New rust, new LLVM, new gcc?

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

Hi,

I am currently working on the pkgsrc-wip package rust183, which
brings rust 1.83.0.  Sadly, this is not smooth sailing; for some
reason cross-compilation for the various rust targets which
worked in rust 1.82.0 doesn't work anymore.  That's however not
the issue I'm here to discuss.

Since cross-compilation fails, I'm having to try to build rust
natively using the rust 1.82.0 bits for bootstrapping on the
various targets.  The particular target this concerns is the
powerpc target.

I am trying to build rust 1.83.0 on NetBSD/macppc 10.0.  This
means that the in-tree gcc is 10.5.0 (nb2 20230710).  Rust comes
with its own copy of LLVM "embedded in the distribution", which
may optionally be built.  I am trying to build with that embedded
LLVM.  The embedded LLVM is for rust 1.83.0 version 19.1.1.  And
this is where the trouble starts.

Trying to build this with the in-tree gcc results in

   /usr/pkgsrc/wip/rust183/work/rustc-1.83.0-src/src/llvm-project/llvm/include/llvm/MC/MCContext.h:407:25:   required from here
   /usr/include/g++/bits/std_function.h:306:5: internal compiler error: in finish_member_declaration, at cp/semantics.c:3235
     306 |     {
	 |     ^
   no stack trace because unwind library not available
   Please submit a full bug report,
   with preprocessed source if appropriate.
   See <http://www.NetBSD.org/support/send-pr.html> for instructions.

So...  I tried via GCC_REQD+= 12 to force the use of GCC version
12.  I had gcc12 installed already (version 12.3.0), but apparently not
gcc12-libs, and that forces an attempt to re-build gcc12 version
12.4.0.  And, what do you know, that build fails with

   In file included from ../../gcc-12.4.0/gcc/diagnostic.h:24,
		    from ../../gcc-12.4.0/gcc/lto-streamer.h:28,
		    from ../../gcc-12.4.0/gcc/symtab-clones.cc:34:
   ../../gcc-12.4.0/gcc/pretty-print.h:421:53: internal compiler error: Segmentation fault
     421 | extern const char *identifier_to_locale (const char *);
	 |                                                     ^
   Please submit a full bug report, with preprocessed source (by using -freport-bug).
   See <https://gcc.gnu.org/bugs/> for instructions.

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
   0x3a95b73 sched_extend_ready_list(int)
	   ../../gcc-14.2.0/gcc/haifa-sched.cc:7803
   0x2959347 schedule_region
	   ../../gcc-14.2.0/gcc/sched-rgn.cc:3146
   0x295a763 schedule_insns()
	   ../../gcc-14.2.0/gcc/sched-rgn.cc:3525
   0x295b377 rest_of_handle_sched2
	   ../../gcc-14.2.0/gcc/sched-rgn.cc:3749
   0x295b71f execute
	   ../../gcc-14.2.0/gcc/sched-rgn.cc:3888
   Please submit a full bug report, with preprocessed source (by using -freport-bug).
   Please include the complete backtrace with any bug report.
   See <https://gcc.gnu.org/bugs/> for instructions.

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.

Retries of the build does not appear to pick up exactly at this
step -- rebuilds does *lots* of other work, and my latest attempt
is still ongoing.

I see that our pkgsrc-wip has llvm 19.1.4.  I have not yet tried
to build that on NetBSD/macppc 10.0, but will probably make an
attempt at that as well, but given the above I am not very
hopeful.

Any hints for how to progress this?

Regards,

- Havard