Hi Iain,
> 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
almost certainly. It's in my initial patch to fix D compilation on
Solaris:
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01890.html
> 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
I belive I had it working on Solaris, at least...
> Secondly possibly using a different method to coax out the object format
> to the D target hooks, or front-end.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
