[Bug c/116481] New: Compilation error caused by -Warray-bounds and -O2

[Bug c/116481] New: Compilation error caused by -Warray-bounds and -O2

[bruno at clisp dot org]

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

            Bug ID: 116481
           Summary: Compilation error caused by -Warray-bounds and -O2
           Product: gcc
           Version: 14.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 58999
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58999&action=edit
test case foo.c

The attached program, foo.c, is valid code but fails to compile when gcc is
given the arguments -Warray-bounds and -O2:

$ gcc -O2 -S foo.c
$ gcc -Warray-bounds -O1 -S foo.c
$ gcc -Warray-bounds -O2 -S foo.c
foo.c: In function ‘is_trampoline’:
foo.c:3:5: error: arrays of functions are not meaningful
    3 | int is_trampoline (void* function)
      |     ^~~~~~~~~~~~~
foo.c:7:84: warning: array subscript 0 is outside array bounds of ‘int[1]’
[-Warray-bounds=]
    7 |   return ((long *) ((char*)function - 2))[0] == ((long *)
((char*)tramp_address-2))[0];
      |                                                
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
foo.c:1:13: note: at offset -2 into object ‘tramp’ of size [0, 2147483647]
    1 | extern void tramp ();
      |             ^~~~~

Seen with several versions of gcc:

$ gcc --version
gcc (Gentoo 14.2.1_p20240817 p4) 14.2.1 20240817

$ gcc --version
gcc (Debian 13.2.0-8) 13.2.0

$ gcc --version
gcc (GCC) 13.1.0

[Bug tree-optimization/116481] Compilation error caused by -Warray-bounds and -O2

[bruno at clisp dot org]

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

--- Comment #1 from Bruno Haible <bruno at clisp dot org> ---
A workaround is to declare the local variable 'tramp_address' volatile:

========================= foo.c =========================
extern void tramp ();

int is_trampoline (void* function)
{
  void* volatile tramp_address = tramp;
  if (!(((unsigned long)function & 3) == 2)) return 0;
  return ((long *) ((char*)function - 2))[0] == ((long *)
((char*)tramp_address-2))[0];
}
=========================================================

Then the compilation succeeds.

[Bug tree-optimization/116481] Compilation error caused by -Warray-bounds and -O2

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |56456
             Target|hppa-linux-gnu              |*-*-*

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
hppa-linux-gnu uses


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug tree-optimization/116481] [12/13/14/15 Regression] Compilation error caused by -Warray-bounds and -O2

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |12.1.0
   Last reconfirmed|                            |2024-08-25
   Target Milestone|---                         |12.5
     Ever confirmed|0                           |1
           Keywords|                            |needs-bisection
             Status|UNCONFIRMED                 |NEW
            Summary|Compilation error caused by |[12/13/14/15 Regression]
                   |-Warray-bounds and -O2      |Compilation error caused by
                   |                            |-Warray-bounds and -O2
      Known to work|                            |11.1.0

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed. Note I think this code is undefined really unless you use the
volatile. Now we should not reject it though. The error message happens on
x86_64 also.

[Bug tree-optimization/116481] [12/13/14/15 Regression] `arrays of functions are not meaningful` error message happens with -W -Wall -O2 even though there are no arrays of function types used

[bruno at clisp dot org]

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

--- Comment #4 from Bruno Haible <bruno at clisp dot org> ---
(In reply to Andrew Pinski from comment #3)
> The error message happens on x86_64 also.

Indeed.

> Note I think this code is undefined really unless you use the volatile.

Why? This code is accessing read-only memory near the address of the 'tramp'
function. Why would it need 'volatile' when doing so? (I don't claim that this
is portable ISO C code; it's  doing a low-level thing. But C is meant to be
used for low-level things.)

[Bug tree-optimization/116481] [12/13/14/15 Regression] `arrays of functions are not meaningful` error message happens with -W -Wall -O2 even though there are no arrays of function types used

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Bruno Haible from comment #4)
> Why? This code is accessing read-only memory near the address of the 'tramp'
> function. Why would it need 'volatile' when doing so? (I don't claim that
> this is portable ISO C code; it's  doing a low-level thing. But C is meant
> to be used for low-level things.)

Because it is accessing before the begining of the function pointer.

>But C is meant to be used for low-level things.

There is still undefined behavior in C and accessing before the start of an
array (in this case the function pointer) is undefined. Standard C says
function pointers and other pointers don't need to be the same size or
otherwise and not convertable (though it is a requirement for POSIX). 

With  -pedantic-errors we get an error message due to this :):
```
<source>: In function 'is_trampoline':
<source>:5:25: error: ISO C forbids initialization between function pointer and
'void *' [-Wpedantic]
    5 |   void* tramp_address = tramp;
      |                         ^~~~~
```

