Patch for bugs 772 and 17913

[Mark Mitchell]

Joseph S. Myers wrote:
> This patch addresses bugs 772 and 17913 by disallowing jumps into
> statement expressions for C. 

Great.

> Jumps out of statement expressions are
> however allowed and the semantics are documented, along with the
> evaluation order rule that the evaluation of a statement expression
> doesn't overlap with the evaluation of other parts of the surrounding
> expression (as with an inline function call and as discussed at
> <http://gcc.gnu.org/ml/gcc/2003-07/msg01461.html>).

Yes, I think those are desirable semantics.  Personally, I'd be happy to 
disallow jumps out of statement expressions, but I can't really justify 
that, at least in C.  In C++, destructor semantics may make jumps out of 
statement-expressions more problematic -- but, then again, they may not.

I certainly have no objection to applying this patch to the 4.0 branch.

> * Jumping into statement expressions via computed goto is undefined at
>   runtime not compile time, but it can lead to the same ICE as in bug
>   17913 when optimizing; for example, compile the following with -O.
> 
>   void f(void) { void *p = &&a; 1 ? 1 : ({ a : 1; 1; }); goto *p; }
> 
> In order to avoid an ICE in such cases I think a patch such as that at
> <http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00130.html> is still
> needed.

Given that we're disallowing jumps inward, does it make sense to make 
all labels in statement expressions implicitly local?  I suppose that it 
might still be possible to get the ICE by storing the address of the 
label in some variable, and then using a computed goto later.

The langhooks part of Gabor's patch is fine.  Given Roger's comment that 
  he's happy with the middle-end changes, the patch is OK for 4.0 and 
mainline, modulo Joseph's comments about formatting, etc.  Gabor, would 
you please revise accordingly?

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304