GMP: IBM mainframe build results

[Tim Van Holder]

[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.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gmp-check-failures.log
Url: http://gmplib.org/list-archives/gmp-bugs/attachments/20070713/a3599caf/attachment.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mp_dv_tab.c
Url: http://gmplib.org/list-archives/gmp-bugs/attachments/20070713/a3599caf/attachment.c