[gimple] assignments to volatile

[Nathan Sidwell]

On 06/24/10 19:38, Mike Stump wrote:
> On Jun 24, 2010, at 7:32 AM, Mark Mitchell wrote:
>> Mike Stump wrote:
>>
>>>> x = y = z;
>>>>
>>>> where "y" is volatile?
>>
>>> C++ requires a re-read of y, the patch was going to remove the
>>> re-read, I objected because the patch then makes the compiler not
>>> conform to the C++ standard.
>>
>> I think that you have to read rather a lot into the C++ standard to
>> arrive at that conclusion.
>
> I disagree.  It we meant to create a temporary for a = b = c, when a b and c are all class types, we would have listed 5.17 in 12.2.  Do you know of any C++ compilers that so create a temporary?  g++ certainly doesn't.  Now, compare 6.6.3.  It can create a temporary, and it does list 12.2, and is listed by 12.2.

We were talking about scalars.  volatile structs are treated differently.  As I 
already mentioned, in G++, '(void)volatile_class_object' does not cause 
lvalue->rvalue  decay and does not cause a read of all the members of the 
object.  I think the behaviour of volatile structs in C++ is too ill-specified 
to meaningfully talk about when accesses to the members occur.

I think the goal should be to make accesses to volatile scalars, as used when 
poking at hardware, follow simple, composable, consistent rules.  IMHO the 
current implemented behaviour is none of those.

> j is re-read.  It is re-read regardless if j=0, or j=k is used in the source.  Now, for the simpler:
>
> volatile int i, j, k;
> volatile int vi;
> void foo(int p) {
>    i ? j=0 : 0;
> }
>
> neither gcc nor g++ re-reads, and I'm not arguing changing that.  Nor is anyone suggesting changing that, so I don't see the point of asking.  I'm dodging what the standard says, well, unless someone wants to propose we change how they behave currently.

But gcc does reread when assigning a non-constant value.  As I pointed out, 
GCC's behaviour is inconsistent.

nathan.

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery