https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120919
Bug ID: 120919
Summary: [14/15/16 Regression]
gcc.target/powerpc/builtin_altivec_tr_stxvr_runnable.c
fails with -fstack-protector-strong
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
In Fedora/RHEL we run testsuite with
RUNTESTFLAGS="--target_board=unix/'{,-fstack-protector-strong}'" and
gcc.target/powerpc/builtin_altivec_tr_stxvr_runnable.c
test added in r14-1501-g957798e44e7194f7b seems to pass without
-fstack-protector-strong but aborts with -fstack-protector-strong.
I'm not 100% sure what the builtins are supposed to do,
https://www.ibm.com/docs/en/openxl-c-and-cpp-lop/17.1.1?topic=functions-vec-xst-trunc
seems to say that they store some part of the vector at the last argument +
second argument.
The abort is already on the first abort:
int i;
signed long sl;
signed char sc, expected_sc;
signed short ss, expected_ss;
signed int si, expected_si;
signed long long int sll, expected_sll;
signed char *psc;
signed short *pss;
signed int *psi;
signed long long int *psll;
#if DEBUG
val.vsi128 = store_data;
printf("Data to store [%d] = 0x%llx %llx\n", i, val.ull[1], val.ull[0]);
#endif
psc = ≻
pss = &ss;
psi = &si;
psll = &sll;
sl = 1;
sc = 0xA1;
expected_sc = 0xA1;
__builtin_altivec_tr_stxvrbx (store_data, sl, psc);
if (expected_sc != sc & 0xFF)
#if DEBUG
printf(" ERROR: Signed char = 0x%x doesn't match expected value 0x%x\n",
sc & 0xFF, expected_sc);
#else
abort();
#endif
I believe and see the stxvrbx instruction to store one byte (0x17) at psc + sl,
i.e. &sc + 1.
In the -fno-stack-protector case it overwrites something unimportant, possibly
padding.
In the -fstack-protector-strong case, we are unlucky enough that &sc + 1 ==
&expected_sc (-O0, so
the var is in memory).
So, svxvrbx overwrites expected_sc and the comparison fails.
Looking at -fno-stack-protector test, the stxvrhx then overwrites 2 bytes at
pss + 1 byte to (0x17, 0x32)
and stxvrwx 4 bytes at psi + 1 byte to (0x17, 0x32, 0x54, 0x76).
So in all cases it invokes some undefined behavior, overwrites 1 random byte
after something.
