[Bug c++/39934] New: Union member incorrectly disallowed

struct A {
  const int x;
  int y;
};

union U {
  const int x;
  A a;
};


g++ 4.3.1 says...

vvv.C:8: error: member `A U::a' with copy assignment operator not allowed in
union

As far as I can see, struct A does not have a copy assignment operator
at all.

Sun's Forte 12 is happy with the code for what that is worth.


--
           Summary: Union member incorrectly disallowed
           Product: gcc
           Version: 4.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: terra at gnome dot org
  GCC host triplet: x86_64-suse-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934

------- Comment #1 from paolo dot carlini at oracle dot com  2009-04-27 20:49 -------
For the record, Comeau and Intel are not happy, though.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934

------- Comment #2 from redhatter at gentoo dot org  2009-11-03 05:45 -------
Also confirmed on GCC 3.4.5 as distributed with Qt SDK:

EzeCorp@TOSHIBA /tmp
$ /c/Qt/2009.03/mingw/bin/gcc --version
gcc.exe (GCC) 3.4.5 (mingw-vista special r3)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

EzeCorp@TOSHIBA /tmp
$ cat test.c
struct A {
  const int x;
  int y;
};

union U {
  const int x;
  struct A a;
};

EzeCorp@TOSHIBA /tmp
$ gcc -o test-c.o -c test.c

EzeCorp@TOSHIBA /tmp
$ echo $?
0

EzeCorp@TOSHIBA /tmp
$ g++ -o test-cpp.o -c test.c
test.c:8: error: member `A U::a' with copy assignment operator not allowed in
union

EzeCorp@TOSHIBA /tmp
$ echo $?
1

Is there a sane workaround for this?


--

redhatter at gentoo dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |redhatter at gentoo dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934

------- Comment #3 from redi at gcc dot gnu dot org  2009-11-03 13:32 -------
(In reply to comment #2)
>
> Is there a sane workaround for this?

Don't use 'const' members of unions.

Union members cannot have a non-trivial copy assignment operator.
The assignment operator for A cannot be implicitly defined, as the const member
would make the program ill-formed.
I'm not sure whether using A in a union causes the implicitly-declared copy
assignment operator to be implicitly defined, but that seems to be what's
happening.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934

------- Comment #4 from terra at gnome dot org  2009-11-03 13:47 -------
> I'm not sure whether using A in a union causes the implicitly-declared copy
> assignment operator to be implicitly defined, but that seems to be what's
> happening.

No, that's not quite it.

The requirement for union members is that there cannot be a non-trivial copy
assignment operator.

gcc uses a different rule: it insists that there be a default copy assignment
operator.

Presumably someone thought those two formulations were the same.  But they
are not: struct A doesn't have a copy assignment operator at all.

For the record, this kind of code occurs fairly naturally in C when creating
trees with different node types, tagged here by "x". The problems arise when
C++ code needs to interface with that C code.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934

------- Comment #5 from redi at gcc dot gnu dot org  2009-11-03 14:21 -------
(In reply to comment #4)

> > I'm not sure whether using A in a union causes the implicitly-declared copy
> > assignment operator to be implicitly defined, but that seems to be what's
> > happening.
>
> No, that's not quite it.
>
> The requirement for union members is that there cannot be a non-trivial copy
> assignment operator.
>
> gcc uses a different rule: it insists that there be a default copy assignment
> operator.
>
> Presumably someone thought those two formulations were the same.

Use the source, Luke:

      if (TYPE_HAS_COMPLEX_ASSIGN_REF (type))
        error ("member %q+#D with copy assignment operator not allowed in
union"
,
           field);

/* Nonzero if there is a user-defined X::op=(x&) for this class.  */
#define TYPE_HAS_COMPLEX_ASSIGN_REF(NODE) (LANG_TYPE_CLASS_CHECK
(NODE)->has_com
plex_assign_ref)

Now there could be a bug there, but it superficially looks right, and does not
look as though anyone thought the two formulations are the same.

>  But they
> are not: struct A doesn't have a copy assignment operator at all.

It might not be defined, but one is declared, according to [class.copy]/10
"If the class definition does not explicitly declare a copy assignment
operator, one is declared implicitly."


> For the record, this kind of code occurs fairly naturally in C when creating
> trees with different node types, tagged here by "x". The problems arise when
> C++ code needs to interface with that C code.

The fact there are problems doesn't mean g++ is wrong.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934

------- Comment #6 from terra at gnome dot org  2009-11-03 17:44 -------
cp/class.c has code like this:

/* If any field is const, the structure type is pseudo-const. * /
if (CP_TYPE_CONST_P (type))
  {
    ...
    /* ARM $12.6.2: [A member initializer list] (or, for an
       aggregate, initialization by a brace-enclosed list) is the
       only way to initialize nonstatic const and references
       members.  */
    TYPE_HAS_COMPLEX_ASSIGN_REF (t) = 1;
  }

The ARM comment (as quoted) is clearly wrong: offhand, I can think of
two other ways of getting an object initialized.  There are probably
more.

1. Casting the offending "const" away.  (Note that struct A is a plain
   old C type -- data members only.)

   // Make an object of type A.
   A *pa = (A *)malloc (sizeof (A));
   *const_cast<int *>(&pa->x) = 42;
   pa->y = 42;

2. Copying an existing object.

   A a (*pa);

I don't see the justification for setting TYPE_HAS_COMPLEX_ASSIGN_REF,
just for prohibiting assignment.  That's pretty much the mixup I was
claiming in comment 4.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934

------- Comment #7 from paolo dot carlini at oracle dot com  2009-11-03 17:49 -------
Saying that ARM is "wrong" seems frankly rather silly to me: either the
quotation is incorrect, I don't think so, or ARM has been obsoleted by the ISO
Standard, perfectly possible.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934

------- Comment #8 from redi at gcc dot gnu dot org  2009-11-03 18:10 -------
(In reply to comment #6)
>
> The ARM comment (as quoted) is clearly wrong: offhand, I can think of
> two other ways of getting an object initialized.  There are probably
> more.
>
> 1. Casting the offending "const" away.  (Note that struct A is a plain
>    old C type -- data members only.)

It's irrelevant that it has data members only.  Casting away const on an object
declared const is undefined behaviour.

> 2. Copying an existing object.
>
>    A a (*pa);

Copy construction is dealt with separately from copy assignment, so
has_complex_assign_ref is not relevant in this case.

So the ARM comment may be incorrect, but not due to either of your reasons.

As I said earlier, I'm not sure whether using A in a union causes the
implicitly-declared copy assignment operator to be implicitly defined.  This
issue hinges on that point, not on the points you've been making.

The standard is clear that a copy assignment operator is implicitly-declared.
If it is implicitly defined then that copy assignment operator would be
ill-formed.
So the only question is whether using the type in a union causes it to be
implicitly defined.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934

------- Comment #9 from redi at gcc dot gnu dot org  2009-11-04 14:41 -------
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#653
and
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#683
and
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2762

I'm still not sure what should happen though, I might ask on the std reflector.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934

------- Comment #10 from redi at gcc dot gnu dot org  2009-11-04 15:28 -------
To be clear:  In C++0x struct A would have a deleted copy assign operator, and
union U would be allowed, but its copy assignment operator would be deleted.

IMHO C++03 is not clear whether struct A has a trivial assignment operator or
not.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934