public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ivan at vmfacility dot fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/26933]  New: Volatile member in struct member accessed/written implicitly
Date: Wed, 29 Mar 2006 21:10:00 -0000	[thread overview]
Message-ID: <bug-26933-5984@http.gcc.gnu.org/bugzilla/> (raw)

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


             reply	other threads:[~2006-03-29 21:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-29 21:10 ivan at vmfacility dot fr [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-26933-5984@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).