32bit arch: EAF_Open error passing argument of 'MA_alloc_get': incompatible pointer type expected Integer {int} but argument is long int

[drew-parsons]

The debian ga build has starting failing on 32-bit arches (armel, armhf, i386 etc). The change in behaviour might be due to gcc-14 tightening compilation conditions, applying -Wincompatible-pointer-types to treat pointer inconsistencies as an error.

Build logscan be found at https://buildd.debian.org/status/package.php?p=ga
e.g. armel
i386

The error (from armel) is

/bin/bash ./libtool  --tag=CC   --mode=compile mpicc.mpich -DHAVE_CONFIG_H -I.         -Ima -I./ma -I./LinAlg/lapack+blas -Iglobal/src -I./global/src -I./global/testing -I./pario/dra -I./pario/eaf -I./pario/elio -I./pario/sf -I./ga++/src  -Igaf2c -I./gaf2c -I./tcgmsg -I./tcgmsg/tcgmsg-mpi       -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2   -fno-aggressive-loop-optimizations -fno-tree-slp-vectorize -g -O2 -c -o pario/eaf/eaf.lo pario/eaf/eaf.c
libtool: compile:  mpicc.mpich -DHAVE_CONFIG_H -I. -Ima -I./ma -I./LinAlg/lapack+blas -Iglobal/src -I./global/src -I./global/testing -I./pario/dra -I./pario/eaf -I./pario/elio -I./pario/sf -I./ga++/src -Igaf2c -I./gaf2c -I./tcgmsg -I./tcgmsg/tcgmsg-mpi -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fno-aggressive-loop-optimizations -fno-tree-slp-vectorize -g -O2 -c pario/eaf/eaf.c -o pario/eaf/eaf.o
pario/eaf/eaf.c: In function 'EAF_Open':
pario/eaf/eaf.c:172:57: error: passing argument 4 of 'MA_alloc_get' from incompatible pointer type [-Wincompatible-pointer-types]
  172 |         if (!MA_alloc_get(MT_CHAR, file[i].size, fname, &handle, &index))
      |                                                         ^~~~~~~
      |                                                         |
      |                                                         long int *
In file included from pario/eaf/eaf.c:63:
ma/macdecls.h:42:18: note: expected 'Integer *' {aka 'int *'} but argument is of type 'long int *'
   42 |     Integer     *memhandle,     /**< RETURN: handle for this block */
      |     ~~~~~~~~~~~~~^~~~~~~~~
pario/eaf/eaf.c:172:66: error: passing argument 5 of 'MA_alloc_get' from incompatible pointer type [-Wincompatible-pointer-types]
  172 |         if (!MA_alloc_get(MT_CHAR, file[i].size, fname, &handle, &index))
      |                                                                  ^~~~~~
      |                                                                  |
      |                                                                  long int *
ma/macdecls.h:43:21: note: expected 'MA_AccessIndex *' {aka 'int *'} but argument is of type 'long int *'
   43 |     MA_AccessIndex *index       /**< RETURN: index for this block */   );
      |     ~~~~~~~~~~~~~~~~^~~~~
make[4]: *** [Makefile:7126: pario/eaf/eaf.lo] Error 1

pario/eaf/eaf.c l.172 is using MA_alloc_get and providing arguments handle and index defined l.145 as long (hardcoded type).
But MA_alloc_get l.42,43 defines the arguments as type Integer.

Integer is defined via gaf2c/typesf2c.h.in l.10 as @F2C_INTEGER_C_TYPE@. This is set in configure.ac as long by default, except it gets replaced by m4/ga_f2c_match_types.m4 to the fortran integer matching C int. From the armel build log

checking for C type corresponding to INTEGER... int

In short, eaf.c hard codes the type as long, but MA_alloc_get uses Integer, which is defined as int distinct from long on 32-bit architectures.

If I understand configure correctly (configure --help), I could get a successful 32-bit build by configuring with --enable-i8, or alternatively by setting FFLAG_INT=8 so that Integer matches the long expected in eaf.c. But I'm [ed:] not sure that that's the best resolution of the problem. Should the hardcoded long instead be replaced with Integer?

[jeffhammond]

Should the hardcoded long instead be replaced with Integer?

That sounds like the right solution, but I haven't tested it.