Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1922142 - micropython fails to build on 32 bit: array subscript 'double[0]' is partly outside array bounds of 'ffi_arg[1]' {aka 'long unsigned int[1]'} [-Werror=array-bounds]
Summary: micropython fails to build on 32 bit: array subscript 'double[0]' is partly o...
Alias: None
Product: Fedora
Classification: Fedora
Component: micropython
Version: 34
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Python Maintainers
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: ARMTracker F34FTBFS 1924346 1950805
TreeView+ depends on / blocked
Reported: 2021-01-29 10:49 UTC by Miro Hrončok
Modified: 2021-05-06 13:04 UTC (History)
6 users (show)

Fixed In Version: micropython-1.15-1.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-05-06 13:04:22 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github micropython micropython issues 7064 0 None open 32 bit build failures: array subscript 'double[0]' is partly outside array bounds of 'ffi_arg[1]' {aka 'long unsigned in... 2021-03-23 18:41:53 UTC

Description Miro Hrončok 2021-01-29 10:49:04 UTC
I don't know since when, because koschei does not build 32 bit, but micropython fails to build on i686 and armv7hl with:

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) {
      |                 ^~~~~~~~~~~~
cc1: all warnings being treated as errors

This is micropython-1.13-2.fc34 and gcc-11.0.0-0.17.fc34.

Maybe we should not treat all warning as error, or maybe we should filter out this particular warning. But I have not tried to figure out yet if the warning makes sense or if this is a gcc bug. In case it is legit, we might want to inform upstream.

Note that we can easily exclude i686 as this is not multilib, but I'd like to keep building for armv7hl if possible.

Comment 1 Martin Sebor 2021-01-31 20:46:35 UTC
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 (

$ 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);

Comment 2 Martin Sebor 2021-01-31 22:14:32 UTC
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

Comment 3 Ben Cotton 2021-02-09 15:44:22 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Comment 4 Fedora Release Engineering 2021-02-14 04:22:39 UTC
Dear Maintainer,

your package has an open Fails To Build From Source bug for Fedora 34.
Action is required from you.

If you can fix your package to build, perform a build in koji, and either create
an update in bodhi, or close this bug without creating an update, if updating is
not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to
acknowledge this. If you have already fixed this issue, please close this Bugzilla report.

Following the policy for such packages [2], your package will be orphaned if
this bug remains in NEW state more than 8 weeks (not sooner than 2021-03-26).

A week before the mass branching of Fedora 35 according to the schedule [3],
any packages not successfully rebuilt at least on Fedora 33 will be
retired regardless of the status of this bug.


Comment 5 Miro Hrončok 2021-03-23 18:41:56 UTC
I finally reported this to upstream:

Sorry for the long delay.

Comment 7 Fedora Update System 2021-05-06 13:04:22 UTC
FEDORA-2021-947802b97e has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.