From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id E370E3857C7D; Sun, 15 Nov 2020 13:03:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E370E3857C7D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=none smtp.mailfrom=hubicka@kam.mff.cuni.cz Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id B1B5D28276F; Sun, 15 Nov 2020 14:03:51 +0100 (CET) Date: Sun, 15 Nov 2020 14:03:51 +0100 From: Jan Hubicka To: Rainer Orth Cc: gcc@gcc.gnu.org, Andreas Schwab , Richard Biener , gcc-patches@gcc.gnu.org Subject: Re: Detect EAF flags in ipa-modref Message-ID: <20201115130351.GD45304@kam.mff.cuni.cz> References: <20201109131632.GA12394@kam.mff.cuni.cz> <20201109231418.GF65107@kam.mff.cuni.cz> <20201110125418.GB53229@kam.mff.cuni.cz> <20201110143143.GA91644@kam.mff.cuni.cz> <87361ahph7.fsf@linux-m68k.org> <20201115111254.GB45304@kam.mff.cuni.cz> <20201115123307.GC45304@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 13:03:57 -0000 > Hi Jan, > > >> I'm seeing the same on both i386-pc-solaris2.11 and > >> sparc-sun-solaris2.11, so I don't think there are special configure > >> flags involved. > > > > When I configure with ../configure --enable-languages=go my build > > eventually finishes fine on curren trunk: > [...] > > On Debian SLES machines. Having preprocessed go-diagnostics.cc and > > .uninit1 dump would probably help. > > apart from go/diagnostics.cc, I see the warning several times in > libstdc++, but only for the 32-bit multilib. > > Try building either for i686-pc-linux-gnu or a bi-arch > x86_64-pc-linux-gnu build. My build is bi-arch. I will check libstdc++ warnings, but we had some such warnings previously there too (plus we have tons of uninitialized warnings with LTO bootstrap). This really may depend on glibc headers and how string functions get expanded. This is why I think having preprocessed diagnotics.cc should help. Honza > > Rainer > > -- > ----------------------------------------------------------------------------- > Rainer Orth, Center for Biotechnology, Bielefeld University