This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix PR middle-end/26306
> 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.
> Of course, AGGREGATE_TYPE_P is not the same as BLKmode either.
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.
That Jason fixed the C++ problem in a different manner should not preclude us
from recognizing that the semantics has changed from 3.x to 4.x and, I would
suspect, by accident.
> 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? 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? 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.