[Bug c/71598] Wrong optimization with aliasing enums

rguenther at suse dot de gcc-bugzilla@gcc.gnu.org
Fri Mar 15 09:26:00 GMT 2019


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 15 Mar 2019, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
> 
> --- Comment #9 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> > Btw, I tried to use TREE_TYPE (TYPE_MIN_VALUE ()) of the ENUMERAL_TYPE but
> > that breaks with Ada (bah, no libbacktrace support there...):
> 
> Probably because of:
> 
>           /* Note that the bounds are updated at the end of this function
>              to avoid an infinite recursion since they refer to the type.  */
>           goto discrete_type;
> 
> > That is, input from language frontend maintainers is still needed as to
> > how to get at the integer type an enum type has to be compatible with
> > TBAA-wise and how to query whether there is any.  For the above Ada issue
> > the code could be amended to simply not do anything special for
> > ENUMERAL_TYPE without a TYPE_MIN_VALUE.
> 
> In Ada, enumeration and integer types are totally unrelated to each other.

I see.  Do you prefer a langhook solution that would "fix" this only
for C/C++ and LTO then?

> > I didn't yet try to debug what the Ada issue above is and what weird
> > kind of ENUMERAL_TYPEs Ada has ...
> 
> We probably don't set TYPE_MIN_VALUE at all to avoid the circularity.

OK, I see.  VRP still expects it to exist though (just not for
pointer types).  Anyhow, I'm probably leaning towards looking at
TYPE_SIZE.  Hopefully "incomplete" enums do not exist ;)


More information about the Gcc-bugs mailing list