From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39146 invoked by alias); 19 Sep 2016 10:55:50 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 39071 invoked by uid 89); 19 Sep 2016 10:55:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy= X-Spam-User: qpsmtpd, 2 recipients X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Sep 2016 10:55:39 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1blwEa-0001sr-2b from Thomas_Schwinge@mentor.com ; Mon, 19 Sep 2016 03:55:36 -0700 Received: from hertz.schwinge.homeip.net (137.202.0.87) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Sep 2016 11:55:32 +0100 From: Thomas Schwinge To: Richard Biener , Joseph Myers CC: GCC Patches , GCC Development , Jakub Jelinek , Bernd Schmidt Subject: Re: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6])) In-Reply-To: References: <20160817154244.GA39270@arm.com> <87h99s53ls.fsf@kepler.schwinge.homeip.net> <87d1kefwgt.fsf@hertz.schwinge.homeip.net> <87twdgb9zi.fsf@hertz.schwinge.homeip.net> <87poo4as2j.fsf@hertz.schwinge.homeip.net> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 19 Sep 2016 11:04:00 -0000 Message-ID: <87eg4gb1lr.fsf@hertz.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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-SW-Source: 2016-09/txt/msg01157.txt.bz2 Hi! On Mon, 19 Sep 2016 10:12:48 +0200, Richard Biener wrote: > On Fri, Sep 16, 2016 at 7:07 PM, Joseph Myers w= rote: > > On Fri, 16 Sep 2016, Thomas Schwinge wrote: > > > >> That's what I was afraid of: for example, I can't tell if it holds for > >> all GCC configurations (back ends), that complex types' component types > >> will always match one of the already existing global trees? (I can > > > > Well, a component type could certainly match a target-specific type > > instead (e.g. __ibm128 on powerpc, which if it's not long double won't = be > > any of the other types either). That's a type registered with > > lang_hooks.types.register_builtin_type, not one of the global trees. > > (You can't write _Complex __ibm128, but can get such a type with _Compl= ex > > float __attribute__ ((__mode__ (__IC__))). Or similarly, with ARM __fp= 16, > > the complex type _Complex float __attribute__ ((__mode__ (__HC__))).) >=20 > The question is whether such a complex type could be a global tree which I > don't think it could. Specifically, my question was whether for every complex type that is part of the global trees, it holds that the complex type's component type also is part of the global trees? Gr=C3=BC=C3=9Fe Thomas