[Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return
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
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
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
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.
[Bug c++/68495] Error when expanding nontype variadic argument in trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68495
--- Comment #1 from Samuel Neves ---
Minimal example can be further reduced to
template struct int_seq {};
constexpr struct {
constexpr int operator()(int x) const { return x + 1; }
} f1 {};
template
auto f2(F f, int_seq) -> int_seq {
return {};
}
int main() {
f2(f1, int_seq<0>{});
}
This suggests that the issue is with GCC not recognizing that `f::operator()`
is constexpr; this information is seemingly lost somewhere along the way.
[Bug c++/68495] New: Error when expanding nontype variadic argument in trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68495
Bug ID: 68495
Summary: Error when expanding nontype variadic argument in
trailing return type
Product: gcc
Version: 5.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 example, works on Clang and MSVC but fails to compile on every GCC
version since 4.7:
template struct int_seq {};
constexpr struct {
constexpr int operator()(int x) const { return x + 1; }
} f1 {};
template
auto f2(F f, int_seq) -> int_seq<f(As)...> {
return {};
}
int main() {
f2(f1, int_seq<0, 1, 2, 3>{});
}
Replacing `int_seq<f(As)...>` by `int_seq<f1(As)...>` in the return type causes
the snippet to compile successfully.
[Bug c++/66923] New: Variable template initialized using auto deduces wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66923
Bug ID: 66923
Summary: Variable template initialized using auto deduces wrong
type
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sneves at dei dot uc.pt
Target Milestone: ---
Consider the following sample:
templateint struct S {};
templateint N
constexpr auto V = SN{};
// constexpr SN V{}; // This works
templatetypename T
auto f(T) {
return V(
#if defined(TRIGGER_ERROR)
(void)T(),
#endif
0);
}
int main() {
f(0);
}
If TRIGGER_ERROR is defined, the definition of V is dependent on the deduced
type T. In this case, GCC will seemingly deduce that the type of Vint is T:
error: cannot convert 'S0' to 'const int' in initialization
constexpr auto V = SN{};
When V's parameter does not depend on T, the program compiles as expected. This
affects GCC 5.x and 6.x in C++14 mode.
[Bug c++/64931] New: ICE on function with deduced return type and input is instantiated template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64931
Bug ID: 64931
Summary: ICE on function with deduced return type and input is
instantiated template class
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sneves at dei dot uc.pt
Minimal example:
templatetypename T, unsigned long N
struct array {
T data[N];
};
auto copy(arrayint, 32 const x) {
return x;
}
This only seems to result in ICE if a) `copy` has deduced return type with
value semantics, i.e. `auto` but not `decltype(auto)`, and b) if the `array`
struct is a template, and `copy` takes in a specific instantiation of `array`.
Verified to ICE in GCC 4.8.2, 4.9.2, and 5.0.0 20150202.
[Bug c++/64562] New: Member functions with r-value reference for *this and deduced return type incorrectly rejected as ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64562
Bug ID: 64562
Summary: Member functions with r-value reference for *this and
deduced return type incorrectly rejected as ambiguous
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sneves at dei dot uc.pt
Consider the following program:
#include iostream
#define RETURN_TYPE auto
namespace {
struct S {
RETURN_TYPE operator--() {
return 1;
}
RETURN_TYPE operator--() const {
return 2;
}
RETURN_TYPE operator--() {
return 3;
}
RETURN_TYPE operator--() const {
return 4;
}
};
const S callme() { return {}; }
auto f1() {
return --S();
}
auto f2() {
return --callme();
}
auto f3() {
S s;
return --s;
}
auto f4() {
const S s {};
return --s;
}
}
int main() {
std::cout f1() ;
std::cout f2() ;
std::cout f3() ;
std::cout f4() std::endl;
}
The expected output would be 1 2 3 4. When RETURN_TYPE is defined to be
int, this is the result obtained. GCC (versions ranging from 4.8.2 to the
latest build), however, rejects this code when RETURN_TYPE is defined to be
auto or decltype(auto).
[Bug c++/64356] New: Some constexpr expressions not recognized as constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64356
Bug ID: 64356
Summary: Some constexpr expressions not recognized as constexpr
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sneves at dei dot uc.pt
Consider the following snippet:
templatesize_t N
constexpr uint64_t f(const char (x)[N]) {
uint64_t s = 0;
#if defined(FAILS)
for(uint64_t c : x)
s += c;
#else
for(size_t i = 0; i N; ++i)
s += x[i];
#endif
return s;
}
templatesize_t N
constexpr uint64_t g(const char (x)[N]) {
char y[N] = {0};
for(size_t i = 0; i N; ++i)
y[i] = x[i];
#if defined(FAILS)
return f(y);
#else
return f(x);
#endif
}
constexpr auto x = g(__DATE__);
When FAILS is defined, GCC (trunk, 20141219) refuses to recognize x as a
constant expression, while with FAILS undefined it works as expected. Clang
accepts both variants.
[Bug c++/63601] New: Segfault on usage of 'this' in unevaluated context inside lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63601
Bug ID: 63601
Summary: Segfault on usage of 'this' in unevaluated context
inside lambda
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sneves at dei dot uc.pt
The following minimal example results in an 'ICE: Segmentation fault' in g++
4.8.1, 4.9.1, and 5.0.0 20141019:
auto f = []{ sizeof(this); };
