[Bug regression/59320] ftree-vrp breaks simple loops

astra at ionic dot at gcc-bugzilla@gcc.gnu.org
Fri Nov 29 01:40:00 GMT 2013


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59320

David Kaufmann <astra at ionic dot at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #11 from David Kaufmann <astra at ionic dot at> ---
(In reply to Joost VandeVondele from comment #10)
> no weird behavior of vrp. given the size of dash_list (2) it correctly
> establishes the range on the value, i.e. that il must be either 0 or 1 (any
> other value would trigger out-of-bounds, which can't happen in a valid C
> program). All the rest is a consequence of this. So, the bug is in the C
> program, not the compiler.
Okay, I tried to apply a temporary fix in the Code and the bug went away.

I just don't understand how it can happen, that if there is a imminent
out-of-range happening somewhere in the loop and therefor il only may have the
value 0 or 1 it compiles it to code, which then stops checking the condition
and therefor running the loop until it gets out-of-bounds.

What surprises me is that a printf on "il < nd = (il<nd)" returns always 1, no
matter the shown values.
(As stated before printf returns "0 < 4 = 1", "1 < 4 = 1", "2 < 4 = 1", "3 < 4
= 1", "4 < 4 = 1", "5 < 4 = 1", and so on until a value of il of approx. 440k.
Then it shows a sigsegv on reading something around fl[448054]. - remember, fl
has only 4 elements...)

Anyway, thankfully now I know where to fix the bug. As -Wall does not show any
warnings and the SIGSEGV is shown on the wrong line combined with the
misleading printf-output I would never have found that in ages.

Thanks,
David



More information about the Gcc-bugs mailing list