From: Khem Raj <raj.khem@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: need help: cdrkit & bitifields
Date: Sat, 7 Mar 2009 01:37:40 -0800 [thread overview]
Message-ID: <200903070138.05252.raj.khem@gmail.com> (raw)
In-Reply-To: <ac9c93b10903051310g48c05d5eiaa6371f67383f7f1@mail.gmail.com>
On Thursday 05 March 2009 13:10:13 Frans Meulenbroeks wrote:
> 2009/3/5 Koen Kooi <k.kooi@student.utwente.nl>:
> > On 05-03-09 18:21, Frans Meulenbroeks wrote:
> >> Ucbit is an unsigned char
> >
> > unsigned char makes me think of
> > http://www.arm.linux.org.uk/docs/faqs/signedchar.php
> >
> > regards,
> >
> > Koen
>
> Well it is explictly defined as unsigned char.
> from utypes.h:
>
> /*
> * The IBM AIX C-compiler seems to be the only compiler on the world
> * which does not allow to use unsigned char bit fields as a hint
> * for packed bit fields. Define a pesical type to avoid warnings.
> * The packed attribute is honored wit unsigned int in this case too.
> */
> #if defined(_AIX) && !defined(__GNUC__)
>
> typedef unsigned int Ucbit;
>
> #else
>
> typedef unsigned char Ucbit;
>
> #endif
>
> The link you give is related to chars that are by default signed or
> unsigned
>
> This one seems to be related to whether bitfields are ordered left to
> right or right to left
> (and if I recall correctly in the ansi C standard this is undefined
> (but it has been a while since I checked)
>
> Decided to do some testing. On x86: gcc 4.3.2:
> frans@linux-suse:~/wt> cat tst.c
> #include <stdio.h>
>
> typedef struct {
> unsigned char bit0:1;
> unsigned char bits:6;
> unsigned char bit7:1;
> } bitfields;
>
> main(int argc, char **argv)
> {
> char c = 0xf0;
> bitfields *bf = &c;
>
> printf("bit 0 = %d, bits = %x, bit7 = %x\n", bf->bit0, bf->bits,
> bf->bit7); }
> frans@linux-suse:~/wt> gcc tst.c
> tst.c: In function ‘main’:
> tst.c:12: warning: initialization from incompatible pointer type
> frans@linux-suse:~/wt> ./a.out
> bit 0 = 0, bits = 38, bit7 = 1
> frans@linux-suse:~/wt> gcc -O1 tst.c
> tst.c: In function ‘main’:
> tst.c:12: warning: initialization from incompatible pointer type
> frans@linux-suse:~/wt> ./a.out
> bit 0 = 0, bits = 38, bit7 = 1
> frans@linux-suse:~/wt> gcc -O2 tst.c
> tst.c: In function ‘main’:
> tst.c:12: warning: initialization from incompatible pointer type
> frans@linux-suse:~/wt> ./a.out
> bit 0 = 0, bits = 1c, bit7 = 1
> frans@linux-suse:~/wt> gcc -O3 tst.c
> tst.c: In function ‘main’:
> tst.c:12: warning: initialization from incompatible pointer type
> frans@linux-suse:~/wt> ./a.out
> bit 0 = 0, bits = 1c, bit7 = 1
>
> Same test on beagle (gcc 4.3.1), -O0 -O1 -O2 -O3
> root@beagleboard:~# ./tst0
> bit 0 = 0, bits = 38, bit7 = 1
> root@beagleboard:~# ./tst1
> bit 0 = 0, bits = 38, bit7 = 1
> root@beagleboard:~# ./tst2
> bit 0 = 0, bits = 20, bit7 = 0
> root@beagleboard:~# ./tst3
> bit 0 = 0, bits = 20, bit7 = 0
>
> Not sure what is happening here.
> I tried to compile cdrkit with -O1 using
> FULL_OPTIMIZATION = "-O1"
> FULL_OPTIMIZATION_armv7a = "-O1"
> BUILD_OPTIMIZATION = "${FULL_OPTIMIZATION}"
> but that did not help either.
>
> There is a compile time macro in gcc called BITS_BIG_ENDIAN but that
> one is set to 0 for arm (same as for x86).
>
> Puzzled....
Frans
There is a gcc bug here you are seeing when you use higher opt level. But this
may not be cause of your problem here. You could try compiling with -Wcast-
align and see for any new warnings that will pop up. You then need to fix those
cases.
You could also try -Wpadded and see if any structure is getting implicit
padding.
Thx
-Khem
prev parent reply other threads:[~2009-03-07 9:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-05 17:21 need help: cdrkit & bitifields Frans Meulenbroeks
2009-03-05 18:26 ` Koen Kooi
2009-03-05 21:10 ` Frans Meulenbroeks
2009-03-06 9:03 ` Phil Blundell
2009-03-06 9:42 ` Frans Meulenbroeks
2009-03-06 15:08 ` Phil Blundell
2009-03-07 9:37 ` Khem Raj [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200903070138.05252.raj.khem@gmail.com \
--to=raj.khem@gmail.com \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.