Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
NR_S0<>NR_D0: they can be identified by the sub type. Further, one can perfectly assign NR_S1 to any location explicitly. Umm, my copy of narmcon.pas contains the following. NR_S0 = tregister($0406); NR_S1 = tregister($0406); NR_D0 = tregister($0407); I can see how the compiler can tell whether i'm assigning S0 or D0 but I don't see how it can tell whether I am assigning S0 or S1 when the constants I would use to make the assignment are defined to have the exact same value. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Am 11.03.2012 18:28, schrieb peter green: > >>> Are you saying that VFP registers are treated as multimedia registers >>> and not as FPU registers? If so presumablly that mean I should be >>> using LOC_MMREG and not LOC_FPUREG as the location for parameters and >>> return values? >>> >> >> Yes. >> > Thank you for your help so-far, i'm gradually making progress though > there is still some way to go. > > While i'm currently working on doubles (since double is the dominant > floating point type in my experiance and is also easier) at some point I > will need to support singles correctly as well and I just ran into an > issue that could pose a problem for making singles work correctly. > > It seems freepascal identifies registers using a series of constants > defined in rarmcon.inc which is generated from armreg.dat however to > workarround a deficiency in the register allocator the same "register > number" was allocated to both of the single precision registers that > overlap with any given double precision register. So it seems there is > no way to identify the two seperately within the compiler. This is a > problem because to correctly implement the EABI VFP calling convention I > need to use those registers. NR_S0<>NR_D0: they can be identified by the sub type. Further, one can perfectly assign NR_S1 to any location explicitly. Only the register allocator cannot use the odd single registers. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Are you saying that VFP registers are treated as multimedia registers and not as FPU registers? If so presumablly that mean I should be using LOC_MMREG and not LOC_FPUREG as the location for parameters and return values? Yes. Thank you for your help so-far, i'm gradually making progress though there is still some way to go. While i'm currently working on doubles (since double is the dominant floating point type in my experiance and is also easier) at some point I will need to support singles correctly as well and I just ran into an issue that could pose a problem for making singles work correctly. It seems freepascal identifies registers using a series of constants defined in rarmcon.inc which is generated from armreg.dat however to workarround a deficiency in the register allocator the same "register number" was allocated to both of the single precision registers that overlap with any given double precision register. So it seems there is no way to identify the two seperately within the compiler. This is a problem because to correctly implement the EABI VFP calling convention I need to use those registers. Any thoughts on how to get arround this? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Am 11.03.2012 15:37, schrieb Jonas Maebe: > > On 11 Mar 2012, at 15:14, Florian Klaempfl wrote: > >> Am 11.03.2012 13:22, schrieb Jonas Maebe: >>> * I'm don't think that requiring yet another different ARM >>> compiler binary for this is the proper way. There's already >>> enough confusion as it is with ppcarm variants. >> >> But isn't this caused by the fact that we have the same executable >> name while it generates different code? > > Yes. > >> I currently think that having even arm/armeb/armel/armhf as cpu >> types is the way to go. This allows also to have units for all four >> flavours on one system. Currently we simply don't support the same >> target cpu but different abi in any way in the build system. > > We also don't support an RTL compiled with -Cp386, -Cppentium, > -Cppentium2, -Cppentium2, -Cppentiumm, -Cfx86, -Cfsse2 and/or -Cfsse3 > on the same system. True, but they are not different abis, debian does not treat them different either. > For ARM hard float, you will also need different > sets of units depending on the exact kind of VFP cpu you have (unless > you always target the lowest common denominator -- if something like > that even exists for all VFP variants, since ARM is not that big on > backward compatibility and they have their own standard of encoding > the entire ABI, target cpu and all other details into attributes > inside every generated object file so that the linker can verify the > compatibility). But the abi stays on all hard float platforms the same? Indenpendent of the instruction set. > > Whether it's ABI or minimally required target cpu, the part that > causes the trouble is that you need a different set of units. I don't > think that renaming the compiler binary just for this particular case > is the right approach. Since the same compiler executable cannot run on the other platforms, I think naming them differently is reasonable. In general, I'd take the debian architecture scheme as measure. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: [Lazarus] FPC index/searcher classes committed.
On Sun, Mar 11, 2012 at 04:29, Michael Van Canneyt wrote: > We'd like people to try it and comment on the design and speed of the > engine, > and if you have suggestions for improvements, they're more than welcome. A good use/test would be to speed up "Find in Files" in Lazarus. -- Alexander S. Klenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
On 11 Mar 2012, at 15:40, peter green wrote: >> Just set a breakpoint in the place where one of the offending instructions >> is generated, found via grep. E.g., the only place where an LDF is generated >> is in arm/cgcpu.pas (in a_loadfpu_ref_reg). >> > Hmm, when I grepped for the first and most prolific problem instruction > (mvfd) I didn't find anything useful. Maybe I should have tried some of the > other problem intstructions. The instruction is MVF. The "D" is a size suffix (like "movl" or "movb" is not an instruction x86, but "mov" is) > Are you saying that VFP registers are treated as multimedia registers and not > as FPU registers? If so presumablly that mean I should be using LOC_MMREG and > not LOC_FPUREG as the location for parameters and return values? Yes. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Just set a breakpoint in the place where one of the offending instructions is generated, found via grep. E.g., the only place where an LDF is generated is in arm/cgcpu.pas (in a_loadfpu_ref_reg). Hmm, when I grepped for the first and most prolific problem instruction (mvfd) I didn't find anything useful. Maybe I should have tried some of the other problem intstructions. Once you figure out from where that routine gets called, then you do need some compiler knowledge: on ARM, the a_*fpu* routines are (should be) only be used in case of FPA. In case of VFP, the a_*mm* routines must be used instead. So there's probably a missing check for the new VFP FPU type you added (which you can easily figure out via a backtrace once the breakpoint is hit). Hmm, I think you may have identified my problem. Are you saying that VFP registers are treated as multimedia registers and not as FPU registers? If so presumablly that mean I should be using LOC_MMREG and not LOC_FPUREG as the location for parameters and return values? I suspect the next thing I actually need to do is come up with a reduced testcase. The assembler output of system.pp is MASSIVE. Unless you want to step through the entire compiler or code generator until you find where it goes wrong, that shouldn't matter. Ok It's neat until something goes wrong and you have to start figuring out how they compiled the compiler, or the person they downloaded it from. Experience tells us that if the compiler binaries have the same name, they should have the same behaviour. Otherwise support becomes hell (and it becomes equally difficult for users to know what to expect). Well the arm variants (arm, armeb, armel and my new armhf) DO announce themselves in the "target OS" line in the output so there is a fairly easy way to tell them apart. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
On 11 Mar 2012, at 15:14, Florian Klaempfl wrote: > Am 11.03.2012 13:22, schrieb Jonas Maebe: >> * I'm don't think that requiring yet another different ARM compiler >> binary for this is the proper way. There's already enough confusion >> as it is with ppcarm variants. > > But isn't this caused by the fact that we have the same executable name > while it generates different code? Yes. > I currently think that having even > arm/armeb/armel/armhf as cpu types is the way to go. This allows also to > have units for all four flavours on one system. Currently we simply > don't support the same target cpu but different abi in any way in the > build system. We also don't support an RTL compiled with -Cp386, -Cppentium, -Cppentium2, -Cppentium2, -Cppentiumm, -Cfx86, -Cfsse2 and/or -Cfsse3 on the same system. For ARM hard float, you will also need different sets of units depending on the exact kind of VFP cpu you have (unless you always target the lowest common denominator -- if something like that even exists for all VFP variants, since ARM is not that big on backward compatibility and they have their own standard of encoding the entire ABI, target cpu and all other details into attributes inside every generated object file so that the linker can verify the compatibility). Whether it's ABI or minimally required target cpu, the part that causes the trouble is that you need a different set of units. I don't think that renaming the compiler binary just for this particular case is the right approach. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
On 11 Mar 2012, at 14:55, peter green wrote: > >> Then I suggest you simply debug it like any other code: first set a >> breakpoint in options.pas where the fpu type should be set, and verify that >> it is in fact set. > I'm pretty sure it is getting set because I use it in generating the > assembler command line and i'm using an assembler wrapper that tells me what > the assembler command line is. > >> Then get the addresses of init_settings.fputype and >> current_settings.fputype, and set watchpoints on those to see whether they >> are still changed somewhere else. Also set a breakpoint in the code >> generator somewhere where it should decide whether to use AFP or VFP >> instructions, > I'll try but I'm having great trouble understanding how the code generator > works. Just set a breakpoint in the place where one of the offending instructions is generated, found via grep. E.g., the only place where an LDF is generated is in arm/cgcpu.pas (in a_loadfpu_ref_reg). Once you figure out from where that routine gets called, then you do need some compiler knowledge: on ARM, the a_*fpu* routines are (should be) only be used in case of FPA. In case of VFP, the a_*mm* routines must be used instead. So there's probably a missing check for the new VFP FPU type you added (which you can easily figure out via a backtrace once the breakpoint is hit). > I suspect the next thing I actually need to do is come up with a reduced > testcase. The assembler output of system.pp is MASSIVE. Unless you want to step through the entire compiler or code generator until you find where it goes wrong, that shouldn't matter. >> You can always select the appropriate default ABI via the global >> configuration file. >> > You can but IMO it's neater to have a compiler built to use appropriate > defaults for the system it's running on than to mess with generating and > updating architecture specific configuration files. It's neat until something goes wrong and you have to start figuring out how they compiled the compiler, or the person they downloaded it from. Experience tells us that if the compiler binaries have the same name, they should have the same behaviour. Otherwise support becomes hell (and it becomes equally difficult for users to know what to expect). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Am 11.03.2012 13:22, schrieb Jonas Maebe: > * I'm don't think that requiring yet another different ARM compiler > binary for this is the proper way. There's already enough confusion > as it is with ppcarm variants. But isn't this caused by the fact that we have the same executable name while it generates different code? I currently think that having even arm/armeb/armel/armhf as cpu types is the way to go. This allows also to have units for all four flavours on one system. Currently we simply don't support the same target cpu but different abi in any way in the build system. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Then I suggest you simply debug it like any other code: first set a breakpoint in options.pas where the fpu type should be set, and verify that it is in fact set. I'm pretty sure it is getting set because I use it in generating the assembler command line and i'm using an assembler wrapper that tells me what the assembler command line is. Then get the addresses of init_settings.fputype and current_settings.fputype, and set watchpoints on those to see whether they are still changed somewhere else. Also set a breakpoint in the code generator somewhere where it should decide whether to use AFP or VFP instructions, I'll try but I'm having great trouble understanding how the code generator works. I suspect the next thing I actually need to do is come up with a reduced testcase. The assembler output of system.pp is MASSIVE. continue and see what goes wrong. Some other comments about your patch: * please do not write code like this: if (target_info.abi <> abi_eabivfp) AND((p.proccalloption in [pocall_softfloat]) or (cs_fp_emulation in current_settings.moduleswitches) or (current_settings.fputype in [fpu_vfpv2,fpu_vfpv3,fpu_vfpv3_d16])) then Use this instead: if (target_info.abi <> abi_eabivfp) and ((p.proccalloption in [pocall_softfloat]) or (cs_fp_emulation in current_settings.moduleswitches) or (current_settings.fputype in [fpu_vfpv2,fpu_vfpv3,fpu_vfpv3_d16])) then Ok i'll try and remember that. * is hard float really only supported on ARMv7-A? There are several ARMv6 platforms that also support VFP. I belive it is in principle possible to use the hard float ABI with ARMv6. Not sure if any distro is doing so though. If there are it may make sense to make ARMv6 the default for an armhf compiler. * I'm don't think that requiring yet another different ARM compiler binary for this is the proper way. There's already enough confusion as it is with ppcarm variants. I think that there should be no problem to support both vfp-softfloat and vfp-hardfloat using the same binary, which should get rid of all the FPC_ARMHF defines. Currently the only FPC_ARMHF defines are selecting different defaults. You should still be able to select either ABI manually with either compiler binary if you wish. You can always select the appropriate default ABI via the global configuration file. You can but IMO it's neater to have a compiler built to use appropriate defaults for the system it's running on than to mess with generating and updating architecture specific configuration files. * "eabivfp" as a name for the ABI is confusing. The existing VFP support also uses the eabi. But it doesn't use the vfp variant of eabi. Something like eabihardfp would be better. mmm, I mused a bit over that name. It is at least in principle possible to have EABI variants for FPUs other than vfp. I don't think any currently exist though and if they do I guess one could always select on the FPU type. So maybe eabihf or eabihardfloat is indeed a better choice. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
On 11 Mar 2012, at 13:00, peter green wrote: > That in turn triggers a block of code that I added to options.pas which sets > the default fpu to "fpu_vfpv3_d16" and errors out if the user manually > specifies a FPU that is not a VFP variant. Then I suggest you simply debug it like any other code: first set a breakpoint in options.pas where the fpu type should be set, and verify that it is in fact set. Then get the addresses of init_settings.fputype and current_settings.fputype, and set watchpoints on those to see whether they are still changed somewhere else. Also set a breakpoint in the code generator somewhere where it should decide whether to use AFP or VFP instructions, continue and see what goes wrong. Some other comments about your patch: * please do not write code like this: if (target_info.abi <> abi_eabivfp) AND((p.proccalloption in [pocall_softfloat]) or (cs_fp_emulation in current_settings.moduleswitches) or (current_settings.fputype in [fpu_vfpv2,fpu_vfpv3,fpu_vfpv3_d16])) then Use this instead: if (target_info.abi <> abi_eabivfp) and ((p.proccalloption in [pocall_softfloat]) or (cs_fp_emulation in current_settings.moduleswitches) or (current_settings.fputype in [fpu_vfpv2,fpu_vfpv3,fpu_vfpv3_d16])) then * is hard float really only supported on ARMv7-A? There are several ARMv6 platforms that also support VFP. * I'm don't think that requiring yet another different ARM compiler binary for this is the proper way. There's already enough confusion as it is with ppcarm variants. I think that there should be no problem to support both vfp-softfloat and vfp-hardfloat using the same binary, which should get rid of all the FPC_ARMHF defines. You can always select the appropriate default ABI via the global configuration file. * "eabivfp" as a name for the ABI is confusing. The existing VFP support also uses the eabi. Something like eabihardfp would be better. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Where is the FPU set to a VFP type? I set it in code. Defining FPC_ARMHF selects a new version of "system_arm_linux_info" which sets the ABI to abi_eabivfp. That in turn triggers a block of code that I added to options.pas which sets the default fpu to "fpu_vfpv3_d16" and errors out if the user manually specifies a FPU that is not a VFP variant. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Florian Klaempfl wrote: Am 11.03.2012 12:01, schrieb peter green: It appears to me (i'm not an expert on arm assembler and I can't seem to find any documentation on FPA) that FPC is generating FPA instructions even though the FPU is set to a VFP type. What i'm really struggling to work out is why the heck that is happening. From telling freepascal to include source lines as comments in the assembler it doesn't look like inline assembler is responsible. Can you please post the full assembler listing of a procedure containing such code? .section .text.n_system_$$_assign$real48$$double .balign 4 .globlSYSTEM_$$_assign$REAL48$$DOUBLE .typeSYSTEM_$$_assign$REAL48$$DOUBLE,#function SYSTEM_$$_assign$REAL48$$DOUBLE: # Temps allocated between r13+4 and r13+12 # [346] begin stmfdr13!,{r14} subr13,r13,#12 # Var $result located in register d0 # Var b located at r13+0 strr0,[r13] addr2,r13,#4 movr1,#6 .Lj10088: ldrbr3,[r0], #1 subsr1,r1,#1 strbr3,[r2], #1 bne.Lj10088 # [347] D:=real2double(b); addr0,r13,#4 blxSYSTEM_$$_REAL2DOUBLE$REAL48$$DOUBLE mvfdd0,f0 # Var $result located in register d0 # [348] end; fstdd0,[r13] ldfdf0,[r13] addr13,r13,#12 ldmfdr13!,{r15} .Le332: .sizeSYSTEM_$$_assign$REAL48$$DOUBLE, .Le332 - SYSTEM_$$_assign$REAL48$$DOUBLE ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
On 11 Mar 2012, at 12:01, peter green wrote: > When I try to build my patched compiler (using make compiler_cycle > 'OPT=-dFPC_ARMHF' ) the starting compiler builds the RTL and compiler > successfully (as would be expected) but when ppc1 tries to build the RTL > things fail with assembler errors. The errors below are a sample of the types > of error seen (there are a HUGE number of each) > > /fpc/rtl/units/arm-linux/system.s:19075: Error: selected processor does not > support ARM mode `mvfd d0,f0' > /fpc/rtl/units/arm-linux/system.s:19077: Error: selected processor does not > support ARM mode `ldfd f0,[r13]' > /fpc/rtl/units/arm-linux/system.s:41169: Error: selected processor does not > support ARM mode `ldfs f0,[r13]' > > It appears to me (i'm not an expert on arm assembler and I can't seem to > find any documentation on FPA) that FPC is generating FPA instructions even > though the FPU is set to a VFP type. Where is the FPU set to a VFP type? You have to add -Cfvfpv2 or so to OPT to select a VFP FPU. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Am 11.03.2012 12:01, schrieb peter green: > It appears to me (i'm not an expert on arm assembler and I can't seem > to find any documentation on FPA) that FPC is generating FPA > instructions even though the FPU is set to a VFP type. What i'm really > struggling to work out is why the heck that is happening. From telling > freepascal to include source lines as comments in the assembler it > doesn't look like inline assembler is responsible. Can you please post the full assembler listing of a procedure containing such code? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
I've made some progress on armhf porting, i've added the nessacery frameworks (vfpv3_d16 FPU target, EABIVFP ABI target, FPC_ARMHF define) and made a start on actually implementing the new ABI. I decided to start with function results. However i've now reached a problem which has me stumped. When I try to build my patched compiler (using make compiler_cycle 'OPT=-dFPC_ARMHF' ) the starting compiler builds the RTL and compiler successfully (as would be expected) but when ppc1 tries to build the RTL things fail with assembler errors. The errors below are a sample of the types of error seen (there are a HUGE number of each) /fpc/rtl/units/arm-linux/system.s:19075: Error: selected processor does not support ARM mode `mvfd d0,f0' /fpc/rtl/units/arm-linux/system.s:19077: Error: selected processor does not support ARM mode `ldfd f0,[r13]' /fpc/rtl/units/arm-linux/system.s:41169: Error: selected processor does not support ARM mode `ldfs f0,[r13]' It appears to me (i'm not an expert on arm assembler and I can't seem to find any documentation on FPA) that FPC is generating FPA instructions even though the FPU is set to a VFP type. What i'm really struggling to work out is why the heck that is happening. From telling freepascal to include source lines as comments in the assembler it doesn't look like inline assembler is responsible. Anyone have any suggestions on where things might be going wrong and how to debug this? I've attatched a patch containing my efforts so far. Index: rtl/arm/setjump.inc === --- rtl/arm/setjump.inc (revision 20511) +++ rtl/arm/setjump.inc (working copy) @@ -16,7 +16,7 @@ function fpc_setjmp(var S : jmp_buf) : longint;assembler;[Public, alias : 'FPC_SETJMP'];nostackframe; compilerproc; asm -{$if defined(FPUVFPV2) or defined(FPUVFPV3)} +{$if defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)} {$if defined(CPUARMV3) or defined(CPUARMV4) or defined(CPUARMV5)} fstmiax r0!, {d8-d15} {$else} @@ -46,7 +46,7 @@ movsr0, r1 it eq moveq r0, #1 -{$if defined(FPUVFPV2) or defined(FPUVFPV3)} +{$if defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)} fldmiad ip!, {d8-d15} {$endif} ldmia ip,{v1-v6, sl, fp} @@ -57,7 +57,7 @@ mov ip, r0 movsr0, r1 moveq r0, #1 -{$if defined(FPUVFPV2) or defined(FPUVFPV3)} +{$if defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)} {$if defined(CPUARMV3) or defined(CPUARMV4) or defined(CPUARMV5)} fldmiax ip!, {d8-d15} {$else} Index: rtl/arm/math.inc === --- rtl/arm/math.inc (revision 20511) +++ rtl/arm/math.inc (working copy) @@ -14,7 +14,7 @@ **} -{$if defined(FPUFPA) or defined(FPUFPA10) or defined(FPUFPA11) or defined(FPUVFPV2) or defined(FPUVFPV3)} +{$if defined(FPUFPA) or defined(FPUFPA10) or defined(FPUFPA11) or defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)} {$define FPC_SYSTEM_HAS_ABS} function fpc_abs_real(d : ValReal) : ValReal;compilerproc; begin Index: rtl/arm/mathu.inc === --- rtl/arm/mathu.inc (revision 20511) +++ rtl/arm/mathu.inc (working copy) @@ -177,7 +177,7 @@ begin end; -{$elseif defined(darwin) or defined(FPUVFPV2) or defined(FPUVFPV3)} +{$elseif defined(darwin) or defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_d16)} const _VFP_ENABLE_IM = 1 shl 8; { invalid operation } Index: rtl/arm/arm.inc === --- rtl/arm/arm.inc (revision 20511) +++ rtl/arm/arm.inc (working copy) @@ -30,7 +30,7 @@ {$if not(defined(wince)) and not(defined(gba)) and not(defined(nds)) and not(defined(FPUSOFT)) and not(defined(FPULIBGCC))} {$define FPC_SYSTEM_HAS_SYSINITFPU} -{$if not defined(darwin) and not defined(FPUVFPV2) and not defined(FPUVFPV3)} +{$if not defined(darwin) and not defined(FPUVFPV2) and not defined(FPUVFPV3) and not defined(FPUVFPV3_D16)} Procedure SysInitFPU;{$ifdef SYSTEMINLINE}inline;{$endif} begin { Enable FPU exceptions, but disable INEXACT, UNDERFLOW, DENORMAL } Index: rtl/arm/setjumph.inc === --- rtl/arm/setjumph.inc (revision 20511) +++ rtl/arm/setjumph.inc (working copy) @@ -16,7 +16,7 @@ type jmp_buf = packed record -{$if defined(FPUVFPV2) or defined(FPUVFPV3)} +{$if defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)} d8,d9,d10,d11,d12,d13,d14,d15: double; {$endif} v1,v2,v3,v4,v5,v6,sl,fp,sp,pc : dword; Index: compiler/ninl.pas === --- compiler/ninl.pas (revision 20511) +++ compiler/ninl.pas (working copy) @@ -3094
Re: [fpc-devel] FreeNotification and opRemove
On Sun, 11 Mar 2012, Martin wrote: On 08/03/2012 13:34, Martin wrote: On 08/03/2012 13:08, michael.vancann...@wisa.be wrote: On Thu, 8 Mar 2012, Martin wrote: Further more: the program below, does not crash in delphi (turbo delphi) I also noticed. I suspect the problem is the owner; If it gets a free notification, it should pass it to all the children. I initially posted this to see if the behaviour would be considered a bug (rather than wrong user code) Seeing that Delphi does not crash, I assume I can consider it a bug, and report? Yes, please. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel