[Bug c++/16564] g++ seems to go into an infinite loop after errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #23 from Paolo Carlini paolo.carlini at oracle dot com --- Manuel, I'm looking into this. I think it makes sense to also submit the testcase updates, or at least provide a breakdown. I'm working on that.
[Bug c++/16564] g++ seems to go into an infinite loop after errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #24 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #23) Manuel, I'm looking into this. I think it makes sense to also submit the testcase updates, or at least provide a breakdown. I'm working on that. Thanks! I didn't do it because of lack of time and not being sure if Jason will actually accept the patch. But I think I covered all cases in my email. They should be fairly automatic.
[Bug c++/16564] g++ seems to go into an infinite loop after errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #25 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue Sep 30 17:10:35 2014 New Revision: 215733 URL: https://gcc.gnu.org/viewcvs?rev=215733root=gccview=rev Log: cp/ 2014-09-30 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/16564 * error.c (print_instantiation_context): Delete. * typeck2.c (build_x_arrow): Record location when pushing template instantiation. * pt.c (push_tinst_level): Make it a wrapper around ... (push_tinst_level_loc): ... this. New function. Make excessive template instantiation depth a fatal error. Record location. Use bool as return type. (instantiate_pending_templates): Make excessive template instantiation depth a fatal error. (problematic_instantiation_changed): Use bool as return type. * cp-tree.h (print_instantiation_context): Delete. (push_tinst_level): Update declaration. (problematic_instantiation_changed): Likewise. (push_tinst_level_loc): New. testsuite/ 2014-09-30 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/16564 * lib/gcc.exp: Accept fatal error: as error prefix. * lib/g++.exp: Likewise. * lib/obj-c++.exp: Likewise. * lib/objc.exp: Likewise. * g++.dg/template/pr16564.C: New test. 2014-09-30 Paolo Carlini paolo.carl...@oracle.com PR c++/16564 * g++.dg/cpp0x/decltype26.C: Adjust. * g++.dg/cpp0x/decltype28.C: Likewise. * g++.dg/cpp0x/decltype29.C: Likewise. * g++.dg/cpp0x/decltype32.C: Likewise. * g++.dg/cpp0x/enum11.C: Likewise. * g++.dg/template/arrow1.C: Likewise. * g++.dg/template/pr23510.C: Likewise. * g++.dg/template/recurse.C: Likewise. * g++.dg/template/recurse2.C: Likewise. * g++.dg/template/vtable2.C: Likewise. * g++.old-deja/g++.pt/infinite1.C: Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/error.c trunk/gcc/cp/pt.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/decltype26.C trunk/gcc/testsuite/g++.dg/cpp0x/decltype28.C trunk/gcc/testsuite/g++.dg/cpp0x/decltype29.C trunk/gcc/testsuite/g++.dg/cpp0x/decltype32.C trunk/gcc/testsuite/g++.dg/cpp0x/enum11.C trunk/gcc/testsuite/g++.dg/template/arrow1.C trunk/gcc/testsuite/g++.dg/template/pr23510.C trunk/gcc/testsuite/g++.dg/template/recurse.C trunk/gcc/testsuite/g++.dg/template/recurse2.C trunk/gcc/testsuite/g++.dg/template/vtable2.C trunk/gcc/testsuite/g++.old-deja/g++.pt/infinite1.C trunk/gcc/testsuite/lib/g++.exp trunk/gcc/testsuite/lib/gcc.exp trunk/gcc/testsuite/lib/obj-c++.exp trunk/gcc/testsuite/lib/objc.exp
[Bug c++/16564] g++ seems to go into an infinite loop after errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #26 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue Sep 30 17:11:38 2014 New Revision: 215734 URL: https://gcc.gnu.org/viewcvs?rev=215734root=gccview=rev Log: cp/ 2014-09-30 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/16564 * error.c (print_instantiation_context): Delete. * typeck2.c (build_x_arrow): Record location when pushing template instantiation. * pt.c (push_tinst_level): Make it a wrapper around ... (push_tinst_level_loc): ... this. New function. Make excessive template instantiation depth a fatal error. Record location. Use bool as return type. (instantiate_pending_templates): Make excessive template instantiation depth a fatal error. (problematic_instantiation_changed): Use bool as return type. * cp-tree.h (print_instantiation_context): Delete. (push_tinst_level): Update declaration. (problematic_instantiation_changed): Likewise. (push_tinst_level_loc): New. testsuite/ 2014-09-30 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/16564 * lib/gcc.exp: Accept fatal error: as error prefix. * lib/g++.exp: Likewise. * lib/obj-c++.exp: Likewise. * lib/objc.exp: Likewise. * g++.dg/template/pr16564.C: New test. 2014-09-30 Paolo Carlini paolo.carl...@oracle.com PR c++/16564 * g++.dg/cpp0x/decltype26.C: Adjust. * g++.dg/cpp0x/decltype28.C: Likewise. * g++.dg/cpp0x/decltype29.C: Likewise. * g++.dg/cpp0x/decltype32.C: Likewise. * g++.dg/cpp0x/enum11.C: Likewise. * g++.dg/template/arrow1.C: Likewise. * g++.dg/template/pr23510.C: Likewise. * g++.dg/template/recurse.C: Likewise. * g++.dg/template/recurse2.C: Likewise. * g++.dg/template/vtable2.C: Likewise. * g++.old-deja/g++.pt/infinite1.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/template/pr16564.C
[Bug c++/16564] g++ seems to go into an infinite loop after errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #27 from Paolo Carlini paolo.carlini at oracle dot com --- Can we close the bug?
[Bug c++/16564] g++ seems to go into an infinite loop after errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #28 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #27) Can we close the bug? There is still the issue that we print: x.ii:5: instantiated from `SAAAint but that is PR43113, so I think yes, we can close this. Congratulations!
[Bug c++/16564] g++ seems to go into an infinite loop after errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|paolo.carlini at oracle dot com| Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #29 from Paolo Carlini paolo.carlini at oracle dot com --- Ok, great.
[Bug c++/16564] g++ seems to go into an infinite loop after errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #22 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Volker Reichelt from comment #18) The first error message about exceeding the maximum template instantiation depth appears rather quickly. So maybe we could make the first error message a fatal one to avoid further processing of potentially bogus nested classes. This is a patch doing exactly that: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01709.html However, I probably won't have time until the Christmas holidays to work on it, so please anyone feel free to take it and get it reviewed and applied. Thanks!
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||dodji at gcc dot gnu.org --- Comment #21 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Still, making the error: template instantiation depth exceeds maximum a fatal error seems a good idea to me. One issue face when implementing this is that the instantiation context is printed after the whole error is given: if (TREE_CODE (d) == TREE_LIST) error (template instantiation depth exceeds maximum of %d (use -ftemplate-depth= to increase the maximum) substituting %qS, max_tinst_depth, d); else error (template instantiation depth exceeds maximum of %d (use -ftemplate-depth= to increase the maximum) instantiating %qD, max_tinst_depth, d); print_instantiation_context (); If we convert the error to a fatal error, that information is lost. There should be a way to tell a diagnostic function to call print_instantiation_context (). We could override the diagnostic_finalizer like we do for macro expansion, but it seems ugly to do this just here. I think it would be better if there was some way to pass down flags to the finalizer to control what to print. Dodji, what do you think?
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564
--- Comment #18 from Volker Reichelt reichelt at gcc dot gnu.org ---
The reduced testcases from comment #3 and #4 compile within split-seconds since
GCC 4 5.0. This is partially due to Manuel's fix for PR 23510.
However, the original testcase still takes a very long time.
This can be demonstrated with the following reduced testcase:
templatetypename struct A
{
AA a;
A() {}
};
Aint a;
The first error message about exceeding the maximum template instantiation
depth appears rather quickly. So maybe we could make the first error message a
fatal one to avoid further processing of potentially bogus nested classes.
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #19 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Volker Reichelt from comment #18) The first error message about exceeding the maximum template instantiation depth appears rather quickly. So maybe we could make the first error message a fatal one to avoid further processing of potentially bogus nested classes. It seems to me GCC is doing something strange. See comment #14. But what you suggest seems to be what Clang++ is doing: $ /usr/bin/time clang++ test.cc test.cc:3:8: fatal error: recursive template instantiation exceeded maximum depth of 256 AA a; ^ test.cc:3:8: note: in instantiation of template class '...' requested here AA a; ^ test.cc:3:8: note: in instantiation of template class '...' requested here AA a; ^ test.cc:3:8: note: in instantiation of template class '...' requested here AA a; ^ test.cc:3:8: note: in instantiation of template class '...' requested here AA a; ^ test.cc:3:8: note: in instantiation of template class '...' requested here AA a; ^ test.cc:3:8: note: (skipping 247 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all) test.cc:3:8: note: in instantiation of template class 'Aint' requested here AA a; ^ test.cc:3:8: note: in instantiation of template class 'int ' requested here AA a; ^ test.cc:3:8: note: in instantiation of template class 'AAAint ' requested here AA a; ^ test.cc:3:8: note: in instantiation of template class 'AAint ' requested here AA a; ^ test.cc:7:8: note: in instantiation of template class 'Aint' requested here Aint a; ^ test.cc:3:8: note: use -ftemplate-depth=N to increase recursive template instantiation depth AA a; ^ 1 error generated. Command exited with non-zero status 1 0.11user 0.02system 0:00.14elapsed 96%CPU (0avgtext+0avgdata 67904maxresident)k 0inputs+0outputs (0major+6524minor)pagefaults 0swaps And GCC's output in recent versions would look better than this because it has automatic recursion detection: test.cc:3:8: error: template instantiation depth exceeds maximum of 900 (use -ftemplate-depth= to increase the maximum) instantiating ‘struct ...’ AA a; ^ test.cc:3:8: recursively required from ‘struct AAint ’ test.cc:3:8: required from ‘struct Aint’ test.cc:7:8: required from here
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #20 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #19) (In reply to Volker Reichelt from comment #18) The first error message about exceeding the maximum template instantiation depth appears rather quickly. So maybe we could make the first error message a fatal one to avoid further processing of potentially bogus nested classes. It seems to me GCC is doing something strange. See comment #14. But what you suggest seems to be what Clang++ is doing: Although GCC is still much slower than Clang for Steven's original testcase, so the above wouldn't be a complete fix. And the long lines are very ugly. Perhaps there is a way to summarize such a recursive template instantiation. Still, making the error: template instantiation depth exceeds maximum a fatal error seems a good idea to me. Jason?
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org | --- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com 2013-04-09 17:38:06 UTC --- Manuel, compile_file changed with this commit: http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=118362 I seem to remember that another PR regressed with it.
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #16 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-09 18:04:14 UTC --- (In reply to comment #15) Manuel, compile_file changed with this commit: http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=118362 I seem to remember that another PR regressed with it. Unfortunately, Changelogs are mostly useless and don't explain the why :(
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #17 from Paolo Carlini paolo.carlini at oracle dot com 2013-04-09 18:11:12 UTC --- I'm not surprised by that, the real problem is that if you go to gcc-patches like I did some weeks ago, the correspinding discussion is even less usefull :(
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Last reconfirmed|2008-12-25 15:59:38 |2012-11-08 15:59:38 --- Comment #11 from Steven Bosscher steven at gcc dot gnu.org 2012-11-08 23:17:40 UTC --- The compiler now produces a wonderful diagnostic for my original test case (comment #1), with one line of the diagnostic with a length of 30750 (!) characters. Nice, on that 80-chars wide terminal! :-) t.C: In instantiation of 'class std::vectorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocat. t.C:120:23: recursively required from 'class std::vectorstd::allocator__gnu_cxx::_Hashtable_nodestd::pairconst std::basic_stringchar, symbol *, std::allocatorstd::a. t.C:120:23: required from 'class std::vector__gnu_cxx::_Hashtable_nodestd::pairconst std::basic_stringchar, symbol *, std::allocator__gnu_cxx::_Hashtable_nodestd::pa.. t.C:445:18: required from 'class __gnu_cxx::hashtablestd::pairconst std::basic_stringchar, symbol, std::basic_stringchar, __gnu_cxx::hashstd::basic_stringchar , st. t.C:552:9: required from 'class __gnu_cxx::hash_mapstd::basic_stringchar, symbol' t.C:574:35: required from here t.C:121:38: error: no type named 'pointer' in 'class std::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd typedef typename _Alloc::pointer pointer; ^
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #12 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-09 00:44:06 UTC --- Do you know where it is looping? That sounds like a different and more serious issue than the pretty-printer for types not being able to summarize repetitive template instantiations (and that is already reported in a different PR). Clang doesn't loop but it still prints the long lines.
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #13 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-09 00:58:20 UTC --- As I said in PR 43113, it would be wonderful if g++ detected that something is a recursive template instantiation and it didn't print the whole expansion but just the first recursion or some such. I wonder if clang++ has a PR open about this...
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||jsm28 at gcc dot gnu.org --- Comment #14 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-09 01:27:49 UTC --- (In reply to comment #12) Do you know where it is looping? That sounds like a different and more serious issue than the pretty-printer for types not being able to summarize repetitive template instantiations (and that is already reported in a different PR). To answer my own question, it loops (or it seems to take a very long time) in instantiate_pending_templates: #150 0x0069403f in emit_mem_initializers (mem_inits=0x77053c58) at /home/manuel/test1/pristine/gcc/cp/init.c:1085 #151 0x005a40ae in tsubst_expr (t=optimized out, args=args@entry=0x77041060, complain=complain@entry=3, in_decl=in_decl@entry=0x7758ca10, integral_constant_expression_p=integral_constant_expression_p@entry=false) at /home/manuel/test1/pristine/gcc/cp/pt.c:12671 #152 0x005a3964 in tsubst_expr (t=0x77416e70, args=args@entry=0x77041060, complain=complain@entry=3, in_decl=in_decl@entry=0x7758ca10, integral_constant_expression_p=integral_constant_expression_p@entry=false) at /home/manuel/test1/pristine/gcc/cp/pt.c:12849 #153 0x005a10aa in instantiate_decl (d=optimized out, d@entry=0x7703c800, defer_ok=optimized out, defer_ok@entry=0, expl_inst_class_mem_p=expl_inst_class_mem_p@entry=false) at /home/manuel/test1/pristine/gcc/cp/pt.c:18674 #154 0x005dbaa4 in instantiate_pending_templates (retries=optimized out) at /home/manuel/test1/pristine/gcc/cp/pt.c:18773 #155 0x00618ac9 in cp_write_global_declarations () at /home/manuel/test1/pristine/gcc/cp/decl2.c:3990 #156 0x00aadbd5 in compile_file () at /home/manuel/test1/pristine/gcc/toplev.c:558 #157 0x00aaf738 in do_compile () at /home/manuel/test1/pristine/gcc/toplev.c:1864 #158 toplev_main (argc=3, argv=0x7fffe738) at /home/manuel/test1/pristine/gcc/toplev.c:1940 #159 0x776261a6 in __libc_start_main () from /lib/libc.so.6 #160 0x0052f919 in _start () Jason, Joseph, why are we trying to do (cp_)write_global_declarations if we have already seen compilation errors? Can't we just abort earlier in compile_file()?
[Bug c++/16564] g++ seems to go into an infinite loop after errors
--- Comment #10 from tkoenig at gcc dot gnu dot org 2008-12-25 15:59 --- Original test case still takes a long time. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-07-15 21:45:26 |2008-12-25 15:59:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564
[Bug c++/16564] g++ seems to go into an infinite loop after errors
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-17 00:42 --- Neither of the reduced testcases take a long time to error out on the mainline but the orginal huge testcase still takes a long time to error out. -- What|Removed |Added Last reconfirmed|2004-10-14 01:55:45 |2005-01-17 00:42:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564
[Bug c++/16564] g++ seems to go into an infinite loop after errors
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-18 12:14 --- Upon closer inspection, gcc does not enter an infinite loop, it just takes a while to finish. The point is that the default for -ftemplate-depth used to be 17 in older compilers. This was changed to 50 quite some tuime ago. And now it's 500, see http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00542.html And that's why new versions keep iterating for a while. The patch mentioned above states: ! The comment above the default sais it is just an arbitrary value, is ! there some reason to keep it that low? Maybe 500 is too high on the other hand. -- What|Removed |Added Keywords|error-recovery, ice-on- |compile-time-hog |invalid-code| Summary|g++ goes into an infinite |g++ seems to go into an |loop after errors |infinite loop after errors http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564
[Bug c++/16564] g++ seems to go into an infinite loop after errors
--- Additional Comments From bangerth at dealii dot org 2004-10-18 15:47 --- I think your testcase isn't very good. After all, you really try to instantiate ... and the compiler only gives up after its 500 nested instantiations. Your testcase is really badly constructed since it necessarily requires the 500 instantiations, whereas mine from comment #3 only requires 2 or so (a finite number if the instantiation depth would be infinite, whereas yours is really infinite). W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564
[Bug c++/16564] g++ seems to go into an infinite loop after errors
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-18 16:04 --- I don't quite agree. The error about the hosed typedef is issued almost at once by the compiler. But since the compiler doesn't give up after the first error, it tries to instantiate the template without the broken typedef. That's what takes ages and what can be demonstrated with my reduced example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564
[Bug c++/16564] g++ seems to go into an infinite loop after errors
--- Additional Comments From bangerth at dealii dot org 2004-10-18 17:14 --- Ah, never mind. I had misread my own example in that I thought that the instantiation of ST only required instantiation of AT, but in fact it also requires SAT which requires SAAT , etc, so we do have in fact an infinite list of instantiations. In that case, I don't even know whether we should consider this a bug: I would say the compiler is clearly doing something useful with your testcase (and with mine as well) in that it tries to go down the list of instantiations that the code clearly prescribes. Your testcase has no problem except the infinite list of instantiations, so there isn't very much the compiler can do differently apart from throttling the limit somewhat. So, what are we supposed to do? As mentioned in the patch you cite, -ftemplate-depth-50 is not enough, so 500 seems a reasonable choice. What value would you suggest instead? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564
