Skip to content

Add support for PowerPC64 on FreeBSD #57605

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1,560 commits into from
Closed

Add support for PowerPC64 on FreeBSD #57605

wants to merge 1,560 commits into from

Conversation

lenoil98
Copy link
Contributor

@lenoil98 lenoil98 commented Jan 14, 2019

These are changes to add support for powerpc64 on FreeBSD.

patch-ppc64.txt

sinkuu and others added 30 commits January 6, 2019 15:33
manual impl was a workaround for #28229.
rustc: Fix regression where jemalloc isn't used

In #56986 the linkage of jemalloc to the compiler was switched from the
driver library to the rustc binary to ensure that only rustc itself uses
jemalloc. In doing so, however, it turns out jemalloc wasn't actually
linked in at all! None of the symbols were referenced so the static
library wasn't used. This means that jemalloc wasn't pulled in at all.

This commit performs a bit of a dance to reference jemalloc symbols,
attempting to pull it in despite LLVM's optimizations.

Closes #57115
use structured suggestion for method calls

Furthermore, don't suggest calling the method if it is part of a place
expression, as this is invalid syntax.

I'm thinking it might be worth putting a label on the method assignment span like "this is a method" and removing the span from the "methods are immutable" text so it isn't reported twice.

The suggestions in `src/test/ui/did_you_mean/issue-40396.stderr` are suboptimal. I could check if the containing expression is `BinOp`, but I'm not sure if that's general enough. Any ideas?

r? @estebank
Since the values for the fcntl constants can vary from architecture
to architecture, it is better to use the values defined in the libc
crate instead of assigning literals in the flock code which would
make the assumption that all architectures use the same values.

Fixes #57007
flock: Use fcntl constants directly from libc crate on Unix targets

Since the values for the fcntl constants can vary from architecture
to architecture, it is better to use the values defined in the libc
crate instead of assigning literals in the flock code which would
make the assumption that all architectures use the same values.

Fixes #57007
Make sure feature gate errors are recoverable (take 2)

Continuation of 15cefe4.
Turns out I missed the most important part - the main feature gate checking pass.
privacy: Fix regression in impl reachability

Rollback to pre-#56878 logic of determining reachability.
`reachability(impl Trait<Substs> for Type<Substs>) = reachability(Trait & Type)`, substs are ignored.

Fixes #57264
tests: Do not use `-Z parse-only`, continue compilation to test recovery

Make tests closer to reality!

The next step will be enabling `-Z continue-parse-after-error` by default and looking at the regressions.

A few instances of `-Z parse-only` are kept when it's appropriate, see e.g `ui/impl-trait/impl-trait-plus-priority.rs`, which tests mostly semantically wrong code and would generate too much useless noise if allowed to continue.
Save quite a few syscalls and avoiding pushing in a loop.
…crum

slightly optimize compiletest test collection

Save quite a few syscalls and avoiding pushing in a loop.
…kennytm

Update compiler_builtins 0.1.2 -> 0.1.4

r? @alexcrichton
These can both rely on IEEE754 semantics to be made faster, by folding
away the sign with an abs (left private for now), and then comparing
to infinity, letting the NaN semantics of a direct float comparison
handle NaN input properly.

The `abs` bit-fiddling is simple (a single and), and so these new
forms compile down to a few instructions, without branches, e.g. for
f32:

```asm
is_infinite:
        andps   xmm0, xmmword ptr [rip + .LCPI2_0] ; 0x7FFF_FFFF
        ucomiss xmm0, dword ptr [rip + .LCPI2_1]   ; 0x7F80_0000
        setae   al
        ret

is_finite:
        andps   xmm0, xmmword ptr [rip + .LCPI1_0] ; 0x7FFF_FFFF
        movss   xmm1, dword ptr [rip + .LCPI1_1]   ; 0x7F80_0000
        ucomiss xmm1, xmm0
        seta    al
        ret
```

When used in loops/repeatedly, they get even better: the memory
operations (loading the mask 0x7FFFFFFF for abs, and infinity
0x7F80_0000) are likely to be hoisted out of the individual calls, to
be shared, and the `seta`/`setae` are likely to be collapsed into
conditional jumps or moves (or similar).

The old `is_infinite` did two comparisons, and the old `is_finite` did
three (with a branch), and both of them had to check the flags after
every one of those comparison. These functions have had that old
implementation since they were added in
6284190
7 years ago.

Benchmark (`abs` is the new form, `std` is the old):

