Re: [Tinycc-devel] RFC: Colored warnings/errors ?

[avih via Tinycc-devel]

 Personally I don't think this is required, but I don't pretend to
represent the tinycc maintainers' opinion. If it is added, however,
then the following should probably be taken into account:

- This mostly works, but it won't work on all terminals, for instance
 the original DEC VT100 has bold but doesn't have colors.

- It's probably better to support disabling it by means other than
 piping stderr into "cat" (so that stdout is not a tty). I.e. using
 an option, probably with value always/never/auto. Preferably it
 should also respect NO_COLOR by default. see https://no-color.org/ .

- This won't work on Windows before 10, e.g. Windows xp/7/8.

- On Windows 10+ this only works if the console/termimal has VT
 enabled - which is disabled by default, or if it runs in
 a terminal which supports VT (like mintty in MSYS2 or cygwin).
 To test if VT is enabled (untested, off the top of my head):
 DWORD mode; int has_vt;
 has_vt = GetConsoleMode(GetStdHandle(STD_ERROR_HANDLE), ) &&
 (mode & ENABLE_VIRTUAL_TERMINAL_PROCESSING);
 Note that ENABLE_VIRTUAL_TERMINAL_PROCESSING is new-ish and not
 defined in the tcc windows headers, so the code above would fail if
 compiled in tcc. You can define it as 4 if it's not defined.
 If you go this path, it should be used when compiling on windows
 (not when the target is windows).

- avih

 On Sunday, May 12, 2024 at 02:36:25 AM GMT+3, Nicolas Sauzede 
 wrote:  
 
 Hi,
I created a very simple mob branch to color warnings/errors output, just like 
GCC and Clang.

$ git fetch origin 
refs/mob/mob_nsauzede/colored_warning_error:colored_warning_error$ git 
checkout colored_warning_error
I tested it successfully on Linux (Arch) and Windows (MSYS2, 64 bits GCC 
bootstrap)It uses `isatty(2)` (unistd.h) to detect if the output should be 
colored (default) or not (eg: piped to a file) to behave like GCC and Clang.

What do you think ?
BR,NS.
___
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] Re : Re: Re : Re: win32: -Wl,-nostdlib: undefined symbol 'memset'

[avih via Tinycc-devel]

 On Tuesday, September 12, 2023 at 12:44:45 PM GMT+3, grischka  
wrote:

On 12.09.2023 11:01, avih via Tinycc-devel wrote:
>> Tcc does not guarantee to compile pure C code into pure machine code,
>> and any pure-C implementation which the user provides might end up
>> depending on those functions involuntarily. The user has no control..

> How do you define "pure C code"?

What I had in mind in this case was a C function which does not
use asm and does not call other functions, like this:

void *memset(void *str, int c, size_t n) {
 unsigned char *s = str;
 while (n--)
 *s++ = c;
 return str;
}

> And were did you get that that a compiler should be able to produce
> runnable binaries from such "pure C" without calling into any library
> functions?

I did not say that. I was trying to explain the scope of the issue.

> Also, what is "pure machine code"? With neither input nor output it
> couldn't do anything but waste instruction cycles.

A function implemented in machine code, where the input is the
arguments in whatever calling convention the implementation uses,
and the output is the return value and whatever memory side effects.

I was hoping that compiling a C function which does not call other
functions would result in machine code which does not call functions,
except maybe existing internal compiler functions.

In the example above it probably does not call external functions.
But the user can't tell when it does and when it doesn't, which makes
-nostdlib very problematic from a practical point of view.

At this stage it's clear that external functions are expected, so the
next step, if we want to have a usable -nostdlib, is to define the spec
which a user has to follow in order to use it.

My initial suggestion was to document the mem* and whatever other
implementations which are required, possibly with a suggestion to link
-ltcc1.

But because the user can't tell if their "pure C" mem* implementations
end up recursive or not, my second semi-suggestion was that maybe
libtcc1 could provide such implementations which it can guarantee to
not depend on external functions, and which the user may utilize if
they don't intend to implement these functions in asm themselves.

Even if these are terrible suggestions, the question remains:

What does the user need to do in order to use -nostdlib?

And maybe also: what is -stdlib good for?

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

Re: [Tinycc-devel] Re : Re: Re : Re: win32: -Wl,-nostdlib: undefined symbol 'memset'

[avih via Tinycc-devel]

 On Tuesday, September 12, 2023 at 11:46:52 AM GMT+3, 
 wrote:

> If the 'memset' function you would provide also call 'memset' (aka itself)
> then indeed it goes into full recursion (aka chicken-egg) and you should
> reconsider your software architecture.

It does not call memset (or memmove etc). It's written in pure C without
calls, but tcc might insert a call to memmove when it compiles C code
which does some assignment.

E.g.
uint64_t x, y = x;

Might end up depending on memmove for the assignment. It doesn't in
this case currently in x86, but how can I tell which assignments end up
implemented by tcc using memmove, and which are not?

That's the point of this additional issue.

Tcc does not guarantee to compile pure C code into pure machine code,
and any pure-C implementation which the user provides might end up
depending on those functions involuntarily. The user has no control..

- avih

- Mail d'origine -
De: avih via Tinycc-devel 
À: tinycc-devel@nongnu.org
Cc: avih 
Envoyé: Tue, 12 Sep 2023 10:33:01 +0200 (CEST)
Objet: Re: [Tinycc-devel] Re : Re: win32: -Wl,-nostdlib: undefined symbol 
'memset'

And actually, there's another potential issue here: even if my
suggestion was correct, how can I tell that the implementation
of memset which I provide doesn't end up requiring memset?
or that tomorrow it still won't require memset?

Basically, tcc expects a stand alone implementation of memset
which is fully self contained and does not depend on other
functions, but when tcc inserts a dependency on such functions
while compiling pure C code, I can't even compile such function
in pure C in tcc with guaranteed no-dependencies.

So it's a chicken and egg problem which might be hard to solve.
Is asm required here? or maybe even that is not always enough?

Maybe libtcc1 can provide implementations of _memset, _memmove
etc which tcc knows does not depend those functions recursively,
and can document that a user implementation of memset could
call _memset etc when linking with libtcc1?


 On Tuesday, September 12, 2023 at 12:11:17 AM GMT+3, avih via Tinycc-devel 
 wrote: 

 Thanks. I was going by the official gcc docs. I did not test
what it requires beyond those mem* implementations.

Back to tcc, the current help for nostdlib is:

> -nostdlib do not link with standard crt and libraries

Would that be fair to change it to something like:

> -nostdlib do not link with standard crt and libraries
> may require memset, memmove, and linking with -ltcc1

That's apriori. Linking with libtcc1.a seems to address all the
missing symbols in my example except memset and memmove.

Are there others? like memcmp or memcpy which the gcc docs mention?
or maybe even more beyond those?

Should the mem* functions and libtcc1 cover these linking issues, assuming
the user code doesn't use the crt and stdlib?

- avih



 On Monday, September 11, 2023 at 10:32:26 PM GMT+3, grischka  
wrote: 

On 11.09.2023 14:41, avih via Tinycc-devel wrote:
> But in the case of tcc, it's not documented, and seems to go
> quite a bit further than what gcc requires

libgcc.a from mingw-gcc-6.3.0 is 6218 kB, all full with according
to your standards "undocumented" stuff that however gcc surely
will require under certain circumstances and will miss when
-nostdlib given. List follows:

_chkstk.o ___chkstk
_chkstk.o __alloca
_chkstk_ms.o ___chkstk_ms
_muldi3.o ___muldi3
_negdi2.o ___negdi2
_lshrdi3.o ___lshrdi3
_ashldi3.o ___ashldi3
_ashrdi3.o ___ashrdi3
_cmpdi2.o ___cmpdi2
_ucmpdi2.o ___ucmpdi2
_clear_cache.o ___clear_cache
_trampoline.o _getpagesize
_trampoline.o _mprotect
__main.o ___do_global_dtors
__main.o ___do_global_ctors
__main.o ___main
_absvsi2.o ___absvsi2
_absvdi2.o ___absvdi2
_addvsi3.o ___addvsi3
_addvdi3.o ___addvdi3
_subvsi3.o ___subvsi3
_subvdi3.o ___subvdi3
_mulvsi3.o ___mulvsi3
_mulvdi3.o ___mulvdi3
_negvsi2.o ___negvsi2
_negvdi2.o ___negvdi2
_ctors.o ___DTOR_LIST__
_ctors.o ___CTOR_LIST__
_ffssi2.o ___ffssi2
_ffsdi2.o ___ffsdi2
_clz.o ___clz_tab
_clzsi2.o ___clzsi2
_clzdi2.o ___clzdi2
_ctzsi2.o ___ctzsi2
_ctzdi2.o ___ctzdi2
_popcount_tab.o ___popcount_tab
_popcountsi2.o ___popcountsi2
_popcountdi2.o ___popcountdi2
_paritysi2.o ___paritysi2
_paritydi2.o ___paritydi2
_powisf2.o ___powisf2
_powidf2.o ___powidf2
_powixf2.o ___powixf2
_powitf2.o ___powitf2
_mulsc3.o ___mulsc3
_muldc3.o ___muldc3
_mulxc3.o ___mulxc3
_multc3.o ___multc3
_divsc3.o ___divsc3
_divdc3.o ___divdc3
_divxc3.o ___divxc3
_divtc3.o ___divtc3
_bswapsi2.o ___bswapsi2
_bswapdi2.o ___bswapdi2
_clrsbsi2.o ___clrsbsi2
_clrsbdi2.o ___clrsbdi2
_fixunssfsi.o ___fixunssfsi
_fixunsdfsi.o ___fixunsdfsi
_fixunsxfsi.o ___fixunsxfsi
_fixsfdi.o ___fixsfdi
_fixdfdi.o ___fixdfdi
_fixxfdi.o ___fixxfdi
_fixunssfdi.o ___fixunssfdi
_fixunsdfdi.o ___fixunsdfdi
_fixunsxfdi.o ___fixunsxfdi
_floatdisf.o ___floatdisf
_floatdidf.o ___floatdidf
_floatdixf.o ___floatdixf
_floatundisf.o ___floatundisf
_floatundidf.o ___floatundidf
_floatundixf.o __

Re: [Tinycc-devel] Re : Re: win32: -Wl,-nostdlib: undefined symbol 'memset'

[avih via Tinycc-devel]

 And actually, there's another potential issue here: even if my
suggestion was correct, how can I tell that the implementation
of memset which I provide doesn't end up requiring memset?
or that tomorrow it still won't require memset?

Basically, tcc expects a stand alone implementation of memset
which is fully self contained and does not depend on other
functions, but when tcc inserts a dependency on such functions
while compiling pure C code, I can't even compile such function
in pure C in tcc with guaranteed no-dependencies.

So it's a chicken and egg problem which might be hard to solve.
Is asm required here? or maybe even that is not always enough?

Maybe libtcc1 can provide implementations of _memset, _memmove
etc which tcc knows does not depend those functions recursively,
and can document that a user implementation of memset could
call _memset etc when linking with libtcc1?


 On Tuesday, September 12, 2023 at 12:11:17 AM GMT+3, avih via Tinycc-devel 
 wrote:  
 
  Thanks. I was going by the official gcc docs. I did not test
what it requires beyond those mem* implementations.

Back to tcc, the current help for nostdlib is:

> -nostdlib do not link with standard crt and libraries

Would that be fair to change it to something like:

> -nostdlib do not link with standard crt and libraries
> may require memset, memmove, and linking with -ltcc1

That's apriori. Linking with libtcc1.a seems to address all the
missing symbols in my example except memset and memmove.

Are there others? like memcmp or memcpy which the gcc docs mention?
or maybe even more beyond those?

Should the mem* functions and libtcc1 cover these linking issues, assuming
the user code doesn't use the crt and stdlib?

- avih



 On Monday, September 11, 2023 at 10:32:26 PM GMT+3, grischka 
 wrote:  
 
 On 11.09.2023 14:41, avih via Tinycc-devel wrote:
> But in the case of tcc, it's not documented, and seems to go
> quite a bit further than what gcc requires

libgcc.a from mingw-gcc-6.3.0 is 6218 kB, all full with according
to your standards "undocumented" stuff that however gcc surely
will require under certain circumstances and will miss when
-nostdlib given.  List follows:

_chkstk.o    ___chkstk
_chkstk.o    __alloca
_chkstk_ms.o    ___chkstk_ms
_muldi3.o    ___muldi3
_negdi2.o    ___negdi2
_lshrdi3.o    ___lshrdi3
_ashldi3.o    ___ashldi3
_ashrdi3.o    ___ashrdi3
_cmpdi2.o    ___cmpdi2
_ucmpdi2.o    ___ucmpdi2
_clear_cache.o    ___clear_cache
_trampoline.o    _getpagesize
_trampoline.o    _mprotect
__main.o    ___do_global_dtors
__main.o    ___do_global_ctors
__main.o    ___main
_absvsi2.o    ___absvsi2
_absvdi2.o    ___absvdi2
_addvsi3.o    ___addvsi3
_addvdi3.o    ___addvdi3
_subvsi3.o    ___subvsi3
_subvdi3.o    ___subvdi3
_mulvsi3.o    ___mulvsi3
_mulvdi3.o    ___mulvdi3
_negvsi2.o    ___negvsi2
_negvdi2.o    ___negvdi2
_ctors.o    ___DTOR_LIST__
_ctors.o    ___CTOR_LIST__
_ffssi2.o    ___ffssi2
_ffsdi2.o    ___ffsdi2
_clz.o    ___clz_tab
_clzsi2.o    ___clzsi2
_clzdi2.o    ___clzdi2
_ctzsi2.o    ___ctzsi2
_ctzdi2.o    ___ctzdi2
_popcount_tab.o    ___popcount_tab
_popcountsi2.o    ___popcountsi2
_popcountdi2.o    ___popcountdi2
_paritysi2.o    ___paritysi2
_paritydi2.o    ___paritydi2
_powisf2.o    ___powisf2
_powidf2.o    ___powidf2
_powixf2.o    ___powixf2
_powitf2.o    ___powitf2
_mulsc3.o    ___mulsc3
_muldc3.o    ___muldc3
_mulxc3.o    ___mulxc3
_multc3.o    ___multc3
_divsc3.o    ___divsc3
_divdc3.o    ___divdc3
_divxc3.o    ___divxc3
_divtc3.o    ___divtc3
_bswapsi2.o    ___bswapsi2
_bswapdi2.o    ___bswapdi2
_clrsbsi2.o    ___clrsbsi2
_clrsbdi2.o    ___clrsbdi2
_fixunssfsi.o    ___fixunssfsi
_fixunsdfsi.o    ___fixunsdfsi
_fixunsxfsi.o    ___fixunsxfsi
_fixsfdi.o    ___fixsfdi
_fixdfdi.o    ___fixdfdi
_fixxfdi.o    ___fixxfdi
_fixunssfdi.o    ___fixunssfdi
_fixunsdfdi.o    ___fixunsdfdi
_fixunsxfdi.o    ___fixunsxfdi
_floatdisf.o    ___floatdisf
_floatdidf.o    ___floatdidf
_floatdixf.o    ___floatdixf
_floatundisf.o    ___floatundisf
_floatundidf.o    ___floatundidf
_floatundixf.o    ___floatundixf
_eprintf.o    ___eprintf
__gcc_bcmp.o    ___gcc_bcmp
_divdi3.o    ___divdi3
_moddi3.o    ___moddi3
_udivdi3.o    ___udivdi3
_umoddi3.o    ___umoddi3
_udiv_w_sdiv.o    ___udiv_w_sdiv
_udivmoddi4.o    ___udivmoddi4
bid_decimal_globals.o    ___dfp_set_round
bid_decimal_globals.o    ___dfp_get_round
bid_decimal_globals.o    ___dfp_clear_except
bid_decimal_globals.o    ___dfp_test_except
bid_decimal_globals.o    ___dfp_raise_except
bid_decimal_globals.o    ___bid_IDEC_glbround
bid_decimal_globals.o    ___bid_IDEC_glbflags
bid_decimal_data.o    ___bid_power10_index_binexp_128
bid_decimal_data.o    ___bid_reciprocals10_64
bid_decimal_data.o    ___bid_short_recip_scale
bid_decimal_data.o    ___bid_power10_index_binexp
bid_decimal_data.o    ___bid_estimate_bin_expon
bid_decimal_data.o    ___bid_power10_table_128
bid_decimal_data.o    ___bid_estimate_decimal_digits
bid_decimal_data.o    ___bid_recip

Re: [Tinycc-devel] Re : Re: win32: -Wl,-nostdlib: undefined symbol 'memset'

[avih via Tinycc-devel]

 Thanks. I was going by the official gcc docs. I did not test
what it requires beyond those mem* implementations.

Back to tcc, the current help for nostdlib is:

> -nostdlib do not link with standard crt and libraries

Would that be fair to change it to something like:

> -nostdlib do not link with standard crt and libraries
> may require memset, memmove, and linking with -ltcc1

That's apriori. Linking with libtcc1.a seems to address all the
missing symbols in my example except memset and memmove.

Are there others? like memcmp or memcpy which the gcc docs mention?
or maybe even more beyond those?

Should the mem* functions and libtcc1 cover these linking issues, assuming
the user code doesn't use the crt and stdlib?

- avih



 On Monday, September 11, 2023 at 10:32:26 PM GMT+3, grischka 
 wrote:  
 
 On 11.09.2023 14:41, avih via Tinycc-devel wrote:
> But in the case of tcc, it's not documented, and seems to go
> quite a bit further than what gcc requires

libgcc.a from mingw-gcc-6.3.0 is 6218 kB, all full with according
to your standards "undocumented" stuff that however gcc surely
will require under certain circumstances and will miss when
-nostdlib given.  List follows:

_chkstk.o    ___chkstk
_chkstk.o    __alloca
_chkstk_ms.o    ___chkstk_ms
_muldi3.o    ___muldi3
_negdi2.o    ___negdi2
_lshrdi3.o    ___lshrdi3
_ashldi3.o    ___ashldi3
_ashrdi3.o    ___ashrdi3
_cmpdi2.o    ___cmpdi2
_ucmpdi2.o    ___ucmpdi2
_clear_cache.o    ___clear_cache
_trampoline.o    _getpagesize
_trampoline.o    _mprotect
__main.o    ___do_global_dtors
__main.o    ___do_global_ctors
__main.o    ___main
_absvsi2.o    ___absvsi2
_absvdi2.o    ___absvdi2
_addvsi3.o    ___addvsi3
_addvdi3.o    ___addvdi3
_subvsi3.o    ___subvsi3
_subvdi3.o    ___subvdi3
_mulvsi3.o    ___mulvsi3
_mulvdi3.o    ___mulvdi3
_negvsi2.o    ___negvsi2
_negvdi2.o    ___negvdi2
_ctors.o    ___DTOR_LIST__
_ctors.o    ___CTOR_LIST__
_ffssi2.o    ___ffssi2
_ffsdi2.o    ___ffsdi2
_clz.o    ___clz_tab
_clzsi2.o    ___clzsi2
_clzdi2.o    ___clzdi2
_ctzsi2.o    ___ctzsi2
_ctzdi2.o    ___ctzdi2
_popcount_tab.o    ___popcount_tab
_popcountsi2.o    ___popcountsi2
_popcountdi2.o    ___popcountdi2
_paritysi2.o    ___paritysi2
_paritydi2.o    ___paritydi2
_powisf2.o    ___powisf2
_powidf2.o    ___powidf2
_powixf2.o    ___powixf2
_powitf2.o    ___powitf2
_mulsc3.o    ___mulsc3
_muldc3.o    ___muldc3
_mulxc3.o    ___mulxc3
_multc3.o    ___multc3
_divsc3.o    ___divsc3
_divdc3.o    ___divdc3
_divxc3.o    ___divxc3
_divtc3.o    ___divtc3
_bswapsi2.o    ___bswapsi2
_bswapdi2.o    ___bswapdi2
_clrsbsi2.o    ___clrsbsi2
_clrsbdi2.o    ___clrsbdi2
_fixunssfsi.o    ___fixunssfsi
_fixunsdfsi.o    ___fixunsdfsi
_fixunsxfsi.o    ___fixunsxfsi
_fixsfdi.o    ___fixsfdi
_fixdfdi.o    ___fixdfdi
_fixxfdi.o    ___fixxfdi
_fixunssfdi.o    ___fixunssfdi
_fixunsdfdi.o    ___fixunsdfdi
_fixunsxfdi.o    ___fixunsxfdi
_floatdisf.o    ___floatdisf
_floatdidf.o    ___floatdidf
_floatdixf.o    ___floatdixf
_floatundisf.o    ___floatundisf
_floatundidf.o    ___floatundidf
_floatundixf.o    ___floatundixf
_eprintf.o    ___eprintf
__gcc_bcmp.o    ___gcc_bcmp
_divdi3.o    ___divdi3
_moddi3.o    ___moddi3
_udivdi3.o    ___udivdi3
_umoddi3.o    ___umoddi3
_udiv_w_sdiv.o    ___udiv_w_sdiv
_udivmoddi4.o    ___udivmoddi4
bid_decimal_globals.o    ___dfp_set_round
bid_decimal_globals.o    ___dfp_get_round
bid_decimal_globals.o    ___dfp_clear_except
bid_decimal_globals.o    ___dfp_test_except
bid_decimal_globals.o    ___dfp_raise_except
bid_decimal_globals.o    ___bid_IDEC_glbround
bid_decimal_globals.o    ___bid_IDEC_glbflags
bid_decimal_data.o    ___bid_power10_index_binexp_128
bid_decimal_data.o    ___bid_reciprocals10_64
bid_decimal_data.o    ___bid_short_recip_scale
bid_decimal_data.o    ___bid_power10_index_binexp
bid_decimal_data.o    ___bid_estimate_bin_expon
bid_decimal_data.o    ___bid_power10_table_128
bid_decimal_data.o    ___bid_estimate_decimal_digits
bid_decimal_data.o    ___bid_recip_scale
bid_decimal_data.o    ___bid_reciprocals10_128
bid_decimal_data.o    ___bid_round_const_table_128
bid_decimal_data.o    ___bid_round_const_table
bid_binarydecimal.o    ___bid32_to_binary32
bid_binarydecimal.o    ___bid64_to_binary32
bid_binarydecimal.o    ___bid128_to_binary32
bid_binarydecimal.o    ___bid32_to_binary64
bid_binarydecimal.o    ___bid64_to_binary64
bid_binarydecimal.o    ___bid128_to_binary64
bid_binarydecimal.o    ___bid32_to_binary80
bid_binarydecimal.o    ___bid64_to_binary80
bid_binarydecimal.o    ___bid128_to_binary80
bid_binarydecimal.o    ___bid32_to_binary128
bid_binarydecimal.o    ___bid64_to_binary128
bid_binarydecimal.o    ___bid128_to_binary128
bid_binarydecimal.o    ___binary32_to_bid32
bid_binarydecimal.o    ___binary64_to_bid32
bid_binarydecimal.o    ___binary80_to_bid32
bid_binarydecimal.o    ___binary128_to_bid32
bid_binarydecimal.o    ___binary32_to_bid64
bid_binarydecimal.o    ___binary64_to_bid64
bid_binarydecimal.o    ___binary80_to_

