[Bug c++/41796] New: Extended sizeof (referring to non-static member) rises ambiguity

[Bug c++/41796] New: Extended sizeof (referring to non-static member) rises ambiguity

[schaub-johannes at web dot de]

The following code fails for GCC:

struct A { int a; }; 
struct B : A {}; 
struct C : A {}; 
struct D : B, C { }; 
int main() { (void) sizeof(D::a); }

According to the current draft, such use is correct: Name lookup will resolve
to a single declaration, and sizeof does not make additional constraint with
regard to the subobject to refer to. It is reasonable to suspect a standard
defect - this bug report is supposed to be a reminder in that case.


-- 
           Summary: Extended sizeof (referring to non-static member) rises
                    ambiguity
           Product: gcc
           Version: 4.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: schaub-johannes at web dot de
  GCC host triplet: 4.4.1
GCC target triplet: 4.4.1


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

[Bug c++/41796] Extended sizeof (referring to non-static member) rises ambiguity

[schaub-johannes at web dot de]

------- Comment #1 from schaub-johannes at web dot de  2009-10-22 18:42 -------
I found the same problem occurs with decltype - same diagnostic. Wasn't sure
whether i should open another bug report for that. 


-- 


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

[Bug c++/41796] ambiguous subobject diagnostic given too early

[jason at gcc dot gnu dot org]

------- Comment #2 from jason at gcc dot gnu dot org  2010-02-09 22:28 -------
Confirmed.  10.3 says that the lookup is unambiguous, just some uses can be
ambiguous.  In fact, we fail the test in paragraph 13:

struct B1 {
  void f();
  static void f(int);
  int i;
};
struct B2 {
  void f(double);
};
struct I1: B1 { };
struct I2: B1 { };
struct D: I1, I2, B2 {
  using B1::f;
  using B2::f;
  void g() {
    f();                    // Ambiguous conversion of this
    f(0);                   // Unambiguous (static)
    f(0.0);                 // Unambiguous (only one B2)
    int B1::* mpB1 = &D::i; // Unambiguous - G++ gets this one wrong
    int D::* mpD = &D::i;   // Ambiguous conversion
  }
};

so, changing the subject line and removing the C++0x tag.


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |rejects-valid
   Last reconfirmed|0000-00-00 00:00:00         |2010-02-09 22:28:30
               date|                            |
            Summary|[C++0x] Extended sizeof     |ambiguous subobject
                   |(referring to non-static    |diagnostic given too early
                   |member) rises ambiguity     |


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

[Bug c++/41796] ambiguous subobject diagnostic given too early

[schaub-johannes at web dot de]

------- Comment #3 from schaub-johannes at web dot de  2010-02-11 01:08 -------
Well this is certainly not valid C++03, so i have tagged it c++0x (class member
name lookup was completely rewritten in c++0x, which made it valid and which
also added 10.2). In '03, the following should fail i think, instead of
re-declaring the member name as an alias to the declaration of "a" in A:

struct A { int a; }; 
struct B : A {}; 
struct C : A {}; 
struct D : B, C { }; 
struct E : D { using D::a; };

The example in 10.2/13 (n3000) is missing an ambiguity check: It's impossible
for GCC to figure out to which sub-object the member pointer address is
associated with. I think the example is wrong (see
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#983 for the issue
report about it).


-- 


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

[Bug c++/41796] ambiguous subobject diagnostic given too early

[jason at gcc dot gnu dot org]

------- Comment #4 from jason at gcc dot gnu dot org  2010-02-11 05:29 -------
Thanks for pointing out that this has changed since C++03, though the change
was to fix to something that was clearly broken.

In any case, I disagree with issue 983.  The point of the example is that it
doesn't matter what subobject it refers to, as the type of &D::i is 'int B::*'.


-- 


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

[Bug c++/41796] ambiguous subobject diagnostic given too early

[schaub-johannes at web dot de]

------- Comment #5 from schaub-johannes at web dot de  2010-02-11 15:06 -------
Ah, i see now. I always thought the the member pointer would contain an offset
from the nested-name-specifier of the "D::i" regardless of the type of the
result. 

In fact, i see now that i'm wrong. Ambiguity checks are done for both of ".*"
and for the implicit conversion at point of use, and the pointer will just
contain "offset 0 in B1" or something to that effect. 

I feel sad now since i'm guilty of making that issue report. Hopefully it won't
make it into the IS :) Tho i wish they would make a cross reference to the
section of ".*" (5.5) too. 


-- 


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

[Bug c++/41796] ambiguous subobject diagnostic given too early

[schaub-johannes at web dot de]

------- Comment #6 from schaub-johannes at web dot de  2010-04-02 14:02 -------
(In reply to comment #4)
> Thanks for pointing out that this has changed since C++03, though the change
> was to fix to something that was clearly broken.
> 
> In any case, I disagree with issue 983.  The point of the example is that it
> doesn't matter what subobject it refers to, as the type of &D::i is 'int B::*'.
> 

I notified Daniel Kruegler about this, since the DR got CD2 status. He replied
that you might want to consider reopening it.


-- 


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