[Bug c++/46096] New: Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

   Summary: Code produces two different outputs when optimized
respectively with -O2 and without it.
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zwei...@gmail.com


Created attachment 22093
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22093
Minimal testcase

The code attached is a very simple application of threads using SDL_threads
library. 

In the code just one thread is created and it should enter in a loop waiting
for a class variable to become 4 and exit printing END on the screen. Since
the variable is modified to 4 in the main program, the thread should exit and
print END on the screen always. However, this does not happen all the time in
the -O2 compiled version.

The compiled version WITHOUT -O2 gives the expected output END (Reproducible:
always).
On the other hand, the -O2 version of the code produces an executable which
sometimes print and sometimes do not print END on the screen (Occasionally
one may need to run the program 20 times to spot 1 error). 

I attached the very simple test.cpp file.

And here is the output from g++ without optimization:

g++ -v -save-temps -o sdl_thread -Wall test.cpp -lSDL 
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.3.4/work/gcc-4.3.4/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.4
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror --enable-secureplt
--disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp
--disable-libgcj --with-arch=i686 --enable-languages=c,c++,treelang,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.3.4 p1.1, pie-10.1.5'
Thread model: posix
gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sdl_thread' '-Wall'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -D_FORTIFY_SOURCE=2 -mtune=generic -march=i686 -Wall -fpch-preprocess
-o test.ii
ignoring nonexistent directory
/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/i686-pc-linux-gnu
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/backward
 /usr/local/include
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sdl_thread' '-Wall'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cpp -mtune=generic -march=i686 -auxbase test -Wall -version -o
test.s
GNU C++ (Gentoo 4.3.4 p1.1, pie-10.1.5) version 4.3.4 (i686-pc-linux-gnu)
compiled by GNU C version 4.3.4, GMP version 4.3.2, MPFR version 2.4.1-p5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a9af7e955b36498814b0c0d47ad1b377
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sdl_thread' '-Wall'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/bin/as -V
-Qy -o test.o test.s
GNU assembler version 2.18 (i686-pc-linux-gnu) using BFD version (GNU Binutils)
2.18
COMPILER_PATH=/usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/:/usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/lib/:/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'sdl_thread' '-Wall'
'-shared-libgcc' '-mtune=generic' '-march=i686'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.3.4/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker 

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

--- Comment #2 from Danilo zweifel at gmail dot com 2010-10-20 14:07:45 UTC 
---
(In reply to comment #1)
 There is no memory synchronisation, so there is no guarantee that the write to
 alpha1-number ever becomes visible to other threads.

According to http://wiki.libsdl.org/moin.cgi/SDL_CreateThread, the threads
created share the same memory. So I guess sync is not needed.

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

Danilo zweifel at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #3 from Danilo zweifel at gmail dot com 2010-10-20 14:17:30 UTC 
---
Changed the status back to unconfirmed.

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

--- Comment #9 from Danilo zweifel at gmail dot com 2010-10-20 14:43:18 UTC 
---
(In reply to comment #7)
  Using a mutex around the reads and writes of shared data will make it work 
  as
  expected, the compiler won't optimise away the read and will re-read the 
  value
  every time.
 
 This is overkill here though, you just need:
 
   volatile alpha *alpha1 = ( alpha * )data;

This solved it! Did not know about volatile variables. I was trying to avoid
exactly the use of mutexes and the like.

Thank you very much!

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

Danilo zweifel at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #10 from Danilo zweifel at gmail dot com 2010-10-20 14:45:18 UTC 
---
(In reply to comment #8)
 I don't recommend people use volatile to avoid multithreading races, it only
 prevents compiler optimisations, not hardware reordering. Using proper 
 atomics,
 memory barriers or other explicit synchronisation is better.
 But for this testcase, yes, volatile will fix it.
 
 Danilo, you might like to read these
 http://www.drdobbs.com/cpp/201804238
 http://www.drdobbs.com/high-performance-computing/212701484

Thanks you very much, Jonathan! I will surely read the references.

I am considering this as closed.

[Bug c++/46096] Code produces two different outputs when optimized respectively with -O2 and without it.

[zweifel at gmail dot com]

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

--- Comment #12 from Danilo zweifel at gmail dot com 2010-10-20 16:53:53 UTC 
---
(In reply to comment #11)
 Busy waiting is rarely a good idea, so it depends on what are you exactly
 waiting for and whether say pthread_barrier_wait, or mutex, or condvar etc.
 wouldn't be more appropriate.

My objective of using threads is to detach a system in a simulation
environment. For this reason, it would be impracticable to use any type of lock
for everytime the I/O changes (which will happen all the time), so I guess
volatiles are the only way??

I am still reading the sites posted by Jonathan and understanding the
difficulties of doing this in modern CPUs, while it is so easy in hardware.
Maybe just always compiling without optimizations will do?

[Bug c++/36175] New: Definition of listClass* not working inside structure

[zweifel at gmail dot com]

Hello,

I tried to include a list Class* inside a structure and it does not worked.
And everytime I compile I get a linker error like that:
 error: no matching function for call to `

Character.cpp:365: error: no matching function for call to
'std::listCharacter_Data*, std::allocatorCharacter_Data*
::remove(Character* const)'
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/list.tcc:174: note:
candidates are: void std::list_Tp, _Alloc::remove(const _Tp) [with _Tp =
Character_Data*, _Alloc = std::allocatorCharacter_Data*]

I tried to compile something similar on Visual Studio and it had compiled, then
I think it could be something related to g++.
I hope this information could help.


-- 
   Summary: Definition of listClass* not working inside structure
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zweifel at gmail dot com


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