https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115040
--- Comment #9 from AK ---
Thanks for merging the patch!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115040
--- Comment #6 from AK ---
The duplicate part of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545, the
first loop, will get fixed with Jonathan's patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545
--- Comment #10 from AK ---
With this patch find of int8_t gets converted to memchr.
Using testcase from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115040 as
example. With the patch posted in
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545
--- Comment #7 from AK ---
Is there a plan to push a patch for this?
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.
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
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
https://gcc.godbolt.org/z/s3hv15935
```
#include
#include
#include
bool find_epi8(const std::vector&am
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
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
#include
#include
std::vector td() {
int arr[]{-5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10,
15, -5, 10, 15,-5, 10, 15 -5, 10, 15, -5, 10, 15, -5, 10
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?
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
#include
#include
#include
int foo() {
std::variant v {"abc"};
std::cout << std::get<0>(v);
return 0;
++
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
#include
#include
std::string foo() {
std::variant v {"abc"};
return std::get<0>(v);
}
g++-13.2 -O2 -std=c++20
foo[abi:cxx11]():
lea rdx, [rdi
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: riscv64-
ormal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
CGBuiltin.cpp:(.text._ZN5clang7CodeGen15CodeGenFunction20EmitRISCVBuiltinExprEjPKNS_8CallExprENS0_15ReturnValueSlotE+0x10d0):
reloc
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 have
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&action=edit
GlobalModuleIndex.cpp preprocessed files
Everytime the crash is in a different file. it could be just because of memory
i
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'
--with-bugurl=file:///usr
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:
too
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
riscv64-gnu-linux (version Debian 13.1) building llvm-project
(GlobalModuleIndex.cpp) crashed with ICE.
src/gcc/toplev.cc:314
profile_count::operator
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
#include
using Container = std::vector;
int copy_assignment(const Container &v1, Container &v2) {
v2 = v1;
return 0;
}
I'd expect this to only generate
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. wha
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
#include
void f(int);
void use_idx_const_size_reserve() {
std::vector v;
v.reserve(10);
auto s
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 >): #
@va
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
deal
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.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
here is slightly modified code example from issue #35269. Both accesses are
similar bug different code is generated
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
T vat1(std::vector v1) {
auto v = v1;
return 10;
}
g++ -O3 -std=c++20 -fno-exceptions
vat1(std::vector >):
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];
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
Reference: https://godbolt.org/z/af4x6zhz9
When all elements of vector are 0, then the compiler should be able to remove
the
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
#include
#include
using namespace std;
bool bar();
using T = int;
T vat(std::vector v) {
T s;
for
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 `__attrib
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
Testcase has been reduced from u-boot's linker-list macro:
https://github.com/u-boot/u-boot/blob/master/include/linker_lists.h#L127
#include
char* bar() {
s
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.
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
Testcase:
#include
void foo() {
std::cout << std::endl;
}
$ g++ -std=c++17 -O3 -fno-exceptions
```asm
foo():
mov rax, QWORD PTR std::cout[rip]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85611
AK changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
int volatile gv = 0;
void foo() {
++gv;
}
$ gcc -Os
foo():
mov eax, DWORD PTR gv[rip]
inc eax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107011
--- Comment #2 from AK ---
ah ok. sorry for the noise.
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
#include
int main() {
return INT_MIN / -1;
}
$ gcc -O3
main:
mov eax, -2147483648
ret
$ clang -O3
main
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
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
#include
int main() { return INT_MIN / -1; }
gcc -O2
main:
mov eax, -2147483648
ret
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 volatile
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
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
https://godbolt.org/z/PeYcoqTKn
---
#include
#include
int volatile gv = 0;
void
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:
.cfi_s
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.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
https://godbolt.org/z/jTEa6ajn3
```
// test.c
// Type your code here, or load an example.
/* Nonzero if either X or Y is not
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
test.cpp
```
int func(int, char);
template
int testFunc(int (*)(TArgs..., char));
int x = testFunc(func);
```
With gcc trunk:
g++ -std=c
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
$ cat test.cpp
#include
using namespace std;
template
struct D {
template bool operator==(Y a) const {
cout << "f"
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
$ cat test.c
bool foo(unsigned i) {
return !(i & 1);
}
gcc -O2 test.c -S -o-
foo(unsigned int):
mov eax, edi
not eax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14
--- Comment #1 from AK ---
godbolt link: https://gcc.godbolt.org/z/f7Y6G1svf
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
struct Foo {
int x;
};
struct Bar {
int x;
};
void alias(Foo* foo, Bar* bar) {
foo->x = 5;
foo->x = bar->x;
}
struct Wrap1
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
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
In the following code generated by gcc 10.2
```
.L2:
movups xmm3, XMMWORD PTR [rax]
add rax, 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95565
--- Comment #1 from AK ---
I believe we need to conditionally disable the following code, but I'm not sure
of all the implications. If someone can implement it that'd be great.
```
gcc/gimplify.c Around Line:14997
x = builtin_decl_impli
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
The flag -finstrument-functions instruments both entry and the exit of
function. There are many scenarios (like cheap profiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94823
--- Comment #5 from AK ---
> So when __k == 0, then all three of those loads will be _Type(0x8b8b8b8bu)
> really; no matter what the values of __n, __p will be.
Will it be a good idea to add the explanation in comments, as this may be
tricky f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94823
--- Comment #4 from AK ---
Makes sense. Thanks for the explanation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94823
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #1 from AK
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
Integer overflow reported by asan with the following stack trace. If this is
not
sufficient I can try to provide a repro
gcc/7.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93584
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #3 from AK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66414
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #8 from AK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66416
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #2 from AK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92638
--- Comment #1 from AK ---
FYI: clang -O3 optimizes the empty loop.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
$cat test.c
#include
#include
#include
#include
char* get(const char* value, const char separator) {
int separator_index
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
https://godbolt.org/z/DY9ruv
void if_delete(char *p) {
if (p) {
delete(p);
}
}
$ gcc-8.2 -Os -fno-exceptions
if_delete(char*):
test rdi, rdi
je .L1
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
test.cpp
#include
int bar(int* v, std::size_t base) {
int sum = 0;
for (int i = base; i < base + 4; ++i) {
sum += v[i];
}
ret
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
$ cat test.cpp
struct BigStruct {
int x[64];
};
void structByValue(BigStruct s);
void callStructByValue(int
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
$ cat test.cpp
#include
std::atomic atomic_var{100};
int somevar;
bool cond;
void run1() {
auto a
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
$ cat test.cpp
#include
std::atomic flag_atomic{false};
extern void f1();
extern void f2();
void foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12333
--- Comment #17 from AK ---
The following workarounds do not emit compiler errors, although I'm not sure if
second option is a correct workaround.
1. this->~X();
2. X::~X(0);
FYI,
ICC 18 also has the same bug. The first workaround works for ICC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22238
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #24 from AK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #25 from AK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #27 from AK
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
$ cat t.cpp
#include
int lol(int32_t* table, int32_t* ht, uint32_t hash, uint32_t mask) {
for (uint64_t probe = (uint32_t)hash & mask, i = 1;;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82776
--- Comment #9 from AK ---
Are we also taking advantage of this statement in the standard:
> An iteration statement that performs no input/output operations, does not
> access volatile objects, and performs no
synchronization or atomic operatio
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hiraditya at msn dot com
Target Milestone: ---
Compiling with
g++ -O2 --std=c++14 -msse4 -DENABLE_FORLOOP
vs.
g++ -O2 --std=c++14 -msse4
gives dramatically different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79349
AK changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|WORKSFORME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79349
AK changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 121 matches
Mail list logo
