Jakub Jelinek <ja...@redhat.com> writes:
> On Tue, Mar 05, 2024 at 06:03:41PM +0000, Richard Sandiford wrote:
>> This patch makes the expansion of IFN_ASAN_MARK let through
>> poly-int-sized objects. The expansion itself was already generic
>> enough, but the tests for the fast path were too strict.
>>
>> Bootstrapped & regression tested on aarch64-linux-gnu. Is this OK
>> for trunk now, or should it wait for GCC 15? I'm not sure that it's
>> technically a regression, in the sense that we previously accepted the
>> testcase, but rejecting with an ICE is arguably worse than "sorry, can't
>> do that". And as noted in the PR, this bug is breaking numpy builds.
>>
>> Richard
>>
>>
>> gcc/
>> PR sanitizer/97696
>> * asan.cc (asan_expand_mark_ifn): Allow the length to be a poly_int.
>>
>> gcc/testsuite/
>> PR sanitizer/97696
>> * gcc.target/aarch64/sve/pr97696.c: New test.
>
> Ok for trunk now.
Thanks. (And thanks for the quick review.)
>
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/aarch64/sve/pr97696.c
>> @@ -0,0 +1,28 @@
>> +/* { dg-options "-fsanitize=address -fsanitize-address-use-after-scope" } */
>
> Though I'd say this test should require sanitize_address affective target.
> E.g. libsanitizer (sure, not actually used by the test) is only supported
> on aarch64*-*-linux*, not e.g. on darwin nor freebsd nor fuchsia etc.
Yeah, I'd wondered about that. But fsanitize_address is only available
in the asan.exp framework (or something else that includes asan-dg.exp).
And like you say, the test doesn't specifically need the library to
be available.
I guess the options are:
(1) Keep the test where it is, taking advantage of the current SVE
handling in aarch64-sve.exp, and add:
/* { dg-skip-if "" { no_fsanitize_address } } */
(2) Move the test to gcc.dg/asan/, make it conditional on aarch64*-*-*,
and add:
#pragma GCC target "+sve"
Any preference?
Actually running the test would require both libsanitizer support and
aarch64_sve_hw. Assembling it would need an assembler that understands SVE.
Richard
