[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #22 from Jakub Jelinek --- Confirmed fixed.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #21 from Jason Merrill --- Author: jason Date: Sun Jan 31 14:53:26 2016 New Revision: 233020 URL: https://gcc.gnu.org/viewcvs?rev=233020=gcc=rev Log: PR c++/68763 * tree.c (strip_typedefs) [FUNCTION_TYPE]: Avoid building a new function type if nothing is changing. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #20 from Jakub Jelinek --- Created attachment 37523 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37523=edit gcc6-pr68763.patch Updated non-working patch. Clearly adjusting the METHOD_TYPEs of some cdtors is a nightmare, giving up.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #18 from Jakub Jelinek --- Created attachment 37506 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37506=edit gcc6-pr68763.patch Partial fix. With the testcase reduction, I gave up, got only 4.7% reduction after 6 hours of 16 processes creduction. With this patch, the testcase compiles fine, but there is still modification in place - DEFARG_INSTANTIATIONS points to the particular TREE_LIST node containing the DEFAULT_ARG, while what we'd really need is let it point to the FUNCTION_DECLs whose TREE_TYPE we should modify similarly. Thoughts on that? I'll bootstrap/regtest this partial fix anyway.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #19 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #18) > Created attachment 37506 [details] > gcc6-pr68763.patch > > Partial fix. With the testcase reduction, I gave up, got only 4.7% > reduction after 6 hours of 16 processes creduction. > With this patch, the testcase compiles fine, but there is still modification > in place - DEFARG_INSTANTIATIONS points to the particular TREE_LIST node > containing the DEFAULT_ARG, while what we'd really need is let it point to > the FUNCTION_DECLs whose TREE_TYPE we should modify similarly. Thoughts on > that? > I'll bootstrap/regtest this partial fix anyway. The patch passed bootstrap, and during regtest regressed FAIL: g++.old-deja/g++.other/lookup15.C -std=c++14 (test for excess errors) Excess errors: /home/jakub/src/gcc/gcc/testsuite/g++.old-deja/g++.other/lookup15.C:33:9: error: call to 'mostd::mostd(int)' uses the default argument for paramete r 1, which is not yet defined FAIL: g++.old-deja/g++.mike/p4623.C -std=c++14 (test for excess errors) Excess errors: /home/jakub/src/gcc/gcc/testsuite/g++.old-deja/g++.mike/p4623.C:30:20: error: call to 'base1::base1(int)' uses the default argument for parameter 1 , which is not yet defined /home/jakub/src/gcc/gcc/testsuite/g++.old-deja/g++.mike/p4623.C:30:20: error: call to 'base2::base2(int)' uses the default argument for parameter 1 , which is not yet defined So, clearly there are more places than just the clones that expect the function/method type to be modified in place.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #15 from Jason Merrill --- Does anyone have a reduced testcase for this? Jakub, where are we modifying the TREE_PURPOSE after creating the METHOD_TYPE?
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #16 from Jakub Jelinek --- (In reply to Jason Merrill from comment #15) > Does anyone have a reduced testcase for this? I've started delta and creduce, but it is boost, so it will take a while (at 7.6MB so far). > Jakub, where are we modifying the TREE_PURPOSE after creating the > METHOD_TYPE? In cp_parser_late_parsing_default_args.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #17 from Markus Trippelsdorf --- (In reply to Jakub Jelinek from comment #16) > (In reply to Jason Merrill from comment #15) > > Does anyone have a reduced testcase for this? > > I've started delta and creduce, but it is boost, so it will take a while (at > 7.6MB so far). I think this issue somehow depends on the size of the testcase, thus making reduction impossible.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763
Jakub Jelinek changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek ---
Isn't this related or dup of PR66745 ?
As for the lvalue error, reduced testcase is:
template
int
foo (int max, int i, int radix, int c)
{
if (max < ((i *= radix) += c))
return i / radix;
return 0;
}
int
bar (int max, int i, int radix, int c)
{
return foo <0> (max, i, radix, c);
}
and that one started with r231640 (doesn't error out if foo is not a template).
Do we have a PR for that already, or shall I file a new one?
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763
--- Comment #11 from Markus Trippelsdorf ---
(In reply to Jakub Jelinek from comment #9)
> Isn't this related or dup of PR66745 ?
>
> As for the lvalue error, reduced testcase is:
> template
> int
> foo (int max, int i, int radix, int c)
> {
> if (max < ((i *= radix) += c))
> return i / radix;
> return 0;
> }
>
> int
> bar (int max, int i, int radix, int c)
> {
> return foo <0> (max, i, radix, c);
> }
> and that one started with r231640 (doesn't error out if foo is not a
> template).
> Do we have a PR for that already, or shall I file a new one?
I've opened PR68978 for this issue.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- Regarding the verify_unstripped_args ICE, what I see is that the ICE is while some parts of strip_typedefs check if recursion has changed anything and only build new trees if it changed, other parts rely on various other mechanisms. Say for POINTER_TYPE we use build_pointer_type and hope (the caching should hopefully ensure that it is fine) that we get the same pointer as we called it with if nothing changed, but say for METHOD_TYPE which is the problem here even if nothing really changed we still construct full new argument list etc. and then call build_method_type_directly (or build_function_type for FUNCTION_TYPE) and hope we get the same method type back. I'd say that is rather costly, depends on how often nothing really needs to be stripped, if that is often the case, we'd better just check first if anything changed and only in that case build the list. On the testcase for some reason build_method_type_directly returns a different type though.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #12 from Markus Trippelsdorf --- *** Bug 66745 has been marked as a duplicate of this bug. ***
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #14 from Jakub Jelinek --- Created attachment 37092 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37092=edit gcc6-pr68763.patch SO, I've tried to write a patch for this, and it passed bootstrap, but introduced: +FAIL: g++.dg/ext/attr-aligned01.C -std=c++11 (test for warnings, line 18) +FAIL: g++.dg/ext/attr-aligned01.C -std=c++11 (test for excess errors) +FAIL: g++.dg/ext/attr-aligned01.C -std=c++14 (test for warnings, line 18) +FAIL: g++.dg/ext/attr-aligned01.C -std=c++14 (test for excess errors) +FAIL: g++.dg/ext/attr-aligned01.C -std=c++98 (test for warnings, line 18) +FAIL: g++.dg/ext/attr-aligned01.C -std=c++98 (test for excess errors) +FAIL: 20_util/decay/requirements/alias_decl.cc (test for excess errors) +FAIL: 20_util/function/cons/57465.cc (test for excess errors) +UNRESOLVED: 20_util/function/cons/57465.cc compilation failed to produce executable regressions. The attr-aligned01.C seems to be from the ARRAY_TYPE hunk, for the others dunno. But I'm afraid I need to give up at this point.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #13 from Jakub Jelinek --- The reason for the weird behavior of build_method_type_directly are default args. We call this function with one argument list and return type etc., where one argument type in TYPE_ARG_TYPES has TREE_PURPOSE some DEFAULT_ARG. Then it is called again on another argument list and return type, but all the types are the same in there, the only difference is that the argument with default arg has different DEFAULT_ARG (and obviously the TREE_LIST nodes aren't the same either, but that is not the problem). TREE_PURPOSE of TYPE_ARG_TYPES nodes is ignored for hash value computation, the two nodes get the same hash value. But, type_list_equal compares even the TREE_PURPOSE and determines the two METHOD_TYPEs are not equal, so we create another METHOD_TYPE. Next, we in-place modify the TREE_PURPOSE in those two METHOD_TYPEs and they actually end up being the same (well, not pointer equality, but simple_cst_equal kind of equality). So, because of the in-place modifications of the default argument, we now have two different METHOD_TYPEs that compare equal and have the same hash value in the hash table, and we get pretty randomly chosen one of those. Now, the question is, do we use hash tables for the FUNCTION_TYPE/METHOD_TYPE just as a way to decrease compiler memory usage (in that case what we do is probably fine), or do we rely on it for other reasons, so that say pointer equality can be used for the "same" function types (strip_typedefs and its caller clearly relies on that, but perhaps that is a bug). If we rely on it for other reasons, then I'd be afraid we couldn't modify the default arguments in place, so we'd need to include the TREE_PURPOSE in the hash value (optionally) and build_method_type_directly again after we change the TREE_PURPOSE, so in the end such change could result in more compiler memory being used for the function/method types.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #8 from Markus Trippelsdorf --- There is also this bogus error, before the ICE: In file included from /usr/include/boost/xpressive/match_results.hpp:59:0, from /usr/include/boost/xpressive/detail/core/access.hpp:21, from /usr/include/boost/xpressive/detail/core/state.hpp:18, from /usr/include/boost/xpressive/detail/core/matcher/alternate_end_matcher.hpp:20, from /usr/include/boost/xpressive/detail/core/matchers.hpp:17, from /usr/include/boost/xpressive/regex_primitives.hpp:22, from /usr/include/boost/xpressive/xpressive_static.hpp:24, from /home/dcb/rpmbuild/BUILD/ledger-720c03b139d251c53f9deef491f5953e2fdb97ca/system.hh:217, from /home/dcb/rpmbuild/BUILD/ledger-720c03b139d251c53f9deef491f5953e2fdb97ca/src/py_account.cc:32: /usr/include/boost/xpressive/detail/utility/algorithm.hpp: In function ‘int boost::xpressive::detail::toi(InIter&, InIter, const Traits&, int, int)’: /usr/include/boost/xpressive/detail/utility/algorithm.hpp:67:28: error: lvalue required as left operand of assignment if(max < ((i *= radix) += c)) ^
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763
Marek Polacek changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|WORKSFORME |---
--- Comment #7 from Marek Polacek ---
Yeah, that ICEs.
1123 static void
1124 verify_unstripped_args (tree args)
1125 {
1126 ++processing_template_decl;
1127 if (!any_dependent_template_arguments_p (args))
1128 {
1129 tree inner = INNERMOST_TEMPLATE_ARGS (args);
1130 for (int i = 0; i < TREE_VEC_LENGTH (inner); ++i)
1131 {
1132 tree arg = TREE_VEC_ELT (inner, i);
1133 if (TREE_CODE (arg) == TEMPLATE_DECL)
1134 /* OK */;
1135 else if (TYPE_P (arg))
1136 gcc_assert (strip_typedefs (arg, NULL) == arg);
strip_typedefs (arg, NULL) is:
struct
{
const struct details_t & account_t:: (const struct account_t *, bool)
* __pfn;
long int __delta;
}
and arg is:
struct
{
const struct details_t & account_t:: (const struct account_t *, bool)
* __pfn;
long int __delta;
}
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #6 from David Binderman --- Created attachment 37043 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37043=edit C++ source code, compressed with xz I can reproduce the problem with the attached C++ source code. gcc trunk from 20151214.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 Markus Trippelsdorf changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Markus Trippelsdorf --- Fortunately I cannot reproduce the issue anymore. Closing.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-10 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Marek Polacek --- I think we're waiting for a testcase then.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #4 from Markus Trippelsdorf --- Well, if you want to reproduce the issue: % wget https://raw.githubusercontent.com/boostorg/regression/develop/testing/src/run.py % python run.py --runner "trippels-powerpc64le-gcc-6.0" --toolsets=gcc "--bjam-options=-j60 toolset=gcc variant=release debug-symbols=off" ... % cat results/bjam.log | grep "nternal compi" ../boost/type_traits/is_class.hpp:105:27: internal compiler error: in verify_unstripped_args, at cp/pt.c:1136
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Try to preprocess with -fdirectives-only, and compile the result as *.cpp/*.C rather than *.ii? If that triggers the ICE, you could attach the result here, and/or reduce.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #2 from Markus Trippelsdorf --- (In reply to Jakub Jelinek from comment #1) > Try to preprocess with -fdirectives-only, and compile the result as > *.cpp/*.C rather than *.ii? If that triggers the ICE, you could attach the > result here, and/or reduce. Thanks. Unfortunately -fdirectives-only doesn't help.
