http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #25 from Niall Douglas
2012-06-14 16:37:15 UTC ---
(In reply to comment #24)
> (In reply to comment #22)
> > I can submit a wishlist issue for GCC for the above if it doesn't already
> > exist?
>
> Sure.
Added as #53673.
Niall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #24 from Jonathan Wakely 2012-06-14
16:23:48 UTC ---
(In reply to comment #22)
> The loss of std::pair interop between
> C++03 and C++11 in my mind is pretty fatal for a lot of end users.
It's a bug. It's being addressed.
> I can s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #23 from Jonathan Wakely 2012-06-14
16:22:05 UTC ---
(In reply to comment #21)
> So this boils down to that we cannot have a c++11/non-c++11 heterogenous
> environment on a system. One would have to build all libraries for both
> stan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #22 from Niall Douglas
2012-06-14 16:16:19 UTC ---
(In reply to comment #20)
> That wouldn't help if you built one object with -std=c++11 and another with
> -std=c++98 and linked them both into the same .so, you'd have the symbol, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #21 from Jonas Wielicki 2012-06-14 16:10:38 UTC ---
So this boils down to that we cannot have a c++11/non-c++11 heterogenous
environment on a system. One would have to build all libraries for both
standards until c++11 is well establis
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #20 from Jonathan Wakely 2012-06-14
15:45:23 UTC ---
That wouldn't help if you built one object with -std=c++11 and another with
-std=c++98 and linked them both into the same .so, you'd have the symbol, but
wouldn't have built everyth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #19 from Jonas Wielicki 2012-06-14 15:21:07 UTC ---
Right, because otherwise I would not consider that as a safe verification that
this is indeed a duplicate of the referenced bug. And I like safe
verifications.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #18 from Niall Douglas
2012-06-14 15:15:30 UTC ---
(In reply to comment #17)
> (In reply to comment #16)
> > I think I built it correctly with std=c++11, but is there a way to verify
> > this
> > properly in the built library?
>
> c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #17 from Jonathan Wakely 2012-06-14
14:00:50 UTC ---
(In reply to comment #16)
> I think I built it correctly with std=c++11, but is there a way to verify this
> properly in the built library?
crashtest.cpp doesn't crash ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #16 from Jonas Wielicki 2012-06-14 13:26:53 UTC ---
I think I built it correctly with std=c++11, but is there a way to verify this
properly in the built library?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #15 from Niall Douglas
2012-06-14 13:24:58 UTC ---
Agreed, but it is highly unlikely to happen anytime soon unless a new sponsor
turns up. BPL needs a fair bit of post-bitrot work as it is.
Niall
(In reply to comment #12)
> Maybe so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #14 from Jonathan Wakely 2012-06-14
13:21:59 UTC ---
(In reply to comment #0)
> I tried boost as delivered with fedora 17, a home-compiled version with
> -std=c++11 and a home-compiled version without c++11. The c++11 flag on the
> _l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #12 from Jonathan Wakely 2012-06-14
12:51:08 UTC ---
Maybe someone should look at fixing these warnings in Boost.Python, or ensure
-fno-strict-aliasing is used
"g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #11 from Niall Douglas
2012-06-14 11:49:01 UTC ---
(In reply to comment #9)
> maybe related: https://svn.boost.org/trac/boost/ticket/6919
> Had similar crash issue. Though in my case (which may well be different from
> the OP) rebuild
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #10 from mbec at gmto dot org 2012-06-14 00:47:04 UTC ---
found the OP crashtest source at the tail of .ii attachment file, that compiles
and runs fine with my new rpm.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #9 from mbec at gmto dot org 2012-06-13 22:14:31 UTC ---
maybe related: https://svn.boost.org/trac/boost/ticket/6919
Had similar crash issue. Though in my case (which may well be different from
the OP) rebuilding boost with new flags fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #8 from Jonas Wielicki 2012-05-24 14:48:23 UTC ---
I was able to use the VM sooner than expected, so sorry for the doublepost.
I found that whether using no_init or init<>() does not make a difference in my
case. To use init<>() on th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #7 from Jonas Wielicki 2012-05-24 14:32:37 UTC ---
Interestingly, I am using no_init too, but without supplying an alternative
constructor. I am not at the testing machine right now, but I thought I'd share
that bit of information. Tes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
Neal Becker changed:
What|Removed |Added
CC||ndbecker2 at gmail dot com
--- Comment #6 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
--- Comment #5 from Niall Douglas 2012-05-22
19:51:04 UTC ---
Link to the c++-sig discussion thread:
http://mail.python.org/pipermail/cplusplus-sig/2012-May/016581.html
For the purposes of assigning tags, this bug is C++11 mode only, GCC 4.7.x
o
21 matches
Mail list logo
