Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"

[Christian Jullien]

Let me summarize where we are on FreeBSD i386 and x86_64 with mod:

 

x86_64:

$ uname -m

amd64

$ gcc --print-file-name=crt1.o

/usr/lib/crt1.o

$ find /usr -name crt1.o

/usr/lib32/crt1.o

/usr/lib/crt1.o

$ ./configure

Binary  directory   /usr/local/bin

TinyCC directory/usr/local/lib/tcc

Library directory   /usr/local/lib

Include directory   /usr/local/include

Manual directory/usr/local/share/man

Info directory  /usr/local/share/info

Doc directory   /usr/local/share/doc

Target root prefix  -

Source path /usr/home/jullien/tinycc

C compiler  gcc

Target OS   FreeBSD

CPU x86-64

Big Endian  no

Profiling   no

Cross compilers no

Use libgcc  no

Triplet -

 

Compiles but test produces:

 

gmake -C tests

gmake[1]: Entering directory '/usr/home/jullien/tinycc/tests'

 hello-exe 

../tcc -B.. -I../include -I.. -I.. ../examples/ex1.c -o hello || (../tcc
-vv; exit 1) && ./hello

Segmentation fault (core dumped)

 

i386:

$ uname -m

i386

$ gcc --print-file-name=crt1.o

/usr/lib/crt1.o

$ find /usr -name crt1.o

/usr/lib/crt1.o

$ ./configure

Binary  directory   /usr/local/bin

TinyCC directory/usr/local/lib/tcc

Library directory   /usr/local/lib

Include directory   /usr/local/include

Manual directory/usr/local/share/man

Info directory  /usr/local/share/info

Doc directory   /usr/local/share/doc

Target root prefix  -

Source path /home/jullien/tinycc

C compiler  gcc

Target OS   FreeBSD

CPU x86

Big Endian  no

Profiling   no

Cross compilers no

Use libgcc  no

Triplet -

 

Compiles but test produces:

 

gmake -C tests

gmake[1]: Entering directory '/usr/home/jullien/tinycc/tests'

 hello-exe 

../tcc -B.. -I../include -I.. -I.. ../examples/ex1.c -o hello || (../tcc
-vv; exit 1) && ./hello

Hello World

 hello-run 

../tcc -B.. -I../include -I.. -I.. -run ../examples/ex1.c

Hello World

gcc -o libtcc_test libtcc_test.c ../libtcc.a -I.. -I.. -lm

 libtest 

./libtcc_test -B.. -I../include -I.. -I..

Hello World!

fib(32) = 2178309

add(32, 64) = 96

gcc -o tcctest.gcc tcctest.c -DTCC_TARGET_I386 -I.. -I.. -w -O0 -std=gnu99
-fno-omit-frame-pointer

./tcctest.gcc > test.ref

 test3 

../tcc -B.. -I../include -I.. -I.. -DTCC_TARGET_I386 -DONE_SOURCE -run
../tcc.c -B.. -I../include -I.. -I.. -DTCC_TARGET_I386 -DONE_SOURCE -run
../tcc.c -B.. -I../include -I.. -I.. -DTCC_TARGET_I386 -DONE_SOURCE -run
../tcc.c -B.. -I../include -I.. -I.. -run tcctest.c > test.out3

tcc: error: undefined symbol 'memcpy'

tcc: error: undefined symbol 'strlen'

tcc: error: undefined symbol 'memmove'

tcc: error: undefined symbol 'memset'

tcc: error: undefined symbol 'memcmp'

 

 

 

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of grischka
Sent: mardi 18 octobre 2016 18:50
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] core dump on FreeBSD with last commit
"configure: --triplet= option, Makefile: cleanup"

 

Michael Matz wrote:

> Hmm and now I see that this hunk also generally breaks building the 

> target compilers like x86_64-tcc, because they don't get 

> NATIVE_DEFINES from config.mak, and hence no -DCONFIG_LDDIR even if 

