This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR middle-end/26306
> 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?
My understanding is that it is not valid to generate the copy in Ada here.
> You're reading too much into the comment.
Indeed, because it is *highly* misleading to have a comment which says that
the only justification is the historical one and gets the history wrong.
> 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;
> 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.
Agreed. But this must be explicitly discussed and not changed by accident.
My patch was only aimed at repairing the seemingly accidental breakage, hence
the rather terse initial message.
> 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.
If I were to design it from scratch, I would not feel strongly either. But we
have a long-established semantics in GCC 2.x and 3.x and, barring any strong
impetus, I think we should retain it in 4.x and later.
--
Eric Botcazou