--- Comment #7 from bonzini at gnu dot org 2007-12-17 15:48 ---
re. comment #5, like this?
Index: gcc.c
===
--- gcc.c (revision 128902)
+++ gcc.c (working copy)
@@ -4685,6 +4685,8 @@ do_spec_1 (const char *spec
--- Comment #7 from bonzini at gnu dot org 2007-12-18 07:43 ---
The generated code has changed a lot recently, though it still uses two spills:
pushl %esi
pushl %ebx
movl12(%esp), %ebx ; load alow
movl20(%esp), %esi ; load
--- Comment #8 from bonzini at gnu dot org 2007-12-18 07:53 ---
For -mregparm=2 the code is this:
pushl %ebx
movl8(%esp), %ebx
movl12(%esp), %ecx
imull %ebx, %edx
imull %eax, %ecx
addl%edx, %ecx
mull%ebx
--- Comment #9 from bonzini at gnu dot org 2007-12-18 08:05 ---
Uros mentioned offlist that he wanted to hijack fwprop to always propagate
stack slots into instructions.
It would be a relatively useful piece of infrastructure to have a flag in MEMs
that marks on-stack MEMs, because
--- Comment #20 from bonzini at gnu dot org 2007-12-18 08:35 ---
Eric, would you please take a look at my counter-proposal and commit it if it
works?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #12 from bonzini at gnu dot org 2007-12-18 16:01 ---
The problem in comment #11 is that GCC generates a widening multiply, and
cannot remove the DImode operations until after register allocation (!). While
the root cause is a deficiency in RTL-level DCE, I suggest filing a
needed
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot o
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #14 from bonzini at gnu dot org 2007-12-18 16:50 ---
The bug with 64*64->32 multiplication is now PR34522.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
--- Comment #1 from bonzini at gnu dot org 2007-12-18 16:58 ---
Prototype untested patch. Produces
movl12(%esp), %eax
imull 4(%esp), %eax
ret
on the testcase.
Index: expr.c
===
--- expr.c
--- Comment #3 from bonzini at gnu dot org 2007-12-19 09:37 ---
Makes a lot of sense. I made the patch only to test that it would not crash,
or something like that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34522
--- Comment #17 from bonzini at gnu dot org 2007-12-19 09:49 ---
With this patch, GCC gets the preferences right, but it does not affect code
generation.
Index: regclass.c
===
--- regclass.c (revision 130928
--- Comment #19 from bonzini at gnu dot org 2007-12-19 12:13 ---
Created an attachment (id=14792)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14792&action=view)
patch to almost fix the bug
With this patch:
1) local-alloc first tries to allocate registers that go int
--- Comment #21 from bonzini at gnu dot org 2007-12-19 12:43 ---
Created an attachment (id=14793)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14793&action=view)
two hunks only from the previous patch
Indeed, if I only use the regclass.c and local-alloc.c hunks, I get o
--- Comment #20 from bonzini at gnu dot org 2007-12-19 12:32 ---
There is a big catch-22. When GCC ties one of regs 64/66 with reg 61, it
enlarges reg 61's live range to cover the live range of the tied range. When
it does this, it basically locks up %edx for the whole live ran
--- Comment #23 from bonzini at gnu dot org 2007-12-19 13:36 ---
Created an attachment (id=14794)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14794&action=view)
teach combine that reg = op(reg, mem) is better
Since combine operates on the whole pattern, it can be tau
--- Comment #25 from bonzini at gnu dot org 2007-12-19 13:50 ---
Note that "fwprop" is not an exact term, because there *is* a memory load in
each multiplication, and propagating a second memory operand will create an
invalid insn. You may try to add a split from reg=op(mem1
--- Comment #39 from bonzini at gnu dot org 2007-12-19 13:57 ---
Yes, we need a no-checking comparison. And this might be a PR of its own, for
example:
tree PRE : 7.94 (15%) usr 0.10 (32%) sys 8.04 (15%) wall
1687 kB ( 2%) ggc
--
http://gcc.gnu.org/bugzilla
--- Comment #26 from bonzini at gnu dot org 2007-12-19 13:53 ---
I'm starting a SPEC run on the overall patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
--- Comment #27 from bonzini at gnu dot org 2007-12-20 13:53 ---
I screwed up so I have to rerun most of SPECfp2000, but the results seem a
wash. Anybody can fire the patch I'll attach soon on a wide range of machines?
--
Bug 17236 depends on bug 6585, which changed state.
Bug
--- Comment #28 from bonzini at gnu dot org 2007-12-20 14:15 ---
Created an attachment (id=14800)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14800&action=view)
combined patch
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #47 from bonzini at gnu dot org 2008-01-04 11:11 ---
Created an attachment (id=14874)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14874&action=view)
kenny's trimmed rd patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
--- Comment #46 from bonzini at gnu dot org 2008-01-04 11:01 ---
on a non-checking compiler:
4.11.8s
on a checking compiler:
unpatched 21s
hybrid search, no pruning 3.6s
hybrid search, LIVE pruning3.5s
hybrid
--- Comment #10 from bonzini at gnu dot org 2008-01-12 16:52 ---
an alternative is to prepare a suppression file for valgrind, and distribute it
with gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
--- Comment #12 from bonzini at gnu dot org 2008-01-12 21:09 ---
well if you can enjoy O(n) initialization (and O(1) clearing as in Peter's
code), you had better rewrite the code completely to query an item with one
(not two) memory accesses.
--
http://gcc.gnu.org/bug
--- Comment #15 from bonzini at gnu dot org 2008-01-13 12:02 ---
Considering that we allocate exactly 1 sparseset per function, it cannot change
the performance in any way to initialize the memory, so maybe we do want to go
for that. But it is just stupid IMHO if the beauty of the data
--- Comment #6 from bonzini at gnu dot org 2008-04-15 12:26 ---
The point of -fsplit-wide-types was to kill patterns like iorsi3 in AVR
backend.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2008-04-17 13:01 ---
I wonder is PR34824 should be reverted then?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #7 from bonzini at gnu dot org 2008-04-18 10:12 ---
I have a patch, it will take a short while before I commit it because I have to
regenerate all the configures.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35457
--- Comment #10 from bonzini at gnu dot org 2008-04-18 11:35 ---
*not* fixed until newlib configures are regenerated
(see the end of http://snipurl.com/24vbq [sourceware.org])
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35457
--- Comment #41 from bonzini at gnu dot org 2008-04-21 13:53 ---
Ralf, do you think it would be possible to create the script atomically in
ltmain.sh?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
--- Comment #43 from bonzini at gnu dot org 2008-04-21 14:07 ---
Yes, but your patch is, even if not wrong, unsatisfactory. Even though only
one program suffers from this bug now, it is in general a problem that libtool
invokes some of the tools that are being built, and I want to fix
--- Comment #46 from bonzini at gnu dot org 2008-04-21 14:38 ---
Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils
source tree doesn't bootstrap with --enable-shared
> But this is a very unique relink and linker problem. It can only happen
> to linker. Why ma
--- Comment #47 from bonzini at gnu dot org 2008-04-21 14:39 ---
Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils
source tree doesn't bootstrap with --enable-shared
> It is probably possible to generate the wrapper script atomically.
> But this solution can beco
--- Comment #49 from bonzini at gnu dot org 2008-04-21 16:05 ---
Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils
source tree doesn't bootstrap with --enable-shared
> I don't think it is a problem since this problem is limited to that the
> new linker i
--- Comment #51 from bonzini at gnu dot org 2008-04-21 16:25 ---
Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils
source tree doesn't bootstrap with --enable-shared
> 3. as calls ld to relink itself.
>3.1 ld calls the previous linker to relink itself to c
--- Comment #53 from bonzini at gnu dot org 2008-04-21 17:02 ---
Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils
source tree doesn't bootstrap with --enable-shared
> I can extend my patch to as.
You surely can (and actually extend it to everything else that is
--- Comment #55 from bonzini at gnu dot org 2008-04-22 06:27 ---
Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils
source tree doesn't bootstrap with --enable-shared
>> (BTW, were you libtool maintainers aware of this race/these races?)
>
> I wasn't.
--- Comment #1 from bonzini at gnu dot org 2008-04-25 15:21 ---
*** This bug has been marked as a duplicate of 35752 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #58 from bonzini at gnu dot org 2008-04-25 15:21 ---
*** Bug 33503 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #17 from bonzini at gnu dot org 2008-05-02 16:29 ---
I wonder if your patch would be a problem because it sometimes removes a CONST
wrapping. It could also be possible to precede the CONST_INT optimization with
another test for two adjacent CONSTANT_P:
if (GET_CODE (ops
--- Comment #19 from bonzini at gnu dot org 2008-05-02 21:08 ---
Subject: Re: [4.3/4.4 Regression] ppc64 cacoshl miscompilation
> Yes, the patch works, modulo typos.
It was not tested indeed.
> Does it make sense to group any two RTX_CONST_OBJ together of not the same
>
--- Comment #21 from bonzini at gnu dot org 2008-05-03 07:13 ---
Subject: Re: [4.3/4.4 Regression] ppc64 cacoshl miscompilation
> How do we proceed? Your initial patch is fine with me.
Whose? I can foster-parent yours too, and bootstrap/regtest it on
i686-pc-linux-gnu.
Pa
--- Comment #23 from bonzini at gnu dot org 2008-05-03 13:25 ---
Subject: Re: [4.3/4.4 Regression] ppc64 cacoshl miscompilation
dje at gcc dot gnu dot org wrote:
> --- Comment #22 from dje at gcc dot gnu dot org 2008-05-03 13:21 ---
> Your patch from comment #17 (with
--- Comment #25 from bonzini at gnu dot org 2008-05-03 15:47 ---
Subject: Re: [4.3/4.4 Regression] ppc64 cacoshl miscompilation
dje at gcc dot gnu dot org wrote:
> --- Comment #24 from dje at gcc dot gnu dot org 2008-05-03 14:20 ---
> I am testing with the patch. I wan
--- Comment #2 from bonzini at gnu dot org 2008-05-09 05:04 ---
unfortunately my current gcc time is ~0, which is why dje actually tested and
committed the patch for me, but sorry for causing these regressions anyway.
for cris, i believe the correct fix is to strengthen the check and
--- Comment #3 from bonzini at gnu dot org 2008-05-09 05:05 ---
i'll post a temptative patch for the cris issue if i get to it during the
commute.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182
--- Comment #4 from bonzini at gnu dot org 2008-05-09 05:05 ---
ahem, tentative
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182
--- Comment #9 from bonzini at gnu dot org 2008-05-09 11:32 ---
You know I'm still not sure if I can review patches outside df* (i.e. files
that do what flow.c did, but are not dataflow related), but if you think I
can... then patch is ok. :-)
--
http://gcc.gnu.org/bug
--- Comment #5 from bonzini at gnu dot org 2008-05-09 13:36 ---
Created an attachment (id=15620)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15620&action=view)
patch for cris problem
This patch should fix the CRIS problem. However, we should also check that it
does n
--- Comment #6 from bonzini at gnu dot org 2008-05-09 13:37 ---
Richard (Sandiford), could you look at the patch? You are the varasm.c expert.
:-)
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #7 from bonzini at gnu dot org 2008-05-09 13:37 ---
not wrong-code, it fails to assemble.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #33 from bonzini at gnu dot org 2008-05-09 15:51 ---
I now think that fixing it in the target is better.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #9 from bonzini at gnu dot org 2008-05-09 16:03 ---
I'll revert my patch on Monday even if no alternative solution for PR36090 is
found during the weekend. It opened too big cans of worms for a release
branch, even though it fixed a serious regression.
--
--- Comment #35 from bonzini at gnu dot org 2008-05-12 15:50 ---
so you prefer to leave my fix (possibly amended in 4.4+)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #2 from bonzini at gnu dot org 2008-05-12 16:27 ---
thanks, fixed!
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #37 from bonzini at gnu dot org 2008-05-12 16:48 ---
Ok, I started a bootstrap of the obvious patch on i686-pc-linux-gnu. But I
think the obvious patch is not enough if we go this way. The comments in
simplify_plus_minus are already not up-to-date, and removing CONST is
--- Comment #39 from bonzini at gnu dot org 2008-05-12 16:54 ---
Ah, only on 4.3 branch. Ok, I'll go on from here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
--- Comment #2 from bonzini at gnu dot org 2008-05-29 13:31 ---
looks like a loop with 5000 basic blocks...
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #12 from bonzini at gnu dot org 2008-05-31 07:25 ---
*** Bug 36398 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from bonzini at gnu dot org 2008-05-31 07:25 ---
I think this was expected, the test should probably be XFAILed.
*** This bug has been marked as a duplicate of 19020 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from bonzini at gnu dot org 2008-05-31 09:18 ---
Well, regression is a big word because -ftrapv is broken in general. I guess
the RM will lower the priority.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #17 from bonzini at gnu dot org 2008-07-10 14:05 ---
changing subject then, thanks for the analysis!
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from bonzini at gnu dot org 2008-07-11 11:56 ---
Yes, the code produced shows that something (probably fwprop, I trust Andrew
though I'd like to see dumps) is turning the GIMPLE code
temp = a[0];
a[1] = temp;
temp++;
into something harder to optimize. It mig
--- Comment #7 from bonzini at gnu dot org 2008-07-11 11:58 ---
> Wonder why nothing in fwprop.c checks modified_between_p
There is code similar to modified_between_p in fwprop.c, that uses def info
from the dataflow pass. Part of the fwprop work was to try using the df-scan.c
i
--- Comment #6 from bonzini at gnu dot org 2008-07-14 16:03 ---
any news? also, P1 is probably wrong (resetting to P3).
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #18 from bonzini at gnu dot org 2008-07-14 16:07 ---
The two commits listed here fix the regression, they should be safe to backport
to 4.3.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35281
--- Comment #8 from bonzini at gnu dot org 2008-07-14 16:18 ---
mine
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Comment #9 from bonzini at gnu dot org 2008-07-14 16:29 ---
In fact, using modified_between_p would not fix the bug. The problem is that
use_killed_between gives the wrong answer *before* it reaches the code that
"redoes" modified_between_p using df data structures.
I&
--- Comment #11 from bonzini at gnu dot org 2008-07-17 09:19 ---
committed to trunk and 4.3.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status
--- Comment #19 from bonzini at gnu dot org 2008-07-18 11:45 ---
bootstrapped/regtested on 4.3 branch, committed there too
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2008-07-18 13:41 ---
auto-inc-dec should be taught about transforming
a <- b + c
...
*(b + c)
into
a <- b
...
*(a += c) pre
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #5 from bonzini at gnu dot org 2008-07-18 14:13 ---
Hmm, even that wouldn't restore the optimization. The problem here is that
there is another access via b, like
a <- b + c
*b
*(b + c)
The bad placement of the first assignment (bad because doing it the o
--- Comment #4 from bonzini at gnu dot org 2008-07-22 15:48 ---
i had a patch to expand pow at the tree level, but it conflicted with fold
(which consistently tried to rebuild pow function calls). the outcome might be
better now that we have PAREN_EXPR, though.
--
bonzini at gnu
--- Comment #21 from bonzini at gnu dot org 2008-07-30 13:10 ---
Yes, I already moved the relevant entry to gnattools/ChangeLog.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5911
--- Comment #6 from bonzini at gnu dot org 2008-07-30 13:12 ---
reopened just because it is not a dup of PR5911...
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #7 from bonzini at gnu dot org 2008-07-30 13:12 ---
... and closed because it was fixed by the introduction of libaad
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #59 from bonzini at gnu dot org 2008-07-31 12:44 ---
Should be fixed by the patch at
http://permalink.gmane.org/gmane.comp.gnu.libtool.patches/8574
which is waiting to be applied upstream.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
--- Comment #9 from bonzini at gnu dot org 2008-07-31 12:58 ---
Michael, any news?
--
bonzini at gnu dot org changed:
What|Removed |Added
CC
--- Comment #60 from bonzini at gnu dot org 2008-08-01 08:26 ---
There is no need for additional patches: a trunk bootstrap is now building gcc
stage2, so it's fixed there. I'll backport to 4.3 the patch from comment #36.
--
bonzini at gnu dot org changed:
--- Comment #2 from bonzini at gnu dot org 2008-08-01 08:44 ---
not really a duplicate
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|RESOLVED
ormal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36995
--- Comment #8 from bonzini at gnu dot org 2008-08-01 09:54 ---
backported
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #62 from bonzini at gnu dot org 2008-08-04 12:24 ---
committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from bonzini at gnu dot org 2006-01-23 08:14 ---
The ICE is the same, but the cause is probably different as 25890 is an
ICE-on-undefined.
I think it's easiest to punt and return failure instead of asserting, but I
want to investigate how we reach the assertion fa
--- Comment #3 from bonzini at gnu dot org 2006-01-23 08:16 ---
The bug here is that expand_compound_operation uses an unsigned HOST_WIDE_INT
for pos, while the argument to the "zero_extract" rtx's is a const_int, which
is signed. A negative value for zero_extract's
--- Comment #5 from bonzini at gnu dot org 2006-01-23 08:22 ---
I cannot reproduce Paul's testcase, but I found this one:
struct object
{
unsigned long mixed_encoding:1;
unsigned long encoding:8;
}
__attribute__ ((packed));
int search_object (struct object *ob)
{
r
--- Comment #6 from bonzini at gnu dot org 2006-01-23 08:28 ---
Uhm, expand has a bug and creates an invalid
(insn 11 7 12 2 (set (subreg:SI (reg:QI 33) 0)
(zero_extract:SI (mem/s:QI (reg/v/f:SI 31 [ ob ]) [0 S1 A8])
(const_int 8 [0x8])
(const_int 1 [0x1
--- Comment #2 from bonzini at gnu dot org 2006-01-23 08:59 ---
I am not so sure that it is a duplicate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25919
--- Comment #3 from bonzini at gnu dot org 2006-01-23 09:59 ---
Reopening...
--
bonzini at gnu dot org changed:
What|Removed |Added
Last reconfirmed|-00-00 00:00
--- Comment #4 from bonzini at gnu dot org 2006-01-23 10:00 ---
Reopening for real...
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #5 from bonzini at gnu dot org 2006-01-23 10:01 ---
... to mark as duplicate for the 20051228-1.c failure.
*** This bug has been marked as a duplicate of 25890 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2006-01-23 10:01 ---
*** Bug 25919 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org
--- Comment #2 from bonzini at gnu dot org 2006-01-23 15:41 ---
This is nasty. I think that the easiest codes to remove are PARM_DECL and
RESULT_DECL.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25886
--- Comment #9 from bonzini at gnu dot org 2006-01-23 17:06 ---
That's not the correct fix. Every user of bsi_after_labels does a
bsi_insert_after, and that inserts after the first executable statement (rather
than before) if there is no label in the basic block.
--
--- Comment #8 from bonzini at gnu dot org 2006-01-24 14:30 ---
Patch committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from bonzini at gnu dot org 2006-01-24 14:30 ---
Patch committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from bonzini at gnu dot org 2006-01-24 14:35 ---
AM_MAINTAINER_MODE is missing.
I thought people did cut'n'paste to generate a new configure.ac, but this must
not be the case. ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25942
--- Comment #4 from bonzini at gnu dot org 2006-02-06 14:06 ---
More precisely, combine is attempting to do instruction selection, and in the
case of this bug it cannot.
A similar ARM test case is
int f (int a, int b)
{
int s = a - b;
int t = a < b ? a : s;
x
1101 - 1200 of 1283 matches
Mail list logo
