GCC 4.6.x + Boost.Signals == failure

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

GCC 4.6.x + Boost.Signals == failure

Bryce Lelbach (wash)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Who is the Boost.Signals maintainer? Boost.Signals fails to build against a
stage-3 GCC build (GCC 4.6.x, r169444) due to an ambigious call to the erase
method of a std::map<>.

Do we have a GCC 4.6.x tester? This compiler is in the Debian- and Ubuntu-
distribution these days. According to the regressions page, we don't appear to
have a GCC 4.6.x tester... this would be nice to have.

- --
Bryce Lelbach aka wash
boost-spirit.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAk1M4qUACgkQ9cB/V3/s9EwaGACeLl0j1IqPnrifdouCW1IfLGAC
MqoAn2Z8IrxozFNbvwpNsS/HSr0XUD4f
=JTd2
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.6.x + Boost.Signals == failure

Vicente Botet
Bryce Lelbach aka wash wrote
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Who is the Boost.Signals maintainer? Boost.Signals fails to build against a
stage-3 GCC build (GCC 4.6.x, r169444) due to an ambigious call to the erase
method of a std::map<>.

Do we have a GCC 4.6.x tester? This compiler is in the Debian- and Ubuntu-
distribution these days. According to the regressions page, we don't appear to
have a GCC 4.6.x tester... this would be nice to have.
We have Win7-x64 jc-bell.com  who is testing gcc-mingw-4.6.0 on trunk.

BTW, no errors for Boost.Signal in last report rev 68358. Which version of Boost.Signals fails?
Vicente
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.6.x + Boost.Signals == failure

Bryce Lelbach (wash)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 5 Feb 2011 01:20:39 -0800 (PST)
Vicente Botet <[hidden email]> wrote:

> BTW, no errors for Boost.Signal in last report rev 68358.

Right. No errors, because there is no tester for the broken environment :)

> Which version of Boost.Signals fails?

The last change on the broken file in question was about a year ago. So, I'd say
any version from about a year ago till now compiled against recentish built
GCC 4.6.x

Find attached a patch for this bug. The problem: GNU stdlib failure or GNU
stdlib failure compounded by GCC failure. Passing a parameter of type
std::map<>::iterator to std::map<>::erase() is ambigious for silly reasons.
Definitions for std::map<>::erase() in the GNU stdlib are provided for
std::map<>::key_type const& and std::map<>::const_iterator, if c++0x support is
enabled (which apparently seems to be just the "default" state of GCC these
days). If c++0x support is disabled, the working C++99 std::map<>::erase()
which takes an std::map<>::iterator is enabled (in C++0x, erase()'s return type
changes from void to iterator).

- --
Bryce Lelbach aka wash
boost-spirit.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAk1PPWcACgkQ9cB/V3/s9ExnGgCfXYMObT6yV81CHgSP/J6H4ihi
YXsAnR5PuaWGIAZc4djdzdmnmk7IlXFZ
=VVGr
-----END PGP SIGNATURE-----

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

signals.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.6.x + Boost.Signals == failure

Steven Watanabe-4
AMDG

On 2/6/2011 4:31 PM, Bryce Lelbach (wash) wrote:

> On Sat, 5 Feb 2011 01:20:39 -0800 (PST)
> Vicente Botet<[hidden email]>  wrote:
>
>> BTW, no errors for Boost.Signal in last report rev 68358.
>
> Right. No errors, because there is no tester for the broken environment :)
>
>> Which version of Boost.Signals fails?
>
> The last change on the broken file in question was about a year ago. So, I'd say
> any version from about a year ago till now compiled against recentish built
> GCC 4.6.x
>
> Find attached a patch for this bug. The problem: GNU stdlib failure or GNU
> stdlib failure compounded by GCC failure. Passing a parameter of type
> std::map<>::iterator to std::map<>::erase() is ambigious for silly reasons.
> Definitions for std::map<>::erase() in the GNU stdlib are provided for
> std::map<>::key_type const&  and std::map<>::const_iterator, if c++0x support is
> enabled (which apparently seems to be just the "default" state of GCC these
> days). If c++0x support is disabled, the working C++99 std::map<>::erase()
> which takes an std::map<>::iterator is enabled (in C++0x, erase()'s return type
> changes from void to iterator).
>

a) Please check defined(__GNUC__) first to avoid warnings
b) __GNUC__ >= 4 && __GNUC_MINOR__ >= 6 is a little
    silly, since it will be false for gcc 5.0.
c) Will the patch work when C++0x support is disabled?

In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.6.x + Boost.Signals == failure

Bryce Lelbach (wash)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 06 Feb 2011 17:07:34 -0800
Steven Watanabe <[hidden email]> wrote:

> a) Please check defined(__GNUC__) first to avoid warnings

K

> b) __GNUC__ >= 4 && __GNUC_MINOR__ >= 6 is a little
>     silly, since it will be false for gcc 5.0.

Good point

> c) Will the patch work when C++0x support is disabled?

No, should probably check for the G++ detection macro as well.

- --
Bryce Lelbach aka wash
boost-spirit.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAk1PRx0ACgkQ9cB/V3/s9EwBKACdHgRB3bnEeyZwkkzSNMMPxNVW
mW8AnjIJ1YseDCvHpuogbIETw+B7JfZR
=I5H4
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: GCC 4.6.x + Boost.Signals == failure

Bryce Lelbach (wash)
In reply to this post by Steven Watanabe-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Turns out that this behavior is not a GCC bug, a change in the definition of
erase is in fact mandated in C++0x. Better solution is needed here - GCC people
suggested one which I have yet to try..

- --
Bryce Lelbach aka wash
boost-spirit.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAk1QtK8ACgkQ9cB/V3/s9ExYogCdFA6FvpE/XO/4JWxAUKqCcZ83
jJwAn2aQvT74kFeLTSnL1DGUS0mVBphI
=SfqE
-----END PGP SIGNATURE-----
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost