Hello Henry,
I personally vote for a unique binary and multiple 32/64 libs that can
generate either 32 or 64 bit using -m32/-m64 flag with -m32 mode be the
default.
The binary itself can be 32 or 64 bit. (i.e. the 32bit tcc version accepts
-m64 as well).
The main difficulty I see for the 32bit
In fact both gcc and tcc are correct because your snippet uses an undefined
behavior.
a==a compares the address of two strings which are the address of the
first character, not the character itself as you said.
Now, which one is correct? None or both.
A litteral string is supposed to be
foo.c:
#include stddef.h
static void foo(size_t);
#include time.h
// after time.h is included, size_t is not of the same type
static void foo(size_t unused) {}
tcc foo.c
foo.c:4: error: incompatible types for redefinition of 'foo'
Changing by:
#ifndef _SIZE_T_DEFINED
time.h: 4
after time.h: 8
It means that __SIZE_TYPE__ is not correctly defined for 64bit
#ifdef TCC_TARGET_X86_64
tcc_define_symbol(s, __SIZE_TYPE__, unsigned long long);
#else
tcc_define_symbol(s, __SIZE_TYPE__, unsigned long);
#endif
_
From: Christian Jullien
On my system, I have two tcc, one for i386 and one x64_86 but
tcc -v only reports
tcc version 0.9.25
I think it should at least report the backend processor it generates code
for.
tcc version 0.9.25 for i386
tcc version 0.9.25 for x86_64
Or, as gcc if you like
tcc version 0.9.25
Target: i386
}
You may also want to add more valuable details like constants from config.h
(PE, COFF, ...)
Christian
-Original Message-
From: tinycc-devel-bounces+eligis=wanadoo...@nongnu.org
[mailto:tinycc-devel-bounces+eligis=wanadoo...@nongnu.org] On Behalf Of
Christian Jullien
Sent: dimanche 20
19:33
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Wrong __int64 computation
Christian Jullien wrote:
In fact it was related to unsigned __int64 not signed __int64
The following patch modeled after TOK_DIV in x86_64-gen fixes, at least
for
my case, this issue.
Yes, almost
Well, this not really a tcc bug but a MS one.
When you compile with tcc 64bit on Windows, difftime compiles to difftime64
which is sometime missing form msvcrt.dll (it seems that msvcrt.dll from
WS2005 has this issue which looks to be fixed in WS2008).
For me,
#if defined( __TINYC__ )
Simple example not working on Windows x64. It should print Ok but hangs even
buf seems to be correctly aligned.
#include stdio.h
#include stdlib.h
#include setjmp.h
int
main(int argc, char *argv[])
{
jmp_buf buf;
if (setjmp(buf) == 0) {
printf(ready to jump at
-
From: tinycc-devel-bounces+eligis=wanadoo...@nongnu.org
[mailto:tinycc-devel-bounces+eligis=wanadoo...@nongnu.org] On Behalf Of
Christian Jullien
Sent: mardi 8 décembre 2009 08:56
To: tinycc-devel@nongnu.org
Subject: RE: [Tinycc-devel] 64bits - Wrong comparison betweenpointerandlong
cste
Update
Change
http://repo.or.cz/w/tinycc.git/commitdiff/dd70d19267ac343adae7bf15fe15c08fa6
04e5e1?hp=5dadff3de553b0dae46cca233c751ed8b6853da4
Is exactly what I proposed few months ago.
You probably may want to notify
mailto:predef-contrib...@lists.sourceforge.net
to update
7 décembre 2009 15:55
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] 64bits - Wrong comparison between pointer
andlong cste
Christian Jullien wrote:
Q. how can I see the .s output (as generally using -S on most compilers) ?
TCC outputs machine code, not assembler.
You can disassemble
-bounces+eligis=wanadoo...@nongnu.org] On Behalf Of
grischka
Sent: jeudi 3 décembre 2009 19:15
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] jmp_buf align problem on win64
ketmar wrote:
On Thu, 3 Dec 2009 16:42:45 +0100
Christian Jullien eli...@wanadoo.fr wrote:
I'm using headers from
Hi all,
Today I managed to try tcc on win64 (i.e. tcc generates 64bit .exe)
I bootstrapped tcc with a recent gcc win64 and got a workable tcc that
compiles my OpenLisp quietly (www.eligis.com). It eventually runs but
crashes depending on jmp_buf stack alignment. Very often, I found that
64bits
I also read your paper.
I'm reluctant to any C extension. If you think C lacks features (it does)
push your ideas to ISO committee and let it be in the next standard
revision. I have software (OpenLisp) that runs on so many compilers and
systems that I long stop to count ( 100).
Any extension
If tcc is supposed to compile ISO C, it is right to complain.
If tcc wants to compile all what gcc compiles it has to support all gcc
extensions as the one you're using with this sample.
IMHO a compiler should compile all valid code as determined by a standard
(in our case different published
that it is
better to use a define like that.
It is much better to use something more modern,
more human-readable, as TCC has now.
If the programs have difficulty reading something
in that format, change the programs, don't try to
change the human beings.
Regards,
Anton.
Christian Jullien wrote
: Re: Versioning (was Re: [Tinycc-devel] TCC 0.9.25 is out)
Christian Jullien eli...@wanadoo.fr wrote:
(22/05/2009 11:16)
Anton,
It's ok to have a TCC_VERSION human readable but it's also *very* important
to have computer readable cste to adapt code depending on a specific
version
if you
@nongnu.org
Subject: [Tinycc-devel] Re: Versioning
lostgallifreyan lostgallifre...@gmail.com writes:
Christian Jullien eli...@wanadoo.fr wrote:
#elif (__TINYC__ = 926 || __TINYC__ = 928)
If an arithmetical comparison is to be made, why not first treat the
value as a string then strip out all
MS cl forces C with -Tc and C++ with -Tp
/Tpsource file compile file as .cpp /TC compile all files as .c
i.e.
cl -Tc foo.BASIC
compiles as C provided that foo.BASIC contains C code.
You can use the same kind of option.
M2c
Christian
-Original Message-
From:
Christian Jullien wrote:
I think you're right.
Bug occurs when int (0x) is promoted to long long
(0x). Then right shift and back to int conversion returns
a
false result.
Another possible fix is to cast to (unsigned int) as with
if (t1 == VT_LLONG) {
l1 = v1-c.ll
-bounces+eligis=wanadoo...@nongnu.org
[mailto:tinycc-devel-bounces+eligis=wanadoo...@nongnu.org] On Behalf Of
grischka
Sent: Tuesday, December 30, 2008 17:33
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] wrong preprocessor shift operation
Christian Jullien wrote:
Many thanks, I tested
@nongnu.org
Subject: Re: [Tinycc-devel] wrong preprocessor shift operation
On Tue, Dec 30, 2008 at 05:32:57PM +0100, grischka wrote:
Christian Jullien wrote:
printf(fails %08x\n, (~0) 1);
fails
Maybe gcc is not correct but then I need an exact explanation why ;)
0 has type int
From: tinycc-devel-bounces+eligis=wanadoo...@nongnu.org
[mailto:tinycc-devel-bounces+eligis=wanadoo...@nongnu.org] On Behalf Of
Christian Jullien
Sent: Sunday, December 28, 2008 9:26
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] wrong preprocessor shift operation
Hello team,
Simple
801 - 824 of 824 matches
Mail list logo
