On Mon, Jan 14, 2019 at 10:00 AM H.J. Lu <hjl.to...@gmail.com> wrote:
>
> On Mon, Jan 14, 2019 at 6:22 AM Jakub Jelinek <ja...@redhat.com> wrote:
> >
> > On Sun, Jan 13, 2019 at 06:54:05AM -0800, H.J. Lu wrote:
> > > > What always matters is whether we take address of a packed structure
> > > > field/non-static data member or whether we just read that field.
> > > > The former should be warned about, the latter not.
> > > >
> > >
> > > How about this patch? It checks if address is taken with NOP.
> >
> > I'd like to first understand the convert_p argument to
> > warn_for_address_or_pointer_of_packed_member.
> >
> > To me it seems you want to emit two different warnings, perhaps one
> > surpressed if the other one is emitted, but you actually from the start
> > decide which of the two you are going to check for. That is just weird.
>
> convert_p is only for C.
>
> > Consider -O2 -Waddress-of-packed-member -Wno-incompatible-pointer-types:
> >
> > struct __attribute__((packed)) S { char p; int a, b, c; };
> >
> > int *
> > foo (int x, struct S *p)
> > {
> > return x ? &p->a : &p->b;
> > }
> >
> > int *
> > bar (int x, struct S *p)
> > {
> > return (int *) (x ? &p->a : &p->b);
> > }
> >
> > short *
> > baz (int x, struct S *p)
> > {
> > return x ? &p->a : &p->b;
> > }
> >
> > short *
> > qux (int x, struct S *p)
> > {
> > return (short *) (x ? &p->a : &p->b);
> > }
> >
> > This warns in foo, bar and qux, but doesn't warn in baz, because we've
> > decided upfront that that case is convert_p = true.
> >
> > I would have expected that the convert_p argument isn't passed at all,
> > the function always does the diagnostics about taking address that is
> > done with !convert_p right now, and either do the pointer -> pointer
> > conversion warning somewhere else (wherever we detect a pointer to pointer
> > conversion, even in the middle of expression?), or do it wherever you do
> > currently, but again always if the orig_rhs and type pointer types are
> > different.
> >
>
> When convert_p is true, we need to treat pointer conversion
> as a special case. I am testing this updated patch.
>
There are no regressions with this patch:
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00792.html
--
H.J.
