[Boost-bugs] [Boost C++ Libraries] #13479: GCC-warning: break strict-aliasing rules in <boost/type_traits/integral_constant.hpp>

Subject: [Boost-bugs] [Boost C++ Libraries] #13479: GCC-warning: break strict-aliasing rules in <boost/type_traits/integral_constant.hpp>
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2018-03-13 14:25:16

#13479: GCC-warning: break strict-aliasing rules in
<boost/type_traits/integral_constant.hpp>
------------------------------+--------------------------
 Reporter:  ibiatiroler@…     |      Owner:  John Maddock
     Type:  Bugs              |     Status:  new
Milestone:  To Be Determined  |  Component:  type_traits
  Version:  Boost 1.65.0      |   Severity:  Problem
 Keywords:  GCC               |
------------------------------+--------------------------
 Currently, I receive the GCC-warning 'warning: dereferencing type-punned
 pointer will break strict-aliasing rules [-Wstrict-aliasing]' about the
 (indirect included) header-file
 <boost/boost/type_traits/integral_constant.hpp> (e.g. line 93), if:
  * I compile with GCC 4.6.4 or 6.4.0, and
  * boost 1.60.0 or 1.65.1, and
  * the option -Wstrict-aliasing=2 is used; not with on level 1 or 3
  * and optimization-level -O2 or -Os (or above), not with -O0,-O1 (or -Og
 on GCC 6)

 IMHO, the reinterpret_cast from &data (I.e.g casting from const char*)
 causes this issue (and not using the dereference-helper afterwards, which
 comment shows that this is a GCC-work-around).

 As work-around I'm using an additional const void* - helper-variable (ptr)
 instead of using &data directly, which seems to satisfy the compiler:

 {{{
   operator const mpl::bool_<val>& ()const
   {
     static const char data = 0;
     void const* ptr = &data;
     return dereference(reinterpret_cast<const mpl::bool_<val>*>(ptr));
   }
 }}}

 ... similar code-snippet also for 'operator const mpl::integral_c<T, val>&
 ()const' on line 65 ...
 [Note: using 'void const* const ptr =&data;' does not fix it]

 As alternative, an additional cast '(uintptr_t)&data' within
 reinterpret_cast seems to fix/inhibit this compiler-warning also.

 At least, is my fix/work-around a feasible solution (without any side-
 effects)?

 Best regards from Salzburg,
 Markus

-- 
Ticket URL: <https://svn.boost.org/trac10/ticket/13479>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.