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?
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>
Hi Arushi,> 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 ) );I bet the call occurs before the function is defined. In this case C treats the callee as being a varargs function (...) of the kind you see in your IR. Ciao, Duncan.> > 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
Hi Arushi,> 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;I just remembered that Kernighan and Ritchie style declarations like this don't have the semantics you might expect. In particular this is not equivalent to saying TypHandle Cyclotomic ( TypHandle hdRes, long n, long m ) If you change the declaration to the previous line, does the nasty bitcasting go away? Ciao, Duncan.