Re: [Tinycc-devel] Do not load all referenced libraries, when linking a library

[Michael Matz]

Hello,

On Tue, 10 Oct 2023, Herman ten Brugge via Tinycc-devel wrote:


On 10/5/23 22:55, Detlef Riekenberg wrote:

 After the comments from grischka and Michael,
 i prepared a different patch to fix the build break of netbsd-curses
 and also updated the patch to current mob.


 `make test` works
 A testapp with netbsd-curses works,
 but i am away for the next 2 weeks.


 Since we have a release canditate, i decided to not push my patch to mob.

I think this is not correct.
If I read the elf documentation correctly a shared lib does not have to 
follow DT_NEEDED.

See attached patch.


Only runtime loaders are required to follow DT_NEEDED.  link editors 
aren't.  There's no distinction between emitting a shared lib or an 
executable.  (And for OUTPUT_MEMORY, which might be said to make tcc 
behave like a runtime loader, it's actually dlopen which does the 
necessary DT_NEEDED following).



Ciao,
Michael.

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

Re: [Tinycc-devel] rc testing with netbsd-curses: build break

[Michael Matz]

Hello,

On Sat, 23 Sep 2023, grischka wrote:


 That would be correct, when the target is TCC_OUTPUT_MEMORY
 but i think, in all other cases, tcc should not do that.


I'd suggest to use "grep -nrw tcc_load_dll ." for example.  There is
only one place from where tcc_load_dll() is called:

in libtcc.c:tcc_add_file_internal():

case AFF_BINTYPE_DYN:
   if (s1->output_type == TCC_OUTPUT_MEMORY) {
#ifdef TCC_IS_NATIVE
void* dl = dlopen(filename, RTLD_GLOBAL | RTLD_LAZY);
if (dl)
   tcc_add_dllref(s1, filename, 0)->handle = dl, ret = 0;
#endif
} else
ret = tcc_load_dll(s1, fd, filename, (flags &
AFF_REFERENCED_DLL) != 0);
break;

So, for TCC_OUTPUT_MEMORY, tcc does not use tcc_load_dll(),  It calls
"dlopen()" instead.  Where dlopen() would invoke the dynamic linker
(ld.so) and that one then would take care to load any dependencies
(DT_NEEDED tags).


TLDR: the recursive load_dll can be removed.

Long variant:

This all is simply the old way of linking against dynamic libs in the 
binutils ELF linker.  TCC currently does like binutils ld would do with 
--copy-dt-needed-entries, which once was the only way, and after 
introduction of that option was the default for some more time. 
Eventually the default was switched, most software was fixed to work in 
the new mode (some did break with this change!), and now TCC could switch 
as well.  The behaviour was changed because the new one resembles how 
linking against static archives works (which don't have dependencies), and 
consistency between static and dynamic linking is a good thing.


I.e. TCC doesn't need to traverse DT_NEEDED entries of cmdline-mentioned 
shared libs anymore, it can ignore them while link-editing and have the 
same behaviour like most other current ELF linkers.


(Of course that just means that the error that now is spit out by TCC 
while link-editing, needs to be solved in a different way by the 
build-system or latest at runtime.  If TCC can't find foobar.so from 
DT_NEEDED, then the dynamic linker will also not find it without help, 
e.g. when the build system uses LD_LIBRARY_PATH, -runpath or other such 
means, or simply doesn't run uninstalled binaries requiring uninstalled 
libs (i.e. requires all of these to be installed).  ncurses indeed doesn't 
have that problem)



Ciao,
Michael.

___
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'

[Michael Matz]

Hello,

On Tue, 12 Sep 2023, avih via Tinycc-devel wrote:


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


"Very problematic" seems an exaggeration given that e.g. GCC behaves 
exactly the same, given the right circumstances.  TCC, as GCC, freely 
emits calls to memcpy, memmove and memset.  It did so forever, like GCC. 
If anything then this is a problem of documentation (not for the 
command line help).  TCCs docu is incomplete in many aspects, and this 
isn't the biggest problem by far.



Even if these are terrible suggestions, the question remains:
What does the user need to do in order to use -nostdlib?


The user needs to provide a working implementation of memcpy, memmove, 
memset (and abort).



And maybe also: what is -stdlib good for?


Hmm?  It's the opposite of nostdlib.  And nostdlib is for exactly the 
documented purpose: prevent linking with default startup files and C 
library.  If you're asking what _that_ is for, then: developing software 
that doesn't make use of the usual hosted C environment, like boot 
loaders or OS kernels.  It's a special-case option, not to be used in 
random software development.



Ciao,
Michael.

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

Re: [Tinycc-devel] Bug 63816 fixed (yarpgen_v1). Thanks Michael

[Michael Matz]

Hey,

On Wed, 8 Mar 2023, Detlef Riekenberg wrote:

> Your commit c771cb52 fixes a lot of bugs in the yarpgen v1 generated tests.
> 
> For seed values from 1 to 99, only 4 result failures left: 26, 56, 64 and
> 84.
> For 100 to 200, there are some more result failures (102, 117 and 173)
> and some compile aborts: 123, 143, 197.

Thanks for checking.  Most of them were struct with anon bitfield members.  
When their sizes were full types (i.e. 32bit int fields) they weren't 
ignored in initializers like they should.  Fixed in mob by Herman.

seed 64 was different and a problem with ternary expressions whose 
condition was a ternay-op itself.  Also fixed in mob.  seeds from 1 to 200 
are working fine for me now.  (I haven't checked others)


Ciao,
Michael

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

Re: [Tinycc-devel] TCC produced wrong code (yarpgen v1)

[Michael Matz]

Hey,

On Sat, 18 Feb 2023, wine@web.de wrote:


While trying yarpgen (v1 branch of github.com/intel/yarpgen ),
various test files compiled with tcc (x86_64@linux) produce a wrong result.

I compared the first failed program with gcc
and found an "if" section in the example code,
where the compiled programs from both compiler
(tcc and gcc-12) enter the "true" section,
but in the middle of the "if" sections,
the tcc compiled code breaks out of the "true" part of the "if" section
and execution continiues at the start of the "false" section.

Very strange


The problem (at least for the 'yarpgen -s 5' generated program) is fixed 
in mob now.  I haven't tried yarpgen on more than your reported example, 
so you might want to check yourself.


FWIW, the problem was that too complicated expressions involving 
short-circuiting || and && with constant operands sometimes left code 
generation deactivated to further statements outside the expression (which 
is why it seemed to jump from inside the true if block to some random 
other place).



Ciao,
Michael.



Any idea, how to nail down the issue?

I already increased some internal stacks:
#define INCLUDE_STACK_SIZE  932
#define IFDEF_STACK_SIZE964
#define VSTACK_SIZE 9256
#define STRING_MAX_SIZE 91024
#define TOKSTR_MAX_SIZE 9256
#define PACK_STACK_SIZE 98


The example source works with clang (v15) and gcc (v12)
and is attached to a bug report:
https://savannah.nongnu.org/bugs/?63816




___
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] clang 15.0 issue with tcctest.c

[Michael Matz]

Hello,


On Thu, 17 Nov 2022, Christian Jullien wrote:


Test later fails with

tcctest.c:2903:17: error: incompatible pointer to integer conversion passing
'void *' to parameter of type 'int' [-Wint-conversion]

    old_style_f((void *)1, 2, 3.0);

    ^


So, this is a warning promoted to an error with recent clang.  We try to 
avoid such compatibility warnings explicitely (by compiling with -w), but 
clang doesn't heed this request anymore.


The warning here is a bit on the border because this is an old style 
function definition, and parameter types are not compared for calls to 
such functions (though the call will be undefined behaviour if the types 
aren't compatible, which is indeed the case here, so a warning is somewhat 
justified).


Can clang15 at least be convinced to not warn (and hence error out) here 
with -Wno-int-conversion?  If so that would be the solution.  If not, we 
have a problem, because tcc _wants_ to support exactly this situation 
(until we decide that we don't, then we need to adjust the testcase).



Ciao,
Michael.___
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

[Michael Matz]

Hello,

On Thu, 20 Oct 2022, avih 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?


That's simply how the win10 runtime behaves a little different.  stack and 
malloc memory ultimately all rely on memory pages gives out by the kernel 
to userspace (on unix that's mmap and on windows that's CreateFileMapping 
and friends), and the win10 kernel happens to give out pages 
residing beyond 4GB by default, while the win7 kernel does not (at least 
for you, in your cases; but I'm guessing that Microsoft is slowly but 
surely eliminating artifacts that still stem from compatibility 
considerations between win32 and win64: giving out pages below 4GB by 
default, even for 64bit processes, would be such compatibility hack)



> 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


Ah, I haven't checked mob before fiddling with this.

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


Yup, as I said, I wasn't able to test for real ;-)


Ciao,
Michael.

___
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

[Michael Matz]

tomic(long) atomic_long;  [position 44:17]
typedef _Atomic(long) atomic_long;  [position 44:30]
typedef _Atomic(unsigned long) atomic_ulong;  [position 45:26]
typedef _Atomic(unsigned long) atomic_ulong;  [position 45:40]
typedef _Atomic(long long) atomic_llong;  [position 46:17]
typedef _Atomic(long long) atomic_llong;  [position 46:22]
typedef _Atomic(long long) atomic_llong;  [position 46:36]
stddef.h
    __FILE__, __FUNCTION__, p, (unsigned long)offset);  [position 
514:50]
    __FILE__, __FUNCTION__, p, (unsigned 
long)offset); \  [position 562:50]
    (void *) (addr + fp), (unsigned long) p[1]);  
[position 642:53]
    (void *) (addr + fp), (unsigned long) p[1]);  
[position 717:57]
    __FILE__, __FUNCTION__, p, (unsigned long)size); [position 
737:50]

    unsigned long start;  [position 1007:18]
    unsigned long end;  [position 1008:18]
    unsigned long ad =  [position 1009:18]
    (unsigned long) __builtin_return_address(0); [position 
1010:23]

    (void *) p[0], (unsigned long) p[1]); [position 1082:46]
    argv[i], (unsigned long)(strlen (argv[i]) + 1));  
[position 1114:44]
    *p, (unsigned long)(strlen (*p) + 1));  [position 
1138:39]

 (unsigned long) tree->size); [position 1193:36]
 __FILE__, __FUNCTION__, ptr, (unsigned 
long)size);  [position 1442:61]
    __FILE__, __FUNCTION__, ptr, (unsigned long)size);  [position 
1452:52]
    __FILE__, __FUNCTION__, ptr, (unsigned long)size);  [position 
1491:52]
    __FILE__, __FUNCTION__, new_ptr, (unsigned long)size);  
[position 1569:56]
 __FILE__, __FUNCTION__, ptr, (unsigned long)size);  
[position 1606:61]
 __FILE__, __FUNCTION__, ptr, (unsigned long)size);  
[position 1614:53]
    __FILE__, __FUNCTION__, start, (unsigned long)size);  
[position 1637:54]
    __FILE__, __FUNCTION__, start, (unsigned long)size);  
[position 1653:54]

    p, (unsigned long)size, function);  [position 1672:30]
    p1, (unsigned long)n1, p2, (unsigned long)n2, 
function);  [position 1687:31]
    p1, (unsigned long)n1, p2, (unsigned long)n2, function);  
[position 1687:54]
    __FILE__, __FUNCTION__, dest, src, (unsigned long)n);  
[position 1696:58]
    __FILE__, __FUNCTION__, s1, s2, (unsigned long)n);  [position 
1712:55]
    __FILE__, __FUNCTION__, dest, src, (unsigned long)n);  
[position 1732:58]
    __FILE__, __FUNCTION__, s, c, (unsigned long)n); [position 
1742:53]
    __FILE__, __FUNCTION__, dest, src, (unsigned long)n);  
[position 1752:58]
    __FILE__, __FUNCTION__, dest, src, (unsigned long)n);  
[position 1764:58]
    __FILE__, __FUNCTION__, dest, src, (unsigned long)n);  
[position 1774:58]
    __FILE__, __FUNCTION__, dest, src, (unsigned long)n);  
[position 1784:58]
    __FILE__, __FUNCTION__, s, c, (unsigned long)n); [position 
1794:53]
    __FILE__, __FUNCTION__, dest, src, (unsigned long)n);  
[position 1836:58]
    __FILE__, __FUNCTION__, s1, s2, (unsigned long)n);  [position 
1871:55]
    __FILE__, __FUNCTION__, new, (unsigned long)(p -s));  
[position 1931:52]

    (void *) t->start, (unsigned long) t->size, [position 2185:42]


On 19/10/22 14:36, Michael Matz wrote:

 Hello,


 On Fri, 14 Oct 2022, avih via Tinycc-devel wrote:


 0x7ff72b42b266 <+50>: repnz scas %es:(%rdi),%al
 0x7ff72b42b268 <+52>: dec %edi


 This is the problem.  "dec %edi" truncates the %rdi register to 32bit by
 zero-extension, so that ...


 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)


 ... this insn now segfault.  That only matters if the stack (which %rdi
 points into) is setup such that it's beyond 32bit, which ...


 rdi 0xcb9ff955 3416258901
 rbp 0x4ecb9ff8f0 0x4ecb9ff8f0
 rsp 0x4ecb9ff8e0 0x4ecb9ff8e0


 ... is indeed the case on win10 for you.  So, it's not malloc() result,
 but it does have to do with address space layout.

 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.


 Ciao,
 Michael.

 --

 diff --git a/tests/tcctest.c b/tests/tcctest.c
 index f5bd9aab..1d

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

[Michael Matz]

Hello,


On Fri, 14 Oct 2022, avih via Tinycc-devel wrote:


0x7ff72b42b266 <+50>: repnz scas %es:(%rdi),%al
0x7ff72b42b268 <+52>: dec %edi


This is the problem.  "dec %edi" truncates the %rdi register to 32bit by 
zero-extension, so that ...



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)


... this insn now segfault.  That only matters if the stack (which %rdi 
points into) is setup such that it's beyond 32bit, which ...



rdi 0xcb9ff955 3416258901
rbp 0x4ecb9ff8f0 0x4ecb9ff8f0
rsp 0x4ecb9ff8e0 0x4ecb9ff8e0


... is indeed the case on win10 for you.  So, it's not malloc() result, 
but it does have to do with address space layout.


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.



Ciao,
Michael.

--

