This is the mail archive of the gcc@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: Assignment to volatile objects


On 30/01/12 23:22, Paul_Koning@Dell.com wrote:
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.


Until gcc gets a feature allowing it to whack the programmer on the back of the head with Knuth's "The Art of Computer Programming" for writing such stupid code that relies on the behaviour of volatile "a = b = 0;", then a warning seems like a good idea.


mvh.,

David


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



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