https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90977
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449
--- Comment #6 from Segher Boessenkool ---
[ Whoops, hit enter. ]
We need to have a C type for decimal integer before we can use that at all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449
--- Comment #5 from Segher Boessenkool ---
bcdadd works with decimal *integers*; _Decimal128 is decimal *float*.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93448
--- Comment #5 from Segher Boessenkool ---
Great :-)
We still should have builtins for this, of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91116
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #1 from Segher Boessenkool ---
*** Bug 90968 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90968
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90968
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc-*-*-* |powerpc*-*-*
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93448
--- Comment #3 from Segher Boessenkool ---
So you just use "d", like in
void g(_Decimal128 x) { asm("# %0" :: "d"(x)); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93448
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #14 from Segher Boessenkool ---
We can use the r10-1234 names in exactly the places we use r123456 before.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177
--- Comment #13 from Segher Boessenkool ---
You cannot use that from intrinsics. But the target code can do similar of
course, whether or not asm syntax for this exists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93012
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93127
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc-*-*-* |powerpc*-*-*
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93123
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc-*-*-* |powerpc*-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
--- Comment #7 from Segher Boessenkool ---
Why? Is there any advantage to that? The probability of having a collision
anywhere in the repo is nihil with ten digits already, and anywhere in the
world ever with twelve. Why do we want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93157
--- Comment #2 from Segher Boessenkool ---
Someone who can test this should send a patch, and Cc: the Musl OS port
maintainer
(is there one? There should be!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93157
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93176
--- Comment #2 from Segher Boessenkool ---
When you want the bits from bit MB to ME (inclusive) set, you can just do
li t,-1
rldic d,T,MB,63-ME
(bit # 0 is the high bit; can also do wrap-around masks this way).
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177
--- Comment #10 from Segher Boessenkool ---
(In reply to Matt Emmerton from comment #9)
> > > __sync()
> > > __isync()
> > > __lwsync()
> >
> > The sync intrinsics need to be tied to some other code. A volatile asm with
> > a "memory" clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93178
--- Comment #3 from Segher Boessenkool ---
The code at
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/rs6000/rs6000.c;h=fc36bb6714b2a4c922e903e2ebe333c6bdaeefcd;hb=HEAD#l9229
does not treat this case specially, but it should.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93393
--- Comment #5 from Segher Boessenkool ---
It is a backend issue that we cannot solve properly without solving much bigger
generic problems first. See the BoF at last year’s cauldron. Without fixing
that first, doing signaling floats regresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93178
--- Comment #2 from Segher Boessenkool ---
(In reply to Martin Liška from comment #1)
> @Segher: Can you please take a look?
Yes, tomorrow, when I am back from vacation :-)
Confirmed, btw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93172
--- Comment #3 from Segher Boessenkool ---
Why should it be limited that way? simplify_rtx does not / should not care
about peculiarities of a certain architecture or microarchitecture.
A transform like this would be a good idea I think, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93133
--- Comment #5 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #1)
> This happens during combine. If whether the comparison raises exception or
> not is distinguished on aarch64 with CCFPEmode vs. CCFPmode, then guess the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92769
--- Comment #5 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #4)
> >Linux system calls and Linux VDSO calls
>
> System calls, I can understand But why is it required by VDSO calls too?
> That seems backwards and also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177
--- Comment #7 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #5)
> >the cntlz ones are not, for example
>
> :) It has been a long time since I touched this but I would not doubt I
> messed up this too.
It's nastiness in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177
--- Comment #6 from Segher Boessenkool ---
(In reply to Matt Emmerton from comment #4)
> The intrinsics that we would find useful, having used them as provided by
> the IBM XL C/C++ compiler, are the following:
>
> __sync()
> __isync()
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177
--- Comment #3 from Segher Boessenkool ---
Okay, I'll bite.
Which of the functions/macros in ppu_intrinsics.h would you find useful?
Have you checked whether the implementation is good for your purpose, or
if they even are correct (the cntlz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #59 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #58)
> (In reply to Jeffrey A. Law from comment #39)
> > Failed to match this instruction:
> > (set (reg/i:DI 0 x0)
> > (ior:DI (and:DI (reg:DI 95)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93168
--- Comment #1 from Segher Boessenkool ---
The actual control stuff is eaten by bugzilla, but it makes just as little
sense like this. There is an escape before the ] I think, but it messes up
the display (in different and interesting ways
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
For example,
nestfunc-1.c: In function 'f':
nestfunc-1.c:22:1: warning: control reaches end of non-void function
[]8;;https://gcc.gnu.org/onlinedocs/gcc/Warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92086
--- Comment #7 from Segher Boessenkool ---
This is related to the compiler saving the return address for noreturn
sibcalls, like in
void g(void) __attribute__((noreturn));
void f(void) { g(); }
Maybe we should have an option like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93122
--- Comment #3 from Segher Boessenkool ---
Alternatively, we should generate the patterns we have by name, not indirectly
like this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93122
--- Comment #2 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #1)
> Created attachment 47581 [details]
> gcc10-pr93122.patch
>
> Untested fix. With additional -fno-asynchronous-unwind-tables, it doesn't
> ICE, but just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91865
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93047
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93013
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93012
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
||2019-12-19
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #3 from Segher Boessenkool ---
I have code to do this for bfp already, so I'll take it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92656
--- Comment #2 from Segher Boessenkool ---
Trying 104 -> 105:
104: r125:SI=zero_extend(r101:SI#0)
REG_DEAD r101:SI
105: r127:SI={(r100:SI!=0)?r125:SI:r79:SI}
REG_DEAD r125:SI
REG_DEAD r100:SI
REG_DEAD r79:SI
Failed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93011
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |SUSPENDED
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91534
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92769
--- Comment #3 from Segher Boessenkool ---
(In reply to Christophe Leroy from comment #2)
> But CR0 being volatile doesn't prevent GCC to set/clr its SO bit just before
> branching to LR as the ASM functions do, does it ?
Not at all, no. But
|UNCONFIRMED |NEW
Last reconfirmed||2019-12-11
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
||2019-12-11
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Segher Boessenkool ---
CR0 is volatile in all our ABIs, so this is impossible to support from
a C function without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92796
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #24 from Segher Boessenkool ---
(In reply to Daniel Marjamäki from comment #23)
> > If the user expects C to provide tests for "mathematically different", the
> user has some learning to do.
>
> I believe most users can appreciate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #21 from Segher Boessenkool ---
(In reply to Daniel Marjamäki from comment #20)
> Ping. Your "much better" code does not work.
I said that this is much better than an explicit cast. It is. And it behaves
identically.
If the user
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379
--- Comment #5 from Segher Boessenkool ---
It's not top priority; it is fine for stage 4, too. Patches welcome.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92635
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92602
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92602
--- Comment #6 from Segher Boessenkool ---
Author: segher
Date: Thu Nov 28 22:28:59 2019
New Revision: 278821
URL: https://gcc.gnu.org/viewcvs?rev=278821=gcc=rev
Log:
rs6000: Use memory_operand for all simple {l,st}*brx instructions
We run
||2019-11-28
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510
--- Comment #5 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #4)
> Sure, before that we would punt much earlier at simplification of the
> non-sensical subreg.
We probably should again then?
> I don't mind if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
--- Comment #13 from Segher Boessenkool ---
Does that work? You cannot put all hard registers in memory I think?
Or do we require that and it is just not documented?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #18 from Segher Boessenkool ---
(In reply to Vincent Lefèvre from comment #17)
> (In reply to Segher Boessenkool from comment #15)
> > A much better fix is
> >
> > void f1(long s, unsigned long u) { unsigned long su = s; if (su ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #16 from Segher Boessenkool ---
(In reply to Eric Gallager from comment #13)
> > Yes. You should not use casts, except in some very specific cases, and
> > most of the uses you see "in the wild" are a bad idea. Sometimes I wonder
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #15 from Segher Boessenkool ---
(In reply to Daniel Marjamäki from comment #12)
> So, how would you fix the warning for `f`? Many programmers would "fix" it
> with a cast.
>
> Assuming that `s` and `u` can have arbitrary values,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566
--- Comment #9 from Segher Boessenkool ---
Oh, and I think you can drop the
if (!TARGET_ALTIVEC && !TARGET_VSX)
thing? The rest of the code should handle that fine?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #11 from Segher Boessenkool ---
Hi Daniel,
(In reply to Daniel Marjamäki from comment #9)
> Problems;
>
> * Code that performs comparison properly gets a warning.
You get a warning if you compare a signed thing to an unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566
--- Comment #8 from Segher Boessenkool ---
I don't think you need lines 4909..4911.
How can we test this? Is there good test coverage for it already?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #19 from Segher Boessenkool ---
(In reply to Aleksey from comment #16)
> > > It would be helpful if you give the explanation how these options affect
> > > "un-factoring".
> >
> > What options? -fno-reorder-blocks? Those doo the
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
r278509 exposes this problem (the -fno-common patch). It causes global
variables to be accessed via an anchor.
But now fwprop1 does:
In insn 8, replacing
(mem/c:DI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090
Segher Boessenkool changed:
What|Removed |Added
Known to work||10.0
Summary|[10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #15 from Segher Boessenkool ---
(In reply to Aleksey from comment #14)
> Performance is not the case here, so don't bother with it. Strict order of
> labels and using everywhere "jmp reg" instead of "jmp rel + jmp reg" - this
> is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566
--- Comment #5 from Segher Boessenkool ---
The whole function can be something as simple as
mode = mode_for_vector (mode, 16 / GET_MODE_SIZE (mode));
if (this is actually an existing mode
&& !VECTOR_UNIT_NONE (mode))
return mode;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92573
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92573
--- Comment #1 from Segher Boessenkool ---
Author: segher
Date: Wed Nov 20 13:38:52 2019
New Revision: 278497
URL: https://gcc.gnu.org/viewcvs?rev=278497=gcc=rev
Log:
rs6000: Fix UNORDERED without NaNs, for DFP (PR92573)
This is the analogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #13 from Segher Boessenkool ---
(In reply to Aleksey from comment #12)
> But adding these two flags "-fno-reorder-blocks-and-partition
> -fno-reorder-blocks"
If you say that basic blocks should not be reordered, then they
are not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566
--- Comment #3 from Segher Boessenkool ---
It should do something like
if (!VECTOR_UNIT_NONE_P (V2DImode))
return V2DImode;
and similar for all existing entries.
Putting the same conditionals in multiple places is prone to error, as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #8 from Segher Boessenkool ---
int f0(void) { return 0x == -1; }
int f1(unsigned x) { return x == -1; }
int f2(int y) { return 0x == y; }
int f3(unsigned x, int y) { return x == y; }
All of them warn the same, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86160
--- Comment #3 from Segher Boessenkool ---
(In reply to jos...@codesourcery.com from comment #2)
> Generic (for some floating-point formats, and maybe not for 128-bit
> formats on 32-bit targets) bit-pattern is* were implemented by Tamar
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92549
--- Comment #6 from Segher Boessenkool ---
(In reply to Richard Biener from comment #2)
> But it looks like x86 has exactly patterns like this - but in this case
> I guess combine won't ever try this because hardregs are invovled
> (not sure if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92557
--- Comment #7 from Segher Boessenkool ---
I opened PR92566 for that. Thanks!
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
As mentioned in PR92557, at least we shouldn't return V2DImode for the
vector mode for DImode, if we do not actually support that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92557
--- Comment #5 from Segher Boessenkool ---
We always have many modes we cannot put in registers at all. This is normal.
And yeah, what Richard says in c#3. Why do we do that? Is that a target bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86160
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92532
--- Comment #2 from Segher Boessenkool ---
Please fix this soon. I think we still have the 48h rule?
at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
5c2bf77d1f6ae68d830c5157871089711a2a8eee (r278098) causes an ICE when building
the powerpc64 defconfig Linux kernel:
during GIMPLE pass: strlen
/home/segher/src/kernel/drivers/scsi/qla2xxx/qla_gs.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83361
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80938
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491
Segher Boessenkool changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80520
Bug 80520 depends on bug 80491, which changed state.
Bug 80491 Summary: [7 Regression] Compiler regression for long-add case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
Bug 79173 depends on bug 80491, which changed state.
Bug 80491 Summary: [7 Regression] Compiler regression for long-add case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92465
--- Comment #1 from Segher Boessenkool ---
-funroll-loops no longer implies -fweb and -frename-registers, for powerpc,
since those options hurt performance and never seem to help.
The testcase can be fixed by simply explicitly passing -fweb?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92449
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92449
--- Comment #7 from Segher Boessenkool ---
Author: segher
Date: Tue Nov 12 21:05:24 2019
New Revision: 278104
URL: https://gcc.gnu.org/viewcvs?rev=278104=gcc=rev
Log:
testsuite: Add testcases for PR92449
PR target/92449
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92464
--- Comment #2 from Segher Boessenkool ---
What is the testcase testing? Whether we can properly vectorize this
code, right? And for p7 we now do it correctly, but thought it was
too expensive before?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92449
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92449
--- Comment #3 from Segher Boessenkool ---
The first testcase has (at expand time)
if (_13 unord _14)
which doesn't mean anything with -ffast-math (-Ofast): unordered does
not *exist*.
The second testcase is similar, but we generate that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92433
--- Comment #5 from Segher Boessenkool ---
if (y)
{
gcc_assert (n == 3);
std::swap (arg_type[1], arg_type[2]);
}
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #31 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #29)
> Does it help the i386 port if we disallow a hard reg dest as well?
> RA should be able to handle that just fine as well.
I tried this out, and it
1101 - 1200 of 3161 matches
Mail list logo
