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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org,
                   |                            |jason at gcc dot gnu.org,
                   |                            |jsm28 at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
get_alias_set does nothing special for ENUMERAL_TYPE which means distinct
enums get distinct alias sets.  Iff the C standard says that from a TBAA
perspective an enumeral type is to be treated as one of the standard
integer types then we need a way to represent such type in the middle-end
or the frontends need to not expose the distinct ENUMERAL_TYPE (at least
in accesses) but whatever underlying type is to be used.

Note since this targets the middle-end behavior the required language
semantics of other languages play a role as well.

A conservative middle-end only patch could look like the following - possibly
also a good idea for LTO.  Eventually we could settle on the ENUMERAL_TYPEs
TYPE_VALUES first entry type to specify that underlying type, but that would
need agreement.  It looks like TREE_TYPE of an ENUMERAL_TYPE is also not
"taken" (but all FEs needing the get_alias_set treatment would need adjustment,
at least it could be conditional on TREE_TYPE set).  The TYPE_VALUES idea
would leave us with no way to handle empty enums.  Another thing to look
at would be TREE_TYPE (TYPE_MIN/MAX_VALUE), for the testcase and the C FE
it is unsigned int.

diff --git a/gcc/alias.c b/gcc/alias.c
index b64e3ea264d..8fbf34bf4dc 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -931,6 +931,11 @@ get_alias_set (tree t)
   if (set != -1)
     return set;

+  /* Enums inter-operate with the corresponding integer type.  */
+  else if (TREE_CODE (t) == ENUMERAL_TYPE)
+    return get_alias_set (build_nonstandard_integer_type
+                           (TYPE_PRECISION (t), TYPE_UNSIGNED (t)));
+
   /* There are no objects of FUNCTION_TYPE, so there's no point in
      using up an alias set for them.  (There are, of course, pointers
      and references to functions, but that's different.)  */

Reply via email to