From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.wavenetuk.net (unknown [195.26.37.10]) by sourceware.org (Postfix) with ESMTP id C28923857023 for ; Thu, 26 Nov 2020 13:17:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C28923857023 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=iain@sandoe.co.uk Received: from [192.168.1.212] (host81-138-1-83.in-addr.btopenworld.com [81.138.1.83]) by smtp2.wavenetuk.net (Postfix) with ESMTPA id BB72A600112; Thu, 26 Nov 2020 13:17:10 +0000 (GMT) Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] configury : Fix LEB128 support for non-GNU assemblers. From: Iain Sandoe In-Reply-To: Date: Thu, 26 Nov 2020 13:17:07 +0000 Cc: GCC Patches Content-Transfer-Encoding: 8bit Message-Id: References: <0099CE62-D849-40BA-BCBD-1AD3882AA9AD@sandoe.co.uk> To: Rainer Orth X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00, KAM_COUK, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KHOP_HELO_FCRDNS, MAY_BE_FORGED, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 13:17:13 -0000 Hi Rainer, Rainer Orth wrote: >>> The ports I know of that can benefit from a change here are: >> [...] >>> Solaris (bootstrapped and tests running on GCC211, but maybe Rainer would >>> want wider checks). >> >> I've just manually tried the augmented test on Solaris 10-11.4, SPARC >> and x86. While the Solaris/SPARC assembler handles it just fine, the >> x86 one chokes in a known way: >> >> Assembler: >> "/homes/ro/leb128.s", line 2 : Syntax error >> Near line: " .uleb128 L2 - L1" >> >>> I guess we could exclude specific ports that don’t want to use leb128 >>> with >>> a target elif in the configuration. >> >> I'll include the patch in tonight's Solaris bootstraps for good measure, >> but it seems fine to me as is. > > unfortunately, Solaris/SPARC results are miserable: > > * About 1600 Go tests FAIL, spread across go.*, libgo, and gotools, all > in the same way, it seems: > > +FAIL: go.go-torture/execute/array-1.go execution, -O0 > > fatal error: DWARF underflow in .debug_line at 3266879 > > goroutine 1 [running, locked to thread]: > fatal error: DWARF underflow in .debug_line at 3266879 > panic during panic > > goroutine 1 [running, locked to thread]: > fatal error: DWARF underflow in .debug_line at 3266879 > stack trace unavailable go is stil not implemented for Darwin, so I have no comparison there. > * On top of that, I get about 80 libstdc++ failures, again all of the > same kind: > > +FAIL: libstdc++-prettyprinters/80276.cc whatis p4 > > type = > std::unique_ptr std::char_traits, std::allocator >>[]>>[99]> > got: type = > std::unique_ptr std::char_traits, std::allocator >>[]>>[99]> > > which is confusing because the the found and expected types are > identical. so some breakage in RTTI .. I suppose. > All this happens for both 32 and 64-bit tests. > > To ascertain that this is really the leb128 patch, I've reverted it in > my tree and reran the bootstrap: all those failures are gone. > > So without further investigation, we cannot use the leb128 directives > with Solaris/SPARC as. I think Andrew was running GCN (not sure of the results there) - but, I suppose that the simplest modification is to do elif … target is darwin and make it so that other (non-GNU-as) platforms have to opt in. I’ll make a version that does this and test it locally. thanks for checking, Iain