https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59710
--- Comment #4 from Sandra Loosemore ---
I'm thinking this isn't an appropriate kind of patch to backport to 4.9 -- it's
a fix for a missed optimization and not a serious bug (wrong code or ICE).
Maybe I'm being exceptionally dense here, but I c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377
--- Comment #15 from Sandra Loosemore ---
It looks like the apparent regressions in my test results are actually the
result of cascading errors from the test harness (Dejagnu is failing to fully
reset state after a test that got an error talking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377
--- Comment #13 from Sandra Loosemore ---
I think the new version of the patch in comment 11 is probably OK. I ran the
entire gcc testsuite (but not g++, etc yet) and have a couple hundred
regressions compared to my r217010 build, but I don't se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64231
--- Comment #12 from Sandra Loosemore ---
I'm using a 4.7.3 based gcc as the host compiler (built from one of our own
CodeBench release branches).
Regardless of whether the actual failure is reproducible, if you look at the
code I pointed at in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377
--- Comment #10 from Sandra Loosemore ---
Test results do not look good with the new patch; over 7000 new failures on
-flto tests in the gcc testsuite alone. :-( I see a lot of
lto1: internal compiler error: in operator[], at vec.h:736
0x884ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377
--- Comment #9 from Sandra Loosemore ---
I've started running nios2-elf regression tests on hardware to compare against
a pre-breakage version from early November; it probably will not be done until
tomorrow morning.
I've heard that someone is w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377
--- Comment #5 from Sandra Loosemore ---
I think complete failure to build GCC for nios2 target due to target-inspecific
changes is a serious regression that needs to be addressed for GCC 5 release.
Can we up the priority?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64377
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot com
Assignee|sandra at codesourcery dot com |unassigned at gcc dot
gnu.org
--- Comment #3 from Sandra Loosemore ---
This has been discussed on the gcc-patches mailing list in this thread:
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02616.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64231
--- Comment #7 from Sandra Loosemore ---
H. I'm not sure why there's trouble in reproducing the failure, but
looking at this some more, it seems like we have a problem with this code
fragment from force_const_mem in varasm.c:
/* If we're
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64231
--- Comment #6 from Sandra Loosemore ---
This reproduces it for me; my build is at r217852.
$ aarch64-linux-gnu-gcc argp-help.i -c -O2
argp-help.c: In function '_help':
argp-help.c:1684:1: internal compiler error: Segmentation fault
0x874f9b0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64231
--- Comment #4 from Sandra Loosemore ---
In case it's also relevant, my GCC was configured with:
Configured with: /scratch/sandra/aarch64-fsf/src/gcc-mainline/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=aarch64-linux-gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64231
--- Comment #3 from Sandra Loosemore ---
Created attachment 34225
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34225&action=edit
preprocessor output (gzipped)
Preprocessor output attached.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at codesourcery dot com
CC: belagod at gcc dot gnu.org
Host: i686-pc-linux-gnu
Target: aarch64-linux-gnu
Build: i686-pc-linux-gnu
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64203
--- Comment #4 from Sandra Loosemore ---
(In reply to Jonathan Wakely from comment #3)
> How's this one?
Looks better; this version fixes the compile-time errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64203
--- Comment #2 from Sandra Loosemore ---
(In reply to Jonathan Wakely from comment #1)
> Created attachment 34208 [details]
> fix config macros for shared_lock
>
> Does this fix it?
No, with this patch I'm still getting the same undefined symbo
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at codesourcery dot com
CC: 3dw4rd at verizon dot net
After merging GCC 4.9.2 onto our local branch, I saw that the new libstdc++
testcase experimental/feat-cxx14.cc is failing on bare-metal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62130
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59710
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55821
--- Comment #9 from Sandra Loosemore ---
Yes, that patch (with regenerated Makefile.in) did the trick. Thanks.
config.log says my configure line is:
$ /scratch/sandra/arm-fsf/src/gcc-mainline/libquadmath/configure --srcdir=/scr
atch/sandra/arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55821
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62225
--- Comment #5 from Sandra Loosemore ---
Thinking about this some more
Why doesn't -g always enable -fvar-tracking by default? It's currently only
enabled if you specify both -g and -O.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62225
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61160
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61526
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61610
--- Comment #1 from Sandra Loosemore ---
Hmmm, this looks like a bug in LRA exposed by the change to register alloc
order. In particular this comment in the code just above the assertion seems
to reflect an incorrect assumption:
/* We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102
--- Comment #9 from Sandra Loosemore ---
I've been looking at this a little bit more.
DWARF_FRAME_REGNUM is specifically documented to take a hard register number as
its operand, so the assertion in dwf_regno is at least consistent with that.
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60758
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61021
--- Comment #4 from Sandra Loosemore ---
Patch has been committed to llvm libsanitizer trunk:
http://llvm.org/viewvc/llvm-project?view=revision&revision=208066
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61021
--- Comment #3 from Sandra Loosemore ---
Patch sent to llvm-commits.
For now I can unblock my work by applying the patch locally, but this isn't
something we'd want to carry around permanently and have to apply to future
versions of GCC, especial
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at codesourcery dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at codesourcery dot com
Created attachment 31383
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31383&action=edit
bf_enc.i
The attached test case (part of blowfish) is compiled for MIPS16 with
-Os -DNDEBUG -fno-s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
--- Comment #11 from Sandra Loosemore ---
Updated patch series:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02057.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02058.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02059.html
Unfortunately
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
--- Comment #13 from Sandra Loosemore ---
Updated patch series:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02057.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02058.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02059.html
Unfortunately
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48784
--- Comment #4 from Sandra Loosemore ---
Updated patch series:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02057.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02058.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02059.html
Unfortunately,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623
--- Comment #17 from Sandra Loosemore ---
Updated patch series:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02057.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02058.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02059.html
Unfortunately
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
--- Comment #8 from Sandra Loosemore ---
Thanks for giving it a try. Do you think that in a case such as this where a
single access of the appropriate size cannot be generated due to the struct
having unaligned fields we should generate the same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
--- Comment #5 from Sandra Loosemore ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00750.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
--- Comment #12 from Sandra Loosemore ---
Patch for the first problem posted here:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00750.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48784
--- Comment #3 from Sandra Loosemore ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00750.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623
--- Comment #16 from Sandra Loosemore ---
Patch that fixes regression posted here:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00750.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48784
--- Comment #2 from Sandra Loosemore ---
I'm working on a fix for this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
--- Comment #10 from Sandra Loosemore ---
I'm working on a new patch that addresses the first problem, the failure in
test().
I think the second failure is not in test1() at all, and has nothing to do with
-fstrict-volatile-bitfields. Looks to m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48784
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53633
Sandra Loosemore changed:
What|Removed |Added
CC||sandra at codesourcery dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51910
--- Comment #20 from Sandra Loosemore
2012-02-17 18:51:48 UTC ---
Apropos of the complaint that -frepo produces smaller executables than relying
just on the linker discarding duplicate COMDAT groups I finally got around
to packing up and sub
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51910
--- Comment #17 from Sandra Loosemore
2012-01-30 00:12:53 UTC ---
Cleaned up version of patch, with Jason's test case.
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01591.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51910
--- Comment #16 from Sandra Loosemore
2012-01-29 04:50:12 UTC ---
Created attachment 26498
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26498
new patch
The attached patch seems to DTRT; I tested it also with explicit -Wl,--demangle
and -W
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51910
--- Comment #15 from Sandra Loosemore
2012-01-27 23:22:45 UTC ---
I've just dug around in the code a bit and I think we can fix this. I don't
have a build tree to use for this set up at the moment, but roughly: the loop
to attempt relinking aft
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51910
--- Comment #13 from Sandra Loosemore
2012-01-27 20:14:22 UTC ---
Sigh. I think it would be OK to make -frepo imply --no-demangle, and document
that this is the case. If my previous patch is reverted, that'll still leave
-frepo broken on Window
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51910
--- Comment #11 from Sandra Loosemore
2012-01-27 15:31:14 UTC ---
I like the first patch too. Since -frepo seems to depend on telling the linker
not to demangle, better to just say so.
I'm not familiar with the overall code flow here. Does -fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51910
--- Comment #7 from Sandra Loosemore
2012-01-23 23:14:18 UTC ---
In addition to specifying an explicit command-line option, I think that if you
configure GCC with --with-demangler-in-ld=no it'll restore the previous
behavior, at least on systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49936
--- Comment #10 from Sandra Loosemore
2012-01-05 17:31:39 UTC ---
My notes are that the unnecessary register moves in the loop have been present
since at least GCC 4.3, so it is not a 4.6->4.7 regression, at least.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49936
Sandra Loosemore changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49936
--- Comment #3 from Sandra Loosemore
2011-08-16 04:13:02 UTC ---
Hmmm. Is it possible to make the INT/memory/whatever decision based on move
costs? Or use a target hook to supply a hint about what to do?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49936
--- Comment #1 from Sandra Loosemore
2011-08-01 19:44:34 UTC ---
Created attachment 24886
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24886
WIP patch to MIPS backend
Here is the WIP patch I referred to earlier. This patch (which handles
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49936
Summary: [4.7 regression] IRA handles CANNOT_CHANGE_MODE_CLASS
poorly, + spills to memory on 4.7
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
--- Comment #23 from Sandra Loosemore
2011-06-01 17:34:56 UTC ---
Draft patch that addresses this bug here:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02029.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42505
--- Comment #13 from Sandra Loosemore
2010-10-01 15:01:08 UTC ---
I think this bug is fixed now.
--- Comment #38 from sandra at codesourcery dot com 2010-07-21 16:08
---
On reading the code again, I think the -7 is coming from the can_autoinc case
in determine_use_iv_cost_address. I also think it is correct to prefer
autoinc. E.g., here's the generated code for the lo
--- Comment #37 from sandra at codesourcery dot com 2010-07-21 04:21
---
It seems like the change was introduced by my patch for PR42505 in r161844.
But, it is correctly choosing the lower-cost candidate set -- the problem is in
the cost model, which was unchanged from r161843. Take
--- Comment #36 from sandra at codesourcery dot com 2010-07-21 04:16
---
Created an attachment (id=21275)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21275&action=view)
-fdump-tree-ivopts-details output from r161844
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
--- Comment #35 from sandra at codesourcery dot com 2010-07-21 04:16
---
Created an attachment (id=21274)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21274&action=view)
-fdump-tree-ivopts-details output from r161843
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
--- Comment #17 from sandra at codesourcery dot com 2010-07-13 17:13
---
As a point of clarification, I am not getting paid to care about this issue
either. :-) At this time I have no plans to continue working on it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39837
--- Comment #14 from sandra at codesourcery dot com 2010-07-13 16:13
---
There are two patches that made the difference: r158189 (Carrot's patch for
PR42601) and r162043 (the second part of my patch for PR42505). I checked that
backporting these two changes to the 4.5 bran
--- Comment #14 from sandra at codesourcery dot com 2010-07-11 17:47
---
Yes, it looks like the prototype fix for PR 36758 fixes the test case at the
top of this issue. The patch needs a little updating, though, and I can't say
I grok the changes to the surrounding code suffici
--- Comment #13 from sandra at codesourcery dot com 2010-07-11 01:22
---
Some further analysis:
The part of my PR42505 patch that made the difference was the change to
estimate_register_pressure_cost in cfgloopanal.c, to make it exclude the
call-clobbered registers. This part was
--- Comment #11 from sandra at codesourcery dot com 2010-07-10 21:07
---
I just checked to see if this is still a problem. As of r162042, the example
in comment #1 produces the same (bad) output as GCC 4.4.1. However, the example
in comment #4 looks fixed to me, with this output
--- Comment #9 from sandra at codesourcery dot com 2010-07-07 01:09 ---
Yes, this is on an Ubuntu system, but one of my co-workers says GCC multilibs
work with Ubuntu now; the support is in gcc/config/i386/t-linux64. Me, I'm
clueless about anything configury-related. :-( I ca
--- Comment #7 from sandra at codesourcery dot com 2010-07-07 00:42 ---
Hmmm. It's possible I built my toolchain incorrectly, but I'm seeing that it
aborts when compiled with -m64 but not with -m32. The failure mode looks
identical to that reported in PR39794:
(gdb) print
--- Comment #4 from sandra at codesourcery dot com 2010-07-06 21:10 ---
Well, I'm *trying* to investigate but I haven't been able to reproduce the
problem yet. I checked out r161844 and built for i686-pc-linux-gnu, and the
gcc.dg/pr39794.c execution test passes. If thi
--- Comment #2 from sandra at codesourcery dot com 2010-07-06 15:57 ---
s/caused by/exposed by/ ?
The patch to ivopts likely results in it selecting a different/smaller set of
loop induction variables, but I don't see how this change by itself could have
introduced a wrong-code
--- Comment #12 from sandra at codesourcery dot com 2010-06-22 18:02
---
Hrmmm, I was planning to attempt a 4.5 backport of the PR42505 patch for
internal use, but if it's not easy or doesn't help, I think I have better
things to do with my time than to try to come up with
--- Comment #10 from sandra at codesourcery dot com 2010-06-22 16:26
---
It looks like this bug has been fixed by my proposed patch for PR42505:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01920.html
Applying that patch to r160755 gives:
:
0: b570push
--- Comment #6 from sandra at codesourcery dot com 2010-06-22 01:55 ---
Julian's patch overlapped some other NEON changes I was already preparing for
submission, so I did some refactoring before posting it for review. Here's the
main part of the fix:
http://gcc.gnu.org/ml/g
--- Comment #10 from sandra at codesourcery dot com 2010-06-19 12:56
---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01920.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42505
--- Comment #9 from sandra at codesourcery dot com 2010-06-12 07:42 ---
I now have a specific theory of what is going on here. There are two problems:
(1) estimate_reg_pressure_cost is not accounting for the function call in the
loop body. In this case it ought to use call_used_regs
--- Comment #8 from sandra at codesourcery dot com 2010-06-10 13:01 ---
I was barking up the wrong tree with my last idea -- the signed/unsigned
conversion business was a red herring. Here's what I now believe is the
problem: the costs computation is underestimating the reg
--- Comment #7 from sandra at codesourcery dot com 2010-06-05 20:41 ---
OK, I'm testing a hack to rewrite_use_compare to make it know that it doesn't
have to introduce a temporary just to compare against constant zero. I'm also
doing a little tuning of the costs model
--- Comment #4 from sandra at codesourcery dot com 2010-06-04 00:09 ---
I've been looking at this problem today. Here's the stupid part coming out of
ivopts:
:
# ivtmp.7_21 = PHI <0(2), ivtmp.7_20(4)>
# ivtmp.10_22 = PHI
count_25 = (int) ivtmp.10_22;
i
--- Comment #15 from sandra at codesourcery dot com 2010-06-01 02:24
---
Proposed patch for PR 39874/comment #5 posted here:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg1.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
--- Comment #4 from sandra at codesourcery dot com 2010-06-01 02:22 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg1.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39874
--- Comment #13 from sandra at codesourcery dot com 2010-05-24 13:21
---
I'm working on a patch that fixes the test case in comment #5 (originally filed
as PR 39874) and some other test cases by improving the comparison combination
logic in both tree-ssa-ifcombine and tree-ssa-re
--- Comment #3 from sandra at codesourcery dot com 2010-05-24 13:08 ---
I'm testing a fix for this (better comparison combination logic in the
ifconvert pass).
--
sandra at codesourcery dot com changed:
What|Removed |
--- Comment #11 from sandra at codesourcery dot com 2010-05-08 03:43
---
I've posted the patch to fix the first testcase here:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00564.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
--- Comment #10 from sandra at codesourcery dot com 2010-05-07 02:32
---
I've been working on a patch that fixes the original reported problem by adding
a little logic to tree-ssa-reassoc.c to make it look for places where it can
use combine_comparisons. Note that this test case
--- Comment #6 from sandra at codesourcery dot com 2009-08-24 22:36 ---
This bug appears to be fixed in mainline HEAD now. Here's an excerpt showing
the generated code for the inner loop in the example program now:
addiu $21,$28,%gp_rel(AA)
addiu $10,$28,%gp_
--- Comment #9 from sandra at codesourcery dot com 2009-04-03 12:54 ---
After the merge of the alias_improvements branch to trunk, the test case no
longer compiles incorrectly at -O1. Is this coincidence, or a real fix that
addresses the underlying problem?
--
http://gcc.gnu.org
--- Comment #1 from sandra at codesourcery dot com 2009-03-31 22:37 ---
Created an attachment (id=17573)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17573&action=view)
C++ test case sink-1.C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
ra at codesourcery dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
--- Comment #5 from sandra at codesourcery dot com 2008-06-30 02:05 ---
Maybe I'm just being clueless here, but I don't understand why this bug was
re-categorized. In my original analysis, I traced the bad code directly to the
RA pass un-doing the results of previous opt
--- Comment #3 from sandra at codesourcery dot com 2008-05-12 19:10 ---
One other tidbit: the MIPS SDE 3.4.4-based toolchain produced the desired code
for this test case. It's really a 4.* regression, not an enhancement.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36223
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sandra at codesourcery dot com
GCC build triplet: i686-pc-linux
1 - 100 of 108 matches
Mail list logo
