This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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]))
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Biener <richard dot guenther at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>, Bernd Schmidt <bschmidt at redhat dot com>
- Date: Fri, 16 Sep 2016 17:07:25 +0000
- 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]))
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.2.20.1606211202040.4526@digraph.polyomino.org.uk> <alpine.DEB.2.20.1606231418120.21240@digraph.polyomino.org.uk> <alpine.DEB.2.20.1606271720270.7438@digraph.polyomino.org.uk> <alpine.DEB.2.20.1607191347340.9265@digraph.polyomino.org.uk> <alpine.DEB.2.20.1607222158330.22448@digraph.polyomino.org.uk> <20160817154244.GA39270@arm.com> <alpine.DEB.2.20.1608171641000.7156@digraph.polyomino.org.uk> <alpine.DEB.2.20.1608172015080.27199@digraph.polyomino.org.uk> <CAFiYyc3xqcqJ1rK2X0rC+wwpx3akHbULVG1G47PRmtk4wTk=7A@mail.gmail.com> <alpine.DEB.2.20.1608191101110.30687@digraph.polyomino.org.uk> <87h99s53ls.fsf@kepler.schwinge.homeip.net> <CAFiYyc3X46eeodD3sTCXDsx1zbfmF_He2AL6CC6BuE6urh4SGw@mail.gmail.com> <87d1kefwgt.fsf@hertz.schwinge.homeip.net> <87twdgb9zi.fsf@hertz.schwinge.homeip.net> <CAFiYyc22Gg_=kdjuT8jKLcOyxhU8ugrxri15jTPTnunDC+4EUA@mail.gmail.com> <87poo4as2j.fsf@hertz.schwinge.homeip.net>
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 _Complex
float __attribute__ ((__mode__ (__IC__))). Or similarly, with ARM __fp16,
the complex type _Complex float __attribute__ ((__mode__ (__HC__))).)
--
Joseph S. Myers
joseph@codesourcery.com