From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 6ACC8385703B for ; Tue, 8 Sep 2020 16:39:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6ACC8385703B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: mN8Bo9SDVpRc0C12XeIQ5n5f2JwRdmpIBhjkDQm1LKCEhkSrQ/6bjCssVSPHUZNCc3LD+61Txk WUQ3Em1yBLZuxqRqrbQh3znAQCTBTp1NWfH/eFi91D2X5w49zU+Z4X88pSTun90scJR3go159n 5Jz3XhQnDrlaLRRhtXxtkEDP6AilKFIMZHySDwm0J4iI27Kmkj9OfigKqhs6KQ7K5tiBBXd6dX KEZvxevLyaKn8/P6y2N1FdbtZnXSQnU//q2cQiTrXH3iZ097f80VMa14QhHXum87RbOpPcnA09 0iQ= X-IronPort-AV: E=Sophos;i="5.76,406,1592899200"; d="scan'208";a="54877563" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 08 Sep 2020 08:39:53 -0800 IronPort-SDR: xS9ZEiS+ltEGaECIiTcGofyiSbFxsXoBVYIIPD1/Ct4ageZ8fxrujlwUQshEv9R25YvMdcFjNB EfJ51JI8pudWj9x71zxQE++TZArUC0iF0aGk/t2baMw2I71n1bh29aOz5zAdLuNIYPjSMmaQZ1 c2UG0lvZWmJ2Bs9s/EKOgXmJT2uiYJq1Kzxq1ChBPjgb6rlkiCWa0fN56Yumko+u9sqrgvf2pI j+FCf6HAB/5Zqve2UIcHmi3uYffeODfF44BwJv8A6IzIaQSQQoQYuEMsAxh4RyqJA/pbSYc74C 0vw= Date: Tue, 8 Sep 2020 16:39:47 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: "H.J. Lu" CC: "Maciej W. Rozycki" , GNU C Library , Alistair Francis Subject: Re: Problem with RISC-V In-Reply-To: Message-ID: References: <20200907151057.196cdb1b@jawa> <0076afe3-0e43-a570-9358-9d00c88c0067@gmail.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3127.2 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_PASS, SPF_PASS, 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: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2020 16:39:55 -0000 On Tue, 8 Sep 2020, H.J. Lu via Libc-alpha wrote: > > Also, that particular binutils commit doesn't actually seem to fix things > > - there is still > > > > Extra PLT reference: libc.so: memset > > Is this related? > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220 I don't see why it would be. All the references to the PLT entry for memset are from libgcc soft-fp code for TFmode. This isn't a matter of visibility attributes not being acted on, libgcc.a can't use such visibility for memset because the same libgcc.a gets used outside of libc as well. I'm not sure it actually makes much sense for GCC to be generating memset calls for whatever memory clearing takes place inside soft-fp (soft-fp never calls memset explicitly from the C sources; libgcc.a for RV64 doesn't have any such memset references, for example; any clearing should be of small aligned pieces of memory that would make more sense to clear inline). So there may be an issue with questionable GCC code generation choices for RV32 that should be investigated. But when libgcc functions reference libc functions, those generally need to be listed in localplt.data for that glibc configuration (with a '?' to make the reference optional, see e.g. the sysdeps/unix/sysv/linux/powerpc/powerpc32/nofpu/localplt.data entries for abort and memset - in this case, the RV32 failures don't appear with GCC 9, which both means the '?' is required to avoid making the tests fail there, and suggest there may be a GCC regression). -- Joseph S. Myers joseph@codesourcery.com