From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.CeBiTec.Uni-Bielefeld.DE (smtp.CeBiTec.Uni-Bielefeld.DE [129.70.160.84]) by sourceware.org (Postfix) with ESMTPS id 726A2385803B for ; Thu, 7 Jan 2021 16:17:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 726A2385803B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=CeBiTec.Uni-Bielefeld.DE Authentication-Results: sourceware.org; spf=none smtp.mailfrom=ro@cebitec.uni-bielefeld.de Received: from localhost (localhost [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 3DB3E8C5D; Thu, 7 Jan 2021 17:17:48 +0100 (CET) X-Virus-Scanned: amavisd-new at CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (smtp.cebitec.uni-bielefeld.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DI2an_V5xbOE; Thu, 7 Jan 2021 17:17:47 +0100 (CET) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p5085535c.dip0.t-ipconnect.de [80.133.83.92]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id B583B11B16; Thu, 7 Jan 2021 17:17:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=CeBiTec.Uni-Bielefeld.DE; s=20200306; t=1610036267; bh=QX1MiN7iPi85akw3/itJrGzJNyFAt4bu6TlR1sdSaX4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=HJatzeDgXSz083zL/RKPLxmm3A0+7luDInDJhodGGCcScDoJviPMMO8qOYzzYMKBF 68hP/lvIXPK/kkemMrzgljCairZvb9D5SSCFp4jqXCZsaB3ElMww0j+VP04YeSXtLF wFx+2Fa+EV/n+VPA4FHuRhds8yhOTcRLX1XsZ6T+rMtTzgXzGe8Ugg/DUU8uCZ471v LkGH9Pru31Bvt5EVdsEQ7qkiqdqoq2qTEVV0CgSt9tSyfJcyhtCrMygr7wPufi3M8G IUmtu1E8LnIQGmVcW5pZlK+MuywLgQH4Oz8qTuSP0uBGFKqtvsUQgZKTNrcv97Hrj7 W6h21jYg1ouVg== From: Rainer Orth To: Iain Buclaw Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] libphobos: Allow building libphobos using Solaris/x86 assembler References: <20210105214349.3401864-1-ibuclaw@gdcproject.org> <1610035055.i2ssecfjha.astroid@galago.none> Date: Thu, 07 Jan 2021 17:17:46 +0100 In-Reply-To: <1610035055.i2ssecfjha.astroid@galago.none> (Iain Buclaw's message of "Thu, 07 Jan 2021 17:11:04 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.90 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3789.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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 16:17:50 -0000 Hi Iain, >> 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. >> >> 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. Great, thanks. >> The last failure is different and due to how COMDAT group handling is >> done with Solaris as: >> >> +UNRESOLVED: gdc.test/runnable/test42.d compilation failed to produce >> executable >> +UNRESOLVED: gdc.test/runnable/test42.d -shared-libphobos compilation >> failed to produce executable >> >> which yields >> >> Input string too long, limit 10240 >> >> The offending input lines are (stripped for brevity) >> >> .section .tdata._D6test42__T5Foo71VAyaa2623[...] >> .group _D6test42__T5Foo71VAyaa2623_68656c6c6f616[...] >> >> The first line is 10597 chars, the second even 15869. >> > > Is there a max symbol length macro available internally? Maybe could 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... > just compress symbols using MD5 if they exceed a certain length... 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... Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University