https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #8 from Richard Biener <rguenth 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...):
make[3]: ***
[/space/rguenther/src/svn/trunk/gcc/ada/gcc-interface/Make-lang.in:1033:
ada/libgnat/a-except.o] Error 1
+===========================GNAT BUG DETECTED==============================+
| 9.0.1 20190314 (experimental) (x86_64-pc-linux-gnu) Storage_Error stack
overflow or erroneous memory access|
| Error detected at lib-xref-spark_specific.adb:39:37 |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ . |
| Use a subject line meaningful to you and us to track the bug. |
| Include the entire contents of this bug box in the report. |
| Include the exact command that you entered. |
| Also include sources listed below. |
+==========================================================================+
Please include these source files with error report
btw, fixing this in get_alias_set would make this transitive (but exact
behavior is still implementation defined!).
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.
For C I guess the type of TYPE_MIN_VALUE matches the type the enum is
compatible with, for C++ I would hope so as well. Testcases covering
also -fshort-enum should be easy to write.
Note anything involving a langhook is going to not work with LTO.
Note another possibility would be (given that most FEs, including LTO,
make unsigned and signed type variants compatible) to look at the
ENUMERAL_TYPEs mode and use the corresponding (unsigned) integer type
as compatible type. That may not work for under-aligned enums though
where the mode may end up as BLKmode... which means we'd need to look
at TYPE_SIZE instead.
I didn't yet try to debug what the Ada issue above is and what weird
kind of ENUMERAL_TYPEs Ada has ...
