User account creation filtered due to spam.

Bug 47049 - [C++0x] ICE in write_unnamed_type_name with lambda use
Summary: [C++0x] ICE in write_unnamed_type_name with lambda use
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.5.2
: P3 normal
Target Milestone: 4.6.1
Assignee: Jason Merrill
Keywords: ice-on-valid-code
Depends on:
Reported: 2010-12-23 09:29 UTC by Eamon Nerbonne
Modified: 2011-05-28 03:23 UTC (History)
4 users (show)

See Also:
Known to work:
Known to fail: 4.5.0, 4.5.1, 4.5.2, 4.6.0
Last reconfirmed: 2011-01-23 16:25:32

Preprocessed source (221.62 KB, application/octet-stream)
2010-12-23 09:29 UTC, Eamon Nerbonne
G++'s output (1017 bytes, text/plain)
2010-12-23 09:30 UTC, Eamon Nerbonne
Unpreprocessed source (depends on Eigen3) (551 bytes, text/plain)
2010-12-23 09:31 UTC, Eamon Nerbonne
slightly reduced and unincluded testcase (111.79 KB, text/plain)
2011-01-20 15:01 UTC, Jonathan Wakely

Note You need to log in before you can comment on or make changes to this bug.
Description Eamon Nerbonne 2010-12-23 09:29:38 UTC
Created attachment 22842 [details]
Preprocessed source

errtest.cpp: In lambda function:
errtest.cpp:16:78: internal compiler error: in write_unnamed_type_name, at cp/mangle.c:1311

While using a mingw64 build I encountered the above ICE and reported it @

It was suggested that this is a gcc bug (and it looks like it).  I'm using a lambda in a class template; as follows:

std::sort(v.begin(),v.end(), [&eigenvaluesUnsorted](size_t a, size_t b) -> bool { return eigenvaluesUnsorted(a) > eigenvaluesUnsorted(b);});

Attached are the small unpreprocessed source, the huge preprocessed source, and g++'s output.  The command line was:
g++ -I%EIGEN3_DIR% --std=c++0x -march=core2 -v -save-temps errtest.cpp 2>gcc-err.txt
Comment 1 Eamon Nerbonne 2010-12-23 09:30:20 UTC
Created attachment 22843 [details]
G++'s output
Comment 2 Eamon Nerbonne 2010-12-23 09:31:24 UTC
Created attachment 22844 [details]
Unpreprocessed source (depends on Eigen3)
Comment 3 Eamon Nerbonne 2010-12-23 09:33:11 UTC
Oh, and finally: a comment on the mingw64 tracker is meaningless to me but perhaps useful to you:

ktietz70 said:
"So, I investigate your issue a bit. First this is for sure a gcc bug, which
calls here write_unnamed_type_name for an ENUMERAL_TYPE, which isn't
The issue is related to write_nested_name, which doesn't special case here
named enumeral types."
Comment 4 Eamon Nerbonne 2011-01-20 11:06:04 UTC
Has anyone seen this bug?
Comment 5 Jonathan Wakely 2011-01-20 12:00:56 UTC
it might get analysed sooner if you try to reduce the code to something smaller than 70000 lines
Comment 6 Jonathan Wakely 2011-01-20 15:01:29 UTC
Created attachment 23046 [details]
slightly reduced and unincluded testcase

confirmed with 4.5 and 4.6

attachment produced by
g++46 -std=c++0x -Ieigen -DNDEBUG -DEIGEN_DONT_VECTORIZE -E | ~/src/gcc-4.6-20110101/contrib/uninclude

(NDEBUG and EIGEN_DONT_VECTORIZE avoid non-portable assertions and intrinsics in the output)
Comment 7 Eamon Nerbonne 2011-01-23 13:31:38 UTC
(In reply to comment #5)
> it might get analysed sooner if you try to reduce the code to something smaller
> than 70000 lines

Yeah, I realize: I've been putting that off, because, well, I don't exactly grok what the issue is and was hoping someone would say "oh, it's obviously just XYZ" without having to minimize the test case.

I've tried removing the eigen headers and causing the ICE in a more manageable bit, but so far the resulting programs compile without ICE, so that's not helping.

Thanks for the response anyhow - I was wondering whether anyone had spotted the report at all - I can empathize with feeling that it's not exactly a nice test-case...
Comment 8 Jonathan Wakely 2011-01-23 16:25:32 UTC
Oops, I did mean to confirm this though - I can reproduce it
Comment 9 H.J. Lu 2011-01-23 16:39:52 UTC
It is caused by revision 152429:

which implements write_unnamed_type_name.
Comment 10 Jakub Jelinek 2011-01-28 16:33:07 UTC
Reduced testcase:

enum { E = 0, F = 1 };
template <int N, int M = ((N == 1) ? F : E)> class S;
template <int N>
struct T
  static void
  foo (S<N> *p)
    S<N> u;
    [&u] ()->bool {};
Comment 11 Richard Biener 2011-02-08 13:55:21 UTC
Hm, this doesn't seem to be a regression.  lambda is not supported in GCC 4.4,
GCC 4.5.x ICE the same way as trunk.

So, what version works for you (some unreleased SVN rev does not count,
such a regression is not percieved as such from a users POV)?  Unmarking
as regression.
Comment 12 Jakub Jelinek 2011-02-08 13:58:17 UTC
It is a regression in the sense that e.g. the #c10 testcase with 4.4 resulted in a bunch of errors, but not an ICE, while it ICEs in 4.6.
Comment 13 Jason Merrill 2011-05-28 00:53:53 UTC
Author: jason
Date: Sat May 28 00:53:49 2011
New Revision: 174375

	PR c++/47049
	* semantics.c (maybe_add_lambda_conv_op): Fix COMDAT sharing.
	* decl.c (start_preparsed_function): Don't call comdat_linkage for
	a template.

Comment 14 Jason Merrill 2011-05-28 03:22:34 UTC
Author: jason
Date: Sat May 28 03:22:31 2011
New Revision: 174377

	PR c++/47049
	* semantics.c (maybe_add_lambda_conv_op): Fix COMDAT sharing.
	* decl.c (start_preparsed_function): Don't call comdat_linkage for
	a template.

Comment 15 Jason Merrill 2011-05-28 03:23:10 UTC
Fixed for 4.6.1.