[Bug c++/111281] unhelpful warning output ('nonnull' argument 'v' compared to NULL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111281
--- Comment #4 from Frank Heckenbach ---
FWIW, as stated, the lack of context in the message made it hard to find the
actual location of the bug in my code -- in the end even harder than I had
expected since it was well hidden.
Fortunately I was able use concepts to the rescue. Otherwise it would have been
pure guesswork. Here's what I did if anyone cares:
#include
template concept IsFunction = std::is_function_v ||
(std::is_pointer_v && std::is_function_v >);
template concept Outputtable = !IsFunction > || std::is_same_v ; // the latter
part is for std::left etc.
void f (const Outputtable auto &v) { std::cout << v; }
int t ();
int main ()
{
f (t);
}
[Bug tree-optimization/110935] Missed BB reduction vectorization because of missed eliding of a permute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110935 --- Comment #2 from rsandifo at gcc dot gnu.org --- If we were going to do this in vect_optimize_slp_pass, I think we'd need a node for the reduction in the pass's internal graph. We could then record that all input layouts have zero cost. What's the reason for not having an SLP node for the reduction? Isn't it a similar kind of sink to a store or constructor?
[Bug tree-optimization/111268] [14 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111268 --- Comment #5 from Mathieu Malaterre --- (In reply to Andrew Pinski from comment #4) > Looks like this one is already fixed. Same symptoms with 20230902 snapshot: * https://buildd.debian.org/status/fetch.php?pkg=highway&arch=arm64&ver=1.0.8%7Egit20230830.fed142a-1&stamp=1693905326&raw=0
[Bug c++/111281] unhelpful warning output ('nonnull' argument 'v' compared to NULL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111281 --- Comment #5 from Jonathan Wakely --- (In reply to Frank Heckenbach from comment #4) > template concept IsFunction = std::is_function_v || > (std::is_pointer_v && std::is_function_v >); remove_pointer is a no-op for non-pointers so you'll get the same result with: template concept IsFunction = std::is_function_v >);
[Bug c++/111281] unhelpful warning output ('nonnull' argument 'v' compared to NULL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111281 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-09-05 Ever confirmed|0 |1 --- Comment #6 from Jonathan Wakely --- (In reply to Frank Heckenbach from comment #3) > - 'nonnull' is a GCC attribute, and quoting it makes it look like it refers > to that, rather than to being a reference. If you can't easily track the > provenance, a wording like "non-null argument (reference or 'nonnull' > attribute)" might be better. Yes, we shouldn't mention an attribute that is implicitly added by GCC, not actually present in the code. > - 'NULL' is a macro (and very much a deprecated one since we have nullptr), > and both that and the comparison are generated by the compiler and not part > of the code, so a wording like "compared to nullptr or converted to bool" > might be better. Yes, we should not use "NULL" to mean a null pointer. Using nullptr would be wrong too, because in `if (ptr)` or `if (ptr != 0)` there's no nullptr keyword or nullptr_t object. We should say "null" or "null pointer". Confirmed.
[Bug c++/111281] unhelpful warning output ('nonnull' argument 'v' compared to NULL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111281 --- Comment #7 from Jonathan Wakely --- The warning comes from the middle end, where the context of the conversion to bool might have been lost. But the C++ front end already suppresses those warnings in several places: /* This is a compiler generated comparison, don't emit e.g. -Wnonnull-compare warning for it. */ else if (TREE_CODE (ifexp) == NE_EXPR) suppress_warning (ifexp, OPT_Wnonnull_compare); Maybe we want that when implicitly converting a function to bool, but then we wouldn't get any warning at all. It does seem useful to warn about converting a non-weak function to bool, because it's always true so why not just write `true` instead. But maybe we want a C++ FE warning instead of the middle end one.
[Bug fortran/111291] New: ASAN error: heap-use-after-free gcc/fortran/parse.cc:359 in decode_statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111291 Bug ID: 111291 Summary: ASAN error: heap-use-after-free gcc/fortran/parse.cc:359 in decode_statement Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fkastl at suse dot cz CC: mjambor at suse dot cz Target Milestone: --- Host: x86_64-linux Target: x86_64-linux With an ASAN-instrumented GCC configure --enable-languages=default,jit,lto,go,d --enable-host-shared --enable-checking=release --disable-multilib --with-build-config=bootstrap-asan running make check-fortran RUNTESTFLAGS="dg.exp=unexpected_interface.f90 -v" produces ==6474==ERROR: AddressSanitizer: heap-use-after-free on address 0x51302ab8 at pc 0x00ad968d bp 0x7ffd08212000 sp 0x7ffd08211ff8 READ of size 8 at 0x51302ab8 thread T0 #0 0xad968c in decode_statement /home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/parse.cc:359 #1 0xae3df4 in next_free /home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/parse.cc:1592 #2 0xae3df4 in next_statement /home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/parse.cc:1824 #3 0xae832f in parse_interface /home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/parse.cc:3991 #4 0xae832f in parse_spec /home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/parse.cc:4350 #5 0xaef85c in parse_progunit /home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/parse.cc:6576 #6 0xaf12cc in gfc_parse_file() /home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/parse.cc:7162 #7 0xbec011 in gfc_be_parse_file /home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/f95-lang.cc:229 #8 0x1fd637f in compile_file /home/worker/buildworker/tiber-gcc-asan/build/gcc/toplev.cc:444 #9 0x7a7df3 in do_compile /home/worker/buildworker/tiber-gcc-asan/build/gcc/toplev.cc:2126 #10 0x7a7df3 in toplev::main(int, char**) /home/worker/buildworker/tiber-gcc-asan/build/gcc/toplev.cc:2282 #11 0x7b2e23 in main /home/worker/buildworker/tiber-gcc-asan/build/gcc/main.cc:39 #12 0x7fd42da281ef in __libc_start_call_main (/lib64/libc.so.6+0x281ef) (BuildId: 80328d345e2dd1be1b7a59ab1f54d94f4b916dac) #13 0x7fd42da282b8 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x282b8) (BuildId: 80328d345e2dd1be1b7a59ab1f54d94f4b916dac) #14 0x7b45e4 in _start ../sysdeps/x86_64/start.S:115 0x51302ab8 is located 120 bytes inside of 336-byte region [0x51302a40,0x51302b90) freed by thread T0 here: #0 0x865ec8 in __interceptor_free /home/worker/buildworker/tiber-gcc-asan/build/libsanitizer/asan/asan_malloc_linux.cpp:52 #1 0xbb6103 in gfc_free_symbol(gfc_symbol*&) /home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/symbol.cc:3105 previously allocated by thread T0 here: #0 0x866bd7 in __interceptor_calloc /home/worker/buildworker/tiber-gcc-asan/build/libsanitizer/asan/asan_malloc_linux.cpp:77 #1 0x57ef974 in xcalloc /home/worker/buildworker/tiber-gcc-asan/build/libiberty/xmalloc.c:164 SUMMARY: AddressSanitizer: heap-use-after-free /home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/parse.cc:359 in decode_statement Shadow bytes around the buggy address: 0x51302800: fd fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x51302880: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x51302900: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x51302980: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa 0x51302a00: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd =>0x51302a80: fd fd fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd 0x51302b00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x51302b80: fd fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x51302c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x51302c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x51302d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==6474==ABORTING
[Bug c++/111286] [12/13/14 Regression] ICE on functional cast empty brace-init-list to const array reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111286 Marek Polacek changed: What|Removed |Added Priority|P3 |P2 Keywords|needs-bisection | CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r12-7069: commit 119cea98f664764cce04963243c39c8f6d797d33 Author: Jason Merrill Date: Wed Feb 2 18:36:41 2022 -0500 c++: assignment, aggregate, array [PR104300]
[Bug c++/111277] GCC fails to reject braced-init-list in a template-argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111277 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- We implement CWG 2450.
[Bug c++/111284] [11/12/13/14 Regression] Some passing-by-value parameters are mishandled since GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284 Marek Polacek changed: What|Removed |Added Last reconfirmed||2023-09-05 Summary|Some passing-by-value |[11/12/13/14 Regression] |parameters are mishandled |Some passing-by-value |since GCC 9 |parameters are mishandled ||since GCC 9 Target Milestone|--- |11.5 CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Started with r9-6136-g43574e4ff2afd4 commit 43574e4ff2afd4a2e47c179921a9b5661786ebf3 Author: Jakub Jelinek Date: Thu Feb 21 22:21:25 2019 +0100 re PR c++/89285 (ICE after casting the this pointer in the constructor in C++17 mode)
[Bug c++/111284] [11/12/13/14 Regression] Some passing-by-value parameters are mishandled since GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284 Marek Polacek changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/111292] New: Missed Dead Code Elimination since r14-2228-g02460c0b8c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111292
Bug ID: 111292
Summary: Missed Dead Code Elimination since
r14-2228-g02460c0b8c9
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
https://godbolt.org/z/sxj43ojn3
Given the following code:
void foo(void);
static struct {
int a;
char b;
} c;
static int d, f, g;
static int *e = &d, *h, *i;
static int **j = &h;
int main() {
{
short k = d;
int l;
for (; c.a; c.a--) {
int **m = 0;
int *n = &l;
if (*e)
g = *i != 0;
else
__builtin_unreachable();
f = 8;
for (; f; f--) {
*n = c.b || k;
if ((k && *i) + g) {
int ***o = &m;
*o = j;
} else
i = &g;
}
if (m == 0 || m == &h)
;
else
foo();
;
}
}
}
gcc-trunk -O3 does not eliminate the call to foo:
main:
movlc(%rip), %eax
pushq %rbx
movzwl d(%rip), %ebx
testl %eax, %eax
je .L37
.p2align 4,,10
.p2align 3
.L2:
movqi(%rip), %rcx
xorl%esi, %esi
movl(%rcx), %edx
testl %edx, %edx
setne %sil
cmpb$0, c+4(%rip)
movl%esi, g(%rip)
jne .L3
testw %bx, %bx
jne .L4
testl %edx, %edx
jne .L5
movl$0, f(%rip)
movq$g, i(%rip)
.L6:
subl$1, %eax
movl%eax, c(%rip)
jne .L2
.L37:
xorl%eax, %eax
popq%rbx
ret
.p2align 4,,10
.p2align 3
.L3:
testw %bx, %bx
je .L45
movl(%rcx), %esi
movl%edx, %edi
orl %esi, %edi
je .L28
xorl%edi, %edi
testl %esi, %esi
je .L46
.p2align 4,,10
.p2align 3
.L23:
movl$0, f(%rip)
movl$h, %esi
testb %dil, %dil
je .L6
.L24:
movq%rcx, i(%rip)
.L11:
testq %rsi, %rsi
je .L6
cmpq$h, %rsi
je .L6
callfoo
movlc(%rip), %eax
subl$1, %eax
movl%eax, c(%rip)
jne .L2
jmp .L37
.p2align 4,,10
.p2align 3
.L4:
testl %edx, %edx
jne .L5
movl$0, f(%rip)
movl(%rcx), %esi
testl %esi, %esi
je .L43
.L8:
movl$h, %esi
jmp .L11
.p2align 4,,10
.p2align 3
.L45:
movl$0, f(%rip)
testl %edx, %edx
jne .L8
.L43:
movq$g, i(%rip)
jmp .L6
.p2align 4,,10
.p2align 3
.L5:
movl$0, f(%rip)
jmp .L6
.L28:
movl$1, %edi
movl$g, %ecx
xorl%esi, %esi
.L12:
movl(%rcx), %r8d
movl%edx, %r9d
orl %r8d, %r9d
jne .L47
movl$1, %edi
movl$g, %ecx
.L14:
movl(%rcx), %r8d
movl%edx, %r10d
orl %r8d, %r10d
je .L31
movl$h, %esi
testl %r8d, %r8d
jne .L23
.L15:
movl(%rcx), %r8d
movl%edx, %r11d
orl %r8d, %r11d
je .L32
movl$h, %esi
testl %r8d, %r8d
jne .L23
.L16:
movl(%rcx), %r8d
movl%edx, %r11d
orl %r8d, %r11d
je .L33
movl$h, %esi
testl %r8d, %r8d
jne .L23
.L18:
movl(%rcx), %r8d
movl%edx, %r10d
orl %r8d, %r10d
je .L48
testl %r8d, %r8d
jne .L23
movl$h, %esi
testl %edx, %edx
jne .L27
.L21:
movl$1, %edi
movl$g, %ecx
.L27:
orl (%rcx), %edx
jne .L23
xorl%ecx, %ecx
movl%ecx, f(%rip)
movl$g, %ecx
jmp .L24
.L47:
movl$h, %esi
testl %r8d, %r8d
jne .L23
jmp .L14
.L48:
cmpl$0, g(%rip)
je .L21
xorl%edx, %edx
movl$g, %ecx
movl$h, %esi
movl%edx, f(%rip)
jmp .L24
.L31:
movl$1, %edi
movl$g, %ecx
jmp .L15
.L32:
movl$1, %edi
movl$g, %ecx
jmp .L16
.L33:
movl$1, %edi
movl$g, %ecx
jmp .L18
.L46:
[Bug tree-optimization/111293] New: [14 Regression] Missed Dead Code Elimination since r14-3414-g0cfc9c953d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
Bug ID: 111293
Summary: [14 Regression] Missed Dead Code Elimination since
r14-3414-g0cfc9c953d0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
https://godbolt.org/z/9aj7sr5d6
Given the following code:
void foo(void);
static int a, d;
static short e;
static int(f)(int b, int c) { return c == 0 ? b : b / c; }
static char g(char h) {
char i = 1;
int j = 8;
e = 3;
for (; d; ++d) {
if (f(0 == j, e)) return a;
for (; i; i--) {
if (j) {
if (e)
;
else if (a)
continue;
else
foo();
j = -h;
break;
}
__builtin_unreachable();
break;
}
}
return 1;
}
int main() {
g(-1);
a = e;
}
gcc-trunk -O2 does not eliminate the call to foo:
main:
subq$8, %rsp
movld(%rip), %ecx
movl$3, %edx
movw%dx, e(%rip)
testl %ecx, %ecx
je .L6
movl$3, %edx
.p2align 4,,10
.p2align 3
.L2:
testw %dx, %dx
jne .L3
movla(%rip), %eax
testl %eax, %eax
je .L18
.L5:
addl$1, d(%rip)
jne .L5
.L6:
movswl e(%rip), %eax
movl%eax, a(%rip)
xorl%eax, %eax
addq$8, %rsp
ret
.p2align 4,,10
.p2align 3
.L18:
callfoo
.L3:
addl$1, d(%rip)
movzwl e(%rip), %edx
jne .L2
jmp .L6
gcc-13.2.0 -O2 eliminates the call to foo:
main:
movld(%rip), %edx
movl$3, %eax
movw%ax, e(%rip)
testl %edx, %edx
je .L3
movl$0, d(%rip)
.L3:
movl$3, a(%rip)
xorl%eax, %eax
ret
Bisects to r14-3414-g0cfc9c953d0
[Bug tree-optimization/111294] New: [14 Regression] Missed Dead Code Elimination since r14-573-g69f1a8af45d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294
Bug ID: 111294
Summary: [14 Regression] Missed Dead Code Elimination since
r14-573-g69f1a8af45d
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
https://godbolt.org/z/7GTzj8Ea1
Given the following code:
void foo(void);
static short a;
static int b, c, d;
static int *e, *f = &d;
static int **g = &e;
static unsigned char h;
static short(i)(short j, int k) { return j > k ?: j; }
static char l() {
if (a) return b;
return c;
}
int main() {
b = 0;
for (; b < 5; ++b)
;
h = l();
if (a ^ 3 >= i(h, 11))
a = 0;
else {
*g = f;
if (e == &d & b) {
__builtin_unreachable();
} else
foo();
;
}
}
gcc-trunk -Os does not eliminate the call to foo:
main:
movswl a(%rip), %eax
xorl%edx, %edx
movl$5, b(%rip)
testw %ax, %ax
je .L2
movl$5, %edx
.L2:
cmpl$3, %edx
setle %dl
movzbl %dl, %edx
cmpl%edx, %eax
je .L3
movw$0, a(%rip)
xorl%eax, %eax
ret
.L3:
pushq %rax
movq$d, e(%rip)
callfoo
xorl%eax, %eax
popq%rdx
ret
gcc-13.2.0 -Os eliminates the call to foo:
main:
movl$5, b(%rip)
xorl%eax, %eax
movw$0, a(%rip)
ret
Bisects to r14-573-g69f1a8af45d
[Bug c++/52953] function parameter name redeclarations not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52953
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c24982689b8af19da9a64f2283fb99764a1c5db0
commit r14-3713-gc24982689b8af19da9a64f2283fb99764a1c5db0
Author: Jakub Jelinek
Date: Tue Sep 5 17:26:59 2023 +0200
c++: Diagnose [basic.scope.block]/2 violations even in compound-stmt of
function-try-block [PR52953]
As the following testcase shows, while check_local_shadow diagnoses most of
the [basic.scope.block]/2 violations, it doesn't diagnose when parameter's
name is redeclared inside of the compound-stmt of a function-try-block.
There is in that case an extra scope (sk_try with parent artificial
sk_block with for FUNCTION_NEEDS_BODY_BLOCK another sk_block and only then
sk_function_param).
The in_function_try_handler case doesn't work correctly
void
foo (int x)
try {
}
catch (int)
{
try {
} catch (int x)
{
}
try {
} catch (int)
{
int x;
}
}
(which is valid) is rejected, because
|| (TREE_CODE (old) == PARM_DECL
&& (current_binding_level->kind == sk_catch
|| current_binding_level->level_chain->kind ==
sk_catch)
&& in_function_try_handler))
is true but nothing verified that for the first case
current_binding_level->level_chain->kind == sk_function_params
(with perhaps artificial scopes in between and in the latter case
with one extra level in between).
The patch also changes behavior where for catch handlers of
function-try-block
the diagnostics will have the shadows function parameter wording as pedwarn
rather than the old redeclaration permerror.
2023-09-05 Jakub Jelinek
PR c++/52953
* name-lookup.h (struct cp_binding_level): Add artificial
bit-field.
Formatting fixes.
* name-lookup.cc (check_local_shadow): Skip artificial bindings
when
checking if parameter scope is parent scope. Don't special case
FUNCTION_NEEDS_BODY_BLOCK. Diagnose the in_function_try_handler
cases in the b->kind == sk_function_parms test and verify no
non-artificial intervening scopes. Add missing
auto_diagnostic_group.
* decl.cc (begin_function_body): Set
current_binding_level->artificial.
* semantics.cc (begin_function_try_block): Likewise.
* g++.dg/diagnostic/redeclaration-1.C: Expect different diagnostic
wording.
* g++.dg/diagnostic/redeclaration-3.C: New test.
* g++.dg/parse/pr31952-1.C: Expect different diagnostic wording.
* g++.dg/parse/pr31952-3.C: Likewise.
[Bug c++/52953] function parameter name redeclarations not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52953
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:efafa66c294d261a4d964383674ab9ee51feaf88
commit r14-3714-gefafa66c294d261a4d964383674ab9ee51feaf88
Author: Jakub Jelinek
Date: Tue Sep 5 17:31:12 2023 +0200
c++: Diagnose [basic.scope.block]/2 violations even for block externs
[PR52953]
C++17 had in [basic.block.scope]/2
"A parameter name shall not be redeclared in the outermost block of the
function
definition nor in the outermost block of any handler associated with a
function-try-block."
and in [basic.block.scope]/4 similar rule for selection/iteration
statements. My reading of that is that it applied even for block local
externs in all those spots, while they declare something at namespace
scope,
the redeclaration happens in that outermost block etc. and introduces names
into that.
Those wordings seemed to have been moved somewhere else in C++20, but
what's
worse, they were moved back and completely rewritten in
P1787R6: Declarations and where to find them
which has been applied as a DR (but admittedly, we don't claim yet to
implement that).
The current wording at https://eel.is/c++draft/basic.scope#block-2
and https://eel.is/c++draft/basic.scope#scope-2.10 seem to imply at least
to me that it doesn't apply to extern block local decls because their
target scope is the namespace scope and [basic.scope.block]/2 says
"and whose target scope is the block scope"...
Now, it is unclear if that is actually the intent or not.
There seems to be quite large implementation divergence on this as well.
Unpatched g++ e.g. on the redeclaration-5.C testcase diagnoses just
lines 55,58,67,70 (i.e. where the previous declaration is in for's
condition).
clang++ trunk diagnoses just lines 8 and 27, i.e. redeclaration in the
function body vs. parameter both in normal fn and lambda (but not e.g.
function-try-block and others, including ctors, but it diagnoses those
for non-extern decls).
ICC 19 diagnoses lines 8,32,38,41,45,52,55,58,61,64,67,70,76.
And MSCV trunk diagnoses 8,27,32,38,41,45,48,52,55,58,67,70,76,87,100,137
although the last 4 are just warnings.
g++ with the patch diagnoses
8,15,27,32,38,41,45,48,52,55,58,61,64,67,70,76,87,100,121,137
as the dg-error directives test.
Jason said:
> Yes, I suspect that should be
>
> If a declaration that is not a name-independent declaration and
whose
> target scope isthat binds a name in the block scope S of
a
>
> which seems to also be needed to prohibit the already-diagnosed
>
> void f(int i) { union { int i; }; }
> void g(int i) { enum { i }; }
The following patch diagnoses DECL_EXTERNAL in check_local_shadow like
!DECL_EXTERNAL, except that
1) it uses pedwarn instead of errors for those cases
2) it doesn't diagnose shadowing of namespace scope identifiers by block
local externs, as they could be not actually shadowing but just
redeclaring
the same objects
2023-09-05 Jakub Jelinek
PR c++/52953
* name-lookup.cc (check_local_shadow): Don't punt early for
DECL_EXTERNAL decls, instead just disable the shadowing of
namespace
decls check for those and emit a pedwarn rather than error_at or
permerror for those. Formatting fix.
* g++.dg/diagnostic/redeclaration-4.C: New test.
* g++.dg/diagnostic/redeclaration-5.C: New test.
* g++.dg/warn/Wshadow-19.C: New test.
[Bug c++/52953] function parameter name redeclarations not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52953 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Should be fixed now for GCC 14.
[Bug tree-optimization/111294] [14 Regression] Missed Dead Code Elimination since r14-573-g69f1a8af45d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |14.0
[Bug tree-optimization/111294] [14 Regression] Missed Dead Code Elimination since r14-573-g69f1a8af45d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294 --- Comment #1 from Andrew Pinski --- In .optimized we have: [local count: 118111600]: # _31 = PHI <5(2), 0(3)> _6 = (int) a.9_28; _8 = _31 <= 3; _9 = (int) _8; if (_6 != _9) goto ; [66.00%] else goto ; [34.00%] Except nothing optimizes _8 into the phi post pre (note _31 is only used in the definition of _8 even).
[Bug tree-optimization/111294] [14 Regression] Missed Dead Code Elimination since r14-573-g69f1a8af45d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294 --- Comment #2 from Andrew Pinski --- The difference is jump threading: old (able to remove foo): ``` Registering killing_def (path_oracle) _4 Registering value_relation (path_oracle) (_4 pe8 _33) (root: bb5) Checking profitability of path (backwards): [1] Registering jump thread: (5, 7) incoming edge; (7, 9) nocopy; path: 5->7->9 SUCCESS ``` vs new (not able to remove foo): ``` Registering killing_def (path_oracle) _33 Registering value_relation (path_oracle) (_33 pe8 _31) (root: bb5) Checking profitability of path (backwards): FAIL: Jump-thread path not considered: duplication of 2 insns is needed and optimizing for size. path: 5->7->xx REJECTED ``` Old IR before jump threading: ``` [local count: 118111600]: a.9_28 = a; if (a.9_28 != 0) goto ; [34.00%] else goto ; [66.00%] [local count: 40157944]: _30 = (char) b.1_2; [local count: 118111600]: # _33 = PHI <_30(6), 0(5)> _4 = (unsigned char) _33; _6 = (int) a.9_28; j_22 = (short int) _4; _20 = (int) _4; if (_4 > 11) goto ; [50.00%] else goto ; [50.00%] ``` New: ``` [local count: 118111600]: a.9_28 = a; if (a.9_28 != 0) goto ; [34.00%] else goto ; [66.00%] [local count: 40157944]: [local count: 118111600]: # _31 = PHI _32 = (char) _31; _4 = (unsigned char) _31; _6 = (int) a.9_28; j_22 = (short int) _4; _33 = _31 & 255; if (_33 > 11) goto ; [50.00%] else goto ; [50.00%] ``` But _32 will be 0, _4 will be 0, j_22 will be 0, _33 will be 0. But I think jump threading does not recognize j_22 will be 0 on that edge and considers it a copy ... I think.
[Bug target/111231] armhf: Miscompilation at O2 level (O1 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #5 from Mathieu Malaterre ---
Result from cvise (+manual editing):
c++ -Wfatal-errors -Wall -Wextra -Werror -o works -O1 -march=armv7-a
-mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee step7.cc
-> exit(0)
c++ -Wfatal-errors -Wall -Wextra -Werror -o fails -O2 -march=armv7-a
-mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee step7.cc
-> exit(42)
Where:
% cat step7.cc
#include
#include
#define HWY_MIN(a, b) a < b
template
void CopyBytes(From from, To to) {
__builtin_memcpy(to, from, kBytes);
}
template void CopySameSize(From from, To to) {
CopyBytes(from, to);
}
struct Relations {
using Wide = int16_t;
};
template using MakeWide = Relations::Wide;
#if 0
#else
#define HWY_LANES(T) (sizeof(T))
#endif
namespace detail {
constexpr size_t ScaleByPower(size_t N, int pow2) { return pow2 >= 0 ? N : 0; }
} // namespace detail
template struct Simd {
using T = Lane;
static constexpr size_t kWhole = N;
static constexpr int kFrac = 0;
static constexpr size_t kPrivateLanes = detail::ScaleByPower(kWhole, kFrac);
constexpr size_t MaxBytes() { return kPrivateLanes; }
template static constexpr size_t RepartitionLanes() {
return sizeof(int);
}
template
static constexpr size_t WholeN() {
return detail::ScaleByPower(kNewMaxLanes, kNewPow2);
}
template static constexpr size_t NewN() {
return WholeN();
}
template using Rebind = Simd;
template
using Repartition =
Simd()>(), kPow2>;
};
namespace detail {
template struct ClampNAndPow2 {
using type = Simd;
};
template struct CappedTagChecker {
static constexpr size_t N = HWY_LANES(T);
using type = typename ClampNAndPow2::type;
};
} // namespace detail
template
using CappedTag = typename detail::CappedTagChecker::type;
template using TFromD = typename D::T;
#define HWY_MAX_LANES_D(D) D::kPrivateLanes
template size_t MaxLanes(D) { return HWY_MAX_LANES_D(D); }
template size_t Lanes(D) { return HWY_MAX_LANES_D(D); }
template using Rebind = typename D::Rebind;
template using RebindToUnsigned = Rebind;
template using Repartition = typename D::Repartition;
template using RepartitionToWide = Repartition, D>;
#include
#include
#include
namespace hwy {
template struct Vec128 {
T raw[16 / sizeof(T)];
};
template Vec128, HWY_MAX_LANES_D(D)> Zero(D);
template using VFromD = decltype(Zero(D()));
template VFromD BitCast(D, VFrom v) {
VFromD to;
CopySameSize(&v, &to);
return to;
}
template VFromD Set(D d, T2 t) {
VFromD v;
for (size_t i = 0; i < MaxLanes(d); ++i)
v.raw[i] = t;
return v;
}
template Vec128 SaturatedAdd(Vec128 b) {
Vec128 a;
using TW = T;
for (size_t i = 0; i < N; ++i)
a.raw[i] = HWY_MIN(TW() + b.raw[i], T());
return a;
}
template void Store(VFromD v, D d, TFromD *aligned) {
CopyBytes(v.raw, aligned);
}
template using Vec = decltype(Zero(D()));
template
Vec SatWidenMulPairwiseAdd(DI16 di16, VU8 a, VI8 b) {
RebindToUnsigned du16;
auto a1 = BitCast(du16, a), b1(BitCast(di16, b));
return SaturatedAdd(a1);
}
using AllocPtr = void *(void *, size_t);
using FreePtr = void (*)(void *, void *);
void *AllocateAlignedBytes(size_t size, AllocPtr, void *) {
return aligned_alloc(4096, size);
}
void FreeAlignedBytes(const void *ptr, FreePtr, void *) {
free((void*)ptr);
}
AllocPtr *AllocateAlignedItems_alloc_ptr;
template T *AllocateAlignedItems(size_t items) {
size_t size = sizeof(T);
bool is_pow2 = 0;
size_t bits(size);
size_t bytes = is_pow2 ? bits : items;
return static_cast(
AllocateAlignedBytes(bytes, AllocateAlignedItems_alloc_ptr, 0));
}
struct AlignedFreer {
AlignedFreer(FreePtr free_ptr, void *opaque_ptr)
: free_(free_ptr), opaque_ptr_(opaque_ptr) {}
template void operator()(T aligned_pointer) {
FreeAlignedBytes(aligned_pointer, free_, opaque_ptr_);
}
FreePtr free_;
void *opaque_ptr_;
};
template
using AlignedFreeUniquePtr = std::unique_ptr;
FreePtr AllocateAligned_free;
template
AlignedFreeUniquePtr AllocateAligned(size_t items, void *opaque) {
T *__trans_tmp_1 = AllocateAlignedItems(items);
return AlignedFreeUniquePtr(__trans_tmp_1,
AlignedFreer(AllocateAligned_free, opaque));
}
template AlignedFreeUniquePtr AllocateAligned(size_t items) {
return AllocateAligned(items, nullptr);
}
void AssertArrayEqual2(void *a, void *b, size_t c, const char *, int) {
if (memcmp(a, b, c))
exit(42);
}
template >
void p(n d, Vec expected, Vec actual, const char *ab, int ac) {
size_t q = Lanes(d);
auto r = AllocateAligned(q), s = AllocateAligned(q);
Store(expected, d, r.get());
Store(actual, d, s.get());
AssertArrayEqual2(r.get(), s.get(), q, ab, ac);
}
#define t(d, expected, actual) p(d, expected, actual, __FILE__, __LINE__)
template struct w {
static void x(size_t ae, size_t af) {
CappedTag d;
size_t ag = Lanes(d);
if (ag < ae)
return;
if (af)
v()(o(), d);
}
}
[Bug tree-optimization/111294] [14 Regression] Missed Dead Code Elimination since r14-573-g69f1a8af45d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-09-05 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Confirmed.(In reply to Andrew Pinski from comment #2) > > But _32 will be 0, _4 will be 0, j_22 will be 0, _33 will be 0. > But I think jump threading does not recognize j_22 will be 0 on that edge > and considers it a copy ... I think. after: Checking profitability of path (backwards): bb:7 (4 insns) bb:5 Control statement insns: 2 Overall: 2 insns before: Checking profitability of path (backwards): bb:7 (3 insns) bb:5 Control statement insns: 2 Overall: 1 insns Actually I think it is counting an already dead statement. The statement: _32 = (charD.10) _31; is dead but is being counted.
[Bug middle-end/111295] New: RISC-V vector ICE in vsetvl pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111295
Bug ID: 111295
Summary: RISC-V vector ICE in vsetvl pass
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremy.bennett at embecosm dot com
Target Milestone: ---
Created attachment 55843
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55843&action=edit
Test case
The following issue was identified while attempting to compile SPEC CPU 2017
600.perlbench_s benchmark.
Reproducer (test.c):
int a, b, c, e, f, g, h, i, j, k;
long l;
int q ()
{
int r ();
char *o, *d;
_Bool p = f;
while (g)
{
int m, n;
for (; m <= n; m++)
*d++ = m;
k = 1;
if (e)
break;
switch (*o)
{
case 'N':
o++;
if (c)
if (h)
while (i)
{
s (-l, ~0);
t (j);
d = d + (a & 1000 ? u (r, 2) : b);
}
}
if (*o)
p ? s () : 0;
}
}
This is compiled with:
riscv64-unknown-linux-gnu-gcc -march=rv64gcv -mabi=lp64d -c \
-Wno-implicit-function-declaration -Ofast \
-ftree-vectorize --param=riscv-autovec-preference=scalable test.c
The output is:
during RTL pass: vsetvl
test.c: In function 'q':
test.c:32:1: internal compiler error: Segmentation fault
32 | }
| ^
0x10db7d3 crash_signal
/home/jeremy/gittrees/mustang/gcc/gcc/toplev.cc:314
0x7fc85743c4af ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x1548f8a riscv_vector::vector_insn_info::get_avl_reg_rtx() const
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.h:339
0x1548f8a insert_vsetvl
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:750
0x1549a5d pass_vsetvl::commit_vsetvls()
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:3642
0x1549d11 pass_vsetvl::pre_vsetvl()
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:3755
0x154b988 pass_vsetvl::lazy_vsetvl()
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:4442
0x154ba91 pass_vsetvl::execute(function*)
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:4477
0x154ba91 pass_vsetvl::execute(function*)
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:4458
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/111293] [14 Regression] Missed Dead Code Elimination since r14-3414-g0cfc9c953d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |14.0
[Bug tree-optimization/111293] [14 Regression] Missed Dead Code Elimination since r14-3414-g0cfc9c953d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293 --- Comment #1 from Andrew Pinski --- The difference is the trunk can figure out the range for j_8: PHI GROUP query for j_8 found : [irange] int [1, 1][8, 8] and adjusted original range from :[irange] int [1, 1][8, 8] to :[irange] int [1, 1][8, 8] Global Exported: j_8 = [irange] int [1, 1][8, 8] MASK 0x9 VALUE 0x8 But 13 can't: Global Exported: j_8 = [irange] int [-INF, +INF] NONZERO 0x9 I have not looked into how 13 can remove the call to foo though.
[Bug tree-optimization/111293] [14 Regression] Missed Dead Code Elimination since r14-3414-g0cfc9c953d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-09-05 Status|UNCONFIRMED |NEW
[Bug c++/111284] [11/12/13/14 Regression] Some passing-by-value parameters are mishandled since GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
private isn't needed.
struct S {
S () = default;
constexpr S (const S &) noexcept : s{this} {}
constexpr S & operator= (const S &) noexcept { return *this; }
constexpr bool foo () const noexcept { return s == this; }
S *s = this;
};
constexpr bool
bar (S x) noexcept
{
return x.foo ();
}
static_assert (bar (S {}), "");
static_assert ([] (S x) { return x.foo (); } (S {}), "");
The most important change in that commit was to make a copy of the inline body
before it is destructively changed during genericization. On the other side,
one of the important changes genericization does is adjust accesses to
DECL_BY_REFERENCE PARM_DECLs/RESULT_DECLs.
During the evaluation of static assert, I see we are first evaluating
bar (&TARGET_EXPR >> );
which means that expression is adjusted for the passing of invisiref parms, we
are
passing there address of D.2583 variable with S type which is constructed.
But, later on when trying to constexpr evaluate the body of bar, we see
S::foo (&x);
call, so passing address of x to the method, where x is PARM_DECL with S type.
DECL_BY_REFERENCE even isn't set (yet) on it.
I guess we need to somewhere during constexpr evaluation take into account that
S pointer/reference has been passed to the function (to an invisiref parm) and
the function body still uses it directly rather than changing it into a
pointer/reference and dereferencing it.
[Bug middle-end/111296] New: RISC-V vector: ICE in lra_split_hard_reg_for during reload pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111296
Bug ID: 111296
Summary: RISC-V vector: ICE in lra_split_hard_reg_for during
reload pass
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremy.bennett at embecosm dot com
Target Milestone: ---
The following issue was identified while attempting to compile SPEC CPU 2017
641.leela_s benchmark.
Reproducer (test.cc):
struct a
{
int b;
int c;
};
int d;
a
e ()
{
a f;
int g = d - 1, h = d / 2 - 1;
f.b = g;
f.c = h;
return f;
}
Compiled with:
riscv64-unknown-linux-gnu-g++ -std=c++03 -march=rv64gcv -mabi=lp64d -c \
-Ofast -ftree-vectorize --param=riscv-autovec-preference=scalable \
test.cpp
Output is:
test.cpp: In function 'a e()':
test.cpp:15:1: error: unable to find a register to spill
15 | }
| ^
test.cpp:15:1: error: this is the insn:
(insn 59 69 68 2 (set (subreg:V2SI (reg:DI 181) 0)
(if_then_else:V2SI (unspec:V2BI [
(const_vector:V2BI [
(const_int 1 [0x1]) repeated x2
])
(const_int 2 [0x2]) repeated x3
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(plus:V2SI (reg:V2SI 182 [141])
(const_vector:V2SI [
(const_int -1 [0x]) repeated x2
]))
(unspec:V2SI [
(reg:SI 0 zero)
] UNSPEC_VUNDEF))) "test.cpp":15:1 3122 {pred_addv2si}
(expr_list:REG_DEAD (reg:V2SI 182 [141])
(expr_list:REG_DEAD (reg:SI 67 vtype)
(expr_list:REG_DEAD (reg:SI 66 vl)
(expr_list:REG_DEAD (reg:SI 0 zero)
(nil))
during RTL pass: reload
test.cpp:15:1: internal compiler error: in lra_split_hard_reg_for, at
lra-assigns.cc:1861
0x9bab61 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/jeremy/gittrees/mustang/gcc/gcc/rtl-error.cc:108
0x1203e80 lra_split_hard_reg_for()
/home/jeremy/gittrees/mustang/gcc/gcc/lra-assigns.cc:1861
0x11fdaf5 lra(_IO_FILE*)
/home/jeremy/gittrees/mustang/gcc/gcc/lra.cc:2495
0x11b4dd9 do_reload
/home/jeremy/gittrees/mustang/gcc/gcc/ira.cc:5970
0x11b4dd9 execute
/home/jeremy/gittrees/mustang/gcc/gcc/ira.cc:6156
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug middle-end/111296] RISC-V vector: ICE in lra_split_hard_reg_for during reload pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111296 --- Comment #1 from Jeremy Bennett --- Created attachment 55844 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55844&action=edit Testcase (test.cpp)
[Bug c++/111284] [11/12/13/14 Regression] Some passing-by-value parameters are mishandled since GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284 --- Comment #3 from Jakub Jelinek --- The PARM_DECL has DECL_ARG_TYPE of reference to S. And the failure is when evaluating the x PARM_DECL as vc_prvalue, else if (tree v = ctx->global->get_value (t)) doesn't find anything.
[Bug target/111295] RISC-V vector ICE in vsetvl pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111295 --- Comment #1 from Jeremy Bennett --- Further analysis suggests this also causes the following SPEC CPU 2017 benchmarks to fail: 602.gcc_s, 648.exchange2_s, 607.cactuBSSN_s, 621.wrf_s, 627.cam4_s, 628.pop2_s, 638.imagick_s, 649.fotonik3d_s and 654.roms_s
[Bug c++/91483] Poor diagnostic on trying to take constexpr reference to non-static object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91483
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:b78cedc6b5bc062717a3e0efb10da8e19af1c422
commit r14-3718-gb78cedc6b5bc062717a3e0efb10da8e19af1c422
Author: Marek Polacek
Date: Fri Sep 1 17:26:01 2023 -0400
c++: improve verify_constant diagnostic [PR91483]
When verify_constant complains, it's pretty terse. Consider
void test ()
{
constexpr int i = 42;
constexpr const int *p = &i;
}
where it says "'& i' is not a constant expression". OK, but why?
With this patch, we say:
b.C:5:28: error: '& i' is not a constant expression
5 | constexpr const int *p = &i;
|^~
b.C:5:28: note: pointer to 'i' is not a constant expression
b.C:4:17: note: address of non-static constexpr variable 'i' may differ on
each invocation of the enclosing function; add 'static' to give it a constant
address
4 | constexpr int i = 42;
| ^
| static
which brings g++ on par with clang++.
PR c++/91483
gcc/cp/ChangeLog:
* constexpr.cc (verify_constant_explain_r): New.
(verify_constant): Call it.
gcc/testsuite/ChangeLog:
* g++.dg/diagnostic/constexpr3.C: New test.
[Bug c++/91483] Poor diagnostic on trying to take constexpr reference to non-static object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91483 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Marek Polacek --- Should be fixed now.
[Bug c++/111284] [11/12/13/14 Regression] Some passing-by-value parameters are mishandled since GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284 --- Comment #4 from Jakub Jelinek --- Strange, cxx_bind_parameters_in_call is called on DECL_ARGUMENTS of the function (so the ones modified by the genericization), while the function bodies actually have the parameters remaped (stored in the fundef->parms). Not really sure how those connect together.
[Bug c++/111284] [11/12/13/14 Regression] Some passing-by-value parameters are mishandled since GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284 --- Comment #5 from Jakub Jelinek --- Ah, /* Associate the bindings with the remapped parms. */ in constexpr.cc remaps those then. So, that loop should take into account also the invisiref parms disagreements.
[Bug c++/111281] unhelpful warning output ('nonnull' argument 'v' compared to NULL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111281 --- Comment #8 from Frank Heckenbach --- I don't suggest to get rid of the warning. As I said in #3, if it's hard to track, a more inclusive wording seems fine to me. But my main grief about this message is the lack of context, i.e. the really relevant source code location (here, where f is called). Without the concept (which I simplified according to your suggestion, thanks), it would have been really hard to find.
[Bug c++/111297] New: missed optimization: [[unlikely]] attribute has no effect at -O2/-O3/-Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111297
Bug ID: 111297
Summary: missed optimization: [[unlikely]] attribute has no
effect at -O2/-O3/-Ofast
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: moncef.mechri at gmail dot com
Target Milestone: ---
Consider the following code:
extern bool CheckCondition(int i);
extern void DoWork();
extern void DoOtherWork();
void f1()
{
if (CheckCondition(42)) [[likely]]
DoWork();
else
DoOtherWork();
}
void f2()
{
if (CheckCondition(42)) [[unlikely]]
DoWork();
else
DoOtherWork();
}
The [[unlikely]] attribute in f2() seems to have no impact on codegen at -O2,
-O3, and -Ofast:
f1():
sub rsp, 8
mov edi, 42
callCheckCondition(int)
testal, al
je .L2
add rsp, 8
jmp DoWork()
.L2:
add rsp, 8
jmp DoOtherWork()
f2():
sub rsp, 8
mov edi, 42
callCheckCondition(int)
testal, al
je .L6
add rsp, 8
jmp DoWork()
.L6:
add rsp, 8
jmp DoOtherWork()
While the codegen for f1() looks good, the codegen I would have expected for
f2() is:
f2():
sub rsp, 8
mov edi, 42
callCheckCondition(int)
testal, al
jne .L8
add rsp, 8
jmp DoOtherWork()
.L8:
add rsp, 8
jmp DoWork()
Observations:
- All GCC versions since 9.1 (where support for [[likely]] and [[unlikely]] was
first added) seem impacted.
- When f1() is commented out, the issue somehow disappears
- Replacing [[likely]] / [[unlikely]] with __builtin_expect() seems to solve
the issue
- Clang does not suffer from this issue (and neither does GCC at -O1)
https://godbolt.org/z/8o1njKvr1
[Bug ipa/106716] Identical Code Folding (-fipa-icf) confuses between functions with different [[likely]] attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106716 Andrew Pinski changed: What|Removed |Added CC||moncef.mechri at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 111297 has been marked as a duplicate of this bug. ***
[Bug ipa/111297] missed optimization: [[unlikely]] attribute has no effect at -O2/-O3/-Ofast due to ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111297 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 106716. *** This bug has been marked as a duplicate of bug 106716 ***
[Bug tree-optimization/96694] Failure to optimize min/max pattern using two binary nots to min/max pattern using one binary not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96694 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:244d1321340116b7780e78096356f69662fd0e18 commit r14-3720-g244d1321340116b7780e78096356f69662fd0e18 Author: Andrew Pinski Date: Sun Sep 3 18:37:51 2023 + MATCH: Add `~MAX(~X, Y)` pattern: [PR96694] This adds `~MAX(~X, Y)` and `~MIN(~X, Y)` patterns that are like the `~(~a & b)` and `~(~a | b)` patterns and allows to reduce the number of ~ by 1. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/96694 gcc/ChangeLog: * match.pd (`~MAX(~X, Y)`, `~MIN(~X, Y)`): New patterns. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/minmax-24.c: New test.
[Bug tree-optimization/105832] [13/14 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105832 --- Comment #18 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:b34f373635635fa331d2803d9232b3cfd4fd4fd1 commit r14-3719-gb34f373635635fa331d2803d9232b3cfd4fd4fd1 Author: Andrew Pinski Date: Sun Sep 3 06:04:41 2023 + MATCH: Transform `(1 >> X) !=/== 0` into `X ==/!= 0` We currently have a pattern for handling `(C >> X) & D == 0` but if C is 1 and D is 1, the `& 1` might have been removed. gcc/ChangeLog: PR tree-optimization/105832 * match.pd (`(1 >> X) != 0`): New pattern gcc/testsuite/ChangeLog: PR tree-optimization/105832 * gcc.dg/tree-ssa/pr105832-1.c: New test. * gcc.dg/tree-ssa/pr105832-2.c: New test. * gcc.dg/tree-ssa/pr105832-3.c: New test.
[Bug tree-optimization/96694] Failure to optimize min/max pattern using two binary nots to min/max pattern using one binary not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96694 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #4 from Andrew Pinski --- Fixed.
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 96694, which changed state. Bug 96694 Summary: Failure to optimize min/max pattern using two binary nots to min/max pattern using one binary not https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96694 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/105832] [13/14 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105832 Andrew Pinski changed: What|Removed |Added Target Milestone|13.3|14.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #19 from Andrew Pinski --- Fixed.
[Bug tree-optimization/111294] [14 Regression] Missed Dead Code Elimination since r14-573-g69f1a8af45d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > In .optimized we have: >[local count: 118111600]: > # _31 = PHI <5(2), 0(3)> > _6 = (int) a.9_28; > _8 = _31 <= 3; > _9 = (int) _8; > if (_6 != _9) > goto ; [66.00%] > else > goto ; [34.00%] > > Except nothing optimizes _8 into the phi post pre (note _31 is only used in > the definition of _8 even). But optimizing that does not help here. Someone who understands jump threading should look into this.
[Bug tree-optimization/111292] [14 Regression] Missed Dead Code Elimination since r14-2228-g02460c0b8c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111292 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Summary|Missed Dead Code|[14 Regression] Missed Dead |Elimination since |Code Elimination since |r14-2228-g02460c0b8c9 |r14-2228-g02460c0b8c9 Keywords||missed-optimization
[Bug tree-optimization/111292] [14 Regression] Missed Dead Code Elimination since r14-2228-g02460c0b8c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111292 --- Comment #1 from Andrew Pinski --- Looks like there is a missing jump threading ... after the patch.
[Bug tree-optimization/107137] (unsigned)-(int)(bool_var) should be optimized to -(unsigned)bool_var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107137 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:e6bcf83989478348428c732c11e6c0f1719e9214 commit r14-3721-ge6bcf83989478348428c732c11e6c0f1719e9214 Author: Andrew Pinski Date: Thu Aug 31 16:17:35 2023 -0700 MATCH: `(nop_convert)-(convert)a` into -(convert)a if we are converting from something smaller This allows removal of one conversion and in the case of booleans, might be able to remove the negate and the other conversion later on. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/107137 gcc/ChangeLog: * match.pd (`(nop_convert)-(convert)a`): New pattern. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/neg-cast-2.c: New test. * gcc.dg/tree-ssa/neg-cast-3.c: New test.
[Bug tree-optimization/103536] Suboptimal codegen for && and || combination.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103536 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:8e995e84233661a1a246807a66cc84003426b1df commit r14-3722-g8e995e84233661a1a246807a66cc84003426b1df Author: Andrew Pinski Date: Sun Sep 3 10:17:29 2023 -0700 MATCH: Add pattern for `(x | y) & (x & z)` Like the pattern already there for `(x | y) & x`, this adds a simple pattern to optimize `(x | y) & (x & z)` to just `x & z`. OK? Bootstrapped and tested on x86-64-linux-gnu with no regressions. gcc/ChangeLog: PR tree-optimization/103536 * match.pd (`(x | y) & (x & z)`, `(x & y) | (x | z)`): New patterns. gcc/testsuite/ChangeLog: PR tree-optimization/103536 * gcc.dg/tree-ssa/andor-6.c: New test. * gcc.dg/tree-ssa/andor-bool-1.c: New test.
[Bug middle-end/98710] missing optimization (x | c) & ~(y | c) -> x & ~(y | c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98710 --- Comment #5 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:ab286761bf703a43bbd8495cd3fc33a7e88c8440 commit r14-3723-gab286761bf703a43bbd8495cd3fc33a7e88c8440 Author: Andrew Pinski Date: Sun Sep 3 14:26:53 2023 -0700 MATCH: Add `(x | c) & ~(y | c)` and `x & ~(y | x)` patterns [PR98710] Adding some more simple bit_and/bit_ior patterns. How often these show up, I have no idea. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/ChangeLog: PR tree-optimization/98710 * match.pd (`(x | c) & ~(y | c)`, `(x & c) | ~(y & c)`): New pattern. (`x & ~(y | x)`, `x | ~(y & x)`): New patterns. gcc/testsuite/ChangeLog: PR tree-optimization/98710 * gcc.dg/tree-ssa/andor-7.c: New test. * gcc.dg/tree-ssa/andor-8.c: New test.
[Bug tree-optimization/107137] (unsigned)-(int)(bool_var) should be optimized to -(unsigned)bool_var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107137 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED --- Comment #7 from Andrew Pinski --- Fixed.
[Bug tree-optimization/103536] Suboptimal codegen for && and || combination.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103536 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 --- Comment #7 from Andrew Pinski --- Fixed.
[Bug middle-end/98710] missing optimization (x | c) & ~(y | c) -> x & ~(y | c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98710 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Andrew Pinski --- Fixed.
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 98710, which changed state. Bug 98710 Summary: missing optimization (x | c) & ~(y | c) -> x & ~(y | c) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98710 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug testsuite/111298] New: time-profiler-2.c flaky on glibc RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111298 Bug ID: 111298 Summary: time-profiler-2.c flaky on glibc RISC-V Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: patrick at rivosinc dot com Target Milestone: --- Created attachment 55845 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55845&action=edit Excerpt from the debug log Failures: FAIL: gcc.dg/tree-prof/time-profiler-2.c scan-ipa-dump-times profile "Read tp_first_run: 0" 2 FAIL: gcc.dg/tree-prof/time-profiler-2.c scan-ipa-dump-times profile "Read tp_first_run: 2" 1 FAIL: gcc.dg/tree-prof/time-profiler-2.c scan-ipa-dump-times profile "Read tp_first_run: 3" 1 Observed on at least one of the 7 tested glibc targets ~50/78 times (~65%). Separated out this gives a ~14% chance that a given testsuite run fails. Example where failures change when comparing across a daily-bump commit: https://github.com/patrick-rivos/riscv-gnu-toolchain/issues/290 Observed on all tested targets: rv32gcv-ilp32d rv32gc_zba_zbb_zbc_zbs-ilp32d rv32gcv_zicond_zawrs_zbc_zvkng_zvksg_zvbb_zvbc_zicsr_zba_zbb_zbs_zicbom_zicbop_zicboz_zfhmin_zkt-ilp32d rv64gc-lp64d rv64gcv-lp64d rv64gc_zba_zbb_zbc_zbs-lp64d rv64gcv_zvbb_zvbc_zvkg_zvkn_zvknc_zvkned_zvkng_zvknha_zvknhb_zvks_zvksc_zvksed_zvksg_zvksh_zvkt-lp64d Not observed using when using newlib. Replicated locally using https://github.com/patrick-rivos/riscv-gnu-toolchain/tree/6feacbc3d00a11a94f1f8fdc7226b4b908462579 ../configure --prefix=$(pwd) --with-arch=rv64gcv --with-abi=lp64 make report-linux -j32 Upstream riscv-gnu-toolchain has the test allowlisted which is likely why nobody has mentioned it before: https://github.com/riscv-collab/riscv-gnu-toolchain/blob/master/test/allowlist/gcc/glibc.log#L8-L10 >From searching the https://gcc.gnu.org/pipermail/gcc-testresults/ mailing list (May 1st - September 5th), the only other occurrence is https://inbox.sourceware.org/gcc-testresults/87zg23qmwp.fsf@Rainer.invalid/ This is likely specific to the risc-v target. I'm guessing that this is likely due to some conflict between time-profiler-1.c and time-profiler-2.c and filing this under testsuite framework issue, but feel free to move it if it's likely caused by a specific component.
[Bug testsuite/111298] time-profiler-2.c flaky on glibc RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111298 --- Comment #1 from Andrew Pinski --- Are you testing using qemu-user? If so it has always been flaky: https://gcc.gnu.org/pipermail/gcc-patches/2013-November/377091.html
[Bug c++/111299] New: lack of warning on dangling reference to temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111299
Bug ID: 111299
Summary: lack of warning on dangling reference to temporary
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Consider the following reduced example:
using size_t = decltype(sizeof(0));
template
struct array {
T elems[N];
auto data() -> T* { return elems; }
auto data() const -> T const* { return elems; }
auto size() const -> size_t { return N; }
};
template
struct Span {
T* p;
size_t len;
Span(T* p, size_t len) : p(p), len(len) { }
template
Span(R&& r) : p(r.data()), len(r.size()) { }
};
struct [[gnu::packed]] X {
array value;
};
auto get_slice_ref(X const& x) {
return Span(x.value);
}
auto get_slice_ptr(X const& x) {
return Span(x.value.data(), 1);
}
Span is a heavily reduced version of std::span: no fixed extent, no
constraints, etc.
X is a packed struct with a single array member.
Neither version (get_slice_ptr or get_slice_ref) emits any warnings on gcc,
with -Wall -Wextra -Wdangling-reference.
But the -DREF version is horribly broken. What ends up happening is that in
order to bind x.value to the reference parameter R&& r, we can't actually do
that, so instead we create a temporary initialized by copying x.value and we
bind a reference to that temporary, returning a Span pointing to... that. Which
immediately goes out of scope and we end up with a dangling Span.
You can see the broken-ness in the codegen (https://godbolt.org/z/zY77eresb).
The pointer version does the right thing:
get_slice_ptr(X const&):
mov rax, rdi
mov edx, 1
ret
The ref version gives me some garbage:
get_slice_ref(X const&):
lea rax, [rsp-12]
mov edx, 1
ret
It would be really helpful if I had any indication that something is going
wrong here.
[Bug testsuite/111298] time-profiler-2.c flaky on glibc RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111298 --- Comment #2 from Patrick O'Neill --- Yep I'm using qemu-user, thanks for the link.
[Bug c++/111299] lack of warning on dangling reference to temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111299 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #1 from Jiang An --- > What ends up happening is that in order to bind x.value to the reference > parameter R&& r, we can't actually do that, so instead we create a temporary > initialized by copying x.value and we bind a reference to that temporary, > returning a Span pointing to... that. This looks like miscompilation. [[gnu::packed]] should have no effect here. Clang seemingly correctly compiles the function (https://godbolt.org/z/7x8fGcEM9).
[Bug c++/111299] lack of warning on dangling reference to temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111299 --- Comment #2 from Andrew Pinski --- (In reply to Jiang An from comment #1) > > What ends up happening is that in order to bind x.value to the reference > > parameter R&& r, we can't actually do that, so instead we create a > > temporary initialized by copying x.value and we bind a reference to that > > temporary, returning a Span pointing to... that. > > This looks like miscompilation. [[gnu::packed]] should have no effect here. > > Clang seemingly correctly compiles the function > (https://godbolt.org/z/7x8fGcEM9). No, [[gnu::packed]] means you cannot bind a full reference to an element of that struct because it would be miscompiled. clang actually miscompiles this because then the alignment for the refernece would be incorrect ...
[Bug tree-optimization/111268] [14 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111268 --- Comment #6 from Andrew Pinski --- reducing ...
[Bug tree-optimization/111268] [14 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111268 --- Comment #7 from Andrew Pinski --- Interesting: /* We checked above that the vectors are constant-length. */ unsigned vnunits = TYPE_VECTOR_SUBPARTS (vtype).to_constant (); But it is not constant ...
[Bug c++/111300] New: [14 Regression] g++.dg/modules/xtreme-header-2_b.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111300 Bug ID: 111300 Summary: [14 Regression] g++.dg/modules/xtreme-header-2_b.C Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: redi at gcc dot gnu.org Target Milestone: --- After commit r14-3615-gfcede95472ceb4 "Make --enable-libstdcxx-backtrace=auto default to yes" there's a regression in test-results for several targets, among them powerpc64le-unknown-linux-gnu: https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/794895.html x86_64-pc-linux-gnu: https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/794904.html s390x-ibm-linux-gnu: https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/795017.html m68k-unknown-linux-gnu: https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/795117.html pru-unknown-elf: https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/795070.html cris-axis-elf: https://gcc.gnu.org/pipermail/gcc-testresults/2023-September/795124.html >From a build-log for cris-axis-elf: Running /topsrc/gcc/testsuite/g++.dg/modules/modules.exp ... ... FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors) >From that g++.log (mind the cut-and-paste-artefacts): /obj/cris-elf/libstdc++-v3/include/stacktrace:202:24: note: a later '-fabi-version=' (or =0) avoids this error with a c\ hange in mangling^M compiler exited with status 1 FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors) Excess errors: /obj/cris-elf/libstdc++-v3/include/stacktrace:202:24: error: mangling of 'constexpr std::stacktrace_entry::_M_get_info(\ std::string*, std::string*, int*) constoperator void (*)(void*, std::stacktrace_entry::uintptr_t, const \ char*, std::stacktrace_entry::uintptr_t, std::stacktrace_entry::uintptr_t)() const' as '_ZZNKSt16stacktrace_entry11_M_g\ et_infoEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENKUlPvmPKcmmE_cvPFvS8_mSA_mmEEv' conflicts with a pr\ evious mangle /obj/cris-elf/libstdc++-v3/include/stacktrace:202:24: error: mangling of 'static constexpr void std::stacktrace_entry::\ _M_get_info(std::string*, std::string*, int*) const_FUN(void*, std::stacktrace_entry::uintptr_t, const c\ har*, std::stacktrace_entry::uintptr_t, std::stacktrace_entry::uintptr_t)' as '_ZZNKSt16stacktrace_entry11_M_get_infoEP\ NSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_PiENUlPvmPKcmmE_4_FUNES8_mSA_mm' conflicts with a previous mangl\ e /obj/cris-elf/libstdc++-v3/include/stacktrace:202:24: error: mangling of 'std::stacktrace_entry::_M_get_info(std::strin\ g*, std::string*, int*) const::' as '_ZZNKSt16stacktrace_entry11_M_get_infoEPNSt7__cxx1112basic_stringIcSt11\ char_traitsIcESaIcEEES6_PiENKUlPvmPKcmmE_clES8_mSA_mm' conflicts with a previous mangle A guess as to the cause, is that there's a bug at the C++ level (hence component "c++") exposed by a module test that includes libstdc++ support for libbacktrace.
[Bug c++/111301] New: misleading messages about missing "inline"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111301
Bug ID: 111301
Summary: misleading messages about missing "inline"
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: f.heckenb...@fh-soft.de
Target Milestone: ---
Another case of misleading messages:
% cat test.cpp
struct S
{
static int i = 0;
static float f = 0;
};
% g++ -c -std=c++23 test.cpp
test.cpp:3:14: error: ISO C++ forbids in-class initialization of non-const
static member 'S::i'
3 | static int i = 0;
| ^
test.cpp:4:16: error: 'constexpr' needed for in-class initialization of static
data member 'float S::f' of non-integral type [-fpermissive]
4 | static float f = 0;
|^
First of all, the two different messages are irritating. As I understand it,
that's because there is an exception for "static const int", apparently mostly
for historic reasons, and actually not really relevant here. Anyway, even if it
seems worth mentioning this exception at all (I doubt it now that we have
constexpr), the messages could be merged, saying "non-const, non-integral ..."
to make it clearer it's actually the same issue both times.
Also, "forbid" and "needed" is too strongly worded now that "static inline" is
also possible (and in fact what I meant to write).
[Bug c++/111301] misleading messages about missing "inline"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111301 --- Comment #1 from Andrew Pinski --- Note the float case is actually supposed to be rejected without a const for the same reason as the int ... GCC had an extension which allowed `const static float` being initialized `in-class initialization` which was removed (well rather allowed only with -fpermissive ) in GCC 4.7. Looks like the change which removed the extension changed how non-const static initialized for non-const errors out ...
[Bug c++/107198] [13/14 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:752 since r13-3175-g6ffbf87ca66f4ed9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107198 Gayathri Gottumukkala changed: What|Removed |Added CC||gayathri.gottumukkala.27@gm ||ail.com --- Comment #6 from Gayathri Gottumukkala --- This bug can fix by enabling exception handler we can enable by using -fno-exceptions flag.
[Bug c++/52953] function parameter name redeclarations not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52953 Gayathri Gottumukkala changed: What|Removed |Added CC||gayathri.gottumukkala.27@gm ||ail.com --- Comment #12 from Gayathri Gottumukkala --- It is the duplicate of bug 74. Arguments of function redeclared in the function definition which is not possible.
[Bug c++/83028] Incorrect -Wsequence-point warning in correct C++17 code with new evaluation order rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83028 Gayathri Gottumukkala changed: What|Removed |Added CC||gayathri.gottumukkala.27@gm ||ail.com --- Comment #4 from Gayathri Gottumukkala --- The code gives warning if we use different flags while compiling. If we give individual print statements instead of one single statement, then there will be no warnings and it is compiled successfully.
[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643 --- Comment #12 from Mathieu Malaterre --- regression started today % cvise check.sh math_test.cc 00:00:27 INFO ===< 3971165 >=== 00:00:27 INFO running 4 interestingness tests in parallel 00:00:27 INFO INITIAL PASSES 00:00:27 INFO ===< IncludesPass >===
[Bug libstdc++/111302] New: aligned std::experimental::simd loads and stores are not constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111302
Bug ID: 111302
Summary: aligned std::experimental::simd loads and stores are
not constant expressions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: mkretz at gcc dot gnu.org
Reporter: mkretz at gcc dot gnu.org
Target Milestone: ---
Test case (https://godbolt.org/z/d16rvjjsK):
#include
namespace stdx = std::experimental;
using V = stdx::native_simd;
alignas(64) constexpr float mem[32] = {};
constexpr V zero1 = V(mem, stdx::element_aligned);
constexpr V zero2 = V(mem, stdx::vector_aligned);
constexpr V zero3 = V(mem, stdx::overaligned<64>);
constexpr float tmp1 = [](){
float buf[V::size()] = {};
V().copy_to(buf, stdx::element_aligned);
return buf[0];
}();
constexpr float tmp2 = [](){
alignas(stdx::memory_alignment_v) float buf[V::size()] = {};
V().copy_to(buf, stdx::vector_aligned);
return buf[0];
}();
constexpr float tmp3 = [](){
alignas(64) float buf[V::size()] = {};
V().copy_to(buf, stdx::overaligned<64>);
return buf[0];
}();
The element_aligned variants compile. The others don't, but they should.
[Bug libstdc++/111302] aligned std::experimental::simd loads and stores are not constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111302 Matthias Kretz (Vir) changed: What|Removed |Added Target Milestone|--- |14.0 Last reconfirmed||2023-09-06 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #11 from Iain Sandoe --- (In reply to François Dumont from comment #10) > This is because you are facing the PR65762 issue. I just attached a path > proposal to it that you need to apply too to be able to run your test. > You'll be even able to simply use --disable-libstdcxx-dual-abi cause I made > cxx11 abi the default in this case. Yes, with the second patch applied, that works for me also. Does gnu-versioned-namespace work for you with these two patches applied? (I have a patch to enable versioned namespace on Darwin, which is very similar to the GNU one, but it no longer builds)..
