Bug 46701 - [C++0x] ICE in build_data_member_initialization, at cp/semantics.c:5503
Summary: [C++0x] ICE in build_data_member_initialization, at cp/semantics.c:5503
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: 4.6.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
: 46697 46698 46699 46700 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-11-29 04:23 UTC by miles
Modified: 2010-12-13 21:29 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-11-29 14:56:22


Attachments
preprocessed source showing crash (57.55 KB, text/plain)
2010-11-29 04:25 UTC, miles
Details

Note You need to log in before you can comment on or make changes to this bug.
Description miles 2010-11-29 04:23:28 UTC
I don't know if this is the same as the other ICEs in build_data_member_initialization, but it's at a different line number anyway...

Compiler version is:
g++ (Debian 20101128-1) 4.6.0 20101128 (experimental) [trunk revision 167220]

Here's the un-preprocessed source (preprocessed source attached):

  #include <string>
  #include <map>

  void f (const std::string &name, const std::string &val)
  {
    std::map<const std::string, std::string>::value_type (name, val);
  }


Compiled with:

  g++-snapshot -c -std=c++0x ,oink.cc


yields:

   In file included from /usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_algobase.h:65:0,
		    from /usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/char_traits.h:41,
		    from /usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/string:42,
		    from ,oink.cc:1:
   /usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h: In constructor 'constexpr std::pair<_T1, _T2>::pair(const _T1&, const _T2&) [with _T1 = const std::basic_string<char>, _T2 = std::basic_string<char>]':
   ,oink.cc:6:66:   instantiated from here
   /usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:102:35: internal compiler error: in build_data_member_initialization, at cp/semantics.c:5503
   Please submit a full bug report,
   with preprocessed source if appropriate.
   See <file:///usr/share/doc/gcc-snapshot/README.Bugs> for instructions.

Thanks,

-miles
Comment 1 miles 2010-11-29 04:25:03 UTC
Created attachment 22559 [details]
preprocessed source showing crash

Generated with: g++-snapshot -E -std=c++0x
Comment 2 miles 2010-11-29 04:30:16 UTC
BTW, sorry about the duplicate bugs.

Bugzilla complains about not being able to autodetect the attachment content-type, and says "hit BACK and try again" -- but doesn't mention that the bug was submitted anyway! [and of course there doesn't actually seem to be anyway to specify the content-type of an attachment on the new-bug page...]
Comment 3 miles 2010-11-29 05:14:29 UTC
*** Bug 46697 has been marked as a duplicate of this bug. ***
Comment 4 miles 2010-11-29 05:14:53 UTC
*** Bug 46698 has been marked as a duplicate of this bug. ***
Comment 5 miles 2010-11-29 05:15:18 UTC
*** Bug 46699 has been marked as a duplicate of this bug. ***
Comment 6 miles 2010-11-29 05:15:43 UTC
*** Bug 46700 has been marked as a duplicate of this bug. ***
Comment 7 H.J. Lu 2010-11-29 14:56:22 UTC
ICE on the preprocessed testcase is caused by revision 166165:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00051.html
Comment 8 Andreas Beckmann 2010-12-09 01:02:18 UTC
Another small minimized testcase for this problem which fails on 4.6 and succeeds on 4.5:

===== 8< =====
struct A
{
        int i ;
} ;
struct B
{
        const A a ;

        constexpr
        B () : a ( A () )
        { }
} ;
===== >8 =====

$ g++-trunk -v -c -W -Wall -std=c++0x PR46701.min.ii
Using built-in specs.
COLLECT_GCC=/opt/software/x86_64/gcc-trunk/bin/g++-trunk
COLLECT_LTO_WRAPPER=/opt/software/x86_64/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/opt/software/x86_64/gcc-trunk --program-suffix=-trunk --enable-languages=c,c++ --enable-checking
Thread model: posix
gcc version 4.6.0 20101207 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-Wextra' '-Wall' '-std=c++0x' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /opt/software/x86_64/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -fpreprocessed PR46701.min.ii -quiet -dumpbase PR46701.min.ii -mtune=generic -march=x86-64 -auxbase PR46701.min -Wextra -Wall -std=c++0x -version -o /tmp/cc22qtoi.s
GNU C++ (GCC) version 4.6.0 20101207 (experimental) (x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.6.0 20101207 (experimental), GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.6.0 20101207 (experimental) (x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.6.0 20101207 (experimental), GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 58dd45b357216c1e9d23aab2b8f87581
PR46701.min.ii: In constructor ‘constexpr B::B()’:
PR46701.min.ii:11:4: internal compiler error: in build_data_member_initialization, at cp/semantics.c:5489
Please submit a full bug report,
Comment 9 Paolo Carlini 2010-12-09 10:31:57 UTC
The patch for c++/46384 fixed this one too.

*** This bug has been marked as a duplicate of bug 46384 ***
Comment 10 Paolo Carlini 2010-12-09 10:32:53 UTC
Sorry.

*** This bug has been marked as a duplicate of bug 46348 ***
Comment 11 Andreas Beckmann 2010-12-09 21:50:26 UTC
I just retried with trunk r167662 and could still reproduce this bug for both miles' code and my minimized test case
So it was *not* fixed by 46348. (But the testcase from 46348 now compiles cleanly.)
Comment 12 Paolo Carlini 2010-12-09 22:37:23 UTC
Weird.
Comment 13 Paolo Carlini 2010-12-10 13:17:54 UTC
By the way, here and in c++/46877, the ICEs in library code - which I would consider rather serious because prevent people from testing in C++0x mode quite common uses of std::map - occur in a std::pair constructor decorated with constexpr in a way not conforming to the letter of n3225. Thus, if we can't really go through such issue in the constexpr code for 4.6.0 - because too risky, or whatelse - I would propose removing for now the constexpr specifiers from std::pair. Jason, what do you think?
Comment 14 Paolo Carlini 2010-12-13 21:29:05 UTC
Thanks Jason. Fixed in Rev. 167770.