Skip to content

32 bit build failures: array subscript 'double[0]' is partly outside array bounds of 'ffi_arg[1]' {aka 'long unsigned int[1]'} [-Werror=array-bounds] #7064

@hroncok

Description

@hroncok

Hello. In Fedora, we get the following Werror when we build micropython (unix port) with GCC 11 on i686 or armv7hl:

gcc -I../../lib/berkeley-db-1.xx/PORT/include -I. -I../.. -Ibuild-standard -I../../lib/mp-readline -Wall -Werror -Wpointer-arith -Wuninitialized -Wdouble-promotion -Wsign-compare -Wfloat-conversion -std=gnu99 -DUNIX -DFFCONF_H=\"lib/oofatfs/ffconf.h\" -DMICROPY_PY_USSL=1 -DMICROPY_SSL_AXTLS=1 -I../../lib/axtls/ssl -I../../lib/axtls/crypto -I../../extmod/axtls-include -DMICROPY_PY_BTREE=1 -DMICROPY_USE_READLINE=1 -DMICROPY_PY_TERMIOS=1 -DMICROPY_PY_SOCKET=1 -DMICROPY_PY_THREAD=1 -DMICROPY_PY_THREAD_GIL=0  -DMICROPY_PY_FFI=1 -Os -fdata-sections -ffunction-sections -DNDEBUG -Ivariants/standard  -g -U _FORTIFY_SOURCE -DMICROPY_QSTR_EXTRA_POOL=mp_qstr_frozen_const_pool -DMICROPY_MODULE_FROZEN_MPY -DMPZ_DIG_SIZE=16  -DMICROPY_MODULE_FROZEN_STR -c -MD -o build-standard/modffi.o modffi.c
make: Leaving directory '/builddir/build/BUILD/micropython-1.13/ports/unix'
modffi.c: In function 'ffifunc_call':
modffi.c:174:20: error: array subscript 'double[0]' is partly outside array bounds of 'ffi_arg[1]' {aka 'long unsigned int[1]'} [-Werror=array-bounds]
  174 |             return mp_obj_new_float_from_d(*p);
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~
modffi.c:365:17: note: while referencing 'val'
  365 | STATIC mp_obj_t ffifunc_call(mp_obj_t self_in, size_t n_args, size_t n_kw, const mp_obj_t *args) {
      |                 ^~~~~~~~~~~~

Martin Sebor, a gcc maintainer, says:

The code the warning points to (copied below) casts ffi_arg* to double*. Browsing the sources suggests ffi_arg should be a typedef for a 64-bit integer type but if it's smaller that would explain the warning. Either way, accessing object of one type using a pointer to an incompatible type is undefined, regardless of whether they have the same size, so the code on like 174 is likely invalid. The text of the warning isn't quite clear about this and a patch I submitted upstream just last week, besides changing this instance from -Warray-bounds to -Wstrict-aliasing, adjusts its text to make the problem clearer (https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564483.html).

$ cat -n micropython-1.13/ports/unix/modffi.c | head -n180 | tail -n16
   165	        #if MICROPY_PY_BUILTINS_FLOAT
   166	        case 'f': {
   167	            union { ffi_arg ffi;
   168	                    float flt;
   169	            } val_union = { .ffi = val };
   170	            return mp_obj_new_float_from_f(val_union.flt);
   171	        }
   172	        case 'd': {
   173	            double *p = (double *)&val;
   174	            return mp_obj_new_float_from_d(*p);
   175	        }
   176	        #endif
   177	        case 'O':
   178	            return (mp_obj_t)(intptr_t)val;
   179	        default:
   180	            return mp_obj_new_int(val);

A bit more testing suggests the problem might be due to armv7hl-eabi defining ffi_arg to unsigned long:

$ grep "typedef.*ffi_arg" micropython-1.13/lib/libffi/src/arm/*
micropython-1.13/lib/libffi/src/arm/ffitarget.h:typedef unsigned long          ffi_arg;

...which in the GCC cross for the target is a 32-bit type:

$ /build/armv7hl-eabi/gcc-master/gcc/xgcc -B /build/armv7hl-eabi/gcc-master/gcc -dM -E -xc - < /dev/null | grep -e SIZEOF_LONG -e SIZEOF_DOUBLE
#define __SIZEOF_LONG__ 4
#define __SIZEOF_LONG_DOUBLE__ 8
#define __SIZEOF_DOUBLE__ 8
#define __SIZEOF_LONG_LONG__ 8

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions