Re: [fpc-devel] Bug (Severe): Floating point values completely break GCC Struct compatability with records in 64-bit
Jonas Maebe schreef: On 16 Dec 2009, at 12:26, Joshua Cearley wrote: It seems that passing records with paired float fields is buggy on FPC/x86_64. Please file a bug report. While it is described in http://www.x86-64.org/documentation/abi.pdf, 3.2.3 Parameter Passing, I found http://blogs.sun.com/alblog/entry/amd64_aggregate_argument_passing clarifying. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: DOM thread-safety merge to 2.4.0?
> Unfortunately, it is too late, building has started. > Michael. Okay, I'll just patch it myself once it's out. Thanks anyway! -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug (Severe): Floating point values completely break GCC Struct compatability with records in 64-bit
On 16 Dec 2009, at 12:26, Joshua Cearley wrote: While working on a binding for the development branch for the Allegro game library I ran in to a bit of a problem in that one of the methods takes a structure of four floating point values (which is how it stores colors) and this is not done through a pointer to a color struct but by passing the structure directly to the method; this never actually works and exploring with GCC shows that the should-be C compatible record built by FPC 2.5 was fine but the version C had was corrupted. I went to FPC 2.4rc1 and tried again, and the same issue remains. 32-bit builds seem to work properly, so I conclude that only the 64-bit version of FPC is emitting broken code. It seems that passing records with paired float fields is buggy on FPC/ x86_64. Please file a bug report. I asked in IRC and was referred to here; unfortunately with Snow Leopard GCC compiles in 64-bit by default and so falling back to 32- bit is exceptionally painful. It's actually quite trivial: just pass "-arch i386" to gcc (or add it to CFLAGS in case of a configure/make build system). All system libraries are available in both 32 and 64 bit Intel versions. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Bug (Severe): Floating point values completely break GCC Struct compatability with records in 64-bit
While working on a binding for the development branch for the Allegro
game library I ran in to a bit of a problem in that one of the methods
takes a structure of four floating point values (which is how it stores
colors) and this is not done through a pointer to a color struct but by
passing the structure directly to the method; this never actually works
and exploring with GCC shows that the should-be C compatible record
built by FPC 2.5 was fine but the version C had was corrupted. I went to
FPC 2.4rc1 and tried again, and the same issue remains. 32-bit builds
seem to work properly, so I conclude that only the 64-bit version of FPC
is emitting broken code.
The following was generated with 2.4rc1;
Recreating this problem is fairly simple; first you have a source file
written in C code `cpart.c`:
/* Start */
#include
struct Bagel
{
float roundness, tastiness;
};
void PrintBagel(struct Bagel b)
{
printf("[Bagel Round:%f Tasty:%f]\n", b.roundness, b.tastiness);
}
/* End */
Then you have the trivial Pascal application `ppart.pp`:
(* Start *)
program ppart;
{$LINK cpart}
uses ctypes;
type
{$PACKRECORDS C}
TBagel = record
roundness, tastiness : CFloat;
end;
Procedure PrintBagel(bagel : TBagel); cdecl; external;
var
b : TBagel;
begin
b.roundness := 42.0;
b.tastiness := 1.0;
PrintBagel(b);
end.
(* End *)
Then we compile these:
skrylar)fpc-bug % gcc -c cpart.c && ppcx64 ppart
Free Pascal Compiler version 2.4.0rc1 [2009/10/24] for x86_64
Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Darwin for x86_64
Compiling ppart.pp
Assembling ppart
Linking ppart
22 lines compiled, 0.1 sec
skrylar)fpc-bug %
Run it:
skrylar)fpc-bug % ./ppart
[Bagel Round:0.00 Tasty:-170141183460469231731687303715884105728.00]
skrylar)fpc-bug %
Disassembling through GDB (AT&T Syntax ahead):
Dump of assembler code for function PASCALMAIN:
0x000109f0 : push %rbp
0x000109f1 : mov%rsp,%rbp
0x000109f4 : callq 0x100013970
0x000109f9 : lea0x1d218(%rip),%rax
# 0x10001dc18 <$PPART$_Ld1>
0x00010a00 : mov(%rax),%eax
0x00010a02 : lea0x2329f(%rip),%rdx
# 0x100023ca8
0x00010a09 : mov%eax,(%rdx)
0x00010a0b : lea0x1d20a(%rip),%rax
# 0x10001dc1c <$PPART$_Ld2>
0x00010a12 : mov(%rax),%eax
0x00010a14 : lea0x2328d(%rip),%rdx
# 0x100023ca8
0x00010a1b : mov%eax,0x4(%rdx)
0x00010a1e : lea0x23283(%rip),%rax
# 0x100023ca8
0x00010a25 : mov(%rax),%rdi
0x00010a28 : callq 0x10a3c
0x00010a2d : callq 0x100013d70
0x00010a32 : leaveq
0x00010a33 : retq
End of assembler dump.
Dump of assembler code for function PrintBagel:
0x00010a3c : push %rbp
0x00010a3d : mov%rsp,%rbp
0x00010a40 : sub$0x10,%rsp
0x00010a44 : movq %xmm0,-0x8(%rbp)
0x00010a49 : movss -0x4(%rbp),%xmm0
0x00010a4e : cvtss2sd %xmm0,%xmm1
0x00010a52 : movss -0x8(%rbp),%xmm0
0x00010a57 : cvtss2sd %xmm0,%xmm0
0x00010a5b : lea0x1d164(%rip),%rdi
# 0x10001dbc6
0x00010a62 : mov$0x2,%eax
0x00010a67 : callq 0x10001d976
0x00010a6c : leaveq
0x00010a6d : retq
0x00010a6e : nop
0x00010a6f : nop
End of assembler dump.
I asked in IRC and was referred to here; unfortunately with Snow Leopard
GCC compiles in 64-bit by default and so falling back to 32-bit is
exceptionally painful.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DOM thread-safety merge to 2.4.0?
On Tue, 15 Dec 2009, Seth Grover wrote: I just ran across this: http://bugs.freepascal.org/view.php?id=12984 http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=14145 And noticed that it is not present in either the 2.4.0 rc1 branch or the tags/release_2_4_0 tag. Is it to late for this to be merged in for the 2.4.0 release? I've got a critical bug in my project stemming from the fact that the DOM isn't thread safe, and I'd love for it to be fixed in 2.4.0 when that's released so I don't have to roll my own for my build environments. Unfortunately, it is too late, building has started. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
