From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [IPv6:2001:67c:2050:0:465::201]) by sourceware.org (Postfix) with ESMTPS id 7E47C3858D28 for ; Wed, 7 Sep 2022 07:34:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7E47C3858D28 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 smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (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-201.mailbox.org (Postfix) with ESMTPS id 4MMvCm2VsBz9sVm; Wed, 7 Sep 2022 09:34:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gdcproject.org; s=MBO0001; t=1662536084; 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=vTZebvdx+N0rtEUnTm0fp7NWP6SwRrvzs0BfIdlt0qk=; b=qb3dMki1Y8AZBvi2ADGje2rzzDWZOAe691kR6ramJ6Z4kzDqXLVc6VB76gE9fyugsSOz6t JyH86MklEV5/mAbhSbw2ISDRpRXKijEQDvCDUxBG/pkwfKQ+2I1N03xn+w+TFf3mHsc36+ w9Px/Xs8kr/tJ3SlmdfsxJQ6Yc6DmUdipuwSymMffA1pJe3ql2PnPwatlU8G0t2yEF3pay XYVIB9NAuRBedOj3QGq19w4Q9VMNH9lClb07vOZqpvFeanWFia4ZUzoB+BixOmCNNxZN7E ULZETYRuK644TF5C9iOwrKnMOGO8Gewvdo0elImO+2qa9Ze3zXH45PEI3sO9ug== Date: Wed, 07 Sep 2022 09:34:40 +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> <1662483174.uvzwp07gdf.astroid@pulse.none> <1662499940.tthemu7pnd.astroid@pulse.none> In-Reply-To: <1662499940.tthemu7pnd.astroid@pulse.none> MIME-Version: 1.0 Message-Id: <1662535517.7ejd7oei0d.astroid@pulse.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4MMvCm2VsBz9sVm X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,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 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, >>>=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_PostConditi= ons >>>>> 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= /stringtable.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_StackGr= owsDown GNU_InlineAsm assert D_PreConditions D_PostConditions D_Invariants = D_ModuleInfo D_Exceptions D_TypeInfo all X86 D_HardFloat Posix Solaris CppR= untime_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/= gcc/deh.d:414 >>> #5 0x0a8e7ab3 in _d_throw (object=3D) at /var/gcc/reghu= nt/master/libphobos/libdruntime/gcc/deh.d:505 >>> #6 0x0a8edf02 in onArrayIndexError (index=3D, length=3D= , file=3D..., line=3D) at /var/gcc/reghunt/ma= ster/libphobos/libdruntime/core/exception.d:650 >>> #7 0x0a8edf3d in _d_arraybounds_indexp (file=3D, line= =3D, index=3D, length=3D) at /= var/gcc/reghunt/master/libphobos/libdruntime/core/exception.d:848 >>> #8 0x08ffc17a in dmd.root.stringtable.StringTable!(dmd.identifier.Iden= tifier).StringTable.findSlot(uint, scope const(char)[]) const (this=3D..., = hash=3D, str=3D...) at /var/gcc/reghunt/master/gcc/d/dmd/roo= t/stringtable.d:291 >>=20 >> 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 se= arch >> the hash table). >>=20 >> 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. >>=20 >=20 > 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. >=20 Ohh, backtrack on that, analysis is correct, but it is a compiler regressio= n. 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