Re: [Tinycc-devel] Re : Re: win32: -Wl,-nostdlib: undefined symbol 'memset'

[avih via Tinycc-devel]

 The issue is bigger than just memset. I found at least 5 more functions
which are required in some cases, not all of them part of stdlib, and I'm
guessing sure there are more, depending on the platform. For instance:

// test3.c ---

typedef struct { int a, b; } S;

void _start(void) {
 S x = {0}; // requires memset with i386, x86-64
 int z[x.a]; // requires alloca with i386, x86-64 (on win32, not linux)
 S y = x; // requires memmove with i386

 long long llng;
 llng /= 2; // requires __divdi3 with i386
 llng %= 2; // requires __moddi3 with i386
 *z *= 1.0; // requires __fixdfdi with i386
}

// ---

Then compile using:
tcc -Wl,-nostdlib test3.c

Result on windows, as i386:
tcc: error: undefined symbol 'memset'
tcc: error: undefined symbol 'alloca'
tcc: error: undefined symbol 'memmove'
tcc: error: undefined symbol '__divdi3'
tcc: error: undefined symbol '__moddi3'
tcc: error: undefined symbol '__fixdfdi'

 
So even if memset and memmove can be provided by the user, others
are not standard and undocumented (__divdi3 does not appear in C99),
while some might not even be possible - how can the user provide an
alloca implementation which allocates on the stack which tcc manages?

Looking at the gcc docs, it includes this about -nostdlib:

> The compiler may generate calls to "memcmp", "memset", "memcpy"
> and "memmove". These entries are usually resolved by entries in
> libc. These entry points should be supplied through some other
> mechanism when this option is specified.

So even if not very friendly (because this is the very thing
which the compiler is supposed to compiled into machine code...),
at least it's well defined what the user should provide in such case.

But in the case of tcc, it's not documented, and seems to go
quite a bit further than what gcc requires, to the point which
makes this option completely impractical for tcc end users.

- avih

 On Sunday, September 10, 2023 at 01:51:14 PM GMT+3, Ziyao via Tinycc-devel 
 wrote:  
 
 On 2023-09-10 15:13, Страхиња Радић wrote:

> What is weird is that tcc requires a libc function, memset, when none 
> is
> explicitly requested, when for example this code:

It is not that weird I think. Early versions of GCC generates a call to 
memset()
as well when zeroing a block of memory [1]

btw, the call could be easily eliminated by add a function like 
gen_struct_copy()
in x86_64-gen.c. And this call may lead to problems. For example, the 
dynamic
linker of musl has code that zeros a structure, but at that time 
memset() has not
been relocated, result in a segfault.

--
Ziyao

[1]: check for clear_storage() in gcc/expr.c of commit 3b6f75e2 of gcc

___
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] win32: -Wl,-nostdlib: undefined symbol 'memset'

[avih via Tinycc-devel]

 I don't think that's a valid argument.

This is plain C code which on its own doesn't require the standard library,
so I don't think the user should provide an alternative standard library
implementation just so that the startup code which tcc uses can be linked.

Today it seems that only `memset` is missing, but what if tomorrow the startup
code also wants some other stdlib functions?

I don't think the user should be responsible for this and/or track the 
requirements.

Instead, in cases where stdlib is not linked, I think tcc should use its own
implementations as needed. In this case a trivial memset is a two LOC function.

- avih
 On Saturday, September 9, 2023 at 08:02:25 PM GMT+3,  
wrote:  
 
 you tell tcc to ignore the std c library during linking, so you have to
provide an implementation yourself.
tcc uses memset to init  'buf'


___
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] win32: -Wl,-nostdlib: undefined symbol 'memset'

[avih via Tinycc-devel]

 Correction: the expected name is "_start" - not "_startup".

- avih


 On Saturday, September 9, 2023 at 07:19:32 PM GMT+3, avih 
 wrote:  
 
 The following is test.c:

#include 

void _start(void) {
    char buf[16] = {0};
    ExitProcess(42);
}


Try to compile it using:
tcc -Wl,-nostdlib test.c -lkernel32

Result:
tcc: error: undefined symbol 'memset'

Which I'm guessing is tcc trying to zero buf on startup using memset,
but failing to link the startup code.

It's possible to define memset at test.c and then it compiles and runs,
but I believe this should not be required.

Additionally, I don't know whether the name "_startup" and its prototype
are standardized, but if not, maybe it's worth either adding an option to
set the startup function name, or document the name _startup and its
prototype at the option help?

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

[Tinycc-devel] win32: -Wl,-nostdlib: undefined symbol 'memset'

[avih via Tinycc-devel]

The following is test.c:

#include 

void _start(void) {
char buf[16] = {0};
ExitProcess(42);
}


Try to compile it using:
tcc -Wl,-nostdlib test.c -lkernel32

Result:
tcc: error: undefined symbol 'memset'

Which I'm guessing is tcc trying to zero buf on startup using memset,
but failing to link the startup code.

It's possible to define memset at test.c and then it compiles and runs,
but I believe this should not be required.

Additionally, I don't know whether the name "_startup" and its prototype
are standardized, but if not, maybe it's worth either adding an option to
set the startup function name, or document the name _startup and its
prototype at the option help?

- avih

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

Re: [Tinycc-devel] Implementation of '--' argument

[avih via Tinycc-devel]

 What some random script tries or doesn't try to do is irrelevant.

tcc should follow the spec and common practices.

Generally speaking, applications which respect the POSIX syntax
guidelines should treat non-option-argument "--" as an indication
that all further arguments are operands:
- https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

It's important to note that according to these guidelines, the
options always come before the operands. I.e. mixing of options and
operands (like GNU getopt does with permutations) is not allowed.

Therefore, the use of "--" is to indicate where the options end and
the operands start, especially for the case where the first operand
begins with "-".

"grep" should indeed respect these guidelines, and "--":
- https://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html

However, there are exceptions, for instance "echo" should not
respect these guidelines and instead treat all arguments as operands:
- https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html

(the fact that some implementations of "echo" deviate from the spec
 and allow options such as "-e" or "-n" is the reason for echo being
 considered non portable, and why "printf" is recommended instead)

The "c99" utility, which should probably be considered the spec for
tcc, has some exceptions with regards to the syntax guidelines:
- https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html

While it does not specifically mention "--", it does say that
options and operands can be mixed, and some options should appear
after [c-files] operands, such as the "-l" and "-L" options
(check the synopsis).

For that reason, allowing "--" to be used before c-filenames
is a footgun, because then it's not possible to add "-l" or "-L"
options as needed by the spec.

The fact that gcc also doesn't recognize "--" is existing common
practice as well.

However, clang does recognize "--", and indeed, it rejects "-l"
or "-L" if they appear after "--" and some c-filenames.

As far as I can tell that's inconsistent with the "c99" POSIX spec.

So there you go. The main point of this is that it's not obvious
that tcc should respect "--" the same as some other utilities.

- avih

 On Sunday, April 16, 2023, 11:44:24 PM GMT+3, certanan via Tinycc-devel 
 wrote:  
 
 I understand. But then what role does the flag fulfil in this script?
https://github.com/qemacs/qemacs/blob/master/qe.tcc

- certanan

> I tried: gcc -- a.c
> and got:
> gcc: error: unrecognized command-line option '--'
> 
> This is with prerelease of gcc 13.
> So gcc does not support this. Why would this be needed for tcc?
> 
> Herman
> 
> ___
> 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
  ___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] __unaligned redefined on windows since afa05caa "Ignore _unaligned..."

[avih via Tinycc-devel]

__unaligned is defined as _attribute__((packed))
at win32/include/_mingw.h and pretty much always included, so tcc
shouldn't blindly define it to something else in advance.

The warnings can be observed when compiling tcc on Windows, or
when using the resulting newly built tcc, or when cross-compiling
(to windows) e.g. on linux: ./configure --enable-cross && make

Wrapping the _unaligned and __unaligned definitions at
include/tccdefs.h inside #ifndef _WIN32 ... #endif _seem_ to work
(and seems it should start on column 4 and not 1, see top comment),
but I'm not pushing this fix because I'm not sure it's right.

Preferably, the original author (Detlef) pushes a fix.

- avih

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

Re: [Tinycc-devel] tcc broken on osx 10.13.6 since 62096265 "Add debug support to macos" (herman ten brugge)

[avih via Tinycc-devel]

 




On Saturday, March 18, 2023, 02:07:35 PM GMT+2, avih  wrote:

> If I use #if 0 instead of #if !defined(__clang__) || GCC_MAJOR >= 11
> then it does pass. Not quite sure what's going on.

Ah, I do get it. When it compiles the reference using clang then
these elements are 0, but when it compiles the test using tcc
then __clang__ is not defined so this block is entered, and the
builtins do exist, so it compiles successfully and works, but still
different than the reference which has zeroes there.  ___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc broken on osx 10.13.6 since 62096265 "Add debug support to macos" (herman ten brugge)

[avih via Tinycc-devel]

 The patch does not work. The file compiles but there's a diff:

 test3 
--- test.ref 2023-03-18 14:01:39.0 +0200
+++ test.out3 2023-03-18 14:01:40.0 +0200
@@ -973,9 +973,9 @@
 6 1490
 7 3010
 8 3010
-9 0
-10 0
-11 0
+9 2444
+10 3056
+11 3056
 12 16149
 13 32126
 14 32126
make[2]: *** [test3] Error 1
make[1]: *** [all] Error 2
make: *** [test] Error 2

If I use #if 0 instead of #if !defined(__clang__) || GCC_MAJOR >= 11
then it does pass. Not quite sure what's going on.

- avih
 On Saturday, March 18, 2023, 12:46:47 PM GMT+2, Herman ten Brugge 
 wrote:  
 
 On 3/18/23 11:34, avih wrote:
>
> This is a second reply to the same email.
>
> On Tuesday, March 14, 2023, 06:02:35 PM GMT+2, Herman ten Brugge 
>  wrote:
>
> > Can you change the code in 'tests/tcctest.c' on line 3865 to '#if
> > GCC_MAJOR >= 40'.
>
> This works. Specifically, only the __builtin_clrsb* are an issue,
> while the others are fine.
Can you try attached patch.

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

Re: [Tinycc-devel] tcc broken on osx 10.13.6 since 62096265 "Add debug support to macos" (herman ten brugge)

[avih via Tinycc-devel]

 
This is a second reply to the same email.

On Tuesday, March 14, 2023, 06:02:35 PM GMT+2, Herman ten Brugge 
 wrote:

> Can you change the code in 'tests/tcctest.c' on line 3865 to '#if
> GCC_MAJOR >= 40'.

This works. Specifically, only the __builtin_clrsb* are an issue,
while the others are fine.

> You probably have a very very old clang that does not have some builtin
> support but stll sets GCC_MAJOR to a value >= 4.

'gcc --version' prints:

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin


'clang --version' is identical, without the 1st line (Configured...).


I don't think that clang 10 is particularly old, but that's
philosophical. It would be nice to be able to use Apple clang 10
to build tcc and pass the tests, but I don't know how to make it work
(I didn't manage to use __has_builtin to detect existence).

FWIW, I did try clang 9 and clang 11 on Debian stable (11.6), and
with both clang versions the tests do pass (and __builtin_clrsb*
exit), so I don't know why Apple's clang 10 doesn't have these.

Either way, it would be nice to be able to pass the tests with
Apple clang 10.


> Not all platforms in tcc are auto detected. For some platforms have set
> configure options like '--with-selinux' or '--config-pie'.

I've pushed autodetection of osx <= 10 to mob as e2152352 .

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

[Tinycc-devel] Self hosting issues with tcc 0.9.27

[avih via Tinycc-devel]

I thought it would be useful to be able to reach from tcc 0.9.27
to the current mob HEAD cleanly, and I've encountered several issues:


1. On Ubuntu 64 22.04 LTS (gcc 11.3), tcc 0.9.27 does not build.

git clean -xfd
git checkout release_0_9_27
./configure --prefix=$PWD/../tcc0927
make

# ends with this error:

../tcc -c bcheck.c -o bcheck.o -B..
bcheck.c:738: error: '__malloc_hook' undeclared
make[1]: *** [Makefile:64: bcheck.o] Error 1


I could not find a configure option to disable bcheck, so I edited
lib/Makefile and hardcoded "BCHECK_O =" (not only with uclibc/musl).

And now "make" works, but "make test" fails:

 asm-c-connect-test 
./asm-c-connect > asm-c-connect.out1 && cat asm-c-connect.out1
Segmentation fault
make[1]: *** [Makefile:245: asm-c-connect-test] Error 139


Disabling asm-c-connect-test (deleting line 19 at tests/Makefile),
and now "make test" succeeds. I did not try to fix the test.

Now run "make install", and keep this install (at $PWD/../tcc0927)

FWIW, gentoo bumped into the same issue, and their solution was
to ditch 0.9.27 in favor of mob from 20211022:
https://bugs.gentoo.org/806511
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=717eba5b5cfb78b1438c348882b34c88b3dc173a


2. Building mob using 0.9.27 works, but tests fail

test3:

As far as I can tell, because in test3, tcc 0.9.27 fails to compile
the reference in tests/tcctest.c in various cases where the test file
expects gcc or other working compiler to succeed, but 0.9.27 fails.

I did my best with a crude axe to at least allow it to compile,
and then test3 failed some diffs with about 7 sub-tests, so I
disabled it completely (delete line 16 of tests/Makefile).

test1b:
failed too, so I disabled it too, without looking into it.

dlltest:
fails with:
 dlltest with PIC 
./tcc2: symbol lookup error: ./libtcc2.so: undefined symbol: __va_start
make[2]: *** [Makefile:164: dlltest] Error 127

Disabled it too (deleted at tests/Makefile)

With test3, test1b, dlltest disabled at tests/Makefile,
this works with mob:

git clean -xfd
./configure --cc=$PWD/../tcc0927/bin/tcc --prefix=$PWD/../mob-pre
make
make test
make install


3. Finally, with this new mob-pre, we can build+test mob proper:

git reset --hard  # restore stock mob (with test3, test1b, dlltest)
git clean -xfd
./configure --cc=$PWD/../mob-pre/bin/tcc --prefix=$PWD/../mob
make
make test




Conclusions:

- This is not ideal. It's hard to build 0.9.27 these days, and
  even once built, it fails some tests, and ignoring that, it can
  build current mob but some tests fail.

- Luckily, using this last "broken tests mob" build it is possible
  to build mob-proper with all tests passing.

What might be be ideal, IMVHO, is:

- A new release 0.9.27.1 with minimal diff from 0.9.27, which:
  - Could be built with modern compilers and pass (enabled) tests.
  - Preferably can be built and pass tests with tcc 0.9.26 too.
- Or at least have a documented path to build from 0.9.26.
  - E.g. maybe just disable bcheck and asm-c-connect-test.

- That mob is modified to allow to be built and pass (Enabled) tests
  using a newly built tcc 0.9.27[.1]. This could be tricky, as
  I think it would have to be detected in configure tests or options,
  because tcc version has not changed for years, so hard to test...
  - maybe add a configure option --with-tcc-0-9-27 or some such.

- Finally, a new release (0.9.28 or 1.0, which can be built and
  pass tests using 0.9.27[.1]), because it's been years, and
  to serve as a new baseline to build future tcc versions.

Cheers,
- avih

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

Re: [Tinycc-devel] tcc broken on osx 10.13.6 since 62096265 "Add debug support to macos" (herman ten brugge)

[avih via Tinycc-devel]

 On Tuesday, March 14, 2023, 06:02:35 PM GMT+2, Herman ten Brugge 
 wrote:

> The config-new-macho=no was the default with commit 62096265.

Right, so that explains why --config-new-macho=no didn't help,
and I'd guess there are no options which would make it work, right?
(I don't have a need for this specific commit, so just curiosity).


> Can you change the code in 'tests/tcctest.c' on line 3865 to '#if
> GCC_MAJOR >= 40'.

This did make all tests pass with mob. Nice.


> You probably have a very very old clang that does not have some builtin
> support but stll sets GCC_MAJOR to a value >= 4.

I have MacOSX10.14 SDK installed (with xcode), which I think is the
latest xcode/sdk which can be installed on 10.13.6, but I don't know
whether or not the default gcc/clang is from this SDK. I guess yes.

'gcc --version' prints:

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin


'clang --version' is identical, sans the 1st line (Configured...).


> Not all platforms in tcc are auto detected. For some platforms have set
> configure options like '--with-selinux' or '--config-pie'.

Sure, but it's still nice if it is automated, assuming it can be.
Can it?

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

Re: [Tinycc-devel] tcc broken on osx 10.13.6 since 62096265 "Add debug support to macos" (herman ten brugge)

[avih via Tinycc-devel]

 On Tuesday, March 14, 2023, 02:53:19 PM GMT+2, Herman ten Brugge via 
Tinycc-devel  wrote:

> I can only test things on macos 12.6 (aarch64) and macos 10.15.7 (x86_64).
> These 2 platforms work with head.
>
> I applied a lot of fixes since november so head is probably the best version.
>
>
> I do not understand why adding debug support fails for osx.
>
> The load command 0x8034 is LC_DYLD_CHAINED_FIXUPS.
>
> This probably means that you have to configure with option
> '--config-new_macho=no'. If this stil fails can you sent me
> 'otool -l ' of the failing executable and tcc.
>
> Herman


Thanks for the reply.

If indeed it should be invoked with --config-new_macho=no, would it
be possible to auto-detect it? (while still allowing override)

With commit 62096265, '--config-new_macho=no' does not seem to make
a difference, and "hello-exe" still fails the same, starting with:

 hello-exe 
dyld: REBASE_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB has segment 4 which is not a 
writable segment (__LINKEDIT) in /Users/avih/dev/tcc/tcc.upstream/tests/./hello
/bin/sh: line 1: 58643 Abort trap: 6 ./hello


With current mob (4dc4e93), '--config-new_macho=no' does make
a difference, where now "hello-exe", "hello-run", and "libtest" do
pass, and "libtest_mt" passes some tests and then fails:

 libtest_mt 
running fib with mixed calls
 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765 10946
 (28 ms)
running fib in threads
 1 5 8 13 21 34 2 55 89 144 233 3 377 610 987 1597 2584 4181 6765 10946
 (23 ms)
running tcc.c in threads to run fib
 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765 10946
 (4159 ms)
compiling tcc.c 10 times
 1 2 3 4 5 6 7 8 9 10
 (1608 ms)
tcctest.c:3878:15: error: use of unknown builtin '__builtin_clrsb' 
[-Wimplicit-function-declaration]
 cnt[9] += __builtin_clrsb(x);
 ^
tcctest.c:3879:16: error: use of unknown builtin '__builtin_clrsbl' 
[-Wimplicit-function-declaration]
 cnt[10] += __builtin_clrsbl(x);
 ^
tcctest.c:3879:16: note: did you mean '__builtin_clrsb'?
tcctest.c:3878:15: note: '__builtin_clrsb' declared here
 cnt[9] += __builtin_clrsb(x);
 ^
tcctest.c:3880:16: error: use of unknown builtin '__builtin_clrsbll' 
[-Wimplicit-function-declaration]
 cnt[11] += __builtin_clrsbll(x);
 ^
tcctest.c:3880:16: note: did you mean '__builtin_clrsbl'?
tcctest.c:3879:16: note: '__builtin_clrsbl' declared here
 cnt[10] += __builtin_clrsbl(x);
 ^
3 errors generated.
make[2]: *** [test.ref] Error 1
make[1]: *** [all] Error 2
make: *** [test] Error 2


While this does not seem like a load issue anymore, I'm still
attaching the full output of configure && make && make test,
as well as of 'otool -l ./tcc' with current mob (4dc4e93).

- avihBinary 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
/usr/include dir
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include
Source path /Users/avih/dev/tcc/tcc.upstream
C compiler  clang (10.0)
Target OS   Darwin
CPU x86_64
Config  OSX new_macho=no
Creating config.mak and config.h
clang -o tcc.o -c tcc.c 
-DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include\""
 -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_NEW_MACHO=0
-DONE_SOURCE=0 -DTCC_GITHASH="\"HEAD:4dc4e93 2023-03-13T17:01:35+01:00\""  
-Wall -O2 -Wdeclaration-after-statement -fno-strict-aliasing 
-fheinous-gnu-extensions -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result 
-Wno-string-plus-int -I. 
clang -o libtcc.o -c libtcc.c 
-DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include\""
 -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_NEW_MACHO=0
-DONE_SOURCE=0 -Wall -O2 -Wdeclaration-after-statement -fno-strict-aliasing 
-fheinous-gnu-extensions -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result 
-Wno-string-plus-int -I. 
clang -DC2STR conftest.c -o c2str.exe && ./c2str.exe include/tccdefs.h 
tccdefs_.h
clang -o tccpp.o -c tccpp.c 
-DCONFIG_USR_INCLUDE="\"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include\""
 -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO -DCONFIG_NEW_MACHO=0
-DONE_SOURCE=0 -Wall -O2 -Wdeclaration-after-statement -fno-strict-aliasing 
-fheinous-gnu-extensions -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result 
-Wno-string-plus-int -I. 
clang -o t

[Tinycc-devel] tcc broken on osx 10.13.6 since 62096265 "Add debug support to macos" (herman ten brugge)

[avih via Tinycc-devel]

The offending commit is from November 2022.
Here are test outputs with the offending commit and then current mob.

Below is the output with the offending commit 62096265
of the test part of:
  git clean -xfd && ./configure && make && make test

 hello-exe 
dyld: REBASE_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB has segment 4 which is not a 
writable segment (__LINKEDIT) in /Users/avih/dev/tcc/tcc.upstream/tests/./hello
/bin/sh: line 1: 49518 Abort trap: 6   ./hello
+ ../tcc -vv
tcc version 0.9.27 HEAD:6209626 (x86_64 Darwin)
install: /usr/local/lib/tcc
include:
  /usr/local/lib/tcc/include
  /usr/local/include
  
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include
libraries:
  /usr/local/lib/tcc
  /usr/lib
  /lib
  /usr/local/lib
  /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
  /Applications/Xcode.app/Developer/SDKs/MacOSX.sdk/usr/lib
libtcc1:
  /usr/local/lib/tcc/libtcc1.a
+ otool -L ../tcc
../tcc:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1252.50.4)
+ exit 1
make[2]: *** [hello-exe] Error 1
make[1]: *** [all] Error 2
make: *** [test] Error 2



And this is the slightly different test part output of the same
command with current mob HEAD (4dc4e93):

 hello-exe 
dyld: cannot load 'hello' (load command 0x8034 is unknown)
/bin/sh: line 1: 53010 Abort trap: 6   ./hello
+ ../tcc -vv
tcc version 0.9.27 HEAD:4dc4e93 2023-03-13T17:01:35+01:00 (x86_64 Darwin)
install: /usr/local/lib/tcc
include:
  /usr/local/lib/tcc/include
  /usr/local/include
  
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include
libraries:
  /usr/local/lib/tcc
  /usr/lib
  /lib
  /usr/local/lib
  /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
  /Applications/Xcode.app/Developer/SDKs/MacOSX.sdk/usr/lib
libtcc1:
  /usr/local/lib/tcc/libtcc1.a
+ otool -L ../tcc
../tcc:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1252.50.4)
+ exit 1
make[2]: *** [hello-exe] Error 1
make[1]: *** [all] Error 2
make: *** [test] Error 2

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