diff --git a/tests/tcctest.c b/tests/tcctest.c
index f5bd9aab..1d625b0c 100644
--- a/tests/tcctest.c
+++ b/tests/tcctest.c
@@ -3254,7 +3254,7 @@ void local_label_test(void)
 /* from linux kernel */
 static char * strncat1(char * dest,const char * src,size_t count)
 {
-long d0, d1, d2, d3;
+size_t d0, d1, d2, d3;
 __asm__ __volatile__(
"repne\n\t"
"scasb\n\t"
@@ -3276,7 +3276,7 @@ return dest;

 static char * strncat2(char * dest,const char * src,size_t count)
 {
-long d0, d1, d2, d3;
+size_t d0, d1, d2, d3;
 __asm__ __volatile__(
"repne scasb\n\t" /* one-line repne prefix + string op */
"dec %1\n\t"

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

Re: [Tinycc-devel] __attribute__((constructor)) not getting called

[Michael Matz]

Hello,

On Sat, 1 Oct 2022, Liam Wilson wrote:


Note __attribute__((constructor)) has been stripped off bar and not foo.


Yep, that's the glibc headers defining __attribute__ away ...


Digging a bit further, it seems to be due to sys/cdefs.h (which is
included by string.h and many other standard headers). In sys/cdefs.h
I found this:


... as you found out.

Is there a work around for this issue? I can define __GNUC__ but 
presumably that may cause other issues?


The work-around is to use the other form of attribute: __attribute(foo)
(note the missing suffix of '__').  That's still in the implementation 
namespace and not defined away by glibc.


The other work-around would be to '#undef __attribute__' after all glibc 
headers are included.  As  (on glibc!) also has header guards 
you might also get away with this, as first directives in the .c files:


  #include 
  #undef __attribute__

as the following includes, even if they include  again, won't 
parse its content again.  As TCC ignores unknown attributes that should 
work fine for the decls in the glibc headers as well.



Ciao,
Michael.

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

Re: [Tinycc-devel] VLA support is not detected with autoconf

[Michael Matz]

Hey,

On Sun, 18 Sep 2022, Detlef Riekenberg wrote:



tcc can't compile the attached VLA check (gcc works)
and configure adds "#define __STDC_NO_VLA__ 1" to config.h

The code was generated using the autoconf macro "AC_C_VARARRAYS".

console output:
tcc -std=c11  vla_conftest.c -c
vla_conftest.c:30: error: constant expression expected


Any ideas, how to fix that?


Fixed in mob.


Ciao,
Michael.

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

Re: [Tinycc-devel] miscompilation for code snippet

[Michael Matz]

Hey,

On Tue, 16 Aug 2022, ntysdd via Tinycc-devel wrote:


Sorry, bad format.


 #define G(x) _Generic((x),int*:"int*",void*:"void*")

 int printf(const char*, ...);

 int main()
 {
         int y = 0;
         const char *s = G(1?(void*)(y*0LL):);
         printf("%s\n", s);
 }


Fixed in mob.


Ciao,
Michael.





 


-- Original --
From: "ntysdd" ;
Date: Tue, Aug 16, 2022 08:32 PM
To: "tinycc-devel";
Subject: miscompilation for code snippet

TCC gets different result than gcc or clang for code below

 #define G(x) _Generic((x),int*:"int*",void*:"void*")

 int printf(const char*, ...);

 int main()
 {
 int y = 0;
 const char *s = G(1?(void*)(y*0LL):y);
 printf("%s\n", s);
 }

expected
void*

actual
int*

Similar constructs are used in Linux kernel.

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

Re: [Tinycc-devel] [patch] adding path resolution to #line directives

[Michael Matz]

Hey,

On Fri, 6 May 2022, Raul Hernandez wrote:

It would seem better to canonicalize during generating this, because 
the above and this don't look equivalent anyway (they are equivalent 
only when the above relative path is less that seven levels deep from 
/).


In our case this isn’t an issue, since the .c file is always compiled 
under /tmp/v_*/, so two levels would actually be enough here.


Sure, but TCC also has to work on input not coming from V.

The problem is that we cannot use an absolute path either (/home/…), 
because tcc will always prepend the file’s directory, even if the #line 
directive contains an absolute path. I guess a different fix could be to 
check for absolute paths, and prevent tcc from prepending the file 
surname if that’s the case,


That seems like a fix for what clearly is a bug in TCC, yes.  TCC 
shouldn't prepend something that is already an absolute path.


but I still think resolving relative paths 
is useful (one could generate #line directives like 
/my/lang/stdlib/../thirdparty/foo.c), and tcc would resolve them down to 
/my/lang/thirdparty/foo.c for cleaner backtraces, for example.


Well, IMHO TCC should do as little processing on what the producer put 
into the '#line' directives, simply because one has to assume that the 
producer did whatever it did for good reasons.  Prepending the compile 
directory to relative paths is borderline acceptably IMHO, but more than 
that: I don't think so.


So you simply remove '../' components without a matching directory 
part. That isn't correct in all circumstances.


This is only ever hit when enough ../’s have been parsed so that the 
beginning of the path (inserted by tcc or otherwise) has been completely 
removed, and we’re left at the root of the filesystem. In that case, 
/../ can be collapsed down to / . Could you give me an example of where 
this would be incorrect?


Hmm, you're right, it should be okay.  (It still feels strange, as it 
relies on the fact that '/..' is equal to '/').  But that still leaves the 
issue of symlinked directories, removing "dir/../" components from paths 
simply isn't preserving the path when 'dir' is a symlink to another 
directory:


% mkdir -p sub/sub2; touch sub/sub2/foo
% ln -sf sub/sub2 symlink
% ls symlink/../sub2/foo
symlink/../sub2/foo
% ls sub2/foo
ls: cannot access 'sub2/foo': No such file or directory

So, no, I don't think the patch is okay, it can transform correct input 
into incorrect output, even if it sometimes also transforms into nicer 
output.


You might consider using realpath(3) (which is in POSIX) to do all of 
this for you.


I tried that, but realpath() checks if the path actually exists on the 
filesystem, and returns an error if it does not, unfortunately.


Well, yeah, it has to, due to the above symlink problem.

This might be generally usefull to libtcc users, and the variant 
printing it out can be written in terms of the char** variant; so that 
seems sensible to have.


I can include that function then; the main__foo -> main.foo change is 
indeed very V-specific.


Related: libbacktrace has an API where it accepts a callback, which is 
then called with a backtrace frame's information 
(https://github.com/ianlancetaylor/libbacktrace/blob/master/backtrace.h#L91-L102 
), 
so that might be a useful alternative too.


Maybe, yeah.  I don't have a strong opinion there.


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

Re: [Tinycc-devel] [patch] adding path resolution to #line directives

[Michael Matz]

Hey,

On Thu, 5 May 2022, Raul Hernandez wrote:


The code we generate looks something like this:

    #line 29
"../../../../../../home/spaceface/git/v/v/vlib/builtin/builtin.c.v"


It would seem better to canonicalize during generating this, because the 
above ...



   /tmp/v_1000/../../../../../../home/spaceface/git/v/v/vlib/builtin/builtin.c
.v:53: at panic_debug: Backtrace


... and this don't look equivalent anyway (they are equivalent only when 
the above relative path is less that seven levels deep from /).



    @@ -2042,6 +2042,22 @@ include_done:
                    pstrcpy(buf, sizeof buf, file->true_filename);
                    *tcc_basename(buf) = 0;
                    pstrcat(buf, sizeof buf, (char *)tokc.str.data);
    +                // collapse relative `../`s
    +                while ((q = strstr(buf, "../")) != NULL) {
    +                    (q == buf) ? (*q = '\0') : (*(q-1) = '\0');
    +                    last_slash = strrchr(buf, '/');
    +                    if (last_slash == NULL) {
    +                        memmove(buf, q + 2, strlen(q + 2) + 1);


So you simply remove '../' components without a matching directory part. 
That isn't correct in all circumstances.  You might consider using 
realpath(3) (which is in POSIX) to do all of this for you.  But as said, 
you might also be better off to just do that during generating the #line 
directives, so as to be independend of compiler behaviour.



Would you be willing to merge something this?

We’ve also added a function that returns the backtrace as a char** rather
than printing it out,


This might be generally usefull to libtcc users, and the variant printing 
it out can be written in terms of the char** variant; so that seems 
sensible to have.



and modified the backtrace functions to replace
e.g. main__foo with main.foo in symbol names,


But this is quite specific to V, so not too applicable without making it 
more general, at which point it doesn't look too attractive anymore.



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

Re: [Tinycc-devel] Disabling memmove optimization

[Michael Matz]

Hi,

On Tue, 26 Apr 2022, Raul Hernandez wrote:


I guess TCC does this as either an optimization (to take advantage of
vectorization in the implementation of memmove), or as a way of simplifying
the generated code.


The latter, plus simplifying the generat_ing_ code (i.e. TCC itself).


My question is: is there any way of disabling this behavior?


Nope.  An alternative way of moving arbitrary memory (which a struct copy 
is) simply isn't implemented in TCC.  To solve the problem that would need 
to happen, i.e. open-coding the memmove/memcpy, with the appropriate care 
for alignment and target specifics.


Ideally I’d wish to be able to disable it for a single function, but I’d 
be happy with a compiler flag when invoking TCC or a compile-time define 
when building it.


***

This probably sounds like the XY problem; the reason why I need to 
change that behavior is that I’m trying to write a closure 
implementation for the V programming language. It works similarly to the 
approach described in https://nullprogram.com/blog/2017/01/08/, but I’m 
trying to write it in pure C for portability (so that it works with any 
calling convention and number of parameters). The implementation works 
correctly when compiled with GCC and clang, but sometimes fails under 
TCC because of the optimization I described. Any function calls within 
the closure wrapper will become invalid after the wrapper is copied 
somewhere else in memory, since the relative offset to that function 
will be different and the CPU will jump to a garbage location instead.


If you have control over the closure wrapper you could perhaps avoid the 
memmove by open-coding any struct copy yourself (with a char-by-char copy 
loop).  If the memcpy/memmove is part of the call sequence (i.e. for 
struct params or returns) and you control even more of your closure 
implementation then you can arrange for the problematic types (e.g. all 
structs) to be passed and returned by reference/pointer and so avoid the 
problem.  If you can't do that, then you'd need to implement the open-code 
sequence emission in TCC.



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

Re: [Tinycc-devel] "error: invalid displacement" i386 1f 'L..1' does not get resolved

[Michael Matz]

Hello,

On Sun, 17 Apr 2022, Volodymyr Boyko wrote:


Hi
I'm trying to assemble the following snippet of code:

.global sigsetjmp
.global __sigsetjmp
.type sigsetjmp,@function
.type __sigsetjmp,@function
sigsetjmp:
__sigsetjmp:
        mov 8(%esp),%ecx
        jecxz 1f

        mov 4(%esp),%eax
        popl 24(%eax)
        mov %ebx,28+8(%eax)
        mov %eax,%ebx

.hidden ___setjmp
        call ___setjmp

        pushl 24(%ebx)
        mov %ebx,4(%esp)
        mov %eax,8(%esp)
        mov 28+8(%ebx),%ebx

.hidden __sigsetjmp_tail
        jmp __sigsetjmp_tail

1:      jmp ___setjmp
but getting this error:
src/signal/i386/sigsetjmp.s:8: error: invalid displacement
After renaming/moving the label around I assume the issue is that local
labels cannot be forward;1b and my_label moved to the top do work fine.


Yeah, it's related to that, but specific to the 'jexcz' opcode: the 
special thing about it is that it only comes in an 8-bit displacement form 
_and_ doesn't have an inverse form.  TCC, being single-pass, has to assume 
that forward labels could be anywhere, and hence potentially need a 32bit 
form (no matter that _in this case_ it would turn out to not be 
necessary), so jumps are rewritten into their disp32 forms for such 
labels.  For jecxz that can't be done.  And as the inverse form doesn't 
exist we can't even work around this by emitting something like a 
hypothetical:


  jecxnz +5   ; doesn't exist!
  jmp 1f

The GNU assembler uses multiple passes to figure out that the displacement 
in the testcase turns out to fit into a disp8 field and hence all is well. 
Add a couple more opcodes between the jecxz and the 1: label to make the 
distance larger than 128 and see it erroring out as well.


Supporting this requires some surgery (e.g. to support the _PC8 relocation 
and emitting them for this case only), so is of low priority.



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

Re: [Tinycc-devel] Question about Atomics support in TCC

[Michael Matz]

Hello,

On Fri, 8 Apr 2022, Davidson Francis wrote:


Hi Domingo, thanks for the additional data. That's exactly what I've
observed here: no type of lock or special instruction is generated,
nor is a function call generated either.

I'm not well-versed with compilers, but looking through the source
code (tccgen.c) it looks like atomic types are just handled like
their non-atomic counterparts, and that's why the generated code is
non-atomic, like any other primitive type .

So it seems to me that atomic support is still incomplete,


That's correct.  _Atomic isn't correctly supported by TCC as of now. 
Meaning: it's parsed and tracked as type qualifier and hence whose 
mismatch is warned about in conversions, but has no other effect, in 
particular nothing about guaranteeing atomic accesses.  Patches welcome :)



Ciao,
Michael.

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

Re: [Tinycc-devel] TinyCC does not accept variable-length static qualifier for function parameter arrays

[Michael Matz]

Hello,

On Mon, 28 Feb 2022, John Scott wrote:


On Mon, 2022-02-28 at 09:25 +0100, david.k...@libertysurf.fr wrote:

Gcc allows this, but Gcc is not conformant and creates "extensions" as it see 
fit.

This is not a GCC extension; it's my understanding that this is pure
C99. N2310 [1] (a C17 draft) 6.7.6.3 says

A declaration of a parameter as "array of type" shall be adjusted to
"qualified pointer to type", where the type qualifiers (if any) are
those specified within the [ and ] of the array type derivation. If the
keyword static also appears within the [ and ] of the array type
derivation, then for each call to the function, the value of the
corresponding actual argument shall provide access to the first element
of an array with at least as many elements as specified by the size
expression.

Correct me if I'm wrong, but isn't argc+1 an expression?


You are correct, it's ISO C and tcc isn't conforming in rejecting this. 
Patches welcome :-)



Ciao,
Michael.



[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf



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

Re: [Tinycc-devel] Using tcc for reflection

[Michael Matz]

Hello,

On Tue, 1 Feb 2022, Domingo Alvarez Duarte wrote:


Hello Elijah !

On 1/2/22 6:30, Elijah Stone wrote:

 ‘cleanup’ variable attribute


It doesn't seem that tinycc has this implemented properly because testing it 
with this example 
https://echorand.me/site/notes/articles/c_cleanup/cleanup_attribute_c.html I 
can build and execute it but there is no output (with gcc there is the 
expected output).


This is deceptive!  The GNU libc headers unconditionally define 
'__attribute__()' to nothing if the compiler isn't GCC, and not just 
internally, so a declaration like:


#include 


  int __attribute__((whatever!)) avar;

doesn't set any attribute at all :-/  Either do:

#undef __attribute__

after including all standard headers, or use the other form of that token:

  int __attribute((cleanup(clean_up))) avar = 1;


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

Re: [Tinycc-devel] Fwd: TCC VLA bug?

[Michael Matz]

Hello grischka,

On Tue, 7 Dec 2021, grischka wrote:


Michael Matz wrote:

 So, the problematic type was:

   int (*)[a][b]

 That's pointer to an vla-array of an vla-array of int.  All three (inner
 array, outer array and pointer, but not the int) should be marked
 VT_VLA.


Hm...,

IMO one (very) invariant convention is that VT_ARRAY rsp. VT_VLA
always also have VT_PTR.

Therefor if the outer pointer would have VT_VLA as you say above,
then it would be not a pointer to a VLA, but it would be a VLA,
as in

   int arr[z][a][b];


Right, sorry.  It really doesn't help to be imprecise here, like I was. 
In the type 'int (*)[a][b]' the outer pointer doesn't need VT_VLA, but the 
inner two array types do (and the int itself doesn't).  But I was wiggling 
around because I also wanted to avoid really looking into it :) 
TCC should generate four CType structs for this type:


  CType *t;   // the full thing, VT_PTR only, 'int (*)[a][b]'
  CType *o = t->ref;  // outer vla, VT_PTR|VT_VLA, 'int [a][b]'
  CType *i = o->ref;  // inner vla, VT_PTR|VT_VLA, 'int [b]'
  CType *e = i->ref;  // element, 'int'

And without looking I wasn't sure it really does (I still am not) ;-)


Anyway, now that I already did look into it (which initially I was
trying to avoid ;) I would maybe just replace all this:


 if (type1.ref->type.t & VT_VLA)
 vla_runtime_pointed_size();
 else {
 u = pointed_size();
 if (u < 0)
 tcc_error("unknown array element size");
#if PTR_SIZE == 8
 vpushll(u);
#else
 /* XXX: cast to int ? (long long case) */
 vpushi(u);
#endif


by that single line:

   vla_runtime_type_size(pointed_type([-1].type), ):


Yeah, I thought so as well when (very quickly! :) ) looking at this.  Also 
in some other places that currently only conditionally call this.


which looks as it would do the right thing automatically also for the 
normal array (non-vla) case (but except the "unknown array size" check).


Of course one could rename "vla_runtime_type_size" to something better, 
then.


Btw, now that I already did look into it (which initially ... ;) I think
I found 2 related problems as can be seen with this (added to the original
test case):

// int (*arr)[h][w];
printf("diff = %d, size = %d/%d\n",
arr + 1 - arr, sizeof *arr, sizeof (*arr + 1));


Yeah, during my quick scanning of tccgen.c I also found code that made me 
think 'huh?', and imagined there could be more errors like this, 
especially with multi-dimensional VLAs.  Alas, I wanted to not get into 
tcc hacking this week :)  Temptations everywhere!



Ciao,
Michael.



-- gr



 In TCC we collapse the outer array+pointer into one type (a
 pointer that also has VT_ARRAY/VT_VLA set), so there actually should be
 two levels: the inner level a VT_VLA pointing to the VT_INT (with its
 VLA runtime length being evaluated to sizeof(int) * b) and the outer
 level a VT_VLA pointing to the inner VT_VLA (and its VLA runtime length
 being evaluated to inner length * a).

 I'm surprised that your patch didn't cause other problems, it seems
 either the testsuite isn't testing VLAs very much, or that the VT_VLA
 flag is set on types where it shouldn't have been (e.g. on the VT_INT
 type that is in the type->ref of the 'int [n]' array type).


 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] How exactly inline works and should I inline all the time?

[Michael Matz]

Hey,

On Tue, 7 Dec 2021, Antoni Gual Via wrote:


Perhaps it's  time to have a new official release?Antoni


Perhaps, but not because inlining would be done now: it isn't.  TCC 
doesn't inline functions into others.  But due to how c99 and c11 have 
special requirement for functions marked "inline" the keyword isn't 
completely ignored either, but it still doesn't cause called functions to 
be integrated into their callers.


Inline asm is something else (and doesn't use an "inline" keyword 
anyway), it simply describes the fact that you can write assembler 
instructions in C files, "in line" with the C sources, and don't have to 
resort writing .s files.



Ciao,
Michael.



[icon-envelope-tick-round-orange-animated-no-repeat-v1.gif] Libre de 
virus. www.avast.com


Missatge de l'adreça  del dia dt., 7 de des. 2021
a les 10:44:
  Probably in 0.9.27 (which is almost 4 years old, btw
  -17-Dec-2017 08:27-) :

  http://download.savannah.nongnu.org/releases/tinycc/
  https://repo.or.cz/tinycc.git ("release_0_9_27" tag)

  Yet it officially supports inlined assembly, that also uses the
  'inline' keyword, hence not completely "ignored".

  Anyway, if you look at the tcc source code (tccgen.c, tccpp.c,
  ...) there is already plenty of "inline" inside.

  Regards.

  - Mail d'origine -
  De: Antoni Gual Via 
  À: tinycc-devel@nongnu.org
  Envoyé: Tue, 07 Dec 2021 09:32:35 +0100 (CET)
  Objet: Re: [Tinycc-devel] How exactly inline works and should I
  inline all the time?

  Have I missed anything?
  The documentation for TCC 0.27 states that the inline keyword is
  ignored

  Antonio



  Libre
  de virus. www.avast.com

  <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

  Missatge de Antonio Prates  del dia
  dt., 7 de des.
  2021 a les 0:35:

  > Also note you can't inline recursive functions, and other
  restrictions
  > could apply.
  >
  > Maybe have a look into this thread on quora:
  > https://www.quora.com/Can-a-inline-function-be-recursive
  >
  > On Dec 6 2021, at 6:23 pm, david.k...@libertysurf.fr wrote:
  >
  > > Inline is used very specifically where the code has to be
  fast.
  > >
  > > Best is only to inline tiny parts of code that will be
  "inlined".
  > >
  > > That's to say "injected" into the source code where it is
  needed.
  > >
  > > Otherwise it is a full jump to a distant function, with
  context saving.
  > >
  > > Hence the "inlining" only serves a very specific purpose.
  > >
  > > Regards.
  > >
  > > - Mail d'origine -
  > > De: rempas via Tinycc-devel 
  > > À: Tinycc Devel 
  > > Cc: rem...@tutanota.com
  > > Envoyé: Mon, 06 Dec 2021 09:35:19 +0100 (CET)
  > > Objet: [Tinycc-devel] How exactly inline works and should I
  inline all
  > > the time?
  > >
  > > Hi!
  > >
  > > I don't know if we must only post questions that are
  specific to the
  > > TCC compiler
  > > specifically (even tho this question can differ from
  compiler to
  > > compiler) or we can
  > > make questions about C in general and in the case that the
  first is
  > > true then please
  > > inform me so I know. Anyway I wanted to ask how inline works
  > > specifically and not
  > > generally. I know generally that it "puts the source code"
  inline so
  > > we don't have to use
  > > "jmp" but is there anything else to it that I should know?
  Are there
  > > any dangers or reasons
  > > than someone should not use it? Also is there a way to tell
  the
  > > compiler to inline every
  > > function rather than always having to add the "inline"
  keyword?
  > >
  > > ___
  > > 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


___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org

Re: [Tinycc-devel] Fwd: TCC VLA bug?

[Michael Matz]

Hey,

On Sun, 5 Dec 2021, Herman ten Brugge via Tinycc-devel wrote:


On 12/1/21 15:18, grischka wrote:
  Got this report on private email.  Not sure what it means ...
  -->>

  Output of the code below if compiled with TCC is pretty messy:
  array values are "misplaced" and overwrite each other.
  But everything's ok if compiled with GCC.


The patch below seems to fix it. Can I push it?

    Herman

diff --git a/tccgen.c b/tccgen.c
index e0b5fd6..67e205b 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -3494,7 +3494,7 @@ redo:
gen_cast_s(VT_INT);
#endif
type1 = vtop[-1].type;
-    if (vtop[-1].type.t & VT_VLA)
+    if (vtop[-1].type.ref->type.t & VT_VLA)
vla_runtime_pointed_size([-1].type);


Hmm, that would mean the VT_VLA flags are wrongly set.  The invariant of 
vla_runtime_pointed_size(type...) is that type->t has VT_VLA (and that 
type->ref is meaningful).  If your patch helps in this situation that 
means the flag setting is going wrong somewhere.  I see that the testcase 
has doubly-vla types, maybe only the innermost level is marked, but a 
variable length type is of course variably length if any of the referred 
types is, so maybe that's the problem.  Just speculation, though.


So, the problematic type was:

  int (*)[a][b]

That's pointer to an vla-array of an vla-array of int.  All three (inner 
array, outer array and pointer, but not the int) should be marked VT_VLA. 
In TCC we collapse the outer array+pointer into one type (a pointer that 
also has VT_ARRAY/VT_VLA set), so there actually should be two levels: the 
inner level a VT_VLA pointing to the VT_INT (with its VLA runtime length 
being evaluated to sizeof(int) * b) and the outer level a VT_VLA pointing 
to the inner VT_VLA (and its VLA runtime length being evaluated to inner 
length * a).


I'm surprised that your patch didn't cause other problems, it seems 
either the testsuite isn't testing VLAs very much, or that the VT_VLA 
flag is set on types where it shouldn't have been (e.g. on the VT_INT type 
that is in the type->ref of the 'int [n]' array type).



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

Re: [Tinycc-devel] Identifying mob build via preprocessor

[Michael Matz]

Hello,

On Mon, 9 Aug 2021, Elijah Stone wrote:

IMO a cleaner solution would be to support clang's 
__has_feature/__has_builtin/__has_extension.  This:


- Is clearer: says exactly what you mean.

- Is less error-prone; if a feature goes away in a later version or in
  some configuration, or if you typo'd the version number in the first
  place, version checking will fail but feature checking won't.

- Doesn't disadvantage newer compilers, which might have implemented the
  extension you need but which your codebase didn't manually check for.
  (The way all compilers pretend to be __GNUC__ reminds me of the way all
  browsers pretend to be Mozilla.)

The disadvantage is that it's harder to implement.


And larger :)  I think the patch as-is is a good one (though maybe count 
from initial commit, not from the 0.9.27 release?), even though that macro 
will be awkwardish to use (and with the disadvantages you named).  I agree 
that the __has_*() predicates are better to use, but do note that it only 
fulfills the promised features if the names you put into the argument are 
agreed upon by compilers (or just taken from GCC or clang, as 
appropriate).  I would not let that better feature hold up the inclusion 
of the __TINYC_MOB__ patch.



Ciao,
Michael.


-E

