Building 1.74.0 natively on NetBSD/powerpc results in "pattern Some(_) not covered" error message

[he32]

While trying to build 1.74.0 natively on NetBSD/powerpc 10.0_BETA, I appear to be unable to cross this problem by myself. It doesn't look like the armv7 or aarch64 NetBSD targets are similarly affected, so this is probably more a powerpc issue than a NetBSD issue.

     Running `/usr/pkgsrc/wip/rust174/work/rust-bootstrap/bin/rustc --crate-name build_script_main --edition=2018 /usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/vendor/typenum-1.15.0/build/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C metadata=ef76ccfc9e00eb4a -C extra-filename=-ef76ccfc9e00eb4a --out-dir /usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/build/bootstrap/debug/build/typenum-ef76ccfc9e00eb4a -L dependency=/usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/build/bootstrap/debug/deps --cap-lints allow -Wrust_2018_idioms -Wunused_lifetimes -Dwarnings`
error[E0004]: non-exhaustive patterns: `Some(_)` not covered
   --> /usr/pkgsrc/wip/rust174/work/rustc-1.74.0-src/vendor/version_check/src/lib.rs:290:11
    |
290 |     match is_feature_flaggable() {
    |           ^^^^^^^^^^^^^^^^^^^^^^ pattern `Some(_)` not covered
    |
note: `Option<bool>` defined here
   --> /usr/pkgsrc/wip/rust/work/rustc-1.73.0-src/library/core/src/option.rs:571:5
    |
563 | pub enum Option<T> {
    | ------------------
...
571 |     Some(#[stable(feature = "rust1", since = "1.0.0")] T),
    |     ^^^^ not covered
    = note: the matched value is of type `Option<bool>`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
    |
293 ~         None => return None,
294 ~         Some(_) => todo!(),
    |

For more information about this error, try `rustc --explain E0004`.
error: could not compile `version_check` (lib) due to previous error

Once again I solicit assistance about how to cross this hurdle.
And ... why does this happen just for this target?
At least this hurdle appears to be consistent / reproducible...

[estebank]

For context, the relevant snippet where we seem to have an exhaustiveness check bug:

pub fn supports_feature(feature: &str) -> Option<bool> {
    match is_feature_flaggable() {
        Some(true) => { /* continue */ }
        Some(false) => return Some(false),
        None => return None,
    }

[Noratrieb]

that is not very good, it seems very bad even. I think your compiler has been miscompiled and is buggy now. version_check doesn't have any platform-specific code, so it feels like the only possible explanation is that there is a bug in PowerPC codegen (at least the only explanation I can think of). Did you use any special config when compiling the 1.73 compiler? It would also be very useful to try to reproduce this on non-netbsd PowerPC targets.

[he32]

that is not very good, it seems very bad even. I think your compiler has been miscompiled and is buggy now. version_check doesn't have any platform-specific code, so it feels like the only possible explanation is that there is a bug in PowerPC codegen (at least the only explanation I can think of).

That's ... not good. Is there something I could do to try to narrow this down, perhaps using the 1.73.0 compiler?

Did you use any special config when compiling the 1.73 compiler? It would also be very useful to try to reproduce this on non-netbsd PowerPC targets.

There are a few adjustments done for powerpc to reduce the size of the bits produced:

CONFIGURE_ARGS+=        --disable-debug
CONFIGURE_ARGS+=        --disable-debug-assertions
CONFIGURE_ARGS+=        --disable-llvm-release-debuginfo
CONFIGURE_ARGS+=        --debuginfo-level=0
CONFIGURE_ARGS+=        --debuginfo-level-rustc=0
CONFIGURE_ARGS+=        --debuginfo-level-std=0
CONFIGURE_ARGS+=        --debuginfo-level-tools=0
CONFIGURE_ARGS+=        --debuginfo-level-tests=0

Other than that, I managed to pick up #116845 and a fix for that issue is also included in the 1.73.0 bits. Other than that it's configured similarly to all the other NetBSD targets, and I have rust 1.74.0 for amd64 successfully building firefox, and the result runs (for the limited testing I've been able to do). It also seems that both the armv7, aarch64 and riscv64 native builds have passed this particular point in their respective builds. So this points the suspicion in the direction of this being something powerpc-specific.

One thing worth mentioning is that the bootstrap kit for 1.73.0 for powerpc is cross-built (on NetBSD/amd64), and as such, is built using the embedded LLVM in the rust compiler distribution. I will take a stab at natively building a test bootstrap kit for 1.73.0 using an older external LLVM, to see if that makes any difference. It'll take a while...

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

[he32]

OK, I have "liftoff" for a build of 1.74.0, using a 1.73.0 built against an external LLVM 15.0.7, and version_check has already been successfully built. This 1.74.0 is also being built against the external LLVM.

[he32]

OK, I have "liftoff" for a build of 1.74.0, using a 1.73.0 built against an external LLVM 15.0.7, and version_check has already been successfully built. This 1.74.0 is also being built against the external LLVM.

FYI: that build of 1.74.0 has now completed successfully.

[apiraino]

cc @nikic could be interested in this issue (context seems that on 1.74 our LLVM miscompiles on this NetBSD/powerpc target)

@rustbot label +A-LLVM

[he32]

cc @nikic could be interested in this issue (context seems that on 1.74 our LLVM miscompiles on this NetBSD/powerpc target)

Actually, the issue may have started with the LLVM inside 1.73.0 -- the original issue was flagged so early in the build that it's the bootstrap compiler which flagged the error.

[he32]

cc @nikic could be interested in this issue (context seems that on 1.74 our LLVM miscompiles on this NetBSD/powerpc target)

Actually, the issue may have started with the LLVM inside 1.73.0 -- the original issue was flagged so early in the build that it's the bootstrap compiler which flagged the error.

I'm going to re-test to build 1.74.0 with the internal LLVM using the 1.73.0 bootstrap built with an external 15.0.7 LLVM, and since rust builds itself several times, we'll see if that flags the error.

[he32]

I'm going to re-test to build 1.74.0 with the internal LLVM using the 1.73.0 bootstrap built with an external 15.0.7 LLVM, and since rust builds itself several times, we'll see if that flags the error.

I can now report that that build of 1.74.0 actually succeeded. That is, 1.74.0 built with the rust-supplied LLVM.

[nikic]

Does this mean this issue can be closed?

[he32]

Does this mean this issue can be closed?

Well, it's a clear indication that all is not well with the LLVM integrated in 1.73.0 when it comes to powerpc code generation. For now I have worked around the issue by building the 1.73.0 bootstrap using an external (older) LLVM. That doesn't mean that there isn't a problem, though... But it doesn't look like 1.74.0 has this particular problem.

[nikic]

The LLVM in 1.73 does indeed have a known issue, see #116845. If I understand correctly, this issue is a duplicate of that one, just now encountered when using it as a bootstrap compiler?

[he32]

The LLVM in 1.73 does indeed have a known issue, see #116845. If I understand correctly, this issue is a duplicate of that one, just now encountered when using it as a bootstrap compiler?

Well, the change from that issue was already found and installed, but it appears that there is yet another problem with the 1.73.0 compiler despite that fix being applied.

[nikic]

Ah I see, thanks for the clarification.