https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110717
--- Comment #13 from Segher Boessenkool ---
So. Before expand we have
_6 = (__int128) x_3(D);
x.0_1 = _6 << 59;
_2 = x.0_1 >> 59;
_4 = (__int128 unsigned) _2;
return _4;
That should have been optimised better :-(
The RTL code it ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #60 from Segher Boessenkool ---
(In reply to Roman Krotov from comment #59)
> All, what I'm asking for, is to make something like -Wno-void-unused, which
> would suppress the warnings only for the (void) casted calls.
So you want to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111367
--- Comment #9 from Segher Boessenkool ---
I don't like that "wzd" attribute at all. Please just put an "if" for the mode
around this -- everywhere else (including in a large part of this patch!) we
deal with SImode and DImode separately alread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111367
--- Comment #11 from Segher Boessenkool ---
> > There really should be a comment why one alternative needs the %U{n} and the
> > other can
> > ignore it, btw. Nothing new there, but a head-scratcher :-)
>
> OK, something like: "prefixed load/s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116143
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107757
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116143
--- Comment #6 from Segher Boessenkool ---
But even then, we should have something like attribute ((used)) to force it to
always be considered used -- this is exactly what that attribute is for!
It only doesn't have to be there if some symbol o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007
--- Comment #17 from Segher Boessenkool ---
Does it also work if you spell the option name correctly? All unknown
configure
options are always accepted silently.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116266
--- Comment #3 from Segher Boessenkool ---
No, we do not want that.
There is a huge difference between MSR[VEC] and MSR[VSX]. People can just
write
out what they actually mean. TARGET_ALTIVEC and TARGET_VSX.
The insns here are mostly Vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
--- Comment #9 from Segher Boessenkool ---
(In reply to Georg-Johann Lay from comment #4)
> Would someone please explain what has to be done?
>
> It's likely more than just
>
> #define TARGET_LRA_P hook_bool_void_true
That is what you start w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116170
--- Comment #4 from Segher Boessenkool ---
Is that strong enough? A const_vector (or a const_anything) as lhs of a set
does not make sense at all. How did we even try this, is some more generic
thing broken?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109329
--- Comment #4 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Peter Bergner from comment #2)
> > (In reply to Jeevitha from comment #1)
> > > This test case requires a Power7 or above due to the ieeelongdo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103628
--- Comment #7 from Segher Boessenkool ---
(In reply to HaoChen Gui from comment #5)
> The memory representation of IBM long double is not unique. It's actually
> the sum of two 64-bit doubles.
Yes, and the first of those two DP numbers is req
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109329
Bug ID: 109329
Summary: rs6000: New testcases {mul,div}ic3* should run on
systems without QP
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109329
Segher Boessenkool changed:
What|Removed |Added
Priority|P3 |P4
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2023-03-30
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #7 from Segher Boessenkool ---
Thank you for looking at this!
(In reply to Jonathan Wakely from comment #5)
> c++tools/Makefile.in has:
>
> mostlyclean::
> rm -f $(MAPPER.O)
>
> clean::
> rm -f g++-mapper-server$(exeex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #8 from Segher Boessenkool ---
(In reply to Jonathan Wakely from comment #6)
> Also, after 'make clean' you can no longer do 'make all'
Of course you cannot. Where do you see this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #9 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #8)
> (In reply to Jonathan Wakely from comment #6)
> > Also, after 'make clean' you can no longer do 'make all'
>
> Of course you cannot. Where do you see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |NEW
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109447
Segher Boessenkool changed:
What|Removed |Added
CC||green at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #5 from Segher Boessenkool ---
Correct, this certainly can not be done by combine, it see two independent
pseudos here. For hard registers it *can* do many tricks, but not for
pseudos like this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #9 from Segher Boessenkool ---
That patch looks fine :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
--- Comment #7 from Segher Boessenkool ---
"For clarity of code, the following named constants are suggested. Preferably,
compilers will provide these constants in a header file, but this is not
required
for compliance."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #12 from Segher Boessenkool ---
With the modified compiler? Does it ICE with an unmodified compiler as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2023-04-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #43 from Segher Boessenkool ---
(In reply to Andrew Church from comment #40)
> My rationale for changing the default behavior is that the wider community
> consensus, as evidenced by things like the C++ (and C2x) [[nodiscard]]
> speci
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #51 from Segher Boessenkool ---
(In reply to rusty from comment #47)
> Civility please.
Thank you.
> As Andrew Pinski says "people are mis-using this attribute", and Jakub
> Jelinek makes a similar point. The use of _wur has change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566
--- Comment #17 from Segher Boessenkool ---
So, apparently powerpc-rtems uses -mpowerpc64 by default?! That is
problematic,
it changes the ABI, might not actually work at all (it requires your
setjmp/longjmp
and getcontext/setcontext to restore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109610
--- Comment #10 from Segher Boessenkool ---
(In reply to Hongtao.liu from comment #5)
> One solution is add an peephole for handle such redudancy.
Not okay.
> If powerpc maintainer doesn't like this way, another alternative is add a
> target h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109610
--- Comment #11 from Segher Boessenkool ---
(In reply to Hongtao.liu from comment #5)
> One solution is add an peephole for handle such redudancy.
Not okay.
> If powerpc maintainer doesn't like this way, another alternative is add a
> target h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858
--- Comment #7 from Segher Boessenkool ---
> The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and
> GENERAL_REGS(which is the case in PR109610), hope it can also fix this
> regression.
That sounds more reasonable. But, wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #54 from Segher Boessenkool ---
Propose a patch, then? With justification. It should also work for 10x
bigger testcases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114004
--- Comment #2 from Segher Boessenkool ---
So, the rlwinm keeps all the top 32 bits intact, but those are all zero to
begin
with. Somehow we don't see that, or don't take that into account anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #16 from Segher Boessenkool ---
Yup, GPR31 is used for the emulated frame pointer, so this is user error:
saying
a fixed-purpose register is clobbered makes no sense. You are not allowed to
use any register that the compiler uses fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #57 from Segher Boessenkool ---
(In reply to Richard Biener from comment #56)
> The fix was reverted but will be re-instantiated for GCC 15 by me.
And I still protest.
PR101523 is a very serious problem, way way way more "P1" than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #10 from Segher Boessenkool ---
It is still wrong. You're trying to sweep tour wrong assumptions under the
rug,
but they will only rear up elsewhere. Just fix the actual *target* problem!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #12 from Segher Boessenkool ---
You cannot use a :CC value as argument of an unspec, as explained before.
The result of a comparison is expressed as a comparison, in RTL. This patch
allows malformed RTL in more places than before,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114732
--- Comment #2 from Segher Boessenkool ---
The fourth CR bit for BCD insns does not mean "unordered", it means "invalid or
overflow". It behaves exactly as unordered though, except that it can signal
overflow as well as one of the lt gt eq cond
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114732
--- Comment #3 from Segher Boessenkool ---
1001, 0101, 0011 I mean of course.
In some ways CCmode models this better than CCFPmode, but we do not actually
model
the SO bit (bit 3) at all in CCmode. It is a nice feature of CCmode (that we
actua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114732
--- Comment #4 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #3)
> -- Bit 0 is all-true, bit 2 is all-false, like in the vcmp* insns.
(And bits 1 and 3 are set to zeroes for those insns. So it is all one-hot
there
as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114732
--- Comment #5 from Segher Boessenkool ---
(Or, at-most-one-hot, that is!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865
Segher Boessenkool changed:
What|Removed |Added
CC||abel at ispras dot ru
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865
--- Comment #4 from Segher Boessenkool ---
Well, I wanted to add Alex as well, but BZ does not allow that? Says he does
not exist?
Is there some other mail address than that mentioned in MAINTAINERS, the one he
usually uses, that works, maybe @
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
--- Comment #2 from Segher Boessenkool ---
> 1. We always define the __ROP_PROTECT__ predefined macro when using
> -mrop-protect, even when we've silently disabled ROP protection because of a
> too old -mcpu=CPU value. We should only emit __R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768
--- Comment #6 from Segher Boessenkool ---
Heh, crossed :-) I can confirm my patch works (tested and everything). I have
no idea about zero_extract, which is a blight that should be eradicated tooth
and
nail!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
--- Comment #6 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #2)
> Looks like the issue is during combine.
>
> We go from CCGC with a sign_extend to a zero_extend with CCZ. that can't be
> right.
Why is that not correct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #61 from Segher Boessenkool ---
(In reply to Sarah Julia Kriesch from comment #60)
> I have to agree with Richard. This problem has been serious for a long time
> but has been ignored by IBM based on distribution choices.
What? Wha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #63 from Segher Boessenkool ---
(In reply to Sarah Julia Kriesch from comment #62)
> (In reply to Segher Boessenkool from comment #61)
> > (In reply to Sarah Julia Kriesch from comment #60)
> > > I have to agree with Richard. This pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #66 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #64)
> As promised I'm going to revert the revert after 14.1 is released
> (hopefully tomorrow).
Thank you! beer++
> As for distros I have decided to inc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #26 from Segher Boessenkool ---
(In reply to Michael Meissner from comment #23)
> 1) Ignore it and say to the users don't do that.
>
> 2) Prevent the IEEE 128-bit libgcc bits from being built on a BE or 32-bit
> LE system unless som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114996
--- Comment #1 from Segher Boessenkool ---
This is not a 2->2 combination. It is a 1->1 combination, which we never have
done,
and still don't. We incorrectly "combined" another instruction, which in fact
we
left in place, it isn't combined at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
--- Comment #9 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #2)
> We go from CCGC with a sign_extend to a zero_extend with CCZ. that can't be
> right.
Why not? We prefer zero_extend whenever it has the same result.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
--- Comment #10 from Segher Boessenkool ---
(_extract, btw.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #15 from Segher Boessenkool ---
(In reply to Aldy Hernandez from comment #11)
> I have reverted the prange enabling patch until the IPA pass is fixed.
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109577
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110014
Segher Boessenkool changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
--- Comment #11 from Segher Boessenkool ---
So, is there a simplified testcase that *actually* shows any *actual* problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #22 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #21)
> I am not sure if powerpc vsx
> has &~ though.
VMX has vandc (since 1999), and VSX has xxlandc (since 2010).
In general, PowerPC has a full complement of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092
--- Comment #6 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #4)
> Indeed, combine_simplify_rtx on
> (set (reg:CCGC 17 flags)
> (compare:CCGC (sign_extract:SI (reg/v:SI 101 [ g ])
> (const_int 1 [0x1])
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092
--- Comment #7 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #5)
> I think the bug is in simplify_comparison.
> We have there
> GE (sign_extract:SI (reg/v:SI 101 [ g ]) (const_int 1 [0x1]) (const_int 0
> [0])) (const_int -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092
--- Comment #9 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #8)
> > Yeah, that look like it is missing some test.
>
> I'd go with
> --- gcc/combine.cc.jj 2024-05-07 18:10:10.415874636 +0200
> +++ gcc/combine.cc2024-05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115092
--- Comment #11 from Segher Boessenkool ---
Still okay :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80182
Segher Boessenkool changed:
What|Removed |Added
CC||mkuvyrkov at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #33 from Segher Boessenkool ---
(In reply to Aldy Hernandez from comment #29)
> A minor rant, but why can't all this be set up automatically in the compile
> farm machines?
We have everything installed with the default for whatever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115289
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115289
--- Comment #2 from Segher Boessenkool ---
Note that the testcase isn't valid C (you cannot validly access an array of
char as a long int), but the problem is there anyway. I'll try to write a
better testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115289
--- Comment #3 from Segher Boessenkool ---
This needs backports all the way back to GCC 10 (well, as far back as we can
go, anyway :-) ).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #27 from Segher Boessenkool ---
(In reply to Roger Sayle from comment #21)
> Segher has proposed that object code size correlates with the quality of
It isn't a proposition, it is a simple and obvious fact. But, this isn't
exactly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103
--- Comment #1 from Segher Boessenkool ---
Those are:
$ diff -up rlwinm-0.s{.12,}
--- rlwinm-0.s.12 2023-11-09 18:28:49.362639203 +
+++ rlwinm-0.s 2023-11-09 18:30:46.422896735 +
@@ -6747,7 +6747,7 @@ f_1_16_31:
.LFB345:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103
--- Comment #2 from Segher Boessenkool ---
In all those cases the code is perfectly fine, but also in all of those cases
the
code is still suboptimal: the rldicl is just as superfluous as the second
rlwinm
was! :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606
--- Comment #4 from Segher Boessenkool ---
It needs -O2 -fPIC -fno-exceptions to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606
--- Comment #5 from Segher Boessenkool ---
The insn that it fails on is the result from a split using *tls_ld .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
--- Comment #13 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #12)
> I'll note that you don't always
> get an assembler error, since gcc still passes -many to the assembler for
> non --enable-checking gcc builds, which caus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606
--- Comment #8 from Segher Boessenkool ---
What does "dead at sched2" mean? Are they dead when sched2 starts, or made
dead
by it? Well it must be the former; what pass does make it dead, then? split3
apparently? Why is this not done in split
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758
--- Comment #4 from Segher Boessenkool ---
WORD_REGISTER_OPERATIONS is extremely ill-defined. Or, it is used for other
things than what it stands for, whichever way you want to look at it.
A backend that defines the macro to non-zero promises
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758
--- Comment #10 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #6)
> I must say I have no idea what WORD_REGISTER_OPERATION says about the upper
> bits of a paradoxical SUBREG if it is a MEM and load_extend_op (inner_mode)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758
--- Comment #12 from Segher Boessenkool ---
(In reply to Eric Botcazou from comment #11)
> > It says those upper bits are well-defined, i.e. whatever MD pattern is used
> > for it eventually will emit machine code that has the exact same result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858
--- Comment #10 from Segher Boessenkool ---
(In reply to Hongtao.liu from comment #8)
> (In reply to Segher Boessenkool from comment #7)
> > > The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and
> > > GENERAL_REGS(which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #5 from Segher Boessenkool ---
(In reply to Matthias Kretz (Vir) from comment #2)
> Yes, I stopped my backporting efforts when I became aware that it's failing
> on ARM. I'll get to PPC ASAP and then continue with the backports.
You
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #6 from Segher Boessenkool ---
(In reply to Matthias Kretz (Vir) from comment #4)
> With -mcpu=power10 I see the issue. The problem has been there all the time
> and only surfaced with this test. (It should also have shown on `make
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #52 from Segher Boessenkool ---
(In reply to Alexander Klepikov from comment #50)
> But maybe there is a way to exclude particular insn from combine pass? (I
> guess not).
In general, it is best to let combine just work on everything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71850
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110254
--- Comment #1 from Segher Boessenkool ---
Off topic / pet peeve: it's not an array of functions, so it should not be
called
something_p .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #87 from Segher Boessenkool ---
(In reply to Oleg Endo from comment #53)
> (In reply to Segher Boessenkool from comment #52)
> > There is TARGET_LEGITIMATE_COMBINED_INSN though, which is a workaround for
> > if
> > you really do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #88 from Segher Boessenkool ---
(In reply to Oleg Endo from comment #85)
> > +/* { dg-final { scan-assembler
> > "_f_loop1_rshift:.*mov\.l\\t(\.L\[0-9\]+),(r\[0-9\]+).*sts.l\\tpr,@-r15.*(\.L\[0-9\]+):.*jsr\\t@\\2.*bf\.s\\t\\3.*\\1:\\
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #9 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #4)
> These die because the struct we're using to check the alignment of uses long
> double as the "big" aligned type. We could either disable the tests using a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #94 from Segher Boessenkool ---
(In reply to Alexander Klepikov from comment #92)
> I remembered why I used two different insns - first to eliminate infinite
> loop with help of marking insn with attribute, and second because I could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
--- Comment #17 from Segher Boessenkool ---
(In reply to Roger Sayle from comment #16)
> Just to warn people in advance, the test case pr78904-1b.c is expected to
> start FAILing with the commit of
> https://gcc.gnu.org/pipermail/gcc-patches/2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
--- Comment #5 from Segher Boessenkool ---
Constraints are completely the wrong tool for this. Just use modes, which
*are* the right tool?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
--- Comment #8 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #6)
> (In reply to Segher Boessenkool from comment #5)
> > Constraints are completely the wrong tool for this. Just use modes, which
> > *are* the right tool?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
--- Comment #10 from Segher Boessenkool ---
(In reply to Nicholas Piggin from comment #9)
> I don't know why constraint is wrong and mode is right
Simple: you would need O(2**T*N) constraints for our existing N register
constraints, together wi
701 - 800 of 906 matches
Mail list logo