On Mon, 9 Aug 2021, Alvarito050506 wrote:


 Hello!

 I'm currently using TCC for testing and experimenting because it's
 blazing fast (amazing work, by the way), and some libraries depend on
 GNU C features which are actually implemented in the `mob` branch, but
 the libraries only check for GCC and Clang, so I would like to send a
 few patches that would make them check for TCC > 0.9.27 too.

 The problem is, as far as I know, there is currently no way to detect
 a build from the `mob` branch, and using `__TINYC__` wouldn't an
 option since it doesn't change anymore.

 I made a small patch that defines `__TINYC_MOB__` as the number of
 commits since 0.9.27, and could be used like the following:

 /* Detect support for the cleanup attribute */
 #if defined(__GNUC__) || defined(__clang__) ||
 defined(__TINYC_MOB__) && __TINYC_MOB__ >= 68
 /* ... */

 I wonder if there is a better way to do this, and if it would be OK to
 add something like this?

 Thanks,
 Álvaro.

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

Re: [Tinycc-devel] tcc need to support --arch on macOS

[Michael Matz]

Hello,

On Tue, 27 Jul 2021, Christian JULLIEN wrote:


In order to support tcc bootstrap with tcc on macOS, we'll need to add -arch
 option to tcc.
It should at least support this option even if nothing is implemented
because -arch is now given on macOS because of this new configure test:


Why should the tcc source be changed to accept a useless flag when the 
configure sources could just as well be changed to not add it in the first 
place (e.g. if $CC doesn't support it)?



Ciao,
Michael.

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

Re: [Tinycc-devel] Errors using riscv64-tcc with gcc/newlib headers

[Michael Matz]

Hello,

On Mon, 19 Jul 2021, Sam Ellicott wrote:


I updated my patch to only include the bare minimum definitions
required to get tcc to compile the newlib stdint.h header. Thank you
for the advice on using the config-extra.mak file, that worked
perfectly.
If this looks okay, then I will push this change to the mob branch.


I agree with the inclusion of this small set of defines.  But I think 
you've put them into the wrong sections of tccdefs.h.  For the 
pointer-size related defines we have three sections (32bit, win64, 
other64) but you added them to only two.  Also your __INT32_TYPE__ define 
is within the __riscv section, but it would be valid for all current TCC 
targets.


So move the __INT32_TYPE__ one somewhere where it's always active.  And 
for the __{U,}INTPTR_TYPE__ defines you may be able to reuse the 
definition of __PTRDIFF_TYPE__ so that you need to change only one place 
instead of three.  (If you choose to not do that, then you need to add 
another hunk for the windows64 section).


I.e. the general idea would be that the macros from tccdefs.h exposing 
target details should be available unconditionally (with different values 
of course), not just on some configurations.  (Exceptions exist of course, 
but I don't see why __INT32_TYPE__ or __{U,}INTPTR_TYPE__ should be an 
exception).



Ciao,
Michael.

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

Re: [Tinycc-devel] Linking system dylibs on macOS 11+

[Michael Matz]

Hello,


On Wed, 7 Jul 2021, Sushant Pandurangi wrote:


Thanks for the Windows patches and the long double fix.
To clarify about tcc -run, I'm not using --cpu=x86-64 at all, I am on a
fresh M1 and Rosetta is not even installed. Here, `tcc -run` starts running
main() and very simple stuff (like Hello World) works already.

On the other hand in a cross-compiler config, I wonder if tcc -run can work
at all -- not unless Rosetta can do in-memory translation of the JIT'd
x86-64 code.

The 2 warnings at tccmacho.c:265/285 -- those are not from my code, did they
show up only after my patch? I wonder why. I'm not familiar with that
function and probably not the best person to make a fix.


Pre-existing and false positive.  The best way to fix them is to disable 
-Wstringop-truncation for that file.



Ciao,
Michael.



To Herman, thanks a lot for catching the memcheck issues.

Regards,
Sushant

  Date: Wed, 7 Jul 2021 07:55:41 +0200
  From: "Christian Jullien" 
  To: 
  Subject: Re: [Tinycc-devel] Linking system dylibs on macOS 11+
  Message-ID: <000301d772f4$b88cf070$29a6d150$@orange.fr>
  Content-Type: text/plain; charset="utf-8"

  Hello Sushant,

  Your pushed patch works at 99%.

  --- The details:

  there are few warnings:

  tccmacho.c: In function 'add_segment':
  tccmacho.c:265:5: warning: '__builtin_strncpy' specified bound
  16 equals destination size [-Wstringop-truncation]
   265 | strncpy(sc->segname, name, 16);
   | ^~~
  In function 'add_section',
     inlined from 'collect_sections' at tccmacho.c:649:22,
     inlined from 'macho_output_file' at tccmacho.c:812:9:
  tccmacho.c:285:5: warning: '__builtin_strncpy' specified bound
  16 equals destination size [-Wstringop-truncation]
   285 | strncpy(sec->sectname, name, 16);
   | ^~~

  --- More annoying.

  BUG1: tcc -run fails because it is not supported by
  cross-compiler. IMHO, on macOS --cpu should not be considered as
  cross-compiler
   hello-run 
  tcc: error: -run is not available in a cross compiler
  If I remove this test:
  #ifndef TCC_IS_NATIVE
     tcc_error("-run is not available in a cross
  compiler");
  #endif

  It fails with
   libtest 
  dyld: lazy symbol binding failed: Symbol not found:
  _tcc_relocate
   Referenced from: /Users/jullien/tinycc/tests/./libtcc_test
   Expected in: flat namespace

  dyld: Symbol not found: _tcc_relocate
   Referenced from: /Users/jullien/tinycc/tests/./libtcc_test
   Expected in: flat namespace

  BUG2: When compiled tcc with ./configure --cpu=x86_64
  Generated code is considered as a cross-compiler.
  Then, when I use a long double in my code, it reaches
  tccgen.c(8087): tcc_error("can't cross compile long double
  constants");

  In this specific case, both double and long double are 8 bytes
  but LDOUBLE_SIZE == 16

  I tried this patch which seems to solve this issues.
  Maintainers, is it the right patch? Do you allow me to push it
  on mod?
  If you prefer, I can surround it with #ifdef TCC_TARGET_MACHO

  jullien@mobley:~/tinycc $ git diff
  diff --git a/tccgen.c b/tccgen.c
  index c36032a..425a001 100644
  --- a/tccgen.c
  +++ b/tccgen.c
  @@ -8088,10 +8088,10 @@ static void init_putv(init_params *p,
  CType *type, unsigned long c)
  #endif
  /* For other platforms it should work natively,
  but may not work
     for cross compilers */
  -    if (sizeof(long double) == LDOUBLE_SIZE)
  -    memcpy(ptr, >c.ld, LDOUBLE_SIZE);
  -    else if (sizeof(double) == LDOUBLE_SIZE)
  -    memcpy(ptr, >c.ld, LDOUBLE_SIZE);
  +    if (sizeof(long double) <= LDOUBLE_SIZE)
  +    memcpy(ptr, >c.ld, sizeof(long
  double));
  +    else if (sizeof(double) <= LDOUBLE_SIZE)
  +    memcpy(ptr, >c.ld, sizeof(double));
  #ifndef TCC_CROSS_TEST
  else
  tcc_error("can't cross compile long double
  constants");




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

Re: [Tinycc-devel] Linking system dylibs on macOS 11+

[Michael Matz]

Hello,

On Mon, 5 Jul 2021, Christian Jullien wrote:


With
./configure --cpu=x86_64
I can build a working tcc on macOS Big Sur M1.
Compiler works using Rosetta, generated code also produces x86_64 code which 
runs the same way using Rosetta.

So your patch is workable solution to build and use tcc on macOS Big Sur M1 
until the native port is fixed.

Once you fixed the warnings I'll love to see this patch in mod (if 
maintainers agree).


For avoidance of doubt: I like the patch for parsing .tbd files.  Thanks 
Sushant!  (And the arm64 reloc problems are pre-existing)



Ciao,
Michael.

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

Re: [Tinycc-devel] Problem after compiling tiny CC

[Michael Matz]

Hello,

On Sat, 26 Jun 2021, Elijah Stone wrote:


On Sat, 26 Jun 2021, Clive Tovero via Tinycc-devel wrote:

 Also watch out for "ar", this will cause the problem too.


Perhaps 'tcc -ar' should add libtcc.a automatically (unless you tell it not 
to)?  That way it would be possible to compile a static library with tcc and 
link a gcc app to it.


No, 'tcc -ar' should behave like 'ar' (within the implemented features). 
It can't simply add random objects from random libraries to the output it 
creates.  There's a proposal somewhere to extend the ar format to be able 
to specify dependencies on libraries for the included objects, that would 
be a possible half-solution.  It's only a half-solution because it 
wouldn't specify search paths for the dependencies and hence would require 
putting the support libs into a default lib path forever (i.e. it would 
rules out the possibility to put that support lib in a compiler specific 
path like GCC is doing for e.g. libgcc.a).


The situation is the same as when trying to use gcc to link stuff compiled 
by g++, or to build with icc and link with clang, or when linking with ld 
directly, or the old problem of compiling with -pthread but not also 
linking with it.  If you do that you need to know how to link the 
compilers runtime libs into the result.  The easiest way to achieve this 
is to compile and link with the same program.


(for this specific instance of the problem with __mzerosf we could 
possibly find an alternate solution, but I think we shouldn't bother as 
there are other instances that can't be easily changed).



Ciao,
Michael.

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

Re: [Tinycc-devel] manually inlining functions

[Michael Matz]

Hello,

On Tue, 4 May 2021, uso ewin wrote:


Tinycc handle inline function like if they were macro, so using inline
in tcc always inline functions.


That's not accurate.  Inline functions in TCC are emitted like normal 
functions but only when there's reason to emit them (which are involved 
and depend on if they are called (or address-taken) or if they are c99 
inline or gnu inline semantics, and static or global).  But they are _not_ 
emitted like macros at every use, rather a normal argument setup and call 
is done, and the body is emitted only once as a normal function.


Either way, the discussion about speed of inline functions in TCC is 
fairly academic, code performance is low for many other, more important, 
reasons.  There is no optimizer, there is no intermediate representation 
that could be optimized, there is nothing that could benefit from inlining 
except the call instruction and the prologue/epilogue itself would be 
removed.


Not even the argument setup would be saved very often: TCCs compilation 
model would require evaluating the arguments to local temporaries which 
are often spilled to stack right soon, in the end needing exactly the same 
work as the argument setup for a call.


I somewhen wrote a simple function inliner for tcc handling most normal 
cases (those when the inline doesn't contain a local static variable, and 
when no variadic args are used), but the result was somewhat so-and-so, 
there simply wasn't much point to having it before having a better 
single-pass optimizer / register allocator.



Ciao,
Michael.

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

Re: [Tinycc-devel] Insight on the macOS 11 port

[Michael Matz]

Hello,

On Mon, 26 Apr 2021, Hayden Seay wrote:

Hello there! I'm sure you're likely aware, but, as of macOS Big Sur, 
system dylibs are found exclusively in the dyld_shared_cache.


This poses a unique issue, where nothing can be linked now, as it can't 
find a libc mach-o. This can be solved one of two ways, by either 
dlopen/dlsym-ing at runtime, or by adding tapi support (Apple's YAML 
format they use in SDKs as opposed to real dynamic libraries). The 
source for libtapi can be found here: 
https://opensource.apple.com/source/tapi/tapi-1100.0.11/


My question is, is there a general consensus on which path to take, or 
has work already been started on one?


My plan was to eventually support the YAML symbol lists in TCC in case I 
wouldn't find a different way to get at the dyld_shared cache pieces: when 
I checked on older MacOS the shared cache was in a format where one could 
easily get at the individual Mach-O headers of components in the cache and 
hence with some massaging it would be possible to reuse the existing 
Mach-O symbol reader.  If that would turn out to be impossible on Big Sur 
for whatever reason parsing the YAML files would be the next best thing. 
I'm not sure of those files are only delivered as part of the SDK (or at 
least command line tools), if so that would be a quality-of-implementation 
regression by Apple: linking against system libraries wouldn't be possible 
without the SDK then anymore, which it was with only TCC.  It wouldn't be 
a large regression, though, as without the SDK you wouldn't have had the 
headers anyway.


MacOS is low prio for me, and right now I only have virtual machines with 
pre-Big Sur, so the above plan didn't materialize yet :)


I don't know what other peoples plans were, but I think the above would be 
the right course of action.



Ciao,
Michael.

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

Re: [Tinycc-devel] Clarification about log message in commit 48df89e10e

[Michael Matz]

Hello,

On Mon, 19 Apr 2021, Michael Matz wrote:

I'm not sure what "this" refers to here, but we basically need to accept any 
of these forms of decls and defs of main:


int main();
int main() { ... }
void main();
void main() { ... }


Gah!  And of course also the ones with void (which does declare a 
prototype even outside of a function def, then, and hence must match a 
definition if there's a separate one):


int main(void);
int main(void) { ... }
void main(void);
void main(void) { ... }


int main(int argc, char *argv[]);
int main(int argc, char *argv[]) { ... }
void main(int argc, char *argv[]);
void main(int argc, char *argv[]) { ... }



Ciao,
Michael.

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

Re: [Tinycc-devel] Clarification about log message in commit 48df89e10e

[Michael Matz]

Hello,

On Sat, 17 Apr 2021, Stefanos wrote:


No particular reason most probably (except in the case when specifically
the standard mandated behaviour of 'int main()' is tested).  If you prefer
the void form for new tests use it.  (please don't change existing tests
except for good reasons)


The reason I asked this question is because I was reading the C standard and
found the following parts at 5.1.2.2.1 [1] and at 6.7.5.3/14 [2]:

   The function called at program startup is named main. The implementation
   declares no prototype for this function. It shall be defined with a return
   type of int and with no parameters:

   int main(void) { /* ... */ }

   or with two parameters (referred to here as argc and argv, though any names
   may be used, as they are local to the function in which they are declared):

   int main(int argc, char *argv[]) { /* ... */ }

   or equivalent; 9) or in some other implementation-defined manner.

and

   An identifier list declares only the identifiers of the parameters of
   the function. An empty list in a function declarator that is part of
   a definition of that function specifies that the function has no parameters.
   The empty list in a function declarator that is not part of a definition of
   that function specifies that no information about the number or types of
   the parameters is supplied.

In other words, all the tests that use `int main()` are open to accept
any number of parameters, correct?


This is all a bit academic, but anyway:

The difference is in "that is part of a definition" and "that is 
not part of a definition".  So:


  int main();

declares main as function but not anything about parameters (main has no 
prototype then).  While:


  int main() { ...; return 0; }

declares (and defines) main to be a function having no parameters. Even 
the first variant (i.e. missing prototype without parameter info) is no 
license to make main (or any other function) accept any number of 
parameters.  This is because "any number of params" would be a stdarg 
function, which must be declared and defined with a parameter type list 
that includes an ellipsis at the end.  You could call such function with 
arbitrary number and types of arguments, and the compiler wouldn't reject 
this, but at runtime it won't work.  The prototype is what is checked, so 
without one no checks are done.  But even without prototype the calls need 
to match the implementation of the function at run time (otherwise: 
undefined behaviour).


Additionally the "or in some other implementation-defined manner" gives us 
leeway to accept more declarations than strictly required, which makes us 
okay to accept:


  void main(void);

(i.e. without return type).  That is good, because in the wild this usage 
of main() happens, so we better accept it as well.



Was this implemented intentionally or just happened?


I'm not sure what "this" refers to here, but we basically need to accept 
any of these forms of decls and defs of main:


int main();
int main() { ... }
void main();
void main() { ... }
int main(int argc, char *argv[]);
int main(int argc, char *argv[]) { ... }
void main(int argc, char *argv[]);
void main(int argc, char *argv[]) { ... }

We need to accept these in such way that the user has to be able to 
write a prototype for main, and has to be able to _not_ have to write a 
prototype for it before definition.  If he chooses to write a prototype it 
must be compatible with the given definition as usual.
We need not accept other forms of main.  E.g. GCC warns 
with other forms, but TCC does not.  Sometimes it's convenient (when you 
know something about the C libraries implementation) to define main like 
so:


  int main(int argc, char *argv[], char *envp[]) { ... }

or even add another one (auxv) on some libc's, so adding more checks for 
validity would have to be done carefully to not disallow valid uses in the 
wild.


The reason why main() is so special-cased in the standard is historic.

I'm not sure if the above answers your question(s), if not, try asking 
more ;-)



Ciao,
Michael.

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

Re: [Tinycc-devel] Clarification about log message in commit 48df89e10e

[Michael Matz]

Hello,

On Sun, 11 Apr 2021, Stefanos wrote:


I hope you are doing well.

The following line in commit 48df89e10e confused me a bit: "don't use 
c99 in tcc (array designators etc.)"


Which C version is being used in TCC's implementation, can you please 
clarify?


If you restrict yourself to c89 that would match the requirement.  The 
actual requirement is rather: "needs to be compilable with an old msvc". 
I don't know which exact version of msvc that is, but it's one that 
doesn't support designated initializers and some other c99 stuff. 
grischka uses such msvc.


P.S.: Is there a particular reason for not using `void` inside `main` 
and you prefer `int main()` instead, in various tests that don't take 
user input as argument(s)?


No particular reason most probably (except in the case when specifically 
the standard mandated behaviour of 'int main()' is tested).  If you prefer 
the void form for new tests use it.  (please don't change existing tests 
except for good reasons)



Ciao,
Michael.

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

Re: [Tinycc-devel] macOS port is broken since "tccelf: use plt-reloc instead of relocplt" commit

[Michael Matz]

Hello,

On Mon, 29 Mar 2021, Ivan Medoedov wrote:


Hi Christian,
Just to confirm, you are ok with using GitHub Actions as the official CI for
the project?


What makes something official to you?  Noone can hinder you in setting up 
CI for anything you are interested enough to invest the work.  Someone did 
so in the past but it became stale:

  https://gitlab.com/giomasce/tinycc/pipelines


Ciao,
Michael.



Ivan

