Re: [fpc-devel] LLVM code generator

On 03/12/2018 07:57, Ryan Joseph wrote: What does this mean for end users? Do we get better debugging support in LLDB? Sorry for getting slightly off topic (replies to lazarus list pleas / or fpc other). Lazarus 2.0 has an LLDB based debugger, that uses it's own code (fpdebug) for watches.

[fpc-devel] wrong step-over with fpc debug info / how to do objcopy on Mac, or strip .debug_frame

With reference to https://bugs.freepascal.org/view.php?id=34159 It *appears* that this issue also happens on Mac, using lldb (so both lldb and gdb get step-over wrong, with debug info from fpc). Posts by "bigDan": http://forum.lazarus-ide.org/index.php/topic,42869.msg303599.html#msg303599

Re: [fpc-devel] question about thread.WaitFor

On 11/11/2018 18:32, Martin wrote: Moreover, variables/fields are only destroyed with .free, not with thread termination, so why does it matter? If SomeHandler is the method of an object that is about to be destroyed, then it must be ensured, that it will not be called after

Re: [fpc-devel] question about thread.WaitFor

On 11/11/2018 18:21, Marco van de Voort wrote: Op 2018-11-11 om 17:58 schreef Martin: assuming code like this.   SomeThread.Terminate;   SomeThread.WaitFor; and assuming that SomeThread has at some time before that done   Thread.Queue(..., SomeHandler) And the queued item had not run yet

[fpc-devel] question about thread.WaitFor

Hi, assuming code like this.   SomeThread.Terminate;   SomeThread.WaitFor; and assuming that SomeThread has at some time before that done   Thread.Queue(..., SomeHandler) And the queued item had not run yet. Is WaitFor guaranteed (or supposed) do have the queued message handled? I know it

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

LVM is its slowness but the resulting code is awesome. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

t Exception Handling" supported by LLVM, for example the runtime part: https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/compiler/__mla__personality.pas Works well so far. Martin ___ fpc-devel maillist - fpc-devel@

Re: [fpc-devel] How to suppress warnings in code?

On Thursday 27 September 2018 09:11:01 Martin Schreiber wrote: > On 9/26/18 6:38 PM, Sven Barth via fpc-devel wrote: > > Please provide concrete examples. > > Here: > https://gitlab.com/mseide-msegui/mseide-msegui/tree/fpc_3_2 > Bug report: https://bugs.freepascal.org/view

Re: [fpc-devel] How to suppress warnings in code?

ot; "mseformatstr.pas" will be compiled with warnings. BTW, compiletimes (s): run 2 3 4 FPC fixes_2_6 39.6 37.8 38.6 FPC fixes_3_0 53.9 53.3 53.8 FPC fixes_3_2 64.6 68.1 65.3 OpenSUSE LEAP 42.3 4 x Intel(R) Pentium(R) CPU J2900 @ 2.41GHz, 3.

[fpc-devel] How to suppress warnings in code?

Hi, How can individual warnings be suppressed in code in Free Pascal fixes_3_2? {$warn off} seems not to work reliable in some projects if compiled with -B. Thanks, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http

Re: [fpc-devel] Graphical RAD IDE in FPC

Hi Alexander, It is not allowed to discuss MSEide+MSEgui themes here. I will answer on the MSEide+MSEgui mailing list: https://sourceforge.net/projects/mseide-msegui/lists/mseide-msegui-talk Archive: https://www.mail-archive.com/mseide-msegui-talk@lists.sourceforge.net/ Martin

Re: [fpc-devel] Graphical RAD IDE in FPC

nerves anymore to fight such battles, MSEide+MSEgui users must become active themselves. Please don't answer to this mail, use the MSEide+MSEgui mailinglist instead: https://sourceforge.net/projects/mseide-msegui/lists/mseide-msegui-talk Archive: https://w

[fpc-devel] debug info by FPC upsets GDB when step-over

