public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/95468] New: ICE in expression sfinae
@ 2020-06-01 19:57 kab at acm dot org
2020-06-02 5:56 ` [Bug c++/95468] " marxin at gcc dot gnu.org
` (10 more replies)
0 siblings, 11 replies; 12+ messages in thread
From: kab at acm dot org @ 2020-06-01 19:57 UTC (permalink / raw)
To: gcc-bugs
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 -----
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95468] ICE in expression sfinae
2020-06-01 19:57 [Bug c++/95468] New: ICE in expression sfinae kab at acm dot org
@ 2020-06-02 5:56 ` marxin at gcc dot gnu.org
2020-06-03 1:09 ` kab at acm dot org
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-06-02 5:56 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95468] ICE in expression sfinae
2020-06-01 19:57 [Bug c++/95468] New: ICE in expression sfinae kab at acm dot org
2020-06-02 5:56 ` [Bug c++/95468] " marxin at gcc dot gnu.org
@ 2020-06-03 1:09 ` kab at acm dot org
2020-06-03 15:23 ` [Bug c++/95468] [8/9/10/11 Regression] " ppalka at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: kab at acm dot org @ 2020-06-03 1:09 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95468] [8/9/10/11 Regression] ICE in expression sfinae
2020-06-01 19:57 [Bug c++/95468] New: ICE in expression sfinae kab at acm dot org
2020-06-02 5:56 ` [Bug c++/95468] " marxin at gcc dot gnu.org
2020-06-03 1:09 ` kab at acm dot org
@ 2020-06-03 15:23 ` ppalka at gcc dot gnu.org
2020-06-03 15:48 ` ppalka at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ppalka at gcc dot gnu.org @ 2020-06-03 15:23 UTC (permalink / raw)
To: gcc-bugs
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>();
}
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95468] [8/9/10/11 Regression] ICE in expression sfinae
2020-06-01 19:57 [Bug c++/95468] New: ICE in expression sfinae kab at acm dot org
` (2 preceding siblings ...)
2020-06-03 15:23 ` [Bug c++/95468] [8/9/10/11 Regression] " ppalka at gcc dot gnu.org
@ 2020-06-03 15:48 ` ppalka at gcc dot gnu.org
2021-01-14 8:57 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ppalka at gcc dot gnu.org @ 2020-06-03 15:48 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95468] [8/9/10/11 Regression] ICE in expression sfinae
2020-06-01 19:57 [Bug c++/95468] New: ICE in expression sfinae kab at acm dot org
` (3 preceding siblings ...)
2020-06-03 15:48 ` ppalka at gcc dot gnu.org
@ 2021-01-14 8:57 ` rguenth at gcc dot gnu.org
2021-02-12 23:37 ` ppalka at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-14 8:57 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95468] [8/9/10/11 Regression] ICE in expression sfinae
2020-06-01 19:57 [Bug c++/95468] New: ICE in expression sfinae kab at acm dot org
` (4 preceding siblings ...)
2021-01-14 8:57 ` rguenth at gcc dot gnu.org
@ 2021-02-12 23:37 ` ppalka at gcc dot gnu.org
2021-02-23 14:40 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-02-12 23:37 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95468] [8/9/10/11 Regression] ICE in expression sfinae
2020-06-01 19:57 [Bug c++/95468] New: ICE in expression sfinae kab at acm dot org
` (5 preceding siblings ...)
2021-02-12 23:37 ` ppalka at gcc dot gnu.org
@ 2021-02-23 14:40 ` cvs-commit at gcc dot gnu.org
2021-02-23 14:42 ` [Bug c++/95468] [8/9/10 " ppalka at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-02-23 14:40 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95468] [8/9/10 Regression] ICE in expression sfinae
2020-06-01 19:57 [Bug c++/95468] New: ICE in expression sfinae kab at acm dot org
` (6 preceding siblings ...)
2021-02-23 14:40 ` cvs-commit at gcc dot gnu.org
@ 2021-02-23 14:42 ` ppalka at gcc dot gnu.org
2021-03-31 12:33 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-02-23 14:42 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95468] [8/9/10 Regression] ICE in expression sfinae
2020-06-01 19:57 [Bug c++/95468] New: ICE in expression sfinae kab at acm dot org
` (7 preceding siblings ...)
2021-02-23 14:42 ` [Bug c++/95468] [8/9/10 " ppalka at gcc dot gnu.org
@ 2021-03-31 12:33 ` cvs-commit at gcc dot gnu.org
2021-04-21 21:09 ` [Bug c++/95468] [8/9 " cvs-commit at gcc dot gnu.org
2021-05-14 13:58 ` [Bug c++/95468] [8 " jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-03-31 12:33 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95468] [8/9 Regression] ICE in expression sfinae
2020-06-01 19:57 [Bug c++/95468] New: ICE in expression sfinae kab at acm dot org
` (8 preceding siblings ...)
2021-03-31 12:33 ` cvs-commit at gcc dot gnu.org
@ 2021-04-21 21:09 ` cvs-commit at gcc dot gnu.org
2021-05-14 13:58 ` [Bug c++/95468] [8 " jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-21 21:09 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/95468] [8 Regression] ICE in expression sfinae
2020-06-01 19:57 [Bug c++/95468] New: ICE in expression sfinae kab at acm dot org
` (9 preceding siblings ...)
2021-04-21 21:09 ` [Bug c++/95468] [8/9 " cvs-commit at gcc dot gnu.org
@ 2021-05-14 13:58 ` jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-05-14 13:58 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-05-14 13:58 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-01 19:57 [Bug c++/95468] New: ICE in expression sfinae kab at acm dot org
2020-06-02 5:56 ` [Bug c++/95468] " marxin at gcc dot gnu.org
2020-06-03 1:09 ` kab at acm dot org
2020-06-03 15:23 ` [Bug c++/95468] [8/9/10/11 Regression] " ppalka at gcc dot gnu.org
2020-06-03 15:48 ` ppalka at gcc dot gnu.org
2021-01-14 8:57 ` rguenth at gcc dot gnu.org
2021-02-12 23:37 ` ppalka at gcc dot gnu.org
2021-02-23 14:40 ` cvs-commit at gcc dot gnu.org
2021-02-23 14:42 ` [Bug c++/95468] [8/9/10 " ppalka at gcc dot gnu.org
2021-03-31 12:33 ` cvs-commit at gcc dot gnu.org
2021-04-21 21:09 ` [Bug c++/95468] [8/9 " cvs-commit at gcc dot gnu.org
2021-05-14 13:58 ` [Bug c++/95468] [8 " jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).