Rustc 1.34 on Solaris SPARC fails with - Expected no forward declarations!

[psumbera]

I was able to build Rust 1.34 on Solaris SPARC without any issue. But when I try it to build Rust 1.35 it fails like this:

/builds/psumbera/rustc-1.34.0/bin//rustc --crate-name unicode_xid /builds/psumbera/userland-rust/components/rust/rustc/rustc-1.35.0-src-vendored-sources/unicode-xid/src/lib.rs --color always --crate-type lib --emit=dep-info,link -C debug-assertions=off -C overflow-checks=on --cfg 'feature="default"' -C metadata=71eab7b4d85734ec -C extra-filename=-71eab7b4d85734ec --out-dir /builds/psumbera/userland-rust/components/rust/rustc/build/sparcv9/build/bootstrap/debug/deps -L dependency=/builds/psumbera/userland-rust/components/rust/rustc/build/sparcv9/build/bootstrap/debug/deps --cap-lints allow -Cdebuginfo=2
Expected no forward declarations!Expected no forward declarations!
!13 = <temporary!> !{}

scope points into the type hierarchy
!19 = !<temporary!> 15!{} =
!DILocation(Expected no forward declarations!scope points into the type hierarchyline:
Expected no forward declarations!

1, scope: !!424) = !20!DILocation(line
: 1,  = Expected no forward declarations!<temporary!> !!{scope
: 32Expected no forward declarations! = !<temporary!> 4
)!{}
!
34scope points into the type hierarchy =
<temporary!> scope points into the type hierarchy!{scope points into the type hierarchy
}
!26
 = !DILocation(line!: 16scope points into the type hierarchy! = 1297!DILocation(
34line = , : !DILocation(column!: line241, 8: 37column, 1scope: ,  = 35scope: , !DILocation(!scope: line: !: 4!131), )4
)
scope points into the type hierarchyscope

: scope points into the type hierarchy!!1227
) =
scope points into the type hierarchy!DILocation(
scope points into the type hierarchy!
line: 381297!!, 36! = column = 1838: <temporary!> !DILocation( =  = 20line!{!DILocation(!DILocation(}, : 22linescopeline: : : 284
, 241!column4, , column)column: : :
1248, , , scope points into the type hierarchyscopescopescope: : !: !
!412scope points into the type hierarchy)13))


scope points into the type hierarchyscope points into the type hierarchy


!scope points into the type hierarchy28
 = !DILocation(!!line41: 19 = 1298 = !DILocation(!, !DILocation(linecolumnline44!: : 37: 5 = 287242, , !DILocation( = scopecolumnline!DILocation(: , line: !column41: : 22: ), 5, 5column,
scope, scopescope: : 23: : , !!412))scope!: !
19
13)scope points into the type hierarchy)


scope points into the type hierarchy!42
 = scope points into the type hierarchy!DILocation(line
: 284, column: !LLVM ERROR: 38LLVM ERROR: 21 = , !DILocation(linescope!: 46:  = 27!12, !DILocation(columnline): : 1
325scope points into the type hierarchy, , scopecolumn
Broken function found, compilation aborted!: : !8Broken function found, compilation aborted!, 13!)scope43
:  = !DILocation(!LLVM ERROR: 19lineBroken function found, compilation aborted!: )283,
scope points into the type hierarchycolumn: 8
, scope
:
!12)
pure virtual method called
pure virtual method called
terminate called recursively
terminate called without an active exception

pure virtual method called
terminate called recursively
Abort (core dumped)

Note that when I change in above line Rustc version to 1.33 it passes.

The generated core dump has following stack:

0007fff7398ec861 libc.so.1`__lwp_sigqueue+8(6, ffffffffffffffec, 7fff7398ed100, 5, 0, 0)
0007fff7398ec911 libc.so.1`abort+0xfc(1, 1210, 0, 1000, 0, 0)
0007fff7398ec9f1 libstdc++.so.6.0.24`__gnu_cxx::__verbose_terminate_handler+0x14c(0, 0, 0, 0, 0, 0)
0007fff7398ecab1 libstdc++.so.6.0.24`__cxxabiv1::__terminate+4(7fff7261bf1ec, 300001dc000, 1b, 0, 1, 194)
0007fff7398ecb61 libstdc++.so.6.0.24`std::terminate+0xc(1b, 7fff7261b4fc8, 1b, 0, 1, 7fff73e3b1a40)
0007fff7398ecc11 libstdc++.so.6.0.24`__cxa_pure_virtual+0x28(7fff728bec088, 7fff7398ed6ff, 1, 3567f8dd70, 6b5d509, 80)
0007fff7398eccc1 libLLVM-6.0.so`llvm::raw_ostream::write+0x160(7fff728bec088, 7fff7398ed6ff, 1, 648424d, 0, 7fff73bb04430)
0007fff7398ecd81 libLLVM-6.0.so`llvm::formatted_raw_ostream::write_impl+0x4c(7fff7398ed898, 7fff7398ed6ff, 1, 7fff73bb04430, 1, 7fff73bb04430)
0007fff7398ece41 libLLVM-6.0.so`llvm::raw_ostream::write+0xc4(7fff7398ed898, 21, 356800bc60, 7fff7398ed6f8, 7fff7398ed898, 7fff73bb04430)
0007fff7398ecf11 libLLVM-6.0.so`WriteAsOperandInternal.isra.778+0x26c(7fff7398ed898, 356806cd38, 7fff7398ed8d8, 356801df40, 2e, 7fff73bb04430)
0007fff7398ecfe1 libLLVM-6.0.so`printMetadataImpl+0x160(7fff728bec088, 356806cd38, 35683af930, 35681de470, 0, 7fff728b25da8)
0007fff7398ed161 libLLVM-6.0.so`llvm::Metadata::printconst+0x40(356806cd38, 7fff728bec088, 35683af930, 35681de470, 0, 7fff73bb04430)
0007fff7398ed221 libLLVM-6.0.so`llvm::VerifierSupport::Write.part.107+0x40(35683af920, 356806cd38, 7fff73bb04430, 0, 7fff728bec088, 7fff73bb04430)
0007fff7398ed2e1 libLLVM-6.0.so`.part.1042+0xb10(35683af920, 356806cd38, 0, 3568241560, 7fff73bb04430, fffffffffffffff8)
0007fff7398ed431 libLLVM-6.0.so`+0xdc(35683af920, 356806cd38, 0, 3567bdbe00, 20, 7fff73bb04430)
0007fff7398ed501 libLLVM-6.0.so`+0x1564(35683af920, 3568247dc8, fffffff, 1, 356806cd38, 7fff73bb04430)
0007fff7398ed6b1 libLLVM-6.0.so`+0x184(35683af920, 3568247dc8, 7fff7398edef8, 35681dbd90, 1, 7fff73bb04430)
0007fff7398ed781 libLLVM-6.0.so`.part.1265+0xcc8(35683af920, 3568235380, 35682473b8, fffffff, 3568247dc8, 3568247de0)
0007fff7398ed9d1 libLLVM-6.0.so`+0x208(35683af920, 35682318e8, 7fff73e2ebdc0, 3568231930, 7fff73bb04430, 3568231930)
0007fff7398edaa1 libLLVM-6.0.so`+0x34(3567b74440, 35682318e8, 0, 0, 0, 7fff73bb04430)
0007fff7398edb61 libLLVM-6.0.so`llvm::FPPassManager::runOnFunction+0x360(35682818d0, 35682318e8, 7fff73bb04430, 3, 35682818f0, 3567b74440)
0007fff7398edc71 libLLVM-6.0.so`llvm::FPPassManager::runOnModule+0x54(35682818d0, 35681de488, 0, 7fff73bb04430, 0, 3568231920)
0007fff7398edd31 libLLVM-6.0.so`llvm::legacy::PassManagerImpl::run+0x35c(356823e320, 35681de470, 1, 0, 35682818d0, 35682616d0)
0007fff7398ede21 libLLVM-6.0.so`llvm::legacy::PassManager::run+0x34(3567ba2940, 35681de470, 7fff7398ee7b8, 1, 1, 7fff73bb04430)
0007fff7398edee1 librustc_codegen_llvm-llvm.so`LLVMRustWriteOutputFile+0x1a0(35682155c0, 3567ba2940, 35681de470, 356822b970, 7fff7398ee7b8, 7fff73bb04430)
0007fff7398ee051 librustc_codegen_llvm-llvm.so`rustc_codegen_llvm::back::write::write_output_file::h06f62ffa85513e02.llvm.6134306529257019547+0x40(7fff7398ef0b0, 35682155c0, 3567ba2940,
35681de470, 356822aa00, 9c)
0007fff7398ee181 librustc_codegen_llvm-llvm.so`rustc_codegen_llvm::back::write::codegen::_$u7b$$u7b$closure$u7d$$u7d$::hb89b8dc96d0d6653.llvm.67276690187451607+0x33c(7fff7398eeb30,
7fff7398ef0b0, 35682155c0, 356822aa00, 35681de470, 3567ba2940)
0007fff7398ee271 librustc_codegen_llvm-llvm.so`rustc::util::common::time_ext::h203241132f3eb1ac+0x70(7fff7398eeb30, 0, 3567ba1cd0, 2b, 7fff7398eedb0, 7fff72fd84000)
0007fff7398ee381
librustc_codegen_llvm-llvm.so`_$LT$rustc_codegen_llvm..LlvmCodegenBackend$u20$as$u20$rustc_codegen_ssa..traits..write..WriteBackendMethods$GT$::codegen::h52f8e70916952150+0x97c(3567ba1cd0, 0, 7fff7398eed88, 7fff7398eed17, 3568075e00, 35681d7240)
0007fff7398ee651 librustc_codegen_llvm-llvm.so`rustc_codegen_ssa::back::write::execute_work_item::h9629fd05538e626e+0x11b4(35681ccf40, 3567b8aa20, 7fff7398ef508, 7fff7398ef598, 7fff7398ef300, 1)
0007fff7398eea31 librustc_codegen_llvm-llvm.so`std::sys_common::backtrace::__rust_begin_short_backtrace::h5c4ce3df3c5c3c41+0x1e4(7fff7398ef5c0, 7fff7398ef508, 7fff7398ef300, 7fff7398ef420,
7fff7398ef2f8, 0)
0007fff7398eee31 librustc_codegen_llvm-llvm.so`std::panicking::try::do_call::hd0b71df38ab7dc19.llvm.4807897764851716782+0x18(7fff7398efb88, 7fff7398ef6e8, 356822d0b0, 7fff7396ee000, 1,
3567f8eaa0)
0007fff7398ef071 libstd-78276fe13ee991a5.so`__rust_maybe_catch_panic+0x14(7fff72fae6700, 7fff7398efb88, 7fff7398efb78, 7fff7398efb80, 7fff73d644000, 0)
0007fff7398ef131 librustc_codegen_llvm-llvm.so`_$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h0a7257b312ec8281+0x94(7fff7398efb88, 7fff72fd84000, 35681e2e80, 7fff7398ef9e0,
1930, 0)
0007fff7398ef511 libstd-78276fe13ee991a5.so`std::sys_common::thread::start_thread::he12a8bd23d4ffc25+0xa8(7fff73e404000, 7fff72faa0efc, 3567b95f40, 2, 7fff73e3b1a40, ff000000)
0007fff7398ef5e1 libstd-78276fe13ee991a5.so`std::sys::unix::thread::Thread::new::thread_start::h0204f2da04a5dd90+4(3567b95f40, 0, 1, 7fff73d4c1f28, 0, 0)
0007fff7398ef691 libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0)

