The optional library has a number of new failures now. I see a checkin to boost/optional/optional.hpp, made by Fernando Cacciola: revision 1.9.2.4 date: 02/03/07 02:08; author: fcacciola none_t/none reimplemented to avoid precompiled header issues (thanks to Joe Gottam) optional<T> now has direct relational operator optional<T>::operator-> fixed for reference types With the following on-list commentary: I just commited the fix to RC_1_34_0, just right on time before the code freeze tonight. I'm concerned about two things: 1. The "code freeze" mentioned above is "complete dead freeze", and it was agreed on this list that all commits, even before this dead freeze, would be posted to the list for approval. I wonder if this agreement was not clearly communicated? 2. Apparently, the change broke something, including mainstream compilers such as gcc-4.1. We're now in a dead freeze. Fernando, what do you think we can do at this point? - Volodya
Vladimir Prus wrote:
The optional library has a number of new failures now. I see a checkin to boost/optional/optional.hpp, made by Fernando Cacciola:
Thanks for investigating.
2. Apparently, the change broke something, including mainstream compilers such as gcc-4.1. We're now in a dead freeze. Fernando, what do you think we can do at this point?
Either this gets fixed by tonight, or we'll have to back out the change. Thomas -- Thomas Witt witt@acm.org
Thomas Witt wrote:
Vladimir Prus wrote:
The optional library has a number of new failures now. I see a checkin to boost/optional/optional.hpp, made by Fernando Cacciola:
Thanks for investigating.
OK, my fault, I certainly misundersood that _before_ the freeze commits needed approval. But then of course they all seemed very simple changes, and my local tests all passed.
2. Apparently, the change broke something, including mainstream compilers such as gcc-4.1. We're now in a dead freeze. Fernando, what do you think we can do at this point?
The new regressions corresponding to "optional_test_ref_fail2" shouldn't be there at all. This test has been removed from the jamfile (that was part of the commit) Why are they still there? But the new regressions corresponding to Darwin 4.01, hp_cxx_71_006_tru64 and hp_cxx_65_042_teu64 are puzzling me. I can't relate the error with my changes because this problem have been shown by other gcc's for a while, so I don't understand why it is a -new- regression? I knew about it before my changes. I've been meaning to fix them but I need a gcc, for which I need a linux box, and I didn't have one at hand. But how come my changes caused even more of these failures now, in new compilers, I can't tell. The same failure on other gcc's where showing even before my changes. Anyway, I've spent most of yesterday and today working on this, but got nowere. I don't have MSVC 60 nor 7.0, but I have 7.1. After I figured how to test against a VC7.1 in a machine that has VC80 as well (it took me a while), I only discovered that it doesn't fail there. So I tried cygwin, which has gcc 3.4.4. It also took me a lot of time to be able to use it (from having to build bjam from scratch onward). But then gain, it doesn't fail there. So finally I installed a linux box on a windows XP machine (from extending the partition onward). I just finished doing that (and installing boost to start testing it), but I haven't finish fixing the gcc failures (which are the most important IMO).
Either this gets fixed by tonight, or we'll have to back out the
OK. What's tonight exacly in UTC time? Best Fernando Cacciola
Fernando, Fernando Cacciola wrote:
Thomas Witt wrote:
Either this gets fixed by tonight, or we'll have to back out the
OK. What's tonight exacly in UTC time?
What do you want it to be? Seriously, I am willing to cut you a little more slack when I know that you are actively working on this and you think you have a chance fixing it. That being said we are talking (very) low single digit days here. Thanks Thomas -- Thomas Witt witt@acm.org
Thomas Witt wrote:
Fernando,
Fernando Cacciola wrote:
Thomas Witt wrote:
Either this gets fixed by tonight, or we'll have to back out the
OK. What's tonight exacly in UTC time?
What do you want it to be? Seriously, I am willing to cut you a little more slack when I know that you are actively working on this and you think you have a chance fixing it. That being said we are talking (very) low single digit days here.
OK. Now it's 8:20 pm local time here, and it's my turn to take care of the kids ;) I drop them at school (kinder actually) at 8:10am, so 8:30 I'm back and right in front of the PC ready to get started. How about I report on the status tomorrow noon? (my time, UTC-3) Now that I have a linux box to play with, I expect to make some progress. Best, and sorry for the mess. Fernando
Thanks
Thomas
Thomas Witt wrote:
Fernando,
Fernando Cacciola wrote:
How about I report on the status tomorrow noon? (my time, UTC-3)
OK. Comming up with a fix was quite easy, specially given that, a I said, this was a known problem and I had the fix waiting to be applied (but needed a linux box to test it). I still don't understand why it showed up after my lastest changes Anyway, here's the diff: 79,91d78 < // Daniel Wallin discovered that bind/apply.hpp badly interacts with the apply<> < // member template of a factory as used in the optional<> implementation. < // He proposed this simple fix which is to move the call to apply<> outside < // namespace boost. < namespace boost_optional_detail < { < template <class T, class Factory> < void construct(Factory const& factory, void* address) < { < factory.BOOST_NESTED_TEMPLATE apply<T>(address); < } < } < 325c312 < boost_optional_detail::construct<value_type>(factory, m_storage.address()); ---
factory.BOOST_NESTED_TEMPLATE apply<value_type>(m_storage.address()) ;
Unfortunately, I couldn't test it on gcc. I got stuck pretty much all morning on this error: gcc.link ../../../bin.v2/libs/optional/test/optional_test.test/gcc-4.0.2 Copyright/debug/optional_test /usr/lib/libc_nonshared.a(elf-init.oS)(.text.__i686.get_pc_thunk.bx+0x0): In function `__i686.get_pc_thunk.bx': : multiple definition of `__i686.get_pc_thunk.bx' ../../../bin.v2/libs/optional/test/optional_test.test/gcc-4.0.2 Copyright/debug/optional_test.o(.gnu.linkonce.t.__i686.get_pc_thunk.bx+0x0):/usr/include/c++/3.3/new:94: first defined here collect2: ld returned 1 exit status "g++" -o "../../../bin.v2/libs/optional/test/optional_test.test/gcc-4.0.2 Copyright/debug/optional_test" -Wl,--start-group "../../../bin.v2/libs/optional/test/optional_test.test/gcc-4.0.2 Copyright/debug/optional_test.o" -Wl,--end-group -g ...failed gcc.link ../../../bin.v2/libs/optional/test/optional_test.test/gcc-4.0.2 Googling indicates that I have my gcc installation messed up, but couldn't fix it yet. So, can anyone tried the patch on gcc? It works here on VC80 and VC7.1. Best Fernando Cacciola
Fernando Cacciola wrote:
Anyway, here's the diff: ..> 79,91d78 < // Daniel Wallin discovered that bind/apply.hpp badly interacts with the apply<> < // member template of a factory as used in the optional<> implementation. < // He proposed this simple fix which is to move the call to apply<> outside < // namespace boost. < namespace boost_optional_detail < { < template <class T, class Factory> < void construct(Factory const& factory, void* address) < { < factory.BOOST_NESTED_TEMPLATE apply<T>(address); < } < } < 325c312 < boost_optional_detail::construct<value_type>(factory, m_storage.address()); ---
factory.BOOST_NESTED_TEMPLATE apply<value_type>(m_storage.address()) ;
Unfortunately, I couldn't test it on gcc. .... Googling indicates that I have my gcc installation messed up, but couldn't fix it yet.
So, can anyone tried the patch on gcc? It works here on VC80 and VC7.1.
If you post your patch as attachment (so that lines are not wrapped) and preferrably in unified diff format (cvs diff -u), I can test with my gcc. - Volodya
Fernando Cacciola wrote:
Anyway, here's the diff:
I attached it here, as unified diff. <off-topic> Just bear with me... That my changes broke the release just now and that I still couldn't tested it on gcc doesn't surprise me: for the last two months problems are trying to set a new record on me. For once I haven't got paid yet. The person that usually do that, by the 1st or 2nd every month, apparently went out of town, but forgot to send me the money. Two months ago I made a silly (from my POV) mistake with one of my credit cards, but which resulted in the bank cancelling the CC and withdrawing at once all debt, including future debt from future payments, and, to compensate mistake by mistake, even some additional money, more than I actually owed. I spent 20 days shouting everyone out in the bank to get the excedent back, which I finally got last week. But that's not all. I'm moving to a bigger house, and 24 days ago I put some money to "reserve" it, money that is due 30 days later (that's 6 days from now). Then I called my accountant to have the paperwork ready for the new morgage, but then he said he couldn't do that because of some delay on behalf of the tax office (the big burocratic engine called goverment). Yet he have been telling me, since mid last year, that he will have them ready right on request (and he have been charging me for that month after month). As of today, I'm still waiting for that paperwork. And not to mention that on March 1st I got yet another code freeze for another project. </off-topic> Fernando begin 666 optional.hpp.diff M+2TM(&]P=&EO;F%L7V]L9"YH<' )5&AU($UA<B P,2 R,#HP,CHT-R R,# W M#0HK*RL@;W!T:6]N86PN:'!P"5=E9"!-87(@,#<@,3,Z,C@Z,#8@,C P-PT* M0$ @+3<V+#8@*S<V+#$Y($! #0H@(V1E9FEN92!"3T]35%]/4%1)3TY!3%]7 M14%+7T]615),3T%$7U)%4T],551)3TX-"B C96YD:68-"B -"BLO+R!$86YI M96P@5V%L;&EN(&1I<V-O=F5R960@=&AA="!B:6YD+V%P<&QY+FAP<"!B861L M>2!I;G1E<F%C=',@=VET:"!T:&4@87!P;'D\/@T**R\O(&UE;6)E<B!T96UP M;&%T92!O9B!A(&9A8W1O<GD@87,@=7-E9"!I;B!T:&4@;W!T:6]N86P\/B!I M;7!L96UE;G1A=&EO;BX-"BLO+R!(92!P<F]P;W-E9"!T:&ES('-I;7!L92!F M:7@@=VAI8V@@:7,@=&\@;6]V92!T:&4@8V%L;"!T;R!A<'!L>3P^(&]U='-I M9&4-"BLO+R!N86UE<W!A8V4@8F]O<W0N#0HK;F%M97-P86-E(&)O;W-T7V]P M=&EO;F%L7V1E=&%I; T**WL-"BL@('1E;7!L871E(#QC;&%S<R!4+"!C;&%S M<R!&86-T;W)Y/@T**R @=F]I9"!C;VYS=')U8W0H1F%C=&]R>2!C;VYS="8@ M9F%C=&]R>2P@=F]I9"H@861D<F5S<RD-"BL@('L-"BL@(" @9F%C=&]R>2Y" M3T]35%].15-4141?5$5-4$Q!5$4@87!P;'D\5#XH861D<F5S<RD[#0HK("!] M#0HK?0T**PT*( T*(&YA;65S<&%C92!B;V]S="![#0H@#0I 0" M,S Y+#<@ M*S,R,BPW($! #0H@(" @('9O:60@8V]N<W1R=6-T("@@17AP<B!C;VYS="8@ M9F%C=&]R>2P@:6Y?<&QA8V5?9F%C=&]R>5]B87-E(&-O;G-T*B I#0H@(" @ M("![#0H@(" @(" @($)/3U-47U-4051)0U]!4U-%4E0@*" Z.F)O;W-T.CIM M<&PZ.FYO=%\\:7-?<F5F97)E;F-E7W!R961I8V%T93XZ.G9A;'5E("D@.PT* M+2 @(" @("!F86-T;W)Y+D)/3U-47TY%4U1%1%]414U03$%412!A<'!L>3QV M86QU95]T>7!E/BAM7W-T;W)A9V4N861D<F5S<R@I*2 [#0HK(" @(" @(&)O M;W-T7V]P=&EO;F%L7V1E=&%I;#HZ8V]N<W1R=6-T/'9A;'5E7W1Y<&4^*&9A M8W1O<GDL(&U?<W1O<F%G92YA9&1R97-S*"DI.PT*(" @(" @("!M7VEN:71I =86QI>F5D(#T@=')U92 [#0H@(" @("!]#0H@#0H` ` end
Vladimir Prus wrote:
Fernando Cacciola wrote:
Fernando Cacciola wrote:
Anyway, here's the diff:
I attached it here, as unified diff.
I can confirm this patch make optional_test pass with gcc 4.0.3 on Kubuntu, whereas it was previously failing.
Thomas, can this patch be applied?
Please go ahead. Thanks Thomas
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Thomas Witt witt@acm.org
Thomas Witt wrote:
Vladimir Prus wrote:
Fernando Cacciola wrote:
Fernando Cacciola wrote:
Anyway, here's the diff:
I attached it here, as unified diff.
I can confirm this patch make optional_test pass with gcc 4.0.3 on Kubuntu, whereas it was previously failing.
Thomas, can this patch be applied?
Please go ahead.
Done. Thanks Fernando
participants (3)
-
Fernando Cacciola -
Thomas Witt -
Vladimir Prus