thread 'rustc' panicked at 'expected expression', compiler/rustc_expand/src/base.rs:176:18

[psumbera]

When I build Rust 1.67.1 on Solaris SPARC build fails with following error (where build on Solaris x86 is ok):

..
   Compiling aho-corasick v0.7.18
   Compiling bstr v0.2.17
   Compiling combine v4.6.6
thread 'rustc' panicked at 'expected expression', compiler/rustc_expand/src/base.rs:176:18
stack backtrace:
   0:    0x7fcff44d63450 - <unknown>
   1:    0x7fcff44e0e088 - <unknown>
   2:    0x7fcff44d2b904 - <unknown>
   3:    0x7fcff44d631dc - <unknown>
   4:    0x7fcff44d5be20 - <unknown>
   5:    0x7fcff44d5ba50 - <unknown>
   6:    0x7fcff44d54428 - <unknown>
   7:    0x7fcff4b6162cc - <unknown>
   8:    0x7fcff44d5cabc - <unknown>
   9:    0x7fcff44d63860 - <unknown>
  10:    0x7fcff44d635e0 - <unknown>
  11:    0x7fcff44d5c284 - <unknown>
  12:    0x7fcff44e0bb90 - <unknown>
  13:    0x7fcff5114bfe8 - <unknown>
  14:    0x7fcff5112be98 - <unknown>
  15:    0x7fcff5112f134 - <unknown>
  16:    0x7fcff5112cad0 - <unknown>
  17:    0x7fcff4b77ea54 - <unknown>
  18:    0x7fcff4b775d70 - <unknown>
  19:    0x7fcff4b7b0190 - <unknown>
  20:    0x7fcff4b5dcb14 - <unknown>
  21:    0x7fcff4b5c7bbc - <unknown>
  22:    0x7fcff4b579c70 - <unknown>
  23:    0x7fcff4b54efc0 - <unknown>
  24:    0x7fcff44d2d4dc - <unknown>
  25:    0x7fcff449c4d84 - <unknown>

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

For build I use:

rustc-1.66.0

[albertlarsan68]

Can you share the code that caused the ICE please?

[psumbera]

Can you share the code that caused the ICE please?

https://github.com/rust-lang/rust/blob/1.67.1/compiler/rustc_expand/src/base.rs#L176

[psumbera]

I tried to git bisect first bad commit. The result was:

97d8a9b

But unfortuantely when I trited to use reverse version of the patch on Rust 1.67.1 source tree the problem was still there...

--

Note also that I do see this internal error only when I build like this:

/usr/bin/python3 src/bootstrap/bootstrap.py build --stage 2

(which is executed when I do: ./configure; gmake).

When I build Rust using x.py build it seems to build without problems.

--

Also I don't see the issue when I trie to build Rust to use system LLVM 13 form OS (--enable-llvm-link-shared --llvm-root=/usr).

--

Note that this is very likely the same issue as reported for BSD here:

#108117

--

@the8472 can you please look at this issue?

[the8472]

That commit changes field ordering of repr(Rust) structs. It's possible that some code somewhere incorrectly relies on field order without using repr(C). But then the question is why this doesn't happen with system llvm? Something specific to sparc ABI?
You could try reverting all of #102750 instead of just that commit.

Also, have you tried building rustc and LLVM with asserts enabled?

[psumbera]

I did some other bisecting and found another problematic commit (on top of the one mentioned above):

53e4b9d

I can confirm that with reverting following two commits I can build Rust 1.67.1:
97d8a9b
53e4b9d

@mikebenfield can you please have look at this too?

For some reason the stack is on Solaris broken unlike on BSD (#108117). But in both cases it hits the same assertion.

[the8472]

Sparc is big-endian, isn't it? We don't have many of those platforms. Maybe something related to the niche codegen has endianness bugs.

[psumbera]

Sparc is big-endian, isn't it? We don't have many of those platforms. Maybe something related to the niche codegen has endianness bugs.

Right. Sparc is big-endian.

[workingjubilee]

@psumbera The "code that caused the ICE" meant "the code that rustc was compiling", not the code in rustc.

cc @ecnelises @bzEq Does this issue surface on AIX? I believe you're using POWER in BE mode, so if this is a pure endianness bug then it should repro.

[he32]

NetBSD/powerpc is big-endian, and was not affected by this particular problem, though that's a 32-bit target. This particular issue only occurred when re-building rust natively on sparc64, which is 64-bit big-endian.

I do not yet have other big-endian 64-bit targets operational with "native" testing ability, though some of that is on my TODO list (mips, arm64).

[bzEq]

Does this issue surface on AIX?

We are upgrading our compiler from 1.64.0-dev to 1.70.0-dev, once we have information about this question, we'll post our findings.

[psumbera]

The issue went away with Rust 1.68.0. Particularly with commit 2f9f097.

Whole time I could build it using x.py build. While /usr/bin/python3 src/bootstrap/bootstrap.py build --stage 2 was failing. What is actually difference between these two?

[albertlarsan68]

Did x.py build --stage 2 failed?

[psumbera]

Did x.py build --stage 2 failed?

Yes

[bzEq]

We are upgrading our compiler from 1.64.0-dev to 1.70.0-dev, once we have information about this question, we'll post our findings.

We have bootstrapped stage3 1.70.0-dev, the error is not reproduced on AIX.

[workingjubilee]

Thank you for that information, @bzEq!

Removing E-needs-mcve since this happened during bootstrap. Tagging with T-bootstrap because the difference between the two x.py build and python3 x.py build --stage 2 commands seems to be unexpected. Since this has stopped happening, we can close this if we can diagnose the difference between those two commands.

[jyn514]

The global stage default for build is 1, not 2, as documented at https://rustc-dev-guide.rust-lang.org/building/bootstrapping.html#building-the-stages.

[workingjubilee]

Oh! I didn't know that.