Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows

Am 19.03.2017 04:53 schrieb "silvioprog" : > > On Wed, Mar 15, 2017 at 4:38 AM, LacaK wrote: >>> >>> I forgot a question, could you send your ippi .a files for us? If so, I can try a test here. :-) >> >> >> Yes of course: I have uploaded them here

Re: [fpc-devel] Some questions about compiler work on x86_64-win64

Am 18.03.2017 23:11 schrieb "Bishop" <cat_sht...@rambler.ru>: > > 03/18/17 00:51:05, Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org>: > > > > Bo, the main sense of this is to detect when a new thread is started and more importantly ter

Re: [fpc-devel] Some questions about compiler work on x86_64-win64

Am 17.03.2017 22:16 schrieb "Bishop" <cat_sht...@rambler.ru>: > > 03/17/17 11:56:47, Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org>: > > >> 1) EXE-file contained .CRT section. As i understand it contained one pointer to _FPC_Tls_Call

Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows

Am 15.03.2017 13:56 schrieb "LacaK" : > > Dňa 15.3.2017 o 12:54 Yury Sidorov napísal(a): > >> On 3/14/2017 4:47 PM, Ladislav Karrach wrote: >>> >>> Did you try this: function ippiThreshold(pSrcDst: PIpp8u; srcDstStep: int; roiSize: IppiSize; thresholdLT:

Re: [fpc-devel] Some questions about compiler work on x86_64-win64

Am 17.03.2017 08:08 schrieb "Bishop via fpc-devel" < fpc-devel@lists.freepascal.org>: > > I have some questions about compiler work on x86_64-win64. > > 1) EXE-file contained .CRT section. As i understand it contained one pointer to _FPC_Tls_Callback functions from RTL. Is it used only for this?

Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows

Am 15.03.2017 17:06 schrieb "LacaK" : > But this can be because probably "libippcore.a" is for Linux 64 ... Yes, the Windows one only supports PE, not ELF. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] LineInfo

Am 04.04.2017 08:52 schrieb "Martok" : > > >> Does it is possible that the LineInfo trace (-gl option) are broken (no output) > >> in 3.0.2 version on Linux (at least)? > > > > Hm. Indeed. I can reproduce the issue :/ > AFAIR lineinfo.pp only works with Stabs? Didn't the

Re: [fpc-devel] LineInfo

Am 04.04.2017 10:42 schrieb "Tomas Hajny" <xhaj...@hajny.biz>: > > On Tue, April 4, 2017 10:21, Michael Van Canneyt wrote: > > On Tue, 4 Apr 2017, Sven Barth via fpc-devel wrote: > >> Am 04.04.2017 08:52 schrieb "Martok" <list...@ma

Re: [fpc-devel] Detecting clashing ppus

Am 01.04.2017 10:53 schrieb "C Western" : > Is this a sensible change? I'd say so. If no other core dev complains during the day I'll commit it tomorrow. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Discussion about "Dynamic packages"

bler code to see what I mean). > 04/13/17 12:28:02, Sven Barth via fpc-devel > <fpc-devel@lists.freepascal.org>: >> Yes, they are specifically for Pascal code and more specifically only FPC >> code as you can't use a Delphi dynamic package with FPC or the > other wa

Re: [fpc-devel] Discussion about "Dynamic packages"

Am 13.04.2017 08:44 schrieb "Bishop via fpc-devel" < fpc-devel@lists.freepascal.org>: > At first I would like to designate a circle of tasks which in principle can effectively decide by means of system of dynamic packets. Lets remember for what DLL`s and SO`s was be created. It was for memory

Re: [fpc-devel] Discussion about "Dynamic packages"