Re: [Tinycc-devel] test failures on win32 x86-64

[avih via Tinycc-devel]

 On Wednesday, October 19, 2022, 03:36:59 PM GMT+3, Michael Matz 
 wrote:

> ...
> "dec %edi" truncates the %rdi register to 32bit by zero-extension,
> so that ... this is now segfault. That only matters if the stack
> (which %rdi points into) is setup such that it's beyond 32bit,
> which ... is indeed the case on win10 for you. So, it's not
> malloc() result, but it does have to do with address space layout.

Thanks for pointing out the relation between my (somewhat off)
addresses observation and the test failures.

Are you able to shed some light on how some binaries (those compiled
with msvc or new mingw gcc) exhibit ~44 bit addresses on Windows 10,
but ~24 bits addresses on Windows 7?

> The problem is that win64 is an IL32 platform, so that 'long' is not the
> same size as a pointer, but the strncat1 implementation, coming from the
> linux kernel, expects that to be the case. The below patch should fix it,
> but I can't test on win64, so please check yourself and commit if it does.

I think your patch will conflict with the fix on mob from few days ago:
 https://repo.or.cz/tinycc.git/commitdiff/bb80cbe0
But I'd imagine it would have worked, as it replaces long with size_t,
which is the same size (64 bits) as word which was set at bb80cbe0 .

(I confirmed that sizeof void*/word/size_t at tcctest.c is 64 bits
when compiled with either mingw gcc 64 or tcc win64, and long is 32).

However, do note that your patch replaces two instances of long with
size_t, while bb80cbe0 replaces few more instances, so I'd imagine
that's why the test was still failing with your patch (didn't check).

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

Re: [Tinycc-devel] test failures on win32 x86-64

[avih via Tinycc-devel]

 On Friday, October 14, 2022, 05:27:47 PM GMT+3, grischka  
wrote:

>> and indeed, when tcc64 is compiled using tcc64 then on win10
>> s->sh_addr is ~22 bits, and all tests do pass _before_ d76e0323.
> 
> Well, maybe behavior of malloc on Win10 has to do with the image-base
> of the process. (see objdump -x file.exe/dll | grep ImageBase)

To me this seems to suggest that the behavior depends on the specific
binary, but the printouts on win7/10 were with the _same_ binaries.
You can grab it from here https://0x0.st/ov4N.zip and examine for
instance addr.gcc-12-2.exe which prints a ~22 bits address on win7
but ~44 bits address on my win10.

> These can be set using -Wl,-image-base=0x..., for example
> $ gcc tcctest.c -g -I.. -O0 -w -o tcctest.exe -Wl,-image-base=0x40

Again, it's an identical tcctest.gcc (at least as far as md5sum goes)
which fails at strncat1 on win10 but succeeds on win7.

> Ok, so it seems that it is tcctest.c compiled by gcc that crashes.
> Which means this problem specifically hasn't to do anything with tcc.

Yup, seems like it.

> $ gdb tcctest.exe
> > run
> > bt
> > disass
> > info reg

The printout below starts at the end of the "run" output.

- avih


[...]
 asm_test 

Thread 1 received signal SIGSEGV, Segmentation fault.
0x7ff72b42b272 in strncat1 ()
(gdb) disass
Dump of assembler code for function strncat1:
 0x7ff72b42b234 <+0>: push %rbp
 0x7ff72b42b235 <+1>: push %rdi
 0x7ff72b42b236 <+2>: push %rsi
 0x7ff72b42b237 <+3>: sub $0x10,%rsp
 0x7ff72b42b23b <+7>: lea 0x10(%rsp),%rbp
 0x7ff72b42b240 <+12>: mov %rcx,0x20(%rbp)
 0x7ff72b42b244 <+16>: mov %rdx,0x28(%rbp)
 0x7ff72b42b248 <+20>: mov %r8,0x30(%rbp)
 0x7ff72b42b24c <+24>: mov 0x28(%rbp),%r8
 0x7ff72b42b250 <+28>: mov 0x20(%rbp),%r9
 0x7ff72b42b254 <+32>: mov $0x0,%eax
 0x7ff72b42b259 <+37>: mov $0x,%edx
 0x7ff72b42b25e <+42>: mov %r8,%rsi
 0x7ff72b42b261 <+45>: mov %r9,%rdi
 0x7ff72b42b264 <+48>: mov %edx,%ecx
 0x7ff72b42b266 <+50>: repnz scas %es:(%rdi),%al
 0x7ff72b42b268 <+52>: dec %edi
 0x7ff72b42b26a <+54>: mov 0x30(%rbp),%ecx
 0x7ff72b42b26d <+57>: dec %ecx
 0x7ff72b42b26f <+59>: js 0x7ff72b42b277 
 0x7ff72b42b271 <+61>: lods %ds:(%rsi),%al
=> 0x7ff72b42b272 <+62>: stos %al,%es:(%rdi)
 0x7ff72b42b273 <+63>: test %al,%al
 0x7ff72b42b275 <+65>: jne 0x7ff72b42b26d 
 0x7ff72b42b277 <+67>: xor %eax,%eax
 0x7ff72b42b279 <+69>: stos %al,%es:(%rdi)
 0x7ff72b42b27a <+70>: mov %ecx,%edx
 0x7ff72b42b27c <+72>: mov %edi,%r8d
 0x7ff72b42b27f <+75>: mov %esi,%r9d
 0x7ff72b42b282 <+78>: mov %r9d,-0x4(%rbp)
 0x7ff72b42b286 <+82>: mov %r8d,-0x8(%rbp)
 0x7ff72b42b28a <+86>: mov %eax,-0xc(%rbp)
 0x7ff72b42b28d <+89>: mov %edx,-0x10(%rbp)
 0x7ff72b42b290 <+92>: mov 0x20(%rbp),%rax
 0x7ff72b42b294 <+96>: add $0x10,%rsp
 0x7ff72b42b298 <+100>: pop %rsi
 0x7ff72b42b299 <+101>: pop %rdi
 0x7ff72b42b29a <+102>: pop %rbp
 0x7ff72b42b29b <+103>: ret
End of assembler dump.
(gdb) info reg
rax 0x20 32
rbx 0x1 1
rcx 0x2 2
rdx 0x 4294967295
rsi 0x7ff72b431fdd 140699559469021
rdi 0xcb9ff955 3416258901
rbp 0x4ecb9ff8f0 0x4ecb9ff8f0
rsp 0x4ecb9ff8e0 0x4ecb9ff8e0
r8 0x7ff72b431fdc 140699559469020
r9 0x4ecb9ff950 338423707984
r10 0x0 0
r11 0x246 582
r12 0x1 1
r13 0x169230214a0 1551070532768
r14 0x16923021440 1551070532672
r15 0x0 0
rip 0x7ff72b42b272 0x7ff72b42b272 
eflags 0x10202 [ IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x53 83
gs 0x2b 43
(gdb)
  ___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] test failures on win32 x86-64

[avih via Tinycc-devel]

 In reply to the second half of:
 https://lists.nongnu.org/archive/html/tinycc-devel/2022-10/msg00021.html

> As to spurious problems with MSYS2 I can only say that in my experience
> it is not a completely reliable build system.
> 
> As a derivative from cygwin it shares the same fork() emulation hack,
> and I've seen it sub-processes just silently terminating (or maybe not
> even start them) with no failure code whatsoever.
> 
> That would not affect the built tcc itself however it could affect the
> 'diff' used by the tests for example.

I think I removed the cygwin/fork/diff variables as follows:

I'm using this, which is a reproducible mingw env without cygwin:
 https://github.com/skeeto/w64devkit/releases/tag/v1.16.1

building tcc (simply configure && make) within this environment
is producing identical tcc.exe, libtcc.dll, libtcc1.a on both my
Windows 10 system (32G ram) and my Windows 7 system (16G ram).

"make test" succeeds on win7 but fails on win10.

_Before_ commit d76e0323 (win64: hi-mem adjustments) test 104
failed also when invoked manually as:
 cd tests/tests2 && path/to/inttalled/tcc 104+_inline.c -run 104_inline.c

where on win7 it printed things and exited successfully, while on
win10 it printed "tcc: error: internal error: relocation failed".

So it's also not an issue of diff not running correctly.

I took the liberty to print the value which fails ("diff") and its
origin (s->sh_addr at relocate_section), and noticed that on win10
it's 41-44 bits values, while on win7 it's 22-24 bits values.

I guessed that this might be an address from malloc, and checked
which values malloc returns using this program (source link below):

int msb(unsigned long long v) {
 for (int i = 0;; ++i, v /= 2)
 if (!v) return i;
}

int main(int argc, char **argv) {
 unsigned long long a = (uintptr_t)malloc(1024);
 printf("%s %d [%d]: malloc: %llu (%d/%d bits)\n",
 cc, ccver, ccbits, a, msb(a), 8 * (int)sizeof(void*));
 return 0;
}

I compiled this program using tcc (64) itself, as well as using
mingw gcc 5.5 (64), mingw gcc 12.2 (64), and msvc 2015 (64).
Source + binaries are available here https://0x0.st/ov4N.zip

On win7 these programs print results like this:
 gcc 12 [64]: malloc: 1464336 (21/64 bits)
 gcc 5 [64]: malloc: 8476688 (24/64 bits)
 msvc 1900 [64]: malloc: 2635264 (22/64 bits)
 tcc 927 [64]: malloc: 2185120 (22/64 bits)

While on win10 the same binaries print resuts like this:
 gcc 12 [64]: malloc: 2620625130432 (42/64 bits)
 gcc 5 [64]: malloc: 12260288 (24/64 bits)
 msvc 1900 [64]: malloc: 1504834189600 (41/64 bits)
 tcc 927 [64]: malloc: 8590208 (24/64 bits)

So somehow, on win7 the address from malloc is always ~22 bits,
while on win10 msvc and new mingw gcc procude ~43 bits address,
while with tcc and old gcc malloc returns ~22 bits addresses.

and indeed, when tcc64 is compiled using tcc64 then on win10
s->sh_addr is ~22 bits, and all tests do pass _before_ d76e0323.


--


On Thursday, October 13, 2022, 10:16:45 PM GMT+3, grischka  
wrote:

>> from tests/tests2/:
>> - 104_inline.test
> 
> This might be fixed on mob.

Confirmed, 104 now passes on win10 with gcc 12.2 (at d76e032).


> You can see the command when you call the test directly:
> 
> make -C tests clean
> make -C tests test1

On win10 with gcc 12.2, the output ends with this:
 ./tcctest.gcc > test.ref
 make: *** [Makefile:110: test.ref] Error -1073741819
 make: Leaving directory 'D:/tmp/tcc2/tests'

and the last line at test.ref is " asm_test -"

Then, at tcctest.c, I commented out /* RUN(asm_test); */
and the test passes.

I tried to find which line crashes at asm_test, and it's:
 strncat1(buf, " worldX", 3);

(adding exit(42) just before it exits with code 42, but exit(42)
after it is not reached).

I then tried also
 make -C tests clean
 make -C tests test3

and it's the same end of output as with test1, and same
diagnostics (pass if commenting out RUN(asm_test), else
crash at strncat1(buf, " worldX", 3)).


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

Re: [Tinycc-devel] tcc-busybox-w32 broken since 20a1ebf (tccpp : get rid of 'ch')

[avih via Tinycc-devel]

 
On Monday, October 10, 2022, 12:33:48 PM GMT+3, grischka  wrote:

>> tcc-busybox is:
>> http://download.savannah.nongnu.org/releases/tinycc/tcc-busybox-for-win32.zip
>>
>> building this busybox using tcc which was built from mob 20a1ebf
>> or later results in sh.exe which always prints "sh: applet not found".
> 
> Hi, I'm afraid you're right.
> 
> Fortunately commit 20a1ebf had to do with the preprocessor exclusively,
> so I did add -E to the build command for the busybox and could produced
> two files, one of 180.381.021 bytes and one of 180.381.020 bytes... Hm.
> ...
> Anyway, fixed on mob.

Confirmed that it seems fixed for both tcc32 and 64. Thanks.
./sh.exe -c 'echo OK' now prints OK, and interactive shell seems good.


> As to spurious problems with MSYS2 I can only say that in my experience
> it is not a completely reliable build system.
> 
> As a derivative from cygwin it shares the same fork() emulation hack,
> and I've seen it sub-processes just silently terminating (or maybe not
> even start them) with no failure code whatsoever.

I presume you refer to my mail "test failures on win32 x86-64" here:
 https://lists.nongnu.org/archive/html/tinycc-devel/2022-10/msg00019.html

If yes, then while cygwin/MSYS2 fork issue is possible, I don't think
it's the cause, and I don't usually have fork issues with cygwin.

I think the resulting tcc.exe is faulty in some ways when built using
mingw gcc 64 (tested cygwin gcc 11.3, and MSYS2/w64devkit gcc 12.2).

w64devkit is interesting because it seems to be a native win32 mingw
gcc, i.e. not a cross compiler, and same for its 'make', and the
shell too (busybox-w32) - https://github.com/skeeto/w64devkit

In all 3 gcc versions and their 'make' and shell/env it's exactly the
same tests which fail, and seemingly in exactly the same ways:
- test3 and test1b _seem_ to crash
- 104_inline outputs "tcc: error: internal error: relocation failed"

And all the tests always pass with mingw i386 - both when building
in MSYS2 and cygwin (and their respective mingw i386 gcc).

Interestingly, when building using native win32 x86-64 tcc, then all
the tests do pass (even if building in MSYS2/cygwin with their fork).

Shall we continue this discussion at its original email thread?

- avih


> That would not affect the built tcc itself however it could affect the
> 'diff' used by the tests for example.
> 
> Mostly it seems to work just fine though, I personally don't currently
> see any problems. Known reasons could be bad interaction with some
> anti-virus-defender-etc...ware. What I see is that on a windows-10
> with its 'defender' ON, building & test tcc with msys is almost twice
> as slow.
> 
> -- grischka



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

[Tinycc-devel] tcc-busybox-w32 broken since 20a1ebf (tccpp : get rid of 'ch')

[avih via Tinycc-devel]

Hi,

It's the first time I tried building it (cute), and turns out that it's 
currently broken.

tcc-busybox is:
  http://download.savannah.nongnu.org/releases/tinycc/tcc-busybox-for-win32.zip

building this busybox using tcc which was built from mob 20a1ebf
or later results in sh.exe which always prints "sh: applet not found".

The steps to reproduce below are using MSYS2 mingw, but it was
reproduced also after building win32 tcc in other environments.

Interestingly, renaming the binary to ash.exe seem to "fix" it. e.g.
  ./sh.exe -c 'echo hello'  #  -> sh: applet not found
  mv ./sh.exe ./ash.exe
  ./ash.exe -c 'echo hello'  #  -> hello

This happens with both win32 tcc i386 and x86-64, and tcc i386
does pass all tests (x86-64 fails some tests, but probably unrelated).

Building one commit earlier (85c32dd tccpp: integrate __has_include..)
and both i386 and x86-64 tcc build sh.exe which seem to work as expected.

I didn't try to find what fails in busybox, and the the bad commit
20a1ebf is quite big, so it's hard to pinpoint the culprit, if any.

regards,
avih


steps to reproduce using MSYS2 with mingw i686 and x86-64 installed:

the following prints "sh: applet not found" if built using tcc from
20a1ebf, but prints "OK" if built using tcc from 85c32dd or earlier.


# get the sources once:

mkdir /c/test \
&& cd /c/test \
&& wget 
http://download.savannah.nongnu.org/releases/tinycc/tcc-busybox-for-win32.zip \
&& unzip tcc-busybox-for-win32.zip \
&& git clone http://repo.or.cz/tinycc.git


# build tcc32, busybox, and test:
# MSYSTEM=... PATH=...  emulates the mingw32 desktop shortcut

cd /c/test/tinycc \
&& git clean -xfd \
&& rm -rf /c/test/tcc-busybox-for-win32/tcc \
&& (
MSYSTEM=MINGW32 PATH=/mingw32/bin:$PATH \
&& ./configure --cpu=i386 --prefix=/c/test/tcc-busybox-for-win32/tcc \
&& make \
&& make install \
&& cd /c/test/tcc-busybox-for-win32/busybox \
&& rm -f ../sh.exe \
&& PATH=/c/test/tcc-busybox-for-win32/tcc \
&& tcc @0.tcc/busybox.tcc.rsp -w \
&& ../sh.exe -c 'echo OK'
)

# tcc64: ... MSYSTEM=MINGW64 PATH=/mingw64/bin:$PATH \
#&& ./configure --cpu=x86_64 --prefix=...

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

[Tinycc-devel] test failures on win32 x86-64

[avih via Tinycc-devel]

Hi,

The following tests fail for me currently (0fd7376 gnu hash) when
building tcc for win32 x86-64 (but pass when building i386)

from tests/:
- test3
- test1b

from tests/tests2/:
- 104_inline.test

I sampled several revisions since release_0_9_27, and all of them
fail somehow, mostly in tests (one revision also failed to build).

This could be related to the mingw gcc I'm testing with - gcc 11.3.0
using mingw64 in MSYS2. I _think_ the x86-64 win32 tests did pass
in thepast, so if someone could confirm the failures it may help.

I tested as follows on Windows 10:
- launch the mingw64 MSYS2 desktop shortcut
- cd path/to/tinycc
- git clean -xfd
- ./configure --cpu=x86_64 --config-mingw32 && make && make test


regards,
avih

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

Re: [Tinycc-devel] Outdated .def files

[avih via Tinycc-devel]

 I _think_ the current win32 definitions are from Windows XP.

If we update to newer definitions, then I assume it would compile
successfully programs which use newer APIs, but the question is
what happens at runtime.

mingw has a system to define what to target (I don't recall the
specifics), so unless tcc's mingw files already have it, I think
it would need to be added, or at least considered.

- avih

 On Saturday, September 18, 2021, 09:03:12 AM GMT+3, Christian Jullien 
 wrote:  
 
 
Hi,

  

If I regenerate a kernel32.def out of kernel32.dll on my Windows 10 21H1 
machine it is 3x times bigger that the one that currently comes with tcc. (see 
enclosed)

It means many kernel32 API are not directly available for tcc.

  

It is probably the same with other .def files

  

What do you advice ?

  

  
___
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] I want to add more info with -v option

[avih via Tinycc-devel]

 
I also think the hash should be there.
git describe can be useful here too.

 On Wednesday, March 31, 2021, 06:44:39 PM GMT+3, Dmitry Selyutin 
 wrote:  
 
 Hi Jullien,
I think this is a really good idea. I'd also consider git hash, not a date, but 
this is likely a minor.
> +TCC_GIT_DATE=$(shell which gut > /dev/null 2>&1 && git log -1 --format=%ad 
> --date=local || echo no)
Did you mean "git" here, not 
"gut"?___
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] [PATCH] arm-asm-testsuite.sh: Refactor to allow bigger tests

[avih via Tinycc-devel]

 local in a sh script is not posix, and while some shells do support it, some 
