[Bug c++/95468] New: ICE in expression sfinae

[Bug c++/95468] New: ICE in expression sfinae

[kab at acm dot org]

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

            Bug ID: 95468
           Summary: ICE in expression sfinae
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kab at acm dot org
  Target Milestone: ---

The code below gets ICE with gcc9.2 and gcc7.5 (the versions I have immediately
available to test with).

The error message is:
internal compiler error: unexpected expression '(bool)(true)' of kind cast_expr

To test:
g++ -c -std=c++11 ice-expr-sfinae.cpp

Strangely, using a namespace scope function template instead of a static member
function template works fine.  To demonstrate that, compile with
-DTRIGGER_ICE=0.

----- ice-expr-sfinae.cpp -----

#include <type_traits>

#ifndef TRIGGER_ICE
#define TRIGGER_ICE 1
#endif

#if TRIGGER_ICE

struct slip {
  template<bool C> static constexpr bool condition() { return C; }
};

template<typename std::enable_if<slip::condition<bool(true)>(), int>::type = 0>
static bool dispatch() { return true; }

bool test() {
  return dispatch();
}

#else

// No ICE if the condition function is at namespace scope.

template<bool C> static constexpr bool noslip_condition() { return C; }

template<typename std::enable_if<noslip_condition<bool(true)>(), int>::type =
0>
static bool dispatch() { return true; }

bool test() {
  return dispatch();
}

#endif

----- end of file -----

[Bug c++/95468] ICE in expression sfinae

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
           Keywords|                            |ice-on-invalid-code
   Last reconfirmed|                            |2020-06-02

[Bug c++/95468] ICE in expression sfinae

[kab at acm dot org]

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

--- Comment #1 from kab at acm dot org ---
This was labeled as "ice-on-invalid-code".  Am I missing something?  I don't
see anything invalid here.

[Bug c++/95468] [8/9/10/11 Regression] ICE in expression sfinae

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |ppalka at gcc dot gnu.org
            Summary|ICE in expression sfinae    |[8/9/10/11 Regression] ICE
                   |                            |in expression sfinae
           Keywords|ice-on-invalid-code         |ice-on-valid-code
   Target Milestone|---                         |8.5

--- Comment #2 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to kab from comment #1)
> This was labeled as "ice-on-invalid-code".  Am I missing something?  I don't
> see anything invalid here.

I just now adjusted the label to be "ice-on-valid-code" instead.

This seems to be a regression relative to GCC 4.8, which compiles the testcase
successfully (with -std=c++11).  We began ICEing on the testcase starting with
r0-122271.

Here is a reduced testcase:

template <int> struct a { };

struct c {
  template <int d> static constexpr bool condition() { return d; }
};

template<typename>
void foo() {
  using A = a<c::condition<bool(true)>()>;
}

void bar() {
  foo<int>();
}

[Bug c++/95468] [8/9/10/11 Regression] ICE in expression sfinae

[ppalka at gcc dot gnu.org]

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

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
The reason we fail to compile the testcase when 'condition' is at class scope
instead of at namespace scope is because in the former case, the template
argument 'c::condition<bool(true)>' is a CALL_EXPR to a BASELINK, and when
doing instantiate_non_dependent_expr_internal on this CALL_EXPR, we don't
semantically process the template argument 'bool(true)' within BASELINK because
we never call tsubst_baselink because tsubst_copy exits early when args is
NULL_TREE.

We don't have this problem in the latter case where 'condition' is at namespace
scope, because then the template argument 'condition<bool(true)>' is a
CALL_EXPR to a TEMPLATE_ID_EXPR, and TEMPLATE_ID_EXPRs are handled directly
from tsubst_copy_and_build which doesn't do an early exit when args is
NULL_TREE.

