Fixes description:
====
2005/01/10 21:50:05 jonas
+ support for passing records in registers under darwin
* tcgpara now also has an intsize field, which contains the size in bytes of the whole parameter
====

I've initially filled bug report here:
http://www.freepascal.org/bugs/showrec.php3?ID=3563

After looking at problem source I've discovered that changing < ncgcal.pas > around 330 line back to pre-patch (old) condition fixes mine problems:

{$ifndef cpu64bit}
// Old code ---
//                    if left.location.size in [OS_64,OS_S64] then
// New code ---
//                    { don't call the cg64 stuff for 8-byte sized records etc }
//                    if is_64bit(left.resulttype.def) then
                    if left.location.size in [OS_64,OS_S64] then
                      cg64.a_param64_loc(exprasmlist,left.location,tempcgpara)
                    else
{$endif cpu64bit}

Mine problems seems to happen in this function (class method), but I can't reproduce it in simpler case:

function CDXUTButton.ContainsPoint(pt: TPoint): LongBool; // this is virtual
function
begin
  // this checking of class variable raises an exception
  if (Text = 'aaa') then begin end;
  // if line above is commented this function returns always false.
  Result:= PtInRect(m_rcBoundingBox, pt);
end;

Compilation is done with "-Sd -Or" parameters.

PS: changing declaration to use CONST doesn't change anything:
function CDXUTButton.ContainsPoint(const pt: TPoint): LongBool;

PPS: How this can be related to this bug report?
http://www.freepascal.org/bugs/showrec.php3?ID=1807

It seems to me the bug is that such structures should be handled by the paramanager.copy_value_on_stack() stuff, also in ncgcal. Using a_param64_loc() is not good, because it swaps the two dwords of the value depending on whether the target processor is little or big endian. Dword-swapped records are no fun either ;)

Jonas

I've found the problem. Some checks were missing, because it should have given an Internal error instead of generating buggy code. Still looking for a clean solution. In the meanwhile you can use your workaround as described above.

I've found the problem. Some checks were missing, because it should have given an Internal error instead of generating buggy code. Still looking for a clean solution. In the meanwhile you can use your workaround as described above.

Thanks, good to know that someone is looking over it