[psumbera]

@glaubitz have you seen something like this on SPARC Linux?

[glaubitz]

@glaubitz have you seen something like this on SPARC Linux?

Not that I know of. 1.34.2 builds fine for us on Linux/sparc64 although the last upload failed to build because of a packaging problem.

[psumbera]

Both Rust 1.34.0 and 1.34.2 builds fine. But I'm not able to use them to build Rust 1.35.0.
Maybe I should try to use bundled llvm (not to use system one).

[glaubitz]

Okay, I guess the title is misleading then. I haven't tested 1.35 yet as this isn't part of Debian yet.

You can always see the latest build logs for rustc Linux/sparc64 on these pages:

https://buildd.debian.org/status/package.php?p=rustc&suite=sid
https://buildd.debian.org/status/package.php?p=rustc&suite=experimental

[glaubitz]

I have seen the issue now with the rust-autocfg package when building with Rust 1.34.2:

Compiling autocfg v0.1.4 (/<<PKGBUILDDIR>>)
     Running `rustc --crate-name autocfg src/lib.rs --color never --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=ddf4bb248d75a26c -C extra-filename=-ddf4bb248d75a26c --out-dir /<<PKGBUILDDIR>>/target/sparc64-unknown-linux-gnu/debug/deps --target sparc64-unknown-linux-gnu -C incremental=/<<PKGBUILDDIR>>/target/sparc64-unknown-linux-gnu/debug/incremental -L dependency=/<<PKGBUILDDIR>>/target/sparc64-unknown-linux-gnu/debug/deps -L dependency=/<<PKGBUILDDIR>>/target/debug/deps -C debuginfo=2 --cap-lints warn -C linker=sparc64-linux-gnu-gcc -C link-arg=-Wl,-z,relro --remap-path-prefix /<<PKGBUILDDIR>>=/usr/share/cargo/registry/autocfg-0.1.4`