I am not sure when this started. It is certainly happening with fpc 3.0.4 and trunk. I do not know if it worked with earlier versions, but afaik user complaints only started since Lazarus was released with 3.0.4 - It happens with all versions of GDB. (So it is not something that changed in

Re: [fpc-devel] SizeOf( const typcasted as shortstring)

On 13/08/2018 02:32, Martin wrote: On 13/08/2018 00:12, Dmitry Boyarintsev wrote: On Sun, Aug 12, 2018 at 5:40 PM Bart <mailto:bartjun...@gmail.com>> wrote: const   x = ShortString('abc'); begin   writeln(SizeOf(x)); end. Delphi (7) prints 256, fpc

Re: [fpc-devel] SizeOf( const typcasted as shortstring)

On 13/08/2018 00:12, Dmitry Boyarintsev wrote: On Sun, Aug 12, 2018 at 5:40 PM Bart > wrote: const   x = ShortString('abc'); begin   writeln(SizeOf(x)); end. Delphi (7) prints 256, fpc prints 3. Is that a bug or an implementation

Re: [fpc-devel] Bug 33983: Bad Photoshop files decoding

On 17/07/2018 23:57, Maxim Ganetsky wrote: Hello. I just moved bug 33983 ("Bad Photoshop files decoding") to FPC project. Can somebody unassign it from user wp and adjust its incorrect "feedback" status so it won't get lost? Done. ___ fpc-devel

Re: [fpc-devel] Is this a bug? TFPImageCanvas.StretchDraw

Btw, a 2nd issue. If you put the dark read pixels on the right most edge of the image (reduce width to 22), then it is missing in the stretched image.   ScFI := TFPCompactImgRGBA8Bit.Create(22, 30); ... ScFI.Colors[20,i] := c;     //c.blue := 10;     c.Red := $7F7F;     ScFI.Colors[21,i]

[fpc-devel] Is this a bug? TFPImageCanvas.StretchDraw

I am investigating this, because similar artefacts can be seen in the new PPI related stretched images in Lazarus. Add below code to a form with 2 TImages on it. (on windows / fpc 3.1.1 39275) It stretches the image to 3 times it size. The magnified result (bottom part) 1) For a single

Re: [fpc-devel] Pure function Wiki page

On 08/07/2018 19:22, J. Gareth Moreton wrote: At the same time, I would argue that, really, the programmer should code something like this: c := sin(x); if c > y then b := c; There probably isn't any harm in supporting such optimisation though. Talking about this Maybe it is worth to

Re: [fpc-devel] Pure function Wiki page

On 08/07/2018 16:50, J. Gareth Moreton wrote: Hi everyone, With some blessing from Florian on the concept, I've set up a Wiki page discussing the design proposals for the support of pure functions, as well as some explanation on what they actually are. wiki.freepascal.org/Pure_functions I

Re: [fpc-devel] threads vs widestringmanager / crash

e debugger. The debugger interrupts the target early on. And that does create a thread in the target. If such an external thread happens, would fcp execute the code in question? Could/Should there be a nil check at the location of the crash? On 07/07/2018 14:40, Martin wrote: "TThread.Queue" cr

Re: [fpc-devel] threads vs widestringmanager / crash

should* do (but is really rather a hack)   {$IFDEF MsWindows}  if WideStringManager.GetStandardCodePageProc = nil then Any better ideas? On 07/07/2018 14:00, Martin wrote: fpc 3.0.4 Win 10 / 32bit Lazarus trunk, but that may not be relevant. This is the first time I am seeing this, and I am therefo

[fpc-devel] threads vs widestringmanager / crash

fpc 3.0.4 Win 10 / 32bit Lazarus trunk, but that may not be relevant. This is the first time I am seeing this, and I am therefore not sure I will be able to reproduce, since it seems a race condition. This appears to happen during unit initialization. Something must have started a thread,

Re: [fpc-devel] Wrong docs: not initialized global variables

On 03/07/2018 19:27, Ondrej Pokorny wrote: On 7/3/2018 9:40 AM, Ondrej Pokorny wrote: program Project1; var    S: string; begin    SetLength(S, 10); // <<< warning here --->> WHY    Writeln(S[2]);    // <<< no warning here --->> WHY end. The compiler tells me that the line