On Mon, Mar 29, 2021 at 7:58 AM Christian Jullien  wrote:

  To reproduce:

  -  Use Catalina or higher on x86_64

  -  Get mob

  -  ./configure; make && make test

   

  That’s all

   

  Please send us a pointer of this CI build when done.

   

  C.

   

  From: Tinycc-devel
  [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
  Behalf Of Ivan Medoedov
  Sent: Sunday, March 28, 2021 21:08
  To: jull...@eligis.com; tinycc-devel@nongnu.org
  Subject: Re: [Tinycc-devel] macOS port is broken since "tccelf:
  use plt-reloc instead of relocplt" commit

   

  Hello,

   

Can we please use GitHub CI to catch these?

 

I volunteer to set it up.

 

It's free and works amazingly well.

 

On Sat, Mar 27, 2021 at 11:26 AM Christian Jullien 
wrote:

  Sorry folks I should have detected this error sooner.

   

  Commit “tccelf: use plt-reloc instead of relocplt” by
  Grischka partially breaks macOS port.

   

  It still works except for tests:

   

  arg_align_test... success

   abitest-tcc 

  make[2]: *** [abitest-tcc] Segmentation fault: 11

  make[2]: Target `abitest' not remade because of errors.

   asm-c-connect-test 

   

  And on test

   

  Test: 114_bound_signal...

  --- 114_bound_signal.expect 2021-02-18
  14:42:59.0 +0100

  +++ 114_bound_signal.output 2021-03-27
  09:22:50.0 +0100

  @@ -1,2 +0,0 @@

  -start

  -end

  make[3]: *** [114_bound_signal.test] Error 1

   

   

  Any program, even an empty main() {} coredumps if –b is
  passed as with test 114.

   

  Christian

___
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] [PATCH] stdatomic: ld/st/xchg/cmpxchg on simple types

[Michael Matz]

Hello,

On Mon, 22 Mar 2021, Dmitry Selyutin wrote:


  "is it really the same type?"

A bit ambiguous wording. What I mean is that, for a naturally-aligned type
N, the corresponding call can be generated to routine __atomic_X_N. The code
generator doesn't need to care whether types in the _implementation_ of
__atomic_X_N must literally match those passed; if the semantics match, this
is enough. And, indeed, the code below...

    #include 
    #include 

    struct combo {
        uint16_t lo;
        uint16_t hi;
    };

    struct combo xchg(_Atomic(struct combo) *atom, struct combo value)
    {
        return atomic_exchange(atom, value);
    }

...causes the compiler to generate the same code as if it operated on
uint32_t.
gcc and clang for x86 inline this code, and this is explicitly allowed by
the documentation, with some additional remarks.
It appears to me that the documentation speaks of code generation. We could
have emitted a call, and this also would have been OK.


I think at this point we have managed to talk past each other.  You do 
seem to agree that the size specific __atomic_X_N "functions" are an 
implementation detail, and hence how and if they are implemented in TCC 
doesn't matter (much).  In the broader sense you agree that how exactly 
the secret sauce of atomics is implemented doesn't matter.


So, what's left to decide is how to deal with generic functions, here the 
 ones that can accept and return rvalues of arbitrary 
(including struct) type, ideally in a way that doesn't add much code to 
TCC.


grischka proposed a compact way involving no compiler changes at all, and 
I basically tried to find out why you didn't want to go that route, given 
that this would be an implementation detail.


(FWIW, in the full glory the generic implementation of e.g. atomic_load 
would need statement expressions, a special typeof and a temporary:


#define atomic_load(p) ({T(*p) r; __atomic_load_impl(p, , sizeof(r)); r; })

where T(*p) is basically __typeof__(*p) but removes _Atomic, that could 
be another extension, or further games with _Generic. )


Now, given that the above hackery would enable the features without any 
TCC compiler help it's reasonable to ask what kind of compiler changes are 
required to make the hackery a bit nicer, without having to implement 
everything in it.


Maybe it also turns out that your current approach is in fact the nicest 
one (it certainly generates better code than the above).  But there's 
certainly duplication between parse_atomic and the function call parser. 
So maybe another way that could be rectified is by adding an extension to 
TCC that would allow to declare the generic functions directly, ala:


  _Generic atomic_load(const volatile _Atomic _Generic *p);

with the following semantic: _Generic is a valid (unqualified?) base type, 
and when used in function decls there must be at least one argument with 
it, and all mentions need to refer to the same type at calls.  This would 
also allow to implement the type generic math functions nicely 
(). (I'm using the same keyword as for the generic selection, 
possibly that's a bad idea :) ).  You would also have to extend the 
function call parser somewhat (and of course the type parser and matcher), 
but it would be a general change that wouldn't need amendements in the 
compiler whenever a new generic function is added to some new standard.
That still leaves the question how to make the connection between this 
decl and which functions are ultimately called (and how), and maybe that 
deserves hardcoding in the compiler for now to be done in the same way as 
the above macro hackery would do by hand.  Not really thought through 
completely, but merely meant as idea trigger.



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

Re: [Tinycc-devel] [PATCH] stdatomic: ld/st/xchg/cmpxchg on simple types

[Michael Matz]

Hello,

On Mon, 22 Mar 2021, Dmitry Selyutin wrote:


Is the above atomic_load supposed to be similar to the GCC __atomic_load
intrinsic?

No, it's supposed to be similar to __atomic_load_N.


I see.  Those return integer types and hence aren't convertible to struct 
types either (not even with a cast).  This doesn't (and shouldn't) 
compile:


% cat x.c
struct S { short a, b; };
struct S load(struct S *mem)
{
  struct S s;
  s = __atomic_load_4(mem, __ATOMIC_SEQ_CST);
  return s;
}
% gcc -c x.c
x.c: In function ‘load’:
x.c:5:7: error: incompatible types when assigning to type ‘struct S’ from 
type ‘unsigned int’



hence structs aren't passed around

It depends on the calling convention.


No, it depends on which types the atomic builtins are defined to support. 
I'm aware that functions that do happen to pass around (or return) structs 
by value can use registers for this.  But the atomic functions don't do 
that.  Are you perhaps talking about the case where the compiler rewrites 
a generic __atomic_load into a size-specific one, ala:


  __atomic_load(mem, , __ATOMIC_SEQ_CST);

into

  __atomic_load_4(mem, __ATOMIC_SEQ_CST);

So, are you wanting to do the same for TCC as well?  The easier way would 
rather be to simply not do such rewriting and just keep calling the 
generic __atomic_load.


So, again, please provide some example code that shows what you want to be 
compilable (and perhaps also in which way).



For the __atomic_##_N, it seems like we can pass things this way, as
long as pointers are naturally-aligned.
As I mentioned in one of the earlier patches, there's no proper align
check yet, for now we have size check.



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

Re: [Tinycc-devel] [PATCH] stdatomic: ld/st/xchg/cmpxchg on simple types

[Michael Matz]

Hello,

On Fri, 19 Mar 2021, Dmitry Selyutin wrote:


Some complex types can still be small and simple enough to fit into
register. Other compilers allow some operations on these types, and it
seems to be quite a reasonable choice. From now on, we should be able
to compile the following artificial example:

   struct combo {
   uint16_t lo;
   uint16_t hi;
   };

   struct combo load(const _Atomic(struct combo) *atom)
   {
   return atomic_load(atom);
   }


Is the above atomic_load supposed to be similar to the GCC __atomic_load 
intrinsic?  If so, then it doesn't return a value.  It rather takes a 
pointer to the return value, hence structs aren't passed around, pointers 
are, and as such don't need special calling convention massaging.  I.e. 
it's declared similar to this:


void __atomic_load (size_t size, void *mem, void *return, int model);

Even when you encode the size directly and hence have a return type it's 
uintN, and hence not convertible to a struct type:


  struct combo c;
  c = __atomic_load_4(atom, __ATOMIC_SEQ_CST);

doesn't compile (and it shouldn't).


   void store(_Atomic(struct combo) *atom, struct combo value)
   {
   atomic_store(atom, value);
   }


Same for atomic_store and the rest: it doesn't take 'value' by value but 
by reference.


So, what exactly are you trying to implement?  Please make a full 
compilable (with GCC) example.




Ciao,
Michael.

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

Re: [Tinycc-devel] [PATCH] stdatomic: ld/st/xchg/cmpxchg on simple types

[Michael Matz]

Hello,

On Mon, 22 Mar 2021, Dmitry Selyutin wrote:


> Dispatching to per-type functions (instead of per-size ones) is mere busy
work
Having a function per each supported size plus one for emulated locking is
still safer than having a pair, where one deals with opaque data type.

> all that code is generated and implementation specific, not user
visible
It is visible.
https://llvm.org/docs/Atomics.html ("libcalls" section)
https://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary ("The library interface"
section)


Yes, sure, that's the GCC (with LLVM following) implementation of runtime 
library.  There is value in providing those as well, from TCCs side, I 
agree.


But there's also value in not implementing facilities twice.

Are your stdatomic patches all on mob meanwhile?


Ciao,
Michael.

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

Re: [Tinycc-devel] [PATCH] stdatomic: ld/st/xchg/cmpxchg on simple types

[Michael Matz]

Hello,

On Sat, 20 Mar 2021, Dmitry Selyutin wrote:


This needs casts, both sign- and type-wise, e.g. signed long long to
unsigned char, and has no way to enforce type safety, even in the minimal
form. A minimally suitable form would require a statement expression, plus
typeof, and even then it would have to be tuned to work with types that are
binary compatible (at least casts are needed). I don't see that many
benefits there. This is a deceptive simplicity which doesn't buy you much
after all. Per-type functions, on the other hand, are known to be generated
by other compilers, so you can be compatible with the code they produce,
whilst keeping other pros, like type deduction and using zero non-portable
extensions.


Within the implementation of compiler provided facilities itself we can 
make use of any non-portable extensions we like.


Type safety already goes out the window with type generic functions.
Dispatching to per-type functions (instead of per-size ones) is mere busy 
work; all that code is generated and implementation specific, not user 
visible.



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

Re: [Tinycc-devel] macOS Big Sur M1 port status

[Michael Matz]

Hello,

On Wed, 24 Feb 2021, Christian JULLIEN wrote:


libSystem.dylib no longer exists as a file on file system,
see https://github.com/pyinstaller/pyinstaller/issues/5107


Aha, I see, so they really moved it to only be contained in the shared lib 
cache :-/


Okay, so something with dlopen and dlsym might be possible.  But not 
having access to the symbol table directly is quite cumbersome.  We'll 
have to load all (system) libraries with dlopen into tcc itself, just so 
that we can check if they provide symbols required from the program. 
Gah.  Apple!  ;-/



Ciao,
Michael.







  Le : 24 février 2021 à 18:24 (GMT +01:00)
  De : "Michael Matz" 
  À : "jull...@eligis.com" ,
  "tinycc-devel@nongnu.org" 
  Objet : Re: [Tinycc-devel] macOS Big Sur M1 port status


  Hello,

  On Mon, 22 Feb 2021, Christian Jullien wrote:

  > I started to adapt mob to compile tcc natively on M1 (which is
  a damn
  > cool and fast CPU, really).
  >
  > With my few latest changes already pushed on mod, I’m able to
  build tcc
  > and its libs.
  >
  > I’m facing an important issue with Big Sur, libc.dylib (or
  libc.a) no
  > longer exist as file on disk!
  >
  > After googling a lot, I’ve found it exists “magically” for
  dlopen.
  >
  > dlopen(“libc.dylib”, RTLD_NOW) => ok
  >
  > With few simple (uncommitted) changes I have been able to let
  tcc succeed
  > searching for libc (using dlopen instead of fopen) but it
  finally failed at
  > macho_load_dll which reads from opened fd.
  >
  > I’m don’t know how macho_load_dll could use dlopen instead of
  read.
  >
  > For those wo. macOS, I think you can do the same on linux
  using dlopen.
  >
  > I’m afraid, with my limited knowledge, I can’t go further on
  this port.

  dlopen is not the answer, it's not the right interface for what
  TCC needs
  doing. (it's basically the difference between -run mode (dlopen)
  and
  compile-to-file mode ((f)read)).

  The file that is necessary surely is somewhere. But it's
  possbile that
  Apple got rid of the libc name and only retained libSystem
  (which already
  exists on x86-64 MacOS and libc is basically just a symlink).

  When I find time and motivation I'll have a look, as someone I
  know also
  bought a new macbook.


  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] zero length last member

[Michael Matz]

Hello,

On Wed, 24 Feb 2021, Yakov wrote:


Thanks for checking. I just tried again and I found that it only
crashes with `-run`. Actually I had `-run` misbehaving many times.
Just today strcpy() was SIGSEGV i.e.:.

int main() {
   char *c = malloc(6);
   strcpy(c, "hello");
}


That still leaves out much information.  architecture and tcc version (or 
commit you used to compile tcc).  Note that the above is a non-conforming 
program, you need a matching declaration of malloc and strcpy, so you need 
to include  and .  Missing them at least malloc is 
assomed to return an 'int' which might have unintended consequences when 
assigned to the char pointer 'c'.



Ciao,
Michael.



вт, 23 февр. 2021 г. в 12:50, Elijah Stone :


Are you running the latest version?  What architecture are you on?  Your
code compiles and runs without issue on my machine (amd64 linux, latest
git).

On Tue, 23 Feb 2021, Yakov wrote:

> https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
>
> I have tried the last zero length member extension in tcc and
> compilation succeeded but the program crashes, is this a bug or a
> different implementation? Btw if you do not know this is a super
> useful extension.
>
> typedef struct {
>int size;
>int data[];
> } T;
>
> void main(){
>T *t = malloc(500);
>t->size = 2;
>t->data[0] = 100;
>t->data[1] = 200;
>printf("%i %i %i\n", t->size, t->data[0], t->data[1]);
> }
>
> ___
> 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] macOS Big Sur M1 port status

[Michael Matz]

Hello,

On Mon, 22 Feb 2021, Christian Jullien wrote:

I started to adapt mob to compile tcc natively on M1 (which is a damn 
cool and fast CPU, really).


With my few latest changes already pushed on mod, I’m able to build tcc 
and its libs.


I’m facing an important issue with Big Sur, libc.dylib (or libc.a) no 
longer exist as file on disk!


After googling a lot, I’ve found it exists “magically” for dlopen.

dlopen(“libc.dylib”, RTLD_NOW) => ok

With few simple (uncommitted) changes I have been able to let tcc succeed
searching for libc (using dlopen instead of fopen) but it finally failed at
macho_load_dll which reads from opened fd.

I’m don’t know how macho_load_dll could use dlopen instead of read.

For those wo. macOS, I think you can do the same on linux using dlopen.

I’m afraid, with my limited knowledge, I can’t go further on this port.


dlopen is not the answer, it's not the right interface for what TCC needs 
doing.  (it's basically the difference between -run mode (dlopen) and 
compile-to-file mode ((f)read)).


The file that is necessary surely is somewhere.  But it's possbile that 
Apple got rid of the libc name and only retained libSystem (which already 
exists on x86-64 MacOS and libc is basically just a symlink).


When I find time and motivation I'll have a look, as someone I know also 
bought a new macbook.



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

Re: [Tinycc-devel] core dump with flex arrays

[Michael Matz]

Hello,

On Mon, 15 Feb 2021, Elijah Stone wrote:


On Tue, 16 Feb 2021, Michael Matz wrote:


 (Note that TCC and GCC behave different with non-top-level flex array
 members: GCC accepts but discards initializers of these with a warning,
 TCC rejects them.  That's fine, flex array members are an extension.)


Flexible array members are standard as of c99.


Sorry, imprecise language on my part.  Flex array members are c99, but a 
struct containing one may not be nested in another struct.  Accepting 
_that_ is the extension of GCC that TCC rejects.



Ciao,
Michael.

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

Re: [Tinycc-devel] [PATCH 0/4] stdatomic: code generators

[Michael Matz]

Hello again,

On Tue, 16 Feb 2021, Michael Matz wrote:


On Sun, 14 Feb 2021, Dmitry Selyutin wrote:


 The first patch introduces a set of routines which any platform which
 wants to support atomics must implement. I don't quite like that
 there's a lot of code duplication, but I haven't come up with a good
 idea on how to avoid it (I've been thinking of some trick with weak
 functions, though). I'm also not sure of ST_STATIC specifier; any tips
 regarding its usage are highly appreciated. I added it as I saw it's
 used in the code around; perhaps this is not required, so I can make
 the routines weak by default?

 The second patch adjusts tokenizer and generator appropriately, and
 also fixes some minor issues. From now on, the count of tokens matches
 count of atomic routines, and calls platform-specific code instead of
 calling usual functions. I'd like to keep this approach in order to
 make the code a bit more flexible. This is not for speed but, rather,
 for being able to tune per-platform code in the future. I'm totally
 open for the discussion.

 The third patch extends x86_64 code generator to generate code from
 the binary buffers, not byte-by-byte, as with g() routine. This
 functionality will be used in the ultimate patch, if it gets accepted.

 The last patch is the implementation for x86_64. This patch is likely
 a controversial one. I tried to make the code somewhat generic to
 different argument sizes, at the same time making it look like a
 function call. It's also caused by the fact that I checked the code
 generated by gcc for cases when usual stdatomic routines are wrapped
 into simple routines. I'm pretty sure a lot there can be improved;
 perhaps many of you will find the approach to be unorthodox to some
 degree. This is just the idea; I'm totally open for discussion.


So, I think you want to iterate a bit on this to find some tiny ways :)

Some ideas:

* For the unimplemented targets: e.g. introduce a define that a target
  sets, define erroring fallbacks (or empty macros or suchlike) if the
  macro isn't set (see e.g. CONFIG_TCC_ASM in tccgen.c).
* commonize the routines: there is no reason why you need four routines
  for four basic arithmetic operations, if gen_op() supports all
  arithmetic operations.  I.e. make it an argument to a single routine.
* The atomic routines itself: like others I suggest doing normal calls to
 library routines.  TCC is _not_ about fastest code.
* For the routines you do want to inline, the use of opcode bytes: nah,
  that can be done in a nicer way.  Think about the very core that you
  need: you will find it's the locked cmpxchg loop and the xchg insn
  itself.  Both have the property that they are very similar to stores
  (including the fact that they have a size),
  they just happen to leave something interesting in the register operand.
  I.e. it would be natural to just extend the 'store' routine to be able
  to emit (lock cmp)xchg instead of the store opcode.

  That will give you the possiblity to accept arbitrary registers instead
  of having to hard-code ax/si/di, obviating the need for the
  prologue/epilogue routines.

  For that you also probably want to use the existing helpers orex and
  gen_modrm(64) from x86_64-gen.c .  After some fiddling you will probably
  find that _not_ hardcoding specific registers is actually going to be
  easier.

* In a similar vain: your atomic load/store routines: these are simply
  load/store themself again.


Drats, I forgot the last remark I wanted to make: don't forget that TCC 
supports inline asm.  So another alternative would be to define all the 
routines/builtins you want as macros expanding to appropriate inline asm. 
That would enable not hardcoding registers, _and_ would be maintainable 
instead of raw opcode bytes.



Ciao,
Michael.

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

Re: [Tinycc-devel] [PATCH 0/4] stdatomic: code generators

[Michael Matz]

Hello,

On Sun, 14 Feb 2021, Dmitry Selyutin wrote:


The first patch introduces a set of routines which any platform which
wants to support atomics must implement. I don't quite like that
there's a lot of code duplication, but I haven't come up with a good
idea on how to avoid it (I've been thinking of some trick with weak
functions, though). I'm also not sure of ST_STATIC specifier; any tips
regarding its usage are highly appreciated. I added it as I saw it's
used in the code around; perhaps this is not required, so I can make
the routines weak by default?

The second patch adjusts tokenizer and generator appropriately, and
also fixes some minor issues. From now on, the count of tokens matches
count of atomic routines, and calls platform-specific code instead of
calling usual functions. I'd like to keep this approach in order to
make the code a bit more flexible. This is not for speed but, rather,
for being able to tune per-platform code in the future. I'm totally
open for the discussion.

The third patch extends x86_64 code generator to generate code from
the binary buffers, not byte-by-byte, as with g() routine. This
functionality will be used in the ultimate patch, if it gets accepted.

The last patch is the implementation for x86_64. This patch is likely
a controversial one. I tried to make the code somewhat generic to
different argument sizes, at the same time making it look like a
function call. It's also caused by the fact that I checked the code
generated by gcc for cases when usual stdatomic routines are wrapped
into simple routines. I'm pretty sure a lot there can be improved;
perhaps many of you will find the approach to be unorthodox to some
degree. This is just the idea; I'm totally open for discussion.


So, I think you want to iterate a bit on this to find some tiny ways :)

Some ideas:

* For the unimplemented targets: e.g. introduce a define that a target
  sets, define erroring fallbacks (or empty macros or suchlike) if the
  macro isn't set (see e.g. CONFIG_TCC_ASM in tccgen.c).
* commonize the routines: there is no reason why you need four routines
  for four basic arithmetic operations, if gen_op() supports all
  arithmetic operations.  I.e. make it an argument to a single routine.
* The atomic routines itself: like others I suggest doing normal calls to
  library routines.  TCC is _not_ about fastest code.
* For the routines you do want to inline, the use of opcode bytes: nah,
  that can be done in a nicer way.  Think about the very core that you
  need: you will find it's the locked cmpxchg loop and the xchg insn
  itself.  Both have the property that they are very similar to stores
  (including the fact that they have a size),
  they just happen to leave something interesting in the register operand.
  I.e. it would be natural to just extend the 'store' routine to be able
  to emit (lock cmp)xchg instead of the store opcode.

  That will give you the possiblity to accept arbitrary registers instead
  of having to hard-code ax/si/di, obviating the need for the
  prologue/epilogue routines.

  For that you also probably want to use the existing helpers orex and
  gen_modrm(64) from x86_64-gen.c .  After some fiddling you will probably
  find that _not_ hardcoding specific registers is actually going to be
  easier.

* In a similar vain: your atomic load/store routines: these are simply
  load/store themself again.

I think it would be good to have a testcase showing the atomic support in 
the works as well.


I hope that wasn't too severe :-)


Ciao,
Michael.

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

Re: [Tinycc-devel] core dump with flex arrays

[Michael Matz]

Hello,

On Mon, 15 Feb 2021, Herman ten Brugge via Tinycc-devel wrote:


I ran the tests/gcctestsuite.sh script and found one test that dumps core.
($GCC_DIR/gcc/testsuite/gcc.c-torture/compile/pr28865.c)

The reduced testcase is:

struct A { int a; char b[]; };
struct A a = { 1, "1" };
struct B { struct A a; };
struct B b = { { 1, "1" } };

line 2 works and line 4 dumps core.

I am not sure how to fix this.


Fixed in mob.  The cause is the discrepancy in handling string vs. normal 
array initializers.  The former wasn't checking for the problematic 
situation.


(Note that TCC and GCC behave different with non-top-level flex array 
members: GCC accepts but discards initializers of these with a warning, 
TCC rejects them.  That's fine, flex array members are an extension.)



Ciao,
Michael.

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

Re: [Tinycc-devel] Code generator (x86_64-tccgen): help required

[Michael Matz]

Hello Dmitry,

On Sat, 13 Feb 2021, Dmitry Selyutin wrote:


I work on support for std atomics and currently attempt to switch from
the initial idea of calling the routines to inlining the assembly
code. Unfortunately I'm lost in the relationships between the code
generator and SValue stack.


Which inline code do you have in mind?  I'm asking because as TCC isn't 
really about generating speedy code we can at least try to make it not 
larger than necessary.  So, if inlined code is actually larger than the 
argument setup and call instruction it might really be the better idea to 
not inline.  Having said this, to get you forward with the experiment:


Let's say I have a pair of values stored in SValue stack, and want to 
load them into the registers %rdi and %rsi, and exactly these. This, I 
presume, means that, unlike for situation with function call, I have to 
save the registers.


Actually it's quite similar to function arg setup.  (Probably not so 
incidentally %rdi and %rsi are exactly the first two argument registers in 
the ELF psABI).  The routine to load an SValue into a specific register is 
'load'.  So, you have two values in vtop[0] and vtop[-1] and need 
to load them into %rdi and %rsi, you would do roughly like this:


save_reg(TREG_RDI);  // first make sure rdi/rsi aren't used in the vstack
save_reg(TREG_RSI);
load(TREG_RDI, vtop);  // force vtop into rdi
vtop->r = TREG_RDI;// and record the fact that it's now in rdi
vswap();   // vtop is now the other value
load(TREG_RSI, vtop);  // do same with rsi
vtop->r = TREG_RSI;

Now vtop[0] sits in rsi and vtop[-1] in rdi, the generated code reflects 
this and the vstack state reflects this.  Now you generate your inline 
code that assumes stuff is in rdi/rsi and leaves result in rax:


  emit_your_code();

And now you want to make it so that the vstack reflects the fact that some 
value sits in rax.  First remove the top two entries, then generate a new 
one:


  vpop();  // remove the old two inputs in rdi/rsi
  vpop();
  vset(type, TREG_RAX, 0); // make vtop represent %rax in given type

There are various variants of the above theme.  If the value in rax 
represents an int, then this might be easier:


  vpushi(0);
  vtop->r = TREG_RAX;  // vtop is now %eax (i.e. as VT_INT)

If it's a pointer-sized value:
  vpushd(0);
  vtop->r = TREG_RAX;  // vtop is now %rax as VT_SIZE_T aka VT_LLONG

Also, when exactly you vpop() the two input values depends a bit on how 
you generate code in emit_your_code().  (Basically you want to pop them 
from the vstack as soon as the values are consumed, but not earlier)


Generally I would advise against using direct emission of opcodes via g() 
for the above argument setup (no matter that it's used in the call-arg 
setup right now), and rather use more generic routines like save_reg and 
load, like above.  (With that you can be relatively sure that you don't 
mess up other values that might still be live).


Of course, for special code you need in your inline code, you use direct 
opcodes via g() and friends.  But for some of the things you need you can 
probably also use the normal tcc codegen via the vstack for values and 
gen_op to generate operations on them.


You might even consider writing your special code as macros in tccdefs.h 
which you then simply feed into the parser and codegen as if the user had 
written normal C code (see e.g. what we do for the stdarg code).  The less 
special machine specific code the better.  (E.g. your atomic code should 
ideally work for other architectures, with possibly a very small 
arch-specific core; doing that is harder when you start fiddling with 
emitting opcodes directly).


Hope this helps.  Good luck.


Ciao,
Michael.

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

Re: [Tinycc-devel] Stack Exhaustion on TinyC "mob" Branch

[Michael Matz]

Hello,

On Sun, 7 Feb 2021, Zhuo Zhang wrote:


Hi,
I am writing to report a stack exhaustion on current TinyC ‘mob’ Branch, which 
is triggered when compiling a crafted program (named pop_stack.c and attacked).

+ How to trigger the bug:
simple run “./tcc poc_stack.c"

+ Detailed information
system:  Ubuntu 18.04.5 LTS, x86-64
compiler (to compile tcc): gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
commit: fbef90a7039b994907db34fde50f6fa5e46ab535
md5 of poc_stack.c: 909242f11e5ce660e1d843de92dd798a

Please let me known if there is anything I can help with. Thanks!


Fixed in mob; this was also a real bug.


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

Re: [Tinycc-devel] [PATCH v2] arm-asm: Add vcvt

[Michael Matz]

Hello Danny,

On Sat, 13 Feb 2021, Danny Milosavljevic wrote:

as of commit 24c94fff09ea21f2e70b575256824e4648124aad on tinycc mob, 
arm-asm is finished.  I've added all that one could reasonably want in 
lowest-common-denominator ARM assembly.


That's quite cool!

(For one-ARM-cpu-model-in-the-world-can-do-it speciality stuff one can 
always use '#define SPECIALINSTRUCTION ".int 0xopcode"')


Now, ARMv8, ehh?  ;-)


Thank you all for your help.


And thank you for putting in the work, the code looks fairly nice.


Ciao,
Michael.

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

Re: [Tinycc-devel] AddressSanitizer: heap-buffer-overflow

[Michael Matz]

Hello,

On Thu, 11 Feb 2021, Zhuo Zhang wrote:


A heap-buffer overflow occurs in commit
fbef90a7039b994907db34fde50f6fa5e46ab535 (ASAN on).

System info: ubuntu 18.04, x86-64


$ cat poc.c
a() {
  int b;
  asm("" : : ""(b == 0), ""(b));
}


Thanks for the report, it showed a real bug.  Fixed in mob.


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

Re: [Tinycc-devel] Assertion Failed

[Michael Matz]

Hello,

On Thu, 11 Feb 2021, Zhuo Zhang wrote:


I find there is an assertion failure in current tcc code.


$ cat poc.c
int a = b(c() * 1e678);

$ ./tcc -c poc.c
test.c:1: warning: implicit declaration of function 'b'
test.c:1: warning: implicit declaration of function 'c'
tcc: x86_64-gen.c:530: load: Assertion `(v >= TREG_XMM0) && (v <= TREG_XMM7)' 
failed.
[1]6773 abort (core dumped)  /root/git/test_tinycc/tcc -c test.c


The abort is fine.  We could replace it with a different error message, 
but it would remain an error; the input simply is fuzzed nonsense.


Note for future fuzzing: a core dump due to an abort is actually a 
good sign, it's not similar to e.g. a core dump due to a segfault (hinting 
at random memory overwrites or suchlike, which could potentially be 
abused).  The abort due to an assert means that someone thought and 
explicitely tested for situations which shouldn't occur, exactly so that 
further problems downstream can't materialize.


