From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [IPv6:2001:67c:2050:0:465::102]) by sourceware.org (Postfix) with ESMTPS id 08968385354A for ; Tue, 6 Sep 2022 17:02:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 08968385354A Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=gdcproject.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gdcproject.org Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4MMWsQ24MVz9sWs; Tue, 6 Sep 2022 19:02:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gdcproject.org; s=MBO0001; t=1662483754; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3MQM21Ksc7wnvva+0WJsrahhOvpMRfnrgjh5tsE/aIg=; b=STzQfWcTlqrmck9ZAxUMq6klhQBHjIUa9uvD70IdTE9NQ6PnQuz55MZRYgcd6oOMDEfwre aS1JcltCKHOm2EIERv+6n3iccNpF38dxM28aySSoQBDY6xAVLErFkF1P+2/plCx2zFZi0K iv3MQozYg19VR7+VHQ9zZrx7TC8HgorD/J9Iao77i4935USvCKr4F+XVoTqcfpocpwVWBO VzfhnxdsdGPywgPOY7ZxB27uOtO7rFv/lKHNydV/sarphTaZr+w3xOQ9GVr93OS1bq3K/X yvKrmXuoHcjb22/JyJ0PAK/D1CCqEPVMcZ5oYPWxP5bkPwahtQo+UXxTseOsJg== Date: Tue, 06 Sep 2022 19:02:24 +0200 From: Iain Buclaw Subject: Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659) To: Rainer Orth Cc: Iain Buclaw via Gcc-patches , Joseph Myers , Richard Biener References: <20220816211627.209433-1-ibuclaw@gdcproject.org> <1661946124.o8swlumpp1.astroid@pulse.none> <1661972814.ht3t1le0d2.astroid@pulse.none> <1662134159.ozionptp0l.astroid@pulse.none> <1662461291.9qhrd4im4r.astroid@pulse.none> <1662473974.qwin0prel4.astroid@pulse.none> In-Reply-To: MIME-Version: 1.0 Message-Id: <1662483174.uvzwp07gdf.astroid@pulse.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4MMWsQ24MVz9sWs X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Excerpts from Rainer Orth's message of September 6, 2022 4:25 pm: > Hi Iain, >=20 >>> there is indeed ;-) The previous d21 emits >>>=20 >>> binary ./266566/gcc/d21 >>> version v2.100.1 >>>=20 >>> predefs GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions >>> GNU_StackGrowsDown GNU_InlineAsm assert D_PreConditions D_PostCondition= s >>> D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo all X86 D_HardFloat >>> Posix Solaris CppRuntime_Gcc >>>=20 >>> while the patched one gives >>>=20 >>> core.exception.ArrayIndexError@/var/gcc/reghunt/master/gcc/d/dmd/root/s= tringtable.d(291): >>> index [3530971477] is out of bounds for array of length 0 >>> gcc.deh(505): uncaught exception >>> : internal compiler error: Abort >>> 0x96d5b6c crash_signal >>> /var/gcc/reghunt/master/gcc/toplev.cc:314 >>>=20 >> >> Excellent, and the stage1 compiler? >=20 > binary ./prev-gcc/d21 > version v2.100.1 >=20 > predefs GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions GNU_StackGrow= sDown GNU_InlineAsm assert D_PreConditions D_PostConditions D_Invariants D_= ModuleInfo D_Exceptions D_TypeInfo all X86 D_HardFloat Posix Solaris CppRun= time_Gcc >=20 > So identical to the pre-patch one. >=20 > Just in case, here's the stacktrace of the crashing d21, filtered > through c++filt -s dlang: >=20 > 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=3D..., = line=3D) at /var/gcc/reghunt/master/libphobos/libdruntime/gc= c/deh.d:414 > #5 0x0a8e7ab3 in _d_throw (object=3D) at /var/gcc/reghunt= /master/libphobos/libdruntime/gcc/deh.d:505 > #6 0x0a8edf02 in onArrayIndexError (index=3D, length=3D, file=3D..., line=3D) at /var/gcc/reghunt/mast= er/libphobos/libdruntime/core/exception.d:650 > #7 0x0a8edf3d in _d_arraybounds_indexp (file=3D, line=3D<= optimized out>, index=3D, length=3D) at /var/= gcc/reghunt/master/libphobos/libdruntime/core/exception.d:848 > #8 0x08ffc17a in dmd.root.stringtable.StringTable!(dmd.identifier.Identi= fier).StringTable.findSlot(uint, scope const(char)[]) const (this=3D..., ha= sh=3D, str=3D...) 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 &=3D (table.length - 1)` (it uses quadratic probing to searc= h 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.