do not,
e.g. ksh 88/93 (frequently used on traditional unix systems), yash, and more.

So portable sh scripts should not use local.

- avih

 On Sunday, February 14, 2021, 09:30:48 PM GMT+2, Danny Milosavljevic 
 wrote:  
 
 ---
 tests/arm-asm-testsuite.sh | 78 --
 1 file changed, 50 insertions(+), 28 deletions(-)

diff --git a/tests/arm-asm-testsuite.sh b/tests/arm-asm-testsuite.sh
index 61c5dad..ae36eb1 100755
--- a/tests/arm-asm-testsuite.sh
+++ b/tests/arm-asm-testsuite.sh
@@ -2,6 +2,53 @@
 
 set -e
 
+# Parameter 1: source file name
+# Parameter 2: unique test id
+# Return value: Whether instruction worked in GNU as
+# Side effect: Files in ${state}: "expected-"*, "got-"*, maybe "ok-"*
+run_test() {
+    local s
+    local err
+    local as_object
+    local tcc_object
+    local expected
+    local got
+    local source_file
+    source_file="$1"
+    s="$2"
+    #echo ".syntax unified" > a.s
+    err="`mktemp --suffix=-stderr.log`"
+    as_object="${state}/as-$s.o"
+    tcc_object="${state}/tcc-$s.o"
+    expected="${state}/expected-$s"
+    got="${state}/got-$s"
+    if "${CROSS_COMPILE}as" -mlittle-endian ${as_opts} -o "${as_object}" 
"${source_file}" 2>"${err}"
+    then
+        cat "${err}"
+        rm -f "${err}"
+        "${CROSS_COMPILE}objdump" -S "${as_object}" |grep "^[ ]*0:" 
>"${expected}"
+        if ${TCC} -o "${tcc_object}" -c "${source_file}"
+        then
+            "${CROSS_COMPILE}objdump" -S "${tcc_object}" |grep "^[ ]*0:" 
>"${got}"
+            if diff -u "${got}" "${expected}"
+            then
+                touch "${state}/ok-$s"
+            else
+                echo "warning: '$s' did not work in tcc (see above)">&2
+            fi
+        else
+            rm -f "${tcc_object}"
+            echo "warning: '$s' did not work in tcc">&2
+        fi
+        rm -f "${err}"
+        return 0
+    else # GNU as can't do it either--so we don't care
+        rm -f "${as_object}"
+    fi
+    rm -f "${err}"
+    return 1
+}
+
 # Note: "{r3}" is definitely different--but would complicate the assembler.
 
 state="`mktemp -d`"
@@ -166,38 +213,13 @@ do
                    "d4, s3" \
                 ""
     do
-        #echo ".syntax unified" > a.s
-        err="`mktemp --suffix=-stderr.log`"
-        as_object="${state}/as-$s $args.o"
-        tcc_object="${state}/tcc-$s $args.o"
-        expected="${state}/expected-$s $args"
-        got="${state}/got-$s $args"
-        if echo "$s $args" | "${CROSS_COMPILE}as" -mlittle-endian ${as_opts} 
-o "${as_object}" - 2>"${err}"
+        src="${state}/src-${s} ${args}.s"
+        echo "${s} ${args}" > "${src}"
+        if run_test "${src}" "${s} ${args}"
         then
-            cat "${err}"
-            rm -f "${err}"
             total_count=`expr $total_count + 1`
-            "${CROSS_COMPILE}objdump" -S "${as_object}" |grep "^[ ]*0:" 
>"${expected}"
-
-            #echo '__asm__("'"$s ${args}"'");' > "${csource}"
-            if echo '__asm__("'"$s ${args}"'");'| ${TCC} -o "${tcc_object}" -c 
-
-            then
-                "${CROSS_COMPILE}objdump" -S "${tcc_object}" |grep "^[ ]*0:" 
>"${got}"
-                if diff -u "${got}" "${expected}"
-                then
-                    touch "${state}/ok-$s $args"
-                else
-                    echo "warning: '$s $args' did not work in tcc (see 
above)">&2
-                fi
-            else
-                rm -f "${tcc_object}"
-                echo "warning: '$s $args' did not work in tcc">&2
-            fi
             ok=1
-        else # GNU as can't do it either--so we don't care
-            rm -f "${as_object}"
         fi
-        rm -f "${err}"
     done
     if [ "${ok}" -eq "0" ]
     then

___
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] Reformatting Tinycc source code

[avih via Tinycc-devel]

 There is a CodingStyle file, and the second paragraph clearly
states (rightly) that style-only changes should be avoided.

The instructions at this file are still valid.

- avih


 On Wednesday, December 2, 2020, 01:08:33 PM GMT+2, Tyge Løvset 
 wrote:  
 
 I have slowly started to look into the core code of tinycc, but can't help 
being annoyed by the inconsistent formatting of the code, in particular the 
mixing of tabs and spaces. (sometimes tabs means 4 indents, sometimes 8). Here 
is a suggestion for an Artistic Style - Index (sourceforge.net) configuration, 
which follows the overall existing formatting style (save it e.g.  as 
tcc_astyle):
### use K brackets style with 4 spaces indent
--style=kr
### indenting--min-conditional-indent=0--max-continuation-indent=50
### add/remove paddings--pad-header--pad-oper--unpad-paren
### keep one-liners--keep-one-line-blocks--keep-one-line-statements
### considered...
#--indent-preproc-block#--indent-col1-comments#--indent=spaces=2#--indent-labels
### create no backup file (already in git)--suffix=none
Reformat the code in-place by: astyle --options=tcc_astyle *.c *.h
I omitted --indent-labels, but default K style is to have labels at first 
column, and they are much easier to spot, e.g. those in between switch case 
labels...
Would anyone care to review the changes it creates, before a possible commit? 
So far it looks good, and I haven't spotted any errors created by the 
reformatting so far.
___
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] Programmer to Programmer

[avih via Tinycc-devel]

 
I already replied to it the last time you asked:
https://lists.nongnu.org/archive/html/tinycc-devel/2020-09/msg00034.html

 On Wednesday, September 23, 2020, 10:22:40 PM GMT+3, Thema 
 wrote:  
 
 Dear tcc Development Team;
I have downloaded the latest version of the Tiny C Compiler butwhen I try to 
run a program compiled by it, I get an error messageabout the exec format being 
invalid. I suppose that the ELF headeris not compatible with the current 
operating system in use. Is thereanother version of tcc that I can download and 
use?
Sincerely,
Thema Guishard

On Mon, Sep 14, 2020 at 9:17 AM Thema  wrote:

Dear tcc Development Team;

I have downloaded the latest version of the Tiny C Compiler butwhen I try to 
run a program compiled by it, I get an error messageabout the exec format being 
invalid. I suppose that the ELF headeris not compatible with the current 
operating system in use. Is thereanother version of tcc that I can download and 
use?
Sincerely,
Thema Guishard

Hello TCC Workers;

I noticed that the tcc compiler does not separate the compiler program and the 
linker program.  I am in the process of developing an ELF64 linker for the 
Linux 64-bit Operating System called 'tgld'.I was wondering if you can include 
a weblink to the linker after testing.

 SIncerely, 

 


Thema Guishard


-- 
Thema Guishard___
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] Programmer to Programmer

[avih via Tinycc-devel]

 On Monday, September 14, 2020, 04:18:21 PM GMT+3, Thema  
wrote:

> I have downloaded the latest version of the Tiny C Compiler but
> when I try to run a program compiled by it, I get an error message
> about the exec format being invalid. I suppose that the ELF header
> is not compatible with the current operating system in use. Is there
> another version of tcc that I can download and use?

You didn't state where you downloaded it from, but regardless, tcc
does not distribute binaries - you have to build it yourself.
The source is at: https://repo.or.cz/tinycc.git

If it doesn't work after you compiled it yourself, then you should
report it here at the mailing list together with platform details,
exact error messages, logs, and anything else you think is relevant.

Or, if your distribution provides it - you should contact them.

There is a sort of official win32 binary here:
http://download.savannah.nongnu.org/releases/tinycc/

But it sounds like you use linux, so it's not relevant to you.


> I noticed that the tcc compiler does not separate the
> compiler program and the linker program. I am in the
> process of developing an ELF64 linker for the Linux
> 64-bit Operating System called 'tgld'.I was wondering 
> if you can include a weblink to the linker after testing.

This is my personal opinion only, but I don't see a relation
between the fact the the linker is built-in to adding a link
to an external linker.

If you think the internal linker is broken, then you should
report it here at the list, or, even better - suggest a fix.

Additionally, it doesn't sound like your linker is ready at
this point in time, and there are enough linkers out there
which people can use already if they prefer.

Bottom line, personally I don't see a reason to link to it.

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

Re: [Tinycc-devel] It seem I pull code in wrong way. How can I revert it?

[avih via Tinycc-devel]

 You already quoted the reply, but in order of descending precedence:

- 4 spaces is the preferred style with new files or new functions.

- Keep the style of the current file if it's obvious (fully/mostly tabs
 or fully/mostly N spaces).

- If a file is mixed style already, do your best effort to keep the
 code which you touch in the same style as the immediate surrounding
 code, with some bias towards 4 spaces.

avih
 On Saturday, September 12, 2020, 04:06:38 PM GMT+3, Kyryl Melekhin 
 wrote:  
 
 What I mean is, just look at this : https://ibb.co/VWzGSt3

сб, 12 сент. 2020 г. в 08:44, Kyryl Melekhin :
>
> About formatting, what's the preferred vim setting you use? I looked
> through the code and couldn't figure out what it was, it seemed so
> inconsistent so I just thought you guys don't care about that.
>
> сб, 12 сент. 2020 г. в 05:55, grischka :
> >
> > avih via Tinycc-devel wrote:
> > >
> > > While force-pushing is usually possible, I'd argue that at the tcc repo
> > > (and generally elsewhere too, but to each his own practices) no one
> > > should force push except maybe maintainers and maybe other regular
> > > contributors which 100% know what they're doing when force-pushing.
> >
> > So I did put on my "maintainer hat" in this case.
> >
> > Pursuer2's patch "misplaced parenthese around ..." is now on top of
> > mob as it was before his pushes.  Kyryl's patch "fix float to u64..."
> > still has bugs (<< vs >>) and adds bad formatting unnecessarily.
> >
> > To all:
> >
> > In the future, please use git cherry-pick or git rebase to put
> > your patches on top of the current public mob branch, first.
> >
> > And as always:
> > * test before you push.
> >
> > * don't add tabs and use 4 spaces to indent.  (Don't use emacs or
> >    configure appropriately its automatisms.).
> >
> > * don't change lines that you did not change.
> >
> > Thanks,
> >
> > --- gr
> >
> > >
> > > I.e. if you want something reverted at the mob repo, please ask here
> > > at the mailing list and one of the regulars will judge how to handle
> > > the request, IMHO.
> > >
> > > - avih
> >
> > ___
> > 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
  ___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] It seem I pull code in wrong way. How can I revert it?

[avih via Tinycc-devel]

 
While force-pushing is usually possible, I'd argue that at the tcc repo
(and generally elsewhere too, but to each his own practices) no one
should force push except maybe maintainers and maybe other regular
contributors which 100% know what they're doing when force-pushing.

I.e. if you want something reverted at the mob repo, please ask here
at the mailing list and one of the regulars will judge how to handle
the request, IMHO.

- avih

 On Friday, September 11, 2020, 09:29:29 PM GMT+3, Patrick Hammer 
 wrote:  
 
 Hi!
Force pushing is dangerous, make sure to have a copy of the repo backed 
up!Sometimes it's necessary though. If you need to do it, make sure that each 
developer re-clones the repository!I had to do it yesterday for 
https://github.com/opennars/opennars-for-applicationsas one author pushed with 
a wrong email address, and this demands a rebase, which changes all 
commit hashes beginning from the edited commit.

Best regards,Patrick

Am Fr., 11. Sept. 2020 um 17:25 Uhr schrieb Pursuer <1596067...@qq.com>:

I found a way to remove these empty commit, by use "git rebase -i".  But I 
can't push these change without -f flag, and I have been told that do NOT use 
"git push -f". So I can only give up to revert it.

-- Original --From: "tinycc-devel" 
;Date: Fri, Sep 11, 2020 11:35 PMTo: 
"tinycc-devel";Cc: "Larry 
Doolittle";Subject: Re: [Tinycc-devel] It seem I pull 
code in wrong way. How can I revert it?
Pursuer -

On Fri, Sep 11, 2020 at 11:27:05PM +0800, Pursuer wrote:
> I'm sorry that I pull code in wrong way.
> And now there are many commit like
> Merge branch 'mob' of git://repo.or.cz/tinycc into mob
> How can I remove them.

Obligatory xkcd:
https://xkcd.com/1597/

There are fancier (and arguably more efficient) ways to recover than
"delete the project, and download a fresh copy".
But they're harder to explain and understand.

  - Larry

___
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

___
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] tcc-0.9.27-win64-bin.zip is missing tiny_impdef.exe

[avih via Tinycc-devel]

 It's now embedded into the tcc binary.
See docs/tcc-win32.txt

 On Saturday, August 29, 2020, 12:33:50 PM GMT+3, Vaidas BoQsc 
 wrote:  
 
 I downloaded tcc-0.9.27-win64-bin.zip from
http://download.savannah.gnu.org/releases/tinycc/

And in this release I couldn't find tiny_impdef.exe
that do exist in the tcc-0.9.24-win32-bin.zip release

Why was tiny_impdef.exe removed?

___
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] macos: new tcc command line option?

[avih via Tinycc-devel]

 I don't have proper gcc installed (via brew or macports), but I think it would
make sense to first check what gcc does and supports.

On the other hand, if it's only aliases to existing options, possibly which are
enabled only on OSX, then I don't think [m]any would object, and it should
be fairly simple to add and possibly revert later.


 On Saturday, July 11, 2020, 08:09:07 AM GMT+3, Christian Jullien 
 wrote:  
 
 
Hi maintainers,

  

As often, Apple reinvent the wheel and makes things differently.

Among other, clang handles shared libs .dylib with a different set of compiler 
options.

For example, -shared is replaced by –dynamiclib etc…

  

It means that a ./configure must test if it uses clang or tcc and adapt its 
compiler options.

  

Question: with proper #if/#endif do you allow me to handle clang specific 
options on macos?

  

FYI I currently see 4/5 options to add (or at least silently drop) to support 
tcc on macos with a better compatibility with clang.

  

C.
___
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] [issue] macos: tcc cannot self-host with --disable-static

[avih via Tinycc-devel]

 Thanks.

Yeah, I was suspecting it could have been the case. Nevertheless, I thought it's
worth noting, for the record.

Cheers.


 On Friday, July 10, 2020, 02:56:19 PM GMT+3, Christian Jullien 
 wrote:  
 
 Thank you for testing the different configure options on macos.
I can easily fix this but it will fail later. I'm not sure that tcc is 
currently able to generate .dylib

tcc -shared -o libtcc.dylib libtcc.o tccpp.o tccgen.o tccelf.o tccasm.o 
tccrun.o x86_64-gen.o x86_64-link.o i386-asm.o tccmacho.o
tcc: error: _main not defined

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of avih via Tinycc-devel
Sent: Friday, July 10, 2020 11:42
To: tinycc-devel@nongnu.org
Cc: avih
Subject: [Tinycc-devel] [issue] macos: tcc cannot self-host with 
--disable-static

Self-hosting with static linking works fine:


[ -e ./conftest.c ] || { echo error: not tcc root; exit 1; }
rm -rf ./bld ./bldself ./dist1 2>/dev/null || :

mkdir bld && cd bld && \
../configure --prefix=$(pwd)/../dist1 && make && make test && make install

cd .. && mkdir bldself && cd bldself && \
../configure --cc=$(pwd)/../dist1/bin/tcc && make && make test


However, if changing the last line to:
../configure --disable-static --cc=$(pwd)/../dist1/bin/tcc && make && make test

then `make' fails at the end on this line:

<...>/../dist1/bin/tcc -dynamiclib -current_version 0.9.27 
-compatibility_version 0.9.27 -install_name @rpath/libtcc.dylib -o libtcc.dylib 
libtcc.o tccpp.o tccgen.o tccelf.o tccasm.o tccrun.o x86_64-gen.o x86_64-link.o 
i386-asm.o tccmacho.o


with:
tcc: error: invalid option -- '-current_version'
make: *** [libtcc.dylib] Error 1


I guess it's somewhat expected that these options are not currently
supported, but I think it would be nice if tcc could self-host a dynamically
linked tcc.

Avi

___
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
  ___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] [issue] macos: tcc cannot self-host with --disable-static

[avih via Tinycc-devel]

Self-hosting with static linking works fine:


[ -e ./conftest.c ] || { echo error: not tcc root; exit 1; }
rm -rf ./bld ./bldself ./dist1 2>/dev/null || :

mkdir bld && cd bld && \
../configure --prefix=$(pwd)/../dist1 && make && make test && make install

cd .. && mkdir bldself && cd bldself && \
../configure --cc=$(pwd)/../dist1/bin/tcc && make && make test


However, if changing the last line to:
../configure --disable-static --cc=$(pwd)/../dist1/bin/tcc && make && make test

then `make' fails at the end on this line:

<...>/../dist1/bin/tcc -dynamiclib -current_version 0.9.27 
-compatibility_version 0.9.27 -install_name @rpath/libtcc.dylib -o libtcc.dylib 
libtcc.o tccpp.o tccgen.o tccelf.o tccasm.o tccrun.o x86_64-gen.o x86_64-link.o 
i386-asm.o tccmacho.o


with:
tcc: error: invalid option -- '-current_version'
make: *** [libtcc.dylib] Error 1


I guess it's somewhat expected that these options are not currently
supported, but I think it would be nice if tcc could self-host a dynamically
linked tcc.

Avi

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

Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after cleanup

[avih via Tinycc-devel]

 
I've pushed a fix to mob to support arbitrary libdir (c69290fb).

