|
|
 | | From: | Old Wolf | | Subject: | Spurious warning using bitfields in ADS 1.2 | | Date: | 19 Jan 2005 17:28:51 -0800 |
|
|
 | For the following code:
.. struct s
.. {
.. unsigned char foo1;
.. unsigned int bar1:8;
.. unsigned int bar2:24;
.. };
..
.. unsigned long foo(void)
.. {
.. struct s t1 = { 1, 2, 0x345678 };
..
.. return t1.bar2;
.. }
compiled with: armcc -S -fp -c foo.c
I get a warning:
"foo.c", line 12: Warning: C2888W: explicit cast to same type
Is this a compiler bug, and does it still generate
correct and efficient code?
Looking at the assembly file, the data is not allocated as
I expected (bar1 comes straight after foo1, and bar2 is at
offsets 4,5,6).
If I remove foo1 (or change it to foo1,foo2,foo3,foo4),
the warning goes away. Similarly if I use bar1 and not bar2.
Compiler is ADS1.2 build 842.
|
|
| | From: | Old Wolf | | Subject: | Re: Spurious warning using bitfields in ADS 1.2 | | Date: | 23 Jan 2005 12:21:02 -0800 |
|
|
| 42Bastian Schick wrote:
> On 20 Jan 2005 12:23:44 -0800, "Old Wolf"
> wrote:
>
> >> At first: Don't use bit-fields, they are highly incompatible.
> >> Second: What is it you want to do, accessing some kind of HW ?
> >
> >No, I wanted to save memory in the size of this struct.
> >Bit fields are a standard C feature and this compiler
> >is supposed to be ansi-compliant.
>
> This does only mean other do understand it, but they way they
> access it varies. The same code compiled with gcc for ARM and
> mc68030 differs in the way the bitfield is saved.
> 68030 can access unaligned and has instruction to extract bitfields,
> so it does not need to insert filler bytes.
Right. I am using the same code on an m68k platform which
has 2-byte alignment, so the bitfield does save space. It is
nice to have as few #if's as possible in the code, but I have
'solved' the problem for now by not using bitfields in the ARM
version.
|
|
| | From: | Old Wolf | | Subject: | Re: Spurious warning using bitfields in ADS 1.2 | | Date: | 20 Jan 2005 12:23:44 -0800 |
|
|
| 42Bastian Schick wrote:
> On 19 Jan 2005 17:28:51 -0800, "Old Wolf"
> wrote:
>
> >For the following code:
> >. struct s
> >. {
> >. unsigned char foo1;
> >. unsigned int bar1:8;
> >. unsigned int bar2:24;
> >. };
> >.
> >. unsigned long foo(void)
> >. {
> >. struct s t1 = { 1, 2, 0x345678 };
> >.
> >. return t1.bar2;
> >. }
> >
> >compiled with: armcc -S -fp -c foo.c
> >
> >I get a warning:
> >"foo.c", line 12: Warning: C2888W: explicit cast to same type
> >
> >Is this a compiler bug, and does it still generate
> >correct and efficient code?
> >Looking at the assembly file, the data is not allocated as
> >I expected (bar1 comes straight after foo1, and bar2 is at
> >offsets 4,5,6).
> >
> >If I remove foo1 (or change it to foo1,foo2,foo3,foo4),
> >the warning goes away. Similarly if I use bar1 and not bar2.
> >Compiler is ADS1.2 build 842.
>
> At first: Don't use bit-fields, they are highly incompatible.
> Second: What is it you want to do, accessing some kind of HW ?
No, I wanted to save memory in the size of this struct.
Bit fields are a standard C feature and this compiler
is supposed to be ansi-compliant.
(Note, the actual struct in my code has some more members
and using a bitfield does actually save space, even though
in this struct that I have posted, it does not save space)
> The warning makes sense to me, you are casting int to long, though it
> is in this case the same, it may differ on other machines.
I'm not casting int to anything. (If you're referring to
the return value, that is a conversion not a cast, and that
isn't the problem anyhow -- change the return type to something
else and see. Also, unsigned long is not the same type as
unsigned int).
That warning usually occurs if you write something like:
int *x;
y = (int *)x;
|
|
| | From: | Tauno Voipio | | Subject: | Re: Spurious warning using bitfields in ADS 1.2 | | Date: | Thu, 20 Jan 2005 21:58:04 GMT |
|
|
| Old Wolf wrote:
> 42Bastian Schick wrote:
>
>>On 19 Jan 2005 17:28:51 -0800, "Old Wolf"
>>wrote:
>>
>>
>>>For the following code:
>>>. struct s
>>>. {
>>>. unsigned char foo1;
>>>. unsigned int bar1:8;
>>>. unsigned int bar2:24;
>>>. };
>>>.
>
> No, I wanted to save memory in the size of this struct.
> Bit fields are a standard C feature and this compiler
> is supposed to be ansi-compliant.
> (Note, the actual struct in my code has some more members
> and using a bitfield does actually save space, even though
> in this struct that I have posted, it does not save space)
>
Please understand that you're not going to save any
in the struct, as the ARM is not able to directly access
unaligned fullwords, and the compiler has to put in
three fill bytes after foo1 to keep bar aligned.
With GCC, the structure can be squeezed together
with the __packed__ attribute, but the code accessing
the members is awful.
--
Tauno Voipio
tauno voipio (at) iki fi
|
|
| | From: | Wilco Dijkstra | | Subject: | Re: Spurious warning using bitfields in ADS 1.2 | | Date: | Thu, 20 Jan 2005 21:57:55 GMT |
|
|
|
"Old Wolf" wrote in message
news:1106252623.928248.55380@z14g2000cwz.googlegroups.com...
> 42Bastian Schick wrote:
> > On 19 Jan 2005 17:28:51 -0800, "Old Wolf"
> > wrote:
> >
> > >For the following code:
> > >. struct s
> > >. {
> > >. unsigned char foo1;
> > >. unsigned int bar1:8;
> > >. unsigned int bar2:24;
> > >. };
> > >.
> > >. unsigned long foo(void)
> > >. {
> > >. struct s t1 = { 1, 2, 0x345678 };
> > >.
> > >. return t1.bar2;
> > >. }
> > >
> > >compiled with: armcc -S -fp -c foo.c
> > >
> > >I get a warning:
> > >"foo.c", line 12: Warning: C2888W: explicit cast to same type
> > >
> > >Is this a compiler bug, and does it still generate
> > >correct and efficient code?
No it is not a compiler bug. Complicated expressions like bitfield
accesses have to be expanded internally and this may involve inserting
casts. In this case the cast was unnecessary and that is what triggered
the warning. Code generation is unaffected by warnings, but if you
don't like them you could stop using -fp.
> > At first: Don't use bit-fields, they are highly incompatible.
In practice bitfields are very portable as long as you know which
corner cases to avoid.
> Bit fields are a standard C feature and this compiler
> is supposed to be ansi-compliant.
Warnings fall outside the scope of the standard. Generating too few, too
many or spurious warnings doesn't affect compliance at all. Of course
compilers try to be as helpful as possible, but most generate spurious
warnings when you turn on warnings.
Wilco
|
|
| | From: | 42Bastian Schick | | Subject: | Re: Spurious warning using bitfields in ADS 1.2 | | Date: | Fri, 21 Jan 2005 05:56:17 GMT |
|
|
| On 20 Jan 2005 12:23:44 -0800, "Old Wolf"
wrote:
>> At first: Don't use bit-fields, they are highly incompatible.
>> Second: What is it you want to do, accessing some kind of HW ?
>
>No, I wanted to save memory in the size of this struct.
>Bit fields are a standard C feature and this compiler
>is supposed to be ansi-compliant.
This does only mean other do understand it, but they way they access
it varies.
The same code compiled with gcc for ARM and mc68030 differs in the way
the bitfield is saved.
68030 can access unaligned and has instruction to extract bitfields,
so it does not need to insert filler bytes.
>(Note, the actual struct in my code has some more members
>and using a bitfield does actually save space, even though
>in this struct that I have posted, it does not save space)
It saves only space if you obey the alignment rules for the ARM.
(This is maybe not new for you, but other sometimes get traped by this
esp. if they try to map structurs on data coming from outside the cpu
like IP frames etc.)
--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @epost.de instead !
|
|
| | From: | 42Bastian Schick | | Subject: | Re: Spurious warning using bitfields in ADS 1.2 | | Date: | Thu, 20 Jan 2005 10:32:24 GMT |
|
|
| On 19 Jan 2005 17:28:51 -0800, "Old Wolf"
wrote:
>For the following code:
>. struct s
>. {
>. unsigned char foo1;
>. unsigned int bar1:8;
>. unsigned int bar2:24;
>. };
>.
>. unsigned long foo(void)
>. {
>. struct s t1 = { 1, 2, 0x345678 };
>.
>. return t1.bar2;
>. }
>
>compiled with: armcc -S -fp -c foo.c
>
>I get a warning:
>"foo.c", line 12: Warning: C2888W: explicit cast to same type
>
>Is this a compiler bug, and does it still generate
>correct and efficient code?
>Looking at the assembly file, the data is not allocated as
>I expected (bar1 comes straight after foo1, and bar2 is at
>offsets 4,5,6).
>
>If I remove foo1 (or change it to foo1,foo2,foo3,foo4),
>the warning goes away. Similarly if I use bar1 and not bar2.
>Compiler is ADS1.2 build 842.
At first: Don't use bit-fields, they are highly incompatible.
Second: What is it you want to do, accessing some kind of HW ?
The warning makes sense to me, you are casting int to long, though it
is in this case the same, it may differ on other machines.
Allocation: Unless you tell the compiler to pack structures, it places
variables in a way to access them optimal.
In this case, the 24 bit var will be loaded as 32 bits. For this it
needs to be 4 aligned.
--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @epost.de instead !
|
|
|
