[Bug c++/114388] New: Behavioral change of typeid on xvalues since GCC 9

[Bug c++/114388] New: Behavioral change of typeid on xvalues since GCC 9

[de34 at live dot cn]

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

            Bug ID: 114388
           Summary: Behavioral change of typeid on xvalues since GCC 9
           Product: gcc
           Version: 9.5.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: de34 at live dot cn
  Target Milestone: ---

IIUC this program behaves differently in C++98 and C++11 due to WG21 N3055
(https://wg21.link/n3055):
```
#include <typeinfo>
#include <cstdio>

struct B {
  virtual ~B() { std::puts("~B"); }
};

struct D : B {};

struct WrapB {
  B b;
};

struct WrapD {
  D d;
};

int main() {
  typeid(true ? WrapB().b : WrapD().d);
}

```

Before C++11/N3055, the operand of the typeid expression shouldn't be evaluated
because it's a rvalue. But since C++11 it should be evaluated because it's a
glvalue of a polymorphic class type.

It's curious that GCC behaves consistently on this in C++98 and C++11 modes.
Per https://godbolt.org/z/7oGdjdMK7, it seems that GCC 8 (and former versions)
applied the C++98 rules to C++11 and later modes, and GCC 9 (and later verions)
applied the C++11 rules to C++98 mode.

For later versions, I'm not sure whether this is a bug (in C++98 mode) or an
intentional backporting.

[Bug c++/114388] Behavioral change of typeid on xvalues since GCC 9

[de34 at live dot cn]

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

--- Comment #1 from Jiang An <de34 at live dot cn> ---
Moreover, perhaps we should list N3055 in the implementation status page
(https://gcc.gnu.org/projects/cxx-status.html) since it did contain behavioral
change of typeid.

[Bug c++/114388] Behavioral change of typeid on xvalues since GCC 9

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
So you say GCC 9+ are wrong with -std=c++98 but OK with -std=c++11 or newer
(the default)?

[Bug c++/114388] Behavioral change of typeid on xvalues since GCC 9

[de34 at live dot cn]

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

--- Comment #3 from Jiang An <de34 at live dot cn> ---
(In reply to Richard Biener from comment #2)
> So you say GCC 9+ are wrong with -std=c++98 but OK with -std=c++11 or newer
> (the default)?

Yes.

[Bug c++/114388] Behavioral change of typeid on xvalues since GCC 9

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This changed with r9-595-g955da5e5443724:

    CWG 616, 1213 - value category of subobject references.

            * tree.c (lvalue_kind): A reference to a subobject of a prvalue is
            an xvalue.
            * typeck2.c (build_m_component_ref): Likewise.
            * typeck.c (cp_build_addr_expr_1, lvalue_or_else): Remove
diagnostic
            distinction between temporary and xvalue.

    From-SVN: r260621

CWG 616 and CWG 1213 are DR, so apply to C++98.

I don't think GCC cares about N3055 here.

[Bug c++/114388] Behavioral change of typeid on xvalues since GCC 9

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Prior to DR 616 the expression (true ? WrapB().b : WrapD().d) was a prvalue of
type B, created by copying the B (or slicing the D when the condition is
false). As an rvalue, it wasn't evaluated. That's true pre-N3055 and
post-N3055.

DR 616 changed WrapB().b to be an xvalue, and the result of the expression is
B&& in C++1 (and const B& in C++98 I guess).

In C++98 the const B& is an lvalue, and in C++11 the B&& is an xvalue which is
a glvalue. Either way, it's correct to treat it as a glvalue of polymorphic
type and evaluate it.

So this change is not caused by N3055. And I think G++ is correct for both
C++98 and C++11. So INVALID.

[Bug c++/114388] Behavioral change of typeid on xvalues since GCC 9

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #5)
> In C++98 the const B& is an lvalue, and in C++11 the B&& is an xvalue which
> is a glvalue. Either way, it's correct to treat it as a glvalue of
> polymorphic type and evaluate it.

Or more precisely, in C++98 it's an lvalue and the rule is that lvalues are
evaluated.
In C++11 it's an xvalue which is a glvalue, and the rule is that glvalues are
evaluated.

So even though N3055 isn't a DR, that doesn't matter. The behaviour changed
with DR 616 not with N3055.

[Bug c++/114388] Behavioral change of typeid on xvalues since GCC 9

[de34 at live dot cn]

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

--- Comment #7 from Jiang An <de34 at live dot cn> ---
(In reply to Jonathan Wakely from comment #5)
> Prior to DR 616 the expression (true ? WrapB().b : WrapD().d) was a prvalue
> of type B, created by copying the B (or slicing the D when the condition is
> false). As an rvalue, it wasn't evaluated. That's true pre-N3055 and
> post-N3055.
> 
> DR 616 changed WrapB().b to be an xvalue, and the result of the expression
> is B&& in C++1 (and const B& in C++98 I guess).
> 
> In C++98 the const B& is an lvalue, and in C++11 the B&& is an xvalue which
> is a glvalue. Either way, it's correct to treat it as a glvalue of
> polymorphic type and evaluate it.
> 
> So this change is not caused by N3055. And I think G++ is correct for both
> C++98 and C++11. So INVALID.

Pre-N3055 there were no xvalue branch in [expr.cond], and (later-called)
xvalues were handled alongwith prvalues. I don't see anything in C++98
[expr.cond] adding const& when there's no const values.

This example also shows that GCC hasn't been thinking that the result of the
expression is const B& in C++98: https://godbolt.org/z/EPv65oY1W.

[Bug c++/114388] Behavioral change of typeid on xvalues since GCC 9

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The change makes the value category clk_rvalueref but I don't know what that
means in C++98 mode:

       op1_lvalue_kind = lvalue_kind (TREE_OPERAND (ref, 0));
+      if (op1_lvalue_kind == clk_class)
+       /* If E1 is an lvalue, then E1.E2 is an lvalue;
+          otherwise E1.E2 is an xvalue.  */
+       op1_lvalue_kind = clk_rvalueref;

You're right that it's not a const B& but it's also not a prvalue of type B.
It's some kind of reference though, as there is no longer a copy/slice that
produces a B prvalue (you can add a private copy ctor and see that it's needed
in GCC 8 and not in GCC 9).

[Bug c++/114388] Behavioral change of typeid on xvalues since GCC 9

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
If there's a bug here, it's the value category of the ternary expression, not a
problem with typeid. Whether there's a problem with the value category depends
on how the DR is interpreted to apply to C++98. I'll let Jason respond to that
part.

[Bug c++/114388] Behavioral change of typeid on xvalues since GCC 9

[de34 at live dot cn]

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

--- Comment #10 from Jiang An <de34 at live dot cn> ---
Broken down into two smaller examples:


https://godbolt.org/z/YhK7PqE6s
```
#include <cstdio>
#include <typeinfo>

int main() {
  struct B {
    B() {}
    virtual ~B() { std::puts("C++11"); }
  };

  struct C { B b; };
  typeid(C().b); // unevaluated in C++98, evaluated in C++11
}
```

https://godbolt.org/z/on76q4Mx5
```
#include <cstdio>

int main() {
  struct B {
    B() {}
    B(const B&) { std::puts("C++98"); }
  };
  struct D : B {};

  struct BB { B b; };
  struct DD { D d; };

  true ? BB().b : DD().d; // additional copy in C++98, no copy or move in C++11
}
```

CWG2887 (https://cplusplus.github.io/CWG/issues/2887.html) is related.