The relative path is now used during `make test', while the fixed libdir is 
used after install.

 On Thursday, July 9, 2020, 09:12:06 PM GMT+3, avih via Tinycc-devel 
 wrote:  
 
  Note to self: Make sure to double check before posting.

Turns out ./dist/lib/ remained from the previous install, which I didn't delete
before testing with --libdir=$(pwd)/dist/mylibs.

Indeed, it only creates ./dist/mylibs, and indeed it fails to find the dylib
when running ./dist/bin/tcc, (make test still works).


 On Thursday, July 9, 2020, 09:02:24 PM GMT+3, avih  
wrote:  
 
  Thanks. I can confirm current mob (6c94df6) does work also with custom prefix,
as well as building in a custom dir (mkdir build && cd build && ../configure 
...).

However, looking at that commit, I thought it would break with a custom 
--libdir,
like ./configure --libdir=$(pwd)/dist/mylibs but I tried it and it still worked.

Turns out it creates both ./dist/lib and ./dist/mylibs, and libtcc.dylib is at 
both
of them as well as tcc/ and its content (duplicated at both dirs), though 
libtcc.a
is only at ./dist/lib/ .

Is that expected? I never tried using --libdir before, but commit 6c94df6 makes 
it look
a bit hardcoded, so I tried it now. Wouldn't it be better to specify the 
absolute
install [libdir] ?

Avi


 On Thursday, July 9, 2020, 08:40:42 PM GMT+3, Christian Jullien 
 wrote:  
 
 #yiv6312635793 -- filtered {}#yiv6312635793 filtered {}#yiv6312635793 filtered 
{}#yiv6312635793 filtered {}#yiv6312635793 filtered {}#yiv6312635793 
p.yiv6312635793MsoNormal, #yiv6312635793 li.yiv6312635793MsoNormal, 
#yiv6312635793 div.yiv6312635793MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:New;}#yiv6312635793
 a:link, #yiv6312635793 span.yiv6312635793MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv6312635793 a:visited, #yiv6312635793 
span.yiv6312635793MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv6312635793 
p.yiv6312635793msonormal, #yiv6312635793 li.yiv6312635793msonormal, 
#yiv6312635793 div.yiv6312635793msonormal 
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:New;}#yiv6312635793
 p.yiv6312635793msonormal1, #yiv6312635793 li.yiv6312635793msonormal1, 
#yiv6312635793 div.yiv6312635793msonormal1 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv6312635793 
span.yiv6312635793msohyperlink {}#yiv6312635793 
span.yiv6312635793msohyperlinkfollowed {}#yiv6312635793 
span.yiv6312635793emailstyle17 {}#yiv6312635793 span.yiv6312635793msohyperlink1 
{color:blue;text-decoration:underline;}#yiv6312635793 
span.yiv6312635793msohyperlinkfollowed1 
{color:purple;text-decoration:underline;}#yiv6312635793 
span.yiv6312635793emailstyle171 {color:#1F497D;}#yiv6312635793 
span.yiv6312635793EmailStyle25 {color:#1F497D;}#yiv6312635793 
span.yiv6312635793EmailStyle26 {color:#1F497D;}#yiv6312635793 
.yiv6312635793MsoChpDefault {font-size:10.0pt;}#yiv6312635793 filtered 
{}#yiv6312635793 div.yiv6312635793WordSection1 {}#yiv6312635793 
I’ve found another (and better) way to achieve this:

-Wl,-rpath,"@executable_path/$(TOP)" -Wl,-rpath,"@executable_path/$(TOP)/../lib"

  

It is commited, can you please test this one.

  

  

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Christian Jullien
Sent: Thursday, July 09, 2020 19:07
To: tinycc-devel@nongnu.org; jull...@eligis.com
Cc: 'avih'
Subject: Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after 
cleanup

  

Thanks avih, another step is missing (it works well with default install 
location)

Can you please test this:

$ install_name_tool -add_rpath "@executable_path/../lib/" tcc

$ make install

$ ./dist/bin/tcc -vv

tcc version 0.9.27 (x86_64 Darwin)

install: /Users/jullien/tinycc/dist/lib/tcc

…

  

It work for me. If it also works for you I’ll add this step to macos build

  

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of avih via Tinycc-devel
Sent: Thursday, July 09, 2020 18:23
To: tinycc-devel@nongnu.org; jull...@eligis.com
Cc: avih
Subject: Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after 
cleanup

  


Seems that moving ./dist/lib/libtcc.dylib to ./dist/bin/ makes it work,
compile programs successfully, and -run works as well.

So it seems that install target doesn't take everything into account.

On Thursday, July 9, 2020, 07:17:38 PM GMT+3, avih  wrote: 

  

  


Oh, I missed the commits from today.

Indeed, with latest mob (6bd0ced) this now succeeds:
./configure --disable-static && make && make test

However, when building and installing like this:
./configure --disable-static --prefix=$(pwd)/dist && make && make test && make 
install

Then it succeeds, but the tcc binary seems missing the dylib:
$ ./dist/bin/tcc
dyld: Library not loaded: @rpath/libtc

Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after cleanup

[avih via Tinycc-devel]

 Note to self: Make sure to double check before posting.

Turns out ./dist/lib/ remained from the previous install, which I didn't delete
before testing with --libdir=$(pwd)/dist/mylibs.

Indeed, it only creates ./dist/mylibs, and indeed it fails to find the dylib
when running ./dist/bin/tcc, (make test still works).


 On Thursday, July 9, 2020, 09:02:24 PM GMT+3, avih  
wrote:  
 
  Thanks. I can confirm current mob (6c94df6) does work also with custom prefix,
as well as building in a custom dir (mkdir build && cd build && ../configure 
...).

However, looking at that commit, I thought it would break with a custom 
--libdir,
like ./configure --libdir=$(pwd)/dist/mylibs but I tried it and it still worked.

Turns out it creates both ./dist/lib and ./dist/mylibs, and libtcc.dylib is at 
both
of them as well as tcc/ and its content (duplicated at both dirs), though 
libtcc.a
is only at ./dist/lib/ .

Is that expected? I never tried using --libdir before, but commit 6c94df6 makes 
it look
a bit hardcoded, so I tried it now. Wouldn't it be better to specify the 
absolute
install [libdir] ?

Avi


 On Thursday, July 9, 2020, 08:40:42 PM GMT+3, Christian Jullien 
 wrote:  
 
 #yiv8281334735 -- filtered {}#yiv8281334735 filtered {}#yiv8281334735 filtered 
{}#yiv8281334735 filtered {}#yiv8281334735 filtered {}#yiv8281334735 
p.yiv8281334735MsoNormal, #yiv8281334735 li.yiv8281334735MsoNormal, 
#yiv8281334735 div.yiv8281334735MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:New;}#yiv8281334735
 a:link, #yiv8281334735 span.yiv8281334735MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv8281334735 a:visited, #yiv8281334735 
span.yiv8281334735MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv8281334735 
p.yiv8281334735msonormal, #yiv8281334735 li.yiv8281334735msonormal, 
#yiv8281334735 div.yiv8281334735msonormal 
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:New;}#yiv8281334735
 p.yiv8281334735msonormal1, #yiv8281334735 li.yiv8281334735msonormal1, 
#yiv8281334735 div.yiv8281334735msonormal1 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8281334735 
span.yiv8281334735msohyperlink {}#yiv8281334735 
span.yiv8281334735msohyperlinkfollowed {}#yiv8281334735 
span.yiv8281334735emailstyle17 {}#yiv8281334735 span.yiv8281334735msohyperlink1 
{color:blue;text-decoration:underline;}#yiv8281334735 
span.yiv8281334735msohyperlinkfollowed1 
{color:purple;text-decoration:underline;}#yiv8281334735 
span.yiv8281334735emailstyle171 {color:#1F497D;}#yiv8281334735 
span.yiv8281334735EmailStyle25 {color:#1F497D;}#yiv8281334735 
span.yiv8281334735EmailStyle26 {color:#1F497D;}#yiv8281334735 
.yiv8281334735MsoChpDefault {font-size:10.0pt;}#yiv8281334735 filtered 
{}#yiv8281334735 div.yiv8281334735WordSection1 {}#yiv8281334735 
I’ve found another (and better) way to achieve this:

-Wl,-rpath,"@executable_path/$(TOP)" -Wl,-rpath,"@executable_path/$(TOP)/../lib"

  

It is commited, can you please test this one.

  

  

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Christian Jullien
Sent: Thursday, July 09, 2020 19:07
To: tinycc-devel@nongnu.org; jull...@eligis.com
Cc: 'avih'
Subject: Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after 
cleanup

  

Thanks avih, another step is missing (it works well with default install 
location)

Can you please test this:

$ install_name_tool -add_rpath "@executable_path/../lib/" tcc

$ make install

$ ./dist/bin/tcc -vv

tcc version 0.9.27 (x86_64 Darwin)

install: /Users/jullien/tinycc/dist/lib/tcc

…

  

It work for me. If it also works for you I’ll add this step to macos build

  

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of avih via Tinycc-devel
Sent: Thursday, July 09, 2020 18:23
To: tinycc-devel@nongnu.org; jull...@eligis.com
Cc: avih
Subject: Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after 
cleanup

  


Seems that moving ./dist/lib/libtcc.dylib to ./dist/bin/ makes it work,
compile programs successfully, and -run works as well.

So it seems that install target doesn't take everything into account.

On Thursday, July 9, 2020, 07:17:38 PM GMT+3, avih  wrote: 

  

  


Oh, I missed the commits from today.

Indeed, with latest mob (6bd0ced) this now succeeds:
./configure --disable-static && make && make test

However, when building and installing like this:
./configure --disable-static --prefix=$(pwd)/dist && make && make test && make 
install

Then it succeeds, but the tcc binary seems missing the dylib:
$ ./dist/bin/tcc
dyld: Library not loaded: @rpath/libtcc.dylib
Referenced from: /Users/avih/dev/tcc/tcc.upstream/./dist/bin/tcc
Reason: image not found
Abort trap: 6

When not using --disable-static, then tcc runs fine, compiles and even -run 
works.

On Thursday, July 9, 2020, 07:07:12 PM GMT+3, Christian 

Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after cleanup

[avih via Tinycc-devel]

 Thanks. I can confirm current mob (6c94df6) does work also with custom prefix,
as well as building in a custom dir (mkdir build && cd build && ../configure 
...).

However, looking at that commit, I thought it would break with a custom 
--libdir,
like ./configure --libdir=$(pwd)/dist/mylibs but I tried it and it still worked.

Turns out it creates both ./dist/lib and ./dist/mylibs, and libtcc.dylib is at 
both
of them as well as tcc/ and its content (duplicated at both dirs), though 
libtcc.a
is only at ./dist/lib/ .

Is that expected? I never tried using --libdir before, but commit 6c94df6 makes 
it look
a bit hardcoded, so I tried it now. Wouldn't it be better to specify the 
absolute
install [libdir] ?

Avi


 On Thursday, July 9, 2020, 08:40:42 PM GMT+3, Christian Jullien 
 wrote:  
 
 #yiv960526 #yiv960526 -- _filtered {} _filtered {} _filtered {} 
_filtered {} _filtered {}#yiv960526 #yiv960526 
p.yiv960526MsoNormal, #yiv960526 li.yiv960526MsoNormal, 
#yiv960526 div.yiv960526MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:New;}#yiv960526
 a:link, #yiv960526 span.yiv960526MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv960526 a:visited, #yiv960526 
span.yiv960526MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv960526 
p.yiv960526msonormal, #yiv960526 li.yiv960526msonormal, 
#yiv960526 div.yiv960526msonormal 
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:New;}#yiv960526
 p.yiv960526msonormal1, #yiv960526 li.yiv960526msonormal1, 
#yiv960526 div.yiv960526msonormal1 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv960526 
span.yiv960526msohyperlink {}#yiv960526 
span.yiv960526msohyperlinkfollowed {}#yiv960526 
span.yiv960526emailstyle17 {}#yiv960526 span.yiv960526msohyperlink1 
{color:blue;text-decoration:underline;}#yiv960526 
span.yiv960526msohyperlinkfollowed1 
{color:purple;text-decoration:underline;}#yiv960526 
span.yiv960526emailstyle171 {color:#1F497D;}#yiv960526 
span.yiv960526EmailStyle25 {color:#1F497D;}#yiv960526 
span.yiv960526EmailStyle26 {color:#1F497D;}#yiv960526 
.yiv960526MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv960526 
div.yiv960526WordSection1 {}#yiv960526 
I’ve found another (and better) way to achieve this:

-Wl,-rpath,"@executable_path/$(TOP)" -Wl,-rpath,"@executable_path/$(TOP)/../lib"

  

It is commited, can you please test this one.

  

  

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Christian Jullien
Sent: Thursday, July 09, 2020 19:07
To: tinycc-devel@nongnu.org; jull...@eligis.com
Cc: 'avih'
Subject: Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after 
cleanup

  

Thanks avih, another step is missing (it works well with default install 
location)

Can you please test this:

$ install_name_tool -add_rpath "@executable_path/../lib/" tcc

$ make install

$ ./dist/bin/tcc -vv

tcc version 0.9.27 (x86_64 Darwin)

install: /Users/jullien/tinycc/dist/lib/tcc

…

  

It work for me. If it also works for you I’ll add this step to macos build

  

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of avih via Tinycc-devel
Sent: Thursday, July 09, 2020 18:23
To: tinycc-devel@nongnu.org; jull...@eligis.com
Cc: avih
Subject: Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after 
cleanup

  


Seems that moving ./dist/lib/libtcc.dylib to ./dist/bin/ makes it work,
compile programs successfully, and -run works as well.

So it seems that install target doesn't take everything into account.

On Thursday, July 9, 2020, 07:17:38 PM GMT+3, avih  wrote: 

  

  


Oh, I missed the commits from today.

Indeed, with latest mob (6bd0ced) this now succeeds:
./configure --disable-static && make && make test

However, when building and installing like this:
./configure --disable-static --prefix=$(pwd)/dist && make && make test && make 
install

Then it succeeds, but the tcc binary seems missing the dylib:
$ ./dist/bin/tcc
dyld: Library not loaded: @rpath/libtcc.dylib
Referenced from: /Users/avih/dev/tcc/tcc.upstream/./dist/bin/tcc
Reason: image not found
Abort trap: 6

When not using --disable-static, then tcc runs fine, compiles and even -run 
works.

On Thursday, July 9, 2020, 07:07:12 PM GMT+3, Christian Jullien 
 wrote: 

  

  

?? can you please try with mob and give me the complete log?

 

The fix is “macos: tcc searches for libtcc.dyln in the same directory as its 
executable”

 

C.

 

From: avih [mailto:avih...@yahoo.com] 
Sent: Thursday, July 09, 2020 17:52
To: jull...@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after 
cleanup

 

What's the fix? I tried lo

Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after cleanup

[avih via Tinycc-devel]

 
Seems that moving ./dist/lib/libtcc.dylib to ./dist/bin/ makes it work,
compile programs successfully, and -run works as well.

So it seems that install target doesn't take everything into account.

 On Thursday, July 9, 2020, 07:17:38 PM GMT+3, avih  
wrote:  
 
  
Oh, I missed the commits from today.

Indeed, with latest mob (6bd0ced) this now succeeds:
./configure --disable-static && make && make test

However, when building and installing like this:
./configure --disable-static --prefix=$(pwd)/dist && make && make test && make 
install

Then it succeeds, but the tcc binary seems missing the dylib:
$ ./dist/bin/tcc
dyld: Library not loaded: @rpath/libtcc.dylib
 Referenced from: /Users/avih/dev/tcc/tcc.upstream/./dist/bin/tcc
 Reason: image not found
Abort trap: 6

When not using --disable-static, then tcc runs fine, compiles and even -run 
works.

 On Thursday, July 9, 2020, 07:07:12 PM GMT+3, Christian Jullien 
 wrote:  
 
 #yiv6760391554 -- filtered {}#yiv6760391554 filtered {}#yiv6760391554 filtered 
{}#yiv6760391554 filtered {}#yiv6760391554 p.yiv6760391554MsoNormal, 
#yiv6760391554 li.yiv6760391554MsoNormal, #yiv6760391554 
div.yiv6760391554MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:New;}#yiv6760391554
 a:link, #yiv6760391554 span.yiv6760391554MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv6760391554 a:visited, #yiv6760391554 
span.yiv6760391554MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv6760391554 
span.yiv6760391554EmailStyle17 {color:#1F497D;}#yiv6760391554 
span.yiv6760391554datetime {}#yiv6760391554 .yiv6760391554MsoChpDefault 
{}#yiv6760391554 filtered {}#yiv6760391554 div.yiv6760391554WordSection1 
{}#yiv6760391554 
?? can you please try with mob and give me the complete log?

  

The fix is “macos: tcc searches for libtcc.dyln in the same directory as its 
executable”

  

C.

  

From: avih [mailto:avih...@yahoo.com] 
Sent: Thursday, July 09, 2020 17:52
To: jull...@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after 
cleanup

  

What's the fix? I tried looking at the earlier messages, but didn't
see a diff/patch.

For me on osx 10.13 (real MBA) I also have the same issue when
using --disable-static, but it seems fine without it, including -run.

On Thursday, July 9, 2020, 06:38:10 PM GMT+3, Michael Matz 
 wrote: 

  

  

Hello Christian,

(I missed the question earlier, apologies)

On Thu, 9 Jul 2020, Christian Jullien wrote:

> If you have a moment, can you please test if my macos fix for dyld also 
> works on your configuration?

Yes, it works fine here on my emulated macOS.




Ciao,
Michael.

___
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
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after cleanup

[avih via Tinycc-devel]

 
Oh, I missed the commits from today.

Indeed, with latest mob (6bd0ced) this now succeeds:
./configure --disable-static && make && make test

However, when building and installing like this:
./configure --disable-static --prefix=$(pwd)/dist && make && make test && make 
install

Then it succeeds, but the tcc binary seems missing the dylib:
$ ./dist/bin/tcc
dyld: Library not loaded: @rpath/libtcc.dylib
 Referenced from: /Users/avih/dev/tcc/tcc.upstream/./dist/bin/tcc
 Reason: image not found
Abort trap: 6

When not using --disable-static, then tcc runs fine, compiles and even -run 
works.

 On Thursday, July 9, 2020, 07:07:12 PM GMT+3, Christian Jullien 
 wrote:  
 
 #yiv1885721961 #yiv1885721961 -- _filtered {} _filtered {} _filtered {} 
_filtered {}#yiv1885721961 #yiv1885721961 p.yiv1885721961MsoNormal, 
#yiv1885721961 li.yiv1885721961MsoNormal, #yiv1885721961 
div.yiv1885721961MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:New;}#yiv1885721961
 a:link, #yiv1885721961 span.yiv1885721961MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv1885721961 a:visited, #yiv1885721961 
span.yiv1885721961MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv1885721961 
span.yiv1885721961EmailStyle17 {color:#1F497D;}#yiv1885721961 
span.yiv1885721961datetime {}#yiv1885721961 .yiv1885721961MsoChpDefault {} 
_filtered {}#yiv1885721961 div.yiv1885721961WordSection1 {}#yiv1885721961 
?? can you please try with mob and give me the complete log?

  

The fix is “macos: tcc searches for libtcc.dyln in the same directory as its 
executable”

  

C.

  

From: avih [mailto:avih...@yahoo.com] 
Sent: Thursday, July 09, 2020 17:52
To: jull...@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after 
cleanup

  

What's the fix? I tried looking at the earlier messages, but didn't
see a diff/patch.

For me on osx 10.13 (real MBA) I also have the same issue when
using --disable-static, but it seems fine without it, including -run.

On Thursday, July 9, 2020, 06:38:10 PM GMT+3, Michael Matz 
 wrote: 

  

  

Hello Christian,

(I missed the question earlier, apologies)

On Thu, 9 Jul 2020, Christian Jullien wrote:

> If you have a moment, can you please test if my macos fix for dyld also 
> works on your configuration?

Yes, it works fine here on my emulated macOS.




Ciao,
Michael.

___
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
  ___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after cleanup

[avih via Tinycc-devel]

 What's the fix? I tried looking at the earlier messages, but didn't
see a diff/patch.

For me on osx 10.13 (real MBA) I also have the same issue when
using --disable-static, but it seems fine without it, including -run.

 On Thursday, July 9, 2020, 06:38:10 PM GMT+3, Michael Matz 
 wrote:  
 
 Hello Christian,

(I missed the question earlier, apologies)

On Thu, 9 Jul 2020, Christian Jullien wrote:

> If you have a moment, can you please test if my macos fix for dyld also 
> works on your configuration?

Yes, it works fine here on my emulated macOS.


Ciao,
Michael.

___
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] Tiny c availability

[avih via Tinycc-devel]

 I've built mpv with tcc on both Ubuntu and Alpine linux, though not
recently. It did require patching waf (the build system) because it's
very picky with compiler identification, as well as some minor patches
in mpv to replace few #pragma once with normal include guards.

tcc builds st ( http://st.suckless.org ) perfectly fine, as well as many
other medium-sized projects.

Other than this I do use tcc occasionally to test that it compiles my
projects on both Linux and windows (it usually does, and if not it's
usually not tcc's fault).

And I do also use tcc on Windows occasionally, though I do also have
proper mingw setup with msys2 or cygwin or MXE.

Overall, tcc works pretty well for me, though it's not my main compiler.


 On Thursday, July 9, 2020, 11:35:24 AM GMT+3, Daniel Glöckner 
 wrote:  
 
 On Thu, Jul 09, 2020 at 10:09:56AM +0200, Christian Jullien wrote:
> Many starts with more than one :o)

Even the Pirahã appear to agree that many doesn't start before three.

> Five BIG projects is not that bad.
>
> Let me start with few I very often (if not daily) compile:
> - OpenLisp (daily)
> - bigz (daily)
> - gnumake (every major version)
> - sqlite (daily - part of OpenLisp build)
> - tcc (almost daily)
>
> They already count for FIVE :o)

But you talked about many people, not many projects, and you are only
one person, unless of course you have a split personality. :P

> What about a page referencing projects that build with tcc?

That would also be useful to show what tcc is capable of compiling.

___
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] POSIX compliance; spaces not supported with -l for libs

[avih via Tinycc-devel]

 For me, with current tcc mob (but also with version at least 6 months
old) this does work: tcc hello.c -l c

Which version did you try?

As for -O, it seems that the option-argument is optional - in both
tcc and gcc. The posix syntax for optional arguments is that the
value must follow at the same argument, hence it's obvious why space
doesn't work.

The c99 spec says for -O that "Other optlevel values may be supported."
which doesn't suggest it can be optional, but IMHO compatibility with
gcc and clang options in this regards is stronger than the posix
requirement, i.e. this should work: tcc -O hello.c

Avi


 On Sunday, July 5, 2020, 01:16:12 AM GMT+3, John Scott  
wrote:  
 
 Hi,

I was checking if tcc conforms to the POSIX standard for a C99 compiler [1], 
particularly to make the case for implementing a generic POSIX C compiler 
backend in Meson [2]. In the meantime, tcc can't be used for building. There 
is concern that small compilers all have their own caveats, and tinycc's seem 
minor.

POSIX says a space after -l—and all flags for that matter—is okay, but tcc 
doesn't accept this:
$ tcc hello.c -l c
tcc: error: library '' not found

It also doesn't handle a space after -O. Fortunately -D, -I, -L, and -U all 
tolerate this.

For completeness here's another discrepancy:
* tcc errors with -lxnet or -ltrace, but so do gcc and Clang.

Please let me know if there's anything I can do to help, and thanks for 
working on tinycc!

[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html
[2] 
https://github.com/mesonbuild/meson/issues/5406___
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] חשבון ועד בית

[avih via Tinycc-devel]

 תודה. זה מגיע לתיבת הדואר שלך? או שהם משאירים את זה במקום כללי ואת לוקחת את זה?


 On Wednesday, August 7, 2019, 10:14:29 AM GMT+3, Mai Aylon 
 wrote:  
 
 היי אבימצרפת לך את החשבון של ועד הביתיום נעיםמאי  ___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Duplicate double

[avih via Tinycc-devel]

 Hi,

The simple answer, with MSYS2, to build tcc win64:
- Start MSYS2 shortcut "mingw64", ensure you have mingw gcc x86-64 installed.
- Clone tinycc and cd to the root source dir.
- Run `mkdir build64 && cd build64 && ../configure --cpu=x86-64 
--prefix=$(pwd)/dist && make && make install`
- Now the `./dist/` dir will have a working portable tcc win64 package/files.

To build tcc win32, use the same steps but instead start the "mingw32" MSYS2
shortcut, ensure you have mingw gcc i686 installed, and use --cpu=i386 (and
optionally different build/install dirs).

The resulting tcc will use relative lib/include files.

However, like Christian, I also use a reproducible build script which I wrote.
It can use any compiler (gcc/clang/tcc/etc) on most systems (cygwin, linux,
macOS, freeBSD, etc) to create a reproducible windows tcc compilers with
identical binaries regardless of the system on which it was created.

Like Christian's script, it first builds (possibly) cross compilers tcc for
windows (which target win32 and win64), then uses them to build 32 and 64 tcc
as well as 2 cross compilers (win64 tcc which targets win32, and win32 tcc
which targets win64). Overall 4 distributions.

The dirs I put at the 7z file are the plain 32/64 builds of tcc (not cross).

To use it:
- Get this file: 
https://github.com/avih/tinycc/blob/mob-win32-repro/win32/build-tcc-reproducible.sh
- Place it at the /win32/ dir and cd into that dir.
- Run `rm -rf ./reprobuild; ./build-tcc-reproducible.sh`
- Too see more options, run it with `-h`


Cheers,
Avi

 On Sunday, August 4, 2019, 2:08:17 PM GMT+3, Klaus Ebbe Grue 
 wrote:  
 
 #yiv3347465128 P {MARGIN-BOTTOM:0px;MARGIN-TOP:0px;}#yiv3347465128 P 
{MARGIN-BOTTOM:0px;MARGIN-TOP:0px;}
Hi again Avi,

 

Can I persuade you to tell how you built https://0x0.st/zOsg.7z ?

 

In particular, how you made the lib and includes relative to the location of 
'tcc.exe' for tcc32 and tcc64.

 

Googling around seems to suggest that one should use the right host (MinGW? 
Cygwin?) and use the right ./configure options.

 

Cheers,
Klaus

 

 




Fra: Tinycc-devel [tinycc-devel-bounces+grue=di.ku...@nongnu.org] på vegne af 
Klaus Ebbe Grue [g...@di.ku.dk]
Sendt: 3. august 2019 16:14
Til: tinycc-devel@nongnu.org
Emne: Re: [Tinycc-devel] Duplicate double


Hi Avi,

 

Great! Thanks!

 

https://0x0.st/zOsg.7z worked.

 

Just to test, I made a fresh msys2 install, cloned git://repo.or.cz/tinycc.git 
and compiled. That also works.

 

For completeness, I have included the steps. The only surprise was that when 
using .configure --prefix=/usr I had to add --bindir=/usr/bin since otherwise 
tcc ends up in /usr/tcc.exe

 

Cheers,

Klaus

 

---

 

Remove C:\msys64 if present

Go to https://www.msys2.org/
Click msys2-x86_64-20190524.exe
Install msys2 using defaults

 

In MSYS2 shell:
> pacman -Syu
As instructed, kill and restart MSYS2 shell
> pacman -Syu
> pacman -S gcc git make texinfo
> git clone git://repo.or.cz/tinycc.git
> cd tinycc
> ./configure --prefix=/usr --bindir=/usr/bin
> make
> make install
> cd
> tcc -v
tcc version 0.9.27 (x86_64 Windows)
> mkdir experiment
> cd experiment
> cat>test.c
#include 
void f(double x,double y,double z){printf("f(%4.1f,%4.1f,%4.1f)\n",x,y,z);}
int main(int argc,char **argv){double u=0.0;f(u*1.0,7.0,8.0);return 0;}
> tcc -o test test.c
> ./test
f( 0.0, 7.0, 8.0)


 

 
Fra: Tinycc-devel [tinycc-devel-bounces+grue=di.ku...@nongnu.org] på vegne af 
avih via Tinycc-devel [tinycc-devel@nongnu.org]
Sendt: 3. august 2019 10:31
Til: tinycc-devel@nongnu.org
Cc: avih
Emne: Re: [Tinycc-devel] Duplicate double

You're right, and I can confirm that the win64 version downloaded the
same as you exhibits the same issue, and the issue also exists if
I build 0.27 for win64 myself (git d348a9a).

However, it was apparently fixed shortly after tcc 0.27 was released,
at the following commit:

commit 8f6fcb709ae7b2379866c292ce478ab95dc75b48
Author: grischka 
Date: Thu May 31 23:51:51 2018 +0200

misc fixes

misc fixes including:
- tcc.c: fix "tcc -vv" for libtcc1.a on win32/PE
- tccelf.c: fix a crash when GOT has no relocs (witn -nostdlib)
- tccelf.c: fix stab linkage for zero n_strx
- tccgen.c: fix stdcall decoration for array parameters
int __stdcall func(char buf[10]) is _func@4 (was _func@12)
- tccgen.c: fix static variables with nocode/nodata_wanted
see tests2/96_nodata_wanted.c
- tccrun.c: align sections using sh_addralign (for reliable function_alignment)
- tests2/Makefile sort 100 after 99
- win32/include/sys/stat.h fix _stat and _wstat
- x86_64-gen.c: win64/gfunc_call: fix a bug with xmmN register args
previously overwrote valid other xmmN registers eventually


Not sure which of the fixes did it, but I'd guess it's at x86_64-gen.c .

If you want, I've built tcc for win32 and win64 from the latest git
version (mob, 9e429db), and uploaded it here: https

Re: [Tinycc-devel] Duplicate double

[avih via Tinycc-devel]

 You're right, and I can confirm that the win64 version downloaded the
same as you exhibits the same issue, and the issue also exists if
I build 0.27 for win64 myself (git d348a9a).

However, it was apparently fixed shortly after tcc 0.27 was released,
at the following commit:

commit 8f6fcb709ae7b2379866c292ce478ab95dc75b48
Author: grischka 
Date: Thu May 31 23:51:51 2018 +0200

 misc fixes

 misc fixes including:
 - tcc.c: fix "tcc -vv" for libtcc1.a on win32/PE
 - tccelf.c: fix a crash when GOT has no relocs (witn -nostdlib)
 - tccelf.c: fix stab linkage for zero n_strx
 - tccgen.c: fix stdcall decoration for array parameters
 int __stdcall func(char buf[10]) is _func@4 (was _func@12)
 - tccgen.c: fix static variables with nocode/nodata_wanted
 see tests2/96_nodata_wanted.c
 - tccrun.c: align sections using sh_addralign (for reliable function_alignment)
 - tests2/Makefile sort 100 after 99
 - win32/include/sys/stat.h fix _stat and _wstat
 - x86_64-gen.c: win64/gfunc_call: fix a bug with xmmN register args
 previously overwrote valid other xmmN registers eventually


Not sure which of the fixes did it, but I'd guess it's at x86_64-gen.c .

If you want, I've built tcc for win32 and win64 from the latest git
version (mob, 9e429db), and uploaded it here: https://0x0.st/zOsg.7z

Cheers,
Avi



 On Friday, August 2, 2019, 9:51:22 PM GMT+3, Klaus Ebbe Grue 
 wrote:  
 
 Hi tinycc-devel,

Under MSYS2/MinGW I have a problem with tcc.

I define this functions:

void f(double x,double y,double z){printf("f(%4.1f,%4.1f,%4.1f)\n",x,y,z);}

As an example, f(1,2,3) prints f( 1.0, 2.0, 3.0).

Then I call f from main in a slightly confusing way:

int main(int argc,char **argv){double u=0.0;f(u*1.0,7.0,8.0);return 0;}

I would expect to get f( 0.0, 7.0, 8.0) but I do get f( 7.0, 7.0, 8.0).

The first argument of f becomes a duplicate of the second argument of f.

If I remove "*1.0" then everything works as expected.

Is this a known bug?

By the way, if I make the same program using integers, then there is no problem.

I have included a reproduction scenario below.

Cheers,
Klaus

---

Install MSYS2/MinGW
Start MSYS2 shell

> mkdir experiment
> cd experiment
> wget http://download.savannah.gnu.org/releases/tinycc/tcc-0.9.27-win64-bin.zip
> pacman -S unzip
> unzip tcc-0.9.27-win64-bin.zip
> tcc/tcc -v
tcc version 0.9.27 (x86_64 Windows)
> cat>test.c
#include 
void f(double x,double y,double z){printf("f(%4.1f,%4.1f,%4.1f)\n",x,y,z);}
int main(int argc,char **argv){double u=0.0;f(u*1.0,7.0,8.0);return 0;}
> tcc/tcc -o test test.c
> ./test
f( 7.0, 7.0, 8.0)
___
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] [PATCH] win32: add include/getopt.h with static implementation

[avih via Tinycc-devel]

 > On Wednesday, July 31, 2019, 8:55:18 PM GMT+3, Christian JULLIEN 
 >  wrote:
> 
> This my THIRD attempt to reply to this thread since Jul, 26. The
> two prev. attempts never reached the list. Hope this one will work
> and go to the list!

It did, at least to me (but I was addressed). FWIW, I don't recall seeing
prior replies from you, though I also don't see my reply from today at:
https://lists.nongnu.org/archive/html/tinycc-devel/2019-07/index.html
But the fact that you got it probably means it got through. Not sure
what's up with the list manager...

> As I said previously (basically the same as Michael): ...

> As I'm aware of, the win32 port is not targeted to support POSIX
> applications. While getopt is great, it introduces a third category
> and the gap from POSIX is huge. For example, among others, I would
> love to have mmap.

Indeed. Though when I now think about it again, I'd say the definition
of tcc on Windows would be "like MinGW, but smaller, and extensible to
some extent with additional MinGW headers".

FWIW, MinGW does include getopt.h at its root include dir (I assume
implemented at glibc).

> That said, if the group decides that's a good idea, I will not protest
> but, in this case put getopt.h in a new directory like include/posix
> to make it clear.

Hmm... and make it a default include path? otherwise
`#include ` would not work out of the box, which kind of
defeats its purpose and usefullness IMO.

