[Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return

[sneves at dei dot uc.pt via Gcc-bugs]

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

Bug ID: 110027
   Summary: Misaligned vector store on
detect_stack_use_after_return
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sneves at dei dot uc.pt
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

(As reported by Jack O'Connor, along with reproducibility instructions, at
https://gist.github.com/oconnor663/69176654f1db1bb96077d6ff4141a022)

Given the following snippet,

  #include 

  int main() {
__m512i v = _mm512_set1_epi32(0);
// It doesn't really matter what we do next, as long as we convince the
// compiler to put v on the stack. Here we just read an int from it.
return *((int *));
  }

compiled with `gcc repro.c -g -mavx512f -fsanitize=address` results in a
segfault due to a misaligned AVX-512 store. The assembly output is visible at
https://gist.github.com/oconnor663/69176654f1db1bb96077d6ff4141a022#file-repro-s.
Specifically, we have the relevant sequence

  andq  $-64, %rsp
  subq  $192, %rsp
  leaq  32(%rsp), %rbx
  ...
  cmpl  $0, __asan_option_detect_stack_use_after_return(%rip)
  je.L1
  ...
  call  __asan_stack_malloc_1@PLT
  ...
  movq  %rax, %rbx
  ...
.L1:
  leaq  160(%rbx), %rax
  movq  %rax, %rcx
  ...
  vmovdqa64 %zmm0, -128(%rcx)

Now, if `__asan_option_detect_stack_use_after_return` is 0, the variable at
%rcx-128 is correctly aligned to 64. However, if it is 1, __asan_stack_malloc_1
returns something aligned to 64 << 1 (as per
https://github.com/gcc-mirror/gcc/blob/master/gcc/asan.cc#L1917) and adding 160
results in %rcx-128 being only aligned to 32. And thus the segfault.

Interestingly this seems to be only reproducible on Arch Linux. Other gcc
13.1.1 builds, Fedora for instance, seem to behave correctly. It is unclear to
me what the reason for this is.

[Bug target/105930] [12/13 Regression] Excessive stack spill generation on 32-bit x86

[sneves at dei dot uc.pt via Gcc-bugs]

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

--- Comment #13 from Samuel Neves  ---
Something simple like this -- https://godbolt.org/z/61orYdjK7 -- already
exhibits the effect. 

Furthermore, and this also applies to the full BLAKE2b compression function, if
you replace all the xors in the rounds by adds, the stack size goes back to
normal. 

On the other hand, replacing the adds by xors, making the whole round function
bitwise ops, does not have any effect on stack size.

[Bug target/105930] [12/13 Regression] Excessive stack spill generation on 32-bit x86

[sneves at dei dot uc.pt via Gcc-bugs]

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

Samuel Neves  changed:

   What|Removed |Added

 CC||sneves at dei dot uc.pt

--- Comment #6 from Samuel Neves  ---
Based on that bisect commit, it is also possible to repro this issue in earlier
GCCs (11, 10, seems fine on <= 9) purely by taking away the -mno-sseX, which
triggers the same splitting as now on gcc-12: https://godbolt.org/z/KEcWGT9Yc

[Bug c++/104802] New: Non-type template parameter of reference type disallowed under certain conditions

[sneves at dei dot uc.pt via Gcc-bugs]

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

Bug ID: 104802
   Summary: Non-type template parameter of reference type
disallowed under certain conditions
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sneves at dei dot uc.pt
  Target Milestone: ---

Minimal (C++17 and 20) example:

  template
  struct S {
template
void operator()() const {}
  };

  struct weird_ {
int operator&() const { return 123; }
  } const weird {};

  auto f() {
S s {};
s();
  }

This fails with the error:

  error: '&(const weird_&)weird.weird_::operator&()' is not a valid template
argument of type 'const weird_&' because '(const
weird_&)weird.weird_::operator&()' is not a variable

Now, if either one of

  - template is commented out, i.e., the called function is no
longer a template;

  - `weird` has the `operator&` removed;

The code compiles without any issues.

As far as I can tell this example is not violating any of the constraints the
standard puts on lvalue reference parameters, and both Clang and MSVC accept
it.