[Bug c++/16564] g++ seems to go into an infinite loop after errors

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[steven at gcc dot gnu.org]

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::vector<std::allocator<std::allocator<std::allocator<std::allocator<std::allocator<std::allocator<std::allocator<std::allocator<std::allocat.....
t.C:120:23:   recursively required from 'class
std::vector<std::allocator<__gnu_cxx::_Hashtable_node<std::pair<const
std::basic_string<char>, symbol> >*>, std::allocator<std::a.....
t.C:120:23:   required from 'class
std::vector<__gnu_cxx::_Hashtable_node<std::pair<const std::basic_string<char>,
symbol> >*, std::allocator<__gnu_cxx::_Hashtable_node<std::pa......
t.C:445:18:   required from 'class __gnu_cxx::hashtable<std::pair<const
std::basic_string<char>, symbol>, std::basic_string<char>,
__gnu_cxx::hash<std::basic_string<char> >, st.....
t.C:552:9:   required from 'class __gnu_cxx::hash_map<std::basic_string<char>,
symbol>'
t.C:574:35:   required from here
t.C:121:38: error: no type named 'pointer' in 'class
std::allocator<std::allocator<std::allocator<std::allocator<std::allocator<std::allocator<std::allocator<std::allocator<std....
     typedef typename _Alloc::pointer pointer;
                                      ^

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[manu at gcc dot gnu.org]

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

[manu at gcc dot gnu.org]

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

[manu at gcc dot gnu.org]

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 0x000000000069403f in emit_mem_initializers (mem_inits=0x7ffff7053c58) at
/home/manuel/test1/pristine/gcc/cp/init.c:1085
#151 0x00000000005a40ae in tsubst_expr (t=<optimized out>,
args=args@entry=0x7ffff7041060, complain=complain@entry=3,
in_decl=in_decl@entry=0x7ffff758ca10, 
    integral_constant_expression_p=integral_constant_expression_p@entry=false)
at /home/manuel/test1/pristine/gcc/cp/pt.c:12671
#152 0x00000000005a3964 in tsubst_expr (t=0x7ffff7416e70,
args=args@entry=0x7ffff7041060, complain=complain@entry=3,
in_decl=in_decl@entry=0x7ffff758ca10, 
    integral_constant_expression_p=integral_constant_expression_p@entry=false)
at /home/manuel/test1/pristine/gcc/cp/pt.c:12849
#153 0x00000000005a10aa in instantiate_decl (d=<optimized out>,
d@entry=0x7ffff703c800, 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 0x00000000005dbaa4 in instantiate_pending_templates (retries=<optimized
out>) at /home/manuel/test1/pristine/gcc/cp/pt.c:18773
#155 0x0000000000618ac9 in cp_write_global_declarations () at
/home/manuel/test1/pristine/gcc/cp/decl2.c:3990
#156 0x0000000000aadbd5 in compile_file () at
/home/manuel/test1/pristine/gcc/toplev.c:558
#157 0x0000000000aaf738 in do_compile () at
/home/manuel/test1/pristine/gcc/toplev.c:1864
#158 toplev_main (argc=3, argv=0x7fffffffe738) at
/home/manuel/test1/pristine/gcc/toplev.c:1940
#159 0x00007ffff76261a6 in __libc_start_main () from /lib/libc.so.6
#160 0x000000000052f919 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

[paolo.carlini at oracle dot com]

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=revision&revision=118362

I seem to remember that another PR regressed with it.

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[manu at gcc dot gnu.org]

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=revision&revision=118362
> 
> I seem to remember that another PR regressed with it.

Unfortunately, Changelogs are mostly useless and don't explain the why :(
>From gcc-bugs-return-419634-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Apr 09 18:10:39 2013
Return-Path: <gcc-bugs-return-419634-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30301 invoked by alias); 9 Apr 2013 18:10:39 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 30223 invoked by uid 48); 9 Apr 2013 18:10:35 -0000
From: "fredrickprashanth at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/28865] Structures with a flexible arrray member have wrong .size
Date: Tue, 09 Apr 2013 18:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fredrickprashanth at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-28865-4-q6ZbwnCOZD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-28865-4@http.gcc.gnu.org/bugzilla/>
References: <bug-28865-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg00779.txt.bz2
Content-length: 309


http://gcc.gnu.org/bugzilla/show_bug.cgi?id(865

--- Comment #7 from Fredrick <fredrickprashanth at gmail dot com> 2013-04-09 18:10:34 UTC ---
HJ,

Thanks for pointing the patch.

The patch works. I tested it on x86-64.
Could this patch be integrated into the mainline GCC?

