--- 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 even in the RTL. Output
--
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 #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*mov r0,r4... Thumb
--- 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
--- 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 for Fortran, too
--- 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 = 0, frame
--- 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 #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
--- 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=gccview=revrev=148961
Log:
PR middle-end/40525
* ifcvt.c
--- 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 #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 #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 #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 |Added
--- 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 anymore
--- 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
--- Comment #5 from steven at gcc dot gnu dot org 2009-06-22 08:06 ---
The only way to really fix this, is to make an RTL epilogue for thumb. Turning
to Richard Earnshaw again for advice...
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from steven at gcc dot gnu dot org 2009-06-22 08:12 ---
Re. Comment #5:
I have no plans to sumbit this patch. But do feel free to foster-parent it ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28050
--- Comment #6 from steven at gcc dot gnu dot org 2009-06-22 16:21 ---
Is there anything in the tool chain that handles this right now (linker maybe)?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2009-06-22 16:25 ---
Since this is inherently a heuristics issue, and the IRA heuristics result in
overall better code size according to Vlad, I would like to propose we close
this PR as WONTFIX. Would anyone object to that?
--
http
--- Comment #5 from steven at gcc dot gnu dot org 2009-06-22 16:29 ---
How is this different from bug 39837?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2009-06-22 16:32 ---
Did that patch go in already?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2009-06-22 16:36 ---
Is this related to bug 39715?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
--- Comment #11 from steven at gcc dot gnu dot org 2009-06-22 16:41 ---
IIUC comment #8, this bug depends on bug 29336.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2009-06-22 16:14 ---
Note that we usually add the name of the committer to the ChangeLog too, like
so:
2009-06-22 Steven Bosscher ...
Matthias Klose ...
etc.
But thanks for handling the patch. Fixed on trunk
--
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_attribute 23, 3
--- 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 |Added
--- 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-20 07:23 ---
Output from ./cc1 -march=armv5te -mthumb -Os PR40499.c -dAP:
.file PR40499.c
.text
.align 1
.global dual_feasible
.code 16
.thumb_func
.type
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-20 05:56 ---
There is an optimization that does this (thread prologue/epilogue insns) but it
is not always a profitable transformation, see e.g. PR40361.
You should analyze why this transformation doesn't happen for your case
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-18 14:00 ---
Why does the zero-bits machinery in combine not make these redundant extensions
go away?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-14 18:04 ---
For reference:
Broken by http://gcc.gnu.org/viewcvs?view=revrevision=148471
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from steven at gcc dot gnu dot org 2009-06-14 19:54 ---
Created an attachment (id=17995)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17995action=view)
Patch agains r148322, works pre-RA only
Joern's original ifcvt.c patch only dealt with pre-reload if-conversion
--- Comment #6 from steven at gcc dot gnu dot org 2009-06-13 23:45 ---
I would still like to know why these constants can't be lowered earlier.
Exposing the split-up insns may allow CSE to do a better job, etc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40327
--- Comment #16 from steven at gcc dot gnu dot org 2009-06-11 19:48 ---
The patch is in 4.4. Apparently it doesn't work? I'll have another look...
--
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 #5 from steven at gcc dot gnu dot org 2009-06-09 08:34 ---
Hmm, I was under the impression that postreload-cse could move instructions
too, but that was just wishful thinking.
I don't really see how the scheduler can solve this. The scheduler would have
to know what
--- Comment #3 from steven at gcc dot gnu dot org 2009-06-08 11:41 ---
might be is such a useless statement.
Carrot, you are aware of the -fdump-rtl-all and -dAP options, I assume? Then
you should have no trouble finding out:
1) Where the move comes from
2) Why postreload (the post
--- Comment #9 from steven at gcc dot gnu dot org 2009-06-08 22:43 ---
There shouldn't be a !. Just make use optimize_function_for_speed_p(cfun).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39284
--- Comment #10 from steven at gcc dot gnu dot org 2009-06-08 22:45 ---
Honza, what do the basic blocks 2 and 71 look like for you, exactly? I see no
memory load. But I have local crossjumping patches -- as you know ;-) -- so I
am probably not looking at the same dumps as you
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
GCC target triplet: arm-elf
OtherBugsDependingO
--- Comment #1 from steven at gcc dot gnu dot org 2009-06-06 17:56 ---
I tested the patch on arm-elf (-march=armv7-r and -march=armv7 -mthumb),
trunk revision 148235, -Os, unpatched and patched, with CSiBE:
armv7-r:
unpatched : 3557127 bytes
patched : 3554655 bytes
win: 2472 bytes
--- Comment #4 from steven at gcc dot gnu dot org 2009-06-04 12:52 ---
This is one of the GCC 4.5 pending patches. Now would be a good time to do
something with this patch -- like, submitting it.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-04 12:53 ---
This is one of the GCC 4.5 pending patches. Since we are in stage 1, now is a
good time to submit this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38091
--- Comment #32 from steven at gcc dot gnu dot org 2009-06-04 12:54 ---
Jerry, was the patch submitted already?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32784
--- Comment #11 from steven at gcc dot gnu dot org 2009-06-04 12:55 ---
Oh, the temptation to close this as WONTFIX Objections?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #35 from steven at gcc dot gnu dot org 2009-06-04 12:58 ---
This bug is marked as one of the GCC 4.5 pending patches PRs. Why? I see no
pending patch...?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20548
--- Comment #1 from steven at gcc dot gnu dot org 2009-06-03 10:36 ---
This code comes from the split2 (split insns after reload). So this is target
specific. It surprises me that non-legitimate constants are accepted before
reload on ARM (at least in thumb mode). It may be (and IMHO
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-03 10:57 ---
FWIW it looks like the define_split at arm.c:5060 (of r147729) is triggered.
Richard E., is there a reason for lowering load-immediates so late in the
pipeline?
--
steven at gcc dot gnu dot org changed
--- Comment #3 from steven at gcc dot gnu dot org 2009-05-28 18:15 ---
This will never be implemented.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC|steven at gcc dot gnu dot |
|org |
AssignedTo
--- Comment #3 from steven at gcc dot gnu dot org 2009-05-14 20:24 ---
FWIW:
-fstrength-reduce is a no-op
-fcse-follow-jumps is a no-op
-fcse-skip-blocks -is a no-op (the crash will be fixed before the day is over)
-fforce-addr isa no-op
The gnuboy maintainers should probably look
--- Comment #4 from steven at gcc dot gnu dot org 2009-05-14 20:57 ---
Subject: Bug 40144
Author: steven
Date: Thu May 14 20:56:54 2009
New Revision: 147543
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147543
Log:
PR driver/40144
* opts.c (common_handle_option
--- Comment #5 from steven at gcc dot gnu dot org 2009-05-14 20:57 ---
http://gcc.gnu.org/viewcvs?view=revrevision=147543
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from steven at gcc dot gnu dot org 2009-05-10 13:51 ---
The late stack slot allocation idea will just cause other problems, like
missing CSE of addresses. GCC should just get the conflicts right somehow...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||steven at gcc dot gnu dot
--- Comment #77 from steven at gcc dot gnu dot org 2009-05-07 17:50 ---
Re. comment #75: Just the fact that an option is enabled in both releases
doesn't mean the pass behind it is doing the same thing in both releases. What
the scheduler does, depends heavily on the code you feed
--- Comment #6 from steven at gcc dot gnu dot org 2009-05-01 08:44 ---
I still see no answer to my question from comment #1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34849
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #8 from steven at gcc dot gnu dot org 2009-05-01 21:51 ---
Crossjumping does nothing, because there is nothing to crossjump anymore at
that point. The two stores have been replaced with one and a conditional set:
- in .ce1 (ifcvt1) we haven't converted to a conditional set
--- Comment #9 from steven at gcc dot gnu dot org 2009-05-01 22:27 ---
FWIW, early crossjumping (after ce1) doesn't work either.
The code before trying to crossjump looks like this:
44 pc={(cc:CC=0x0)?L50:pc}
REG_DEAD: cc:CC
REG_BR_PROB: 0x1388
45
--- Comment #10 from steven at gcc dot gnu dot org 2009-04-30 07:51 ---
These functions will *not* be implemented, period.
And even if they would be implemented, they'd internally just return
sin(arg*180/pi) co. The compiler and the runtime library don't actually
calculate sin/cos
--- Comment #8 from steven at gcc dot gnu dot org 2009-04-25 22:24 ---
Re. comment #5 -- what doesn't work very well, i.e. what massive breakage does
your patch cause?
Maybe you can treat static locals optimistically if they are only stored to
once?
--
http://gcc.gnu.org/bugzilla
--- Comment #1 from steven at gcc dot gnu dot org 2009-04-18 19:24 ---
Spurious differences fall in the wrong code category.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2009-04-18 20:01 ---
Similar as what is said in commen #0, the detailed vrp1 dump of trunk today
has:
Removing basic block 3
;; basic block 3, loop depth 0, count 0
;; prev block 7, next block 4
;; pred:
;; succ: 8 [100.0
--- Comment #2 from steven at gcc dot gnu dot org 2009-04-13 21:59 ---
Is this really broken when the Apple compiler has the same behavior (assuming
we all accept that the Apple Objective-C semantics are the de facto standard)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39753
--- Comment #13 from steven at gcc dot gnu dot org 2009-04-12 23:46 ---
The real bug is that somehow MEM_ATTRS are not shared anymore. We have lots
and lots of exactly the same expression in the table, e.g.:
Index 3 (hash value 4232)
(mem/s/f/c:SI (plus:SI (reg/f:SI 20 frame
--- Comment #14 from steven at gcc dot gnu dot org 2009-04-12 23:52 ---
Ah, how subtle.
(gdb) p MEM_ATTRS(x)
$25 = (mem_attrs *) 0x7f20d1ad0440
(gdb) p MEM_ATTRS(y)
$26 = (mem_attrs *) 0x7f20d1ad71a0
(gdb) p MEM_ATTRS(*x)
$27 = (mem_attrs *) 0x7f20d1ad0440
(gdb) p MEM_ATTRS(*y)
$28
--- Comment #23 from steven at gcc dot gnu dot org 2009-04-05 12:38 ---
Could it be that this is now fixed by the a-i-b merge?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2009-04-05 17:40 ---
Bug is not in an FSF-GCC supported port.
Does the problem reproduce on supported targets? Otherwise this bug should be
closed as INVALID.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from steven at gcc dot gnu dot org 2009-04-04 11:53 ---
Re. comment #10: And who are you funding, Martin Guy, to improve GCC for ARM?
Or are you just another user who expects magic for free?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501
--- Comment #13 from steven at gcc dot gnu dot org 2009-04-04 12:00 ---
Re. comment #10: I don't know about the buggier and slower parts.
But for bigger I know we have benchmarks that say otherwise. e.g. CSiBE for
arm-elf (http://www.inf.u-szeged.hu/csibe/s-arm.php) and CSiBE for arm
--- Comment #3 from steven at gcc dot gnu dot org 2009-04-04 17:30 ---
I'm not sure how the -march=native option changes codegen behavior, but the
most likely suspect is the vectorizer. Do things pass with -march=native if
you don't vectorize (needs explicit -ftree-vectorize
--- Comment #10 from steven at gcc dot gnu dot org 2009-04-04 18:41 ---
*sigh* I wanted to say in comment #3 that you need explitit
-f*no*-tree-vectorize and got it wrong :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39573
--- Comment #1 from steven at gcc dot gnu dot org 2009-04-03 16:43 ---
This feature requires a substantial re-work of symbol handling in gfortran
(make it block based).
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2009-03-29 22:36 ---
Created an attachment (id=17557)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17557action=view)
Always create a new BIND_EXPR for VLA decls
I tried to make use of scopes: If a label is defined in a parent
--- Comment #4 from steven at gcc dot gnu dot org 2009-03-29 22:38 ---
Jakub, this is what we discussed last night.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2009-03-28 23:32 ---
*NetBSD* seems to be using jemalloc, i.e. jemalloc is your system's malloc()
and it is the same as FreeBSD where the test case *does* work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39571
--- Comment #1 from steven at gcc dot gnu dot org 2009-03-28 00:51 ---
Which version of GMP are you using?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #9 from steven at gcc dot gnu dot org 2009-03-22 09:38 ---
I wonder if toplevel bootstrap fixed this issue...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from steven at gcc dot gnu dot org 2009-03-22 09:43 ---
No progress for *years* now. Was bug 14354 the same issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12955
--- Comment #22 from steven at gcc dot gnu dot org 2009-03-22 09:51 ---
Fixed in GCC 4.4 with -frecord-gcc-switches
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2009-03-22 09:59 ---
Long time in WAITING state, and per comment #4 - FIXED.
If the problem resurfaced at the toplevel, a new report should be opened for
this.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from steven at gcc dot gnu dot org 2009-03-22 10:01 ---
fastjar is gone. The rest still has AM_MAKEFLAGS.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|other |rtl-optimization
601 - 700 of 3017 matches
Mail list logo
