Re: [Tinycc-devel] TinyCC 0.9.26 released
> > > At least for future reference, you should have given an URL to > > > download the source code (e.g. as a .tar.gz file) and preferably, > > > some hash code (e.g. MD5 or SHA1) of it. > > > > Same for me. I found > > http://download.savannah.gnu.org/releases/tinycc/ but I'm not sure > > that's the right place. A GPG signature would be welcome too :) > > Right right. When I sent the email the binaries were not uploaded yet. > > So here are some checksum: > > MD5: 5fb28e4abc830c46a7f54c1f637fb25d > SHA1: 7110354d3637d0e05f43a006364c897248aed5d0 > SHA256: > 521e701ae436c302545c3f973a9c9b7e2694769c71d9be10f70a2460705b6d71 > > See attached the corresponding gpg signature. Thanks! > > One more little thing: the http://tinycc.org/ web site (that > > redirects to http://bellard.org/tcc/) does not mention the last > > release. Maybe the website could be updated to mention that tcc is > > still maintained and a new version was released? > > This website belongs to Fabrice Bellard and as such neither Grischka > nor me can modify it. I sent an email to Fabrice just after the > announce to notify him about the release and ask him to update his > website. I haven't got any answer yet so I guess he simply didn't > read the mail yet. OK, that's fine. Regards, Didier signature.asc Description: PGP signature ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyCC 0.9.26 released
> > Greetings everybody, > > > > it is my pleasure to finally announce the release of TinyCC 0.9.26. > > This release has been longer than previously to come along but it's > > finally here. > > Bravo! You did a very good job for the release! > At least for future reference, you should have given an URL to > download the source code (e.g. as a .tar.gz file) and preferably, > some hash code (e.g. MD5 or SHA1) of it. Same for me. I found http://download.savannah.gnu.org/releases/tinycc/ but I'm not sure that's the right place. A GPG signature would be welcome too :) One more little thing: the http://tinycc.org/ web site (that redirects to http://bellard.org/tcc/) does not mention the last release. Maybe the website could be updated to mention that tcc is still maintained and a new version was released? Regards, Didier signature.asc Description: PGP signature ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Thomas, > Le jeudi 24 janvier 2013 11:35:30, Thomas Preud'homme a écrit : > > > > I finally got around to look in this last failure. I just started > > but the good news is that it's limited to the -run function. There > > is no problem when compiling the example. Objdump shows it's the > > exact same code in both case. So it's probably a relocation bug. > > Ok got it. Fix attached. I'm not sure about the comments though, as I > don't have all the details in my mind. Let me explain a bit what's > going on and you might have idea about the details. Worked for me. Thank you for the fix! $ git pull ... From git://repo.or.cz/tinycc e92dbe4..de35a33 mob-> origin/mob Updating e92dbe4..de35a33 ... $ gcc --version gcc (Gentoo 4.6.3 p1.9, pie-0.5.2) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ ./configure --prefix=/usr/local/ && make clean all test (all tests passed) $ su # make install # exit $ CC=/usr/local/bin/tcc LD=/usr/local/bin/tcc ./configure \ --prefix=/usr/local/ $ make clean all test CC=/usr/local/bin/tcc LD=/usr/local/bin/tcc (all tests passed) $ su # make install # exit $ CC=/usr/local/bin/tcc LD=/usr/local/bin/tcc ./configure \ --prefix=/usr/local/ $ make clean all test CC=/usr/local/bin/tcc LD=/usr/local/bin/tcc (all tests passed) Regards, Didier signature.asc Description: PGP signature ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Thomas, > I finally got around to look in this last failure. I just started but > the good news is that it's limited to the -run function. There is no > problem when compiling the example. Objdump shows it's the exact same > code in both case. So it's probably a relocation bug. > > Thanks again for all your tests. As you saw, you helped fixing many > bugs. You're welcome! Regards, Didier signature.asc Description: PGP signature ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
> Hi Olivier, My name's Didier :) > > === Build of TCC GIT with GCC 4.0.4 === > > > > Build failed because of -Wno-unused-result being unknown. > > > > [...] > > > > === Build of TCC GIT with GCC 4.1.2 === > > > > Build failed because of -Wno-unused-result being unknown. > > > > [...] > > > > === Build of TCC GIT with GCC 4.3.6 === > > > > Build failed because of -Wno-unused-result being unknown. > > > > [...] > > Can you try thi fix in eb028a8f423d2623cc174ab4d3c5a80fd8efbdde ? If > you have access to llvm, can you give me its output to -dumpversion ? Build and tests are now OK for GCC 4.0.4, 4.1.2, and 4.3.6. Thanks! > > === Build of TCC GIT with Clang 3.2 === > > > > Build OK (with some warnings, I can provide them to you if you > > want). > > > > Tests KO (see traces below). > > > > libtest > > ./libtcc_test lib_path=.. > > Hello World! > > fib(32) = 2178309 > > add(32, 64) = 96 > > cp ../include/tcclib.h . > > /usr/bin/clang -o tcctest.gcc tcctest.c -I. -I. > > -I/home/didier/documents/tech/dev/tcc/tinycc -w -Wall -g -O2 > > -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare > > -Wno-unused-result -mpreferred-stack-boundary=2 -march=i386 > > -falign-functions=0 -m32 -DTCC_TARGET_I386 -std=gnu99 -O0 > > -fno-omit-frame-pointer > > tcctest.c:2585:3: error: void function 'cmp_comparison_test' should > > not ret urn a value [-Wreturn-type] return 0; > > ^ ~ > > 1 error generated. > > make[1]: *** [test.ref] Error 1 > > make[1]: Leaving directory > > `/home/didier/documents/tech/dev/tcc/tinycc/test s' make: *** > > [test] Error 2 > > Fixed in mob. I confirm. Regards, Didier signature.asc Description: PGP signature ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Thomas, > In preparation of the upcoming release of tinycc 0.9.26, I would like > to have reports about how tcc build and works to be sure it is as > stable as possible.I tried quickly on my arm machine and will > continue to do experiment on that machine and my amd64 machine but > I'd welcome any test from other people with different usage. In > particular, I would appreciate to have people build tcc for other > platform than Linux, for instance Windows (Grishka ;) or Mac OS (I > think there was some work to make tcc work on Mac OS but I'm not > sure). I performed some tests on a Linux x86 system with the various compilers available on that system. For all tests, GIT revision was fc574f14984d11f1ead50560d1bdc5ae0eaf6d8d === Build of TCC GIT with GCC 4.0.4 === Build failed because of -Wno-unused-result being unknown. /usr/bin/gcc-4.0.4 -o tcc.o -c tcc.c -DTCC_TARGET_I386 -I. -I/home/didier/documents/tech/dev/tcc/tinycc -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32 cc1: error: unrecognized command line option "-Wno-unused-result" make: *** [tcc.o] Error 1 === Build of TCC GIT with GCC 4.1.2 === Build failed because of -Wno-unused-result being unknown. /usr/bin/gcc-4.1.2 -o tcc.o -c tcc.c -DTCC_TARGET_I386 -I. -I/home/didier/documents/tech/dev/tcc/tinycc -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32 cc1: error: unrecognized command line option "-Wno-unused-result" make: *** [tcc.o] Error 1 === Build of TCC GIT with GCC 4.3.6 === Build failed because of -Wno-unused-result being unknown. /usr/bin/gcc-4.3.6 -o tcc.o -c tcc.c -DTCC_TARGET_I386 -I. -I/home/didier/documents/tech/dev/tcc/tinycc -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32 cc1: error: unrecognized command line option "-Wno-unused-result" make: *** [tcc.o] Error 1 === Build of TCC GIT with GCC 4.4.7 === Build OK. Tests OK. === Build of TCC GIT with GCC 4.5.4 === Build OK. Tests OK. === Build of TCC GIT with GCC 4.6.3 === Build OK. Tests OK. === Build of TCC GIT with GCC 4.7.2 === Build OK. Tests OK. === Build of TCC GIT with Clang 3.2 === Build OK (with some warnings, I can provide them to you if you want). Tests KO (see traces below). libtest ./libtcc_test lib_path=.. Hello World! fib(32) = 2178309 add(32, 64) = 96 cp ../include/tcclib.h . /usr/bin/clang -o tcctest.gcc tcctest.c -I. -I. -I/home/didier/documents/tech/dev/tcc/tinycc -w -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32 -DTCC_TARGET_I386 -std=gnu99 -O0 -fno-omit-frame-pointer tcctest.c:2585:3: error: void function 'cmp_comparison_test' should not return a value [-Wreturn-type] return 0; ^ ~ 1 error generated. make[1]: *** [test.ref] Error 1 make[1]: Leaving directory `/home/didier/documents/tech/dev/tcc/tinycc/tests' make: *** [test] Error 2 With the 'return' statement removed from the cmp_comparison_test() function, tests seem to be still KO. Example with 'test1': test1 ../tcc -B.. -DTCC_TARGET_I386 -run tcctest.c > test.out1 --- test.ref2013-01-06 10:59:06.0 +0100 +++ test.out1 2013-01-06 10:59:06.0 +0100 @@ -299,7 +299,7 @@ sizeof(+(char)'a') = 4 sizeof(-(char)'a') = 4 sizeof(~(char)'a') = 4 --66 -66 -66 -66 4294967230 4294967230 +-66 -66 -66 -66 -66 -66 0x1 0xf0f0 (nil) 0xfff0 bitfield_test:sizeof(st1) = 8 3 -1 15 -8 121 I can do other tests and/or try patches to fix that problem if you want. === Build of TCC GIT with TCC GIT === Build OK. Tests KO. make -C tests2 test make[1]: Entering directory `/home/didier/documents/tech/dev/tcc/tinycc/tests2' Test: 00_assignment... Test: 01_comment... Test: 02_printf... Test: 03_struct... Test: 04_for... Test: 05_array... Test: 06_case... Test: 07_function... Test: 08_while... Test: 09_do_while... Test: 10_pointer... Test: 11_precedence... Test: 12_hashdefine... Test: 13_integer_literals... Test: 14_if... Test: 15_recursion... Test: 16_nesting... Test: 17_enum... Test: 18_include... Test: 19_pointer_arithmetic... Test: 20_pointer_comparison... Test: 21_char_array... Test: 22_floating_point... Test: 23_type_coercion... Test: 24_math_library... Test: 25_quicksort... Test: 26_character_constants... Test: 27_sizeof... Test: 28_strings... /bin/sh: line 5: 5741 Segmentation fault ../tcc -B.. -run 28_strings.c 2>&1 > 28_strings.output make[1]: *** [28_strings.test] Error 139 make[1]: Leaving directory `/home/didier/documents/tech/dev/tcc/tinycc/tests2' make: *** [test] Error 2 I can do other tests and/or try patches to fix that problem if you want. === Build of ROHC
Re: [Tinycc-devel] question about bit-fields
> > The 2 first fields uses 1 byte with GCC/Clang while they use > > sizeof(unsigned int) bytes with TCC. GCC/Clang pack the bit fields > > on the smaller type available. So, sizeof(struct mystruct1) = 4 with > > GCC/Clang and sizeof(struct mystruct1) = 8 with TCC. > > I tried your "bitfield.c" test with GCC and it failed on the 2nd > assertion. Hm ... Arf, I did a mistake :( I started my tests with GCC and my modified TCC, it worked. Then I enhanced the test to cover additional cases, and I forgot to test again with GCC. So my TCC patch is not always conform to GCC behaviour... I'll update my patch. Sorry for the noise grischka. Regards, Didier signature.asc Description: PGP signature ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] question about bit-fields
> This was the very first patch that I ever wrote to tcc. Except I > didn't make it optional. I never submitted it because of that. > > Being able to pack data the same way that GCC (and MSVC for that > matter) does is very useful, especially in network code. Granted that > "officially" I think this is considered an implementation detail by > the various C standards. Thank you Michael, I feel less alone :) Please send your patch, it may be better than mine. Or maybe we can create a third patch from ours and mine. Regards, Didier signature.asc Description: PGP signature ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] question about bit-fields
Grischka,
> > Please find attached, a patch that modify TCC so that it can pack
> > bit fields the way GCC does. The mechanism is optional and off by
> > default. It can be enabled with the -fgcc-packing option.
>
> ... the way GCC does?
>
> > I added this mechanism because I want to use TCC to compile some
> > code that manages IPv4 headers [1]. The code uses the 'struct
> > iphdr' of the GNU libc, and relies on its size doing exactly 20
> > bytes. TCC does not compute the structure length the same way GCC
> > does, and the program fails.
>
> ... the same way GCC does?
>
> > Someone told me that I can add code to mimic the behaviour of GCC.
> > The attached patch is an attempt to do so. It is probably not very
> > good as I didn't known TCC's codebase before, but it seems to work.
> > I'm open for comments on it. I tested my modifications with the
> > attached test program.
>
> ... to mimic the behavior of GCC?
>
> Just curious: What now is this way/behavior of GCC, actually?
>
> Because as you say, maybe the patch is not very good (e.g. suspicious
> "copy & paste" portion) but you didn't know TCC before.
>
> Then again maybe some people here know TCC but still can't really
> comment your patch or suggest improvements because they don't know
> the details about GCC's bit packing right now.
Sorry, it was discussed in previous emails, but I forgot to repeat it.
Here are some more details.
On a structure such as:
struct mystruct1
{
unsigned int mystruct1_foo:4;
unsigned int mystruct1_bar:4;
uint8_t mystruct1_other;
uint16_t mystruct1_other2;
};
The 2 first fields uses 1 byte with GCC/Clang while they use
sizeof(unsigned int) bytes with TCC. GCC/Clang pack the bit fields on
the smaller type available. So, sizeof(struct mystruct1) = 4 with
GCC/Clang and sizeof(struct mystruct1) = 8 with TCC.
My program (and probably many others, as the struct iphdr for IPv4
header defined by the GNU libc is defined that way) relies on this
behaviour. That's why I created the patch. It packs bit fields "the way
GCC does". If you got a better description, I'll be happy to change
it :)
Regards,
Didier
signature.asc
Description: PGP signature
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] question about bit-fields
Hello all,
> > > If one changes anything at all then it only makes sense to change
> > > it so as to be layout compatible with GCC. A third layout (GCC,
> > > TCC-old, TCC-new) wouldn't help. Although the rules of GCC are
> > > relatively obscure and complex in corner cases.
> >
> > Actually I have to correct myself here. After studying the layout
> > code a bit I see that TCC implements mostly microsoft's bit-field
> > layout. We don't want to get rid of that capability, so GCCs layout
> > (which is PCC layout for i386 and arm AAPCS, and funky layout for
> > legacy arm) would have to be implemented in addition.
>
> OK, I'll give it a try during the next week.
Hum, 'next week' is well over, but here is the patch! :)
Please find attached, a patch that modify TCC so that it can pack bit
fields the way GCC does. The mechanism is optional and off by default.
It can be enabled with the -fgcc-packing option.
I added this mechanism because I want to use TCC to compile some code
that manages IPv4 headers [1]. The code uses the 'struct iphdr' of the
GNU libc, and relies on its size doing exactly 20 bytes. TCC does not
compute the structure length the same way GCC does, and the program
fails.
Someone told me that I can add code to mimic the behaviour of GCC. The
attached patch is an attempt to do so. It is probably not very good as
I didn't known TCC's codebase before, but it seems to work. I'm open
for comments on it. I tested my modifications with the attached test
program.
Regards,
Didier
[1] http://rohc-lib.org/
diff --git a/libtcc.c b/libtcc.c
index b0a9b1a..721b20b 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1023,6 +1023,7 @@ LIBTCCAPI TCCState *tcc_new(void)
#if defined(TCC_TARGET_PE) && 0
s->leading_underscore = 1;
#endif
+s->gcc_packing = 0;
if (s->section_align == 0)
s->section_align = ELF_PAGE_SIZE;
#ifdef TCC_TARGET_I386
@@ -1414,6 +1415,7 @@ static const FlagDef flag_defs[] = {
{ offsetof(TCCState, char_is_unsigned), FD_INVERT, "signed-char" },
{ offsetof(TCCState, nocommon), FD_INVERT, "common" },
{ offsetof(TCCState, leading_underscore), 0, "leading-underscore" },
+{ offsetof(TCCState, gcc_packing), 0, "gcc-packing" },
};
/* set/reset a flag */
diff --git a/tcc-doc.texi b/tcc-doc.texi
index 4d4a029..a74f84f 100644
--- a/tcc-doc.texi
+++ b/tcc-doc.texi
@@ -239,6 +239,9 @@ Do not generate common symbols for uninitialized data.
@item -fleading-underscore
Add a leading underscore at the beginning of each C symbol.
+@item -fgcc-packing
+Pack bit fields the way GCC does.
+
@end table
Warning options:
diff --git a/tcc.h b/tcc.h
index 8bca9ae..2ee977f 100644
--- a/tcc.h
+++ b/tcc.h
@@ -567,7 +567,8 @@ struct TCCState {
/* C language options */
int char_is_unsigned;
int leading_underscore;
-
+int gcc_packing;
+
/* warning switches */
int warn_write_strings;
int warn_unsupported;
diff --git a/tccgen.c b/tccgen.c
index 7295267..41db5ba 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -2740,6 +2740,7 @@ static void struct_decl(CType *type, int u)
prevbt = VT_INT;
bit_pos = 0;
offset = 0;
+int bf_req_size = -1;
while (tok != '}') {
parse_btype(&btype, &ad);
while (1) {
@@ -2770,7 +2771,7 @@ static void struct_decl(CType *type, int u)
if (ad.aligned) {
if (align < ad.aligned)
align = ad.aligned;
-} else if (ad.packed) {
+} else if (ad.packed || tcc_state->gcc_packing == 1) {
align = 1;
} else if (*tcc_state->pack_stack_ptr) {
if (align > *tcc_state->pack_stack_ptr)
@@ -2820,11 +2821,32 @@ static void struct_decl(CType *type, int u)
/* add new memory data only if starting
bit field */
if (lbit_pos == 0) {
+/* pack bit-fields the same way GCC does */
+if (tcc_state->gcc_packing == 1 && bf_req_size > 0) {
+if (bf_req_size <= 8)
+bf_req_size = 8;
+else if (bf_req_size <= 16)
+bf_req_size = 16;
+else if (bf_req_size <= 32)
+bf_req_size = 32;
+else
+tcc_error("bitfield larger than 32 bits");
+c += bf_req_size / 8;
+}
+bf_req_size = bit_size;
+
if (a == TOK_STRUCT) {
c = (c + align - 1) & -align;
offset = c;
-if (size > 0)
-
[Tinycc-devel] segfault with static array initialized by a macro
Hello all,
In encountered what seems to be a bug in TCC (git revision
ad5f3758c38f2364f03205dcb9fd48142d2d4499). I narrowed it down to the
following test case.
$ cat segfault_with_static_array.c
#include
#define LENGTH1 10
#define LENGTH2 20
#define max(a, b) (((a) > (b)) ? (a) : (b))
int main(int argc, char *argv[])
{
static unsigned char data[max(LENGTH1, LENGTH2)];
printf("max(%d, %d) = %d\n", LENGTH1, LENGTH2, max(LENGTH1,
LENGTH2)); printf("data = %p\n", data);
data[0] = 0x42;
return 0;
}
$ tcc -o segfault_with_static_array -Wall -Werror \
segfault_with_static_array.c
$ ./segfault_with_static_array
max(10, 20) = 20
data = (nil)
Erreur de segmentation
$ echo $?
139
The program above works with GCC 4.5, GCC 4.6, GCC 4.7 and Clang 3.1.
It does not fail with TCC if I do not use the max() macro or remove the
'static' keyword for the 'data' array.
Regards,
Didier
signature.asc
Description: PGP signature
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] question about bit-fields
Hi, > > If one changes anything at all then it only makes sense to change > > it so as to be layout compatible with GCC. A third layout (GCC, > > TCC-old, TCC-new) wouldn't help. Although the rules of GCC are > > relatively obscure and complex in corner cases. > > Actually I have to correct myself here. After studying the layout > code a bit I see that TCC implements mostly microsoft's bit-field > layout. We don't want to get rid of that capability, so GCCs layout > (which is PCC layout for i386 and arm AAPCS, and funky layout for > legacy arm) would have to be implemented in addition. OK, I'll give it a try during the next week. Regards, Didier signature.asc Description: PGP signature ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] question about bit-fields
> > Is there an option or a declaration to make tcc compute the expected > > length for unsigned-int-based bit fields? > > No, there isn't. > > AFAIK the C standard says this is implementation-defined. > For portability don't use bitfields. Thank for your answer. I see the problem. I added a check for this compiler's behaviour in my configure script. The code of my example is a reduced version of struct iphdr defined by GNU libc's netinet/ip.h. It means that every programs using the GNU libc's IPv4 header (or its BSD variant) cannot work fine if built with tinycc. Regards, Didier signature.asc Description: PGP signature ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] question about bit-fields
Hello all,
I'm trying to build my project with tcc (yesterday's git version). It
succeeds without any required change (cool!), but tests fail :(
I narrowed the problem to bit-fields, and more especially to the length
of some bit-fields. I created a small test program to explain the
problem:
$ cat test.c
#include
struct data
{
unsigned int foo:4;
unsigned int bar:4;
uint8_t other;
uint16_t other2;
};
int main(void)
{
return sizeof(struct data);
}
$ gcc -Wall -Werror -Wextra -g -O2 -o test_gcc test.c
$ ./test_gcc ; echo $?
4
$ clang -Wall -Werror -Wextra -g -O2 -o test_clang test.c
$ ./test_clang ; echo $?
4
$ tcc -Wall -Werror -Wextra -g -O2 -o test_tcc test.c
$ ./test_tcc ; echo $?
8
Length 4 is expected, but tcc reports 8. Reporting the expected
length is important because the structure defines a network header.
I then tried to replace unsigned-int-based bitfield by an uint8_t-based
bitfield:
$ cat test2.c
#include
struct data
{
uint8_t foo:4;
uint8_t bar:4;
uint8_t other;
uint16_t other2;
};
int main(void)
{
return sizeof(struct data);
}
$ gcc -Wall -Werror -Wextra -g -O2 -o test2_gcc test2.c
$ ./test2_gcc ; echo $?
4
$ clang -Wall -Werror -Wextra -g -O2 -o test2_clang test2.c
$ ./test2_clang ; echo $?
4
$ tcc -Wall -Werror -Wextra -g -O2 -o test2_tcc test2.c
$ ./test2_tcc ; echo $?
4
Expected result is given by tcc this time. Problem is that I cannot
change the struct's definition from unsigned int to uint8_t.
Is there an option or a declaration to make tcc compute the expected
length for unsigned-int-based bit fields?
For the record, GCC is version 4.5.3, clang is version 3.0, and tcc is
git rev f98c2306a0857ad3f8800f91e0554a27adc7f675.
Regards,
Didier
signature.asc
Description: PGP signature
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