A potential untested fix therefore is to also handle BASELINK directly from
tsubst_copy_and_build:

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c                                          
index d7f61289621..e15fca54823 100644                                           
--- a/gcc/cp/pt.c                                                               
+++ b/gcc/cp/pt.c                                                               
@@ -19472,6 +19472,11 @@ tsubst_copy_and_build (tree t,                         
     case SCOPE_REF:                                                            
       RETURN (tsubst_qualified_id (t, args, complain, in_decl, /*done=*/true,  
                                  /*address_p=*/false));                        
+                                                                               
+    case BASELINK:                                                             
+      RETURN (tsubst_baselink (t, current_nonlambda_class_type (),             
+                              args, complain, in_decl));                       
+                                                                               
     case ARRAY_REF:                                                            
       op1 = tsubst_non_call_postfix_expression (TREE_OPERAND (t, 0),           
                                                args, complain, in_decl);       

Ideally we might want two versions of tsubst_baselink, one that does template
argument substitution and another than additionally performs semantic
processing?

[Bug c++/95468] [8/9/10/11 Regression] ICE in expression sfinae

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
            Version|unknown                     |9.3.0

[Bug c++/95468] [8/9/10/11 Regression] ICE in expression sfinae

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org

[Bug c++/95468] [8/9/10/11 Regression] ICE in expression sfinae

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:5bd7afb71fca3a5a6e9f8586d86903bae1849193

commit r11-7345-g5bd7afb71fca3a5a6e9f8586d86903bae1849193
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Feb 23 09:40:09 2021 -0500

    c++: Fix folding of non-dependent BASELINKs [PR95468]

    Here, the problem ultimately seems to be that tsubst_copy_and_build,
    when called with empty args as we do during non-dependent expression
    folding, doesn't touch BASELINKs at all: it delegates to tsubst_copy
    which then immediately exits early due to the empty args.  This means
    that the CAST_EXPR int(1) in the BASELINK A::condition<int(1)> never
    gets folded (as part of folding of the overall CALL_EXPR), which later
    causes us to crash when performing overload resolution of the rebuilt
    CALL_EXPR (which is still in terms of this templated BASELINK).

    This doesn't happen when condition() is a namespace-scope function
    because then condition<int(1)> is represented by a TEMPLATE_ID_EXPR
    rather than by a BASELINK, which does get handled directly from
    tsubst_copy_and_build.

    This patch fixes this issue by having tsubst_copy_and_build handle
    BASELINK directly rather than delegating to tsubst_copy, so that it
    processes BASELINKs even when args is empty.

    gcc/cp/ChangeLog:

            PR c++/95468
            * pt.c (tsubst_copy_and_build) <case BASELINK>: New case, copied
            over from tsubst_copy.

    gcc/testsuite/ChangeLog:

            PR c++/95468
            * g++.dg/template/non-dependent15.C: New test.

[Bug c++/95468] [8/9/10 Regression] ICE in expression sfinae

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[8/9/10/11 Regression] ICE  |[8/9/10 Regression] ICE in
                   |in expression sfinae        |expression sfinae

--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed for GCC 11 so far.

[Bug c++/95468] [8/9/10 Regression] ICE in expression sfinae

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:78e6c55b0d0d2d49f489c581cf8d5a8125b28563

commit r10-9636-g78e6c55b0d0d2d49f489c581cf8d5a8125b28563
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Feb 23 09:40:09 2021 -0500

    c++: Fix folding of non-dependent BASELINKs [PR95468]

    Here, the problem ultimately seems to be that tsubst_copy_and_build,
    when called with empty args as we do during non-dependent expression
    folding, doesn't touch BASELINKs at all: it delegates to tsubst_copy
    which then immediately exits early due to the empty args.  This means
    that the CAST_EXPR int(1) in the BASELINK A::condition<int(1)> never
    gets folded (as part of folding of the overall CALL_EXPR), which later
    causes us to crash when performing overload resolution of the rebuilt
    CALL_EXPR (which is still in terms of this templated BASELINK).

    This doesn't happen when condition() is a namespace-scope function
    because then condition<int(1)> is represented by a TEMPLATE_ID_EXPR
    rather than by a BASELINK, which does get handled directly from
    tsubst_copy_and_build.

    This patch fixes this issue by having tsubst_copy_and_build handle
    BASELINK directly rather than delegating to tsubst_copy, so that it
    processes BASELINKs even when args is empty.

    gcc/cp/ChangeLog:

            PR c++/95468
            * pt.c (tsubst_copy_and_build) <case BASELINK>: New case, copied
            over from tsubst_copy.

    gcc/testsuite/ChangeLog:

            PR c++/95468
            * g++.dg/template/non-dependent15.C: New test.

    (cherry picked from commit 5bd7afb71fca3a5a6e9f8586d86903bae1849193)

[Bug c++/95468] [8/9 Regression] ICE in expression sfinae

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:1b265d910f27743dc3ea8e4fde6c292df220fb9f

commit r9-9456-g1b265d910f27743dc3ea8e4fde6c292df220fb9f
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Feb 23 09:40:09 2021 -0500

    c++: Fix folding of non-dependent BASELINKs [PR95468]

    Here, the problem ultimately seems to be that tsubst_copy_and_build,
    when called with empty args as we do during non-dependent expression
    folding, doesn't touch BASELINKs at all: it delegates to tsubst_copy
    which then immediately exits early due to the empty args.  This means
    that the CAST_EXPR int(1) in the BASELINK A::condition<int(1)> never
    gets folded (as part of folding of the overall CALL_EXPR), which later
    causes us to crash when performing overload resolution of the rebuilt
    CALL_EXPR (which is still in terms of this templated BASELINK).

    This doesn't happen when condition() is a namespace-scope function
    because then condition<int(1)> is represented by a TEMPLATE_ID_EXPR
    rather than by a BASELINK, which does get handled directly from
    tsubst_copy_and_build.

    This patch fixes this issue by having tsubst_copy_and_build handle
    BASELINK directly rather than delegating to tsubst_copy, so that it
    processes BASELINKs even when args is empty.

    gcc/cp/ChangeLog:

            PR c++/95468
            * pt.c (tsubst_copy_and_build) <case BASELINK>: New case, copied
            over from tsubst_copy.

    gcc/testsuite/ChangeLog:

            PR c++/95468
            * g++.dg/template/non-dependent15.C: New test.

    (cherry picked from commit 5bd7afb71fca3a5a6e9f8586d86903bae1849193)

[Bug c++/95468] [8 Regression] ICE in expression sfinae

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4
                 CC|                            |jakub at gcc dot gnu.org
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The GCC 8 branch is being closed, fixed in GCC 9.4.