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*, th
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=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 mor
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.
>
> Doe
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 woul
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 outpu
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 #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
> ina
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 #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
> anywhe
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=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 particu
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.
> Besides
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 #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
> warnings
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=115389
--- Comment #2 from Segher Boessenkool ---
So, what value do we output? And why?
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=115466
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
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
--- 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=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=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=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=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=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=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=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=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=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=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=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 #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=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=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 #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 #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 #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=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=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=113484
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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=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=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 #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 #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=116550
--- Comment #13 from Segher Boessenkool ---
Yeah :-) So post an actual patch, to gcc-patches@? :-)
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=19779
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
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=117007
--- Comment #7 from Segher Boessenkool ---
It is always more and slower code. Yes.
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=29838
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
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=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=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=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=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=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=113954
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
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
--- 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=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=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=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=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 #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=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=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=118663
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #5 from Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118556
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
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 #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 #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
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
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 #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=116028
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #14 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #8)
> Because as this PR shows, those 2->2 insn merges with no change on i2 can
> make a lot of sense and allow combination on the second and following user
> of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #22 from Segher Boessenkool ---
(In reply to Richard Sandiford from comment #18)
> I'd been reluctant to get involved in this for fear of creating friction or
> being a cook too many,
No, your input is much appreciated!
> but: the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #19 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #16)
> Tamar's explanation why #c0 gcc 14 code is better than gcc 15:
> "the mov is a zero latency instruction. sxtw, asr and sbfx themselves are
> aliases to th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #26 from Segher Boessenkool ---
(In reply to Richard Sandiford from comment #23)
> Yeah, I'd wondered about limiting it an all cases too. Definitely seems
> worth trying. But given that we're in stage 4, maybe it would make sense t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #4 from Segher Boessenkool ---
Hi Alex,
(In reply to Alexandre Oliva from comment #0)
> This raises a number of problems:
>
> - instructions and expanders for these builtins don't have their conditions
> tested, so they must necess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #6 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #5)
> This needs splitting up in parts. Maybe then some parts can be correct,
> even!
Of course that requires explanatory comments in the patch submission
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119629
--- Comment #5 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #2)
> (In reply to Peter Bergner from comment #1)
> > > but the conditions that enable the expansion of
> > > __builtin_scalar_byte_in_set
> > > are those of [po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119468
--- Comment #3 from Segher Boessenkool ---
prtyd and popcntb are executed similarly on all hardware: same execution pipes.
The extsw we currently generate is not needed at all, a very common and
well-known issue, generic as well (not really rs60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119468
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118541
--- Comment #8 from Segher Boessenkool ---
(The traditional FP comparisons we do use, i.e. fcmpu. We never used fcmpo,
because it is problematic, it needs access to information that in not in the
RTL at the point of the comparison, that informa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117207
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118541
--- Comment #7 from Segher Boessenkool ---
isgreater is not supposed to set floating point exception flags at all. So
whether the comparison resulted in unordered (i.e., one of the arguments was a
NaN) or not, isgreater should not set VXVC in p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118638
--- Comment #24 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #21)
> I certainly plan to backport it to those releases as well. But it is just
> latent there...
Where "latent" means "our testcases do not show problems" th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97786
--- Comment #6 from Segher Boessenkool ---
Hi Surya!
Hrm yes, xststdcdp _does_ return a sign bit as well. Do we currently say
that in RTL as well?
Unfortunately we cannot just follow an xststdcdp by a setb, setb tests bit 1,
but
the tdp sets b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117818
--- Comment #8 from Segher Boessenkool ---
We still support powerpc64-* just fine. And powerpc-linux (the 32-bit target)
is
tested just fine as well, and the community does support it. No one cares
_too_
much about it anymore, but why let it d
801 - 900 of 906 matches
Mail list logo
