https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #13 from Segher Boessenkool ---
(In reply to Bill Schmidt from comment #11)
> As I mentioned privately, we could do with an audit of our implementation of
> standard patterns in general, since we tend to find such missing cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #12 from Segher Boessenkool ---
When is the lowering done currently? Only for the ops that have no other way
of doing, and things are merged back to an __int128 immediately after that?
If that is what is going on, then that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #9 from Segher Boessenkool ---
(In reply to Richard Biener from comment #7)
> > I still think it would be best if Gimple did *never* split data. It
> > simply does not know enough about the machine and what the eventual
> > machine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #8 from Segher Boessenkool ---
Btw:
> mfvsrd 9,34
> mfvsrld 8,34
> mfvsrd 11,35
> mfvsrld 10,35
> li 7,1
> cmpd 0,9,11
> bgt 0,.L2
> cmpld 0,9,11
> beq 0,.L5
> .L3:
> li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #6 from Segher Boessenkool ---
Ah, now I see. Thanks!
Power10 has some new 128-bit insns (and p9 and p8 did before, too).
I still think it would be best if Gimple did *never* split data. It
simply does not know enough about the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #2 from Segher Boessenkool ---
Do you maybe have some simple example (of what we generate, and what you say
it should be)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
--- Comment #8 from Segher Boessenkool ---
So it seems to think that all registers in the preferred class,
GEN_OR_VSX_REGS,
are the same cost? They very much are not :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
--- Comment #6 from Segher Boessenkool ---
Not only is this a missed-optimization, it also is a regression (in GCC 10
already). It seems like the root cause here may be the same as in PR102169.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103251
--- Comment #2 from Segher Boessenkool ---
It makes results not reproducable. It is a bug in the test. It is good to
have the pid in the testcase output somewhere of course, just not in the
summary.
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
TSAN testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87656
--- Comment #9 from Segher Boessenkool ---
(In reply to Eric Gallager from comment #8)
> Any reason not to put -Wnested-externs in -Wall or -Wextra?
It warns for any "extern" declaration in other than file scope. This is
completely standard C,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2021-11-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103051
--- Comment #10 from Segher Boessenkool ---
(In reply to Martin Liška from comment #9)
> All right, so something like this should work, right?
>
> diff --git a/gcc/testsuite/gcc.dg/vect/tsvc/vect-tsvc-s112.c
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103004
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103004
--- Comment #5 from Segher Boessenkool ---
Bah, I typoed the PR id:
commit 8d71d3a317236ab4a69f441cf867a43aeb448150
Author: Raphael Moreira Zinsly
Date: Thu Nov 11 11:40:10 2021 -0300
libgcc: Fix backtrace fallback on PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103051
--- Comment #8 from Segher Boessenkool ---
Note that the -mcpu= in use can be set by compiler defaults as well (which
can be set at build time, --with-cpu=), or commonly in RUNTESTFLAGS (to test
a bunch of different -mcpu= settings at the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103051
--- Comment #7 from Segher Boessenkool ---
(In reply to Martin Liška from comment #4)
> Shouldn't the function check_effective_target_has_arch_pwr7 pass
> -mcpu=native?
No. It checks if the effective target (set by options elsewhere!) is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103124
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2021-11-10
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453
--- Comment #3 from Segher Boessenkool ---
Splitters run after all RTL transforms, so anything that can be done on the
split result has to be done manually. This does not scale. Splitters are
not suitable for this kind of thing.
You can do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
--- Comment #15 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #14)
> (In reply to Martin Liška from comment #13)
> > Created attachment 51668 [details]
> > Patch candidate
> >
> > Please test the patch on a power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102440
--- Comment #9 from Segher Boessenkool ---
(In reply to Martin Liška from comment #8)
> > We could make the "UInteger" type mean it is implemented with an "unsigned
> > int"
> > C type (or some other unsigned integer type).
>
> This would lead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
--- Comment #8 from Segher Boessenkool ---
Created attachment 51664
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51664=edit
proposed patch
This is the patcgh I am currently testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102440
--- Comment #7 from Segher Boessenkool ---
The documentation for UInteger also says
Positive values of the argument in
excess of @code{INT_MAX} wrap around zero.
so C "unsigned" types are natural for it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102440
--- Comment #6 from Segher Boessenkool ---
(In reply to Martin Liška from comment #5)
> All right, so the meaning of the UInteger type is actually that users can't
> set the flag/param to a negative value:
>
> $ gcc -fabi-version=-3 a.c
> gcc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
--- Comment #4 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #1)
> The stvx stuff is guarded by #ifdef __VEC__, so perhaps the lvx stuff should
> be too, or there should be .machine push; .machine power7; ... .machine pop;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783
--- Comment #8 from Segher Boessenkool ---
(In reply to jos...@codesourcery.com from comment #6)
> Generically (and if the command-line options are such that floating-point
> control / status bits are to be respected by optimizations), *any*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783
--- Comment #7 from Segher Boessenkool ---
(In reply to Richard Biener from comment #5)
> Even out-of-line does not help if there are visible CSE/association
> opportunities across such call.
Yeah, good point.
> A workaround is to make the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102767
--- Comment #6 from Segher Boessenkool ---
(In reply to Richard Earnshaw from comment #5)
> We have the type
> type size
> unit-size
> and movmisalign pattern is enabled for this.
>
> but the vectorization cost doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2021-10-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
--- Comment #14 from Segher Boessenkool ---
(In reply to Patrick McGehearty from comment #13)
> I may be mistaken about the source of the issue being glibc.
> Perhaps it is a system include file issue? Here are some
> more details.
>
> Here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
--- Comment #12 from Segher Boessenkool ---
(In reply to Patrick McGehearty from comment #8)
> My challenge is that the very old glibc on gcc135.fsffrance.org
> does not know about _TF_ vs _KF_ and _IF_. It refused to
> build the new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485
--- Comment #5 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #4)
> (In reply to Segher Boessenkool from comment #3)
> > (In reply to Paul Clarke from comment #2)
> > > "-many" is supposed to make those black boxes just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485
--- Comment #3 from Segher Boessenkool ---
(In reply to Paul Clarke from comment #2)
> GCC putting the base ".machine" directive at the beginning of the file makes
> any command-line use of "-many" (-Wa,-many) be ignored. Is that OK?
If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85730
--- Comment #7 from Segher Boessenkool ---
(In reply to Richard Biener from comment #5)
> Not sure whether targets should have a special-case pattern here or whether
> that's for combine to un-canonicalize it?
Is the shift defined anywhere as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102169
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94428
--- Comment #3 from Segher Boessenkool ---
(In reply to Martin Sebor from comment #1)
> With the introduction of -Wzero-length-bounds in GCC 10 (which,
> incidentally, was added specifically to ease the adoption of the stricter
> array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102140
--- Comment #4 from Segher Boessenkool ---
Confirmed. Doesn't need -mlittle or -mabi=elfv2, or -mcpu=power8 even, but
does need -mvsx.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107
--- Comment #22 from Segher Boessenkool ---
Backported to 11 and 10. Not doing GCC 9; the problem is older than that,
and the backport wouldn't be completely trivial. Paul, please close if
everything is okay now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306
--- Comment #8 from Segher Boessenkool ---
The patch in c#5 looks good. Since you test added_sets_0 and added_sets_1
as well, does this mean it could happen before this patch as well?
We already did have some things that did combine 2->2 (via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102306
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185
--- Comment #12 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #11)
> as mentioned in another bug, this is more of a documentation issue and the
> internal details on how inline-asm works.
Yup. I suggest we advice to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #27 from Segher Boessenkool ---
(In reply to Hongtao.liu from comment #22)
> > Btw, I think this is a subreg that would be reasonable to handle.
> > It's exactly the kind that x86 would like to allow, (subreg:HF (reg:SI
> > ..) 0).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #26 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #24)
> > The expander should never create such code in the first place, it is
> > premature
> > optimisation! At expand time this should be separate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #23 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #21)
> > /home/seurer/gcc/git/gcc-test/libgo/go/strconv/atof.go:704:1: error:
> > unrecognizable insn:
> > 704 | func parseFloatPrefix(s string, bitSize
,
||segher at gcc dot gnu.org
--- Comment #6 from Segher Boessenkool ---
(In reply to Jim Wilson from comment #4)
> Yes, moving SI/DI values to FP regs is OK. However, RISC-V requires that FP
> values in FP registers be stored NaN-boxed. So an SFmode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #20 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #18)
> So I wonder if it makes sense to allow lowpart subregs of any mode when
> the inner mode is integer.
We really really really should make a separate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2021-09-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #17 from Segher Boessenkool ---
(In reply to Hongtao.liu from comment #15)
> as discussed in
> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578437.html, allow
> specific float-int subreg seems weird.
Indiscriminately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #19 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #17)
> The Version about is to 10.2, does that mean we're going to back port this
> to the release branches, or are we calling it good with trunk?
This is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #18 from Segher Boessenkool ---
+/* { dg-final { scan-assembler-not {(?n)\mb.*fmod} } } */
+/* { dg-final { scan-assembler-not {(?n)\mb.*fmodf} } } */
+/* { dg-final { scan-assembler-not {(?n)\mb.*remainder} } } */
+/* { dg-final {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65584
--- Comment #7 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #6)
> And the "somehow" is now possible too, we can use __has_include().
Including it with -ffreestanding in effect is always wrong. Even if the header
exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65584
--- Comment #4 from Segher Boessenkool ---
Since you closed PR102231 (which has a lot more detail), let me paste
that here:
includes unconditionally
Instead, it should do something like
#if __STDC_HOSTED__
#include
#endif
as Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65584
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
Instead, it should do something like
#if __STDC_HOSTED__
#include
#endif
as Clang does, because only exists on hosted environments
(which is good, because it itself uses , etc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107
--- Comment #16 from Segher Boessenkool ---
(Hopefully) fixed on trunk, but it needs backports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #25 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #24)
> (In reply to Segher Boessenkool from comment #23)
> > Anyway, patch in testing.
>
> Did your patch fix the problem or do we need to take another run at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #14 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #13)
> (In reply to luoxhu from comment #12)
> > Patch submitted:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568143.html
>
> Looks like Will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102154
--- Comment #14 from Segher Boessenkool ---
(In reply to Jonathan Wakely from comment #13)
> Is this also the cause of several libstdc++ FAILs on ppc64le?
Yes.
I have asked for reversion of g:d2874d905647:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107
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=102107
--- Comment #13 from Segher Boessenkool ---
/* If we need to save CR, put it into r12 or r11. Choose r12 except when
r12 will be needed by out-of-line gpr save. */
cr_save_regno = ((DEFAULT_ABI == ABI_AIX || DEFAULT_ABI == ABI_ELFv2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #16 from Segher Boessenkool ---
(In reply to wschmidt from comment #14)
> I disagree with that. You should use __VSX__ && _ARCH_PWR9 to check for
> P9 vector support, etc. The __POWERn_VECTOR__ things really are not
> great and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #15 from Segher Boessenkool ---
(In reply to HaoChen Gui from comment #9)
> For this example, let's suppose that we set mcpu=power8 and mno-vsx in the
> command line. Thus, _ARCH_PWR8 should be defined as mcpu=power8. But if the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107
--- Comment #10 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #9)
> So that is something older from the GCC 11 branch, aha.
And I cannot reproduce it with anything that has been on the GCC 11 branch,
either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107
--- Comment #9 from Segher Boessenkool ---
So that is something older from the GCC 11 branch, aha.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102062
--- Comment #15 from Segher Boessenkool ---
This should be fixed now, please confirm. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102127
--- Comment #4 from Segher Boessenkool ---
Program received signal SIGSEGV, Segmentation fault.
0x10f9b10c in ._Z19build_function_typeP9tree_nodeS0_ ()
(gdb) bt
#0 0x10f9b10c in ._Z19build_function_typeP9tree_nodeS0_ ()
#1
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=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=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=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
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=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
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
>
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
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
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
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
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
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
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
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=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=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)
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
FAIL: gcc.target/powerpc/sse4_1-phminposuw.c (test for excess errors)
Excess errors:
/home/segher/build/tot-master/gcc/include/smmintrin.h:103:3: error: AltiVec
argument passed to unprototyped
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Segher Boessenkool ---
Confirmed. I'll take it.
|NEW
CC||segher at gcc dot gnu.org
Last reconfirmed||2021-08-11
--- Comment #1 from Segher Boessenkool ---
Confirmed.
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=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
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
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
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
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
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
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
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=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:
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
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
501 - 600 of 3154 matches
Mail list logo
