This weekend, I attempted to build polyml 5.8 for Fedora (Rawhide for now, hopefully Fedora 30 later). I encountered issues with the 32-bit ARM build and the s390x build.
On s390x, immediately after the C++ code is compiled, polyimport is executed for the first time:
./polyimport polytemp.txt -I . < ./exportPoly.sml /bin/sh: line 1: 33283 Segmentation fault (core dumped) ./polyimport polytemp.txt -I . < ./exportPoly.sml
GDB says: (gdb) bt #0 0x000003fffde56ce6 in PolyObject::Get (this=0x8017c8fcff030000, i=0) at globals.h:311 #1 0x000003fffdebbfce in IntTaskData::SwitchToPoly (this=0x10336d0) at interpret.cpp:761 #2 0x000003fffdec2830 in IntTaskData::EnterPolyCode (this=0x10336d0) at interpret.cpp:2261 #3 0x000003fffde92eea in NewThreadFunction (parameter=0x10336d0) at processes.cpp:1307 #4 0x000003fffdb89da6 in start_thread () from /usr/lib64/libpthread.so.0 #5 0x000003fffdd01b06 in thread_start () from /usr/lib64/libc.so.6
Notice the "this" parameter in frame 0. That is an invalid address ... unless one reverses the bytes to get 0x000003fffcc81780, which is a valid address. The code that produces the argument to indirect_0 has apparently done so in little endian byte order. If you can tell me where to look, I can help debug this further. The presence or absence of --enable-compact32bit makes no difference; the segfault happens either way.
On 32-bit ARM, the build succeeds, but one test fails: Tests/Succeed/Test174.ML. The first two failures are on lines 34 and 35:
check(Real32.fromLarge IEEEReal.TO_ZERO pm < p32); check(Real32.fromLarge IEEEReal.TO_ZERO mp > m32);
Entering those values by hand at the polyml command prompt I get:
Real32.fromLarge IEEEReal.TO_ZERO pm;
val it = 3.141592741: Real32.real
p32;
val it = 3.141592741: ?.Math.real
Real32.fromLarge IEEEReal.TO_ZERO mp;
val it = ~3.141592741: Real32.real
Then the tests at lines 40 and 42 fail:
check(Real32.fromLarge IEEEReal.TO_POSINF pp > p32); check(Real32.fromLarge IEEEReal.TO_POSINF mp > m32);
Real32.fromLarge IEEEReal.TO_POSINF pp;
val it = 3.141592741: Real32.real
Real32.fromLarge IEEEReal.TO_POSINF mp;
val it = ~3.141592741: Real32.real
Likewise, the tests at lines 48 and 50 fail:
check(Real32.fromLarge IEEEReal.TO_NEGINF pm < p32); check(Real32.fromLarge IEEEReal.TO_NEGINF mm < m32);
Real32.fromLarge IEEEReal.TO_NEGINF pm;
val it = 3.141592741: Real32.real
Real32.fromLarge IEEEReal.TO_NEGINF mm;
val it = ~3.141592741: Real32.real
The output of configure on ARM seems okay, although I will note an entirely different problem:
configure:17740: checking whether as supports .note.GNU-stack configure:17753: armv7hl-redhat-linux-gnueabi-gcc -c -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -march=armv7-a -mfpu=vfpv3-d16 -mtune=generic-armv7-a -mabi=aapcs-linux -mfloat-abi=hard -fno-strict-aliasing -D_GNU_SOURCE conftest.c >&5 {standard input}: Assembler messages: {standard input}:552: Error: junk at end of line, first unrecognized character is `,' configure:17753: $? = 1 configure: failed program was: | /* confdefs.h */
[ skip lots of #defines that don't matter]
| /* end confdefs.h. */ | __asm__(".section .note.GNU-stack,"", at progbits"); | int | main () | { | | ; | return 0; | }
Taking a clue from the output of gcc -S conftest.c -fverbose-asm after removing the __asm__ line above, I changed @progbits to %progbits, and then the test worked.
Advice on how to proceed w.r.t the floating point issues with the ARM build is much appreciated. Regards,