So: assert --> fine, segfault --> potentially interesting.


Ciao,
Michael.

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

Re: [Tinycc-devel] AddressSanitizer: global-buffer-overflow

[Michael Matz]

Hello,

On Thu, 11 Feb 2021, Zhuo Zhang wrote:


A global-buffer overflow occurs in commit 
fbef90a7039b994907db34fde50f6fa5e46ab535 (ASAN on).

System info: ubuntu 18.04, x86-64

Without ASAN, tcc will encounter a segment fault due to this overflow.


Actually you won't get a segfault but an abort, due to an 
assert triggering.  That is fine.  Nevertheless it's nicer to not do 
out-of-bounds array accesses, so I've fixed that in mob.  Thanks for the 
report.



Ciao,
Michael.

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

Re: [Tinycc-devel] Regarding Long double Constant

[Michael Matz]

Hello,

On Thu, 11 Feb 2021, Ayush Varshney wrote:


[1] https://www.researchgate.net/publication/245578769_Fully_Countering_Tru
sting_Trust_through_Diverse_Double-Compiling

On Thu, Feb 11, 2021 at 9:27 AM Ayush Varshney 
wrote:
  Hi everyone,
Hope you all are doing well!!
I am new to the tinycc community.
I was working over Diverse Double-compiling technique [1]. And found
there is a bad optimization performed by tcc. The problem is called
Long double constant problem.

Long double constant problem is for storing the value of 0.0, tcc stores 
0.0 in memory as long double value but long double value in tcc takes 
only 10 bytes but the source code stores 0.0 value in 12 bytes.


Can you show this with a small example?  Because TCC, when allocating 
storage in data sections (which is where float constants are stored) zeros 
the memory.  (And the trivial example ala:


  long double ld;
  int foo(void) { return ld == 0.0; }

shows that indeed, .data contains only zeros. )

If you are talking about a different compiler than TCC having this problem 
(i.e. initializing only 10 of the 12 bytes), then _that_ needs to be fixed 
instead of putting such code in TCC.


Also, if TCC really has a problem in initializing some memory for 
reproducability it probably doesn't affect only long double, in which case 
fixing the root cause also will be better.


The extra two bytes creates variations in the output. The problem is 
solved using (f1-f1) instead of 0.0, it is semantically same and 
produces the same output. For example, Instead of ‘if(f2==0.0)’ use 
‘if(f2==f1-f1)’


That's only a work around, for a compiler not initializing memory fully 
(and if it's TCC doing that, please show us where).  Your change in 
init_putv also doesn't compile.  Please don't push anything to mob that 
you haven't at least tested for that.  But even better would be to give us 
some more details.


Meanwhile I've reverted the change as it broke mob.


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

Re: [Tinycc-devel] Jupm Optimizations regession bug

[Michael Matz]

Hello,

On Tue, 2 Feb 2021, Kyryl Melekhin wrote:


Hello Grischka and Tcc community,

I have found a regression bug in Tcc code gen (X86_64).
Caused by this commit: 8227db3a23fd3cf11840eaa25eab5f3f5f813ac7


This may have triggered the problem, but I think only by chance.  The bug 
is really in the VLA save/restore tracking.  I've fixed it in 
https://repo.or.cz/tinycc.git/commitdiff/fbef90a7039 .



Sadly I don't have a small test case to reproduce it.


See the testcase I've added in above commit.  It shows the problematic 
situation, mimicing the one in your vi.c (nice thing, that :) ).


Many thanks for the report.


Ciao,
Michael.

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

Re: [Tinycc-devel] Scoping fix

[Michael Matz]

Hello,

On Thu, 21 Jan 2021, Elijah Stone wrote:


 You can't declare a struct in the declaration part of the for stmt
 (6.8.5p3), only objects of auto and register class.


Hmmm.  I think the spec is somewhat ambiguous here.
The specific wording is:


 The declaration part of a for statement shall only declare identifiers for
 objects having storage class auto or register


Does that mean that:

1. all objects which have identifiers declared for them must have
   storage class auto or register

2. all identifiers which are declared must be for objects, and those
   objects must have storage class auto or register


Yep, I stumbled over the same ambiguity here, but as clang and gcc behaved 
consistently and interpretation 2 is reasonable (I didn't think to check 
msvc or icc^Wedg) I thought tcc should follow suit.  Now, with your 
experiments on other compilers the picture is different, but I'd still 
like to have the testcases in tests2 to be compilable with GCC.  In the 
extreme it would be okay to compile f2 and f4 only for TCC (with a comment 
about this discussion), but perhaps there's a different way to test the 
same scoping rules without having to deal with the interpretation of 
6.8.5p3, e.g. for f2:


int
f2_1 (void)
{
struct foo { int m; };
int i;
for (i = sizeof(struct foo {int m;});;)
return sizeof(struct foo { int m; });
}

Another expression of the inconsistency, which I think makes it even clearer: 
under this interpretation, the first two of the following forms are allowed 
but the third is not:


// 1, ok
int i; for (i = sizeof(struct foo { int m; });;)

// 2, ok
int i = sizeof(struct foo { int m; });

// 3, not ok; why not?
for (int i = sizeof(struct foo { int m; });;)


Yeah, there's no conceivable reason why (3) should not be allowed.  Often 
some of the stranger rules in the standard are to cater for very simple 
(one-pass) parsers, but as tcc plus your patch proves in this case that's 
not necessary.


I suspect that no one ever intended for it to be possible to declare an 
identifier inside of an expression, and now we're dealing with the 
fallout.


Yeah, the wonders and fun of fine-print language lawyering :-)

I don't know if there's a _good_ solution, but I think that the 
most consistent option is to allow struct declarations there.


FWIW, I agree with you.  In fact I don't even see the necessity to have 
_any_ restriction at all for the decl-form of 'for', it's just not 
explainable why 'for (decl;;)' shouldn't be 100% equivalent to

 'decl; for(;;)' So the decl part could be a typedef, so what?.

I've written a short paper on the topic outlining the problem and a few 
potential solutions for future versions of the spec; would appreciate any 
feedback: https://elronnd.net/sl.pdf


Ah, nice.  So I'd argue for your proposal 3.

While I agree that in the abstract your proposal 4 (don't leak decls from 
expressions) is the best I think it sufficiently changes the language that 
it wouldn't be acceptable anymore for something as mature as C (and would 
need either of the first three proposals anyway).



Ciao,
Michael.

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

Re: [Tinycc-devel] Scoping fix

[Michael Matz]

Hello,

On Thu, 21 Jan 2021, Elijah Stone wrote:

Patch is attached to fix tcc scoping behaviour.  Test should be 
self-explanatory.  (Citation: c11 §6.8.4p3 and §6.8.5p5.)


Nearly, but your testcase isn't completely C99/C11.  It's not related 
to the scoping issue you fixed, but to a side constraint for the 'for' 
statement:


...
for (struct foo { int m; } x;;)
...

(both in f2 and f4)

You can't declare a struct in the declaration part of the for stmt 
(6.8.5p3), only objects of auto and register class.


Testcases we add for conformance should be conforming themself :)

Apart from that: thank you!  (I have the feeling the added number of lines 
could be reduced by some factoring, but that can always be done later)



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

Re: [Tinycc-devel] enforced immutability - proposed research project

[Michael Matz]

Hello,

On Tue, 19 Jan 2021, Steffen Nurpmeso wrote:


Bruno Haible wrote in
<2278523.dGrNHthDRc@omega>:
|Michael Matz wrote:
...
|> Okay, that's quite limited, and very easy to implement: disallow casting 
|> away immutability and you're done.  But in this limited form you then 
|> can't infer anything useful from this, in particular you can't infer \
|> that 
|> the (immutably) pointed to object is unmodified when you allow mutable 
|> references to exist to it at the same time.

|
|Correct. The way I see it is:
|  - Code that got hold of a writable pointer (wp) may do modifications to
|the object, as long as it wants.
|  - Code that got hold of a read-only pointer (p) should crash when it
|attemps a modification through this pointer. Either the crash happens
|when casting 'const struct data *' to 'struct data *', or it happens

memchr(3) would stop working.


memchr doesn't write, it would work just fine.  (You can't write into the 
returned pointer, of course, at least not without mapping it back to a 
writable variant).  But it's immaterial even if it wouldn't work: the 
proposal is contemplating a language extension, which might or might not 
be compatible with const qualifications.  That might (or might not) 
require appropriate variants of standard functions.


|Very often the application lets all writable pointers to the object go 
|out-of-scope early, such that only read-only pointers to the object \ 
|survive. Then you have a true immutable object in the proper sense of 
|the word.


Shadow regions make this a 64-bit only thing then, i presume.


Nope, it works with 32bit just fine, it merely needs a MMU.  Of course you 
reduce the available address space, which matters more on 32bit, but many 
programs don't need 1GB of address space in regular operation.



Ciao,
Michael.

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

Re: [Tinycc-devel] enforced immutability - proposed research project

[Michael Matz]

Hello,

On Mon, 18 Jan 2021, Bruno Haible wrote:


Michael Matz wrote:

... you also need to invalidate all _copies_ of wp:

   wp = malloc(); init(wp);
   p = freeze(wp);
   globalp->foo = ...;  // should be disallowed

where init(wp) is something like:

struct S *globalp;
void init(struct S *x) { x->foo = 1; globalp = x; }


This is a perfectly valid code, with no "bad" cast. I would say that
assigning to globalp->foo should be allowed.


I see, but see below for what this then means.


Many programs don't make copies of wp. The typical idiom is that the
function that allocates an object also fills it and selectively stores or
returns writable and read-only views to the object. Enforced immutability
should only verify that some code that received a read-only pointer does
not do a write access.


Okay, that's quite limited, and very easy to implement: disallow casting 
away immutability and you're done.  But in this limited form you then 
can't infer anything useful from this, in particular you can't infer that 
the (immutably) pointed to object is unmodified when you allow mutable 
references to exist to it at the same time.  Obviously I misunderstood 
your proposal, I thought you also wanted to defend against accidental (or 
malicious) modification of frozen objects.


Doing things at runtime also isn't super-easy: you either waste full 
pages for each allocation, no matter how small (in order to 
write-protect them at freeze), or you need to copy contents around (to 
write-controlled areas) invalidating addresses already pointing to it, 
or you need to do checked-writes for each memory write.


The cited implementation (immutable.h, immutable.c) does none of these.


Ahh, two shared mappings to the same thing.  Okay, I retract my claim and 
say: cute idea! :)  (sorry for not checking gnulib earlier)



Ciao,
Michael.

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

Re: [Tinycc-devel] enforced immutability - proposed research project

[Michael Matz]

Hello,

On Mon, 18 Jan 2021, Barath Aron via Tinycc-devel wrote:


Yes, this is how you would do it without proper type system (like C
has). I mean, if you want to add runtime stuff here, it is fine for me
(until it is optional :P -- I use tcc on an exotic hosted system, so it
is crucial for me [hmm, did I mentioned that tcc works only partially,
due to lack of PIE support?]


[The x86-64 code was mostly PIE already, and Herman fixed more things 
regarding that recently, so if it still doesn't work 100% it should be 
relatively easy to fix.  For the other targets Herman also fixed a couple 
things towards position independence, but for some architectures a 
performance price needs to be paid, so it should only be optional.]



). But in the example above, it is clearly,
you need to do something in your code to get this working. Another
aspect would be an extension to the C type system, which makes such
escapes impossible (like 'const'):

   immutable struct S *globalp;
   void init(immutable struct S *x) { x->foo = 1; globalp = x; }


*x can't be immutable within init(), otherwise it couldn't initialize 
x->foo.  Except if you say that 'init' is somehow special, like 
constructors in C++, and allow it to write through immutable references.



And make this property permanent, so no one can cast it away.


Forbidding to cast away immutability is easy.  The problem is at the side 
of creating immutability retroactively, and what to do with the mutable 
references that already exist.


I mean, I see two ways to do it. One will work only in certain hosted 
system, while the other will work with any hosted and freestanding 
environment. And it would be useful to examine both directions, 
especially for a research project. :)


True that.  For a real research project the type system route should 
definitely be included :)



Ciao,
Michael.

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

Re: [Tinycc-devel] enforced immutability - proposed research project

[Michael Matz]

Hello,

On Mon, 18 Jan 2021, Barath Aron via Tinycc-devel wrote:


Hello,

On Mon, 18 Jan 2021 12:32:29 +0100 Bruno Haible  wrote:

((struct data *) p)->x = 9; // Violation of immutability,
crashes ...


If you do not allow such cast, you don't have to do anything at runtime.


Depends what happens with the original wp in Brunos example.  To remind, 
the context was:


  wp = malloc(); wp->foo = ...;
  p = freeze(wp);