But anyway, indeed the main question to answer first and foremost is
what's the desirable scope of tcc on windows, and once it's answered
clearly, then hopefully the rest would be easy to derive.

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

Re: [Tinycc-devel] [PATCH] win32: add include/getopt.h with static implementation

[avih via Tinycc-devel]

 Hi Michael,

> > Patch is attached. If there are no objections, I'll push it in few days.
> 
> But why? TCC is a compiler, it doesn't generally provide a C library. 
> Use newlib or musl or the like for that.

You know as well as anyone that the Windows build of tcc is more than
that. It's a self contained vertical package which includes everything
required to build many programs without further dependencies. So your
statement, while correct in general, is not so true for Windows.

Most CLI programs process arguments, and getopt is the standard.


> The underlying objection is basically the answer to the question "where
> do you stop?"

Indeed that is the real question, and the only relevant question IMHO,
to which I don't have an answer, but I think it's along the lines of
"small and generally useful, not full blown".

I'm not familiar with TCC guidelines, official or not, to use it with
newlib or musl. If there were such then I'd agree getopt should not be
part of tcc itself, but I think it's not trivial on Windows, and this
patch is very small in the grand scheme of things, and provides a very
useful functionality.


> So, please no.

So do you have a concrete answer to "where do we stop", or guidelines
to use musl or newlib with tcc for windows?

If yes, then the text should be incorporated into the repo IMO.

If no, then I think getopt has good value and low risk/complexity,
which IMHO makes it worth including for the Windows build.

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

Re: [Tinycc-devel] test 104 fails on windows: missing mkstemps

[avih]

After commit d39c49db  Remove empty conditional _WIN32 code
and some hacking of the code (it's an unhealthy mix of basically running a 
shell script from a program compiled using tcc for windows), I get the 
following 2 diffs:
+inst_extern_inline_postdeclared
+inst_extern_inline_predeclared

and
-inst_extern_inline_postdeclared
-inst_extern_inline_predeclared

I'm running it in a cygwin environment and the tools (nm, sort, gawk) are 
cygwin tools, while the tested tcc is normal mingw tcc for windows (which I 
build in a reproducible way using my script).

Regardless of these two diffs, I think the test should be composed of a program 
and a normal shell script (which uses mktemp, awk, sort etc), so that the paths 
are consistent between the tools.
Also, the TCC path is hardcoded at the test, but in fact it's parametric at the 
makefile as $(TCC), so it's better to use that instead (but then there are 
forward/backward slash issues which need to be handled too, because system(...) 
in win32 expects backward slashes, but $(TCC) at the makefile has forward 
slashes). Making this a program + a script should implicitly solve this issue 
as well.

After all, a working shell+tools is assumed for this test anyway, but the 
current way of using system(...) from a win32 program (compiled using tcc for 
windows) invokes a windows shell which can be inconsistent with the actual 
shell where `make` runs.
Avi


 

On Tuesday, June 18, 2019 12:11 AM, avih  wrote:
 

 Hmm.. I now see that test 104 uses signal and nm, so it might require some 
effort to make it work on windows.
Nevertheless, considering the recent breakage specifically on windows from 
related code, I think it would be beneficial if this test could be made to work 
on windows,
 

On Monday, June 17, 2019 11:54 PM, avih  wrote:
 

 Wouldn't it be better to just create a known/fixed file instead? (assuming the 
test doesn't need explicitly mkstemps, I didn't look at its actual code).
 

On Monday, June 17, 2019 11:50 PM, Christian Jullien  
wrote:
 

 #yiv8333276739 -- filtered {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 
4;}#yiv8333276739 filtered {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 
4;}#yiv8333276739 filtered {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 
4;}#yiv8333276739 filtered {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 
4;}#yiv8333276739 p.yiv8333276739MsoNormal, #yiv8333276739 
li.yiv8333276739MsoNormal, #yiv8333276739 div.yiv8333276739MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:New;}#yiv8333276739
 a:link, #yiv8333276739 span.yiv8333276739MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv8333276739 a:visited, #yiv8333276739 
span.yiv8333276739MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv8333276739 
span.yiv8333276739EmailStyle17 {color:#1F497D;}#yiv8333276739 
.yiv8333276739MsoChpDefault {font-size:10.0pt;}#yiv8333276739 filtered 
{margin:1.0in 1.0in 1.0in 1.0in;}#yiv8333276739 div.yiv8333276739WordSection1 
{}#yiv8333276739 Yes it has been previously reported.  Michael, as said in a 
private mail, I agree with you that this test should be skipped on Windows.  C. 
 From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] 
On Behalf Of avih
Sent: Monday, June 17, 2019 22:46
To: Tinycc-devel Mailing List
Subject: [Tinycc-devel] test 104 fails on windows: missing mkstemps  Test 104 
log on windows (both tcc32 and tcc 64):  Test: 104_inline_test...
--- 104_inline_test.expect  2019-06-17 23:42:00.162697100 +0300
+++ 104_inline_test.output  2019-06-17 23:42:35.531550400 +0300
@@ -1,25 +1,2 @@
-extern_extern_postdeclared
-extern_extern_postdeclared2
-extern_extern_predeclared
-extern_extern_predeclared2
-extern_extern_prepostdeclared
-extern_extern_prepostdeclared2
-extern_extern_undeclared
-extern_extern_undeclared2
-extern_postdeclared
-extern_postdeclared2
-extern_predeclared
-extern_predeclared2
-extern_prepostdeclared
-extern_undeclared
-extern_undeclared2
-inst2_extern_inline_postdeclared
-inst2_extern_inline_predeclared
-inst3_extern_inline_predeclared
-inst_extern_inline_postdeclared
-inst_extern_inline_predeclared
-main
-noinst_extern_inline_func
-noinst_extern_inline_postdeclared
-noinst_extern_inline_postdeclared2
-noinst_extern_inline_undeclared
+104_inline_test.c:30: warning: implicit declaration of function 'mkstemps'
+tcc: error: undefined symbol 'mkstemps'
make[1]: *** [Makefile:70: 104_inline_test.test] Error 1
Test: 105_local_extern...
make[1]: Target 'all' not remade because of errors.  

   

   

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

Re: [Tinycc-devel] test 104 fails on windows: missing mkstemps

[avih]

Wouldn't it be better to just create a known/fixed file instead? (assuming the 
test doesn't need explicitly mkstemps, I didn't look at its actual code).
 

On Monday, June 17, 2019 11:50 PM, Christian Jullien  
wrote:
 

 #yiv8167816049 #yiv8167816049 -- _filtered #yiv8167816049 
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv8167816049 
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv8167816049 
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv8167816049 
{font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv8167816049 
#yiv8167816049 p.yiv8167816049MsoNormal, #yiv8167816049 
li.yiv8167816049MsoNormal, #yiv8167816049 div.yiv8167816049MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:New;}#yiv8167816049
 a:link, #yiv8167816049 span.yiv8167816049MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv8167816049 a:visited, #yiv8167816049 
span.yiv8167816049MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv8167816049 
span.yiv8167816049EmailStyle17 {color:#1F497D;}#yiv8167816049 
.yiv8167816049MsoChpDefault {font-size:10.0pt;} _filtered #yiv8167816049 
{margin:1.0in 1.0in 1.0in 1.0in;}#yiv8167816049 div.yiv8167816049WordSection1 
{}#yiv8167816049 Yes it has been previously reported.  Michael, as said in a 
private mail, I agree with you that this test should be skipped on Windows.  C. 
 From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] 
On Behalf Of avih
Sent: Monday, June 17, 2019 22:46
To: Tinycc-devel Mailing List
Subject: [Tinycc-devel] test 104 fails on windows: missing mkstemps  Test 104 
log on windows (both tcc32 and tcc 64):  Test: 104_inline_test...
--- 104_inline_test.expect  2019-06-17 23:42:00.162697100 +0300
+++ 104_inline_test.output  2019-06-17 23:42:35.531550400 +0300
@@ -1,25 +1,2 @@
-extern_extern_postdeclared
-extern_extern_postdeclared2
-extern_extern_predeclared
-extern_extern_predeclared2
-extern_extern_prepostdeclared
-extern_extern_prepostdeclared2
-extern_extern_undeclared
-extern_extern_undeclared2
-extern_postdeclared
-extern_postdeclared2
-extern_predeclared
-extern_predeclared2
-extern_prepostdeclared
-extern_undeclared
-extern_undeclared2
-inst2_extern_inline_postdeclared
-inst2_extern_inline_predeclared
-inst3_extern_inline_predeclared
-inst_extern_inline_postdeclared
-inst_extern_inline_predeclared
-main
-noinst_extern_inline_func
-noinst_extern_inline_postdeclared
-noinst_extern_inline_postdeclared2
-noinst_extern_inline_undeclared
+104_inline_test.c:30: warning: implicit declaration of function 'mkstemps'
+tcc: error: undefined symbol 'mkstemps'
make[1]: *** [Makefile:70: 104_inline_test.test] Error 1
Test: 105_local_extern...
make[1]: Target 'all' not remade because of errors.  

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

Re: [Tinycc-devel] tcc coding style question

[avih]

While `git blame -w` does skip white spaces changes, not all tools/editors use 
it. In general, I think it's better to not do style-only changes except in 
lines/functions which are touched for "proper" reasons.
- avih
 

On Thursday, January 24, 2019 7:20 PM, Christian Jullien  
wrote:
 

 I understand it's a go?

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Michael Matz
Sent: jeudi 24 janvier 2019 18:10
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] tcc coding style question

Hi,

On Thu, 24 Jan 2019, Vincent Lefevre wrote:

> On 2019-01-24 16:10:03 +, Michael Matz wrote:
> > On Thu, 24 Jan 2019, Christian Jullien wrote:
> > 
> > > Question (to maintainers): do you allow me to fix them all?
> > 
> > Please don't.  It makes git blame unnecessarily hard.
> 
> Doesn't the -w option of "git blame" solve this issue.

Oh, it does, I didn't know about that option.

In that case bulk changes are fine with me.


Ciao,
Michael.

___
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


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

Re: [Tinycc-devel] __builtin_va_* builtins missing

[avih]

Do you have a specific issue to build tcc on musl or use va_* with tcc built 
with musl?
For me, on current Alpine linux (with gcc 8.2) `git clone 
git://git.or.cz/tinycc && cd tinycc && ./configure --config-musl && make` 
builds fine, all the tests pass (`make test`), and I've used this tcc (in the 
past) to build complex programs which use va_* (mpv).
Is there something you're trying to do which you can't? if yes, can you please 
give exact steps to reproduce? (including the error messages, if any, which you 
get)
 

On Wednesday, October 31, 2018 10:53 PM, Jan Nieuwenhuizen 
 wrote:
 

 Daniel Wingerd writes:

> I'm working on getting musl to build using TCC and the first problem I
> encountered was that TCC is missing __builtin_va_* builtins.

I suspect this is on x86_64?  FWIW, I have finally managed to
bootstrap*) TCC on i686-linux using the Mes C Library and a pretty
simplistic stdarg+).

Greetings,
janneke

*) http://joyofsource.com/reduced-binary-seed-bootstrap.html
+) http://git.savannah.gnu.org/cgit/mes.git/tree/include/stdarg.h

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

___
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] "error: undefined symbol main" with -pthread on linux

[avih]

Confirmed fixed. Thanks.

So quick, it must be Christmas! I wish I had more bugs to report ;)  

On Saturday, December 23, 2017 3:52 PM, Michael Matz <matz@frakked.de> 
wrote:
 

 Hi,

On Sat, 23 Dec 2017, avih wrote:

> I think maybe, instead of saying and doing:
> -pthread   same as -D_REENTRANT and -lpthread
> 
> It should say and do something along these lines:
> -pthread   same as -D_REENTRANT while compiling and -lpthread while linking

I decided to keep the help message as is (staying in <= 80 columns), but 
...

> However, It seems to still not behave the same as gcc. Using the same 
> test.c file as before:
> 
> tcc -pthread -c test.c # -> tcc: error: cannot specify libraries with -c
> 
> It's not unreasonable I think that tcc complains, but gcc is fine with it.

... I've fixed this behaviour.  I agree that -pthread shouldn't add the 
library with -c (or, well, at least not complain then :) ).


Ciao,
Michael.

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

Re: [Tinycc-devel] a patch

[avih]

I don't think so, or else you'll disable -run on any non-win32 platform.
As far as I can tell, the goal of this condition is to test that it's not
a win32 cross compiler, i.e. either native win32 binary which targets win32, or
not win32 binary and not targeting win32. 

On Tuesday, December 19, 2017 2:18 AM, Michael B. Smith 
 wrote:
 

  tcc.h line 
153 should be:    #ifdefined_WIN32&_TARGET_PE    Sorry. I don’t have 
git set up yet. Working on it. ___
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] forward asm symbols vs static

[avih]

I can confirm that with this version of the file the asm test (and all other 
tests) pass both with tcc32 and tcc64, regardless if it was built with gcc or 
tcc, and regardless of build/test procedure. 

On Thursday, November 23, 2017 10:17 PM, grischka <gris...@gmx.de> wrote:
 

 avih wrote:
> - tcc 64 fails the asm tests (again, all versions regardless of how it was 
> built).

Different calling convention on win64.  I'd suggest the attached
version which is more platform neutral.

-- gr

