https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #27 from Segher Boessenkool ---
> This is a GIMPLE pass which has no idea what the backend will expand
> __builtin_darn() to.
So you are saying >90% of builtins now need to say they are pure and const
(which
makes totally no sense f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #25 from Segher Boessenkool ---
No, darn does have a side effect: it returns a random number in the destination
reg (_deliver_ _a_ _r_andom _n_umber). It does not touch memory at all.
There are no call insns at all either, of cours
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #24 from Segher Boessenkool ---
> > Okay, two insns, there's an add insn as well. But *not* unrolling this
> > likely
> > makes bigger code already!
>
> This is because
>
> /* If there is call on a hot path through the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #20 from Segher Boessenkool ---
gcc.target/powerpc/darn-3.c
I'll quote the whole thing:
===
static int darn32(void) { return __builtin_darn_32(); }
int four(void)
{
int sum = 0;
int i;
for (i = 0; i < 4; i+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #18 from Segher Boessenkool ---
So, you are saying the change made us realise some insns can never be optimised
away? It should be obvious in much more fundamental ways that these insns can
never be optimised away (simply because t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #16 from Segher Boessenkool ---
Trivial stuff is no longer unrolled at all after this change. It does not
matter
*at all* whether an insn has a side effect or not, for whether code with such
an
insn should be unrolled or not. Any h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117964
--- Comment #10 from Segher Boessenkool ---
Wrt more barriers than needed... This is always less than the amount of other
extra RTL, so it is kinda harmless. But if we care, we should do prevent this
in emit_barrier itself, so that it is solve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117964
--- Comment #9 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #8)
> > maybe_duplicate_computed_goto should never ever decide to know better than
> > its caller. That way insanity lies.
>
> "maybe_" suggests it's not al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117964
--- Comment #7 from Segher Boessenkool ---
When maybe_duplicate_computed_goto is asked to duplicate a block with 9189
successors, it damn well should! If that is a bad idea for the case at hand,
just do not call maybe_duplicate_computed_goto on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117718
--- Comment #4 from Segher Boessenkool ---
The address for lxv and lxvx can be anything. The *offset* in the address for
lxv has to be a multiple of sixteen. This isn't any different from DS-mode
(well,
multiple of 4 there), and we have DQ-mod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117629
--- Comment #2 from Segher Boessenkool ---
"Since C23 "bool" is a keyword designating a type", something like that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #25 from Segher Boessenkool ---
(In reply to John David Anglin from comment #24)
> There are a couple of issues. The pa backend only supports memory
> accesses that load to a register or store from a register. LRA was
> creating in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #23 from Segher Boessenkool ---
(In reply to John David Anglin from comment #21)
> This bug was fixed by changing PA_HARD_REGNO_MODE_OK. On the 32-bit
> target we no longer allow TI and OI mode in the hard registers. I only
> allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117007
--- Comment #7 from Segher Boessenkool ---
It is always more and slower code. Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #14 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #13)
asm-generic/ is a kernel thing, not relevant at all. bits/resource.h is used
by , the header you should use.
That is used by "system.h" under a
#ifdef H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #9 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #2)
> I am not sure if there is not much to be done.
> The front-end is recusive here:
So you found the bug already. Now fix it :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #12 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #10)
> void
> stack_limit_increase (unsigned long pref ATTRIBUTE_UNUSED)
> {
> #if defined(HAVE_SETRLIMIT) && defined(HAVE_GETRLIMIT) \
> && defined(RLIMIT_S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #11 from Segher Boessenkool ---
(In reply to Richard Biener from comment #5)
> I agree it's difficult to solve. GCC tries to up the stack limit to
> unlimited, why isn't this working for you? Maybe we should remember the
> failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117251
--- Comment #12 from Segher Boessenkool ---
(In reply to Richard Biener from comment #7)
> Is it possible to define a fused and/xor+xor alternative that's split after
> RA, slightly pessimized to prefer the altivec alternative, to allow the XXL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116780
--- Comment #17 from Segher Boessenkool ---
(In reply to Georg-Johann Lay from comment #16)
> (In reply to Segher Boessenkool from comment #15)
> > It makes sense never, not on any target, not with LRA nor without.
> Though there are test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117238
--- Comment #2 from Segher Boessenkool ---
So the only way you can handle anything OImode is via a function call, with it
pointed to by a function argument? Should you support OImode at all then
(you can do that with a pointer to void argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115242
--- Comment #7 from Segher Boessenkool ---
(In reply to Florian Weimer from comment #6)
> The issue on POWER is different because the ABI was enhanced retroactively,
> supposedly in a transparent way.
The PowerPC AltiVec ABI is separate from th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116780
--- Comment #15 from Segher Boessenkool ---
(In reply to Georg-Johann Lay from comment #14)
> (In reply to Segher Boessenkool from comment #13)
> > But this testcase is in gcc.target/ anyway, right?
> That's just a copy of gcc.dg/torture/pr6408
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116780
--- Comment #13 from Segher Boessenkool ---
(In reply to Georg-Johann Lay from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > That is invalid C code, of course (an out of bounds access).
> What about the other test case
> htt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116780
--- Comment #12 from Segher Boessenkool ---
(In reply to denisc from comment #11)
> (In reply to Segher Boessenkool from comment #8)
> > (In reply to denisc from comment #2)
> > > Comment on attachment 59393 [details]
> > > Simplified testcase
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116780
--- Comment #8 from Segher Boessenkool ---
(In reply to denisc from comment #2)
> Comment on attachment 59393 [details]
> Simplified testcase
>
> void
> f ()
> {
> volatile char c[0];
> c[0] = 0;
> }
That is invalid C code, of course (an o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #20 from Segher Boessenkool ---
(In reply to John David Anglin from comment #19)
> (In reply to Segher Boessenkool from comment #17)
> > (In reply to John David Anglin from comment #15)
> > > While bootstrap is okay, there are some n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #17 from Segher Boessenkool ---
(In reply to John David Anglin from comment #15)
> While bootstrap is okay, there are some new test fails:
>
> AIL: gcc.c-torture/compile/pr92618.c -O1 (internal compiler error:
> maximum number of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #16 from Segher Boessenkool ---
(In reply to GCC Commits from comment #13)
> The master branch has been updated by John David Anglin
> :
>
> https://gcc.gnu.org/g:44a81aaf73f795e6992cbfb98ec48480e5ca94ec
>
> commit r15-4483-g44a81a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116550
--- Comment #13 from Segher Boessenkool ---
Yeah :-) So post an actual patch, to gcc-patches@? :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113954
--- Comment #9 from Segher Boessenkool ---
Add a RejectNegative perhaps, because -mno-lra no longer does what the user
expects? And/or WarnRemoved? And the
;; lra is still unproven for ARC, so allow to fall back to reload with
-mno-lra.
line
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
--- Comm
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
--- Comm
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=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
--- Comm
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?
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=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
--- Comm
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
1 - 100 of 881 matches
Mail list logo
