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: Richard Biener <richard dot guenther at gmail dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Thomas Schwinge <thomas at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, GCC Development <gcc at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>, Bernd Schmidt <bschmidt at redhat dot com>
- Date: Mon, 19 Sep 2016 10:12:48 +0200
- 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> <alpine.DEB.2.20.1609161704190.14509@digraph.polyomino.org.uk>
On Fri, Sep 16, 2016 at 7:07 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> 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__))).)
The question is whether such a complex type could be a global tree which I
don't think it could.
Richard.
> --
> Joseph S. Myers
> joseph@codesourcery.com
- References:
- Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6])
- Re: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6])
- Re: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6])
- [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]))
- 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]))
- 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]))
- 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]))