-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Patrick Horgan Sent: Wednesday, December 23, 2009 2:50 AM To: boost@lists.boost.org Subject: Re: [boost] [optional] Strict Aliasing Warnings on Trunk
After reading this exchange, am I right in adding this to the GCC 'what to do about warnings' guidelines section at
https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines?
" warning: dereferencing pointer ‘<anonymous>’ does break strict-aliasing rules
This warns about undefined behaviour that is likely to cause unwanted results when optimisation is switched on.
Recommendation: Fix this by recoding if possible, and document that optimisation may
Include a link to the above example email.
Do not suppress the warning with -Wno-strict-warnings - leave that to users after reading
Paul A. Bristow wrote: produce wrong results. the documentation or making their own tests / compile without optimisation.
It's a lot more complex then that. Sometimes that warning comes from safe type punning such as the placement use in boost optional.
OK but there is limit to the detail that can/should be provided in Maintenance Guidelines? So should it read "Be very cautious before suppressing the warning".
I've not convinced myself (yet) that it can't go awry with optimization, in that the optimizer could ignore type-punned access and when you try to retrieve the value get an optimized original value, but others who are quite intelligent and muchly more familiar with it than I believe so.
What I believe we should document is that there *may* be a problem here. And (in the source code too). This might reduce hair loss by users who will assume that something bad could not possibly happen.
I'm definitely in favor of something like this. I've started working on something myself I wanted to put on that page covering common gcc warnings (mostly drawn from warnings from compiling and using boost), their causes and the fixes, and at 268 lines it's getting tomeish. My post in this conversation came from that document via the magic of cut and paste.
I think *you* should edit the wiki gcc section - I'm totally ignorant about gcc.