warning break strict-aliasing rules

[anonymous]

Hello, under x86_64, using g++ 4.4.1 with '-W -Wall -O3' , when trying to compile the code below [code] #include "boost/make_shared.hpp" #include <iostream>

int main(void) {

boost::shared_ptr<std::string> x = boost::make_shared<std::string>("hello, world!"); std::cout << *x;

} code (copied from make_shared doc)

I get the folowing warnings:

boost/smart_ptr/make_shared.hpp:52: warning: dereferencing type-punned pointer will break strict-aliasing rules

[Peter Dimov]

This appears to be a bug in g++ 4.4's alias analysis. I can see a number of such issues marked as fixed in the GCC Bugzilla, so you might want to test again with 4.5.

[anonymous]

I still got the warning with g++ 4.5.0

[Matheus Martino]

That warnings shows you that there is incompatibility betwen boost code and mingw optimization algorithm, it only hapens when using optimizations "-O2", "-O3" and "-Os", it don't hapens with optimizations "-O" and "-O1". If you get that warning, and think it is stoping your app from work, try to change the type of aptimization to "-O" or "-O1".

[anonymous]

Also occurs under linux on ubuntu 64 bit (10.04). It also occurs when using boost log (due to join main boost release?). My version of g++ is below:

ubuntu:~/workspace/.metadata$ g++ -v

Using built-in specs.

Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5' --with-bugurl=​file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)

[anonymous]

Hi, the suggested fix from ​http://tugll.tugraz.at/37921/weblog/12171.html fixes the problem for me on windows with gcc (tdm64-1) 4.5.1

[Peter Dimov]

(In [69251]) Apply suggested fix. Refs #4127.

[Peter Dimov]

(In [70439]) Merge [69251] to release. Fixes #4127.

[anonymous]

I have another occurrence of this warning. I noticed that with -O1 there is no warning. No warning also if I remove -Wstrict-aliasing=2.

In file included from /home/ededu/softs/ekiga/windows-mingww64/include/boost/function/detail/maybe_include.hpp:23:0,

from /home/ededu/softs/ekiga/windows-mingww64/include/boost/function/function2.hpp:11, from /home/ededu/softs/ekiga/windows-mingww64/include/boost/signals/detail/named_slot_map.hpp:18, from /home/ededu/softs/ekiga/windows-mingww64/include/boost/signals/detail/signal_base.hpp:15, from /home/ededu/softs/ekiga/windows-mingww64/include/boost/signals/signal_template.hpp:23, from /home/ededu/softs/ekiga/windows-mingww64/include/boost/signals/signal0.hpp:24, from /home/ededu/softs/ekiga/windows-mingww64/include/boost/signal.hpp:19, from /home/ededu/softs/ekiga/windows-mingww64/include/boost/signals.hpp:9, from ../lib/engine/framework/services.h:47, from ekiga.h:46, from ekiga.cpp:41:

/home/ededu/softs/ekiga/windows-mingww64/include/boost/function/function_template.hpp: In static member function ‘static R boost::detail::function::function_obj_invoker2<FunctionObj, R, T0, T1>::invoke(boost::detail::function::function_buffer&, T0, T1) [with FunctionObj = boost::signals::detail::group_bridge_compare<std::less<int>, int>, R = bool, T0 = boost::signals::detail::stored_group, T1 = boost::signals::detail::stored_group]’: /home/ededu/softs/ekiga/windows-mingww64/include/boost/function/function_template.hpp:907:60: instantiated from ‘void boost::function2<R, T1, T2>::assign_to(Functor) [with Functor = boost::signals::detail::group_bridge_compare<std::less<int>, int>, R = bool, T0 = boost::signals::detail::stored_group, T1 = boost::signals::detail::stored_group]’ /home/ededu/softs/ekiga/windows-mingww64/include/boost/function/function_template.hpp:722:7: instantiated from ‘boost::function2<R, T1, T2>::function2(Functor, typename boost::enable_if_c<boost::type_traits::ice_not<boost::is_integral<Functor>::value>::value, int>::type) [with Functor = boost::signals::detail::group_bridge_compare<std::less<int>, int>, R = bool, T0 = boost::signals::detail::stored_group, T1 = boost::signals::detail::stored_group, typename boost::enable_if_c<boost::type_traits::ice_not<boost::is_integral<Functor>::value>::value, int>::type = int]’ /home/ededu/softs/ekiga/windows-mingww64/include/boost/signals/signal_template.hpp:197:53: instantiated from ‘boost::signal1<R, T1, Combiner, Group, GroupCompare, SlotFunction>::signal1(const Combiner&, const GroupCompare&) [with R = void, T1 = boost::shared_ptr<Ekiga::Service>, Combiner = boost::last_value<void>, Group = int, GroupCompare = std::less<int>, SlotFunction = boost::function1<void, boost::shared_ptr<Ekiga::Service> >]’ ../lib/engine/framework/services.h:73:20: instantiated from here /home/ededu/softs/ekiga/windows-mingww64/include/boost/function/function_template.hpp:129:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]

and others. So it seems function_template.hpp needs the same workaround.

[anonymous]

Any comment on my previous comment?

[anonymous]

Any comment, do you need other information? This generates maybe 150 warning lines per file compiled...

[Peter Dimov]

Have you verified that the same workaround works for function_template?

In either case, this problem is no longer about smart_ptr, so I suggest you create another ticket with "function" as the component and put the information there.

[anonymous]

The fix in comment 6 does not apply, since there the fix was to cut the redirection in two, but in my case there is no redirection.

I have warnings in function_template, signal_template and function_base. I wait for gcc 4.7 on my distro and create a new bug report if it still applies.