public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/15456] New: writing to volatile pointer in C++ may produce extra read after write
@ 2004-05-15 21:32 M dot A dot Bukin at inp dot nsk dot su
  2004-05-16  1:25 ` [Bug c++/15456] " pinskia at gcc dot gnu dot org
  0 siblings, 1 reply; 2+ messages in thread
From: M dot A dot Bukin at inp dot nsk dot su @ 2004-05-15 21:32 UTC (permalink / raw)
  To: gcc-bugs

Accessing hardware registers mapped in address space requires
the use of volatile pointer - to leave all accesses in the result
and not optimize them away.  But writing to volatile pointer in C++
may result in extra read instruction right after write,
which may obviously trigger some undesired action in hardware,
as memory access actually accesses mmapped hardware register.

The program below demonstrates this behaviour, when compiled with
bash$ gcc -O2 -S test_volatile_ptr.cpp

Here is a short snippet of assembly output, which you should look for:
	movl	$128, (%eax)
        ...
	movl	(%eax), %eax   ; I don't like this one

bash$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)

Complete source code:

cat >test_volatile_ptr.cpp <<EOF
// <test_volatile_ptr.cpp>

// Pointer to hardware registers mapped in our address space.
// volatile is to prevent read/write optimizations.
volatile unsigned long *addr;

// Helper function to set memory mapped register.
inline void _set (unsigned long _offs, unsigned long _data)
{
  addr[_offs] = _data;
}

// This one produces correct assembler output.
void init_good ()
{
  addr[0] = 0x80;
}

// This one adds extra read after write,
// Which in case of memory mapped hardware access
// may trigger undesired action in hardware.
void init_bad ()
{
  _set (0, 0x80);
}

// </test_volatile_ptr.cpp>
EOF

-- 
           Summary: writing to volatile pointer in C++ may produce extra
                    read after write
           Product: gcc
           Version: 2.96 (redhat)
            Status: UNCONFIRMED
          Severity: minor
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: M dot A dot Bukin at inp dot nsk dot su
                CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i386-redhat-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15456


^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug c++/15456] writing to volatile pointer in C++ may produce extra read after write
  2004-05-15 21:32 [Bug c++/15456] New: writing to volatile pointer in C++ may produce extra read after write M dot A dot Bukin at inp dot nsk dot su
@ 2004-05-16  1:25 ` pinskia at gcc dot gnu dot org
  0 siblings, 0 replies; 2+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-05-16  1:25 UTC (permalink / raw)
  To: gcc-bugs


------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-15 12:10 -------
Fixed in at least 3.2.2, time to update your gcc.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
      Known to work|                            |3.2.3 3.2.2 3.3.3
         Resolution|                            |FIXED
   Target Milestone|---                         |3.1.x/3.2.x


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15456


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2004-05-15 12:10 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-05-15 21:32 [Bug c++/15456] New: writing to volatile pointer in C++ may produce extra read after write M dot A dot Bukin at inp dot nsk dot su
2004-05-16  1:25 ` [Bug c++/15456] " pinskia 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).