|
From: | Christian Jullien |
Subject: | Re: [Tinycc-devel] _Generic or __builtin_choose_expr |
Date: | Sat, 8 Jul 2017 06:39:45 +0200 |
Mattias, The issue is that the 94_generic.c test expected results are machine dependent. This modified version below is more neutral and works on RPI. However it tests fewer cases. You should think of a better tests that deals in a portable way with const/non-const, signed/unsigned and different integer sizes you can meet on different architectures. address@hidden:~/tcc $ git diff tests/tests2/94_generic.c diff --git a/tests/tests2/94_generic.c b/tests/tests2/94_generic.c index 0655dd4..d9db14b 100644 --- a/tests/tests2/94_generic.c +++ b/tests/tests2/94_generic.c @@ -20,6 +20,8 @@ int b_f() return 10; } +typedef unsigned char * strtype; + #define gen_sw(a) _Generic(a, const char *: 1, default: 8, int: 123); int main() @@ -27,7 +29,7 @@ int main() int i = 0; struct b titi; const int * const ptr; - const char *ti; + const strtype ti; i = _Generic(a, int: a_f, const int: b_f)(); printf("%d\n", i); @@ -41,11 +43,11 @@ int main() printf("%d\n", i); i = _Generic(17, int :1, int **:2); printf("%d\n", i); - i = _Generic(17L, int :1, long :2, long long : 3); + i = _Generic(17L, int :2, long :2, long long : 2); printf("%d\n", i); - i = _Generic("17, io", const char *:1, char *:3, const int :2); + i = _Generic((strtype)"17, io", const strtype:1, strtype:3, const int :2); printf("%d\n", i); - i = _Generic(ti, const char *:1, char *:3, const int :2); + i = _Generic(ti, const strtype:1, strtype:1, const int :2); printf("%d\n", i); return 0; } -----Original Message----- On Fri, Jul 7, 2017 at 4:40 PM, Christian JULLIEN <address@hidden> wrote: > Just tested your > git clone -b mob https://github.com/cosmo-ray/tcc.git > > On RPI, I now get: > > --- ../../tests/tests2/94_generic.expect 2017-07-07 16:28:08.010486068 > +0200 > +++ 94_generic.output 2017-07-07 16:29:51.560466233 +0200 > @@ -1,9 +1 @@ > -20 > -20 > -123 > -2 > -5 > -1 > -2 > -3 > -1 > +94_generic.c:46: error: _Generic sellector of type 'char *' is not > compatible with any assosiation > > Also note that sellector has only one 'l' => selector > > Le : 06 juillet 2017 à 14:24 (GMT +02:00) De : "uso ewin" > <address@hidden> À : "address@hidden" > <address@hidden> Objet : Re: [Tinycc-devel] _Generic or > __builtin_choose_expr > > > > On Thu, Jul 6, 2017 at 2:09 PM, uso ewin <address@hidden> wrote: >> On Thu, Jul 6, 2017 at 6:11 AM, Christian Jullien <address@hidden> >> wrote: >>> On Windows 32bit as with RPi I get: >>> Test: 94_generic... >>> --- ../../tests/tests2/94_generic.expect 2017-07-06 >>> 06:06:36.520552800 +0200 >>> +++ 94_generic.output 2017-07-06 06:07:53.359318000 +0200 >>> @@ -1,9 +1 @@ >>> -20 >>> -20 >>> -123 >>> -2 >>> -5 >>> -1 >>> -2 >>> -3 >>> -1 >>> +94_generic.c:44: error: type march twice >>> make[2]: *** [Makefile:49: 94_generic.test] Error 1 >>> >> >> Ok the error happen because parse_btype, does never return VT_LONG. >> So I guess if a _Generic _expression_ contain a long long and a long in >> 64bit the error would happen too. >> >> I guess a solution would be either a global variable to force >> parse_btype to let long as long, or to patch every functions that >> call parse_btype so it take another argument which is here to force >> parse_btype to keep long as long. >> >> sorry for adding a bug. >> >> Matthias > > I've push the fix on my mob: > https://github.com/cosmo-ray/tcc/commit/fb26db96828291a9c4ae94394f1aa4 > d1289ae14f > > I've add a small commit so generic unqualify volatile too: > https://github.com/cosmo-ray/tcc/commit/e87939bfd385f412375f8a599e0b32 > 914b5e8488 > > If your okay with that, I push it on mob. > > Matthias > > _______________________________________________ > Tinycc-devel mailing list > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > > _______________________________________________ > Tinycc-devel mailing list > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > typo fix on my github I'm sorry but I don't have any arm machine, does someone have an idea how to fix, or debug this ? I guess parse_btype or type_decl return the wrong type at line 4726 of tccgen.c |
[Prev in Thread] | Current Thread | [Next in Thread] |