pack doesn't work in new gcc 4.9.1 compiler #14554
Comments
From @khwilliamsonThis is a bug report for perl from khw@khw.(none), See http://nntp.perl.org/group/perl.perl5.porters/225619 Tony Cook says "This looks like another "rubbish in the packing" issue." # Failed test 4311 - at op/pack.t line 1127 Flags: Site configuration information for perl 5.21.10: Configured by khw at Mon Mar 2 08:04:33 MST 2015. Summary of my perl5 (revision 5 version 21 subversion 10) configuration: Locally applied patches: @INC for perl 5.21.10: /home/khw/blead/lib/perl5/site_perl/5.21.10/x86_64-linux-thread-multi-ld Environment for perl 5.21.10: PATH=/home/khw/bin:/home/khw/perl5/perlbrew/bin:/home/khw/print/bin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/usr/games:/usr/local/games:/home/khw/cxoffice/bin |
From @jhiStrangely, cannot repro in OS X with g++ 4.9.2 (*), with x86_64 and "Configure -des -Dusedevel". Something about Ubuntu in particular? It would be good to change t/op/pack.t:1127 to be is($p1, $p2, "t=$t, c=$t"); There are a few spots in pp_pack.c where the pack() code intentionally calls Zero() for (*) g++-mp-4.9 (mp = MacPorts), -v saying "gcc version 4.9.2 (MacPorts gcc49 4.9.2_1)" |
From [Unknown Contact. See original ticket]Strangely, cannot repro in OS X with g++ 4.9.2 (*), with x86_64 and "Configure -des -Dusedevel". Something about Ubuntu in particular? It would be good to change t/op/pack.t:1127 to be is($p1, $p2, "t=$t, c=$t"); There are a few spots in pp_pack.c where the pack() code intentionally calls Zero() for (*) g++-mp-4.9 (mp = MacPorts), -v saying "gcc version 4.9.2 (MacPorts gcc49 4.9.2_1)" |
From @tonycozOn Tue Mar 03 04:04:28 2015, jhi wrote:
You need at least -Dcc=g++ (it doesn't happen with gcc) and -Duselongdouble (the only floating point type with packing filler). I tested that with gcc 5.0 today, but I reproduced it with 4.9.1 a few weeks ago. Here's the relevant generated codecode: /home/tony/dev/perl/git/perl/pp_pack.c:2732 ; Zero() ; the strange part, we already stored the result above, here we store it again Tony |
|
The RT System itself - Status changed from 'new' to 'open' |
From @jhiI did use -Dcc=g++-mp-4.9, but not -Duselongdouble. (I had this mental glitch of long double packing working with just HAS_LONG_DOUBLE, without USE_LONG_DOUBLE, caused by prolonged exposure to printf() code which does exactly that...) But nope, still no fail from op/pack.t in OS X, with g++ 4.9.2 and -Duselongdouble. ./miniperl -Ilib -V Characteristics of this binary (from libperl): |
From [Unknown Contact. See original ticket]I did use -Dcc=g++-mp-4.9, but not -Duselongdouble. (I had this mental glitch of long double packing working with just HAS_LONG_DOUBLE, without USE_LONG_DOUBLE, caused by prolonged exposure to printf() code which does exactly that...) But nope, still no fail from op/pack.t in OS X, with g++ 4.9.2 and -Duselongdouble. ./miniperl -Ilib -V Characteristics of this binary (from libperl): |
From @jhiI tried poking around to get to see the same disassembly but it seems that with OS X no can do. The g++ -S does some, there's otool(1) which is kind of objdump, but it's not the same. But I *think* by visual fuzzy grep this is the same spot as seen by (a) g++ -S -fverbose-asm (b) otool -tvVj: (a) L2017: (b) 000000000000b5c8 488b842498000000 movq 0x98(%rsp), %rax |
From [Unknown Contact. See original ticket]I tried poking around to get to see the same disassembly but it seems that with OS X no can do. The g++ -S does some, there's otool(1) which is kind of objdump, but it's not the same. But I *think* by visual fuzzy grep this is the same spot as seen by (a) g++ -S -fverbose-asm (b) otool -tvVj: (a) L2017: (b) 000000000000b5c8 488b842498000000 movq 0x98(%rsp), %rax |
From @khwilliamsonIf this doesn't get fixed for v5.22, the branch at |
From [Unknown Contact. See original ticket]If this doesn't get fixed for v5.22, the branch at |
From @tonycozOn Thu Mar 26 20:59:53 2015, khw wrote:
Please try the attached patch. Tony |
From @tonycoz0001-perl-123971-fix-long-double-pack-padding-on-newer-GC.patchFrom a2db6c92fc2880ba1f288b6c4599a779997dd4e7 Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Thu, 9 Apr 2015 15:45:16 +1000
Subject: [PATCH] [perl #123971] fix long double pack padding on newer GCC
---
pp_pack.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/pp_pack.c b/pp_pack.c
index 06adade..1d732a8 100644
--- a/pp_pack.c
+++ b/pp_pack.c
@@ -2709,6 +2709,12 @@ S_pack_rec(pTHX_ SV *cat, tempsym_t* symptr, SV **beglist, SV **endlist )
#ifdef __GNUC__
/* to work round a gcc/x86 bug; don't use SvNV */
anv.nv = sv_2nv(fromstr);
+# if defined(LONGDOUBLE_X86_80_BIT) && defined(USE_LONG_DOUBLE) \
+ && LONG_DOUBLESIZE > 10
+ /* GCC sometimes overwrites the padding in the
+ assignment above */
+ Zero(anv.bytes+10, sizeof(anv.bytes) - 10, U8);
+# endif
#else
anv.nv = SvNV(fromstr);
#endif
@@ -2726,6 +2732,11 @@ S_pack_rec(pTHX_ SV *cat, tempsym_t* symptr, SV **beglist, SV **endlist )
# ifdef __GNUC__
/* to work round a gcc/x86 bug; don't use SvNV */
aldouble.ld = (long double)sv_2nv(fromstr);
+# if defined(LONGDOUBLE_X86_80_BIT) && LONG_DOUBLESIZE > 10
+ /* GCC sometimes overwrites the padding in the
+ assignment above */
+ Zero(aldouble.bytes+10, sizeof(aldouble.bytes) - 10, U8);
+# endif
# else
aldouble.ld = (long double)SvNV(fromstr);
# endif
--
1.7.10.4
|
From @khwilliamsonOn 04/08/2015 11:46 PM, Tony Cook via RT wrote:
This patch causes the previously failing tests to now pass. |
|
@tonycoz - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#123971 (status was 'resolved')
Searchable as RT123971$
The text was updated successfully, but these errors were encountered: