[Bug target/113950] PowerPC, ICE with -O1 or higher compiling __builtin_vsx_splat_2di test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113950 Jeevitha changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jeevitha --- Fixed, and all backports are done.
[Bug target/113950] PowerPC, ICE with -O1 or higher compiling __builtin_vsx_splat_2di test case
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 = __builtin_vsx_splat_2di (sll_arg1); // ISSUE The error indicated a shortage of arguments for the built-in function. It expects two arguments because the function prototype is different in GCC 11 compared to GCC 12, 13, and 14. I have found that the commit responsible for changing the function prototype was made by Bill Schmidt (commit hash: d08236359eb22918ba067489edcec02857109d09). In this commit, he introduced new built-in functionality, where the function prototype is sourced from rs6000-builtin-new.def, which includes the following declaration: const vsll __builtin_vsx_splat_2di (signed long long); Prior to this commit ie, in gcc11, the function prototype was sourced from rs6000-builtin.def and included two arguments: /* 2 argument VSX builtins. */ BU_VSX_2 (SPLAT_2DI, "splat_2di", CONST, vsx_splat_v2di) These changes are controlled by the setting new_builtins_are_live. Bill made this change in his commit by adjusting this setting. Due to the above prototype changes, we are not backporting to GCC 11.
[Bug target/101345] wrong code at -O1 with vector modulo
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
ad5f8ac1d2f2dc92d43663243b52f9e9eb3cf7c0, where Bill disabled the swap for mult
with subreg. This addressed the issue.
The reason behind this change is as follows:
The input for the swap pass is,
insn 23 set r144, vec_concat(r152,r160)
insn 26 set r162, r237*(r144+0)
insn 27 set r163, (r144+8)*r236
insn 29 set r166, r236*(r144+0)
insn 30 set r167, subreg(r236*(r144+0),8)
Output from swap pass is,
insn 23 set r144, vec_concat(r160,r152)
insn 26 set r162, r237*(r144+8)
insn 27 set r163, (r144+0)*r236
insn 29 set r166, r236*(r144+8)
insn 30 set r167, subreg(r236*(r144+8),0)
In the provided sample code, multiplication operations are performed. Here, the
SUBREG_BYTE changes in pseudo 144 are correct. However, the change from 8 to 0
in the SUBREG_BYTE of MULT(r236,r144) is incorrect. This alteration leads to
treating it as a low-part multiply ie, similar to insn 29, whereas it should
actually a high-part multiply. Therefore, Bill stopped the swap for mult with
subreg case, which resolves this issue.
To provide clear reference, here is the RTL for insn 30 in failure case:
(insn 30 29 31 2 (set (reg:DI 167)
(subreg:DI (mult:TI (zero_extend:TI (reg:DI 236))
- (zero_extend:TI (subreg:DI (reg:V2DI 144) 0))) 8))
"test1.c":13:5 166 {umuldi3_highpart_le} //input from swap pass
+ (zero_extend:TI (subreg:DI (reg:V2DI 144) 8))) 0))
"test1.c":13:5 166
{umuldi3_highpart_le} //output from swap pass
[Bug rtl-optimization/96865] ICE in hash_rtx_cb, at cse.c:2548
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865
Jeevitha changed:
What|Removed |Added
CC||jeevitha at gcc dot gnu.org
--- Comment #1 from Jeevitha ---
The issue was in the following RTL,
(insn 6 2 21 2 (parallel [
(set (reg:SI 96 lr)
(unspec:SI [
(symbol_ref:SI ("_GLOBAL_OFFSET_TABLE_") [flags 0x42])
(label_ref 0)
] UNSPEC_TOCPTR))
(code_label 0 0 0 2 (nil) [2 uses])
]) "test.c":6:6 798 {load_toc_v4_PIC_1b_normal}
The above RTL will generate the following assembly:
bcl 20,31,$+8
There is no need for 'label_ref 0' and 'code_label' in the RTL instruction, as
the assembly does not require them. Is my understanding correct?
Currently, we are encountering an ICE due to the following reason: In the
'hash_rtx' function [cse.cc], handling for 'LABEL_REF' is present but not for
'code_label', causing it to not return a hash directly. Instead, it searches
for the format corresponding to '(code_label 0 0 0 4 (nil))', which is
"uuB00is". In the provided code snippet below, 'B' and 'u' do not have case
handling, leading to a 'gcc_unreachable'. This is the reason for the ICE
currently.
fmt = GET_RTX_FORMAT (code); //code -> code_label
for (; i >= 0; i--)
{
switch (fmt[i])
{
case 'e':
/* If we are about to do the last recursive call
needed at this level, change it into iteration.
This function is called enough to be worth it. */
if (i == 0)
{
x = XEXP (x, i);
goto repeat;
}
hash += hash_rtx (XEXP (x, i), VOIDmode, do_not_record_p,
hash_arg_in_memory_p,
have_reg_qty, cb);
break;
case 'E':
for (j = 0; j < XVECLEN (x, i); j++)
hash += hash_rtx (XVECEXP (x, i, j), VOIDmode, do_not_record_p,
hash_arg_in_memory_p,
have_reg_qty, cb);
break;
case 's':
hash += hash_rtx_string (XSTR (x, i));
break;
case 'i':
hash += (unsigned int) XINT (x, i);
break;
case 'p':
hash += constant_lower_bound (SUBREG_BYTE (x));
break;
case '0': case 't':
/* Unused. */
break;
default:
gcc_unreachable ();
}
}
To address this, I've removed 'operand1' and adjusted the respective
'match_dup' to 'operand0' in the below pattern.
(define_insn "load_toc_v4_PIC_1b_normal"
[(set (reg:SI LR_REGNO)
(unspec:SI [(match_operand:SI 0 "immediate_operand" "s")
(label_ref (match_operand 1 "" ""))]
UNSPEC_TOCPTR))
(match_dup 1)]
After implementing the mentioned change, there were no ICEs or regressions. Is
this approach correct?
[Bug target/112868] GCC passes -many to the assembler for --enable-checking=release builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868 Jeevitha changed: What|Removed |Added CC||jeevitha at gcc dot gnu.org --- Comment #8 from Jeevitha --- Created attachment 57584 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57584=edit Removed -many from the options passed by default to the assembler. Sam James, can you do a practice distro build using this patch?
[Bug target/110411] ICE on simple memcpy test case when allowing generation of vector pair load/store insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110411 Jeevitha changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jeevitha --- Fixed
[Bug target/110320] ELFv2 pc-rel ABI extension allows using r2 as a volatile register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110320 Jeevitha changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jeevitha --- Fixed
[Bug target/106907] gcc/config/rs6000/rs6000.cc:23155: strange expression ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106907 Jeevitha changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #11 from Jeevitha --- Fixed
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
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 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu
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'.
The corresponding source code is as follows:
if (sMemPool) {
__trans_tmp_2 = operator new(AllocMemory_size);
return __trans_tmp_2;
}
void *ptr = operator new(AllocMemory_size);
return ptr;
The subsequent details are pertaining to the body of if statement [BB5], which
includes a 'mov' [insn 35] for "AllocMemory_size" and a 'call' [insn 36] for
"operator new." Furthermore, regarding the code after the if body [BB6], there
was another 'mov' [insn 43] and 'call' [insn 44], similar to those in BB5.
Before SCHED1:
--
BB5:
insn 35 set r3, r124
insn 36 call [`operator new`] -> Uses r3,r2
...
insn 78 jump L47
L41:
BB6:
insn 43 set r3, r124
insn 44 call [`operator new`] -> Uses r3,r2
...
L47:
BB7:
insn 49 set r5, 0
insn 50 set r4, 1
During the 'sched1' pass, a reordering occurred that moved insn 35 before insn
31 from BB5 to BB4. BB4 contains the check for the 'sMempool' variable [insn
33]: if it's zero, there's a branch to label 41, leading to BB6; otherwise, it
continues with BB5.
After SCHED1:
-
BB3:
insn 80 set r145, high(unspec[r2])
insn 81 set r139, r145+low(unspec[r2])'
BB4:
insn 72 set r3, r139
insn 23 set r124, [r138]
insn 26 call [`__tls_get_addr`] -> Uses r3,r2
insn 75 set r142, r3
insn 28 set r132, unspec[r142, symbol_ref: `_ZL8sMemPool`]
insn 29 set r130, unspec[r132, symbol_ref: `_ZL8sMemPool`]
insn 35 set r3, r124
insn 31 set r133, [r130]
insn 32 set r134, cmp(r133, 0)
insn 33 set pc, { (r134 == 0) ? L41 : pc }
BB5:
insn 36 call [`operator new`] -> Uses r3,r2
...
insn 78 jump L47
L41:
BB6
insn 43 set r3, r124
insn 44 call [`operator new`] -> Uses r3,r2
...
L47:
BB7:
insn 49 set r5, 0
insn 50 set r4, 1
In the 'Jump2' pass, the compiler successfully removed the if body (bb5)
consisting of insn 36 and insn 78. However, it couldn't remove insn 35, which
was moved to bb4. Additionally, it changed insn 43 to be in bb6 and moved the
remaining instructions from insn 44 to bb10. As insn 43 and insn 35 are similar
instructions, insn 43 was chosen for deletion in the later pass.
After JUMP2:
---
BB3:
insn 80 set r28[orig:r145], high(unspec[r2])
insn 81 set r28[orig:r139], r28[orig:r145]+low(unspec[r2])'
BB4:
insn 32 set cr0[orig:r134], cmp(r9[orig:r133], 0)
insn 33 set pc, { (cr0[orig:r134] == 0) ? L41 : pc }
BB5:
insn 134 set pc, L133
L41:
BB6:
insn 43 set r3, r30[orig:r124]
L133:
BB10:
insn 44 call [`operator new`] -> Uses r3,r2
insn 49 set r5,0
insn 50 set r4, 1
In cprop_hardreg pass, insn 43 in BB6 is removed
After cprop_hardreg:
BB3:
insn 80 set r28, high(unspec[r2])
insn 81 set r139, r28+low(unspec[r2])'
BB4:
insn 72 set r3, r28[orig:r139]
insn 23 set r30[orig:r124], r27[orig:r138]
insn 26 call [`__tls_get_addr`] -> Uses r3,r2
insn 28 set r9[orig:r132], unspec[r3[orig:r142],symbol_ref: `_ZL8sMemPool']
insn 29 set r9[orig:r130], unspec[r9[orig:r132],symbol_ref: `_ZL8sMemPool']
insn 35 set r3, r30[orig:r124]
insn 31 set r9[orig:r133], [r9][orig:r130]
insn 32 set cr0[orig:r134], cmp(r9[orig:r133], 0)
insn 33 set pc, { (cr0[orig:r134] == 0) ? L41 : pc }
BB5:
insn 134 set pc, L133
L41:
BB6:
L133:
BB10:
insn 44 call [`operator new`] -> Uses r3,r2
insn 49 set r5,0
insn 50 set r4, 1
Following the removal of insn 43 in the 'cprop_hardreg' pass, both insn 134 and
33 became unnecessary due to jumping to the same location, which was removed in
the basic block reordering pass.
After BBRO:
---
BB3:
...
insn 80 set r28, high(unspec[r2])
insn 81 set r28, r28+low(unspec[r2])'
...
BB4:
insn 72 set r3, r28
insn 23 set r30, r27
insn 26 call [`__tls_get_addr`] -> Uses r3,r2
insn 28 set r9, unspec[r3,`_ZL8sMemPool']
insn 29 set r9, unspec[r9,`_ZL8sMemPool']
insn 35 set r3, r30
insn 31 set r9, [r9]
insn 32 set cr0, cmp(r9, 0)
insn 44 call [`operator new`] -> Uses r3,r2
insn 49 set r5,0
insn 50 set r4, 1
...
Upon the removal of these jumps, instructions 32, 31, 29, and 28 in bb4 became
dead, since r9, r3 were used for those jumps. During 'sched2 DCE,' those
instructions in BB4 were removed, rendering r3 unused (which was populated in
insn 26). However, its not deleted in this pass:
After SCHED2:
BB3:
...
insn 80 set r28, high(unspec[r2])
insn 81 set r28, r28+low(unspec[r2])'
...
BB4:
insn 23 set r30, r27
insn 72 set r3, r28
insn 26 call [`__tls_get_addr`] -> Uses r3,r2
insn 35 set r3, r30
insn 44 call [`operator new`] -> Uses r3,r2
insn 49 set r5,0
insn 50 set r4, 1
...
...
The flag 'df_in_progress' is avoiding the call deletion in 'sched2 DCE'. If the
insn 26 is removed, insn 72 can be removed. Consequently, below
[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu
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])
(unspec:DI [
(reg:DI 3 3 [142])
(symbol_ref:DI ("_ZL8sMemPool") [flags 0x1a] )
] UNSPEC_TLSDTPRELHA)) "test.cc":27:7 740 {tls_dtprel_ha_64}
(expr_list:REG_DEAD (reg:DI 3 3 [142])
(nil)))
(insn 29 28 35 4 (set (reg:DI 9 9 [130])
(unspec:DI [
(reg:DI 9 9 [132])
(symbol_ref:DI ("_ZL8sMemPool") [flags 0x1a] )
] UNSPEC_TLSDTPRELLO)) "test.cc":27:7 741 {tls_dtprel_lo_64}
(nil))
(insn 31 35 32 4 (set (reg/f:DI 9 9 [orig:133 sMemPool ] [133])
(mem/f/c:DI (reg:DI 9 9 [130]) [1 sMemPool+0 S8 A64])) "test.cc":27:3
683 {*movdi_internal64}
(nil))
(insn 32 31 44 4 (set (reg:CC 100 0 [134])
(compare:CC (reg/f:DI 9 9 [orig:133 sMemPool ] [133])
(const_int 0 [0]))) "test.cc":27:3 799 {*cmpdi_signed}
(expr_list:REG_DEAD (reg/f:DI 9 9 [orig:133 sMemPool ] [133])
(nil)))
The following are the instructions that were not removed in sched2 DCE because
they are avoiding call deletion [call_insn 26] with this flag [df_in_progress].
(insn 72 23 53 4 (set (reg:DI 3 3)
(reg:DI 28 28 [139])) "test.cc":27:7 683 {*movdi_internal64}
(nil))
(call_insn/u 26 53 35 4 (parallel [
(set (reg:DI 3 3)
(call (mem:SI (symbol_ref:DI ("__tls_get_addr") [flags 0x41]
) [0 S4 A8])
(unspec:DI [
(reg:DI 2 2)
] UNSPEC_TLSLD)))
(use (const_int 0 [0]))
(clobber (reg:DI 96 lr))
]) "test.cc":27:7 776 {*call_value_nonlocal_aixdi}
(expr_list:REG_UNUSED (reg:DI 3 3)
(expr_list:REG_CALL_DECL (symbol_ref:DI ("__tls_get_addr") [flags 0x41]
)
(expr_list:REG_EH_REGION (const_int -2147483648
[0x8000])
(nil
(expr_list (use (reg:DI 2 2))
(expr_list (use (reg:DI 3 3))
(nil
Here, call_insn 26 becomes dead after deleting insn 28, but it is not removed.
If call_insn 26 is removed, insn 72 can be removed. If insn 72 is removed, the
following insns in basic block 3 can also be removed:
(insn 80 136 81 3 (set (reg:DI 28 28 [145])
(high:DI (unspec:DI [
(reg:DI 2 2)
] UNSPEC_TLSLD))) "test.cc":27:7 737 {*tls_ld_high64}
(expr_list:REG_EQUIV (high:DI (unspec:DI [
(reg:DI 2 2)
] UNSPEC_TLSLD))
(nil)))
(insn 81 80 54 3 (set (reg:DI 28 28 [139])
(lo_sum:DI (reg:DI 28 28 [145])
(unspec:DI [
(reg:DI 2 2)
] UNSPEC_TLSLD))) "test.cc":27:7 738 {*tls_ld_low64}
(expr_list:REG_DEAD (reg:DI 2 2)
(nil)))
Currently, we are encountering an ICE in insn 80 and 81. These two instructions
are dead but remain unremoved until the final pass. They are attempting to
retrieve a symbol that was present in insn 28, yet this insn has already been
removed in sched2.
When allowing sched2 to process call deletion, it successfully removed
call_insn/u 26 and insn 72 in bb4, but not insn 80 and 81 because live
registers are not updated for bb3 in same pass. It requires another DCE, but
our GCC does not have DCE after sched2.
[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu
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?
> split3
> apparently? Why is this not done in split2 already, any good reason?
Its latter, dead after sched2, DCE was happened in sched2 which removes the
uses of reg 3,
The following is the insn removed in sched2,
(insn 28 26 29 4 (set (reg:DI 9 9 [132])
(unspec:DI [
(reg:DI 3 3 [142])
(symbol_ref:DI ("_ZL8sMemPool") [flags 0x1a] )
] UNSPEC_TLSDTPRELHA)) "test.cc":27:7 740 {tls_dtprel_ha_64}
(expr_list:REG_DEAD (reg:DI 3 3 [142])
(nil)))
This makes the following insn unused, There was nouse of register 3 after this.
call_insn/u 26 53 35 4 (parallel [
(set (reg:DI 3 3)
(call (mem:SI (symbol_ref:DI ("__tls_get_addr") [flags 0x41]
) [0 S4 A8])
(unspec:DI [
(reg:DI 2 2)
] UNSPEC_TLSLD)))
(use (const_int 0 [0]))
(clobber (reg:DI 96 lr))
]) "test.cc":27:7 776 {*call_value_nonlocal_aixdi}
[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references on powerpc64le-linux-gnu
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 [
(reg:DI 2 2)
] UNSPEC_TLSLD))) "test.cc":27:7 737 {*tls_ld_high64}
(expr_list:REG_EQUIV (high:DI (unspec:DI [
(reg:DI 2 2)
] UNSPEC_TLSLD))
(nil)))
(insn:TI 81 106 54 3 (set (reg:DI 28 28 [139])
(lo_sum:DI (reg:DI 28 28 [145])
(unspec:DI [
(reg:DI 2 2)
] UNSPEC_TLSLD))) "test.cc":27:7 738 {*tls_ld_low64}
(expr_list:REG_DEAD (reg:DI 2 2)
(nil)))
(insn 72 23 53 4 (set (reg:DI 3 3)
(reg:DI 28 28 [139])) "test.cc":27:7 683 {*movdi_internal64}
(nil))
call_insn/u 26 53 35 4 (parallel [
(set (reg:DI 3 3)
(call (mem:SI (symbol_ref:DI ("__tls_get_addr") [flags 0x41]
) [0 S4 A8])
(unspec:DI [
(reg:DI 2 2)
] UNSPEC_TLSLD)))
(use (const_int 0 [0]))
(clobber (reg:DI 96 lr))
]) "test.cc":27:7 776 {*call_value_nonlocal_aixdi}
(expr_list:REG_UNUSED (reg:DI 3 3)
(expr_list:REG_CALL_DECL (symbol_ref:DI ("__tls_get_addr") [flags 0x41]
)
(expr_list:REG_EH_REGION (const_int -2147483648
[0x8000])
(nil
(expr_list (use (reg:DI 2 2))
(expr_list (use (reg:DI 3 3))
(nil
[Bug target/110606] ICE output_operand: '%&' used without any local dynamic TLS references 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:7 737 {*tls_ld_high64}
(expr_list:REG_EQUIV (high:DI (unspec:DI [
(reg:DI 2 2)
] UNSPEC_TLSLD))
(nil)))
It was unable to parse the operand "%&" in the following instruction for above
RTL.
"addis %0,%1,%&@got@tlsld@ha"
For the operand "%&" tries to retrive some local-dynamic symbol in that
function but it return null. This happened because that function lost its
symbol(it was dead insn and removed from split3). Unfortunately the reference
are not removed, those instruction are unused but not eliminated which results
in error.
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 --- Comment #27 from Jeevitha --- Jakub's patch fixed the issue on powerpc64le-linux-gnu
[Bug bootstrap/111601] [14 Regression] bootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 Jeevitha changed: What|Removed |Added CC||jeevitha at gcc dot gnu.org --- Comment #8 from Jeevitha --- When I disable thread-jumps for cp/call.cc:splice_viable. There is no bootstrap fail. thread-jumps optimisation was enabled in O2 level.
[Bug target/111045] PCREL should not be supported on BE ABI
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.
[Bug target/111045] PCREL should not be supported on BE ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111045 Jeevitha changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-08-17
[Bug target/111045] New: PCREL should not be supported on BE ABI
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 Assignee: unassigned at gcc dot gnu.org Reporter: jeevitha at gcc dot gnu.org Target Milestone: ---
[Bug target/106907] gcc/config/rs6000/rs6000.cc:23155: strange expression ?
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 Jeevitha --- Static analyser cppcheck says: gcc/config/rs6000/rs6000.cc:7668:16: style: Redundant initialization for 'new_addr'. The initialized value is overwritten before it is read. [redundantInitialization] new_addr = gen_rtx_PLUS (Pmode, XEXP (mem, 0), elt); ^ rs6000.cc:7663:20: note: new_addr is initialized rtx new_addr = gen_reg_rtx (Pmode); ^ rs6000.cc:7668:16: note: new_addr is overwritten new_addr = gen_rtx_PLUS (Pmode, XEXP (mem, 0), elt); ^ In above issue new_addr was initialized at line no : 7663 which was overwritten before it reads at line no : 7668
[Bug target/106907] gcc/config/rs6000/rs6000.cc:23155: strange expression ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106907 Jeevitha changed: What|Removed |Added CC||jeevitha at gcc dot gnu.org --- Comment #4 from Jeevitha --- (In reply to Andreas Schwab from comment #3) > Should probably be written as swapped != !BYTES_BIG_ENDIAN. I bootstrapped and regtest there is no regression with this change.
[Bug target/110040] rs6000 port emits dead mfvsrd instruction for simple test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110040 Jeevitha changed: What|Removed |Added Target Milestone|--- |14.0 CC||bergner at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jeevitha at gcc dot gnu.org Keywords||missed-optimization Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-05-30 Ever confirmed|0 |1 Target||powerpc64le-linux --- Comment #1 from Jeevitha --- I am working on this.
[Bug target/110040] New: rs6000 port emits dead mfvsrd instruction for simple test case
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
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jeevitha at gcc dot gnu.org
Target Milestone: ---
GCC Trunk generates a dead mfvsrd for the following test case.
[jeevitha@ltcden2-lp1 ~]$ cat bug.c
#include
void
foo (signed long *dst, vector signed __int128 src)
{
*dst = (signed long) src[0];
}
[jeevitha@ltcden2-lp1 ~]$ gcc bug.c -O2 -mcpu=power9 -S -o bug.s
[jeevitha@ltcden2-lp1 ~]$ cat bug.s
.file "bug.c"
.machine power9
.abiversion 2
.section".text"
.align 2
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
mfvsrd 11,34 #dead instruction
mfvsrld 10,34
std 10,0(3)
blr
