Hi, This is a resend of v4 with slightly adjusted commit messages:
v1: https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525016.html v2: https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525069.html v3: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548338.html v4: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549252.html It still survives the bootstrap and the regtest on x86_64-redhat-linux, s390x-redhat-linux and ppc64le-redhat-linux. It also fixes [1]. I also tried the approach with moving .LASANPC closer to the function label and using FUNCTION_BOUNDARY instead of introducing CODE_LABEL_BOUNDARY, but the problem there is that it's hard to catch the moment where the function label is written. Architectures can do it by calling ASM_OUTPUT_LABEL() or assemble_name() in ASM_DECLARE_FUNCTION_NAME(), ASM_OUTPUT_FUNCTION_LABEL() or TARGET_ASM_FUNCTION_PROLOGUE(). epiphany_start_function() does that twice, but passes the same decl to both calls. Note that simply moving asan_function_start() to final_start_function_1() is not enough, since an architecture can write something after the function label. This all means that for this approach to work, all the architectures need to be adjusted, which looks like an overkill to me. Best regards, Ilya [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593666.html Ilya Leoshkevich (2): asan: specify alignment for LASANPC labels IBM zSystems: Define CODE_LABEL_BOUNDARY gcc/asan.cc | 1 + gcc/config/s390/s390.h | 3 +++ gcc/defaults.h | 5 +++++ gcc/doc/tm.texi | 4 ++++ gcc/doc/tm.texi.in | 4 ++++ gcc/testsuite/gcc.target/s390/asan-no-gotoff.c | 15 +++++++++++++++ 6 files changed, 32 insertions(+) create mode 100644 gcc/testsuite/gcc.target/s390/asan-no-gotoff.c -- 2.37.2
