User account creation filtered due to spam.

Bug 44045 - initialization of array of shared_ptr's with initializer list causes compiler segfault
Summary: initialization of array of shared_ptr's with initializer list causes compiler...
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.4.4
: P3 normal
Target Milestone: 4.6.0
Assignee: Jason Merrill
Keywords: ice-on-invalid-code
: 46848 48050 (view as bug list)
Depends on:
Reported: 2010-05-08 23:06 UTC by lynczu
Modified: 2011-03-09 16:51 UTC (History)
4 users (show)

See Also:
Host: x86_64-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2010-05-09 20:36:10

preprocessed file gcc-4.4.4 x86_64 (91.30 KB, text/plain)
2010-05-08 23:08 UTC, lynczu
preprocessed file gcc-4.5.0 x86 (92.90 KB, text/plain)
2010-05-08 23:09 UTC, lynczu

Note You need to log in before you can comment on or make changes to this bug.
Description lynczu 2010-05-08 23:06:31 UTC
I was able to reproduce this problem with gcc-4.4.4 on x86_64 (Exherbo) and gcc-4.5.0 on x86 (Arch Linux 2009.08). Just to be honest I'm not quite sure, if the code used to build this testcase if valid C++, but it seems to me that there is some issue with initializing array of shared_ptr's with initializer list (or throwing an error if it's not valid). It works when I use std::array instead of C-like array for storing these shared_ptr's. Here's the output from gcc-4.4.4:

Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/paludis/build/sys-devel-gcc-4.4.4/work/gcc-4.4.4/configure --prefix=/usr --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --enable-fast-install --libdir=/usr/lib64 --enable-multilib --libdir=/usr/lib64 --enable-languages=c++,objc,obj-c++,java --enable-libstdcxx-pch=yes --enable-nls --program-suffix=-4.4 --with-pkgversion='exherbo gcc-4.4.4' --with-cloog --with-ppl --with-system-zlib --enable-libgomp --disable-libssp
Thread model: posix
gcc version 4.4.4 (exherbo gcc-4.4.4) 
COLLECT_GCC_OPTIONS='-std=c++0x' '-Wall' '-save-temps' '-v' '-o' 'gcc_bugoo' '-shared-libgcc' '-mtune=generic'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.4/cc1plus -E -quiet -v -D_GNU_SOURCE -mtune=generic -std=c++0x -Wall -fpch-preprocess -o gcc_bug.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/lib64/gcc/x86_64-pc-linux-gnu/4.4.4/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
End of search list.
COLLECT_GCC_OPTIONS='-std=c++0x' '-Wall' '-save-temps' '-v' '-o' 'gcc_bugoo' '-shared-libgcc' '-mtune=generic'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.4/cc1plus -fpreprocessed gcc_bug.ii -quiet -dumpbase -mtune=generic -auxbase gcc_bug -Wall -std=c++0x -version -o gcc_bug.s
GNU C++ (exherbo gcc-4.4.4) version 4.4.4 (x86_64-pc-linux-gnu)
        compiled by GNU C version 4.4.4, GMP version 4.3.2, MPFR version 2.4.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1311f0de2e0742c3e083aaa93b5e2b4b In function ‘int main()’: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <> for instructions.
Comment 1 lynczu 2010-05-08 23:08:17 UTC
Created attachment 20608 [details]
preprocessed file gcc-4.4.4 x86_64
Comment 2 lynczu 2010-05-08 23:09:08 UTC
Created attachment 20609 [details]
preprocessed file gcc-4.5.0 x86
Comment 3 Paolo Carlini 2010-05-08 23:15:48 UTC
If it's a segmentation fault, isn't a library issue, that for sure.
Comment 4 lynczu 2010-05-08 23:44:59 UTC
On my two different systems it ends with segfault and on a third one (with Ubuntu gcc-4.4.0) it throws "incompatible types in assignment" error. So apparently I was in a bit too hurry in filling this bug error, sorry about that. May those segfaults affect somehow further compilations or just I need to not bother? 
Comment 5 Paolo Carlini 2010-05-09 01:20:35 UTC
Maybe I was not clear enough: **any** segmentation fault is a bug in the compiler. It must **never** seg fault, no matter which is the input. Thus, the point is simply that a segmentation must be reported as a C++ (or C, Fortran, whatever) bug, not as library bug. If you see a seg fault, first double check that you can reproduce the problem also with a recent compiler, reduce the testcase as much as possible (maybe also helping yourself with "delta"), and file a front-end bug. Thanks!
Comment 6 lynczu 2010-05-09 09:58:42 UTC
reopened then
Comment 7 Doug Semler 2010-05-09 16:24:21 UTC
Reduced test case:

# 1 ""
# 1 "<built-in>"
# 1 "<command-line>"
# 1 ""
struct base
   virtual ~base() { }

int main()
 base ptr_array[1];
 ptr_array = { base() };
Comment 8 Paolo Carlini 2010-05-09 16:47:40 UTC
Many thanks, this will help the debugging a lot. CC-ing Jason...
Comment 9 Jason Merrill 2010-05-10 15:30:25 UTC
The testcase is invalid; 5.17 doesn't allow assignment to an array from an initializer list (although I'm not sure why not).  But certainly we should give an error rather than crash.
Comment 10 Doug Semler 2010-05-10 17:18:41 UTC
Well, is it really invalid code with -std=c++0x?

The virutal destructor seems to be causing the issue.

With gcc 4.4.3 (after changing virtual ~base() to virtual void func()):

$ g++ In function ‘int main()’: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x

$ g++  -std=c++0x

So you can see that g++ sees this as valid code.
Comment 11 Jonathan Wakely 2010-05-10 17:32:57 UTC
(In reply to comment #10) 
> So you can see that g++ sees this as valid code.

I think that's a bug too

Comment 12 Jason Merrill 2010-05-10 18:38:11 UTC
Subject: Bug 44045

Author: jason
Date: Mon May 10 18:37:56 2010
New Revision: 159243

	PR c++/44045
	* typeck.c (cp_build_modify_expr): Complain about assignment to
	array from init list.


Comment 13 Jason Merrill 2010-05-10 18:40:49 UTC
Fixed for 4.6.
Comment 14 Jonathan Wakely 2010-12-08 12:33:39 UTC
*** Bug 46848 has been marked as a duplicate of this bug. ***
Comment 15 Jonathan Wakely 2011-03-09 16:51:05 UTC
*** Bug 48050 has been marked as a duplicate of this bug. ***