[LLVMdev] Incompatible types at call site
arushi987 at gmail.com
Wed Apr 6 06:26:02 PDT 2011
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
> 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
> 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 )
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev