https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95396
--- Comment #4 from Dmitry Babokin ---
Richard Sandiford, could you please have a look as author of the commit, which
brought the regression?
We have a bunch of other fails, which might be or might be not the same as this
one. We'd like to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95396
--- Comment #3 from Dmitry Babokin ---
Could anyone please have a look at this bug? Fixing it would help us not to
file duplicate bugs discovered in random testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83382
--- Comment #2 from Dmitry Babokin ---
(In reply to Richard Biener from comment #1)
> The interaction between sanitizers and middle-end emitted warnings is
> difficult at best. Can you avoid -Werror when sanitizing?
I can, if it's absolutely
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
gcc trunk, rev 255537, x86_64.
> cat f.cpp
unsigned long long int tf_3_var_118 = 12702665990007799801ULL;
unsigned c
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83252
--- Comment #11 from Dmitry Babokin ---
(In reply to Andrew Pinski from comment #10)
> We can add this if needed. I think regression could be made make generic
> and add a generic new bug component. We do have some very active people
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83252
--- Comment #9 from Dmitry Babokin ---
(In reply to Richard Biener from comment #8)
> I suppose one could try scripting something with -fdisable-{tree,rtl}-$dump
> and seeding the list of passes to enable/disable with -fdump-{tree,rtl}-all.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83252
--- Comment #6 from Dmitry Babokin ---
(In reply to Jakub Jelinek from comment #1)
> Option bisection is rarely useful for GCC, debugging issues with -Ox -fthat
> -fno-this -fwhatever is usually not beneficial over just -Ox or whatever
> minimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83252
--- Comment #5 from Dmitry Babokin ---
The original test case is also fixed. Thanks for investigation.
nt: target
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
Created attachment 42775
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42775=edit
reproducer
gcc trunk rev255248, x86_64.
Attached test case produces wr
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
Created attachment 42748
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42748=edit
reproducer
gcc trunk rev255248, x86
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Building compiler-rt (LLVM libs) with GCC trunk (rev 254666, x86_64) I get this
error
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
gcc trunk rev254211, x86_64.
> cat f.cpp
template struct c {
typedef a d[b];
static a e(d f, int g) { return f[g]; }
};
template struct B {
typedef c<a
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
Created attachment 42382
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42382=edit
Reproducer
gcc trunk, rev253744, x86_64.
Trying compile attached test c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81423
--- Comment #16 from Dmitry Babokin ---
ll = -5597998501375493990LL;
// result is 2595916314 here.
ll = unsigned(5677365550390624949L - ll) - (ull1 > 0);
So:
// t1 is 466811183
unsigned long long int t1 = ll + -2129105131L;
// t2 is
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
GCC trunk, rev 253367, x86_64.
Rev 253307 works fine, so it's a fresh regression.
> cat f.cpp
bool a;
int b;
void c() { b & <= 0; }
> g++ -c f.cpp
f.cpp: In fun
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
GCC trunk rev 253307, x86_64.
This looks like a fresh regression. I see quite many fails like this one.
> cat f.cpp
char b, h;
unsigned short c, e;
short d, f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82353
--- Comment #1 from Dmitry Babokin ---
Created attachment 42256
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42256=edit
original test case
I'm also attaching original test case, just in case. For the bug to reproduce
it's important to
: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Created attachment 42255
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
gcc trunk, x86_64.
The test case is simple and my understanding that the correct result is
0x0100, while gcc produces 0. Slight massaging of the code (like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607
--- Comment #12 from Dmitry Babokin ---
The fix helped all fails that I see (with all 7 different symptoms). Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81705
--- Comment #7 from Dmitry Babokin ---
That's an excellent new! This means UBSAN becomes finally fully functional in
GCC. No known false positives anymore (on quite large test base). Great job and
thank you!
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
gcc trunk, rev250857, x86_64.
After recent fix for #81148, this case is the last one failing UBSAN false
positive that I see on my radars.
> cat f.cpp
int var_4 = -1716607
ty: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
gcc trunk, rev250630, x86_64.
I see a lot of crashes involving conditional operator and struct field access.
I see
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
gcc trunk, rev250630, x86_64.
> cat f.cpp
#include
long int var_34 = 5011877430933453486L;
unsigned short var_82 = 24847;
long int var_58 = 1;
void foo() {
if (var_82 > var_34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81555
--- Comment #4 from Dmitry Babokin ---
(In reply to Marc Glisse from comment #3)
> -fno-tree-reassoc should help both.
It helps.
> It is often a combination of optimizations that causes the bug. Reassoc is
> doing a good transformation, but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81555
--- Comment #2 from Dmitry Babokin ---
Hmmm, but this one is triggered at -O1, another only at -O2.
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
gcc trunk, rev250545, x86_64.
This one seems to be different from previously reported bugs. Minimum opt level
to trigger bug is -O2, switching slsr doesn't help (-fno-tree-slsr).
> cat f.
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
gcc trunk, rev250545, x86_64.
> cat f.cpp
#include
unsigned int var_1 = 1;
bool var_2 = false;
unsigned int var_3 = 679743406U;
unsigned int var_4 = 3054363510U;
bool var_5 = true;
unsig
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
gcc trunk, rev250527, x86_64
> cat f.cpp
int a, b, c;
struct d {
static int e;
} f;
d g, h;
void i() {
f.e = (10834211066969351267ULL || 0) >> c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81546
--- Comment #2 from Dmitry Babokin ---
Reduced test case consumes about 11Gb. That's a lot and looks like it's just
the consequence of the real problem. But the test case in #81488 consumes 128Gb
and dies on my machine because of lack of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81503
--- Comment #6 from Dmitry Babokin ---
How can I switch off optimization phases to workaround the bug?
I have another instances of wrong code bugs, so I'd like to make sure that I
don't create duplicate reports for the same problem.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
Created attachment 41823
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41823=edit
reduced and original test cases
gcc trunk rev250367, x86_64
Test case is reduced f
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
gcc trunk, rev250367, x86_64.
> cat f.cpp
#include
unsigned short a = 41461;
unsigned short b = 3419;
int c = 0;
void foo() {
if (a + b * ~(0 != 5))
c = -~(b * ~(0 != 5)) + 2147483
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
Created attachment 41792
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41792=edit
reproducer
gcc tr
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
gcc trunk, rev250140, x86_64.
Test case has no undefined behavior, but -O2 produces incorrect result.
> cat f.cpp
#include
unsigned long long int ll = 0;
unsigned long long int ull1 = 1
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
gcc rev250140, x86_64.
> cat f.cpp
#include
short var_9 = 19581;
unsigned char var_33 = 21;
long int var_55 = 286697804684061197L;
long int var_59 = -1962393262513510540L;
long int var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81387
--- Comment #3 from Dmitry Babokin ---
Interesting that you've mentioned -fno-sanitize-recover, I haven't realized
that it has effect on the number of basic blocks. But by default I run
"-fsanitize=undefined -fno-sanitize-recover=undefined", so
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81332
--- Comment #1 from Dmitry Babokin ---
I've jut hit another instance on this bug, which mean that it's probably not
too rare and quite possible to hit in the wild.
NCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
gcc rev250008, x86_64.
> cat f.cpp
extern int var_8, var_18, var_29, var_1365;
long a;
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
gcc trunk rev249427, x86_64
In presence of -fsanitize=undefined optimisations (-O2) produce wrong code.
> cat f.cpp
#include
short s;
int i1 = 1;
int i2
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
gcc rev249427
: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81065
--- Comment #5 from Dmitry Babokin ---
Thanks for blazingly fast fixes. This enables filing more bugs, as it's
difficult to distinguish between unrelated fails before one of them is actually
fixed.
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66313
--- Comment #20 from Dmitry Babokin ---
I've created #80932 for c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2 issue.
--- Comment #21 from Dmitry Babokin ---
I've created #80932 for c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2 issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66313
--- Comment #20 from Dmitry Babokin ---
I've created #80932 for c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2 issue.
--- Comment #21 from Dmitry Babokin ---
I've created #80932 for c1*(c2*v1-c3*v2)=>c1*c2*v1-c1*c3*v2 issue.
MED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66313
--- Comment #17 from Dmitry Babokin ---
Any chances for the fix for this bug?
Looks like this one stands as a last obstacle to claim UBSAN in GCC fully
functional.
I still see quite a few errors, but looks like all of them are attributed to
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66313
--- Comment #16 from Dmitry Babokin ---
Here's another test case with a contrary example, where a variable gets pulled
into the braces and it also causes false positive. Transformation is: const1 *
(const2 * var1 - const3 * var2) =>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597
--- Comment #17 from Dmitry Babokin ---
Yes, it's fix with current trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66313
--- Comment #15 from Dmitry Babokin ---
The bug is almost 2 years old. I consider it's quite important, as false
positives make UBSAN not usable on any large codebases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80847
Dmitry Babokin changed:
What|Removed |Added
CC||babokin at gmail dot com
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597
--- Comment #14 from Dmitry Babokin ---
Disregard my previous comment.
Original test case still fails with compiler switches that I've originally
reported (-fsanitize=undefined).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597
--- Comment #13 from Dmitry Babokin ---
The attached patch fixes my original test case.
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
gcc rev248130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80386
--- Comment #8 from Dmitry Babokin ---
Many failing tests are fixed, but quite few still failing. Should I add failing
test cases here or create a separate bug?
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
Created attachment 41299
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41299=edit
reproducer
gcc top of the tr
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
> cat f.cpp
extern unsigned char var_67;
v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80349
--- Comment #12 from Dmitry Babokin ---
int var;
long a;
long foo() {
int i = !(1 & 808U ^ 1 & var) >> 0;
long l = 0 % ((a & 1) != (3053241240409UL & 1));
return i+l;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80349
--- Comment #8 from Dmitry Babokin ---
I also see crashes reporting problems with ^ operator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80349
--- Comment #7 from Dmitry Babokin ---
One more. GCC r247062.
> cat f.cpp
unsigned long int ll;
int foo() {
return (2036854775807 >> ll & char(207648476159223) | 502810590243120797UL)
<< 0;
}
> g++ -fsanitize=undefined -O0 -c f.cpp
f.cpp: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80386
--- Comment #4 from Dmitry Babokin ---
Any update? This bug makes gcc ubsan implementation almost unusable on any real
application.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80403
--- Comment #11 from Dmitry Babokin ---
I confirm that the latest patch fixes all UBSAN compile time problems that I
have. Thanks!
Though correctness issues remain - PR80386.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80403
--- Comment #8 from Dmitry Babokin ---
Three errors in one test case. GCC r246882.
> cat f.cpp
extern const long long int var_7;
extern unsigned long int var_59;
int foo() {
int a = (0 - 40U <= (0 == 8)) << !var_59 << (0 < var_7) == 0;
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80403
--- Comment #7 from Dmitry Babokin ---
80404 and 80405 seemed similar, but different to me, so I decided to report
them separately. Anyway, after the latest fixes I still see 2 compile crashes.
I'm reducing them and will report here.
ty: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.or
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc d
NCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org,
: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80349
--- Comment #3 from Dmitry Babokin ---
PR80348 is fixed, but this still fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80348
--- Comment #7 from Dmitry Babokin ---
These tests are still failing:
> cat f1.cpp
void foo() { 0 / unsigned(!(0 - 3) >= (0 > 0)); }
> cat f2.cpp
extern long long int var_58;
void foo() { (0 >= 10253361740180 >= long(0 >= 0)) % var_58; }
> cat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80348
--- Comment #1 from Dmitry Babokin ---
*** Bug 80347 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80347
Dmitry Babokin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc d
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
Top of the tree gcc crashes when compiler the following test case. Gcc 4.8
works well.
> cat f.cpp
extern const unsigned long int var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79399
--- Comment #11 from Dmitry Babokin ---
With new patch it compiled successfully. It took 41G of memory and 5:25 hours
to complete.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79399
--- Comment #7 from Dmitry Babokin ---
It crashed.
> /usr/bin/time --format="Max %M kb\nreal %E\nuser %U\nsys%S" g++ -std=c++11 -w
> -O0 -march=nehalem -o gcc_no_opt_func.o -c func.cpp
func.cpp: In function ‘void foo()’:
func.cpp:26656:1:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79399
--- Comment #6 from Dmitry Babokin ---
I've started the compilation, it should take more than an hour to finish. Will
report back when it's done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79399
--- Comment #4 from Dmitry Babokin ---
The purpose of the generator is to break a compiler, that's why it's a single
function in this case, but not many. Though with smaller functions we break
compilers too.
This is the generator:
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
The bug report is not very typical, but it may help fixing the real issue,
which is hard to find and debug in other corricumstances. I don't mind if it's
closed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78769
--- Comment #2 from Dmitry Babokin ---
I've used r243504, the latest available on git://gcc.gnu.org/git/gcc.git
everity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
> cat bug.cpp
#include
char a = -110;
unsigned long long int b;
void foo();
int main() {
foo();
pr
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
Created attachment 40279
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40279=edit
reproducer
-O2 produces different result t
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
Created attachment 40278
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40278=edit
reproducer
> g++ -O2 -march=nehalem -o opt illegal_in
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
Created attachment 40093
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40093=edit
reproducer
> g++ -O0 main.cpp func.cpp -o no_opt; ./no_opt
0
> g++ -O1 main.cpp func.c
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
Created attachment 40091
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40091=edit
reproducer
The test is correct C++ prog
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
Created attachment 39594
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39594=edit
reproducer
> g++ -O0 -c func
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
Created attachment 39554
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39554=edit
reproducer
> g++ -std=c++11 -O3 -march=knl
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
Test case:
#include
int var_s2 = 0;
int main () {
unsigned long long a = 1ULL << (57 - var_s2);
//
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: babokin at gmail dot com
Target Milestone: ---
Created attachment 39074
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39074=edit
reproducer
-O0 and
99 matches
Mail list logo
