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

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

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.

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

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

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

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: > > >

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

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).

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

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

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

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

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

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:

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

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

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

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 >

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

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

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

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