> configure would have found the correct one, so it now defaults to /lib,
and boom.

 

Hi Michael,

 

Honestly, in my book the cross compilers are just to test compilation,  they
are not assumed to work out of the box.

(Except the windows compiles where everything you need comes with the source
and therefor is well known where it is).

 

There is no support whatsoever from our configure either.

People tried to "fix" that but I was not able to detect any underlying
concept.

 

As I see it, if you want cross-compilers that really work you need to
edit/add the CONFIG_TCC_ paths for that target manually in the Makefile
(which is not difficult at all) or pass via environment or something. (We
could maybe add a "cross-config-include.mak.template" as an example).

 

As to the lib/lib64 issue, whatever you can figure out I'm fine.

 

Except I'd prefer to have the logic in only one location, that is NOT in
both the Makefile AND configure, because that is just confusing.

 

FYI: on my (old 8.10 from 2008) ubuntu 64, there is /usr/lib64, but it is a
link to /usr/lib.  There is also /usr/lib/x86_64-linux-gnu, but it is empty.
I was under the impression that lib64 was an old misguided concept from the
early 64 bit days. Maybe I was wrong.

 

Thanks,

 

-- grischka

 

 

___

Tinycc-devel mailing list

  Tinycc-devel@nongnu.org

 

Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"

[grischka]

Michael Matz wrote:
Hmm and now I see that this hunk also generally breaks building the target 
compilers like x86_64-tcc, because they don't get NATIVE_DEFINES from 
config.mak, and hence no -DCONFIG_LDDIR even if configure would have found 
the correct one, so it now defaults to /lib, and boom.


Hi Michael,

Honestly, in my book the cross compilers are just to test
compilation,  they are not assumed to work out of the box.
(Except the windows compiles where everything you need comes
with the source and therefor is well known where it is).

There is no support whatsoever from our configure either.
People tried to "fix" that but I was not able to detect
any underlying concept.

As I see it, if you want cross-compilers that really work you
need to edit/add the CONFIG_TCC_ paths for that target
manually in the Makefile (which is not difficult at all) or
pass via environment or something. (We could maybe add a
"cross-config-include.mak.template" as an example).

As to the lib/lib64 issue, whatever you can figure out I'm fine.

Except I'd prefer to have the logic in only one location, that
is NOT in both the Makefile AND configure, because that is just
confusing.

FYI: on my (old 8.10 from 2008) ubuntu 64, there is /usr/lib64,
but it is a link to /usr/lib.  There is also /usr/lib/x86_64-linux-gnu,
but it is empty.  I was under the impression that lib64 was an
old misguided concept from the early 64 bit days. Maybe I was wrong.

Thanks,

-- grischka


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"

[Michael Matz]

Hi,

On Tue, 18 Oct 2016, avih wrote:

> Some time ago I also bumped into the lib64 issue, which was apparent 
> when building cross compilers on a 64 system which doesn't use lib64, 
> e.g. Ubuntu 64. At the time I wrote a patch (which I didn't submit to 
> mob) which decides only at one place (configure) and then uses it 
> everywhere else.That's the patch: 
> https://github.com/avih/tinycc/commit/65b39fb66657459339fac88f1f4f4cedca4d0ad1

See my follow up, that's not a complete solution either because the 
$target-tcc compilers aren't build with NATIVE_DEFINES.  There are three 
major ways of dealing with multi-lib systems:

1 no multi-lib at all.  subcases:
  a) 64-bit only into /lib64
  b) 64-bit only but into /lib
2 restricted multi-lib, 32-bit or 64-bit
  at least non-debian linuxes:
  a) 64-bit to /lib64, 32-bit to /lib, 64-bit considered "native"
  b) 64-bit to /lib, 32-bit to /lib32, 64-bit considered "native"
3 unrestricted multi-lib, aka multiarch
  debian linuxes:
  everything to /usr/$triplet/lib

