tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] _Generic or __builtin_choose_expr


From: Ramsay Jones
Subject: Re: [Tinycc-devel] _Generic or __builtin_choose_expr
Date: Sat, 8 Jul 2017 14:04:18 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1


On 08/07/17 05:39, Christian Jullien wrote:
> 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.

This also fails on 32-bit Linux:

  $ uname -a
  Linux satellite-18-32bit 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:58:04 
UTC 2016 i686 i686 i686 GNU/Linux
  $ 

  $ make test
  ...
  Test: 94_generic...
  --- ../../tests/tests2/94_generic.expect      2017-07-08 12:36:44.056422769 
+0100
  +++ 94_generic.output 2017-07-08 12:37:28.921214574 +0100
  @@ -1,9 +1 @@
  -20
  -20
  -123
  -2
  -5
  -1
  -2
  -3
  -1
  +94_generic.c:44: error: type march twice
  Makefile:47: recipe for target '94_generic.test' failed
  make[2]: *** [94_generic.test] Error 1
  make[2]: Target 'all' not remade because of errors.
  make[2]: Leaving directory '/home/ramsay/tinycc/tests/tests2'
  Makefile:80: recipe for target 'tests2-dir' failed
  make[1]: *** [tests2-dir] Error 2
  make[1]: Leaving directory '/home/ramsay/tinycc/tests'
  Makefile:350: recipe for target 'test' failed
  make: *** [test] Error 2
  $ 

Also, note the typo in the error message 'type _march_ twice',
rather than 'type match twice'.

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

That may be true, but I think tcc is also at fault. BTW, gcc does
not have a problem with this test:

  $ gcc  -o gcc-generic tests/tests2/94_generic.c
  $ ./gcc-generic >gcc-actual
  $ diff -u tests/tests2/94_generic.expect gcc-actual
  $ 

However, looking in the debugger, it seems that tcc can't tell
that the constant '17L' has the 'long' type - it seems to think
that it is an 'int'. Indeed, if you look at the end of parse_btype(),
we find:
  
      /* long is never used as type */
      if ((t & VT_BTYPE) == VT_LONG)
  #if PTR_SIZE == 8 && !defined TCC_TARGET_PE
          t = (t & ~VT_BTYPE) | VT_LLONG;
  #else
          t = (t & ~VT_BTYPE) | VT_INT;
  #endif
  
ATB,
Ramsay Jones




reply via email to

[Prev in Thread] Current Thread [Next in Thread]