Re: [Xen-devel] [PATCH 1/2] x86/e820: fix build with gcc9

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Mar 07, 2019 at 11:46:08AM +0100, Roger Pau Monné wrote:
> On Thu, Mar 07, 2019 at 03:31:43AM -0700, Jan Beulich wrote:
> > e820.c: In function ‘clip_to_limit’:
> > .../xen/include/asm/string.h:10:26: error: ‘__builtin_memmove’ offset [-16, 
> > -36] is out of the bounds [0, 20484] of
> > object ‘e820’ with type ‘struct e820map’ [-Werror=array-bounds]
> >    10 | #define memmove(d, s, n) __builtin_memmove(d, s, n)
> >       |                          ^~~~~~~~~~~~~~~~~~~~~~~~~~
> > e820.c:404:13: note: in expansion of macro ‘memmove’
> >   404 |             memmove(&e820.map[i], &e820.map[i+1],
> >       |             ^~~~~~~
> > e820.c:36:16: note: ‘e820’ declared here
> >    36 | struct e820map e820;
> >       |                ^~~~
> > 
> > While I can't see where the negative offsets would come from, converting
> > the loop index to unsigned type helps. Take the opportunity and also
> > convert several other local variables and copy_e820_map()'s second
> > parameter to unsigned int (and bool in one case).
> 
> I also cannot see how you can end up with negative offsets, but
> changing to unsigned int is definitely and improvement IMO.

Gcc is becoming more and more aggressive in inferring what you mean with
your code. There are definitely bugs in that area.

This one comes to mind:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86827

Although I'm not sure if -Warray-bounds is the culprit in this case.

> 
> > Reported-by: Charles Arnold <carnold@xxxxxxxx>
> > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> 
> Thanks.

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