Must TYPE_MODE of a UNION_TYPE be of MODE_INT class?

Jozef Lawrynowicz jozef.l@mittosystems.com
Thu May 24 18:01:00 GMT 2018


I've written a patch to fix the transparent_union attribute when the first
field in a union is MODE_PARTIAL_INT, but I noticed that the current code
only allows the TYPE_MODE of a UNION_TYPE to be of MODE_INT class.

See stor-layout.c (compute_record_mode), particularly this section:

   /* If we only have one real field; use its mode if that mode's size
      matches the type's size.  This only applies to RECORD_TYPE.  This
      does not apply to unions.  */
   if (TREE_CODE (type) == RECORD_TYPE && mode != VOIDmode
       && tree_fits_uhwi_p (TYPE_SIZE (type))
       && known_eq (GET_MODE_BITSIZE (mode), tree_to_uhwi (TYPE_SIZE
           (type))))
   ;
   else
     mode = mode_for_size_tree (TYPE_SIZE (type), MODE_INT, 1).else_blk ();

Is there a reason the type of the union must be of MODE_INT class but a
RECORD_TYPE with one field can have the class of it's single field?

If the else clause is changed to the following, then transparent_union unions
with a first field of double (e.g. gcc/testsuite/g++.dg/ext/transparent-union.C)
no longer error.

     mode = mode_for_size_tree (TYPE_SIZE (type),
                                (GET_MODE_CLASS (mode) != MODE_RANDOM
                                 ? GET_MODE_CLASS (mode) : MODE_INT),
                                1).else_blk ();

Could anyone provide some insight on whether the TYPE_MODE of a union should
stay as a MODE_INT class or if it would be acceptable for the TYPE_MODE to be
other classes e.g. MODE_FLOAT?



More information about the Gcc mailing list