Thanks,
Fredrick

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[paolo.carlini at oracle dot com]

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

[reichelt at gcc dot gnu.org]

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 veeeeery long time.
This can be demonstrated with the following reduced testcase:

================================
template<typename> struct A
{
  A<A> a;
  A() {}
};

A<int> 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

[manu at gcc dot gnu.org]

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
  A<A> a;
       ^
test.cc:3:8: note: in instantiation of template class
      '...' requested here
  A<A> a;
       ^
test.cc:3:8: note: in instantiation of template class
      '...' requested here
  A<A> a;
       ^
test.cc:3:8: note: in instantiation of template class
      '...' requested here
  A<A> a;
       ^
test.cc:3:8: note: in instantiation of template class
      '...' requested here
  A<A> a;
       ^
test.cc:3:8: note: in instantiation of template class
      '...' requested here
  A<A> 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 'A<A<A<A<A<int> > > > >'
requested here
  A<A> a;
       ^
test.cc:3:8: note: in instantiation of template class 'A<A<A<A<int> > > >'
requested here
  A<A> a;
       ^
test.cc:3:8: note: in instantiation of template class 'A<A<A<int> > >'
requested here
  A<A> a;
       ^
test.cc:3:8: note: in instantiation of template class 'A<A<int> >' requested
here
  A<A> a;
       ^
test.cc:7:8: note: in instantiation of template class 'A<int>' requested here
A<int> a;
       ^
test.cc:3:8: note: use -ftemplate-depth=N to increase recursive template
instantiation depth
  A<A> 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 ...’
   A<A> a;
        ^
test.cc:3:8:   recursively required from ‘struct A<A<int> >’
test.cc:3:8:   required from ‘struct A<int>’
test.cc:7:8:   required from here
>From gcc-bugs-return-438614-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Dec 27 20:53:28 2013
Return-Path: <gcc-bugs-return-438614-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9982 invoked by alias); 27 Dec 2013 20:53:26 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9957 invoked by uid 48); 27 Dec 2013 20:53:20 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/16564] g++ seems to go into an infinite loop after errors
Date: Fri, 27 Dec 2013 20:53:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: compile-time-hog, diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-16564-4-ej4uMTxr5L@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-16564-4@http.gcc.gnu.org/bugzilla/>
References: <bug-16564-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg02269.txt.bz2
Content-length: 989

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?
>From gcc-bugs-return-438615-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Dec 27 21:24:48 2013
Return-Path: <gcc-bugs-return-438615-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19478 invoked by alias); 27 Dec 2013 21:24:47 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 19424 invoked by uid 55); 27 Dec 2013 21:24:42 -0000
From: "sgk at troutmask dot apl.washington.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/59604] Constant comparisons with -fno-range-check and int(z'...')
Date: Fri, 27 Dec 2013 21:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: sgk at troutmask dot apl.washington.edu
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59604-4-wd5G2CXNjE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59604-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59604-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg02270.txt.bz2
Content-length: 2919

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY604

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Dec 27, 2013 at 07:53:00PM +0000, tkoenig at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?idY604
>
> Thomas Koenig <tkoenig at gcc dot gnu.org> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Blocks|                            |58003
>
> --- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
> (In reply to kargl from comment #2)
> > (In reply to Thomas Koenig from comment #1)
> > > TRANSFER gets this right.
> >
> > It is unclear what you mean here.
>
> What I mean is that
>
> program test
>   if (transfer(z'FFFFFFFF',1) /= -1) call abort
> end program test
>
> does not call abort.

I suspect that the above is not portable as transfer() simply copies
bits.  z'FFFFFFF' is an integer(8) (or integer(16)) entity.  Transfer()
is copying 32-bits from that entity.  It is clear from the
-fdump-tree-original that middle-end is "converting" the resulting
32-bit thing into -1.  So, you're relying on twos-complement wrap
around semantics.

> Also setting this as blocking 58003, because an obvious
> fix to that bug would replace an ICE with a wrong-code
> bug for some corner cases (not preferable :-)

This isn't blocking 58003 as the code in 59604 is invalid.  As gfortran
provides popcnt() as an intrinsics procedure, it follows that popcnt()
should follow the Fortran standard (see below quote).  Now, if you want
to chase a real bug in gfortran, try this little program

program test
   integer(8) :: i = 4294967295_8
   integer(8) :: j = z'FFFFFFFF'
   !
   ! The following two lines should call abort, but don't!  In addition,
   ! these lines do not require -fno-range-check to compile, so gfortran
   ! violates the quote from the F95 standard (p.228) below.
   !
   if (int(i) /= -1) call abort
   if (int(j) /= -1) call abort
   !
   ! On a 2-complement system, the next statement is optimized away.
   ! I haven't decided yet, whether transfer() violates the standard
   ! because it only copies bits and the 32-bits copied from the boz
   ! fit into an integer(4).
   !
   if (transfer(z'FFFFFFFF',1) /= -1) call abort
   !
   ! Both of these require -fno-range-check to compile, and they violate
   !
   !    A program is prohibited from invoking an intrinsic procedure
   !    under circumstances where a value to be returned in a subroutine
   !    argument or function result is outside the range of values
   !    representable by objects of the specified type and type parameters.
   !
   ! 4294967295_8 is well outside of the range [-huge()-1:huge()] of a
   ! twos-complement 32-bit integer(4)
   !
   if (int(z'FFFFFFFF') /= -1) call abort
   if (int(4294967295_8) /= -1) call abort
end program test

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[manu at gcc dot gnu.org]

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?
>From gcc-bugs-return-438719-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Dec 29 22:01:50 2013
Return-Path: <gcc-bugs-return-438719-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29387 invoked by alias); 29 Dec 2013 22:01:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 29351 invoked by uid 48); 29 Dec 2013 22:01:45 -0000
From: "pageexec at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug plugins/59335] Plugin doesn't build on trunk
Date: Sun, 29 Dec 2013 22:01:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: plugins
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pageexec at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-59335-4-91XQpCA7Qe@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59335-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59335-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg02374.txt.bz2
Content-length: 502

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY335

