This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR middle-end/26306

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]