[Bug c/106554] New: -fstack-usage result too low for variadic function on Arm

[Bug c/106554] New: -fstack-usage result too low for variadic function on Arm

[tim.schendekehl+gcc at egnite dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106554

            Bug ID: 106554
           Summary: -fstack-usage result too low for variadic function on
                    Arm
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tim.schendekehl+gcc at egnite dot de
  Target Milestone: ---

The following code contains a simple variadic function:
void f(const char *fmt, ...)
{
    (void)fmt;
}

I have compiled it with the following command:
arm-none-eabi-gcc teststackusage.c -mcpu=cortex-m7 -mthumb -c -O0 -Wall -Wextra
-fstack-usage

GCC creates the file teststackusage.su with information about the stack usage:
teststackusage.c:1:6:f  4       static

It reports a stack usage of 4 bytes, but the disassembly looks like it should
be 20 bytes:
00000000 <f>:
   0:   b40f            push    {r0, r1, r2, r3}
   2:   b480            push    {r7}
   4:   af00            add     r7, sp, #0
   6:   bf00            nop
   8:   46bd            mov     sp, r7
   a:   bc80            pop     {r7}
   c:   b004            add     sp, #16
   e:   4770            bx      lr

Information reported by arm-none-eabi-gcc -v:
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/12.1.0/lto-wrapper
Target: arm-none-eabi
Configured with: /build/arm-none-eabi-gcc/src/gcc-12.1.0/configure
--target=arm-none-eabi --prefix=/usr --with-sysroot=/usr/arm-none-eabi
--with-native-system-header-dir=/include --libexecdir=/usr/lib
--enable-languages=c,c++ --enable-plugins --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath
--disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-system-zlib
--with-newlib --with-headers=/usr/arm-none-eabi/include
--with-python-dir=share/gcc-arm-none-eabi --with-gmp --with-mpfr --with-mpc
--with-isl --with-libelf --enable-gnu-indirect-function
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='Arch Repository' --with-bugurl=https://bugs.archlinux.org/
--with-multilib-list=rmprofile
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Arch Repository)

Also tested with arm-linux-gnueabi-gcc 9.4.0-1ubuntu1~20.04.1 for Ubuntu 20.04
and arm-none-eabi-gcc 11.2.1 from https://developer.arm.com, which have the
same problem.

[Bug target/106554] -fstack-usage result too low for variadic function on Arm

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106554

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
IIRC there's target support code eventually missing for some targets.  The
-fstack-usage documentation isn't clear how exact the result is supposed to be.

[Bug target/106554] -fstack-usage result too low for variadic function on Arm

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106554

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-08-09

--- Comment #2 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> IIRC there's target support code eventually missing for some targets.  The
> -fstack-usage documentation isn't clear how exact the result is supposed to
> be.

It must always be conservatively correct, so it's certainly a bug.