I don't know about the *BSDs, but probably they fit one of the above.  The 
way to find out which directory is used by gcc when calling without 
options (i.e. the default) is to inspect the output of

% gcc --print-file-name=crt1.o

The second to last component will be the libdir name.  The full path could 
also be used.

> However, with recent clean mob (though I haven't tested with the very 
> latest 2-3 commits as of now)

Yeah, it's the (as of now) most recent commit that broke it :)


Ciao,
Michael.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"

[David Mertens]

Can we just take a moment to appreciate how a pull request with automated
testing (a la Travis CI) would have made this error obvious *before* it was
added to mob?

On Tue, Oct 18, 2016 at 11:09 AM, Michael Matz  wrote:

> Hi,
>
> On Tue, 18 Oct 2016, grischka wrote:
>
> > Christian Jullien wrote:
> > > Get worse as it now core dumps ...
> >
> > At least it seems to find the crt*.o now.
>
> But not on linux-x86-64 anymore :-/  I think trying to fix things for a
> system one doesn't have access to is futile.  FWIW, your recent patch did,
> amongst other things:
>
>  #ifndef CONFIG_LDDIR
> -# ifdef TCC_TARGET_X86_64
> -#   define CONFIG_LDDIR "lib64"
> -# else
> -#   define CONFIG_LDDIR "lib"
> -# endif
> +# define CONFIG_LDDIR "lib"
>  #endif
>
> Okay, so no sensible default setting anymore, which is fine, but now we
> rely on configure providing the correct one.  But the same commit also
> does:
>
> -  triplet="$($CONFTEST triplet)"
> -  if test -f "/usr/lib/$triplet/crti.o" ; then
> -   tcc_lddir="lib"
> -   multiarch_triplet="$triplet"
> -  elif test "$cpu" != "x86" -a -f "/usr/lib64/crti.o" ; then
> -   tcc_lddir="lib64"
> +
> +  if test -z "$triplet"; then
> +tt="$($CONFTEST triplet)"
> +if test -n "$tt" -a -f "/usr/lib/$tt/crti.o" ; then
> +  triplet="$tt"
> +fi
> +  fi
> +
> +  if test -z "$triplet"; then
> +if test ! -f "/usr/lib/crti.o" -a -f "/usr/lib64/crti.o" ; then
> +  tcc_lddir="lib64"
> +fi
>fi
>
> That's not correct.  On an x86-64 system I can have both /usr/lib/crti.o
> and /usr/lib64/crti.o, namely when one also has a 32bit development
> environment (which I have).  Before it was testing if the cpu isn't x86
> and differenciated by that.  Now, on my system, tcc_lddir remains unset
> and hence runs into the above hunk which has no fallback to lib64 anymore.
>
> Christian: do you have /usr/lib64 as well or only /usr/lib?  If you also
> have the former, is there a crti.o in there as well?
>
> I'm tempted to remove the check for /usr/lib/crti.o altogether.  That
> would mean to always assume lib64 if no triplet is given but
> /usr/lib64/crti.o exists.  That seems sensible to me (on 32 hosts you
> won't have lib64, and on 64bit hosts you probably will default to 64bit
> code).
>
> Thoughts?
>
>
> Ciao,
> Michael.
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Weird bitfield size handling, discrepancy with gcc

[Michael Matz]

Hi,

On Tue, 18 Oct 2016, David Mertens wrote:

> According to Christian, we have at least one major compiler (VC++) whose
> behavior matches tcc's current behavior and another (GCC) whose behavior
> differs.

Yes, I've implemented the GCC way privately already (necessary for e.g. 
linux kernel).  Need to clean this up, sigh.

> While it would be nice to just pick one implementation and go with it, I 
> am personally much more concerned with binary compatibility with one's 
> major compiler of choice. 

