On 21/03/2025 14:06, Matthew Malcomson wrote: > On 3/20/25 15:03, Alex Coplan wrote: > > External email: Use caution opening links or attachments > > > > > > On 20/03/2025 14:31, Alfie Richards wrote: > > > Hello, > > > > > > This is a cherry pick of 20385cb92cbd4a1934661ab97a162c1e25935836 which > > > didn't apply cleanly > > > so needed a very minor edit to for it to apply for GCC 12 and 13. > > > > > > Regtested and bootstrapped for gcc-13 on aarch64-linux-gnu. > > > > > > This applies cleanly to gcc-12 but there is a regression for > > > `c-c++-common/hwasan/large-aligned-1.c`. > > > > > > The output of execution was > > > > > > ``` > > > ==2242916==ERROR: HWAddressSanitizer: tag-mismatch on address > > > 0xfffffffff680 at pc 0xfffff780e08c > > > READ of size 4 at 0xfffffffff680 tags: 02/01(00) (ptr/mem) in thread T0 > > > #0 0xfffff780e08c in SigTrap<2> > > > ../../../../src/libsanitizer/hwasan/hwasan_checks.h:28 > > > ``` > > > > > > and has changed to > > > > > > ``` > > > ==2242927==ERROR: HWAddressSanitizer: tag-mismatch on address > > > 0xfffffffff690 at pc 0xfffff780e08c > > > READ of size 4 at 0xfffffffff690 tags: 02/00 (ptr/mem) in thread T0 > > > #0 0xfffff780e08c in SigTrap<2> > > > ../../../../src/libsanitizer/hwasan/hwasan_checks.h:28 > > > ``` > > > > > > Note the difference in the tags. > > > > > > Does anyone with experience of HWAddressSanitizer know what caused this > > > and if it's an issue? > > > > Yeah, I ran into this too in the past when testing GCC 12 backports. > > I think those hwasan tests are flaky due to the dg-output checks being > > overly strict. Martin Liska pushed a fix to GCC 13 to relax them > > (r13-100-g3771486daa1e904ceae6f3e135b28e58af33849). I think that patch > > needs backporting to the GCC 12 branch, which I requested here: > > https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645278.html but > > that backport request was never ACKed. I still think we should backport > > it. > > Just for context: From having a look at the output on my local machine it > seems that for some reason the stack layout has been changed after this > patch so that the order of the naturally aligned and artificially aligned > objects are different. That has meant that the access past the end of the > naturally aligned object hits something different. > > I'm honestly a bit baffled about why this patch would change the stack > layout. > > So agree this is a flaky test, and not demonstrating a problem with the > relevant patch. I'm still really surprised that it happened.
FWIW, ISTR when I investigated this previously that the same test binary on the same machine would flip-flop between failing and passing based on e.g. the current working directory at the time the test was run, so it seems minor changes in the environment are enough to affect the stack layout in this way. Thanks, Alex > > > > > Alex > > > > > > > > Kind regards, > > > Alfie Richards > > > > > > > > > Andrew Carlotti (1): > > > aarch64: Use PAUTH instead of V8_3A in some places > > > > > > gcc/config/aarch64/aarch64.cc | 6 +++--- > > > gcc/config/aarch64/aarch64.md | 8 ++++---- > > > 2 files changed, 7 insertions(+), 7 deletions(-) > > > > > > -- > > > 2.34.1 > > > >
