Hi,
On Wed, 16 Mar 2016, Assaf Gordon wrote:
> $ git clone git://git.sv.gnu.org/coreutils.git && cd coreutils
> $ ./bootstrap
> $ ./configure --without-selinux CC=tcc
> $ make V=1
Thanks for the report.
> The offending code is a complex struct initialization, perhaps related to
Hi,
On Thu, 24 Mar 2016, Vladimir Vissoultchev wrote:
> Thanks for the effort! Apologies for not finding the time to rollback to
> prev impl, had this on my todo, I swear :-))
No matter; had found a couple of minutes under my desk just now myself ;)
Ciao,
Michael.
Hi,
On Wed, 16 Mar 2016, Steffen Nurpmeso wrote:
> So now with [mob] i face the problem that the "const" attribute
> results in "unknown struct/union/enum" error when used in the way
> i do, the uncommon suffix way, i.e., TYPE ATTRIBUTE PTR/REF NAME,
> as in "char const *myname", rather
Hi,
On Sun, 20 Mar 2016, Phillip McNallen wrote:
> Functions with floating point arguments(in x86-64) don't use the proper
> calling convention.
>
> Float values should be passed in XMM0 - XMM3
>
> double sum(double a, double b) {
> return (a+b);
> }
>
> Generates this:
> mov
Hi,
On Thu, 24 Mar 2016, Steffen Nurpmeso wrote:
|> tcc: x86_64-gen.c:421: load: Assertion `((ft & VT_BTYPE) == VT_IN\
|> T) || ((ft & VT_BTYPE) == VT_LLONG) || ((ft & VT_BTYPE) == VT_PTR\
|> ) || ((ft & VT_BTYPE) == VT_ENUM) || ((ft & VT_BTYPE) == VT_FUNC)\
|> ' failed.
|> /bin/sh:
Hi,
On Sun, 6 Mar 2016, Мельников Алексей wrote:
I hope TCC already has supported some C99 options:
(Online documents "3.2 ISOC99 extensions").
And I have found this options (C99 tokens) was discussed several years ago:
Hi,
On Thu, 3 Mar 2016, Thomas Mertes wrote:
Please replace
I home thet it is possible to fix this bug.
with
I hope that it is possible to fix this bug.
BTW.: Tcc has also problems with negative zero, NaN and pow() (maybe
these are related). As soon as I have a test case for the floating
Hi,
On Sun, 3 Apr 2016, Vladimir Vissoultchev wrote:
Here is the fix that switches off '.' for identifiers when parsing
#defines in .S files.
https://github.com/wqweto/tinycc/commit/2ec8d7068aeed7b83c9d4f30aa686586182b
1c34
This includes an originally failing test with your SRC(y...)
Hi,
On Sun, 24 Apr 2016, Sergey Korshunoff wrote:
As I see this today. For example, I prefer to speed up tccboot kernel
compilation.
A current command to compile is like
tcc -o vmlinux linux/kernel/init.c linux/arch/kernel/head.c ...
With -cheaders[=dDIR] option tcc will precompile headers
Hi,
On Sun, 24 Apr 2016, Edmund Grimley Evans wrote:
The C standard has a somewhat unclear description of how the
preprocessor should work, but there is general agreement about what
was intended, and the general agreement leaves no real option for
alternative behaviour. Therefore, if two
Hi,
On Sun, 24 Apr 2016, Sergey Korshunoff wrote:
I need some switch to allow tcc behave like gcc/pcc in the code:
void vide(void); __asm__("vide: ret");
like
void vide(void); __asm__("globl vide\nvide: ret");
But this is not how GCC behaves:
% cat x.c
void vide(void); __asm__("vide:
Hi,
On Sun, 24 Apr 2016, Sergey Korshunoff wrote:
What to do with 78_vla_label test? May be a tcc switch to skip unused code?
No.
void f1(int argc) {
char test[argc];
if(0)
label:
printf("boom!\n");
if(argc-- == 0)
return;
goto label;
}
This is valid code, while your kernel
Hi,
On Sun, 24 Apr 2016, Sergey Korshunoff wrote:
Hi!
https://github.com/seyko2/tinycc/commit/086ae74b696b7e2a73980bd852516b84251bd553
don't accept 0x123e-3 float format. This allow to compile
tccboot kernel with a macro expansion like
__asm__( "pushl $""0xfe""-256\n\t" );
No, simply fix
Hello David,
On Mon, 18 Apr 2016, David Mertens wrote:
> I have nuked that commit.
Thank you for that. (But you haven't yet committed the revert, right?)
> For time management reasons, my recreational programming goes through a
> distinct email account, one that I hadn't checked since early
Hi,
On Wed, 20 Apr 2016, Sergey Korshunoff wrote:
> > Just checked. I used a hex editor to replace a 0x20 bytes in mem-2.o with
> > 0x04.
> > This helped.
>
> diff --git a/libtcc.c b/libtcc.c
> index 5aebd32..a8e109c 100644
> --- a/libtcc.c
> +++ b/libtcc.c
> @@ -514,7 +514,11 @@ ST_FUNC
Hi,
On Fri, 22 Apr 2016, David Mertens wrote:
Hello Michael,
I committed the revert. Based on what I see at the gitweb for the mob branch
(http://repo.or.cz/tinycc.git/shortlog/refs/heads/mob), it's not there. I
don't see anything between Vlad's commit and the one you pushed an hour ago.
Hi,
On Sat, 23 Apr 2016, Vladimir Vissoultchev wrote:
Rolling hashes have a nice property -- associativity -- i.e. hash(concat(a,
b)) = [hash(a) * TOK_HASH_PRIME^len(b) + hash(b)] in GF(TOK_HASH_SIZE)
What I tried based on this was to pre-hash all of file->buffer and calc hash
on current
Hello,
On Sun, 15 May 2016, Sergey Korshunoff wrote:
.fill problem is not fixed (on i386)
Is the following patch correct?
Yes. Using long was harmless on x86-64 (host), but wrong when the type
of ExprValue->v is actually unsigned. Thanks for tracking this down.
Ciao,
Michael.
Hi,
On Mon, 16 May 2016, Sergey Korshunoff wrote:
With the prev fix I still have a tccboot kernel trap on PCI bus configuration.
What the purpose of the
-ALT(DEF_ASM_OP2(addb, 0x80, 0, OPC_ARITH | OPC_MODRM | OPC_BWLX,
OPT_IM, OPT_EA | OPT_REG))
ALT(DEF_ASM_OP2(addw, 0x83, 0, OPC_ARITH |
Hi,
On Sun, 15 May 2016, Sergey Korshunoff wrote:
The idea of using only tcc headers for lib/* compilation might sound good at
first, but tcc
doesn't provide all standard headers (and shouldn't because it's not a full
toolchain with C
library); it really relies on the existence of
Hi,
On Mon, 16 May 2016, Michael Matz wrote:
Can you somehow find out which file and instruction is the one that's
miscompiled? If you can, please attach the pre-processed source file
here.
That's not needed anymore, I found out myself. There were several
pre-existing errors
Hi,
[request for testing a patch below]
On Sat, 14 May 2016, Sergey Korshunoff wrote:
It might also simply be that your libc headers are incompatible with a 64bit
compilation (e.g. if
you miss any WORDSIZE support from ). In that case we might
have to do
more hackery, but generally it won't
Hello,
On Sat, 14 May 2016, Christian Jullien wrote:
F:\tinycc\win64>.\tcc -DTCC_TARGET_PE -DTCC_TARGET_X86_64 -c
../lib/alloca86_64.S
../lib/alloca86_64.S:15: error: bad operand with opcode 'and'
You weren't using the most recent [mob] branch. The above problem was
fixed in 4f27e21 late
Hi,
[I'm currently having problems getting mails through to the GNU mail
server, sorry if you get this multiple times]
On Fri, 13 May 2016, Sergey Korshunoff wrote:
I have the following patches in github repo (requests in tinycc bugzilla):
+ memory model macros __{L,}LP64__
Hello,
[Sorry if you get this multiple times, the eggs.gnu.org mail server currently
has issues accepting mails from my normal provider]
On Fri, 13 May 2016, Sergey Korshunoff wrote:
> Is this change must be for x86_64 only?
Well, strictly speaking 64bit immediates are x86-64 only of
Hi,
On Tue, 3 May 2016, Sergey Korshunoff wrote:
Fixed in mob, plus some more asm bugs (32 and 64 bit).
ALT(DEF_ASM_OP1(lcall, 0xff, 3, OPC_MODRM, OPT_EA))1) or
ALT(DEF_ASM_OP1(lcall, 0xff, 3, OPC_MODRM, OPT_INDIR))2) ?
The first one. Look at the handling of OPT_INDIR, it's a
Hi,
On Mon, 2 May 2016, Michael Matz wrote:
ALT(DEF_ASM_OP2(lcall, 0x9a, 0, 0, OPT_IM16, OPT_IM32))
-ALT(DEF_ASM_OP1(lcall, 0xff, 3, 0, OPT_EA))
+ALT(DEF_ASM_OP1(lcall, 0xff1f, 3, 0, OPT_EA))
ALT(DEF_ASM_OP2(ljmp, 0xea, 0, 0, OPT_IM16, OPT_IM32))
ALT(DEF_ASM_OP1(ljmp, 0xff, 5, 0, OPT_EA
Hi,
On Sun, 1 May 2016, Sergey Korshunoff wrote:
diff --git a/i386-asm.h b/i386-asm.h
index 486cffe..637568b 100644
--- a/i386-asm.h
+++ b/i386-asm.h
@@ -213,7 +213,7 @@ ALT(DEF_ASM_OP1(jmp, 0xff, 0, OPC_JMP | OPC_WL, OPT_REGW))
#endif
.
ALT(DEF_ASM_OP2(lcall, 0x9a, 0, 0, OPT_IM16, OPT_IM32))
Hi,
On Tue, 3 May 2016, Michael Matz wrote:
Not really. It does work-around the above problem, but at the expense
of not using the one-byte opcode 0x90+reg anymore, even if possible.
Generally the opcode in i386-asm.h are sorted by some sort of preference
(e.g. first the one-byte opcodes
Hi,
On Wed, 4 May 2016, Edmund Grimley Evans wrote:
Proposed patch attached. Proposed log message:
Insert spaces between certain tokens when tcc is invoked with -E.
Insert a space when it is required to prevent mistokenisation of
the output, and also in a few cases where it is not
Hi,
On Thu, 5 May 2016, David Mertens wrote:
wtf is this? Commit fe845cf is huge, and looks like it's messing with a
lot. You may know what you're doing, but onlookers will observe your
behavior and think, "Oh, it's OK if I push a huge, opinionated changeset
to mob without discussion." I
Hi,
On Mon, 2 May 2016, Sergey Korshunoff wrote:
The mod/rm byte was simply missing from the encoding. I've corrected
this in mob.
can you post a diff? I don't see any patch in the [mob]
Meh, forgot to push. Should be in now.
Ciao,
Michael.
Hi,
On Mon, 2 May 2016, Sergey Korshunoff wrote:
A right constant value was detected by comparing *.o produced by gcc and
tcc (objdump -Dtsr test.o)
You realize that you can't simply copy random bytes around without
understanding the instruction encoding, right? You took one specific
Hi,
On Fri, 15 Apr 2016, Sergey Korshunoff wrote:
> ./configure --enable-cross
> make
> cc -o arm64-tcc tcc.c -DONE_SOURCE -DTCC_TARGET_ARM64 -I. -Wall -g -O0 \
> -Wdeclaration-after-statement -Wno-deprecated-decl arations
> -Wno-strict-aliasing \
> -Wno-sign-compare -Wno-uninitialized
Hi,
On Thu, 14 Apr 2016, Vladimir Vissoultchev wrote:
> > Which compiler are you used?
> > #if PATHCMP==stricmp
> >strupr(buf1);
> > #endif
>
> I'm using tinycc to compile this... Kidding :-)) Here it is:
>
> C:\Users\wqw>gcc --version
> gcc (i686-win32-dwarf-rev0, Built
Hi,
On Thu, 14 Apr 2016, Vladimir Vissoultchev wrote:
> Unless the body of the function is single __asm__ instruction for
> instance.
>
> I was thinking about a simple C subset parser that produces AST of the
> inline if sucessful.
tinycc has no AST. I don't think what you want is in scope
Hi,
On Mon, 18 Apr 2016, Vladimir Vissoultchev wrote:
'#if PATHCMP==stricmp' doesn't do what you want anyway. The preprocessor
== can't
compare strings, so the above is always true (because no matter if PATHCMP
is
defined to stricmp or not defined it evaluates to zero, and as stricmp is
Hi,
On Mon, 18 Apr 2016, Sergey Korshunoff wrote:
Gosh, and you even put the exsymtab stuff into [mob] now. Without discussion
http://lists.nongnu.org/archive/html/tinycc-devel/2015-05/threads.html
(David Martens)
Yes, I know exsymtab, I was there when you both talked about it. In
Hi,
On Tue, 19 Apr 2016, Sergey Korshunoff wrote:
> > Probably on PARSE_FLAG_ASM_FILE would be better to leave single dots as tok
> = '.' -- that is when next char is not IS_ID it will not become a symbol on
> its own.
>
> A patch for the asm .rept/.endr directives
>
Hi,
On Sat, 16 Apr 2016, Vladimir Vissoultchev wrote:
Ok, so the portable way is to loop the string and call `toupper`
probably inside the #ifdef?
Something like that. Of course that breaks when e.g. the strings are
utf-8 encoded. I simply wouldn't bother to do that portably right now.
Hi,
On Sat, 16 Apr 2016, u-tcc-u...@aetey.se wrote:
So, the implementation of __clear_cache (and only it!) needs to be
provided by tcc itself, but only when compiling with pcc. I.e. some
file
__clear_cache() or the lack of it is not pcc-specific at all, actually
it is gcc-specific by
Hi,
On Sun, 17 Apr 2016, Michael Matz wrote:
Can try to extract this
Sorry, reading a comment: no op now (a patch attached)
This is just silly. Put
#define __builtin_expect(a,b) (a)
anywhere and you're done. No need for support in the compiler.
Argh! And now you put in this thing
Hi,
On Sat, 16 Apr 2016, Sergey Korshunoff wrote:
Can try to extract this
Sorry, reading a comment: no op now (a patch attached)
This is just silly. Put
#define __builtin_expect(a,b) (a)
anywhere and you're done. No need for support in the compiler.
Ciao,
Michael.
Hi,
On Fri, 15 Apr 2016, Christian Jullien wrote:
I wonder if s.o ever tried to compile tcc with gcc and then use
kcachegrind on some big project compiled with tcc to see what tcc areas
can/must be optimized?
Yes, I did in the past. Not surprisingly it's malloc/free overhead and
character
Hi,
On Fri, 8 Apr 2016, Vladimir Vissoultchev wrote:
> How would you implement intrinsic functions in tcc?
I wouldn't except for those that really need compiler support (which are
very few). This is supposed to be a tiny CC, remember, with one goal
being C99 compatible (if we ever get
Hi,
On Wed, 13 Apr 2016, Sergey Korshunoff wrote:
> > I can see that for inlines there is a separate `InlineFunc` struct
> > that keeps function body until end of generation when in
> > `gen_inline_functions` only the referenced inlines are generated as
> > regular functions.
>
> Then we can
Hi,
On Thu, 14 Apr 2016, Sergey Korshunoff wrote:
> #if 0
> .rept NR_syscalls-(.-sys_call_table)/4
> <--><-->.long SYMBOL_NAME(sys_ni_syscall)
> <-->.endr
> #else
> .long SYMBOL_NAME(sys_ni_syscall)
> .long SYMBOL_NAME(sys_ni_syscall)
> .long
Hi,
On Sun, 10 Jul 2016, Michael Matz wrote:
TCC's handling of variable argument lists are spelled out in stdarg.h,
with implementation in libtcc1.c. I think that for 64-bit machines, we
should also check for clang, and then use clang-compatible definitions.
Oh, I forgot to expand here
Hi,
On Tue, 2 Aug 2016, David Mertens wrote:
Unless I hear opposition, I'll push a fix to mob some time tomorrow.
Also, for similar reasons, it appears that including "#define
_VA_LIST_DECLARED" might help make BSD (or at least FreeBSD) happy. I am
currently testing this. Does anybody have
Hi,
On Fri, 20 Jan 2017, Markus Reichelt wrote:
Aloha,
http://repology.org/metapackage/tcc/versions
shows tinycc 0.9.27 as the latest version available for deb unstable
& ubuntu zesty
I didn't know about that repology site at first but I've been bugged to
update to 0.9.27 as well (I deal
Hi,
On Mon, 20 Feb 2017, grischka wrote:
The good news: we got debug line output with asm to create
mixed output as below.
Yeah, noticed that. Nice :)
p0:
movslq %eax, %rcx
0:48 rex.W
1:48 63 c8movslq %eax,%rcx
mov $0x12345678,%eax
Hi,
On Sat, 11 Feb 2017, Michael Matz wrote:
Your commit:
http://repo.or.cz/tinycc.git/blobdiff/cd9514abc4f4d7d90acce108b98ea2af58a1b8
0a..77d7ea04acb56f839031993c102366e30cad5c25:/tests/tests2/Makefile
Is the source of this error
Well, that means it uncovered a pre-existing bug
Hi,
On Fri, 10 Feb 2017, grischka wrote:
FYI, GCC 6 behaves in the same way with -std=c89, -std=c99 and -std=c11.
Ditto for Clang 3.9.
I wouldn't really mind if we change the behavior.
I think we should. If still for 0.9.27 I don't know. It's a subtle
change breaking stuff in strange
Hi
On Sat, 11 Feb 2017, Christian Jullien wrote:
Michael,
Your commit:
http://repo.or.cz/tinycc.git/blobdiff/cd9514abc4f4d7d90acce108b98ea2af58a1b8
0a..77d7ea04acb56f839031993c102366e30cad5c25:/tests/tests2/Makefile
Is the source of this error
Well, that means it uncovered a
om: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Michael Matz
Sent: samedi 11 février 2017 14:34
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Ready for Release 0.9.27
Hi,
On Sat, 11 Feb 2017, Michael Matz wrote:
Your commit:
http://repo.or.cz/
Hi grischka,
On Sat, 1 Oct 2016, grischka wrote:
I did push some cleanups to prepare for a release 0.9.27, eventually.
Just if you wonder what's the point of that.
I wonder about only one change:
6d2be31b93 test/pp: cleanup
There you removed tests/pp/15.{c,expect} and changed
Hi,
On Tue, 27 Sep 2016, Jean-Claude Beaudoin wrote:
> Hello TCC devs,
>
> I am starting an effort to implement -fPIC support for real in TCC.
> The target is to have TCC generate full fledged shared libraries
> on ELF platforms.
For which architectures? For x86_64 that's already implemented.
Hi,
On Mon, 3 Oct 2016, Christian JULLIEN wrote:
On RPI, for monthes now, I have this error:
jullien@sims3:~/tinycc/tests/pp $ ../../tcc -E -P 13.S >13.output 2>&1 ;
diff -Nu -b -B -I "^#" ../../tests/pp/13.expect 13.output
--- ../../tests/pp/13.expect 2016-10-03 13:15:02.292455721
Hi,
On Mon, 3 Oct 2016, grischka wrote:
Ok, have seen it: crash in "make test".
I did something different now. It's not nice but maybe works. It would
just run a second pass in copy_params to reload registers that have been
saved on stack by accident.
Hi,
On Tue, 8 Nov 2016, Steffen Nurpmeso wrote:
> (gdb) run
> Starting program:
> /home/steffen/usr-wales-arch-linux-x86_64/opt/tcc-mob/bin/tcc
> -Wl,-rpath=/home/steffen/usr/lib -Wl,-rpath=/home/steffen/usr/opt/tcc-mob/lib
> -Wl,-rpath=/home/steffen/usr/opt/pcc/lib -Wl,-rpath=/lib
>
Hello,
On Mon, 7 Nov 2016, Thomas Stalder wrote:
> I have tested with latests TinyCC git commit and sometimes i have the error
> (with DEBUG_RELOC) :
>
> reloc 1: x=0xfe val=0x1eddc newx=0xfdaf7d70 name=printf
> tcc: error: can't relocate value at 2527064,1
Out of range jump because no
Hi,
On Wed, 9 Nov 2016, Steffen Nurpmeso wrote:
> Hello.
>
> Michael Matz <matz@frakked.de> wrote:
> |On Tue, 8 Nov 2016, Steffen Nurpmeso wrote:
> ...
> |> cc': corrupted double-linked list: 0x0065c0f0 ***
> |
> |Something in tcc is probabl
Hi,
On Thu, 10 Nov 2016, Steffen Nurpmeso wrote:
> Hallo.
>
> |The attached diff fixes the issue for me.
>
> One more.
diff --git a/tccgen.c b/tccgen.c
index fdd8654..00a26c5 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -6523,11 +6523,13 @@ static void gen_inline_functions(TCCState *s)
Hi,
On Tue, 11 Oct 2016, Edmund Grimley Evans wrote:
> Me:
>
> > That's interesting. Perhaps that could be extended to AArch64 instead
> > of using the ugly work-around...
>
> I've pushed my work-around as I'm not sure when I'll be able to
> investigate the linker...
Just for the benefit of
Hi,
On Tue, 11 Oct 2016, Chen, Xianwen wrote:
> In file included from Bessel_Function.c:1:
> In file included from C:/cygwin64/usr/include//stdio.h:60:
> In file included from C:/cygwin64/usr/include//sys/reent.h:15:
> C:/cygwin64/usr/include//sys/_types.h:168: error: ',' expected (got "__wch")
makes us compile the linux x86-64
kernel.
Ciao,
Michael.
commit 70a1dc38908b6ff679f15cf033828afda885d35f
Author: Michael Matz <m...@suse.de>
Date: Wed Jun 29 18:06:40 2016 +0200
inline asm: Fix 'm' constraints
See testcase. The m constraint actually passes the address
and hence is of pointer
Hello Christian,
On Wed, 19 Oct 2016, Christian Jullien wrote:
> x86_64:
> $ uname -m
> amd64
> $ gcc --print-file-name=crt1.o
> /usr/lib/crt1.o
> $ find /usr -name crt1.o
> /usr/lib32/crt1.o
> /usr/lib/crt1.o
Aha! So they chose the opposite way to the linuxes. Okay, that helps,
thanks. Can
Hi,
On Tue, 18 Oct 2016, grischka wrote:
> Honestly, in my book the cross compilers are just to test
> compilation, they are not assumed to work out of the box.
> (Except the windows compiles where everything you need comes
> with the source and therefor is well known where it is).
I generally
Hi,
On Tue, 18 Oct 2016, David Mertens wrote:
> According to Christian, we have at least one major compiler (VC++) whose
> behavior matches tcc's current behavior and another (GCC) whose behavior
> differs.
Yes, I've implemented the GCC way privately already (necessary for e.g.
linux kernel).
Hi,
On Tue, 18 Oct 2016, Michael Matz wrote:
> But not on linux-x86-64 anymore :-/ I think trying to fix things for a
> system one doesn't have access to is futile. FWIW, your recent patch did,
> amongst other things:
>
> #ifndef CONFIG_LDDIR
> -# ifdef TCC_TARGET_X8
Hi,
On Tue, 18 Oct 2016, avih wrote:
> Some time ago I also bumped into the lib64 issue, which was apparent
> when building cross compilers on a 64 system which doesn't use lib64,
> e.g. Ubuntu 64. At the time I wrote a patch (which I didn't submit to
> mob) which decides only at one place
Hi,
On Tue, 18 Oct 2016, grischka wrote:
> Christian Jullien wrote:
> > Get worse as it now core dumps ...
>
> At least it seems to find the crt*.o now.
But not on linux-x86-64 anymore :-/ I think trying to fix things for a
system one doesn't have access to is futile. FWIW, your recent
Hi,
On Thu, 20 Oct 2016, David Mertens wrote:
> > For instance, this is wrong for PCC layout. MS layout indeed switches
> > storage containers when the base type changes, i.e. here:
> >
> > struct S {
> > char c:1;
> > short s:1;
> > char foo;
> > };
> >
> > PCC layout has no such
to:tinycc-devel-bounces+eligis=orange...@nongnu.org]
> On Behalf Of Michael Matz
> Sent: jeudi 20 octobre 2016 17:23
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] core dump on FreeBSD with last commit
> "configure: --triplet= option, Makefile: cleanup"
>
> He
Hi,
On Mon, 10 Oct 2016, grischka wrote:
> In general, often when I see people adding tests I think: "Well you
> just fixed that, what's the point? I'd rather see what's still broken."
The point of course is to not break things ever again, after somebody got
to the length of fixing
Hi,
On Sat, 15 Oct 2016, David Mertens wrote:
Ah, now I get errors running the preprocessor tests. Here's a representative
result:
PPTest 14 ...
--- 14.expect 2016-10-15 13:07:53.790016538 -0400
+++ 14.output 2016-10-15 22:36:25.971293975 -0400
@@ -1,3 +1,8 @@
+
return Z(Z(1,2),2);
+
Hi,
On Sat, 15 Oct 2016, grischka wrote:
Christian Jullien wrote:
Ok,
The point is that it compiles ROOTB but then a single line program using
only ISO include and std C library fails because of __aligned in a
**system** header.
I agree that __aligned is a probably a macro or a gcc FreeBSD
Hello,
On Sat, 15 Oct 2016, David Mertens wrote:
This commit:
0a624782dfc8fee6f0600066b135d3b20e4274f4
causes "make test" to fail on my 64-bit Linux (ubuntu 16.04). Any idea of
what's going on? Below is the output of "make" followed by "make test".
$ make test
../tcc -B.. -I/include -I -I..
Hi grischka,
commit b69158578 "tccgen: arm/i386: save_reg_upstack" miscompiles tccboot.
It ultimately boils down to this routine:
% cat bug.c
#define APIC_DIVISOR 16
#define HZ 1000
extern long getl();
extern unsigned long long getull();
extern void printk(const char *, ...);
int
Hi,
On Sun, 16 Oct 2016, avih wrote:
Overall, I'd vote to move tinycc to github, with the caveat that it'd be
nice to also have an external archive of all the discussions, issues,
reviews, etc.
You can't "move" tinycc anyway. If people want to start using github:
more power to them,
Hi,
On Mon, 17 Oct 2016, Michael Matz wrote:
Now, I do agree that we'd want to add a work around for this in tcc. I
think a better work-around than defining __GNUC__ is to define the above
macros instead. __GNUC__ simply has quite some side-effects. (E.g.
after the patch you can't compile
Hi,
On Sun, 16 Oct 2016, Chen, Xianwen wrote:
I'm using the latest release, but not the latest version as of the
source code. Are you suggesting me to compile tcc itself from source
codes?
Yes.
Ciao,
Michael.
___
Tinycc-devel mailing list
Hi,
On Sun, 16 Oct 2016, Christian Jullien wrote:
Ok Michael,
It is defined in sys/cdefs.h as:
#if __GNUC_PREREQ__(2, 7) || defined(__INTEL_COMPILER)
#define __dead2 __attribute__((__noreturn__))
#define __pure2 __attribute__((__const__))
#define __unused
Hi,
On Mon, 10 Oct 2016, Christian JULLIEN wrote:
> The problem is perhaps different:
> ./tcc -B. -Iinclude -I. -run tests/tcctest.c
> Compiles and works well. This one ic compiled with GCC
>
> I get this issue only with:
> ../tcc -B.. -I../include -I.. -I.. -DTCC_TARGET_I386 -DONE_SOURCE -run
Hi,
On Tue, 11 Oct 2016, Edmund Grimley Evans wrote:
> Could someone please take a look at this warning?
Yeah, fixed.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Hi,
On Fri, 16 Dec 2016, Christian JULLIEN wrote:
> With latest commit commitcd9514abc4f4d7d90acce108b98ea2af58a1b80a
> I have been able to make a working tcc on:
> * Windows 10 i386 + x64 - using my own Makefile (and not .bat)
> * Raspberry Pi3 (ARM)
>
> The 3 versions successbuly built my
Hi,
On Thu, 15 Dec 2016, grischka wrote:
> Michael Matz wrote:
> > * simple dead code optimization: in code like if (1) ...
> > else {stuff};
> > don't emit anything for the else branch code (unless there's a different
> > way to enter this code, e.g. via
Hi,
On Sat, 17 Dec 2016, Thomas Preud'homme wrote:
Some recent change between bf692af3 (from 2016-11-12) and fe6453f8 (from
2016-12-10) broke gawk (on x86-64), and that fail still exists with my
changes on the top; I haven't investigated that yet, but it's mostly
changes for separating out
Hi,
On Fri, 16 Dec 2016, grischka wrote:
Therfor before we change assumptions (which we clearly do as soon as we
start to use 'nocode_wanted' for optimization purposes) I'd really like
to see the below working under all tests and everything except fire in
the computer:
ST_FUNC void
Hi,
On Sun, 18 Dec 2016, Michael Matz wrote:
Yes, the changes on that didn't really help. I'll need some more time to
really digest the changes (to which I generally agree) but at the outset it
looks like it contains some confusion (e.g. a R_X86_64_64 relocation does
_not_ normally need
Hello,
On Sun, 18 Dec 2016, grischka wrote:
Ok, I guess the best we can do to make sure the assert of above
will never trigger is to tell the compiler to optimize it out,
like so:
ST_FUNC void g(int c)
{
int ind1;
if (nocode_wanted)
return;
if
Hi,
On Tue, 28 Mar 2017, Andrei E. Warkentin wrote:
> Dear tinycc-devel,
>
> Found your mailing list today looking for macOS support for TCC. I have
> some good news, in the form of a patch that enables '-run' mode and a patch
> consisting of clang warning fixes. This should allow for further
Hello,
On Thu, 13 Apr 2017, Andrei E. Warkentin wrote:
How does the merge process work for tinycc? Anything you want from my
end?
I used imprecise language. When I said "merge" I meant "push to mob".
See http://repo.or.cz/tinycc.git, in particular the section "mob" of the
repository
Hey grischka,
some of my patches interact with $subject, and I have difficulties to
determine what the purpose of that commit was. The comments ("to avoid
precision loss" (... when converting to int)) don't really clarify much.
I also can't find testcases (on x86-64) where the commit
Hi,
On Wed, 12 Apr 2017, Patrick Pelissier wrote:
I think I found a bug in the preprocessor of tcc.
You're right, thanks for the report. Fixed with
http://repo.or.cz/tinycc.git/commitdiff/328b826e
Ciao,
Michael.
___
Tinycc-devel mailing list
Hi,
On Sun, 12 Mar 2017, Tony Robinson wrote:
Very sorry for newbie questions but I'm looking for C compiler for a
processor that I've been very slowly building as a hobby. The
instruction set is super simple (Rz = Rx op Ry for op in ADD, SUB, AND,
OR, XOR, ASR plus basic
Hi,
On Wed, 5 Jul 2017, Patrick Pelissier wrote:
I think I found an issue in the preprocessor of tcc.The following program:
[...]
TEST3((INIT(KO)))// ==> expect ok, get "error: macro 'KO' used
with too many args"
produces an error "error: macro 'KO' used with too many args"
Yikes!
Hi,
On Mon, 3 Jul 2017, Barath Aron wrote:
I vote for __COUNTER__ as well. Some macro-libraries of mine also use
it. :)
Implemented in mob 824dceb. Wasn't totally trivial because our way of
expanding macro arguments wasn't like the standard requires but only in a
way noticable with macros
Hi,
On Tue, 25 Jul 2017, grischka wrote:
uso ewin wrote:
I guess ptrdiff_t should indeed be a long int, but ssize_t should be an
int,
same for intptr_t and uintptr_t should be an unsigned int.
gcc 6.3.0 on win32 (32bits):
test.c:9:14: error: '_Generic' selector of type 'int' is not
Hi,
On Sun, 23 Jul 2017, grischka wrote:
As to
static int counter;
Michael, what can I do to convince you that static locals are most
likely always not a good idea in (lib)tcc ;)
You mean because it's not reset to zero for multiple files and for usage
of tcc as library? You've
101 - 200 of 514 matches
Mail list logo
