--- Comment #39 from bonzini at gnu dot org 2007-08-06 08:08 ---
committed??
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
--- Comment #10 from bonzini at gnu dot org 2007-07-20 15:47 ---
Andrew, could you make a C testcase maybe?...
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from bonzini at gnu dot org 2007-07-11 19:49 ---
First, I'm not a reload expert. :-) But it does not look like a reload bug (or
at least it is easily worked around in the machine description, methinks).
regmove should have changed that but it does not probably because
--- Comment #32 from bonzini at gnu dot org 2007-07-09 15:38 ---
additional fix committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status
--- Comment #15 from bonzini at gnu dot org 2007-07-09 16:31 ---
Note that this:
Before the dataflow merge, the argument pointer was always included
in Registers live at start.
... was because uninitialized registers always showed up as live at start
before DF merge.
--
http
--- Comment #16 from bonzini at gnu dot org 2007-07-09 21:04 ---
Looking out of the box, why can't we add it always, the same as we do with the
frame and stack pointer?? I wonder if the fixed/variable thing is a red
herring.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
--- Comment #23 from bonzini at gnu dot org 2007-07-06 12:08 ---
In particular, this one could be rewritten to
inline void g(int b)
{
register int reg = 0;
asm volatile (nop : +a(reg), +r(b));
}
void f(int a)
{
a /= 1000;
g(a);
}
but the one in PR21291 could not.
--
http
--- Comment #24 from bonzini at gnu dot org 2007-07-06 12:18 ---
Also, the testcase from comment #21 is not a regression: if we do the inlining
manually, it fails in 3.3 too. The failing testcase is:
void f(int a)
{
register int reg asm (eax) = 0;
a /= 1000;
asm volatile (nop
Status: UNCONFIRMED
Keywords: ra
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #27 from bonzini at gnu dot org 2007-07-06 15:13 ---
fixed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|NEW
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #7 from bonzini at gnu dot org 2007-07-05 10:27 ---
Using s,g,g, or s,^,, or even b as the default sed command doesn't seem
to bad to me.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #13 from bonzini at gnu dot org 2007-07-05 10:36 ---
Can we mark it as WONTFIX for 4.0 to 4.2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
--- Comment #11 from bonzini at gnu dot org 2007-07-05 11:13 ---
Actually any no-op command would do, I think even b would be ok unless it
triggers other bugs. In particular, replacing one g with a g, or all g's with
g's, should not matter. :-)
--
http://gcc.gnu.org/bugzilla
--- Comment #8 from bonzini at gnu dot org 2007-07-05 20:03 ---
Subject: Re: BOOT_CFLAGS is not passed to stage2 and stage3
compile
Sebastian Pop wrote:
Hi,
here is a fix for PR32622 that I've bootstrapped and tested on
i686-linux with configure BOOT_CFLAGS=-O2 that made
--- Comment #22 from bonzini at gnu dot org 2007-07-05 20:11 ---
The patch does not fix this one, which also works in 3.3 and fails in 4.1. I'm
not sure it's 100% the same bug. Still, I committed the patch to fix the
testcase from PR21291.
--
http://gcc.gnu.org/bugzilla
--- Comment #17 from bonzini at gnu dot org 2007-07-04 07:11 ---
I'm working on this, but don't hold your breath (hence not assigning to
myself).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
--- Comment #5 from bonzini at gnu dot org 2007-07-04 07:12 ---
*** This bug has been marked as a duplicate of 32004 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #18 from bonzini at gnu dot org 2007-07-04 07:12 ---
*** Bug 25216 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #7 from bonzini at gnu dot org 2007-07-04 07:13 ---
PR25216 is a dup of PR32004.
--
bonzini at gnu dot org changed:
What|Removed |Added
BugsThisDependsOn
--- Comment #19 from bonzini at gnu dot org 2007-07-04 08:16 ---
Created an attachment (id=13843)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13843action=view)
patch under testing
QED (Quite Easily Done :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
--- Comment #20 from bonzini at gnu dot org 2007-07-04 13:54 ---
The attached patch makes PR30311 resurface; this seems like a minor problem
because that code is dubious, and can be worked around by not doing the
transformation when the modes mismatch.
--
http://gcc.gnu.org
--- Comment #17 from bonzini at gnu dot org 2007-06-29 19:25 ---
And that's why I left it assigned to me. I'll work on it next week.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
--- Comment #3 from bonzini at gnu dot org 2007-06-29 19:26 ---
CCing Honza, he had a patch for this bug.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #14 from bonzini at gnu dot org 2007-06-25 07:01 ---
wrong bug marked as duplicate... reopening...
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #6 from bonzini at gnu dot org 2007-06-25 07:02 ---
*** This bug has been marked as a duplicate of 30563 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #15 from bonzini at gnu dot org 2007-06-25 07:02 ---
*** Bug 30537 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #16 from bonzini at gnu dot org 2007-06-25 07:03 ---
... to close as fixed
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|REOPENED
--- Comment #10 from bonzini at gnu dot org 2007-06-20 11:13 ---
DJ, do you think this patch is ok?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #6 from bonzini at gnu dot org 2007-06-11 06:54 ---
can you please show the difference in assembly code between the two?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #2 from bonzini at gnu dot org 2007-05-31 06:06 ---
I'm not sure we actually want to build libgcc stage1 optimized. But yes,
fixing 32009 will provide a way to fix this.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #5 from bonzini at gnu dot org 2007-05-30 15:57 ---
A bug with the same symptom resurfaced. David, did I understand right that
this time the problem is the huge environment passed from the toplevel
makefile?
--
bonzini at gnu dot org changed:
What
--- Comment #8 from bonzini at gnu dot org 2007-05-23 15:24 ---
I have a Mac so I can fix this, but I'm not sure on the timing. I'm commenting
out the BOOT_CFLAGS setting for a moment to unbreak bootstrap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
--- Comment #6 from bonzini at gnu dot org 2007-05-22 10:33 ---
Please try this patch on top of the previous one. Its purpose is just to
validate the logic of the previous one, it's not meant to be committed.
Index: libgcc/configure.ac
--- Comment #1 from bonzini at gnu dot org 2007-05-21 08:19 ---
I know what's going on :-)
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #2 from bonzini at gnu dot org 2007-05-21 08:21 ---
Created an attachment (id=13593)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13593action=view)
tentative patch?
Please test this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
--- Comment #11 from bonzini at gnu dot org 2007-05-21 08:48 ---
Micha, do you mean transforming (while expanding to RTL)
asm (: =mr (inout_2) : 0 (inout_1));
to
inout_2 = inout_1;
asm (: =mr (inout_2) : 0 (inout_2));
?
That shouldn't be too hard.
--
http://gcc.gnu.org
--- Comment #13 from bonzini at gnu dot org 2007-05-21 09:32 ---
So we'd just be replacing a weak workaround with a stronger (but not
definitive) workaround. :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
--- Comment #11 from bonzini at gnu dot org 2007-05-13 09:20 ---
I confirm the compile-time improvements from the complete patch (2%
enable-checking, 0.8% disable-checking), but there's no improvement in SPEC (no
regression either).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #8 from bonzini at gnu dot org 2007-05-11 07:19 ---
I started bootstrap and SPEC2000 on i686-pc-linux-gnu, I'll post the result
tomorrow hopefully (if the weekend swamps me it I might delay that). :-(
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #5 from bonzini at gnu dot org 2007-04-16 20:10 ---
What about a patch like this?
Index: macro.c
===
--- macro.c (revision 123691)
+++ macro.c (working copy)
@@ -499,9 +499,15 @@ paste_all_tokens
--- Comment #2 from bonzini at gnu dot org 2007-04-16 20:11 ---
Created an attachment (id=13372)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13372action=view)
patch to fix part of the bug
This patch seems to fix the preprocessor side of the bug. However there are
problems later
--- Comment #3 from bonzini at gnu dot org 2007-04-16 20:24 ---
Created an attachment (id=13373)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13373action=view)
patch to fix part of the bug
By fixing the preprocessor part better, we can fix the bug completely.
However, I don't
--- Comment #13 from bonzini at gnu dot org 2007-04-05 11:01 ---
So this is an unstable sorting. Adding dnovillo.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #15 from bonzini at gnu dot org 2007-04-05 13:03 ---
Transformations do not, but out-of-SSA could. Is there a way to ensure
ordering of PHI functions unlike what Uros's dumps suggest?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
--- Comment #8 from bonzini at gnu dot org 2007-04-03 12:43 ---
what's the generated code for -ffast-math? in principle i don't see a reason
why it should make any difference...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
--- Comment #5 from bonzini at gnu dot org 2007-04-03 13:31 ---
well, for sure it would be possible to use df and a good example of that too.
But I'm not *that* knowledgeable about the df-*.c implementation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
--- Comment #6 from bonzini at gnu dot org 2007-04-03 13:33 ---
anyway, the code looks well written. the dataflow_set_* functions look
inefficient, though. maybe it's also possible to replace hash tables with
pointer maps (there is a 1:1 relationships between decl nodes
--- Comment #10 from bonzini at gnu dot org 2007-04-03 13:36 ---
I would look at the lreg output, which contains the results of regclass.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19780
--- Comment #8 from bonzini at gnu dot org 2007-04-03 13:38 ---
I wouldn't say so. If there is a bug and the df solver oscillates, that's the
reason for the infinite loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
--- Comment #94 from bonzini at gnu dot org 2007-04-02 16:20 ---
I think that Uros' patch to add a -mpc switch for precision control would fix
this.
The real fix would be to automatically insert fldcw instructions before
float/double operations, in order to limit the precision
--- Comment #7 from bonzini at gnu dot org 2007-04-02 16:21 ---
Reopened...
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #8 from bonzini at gnu dot org 2007-04-02 16:22 ---
... because GCC now has -mpc to limit precision for float/double operations.
Even as far as x86 is concerned, this is a special case of PR323, and thus
I'm closing it as fixed.
--
bonzini at gnu dot org changed
--- Comment #3 from bonzini at gnu dot org 2007-03-30 08:23 ---
still occurs at -O2 (testing with checking disabled).
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #62 from bonzini at gnu dot org 2007-03-26 16:50 ---
dataflow branch cannot complete this at -O3 -fno-tree-pre -fno-tree-fre
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #5 from bonzini at gnu dot org 2007-03-20 08:31 ---
fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30841
--- Comment #6 from bonzini at gnu dot org 2007-03-20 08:32 ---
patch committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from bonzini at gnu dot org 2007-03-16 11:18 ---
the patch was not responsible for the regressions, and it regtested ok if i
paper over the bug in stevenb's patch. so i committed it.
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #1 from bonzini at gnu dot org 2007-03-15 17:03 ---
Created an attachment (id=13211)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13211action=view)
patch that fixes the bug, untested
REG_N_CALLS_CROSSED is computed using live, not urec. caller_save uses
it to decide
--- Comment #9 from bonzini at gnu dot org 2007-03-09 08:44 ---
Zdenek, any chance that your aliasing oracle can be used to fix these?
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #10 from bonzini at gnu dot org 2007-03-07 08:22 ---
Unfortunately, if I fix the fwprop bug (which is actually caused by wrong df
information), I get again
leal-4(%edi), %eax
movl%eax, %edi
movl(%eax), %eax
testl %eax, %eax
--- Comment #5 from bonzini at gnu dot org 2007-03-05 09:17 ---
On 4.3, it is still there at -O1
--
bonzini at gnu dot org changed:
What|Removed |Added
Known
--
bonzini at gnu dot org changed:
What|Removed |Added
CC||bonzini at gnu dot org
Status|UNCONFIRMED |NEW
: bonzini at gnu dot org
GCC target triplet: i686-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31025
--- Comment #10 from bonzini at gnu dot org 2007-02-23 14:30 ---
No, i (which is in %edx) *is* being incremented. It's the strength-reduced
derived induction variable that is constructed in a wrong way. The optimized
code looks like:
void bug (struct s *p)
{
int i;
struct s *pp
--- Comment #11 from bonzini at gnu dot org 2007-02-23 14:32 ---
for (i=0; i 2; i++)
Well, that's obviously
for (i=0; i 2; )
in my code of comment #10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30931
--- Comment #1 from bonzini at gnu dot org 2007-02-22 08:27 ---
It's actually a small oversight in fwprop, which is supposed to replace
find_best_addr indeed.
The patch indicated in the URL is enough for dataflow-branch; on mainline you
need also http://gcc.gnu.org/ml/gcc-patches/2007
--- Comment #7 from bonzini at gnu dot org 2007-02-22 08:41 ---
Now that the patch has been applied to dataflow branch, this remains as a
missed optimization on the tree level.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from bonzini at gnu dot org 2007-02-22 10:20 ---
This will also appear in mainline when the patch for PR30841 is applied
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30907
--- Comment #2 from bonzini at gnu dot org 2007-02-22 16:46 ---
Changing the patch address since part 1 was approved. And adding bug 30907
since committing part 2 would cause that bug to surface on mainline.
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #4 from bonzini at gnu dot org 2007-02-22 16:48 ---
Though we don't have a testcase for mainline, the bug is there too.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #2 from bonzini at gnu dot org 2007-02-21 16:01 ---
fwprop has some tricks to avoid propagating within loops before unrolling. The
interesting point is why they trigger differently in mainline vs. dataflow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30907
--- Comment #3 from bonzini at gnu dot org 2007-02-21 16:03 ---
This unrelated patch fixes a very similar case for powerpc
unpatched:
or r0,r3,r28
rlwinm r0,r0,0,0xff
cmpwi cr7,r0,0
beq- cr7,L4929
patched: (r3 and r28 are both extended from QImode
--- Comment #4 from bonzini at gnu dot org 2007-02-21 16:05 ---
It doesn't, but I confirm that the bug is target independent. A way to fix it
would be to do the transform in VRP, but I'll look at combine if time permits.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30904
--- Comment #5 from bonzini at gnu dot org 2007-02-21 16:11 ---
The first one is in the same EBB as the assignment. The second one isn't and
combine screws up. This is because of the way combine treats regs with one def
that dominates all uses, I talked to zadeck yesterday about
--- Comment #6 from bonzini at gnu dot org 2007-02-21 16:23 ---
Created an attachment (id=13083)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13083action=view)
patch to fix the bug
The logic in trunk's combine with respect to uninitialized variables is
correct.
We have to look
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org
--- Comment #10 from bonzini at gnu dot org 2007-02-16 09:14 ---
committed to all active branches.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #30 from bonzini at gnu dot org 2007-02-06 08:37 ---
Created an attachment (id=13011)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13011action=view)
proposed, untested patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
--- Comment #34 from bonzini at gnu dot org 2007-02-06 10:41 ---
The two bits were actually the same, since passes.c was doing this exactly
after calling set_nothrow_function_flags
if (current_function_nothrow)
/* Now we know that this can't throw; set the flag for the benefit
--- Comment #22 from bonzini at gnu dot org 2007-02-05 09:22 ---
If you refer to http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00559.html this
little patch would undo any semantic changes introduced there. I didn't follow
the discussion however and I don't know if this is the correct
--- Comment #2 from bonzini at gnu dot org 2007-02-02 15:35 ---
Adding Eric to the CC list, he probably knows what's going on for Solaris.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2007-02-02 16:35 ---
Thanks. Should we close the bug? Is there anything to update in the
documentation?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27843
--- Comment #9 from bonzini at gnu dot org 2007-01-23 13:17 ---
Can you attach a working patch for 4.1 (for all three of GNATBIND, GNATLINK,
GNATMAKE; I prefer to err on the safe side)? Then of course we'll update it
and apply it to 4.3 first, but at least I can understand better what
--- Comment #11 from bonzini at gnu dot org 2007-01-23 14:09 ---
You're right. gnattools is only built at the end of the bootstrap.
I'd prefer a slightly more conservative patch; I don't want to fix things later
if we know that the tools are needed somewhen during the build.
So
--- Comment #1 from bonzini at gnu dot org 2007-01-23 14:23 ---
Is this really a bug, or just an enhancement?
As far as I know, it's been like this forever (even when you used to make
gnat_lib_and_tools after make bootstrap).
--
bonzini at gnu dot org changed:
What
--- Comment #4 from bonzini at gnu dot org 2007-01-23 16:02 ---
Is the file placed in srcdir? If not, it's *right* to generate the file on
every stage.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30556
--- Comment #5 from bonzini at gnu dot org 2007-01-22 16:48 ---
During the build we still call (and require) a 'gnatmake' in $PATH like for
(cd ada/bldtools/nmake_b; gnatmake -q xnmake ; ./xnmake -b ../../nmake.adb )
but at least gnatbind is used as specified at configure time
--- Comment #7 from bonzini at gnu dot org 2007-01-22 17:37 ---
However, fixing GNATBIND/GNATLINK/GNATMAKE would allow you to e.g. install 4.1
in /opt/gcc-4.1/ and then configure with GNATMAKE=/opt/gcc-4.1/bin/gnatmake.
So there is still a point in fixing this bug.
If you start from
--- Comment #5 from bonzini at gnu dot org 2007-01-09 16:08 ---
I'll take a look.
--
bonzini at gnu dot org changed:
What|Removed |Added
CC
--- Comment #4 from bonzini at gnu dot org 2007-01-08 13:32 ---
This code is undefined as the address of a label will never be 128bytes, it
will either be 4 or 8 bytes.
No, that would be
void *p = dummy;
memcpy (foo, p, sizeof (p));
Here, it's copying code from the address
--- Comment #9 from bonzini at gnu dot org 2006-12-29 17:47 ---
committed
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #36 from bonzini at gnu dot org 2006-12-22 12:52 ---
Should be fixed now (by inspection of the reduced test case). Patch committed
is at this URL:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01378.html
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #6 from bonzini at gnu dot org 2006-12-20 12:28 ---
Ok, so we have an agreement on why this is bad.
I've reopened the bug myself and made it block 22372. A fix for 22372 can be
done independent of this PR, but it will be inefficient memory-wise.
--
bonzini at gnu dot
--- Comment #7 from bonzini at gnu dot org 2006-12-20 15:25 ---
To make it clearer, there is a fix for this PR other than
The way to solve this bug could be to pass the two operands to
rs6000_builtin_mul_widen_even, and get back the fully-built tree,
including conversions
--- Comment #4 from bonzini at gnu dot org 2006-12-15 12:05 ---
Seems invalid. Ira, if you have a specific bug (missed optimization, or
whatever) triggered by this, please reopen and change the subject.
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #1 from bonzini at gnu dot org 2006-12-14 17:23 ---
Builtin vmuloub has always returned wrong types, because it derives its types
simply from the modes of the altivec_vmuloub pattern. For this reason, the C
front-end uses vec_vmuloub instead: this one is expanded
--- Comment #17 from bonzini at gnu dot org 2006-12-14 17:41 ---
It was a mess before too. Anyway, you are confusing compatibility with
convertible without added casts.
comptypes needs to recur in order to unbreak Altivec builtins. vector int and
vector bool int for example
--- Comment #3 from bonzini at gnu dot org 2006-12-14 17:46 ---
Don't confuse __builtin_altivec_vmuloub (only used by middle-end, has the
wrong types) with __builtin_vec_vmuloub (cannot be created by middle-end,
lowered by the C front-end to __builtin_altivec_vmuloub after checking
--- Comment #1 from bonzini at gnu dot org 2006-12-06 10:10 ---
You might have to add a post-reload splitter for something like
(set (match_operand:SI 0 register_operand +r)
(plus (match_dup 0)
(lt:SI (match_operand:SF 1 register_operand x
901 - 1000 of 1258 matches
Mail list logo
