[Bug c++/58910] New: std::Tuple_impl is non constexpr when using identical userdefined structs as type

[Bug c++/58910] New: std::Tuple_impl is non constexpr when using identical userdefined structs as type

[Gaetano.Checinski at googlemail dot com]

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

            Bug ID: 58910
           Summary: std::Tuple_impl is non constexpr when using identical
                    userdefined structs as type
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Gaetano.Checinski at googlemail dot com

Following code does not compile with gcc-snapshot(2013-10-21) :

#include <tuple>
using namespace std;
struct t1{ constexpr t1(){} };
struct t2{ constexpr t2(){} };


int main()
{
 constexpr t1 T1;
 constexpr t2 T2;
 constexpr tuple<t1,t2> Tup1(T1,T2);
 constexpr tuple<t1,t1> Tup2(T1,T1);
 constexpr auto a=get<0>(Tup1 ); //works fine
 constexpr auto b=get<0>(Tup2 ); // error: 
//'(const std::_Head_base<0ul, t1, true>*)(& Tup2)' 
//is not a constant expression constexpr auto b=get<0>(Tup2 );

return 0;
}

[Bug c++/58910] [4.9 Regression] std::Tuple_impl is non constexpr when using identical userdefined structs as template-args

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-10-29
                 CC|                            |jwakely.gcc at gmail dot com
            Summary|std::Tuple_impl is non      |[4.9 Regression]
                   |constexpr when using        |std::Tuple_impl is non
                   |identical userdefined       |constexpr when using
                   |structs as template-args    |identical userdefined
                   |                            |structs as template-args
     Ever confirmed|0                           |1

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> ---
This is a regression and I don't think we changed anything in the library?!?
Looks like a C++ regression then, and we would need a reduced testcase.

[Bug c++/58910] std::Tuple_impl is non constexpr when using identical userdefined structs as template-args

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.9 Regression]            |std::Tuple_impl is non
                   |std::Tuple_impl is non      |constexpr when using
                   |constexpr when using        |identical userdefined
                   |identical userdefined       |structs as template-args
                   |structs as template-args    |

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Sorry, in fact this isn't a regression. Still the issue seems serious in terms
of impact on <tuple> use. I also note that with the same <tuple>
implementation, clang++ accepts the testcases, thus seems definitely a
front-end issue.

[Bug c++/58910] std::Tuple_impl is non constexpr when using identical userdefined structs as template-args

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen <ville.voutilainen at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ville.voutilainen at gmail dot com

--- Comment #3 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
I can't reproduce this bug with the current trunk.