[Bug tree-optimization/104657] New: array subscript 0 is outside array bounds

[Bug tree-optimization/104657] New: array subscript 0 is outside array bounds

[christophm30 at gmail dot com]

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

            Bug ID: 104657
           Summary: array subscript 0 is outside array bounds
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: christophm30 at gmail dot com
  Target Milestone: ---

Compiling the following code:

void foo(unsigned long v)
{
        volatile unsigned long *p;
        p = (void *)0x8;
        *p = v;
}

with GCC master and "-O2 -Wall" results in the following warning:

$ gcc -O2 -Wall  -c array_subscript_0.c 
array_subscript_0.c: In function 'foo':
array_subscript_0.c:5:9: warning: array subscript 0 is outside array bounds of
'volatile long unsigned int[0]' [-Warray-bounds]
    5 |         *p = v;
      |         ^~

This warning is unexpected and is not triggered by earlier versions of GCC.

Possibly related: pr101977

[Bug tree-optimization/104657] array subscript 0 is outside array bounds

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup of bug 99578.

*** This bug has been marked as a duplicate of bug 99578 ***

[Bug tree-optimization/104657] array subscript 0 is outside array bounds

[christophm30 at gmail dot com]

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

--- Comment #2 from Christoph Müllner <christophm30 at gmail dot com> ---
Thanks for referencing pr99578.
Based on the information there, I created the following workaround:

void foo(unsigned long v)
{
        volatile unsigned long *p;
        p = (volatile unsigned long*)8;
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Warray-bounds"
        *p = v;
#pragma GCC diagnostic pop
}

[Bug tree-optimization/104657] array subscript 0 is outside array bounds

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

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

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
An alternate way of avoiding the warning in cases when the code is safe is to
make the pointer itself volatile, e.g., as below.  The codegen impact should be
negligible (an extra instruction on x86_.

static volatile unsigned long * const volatile p0x8 = (void*)8;

void bar(unsigned long v)
{
    *p0x8 = v;
}

As I mentioned in bug  99578 comment 25, on the AVR target GCC supports
attribute address which can be used to pin a declared object to a hardwired
address like so:

void bar(unsigned long v)
{
    extern volatile unsigned long x0x8 __attribute__ ((address (0x8)));

    x0x8 = v;
}

This avoids the warning and emits object code that's equivalent to the
original.

[Bug tree-optimization/104657] array subscript 0 is outside array bounds

[christophm30 at gmail dot com]

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

--- Comment #4 from Christoph Müllner <christophm30 at gmail dot com> ---
Thanks for mentioning the volatile pointer method.
However, the pragma-solution results in better code (fewer instructions and
does not require a valid stack pointer).

I've used the code below to see what happens on AArch64 and RISC-V 64-bit:
#define MEM_ADDR 0xffff8000
void foo_warning(unsigned long v)
{
        volatile unsigned long * p;
        p = (void*)MEM_ADDR;
        *p = v;
}

void foo_warningfree(unsigned long v)
{
        volatile unsigned long * p;
        p = (void*)MEM_ADDR;
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Warray-bounds"
        *p = v;
#pragma GCC diagnostic pop
}

void foo_volatile(unsigned long v)
{
        volatile unsigned long * volatile p;
        p = (void*)MEM_ADDR;
        *p = v;
}

AArch64:
foo_warning:
        mov     x1, 4294934528
        str     x0, [x1]
        ret
foo_warningfree:
        mov     x1, 4294934528
        str     x0, [x1]
        ret
foo_volatile:
        sub     sp, sp, #16
        mov     x1, 4294934528
        str     x1, [sp, 8]
        ldr     x1, [sp, 8]
        str     x0, [x1]
        add     sp, sp, 16
        ret

RISC-V 64-bit:
foo_warning:
        li      a5,536866816
        slli    a5,a5,3
        sd      a0,0(a5)
        ret
foo_warningfree:
        li      a5,536866816
        slli    a5,a5,3
        sd      a0,0(a5)
        ret
foo_volatile:
        li      a5,536866816
        addi    sp,sp,-16
        slli    a5,a5,3
        sd      a5,8(sp)
        ld      a5,8(sp)
        sd      a0,0(a5)
        addi    sp,sp,16
        jr      ra

[Bug tree-optimization/104657] array subscript 0 is outside array bounds

[christophm30 at gmail dot com]

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

--- Comment #5 from Christoph Müllner <christophm30 at gmail dot com> ---
Creating hard-wired object references might be a solution, but there is a lot
of existing code out there, that would need to be patched (including all the
hassle with support for old and new compilers).

One example is the bootloader U-Boot, which does the following for ARM ([1]):
    #define __arch_putl(v,a)            (*(volatile unsigned int *)(a) = (v))

Another example is Linux, where read*()/write*() and friends do the following
([2]):
    # define __iomem
    void foo_linux(unsigned long v)
    {
        void __iomem *p = (void __iomem *)MEM_ADDR;
        *(volatile unsigned long *)p = v;
    }

FWIW, the __iomem expands in Linux as follows ([3]), if the sources are passed
to the semantic parser "sparse" ([4]):
    # define __iomem        __attribute__((noderef, address_space(__iomem)))
That's similar to the AVR solution but allows to create user-defined distinct
types.

[1]
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/include/asm/io.h#L50
[2]
https://elixir.bootlin.com/linux/latest/source/include/asm-generic/io.h#L125
[3]
https://elixir.bootlin.com/linux/latest/source/include/linux/compiler_types.h#L11
[4]
https://git.kernel.org/pub/scm/devel/sparse/sparse.git/tree/Documentation/annotations.rst