[Bug c/106920] New: -Warray-bound false positive regression with -O2 or -Os

[Bug c/106920] New: -Warray-bound false positive regression with -O2 or -Os

[npfhrotynz-ptnqh.myvf at noclue dot notk.org]

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

            Bug ID: 106920
           Summary: -Warray-bound false positive regression with -O2 or
                    -Os
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: npfhrotynz-ptnqh.myvf at noclue dot notk.org
  Target Milestone: ---

Hello,

I think I've run into a false positive on this file:
https://source.codeaurora.org/external/imx/imx-atf/tree/plat/imx/imx8m/hab.c?h=lf_v2.6

I could trim it down to this
----
#include <stdint.h>

typedef void hab_rvt_entry_t(void);

int main() {
        hab_rvt_entry_t *a;
        a = ((hab_rvt_entry_t *)(*(unsigned long *)(0x908)));
        a();
        return 0;
}
----
$ gcc -O2 -Warray-bounds -c t.c
t.c: In function ‘main’:
t.c:7:34: warning: array subscript 0 is outside array bounds of ‘long unsigned
int[0]’ [-Warray-bounds]
    7 |         a = ((hab_rvt_entry_t *)(*(unsigned long *)(0x908)));
      |                                 ~^~~~~~~~~~~~~~~~~~~~~~~~~~
----

According to godbolt this passed on 11.3 and starts emitting the warning on
12.1 (it doesn't have 12.0) and still emits it on trunk.

Note the warning requires -O2, -O3 or -Os to be emitted.


The problem seems to be that it considers an arbitrary address casted to u64*
to be a u64[0] ?

If so that might be a problem for quite a few embedded products as that is
quite common when dealing with hardware registers.
(and who doesn't love products that compile with -Werror for release builds...)

Thanks!

[Bug c/106920] -Warray-bound false positive regression with -O2 or -Os

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-09-13
             Blocks|                            |56456
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed, that was an intended change to catch errors with accessing a
subobject of an object at nullptr.  There's some related duplicate where we
discuss workarounds.


Referenced Bugs:

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

[Bug c/106920] -Warray-bound false positive regression with -O2 or -Os and constant address

[npfhrotynz-ptnqh.myvf at noclue dot notk.org]

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

--- Comment #2 from Dominique Martinet <npfhrotynz-ptnqh.myvf at noclue dot notk.org> ---
Thanks for the very fast reply!

since you mentioned null pointers I now see this warning doesn't happen if I
try with a larger constant, I just had bad luck that imx-atf uses an address <
4k...?


I checked the first dozen of issues from the meta-bug (from start of open bugs
list to 86613 included), but there are just too many and didn't see a
workaround in the ones I did open.

I can see catching bad casts to be useful, but for low level hardware code
accessing register addresses directly is the norm -- I'm not too worried now
I've noticed the <4k "rule" but there really can't be any assumption made with
hardware, as seen here...
(And NXP isn't exactly great at working with external entities, I tried
reaching out for another compile fix with little success... but that's
offtopic.)

Well, good to understand the reason behind that warning at least.

[Bug c/106920] -Warray-bound false positive regression with -O2 or -Os and constant address

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is a deliberate change, dup of bug 105762.

If the address is a valid address, you can also pass --param=min-pagesize=0 to
say that all addresses are valid (see PR 99578).

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

[Bug c/106920] -Warray-bound false positive regression with -O2 or -Os and constant address

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
might be nice to have a way to declare a variable at a fixed address so the
code can become

extern hab_rvt_entry_p **entryptr __attribute__((at(0x908)));

int main() {
        hab_rvt_entry_t *a = *entryptr;
        a();
        return 0;
}

(I googled that some embedded compiler suppports 'at')

Note if you have a definition there's a workaround to declare the
variable in a custom section and use a linker script to place that
at a fixed address.  Still that doesn't allow the compiler to
optimize the access instructions.

We could honor the 'at' attribute when expanding the variable to RTL.

Such variables are going to be interesting for alias analysis btw,
so we should document it being undefined when a variables declared
with 'at' overlaps with another variable (or allocated object).

[Bug c/106920] -Warray-bound false positive regression with -O2 or -Os and constant address

[npfhrotynz-ptnqh.myvf at noclue dot notk.org]

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

--- Comment #5 from Dominique Martinet <npfhrotynz-ptnqh.myvf at noclue dot notk.org> ---
hmm this is a pretty complex topic.

My problem like pointed out in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 is more with all the legacy
code that I have to deal with, that isn't maintained by anyone, and well the
sorry state of embedded systems upstreams in general... So I'm really just
sitting there trying to get old code to keep working with my newer gcc version.

(I actually wonder why that didn't fail with gcc11, I've been using that for a
while...)

The solution in that other bug ^ to just not issue warnings for constant
addresses is good in general and I was just unlucky that such an address
happened below 4k for this code.
I don't understand why the ast tree cannot make the difference between a
constant address and a constant null pointer macroed to hell, but since that
only happens with optimizations enabled I guess some info is lost at that point
and there was nothing to do or it would have been done.

Anyway, I consider that closed, there's been enough ink spilled in the other
thread and thank you all for the quick replies!