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=80182
Segher Boessenkool changed:
What|Removed |Added
CC||mkuvyrkov at gcc dot gnu.org
---
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=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.cc
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
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=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=114902
--- Comment #11 from Segher Boessenkool ---
So, is there a simplified testcase that *actually* shows any *actual* problem?
|REOPENED
CC||segher at gcc dot gnu.org
--- Comment #7 from Segher Boessenkool ---
Reopened, then.
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=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=114902
--- Comment #10 from Segher Boessenkool ---
(_extract, btw.)
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=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
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
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
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
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?
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=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=114768
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
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
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=96865
Segher Boessenkool changed:
What|Removed |Added
CC||abel at ispras dot ru
--- Comment
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=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
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
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
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=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=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=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
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=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=114518
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2024-03-29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #21 from Segher Boessenkool ---
(2.06, whoops)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #20 from Segher Boessenkool ---
(In reply to Michael Meissner from comment #19)
> When I wrote the VSX support many years ago, I intended that -mvsx enable
> all of ISA 2.06
But that is not how we do things, and it can never work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114518
--- Comment #1 from Segher Boessenkool ---
It fails with -m32 only for me?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114515
--- Comment #2 from Segher Boessenkool ---
The PR101523 fix makes sure we do not get the same I2 back, because that
violates algorithmic assumptions of combine. Importantly, the way it was
things can be changed back time and time again, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70928
--- Comment #6 from Segher Boessenkool ---
"All"... not the non-finite denormals ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #51 from Segher Boessenkool ---
(In reply to Richard Biener from comment #46)
> Maybe combine already knows that it just "keeps i2" rather than replacing it?
It never does that. Instead, it thinks it is making a new I2, but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #39 from Segher Boessenkool ---
(In reply to Richard Biener from comment #37)
> Created attachment 57753 [details]
> quick attempt at a limit
>
> So like this?
Hrm. It should be possible to not have the same test 28 times. Just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #38 from Segher Boessenkool ---
(In reply to Richard Biener from comment #36)
> > No, it definitely should be done. As I showed back then, it costs less than
> > 1%
> > extra compile time on *any platform* on average, and it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #35 from Segher Boessenkool ---
(In reply to Richard Biener from comment #34)
> The change itself looks reasonable given costs, though maybe 2 -> 2
> combinations should not trigger when the cost remains the same? In
> this case it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #31 from Segher Boessenkool ---
I need a configure flag, hrm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #29 from Segher Boessenkool ---
I did manage to build one, but it does not know _Float64x and stuff.
Do you have a basic C-only testcase, maybe?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #28 from Segher Boessenkool ---
For Q111: on rs6000:
;; Combiner totals: 53059 attempts, 52289 substitutions (7135 requiring new
space),
;; 229 successes.
I don't have C++ cross-compilers built (those are not trivial to do, hrm).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #25 from Segher Boessenkool ---
So this testcase compiles on powerpc64-linux (-O2) in about 34s. Is s390x
way worse, or is this in lie what you are seeing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #24 from Segher Boessenkool ---
(In reply to Andreas Krebbel from comment #21)
> Wouldn't it in this particular case be possible to recognize already in
> try_combine that separating the move out of the parallel cannot lead to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #17 from Segher Boessenkool ---
Why does this happen so extremely often for s390x customers? It should from
first principles happen way more often for e.g. powerpc, but we never see such
big problems, let alone "all of the time"!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #16 from Segher Boessenkool ---
(In reply to Andreas Krebbel from comment #14)
> If my analysis from comment #1 is correct, combine does superfluous steps
> here. Getting rid of this should not cause any harm, but should be
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #13 from Segher Boessenkool ---
(In reply to Sarah Julia Kriesch from comment #12)
> I expect also, that this bug is a bigger case.
A bigger case of what? What do you mean?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #11 from Segher Boessenkool ---
Okay, so it is a function with a huge BB, so this is not a regression at all,
there will have been incredibly many combination attempts since the day combine
has existed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101893
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #9 from Segher Boessenkool ---
Yeah.
Without a testcase we do not know what is going on. Likely it is a testcase
with some very big basic block, which naturally gives very many combination
opportunities: the problem by nature is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65010
--- Comment #13 from Segher Boessenkool ---
(In reply to pthaugen from comment #11)
> Another example to clean up. The back to back constant load/sign extend
> sequence of rtl insns is created in each block by the block reordering pass
> (.bbo)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #6 from Segher Boessenkool ---
There is no attached testcase, btw. This makes investigating this kind of
tricky ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #5 from Segher Boessenkool ---
Hrm. When did this start, can you tell?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89072
--- Comment #13 from Segher Boessenkool ---
I always have -Wmissing-declarations -Wformat=2 , for some reason those aren't
in
-Wall, not even in -W . Crazy if you ask me :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89072
--- Comment #11 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #9)
> It is not always wrong, it is a reasonable choice for some projects during
> their development, if they are willing to fix or work around all new
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89072
--- Comment #7 from Segher Boessenkool ---
-Werror always is wrong, for any sane users. Always. Not just "in general".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89072
--- Comment #4 from Segher Boessenkool ---
(In reply to Xi Ruoyao from comment #3)
> In GCC 14 several warnings will be turned to errors by default with C99 or a
> newer C standard. But generally -Werror should *never* be the default.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #5 from Segher Boessenkool ---
(In reply to John Paul Adrian Glaubitz from comment #3)
> (In reply to Segher Boessenkool from comment #2)
> > We need a reduced testcase.
>
> Any suggestion on how to proceed here?
Nothing in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #2 from Segher Boessenkool ---
We need a reduced testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113280
--- Comment #11 from Segher Boessenkool ---
(In reply to David Brown from comment #8)
> As for using "=X" in the "opt == 3" case, I worry that that could lead to
> errors as the two assembly lines are independent. The first says "put X
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113280
--- Comment #10 from Segher Boessenkool ---
> But the dump from combine does not make sense:
What about this does not make sense to you?
> Failed to match this instruction:
and then still doing stuff? That is normal. I'll work on making that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113280
--- Comment #9 from Segher Boessenkool ---
(In reply to Alexander Monakov from comment #6)
> From the context given in the gcc-help thread, the goal is to place an
> optimization barrier in a sequence of floating-point calculation. "+r" is
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113280
--- Comment #5 from Segher Boessenkool ---
Oh, and if the goal of the code is to put and keep the datum in a register, the
code should really use "+r" anyway!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113280
--- Comment #4 from Segher Boessenkool ---
Nothing has changed here.
opt == 2 and opt == 3 should use "=X", not "+X", btw.
combine is perfectly correct that "X" allows *any operand whatsoever*, also
those
that you cannot really use as an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113115
--- Comment #6 from Segher Boessenkool ---
Using -mpower9-vector while not having -mcpu=power9 (or later) is wrong, and
should
not work. Using -mno-power9-vector is just weird.
If we can neuter the -mpower9-vector (etc.) options now, that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208
--- Comment #9 from Segher Boessenkool ---
(In reply to John Paul Adrian Glaubitz from comment #8)
> (In reply to Segher Boessenkool from comment #7)
> > This PR is for the sysv ABI, while most discussion was about the "ELFv1"
> > ABI.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208
--- Comment #7 from Segher Boessenkool ---
This PR is for the sysv ABI, while most discussion was about the "ELFv1" ABI.
Only the 64-bit ABIs have the code model ABI, for the powerpc*-*-*
configurations.
Some other architectures have it for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108208
--- Comment #4 from Segher Boessenkool ---
See my previous comment?
You can either write better code, or use -mcmodel=large or similar, accepting
the not-so-stellar generated code you get then.
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=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 #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=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
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
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=110606
--- Comment #4 from Segher Boessenkool ---
It needs -O2 -fPIC -fno-exceptions to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
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=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=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=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
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
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110717
--- Comment #12 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #9)
> Wonder how many important targets provide double-word shift patterns vs.
> ones which expand it through generic code.
Very long ago rs6000 had special
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
--- Comment #12 from Segher Boessenkool ---
> I guess that would be annoying if you couldn't have modifiers on constraints
There is no such thing as "operand modifiers". There are *output* modifiers:
they change how an operand is *printed*,
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
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 #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=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/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=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 #88 from Segher Boessenkool ---
(In reply to Oleg Endo from comment #85)
> > +/* { dg-final { scan-assembler
> >
1 - 100 of 3134 matches
Mail list logo
