> -----Original Message-----
> From: Charles R. Hardnett [mailto:hardnett@xxxxxxxxxxxxx]
> Sent: Monday, June 25, 2001 6:48 AM
> To: pro64-support@xxxxxxxxxxx
> Subject: C to Whirl
>
>
>
>
> Hello,
>
> I have a question that involves the C to Whirl generation. I am using
> the whirl2C module, and noticed a bug with code such as the following:
>
>
> struct stat sbuf;
>
> if (sbuf.st_mode) {
> printf("hello");
> }
>
>
> The above code comes out of pro64 after whirl2c translation to look
> something like:
>
> if((_UINT32)(*(struct stat0 {
> _UINT64 st_dev;
> _UINT32 st_ino;
> _INT32 __pad1;
> _UINT32 st_mode;
> _UINT32 st_nlink;
> _UINT32 st_uid;
> _UINT32 st_gid;
> _UINT64 st_rdev;
> _INT64 st_size;
> _INT64 st_atime;
> _INT64 st_mtime;
> _INT64 st_ctime;
> _INT32 st_blocks;
> _INT32 __pad2;
> _UINT32 st_blksize;
> _INT32 __pad3;
> _INT64 __unused[6LL];
> } *)(((_INT8 *) & sbuf) + 16LL)) != 0U)
> {
> printf((const _INT8 *)(_INT8(*)[6LL]) "hello");
> }
>
>
> The problem of course is cast contains a declaration of the struct,
> and not just the name of the struct. I have tracked down the problem
> to where this only occurs when a struct field is accessed within a
> cond exp i.e. within while, if, for, etc.
>
> I have also convinced myself that the problem is not in the whirl2c
> conversion because it appears that whirl2C is only outputing the token
> information that is stored in the WN for this object's
> type. Therefore, it appears that the problem is the translation from C
> to whirl by GFEC is most likely the culprit.
Whirl is just an IR, the problem is not in WHIRL, its in Whirl2c itself
on how it handles type info while outputing the IR back into C.
Sun
|