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

[Richard Biener]

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