From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [IPv6:2001:67c:2050::465:202]) by sourceware.org (Postfix) with ESMTPS id 36A6B3858039 for ; Thu, 7 Jan 2021 17:48:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 36A6B3858039 Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (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-202.mailbox.org (Postfix) with ESMTPS id 4DBYd32kbHzQlVW; Thu, 7 Jan 2021 18:48:55 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter03.heinlein-hosting.de (spamfilter03.heinlein-hosting.de [80.241.56.117]) (amavisd-new, port 10030) with ESMTP id CiiAuLBHzXGV; Thu, 7 Jan 2021 18:48:52 +0100 (CET) Date: Thu, 07 Jan 2021 18:48:47 +0100 From: Iain Buclaw Subject: Re: [PATCH] libphobos: Allow building libphobos using Solaris/x86 assembler To: Rainer Orth Cc: gcc-patches@gcc.gnu.org References: <20210105214349.3401864-1-ibuclaw@gdcproject.org> <1610035055.i2ssecfjha.astroid@galago.none> In-Reply-To: MIME-Version: 1.0 Message-Id: <1610041123.b2i26y1t01.astroid@galago.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MBO-SPAM-Probability: X-Rspamd-Score: -0.93 / 15.00 / 15.00 X-Rspamd-Queue-Id: 461C4183D X-Rspamd-UID: a4f5e1 X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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, 07 Jan 2021 17:48:59 -0000 Excerpts from Rainer Orth's message of January 7, 2021 5:17 pm: > Hi Iain, >=20 >>> The Solaris assemblers don't support UTF-8 identifiers. Unless gdc can >>> encode them in some way for toolchains like this (no idea if this is >>> worth the effort), it may be possible to guard the tests with the ucn >>> effective-target keyword. >>>=20 >>> Apart from that, it seems strange that the failing tests should only >>> show up as UNSUPPORTED. I'd have expected the compilation to FAIL, but >>> IIRC the gdc testsuite has to ignore all output, so the test for excess >>> errors which would usually catch this is disabled effectively. >> >> Indeed, the testsuite is far too verbose. Although many tests have a >> TEST_OUTPUT directive, converting them to a Dejagnu style is probably >> too much effort for the gain. >> >> Those tests can just be explicitly disabled, I'll look into that. >=20 > Great, thanks. >=20 >>> The last failure is different and due to how COMDAT group handling is >>> done with Solaris as: >>>=20 >>> +UNRESOLVED: gdc.test/runnable/test42.d compilation failed to produce >>> executable >>> +UNRESOLVED: gdc.test/runnable/test42.d -shared-libphobos compilation >>> failed to produce executable >>>=20 >>> which yields >>>=20 >>> Input string too long, limit 10240 >>>=20 >>> The offending input lines are (stripped for brevity) >>>=20 >>> .section .tdata._D6test42__T5Foo71VAyaa2623[...] >>> .group _D6test42__T5Foo71VAyaa2623_68656c6c6f616[...] >>>=20 >>> The first line is 10597 chars, the second even 15869. >>>=20 >> >> Is there a max symbol length macro available internally? Maybe could >=20 > Not that I'm aware of. I believe D tests are the first time ever that I > ran into this Solaris/x86 as limit. One might try to iteratively > determine the value at configure time if this is helpful. No idea if > other non-gas assemblers are even worse in that apartment. E.g. the > Solaris/SPARC one has a considerably higher limit... >=20 >> just compress symbols using MD5 if they exceed a certain length... >=20 > That's certainly an easy option. OTOH if this is unlikely to occur in > real-life code, once could just xfail the test on Solaris/x86 with as... >=20 Looking at the test which generates that symbol, it is very much a contrived example that deliberately exceeds the limit of another linker. However given the size and use of meta and templates in some production codebases out there, I can't say that symbols like it for sure won't appear in real-life code. Though it's going to be unlikely said code will be compiled for Solaris anyway. Iain.