https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66348
--- Comment #11 from Sebastiano Vigna <sebastiano.vigna at unimi dot it> ---
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% of the cases.
The problem is that we face what is called a "heisenbug". Any tentative to
observe it or reproduce it fails. Add ubsan: no bug. Add a print in the loop:
no bug. Isolate the behaviour by having a main() calling the faulty function
with the same parameters: no bug.
Reproducing requires running ne (the nice editor) on a machine with at least
256GB of RAM, opening a 30GB file and running a specified macro. I don't think
this is doable. But if anybody is interested in reproducing the bug, I can
provide an account, given ssh credentials, and a directory with all necessary
instructions. Running ne using the given macro reproduces exactly the bug. But
all my tentatives to reduce the size of the source failed miserably.
Heisenbugs are very often (but not always) compiler bugs. In our case, I
finally settled for
// Problematic loop
for(int64_t i = 0; i < b->num_lines - 1 - n; i++) {
if ( i == -1 ) fputc('.', stderr); // ***
ld = (line_desc *)ld->ld_node.prev;
}
I just added the line marked ***. It does nothing--i is never -1. Nothing is
ever printed. But now the code runs correctly when using -O3.
Does this prove that I'm facing a compiler bug? I don't know for certain, but
I'm pretty sure it does, and considering the very short function in which the
bug appears it would be probably easy to check whether this is true or not.