```
test f32_is_finite_abs            ... bench:          55 ns/iter (+/- 10)
test f32_is_finite_std            ... bench:         118 ns/iter (+/- 5)

test f32_is_infinite_abs          ... bench:          53 ns/iter (+/- 1)
test f32_is_infinite_std          ... bench:          84 ns/iter (+/- 6)

test f64_is_finite_abs            ... bench:          52 ns/iter (+/- 12)
test f64_is_finite_std            ... bench:         128 ns/iter (+/- 25)

test f64_is_infinite_abs          ... bench:          54 ns/iter (+/- 5)
test f64_is_infinite_std          ... bench:          93 ns/iter (+/- 23)
```

```rust
 #![feature(test)]
extern crate test;

use std::{f32, f64};
use test::Bencher;

const VALUES_F32: &[f32] = &[0.910, 0.135, 0.735, -0.874, 0.518, 0.150, -0.527, -0.418, 0.449, -0.158, -0.064, -0.144, -0.948, -0.103, 0.225, -0.104, -0.795, 0.435, 0.860, 0.027, 0.625, -0.848, -0.454, 0.359, -0.930, 0.067, 0.642, 0.976, -0.682, -0.035, 0.750, 0.005, -0.825, 0.731, -0.850, -0.740, -0.118, -0.972, 0.888, -0.958, 0.086, 0.237, -0.580, 0.488, 0.028, -0.552, 0.302, 0.058, -0.229, -0.166, -0.248, -0.430, 0.789, -0.122, 0.120, -0.934, -0.911, -0.976, 0.882, -0.410, 0.311, -0.611, -0.758, 0.786, -0.711, 0.378, 0.803, -0.068, 0.932, 0.483, 0.085, 0.247, -0.128, -0.839, -0.737, -0.605, 0.637, -0.230, -0.502, 0.231, -0.694, -0.400, -0.441, 0.142, 0.174, 0.681, -0.763, -0.608, 0.848, -0.550, 0.883, -0.212, 0.876, 0.186, -0.909, 0.401, -0.533, -0.961, 0.539, -0.298, -0.448, 0.223, -0.307, -0.594, 0.629, -0.534, 0.959, 0.349, -0.926, -0.523, -0.895, -0.157, -0.074, -0.060, 0.513, -0.647, -0.649, 0.428, 0.401, 0.391, 0.426, 0.700, 0.880, -0.101, 0.862, 0.493, 0.819, -0.597];

 #[bench]
fn f32_is_infinite_std(b: &mut Bencher) {
    b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.is_infinite()));
}
 #[bench]
fn f32_is_infinite_abs(b: &mut Bencher) {
    b.iter(|| test::black_box(VALUES_F32).iter().any(|x| x.abs()== f32::INFINITY));
}
 #[bench]
fn f32_is_finite_std(b: &mut Bencher) {
    b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.is_finite()));
}
 #[bench]
fn f32_is_finite_abs(b: &mut Bencher) {
    b.iter(|| test::black_box(VALUES_F32).iter().all(|x| x.abs() < f32::INFINITY));
}

const VALUES_F64: &[f64] = &[0.910, 0.135, 0.735, -0.874, 0.518, 0.150, -0.527, -0.418, 0.449, -0.158, -0.064, -0.144, -0.948, -0.103, 0.225, -0.104, -0.795, 0.435, 0.860, 0.027, 0.625, -0.848, -0.454, 0.359, -0.930, 0.067, 0.642, 0.976, -0.682, -0.035, 0.750, 0.005, -0.825, 0.731, -0.850, -0.740, -0.118, -0.972, 0.888, -0.958, 0.086, 0.237, -0.580, 0.488, 0.028, -0.552, 0.302, 0.058, -0.229, -0.166, -0.248, -0.430, 0.789, -0.122, 0.120, -0.934, -0.911, -0.976, 0.882, -0.410, 0.311, -0.611, -0.758, 0.786, -0.711, 0.378, 0.803, -0.068, 0.932, 0.483, 0.085, 0.247, -0.128, -0.839, -0.737, -0.605, 0.637, -0.230, -0.502, 0.231, -0.694, -0.400, -0.441, 0.142, 0.174, 0.681, -0.763, -0.608, 0.848, -0.550, 0.883, -0.212, 0.876, 0.186, -0.909, 0.401, -0.533, -0.961, 0.539, -0.298, -0.448, 0.223, -0.307, -0.594, 0.629, -0.534, 0.959, 0.349, -0.926, -0.523, -0.895, -0.157, -0.074, -0.060, 0.513, -0.647, -0.649, 0.428, 0.401, 0.391, 0.426, 0.700, 0.880, -0.101, 0.862, 0.493, 0.819, -0.597];

 #[bench]
fn f64_is_infinite_std(b: &mut Bencher) {
    b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.is_infinite()));
}
 #[bench]
fn f64_is_infinite_abs(b: &mut Bencher) {
    b.iter(|| test::black_box(VALUES_F64).iter().any(|x| x.abs() == f64::INFINITY));
}
 #[bench]
fn f64_is_finite_std(b: &mut Bencher) {
    b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.is_finite()));
}
 #[bench]
fn f64_is_finite_abs(b: &mut Bencher) {
    b.iter(|| test::black_box(VALUES_F64).iter().all(|x| x.abs() < f64::INFINITY));
}
```
Bump stage0

