http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #26 from Alexey Feldgendler
2011-01-08 21:10:50 UTC ---
This is a great success, although I have to say it's still way too much RAM to
ask for. In particular, this excludes the possiblity of compiling on a 32-bit
architecture.
--- Comment #5 from alexey at feldgendler dot ru 2010-09-06 14:03 ---
Indeed, the patch fixes this bug for me. Thanks!
--
alexey at feldgendler dot ru changed:
What|Removed |Added
--- Comment #3 from alexey at feldgendler dot ru 2010-09-06 13:51 ---
$ gdb --args /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -v
-D_GNU_SOURCE TC.cpp -dumpbase TC.cpp -mtune=generic -march=x86-64 -auxbase TC
-O1 -version -flto -finline-small-functions -fpartial
--- Comment #2 from alexey at feldgendler dot ru 2010-09-06 13:49 ---
Created an attachment (id=21711)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21711&action=view)
Incomplete assembly file cc1plus manages to write before segfaulting
--
http://gcc.gnu.org/b
--- Comment #1 from alexey at feldgendler dot ru 2010-09-06 13:48 ---
Created an attachment (id=21710)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21710&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45557
: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexey at feldgendler dot ru
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45557
--- Comment #23 from alexey at feldgendler dot ru 2010-09-02 15:55 ---
Yes, the patch fixes the observed bug. Thanks a lot!
However, there's also the issue of missing error reporting for a failure to
read ELF. I don't know if it should be fixed as part of this bug or
--- Comment #20 from alexey at feldgendler dot ru 2010-09-02 15:13 ---
Indeed, when gcc is configured with --disable-gnu-unique-object, the bug
doesn't occur.
binutils 2.20.1-12 from Debian.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45496
--- Comment #18 from alexey at feldgendler dot ru 2010-09-02 14:51 ---
Further research: the LTO pass on either the affected or unaffected
installation fails if one or both .s files come from the affected installation,
but succeeds with both .s files from the unaffected installation
--- Comment #15 from alexey at feldgendler dot ru 2010-09-02 14:43 ---
Created an attachment (id=21666)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21666&action=view)
Assembly for 1.cpp
Re-uploaded 1.s.
--
alexey at feldgendler dot ru changed:
What|
--- Comment #14 from alexey at feldgendler dot ru 2010-09-02 14:40 ---
Created an attachment (id=21665)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21665&action=view)
Assembly for 2.cpp
Re-uploaded 2.s.
--
alexey at feldgendler dot ru changed:
What|
--- Comment #12 from alexey at feldgendler dot ru 2010-09-02 12:13 ---
Could it be specific to x86_64-linux-gnu?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45496
--- Comment #11 from alexey at feldgendler dot ru 2010-09-02 12:04 ---
Attached cgraph dump from "/usr/lib/gcc/x86_64-linux-gnu/4.5.1/lto1
-fdump-ipa-cgraph 1.o 2.o". For some reason, though, lto1 creates only one dump
file, and that only covers its first input infile.
--- Comment #10 from alexey at feldgendler dot ru 2010-09-02 11:59 ---
Created an attachment (id=21662)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21662&action=view)
-fdump-ipa-cgraph from LTO pass
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45496
--- Comment #9 from alexey at feldgendler dot ru 2010-09-02 11:57 ---
Output of lto1 without -quiet:
$ /usr/lib/gcc/x86_64-linux-gnu/4.5.1/lto1 1.o 2.o
Performing interprocedural optimizations
Assembling functions:
main
Execution times (seconds)
TOTAL : 0.00
--- Comment #8 from alexey at feldgendler dot ru 2010-09-02 11:40 ---
Attached assembler files generated for 1.cpp and 2.cpp, as well as the
assembler file generated by the LTO pass. As can be seen from the latter,
_Z6callmev is referenced but not defined.
--
http://gcc.gnu.org
--- Comment #7 from alexey at feldgendler dot ru 2010-09-02 11:38 ---
Created an attachment (id=21660)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21660&action=view)
Assembly after LTO for entire program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45496
--- Comment #5 from alexey at feldgendler dot ru 2010-09-02 11:35 ---
Created an attachment (id=21658)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21658&action=view)
Assembly for 2.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45496
--- Comment #4 from alexey at feldgendler dot ru 2010-09-02 11:35 ---
Created an attachment (id=21657)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21657&action=view)
Assembly for 1.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45496
--- Comment #3 from alexey at feldgendler dot ru 2010-09-02 11:31 ---
Output of "gcc-4.5 -v 1.cpp 2.cpp":
$ g++-4.5 -v -flto 1.cpp 2.cpp
Using built-in specs.
COLLECT_GCC=g++-4.5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.5.1/lto-wrapper
Target: x86_64-linux-gnu
--- Comment #2 from alexey at feldgendler dot ru 2010-09-02 11:27 ---
Created an attachment (id=21656)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21656&action=view)
TC (2.cpp)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45496
--- Comment #1 from alexey at feldgendler dot ru 2010-09-02 11:27 ---
Created an attachment (id=21655)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21655&action=view)
TC (file 1)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45496
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexey at feldgendler dot ru
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45496
--- Comment #2 from alexey at feldgendler dot ru 2009-07-13 11:40 ---
Happens also on x86_64-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31872
24 matches
Mail list logo