Exactly.  Actually also GCC itself has different implementations.  E.g. 
when configured for windows (or with -mms-bitfields) it implements the 
microsoft way, otherwise it defaults to the old PCC layout, which GCC uses 
on most UNIXen and other operating systems.  There're also minor 
variations for the latter e.g. on ppc64, but those wouldn't concern us.

> Here is a patch that makes the bit field size logic match gcc. I can 
> confirm that the original alignment bug is gone (though other alignment 
> bugs may yet be around). I am not 100% sure if this is correct, but I 
> throw it out there for folks to mull over. Note that indentation may not 
> be consistent; the indentation pattern in the existing code was weird. 
> Finally, it might be more efficient to use (bit_size & 7) rather than 
> (bit_size % 8), or optimizing compilers might do that for us anyway; I 
> leave that to the gurus.

>  } else {
> +   size = bit_size / 8;
> +if (bit_size % 8) size++; /* round up */
> +lbit_pos = bit_pos;
>  /* we do not have enough room ?
> did the type change?
> is it a union? */
>  if ((bit_pos + bit_size) > bsize ||
> -bt != prevbt || a == TOK_UNION)
> -bit_pos = 0;
> -lbit_pos = bit_pos;
> +bt != prevbt || a == TOK_UNION) {
> +lbit_pos = bit_pos = 0;

For instance, this is wrong for PCC layout.  MS layout indeed switches 
storage containers when the base type changes, i.e. here:

struct S {
  char  c:1;
  short s:1;
  char foo;
};

PCC layout has no such provisions.  But the base type _does_ influence 
alignment of the containing struct nevertheless.  Except if the bitfield 
has :0 size, then it _does_ force the next field to be placed into a new 
storage container.  It's all quite terrible and twisted :-/


Ciao,
Michael.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"

[Michael Matz]

Hi,

On Tue, 18 Oct 2016, Michael Matz wrote:

> But not on linux-x86-64 anymore :-/  I think trying to fix things for a 
> system one doesn't have access to is futile.  FWIW, your recent patch did, 
> amongst other things:
> 
>  #ifndef CONFIG_LDDIR
> -# ifdef TCC_TARGET_X86_64
> -#   define CONFIG_LDDIR "lib64"
> -# else
> -#   define CONFIG_LDDIR "lib"
> -# endif
> +# define CONFIG_LDDIR "lib"
>  #endif

Hmm and now I see that this hunk also generally breaks building the target 
compilers like x86_64-tcc, because they don't get NATIVE_DEFINES from 
config.mak, and hence no -DCONFIG_LDDIR even if configure would have found 
the correct one, so it now defaults to /lib, and boom.

Hmm.  The state before was arguably broken as well, but in practice less 
broken than now :)


Ciao,
Michael.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"

[Michael Matz]

Hi,

On Tue, 18 Oct 2016, grischka wrote:

> Christian Jullien wrote:
> > Get worse as it now core dumps ...
> 
> At least it seems to find the crt*.o now.

But not on linux-x86-64 anymore :-/  I think trying to fix things for a 
system one doesn't have access to is futile.  FWIW, your recent patch did, 
amongst other things:

 #ifndef CONFIG_LDDIR
-# ifdef TCC_TARGET_X86_64
-#   define CONFIG_LDDIR "lib64"
-# else
-#   define CONFIG_LDDIR "lib"
-# endif
+# define CONFIG_LDDIR "lib"
 #endif

Okay, so no sensible default setting anymore, which is fine, but now we 
rely on configure providing the correct one.  But the same commit also 
does:

-  triplet="$($CONFTEST triplet)"
-  if test -f "/usr/lib/$triplet/crti.o" ; then
-   tcc_lddir="lib"
-   multiarch_triplet="$triplet"
-  elif test "$cpu" != "x86" -a -f "/usr/lib64/crti.o" ; then
-   tcc_lddir="lib64"
+
+  if test -z "$triplet"; then
+tt="$($CONFTEST triplet)"
+if test -n "$tt" -a -f "/usr/lib/$tt/crti.o" ; then
+  triplet="$tt"
+fi
+  fi
+
+  if test -z "$triplet"; then
+if test ! -f "/usr/lib/crti.o" -a -f "/usr/lib64/crti.o" ; then
+  tcc_lddir="lib64"
+fi
   fi

