Stream: t-compiler/wg-mir-opt

Topic: --bless-ing mir-opt tests


eddyb (Apr 09 2020 at 07:41, on Zulip):

so the command we have been using to handle re-blessing all mir-opt tests is:
rm src/test/mir-opt/**.{diff,mir}; touch src/test/mir-opt/**.rs; /x.py test --stage 1 src/tools/tidy src/test/mir-opt --bless --target x86_64-unknown-linux-gnu --target i686-unknown-linux-gnu

eddyb (Apr 09 2020 at 07:43, on Zulip):

@oli and the thing I'm scared about is PR CI not catching "output changed but only 64bit output was blessed, not 32bit"

eddyb (Apr 09 2020 at 07:44, on Zulip):

I wonder if we could run just mir-opt tests with a 32-bit target on CI

eddyb (Apr 09 2020 at 07:44, on Zulip):

we don't need a 32-bit host which should make it almost free, since it's just stdlib+this test suite

eddyb (Apr 09 2020 at 07:44, on Zulip):

@simulacrum @Pietro Albini ^^ wdyt?

eddyb (Apr 09 2020 at 07:46, on Zulip):

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

Pietro Albini (Apr 09 2020 at 09:45, on Zulip):

@eddyb could you send a PR adding it to a builder so we can measure the impact?

eddyb (Apr 09 2020 at 11:04, on Zulip):

@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

Pietro Albini (Apr 09 2020 at 11:04, on Zulip):

hmm I can't recall off the top of my head

eddyb (Apr 09 2020 at 11:04, on Zulip):

eh I guess I'll try

simulacrum (Apr 09 2020 at 12:03, on Zulip):

we can always add it, that should be not too hard I think

simulacrum (Apr 09 2020 at 12:03, on Zulip):

so long as it's just more apt things

eddyb (Apr 10 2020 at 12:10, on Zulip):

heh we already have two test runs on CI (the second one is for tidy)

eddyb (Apr 10 2020 at 14:25, on Zulip):

so the PR is opened: #70989

eddyb (Apr 10 2020 at 14:26, on Zulip):

@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?

simulacrum (Apr 10 2020 at 14:26, on Zulip):

nah, gha should be fine for this

eddyb (Apr 10 2020 at 16:18, on Zulip):

@simulacrum c u r s e d https://github.com/rust-lang/rust/pull/70989#issuecomment-612103573

simulacrum (Apr 10 2020 at 16:20, on Zulip):

uh no you cannot really get a coredump from CI unfortunately

simulacrum (Apr 10 2020 at 16:20, on Zulip):

I guess retry?

simulacrum (Apr 10 2020 at 16:20, on Zulip):

or we can run locally...

eddyb (Apr 10 2020 at 16:20, on Zulip):

yeah I can bite the bullet and try to use Docker

eddyb (Apr 10 2020 at 17:51, on Zulip):

@simulacrum I missed this https://github.com/rust-lang/rust/pull/70989#issuecomment-612133962

eddyb (Apr 10 2020 at 17:51, on Zulip):

what's the goal here?

eddyb (Apr 10 2020 at 17:52, on Zulip):

I didn't change the Dockerfile that @bors try will use, AFAIK

eddyb (Apr 10 2020 at 17:53, on Zulip):

this is a noop PR modulo src/ci/docker/x86_64-gnu-llvm-7/Dockerfile

simulacrum (Apr 10 2020 at 17:53, on Zulip):

Did I miss a try build?

simulacrum (Apr 10 2020 at 17:53, on Zulip):

oh I see

simulacrum (Apr 10 2020 at 17:53, on Zulip):

yeah I see what you mean

eddyb (Apr 10 2020 at 17:53, on Zulip):

feel free to cancel the try build if it's pointless :P

simulacrum (Apr 10 2020 at 17:54, on Zulip):

I forget how to do that

simulacrum (Apr 10 2020 at 17:54, on Zulip):

g++-multilib vs. gcc may be causing the linker trouble?

eddyb (Apr 10 2020 at 17:54, on Zulip):

what linker trouble?

simulacrum (Apr 10 2020 at 17:54, on Zulip):

but it looks like we're specifically having problems with rustc segfaulting, not the linker

eddyb (Apr 10 2020 at 17:54, on Zulip):

I fixed the first failure by switching to -multilib

simulacrum (Apr 10 2020 at 17:54, on Zulip):

well, I mean that g++-multilib could be giving us a broken compiler somehow

eddyb (Apr 10 2020 at 17:54, on Zulip):

which started segfaulting :D

eddyb (Apr 10 2020 at 17:54, on Zulip):

ah okay

eddyb (Apr 10 2020 at 17:55, on Zulip):

@simulacrum I can make the @bors try Dockerfile pass --target=i686-... if you want to test that

simulacrum (Apr 10 2020 at 17:55, on Zulip):

yeah let's do that I guess

eddyb (Apr 10 2020 at 17:55, on Zulip):

and even run the mir-opt tests actually, that should be easy

eddyb (Apr 10 2020 at 17:58, on Zulip):

@simulacrum ugh dist-x86_64-linux is CentOS

eddyb (Apr 10 2020 at 17:58, on Zulip):

let me try to bump the LLVM version instead

simulacrum (Apr 10 2020 at 17:58, on Zulip):

alternatively we can use the normal x86 tests builder probably

eddyb (Apr 10 2020 at 17:59, on Zulip):

we're on LLVM9 nowadays right?

simulacrum (Apr 10 2020 at 17:59, on Zulip):

that sounds correct

eddyb (Apr 10 2020 at 19:31, on Zulip):

ugh where does https://packages.ubuntu.com/bionic/devel/llvm-9-tools place LLVM

eddyb (Apr 10 2020 at 19:32, on Zulip):

oh https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/blob/9/debian/llvm-X.Y-tools.install.in

eddyb (Apr 10 2020 at 19:34, on Zulip):

wait why didn't usr/bin/llvm-9 work :/

eddyb (Apr 10 2020 at 19:37, on Zulip):

oh lol you just run llvm-config-9

eddyb (Apr 10 2020 at 19:37, on Zulip):

at least their scripts do

eddyb (Apr 10 2020 at 20:40, on Zulip):

what the hell, that doesn't exist

eddyb (Apr 10 2020 at 20:41, on Zulip):

is it just lies or is llvm-9-tools the wrong package?!

eddyb (Apr 10 2020 at 20:52, on Zulip):

failed to execute command: "/usr/bin/llvm-config" "--bindir"
error: No such file or directory (os error 2)

eddyb (Apr 10 2020 at 20:52, on Zulip):

ughhhh

eddyb (Apr 10 2020 at 21:03, on Zulip):

okay found something https://packages.ubuntu.com/search?suite=bionic-updates&arch=any&mode=filename&searchon=contents&keywords=llvm-config

eddyb (Apr 10 2020 at 21:05, on Zulip):

why were we using llvm-7-tools? only llvm-7-dev looks correct :|

eddyb (Apr 10 2020 at 21:07, on Zulip):

@simulacrum goddammit I figured it out:

eddyb (Apr 10 2020 at 21:26, on Zulip):

@simulacrum nailed it :)

eddyb (Apr 10 2020 at 21:26, on Zulip):

now to see if this fixes the segfault lol

eddyb (Apr 10 2020 at 21:54, on Zulip):

lol I found a bug

eddyb (Apr 10 2020 at 21:55, on Zulip):

siiiiigh

eddyb (Apr 10 2020 at 22:54, on Zulip):

@simulacrum progress! https://github.com/rust-lang/rust/pull/70989#issuecomment-612254495

simulacrum (Apr 10 2020 at 23:03, on Zulip):

I'm a bit confused how your PR managed to trigger this

eddyb (Apr 10 2020 at 23:04, on Zulip):

@simulacrum we don't really use LLVM 7 nowadays :P

simulacrum (Apr 10 2020 at 23:05, on Zulip):

Well I mean that you didn't change anything in built-ins

eddyb (Apr 10 2020 at 23:05, on Zulip):

and it's system LLVM so it could have old bugs we're hitting with new compiler code

eddyb (Apr 10 2020 at 23:05, on Zulip):

@simulacrum I think we've been running miscompiled rustc for a while :)

eddyb (Apr 10 2020 at 23:06, on Zulip):

it just doesn't affect 64-bit builds

eddyb (Apr 10 2020 at 23:06, on Zulip):

I will take a simpler explanation but idk

simulacrum (Apr 10 2020 at 23:06, on Zulip):

Hm alright

eddyb (Apr 10 2020 at 23:06, on Zulip):

@simulacrum oh oh I know how to bypass this: run the tests at stage1 :D

eddyb (Apr 10 2020 at 23:06, on Zulip):

we have no ignore-stage1 mir-opt tests

simulacrum (Apr 10 2020 at 23:08, on Zulip):

Seems intriguing

simulacrum (Apr 10 2020 at 23:09, on Zulip):

I don't really care :)

eddyb (Apr 10 2020 at 23:11, on Zulip):

@simulacrum do you want me to open an issue or should we treat this as a LLVM7 WONTFIX?

eddyb (Apr 10 2020 at 23:12, on Zulip):

the easiest thing I can offer is a tiny diff for the PR CI Dockerfile

simulacrum (Apr 10 2020 at 23:13, on Zulip):

Let's treat as won't fix

eddyb (Apr 10 2020 at 23:43, on Zulip):

@simulacrum welp, workaround wouldn't work https://github.com/rust-lang/rust/pull/70989#issuecomment-612267971

eddyb (Apr 10 2020 at 23:44, on Zulip):

I'm guessing not_atomic is too new?

eddyb (Apr 10 2020 at 23:44, on Zulip):

and the connection is that 32-bit targets need some atomic emulation or something

simulacrum (Apr 10 2020 at 23:44, on Zulip):

Hm yeah seems plausible

simulacrum (Apr 10 2020 at 23:45, on Zulip):

I guess we'll have to just not test this on a PR builder?

simulacrum (Apr 10 2020 at 23:45, on Zulip):

I'd rather not bump llvm version for this

simulacrum (Apr 10 2020 at 23:46, on Zulip):

(even if I guess it's broken for 32 bit anyway)

eddyb (Apr 10 2020 at 23:47, on Zulip):

likely caused by https://github.com/rust-lang/compiler-builtins/pull/311

eddyb (Apr 10 2020 at 23:51, on Zulip):

left https://github.com/rust-lang/compiler-builtins/pull/311#issuecomment-612270089

eddyb (Apr 10 2020 at 23:53, on Zulip):

it's gated by #[cfg(target_has_atomic_load_store = "64")]

eddyb (Apr 10 2020 at 23:54, on Zulip):

shot: https://github.com/rust-lang/rust/blob/master/src/librustc_target/spec/i686_unknown_linux_gnu.rs#L6
chaser: https://github.com/rust-lang/rust/blob/master/src/librustc_target/spec/i586_unknown_linux_gnu.rs

eddyb (Apr 11 2020 at 02:18, on Zulip):

aaaand it still segfaults :/ https://github.com/rust-lang/rust/pull/70989#issuecomment-612292682

eddyb (Apr 11 2020 at 02:18, on Zulip):

time to go back to LLVM 8 to diagnose sigh

eddyb (Apr 11 2020 at 02:24, on Zulip):

image.png

eddyb (Apr 11 2020 at 02:24, on Zulip):

this may be the GitHub extension. just noticed this, seems handy heh

eddyb (Apr 11 2020 at 03:17, on Zulip):

@simulacrum okay armv5te-unknown-linux-gnueabi works lmao

Last update: Jan 22 2021 at 13:30UTC