--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from steven at gcc dot gnu dot org 2009-06-22 17:58 ---
Compiling with gcc 4.4.1 with options "-Os -mtune=cortex-a8" I get this:
.cpu arm7tdmi
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attri
--- Comment #6 from steven at gcc dot gnu dot org 2009-06-22 18:25 ---
I get the same code with 4.5-today as the code of comment #5. I configured for
--target=arm-eabi. Should I configure differently to see the shifts instead of
ands?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #7 from steven at gcc dot gnu dot org 2009-06-22 18:25 ---
see the uxtbs instead of the ands, that is...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
--- Comment #12 from steven at gcc dot gnu dot org 2009-06-22 22:17 ---
Three and a half year of nothing. Dead horse.
=> Closing. If something shows up, open a new bug report please.
--
steven at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #1 from steven at gcc dot gnu dot org 2009-06-22 22:18 ---
Uros, this bug is from the pre-IRA times. Could you check if you still see
this problem, please?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2009-06-22 22:23 ---
Vlad, what can we do with IRA to make it choose a better regclass here? Maybe
do something similar to what MIPS does, changing IRA_COVER_CLASSES for i386
depending on target options?
--
http://gcc.gnu.org
--- Comment #3 from steven at gcc dot gnu dot org 2009-06-22 23:22 ---
Digging old bugs can be fun...
Andrew, do you think this is perhaps fixed by Jakub's x86 mem* work?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12966
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-22 23:24 ---
Qualcomm does someting like this, see:
http://www.capsl.udel.edu/conferences/open64/2009/Papers/101-codeSizeOpen64_Qualcomm.pdf
http://www.capsl.udel.edu/conferences/open64/2009/Slides/001-101
--- Comment #3 from steven at gcc dot gnu dot org 2009-06-23 09:47 ---
This should be done in if conversion. I'll have a look.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #10 from steven at gcc dot gnu dot org 2009-06-23 09:50 ---
Yes, this bug is indeed not related to bug 39715.
I have also verified that the SEE pass (sign-extend elimination, but also
should handle zero-extend) fails to handle this case. And that pass doesn't
exist an
--- Comment #4 from steven at gcc dot gnu dot org 2009-06-23 12:31 ---
This is the usual idiotic behavior of ifcvt.c for targets that have conditional
execution, but not for all insns.
Normally the find_if_case_1() transformation should handle this optimization.
But the
--- Comment #4 from steven at gcc dot gnu dot org 2009-06-24 07:42 ---
Couldn't this be fixed also by changing the initial gimplification from:
p.0 = p;
p = p + 1;
foo (p.0);
to:
p.0 = p;
foo (p.0);
p = p + 1;
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34737
--- Comment #9 from steven at gcc dot gnu dot org 2009-06-24 07:45 ---
I agree with Comment #8
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2009-06-24 07:49 ---
How are things progressing with a fix for this, Richi? :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-24 12:37 ---
Not a self-contained bug report: Impossible to reproduce unless you have the
intel compiler. Maybe you can attach the assembler output of ifort?
--
steven at gcc dot gnu dot org changed:
What
--- Comment #5 from steven at gcc dot gnu dot org 2009-06-25 08:17 ---
Tentative patch:
Index: ifcvt.c
===
--- ifcvt.c (revision 148927)
+++ ifcvt.c (working copy)
@@ -3780,6 +3780,8
--- Comment #6 from steven at gcc dot gnu dot org 2009-06-25 20:24 ---
Patch posted.
Many thanks to Google for doing all this code analysis.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2009-06-26 06:06 ---
Subject: Bug 40525
Author: steven
Date: Fri Jun 26 06:06:04 2009
New Revision: 148961
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148961
Log:
PR middle-end/40525
*
--- Comment #8 from steven at gcc dot gnu dot org 2009-06-26 06:06 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from steven at gcc dot gnu dot org 2009-06-26 06:12 ---
Adding IPA-CP to CC...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2009-06-29 12:00 ---
Ack. Honza, yours I would guess.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-29 12:02 ---
Richi, do you have a test case you can share? I have seen this problem in code
I can't take public...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40585
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40416
--- Comment #7 from steven at gcc dot gnu dot org 2009-06-30 08:21 ---
Please adjust the test case:
/* { dg-options "-O2 -Os -fdump-tree-sink-stats" } */
This makes no sense, -Os implies -O2. So it should be:
/* { dg-options "-Os -fdump-tree-sink-stats&quo
--- Comment #3 from steven at gcc dot gnu dot org 2009-06-30 11:35 ---
For this test case:
unsigned int code_in_ram[100];
void testme(void)
{
unsigned int *p_rom, *p_ram, *p_end, len;
extern unsigned int _ram_erase_sector_start;
extern unsigned int _ram_erase_sector_end
--- Comment #8 from steven at gcc dot gnu dot org 2009-06-30 13:14 ---
Honza, I can take care of the CSiBE run if you want.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
--- Comment #4 from steven at gcc dot gnu dot org 2009-06-30 13:21 ---
The auto-inc-dec pass fails because the store and the reg increment are not in
the same basic block. The dump of the pass before auto-inc-dec (reginfo) looks
like this:
;; Function testme (testme)
74
--- Comment #5 from steven at gcc dot gnu dot org 2009-06-30 13:27 ---
Compiling with "./cc1 -Os t.c -fno-ivopts" I get the following code:
.global testme
.type testme, %function
testme:
@ Function supports interworking.
@ args = 0, pretend
--- Comment #10 from steven at gcc dot gnu dot org 2009-06-30 19:55 ---
I see no effect whatsoever of the patch for for CSiBE on arm-elf-unknown.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
--- Comment #12 from steven at gcc dot gnu dot org 2009-07-01 05:41 ---
Yes, at -Os.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
--- Comment #3 from steven at gcc dot gnu dot org 2009-07-02 09:15 ---
Is there a C test case? Can you add objdump of the gcc-generated asm and the
fixed asm to show the impact on code size? (/me is surprised that 3*"add
r0,sp,4" is smaller than 1**"add r0,sp,4"+3*
--- Comment #9 from steven at gcc dot gnu dot org 2009-07-02 15:12 ---
Note I have various working patches for GVN-based hoisting. All of them are
actually too aggressive, causing failures in the vectorizer test cases
(unrecognizable data dependency patterns). But I still intend to
--- Comment #6 from steven at gcc dot gnu dot org 2009-07-02 15:40 ---
Dan, you mentioned a "pointer_no_escape" attribute. What was that about? I've
never seen that mentioned before (or a patch to implement it). Sounds like a
cool attribute to have (and not just f
--- Comment #2 from steven at gcc dot gnu dot org 2009-07-06 09:13 ---
IIRC push-multiple and pop-multiple are not supported yet. Richard E.?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2009-07-06 10:43 ---
Ah, heh, so you're saying that pushing/popping registers you don't have to save
may be a size optimization? That's an interesting idea.
But how to do this in GCC... The "push {lr}" is never
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #2 from steven at gcc dot gnu dot org 2009-07-09 09:59 ---
Maybe we can fix this in expand instead: if we see (x & CONST) and CONST is a
masking constant that isn't a legitimate constant for the the target, then see
if the sum of the rtx_cost of expressing the mask
--- Comment #3 from steven at gcc dot gnu dot org 2009-07-13 10:10 ---
And no, it is *not* OK to remove this kind of redundant code in DCE. The load
may be redundant, but it is not dead.
It is not clear to me why cleanup_cfg would move that insn. Perhaps you can
show what is going on
--- Comment #5 from steven at gcc dot gnu dot org 2009-07-14 09:18 ---
As you said, try_crossjump_bb tries to find the same instruction sequence in
*all* predecessors of a basic block bb. Meaning that the load must have been
redundant even before cross jumping occurred.
If you are
--- Comment #6 from steven at gcc dot gnu dot org 2009-07-14 09:20 ---
Carrot, can you please try this test case with my patch
"crossjump_abstract.diff" from Bug 20070 applied?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40730
--- Comment #2 from steven at gcc dot gnu dot org 2009-07-14 09:26 ---
Microblaze is not an FSF GCC version.
Please report this bug to the distributor of mb-gcc (Google says this is
http://www.petalogix.com/resources/downloads/mb-gcc). and kindly request them
to adjust the bug
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from steven at gcc dot gnu dot org 2009-07-15 07:21 ---
Ack.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.5.0
Known to work||4.3.0
Target
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40500
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40543
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40596
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40660
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40671
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40700
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40701
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40743
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
--- Comment #12 from steven at gcc dot gnu dot org 2009-07-15 07:30 ---
Tom, ping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40154
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40714
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40760
--- Comment #8 from steven at gcc dot gnu dot org 2009-07-15 07:34 ---
Does seem to be a real issue, somewhere.
When trunk builds again, can you please give it a try too?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2009-07-15 07:36 ---
Paul, ping. This is almost 3 years with zero progress. If this is not an
issue in GCC 4.3 or later, then please close this PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28547
--- Comment #8 from steven at gcc dot gnu dot org 2009-07-15 07:38 ---
The audit log for this PR is awfully quiet... Ping?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457
--- Comment #1 from steven at gcc dot gnu dot org 2009-07-15 07:46 ---
Richi, this looks like it should go into your bucket of things to look at:
==6729== Conditional jump or move depends on uninitialised value(s)
==6729==at 0x84F22CB: solve_graph (tree-ssa-structalias.c:1570
--- Comment #8 from steven at gcc dot gnu dot org 2009-07-15 09:47 ---
That redundant move has to be a separate issue, indeed. I would expect the
register allocator to coalesce those registers.
I hadn't expected this. I thought the result would be just the removal of the
redu
--- Comment #15 from steven at gcc dot gnu dot org 2009-07-15 21:12 ---
*** Bug 40768 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2009-07-15 21:12 ---
I will re-test and submit my PRE patches this weekend (richi: including the -Os
PRE patch unless you already put yours in first -- but mine is nicer ;-)
*** This bug has been marked as a duplicate of 38785
--- Comment #4 from steven at gcc dot gnu dot org 2009-07-15 21:35 ---
I have a patch for PPRE to stop inserting this much (want_to_ppre_p).
Basically make it insert only once.
*** This bug has been marked as a duplicate of 38785 ***
--
steven at gcc dot gnu dot org changed
--- Comment #16 from steven at gcc dot gnu dot org 2009-07-15 21:35 ---
*** Bug 40768 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
--- Comment #3 from steven at gcc dot gnu dot org 2009-07-19 07:57 ---
What is the last revision that is known to work?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40797
--- Comment #6 from steven at gcc dot gnu dot org 2009-07-19 22:08 ---
*sigh* another kernel bug where kernel developers just immediately look to
blame gcc instead of trying to see their own mistake...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40803
--- Comment #2 from steven at gcc dot gnu dot org 2009-07-21 07:23 ---
You mean to say that all tree optimizers, CSE, CPROP, fwprop, and combine fail
to eliminate this? Wow. What does the .expand dump look like (compile with
extra flag -fdump-rtl-expand-details, then attach the .expand
--- Comment #4 from steven at gcc dot gnu dot org 2009-07-24 06:27 ---
A hint, please, about why the patch of comment #2 would be the correct fix. As
far as I can tell, loop-iv doesn't need the notes and shouldn't have to clean
up other passes' mess. This patch also in
--- Comment #3 from steven at gcc dot gnu dot org 2009-07-24 06:59 ---
Because HAVE_cc0 is only for cc0 targets, and ARM is not one of those?
You should stop jumping to peepholes for every missed optimization you find.
There is a csecc pass (part of cse2) that should handle this. You
--- Comment #5 from steven at gcc dot gnu dot org 2009-07-24 08:25 ---
The fact that the move sets the condition code is not modelled in the insn.
>From .expand dump:
(insn 6 5 7 3 t.c:5 (set (reg/v:SI 133 [ v ])
(reg:SI 0 r0)) -1 (nil))
>From -dAP output:
@(insn 6 5 7
--- Comment #6 from steven at gcc dot gnu dot org 2009-07-24 08:48 ---
In fact even the compare isn't a separate insn:
@(insn 6 5 7 t.c:5 (set (reg/v:SI 1 r1 [orig:133 v ] [133])
@(reg:SI 0 r0)) 167 {*thumb1_movsi_insn} (nil))
@ 0x0004
mov r1, r0
--- Comment #6 from steven at gcc dot gnu dot org 2009-07-24 17:04 ---
Then we should write a new function, something like this in df.h perhaps:
/* Given an INSN, return a SET expression if the insn has only one
SET whose SET_DEST is used. If SET_DEST is memory, then the SET is
--- Comment #4 from steven at gcc dot gnu dot org 2009-07-30 16:36 ---
And -O4 doesn't exist, FWIW.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40910
--- Comment #2 from steven at gcc dot gnu dot org 2009-08-04 09:05 ---
Hoisting
*** This bug has been marked as a duplicate of 23286 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from steven at gcc dot gnu dot org 2009-08-04 09:05 ---
*** Bug 40956 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2009-08-04 09:10 ---
Yup
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from steven at gcc dot gnu dot org 2009-08-06 22:12 ---
Instead of guessing -- why not inspect the dumps you get with -fdump-tree-all
-fdump-rtl-all and see if someone can figure out which pass is the first to
screw up the test case?
--
http://gcc.gnu.org/bugzilla
--- Comment #6 from steven at gcc dot gnu dot org 2009-08-06 22:13 ---
If it turns out to be the RTL if-conversion pass, assign this bug to me please.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2009-08-07 09:47 ---
Re. comment #6: doloop never worked on x86 except for the AMD K6. x86 does not
have a doloop pattern.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40886
--- Comment #2 from steven at gcc dot gnu dot org 2009-08-08 09:07 ---
Why does the basic block reordering pass also not handle this?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #8 from steven at gcc dot gnu dot org 2009-08-08 22:24 ---
This bug is as dead as SCO.
With the difference, of course, that all issues in this meta-bug appear to be
fixed, whereas SCO is still damaged goods :-)
--
steven at gcc dot gnu dot org changed:
What
--- Comment #3 from steven at gcc dot gnu dot org 2009-08-08 22:26 ---
No progress for >6 years. Concerns a very old, no longer supported GCC version.
-> WONTFIX
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from steven at gcc dot gnu dot org 2009-08-08 22:35 ---
I believe this should be closed as WONTFIX. Warnings exist to indicate things
in the program that are almost certainly wrong. In this case, the only way to
really avoid false positives is to look at the context of
--- Comment #2 from steven at gcc dot gnu dot org 2009-08-08 22:37 ---
Would anyone object if this gets closed as WONTFIX?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2009-08-08 22:38 ---
Any news on this one?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2009-08-08 22:42 ---
Let's be realistic about this one: It will not be fixed, ever.
-> WONTFIX
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from steven at gcc dot gnu dot org 2009-08-08 22:47 ---
Looks OK in r150579. Fixed somewhere along the road. Going through really old
bug reports can be so rewarding...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2009-08-08 22:52 ---
Obviously something experienced by more than one user, on more than one
platform.
Tom, can you make a guess about what is wrong based on the suggested
work-around of comment #5?
--
steven at gcc dot gnu dot org
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from steven at gcc dot gnu dot org 2009-08-10 07:16 ---
SRA expert -> CC
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
--- Comment #2 from steven at gcc dot gnu dot org 2009-08-10 21:29 ---
Hmm, this isn't my day. Of course you're right, Andrew.
So the issue is that a loop invariant load is not hoisted at -Os, because it
does not improve size.
FWIW several patches have been proposed to c
301 - 400 of 3051 matches
Mail list logo
