: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sparc64 at rediffmail dot com
GCC build triplet: 4.1.1
GCC host triplet: ???
GCC t
--- Comment #5 from sparc64 at rediffmail dot com 2007-11-17 11:50 ---
(In reply to comment #3)
> This is invalid as there are no computed gotos in your example so the compiler
> does not know it is a target for a goto so it is able to move the label
> around.
I dont under
--- Comment #7 from sparc64 at rediffmail dot com 2007-11-18 06:41 ---
> No, this extension is not designed that way. It is only designed for computed
> goto's.
So, Are programmers expected to see their code work differently with
optimization enabled ? I dont think so.
&g
--- Comment #8 from sparc64 at rediffmail dot com 2007-11-18 07:25 ---
Ok, Continued :
The "goto" statement works fine with optimization unless that "goto" is
needless (like "goto" to next C statement) in which case, usage of "labels" as
address
--- Comment #9 from sparc64 at rediffmail dot com 2007-11-18 07:28 ---
I must have said "architectural hurdles" not "limitations..." especially
because I have quoted "harvard cache" as an example.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581
--- Comment #11 from sparc64 at rediffmail dot com 2007-11-18 14:44 ---
> I agree that we should clarify the documentation if we definitely rule the
> code as being invalid.
Since "&&" is a C extension, I believe one can reserve the right to limit how
l
