https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113953
--- Comment #4 from Segher Boessenkool ---
Heh, I thought you forgot the manual, but -mlra apparently never was mentioned
in there anyway :-)
Thanks for the help pulling GCC kicking and streaming into the 21st century!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113954
--- Comment #4 from Segher Boessenkool ---
Yup. What I meant is, if the port still sees some use in their -mlra, there is
no pressure from us to have them remove it, we'll just make it not do anything
anymore :-) Maybe they still see some prob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113954
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #2 from Segher Boessenkool ---
(In reply to dave.anglin from comment #1)
> On 2024-02-15 2:01 p.m., sjames at gcc dot gnu.org wrote:
> > People are getting eager to require LRA. Please port the PA target to LRA
> > (see
> > PR113932
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
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=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=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=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=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=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=107757
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=113484
--- Comment #4 from Segher Boessenkool ---
Ah, this was about *actual* half-precision float, which indeed is 3.0 (Power9).
But all the same holds: it needs to be added to the ABI before we can have a
type for it, and it still won't be terribly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113484
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116063
--- Comment #4 from Segher Boessenkool ---
The two members have the same in-memory representation, but transparent_union
is explicitly only about function arguments, so Andrew's arguments are very
valid I think.
It would be nice if we could war
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389
--- Comment #8 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #4)
> (In reply to Segher Boessenkool from comment #2)
> > So, what value do we output? And why?
> The invalid offset is zero, so: hashst r0,0(r1)
> As the assemb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #82 from Segher Boessenkool ---
(In reply to rusty from comment #81)
> Not many function returns are as clearly required as realloc...
Then they shouldn't use warn_unused_result! The documentation of that is
very very clear: both ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #80 from Segher Boessenkool ---
(In reply to Andrew Church from comment #79)
> (In reply to Segher Boessenkool from comment #78)
> > If someone (the user, the author, anyone) used warn_unused_result where it
> > is
> > not appropriat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #78 from Segher Boessenkool ---
(In reply to Andrew Church from comment #77)
> (In reply to Segher Boessenkool from comment #72)
> > if (foo()) {
> > /* The return value of foo can be ignored here because X and Y. */
> > }
>
> Thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #72 from Segher Boessenkool ---
The correct way to not get the warning about unused results, is to _do_ use
the function return value, of course, as I explained in #c18 already.
Like:
if (foo()) {
/* The return value of foo can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #63 from Segher Boessenkool ---
(In reply to Christian Groessler from comment #62)
> (In reply to Segher Boessenkool from comment #60)
> > So you want to not warn for some (just *some*) explicitly unused cases, and
> > do
> > warn for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115800
--- Comment #3 from Segher Boessenkool ---
Note that we *should* support ieee128 with *any* configuration, to avoid
nonsense
like this (and many more). But, alas.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115800
--- Comment #2 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #1)
> "If you build a little-endian compiler". What does that mean? A
> cpu=powerpc76le* compiler? Or something else?
>
> Note that *any* compiler can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115800
--- Comment #1 from Segher Boessenkool ---
"If you build a little-endian compiler". What does that mean? A
cpu=powerpc76le* compiler? Or something else?
Note that *any* compiler can be used as little-endian, by just using -mlittle.
Nothing m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115612
--- Comment #3 from Segher Boessenkool ---
(And it shouldn't be called *"combine"* at all, yadda yadda).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115612
--- Comment #2 from Segher Boessenkool ---
(In reply to Kewen Lin from comment #1)
> Thanks for filing this!
>
> For the given example, previously split1 splits ordered test into unordered
> test + xor, late-combine pass recombines them into or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
--- Comment #5 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #4)
> bergner@ltcden2-lp1:ICE$ gcc -S -m64 -O2 -mcpu=power5 -mabi=no-altivec bug.c
> bug.c:3:1: internal compiler error: in rs6000_option_override_internal, at
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688
--- Comment #3 from Segher Boessenkool ---
Something like that.
But why would we want to disable generation of VSX or VMX insns at all?
This is similar to disabling generation of popcntd insns if you do not like
those!
Having generation of V*X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
--- Comment #12 from Segher Boessenkool ---
The backports have not been done yet.
It would be good if the blockage / barrier would get some comment btw, saying
what exactly it is intended to do! It is very much cargo-cult the way it is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #15 from Segher Boessenkool ---
(In reply to Jessica Clarke from comment #8)
> The clang/ subdirectory should be building itself with -fno-strict-aliasing
> on GCC already
"Should". I guess you mean "is", as in "we already conclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #14 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #7)
> This code gives me strict aliasing violation vibes:
> ```
> T **getAddressOfPointer(ExternalASTSource *Source) const {
> // Ensure the integer is in po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114996
--- Comment #5 from Segher Boessenkool ---
(My name is Segher)
I implemented unCSE. It does exactly this. It will still be a few days before
you will see it, sorry!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114996
--- Comment #3 from Segher Boessenkool ---
That makes no sense. combine only ever results in 0, 1, or 2 insns, never 3.
What you mean is that after 4 or more combinations you got what you wanter.
But
combine (like most RTL optimisations!) is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115466
--- Comment #5 from Segher Boessenkool ---
The GCC documentation says
> Note that the 'vec_ld' and 'vec_st' built-in functions always generate
> the AltiVec 'LVX' and 'STVX' instructions even if the VSX instruction
> set is available.
(which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114004
--- Comment #3 from Segher Boessenkool ---
We have very many similar PRs reported over the years, but more for when the
argument is *signed*, actually! There, we end up with unneeded sign-extension
insns often (which are easier to spot than ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115466
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389
--- Comment #3 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #2)
> So, what value do we output? And why?
It would be nice if the assembler told us, btw :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389
--- Comment #2 from Segher Boessenkool ---
So, what value do we output? And why?
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=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
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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
--- Co
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.cc2024-05
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 #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 at
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=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=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 #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=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 __R
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
as
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 #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=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 fo
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
Status|UNCO
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 pr
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 tha
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 ends
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 a
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 reduced
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).
I
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
> addi
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"!
S
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
> benefic
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
Status|UNCONFIRM
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 at
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) d
1 - 100 of 1210 matches
Mail list logo