PaX Team <pageexec at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pageexec at gmail dot com

--- Comment #2 from PaX Team <pageexec at gmail dot com> ---
there're some more missing headers for plugins on amd64 at least:

gimplify.h
tree-flow.h
tree-flow-inline.h
config/i386/x86-tune.def

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[paolo.carlini at oracle dot com]

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

[manu at gcc dot gnu.org]

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.
>From gcc-bugs-return-462937-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Sep 30 14:34:02 2014
Return-Path: <gcc-bugs-return-462937-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24699 invoked by alias); 30 Sep 2014 14:34:02 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 24644 invoked by uid 48); 30 Sep 2014 14:33:53 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/62056] Long compile times with large tuples
Date: Tue, 30 Sep 2014 14:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-62056-4-hMnmtXFuv2@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62056-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62056-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg02771.txt.bz2
Content-length: 1166

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-09-30
                 CC|                            |manu at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Agustín Bergé from comment #6)
> Well, not necessarily, It's not `std::tuple` which is at fault, but the
> compiler (gcc and every other). Note that this issue was moved from
> libstdc++ to c++, so that's promising!

I don't see any analysis of what the "bug" actually is. If there is a bug in
g++, you should be able to trigger it with a testcase not including <tuple>.

On the other hand, if you want to provide an alternative implementation of
<tuple>, you should join libstc++:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html
>From gcc-bugs-return-462938-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Sep 30 15:15:29 2014
Return-Path: <gcc-bugs-return-462938-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32348 invoked by alias); 30 Sep 2014 15:15:28 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 32245 invoked by uid 48); 30 Sep 2014 15:15:12 -0000
From: "kaballo86 at hotmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/62056] Long compile times with large tuples
Date: Tue, 30 Sep 2014 15:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kaballo86 at hotmail dot com
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62056-4-GCHvjWcRlI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62056-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62056-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg02772.txt.bz2
Content-length: 2590

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