Now, if you only disallow to cast away immutability, then you still would 
be able to write to the object via *wp.  So, you either need to do 
something at runtime, or encode the fact that wp becomes invalid after 
freezing it.  That might sound easy, but you also need to invalidate all 
_copies_ of wp:


  wp = malloc(); init(wp);
  p = freeze(wp);
  globalp->foo = ...;  // should be disallowed

where init(wp) is something like:

   struct S *globalp;
   void init(struct S *x) { x->foo = 1; globalp = x; }

Doing things at runtime also isn't super-easy: you either waste full pages 
for each allocation, no matter how small (in order to write-protect them 
at freeze), or you need to copy contents around (to write-controlled 
areas) invalidating addresses already pointing to it, or you need to do 
checked-writes for each memory write.  The latter is basically what 
current bounds-checking in tcc already does, just with even more meta-data.


I think the latter would actually be the quickest route to success here: 
reuse the bounds-checking code.  You just need a way to register read-only 
regions (which is what freezing does), and then check that list of regions 
at each write.



Ciao,
Michael.


Also, freestanding mode would work that way too.
But for that, you need a more complex type system.

Aron

___
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] arm-asm: Test script

[Michael Matz]

Hello,

On Wed, 6 Jan 2021, Danny Milosavljevic wrote:


Hello,

On Wed, 6 Jan 2021 00:07:07 +0100 (CET)
Michael Matz  wrote:


Hmm, how can I get the name of the tcc executable to use for tests from
inside the shell script?  Do I just use ./tcc ?


Probably easiest to pass $(TCC) to the shell script as an argument I
guess.  It needs -B and -I flags to work correctly from uninstalled paths
and the Makefile sets that up correctly.


Does that mean I should use ${TCC} without quotes in the shell script?


No, it's currently not exported from make, so not available in the 
environment.  What I meant is something like this: extend the script to 
take an optional compiler-with-arguments argument, so that it can be 
called like:


% ./the-test-script.sh -c "../tcc -B.. -I.. -whatever-else"

and then use it with that argument in the makefile like so:

 snip 
mytarget: the-test-script.sh
./the-test-script.sh -c "$(TCC)"
 snap 


Do I need $(TCCFLAGS), too?


The Makevariable $(TCC) should contain everything that's needed.
Still, even the above might be overdesigning it a bit :)
(I see you also access the tcc-tok file directly, so that might further 
complicate things from the tests/ Makefile, so don't bother if that gets 
you into the rabbit hole too far)



Ciao,
Michael.

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

Re: [Tinycc-devel] x86_64 tcc doesn't set sign bit on NaNs

[Michael Matz]

Hello,

On Wed, 6 Jan 2021, ian wrote:


Hi to all, and happy new year.

AFAIK neither -NaN nor +NaN have sense (how to put a sign at a 'not a
number' ).


To be precise, the sense isn't specified.  Like for the payload of IEEE 
NaNs you can give it any meaning you like, including none.  But if you 
regard unary minus as a non-arithmetic but algebraic operation (like 
recommended by IEEE) on an extension of the float numbers, it should do 
something to the (algebraic) sign.



For instance, in my own language NaN have no sign, but on the other hand I
use -Inf and +Inf :


That's completely fine.


It seems to me that using a sign bit on NaN is a design error.


Possibly.  But it's the more orthogonal choice with IEEE float (where 
simply all specified values have a sign).



Ciao,
Michael.



Regards to all, and best wishes.

ian

Le 05/01/2021 à 10:27, Vincent Lefevre a écrit :

On 2021-01-04 04:59:28 +0100, Michael Matz wrote:

Hello,

On Mon, 4 Jan 2021, Vincent Lefevre wrote:

-
#include 
#include 
#include 

int main(int argc, char **argv)
{
double d = strtod("-nan", NULL);
d = -d;
printf("%g, signbit(d) = %d\n", d, signbit(d));
return 0;
}
-

Results:

$ gcc foo.c -o foo && ./foo
-nan, signbit(d) = 1

$ tcc foo.c -o foo2 && ./foo2
nan, signbit(d) = 0

I get the same results as gcc with clang and pcc. tcc is the outlier.

AFAIK, the status of the sign bit of a NaN is unspecified, except
for some particular functions, but not strtod. So I don't see a
bug in tcc.

Note: for GCC, there's an inconsistency between your testcase
and the result.

Yeah, I think that's merely a typo in Arnolds email.  The inconsistency is
there, applying unary '-' to a NaN doesn't change the sign of it in TCC.

But my point is that with the above testcase, you cannot know whether
the difference between gcc and tcc comes from strtod (which would be
valid, as strtod doesn't specify the sign or NaN) or the "d = -d;"
(which would be invalid). A printf should have been added between
the strtod and the "d = -d;" to be sure.

--
-- sibian0...@gmail.com
-- Développeur compulsif

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

Re: [Tinycc-devel] arm-asm: Test script

[Michael Matz]

Hello,

On Tue, 5 Jan 2021, Danny Milosavljevic wrote:


Hi,

On Mon, 4 Jan 2021 05:05:40 +0100 (CET)
Michael Matz  wrote:


Yeah, put it into tests/ I'd say.


Ok, I've added it as tests/arm-asm-testsuite.sh .


 The x86 assembler also has a little
testfile in there that isn't used by default (as it shows a few
differences between GNU as and tcc; and needs updates from time to time
to cater to stricter versions of GNU as).



Maybe you can wire it into the
existing asmtest target when $(ARCH) is arm.


Hmm, how can I get the name of the tcc executable to use for tests from 
inside the shell script?  Do I just use ./tcc ?


Probably easiest to pass $(TCC) to the shell script as an argument I 
guess.  It needs -B and -I flags to work correctly from uninstalled paths 
and the Makefile sets that up correctly.



Ciao,
Michael.

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

Re: [Tinycc-devel] recover commits on mob

[Michael Matz]

Hello,

On Tue, 5 Jan 2021, Danny Milosavljevic wrote:


On Tue, 5 Jan 2021 18:12:35 +
Ramsay Jones  wrote:


I just pushed a fix-up to the 'mob' branch to recover three
commits which had been 'overwritten' somehow. (Danny, did
you not see an error message when you tried to push?).


Thank you!

I've reconstructed what could have happened.

In the current tinycc-suggested workflow

 git push ssh://m...@repo.or.cz/srv/git/tinycc.git arm-asm:mob


Yeah, but you must have used -f somewhere.  Almost never a good idea when 
pushing to some remote :-)



Ciao,
Michael.

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

Re: [Tinycc-devel] [PATCH 1/3] arm-asm: Implement branch to label

[Michael Matz]

Hello,

On Tue, 5 Jan 2021, Danny Milosavljevic wrote:


Some tests which cannot be automatically generated:

1.

__asm__(".a:\n\t"
   "mov r0, #1\n\t"
   "bne .a");

2.

__asm__("mov r0, #1\n\t"
   "bne L0\n\t"
   "L0:\n\t");

3.

__asm__("mov r1, #2\n\t"
   ".L0:\n\t"
   "mov r0, #1\n\t"
   "bne .L0");

So maybe we should have a directory with manual assembly tests, probably 
at least one for arm and one for x86.


What do you think?


Don't overcomplicate :)  Make it one file and add it as tests/asm-arm.c 
(or .s or .S).



Ciao,
Michael.

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

Re: [Tinycc-devel] x86_64 tcc doesn't set sign bit on NaNs

[Michael Matz]

Hello,

On Mon, 4 Jan 2021, Christian Jullien wrote:


Also on OpenBSD x64 with clang 10


Bah.  I could fix this generically with using signbit(3) to check 
for the required sign flip, but I'm not sure how widespread it's 
availability or correctnes is on other platforms.  So Hermans disabling 
for clang works for me as well.



Ciao,
Michael.

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

Re: [Tinycc-devel] arm-asm: Test script

[Michael Matz]

Hello,

On Sun, 3 Jan 2021, Danny Milosavljevic wrote:


Updated test script for all of this (should I also commit this?  Where?):


Yeah, put it into tests/ I'd say.  The x86 assembler also has a little 
testfile in there that isn't used by default (as it shows a few 
differences between GNU as and tcc; and needs updates from time to time 
to cater to stricter versions of GNU as).  Maybe you can wire it into the 
existing asmtest target when $(ARCH) is arm.



Ciao,
Michael.

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

Re: [Tinycc-devel] x86_64 tcc doesn't set sign bit on NaNs

[Michael Matz]

Hello,

On Mon, 4 Jan 2021, Vincent Lefevre wrote:


-
#include 
#include 
#include 

int main(int argc, char **argv)
{
double d = strtod("-nan", NULL);
d = -d;
printf("%g, signbit(d) = %d\n", d, signbit(d));
return 0;
}
-

Results:

$ gcc foo.c -o foo && ./foo
-nan, signbit(d) = 1

$ tcc foo.c -o foo2 && ./foo2
nan, signbit(d) = 0

I get the same results as gcc with clang and pcc. tcc is the outlier.


AFAIK, the status of the sign bit of a NaN is unspecified, except
for some particular functions, but not strtod. So I don't see a
bug in tcc.

Note: for GCC, there's an inconsistency between your testcase
and the result.


Yeah, I think that's merely a typo in Arnolds email.  The inconsistency is 
there, applying unary '-' to a NaN doesn't change the sign of it in TCC.


While the interpretation of sign bits in NaNs isn't specified in 
IEEE754/854/P754, its existence is a given (in particular it talks about 
"the sign of a NaN", in order to say that their interpretation isn't 
determined :) )


Further IEEE754 recommends implementations to provide a negate(x) 
operation that copies x with reversed sign, that is to work on NaNs (and 
due to copysign needs to have observable behaviour).  C99 and up specify 
that the unary '-' operator maps to that operation.


So, I think it's pretty clear, that whatever the sign bit of NaNs is 
supposed to mean, it must be switchable by unary '-' when IEEE754 
conformance is claimed.  We currently don't claim so, but we aim for it if 
possible :)


So the current "-0.0-x" expansion of unary '-' needs a change.  It turned 
out to be a bit uglier than I wished for, but alas, fixed in mob.


Thanks for the report, Arnold.


Ciao,
Michael.

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

Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc

[Michael Matz]

Hello,

On Fri, 1 Jan 2021, Joshua Scholar wrote:


I noticed that in the win32 directory there are 46 include files in the main
include directory, 9 in include/sys, there's a secure api directory with 12
files, an a libtcc directory with an include file and a def file.. but the
include directory for the non-windows build only has 9 files, so I guess
it's relying on the system to have another C compiler installed whose .h
files it can use.


No, it means you have to have a C library installed (there are multiple). 
The compiler doesn't provide one.  If you come from Windows that might 
seem unusual, but the C standard explicitely has provisions for this, and 
it's the usual way of delivery on non-windows system.  You might have 
multiple compilers, all using the same C library, the latter being more 
tied to the system facilities than a compiler.  It does require some 
cooperation between C library and C compiler at the overlap, but it 
provides much better separation of concerns.


I haven't been here long, but it does sound like a bad idea to not 
include your own include files for every platform.


How could it be any different?  We don't provide a graphical GUI library, 
so we provide no headers for it.  We don't provide a C library either, so 
we don't provide those headers either.


The headers you see for Windows and its msvcrt library are a mere nicety: 
there's only one de-facto C library on Windows so providing headers for 
that one is fairly easy.  In addition there're also well-known other 
libraries provided on every windows system, so some headers (and .def) 
files for them are provided as well.  But that's more catering to 
expectations of Windows users than the usual way.



Does that mean you have to have GCC installed?


No.

It's awfully confident of them to be sure that every GCC include tree 
will work.


Not every GCC include tree, no.  But every C library include tree: yes, 
that is an expectation.  Within limits, but generally so: the C lib 
include headers are expected to make use of only standard C features (or 
use non-standard features only after checking for availability from the 
compiler at hand), and TCC is expected to conform to the standard.  Again, 
that's the ideal, not 100% reached, but it's the general direction.



Does Clang work?


With what?  With GCC include trees: no, with C lib includes: yes.  Clang 
is not different from TCC in this respect, or from GCC for that matter. 
It's just another compiler.  (Well, in fact clang implements most GCC 
extensions, so it is even fine with most GCC-specific headers; but 
that's a detail).


Is it a license issue?  If so, that's 
passing the license issue on to you.


No, it's not a license issue, it's a separation of concern issue.


Ciao,
Michael.



On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien  wrote:

  First, happy new year all.

   

  Porting tcc on *BSD systems raised issues/questions with
  stddef.h from tcc distrib.

   

  First, it contains a mix of definitions coming from both
  stddef.h and stdint.h IMHO it should only contain what stddef.h
  is supposed to contain.

  i.e. From C11:

   

  B.18 Common definitions 

  ptrdiff_t

  size_t

  max_align_t

  wchar_t

  NULL

  offsetof(type, member-designator)

  _ _STDC_WANT_LIB_EXT1_ _

  rsize_t

   

  Howerver it also contain many [u]intN_t type definitions which
  duplicate what is found on stdint.h

   

  The issues come when a valid program frist includes 
  then 

  It first finds [u]intN_t definitions in system
  [/usr/include/]stdint.h file which are duplicated/redefined in
  [tcc/include/]stddef.h from tcc.

  When definitions differ, tcc stops as some with *BSD systems and
  [u]int64_t definitions.

   

  Questions:

   

  Why tcc needs its own stddef.h instead of system one?

  Why tcc does not need stdint.h?

   

  I suppose it is because tcc does not support all gcc syntaxes
  found on stddef.h (is it still true?) in that case, it would be
  better to split definitions in stddef.h and stdint.h following
  the ISO C11 standard.

   

  Clarifications/fixes are welcome.

   

  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] issues/questions with stddef.h which comes with tcc

[Michael Matz]

Hello,

On Fri, 1 Jan 2021, Christian Jullien wrote:


First, happy new year all.


To you as well.


Porting tcc on *BSD systems raised issues/questions with stddef.h from tcc
distrib.

First, it contains a mix of definitions coming from both stddef.h and
stdint.h IMHO it should only contain what stddef.h is supposed to contain.


First some background.  TLDR: patches welcome :)

Standard headers are a bit complicated when considering the C library and 
the C compiler in isolation (which we need to do with TCC, as we provide 
only a compiler).  Both are part of a standard describing the whole 
implementation, of library and compiler.  But some header facilities can 
be usefully provided only with compiler knowledge.  There's the concept of 
free-standing implementations, that need to provide only a few headers 
( being one), and it's such that in those headers are the most 
compiler specifics.  So it's sensible to provide them with the compiler, 
not with the C library (and if only for the reason that if you don't even 
have a C library that you can use the free-standing part of the C 
standard).


You will notice that also GCC provides it's own .

 is a mixed bag; most of it's facilities can be nicely defined 
without many compiler specifics except very few crucial macros/builtins. 
So, many C libraries do in fact provide that header themself, but still in 
a way that there are compilers that don't work correctly with them.  E.g. 
GCC provides a  that uses the library one with a hosted 
implementation (the opposite of a free-standing one).


There's also an advantage for the C library providing these headers: they 
can in addition to the standard facilities also provide means that are 
specific to the library implementation (e.g. the whole _GNU_SOURCE 
business in the GNU C library).


So, for some headers there's a grey zone for decisions: should the 
compiler or the library provide a header.  For  it's easy: also 
other system compilers provide it, e.g. also because of the offsetof() 
macro that needs compiler support when you want to avoid non-portable 
implementations, so TCC should provide it.  For : here it's less 
clear: TCC doesn't claim to provide a free-standing implementation, so it 
doesn't _have_ to provide it, but could rely on the C library, which we do 
right now.


But of course you are right in that the TCC  should not provide 
anything that it isn't supposed to provide, as that can cause conflicts 
like you are seeing.


Several solutions:
a) make the non-standard extensions of TCC  be conditional on a
   macro (or a non-existence of a macro, like e.g. it could continue to
   provide them outside C89/C99/C11 conformance).
b) remove those additions completely
c) b + provide own 
d) b + leave it to the C library to provide 

The nicest solution would be (c) as that goes towards providing a 
free-standing implementation.  But the provided  needs to be 
compatible with anything the C libraries provide or rely on.  GCC has to 
jump through hoops with that (using include_next), that might be historic 
cruft, or it might still be for a reason, I don't know.  So without trying 
on a range of platforms I can't say if (c) is realistic or not.




Why tcc needs its own stddef.h instead of system one?


See above, the system one also is compiler specific.


Why tcc does not need stdint.h?


Because we got away with it :)  Patches welcome.

I suppose it is because tcc does not support all gcc syntaxes found on 
stddef.h (is it still true?) in that case, it would be better to split 
definitions in stddef.h and stdint.h following the ISO C11 standard.



Ciao,
Michael.

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

Re: [Tinycc-devel] [PATCH 00/16] Add ARM inline assembler

[Michael Matz]

Hello Danny,

On Sat, 26 Dec 2020, Danny Milosavljevic wrote:


This patchset adds an ARM inline assembler.


Wonderful!  I like the content and the form of presentation :)
Cool stuff.


Ciao,
Michael.

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

Re: [Tinycc-devel] What is your general workflow in answering to mailing list thread?

[Michael Matz]

Hello,

On Sat, 26 Dec 2020, Michael Matz wrote:


c) no top-posting [1], no full-quoting if answering to only some parts,


And obviously I could use an email client that asked me that, if I had 
used something like "[1]" to reference a foot note, and then not 
actually put in a foot note in the mail text, this was not just forgotten 
:)


So, maybe a next rule would be: e) read your text before sending :)

That foot note was supposed to be this:

[1]
This is why top posting is so bad (in top posting order):

 A: Because it messes up the order in which people normally read text.
 Q: Why is top-posting such a bad thing?
 A: Top-posting.
 Q: What is the most annoying thing in e-mail?


Ciao,
Michael.

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

Re: [Tinycc-devel] What is your general workflow in answering to mailing list thread?

[Michael Matz]

Hello,

On Fri, 25 Dec 2020, Vaidas BoQsc wrote:


What is the proper way to quote and reply in a Mailing List? Thanks.
I just noticed that instead of replying, I created a new thread.


Thank you for asking.  Generally the usual netiquette rules should be 
obeyed, but we don't need to be too obsessive about them as the size of 
this list is small.  Googling for mailing list netiquette will give you 
various answers, from relaxed to much too strict, but commonalities would 
be:


a) No HTML-only mails (of possible without HTML content, but multi-part
   with non-html is okayish)
b) readable with mono-space font
c) no top-posting [1], no full-quoting if answering to only some parts,
   quote with '> ' prefixed lines
d) 72 characters line width


As an average, I use in-browser Google Mail.
Do I need a Mail Client to have a better experience with Mailing Lists?  


Ugh, let's hope this doesn't transform into a flame-war of 
best-email-clients ;)


gmail is probably the best in-browser client, but still fairly bad as far 
as mail clients go; I'm not sure how much of the badness can be configured 
away.  I'm not a GUI user myself, so can't really suggest anything from 
own experience, but reasonable mails seem to be produced by Thunderbird 
users.  If the settings allow to send text-only mails and a mono-space 
font and do quoting in classic '> bla' style it's going to be fine.



Do you happen to do any manual message formatting work while replying?


(FWIW, I'm using alpine, and the only formatting I regularly use is to 
justify whole text paragraphs to the text width that they don't look too 
jiggly)



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

Re: [Tinycc-devel] tinycc manpage

[Michael Matz]

Hello,

On Fri, 25 Dec 2020, Sudipto Mallick wrote:


When I compiled a recent version of tinycc from mob, I looked at the
source of the manpage. I don't like it.


In which sense?  tcc.1 is a generated file, it's not supposed to be 
edited.  The source is tcc-doc.texi, i.e. texinfo, via texi2pod and 
pod2man.  So, are you sure you're barking at the right tree?


I learnt about the mdoc(7) format for writing man pages and thought to 
use that format for the tcc man page. The rewrite is attached.


While -mdoc certainly is nicer than -man it's both trumped (IMHO) by 
perlpod and texinfo, in writability.



What do you think about this mdoc formatted manual page?


