[Bug middle-end/115345] [12/13/14/15 Regression] Different outputs compared to GCC 11- and MSVC/Clang

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Wed Jun 5 06:59:02 GMT 2024


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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.


More information about the Gcc-bugs mailing list