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. Iain.
