From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.esperi.org.uk (icebox.esperi.org.uk [81.187.191.129]) by sourceware.org (Postfix) with ESMTPS id B400C3858C52 for ; Tue, 10 Jan 2023 12:43:35 +0000 (GMT) Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=oracle.com Received: from loom (nix@sidle.srvr.nix [192.168.14.8]) by mail.esperi.org.uk (8.16.1/8.16.1) with ESMTPS id 30AChWvR026789 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 10 Jan 2023 12:43:32 GMT From: Nick Alcock To: binutils@sourceware.org Cc: Nick Alcock , Nick Clifton , Matthias Klose Subject: Re: The 2.40 branch has been created References: <87mt739186.fsf@redhat.com> <35a47bed-36af-6f8a-55a6-9cef247f9840@canonical.com> <87wn62sdel.fsf@esperi.org.uk> Emacs: featuring the world's first municipal garbage collector! Date: Tue, 10 Jan 2023 12:43:32 +0000 In-Reply-To: <87wn62sdel.fsf@esperi.org.uk> (Nick Alcock via Binutils's message of "Wed, 04 Jan 2023 12:16:34 +0000") Message-ID: <87r0w2r24r.fsf@esperi.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DCC-wuwien-Metrics: loom 1290; Body=4 Fuz1=4 Fuz2=4 X-Spam-Status: No, score=-12.8 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KHOP_HELO_FCRDNS,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 4 Jan 2023, Nick Alcock via Binutils stated: > On 2 Jan 2023, Matthias Klose via Binutils stated: >> On 31.12.22 14:00, Nick Clifton via Binutils wrote: >> i686-linux-gnu: >> >> Running /<>/ld/testsuite/ld-ctf/ctf.exp ... >> FAIL: Diagnostics - No parent dictionary > > This seems to be a cross-platform issue, which is strange because I've > never seen this test (ld/testsuite/ld-ctf/diag-parname.d) fail: for me, > it doesn't fail now, even with current 2.40 branch. This stuff is not > compiler-dependent, so I'd expect to see identical failures for > everybody. I have a fix for this one under test (see the last patch in the series I just sent). It's a type confusion that involves treating one struct as if it were a much bigger one (and then writing to it, ugh), so it comes down to accessing uninitialized memory. Hence the irreproducibility. I'll backport the fix to all affected branches (2.36+). This is now bug 29983.