Re: [Tinycc-devel] bug

[Kyryl Melekhin]

Hello,

This isn't right. It should be:
printf("%lld\n", (long long int)641*6700417);
instead of:
printf("%lld\n", 641*6700417);

Default type is assumed to be int.

Tested x86_64 linux the output is correct.
Please update the tcc to the git version or
specify the platform on which the bug occurs.

Thanks,
Kyryl

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

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

[Kyryl Melekhin]

Hello Michael Matz,

On a side note about tcc and VLA, I have reported a valgrind bug
on their mailing list. But there might be a chance that it is
actually tcc bug, though I could not find any incorrect behavior
in my programs compiled by tcc.

I think it's quite normal for valgrind to complain about VLAs
generated by tcc on x86_64? 

Here's the archived emails:
https://sourceforge.net/p/valgrind/mailman/message/37382347/
https://sourceforge.net/p/valgrind/mailman/message/37382384/
https://sourceforge.net/p/valgrind/mailman/message/37382663/
https://sourceforge.net/p/valgrind/mailman/message/37382912/

John did not update on the results of further investigation
and I suppose he did hit a hard wall.

What's your opinion on the matter? I am not awfully familiar
with tcc's VLA implementation itself, but it does something
that triggers valgrind to think there are uninitialized values
when it's not actually possible.

Kind Regards,
Kyryl.

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

Re: [Tinycc-devel] Code generation: `libtcc` vs transpiling to C and then compiling with tcc. Why one over another?

[Kyryl Melekhin]

On Tue, Nov 23, 2021 at 7:47 PM rempas via Tinycc-devel
 wrote:

> P.S. Forgive me if the formatting is not the best, normally I'm not writing 
> emails
> so I'm still working on that

About that: http://david.woodhou.se/email.html
Hope this helps,

Kind regards and good luck hacking on tcc.
Kyryl.

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

Re: [Tinycc-devel] Issues compiling as a static library on windows

[Kyryl Melekhin]

Hello, if your goal is to embed tcc into your application, you would
be better off using
https://github.com/kyx0r/tinycc

Yes, sure it might be outdated cause I can't be bothered to update it
properly, but
it proves a point. Things should be simple, and as such this will get
you up and running
in no time.

Kind regards,
Kyryl.

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

Re: [Tinycc-devel] manually inlining functions

[Kyryl Melekhin]

Well, I may take that back, recursion may be useful if you
have a 5000 loc function that you need to invoke
on some very rare occasion once. And if you care about
the size of your executable a lot for some reason. 
But on hotpath, it makes no sense. Unless you are trying
to satisfy your academia, which likely aren't teaching
you useful stuff anyways... But even in those cases, recursion
can be a goto statement, with little state dublication. 
I tried actually cracking this problem before, (about rewriting
recursion iteratively) and the aspect of your analyzer to keep
track of every data that is actually relevant (to get the optimal
solution) is hard to achieve. I had some sucesses, until I got
tired of trying to solve this. Sorry this a bit off topic, carry on.

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

Re: [Tinycc-devel] manually inlining functions

[Kyryl Melekhin]

Yakov  wrote:

> Kyryl you cannot inline everything because you will get code
> explosion, often infinite code explosion when functions have a
> circular dependency on each other. I am just talking about inlining
> certain functions carefully chosen by a programmer.

Yeah, I get that. That's why it is so hard to make such a tool.
Because recursion is hard to decompose, so the inliner has to be
smart enough to actually rewrite the recursive solution iteratively
otherwise it will blow up. But that actually opens up a massive
opportunity for optimizations, because lets be real - recursion 
sucks and there is never ever a situation where it's actually 
useful for the cpu to do. And yes, the unary() function in tcc
which is recursive sucks a lot too, there is just so much 
state in there that it's very difficult to understand what is
going on. Luckly I have been looking at that code for more
than a year, so my grasp got better, but if that were iterative,
I be loving it even more.

--

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

Re: [Tinycc-devel] manually inlining functions

[Kyryl Melekhin]

Yakov  wrote:

> Manual inlining seems to be a straightforward thing, just clone the
> node into the ast and rename all variables to something unique so I
> thought maybe that's what tcc supports with some pragma or what not.

If you create such a tool which can take any C code and straight up
inline everything into main() function you would be revolutionary
genious in my eyes. I don't know why, but seems like nobody tried
creating such tool before or I am not aware of it's existance. If
you find any, let me know. Thanks.

Regards,
Kyryl.

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

Re: [Tinycc-devel] Can tcc -run work with multiple source files?

[Kyryl Melekhin]

Peng Yu  wrote:

> Hi,
>
> See the following examples, tcc -run does not work with multiple
> source files. But without -run tcc works as expected. Why -run does
> not run? Can -run be made to work with multiple source files? Thanks.
>
> $ cat main.c
> #include "print.h"
>
> int main() {
>   print();
> }
> $ cat print.c
> #include 
>
> void print() {
>   puts("Hello World!");
> }
> $ tcc -run main.c  print.c
> tcc: error: undefined symbol '_print'
> $ tcc main.c  print.c
> $ ./a.out
> Hello World!
>