Updates stage 0
From: rustc 1.32.0-beta.2 (a01e476 2018-12-08)
To:   rustc 1.32.0-beta.11 (e64fee6 2019-01-04)

Intended to pull in #57292 which will fix #57142.

The following is a list of PRs this also pulls in in case anyone is interested in seeing the changes:

#56930
#56961
#57236
#57305
Use fonts from the Roman 2.007 and Italic 1.007 version at:
https://github.com/adobe-fonts/source-serif-pro/releases/tag/2.007R-ro%2F1.007R-it

The following files are used from the distribution:

  * WOFF/TTF/SourceSerifPro-Regular.ttf.woff
  * WOFF/TTF/SourceSerifPro-Bold.ttf.woff
  * WOFF/TTF/SourceSerifPro-It.ttf.woff

These replace the older Source Serif Pro regular and bold fonts, and
the Heuristica italic font.
NLL: Fix bug in associated constant type annotations.

Fixes #57280.

This PR reverses the variance used when relating types from the type
annotation of an associated constant - this matches the behaviour of the
lexical borrow checker and fixes a bug whereby matching a `&'a str`
against a `&'static str` would produce an error.

r? @nikomatsakis
estebank and others added 15 commits January 13, 2019 17:36
Tweak output of type mismatch between "then" and `else` `if` arms

```
error[E0308]: if and else have incompatible types
  --> $DIR/if-else-type-mismatch.rs:5:9
   |
LL |       let _ = if true {
   |  _____________-
LL | |         42i32
   | |         ----- expected because of this
LL | |     } else {
LL | |         42u32
   | |         ^^^^^ expected i32, found u32
LL | |     };
   | |_____- if and else have incompatible types
   |
   = note: expected type `i32`
              found type `u32`

error[E0308]: if and else have incompatible types
  --> file.rs:2:38
   |
LL |     let _ = if false { 3u8; } else { 3u8 };
   |                        ----          ^^^ expected (), found u8
   |                        |  |
   |                        |  help: consider removing this semicolon
   |                        expected because of this
   |
   = note: expected type `()`
              found type `u8`

error[E0308]: if and else have incompatible types
  --> file.rs:3:37
   |
LL |     let _ = if false { 3u8 } else { 3u8; };
   |                        ---          ^^^-
   |                        |            |  |
   |                        |            |  help: consider removing this semicolon
   |                        |            expected u8, found ()
   |                        expected because of this
   |
   = note: expected type `u8`
              found type `()`

error[E0308]: if and else have incompatible types
  --> file.rs:4:37
   |
LL |     let _ = if false { 3i8 } else { 3u8 };
   |                        ---          ^^^ expected i8, found u8
   |                        |
   |                        expected because of this
   |
   = note: expected type `i8`
              found type `u8`
```

Fix #57348.
Use structured suggestions for nonstandard style lints

This PR modifies the lints in the nonstandard_style group to use structured suggestions. Note that there's a bit of tricky span calculation going on for the `crate_name` attribute. It also simplifies the code a bit: I don't think the "fallback" suggestions for these lints can actually be triggered.

Fixes #48103.
Fixes #52414.
Stabilize core::convert::identity

r? @SimonSapin

fixes #53500

This is waiting for FCP to complete but in the interim it would be good to review.
Parallelize and optimize parts of HIR map creation

r? @michaelwoerister
MetadataOnlyCodegenBackend: run the collector only once

Use the `collect_and_partition_mono_items` query to avoid calling the collector directly twice.

Fixes #57406.
…shtriplett,Centril

Stabilize cfg_target_vendor

This stabilizes the use of `cfg(target_vendor = "...")` and removes the corresponding `cfg_target_vendor` feature. Other unstable cfgs remain behind their existing feature gates.