>    On Thursday, November 23, 2017 8:17 PM, grischka <gris...@gmx.de> wrote:
>  
> 
>  I've seen a segfault under some other circumstances on linux 64.
> 
> Using "lea str(%rip),%rdi" instead of "mov $str,%rdi" in asm-c-connect-1.c
> did fix it.  (I can't tell right now whether that is expected behavior or
> points to a bug though.)
> 
> Also I noticed that apparently 'U' is a string prefix in newer gcc versions.
> (Don't know, maybe for unicode?).
> 
> Btw, what about the "vide" hack on tccasm.c:1020 from commit 6afe668ec
> Can we delete it?
> 
> Ciao,
> 
> --- grischka
> 



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

Re: [Tinycc-devel] forward asm symbols vs static

[avih]

> but I'm currently having some issues which I want to explore further before I 
> post further info.
My initial inaccurate description was because my build script was skipping some 
tests for tcc 64, and it all passed, and the success I saw at the log was for 
tcc32. It didn't actually run the asm test for tcc 64.
For completeness, I installed also mingw gcc 32 and tested all combinations 
again.

TL;DR:
- tcc 32 pass the asm test (all versions, built with gcc 32 or with tcc 32, 
with the normal build procedure or with my reproducible script).
- tcc 64 fails the asm tests (again, all versions regardless of how it was 
built).
My build script, once fixed to not skip some 64 tests, also fails the asm test 
with tcc 64.



On Thursday, November 23, 2017 8:17 PM, grischka <gris...@gmx.de> wrote:
 

 I've seen a segfault under some other circumstances on linux 64.

Using "lea str(%rip),%rdi" instead of "mov $str,%rdi" in asm-c-connect-1.c
did fix it.  (I can't tell right now whether that is expected behavior or
points to a bug though.)

Also I noticed that apparently 'U' is a string prefix in newer gcc versions.
(Don't know, maybe for unicode?).

Btw, what about the "vide" hack on tccasm.c:1020 from commit 6afe668ec
Can we delete it?

Ciao,

--- grischka

avih wrote:
>> The test is always compiled by tcc.
> Of course.
> 
>> So if you say "initial compiler", do you mean the compiler by which tcc 
>> itself is compiled?
> Yes
>> I.e. there is a difference if tcc is compiled by gcc (tcc produces 
>> segfaulting> code then), vs. with tcc (the resulting tcc produces good code)?
> That's what I said indeed, but apparently there's more to it.
> First, attached are the .o files from the two c files, each compiled with 
> three different versions of tcc, two of those were compiled themselves using 
> tcc (tcc32-tcc32 and tcc64-tcc64), and one version of tcc compiled using gcc 
> (gcc64-tcc64).
> There's no difference at the .o files between the tcc64-tcc64 versions to the 
> gcc64-tcc64 versions. I don't have gcc32 installed to create gcc32-tcc32 .o 
> file and compare to the tcc32-tcc32 .o version, but I've attached the 
> tcc32-tcc32 version anyway.
> So it must be at the build/test procedure.
> If I use the standard (out of tree) build with ../configure && make && make 
> test then indeed it fails the same way (segfault) regardless if I'm building 
> tcc with gcc or with tcc (i.e. ../configure --cc=/abs/path/to/tcc.exe ...).
> But when I reported my results earlier I used a different build+test  
> procedure for tcc-tcc which succeeded - at least apparently, with the output 
> I reported at the previous mail.
> The one which succeeded was using my reproducible build script which runs the 
> tests makefile with custom arguments, but I'm currently having some issues 
> which I want to explore further before I post further info.
> If anyone else could try building tcc using mingw gcc (32 and/or 64) using 
> the normal procedure and running the tests, it could help.
> 
> 
>  
> 
>    On Thursday, November 23, 2017 3:58 PM, Michael Matz <matz@frakked.de> 
>wrote:
>  
> 
>  Hi,
> 
> On Thu, 23 Nov 2017, avih wrote:
> 
>>> I hope it also works on win32 and win64, which I haven't tested
>> asm-c-connect-test pass if the initial compiler is tcc 32 or 64 (and 
>> building tcc 32/64 respectively).
>> It segfaults if the initial compiler is gcc 64 (mingw gcc 7.2.0, in msys2 
>> setup).
>> I didn't test with gcc 32 mingw.
> 
> The test is always compiled by tcc.  So if you say "initial compiler", do 
> you mean the compiler by which tcc itself is compiled?  I.e. there is a 
> difference if tcc is compiled by gcc (tcc produces segfaulting code then), 
> vs. with tcc (the resulting tcc produces good code)?
> 
> Hmpf.
> 
> Can you compile the two files separately into .o files and attach them 
> here?  (With the failing compiler I mean).  Perhaps it's something 
> obvious, but I can't test win32/64.
> 
> 
> Ciao,
> Michael.
> 
>> When it passes, this is what it prints: asm-c-connect-test 
>> 
>> ./asm-c-connect
>> x1
>> x2
>> x3
>> And when it fails:../tcc.exe -B../../win32 -I../../include -I../.. -I.. -L.. 
>> -o asm-c-connect.exe ../../tests/asm-c-connect-1.c 
>> ../../tests/asm-c-connect-2.c
>>  asm-c-connect-test 
>> ./asm-c-connect.exe
>> make[1]: *** [Makefile:240: asm-c-connect-test] Segmentation fault
>> make[1]: Leaving directory '/bld/tests'
>> make: *** [Makefile:346: test] Error 2
>>  
>>
>>    On Wednesday, November 22, 2017 7:11 PM, Michael Matz 
>>

Re: [Tinycc-devel] plans to 0.9.27

[avih]

Indeed fantastic.
Just tested on Alpine linux, and tcc now builds tmux, htop, st (x terminal), 
freetype2 (but ft2 doesn't link), an order of magnitude faster than gcc. And 
gcc on Alpine is already faster than elsewhere, maybe because of s/glibc/musl/.
The resulting binaries seem to work fine, though I only tried them very briefly.
Thank you. 

On Wednesday, October 11, 2017 8:20 PM, Steffen Nurpmeso 
 wrote:
 

 grischka  wrote:
 |grischka wrote:
 ...
 |Moreover, there is
 |* a patch to tccelf.c to avoid DT_TEXTREL unless really required
 |* a nifty one in tccasm.c to avoid the 'p3' forward label from
 |  alloca86_64.S being put into dynsym with a relocation (huh?)
 |* and the (sig)set variable in tcctest.c was made static to
 |  avoid some issue with inline asm that I didn't try to fix
 |* no diff -I option anymore to make tests work with busybox
 |* a patch to tccrun.c for better selinux support.
 |
 |With these changes, tcc now seems to build and pass all tests
 |cleanly on Alpine musl x86_64 standard-grsec and vanilla too,
 |configured with
 |    ./configure --config-musl --with-selinux
 |optionally also with
 |    --disable-static and/or --cc=tcc (once it was installed)

Now really: boah!  That is great!  I had it in the queue to see if
i would get my head around what Michael Matz sent, but that is
gigantic, thank you!  I will have a look and happily try that
soon.
Ciao!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter          he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

___
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] Push reproducible builds script? (for windows)

[avih]

 

> On Wednesday, September 27, 2017 9:30 AM, grischka <gris...@gmx.de> wrote:
 

 > May I suggest something:  Why don't you guys combine your knowledge>  and 
 > personal preferences and apply it to our standard Makefile instead> of 
 > adding each your own scripts?
I don't disagree that it would be nice to have one place which maintains the 
work of "create the win32 distributions (32/64)", and preferably it can run on 
any system/OS, and be reproducible.

I was attempting to improve the standard makefile some time ago with roughly 
that in mind, and specifically the cross builds. You can see my list of commits 
(haven't pushed new ones for over a year) here: 
https://github.com/avih/tinycc/commits/drafts

However, as hard as I tried, I could not keep my patches up to date with your 
(grishka) ever changing-everything commits once in a while, especially those at 
Makefile and configure.
And since I didn't consider my patches production ready to push, and I couldn't 
maintain and rebase them, I dropped this work, and concentrated my efforts on 
my reproducible build script.

I suspect (though for sure cannot know) that win32/Makefile is not integrated 
to the main Makefile for similar reasons. After all, why would one need 
win32/Makefile if the main one would "just work" for this need?

I did manage to push to mob or promote some changes, such as supporting out of 
tree builds, for which I'm grateful.

> As I see it, both, Christian's win32/Makefile (labeled "for cygwin")
> as well as Avi's suggested reproducible builds script really are very
> similar:
Indeed they are. They use the same approach and with the same goal. The main 
differences I could identify off hand would be:
- win32/Makefile requires [g]make. my script needs only a shell and a compiler.
- win32/Makefile runs only on cygwin (and confirmed msys2 too), but not on *nix 
systems (tested ubuntu), mine runs everywhere I tested - which is a lot.- My 
script calculates and prints a signature to confirm reproducibility.- My script 
makes an explicit effort to not require features which are not available 
everywhere, such as realpath, symlinks, and few more, and instead implements 
good enough variants as posix shell functions.
- My script only puts new files at the output dir and doesn't leave traces at 
the main dir[s]. It also creates a temp work dir inside the output dir and 
deletes it once done. As you can tell, I'm a big fan of out-of-tree builds...
My goal was to allow building the same binary everywhere (even osx or bsd) and 
with the same tool (a single script), with the minimal supported setup being 
busybox on windows and tcc itself as a bootstrap CC .
Therefore I find most of the diffs meaningful.
If you agree with this goal, then I cannot see this happen with the main 
configure and Makefile. I did also try to use a win32 make.exe within busybox 
and do the normal procedure. I made some progress, but there are a lot of 
roadblocks and a lot of missing features, and eventually I dropped it and took 
the script approach.
I also think it won't be fair to limit the tools which the main configure && 
make use just to allow building with a minimal setup.



> What do you guys think?
I'm willing to help with such effort, but It will only be usable with a full 
blown development environment, which not everyone has.
I think the reproducible shell script would still have value on such case, for 
the little people :), and for its simplicity and relatively bullet proof 
implementation (famous last words ;) ).


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

Re: [Tinycc-devel] Add support of musl-libc to tinycc

[avih]

 On Saturday, May 13, 2017 10:01 AM, grischka  wrote:

>> 3. It seems that (with musl) tcc needs stdarg.h included before stdio.h, or 
>> else

> You could create a stdio.h in /include ...

While I could do that (and thanks, wasn't aware of #include_next), va_list et-al
are required by more than one std include file. The headers which need it could
also change over time. My hope was to find a reasonably inter-operable way to
communicate it between the libc and tcc.

Rich Felker noted that musl expects __builtin_va* intrinsic or predefined
macros, which to me doesn't sound unreasonable. While the subject seems to have
drawn some responses with workarounds (your reply included), I haven't yet seen
a response which states that it's a bad idea for tcc to follow.

Is it a bad idea for tcc to follow?


>> 4. Initializers of NAN fail with "division by 0 in a constant", but I was 
>> _not_

> tcc knows __nan__

Yup, I was aware of it and I forgot to mention that it works. However, as I
noted in my followup email about the NAN subject, the main question here, IMHO,
is whether or not 0.0f/0.0f should be allowed in static-storage initializer.

If it's allowed, then it's probably best to fix it in tcc. But if not, then musl
does something which breaks tcc, and it needs to be communicated somehow between
tcc and musl. Or work around it in tcc, for instance by replacing NAN with
__nan__ before musl's headers get a chance to do a bad substitution.


> > 5. tcc dislikes some #defines ...

> According to the standard "#define ... defined" is undefined.
> Undefined identifiers however evaluate to 0: ...

Right. So this one is mpv's fault. Good solution :)


>> All that being said, after replacing the NANs with 0, moving include stdarg 
>> to
>> the top, and modifying the #define, mpv builds with tcc cleanly and runs fine
>> on alpine (with video, opengl, audio, etc).

> Doesn't sound too bad ;)
> --- grischka

And I even forgot to mention the best part: tcc did it more than 20x faster!

More build info:
- I used unofficial configure + Makefile because the official build system (waf)
doesn't know tcc and I couldn't fix it easily.
- Using 15W mobile Haswell CPU.
- configure completed in 1.1s with tcc, 3.5s with gcc
- make -j4 for ~150 C files completed in 1(!).0s with tcc, 26s with gcc.

So yeah, not bad at all indeed :)___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Add support for Unicode entries 'wmain' and 'wWinMain' on Windows

[avih]

Thanks. All tests now pass, and so far it seems to behave as expected while 
building with gcc or tcc itself, and when using the resulting tcc.

The tcctools (only tested -ar) also works as expected and probably simplify 
things, though I think some tools might work better with a stand alone 
ar-clone, but so far tcc -ar works for me.
I don't recall an official announcement for tcc 0.9.27, so I'm guessing this 
big change/refactor is still for 0.9.27?
There's still one more issue I wanted to report, which I think should be fixed 
before 0.9.27- about libtcc1.a when building with --enable-cross, but I'll 
create a new email thread for it.
 

On Saturday, February 18, 2017 11:05 AM, grischka <gris...@gmx.de> wrote:
 

 avih wrote:
> This caused tests failures on windows (gcc, normal configure and make, the 
> build succeeds) - missing symbol "main" when running libtcc test, and many 
> later tests too which probably use libtcc in memory.
> Attached are two orthogonal patches, i.e. the test failures happen with or 
> without also building the unicode variants of the crt files, and the tests 
> pass (with the tccpe.c fix) regardless if building with or without the 
> unicode variants.
> I'm not entirely sure the tccpe.c fix is correct, and also not sure whether 
> the wrapper c file is an acceptable solution for re-compiling the same files 
> with different defines and to different .o files. Please either someone 
> pushes a better fix, or tell me how to improve the patches, or just tell me 
> to push it as is.
> Thanks.

I picked up the wrapper suggestion.  See
http://repo.or.cz/tinycc.git/commitdiff/096125d963400951e0f160ced86416ef8c9c98b0

Also, tiny_xxx tools are now integrated:
http://repo.or.cz/tinycc.git/commitdiff/2d3b9559bf569f137cefb7f8386a0dc58e33c81f

Also, new help screen for the advanced options:
    tcc -hh

-- gr

>    On Thursday, February 16, 2017 10:35 PM, grischka <gris...@gmx.de> wrote:
>  
> 
>  YX Hao wrote:
>> Dear grischka and group,
>> Unicode entry support for windows platform is useful. Especially when
>> developing programs which relays on the Unicode version APIs and takes
>> Unicode arguments, it will help.
>>
>> Here is my patch for this feature. I have used it for about 1 year. It has
>> followed the recent commits (7b99c3ac2c9c1761d68be1192f975a39199be28d).
>>
>> '-run' option is useable. And arguments converted.
>>
>> Since I'm not experienced as you guys. Please give me a review.
> 
> Looks good.  Please push.  I will adjust the Makefiles later.
> 
> Thanks,
> 
> --- grischka
> 
>>  
>> Best Regards,
>>
>> YX Hao
>>
> 
> ___
> 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




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

Re: [Tinycc-devel] Add support for Unicode entries 'wmain' and 'wWinMain' on Windows

[avih]

This caused tests failures on windows (gcc, normal configure and make, the 
build succeeds) - missing symbol "main" when running libtcc test, and many 
later tests too which probably use libtcc in memory.
Attached are two orthogonal patches, i.e. the test failures happen with or 
without also building the unicode variants of the crt files, and the tests pass 
(with the tccpe.c fix) regardless if building with or without the unicode 
variants.
I'm not entirely sure the tccpe.c fix is correct, and also not sure whether the 
wrapper c file is an acceptable solution for re-compiling the same files with 
different defines and to different .o files. Please either someone pushes a 
better fix, or tell me how to improve the patches, or just tell me to push it 
as is.
Thanks.
 

On Thursday, February 16, 2017 10:35 PM, grischka <gris...@gmx.de> wrote:
 

 YX Hao wrote:
> Dear grischka and group,
> Unicode entry support for windows platform is useful. Especially when
> developing programs which relays on the Unicode version APIs and takes
> Unicode arguments, it will help.
> 
> Here is my patch for this feature. I have used it for about 1 year. It has
> followed the recent commits (7b99c3ac2c9c1761d68be1192f975a39199be28d).
> 
> '-run' option is useable. And arguments converted.
> 
> Since I'm not experienced as you guys. Please give me a review.

Looks good.  Please push.  I will adjust the Makefiles later.

Thanks,

--- grischka

>  
> Best Regards,
> 
> YX Hao
> 

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


   From f5126397c1c96b3ffe866303c8177c4458df3e0e Mon Sep 17 00:00:00 2001
From: "Avi Halachmi (:avih)" <avih...@yahoo.com>
Date: Sat, 18 Feb 2017 08:04:07 +0200
Subject: [PATCH 1/2] win: fix usage of libtcc in memory

This also fixes test failures for libtcc and other tests which were introduced
at "86e3cd0 Add support for Unicode entries 'wmain' and 'wWinMain' ..."

This fix is orthogonal to building also with the unicode variants of crt1.c
and wincrt1.c (adding those does add tcc support for wmain and wWinMain, but
the build/tests don't use them anyway, and the failures happened with or
without them).
---
 tccpe.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/tccpe.c b/tccpe.c
index 8bb3d85..5c1339d 100644
--- a/tccpe.c
+++ b/tccpe.c
@@ -1760,6 +1760,7 @@ static void pe_add_runtime(TCCState *s1, struct pe_info *pe)
 const char *start_symbol;
 int pe_type = 0;
 int unicode_entry = 0;
+int user_entry = 1;
 
 if (find_elf_sym(symtab_section, PE_STDSYM("WinMain","@16")))
 pe_type = PE_GUI;
@@ -1778,12 +1779,15 @@ static void pe_add_runtime(TCCState *s1, struct pe_info *pe)
 pe_type = PE_EXE;
 if (find_elf_sym(symtab_section, "wmain"))
 unicode_entry = PE_EXE;
+else if (!find_elf_sym(symtab_section, "main"))
+user_entry = 0;  /* hopefully we're using libtcc in memory */
 }
 
 start_symbol =
 TCC_OUTPUT_MEMORY == s1->output_type
 ? PE_GUI == pe_type ? (unicode_entry ? "__runwwinmain" : "__runwinmain")
-: (unicode_entry ? "__runwmain" : "__runmain")
+: user_entry ? (unicode_entry ? "__runwmain" : "__runmain")
+: "_main"  /* not used except to report if "main" is missing */
 : PE_DLL == pe_type ? PE_STDSYM("__dllstart","@12")
 : PE_GUI == pe_type ? (unicode_entry ? "__wwinstart": "__winstart")
 : (unicode_entry ? "__wstart" : "__start")
@@ -1793,12 +1797,12 @@ static void pe_add_runtime(TCCState *s1, struct pe_info *pe)
 ++start_symbol;
 
 /* grab the startup code from libtcc1 */
-/* only (PE_Dll == pe_type) doesn't need it,
-   (TCC_OUTPUT_MEMORY == s1->output_type && PE_Dll == pe_type) is illegal */
-set_elf_sym(symtab_section,
-0, 0,
-ELFW(ST_INFO)(STB_GLOBAL, STT_NOTYPE), 0,
-SHN_UNDEF, start_symbol);
+if (user_entry) {
+set_elf_sym(symtab_section,
+0, 0,
+ELFW(ST_INFO)(STB_GLOBAL, STT_NOTYPE), 0,
+SHN_UNDEF, start_symbol);
+}
 
 tcc_add_pragma_libs(s1);
 
-- 
2.11.0

From 2a0355f51019af84c1bf34c75920e89148149aa9 Mon Sep 17 00:00:00 2001
From: "Avi Halachmi (:avih)" <avih...@yahoo.com>
Date: Sat, 18 Feb 2017 08:13:16 +0200
Subject: [PATCH 2/2] win: makefiles: add upport for wmain and wWinMain

Prior to this commit, wmain and wWinMain were only supported at build-tcc.bat

Since crt1.c and wincrt1.c need to be compiled twice with different
defines and to different .o files, it's easier to

Re: [Tinycc-devel] Can you compile TCC using TCC?

[avih]

Ben, please reply to the mailing list next time. Thanks. 

  Show original message On Wednesday, January 18, 2017 12:08 AM, Ben 
Hutchinson  wrote:
 

 > I want a version of TCC that will run on both 32bit and 64bit Windows. In 
 > order to make tcc.exe run on both 32bit and 64bit Windows, I will need to 
 > compile TCC as a 32bit EXE file rather than a 64bit EXE file. Problem is, 
 > MSYS2 is only available now as a 64bit compiler. I can't compile 32bit EXE 
 > files with it, and that's a show stopper for me.

MSYS2 is available as both 64 and 32 installs, and both can compile either 32 
or 64 bit applications. The instructions I linked to in my first reply will get 
you a 32 bit application (tcc).


> Also as far as I know, the latest version of TCC (both source and binaries)  
> is 0.26. I would think that if TCC can compile TCC, then each version of TCC 
> should be able to compile whatever its own version is. So TCC 0.26 should be 
> able to compile TCC 0.26. Or is there some later version of TCC now that 
> exists only as source code?
tcc 0.9.26 is few years old and a lot of progress was made since, but no 
official release was made since then - and it's only available as source code. 
There are some talks of 0.9.27 getting released soon (TM). You can find the git 
repository from this page: http://repo.or.cz/w/tinycc.git and the current 
zipped snapshot is 
http://repo.or.cz/tinycc.git/snapshot/5420bb8a67f5f782ac49c90afb7da178a60c448a.zip
 


> Personally I'm just trying to compile version TCC 0.26 with TCC 0.26.
tcc 0.9.26 can probably compile itself with the instructions I linked to 
earlier (after you git checkout the 0.9.26 tag), but you probably want to build 
the latest source instead which has many fixes and improvements over 0.9.26.


