RE : [fpc-devel] Major problem with Move and Array of Int64
> > > I use latest FPC from /trunk/ and this problem just started > happening recently. > > Pseudo code > > Write To SQL as Blob (using parameter binding) > > Param.AsString=uInt64Array.toBlob(MyList); > > unit "uInt64Array" > > procedure fromBlob(List,string) > count=length(string) div 8; // size of int64 > SetLength(List,count) > iPos:=1; > for iLcv=0 to Count-1 do begin > System.Move(String[iPos],List[iLcv],8); > Inc(iPos,8); > end; > end; > > function toBlob(List):string; > begin > iLen=System.Length(List)*8; > System.SetLength(Result,iLen); > iPos:=1; > for iLcv:=0 to High(List) do begin > System.Move(List[iLcv],Result[iPos],8); > Inc(iPos,8); > end; > end; > > Posting to the MySQL 5.1 database : the field size is as > expected. Retrieving /converting the list (asString) from the > database with all values set to small numbers appears to work > Retrieving converting the list (asString) from teh database > with larger values no longer works. > > Did anyone do anything to System.Move? > Did anyone recently do work on BLOB features to MySQL 5.1 > connector? What is "large". Remember that the upper limit for blobs sent in a sql statement is max_allowed_packet. Default is 1M. http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_m ax_allowed_packet To send larger blobs you need to prepare the statement and send data in chuncks. Not supported in sqldb. Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM native compilation (Toshiba AC100)
Thomas Schatzl wrote: That is a known issue with 2.4.4 that it does not compile trunk with optimization turned on. There seems to be a bug that has been existing for a long time that has been triggered by code changes in 18230; the ARM compiler is not as well maintained as others. I think 2.4.4 definitely builds when specifying -O- as extra build options though. I am working on it, however I fear that -O- will need to be set for some time. So I wonder what version/revision Delphi uses? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM native compilation (Toshiba AC100)
Hi, On Fri, 23 Sep 2011 08:17:17 +, Mark Morgan Lloyd wrote: Thomas Schatzl wrote: That is a known issue with 2.4.4 that it does not compile trunk with optimization turned on. There seems to be a bug that has been existing for a long time that has been triggered by code changes in 18230; the ARM compiler is not as well maintained as others. I think 2.4.4 definitely builds when specifying -O- as extra build options though. I am working on it, however I fear that -O- will need to be set for some time. So I wonder what version/revision Delphi uses? The build that is used is the build with softfloat support (it's the only one we provide), which may be the only one that is affected by the recent bug(s), i.e. it is used as a starting compiler (in the original email). Further, reading Sash0k's original email again, he might be able to avoid the issue by cross-compiling a start compiler to ARM from a current trunk compiler enabling VFP (hardware FP) support. See http://wiki.freepascal.org/iPhone/iPod_development#Building_an_ARM_Cross-compiler for ideas. Btw, I'm not sure what FP type is using in his build because he does not specify. Delphi cross-compiles too, so it might be okay. Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: r18252 - x*x -> sqr(x) optimization (Was: Re: [fpc-devel] ARM native compilation (Toshiba AC100))
On 23 Sep 2011, at 01:21, Thomas Schatzl wrote:
I found that 18251 is okay, but the newer ones are not when
compiling with -O2. It seems that one optimization that transforms
expressions of type x*x into sqr(x) for floats in 18252 (and 18257
and 18263 that seem to have been fixing issues with the original
implementation) causes troubles. With that in place, a compiler
cycle hangs at ppc2 compiling something (processing real2str.inc
from the system unit fyi).
Florian, Jonas, any ideas? Seems to be related to softfloat code
generation because apparently other platforms are fine.
The optimization changes x*x into sqr(x). For ARM/softfloat, the
compiler calls the fpc_sqr_real() helper from the RTL.
The code of this helper is:
function fpc_sqr_real(d : ValReal) : ValReal;compilerproc;{$ifdef
MATHINLINE}inline;{$endif}
begin
result := d*d;
end;
So yes, this clearly puts the compiler into an endless loop. I'm not
sure what would be a clean fix for this (other than completely
disabling the transformation; does it improve the generated code that
much beyond what CSE can achieve?)
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM native compilation (Toshiba AC100)
Am 23.09.2011 10:52, schrieb Thomas Schatzl: Btw, I'm not sure what FP type is using in his build because he does not specify. He wrote it in the mail titled "Re: fpc-devel Digest, Vol 89, Issue 82": === quote begin === Toshiba AC100 have 2 Cortex-A9 cores. Arm architecture is "armv7" I use Ubuntu 11.04 armel. It means: ARM, EABI, Little Endian. Float point mode now is "softfloat". But in the future I plan to migrate to Debian hardfloat port: http://wiki.debian.org/ArmHardFloatPort === quote end === Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: r18252 - x*x -> sqr(x) optimization (Was: Re: [fpc-devel] ARM native compilation (Toshiba AC100))
Hi,
On Fri, 23 Sep 2011 10:52:17 +0200, Jonas Maebe wrote:
On 23 Sep 2011, at 01:21, Thomas Schatzl wrote:
I found that 18251 is okay, but the newer ones are not when
compiling with -O2. It seems that one optimization that transforms
expressions of type x*x into sqr(x) for floats in 18252 (and 18257
and 18263 that seem to have been fixing issues with the original
implementation) causes troubles. With that in place, a compiler cycle
hangs at ppc2 compiling something (processing real2str.inc from the
system unit fyi).
Florian, Jonas, any ideas? Seems to be related to softfloat code
generation because apparently other platforms are fine.
The optimization changes x*x into sqr(x). For ARM/softfloat, the
compiler calls the fpc_sqr_real() helper from the RTL.
The code of this helper is:
function fpc_sqr_real(d : ValReal) : ValReal;compilerproc;{$ifdef
MATHINLINE}inline;{$endif}
begin
result := d*d;
end;
So yes, this clearly puts the compiler into an endless loop. I'm not
sure what would be a clean fix for this (other than completely
Other options I see:
- disable if using softfloat knowing that the soft float code just
transforms this into the same code sequence again
- move it to i386 specific optimizations since afaik it is the only
arch which has an instruction which benefits from that.
disabling the transformation; does it improve the generated code that
much beyond what CSE can achieve?)
I doubt it has any noticeable impact.
Thomas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Major problem with Move and Array of Int64
23.09.2011 5:52, Andrew Brunner пишет: I use latest FPC from /trunk/ and this problem just started happening recently. ... Posting to the MySQL 5.1 database : the field size is as expected. Retrieving /converting the list (asString) from the database with all values set to small numbers appears to work Retrieving converting the list (asString) from teh database with larger values no longer works. Did anyone do anything to System.Move? Did anyone recently do work on BLOB features to MySQL 5.1 connector? Recently strings behavior was changed, they are now codepage-aware. The compiler can now implicitly convert strings from one encoding to another. To handle non-string data, you should use RawByteString type, or better yet non-string types like (dynamic) array of byte. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE : r18252 - x*x -> sqr(x) optimization (Was: Re: [fpc-devel] ARMnative compilation (Toshiba AC100))
> function fpc_sqr_real(d : ValReal) :
> ValReal;compilerproc;{$ifdef
> MATHINLINE}inline;{$endif}
> begin
>result := d*d;
> end;
>
> So yes, this clearly puts the compiler into an endless loop. I'm not
> sure what would be a clean fix for this (other than completely
> disabling the transformation; does it improve the generated
> code that
> much beyond what CSE can achieve?)
-O2 doesn't optimize the follow into a new call to fpc_sqr_real (svn 18901):
function fpc_sqr_real(d : ValReal) : ValReal;compilerproc;inline;
Begin
fpc_sqr_real:=d;
fpc_sqr_real:=fpc_sqr_real*d;
End;
Ludo
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Major problem with Move and Array of Int64
On Friday 23 September 2011 14.00:07 Sergei Gorelkin wrote: > > Recently strings behavior was changed, they are now codepage-aware. The > compiler can now implicitly convert strings from one encoding to another. > To handle non-string data, you should use RawByteString type, or better > yet non-string types like (dynamic) array of byte. > So TBlobField.Value probably should be changed to array of byte and there should be a TField.AsByteArray property? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Major problem with Move and Array of Int64
On Fri, Sep 23, 2011 at 1:07 AM, LacaK wrote: > TMySQL51Connection ? I'm using TMySQL51Connection. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Major problem with Move and Array of Int64
On Fri, Sep 23, 2011 at 7:00 AM, Sergei Gorelkin wrote: > Recently strings behavior was changed, they are now codepage-aware. The > compiler can now implicitly convert strings from one encoding to another. To > handle non-string data, you should use RawByteString type, or better yet > non-string types like (dynamic) array of byte. I always felt uncomfortable with converting binary types to strings because I know older strings with #0 would cause memory leaks. I think this has something to do with the problem. I think blobs should be stream objects so we can write/read that way. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Major problem with Move and Array of Int64
On Fri, Sep 23, 2011 at 7:28 AM, Martin Schreiber wrote: > On Friday 23 September 2011 14.00:07 Sergei Gorelkin wrote: >> >> Recently strings behavior was changed, they are now codepage-aware. The >> compiler can now implicitly convert strings from one encoding to another. >> To handle non-string data, you should use RawByteString type, or better >> yet non-string types like (dynamic) array of byte. >> > So TBlobField.Value probably should be changed to array of byte and there > should be a TField.AsByteArray property? > Yes, Certainly. Or better even Stream objects. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Major problem with Move and Array of Int64
Andrew Brunner schrieb: On Fri, Sep 23, 2011 at 7:28 AM, Martin Schreiber wrote: On Friday 23 September 2011 14.00:07 Sergei Gorelkin wrote: Recently strings behavior was changed, they are now codepage-aware. The compiler can now implicitly convert strings from one encoding to another. To handle non-string data, you should use RawByteString type, or better yet non-string types like (dynamic) array of byte. So TBlobField.Value probably should be changed to array of byte and there should be a TField.AsByteArray property? Yes, Certainly. Or better even Stream objects. Why not use (or introduce) an TBlob type, matching the need of DB users and other users, which currently use strings for storing raw bytes. It must not be a really new type, just an alias for the suggested type for such content. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Major problem with Move and Array of Int64
On Friday 23 September 2011 16.32:21 Hans-Peter Diettrich wrote: > >> So TBlobField.Value probably should be changed to array of byte and > >> there should be a TField.AsByteArray property? > > > > Yes, Certainly. Or better even Stream objects. > > Why not use (or introduce) an TBlob type, matching the need of DB users > and other users, which currently use strings for storing raw bytes. It > must not be a really new type, just an alias for the suggested type for > such content. > String index is one-based, array of byte index is null-based and has no copy on write semantic, a TStream is not refcounted and must be destroyed in code if copied by TBlobField or is invalid if the TField instance is destroyed if not copied by TBlobField. Programs can not handle String, array of byte or TStream in the same way. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM native compilation (Toshiba AC100)
On 9/22/2011 14:38, Sven Barth wrote: On 22.09.2011 18:03, waldo kitty wrote: On 9/22/2011 03:28, Sven Barth wrote: Compiling the trunk compiler is only supported when using the latest release (currently 2.4.4) as a starting compiler. where in the SVN can this be pulled from, please. would it be (from memory) tags/release_2_4_4? Yes, but you'll need a compiler of the previous release (2.4.2) for that one. i believe i do... i use macros douglas' (i think i got the name right) method from the wiki... one of the first steps is to pull down a bootstrap compiler and tools... i don't believe that that compiler is altered during the script/make run... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TField.Validate in FPC 2.6
Am 17.09.2011 10:18, schrieb Joost van der Sluis: On Sat, 2011-09-17 at 10:56 +0200, Michael Van Canneyt wrote: On Sat, 17 Sep 2011, Martin Schreiber wrote: Hi, TField.SetData() in fixes_2_6 calls TField.Validate(). 2.4.4 does not, trunk neither. Strange that 2.6 does this if trunk does not ? What are the plans for the upcoming release? Will FPC 2.6.0 call TField.Validate() in TField.SetData()? It should not. There were some changes regarding this, and I still didn't look at them. I will and decide how to solve this. (I think I'll revert it all) Has a decision been made already? I should know if I must implement workarounds into MSEgui. Thanks, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
