[Tinycc-devel] Current downloads
The most recent download I can find is here: http://savannah.nongnu.org/files/?group=tinycc And it's from 2009. Is there a more recent release (as opposed to downloading some revision from git)? If not, can there be? :) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Current downloads
+1 -redj On Wed, Apr 18, 2012 at 8:42 AM, NightStrike nightstr...@gmail.com wrote: The most recent download I can find is here: http://savannah.nongnu.org/files/?group=tinycc And it's from 2009. Is there a more recent release (as opposed to downloading some revision from git)? If not, can there be? :) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Current downloads
Le mercredi 18 avril 2012 14:42:07, NightStrike a écrit : The most recent download I can find is here: http://savannah.nongnu.org/files/?group=tinycc And it's from 2009. Is there a more recent release (as opposed to downloading some revision from git)? If not, can there be? :) The last release is indeed the 0.9.25. There will be a release soon, but the soon is not defined yet. Best regards, Thomas Preud'homme signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] symtab_section
I pushed a small patch that should allow using tcc_get_symbol also for older states. Please test. http://repo.or.cz/w/tinycc.git/commitdiff/f98c2306a0857ad3f8800f91e0554a27adc7f675 Current state of multiple TCCStates usage summary: There are now two things you can do with TCCStates after tcc_relocate: - run the ccde - get symbol addresses There is one thing you cannot do _before_ tcc_relocate: - create another TCCState Also, tcc_relocate can be called only once for each state. --- grischka David Mertens wrote: Milutin, all - Yes, you were absolutely correct. Once I recompiled tcc as a shared library, the issue went away. That lesson has been learned. :-) However, my main question remains unanswered, and my suspicions have been confirmed with new tests. To recap, here is my original question: Is there a good reason symtab_section is a global variable? In addition to the issue that I encountered, what if I want to have multiple compiler states? It looks to me like the pointer for symtab_section will be overwritten for each call to the constructor. Won't this lead to trouble? And is there any reason we don't have a field in the TCCState struct to store the location of symtab_section? Whether or not this is the source, I have indeed encountered issues under a few circumstances: 1) Using a single compiler state, compiling+relocating multiple times. When I do this, I cannot call any functions from the first relocation after the second relocation. 2) Using two states, I cannot call any functions from the first state after I have compiled+relocated the second state. Using the *first* state, I *can* retrieve symbols from the compilation of the second state! So, it looks like there's a global variable for some sort of symbol table machinations. Thoughts? David ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Fwd: Use CString to concat linker options
Gabriel Corneanu wrote: Hi, I had the same problem. Why don't you just modify build-tcc.bat to build tcc with -DONE_SOURCE also (just like libtcc)? Which may fix YOUR problem but doesn't fix THE problem. Anyway, since the CString wasn't zero-terminated either, I decided to do my contribution to this story, also: http://repo.or.cz/w/tinycc.git/commitdiff/4274c44de7dfb99a1058a5af515e9865cc9d2ff9 --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] symtab_section
Wow, excellent! I looked over the patch and the changes were minimal, but they are 90% of what needs to happen. More importantly, I ran your code against my Perl bindings' test suite and it passed, where before it failed. I would still like to be able to have multiple not-yet-relocated TCCStates, and I will focus my energy on that when I get a round tuit, but at this point if I really need to, I can control how my Perl code accesses TCC with a singleton. Sorry I didn't actually get around to implementing this work, and thanks for beating me too it. I have lots of projects and some of them got my attention in the last few weeks. Thank you thank you thank you! David :-D On Wed, Apr 18, 2012 at 11:50 AM, grischka gris...@gmx.de wrote: I pushed a small patch that should allow using tcc_get_symbol also for older states. Please test. http://repo.or.cz/w/tinycc.**git/commitdiff/** f98c2306a0857ad3f8800f91e0554a**27adc7f675http://repo.or.cz/w/tinycc.git/commitdiff/f98c2306a0857ad3f8800f91e0554a27adc7f675 Current state of multiple TCCStates usage summary: There are now two things you can do with TCCStates after tcc_relocate: - run the ccde - get symbol addresses There is one thing you cannot do _before_ tcc_relocate: - create another TCCState Also, tcc_relocate can be called only once for each state. --- grischka David Mertens wrote: Milutin, all - Yes, you were absolutely correct. Once I recompiled tcc as a shared library, the issue went away. That lesson has been learned. :-) However, my main question remains unanswered, and my suspicions have been confirmed with new tests. To recap, here is my original question: Is there a good reason symtab_section is a global variable? In addition to the issue that I encountered, what if I want to have multiple compiler states? It looks to me like the pointer for symtab_section will be overwritten for each call to the constructor. Won't this lead to trouble? And is there any reason we don't have a field in the TCCState struct to store the location of symtab_section? Whether or not this is the source, I have indeed encountered issues under a few circumstances: 1) Using a single compiler state, compiling+relocating multiple times. When I do this, I cannot call any functions from the first relocation after the second relocation. 2) Using two states, I cannot call any functions from the first state after I have compiled+relocated the second state. Using the *first* state, I *can* retrieve symbols from the compilation of the second state! So, it looks like there's a global variable for some sort of symbol table machinations. Thoughts? David __**_ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/**mailman/listinfo/tinycc-develhttps://lists.nongnu.org/mailman/listinfo/tinycc-devel -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian Kernighan ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Some fixes for x86_64 and general code to enable compiling GCC
Hi,
I was bored the last weekend and stumbled over tinycc, tried compiling GCC with
it, which breaks in multiple ways, sometimes not parsing stuff, sometimes
miscompiling it, and thought about hacking some other compiler than GCC :) I
just pushed nine patches to mob to fix all the problems I encountered (also
attached for reference).
I've added testcases for all the issues to tcctest.c.
I can now build current GCC (well, r186469 plus a modification, see below) with
tinycc on x86_64 (all language frontends written in C, i.e. c, c++, objc,
objc++ and fortran), and that so built GCC is able to compile all its own
target libraries.
The nice thing is that I even found a real bug in GCC (fixing it is required to
make it work with tinycc on x86_64), which I'm going to apply upstream later,
but for completeness I attach it here too in case anyone wants to play with it
right now (fix-diag-vaend.diff) :)
Have fun,
Michael.From 6471ec0a2bd523edd4bbc79277a33d0b853940fa Mon Sep 17 00:00:00 2001
From: Michael Matz m...@suse.de
Date: Sat, 14 Apr 2012 23:50:21 +0200
Subject: [PATCH 1/9] Fix conversion in a?0:ptr.
(cond ? 0 : ptr)-member wasn't handled correctly. If one arm
is a null pointer constant (which also can be a pointer) the result
type is that of the other arm.
---
tccgen.c| 19 ++-
tests/tcctest.c | 13 +
2 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/tccgen.c b/tccgen.c
index 5aa21c6..b0cec4a 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -1489,7 +1489,8 @@ static inline int is_null_pointer(SValue *p)
if ((p-r (VT_VALMASK | VT_LVAL | VT_SYM)) != VT_CONST)
return 0;
return ((p-type.t VT_BTYPE) == VT_INT p-c.i == 0) ||
-((p-type.t VT_BTYPE) == VT_LLONG p-c.ll == 0);
+((p-type.t VT_BTYPE) == VT_LLONG p-c.ll == 0) ||
+ ((p-type.t VT_BTYPE) == VT_PTR p-c.ptr == 0);
}
static inline int is_integer_btype(int bt)
@@ -4116,14 +4117,22 @@ static void expr_cond(void)
(t2 (VT_BTYPE | VT_UNSIGNED)) == (VT_LLONG | VT_UNSIGNED))
type.t |= VT_UNSIGNED;
} else if (bt1 == VT_PTR || bt2 == VT_PTR) {
-/* XXX: test pointer compatibility */
-type = type1;
+ /* If one is a null ptr constant the result type
+ is the other. */
+ if (is_null_pointer (vtop))
+ type = type1;
+ else if (is_null_pointer (sv))
+ type = type2;
+/* XXX: test pointer compatibility, C99 has more elaborate
+ rules here. */
+ else
+ type = type1;
} else if (bt1 == VT_FUNC || bt2 == VT_FUNC) {
/* XXX: test function pointer compatibility */
-type = type1;
+type = bt1 == VT_FUNC ? type1 : type2;
} else if (bt1 == VT_STRUCT || bt2 == VT_STRUCT) {
/* XXX: test structure compatibility */
-type = type1;
+type = bt1 == VT_STRUCT ? type1 : type2;
} else if (bt1 == VT_VOID || bt2 == VT_VOID) {
/* NOTE: as an extension, we accept void on only one side */
type.t = VT_VOID;
diff --git a/tests/tcctest.c b/tests/tcctest.c
index f0d82cf..723adc1 100644
--- a/tests/tcctest.c
+++ b/tests/tcctest.c
@@ -2486,3 +2486,16 @@ void const_warn_test(void)
{
const_func(1);
}
+
+struct condstruct {
+ int i;
+};
+
+int getme (struct condstruct *s, int i)
+{
+ int i1 = (i == 0 ? 0 : s)-i;
+ int i2 = (i == 0 ? s : 0)-i;
+ int i3 = (i == 0 ? (void*)0 : s)-i;
+ int i4 = (i == 0 ? s : (void*)0)-i;
+ return i1 + i2 + i3 + i4;
+}
--
1.7.3.4
From 5c0a2366a3bb5bdeb3b3617389d4584375d5bfbc Mon Sep 17 00:00:00 2001
From: Michael Matz m...@suse.de
Date: Sun, 15 Apr 2012 01:06:46 +0200
Subject: [PATCH 2/9] Fix bitfield loads into char/short.
Removes a premature optimization of char/short loads
rewriting the source type. It did so also for bitfield
loads, thereby removing all the shifts/maskings.
---
tccgen.c|5 +++--
tests/tcctest.c |5 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/tccgen.c b/tccgen.c
index b0cec4a..2c759e1 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -2320,8 +2320,9 @@ ST_FUNC void vstore(void)
ft = vtop[-1].type.t;
sbt = vtop-type.t VT_BTYPE;
dbt = ft VT_BTYPE;
-if (((sbt == VT_INT || sbt == VT_SHORT) dbt == VT_BYTE) ||
-(sbt == VT_INT dbt == VT_SHORT)) {
+if sbt == VT_INT || sbt == VT_SHORT) dbt == VT_BYTE) ||
+ (sbt == VT_INT dbt == VT_SHORT))
+ !(vtop-type.t VT_BITFIELD)) {
/* optimize char/short casts */
delayed_cast = VT_MUSTCAST;
vtop-type.t = ft (VT_TYPE ~(VT_BITFIELD | (-1 VT_STRUCT_SHIFT)));
diff --git a/tests/tcctest.c b/tests/tcctest.c
index 723adc1..afb0825 100644
--- a/tests/tcctest.c
+++ b/tests/tcctest.c
@@ -1461,6 +1461,8 @@ void c99_bool_test(void)
void bitfield_test(void)
{
int a;
+short sa;
+unsigned char ca;
Re: [Tinycc-devel] Fwd: Use CString to concat linker options
Le mercredi 18 avril 2012 19:01:35, grischka a écrit : Gabriel Corneanu wrote: Hi, I had the same problem. Why don't you just modify build-tcc.bat to build tcc with -DONE_SOURCE also (just like libtcc)? Which may fix YOUR problem but doesn't fix THE problem. Anyway, since the CString wasn't zero-terminated either, I decided to do my contribution to this story, also: http://repo.or.cz/w/tinycc.git/commitdiff/4274c44de7dfb99a1058a5af515e9865c c9d2ff9 Ouch, I guess I thought the nul byte was systematically added or maybe I just forgot. Thanks. I saw a cstr_new at the top, did I forget it when reverting? Damn me. About the cstr_*, are they now part of the library on Windows? I mean if they are exported some people might start to use them, no? --- grischka Best regards, Thomas Preud'homme ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
