https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38087
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |accepts-invalid
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-08-17
CC| |egallager at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Eric Gallager <egallager at gcc dot gnu.org> ---
Redoing lost comments:
https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01624.html
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2017-08-14
CC| |egallager at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> I still think this is valid code ... There are defect reports against this
> area too.
Which ones do you mean?
https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01637.html
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |accepts-invalid
Status|WAITING |NEW
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
There's https://wg21.link/cwg555 but I don't think it changes anything here.
[expr.pseudo] definitely doesn't apply, as that only applies to non-class
types. (The bug title is wrong for the same reason, this is a destructor call,
not a pseudo destructor call.)
The current wording in [basic.lookup.classref] says "At least one of the
lookups shall find a name that refers to cv T." The object expression has type
C, but the lookup result for B does not find that type, so the code is invalid.
