[Bug libstdc++/31836] New: FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[Bug libstdc++/31836] New: FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[danglin at gcc dot gnu dot org]

Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v
3/src -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/g
nu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-4.3.0/hppa64-hp
-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/include
-i
system /opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/sys-include -g -O2
-D_GLIBCX
X_ASSERT -ffunction-sections -fdata-sections -fmessage-length=0 -g -O2
-DLOCALED
IR="." -nostdinc++
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/inclu
de/hppa64-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/i
nclude -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-
v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/test/gnu/gc
c/gcc/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/12.c
c    -include bits/stdc++.h ./libtestc++.a  -lm   -o ./12.exe    (timeout =
600)
PASS: 27_io/basic_istream/extractors_arithmetic/char/12.cc (test for excess
erro
rs)
Setting LD_LIBRARY_PATH to
:/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa64
-hp-hpux11.11/./libstdc++-v3/src/.libs::/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/o
bjdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs
Assertion failed: is.fail(), file
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io
/basic_istream/extractors_arithmetic/char/12.cc, line 57
FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
extra_tool_flags are:
  -include bits/stdc++.h


-- 
           Summary: FAIL:
                    27_io/basic_istream/extractors_arithmetic/char/12.cc
                    execution test
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #1 from pcarlini at suse dot de  2007-05-05 21:11 -------
Hi Dave. This one and the next one are the very same issue, caused by my fix
for libstdc++/31117.
I would ask you to help me with config/locale/generic/c_locale.cc on hppa. I
would ask you first to check separately the various tests in 12.cc and see
which one is failing, float, double, long double or all of them (I expect
integers to be all fine). I think float is the most tricky to get right. If I
remember correctly, for float, in c_locale.cc hppa ends up using the check:

        if (fabs(__d) > numeric_limits<float>::max())
        __f = __builtin_huge_valf();

on the d:

       double __d = strtod(__s, &__sanity);

and therefore you should check that why a very large __s doesn't lead to a __d
which doesn't pass the check above. More generally, you should tell me whether
hppa behave as expected wrt the various __builtin_huge_val* builtins: the
various strtof, strtod, strtold, sscanf should return floating point values up
to __FLT_MAX__, __DBL_MAX__, __LDBL_MAX__, or, +INF, which should be the same
as __builtin_huge_valf(), __builtin_huge_val(), respectively,
__builtin_huge_vall() and should compare bigger.  


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-05-05 21:11:02
               date|                            |
            Summary|FAIL:                       |[4.3 Regression] FAIL:
                   |27_io/basic_istream/extracto|27_io/basic_istream/extracto
                   |rs_arithmetic/char/12.cc    |rs_arithmetic/char/12.cc
                   |execution test              |execution test


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #2 from pcarlini at suse dot de  2007-05-05 21:12 -------
*** Bug 31837 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #3 from pcarlini at suse dot de  2007-05-05 21:38 -------
Humm, unfortunately it can be that __FLT_HAS_INFINITY__, __DBL_HAS_INFINITY__,
__LDBL_HAS_INFINITY__ are false... Maybe you should check that first. In that
case we should call back the code pre-libstdc++/31117 on such targets.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #4 from pcarlini at suse dot de  2007-05-05 22:56 -------
Created an attachment (id=13514)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13514&action=view)
Draft

For this last issue (which we have to tackle anyway, irrespective of this
specific hppa regression) I have this draft. I would ask you to test it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca  2007-05-05 23:02 -------
Subject: Re:  [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

> For this last issue (which we have to tackle anyway, irrespective of this
> specific hppa regression) I have this draft. I would ask you to test it.

Will do.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2007-05-06 04:00 -------
Subject: Re:  [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

> I would ask you to help me with config/locale/generic/c_locale.cc on hppa. I
> would ask you first to check separately the various tests in 12.cc and see
> which one is failing, float, double, long double or all of them (I expect
> integers to be all fine). I think float is the most tricky to get right.

Unmodified, 12.cc fails here:

Breakpoint 1, bool test12_aux<short>(bool) (integer_type=true)
    at
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/12.cc:54
54        VERIFY( is.fail() );
(gdb) bt
#0  bool test12_aux<short>(bool) (integer_type=true)
    at
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/12.cc:54
#1  0x00005460 in test12() ()
    at
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/12.cc:61

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca  2007-05-06 04:02 -------
Subject: Re:  [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

> For this last issue (which we have to tackle anyway, irrespective of this
> specific hppa regression) I have this draft. I would ask you to test it.

Doesn't resolve hppa-hpux specific regression.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|pcarlini at suse dot de     |unassigned at gcc dot gnu
                   |                            |dot org
             Status|ASSIGNED                    |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #8 from pcarlini at suse dot de  2007-05-06 10:16 -------
(In reply to comment #6)
> Unmodified, 12.cc fails here:
> 
> Breakpoint 1, bool test12_aux<short>(bool) (integer_type=true)

Nothing changed in the library code for integers, lately, and, moreover, as far
as I can see, the test started failing exactly around 2007-04-06, when I
changed that code involved only with floats. Moreover, for integers, there is
nothing target-specific in the library, and the other targets (hppa-linux
included) are fine. I'm going to commit my changes, which are needed, anyway,
but, missing additional info, I cannot do more, I have absolutely no clues.
Maybe it's just a miscompilation, you should try to compile both library and
testcase at lower optimization level, as a first check.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #9 from pcarlini at suse dot de  2007-05-06 10:29 -------
By the way, I think it would be interesting for anyone working in this area to
know answers for at least some of my questions, e.g., whether hppa-hpux defines
__FLT_HAS_INFINITY__ to 1...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[paolo at gcc dot gnu dot org]

------- Comment #10 from paolo at gcc dot gnu dot org  2007-05-06 12:51 -------
Subject: Bug 31836

Author: paolo
Date: Sun May  6 11:51:23 2007
New Revision: 124472

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124472
Log:
2007-05-06  Paolo Carlini  <pcarlini@suse.de>

        PR libstdc++/31836
        * testsuite/17_intro/headers/c++200x/all.cc: Protect inclusion
        of C99 headers.
        * testsuite/17_intro/headers/c++200x/all_multiple_inclusion.cc:
        Likewise.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/all.cc
   
trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_multiple_inclusion.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #11 from pcarlini at suse dot de  2007-05-06 12:55 -------
Sorry about the wrong PR number in my last commit.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca  2007-05-06 22:35 -------
Subject: Re:  [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

> ------- Comment #9 from pcarlini at suse dot de  2007-05-06 10:29 -------
> By the way, I think it would be interesting for anyone working in this area to
> know answers for at least some of my questions, e.g., whether hppa-hpux defines
> __FLT_HAS_INFINITY__ to 1...

Yes.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca  2007-05-06 23:07 -------
Subject: Re:  [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

> ------- Comment #8 from pcarlini at suse dot de  2007-05-06 10:16 -------
> (In reply to comment #6)
> > Unmodified, 12.cc fails here:
> > 
> > Breakpoint 1, bool test12_aux<short>(bool) (integer_type=true)
> 
> Nothing changed in the library code for integers, lately, and, moreover, as far
> as I can see, the test started failing exactly around 2007-04-06, when I
> changed that code involved only with floats. Moreover, for integers, there is
> nothing target-specific in the library, and the other targets (hppa-linux
> included) are fine. I'm going to commit my changes, which are needed, anyway,
> but, missing additional info, I cannot do more, I have absolutely no clues.
> Maybe it's just a miscompilation, you should try to compile both library and
> testcase at lower optimization level, as a first check.

Looking at the testresults, 123629 was ok and 123662 has the failure.
There's only one libstdc++ change in this interval:

        PR libstdc++/31117
        * config/locale/gnu/c_locale.cc (__convert_to_v): Do not use errno,
        just check that the value is finite.
        * config/locale/generic/c_locale.cc (__convert_to_v): Likewise.

Other than that, there's just r123630.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #14 from pcarlini at suse dot de  2007-05-06 23:59 -------
(In reply to comment #13)
> Looking at the testresults, 123629 was ok and 123662 has the failure.
> There's only one libstdc++ change in this interval:
> 
>         PR libstdc++/31117

I told you that at the beginning of this thread, right? Then, you reported that
the portion of 12.cc about *short* type is failing, and that has nothing to do
with that change, doesn't make any sense frankly. Therefore, either something
changed in the memory layout, a latent miscompilation is triggered, or
something else, definitely, nothing I can fix with the info I have from you.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca  2007-05-07 00:51 -------
Subject: Re:  [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

> I told you that at the beginning of this thread, right? Then, you reported that
> the portion of 12.cc about *short* type is failing, and that has nothing to do
> with that change, doesn't make any sense frankly. Therefore, either something
> changed in the memory layout, a latent miscompilation is triggered, or
> something else, definitely, nothing I can fix with the info I have from you.

I understand that.  There's only two changes in the interval that are
significant (r123630 and r123635 -- r123636 was reverted).  If it's
a latent miscompilation, I still want to know which change exposed
the problem.

The test is failing on both 32 and 64-bit hpux, but not
on linux.  The code generated for the linux target is generally
very similar to 32-bit hpux target and usually miscompilations
appear on both.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #16 from pcarlini at suse dot de  2007-05-07 01:02 -------
Ok. I would suggest doing the basic checks, e.g.: build and install the library
itself -O0 and then compile the testcase too -O0; comment out everything in the
main of testcase 12.cc except the line VERIFY(test12_aux<short>(true));
"un-templatize" test12_aux, make of it a normal function on short or any other
type... Try by all means to figure out how and where the testcase is failing
for integer types, because, I repeat, my changes for 31117 are completely
unrelated to the code parsing integer types.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[amylaar at gcc dot gnu dot org]

------- Comment #17 from amylaar at gcc dot gnu dot org  2007-05-11 17:36 -------
(In reply to comment #4)
> Created an attachment (id=13514)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13514&action=view) [edit]
> Draft
> 
> For this last issue (which we have to tackle anyway, irrespective of this
> specific hppa regression) I have this draft. I would ask you to test it.
> 

Using a compiler based on gcc version 4.2.0 20070317 (prerelease),
i686-pc-linux-gnu X arc-elf32, I see execution failures for 
27_io/basic_istream/extractors_arithmetic/char/12.c .
Using some printf (actually, std::cerr) debugging, I've found that
the failure occurs for the float conversion, and the value of t is inf.

Applying the patch from PR31117 and your patch from the attachement
referenced above fixes the problem.


-- 

amylaar at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amylaar at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #18 from pcarlini at suse dot de  2007-05-11 18:28 -------
(In reply to comment #17)
> Using a compiler based on gcc version 4.2.0 20070317 (prerelease),
> i686-pc-linux-gnu X arc-elf32, I see execution failures for 
> 27_io/basic_istream/extractors_arithmetic/char/12.c .
> Using some printf (actually, std::cerr) debugging, I've found that
> the failure occurs for the float conversion, and the value of t is inf.
> 
> Applying the patch from PR31117 and your patch from the attachement
> referenced above fixes the problem.

That's interesting, slightly unexpected. For, the patch attached here (which I
have applied in mainline, in the meanwhile), was only meant to fix, in mainline
again, possible issues caused by the fix for PR31117. In short, in order to
solve 31117, we are doing our best to avoid errno, but that cannot be done
safely when the target doesn't have infinities. Therefore, I would ask you to
untangle a bit this thing... Apparently, for some reason, for your target onte
of the checks (which one? !finitef? !finite?) is not working, instead the final
f != __builtin_huge_valf() catches it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca  2007-05-11 18:32 -------
Subject: Re:  [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

> Using some printf (actually, std::cerr) debugging, I've found that
> the failure occurs for the float conversion, and the value of t is inf.

In the hppa64-hp-hpux11.11 case, I determined last night that the failure
just occurs in the long double case.

I need to recheck what's happening on hppa2.0.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #20 from pcarlini at suse dot de  2007-05-11 19:02 -------
(In reply to comment #19)
> Subject: Re:  [4.3 Regression] FAIL:
> 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
> 
> > Using some printf (actually, std::cerr) debugging, I've found that
> > the failure occurs for the float conversion, and the value of t is inf.
> 
> In the hppa64-hp-hpux11.11 case, I determined last night that the failure
> just occurs in the long double case.

Ah, ok, that makes more sense. Therefore integer types are ok. For long double,
which code do we have on hppa? _GLIBCXX_HAVE_STRTOLD is defined or not?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #21 from pcarlini at suse dot de  2007-05-11 19:03 -------
And of course please check also whether __LDBL_HAS_INFINITY__ is 1 or 0.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #22 from pcarlini at suse dot de  2007-05-11 19:17 -------
An additional remark on hppa: a *theoretical* possibility is that on hppa
strtold (or sscanf), even if infinities are available, doesn't return an
infinity in case of input overflow. As far as I know, that is strictly mandated
only in C99. In that case, we could strengthen the check on
__LDBL_HAS_INFINITY__ to one on _GLIBCXX_USE_C99, for example.


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pcarlini at suse dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #23 from dave at hiauly1 dot hia dot nrc dot ca  2007-05-11 23:37 -------
Subject: Re:  [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

> ------- Comment #21 from pcarlini at suse dot de  2007-05-11 19:03 -------
> And of course please check also whether __LDBL_HAS_INFINITY__ is 1 or 0.

hppa2.0w-hp-hpux11.11: it's 1.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #24 from dave at hiauly1 dot hia dot nrc dot ca  2007-05-12 01:22 -------
Subject: Re:  [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

> which code do we have on hppa? _GLIBCXX_HAVE_STRTOLD is defined or not?

It's defined.

The 11.11 man page indicates that single-byte character code sets
are supported.  It also states that this function is "to be obsoleted
at a future date."

The code is:

  char* __sanity;
  long double __ld = strtold(__s, &__sanity);
  if (__sanity != __s
      && __ld != __builtin_huge_vall() && __ld != -__builtin_huge_vall())
    __v = __ld;

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #25 from pcarlini at suse dot de  2007-05-12 01:51 -------
(In reply to comment #24)
> It's defined.

Ok, thanks.

> The 11.11 man page indicates that single-byte character code sets
> are supported.  It also states that this function is "to be obsoleted
> at a future date."

Well, that seems weird, to say the least, because strtold is new in C99!
Probably, the problem here is that in this libc a version of strtold pre-dates
the C99 standard (therefore in those docs, definitely before the final C99
standard, was even expected to not last much!) and, as such, doesn't implement
the actual C99 semantics, which would mean returning __builtin_huge_vall() in
case of overflow (C99, 7.20.1.3/10) and everything would perfectly work.

Certainly, we can fix this issue, one way or another, we could even add a
AC_TRY_RUN configure test, exercising the function in this conditions. I'll
give the issue more thought, feel free to suggest something, of course...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #26 from pcarlini at suse dot de  2007-05-12 02:01 -------
More simply, we could define a macro in config/os/hpux/os_defines.h like:
#define _GLIBCXX_HAVE_BROKEN_STRTOLD 1
to inform the library to avoid strtold, checked in clocale.cc. If you find this
reasonable, could you suggest an appropriate way to enable it only for hppa? Or
hppa + hppa64? Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #27 from dave at hiauly1 dot hia dot nrc dot ca  2007-05-12 02:23 -------
Subject: Re:  [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

> An additional remark on hppa: a *theoretical* possibility is that on hppa
> strtold (or sscanf), even if infinities are available, doesn't return an
> infinity in case of input overflow. As far as I know, that is strictly mandated
> only in C99. In that case, we could strengthen the check on
> __LDBL_HAS_INFINITY__ to one on _GLIBCXX_USE_C99, for example.

That's it.  From the manpage:

      If the correct value would cause overflow, positive _LDBL_MAX or
      negative _LDBL_NMAX is returned (according to the sign of the value),
      and errno is set to ERANGE.  The __LDBL_MAX and __LDBL_NMAX macros are
      provided to assist in checking the return values against _LDBL_MAX and
      _LDBL_NMAX.

      If the correct value would cause underflow, _ZERO is returned and
      errno is set to ERANGE.

So, I guess we have to check errno.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #28 from dave at hiauly1 dot hia dot nrc dot ca  2007-05-12 02:36 -------
Subject: Re:  [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

> > The 11.11 man page indicates that single-byte character code sets
> > are supported.  It also states that this function is "to be obsoleted
> > at a future date."
> 
> Well, that seems weird, to say the least, because strtold is new in C99!

Agreed.

sscanf appears to have better locale support.  However, the manpage doesn't
indicate what happens on overflow/underflow (i.e., there's no indication
that errno is ever set to ERANGE).

> Probably, the problem here is that in this libc a version of strtold pre-dates
> the C99 standard (therefore in those docs, definitely before the final C99
> standard, was even expected to not last much!) and, as such, doesn't implement
> the actual C99 semantics, which would mean returning __builtin_huge_vall() in
> case of overflow (C99, 7.20.1.3/10) and everything would perfectly work.
> 
> Certainly, we can fix this issue, one way or another, we could even add a
> AC_TRY_RUN configure test, exercising the function in this conditions. I'll
> give the issue more thought, feel free to suggest something, of course...

Yes, 11.11 is old now.  The behavior on 11.23 or 11.31 may be different,
so a configure check is probably a good idea.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #29 from pcarlini at suse dot de  2007-05-12 19:17 -------
Ok, Dave, thanks for the details. Let's go for a configure check, I'll work on
it.


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
                   |dot org                     |
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #30 from dave at hiauly1 dot hia dot nrc dot ca  2007-05-12 19:54 -------
Subject: Re:  [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

> Ok, Dave, thanks for the details. Let's go for a configure check, I'll work on
> it.

At the moment, I'm investigating a fix along the lines suggested in
comment #26.  The implementation of strtold in HP-UX 11.11 and earlier
is broken in at least four ways:

1) Return of plus or minus _LDBL_MAX instead of HUGE_VALL if correct
   value would cause overflow,
2) locale support is worse than for sscanf,
3) it is listed by HP as not being thread safe,
4) it doesn't support "inf", "infinite" and "nan" conversions.

As a result of 1, we would have to check errno if we are going to
use strtold.  This is likely not thread safe.  Thus, it looks better
to use sscanf.  I checked.  It returns 0 if the result would cause
overflow.  Is there any reason not to sscanf other than performance?

I sent mail to Steve Ellcey asking him to check the behavior of
strtold in HP-UX 11.23 and 11.31.  If there aren't good technical
reasons to favor strtold over sscanf, I think we had best go for
consistency on all versions of HP-UX.  In that case, we wouldn't
need the configure check.

I see that at one time we used _GLIBCXX_USE_C99 instead of
_GLIBCXX_HAVE_STRTOLD.  However, this caused a problem on mips.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #31 from pcarlini at suse dot de  2007-05-12 20:26 -------
(In reply to comment #30)
> At the moment, I'm investigating a fix along the lines suggested in
> comment #26.  The implementation of strtold in HP-UX 11.11 and earlier
> is broken in at least four ways:
> 
> 1) Return of plus or minus _LDBL_MAX instead of HUGE_VALL if correct
>    value would cause overflow,
> 2) locale support is worse than for sscanf,
> 3) it is listed by HP as not being thread safe,
> 4) it doesn't support "inf", "infinite" and "nan" conversions.
> 
> As a result of 1, we would have to check errno if we are going to
> use strtold.  This is likely not thread safe.  Thus, it looks better
> to use sscanf.  I checked.  It returns 0 if the result would cause
> overflow.  Is there any reason not to sscanf other than performance?

Indeed, I was also considering this kind of solution. Excellent.

> I sent mail to Steve Ellcey asking him to check the behavior of
> strtold in HP-UX 11.23 and 11.31.  If there aren't good technical
> reasons to favor strtold over sscanf, I think we had best go for
> consistency on all versions of HP-UX.  In that case, we wouldn't
> need the configure check.

Fine. Actually, it would have to be an AC_TRY_RUN (we are trying to keep those
to a minimum), and I'm just learning to you would have to be rather complex, to
be safe. Then, how would we deal with the issue, in practice? 
_GLIBCXX_HAVE_STRTOLD would still be true on HP-UX, because the function is in
any case available at compile time. By way of the _GLIBCXX_HAVE_BROKEN_STRTOLD
which I mentioned before? Like:

#if defined(_GLIBCXX_HAVE_STRTOLD) && !defined(_GLIBCXX_HAVE_BROKEN_STRTOLD)

> I see that at one time we used _GLIBCXX_USE_C99 instead of
> _GLIBCXX_HAVE_STRTOLD.  However, this caused a problem on mips.

I was also considering this option too ;) Too bad we had such kind of problem
on mips, because, in principle, it also looks like a conservative solution:
that macro results only from TRY_COMPILE tests, but very extensive. I would say
it's very-very unlikely that a target passes all the _GLIBCXX_USE_C99 test
still such basic functionality of the strto* functions is missing...

Anyway, Dave, since you are working hard on the issue (thanks!), I can't
consider myself responsible for fixing the problem, for better or worse, I'm
unassigning myself from the PR, still in CC and helping of course.


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|pcarlini at suse dot de     |unassigned at gcc dot gnu
                   |                            |dot org
             Status|ASSIGNED                    |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[amylaar at spamcop dot net]

------- Comment #32 from amylaar at spamcop dot net  2007-05-14 16:39 -------
Subject: Re:  [4.3 Regression] FAIL:
        27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

Quoting pcarlini at suse dot de <gcc-bugzilla@gcc.gnu.org>:

>
> safely when the target doesn't have infinities. Therefore, I would ask you to
> untangle a bit this thing... Apparently, for some reason, for your target
> onte
> of the checks (which one? !finitef? !finite?) is not working, instead the
> final
> f != __builtin_huge_valf() catches it.

These are excepts from
arc-elf32/arc700/libstdc++-v3/include/arc-elf32/bits/c++config.h:

/* Define to 1 if you have the `finitef' function. */
/* #undef _GLIBCXX_HAVE_FINITEF */
/* Define to 1 if you have the `_finitef' function. */
/* #undef _GLIBCXX_HAVE__FINITEF */
/* Define to 1 if you have the `finite' function. */
/* #undef _GLIBCXX_HAVE_FINITE */
/* Define to 1 if you have the `_finite' function. */
/* #undef _GLIBCXX_HAVE__FINITE */
/* Define to 1 if you have the `isinf' function. */
/* #undef _GLIBCXX_HAVE_ISINF */
/* Define to 1 if you have the `_isinf' function. */
/* #undef _GLIBCXX_HAVE__ISINF */

Thus, the test that should be performed in
_ZSt14__convert_to_vIfEvPKcRT_RSt12_Ios_IostateRKPi should be:

      if (fabs(__d) > numeric_limits<float>::max())
        errno = ERANGE;

Disassembly of that method shows that the test has been
optimized away.
This is not actually surprising, because _GLIBCXX_HAVE_STRTOF
has been set, and hence strtof has been used, and
__d remained uninitalized.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pcarlini at suse dot de]

------- Comment #33 from pcarlini at suse dot de  2007-05-14 16:54 -------
(In reply to comment #32)
> /* Define to 1 if you have the `finitef' function. */
> /* #undef _GLIBCXX_HAVE_FINITEF */
> /* Define to 1 if you have the `_finitef' function. */
> /* #undef _GLIBCXX_HAVE__FINITEF */
> /* Define to 1 if you have the `finite' function. */
> /* #undef _GLIBCXX_HAVE_FINITE */
> /* Define to 1 if you have the `_finite' function. */
> /* #undef _GLIBCXX_HAVE__FINITE */
> /* Define to 1 if you have the `isinf' function. */
> /* #undef _GLIBCXX_HAVE_ISINF */
> /* Define to 1 if you have the `_isinf' function. */
> /* #undef _GLIBCXX_HAVE__ISINF */

Ok, all undefined, it's possible.

> Thus, the test that should be performed in
> _ZSt14__convert_to_vIfEvPKcRT_RSt12_Ios_IostateRKPi should be:
> 
>       if (fabs(__d) > numeric_limits<float>::max())
>         errno = ERANGE;

Only *if* _GLIBCXX_HAVE_STRTOF is not defined, however.

> Disassembly of that method shows that the test has been
> optimized away.
> This is not actually surprising, because _GLIBCXX_HAVE_STRTOF
> has been set, and hence strtof has been used, and
> __d remained uninitalized.

Ok, therefore _GLIBCXX_HAVE_STRTOF is set and no further test is needed before
the final one. In this case __d isn't optimized out, simply the pre-processor
selects:

      float __f = strtof(__s, &__sanity);

instead of

      double __d = strtod(__s, &__sanity);
      float __f = static_cast<float>(__d);

Now, the strange thing is that, before these two last patches (in 4_2-branch in
other terms), errno doesn't turn out to be == ERANGE for your target: strtof
should have set it...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[amylaar at spamcop dot net]

------- Comment #34 from amylaar at spamcop dot net  2007-05-14 19:25 -------
Subject: Re:  [4.3 Regression] FAIL:
        27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

Quoting pcarlini at suse dot de <gcc-bugzilla@gcc.gnu.org>:

> Now, the strange thing is that, before these two last patches (in 4_2-branch
> in
> other terms), errno doesn't turn out to be == ERANGE for your target: strtof
> should have set it...

It's lameness in newlib.

newlib/libc/stdlib/strtod.c defines:

float
_DEFUN (strtof, (s00, se),
        _CONST char *s00 _AND
        char **se)
{
  double retval = _strtod_r (_REENT, s00, se);
  if (isnan (retval))
    return nanf (NULL);
  return (float)retval;
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
   Target Milestone|---                         |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[danglin at gcc dot gnu dot org]

------- Comment #35 from danglin at gcc dot gnu dot org  2007-07-25 15:32 -------
Subject: Bug 31836

Author: danglin
Date: Wed Jul 25 15:32:33 2007
New Revision: 126914

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126914
Log:
        PR libstdc++/31836
        * config/locale/generic/c_locale.cc (__convert_to_v): Don't use
        strtold if _GLIBCXX_HAVE_BROKEN_STRTOLD is defined.
        * config/os/hpux/os_defines.h (_GLIBCXX_HAVE_BROKEN_STRTOLD): Define
        if __hppa__ is defined.


Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/config/locale/generic/c_locale.cc
    trunk/libstdc++-v3/config/os/hpux/os_defines.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836

[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

[danglin at gcc dot gnu dot org]

------- Comment #36 from danglin at gcc dot gnu dot org  2007-07-25 15:36 -------
Fixed on hppa by change.


-- 

danglin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836