I want to be rolling prerelease tarballs by next Friday, June 10th, and hope to release 1.33.0 shortly thereafter. To get there, I need your help. We've just brought the "Unresolved issues" page back online at: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/ issues.html This reflects all of the bugs that we need fixed or accounted for before we release Boost 1.33.0. The page itself has some flaws that we are aware of (and will work on), but please verify that your libraries don't have any entries on this page. Click on the name of the library to see the full set of results for the compilers important for this release. Focus on those compilers; ask me first before making changes to accommodate other compilers. We're...almost...there. Doug
Douglas Gregor wrote:
To get there, I need your help. We've just brought the "Unresolved issues" page back online at:
I just checked in a change that should clear numeric/interval from that list. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Le jeudi 02 juin 2005 à 10:47 -0500, Rene Rivera a écrit :
Douglas Gregor wrote:
To get there, I need your help. We've just brought the "Unresolved issues" page back online at:
I just checked in a change that should clear numeric/interval from that list.
Thanks for the fix. But have you tried the fix you committed? Unfortunately I am a bit dubious it will work. I think it will just change the compiler error from Error : preprocessor #error directive ../boost/numeric/interval/hw_rounding.hpp line 34?# error Boost.Numeric.Interval: Please specify rounding control mechanism. to Error : preprocessor #error directive ../boost/numeric/interval/detail/ppc_rounding_control.hpp line 16?# error This header only works on PPC CPUs. And even if you fix this new error, the file is full of GCC asm. Does the Codewarrior compiler support the same syntax for assembly blocks? I had tried to make the library work on this compiler by enabling the C99 mode (header <fenv.h>). But unfortunately it seems the compiler does not define the __USE_ISOC99 macro. Perhaps there is another macro to express this capability, but I was unable to find it (I don't have access to this compiler). Does this compiler support <fenv.h>? Best regards, Guillaume
Guillaume Melquiond wrote:
Thanks for the fix. But have you tried the fix you committed? And even if you fix this new error, the file is full of GCC asm. Does the Codewarrior compiler support the same syntax for assembly blocks?
Sorry my bad. I did not test it as I assume since there was no compiler guard that it applied to any PPC machine. Would you mind if I add a GCC check since it has GCC asm, it should only apply then?
I had tried to make the library work on this compiler by enabling the C99 mode (header <fenv.h>). But unfortunately it seems the compiler does not define the __USE_ISOC99 macro. Perhaps there is another macro to express this capability, but I was unable to find it (I don't have access to this compiler). Does this compiler support <fenv.h>?
Don't know if it supports fenv specifically, but it does support some C99 features. You can test if it's enabled with: #if __option(c99) And you can control it with: #pragma c99 on | off | reset I'll go test this now. :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Guillaume Melquiond wrote:
I had tried to make the library work on this compiler by enabling the C99 mode (header <fenv.h>). But unfortunately it seems the compiler does not define the __USE_ISOC99 macro. Perhaps there is another macro to express this capability, but I was unable to find it (I don't have access to this compiler). Does this compiler support <fenv.h>?
Don't know if it supports fenv specifically, but it does support some C99 features.
I'll go test this now. :-)
OK looked at the code it's not C99 language features that are needed but C99 library features. MSL seems to support fenv.h in both PPC and X86, regardless of whether the C99 language features are used or not (the _option(c99) stuff). So I change the check that was their for C99 to also use that when defined(__MSL__). All the tests now pass. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Le jeudi 02 juin 2005 à 17:43 -0500, Rene Rivera a écrit :
Rene Rivera wrote:
Guillaume Melquiond wrote:
I had tried to make the library work on this compiler by enabling the C99 mode (header <fenv.h>). But unfortunately it seems the compiler does not define the __USE_ISOC99 macro. Perhaps there is another macro to express this capability, but I was unable to find it (I don't have access to this compiler). Does this compiler support <fenv.h>?
Don't know if it supports fenv specifically, but it does support some C99 features.
I'll go test this now. :-)
OK looked at the code it's not C99 language features that are needed but C99 library features. MSL seems to support fenv.h in both PPC and X86, regardless of whether the C99 language features are used or not (the _option(c99) stuff). So I change the check that was their for C99 to also use that when defined(__MSL__). All the tests now pass.
Thanks. About adding a GCC check because of the GCC asm in the PPC specific file, there is already one in fact. I had already added it, when I learned GCC was no more the only compiler to be available on PPC. I just had forgotten about it. :-) Best regards, Guillaume
http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/ issues.html
This reflects all of the bugs that we need fixed or accounted for before we release Boost 1.33.0. The page itself has some flaws that we are aware of (and will work on), but please verify that your libraries don't have any entries on this page. Click on the name of the library to see the full set of results for the compilers important for this release. Focus on those compilers; ask me first before making changes to accommodate other compilers.
The only one listed for regex is a gcc-2.95.3 internal compiler error that I don't know how to fix (see http://tinyurl.com/8g8cc ) any help appreciated: the code is so trivial it's hard to see how to simplify it any more (and believe me I've tried!). Thanks, John.
The only one listed for regex is a gcc-2.95.3 internal compiler error that I don't know how to fix (see http://tinyurl.com/8g8cc ) any help appreciated: the code is so trivial it's hard to see how to simplify it any more (and believe me I've tried!).
But not tried hard enough: should now be fixed in cvs. John.
Somewhere in the E.U., le 09/06/2005 Bonjour In article <885fb890aa899f55020969612ff1020e@cs.indiana.edu>, Douglas Gregor <doug.gregor@gmail.com> wrote:
I want to be rolling prerelease tarballs by next Friday, June 10th, and hope to release 1.33.0 shortly thereafter.
To get there, I need your help. We've just brought the "Unresolved issues" page back online at:
http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/ issues.html
This reflects all of the bugs that we need fixed or accounted for before we release Boost 1.33.0. The page itself has some flaws that we are aware of (and will work on), but please verify that your libraries don't have any entries on this page. Click on the name of the library to see the full set of results for the compilers important for this release. Focus on those compilers; ask me first before making changes to accommodate other compilers.
We're...almost...there.
Doug
As far as the math library is concerned, I guess the VC 7.0 failures can be chalked up as "expected failures". They disappear with VC 7.1 and VC 8.0. How does one proceed to do so? Merci Hubert
On Jun 9, 2005, at 6:56 AM, Hubert Holin wrote:
As far as the math library is concerned, I guess the VC 7.0 failures can be chalked up as "expected failures". They disappear with VC 7.1 and VC 8.0. How does one proceed to do so?
Add them to status/expected-failures-markup.xml. The format should be pretty obvious, but please be sure to validate the XML before checking it in, as described at the top of the file. Doug
On 6/9/05, Hubert Holin <Hubert.Holin@meteo.fr> wrote:
As far as the math library is concerned, I guess the VC 7.0 failures can be chalked up as "expected failures". They disappear with VC 7.1 and VC 8.0. How does one proceed to do so?
Look at status/expected-failures-markup.xml. I've added some expected failures for the octonion and quaternion test on gcc + Solaris in there. You can use those as a starting point. Also be sure to validate the XML against the XSD before comitting (instructions at the top of the file). -- Caleb Epstein caleb dot epstein at gmail dot com
participants (7)
-
Caleb Epstein -
Doug Gregor -
Douglas Gregor -
Guillaume Melquiond -
Hubert Holin -
John Maddock -
Rene Rivera