[Bug c++/114265] New: Unhelpful message when var name is also a struct name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114265
Bug ID: 114265
Summary: Unhelpful message when var name is also a struct name
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
While working with legacy code, I encountered the following problem.
The code:
struct Struct;
int fn(Struct *);
Struct *Struct;
int fn(Struct *)
{
return 0;
}
-
produces the following error message:
-
aa.c:7:8: error: 'int fn' redeclared as different kind of entity
7 | int fn(Struct *)
|^~
aa.c:3:5: note: previous declaration 'int fn(Struct*)'
3 | int fn(Struct *);
| ^~
aa.c:7:16: error: expected primary-expression before ')' token
7 | int fn(Struct *)
--
This message does not really explain what the real problem is.
A message saying that `Struct` has been redefined as a variable would help
more.
[Bug rtl-optimization/114228] New: memset/memcpy loop not always recognised with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114228
Bug ID: 114228
Summary: memset/memcpy loop not always recognised with -Os
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
typedef __SIZE_TYPE__ size_t;
void baz(char *);
void foo( char *__restrict buff, const char*__restrict input)
{
size_t max = __builtin_strlen (input);
for(size_t i = 0 ; i < max; ++i)
buff[i] = 0;
baz(buff);
}
void bar( char *__restrict buff, const char*__restrict input)
{
size_t max = __builtin_strlen (input);
for(size_t i = 0 ; i < max; ++i)
buff[i] = input[i];
baz(buff);
}
--
The code above, compiled with -Os, the current trunk fails to convert the two
loops into memcpy/memset.
gcc 13.2 is able to convert the loops into a call.
[Bug target/113269] New: X86_64 generates extra mov (and xchg) when passing struct with constant value to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113269
Bug ID: 113269
Summary: X86_64 generates extra mov (and xchg) when passing
struct with constant value to function
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
On today's trunk, compiled with g++
---
typedef struct s{
char *key, *value;
}s;
s *search(s);
s *find(char *word)
{
return search((s){.key = word});
}
s *find2(char *word)
{
s a = {.key = word, .value = 0};
return search(a);
}
compiled with -O2 produces a useless mov instruction in each function :
--
find(char*):
xor edx, edx
mov rsi, rdx
jmp search(s)
find2(char*):
xor edx, edx
mov rsi, rdx
jmp search(s)
--
compiled with -Oz, a useless mov and two useless xchg instructions are
produced.
---
find(char*):
xchgrdi, rax
xor edx, edx
xchgrax, rdi
mov rsi, rdx
jmp search(s)
find2(char*):
xchgrdi, rax
xor edx, edx
xchgrax, rdi
mov rsi, rdx
jmp search(s)
If the code is compiled with gcc, the mov instruction is not generated for
find2.
[Bug tree-optimization/113268] New: (i + (i + 1) * CST) AND (i + i * CST + 1 * CST) not folded the same way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113268
Bug ID: 113268
Summary: (i + (i + 1) * CST) AND (i + i * CST + 1 * CST) not
folded the same way
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
The two following functions should produce the same assembly with optimizations
enabled.
This lead, for exemple, to missed optimization with -Oz
---
#define CST 36
int foo(int i)
{
return i + (i + 1) * CST;
}
int bar(int i)
{
return i + i * CST + 1 * CST;
}
---
foo:
lea eax, [rdi+1]
imuleax, eax, 36
add eax, edi
ret
bar:
imuleax, edi, 37
add eax, 36
ret
[Bug rtl-optimization/113234] New: missing folding to builtin_isunordered if manual nan comparison is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113234
Bug ID: 113234
Summary: missing folding to builtin_isunordered if manual nan
comparison is used
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Compiled with -O1, on x86-64, f1 and f2 should produce the same code than f3
and f4, but f1 and f2 use two comparisons whereas f3 and f4 only use 1.
---
bool f1(float i, float j)
{
return i !=i || j != j;
}
bool f2(float i, float j)
{
return i == i && j == j;
}
bool f3(float i, float j)
{
return __builtin_isnan(i) || __builtin_isnan(j);
}
bool f4(float i, float j)
{
return !__builtin_isnan(i) && !__builtin_isnan(j);
}
---
It seems that gcc does not fold "f != f" to __builtin_isnan, or too late,
leading to the missed optimisation.
[Bug rtl-optimization/113231] New: x86_64 use MMX instructions for simple shift operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113231
Bug ID: 113231
Summary: x86_64 use MMX instructions for simple shift
operations
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Compiled with -Os, the following functions use MMX instructions for simple
shift.
--
void foo(int *i)
{
*i *=2;
}
void bar(int *i)
{
*i <<=2;
}
void baz(int *i)
{
*i >>=2;
}
--
foo(int*):
movdxmm0, DWORD PTR [rdi]
pslld xmm0, 1
movdDWORD PTR [rdi], xmm0
ret
bar(int*):
movdxmm0, DWORD PTR [rdi]
pslld xmm0, 2
movdDWORD PTR [rdi], xmm0
ret
baz(int*):
movdxmm0, DWORD PTR [rdi]
psrad xmm0, 2
movdDWORD PTR [rdi], xmm0
ret
-
I would expect the generated code to use "sar" or "sal" instructions like O2
uses.
The functions used to generate optimal code with version 9.5.
[Bug c++/108093] New: Quadratic error lines printed with missing include for template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108093 Bug ID: 108093 Summary: Quadratic error lines printed with missing include for template Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: denis.campredon at gmail dot com Target Milestone: --- Compiled with -std=c++20, who has only missing includes, the following code prints way too much lines of error. Adding or removing one template level drastically changes the number or error lines. using namespace std; vector>> foo; with std=c++17 only one line is printed : 'vector' does not name a type Ideally, both invocations should print 1 error per unknown type and add fix-hints for the missing includes.
[Bug rtl-optimization/107991] New: Extra mov instructions with ternary on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107991
Bug ID: 107991
Summary: Extra mov instructions with ternary on x86
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Compiled with -O2 on x86, gcc trunk produces 3 mov instructions for each of the
following functions:
int foo(bool b, int i, int j) {
return b ? i - j : i;
}
int bar(bool b, int i, int j) {
return i + (b ? -j : 0);
}
int baz(bool b, int i, int j) {
return i - (b ? j : 0);
}
-
Whearas with gcc 7.5, only 1 mov was produced for foo and bar, and two for baz
[Bug tree-optimization/107859] New: Fail to optimize rot13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107859
Bug ID: 107859
Summary: Fail to optimize rot13
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Compiled with -O2, the following functions produce different assembly although
they compute the same things:
unsigned rot13_1(unsigned c) {
if(c >= 'A' && c <= 'Z') return 'A' + ((c -'A') + 13)%26;
__builtin_unreachable();
}
unsigned rot13_2(unsigned c) {
if (c >= 'A' && c <= 'M' ) return c + 13;
else if (c >= 'N' && c <= 'Z' ) return c - 13;
__builtin_unreachable();
}
unsigned rot13_3(unsigned c) {
if(c >= 'A' && c <= 'Z') return c + (c > 'Z' - 13 ? -13 : 13);
__builtin_unreachable();
}
unsigned rot13_4(unsigned c) {
if(c >= 'A' && c <= 'Z') return c + 13 + (c > 'Z' - 13 ? -26 : 0);
__builtin_unreachable();
}
--
rot13_1(unsigned int):
lea edx, [rdi-52]
mov rax, rdx
imulrdx, rdx, 1321528399
shr rdx, 35
imuledx, edx, 26
sub eax, edx
add eax, 65
ret
rot13_2(unsigned int):
lea edx, [rdi-65]
lea eax, [rdi+13]
sub edi, 13
cmp edx, 12
cmova eax, edi
ret
rot13_3(unsigned int):
cmp edi, 78
sbb eax, eax
and eax, 26
lea eax, [rax-13+rdi]
ret
rot13_4(unsigned int):
cmp edi, 78
sbb eax, eax
not eax
and eax, -26
lea eax, [rax+13+rdi]
ret
[Bug tree-optimization/105883] New: Memcmp folded only when size is a power of two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105883
Bug ID: 105883
Summary: Memcmp folded only when size is a power of two
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Compiled with trunk and -O2, on x86-64, the testcase bellow shows, the calls to
memcmp are folded just when the size is a power of two. Other archs seems to
produce unoptimal code too.
If the arrays are declared const, everything is optimized as expected.
---
template
bool equals() {
T a[16] = {1,2,3,4,5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16};
T b[16] = {1,2,3,4,5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16};
static_assert(I <= sizeof a);
return !__builtin_memcmp(a, b, I);
}
template
bool not_equals() {
T a[16] = {1,2,3,4,5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16};
T b[16] = {0,2,3,4,5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16};
static_assert(I <= sizeof a);
return !__builtin_memcmp(a, b, I);
}
#define TEST \
template bool equals<1, char>(); \
template bool equals<2, char>(); \
template bool equals<3, char>(); \
template bool equals<4, char>(); \
template bool equals<5, char>(); \
template bool equals<7, char>(); \
template bool equals<8, char>(); \
template bool equals<15, char>(); \
template bool equals<16, char>(); \
template bool equals<1, long long>(); \
template bool equals<2, long long>(); \
template bool equals<3, long long>(); \
template bool equals<4, long long>(); \
template bool equals<5, long long>(); \
template bool equals<7, long long>(); \
template bool equals<8, long long>(); \
template bool equals<16, long long>(); \
template bool equals<17, long long>(); \
template bool equals<31, long long>(); \
template bool equals<32, long long>(); \
template bool equals<63, long long>(); \
template bool equals<64, long long>(); \
template bool equals<127, long long>(); \
template bool equals<128, long long>();
TEST
#define equals not_equals
TEST
[Bug target/105338] [12 Regression] Regression: jump or cmove generated for pattern (x ? CST : 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105338
--- Comment #13 from denis.campredon at gmail dot com ---
Thanks a lots.
I have a question though: foo and bar are similar, foo produces a branchless
code whereas bar uses a jump.
int foo(int i) {
return !i ? 0 : -2;
}
int bar(int i) {
return i ? -2 : 0;
}
If I'm readding correctly in the two functions the probabilities are the same.
Is this "normal" or worth a new ticket ?
[Bug rtl-optimization/105338] New: Regression: jump or cmove generated for pattern (x ? CST : 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105338
Bug ID: 105338
Summary: Regression: jump or cmove generated for pattern (x ?
CST : 0)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
int f(int i) {
return i ? 5 : 0;
}
int g(int i) {
return i ? -2 : 0;
}
int h(int b) {
return !!b * -2;
}
int i(int b) {
return !!b * 5;
}
int j(int b) {
if (!b) return 0;
return -2;
}
-
With -02 gcc 11.2 the five functions above output branchless code like:
f(int):
neg edi
sbb eax, eax
and eax, 5
ret
g(int):
neg edi
sbb eax, eax
and eax, -2
ret
...
--
Whereas -02 gcc 12 now outputs a cmov or jump depending of sign of the
constant:
f(int):
mov eax, edi
testedi, edi
mov edx, 5
cmovne eax, edx
ret
g(int):
mov eax, edi
testedi, edi
jne .L11
ret
.L11:
mov eax, -2
ret
h(int):
mov eax, edi
testedi, edi
jne .L17
ret
.L17:
mov eax, -2
ret
i(int):
mov eax, edi
testedi, edi
mov edx, 5
cmovne eax, edx
ret
j(int):
mov eax, edi
testedi, edi
mov edx, -2
cmovne eax, edx
ret
---
Alternatively, with the following code
int k(int b) {
bool b2 = b;
return b2 * 5;
}
Both gcc 12 and 11.2 are outputing
k(int):
xor eax, eax
testedi, edi
setne al
lea eax, [rax+rax*4]
ret
[Bug c/105276] New: [12 Regression] executed once loop not optimized anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105276
Bug ID: 105276
Summary: [12 Regression] executed once loop not optimized
anymore
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
bool foo(unsigned i) {
bool result = true;
while (i) {
i = i % 3;
i = i - (i==2 ? 2 : i ? 1 : 0);
result = !result;
}
return result;
}
--
compiled with g++ 11.2 and -O2 it produces:
-
foo(unsigned int):
testedi, edi
seteal
ret
With current trunk and -02 lots of instructions are generated, the loop is
still present, about 30 instructions are produced.
Also, when compiled with -Os trunk produces loopless assembly:
--
foo(unsigned int):
mov dl, 1
testedi, edi
je .L1
xor edx, edx
.L1:
mov eax, edx
ret
---
Whereas using -Os and g++ 11.2 it uses one less register:
--
foo(unsigned int):
mov al, 1
testedi, edi
je .L4
xor eax, eax
.L4:
ret
[Bug tree-optimization/104645] New: [12 Regression] i ? i % 2 : 0 not optimized anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104645
Bug ID: 104645
Summary: [12 Regression] i ? i % 2 : 0 not optimized anymore
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Was told to file a new PR for that case :
--
int foo(unsigned i) {
return i ? i % 2 : 0;
}
--
With trunk
foo(unsigned int):
mov eax, edi
xor edx, edx
and eax, 1
testedi, edi
cmove eax, edx
ret
---
With 11.2
---
foo(unsigned int):
mov eax, edi
and eax, 1
ret
---
According to Jakub Jelinek in PR104639 it started with
r12-5358-g32221357007666124409ec3ee0d3a1cf263ebc9e
[Bug tree-optimization/104639] [12 Regression] Useless loop not fully optimized anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104639
--- Comment #5 from denis.campredon at gmail dot com ---
That peace of code seems related but does not need a loop unlike the original
one.
--
int foo(unsigned i) {
return i ? i % 2 : 0;
}
--
With trunk 12
foo(unsigned int):
mov eax, edi
xor edx, edx
and eax, 1
testedi, edi
cmove eax, edx
ret
---
With 11.2
---
foo(unsigned int):
mov eax, edi
and eax, 1
ret
---
[Bug tree-optimization/104639] New: Useless loop not fully optimized anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104639
Bug ID: 104639
Summary: Useless loop not fully optimized anymore
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
the following code compiled with -02
---
bool foo(int i) {
while (i == 4)
i += 2;
return i;
}
--
Trunk generates the following assembly
-
foo(int):
cmp edi, 4
mov eax, 6
cmove edi, eax
testedi, edi
setne al
ret
-
whereas 11.2 generate more optimized assembly
-
foo(int):
testedi, edi
setne al
ret
[Bug middle-end/97968] [9/10/11/12 Regression] Unnecessary mov instruction with comparison and cmov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97968 --- Comment #3 from denis.campredon at gmail dot com --- This seems to be fixed for gcc12, unlike the code from pr-98303
[Bug tree-optimization/104106] Fail to remove stores to VLA inside loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104106 --- Comment #2 from denis.campredon at gmail dot com --- The missed optimisations are also present if the arrays are allocated with malloc or new.
[Bug tree-optimization/104106] New: Fail to remove some useless loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104106
Bug ID: 104106
Summary: Fail to remove some useless loop
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
In the following snippet none of the loops are removed when compiled with -O2
or -O3.
In f and g the optimizers shoulds detect that tmp_a is only written and never
read.
In h, only one index of tmp_a is read, so it should be the only one computed.
Ideally, if not too complex for gcc, the first two loops should be removed and
the computations, if any, done on the last loop.
-
int f(char *a, unsigned n) {
char tmp_a[n];
for (unsigned i = 1; i != n; i++) tmp_a[i] = a[i];
return a[0];
}
int g(char *a, int n) {
char tmp_a[n];
for (int i = 1; i < n; i++) tmp_a[i] = a[i] - a[i - 1];
return a[0];
}
int h(char *a, int n) {
char tmp_a[n];
for (int i = 0; i < n; i++) tmp_a[i] = a[i];
return tmp_a[1];
}
int i(char *a, char *b, int n) {
char tmp_a[n];
char tmp_b[n];
for (int i = 1; i < n; i++) tmp_a[i] = a[i] - a[i - 1];
for (int i = 1; i < n; i++) tmp_b[i] = b[i] - b[i - 1];
int result = 0;
for (int i = 1; i < n; i++) result += tmp_a[i] + tmp_b[i];
return result;
}
-
[Bug c++/104105] New: Unused nothrow new not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104105
Bug ID: 104105
Summary: Unused nothrow new not optimized
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
g++ can remove new calls when the result is unused, but fails to di the same
with nothrow new calls. f() could be compiled to an empty function with
optimisations on.
void f() {
new (std::nothrow) int(5);
new (std::nothrow) int[5];
}
[Bug c/103647] New: constant array comparison not always folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103647
Bug ID: 103647
Summary: constant array comparison not always folded
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
On trunk and gcc 11, with -O2 the following functions are not optimized to
xor eax, eax
bool f() {
char a[] = {'a', 'c'};
char b[] = {'a', 'b'};
return __builtin_memcmp(a, b, 2);
}
bool g() {
char a[] = {'a', 'b'};
char b[] = {'a', 'b', 'c'};
return __builtin_memcmp(a, b, 2);
}
.LC1:
.string "ab"
.LC0:
.string "ac"
f():
movzx eax, WORD PTR .LC1[rip]
cmp WORD PTR .LC0[rip], ax
setne al
ret
g():
cmp WORD PTR .LC1[rip], 25185
setne al
ret
[Bug tree-optimization/94802] Failure to recognize identities with __builtin_clz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94802 denis.campredon at gmail dot com changed: What|Removed |Added CC||denis.campredon at gmail dot com --- Comment #10 from denis.campredon at gmail dot com --- PR98236 is also somewhat related, and half of the problems should be solved by this patch.
[Bug tree-optimization/98278] New: switch optimisation and -fstrict-enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98278
Bug ID: 98278
Summary: switch optimisation and -fstrict-enums
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Created attachment 49761
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49761=edit
input file
The attached file, compiled with -O2 -fstrict-enums, only for `foobar` all
branches are transformed to a jump table.
If I did not made any mistake all the function should be able to be transformed
should produce the same assembly.
Changing the definition of the enum to
enum e { A = 1, B, C, D}; will produce worse code. Only one jumtable is
used/created.
enum e { A = 2, B = 4, C = 6, D = 8 }; (or any other sequence) no jump table is
created.
[Bug tree-optimization/98236] x plus/minus y cmp 0 produces unoptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98236 --- Comment #1 from denis.campredon at gmail dot com --- Created attachment 49734 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49734=edit assemble generated
[Bug tree-optimization/98236] New: x plus/minus y cmp 0 produces unoptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98236
Bug ID: 98236
Summary: x plus/minus y cmp 0 produces unoptimal code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Created attachment 49733
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49733=edit
input file
Compiling test.c on x86 with -O2 leads to unoptimal code generation.
f1 to f4 could be optimized to `add + set(g|ge|l|le)`
f5 to f8 could be optimized to `sud|cmp + set(g|ge|l|le)`
For f2, f4, f6 and f8 no pattern is recognized.
For f1, f3, f5 and f7, the optimizers are not aware that, at least on x86,
`add` and `sub` can set flags.
This can also be seen with the following function. gcc will produce `cmp + sub`
although only `sub` could be used
---
void foo();
int bar(int x, int y) {
if (x - y)
foo();
return x - y;
}
---
produces
---
bar(int, int):
pushrbp
mov ebp, esi
pushrbx
mov ebx, edi
sub rsp, 8
cmp edi, esi
je .L2
callfoo()
.L2:
mov eax, ebx
add rsp, 8
sub eax, ebp
pop rbx
pop rbp
ret
---
expected
---
bar(int, int):
pushrbx
mov ebx, edi
sub ebx, esi
je .L2
callfoo()
.L2:
mov eax, ebx
pop rbx
ret
---
[Bug rtl-optimization/98212] New: X86 unoptimal code for float equallity comparison followed by jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98212
Bug ID: 98212
Summary: X86 unoptimal code for float equallity comparison
followed by jump
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
For f1 code an unnecessary `comiss` instruction is used, the parity flag is
still set after the `jp` instruction.
For f2, I'm not sure if it's the optimal way to do that.
The same problems appear for `float`, `double` and `long double`
--
void f();
void f1(float a, float b) {
if (a != b)
f();
}
void f2(float a, float b) {
if (a == b)
f();
}
--
f1(float, float):
ucomiss xmm0, xmm1
jp .L4
comiss xmm0, xmm1
jne .L4
ret
.L4:
jmp f()
f2(float, float):
ucomiss xmm0, xmm1
jnp .L11
.L7:
ret
.L11:
jne .L7
jmp f()
--
[Bug tree-optimization/98169] isnan pattern not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98169
--- Comment #2 from denis.campredon at gmail dot com ---
This also applies to vector types.
---
typedef float __attribute__((vector_size(8))) T;
T f(T a) {
return a != a;
}
---
Gcc could generate:
--
f:
xorps xmm1, xmm1
cmpunordps xmm0, xmm1
ret
--
But instead generate a less optimal code:
--
f:
ucomiss xmm0, xmm0
mov edx, -1
movaps xmm1, xmm0
mov eax, 0
mov ecx, edx
shufps xmm1, xmm1, 0xe5
cmovnp ecx, eax
ucomiss xmm1, xmm1
movdxmm0, ecx
cmovp eax, edx
movdxmm2, eax
punpckldq xmm0, xmm2
ret
[Bug tree-optimization/98169] New: isnan pattern not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98169
Bug ID: 98169
Summary: isnan pattern not folded
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
The two following functions should produce the same assembly, at least on x86,
but for f1 gcc does not recognize the pattern for f1 and produce not optimal
code.
The problem is the same for all floating types.
bool f1(float a) {
return a == a;
}
bool f2(float a) {
return !__builtin_isnan(a);
}
Furthermore, for __float128, instead of calling __unordtf2 the following code
call __netf2
bool f3(__float128 a) {
return a != a;
}
[Bug tree-optimization/98028] New: __builtin_sub_overflow_p not folded to const when some constraints are known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98028
Bug ID: 98028
Summary: __builtin_sub_overflow_p not folded to const when some
constraints are known
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
According to godbolt, f1 used to be optimised with gcc 7.
The same problem can be seen with signed types (and maybe more conditions?).
All the following functions should be only one instruction plus ret with O2
-
unsigned f1(unsigned i, unsigned j) {
if (j != i) __builtin_unreachable();
return __builtin_sub_overflow_p(i, j, (unsigned)0);
}
unsigned f2(unsigned i, unsigned j) {
if (j > i) __builtin_unreachable();
return __builtin_sub_overflow_p(i, j, (unsigned)0);
}
unsigned f3(unsigned i, unsigned j) {
if (j >= i) __builtin_unreachable();
return __builtin_sub_overflow_p(i, j, (unsigned)0);
}
unsigned f4(unsigned i, unsigned j) {
if (j < i) __builtin_unreachable();
return __builtin_sub_overflow_p(i, j, (unsigned)0);
}
-
[Bug tree-optimization/98026] New: optimization dependant on condition order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98026
Bug ID: 98026
Summary: optimization dependant on condition order
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
In all the following functions gcc should recognize that j can't be greater
than 100, and link_error should not appear in assembly. Currently only f3 is
optimized.
---
void link_error();
void f1(int i, int j) {
if (j > i || i > 100) return;
if (j > 100) link_error();
}
void f2(int i, int j) {
if (i > 100 || j > i) return;
if (j > 100) link_error();
}
void f3(int i, int j) {
if (i > 100) return;
if (j > i) return;
if (j > 100) link_error();
}
void f4(signed int i,unsigned int j) {
if (i > 100) return;
if (j > i) return;
if (j > 100) link_error();
}
--
[Bug rtl-optimization/97968] New: Unnecessary mov instruction with comparison and cmov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97968
Bug ID: 97968
Summary: Unnecessary mov instruction with comparison and cmov
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
The same problem applies with all comparison operators but '==' for 'int' and
'long' on x86-64.
(Returning a negative value instead of 0 makes the compiler generate a jump
instead of a cmov. I don't know if it's worth a bug)
---
int f(int n, int j)
{
return n > j ? n : 0;
}
---
with O2 produces
---
f(int, int):
mov eax, edi
cmp edi, esi
mov edx, 0
cmovle eax, edx
ret
---
Ideally it should produce something like that. (the first mov can be deleted
with some little changes later)
---
f(int, int):
mov eax, 0
cmp edi, esi
cmovg eax, edi
ret
---
[Bug tree-optimization/97950] Unoptimal code generation with __builtin_*_overflow{,_p} for short and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950 --- Comment #2 from denis.campredon at gmail dot com --- Thanks for your fast patch. I've opened PR97961 for the __int128 problem
[Bug tree-optimization/97961] New: unnecessary moves with __builtin_{add,sub}_overflow_p and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97961
Bug ID: 97961
Summary: unnecessary moves with __builtin_{add,sub}_overflow_p
and __int128
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
In #97950 Jackub told me to open a new bug for that.
The snippet bellow has the following problems
- f1 and f2 generate 4 unnecessary moves
mov r9, rdi
mov r8, rsi
mov rsi, r9
mov rdi, r8
- f4 has "only" 2 unnecessary moves
mov r9, rdi
mov rdi, rsi
- f3 should be identical to f4 except for the flag checking.
bool f1(unsigned __int128 a,unsigned __int128 b) {
return __builtin_add_overflow_p(a, b, (unsigned __int128)0);
}
bool f2(__int128 a,__int128 b) {
return __builtin_add_overflow_p(a, b, (__int128)0);
}
bool f3(unsigned __int128 a,unsigned __int128 b) {
return __builtin_sub_overflow_p(a, b, (unsigned __int128)0);
}
bool f4(__int128 a,__int128 b) {
return __builtin_sub_overflow_p(a, b, (__int128)0);
}
asm generated
f1(unsigned __int128, unsigned __int128):
mov r9, rdi
mov r8, rsi
mov rsi, r9
mov rdi, r8
add rsi, rdx
adc rdi, rcx
setcal
ret
f2(__int128, __int128):
mov r9, rdi
mov r8, rsi
mov rsi, r9
mov rdi, r8
add rsi, rdx
adc rdi, rcx
setoal
ret
f3(unsigned __int128, unsigned __int128):
mov r9, rdi
mov r8, rsi
mov rdi, r8
mov rax, r9
mov r8, rdx
sub rax, r8
mov rdx, rdi
sbb rdx, rcx
cmp r9, rax
mov rcx, rdi
sbb rcx, rdx
setcal
ret
f4(__int128, __int128):
mov r9, rdi
mov rdi, rsi
cmp r9, rdx
sbb rdi, rcx
setoal
ret
---
[Bug tree-optimization/97950] New: Unoptimal code generation with __builtin_*_overflow{,_p} for short and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950
Bug ID: 97950
Summary: Unoptimal code generation with
__builtin_*_overflow{,_p} for short and __int128
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
For the following code, the generation is unoptimal on x86-64.
For most of the functions with `short` a jump is generated.
For the functions with `__int128` all but `mul_overflow_{,un}signed___int128`
seems to have extra `mov` produced.
The same problems apply to all the `__builtin_*_overflow_p`
-
#define TEST_OVERFLOW(type) \
bool mul_overflow_signed_##type(signed type a, signed type b, signed type c)
{return __builtin_mul_overflow(a,b,);} \
bool add_overflow_signed_##type(signed type a, signed type b, signed type c)
{return __builtin_add_overflow(a,b,);} \
bool sub_overflow_signed_##type(signed type a, signed type b, signed type c)
{return __builtin_sub_overflow(a,b,);} \
bool mul_overflow_unsigned_##type(unsigned type a, unsigned type b, unsigned
type c) {return __builtin_mul_overflow(a,b,);} \
bool add_overflow_unsigned_##type(unsigned type a, unsigned type b, unsigned
type c) {return __builtin_add_overflow(a,b,);} \
bool sub_overflow_unsigned_##type(unsigned type a, unsigned type b, unsigned
type c) {return __builtin_sub_overflow(a,b,);} \
TEST_OVERFLOW(short)
TEST_OVERFLOW(__int128)
-
[Bug c++/88577] New: misleading error message with template and auto return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88577
Bug ID: 88577
Summary: misleading error message with template and auto return
type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
For the following code
template struct s{}
auto f() {}
g++ produces a rather misleading error message:
:3:1: error: multiple types in one declaration
3 | auto f() {}
| ^~~~
:3:5: error: expected ';' before 'f'
3 | auto f() {}
| ^~
| ;
If the template is removed, or the return type is changed the compiler suggest
the good place for the missing semi colon.
[Bug tree-optimization/88314] New: range calculation of shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88314
Bug ID: 88314
Summary: range calculation of shift
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
gcc is not able to determine that the possible values of res are 0, 8, 16, 32
and so the following function is not optimized :
--
bool f(bool a, bool b, bool c) {
int res = (a + b) << (1 + c) << 2;
return res > 0 && res < 8;
}
-
[Bug tree-optimization/88280] missing folding of logical and bitwise AND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88280
--- Comment #2 from denis.campredon at gmail dot com ---
I don't know if I should create a separate bug report or not, since it looks
kind of related.
I've tried to replace the operator of the function e with other and it
generates a branch with the following operators
--
int b_and(int i, int a) {
return i && i & a;
}
int b_or(int i, int a) {
return i && i | a;
}
int add(int i, int a) {
return i && i + a;
}
int mult(int i, int a) {
return i && i * a;
}
int left(int i, int a) {
return i && i << a;
}
int right(int i, int a) {
return i && i >> a;
}
int l_or(int i, int a) {
return i && (i || a);
}
--
But does not with :
--
int b_xor(int i, int a) {
return i && i ^ a;
}
int sub(int i, int a) {
return i && i - a;
}
[Bug tree-optimization/88280] New: missing folding of logical and bitwise AND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88280
Bug ID: 88280
Summary: missing folding of logical and bitwise AND
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
The following functions should all produce the same code with optimisations on
(it is the same if `a' is replaced with a constant)
-
int e(int i, int a) {
return i && i & a;
}
int f(int i, int a) {
return i & a && i;
}
int g(int i, int a) {
int j = i & a;
return j && i;
}
int h(int i, int a) {
int j = i & a;
return i && j;
}
-
But currently only f produces good assembly:
f(int, int):
xor eax, eax
testedi, esi
setne al
ret
[Bug tree-optimization/84312] New: Variadic function without named argument not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84312
Bug ID: 84312
Summary: Variadic function without named argument not inlined
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
--
int a;
static inline void f2 (...) {a++;}
void f1 (void) { f2 (0); }
--
g++ with optimisations enabled inlines f2 only when f2 is empty or when it is
called with 0 arguments.
When compiled with -Winline the code above produces the following warning
which is I think wrong :
--
main.cpp: In function 'void f1()':
main.cpp:3:20: warning: inlining failed in call to 'void f2(...)': mismatched
arguments [-Winline]
static inline void f2 (...) {a++;}
^~
main.cpp:4:21: note: called from here
void f1 (void) { f2 (0); }
~~~^~~
-
[Bug c++/83798] New: Enhancement to Wmain warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83798
Bug ID: 83798
Summary: Enhancement to Wmain warnings
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Compiled with g++ the following code produces some rather confusing warnings:
---
int main(short s, void** t, int** u, int** v) {}
---
1 : :1:5: warning: first argument of 'int main(short int, void**,
int**, int**)' should be 'int' [-Wmain]
int main(short s, void** t, int** u, int** v) {}
^~~~
1 : :1:5: warning: second argument of 'int main(short int, void**,
int**, int**)' should be 'char **' [-Wmain]
1 : :1:5: warning: third argument of 'int main(short int, void**,
int**, int**)' should probably be 'char **' [-Wmain]
1 : :1:5: warning: 'int main(short int, void**, int**, int**)' takes
only zero or two arguments [-Wmain]
---
In the first three warnings, just '::main' should be displayed, like when
compiled with gcc, instead of the full signature.
For the fourth one, we can see that gcc also accepts three arguments in main,
for the env, not only 0 or 2.
[Bug c++/83797] New: Inconsistent error messages for main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83797
Bug ID: 83797
Summary: Inconsistent error messages for main
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
In the following snippet:
-
inline static constexpr short main() {
}
-
1 : :1:36: error: cannot declare '::main' to be inline
inline static constexpr short main() {
^
1 : :1:36: error: cannot declare '::main' to be 'constexpr'
1 : :1:36: error: cannot declare '::main' to be static
1 : :1:36: error: '::main' must return 'int'
-
'int' and 'constexpr' are quoted whereas 'inline' and 'static' are not.
In this one 'main' is not preceded by '::' whereas in all the previous warnings
it is.
main() {}
1 : :1:6: warning: ISO C++ forbids declaration of 'main' with no type
[-Wreturn-type]
main(){}
^
[Bug tree-optimization/83311] New: Unable to optimize alloc calls with casts and string builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83311
Bug ID: 83311
Summary: Unable to optimize alloc calls with casts and string
builtins
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Hello,
The fix for #pr83128 does not optimize the following testcase which should
produce the same result
int fn() {
// same with malloc or calloc
char * s = __builtin_alloca(sizeof(*s));
return ((char*)__builtin_memcpy(s, "a", 1))[0];
}
-
Regards,
Denis
[Bug tree-optimization/83128] Unable to optimize {m,c}alloc when strings builtin are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83128
--- Comment #4 from denis.campredon at gmail dot com ---
Hi Richard,
Thanks for your quick response.
I don't know if I should open a new bug or not, but your patch does not seems
to handle casts. It fails to optimize the following snippet.
int fn() {
char * s = malloc(sizeof(*s));
return ((char*)__builtin_memcpy(s, "a", 1))[0];
}
Regards,
Denis
[Bug tree-optimization/83129] New: calloc zero initialization is not taken into account by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83129
Bug ID: 83129
Summary: calloc zero initialization is not taken into account
by gcc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
It seems that GCC does not know that calloc initialize the memory to zero.
The the following functions could be optimized to the same assemble, but only
f3 is optimized to:
xor eax, eax
ret
--
int f1() {
char * i = __builtin_calloc(1, 1);
return *i;
}
int f2() {
struct s{int i;}* a = __builtin_calloc(1, sizeof(*a));
return a->i;
}
int f3() {
char * i = (char*)__builtin_calloc(1, 1);
i[0] = 0;
return *i;
}
--
[Bug tree-optimization/83128] New: Unable to optimize {m,c}alloc when strings builtin are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83128
Bug ID: 83128
Summary: Unable to optimize {m,c}alloc when strings builtin are
used
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Currently gcc with -03 is able to optimize
--
char f() {
char * i = (char*)__builtin_malloc(100);
i[0] = 'a';
return i[0];
}
--
to
--
mov al, 97
ret
But is unable to do the same when string builtins are used with either malloc
or calloc.
-
char f() {
char * i = (char*)__builtin_malloc(100);
__builtin_memcpy(i, "a", 1);
return i[0];
}
-
[Bug c++/82295] New: Two errors produced with private/protected deleted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82295
Bug ID: 82295
Summary: Two errors produced with private/protected deleted
methods
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Hello,
The following code produces
---
class C {
int f() = delete;
};
int f() {
return C().f();
}
--
Will produce the followings messages
---
: In function 'int f()':
:6:15: error: 'int C::f()' is private within this context
return C().f();
^
:2:6: note: declared private here
int f() = delete;
^
:6:15: error: use of deleted function 'int C::f()'
return C().f();
^
:2:6: note: declared here
int f() = delete;
^
-
Since the method is deleted only the second error should be displayed.
[Bug c++/81086] New: ICE with structured binding of initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81086
Bug ID: 81086
Summary: ICE with structured binding of initializer_list
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
The following code make the compiler emit an ICE with the latest snapshot
:3:13: internal compiler error: in write_unqualified_name, at
cp/mangle.c:1318
#include
auto [a] = {0};
-
g++ 7.1 does not ICE
[Bug tree-optimization/80874] gcc does not emit cmov for minmax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80874
--- Comment #1 from denis.campredon at gmail dot com ---
Sorry, minmax3 should not produce the same asm, since minmax return a pair of
const reference.
But still the code is less than optimal.
One part it is because gcc might be because gcc is not able to optimize the two
functions the same way:
---
struct pair {
const int , y;
};
pair minmax(int x) {
return {x, x};
}
const std::pair minmax2(int x) {
return std::minmax(x, x);
}
--
[Bug tree-optimization/80874] New: gcc does not emit cmov for minmax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80874
Bug ID: 80874
Summary: gcc does not emit cmov for minmax
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Hello,
Considering the following code:
--
struct pair {
int min, max;
};
pair minmax1(int x, int y) {
if (x > y)
return {y, x};
else
return {x, y};
}
#include
std::pair<int, int> minmax2(int x, int y) {
return std::minmax(x, y);
}
auto minmax3(int x, int y) {
return std::minmax(x, y);
}
---
I've found that for minmax1 and minmax 2, gcc fails to emit cmov at -03.
Instead it produces the following:
minmax1(int, int):
cmp edi, esi
jle .L2
mov eax, edi
mov edi, esi
mov esi, eax
.L2:
mov eax, edi
sal rsi, 32
or rax, rsi
ret
For minmax3, the asm should be the same (I think), but it produces a more
complex code.
[Bug c++/80789] New: Better error for passing lambda with capture as function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80789
Bug ID: 80789
Summary: Better error for passing lambda with capture as
function pointer
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
With the following code:
-
void g(void (*)());
void f() {
int x;
g([x](){});
}
--
gcc produce this error:
main.cpp: In function 'void f()':
main.cpp:5:14: error: cannot convert 'f()::<lambda()>' to 'void (*)()' for
argument '1' to 'void g(void (*)())'
g([x](){});
It is not clear why the lambda is not accepted since calling g with a lambda
with no capture produce no error.
A better error would say something like:
'cannot convert a lambda with capture to function pointer'.
And maybe a hint telling to use a "std::function" instead.
Regards,
Denis
[Bug c++/77846] Wrong error recovery with switch, goto and initialization skipped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77846
--- Comment #1 from denis.campredon at gmail dot com ---
I'm pretty sure it is linked the following code, compiled with '-fpermissive'
only prints A instead of AB
--
enum E{ A, B };
class C {public:C(){};};
static inline
void f(E e) {
if (0)
goto out;
switch (e) {
case A:
__builtin_printf("A");
C c;
break;
case B:
__builtin_printf("B");
}
out:{}
}
int main() {
f(E::B);
f(E::A);
return 0;
}
-
[Bug c++/77846] New: Wrong error recovery with switch, goto and initialization skipped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77846
Bug ID: 77846
Summary: Wrong error recovery with switch, goto and
initialization skipped
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Compiling the following code with -Wswitch
---
enum E {A, B};
class C {public: C();};
void f(E e) {
goto out;
switch (e) {
case A:
C c;
case B:;
}
out:{}
}
---
main.cpp: In function 'void f(E)':
main.cpp:9:14: error: jump to case label [-fpermissive]
case B:;
^
main.cpp:8:11: note: crosses initialization of 'C c'
C c;
^
main.cpp:6:12: warning: enumeration value 'B' not handled in switch [-Wswitch]
switch (e) {
^
The warning
main.cpp:6:12: warning: enumeration value 'B' not handled in switch [-Wswitch]
Is wrong since B is handled in the switch.
Also it would be nice if the line of the goto and the line of the label were
shown in the output, something like:
Jumping from `goto' to `label' crosses the initialization of 'c, d, ...
[Bug c++/72806] New: Extra note/missing not location for __builtin_va_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72806 Bug ID: 72806 Summary: Extra note/missing not location for __builtin_va_list Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: denis.campredon at gmail dot com Target Milestone: --- Compiling the following code void f(struct __builtin_va_list* ap); Will result in an unfinished message ./Messages.h:1:15: error: using typedef-name ‘__builtin_va_list’ after ‘struct’ void f(struct __builtin_va_list* ap); ^ cc1plus: note: ‘__builtin_va_list’ has a previous declaration here I would expect no note or the compiler saying that __builtin_va_list is a builtin_type.
[Bug c++/71982] New: Wrong error and note range with macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71982
Bug ID: 71982
Summary: Wrong error and note range with macro
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Created attachment 38956
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38956=edit
Reproducer to the bug
Compiling the attached file with `g++ ./bug.cpp' show an erroneous error
range:
./bug.cpp: In instantiation of ‘bool operator==(const A&, const A&) [with
T = const B]’:
./bug.cpp:25:30: required from here
./bug.cpp:1:34: error: no match for ‘operator==’ (operand types are ‘const B’
and ‘const B’)
#define MACRO(left, right) *left == *right
~~^
template
~
struct A {
~~
T *a;
~
T* get() const;
~~~
};
~~
template
~
bool operator==(const A& left, const A& right)
{
~
T* _left = left.get();
~~
T* _right = right.get();
return MACRO(_left, _right);
~
./bug.cpp:15:10: note: in expansion of macro ‘MACRO’
return MACRO(_left, _right);
^
./bug.cpp:10:6: note: candidate: template bool operator==(const A&,
const A&)
bool operator==(const A& left, const A& right)
^~~~
./bug.cpp:10:6: note: template argument deduction/substitution failed:
./bug.cpp:1:34: note: ‘const B’ is not derived from ‘const A’
#define MACRO(left, right) *left == *right
~~^
template
~
struct A {
~~
T *a;
~
T* get() const;
~~~
};
~~
template
~
bool operator==(const A& left, const A& right)
{
~
T* _left = left.get();
~~
T* _right = right.get();
return MACRO(_left, _right);
~
./bug.cpp:15:10: note: in expansion of macro ‘MACRO’
return MACRO(_left, _right);
^
./bug.cpp:24:6: note: candidate: bool operator==(C&, C&)
bool operator==(C& left, C& right) {
^~~~
./bug.cpp:24:6: note: no known conversion for argument 1 from ‘const B’ to
‘C&’
compiled with gcc version 7.0.0 20160716 (experimental) (GCC)
[Bug c++/71718] New: ICE on erroneous recursive template error printing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71718
Bug ID: 71718
Summary: ICE on erroneous recursive template error printing
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
template
class A : T{};
template
using sp = A;
struct Base {};
template
const sp
rec()
{
return rec<T, num - 1>();
}
static void f(void) {
rec();
}
---
This erroneous code compiled with g++ (6.1.0) produces an ice with the
following backtrace.
0x62b536 push_tinst_level_loc(tree_node*, unsigned int)
../../gcc-6.1.0/gcc/cp/pt.c:9077
0x63c942 push_tinst_level(tree_node*)
../../gcc-6.1.0/gcc/cp/pt.c:9061
0x63c942 instantiate_alias_template
../../gcc-6.1.0/gcc/cp/pt.c:17466
0x63c942 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-6.1.0/gcc/cp/pt.c:12842
0x66fef0 dump_template_bindings
../../gcc-6.1.0/gcc/cp/error.c:349
0x66fef0 dump_substitution
../../gcc-6.1.0/gcc/cp/error.c:1450
0x675964 decl_to_string
../../gcc-6.1.0/gcc/cp/error.c:2955
0x675964 cp_printer
../../gcc-6.1.0/gcc/cp/error.c:3535
0x115928c pp_format(pretty_printer*, text_info*)
../../gcc-6.1.0/gcc/pretty-print.c:631
0x1159ff0 pp_format_verbatim(pretty_printer*, text_info*)
../../gcc-6.1.0/gcc/pretty-print.c:690
0x115a0c4 pp_verbatim(pretty_printer*, char const*, ...)
../../gcc-6.1.0/gcc/pretty-print.c:891
0x66f029 print_instantiation_partial_context_line
../../gcc-6.1.0/gcc/cp/error.c:3335
0x66f029 print_instantiation_partial_context
../../gcc-6.1.0/gcc/cp/error.c:3445
0x66f029 print_instantiation_full_context
../../gcc-6.1.0/gcc/cp/error.c:3324
0x66f029 maybe_print_instantiation_context
../../gcc-6.1.0/gcc/cp/error.c:3461
0x67313f cp_diagnostic_starter
../../gcc-6.1.0/gcc/cp/error.c:3154
0x1154e97 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc-6.1.0/gcc/diagnostic.c:824
0x11562a1 fatal_error(unsigned int, char const*, ...)
../../gcc-6.1.0/gcc/diagnostic.c:1239
0x62b536 push_tinst_level_loc(tree_node*, unsigned int)
../../gcc-6.1.0/gcc/cp/pt.c:9077
0x63c942 push_tinst_level(tree_node*)
../../gcc-6.1.0/gcc/cp/pt.c:9061
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug c++/71566] Attribute [[aligned(16)]] on function is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71566 denis.campredon at gmail dot com changed: What|Removed |Added CC||denis.campredon at gmail dot com --- Comment #1 from denis.campredon at gmail dot com --- You have to change `[[aligned(16)]]' to `[[gnu::aligned(16)]]' as attribute aligned is a gnu extension to the standard.
[Bug tree-optimization/71558] New: missed optimization for type short, char and floating point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71558
Bug ID: 71558
Summary: missed optimization for type short, char and floating
point types
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
for the following code gcc should produce the same code for fun and fun2, but
fail for shorts and char with -01 and higher. It also fails for floating types
with -0fast
-
#define optimize(type) \
type fun(type i, type j)\
{ \
return i + j; \
} \
type fun2(type i, type j) \
{ \
if (j == 0) \
return i; \
else if (i == 0) \
return j; \
else \
return i + j; \
}
optimize(int);
optimize(char);
optimize(short);
For all types the optimization is no longer performed if any type is different
from the other
int fun2(unsigned i, int j)
{
if (i == 0)
return j;
else if (j == 0)
return i;
else
return i + j;
}
And if we are testing if both i and j are 0 the optimization is no longer
performed
--
int fun2(int i, int j)
{
if (i == 0 && j == 0)
return j; //or "return i + j;" or "return 0;" or "return i;"
if (i == 0)
return j;
else if (j == 0)
return i;
else
return i + j;
}
---
It also fails if one replace the addition with a subtraction or a
multiplication (with changed return values.)
[Bug c++/71542] New: unhelpfull error for wrong initializer of initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71542
Bug ID: 71542
Summary: unhelpfull error for wrong initializer of initializer
list
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
For the following code
#include
struct s
{
int *i;
};
void f()
{
std::initializer_list initializer = {{false}};
s array[] = {{true}, {true}};
}
---
g++ emits the following error message :
---
main.cpp: In function 'void f()':
main.cpp:10:42: error: could not convert '{{false}}' from '' to 'std::initializer_list'
std::initializer_list a = {{false}};
^
main.cpp:11:32: error: cannot convert 'bool' to 'int*' in initialization
s array[] = {{true}, {true}};
^
main.cpp:11:32: error: cannot convert 'bool' to 'int*' in initialization
--
But the message for the initializer_list is not really helpfull. I'd expect a
similar message than with the array.
[Bug c++/48050] New: [c++] ice with c++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48050 Summary: [c++] ice with c++ code Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: denis.campre...@gmail.com Created attachment 23606 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23606 reduced preproceded file whith this command : g++ test-min.i gcc emit this message : /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.5/include/stddef.h: In constructor ‘std::Poney::Poney()’: /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.5/include/stddef.h:2164: internal compiler error: Segmentation fault Here are the configurations: Target: x86_64-unknown-linux-gnu Configured with: ./configure Thread model: posix gcc version 4.4.5 (GCC) I tried to with GCC 4.5 a week ago, and there was the ICE too
