[Bug sanitizer/91101] Possible performance regression in libasan with detect_stack_use_after_return=1

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91101

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #15)
> Seems systemd abuses compound literals even in cases where they make no
> sense, perhaps one of those in a short function like that is no longer
> optimized away completely and that is why it triggers all the
> __asan_malloc_0 calls in there where formerly it got away without that.
> E.g.
> #define assert_cc(expr)                                                 \
>         struct CONCATENATE(_assert_struct_, __COUNTER__) {              \
>                 char x[(expr) ? 0 : -1];                                \
> };
> doesn't make any sense to me, why not say
> do { extern char CONCATENATE(_assert_var_, __COUNTER__) [(expr) ? 0 : -1]; }
> while (0)
> instead?
> The IN_SET macro has another compound literal:
> assert_cc((sizeof((long double[]){__VA_ARGS__})/sizeof(long double)) <= 20);
> It would surprise me if you can't do such counting without resorting to
> compound literals.

As IN_SET is turning the __VA_ARGS__ arguments into case N:, those have to be
constant expressions, so you could say replace IN_SET's
assert_cc((sizeof((long double[]){__VA_ARGS__})/sizeof(long double)) <= 20);
with static long double __assert_in_set __attribute__((__unused__)) [] = {
__VA_ARGS__ };
assert_cc(sizeof (__assert_in_set)/sizeof(long double)) <= 20);
or similar, this is in its own scope, so doesn't need to use any __COUNTER__
etc.
With -O1 and above it would be surely optimized away, and with -O0 it would be
much less costly for asan.