Re: [boost] [SIGNAL/BIND] Regressions with GCC 4.1 RC.

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-02-28 07:49:10

Douglas Gregor wrote:
> On Feb 20, 2006, at 12:22 PM, Lars Gullik Bjønnes wrote:
>> We se some strange problems with GCC 4.1 (the prerelease/release
>> candidate) with use of boost::signal and boost::bind. Have anyone run
>> the regressions tests for this GCC version?
>>
>> g++ (GCC) 4.1.0 20060219 (prerelease
>>
>> We get errors of this form:
>> [snip]
>> <gcc41-1.diff>
>>
>> Any opinions on this?
>
> Hmmm, I'm surprised that patch fixes the problem.
>
>> Is it something strange hidden in our code, boost or a real
>> regression
>> in gcc?
>
> There is definitely a bug in Boost.CVS. However, I didn't think that
> GCC 4.1 should be susceptible to the bug; I remember fixing this bug
> for GCC 4.0.1, and it works there. So we might actually have two
> bugs; I really don't know
>
> The Boost bug is an interaction between the storage optimizations
> that went in to Bind (to make the storage optimizations of Function
> actually useful) and the visit_each mechanism.

You're mixing these up. The bug in this thread is present in 1.33.1 which 
doesn't have the storage optimization. It only shows up on proper two-phase 
lookup compilers because the primary declaration of visit_each wasn't 
#included.

> I've taken a stab at a
> fix (to Bind) that seems to solve the problem for me on GCC 3.3; it
> should solve the problems on other compilers as well.
>
> Attached is a patch to bind and a test case that illustrates the
> problem. Peter, could you take a look?

The patch seems good to me. There are several things that I don't like in 
the test, though; (a) it doesn't actually test anything, (b) it uses 
boost/test instead of lightweight_test.hpp, (c) it binds std::plus<> with 
one argument, which is invalid and can be rejected by a conforming bind.

I tried to fix it, but an interesting question has come up. The primary 
visit_each is defined as:

    template<typename Visitor, typename T>
    inline void visit_each(Visitor& visitor, const T& t);

By forcing a const qualification on the visited object, this interface 
prevents a visitor from mutating it (in addition to breaking when a function 
is being passed for t.) Is this deliberate or accidental?

I've also found bind_visitor.cpp. Looks like it expects a certain number of 
visitations, though, so the storage optimization will break it either way.

Anyway. Could you please look at the attached test case and confirm that it 
passes with your patch applied?