Created attachment 358406 [details] dev-db/postgresql-server-9.3.0 build log All is in the title: dev-db/postgresql-server-9.3.0 fails to build on hardened with this ICE error: x86_64-pc-linux-gnu-gcc -march=native -O2 -mtune=native -pipe -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -I../../src/include -I../../src/include -D_GNU_SOURCE -I/usr/include/postgresql-9.3/ '-DSYSTEMTZDIR="/usr/share/zoneinfo"' -c -o pgtz.o pgtz.c pgtz.c: In function 'pg_tzenumerate_start': pgtz.c:352:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://bugs.gentoo.org/> for instructions. {standard input}: Assembler messages: {standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive I think it's related to hardened gcc since I have no problem on my not hardened box. Find full build log attached. # emerge --info =dev-db/postgresql-server-9.3.0 Portage 2.2.2 (hardened/linux/amd64/no-multilib, gcc-4.7.3, glibc-2.17, 3.10.9-hardened-r1 x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.10.9-hardened-r1-x86_64-Intel-R-_Atom-TM-_CPU_D510_@_1.66GHz-with-gentoo-2.2 KiB Mem: 2030488 total, 282984 free KiB Swap: 1048704 total, 971980 free Timestamp of tree: Tue, 10 Sep 2013 11:00:01 +0000 ld GNU ld (GNU Binutils) 2.23.2 app-shells/bash: 4.2_p45 dev-lang/python: 2.7.5-r2, 3.3.2-r2 dev-util/cmake: 2.8.11.1 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.69 sys-devel/automake: 1.12.6, 1.14 sys-devel/binutils: 2.23.2 sys-devel/gcc: 4.7.3 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.11 (virtual/os-headers) sys-libs/glibc: 2.17 Repositories: gentoo gcpan xwing local_portage Installed sets: @system ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -mtune=native -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.5/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=native -O2 -mtune=native -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps y" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs buildsyspkg collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://dagobah.xwing.info/ ftp://ftp.free.fr/mirrors/ftp.gentoo.org/ http://mirror.ovh.net/gentoo-distfiles/ http://gentoo.tiscali.nl/" LANG="fr_FR.utf8" LC_ALL="fr_FR.utf8" LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,--sort-common" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/gcpan-portage /usr/local/portage/portage /usr/local/portage/local-portage" SYNC="rsync://dagobah.xwing.info/gentoo-portage" USE="acl acpi adobe-cff amd64 bash-completion bashlogger bzip2 caps cli cracklib crypt cxx dri fontconfig fpm hardened iconv idn inotify iproute2 ipv6 ithreads jpeg justify mmx mudflap ncurses nls nptl openldap openmp openssl pam pax_kernel pcre png readline sasl session sieve sse sse2 sse3 ssl ssse3 tcpd threads tiff unicode urandom vim-pager vim-syntax xattr zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="fr" NGINX_MODULES_HTTP="access auth_basic autoindex browser charset empty_gif fastcgi gzip headers_more limit_req limit_conn map proxy realip referer rewrite stub_status upstream_ip_hash userid" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON Thanks!
I was unable to reproduce this with stable GCC. Please switch to a stable GCC.
Yes indeed, here in no problem with gcc-4.6 hardened. To sum up: - gcc 4.6.4 hardened => pass - gcc 4.7.3 vanilla => pass - gcc 4.7.3 hardened => fail
I'm not so sure this is a bug with PostgreSQL as much as it might be with Hardened GCC. @toolchain and @hardened, any hints?
(In reply to Aaron W. Swenson from comment #3) > I'm not so sure this is a bug with PostgreSQL as much as it might be with > Hardened GCC. > > @toolchain and @hardened, any hints? The first thing that comes to mind is low memory: pgtz.c:352:1: internal compiler error: Segmentation fault A seg fault in the compiler often indicates that. I don't have 4.7.3 installed so I can't test.
So gcc 4.7 would require much memory than 4.6 ? For the record, this box has 1.5GB free RAM (from a total of 2GB) plus 2 more GB of free swap, and error is 100% reproducible on this particular pgtz.c file. Unless you have a better idea to monitor memory usage of the gcc process, I'm currently rebuilding glibc with splitdebug to check with valgrind.
(In reply to Guillaume Castagnino from comment #5) > Unless you have a better idea to monitor memory usage of the gcc process, > I'm currently rebuilding glibc with splitdebug to check with valgrind. valgind --tool=massif seems not to play with something (pax ?): I cannot retrieve any memory allocation report. If you have other way to check for a potential memory issue, please tell me. By the way, I hope this single 10k source file would not need more than the 1.5GB RAM available to compile. And just to notice, postgres 9.2.4 compiles just fine with the same gcc-4.7 hardened with more or less the same amount of RAM available.
Have you tried compiling with -j1?
(In reply to Aaron W. Swenson from comment #7) > Have you tried compiling with -j1? More than that: I currently directly execute this command manually (taken from build log): coruscant 20:10 - 0.13 /var/tmp/portage/dev-db/postgresql-server-9.3.0/work/postgresql-9.3.0/src/timezone # LC_ALL=C x86_64-pc-linux-gnu-gcc -march=native -O2 -mtune=native -pipe -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -I../../src/include -I../../src/include -D_GNU_SOURCE -I/usr/include/postgresql-9.3/ '-DSYSTEMTZDIR="/usr/share/zoneinfo"' -c -o pgtz.o pgtz.c pgtz.c: In function 'pg_tzenumerate_start': pgtz.c:352:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://bugs.gentoo.org/> for instructions. {standard input}: Assembler messages: {standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
dev-db/postgresql-server-9.3.0 build fine for me with 8GB Portage 2.2.4 (hardened/linux/amd64, gcc-4.7.3, glibc-2.17, 3.8.10-hardened x86_64) ================================================================= System uname: Linux-3.8.10-hardened-x86_64-Intel-R-_Core-TM-_i7_CPU_Q_720_@_1.60GHz-with-gentoo-2.2 KiB Mem: 8120144 total, 5265124 free KiB Swap: 0 total, 0 free Timestamp of tree: Fri, 13 Sep 2013 18:15:01 +0000 ld GNU ld (GNU Binutils) 2.23.2 app-shells/bash: 4.2_p45 dev-java/java-config: 2.2.0 dev-lang/python: 2.6.8-r3, 2.7.5-r2, 3.2.5-r2, 3.3.2-r2 dev-util/cmake: 2.8.11.1 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12 sys-apps/sandbox: 2.6-r1::x-portage sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.8.5-r4, 1.9.6-r3, 1.11.6, 1.12.6, 1.13.4, 1.14 sys-devel/binutils: 2.23.2 sys-devel/gcc: 4.4.4-r2, 4.5.3-r2, 4.6.4, 4.7.3, 4.8.1 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.11 (virtual/os-headers) sys-libs/glibc: 2.17 Hardened compile need more mem then the default one. and for me it looks like it run out of mem when compilening.
I just rebooted, and I have now 1.7GB memory available, but same thing, this still fails. But some news: switching from -O2 to -O1 make the compilation pass. -Os is working too: coruscant 22:02 - 0.01 /var/tmp/portage/dev-db/postgresql-server-9.3.0-r1/work/postgresql-9.3.0/src/timezone # LC_ALL=C x86_64-pc-linux-gnu-gcc -march=native -O1 -mtune=native -pipe -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -I../../src/include -I../../src/include -D_GNU_SOURCE -I/usr/include/postgresql-9.3/ '-DSYSTEMTZDIR="/usr/share/zoneinfo"' -c -o pgtz.o pgtz.c coruscant 22:04 - 0.00 /var/tmp/portage/dev-db/postgresql-server-9.3.0-r1/work/postgresql-9.3.0/src/timezone # LC_ALL=C x86_64-pc-linux-gnu-gcc -march=native -O2 -mtune=native -pipe -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -I../../src/include -I../../src/include -D_GNU_SOURCE -I/usr/include/postgresql-9.3/ '-DSYSTEMTZDIR="/usr/share/zoneinfo"' -c -o pgtz.o pgtz.c pgtz.c: In function 'pg_tzenumerate_start': pgtz.c:352:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://bugs.gentoo.org/> for instructions. {standard input}: Assembler messages: {standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive coruscant 22:04 - 0.00 /var/tmp/portage/dev-db/postgresql-server-9.3.0-r1/work/postgresql-9.3.0/src/timezone # LC_ALL=C x86_64-pc-linux-gnu-gcc -march=native -O3 -mtune=native -pipe -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -I../../src/include -I../../src/include -D_GNU_SOURCE -I/usr/include/postgresql-9.3/ '-DSYSTEMTZDIR="/usr/share/zoneinfo"' -c -o pgtz.o pgtz.c pgtz.c: In function 'pg_tzenumerate_start': pgtz.c:352:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://bugs.gentoo.org/> for instructions. {standard input}: Assembler messages: {standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive coruscant 22:04 - 0.00 /var/tmp/portage/dev-db/postgresql-server-9.3.0-r1/work/postgresql-9.3.0/src/timezone # LC_ALL=C x86_64-pc-linux-gnu-gcc -march=native -Os -mtune=native -pipe -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -I../../src/include -I../../src/include -D_GNU_SOURCE -I/usr/include/postgresql-9.3/ '-DSYSTEMTZDIR="/usr/share/zoneinfo"' -c -o pgtz.o pgtz.c coruscant 22:04 - 0.00 /var/tmp/portage/dev-db/postgresql-server-9.3.0-r1/work/postgresql-9.3.0/src/timezone
What happen if you lower your MAKEOPTS?
(In reply to Magnus Granberg from comment #11) > What happen if you lower your MAKEOPTS? Same thing. I have perhaps not clearly explained, but in the comments above, I directly execute the gcc statement "by hand" inside the compile dir, not through "make" or "emerge", so there cannot be any parallelism issue since only *one* gcc command is launched. Anyway, -O1 seems fine and compiles, so -O2 seems to have insane memory requirements for this sole file. What is strange is that postgres 9.2.4 has not the same problem…
(In reply to Guillaume Castagnino from comment #8) > (In reply to Aaron W. Swenson from comment #7) > > Have you tried compiling with -j1? > > More than that: I currently directly execute this command manually (taken > from build log): > coruscant 20:10 - 0.13 > /var/tmp/portage/dev-db/postgresql-server-9.3.0/work/postgresql-9.3.0/src/ > timezone > # LC_ALL=C x86_64-pc-linux-gnu-gcc -march=native -O2 -mtune=native -pipe > -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement > -Wendif-labels -Wmissing-format-attribute -Wformat-security > -fno-strict-aliasing -fwrapv -fexcess-precision=standard -I../../src/include > -I../../src/include -D_GNU_SOURCE -I/usr/include/postgresql-9.3/ > '-DSYSTEMTZDIR="/usr/share/zoneinfo"' -c -o pgtz.o pgtz.c > pgtz.c: In function 'pg_tzenumerate_start': > pgtz.c:352:1: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See <http://bugs.gentoo.org/> for instructions. > {standard input}: Assembler messages: > {standard input}: Error: open CFI at the end of file; missing .cfi_endproc > directive Can you test with -save-temp added to the command line? It will make some *.i* files that can be run in cc1 to debug the compiler can you attach them to the bug?
Created attachment 358892 [details] pgtz.tgz (In reply to Magnus Granberg from comment #13) > Can you test with -save-temp added to the command line? > It will make some *.i* files that can be run in cc1 to debug the compiler > can you attach them to the bug? It has generated pgtz.i and pgtz.s attached here in a tar.gz
I have a gdb backtrace: Of course it misses debugging symbols, but there may have some informations: (gdb) run -march=native -O2 -mtune=native -pipe -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -I../../src/include -I../../src/include -D_GNU_SOURCE -I/usr/include/postgresql-9.3/ '-DSYSTEMTZDIR="/usr/share/zoneinfo"' -c -o pgtz.o pgtz.c Starting program: /usr/x86_64-pc-linux-gnu/gcc-bin/4.7.3/x86_64-pc-linux-gnu-gcc -march=native -O2 -mtune=native -pipe -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -I../../src/include -I../../src/include -D_GNU_SOURCE -I/usr/include/postgresql-9.3/ '-DSYSTEMTZDIR="/usr/share/zoneinfo"' -c -o pgtz.o pgtz.c [New process 10374] process 10374 is executing new program: /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.3/cc1 Program received signal SIGSEGV, Segmentation fault. [Switching to process 10374] 0x000000000099efd9 in ?? () (gdb) bt #0 0x000000000099efd9 in ?? () #1 0x000000000099f2df in ?? () #2 0x0000000000b50198 in ?? () #3 0x000000000065948d in final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*) () #4 0x0000000000659d05 in final(rtx_def*, _IO_FILE*, int) () #5 0x000000000065a0e7 in ?? () #6 0x0000000000759ea1 in execute_one_pass(opt_pass*) () #7 0x000000000075a20d in execute_pass_list(opt_pass*) () #8 0x000000000075a21f in execute_pass_list(opt_pass*) () #9 0x000000000075a21f in execute_pass_list(opt_pass*) () #10 0x000000000084a87e in tree_rest_of_compilation(tree_node*) () #11 0x00000000005b6320 in ?? () #12 0x00000000005b7d4a in cgraph_optimize() () #13 0x00000000005b81ff in cgraph_finalize_compilation_unit() () #14 0x00000000004e513a in c_write_global_declarations() () #15 0x00000000007fd95e in toplev_main(int, char**) () #16 0x000003fff6c43926 in ?? () #17 0x0000000000000000 in ?? () Adress 0x000000000099efd9 where it segfault is in the data section of cc1, not in some lib. So from my understanding, this should not be related to a memory allocation failure, since in such case, the segfault would occur inside the libc address space, wouldn't it? And by the way, since gdb stop the process when it segfaults, I can check the memory consumption of the cc1 process at this moment => 16MB RSS. So this definitely not looks like a memory pressure issue to me. If someone has an idea :)
Can't get cc1 to segfault with your pgtz.i file. Do you have any strace from the segfault? Make a core dump that can be run in gdb or make cc1 with debugsymbols and source so you can debug it. You can use the .i file to debug cc1 direcly if you pass all the options that gcc pass to cc1.
Ok, I recompiled gcc with debug symbols. If you cannot reproduce, perhaps it's because of the very different cpu. Mine is a ATOM. If I remind correctly, there are many differences compared to "standards" pentium (in order arch instead of out of order for example, that may lead to very different optimization if I'm not mistaken). Now the segfault. It seems it's a null pointer dereference: process 11665 is executing new program: /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.3/cc1 Program received signal SIGSEGV, Segmentation fault. [Switching to process 11665] distance_non_agu_define_in_bb (regno1=regno1@entry=6, regno2=regno2@entry=4294967295, insn=insn@entry=0x3fff6731438, distance=distance@entry=0, start=<optimized out>, found=found@entry=0x3ffffffcdd7) at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/config/i386/i386.c:16626 16626 if (prev == BB_HEAD (bb)) (gdb) bt #0 distance_non_agu_define_in_bb (regno1=regno1@entry=6, regno2=regno2@entry=4294967295, insn=insn@entry=0x3fff6731438, distance=distance@entry=0, start=<optimized out>, found=found@entry=0x3ffffffcdd7) at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/config/i386/i386.c:16626 #1 0x000000000099f2df in distance_non_agu_define (insn=0x3fff6731438, regno2=4294967295, regno1=6) at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/config/i386/i386.c:16684 #2 ix86_lea_outperforms (insn=0x3fff6731438, regno0=4, regno1=6, regno2=4294967295, split_cost=0) at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/config/i386/i386.c:16850 #3 0x0000000000b50198 in output_62 (operands=0x138f9e0 <recog_data>, insn=0x3fff6731438) at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/config/i386/i386.md:1969 #4 0x000000000065948d in final_scan_insn (insn=insn@entry=0x3fff6731438, file=file@entry=0x3fff6fc70e0, optimize_p=optimize_p@entry=2, nopeepholes=nopeepholes@entry=0, seen=seen@entry=0x3ffffffcef4) at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/final.c:2682 #5 0x0000000000659d05 in final (first=0x3fff6718840, file=0x3fff6fc70e0, optimize_p=2) at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/final.c:1786 #6 0x000000000065a0e7 in rest_of_handle_final () at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/final.c:4319 #7 0x0000000000759ea1 in execute_one_pass (pass=pass@entry=0x12676a0 <pass_final>) at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/passes.c:2084 #8 0x000000000075a20d in execute_pass_list (pass=0x12676a0 <pass_final>) at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/passes.c:2139 #9 0x000000000075a21f in execute_pass_list (pass=0x1268440 <pass_postreload>) at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/passes.c:2140 #10 0x000000000075a21f in execute_pass_list (pass=0x12684a0 <pass_rest_of_compilation>) at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/passes.c:2140 #11 0x000000000084a87e in tree_rest_of_compilation (fndecl=fndecl@entry=0x3fff6a02f00) at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/tree-optimize.c:422 #12 0x00000000005b6320 in cgraph_expand_function (node=0x3fff69edd80) at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/cgraphunit.c:1837 #13 0x00000000005b7d4a in cgraph_expand_all_functions () at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/cgraphunit.c:1904 #14 cgraph_optimize () at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/cgraphunit.c:2218 #15 0x00000000005b81ff in cgraph_finalize_compilation_unit () at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/cgraphunit.c:1344 #16 0x00000000004e513a in c_write_global_declarations () at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/c-decl.c:10032 #17 0x00000000007fd95e in compile_file () at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/toplev.c:573 #18 do_compile () at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/toplev.c:1929 #19 toplev_main (argc=64, argv=0x3ffffffd238) at /var/tmp/portage/sys-devel/gcc-4.7.3/work/gcc-4.7.3/gcc/toplev.c:2005 #20 0x000003fff6c43926 in ?? () #21 0x0000000000000000 in ?? () (gdb) l 16621 } 16622 } 16623 16624 next = prev; 16625 } 16626 if (prev == BB_HEAD (bb)) 16627 break; 16628 16629 prev = PREV_INSN (prev); 16630 } (gdb) p bb $1 = (basic_block) 0x0 Hmm, the macro BB_HEAD is: #define BB_HEAD(B) (B)->il.rtl->head_ Yeah, it's a gcc bug :)
And, here is the upstream bug ! http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56707
so problem was not hardened, it's atom with gcc-4.7
*** This bug has been marked as a duplicate of bug 461694 ***
