[Bug c++/58046] New: template operator= in SFINAE class

[Bug c++/58046] New: template operator= in SFINAE class

[suibaka at gmail dot com]

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

            Bug ID: 58046
           Summary: template operator= in SFINAE class
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: suibaka at gmail dot com

I think the following code should be compile error,
but the result is ICE in gcc-4.7.2.

The error still exists in gcc HEAD.

$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.7.2/configure
--enable-languages=c,c++,ada,fortran,obj
c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared
--enable-libgo
mp --disable-win32-registry --enable-libstdcxx-debug
--disable-build-poststage1-
with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.7.2 (GCC)


The code:

#include <type_traits>

extern void* enabler; 

template <typename T, typename
std::enable_if<std::is_arithmetic<T>::value>::type*& = enabler>
class A
{
public:
    A()
    {}
    template <typename U>
    A& operator=( A<U>&& rhs )
    {
        return *this;
    }
};

int main()
{
    A<int> a_i;
    A<double> a_d;

    a_i = a_d;
}


The error(in 4.7.2):

$ g++ main.cc -Wall -std=c++11
main.cc: In function 'int main()':
main.cc:24:11: internal compiler error: in unify, at cp/pt.c:16956
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


The error(in HEAD):

prog.cc: In substitution of 'template<class U> A<T, <anonymous> >& A<T,
<anonymous> >::operator=(A<U>&&) [with U = <missing>]':
prog.cc:24:9:   required from here
prog.cc:24:9: internal compiler error: in unify, at cp/pt.c:17384
     a_i = a_d;

[Bug c++/58046] template operator= in SFINAE class

[paolo.carlini at oracle dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-invalid-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-08-01
     Ever confirmed|0                           |1

[Bug c++/58046] template operator= in SFINAE class

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler@googlemail.
                   |                            |com

--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
The same problem occurs for gcc 4.9.0 20130616 (experimental) as well.

A version without any dependencies to the library headers:

//--------------------------------
template<bool, class T = void>
struct enable_if {};

template<class T>
struct enable_if<true, T>
{
  using type = T;
};

template<class T>
struct is_true
{
  static constexpr bool value = true;
};

extern void* enabler;

template <typename T, typename enable_if<is_true<T>::value>::type*& = enabler>
class A
{
public:
    A()
    {}
    template <typename U>
    A& operator=( A<U>&& rhs )
    {
        return *this;
    }
};

int main()
{
    A<int> a_i;
    A<double> a_d;

    a_i = a_d;
}
//---------------------------------------------------------

Gives as well:

"
main.cpp|36|required from here|
main.cpp|36|internal compiler error: in unify, at cp/pt.c:17325|
"

It is interesting to note that a variation of this sfinae construction doesn't
produce the ICE:

template <typename T, typename enable_if<is_true<T>::value, bool>::type =
false>
class A
{
public:
    A()
    {}
    template <typename U>
    A& operator=( A<U>&& rhs )
    {
        return *this;
    }
};

int main()
{
    A<int> a_i;
    A<double> a_d;

    a_i = a_d;
}
>From gcc-bugs-return-427283-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Aug 03 18:58:48 2013
Return-Path: <gcc-bugs-return-427283-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30359 invoked by alias); 3 Aug 2013 18:58:48 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 30296 invoked by uid 48); 3 Aug 2013 18:58:45 -0000
From: "daniel.kruegler at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/58062] [C++11] bogus __func__ lookup in lambda body
Date: Sat, 03 Aug 2013 18:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords: accepts-invalid, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: daniel.kruegler at googlemail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-58062-4-8gis8sE28p@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58062-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58062-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-08/txt/msg00207.txt.bz2
Content-length: 968

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

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler@googlemail.
                   |                            |com

--- Comment #2 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
The fact that MSVC is giving the "expected error" is a bit misleading. It
rejects it, because it still is not conforming and is not aware of __func__ in
any context. But I agree that correct MSVC behaviour can be deduced when
__FUNCTION__ is used instead.

