https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #12 from Segher Boessenkool ---
Thanks. Unfortunately it isn't saying much more (well, during which
pass this happened, pretty important ;-) )
> I can prepare the preprocessed source tomorrow if needed.
Thanks! That will make repr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96907
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97019
--- Comment #1 from Segher Boessenkool ---
Cool, if that helps, great!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #20 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #18)
> > Why aren't KFmode, IFmode and TFmode all 128??? Mike?
>
> This comes from rs6000-modes.h:
>
> /* We order the 3 128-bit floating point types so that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #18 from Segher Boessenkool ---
I have a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
--- Comment #3 from Segher Boessenkool ---
Created attachment 49214
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49214&action=edit
proposed patch for the ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
Segher Boessenkool changed:
What|Removed |Added
Attachment #49214|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #19 from Segher Boessenkool ---
Created attachment 49215
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49215&action=edit
proposed patch for the ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #20 from Segher Boessenkool ---
Could you guys please test the attached patch? Thanks in advance!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
--- Comment #5 from Segher Boessenkool ---
So hrm, why did GCC generate lis 0x ; ori 0x ; rldicl instead of
li 0x ; oris 0x ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #26 from Segher Boessenkool ---
What Joseph says in c#25. Also, the documentation currently says
The @code{KIND} value matches the storage size in bytes, [...]
which will have to change, too (the standard does not require this,
it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
--- Comment #8 from Segher Boessenkool ---
(In reply to Alan Modra from comment #7)
> and of course, li 0x is li -1 which sets all bits.
Erm, yes. Duh.
So that g:5d3ae76af13 splitter should not fire for numbers that fit in
32 bits but that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2020-09-15
Status|UNCON
|NEW
CC||segher at gcc dot gnu.org
Last reconfirmed||2020-09-16
--- Comment #6 from Segher Boessenkool ---
Confirmed.
Maaybe cse2 should do this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710
--- Comment #16 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #15)
> Fixed.
Yes. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Segher Boes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #8 from Segher Boessenkool ---
I don't think we have an instruction for that? But we can inline the
code we need instead of doing a library call, which is much faster.
(We probably can use FMAs here usefully, btw; maybe even without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97163
--- Comment #3 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #2)
> Guess we need something like:
> -#elif defined(_ARCH_PWR8) && defined(__ALTIVEC__)
> +#elif (GCC_VERSION >= 4005) && defined(_ARCH_PWR8) && defined(__ALTIVEC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97163
--- Comment #5 from Segher Boessenkool ---
Yeah, good point.
So either we can convert to the normal intrinsics, or (much easier)
check we are building with GCC at all. But why 4.5? Do earlier
versions not work?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97163
--- Comment #7 from Segher Boessenkool ---
Ah.
Is there no better way to detect GCC impostors? Oh well.
Since we require 4.5 as bootstrap compiler, this makes no difference
at all for compilers that truthfully claim to be GCC, so it has my
ble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #13 from Segher Boessenkool ---
I don't see a patch there? If you have one, please attach it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #16 from Segher Boessenkool ---
Oh doh, I am blind, apparently :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89721
--- Comment #6 from Segher Boessenkool ---
Author: segher
Date: Thu Oct 17 19:51:01 2019
New Revision: 277131
URL: https://gcc.gnu.org/viewcvs?rev=277131&root=gcc&view=rev
Log:
Backport from trunk
2019-03-15 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89721
--- Comment #7 from Segher Boessenkool ---
Author: segher
Date: Thu Oct 17 19:52:55 2019
New Revision: 277132
URL: https://gcc.gnu.org/viewcvs?rev=277132&root=gcc&view=rev
Log:
Backport from trunk
2019-03-15 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89721
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||segher at gcc dot gnu.org
Resolution|--- |FIXED
Known to fail||7.4.0, 8.3.0, 9.2.0
--- Comment #3 from Segher Boessenkool ---
Fixed on trunk. This doesn't need a backport unless something that uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #11 from Segher Boessenkool ---
If an insn condition uses can_create_pseudo_p, the insn will suddenly stop
to match after reload --> kaboom.
If your insn always splits ("&& 1"), this means that if any of these:
NEXT_PASS (pass_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #18 from Segher Boessenkool ---
(In reply to Uroš Bizjak from comment #15)
> Is it possible to lift the limitation from the combine pass, where the
> combine tries to split the insn, but expects exactly two new insn patterns
> to be g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #20 from Segher Boessenkool ---
Ah, okay. So it is either one or two insns (zero can not be handled, but you
can do a noop, a move of a reg to itself, and that will be optimised away just
fine). Three insns is not something combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #22 from Segher Boessenkool ---
Hrm, I don't see how this is nicer than just adding a scratch in the
pattern? What makes that a worse option?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #24 from Segher Boessenkool ---
A dumb question I'm sure, but I don't see it: if the rest of your
define_insn doesn't need constraints, why would the match_scratch
need some? (A define_split never uses constraints).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #29 from Segher Boessenkool ---
(In reply to Uroš Bizjak from comment #27)
> FYI, these constraints were used in the past (when combine was allowed to
> propagate hard registers into combined insn) to prevent reload failures,
> where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92113
--- Comment #3 from Segher Boessenkool ---
I don't understand that Fortran code correctly, but it seems to me that
ARTIFICIAL code is the correct one, so you shouldn't have reverted this
patch, and that may just be a red herring even?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #21 from Segher Boessenkool ---
It will be fixed in the next releases of all still supported branches
(that's GCC 7, 8, and 9), and also in the upcoming GCC 10 release of
course.
If you are in a hurry, you can build your own compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #25 from Segher Boessenkool ---
There is no 9.2.1 release, and there will not be one either.
See https://gcc.gnu.org/develop.html for how our numbering scheme works.
Very briefly, if the second number is 0, or the third number is *no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92180
--- Comment #2 from Segher Boessenkool ---
Combine *does* combine setters of hard registers.
nonzero_bits is not reliable, it depends on the order things are tried in.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92180
--- Comment #4 from Segher Boessenkool ---
For x86 it may be because targetm.class_likely_spilled_p is true for ax, and
then indeed cant_combine_insn_p is true. See r53531, the mail thread for that
patch starts at https://gcc.gnu.org/ml/gcc-patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
--- Comment #14 from Segher Boessenkool ---
Author: segher
Date: Sat Oct 26 16:38:59 2019
New Revision: 277472
URL: https://gcc.gnu.org/viewcvs?rev=277472&root=gcc&view=rev
Log:
rs6000: Fix allocate_stack in a corner case (PR91289)
When we have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |ASSIGNED
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92218
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc64le-gnu-linux, |powerpc*
|powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287
--- Comment #8 from Segher Boessenkool ---
(In reply to gnzlbg from comment #7)
> > Note that the situation for zero-sized structs isn't very clear in
> > most ABIs, these included.
>
> This is incorrect: zero-sized types are well-defined and ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281
--- Comment #4 from Segher Boessenkool ---
(In reply to Richard Earnshaw from comment #2)
> Yes, but since
> (A - B) - C = A - B - C = A - C - B = (A - C) - B
> we can clearly swap the order of the two RHS operands here.
My intent was to show
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281
--- Comment #6 from Segher Boessenkool ---
(In reply to Richard Earnshaw from comment #5)
> What I've shown is equivalent to (minus (minus (A) (B)) (C)), which is what
> combine produces today. Are you saying that the documentation disagrees on
||2019-11-04
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Segher Boessenkool ---
(That is r271047; confirmed).
As the commit message says, with that patch we generate better code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342
--- Comment #7 from Segher Boessenkool ---
(In reply to Richard Earnshaw from comment #5)
> So if the AND-based idiom is now preferred, shouldn't the if-then-else
> variant be transformed into it?
Neither form is canonical currently.
The form y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342
--- Comment #8 from Segher Boessenkool ---
(In reply to Richard Earnshaw from comment #6)
> (In reply to Richard Earnshaw from comment #5)
> > So if the AND-based idiom is now preferred, shouldn't the if-then-else
> > variant be transformed into
||2019-11-04
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #5 from Segher Boessenkool ---
It needs -Os and -mcpu=power8 (or power9), too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090
--- Comment #6 from Segher Boessenkool ---
It also fails on GCC 9 (which needs additional -finline-functions --param
max-inline-insns-single=20), but not on GCC 8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090
--- Comment #7 from Segher Boessenkool ---
LRA creates
;; Insn is not within a basic block
(insn 7037 0 0 (set (reg:PTI 3703)
(const_wide_int 0x3ff0)) -1
(nil))
but that is not a valid insn.
This starte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
--- Comment #16 from Segher Boessenkool ---
Author: segher
Date: Tue Nov 5 17:17:03 2019
New Revision: 277855
URL: https://gcc.gnu.org/viewcvs?rev=277855&root=gcc&view=rev
Log:
backport for PR91289
Backport from trunk
2019-10-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
--- Comment #17 from Segher Boessenkool ---
Author: segher
Date: Tue Nov 5 17:20:00 2019
New Revision: 277856
URL: https://gcc.gnu.org/viewcvs?rev=277856&root=gcc&view=rev
Log:
backport for PR91289
Backport from trunk
2019-10-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #4 from Segher Boessenkool ---
Yes, you should use "wa".
Making our constraint (and output modifier) doc more useful is on my list
for GCC 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #5 from Segher Boessenkool ---
So:
-- LLVM should support "wa", since that is *the* constraint for VSX registers.
-- musl should use the "wa" constraint in its inline asm.
-- If after those two you still want "ws" (for compiling lega
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379
Segher Boessenkool changed:
What|Removed |Added
Priority|P3 |P5
--- Comment #1 from Segher Boess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379
--- Comment #3 from Segher Boessenkool ---
Sure. But it still is harmless, and a special build config.
Which isn't to say it shouldn't be fixed. But it isn't very high on
the list, that's all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342
--- Comment #10 from Segher Boessenkool ---
There are a gazillion ways to write this without if_then_else, none
obviously better than any other, and it gets much worse if your b,c
have special values.
I don't think this optimisation should be d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #7 from Segher Boessenkool ---
Then (In reply to nsz from comment #6)
> (In reply to Segher Boessenkool from comment #5)
> > -- LLVM should support "wa", since that is *the* constraint for VSX
> > registers.
> > -- musl should use the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92366
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92366
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #10 from Segher Boessenkool ---
(In reply to Rich Felker from comment #8)
> > Then LLVM has more to fix. Constraints never look at types. A register
> > constraint (like "wa") simply says what registers are valid.
>
> This is blate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #11 from Segher Boessenkool ---
(In reply to Rich Felker from comment #9)
> And ok, to be more productive rather than just angry about the regression,
> if you really think the "ws" constraint should be removed, what is the
> proper p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #15 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Segher Boessenkool from comment #10)
> > No, they are not. The constraints are an implementation detail. And
> > they *have* to be, or we co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #17 from Segher Boessenkool ---
(In reply to Rich Felker from comment #13)
> > That does not look at types. It complains that "x" lives in memory,
> > while the constraint requires a register (a floating point register).
>
> That do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #19 from Segher Boessenkool ---
(In reply to Rich Felker from comment #16)
> > Using "ws" in inline asm never made sense. It was always the same as
> > "wa", for all cases where either could be used in inline asm at all.
>
> It made
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #23 from Segher Boessenkool ---
(In reply to rsand...@gcc.gnu.org from comment #21)
> > I am saying it is a mistake that GCC ever documented this for public
> > use. Every use of "ws" in inline asm should be "wa".
>
> But it was a m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #26 from Segher Boessenkool ---
(In reply to Rich Felker from comment #24)
> > Sure, and I'll do that, *if there are users*, *after they fix their stuff*.
>
> Nothing is broken on our side here. We are using the documented
> function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #28 from Segher Boessenkool ---
(In reply to A. Wilcox (awilfox) from comment #25)
> GCC typically announces deprecations for publicly-documented interfaces
> being removed versions ahead of time, and I'm surprised that wasn't followe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #33 from Segher Boessenkool ---
(In reply to nsz from comment #31)
> (In reply to Segher Boessenkool from comment #28)
> > [ "ws" needs at least a Power7, btw. ]
>
> powerpc64le-* implies power8 and that's where this came up.
Does m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #31 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #29)
> Does it help the i386 port if we disallow a hard reg dest as well?
> RA should be able to handle that just fine as well.
I tried this out, and it cre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92433
--- Comment #5 from Segher Boessenkool ---
if (y)
{
gcc_assert (n == 3);
std::swap (arg_type[1], arg_type[2]);
}
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92449
--- Comment #3 from Segher Boessenkool ---
The first testcase has (at expand time)
if (_13 unord _14)
which doesn't mean anything with -ffast-math (-Ofast): unordered does
not *exist*.
The second testcase is similar, but we generate that unord
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92449
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=92464
--- Comment #2 from Segher Boessenkool ---
What is the testcase testing? Whether we can properly vectorize this
code, right? And for p7 we now do it correctly, but thought it was
too expensive before?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92449
--- Comment #7 from Segher Boessenkool ---
Author: segher
Date: Tue Nov 12 21:05:24 2019
New Revision: 278104
URL: https://gcc.gnu.org/viewcvs?rev=278104&root=gcc&view=rev
Log:
testsuite: Add testcases for PR92449
PR target/92449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92449
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92465
--- Comment #1 from Segher Boessenkool ---
-funroll-loops no longer implies -fweb and -frename-registers, for powerpc,
since those options hurt performance and never seem to help.
The testcase can be fixed by simply explicitly passing -fweb?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491
Segher Boessenkool changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80520
Bug 80520 depends on bug 80491, which changed state.
Bug 80491 Summary: [7 Regression] Compiler regression for long-add case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
Bug 79173 depends on bug 80491, which changed state.
Bug 80491 Summary: [7 Regression] Compiler regression for long-add case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80938
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83361
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
5c2bf77d1f6ae68d830c5157871089711a2a8eee (r278098) causes an ICE when building
the powerpc64 defconfig Linux kernel:
during GIMPLE pass: strlen
/home/segher/src/kernel/drivers/scsi/qla2xxx/qla_gs.c: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92532
--- Comment #2 from Segher Boessenkool ---
Please fix this soon. I think we still have the 48h rule?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86160
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92557
--- Comment #5 from Segher Boessenkool ---
We always have many modes we cannot put in registers at all. This is normal.
And yeah, what Richard says in c#3. Why do we do that? Is that a target bug?
arget
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
As mentioned in PR92557, at least we shouldn't return V2DImode for the
vector mode for DImode, if we do not actually support that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92557
--- Comment #7 from Segher Boessenkool ---
I opened PR92566 for that. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92549
--- Comment #6 from Segher Boessenkool ---
(In reply to Richard Biener from comment #2)
> But it looks like x86 has exactly patterns like this - but in this case
> I guess combine won't ever try this because hardregs are invovled
> (not sure if i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86160
--- Comment #3 from Segher Boessenkool ---
(In reply to jos...@codesourcery.com from comment #2)
> Generic (for some floating-point formats, and maybe not for 128-bit
> formats on 32-bit targets) bit-pattern is* were implemented by Tamar
> Chri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #8 from Segher Boessenkool ---
int f0(void) { return 0x == -1; }
int f1(unsigned x) { return x == -1; }
int f2(int y) { return 0x == y; }
int f3(unsigned x, int y) { return x == y; }
All of them warn the same, and th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566
--- Comment #3 from Segher Boessenkool ---
It should do something like
if (!VECTOR_UNIT_NONE_P (V2DImode))
return V2DImode;
and similar for all existing entries.
Putting the same conditionals in multiple places is prone to error, as
this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #13 from Segher Boessenkool ---
(In reply to Aleksey from comment #12)
> But adding these two flags "-fno-reorder-blocks-and-partition
> -fno-reorder-blocks"
If you say that basic blocks should not be reordered, then they
are not. A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92573
--- Comment #1 from Segher Boessenkool ---
Author: segher
Date: Wed Nov 20 13:38:52 2019
New Revision: 278497
URL: https://gcc.gnu.org/viewcvs?rev=278497&root=gcc&view=rev
Log:
rs6000: Fix UNORDERED without NaNs, for DFP (PR92573)
This is the a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92573
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566
--- Comment #5 from Segher Boessenkool ---
The whole function can be something as simple as
mode = mode_for_vector (mode, 16 / GET_MODE_SIZE (mode));
if (this is actually an existing mode
&& !VECTOR_UNIT_NONE (mode))
return mode;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785
--- Comment #15 from Segher Boessenkool ---
(In reply to Aleksey from comment #14)
> Performance is not the case here, so don't bother with it. Strict order of
> labels and using everywhere "jmp reg" instead of "jmp rel + jmp reg" - this
> is wha
201 - 300 of 3249 matches
Mail list logo
