[Bug debug/66068] [6 Regression] error: type variant has different TYPE_VFIELD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66068 Matt Hargett matt at use dot net changed: What|Removed |Added CC||matt at use dot net --- Comment #5 from Matt Hargett matt at use dot net --- I also saw this when compiling qemu with latest Ubuntu gcc-snapshot 6.0.0 20150722: /home/matt/src/qemu-arm/exec.c:462:1: error: type variant has different TYPE_VFIELD }; ^ record_type 0x7fcf97fcc150 VMStateDescription asm_written type_0 BLK size integer_cst 0x7fcf98d34f00 type integer_type 0x7fcf98f212a0 bitsizetype constant 576 unit size integer_cst 0x7fcf98dad108 type integer_type 0x7fcf98f211f8 sizetype constant 72 align 64 symtab -1745049488 alias set -1 canonical type 0x7fcf97fcc150 fields field_decl 0x7fcf97c658e8 name type pointer_type 0x7fcf98f421f8 type integer_type 0x7fcf98f42150 char asm_written public unsigned DI size integer_cst 0x7fcf98f1dca8 constant 64 unit size integer_cst 0x7fcf98f1dcc0 constant 8 align 64 symtab -1727089808 alias set -1 canonical type 0x7fcf98f421f8 pointer_to_this pointer_type 0x7fcf98f42a80 unsigned DI file /home/matt/src/qemu-arm/include/migration/vmstate.h line 128 col 17 size integer_cst 0x7fcf98f1dca8 64 unit size integer_cst 0x7fcf98f1dcc0 8 align 64 offset_align 128 offset integer_cst 0x7fcf98f1dcd8 constant 0 bit offset integer_cst 0x7fcf98f1dd20 constant 0 context record_type 0x7fcf97fcc150 VMStateDescription chain field_decl 0x7fcf97c65980 unmigratable type integer_type 0x7fcf98f217e0 int SI file /home/matt/src/qemu-arm/include/migration/vmstate.h line 129 col 9 size integer_cst 0x7fcf98f1dee8 constant 32 unit size integer_cst 0x7fcf98f1df00 constant 4 align 32 offset_align 128 offset integer_cst 0x7fcf98f1dcd8 0 bit offset integer_cst 0x7fcf98f1dca8 64 context record_type 0x7fcf97fcc150 VMStateDescription chain field_decl 0x7fcf97c65a18 version_id chain type_decl 0x7fcf97fc4850 D.19553 record_type 0x7fcf97c63e70 VMStateDescription readonly asm_written BLK size integer_cst 0x7fcf98d34f00 type integer_type 0x7fcf98f212a0 bitsizetype constant 576 unit size integer_cst 0x7fcf98dad108 type integer_type 0x7fcf98f211f8 sizetype constant 72 align 64 symtab -1748613568 alias set -1 canonical type 0x7fcf97fcc690 fields field_decl 0x7fcf97c658e8 name type pointer_type 0x7fcf98f421f8 type integer_type 0x7fcf98f42150 char asm_written public unsigned DI size integer_cst 0x7fcf98f1dca8 constant 64 unit size integer_cst 0x7fcf98f1dcc0 constant 8 align 64 symtab -1727089808 alias set -1 canonical type 0x7fcf98f421f8 pointer_to_this pointer_type 0x7fcf98f42a80 unsigned DI file /home/matt/src/qemu-arm/include/migration/vmstate.h line 128 col 17 size integer_cst 0x7fcf98f1dca8 64 unit size integer_cst 0x7fcf98f1dcc0 8 align 64 offset_align 128 offset integer_cst 0x7fcf98f1dcd8 constant 0 bit offset integer_cst 0x7fcf98f1dd20 constant 0 context record_type 0x7fcf97fcc150 VMStateDescription chain field_decl 0x7fcf97c65980 unmigratable type integer_type 0x7fcf98f217e0 int SI file /home/matt/src/qemu-arm/include/migration/vmstate.h line 129 col 9 size integer_cst 0x7fcf98f1dee8 constant 32 unit size integer_cst 0x7fcf98f1df00 constant 4 align 32 offset_align 128 offset integer_cst 0x7fcf98f1dcd8 0 bit offset integer_cst 0x7fcf98f1dca8 64 context record_type 0x7fcf97fcc150 VMStateDescription chain field_decl 0x7fcf97c65a18 version_id pointer_to_this pointer_type 0x7fcf97c63f18 /home/matt/src/qemu-arm/exec.c:462:1: internal compiler error: verify_type failed
[Bug middle-end/65289] [5.0 regression] ICE when compiling libjpegturbo with -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65289 --- Comment #1 from Matt Hargett matt at use dot net --- Also reproducible with -O2 -fgraphite-identity . I use both of these optimizations regularly to help get the most out of prefetch on the embedded ARM targets I work on.
[Bug middle-end/65289] New: [5.0 regression] ICE when compiling libjpegturbo with -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65289 Bug ID: 65289 Summary: [5.0 regression] ICE when compiling libjpegturbo with -floop-nest-optimize Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: matt at use dot net Created attachment 34929 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34929action=edit pre-processed source file that reproduces the crash Using either Ubuntu's gcc-snapshot on amd64 and my armv6j cross-compiling toolchain, I get a crash when compiling libjpegturbo 1.4.0 from sources when using -floop-nest-optimize. Pre-processed source is attached (generated by cross-toolchain, but amd64 GCC reproduces same crash). The crash does NOT happen with 4.9.1 from Ubuntu 14.10 on amd64. Ubuntu version string: gcc (Ubuntu 20150225-1ubuntu1) 5.0.0 20150225 (experimental) [trunk revision 220970] armv6j cross-compiler built from SVN version string: arm-kindle-linux-gnueabi-gcc (GCC) 5.0.0 20150224 (experimental) To reproduce: CFLAGS=-O2 -floop-nest-optimize CC=/path/to/gcc5/bin/gcc ./configure --disable-static --without-simd make or /path/to/gcc5/bin/gcc -O2 -floop-nest-optimize turbojpeg.c.i result: turbojpeg.c: In function 'tjCompress2': turbojpeg.c:713:6: error: loop 3's latch is marked as part of irreducible region DLLEXPORT int DLLCALL tjCompress2(tjhandle handle, unsigned char *srcBuf, ^ turbojpeg.c:713:6: error: edge from 64 to 78 should be marked irreducible turbojpeg.c:713:6: error: basic block 78 should be marked irreducible turbojpeg.c:713:6: error: edge from 78 to 82 should be marked irreducible turbojpeg.c:713:6: error: edge from 78 to 92 should be marked irreducible turbojpeg.c:713:6: error: basic block 92 should be marked irreducible turbojpeg.c:713:6: error: edge from 92 to 98 should be marked irreducible turbojpeg.c:713:6: error: edge from 92 to 95 should be marked irreducible turbojpeg.c:713:6: error: basic block 95 should be marked irreducible turbojpeg.c:713:6: error: edge from 95 to 93 should be marked irreducible turbojpeg.c:713:6: error: basic block 98 should be marked irreducible turbojpeg.c:713:6: error: edge from 98 to 96 should be marked irreducible turbojpeg.c:713:6: error: edge from 99 to 100 should be marked irreducible turbojpeg.c:713:6: error: basic block 100 should be marked irreducible turbojpeg.c:713:6: error: edge from 100 to 94 should be marked irreducible turbojpeg.c:713:6: error: basic block 94 should be marked irreducible turbojpeg.c:713:6: error: edge from 94 to 93 should be marked irreducible turbojpeg.c:713:6: error: basic block 93 should be marked irreducible turbojpeg.c:713:6: error: edge from 93 to 81 should be marked irreducible turbojpeg.c:713:6: error: basic block 81 should be marked irreducible turbojpeg.c:713:6: error: edge from 81 to 79 should be marked irreducible turbojpeg.c:713:6: error: basic block 82 should be marked irreducible turbojpeg.c:713:6: error: edge from 82 to 88 should be marked irreducible turbojpeg.c:713:6: error: edge from 82 to 85 should be marked irreducible turbojpeg.c:713:6: error: basic block 85 should be marked irreducible turbojpeg.c:713:6: error: edge from 85 to 83 should be marked irreducible turbojpeg.c:713:6: error: basic block 88 should be marked irreducible turbojpeg.c:713:6: error: edge from 88 to 86 should be marked irreducible turbojpeg.c:713:6: error: edge from 89 to 90 should be marked irreducible turbojpeg.c:713:6: error: basic block 90 should be marked irreducible turbojpeg.c:713:6: error: edge from 90 to 84 should be marked irreducible turbojpeg.c:713:6: error: basic block 84 should be marked irreducible turbojpeg.c:713:6: error: edge from 84 to 83 should be marked irreducible turbojpeg.c:713:6: error: basic block 83 should be marked irreducible turbojpeg.c:713:6: error: edge from 83 to 80 should be marked irreducible turbojpeg.c:713:6: error: basic block 80 should be marked irreducible turbojpeg.c:713:6: error: edge from 80 to 79 should be marked irreducible turbojpeg.c:713:6: error: basic block 79 should be marked irreducible turbojpeg.c:713:6: error: edge from 79 to 67 should be marked irreducible turbojpeg.c:713:6: error: basic block 67 should be marked irreducible turbojpeg.c:713:6: error: edge from 67 to 65 should be marked irreducible turbojpeg.c:713:6: error: edge from 68 to 71 should be marked irreducible turbojpeg.c:713:6: error: basic block 71 should be marked irreducible turbojpeg.c:713:6: error: edge from 71 to 69 should be marked irreducible turbojpeg.c:713:6: error: basic block 72 should not be marked irreducible turbojpeg.c:713:6: error: edge from 72 to 77 should not be marked irreducible turbojpeg.c:713:6: error: basic block 77 should not be marked irreducible turbojpeg.c:713:6: error: edge from 77 to 75 should not be marked irreducible
[Bug middle-end/55500] [devirt] trunk fails inline-devirt test #7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55500 --- Comment #4 from Matt Hargett matt at use dot net --- Phillip, the problem is not that the program doesn't run properly. It's that the code isn't inline via de-virtualization when it could be. The main() should contain a few printf/puts calls and nothing more.
[Bug ipa/55499] [devirt] trunk fails to eliminate dead functions where all call sites were inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55499 Matt Hargett matt at use dot net changed: What|Removed |Added Component|middle-end |ipa Version|4.8.0 |4.9.0 --- Comment #2 from Matt Hargett matt at use dot net --- still the case with current trunk.
[Bug middle-end/55477] [devirt] trunk fails inline-devirt tests #2 and and #3 whereas they pass in google/4_7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477 Matt Hargett matt at use dot net changed: What|Removed |Added Status|NEW |RESOLVED Version|4.8.0 |4.9.0 Resolution|--- |FIXED --- Comment #8 from Matt Hargett matt at use dot net --- this is resolved, except for the test cases being added. it looks like there are variants that may cover the cases, but someone should verify the attached testcases don't exercise slightly different things.
[Bug middle-end/55478] [devirt] trunk fails inline-devirt test #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478 Matt Hargett matt at use dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Matt Hargett matt at use dot net --- passes on current trunk, modulo the lack of DCE as tracked by another bug.
[Bug middle-end/55498] [devirt] trunk fails inline-devirt test #6 due to lack of return functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55498 Matt Hargett matt at use dot net changed: What|Removed |Added Version|4.8.0 |4.9.0 --- Comment #5 from Matt Hargett matt at use dot net --- same result on current trunk. has the iterating param been introduced in 4.9?
[Bug middle-end/55500] [devirt] trunk fails inline-devirt test #7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55500
Matt Hargett matt at use dot net changed:
What|Removed |Added
Version|4.8.0 |4.9.0
--- Comment #2 from Matt Hargett matt at use dot net ---
still fails with current trunk.
this factory pattern is one of the very common C++ abstraction patterns we got
to devirtualize with Maxim's work in 2010. all our previous tests were building
up to this real issue in the high-performance networking products I was working
on at the time. I'd be surprised if real-world products see a notable speed-up
if this tests {7,8,9} don't pass.
[Bug bootstrap/57486] New: bootstrap fails on 4.8 and google/4.8 branch on RHEL6.1 platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57486 Bug ID: 57486 Summary: bootstrap fails on 4.8 and google/4.8 branch on RHEL6.1 platform Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: matt at use dot net I'm getting this failure when trying to bootstrap on RHEL6.1, with either the system compiler (gcc 4.4.x) or a 4.7-based compiler I bootstrapped successfully before: ../configure --prefix=/u/mhargett --with-cloog=/usr/home/nfs-readonly/mhargett --with-isl=/usr/home/nfs-readonly/mhargett --with-gmp=/usr/home/nfs-readonly/mhargett --with-mpfr=/usr/home/nfs-readonly/mhargett --with-ppl=/usr/home/nfs-readonly/mhargett --with-isl=/usr/home/nfs-readonly/mhargett/ --disable-isl-version-check --with-build-config=bootstrap-lto --enable-languages=c,c++,lto --enable-gold=yes --enable-lto /opt/gcc-google-4.7-v7/bin/g++-google-4.7 -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I/usr/home/nfs-readonly/mhargett/include -I/usr/home/nfs-readonly/mhargett/include -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace -DCLOOG_INT_GMP -I/usr/home/nfs-readonly/mhargett/include -I/usr/home/nfs-readonly/mhargett//include ../../gcc/graphite-dependences.c -o graphite-dependences.o In file included from ../../gcc/dbgcnt.h:28:0, from ../../gcc/graphite.c:57: ../../gcc/dbgcnt.def:149:1: error: \u2018clone\u2019 redeclared as different kind of symbol In file included from /usr/include/sched.h:43:0, from /usr/include/pthread.h:25, from /opt/gcc-google-4.7-v7/lib/gcc/x86_64-unknown-linux-gnu/4.7.x-google/../../../../include/c++/4.7.x-google/x86_64-unknown-linux-gnu/bits/gthr-default.h:41, from /opt/gcc-google-4.7-v7/lib/gcc/x86_64-unknown-linux-gnu/4.7.x-google/../../../../include/c++/4.7.x-google/x86_64-unknown-linux-gnu/bits/gthr.h:150, from /opt/gcc-google-4.7-v7/lib/gcc/x86_64-unknown-linux-gnu/4.7.x-google/../../../../include/c++/4.7.x-google/ext/atomicity.h:34, from /opt/gcc-google-4.7-v7/lib/gcc/x86_64-unknown-linux-gnu/4.7.x-google/../../../../include/c++/4.7.x-google/bits/ios_base.h:41, from /opt/gcc-google-4.7-v7/lib/gcc/x86_64-unknown-linux-gnu/4.7.x-google/../../../../include/c++/4.7.x-google/ios:43, from /opt/gcc-google-4.7-v7/lib/gcc/x86_64-unknown-linux-gnu/4.7.x-google/../../../../include/c++/4.7.x-google/ostream:40, from /opt/gcc-google-4.7-v7/lib/gcc/x86_64-unknown-linux-gnu/4.7.x-google/../../../../include/c++/4.7.x-google/iostream:40, from /usr/home/nfs-readonly/mhargett/include/isl/int.h:17, from /usr/home/nfs-readonly/mhargett/include/isl/ctx.h:16, from /usr/home/nfs-readonly/mhargett/include/isl/map_type.h:4, from /usr/home/nfs-readonly/mhargett/include/isl/set.h:13, from ../../gcc/graphite.c:38: /usr/include/bits/sched.h:83:12: error: previous declaration of \u2018int clone(int (*)(void*), void*, int, void*, ...)\u2019 make[3]: *** [graphite.o] Error 1 make[3]: *** Waiting for unfinished jobs the problem is this line in dbgcnt.def: DEBUG_COUNTER (clone) unless there's a better suggestion, I'll attach a patch that renames the counter to clone_function.
[Bug middle-end/56526] [4.8 regression] false positive for maybe-uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56526 --- Comment #4 from Matt Hargett matt at use dot net 2013-03-06 02:06:03 UTC --- It does fix that warning, but there's a bug in the analysis that makes it a false positive. I've had difficulty reducing it to a self-contained example, and I don't have the expertise to do more in-depth debugging. This should stay open until the analysis is done to show that it's an accepted limitation of the warning's capabilities, IMO.
[Bug middle-end/56526] New: [4.8 regression] false positive for maybe-uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56526 Bug #: 56526 Summary: [4.8 regression] false positive for maybe-uninitialized Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net I haven't tracked down when this started happening, but it's a regression from fsf/4.7 and google/4.7, as well as trunk from some months ago. /work/mhargett/gcc-trunk-lto-O3/./prev-gcc/xg++ -B/work/mhargett/gcc-trunk-lto-O3/./prev-gcc/ -B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++ -L/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -O3 -g -flto=jobserver -frandom-seed=1 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc gcc-nm.o -o gcc-nm \ file-find.o libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a ../../gcc-trunk/libiberty/simple-object-mach-o.c: In function 'simple_object_mach_o_find_sections': ../../gcc-trunk/libiberty/simple-object-mach-o.c:653:37: error: 'wrapper_sect_offset' may be used uninitialized in this function [-Werror=maybe-uninitialized] secoffset = wrapper_sect_offset + subsect_offset; ^ lto1: all warnings being treated as errors make[4]: *** [/tmp/ccGVpjK3.ltrans21.ltrans.o] Error 1 ../../gcc-trunk/libiberty/simple-object-mach-o.c: In function 'simple_object_mach_o_find_sections': ../../gcc-trunk/libiberty/simple-object-mach-o.c:653:37: error: 'wrapper_sect_offset' may be used uninitialized in this function [-Werror=maybe-uninitialized] secoffset = wrapper_sect_offset + subsect_offset; ^ lto1: all warnings being treated as errors make[4]: *** [/tmp/ccGVpjK3.ltrans21.ltrans.o] Error 1 lto-wrapper: make returned 2 exit status /u/mhargett/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status make[3]: *** [lto-wrapper] Error 1 make[3]: *** Waiting for unfinished jobs mv -f Tcollect2 collect2 make[3]: Leaving directory `/work/mhargett/gcc-trunk-lto-O3/gcc' make[2]: *** [all-stage2-gcc] Error 2 wrapper_sect_offset is initialized in the block predicated by ((gnu_sections_found SOMO_WRAPPING) != 0), and is only accessed in a block with the same (outer) predicate. reproduced with bootstrap-lto on current trunk with -O3. save-temp outputs are attached.
[Bug middle-end/56526] [4.8 regression] false positive for maybe-uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56526 --- Comment #1 from Matt Hargett matt at use dot net 2013-03-04 19:04:58 UTC --- Created attachment 29580 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29580 save-temps output from same commandline/path
[Bug bootstrap/55644] bootstrap-lto fails on current trunk (with and without profiledbootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644 --- Comment #10 from Matt Hargett matt at use dot net 2013-03-01 23:11:50 UTC --- I'll file a new bug for each warning false positive that results in a bootstrap failure. Feel free to close this one.
[Bug bootstrap/55644] maybe-uninitialized false positive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644 Matt Hargett matt at use dot net changed: What|Removed |Added Summary|bootstrap-lto fails on |maybe-uninitialized false |current trunk (with and |positive |without profiledbootstrap) | --- Comment #11 from Matt Hargett matt at use dot net 2013-03-01 23:34:53 UTC --- The current false positives emitted: mhargett@chert:/work/mhargett/gcc-trunk-lto-O3-debug/gcc$ /work/mhargett/gcc-trunk-lto-O3-debug/./prev-gcc/xg++ -B/work/mhargett/gcc-trunk-lto-O3-debug/./prev-gcc/ -B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++ -L/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -O3 -g -flto=jobserver -flto-partition=none -frandom-seed=1 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc gcov-dump.o libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -o gcov-dump ../../gcc-trunk/libbacktrace/elf.c: In function 'elf_add': ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.len' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (munmap (const_cast.v, view-len) 0) ^ ../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.len' was declared here struct backtrace_view ehdr_view; ^ ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.base' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (munmap (const_cast.v, view-len) 0) ^ ../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.base' was declared here struct backtrace_view ehdr_view; ^ ../../gcc-trunk/libbacktrace/elf.c:516:10: error: 'ehdr_view.data' may be used uninitialized in this function [-Werror=maybe-uninitialized] memcpy (ehdr, ehdr_view.data, sizeof ehdr); ^ ../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.data' was declared here struct backtrace_view ehdr_view; ^ which is a false positive, because ehdr_view's fields are correctly initialized via a call from elf_add() to backtrace_get_view() view-data = (char *) map + inpage; view-base = map; view-len = size; if the mmap() earlier in the backtrace_get_view() didn't fail, view is initialized and the backtrace_get_view() returns 1. if that mmap() fails, view remains uninitialized and backtrace_get_view() returns 0. elf_add()'s invocation checks the return value of backtrace_get_view(). in the 0 (failure) case, backtrace_release_view() is never invoked: if (!backtrace_get_view (state, descriptor, 0, sizeof ehdr, error_callback, data, ehdr_view)) goto fail; since backtrace_release_view() is never called in the case where the fields are uninitialized, the warning is a false positive. while it occurs here with the confluence of several optimizations, it looks like the same problem would happen in a contrived single-file case. attached are the temp files for the module the generated this false positive.
[Bug middle-end/55644] maybe-uninitialized false positive due to incorrect flow analysis when gotos are present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644 --- Comment #12 from Matt Hargett matt at use dot net 2013-03-01 23:38:51 UTC --- Created attachment 29566 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29566 files generated during compilation where false positive happens with save-temps
[Bug tree-optimization/55264] [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264 Matt Hargett matt at use dot net changed: What|Removed |Added CC||matt at use dot net --- Comment #15 from Matt Hargett matt at use dot net 2013-02-19 22:51:57 UTC --- Hey Martin, I noticed that this doesn't apply cleanly to google/4_7 without some massaging. The difference between trunk and google/4_7 might be worth pulling into trunk. Unfortunately, the trail of merge commit log breadcrumbs leads to a dead end :/ From a blame of google/main/gcc/ipa.c: 165972hubicka || (before_inlining_p 195116davidxlDECL_VIRTUAL_P (node-symbol.decl) 195825davidxlcgraph_is_aux_decl_external (node it's that last line that's unique to the google branches, and should probably be merged to trunk.
[Bug bootstrap/55644] bootstrap-lto fails on current trunk (with and without profiledbootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644 --- Comment #7 from Matt Hargett matt at use dot net 2013-02-14 18:00:57 UTC --- Sorry, but wouldn't that be papering over bugs? I'm confounded by the attitude around bootstrap failures, regardless of the basic supported options being used: -O3 with LTO and profile-use. This combination has been in use in 3 different companies I have worked with, since 4.6.x. If it's not a supported configuration to the point where an FSF GCC release can't bootstrap itself consistently without wrong-code/diagnostic false positives, then I'll just plan on sticking to vendor branches -- something I don't want to do since I would prefer not to have another EGCS situation. Let me know how to proceed with these classes of issues.
[Bug middle-end/55478] [devirt] trunk fails inline-devirt test #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478 --- Comment #11 from Matt Hargett matt at use dot net 2013-02-14 21:27:54 UTC --- Attached is an updated version of the tests Maxim committed to the google/4_7 branch. The only difference is that more of the tests are xfail'd than in the older google branch. We could unset the xfail for inline-devirt-4.C if we set it to -O3, but I'd rather track the fact the test hasn't passed at -O2 since the patches Maxim proposed ~2 years ago due to various (possibly nested) regressions in other areas.
[Bug middle-end/55477] [devirt] trunk fails inline-devirt tests #2 and and #3 whereas they pass in google/4_7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477 --- Comment #7 from Matt Hargett matt at use dot net 2013-02-14 21:28:33 UTC --- Created attachment 29455 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29455 diff against trunk adding new testcases
[Bug c/44938] Variable origtypes in c-parser.c accessed uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44938 Matt Hargett matt at use dot net changed: What|Removed |Added CC||matt at use dot net --- Comment #2 from Matt Hargett matt at use dot net 2013-02-12 19:15:31 UTC --- also fails with current trunk with bootstrap-O3 and bootstrap-lto-O3.
[Bug middle-end/55496] False positive -Werror=uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55496 Matt Hargett matt at use dot net changed: What|Removed |Added CC||matt at use dot net --- Comment #1 from Matt Hargett matt at use dot net 2013-02-13 02:08:02 UTC --- Confirmed on current trunk, verified that it's not an issue in google/4_7 branch. Only happens with profiledbootstrap and bootstrap-lto. /var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/obj/./prev-gcc/xg++ -B/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/obj/./prev-gcc/ -B/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/gcc-trunk-r195990/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/libstdc++-v3/libsupc++ -L/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -flto=jobserver -frandom-seed=1 -fprofile-use -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace ../../gcc/cfg.c -o cfg.o ../../gcc/cfg.c: In function 'scale_bbs_frequencies_gcov_type(basic_block_def**, int, long, long)': ../../gcc/cfg.c:943:8: error: 'e' may be used uninitialized in this function [-Werror=maybe-uninitialized] edge e; ^ cc1plus: all warnings being treated as errors make[3]: *** [cfg.o] Error 1
[Bug middle-end/56231] warning traces have bogus line information when using LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231 --- Comment #11 from Matt Hargett matt at use dot net 2013-02-12 01:55:28 UTC --- can you add the reduced test case you came up with to the testsuite? I've seen these issues come and go at various points.
[Bug middle-end/56231] warning traces have bogus line information when using LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
--- Comment #12 from Matt Hargett matt at use dot net 2013-02-12 02:02:33 UTC
---
looking at the patch for merging elsewhere, I noticed that
location_t
lto_input_location (struct bitpack_d *bp, struct data_in *data_in)
{
+ static const char *current_file;
+ static int current_line;
+ static int current_col;
bool file_change, line_change, column_change;
unsigned len;
- bool prev_file = data_in-current_file != NULL;
+ bool prev_file = current_file != NULL;
current_file is potentially of unknown value on the comparison in the last
line, right? or is there some static const initialization rule that implicitly
initializes it to 0?
[Bug middle-end/55477] [devirt] trunk fails inline-devirt tests #2 and and #3 whereas they pass in google/4_7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477
--- Comment #6 from Matt Hargett matt at use dot net 2013-02-11 01:55:51 UTC
---
I just tested with latest trunk (4.8.0 20130210). inline-devirt-2.C does indeed
pass when adding an outer loop, but only at -O3. That is probably fine, but I
could have sworn it used to work with the outer loop with just -O2.
inline-devirt-3.C has seemingly regressed further since my last test, for some
reason. I *have* to supply both -O3 *and* -funroll-loops now to see the correct
number of inlined printf statements in main():
#include stdio.h
class Calculable
{
public:
virtual unsigned char calculate() const = 0;
virtual ~Calculable() {}
};
class X : public Calculable
{
public:
virtual unsigned char calculate() const { return 0; }
};
class Y : public Calculable
{
public:
virtual unsigned char calculate() const { return 3; }
};
static void print(const Calculable c)
{
for (int i = 0; i c.calculate(); i++)
{
printf(%d\n, c.calculate());
}
}
int main()
{
X x;
Y y;
for (int i=3; i 0; i--)
{
print(x);
print(y);
}
return 0;
}
[Bug middle-end/55478] [devirt] trunk fails inline-devirt test #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478 --- Comment #9 from Matt Hargett matt at use dot net 2013-02-11 02:02:46 UTC --- Just tested with latest trunk and it passes at -O3. With Maxim's previous devirt patches, it passed at -O2. That being said, I'm happy and this can be marked as RESOLVED.
[Bug middle-end/55498] [devirt] trunk fails inline-devirt test #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55498
--- Comment #3 from Matt Hargett matt at use dot net 2013-02-11 02:11:36 UTC
---
Just tested with latest trunk and things have regressed/changed a bit. This is
another test case where I *have* to use both -O3 and -funroll-loops to get the
desired effect. This didn't use to be the case. Also, even at -O3 the indirect
references to one() and two() are inlined, but the actual immediates returned
by those functions is not.
#include stdio.h
typedef unsigned char(*Calculable)(void);
typedef Calculable(*CalculateStrategy)(void);
unsigned char one() { return 1; }
Calculable oneStrategy() { return one; }
unsigned char two() { return 2; }
Calculable twoStrategy() { return two; }
static void print(CalculateStrategy calculateStrategy)
{
printf(%d\n, calculateStrategy()());
printf(+1: %d\n, calculateStrategy()() + 1);
}
int main()
{
for (int i = 3; i 0; i--) {
print(oneStrategy);
print(twoStrategy);
}
return 0;
}
[Bug middle-end/56231] New: warning traces have bogus line information when using LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231 Bug #: 56231 Summary: warning traces have bogus line information when using LTO Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net From bootstrapping GCC itself, one gets warnings that have bogus line entries, like the :61: line below: In file included from ../../gcc-trunk/libbacktrace/mmapio.c:116:0, from :61: ../../gcc-trunk/libbacktrace/elf.c: In function 'elf_add': ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.len' may be used uninitialized in this function [-Werror=maybe-uninitialized] On large LTO compilation units, the final link can include some of these kinds of warnings that contain literally hundreds of :0: and :N: entries per warning. To reproduce the above issue, bootstrap trunk like so: ../gcc-trunk/configure --program-suffix=-4.8 --enable-languages=c,c++,lto --prefix=/u/mhargett --with-build-config=bootstrap-lto --enable-lto --with-fpmath=sse --disable-isl-version-check --disable-libmudflap --disable-libssp --enable-gold=yes --disable-multilib --disable-nls BOOT_CFLAGS=-O3 -floop-block -floop-interchange -floop-strip-mine -march=nocona =mtune=core2 CFLAGS_FOR_BUILD=-O3 -floop-block -floop-strip-mine -floop-interchange -march=nocona -mtune=core2 CXXFLAGS_FOR_BUILD=-O3 -floop-block -floop-interchange -floop-strip-mine -march=nocona -mtune=core2 make more complete output from the bootstrap that illustrates this bug: /work/mhargett/gcc-trunk-obj/./prev-gcc/xg++ -B/work/mhargett/gcc-trunk-obj/./prev-gcc/ -B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++ -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -O3 -march=nocona -mtune=core2 -floop-block -floop-interchange -floop-strip-mine -flto=jobserver -frandom-seed=1 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc gcov.o libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -o gcov /work/mhargett/gcc-trunk-obj/./prev-gcc/xg++ -B/work/mhargett/gcc-trunk-obj/./prev-gcc/ -B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++ -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -O3 -march=nocona -mtune=core2 -floop-block -floop-interchange -floop-strip-mine -flto=jobserver -frandom-seed=1 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc gcov-dump.o \ libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -o gcov-dump In file included from ../../gcc-trunk/libbacktrace/mmapio.c:116:0, from :61: ../../gcc-trunk/libbacktrace/elf.c: In function 'elf_add': ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.len' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (munmap (const_cast.v, view-len) 0) ^ In file included from ../../gcc-trunk/libbacktrace/mmapio.c:119:0, from :61: ../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.len' was declared here struct backtrace_view ehdr_view; ^ In file included from
[Bug bootstrap/55644] bootstrap-lto fails on current trunk (with and without profiledbootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644 --- Comment #5 from Matt Hargett matt at use dot net 2013-02-06 01:23:02 UTC --- the latest failure, with current trunk: /work/mhargett/gcc-trunk-obj/./prev-gcc/xg++ -B/work/mhargett/gcc-trunk-obj/./prev-gcc/ -B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++ -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -O3 -march=nocona -mtune=core2 -floop-block -floop-interchange -floop-strip-mine -flto=jobserver -frandom-seed=1 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc gcc-ar.o -o gcc-ar \ file-find.o libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a In file included from ../../gcc-trunk/libbacktrace/mmapio.c:116:0, from :61: ../../gcc-trunk/libbacktrace/elf.c: In function 'elf_add': ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.len' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (munmap (const_cast.v, view-len) 0) ^ In file included from ../../gcc-trunk/libbacktrace/mmapio.c:119:0, from :61: ../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.len' was declared here struct backtrace_view ehdr_view; ^ In file included from ../../gcc-trunk/libbacktrace/mmapio.c:116:0, from :61: ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.base' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (munmap (const_cast.v, view-len) 0) ^ In file included from ../../gcc-trunk/libbacktrace/mmapio.c:119:0, from :61: ../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.base' was declared here struct backtrace_view ehdr_view; ^ In file included from ../../gcc-trunk/libbacktrace/mmapio.c:119:0, from :61: ../../gcc-trunk/libbacktrace/elf.c:516:10: error: 'ehdr_view.data' may be used uninitialized in this function [-Werror=maybe-uninitialized] memcpy (ehdr, ehdr_view.data, sizeof ehdr); ^ In file included from ../../gcc-trunk/libbacktrace/mmapio.c:119:0, from :61: ../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.data' was declared here struct backtrace_view ehdr_view; ^ lto1: all warnings being treated as errors make[4]: *** [/tmp/cc68SyuG.ltrans2.ltrans.o] Error 1 make[4]: *** Waiting for unfinished jobs lto-wrapper: make returned 2 exit status /u/mhargett/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status make[3]: *** [gcov-dump] Error 1 make[3]: *** Waiting for unfinished jobs In file included from ../../gcc-trunk/libiberty/cp-demangle.c:877:0, from :73: ../../gcc-trunk/libbacktrace/elf.c: In function 'backtrace_initialize': ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.len' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (munmap (const_cast.v, view-len) 0) ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0, from :73: ../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.len' was declared here struct backtrace_view ehdr_view; ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:877:0, from :73: ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.base' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (munmap (const_cast.v, view-len) 0) ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0, from :73: ../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.base' was declared here struct backtrace_view ehdr_view; ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0, from :73: ../../gcc-trunk/libbacktrace/elf.c:516:10: error: 'ehdr_view.data' may be used uninitialized in this function [-Werror=maybe-uninitialized
[Bug middle-end/42371] dead code not eliminated during folding with whole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371 --- Comment #13 from Matt Hargett matt at use dot net 2013-01-17 18:28:18 UTC --- No. 4.6 doesn't devirt (at -O2 or -O3) and therefore the DCE isn't relevant. At both -O2 and -O3, with and without -fwhole-program, both with and without adjustin declarations one()/two() to one(void)/two(void): 4.7 and google/4.7 both devirt correctly but the DCE on the function bodies doesn't happen. 4.8 also devirts correctly, but the DCE on the function bodies doesn't happen.
[Bug middle-end/42371] dead code not eliminated during folding with whole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371 Matt Hargett matt at use dot net changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #11 from Matt Hargett matt at use dot net 2013-01-17 00:09:32 UTC --- Still a problem in latest 4.7, google/4.7, and trunk (4.8).
[Bug bootstrap/50148] GCC fails to bootstrap with -O3 due to may be used uninitialized errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50148 --- Comment #7 from Matt Hargett matt at use dot net 2013-01-07 22:14:21 UTC --- This appears to be resolved for me, as of r194995. If someone with permissions can mark as RESOLVED, I'll VERIFY.
[Bug bootstrap/50148] GCC fails to bootstrap with -O3 due to may be used uninitialized errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50148 --- Comment #6 from Matt Hargett matt at use dot net 2012-12-18 17:26:54 UTC --- Applying the supplied patch reveals another issue underneath, which is a false positive: /work/mhargett/gcc-trunk-obj/./prev-gcc/xg++ -B/work/mhargett/gcc-trunk-obj/./prev-gcc/ -B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++ -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -O3 -march=nocona -mtune=core2 -floop-block -floop-interchange -floop-strip-mine -flto=jobserver -frandom-seed=1 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o gengtype \ gengtype.o gengtype-lex.o gengtype-parse.o gengtype-state.o version.o errors.o libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a ../libbacktrace/.libs/libbacktrace.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a In file included from ../../gcc-trunk/libiberty/cp-demangle.c:876:0, from :51: ../../gcc-trunk/libbacktrace/elf.c: In function ‘elf_add’: ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: ‘ehdr_view.len’ may be used uninitialized in this function [-Werror=maybe-uninitialized] if (munmap (const_cast.v, view-len) 0) ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0, from :51: ../../gcc-trunk/libbacktrace/elf.c:476:25: note: ‘ehdr_view.len’ was declared here struct backtrace_view ehdr_view; ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:876:0, from :51: ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: ‘ehdr_view.base’ may be used uninitialized in this function [-Werror=maybe-uninitialized] if (munmap (const_cast.v, view-len) 0) ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0, from :51: ../../gcc-trunk/libbacktrace/elf.c:476:25: note: ‘ehdr_view.base’ was declared here struct backtrace_view ehdr_view; ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0, from :51: ../../gcc-trunk/libbacktrace/elf.c:516:10: error: ‘ehdr_view.data’ may be used uninitialized in this function [-Werror=maybe-uninitialized] memcpy (ehdr, ehdr_view.data, sizeof ehdr); ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0, from :51: ../../gcc-trunk/libbacktrace/elf.c:476:25: note: ‘ehdr_view.data’ was declared here struct backtrace_view ehdr_view; ^ lto1: all warnings being treated as errors make[4]: *** [/tmp/ccQGEpYR.ltrans15.ltrans.o] Error 1 in libbacktrace/elf.c, elf_add() calls backtrace_get_view(..., ehdr_view). ehdr_view isn't initialized. backtrace_get_view() will return 1 and leave edhr_view uninitialized, but the potential uninitialized use of ehdr_view is guarded in get_elf() with a 'goto fail'. Therefore, the uninitialized ehdr_view would never get to backtrace_release_view(). Let me know if I should file a separate bug for this.
[Bug bootstrap/50148] GCC fails to bootstrap with -O3 due to may be used uninitialized errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50148 --- Comment #5 from Matt Hargett matt at use dot net 2012-12-17 19:12:11 UTC --- Just verified this still happens in 4.7 and trunk.
[Bug middle-end/55498] [devirt] trunk fails inline-devirt test #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55498 --- Comment #2 from Matt Hargett matt at use dot net 2012-12-17 23:34:08 UTC --- Would iterating during LTO work in this instance, or would it need to happen during early IPA? is stage3 too late for the IPA-CP enhancement you mention?
[Bug bootstrap/55644] New: profiledbootstrap fails on current trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644 Bug #: 55644 Summary: profiledbootstrap fails on current trunk Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net ../../gcc-trunk/gcc/cfg.c: In function scale_bbs_frequencies_gcov_type(basic_block_def**, int, long, long): ../../gcc-trunk/gcc/cfg.c:945:8: error: e may be used uninitialized in this function [-Werror=maybe-uninitialized] edge e; during profile-use stage. configure line: ../gcc-trunk/configure --program-suffix=-4.8 --prefix=/u/mhargett --with-build-config=bootstrap-lto --enable-lto --with-fpmath=sse --disable-libmudflap --disable-libssp --enable-gold=yes --with-mpc=/u/mhargett --with-cloog=/u/mhargett/ --with-ppl=/u/mhargett/ --with-gmp=/u/mhargett/ --with-isl=/u/mhargett --with-mpfr=/u/mhargett/ --enable-cloog-backend=isl CC=gcc-4.8 CXX=g++-4.8 --enable-languages=c,c++,lto
[Bug bootstrap/55644] bootstrap-lto fails on current trunk (with and without profiledbootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644 Matt Hargett matt at use dot net changed: What|Removed |Added Summary|profiledbootstrap fails on |bootstrap-lto fails on |current trunk |current trunk (with and ||without profiledbootstrap) --- Comment #1 from Matt Hargett matt at use dot net 2012-12-10 22:19:23 UTC --- Just tested with plain bootstrap-lto, and it gets the same failure: ../../gcc-trunk/gcc/cfg.c: In function ‘scale_bbs_frequencies_gcov_type(basic_block_def**, int, long, long)’: ../../gcc-trunk/gcc/cfg.c:945:8: error: ‘e’ may be used uninitialized in this function [-Werror=maybe-uninitialized] edge e; ^ /work/mhargett/gcc-trunk-obj/./prev-gcc/xg++ -B/work/mhargett/gcc-trunk-obj/./prev-gcc/ -B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++ -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -flto=jobserver -frandom-seed=1 -fprofile-use -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/. -I../../gcc-trunk/gcc/../include -I../../gcc-trunk/gcc/../libcpp/include -I/u/mhargett//include -I/u/mhargett//include -I/u/mhargett/include -I../../gcc-trunk/gcc/../libdecnumber -I../../gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc-trunk/gcc/../libbacktrace -DCLOOG_INT_GMP -I/u/mhargett//include -I/u/mhargett/include ../../gcc-trunk/gcc/cfgexpand.c -o cfgexpand.o cc1plus: all warnings being treated as errors make[3]: *** [cfg.o] Error 1 make[3]: *** Waiting for unfinished jobs
[Bug middle-end/55595] New: [google] r172952 (LIPO) broke profiledbootstrap on google/main, and later in google/gcc-4_7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55595 Bug #: 55595 Summary: [google] r172952 (LIPO) broke profiledbootstrap on google/main, and later in google/gcc-4_7 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net starting with r172592, google/main fails profiledbootstrap with the error below. going one revision back eliminates the error. later commits compound/mutate the profiledbootstrap failures; once this bug is fixed, I'll retest. $ rm -rf * $ ../google-main/configure --program-suffix=-google-4.7 --prefix=/u/mhargett --enable-languages=c,c++,lto --enable-lto --with-fpmath=sse --disable-libmudflap --disable-libssp --enable-build-with-cxx --enable-gold=yes --with-mpc=/u/mhargett --with-gmp=/u/mhargett/ --with-mpfr=/u/mhargett/ --disable-multilib --disable-libgomp --disable-werror $ make -j1 profiledbootstrap if [ x-fpic != x ]; then \ /work/mhargett/google-main-obj/./prev-gcc/xgcc -B/work/mhargett/google-main-obj/./prev-gcc/ -B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -B/u/mhargett/x86_64-unknown-linux-gnu/lib/ -isystem /u/mhargett/x86_64-unknown-linux-gnu/include -isystem /u/mhargett/x86_64-unknown-linux-gnu/sys-include-c -DHAVE_CONFIG_H -g -O2 -fprofile-use -I. -I../../google-main/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -fpic ../../google-main/libiberty/cp-demangle.c -o pic/cp-demangle.o; \ else true; fi ../../google-main/libiberty/cp-demangle.c: In function \u2018is_ctor_or_dtor\u2019: ../../google-main/libiberty/cp-demangle.c:5172:1: error: coverage mismatch for function \u2018is_ctor_or_dtor\u2019 while reading counter \u2018arcs\u2019 [-Werror=coverage-mismatch] ../../google-main/libiberty/cp-demangle.c:5172:1: note: number of counters is 7 instead of 8 ../../google-main/libiberty/cp-demangle.c: In function \u2018d_demangle_callback\u2019: ../../google-main/libiberty/cp-demangle.c:5172:1: error: coverage mismatch for function \u2018d_demangle_callback\u2019 while reading counter \u2018arcs\u2019 [-Werror=coverage-mismatch] ../../google-main/libiberty/cp-demangle.c:5172:1: note: number of counters is 25 instead of 26 ../../google-main/libiberty/cp-demangle.c: In function \u2018d_ctor_dtor_name\u2019: ../../google-main/libiberty/cp-demangle.c:5172:1: error: coverage mismatch for function \u2018d_ctor_dtor_name\u2019 while reading counter \u2018arcs\u2019 [-Werror=coverage-mismatch] ../../google-main/libiberty/cp-demangle.c:5172:1: note: number of counters is 20 instead of 18 ../../google-main/libiberty/cp-demangle.c: In function \u2018d_operator_name\u2019: ../../google-main/libiberty/cp-demangle.c:5172:1: error: coverage mismatch for function \u2018d_operator_name\u2019 while reading counter \u2018arcs\u2019 [-Werror=coverage-mismatch] ../../google-main/libiberty/cp-demangle.c:5172:1: note: number of counters is 21 instead of 20 ../../google-main/libiberty/cp-demangle.c: In function \u2018d_make_name\u2019: ../../google-main/libiberty/cp-demangle.c:5172:1: error: coverage mismatch for function \u2018d_make_name\u2019 while reading counter \u2018arcs\u2019 [-Werror=coverage-mismatch] ../../google-main/libiberty/cp-demangle.c:5172:1: note: number of counters is 5 instead of 4 cc1: some warnings being treated as errors
[Bug lto/55596] New: [google] r191813 broke bootstrap-lto on google/gcc-4_7 branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55596 Bug #: 55596 Summary: [google] r191813 broke bootstrap-lto on google/gcc-4_7 branch Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net r191813 broke bootstrap-lto on the google/gcc-4_7 branch. updating to one revision prior fixes the issue. trying to cherry pick other LTO fixes from trunk doesn't resolve the issues, only changes the error (to an ICE in lto_fixup_prevailing_decls). $ rm -rf * $ ../google-gcc-4_7-searching/configure --with-build-config=bootstrap-lto --program-suffix=-google-4.7 --prefix=/u/mhargett --enable-lto --with-fpmath=sse --disable-libmudflap --disable-libssp --enable-build-with-cxx --enable-gold=yes --with-mpc=/u/mhargett --with-cloog=/u/mhargett/ --with-ppl=/u/mhargett/ --with-gmp=/u/mhargett/ --with-mpfr=/u/mhargett/ --enable-cloog-backend=isl --disable-cloog-version-check --disable-multilib --disable-libgomp --disable-werror --enable-languages=c,c++,lto $ make /work/mhargett/google-gcc-4.7-obj/./prev-gcc/g++ -B/work/mhargett/google-gcc-4.7-obj/./prev-gcc/ -B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/work/mhargett/google-gcc-4.7-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/work/mhargett/google-gcc-4.7-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/work/mhargett/google-gcc-4.7-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/work/mhargett/google-gcc-4.7-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/work/mhargett/google-gcc-4_7-searching/libstdc++-v3/libsupc++ -L/work/mhargett/google-gcc-4.7-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/work/mhargett/google-gcc-4.7-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -flto=jobserver -frandom-seed=1 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1plus \ cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-gimplify.o tree-mudflap.o attribs.o incpath.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o i386-c.o default-c.o cc1plus-checksum.o main.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/u/mhargett//lib -lcloog-isl -lisl -L/u/mhargett//lib -lppl_c -lppl -lgmpxx -L/u/mhargett//lib -L/u/mhargett//lib -L/u/mhargett/lib -lmpc -lmpfr -lgmp -rdynamic -ldl -L../zlib -lz lto1: internal compiler error: tree code ‘H?E?H@’ is not supported in LTO streams Let me know if providing the LTO temps would be useful.
[Bug bootstrap/55074] error during bootstrap of trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55074 Matt Hargett matt at use dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Matt Hargett matt at use dot net 2012-12-04 20:16:55 UTC --- Fixed with current trunk.
[Bug middle-end/51233] [ipa-iterations] running multiple passes of early IPA on zlib produces more optimal code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51233 --- Comment #5 from Matt Hargett matt at use dot net 2012-12-04 20:35:09 UTC --- ping? if you're more comfortable with relegating multiple passes to LTO, I think that's a good starting point. we can wait for a per-unit C++ template case to come up after that's in. is there anything you'd like me to do to get this moving again? thanks!
[Bug middle-end/55595] [google] r172952 (LIPO) broke profiledbootstrap on google/main, and later in google/gcc-4_7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55595 --- Comment #2 from Matt Hargett matt at use dot net 2012-12-05 00:06:47 UTC --- I'm not trying to use google/main, but rather google/gcc-4_7. I got to the beginning of the 4.7 branch and was still getting the error, so I traced it back to google/main. If you can fix profiledbootstrap just in google/gcc-4_7, that would be fab. Thanks!
[Bug lto/55596] [google] r191813 broke bootstrap-lto on google/gcc-4_7 branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55596 --- Comment #2 from Matt Hargett matt at use dot net 2012-12-05 00:56:56 UTC --- We have a large C++ application that was working with LTO in google/gcc-4_6, and now we're running into issues on google/gcc-4_7. We saw performance gains and binary size decreases with LTO that were extremely useful. Understandably, we're concerned about using LTO as all with the newer toolchain if bootstrap-lto doesn't work. Are there other patches from trunk not yet backported into the 4_7 branch that make merging the other LTO fixes difficult? Anything you can do to restore the functionality that worked in previous google branches is greatly appreciated. Thanks!
[Bug debug/48670] [4.6 regression] explosion in time and stack usage when using -ggdb on a class with many members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48670 --- Comment #10 from Matt Hargett matt at use dot net 2012-12-03 23:17:22 UTC --- I no longer have access to the source tree that exhibited this problem, but it was likely the same as the qemu issue referenced earlier. Feel free to resolve as fixed.
[Bug bootstrap/45700] [4.5/4.6 Regression] --enable-checking=fold bootstrap failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45700 Matt Hargett matt at use dot net changed: What|Removed |Added CC||matt at use dot net --- Comment #5 from Matt Hargett matt at use dot net 2012-12-03 23:18:45 UTC --- *** Bug 42628 has been marked as a duplicate of this bug. ***
[Bug bootstrap/42628] ICE during bootstrap when compiling several libsupc++ files: original tree changed by fold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42628 Matt Hargett matt at use dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #13 from Matt Hargett matt at use dot net 2012-12-03 23:18:45 UTC --- Cleaning up my bug list. I didn't realize that I would resolve something as duplicate myself. *** This bug has been marked as a duplicate of bug 45700 ***
[Bug middle-end/50398] ICE when compiling openssl-1.0.0d with -O2 -floop-flatten
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50398 --- Comment #1 from Matt Hargett matt at use dot net 2012-12-03 23:20:57 UTC --- loop flattening was removed as a feature, yes? If so, this bug can be closed.
[Bug debug/48670] [4.6 regression] explosion in time and stack usage when using -ggdb on a class with many members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48670 Matt Hargett matt at use dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #11 from Matt Hargett matt at use dot net 2012-12-04 00:02:52 UTC --- Marking it resolved myself.
[Bug lto/50468] ICE in force_type_die when compiling binutils with -flto -O[12]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50468 Matt Hargett matt at use dot net changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #2 from Matt Hargett matt at use dot net 2012-12-04 00:13:29 UTC --- Can no longer reproduce with gcc-4.7 and binutils-2.23.51.0.3. I think it's safe to assume that the numerous LTO fixes that went into 4.7 resolved this issue.
[Bug middle-end/55478] [devirt] trunk fails inline-devirt test #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478 --- Comment #7 from Matt Hargett matt at use dot net 2012-11-27 17:32:01 UTC --- I'll rewrite the test to add a loop that hopefully triggers it as hot at -O3 (and gets unrolled). shouldn't it inline at -O2 since DCE would eliminate the function body and make it an overall win?
[Bug middle-end/55477] [devirt] trunk fails inline-devirt tests #2 and and #3 whereas they pass in google/4_7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477 --- Comment #4 from Matt Hargett matt at use dot net 2012-11-27 17:37:01 UTC --- I'll add a loop to the test that hopefully triggers the inlining (and does the unrolling). Adding both variants (renamed main and with loop) to the test suite would be fantastic. Thanks for the prompt attention!
[Bug middle-end/55498] New: [devirt] trunk fails inline-devirt test #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55498 Bug #: 55498 Summary: [devirt] trunk fails inline-devirt test #6 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net Created attachment 28799 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28799 test case that fails in trunk but passed with Maxim's devirt patches. added a loop to induce 'hotness' of the path versus the original test case. With current trunk, inline-devirt-6.C (attached) fails to fully inline the one() and two() indirect functions returned by the strategy functions. This did work with Maxim's patches from November/2011. 00400480 main: 400480: 41 55 push r13 400482: 41 54 push r12 400484: 55 push rbp 400485: 53 push rbx 400486: 48 83 ec 08 subrsp,0x8 40048a: e8 e1 01 00 00 call 400670 _Z3onev 40048f: 0f b6 e8movzx ebp,al 400492: 44 8d 6d 01 lear13d,[rbp+0x1] 400496: e8 f5 01 00 00 call 400690 _Z3twov 40049b: 89 ee movesi,ebp 40049d: 0f b6 d8movzx ebx,al 4004a0: bf 60 07 40 00 movedi,0x400760 4004a5: 31 c0 xoreax,eax 4004a7: 44 8d 63 01 lear12d,[rbx+0x1] 4004ab: e8 b0 ff ff ff call 400460 printf@plt 4004b0: 44 89 eemovesi,r13d 4004b3: bf 5c 07 40 00 movedi,0x40075c 4004b8: 31 c0 xoreax,eax 4004ba: e8 a1 ff ff ff call 400460 printf@plt
[Bug middle-end/55499] New: [devirt] trunk fails to eliminate dead functions where all call sites were inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55499 Bug #: 55499 Summary: [devirt] trunk fails to eliminate dead functions where all call sites were inlined Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net When compiling inline-devirt-1.C, all inlining happens correctly but the function bodies remain, with or without whole-program, with or without renaming main to main2 (and compiling as a shared lib): g++-4.8 -fwhole-program -O3 -funroll-loops inline-devirt-1.C 00400810 _ZN10CalculableD1Ev: 400810: 48 c7 07 d0 09 40 00movQWORD PTR [rdi],0x4009d0 400817: c3 ret 400818: 0f 1f 84 00 00 00 00nopDWORD PTR [rax+rax*1+0x0] 40081f: 00 00400820 _ZN1X9calculateEv: 400820: b8 01 00 00 00 moveax,0x1 400825: c3 ret 400826: 66 2e 0f 1f 84 00 00nopWORD PTR cs:[rax+rax*1+0x0] 40082d: 00 00 00 00400830 _ZN1Y9calculateEv: 400830: b8 02 00 00 00 moveax,0x2 400835: c3 ret 400836: 66 2e 0f 1f 84 00 00nopWORD PTR cs:[rax+rax*1+0x0] 40083d: 00 00 00 00400840 _ZN1YD1Ev: 400840: 48 c7 07 d0 09 40 00movQWORD PTR [rdi],0x4009d0 400847: c3 ret 400848: 0f 1f 84 00 00 00 00nopDWORD PTR [rax+rax*1+0x0] 40084f: 00 00400850 _ZN1XD1Ev: 400850: 48 c7 07 d0 09 40 00movQWORD PTR [rdi],0x4009d0 400857: c3 ret 400858: 0f 1f 84 00 00 00 00nopDWORD PTR [rax+rax*1+0x0] 40085f: 00 00400860 _ZN10CalculableD0Ev: 400860: 48 c7 07 d0 09 40 00movQWORD PTR [rdi],0x4009d0 400867: e9 94 fd ff ff jmp400600 _ZdlPv@plt 40086c: 0f 1f 40 00 nopDWORD PTR [rax+0x0] 00400870 _ZN1YD0Ev: 400870: 48 c7 07 d0 09 40 00movQWORD PTR [rdi],0x4009d0 400877: e9 84 fd ff ff jmp400600 _ZdlPv@plt 40087c: 0f 1f 40 00 nopDWORD PTR [rax+0x0] 00400880 _ZN1XD0Ev: 400880: 48 c7 07 d0 09 40 00movQWORD PTR [rdi],0x4009d0 400887: e9 74 fd ff ff jmp400600 _ZdlPv@plt 40088c: 0f 1f 40 00 nopDWORD PTR [rax+0x0]
[Bug middle-end/55499] [devirt] trunk fails to eliminate dead functions where all call sites were inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55499 --- Comment #1 from Matt Hargett matt at use dot net 2012-11-27 22:26:28 UTC --- Created attachment 28800 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28800 test case that devirtualizes correctly, but DCE fails
[Bug middle-end/55500] New: [devirt] trunk fails inline-devirt test #7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55500 Bug #: 55500 Summary: [devirt] trunk fails inline-devirt test #7 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net Created attachment 28802 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28802 test case that fails in trunk but passed with Maxim's devirt patches. added a loop to induce 'hotness' of the path versus the original test case. inline-devirt-7.C, which passed using Maxim's patches from 11/2011, do not pass on current trunk. Current trunk is missing the ipa-iterations patch, which may be required for this test case to pass. This test embodies a simple factory pattern and interface segregation, two C++ best practices. (The weird loop in main() is to induce hot inlining as mentioned in previous bugs.) 004006d0 main: 4006d0: 55 push rbp 4006d1: bd 03 00 00 00 movebp,0x3 4006d6: 53 push rbx 4006d7: 48 83 ec 08 subrsp,0x8 4006db: bf 10 00 00 00 movedi,0x10 4006e0: e8 db ff ff ff call 4006c0 _Znwm@plt 4006e5: 48 c7 00 50 0c 40 00movQWORD PTR [rax],0x400c50 4006ec: 48 c7 40 08 88 0c 40movQWORD PTR [rax+0x8],0x400c88 4006f3: 00 4006f4: 48 89 c7movrdi,rax 4006f7: 48 89 c3movrbx,rax 4006fa: e8 61 02 00 00 call 400960 _ZN11LinuxSocket4openEv
[Bug middle-end/55477] New: [devirt] trunk fails inline-devirt tests #2 and and #3 whereas they pass in google/4_7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477 Bug #: 55477 Summary: [devirt] trunk fails inline-devirt tests #2 and and #3 whereas they pass in google/4_7 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net Created attachment 28782 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28782 test case that fails in trunk but passes with google/gcc-4_7 When compiling Maxim's inline-devirt-2.C and inline-devirt-3.C test cases with both current trunk (r193828) and google/gcc-4_7, the Google branch correctly optimizes and trunk does not. Test cases are here: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02589.html My trunk configure line: $ ../gcc-trunk/configure --program-suffix=-4.8 --prefix=/u/mhargett --disable-bootstrap --enable-lto --with-fpmath=sse --disable-libmudflap --disable-libssp --enable-gold=yes --with-mpc=/u/mhargett --with-cloog=/u/mhargett/ --with-ppl=/u/mhargett/ --with-gmp=/u/mhargett/ --with-isl=/u/mhargett --with-mpfr=/u/mhargett/ --enable-cloog-backend=isl --enable-languages=c,c++,lto $ g++-4.8 -O2 inline-devirt-2.C trunk objdump for the second testcase: 0400630 main: 400630: 48 83 ec 28 subrsp,0x28 400634: 48 89 e7movrdi,rsp 400637: 48 c7 04 24 b0 09 40movQWORD PTR [rsp],0x4009b0 40063e: 00 40063f: 48 c7 44 24 10 f0 09movQWORD PTR [rsp+0x10],0x4009f0 400646: 40 00 400648: e8 23 01 00 00 call 400770 _ZL5printR10Calculable 40064d: 48 8d 7c 24 10 leardi,[rsp+0x10] 400652: e8 19 01 00 00 call 400770 _ZL5printR10Calculable 400657: 31 c0 xoreax,eax 400659: 48 83 c4 28 addrsp,0x28 40065d: c3 ret 40065e: 66 90 xchg ax,ax and for google/gcc-4_7: 00400630 main: 400630: 48 83 ec 08 subrsp,0x8 400634: be 01 00 00 00 movesi,0x1 400639: bf c8 08 40 00 movedi,0x4008c8 40063e: 31 c0 xoreax,eax 400640: e8 ab ff ff ff call 4005f0 printf@plt 400645: be 02 00 00 00 movesi,0x2 40064a: bf c4 08 40 00 movedi,0x4008c4 40064f: 31 c0 xoreax,eax 400651: e8 9a ff ff ff call 4005f0 printf@plt 400656: be 02 00 00 00 movesi,0x2 40065b: bf c8 08 40 00 movedi,0x4008c8 400660: 31 c0 xoreax,eax 400662: e8 89 ff ff ff call 4005f0 printf@plt 400667: be 03 00 00 00 movesi,0x3 40066c: bf c4 08 40 00 movedi,0x4008c4 400671: 31 c0 xoreax,eax 400673: e8 78 ff ff ff call 4005f0 printf@plt 400678: 31 c0 xoreax,eax 40067a: 48 83 c4 08 addrsp,0x8 40067e: c3 ret 40067f: 90 nop
[Bug middle-end/55478] New: [devirt] trunk fails inline-devirt test #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478 Bug #: 55478 Summary: [devirt] trunk fails inline-devirt test #4 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net Created attachment 28783 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28783 test case that fails in trunk but passed with Maxim's devirt patches trunk currently fails test #4 here (also attached): http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02589.html $ g++-4.8 -O2 inline-devirt-4.C objdump -d -Mintel a.out | less -p main\ 00400630 main: 400630: 48 83 ec 18 subrsp,0x18 400634: 48 89 e7movrdi,rsp 400637: 48 c7 04 24 d0 09 40movQWORD PTR [rsp],0x4009d0 40063e: 00 40063f: c6 44 24 0a 00 movBYTE PTR [rsp+0xa],0x0 400644: c6 44 24 08 61 movBYTE PTR [rsp+0x8],0x61 400649: c6 44 24 09 62 movBYTE PTR [rsp+0x9],0x62 40064e: e8 2d 01 00 00 call 400780 _Z12print_lengthRK6String 400653: 31 c0 xoreax,eax 400655: 48 83 c4 18 addrsp,0x18 400659: c3 ret 40065a: 66 0f 1f 44 00 00 nopWORD PTR [rax+rax*1+0x0] It does inline the FixedString ctor, but not print_length(const String), nor does it even inline FixedString::length() into print_length(const String). I tried -O3 and -Ofast along with various inline --params, but to no avail.
[Bug middle-end/55481] New: [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481 Bug #: 55481 Summary: [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net With current trunk at -O2, the attached preprocessed code emits what appears to be an infinite loop (linux/x64 binaries also attached). GCC 4.7 at -O2 and GCC 4.8 ant -O[13] do not exhibit the problem. I tried adding individual flags to -O1 to narrow the problem but wasn't able to reproduce.
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481 --- Comment #1 from Matt Hargett matt at use dot net 2012-11-27 01:09:28 UTC --- Created attachment 28784 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28784 zip containing preprocessed source of reduced examples and multiple binaries. only gcc48-O2 exhibits the bug.
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481 --- Comment #3 from Matt Hargett matt at use dot net 2012-11-27 02:11:29 UTC --- Actually, the same problem happens at -O3 with const int SIZE 20. base_iterations can be very high; it's just SIZE that's the problem.
[Bug middle-end/55219] New: [4.7 regression] attempting to compile a pre-processed unit eats up memory until OOM kills the cc1 process
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55219 Bug #: 55219 Summary: [4.7 regression] attempting to compile a pre-processed unit eats up memory until OOM kills the cc1 process Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net Created attachment 28623 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28623 preprocessed source that exhibits the OOM With the attached pre-preprocessed source, every GCC since 4.6 eats up memory until killed. This is reproducible at -O[0-3]. It gets up to 10GB of RAM before it gets killed. GCC 4.5 (from branch, bootstrapped on same machine with similar configure line) has no such issues.
[Bug middle-end/55219] [4.7 regression] attempting to compile a pre-processed unit eats up memory until OOM kills the cc1 process
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55219 --- Comment #1 from Matt Hargett matt at use dot net 2012-11-06 01:31:22 UTC --- Perhaps worth noting that gcc/trunk and google/4_7 also still exhibit the problem.
[Bug bootstrap/55074] New: error during bootstrap of trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55074 Bug #: 55074 Summary: error during bootstrap of trunk Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net On the same machine and same environment where I bootstrap 4.6, 4.7, google-4.6, and google-4.7, I have not been able to bootstrap trunk as r192821. It may be worth noting that I see similar errors when I attempt a profiledbootstrap with google/4_7, but not with any FSF branch or google/4_6. My configure line: ../gcc-trunk/configure --program-suffix=-4.8 --prefix=/u/mhargett --enable-lto --with-fpmath=sse --disable-libmudflap --disable-libssp --enable-gold=yes --with-mpc=/u/mhargett --with-cloog=/u/mhargett/ --with-ppl=/u/mhargett/ --with-gmp=/u/mhargett/ --with-isl=/u/mhargett --with-mpfr=/u/mhargett/ --enable-cloog-backend=isl CC=gcc-4.7 CXX=g++-4.7 --enable-languages=c,c++,lto Always results in this error, even without bootstrap-lto, and without profiledbootstrap just make -j8: /work/mhargett/gcc-trunk-obj/./prev-gcc/g++ -B/work/mhargett/gcc-trunk-obj/./prev-gcc/ -B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++ -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -fprofile-use -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/. -I../../gcc-trunk/gcc/../include -I../../gcc-trunk/gcc/../libcpp/include -I/u/mhargett//include -I/u/mhargett//include -I/u/mhargett/include -I../../gcc-trunk/gcc/../libdecnumber -I../../gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc-trunk/gcc/../libbacktrace -DCLOOG_INT_GMP -I/u/mhargett//include -I/u/mhargett/include ../../gcc-trunk/gcc/cfgrtl.c -o cfgrtl.o /work/mhargett/gcc-trunk-obj/./prev-gcc/g++ -B/work/mhargett/gcc-trunk-obj/./prev-gcc/ -B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++ -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -fprofile-use -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/. -I../../gcc-trunk/gcc/../include -I../../gcc-trunk/gcc/../libcpp/include -I/u/mhargett//include -I/u/mhargett//include -I/u/mhargett/include -I../../gcc-trunk/gcc/../libdecnumber -I../../gcc-trunk/gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc-trunk/gcc/../libbacktrace -DCLOOG_INT_GMP -I/u/mhargett//include -I/u/mhargett/include ../../gcc-trunk/gcc/symtab.c -o symtab.o /work/mhargett/gcc-trunk-obj/./prev-gcc/g++ -B/work/mhargett/gcc-trunk-obj/./prev-gcc/ -B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++ -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -fprofile-use -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic
[Bug lto/53780] [l4.7.1 lto] linker fails with lto and standard object file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53780 Matt Hargett matt at use dot net changed: What|Removed |Added CC||matt at use dot net --- Comment #11 from Matt Hargett matt at use dot net 2012-10-11 19:10:00 UTC --- I am also seeing the message: boost::exception_detail::clone_implboost::exception_detail::error_info_injectorboost::gregorian::bad_day_of_year warning: relocation refers to discarded section in my final link of a large C++ program compiled with LTO (with boost not compiled as LTO). I tried compiling boost with LTO to work around the problem, but got an ICE instead (will file that later). Do the patches mentioned below (still) fix the problem in 4.7.x?
[Bug lto/53572] Some public symbols don't get to serialized LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572
Matt Hargett matt at use dot net changed:
What|Removed |Added
CC||matt at use dot net
--- Comment #11 from Matt Hargett matt at use dot net 2012-09-04 23:48:40 UTC
---
Applying this patch to my 4.7 branch checkout fixes my problem, which had the
same symptoms. Can someone please commit this to the 4.7 branch?
===
--- ../google-gcc-4_7/gcc/cgraph.h(revision 190939)
+++ ../google-gcc-4_7/gcc/cgraph.h(working copy)
@@ -1004,10 +1004,16 @@
static inline bool
varpool_can_remove_if_no_refs (struct varpool_node *node)
{
- return (!node-force_output !node-used_from_other_partition
+ if (DECL_EXTERNAL (node-decl))
+ return true;
+
+ return (!node-force_output !node-used_from_other_partition
(flag_toplevel_reorder || DECL_COMDAT (node-decl)
|| DECL_ARTIFICIAL (node-decl))
- (DECL_COMDAT (node-decl) || !node-externally_visible));
+ ((DECL_COMDAT (node-decl)
+ !varpool_used_from_object_file_p (node))
+ || !node-externally_visible
+ || DECL_HAS_VALUE_EXPR_P (node-decl)));
}
[Bug middle-end/53676] [4.7 regression] empty loop is not always removed now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676 --- Comment #16 from Matt Hargett matt at use dot net 2012-08-23 18:01:08 UTC --- Back/forward-porting of the trivial restoration of the old behavior is acceptable to me, as it would remove a major barrier to our adoption of 4.7.x. That being said, if there's multi-platform testing I can do with a 'better' fix based on trunk, I have SPARC and ARM qemu environments set up to regression test on. BTW, I realized that my initial analysis was wrong -- the int32_t and uint32_t benchmarks are unaffected by this regression. Let me know if there's an easy way to apply the restoration patch and I'll test it locally on our amdfam10 and bdver2 hardware. If the testcase committed to trunk would be applicable to a 4.7 fix as well, I can make a patch to integrate that to ensure thie functionality doesn't regress again in future 4.7.x point releases. I'm happy to do as much footwork as my expertise allows, just let me know :) Thanks!
[Bug libstdc++/54307] [4.7 regression] increases in memory usage by some C++11 (and C++03) standard containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54307 --- Comment #3 from Matt Hargett matt at use dot net 2012-08-21 17:26:55 UTC --- Paolo, what about listint? Does VC11 achieve the size GCC 4.6 has by not being compliant somehow?
[Bug middle-end/53676] [4.7 regression] empty loop is not always removed now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676 --- Comment #12 from Matt Hargett matt at use dot net 2012-08-21 21:40:11 UTC --- I've been doing research into LLVM 3.1 and other GCC versions. LLVM 3.1 correctly eliminate the (near) empty loop, and their current trunk does not regress like 4.7 has. Is the trunk patch coupled to other changes that are too invasive for 4.7? I'm confused and curious about what optimization regressions are serious enough to warrant a back port, if any.
[Bug rtl-optimization/53533] [4.7/4.8 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 --- Comment #20 from Matt Hargett matt at use dot net 2012-08-20 23:52:31 UTC --- Some additional information: Compared to LLVM 3.1 with -O3, GCC 4.7 is twice as slow on these benchmarks. LLVM even outperforms GCC 4.1, which previously had the best result. We are very eager to hear about any resolution for this major regression in 4.7 so we can deploy it. Even a return to GCC 4.1 performance levels would be fine. Thanks!
[Bug libstdc++/54307] New: [4.7 regression] increases in memory usage by some C++11 (and C++03) standard containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54307
Bug #: 54307
Summary: [4.7 regression] increases in memory usage by some
C++11 (and C++03) standard containers
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net
Between 4.6 and 4.7.x, the memory used by a few standard containers has
increased, resulting in some OOM and performance issues on an amd64 application
I work on.
4.7:
listint size = 24
unordered_mapint,int size = 64
unordered_setint,int size = 64
4.6:
listint size = 16
unordered_mapint,int size = 56
unordered_setint,int size = 56
comparing to VC11:
listint size = 16
unordered_mapint,int size = 64
unordered_setint,int size = 64
compile commandline is just -std=c++0x. testcase program below:
#include vector
#include array
#include deque
#include forward_list
#include list
#include queue
#include stack
#include tuple
#include map
#include set
#include hash_map
#include hash_set
#include unordered_map
#include unordered_set
#include string
using namespace std;
int main(void)
{
vectorint v; printf(vectorint size\t = %d\n, sizeof(v));
arrayint,5 a; printf(arrayint,5 size\t = %d\n, sizeof(a));
dequeint d; printf(dequeint size\t = %d\n, sizeof(d));
forward_listint f; printf(forward_listint size\t = %d\n, sizeof(f));
listint l; printf(listint size\t = %d\n, sizeof(l));
queueint q; printf(queueint size\t = %d\n, sizeof(q));
stackint s; printf(stackint size\t = %d\n, sizeof(s));
tupleint,int,int t; printf(tupleint,int,int size\t = %d\n,
sizeof(t));
mapint,int m; printf(mapint,int size\t = %d\n, sizeof(m));
setint set; printf(setint size\t = %d\n, sizeof(set));
unordered_mapint,int um; printf(unordered_mapint,int size\t = %d\n,
sizeof(um));
unordered_setint us; printf(unordered_setint,int size\t = %d\n,
sizeof(us));
string str; printf(string size\t = %d\n, sizeof(string));
return 0;
}
[Bug rtl-optimization/53533] [4.7/4.8 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 --- Comment #19 from Matt Hargett matt at use dot net 2012-08-14 17:25:40 UTC --- Does this mean there will be a fix for this regression committed for 4.7.2? If there's a patch I can test ahead of time, please let me know. Thanks!
[Bug middle-end/51233] [ipa-iterations] running multiple passes of early IPA on zlib produces more optimal code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51233 --- Comment #4 from Matt Hargett matt at use dot net 2012-08-14 17:43:30 UTC --- I agree it's more appropriate in LTO, but can still provide measurable benefit for template-heavy C++ applications where lots of implementation bodies are in header files by necessity. With regard to zlib performance improving with multiple iterations, is there a multiple iterations patch against trunk you'd like me to retest on this specific testcase? We never did an RTL/tree dump in the 4.6/4.7 case for each iteration to see if the improvements could have been caught in a single iteration.
[Bug middle-end/51233] [ipa-iterations] running multiple passes of early IPA on zlib produces more optimal code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51233 --- Comment #2 from Matt Hargett matt at use dot net 2012-08-14 00:26:35 UTC --- Okay. I filed this bug at your request last year because of your concerns that some of the improvements seen with multiple iterations might be papering over existing bugs in the optimizers. Does this mean that in this zlib case the passes are all fine, but multiple iterations legitimately helps? The original discussion was in the context of Maxim's devirt patches. Would the approach you mention still allow for the testcases from his proposed patches to pass? (We can discuss this second question on-list, if you like.) Thanks for reviving this; we saw dramatic performance improvements with the 4.6-based deliverable we got from Maxim.
[Bug bootstrap/49797] CLooG use of LANGUAGE_C conflicts with MIPS compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49797 --- Comment #6 from Matt Hargett matt at use dot net 2012-06-29 18:49:35 UTC --- Pinging on this again since this patch has been back ported to a couple of 4.6-based branches now. Anyone attempting to use a recent cloog release with GCC 4.6 will run into this problem. It is incredibly low-risk in an of itself, and I can verify that it works with both latest cloog and the previous release.
[Bug tree-optimization/37242] missed FRE opportunity because of signedness of addition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37242 --- Comment #22 from Matt Hargett matt at use dot net 2012-06-29 00:20:17 UTC --- Hey Andrew, any word on your patch?
[Bug middle-end/53676] [4.7 regression] empty loop is not always removed now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676 --- Comment #10 from Matt Hargett matt at use dot net 2012-06-27 18:26:55 UTC --- Is there a fix targeted for 4.7.2? I can apply the patch and do some testing, if that helps. Let me know what I can do, if anything, so we can make 4.7 deployable for us. Thanks for the quick turnaround on the trunk commit!
[Bug rtl-optimization/53533] [4.7/4.8 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 --- Comment #15 from Matt Hargett matt at use dot net 2012-06-14 18:01:31 UTC --- (In reply to comment #14) Mine, at least for a 4.8 solution. What enhancement to 4.7 caused the regression? Can whatever the change was be (partially) reverted to lessen the impact?
[Bug middle-end/53676] New: [4.7/4.8 regression] constant folding regression, shown as slowdown as measured by Adobe's C++Benchmark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676 Bug #: 53676 Summary: [4.7/4.8 regression] constant folding regression, shown as slowdown as measured by Adobe's C++Benchmark Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net The attached ZIP contains two binaries and preprocessor output files, based on a subset of a test in Adobe's C++Benchmark suite. All GCC versions I tested prior to 4.7 do the folding correctly. I tried using Ofast and other tricks to workaround this new regression to no avail. -rw-r--r-- 1 mhargett users 143573 Jun 14 15:31 int8_folding_test.gcc47.i mhargett@chert:~/src/C++Benchmarks-gcc47-google-fast$ ./int8_folding_test-gcc46 ./int8_folding_test-gcc46 test description absolute operations ratio with number time per second test0 0 int8_t constant 0.00 sec inf M -nan Total absolute time for int8_t simple constant folding: 0.00 sec mhargett@chert:~/src/C++Benchmarks-gcc47-google-fast$ ./int8_folding_test-gcc47 ./int8_folding_test-gcc47 test description absolute operations ratio with number time per second test0 0 int8_t constant 0.69 sec 2318.84 M 1.00 Total absolute time for int8_t simple constant folding: 0.69 sec
[Bug middle-end/53676] [4.7/4.8 regression] constant folding regression, shown as slowdown as measured by Adobe's C++Benchmark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676 --- Comment #1 from Matt Hargett matt at use dot net 2012-06-14 22:48:49 UTC --- Created attachment 27622 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27622 ZIP containing pre-processed source and binaries that demonstrate the const folding regression
[Bug middle-end/53676] [4.7/4.8 regression] constant folding regression, shown as slowdown as measured by Adobe's C++Benchmark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676 --- Comment #2 from Matt Hargett matt at use dot net 2012-06-14 23:00:33 UTC --- I forgot to mention -- it's the same result on all types, both signed and unsigned. the int8_t case is (hopefully) representative of the root cause for all/most of them.
[Bug rtl-optimization/53533] [4.7/4.8 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 --- Comment #11 from Matt Hargett matt at use dot net 2012-06-12 18:25:25 UTC --- Richard, Thanks for the quick analysis! Sounds like a perfect storm of sorts :/ re: cprop failure: this may be indicated by another major regression in their suite for the simple constant folding tests. in GCC 4.1-4.6, those tests are all 0.0s but in 4.7 take tens of seconds. Let me know if you want me to file a separate bug/reduced test case for that, and then have that new bug depend on this one. Otherwise, I'll wait until this one sees some resolution and then retest. re: multiple passes: if you think that feature has enough merit to be revisited now, I can look into re-proposing Maxim's patches from October/November 2011 that integrated your feedback at the time. re: -march workaround: our deployment platform's minimum arch is nocona, and enabling -march=nocona doesn't workaround the issue. For grins, I tried -march=amdfam10 (another deployment target, but would require a separate distributable binary), but that also didn't work around the issue. I see a small improvement when using -fno-tree-vectorize, but not nearly as dramatic as yours. For the int32_t for and while loop unrolling, the times go from ~107s and ~105s to ~96s and ~95s, respectively. The do and goto loop unrolling times get slightly worse (~2%), but it might be noise. Let me know if there's any additional testing/footwork you'd like me to do. Again, thanks for the quick turnaround on such a deep analysis!
[Bug middle-end/53533] [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 --- Comment #3 from Matt Hargett matt at use dot net 2012-06-11 19:56:14 UTC --- Created attachment 27603 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27603 ZIP with pre-processed shorter example, callgrind output, and smaller binaries
[Bug middle-end/53533] [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 --- Comment #4 from Matt Hargett matt at use dot net 2012-06-11 19:57:12 UTC --- Created attachment 27604 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27604 shorter source example, ~150 lines w/o comments
[Bug middle-end/53533] [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 --- Comment #5 from Matt Hargett matt at use dot net 2012-06-11 20:02:41 UTC --- Got rid of graphite options, it made no difference. I reduced the original test from the suite and attached it's source, preprocessor output from 4.6 and 4.7 (no major difference), and callgrind output. To keep things simple, I'm just using -O3 and -fwhole-program. According to callgrind, 4.7's instruction references went up by 60% and D1 misses went up by 15% at -O3 versus 4.6 at -O3. Let me know if you need any more information to continue triaging. Thanks!
[Bug middle-end/53533] New: [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 Bug #: 53533 Summary: [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6 Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net Comparing GCC versions, branches, and optimization levels on Adobe's C++Benchmark suite, I discovered that 4.7 has a major regression with their loop unrolling tests. I have captures the data here: https://docs.google.com/spreadsheet/ccc?key=0Amu19eOay72HdE1xYVRPUTFYWU1TSld3Y2FEOEt5LXc All compilers were fresh checkouts by me from their trunk revisions as of a few days ago. My configure command line: /u/mhargett/src/gcc-4_7-branch/configure --program-suffix=-4.7 --prefix=/u/mhargett --enable-languages=c,c++,lto --enable-lto --with-build-config=bootstrap-lto --with-fpmath=sse --disable-libmudflap --disable-libssp --enable-build-with-cxx --enable-gold=yes --with-mpc=/u/mhargett --with-cloog=/u/mhargett/ --with-ppl=/u/mhargett/ --with-gmp=/u/mhargett/ --with-mpfr=/u/mhargett/ --enable-cloog-backend=isl --disable-cloog-version-check CC=gcc-4.7 CXX=g++-4.7 The 4.6 and 4.7 versions were both build against the same Cloog, ppl, mpfr, etc. Going from -O3 -floop-block -floop-strip-mine -floop-interchange -mtune=amdfam10 to -Ofast -funsafe-loop-optimizations -funroll-loops -floop-block -floop-strip-mine -floop-interchange didn't help. Attached is a tar ball of the 4.6 and 4.7 -O3 optimized builds. 'make report' re-runs the tests, 'make clean make' rebuilds.
[Bug middle-end/53533] [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 --- Comment #1 from Matt Hargett matt at use dot net 2012-05-31 00:55:36 UTC --- Created attachment 27526 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27526 tarball containing buildable sources and binaries that demonstrate the severe performance regression on amdfam10
[Bug bootstrap/49797] CLooG use of LANGUAGE_C conflicts with MIPS compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49797 --- Comment #5 from Matt Hargett matt at use dot net 2012-05-11 17:58:27 UTC --- It's not an IRIX-specific thing AFAICS, but rather that newer versions of cloog/ppl renamed the macro to avoid conflicts on IRIX. 4.6 still checks for the old macro name, which is no longer set. I have applied the patch locally to work around the issue and can verify it solved the problem for me. Let me know if there's anything else you'd like me to test/validate to get it back ported.
[Bug debug/51564] [4.7 Regression] ICE in force_type_die, at dwarf2out.c:19288
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51564 --- Comment #7 from Matt Hargett matt at use dot net 2012-05-11 20:19:01 UTC --- Applying the patch does allow DWARF serialization to get further, but now it dies here: internal compiler error: in add_AT_specification, at dwarf2out.c:7536 It looks like this problem (hiding beneath the original) is related to PR47839, whose fix was fortran front-end specific. Should I just file a new bug and reference these other bugs?
[Bug debug/51564] [4.7 Regression] ICE in force_type_die, at dwarf2out.c:19288
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51564 Matt Hargett matt at use dot net changed: What|Removed |Added CC||matt at use dot net --- Comment #5 from Matt Hargett matt at use dot net 2012-05-03 20:56:40 UTC --- I believe I'm hitting (what I'm pretty sure is) this with same bug GCC 4.6 trunk as well. Can you apply the patch to lto-streamer-out.c on the 4_6 branch as well? Thanks! In member function ‘__base_dtor ’: lto1: internal compiler error: in force_type_die, at dwarf2out.c:21059
[Bug bootstrap/49797] CLooG use of LANGUAGE_C conflicts with MIPS compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49797 Matt Hargett matt at use dot net changed: What|Removed |Added CC||matt at use dot net --- Comment #3 from Matt Hargett matt at use dot net 2012-04-23 22:19:35 UTC --- Can you please back port this to 4.6 as well? Running into this on Scientific Linux 6.1 on x64 with GCC 4.6 trunk and latest cloog-isl and ppl. Thanks!
[Bug target/52717] thunk referenced in discarded section when building samba with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717 --- Comment #13 from Matt Hargett matt at use dot net 2012-04-23 15:19:47 UTC --- *** Bug 52704 has been marked as a duplicate of this bug. ***
[Bug middle-end/52704] thunk referenced in discarded section when combining -flto -ftree-vectorize -fipa-cp-clone on Debian/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52704 Matt Hargett matt at use dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Matt Hargett matt at use dot net 2012-04-23 15:19:47 UTC --- Went away when the fix for 52717 was applied. *** This bug has been marked as a duplicate of bug 52717 ***
[Bug target/52610] mpfr fails to compile when specifying CFLAGS=-O3 -mcpu=leon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52610 Matt Hargett matt at use dot net changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #7 from Matt Hargett matt at use dot net 2012-04-23 15:21:19 UTC --- Verified again with 4.7 trunk.
[Bug target/52717] thunk referenced in discarded section when building samba with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717 --- Comment #7 from Matt Hargett matt at use dot net 2012-03-28 03:22:49 UTC --- Is there any more information I need to provide for this class of issues to be resolved? Mozilla, WebKit, and others all eventually fail with similar errors. If there's a proposed fix, I can rebuild and provide test results back in a few days. Thanks!
[Bug target/52717] thunk referenced in discarded section when building samba with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717 --- Comment #5 from Matt Hargett matt at use dot net 2012-03-26 17:09:55 UTC --- Attachment was too big. Here's a URL for an archive that includes the ltrans objects, ltrans asm, and cc temp files: http://www.clock.org/~matt/tmp/smbta-util-lto-failure-temps.tar.bz2 I can provide the whole source dir or a VM image if that helps. binutils version is freshly compiled with GCC 4.7.0 RC1: debian-sparc:~/src/samba-3.6.3/source3# ld --version GNU ld (GNU Binutils) 2.22.52.20120317 Copyright 2012 Free Software Foundation, Inc. using this configure line for binutils: ../configure --prefix=/opt/gcc-4.7.0/ --enable-lto --with-gmp=/opt/gcc-4.7.0/ --with-mpfr=/opt/gcc-4.7.0/ --with-mpc=/opt/gcc-4.7.0/ --with-cloog=/opt/gcc-4.7.0/ --with-ppl=/opt/gcc-4.7.0 --enable-gold --enable-cloog-backend=isl --disable-cloog-version-check --enable-plugins and then this configure line for gcc 4.7.0: ../configure --prefix=/opt/gcc-4.7.0/ --enable-lto --with-gmp=/opt/gcc-4.7.0/ --with-mpfr=/opt/gcc-4.7.0/ --with-mpc=/opt/gcc-4.7.0/ --with-cloog=/opt/gcc-4.7.0/ --with-ppl=/opt/gcc-4.7.0 --enable-gold --enable-cloog-backend=isl --enable-plugins --with-build-config=bootstrap-lto --disable-libstdcxx-pch --enable-thread-safe --enable-threads=posix --with-libelf=/opt/gcc-4.7.0/ --enable-languages=c,c++,lto --disable-bootstrap --with-tune=leon --enable-build-with-cxx --disable-cloog-version-check --disable-nls
[Bug target/52717] thunk referenced in discarded section when building samba with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717 --- Comment #6 from Matt Hargett matt at use dot net 2012-03-26 17:32:51 UTC --- The link line that fails: gcc -o bin/smbta-util utils/smbta-util.o dynconfig.o param/loadparm.o param/loadparm_server_role.o param/util.o lib/sharesec.o lib/ldap_debug_handler.o registry/reg_api.o registry/reg_dispatcher.o registry/reg_cachehook.o registry/reg_objects.o registry/reg_util_internal.o lib/util_nttoken.o registry/reg_backend_db.o registry/reg_init_basic.o registry/reg_util_token.o registry/reg_api_util.o registry/reg_backend_smbconf.o registry/reg_init_smbconf.o ../lib/smbconf/smbconf.o ../lib/smbconf/smbconf_util.o ../lib/smbconf/smbconf_txt.o lib/smbconf/smbconf_reg.o lib/smbconf/smbconf_init.o ../libcli/security/privileges.o lib/popt_common.o ./../lib/replace/replace.o ./../lib/replace/snprintf.o ./../lib/replace/getpass.o ../lib/util/rbtree.o ../lib/util/signal.o ../lib/util/time.o ../lib/util/xfile.o ../lib/util/util_strlist.o ../lib/util/util_file.o ../lib/util/data_blob.o ../lib/util/util.o ../lib/util/fsusage.o ../lib/util/params.o ../lib/util/talloc_stack.o ../lib/util/genrand.o ../lib/util/util_net.o ../lib/util/become_daemon.o ../lib/util/system.o ../lib/util/tevent_unix.o ../lib/util/tevent_ntstatus.o ../lib/util/tevent_werror.o ../lib/util/smb_threads.o ../lib/util/util_id.o ../lib/util/blocking.o ../lib/util/rfc1738.o ../lib/util/select.o ../lib/util/util_pw.o ../lib/crypto/crc32.o ../lib/crypto/md5.o ../lib/crypto/hmacmd5.o ../lib/crypto/arcfour.o ../lib/crypto/md4.o ../lib/crypto/sha256.o ../lib/crypto/hmacsha256.o ../lib/crypto/aes.o ../lib/crypto/rijndael-alg-fst.o lib/messages.o librpc/gen_ndr/ndr_messaging.o lib/messages_local.o lib/messages_ctdbd.o lib/packet.o lib/ctdbd_conn.o lib/interfaces.o lib/memcache.o lib/talloc_dict.o lib/serverid.o lib/util_sconn.o lib/util_transfer_file.o ../lib/async_req/async_sock.o lib/addrchange.o lib/util_tdb.o ../lib/util/util_tdb.o ../lib/util/tdb_wrap.o lib/dbwrap.o lib/dbwrap_tdb.o lib/dbwrap_ctdb.o lib/g_lock.o lib/dbwrap_rbt.o lib/version.o lib/charcnv.o ../lib/util/debug.o ../lib/util/debug_s3.o lib/fault.o lib/interface.o lib/pidfile.o lib/system.o lib/sendfile.o lib/recvfile.o lib/time.o lib/username.o ../libds/common/flag_mapping.o lib/access.o lib/smbrun.o lib/bitmap.o lib/dprintf.o ../libcli/registry/util_reg.o lib/wins_srv.o lib/util_str.o lib/clobber.o lib/util_sid.o lib/util_unistr.o ../lib/util/charset/codepoints.o lib/util_file.o lib/util.o lib/util_cmdline.o lib/util_names.o lib/util_sock.o lib/sock_exec.o lib/util_sec.o lib/substitute.o lib/dbwrap_util.o lib/ms_fnmatch.o lib/errmap_unix.o lib/tallocmsg.o lib/dmallocmsg.o libsmb/clisigning.o libsmb/smb_signing.o ../lib/util/charset/iconv.o intl/lang_tdb.o lib/conn_tdb.o lib/adt_tree.o lib/gencache.o lib/sessionid_tdb.o lib/module.o lib/events.o ./../lib/tevent/tevent.o ./../lib/tevent/tevent_debug.o ./../lib/tevent/tevent_util.o ./../lib/tevent/tevent_fd.o ./../lib/tevent/tevent_timed.o ./../lib/tevent/tevent_immediate.o ./../lib/tevent/tevent_signal.o ./../lib/tevent/tevent_req.o ./../lib/tevent/tevent_wakeup.o ./../lib/tevent/tevent_queue.o ./../lib/tevent/tevent_standard.o ./../lib/tevent/tevent_select.o ./../lib/tevent/tevent_poll.o ./../lib/tevent/tevent_epoll.o lib/server_contexts.o lib/ldap_escape.o lib/secdesc.o ../libcli/security/access_check.o ../libcli/security/secace.o ../libcli/security/object_tree.o ../libcli/security/sddl.o ../libcli/security/secacl.o lib/fncall.o libads/krb5_errs.o lib/system_smbd.o lib/audit.o ../librpc/ndr/ndr_basic.o ../librpc/ndr/ndr.o ../librpc/ndr/ndr_misc.o librpc/gen_ndr/ndr_misc.o librpc/gen_ndr/ndr_security.o ../librpc/ndr/ndr_sec_helper.o ../librpc/ndr/ndr_string.o ../librpc/ndr/uuid.o librpc/ndr/util.o librpc/gen_ndr/ndr_server_id.o librpc/gen_ndr/ndr_dcerpc.o lib/file_id.o lib/idmap_cache.o ../libcli/security/dom_sid.o ../libcli/security/security_descriptor.o ../libcli/security/security_token.o ../libcli/security/util_sid.o lib/dummysmbd.o lib/dummyroot.o libsmb/nterr.o libsmb/smberr.o ../libcli/util/doserr.o libsmb/errormap.o ../librpc/rpc/dcerpc_error.o ../libcli/auth/smbdes.o ../libcli/auth/smbencrypt.o ../libcli/auth/msrpc_parse.o ../libcli/auth/session.o passdb/secrets.o passdb/machine_account_secrets.o passdb/machine_sid.o librpc/gen_ndr/ndr_secrets.o lib/filename_util.o -pie -Wl,-z,relro -O2 -flto -L./bin -Wl,--export-dynamic -lresolv -lresolv -lnsl -ldl -lrt -lldap -llber -lpopt -ltalloc -ltdb To make the failure go away, just add -finline-functions. Similarly, changing -O2 to -O3 also eliminates the error.
[Bug middle-end/52717] New: thunk referenced in discarded section when building samba with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717 Bug #: 52717 Summary: thunk referenced in discarded section when building samba with -flto Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net To reproduce from scratch with 4.7.0 and samba-3.6.3 (reduced case below/attached): debian-sparc:~/src/samba-3.6.3/source3# CFLAGS=-O2 -flto -mtune=leon -floop-block -floop-interchange -floop-strip-mine -ftree-loop-distribution -ftree-loop-distribute-patterns -ftree-loop-im -ftree-loop-ivcanon -fivopts -fpredictive-commoning -fipa-cp-clone -ffast-math -fgcse-after-reload -fgcse-sm -fgcse-las LDFLAGS=-flto -O2 ./configure --prefix=/opt/samba-3.6.4 --exec-prefix=/opt/samba-3.6.4 --sysconfdir=/opt/samba-3.6.4/etc --with-configdir=/opt/samba-3.6.4/etc --with-quotas --with-pam --with-pam_smbpass --build=sparc-linux --with-logfilebase=/opt/samba-3.6.4/var/log --with-piddir=/opt/samba-3.6.4/var/run --with-lockdir=/opt/samba-3.6.4/var/lock debian-sparc:~/src/samba-3.6.3/source3# make [...] `__sparc_get_pc_thunk.l7' referenced in section `.text' of smbta-util.ltrans24.ltrans.o: defined in discarded section `.text.__sparc_get_pc_thunk.l7.4585[__sparc_get_pc_thunk.l7.4585]' of smbta-util.ltrans24.ltrans.o This is different from the previous bug -- there is no ipa-cp-clone here. Attached is the output from save-temps. I have yet to have any mid-sized C project fully build with LTO using -O2 or variants, most coming down to this class of errors.
[Bug target/52610] mpfr fails to compile when specifying CFLAGS=-O3 -mcpu=leon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52610 --- Comment #6 from Matt Hargett matt at use dot net 2012-03-24 20:20:42 UTC --- Great. I verified the fix yesterday. Thanks!
[Bug middle-end/52704] New: thunk referenced in discarded section when combining -flto -ftree-vectorize -fipa-cp-clone on Debian/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52704 Bug #: 52704 Summary: thunk referenced in discarded section when combining -flto -ftree-vectorize -fipa-cp-clone on Debian/SPARC Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net To reproduce from scratch with 4.7.0 and sambe-3.6.3 (reduced case below/attached): debian-sparc:~/src/samba-3.6.3/source3# CFLAGS=-O2 -flto -mtune=leon -floop-block -floop-interchange -floop-strip-mine -ftree-loop-distribution -ftree-loop-distribute-patterns -ftree-loop-im -ftree-loop-ivcanon -fivopts -fpredictive-commoning -fipa-cp-clone -ftree-vectorize -ffast-math -fgcse-after-reload -fgcse-sm -fgcse-las LDFLAGS=-flto -O2 ./configure --prefix=/opt/samba-3.6.4 --exec-prefix=/opt/samba-3.6.4 --sysconfdir=/opt/samba-3.6.4/etc --with-configdir=/opt/samba-3.6.4/etc --with-quotas --with-pam --with-pam_smbpass --build=sparc-linux --with-logfilebase=/opt/samba-3.6.4/var/log --with-piddir=/opt/samba-3.6.4/var/run --with-lockdir=/opt/samba-3.6.4/var/lock debian-sparc:~/src/samba-3.6.3/source3# make [...] Linking shared library bin/libtdb.so.1 gcc -I../lib/zlib -O2 -flto -mtune=leon -floop-block -floop-interchange -floop-strip-mine -ftree-loop-distribution -ftree-loop-distribute-patterns -ftree-loop-im -ftree-loop-ivcanon -fivopts -fpredictive-commoning -fipa-cp-clone -ftree-vectorize -ffast-math -fgcse-after-reload -fgcse-sm -fgcse-las -I. -I/root/src/samba-3.6.3/source3 -I/root/src/samba-3.6.3/source3/../lib/iniparser/src -Iinclude -I./include -I. -I. -I./../lib/replace -I./../lib/tevent -I./librpc -I./.. -I./../lib/talloc -I../lib/tdb/include -DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iinclude -I./include -I. -I. -I./../lib/replace -I./../lib/tevent -I./librpc -I./.. -I./../lib/popt -DLDAP_DEPRECATED -I/root/src/samba-3.6.3/source3/lib -I.. -D_SAMBA_BUILD_=3 -D_SAMBA_BUILD_=3 -fPIC -shared -Wl,-Bsymbolic -Wl,-z,relro -flto -O2 -L./bin -lc -Wl,-z,defs -Wl,--version-script,/root/src/samba-3.6.3/source3/exports/`basename bin/libtdb.so.1 | sed 's:\.so[\.0-9]*$:.syms:'` -o bin/libtdb.so.1 ../lib/tdb/common/tdb.o ../lib/tdb/common/dump.o ../lib/tdb/common/transaction.o ../lib/tdb/common/error.o ../lib/tdb/common/traverse.o ../lib/tdb/common/freelist.o ../lib/tdb/common/freelistcheck.o ../lib/tdb/common/io.o ../lib/tdb/common/lock.o ../lib/tdb/common/open.o ../lib/tdb/common/check.o ../lib/tdb/common/hash.o ../lib/tdb/common/summary.o ./../lib/replace/replace.o ./../lib/replace/snprintf.o ./../lib/replace/getpass.o\ -Wl,-soname=`basename bin/libtdb.so.1` `__sparc_get_pc_thunk.l7' referenced in section `.text' of /tmp/ccUwrHhg.ltrans2.ltrans.o: defined in discarded section `.text.__sparc_get_pc_thunk.l7.2305[__sparc_get_pc_thunk.l7.2305]' of /tmp/ccUwrHhg.ltrans2.ltrans.o collect2: error: ld returned 1 exit status I reduced it to an interaction between tree-vectorize and ipa-cp-clone with inline-functions is *not* present. when using -O3, or adding inline-functions along with those two options, the problem goes away: gcc -I../lib/zlib -O0 -flto -ftree-vectorize -fipa-cp-clone -I. -I/root/src/samba-3.6.3/source3 -I/root/src/samba-3.6.3/source3/../lib/iniparser/src -Iinclude -I./include -I. -I. -I./../lib/replace -I./../lib/tevent -I./librpc -I./.. -I./../lib/talloc -I../lib/tdb/include -DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iinclude -I./include -I. -I. -I./../lib/replace -I./../lib/tevent -I./librpc -I./.. -I./../lib/popt -DLDAP_DEPRECATED -I/root/src/samba-3.6.3/source3/lib -I.. -D_SAMBA_BUILD_=3 -D_SAMBA_BUILD_=3 -fPIC -shared -Wl,-Bsymbolic -Wl,-z,relro -flto -O2 -L./bin -lc -Wl,-z,defs -Wl,--version-script,/root/src/samba-3.6.3/source3/exports/`basename bin/libtdb.so.1 | sed 's:\.so[\.0-9]*$:.syms:'` -o bin/libtdb.so.1 ../lib/tdb/common/tdb.o ../lib/tdb/common/dump.o ../lib/tdb/common/transaction.o ../lib/tdb/common/error.o ../lib/tdb/common/traverse.o ../lib/tdb/common/freelist.o ../lib/tdb/common/freelistcheck.o ../lib/tdb/common/io.o ../lib/tdb/common/lock.o ../lib/tdb/common/open.o ../lib/tdb/common/check.o ../lib/tdb/common/hash.o ../lib/tdb/common/summary.o ./../lib/replace/replace.o ./../lib/replace/snprintf.o ./../lib/replace/getpass.o -Wl,-soname=`basename bin/libtdb.so.1` `__sparc_get_pc_thunk.l7' referenced in section `.text' of libtdb.so.1.ltrans2.ltrans.o: defined in discarded section `.text.__sparc_get_pc_thunk.l7.2305[__sparc_get_pc_thunk.l7.2305]' of libtdb.so.1.ltrans2.ltrans.o Attached are the save-temps outputs and (hopefully) enough of the original source dir to reproduce otherwise.
[Bug middle-end/52704] thunk referenced in discarded section when combining -flto -ftree-vectorize -fipa-cp-clone on Debian/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52704 --- Comment #1 from Matt Hargett matt at use dot net 2012-03-24 21:12:21 UTC --- Created attachment 26975 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26975 save-temps output from /tmp and linking dir