Hello Peng Yu, 

The -run switch must always be last. Due to specifics of tcc
argument parsing.

$ tcc main.c  print.c -run 

This will work.

Regards,
Kyryl

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

Re: [Tinycc-devel] Regarding Long double Constant

[Kyryl Melekhin]

"Christian Jullien"  wrote:

> No, I think he probably meant (1F-1F) to get 0.0F value?

Looking at the general context I think it should be 

else if (vtop->c.ld == (vtop->c.ld - vtop->c.ld))

instead. 

But as for my opinion I also think it's unnecessary and
should be reverted.


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

Re: [Tinycc-devel] Regarding Long double Constant

[Kyryl Melekhin]

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. 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)*
>
> I have pushed my solution
> 
> and please let me know if you have any queries regarding it.
>
> Regards
> Ayush

Hello Ayush,

tccgen.c:8105:41: error: 'f1' undeclared (first use in this function); did you 
mean 'y1'?
 8105 | else if (vtop->c.ld == (f1-f1) )
  | ^~
  | y1

I don't know where you found f1 in that
function but the build is broken right now.
Typo?

Regards.

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

[Tinycc-devel] Jupm Optimizations regession bug

[Kyryl Melekhin]

Hello Grischka and Tcc community,

I have found a regression bug in Tcc code gen (X86_64).
Caused by this commit: 8227db3a23fd3cf11840eaa25eab5f3f5f813ac7
Sadly I don't have a small test case to reproduce it. But it is
caused by stack allocation (unknown compile time alloca but in
C99). You have to compile my text editor project, I get a crash 
in vfprintf in MuslC. The rsp pointer is corrupted. What is funny
that crash is completely unrelated to the code that causes it, the
reason I am 100% sure this is not a bug in any of my code is because
first, I don't have any invalid accesses, tcc version compiled 
1 commit behind from the commit above never crashes like that and 
also obviously it does not crash with any other compiler, gcc, clang, etc.


Here is the 2 lines that cause invalid rsp instruction code gen.

https://github.com/kyx0r/neatvi/blob/f6c46e9e8bdd8b1d4011d08019115936268e8536/vi.c#L1727
https://github.com/kyx0r/neatvi/blob/f6c46e9e8bdd8b1d4011d08019115936268e8536/vi.c#L1737


Why nobody had this dynamic array crashes before? As you can see the
input for compiler is pretty complicated, there is a enclosed switch 
into if statements, and even more if statements everywhere. This is why
I can't test the bug in more simple way, because it is unclear where
the undefined behavior occurs in tcc. But from what I saw in that
regression commit that if statements code gen was changed. Probably
what happens now is the compiler places rsp restore instructions in the
wrong places perhaps they are placed before the if statement inside
switch. Also the code I linked does not have to run at all for it to crash,
the only thing that has to happen is to be any of the cases of enclosing
switch be true and execute.

I can fix my code by simply not using the C99 stack allocated arrays
in those spots, but that does not solve the obvious compiler bug.

I will take a look into that commit more closely sometime later
and maybe find a fix, but since grischka wrote it he may solve
the bug before I do.

Regards,
Kyryl

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

Re: [Tinycc-devel] [PATCH 3/3] stdatomic: stdatomic.h header

[Kyryl Melekhin]

Elijah Stone  wrote:

> On Tue, 26 Jan 2021, Kyryl Melekhin wrote:
>
> > Also while atomics are probably better solution so using something like 
> > mutex or spinlock, they are platform dependant
>
> They're no more platform-dependent than addition.  Obviously they do need 
> support from the CPU, but so does everything else.  They don't depend on 
> any OS-specific facilities or anything like that.
>
> > they just kind of produce code smell
>
> How's that?

Absolutely agree with you that atomics are nothing more but just cpu
instructions. I probably think this way because I always try to not use
any GNU compiler extensions or anything too fancy that would require use
of extra features. So for example just calling pthread_mutex_lock() does
not require anything from compiler other than to call the function.
I think part of contributing to this midset is that I only write C99
code, and tcc being not able to support atomics until now assured me
not to use them. It's hard to accept some feature like this one after
avoiding it for very long time. I might come to change my mind.

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

Re: [Tinycc-devel] [PATCH 3/3] stdatomic: stdatomic.h header

[Kyryl Melekhin]

Dmitry Selyutin  wrote:


Sorry, it actually may be in C11 but not in C99
for sure, this revision introduces the atomic
https://en.wikipedia.org/wiki/C11_(C_standard_revision)
So it maybe be actually fine, as per tcc C11 support.

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

Re: [Tinycc-devel] [PATCH 3/3] stdatomic: stdatomic.h header

[Kyryl Melekhin]

Dmitry Selyutin  wrote:

> Ok, what exact parts do you suggest to change? For now I see that dropping
> __cplusplus guards should make the code C++-free; please, correct me if I'm
> wrong.

