Re: [Tinycc-devel] [ARM regression] ret_longdouble_test2... failure
Le 2014-05-13 23:29, jiang a écrit : --- a/tests/Makefile +++ b/tests/Makefile @@ -207,8 +207,8 @@ asmtest: asmtest.ref abitest-cc$(EXESUF): abitest.c $(top_builddir)/$(LIBTCC) $(CC) -o $@ $^ $(CPPFLAGS) $(CFLAGS) $(NATIVE_DEFINES) $(LIBS) $(LINK_LI -abitest-tcc$(EXESUF): abitest.c libtcc.c - $(TCC) -o $@ $^ $(CPPFLAGS) $(CFLAGS) $(NATIVE_DEFINES) -DONE_SOURCE $(L +abitest-tcc$(EXESUF): abitest.c $(top_builddir)/$(LIBTCC) + $(CC) -o $@ $^ $(CPPFLAGS) $(CFLAGS) $(NATIVE_DEFINES) $(LIBS) $(LINK_LI abitest: abitest-cc$(EXESUF) abitest-tcc$(EXESUF) @echo $@ Where does this change come from? I hope you don't intend to commit this. The purpose of abitest-tcc is to be compiled by tcc, not by the host compiler $(CC). I still didn't look at anything that happen since 2ac238f but given the recent breakage I'll try to take a look at some point (but still can't right now). However the number of changes is pretty big and difficult to read now. The other solution would be to just do a git diff between then and now. Given the terse changelog it might not make a big difference anyway. Please be more specific when you commit something, instead of just fix commit foo. Cheers, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Fwd: Bug#675024: tcc: errors Symbol `mpfr_xxx' causes overflow in R_X86_64_PC32 relocation
Another report about the current state of shared libraries produced by
tcc. Michael, I'm just copying it here because you asked. It's ok if you
don't want or can't work on this.
Best regards,
Thomas
Message original
Objet: Bug#675024: tcc: errors Symbol `mpfr_xxx' causes overflow in
R_X86_64_PC32 relocation
Date: 2014-04-01 07:15
De: Vincent Lefevre vinc...@vinc17.net
À: Thomas Preud'homme robo...@debian.org
Cc: 675...@bugs.debian.org
Répondre à: Vincent Lefevre vinc...@vinc17.net,
675...@bugs.debian.org
Control: tags -1 - fixed-upstream
On 2014-03-31 22:22:03 +0800, Thomas Preud'homme wrote:
Two commits were done upstream to fix this bug. The author (Michael
Matz) would appreciate some testing to see if it works correctly.
With MPFR 3.1.2 configured with ./configure CC=tcc, I still get
Symbol `...' causes overflow in R_X86_64_PC32 relocation messages,
but the tests no longer fail... except texceptions.
Actually the symbols are no longer mpfr_xxx, but libc functions, e.g.
ypig:.../mpfr-3.1.2/tests ./texceptions
./texceptions: Symbol `abort' causes overflow in R_X86_64_PC32
relocation
zsh: segmentation fault (core dumped) ./texceptions
I'm not sure whether this is related, but it seems so, because
if I configure MPFR with ./configure --disable-shared CC=tcc,
all tests pass.
I could reduce texceptions.c to:
#include mpfr-test.h
int
main (void)
{
(mpfr_clear_flags)();
return 0;
}
Then I get:
ypig:.../mpfr-3.1.2/tests ./texceptions
zsh: segmentation fault (core dumped) ./texceptions
The message has disappeared, but it still crashes.
--
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog:
https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] improving get_tok_str
Le 2014-03-31 23:46, mobi phil a écrit : Was not proposing to commit this into the main repo, just a very simple way to tag lines that probably need some more comments. The experts then just could do a diff and see those points, remove the tag and/or add comment. Oh you mean through another repo? Sorry, I assumed the main repo. I'm too used to the centralized approach we have for tcc. Thought this would be a very simple channel for this goal. Yeah indeed. But it would make searching the questions not so easy. You'd use diff but over time the diff would also contain the answers. Do you have any specific code review platform, that could be well integrated with git and a simple editor like vim? Nope sorry. I know you can do this via github but I'd rather we stick to open platform if possible. But yeah, github would be easy to setup. Honestly never used mob. On http://repo.or.cz/h/mob.html [1], _only_ if you add a mob user and statement made me thinking that I need some access grant. Will read again the documentation. It mentions about the administrator of the repo. As a user you have almost nothing to do. Mob is enabled for tcc so you can just push as I said. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Valgrind Inconsistency detected by ld.so: rtld.c:
Le 2014-04-01 19:53, Domingo Alvarez Duarte a écrit : Hello Daniel ! Hi Domingo, Just in case do you want to look at it too, I discovered other issue with sqlite3 compiled with tcc on arm, running the query bellow on sqlite3-gcc takes 1 second but doing the same on sqlite3-tcc takes for ever, if we remove the call to datetime and use only the field mtime the the sqlite3-tcc works almost like sqlite3-gcc. I think there would be more chance that someone work on it if you can provide a simple testcase or at least a complete testcase. Typically something that fit in only one source file. I acknowledge that it is not always possible or easy to find such a testcase but tinycc like most (all?) free software lack of manpower and something difficult to reproduce is very likely not going to be taken care of. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] mksh fails to build with bound check
Le 2014-03-30 23:56, Kirill Smelkov a écrit : Just a quick note, that I've got your message and was able to reproduce mksh 0.38-3 breakage with `tcc -b`, and also, as I hope, found a small test-case for argv v.s. bcheck crash which is below. Please note that I already made a change recently to try to handle the argv and arge (environ in main) case. See commit b125743323f92b3492634cd875be820c890d5f29, that might be the cause for the bug your testcase shows. I also gave some thought to a solution to the more general case at [1]. [1] http://lists.nongnu.org/archive/html/tinycc-devel/2014-03/msg00126.html When I have my next free time, I'll try to analyze it, but that should not be soon as I'm currently very busy... No problem, thanks a lot for helping us. Thanks, Kirill Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] x86_64: shared libs
Le 2014-03-31 11:54, Michael Matz a écrit : Hi, I just pushed some things [1] to mob that make shared libs on x86-64 linux sort of working (well, in my little tests). It's not 100% conformant to the ABI yet, but hey, its late here :) i386 could now use some cleanups as well (so that it really generates PIC code, not that unsharing text-reloc containing code it currently emits). I have checked x86-64 (no testsuite bugs) and i386 (no _additional_ testsuite bugs), but not ARM. I tried to not change the latter, although it also contains dubious code (OTOH it currently doesn't support generated shared libs at all, so ...), but I might have unintentionally broken stuff. Wow, that's great. Thanks a lot for this, I know a few users that will be happy. I had to extend struct sym_attr to contain a full plt_offset, not just a flag, it's really required. Shouldn't be too bad as it's created only for symbols that really take part in dynamic linking. Not really no because alloc_sym_attr allocates an array whose size is that of the max sym_index passed to it. This makes finding the attribute of a symbol fast, as opposed to a mailing list. A simple hashtable with helper functions would be better of course. Testing appreciated (hi Arnold :) ). I'll ping the Debian bug report for people to test you changes. Thanks again, it was a long requested feature. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] improving get_tok_str
Le 2014-03-30 21:18, Domingo Alvarez Duarte a écrit : That would be nice ! I would like to see the implementation of qcc http://lists.nongnu.org/archive/html/tinycc-devel/2011-09/txtYogaFhDvlT.txt [3] and any documentation will help on it, someone asked before about tinycc generate an intermediate pcode that would make things easier for qcc. When I started tinycc-noglobals it was because I was looking at a jit library and found libjit very nice but its not maintained and only the x86 and x86_64 backends are implemented (arm is only a draft that doesnt work), then I started playing with it and found the instructions to construct jitted code a bit complicated, knowing tinycc I thought why complicate my life when I already know C and tinycc generates executable code onthefly/jit ? Then I actualized my virtual io on top of tinycc:mob and then started looking at the tinycc code in more detail, when I found global variables like ch, file, tok it was clear that the potential for name clashing/bugs using it as is would be huge. Thats why tinycc-noglobals came to existence, then I found that the backends of tinycc was not in good shape, it can compile some simple programs in general but when we try to compile something a bit more complex like fossil-scm it failed. Then searchin the net I found the http://landley.net/qcc/ [4] , http://elinux.org/CELF_Project_Proposal/Combine_tcg_with_tcc [5] and looked at qemu tcg Tiny Code Generator and thought what a great idea !! I propose to try make it a reality, any volunteers ??? Sorry I don't have much free time and I cannot work on qemu due to IP issues related to my work. But the idea sounds interesting. It's just a bit sad to use an old version of tcc as the frontend though. Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc should allow redefinition of enumerator in inner scope
Le 2014-03-31 19:25, Jay Foad a écrit :
Hi Jay,
tcc complains about the redefinition of FOO, but it should allow it
because the second definition is in an inner scope:
$ cat e.c
enum { FOO = 1 };
void f() { enum { FOO = 2 }; }
$ ./tcc e.c
e.c:2: error: redefinition of enumerator 'FOO'
Fixed. Thanks for reporting.
Best regards,
Thomas
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] improving get_tok_str
Le 2014-03-31 22:50, Domingo Alvarez Duarte a écrit : Hello Thomas ! What do you mean by old version of tcc there is other newer versions elsewhere ? No. I meant qcc would be tcg + old version of tcc (not the current one). Cheers, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] spurious cast expected error when initialising a struct
Le 2014-03-31 21:36, j...@mchsi.com a écrit :
On Mon, Mar 31, 2014 at 01:42:36PM +0100, Jay Foad wrote:
In this example I get a spurious error, but only when I elide some
braces *and* put parentheses around the literal:
$ cat a.c
struct {
struct {
int i;
} a;
} x = {
(3)
};
$ ./tcc a.c
a.c:6: error: cast expected
Some compilers accept it but issues warning (with -Wall).
The following should always be valid:
struct {
struct {
int i;
} a;
} x = {
{3}
};
At least according to C99 not all parenthesis are necessary if there is
no ambiguity. It's a known bug but nobody found time / interest to work
on this yet. Maybe for tcc 0.9.27 as I remember grischka warning that
the current code is not adapted to detect this and some important
changes would be needed.
Best regards,
Thomas
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] improving get_tok_str
Le 2014-03-30 19:36, Domingo Alvarez Duarte a écrit : I vote for write a comment and tagging it NOTSURE, when other people look at the commit probably some of then they will read it and check the validity of it and if its not valid will raise it and probably between us we can fix/improve it. You need to consider 2 things though. The first is that when doing a patch you will typically look at much more code than you modify. Adding comment for all that code would be a big hassle that would almost certainly demotivate me from contributing since I'm doing this as volonteer (as opposed to a paid job). You need to find the right balance. When I modify something I try to add comments for what I did (unless it's trivially obvious like a lot of my fixes) and add some comments around if I find something is missing and I have the knowledge. The second thing is I don't like much to show how much I am still ignorant after all this time spent on tinycc :( Alternatively, if any code seems obscur to you feel free to ask here and you might find an answer. You obviously cannot do that when lots of things are obscur, only for the worst things. One thing very important that people new to tcc can do though is write down somewhere what things where difficult to figure out. As you said, once you gained knowledge about a software you forget about what part lack documentation because you understand things. So new people can write this down and either publish it here, or keep it and write the documentation once they gained the knowledge themselves. Cheers, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Is --enable-cross of any use in its current form?
Hi there, TL;DR: remove --enable-cross and use build arch != target arch to detect the cross-compiling case When packaging tinycc 0.9.27 for Debian I want to create a separate package with tinycc cross compilers. However, the current mechanism to build the cross compilers, --enable-cross in the configure switch, is not adapted because it builds all the cross compilers at once and thus apply the same configuration for all of them. This is a problem in the multiarch world because the library path would be different for each compiler. It would be include in the path i386-linux-gnu for i386, x86_64-linux-gnu for x86-64, arm-linux-gnueabi for arm softfloat, arm-linux-gnueabihf for ARM hardfloat, etc… So for arm hardfloat you'd have /usr/lib/arm-linux-gnueabihf then /usr/lib then /lib/arm-linux-gnueabihf, then /lib, then /usr/local/lib/arm-linux-gnueabihf and to finish /usr/local/lib. Right now this is detected in the native build case and you'd have to set it for cross-building. But since cross-building builds all compiler, this is not practical. Therefore I was thinking about removing --enable-cross and instead decide whether we are building a cross-compiler or not by comparing what's in $cpu with what's coming from uname -m and decide based on that. Agreed, I'm conflating host arch and build arch together but I'm not sure we support the case of build != host arch well right now anyway. Is there any people relying on --enable-cross? If yes we could still keep it and also add the detection mechanism which would allow to either build all cross-compilers or just one. Has anyone an objection to that? For information, that's one of the last of the blocker for me to start the call for testing of tcc 0.9.27. The other blocker is the testsuite to work on all arch without error (not the case on i386 right now). Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] improving get_tok_str
Le 2014-03-30 03:20, mobi phil a écrit : What is missing is few lines more of comments. As with any code base once you know it any piece of documentation becomes superfluous, but for newcomers the amount of comments will clearly decide the should I stay or should I go ;) While I agree more comment would be nice (and also more documentation) I do have quite some fun working on tcc because its size is reasonnable. Also it touches more than compilation: linking and parts of dynamic linking (tcc -run) and a bit of assembler (not my favourite part) so it's nice to learn things. I think people who have bit more insight into the architecture of tcc, could write valuable comments especially around core types and their fields and key functions. Since a few months I've been trying to add comments when I modify something. See gfunc_call as of 0.9.26 for instance and now. However there is still some place where I'm not sure of all the lines so I prefer not to put a comment that are wrong (it's worse than no comment). Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bounds mixing non malloced strings is the reason to make tests fail on linux 32bits
Le 2014-03-30 01:01, Domingo Alvarez Duarte a écrit : Hello all ! I followed the code and could see that mixing strings malloced and not malloced by tcc is the reason for the test to fail on linux 32 bits. Have you tried compiling with -b switch? There is still some bugs in bound checking code. On that particular case we are mixing a string from program argv[] with the tcc bounds checking, the later expect all strings to have been malloced by __bound_malloc that adds an extra byte to the size, but the strings from program parameters argv[] seem to be allocated without __bound_malloc and then the false BAD_POINTER is raised. Who did this ? Mmmh, that's me. There was bound checking when doing *argv and that made the bound checking work in this case. But indeed, I didn't think about when accessed as array. I fail to see how it could work before. For objects defined in a different compilation unit, there is no way to know if it will be compiled by tcc or not. So either you don't do any bound checking for object not defined within the compilation unit you are compiling, or you do it on all objects but it will fail for those not compiled by tcc. I was trying to make at least argv and arge work as they are probably the most frequently encountered object comming from outside a program (I assume usually people compile a whole program with tcc). To make it a more general solution we could teach the bound checking code about all the memory region used by libraries and tcc. If a pointer is in program area, normal bound checking occurs, else if it's in a library area it just returns without error and if outside it returns -2 like now. I'll think about how to discover the mapping at runtime and see if I can implement this for 0.9.27. If we do the tests without compiled tcc by tcc it works fine, I propose to move those tests to the compiled tcc instead of tcc running by other tcc. Certainly not. a test is meant to fail when there is a problem. When that is the case you fix the bug or declare the situation as not supported. I prefer the former. It sounds a bit crazy but if someone can come in to help clarify this we can together solve this problem. See above. Cheers, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Compiling mupdf on X86_64 fails
Le 2014-03-28 14:44, Aharon Robbins a écrit : If TCC would support generation of PIC code on x86_64, I would immediately switch to it as my default compiler for gawk development. I know we get often asked about it. I wanted to do it in this development cycle but that would delay the release quite a bit and I think it's better to do a release soon. I can't promise anything but I will try to look into it first after the release (albeit any segfault or miscompiled bug discovered). Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Compiling mupdf on X86_64 fails
Le 2014-03-27 23:14, Armin Steinhoff a écrit : I never saw a commitment that tcc supports X86_64 and I saw never a statement that tcc supports fully all assembler directives. x86_64 is quite well supported on the contrary. Several people are making commits just for this architecture and it seems to be the version of tcc people use the most. That said, I do agree on the general statement that we should define what we care about for tcc. Right now we should aim for a new release of tcc (it's getting a bit long to come there but I have a couple more small bugfix I would like to do before). That means things which are not a regression from 0.9.26 can wait for the next to next release. And yes, .balign definitely enters that category and yes also, there is little chance that tcc will ever support all assembly directive. For one, tcc does not support it assembler on ARM. Don't take me wrong, I really do appreciate all the bug report we got, although I feel a bit overwhelmed and would welcome any help. But if we try to fix all bugs before we release we'll probably never release so let's fix the biggest one and especially the regressions. I really don't like tcc leading to segfault for programs compiled with it so if these errors could be investigated I would appreciate it but I don't have the time myself. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] improving get_tok_str
Le 2014-03-15 20:10, mobi phil a écrit :
Hi,
get_tok_str is called in several places with second parameter NULL,
though inside members (thus dereferencing NULL) is possible.
Probably this combination bad never happens, but would like to use
this
function to understand the code.
Yes, it ought to be fixed. The solution would be simple:
CValue cval;
if (!cv) {
cval.ull = 0;
cv = cval;
}
No problem to fix on my side, but I am doing some similar minor
fixes,
and find it pity not to commit upstream.
Yep and we really welcome any help.
Can you please tell me your rules for git push/branches etc.?
It's quite easy actually. There is a branch called mob that everybody
can commit to. It is the branch that gets clone by default. When you
want to push, just do git push ssh://m...@repo.or.cz/srv/git/tinycc.git
$branch:mob. If you intend to push more than once I suggest that you
create a remote repository. I personnaly have this:
[remote mob-access]
url = ssh://m...@repo.or.cz/srv/git/tinycc.git
fetch = +refs/heads/*:refs/remotes/mob-access/*
Best regards,
Thomas
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] llvm IR target
Le 2014-03-12 21:36, mobi phil a écrit : As you may have noticed the syntax is a bit special. Uses @ and $. @ for decorators, and $ for referencing decorator instances. (These are supposed to be more than objects) The reason to use these is that the parsing/grammar would be easier and the syntax will be also more visible (though a bit more typing) You'll then need to look at tccpp which contains the tokenizer. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] help with this modification
Le 2014-03-11 22:39, Carlos Montiers a écrit : Hello. I want modify the source code of tiny for warns about arrays declared inside functions, with a size greather than 1MB (default stack size on windows) or a less value, maybe 256KB, but I have problem for know is the arrays is declared in global or inside the function. How I can know it. I have this line on tccgen.c under line 3324 : if ((n 262144) !(vtop-type.t VT_STATIC)) tcc_warning(array size greater than 256 KB can full the default stack reservation size on windows (1 MB)); Depending on the version of tcc you use line 3324 could be a quite different place. You could either give a commit sha1 to be more precise or give a unified diff that would give us the context of where you are trying this change. By the way, I'd go for n (1 (256 * 1024)) or a 0x notation that would be more comprehensible than this base 10 integer value. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc compile broken with clang-3.3 (regression from 0.9.26)
Le 2014-03-10 06:08, Austin English a écrit : On Sun, Mar 9, 2014 at 10:24 AM, Thomas Preudhomme robo...@celest.fr [1] wrote: Le dimanche 9 mars 2014, 01:29:30 Austin English a écrit : It broke between 0.9.25 and 0.9.26. Introduced by: 7a477d70cabe15fa66fd0f32fab5e95841a500e5 is the first bad commit commit 7a477d70cabe15fa66fd0f32fab5e95841a500e5 Author: grischka grischka Date: Wed Feb 6 19:01:07 2013 +0100 lib/Makefile: use CC, add bcheck to libtcc1.a Also: - fix make tcc_p (profiling version) - remove old gcc flags: -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 - remove test hello for Darwin (cannot compile to file) [austin@localhost tinycc]$ git describe release_0_9_26-158-gfdb3b10 clang -c libtcc1.c -o x86_64/libtcc1.o -I.. -Wall -g -O2 -fheinous-gnu-extensions -DTCC_TARGET_X86_64 libtcc1.c:697:45: error: too few arguments provided to function-like macro invocation void *__va_copy(struct __va_list_struct *src) ^ /usr/bin/../lib/clang/3.3/include/stdarg.h:40:9: note: macro __va_copy defined here #define __va_copy(d,s) __builtin_va_copy(d,s) ^ libtcc1.c:697:16: error: expected ; after top level declarator void *__va_copy(struct __va_list_struct *src) ^ ; 2 errors generated. make[1]: *** [x86_64/libtcc1.o] Error 1 Fixed. But there is another error with __clear_cache being defined and I dont know how to solve this. Why isnt this just a warning? Best regards, Thomas Works, and passes make test, thanks. I dont get that warning. With release_0_9_26-164-gd3d8990, I get two warnings: clang -o tccasm.o -c tccasm.c -DCONFIG_LDDIR=lib64 -DTCC_TARGET_X86_64 -I. -Wall -g -O2 -fheinous-gnu-extensions tccasm.c:541:72: warning: data argument not used by format string [-Wformat-extra-args] sprintf(sname, (n?.%s%d:.%s), get_tok_str(tok1, NULL), n); Yeah, so if n is non zero, you get 2 conversion specifications and there is 2 parameters. But when n is null, there is only 1 conversion specification but still 2 parameters. It's fine as it will just get ignored which is why clang just emits a warning. ~ ^ .. clang -o tcc tcc.o libtcc.a -lm -ldl -I. -Wall -g -O2 -fheinous-gnu-extensions clang: warning: argument unused during compilation: -fheinous-gnu-extensions I guess fheinous-gnu-extensions is just a compilation flag and clang says that adding it to the command line was useless here since we are linking. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc bootstrap
Le 2014-03-10 07:27, Patrick Lauer a écrit : On Sunday 09 March 2014 17:12:11 Christian Jullien wrote: I think Patrick summarized things very well. Ok, using gcc -O3 you can generate a tcc that compiles faster any program than tcc compiled with itself. That is mildly funny, but not unexpected ... And I think that is the main reason why we don't compile tcc with tcc. I believe it's important to keep the possibility to demonstrate that tcc is capable enough to compile itself but I don't think we should do it by default. The most important use case for tcc is to use it for development because it's fast to compile programs. If tcc were to be compiled by itself it would be less fast (yet still quite fast) so there is not much interest in doing so. Best regards, Thomas P.S.: Hi Patrick :) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Fwd: Re: llvm IR target
Message original Objet: Re: [Tinycc-devel] llvm IR target Date: 2014-02-21 10:48 De: Thomas Preudhomme robo...@celest.fr À: mobi phil m...@mobiphil.com, tinycc-de...@lists.gnu.org Le 2014-02-21 07:12, mobi phil a écrit : ... another reason, probably the strongest one: as we all know one trades the speed of tcc against the optimizations of the resulting binary. I would see tcc nicely integrated in a development process where one would almost instantly build thousands of lines of code, but when going for production, would generate llvm and otpimize... But why not just use a different compiler at that point? You are going to do a special action when going for production anyway. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Drop OABI and FPA from arm-gen.c
Hi Daniel, I prepared two commits to remove OABI and FPA support from arm-gen.c. No new hardware come with a FPA unit as far as I know and kernel FPA implementation was removed from the Linux kernel a few versions ago. As to OABI, everybody seems to have moved to EABI at this point, so I think it deserve to be removed as well. The code is not very big but I myself can't easily test my change for these configurations. But since it's your baby I'd understand if you want to keep the code around. Also you might yourself have some hardware or installation with them so I prefer to decide it with you. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] uint64_t/int64_t = double broken on ARM
Le 2014-01-29 13:14, Christian Jullien a écrit : Thank you for your reply Daniel but I don’t understand if it is a libgcc or tcc issue. What Daniel says is that parameters must be passed to casting function from libgcc in a specific way (that is, different from the usual calling convention). So it is obviously tcc's fault. However, there is special provision in the code for this normally but it seems the provision is not complete. I'll look at it asap but I won't before 1 week. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
