[Bug c++/58798] New: class with a class reference member generates unjustified warning

[Bug c++/58798] New: class with a class reference member generates unjustified warning

[nate at lumigrow dot com]

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

            Bug ID: 58798
           Summary: class with a class reference member generates
                    unjustified warning
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nate at lumigrow dot com

Created attachment 31045
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31045&action=edit
command line input/output and preprocessor output

A class member declared as a reference to a class generates an unjustified
warning and possibly generates incorrect code (if, for example, the class is
not packed and should be).

class A { public: A(void) {}; } _A ;
class B { public: A& _a; B(A& a) : _a( a) {}; } _B(_A);
class C { public: A* _p; C(A& a) : _p(&a) {}; } _C(_A);

warning: ignoring packed attribute because of unpacked non-POD field 'A& B::_a'

class B has a reference and class C has a pointer to the same type of class.
Both allocate 2 bytes for the member (8-bit cpu).
There should be no issue with packing.

Why does the compiler think there is an unpacked non-POD field?
Everything is packed and class A is declared before B or C.

Use of either the reference or the pointer should generate the same code, so
why does the compiler think there is a difference w.r.t. packing?

I am concerned that the compiler will not pack any class that contains a
reference and/or that if class A is packed and the compiler assumes it is not
when B accesses it the code will not have the right offsets.

[Bug c++/58798] class with a class reference member generates unjustified warning

[olafvdspek at gmail dot com]

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

Olaf van der Spek <olafvdspek at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |olafvdspek at gmail dot com

--- Comment #9 from Olaf van der Spek <olafvdspek at gmail dot com> ---
Any conclusions?
Could classes with references be packed?

[Bug c++/58798] class with a class reference member generates a warning that ought to be disableable with -Wpacked

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egallager at gcc dot gnu.org,
                   |                            |steven.spark at gmail dot com
            Summary|class with a class          |class with a class
                   |reference member generates  |reference member generates
                   |unjustified warning         |a warning that ought to be
                   |                            |disableable with -Wpacked

--- Comment #10 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Eric Gallager from comment #6)
> (In reply to Szikra from comment #5)
> > (In reply to Jonathan Wakely from comment #4)
> > > Because the warning isn't controlled by the -Wpacked option. If it was, it
> > > would say [-Wpacked] after the warning. I think that's a bug, every warning
> > > should be controlled by some -Wxxx option.
> > 
> > Thanks, good to know. So does this require a separate bug report, or can
> > someone change the status and confirm this one?
> 
> Confirmed that the warning should be controlled by -Wpacked.

Updating the title accordingly.

[Bug c++/58798] class with a class reference member generates a warning that ought to be disableable with -Wpacked

[olafvdspek at gmail dot com]

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

--- Comment #11 from Olaf van der Spek <olafvdspek at gmail dot com> ---
(In reply to Eric Gallager from comment #10)
> Updating the title accordingly.

The title doesn't reflect the original issue anymore, should a new issue be
filed for that?