https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106059
--- Comment #5 from Segher Boessenkool ---
Thank you for the quick fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026
--- Comment #9 from Segher Boessenkool ---
This is all handled in combine, nothing is specific to rs6000 (only the
description of all of our insns is, of course, but there is really no way
around that, nor should there be :-) )
Why does combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026
--- Comment #10 from Segher Boessenkool ---
So on Arm we get
Trying 6 -> 8:
6: r119:SI=r123:SI>>0x8
REG_DEAD r123:SI
8: {cc:CC_NZ=cmp(r119:SI&0x6,0);clobber scratch;}
REG_DEAD r119:SI
Failed to match this instruction:
(parall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026
--- Comment #11 from Segher Boessenkool ---
Wrt rs6000: we have shift+mask+compare in just one insn (it is basic powerpc),
and our
(define_insn "*and3_imm_dot_shifted"
pattern outputs this as just an "andi." insn when it can. But indeed the sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #3 from Segher Boessenkool ---
STRICT_LOW_PART is required to contain a SUBREG though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #5 from Segher Boessenkool ---
Thanks for tracking this down!
Interesting it survived so long. We could use some RTL checking on this :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #6 from Segher Boessenkool ---
It looks like quite a few more backends use strict_low_part on random RTL,
which
is completely meaningless :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #8 from Segher Boessenkool ---
There is structural RTL checking in rtl.h (see RTL_CHECK{1,2,C1,C2,C3} and the
various ELT and INT accessors). This would be easier to use here if we used
some STRICT_LOW_PART_P everywhere :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #6 from Segher Boessenkool ---
What is wrong there? It isn't obvious. You may need to show insns 188 and 199
in non-slim form, "slim" is very lossy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #7 from Segher Boessenkool ---
(The original insns, before this combination.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100694
--- Comment #3 from Segher Boessenkool ---
Should this not be handled by the subreg passes?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100694
--- Comment #4 from Segher Boessenkool ---
On aarch64 we have (in expand):
;; i_4 = i_3 << 64;
(insn 10 9 11 (set (subreg:DI (reg/v:TI 94 [ i ]) 8)
(subreg:DI (reg/v:TI 93 [ i ]) 0)) "100694.c":4:6 -1
(nil))
(insn 11 10 0 (set (s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106335
Bug ID: 106335
Summary: struct copies with volatile fields are done using
memcpy
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106210
--- Comment #6 from Segher Boessenkool ---
The prepare_shrink_wrap code handles only very limited very simple cases.
After g:8d2d39587d94 there is another copy at this point (which is an
*improvement*, it gives more freedom). I don't see how t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301
--- Comment #3 from Segher Boessenkool ---
What CPU is in your Power system, and what -mcpu= did you compile with?
What is the ABI you are using? (That last one doesn't seem to matter in
this particular case, but :-) )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301
--- Comment #5 from Segher Boessenkool ---
Looking at -fdump-tree-all-all, things are fine with "foo" until the
switchlower pass. Before that all nine switch cases and the default
case all had probability 0.10; after the switch conversion there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301
--- Comment #7 from Segher Boessenkool ---
Assuming that you divide the "default" case into ten pieces of 0.01 each,
some slight corrections:
(In reply to Thomas Koenig from comment #6)
> int foo3 (int n)
> {
> if (__builtin_expect_with_proba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
--- Comment #1 from Segher Boessenkool ---
Could you attach something that is a valid input to the compiler? Something
that does not include the preprocessor directives... did you use -dM?
Don't :-)
(I can reproduce with this code, but there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
--- Comment #2 from Segher Boessenkool ---
So, even if I use
-fno-shrink-wrap
and, although rs6000.c has anyway
/* If we are inserting ROP-protect instructions, disable shrink wrap. */
if (rs6000_rop_protect)
flag_shrink_wrap = 0;
we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
Segher Boessenkool changed:
What|Removed |Added
CC||mliska at suse dot cz
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301
--- Comment #9 from Segher Boessenkool ---
(In reply to Thomas Koenig from comment #8)
> (In reply to Segher Boessenkool from comment #7)
>
> > Yeah :-) Of course in your testing the nine named cases have the same
> > probability,
> > which i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101177
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101372
--- Comment #5 from Segher Boessenkool ---
On powerpc64-linux the failure is
In file included from /home/segher/src/gcc/gcc/c-family/c-common.h:26,
from /home/segher/src/gcc/gcc/cp/cp-tree.h:40,
from /home/segh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101384
--- Comment #4 from Segher Boessenkool ---
The testcase works fine for me? What does it need to fail?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #2 from Segher Boessenkool ---
A good solution would add all those historical targets to
rs6000_machine_from_flags.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101323
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2021-07-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101384
--- Comment #6 from Segher Boessenkool ---
I did run on the cfarm. What kind of machine does it need to fail? p8? p9?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288
--- Comment #23 from Segher Boessenkool ---
-m32 is required here. With -fno-unroll-loops -m32 you now get
flush_dcache_range:
rlwinm 3,3,0,0,27
addi 4,4,15
subf 4,3,4
srwi. 4,4,4
beqlr 0
mtctr 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129
--- Comment #7 from Segher Boessenkool ---
That patch is pre-approved (if it works ;-) ) Bill. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #5 from Segher Boessenkool ---
(In reply to Franz Sirl from comment #3)
> (In reply to Segher Boessenkool from comment #1)
> > The -many is problematic, that is the whole point of this. As in this
> > example: on different subtarget
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #6 from Segher Boessenkool ---
(In reply to Franz Sirl from comment #4)
> How about something along this patch? It's not fully done (no good idea
> about SPEC stuff like "mcpu=7400: -mppc %{!mvsx:%{!maltivec:-maltivec}};"
> yet), but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43073
--- Comment #8 from Segher Boessenkool ---
Much more importantly, gcc-core doesn't exist anymore (so WORKSFORME is a
strange resolution).
Using the documented build procedures is recommended, and is what is
supported here (not any cross tool wha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
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=101104
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
Segher Boessenkool changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #10 from Segher Boessenkool ---
(In reply to Franz Sirl from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > I don't think it is a good idea to add workaround upon workaround to avoid
> > some of the not-so-useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
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=101393
--- Comment #14 from Segher Boessenkool ---
(In reply to Franz Sirl from comment #12)
> The emitted .machine is easy to fix, what's not so easy to fix is the
> intention behind Segher's change that caused the wrong .machine.
>
> Consider this s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #17 from Segher Boessenkool ---
(In reply to Franz Sirl from comment #15)
> > "7400" and "403" are not supported target attribute values, fwiw (says the
> > manual).
>
> Hmm, I don't understand what you mean.
I mean that I cannot r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67382
--- Comment #4 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #3)
> Note combine is able to figure out the jump is unconditional but there is no
> "pattern" to match it:
> Trying 10 -> 17:
>10: r85:QI=0x1
>17: {flags:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67382
--- Comment #5 from Segher Boessenkool ---
It turns out that noop other_insn is fine, and is accepted etc., but the
resulting i3 in this case is not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103
--- Comment #13 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #10)
> Unfortunately, it doesn't work for the #c0 testcase, after the combiner
> splitter kicks in, the combiner doesn't even try that 4 insn combination.
It do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103
--- Comment #15 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Segher Boessenkool from comment #13)
> > (In reply to Jakub Jelinek from comment #10)
> > > Unfortunately, it doesn't work for the #c0 testcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103
--- Comment #17 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #16)
> Created attachment 51209 [details]
> gcc12-pr78103.patch
>
> Updated patch. This one fixes the reuse of a pseudo you've mentioned above,
> and fixes gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103
--- Comment #20 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #18)
> (In reply to Segher Boessenkool from comment #17)
> > > Nothing changes for combine though, I think it really would be nice if it
> > > could either change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103
--- Comment #21 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #19)
> Created attachment 51211 [details]
> gcc12-pr78103.patch
>
> Updated untested patch that uses define_insn_and_split in 2 cases instead of
> the combine sp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89847
--- Comment #2 from Segher Boessenkool ---
Interestingly, while this gives optimal code for power8 and power9, we still
get an unnecessary mulli for power10. This is because multiplication by 31
is expanded to a multiplication on power10 (just l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82940
--- Comment #5 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #4)
> As long as nothing on the rtl level (combine) does not mess this up, it
> should produce the best code.
combine cannot ever create worse code than it had as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830
--- Comment #4 from Segher Boessenkool ---
(In reply to Bill Schmidt from comment #0)
> (1) linebuf and pos are global variables, and the compiler cannot tell
> whether or not there are problems with array bounds accesses here. Indeed,
> pos is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2021-08-12
Assignee|unas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101893
Bug ID: 101893
Summary: There is no vgbbd on p7
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #3 from Segher Boessenkool ---
The current code reads
if ((flags & OPTION_MASK_DIRECT_MOVE) != 0)
rs6000_define_or_undefine_macro (define_p, "_ARCH_PWR8");
if ((flags & OPTION_MASK_MODULO) != 0)
rs6000_define_or_undefine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #3 from Segher Boessenkool ---
(In reply to Marek Polacek from comment #2)
> Assignee present -> ASSIGNED.
Hrm, this used to work automatically when you press "take"? What changed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55549
--- Comment #2 from Segher Boessenkool ---
Three things:
1) It was invalid *before* this, already (vector mode paradoxical subregs
make no sense);
2) The subreg needs to be fixed up *somehow*, too;
3) subreg of mem will go away any day now (or,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82940
--- Comment #7 from Segher Boessenkool ---
(In reply to Peter Cordes from comment #6)
> # power64 GCC 9.2.1 (ATI13.0)
> rlwimi 3,4,0,255# bit-blend according to mask, rotate count=0
> rldicl 3,3,0,32 # Is this zero-extensi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82940
--- Comment #8 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #7)
> (In reply to Peter Cordes from comment #6)
> > # power64 GCC 9.2.1 (ATI13.0)
> > rlwimi 3,4,0,255# bit-blend according to mask, rotate count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #5 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #4)
> Started with r9-3950-g2f0b80c7a4ab4254f57ba63de26ebb7896e3742d
> Does the modsw instruction really need the early-clobber (i.e. does it first
> overwrite th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #5 from Segher Boessenkool ---
"structure layout happens before the zero width bitfields are removed by the
FE".
So, what can break still, then?
- li 9,0
- sldi 9,9,32
- mtvsrd 1,9
+ li 3,0
std 0,16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #6 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #5)
> "structure layout happens before the zero width bitfields are removed by the
> FE".
>
> So, what can break still, then?
Homogeneous aggregates can br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #5 from Segher Boessenkool ---
(In reply to HaoChen Gui from comment #4)
> I wonder if it's a Power8 architecture when those 6 options are all
> disabled. Or it is regressed to Power7? The "_ARCH_PWR8" represents the
> hardware archi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90381
--- Comment #6 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > Are bitfields allocated right to left on all LE configs?
>
> I think the majority of them, I have not u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #9 from Segher Boessenkool ---
(In reply to Michael Matz from comment #8)
> So, I think, not removing those members from the FE makes sense, they contain
> crucial information. Unfortunately that means that they need to be dealt
> w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062
--- Comment #6 from Segher Boessenkool ---
(In reply to Nicholas Piggin from comment #0)
> I may be unaware of a constraint of C standard here, but maintaining the two
> base addresses seems pointless,
This is an ordering problem. The unroller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062
--- Comment #7 from Segher Boessenkool ---
Btw, -ftree-loop-vectorize -fvect-cost-model=cheap makes this 8 vectors per
iteration (and very-cheap doesn't vectorise it). Maybe overkill, esp. when
you look at the tail code, but that 8 vector core
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #8 from Segher Boessenkool ---
(In reply to HaoChen Gui from comment #6)
> (In reply to Segher Boessenkool from comment #5)
> > (In reply to HaoChen Gui from comment #4)
> > > I wonder if it's a Power8 architecture when those 6 optio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062
--- Comment #9 from Segher Boessenkool ---
Thanks for the detective work!
So the variable expansion code could be improved to handle sign extensions
better (or maybe zero extensions as well?) In either case that won't help
rs6000 much anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062
--- Comment #12 from Segher Boessenkool ---
We can backport Hao Chen's patch, it has proven to cause no problems at all.
We don't normally backport patches that aren't bugfixes, but we could do it
for important enough things (we did it for most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
Segher Boessenkool changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
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=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=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
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=101893
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRM
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=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 #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 #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 #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 #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 #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 #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 #31 from Segher Boessenkool ---
I need a configure flag, hrm.
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 #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 #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 #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
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=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=114518
--- Comment #1 from Segher Boessenkool ---
It fails with -m32 only for me?
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=113652
--- Comment #21 from Segher Boessenkool ---
(2.06, whoops)
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=110762
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
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 cod
601 - 700 of 897 matches
Mail list logo
