There could have been a typeconversion around the pointerconstn/niln.
This was hidden because llvmtype fixed it up later, but with opaque
pointers it showed up again.
pasbool8type for this results in too much trouble (we mustn't use i1
for parameters, because then LLVM will try to apply the ABI convention
for passing "1 bit" values, or in records because then this may
result in unwanted bitpacking). Downside: the new LLVMBool1 type is
also exposed in the system unit, because we need it to define LLVM
intrinsics...
git-svn-id: trunk@33726 -
if the it's an addn/subn. For comparisons, the resultdef is boolean, and
left and right will already have the same type (with addn/subn, one could
be a pointer and the other an integer)
git-svn-id: trunk@32523 -
constants on llvm, as you can only compare with "null" in that case
* convert all arguments to integers in case of pointer subtractions,
as pointer subtractions are not supported by llvm
git-svn-id: trunk@30485 -
fpu: treat them as extended when they are loaded into registers, and as
int64 when loading from/storing to memory
git-svn-id: branches/hlcgllvm@26048 -
