[Bug tree-optimization/94589] Optimize (i<=>0)>0 to i>0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589 Victor Khimenko changed: What|Removed |Added CC||khim at google dot com --- Comment #2 from Victor Khimenko --- Note that gcc looks bad even on the example from Microsoft's blog post: https://godbolt.org/z/Jc7TcN The fact that MSVC also looks bad on example from Microsoft is not really relevant, it's MSVC, after all. Blogpost itself is here: https://devblogs.microsoft.com/cppblog/simplify-your-code-with-rocket-science-c20s-spaceship-operator/
[Bug c++/96490] New: Template code with function pointers fails with very cryptic error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96490
Bug ID: 96490
Summary: Template code with function pointers fails with very
cryptic error message
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: khim at google dot com
Target Milestone: ---
The following code works with all other compilers: https://godbolt.org/z/Mv3xsn
template
class TagType;
int foo();
constexpr auto foo_ptr = &foo;
template
int test();
int bar() {
return test>();
}
int baz() {
return test>();
But GCC reports very cryptic error:
could not convert template argument 'foo_ptr' from 'int (* const)()' to 'int (*
const)()'
[Bug rtl-optimization/80491] New: Compiler regression for long-add case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491
Bug ID: 80491
Summary: Compiler regression for long-add case.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: khim at google dot com
Target Milestone: ---
Simple long addition program.
struct pair {
uint64_t low;
uint64_t hi;
};
pair add(pair& a, pair& b) {
pair s;
s.low = a.low + b.low;
s.hi = a.hi + b.hi + (s.low < a.low); //carry
return s;
}
Old versions of GCC produced adequate code:
$ gcc -S -O3 test.cc -o-
.file "test.cc"
.text
.p2align 4,,15
.globl _Z3addR4pairS0_
.type _Z3addR4pairS0_, @function
_Z3addR4pairS0_:
.LFB4:
.cfi_startproc
movq(%rdi), %rax
movq8(%rsi), %rdx
xorl%ecx, %ecx
addq8(%rdi), %rdx
addq(%rsi), %rax
setc%cl
addq%rcx, %rdx
ret
.cfi_endproc
.LFE4:
.size _Z3addR4pairS0_, .-_Z3addR4pairS0_
.ident "GCC: (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4"
.section.note.GNU-stack,"",@progbits
New version of gcc produces comparison and jump:
$ gcc -S -O3 test.cc -o-
.file "test.cc"
.text
.p2align 4,,15
.globl _Z3addR4pairS0_
.type _Z3addR4pairS0_, @function
_Z3addR4pairS0_:
.LFB4:
.cfi_startproc
xorl %ecx, %ecx
movq (%rsi), %rax
addq (%rdi), %rax
jc .L5
.L2:
movq 8(%rsi), %rdx
addq 8(%rdi), %rdx
addq %rcx, %rdx
ret
.L5:
movl $1, %ecx
jmp .L2
.cfi_endproc
.LFE4:
.size _Z3addR4pairS0_, .-_Z3addR4pairS0_
.ident "GCC: (GNU) 7.0.1 20170307 (experimental)"
.section .note.GNU-stack,"",@progbits
For comparison - clang produces perfect code here:
$ clang++ -S -O3 test1.cc -o-
.text
.file "test1.cc"
.globl _Z3addR4pairS0_
.p2align4, 0x90
.type _Z3addR4pairS0_,@function
_Z3addR4pairS0_:# @_Z3addR4pairS0_
.cfi_startproc
# BB#0:
movq(%rsi), %rax
movq8(%rsi), %rdx
addq8(%rdi), %rdx
addq(%rdi), %rax
adcq$0, %rdx
retq
.Lfunc_end0:
.size _Z3addR4pairS0_, .Lfunc_end0-_Z3addR4pairS0_
.cfi_endproc
.ident "Android clang version 4.0.285906 (based on LLVM 4.0.285906)"
.section".note.GNU-stack","",@progbits
[Bug rtl-optimization/80491] Compiler regression for long-add case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491
--- Comment #1 from Victor Khimenko ---
Actually even clang's version is not optimal ("addq 8(%rdi), %rdx" then "adcq
$0, %rdx" could be replaced with "adcq 8(%rdi), %rdx"). But at least both calng
and old version of gcc are smart enough to remove jumps from that code...
[Bug rtl-optimization/80491] Compiler regression for long-add case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80491 --- Comment #2 from Victor Khimenko --- An interesting observation: -O1 actually produces perfect code: $ gcc -S -O1 test.cc -o- .file "test.cc" .text .p2align 4,,15 .globl _Z3addR4pairS0_ .type _Z3addR4pairS0_, @function _Z3addR4pairS0_: .LFB4: .cfi_startproc movq(%rdi), %rax movq8(%rsi), %rdx addq(%rsi), %rax adcq8(%rdi), %rdx ret .cfi_endproc .LFE4: .size _Z3addR4pairS0_, .-_Z3addR4pairS0_ .ident "GCC: (GNU) 7.0.1 20170307 (experimental)" .section .note.GNU-stack,"",@progbits For some reason incrased optimization levels make code significantly worse here.
[Bug c++/114305] New: GCC doesn't use [[gnu::pure]] attribute on the inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114305
Bug ID: 114305
Summary: GCC doesn't use [[gnu::pure]] attribute on the inline
function
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: khim at google dot com
Target Milestone: ---
The following program is an illustration (https://godbolt.org/z/PYW34ccvP):
#include
GNU_PURE1 extern size_t foo(size_t);
template
GNU_PURE2 inline size_t test() {
return foo(size);
}
int test_func(int x, int y) {
return test() + test();
}
If GNU_PURE1 is [[gnu::pure]] then both gcc and clang optimize away second
call, if GNU_PURE2 is [[gnu::pure]] then only clang does that.
That means that it's impossible to add [[gnu::pure]] optimization on top of
function that's pure according to the docs but is not declared as such in the
header file.
