https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
--- Comment #13 from Djordje Baljozovic <djordje.baljozovic at ac dot rwth-aachen.de> --- (In reply to Richard Biener from comment #12) > (In reply to Djordje Baljozovic from comment #11) > > (In reply to Djordje Baljozovic from comment #9) > > > (In reply to Andrew Pinski from comment #7) > > > > A few questions, does `-fsanitize=undefined -fsanitize=address` report > > > > anything? Does it work at -O0 and not just -O3? Does adding > > > > -fno-strict-aliasing to the command line "fix" the crash? Are there any > > > > warnings with `-Wextra -Wall` that might be causing an issue? > > > > > > Have not tested -O0 and -fno-strict-aliasing; will let you know if this > > > fixed the problem. > > > No warnings with -Wextra -Wall to my knowledge. > > > > > > Sincerely, > > > George > > > > Hi Andrew and Jakub, > > The results are more than interesting: > > > > 1. -fno-strict-aliasing: none of the inputs processed (with O3) > > 2. O0: all but one input processed > > 3. O3: none of the inputs processed > > 4. O1 and O2: all inputs processed without any issues -- this did it. > > > > Now the question is: how on Earth did O1/O2 do the trick, and not O0?! > > Can you check whether -O0 works with the other compilers? It feels like > you might be triggering some undefined behavior in your code. > > If you have a short running example that breaks with -O0 it might be > also interesting to run it through valgrind to spot use-after-free > or uninitialized use issues. > > > Once again, thanks a lot for your detailed and quick responses. > > George > > P.S. I will keep @Jakub's bisect idea in mind if something like this happens > > in the future. Hi Richard, Yes, I think that testing O0 with other compilers makes sense. BTW, do you think that running the code through valgrind can identify some issues which are not detected by fuzzers? Thanks, George