Re: [fpc-devel] Optimization theory

On 25/06/2018 16:18, J. Gareth Moreton wrote: One would need to develop some tight timing tests to determine the fastest method for a given number of cases.  As Florian once stated... it takes a large number of jumps before the standard linear subtraction search (where the ordinal difference

Re: [fpc-devel] Optimization theory

On 24/06/2018 23:28, J. Gareth Moreton wrote: On paper, a binary search is the fastest method to locate a data pointer associated with a key (in this case, an opcode). Forgive me for stepping in, given that I hardly looked at your work, nor the particular part of fpc. But the fastest way

Re: [fpc-devel] TThread.Queue and TThread.Destroy

On 21/06/2018 21:21, Sven Barth via fpc-devel wrote: Would you please test with trunk? There it already checks for aMethod. Indeed, it works with trunk. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] TThread.Queue and TThread.Destroy

On 21/06/2018 01:27, Martin wrote: fpc 3.0.4 / Linux 64bit (Fedora) What should happen if: - A Thread has queued a call with "TThread.Queue" - The Thread gets Terminated and Destroyed before the queued method can be executed.   That is the thread checks for "Terminated&quo

[fpc-devel] TThread.Queue and TThread.Destroy

fpc 3.0.4 / Linux 64bit (Fedora) What should happen if: - A Thread has queued a call with "TThread.Queue" - The Thread gets Terminated and Destroyed before the queued method can be executed.   That is the thread checks for "Terminated" and exits Execute before the queued method can be

Re: [fpc-devel] FPC trunk compiler slower than 3.0.4

On 18/05/2018 17:32, Ondrej Pokorny wrote: Hello, I observe that FPC trunk compiler is about 65-70% (factor 1.65-1.7) slower than FPC 3.0.4 compiler. E.g. building Lazarus IDE takes on my machine: 1:00 with FPC 3.0.4 1:40 with FPC trunk Do you observe the same? Any hints why? Is anybody

Re: [fpc-devel] Wrong docs: not initialized global variables

specific point (although I quite agree with Ondrej), > I just want to remind that the cost in terms of diminishing userbase > is real, and that makes me sad. Agreed 100%. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.f

Re: [fpc-devel] Why debugger does not "step in"?

On 24/03/18 19:34, Jonas Maebe wrote: https://bugs.freepascal.org/view.php?id=14399 Will your fix (2018-01-13 16:59) be in 3.0.6? Or 3.2 only? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Why debugger does not "step in"?

On 24/03/18 17:58, Gennady Agranov wrote: >>> It isn't a method of an "interface"? interfaces indeed have this issue. It is the case - thanks! Is it "nothing can be done about it" case? Is there an already submitted bug? Not sure if there is a bug report. I am not even sure if this is: -

Re: [fpc-devel] Why debugger does not "step in"?

On 24/03/18 02:24, Gennady Agranov wrote: Hi, I use FPC 3.0.4 / Lazarus 1.8.2 I am seeing the same behavior when I debug the program using Lazarus IDE under Win64 and Linux64 When I want to "step in" into my own function/procedure - GDB simply steps over... If I set a breakpoint inside

Re: [fpc-devel] Suspicion about TThread.Synchronize

Ok, I got it again in the debugger. Since it is nor reproducible all the times, I am using auto continue breakpoints, and just record that they were hit. So I have limited data. - After a long series of syncs ThreadQueueTail is nil. - A thread calls ThreadQueueAppend (from within Syncronize)

Re: [fpc-devel] Suspicion about TThread.Synchronize

