[Bug c++/56039] New: ICE in iterative_hash_template_arg, at cp/pt.c:1606

[Bug c++/56039] New: ICE in iterative_hash_template_arg, at cp/pt.c:1606

[hstong at ca dot ibm.com]

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

             Bug #: 56039
           Summary: ICE in iterative_hash_template_arg, at cp/pt.c:1606
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hstong@ca.ibm.com
              Host: powerpc64-suse-linux
            Target: powerpc64-suse-linux
             Build: powerpc64-suse-linux


I am working on a code base which implements type traits using SFINAE,
and when I try it with GCC, I get the reported ICE.

The code uses C++11 lambda expressions in a constant expression context for
the SFINAE. As far as I can tell, SFINAE should apply since the lambda occurs
lexically within the immediate context for the substitution.

I have extracted a functional portion of the code base into a standalone file
(see below).


### Self-contained source:$ cat lambdaSupportedTraits.cc
template <bool> struct BoolSink { typedef void type; };

template <typename T, typename U>
struct AddRvalueReferenceImpl { typedef T type; };

template <typename T>
struct AddRvalueReferenceImpl<T, typename BoolSink<false &&
      [] {
         extern T &&tref;
      }>::type> {
   typedef T &&type;
};

template <typename T>
struct AddRvalueReference : AddRvalueReferenceImpl<T, void> { };

namespace ImplHelpers {
   template <typename T>
   typename AddRvalueReference<T>::type create(void) { }
}

template <typename T, typename U, typename ...Args>
struct IsConstructibleImpl { enum { value = 0 }; };

template <typename T, typename ...Args>
struct IsConstructibleImpl<T, typename BoolSink<false &&
      [] {
         T t( ::ImplHelpers::create<Args>() ...);
      }>::type, Args ...> {
   enum { value = 1 };
};

template <typename T, typename ...Args>
struct IsConstructible : IsConstructibleImpl<T, void, Args ...> { };

struct DestroyMe {
   ~DestroyMe() = delete;
};

static_assert(+IsConstructible<int>::value, "error");
static_assert(!IsConstructible<void>::value, "error");
static_assert(+IsConstructible<int [1]>::value, "error");
static_assert(!IsConstructible<DestroyMe>::value, "error");
static_assert(!IsConstructible<int *, char *>::value, "error");

static_assert(+IsConstructible<int &&, int>::value, "error");
static_assert(!IsConstructible<int &&, int &>::value, "error");
static_assert(+IsConstructible<int &&, int &&>::value, "error");


### Compiler output:$ g++-4.7 -std=c++11 lambdaSupportedTraits.cc -c
lambdaSupportedTraits.cc:10:8: internal compiler error: in
iterative_hash_template_arg, at cp/pt.c:1606
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugs.opensuse.org/> for instructions.


### g++ -v output:$ g++-4.7 -v
Using built-in specs.
COLLECT_GCC=/GCC_INSTALL/bin/g++-4.7
COLLECT_LTO_WRAPPER=/GCC_INSTALL/libexec/gcc/powerpc64-suse-linux/4.7.2/lto-wrapper
Target: powerpc64-suse-linux
Configured with: ../GCC_SOURCE/gcc-4.7.2/configure --prefix=/GCC_INSTALL
--enable-languages=c,c++,fortran --enable-checking=release --enable-ssp
--disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.7
--enable-linux-futex --without-system-libunwind --with-cpu=power4
--enable-secureplt --with-long-double-128 --build=powerpc64-suse-linux
--with-mpc=/GCC_INSTALL/mpc1.0.1 --with-mpfr=/GCC_INSTALL/mpfr3.1.1
--with-gmp=/GCC_INSTALL/gmp5.1
--with-zlib-include=/usr/src/linux-3.0.13-0.27/include/linux
--with-zlib-lib=/lib
Thread model: posix
gcc version 4.7.2 (SUSE Linux)

