[Bug optimization/15242] pessimization of "goto *"

["anton at a0 dot complang dot tuwien dot ac dot at" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From anton at a0 dot complang dot tuwien dot ac dot at  2004-05-04 15:06 -------
Subject: Re:  pessimization of "goto *"

jsm at polyomino dot org dot uk wrote:
> 
> 
> ------- Additional Comments From jsm at polyomino dot org dot uk  2004-05-02 19:06 -------
> Subject: Re:  pessimization of "goto *"
> 
> On Sun, 2 May 2004, anton at a0 dot complang dot tuwien dot ac dot at wrote:
> 
> > And that refers to a discussion in the mailing list, and the only
> > mention of a problem with jumping out that I found there was in
> > <http://gcc.gnu.org/ml/gcc/2000-07/msg00721.html>.  For this example
> > the semantics seem pretty obvious and well-defined to me (in contrast
> > to the jump-into example), and this was just a compiler bug.
> 
> The semantics are neither obvious nor well-defined, because other parts of
> the larger expression containing the statement expression might or might
> not have been evaluated.

The example is:

  a:
     f ("%d\n", ({goto a;})

The only other part that might or might not have been evaluated is the
"%d\n"; since this has no side effect, it does not matter whether it
is evaluated or not.  So the obvious (to me) and well-defined
semantics of this example is to be equivalent to

a: goto a;

In general, true, if the other parts of the expression have side
effects, the whole expression is undefined, but that's just the same
as in other cases with side effects in expression evaluation, so the
semantics still seem obvious to me.

>  The only thing in C giving rise to such a
> situation (where parts of an expression might or might not have been
> evaluated when a jump occurs) is setjmp/longjmp, and you should be able to
> use longjmp in statement expressions; goto can't have such effects in C so
> it's dubious allowing them in GNU C.

Variable definitions also give rise to such situations (where parts of
an expression might or might not have been evaluated when the
definition occurs), and this may also lead to undefined behaviour, and
this cannot happen in C.  Does this make allowing variable definitions
in statement expressions dubious in GNU C?

I don't think so (after all, they are used in the first example for
statement expressions), and I don't think that this kind of argument
is valid for other things that cannot occur in C expressions, either.

If only things were allowed in statement expressions that are allowed
in C expressions, then statement expressions would be redundant; you
could simply write "(expr, expr, expr)" instead of "({expr; expr;
expr;})".

- anton




-- 


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