[Function][Bind] Strange problem with g++ 4.5
Hi, I've got a very strange problem with Boost.Function used in conjunction with Boost.Bind with g++ 4.5.0. Here is the minimal test case: ----------------gtest.cc--------------------------------- #include <boost/bind.hpp> #include <boost/function.hpp> #include <iostream> int fun(const int* id) { std::cout << "id: " << id << std::endl; std::cout << *id << std::endl; return 0; } int main() { typedef boost::function<int ()> func_t; int id = 42; std::cout << "id: " << &id << std::endl; func_t f = boost::bind(&fun, &id); //std::cout << f << std::endl; func_t g = f; g(); return 0; } ------------------------------------------------- When compiled with -O2 the program crashes: ------------------------------------------------- $ g++ -O2 gtest.cc && ./a.out id: 0x7fff3f7f85ec id: 0 Segmentation fault ------------------------------------------------- The problem seems to be inlining, when compiled with -O0 or -O2 -fno-inline everything works fine: ------------------------------------------------- $ g++ -O2 -fno-inline gtest.cc && ./a.out id: 0x7fff32b81a9c id: 0x7fff32b81a9c 42 $ g++ -O0 gtest.cc && ./a.out id: 0x7fff960b270c id: 0x7fff960b270c 42 ------------------------------------------------- What is very strange is that if I uncomment the std::cout of f everything works fine: ------------------------------------------------- $ g++ -O2 gtest.cc && ./a.out id: 0x7fff738619ac 1 id: 0x7fff738619ac 42 ------------------------------------------------- If the Boost.Function is not copied to g (ie, use f) everything works. Everything works fine with g++ (GCC) 4.4.3 20100316 (prerelease). I'm using Linux x86_64 with boost 1.42 and 1.43. Any idea of what may be going wrong here? -- Maxime
Maxime van Noppen wrote:
Hi,
I've got a very strange problem with Boost.Function used in conjunction with Boost.Bind with g++ 4.5.0.
Here is the minimal test case: ...
I think that this sounds very much like an optimizer bug and the way to understand what's going on is to submit a bug report to the GCC bugzilla. It could, in principle, be an aliasing violation issue in boost::function, but I doubt it. g++ since 4.4 is getting more aggressive with its aliasing assumptions when optimizing.
On 05/15/2010 09:18 PM, Peter Dimov wrote:
I think that this sounds very much like an optimizer bug and the way to understand what's going on is to submit a bug report to the GCC bugzilla. It could, in principle, be an aliasing violation issue in boost::function, but I doubt it. g++ since 4.4 is getting more aggressive with its aliasing assumptions when optimizing.
Ouch. I'll report to GCC then. -- Maxime
On 05/17/2010 10:05 AM, Maxime van Noppen wrote:
On 05/15/2010 09:18 PM, Peter Dimov wrote:
I think that this sounds very much like an optimizer bug and the way to understand what's going on is to submit a bug report to the GCC bugzilla. It could, in principle, be an aliasing violation issue in boost::function, but I doubt it. g++ since 4.4 is getting more aggressive with its aliasing assumptions when optimizing.
Ouch. I'll report to GCC then.
Maxime van Noppen:
On 05/17/2010 10:05 AM, Maxime van Noppen wrote:
On 05/15/2010 09:18 PM, Peter Dimov wrote:
I think that this sounds very much like an optimizer bug and the way to understand what's going on is to submit a bug report to the GCC bugzilla. It could, in principle, be an aliasing violation issue in boost::function, but I doubt it. g++ since 4.4 is getting more aggressive with its aliasing assumptions when optimizing.
Ouch. I'll report to GCC then.
Thanks. I'm trying to retrieve the password for my Bugzilla account - with no luck so far. You may want to relay to Richard that after stepping through the code, it turns out that function_buffer is indeed assigned directly, due to the fact that __has_trivial_copy and __has_trivial_destructor report true for the stored function object.
participants (2)
-
Maxime van Noppen
-
Peter Dimov