--- Comment #13 from ppr at melexis dot com 2008-09-18 12:15 ---
(In reply to comment #12)
> Note you can do the same as AVR does - force flag_delete_null_pointer_checks
> to
> zero:
>
Thanks for the hint, I'll use it!
Plamen
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37569
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-09-18 11:11
---
Note you can do the same as AVR does - force flag_delete_null_pointer_checks to
zero:
grep flag_delete_null_pointer_checks config/*/*.c
config/avr/avr.c: flag_delete_null_pointer_checks = 0;
--
http://gcc.gn
--- Comment #11 from ppr at melexis dot com 2008-09-18 10:57 ---
(In reply to comment #10)
This workaround doesn't work with GCC 3.4.3 (the base for our 16-bit port). It
does work with the latest GCC4.3 though.
Anyway, thanks for your support, and for explaining the reasons behind the
--- Comment #10 from brian at dessent dot net 2008-09-18 10:45 ---
Subject: Re: Loop incorrectly optimized to endless loop with
-Os/-O2/-O3
That fact that the hardware allows it doesn't change the fact that it's
still invalid in ISO C, and that is the spec that gcc follows.
Seems to
--- Comment #9 from ppr at melexis dot com 2008-09-18 10:20 ---
(In reply to comment #8)
> I think this code is invalid. I seem to recall the argument that it's
> undefined behavior to increment or decrement a pointer to 0.
Well, the pointer is not NULL initially, it's just decremented
--- Comment #8 from brian at dessent dot net 2008-09-18 09:25 ---
Subject: Re: New: Loop incorrectly optimized to endless loop with
-Os/-O2/-O3
I think this code is invalid. I seem to recall the argument that it's
undefined behavior to increment or decrement a pointer to 0.
Speaki
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-09-18 08:57 ---
Well ... VRP validly asserts that i_7 is not NULL after dereferencing it:
:
# i_2 = PHI <4094B(2), i_20(8)>
# sum_1 = PHI <0(2), sum_9(8)>
i_7 = i_2 + -4;
D.1209_8 = *i_7;
i_20 = ASSERT_EXPR ;
sum_9 = D.
--- Comment #6 from ppr at melexis dot com 2008-09-18 08:22 ---
(In reply to comment #5)
> another vrp bug? -fno-tree-vrp helps.
>
Yes, -fno-tree-vrp does help
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37569
--- Comment #5 from pluto at agmk dot net 2008-09-18 08:08 ---
another vrp bug? -fno-tree-vrp helps.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37569
--- Comment #4 from ppr at melexis dot com 2008-09-18 07:58 ---
The problem seems to be related with the i pointer reaching 0. If the loop
condition is e.g. "while ( i != 2 )" everything is ok.
The same if the "sum = sum + *(i)" is replaced e.g. with "sum = sum + *(i+1)"
--
http://g
--- Comment #3 from ppr at melexis dot com 2008-09-18 07:53 ---
Created an attachment (id=16354)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16354&action=view)
The compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37569
--- Comment #2 from ppr at melexis dot com 2008-09-18 07:53 ---
Created an attachment (id=16353)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16353&action=view)
The produced assembler source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37569
--- Comment #1 from ppr at melexis dot com 2008-09-18 07:52 ---
Created an attachment (id=16352)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16352&action=view)
preprocessed source of the test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37569
13 matches
Mail list logo