https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101528
--- Comment #7 from Carl Love ---
I recently committed a patch to fix the counts.
commit 5d336ae49528fde3904c9e5bfc83a450429b2961
Author: Carl Love
Date: Fri Mar 10 18:16:52 2023 -0500
rs6000: Fix test int_128bit-runnable.c instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101528
Carl Love changed:
What|Removed |Added
CC||cel at us dot ibm.com
--- Comment #6 from
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cel at us dot ibm.com
Target Milestone: ---
On PowerPC, the address of the buffer to return non-trivial values such as
structures is passed in register r3. The value of r3 on entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101022
Carl Love changed:
What|Removed |Added
CC||cel at us dot ibm.com
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98092
--- Comment #2 from Carl Love ---
Segher:
Yup, I saw the buzilla. Will take a look at it.
Carl
On Fri, 2021-01-22 at 18:49 +, segher at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98092
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449
Carl Love changed:
What|Removed |Added
CC||cel at us dot ibm.com
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85830
--- Comment #4 from Carl Love ---
Just remove
#define vec_popcntb __builtin_vec_vpopcntub
#define vec_popcnth __builtin_vec_vpopcntuh
#define vec_popcntw __builtin_vec_vpopcntuw
#define vec_popcntd __builtin_vec_vpopcntud
from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85830
--- Comment #2 from Carl Love ---
Hit the save button a little too fast missed putting in everything I intended
to put in. Lets try to get it all in.
(In reply to Carl Love from comment #1)
> The Power 64-Bi ELF V2 ABI specification revision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85830
Carl Love changed:
What|Removed |Added
CC||cel at us dot ibm.com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93819
Carl Love changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #8 from Carl Love ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93819
Carl Love changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91638
Carl Love changed:
What|Removed |Added
CC||cel at us dot ibm.com
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91638
--- Comment #6 from Carl Love ---
Yea, I like that a bit better. It is a bit shorter, mine was a bit verbose.
I updated the patch to print:
-mlong-double- Use -mlong-double-64 for 64-bit IEEE floating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91638
--- Comment #4 from Carl Love ---
Created attachment 47982
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47982=edit
patch to update -mlong-double-NN description
Attached the proposed patch so I will not lose it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91638
Carl Love changed:
What|Removed |Added
CC||cel at us dot ibm.com
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93819
--- Comment #2 from Carl Love ---
With the attached patch, the test program now runs as follows:
ABI says:
VEC_RLNM (ARG1, ARG2, ARG3)
ARG2 contains the shift count for each element in the low-order
byte, with other bytes zero.
ARG3 contains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93819
--- Comment #1 from Carl Love ---
Created attachment 47873
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47873=edit
Patch to fix vec_vrlnm() functionality
The issue with the vec_rlnm() builtin is the order of the arguments in the
builtin
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cel at us dot ibm.com
Target Milestone: ---
Created attachment 47872
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47872=edit
test program to demonstrate the bug.
The API for the PPC 64 vec_rlnm() builtin s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206
--- Comment #11 from Carl Love ---
Created attachment 47626
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47626=edit
311r.dwarf2 file for v4si and the v2di test case
The attached file was generated with the #if in the test program set to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206
--- Comment #10 from Carl Love ---
Created attachment 47625
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47625=edit
310r.nothrow for both tests v4si and v2di
The attached file was generated with the #if in the test program set to 1 to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206
--- Comment #9 from Carl Love ---
Created attachment 47624
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47624=edit
311r.dwarf2 file for just the v2di test case
The attached file was generated with the #if in the test program set to 0 so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206
--- Comment #8 from Carl Love ---
Created attachment 47623
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47623=edit
310r.nothrow for just the __builtin_vec_foo_v2di test case
The attached file was generated with the #if in the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206
--- Comment #5 from Carl Love ---
I am puzzled. When we have both test cases included which are identical other
then the data size, the notes are correct for second test case but not the
first test case. When we remove the first test case,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93206
--- Comment #3 from Carl Love ---
The initial bug report states that the bug moves around depending on the test
case. If the test case only consists of the test for the V2DI case, you get
the error that Bill was specifically stating, i.e.
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cel at us dot ibm.com
Target Milestone: ---
Created attachment 47616
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47616=edit
GCC src tree pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84371
--- Comment #2 from Carl Love ---
Will:
Here is the bug report I just got from Peter. From our sametime
conversation sounds like you have addressed these in a recent update.
Take a look, may be that Peter needs to update his tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81158
--- Comment #2 from Carl Love ---
On Thu, 2017-06-22 at 21:06 +, wschmidt at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81158
>
> --- Comment #1 from Bill Schmidt ---
> I expect this is probably due to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79039
--- Comment #2 from Carl Love ---
On Tue, 2017-01-10 at 14:29 +, wschmidt at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79039
>
> Bill Schmidt changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68752
--- Comment #4 from Carl Love ---
I do not seem to have permission to change the status of the bug.
Anton, can you recheck the issue and close if you agree it is no longer an
issue. Thanks.
Carl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68752
--- Comment #3 from Carl Love ---
I investigated the issue using GCC 6.1. The t1() function from file
recip-vec-sqrtf.c file is as follows:
void t1(void)
{
int i;
for (i = 0; i < 4; i++)
r[i] = a[i] / sqrtf (b[i]);
}
The assembly code being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68752
Carl Love changed:
What|Removed |Added
CC||cel at us dot ibm.com
--- Comment #2 from
31 matches
Mail list logo
