Re: [boost] [optional] Strict Aliasing Warnings on Trunk

Subject: Re: [boost] [optional] Strict Aliasing Warnings on Trunk
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2009-12-23 13:01:32

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On Behalf Of
> Patrick Horgan
> Sent: Wednesday, December 23, 2009 2:50 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] [optional] Strict Aliasing Warnings on Trunk
> 
> Paul A. Bristow wrote:
> > 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
> produce wrong results.
> > Include a link to the above example email.
> >
> > Do not suppress the warning with -Wno-strict-warnings - leave that to users after reading
> 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.