https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
--- Comment #25 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #24)
> (In reply to Martin Sebor from comment #1)
> > The warning is by design.
>
> That just means the design is bad. Especially in the embedded world, using
> memory mapped IO at fixed addresses is very common and we really shouldn't
> force
> people to pessimize their code by adding volatile on the pointers etc.
No, the design is perfectly fine: it enforces the constraint in the standard
that require pointers to point to live objects when they're used.
Implementations can impose less restrictive constraints and implement behavior
the standard leaves undefined by providing extensions. But to distinguish the
two kinds of behavior they need to document the extensions. Failing to do that
only leads to confusion and bugs (this code worked just fine in version X of
GCC but version Y broke it!)
Following this simple approach not only improves the quality of the
implementation but also helps guide decisions about what's helpful to diagnose
and what should be silently accepted.
> > Its purpose is to detect invalid accesses at
> > non-zero offsets to null pointers, like in the memset call below:
> >
> > struct S { int a, b[4]; };
> >
> > void f (struct S *p)
> > {
> > if (p) return;
> > memset (p->b, 0, 4 * sizeof p->b);
> > }
> >
> > For now, I recommend suppressing the warning either by #pragma GCC
> > diagnostic or by making the pointer volatile. In the future, providing an
> > attribute to annotate constant addresses with (or extending the io()
> > attribute supported by some targets to all targets) might be another way to
> > avoid it.
>
> Then perhaps just add some flag on the INTEGER_CSTs created from folding
> &ptr->member into constant (seems currently that happens during {,e}vrp and
> dom) and only in the spots you warn if the INTEGER_CST has that flag set?
In my opinion, code that deliberately uses invalid pointers (e.g., hardwired
addresses) should be explicitly annotated, e.g., by some attribute. This
approach has at least two advantages: 1) it makes the intent clear to the
reader, and 2) by declaring the object it lets GCC enforce type safety as well
as check for out-of-bounds access to it. GCC already provides two such
attributes: the AVR address and io attributes. Rather than relying on
heuristics I would suggest to make the address attribute (or one like it)
available on all targets and use it for this purpose. (I started working on it
last November but didn't finish it.)