Yeah, pretty much just that. But I don't know if grishka will approve this
patch generally, because atomics are not in the standard, so it may be
against the tcc being "tiny". Also while atomics are probably better solution
so using something like mutex or spinlock, they are platform dependant and
they just kind of produce code smell, so personally I always tried to avoid
using them, because portability issues might arrise at some point, especially 
with new hardware and embeded world.

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

Re: [Tinycc-devel] [PATCH 3/3] stdatomic: stdatomic.h header

[Kyryl Melekhin]

Dmitry Selyutin  wrote:

> > Except to the extent which they're not, which is clear from the fact that
> I was able to recognize that as clang's header.
>
> I don't object to marking it as clang-derived. I can also copy the
> copyright notice.
>
> > Why should the Tiny _C_ Compiler's headers be compatible with c++?
>
> Because this is the direction which will most certainly be reflected in the
> future standards, in C++ for sure. If it's not difficult to keep it
> compatible, I don't see why it should not be compatible. I cannot predict
> how and why this header can be re-used, though.

C++ support statements should be avoided simply because
it is not consistent to the rest of the codebase. If you want to 
build it with cpp compiler having that one file is pointless.
Nothing will work anyways. Also gcc now depends on c++ which
I think was their greatest mistake and downfall. Please don't
make this happen with tcc. 

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

Re: [Tinycc-devel] Miscompilation returning small struct

[Kyryl Melekhin]

Nicholas Fraser via Tinycc-devel  wrote:

> I've encountered what I believe is a miscompilation bug in TinyCC. I'm using
> tcc 0.9.27 on latest Arch Linux on x86_64. I can't reproduce the same issue on
> the mob branch so this may already be fixed, but I can't find a bug report
> about anything similar so it may just be a coincidence; the bug might still be
> around, just reproducible in a different way. I tried reducing the code as 
> much
> as possible:

>
> Sorry if this is already fixed. I lost a couple hours tracking this down today
> so if it is already fixed, maybe it's time for a release?
>
> Nick
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Hello Nicholas, 
I have tried to reproduce the bug just now and it is already fixed on mod,
however, you are right - the old release version does still have it.

Tcc does not release new versions mainly because everyone just uses mob
I think? There is just no person to go and do all the boring routine of
updating it for every distro. Maybe you can take the initiative?

Regards,
Kyryl.

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

Re: [Tinycc-devel] Almost added a feature, but I broke things

[Kyryl Melekhin]

This isn't a build system you are misunderstanding a lot of things, it's a
special tool that can save you a lot of time if you ever need to correctly
combine C source or libraries into one file. The best build system is
having no build system at all. Also files are annoying to a lot of people
and hurt your understanding of the code as a whole. Thats why single header
libraries are so popular. Sometimes the best way to read the source code of
some C project is to combine everything into one file and explore the code
in its entirety without wasting your time memorizing where every function
is located, what file and subfolders. Sometimes to gain complete
understanding of complex system it's better to strip it down to the
"suckless" level. Also if your editor can't handle large files, it's better
to reconsider your tools or write your own that suck less. There is always
some kind of missing data and indirection between the original software
authors and you, what made sense to them when building a project will not
be something you will be able to understand on your own. Most of the time
developers split code into files for no reason whatsoever and cryptic names
dont help. I don't recall ever having filename help me in understanding the
code of example. It's just for esthetic organizational purposes only, but
they are useless when it comes to being productive. Also dont even tell me
about multicore builds, those are sucky too, most of the time you will be
hit by O(n) slow linker, which makes whole thing even slower in some cases.
That's why I use Tcc, compiler should be fast enough to handle massive
codebases without a chug. If tcc compiles 200K loc of code in less than a
second, I don't think any reasonable user land applications should have any
justifications for using build systems because such a compiler exists.

Anyway, I was actually replying to the person who asked me about the
amalgamation, but I figured might as well tell you bit about my philosophy
that I've come to form over the years.

On Thu, Dec 24, 2020, 19:19 Joshua Scholar  wrote:

> I guess I misunderstood, I thought that your file was all of the header
> files and the runtime placed into one source file so that you could have
> tcc or libtcc be part of a project and make the product/or tcc  be a single
> executable that doesn't need directories.
> ie. without needing link files for the run time and without needing a
> directory tree of include files, (or the same for a program using libtcc
> internally).
>
> But this is just another way of BUILDING tcc.
>
> I wanted a project that USES libtcc without needing a directory of
> standard includes and without needing lib files - ie a single file
> product.  I wanted to USE libtcc, I didn't want a project that that BUILDS
> tcc.
>
> And since your file starts with a number of standard includes, your file
> doesn't even stop people from needing all of directories of includes, it
> just saves them from needing make? Or this is so that people can use the
> equivalent of libtcc without knowing how to link a library into their own
> program?
>
> So this isn't for making products that use lib tcc, it's for developers
> who hate make and for some strange reason don't want to link?
>
> I don't get it, what sort of meta-product needs to compile tcc over and
> over?
>
> Is this just to save time on running make on your personal project that
> changes tcc?  And the cost of that is that tcc is one huge file?  That
> still doesn't tell me why you smashed tcc's headers into it since you need
> to include tcc compatible versions of the header files anyway.  You don't
> want people to need make, but they'll still need gnu C for the headers?
>
>
>
> Anyway I GOT MY ADDON WORKING, there were just a bunch of typos.
>
> But I'm gonna rewrite it.  Instead of making the embedded directory a zip
> file and adding a bunch of libraries to handle zip files, I'm gonna make it
> a tar file (uncompressed),  write a program that converts a tar file into a
> .c file (so my program won't need an external tar file) and just write c
> code that can make an index into a tar file in memory.
>
> And I'll keep my change to libtcc so that it searches my virtual file
> first.
>
> That will mean that the feature needs minimal changes to the project and
> it will make a compiler that's much faster than a version that reads from a
> compressed archive.
>
> Just add a flag to the make (I have it as -s on the windows bat file make)
> and it will build versions of tcc and libtcc that don't need directories of
> include and libraries.
> There are some things that won't work.  You can't load a dynamic link
> library out of an archive.
>
> But my idea of using libtcc as a jit needs work on exporting the run time,
> I think.  Though I noticed libtcc reading a file ca

Re: [Tinycc-devel] Almost added a feature, but I broke things

[Kyryl Melekhin]

https://raw.githubusercontent.com/kyx0r/klec/master/utils/tinycc.c

on x86_64 linux compile like so gcc tinycc.c -ldl -lpthread
then you can use it like so:

if the project already has something resembling a unity build:
a.out -E file1.c > file2.c

if the project does incremental build:
use cat on every C file in correct order ignore the headers.
cat *.c > file1.c
a.out -E file1.c > file2.c


To better understand how it works I recommend to try it on tcc
code base first. Tcc code actually is layed out in an easy format
despite make forcing the incremental build.
a.out -E tcc.c > tinycc.c
This current version the result should amount to approx 87K loc

Some comments:
1. If the headers in C source are not guarded properly
it will not work, but so will your project not compile also. So
this does not happen. Header exclusion works the same way a compiler
would exclude it.
2. Problem of amalgamation is not as trivial as you think it might be,
because of the nature of how C works your header might be guarded but
you can also have code outside of that guard, in any case my program will
exclude the code properly. Especially that #endif is used to terminate any kind
of preprocessing expression.
3. By default headers with <> (system headers) are not amalgamated.
You can enable that, just read the source code in tcc_preprocess.
This program is powered by strategically placing printfs inside tcc
and some compiler logic changes of the default option -E, so don't try
to use this tcc for anything except what is meant to be.
4. While in most cases the resulting file will compile, some projects might be
weird and still require some manual tweaks and edits. Also you might need
to spend some time to clean the code from extra newlines that might get
created.
5. You can also configure it in source code to instead of processing everything
actually do the preprocess and exclude all the unnecessary junk, so for example
with that tcc source for x64 linux will be about ~35K instead of 87K.

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

Re: [Tinycc-devel] Almost added a feature, but I broke things

[Kyryl Melekhin]

>I figured a lot of people would like, that >libtcc can hold a virtual
read-only file >system, so that you don't actually need to >have an
include, lib and libtcc directory for >a project to use libtcc.

Is that so? I can kind of see where you are coming from, but this is not
the right way to solve it. It creates unnecessary dependency bloat, and
even a lot more headache for anybody willing to take time and read though
that. If you want I can send you my custom amalgamated version of TCC which
is literally 1 c file, does not depend on tcclib, because it has it in it's
source already, all the assembly routines for stuff like alloca, are
written in extended asm syntax and they work. There is no need to run make
to compile, just gcc tinycc.c and some platform flags is enough. You also
don't need to worry about header files, because you can always make your
own, just write extern printf(...) bla bla and it will work. That's
basically how I use tcc, it's so much easier to work with and maintain
especially now that i have wrote a special version of tcc which can
correctly amalgamate any C source code just like compiler sees it, no
assumptions because tcc implements complete preprocessor spec.

On Thu, Dec 24, 2020, 06:29 Joshua Scholar  wrote:

> If anyone who knows this project better than me can help it would be
> wonderful.
>
> I decided to add a feature I figured a lot of people would like, that
> libtcc can hold a virtual read-only file system, so that you don't actually
> need to have an include, lib and libtcc directory for a project to use
> libtcc.
>
> Warning, I'm a windows user, so I'm probably doing this on a different
> system than most of you.
>
> Now that I think about it, my choice to do it by embedding a zip file and
> linking miniunzip and libz in was probably a poor one for efficiency.
> Those parts are working, so I'll leave it alone until I get the bugs I
> caused out, unzipping, buffering the unzipped data every time, allocating
> and deallocating the memory for those buffers and putting a global lock on
> the miniunzip calls waste time, and if people want to use libtcc as
> something like a jit, they probably would prefer the speed to the memory.
>
> Also, and even more convincing, embedding libz and the latest version of
> minizip (which has forked off from libz) into the project and making it
> work on every platform would be a nightmare.
>
> But never mind that for now, my current state is:
> tcc works for making .o files and .a files and the results are byte
> equivalent the previous version - and it doesn't need the directories to
> exist to do it.
>
> But libtcc_test silently fails, and I can't get this version of tcc to
> make exe files and -run doesn't work.
>
> But since I didn't make a visual studio solution file, I'm just working
> off the command line, I haven't been able to use a debugger and I'm lost
> for why everything compiles without complaint and runs without complaint,
> but not everything works.
>
> To get help from the compiler I replaced the int type for posix handles
> with a struct type for a wrapped handle that can read from this virtual
> file system.  Since the types can't be substituted without error, I should
> have caught all the spots where I need to change things.
>
> Joshua Scholar
> ___
> 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

[Kyryl Melekhin]

On Sun, Dec 20, 2020 at 2:03 PM Joshua Scholar  wrote:
> 1) If I've generated some code into a memory buffer and I've retrieved an 
> entry point with tcc_get_symbol, is it safe to call tcc_delete_state before I 
> call the entry point?  Looking at the source code, it looks like 
> tcc_delete_state deletes some things that you don't need at run-time.
>
> 2) If you use TCC_RELOCATE_AUTO, does tcc ever delete that memory for you?  
> Does  tcc_delete_state delete the generated code?  I do realize that if I 
> supply a buffer myself, I have to make it executable myself, but then I can 
> also know that I can delete it.
>
> 3) Does the tcc compiler allocate space for a stack?  Or is it that when you 
> call into code it generated, it uses your current stack? Or is there a 
> difference between tcc_run and just calling a function you got back from 
> tcc_get_symbol, where tcc_run allocates its own stack?
>
> 3 a) I noticed that there's a bounds checking version of alloca, but I 
> couldn't understand it.  Does this imply an answer to my previous question, 
> that TCC DOES allocate its own stack? Generally operating systems expand user 
> stacks as needed, up to a point, so bounds checking a stack doesn't make a 
> lot of sense.
>
> 4) Is it possible to reuse a TCCState? What would it do?  Would it trash the 
> code already generated?  Would it remember symbols from previous compiles?
>
> 5) Is the compiler thread safe?  While it would be surprising, I might as 
> well ask if you can compile multiple sources at once.
>
> 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?
>
> 2)  Is the TCC runtime multithread safe?
> a) And what are the details?  Can I run generated code in multiple threads at 
> once?  Does it use locks for anything?
> 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?
>
> 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?
>
> 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?
>
> 6) Are there any pointers on how to use the built in assembler?
>

