aboutsummaryrefslogtreecommitdiff
path: root/libstdc++-v3/testsuite/ext/is_heap
diff options
context:
space:
mode:
authorStefan Schulze Frielinghaus <stefansf@gcc.gnu.org>2025-07-08 16:40:34 +0200
committerStefan Schulze Frielinghaus <stefansf@gcc.gnu.org>2025-07-08 16:40:34 +0200
commitbb6075e7115208bab3d9c8b2c54e0bd6a5c808b7 (patch)
treea0900efaf76e5ba19981ff8c93ea2ce75045df3d /libstdc++-v3/testsuite/ext/is_heap
parenta543fcbb72f014f146f5804c963bb9dfd936e50b (diff)
downloadgcc-master.zip
gcc-master.tar.gz
gcc-master.tar.bz2
s390: Always compute address of stack protector guardHEADtrunkmaster
Computing the address of the thread pointer on s390 involves multiple instructions and therefore bears the risk that the address of the canary or intermediate values of it are spilled after prologue in order to be reloaded for the epilogue. Since there exists no mechanism to ensure that a value is not coming from stack, as a precaution compute the address always twice, i.e., one time for the prologue and one time for the epilogue. Note, even if there were such a mechanism, emitting optimal code is non-trivial since there exist cases with opposing requirements as e.g. if the thread pointer is not only computed for the TLS guard but also for other TLS objects. For the latter accesses it is desired to spill and reload the thread pointer instead of recomputing it whereas for the former it is not. gcc/ChangeLog: * config/s390/s390.md (stack_protect_get_tpsi): New insn. (stack_protect_get_tpdi): New insn. (stack_protect_set): Use new insn. (stack_protect_test): Use new insn. gcc/testsuite/ChangeLog: * gcc.target/s390/stack-protector-guard-tls-1.c: New test.
Diffstat (limited to 'libstdc++-v3/testsuite/ext/is_heap')
0 files changed, 0 insertions, 0 deletions