https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545
--- Comment #6 from AK ---
> We can use memchr to find a char in a range of signed char, or even to find
> an int in a range of signed char, as long as we're careful about values.
+1, this approach should fix the bug i reported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #5 from AK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115041
Bug ID: 115041
Summary: Missed optimization opportunity in std::find of
std::vector elements
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107263
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #3 from AK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59863
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #9 from AK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114342
AK changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114342
Bug ID: 114342
Summary: suboptimal codegen of vector::vector(range)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111806
--- Comment #1 from AK ---
It seems like we could 'sink' the 4 common instructions (of .L2) at -O3
L2:
add rsp, 48
xor eax, eax
pop rbx
ret
Or is it due to some kind of tail duplication?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111806
Bug ID: 111806
Summary: g++ generates better code for variant at
-Os compared to -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111805
Bug ID: 111805
Summary: suboptimal codegen of variant
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420
--- Comment #6 from AK ---
To confirm what Andrew mentioned, the release build (-O3) built successfully.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420
AK changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420
--- Comment #4 from AK ---
good catch. By mistake i built at -O0, i wanted to build at -O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420
--- Comment #1 from AK ---
I got this error while building clang (ninja clang) on a riscv machine.
root@lpi4a:~# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/riscv64-linux-gnu/13/lto-wrapper
Target:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420
Bug ID: 111420
Summary: relocation truncated to fit: R_RISCV_JAL against
`.L12287'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393
--- Comment #9 from AK ---
i think it is okay to close this bug as this doesn't seem to be related to gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393
--- Comment #8 from AK ---
> this does seem like a HW issue. Are you sure you have a decent RISCV machine
> without any memory issues?
> I suspect ninja is building with all of the cores which pushes the memory
> usage high.
possible. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393
--- Comment #5 from AK ---
Created attachment 55890
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55890=edit
GlobalModuleIndex.cpp preprocessed files
Everytime the crash is in a different file. it could be just because of memory
issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393
--- Comment #3 from AK ---
gcc -v
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/riscv64-linux-gnu/13/lto-wrapper
Target: riscv64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 13.1.0-6'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393
--- Comment #1 from AK ---
oot/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/build# ninja clang
check-clang
[100/845] Building CXX object
tools/clang/lib/Serialization/CMakeFiles/obj.clangSerialization.dir/GlobalModuleIndex.cpp.o
FAILED:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393
Bug ID: 111393
Summary: ICE: Segmentation fault src/gcc/toplev.cc:314
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110909
Bug ID: 110909
Summary: Suboptimal codegen in vector copy assignment
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #3 from AK ---
1. clang also has noalias on nothrow versions of operator new. will
`-fassume-sane-operator-new` enable that as well?
2. as per: http://eel.is/c++draft/basic.stc.dynamic#allocation-2
"""If the request succeeds, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110819
--- Comment #2 from AK ---
> When compiled with clang, libstdc++'s std::vector uses __builtin_operator_new
> which always has the -fassume-sane-operator-new semantics, and so can be
> optimized.
yes clang optimizes with libstdc++ as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110819
Bug ID: 110819
Summary: Missed optimization: when vector size is 0 but
vector::reserve has been called.
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #17 from AK ---
With recent changes in libc++ (https://reviews.llvm.org/D147741) clang
optimizes away the new-delete pair. https://godbolt.org/z/a6PG54Pvb
$ clang++ -O3 -stdlib=libc++ -fno-exceptions
vat1(std::__1::vector >): #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #17 from AK ---
Even after vector::size() is hoisted, the codegen is sub-optimal compared to
iterator version.
```
void use_idx_const_size(std::vector v) {
auto s = v.size();
for (std::vector::size_type i = 0; i < s; i++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811
--- Comment #8 from AK ---
Should we enable frame-pointers by default for RISCV64 as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #4 from AK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87628
--- Comment #6 from AK ---
Opened a bug for clang as well:
https://github.com/llvm/llvm-project/issues/62783
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87628
--- Comment #5 from AK ---
As per: https://en.cppreference.com/w/cpp/memory/new/operator_delete
"""
In all cases, if ptr is a null pointer, the standard library deallocation
functions do nothing. If the pointer passed to the standard library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441
--- Comment #3 from AK ---
> But IMHO it's academic, right?
yes. i was just messing with vector codegen. But in case all the elements of a
vector/array are same, maybe the loop can be replaced with equivalent
computation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35269
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #2 from AK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #1 from AK ---
Link to issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35269 where I
derived the testcase from.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
Bug ID: 109443
Summary: missed optimization of std::vector access (Related to
issue 35269)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
Bug ID: 109442
Summary: Dead local copy of std::vector not removed from
function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441
--- Comment #1 from AK ---
I guess a better test case is this:
#include
using namespace std;
using T = int;
T v(std::vector v) {
T s;
std::fill(v.begin(), v.end(), T());
for (auto i = 0; i < v.size(); ++i) {
s += v[i];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441
Bug ID: 109441
Summary: missed optimization when all elements of vector are
known
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109440
Bug ID: 109440
Summary: Missed optimization of vector::at when a function is
called inside the loop
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108915
--- Comment #6 from AK ---
For reference, I had opened a related bug in clang:
https://github.com/llvm/llvm-project/issues/60967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109017
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #1 from AK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108915
AK changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #4 from AK ---
Adding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108915
Bug ID: 108915
Summary: invalid pointer access preserved in optimized code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107335
AK changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107335
--- Comment #5 from AK ---
Is this the definition of throw_bad_cast?
https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/gcc/cp/rtti.c#L221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107335
--- Comment #4 from AK ---
I wasn't sure if this is expected. Thanks for clarifying.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107335
Bug ID: 107335
Summary: call to throw_bad_cast even with -fno-exceptions
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85611
AK changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107063
Bug ID: 107063
Summary: [X86_64 codegen] Using inc eax instead of inc dword
ptr
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107011
--- Comment #2 from AK ---
ah ok. sorry for the noise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107011
Bug ID: 107011
Summary: instruction with undefined behavior not optimized away
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95565
--- Comment #2 from AK ---
clang has `-finstrument-function-entry-bare` to this effect:
https://reviews.llvm.org/D40276
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107005
Bug ID: 107005
Summary: gcc not exploiting undefined behavior to optimize away
the result of division
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106991
--- Comment #3 from AK ---
Thanks for identifying the underlying issue @Jan
After modifying the definition of operator delete. gcc does optimize it at -O3
as well.
https://godbolt.org/z/1WPqaWrEr
// source code
#include
#include
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87628
--- Comment #4 from AK ---
Seems like clang now added the check:
$ clang++ -Oz -fno-exceptions
if_delete(char*): # @if_delete(char*)
testrdi, rdi
jne operator delete(void*)@PLT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106991
Bug ID: 106991
Summary: new+delete pair not optimized by g++ at -O3 but
optimized at -Os
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87628
--- Comment #3 from AK ---
Still happening with gcc trunk.
https://godbolt.org/z/5K94665GK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82889
--- Comment #5 from AK ---
Link to compiler explorer: https://godbolt.org/z/dGYG4dG15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82889
--- Comment #4 from AK ---
Seems like clang doesn't sign extend.
$ clang -O3 -std=c++14 -g0
```
.text
.intel_syntax noprefix
.file "example.cpp"
.globl lol(int*, int*, unsigned int, unsigned int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78717
--- Comment #3 from AK ---
Even with a high inline limit, string::find didn't inline.
g++-11.0.2 -O3 -finline-limit=10 -S -o a.s s.cpp
cat a.s
```
_Z3fooRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_i:
.LFB1240:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #12 from AK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #9 from AK ---
can't repro this with gcc 12.1 Seems like this is fixed?
https://godbolt.org/z/e6n94zK4E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105830
--- Comment #3 from AK ---
with -ffreestanding the calls to memcpy did disappear. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105830
Bug ID: 105830
Summary: call to memcpy when -nostdlib -nodefaultlibs flags
provided
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105796
Bug ID: 105796
Summary: error: no matching function for call with template
function
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101138
Bug ID: 101138
Summary: Ambiguous code (with operator==) compiled without
error
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101116
Bug ID: 101116
Summary: missed peephole optimization not of bitwise and
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14
--- Comment #1 from AK ---
godbolt link: https://gcc.godbolt.org/z/f7Y6G1svf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14
Bug ID: 14
Summary: Dead write not removed when indirection is introduced.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #17 from AK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98497
Bug ID: 98497
Summary: [Potential Perf regression] jne to hot branch instead
je to cold
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
71 matches
Mail list logo