[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606

[daniel.kruegler at googlemail dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler at
                   |                            |googlemail dot com

--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2013-01-19 12:07:54 UTC ---
This code surely is not valid. Lambda expressions are restricted and they are
neither allowed in constant expressions (5.19 p2 b8) nor can they appear in an
unevaluated operand (5.1.2 p2).

[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606

[hstong at ca dot ibm.com]

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

--- Comment #2 from Hubert Tong <hstong at ca dot ibm.com> 2013-01-19 16:38:31 UTC ---
(In reply to comment #1)
re: 5.19 p2 b8

5.19 p2 (before the referenced bullet list) reads:
..., but subexpressions of logical AND (5.14), logical OR (5.15) and
conditional (5.16) operations that are not evaluated are not considered...

re: 5.1.2 p2
The use of the lambda expression in the code snippet does not appear as the
operand of either typeid, sizeof, noexcept or decltype.

[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2013-01-19 17:20:21 UTC ---
(In reply to comment #2)
You make a good point, but my remaining argument would focus on the fact that
the expression

false && [](){}

is always invalid because it attempts to combine a boolean expression and a
void expression (Not covered by 5.14). This is presumably easy to fix by
ensuring that the lambda expressions return a boolean value. This code still
not accepted by gcc 4.8 nor by clang 3.2. While you may try to insist that it
should, this looks like a potential core language issue to me. I'm forwarding
this problem to CWG. I don't think that any compiler change will be done before
that decision, because the CWG group intentionally tried to forbid lambda
expressions within template declarations because of some known technical
problems.

[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606

[hstong at ca dot ibm.com]

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

--- Comment #4 from Hubert Tong <hstong at ca dot ibm.com> 2013-01-19 20:10:59 UTC ---
(In reply to comment #3)
I seem to find that the expression in question
> 
> false && [](){}
> 
is valid because there is a implicit conversion sequence consisting of a
user-defined conversion to pointer-to-function followed by a conversion to bool
from the pointer type.

> I'm forwarding this problem to CWG. I don't think that any compiler change
> will be done before that decision, because the CWG group intentionally tried
> to forbid lambda expressions within template declarations because of some
> known technical problems.
Sure. While I may not have a full appreciation of the difficultly for having an
implementation which works with this, I am aware that there is at least the
issue with mangling hinted at by the note in 14.5.6.1 [temp.over.link] p7 with
regards to the linking of equivalent declarations.

I am not sure, though, that implementation difficulty is a good reason to
remove the ability to have SFINAE applied on statements such as the declaration
in the IsConstructibleImpl specialization above.

[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606

[daniel.kruegler at googlemail dot com]

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

--- Comment #5 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2013-01-19 20:20:43 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> I seem to find that the expression in question
> > 
> > false && [](){}
> > 
> is valid because there is a implicit conversion sequence consisting of a
> user-defined conversion to pointer-to-function followed by a conversion to bool
> from the pointer type.

I agree, I missed the existence of the conversion function when arguing about
the expression. 

Let me add that for exactly the use-case you presented here
(std::is_constructible) I would have loved to have it defined in terms of a
lambda expression. But I guess that this is not what will be decided on that
guess (but maybe I'm just biased)

[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606

[daniel.kruegler at googlemail dot com]

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

--- Comment #6 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2013-01-20 12:27:20 UTC ---
(In reply to comment #0)
> The code uses C++11 lambda expressions in a constant expression context for
> the SFINAE. As far as I can tell, SFINAE should apply since the lambda occurs
> lexically within the immediate context for the substitution.

I wonder why you think this would belong to the "immediate context". Actually
it seems to me as if the instantiation of the body of a lambda expression is
similarly non-immediate as the instantiation of a class template.

[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606

[hstong at ca dot ibm.com]

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

--- Comment #7 from Hubert Tong <hstong at ca dot ibm.com> 2013-01-20 16:45:13 UTC ---
(In reply to comment #6)
> I wonder why you think this would belong to the "immediate context". Actually
> it seems to me as if the instantiation of the body of a lambda expression is
> similarly non-immediate as the instantiation of a class template.

The body of a closure under N3290, forms a unique, singular "instance" which
lexically eminates from the source location where the lambda expression occurs
(by definition) and cannot be "instantiated" except by the presence of the
lambda expression itself.

That is, whether the "body" of the lambda expression is valid or not valid
is not affected by unknowns such as what types it would be instantiated with or
what names would be found if the lookup was moved to a different context.

[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606

[hstong at ca dot ibm.com]

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

--- Comment #8 from Hubert Tong <hstong at ca dot ibm.com> 2013-01-20 17:50:50 UTC ---
(In reply to comment #7)
> That is, whether the "body" of the lambda expression is valid or not valid
> is not affected by unknowns such as what types it would be instantiated with or
> what names would be found if the lookup was moved to a different context.

I am referring to the case where the lambda is not inside a template
declaration in the above. For the case where the lambda is in a template
declaration, I  believe that the properties I mentioned in comment #7 translate
to the body of the lambda being within the "immediate context" of the
instantiation when an instantiation of the enclosing template occurs.

[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-valid-code           |ice-on-invalid-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-03-11
                 CC|                            |jason at gcc dot gnu.org
         AssignedTo|unassigned at gcc dot       |jason at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #9 from Jason Merrill <jason at gcc dot gnu.org> 2013-03-11 20:35:36 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> re: 5.19 p2 b8
> 
> 5.19 p2 (before the referenced bullet list) reads:
> ..., but subexpressions of logical AND (5.14), logical OR (5.15) and
> conditional (5.16) operations that are not evaluated are not considered...

Looks like a defect in the wording.  The intent is that a lambda body must not
appear in SFINAE context.

[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill <jason at gcc dot gnu.org> 2013-03-17 02:38:49 UTC ---
Author: jason
Date: Sun Mar 17 02:38:35 2013
New Revision: 196741

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196741
Log:
    PR c++/56039
    * tree.c (strip_typedefs_expr): Complain about lambda, don't abort.

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-sfinae1.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/tree.c

[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.8.1

--- Comment #11 from Jason Merrill <jason at gcc dot gnu.org> 2013-03-23 19:25:59 UTC ---
ICE changed to error in 4.8.1.