I think it's nicer than the current generated tcc.1 file, and I think it's 
somewhat more purist to directly write mdoc files for a project like TCC, 
instead of generating them.  But I also think that something like this 
needs to be easy to write/edit, and in this case I'd argue that texinfo is 
just fine.


This is not yet complete (see TODOs). Please give suggestion to complete 
it.



Ciao,
Michael.

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

Re: [Tinycc-devel] Hello and a few questions about using libtcc

[Michael Matz]

Hello,

On Sun, 20 Dec 2020, Joshua Scholar wrote:


4) If I did something weird like have a call out from generated code to

my

code, and my code returned on the same stack but in the context of a
different thread than it entered from, would that break anything?


No.  Or, perhaps better said, it would break in the same way when the
generated code would also be your code and not generated by TCC, i.e. TCC
doesn't introduce additional restrictions.  In particular the usual
makecontext/swapcontext way of implementing lightweight threads via stack
switching should work just fine, as should any more unusual way of
switching threads but not stack (what is that even supposed to mean?), as
long as the input code doesn't have any problem if it had been written
literally without TCC involvement.

"switching threads but not stack (what is that even supposed to mean?)"


What it means is this, imagine that a scheduler outside the generated code
created a new stack, switched to it then called some generated code.
And at some point that generated code rather than returning to the
scheduler yielded by making a call into my own code which, instead of
returning, just saved the context/continuation somewhere and switched back
to its native stack.

Then later on, a scheduler running on a different thread with a different
thread local state, for instance, takes that stack and switches to it and
returns into the generated code, appearing to
return from the call, but in a different thread.


Yeah, so the classic makecontext stack switching/co-routines.  The above 
does switch stacks, which is why I was confused by your saying of not 
doing that.  Just mis-understanding.



Any code that used thread local memory might break.


Yeah, and no, TCC is not doing any of that; the code it generates uses 
exactly the features that the input code uses as if it were compiled by a 
normal ahead-of-time C compiler.  So if your to-be-compiled source 
snippets are free of effects breaking the above use case then the code 
generated by TCC is free of them as well.



I assume that tcc_compile_string is equivalent to tcc_add_file.  Does that
mean that you can add multiple strings to be compiled?  Does tcc copy them,
or does it compile them immediately and forget them, or do the original
buffers have to be retained?


The string buffer doesn't have to be retained.  TCC generates machine code 
into the appropriate buffers, binds them to the host programs (or other 
parts of such machine code also added by tcc_compile_string) and that's 
it.



Kyryl's answers brought up a bunch more questions for me.

For instance, he said "tcc_delete will free everything, if you call it 
before running generated code it will crash."


So I wonder,
1) when is the run time library loaded, when is it initialized and is it
ever freed or finalized?


Which run time library?  In a code snippet like
  "int foo(int a, int b) { return a + b; }"
there's nothing else involved than the assembly code containing basically 
some moves and an add and return instruction.  No runtime library 
involved.  There's a bit of runtime lib code in libtcc1.a which implements 
support for some things the compiler relies on that is better expressed 
with extra routines: some double-long arithmetics and va_list support, 
alloca, and the helpers for bounds-checking.  The code for that lies in 
libtcc1.a and is linked into the TCCState via tcc_add_runtime, called by 
tcc_relocate_ex in some cases.  This linking also places the resulting 
code in the provided buffers (or somewhere into TCCState).  It's deleted 
with tcc_delete, like the code from compile_string.




If a jit made a different TCCState for each routine it compiles, say 1000
routines,

a) would tcclib load 1000 copies of the runtime library?


Yes.  Basically a TCCState is a complete sandbox separate from each other 
(not in a safety sense, but in design, if you have wild writes in on 
TCCState it might affect memory that happens to be for another TCCState), 
only communicating with the host executable (e.g. to provide a 'bar' 
routine for this snippet: "void callbar(void) { bar(); }").  But libtcc1.a 
is only loaded as necessary, so if your snippets don't use va_list and 
alloca (and you don't use bounds checking) then you don't need any of it 
on x86-64 for usual code (i.e. not one involving 128 bit arithmetics).



b) would it make a static variable section for the runtime library 1000
times and initialize the variables in it?


Yes.


c) would it make a different heap for each routine?  If I call malloc in
one routine and then free it in another routine would it try to free it
into a different heap and corrupt a heap?


malloc and free aren't provided by TCC, they are provided by your host 
program (or rather by the supporting C library linked into it), the 
snippets, when calling malloc will use those routines.  So, if those are 
thread-safe (they are in all but the most basic C systems) then all is 
safe.  All TCCStates 

Re: [Tinycc-devel] Problem with NOTE commit

[Michael Matz]

Hello,

On Thu, 24 Dec 2020, Herman ten Brugge via Tinycc-devel wrote:

The recent commit 'ELF: include SHT_NOTE sections everywhere' does not work 
for me on x86_64.


The problem is in /usr/lib64/crt1.o
If I do: readelf -a -W /usr/lib64/crt1.o | grep .gnu.build.attributes.hot
I get:
  [64] .gnu.build.attributes.hot NOTE     0002e0 
28 00   G  0   0  4
  [65] .rela.gnu.build.attributes.hot RELA  001b38 30 18  
IG 90  64  8
  [72] .gnu.build.attributes.hot NOTE     000380 
28 00   G  0   0  4
  [73] .rela.gnu.build.attributes.hot RELA  001bf8 30 18  
IG 90  72  8
  [80] .gnu.build.attributes.hot NOTE     000420 
28 00   G  0   0  4
  [81] .rela.gnu.build.attributes.hot RELA  001cb8 30 18  
IG 90  80  8

   [   64]   .gnu.build.attributes.hot
   [   65]   .rela.gnu.build.attributes.hot
   [   72]   .gnu.build.attributes.hot
   [   73]   .rela.gnu.build.attributes.hot
   [   80]   .gnu.build.attributes.hot
   [   81]   .rela.gnu.build.attributes.hot


Huh, so multiple same-named sections in an .o file.  Somewhat unusual, but 
the above are all in section groups, so a supported scenario (in the ELF 
sense, not by TCC).  Can you send my your crt1.o file, please?


The tcc_load_object_file tries to merge the sections and then adjust the 
reloads. This does not work in this case because there are 3 section 
with the same name.


A hack would be to accept NOTE sections but only if they aren't in groups. 
Ugly, but, well...   Of course, correctly implementing ELF group support 
would also be an option, but more work, or maybe other hacks are possible. 
I'll take a look if I can get such crt file.



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

Re: [Tinycc-devel] Anyone else working with the RISC-V port?

[Michael Matz]

Hello Christian,

On Mon, 21 Dec 2020, Christian Jullien wrote:

tcc Linux/riscv-64 is now part of my OpenLisp compiler non-regression 
plateform and the result is as good as if compiled with gcc (except of 
course execution speed). My huge OpenLisp test suite runs flawlessly 
when using tcc. For my use, this port is fully functional. I use a 
Gnufarm emulated machine installed with latest Debian. I'm impatient to 
see a RPi like with riscv-64.


Here is what I can say of the wonderful port made by Michael.


That's all very nice to hear!  Thanks for your kind words :-)


Ciao,
Michael.



C.

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Michael Matz
Sent: Sunday, December 20, 2020 23:41
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Anyone else working with the RISC-V port?

Hello,

On Sat, 19 Dec 2020, Charles Lohr wrote:

I am interested in doing a project using TinyCC, a web-based IDE for 
the ESP32-C3, a wifi-enabled microcontroller.

https://github.com/cnlohr/espwebc3/blob/main/README.md

I spent a while trying to decipher riscv-gen, and it's actually not 
that bad.  Very much inline with the cryptic TinyCC (ok, bit of a jab, 
but it's not that bad).  It currently only supports RV64, vs the chip 
I'll be using supports RV32-IMC.  Conveniently, most of the 
instructions implemented in riscv-gen are the 32-bit instructions, 
only a handful of RV64 instructions, which shouldn't be too difficult to avoid.


Right, that should be relatively easy.  One thing to look out for will probably be the fact that you then need to use the generic code in tcc for open-coding 64bit support (e.g. arithmetic on long long), i.e. 
lexpand/lbuild/gen_opl, which currently is only tested on i386 and arm32. 
Look for uses of PTR_SIZE in tccgen.c.


You also need to adjust the linker/object-file-writer to use ELF32 on riscv; 
that's all supported already of course, but needs the right conditionals and 
some additional defines/codes for the 32bit relocations (where they really 
differ from the ELF64 ones).

Is anyone else working in this area? Has anyone expressed any 
possibility at adding a few more comments to the riscv-gen code?


Well, what can I say.  Sure, comments might be nice, if they clarify things :)


Are there any landmines I may run into?


Not that I know of, it's all fairly straight forward.  I have tested the
riscv64 backend only relatively lightly, and am not sure if others have played 
much with it, so it's quite possible you run into genuine bugs therein.


How eager would people be to add a -m32 flag for RISC-V?


I'd suggest going the same way as i386/x86-64, i.e. create a riscv32-tcc 
compiler, which can then be called from tcc when -m32 is used.  Supporting both 
bit-width in the same executable will run into major refactoring work as 
several types are hard-coded (e.g. the whole ELF support isn't conditionalized 
at runtime per word width).


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] Hello and a few questions about using libtcc

[Michael Matz]

Hello,

In addition to the answers already given by Kyryl:

On Sun, 20 Dec 2020, Joshua Scholar wrote:


Now questions about generated code.  The jit I'm hoping to make is for a
language that's embarrassingly parallel, so I need to know how the generated
code works with threads and stacks and contexts.

1) The simplest thing, what's the calling convention of generated
functions?  On 64 bit windows?  On 64 bit Linux? 


TCC follows the native calling convention, i.e. msvc on windows and ELF 
psABI on linux.



2)  Is the TCC runtime multithread safe?


Depends what you mean by runtime:
a) if you mean the code of libtcc itself, i.e. compiler/linker: you can 
use several TCCStates from separate threads, but must not use the same 
TCCState concurrently.
b) if you mean the code of libtcc1, i.e. support routines sometimes used 
by the generated code: then, yes, that's thread-safe.  (It's also very 
minimal, there's not much in term of support code necessary).



a) And what are the details?  Can I run generated code in multiple threads
at once?  Does it use locks for anything?


Yes, the generated code is as thread-safe as the input C code is.  No it 
doesn't use locks for anything (the runtime support for boundschecking 
uses locks, but that's for debugging purposes).



Is it at least as thread safe as C usually is, ie, you can do anything that
doesn't involve a shared buffer like an implicit error string. Would it be
fine as long as I put a critical section around some non-thread safe part?

3) Does the run time library use thread local storage?  


No.


4) If I did something weird like have a call out from generated code to my
code, and my code returned on the same stack but in the context of a
different thread than it entered from, would that break anything?


No.  Or, perhaps better said, it would break in the same way when the 
generated code would also be your code and not generated by TCC, i.e. TCC 
doesn't introduce additional restrictions.  In particular the usual 
makecontext/swapcontext way of implementing lightweight threads via stack 
switching should work just fine, as should any more unusual way of 
switching threads but not stack (what is that even supposed to mean?), as 
long as the input code doesn't have any problem if it had been written 
literally without TCC involvement.



5) Some systems are broken by fibers, ie, if I switched between generated
code, each using a different stack, but in the same thread, would that break
anything?


See above, stack switching shouldn't be affected by TCC-generated code, if 
the input C source isn't.



6) Are there any pointers on how to use the built in assembler?


It's the GCC builtin assembler syntax, but only for i386/x86-64, and with 
some limits.  The limits aren't documented and subject to change if more 
things are needed.  As for usage documentation have a look at GCCs docu:


https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Using-Assembly-Language-with-C.html


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

Re: [Tinycc-devel] Anyone else working with the RISC-V port?

[Michael Matz]

Hello,

On Sat, 19 Dec 2020, Charles Lohr wrote:


I am interested in doing a project using TinyCC, a web-based IDE for the
ESP32-C3, a wifi-enabled microcontroller. 
https://github.com/cnlohr/espwebc3/blob/main/README.md

I spent a while trying to decipher riscv-gen, and it's actually not that
bad.  Very much inline with the cryptic TinyCC (ok, bit of a jab, but it's
not that bad).  It currently only supports RV64, vs the chip I'll be using
supports RV32-IMC.  Conveniently, most of the instructions implemented in
riscv-gen are the 32-bit instructions, only a handful of RV64 instructions,
which shouldn't be too difficult to avoid.


Right, that should be relatively easy.  One thing to look out for will 
probably be the fact that you then need to use the generic code in tcc for 
open-coding 64bit support (e.g. arithmetic on long long), i.e. 
lexpand/lbuild/gen_opl, which currently is only tested on i386 and arm32. 
Look for uses of PTR_SIZE in tccgen.c.


You also need to adjust the linker/object-file-writer to use ELF32 on 
riscv; that's all supported already of course, but needs the right 
conditionals and some additional defines/codes for the 32bit relocations 
(where they really differ from the ELF64 ones).



Is anyone else working in this area? Has anyone expressed any possibility at
adding a few more comments to the riscv-gen code?


Well, what can I say.  Sure, comments might be nice, if they clarify 
things :)



Are there any landmines I may run into?


Not that I know of, it's all fairly straight forward.  I have tested the 
riscv64 backend only relatively lightly, and am not sure if others have 
played much with it, so it's quite possible you run into genuine bugs 
therein.



How eager would people be to add a -m32 flag for RISC-V?


I'd suggest going the same way as i386/x86-64, i.e. create a riscv32-tcc 
compiler, which can then be called from tcc when -m32 is used.  Supporting 
both bit-width in the same executable will run into major refactoring work 
as several types are hard-coded (e.g. the whole ELF support isn't 
conditionalized at runtime per word width).



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

Re: [Tinycc-devel] A possible bug in TCC

[Michael Matz]

Hello,

On Sun, 13 Dec 2020, Anton Shepelev wrote:


Vincent Lefevre:


No issue with tcc 0.9.27+git20200814.62c30a4a-1 provided
by Debian.


The bug on my side is reproduced with this version just five
days old:

  
https://repo.or.cz/tinycc.git/snapshot/8ff705554de47f16726ec5f1a6c49a162b926732.zip

I had to compile it myself on Windows, using
win32\build-tcc.bat . Is there a pre-compiled win32 build
available?

I have also tried the same on a Linux. Since I had not
enough permissions to install TCC, I only built it and tried
the following from the root of the source directory:

  ./tcc -Iinclude -L. ld.c


For uninstalled tcc you need to use './tcc -B. ...' to set the compiler 
path to something else than the install directory.



tcc failed with error:

  file '/usr/local/lib/tcc/libtcc1.a' not found

The file libtcc1.a is right there in the working directory.
Why did it ignore -L. ?


A deficiency.  libtcc1.a is searched in a different way than normal -lfoo 
libraries.


FWIW, I also can't reproduce the problem you're seeing on linux x86-64, 
with various revisions of the mob branch.



Ciao,
Michael.

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

Re: [Tinycc-devel] Multiple, threaded LibTCC states

[Michael Matz]

Hello,

On Thu, 3 Dec 2020, Jonathan Levi wrote:


I am using LibTCC to compile runtime defined functions for a rendering layer
of a project of mine.  I compile many of these functions in parallel. 
LibTCC is crashing with exit code -11, at what appears to be when execution
is passed to LibTCC on multiple threads, at the same time.  It happens when
I try to compile multiple functions at the same time, or compile a function
at the same time as calling another already compiled function.  (Although
calling multiple functions at the same time does not appear to exit.)

Should LibTCC work in multiple threads?  I wonder whether I am just missing
a dependency.


It's quite possible that there are still bugs with that, but in general it 
should work.  There's actually a testcase that compiles tcc with itself 
20 times with 20 threads, so that makes sure it normally works.


One thing to keep in mind: each thread must use a different top-level 
TCCState, i.e. tcc_new result, you can't share that one between threads 
(or at least can't use the same TCCState concurrently).  There is a little 
shared global state in TCC, but all accesses to that one are (supposed to 
be) protected by appropriate mutexes (fairly coaerse grained).


You also want to use the mob branch of tcc, not the 0.9.27 release.  And 
you may want to have a look at tests/libtcc_test_mt.c to see if you're 
using libtcc like that testcase does.



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

Re: [Tinycc-devel] struct bug: identical named struct members

[Michael Matz]

Hello again,

On Sun, 29 Nov 2020, Michael Matz wrote:


 The only other fast C map I know
 of is khash (https://attractivechaos.github.io/klib), however not memory
 efficient, and the codebase is somewhat bigger.


I guess there as many map implementations as there are C developers :-)


Though I should say that yours from C99Containers look nice to use, 
despite the macros-as-template hell in the implementation :-)



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

Re: [Tinycc-devel] struct bug: identical named struct members

[Michael Matz]

Hello,

On Sat, 28 Nov 2020, Tyge Løvset wrote:


Yes I started looking in struct_decl. Is there a reason why it doesn't use
an efficient unordered map for lookup, other than the extra code weight?


Mostly because of the T in tiny c compiler and because no profiling shows 
field lookup to be a problem :)



If that (and the cstr string type) is stripped down to its bare minimum, it
would be perfect for general symbol tables.


It's not general symbol tables in this case, but fairly specific: the set 
must be ordered (for struct layout), at least at some point; the set is 
looked up by small integers (aka identifier name); the set tends to be 
small.



The only other fast C map I know
of is khash (https://attractivechaos.github.io/klib), however not memory
efficient, and the codebase is somewhat bigger.


I guess there as many map implementations as there are C developers :-)


But, looking at tccgen.c, it may be too ambitious to integrate?


I personally would not integrate a full generally capable hashmap without 
measurements on realistic sources (i.e. not sources that artificially use 
structs with 1000 members and 10.000 accesses to the last member :) ). 
It's simply such that the number of struct members in C sources tends to 
be a dozen max, on average, where a linked list is fairly okay.  (This 
implies that the quadratic checking of duplicates at struct decl time 
might be completely acceptable, eventually it will be overshadowed by 
normal member lookups)


But do try, if the implementation turns out to not add memory overhead and 
many source lines, and is generally in the spirit of TCC, why not :) 
(what's the spirit?  I don't know, you'll eventually get a feeling for 
it.)


(you will probably see in the course of such experiment that various 
things aren't that straight forward to add, e.g. currently all parser 
structures are Syms, and they are generically freed per scope no matter if 
they are types, symbols, cleanups, or anything else; you would have to 
free the hash tables somewhere, which would exist only for struct types, 
which would mean at least different handling for these and the other Syms, 
i.e. you'll probably see that it reduces elegance somewhat)



ps: I haven't really looked much at the core code yet;


Keep reading then, it's a quirky, dense, capable and satisfying source 
base :)



Ciao,
Michael.


