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

> 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

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