Expected no forward declarations!
!180 = <temporary!> !{}
scope points into the type hierarchy
!184 = !DILocation(line: 1, scope: !21)
scope points into the type hierarchy
!186 = distinct !DILexicalBlock(scope: !21, file: !22, line: 357, column: 8)
scope points into the type hierarchy
!188 = !DILocation(line: 360, column: 5, scope: !21)
LLVM ERROR: Broken function found, compilation aborted!
error: Could not compile `autocfg`.

Full log at: https://buildd.debian.org/status/fetch.php?pkg=rust-autocfg&arch=sparc64&ver=0.1.4-1&stamp=1559286795&raw=0

CC @karcherm @jrtc27

[glaubitz]

Okay, I can confirm we are seeing the same issue on Linux/sparc64 when building Rust 1.35 with 1.34.2.

Wasn't LLVM switched from 7 to 8 for Rust 1.34? If yes, that would probably explain it as we had similar breakage on 32-bit powerpc back then when LLVM was upgraded.

I'm testing with the embedded LLVM copy first.

[psumbera]

My testing was with usage of Solaris bundled LLVM (which is still version 6.0.1).

[glaubitz]

Okay, it's not an issue with the system LLVM compiler. Using Rust's embedded LLVM shows the same problem. I'll try to bisect the problem now.

