[Bug c++/94723] New: Missing -Wdeprecated warning when user-declared copy assignment operator is defined as deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94723
Bug ID: 94723
Summary: Missing -Wdeprecated warning when user-declared copy
assignment operator is defined as deleted
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
struct S {
int i;
S& operator=(const S&) = delete;
};
S test(const S& s) { return S(s); }
GCC does not warn with -Wdeprecated-copy nor -Wdeprecated.
Is this intentionally not diagnosed? or just missed case in GCC?
Godbolt link: https://godbolt.org/z/Zqgdue
[Bug tree-optimization/90949] [9 Regression] null pointer check removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90949 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #14 from Dávid Bolvanský --- Since 10.1, gcc does crazy things with bloaty codegen for this case https://godbolt.org/z/Qb3yHZ
[Bug tree-optimization/90949] [9 Regression] null pointer check removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90949 --- Comment #16 from Dávid Bolvanský --- For -O3 it is okay, but for -O2 this is questionable
[Bug c/95492] New: Avoid recursive inlining for -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95492
Bug ID: 95492
Summary: Avoid recursive inlining for -O2
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
Test case from PR90949:
int puts(const char*);
void free(void*);
void* malloc(unsigned long);
#define NULL 0
struct Node
{
struct Node* child;
};
void walk(struct Node* module, int cleanup)
{
if (module == NULL) {
return;
}
if (!cleanup) {
puts("No cleanup");
}
walk(module->child, cleanup);
if (cleanup) {
free(module);
}
}
int main()
{
struct Node* node = malloc(sizeof(struct Node));
node->child = NULL;
walk(node, 1);
}
https://godbolt.org/z/aqVApt
Since GCC 10, GCC inlines recursion with -O2/-O3. With -O3, new bigger code is
justified, but for -O2, it is quite questionable whether GCC should inline it
or not (or possibly, less agressive "inlining" for -O2)
[Bug tree-optimization/90949] [9 Regression] null pointer check removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90949 --- Comment #18 from Dávid Bolvanský --- Yes, PR95492
[Bug analyzer/95042] ICE in can_merge_p, at analyzer/region-model.cc:2053
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95042 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #2 from Dávid Bolvanský --- compilation of zstd fails with this error too
[Bug rtl-optimization/96337] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #1 from Dávid Bolvanský --- Inliner changes?
[Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337 --- Comment #10 from Dávid Bolvanský --- >> Compiler version : GCC10.1.1 Maybe you want to use same GCC version as phoronix used (GCC 10.2)?
[Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337 --- Comment #14 from Dávid Bolvanský --- Or change -Os to be gcc10 -O2 with less inlining, -revert O2 to gcc9 -02 and implement -Oz to create agressive “-Os”.
[Bug c/96433] New: Failed to optimize (A / N) * N <= A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96433
Bug ID: 96433
Summary: Failed to optimize (A / N) * N <= A
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
const __SIZE_TYPE__ N = 3;
int foo(__SIZE_TYPE__ len) {
__SIZE_TYPE__ newlen = (len / N) * N;
return newlen <= len;
}
[Bug rtl-optimization/31799] Failed to optimize out test instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31799 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #5 from Dávid Bolvanský --- Codegen: https://godbolt.org/z/7EvYj9 foo: movabs rdx, -6148914691236517205 mov rax, rdi mul rdx mov rax, rdx and rdx, -2 shr rax add rdx, rax xor eax, eax cmp rdi, rdx setnb al ret N: .quad 3 Can be optimized to return true
[Bug c/96433] Failed to optimize (A / N) * N <= A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96433 --- Comment #1 from Dávid Bolvanský --- Codegen: https://godbolt.org/z/7EvYj9 foo: movabs rdx, -6148914691236517205 mov rax, rdi mul rdx mov rax, rdx and rdx, -2 shr rax add rdx, rax xor eax, eax cmp rdi, rdx setnb al ret N: .quad 3 Can be optimized to return true
[Bug rtl-optimization/31799] Failed to optimize out test instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31799 --- Comment #6 from Dávid Bolvanský --- ^ Posted by mistake. Sorry.
[Bug c++/92182] New: No way to silence ''A::TKind' is too small to hold all values of 'enum Kind''
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92182
Bug ID: 92182
Summary: No way to silence ''A::TKind' is too small to hold all
values of 'enum Kind''
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
enum Kind : unsigned {
Y = 0x0,
N = 0x1,
Z = 0x2,
};
struct A {
Kind TKind : 2;
};
gcc file.c
warning: 'A::TKind' is too small to hold all values of 'enum Kind'
This warning has no flag so we cannot use -Wno-XXX. Only option to silence this
warning is '-w'.
[Bug c++/61414] enum class bitfield size-checking needs a separate warning flag controlling it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414 --- Comment #19 from Dávid Bolvanský --- 5 years... Can anybody fix it? It is real issue on real world code: https://reviews.llvm.org/D69792
[Bug c/89549] [7/8/9/10 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549 --- Comment #12 from Dávid Bolvanský --- This missed gcc 7.5 :/
[Bug c/89549] [8/9/10 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549 --- Comment #15 from Dávid Bolvanský --- But there is no way to silence this "note".
[Bug c/89549] [8/9/10 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549 --- Comment #17 from Dávid Bolvanský --- Check few lines above https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549#c8
[Bug c++/93446] New: Improve -Wconversion warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93446
Bug ID: 93446
Summary: Improve -Wconversion warning message
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
Code:
void foo() {
char c = 255;
}
GCC:
warning: conversion from 'int' to 'char' changes value from '255' to
'\377' [-Wconversion]
Clang:
warning: implicit conversion from 'int' to 'char' changes value from 255 to -1
[-Wconstant-conversion]
It would be great if GCC could match Clang here and show -1 instead of very
user unfriendly value \377.
[Bug tree-optimization/93721] swapping adjacent scalars could be more efficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93721
Dávid Bolvanský changed:
What|Removed |Added
CC||david.bolvansky at gmail dot
com
--- Comment #6 from Dávid Bolvanský ---
void swap (std::pair &x)
{
int y[2], t;
static_assert (sizeof x == sizeof y);
__builtin_memcpy (y, &x, sizeof x);
t = y[0]; y[0] = y[1]; y[1] = t;
__builtin_memcpy (&x, y, sizeof x);
}
-O3 x86-64 codegen is regressed in trunk, -O2/-Os is okay
_Z4swapRSt4pairIiiE:
movq (%rdi), %rax
movd (%rdi), %xmm1
sarq $32, %rax
movq %rax, %xmm0
punpckldq %xmm1, %xmm0
movq %xmm0, (%rdi)
ret
[Bug analyzer/93723] ICEs building ada with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93723 --- Comment #2 from Dávid Bolvanský --- Without LTO during IPA pass: analyzer common/entropy_common.c: In function ‘HUF_readStats’: common/entropy_common.c:196:37: internal compiler error: in make_region_for_type, at analyzer/region-model.cc:5983 196 | huffWeight[n] = ip[n/2] >> 4; | ^ 0x1128bb9 make_region_for_type ../../gcc/analyzer/region-model.cc:5983
[Bug analyzer/93723] ICEs building ada with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93723 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #1 from Dávid Bolvanský --- make_region_for_type also crashes when building zstd https://github.com/facebook/zstd make CC="gcc -fanalyzer -flto" -B during IPA pass: analyzer legacy/zstd_v07.c: In function ‘ZBUFFv07_decompressContinue’: legacy/zstd_v07.c:4395:39: internal compiler error: in make_region_for_type, at analyzer/region-model.cc:5983 4395 | const char* const iend = istart + *srcSizePtr; | ^ 0x100fbb9 make_region_for_type ../../gcc/analyzer/region-model.cc:5983 0x100fbb9 ana::region_model::add_region_for_type(ana::region_id, tree_node*) ../../gcc/analyzer/region-model.cc:5993 0x1011984 ana::region_model::get_or_create_view(ana::region_id, tree_node*) ../../gcc/analyzer/region-model.cc:6568 0x1017bed ana::array_region::get_element(ana::region_model*, ana::region_id, ana::svalue_id, ana::region_model_context*) ../../gcc/analyzer/region-model.cc:2199 0x1017da3 ana::region_model::get_or_create_mem_ref(tree_node*, ana::svalue_id, ana::svalue_id, ana::region_model_context*) ../../gcc/analyzer/region-model.cc:6526 0x101d9fa ana::region_model::get_or_create_pointer_plus_expr(tree_node*, ana::svalue_id, ana::svalue_id, ana::region_model_context*) ../../gcc/analyzer/region-model.cc:6546 0x101d9fa ana::region_model::on_assignment(gassign const*, ana::region_model_context*) ../../gcc/analyzer/region-model.cc:3977 0xff855b ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode const*, gimple const*, ana::program_state*, ana::state_change*) const ../../gcc/analyzer/engine.cc:948 0xff8ffb ana::exploded_graph::process_node(ana::exploded_node*) ../../gcc/analyzer/engine.cc:2439 0xff9632 ana::exploded_graph::process_worklist() ../../gcc/analyzer/engine.cc:2259 0xffac8e ana::impl_run_checkers(ana::logger*) ../../gcc/analyzer/engine.cc:3580 0xffb91d ana::run_checkers() ../../gcc/analyzer/engine.cc:3634 0xff07d8 execute ../../gcc/analyzer/analyzer-pass.cc:84
[Bug analyzer/93798] New: ICE in make_region_for_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93798 Bug ID: 93798 Summary: ICE in make_region_for_type Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: david.bolvansky at gmail dot com Target Milestone: --- Created attachment 47865 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47865&action=edit preprocessed zstd source file Using latest snapshot: gcc-latest_10.0.1-20200126git787c79e559f5.deb (https://jwakely.github.io/pkg-gcc-latest/) How to reproduce: gcc -fanalyzer -O3 preprocessed.c ICE log: during IPA pass: analyzer entropy_common.c: In function ‘HUF_readStats’: entropy_common.c:196:35: internal compiler error: in make_region_for_type, at analyzer/region-model.cc:5983 196 | huffWeight[n] = ip[n/2] >> 4; | ^ 0x1128bb9 make_region_for_type ../../gcc/analyzer/region-model.cc:5983 0x1128bb9 ana::region_model::add_region_for_type(ana::region_id, tree_node*) ../../gcc/analyzer/region-model.cc:5993 0x11307d5 ana::array_region::get_or_create(ana::region_model*, ana::region_id, int, tree_node*) ../../gcc/analyzer/region-model.cc:2331 0x1130bc2 ana::array_region::get_element(ana::region_model*, ana::region_id, ana::svalue_id, ana::region_model_context*) ../../gcc/analyzer/region-model.cc:2195 0x1130da3 ana::region_model::get_or_create_mem_ref(tree_node*, ana::svalue_id, ana::svalue_id, ana::region_model_context*) ../../gcc/analyzer/region-model.cc:6526 0x11369fa ana::region_model::get_or_create_pointer_plus_expr(tree_node*, ana::svalue_id, ana::svalue_id, ana::region_model_context*) ../../gcc/analyzer/region-model.cc:6546 0x11369fa ana::region_model::on_assignment(gassign const*, ana::region_model_context*) ../../gcc/analyzer/region-model.cc:3977 0x55b ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode const*, gimple const*, ana::program_state*, ana::state_change*) const ../../gcc/analyzer/engine.cc:948 0xffb ana::exploded_graph::process_node(ana::exploded_node*) ../../gcc/analyzer/engine.cc:2439 0x1112632 ana::exploded_graph::process_worklist() ../../gcc/analyzer/engine.cc:2259 0x1113c8e ana::impl_run_checkers(ana::logger*) ../../gcc/analyzer/engine.cc:3580 0x111491d ana::run_checkers() ../../gcc/analyzer/engine.cc:3634 0x11097d8 execute ../../gcc/analyzer/analyzer-pass.cc:84 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug analyzer/93723] ICEs building ada with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93723 --- Comment #4 from Dávid Bolvanský --- Thanks, created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93798
[Bug c++/88637] New: GCC should mention C++17 in warnings, not C++1z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88637 Bug ID: 88637 Summary: GCC should mention C++17 in warnings, not C++1z Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: david.bolvansky at gmail dot com Target Milestone: --- GCC 8.2 Ubuntu build Code from: http://coliru.stacked-crooked.com/a/d59814e0765c3499 g++ -O3 file.cpp Now: warning: pack expansion in using-declaration only available with -std=c++1z or -std=gnu++1z Expected: warning: pack expansion in using-declaration only available with -std=c++17
[Bug regression/91185] New: -Og miscompiles code causing runtime segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91185
Bug ID: 91185
Summary: -Og miscompiles code causing runtime segfault
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
tVar *eval(tVar *op)
{
if (unlikely(op == NULL))
return NULL;
tVar *a = op->offset + frame_stack.top->frame->local;
switch (op->offset)
{
case CONSTANT:
return op;
default:
{
if (likely(a->initialized))
return a;
else
abort();
}
}
}
GCC 7.4 -Og
eval(tVar*):
testrdi, rdi
je .L4
mov rax, QWORD PTR frame_stack[rip]
mov rsi, QWORD PTR [rax]
mov edx, DWORD PTR [rdi+16]
movsx rax, edx
lea rcx, [rax+rax*2]
lea rax, [0+rcx*8]
lea rax, [rsi+16+rax]
cmp edx, -1
je .L5
cmp BYTE PTR [rax], 0
je .L9
.L1:
rep ret
.L9:
sub rsp, 8
callabort
.L4:
mov eax, 0
ret
.L5:
mov rax, rdi
jmp .L1
frame_stack:
.zero 16
GCC 7.4 -O1
eval(tVar*):
testrdi, rdi
je .L2
mov eax, DWORD PTR [rdi+16]
cmp eax, -1
je .L2
mov rdx, QWORD PTR frame_stack[rip]
mov rdx, QWORD PTR [rdx]
cdqe
lea rax, [rax+rax*2]
lea rdi, [rdx+16+rax*8]
cmp BYTE PTR [rdi], 0
je .L7
.L2:
mov rax, rdi
ret
.L7:
sub rsp, 8
callabort
frame_stack:
.zero 16
It seems -Og places the check
cmp edx, -1
je .L5
too late -> SEGFAULT
I have a segfault with GCC 7,8,9 on Intel Haswell. Looking at godbolt's output
for GCC 6.4, it is seems to be buggy too.
Godbolt: https://godbolt.org/z/m2yzDA
[Bug regression/91185] -Og miscompiles code causing runtime segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91185 --- Comment #1 from Dávid Bolvanský --- (gdb) r bw Starting program: /home/xbolva00/IFJ16/src/ifj16c bw Program received signal SIGSEGV, Segmentation fault. 0xeac5 in eval (op=0x55768b80) at interpret.c:37 37 tVar *a = op->offset + frame_stack.top->frame->local; (gdb) disassemble Dump of assembler code for function eval: 0xeab9 <+0>: test %rdi,%rdi 0xeabc <+3>: je 0xeaf4 0xeabe <+5>: mov0x205d8b(%rip),%rax# 0x55764850 => 0xeac5 <+12>:mov(%rax),%rsi 0xeac8 <+15>:mov0x10(%rdi),%edx 0xeacb <+18>:movslq %edx,%rax
[Bug regression/91185] -Og miscompiles code causing runtime segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91185 Dávid Bolvanský changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Dávid Bolvanský --- Ok, it seems this is not a miscompilation. Just -O1 and higher hides bug in the code (no segfault).
[Bug c/89549] [7/8/9/10 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #8 from Dávid Bolvanský --- Why this annoying note cannot be disabled using #pragma GCC diagnostic ignored "-Wmisleading-indentation" ? So only solution is -Wno-misleading-indentation?
[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487
Dávid Bolvanský changed:
What|Removed |Added
CC||david.bolvansky at gmail dot
com
--- Comment #18 from Dávid Bolvanský ---
a.c
int foo(void) __attribute__((const));
int main(void) {
return foo();
}
b.c
#include
int foo(void) {
puts("BUM");
return 0;
}
gcc a.c b.c -Wall -Wextra -flto -o bum
It would be nice to get a warning.
[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885 --- Comment #20 from Dávid Bolvanský --- Clang implemented [0] this diagnostic under -Wxor-used-as-pow. From user perspective it would be reasonable if GCC follows this naming. [0] https://reviews.llvm.org/D63423
[Bug c/89549] [7/8/9/10 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549 --- Comment #11 from Dávid Bolvanský --- Would be nice to fix this for the last release of GCC 7.
[Bug c++/91746] New: Bogus error due to a type and variable with the same name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91746
Bug ID: 91746
Summary: Bogus error due to a type and variable with the same
name
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
GCC fails to compile:
struct pixel {
int x;
int y;
};
struct master {
pixel pixel;
};
:9:11: error: declaration of 'pixel master::pixel' changes meaning of
'pixel' [-fpermissive]
9 | pixel pixel;
| ^
:3:8: note: 'pixel' declared here as 'struct pixel'
3 | struct pixel {
|^
Clang, ICC, MSVC - compiles it just fine.
[Bug c++/91761] Overloaded new operator compiled with -O3 option distorts original C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91761 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #4 from Dávid Bolvanský --- But GCC 5.5 could remove one malloc-free pair https://godbolt.org/z/fDJZs0 New optimization in gcc 6 actually made the code worse..
[Bug c++/91840] New: Support for #pragma unroll (N)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91840
Bug ID: 91840
Summary: Support for #pragma unroll (N)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
Clang/ICC supports #pragma unroll (N) and it would be good if GCC too, so we
don't have to write macros to workaround it and to keep the code buildable by
all tree compilers.
This should not be so hard, since GCC already has #pragma GCC unroll (N).
void unroll(int a[], int b[], int c[], int d[]) {
#pragma unroll(4)
for (int i = 1; i < 100; i++) {
b[i] = a[i] + 1;
d[i] = c[i] + 1;
}
}
[Bug target/29776] result of ffs/clz/ctz/popcount/parity are already sign-extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
Dávid Bolvanský changed:
What|Removed |Added
CC||david.bolvansky at gmail dot
com
--- Comment #21 from Dávid Bolvanský ---
long long foo (int x) { return __builtin_ctz (x); }
still produces
foo(int):
xor eax, eax
tzcnt eax, edi
cdqe
ret
instead of
foo(int):# @foo(int)
tzcnt eax, edi
ret
[Bug tree-optimization/88814] transform snprintf into memccpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88814 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #2 from Dávid Bolvanský --- You cannot [0] do this general transformation.. Runtime variable n = 10. d[9] = 'A'; snprintf(d, n, "%s", s) // s is "str" assert(d[9] == 'A'); => d[9] = 'A'; memccpy(d, s, 0, 9); d[9] = 0; assert(d[9] == 'A'); [0] https://reviews.llvm.org/D67986
[Bug other/81334] -Wmisleading-indentation prints notes about being disabled even when already intentionally ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81334 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #4 from Dávid Bolvanský --- Two years passed and no fix :( Can somebody look at it?
[Bug tree-optimization/89263] New: Simplify bool expression to OR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89263
Bug ID: 89263
Summary: Simplify bool expression to OR
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
bool foo(bool a, bool b)
{
if (a)
return true;
return b;
}
Current:
foo(bool, bool):
testdil, dil
mov eax, esi
cmovne eax, edi
ret
Better:
foo(bool, bool):
mov eax, edi
or eax, esi
ret
[Bug tree-optimization/89491] New: Inline jump tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89491
Bug ID: 89491
Summary: Inline jump tables
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
int square(int x) {
return x*x;
}
int add(int x) {
return x + x;
}
typedef int (*p) (int);
p arr[4] = {square, add};
int test(int x) {
int res = arr[1](x);
return res;
}
Expected:
test(int):
lea eax, [rdi+rdi]
ret
Currently:
test(int):
jmp [QWORD PTR arr[rip+8]]
If the index to the jump table isn't a constant, should not be better to expand
"if else" chain like:
if (x==1) arr[1](x);
else if (x==2) arr[2](x);
..and then take an opportunity to inline functions?
[Bug tree-optimization/89491] Inline jump tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89491 --- Comment #2 from Dávid Bolvanský --- Right, static helps. What about more complex examples, like inlining vtables? https://gcc.godbolt.org/z/ZXkRYa
[Bug c/89526] New: Diagnose errors in asserts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89526
Bug ID: 89526
Summary: Diagnose errors in asserts
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
GCC trunk -Wall -Wextra
#include
int foo(int *x) {
assert(x && "nullptr");
return *x;
}
int foo2(int *x) {
assert("nullptr"); // should warn
return *x;
}
[Bug tree-optimization/89491] Inline jump tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89491
--- Comment #5 from Dávid Bolvanský ---
Let's take the original example with small modification:
int square(int x) { return x*x; }
int add(int x) { return x + x; }
typedef int (*p)(int);
static const p arr[4] = {square, add};
int test(int x) {
int res = arr[x](1);
return res;
}
Nothing is expanded/inlined. ICC can do it for "two items in arr" case.
[Bug c++/89554] New: Incorrect location of warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89554
Bug ID: 89554
Summary: Incorrect location of warning
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
Found when building LLVM trunk with GCC 9 trunk (built today) compiler.
https://clang.llvm.org/doxygen/LiteralSupport_8cpp_source.html
const char *End = saw_exponent ? ExponentBegin : SuffixBegin;
for (const char *Ptr = DigitsBegin; Ptr < End; ++Ptr) {
if (*Ptr == '.') {
FoundDecimal = true;
continue;
/home/xbolva00/LLVM/llvm-project/clang/lib/Lex/LiteralSupport.cpp:1127:43:
warning: ‘ExponentBegin’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
1127 | for (const char *Ptr = DigitsBegin; Ptr < End; ++Ptr) {
^
I would expect carret to be here: saw_exponent ? ExponentBegin : SuffixBegin;
^
As side note: there are so many "-Wmaybe-uninitialized" warnings. You should
check them whether real issues or no (they spam build warning log very much) -
don't think so.
You should consider removing '-Wmaybe-uninitialized" from standard "-Wall
-Wextra".
[Bug c++/89554] Incorrect location of warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89554 --- Comment #1 from Dávid Bolvanský --- Another weird report: Building CXX object lib/Lex/CMakeFiles/clangLex.dir/PPMacroExpansion.cpp.o In file included from /home/xbolva00/LLVM/llvm-project/clang/include/clang/Basic/SourceManager.h:37:0, from /home/xbolva00/LLVM/llvm-project/clang/include/clang/Lex/DirectoryLookup.h:17, from /home/xbolva00/LLVM/llvm-project/clang/lib/Lex/PPMacroExpansion.cpp:23: /home/xbolva00/LLVM/llvm-project/clang/include/clang/Basic/Diagnostic.h: In function ‘void EvaluateFeatureLikeBuiltinMacro(llvm::raw_svector_ostream&, clang::Token&, clang::IdentifierInfo*, clang::Preprocessor&, llvm::function_ref)’: /home/xbolva00/LLVM/llvm-project/clang/include/clang/Basic/Diagnostic.h:1230:18: warning: ‘*((void*)& ResultTok +16)’ may be used uninitialized in this function [-Wmaybe-uninitialized] DB.AddTaggedVal(static_cast(I), DiagnosticsEngine::ak_tokenkind); *((void*)& ResultTok +16) seems weird for me.
[Bug c++/89708] New: printf and std::byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89708
Bug ID: 89708
Summary: printf and std::byte
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
#include
#include
typedef unsigned char byte_t;
void test (byte_t a, std::byte b)
{
printf("%u", a); // OK
printf("%hhu", a); // OK
printf("%u", b); // GCC warns, Clang warns and recommends %hhu
printf("%hhu", b); // GCC warns
}
What is wrong with this code? I think we shouldn't see any warnings for
std::byte.. or?
[Bug c/89738] New: Warn for unused macro arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89738 Bug ID: 89738 Summary: Warn for unused macro arguments Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: david.bolvansky at gmail dot com Target Milestone: --- I found a nasty bug in my code which was related to unused macro arguments. #define PARENT_NODE(x) ((id - 1) / 2) As you can see, the "id" macro argument was unused. The code worked fine, since id matched id in the code. Then I reused this macro in the other project and bum, the "id" variable unfortunely existed too, but now I used the macro as eg. PARENT_NODE(idx). Any changes for diagnostics for this case?
[Bug preprocessor/89738] Warn for unused macro arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89738 --- Comment #2 from Dávid Bolvanský --- #define PARENT_NODE(x) ((id - 1) / 2) int id = 0; int idx = 1; PARENT_NODE(idx); // macro contais id, but id is defined, warn? But probably such analysis is not so easy...
[Bug c++/90159] New: Poor warning for an ambiguous reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90159
Bug ID: 90159
Summary: Poor warning for an ambiguous reference
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
Test case:
#include
#include
using namespace std;
struct sort_heap
{
bool operator()(const int* lhs, const int* rhs) const
{
return *lhs < *rhs;
}
};
void foo()
{
std::priority_queue, sort_heap> tmp;
}
: In function 'void foo()':
:16:59: error: template argument 3 is invalid
16 | std::priority_queue, sort_heap> tmp;
| ^
:16:61: warning: unused variable 'tmp' [-Wunused-variable]
16 | std::priority_queue, sort_heap> tmp;
| ^~~
GCC does not provide enough info why argument is really invalid. Clang produces
more info, which explain the root problem:
Clang
:16:50: error: reference to 'sort_heap' is ambiguous
std::priority_queue, sort_heap> tmp;
^
:6:8: note: candidate found by name lookup is 'sort_heap'
struct sort_heap
^
/opt/compiler-explorer/gcc-8.3.0/lib/gcc/x86_64-linux-gnu/8.3.0/../../../../include/c++/8.3.0/bits/algorithmfwd.h:576:5:
note: candidate found by name lookup is 'std::sort_heap'
sort_heap(_RAIter, _RAIter, _Compare);
^
[Bug tree-optimization/90373] New: Better alias analysis based on libc functions with arguments which cannot alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90373
Bug ID: 90373
Summary: Better alias analysis based on libc functions with
arguments which cannot alias
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
bool foo(int *a, int *b, unsigned n) {
memcpy(a, b, n);
return a == b;
}
GCC trunk X86-64 -O3
foo(int*, int*, unsigned int):
pushrbx
mov edx, edx
mov rbx, rsi
callmemcpy
cmp rax, rbx
pop rbx
seteal
ret
if a and b aliases, it would be UB to call memcpy since "The memory areas must
not overlap.". Currently GCC emits "a == b", but possibly, info that a cannot
alias b in range n could be propagated more.
Same for strcpy
"The strings may not overlap, and the destination string dest must be large
enough to receive the copy."
[Bug c++/90353] No warning on unused exception parameter with -Wall -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90353 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #3 from Dávid Bolvanský --- Clang has switch -Wunused-exception-parameter so maybe GCC should support it too.
[Bug c/90554] New: Missed vectorization with conditionally defined the end of the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90554
Bug ID: 90554
Summary: Missed vectorization with conditionally defined the
end of the loop
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
int vectorize(int b, unsigned *x, unsigned *y, int N, int NN)
{
int sum = 0;
int end = b ? N : NN;
unsigned *p = b ? x : y;
for(int i = 0; i < end; ++i) {
sum += p[i];
}
return sum;
}
Trunk -O3
vectorize:
testedi, edi
cmovne r8d, ecx
cmovne rdx, rsi
testr8d, r8d
jle .L5
lea eax, [r8-1]
lea rcx, [rdx+4+rax*4]
xor eax, eax
.L4:
add eax, DWORD PTR [rdx]
add rdx, 4
cmp rcx, rdx
jne .L4
ret
.L5:
xor eax, eax
ret
ICC or Clang vectorizes this code.
[Bug c++/90629] New: Support for -Wmismatched-new-delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90629
Bug ID: 90629
Summary: Support for -Wmismatched-new-delete
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
void alloc() {
int *arr = new int [10];
delete arr;
}
GCC with -Wall -Wextra - No warnings.
Clang with -Wall -Wextra:
:5:5: warning: 'delete' applied to a pointer that was allocated with
'new[]'; did you mean 'delete[]'? [-Wmismatched-new-delete]
delete arr;
^
[]
:4:16: note: allocated with 'new[]' here
int *arr = new int [10];
[Bug middle-end/90693] Missing popcount simplifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90693 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #1 from Dávid Bolvanský --- >> __builtin_popcount (x) == 1 into x == (x & -x) This will not work for x = 0. Should work: x && x == (x & -x) x && (x & x-1) == 0
[Bug middle-end/90693] Missing popcount simplifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90693 --- Comment #3 from Dávid Bolvanský --- I measured it a bit.. (x-1)
[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #18 from Dávid Bolvanský --- -Wxor-as-pow ? :)
[Bug tree-optimization/90917] New: Propagate constants into loads if dominated by str(n)cmp/memcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90917
Bug ID: 90917
Summary: Propagate constants into loads if dominated by
str(n)cmp/memcmp
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
Motivation:
char f(char* s) {
if (strcmp(s, "test") == 0) return s[0];
return '-';
}
--->
char f2(char* s) {
if (strcmp(s, "test") == 0) return 't';
return '-';
}
[Bug tree-optimization/90917] Propagate constants into loads if dominated by str(n)cmp/memcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90917
--- Comment #1 from Dávid Bolvanský ---
char f(void) {
char* s = ... ;
if (strcmp(global_s, s) == 0) return global_s[0];
return '-';
}
-->
char f2(void) {
char* s = ... ;
if (strcmp(global_s, s) == 0) return s[0];
return '-';
}
[Bug c/86628] New: Missed simplification of division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
Bug ID: 86628
Summary: Missed simplification of division
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
Hello,
for code:
int f(int x, int y, int z) {
return (x * y * z) / (y * z);
}
GCC 8.1 (x86-64) with -O3 emits:
f(int, int, int):
mov eax, edi
imul eax, esi
imul esi, edx
imul eax, edx
cdq
idiv esi
ret
but one multiplication can be removed, as Clang does it:
f(int, int, int):
imul esi, edx
imul edi, esi
mov eax, edi
cdq
idiv esi
ret
Also, for:
unsigned f2(unsigned x, unsigned y, unsigned z) {
return (x*z) / (y*z);
}
f2(unsigned int, unsigned int, unsigned int):
mov eax, edi
imul esi, edx
imul eax, edx
xor edx, edx
div esi
ret
This could be simplified to "x/y". For a signed case it could be possible too,
just z = -1 needs to be checked.
[Bug tree-optimization/86628] Missed simplification of division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628 --- Comment #2 from Dávid Bolvanský --- Something/0 is undefined behaviour
[Bug tree-optimization/86701] New: Optimize strlen called on std::string c_str()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86701
Bug ID: 86701
Summary: Optimize strlen called on std::string c_str()
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
Transform:
int lenstr(std::string &str) {
return strlen(str.c_str() /* .data() */);
}
To:
int lenstr(std::string &str) {
return str.length();
}
[Bug tree-optimization/86701] Optimize strlen called on std::string c_str()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86701 --- Comment #2 from Dávid Bolvanský --- There is not string analysis to tell us that string has no null characters in the middle?
[Bug c++/87230] New: GCC should warn if [[fallthrough]] is used in the last case in a switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87230
Bug ID: 87230
Summary: GCC should warn if [[fallthrough]] is used in the last
case in a switch
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
void f(int n) {
void g(), h(), i();
switch (n) {
case 1:
case 2:
g();
[[fallthrough]];
case 3: // no warning on fallthrough
h();
case 4: // compiler may warn on fallthrough
if(n < 3) {
i();
[[fallthrough]]; // OK
}
else {
return;
}
case 5:
[[fallthrough]]; // ill-formed, no subsequent case or default label
}
}
gcc -O3 -std=c++17 -Wall -Werror -> no errors
clang -O3 -std=c++17 -Wall -Werror ->
:24:7: error: fallthrough annotation does not directly precede switch
label
[[fallthrough]]; // ill-formed, no subsequent case or default label
^
[Bug c++/87234] New: GCC should warn if template parameter redefines default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87234
Bug ID: 87234
Summary: GCC should warn if template parameter redefines
default argument
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
-O3 -Wall -Werror -std=c++17
template< typename T = int > T func( );
template< typename T = int > T func( ) {
}
No warning.
Clang:
:5:24: error: template parameter redefines default argument
template< typename T = int > T func( ) {
^
:4:24: note: previous default template argument defined here
template< typename T = int > T func( );
^
1 error generated.
See:
https://stackoverflow.com/questions/14197436/c11-template-parameter-redefines-default-argument
[Bug tree-optimization/87465] New: Loop removal regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87465
Bug ID: 87465
Summary: Loop removal regression
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
void Test()
{
int c = 0;
int in[4] = {4,3,4,4};
for (unsigned i = 0; i < 4; i++) {
for (unsigned j = 0; j < i; j++) {
if (in[i] == in[j])
break;
else
++c;
}
}
printf("test %d", c);
}
GCC 7.3:
Test():
mov esi, 1
mov edi, OFFSET FLAT:.LC0
xor eax, eax
jmp printf
GCC 8+ is unable to simplify it as 7.3 (no loops are removed).
Godbolt:
https://godbolt.org/z/tDAuug
[Bug tree-optimization/87540] New: Missed inner loop hoist if the loop does not depend on outer loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87540
Bug ID: 87540
Summary: Missed inner loop hoist if the loop does not depend on
outer loop
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
Not sure how often this happens in the real world apps but anyway idea is..
int foo(void)
{
double *array = calloc(ARRAY_SIZE, sizeof(double));
double sum = 0;
int i;
for (i = 0; i < N_TIMES; i++) {
// lot of code
// well, this loop does not even depend on "i", hoist it?
for (int j = 0; j < ARRAY_SIZE; j += 8) {
sum += array[j] + array[j+1] + array[j+2] + array[j+3] + array[j+4]
+ array[j+5] + array[j+6] + array[j+7];
}
}
return sum;
}
Let's say we have the big outer loop with many inner loops. GCC should detect
if these loops really depend on the outer loop and if not, hoist them out of
this loop.
[Bug target/98348] [10 Regression] GCC 10.2 AVX512 Mask regression from GCC 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98348 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #20 from Dávid Bolvanský --- Some small regression (missed opportunity to use vptestnmd): Current trunk compare(unsigned int __vector(16)): vpxor xmm1, xmm1, xmm1 vpcmpd k0, zmm0, zmm1, 0 vpmovm2d zmm0, k0 ret GCC 9.2 compare(unsigned int __vector(16)): vptestnmd k0, zmm0, zmm0 vpmovm2d zmm0, k0 ret https://gcc.godbolt.org/z/5vK68jM3r
[Bug tree-optimization/99971] GCC generates partially vectorized and scalar code at once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #7 from Dávid Bolvanský --- Still bad for -O3 -march=skylake-avx512 https://godbolt.org/z/azb8aTG43
[Bug c/98658] New: Loop idiom recognization for memcpy/memmove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98658
Bug ID: 98658
Summary: Loop idiom recognization for memcpy/memmove
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
void copy(int *__restrict__ d, int * s, __SIZE_TYPE__ sz) {
__SIZE_TYPE__ i;
for (i = 0; i < sz; i++) {
*d++ = *s++;
}
}
gcc emits call to memcpy.
void copy(int * d, int * s, __SIZE_TYPE__ sz) {
__SIZE_TYPE__ i;
for (i = 0; i < sz; i++) {
*d++ = *s++;
}
}
gcc could emit memmove, but currently does not:
https://godbolt.org/z/5n1rnh
[Bug c/98658] Loop idiom recognization for memcpy/memmove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98658 --- Comment #1 from Dávid Bolvanský --- ICC produces memcpy: https://godbolt.org/z/oKxxTM
[Bug c/98658] Loop idiom recognization for memcpy/memmove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98658 --- Comment #3 from Dávid Bolvanský --- Yes, runtime check.
[Bug other/98663] gcc generates endless loop at -O2 or greater depending on order of testExpression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98663 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #1 from Dávid Bolvanský --- Compiler can do anything if there is UB in the code.
[Bug c/98713] New: Failure to generate branch version of abs if user requested it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98713
Bug ID: 98713
Summary: Failure to generate branch version of abs if user
requested it
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
int branch_abs(int v) {
return __builtin_expect(v > 0, 1) ? v : -v;
}
GCC -O2 now:
branch_abs:
mov eax, edi
neg eax
cmovs eax, edi
ret
Expected:
branch_abs:
mov eax, edi
test edi, edi
js .LBB0_1
ret
.LBB0_1:
neg eax
ret
Same for min/max.
[Bug middle-end/98713] Failure to generate branch version of abs if user requested it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98713 --- Comment #5 from Dávid Bolvanský --- User knows the data better, so he/she may prefer abs with branch. Also PGO may say that branch for abs is better based on profile data.
[Bug c/100260] New: DSE: join stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100260
Bug ID: 100260
Summary: DSE: join stores
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
#include
struct pam {
void *p1;
void *p2;
#ifdef LONG
unsigned long size;
#else
unsigned int pad;
unsigned int size;
#endif
};
extern int use(struct pam *param);
unsigned int foo(void) {
struct pam s_pam;
memset(&s_pam, 0, sizeof(struct pam));
s_pam.size = 1;
return use(&s_pam);
}
INT
foo():
sub rsp, 40
pxor xmm0, xmm0
mov rdi, rsp
mov DWORD PTR [rsp+16], 0
mov DWORD PTR [rsp+20], 1
movaps XMMWORD PTR [rsp], xmm0
call use(pam*)
add rsp, 40
ret
LONG
foo():
sub rsp, 40
pxor xmm0, xmm0
mov rdi, rsp
movaps XMMWORD PTR [rsp], xmm0
mov QWORD PTR [rsp+16], 1
call use(pam*)
add rsp, 40
ret
Stores
mov DWORD PTR [rsp+16], 0
mov DWORD PTR [rsp+20], 1
can be replaced with one mov QWORD..
[Bug c/108593] New: No inlining after function cloning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108593
Bug ID: 108593
Summary: No inlining after function cloning
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
int __attribute__ ((noinline))
foo (int arg)
{
return 2 * arg;
}
int
bar (int arg)
{
return foo (5);
}
results in:
foo.constprop.0:
mov eax, 10
ret
foo:
lea eax, [rdi+rdi]
ret
bar:
jmp foo.constprop.0
But ... why foo.constprop.0 is not inlined fully into bar? Maybe
foo.constprop.0 inherits noinline attribute from foo?
If so, gcc should drop attributes from cloned functions..
[Bug ipa/104187] Call site specific attribute to control inliner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104187
--- Comment #8 from Dávid Bolvanský ---
So this works in Clang now
int foo(int x, int y) { // any compiler will happily inline this function
return x / y;
}
int test(int x, int y) {
int r = 0;
[[clang::noinline]] r += foo(x, y); // for some reason we don't want any
inlining here
return r;
}
foo(int, int): # @foo(int, int)
mov eax, edi
cdq
idiv esi
ret
test(int, int): # @test(int, int)
jmp foo(int, int) # TAILCALL
foo(int, int): # @foo(int, int)
mov eax, edi
cdq
idiv esi
ret
test(int, int): # @test(int, int)
jmp foo(int, int) # TAILCALL
[Bug c/104187] New: Call site specific attribute to control inliner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104187
Bug ID: 104187
Summary: Call site specific attribute to control inliner
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
It could be useful to have more control over inlining. Use cases:
int foo();
void bar();
int g;
void test()
{
g = __builtin_always_inline(foo()); // force inlining of foo() here
__builtin_noinline(bar()); // never inline bar to this function
}
[Bug ipa/104187] Call site specific attribute to control inliner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104187 --- Comment #5 from Dávid Bolvanský --- So you prefer eg. g = a[i] - [[gnu::always_inline]] foo(x, y) + 2 * bar(); over g = a[i] - __builtin_always_inline(foo(x, y)) + 2 * bar(); ? What is your proposed syntax?
[Bug tree-optimization/93150] (A&N) == CST1 &( ((A&M)==CST2) | ((A&O)==CST3) ) is not simplified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93150 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #2 from Dávid Bolvanský --- Bin ops with constants are simplified by compiler itself..
[Bug tree-optimization/102483] New: Regression in codegen of reduction of 4 chars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102483
Bug ID: 102483
Summary: Regression in codegen of reduction of 4 chars
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
char foo (char* p)
{
char sum = 0;
for (int i = 0; i != 4; i++)
sum += p[i];
return sum;
}
-O3 -march=x86-64
GCC trunk:
foo:
mov edx, DWORD PTR [rdi]
movzx eax, dh
mov ecx, edx
add eax, edx
shr ecx, 16
add eax, ecx
shr edx, 24
add eax, edx
ret
GCC 11 (much better):
foo:
movzx eax, BYTE PTR [rdi+1]
add al, BYTE PTR [rdi]
add al, BYTE PTR [rdi+2]
add al, BYTE PTR [rdi+3]
ret
Best? llvm-mca says so..
foo:# @foo
movdxmm0, dword ptr [rdi] # xmm0 = mem[0],zero,zero,zero
pxorxmm1, xmm1
psadbw xmm1, xmm0
movdeax, xmm1
ret
https://godbolt.org/z/sT9svvj7W
[Bug tree-optimization/102564] New: Missed loop vectorization with reduction and ptr load/store inside loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102564
Bug ID: 102564
Summary: Missed loop vectorization with reduction and ptr
load/store inside loop
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
void test1(int *p, int *t, int N) {
for (int i = 0; i != N; i++) *t += p[i];
}
void test2(int *p, int *t, int N) {
if (N > 1024) // hint, N is not small
for (int i = 0; i != N; i++) *t += p[i];
}
void test3(int *p, int *t, int N) {
if (N > 1024) { // hint, N is not small
int s = 0;
for (int i = 0; i != N; i++) s += p[i];
*t += s;
}
}
test3 is successfully vectorized with LLVM, GCC, ICC. Sadly, only ICC can catch
test1 and test2.
https://godbolt.org/z/PzoYd4eEK
[Bug tree-optimization/103002] New: Missed loop unrolling opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103002
Bug ID: 103002
Summary: Missed loop unrolling opportunity
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
#define C 3
struct node {
struct node *next;
int payload;
};
static int count_nodes(const node* p) {
int size = 0;
while (p) {
p = p->next;
size++;
}
return size;
}
bool has_one_node(const node* p) {
return count_nodes(p) == 1;
}
bool has_C_nodes(const node* p) {
return count_nodes(p) == C;
}
has_one_node(node const*):# @has_one_node(node const*)
testrdi, rdi
je .LBB0_1
mov eax, 1
.LBB0_3:# =>This Inner Loop Header: Depth=1
mov rdi, qword ptr [rdi]
add eax, -1
testrdi, rdi
jne .LBB0_3
testeax, eax
seteal
ret
.LBB0_1:
xor eax, eax
ret
has_C_nodes(node const*): # @has_C_nodes(node const*)
testrdi, rdi
je .LBB1_1
mov eax, 3
.LBB1_3:# =>This Inner Loop Header: Depth=1
mov rdi, qword ptr [rdi]
add eax, -1
testrdi, rdi
jne .LBB1_3
testeax, eax
seteal
ret
.LBB1_1:
xor eax, eax
ret
has_C_nodes is simple with some kind of loop deletion pass, but generally,
these loops can be unrolled for some reasonable C values.
https://godbolt.org/z/do656c17b
[Bug rtl-optimization/7061] Access of bytes in struct parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7061 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #10 from Dávid Bolvanský --- llvm emits just: im: # @im shufps xmm0, xmm0, 85 # xmm0 = xmm0[1,1,1,1] ret
[Bug c++/117465] New: Disable -Wnonnull-compare in macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117465
Bug ID: 117465
Summary: Disable -Wnonnull-compare in macros
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
#include
#define DEBUG(ptr) if (ptr) printf("%p", (void *)ptr);
class Clz {
int data;
public:
Clz(void) {
DEBUG(this);
}
};
int main(void) {
int i;
DEBUG(&i);
Clz a;
return 0;
}
g++ -Wall -Wextra code.cpp
warning: 'nonnull' argument 'this' compared to NULL [-Wnonnull-compare]
3 | #define DEBUG(ptr) if (ptr) printf("%p", (void *)ptr);
This is quite annoying in macros. Derived from real code, where null check is
needed, as macro is universal.