That's not correct.  On an x86-64 system I can have both /usr/lib/crti.o 
and /usr/lib64/crti.o, namely when one also has a 32bit development 
environment (which I have).  Before it was testing if the cpu isn't x86 
and differenciated by that.  Now, on my system, tcc_lddir remains unset 
and hence runs into the above hunk which has no fallback to lib64 anymore.

Christian: do you have /usr/lib64 as well or only /usr/lib?  If you also 
have the former, is there a crti.o in there as well?

I'm tempted to remove the check for /usr/lib/crti.o altogether.  That 
would mean to always assume lib64 if no triplet is given but 
/usr/lib64/crti.o exists.  That seems sensible to me (on 32 hosts you 
won't have lib64, and on 64bit hosts you probably will default to 64bit 
code).

Thoughts?


Ciao,
Michael.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"

[Christian JULLIEN]

Thanks,
no more core dump but still unable to link with std C.

$ ./tcc -vv
tcc version 0.9.26 (i386 FreeBSD)
install: /usr/local/lib/tcc
include:
 /usr/local/lib/tcc/include
 /usr/local/include
 /usr/include
libraries:
 /usr/lib
 /lib
 /usr/local/lib
crt:
 /usr/lib
elfinterp:
 /libexec/ld-elf.so.1
$ gmake test
gmake -C tests
gmake[1]: Entering directory '/usr/home/jullien/tinycc/tests'
 hello-exe 
../tcc -B.. -I../include -I.. -I.. ../examples/ex1.c -o hello || (../tcc -vv; 
exit 1)  ./hello
Hello World
 hello-run 
../tcc -B.. -I../include -I.. -I.. -run ../examples/ex1.c
Hello World
gcc -o libtcc_test libtcc_test.c ../libtcc.a -I.. -I.. -lm
 libtest 
./libtcc_test -B.. -I../include -I.. -I..
Hello World!
fib(32) = 2178309
add(32, 64) = 96
gcc -o tcctest.gcc tcctest.c -DTCC_TARGET_I386 -I.. -I.. -w -O0 -std=gnu99 
-fno-omit-frame-pointer
./tcctest.gcc  test.ref
 test3 
../tcc -B.. -I../include -I.. -I.. -DTCC_TARGET_I386 -DONE_SOURCE -run ../tcc.c 
-B.. -I../include -I.. -I.. -DTCC_TARGET_I386 -DONE_SOURCE -run ../tcc.c -B.. 
-I../include -I.. -I.. -DTCC_TARGET_I386 -DONE_SOURCE -run ../tcc.c -B.. 
-I../include -I.. -I.. -run tcctest.c  test.out3
tcc: error: undefined symbol 'memcpy'
tcc: error: undefined symbol 'strlen'
tcc: error: undefined symbol 'memmove'
tcc: error: undefined symbol 'memset'
tcc: error: undefined symbol 'memcmp'
...


All other tests passed!


- message d'origine -
De : "grischka" gris...@gmx.de
date mar. 18/10/2016 15:05 (GMT +02:00)
À : "tinycc-devel@nongnu.org" tinycc-devel@nongnu.org
Objet : Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: 
--triplet= option, Makefile: cleanup"

Christian Jullien wrote:
 Get worse as it now core dumps ...

At least it seems to find the crt*.o now.

See also
   http://lists.gnu.org/archive/html/tinycc-devel/2009-11/msg7.html
   http://lists.gnu.org/archive/html/tinycc-devel/2009-11/msg9.html
   http://lists.gnu.org/archive/html/tinycc-devel/2009-11/msg00010.html
