https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66068
Matt Hargett changed:
What|Removed |Added
CC||matt at use dot net
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65289
--- Comment #1 from Matt Hargett ---
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.
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=34929&action=edit
pre-processed source file that reproduces the crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55500
--- Comment #4 from Matt Hargett ---
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55500
Matt Hargett changed:
What|Removed |Added
Version|4.8.0 |4.9.0
--- Comment #2 from Matt Hargett --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55498
Matt Hargett changed:
What|Removed |Added
Version|4.8.0 |4.9.0
--- Comment #5 from Matt Hargett --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478
Matt Hargett changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477
Matt Hargett changed:
What|Removed |Added
Status|NEW |RESOLVED
Version|4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55499
Matt Hargett changed:
What|Removed |Added
Component|middle-end |ipa
Version|4.8.0
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 success
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56526
--- Comment #4 from Matt Hargett 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 expe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56526
--- Comment #1 from Matt Hargett 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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644
--- Comment #12 from Matt Hargett 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644
Matt Hargett changed:
What|Removed |Added
Summary|bootstrap-lto fails on |maybe-uninitialized false
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644
--- Comment #10 from Matt Hargett 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264
Matt Hargett changed:
What|Removed |Added
CC||matt at use dot net
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477
--- Comment #7 from Matt Hargett 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478
--- Comment #11 from Matt Hargett 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644
--- Comment #7 from Matt Hargett 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55496
Matt Hargett changed:
What|Removed |Added
CC||matt at use dot net
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44938
Matt Hargett changed:
What|Removed |Added
CC||matt at use dot net
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
--- Comment #12 from Matt Hargett 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_f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
--- Comment #11 from Matt Hargett 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55498
--- Comment #3 from Matt Hargett 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478
--- Comment #9 from Matt Hargett 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477
--- Comment #6 from Matt Hargett 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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644
--- Comment #5 from Matt Hargett 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/ -no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371
--- Comment #13 from Matt Hargett 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 declarat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371
Matt Hargett changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50148
--- Comment #7 from Matt Hargett 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50148
--- Comment #6 from Matt Hargett 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/m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55498
--- Comment #2 from Matt Hargett 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?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50148
--- Comment #5 from Matt Hargett 2012-12-17 19:12:11 UTC
---
Just verified this still happens in 4.7 and trunk.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644
Matt Hargett changed:
What|Removed |Added
Summary|profiledbootstrap fails on |bootstrap-lto fails on
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55596
--- Comment #2 from Matt Hargett 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 decreas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55595
--- Comment #2 from Matt Hargett 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51233
--- Comment #5 from Matt Hargett 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'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55074
Matt Hargett changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
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
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: unkn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50468
Matt Hargett changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48670
Matt Hargett changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50398
--- Comment #1 from Matt Hargett 2012-12-03 23:20:57 UTC
---
loop flattening was removed as a feature, yes? If so, this bug can be closed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45700
Matt Hargett changed:
What|Removed |Added
CC||matt at use dot net
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42628
Matt Hargett changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48670
--- Comment #10 from Matt Hargett 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.
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55499
--- Comment #1 from Matt Hargett 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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477
--- Comment #4 from Matt Hargett 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
fantast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478
--- Comment #7 from Matt Hargett 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481
--- Comment #3 from Matt Hargett 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481
--- Comment #1 from Matt Hargett 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 ex
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55219
--- Comment #1 from Matt Hargett 2012-11-06 01:31:22 UTC
---
Perhaps worth noting that gcc/trunk and google/4_7 also still exhibit the
problem.
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53780
Matt Hargett changed:
What|Removed |Added
CC||matt at use dot net
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572
Matt Hargett changed:
What|Removed |Added
CC||matt at use dot net
--- Comment #11 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676
--- Comment #16 from Matt Hargett 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 mult
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676
--- Comment #12 from Matt Hargett 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54307
--- Comment #3 from Matt Hargett 2012-08-21 17:26:55 UTC
---
Paolo, what about list? Does VC11 achieve the size GCC 4.6 has by not
being compliant somehow?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #20 from Matt Hargett 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
ve
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51233
--- Comment #4 from Matt Hargett 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #19 from Matt Hargett 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!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51233
--- Comment #2 from Matt Hargett 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 optim
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49797
--- Comment #6 from Matt Hargett 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 proble
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37242
--- Comment #22 from Matt Hargett 2012-06-29 00:20:17 UTC
---
Hey Andrew, any word on your patch?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676
--- Comment #10 from Matt Hargett 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 t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676
--- Comment #2 from Matt Hargett 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676
--- Comment #1 from Matt Hargett 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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #15 from Matt Hargett 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?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #11 from Matt Hargett 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 co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #5 from Matt Hargett 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #4 from Matt Hargett 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #3 from Matt Hargett 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #1 from Matt Hargett 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 o
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51564
--- Comment #7 from Matt Hargett 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49797
--- Comment #5 from Matt Hargett 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 lo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51564
Matt Hargett changed:
What|Removed |Added
CC||matt at use dot net
--- Comment #5 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49797
Matt Hargett changed:
What|Removed |Added
CC||matt at use dot net
--- Comment #3 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52610
Matt Hargett changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #7 from Matt Hargett
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52704
Matt Hargett changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717
--- Comment #13 from Matt Hargett 2012-04-23 15:19:47 UTC
---
*** Bug 52704 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717
--- Comment #7 from Matt Hargett 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,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717
--- Comment #6 from Matt Hargett 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 registr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717
--- Comment #5 from Matt Hargett 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
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: UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52704
--- Comment #1 from Matt Hargett 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
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
Versio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52610
--- Comment #6 from Matt Hargett 2012-03-24 20:20:42 UTC
---
Great. I verified the fix yesterday. Thanks!
1 - 100 of 238 matches
Mail list logo
