GMP: IBM mainframe build results

[cc'ing the libtool list because of the issues marked
[LIBTOOL] below;
these may or may not already be resolved in more recent
libtools - the
version included with gmp is 1.5.6 according to ltmain.sh
(1.220.2.94)]

I just finished building gmp 4.2.1 under OpenMVS
("370-ibm-openedition",
the Unixy subsystem of z/OS). All in all the build was a
fairly painless
experience (especially compared to trying to compile some
GNU tools).
However, the testsuite is providing me with headaches...

A few platform notes:
- the compiler considers missing headers a warning, which
breaks many
  configure tests. So the equivalent of -Werror needs to be
used,
  which is setting the envvar _CC/C89/CXX_ACCEPTABLE_RC to 0
(depending
  on whether the K&R C/ANSI C/C++ compiler is used)
- [LIBTOOL?] there is no separate linker executable, and
  configure/libtool don't handle this case ('no acceptable
LD found in
  path'), so configure needs to be told LD is $CC (or $CXX
if the C++
  wrappers are needed). Not a big deal, but it would be nice
if this
  test would fall back on $CC if no separate linker is
found.
- not all C library functions/declarations are visible by
default;
  configure should ideally be told that CPPFLAGS contains
  -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED
- [LIBTOOL] by default, the compilers require that files
come last on
  the command line, and many versions of libtool (including
the one
  included with GMP) break this rule when configure has
determined -c
  and -o can both be used (it puts the -o last). To work
around this,
  the envvar _CC/C89/CXX_CCMODE needs to be set to 1.
- I didn't build the C++ wrappers, but because they use the
.cc
  extension, the _CXX_CXXSUFFIX envvar would need to be set
to "cc" to
  succeed (by default, the compiler only accepts foo.C as a
C++ source).
- the system compiler does not use IEEE floats/doubles by
default (the
  default is the "base 16 zSeries hexadecimal
format"), so configure
  complains about it (but other than performance, this
should not have
  any impact). Might be useful to mention in the platform
notes in the
  manual that the IEEE format can be selected by adding
  "-Wc,'float(ieee)'" to CFLAGS (although it would
also have to be
  used for any application using libgmp). Configuring +
building gmp
  takes the better part of the day, so I haven't redone the
build with
  IEEE floats enabled (yet).

Build issues encountered:
- gmp.h doesn't know about OpenMVS' include guard for stdio
(__stdio),
  so configure warns that FILE prototypes won't be available
- easily
  fixed by adding a test for __stdio to gmp-h.in.
- gmp.h doesn't know whether "extern inline" works
as needed (and
  neither do I, so I didn't modify gmp-h.in for this). The
warning given
  by configure ('gmp.h doesnt recognise compiler
"__inline"') was rather
  confusing however (leaving aside the "doesnt"
typo which is repeated a
  few times in acinclude.m4). Perhaps something like
"gmp.h doesn't know
  whether the compiler supports external inlining; inlining
disabled"
  more closely matches the actual situation?
- OpenMVS has no obstacks, so the obstack-related
functionality in
  printf is disabled, which is fine. However, so much of the
ob*.c
  sources is #ifdef'ed out that the compilation unit ends up
being empty
  (only config.h is included, and that has only preprocessor
stuff).
  This causes a warning, which due to the required
-Werror-like
  behaviour (see above) stops the build. Simply moving the
stdarg/vararg
  #includes out of the obstack-available test makes things
compile
  smoothly.
- [LIBTOOL] MAJOR: The system 'ar' does not store paths,
only basenames,
  and during the (piecewise) link of libgmp.la, multiple
files with the
  same basename are given to ar, resulting in messages
like:
    ar: FSUM9942 "mpn/mul.o" ignored, same
basename as "mpq/mul.o".
  I made a little script that copied all relevant objects to
a single
  directory (replacing / by _ so I got files like
mpf_fits_sint.o) in
  order to easily (re)create a complete libgmp.a.
  I would consider this a libtool bug; adding the same file
(or files
  with the same basename) to a library multiple times works
fine as long
  as it is not in a single invocation of ar. So perhaps the
libtool
  configury should detect this issue and avoid including
multiple files
  with the same basename during piecewise linking.
- [LIBTOOL] During installation, the "libraries have
been installed in"
  message is shown, but the shell's print builtin (used in
$echo) shows
  an error for the line of dashes:
    print: ./libtool 6200: FSUM6241 Unknown option
"--"
    print: ./libtool 6200: Usage: print [-nprRsu[n]] [arg
...]
  Preceding the string with -- makes this go away ($echo --
"--...").

Test results:
- top-level:  9/9  tests passed
- mpn:        9/10 tests passed
- mpz:       35/56 tests passed
- mpq:        3/11 tests passed
- mpf:       20/26 tests passed
- rand:       7/7  tests passed
- misc:       0/3  tests passed
  total:     83/122 => 68% passed (not exactly great)

Several of the tests seem to run into the limits of the
default
floating-point system on zSeries. Its exponent is only in
the -64..63
range (according to float.h anyway), and it seems to be
limited to 248
bits (8 31-bit words).
This causes compilation errors (e.g. mpz/t-cmp_d) due to
out-of-range
floating-point literals, as well as runtime exceptions (e.g.
most of the
t-get_d tests).
I manually adjusted mpn/t-get_d for these limits, but the
test still
failed:
  mpn_get_d wrong on random data
     sign     -1
     n        =0xC6843F29A331B7
     nsize    2
     exp      -45
     want     =[C3 63 42 1F 94 D1 98 D8] -1588.132710283984
     got      =[C3 63 42 1F 94 D1 98 DB] -1588.132710283984
  CEE5207E The signal SIGABRT was received.
I also added
  #if defined (__MVS__) &&
!defined(_FP_MODE_VARIABLE)
  #define LOW_BOUND 1e-64
  #define HIGH_BOUND 8e63
  #endif
to mpf/t-get_d.c (inspired by the VAX settings), which fixed
similar
compilation issues there, and also lets the test pass
(judging by
float.h, _FP_MODE_VARIABLE is defined when IEEE floats are
enabled).

The other major source of errors is that mp_dv_tab.c assumes
ASCII while
this is an EBCDIC host; and the unfortunate decision to use
only 224
positions for base < 36 (instead of 256, or separate
tables) means it
is not possible to have a 100% working table without
adjusting many
places in the code (because '0' through '9' are 0xF0 through
0xF9, which
falls in the area where the 2 base ranges overlap). Attached
is a
version of the file that handles both ASCII and EBCDIC;
ideally the
table should be increased to the full 2x256 size, and the
offset used
for base >36 changed to 256. It relies on the ability of
the
preprocessor to compare a character literal against an
integer; I'm not
sure how portable that is - if it cannot be done this way
portably, the
best solution would be to have a
"gmp_get_digit_value_table(int base)"
method that returns the correct table (determining ASCII vs
EBCDIC at
runtime).

With these changes (limits in mpf/t-get_d.c, and
EBCDIC-friendly
mp_dv_tab.c), the test results change to

- top-level:  9/9  tests passed
- mpn:        9/10 tests passed
- mpz:       53/56 tests passed
- mpq:        9/11 tests passed
- mpf:       26/26 tests passed
- rand:       7/7  tests passed
- misc:       0/3  tests passed
  total:    113/122 => 93% passed (much, much better)

The output of the remaining errors is attached.

_______________________________________________
gmp-bugs mailing list
gmp-bugsswox.com
http://swox
.com/mailman/listinfo/gmp-bugs

GMP: IBM mainframe build results

Thread: GMP: IBM mainframe build results