[PATCH] Fix PR middle-end/26306

Mark Mitchell mark@codesourcery.com
Mon Nov 6 15:54:00 GMT 2006

Eric Botcazou wrote:
>> None, but TREE_ADDRESSABLE is what says that you can't copy type by just
>> copying bits about, and that's the situation that's problematic here.
> OK, sorry for being terse in my initial message, TREE_ADDRESSABLE is 
> orthogonal to the Ada problem.


>> For a non-TREE_ADDRESSABLE type, you can just create a temporary, copy
>> the value into the temporary; that creates the memory access.
> No, we can't always do that for variable-sized types, that's the ICE.

So, can the middle-end detect that case, i.e., that the variable-sized 
type has a variable size that (apparently) cannot be computed even at 
runtime?  Or, is it the case that (as for C++, see below), it's not 
valid to generate a copy of such Ada types for language-specific reasons?

> It's the best approximation without getting dirty.  Of course we can check 
> TYPE_MODE if you prefer.
>> I don't think consistency with 3.4 should be the paramount goal here.
>> The goal should be to avoid ICEing, and, hopefully, do something with
>> semantics that are readily explained.  At least for C++, we could have
>> avoid ICEing by checking TREE_ADDRESSABLE -- but instead, Jason chose to
>> handle this in the front end.
> Well, something is (partially) wrong in the middle-end, namely
> else if (COMPLETE_TYPE_P (TREE_TYPE (*expr_p)))
>         {
>           /* Historically, the compiler has treated a bare
>              reference to a volatile lvalue as forcing a load.  */
> and these wrong bits break the Ada compiler.  Since the only justification 
> appears to be the historical one, I think history should not be rewritten.

You're reading too much into the comment.  It's not just GCC history; 
it's sensible semantics, at least for C and C++.  A volatile lvalue, all 
by itself, e.g.:

   volatile int i;

indicates a memory reference.  The C/C++ standards don't specify the 
behavior here; they explicitly leave it unspecified.  But, we can 
specify it, and specifying it to copy "i" to a temporary is a reasonable 
thing to do.

>> That seems best in that it avoids having to define the middle-end
>> semantics conditionally.  Instead, we simply say that a volatile read,
>> to the middle end, means the semantics I gave above in terms of copying
>> to temporaries.  It's the front-end's responsibility to make sure that
>> the middle-end never sees a volatile read where copying to a temporary
>> is not an option.
> Why fixing the problem multiple times in different front-ends while simply 
> reverting to the 3.x semantics of the middle-end would do it?

Because the middle end defines the semantics.  There are two 
possibilities: (a) the middle end conditionally creates the temporary, 
depending on some property of the type that indicates whether or not the 
type may be copied, or (b) the front ends promise only to produce 
volatile lvalues as stand-alone expressions if the copy is in fact 
possible.  Either (a) or (b) will work, but (b) seems marginally better 
to me, since it reduces the amount of pointless IL we will feed to the 
middle end.  I don't feel strongly about that, though.

>  Moreover, you 
> said in a previous message that 'volatile' doesn't really apply to aggregates 
> in C/C++, so why invoking the C++ front-end here?

If I did say that, that's not what I meant. :-) I think:

   struct S { int i; };
   volatile S s;


makes sense, just as does the integer example above.  However, if S has 
a copy constructor, then defining the semantics in terms of a copy 
doesn't make sense, since the C++ standard specifies the times a copy 
constructor can be called, and this is not one of those times.

> I'd think that if these 
> middle-end bits are only really meaningful for the Ada compiler, let's change 
> them back in accordance with what the Ada front-end has been generating from 
> the very beginning.

I think the important thing is to actually define the semantics of the 
middle-end, following either (a) or (b) above.

Mark Mitchell
(650) 331-3385 x713

More information about the Gcc-patches mailing list