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]))

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

On Mon, 19 Sep 2016 10:12:48 +0200, Richard Biener <richard.guenther@gmail.com> wrote:
> 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.

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üße
 Thomas