[Bug c++/42013] New: cv-qualification of conditional expression type depending on the value of its first expression?!?

I'm seeing something strange while implementing C++0x declval. In a nutshell,
since I'm not reading anything in 5.16 (of C++03) saying that the type of a
conditional expression depends on the value of its first expression, I'm
surprised that this is the case with GCC, as far as cv-qualification is
concerned.

By the way, if actually this is conforming behavior, then the current C++0x
specifications for the two arguments common_type become really weird (see
20.6.7/3 in N2960): the cv-qualification of the common_type ends up depending
on the order of the types. Cannot be right, IMHO.

For example, the below doesn't compile:

template<typename _Tp>
  struct __declval_protector
  {
     static _Tp __delegate();
  };

template<typename _Tp>
  _Tp
  declval()
  {
    return __declval_protector<_Tp>::__delegate();
  }

template<typename _Tp, typename _Up>
  struct common_type
  {
    typedef __decltype(true  ? declval<_Tp>() : declval<_Up>()) typet;
    typedef __decltype(false ? declval<_Tp>() : declval<_Up>()) typef;
  };

template<typename, typename> struct is_same;

template<typename _Tp> struct is_same<_Tp, _Tp> { typedef _Tp type; };

void f()
{
  typedef common_type<int, const int>::typet typet;
  typedef common_type<int, const int>::typef typef;

  typedef is_same<typet, typef>::type type;
}


--
           Summary: cv-qualification of conditional expression type
                    depending on the value of its first expression?!?
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: paolo dot carlini at oracle dot com


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

------- Comment #1 from paolo dot carlini at oracle dot com  2009-11-12 04:09 -------
Actually, the observation about C++0x is largely incorrect, because the actual
specifications in DR 1255 are different, use std::add_rvalue_reference.

However, my main puzzlement stands.

Also, as regards the C++0x common_type (per DR 1255), I'm seeing the problem
with cv-qualified void, eg, replace in the snippet int -> void and const int ->
const void, because in that case std::add_rvalue_reference does nothing:

#include <type_traits>

template<typename _Tp>
  struct __declval_protector
  {
     static typename std::add_rvalue_reference<_Tp>::type __delegate();
  };

template<typename _Tp>
  typename std::add_rvalue_reference<_Tp>::type
  declval()
  {
    return __declval_protector<_Tp>::__delegate();
  }

template<typename _Tp, typename _Up>
  struct common_type
  {
    typedef __decltype(true  ? declval<_Tp>() : declval<_Up>()) typet;
    typedef __decltype(false ? declval<_Tp>() : declval<_Up>()) typef;
  };

template<typename, typename> struct is_same;

template<typename _Tp> struct is_same<_Tp, _Tp> { typedef _Tp type; };

void f()
{
  typedef common_type<void, const void>::typet typet;
  typedef common_type<void, const void>::typef typef;

  typedef is_same<typet, typef>::type type;
}


--


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

------- Comment #2 from pinskia at gcc dot gnu dot org  2009-11-12 04:16 -------
Might be related to the old fixed bug 36628.


--


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

------- Comment #3 from jason at gcc dot gnu dot org  2009-11-12 05:47 -------
More hoops to jump through to prevent the magic decltype handling of calls
exposed by constant folding...


--

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-11-12 05:47:08
               date|                            |


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

------- Comment #4 from jason at gcc dot gnu dot org  2009-11-12 18:26 -------
Subject: Bug 42013

Author: jason
Date: Thu Nov 12 18:25:42 2009
New Revision: 154124

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154124
Log:
        PR c++/42013
        * call.c (build_conditional_expr): Don't fold a TREE_SIDE_EFFECTS
        COND_EXPR in unevaluated context.

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/decltype19.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/call.c
    trunk/gcc/testsuite/ChangeLog


--


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

------- Comment #5 from paolo dot carlini at oracle dot com  2009-11-12 18:47 -------
Thanks.


--


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

------- Comment #6 from jason at gcc dot gnu dot org  2009-11-12 20:26 -------
Subject: Bug 42013

Author: jason
Date: Thu Nov 12 20:26:36 2009
New Revision: 154129

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154129
Log:
        PR c++/42013
        * call.c (build_conditional_expr): Check specifically for folding
        to CALL_EXPR rather than TREE_SIDE_EFFECTS.

Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/call.c
    trunk/gcc/testsuite/g++.dg/cpp0x/decltype19.C


--


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

------- Comment #7 from jason at gcc dot gnu dot org  2009-11-12 20:27 -------
Fixed.


--

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.5.0


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