[glaubitz]

I have bi-sected this issue down to the commit which replaced LLVM (df0466d):

df0466d0bb807a7266cc8ac9931cd43b3e84b62e is the first bad commit
commit df0466d0bb807a7266cc8ac9931cd43b3e84b62e
Author: Josh Stone <jistone@redhat.com>
Date:   Wed Jan 16 09:59:03 2019 -0800

    Rebase to the llvm-project monorepo
    
    The new git submodule src/llvm-project is a monorepo replacing src/llvm
    and src/tools/{clang,lld,lldb}.  This also serves as a rebase for these
    projects to the new 8.x branch from trunk.
    
    The src/llvm-emscripten fork is unchanged for now.

:100644 100644 c4763612dbf3cc85d8682775b79d3297e6ec8c69 4e368c3ebafd8ba3b766ffd4d21d2339ec4f1852 M      .gitmodules
:100644 100644 6596c5a3d9aff0e5f450ba05c826cb34bcabf3b4 dc9abf84b8e5a4d3b6ab5472883f0997fa0454cc M      COPYRIGHT
:040000 040000 d28fae50cd16a7552c46d90c861785b8f9e24f63 1d444fc6305f36cd4e9a429b32387a5737ec7805 M      src

Since using the system LLVM doesn't usually cause problems, I don't suspect there is a bug in the LLVM bug but rather somewhere in the glue code between Rust and LLVM, i.e. Rustwrapper.cpp or something like that.

[jrtc27]

That makes sense; that commit swapped the bool IsDefinition for LLVMRustDISPFlags SPFlags in LLVMRustDIBuilderCreateFunction. RustWrapper.cpp looks sensible and doesn't cause issues elsewhere. If I had to guess, I would say that there's something wrong with the C ABI code for passing a uint32_t on the stack (since SPFlags is beyond the 6th argument), since the call site that was changed unconditionally sets SPFlagDefinition.

[glaubitz]

Okay, it looks like then this isn't something that can be trivially partially reverted then. I would have hoped, we could just use bool IsDefinition again on sparc64 as a workaround and see if that fixes the problem.

But I guess we will have to find out what's wrong with the C-ABI.