This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Assignment to volatile objects
- From: <Paul_Koning at Dell dot com>
- To: <zoltan at bendor dot com dot au>, <gcc at gcc dot gnu dot org>
- Date: Mon, 30 Jan 2012 16:22:12 -0600
- Subject: RE: Assignment to volatile objects
- References: <20120131090257.3a2934b4@tade.bendor.com.au>
I would prefer this to generate a warning. The C language standard change you refer to is a classic example of a misguided change, and any code whose behavior depends on this deserves a warning message, NOT an option to work one way or the other.
paul
-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of Zoltán Kócsi
Sent: Monday, January 30, 2012 5:03 PM
To: gcc@gcc.gnu.org
Subject: Assignment to volatile objects
Now that the new C standard is out, is there any chance that gcc's behaviour regarding to volatile lhs in an assignment changes?
This is what it does today:
volatile int a, b;
a = b = 0;
translates to
b = 0;
a = b;
because the standard (up to and including C99) stated that the value of the assignment operator is the value of the lhs after the assignment.
The C11 standard says the same but then it explicitely states that the compiler does not have to read back the value of the lhs, not even when the lhs is volatile.
So it is actually legal now not to read back the lhs. Is there a chance for the compiler to get a switch which would tell it explicitely not to read the value back?
Zoltan