I'll do my best to answer these, make sure to reply if any corrections
are necessary.

1. tcc_delete_state is not a thing, you mean tcc_delete? No,
tcc_delete will free everything, if you call it before running
generated code it will crash. But you could free some stuff from
TCCState, just make sure to not call tcc_run_free() if you don't plan
to ever use the state for compiling.

2. TCC_RELOCATE_AUTO means that the TCCState manages the code's
memory, and no, you still have to free it manually by calling
tcc_delete() or tcc_run_free(). The memory pointer is s->runtime_mem

3. No. The program does not create additional stacks. tcc_run creates
a section in memory and calls __init_array_start, just like any normal
C program would when you run it with libc. But because it goes through
the new section init it will allocate the amount of static memory it
needs. So you can expect the static memory to be set 0.

3a Bounds checking code is for debug only, there are special trap
instructions inserted by compiler if you enable it, but it will not
mitigate any program errors, it can detect stackoverflow and report
it, but that's the extent. It also checks the memory sections for
buffer overflows.

4. Yes you can reuse it, but it's not going to be efficient because it
will have to recompile the previous stuff also.

5. I'd say no, a compiler is not thread safe unless you run a TCCState
per thread.

-

1.  Read code in gfunc_prolog gfunc_epilog. But I am confused by this
because x64 only has one calling convention, so I don't understand why
it matters except for i386 really. Windows is like the only exception
that does not follow the abi, but the difference is only register
order. Convention is fastcall

2. There is one semaphore in the code, but all I can tell you is that
it's there for some specific reason which I can't recall

3. No

4. I don't see any problems doing that. Stack memory is generally
thread safe and reentrant.

5. No idea what that means, probably no though

6. Use keywords like asm() or __asm() or __asm__() and only GAS
assembly syntax is supported.

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

Re: [Tinycc-devel] Report - A decying support for Windows 2000 Professional SP4

[Kyryl Melekhin]

Can't you just implement that function (strtoui64) in tcc's source code
instead of using the crt version? Or at least make a dummy function with
this symbol and you should be able to compile.

On Tue, Dec 1, 2020, 08:27 Vladimir Vissoultchev  wrote:

