public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/26933] New: Volatile member in struct member accessed/written implicitly
@ 2006-03-29 21:10 ivan at vmfacility dot fr
2006-03-29 21:18 ` [Bug c/26933] " ivan at vmfacility dot fr
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: ivan at vmfacility dot fr @ 2006-03-29 21:10 UTC (permalink / raw)
To: gcc-bugs
This actually occurs on 3.3.3 and 4.0.3 (haven't tried others).
When a structure contains a 32 bit int, and because of alignement, it is not
located on a 64 bit boundary *and* (apparently) the compiler aligns a bitfield
int on the first fullword, operations on that bitfield implicitly access the
volatile member.
For exemple, the following structure is affected :
struct foo
{
long long A;
int B:1;
volatile int C;
};
In this case, storing into foo.b triggers a load and a store from foo.C.
The following code sample demonstrates that :
struct _test1
{
long long A;
int B:1;
volatile int C;
};
unsigned int foo(struct _test1 *data)
{
data->B=1;
return data->C;
}
Generating assembler output with "gcc -m64 foo.c -S" shows the following for
function "foo" (comments are my own)
ld 9,112(31) * Get "data"
ld 11,8(9) * get data->B 64 bit value - including data->C
li 0,-1 * Set
rldicr 0,0,0,0 * The Right
or 0,11,0 * Bit and
std 0,8(9) * Store 64 bit value Including data->C
ld 9,112(31) * get data again
lwz 0,12(9) * get C for return
If data->C is altered somewhere else (thread for exemple) or if read or writing
C has a side affect (I/O area) then although the code has never explicitly
accessed or stored data in the code, the program will implictly access or store
in that field - thus defeating the purpose of the 'volatile' type specifier.
Note that this occurs EVEN without optimization.
This problem may or may not affect other 64 bit platforms (this depends whether
it is insns generation related or backend related or both).
*Possible Workaround*
If feasable - align serializable 32 bit ints manually to ensure 64 bit
alignement.
Note that I also have a 'working' program that demonstrates the volatile
variable being altered without being accessed explicitly... I can provide it if
necessary.
--Ivan
--
Summary: Volatile member in struct member accessed/written
implicitly
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ivan at vmfacility dot fr
GCC build triplet: powerpc-linux-gnu
GCC host triplet: powerpc-linux-gnu
GCC target triplet: powerpc64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26933
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c/26933] Volatile member in struct member accessed/written implicitly
2006-03-29 21:10 [Bug c/26933] New: Volatile member in struct member accessed/written implicitly ivan at vmfacility dot fr
@ 2006-03-29 21:18 ` ivan at vmfacility dot fr
2009-04-01 1:01 ` [Bug middle-end/26933] " bje at gcc dot gnu dot org
2009-04-09 6:17 ` bje at gcc dot gnu dot org
2 siblings, 0 replies; 4+ messages in thread
From: ivan at vmfacility dot fr @ 2006-03-29 21:18 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from ivan at vmfacility dot fr 2006-03-29 21:18 -------
Created an attachment (id=11158)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11158&action=view)
Runnable program demonstrating the problem
This program, once compiled for powerpc64 and run on powerpc64 demonstrates a
volatile field being implicitly accessed/changed by the explicit change of a
neighbouring value.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26933
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/26933] Volatile member in struct member accessed/written implicitly
2006-03-29 21:10 [Bug c/26933] New: Volatile member in struct member accessed/written implicitly ivan at vmfacility dot fr
2006-03-29 21:18 ` [Bug c/26933] " ivan at vmfacility dot fr
@ 2009-04-01 1:01 ` bje at gcc dot gnu dot org
2009-04-09 6:17 ` bje at gcc dot gnu dot org
2 siblings, 0 replies; 4+ messages in thread
From: bje at gcc dot gnu dot org @ 2009-04-01 1:01 UTC (permalink / raw)
To: gcc-bugs
--
bje at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |bje at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-04-01 01:00:38
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26933
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/26933] Volatile member in struct member accessed/written implicitly
2006-03-29 21:10 [Bug c/26933] New: Volatile member in struct member accessed/written implicitly ivan at vmfacility dot fr
2006-03-29 21:18 ` [Bug c/26933] " ivan at vmfacility dot fr
2009-04-01 1:01 ` [Bug middle-end/26933] " bje at gcc dot gnu dot org
@ 2009-04-09 6:17 ` bje at gcc dot gnu dot org
2 siblings, 0 replies; 4+ messages in thread
From: bje at gcc dot gnu dot org @ 2009-04-09 6:17 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from bje at gcc dot gnu dot org 2009-04-09 06:17 -------
Reproduced.
--
bje at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to fail| |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26933
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-04-09 6:17 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-03-29 21:10 [Bug c/26933] New: Volatile member in struct member accessed/written implicitly ivan at vmfacility dot fr
2006-03-29 21:18 ` [Bug c/26933] " ivan at vmfacility dot fr
2009-04-01 1:01 ` [Bug middle-end/26933] " bje at gcc dot gnu dot org
2009-04-09 6:17 ` bje at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).