Re: New rust, new LLVM, new gcc?

[Havard Eidnes <he%NetBSD.org@localhost>]

Hi,

an update on this, and it's not good news, I'm afraid:

> OK.  So what alternatives exist?  Well, isn't there gcc14 in
> pkgsrc?  So I tried with GCC_REQD+= 14 instead.  But...  My
> initial attempt failed with
>
>    during RTL pass: sched2
>    ../../gcc-14.2.0/libiberty/simple-object-mach-o.c: In function 'simple_object_mach_o_find_sections':
>    ../../gcc-14.2.0/libiberty/simple-object-mach-o.c:805:1: internal compiler error: in xrecalloc, at haifa-sched.cc:8082
>      805 | }
> 	 | ^
>    0x3a96a27 xrecalloc(void*, unsigned int, unsigned int, unsigned int)
> 	   ../../gcc-14.2.0/gcc/haifa-sched.cc:8082
...
> So ... exhausting virtual address space, or at least resource
> limits?  So I tried adding
> 
> UNLIMIT_RESOURCES+=     virtualsize
>
> since "datasize" was already unlimited, but that didn't get me
> a successful build:
> 
>    during RTL pass: sched1
>    gimple-match-8.cc: In function 'bool gimple_simplify_COND_EXPR(gimple_match_op*, gimple**, tree_node* (*)(tree), code_helper, tree, tree, tree, tree)':
>    gimple-match-8.cc:52002:1: internal compiler error: in dep_list_size, at haifa-sched.cc:1586
>    52002 | }
> 	 | ^
>    Please submit a full bug report, with preprocessed source (by using -freport-bug).
>    See <https://gcc.gnu.org/bugs/> for instructions.

This build required multiple restarts, but I now have
gcc14-14.2.0 installed.  The other errors I saw were:
	     
   gimple-match-8.cc: In function 'bool gimple_simplify_COND_EXPR(gimple_match_op*, gimple**, tree_node* (*)(tree), code_helper, tree, tree, tree, tree)':
   gimple-match-8.cc:52002:1: internal compiler error: in dep_list_size, at haifa-sched.cc:1586
   52002 | }
	 | ^
   Please submit a full bug report, with preprocessed source (by using -freport-bug).

and

   /usr/pkgsrc/lang/gcc14/work/build/powerpc--netbsd/soft-float/libstdc++-v3/includ   e/bits/locale_facets.tcc:374:7: internal compiler error: in execute_one_pass, at passes.cc:2587
     374 |       num_get<_CharT, _InIter>::
	 |       ^~~~~~~~~~~~~~~~~~~~~~~~

I am uncertain what caused the build to eventually succeed on the
re-tries, but the prospects of this succeeding in a bulk build
are slim.  This is, of course, with ASLR turned on, I have yet to
re-try the gcc14 build with ASLR turned off.

That said...  Using gcc14 for the rust compiler build did not fix
the issue that the build of the internal LLVM build fails with

   [ 61%] Building CXX object lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/DataFlowSanitizer.cpp.o
   during RTL pass: cprop
   /usr/pkgsrc/wip/rust183/work/rustc-1.83.0-src/src/llvm-project/llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp: In member function 'void {anonymous}::
   DFSanVisitor::visitLoadInst(llvm::LoadInst&)':
   /usr/pkgsrc/wip/rust183/work/rustc-1.83.0-src/src/llvm-project/llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp:2457:1: internal compiler error: Segmentation fault
    2457 | }
	 | ^
   0x306f64b internal_error(char const*, ...)
	   ???:0
   Please submit a full bug report, with preprocessed source (by using -freport-bug).

So...  I see two possible paths forward:

1) Get LLVM 19.1.4 from pkgsrc-wip built.  It is slightly newer
   than the LLVM bundled in rust 1.83.0.  However, given the
   experiences reported above I am not particularly hopeful that
   this will succeed.

   However, this should be a more easily reproducible problem
   (but still requires a powerpc system).

2) Get LLVM 18.x built & installed, whereever I can find it.
   This has probably a better prospect of succeeding, and rust is
   still compatible with an external LLVM >= 18.  But I am
   guessing that it's only a question of time before rust insists
   on an external LLVM >= 19, so this is going to at best be just
   a temporary workaround.

So...  Any suggestions, hints or assistance?

Best regards,

- Håvard