While I agree that gcc is not conforming I would like to add that many existing
compilers do not and to my knowledge there is an core language issue planned in
regard to exactly this problem, so I recommend to defer working on that.
>From gcc-bugs-return-427284-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Aug 03 20:08:52 2013
Return-Path: <gcc-bugs-return-427284-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23462 invoked by alias); 3 Aug 2013 20:08:52 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 23370 invoked by uid 48); 3 Aug 2013 20:08:47 -0000
From: "daniel.kruegler at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/58063] default arguments evaluated twice per call
Date: Sat, 03 Aug 2013 20:08:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: daniel.kruegler at googlemail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-58063-4-BEWnVWvzlq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58063-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58063-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-08/txt/msg00208.txt.bz2
Content-length: 2576

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

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler@googlemail.
                   |                            |com

--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
The behavior looks indeed odd to me (and I can confirm it for gcc 4.9 as well).
I suspect at the moment that it is somehow related to the very specific
definition of std::cout, because when I try to mimic the problem for a model
type like the following, I cannot produce this effect:

//---------------------------------------------
#include <iostream>

struct my_ostream
{
  my_ostream(){}
  virtual ~my_ostream() {}
  operator void*() const { return const_cast<my_ostream*>(this); }
  bool operator!() const { return false; }
private:
  my_ostream(const my_ostream&);
  my_ostream& operator=(const my_ostream&);
 } my_cout;

my_ostream& operator<<(my_ostream& os, const char* s)
{
  std::cout << s;
  return os;
}

void f(bool x = !(std::cout << "hi!\n")) {
  std::cout << x << '\n';
}

void f2(bool x = !(my_cout << "hi!\n")) {
  std::cout << x << '\n';
}

int main() {
 f();
 std::cout << "------------------\n";
 f2();
}
//---------------------------------------------

gives the output:

<quote>
hi!
hi!
0
------------------
hi!
0
</quote>

Looking at the generate assembly (mingw 64 but), I see the following relevant
lines:

0x004017AD    lea    0x7a86d(%rip),%rdx        # 0x47c021
<std::piecewise_construct+1>
0x004017B4    mov    0x7e4a5(%rip),%rcx        # 0x47fc60 <.refptr._ZSt4cout>
0x004017BB    callq  0x4624c0 <std::operator<< <std::char_traits<char>
>(std::basic_ostream<char, std::char_traits<char> >&, char const*)>
0x004017C0    mov    %rax,%rbx
0x004017C3    lea    0x7a857(%rip),%rdx        # 0x47c021
<std::piecewise_construct+1>
0x004017CA    mov    0x7e48f(%rip),%rcx        # 0x47fc60 <.refptr._ZSt4cout>
0x004017D1    callq  0x4624c0 <std::operator<< <std::char_traits<char>
>(std::basic_ostream<char, std::char_traits<char> >&, char const*)>
0x004017D6    mov    (%rax),%rax
0x004017D9    sub    $0x18,%rax
0x004017DD    mov    (%rax),%rax
0x004017E0    add    %rbx,%rax
0x004017E3    mov    %rax,%rcx
0x004017E6    callq  0x433f60 <std::basic_ios<char, std::char_traits<char>
>::operator!() const>
0x004017EB    movzbl %al,%eax
0x004017EE    mov    %eax,%ecx
>From gcc-bugs-return-427285-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Aug 03 20:21:21 2013
Return-Path: <gcc-bugs-return-427285-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9340 invoked by alias); 3 Aug 2013 20:21:21 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9279 invoked by uid 48); 3 Aug 2013 20:21:18 -0000
From: "tkoenig at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/58027] "Arithmetic overflow converting ..." in PARAMETER triggers an ICE
Date: Sat, 03 Aug 2013 20:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tkoenig at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-58027-4-wt7i8P7Q4Q@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58027-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58027-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-08/txt/msg00209.txt.bz2
Content-length: 903

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX027

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-08-03
     Ever confirmed|0                           |1

--- Comment #1 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
The problem is that the error raised in arith_error does not
get emitted, and the function gets passed to
gfc_conv_array_initializer, where it ICEs.

I played around this a little bit.  The problem is that
an obvious thing like issuing a gfc_error_now in
arith_error leads to regressions (like "unclassifiable statements")
in boz_4.f90.

Putting in a specific error for this case where the ICE occurs seems
hackish, to put it mildly.