Re: [Open64-devel] Re: Open64/ORC as a source-to-source compiler (redux)

[Costin I. <cc...@lb...>]

Marc, the whirl2c that comes with the regular ORC distribution requires
a lot of modifications in order to be used as a source-to-source
translator.

There are problems with the correctness of the generated code  and there
are problems with the legality  of the output C code. You'll see
problems similar to the one you describe for any composite type
(aggregates and multi-dimensional arrays). There are also problems 
with  function return values. In addition, when trying
to compile files that include system header files the output code will
contain a lot of redefined/renamed  data types and system level 
variables.

Roy Ju from Intel mentioned some time ago that they might have a
cleaned up version of whirl2c that works well. I do not think it 
made it into the ORC release. 

Our  Berkeley UPC translator  also contains a cleaned up version
of whirl2c. The correctness problems are fixed in the code base and
we have  a wrapper script that handles  system header files. Our system
might just work for you with minor modifications.

Starting with any of these two will save you a lot of time. The problem
you describe is only the tip of the iceberg.

Costin 

> Marc Gonzalez-Sigler wrote:
> 
> > Take 183.equake, a single-file C program, from SPECfp2000 for example,
> > 
> > $ orcc -fe -keep quake.c
> > $ w2c quake.B
> > whirl2c translates quake.B into quake.w2c.h and quake.w2c.c, based on 
> > source quake.c
> > $ orcc -I. quake.w2c.c -lm (or gcc -I. quake.w2c.c -lm)
> > $ a.out < inp.in 1> stdout
> > $ head stdout
> > 3135: 4.60e+141 -1.40e+143 1.45e+142
> > 3135: 4.60e+141 -1.40e+143 1.45e+142
> > 3135: nan nan nan
> > 3135: nan nan nan
> > 
> > As you can see, the output is incorrect.
> > 
> > Has anybody tested whirl2c and whirl2f with the SPECfp2000 benchmarks? 
> > Did it work for you? (Perhaps I built the compiler incorrectly.)
> 
> $ cat testcase.c
> struct foo { int x; int y[3]; } bar;
> 
> int main(void)
> {
>    bar.y[1] = 666;
>    return 0;
> }
> 
> $ orcc -fe -keep testcase.c ; w2c testcase.B
> whirl2c translates testcase.B into testcase.w2c.h and testcase.w2c.c, 
> based on source testcase.c
> !!! DevWarn during W2C Initialization: Should use ST_pu_type instead
> !!! DevWarn during WHIRL To C: Count limit reached on the following DevWarn:
> !!! DevWarn during WHIRL To C: Should use ST_pu_type instead
> !!! DevWarn during WHIRL To C: Rehashing TY pointer map -- this should 
> NOT happen often
> 
> $ cat testcase.w2c.c
> [...]
> _INT32 main()
> {
>    (*(_INT32 *)(&((struct foo__0 *)(((_INT8 *) & bar) + 4LL))[1])) = 666;
>    return 0;
> } /* main */
> 
> Let char *p = &(bar.y)
> 
> ((_INT8 *) & bar) + 4LL == p (so far, so good)
> 
> (*(_INT32 *)(&((struct foo__0 *)p)[1])) = 666;
> 
> Then, p is incorrectly cast to a 'struct foo' pointer.
> 
> Let struct foo *WRONG = (struct foo *)p
> 
> (*(_INT32 *)(&WRONG[1])) = 666;
> 
> &WRONG[1] == p + 1*sizeof(struct foo)
> 
> We are now pointing *outside* bar :-)
> 
> I will try to fix it.
-- 
Costin C. Iancu                                 cc...@lb...
Future Technologies Group                       Phone: 510-495-2122
Lawrence Berkeley National Laboratory           Fax:   510-486-6900