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.
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
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.
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
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,
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
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
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() {
>
"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.
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
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
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
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
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
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
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
ou 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 called "msvcrt.def", so
> maybe it's doing something clever and reusing the runtime libr
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
>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
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
>
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
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.
>
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 yo
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
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", (
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
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
27 matches
Mail list logo
