sparse warnings for variable length arrays

sparse warnings for variable length arrays

[Heiko Carstens]

Hi all,

in include/asm-s390/bitops.h we have several typedefs:

typedef struct { long _[__BITOPS_WORDS(size)]; } addrtype;

sparse warns about these with "error: bad constant expression".
Is there any way to tell sparse to be quiet? __force doesn't seem to work.

Re: sparse warnings for variable length arrays

[Dave Jones]

On Thu, Jul 13, 2006 at 10:58:08AM +0200, Heiko Carstens wrote:
 > Hi all,
 > 
 > in include/asm-s390/bitops.h we have several typedefs:
 > 
 > typedef struct { long _[__BITOPS_WORDS(size)]; } addrtype;
 > 
 > sparse warns about these with "error: bad constant expression".
 > Is there any way to tell sparse to be quiet? __force doesn't seem to work.

In many cases, these turn up as on-stack variables.  It'd be
nice if sparse could figure out the maximum potential bound
and warn appropriately if they could reach $BIGSIZE.

For non-stack vars, it's less of an issue of course.

		Dave

-- 
http://www.codemonkey.org.uk

Re: sparse warnings for variable length arrays

[Martin Schwidefsky]

On Thu, 2006-07-13 at 13:01 -0400, Dave Jones wrote:
> On Thu, Jul 13, 2006 at 10:58:08AM +0200, Heiko Carstens wrote:
>  > Hi all,
>  > 
>  > in include/asm-s390/bitops.h we have several typedefs:
>  > 
>  > typedef struct { long _[__BITOPS_WORDS(size)]; } addrtype;
>  > 
>  > sparse warns about these with "error: bad constant expression".
>  > Is there any way to tell sparse to be quiet? __force doesn't seem to work.
> 
> In many cases, these turn up as on-stack variables.  It'd be
> nice if sparse could figure out the maximum potential bound
> and warn appropriately if they could reach $BIGSIZE.

The reason why I introduced the typedef was a bug that had its cause in
an on-stack bit field (actually is has been a single unsigned long) that
was passed to one of find_bit functions. The old find_bit inlines did
not tell the compiler that the content of the on-stack bit field is
accessed, just the address to it was passed and ther has been a "memory"
clobber. The "memory" clobber works fine with bit fields that are not on
the stack, it forces the compiler to write everything to memory before
calling the inline. For on-stack bit fields things look different, the
old inline did not inform the compiler that the content of the local
variable is accessed, only the address of a local variable is needed. If
no other code in the scope of the local variable accesses the content of
the bitfield the surprising conclusion of gcc is that since nobody
accesses the content it can remove the initialization of it and the
stack slot for it as well. gcc just passed the inline an address
pointing to nothing.

In short, we need the typedef (or something equivalent). Sparse reports
a false positive.

> For non-stack vars, it's less of an issue of course.

Even for non-stack variables the typedef makes sense. By telling the
compiler exactly what is accessed by the inline you don't need the
"memory" clobber anymore. The inlines of the s390 find_xxx_bit functions
do not have it. That allows the compiler to optimize a little bit
better.

-- 
blue skies,
  Martin.

Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH

"Reality continues to ruin my life." - Calvin.