On 04/02/2018 20:33, Martin wrote: On 04/02/2018 20:23, Sven Barth via fpc-devel wrote: Would you please test whether my change in r38115 (applied to 3.0.2) makes any difference? Calling RemoveQueuedEvents() with a thread, but no method (which happens during a thread's destruction) was up

Re: [fpc-devel] Suspicion about TThread.Synchronize

On 04/02/2018 20:23, Sven Barth via fpc-devel wrote: Would you please test whether my change in r38115 (applied to 3.0.2) makes any difference? Calling RemoveQueuedEvents() with a thread, but no method (which happens during a thread's destruction) was up to then a way to corrupt the queue.

Re: [fpc-devel] Suspicion about TThread.Synchronize

On 04/02/2018 19:17, Sven Barth via fpc-devel wrote: On 03.02.2018 17:39, Martin wrote: All based on win32 Pretext: I have an issue with a crash in PopThreadQueueHead called by CheckSynchronize.  (3.0.2) It happens in the Lazarus IDE, but at a low percentage only. (And not yet in the debugger

[fpc-devel] Suspicion about TThread.Synchronize

All based on win32 Pretext: I have an issue with a crash in PopThreadQueueHead called by CheckSynchronize.  (3.0.2) It happens in the Lazarus IDE, but at a low percentage only. (And not yet in the debugger) I don't think the below is related, but I found it while looking around. Potential

Re: [fpc-devel] TCollection.FOwner

to change component streaming behavior. It is difficult to see all consequences with inlined and inherited components and all possible combinations. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/lis

[fpc-devel] register / ABI for constructor and destroy

I am trying to update pascal script. It seems that at some time there where changes in the register usage for calling constructors. At least I found the following code:   {$IF DEFINED (fpc) and (fpc_version < 3)}     if IsConstructor or IsVirtualCons then  

[fpc-devel] const param documentation

https://www.freepascal.org/docs-html/current/ref/refsu67.html#x179-20100014.4.4 Just came to notice something But first: I had been under the impression, that if you - define a param as const - pass a global variable - violate the contract, by modifying the global var while in the scope of

[fpc-devel] windres.h / issue https://bugs.freepascal.org/view.php?id=32015

Hi, about https://bugs.freepascal.org/view.php?id=32015 is there a reason why those files are not in fpcbuild? https://bugs.freepascal.org/view.php?id=29698#c90689 Cyrax (reporter)  2016-03-06 14:42 Related files to windres needs to

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On 28/06/2017 20:03, Martok wrote: Interestingly, I just ran into "bad" code generation with exactly the properties discussed in this thread. Because every declared element is covered, the generated code for it ends up being a computed goto: and most importantly, not into any else statement.

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On 07/06/2017 00:04, Denis Kozlov wrote: Consider the code fragment below. Currently, FCP 3.0.2 with -O3 shows "uninitialized result" warning for Convert2 and Convert3 functions, but not for Convert1. I find this perfect as is, and, of course, you can rightfully disagree. You suggest that

Re: [fpc-devel] Mantis/Bugtracker registrations fixed

On 31/05/2017 15:50, Karoly Balogh (Charlie/SGR) wrote: Hi, We had numerous reports over the past few weeks, that the FPC/Lazarus Bugtracker registration verification was broken. Thanks to the work of Michael van Canneyt, it should be fixed now. If you had trouble creating a bugtracker account

[fpc-devel] Different results of random(int32) and random(int64) for negative limit value

ot; Is this intended? If not, which one is correct? https://www.freepascal.org/docs-html/current/rtl/system/random.html states for 32 and 64 bit " Random returns a random number larger or equal to 0 and strictly less than L. " which raises the questi

Re: [fpc-devel] Let's Encrypt cert and mantis.freepascal.org

On 02/05/2017 22:59, Michael Van Canneyt wrote: That's probably good as the fastest / short-term solution, but as long as both DNS records are valid and point to the same IP address (and http access to both is redirected to the https version), the certificate should cover both domain names

[fpc-devel] Overflow in TMemoryStream?

quarter if (NewCapacity>FCapacity) and (NewCapacity < (5*FCapacity) div 4) then NewCapacity := (5*FCapacity) div 4; " Isn't there an overflow if the capacity grows above high(ptrint) div 5 (about 430MB on 32 bit)? IIRC there was a discussion on the list about memory problems with big TMemo

Re: [fpc-devel] "Default" discussion for SmartPointers etc

I second this. It is really sad what happened with the Delphi language and even worse with Free Pascal and its different dialects in recent years. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Unicode paths

hem > (being public) > Is there a possibility to still get the raw data in case one wants to handle encoding himself? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Ability to handle instance pointers as ordinal type.

On 21/02/2016 11:15, Sven Barth wrote: Would it be possible to implement? Yes Would that mean that instance pointers would be handled as ordinal values? No, because "case" is merely a parser construct. In principle the condition and the case labels could be anything. String constants aren't

[fpc-devel] delays sending to this list

Is there any known issue? I recently noted a few times that mails I sent to this list take rather long (some more than an hour) before they reach this list. The problem is not with the list delivery to me, the delayed message is also missing from

[fpc-devel] debug info for nested procedures

procedure TForm1.FormCreate(Sender: TObject); var i: Integer; procedure foo; begin i := i + 1; end; begin i := 11; foo; Caption := IntToStr(i); end; it appears that fpc now adds explicit debug info for "i" in the nested procedure (dwarf and stabs)? And when using

Re: [fpc-devel] delays sending to this list

On 10/02/2016 17:45, Martin wrote: Is there any known issue? I recently noted a few times that mails I sent to this list take rather long (some more than an hour) before they reach this list. The problem is not with the list delivery to me, the delayed message is also missing from http

[fpc-devel] debug info for nested procedures

procedure TForm1.FormCreate(Sender: TObject); var i: Integer; procedure foo; begin i := i + 1; end; begin i := 11; foo; Caption := IntToStr(i); end; it appears that fpc now adds explicit debug info for "i" in the nested procedure (dwarf and stabs)? And when using

Re: [fpc-devel] debug info for nested procedures / Solved

Please ignore the below. "i" was a bad choice for testing. There may be a global var somewhere. works fine, when the variable name is not used elsewhere. On 10/02/2016 17:31, Martin wrote: procedure TForm1.FormCreate(Sender: TObject); var i: Integer; procedure foo; begin

[fpc-devel] ifthen bugs (maybe)

just found some issues Neither syntax works in constant evaluation. Not sure if they should, so asking here (the 2nd syntax is operator like, so kind of expected it would) both cause an internal error trying to take the address of the returned candidate. Then again this might not be a valid

Re: [fpc-devel] Debuginfo for dynamic arrays

On 24/01/2016 14:06, Martin Schreiber wrote: Hi, For a "array of integer" type variable FPC 32bit stabs returns for gdb "ptype" command " type = ^(array [0..-1] of LONGINT) ". MSEide uses this info to fetch the itemcount and item memory and to show the array item

[fpc-devel] Debuginfo for dynamic arrays

e" returns " type = ^LONGINT ". How can we identify a dynamic array with FPC dwarf? Thanks, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Debuginfo for dynamic arrays

On Sunday 24 January 2016 15:20:04 Martin wrote: > On 24/01/2016 14:06, Martin Schreiber wrote: > > How can we identify a dynamic array with FPC dwarf? > > If I remember correctly then you can do (after you got above result) > ptype foo^ > or if foo is an

Re: [fpc-devel] Dwarf-3

On 24/01/2016 16:03, Florian Klämpfl wrote: Dwarf-3 can handle dyn. arrays much better. What do you think about switching the default dwarf level from 2 to 3? The last gdb I tested on win (32bit vista) was gdb 10.0 (current is 10.1) And (IIRC) it still crashes (gdb exe has stopped

Re: [fpc-devel] Dwarf-3

On Sunday 24 January 2016 17:17:57 Martin wrote: > On 24/01/2016 16:03, Florian Klämpfl wrote: > > Dwarf-3 can handle dyn. arrays much better. What do you think about > > switching the default dwarf level from 2 to 3? > > The last gdb I tested on win (32bit vista) was gdb 1

[fpc-devel] build process of official releases (3.0 / win)

Someone pointed out that the official build and the 3.0 included in lazarus differ. http://forum.lazarus.freepascal.org/index.php/topic,30663.msg195462.html#msg195462 http://forum.lazarus.freepascal.org/index.php/topic,30663.msg195577.html#msg195577 Of course this can easily be caused by

Re: [fpc-devel] Fwd: While - Otherwise Statement

o be one of the very few thinking this given the > enthousiasm with which people are discussing this. > We are at least two people. :-) > Soon I will be forced to emigrate to Javascript country. Or to MSElang? ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Fwd: While - Otherwise Statement

wkitt...@windstream.net wrote: a... my bad... sorry 'bout that... i've been thinking about this, too... 'else' and 'otherwise' mean the same thing... what they seem to be looking for is 'aswell'... foo := 0; while foo < 100 do begin inc(foo); end; aswell begin dec(foo);

Re: [fpc-devel] Fwd: While - Otherwise Statement

On 12/10/2015 20:01, Max Nazhalov wrote: I can't think of a use case either. And just because another language provides such a solution, does not imply that FPC should. +1 (despite my earlier contribution) Discussion of the feature below, is regardless of it not being desirable (in any form)

Re: [fpc-devel] Fwd: While - Otherwise Statement

On 11/10/2015 16:14, Sven Barth wrote: Am 11.10.2015 15:56 schrieb "MohsenTi" >: > > Hi everybody > > I add new feature to FPC compiler to simplify programming. > this is While - Otherwise working like While - Else in python and has

Re: [fpc-devel] Fwd: While - Otherwise Statement

On 11/10/2015 22:33, Tomas Hajny wrote: On Sun, October 11, 2015 22:48, Sven Barth wrote: . . That "then" is a great idea! That would definitely not break anything and it would make sense indeed: === code begin === while bool do foo then bar; repeat foo; until bool then bar;

Re: [fpc-devel] new features and facilities

On 08/10/2015 23:18, Mark Morgan Lloyd wrote: Michael Van Canneyt wrote: Let me explain. If I see If expr1 then expr2 else expr3 it says 'statement' to me. But a ? b : c; Says "expression" to me. The way I look at it is that it's restoring a feature that was (possibly accidentally)

Re: [fpc-devel] Resourcestrings and encodings

not use *.po files and rstconv -> not tested by me. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Printing to PDF on Mac crashes due to unaligned MOVDQA

to fix it somehow... and know just a little about OSX. For more details see http://stackoverflow.com/q/30923914/581205 It's similar to http://bugs.freepascal.org/view.php?id=25920, but here I don't even know what library is the culprit. Regards, Martin

Re: [fpc-devel] ref count issue with out param

On 13/06/2015 10:05, Jonas Maebe wrote: Martin Frb wrote: ebx is a temp copy of s1, but then f1 becomes nil, and ebx points to freed memory. It's because out finalises on the caller side (due to its COM origin, I guess) while value parameters get their reference count increased

Re: [fpc-devel] ref count issue with out param

On 13/06/2015 15:12, Michael Van Canneyt wrote: Note the 0 ! Secondly, the section about 'out' parameters is very old; there were not nearly so much managed types at the time. I will update it, I was just documenting the new string types anyway. The above will nicely illustrate the point.

Re: [fpc-devel] ref count issue with out param

On 13/06/2015 09:31, Florian Klämpfl wrote: The only way to prevent this (of course, such a simple case could be detected by the compiler but one can always construct an example which works around this detection), is to turn off the const optimization that const allows the compiler to pass

Re: [fpc-devel] ref count issue with out param

On 13/06/2015 15:18, Florian Klämpfl wrote: Foo2(a1[i],a2[j]) a1, a2 being dyn. arrays, but sharing data, i and j having the same value. I dug out my old turbo delphi. In all both cases (my original example / you dyn array example) Delphi passes nil for the normal parameter, and fpc

Re: [fpc-devel] ref count issue with out param

On 13/06/2015 09:31, Florian Klämpfl wrote: It is similar to type tarray = array [1..10] of longint; procedure p(const a1 : tarray;var a2 : tarray); begin a2[1]:=4321; writeln(a1[1]); // surprise end; var arr : tarray; begin arr[1]:=1234; p(arr,arr); end. I

Re: [fpc-devel] ref count issue with out param

On 13/06/2015 10:05, Jonas Maebe wrote: Martin Frb wrote: ebx is a temp copy of s1, but then f1 becomes nil, and ebx points to freed memory. It's because out finalises on the caller side (due to its COM origin, I guess) while value parameters get their reference count increased

Re: [fpc-devel] ref count issue with out param

On 13/06/2015 17:48, Florian Klämpfl wrote: Am 13.06.2015 um 16:42 schrieb Martin Frb: On 13/06/2015 15:18, Florian Klämpfl wrote: Foo2(a1[i],a2[j]) a1, a2 being dyn. arrays, but sharing data, i and j having the same value. I dug out my old turbo delphi. In all both cases (my original

Re: [fpc-devel] ref count issue with out param

On 13/06/2015 19:55, Florian Klämpfl wrote: procedure Foo1(a: AnsiString; out b: AnsiString); procedure Foo2(out a: AnsiString; b: AnsiString); So in Delphi it does not depend on this order. The none out is always nil. Yes. Implementation specific behavior. Really. Then Delphi documented

Re: [fpc-devel] ref count issue with out param

On 13/06/2015 21:48, Jonas Maebe wrote: On 13/06/15 22:04, Florian Klämpfl wrote: Or is it documented somewhere that out parameters are finalized first and then the other parameters are loaded? Regardless of whether it's documented, maybe we should do that anyway. It doesn't seem like a bad

[fpc-devel] ref count issue with out param

Reading http://forum.lazarus.freepascal.org/index.php/topic,28740.msg180163.html#msg180163 and http://bugs.freepascal.org/view.php?id=28279 I did some tests and found something related, that I believe to be a bug. 2.6.4 and trunk (few weeks old) Could someone please confirm? The line s1 :=

Re: [fpc-devel] fpc does not recompile units, even used units have changed.

On 21/05/2015 15:46, Martin Frb wrote: If I recompile I can see that LazListClasses is recompiled (hints are produced for the unit) But TestLazStorageMemCase1 is not recompiled, and the debugln still in place. fpc revision 30815 ___ fpc-devel

Re: [fpc-devel] bitwise shift oddity a b

On 19/05/2015 09:22, Mark Morgan Lloyd wrote: Jonas Maebe wrote: Martin Frb wrote: What is supposed to happen if the 2nd argument is negative? I would propose to document it as undefined behaviour, just like C does (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf , section 4.5.7

Re: [fpc-devel] bitwise shift oddity a b

On 19/05/2015 11:03, Adriaan van Os wrote: the cpu, so if you want to guarantee consistent behaviour on all platforms, you can no longer just emit a shift left/right instruction and have to add all kinds of checks. Maybe we should support emitting range checks for the right operand though

Re: [fpc-devel] bitwise shift oddity a b

On 19/05/2015 13:56, Jonas Maebe wrote: On x86-64, x shr 64 = x, for any value of x. On i386, x shr 32 = x, for any value of x. For PowerPC (32 bit), x shr y = 0 if bit 5 of y is set, otherwise it's (x shr (y mod 32)). Really, there are very good reasons to treat this kind of stuff as

[fpc-devel] generated assembler code

fpc 3.1.1 on i386 -O3 function FOO: Boolean; inline; begin Result := FMem nil; end; function BAR: TPItemT; begin if FOO then Result := nil else Result := TPItemT(FMem.FirstItemPointer + (Index * FItemSize.ItemSize)); end; generates something like: 005EACF0 833A00

Re: [fpc-devel] generated assembler code

On 19/05/2015 14:23, Jonas Maebe wrote: Martin Frb wrote on Tue, 19 May 2015: 005EACF0 833A00 cmp dword ptr [edx],$00 005EACF3 0F95C0 setnz al 005EACF6 84C0 test al,al 005EACF8 7509 jnz +$09 Is that something

[fpc-devel] bitwise shift oddity a b

What is supposed to happen if the 2nd argument is negative? program Project1; uses sysutils; var a: LongInt; begin a := StrToInt('-1'); WriteLn(2 a); WriteLn(2 -1); ReadLn; end. prints: 0 4294967296 2 a translates to shl eax,cl (cl being loaded with the result from strtoint) So at least

[fpc-devel] {$INLINE off}

Are there any known conditions, in which inlining is applied, despite a {$INLINE off} on top of the unit? (fpc trunk and 2.6.4) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] {$INLINE off}

On 09/05/2015 19:54, Martin Frb wrote: It does not work for me in units. fpc trunk r30815. If I copy all the code into the main project, then it works (and I get all the hints, about inlining disabled.). But the above, stopping with the debugger, and stepping in: - there is on call

[fpc-devel] generics and scoping rules

What are the scoping rules? Example: TLazStorageMemBase = object private const CNT_OFFS = SizeOf(Pointer); DATA_OFFS = CNT_OFFS + (2 * SizeOf(Integer)); private FMem: PByte; function GetCapacity: Integer; inline; function GetCount: Integer; inline; . end;

Re: [fpc-devel] Tprocess using pipes, handle = 0

On 17/03/2015 21:00, Marco van de Voort wrote: Or could an Handle (active/all ok) be 0? 0 is standard input. Ah, except, if stdiin is closed, it can go to whatever handle is next And I have to go and fix some 10 year old code (that now started failing)

Re: [fpc-devel] Tprocess using pipes, handle = 0

On 17/03/2015 21:04, Martin Frb wrote: On 17/03/2015 21:00, Marco van de Voort wrote: Or could an Handle (active/all ok) be 0? 0 is standard input. Ah, except, if stdiin is closed, it can go to whatever handle is next Are there any values that are known to be ont a handle? On windows

Re: [fpc-devel] Tprocess using pipes, handle = 0

On 17/03/2015 22:57, Marco van de Voort wrote: In our previous episode, Martin Frb said: Are there any values that are known to be ont a handle? On windows codetools find InvalidHandleValue = -1 But on Linux I found nothing like this. Given that fpselect is documented to have a bit-array

Re: [fpc-devel] Tprocess using pipes, handle = 0

On 16/03/2015 22:03, Martin Frb wrote: Further debugging was done, and the value of FDbgProcess.FOutputStream.FHandle was inspected immediately after TProcess.Execute It was zero already. It is my understanding (from browsing the code), that if TProcess.Execute is succesful, the handle

[fpc-devel] Tprocess using pipes, handle = 0

This is based on a report I got. I can not reproduce myself. (I bcc the reporter, and hope he will comment) ON a 664 bit amd linux, fpc_2.6.4-140420_amd64.deb (apparently the one from Lazarus sourceforge) The problem started with an error launching the debugger. Apparently the error occurs

[fpc-devel] Letter for ctrl char

^X (where X can be (almost?) any letter results in a char (^A=^Z = control chars) This also works for none a-z letters. The compiler generates chars. The only exception is ^{ standalone this is a char. But ^{$ is not a char followed by $, but a ^ followed by directive. Yet this is

Re: [fpc-devel] Exception while creating process: Could not detect X-Terminal program / Fedora 20

On 09/11/2014 11:25, Mattias Gaertner wrote: Yes, that's logical. It seems Martin thinks that the compiler needs a terminal. Why does the compiler use poNewConsole? It is about starting the debugger (if I read the issue correct). And actually, this is very old code, and has not been

Re: [fpc-devel] Exception while creating process: Could not detect X-Terminal program / Fedora 20

On 09/11/2014 09:18, Michael Van Canneyt wrote: What is there to look at ? There must be one of the 8 (!) supported terminal programs in the path. The error message indicates that there is no such program. You can't get more clear than that, I would think ? Well to me this error says,

<    1   2   3   4   5   6   7   8   9   10   >