[LLVMdev] Incompatible types at call site

[Arushi Aggarwal]

On Wed, Apr 6, 2011 at 1:41 AM, Duncan Sands <baldrick at free.fr> wrote:

> Hi Arushi,
>
>
>  When it asks for the castOpcode, it assumes both types are
>> unsigned(indicated by
>> the false arguments).
>>
>> Is it correct to assume this?
>>
>
> yes, because the behaviour of the original code was undefined.
>
> Ciao, Duncan.
>
> PS: This is the sort of thing that happens when a function is declared with
> a
> prototype such as
>  void *Cyclotomic(void *, long, int)
> but the function actually has a different prototype, for example
>  void *Cyclotomic(void *, long, long)
> and the function is called from a place that has only seen the wrong
> prototype.
> In short, this is usually a bug in the original code.  Confusion between
> int and
> long is common, since on 32 bit platforms they are the same but differ on
> 64 bit
> platforms.  Of course it could also be a compiler bug.  You got this from
> compiling Fortran with dragonegg, right?  What was the original code?
>

I got this from C code compiled by llvm-gcc.

There is a consistent prototype for the function

TypHandle       Cyclotomic ( hdRes, n, m )
    TypHandle           hdRes;
    long                n,  m;

the call looks as follows,
 hdI = ProdCyc( hdI, Cyclotomic( HdResult, n, 1 ) );

which is basically

Cyclotomic( HdResult, n, 1 );

The problem is the fact that it interprets 1 as an int32 instead of an
int64. And later converts it by assuming an unsigned to unsigned cast.

Arushi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110406/5359a8d1/attachment.html>