Re: [PATCH v3 1/7] Fix __libc_signal_block_all on sparc64

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 11/12/2019 11:06, Andreas Schwab wrote:
> On Dez 11 2019, Adhemerval Zanella wrote:
> 
>> It is a suggestion from Florian to use less stack usage since the
>> gcc with compound literal materialize the object on the stack; and
>> slight compat code on some architecture (where coping the compiler
>> create compound object might incur in a memcpy call).
> 
> It shouldn't do that for a const literal.

Well I am seeing such behaviour with gcc 9.2.1 on x86_64 at least:

$ cat sigmask.c
#include <signal.h>

#ifdef COMPOUND
#define sigall \
  ((const __sigset_t) { .__val = {[0 ...  _SIGSET_NWORDS-1 ] =  -1 } })
#else
static const sigset_t sigall = {
   .__val = {[0 ...  _SIGSET_NWORDS-1 ] =  -1 }
};
#endif

int foo (void)
{
  return sigprocmask (SIG_BLOCK, &sigall, 0);
}
$ x86_64-glibc-linux-gnu-gcc -O2 -std=gnu11 sigmask.c -S -o -
[...]
foo:
.LFB0:
        .cfi_startproc
        xorl    %edx, %edx
        movl    $sigall, %esi
        xorl    %edi, %edi
        jmp     sigprocmask
[...]
$ x86_64-glibc-linux-gnu-gcc -O2 -std=gnu11 sigmask.c -S -o - -DCOMPOUND
[...]foo:
.LFB0:
        .cfi_startproc
        subq    $136, %rsp
        .cfi_def_cfa_offset 144
        xorl    %edx, %edx
        xorl    %edi, %edi
        movq    %rsp, %rsi
        movq    $-1, (%rsp)
        [...]
        call    sigprocmask
        addq    $136, %rsp
[...]

Do you consider this a blocker? Should we use the compound literal? The
advantage of the static global is it slighter easier to define different
mask for the different ABI (64-bit, 32-bit, and mips with its outlier
number of signals).