Am 13.04.2017 12:03 schrieb "Mattias Gaertner" <nc-gaert...@netcologne.de>: > > On Thu, 13 Apr 2017 11:28:02 +0200 > Sven Barth via fpc-devel <fpc-devel@lists.freepascal.org> wrote: > > >[...] > > The intended purpose of dynamic packages (and l

Re: [fpc-devel] Discussion about "Dynamic packages"

Am 13.04.2017 23:54 schrieb "gabor" <ga...@poczta.onet.pl>: > > > > W dniu 2017-04-13 o 22:27, Sven Barth via fpc-devel pisze: > >> And it's not about saving RAM or disk memory! It's about *binary code >> reuse*, the ability to fix a bug in multiple

Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows

Am 14.03.2017 13:30 schrieb "LacaK" : > > Hi, > > I have C/C++ librarby (".lib" for Windows and ".a" for Linux) from Intel IPP package (they distribute ".lib" and also ".dll" for Windows and ".a" for Linux) > > Can I link in FPC (on Windows) at compile time to this ".lib" versions

Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows

Am 14.03.2017 14:33 schrieb "Sven Barth" : > > Am 14.03.2017 13:30 schrieb "LacaK" : > > > > Hi, > > > > I have C/C++ librarby (".lib" for Windows and ".a" for Linux) from Intel IPP package (they distribute ".lib" and also ".dll" for Windows and ".a"

Re: [fpc-devel] Multiple inheritance

Am 19.08.2017 09:12 schrieb "Ondrej Pokorny" : > > Hello! > > Has anybody thought about multiple inheritance in object pascal? I am now working on a client-server service that entirely uses ORM. I have several patterns that repeat all over and some of them do not match into the

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

On 05.06.2017 20:37, Denis Kozlov wrote: > > I just wanted to highlight that these cases as legal and I presume not > uncommon, particularly if values are deserialized and typecasted. They are legal in the sense that they result in undefined behavior and in that case the compiler is free to act

Re: [fpc-devel] UTF-8 string literals

Am 05.05.2017 16:08 schrieb "Sven Barth" : > > Am 05.05.2017 16:03 schrieb "Juha Manninen" : > > > > On Fri, May 5, 2017 at 2:53 PM, Mattias Gaertner > > wrote: > > > 1. When using a character outside BMP FPC stops

Re: [fpc-devel] UTF-8 string literals

On 07.05.2017 14:16, Marco van de Voort wrote: > In our previous episode, Sven Barth via fpc-devel said: >>>> Is there a plan to fix it? >>> >>> Now it is fixed :D (revision 36116; maybe we should merge that to fixes >> once I or someone else tested a

Re: [fpc-devel] UTF-8 string literals

Am 05.05.2017 16:03 schrieb "Juha Manninen" : > > On Fri, May 5, 2017 at 2:53 PM, Mattias Gaertner > wrote: > > 1. When using a character outside BMP FPC stops with: > > Error: UTF-8 code greater than 65535 found > > For example: > > const

Re: [fpc-devel] UTF-8 string literals

Am 05.05.2017 15:55 schrieb "Michael Van Canneyt" : > > > > On Fri, 5 May 2017, Mattias Gaertner wrote: > >> On Fri, 5 May 2017 14:30:32 +0200 (CEST) >> Michael Van Canneyt wrote: >> >>> [...] >>> > AFAIK FPC stores UTF-8 string literals (-Fcutf8)

Re: [fpc-devel] UTF-8 string literals

Am 06.05.2017 08:18 schrieb "Martok" : > PS: adding to the discussion over on the Lazarus ML: I just found a fourth wiki > page describing a slightly different Unicode support. This is getting ridiculous. That might be the one from Michael Schnell. Probably it should be

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

On 03.05.2017 09:06, Michael Van Canneyt wrote: > > > On Wed, 3 May 2017, Tomas Hajny wrote: > >> On Wed, May 3, 2017 00:33, Michael Van Canneyt wrote: >>> On Tue, 2 May 2017, Martin wrote: On 02/05/2017 22:59, Michael Van Canneyt wrote: > >> That's probably good as the fastest /

Re: [fpc-devel] x86_64.inc CompareByte

Am 16.10.2017 23:04 schrieb "Markus Beth" : > > On 16.10.2017 22:41, Florian Klämpfl wrote: >> BTW: I would really like to see a PCMPSTR based implementation :) > > PCMPSTR is (at the moment) out of my scope. I thought PCMPSTR is part of SSE4.2. How would you deal with Intel

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 29.08.2017 17:39 schrieb "Ondrej Pokorny" : > So yes, your description of {$modeswitch typehelpers} makes sense for 3.0.0 but not for trunk any more. So what is your intention - 3.0.0 behavior or trunk behavior? Maybe it would indeed make more sense to adjust the meaning of

Re: [fpc-devel] Can't compile FPC trunk x86_64-win64

Am 30.09.2017 07:37 schrieb "Ondrej Pokorny" <laza...@kluug.net>: > > On 30.09.2017 0:10, Sven Barth via fpc-devel wrote: >> >> Are you sure that you're compiling with the correct compiler? Cause that sounds quite like you're trying to compile the Win64 RTL with a

Re: [fpc-devel] Can't compile FPC trunk x86_64-win64

Am 29.09.2017 22:14 schrieb "Ondrej Pokorny" : > > Hello, > > I can't compile latest trunk for x86_64-win64: the first error message is: > > system.pp(136,18) Error: invalid register name > > i386-win32 compiles fine. Are you sure that you're compiling with the correct

Re: [fpc-devel] Optimizing unused return values of inline functions

Am 22.08.2017 13:15 schrieb "Michael Van Canneyt" : > > > > On Tue, 22 Aug 2017, Thaddy de Koning wrote: > >>> On 21.08.2017 13:22, Michael Van Canneyt wrote: On Mon, 21 Aug 2017, Benito van der Zander wrote: > Hi, > >> This pattern is

Re: [fpc-devel] Optimizing unused return values of inline functions

On 21.08.2017 13:22, Michael Van Canneyt wrote: > > > On Mon, 21 Aug 2017, Benito van der Zander wrote: > >> Hi, >> >>> This pattern is not inherently efficient. Why should it be ? >> >> >> It is not efficient, because of the pointless instruction! > > I am not speaking of the current FPC

Re: [fpc-devel] Optimizing unused return values of inline functions

On 21.08.2017 21:15, Marco van de Voort wrote: > In our previous episode, Sven Barth via fpc-devel said: >>> I am asking, why do you think *this pattern* (of always returning self) >>> should be inherently more efficient ? >> >> The pattern definitely has its us

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 29.08.2017 08:47 schrieb "Michael Van Canneyt" <mich...@freepascal.org>: > > > > On Tue, 29 Aug 2017, Sven Barth via fpc-devel wrote: > >> Am 28.08.2017 23:11 schrieb "Ondrej Pokorny" <laza...@kluug.net>: >>> >>> >&g

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 29.08.2017 10:37 schrieb "Ondrej Pokorny" <laza...@kluug.net>: > > On 29.08.2017 8:47, Michael Van Canneyt wrote: >> >> On Tue, 29 Aug 2017, Sven Barth via fpc-devel wrote: >> >>> Suggested name is "NonDelphiExtensions". >>

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 28.08.2017 23:11 schrieb "Ondrej Pokorny" : > > Hello! > > I find it unnecessary to disable record helper inheritance in Delphi mode. Due to this artificial limitation I have to change unit mode from Delphi to ObjFPC. > > Reasons: > 1.) It's a limitation of a feature that

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 31.08.2017 12:07 schrieb "Ondrej Pokorny" : > > On 29.08.2017 22:30, Maciej Izak wrote: >> >> >>> >>> Btw. record helpers support inheritance in all modes but Delphi. It doesn't make sense to disallow it for record helpers but allow it for type helpers... Too overcomplicated

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 01.09.2017 11:51 schrieb "Stefan Glienke" : > > What I am lobbying for in Delphi are interface helpers and helpers for generic types in general. > > I just saw that FPC currently has the same limitation. That also on your list? > Interface helpers are implemented in trunk

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 01.09.2017 12:15 schrieb "Maciej Izak" : > > 2017-09-01 11:41 GMT+02:00 Stefan Glienke : >> >> Again you will cause unnecessary headaches because now your helper has the dependency of the builtin and the third party one. >> How would third party one and

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 31.08.2017 15:55 schrieb "Ondrej Pokorny" <laza...@kluug.net>: > > On 31.08.2017 14:55, Sven Barth via fpc-devel wrote: >> >> >> > Yeah, they might enable record helper inheritance for example :P (Record helper inheritance was documented to work fo

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 01.09.2017 14:41 schrieb "Maciej Izak" : > > 2017-09-01 14:30 GMT+02:00 Michael Van Canneyt : >>> >>> >>> No, directives won't be abused for something like that. >> >> >> I am glad I am not the only one who thins so :) > > > I like experiments as you

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 01.09.2017 14:50 schrieb "Stefan Glienke" : > > > For generics the only way to support them is that you must explicitly specialize a generic helper type. The compiler won't do any type inference for you. > > IMO this makes them rather useless. Is that a technical limitation

Re: [fpc-devel] trunk broken

On 02.09.2017 20:01, Benito van der Zander wrote: > Hi, > > trunk is always broken, is it not? Huh? It's rather seldom that we have real build breakages and even then more often than not only on certain systems. Regards, Sven ___ fpc-devel maillist

Re: [fpc-devel] trunk broken

Am 02.09.2017 17:06 schrieb "Karoly Balogh (Charlie/SGR)" < char...@scenergy.dfmk.hu>: > > Hi, > > On Sat, 2 Sep 2017, Marco van de Voort wrote: > > > The expansion of texpropcode in r37108 (Mattias) breaks fppasjs because it > > defines an array with texpropcode as range. > > > > This prohibits

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 29.08.2017 12:44 schrieb "Ondrej Pokorny" <laza...@kluug.net>: > > On 29.08.2017 11:48, Sven Barth via fpc-devel wrote: >> >> The idea is okay as well, but I'd name it RecordHelperInheritance, cause if we'd allow "type helper" in mode Delphi (as Macie

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 31.08.2017 17:48 schrieb "Ondrej Pokorny" <laza...@kluug.net>: > > On 31.08.2017 17:22, Sven Barth via fpc-devel wrote: >> >> > I remember a compiler bug in class destructor order call in Delphi: https://stackoverflow.com/questions/19332847/delphi-class-var

Re: [fpc-devel] Allow record helper inheritance in Delphi mode

Am 01.09.2017 08:47 schrieb "Stefan Glienke" : > Therefor I argue that the "only the last one in scope is applied" restriction should be removed. > If there are any clashes because two helpers introduce a any ambiguity well then it is the compilers job to warn or error about

Re: [fpc-devel] String constant without code page

Am 14.12.2017 09:37 schrieb "Petr Kristan" : Hi. I compile whole project with -FcUTF8, but sometimes should be useful to define string constant with CP_NONE to prevent conversions. Example: DefaultSystemCodePage:=1250 variable s contains text with cp=1250 s := s + '#';

Re: [fpc-devel] First pas2js public release

Am 18.12.2017 14:56 schrieb "Benito van der Zander" : Isn't speed the main idea of using pointers? It would be to port all existing pascal code But that isn't the goal of pas2js. That is what WebAsm is for. You may want to take a look at asm.js, which has a working model

Re: [fpc-devel] FillWord, FillDWord and FillQWord are very poorly optimised on Win64 (not sure about x86-64 on Linux)

Am 01.11.2017 05:58 schrieb "J. Gareth Moreton" : Would it be worth opening up a bug report for this, with the attached assembler routines as suggestions? I haven't worked out how to implement internal functions into the compiler yet, and I rather clear it with you guys

Re: [fpc-devel] Vectorization

Am 10.12.2017 20:01 schrieb "J. Gareth Moreton" : The idea I had currently (this is without looking at any previous theory) was to use a kind of sliding window, similar to how ZIP and other LZ77-based algorithms work when compressing repeating strings, to look backwards

Re: [fpc-devel] Quickly recompiling fpc

Am 09.12.2017 14:57 schrieb "Benito van der Zander" : Hi, how do you recompile fpc after making a small change in the compiler, like enabling the debugmsg define in x86/aoptx86.pas? make buildbase says nothing was changed, and make clean; make buildbase recompiles not just

Re: [fpc-devel] Multiple type sections - Far forward type declarations [feasible feature request?]

Am 31.10.2017 10:47 schrieb "Michael Van Canneyt" : On Tue, 31 Oct 2017, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: > >> >> With your extended "forward type resolution" this would no longer be >> possible. >> Theoretically it probably

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac function in FPC3.1.1 / Windows x86_64

Thorsten Engler schrieb am Fr., 27. Apr. 2018, 16:09: > Highest integer that fits in a Int64: > > 9223372036854775808 > > 1e20: > > 1 > > > > Your Int is overflowing. > > > > You can’t implement Frac by going through an Integer, that will never >

Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

Bart schrieb am Fr., 27. Apr. 2018, 13:42: > On Wed, Apr 25, 2018 at 11:04 AM, wrote: > > > If you compile and run this 64-bit program on Win 64 you get a crash > > And AFAICS your analysis of the cause (see bugtracker) is correct as well. > >

Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

Thorsten Engler schrieb am Fr., 27. Apr. 2018, 18:48: > For what it’s worth, Delphi simply decided to give up on doing it > correctly and silently fail if the double is too large to fit in an Int64. > > > > WriteLn(Frac(1e15+0.5)); > > WriteLn(Frac(1e16+0.5)); > > > >

Re: [fpc-devel] Case of string

Bart schrieb am Do., 26. Apr. 2018, 19:29: > Is this a bug, or was it changed by design? > It's a bug due to refactoring. I'll commit the fix once I got to run the testsuite. Regards, Sven > ___ fpc-devel maillist -

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac function in FPC3.1.1 / Windows x86_64

Thorsten Engler schrieb am Fr., 27. Apr. 2018, 17:47: > > That's true for i386. But on x86_64 cvt(t)sd2si instuctions can > > deal with int64 range, if destination register is a 64-bit one. > > You are still going to be at least 960-bit short... > I've disabled the SSE

Re: [fpc-devel] Case of string

Am 27.04.2018 um 22:48 schrieb Bart: On Fri, Apr 27, 2018 at 5:49 PM, Sven Barth via fpc-devel <fpc-devel@lists.freepascal.org> wrote: It's a bug due to refactoring. I'll commit the fix once I got to run the testsuite. So, I need not file a bugreport then? Nope, fixed in

Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

Am 28.04.2018 um 11:28 schrieb Thorsten Engler: Basically that. For doubles that don't fit into an Int64, any fraction is beyond the significant number of digits that the double can store anyway, so 0 is the valid and correct result for Frac in that case. Since a float only stores the

Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

Am 28.04.2018 um 10:11 schrieb Thorsten Engler: Oops, small mistake caused by last minute change (I replaced rol with shl): it needs to be shr (or ror or rol, they all perform about the same on my cpu). And in case anyone wonders, the first cmp and branch returns 0 for numbers that would

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

Marco van de Voort schrieb am Mo., 21. Mai 2018, 21:05: > In our previous episode, Florian Kl?mpfl said: > > > 1:40 with FPC trunk > > > > > > Do you observe the same? Any hints why? > > > > New features? E.g. helpers made fpc a lot slower (or are they already in > 3.0.x?)

Re: [fpc-devel] Debugging Loop Unroll Optimization

Martok schrieb am Fr., 18. Mai 2018, 15:40: > > Citation: "If the loop was terminated prematurely with an exception or a > > break statement, the loop variable retains the value it had when the > > loop was exited." > As a quick fix, not unrolling loops left with exit

Re: [fpc-devel] Found compiler bug while working on Deep Optimiser

Am 27.05.2018 um 02:48 schrieb J. Gareth Moreton: Hi guys, So I'm still experimenting and researching with the deep optimiser, and I'm starting to have some successes... until I found a compiler bug! https://bugs.freepascal.org/view.php?id=33794 What I'm trying to do, and something which

Re: [fpc-devel] x86_64-win64 compilation failure

J. Gareth Moreton schrieb am Fr., 1. Juni 2018, 21:02: > It seems to have been fixed now after I did a manual deletion of all .o > and .ppu files. Not sure what that was all about. Sorry to waste anyone's > time - emergency over. Just to be sure: you are doing a "make clean all" at the top

Re: [fpc-devel] procedure ShowException

Am 01.06.2018 um 21:14 schrieb Ondrej Pokorny: Hello, is there any reason the OnShowException event is ignored for console applications? The OnShowException event is a feature of FPC (Delphi doesn't have it), so whoever added it probably thought that it makes more sense this way 路‍♀️

Re: [fpc-devel] RandomFrom vs Generics

Gabor Boros schrieb am Mi., 6. Juni 2018, 08:09: > Hi All, > > This > > var >x:Integer; >a:array of Integer; > > begin >x:=RandomFrom(a); > > code works with 3.0.4 but cannot compile with trunk and got "Error: > Generics without specialization cannot be used as a type for a >

Re: [fpc-devel] RandomFrom vs Generics

Gabor Boros schrieb am Mi., 6. Juni 2018, 10:15: > 2018. 06. 06. 9:05 keltezéssel, Sven Barth via fpc-devel írta: > > Seems like a bug due to there being multiple overloads plus the generic. > > Would you please report that to the bug tracker? > > > Done: > > https:

Re: [fpc-devel] x86-64 compilation of while loops

J. Gareth Moreton schrieb am Mo., 28. Mai 2018, 02:55: > In this case, the ".balign" hint adds 2 bytes to pad the loop. However, > my question is this... why does it immediately jump to the end of the loop > to check the condition (which is very likely to be true on

Re: [fpc-devel] FPC Macros: Could it be used for unit aliases?

Marcos Douglas B. Santos schrieb am Mi., 27. Juni 2018, 14:37: > Sven and all, > Is there any change to implement this? > Not from me. I don't care about that. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Maximum symbol length -- answer needed

Am 23.06.2018 um 10:48 schrieb Jonas Maebe: I would propose to switch all targets to use use ansistrings for symbol names. Is this the consensus? Personally, if I had any stake in this, I would be against it. I mean, FPC is already slower than DCC. I doubt this is a major contributor to

Re: [fpc-devel] Managed Types, Undefined Bhaviour

Willibald Krenn schrieb am Sa., 30. Juni 2018, 08:01: > TBH, I didn't know this issue existed in Delphi and I've done my share of > Delphi over time. I still maintain that for managed types the compiler is > responsible for some minimal initialization (like it's done for records > etc, no?). >

Re: [fpc-devel] Attn. Generics.Collections and rev. 39345 and speed slowdown

Maciej Izak schrieb am Sa., 30. Juni 2018, 08:16: > Hi, > > renaming for TMormotHashFactory to TGenericsHashFactory is somehow > acceptable (but IMO bad taste) but change for default hashing algorithm in > such important library is really really really bad idea. > No, the bad taste is too have

Re: [fpc-devel] Generics.Collections June update

Maciej Izak schrieb am Sa., 30. Juni 2018, 08:15: > 2018-06-28 22:13 GMT+02:00 Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org>: > >> - why is it that you adjusted DaThoX' copyright range, but not yours at >> the top? >> > > on the top is date

Re: [fpc-devel] Attn. Generics.Collections and rev. 39345 and speed slowdown

Am 30.06.2018 um 09:52 schrieb Maciej Izak: 2018-06-30 8:55 GMT+02:00 Sven Barth via fpc-devel mailto:fpc-devel@lists.freepascal.org>>: No, the bad taste is too have a class that appears to be named specifically to fit a specific third party project inside a general purpose l

Re: [fpc-devel] Broken frac functionin FPC3.1.1 / Windows x86_64

J. Gareth Moreton schrieb am Di., 1. Mai 2018, 23:39: > It turns out I did over-engineer the solution somewhat - this version is > far more efficient, honours NaNs and triggers SIGFPE if infinity is passed > in (subsd triggers it), hence there are no regressions. > >

Re: [fpc-devel] Broken frac functionin FPC3.1.1 / Windows x86_64

J. Gareth Moreton schrieb am Mi., 2. Mai 2018, 11:10: > > > > > On Wed 02/05/18 06:55 , Sven Barth pascaldra...@googlemail.com sent: > > ... > Thank you for the work so far. Does it also work correctly when exceptions > are disabled? > > Regards, > Sven > > > I confess

Re: [fpc-devel] NewPascal plans, Generics.Collections and FPC trunk

Maciej Izak schrieb am Mi., 2. Mai 2018, 18:21: > I will continue my all work as much as possible with NewPascal (which will > be synced with FPC trunk few times in the year - or more often if needed), > I mean here all stuff, including updates for Generics.Collections

Re: [fpc-devel] NewPascal plans, Generics.Collections and FPC trunk

Maciej Izak <hnb.c...@gmail.com> schrieb am Mi., 2. Mai 2018, 19:59: > 2018-05-02 18:41 GMT+02:00 Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org>: > >> Please note that the pnameless.pas file by Blaise does not yet have a GPL >> compatible license h

Re: [fpc-devel] Broken frac functionin FPC3.1.1 / Windows x86_64

J. Gareth Moreton schrieb am Do., 3. Mai 2018, 04:55: > Tests complete! It turns out that I was using SetExceptionMask wrong and > subtracting rather than adding exInvalidOp. > > When exceptions are disabled, this new Frac function returns NaN when you > pass in plus

Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

Anthony Walter schrieb am So., 29. Apr. 2018, 21:27: > I've run into an almost must have use case for FPC smart pointers as > described and implemented by Maciej. I wanted to know from the people who > make decision about what to merge, what's the status of rolling his >

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

Ondrej Pokorny schrieb am Di., 3. Juli 2018, 22:57: > On 03.07.2018 22:08, Florian Klämpfl wrote: > > Am 03.07.2018 um 21:30 schrieb Ondrej Pokorny: > >> On 03.07.2018 20:54, Florian Klämpfl wrote: > >> program Project1; > >> type > >>TMyArray = array[0..10] of Integer; > >>procedure

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

Am 04.07.2018 um 00:00 schrieb Nikolay Nikolov: So, even though filling objects with zero introduces a small runtime overhead, it saves a lot of pain and prevents difficult to find bugs (people quite often don't test exceptions raised in the constructor). And I don't know how often I've been

Re: [fpc-devel] Vectorization

Am 23.12.2017 11:01 schrieb "Adriaan van Os" : J. Gareth Moreton wrote: > Hey Adriaan, > > I dare ask - did the patch help out your issue at all? I did supply it to > Florian as well, although he has his own work in progress for > vectorization, so whether my code is

Re: [fpc-devel] Internal error 2018011401

Am 15.01.2018 10:14 schrieb "Mattias Gaertner" : Hi, Using fpc trunk. What means error Error: Internal error 2018011401 ? Seems like the addition of that code wasn't as thought out by me as I hoped it was... You can remove the internal error and the check that leads

Re: [fpc-devel] Internal error with division by QWord (Issue #33004)

Am 11.01.2018 21:46 schrieb "J. Gareth Moreton" : Possibly related, but the compiler automatically treats numbers larger than or equal to $8000 as signed (Int64) regardless of the context or what it's being assigned to (this usually involves compiler

Re: [fpc-devel] End of support for Win XP?

Am 01.02.2018 14:08 schrieb "Denis Kozlov" : A proposal: 1) Use windirs.GetWindowsSpecialDir in fpttf.pp, which already uses a more backwards compatible SHGetFolderPath(). 2) Optionally, improve windirs.GetWindowsSpecialDir to use a newer SHGetKnownFolderPath() when it is

Re: [fpc-devel] End of support for Win XP?

Am 01.02.2018 14:31 schrieb "Michael Van Canneyt" : On Thu, 1 Feb 2018, Denis Kozlov wrote: A proposal: > 1) Use windirs.GetWindowsSpecialDir in fpttf.pp, which already uses a more > backwards compatible SHGetFolderPath(). > 2) Optionally, improve

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

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) > I don't think the below is related, but

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

On 04.02.2018 20:37, Martin wrote: > 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 >>> CheckS

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

On 05.02.2018 03:03, Martin wrote: > 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

Re: [fpc-devel] What's the best way to debug the fpc compiler?

Am 28.12.2017 11:30 schrieb "Giuliano Colla" : Hi fpc developers, I'm playing a bit with the compiler. In order to debug my changes I need to compile some test programs. To stay on the safe side, currently when I modify something I rebuild everything (make all -

Re: [fpc-devel] An extension of fpc language: the BASED construct

Am 26.12.2017 13:33 schrieb "Giuliano Colla" : If the idea is not rejected, then a number of refinements (which I'm ready to implement) are required to make the feature generally available: My following remarks are independent of an eventual acceptance of the

Re: [fpc-devel] *** GMX Spamverdacht *** An extension of fpc language: the BASED construct

Am 26.12.2017 14:44 schrieb "Thorsten Engler" : > Item: BYTE BASED ItemPtr; Ignoring any other considerations for now, I would have at least used a logical extension derived from already supported syntax: Item: Byte absolute ItemPtr^; I agree, as it avoids adding a

Re: [fpc-devel] An extension of fpc language: the BASED construct

Am 27.12.2017 00:54 schrieb "Giuliano Colla" <giuliano.co...@fastwebnet.it>: Il 26/12/2017 18:26, Sven Barth via fpc-devel ha scritto: Am 26.12.2017 13:33 schrieb "Giuliano Colla" <giuliano.co...@fastwebnet.it>: If the idea is not rejected, then a number

Re: [fpc-devel] MACRO - correct syntax?

Am 25.02.2018 12:14 schrieb "Mark Morgan Lloyd" < markmll.fpc-de...@telemetry.co.uk>: On 25/02/18 10:30, Florian Klämpfl wrote: > Am 25.02.2018 um 11:12 schrieb Mark Morgan Lloyd:> On 25/02/18 02:15, Ozz > Nixon wrote:>> {$MACRO ON}>> {$DEFINE _CTASSERT(X,Y,Z):=assert(x=y,z);}>> > Begin

Re: [fpc-devel] MACRO - correct syntax?

Am 25.02.2018 03:01 schrieb "Ozz Nixon" : {$MACRO ON} {$DEFINE _CTASSERT(X,Y,Z):=assert(x=y,z);} Begin _CTASSERT(1,1,'Constant failed.'); end. Macros with arguments are not supported. Regards, Sven ___ fpc-devel maillist -

Re: [fpc-devel] FPC fails on overload

Am 19.06.2018 um 02:47 schrieb J. Gareth Moreton: Technically it's a regression because it worked fine before and it breaks now.  However, I do agree... how should a string literal be interpreted? Technically either a WideString or UnicodeString is correct, so the compiler cannot decide

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

Am 21.06.2018 um 10:26 schrieb Martin: 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

Re: [fpc-devel] Attn Sven: New flags related to management operators

Am 20.06.2018 um 23:41 schrieb Maciej Izak: Hi Sven, I saw the new commits related to Management Operators (I mean new flags riifNonTrivialChild and riifParentHasNonTrivialChild) and I wonder what next. When I was developing management operators (and FastRTTI related to speed up things) I

Re: [fpc-devel] FreeInstance

Ryan Joseph schrieb am Di., 31. Juli 2018, 22:29: > > > > On Jul 31, 2018, at 9:56 AM, Ryan Joseph > wrote: > > > > then how does it get invoked then? there must be some node added > somewhere but I can’t find it. > > I’m still trying to find this with no luck. I suspect there’s a call node >

Re: [fpc-devel] Why/how does the compiler have a non-trivial number ofmemory leaks after over two decades of development?

Michael Van Canneyt schrieb am Mo., 30. Juli 2018, 15:30: > Obviously provided you don't install another mechanism that does this and > don't raise exceptions manually, which - AFAIK - is the case in the > compiler... > The compiler does use exceptions when the compilation needs to be aborted

Re: [fpc-devel] Why/how does the compiler have a non-trivial number ofmemory leaks after over two decades of development?

J. Gareth Moreton schrieb am Mo., 30. Juli 2018, 13:31: > I've noticed that the compiler doesn't use > try...finally blocks to help with freeing > blocks. I'm not sure why this is the case, > but might be speed related. > Correct. Even implicit try-finally frame generation is disabled for the

  1   2   3   4   5   6   7   8   >