so the command we have been using to handle re-blessing all mir-opt tests is:
/x.py test --stage 1 src/tools/tidy src/test/mir-opt --bless --target x86_64-unknown-linux-gnu --target i686-unknown-linux-gnu
@oli and the thing I'm scared about is PR CI not catching "output changed but only 64bit output was blessed, not 32bit"
I wonder if we could run just
mir-opt tests with a 32-bit target on CI
we don't need a 32-bit host which should make it almost free, since it's just stdlib+this test suite
@simulacrum @Pietro Albini ^^ wdyt?
or we could error if you use
--bless with the
mir-opt test suite and a 64bit file changes but you don't have a 32bit target as well (or the other way around I suppose) but compiletest doesn't know the targets, only the build system does
@eddyb could you send a PR adding it to a builder so we can measure the impact?
@Pietro Albini does the linux x64 PR CI builder have the multilib stuff installed? I mean for linking, even though running these tests doesn't really need a linkable libstd heh
hmm I can't recall off the top of my head
eh I guess I'll try
we can always add it, that should be not too hard I think
so long as it's just more apt things
heh we already have two test runs on CI (the second one is for tidy)
so the PR is opened: #70989
@simulacrum for testing (I plan to add a commit that will create an intentional failure), do you think it's okay to rely on GHA or should I wait for Azure as well?
nah, gha should be fine for this
@simulacrum c u r s e d https://github.com/rust-lang/rust/pull/70989#issuecomment-612103573
uh no you cannot really get a coredump from CI unfortunately
I guess retry?
or we can run locally...
yeah I can bite the bullet and try to use Docker
@simulacrum I missed this https://github.com/rust-lang/rust/pull/70989#issuecomment-612133962
what's the goal here?
I didn't change the Dockerfile that
@bors try will use, AFAIK
this is a noop PR modulo
Did I miss a try build?
oh I see
yeah I see what you mean
feel free to cancel the try build if it's pointless :P
I forget how to do that
g++-multilib vs. gcc may be causing the linker trouble?
what linker trouble?
but it looks like we're specifically having problems with rustc segfaulting, not the linker
I fixed the first failure by switching to
well, I mean that g++-multilib could be giving us a broken compiler somehow
which started segfaulting :D
@simulacrum I can make the
@bors try Dockerfile pass
--target=i686-... if you want to test that
yeah let's do that I guess
and even run the mir-opt tests actually, that should be easy
dist-x86_64-linux is CentOS
let me try to bump the LLVM version instead
alternatively we can use the normal x86 tests builder probably
we're on LLVM9 nowadays right?
that sounds correct
ugh where does https://packages.ubuntu.com/bionic/devel/llvm-9-tools place LLVM
wait why didn't usr/bin/llvm-9 work :/
oh lol you just run
at least their scripts do
what the hell, that doesn't exist
is it just lies or is llvm-9-tools the wrong package?!
failed to execute command: "/usr/bin/llvm-config" "--bindir"
error: No such file or directory (os error 2)
why were we using
llvm-7-dev looks correct :|
@simulacrum goddammit I figured it out:
@simulacrum nailed it :)
now to see if this fixes the segfault lol
lol I found a bug
@simulacrum progress! https://github.com/rust-lang/rust/pull/70989#issuecomment-612254495
I'm a bit confused how your PR managed to trigger this
@simulacrum we don't really use LLVM 7 nowadays :P
Well I mean that you didn't change anything in built-ins
and it's system LLVM so it could have old bugs we're hitting with new compiler code
@simulacrum I think we've been running miscompiled rustc for a while :)
it just doesn't affect 64-bit builds
I will take a simpler explanation but idk
@simulacrum oh oh I know how to bypass this: run the tests at stage1 :D
we have no ignore-stage1 mir-opt tests
I don't really care :)
@simulacrum do you want me to open an issue or should we treat this as a LLVM7 WONTFIX?
the easiest thing I can offer is a tiny diff for the PR CI
Let's treat as won't fix
@simulacrum welp, workaround wouldn't work https://github.com/rust-lang/rust/pull/70989#issuecomment-612267971
not_atomic is too new?
and the connection is that 32-bit targets need some atomic emulation or something
Hm yeah seems plausible
I guess we'll have to just not test this on a PR builder?
I'd rather not bump llvm version for this
(even if I guess it's broken for 32 bit anyway)
likely caused by https://github.com/rust-lang/compiler-builtins/pull/311
it's gated by
#[cfg(target_has_atomic_load_store = "64")]
aaaand it still segfaults :/ https://github.com/rust-lang/rust/pull/70989#issuecomment-612292682
time to go back to LLVM 8 to diagnose sigh
this may be the GitHub extension. just noticed this, seems handy heh
armv5te-unknown-linux-gnueabi works lmao