I do have some
compiler tech experience way back from creating an external syntax checker
for www.autoitscript.com, using flex and yacc.
(http://www.google.com/search?q=au3check)

Cheers,
Tyge

On Sat, 28 Nov 2020 at 00:32, Michael Matz  wrote:
  Hello,

  On Fri, 27 Nov 2020, Tyge Løvset wrote:

  > Is this a known bug, or regression? 

  Known bug.

  > I tried to follow the code in parse_btype() in tccgen.c for
  the missing
  > struct member symbol lookup check, but didn't succeed so far:
  >
  >       } else {
  >             c = 0;
  >             flexible = 0;
  >             while (tok != '}') {
  >                 if (!parse_btype(, )) {
  >     skip(';');
  >     continue;
  > }

  Member lookup is linear, so checking for duplicates is
  quadratic, so TCC
  doesn't bother to do it.  The check would belong to struct_decl,
  not
  parse_btype, probably involving find_field before adding it.


  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] struct bug: identical named struct members

[Michael Matz]

Hello,

On Fri, 27 Nov 2020, Tyge Løvset wrote:


Is this a known bug, or regression? 


Known bug.


I tried to follow the code in parse_btype() in tccgen.c for the missing
struct member symbol lookup check, but didn't succeed so far:

      } else {
            c = 0;
            flexible = 0;
            while (tok != '}') {
                if (!parse_btype(, )) {
    skip(';');
    continue;
}


Member lookup is linear, so checking for duplicates is quadratic, so TCC 
doesn't bother to do it.  The check would belong to struct_decl, not 
parse_btype, probably involving find_field before adding it.



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

Re: [Tinycc-devel] Building sudo?

[Michael Matz]

Hello,

On Fri, 20 Nov 2020, James Mills wrote:


Are you saying if I don't alias ar to tcc -ar it will build?


If you have another POSIX compatible ar, I suspect so, yes.

What am I missing? I need to alias ar to tcc -ar for other builds to 
work :)


Well, it seems that sudo, as part of its default build process, wants to 
extract archives it built itself.  tcc -ar simply is incapable of that 
(right now), it only supports creating archives.  So, if you don't want to 
hack sudo's build system then you need an 'ar' that can extract archives. 
If you then do have such 'ar' (in $PATH), then not aliasing 'ar' to 'tcc 
-ar' will do the right thing.


If you don't have any such 'ar', but only tcc, then you can't make it work 
except by changing sudo's build system or implementing the missing 
functionality in tcc -ar.


It's may for instance be possible to build binutils (at least parts of it) 
with tcc, then you would have a capable 'ar' program available.



Ciao,
Michael.



cheers
James

James Mills / prologic

E: prolo...@shortcircuit.net.auw: prologic.shortcircuit.net.au
Blog:  Read my Blog
Twtxt: Follow me on twtxt.net


On Thu, Nov 19, 2020 at 5:28 AM Michael Matz  wrote:
  Hello,

  On Tue, 17 Nov 2020, James Mills wrote:

  > Hi guys,
  > Tried to build sudo with tcc and it fails with:
  >
  > libtool: link: (cd .libs/sudoers.lax/libparsesudoers.a && 
arx"/usr/ports/sudo/build/src/sudo-1.9.3p1/plugins/sudoers/./.libs/libparsesu
  d
  > oers.a")
  > usage: tcc -ar [rcsv] lib file...
  > create library ([abdioptxN] not supported).
  > make[1]: *** [Makefile:277: sudoers.la] Error 1
  > make[1]: Leaving directory
  > '/usr/ports/sudo/build/src/sudo-1.9.3p1/plugins/sudoers'
  > make: *** [Makefile:108: all] Error 2
  > #

  TCCs own 'ar' functionality is very limited, it's not a full
  replacement.

  > Is tcc missing a feature needed here? Is there a work-around?

  Yes, don't alias 'ar' to 'tcc -ar'.


  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] Building sudo?

[Michael Matz]

Hello,

On Tue, 17 Nov 2020, James Mills wrote:


Hi guys,
Tried to build sudo with tcc and it fails with:

libtool: link: (cd .libs/sudoers.lax/libparsesudoers.a && ar 
x"/usr/ports/sudo/build/src/sudo-1.9.3p1/plugins/sudoers/./.libs/libparsesud
oers.a")
usage: tcc -ar [rcsv] lib file...
create library ([abdioptxN] not supported).
make[1]: *** [Makefile:277: sudoers.la] Error 1
make[1]: Leaving directory
'/usr/ports/sudo/build/src/sudo-1.9.3p1/plugins/sudoers'
make: *** [Makefile:108: all] Error 2
#


TCCs own 'ar' functionality is very limited, it's not a full replacement.


Is tcc missing a feature needed here? Is there a work-around?


Yes, don't alias 'ar' to 'tcc -ar'.


Ciao,
Michael.

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

Re: [Tinycc-devel] How do you specify code model?

[Michael Matz]

Hello,

On Mon, 9 Nov 2020, Somchai Smythe wrote:


I guess it's documented somewhere, and I tried to find out that way,
but failed.  I looked in the tcc git root directory README file, the
man page, the TODO, the wikipedia page
https://en.wikipedia.org/wiki/Tiny_C_Compiler,
https://bellard.org/tcc/, https://bellard.org/tcc/tcc-doc.html, and
tried using Google and Bing with no luck.  I tried grepping the source
and only found one file, ./elf.h, that was non-windows-centric and


Does Windows even support the large code model?


mentioned models, but they didn't seem to indicate what model is used.
It did menion huge model though:

#define SHN_PARISC_HUGE_COMMON  0xff01 /* Common blocks in huge model.  */

which is why I asked the original question.


That's PA-RISC, not x86-64.  But may I ask why you went to such great 
lengths to find anything about the large code model on x86-64?  What's 
your usecase?


I'm not sure if the README or other documentation should specify 
unsupported things as that list is unlimited.  The normal course of action 
would be to document supported features, implying that everything not 
mentioned can't be expected to be supported.  (Of course, TCCs current 
docu hasn't reached that ideal yet either).



Ciao,
Michael.

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

Re: [Tinycc-devel] How do you specify code model?

[Michael Matz]

Hello,

On Thu, 5 Nov 2020, Somchai Smythe wrote:


With gcc and clang, I specify the AMD64 large code model with
-mcmodel=large
but that doesn't seem to work for tcc.  What is the right way to do that on tcc?


tcc only supports the normal ("small") code model, so there's no way to 
specify a different one.  As the large code model is only useful when your 
overall code segment in the executable or a shared lib is larger than 2GB 
the feature isn't very useful even for GCC or LLVM.



Ciao,
Michael.

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

[Tinycc-devel] attribute alias handling and Windows testing request

[Michael Matz]

Hello,

I just pushed a change to reinstate proper handling of the alias attribute 
(352e1d0f).  It affects targets with different symbol leading underscore 
conventions, some of which I can't properly test, namely Windows.  Can 
someone do this for me please?  Thanks in advance.


(The commit gives the rationale and includes a testcase for the require 
functionality)



Ciao,
Michael.

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

Re: [Tinycc-devel] compare problem on riscv target

[Michael Matz]

Hello,

On Thu, 16 Jul 2020, Herman ten Brugge via Tinycc-devel wrote:


While testing gmp on the riscv target I discovered a compare bug.
(t-get_d test fails in directory tests/mpq)

The code:

#include 

int tst(void) {
  long value = 3;
  return -value;
}

int main(void) {
  printf ("%d\n", tst());
  if (tst() > 0) printf ("error\n");
  return 0;
}

prints "error" on the riscv target. The problem is that the value returned is
converted from long to int in gen_cast and is returned as 0xfffd from 
tst().


On riscv registers should always contain the sign-extended value of 
shorter values, so this here is the bug, and ...



The compare in the main code fails because it does a long compare
instead


... this is the okay because of the above invariant.

TCCs other architectures expect either zero extension or don't care or 
natural extension about narrow values in large registers, so riscv was 
somewhat novel in that respect; obviously I didn't catch all corner cases 
yet, so thanks for the report.



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

Re: [Tinycc-devel] function pointer problem on x86_64/macos/riscv

[Michael Matz]

Hello,

On Thu, 16 Jul 2020, Herman ten Brugge via Tinycc-devel wrote:


While testing gmp on the x86_64 target I discovered a fuction pointer bug.
(reuse in directory tests/mpf)

The code:

#include 

typedef int (*func) (int);
func allfunc[] = { putchar };

int main(void) {
  printf ("%d\n", allfunc[0] == putchar);
  return 0;
}

prints 0 on x86_64, macos and riscv (all other targets (i386, arm, arm64, 
win32, win64) print 1).


There seems to be something wrong with relocation.
The allfunc[0] points to the got table. The putchar to the externel symbol.


Yeah, known problem.  Function pointer value comparisons involving 
functions in other shared objects are surprisingly complicated when shared 
objects and lazy linking (and hence PLT slots) are involved.  It took many 
years to fix most (or all?) corners cases even in binutils and gcc, and 
some even can't be fixed when weak or protected symbols are involved.


In this particular case the reason is that TCCs linker doesn't currently 
emit outstanding relocations for executables except for the GOT, so the 
reference to putchar in the data section (in allfunc) has to be statically 
resolved to something local, and that's the PLT slot.


Note that this only affects the value of the function pointer itself, not 
the semantics (i.e. you can call through allfunc[0] just fine), so it's 
relatively seldomly a real problem.  Does this affect anything else than a 
synthetic test case in gmp?



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

Re: [Tinycc-devel] aarch64: subnormal double to long double conversion bug

[Michael Matz]

Hello,

On Wed, 15 Jul 2020, Vincent Lefevre wrote:


With TCC mob on aarch64, the double to long double conversion
is buggy on subnormal values. This makes a MPFR test fail
(reported by Christian Jullien).


Thanks for the report, it was indeed unhandled in the support routines. 
I fixed this in mob for riscv64, but the routines are shared with aarch64 
so it's likely also fixed there, please check.



Ciao,
Michael.

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

Re: [Tinycc-devel] aarch64: wrong constant values for float.h

[Michael Matz]

Hello,

On Wed, 15 Jul 2020, Christian JULLIEN wrote:


I think that float.h should be modified accordingly, is it Ok?


Yes, as the aarch64 backend indeed uses the IEEE float128 for long double.


(what are the risc-v values)


Same as on aarch64.


Ciao,
Michael.

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

Re: [Tinycc-devel] missing dlfcn.h but defined in tcclib.h, also missing RTLD_LOCAL

[Michael Matz]

Hello,

On Tue, 14 Jul 2020, UnknownGamer40464 wrote:


I see. I had assumed it was for unix compatibility but I guess not.

Is it supposed to show up in the win32 tcclib.h file then?


tcclib.h is a small convenience header that exists merely to show how a 
minimal installation on unix-like systems could look like, i.e. it's a 
replacement for a subset of standard headers.  As such it declares a 
couple functions and macros that are useful for simple standard C 
programs.  It might or might not declare more facilities than are actually 
available on the system at hand, and noone bothered to add the #ifdef-ery 
to make it declare only available things.  Similarly it also doesn't 
declare all facilities that are available on the system (for that you have 
to use the standard headers).


I.e. that it declares also dlfcn facilities is not an issue, though it 
might lead to the expectation that those are available on Windows, and 
hence confusion.  The best way to avoid this is actually to simply not use 
that header at all.



Ciao,
Michael.



It seems to be placed there by the win32 batch script,
 but indeed using dlfcn functions cause undefined symbol errors.

Either way, sounds like a minor thing to me now.

Thanks a lot.

On Tue, Jul 14, 2020 at 1:02 AM Christian JULLIEN  wrote:
  Hi,
dlfcn provides declarations for functions dlopen/dlsym/dlclose that
allow to dynamically load a shared lib at runtime on unix systems.
Windows uses a similar but different interface to load DLL (which are
different from .so shared libs).
Hence, you don't need dlfcn.h on Windows.

Systems like mingw/cygnwin add some unix compatibiliy on Windows. This
is not the case with tcc which supports only C standard and most
Windows API on Windows.

C.



  Le : 14 juillet 2020 à 05:27 (GMT +02:00)
  De : "UnknownGamer40464"
  
  À : "tinycc-devel@nongnu.org" 
  Objet : [Tinycc-devel] missing dlfcn.h but defined in
  tcclib.h, also missing RTLD_LOCAL


  Is there any reason dlfcn.h is missing (at least on
  windows) and yet its functions and macros
 are defined in tcclib.h, and that tcclib.h references it in a
comment as if it were a file?

I also noticed RTLD_LOCAL was missing but it seems like
 it should just be 0x000 since, according to oracle man pages,
 local is the default option.

I see this on a windows build of 50abaae, which I'm using, and
in windows mob.

Thanks.



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

[Michael Matz]

Hello,

On Fri, 10 Jul 2020, 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


It's not, and even if it were I wouldn't want to support the complete ld 
cmdline interface (with setting all kinds of bells and whistles of the 
generated libraries).  In particular the versioning options.  TCC 
hardcodes defaults that work, and that's that :)



Ciao,
Michael.

___
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

[Michael Matz]

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

Re: [Tinycc-devel] Tiny c availability

[Michael Matz]

Hello,

On Thu, 9 Jul 2020, arn...@skeeve.com wrote:


I compile gawk with it all the time and gawk passes its test suite.
I use it mainly when I want a quick build to test something.

My big wish for tcc is that it'd produce debug info for use with GDB.


Recent mob has some changes that make tcc emit some debug info also for 
variables (it always had support for line numbers).  E.g. this works fine:


% cat dbgexample.c
struct S {int member;};
int global = 2;
extern int printf (const char*, ...);
int main()
{
  int i = 1;
  struct S s;
  s.member = 42;
  printf("%d %d %d\n", i, global, s.member);
  return 0;
}

% ./tcc -g dbgexample.c
% gdb ./a.out
...
(gdb) start
Temporary breakpoint 1, main () at dbgtest.c:6
6 int i = 1;
(gdb) p global
$1 = 2
(gdb) p i
$2 = 0
(gdb) n
8 s.member = 42;
(gdb) p i
$3 = 1
(gdb) n
9 printf("%d %d %d\n", i, global, s.member);
(gdb) p s
$4 = {member = 42}
(gdb) ptype s
type = struct S {
int member;
}

Using it for good will probably reveal issues and incompleteness here and 
there, but some non-trivial things do work fine.  (Luckily we aren't an 
optimizing compiler, so stabs will be enough to express everything we need 
for a while; we don't need DWARF).



Ciao,
Michael.



Arnold

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

[Michael Matz]

Hello,

On Thu, 9 Jul 2020, Christian Jullien wrote:


Got it! Once again Apple does things in your back.
Whatever starts with DYLD_ is processed directly by the system in a 
different way on a real mac (tested on Catalina and High Sierra).


Read: 
https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-dyld-environment-variables


Ah, I guess the purpose of this is the same as why Linux ld.so ignores 
e.g. LD_LIBRARY_PATH for setuid binaries (understandable).  That MacOS 
(with some settings?) ignores this also for normal binaries is of course 
strange.  I'm glad you found a work-around :)



Ciao,
Michael.



Michael, it probably works for you because your system is set 
differently. Mine is 'standard" I mean installed wo. special tuning.


--- Makefile ---
ifndef TOP
TOP = .
CURDIR = $(PWD)
SYSTEM = `uname`
endif

export DYLD_LIBRARY_PATH := $(CURDIR)/$(TOP)
export DYLD_LIBRARY_FOO := $(CURDIR)/$(TOP)
export DYLD_FOO_PATH := $(CURDIR)/$(TOP)
export DYLDFOO_PATH := $(CURDIR)/$(TOP)
export EDYLD_LIBRARY_PATH := $(CURDIR)/$(TOP)
export

all:
   @echo Running on $(SYSTEM)
   @echo in Makefile environment is set to
   @set

$ make | grep DY
DYLDFOO_PATH=/Users/jullien/foo/.
EDYLD_LIBRARY_PATH=/Users/jullien/foo/.

All "^DYLD_" variables are dropped!!!
I'll revert to the code I wrote which uses "DYLD_LIBRARY_PATH= tcc"

I faced a similar issue while porting Le-Lisp (not OpenLisp) on macOS. The 
assembler code has dlink and llink variables (dynamic and lexical link). macOS 
assembler uses llink internally and silently dropped (wo warning) this variable 
while dlink was kept (!). It took me 2 days to understand. G!

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Christian Jullien
Sent: Wednesday, July 08, 2020 17:50
To: tinycc-devel@nongnu.org; jull...@eligis.com
Subject: Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after 
cleanup

Thank you for testing, make is the same:
jullien@jacquet:~/tinycc $ make -v
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.

Single dash was an automatic edit from my email agent. I pass of course 2 dashes

I tested on High Sierra which uses bash and Catalina which uses zsh. It fails 
the same on both systems.

jullien@jacquet:~/tinycc $ make clean
jullien@jacquet:~/tinycc $ ./configure --disable-static
Binary directory/usr/local/bin
TinyCC directory/usr/local/lib/tcc
Library directory   /usr/local/lib
Include directory   /usr/local/include
Manual directory/usr/local/share/man
Info directory  /usr/local/share/info
Doc directory   /usr/local/share/doc
/usr/include dir
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include
Source path /Users/jullien/tinycc
C compiler  clang (10.0)
Target OS   Darwin
CPU x86_64
Config  OSX static=no
Creating config.mak and config.h
config.h is unchanged
jullien@jacquet:~/tinycc $ make && make test
clang -o tcc.o -c tcc.c 
-DCONFIG_USR_INCLUDE="\"/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include\""
 -DTCC_TARGET_X86_64 -DTCC_TARGET_MACHO   -DONE_SOURCE=0 -Wall -O2 
-Wdeclaration-after-statement -fno-strict-aliasing -fheinous-gnu-extensions -Wno-pointer-

clang -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  -flat_namespace 
-undefined warning
clang -o tcc tcc.o libtcc.dylib -lm -lpthread -ldl  -flat_namespace -undefined warning  
-Wl,-rpath,"/usr/local/lib"
../tcc -c libtcc1.c -o libtcc1.o -B.. -I..
../tcc -c alloca86_64.S -o alloca86_64.o -B.. -I..
../tcc -c alloca86_64-bt.S -o alloca86_64-bt.o -B.. -I..
../tcc -c va_list.c -o va_list.o -B.. -I..
../tcc -ar rcs ../libtcc1.a libtcc1.o alloca86_64.o alloca86_64-bt.o va_list.o
../tcc -c bt-exe.c -o ../bt-exe.o -B.. -I..
../tcc -c bt-log.c -o ../bt-log.o -B.. -I..
../tcc -c bcheck.c -o ../bcheck.o -B.. -I.. -g
...
 hello-exe 
dyld: Library not loaded: libtcc.dylib
 Referenced from: /Users/jullien/tinycc/tests/../tcc
 Reason: image not found
/bin/sh: line 1: 62218 Abort trap: 6   ../tcc -B.. -I../include -I.. 
-I.. ../examples/ex1.c -o hello
+ ../tcc -vv
dyld: Library not loaded: libtcc.dylib
 Referenced from: /Users/jullien/tinycc/tests/../tcc
 Reason: image not found
/bin/sh: line 1: 62220 Abort trap: 6   ../tcc -vv
+ ldd ../tcc
/bin/sh: ldd: command not found
+ exit 1
make[2]: *** [hello-exe] Error 1
make[1]: *** [all] Error 2
make: *** [test] Error 2




-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Michael Matz
Sent: Wednesday, July 08, 2020 17:35
To: jull...@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works afte

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

[Michael Matz]

Hello,

On Wed, 8 Jul 2020, Christian Jullien wrote:



It is still unclear why it does not work but on macOS, ./configure
–disable-static
Now raises an error:

 hello-exe 

=== recurse /Users/jullien/tinycc/tests/.. ===

dyld: Library not loaded: libtcc.dylib

  Referenced from: /Users/jullien/tinycc/tests/../tcc

  Reason: image not found


Hmm, can't reproduce here:

% git log -1 --online HEAD
9d75f14 Fix structure passing i386 PE
% make clean
% ./configure --disable-static
...
Config  OSX static=no
...
% make
% make test
... works ...

(Note the double dash for configure options, I'm not sure if it was just a 
typo in your mail).  And there's proof that the export from the Makefile 
does work, because calling tcc from the tests directory directly indeed 
doesn't work:


% cd tests; ../tcc -h
dyld: Library not loaded: libtcc.dylib
  Referenced from: /Users/micha/src/tinycc/tests/../tcc
  Reason: image not found
Abort trap: 6

So that the testsuite works for me is the indication that the 'export 
DYLD_LIBRARY_PATH' construct does work (for me).  Any differences in make 
behaviour perhaps?


% make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i386-apple-darwin11.3.0


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

Re: [Tinycc-devel] Regression building GMP with tcc, bisected

[Michael Matz]

Hello,

On Mon, 6 Jul 2020, Herman ten Brugge wrote:


In the old code you can also make it fail:
tst.s:
-
    .data
    .globl  foo
    .long   0
foo
    .byte   0
-

If you compile it in the old compiler with:
tcc -include tst.s -c tst.s
you get no error. This is because of the same latent bug in next_nomacro1.


I think the bug is rather to prepare preprocessing directives and the 
inline stack when no preprocessing is to be done.  See 40671f76 in mob.



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