Bug 56403 - [4.6/4.7 Regression] internal compiler error: in build_zero_init_1, at cp/init.c:279
Summary: [4.6/4.7 Regression] internal compiler error: in build_zero_init_1, at cp/ini...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.7.2
: P2 normal
Target Milestone: 4.6.4
Assignee: Jakub Jelinek
URL:
Keywords: ice-on-valid-code, patch
Depends on:
Blocks:
 
Reported: 2013-02-19 22:13 UTC by Adam Seering
Modified: 2013-03-14 16:41 UTC (History)
3 users (show)

See Also:
Host:
Target: x86_64-linux-gnu
Build:
Known to work: 4.8.0
Known to fail: 4.2.2, 4.3.5, 4.4.5
Last reconfirmed: 2013-02-19 00:00:00


Attachments
Preprocessed output from the source files that reproduce this bug (134.86 KB, text/plain)
2013-02-19 22:13 UTC, Adam Seering
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Seering 2013-02-19 22:13:02 UTC
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.
Comment 1 Paolo Carlini 2013-02-19 22:16:53 UTC
Confirmed.
Comment 2 Andrew Pinski 2013-02-19 23:49:28 UTC
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());
 }
Comment 3 Jakub Jelinek 2013-02-20 07:05:27 UTC
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?
Comment 4 Jakub Jelinek 2013-02-20 11:52:25 UTC
Alternatively build_zero_init_1 could use RECORD_OR_UNION_CODE_P (TREE_CODE (type)) instead of CLASS_TYPE_P (type).
Comment 5 Marek Polacek 2013-02-20 15:17:58 UTC
(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.
Comment 6 Jason Merrill 2013-02-23 05:22:22 UTC
(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.
Comment 7 Jakub Jelinek 2013-02-25 14:41:31 UTC
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
Comment 8 Jakub Jelinek 2013-02-25 14:43:13 UTC
Fixed on the trunk so far.
Comment 9 Adam Seering 2013-03-04 16:43:07 UTC
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?
Comment 10 Jason Merrill 2013-03-04 17:02:23 UTC
The fix seems extremely safe, so I think backporting to 4.6 and 4.7 makes sense.
Comment 11 Adam Seering 2013-03-14 13:15:02 UTC
I'm not familiar with gcc's backport process; is there anything I can do to help that along?  Is it already in-queue?
Comment 12 Manuel López-Ibáñez 2013-03-14 15:43:28 UTC
(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.
Comment 13 Jason Merrill 2013-03-14 16:11:56 UTC
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
Comment 14 Jason Merrill 2013-03-14 16:12:58 UTC
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
Comment 15 Jason Merrill 2013-03-14 16:28:10 UTC
Fixed in 4.6 and 4.7 as well.
Comment 16 Adam Seering 2013-03-14 16:41:57 UTC
Thanks!