This is the mail archive of the gcc-patches@gcc.gnu.org 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:
>> I'll not object to such a patch.  In fact, I'll pre-approve it, on one
>> condition: fill in the section in the manual about implementation of C
>> with respect to "qualifiers implementation" to explain under what
>> conditions we generate an access to a volatile lvalue whose value is not
>> otherwise required.  If we're going to restore this behavior, and you
>> think it ought to be preserved in future, we ought to document it.
> 
> Agreed, this will be easier to read than the RTL expander in any cases.  
> Moreover I think we should also make the "When is a Volatile Object Accessed" 
> section for the C++ compiler reference this new section.  Patch attached.
> 
>> I'm not trying to be cute; I really do think those are the reasonable
>> choices, if we want to preserve this behavior for the foreseeable future.
> 
> The Ada compiler happens to rely on this behavior of the middle-end for proper 
> operation, so we certainly are interested in preserving it. :-)

This patch is OK, with a few small doc changes:

> +Less obvious expressions are where something which looks like an access
> +is used in a void context.  An example would be

I think:

However, the volatile storage is not being modified, and the value of
the volatile storage is not used, then the situation is less obvious.
For example:

> +
> +@smallexample
> +volatile int *src = @var{somevalue};
> +*src;
> +@end smallexample
> +
> +According to (C90 ?, C99 6.3.2.1), such an expression is an rvalue whose

Fill in that "?".

> +type is the unqualified version of its original type, i.e. @code{int}.
> +Whether GCC interprets this as a read of the volatile object being pointed
> +to or only as a request to evaluate the expression for its side-effects
> +depends on this unqualified version of the original type.

I think just "depends on the type" is fine.

> +If it is a scalar type, or an aggregate type whose only member object is
> +of a scalar type, or a union type whose member objects are of scalar types,
> +the expression is interpreted by GCC as a read of the volatile object; in
> +the other cases, the expression is only evaluated for its side-effects.

Is that true on all platforms?  Are there no platforms where "long
long", or a structure containing that, gets BLKmode?

> +pointer to volatile object of complete type in a void context like GCC
> +would do it for an equivalent C type.  When the object has incomplete

Replace from "in a void..." with "when the value is unused as GCC would
do for an equivalent type in C."

Thanks for going along with me on this adventure. :-)

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


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