Excerpts from Iain Buclaw's message of September 6, 2022 11:41 pm:
> Excerpts from Iain Buclaw's message of September 6, 2022 7:02 pm:
>> Excerpts from Rainer Orth's message of September 6, 2022 4:25 pm:
>>> Hi Iain,
>>>
>>>>> there is indeed ;-) The previous d21 emits
>>>>>
>>>>> binary ./266566/gcc/d21
>>>>> version v2.100.1
>>>>>
>>>>> predefs GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions
>>>>> GNU_StackGrowsDown GNU_InlineAsm assert D_PreConditions D_PostConditions
>>>>> D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo all X86 D_HardFloat
>>>>> Posix Solaris CppRuntime_Gcc
>>>>>
>>>>> while the patched one gives
>>>>>
>>>>> core.exception.ArrayIndexError@/var/gcc/reghunt/master/gcc/d/dmd/root/stringtable.d(291):
>>>>> index [3530971477] is out of bounds for array of length 0
>>>>> gcc.deh(505): uncaught exception
>>>>> <built-in>: internal compiler error: Abort
>>>>> 0x96d5b6c crash_signal
>>>>> /var/gcc/reghunt/master/gcc/toplev.cc:314
>>>>>
>>>>
>>>> Excellent, and the stage1 compiler?
>>>
>>> binary ./prev-gcc/d21
>>> version v2.100.1
>>>
>>> predefs GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions
>>> GNU_StackGrowsDown GNU_InlineAsm assert D_PreConditions D_PostConditions
>>> D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo all X86 D_HardFloat Posix
>>> Solaris CppRuntime_Gcc
>>>
>>> So identical to the pre-patch one.
>>>
>>> Just in case, here's the stacktrace of the crashing d21, filtered
>>> through c++filt -s dlang:
>>>
>>> Thread 2 received signal SIGABRT, Aborted.
>>> [Switching to Thread 1 (LWP 1)]
>>> 0xfe1be2e5 in __lwp_sigqueue () from /lib/libc.so.1
>>> (gdb) bt
>>> #0 0xfe1be2e5 in __lwp_sigqueue () from /lib/libc.so.1
>>> #1 0xfe1b62cf in thr_kill () from /lib/libc.so.1
>>> #2 0xfe0ed662 in raise () from /lib/libc.so.1
>>> #3 0xfe0bae74 in abort () from /lib/libc.so.1
>>> #4 0x0a8e786d in gcc.deh.terminate(immutable(char)[], uint) (msg=...,
>>> line=<optimized out>) at
>>> /var/gcc/reghunt/master/libphobos/libdruntime/gcc/deh.d:414
>>> #5 0x0a8e7ab3 in _d_throw (object=<optimized out>) at
>>> /var/gcc/reghunt/master/libphobos/libdruntime/gcc/deh.d:505
>>> #6 0x0a8edf02 in onArrayIndexError (index=<optimized out>,
>>> length=<optimized out>, file=..., line=<optimized out>) at
>>> /var/gcc/reghunt/master/libphobos/libdruntime/core/exception.d:650
>>> #7 0x0a8edf3d in _d_arraybounds_indexp (file=<optimized out>,
>>> line=<optimized out>, index=<optimized out>, length=<optimized out>) at
>>> /var/gcc/reghunt/master/libphobos/libdruntime/core/exception.d:848
>>> #8 0x08ffc17a in
>>> dmd.root.stringtable.StringTable!(dmd.identifier.Identifier).StringTable.findSlot(uint,
>>> scope const(char)[]) const (this=..., hash=<optimized out>, str=...) at
>>> /var/gcc/reghunt/master/gcc/d/dmd/root/stringtable.d:291
>>
>> Yeah, I don't see how that could trigger, as the value of `i` is always
>> adjusted to `i &= (table.length - 1)` (it uses quadratic probing to search
>> the hash table).
>>
>> The logic of the compiler doesn't appear to have changed, but the data
>> layout may have, so I'm suspecting an issue that was always there has
>> now surfaced to the fore.
>>
>
> 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"
Iain