This functionality was added back in 2015 in #28612 to complete the coverage of target tuples (`<arch><sub>-<vendor>-<os>-<env>`). [RFC 131](https://github.com/rust-lang/rfcs/blob/master/text/0131-target-specification.md) governs the target specification, not including `target_vendor` seems to have just been an oversight. `target_os`, `target_family`, and `target_arch` are stable as of 1.0.0. `target_env` was also not mentioned in RFC 131, was added in #24777, never behind a feature_gate, and insta-stable at 1.1.0.

The functionality is tested in [test/run-pass/cfg/cfg-target-vendor.rs](https://github.com/rust-lang/rust/blob/master/src/test/run-pass/cfg/cfg-target-vendor.rs).

Closes #29718
clarify resolve typo suggestion

Include the kind of the binding that we're suggesting, and use a
structured suggestion.

Fixes #53445.
privacy: Fix private-in-public check for existential types

Fixes #53546 (regression from #56878)

r? @arielb1
…=sfackler

Remove the `connect_timeout_unroutable` test.

It requires an unreachable IP address, but there is no such thing, and
this has caused it to fail for multiple people.

Fixes #44698, fixes #50065.

r? @sfackler
Rollup of 6 pull requests

Successful merges:

 - #57232 (Parallelize and optimize parts of HIR map creation)
 - #57418 (MetadataOnlyCodegenBackend: run the collector only once)
 - #57465 (Stabilize cfg_target_vendor)
 - #57477 (clarify resolve typo suggestion)
 - #57556 (privacy: Fix private-in-public check for existential types)
 - #57584 (Remove the `connect_timeout_unroutable` test.)

Failed merges:

r? @ghost
Update cargo

13 commits in 34320d212dca8cd27d06ce93c16c6151f46fcf2e..2b4a5f1f0bb6e13759e88ea9512527b0beba154f
2019-01-03 19:12:38 +0000 to 2019-01-12 04:13:12 +0000
- Add test for publish with [patch] + cleanup. (rust-lang/cargo#6544)
- Fix clippy warning (rust-lang/cargo#6546)
- Revert "Workaround by using yesterday's nightly" (rust-lang/cargo#6540)
- Adding feature-flags to `cargo publish` and `cargo package` (rust-lang/cargo#6453)
- Fix the Travis CI badge (rust-lang/cargo#6530)
- Add helpful text for Windows exceptions like Unix (rust-lang/cargo#6532)
- Report fix bugs to Rust instead of Cargo (rust-lang/cargo#6531)
- --{example,bin,bench,test} with no argument now lists all available targets (rust-lang/cargo#6505)
- Rebuild on mid build file modification (rust-lang/cargo#6484)
- Derive Clone for TomlDependency (rust-lang/cargo#6527)
- publish: rework the crates.io detection logic. (rust-lang/cargo#6525)
- avoid duplicates in ignore files (rust-lang/cargo#6521)
- Rustflags in metadata (rust-lang/cargo#6503)

r? @alexcrichton
@rust-highfive
Copy link
Contributor

Some changes occurred in HTML/CSS.

cc @GuillaumeGomez

@rust-highfive
Copy link
Contributor

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @estebank (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive
Copy link
Contributor

⚠️ Warning ⚠️

  • Pull requests are usually filed against the master branch for this repo, but this one is against stable. Please double check that you specified the right target!
  • These commits modify submodules.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 14, 2019
@jonas-schievink
Copy link
Contributor

This should target master, not stable

@lenoil98
Copy link
Contributor Author

my bad! Should've been against master. Please change. tks!

@jonas-schievink
Copy link
Contributor

I don't think this can be changed after the PR is opened. Try opening a new one with the right branches.

@estebank
Copy link
Contributor

I don't think this can be changed after the PR is opened. Try opening a new one with the right branches.

It can. You need to git rebase master and once you're done with the rebase, git push <your_origin> -f.

@jonas-schievink
Copy link
Contributor

@estebank I think that does something different - the problem here is that the PRs target branch was set to stable instead of master, which you can only configure through the GitHub UI

Oh and apparently the source branch is set to this repos master instead of the repo where the code to be merged is located.

@estebank
Copy link
Contributor

estebank commented Jan 14, 2019

You can change the target branch, but for some reason here I can't change it to master, the list of commits is different to what I'd expect.

Now that I think about it, it might not be letting me to select master because it's already merged into this PR.

@lenoil98 lenoil98 closed this Jan 15, 2019
@lenoil98 lenoil98 reopened this Jan 15, 2019
@lenoil98
Copy link
Contributor Author

It's not letting me select master. I'll close the PR and resubmit.

@lenoil98 lenoil98 closed this Jan 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.