Created attachment 29504 [details] Preprocessed output from the source files that reproduce this bug (I'm re-filing this bug per suggestion from the downstream Ubuntu bug tracker: <https://bugs.launchpad.net/ubuntu/+source/gcc-4.6/+bug/1093055> Upon further investigation, the bug doesn't appear to be Ubuntu-specific.) I've hit this bug on several g++ versions, but am primarily running 4.6.3 as bundled with Ubuntu 12.04, on a relatively stock system: $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) $ g++ --version g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ apt-cache policy g++-4.6 g++-4.6: Installed: 4.6.3-1ubuntu5 Candidate: 4.6.3-1ubuntu5 Version table: *** 4.6.3-1ubuntu5 0 500 http://us.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages 100 /var/lib/dpkg/status $ lsb_release -rd Description: Ubuntu 12.04.1 LTS Release: 12.04 I'm trying to compile a particular source file. When I compile it as follows, I get the following error: $ g++ -I ../include -I HelperLibraries -g -Wall -Wno-unused-value -shared -fPIC -o build/BasicIntegerParser_continuous.so ParserFunctions/BasicIntegerParser_continuous.cpp ../include/Vertica.cpp ParserFunctions/BasicIntegerParser_continuous.cpp: In member function ‘virtual Vertica::UDParser* BasicIntegerParserFactory::prepare(Vertica::ServerInterface&, Vertica::PerColumnParamReader&, Vertica::PlanContext&, const Vertica::SizedColumnTypes&)’: ParserFunctions/BasicIntegerParser_continuous.cpp:76:16: internal compiler error: in build_zero_init_1, at cp/init.c:279 Please submit a full bug report, with preprocessed source if appropriate. See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions. Preprocessed source stored into /tmp/cc8HZt1y.out file, please attach this to your bugreport. I expected the file to compile properly, or at least provide an error message describing a fault in my code rather than in the compiler. I have attached the preprocessed source file as requested by the error message. The error reproduces for me on g++ 4.4.5 (installed on top of Red Hat Enterprise Linux -- hence concluding no Ubuntu dependency). Others have reproduced this with both vanilla and Ubuntu-packaged g++ 4.7.2. The bug does NOT reproduce for me on g++ 4.1.2; the above code compiles and runs as I would expect: $ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --disable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-52) The code also compiles and runs as I would expect under clang 3.0. (I suspect that's not too useful for debugging, but, just in case / to be thorough.) Please let me know if I can help out in debugging or fixing.
Confirmed.
Reduced testcase: typedef __builtin_va_list __gnuc_va_list; typedef __gnuc_va_list va_list; struct ContinuousUDParser { va_list err_args; }; void* prepare(){ return (new ContinuousUDParser()); }
My guess is this started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126399 but haven't verified (all I know is that r126000 didn't ICE, r127000 does). I think the problem is that (*lang_hooks.types.make_type) (RECORD_TYPE) doesn't create CLASS_TYPE_P, which is what I think is generally desirable at least for the middle-end va_list aggregates (and supposedly other records too, though they likely can't appear in user code). One way would be just during the initialization of C++ FE to fix up the RECORD_TYPE embedded in va_list, but that wouldn't work well on i?86 which creates several va_list records for the different ABIs. We have cxx_make_type which doesn't create CLASS_TYPE_P, and make_class_type which does, but only handles RECORD_TYPE and UNION_TYPE. So, perhaps the lang hook make_type should be some other function, that for code == RECORD_TYPE || code == UNION_TYPE calls make_class_type, otherwise calls cxx_make_type?
Alternatively build_zero_init_1 could use RECORD_OR_UNION_CODE_P (TREE_CODE (type)) instead of CLASS_TYPE_P (type).
(In reply to comment #4) > Alternatively build_zero_init_1 could use RECORD_OR_UNION_CODE_P (TREE_CODE > (type)) instead of CLASS_TYPE_P (type). I've tried that approach and even regtested that - it looks fine.
(In reply to comment #4) > Alternatively build_zero_init_1 could use RECORD_OR_UNION_CODE_P (TREE_CODE > (type)) instead of CLASS_TYPE_P (type). That makes sense to me.
Author: jakub Date: Mon Feb 25 14:41:26 2013 New Revision: 196260 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196260 Log: PR c++/56403 * init.c (build_zero_init_1): Use RECORD_OR_UNION_CODE_P instead of CLASS_TYPE_P. * g++.dg/torture/pr56403.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr56403.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog
Fixed on the trunk so far.
Thanks! I'm curious if the fix is likely to get backported? Also, is there a straightforward workaround? Would you expect it to trigger with all cases of a va_list not allocated on the stack?
The fix seems extremely safe, so I think backporting to 4.6 and 4.7 makes sense.
I'm not familiar with gcc's backport process; is there anything I can do to help that along? Is it already in-queue?
(In reply to comment #11) > I'm not familiar with gcc's backport process; is there anything I can do to > help that along? Is it already in-queue? I guess Jakub is extremely busy with the imminent release of GCC 4.8.0. To backport, someone would need to apply the patch here: http://gcc.gnu.org/r196260 to the GCC 4.7 branch here: http://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch/ then bootstrap + regression test and check if there are any new failures. Then submit the patch with an appropriate changelog to gcc-patches. Since the patch is already written, I don't think you need a copyright assignment to do any of this.
Author: jason Date: Thu Mar 14 16:11:37 2013 New Revision: 196660 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196660 Log: PR c++/56403 * init.c (build_zero_init_1): Use RECORD_OR_UNION_CODE_P instead of CLASS_TYPE_P. * g++.dg/torture/pr56403.C: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/torture/pr56403.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/init.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
Author: jason Date: Thu Mar 14 16:12:37 2013 New Revision: 196661 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196661 Log: PR c++/56403 * init.c (build_zero_init_1): Use RECORD_OR_UNION_CODE_P instead of CLASS_TYPE_P. * g++.dg/torture/pr56403.C: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/torture/pr56403.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/init.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
Fixed in 4.6 and 4.7 as well.
Thanks!