On 07/10/14 21:10 +0200, Andreas Schwab wrote:
That cannot work. std::__convert_from_v always passes __prec before
__v, but the format is %a.
Ah yes. I'm testing this fix now.
commit 543771e2db1642715854ae4bec81d803ca8e2e59
Author: Jonathan Wakely jwak...@redhat.com
Date: Wed Oct 8
Jonathan Wakely jwak...@redhat.com writes:
On 28/03/14 08:56 +0900, Luke Allardyce wrote:
It looks like the new standard also requires the precision to be
ignored for hexfloat
For conversion from a floating-point type, if floatfield !=
(ios_base::fixed | ios_base:: scientific), str.precision()
On 08/10/14 13:27 +0200, Rainer Orth wrote:
On Solaris 11 (both SPARC and x86), the test execution FAILs:
Assertion failed: os std::stod(os.str()) == d, file
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc,
line 51, function test01
On 08/10/14 11:07 +0100, Jonathan Wakely wrote:
On 07/10/14 21:10 +0200, Andreas Schwab wrote:
That cannot work. std::__convert_from_v always passes __prec before
__v, but the format is %a.
Ah yes. I'm testing this fix now.
Committed.
I assume it was working for me because
On 08/10/14 12:37 +0100, Jonathan Wakely wrote:
On 08/10/14 13:27 +0200, Rainer Orth wrote:
On Solaris 11 (both SPARC and x86), the test execution FAILs:
Assertion failed: os std::stod(os.str()) == d, file
Jonathan Wakely jwak...@redhat.com writes:
On 08/10/14 12:37 +0100, Jonathan Wakely wrote:
On 08/10/14 13:27 +0200, Rainer Orth wrote:
On Solaris 11 (both SPARC and x86), the test execution FAILs:
Assertion failed: os std::stod(os.str()) == d, file
On 08/10/14 16:21 +0200, Rainer Orth wrote:
I'd already tried that patch before you committed it, and unfortunately
it didn't help.
Oh dear. Did you do a clean build, or at least
'touch libstdc++-v3/src/*/*.cc' to ensure the library sources get
rebuilt? Changes to headers do not trigger
Jonathan Wakely jwak...@redhat.com writes:
On 08/10/14 16:21 +0200, Rainer Orth wrote:
I'd already tried that patch before you committed it, and unfortunately
it didn't help.
Oh dear. Did you do a clean build, or at least
'touch libstdc++-v3/src/*/*.cc' to ensure the library sources get
Jonathan Wakely jwak...@redhat.com writes:
diff --git a/libstdc++-v3/src/c++98/locale_facets.cc
b/libstdc++-v3/src/c++98/locale_facets.cc
index 3669acb..7ed04e6 100644
--- a/libstdc++-v3/src/c++98/locale_facets.cc
+++ b/libstdc++-v3/src/c++98/locale_facets.cc
@@ -69,19 +69,26 @@
On 28/03/14 08:56 +0900, Luke Allardyce wrote:
It looks like the new standard also requires the precision to be
ignored for hexfloat
For conversion from a floating-point type, if floatfield != (ios_base::fixed |
ios_base:: scientific), str.precision() is specified as precision in the
On 17 April 2014 01:56, Luke Allardyce wrote:
Thanks, I was wrong about that.
Then I think we should just bite the bullet and provide the new
behaviour. If we do have an abi_tag on those types in the next release
then we can preserve the old behaviour in the old ABI and use the
C++11
On 16/04/14 14:26 +0900, Luke Allardyce wrote:
Also the old standard seems to require that ios_base::fixed |
ios_base::scientific (or any other combination) falls through to the
uppercase test; I was trying to use abi_tag for a solution as not only
would two versions of _S_format_float be
Thanks, I was wrong about that.
Then I think we should just bite the bullet and provide the new
behaviour. If we do have an abi_tag on those types in the next release
then we can preserve the old behaviour in the old ABI and use the
C++11 semantics for the abi_tagged type, which will be used
On 27 March 2014 23:56, Luke Allardyce wrote:
It looks like the new standard also requires the precision to be
ignored for hexfloat
For conversion from a floating-point type, if floatfield != (ios_base::fixed
| ios_base:: scientific), str.precision() is specified as precision in the
Also the old standard seems to require that ios_base::fixed |
ios_base::scientific (or any other combination) falls through to the
uppercase test; I was trying to use abi_tag for a solution as not only
would two versions of _S_format_float be necessary, but also num_get
due to the
Hello Jonathan,
thanks for your comments.
N.B. patches to the ChangeLog rarely apply cleanly (because someone
else may have changed the ChangeLog since the patch was created) so
the convention is to send the ChangeLog entry in the email body, or as
a separate attachment, or by using 'git log
On 27/03/14 17:00 +0100, Rüdiger Sonderfeld wrote:
Hello Jonathan,
thanks for your comments.
N.B. patches to the ChangeLog rarely apply cleanly (because someone
else may have changed the ChangeLog since the patch was created) so
the convention is to send the ChangeLog entry in the email body,
17 matches
Mail list logo
