kiwifb
commented
7 years ago comment:1
I can confirm the issue. The trick fells very dirty but I can easily test it I think.
Closed jpflori closed 7 years ago
kiwifb
commented
7 years ago I can confirm the issue. The trick fells very dirty but I can easily test it I think.
kiwifb
commented
7 years ago Has expected passing -D__x86_64__ -DSMARTPTR64 choke the build. Fails as soon as we load gmp headers which complain about the ABI being unsupported.
Now by default the thing builds but fails in calling pari. We could temporarily disable building against pari on non x86 (--disable-pari in giac-1.2.3-13).
More fundamentally I suspect the way pari is called is what is really wrong here, as discussed on sage-packaging https://groups.google.com/d/msgid/sage-packaging/ac9575ae-4dd3-4d29-97aa-a3ef785d3509%40googlegroups.com
kiwifb
commented
7 years ago Description changed:
---
+++
@@ -1,2 +1,2 @@
-One can maybe cheat and pass "-D__x86_64__ -DSMARTPTR64" in CPPFLAGS but that's dirty, see:
+One can maybe cheat and pass `-D__x86_64__ -DSMARTPTR64` in CPPFLAGS but that's dirty, see:
* http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?f=19&t=1723
frederichan-IMJPRG
commented
7 years ago I don't know if it helps but the 1.2.3.25 version such as in #22101 contains the modifications for pari asked there:
kiwifb
commented
7 years ago Still failing. Those changes are, I think are a progress but not the full changes that are needed - not that I would really be able to do them myself. The fact that we still have
#ifdef ENABLE_TLS
extern THREAD void *PARI_stack_limit;
#else
extern void *PARI_stack_limit;
#endifwhich is a private function is a sign you are doing something wrong.
jdemeyer
commented
7 years ago See http://pari.math.u-bordeaux.fr/archives/pari-users-1702/msg00002.html for a suggestion from the PARI developers on how this should be fixed.
jdemeyer
commented
7 years ago Description changed:
---
+++
@@ -1,2 +1,34 @@
+Executing `1+1` with giac-1.2.2.103 on ppc64le POWER8:
+
+```
+0>> 1+1;
+[New Thread 0x3fff7443f180 (LWP 173710)]
+
+Program received signal SIGSEGV, Segmentation fault.
+[Switching to Thread 0x3fff7443f180 (LWP 173710)]
+0x00003fffb7b9e544 in giac::gen::in_eval (this=0x3fff7443e768, level=25, evaled=..., contextptr=0x3fffffffda40) at gen.cc:2109
+2109 evaled=(*_SYMBptr->sommet.ptr())(evaled,contextptr);
+(gdb) bt
+#0 0x00003fffb7b9e544 in giac::gen::in_eval (this=0x3fff7443e768, level=25, evaled=..., contextptr=0x3fffffffda40) at gen.cc:2109
+#1 0x00003fffb7b9bcdc in giac::gen::eval (this=0x3fff7443e768, level=25, contextptr=0x3fffffffda40) at gen.cc:1899
+#2 0x00003fffb789e6ac in giac::protecteval (g=..., level=25, contextptr=0x3fffffffda40) at prog.cc:6881
+#3 0x00003fffb767ff44 in giac::in_thread_eval (arg=0x100a9cd8) at global.cc:3463
+#4 0x00003fffb5b18070 in start_thread () from /lib/powerpc64le-linux-gnu/libpthread.so.0
+#5 0x00003fffb5763230 in clone () from /lib/powerpc64le-linux-gnu/libc.so.6
+(gdb) list
+2104 evaled=_SYMBptr->feuille;
+2105 }
+2106 if (is_ifte)
+2107 evaled=ifte(evaled,true,contextptr);
+2108 else
+2109 evaled=(*_SYMBptr->sommet.ptr())(evaled,contextptr);
+2110 elevel=slevel;
+2111 }
+2112 else
+2113 evaled=_SYMBptr->eval(level,contextptr);
+```
+
+---
+
One can maybe cheat and pass `-D__x86_64__ -DSMARTPTR64` in CPPFLAGS but that's dirty, see:
* http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?f=19&t=1723(1) What does this refer to:
One can maybe cheat and pass
-D__x86_64__ -DSMARTPTR64in CPPFLAGS but that's dirty, see:
(2) From the comments it seems that you think that there is a problem with PARI. Why do you think that?
jdemeyer
commented
7 years ago Description changed:
---
+++
@@ -28,6 +28,8 @@
2113 evaled=_SYMBptr->eval(level,contextptr);One can maybe cheat and pass -D__x86_64__ -DSMARTPTR64 in CPPFLAGS but that's dirty, see:
Note that compiling with -D__x86_64__ obviously does not work due to the use of inline assembly in ifactor.cc.
jdemeyer
commented
7 years ago And compiling with -DSMARTPTR64 (whatever that means) does not change anything.
frederichan-IMJPRG
commented
7 years ago There is a related topic (about SMARTPTR64 that should not be undefined by first.h)here: http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?f=4&t=1785
edd8e884-f507-429a-b577-5d554626c0fe
commented
7 years ago I am not sure if it is the same error, but i cannot build+check giac on Debian Jessie 32bits, see the attached log. It fails at chk_fhan1 and before there are tons of "bug in PARI/GP (Segmentation Fault), please report."
Since giac is a standard package, i set the priority to blocker.
frederichan-IMJPRG
commented
7 years ago Attachment: giac-1.2.2.103.log.7.6.rc0.gz
Replying to @sagetrac-tmonteil:
I am not sure if it is the same error, but i cannot build+check
giacon Debian Jessie 32bits, see the attached log. It fails atchk_fhan1and before there are tons of "bug in PARI/GP (Segmentation Fault), please report."Since
giacis a standard package, i set the priority to blocker.
On linux 32bits there is the following problem #22101 and it should be already solved by giac-1.2.3.25 but I am waiting the next one to have a new config.guess as it was requested in #22101.
vbraun
commented
7 years ago Unless something happens real soon I'll ignore this for sage 7.6. If it isn't fixed we should think about downgrading giac to optional.
The snippet in the description is hopefully not repesentative of the giac code quality:
edd8e884-f507-429a-b577-5d554626c0fe
commented
7 years ago If the upgrade can not be done soon (i hope it could!), another possibility would be to downgrade giac/giacpy_sage to a previously working version. Indeed, pynac is standard and depends on giac.
kiwifb
commented
7 years ago Replying to @sagetrac-tmonteil:
If the upgrade can not be done soon (i hope it could!), another possibility would be to downgrade
giac/giacpy_sageto a previously working version. Indeed,pynacis standard and depends ongiac.
pynac doesn't currently depend on giac. Ralf wants it to happen, but things keep getting in the way. Enabling giac in pynac will cause at least two doctests to fail.
edd8e884-f507-429a-b577-5d554626c0fe
commented
7 years ago Dependencies: #22101
edd8e884-f507-429a-b577-5d554626c0fe
commented
7 years ago If people running powerpc and other platforms coudl check #22101, it seems to solve the issue.
jpflori
commented
7 years ago Trying it on ppc64.
frederichan-IMJPRG
commented
7 years ago Replying to @sagetrac-tmonteil:
If people running powerpc and other platforms coudl check #22101, it seems to solve the issue.
Really? I thought it was only improving for i386. (cf comment4) The only (small) news I have for other architecture are about arm64 from this topic: http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?f=4&t=1785
where it seems that the static built of icas is functionnal while the original built crashes with 1+1
jpflori
commented
7 years ago I can confirm nothing changed on ppc64.
kiwifb
commented
7 years ago I think SMARTPTR64 is unrelated to our problems. It is added in some pre-made makefile, some of them for the debian package specifically. But there is no way I can see for it to make its way in the build system on a regular build - any system. Same story for DOUBLEVAL but this time with windows and OS X - it could be of interest since on OS X it included ppc.
frederichan-IMJPRG
commented
7 years ago does
./configure --enable-shared=nochanges things?
kiwifb
commented
7 years ago I cannot test right now - I am waiting for a world update to finish on the machine (this is a gentoo prefix, everything is compiled) but I am putting it on the things to try.
edd8e884-f507-429a-b577-5d554626c0fe
commented
7 years ago Replying to @frederichan-IMJPRG:
Replying to @sagetrac-tmonteil:
If people running powerpc and other platforms coudl check #22101, it seems to solve the issue.
Really? I thought it was only improving for i386. (cf comment4)
Sorry, i meant it solves the issue on i386.
kiwifb
commented
7 years ago Currently for me every single tests fails (but I can do 1+1) on ppc64. Trying to run a test manually I get the following back trace which is slightly different from Jeroen
#7480 <signal handler called>
#7481 0x00000400020258e0 in ?? () from /shared/work_no_backup/ppc64-prefix/usr/lib64/libpari-gmp-2.8.so.0
#7482 0x00000400020258b0 in ?? () from /shared/work_no_backup/ppc64-prefix/usr/lib64/libpari-gmp-2.8.so.0
#7483 0x00000400020274f8 in .pari_err () from /shared/work_no_backup/ppc64-prefix/usr/lib64/libpari-gmp-2.8.so.0
#7484 0x0000040002028290 in .pari_sighandler () from /shared/work_no_backup/ppc64-prefix/usr/lib64/libpari-gmp-2.8.so.0
#7485 <signal handler called>
#7486 0x00000400005565ec in .std::vector<char const*, std::allocator<char const*> >::_M_insert_aux(__gnu_cxx::__normal_iterator<char const**, std::vector<char const*, std::allocator<char const*> > >, char const* const&) () from /dev/shm/portage/sci-mathematics/giac-1.2.2.105/work/giac-1.2.2/src/.libs/libgiac.so.0
#7487 0x00000400005550bc in .giac::symbolic::eval(int, giac::context const*) const () from /dev/shm/portage/sci-mathematics/giac-1.2.2.105/work/giac-1.2.2/src/.libs/libgiac.so.0
#7488 0x0000040000c8e158 in .giac::gen::in_eval(int, giac::gen&, giac::context const*) const ()
from /dev/shm/portage/sci-mathematics/giac-1.2.2.105/work/giac-1.2.2/src/.libs/libgiac.so.0
#7489 0x0000040000c8fb58 in .giac::gen::eval(int, giac::context const*) const () from /dev/shm/portage/sci-mathematics/giac-1.2.2.105/work/giac-1.2.2/src/.libs/libgiac.so.0
#7490 0x0000040000a35074 in .giac::protecteval(giac::gen const&, int, giac::context const*) ()
from /dev/shm/portage/sci-mathematics/giac-1.2.2.105/work/giac-1.2.2/src/.libs/libgiac.so.0
#7491 0x000004000083d654 in .giac::in_thread_eval(void*) () from /dev/shm/portage/sci-mathematics/giac-1.2.2.105/work/giac-1.2.2/src/.libs/libgiac.so.0
#7492 0x0000040002bbbb10 in .start_thread () from /shared/work_no_backup/ppc64-prefix/lib64/libpthread.so.0
#7493 0x000004000170b268 in .__clone () from /shared/work_no_backup/ppc64-prefix/lib64/libc.so.6I have cut all the extra repetition of the pari signal handler. This is 1.2.2-105, with 1.2.3 compiled "statically" (same "test case"):
#0 0x000000001029321c in .std::vector<char const*, std::allocator<char const*> >::_M_insert_aux(__gnu_cxx::__normal_iterator<char const**, std::vector<char const*, std::allocator<char const*> > >, char const* const&) ()
#1 0x0000000010291eec in .giac::symbolic::eval(int, giac::context const*) const ()
#2 0x000000001098e0c0 in .giac::gen::in_eval(int, giac::gen&, giac::context const*) const ()
#3 0x0000000010291b64 in .giac::symbolic::eval(int, giac::context const*) const ()
#4 0x000000001098e0c0 in .giac::gen::in_eval(int, giac::gen&, giac::context const*) const ()
#5 0x000000001098f570 in .giac::gen::eval(int, giac::context const*) const ()
#6 0x000000001070fe14 in .giac::protecteval(giac::gen const&, int, giac::context const*) ()
#7 0x0000000010568324 in .giac::in_thread_eval(void*) ()
#8 0x00000400017fbb10 in .start_thread () from /shared/work_no_backup/ppc64-prefix/lib64/libpthread.so.0
#9 0x0000040001f0b268 in .__clone () from /shared/work_no_backup/ppc64-prefix/lib64/libc.so.6(Sorry just small news) I have tried with qemu on the following:
Linux debianppc64 3.16.0-4-powerpc64le #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) ppc64le GNU/Linuxto build giac on a basic debian (stable) system with just libgmp-dev and libmpfr-dev.
With the defaut compiler (gcc 4.9) I was able to built giac 1.2.3-31 and reproduce crashes with 1+1 or also just by evaluating: e (it should answer exp(1))
trying with e it seems that the string giving the name of a fonction was not correctly stored.
(gdb) p sommet.ptr()
$12 = (giac::unary_function_abstract *) 0xb7f71ee0
(gdb) p sommet.ptr()->s
Cannot access memory at address 0xb7f71ee8NB: as I am under qemu I have 1cpu and my threads value was 1. (yours may differ, I don't know if you are able to do: threads:=1)
Then I tried to built with gcc 4.8 and I got a good version of giac.
kiwifb
commented
7 years ago My latest experiment on ppc64 build with -O0 -ggdb, pari and ntl disabled to simplify things and rule them out.
#0 0x0000040000b1a068 in giac::add_print_symbolic (s=..., g=..., contextptr=0xffff075a590) at symbolic.cc:483
483 if ( g.sommet.ptr()->printsommet && g.sommet!=at_plus && g.sommet!=at_prod && g.sommet!=at_pow){
[Current thread is 1 (Thread 0x4000004d460 (LWP 13277))]
(gdb) bt
#0 0x0000040000b1a068 in giac::add_print_symbolic (s="", g=..., contextptr=0xffff075a590) at symbolic.cc:483
#1 0x0000040000b1b18c in giac::symbolic::print[abi:cxx11](giac::context const*) const (this=0x10094d18, contextptr=0xffff075a590) at symbolic.cc:599
#2 0x00000400013ea160 in giac::gen::print[abi:cxx11](giac::context const*) const (this=0xffff0743918, contextptr=0xffff075a590) at gen.cc:12815
#3 0x00000400013069d4 in giac::warn_implicit (a=..., b=..., contextptr=0xffff075a590) at usual.cc:4950
#4 0x0000040001306cbc in giac::check_symb_of (a=..., b0=..., contextptr=0xffff075a590) at usual.cc:4960
#5 0x0000040000afed78 in giac::giac_yyparse (scanner=0x1008bdd0) at input_parser.yy:232
#6 0x00000400013d7784 in giac::try_parse (
s=" restart;maple_mode(1);cas_setup(0,0,0,1,0,1e-10,10,[1,50,0,25],0,0,0); #radians,pas de cmplx, pas de Sqrt\n/* astuces, a retenir: sous xcas on utilise unapply qui est en general plus sur\243que la metho"..., contextptr=0xffff075a590) at gen.cc:11074
#7 0x00000400013d9284 in giac::protected_giac_yyparse (
chaine=" restart;maple_mode(1);cas_setup(0,0,0,1,0,1e-10,10,[1,50,0,25],0,0,0); #radians,pas de cmplx, pas de Sqrt\n/* astuces, a retenir: sous xcas on utilise unapply qui est en general plus sur\243que la metho"..., parse_result=..., contextptr=0xffff075a590) at gen.cc:11237
#8 0x00000400013d95d0 in giac::gen::gen (this=0xffff0759f58,
s=" restart;maple_mode(1);cas_setup(0,0,0,1,0,1e-10,10,[1,50,0,25],0,0,0); #radians,pas de cmplx, pas de Sqrt\n/* astuces, a retenir: sous xcas on utilise unapply qui est en general plus sur\243que la metho"..., contextptr=0xffff075a590) at gen.cc:11267
#9 0x000004000076788c in giac::readargs_from_stream (inf=..., args=..., contextptr=0xffff075a590) at sym2poly.cc:3869
#10 0x0000040000767cf8 in giac::readargs (ARGC=2, ARGV=0xffff075b5e8, args=..., contextptr=0xffff075a590) at sym2poly.cc:3920
#11 0x0000000010011b60 in main (ARGC=2, ARGV=0xffff075b5e8) at icas.cc:1615I also noticed this warning during the build, nothing bad happens because of it on x86_64 but who knows
usual.cc: In function 'giac::complex_long_double giac::lngamma(giac::complex_long_double)':
usual.cc:7138:30: note: the ABI of passing aggregates with 16-byte alignment has changed in GCC 5
static complex_long_double lngamma(complex_long_double x){
^I guess that
g.sommet.ptr()->printsommet
try to acces to the string representation of a usual symbol. so it looks similar to what I got.
May be the less confusing example is to just type: e in icas, it should crash also for you when trying to obtain the exp string while d should return d because it is not a reserved keyword. Could it be an loader ordering problem?
kiwifb
commented
7 years ago Typing e in icas segfault and that's what I get from the core dump
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000040000b28538 in __gnu_cxx::new_allocator<char const*>::construct<char const*, char const* const&> (this=0x1007fc00, __p=0x40054000940)
at /shared/work_no_backup/ppc64-prefix/usr/lib/gcc/powerpc64-unknown-linux-gnu/5.4.0/include/g++-v5/ext/new_allocator.h:120
120 { ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
[Current thread is 1 (Thread 0x4005228f080 (LWP 40544))]
(gdb) bt
#0 0x0000040000b28538 in __gnu_cxx::new_allocator<char const*>::construct<char const*, char const* const&> (this=0x1007fc00, __p=0x40054000940)
at /shared/work_no_backup/ppc64-prefix/usr/lib/gcc/powerpc64-unknown-linux-gnu/5.4.0/include/g++-v5/ext/new_allocator.h:120
#1 0x0000040000b274fc in std::allocator_traits<std::allocator<char const*> >::construct<char const*, char const* const&> (__a=..., __p=0x40054000940)
at /shared/work_no_backup/ppc64-prefix/usr/lib/gcc/powerpc64-unknown-linux-gnu/5.4.0/include/g++-v5/bits/alloc_traits.h:530
#2 0x0000040000b275cc in std::vector<char const*, std::allocator<char const*> >::_M_emplace_back_aux<char const* const&> (this=0x1007fc00)
at /shared/work_no_backup/ppc64-prefix/usr/lib/gcc/powerpc64-unknown-linux-gnu/5.4.0/include/g++-v5/bits/vector.tcc:416
#3 0x0000040000b263c4 in std::vector<char const*, std::allocator<char const*> >::push_back (this=0x1007fc00, __x=<error reading variable>)
at /shared/work_no_backup/ppc64-prefix/usr/lib/gcc/powerpc64-unknown-linux-gnu/5.4.0/include/g++-v5/bits/stl_vector.h:923
#4 0x0000040000b21ca4 in giac::symbolic::eval (this=0x1013a1a8, level=25, contextptr=0xfffc02556f0) at symbolic.cc:1371
#5 0x0000040001368ccc in giac::gen::in_eval (this=0x4005228e5c8, level=25, evaled=..., contextptr=0xfffc02556f0) at gen.cc:2113
#6 0x0000040001366268 in giac::gen::eval (this=0x4005228e5c8, level=25, contextptr=0xfffc02556f0) at gen.cc:1899
#7 0x000004000106fd7c in giac::protecteval (g=..., level=25, contextptr=0xfffc02556f0) at prog.cc:6881
#8 0x0000040000e4e50c in giac::in_thread_eval (arg=0x1007ff28) at global.cc:3463
#9 0x000004000265bb10 in .start_thread () from /shared/work_no_backup/ppc64-prefix/lib64/libpthread.so.0
#10 0x0000040002d6b268 in .__clone () from /shared/work_no_backup/ppc64-prefix/lib64/libc.so.6So you have the same debug as what I had with gcc4.9 in comment 26 where I put a break in symbolic.cc.
But for me, if after the built I rebuilt icas with .libs/libgiac.a instead of .libs/libgiac.so by doing in the src/ directory:
fred@debianppc64:~/giac-1.2.3-gcc49/src$ g++ -g -fno-strict-aliasing -DGIAC_GENERIC_CONSTANTS -o .libs/icas icas.o ./.libs/libxcas.a /home/fred/giac-1.2.3-gcc49/src/.libs/libgiac.a -lreadline -ltermcap -lrt -lpthread -ldl -lm -lmpfr -lgmpthen I can run .libs/icas without problems.
jpflori
commented
7 years ago Indeed, if I configure giac with disable-shared, I can ask e in icas without sefgault.
jpflori
commented
7 years ago But I still have similar failures:
0>> maple_mode(0);
[New Thread 0x3fffaf10f1a0 (LWP 31223)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x3fffaf10f1a0 (LWP 31223)]
0x000000001034c1a0 in __gnu_cxx::new_allocator<char const*>::construct (
this=0x1107a830, __p=0x3fffa8000940,
__val=@0xffffe3b0: <error reading variable>)
at /usr/include/c++/4.8.3/ext/new_allocator.h:130
130 { ::new((void *)__p) _Tp(__val); }
Missing separate debuginfos, use: debuginfo-install glibc-2.18-16.fc20.ppc64p7 libgcc-4.8.3-7.fc20.ppc64 libgfortran-4.8.3-7.fc20.ppc64 libstdc++-4.8.3-7.fc20.ppc64
(gdb) bt
#0 0x000000001034c1a0 in __gnu_cxx::new_allocator<char const*>::construct (
this=0x1107a830, __p=0x3fffa8000940,
__val=@0xffffe3b0: <error reading variable>)
at /usr/include/c++/4.8.3/ext/new_allocator.h:130
#1 0x000000001034ae74 in __gnu_cxx::__alloc_traits<std::allocator<char const*> >::construct<char const*> (__a=..., __p=0x3fffa8000940,
__arg=@0xffffe3b0: <error reading variable>)
at /usr/include/c++/4.8.3/ext/alloc_traits.h:216
#2 0x000000001034b024 in std::vector<char const*, std::allocator<char const*> >::_M_insert_aux (this=0x1107a830,
__position=<error reading variable: Cannot access memory at address 0x0>,
__x=@0xffffe3b0: <error reading variable>)
at /usr/include/c++/4.8.3/bits/vector.tcc:353
#3 0x000000001034942c in std::vector<char const*, std::allocator<char const*> >::push_back (this=0x1107a830, __x=@0xffffe3b0: <error reading variable>)
at /usr/include/c++/4.8.3/bits/stl_vector.h:913
#4 0x0000000010344af4 in giac::symbolic::eval (this=0x1119df98, level=25,
contextptr=0x3fffffffde10) at symbolic.cc:1372
#5 0x0000000010b7f04c in giac::gen::in_eval (this=0x3fffaf10e6f8, level=25,
evaled=..., contextptr=0x3fffffffde10) at gen.cc:2109
#6 0x0000000010b7c7f8 in giac::gen::eval (this=0x3fffaf10e6f8, level=25,
contextptr=0x3fffffffde10) at gen.cc:1893
#7 0x0000000010887b2c in giac::protecteval (g=..., level=25,
contextptr=0x3fffffffde10) at prog.cc:7001
#8 0x000000001068bb08 in giac::in_thread_eval (arg=0x1107aad8)
at global.cc:3467
#9 0x00003fffb703c328 in .start_thread () from /lib64/libpthread.so.0
#10 0x00003fffb6abdc70 in .__clone () from /lib64/libc.so.6A shorter one:
0>> maple_mode
[New Thread 0x3fffaf10f1a0 (LWP 35528)]
[Thread 0x3fffaf10f1a0 (LWP 35528) exited]
Program received signal SIGSEGV, Segmentation fault.
0x0000000010bfc680 in giac::gen::print (this=0x3fffffffdb50,
contextptr=0x3fffffffde10) at gen.cc:12961
12961 if (rpn_mode(contextptr) || _FUNCptr->ptr()->printsommet==&printastifunction || subtype==0)
(gdb) bt
#0 0x0000000010bfc680 in giac::gen::print (this=0x3fffffffdb50,
contextptr=0x3fffffffde10) at gen.cc:12961
#1 0x00000000100174cc in main (ARGC=1, ARGV=0x3fffffffe398) at icas.cc:1536
(gdb) This looks bad:
(gdb) p this->ref_FUNCptr()->ptr()
$8 = (giac::unary_function_abstract *) 0xffffe3a8Address has been cut.
jpflori
commented
7 years ago One can circumvent that by setting __x86_64__ but this automatically sets SMARTPTR64 which might be broken on ppc64 because of endianness (vould work on ppc64le) and _I386_ which includes assembly code.
I'm now trying with proper 64 bits pointers but without "smart" pointers.
jpflori
commented
7 years ago Oh yeah and on 64 bits systems, not using SMARTPTR64 is doomed to fail because C(++) types of different lengths are used to access the _FUNC_ part of a gen.
jpflori
commented
7 years ago And double storage trick fails because of byte order and is fixed when passing -DDOUBLEVAL.
jpflori
commented
7 years ago Everything seems fine now, patches on their way.
jpflori
commented
7 years ago Here you go. Please report any success/failure with this branch.
New commits:
f5e35f2 | Make giac behave correctly on 64 bits or big endian systems. |
jpflori
commented
7 years ago Branch: public/giac
jpflori
commented
7 years ago Author: Jean-Pierre Flori
jpflori
commented
7 years ago Upstream: Not yet reported upstream; Will do shortly.
jpflori
commented
7 years ago And let's even say it's needs_review...
jpflori
commented
7 years ago I've been in contact with Bernard (Parisse = upstream) and made some efforts have been made towards more portability but according to my experiments not enough at the moment. See:
__x86_64__ to x86_64 which is kind of a good move though I'd prefer a better macro name and why not just use __LP64__; and this does not prevent inclusion of x86_64 assembly on non-x86_64 and this change (as mine) covers at the same times part where we want pointers to be 64 bit but also long to be (or long long? which would make it more easy to deal with)..._FUNC_SMARTPTR64 on (approximatively) __LP64__ and __LLP64__ archs; but there is still the endianness issue with smart pointers.DOUBLEVAL is not defined but that should not happen when x86_64 is defined.jpflori
commented
7 years ago Changed upstream from Not yet reported upstream; Will do shortly. to Reported upstream. No feedback yet.
edd8e884-f507-429a-b577-5d554626c0fe
commented
7 years ago Did you suggest the fix for libpng/lpng1x too ([/22159#comment:29 suggested on this comment])?
kiwifb
commented
7 years ago Which version is your starting point? I am trying with 1.2.3-25 at the moment (because I have it handy on ppc64 right now) and while it is an improvement there are still failures, and I seem to be hanging at chk_morley_demo and a few others.
Executing
1+1with giac-1.2.2.103 on ppc64le POWER8:Upgrading to giac-1.2.3.25 (#22101) does not fix this problem.
Use > -45 version: The upstream tarball is at http://www-fourier.ujf-grenoble.fr/~parisse/debian/dists/stable/main/source/giac_1.2.3-47.tar.gz Repackaged tarball is at:
-Dx86_64in CPPFLAGS.Depends on #22101
Upstream: Fixed upstream, in a later stable release.
CC: @rwst @frederichan-IMJPRG @vbraun
Component: packages: standard
Author: Jean-Pierre Flori
Branch:
8dc4c88Reviewer: Thierry Monteil, Jean-Pierre Flori, François Bissey
Issue created by migration from https://trac.sagemath.org/ticket/22280