> You are probably trying to run x64 build on x86 version of Win2000
>
>
>
> Even if you test the x86 build with
>
>
>
>c:> build-tcc.bat -t 32 -i c:\tcc1
>
>c:> set path=c:\tcc1;%path%
>
>c:> build-tcc.bat -c tcc -t 32 -i c:\tcc
>
>
>
> . . . you'll find out that it bombs with
>
>
>
> ---
>
> tcc.exe - Entry Point Not Found
>
> ---
>
> The procedure entry point _strtoui64 could not be located in the dynamic
> link library msvcrt.dll.
>
> ---
>
> OK
>
> ---
>
>
>
> . . . which is unfortunately a show-stopper.
>
>
>
> cheers,
>
> 
>
>
>
>
>
> *From:* Tinycc-devel [mailto:tinycc-devel-bounces+wqweto=
> gmail@nongnu.org] *On Behalf Of *Vaidas BoQsc
> *Sent:* Tuesday, December 1, 2020 1:43 PM
> *To:* tinycc-devel@nongnu.org
> *Subject:* [Tinycc-devel] Report - A decying support for Windows 2000
> Professional SP4
>
>
>
> Internet Explorer 5 - unable to open the website.
> The https://bellard.org/tcc/ Website is no longer usable via "http"
> protocol.
>
> Tiny C compiler no longer works: tcc version 0.9.27 (i386 Windows)
> C:\Documents and Settings\Administrator\Desktop\tcc.exe is not a valid
> Win32 application.
> C:\Documents and Settings\Administrator\Desktop\i386-win32-tcc.exe is not
> a valid Win32 application.
>
> The latest Tiny C Compiler built from source of the Git repository: the
> same error.
> C:\Documents and Settings\Administrator\Desktop\tcc.exe is not a valid
> Win32 application.
> C:\Documents and Settings\Administrator\Desktop\i386-win32-tcc.exe is not
> a valid Win32 application.
>
>
>
>
>
> Testing_Tools__
>
> https://archive.org/details/Windows2000ProfessionalSP4
> ___
> 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] Request for "fix float to u64 intrinsics"

[Kyryl Melekhin]

Hello.

I reverted the tests because the same result doesn't apply on every
platform, but as Herman sent me the latest tests results earlier the
patch did not seem to affect anything except x86_64 which is the
intended target.
That's why I'll let the maintainer decide whether he wants to keep
changes or not. I'll fix the formatting later on if first choice, so
that I don't have to revert 2 commits in the latter case.

Thank you,
Kyryl

чт, 17 сент. 2020 г. в 07:04, Herman ten Brugge :
>
> Hello,
>
> Would it be possible to revert:
> fix float to u64 intrinsics
> and:
> add tests for float conversions to u64
>
> until you have a proper fix.
> The reason is that testing new code is much more difficult because test 22 
> fails for most targets.
>
> Regards,
>
> Herman
>
> On 2020-09-12 17:36, Herman ten Brugge wrote:
>
> With 'fix float to u64 intrinsics' removed (original libtcc1.c, tccgen.c, new 
> 22_floating_point.*) the result is:
>
> x86_64 (linux + macos):
> --- 22_floating_point.expect2020-09-11 19:25:02.125152055 +0200
> +++ 22_floating_point.output2020-09-12 17:18:13.870481385 +0200
> @@ -17,6 +17,6 @@
>  3421
>  7855
>  2469
> -18446744073709548195
> -18446744073709543761
> -18446744073709549147
> +3421
> +7855
> +2469
>
> x86_64 (windows), i386 (linux + windows):
> --- 22_floating_point.expect2020-09-11 19:25:04.775174826 +0200
> +++ 22_floating_point.output2020-09-12 17:18:49.234749027 +0200
> @@ -17,6 +17,6 @@
>  3421
>  7855
>  2469
> -18446744073709548195
> -18446744073709543761
> -18446744073709549147
> +4294963875
> +4294959441
> +4294964827
>
> arm, arm64, riscv64:
> --- 22_floating_point.expect2020-09-11 19:49:40.034917990 +0200
> +++ 22_floating_point.output2020-09-12 17:22:27.576366194 +0200
> @@ -17,6 +17,6 @@
>  3421
>  7855
>  2469
> -18446744073709548195
> -18446744073709543761
> -18446744073709549147
> +0
> +0
> +0
>
> The arm64 and risc code do not use libtcc1.c and arm does not use 
> __fixunsxfdi.
> The test code should probably use 'long long' to fix some 3 testcases.
> But the arm and risc can not be fixed in this way.
> The arm and risc code look more correct then the i386/x86_64 code to me.
> But it is still undefined behavior.
>
> Regards,
>
> Herman
>
>
> On 2020-09-12 10:38, Kyryl Melekhin wrote:
>
> Hi Herman,
>
> I've seen that tests fail on i386 and arm,riscv. Thing is, I'm not
> even sure if it's relevant to test this way since we are dealing with
> undefined behavior, so maybe it's not right to expect the same output
> everywhere. Could you run this test again but before the patch? I want
> to see how it behaves on arm. I wanted to test this on my own, on my
> other arm computer but I have some difficulty. I'll get it working
> soon or later but it will take some time.
>
> Thanks.
>
> сб, 12 сент. 2020 г. в 05:52, Herman ten Brugge :
>
> I sent this in a private mail to Kyryl but it probably should also be sent to 
> the list.
>
> After 'add tests for float conversions to u64' I get the following output:
>
> x86_64 (linux + macos): ok
>
> x86_64 (windows), i386 (linux + windows):
> --- 22_floating_point.expect2020-09-11 19:25:04.775174826 +0200
> +++ 22_floating_point.output2020-09-11 20:54:23.583325674 +0200
> @@ -17,6 +17,6 @@
>  3421
>  7855
>  2469
> -18446744073709548195
> -18446744073709543761
> -18446744073709549147
> +4294963875
> +4294959441
> +4294964827
>
> arm, arm64, riscv64:
> --- 22_floating_point.expect2020-09-11 19:49:40.034917990 +0200
> +++ 22_floating_point.output2020-09-11 20:58:33.768829655 +0200
> @@ -17,6 +17,6 @@
>  3421
>  7855
>  2469
> -18446744073709548195
> -18446744073709543761
> -18446744073709549147
> +0
> +0
> +0
>
> The test code only works 2 targets. The other 6 are broken now.
>
> Regards,
>
> Herman
>
> On 2020-09-11 13:11, Kyryl Melekhin wrote:
>
> If this is undefined behavior, then this line is straight up also UB.
> https://repo.or.cz/tinycc.git/blobdiff/55f8963dfab5c543f7f34589d3ef9d3f2da3db14..310e3b428cfd181b51723276e6563b90d670da06:/tccgen.c
> And because that line is UB, then it causes even more bugs down the drain.
> At least if the output for this UB matches what other compilers generate
> some bugs can be eliminated. But what gets me the most is why doesn't
> gcc or clang compiler warn on any of this. Also how come we can't
> represent a 32 bit
> float in a 64 bit number? On x86_64 we sure can. Then you are citing ISO 17
> while we don't even have full support for C11.
>
> пт, 11 сент. 2020 г. в 14:43, Vincent Lefevre :
>
&g

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

