https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #14 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581
Andreas Schwab changed:
What|Removed |Added
CC||joel.porquet at gmail dot com
--- Comme
--- Comment #12 from steven at gcc dot gnu dot org 2007-11-18 16:05 ---
This is not a smal thing to fix at all.
"Fixing" this involves teaching the compiler that some labels cannot be moved;
that these labels are optimization barriers (i.e. no insn can be safely moved
up or down across
--- 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
long it extends. But this limitatio
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-11-18 08:46
---
> The compiler is refusing to see the usage of labels as addresses in other
> places than "goto"s. I think you call this "design". But one cant expect
> the code to produce different results with "optimization"
--- 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 #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
addresses in other places (like printf) takes a b
--- 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.
> Please read:
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-11-17 20:36 ---
(In reply to comment #5)
> I dont understand why this bug is invalid. When I use "&&label", I intend to
> load the address where I point to in my code -- not where the compiler wants
> to
> move it around.
No, th
--- 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 understand why thi
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-16 19:57 ---
*** Bug 34116 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-08 00:33 ---
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.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-03 11:44 ---
This is actually invalid but I cannot find where in the docs which talk about
this issue. What is happening is the scheduler is moving around the label as
the basic block which contains the user label is gone.
--
13 matches
Mail list logo