The mentioned commit is now:
   http://repo.or.cz/w/tinycc.git/commitdiff/55cb2170cd5ce77

From
   +*paddr = uc-uc_mcontext.mc_rip;
it seems the patch was for x86-64.

-- gr


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Weird bitfield size handling, discrepancy with gcc

[David Mertens]

According to Christian, we have at least one major compiler (VC++) whose
behavior matches tcc's current behavior and another (GCC) whose behavior
differs. While it would be nice to just pick one implementation and go with
it, I am personally much more concerned with binary compatibility with
one's major compiler of choice. In that case, the logic for how to handle
this would depend upon a bit being set in the TCCState struct.

Here is a patch that makes the bit field size logic match gcc. I can
confirm that the original alignment bug is gone (though other alignment
bugs may yet be around). I am not 100% sure if this is correct, but I throw
it out there for folks to mull over. Note that indentation may not be
consistent; the indentation pattern in the existing code was weird.
Finally, it might be more efficient to use (bit_size & 7) rather than
(bit_size % 8), or optimizing compilers might do that for us anyway; I
leave that to the gurus.

If this looks good, I propose adding a bit to TCCState to pick this vs the
old behavior, then throwing in a couple of if statements to the below patch
to switch based on said bit.

David

diff --git a/tccgen.c b/tccgen.c
index ad70de6..97b37a4 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -3109,13 +3109,27 @@ static void struct_decl(CType *type, AttributeDef
*ad, int u)
 /* zero size: means to pad */
 bit_pos = 0;
 } else {
+   size = bit_size / 8;
+if (bit_size % 8) size++; /* round up */
+lbit_pos = bit_pos;
 /* we do not have enough room ?
did the type change?
is it a union? */
 if ((bit_pos + bit_size) > bsize ||
-bt != prevbt || a == TOK_UNION)
-bit_pos = 0;
-lbit_pos = bit_pos;
+bt != prevbt || a == TOK_UNION) {
+lbit_pos = bit_pos = 0;
+}
+/* only allocate large-type int bitfields
+ * one byte at a time */
+else {
+   int overage;
+   overage = bit_pos % 8 + bit_size;
+   if (overage > 8) {
+   lbit_pos = 0;
+   size = overage / 8;
+   if (overage % 8 == 0) size--;
+   }
+   }
 /* XXX: handle LSB first */
 type1.t |= VT_BITFIELD |
 (bit_pos << VT_STRUCT_SHIFT) |



On Tue, Oct 18, 2016 at 4:35 AM, Vincent Lefevre  wrote:

> On 2016-10-18 09:59:36 +0200, Daniel Glöckner wrote:
> > On Tue, Oct 18, 2016 at 09:41:49AM +0200, Vincent Lefevre wrote:
> > > AFAIK, both are correct.
> >
> > It depends on the ABI. The ARM EABI defines those details in
> > http://infocenter.arm.com/help/topic/com.arm.doc.
> ihi0042f/IHI0042F_aapcs.pdf
> > section 7.1.7. But I don't know if we adhere to those rules when
> > compiling for ARM.
>
> "For the purposes of calculating the alignment of the aggregate the
> type of the member shall be the Fundamental Data Type upon which the
> bit-field is based.[1]
>
> [1] The intent is to permit the C construct struct {int a:8; char b[7];}
> to have size 8 and alignment 4."
>
> Assuming that there are similar requirements for other architectures,
> the behavior of GCC now makes sense to me.
>
> --
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Weird bitfield size handling, discrepancy with gcc

[Vincent Lefevre]

On 2016-10-18 09:59:36 +0200, Daniel Glöckner wrote:
> On Tue, Oct 18, 2016 at 09:41:49AM +0200, Vincent Lefevre wrote:
> > AFAIK, both are correct.
> 
> It depends on the ABI. The ARM EABI defines those details in
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/IHI0042F_aapcs.pdf
> section 7.1.7. But I don't know if we adhere to those rules when
> compiling for ARM.

