[Bug c/106920] -Warray-bound false positive regression with -O2 or -Os and constant address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106920 --- Comment #5 from Dominique Martinet --- 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!
[Bug c/106920] -Warray-bound false positive regression with -O2 or -Os and constant address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106920
--- Comment #4 from Richard Biener ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106920 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106920 --- Comment #2 from Dominique Martinet --- 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.
