[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-li

[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  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  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #3 from Danilo  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  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  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #10 from Danilo  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  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 list not working inside structure

[zweifel at gmail dot com]

Hello,

I tried to include a list  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::list
>::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::allocator]

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 list 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