This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/82340] volatile ignored in compound literal
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 27 Sep 2017 09:20:42 +0000
- Subject: [Bug c/82340] volatile ignored in compound literal
- Auto-submitted: auto-generated
- References: <bug-82340-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82340
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|middle-end |c
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well. I don't see how a volatile compound literal could make any sense or how
you'd observe the side-effect of multiple stores to it (IIRC compound literals
are constant!?).
So you need to come up with sth more clever to be convincing ;)
Implementation-wise we end up with
volatile char * p;
volatile char D.1801[1];
<bb 2> [0.00%]:
D.1801[0] = 1;
p_6 = &D.1801;
i_7 = 1;
goto <bb 4>; [0.00%]
<bb 3> [0.00%]:
*p_6 ={v} 4;
i_10 = i_2 + 1;
<bb 4> [0.00%]:
# i_2 = PHI <i_7(2), i_10(3)>
if (i_2 <= 9)
goto <bb 3>; [0.00%]
else
goto <bb 5>; [0.00%]
<bb 5> [0.00%]:
_1 ={v} *p_6;
_8 = (int) _1;
which is mostly fine but the initialization of D.1801[0] is not a volatile
access. And after optimization
volatile char D.1801[1];
char _1;
unsigned int ivtmp_2;
int _6;
unsigned int ivtmp_10;
<bb 2> [10.00%]:
<bb 3> [90.00%]:
# ivtmp_2 = PHI <ivtmp_10(3), 9(2)>
MEM[(volatile char *)&D.1801] ={v} 4;
ivtmp_10 = ivtmp_2 + 4294967295;
if (ivtmp_10 != 0)
goto <bb 3>; [88.89%]
else
goto <bb 4>; [11.11%]
<bb 4> [10.00%]:
_1 ={v} MEM[(volatile char *)&D.1801];
_6 = (int) _1;
so GIMPLE does what you want but somewhere on RTL we are too clever in the
end. D.1801 ends up being expanded as a register. Probably the variable
itself is _not_ marked volatile but only the array member type.