[fpc-devel] TryStrToFloat

The attached patch is a suggested implementation of TryStrToFloat, which (I hope) improves compatibility with Delphi Colin diff -uNr fpc/rtl/objpas/sysutils/sysstrh.inc fpc.w/rtl/objpas/sysutils/sysstrh.inc --- fpc/rtl/objpas/sysutils/sysstrh.inc 2005-01-02 21:32:50.0 + +++

[fpc-devel] Patch for linux syscalls

One of the syscall routines in rtl/linux/i386/syscall.inc checks for a return value in the range -4095..-1 as the error return, but all the rest just take a negative value as an error. I think the former is correct and attach a patch that will fix the rest. (I sent something to the list quite

[fpc-devel] utf8 reading

Can I offer the attached patch for reading utf8 strings from resource files? It simply converts the utf string to a normal string by discarding the high bits, but I had some files from Delphi or Kylix that were otherwise unreadable. Colin diff -uNr fpc/rtl/objpas/classes/classesh.inc

Re: [fpc-devel] utf8 reading

C Western wrote: Florian Klaempfl wrote: C Western wrote: Can I offer the attached patch for reading utf8 strings from resource files? It simply converts the utf string to a normal string by discarding the high bits, What would be the correct solution? I am showing my ignorance of multi byte

Re: [fpc-devel] utf8 reading

This discussion has inspired me to think a little more about what should be done in this specfic context, and I think the attached patch should do it. It is a more drastic patch than the previous one, and I don't have any widestring test material, but it passes some simple tests. I have copied

[fpc-devel] FPC and valgrind

I tried out valgrind on lazaraus and one of my own lcl programs, and was able to get it working by after applying some small patches to valgrind (which I have sent to the valgrind mailing lists). valgrind found some uninitialised memory reads, which the attached patch fixes. On a related

[fpc-devel] fpc_ShortStr_To_WideStr

Is the assignment to Size meant to be commented out? (I have just started having trouble with a program which I think has just started using widestrings because the DOM unit has been switched to widestrings.) Colin Function fpc_ShortStr_To_WideStr (Const S2 : ShortString): WideString; {$ifdef

Re: [fpc-devel] fpc_ShortStr_To_WideStr

peter green wrote: oops looks like i commented out the wrong line when changing the widestringmanager system for improved flexibility. the code should be: Function fpc_ShortStr_To_WideStr (Const S2 : ShortString): WideString; {$ifdef hascompilerproc} compilerproc; {$endif} { Converts a

Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)

Marco van de Voort wrote: var v : cardinal; begin v:=100; inc(v,-1); end. The reason is that -1 is in fact an addition of $ resulting in the carry flag being set and therefor an overflow. For cardinal IMHO not-a-bug? I think it's a bug for cardinals and other unsigned ints also

[fpc-devel] Linking problems (bug 4317)

The current svn does not work for me (bug 4317) but I can get it working with the attached patch. (It seems that the -T option makes ld not use it's default script) Colin diff -uNr trunk/fpcsrc/compiler/systems/t_linux.pas trunk.w/fpcsrc/compiler/systems/t_linux.pas ---

[fpc-devel] Small fixes

Attached are two small patches to fix: 1. TFPWriterXPM fails if there are more than 60 or so colours in the palette 2. Warnings when using ReadXMLFile Colin diff -uNr trunk/fpcsrc/fcl/xml/xmlread.pp trunk.w/fpcsrc/fcl/xml/xmlread.pp --- trunk/fpcsrc/fcl/xml/xmlread.pp 2005-10-19

Re: [fpc-devel] fpc.spec for x86_64

[EMAIL PROTECTED] wrote: Quoting Michael Van Canneyt [EMAIL PROTECTED]: On Sun, 20 Aug 2006 [EMAIL PROTECTED] wrote: Can I suggest the attached patch for fpc.spec? Without it I have problems building on the 64 bit Fedora core 5; with it the i386 and x86_64 can be installed simultaneously

[fpc-devel] syncobjs unit

Does the syncobjs unit in the FCL need to be machine dependent any more? The functionality seems to be in the thread manager for all the platforms that have threads, and I had some problems using the unit. (TRTLCriticalSection is defined in sybcobjs and as part of the system thread stuff). The

Re: [fpc-devel] CompareValue

Пётр Косаревский wrote: In the math unit are the CompareValue functions only for signed integers. Why not for DWORD and QWORD? I guess, that it's Delphi mimicing implementation (because it is Delphi-like). And it can be tricky to distinguish signed and unsigned expression values. Like, a:

Re: [fpc-devel] Important: Call for testing.

There seems to be a problem in TReader.FindComponentClass - the search in FindInFieldTable does not properly include ancestors. See attached patch Colin diff -uNr --exclude=.svn --exclude='*.rst' trunk/fpcsrc/rtl/objpas/classes/reader.inc trunk.w/fpcsrc/rtl/objpas/classes/reader.inc ---

Re: [fpc-devel] Important: Call for testing.

There also seems to be a problem with fixing up references to other components while reading - TLabel.FocusControl seems to be one of the things that is tripping this up. Local unresolved references are being silently discarded, but I think should be added to the global list. The attached

[fpc-devel] xlib patch

The recent xlib change seems to contain an infinite loop - the attached patch fixes it for me Colin diff -uNr --exclude=.svn --exclude='*.rst' trunk/fpcsrc/packages/x11/src/xlib.pp trunk.w/fpcsrc/packages/x11/src/xlib.pp --- trunk/fpcsrc/packages/x11/src/xlib.pp 2008-03-29 12:07:09.0

Re: [fpc-devel] Important: Call for testing.

Michael Van Canneyt wrote: Indeed. It completely short-circuits the idea of trying to locally resolve references before trying globally :) Anyway, your hint gave me the idea where to look. I fixed the issue properly. The error was in another routine altogether. Hopefully now 11060 is really

Re: [fpc-devel] Important: Call for testing.

Michael Van Canneyt wrote: Nono, it's good that you fixed your bug. You should never rely on the loading order. For forms, for instance, it is dependent on the creation in the IDE. A simple cut and paste could change the order. Relying on this would be bad practice. Absolutely The

Re: [fpc-devel] Important: Call for testing.

I have noticed another incompatibility with the previous version - the TParser object in parser.inc can now return toWString as one of the possibilities; the previous version returned toString regardless, but offered a wide and normal version of the string. This change breaks lazarus on wide

Re: [fpc-devel] Important: Call for testing.

Giulio Bernardi wrote: Maybe this patch (for lazarus) solves the issue? (warning: lazarus compiles and runs but I didn't test it). Giulio It seems to work reasonably OK for me. It doesn't handle the copyright symbol quite right that was causing me problems, but I don't think the previous

Re: [fpc-devel] childpos streaming fixed

Jonas Maebe wrote: On 12 Apr 2008, at 20:53, Michael Van Canneyt wrote: I hope to have fixed what seems to be the last open bug in the streaming system. Unless there are additional reports, the whole cleanroom implementation will be merged to fixes 2.2 and the release process for 2.2.2 will

[fpc-devel] Read from memory stream with position before start of file

While finding the bug #12897 I found that a memory stream position could be set to before the start of the file without giving an error, and subsequent reads would appear to work (unless the position was so far off an invalid region of memory was read). I found the precise problem by patching

Re: [fpc-devel] Read from memory stream with position before start of file

Michael Van Canneyt wrote: On Thu, 1 Jan 2009, Paul Ishenin wrote: Michael Van Canneyt wrote: While finding the bug #12897 I found that a memory stream position could be set to before the start of the file without giving an error, and subsequent reads would appear to work (unless the

Re: [fpc-devel] Read from memory stream with position before start of file

Paul Ishenin wrote: Michael Van Canneyt wrote: And writing ? Silently do nothing: procedure TForm4.Button1Click(Sender: TObject); var S: TMemoryStream; B: Byte; Count: Integer; begin S := TMemoryStream.Create; S.Position := -1; B := 1; S.Write(B, SizeOf(B));

[fpc-devel] cmem not aligning memory

I notice that the cmem unit does not align memory in the same way as the default unit - removing the cmem unit makes a factor of two difference in the speed of some double precision matrix code. (My system is i386). Inspecting the cmem unit indicates the issue is the extra bytes allocated for

Re: [fpc-devel] cmem not aligning memory

On 03/04/10 13:12, Jonas Maebe wrote: On 03 Apr 2010, at 14:09, Micha Nelissen wrote: Do C memory managers guarantee any alignment anyway? Not for SSE (16 bytes) I'm sure, but 8 bytes I don't know. From Linux' malloc man page: For calloc() and malloc(), the value returned is a pointer to

Re: [fpc-devel] cmem not aligning memory

On 08/04/10 14:12, Jonas Maebe wrote: On 08 Apr 2010, at 15:05, C Western wrote: How about an alternative implementation, without the integer recording size? I had a quick try at this - the only use of the MemSize routine in fpc+lazarus seems to be in an optimization in resizing strings

Re: [fpc-devel] can't build trunk for x86_64-linux (suse-64)

On 24/11/14 23:50, Gennady Agranov wrote: suse-32 builds fine though ... Anything obvious I have missed? Thanks, Gennady Start compiling package gdbint for target x86_64-linux. File libgdb.a not found Compiling gdbint/src/gdbint.pp Compiling gdbint/src/gdbcon.pp

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

On 26/03/16 09:19, Michael Van Canneyt wrote: I have implemented a new property TStringsSortStyle = (sslNone,sslUser,sslAuto); Property SortStyle : TStringsSortStyle Read FSortStyle Write SetSortStyle; I assume the meaning is clear. - Sorted is true if SortStyle is in [sslUser,sslAuto],

Re: [fpc-devel] Error seeking resources when copiling with {$R *.res}

Is {$R *.res} handled differently to {$R *.lfm}? (My projects have lots of {$R *.lfm} On 05/11/16 11:31, Thaddy de Koning wrote: On Fri, 4 Nov 2016 11:46:24 +0200 (EEST) {$R *.res} in ONLY allowed for the project file. You should never try to link in a * resource in a unit, because the *

[fpc-devel] Detecting clashing ppus

I recently encountered a problem with clashing .ppu files - see the thread in the lazarus mailing list "Strange problem compiling IDE". I found it difficult to track down, and it would have been much easier if the full pathname had been given. Looking at the compiler source this looks like a

[fpc-devel] Object checks

If I may, a couple of queries about code generated for object checking when range checks are on (-Cr): An explicit check for nil is generated, which seems redundant, as any attempt to use the value will generate a SIGSEGV anyway on most platforms, or am I missing something? If the

[fpc-devel] Bad code generation on linux x86_64

The following revision seems to be generating bad code for me on linux/x86_64: r36200 | florian | 2017-05-13 10:58:25 +0100 (Sat, 13 May 2017) | 1 line Changed paths: M /trunk/compiler/i386/aoptcpu.pas M /trunk/compiler/x86/aoptx86.pas * moved InstructionLoadsFromReg and

Re: [fpc-devel] Bad code generation on linux x86_64

On 21/05/17 08:45, Florian Klämpfl wrote: Am 20.05.2017 um 10:50 schrieb C Western: The following revision seems to be generating bad code for me on linux/x86_64: Can you please change line 26 in fpc compiler/x86/aoptx86.pas from { $define DEBUG_AOPTCPU} to {$define DEBUG_AOPTCPU} and post

Re: [fpc-devel] Bad code generation on linux x86_64

On 21/05/17 11:56, Florian Klämpfl wrote: Am 21.05.2017 um 11:23 schrieb C Western: On 21/05/17 08:45, Florian Klämpfl wrote: Am 20.05.2017 um 10:50 schrieb C Western: The following revision seems to be generating bad code for me on linux/x86_64: Can you please change line 26 in fpc

Re: [fpc-devel] Bad code generation on linux x86_64

On 21/05/17 10:23, C Western wrote: On 21/05/17 08:45, Florian Klämpfl wrote: Am 20.05.2017 um 10:50 schrieb C Western: The following revision seems to be generating bad code for me on linux/x86_64: Can you please change line 26 in fpc compiler/x86/aoptx86.pas from { $define DEBUG_AOPTCPU

Re: [fpc-devel] Object checks

On 05/05/17 12:54, Pierre Muller wrote: I applied a patch in commit 36113 to trunk that substitutes RunError with HandleError. It has been applied to three functions: fpc_help_destructor, fpc_check_object and fpc_check_object_ext Thank you for doing this. In the meantime I put a slightly

Re: [fpc-devel] Bad code generation on linux x86_64

On 21/05/17 16:08, Florian Klämpfl wrote: Am 21.05.2017 um 13:21 schrieb C Western: On 21/05/17 11:56, Florian Klämpfl wrote: Am 21.05.2017 um 11:23 schrieb C Western: On 21/05/17 08:45, Florian Klämpfl wrote: Am 20.05.2017 um 10:50 schrieb C Western: The following revision seems

Re: [fpc-devel] x86_64.inc CompareByte

On 31/10/17 11:47, Florian Klämpfl wrote: Am 30.10.2017 um 19:46 schrieb C Western: On 29/10/17 22:18, Florian Klämpfl wrote: I have committed your lastest patch with a few changes: the loop entry is aligned now to 16 bytes, I used movb instead of movbzl and inc instead of add. For me

Re: [fpc-devel] x86_64.inc CompareByte

On 29/10/17 22:18, Florian Klämpfl wrote: I have committed your lastest patch with a few changes: the loop entry is aligned now to 16 bytes, I used movb instead of movbzl and inc instead of add. For me (Haswell CPU) this works better. I think also these changes are better on average.

Re: [fpc-devel] Redundant compiler hints

On 25/03/18 22:29, Martok wrote: The hint was added in response to . Not very useful, other than to demonstrate 'inline' is rarely respected. However, it probably wasn't the intention to generate it for intrinsics as well? I am seeing lots of

Re: [fpc-devel] [fpc-pascal] MacOSX Mojave

ndLineTools/SDKs/MacOSX.sdk/usr/lib/'+startupfile) then + result:='/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/'+startupfile end    else result:=''; Am 06.10.18 um 16:01 schrieb C Western: Possibly unwisely, I updated by Mac to Mojave. I found that things (including 32

[fpc-devel] New sorting routines

I suspect the new sorting routines need some work - lazarus compiled with the latest trunk hangs on start up, and it looks like an infinite loop in sorting. Stack trace below. Colin #0  0x00422167 in DECLOCKED (L=2) at ../x86_64/x86_64.inc:709 #1  0x0042c325 in

Re: [fpc-devel] New sorting routines

On 04/02/2019 12:26, Nikolay Nikolov wrote: On 2/3/19 11:22 PM, C Western wrote: I suspect the new sorting routines need some work - lazarus compiled with the latest trunk hangs on start up, and it looks like an infinite loop in sorting. Stack trace below. Even though the sort routine did

Re: [fpc-devel] Internal error 2018062911

I can confirm thet the fpc build now works for me (and my application works also). Thanks for the quick fix Colin On 12/11/2019 02:22, J. Gareth Moreton wrote: All fixed, https://bugs.freepascal.org/view.php?id=36299 Gareth aka. Kit ___

[fpc-devel] Internal error 2018062911

I am seeing internal error 2018062911 with trunk r43441 and above. This may be the result of building with DEBUG on, but this configuration normally works fine for me. Colin External command "/home/me/fpc/trunk/fpcsrc/compiler/ppcx64 -Tlinux -FUfcl-xml/units/x86_64-linux/

Re: [fpc-devel] Internal error 2018062911

Gareth - It is indeed linux 64 bit. I use: make distclean DEBUG=1 install NOGDB=1 NOGDBMI=1 GDBMI=1 PREFIX=/home/me/usr64 FPC=/home/me/fpc/bootstrap/ppcx64 in the fpcsrc directory which gives: make -C fpcsrc distclean make[1]: Entering directory '/home/me/fpc/trunk/fpcsrc' make -C compiler

[fpc-devel] Internal error 200609171

I have a project that triggers Internal error 200609171 when compiled for 64 bit Mac with -gw3 set. It works fine on other platforms, or if a different debug mode is set. The error is triggered on the first var in the implementation section. I would create a bug report, only it is not obvious

[fpc-devel] Stack misalignment?

FPC version r44191 seems to be causing problems for a lazarus application – it crashes on exit, with a segmentation fault. This is x86_64 on linux, with the gtk2 widget set, and the crash occurs in one of the system gtk c library routines. If I am interpreting the gdb information correctly the

Re: [fpc-devel] Stack misalignment?

On 01/03/2020 08:45, Florian Klämpfl wrote: Am 29.02.20 um 12:12 schrieb C Western: I may not have diagnosed the underlying error correctly, but the crash after r44191 is certainly real – any thoughts on this? Any other tests I could try? Do you use -O4? Yes Thank uou for looking

Re: [fpc-devel] Stack misalignment?

On 01/03/2020 09:37, Florian Klämpfl wrote: Am 01.03.20 um 10:24 schrieb C Western: On 01/03/2020 08:45, Florian Klämpfl wrote: Am 29.02.20 um 12:12 schrieb C Western: I may not have diagnosed the underlying error correctly, but the crash after r44191 is certainly real – any thoughts

[fpc-devel] r45217 breaks Lazarus compile

Compiling Lazarus trunk with the latest fpc: components/ideintf/propedits.pp(6019,28) Fatal: Internal error 200709171 Colin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] r45217 breaks Lazarus compile

On 02/05/2020 10:36, C Western wrote: Compiling Lazarus trunk with the latest fpc: components/ideintf/propedits.pp(6019,28) Fatal: Internal error 200709171 Colin Seems now to be fixed in a recent update. However my program now crashes on exit in CSetThreadDebugNameA. (Why is this called

Re: [fpc-devel] r45217 breaks Lazarus compile

On 03/05/2020 20:59, C Western wrote: On 02/05/2020 10:36, C Western wrote: Compiling Lazarus trunk with the latest fpc: components/ideintf/propedits.pp(6019,28) Fatal: Internal error 200709171 Colin Seems now to be fixed in a recent update. However my program now crashes on exit

Re: [fpc-devel] r45217 breaks Lazarus compile

I have added protections against empty strings in r45237, though I would be quite curious what already called TThread.NameThreadForDebugging considering it was implemented only recently... In fact I had added a call to pthread_setname_np in my application a while ago, and I think there was

[fpc-devel] Can't compile 32 bit trunk on Mac OSX

I am not able to compile the current trunk for 32 bits on Mac OS High Sierra - some details below. (The 64 bit version compiles and runs fine.) Is this a specific issue with my setup, or something more general? Colin ... /bin/rm -f i386/ppc386 i386/ppc68k i386/ppcppc i386/ppcsparc

[fpc-devel] r47078 : customlistview.inc(646, 28) Error: Internal error 2020101001

Lazarus does not compile with the latest trunk, generating an internal error: customlistview.inc(646,28) Error: Internal error 2020101001       C.Width := Round(C.Width * AXProportion); This seems to have been introduced in r47078 The platform is linux x86_64, with lazarus compiled with

Re: [fpc-devel] r47078 : customlistview.inc(646, 28) Error: Internal error 2020101001

Seems to be fixed in r47084 Colin On 11/10/2020 09:12, C Western via fpc-devel wrote: Lazarus does not compile with the latest trunk, generating an internal error: customlistview.inc(646,28) Error: Internal error 2020101001       C.Width := Round(C.Width * AXProportion); This seems

Re: [fpc-devel] Can't compile 32 bit trunk on Mac OSX

On 15/08/2020 17:07, Jonas Maebe via fpc-devel wrote: On 14/08/2020 11:39, C Western wrote: I am not able to compile the current trunk for 32 bits on Mac OS High Sierra - some details below. (The 64 bit version compiles and runs fine.) Is this a specific issue with my setup, or something more

[fpc-devel] Apple M1 processor

I have been trying out compiling my main application for the new Apple M1 machines, and have two queries: The traceback on crashes does not include line numbers, when the same flags on other architectures does. Is this something that is easy to fix? Any pointers as to how? Related to this I

Re: [fpc-devel] Apple M1 processor

On 07/02/2021 14:40, Jonas Maebe via fpc-devel wrote: On 03/02/2021 11:58, Jonas Maebe via fpc-devel wrote: On 02/02/2021 16:48, C Western via fpc-devel wrote: Related to this I am trying to compile the rtl with debug information on by passing DEBUG=1 to the make install when compiling from

Re: [fpc-devel] Apple M1 processor

On 07/02/2021 14:45, Jonas Maebe via fpc-devel wrote: On 02/02/2021 16:48, C Western via fpc-devel wrote: My application works fine single threaded, but crashes occasionally when multi threaded, with what I think is some sort of memory corruption, but I haven't been able to pin this down yet