https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99921
Bug ID: 99921
Summary: PowerPC xxeval has the wrong predicates
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98952
Michael Meissner changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100166
Bug ID: 100166
Summary: Some vold-vec-{load,store} tests fail when built with
compiler configured with --with-cpu=power10
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100167
Bug ID: 100167
Summary: GCC configured for power10 fails the
gcc.target/powerpc/fold-vec-div-longlong.c test
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100168
Bug ID: 100168
Summary: Test gcc.dg/pr56727-2.c fails on power10 code
generation
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100169
Bug ID: 100169
Summary: Test gcc.dg/sms-10.c fails on power10
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100166
--- Comment #1 from Michael Meissner ---
The test gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c also fails
because it needs to add prefixed instruction support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100166
--- Comment #2 from Michael Meissner ---
gcc.target/powerpc/lvsl-lvsr.c is another test that needs prefixed load/store
support added.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100170
Bug ID: 100170
Summary: Gcc tests gcc.target/powerpc/ppc-{eq,ne}0-1.c fail on
Power10
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
--- Comment #5 from Michael Meissner ---
One of my patches for adding IEEE 128-bit long double may help with this
situation. The ibm-ldouble.c module was not being compiled with
-mno-gnu-attributes would affect things if a different long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
--- Comment #7 from Michael Meissner ---
Just to be clear, my patch only turns on -mno-gnu-attributes on compiling
ibm-ldouble.c. That is the module that has the extended IBM 128-bit support in
it.
However, I believe if any module in libgcc_s.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
--- Comment #8 from Michael Meissner ---
In addition to ibm-ldouble.c, the following functions set the gnu attribute #4
to 5 (i.e. pass/use IBM extended double as long double):
_divtc3
_fixtfdi
_fixunstfdi
_floatditf
_floatunditf
_multc3
_powitf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Michael Meissner changed:
What|Removed |Added
Last reconfirmed||2020-11-03
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #4 from Michael Meissner ---
You need the patch that fixes PR libgcc/97543, which is another side of the
same coin. PR 97543 was about making long double default to 64-bits, PR 97643
is about making long double default to IEEE 128-bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97791
Bug ID: 97791
Summary: GNU attributes for long double could be improved on
PowerPC
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #22 from Michael Meissner ---
When I wrote the original in power7 days, the intent was:
If the user said -mcpu=power7 (for 32-bit) and did not explicitly set either
-mabi=altivec or -mabi=no-altivec, that -mabi=altivec would be set
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #2 from Michael Meissner ---
That fell off the plate. I imagine we are going to need a hook with asm that
makes sure none of the memory references are PC-relative.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #9 from Michael Meissner ---
I agree with Segher. Given the 'magic' we need to add the missing 'p' and set
the length for normal RTL, I don't see any reasonable way to add it to asm. We
will just need to use a hook (or make one) to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #15 from Michael Meissner ---
FWIW, the hook that will need to be modified is rs6000_md_asm_adjust in
rs6000.c. It appears you are passed the outputs, the inputs, the constraints,
and the clobbers. Right now, we just mark the CA reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98645
Bug ID: 98645
Summary: C++ modules support does not work on PowerPC with IEEE
128-bit long double
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98645
Michael Meissner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Bug 97653 depends on bug 97543, which changed state.
Bug 97543 Summary: powerpc64le: libgcc has unexpected long double in
.gnu_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Michael Meissner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98873
Bug ID: 98873
Summary: PowerPC test
gcc.target/powerpc/ppc-fortran/ieee128-math.f90 now
fails
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98873
Michael Meissner changed:
What|Removed |Added
Target||powerpc64le-gnu-linux
Bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98874
Bug ID: 98874
Summary: PowerPC test
gcc.target/powerpc/ppc-fortran/pr80108-1.f90 uses
wrong dg-options
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98870
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #21 from Michael Meissner ---
I have patches that fix the problem in the hook.
My original idea of not allowing prefixed insns in the hook doesn't work
because when the hook is called, it only sees pseudo registers.
So what my patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
Michael Meissner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
Michael Meissner changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|meissner at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #23 from Michael Meissner ---
Obviously one approach is to use the recog_data.is_asm field to determine if
the %m constraint is in an asm and restrict it to non-prefixed memory
addresses.
However, this doesn't work, because is_asm is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #24 from Michael Meissner ---
Obviously I had a small typo in the previous example (using %U0%X0 instead of
%U1%X1) which did not matter, but here is the corrected example:
static int x;
int *p_x = &x;
int get (void)
{
int a;
__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #25 from Michael Meissner ---
Created attachment 50201
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50201&action=edit
Example code for both input and output %m usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99133
Bug ID: 99133
Summary: Power10 xxspltiw, xxspltidp, xxsplti32dx instructions
need to be marked as prefixed
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99133
--- Comment #1 from Michael Meissner ---
Note, the comment should read:
Note unlike the load/store/paddi instructions, these prefixed instructions do
NOT have a 'p' prefix, which means the code in rs6000_final_prescan_insn will
have to be modifie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99133
Michael Meissner changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98952
Michael Meissner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100327
Michael Meissner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100327
--- Comment #5 from Michael Meissner ---
Unfortunately the patch does not work because there aren't suffixes for IFmode
and KFmode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100327
Michael Meissner changed:
What|Removed |Added
Attachment #50708|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100327
Michael Meissner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100166
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99921
Michael Meissner changed:
What|Removed |Added
Last reconfirmed||2021-05-04
Assignee|unassig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100167
Michael Meissner changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100170
Michael Meissner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100712
Bug ID: 100712
Summary: The vec_splatid instruction allows the creation of
XXSPLTIDP instructions which produces undefined
results.
Product: gcc
Version: 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96762
Michael Meissner changed:
What|Removed |Added
Last reconfirmed||2021-05-27
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96762
--- Comment #2 from Michael Meissner ---
It is in the memcpy expansion, when the compiler tries to generate lxvl and
stxvl to do the move. Unfortunately, the pattern in the expansion does a
DImode shift left by 56 to get the value into the corre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100809
Michael Meissner changed:
What|Removed |Added
Last reconfirmed||2021-06-01
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100809
--- Comment #4 from Michael Meissner ---
Note, in looking at Carl's patch, it is only for adding the built-ins. I don't
believe it adds direct support for {,u}divti3 and {,u}moddti3 to implement
these for normal __int128 variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100168
Michael Meissner changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100809
Michael Meissner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99293
--- Comment #3 from Michael Meissner ---
Created attachment 50947
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50947&action=edit
Proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99293
Michael Meissner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
Bug ID: 101002
Summary: Some powerpc tests fail with -mlong-double-64
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101019
Bug ID: 101019
Summary: GCC should consider using PLI/SLDI/PADDI to load up
64-bit constants on power10
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101019
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101019
Michael Meissner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
Bug ID: 108623
Summary: We need to grow the precision field in
tree_type_common for PowerPC
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #4 from Michael Meissner ---
I must have missed the spare bits. I think it is better to use the full 16
bits for precision. I also think your other changes to realign bit fields
greater than 1 bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
Michael Meissner changed:
What|Removed |Added
Last reconfirmed||2023-02-01
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #7 from Michael Meissner ---
Created attachment 54387
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54387&action=edit
Proposed patch combining Richard's patch and an assertion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108958
Bug ID: 108958
Summary: Powerpcle could generate mtvsrdd for zero extend DI to
TI mode, when the TImode is in a vector register
Product: gcc
Version: 13.0
Status: UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109067
Bug ID: 109067
Summary: Powerpc GCC does not support __ibm128 complex
multiply/divide if long double is IEEE 128-bit.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104256
Michael Meissner changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
Michael Meissner changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104698
Bug ID: 104698
Summary: Inefficient code for DI to TI sign extend on power10
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104698
--- Comment #3 from Michael Meissner ---
It goes beyond 'just use RTL'.
The problem is the code only generates an altivec instruction. So if the
__int128_t value is in a GPR, the compiler will need to do a move to the vector
registers (1 insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253
Michael Meissner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868
--- Comment #4 from Michael Meissner ---
In looking at it, the reason is the convert from DImode to TImode has several
constraints. The constraint that matters in this case has the output being an
Altivec register, while the input is a GPR regi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868
Michael Meissner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868
--- Comment #8 from Michael Meissner ---
Matheus, try the patch I just attached to the PR that I posted to the
gcc-patches mailing list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
Michael Meissner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101169
Michael Meissner changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106680
Bug ID: 106680
Summary: Test gcc.target/powerpc/bswap64-4.c fails on 32-bit BE
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106681
Bug ID: 106681
Summary: Powerpc test gcc.dg/pr104992.c fails on power10
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106682
Bug ID: 106682
Summary: Powerpc test
gcc.target/powerpc/pr86731-fwrapv-longlong.c fails on
power8, passes on power9/power10
Product: gcc
Version: unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345
Michael Meissner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103763
Michael Meissner changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103763
--- Comment #1 from Michael Meissner ---
Created attachment 52141
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52141&action=edit
Patch to fix the insn count
Update the insn regex for power10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102935
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102935
--- Comment #2 from Michael Meissner ---
Created attachment 52143
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52143&action=edit
Patch to update code generation test
The test wants to load all 1's into a vector register. On power8 it u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102935
Michael Meissner changed:
What|Removed |Added
Attachment #52143|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102935
Michael Meissner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104136
Bug ID: 104136
Summary: Gcc cannot compile wrf_r for power10 using -Ofast
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104136
Michael Meissner changed:
What|Removed |Added
Priority|P3 |P1
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104136
--- Comment #1 from Michael Meissner ---
Created attachment 52244
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52244&action=edit
Patch to mark XXSPLTIW and XXSPLTIDP as possibly being prefixed
If you compile module_advect_em.F90 with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104136
Michael Meissner changed:
What|Removed |Added
Attachment #52244|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104136
Michael Meissner changed:
What|Removed |Added
Attachment #52246|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104136
--- Comment #5 from Michael Meissner ---
Fixed in commit f9063d12633c62a089115df032a19295854d8b06 on January 21, 2022.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104136
Michael Meissner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103763
Michael Meissner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253
Michael Meissner changed:
What|Removed |Added
Last reconfirmed||2022-01-26
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253
--- Comment #4 from Michael Meissner ---
Created attachment 52306
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52306&action=edit
Patch to use the correct names for __ibm128 converts if long double is IEEE
128-bit
The problem was interna
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253
Michael Meissner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104124
--- Comment #3 from Michael Meissner ---
There are two things going on.
1) There is no vspltisd instruction, so we can't generate a single instruction
to load constants other than 0 or -1. Unfortunately, this was not added in
either power9 or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253
--- Comment #8 from Michael Meissner ---
Yes, you are right. I didn't remember which functions were generated by the
compiler, but I just did all of the conversion functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253
Michael Meissner changed:
What|Removed |Added
Attachment #52306|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253
--- Comment #11 from Michael Meissner ---
The patch has been posted, I'm awaiting approval.
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589469.html
BTW, the copy_to_mode_reg bug I mentioned earlier goes away with the patch.
1 - 100 of 173 matches
Mail list logo
