Committed, testsuite: match warnings for attribute packed being ignored.

[Hans-Peter Nilsson]

> Date: Thu, 01 Dec 2005 14:59:47 +0000
> From: Nathan Sidwell <nathan@codesourcery.com>

> Hans-Peter Nilsson wrote:
> > The attribute then has no effect and is totally harmless.  It
> > has effect on other arches.  So, the warning is spurious for
> > arches where the field is already packed.
> 
> I'm sorry, but i see attempting to pack a type whose alignment is already a byte 
> to be akin to writing '0;'.

You didn't address the point that this attribute is likely to be
used on sources across multiple architectures and ABI:s, where
the packed attribute should be all "tailoring" that's needed.

But as long as the warning is *only on wrong usage* like in
fp-bit (pack the struct, not the field), I'm not going to
continue arguing.

> > /tmp/f.c:11: warning: 'packed' attribute ignored for field of type 'struct <anonymous>'
> 
> yes, that's because you've asked for the 'bits' field of FLO_union_type to be 
> packed.  To ask for struct <anonymous> itself to be packed you need to write
> 
> typedef union
> {
>   int value;
> 
>    struct __attribute__((packed))
>     {
>       int fraction:24;
>        unsigned int exp:7;
>        unsigned int sign:1;
>      }
>    bits;
> }
> FLO_union_type;
> 
> which does not give a warning on cris.

Ah, so there *is* a usage bug in fp-bit!  Ok then, I guess.

> >>(c) use the fine grained warning control.
> > Um, this warning is *on by default*.
> I don't see how that's relevent to fine grained warning control.

It's relevant to *fine-grained-control* because it's coupled
with warnings heavy-weight enough to be on by default.

It's relevant to *packed handling* because that's where the
warning is emitted from, and you chose the heavy-weight option.

brgds, H-P