https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
Bug 89863 depends on bug 106907, which changed state.
Bug 106907 Summary: gcc/config/rs6000/rs6000.cc:23155: strange expression ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106907
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106907
Jeevitha changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110320
Jeevitha changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110411
Jeevitha changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868
Jeevitha changed:
What|Removed |Added
CC||jeevitha at gcc dot gnu.org
--- Comment #8 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111045
Bug ID: 111045
Summary: PCREL should not be supported on BE ABI
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111045
Jeevitha changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111045
--- Comment #1 from Jeevitha ---
TARGET_PCREL was enabled on the Big Endian machine. However, the Big Endian ABI
does not support PCREL. Therefore, TARGET_PCREL needs to be disabled here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106438
--- Comment #5 from Jeevitha ---
Able to reproduce the error with a simple test case using the following
compilation and linking commands. The issue occurs whenever we pass different
ABIs during compilation and linking.
jeevitha@ltcden2-lp1 nb_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106438
--- Comment #6 from Jeevitha ---
Interestingly, the issue occurs only with _Float128 and not with __float128.
Here's the test case without the issue,
[jeevitha@ltcden2-lp1 nb_gcc_106438]$ cat t1.c
#include
typedef __float128 GFC_REAL_17;
vola
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106438
--- Comment #7 from Jeevitha ---
(In reply to Jeevitha from comment #5)
> jeevitha@ltcden2-lp1 nb_gcc_106438]$ cat t.c
> #include
>
> typedef _Float128 GFC_REAL_17;
>
> GFC_REAL_17 a;
> GFC_REAL_17 b;
> int main() {
> GFC_REAL_17 sum = a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109329
--- Comment #1 from Jeevitha ---
This test case requires a Power7 or above due to the ieeelongdouble ABI. The
test case includes "ppc_float128_sw", but this is not helpful. We can use the
target check "ppc_ieee128_ok" to verify IEEE support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865
Jeevitha changed:
What|Removed |Added
CC||jeevitha at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101345
--- Comment #3 from Jeevitha ---
> Jeevitha, can you please do a git bisect from the two commits above to
> identify the commit that fixes this for posterity sake? Thanks.
The commit that resolved the incorrect code was
ad5f8ac1d2f2dc92d43663
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113950
--- Comment #7 from Jeevitha ---
In GCC 11, we encountered a different issue that didn't result in an ICE.
The following is the error message in GCC 11:
error: too few arguments to function '__builtin_vsx_splat_2di'
11 | vsll_result = __
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113950
Jeevitha changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115242
Bug ID: 115242
Summary: libgcc unwinder does not handle vector registers, even
if the target machine supports them.
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115242
--- Comment #1 from Jeevitha ---
I am looking into this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
Jeevitha changed:
What|Removed |Added
CC||jeevitha at gcc dot gnu.org
--- Comment #8 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #27 from Jeevitha ---
Jakub's patch fixed the issue on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606
--- Comment #6 from Jeevitha ---
The ICE is happenning on the following insn at final_scan,
(insn 80 146 111 (set (reg:DI 28 28 [145])
(high:DI (unspec:DI [
(reg:DI 2 2)
] UNSPEC_TLSLD))) "test.ii":28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606
--- Comment #7 from Jeevitha ---
The following insns are dead at sched2, but not removed until pass_final, If
these instruction are removed there will be no ICE.
(insn 80 110 111 3 (set (reg:DI 28 28 [145])
(high:DI (unspec:DI [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606
--- Comment #9 from Jeevitha ---
(In reply to Segher Boessenkool from comment #8)
> What does "dead at sched2" mean? Are they dead when sched2 starts, or made
> dead
> by it? Well it must be the former; what pass does make it dead, then?
> sp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606
--- Comment #10 from Jeevitha ---
The following instructions [in basic block 4] were removed in sched2 DCE, which
makes r3 unused [populated in call_insn 26], but they were not deleted in this
pass itself:
(insn 28 26 29 4 (set (reg:DI 9 9 [132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110040
Bug ID: 110040
Summary: rs6000 port emits dead mfvsrd instruction for simple
test case
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110040
Jeevitha changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106907
Jeevitha changed:
What|Removed |Added
CC||jeevitha at gcc dot gnu.org
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106907
Jeevitha changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110606
--- Comment #11 from Jeevitha ---
Regarding the test case provided by Matthias Klose:
Within the AllocMemory() routine, the compiler aimed to eliminate the entire if
block but faced difficulties in removing references to the variable 'sMemPool'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110040
Jeevitha changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117207
--- Comment #1 from Jeevitha ---
In pr103515.c, we have two functions: foo1 and foo2. We have the #pragma GCC
optimize("O3,unroll-loops") directive for foo2. In the test suite, the
following checks are performed:
"The pragma specified for foo2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117207
Bug ID: 117207
Summary: gcc.target/powerpc/pr103515.c fail starting with
r15-4225-g70c3db511ba14f
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #16 from Jeevitha ---
Jonathan Wakely,
Unable to recreate the issue.
Tested on Power9 (RHEL 9.4) with GCC 14.1.0, GCC 13, and the trunk, using glibc
2.34, 2.35, and 2.36.
Tested on Power9 (SUSE 15) with the GCC trunk, using glibc 2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115242
--- Comment #2 from Jeevitha ---
Created attachment 59194
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59194&action=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115242
--- Comment #3 from Jeevitha ---
(In reply to Jeevitha from comment #2)
> Created attachment 59194 [details]
> testcase
To reproduce the issue using following option:
g++ -o out standalone_test.c -O1 -mvsx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118567
--- Comment #1 from Jeevitha ---
The following vectorization testcases are failing,
FAIL: gcc.target/powerpc/vsx-vectorize-1.c scan-tree-dump-times vect "Alignment
of access forced using versioning" 1
FAIL: gcc.target/powerpc/vsx-vectorize-2.c s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118541
Bug ID: 118541
Summary: Incorrect transformation to xscmpgtdp for Unordered
Operations
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118541
--- Comment #1 from Jeevitha ---
This issue arises from a glibc math function. Below is the discussion from the
glibc mailing list conversation between Florian and Adhemerval.
I saw this when building for POWER10 and it seems a compiler issue t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118541
--- Comment #3 from Jeevitha ---
(In reply to Florian Weimer from comment #2)
> This is about these glibc test suite failures, right?
>
Yes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118567
Bug ID: 118567
Summary: gcc.target/powerpc/vsx-vectorize-1.c fail starting
with r15-6807-g68326d5d1a593d
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119382
--- Comment #4 from Jeevitha ---
(In reply to Andrew Pinski from comment #2)
> Oh this is just a testsuite issue.
>
>
> `-fno-ipa-icf` is needed as now insert_di_0_v2 and insert_di_0 can figure
> out are the same function so insert_di_0_v2 bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119382
Bug ID: 119382
Summary: gcc.target/powerpc/vsx-builtin-7.c fail starting with
r15-7961-gdc47161c1f32c3
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119234
Jeevitha changed:
What|Removed |Added
CC||jeevitha at gcc dot gnu.org
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119862
Jeevitha changed:
What|Removed |Added
CC||jeevitha at gcc dot gnu.org
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119909
--- Comment #1 from Jeevitha ---
The test case failed as shown below:
FAIL: gcc.dg/torture/pr119131-1.c -O0 (test for excess errors)
FAIL: gcc.dg/torture/pr119131-1.c -O1 (test for excess errors)
FAIL: gcc.dg/torture/pr119131-1.c -O2 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119909
--- Comment #4 from Jeevitha ---
Created attachment 61178
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61178&action=edit
pr119131-1.c_test_log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119908
Bug ID: 119908
Summary: gcc.dg/torture/pr119131-1.c fails since
r15-7974-g0bbdffc5d4f723
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119909
Bug ID: 119909
Summary: gcc.dg/torture/pr119131-1.c fails since
r15-7974-g0bbdffc5d4f723
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119382
Jeevitha changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120598
--- Comment #6 from Jeevitha ---
The following dot_product function gets vectorized with the latest GCC trunk
and gcc 15.1.0:
#include
#include
extern float dot_product(const int16_t *v1, const int16_t *v2, size_t len);
float dot_product(cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119382
--- Comment #10 from Jeevitha ---
Right now, I have fixed this in trunk and plan to backport it to GCC 15.
It seems that patch dc47161c1f32c3 has been backported to the GCC 14 and 13
branches.
Can I backport the corresponding testcase fix also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119382
--- Comment #16 from Jeevitha ---
Backported to all affected branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118480
--- Comment #7 from Jeevitha ---
Now, in the following case, we run into issues whenever we use a splat constant
with vec_slo or vec_sll:
vui128_t
test_slqi_char_15_V1 (vui128_t vra)
{
vui8_t result;
vui8_t tmp = vec_splats((unsigned char)1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118480
--- Comment #6 from Jeevitha ---
For the following case:
vui8_t
test_splat7_char_18 ()
{
return vec_splats((unsigned char)18);
}
Assembly output:
test_splat7_char_18:
xxspltib 34,9
vaddubm 2,2,2
blr
The compiler generates xxsplti
54 matches
Mail list logo
