Re: [fpc-devel] Can FPC at least give a hint/warning?

Am 07.11.2016 um 03:42 schrieb Gennady Agranov: > Hi, > > I have submitted a bug - http://bugs.freepascal.org/view.php?id=30872 > (misaligned data exception on > ARMv7) > > And this big was resolved as "won't fix" > > 1. I understand that one has to work really hard to encounter this bug - and

Re: [fpc-devel] ANN: Management operators - final patch

Am 21.11.2016 um 02:54 schrieb Paul Ishenin: > 21.11.2016 8:16, Maciej Izak wrote: > > Overall you've made a great job and a perfect example of how to supply > patches for FPC. > > I have a small question regards the following commit: >> 13. >> https://github.com/maciej-izak/freepascal/commit/9

Re: [fpc-devel] Attributes

Am 22.11.2016 um 20:48 schrieb Maciej Izak: > > Branch is waiting almost 3 years (sic!). Joost branch should be part of > NewPascal much much sooner > than official FPC trunk, anyway I have question: Well, Joost has write permissions on FPC trunk, I think he has himself the opinion that the bra

Re: [fpc-devel] Management operators : Copy and Clone confusion...

Am 19.01.2017 um 10:44 schrieb Michael Van Canneyt: > > At the risk of writing nonsense: > > I would think that a method name should give a clue as to what it actually > does. > In that sense AddRef/Clone seems better to me ? Even if it is used by types not being ref. counted? Ref. counted type

Re: [fpc-devel] aarch64-android target support

Am 22.01.2017 um 13:11 schrieb Alfred: > Hello, > > I would like to know if there already any news about this ? > > http://lists.freepascal.org/pipermail/fpc-devel/2016-August/037330.html So far I am not aware of any patch regarding this. ___ fpc-deve

Re: [fpc-devel] co-processor offset out of range issue in Debian armhf.

Am 26.01.2017 um 18:17 schrieb Jeppe Johansen: >> Any thoughts on what might cause this or possible fixes? my guess is that >> the compiler is missing >> an offset range check for access to local variables. >> > I'm fairly certain this is from spilling code as the only other case has > bounds che

Re: [fpc-devel] IsMultiThread always true issue 30535

Am 19.03.2017 um 21:33 schrieb Dimitrios Chr. Ioannidis via fpc-devel: > Hi, > > is the commit from 35567 rev. compatible with 3.0.x fixes branch ? If so is > it possible someone to > commit it also there ? It is too invasive to be backported. ___ f

Re: [fpc-devel] Optimization of redundant mov's

Am 20.03.2017 um 08:50 schrieb Jonas Maebe: >> And again, I've seen this happen more than once on i386 code, where it even >> creates "fake" register pressure (by using 2 or more registers to hold >> exactly >> the same temporary) > > That's again something that needs to be solved at the register

Re: [fpc-devel] Error: Data element too large / Compilation aborted .. unhandled exception .. AV

Am 15.03.2017 um 22:36 schrieb Hans-Peter Suter: > Goedenavond, > > The following snippet gives the above mentioned error message The error message for a 32 bit target is correct, the data structure is too big. > on Mac (Yosem.) and aborts the > compilation process on Ubuntu (14.04). Indeed, th

Re: [fpc-devel] fpc-devel Digest, Vol 156, Issue 16

Am 26.04.2017 um 12:57 schrieb Schindler Karl-Michael: >> The only alternative would be to advise *nix users to use the 3.0.0 >> release instead. >> >> Bart > > my two cents: > > 1) Why not call it 3.0.4? I would also think that we should aim at a quick 3.0.4 then. _

Re: [fpc-devel] Request for an interim release of the 3.0 branch

