From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-181537-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 30086 invoked by alias); 29 Mar 2006 21:10:45 -0000
Received: (qmail 30071 invoked by uid 48); 29 Mar 2006 21:10:42 -0000
Date: Wed, 29 Mar 2006 21:10:00 -0000
Subject: [Bug c/26933]  New: Volatile member in struct member accessed/written implicitly
X-Bugzilla-Reason: CC
Message-ID: <bug-26933-5984@http.gcc.gnu.org/bugzilla/>
Reply-To: gcc-bugzilla@gcc.gnu.org
To: gcc-bugs@gcc.gnu.org
From: "ivan at vmfacility dot fr" <gcc-bugzilla@gcc.gnu.org>
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2006-03/txt/msg02896.txt.bz2
List-Id: <gcc-bugs.sourceware.org>

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