[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 7/7] tools/kdd: mute spurious gcc warning



Hi,

At 16:32 +0200 on 06 Apr (1523032362), Marek Marczykowski-Górecki wrote:
> On Fri, Apr 06, 2018 at 09:56:05AM -0400, Boris Ostrovsky wrote:
> > Can we instead pre-compute the pointer to pacify the compiler? I haven't
> > seen the original error so I can't test it, but something like
> 
> Nope, it doesn't help. But adding "if (offset > 0)" before that "+=
> offset" does... 
> For me it looks like a gcc bug. Not sure how to deal with this. Enclose
> #pragma with #if __GNUC__ >= 8 ?

If the logic can be reshuffled so that gcc8 is happy with, that would
be better than silencing the warning, IMO.  As far as I can see the
pointer is indeed safe[1], and if the compiler's going to decide
that it's not, I'd rather have the warning than have it silently
optimized out.

Cheers,

Tim.

[1] except a possible memcpy(dst, one-past-the-end-of-the-struct, 0),
    which is not what's being complained of here, and is a good deal
    too theological for me while I'm on my holiday.

> > diff --git a/tools/debugger/kdd/kdd.c b/tools/debugger/kdd/kdd.c
> > index 61d769e..1b048ac 100644
> > --- a/tools/debugger/kdd/kdd.c
> > +++ b/tools/debugger/kdd/kdd.c
> > @@ -688,6 +688,7 @@ static void kdd_handle_read_ctrl(kdd_state *s)
> >      } else {
> >          /* 32-bit control-register space starts at 0x[2]cc, for 84 bytes */
> >          uint64_t offset = addr;
> > +        void *ptr = &ctrl.c32;
> >          if (offset > 0x200)
> >              offset -= 0x200;
> >          offset -= 0xcc;
> > @@ -695,10 +696,8 @@ static void kdd_handle_read_ctrl(kdd_state *s)
> >              KDD_LOG(s, "Request outside of known control space\n");
> >              len = 0;
> >          } else {
> > -#pragma GCC diagnostic push
> > -#pragma GCC diagnostic ignored "-Warray-bounds"
> > -            memcpy(buf, ((uint8_t *)&ctrl.c32) + offset, len);
> > -#pragma GCC diagnostic pop
> > +            ptr += offset;
> > +            memcpy(buf, ptr, len);
> >          }
> >      }
> >  
> > -boris
> 
> -- 
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.