[Kyryl Melekhin]

What I mean is, just look at this : https://ibb.co/VWzGSt3

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

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

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

[Kyryl Melekhin]

About formatting, what's the preferred vim setting you use? I looked
through the code and couldn't figure out what it was, it seemed so
inconsistent so I just thought you guys don't care about that.

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

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

Re: [Tinycc-devel] Request for "fix float to u64 intrinsics"

[Kyryl Melekhin]

If this is undefined behavior, then this line is straight up also UB.
https://repo.or.cz/tinycc.git/blobdiff/55f8963dfab5c543f7f34589d3ef9d3f2da3db14..310e3b428cfd181b51723276e6563b90d670da06:/tccgen.c
And because that line is UB, then it causes even more bugs down the drain.
At least if the output for this UB matches what other compilers generate
some bugs can be eliminated. But what gets me the most is why doesn't
gcc or clang compiler warn on any of this. Also how come we can't
represent a 32 bit
float in a 64 bit number? On x86_64 we sure can. Then you are citing ISO 17
while we don't even have full support for C11.

пт, 11 сент. 2020 г. в 14:43, Vincent Lefevre :
>
> On 2020-09-11 10:32:06 +, Kyryl Melekhin wrote:
> > I guess I'll explain the bug here as well.
> > consider this code:
> >
> > float a = -123.987;
> > printf("%lu", (unsigned long int)a);
> >
> > Before the patch output would be 123.
> > After the patch output would be 18446744073709551493.
>
> There's no bug. That's undefined behavior (see ISO C17, 6.3.1.4)
> because -123 is not representable in unsigned long int. So, any
> behavior is correct.
>
> --
> Vincent Lefèvre  - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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

Re: [Tinycc-devel] Request for "fix float to u64 intrinsics"

[Kyryl Melekhin]

Hi Christian,

I completely understand what you mean about potential regressions. If
that is the case
it would be trivial to wrap the code into #ifdef. By the way you
mentioned Aarch64
long double precision, well that will not be a problem because if you
look at existing
source code, function __fixunsxfdi is already wrapped in #ifndef __arm__ so
it's not even used on arm I suppose.

I guess I'll explain the bug here as well.
consider this code:

float a = -123.987;
printf("%lu", (unsigned long int)a);

Before the patch output would be 123.
After the patch output would be 18446744073709551493.

Compare that to what gcc will output for example,
and the correct answer is 18446744073709551493.

Which is exactly what I've fixed here.
I hope that explains.

Kind regards,
Kyryl.

