https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348
Sebastiano Vigna changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #10 from Sebastiano Vigna ---
Ahem no, my correction goes in the opposite direction it should go. I'll ask
suggestions to the library authors.
I really apologize for all the noise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #9 from Sebastiano Vigna ---
Finally solved: the problematic statement
if (h == NULL) h = (struct prb_node *)&tree->prb_root;
should just be
if (h == NULL) h = tree->prb_root->prb_link[0];
The position in memory of the two pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #8 from Sebastiano Vigna ---
I'm sorry, I did the test on the wrong file. No, you cannot eliminate the &,
even if the type is correct, and h can be NULL at that point. I'll ask the
libavl maintainers their opinion. We can compile with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
Sebastiano Vigna changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #6 from Sebastiano Vigna ---
Created attachment 50410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50410&action=edit
Source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #5 from Sebastiano Vigna ---
Created attachment 50409
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50409&action=edit
Source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #2 from Sebastiano Vigna ---
Created attachment 50408
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50408&action=edit
Source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99623
--- Comment #1 from Sebastiano Vigna ---
Created attachment 50407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50407&action=edit
Output of gcc with -O2
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastiano.vigna at unimi dot it
Target Milestone: ---
Created attachment 50406
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50406&action=edit
Output of --save-temps
The included code compares two variants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348
--- Comment #13 from Sebastiano Vigna ---
I can confirm that compiling/running with ubsan and asan no problem is
reported. The bug does not show up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348
--- Comment #12 from Sebastiano Vigna ---
BTW, to further restrict the search I'm trying to replicate the bug with
-fsanitize=address, or at least to get to the problematic call under
-fsanitize=address, but it'll take a while. I have to recompil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348
--- Comment #11 from Sebastiano Vigna ---
Dear Mikhail,
I have several ongoing open-source projects and, believe me, I make exactly the
same recommendation to people reporting bugs. They are perfectly sensible and
certainly the way to go in 99% o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348
--- Comment #9 from Sebastiano Vigna ---
As I said, I was trying (a bit naively, admittedly) a diagnosis. I agree
fully--I'm no expert in x86 assembly. But it is a fact that the problematic
loop never exits with -O1, and exits normally with -O0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348
--- Comment #7 from Sebastiano Vigna ---
I tried also with -fsanitize=address. No problems reported. Bug not showing up.
A classical heisenbug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348
--- Comment #6 from Sebastiano Vigna ---
I forgot an important aspect: with -fsanitize=undefined the optimization bug
does not show up. The instrumentation perturbs the code enough to make it go
away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348
--- Comment #5 from Sebastiano Vigna ---
Fantastic tool! I didn't know about it.
But it doesn't fire. There is no undefined behaviour in that code--it's just
that the optimizer at -O1 does something wrong.
I tried a binary search over the singl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348
--- Comment #3 from Sebastiano Vigna ---
As an additional information: we printed b->num_lines - 1 - n just before the
loop, and everything is fine--we get there with the current value both with -O0
and -O1. But we -O1 we never exit the loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348
--- Comment #2 from Sebastiano Vigna ---
Er... it's perfectly possible. My knowledge of x64 assembly is rudimentary, but
I wanted to try a diagnosis.
What is definitely true is that at -O0 we enter and exit the loop as it should
happen, and at -
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastiano.vigna at unimi dot it
Target Milestone: ---
Created attachment 35657
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35657&action=edit
Source (buffer.c) and
20 matches
Mail list logo
