Excerpts from Rainer Orth's message of September 7, 2022 2:40 pm: > Hi Iain, > >>> Yes, this is data related. The DSO registry picks up nothing in the >>> miscompiled stage2 compiler, leaving all data uninitialized. The stage1 >>> compiler works, and runs all module constructors ahead of compilation. >>> >> >> Ohh, backtrack on that, analysis is correct, but it is a compiler regression. >> >> The TARGET_D_MINFO_SECTION macros are in elfos.h, which of course no >> longer get pulled in to sol2-d.cc after I removed the tm.h include. >> >> Re-adding these two ought to fix the bootstrap for you. >> >> #include "tm.h" >> #include "memmodel.h" > > it does indeed: with that patch, i386-pc-solaris2.11 and > sparc-sun-solaris2.11 bootstraps completed successfully and test results > are back to normal. > > Thanks a lot. >
I'm just running through various target configurations with memmodel.h removed, I know it was used to be required for one of the targets (probably SPARC), though that may have been because of the previously included tm_p.h header. Will have a think about a likely follow-up though. Firstly fixing the outstanding issues with https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598078.html Secondly possibly using a different method to coax out the object format to the D target hooks, or front-end. Iain.