Am 28.04.2017 um 16:05 schrieb Marco van de Voort: > In our previous episode, Benito van der Zander said: >> >> r35545, too ? (http://bugs.freepascal.org/view.php?id=31135) > > I need some report on the safety of merging from a compiler dev for that, I > don't merge compiler revs on my own It is

Re: [fpc-devel] BacktraceStrFunc on linux x86_64?

Am 01.05.2017 um 10:40 schrieb Nikolai Zhubr: > 01.05.2017 11:21, Michael Van Canneyt: > [...] >> No, but the units that we distribute do not have debug information >> included. >> So if the error is in the RTL, then there is no debug information. > > Ok, right, but then I suppose it should show l

Re: [fpc-devel] BacktraceStrFunc on linux x86_64?

Am 01.05.2017 um 14:34 schrieb Marco van de Voort: > In our previous episode, Bernd Mueller said: >>> Only 3.0.2 linux for i386 CPU has the problem. 64-bit is OK. >> >> hmm, I don't get the lineinfo on x86-64 (Ubuntu 16.04/Mate, 64-Bit). >> armel and armhf are affected too. > > Please test with t

Re: [fpc-devel] BacktraceStrFunc on linux x86_64?

Am 01.05.2017 um 15:16 schrieb Marco van de Voort: > In our previous episode, Marco van de Voort said: http://www.stack.nl/~marcov/mergelogs26/backtrace.txt >>> >>> BTW: Could you extend your scripts to include links for the revs to ViewVC? >>> Pattern is: >>> https://svn.freepascal.org/cgi-b

Re: [fpc-devel] BacktraceStrFunc on linux x86_64?

Am 01.05.2017 um 17:10 schrieb Marco van de Voort: > In our previous episode, Florian Kl?mpfl said: >>> URL >>> 'https://svn.freepascal.org/svn/fpc/branches/fixes_3_0': >> >> Just relocate the check out? >> >> For people using git-svn, the section 'General Case' here: >> https://git.wiki.kernel.org

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

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 the assembler output again? > > r36200 | flo

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

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

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

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 revis

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

Am 21.05.2017 um 19:20 schrieb C Western: > 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, Flor

Re: [fpc-devel] Porting fpc to linux-sparc64

Am 29.05.2017 um 17:35 schrieb John Paul Adrian Glaubitz: > On Mon, May 29, 2017 at 05:11:52PM +0200, Karoly Balogh (Charlie/SGR) wrote: >> Err, sorry, there's a typo in the previous line I've sent. here's the >> correct one. Also, ASTARGET= override seems to work, so you don't need to >> patch the

Re: [fpc-devel] Porting fpc to linux-sparc64

Am 29.05.2017 um 10:37 schrieb John Paul Adrian Glaubitz: >> And/or completely unprepared for 64bit in any way. > > I actually don't think there would be much work necessary. fpc already > supports SPARCv9 which is actually by default a 64-bit architecture > (also known as UltraSPARC). Well, fpc

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

Am 05.06.2017 um 20:49 schrieb Jonas Maebe: > On 05/06/17 20:37, Denis Kozlov wrote: >> >> >> On 05/06/2017 18:59, Jonas Maebe wrote: >>> That is why I said "If range checking is off there or disabled via an >>> explicit type cast, then >>> the result is undefined by definition." You use an explic

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 02.07.2017 um 00:26 schrieb Martok: > Depending on the number of case labels, tcgcasenode.pass_generate_code > (ncgset.pas:1070) may choose one of 3 strategies for the "matching" task: > jumptable, jmptree or linearlist. Jmptree and linearlist are basically "lots > of > if/else", while jumptabl

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 02.07.2017 um 19:29 schrieb Martok: > Addendum to this: > >> This was also always my intuition that the else block is also triggered for >> invalid enum values (the docs even literally say that, "If none of the case >> constants match the expression value") - and it *is* true in Delphi. > There

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 02.07.2017 um 19:29 schrieb Martok: >type Percentile = 1..99; >var I: Percentile; >begin > I:= 99; > inc(I); // I is now 100 Forgot the mention: Tried with $r+ :)? >So if this is a legal statement, Well, it is a matter of definition, if a statement causing a rte 2

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 02.07.2017 um 19:51 schrieb Martok: > Booleans are not enums in Delphi (not even ordinals), They are: http://docwiki.embarcadero.com/Libraries/XE5/en/System.Boolean > but their own little > thing. "if boolean_expr" is always a jz/jnz, no matter what. Yes. This is an optimization which is in

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 02.07.2017 um 20:12 schrieb Martok: >> They are: >> http://docwiki.embarcadero.com/Libraries/XE5/en/System.Boolean > That prototype is a recent invention, it wasn't there in older versions. Also *sigh* This is the case since pascal was iso standarized. > the text sounds quite different somewhe

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 02.07.2017 um 19:55 schrieb Ondrej Pokorny: > On 02.07.2017 19:29, Martok wrote: >> - Case statements execute *precisely one* of their branches: the statements >> of >> the matching case label, or the else block otherwise > > To support your argument, the current Delphi documentation says the

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 02.07.2017 um 21:40 schrieb Martok: > Honestly, I still don't understand why we're even having this discussion. Because it is a fundamental question: if there is any defined behavior possible if a variable contains an invalid value. I consider a value outside of the declared range as invalid,

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 15.07.2017 um 17:17 schrieb Martok: > Several different ways of writing the (apparent) tautology "is EnumVar in > Low(EnumType)..High(EnumType)" all handle out-of-range-values (expressly, not > as > a side effect of something else). ... only because nobody implemented such an optimization yet

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 20:25 schrieb Ondrej Pokorny: > For now, Pascal enumerated types work as aliases for underlying ordinal > values - a concept that is > exactly the same as C enums: > Very good point: florian@ubuntu64:~$ cat test.cc #include enum tenum { e1,e2,e3,e4,e5,e6,e7,e8 }; int f(tenum

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 22:15 schrieb Martok: > > However: > --- > {$mode objfpc} > type > TExplEnum = (a=1, b=3, c=5, d=7); > TSubEnum = a..d; > TEnArr = array[TSubEnum] of Byte; > > begin > WriteLn('SizeOf(TEnArr) = ', SizeOf(TEnArr)); > WriteLn('Low(TEnArr) = ', Low(

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 22:39 schrieb Florian Klämpfl: > Am 16.07.2017 um 22:15 schrieb Martok: >> >> However: >> --- >> {$mode objfpc} >> type >> TExplEnum = (a=1, b=3, c=5, d=7); >> TSubEnum = a..d; >> TEnArr = array[

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

Am 21.08.2017 um 12:12 schrieb Benito van der Zander: > Hi, > >> This pattern is not inherently efficient. Why should it be ? > > > It is not efficient, because of the pointless instruction! Well, a register-register move can be considered almost as a nop on modern architectures. If you reall

Re: [fpc-devel] x86-64 optimizations

Am 24.09.2017 um 14:20 schrieb J. Gareth Moreton: > Hi everyone, > > Following on from an enhancement report I posted a few months ago, I decided > to take a shot at learning the > nuances of the compiler's source code and programming in the improvements > myself. These don't fix any bugs per

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

Am 14.10.2017 um 14:36 schrieb Martin: > I am trying to update pascal script. > > It seems that at some time there where changes in the register usage for > calling constructors. As far as I am aware, those did not change for years? I think the only way to find out what happens is to test what

Re: [fpc-devel] x86_64.inc CompareByte

Am 12.10.2017 um 20:37 schrieb sserg...@gmail.com: > Hi. > > Sorry for late message. But nobody still have said about possible problem > with > suggested patch. Well, it's always very hard to review such highly optimized code. I had a look and tested it and it worked, I didn't notice the prob

Re: [fpc-devel] x86_64.inc CompareByte

Am 16.10.2017 um 22:33 schrieb Markus Beth: > Sorry for the late reply. I had a weekend off(line). > > The instructions were chosen on purpose and Sergey already cited the part of > the Intel documentation > that explains why this is correct. You can find a similar part in AMD "AMD64 > Architect

Re: [fpc-devel] x86_64.inc CompareByte

Am 16.10.2017 um 23:08 schrieb Markus Beth: > On 16.10.2017 22:41, Florian Klämpfl wrote: >>> P.S.: I am currently working on another version of CompareByte that might >>> have a slightly higher >>> latency for very small len but a higher throughput (2 cycles per ite

Re: [fpc-devel] x86_64.inc CompareByte

e(buf1,buf2,len); end; end. > > > On 16.10.2017 23:08, Markus Beth wrote: >> On 16.10.2017 22:41, Florian Klämpfl wrote: >>>> P.S.: I am currently working on another version of CompareByte that might >>>> have a slightly higher >>>> latency

Re: [fpc-devel] x86_64.inc CompareByte

Am 23.10.2017 um 22:58 schrieb Markus Beth: > Here are the numbers for on ivy bridge CPU: > The output for [1] using the current RTL CompareByte is: >   9.001.275.281   cycles:u    ( +-  0,00% ) >  28.000.560.462   instructions:u #   3,11  insn per cycle ( +-  0,00% ) >   2,65473581

Re: [fpc-devel] x86_64.inc CompareByte

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 (Haswell CP

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

Am 01.11.2017 um 05:58 schrieb J. Gareth Moreton: > I also made versions that use memory fences and other checks such as memory > alignment in order to gain speed > - I've converted them to use the System V ABI of Linux as well, but are > currently completely untested as I > don't have the fac

Re: [fpc-devel] Revision 37555 (Florian)

Am 05.11.2017 um 22:27 schrieb Bart: > Hi, > > Just nitpicking here on a Sunday evening. > > "ports unit does not depend on objpas anymore", so {$Mode ObjFpc} was > removed, but the comment one line above weas left intact. It states: > > { this unit uses classes so > ObjFpc mode is required

Re: [fpc-devel] AMD64 - more efficient code padding

Am 11.11.2017 um 16:53 schrieb J. Gareth Moreton: > Hi everyone, > > So I've noticed that when certain blocks of code are aligned (usually to a > 16-byte boundary), the bytes in > between are set to a combination of 90H, 66 90H, 66 66 90H or 66 66 66 90H. > This is fine and all, but for > any

Re: [fpc-devel] Review of AVR patch for bug 31925

Am 22.09.2017 um 17:28 schrieb Christo: > On Fri, 2017-09-22 at 07:10 +0200, Christo wrote: >> On Wed, 2017-09-20 at 12:36 +0200, Karoly Balogh (Charlie/SGR) wrote: >>> > > A complication I've noted is that enabling overflow checking doesn't > call the fpc_mul_byte_overflow function (as the naming

Re: [fpc-devel] AVR - assembler error when compiling large files

Am 25.11.2017 um 16:53 schrieb Christo: > I am busy adding extra definitions to the AVR mcu files.  I've > encountered a problem when building some controller files with lots of > record and set definitions.  When I build the RTL the build process > fails with lots of assembler errors: > ../../rtl/

[fpc-devel] Test, please ignore

___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] AVR - assembler error when compiling large files

Am 25.11.2017 um 22:19 schrieb Christo: > On Sat, 2017-11-25 at 18:27 +0100, Florian Klämpfl wrote: >> What happens if you compile them with -CX? > Same problem. > >>>  Is there a way to instruct the compiler to use a larger data type >>> when >>> emitt

Re: [fpc-devel] AVR - assembler error when compiling large files

Am 30.11.2017 um 21:22 schrieb Christo: > On Tue, 2017-11-28 at 20:08 +0100, Florian Klämpfl wrote: >> What command line do you use? > > Also note that not specifying debug info (no -g) there is also no problem > compiling > atmega32u4.pp: Should be fixed with r37661,

Re: [fpc-devel] Compiler error for target AVR - r37660

Am 03.12.2017 um 13:51 schrieb Christo: > After updating to svn r37660 I cannot compile an empty program for AVR target: > > test.pp: program test; begin end. > > Compile with ../compiler/ppcrossavr -Cpavr5 -Pavr -Wpatmega328p test.pp > > test.pp(1,20) Fatal: Cannot find system type "variant". C

Re: [fpc-devel] Compiler error for target AVR - r37660

Am 07.12.2017 um 20:40 schrieb Christo: > On Sun, 2017-12-03 at 19:03 +0100, Florian Klämpfl wrote: >> Am 03.12.2017 um 13:51 schrieb Christo: >>> >>> After updating to svn r37660 I cannot compile an empty program for AVR >>> target: >>> >>>

Re: [fpc-devel] Vectorization

Am 10.12.2017 um 14:03 schrieb Marco van de Voort: > In our previous episode, J. Gareth Moreton said: >> Since I'm masochistic in my desire to understand and improve the Free Pascal >> Compiler, I would like to add >> some vectorisation support in its optimisation cycle, since that is one >> thi

Re: [fpc-devel] Vectorization

Am 10.12.2017 um 02:29 schrieb J. Gareth Moreton: > Hi everyone, > > Since I'm masochistic in my desire to understand and improve the Free Pascal > Compiler, I would like to add > some vectorisation support in its optimisation cycle, since that is one thing > that many other compilers > attemp

Re: [fpc-devel] Quickly recompiling fpc

Am 09.12.2017 um 14:49 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 the >

Re: [fpc-devel] Compiler error for target AVR - r37660

Am 04.12.2017 um 20:19 schrieb Christo: >> >> I guess I'm missing something? > > OK, missed a comment marker in the config file which is now fixed. Now I get > the origninal error > - Cannot find system type "variant" It should be fixed meanwhile. ___

Re: [fpc-devel] AVR calling convention for shortstring result type

Am 11.12.2017 um 21:58 schrieb Christo: > I'm trying to write an assembler function to read a string from program > memory using LPM and > return a shortstring result.  Consider the following prototype function: > > function readProgmemStr(constref s: shortstring): shortstring; > > It appears fr

Re: [fpc-devel] AVR assembler code consistency checking

Am 03.01.2018 um 15:48 schrieb Christo: > I'm trying to implement some error checking for assembler code for the AVR > target (e.g. issues > 32007, 32109 and 32261).  After stepping through the compiler code a couple > of times it seems as > if there isn't a proper assembler constraint check buil

Re: [fpc-devel] AVR assembler code consistency checking

Am 05.01.2018 um 11:24 schrieb Christo: > On Wed, 2018-01-03 at 18:10 +0100, Florian Klämpfl wrote: >> Am 03.01.2018 um 15:48 schrieb Christo: >>> >>> I'm trying to implement some error checking for assembler code for the AVR >>> target (e.g. >&

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

Am 11.01.2018 um 21:46 schrieb J. Gareth Moreton: > So while testing some proposed optimisations for how div and mod operations > are compiled, I came across an > internal error in the compiler. > > https://bugs.freepascal.org/view.php?id=33004 > > I haven't yet delved into the location of Inte

Re: [fpc-devel] Data alignment feature

Am 19.01.2018 um 21:08 schrieb J. Gareth Moreton: > Hi everyone, > > So unless anyone has any objections, I would like to start experimenting to > implement a feature that allows > for per-type data alignment. The main purpose for this is to better support > x86-64 SIMD extensions, where > al

Re: [fpc-devel] AVR assembler code consistency checking

Am 22.01.2018 um 21:35 schrieb Christo: > On Sat, 2018-01-06 at 16:03 +0100, Florian Klämpfl wrote: >> Am 05.01.2018 um 11:24 schrieb Christo: >>> >>> On Wed, 2018-01-03 at 18:10 +0100, Florian Klämpfl wrote: >>>> >>>> Am 03.01.2018 um 15:48 schri

Re: [fpc-devel] AVR assembler code consistency checking

Am 23.01.2018 um 09:11 schrieb Christo Crause: > On Mon, Jan 22, 2018 at 11:11 PM, Florian Klämpfl <mailto:flor...@freepascal.org>> wrote: > > > To me it looks good. I propose to commit if it breaks no existing code, > time will tell if the checks > are ok

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

Am 29.01.2018 um 21:11 schrieb Russell Davies: > Hi, > > Just curious, does the use of SHGetKnownFolderPath() in trunk package > winunits-base in fpttf.pp mean > the end of Windows XP support as this function is not available in XP's > shell32.dll Probably yes, at least with the release of 3.2.

Re: [fpc-devel] "Homogeneous Float Aggregate"

Am 04.02.2018 um 20:57 schrieb J. Gareth Moreton: > Hi everyone, > > So I've almost finished implementing Microsoft's 'vectorcall' calling > convention into Free Pascal - the final > sticking point are Homogeneous Float Aggregates (HFA's), since the > documentation isn't tremendously clear on

Re: [fpc-devel] FPProfiler

Am 18.02.2018 um 20:59 schrieb Anton Shepelev: > Why is not FPProfiler shipped as a binary with the > standard FreePascal distribution? I belive many > users would appreciate it, especially those using > Windows (as I am), where the standard Unix utilities > are not readily available and

Re: [fpc-devel] AVR assembler code consistency checking

Am 27.01.2018 um 09:18 schrieb Christo: > cOn Tue, 2018-01-23 at 21:57 +0100, Florian Klämpfl wrote: >> Just make a zip of the test programs. If they should fail during >> compilation, add a { %fail } >> comment as the first line, this tells the test runner, that the pro

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

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   _CTASSERT(1,1,'Constant failed.');end. > > I don't believe parameters are supported :-( > Why so sad? They are not supported on purpose

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

Am 25.02.2018 um 13:28 schrieb Giuliano Colla: > Il 25/02/2018 13:15, Sven Barth via fpc-devel ha scritto: > >> Yes, we definitely feel good about this, because we don't *want* parameter >> support in FPC's macro >> handling. > > Maybe I'm obtuse, but I fail to grasp the reason why. > Can you e

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

Am 25.02.2018 um 13:31 schrieb Florian Klämpfl: > Am 25.02.2018 um 13:28 schrieb Giuliano Colla: >> Il 25/02/2018 13:15, Sven Barth via fpc-devel ha scritto: >> >>> Yes, we definitely feel good about this, because we don't *want* parameter >>> support in FPC&

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

Am 25.02.2018 um 18:21 schrieb Giuliano Colla: > Il 25/02/2018 13:55, Florian Klämpfl ha scritto: > >>> To limit their use. > > Well, just for sake of argument, it appears to me a rather drastic approach. > > You may write other similar pages on stackoverflow, tell

Re: [fpc-devel] Some RTL bug fixes and suggestions

Am 04.04.2018 um 11:02 schrieb NetSpirit: > Anyone, who responsible to make fixes in code, please, correct this: > > In file 'rtl\win\wininc\struct.inc' there is differences in declaration of > NEWCPLINFO record: NEWCPLINFOA has field 'lpData', > but in NEWCPLINFOW this field named 'lData'. I thin

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

Am 28.04.2018 um 15:33 schrieb Thorsten Engler: > procedure XXX1; > asm > .noframe > nop > nop // added this > end; I did not look at the code in detail but I suspect this is caused by the two branches: cmp edx, $4330 jge @@zero cmp edx, $3FE0 jbe @@s

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 16.05.2018 um 14:57 schrieb Martok: > Hi all, > > as we have discovered in 0033576 and 0033614, there is a bug somewhere in the > loop unroll optimization pass that only appears in complex enough code. The > problem is, it doesn't happen in the single testsuite test, and the observable > crashe

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 17.05.2018 um 18:01 schrieb Martok: > I think I found something, see below. Answering the question first ;-) > > Am 16.05.2018 um 19:20 schrieb Florian Klämpfl: >> How big is the project? Normally, the number of unrolled loops is reasonable >> small so comparing the &

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 17.05.2018 um 19:01 schrieb Martok: > Same documentation for FPC, > > > But, someone clearly explicitly thought otherwise at some point: Sometime ago, fpc behaved strange in case of for loops and dfa, so it might have been that the comp

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

Am 18.05.2018 um 17:32 schrieb Ondrej Pokorny: > 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

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 18.05.2018 um 17:15 schrieb Sven Barth via fpc-devel: > Martok mailto:list...@martoks-place.de>> 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 th

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 21.05.2018 um 19:27 schrieb Ondrej Pokorny: > On 21.05.2018 18:23, Martok wrote: >> Am 21.05.2018 um 17:44 schrieb Florian Klämpfl: >>> I added raise, exit, goto and label as well. >> Oh, label, right. >> >> I'd say #0033614 can be resolved as "

Re: [fpc-devel] Kit's ambitions!

Am 13.05.2018 um 21:02 schrieb Christo: > On Sun, 2018-05-13 at 03:28 +0100, J. Gareth Moreton wrote: >>  Expand on Data Flow Analysis in the compiler. >> >> What I personally call the "Deep Optimizer", I'm proposing an >> assembler-level optimisation >> system (although it won't touch pure assemb

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 some

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

Am 28.05.2018 um 01:55 schrieb J. Gareth Moreton: > > 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 the first iteration), only

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

the reasons I mentioned. > > On Tue 29/05/18 21:27 , Florian Klämpfl > flor...@freepascal.org sent: >> Am 28.05.2018 um 01:55 schrieb J. Gareth > Moreton: >> >>> >> >>> In this case, the ".balign" hint adds >> 2 bytes to pad the loo

Re: [fpc-devel] Kit's ambitions!

Am 21.05.2018 um 21:05 schrieb J. Gareth Moreton: Would you object to me trying anyway, Florian? No, feel free to go ahead, but it needs to be done step by step. It might be that I run into the same problems you had and it's too unsafe, but I'm going by a conservative philosophy in that if it

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 21.05.2018 um 20:58 schrieb Ondrej Pokorny: In this (your) case I don't expect anything - it is one of FPC's favorites "undefined behaviour" because as documented, it is not allowed to change the loop variable value within a for loop. Yes, just asking :) In my case (without the I:=1 ass

Re: [fpc-devel] Kit's ambitions!

Am 12.06.2018 um 23:45 schrieb nick...@gmail.com: On Mon, 2018-06-11 at 21:07 +0100, J. Gareth Moreton wrote: Thanks David, I'm still learning some of the nuances of the Intel and AMD processors, but most of it is just logical analysis. Admittedly my main drive has been to shrink down the size

Re: [fpc-devel] Proposal for 2 new compiler functions

Am 12.06.2018 um 14:42 schrieb J. Gareth Moreton: Hi everyone, Sorry to flood the mailing list again with more ideas and experiments. I would like to propose introducing a new pair of in-built functions for the compiler. function FLog2(X: Cardinal): Cardinal; function CLog2(X: Cardinal): Card

Re: [fpc-devel] Kit's ambitions!

Am 12.06.2018 um 23:27 schrieb J. Gareth Moreton: Ideally yes, but this occurs after peephole optimisations where all of the register allocations have already been made. Doing the peephole and deep optimisations while the registers are still in a virtual state would be better overall, but may r

Re: [fpc-devel] Kit's ambitions!

Am 13.06.2018 um 20:50 schrieb J. Gareth Moreton: I haven't fully uncovered the secrets of the compiler yet, but I did notice "pre- peephole pass" under x86, but I think the only functions it touched was one of the bit shifts. Does this occur before register allocation or was it just something th

Re: [fpc-devel] Kit's ambitions!

Am 14.06.2018 um 23:49 schrieb J. Gareth Moreton: Hi Florian, I don't know if you have any answers, but I'm unable to apply any patches I receive. I can view them and see the changes, and manually apply them via copy+paste if I have to, but using the "Apply Patch" option ends up not doing anyt

Re: [fpc-devel] Kit's ambitions!

Am 15.06.2018 um 18:17 schrieb J. Gareth Moreton: Not much luck for me - the file won't patch without options or modifications, and using -p 1 to remove the "a/" and "b/" from the starts of the files causes an assertion in patch.exe. Sorry, my bad. The patch has unix line feeds, this crashes p

Re: [fpc-devel] AVX 512 - Can't compile vaddps zmm1, zmm2, zmm3

Am 17.06.2018 um 06:37 schrieb Joao Schuler: Hi, I started testing the AVX512 branch: https://svn.freepascal.org/svn/fpc/branches/tg74/avx512/ This is the code: {$ASMMODE intel} asm     vaddps  zmm1, zmm2, zmm3 end; The error message is: invalid combination of opcode and operands. The assemb

Re: [fpc-devel] Optimization theory

Am 16.06.2018 um 23:21 schrieb J. Gareth Moreton: Note that I speak mostly from an x86_64 perspective, since this is where I have almost universal exposure. So I've been pondering a few things after researching Florian's prototype patch for optimisations done prior to register allocation, when

Re: [fpc-devel] FPC fails on overload

Am 18.06.2018 um 22:00 schrieb David Jenkins: This is something that has just recently stopped working for us(with update to current trunk).  We previously were using trunk rev 36812 with no problems. Please submit a bug report to mantis. ___ fpc-deve

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

Am 30.06.2018 um 08:47 schrieb Sven Barth via fpc-devel: Willibald Krenn mailto:willibald.kr...@gmx.at>> 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 compi

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

Am 30.06.2018 um 12:02 schrieb Willibald Krenn: Gesendet: Samstag, 30. Juni 2018 um 10:54 Uhr Von: "Michael Van Canneyt" Am 30.06.2018 um 08:47 schrieb Sven Barth via fpc-devel: The variables we're talking about here *are* initialized. Bit lost here. Maybe A and B are setup, but not result

Re: [fpc-devel] Revision 39348 (Florian)

Am 30.06.2018 um 18:19 schrieb Bart: Hi Florian, I do nut really understand why you return a mantissa with the highest bit stripped off for type Extended. From what I have gathered about 80-bit extended type the mantissa of this type _is_ the full 64 bits, see http://rvelthuis.de/articles/arti

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

Am 03.07.2018 um 20:46 schrieb Ondrej Pokorny: On 03.07.2018 19:53, Stefan Glienke wrote: SetLength should not cause anything uninitialized. It enlarges or shrinks the data and keeps any prior data as it was, new allocated memory is zeroed (at least that is how it works in the Delphi RTL and I

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

Am 03.07.2018 um 21:30 schrieb Ondrej Pokorny: On 03.07.2018 20:54, Florian Klämpfl wrote: The warning happens also for any other call which takes an uninitialized variable as var parameter (see e.g. fillchar). So the warning increases only orthogonality of the language. It was an oversight

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

Am 03.07.2018 um 22:57 schrieb Ondrej Pokorny: 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 Init2(var A: TMyArray);    begin

<    1   2   3   4   5   6   7   8   9   >