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 ab
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.
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 n
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, w
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
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
inli
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(
"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 co
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
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
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
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 a
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 com
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 sim
I started to like using mailx for emails recently.
It seems to be the most minimal email client
that is easy to hack on in C. The learning curve
might be too steep for an average but in the end
it always ends up paying off in the long term.
Mutt probably will take a 2nd place in terms of
minimalis
rsions 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 thi
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 solve
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
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 x8
t; +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
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
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-pushi
e 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;
> > print
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 __fix
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 inste
28 matches
Mail list logo