"For the purposes of calculating the alignment of the aggregate the
type of the member shall be the Fundamental Data Type upon which the
bit-field is based.[1]

[1] The intent is to permit the C construct struct {int a:8; char b[7];}
to have size 8 and alignment 4."

Assuming that there are similar requirements for other architectures,
the behavior of GCC now makes sense to me.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Weird bitfield size handling, discrepancy with gcc

[Daniel Glöckner]

On Tue, Oct 18, 2016 at 09:41:49AM +0200, Vincent Lefevre wrote:
> AFAIK, both are correct.

It depends on the ABI. The ARM EABI defines those details in
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/IHI0042F_aapcs.pdf
section 7.1.7. But I don't know if we adhere to those rules when
compiling for ARM.

Best regards,

  Daniel

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Weird bitfield size handling, discrepancy with gcc

[Vincent Lefevre]

On 2016-10-18 06:57:09 +0200, Christian Jullien wrote:
> Hi all,
> VC++ 32 and 64 both return:
> t1 struct size: 2
> t2 struct size: 8
> t3 struct size: 8
> 
> Which IMHO is correct. I really don’t understand why gcc returns
> t1 struct size: 2
> t2 struct size: 4
> t3 struct size: 4

AFAIK, both are correct.

> To me,
> struct t2 {
> uint32_t op_type:1;
> uint8_t op_flags;
> };
> 
> op_type uses a plain uint32_t to store only one bit as there is
> another field which is not a bit bitfield, C compile must allocate
> at least one extra byte in this struct. The minimal size I expect
> is 5!

I disagree. For the bit-field, a size 1 is sufficient for 1 bit.
So, the minimum size of the structure I would expect is 2 in all
of the 3 examples. Actually, even though the standard does not
require this, I would have expected the same size for all of these
3 examples, as this would have been more consistent, unless the
type of the bit-field is regarded as a hint for alignment choices.

> I changed you sample a little bit to see offset of op_flags:
> 
> #include 
> #include 
> #include 
> struct t1 {
> uint8_t op_type:1;
> uint8_t op_flags;
> };
> struct t2 {
> uint32_t op_type:1;
> uint8_t op_flags;
> };
> struct t3 {
> unsigned op_type:1;
> char op_flags;
> };
> 
> int main() {
> printf("t1 struct size: %ld\n", sizeof(struct t1));
> printf("t2 struct size: %ld\n", sizeof(struct t2));
> printf("t2 offset of op_flags: %ld\n", offsetof(struct t2, op_flags));
> printf("t3 struct size: %ld\n", sizeof(struct t3));
> return 0;
> }
> 
> Visual C++ gives:
> t1 struct size: 2
> t2 struct size: 8
> t2 offset of op_flags: 4
> t3 struct size: 8
> 
> While gcc gives
> c:\tmp>a.exe
> t1 struct size: 2
> t2 struct size: 4
> t2 offset of op_flags: 1
> t3 struct size: 4
> 
> Which IMHO is wrong. If later I change my mind with:
> struct t2 {
> uint32_t op_type:1;
> uint32_t op_other_field: 12;
> uint8_t op_flags;
> };

I see GCC's choice as OK. If you change your mind, the structure
changes and the offset of op_flags may change. I don't see anything
wrong here.

> I expect my struct will have the same size.

Different users have different expectations. For instance, I would
have expected the same size for the initial 3 examples. But as long
as the standard doesn't specify anything, the entire choices are
left to the implementation.

> I don't think we want tcc mimic this behavior. Doing this will break
> Windows code that depends on this behavior. The only solution is to
> add a compiler flag to ask for a specific behavior.

There are at least 2 things that should be specified: how offsets are
determined (i.e. how the unit sizes are determined), and how alignment
(which affects the size of the structure) is determined.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel