Re: [Tinycc-devel] Some fixes for x86_64 and general code to enable compiling GCC

2012-04-21 Thread grischka

Michael Matz wrote:

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).


Thanks for sharing this moment of productive boredom.


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.


If practicable, could you post the recipe that you used to build
GCC with TCC?  (If it is a script you might just push it into our
'tests' directory.  There is already gcctestsuite.sh)

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.


It was fun to read, indeed.

--- grischka

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


Re: [Tinycc-devel] Some fixes for x86_64 and general code to enable compiling GCC

2012-04-21 Thread Michael Matz

Hi,

On Sat, 21 Apr 2012, grischka wrote:

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.


If practicable, could you post the recipe that you used to build GCC with 
TCC?  (If it is a script you might just push it into our 'tests' directory. 
There is already gcctestsuite.sh)


No script.  Just:

from directory in which `pwd`/gcc is the top-level dir of checked out gcc:
% mkdir devtcc; cd devtcc
% CC=/matz/git/tinycc/tcc -B/matz/git/tinycc/ ../gcc/configure \
  --disable-bootstrap --enable-languages=c,c++,fortran,java,objc
% make -j8

Recent checkouts of GCC will also have the va_arg fix already applied, so it 
should build well out of box with tcc's mob branch.  Note that I checked only 
the above self-build of gcc (i.e. including building its own runtime libs), I 
didn't run the testsuite; weekend was running out :)



Ciao,
Michael.

___
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

2012-04-18 Thread Michael Matz

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;