[Bug tree-optimization/116481] [12/13/14/15 Regression] `arrays of functions are not meaningful` error message happens with -W -Wall -O2 even though there are no arrays of function types used

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
For portability you likely want to convert the function pointer to uintptr_t
and only that to char */long *.  That might also avoid GCCs diagnostic.

[Bug tree-optimization/116481] [12/13/14/15 Regression] `arrays of functions are not meaningful` error message happens with -W -Wall -O2 even though there are no arrays of function types used

[bruno at clisp dot org]

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

--- Comment #7 from Bruno Haible <bruno at clisp dot org> ---
(In reply to Richard Biener from comment #6)
> For portability you likely want to convert the function pointer to uintptr_t
> and only that to char */long *.  That might also avoid GCCs diagnostic.

Thanks for the attempted advice. But, no, converting a pointer to uintptr_t and
later back to a pointer is bad for portability: It does not work on the CHERI
architecture and its implementation on the ARM Morello chip
https://developer.arm.com/Architectures/Morello, because it loses the tag bits
that are essential for accessing the pointer. See
https://www.gnu.org/software/gnulib/manual/html_node/C99-features-avoided.html
and https://lists.gnu.org/archive/html/bug-gnulib/2023-12/msg00021.html .

[Bug tree-optimization/116481] [12/13/14/15 Regression] `arrays of functions are not meaningful` error message happens with -W -Wall -O2 even though there are no arrays of function types used

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

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

--- Comment #8 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Bruno Haible from comment #7)
> (In reply to Richard Biener from comment #6)
> > For portability you likely want to convert the function pointer to uintptr_t
> > and only that to char */long *.  That might also avoid GCCs diagnostic.
> 
> Thanks for the attempted advice. But, no, converting a pointer to uintptr_t
> and later back to a pointer is bad for portability: It does not work on the
> CHERI architecture and its implementation on the ARM Morello chip
> https://developer.arm.com/Architectures/Morello, because it loses the tag
> bits that are essential for accessing the pointer. See
> https://www.gnu.org/software/gnulib/manual/html_node/C99-features-avoided.
> html and https://lists.gnu.org/archive/html/bug-gnulib/2023-12/msg00021.html
> .

Related to the CHERI part: bug 111908

[Bug tree-optimization/116481] [12/13/14/15 Regression] `arrays of functions are not meaningful` error message happens with -W -Wall -O2 even though there are no arrays of function types used

[rsandifo at gcc dot gnu.org]

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

Richard Sandiford <rsandifo at gcc dot gnu.org> changed:

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

--- Comment #9 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
(In reply to Bruno Haible from comment #7)
> Thanks for the attempted advice. But, no, converting a pointer to uintptr_t
> and later back to a pointer is bad for portability: It does not work on the
> CHERI architecture and its implementation on the ARM Morello chip
> https://developer.arm.com/Architectures/Morello, because it loses the tag
> bits that are essential for accessing the pointer. See
> https://www.gnu.org/software/gnulib/manual/html_node/C99-features-avoided.
> html and https://lists.gnu.org/archive/html/bug-gnulib/2023-12/msg00021.html
> .
I think Richard's point still stands though.  Conversion to and from
(u)intptr_t does not in itself drop the tag bit.  CHERI/Morello (u)intptr_t can
hold exactly what a void* can hold.  If the tag bit is dropped by going out of
bounds, that's a feature, not a bug, and would happen equally for void*/char*
arithmetic as for (u)intptr_t arithmetic.

[Bug tree-optimization/116481] [12/13/14/15 Regression] `arrays of functions are not meaningful` error message happens with -W -Wall -O2 even though there are no arrays of function types used

[rsandifo at gcc dot gnu.org]

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

--- Comment #10 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
(In reply to Richard Sandiford from comment #9)
> If the tag bit is dropped by going
> out of bounds, that's a feature, not a bug, and would happen equally for
> void*/char* arithmetic as for (u)intptr_t arithmetic.
“out of bounds” here meaning “out of the representable bounds” of a capability
(as distinct from “out of the object's bounds”, which is checked at
dereference).