Open p5pRT opened 5 years ago
Blead is currently failing three tests in t/op/sprintf2.t on Windows (this is Windows 10) with VC12 (x64):
Failed tests: 1512\, 1517\, 1522
VC14\, VC14.1 and MinGW-w64 GCC 7.1.0 all work fine\, all x64.
See attached verbose output.
op/sprintf2.t ..
# uvsize = 8
# nvsize = 8
# nv_preserves_uv_bits = 53
# d_quad = define
# uselongdouble = undef
ok 1 - the sprintf "%.\
Test Summary Report
op/sprintf2.t (Wstat: 0 Tests: 1696 Failed: 3) Failed tests: 1512\, 1517\, 1522 Files=1\, Tests=1696\, 3 wallclock secs ( 0.06 usr + 0.02 sys = 0.08 CPU) Result: FAIL
Can you determine whether these problem values are being assigned correctly in the first place ? I would guess that's where the problem lies.
If $Config{d_strtod} is defined\, then the values are being assigned using C's strtod(). If you wish to use perl's Atof to assign the values\, just re-build perl with $Config{d_strtod} undefined. (Edit the 'd_strtod' setting in Win32/ config.vc and the 'HAS_STRTOD' setting in Win32/config_H.vc).
On Thu\, Apr 4\, 2019 at 4:02 AM Steve Hay (via RT) \perlbug\-followup@​perl\.org wrote:
# New Ticket Created by Steve Hay # Please include the string: [perl #133982] # in the subject line of all future correspondence about this issue. # \<URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133982 >
This is a bug report for perl from steve.m.hay@googlemail.com\, generated with the help of perlbug 1.41 running under perl 5.29.10.
----------------------------------------------------------------- [Please describe your issue here]
Blead is currently failing three tests in t/op/sprintf2.t on Windows (this is Windows 10) with VC12 (x64):
Failed tests: 1512\, 1517\, 1522
VC14\, VC14.1 and MinGW-w64 GCC 7.1.0 all work fine\, all x64.
See attached verbose output.
[Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=medium --- Site configuration information for perl 5.29.10:
Configured by shay at Wed Apr 3 08:46:38 2019.
Summary of my perl5 (revision 5 version 29 subversion 10) configuration:
Platform: osname=MSWin32 osvers=10.0.17763.379 archname=MSWin32-x64-multi-thread uname='' config_args='undef' hint=recommended useposix=true d_sigaction=undef useithreads=define usemultiplicity=define use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='cl' ccflags ='-nologo -GF -W3 -O1 -MD -Zi -DNDEBUG -GL -fp:precise -DWIN32 -D_CONSOLE -DNO_STRICT -DWIN64 -DCONSERVATIVE -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS' optimize='-O1 -MD -Zi -DNDEBUG -GL -fp:precise' cppflags='-DWIN32' ccversion='18.00.40629' gccversion='' gccosandvers='' intsize=4 longsize=4 ptrsize=8 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=undef longlongsize=8 d_longdbl=define longdblsize=8 longdblkind=0 ivtype='__int64' ivsize=8 nvtype='double' nvsize=8 Off_t='__int64' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='link' ldflags ='-nologo -nodefaultlib -debug -opt:ref\,icf -ltcg -libpath:"c:\perl\lib\CORE" -machine:AMD64 -subsystem:console\,"5.02"' libpth="C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\\lib\amd64" libs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib perllibs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib libc=msvcrt.lib so=dll useshrplib=true libperl=perl529.lib gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs dlext=dll d_dlsymun=undef ccdlflags=' ' cccdlflags=' ' lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref\,icf -ltcg -libpath:"c:\perl\lib\CORE" -machine:AMD64 -subsystem:console\,"5.02"'
--- @INC for perl 5.29.10: C:/perl/site/lib C:/perl/lib
--- Environment for perl 5.29.10: HOME (unset) LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset)
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\perl\bin PERL_BADLANG (unset) SHELL (unset)
The RT System itself - Status changed from 'new' to 'open'
On Wed\, Apr 03\, 2019 at 10:00:50AM -0700\, Steve Hay (via RT) wrote:
Blead is currently failing three tests in t/op/sprintf2.t on Windows (this is Windows 10) with VC12 (x64):
Failed tests: 1512\, 1517\, 1522
VC14\, VC14.1 and MinGW-w64 GCC 7.1.0 all work fine\, all x64.
These are
sprintf "%a"\, "3e-322; # expected 0x1.e8p-1069 got 0x1.ep-1069 sprintf "%a"\, "7e-322; # expected 0x1.1cp-1067 got 0x1.1ap-1067 sprintf "%.4a"\, "3e-322; # expected 0x1.e800p-1069 got 0x1.e000p-1069
Which seems to imply the last bit of precision is being messed up. Whether that's due to the way subnormals are calculated from a string\, stored as an NV\, or processed for %a display\, I don't know.
-- More than any other time in history\, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other\, to total extinction. Let us pray we have the wisdom to choose correctly. -- Woody Allen
If we could see the output of: perl -le "print scalar reverse unpack 'h*'\, pack 'd\<'\, 7e-322;" and perl -le "print scalar reverse unpack 'h*'\, pack 'd\<'\, 3e-322;"
then we could probably deduce whether the problem is in the assigning of the value\, or elsewhere. Correct outputs are (resp): 000000000000008e and 000000000000003d
If the VC12 outputs agree with the above\, then I would believe that the values are being assigned correctly\, and the problem is with the %a processing. Otherwise\, vice-versa.
(Admittedly\, it's not impossible that we could be led astray by a bug in pack/unpack - but very unlikely\, IME.)
Cheers\, Rob
On Thu\, Apr 4\, 2019 at 8:36 PM Dave Mitchell \davem@​iabyn\.com wrote:
On Wed\, Apr 03\, 2019 at 10:00:50AM -0700\, Steve Hay (via RT) wrote:
Blead is currently failing three tests in t/op/sprintf2.t on Windows (this is Windows 10) with VC12 (x64):
Failed tests: 1512\, 1517\, 1522
VC14\, VC14.1 and MinGW-w64 GCC 7.1.0 all work fine\, all x64.
These are
sprintf "%a"\, "3e-322; # expected 0x1.e8p-1069 got 0x1.ep-1069 sprintf "%a"\, "7e-322; # expected 0x1.1cp-1067 got 0x1.1ap-1067 sprintf "%.4a"\, "3e-322; # expected 0x1.e800p-1069 got 0x1.e000p-1069
Which seems to imply the last bit of precision is being messed up. Whether that's due to the way subnormals are calculated from a string\, stored as an NV\, or processed for %a display\, I don't know.
-- More than any other time in history\, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other\, to total extinction. Let us pray we have the wisdom to choose correctly. -- Woody Allen
The outputs are not correct:
.\perl -le "print scalar reverse unpack 'h*'\, pack 'd\<'\, 7e-322;" 000000000000008d
perl -le "print scalar reverse unpack 'h*'\, pack 'd\<'\, 3e-322;" 000000000000003c
On Thu\, 4 Apr 2019 at 11:12\, sisyphus \sisyphus359@​gmail\.com wrote:
If we could see the output of: perl -le "print scalar reverse unpack 'h*'\, pack 'd\<'\, 7e-322;" and perl -le "print scalar reverse unpack 'h*'\, pack 'd\<'\, 3e-322;"
then we could probably deduce whether the problem is in the assigning of the value\, or elsewhere. Correct outputs are (resp): 000000000000008e and 000000000000003d
If the VC12 outputs agree with the above\, then I would believe that the values are being assigned correctly\, and the problem is with the %a processing. Otherwise\, vice-versa.
(Admittedly\, it's not impossible that we could be led astray by a bug in pack/unpack - but very unlikely\, IME.)
Cheers\, Rob
On Thu\, Apr 4\, 2019 at 8:36 PM Dave Mitchell \davem@​iabyn\.com wrote:
On Wed\, Apr 03\, 2019 at 10:00:50AM -0700\, Steve Hay (via RT) wrote:
Blead is currently failing three tests in t/op/sprintf2.t on Windows (this is Windows 10) with VC12 (x64):
Failed tests: 1512\, 1517\, 1522
VC14\, VC14.1 and MinGW-w64 GCC 7.1.0 all work fine\, all x64.
These are
sprintf "%a"\, "3e-322; # expected 0x1.e8p-1069 got 0x1.ep-1069 sprintf "%a"\, "7e-322; # expected 0x1.1cp-1067 got 0x1.1ap-1067 sprintf "%.4a"\, "3e-322; # expected 0x1.e800p-1069 got 0x1.e000p-1069
Which seems to imply the last bit of precision is being messed up. Whether that's due to the way subnormals are calculated from a string\, stored as an NV\, or processed for %a display\, I don't know.
-- More than any other time in history\, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other\, to total extinction. Let us pray we have the wisdom to choose correctly. -- Woody Allen
Yes\, the values are being assigned incorrectly by C's strtod. The good news is that sprintf's %a formatting is correctly displaying the values that were assigned ;-)
Should those 3 tests therefore be made TODO for MS compilers that are pre-VC14 ? (That VC14 passes would indicate that the TODO has now been done.)
On Fri\, Apr 5\, 2019 at 6:22 AM Steve Hay \steve\.m\.hay@​googlemail\.com wrote:
The outputs are not correct:
.\perl -le "print scalar reverse unpack 'h*'\, pack 'd\<'\, 7e-322;" 000000000000008d
perl -le "print scalar reverse unpack 'h*'\, pack 'd\<'\, 3e-322;" 000000000000003c
On Thu\, 4 Apr 2019 at 11:12\, sisyphus \sisyphus359@​gmail\.com wrote:
If we could see the output of: perl -le "print scalar reverse unpack 'h*'\, pack 'd\<'\, 7e-322;" and perl -le "print scalar reverse unpack 'h*'\, pack 'd\<'\, 3e-322;"
then we could probably deduce whether the problem is in the assigning of the value\, or elsewhere. Correct outputs are (resp): 000000000000008e and 000000000000003d
If the VC12 outputs agree with the above\, then I would believe that the values are being assigned correctly\, and the problem is with the %a processing. Otherwise\, vice-versa.
(Admittedly\, it's not impossible that we could be led astray by a bug in pack/unpack - but very unlikely\, IME.)
Cheers\, Rob
On Thu\, Apr 4\, 2019 at 8:36 PM Dave Mitchell \davem@​iabyn\.com wrote:
On Wed\, Apr 03\, 2019 at 10:00:50AM -0700\, Steve Hay (via RT) wrote:
Blead is currently failing three tests in t/op/sprintf2.t on Windows (this is Windows 10) with VC12 (x64):
Failed tests: 1512\, 1517\, 1522
VC14\, VC14.1 and MinGW-w64 GCC 7.1.0 all work fine\, all x64.
These are
sprintf "%a"\, "3e-322; # expected 0x1.e8p-1069 got 0x1.ep-1069 sprintf "%a"\, "7e-322; # expected 0x1.1cp-1067 got 0x1.1ap-1067 sprintf "%.4a"\, "3e-322; # expected 0x1.e800p-1069 got 0x1.e000p-1069
Which seems to imply the last bit of precision is being messed up. Whether that's due to the way subnormals are calculated from a string\, stored as an NV\, or processed for %a display\, I don't know.
-- More than any other time in history\, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other\, to total extinction. Let us pray we have the wisdom to choose correctly. -- Woody Allen
On Thu\, 04 Apr 2019 16:35:57 -0700\, sisyphus359@gmail.com wrote:
Yes\, the values are being assigned incorrectly by C's strtod. The good news is that sprintf's %a formatting is correctly displaying the values that were assigned ;-)
Should those 3 tests therefore be made TODO for MS compilers that are pre-VC14 ? (That VC14 passes would indicate that the TODO has now been done.)
Now marked TODO for pre-VC14 versions of VC++ in commit 113a38a2051d3a3460d5972bfb05284a2daa89ae. Thanks.
Migrated from rt.perl.org#133982 (status was 'open')
Searchable as RT133982$