qmk / qmk_firmware

Open-source keyboard firmware for Atmel AVR and Arm USB families
https://qmk.fm
GNU General Public License v2.0
18.28k stars 39.38k forks source link

[Bug] ChibiOS compilation error: '__builtin_memcpy' offset [0, 21] is out of the bounds [0, 0] #12925

Closed TheEdgeOfRage closed 3 years ago

TheEdgeOfRage commented 3 years ago

I'm not sure whether I should open this issue here, on tmk, or chibios, but it's not in any of the submodules, so I guess I'll start here. If it doesn't belong here, please redirect me to the correct place.

Describe the Bug

When trying to compile the firmware for ergodox_infinity, I get the following output:

$ MAKEFLAGS=-j1 make ergodox_infinity:default MASTER=right

QMK Firmware 0.12.38
Making ergodox_infinity with keymap default

arm-none-eabi-gcc (Arch Repository) 11.1.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling: keyboards/ergodox_infinity/keymaps/default/keymap.c                                      [OK]
Compiling: quantum/command.c                                                                        [OK]
Compiling: tmk_core/common/chibios/bootloader.c                                                    tmk_core/common/chibios/bootloader.c: In function 'bootloader_jump':
tmk_core/common/chibios/bootloader.c:90:5: error: '__builtin_memcpy' offset [0, 21] is out of the bounds [0, 0] [-Werror=array-bounds]
   90 |     __builtin_memcpy((void *)VBAT, (const void *)sys_reset_to_loader_magic, sizeof(sys_reset_to_loader_magic));
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
 [ERRORS]
 |
 |
 |
make[1]: *** [tmk_core/rules.mk:417: .build/obj_ergodox_infinity_default/common/chibios/bootloader.o] Error 1
Make finished with errors
make: *** [Makefile:523: ergodox_infinity:default] Error 1

This is after a second make run, to reduce the output for files that have already previously been compiled successfully.

System Information

Additional Context

A few days ago, this compilation ran just fine, and this error happened both before rebasing on the latest master commid and after. My guess is that something changed in my local environment, since running it in the Docker container from the provided Dockerfile, works flawlessly.

The arm-none-eabi-gcc package on archlinux received an update 4 days ago, so I assume that that is the culprit, I'm just not sure why.

I have set up a Dockerfile that reproduces the error (at least at time of writing) using the archlinux base image:

FROM archlinux

RUN pacman -Syy \
    && pacman -S --noconfirm \
        make \
        git \
        diffutils \
        arm-none-eabi-gcc \
        qmk \
    && git clone https://github.com/qmk/qmk_firmware

WORKDIR /qmk_firmware
RUN git checkout a5d7e83985ae07689cc71ab1dd2755a8ac335df3 \
    && make git-submodule

CMD make ergodox_infinity:default
tzarc commented 3 years ago

Yeah looks like a compiler issue -- it looks like trying to be smart and validate the size of the target variable, ignoring the fact that it'd been cast to something else.

Can you try changing VBAT to VBAT_BASE?

TheEdgeOfRage commented 3 years ago

Same thing :/

Compiling: tmk_core/common/chibios/bootloader.c                                                    tmk_core/common/chibios/bootloader.c: In function 'bootloader_jump':
tmk_core/common/chibios/bootloader.c:90:5: error: '__builtin_memcpy' offset [0, 21] is out of the bounds [0, 0] [-Werror=array-bounds]
   90 |     __builtin_memcpy((void *)VBAT_BASE, (const void *)sys_reset_to_loader_magic, sizeof(sys_reset_to_loader_magic));
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
t-8ch commented 3 years ago

I think it is this bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578

cknv commented 3 years ago

For anyone suffering the same problem, I have one insight to offer:

The problem seems to not be universal as I am able to compile a dz60 default layout, but is perhaps limited to keyboards made by input club. I tried compiling infinity60 and whitefox with the default layers, which ended with the same compilation error. Based on the fact that the affected keyboards are designed by the same team I would guess they would be related - software and/or hardware.

However if I downgrade the ARM bare metal GCC target package (arm-none-eabi-gcc on arch linux) to 10.3.0 from 11.1.0, I can compile and flash just fine.

Perhaps it would be possible to tweak the code to use different logic than currently, but I honestly don't know if that makes sense to do, or if it is even possible. Maybe waiting for the GCC fix is most reasonable thing to do ?

TheEdgeOfRage commented 3 years ago

13450 Fixes this issue. I rebased my branch on develop and it compiled just fine with the latest version of arm-none-eabi-gcc (11.1.0)