, Pathscale, ...
compiler) code).
Using -fheinous-gnu-extensions for clang makes sense but I still
don't see how GCC_MAJOR may be set even is $CC not realy gcc???
Thanks,
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https
with just one
variable, on 1Mbit bus sized processors. ;)
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
what now you actually
did.
Unless that is sufficiently clear already from your commits and
commit comments in which case please just ignore this message.
Thanks,
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https
- to change our tinycc code's license from LGPL
to a BSD-like one (such as below).
Please discuss.
--- grischka
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without
Daniel Glöckner wrote:
On Tue, Apr 30, 2013 at 05:43:03PM +0200, Thomas Preud'homme wrote:
As I already said privately, I'm fine with BSD-2-clause.
Does that mean you prefer it over the LGPL?
What about you, grischka? Which one do you prefer?
I don't have a preference yet (and even if I
, also.
Thanks,
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
)
In my version (tcc version 0.9.26 (i386 Win32)) in Win7-64 it crashes.
Should work now:
http://repo.or.cz/w/tinycc.git/commitdiff/69c2e7f96c95ba088657ce8bb9754c12c3e89397
Thanks,
--- grischka
I was hit by this, not by mispelling a struct but because my code was
trying to use a struct from
of the compiler during compile time not about a crash during runtime.
Neither is tcc known to crash with an empty struct nor is the
struct asdasd in the test case known to be empty.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https
Anton Shepelev wrote:
There must be something wrong with the envi-
ronment on one of the machines, but I have no idea how to
locate it...
tcc -vvv file.c shows where tcc is looking for files.
--- grischka
___
Tinycc-devel mailing list
Tinycc
step through the function at 004058B0 to see what
happens.
But how do you find this in gdb? Or is it that free software is
stuck with a tool that is not practically useful?
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https
There are probably still some odd cases, for example you cannot
use -nostdlib and still link the startup code from libtcc1, as
in
tcc foo.c -nostdlib -ltcc1
--- grischka
Regards,
Gabriel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
Gabriel Corneanu wrote:
Hello again,
First thanks to grischka for previous quick fix.
Now I have another small issue; using stdcall always generate some
name mangling for function names, in libtcc.c line ~499.
It ignores the leading_underscore option, which is otherwise respected
a few lines
://repo.or.cz/w/tinycc.git/blob/refs/heads/mob:/il-opcodes.h
http://en.wikipedia.org/wiki/Common_Intermediate_Language
However it has fallen behind since then so definitely would need
some care if someone wants to reactivate it.
--- grischka
Ideally of course as a series of single patches for each feature. :)
Thanks,
--- grischka
BTW, it looks like the original source was tab-free, but some tabs have
snuck in, so you may want to (de)tabify the whole lot. I've also made a
couple of spelling corrections.
First off, here's the results
grischka wrote:
Anyway I think this experiment is definitely worth to be kept around.
I'd like to encourage you to push this on a fork, as with the fork
link top of -- http://repo.or.cz/w/tinycc.git
I just noticed that repo.or.cz now supports Personal mob branches:
http://repo.or.cz/h
Btw. there was a related patch here:
John wrote:
... Added some functions to retrieve information about declared
symbols, struct definitions, and values of object-like macros.
Please see libtcc.h and libtcc_test.c to get an idea about how to
use these.
, or is there any
other small compiler that can do this?
You might want to check the win64 version at
http://download.savannah.gnu.org/releases/tinycc/
--- grischka
Tanks for your attention, R. G.
___
Tinycc-devel mailing list
Tinycc-devel
, {0xC0,0,0,0,0,0,0,0x46}};
... or create your own (lib)uuid.a using tcc and ar from mingw.
(tiny_libmaker would probably have problems with command-line
length because it cannot add files incrementally)
--- grischka
And what about custom entry point/subsystem? (i.e. the famous
-Wl,-eEntryPoint and -Wl,--subsystem
://lists.gnu.org/archive/html/tinycc-devel/2013-12/msg8.html
[2]
http://repo.or.cz/w/tinycc.git/commitdiff/2bbfaf436f937ace4809d84be812ea1ac7fd7352
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman
/fbc8810334e6a087bed6de4dd84635cb6037b4dc
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
-Wimplicit-function-declaration ...
or
tcc -Wall ...
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Daniel Glöckner wrote:
FWIW I'm fine with relicensing all my contributions to files other than
arm-gen.c to the BSD license reproduced in RELICENSING.
Daniel
No problem but could you add such note in the RELICENSING file
itself?
Thanks,
--- grischka
Christian JULLIEN wrote:
configure is no more executable
Thanks, fixed.
Vincent Lefevre wrote:
x86_64-gen.c:1064:5: error: conflicting types for ‘gfunc_sret’
Also.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https
regressions.
Ok, I've put them back:
http://repo.or.cz/w/tinycc.git/commitdiff/32a4962593d6a2006cdd725480124717e7f5377d
--- grischka
Kirill
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
I guess these errors aren't new, just make test didn't stop
previously. I'll leave it to others to decide whether this
should still be ignored (e.g. changing lines @diff to -@diff).
make -k test should run all tests anyway.
--- grischka
Christian JULLIEN wrote:
Hi,
This commit raises
Austin English wrote:
tcctest.c:6:15: error: operator '=' has no left operand
#if GCC_MAJOR = 3
Check how it comes that conftest(.exe) is not built or gcc_major
is not set from configure, lines 295-304.
--- grischka
___
Tinycc-devel mailing list
with my compilation environment here.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Austin English wrote:
It fails with gcc-4.8.1, gcc-4.7.2 and gcc-4.6.2 I also tried gcc-4.5.2,
but that failed to compile at all.
Here using gcc-4.7.2, shell from git, no AV, works.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel
tne bug with some counter-bug, for example intentionally
mis-spelling the word version in the input (versio, verssion, ...).
Plus a short comment in the commit message.
But really it is up to your preference (technically, aesthetically,
spiritually, ...) what you do.
Thanks,
--- grischka
-Austin
(dllexport)
DLL_EXPORT BOOL func(HANDLE h, UCHAR c) {
...
}
--
Can someone show me how to define this to use stdcall?
See win32/examples/dll.c for an example and win32/include/_mingw.h for
more background info how __declspec works.
--- grischka
. Grischka, is it something we should change?
Why not. Wouldn't be for the first time:
http://repo.or.cz/w/tinycc.git/commitdiff/642b6d0f50c6
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo
they don't.
Anyway, I guess there are some ways to solve this:
- install a newer msvcrt.dll
- use the older utime.h
- hack the newer utime.h
- patch the tinycc mob version, in case you want to make
everybody's life easier, wrt utime on XP.
--- grischka
There is a ZIP file with all the relevant
Section *new_section(TCCState *s1, const char *name, int sh_type, int sh_flags)
{
Section *sec;
-sec = tcc_mallocz(sizeof(Section) + strlen(name));
+sec = tcc_mallocz(sizeof(Section) + strlen(name)+1);
This was not incorrect.
--- grischka
mobi phil wrote:
It is really fun to see so much activity the last days. Thanks!
I think I solved my problem that moment by calling.
get_tok_str(tok, tokc));
versus
get_tok_str(tok, NULL);
After a bit of experience with the code, I could even accept that
the original behavior of the function
, then it
is probably as in
#define get_sym_str(v) get_tok_str(v, NULL)
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
/tinycc.git/commitdiff/5879c854fb94f722a7ffdd4e895c9ce418548959
Thanks,
--- grischka
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
estimation, would it be possible to do the same on ELF?
That is build the PLT/GOT as if we were making an executable and
then use that with tcc -run?
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman
lifenjoi...@163.com wrote:
As dbghelp.chm says:
DWORD64 WINAPI SymLoadModuleEx(
__in HANDLE hProcess,
__in HANDLE hFile,
__in PCTSTR ImageName,
__in PCTSTR ModuleName,
__in DWORD64 BaseOfDll,
__in DWORD DllSize,
__in
relocations (the _GLOB_DAT and _JUMP_SLOT
relocs), which is cut short with the hack. OTOH removing the hack
would remove deviation depending on output type, so I think it's a
good idea nevertheless.
Done now.
Wow, does that look clean. Thanks !
--- grischka
For x86_64 and ARM, where the latter
cases of token pasting) runs similar code additional
22669 times. This raises some questions.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Thomas Preud'homme wrote:
On April 12, 2014 9:53:51 PM GMT+08:00, grischka gris...@gmx.de wrote:
Good, however note that the mechanism to perform token pasting
via
tcc_open_bf(tcc_state, :paste:, cstr.size);
is extremely slow and per se has a good share in making current
tcc about twice
else would have to step in because I don't have a win64 installed
currently.
Thanks,
--- grischka
diff --git a/x86_64-gen.c b/x86_64-gen.c
index ae65328..22783cd 100644
--- a/x86_64-gen.c
+++ b/x86_64-gen.c
@@ -604,7 +604,11 @@ static void gcall_or_jmp(int is_jmp)
if (vtop-r VT_SYM
Christof wrote:
Tried patch of grischka:
tcc examples/fib.c
outputs fib.exe, however
fib.exe
says Invalid win32 program + access denied
There is still something wrong with the generated pe-image.
I've pushed something on mob that might fix something:
http://repo.or.cz/w/tinycc.git
)
in
http://repo.or.cz/w/tinycc.git/commitdiff/14d0aa450f9a926a852ea01fbdecf27425264d14
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
to be fair we cannot reject the entire series. So which patches
would you like to trust and/or which ones would you prefer not to have?
Place your vote (everybody).
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org
users only? And how are
people supposed to benefit if it is not documented?
I use my patched version all the time. It works well.
Fine, great. But do we really need this in everybody's public
mob version? :P
--- grischka
___
Tinycc-devel mailing
jiang wrote:
/* bitfield store handling */
+SValue tmp;
+tmp = vtop[0];
[...]
+vtop--;
+vpushv(tmp);
This is still not a solution. See
#include stdio.h
int main(int argc, char **argv)
{
struct {
unsigned a:9, b:5, c:7;
lifenjoi...@163.com wrote:
One way is reproduce them all by tiny_impdef or don't use them but produce
the one when needed. It's OK.
As you say it's OK and that is good enough for this project.
You can create another project to provide complete library and
header sets for tcc on windows
Wendell P wrote:
On Sun, Jun 22, 2014, at 01:02 AM, lifenjoi...@163.com wrote:
I have tried a few methods to produce an MSVCRT in ELF format suitable
for static linking with TCC on Windows, but so far no success. If you
Why would you do this?
At this point, I'm just trying to see if it is
Markus Bergholz wrote:
I'd tried to compile tcc itself with build_cross=yes and tried
./x86_64-win32-tcc -nostdinc -I /usr/x86_64-w64-mingw32/include/
../helloworld.c -o helloworld-gcc.exe
[...]
/usr/x86_64-w64-mingw32/include//vadefs.h:33: error: #error VARARGS not
implemented for this
Markus Bergholz wrote:
However, both end up with Mex file entry point it missing.
__declspec(dllexport) Mex file entry point
-- gr
Thanks in advanced,
Markus
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
Thomas Preud'homme wrote:
It should yes. Grischka, Shinichiro, James: do you agree to relicense your
contributions to lib/libtcc1.c under the BSD variants in RELICENSING file?
Is not that what people listed in RELICENSING already did agree to?
If both of you answer yes, could you commit
Thomas Preud'homme wrote:
If both of you answer yes, could you commit the change Grischka?
Change the FSF header in lib/libtcc1.c? I'm not sure they would
agree. However it allows being linked into any program anyway.
Why would they have to agree? They are not author of this file. Only
YX Hao wrote:
Hi,
I mean just Ramsay Jones wrote.
the expression:
sizeof(a string literal)
was causing an _unused_ copy of the string literal to be stored in
the data section. This expression is a compile-time constant and,
once it has been evaluated, the string literal is no longer
jiang wrote:
my patch: See Attachment
You look at, if no problem, I'll push mob
Jiang
Patch is too long. I cannot understand it.
-- gr
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
jiang wrote:
The meaning is very simple patch
The patch has bugs. See:
$ make -C ../gnumake CC=tcc clean all
[...]
$ ../gnumake/gnumake
Makefile:203: target '$(patsubst)' doesn't match the target pattern
Makefile:203: *** mixed implicit and normal rules: deprecated syntax
Best regards,
Jiang
在 2014年08月02日 06:17, grischka 写道:
jiang wrote:
The meaning is very simple patch
The patch has bugs. See:
$ make -C ../gnumake CC=tcc clean all
[...]
$ ../gnumake/gnumake
Makefile:203: target '$(patsubst)' doesn't match the target pattern
Makefile:203
Please use the tinycc mailing list.
Gonzo FWS wrote:
Hey,
I'm not much of an expert on the C-standard, however I have been using
libtcc in a C++11 project of mine.
I cannot immediately use these functions:
tcc_get_symbol
tcc_add_symbol
Because C++ is very strict: It will not convert void* to
YX Hao wrote:
- s-unicode_entry is used (in compilation) before it is set
(in the link phase).
It passed. Can you explain what do you mean?
I mean it is like
x = 0;
if (x == 17)
do_something();
if (foo)
x = 17;
It does ... nothing.
-- gr
Regards,
YX
YX Hao wrote:
Attach the new patch.
So, does it support tcc -run? If yes then it needs to convert
argv.
-- gr
Please take a look at the flow I summarized bellow:
main()
..
=
tcc_new() -- tcc_parse_args() -- tcc_set_environment(s) --
Thomas Preud'homme wrote:
Grischka: it would be nice to have a release now (Debian is freezing soon)
after the issue I'm discussing with Michael is sorted out. I would have liked
to have the two fixes Jiang is working on but he didn't reply in some time.
I fixed one:
http://repo.or.cz/w
, someone needs to have a better idea.
--- grischka
Cheers,
Thomas
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
JFC Morfin wrote:
The question is not about bugs. These are ten years old libraries used
millions of time but compiled under Borland. There are differences
between compilers. The question is only to understand them.
And the answer is that there is no difference. Under any compiler
$ tcc bug1.c
bug1.c:109: warning: implicit declaration of function 'AB'
bug1.c:109: error: 'C' undeclared
thanks,
-- gr
//
//
//
Pip Cet wrote:
Does this fix it for you? Even if it doesn't, this should indicate
where the code is that goes wrong...
Yep, just funny how long it did NOT go wrong...
ch = tcc_peekc_slow(file);
as in ch = handle_eob();
One more, anyone ?
#define t(x,y,z) x ## y ## z
int main(int
Pip Cet wrote:
Hmm, this is trickier than I thought at first. The attached patch
passes tests and works for the case I described in my last mail, but
fails for
#define A(a,b...) g(a,##b,##b)
A(a,)
which should produce g(a). Probably. I mean, it's pretty weird to use
variadic macros like that,
option by executing sstrip/strip program
Eh, right, not to depend on external programs was the other
feature of tinycc.
* ...
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Pip Cet wrote:
I'm still working on this, for what it's worth. I'm not quite there
yet, but here's the current diff, and a few more CPP tests. Right now
it shouldn't be too hard to break the new code, but if you just happen
to do so please let me know how so I can put it on my list.
Hi,
I've
Sergey Korshunoff wrote:
Hi all,
there is a patch for the problem. Any suggestions?
And why does tinycc need this? If you want the symbol to be
global, you can add .globl to your asm.
Behavior whereby any extern declaration in C, provided it
appears above the asm in the file, would have the
David Mertens wrote:
@Everybody, Might there be a subtle bug in tcc's anonymous symbol
checking, since it uses inequalities rather than querying bits directly?
No, not at all. Say, you think that potentially 268 million symbols
in one source file could easily confuse anyone non-asperger and
Next time you want to do whole-sale code changes please discuss on the
mailing list before doing so, there might be reasons for the status quo
that you're unaware of, like in this case.
Noted.
See also the mob regression ... thread from 1.7.2015 and thanks
in advance for reverting
Christian JULLIEN wrote:
With this diff I'm able to compile tcc and libttc.a ROOTB on Cygwin.
Using tcc fails because it is not able to find crt*.o
Invsetigating why:
There are two issues:
1) compiling tcc for cygwin
2) using tcc to compile some program for cygwin
I'd suggest to start with 2)
Michael Matz wrote:
... In C it's not
allowed to have two definitions of the same non-static symbol, simple as
that. It's not only for when initialized with different values or the
like; it's undefined no matter what.
Maybe it isn't that clear. See below from the c99 draft, in particular
Sergey Korshunoff wrote:
Removing a valid warning is never a goid idea long-term.
A tcc message was: Error And this condition is an error only if an
initialization with diffenet values asked. In other cases it can be
only warning. And there must be a flag to supress it
TCC already has that
Sergey Korshunoff wrote:
You could refer to GCC's source and test suite
From the clang code:
...
// If this is a system #include, ignore the user #include locs.
unsigned i = isAngled ? SystemDirIdx : 0;
...
// If this is a #include_next request, start searching after the directory the
// file
Hm, could you describe what now the problem actually was, originally?
And what instead would be, in your opinion, the correct behavior
of #include_next in order to avoid that problem?
-- gr
Sergey Korshunoff wrote:
Hi!
A final version of the patch submitted.
This version looks rigth.
Sergey Korshunoff wrote:
a last grishka patch reversed a '...' handling by reason
"not a reliable way to lookahead". Now asm code in tccboot kernel
can't be compiled by tcc.
Very nice "reliable way"
p[1] is not allowed because it can point after EOB.
This means that with your patch, tcc would
Sergey Korshunoff wrote:
p[1] is not allowed because it can point after EOB
Yes, it can. But what algo wanted: if there is only 2 '.', return
tok='.', not the error message.
It is a parser, not a syntax checker. Is this possiible?
You could have asked first, and pushed later.
Anyway, see:
Sergey Korshunoff wrote:
And because you already spoiled maybe 20 patches for that nosense
I can imagine a test with which current tcc will fail and gcc not. Is
this considered nonsence?
Imagination in your head alone is not enough reason to put code into
the
Edmund Grimley Evans wrote:
Does anyone, and in particular grischka, who last modified this code,
object to the following patch?
Most likely I didn't change the seach order.
I think TCC's own include directory (/usr/local/lib/tcc/include by
default) should come before the system directories
Michael Matz wrote: ---
So, for this code:
struct S { int i;}
void f(struct S *s) { struct S y[1] = { *x }; }
void g(struct S *s) { struct S y[1] = { { x->i } }; }
TCC needs to differ between both cases and when parsing the LHS needs to
dive into the type struct S for function g() but not for
Ben Hutchinson wrote: ---
When I try to compile this:
#include
int _start(void){
unsigned char MyArray[4];
LPDWORD BytesWritten;
HANDLE hFile;
hFile=CreateFile("MyFile.dat",0xC000,0,0,2,0,0);
MyArray[0]=1;
MyArray[1]=2;
MyArray[2]=3;
MyArray[3]=4;
Sergey Korshunoff wrote: ---
A useful patch that does not add lines:
Yes, a master stroke.
PS: what about
output with -E should include spaces: #define n 0xe {newline} n+1
You mean the attempts on your branch? Horrible, of course ;)
-- gr
___
Sergey Korshunoff wrote: ---
PS: what about output with -E should include spaces: #define n 0xe {newline}
n+1
You mean the attempts on your branch? Horrible, of course ;)
I mean attached patch. It is not abount X(X(1)), but about
preprocessor output for
#define n 0xe
n+1
It must look like
Sergey Korshunoff wrote: ---
And currently output is identical for the case #define A B+1
correction for X(X(X(X(X(1)
https://github.com/seyko2/tinycc/commit/a95cb9a7d90f844fb6f5e8f14eaa8798af71577f
I think a patch is quite usefull. It adds a right replacement for the
nested macro calls
Sergey Korshunoff wrote: ---
The recommendation is:
Implementations should avoid imposing fixed translation limits
whenever possible.
Implemented adddition is a macro recursion detection:
* on define macro stage (is the name of macro can be found in macro string)
Bad idea :
#define A
David Mertens wrote: ---
Hello grischka,
Your commit caebbc3, "tccgen: scope levels for local symbols", breaks test
60_enum_redefinition on 32-bit Ubuntu 15.10. The test should error out
saying "error: struct/union/enum already defined", but now it errors saying
"main n
I tried to fix that:
http://repo.or.cz/tinycc.git/commitdiff/caebbc3ee1071ace94003cdf645f749d2b0a9eed
--gr
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Michael Matz wrote: ---
One remark: I believe in the tcc_preprocess routine
s1->ppfp is always set, otherwise it wouldn't have been called.
True.
Also, some things can be reused. Ideally, after minor modifications,
it could look like this in tcc_preprocess:
} else
spcs =
Vladimir Vissoultchev wrote: ---
One remark: I believe in the tcc_preprocess routine s1->ppfp
is always set, otherwise it wouldn't have been called.
I think it can be NULL when dffp is set for the dflag output when dumping
defines only (w/o actual preprocessor output).
There is no dffp.
Nor
David Mertens wrote: ---
Just as a point of context, I am now maintaining the exsymtab work as a
fork of the current mob, so any changes that are made have to be merged. In
other words, I'm a downstream consumer of tcc. This morning I got a merge
conflict with these define print functions that
Edmund Grimley Evans wrote: ---
You seem to have made TCC stricter than GCC:
$ cat t.c
typedef int x;
typedef int x;
$ gcc -Wall -O2 -c t.c
$ ./tcc -B. -c t.c
t.c:2: error: redeclaration of 'x'
Apparently such redefinitions are not officially allowed in C99, so
TCC is not really wrong in
Sergey Korshunoff wrote: ---
else if (*optarg == 'b') // ???
Leftover from a feature that I decided not to push to [mob] because
of little relevance (estimated).
-- gr
___
Tinycc-devel mailing list
David Mertens wrote: ---
Nope. I had to learn by diving into the source myself. But if you want to
learn the process of compilation, you should just try to follow the series
of function calls to compile code.
First commits to tinycc are from 2001
Rhagdamaziel wrote: ---
Hi, I am a user of the Nim programming language which compile to C,
among others.
I use TinyCC for compiling Nim programs in debug mode for its especially
fast compilation time.
I recently encountered an issue where I was getting a segfault at some
point after I called
Jin Qian wrote:
I even did the experiment by modifying the few bytes of machine code in gcc compiled object file just to make it look like tcc compiled, then linking with tcc produced a good exe. Any ideas why tcc does this, why is the "-4" offset in lea instruction?
You are using objcopy to
Michael Matz wrote:
(Ultimately the layout of va_list has to be compatible between compilers
on the same system anyway; it's dictated by the psABI.)
Which reminds me of a fix for exactly such problem on win64 (which
strangely enough exists since 04/2013)
.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
to compile the hello_win
example. It's just that I like that criterion because it is well
defined.
Regards,
--- grischka
On Wednesday, February 8, 2017 9:15 PM, grischka <gris...@gmx.de> wrote:
Hi all,
I pushed some last patches that I found and updated the version
number: htt
tcc' then the error is present, so it must be a bug
in the Ubuntu package.
You might also try the latest git mob branch version which is supposed
to become 0.9.27 soon:
http://repo.or.cz/w/tinycc.git
--- grischka
-Mike
___
Tinycc-devel mailing
401 - 500 of 803 matches
Mail list logo
