c++ & c differ on 'volatile' interpretations

[Robert Lipe]

The example assembler output shown is from a mips-elf target on a linux
host.  I don't suspect that actually matters as I also see similar
results on my OpenServer native (x86) target.  The code is from the EGCS
trunk of 981103.

When volatility counts, it's pretty common to have to do things like a
read of a latch to clear an interrupt state or to resynchronize a write
buffer.  This is often done like this:

void
clear_thingy(void)
{
        *(volatile int*) 1234;
}

$ emips-gcc -x c  -fno-exceptions -O -c -W x.cc
clear_thingy():
   0:   240204d2        li      $v0,1234
   4:   8c420000        lw      $v0,0($v0)
   8:   03e00008        jr      $ra
   c:   00000000        nop

Perfect.   A single one-word read of address 1234.

[ If the tools were really smart and this was being inlined, it could do
this while trouncing zero registers in one opcode by doing a simple
	lw $0, 1234(0)
but that's a different issue. ]

Of course, if this expression wasn't volatile, it would make no sense, and
gcc tells us about this.

$ emips-gcc -Dvolatile= -x c  -fno-exceptions -O -c -W x.cc
x.cc: In function `clear_thingy':
x.cc:4: warning: statement with no effect

If you then disassemble that object, it's an empty function.


If we change it to compile this as C++, the rules seem to change.
Whether this is a difference in language specs or a compiler problem
isn't obvious to me.  This construct has worked in C++ in the past, but
I fully understand that doesn't mean much. :-) It almost looks like it's
not seeing the volatile qualifier here.

$ emips-gcc -x c++  -fno-exceptions -O -c -W x.cc
x.cc: In function `void clear_thingy()':
x.cc:4: warning: statement with no effect
(robertl) rjlinux:/home/robertl/src/tigger/rap1/fw/fep
$ mips-dis x.o
x.o: no recognized debugging information

x.o:     file format elf32-bigmips

Disassembly of section .text:

0000000000000000 <clear_thingy(void)>:
clear_thingy(void)():
   0:   03e00008        jr      $ra
   4:   00000000        nop


Is this no longer the way to express this in C++ or is this a bug?

Thanx,
RJL