From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id CA4AD3858C2F for ; Wed, 31 Aug 2022 23:09:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CA4AD3858C2F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 27VN87Rs018715; Wed, 31 Aug 2022 18:08:07 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 27VN87PT018714; Wed, 31 Aug 2022 18:08:07 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 31 Aug 2022 18:08:07 -0500 From: Segher Boessenkool To: Peter Bergner Cc: "Kewen.Lin" , GCC Patches Subject: Re: [PATCH] rs6000: Don't ICE when we disassemble an MMA variable [PR101322] Message-ID: <20220831230807.GY25951@gate.crashing.org> References: <9c6a44db-1239-466a-2990-42207b7eb264@linux.ibm.com> <6cf4ceb2-9deb-93b4-bd94-ab08c08eb330@linux.ibm.com> <20220831205126.GU25951@gate.crashing.org> <67da6fae-184d-4414-cb04-53e295abc477@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67da6fae-184d-4414-cb04-53e295abc477@linux.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Aug 31, 2022 at 05:01:04PM -0500, Peter Bergner wrote: > The problem goes away if I use use -O1 or above, I drop -flto or I use > the code I originally posted without the ptr_vector_*_type > > The assert in gimple_canonical_types_compatible_p() we're hitting is: > 13673 default: > 13674 /* Consider all types with language specific trees in them mutually > 13675 compatible. This is executed only from verify_type and false > 13676 positives can be tolerated. */ > 13677 gcc_assert (!in_lto_p); > 13678 return true; > > I have no idea why ptr_vector_*_type would behave differently here than > build_pointer_type (vector_*_type_node). Using the build_pointer_type() > fixed it for me, so that's why I went with it. :-) Maybe this is a bug > in lto??? It looks like left-over debugging code. Or this truly should never happen in LTO? Segher