I'm going to have to keep trying. So far that gets me the following
(some debug lines I inserted into the compiler):
record UCOMPLEX.complex
- alignment = 8
- aggregatealignment = 8
- structalignment = 8
- size = 16
I was wrong about what I said about RECORDMIN=16... the alignment fields
are still equal to 8, but it puts the byte offset of the 2nd field to 16.
There might be a bug in my vectorcall code that prevents the correct
alignment (plus I need to double-check which alignment field is which).
If there is a bug, I'll post a test and a patch to fix it.
Gareth aka. Kit
On 21/10/2019 20:53, Florian Klämpfl wrote:
Am 21.10.19 um 21:42 schrieb J. Gareth Moreton:
On 21/10/2019 20:00, Florian Klämpfl wrote:
What's the problem with
{$push}
{$codealign RECORDMIN=16}
type complex = record
re : real;
im : real;
end;
{$pop}
?
Hi Florian,
I tried that, but that puts each individual field on a 16-byte boundary
Then do:
{$push}
{$codealign RECORDMIN=16}
type dummyrec = record
b : byte;
end;
{$pop}
type complex = record
case byte of
1 : (
re : real;
im : real
);
2 : (alignmentdummy : dummyrec);
end;
I thought I mentioned this trick even somewhere :)
parameters passed into the function may not be aligned (e.g. when
deferencing a pointer on the heap after calling, say,
"New(complex);"), hence why the compiler can only go by the 8-byte
aggregate alignment.
No. Data is guaranteed to be aligned at it's natural boundary when it
is passed without further information.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
