You do not need to compute IntTy with the switch (which would assert on x86_64). Note that you can just use IntegerType::get(N) to return the integer type of width N (which in fact the code right above is already doing).
However, even with this change this will break x86_64, because the memset intrinsics expect an int32 parameter for the alignment. Its not clear to me why PIC16 should need the alignment to be an int16; this is a small constant integer, not something for which code is actually generated. It is inconsistent to have the alignment be int32 for the 64-bit and 32-bit memcpy intrinsics and 16-bit for PIC16. - Daniel On Wed, Nov 19, 2008 at 1:20 AM, sanjiv gupta <[EMAIL PROTECTED]> wrote: > We use hard coded Int32Ty while converting aggregate copy to a memmove, > which is wrong in case of PIC16.(PIC16 has int type as i16). > > I have attached a patch to address this. Please let me know if it is ok > to commit. > > > - Sanjiv > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
