[Bug libstdc++/31836] [4.3 Regression] FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
--- 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=gccview=revrev=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
--- 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
[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 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
--- 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 [EMAIL PROTECTED]: 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_limitsfloat::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
--- 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_limitsfloat::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_castfloat(__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
--- 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 [EMAIL PROTECTED]:
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
--- 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
--- 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
--- 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
--- 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=13514action=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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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_auxshort(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 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
--- 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
--- 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=gccview=revrev=124472 Log: 2007-05-06 Paolo Carlini [EMAIL PROTECTED] 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
--- 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
--- 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
--- 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_auxshort(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
--- 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
--- 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
--- 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_auxshort(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
--- 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_limitsfloat::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|-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
--- 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
--- 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
--- 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=13514action=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
--- 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
--- 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_auxshort(bool) (integer_type=true) at /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/12.cc:54 54VERIFY( is.fail() ); (gdb) bt #0 bool test12_auxshort(bool) (integer_type=true) at /test/gnu/gcc/gcc/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/12.cc:54 #1 0x5460 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
--- 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
