[Bug web/112972] New: ambiguity in specification for cast to union types

[Bug web/112972] New: ambiguity in specification for cast to union types

[stephan.stiller at outlook dot com]

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

            Bug ID: 112972
           Summary: ambiguity in specification for cast to union types
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: web
          Assignee: unassigned at gcc dot gnu.org
          Reporter: stephan.stiller at outlook dot com
  Target Milestone: ---

On this page of the GCC documentation
    https://gcc.gnu.org/onlinedocs/gcc/Cast-to-Union.html
the statement that
    the following assignments
      z = (union foo) x;
      z = (union foo) y;
    are shorthand equivalents of these
      z = (union foo) { .i = x };
      z = (union foo) { .d = y };
doesn't give the full picture.

While the statement is accurate about
  union foo
  x
  y
  z
as defined just above, unions with multiple members of the same type would lead
to a potential ambiguity. For example, for Richard Stallman's example of a
union
    union datum {
      double latitude;
      double longitude;
      double height;
      double weight;
      int continent;
    }
(taken from: "GNU C Language Introduction and Reference Manual", Edition 0.0,
section 15.14 (Unions)), casting to this union would be indeterminate with
respect to which of the 4 members of type double is being assigned to.

That is, either (1) first writing to and then reading from identically typed
but differently named members is *not* undefined behavior (and this should be
stated somewhere in the documentation) or (2) a simple "equivalence" between
assignments of the form
    p = (union foo) q;
and assignments of the form
    p = (union foo) { .m = q };
can't exist (due to the ambiguity of which m applies in the case of there being
multiple members of type typeof(q)).

[Bug c/112972] ambiguity in specification for cast to union types

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>and this should be stated somewhere in the documentation

Actually it is documented.

https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Optimize-Options.html#Type-punning

The practice of reading from a different union member than the one most
recently written to (called “type-punning”) is common. Even with
-fstrict-aliasing, type-punning is allowed, provided the memory is accessed
through the union type.

[Bug c/112972] ambiguity in specification for cast to union types

[stephan.stiller at outlook dot com]

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

Stephan Stiller <stephan.stiller at outlook dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #2 from Stephan Stiller <stephan.stiller at outlook dot com> ---
I disagree; the documentation overall is contradictory with respect to whether
reading from a different member with the same type is also considered "type
punning".

Given the example of union datum p, it wouldn't make sense for any compiler to
not produce code with the intended effect for something like the following:
    p.height = 3.4;
    double d = p.weight;
However, the point is that this is not explicitly documented for the case of
different members having identical types.

For the example from the GCC webpage, if union foo were replaced by union
datum, it would be unclear what the "equivalence" would be. (The choice of
latitute/longitude/height/weight as the designated member of type double
wouldn't matter in practice, but again, this needs to be said explicitly.)