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
