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: [gimple] assignments to volatile


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


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