> And by the way, there's also a problem with that source code release (at 
> least in the version 0.26 official source code release from the official TCC 
> website, not sure if there are any corrected versions floating around the 
> web). It appears to be missing a particular file. That file is config.h. If 
> you look in the Makefile, you'll see the line that says "CPPFLAGS = -I$(TOP) 
> # for config.h" but if you look at the available h files in the TCC source 
> code folder, there is no file called "config.h". So that right there is going 
> to prevent compiling. I'm tempted to just remove that line from the Makefile, 
> but don't even know what things are supposed to be defined in config.h. They 
> may be very critical to the correct compilation of TCC, and without config.h 
> it may be 100% impossible to compile TCC.
> Some help here would be greatly appreciated.

config.h is created when you run the configure script, and includes 
configuration which is specific to your system (e.g. whether it's a windows tcc 
or linux, and more). Again, the instructions I linked to would result in 
exactly what you want - latest tcc 32 for windows.





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

Re: [Tinycc-devel] Various broken tests

[avih]

The memleak issue ("4.  memtest failure when building using newly built tcc 
(32)" ) seems fixed with latest commit ( 4beb469 Fix pseudo leak ). I was 
testing previously while 2 commits behind.
The three other issues remain. 

On Tuesday, December 20, 2016 4:25 PM, avih <avih...@yahoo.com> wrote:
 

 Note: residues from past builds can affect the results. Make sure you don't 
have untracked files which you need, and use `git clean -xfd` to really clean 
it up.


1. Out-of-tree tests broken. This used to work few weeks ago, but there were 
several commits which broke this scenario in various ways:
git clone  && cd tinycc && mkdir build && cd build && ../configure && 
make && make test
Linux (tested ubuntu 16.04 64) and windows (MINGW 32/64 with gcc 6.2 from 
msys2):- dlltest, memtest fail - both assume we're at $(TOPSRC)/tests so can't 
find relevant source files (needs $(TOPSRC)/ instead of ../).- tests/pp/16 
fails - the (expected, correct) warning message has different source path (not 
sure how to fix).
On linux 64 and windows MINGW 32, after fixing dlltest/memtest paths and 
ignoring pp/16, all other tests pass.

The below 2/3/4 are after applying the dlltest/memtest fixes and ignoring pp/16.



2. libtest failure on Windows - MINGW 64 (gcc 6.2), with the following test 
output:
 libtest 
./libtcc_test.exe -B../../win32 -I../../include -I../.. -I.. -L..
0@@
fib(32) = 2178309
add(32, 64) = 96
gcc -o tcctest.gcc ../../tests/tcctest.c -DTCC_TARGET_X86_64 -DTCC_TARGET_PE 
-fno-strict-aliasing -I.. -I../.. -w -O0 -std=gnu99 -fno-omit-frame-pointer
../../tests/tcctest.c:2680:28: error: initializer element is not constant
 {
    ^
make[1]: *** [Makefile:90: test.ref] Error 1


3. libtest failure on windows - building with tcc32 from some weeks ago - 
possibly expected? : libtest 
./libtcc_test.exe -B../../win32 -I../../include -I../.. -I.. -L..

fib(32) = 2178309
add(32, 64) = 96
/path/to/not-latest/tcc.exe -o tcctest.gcc ../../tests/tcctest.c 
-DTCC_TARGET_I386 -DTCC_TARGET_PE -I.. -I../.. -w -O0 -std=gnu99 
-fno-omit-frame-pointer
../../tests/tcctest.c:70: error: invalid number

make[1]: *** [test.ref] Error 1


4.  memtest failure when building using newly built tcc (32): 
memtest 
/path/to/tcc.exe -I.. -I../.. -DTCC_TARGET_I386 -DTCC_TARGET_PE -DONE_SOURCE 
-DMEM_DEBUG=2 ../../tcc.c  -o memtest-tcc.exe
./memtest-tcc.exe -B../../win32 -I../../include -I../.. -I.. -L.. 
-DTCC_TARGET_I386 -DTCC_TARGET_PE -DONE_SOURCE ../../tcc.c
TAL_DEBUG: memory leak 1 chunk(s) (limit= 1024)
../../tccpp.c:331: chunk of 32 bytes leaked
make[1]: *** [memtest] Error 2



   ___
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

[avih]

Thanks for the detailed reply. I haven't yet read the linked discussion, but I 
will.
I like that it will work better on Linux, but the latter part of my question 
was intended to understand better what would stop working on Windows if you 
take approach #1 but the flag isn't used when invoking tcc.
 

On Tuesday, November 22, 2016 8:38 PM, David Mertens 
<dcmertens.p...@gmail.com> wrote:
 

 Hello,

Folks have been using tcc on linux for years and have not reported this as an 
issue. Juding from the evidence, the situations where this is problematic are 
vanishingly small. That's because it is only an issue when a library presents 
the following sort of struct as part of its public api:

struct {
    void * some;
    double data;
    int a : 2;
    char vowel;
}

On 32-bit systems, the "int" in the a bitfield force the value of a to have an 
alignment of four bytes. But, does the bitfield take four bytes followed by a 
single char, causing the struct to consume eight bytes across its last two 
members? Or, does the bitfield take a single byte, followed by a char with a 
single byte, and two unused bytes? VC++ does the former behavior, gcc without 
-mms-bitfields does the latter.

 Perl uses gcc's close-packing behavior. That is what made me aware of the 
problem. Even so, it is possible to compile perl.h and call functions from the 
Perl API with tcc without running into trouble. If you use functions that only 
need struct info that comes ahead of this bitfield stuff, you're layouts will 
still agree. This means you can directly manipulate s->some, s->data, and s->a, 
even when the alignment of vowel is wrong. Obviously if you pass around 
pointers to your structs, you can call functions as pass the pointers without 
any problems. It's really only an issue in two circumstances: (1) if you are 
allowed/expected to directly manipulate the elements of the struct (or use 
macros that do so, which was the case with the Perl API), or (2) if you are 
supposed to call a function on a struct directly, rather than passing via a 
pointer, in which case the stack will not be properly set up.

Here is a discussion of enabling -mms-bitfields by default for another project. 
You might find it informative: 
https://groups.google.com/forum/#!topic/cocotron-dev/jwhEynyoZms

To reiterate, there is currently no way to get this to work correctly on Linux. 
I'm proposing something that'll make it possible for everyone to achieve the 
correct behavior, albeit possibly with an additional command-line flag if 
you're on Windows.

David

On Tue, Nov 22, 2016 at 9:40 AM, avih <avih...@yahoo.com> wrote:

Sounds fine to me to have better interoperability with existing/common tools on 
Linux.

> If a library was compiled on Linux with gcc, there is no way to compile 
> consuming code using tcc that is binary-compatible.
Could you please elaborate on the scope of the affected use cases? does it 
apply to both .a and .so libs? I think the windows side has a potential to 
suffer more, if I understand it correctly.

Assuming we take suggestion 1 (so on windows we'd need to invoke tcc with 
special cli flag to set a non default alignment) but we _don't_ use that flag, 
what would work which didn't before? interoperability with gcc? what wouldn't 
work? linking with libs created by native windows tools (MSVC)? What about 
using windows DLLs (which happens almost always as AFAIK binaries built with 
tcc use the ms crt for many things, and tcc comes with interfaces definitions 
to major system DLLs)?
etc.
Thanks.
 

On Tuesday, November 22, 2016 5:16 AM, David Mertens 
<dcmertens.p...@gmail.com> wrote:
 

 Hello all,

I have finally found a bit of time to work on this. Just to re-iterate, I've 
found variation in alignment with bitfields across different flavors of 
compilers, and tcc is incompatible with gcc on Linux. If a library was compiled 
on Linux with gcc, there is no way to compile consuming code using tcc that is 
binary-compatible. I've listed the test program and the known results below.

I believe the sensible thing to do is to make tcc more gcc-ish. This would 
involve (1) making tcc's default behavior align with gcc's default behavior, 
which appears to be consistent across platforms, and (2) providing the 
-mms-bitfields command-line option for Windows folks who need it. This makes 
binary compatibility possible across both Linux and Windows, and asks no more 
of Windows folks than what gcc asks.

Alternatively, we could make tcc's default behavior configurable. This would 
require an additional configure flag. It would also require both -mms-bitfields 
and -no-mms-bitfields (or whatever the proper name for that flag should be). 
And finally, it would probably be best to make the default configuration 
OS-dependent.

I prefer the first option because (a) it is simpler and (b) any configuration 
tools that think they're working with gcc will be smart enough to includ

[Tinycc-devel] Reproducible builds

[avih]

I tried to create a reproducible windows build of tcc. I chose windows because:
- I'm more familiar with Windows as a tcc build target.- tcc targeting windows 
is self contained (has all headers/libs to create executables)
- tcc is distributed as binary for windows, so it would be nice if users could 
reproduce the official build on any OS.
- It might be able to detect problems with tcc.
- I wanted to make it easy to build tcc for windows without installing big 
environments.

What I came up with is a simple procedure which is compiler and 
operating-system agnostic*:
- Use a native compiler to create a native tcc executable which targets windows.
- Use this new tcc to build tcc for windows (this is how the normal makefile 
builds the libs for the windows cross compilers).
- It then outputs a single combined signature of all the output files such that 
it can be compared easily between environments.
- For simplicity, I used ONE_SOURCE (which still supports -run, but no libtcc).

I ended up with a script which builds 4 windows tcc compilers: native 32 and 
64, and cross 32->64 and 64->32.
Its only input is a working native compiler, and it requires a posix-y shell, 
and works in busybox, dash, bash, etc.
To use it, place the attached file at the win32 dir of tcc, and then:
CC=gcc ./build-tcc-reproducible.sh

For the currently latest mob commit (3054a76   i386-gen: use EBX as 4th 
register) the build signature is 52155cb6a03fcfd2632dc649984875e1

This script completes on all the environments which I tried and produces 
identical binaries (and signature) regardless of the system and the initial 
compiler.

Tested environments/compilers which produce identical outputs:
- Ubuntu 16.04 32/64 (gcc 5.4 and clang-3.8, glibc)
- FreeBSD* (GhostBSD) 32/64 (gcc 4.4, glibc?)
- OSX* el capitan (Apple LLVM 8)
- Alpine** linux 64 (gcc 6.2, musl-libc)
- Windows: Msys2 32/64 (gcc 6.2), MSVC 2013 32/64
- And of course each of the 4 output tcc compilers which this script generates 
can generate identical 4 output compilers.

On windows, it's enough to use a binary distribution of tcc (zipped, but not 
0.9.26) and busybox to generate identical outputs.

I didn't run the resulting tcc's through the existing tests, but I did use them 
as inputs to the script itself (generates identical outputs) and as input for 
the normal tcc configure, make, make test - where the generated tcc's do pass 
all tests.

I'm not sure how much value this has in general, but at the very least it's 
interesting IMO.
I _think_ it would be possible to generate identical compilers which target 
other systems too, even if they won't be as functional as the windows outputs, 
just to see how tcc "reacts" on different systems where it's supposed to 
generate eventual identical outputs, but I'm not familiar enough with the 
subject to really assess how feasible or useful it would be.

---

* On Alpine/OSX/BSD I wasn't able to build native tcc with configure+make, but 
the script still works and generates cross and then identical win-native tcc's.

** On GhostBSD 32/64 there's a tcc bug where the object files (for libtcc1.a) 
use BSD bits at elf header even if the target if not BSD. I worked around it 
but didn't push to mob since I don't think it's the best fix. The offending 
line is at (the current) tccelf.c:2577 :

#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
    ehdr.e_ident[EI_OSABI] = ELFOSABI_FREEBSD;
#endif

And my workaround was to check if the target is not windows, which was good 
enough to generate identical signature as the other envs. There are actually a 
lot of similar target-unconditional BSD code, but changing this one alone was 
enough to generate identical output.



build-tcc-reproducible.sh
Description: Binary data
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Windows test suite, why 24_math_library is removed?

[avih]

round and several other floating point functions from math.h were not working 
on windows for some years, and around November 2015 I fixed most of those 
issues. However, I wasn't aware that some tests were disabled on windows due to 
the missing functions. Good catch (I'd leave it to you to re-enable them).
 

On Sunday, October 9, 2016 5:20 PM, Christian Jullien  
wrote:
 

 Hi 
again,  I see from test/test2/Makefile that 24_math_library is removed for 
Windows because of lack of round().  ifdef CONFIG_WIN32 SKIP += 
24_math_library.test # don't have round()  With mob compiled with a recent 
MinGW gcc compiler.This test is fully working. Can you reconsider to add it as 
part of standard tests suite.  I also note that 28_strings is removed because 
Windows lacks index/rindex (which is true).Now, if you remove  which 
was a BSDish include now removed from POSIX and replace   printf("%s\n", 
index(a, 'o'));   printf("%s\n", rindex(a, 'l'));   printf("%d\n", rindex(a, 
'x') == NULL);  By iso C equivalent functions:     printf("%s\n", strchr(a, 
'o'));   printf("%s\n", strrchr(a, 'l'));   printf("%d\n", strrchr(a, 'x') == 
NULL);  It works on Windows and should work on any system.
___
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] tcc compilation on MSYS2

[avih]

@seyko
While I appreciate the confidence in me when you take code/patches which I 
wrote and commit them to mob yourself (and also the credit which you gave in 
your commits from today - in the past you did so without giving credit IIRC), 
I'd also appreciate some heads up and possibly some discussion.
For instance, your commit bab4519 which is based on an issue which I detected 
and fixed (not perfectly, but still) at my drafts branch to allow the tests to 
run at a custom build dir, you changed the code to use 'realpath', but realpath 
is not available on all systems.
You can use this code instead, which I wrote and I think would be enough for 
this case, here:  
https://github.com/avih/tinycc/blob/drafts/win32/build-tcc-reproducible.sh#L11 

Also, if you take someone else's commit and push it yourself, you can keep the 
author the same (assuming you didn't make meaningful changes) using git 
format-patch and git am (or cherry-pick etc), such that the original author 
doesn't appear only at the commit message, but actually stays the author of the 
commit.



On Saturday, May 14, 2016 5:33 PM, avih <avih...@yahoo.com> wrote:
 

 You can try my branch: https://github.com/avih/tinycc/commits/drafts (note, I 
force-push and keep it rebased on top of mob).
It includes several build consolidation for windows such that it needs less 
windows-specific checks etc, but also adds some other improvements (like getopt 
working out of the box, and few more, including make it self-hosting using the 
latest official tcc-for-windows-release - 0.26). It shouldn't hard to identify 
the commits which only touch the build system.

I haven't touched tcc for some months, and at the time I was able to use my 
drafts branch to build tcc and cross out of tree with all tests passing and the 
output executables working as expected, either on windows or linux, either in 
msys2-32/64 env using the native (gcc) compiler or msys1 env (using tcc0.26-32 
for windows as the compiler and tiny_libmaker.exe as AR).
I've updated it today (pushed to the drafts branch already) and added one 
commit which reverts a win32 specific stuff at the tests/Makefile (my earlier 
consolidations made it unneeded), and it now _seems_ to work again as expected 
(was able to build using msys2 (gcc) or msys[1] (tcc.exe) and all the tests 
pass). But I didn't test it extensively.

If you wish to test the version which got some more testing by me, you can try 
the branch "snapshot-drafts-2015-12-17"

Hope it helps.
PS.I wanted to push some/all of the commits on my "drafts" branch to mob after 
some cleanups, but never really got to end up doing it. If there's enough 
interest and my current drafts branc ends up usable for many, I'll reconsider 
putting the effort.


On Saturday, May 14, 2016 4:57 PM, Chris Marshall <devel.chm...@gmail.com> 
wrote:
 

 As someone whose primary development environment is cygwin/win7, I would 
love for tcc to build and run under cygwin.


--Chris


On 5/14/2016 03:24, Sergey Korshunoff wrote:
> MSYS2 is current environment for Qt and other software development on
> Windows. It is a mingw+cygwin with a package manager (pacman), ported
> from ARCH Linux. MSYS2 allow to build
> mingw32/mingw64/cygwin32/cygwin64 programs in unix-like environment.
> Currenly tcc can not be build on this environment (mix of unix and
> windows). I think a system name (uname output) is needed to
> select/reject some code in sources of the tcc.
>
> ___
> 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


   

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

Re: [Tinycc-devel] tcc compilation on MSYS2

[avih]

Maybe it would be better to have tcc define (or not) TCC_BCHECK, and then this 
file, and possibly elsewhere too, check only this instead of all these tests? 

On Wednesday, May 18, 2016 7:31 AM, Sergey Korshunoff  
wrote:
 

 > However, since the
> preprocessing is being done by tcc the __CYGWIN__ macro is not defined
> and I can't figure out where that would go.
iff --git a/libtcc.c b/libtcc.c
index 7d9a058..a5ec7f3 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1170,6 +1170,8 @@ LIBTCCAPI TCCState *tcc_new(void)
 # ifdef TCC_TARGET_X86_64
    tcc_define_symbol(s, "_WIN64", NULL);
 # endif
+#elif defined(__CYGWIN__)
+    tcc_define_symbol(s, "__CYGWIN__", NULL);
 #else
    tcc_define_symbol(s, "__unix__", NULL);
    tcc_define_symbol(s, "__unix", NULL);

___
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

[Tinycc-devel] RFC [PATCH] win: libm: fix "unknown constraint 't'", missing fpclassify/round/etc

[avih]

I've noticed that for many years now there have been a recurring Windowsrelated 
complaint about "Error: unknown constraint 't'" message, which goes asearly as 
2007, e.g. 
https://lists.nongnu.org/archive/html/tinycc-devel/2007-07/msg00013.html

There appears to be a patch for it (didn't test it), but it seems it was never 
taken:http://lists.gnu.org/archive/html/tinycc-devel/2014-08/msg00024.html
I decided to approach it from a different direction, and while at it also add 3 
missing libmfunctions. Following these changes, at least 2 medium sized 
projects which tcc couldn'tbuilt on windows (using the windows official 
distribution package), now build and appearto be working well (mujs and 
Duktape).
If there are no objections, I'll push that to the mob branch soon. The patch is 
attached,and that's the commit 
message:--
win: libm: fix "unknown constraint 't'", missing  fpclassify/round/etc

Some libm functions were broken at win32/include/math.h in few ways:

1. Unknown constraint 't': a similar piece of code was used in several inline
   functions at math.h (from mingw), and currently the tcc asm doesn't support
   it. This broke __fpclassifyl, __isnan* and __signbit*, and indirectly broke
   the macros fpclassify, isfinite, isinf, isnan, isnormal and signbit.

2. Even if 't' was supported by tcc's asm, there were no definitions for
   __fpclassify and __fpclassifyf, therefore breaking the macro fpclassify.
   Newer mingw(w64) math.h doesn't have this issue, but still uses 't' in asm.

3. Other than the above, some common libm functions werere not implemented
   anywhere in the tcc Windows distribution package - mainly fmin/fmax/round.
   Newer mingw(64) math.h stil doesn't include these implementations.

To address these issues, code which used inline asm with 't' was replaced with
a C implementation, and the missing __fpclassify functions were added.

The code is mostly taken from MUSL rs-1.0 (MIT) [*], and is placed as inline
functions at win32/include/tcc/tcc_libm.h, which is now included from math.h,
and is also copied to the win32 install target.

Future enhancements:
- Support 't' contraint in asm. Newer mingw headers still use it, and it would
  make future porting of mingw headers easier.
- Enumerate the still-missing libm functions (if there are such) and add missing
  implementations. Most should be simple and will add good value to tcc.
- Possibly move the code at tcc/tcc_libm.h to a C file and create an actual
  libm.a library, or just create a dummy libm. For build procedures which expect
  libm, this could allow to complete successfully, assuming no yet-unimplemented
  functions are used.
- Add some tests for common libm functions.

[*] - http://git.musl-libc.org/cgit/musl/tree/src/math?h=rs-1.0
    - MUSL's license: http://git.musl-libc.org/cgit/musl/tree/COPYRIGHT?h=rs-1.0
From 67b64295332c11641ccdcd582edbb040a5e528e0 Mon Sep 17 00:00:00 2001
From: "Avi Halachmi (:avih)" <avih...@yahoo.com>
Date: Sun, 1 Nov 2015 18:47:03 +0200
Subject: [PATCH] win: libm: fix "unknown constraint 't'", missing
 fpclassify/round/etc

Some libm functions were broken at win32/include/math.h in few ways:

1. Unknown constraint 't': a similar piece of code was used in several inline
   functions at math.h (from mingw), and currently the tcc asm doesn't support
   it. This broke __fpclassifyl, __isnan* and __signbit*, and indirectly broke
   the macros fpclassify, isfinite, isinf, isnan, isnormal and signbit.

2. Even if 't' was supported by tcc's asm, there were no definitions for
   __fpclassify and __fpclassifyf, therefore breaking the macro fpclassify.
   Newer mingw(w64) math.h doesn't have this issue, but still uses 't' in asm.

3. Other than the above, some common libm functions werere not implemented
   anywhere in the tcc Windows distribution package - mainly fmin/fmax/round.
   Newer mingw(64) math.h stil doesn't include these implementations.

To address these issues, code which used inline asm with 't' was replaced with
a C implementation, the missing __fpclassify functions were added, as well as
fmin/fmax/round and their variants.

The code is mostly taken from MUSL rs-1.0 (MIT) [*], and is placed as inline
functions at win32/include/tcc/tcc_libm.h, which is now included from math.h,
and is also copied to the win32 install target.

Future enhancements:
- Support 't' contraint in asm. Newer mingw headers still use it, and it would
  make future porting of mingw headers easier.
- Enumerate the still-missing libm functions (if there are such) and add missing
  implementations. Most should be simple and will add good value to tcc.
- Possibly move the code at tcc/tcc_libm.h to a C file and create an actual
  libm.a library, or just create a dummy libm. For build procedures which expect
  libm, this could allow to complete successfully, assuming no yet-unimplemented
  functions are used.
- Add som