--- Comment #8 from Agustín Bergé <kaballo86 at hotmail dot com> ---
(In reply to Manuel López-Ibáñez from comment #7)
> (In reply to Agustín Bergé from comment #6)
> > Well, not necessarily, It's not `std::tuple` which is at fault, but the
> > compiler (gcc and every other). Note that this issue was moved from
> > libstdc++ to c++, so that's promising!
> 
> I don't see any analysis of what the "bug" actually is. If there is a bug in
> g++, you should be able to trigger it with a testcase not including <tuple>.
> 
> On the other hand, if you want to provide an alternative implementation of
> <tuple>, you should join libstc++:
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html

This issue started targeting libstdc++, and later someone reassigned it to c++.
The recursive tuple implementation in libstdc++ causes our use of large tuples
to more than double compilation time when compared to a flat implementation.
Hence the inclusion of <tuple>.

There is no bug, but a QoI issue that makes `std::tuple` use prohibitive for
large tuples. Whether the QoI issue belongs with libc++ or g++, I am not
entitled to say. The underlying issue is a g++ issue, but there are known
compile-time efficient implementations of `std::tuple`. Of course, a solution
in the compiler would benefit a wider audience so it would be preferable. And
again, no solution would be fine as well given that this is QoI.

As for a "bug" analysis (which is a requirement that I was unaware of), I
haven't put this particular combination of implementation and compiler under a
profiler. I have done however enough experimentation on similar code bases and
the results are consistent, so while I might be off in the specific details it
should still give you a strong hint of where to look. The issue boils down to
name mangling and lookup: the longer the name the more memory consumption and
cpu usage. For a recursive variadic implementation, instantiating a tuple of N
elements with aggregated mangled length M results in the mangling of N bases
with average mangled length M/2. For a flat variadic implementation, it results
in the mangling of N bases of average mangled length M/N instead. As the tuple
gets large and the names get long (and mangled names get very long very fast),
the recursive implementation turns into a compilation time (and memory!) hog
way faster than a flat implementation does.

Please let me know if I can help you in any other way.
>From gcc-bugs-return-462939-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Sep 30 15:28:49 2014
Return-Path: <gcc-bugs-return-462939-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11512 invoked by alias); 30 Sep 2014 15:28:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 11476 invoked by uid 48); 30 Sep 2014 15:28:43 -0000
From: "gerrit.los at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63405] [5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
Date: Tue, 30 Sep 2014 15:28:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: gerrit.los at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-63405-4-6Ji35wHlQK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63405-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63405-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg02773.txt.bz2
Content-length: 1333

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc405

Gert-jan Los <gerrit.los at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gerrit.los at gmail dot com

--- Comment #2 from Gert-jan Los <gerrit.los at gmail dot com> ---
git bisect points to the following commit:
internal compiler error: in cp_perform_integral_promotions, at cp/typeck.c:2084
ffe3a6612f48c48d0d4ca285cf9833df87b6c240 is the first bad commit
commit ffe3a6612f48c48d0d4ca285cf9833df87b6c240
Author: jason <jason@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Thu Sep 11 13:50:27 2014 +0000

        PR c++/63139
        * pt.c (tsubst_pack_expansion): Simplify substitution into T....
        (tsubst): Don't throw away PACK_EXPANSION_EXTRA_ARGS.

    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@215171
138bc75d-0d04-0410-961f-82ee72b054a4

additional testcase:
-----
template <typename _Tp> _Tp forward(_Tp);
template <typename Args> struct Format { Format(int, Args); };
template <typename... Args> auto format(Args &&... args) -> Format<Args...> {
  return {0, args...};
}

template <typename... Args> void msg(Args... args) {
  format(forward(args)...);
}

void some_function() { msg('x'); }
-----

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[manu at gcc dot gnu.org]

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 `S<A<A<A<A<A<A<A<A<A<A<A<int> > > > > > > > > > > 

but that is PR43113, so I think yes, we can close this. Congratulations!
>From gcc-bugs-return-462959-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Sep 30 17:32:47 2014
Return-Path: <gcc-bugs-return-462959-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5222 invoked by alias); 30 Sep 2014 17:32:47 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 5162 invoked by uid 48); 30 Sep 2014 17:32:43 -0000
From: "macro@linux-mips.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/58139] PowerPC volatile VSX register live across call
Date: Tue, 30 Sep 2014 17:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: macro@linux-mips.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: bergner at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-58139-4-yYkzkrwMBL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58139-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58139-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg02793.txt.bz2
Content-length: 193

https://gcc.gnu.org/bugzilla/show_bug.cgi?idX139

--- Comment #16 from Maciej W. Rozycki <macro@linux-mips.org> ---
The unwinder issue has been now fixed along PR target/60102, rev. 213596.

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[paolo.carlini at oracle dot com]

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

[tkoenig at gcc dot gnu dot org]

------- 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] New: g++ goes into an infinite loop after errors

[steven at gcc dot gnu dot org]

g++ goes into an infinite loop for the test case after issueing a few errors 
(the test case is crappy code, delta output produces this kind of thing 
sometimes ;-)

-- 
           Summary: g++ goes into an infinite loop after errors
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Keywords: error-recovery
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: steven at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[reichelt at gcc dot gnu dot org]

------- 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

[bangerth at dealii dot org]

------- 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 A<A<A<A...>>> 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

[reichelt at gcc dot gnu dot org]

------- 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

[bangerth at dealii dot org]

------- 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 S<T> only required instantiation of A<T>, but in 
fact it also requires S<A<T> > which requires S<A<A<T> > >, 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

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[pinskia at gcc dot gnu dot org]

------- 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