пт, 11 сент. 2020 г. в 03:50, Christian Jullien :
>
> Hi Kyryl,
>
>
>
> First I personally appreciate you want to make tcc even better.
>
> Unfortunately your fixes are unclear about what they fix.
>
> It’s hard to see if they don’t introduce a regression on another platform. 
> For example, long double has not the same precision on x64 or on Aarch64. It 
> easy to make a fix on a plateform that introduces a regression on another.
>
> I understand that you can’t test on all supported platforms but a new test in 
> test suite can help us to understand what was the bug and if your patches fix 
> it on all supported plateforms.
>
> Can you please add an almost complete set of tests that prove that tcc was 
> previously wrong and that now, it fixes them all.
>
> For example, I suggest you add those tests (with a little comment) on 
> 22_floating_point.c
>
>
>
> $ make && make test
>
>
>
> Then I’ll be glad to test it works on all supported platforms.
>
>
>
> Also, as a matter of style, we prefer a space between if and ( in expression 
> like if(SIGN(fl1.l)).
>
> Style with space occurs 4015 times while style w.o. space occurs only 154 
> times.
>
>
>
> Tia
>
>
>
> 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

Re: [Tinycc-devel] Error with today's patches

[Kyryl Melekhin]

Hey Christian Jullien, the patch is only a temporary workaround to get
correct code gen working. Right I have to confront the C standard
to understand if calling __fixunsxfdi on long double to uin64_t
is actually correct. And if we need to fix the code generator to emit
__fixxfdi in this case instead. It looks like tcc always emits __fixunsxfdi
even on non constants. Gcc and Clang always end up keeping the
floats sign, ie on x86_64 cvttss2si instruction is used, which is basically
what __fixxfdi does as well.

What do you think? Should we just make tcc always call __fixxfdi
on every unsigned conversion?

I don't really know how to write tests for this yet, besides I think
there is no need yet. Because the bug is not solved correctly yet.

чт, 10 сент. 2020 г. в 03:58, Christian Jullien :
>
> I know how Herman works and I was sure its patch was Ok (and it is) . The 
> patch made by wanjochan was the culprit. I just reverted his patch until 
> better tested.
>
> On its side, Kyryl patch “looks” Ok. At least it does not break the test 
> suite.
>
> Kyryl can you add the test case in tcc suite so that we can verify your patch 
> works on all supported platforms.
>
>
>
> Christian
>
>
>
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] 
> On Behalf Of ian
> Sent: Wednesday, September 09, 2020 23:57
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] Error with today's patches
>
>
>
> Hi back to all.
>
> I read carefully all of the mailing-list, but I hava add a quick comment, 
> right now.
>
> The main aim of a CVS is to able people to test patches, and concurrent 
> versions.
>
> The target should be to create a fork, and, tests achieved, to merge them to 
> the mob.
>
> Every one HAVE to test their modifications upon EVERY structures (OSes, 
> procs, byte lengthS, and so on) before submitting them, or to leave them in 
> the fork branch before merging
>
> It's a shame that everybody could come and propose modifications, even push 
> them on mob, without a complete review
>
> Really, I do believe that Christian, while working on his own language, is 
> right in many ways You should read him with attention.
>
>
>
> Take care all,  and sorry for this.
>
> ian
>
>
>
> Le 09/09/2020 à 11:44, Christian Jullien a écrit :
>
> macOS:
>
>
>
> …
>
> compiling tcc.c 10 times
>
> (827 ms)
>
>  test3 
>
> tcc: error: undefined symbol '___va_arg'
>
> tcc: error: undefined symbol '_alloca'
>
> make[2]: *** [test3] Error 255
>
>  memtest 
>
>
>
> RPi:
>
> running fib in threads
>
>   1 8 144 5 10946 21 6765 89 55 34 3 377 610 233 987 2 13 4181 2584 1597
>
> (35 ms)
>
> running tcc.c in threads to run fib
>
> tcc: error: undefined symbol '__aeabi_idivmod'
>
> tcc: error: undefined symbol '__aeabi_idivmod'
>
> tcc: error: undefined symbol '__aeabi_idiv'
>
> tcc: error: undefined symbol '__aeabi_uldivmod'
>
> tcc: error: undefined symbol '__aeabi_llsl'
>
> tcc: error: undefined symbol '__aeabi_llsr'
>
> tcc: error: undefined symbol '__aeabi_ul2d'
>
> tcc: error: undefined symbol '__aeabi_d2lz'
>
> tcc: error: undefined symbol '__aeabi_uidivmod'
>
> tcc: error: undefined symbol '__clear_cache'
>
> tcc: error: undefined symbol '__aeabi_uidiv'
>
> tcc: error: undefined symbol '__aeabi_idivmod'
>
> tcc: error: undefined symbol '__aeabi_idiv'
>
> tcc: error: undefined symbol '__aeabi_uldivmod'
>
> tcc: error: undefined symbol '__aeabi_llsl'
>
> tcc: error: undefined symbol '__aeabi_llsr'
>
> tcc: error: undefined symbol '__aeabi_ul2d'
>
> …
>
>
>
>
>
> ___
>
> Tinycc-devel mailing list
>
> Tinycc-devel@nongnu.org
>
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
> --
> -- sibian0...@gmail.com
> -- Développeur compulsif
>
> ___
> 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