Description of problem: It seems that g++ will produce an odd warning when compiled with -fno-exceptions for an application that uses pthread_cleanup_push. Version-Release number of selected component (if applicable): [jwboyer@vader ~]$ rpm -q gcc-c++ gcc-c++-4.1.2-33 How reproducible: Always Steps to Reproduce: 1. Copy test program 2. Build with: g++ -O2 -Wall -fno-exceptions test.C -o foo -lpthread 3. Actual results: test.C: In member function ‘void foo::push(uint32_t)’: test.C:22: warning: type-punning to incomplete type might break strict-aliasing rules test.C: In member function ‘void foo::pop(uint32_t&)’: test.C:28: warning: type-punning to incomplete type might break strict-aliasing rules Expected results: No warning? Not sure exactly. Additional info: From what I can tell, pthread.h will use a __pthread_cleanup_class when building C++ code normally. However, when -fno-exceptions is passed, it expands the macro to use a __pthread_unwind_buf_t used in conjunction with __sigsetjmp. The warning seems to come from something to do with __sigsetjmp, but I can't tell what exactly.
Created attachment 257601 [details] small test app to try compiling Compiling this test app shows the warning when passing -fno-exceptions. (Yes, I know the application is stupid and broken. It's only to illustrate the warning that I can't figure out.) [jwboyer@vader ~]$ g++ -O2 -Wall test.C -o foo -lpthread [jwboyer@vader ~]$ g++ -O2 -Wall -fno-exceptions test.C -o foo -lpthread test.C: In member function ‘void foo::push(uint32_t)’: test.C:22: warning: type-punning to incomplete type might break strict-aliasing rules test.C: In member function ‘void foo::pop(uint32_t&)’: test.C:28: warning: type-punning to incomplete type might break strict-aliasing rules [jwboyer@vader ~]$
Ok, I can't figure out what the compiler is warning about. I even tried using -dD -E to get preprocessed output and that didn't lead me to any further conclusions. I'm not sure if this is a g++ bogus warning, or if something is truly broken here.
This seems to happen on all of the more recent distros I've tried. Perhaps an upstream bug should be opened? If so, should it be done against GCC or glibc?
If you use cancellation, then it is terribly bad idea to compile with -fno-exceptions. That said, I have added an extra void * cast to shut up the warnings with g++ 4.1/4.2, g++ 4.3 is smart enough not to warn in this case.
(In reply to comment #4) > If you use cancellation, then it is terribly bad idea to compile with > -fno-exceptions. That said, I have added an extra void * cast to shut up the > warnings with g++ 4.1/4.2, g++ 4.3 is smart enough not to warn in this case. Thanks Jakub.