Re: [fpc-devel] Xtensa compiler error when building RTL

Am 30.08.20 um 10:40 schrieb Christo Crause via fpc-devel: Since the bug tracker is offline I want to highlight this problem, before it slips my mind: Updating trunk revision this morning results in a failure for freertos-xtensa RTL (the cross compiler itself successfully bootstrapped):

Re: [fpc-devel] Github hosting of FPC utilities and [stable] sources

Am 15.10.20 um 02:33 schrieb Michael Fuchs via fpc-devel: Am 14.10.20 um 00:59 schrieb Michael Van Canneyt via fpc-devel: Will there still be an access via SVN or is git the only possibility? There are no plans to support SVN after the switch. That is a great pity. But I understand that

Re: [fpc-devel] Trunk does not build on AArch64

Am 18.10.20 um 08:56 schrieb J. Gareth Moreton via fpc-devel: (On another note, a number of AArch64 opcodes are missing, notably ADDS (add and set flags) and similar instructions - This is done by opcode prefixes. ___ fpc-devel maillist -

Re: [fpc-devel] Compiler development guides

Am 18.08.20 um 14:46 schrieb Dmitriy Pomerantsev via fpc-devel: Hello. Are there any guides for those who want to try adding something to the compiler? No, there aren't. For example, I would like to try making a new backend. Is there some example template, etc? Or just other backend code

Re: [fpc-devel] AArch64 Register efficiency

Am 20.08.20 um 14:18 schrieb J. Gareth Moreton via fpc-devel: Hi everyone. During my evaluation of the assembly language produced by the AArch64 implementation of the Free Pascal Compiler, I've noticed that it uses the stack an awful lot and, generally, not many of the 28 or so general-

Re: [fpc-devel] AArch64 Register efficiency

Am 20.08.20 um 15:09 schrieb J. Gareth Moreton: Oh dear, that's a shame. Havoc sounds fun though! Part of me wants to try anyway because I'm masochistic like that, but I'll do that privately. As an example, here's something from the classes unit - see how many references there are to [sp,

Re: [fpc-devel] Xtensa compiler error when building RTL

Am 30.08.20 um 12:20 schrieb Christo Crause via fpc-devel: On Sun, Aug 30, 2020 at 11:37 AM Florian Klämpfl via fpc-devel mailto:fpc-devel@lists.freepascal.org>> wrote: Am 30.08.20 um 10:40 schrieb Christo Crause via fpc-devel: > Since the bug tracker is offline I want to

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

Am 27.09.20 um 22:03 schrieb Florian Klämpfl via fpc-devel: Am 27.09.20 um 21:50 schrieb Florian Klämpfl via fpc-devel: Am 27.09.20 um 21:38 schrieb denisgolovan via fpc-devel: See above. It perfectly shows why it is frightening (not the basic stuff, but the transcendent functions

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

Am 27.09.20 um 21:38 schrieb denisgolovan via fpc-devel: See above. It perfectly shows why it is frightening (not the basic stuff, but the transcendent functions): - there are little libraries being really IEEE compliant for float128 - if they are IEEE compliant, their license does not allow to

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

Am 27.09.20 um 22:12 schrieb denisgolovan: Am 27.09.20 um 21:50 schrieb Florian Klämpfl via fpc-devel: Not for 80 bit extended, but it would be the clean solution with float128 support being optional in some architectures (RiscV, Sparc64, PPC64). So if we change it, we should do it right as 80

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

Am 27.09.20 um 20:57 schrieb denisgolovan via fpc-devel: Am 27.09.20 um 18:21 schrieb Florian Klämpfl via fpc-devel: So we would need softfloat extended support. This is doable with one major obstacle: the "irrational" functions like ld, sin etc.: they need precise enough implementati

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

Am 27.09.20 um 21:50 schrieb Florian Klämpfl via fpc-devel: Am 27.09.20 um 21:38 schrieb denisgolovan via fpc-devel: See above. It perfectly shows why it is frightening (not the basic stuff, but the transcendent functions): - there are little libraries being really IEEE compliant for float128

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

As long as there is no generic 80 bit float support in the compiler, there is no need to discuss anything else. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

> Am 28.09.2020 um 00:32 schrieb Nikolay Nikolov via fpc-devel > : > > I don't have an exact answer, but I think higher precision is better, > compared to lower. You can not expect bitwise identical result, when using > floating point calculations anyway. For example AMD and Intel FPUs

Re: [fpc-devel] Comment in math unit is a bit ambiguous?

Am 18.09.20 um 22:50 schrieb Bart via fpc-devel: Hi, In unit math.pp you can find this comment: 510 { returns random values with gaussian distribution } 511

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

Am 27.09.20 um 18:03 schrieb Martin Frb via fpc-devel: On 27/09/2020 09:34, Sven Barth via fpc-devel wrote: Ben Grasset via fpc-devel > schrieb am So., 27. Sep. 2020, 07:50: That last quote is absolute BS, to be very frank. There is no reason

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

Am 27.09.20 um 18:21 schrieb Florian Klämpfl via fpc-devel: The thing is: we would distribute a compiler (the x86_64-win64 one) which claims to be able to compile to e.g. to x86_64-linux, but it would generate programs which might behave differently than natively compiled ones as float

Re: [fpc-devel] ROL/ROR with Carry

Am 11.01.21 um 19:10 schrieb Sven Barth via fpc-devel: Hello together! Considering that jamie philbrook has given up on his feature request ( https://bugs.freepascal.org/view.php?id=38341 ) rather quickly and that it had been my idea for him to open that bug report I'd like to discuss this

Re: [fpc-devel] Attn Florian: r47852 broke building of i386

> Am 29.12.2020 um 10:49 schrieb Jonas Maebe via fpc-devel > : > > On 29/12/2020 08:17, Pascal Riekenberg via fpc-devel wrote: >> cpu.pp(77,15) Error: Unrecognized opcode xbegin >> cpu.pp(77,22) Error: Assembler syntax error >> cpu.pp(83,15) Error: Unrecognized opcode xend >> cpu.pp(269)

Re: [fpc-devel] Fpc does not allow Chr() in type definition. Bug?

Am 07.11.2020 um 23:00 schrieb Bart via fpc-devel: Hi, Type SubRange = Chr(1)..Chr(2); begin end. This compiles in TP 6.0 and Delphi 7.0, but fpc doesn't. Free Pascal Compiler version 3.3.1 [2020/09/26] for i386 Copyright (c) 1993-2020 by Florian Klaempfl and others Target OS: Win32 for

Re: [fpc-devel] Compiler message colour scheme

Am 22.11.2020 um 17:23 schrieb Ryan Joseph via fpc-devel: On Nov 22, 2020, at 8:57 AM, Jonas Maebe via fpc-devel wrote: It's only enabled on Linux and Windows currently. Why is that? Mac has colors in the terminal also. Because I have no Mac so I couldn't test it.

Re: [fpc-devel] initialization order of units

Am 22.10.20 um 23:04 schrieb Pascal Riekenberg via fpc-devel: Jonas Maebe via fpc-devel hat am 22.10.2020 22:28 geschrieben: On 22/10/2020 21:35, Pascal Riekenberg via fpc-devel wrote: Have there been any changes to the initialization order of units in the last 6 month? I have a complex

Re: [fpc-devel] Proposal for implementing named address space support

Am 31.12.20 um 21:35 schrieb Christo Crause via fpc-devel: On Thu, Dec 31, 2020 at 9:42 PM Jonas Maebe via fpc-devel mailto:fpc-devel@lists.freepascal.org>> wrote: On 31/12/2020 20:32, Christo Crause via fpc-devel wrote: > For example I do not know how to generate the equivalent to

Re: [fpc-devel] Attn Florian: r47852 broke building of i386

Am 02.01.2021 um 18:47 schrieb J. Gareth Moreton via fpc-devel: There still seems to be a problem with i386-win32 - this is from using FPC 3.2.0 as a base compiler and calling: make distclean all install CPU_TARGET=i386 OS_TARGET=win32 ... C:/FPC/3.2.0/bin/i386-Win32/ppc386.exe -Ur -Xs -O2 -n

Re: [fpc-devel] Creating uf2 files for arm-embedded and Raspberry Pi Pico

Am 22.01.21 um 22:02 schrieb Michael Ring via fpc-devel: Hi! Raspberry Pi organization announced the Raspberry Pi Pico (A dualcore Cortex-M0) and by coincidence I played with uf2 file format in the past days which is used by this board and many, many Adafruit boards to upload firmware in an

Re: [fpc-devel] Proposal for implementing named address space support

Am 08.01.21 um 22:00 schrieb Christo Crause via fpc-devel: On Sun, Oct 4, 2020 at 1:49 PM Christo Crause > wrote: FPC can use the section modifier to specify which address space should be used for data. I've made some progress in certain areas

Re: [fpc-devel] Difficulty building i386-win32

> Am 04.01.2021 um 11:34 schrieb J. Gareth Moreton via fpc-devel > : > > Hi everyone, > > I'm having a bit of difficulty building i386-win32 from my win64 workstation > (building under -CriotR -O4 because of my work on optimisation): > > [ 43%] Compiled package fv > Start compiling package

Re: [fpc-devel] dwarf 2 warning CIE

Am 02.02.21 um 11:24 schrieb Dimitrios Chr. Ioannidis via fpc-devel: Hi,   while I investigate some problems I'm having regarding avr debugging, I noticed that the dwarf 2 / 3 generation gives a warning when I call a procedure from another unit. Is it a bug or because it's a warning I can

Re: [fpc-devel] Discussion on a particular optimisation development (WARNING: Technical!)

Am 03.02.21 um 22:14 schrieb J. Gareth Moreton via fpc-devel: Rats, I might have messed up with some of the arithmetic, as well as the dangers of crossing bitwise with logical Boolean operations, although some combinations still work - if the conditions are "x = 0" rather than "x <> 0" in the

Re: [fpc-devel] Discussion on a particular optimisation development (WARNING: Technical!)

Am 02.02.21 um 22:06 schrieb J. Gareth Moreton via fpc-devel: Hi everyone, I've found a potential optimisation for conditions of the form "(x <> 0) and (y <> 0)", which are very common because this is semantically equivalent to "Assigned(x) and Assigned(y)", for example, and such a construct

Re: [fpc-devel] Discussion on a particular optimisation development (WARNING: Technical!)

Am 03.02.21 um 21:23 schrieb Sven Barth via fpc-devel: Am 03.02.2021 um 20:25 schrieb Florian Klämpfl via fpc-devel: Am 02.02.21 um 22:06 schrieb J. Gareth Moreton via fpc-devel: Hi everyone, I've found a potential optimisation for conditions of the form "(x <> 0) and (y &l

Re: [fpc-devel] Discussion on a particular optimisation development (WARNING: Technical!)

Am 03.02.21 um 22:36 schrieb J. Gareth Moreton via fpc-devel: On 03/02/2021 21:18, Florian Klämpfl via fpc-devel wrote: Am 03.02.21 um 22:14 schrieb J. Gareth Moreton via fpc-devel: Rats, I might have messed up with some of the arithmetic, as well as the dangers of crossing bitwise

Re: [fpc-devel] ARM/AARCH64 work

> Am 26.04.2021 um 08:09 schrieb J. Gareth Moreton via fpc-devel > : > > and the other is implementing "magic division" > where division by a constant is replaced with a multiplication. You are aware there is code for arm 32 bit and e.g. x86 which can most likely be reused/adapted? It

Re: [fpc-devel] [Dwarf AVR] DIE refers to abbreviation number which does not exist

Am 04.02.21 um 00:28 schrieb Dimitrios Chr. Ioannidis via fpc-devel: Hi,  in Windows which cross tools / toolchain for avr should I use ? FPC's avr-embedded- ( from https://svn.freepascal.org/svn/fpcbuild/binaries/i386-win32 ) or Microchip's AVR Toolchain for Windows (

Re: [fpc-devel] AVR systeminfo defaults to dwarf 3

> Am 10.02.2021 um 11:46 schrieb Dimitrios Chr. Ioannidis via fpc-devel > : > > Hi, > > I read at compiler/systems/i_embed.pas the AVR systeminfo, is the only one > that, has as default "dbg : dbg_dwarf3". The other embed systems that uses > dwarf ( ARM, MIPSEL, i8086, m68k, RISCV32/64,

Re: [fpc-devel] Proposal for implementing named address space support

Am 31.01.21 um 16:54 schrieb Christo Crause via fpc-devel: On Sun, Jan 24, 2021 at 10:13 PM Christo Crause mailto:christo.cra...@gmail.com>> wrote: My next challenge is to extend error checking so that call parameters are checked for section incompatibility. Is there a way to define

Re: [fpc-devel] Creating uf2 files for arm-embedded and Raspberry Pi Pico

via fpc-devel <mailto:fpc-devel@lists.freepascal.org>> wrote: Am 22.01.21 um 22:02 schrieb Michael Ring via fpc-devel: > Are you guys willing to accept that patch in fpc trunk? Yes. The commit message for r48394 should rather acknowledge Michael Ring as pat

Re: [fpc-devel] FPC 3.2.2-RC1 release, now with working link!

> Am 24.03.2021 um 16:45 schrieb Kirinn via fpc-devel > : > > On Wed, 24 Mar 2021 12:24:12 +0100 > Marco van de Voort via fpc-devel wrote: > >> Hello, >> >> We have placed the first release candidate of the Free Pascal Compiler >> version 3.2.2 on our ftp servers. >> >> You can help

Re: [fpc-devel] Public access of FPC features and settings

> Am 07.03.2021 um 15:12 schrieb Florian Klämpfl via fpc-devel > : > > Am 07.03.21 um 12:05 schrieb Alfred via fpc-devel: >> Hello, >> As a follow-up on a Lazarus feature request. >> Among other applications, Lazarus uses some hard-coded list that represent >&

Re: [fpc-devel] FPC 3.2.2-RC1 release, now with working link!

> Am 02.04.2021 um 14:01 schrieb Kirinn via fpc-devel > : > We have placed the first release candidate of the Free Pascal Compiler version 3.2.2 on our ftp servers. You can help improve the upcoming 3.2.2 release by downloading and testing this release. If you want

Re: [fpc-devel] Public access of FPC features and settings

> Am 02.04.2021 um 16:21 schrieb Michael Ring via fpc-devel > : > > Florian, it seems you missed a comment on that topic I wrote a while ago. > > You are right. The controller unit is written now like: ___

Re: [fpc-devel] Annoying error when building compiler on i386-win32

> Am 06.04.2021 um 10:42 schrieb Michael Van Canneyt via fpc-devel > : > > > > On Tue, 6 Apr 2021, Florian Klämpfl via fpc-devel wrote: > >> >> >>> Am 06.04.2021 um 07:37 schrieb Sven Barth via fpc-devel >>> : >>> Am 05.04.20

Re: [fpc-devel] Annoying error when building compiler on i386-win32

> Am 06.04.2021 um 07:37 schrieb Sven Barth via fpc-devel > : > > Am 05.04.2021 um 20:33 schrieb J. Gareth Moreton via fpc-devel: >> Hi everyone, >> >> I have a slightly annoying error when building the compiler for i386-win32. >> I mentioned it to Sven a while ago, and the cause is due to

Re: [fpc-devel] Public access of FPC features and settings

Am 08.03.21 um 10:46 schrieb Michael Van Canneyt via fpc-devel: On Sun, 7 Mar 2021, Florian Klämpfl via fpc-devel wrote: Am 07.03.21 um 12:05 schrieb Alfred via fpc-devel: Hello, As a follow-up on a Lazarus feature request. Among other applications, Lazarus uses some hard-coded list

Re: [fpc-devel] Public access of FPC features and settings

Am 07.03.21 um 12:05 schrieb Alfred via fpc-devel: Hello, As a follow-up on a Lazarus feature request. Among other applications, Lazarus uses some hard-coded list that represent FPC features. Like supported MCU and boards. It would be (much) more convenient to parse the FPC output itself to

Re: [fpc-devel] Optimisation and memory alignment question

Am 28.02.21 um 11:11 schrieb J. Gareth Moreton via fpc-devel: Hi everyone, So to get to the point, I've spotted another potential peephole optimisation specifically on x86_64:     movq    (%rdx),%rax     shrq    $32,%rax Is it acceptable to change this to the following?     movl   

Re: [fpc-devel] FreeBSD PowerPC64 Port

> Am 19.04.2021 um 14:22 schrieb Marco van de Voort via fpc-devel > : > > Op 2021-04-18 om 11:40 schreef Florian Klämpfl via fpc-devel: >>> Am 18.04.2021 um 00:45 schrieb Curtis Hamilton via fpc-devel >>> : >>> >>> Is there any interest i

Re: [fpc-devel] FreeBSD PowerPC64 Port

> Am 18.04.2021 um 00:45 schrieb Curtis Hamilton via fpc-devel > : > > Is there any interest in porting FPC to Freebsd/PowerPC64? > > I'm looking for some help with port FPC to FreeBSD on PowerPC. Any > assistance would be appreciated. > Interest in FreeBSD is apparently very little in

Re: [fpc-devel] [Dwarf AVR] DIE refers to abbreviation number which does not exist

Am 07.02.21 um 11:49 schrieb Dimitrios Chr. Ioannidis via fpc-devel: Hi,   I made some more tests, and it seems that there is a problem with the array types, used in other units where they are defined.   I don't know if it helps but, if I define an array type on unit B, which a unit A

Re: [fpc-devel] What is the status of -CfLIBGCC ? Can ib be considered good/working for embedded targets?

Am 14.02.21 um 14:42 schrieb Michael Ring via fpc-devel: Thanks, so I will try to have some fun with debugging softfp, 'fortuately' the first issue manifested itself in multiplying two numbers, may the gods of gdb smile on me! What assembler are you using? Ensure it's the external one

Re: [fpc-devel] What is the status of -CfLIBGCC ? Can ib be considered good/working for embedded targets?

Am 14.02.21 um 14:08 schrieb Michael Ring via fpc-devel: I am having a lot of (no-)fun with floating point on Cortex-M0, current summary would be to say that things get pretty unreliable once I start using Floats. I today stumbled over -CfLIBGCC, sounds interesting, but compiling

Re: [fpc-devel] AVR systeminfo defaults to dwarf 3

Am 11.02.21 um 09:34 schrieb Dimitrios Chr. Ioannidis via fpc-devel: You are probably right, I never checked if the pointer change of #33914 also fixed the original issue in the mailing list so the default dwarf version for AVR could be changed back to 2.  But then Florian does have a point,

Re: [fpc-devel] Making $FPCABI work as expected for embedded targets

Am 13.02.21 um 15:22 schrieb Michael Ring via fpc-devel: But as I am not that deep in the internals of FPC the question is if my change makes sense or if sonner or later my cat will explode or my Mac will suddenly convert to run Windows... or some other harmfull things will happen with making

Re: [fpc-devel] Enabling hardware floating point processor for cortex-m4f on embedded and freertos

Am 20.02.21 um 10:35 schrieb Michael Ring via fpc-devel: I have created an issue with this patch for ermbedded target, for unknown reason the 'end;' at the end of the patch for rtl/embedded/arm/cortexm4f_start.inc is missing, likely when I copy/pasted I lost that line. Sorry for this I

Re: [fpc-devel] Enabling hardware floating point processor for cortex-m4f on embedded and freertos

Am 20.02.21 um 22:54 schrieb Michael Ring via fpc-devel: the lm4f120 was the only unit that did not fit. funny enough it was already defined for armv7em so this patch only removes it from armv7m Thanks, applied. ___ fpc-devel maillist -

Re: [fpc-devel] Enabling hardware floating point processor for cortex-m4f on embedded and freertos

Am 19.02.21 um 21:55 schrieb Michael Ring via fpc-devel: When rtl for arm-embedded/arm-freertos is build with hardfloat the fpu should also automagically get enabled, by default it is off which causes a crash when floats are used. This small patch fixes that problem in cortexm4f_start.inc

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

> Am 22.08.2021 um 10:20 schrieb Bart via fpc-devel > : > > On Sun, Aug 22, 2021 at 5:40 AM J. Gareth Moreton via fpc-devel > wrote: > >> This is a problem I run into all the time Basically, the DLL is 64-bit >> and hence is invalid in a 32-bit binary. This can be bypassd by >> commenting

Re: [fpc-devel] Division optimisations

Am 10.09.21 um 21:17 schrieb J. Gareth Moreton via fpc-devel: Hi everyone, I'm looking at ways to optimise div and mod, starting with x86 and then probably AArch64.  The obvious one is attempting to merge "Q := N div D; R := N mod D;", where D is a variable (but invariant between the two

Re: [fpc-devel] Build failure in Fedora 35 due to glibc 2.34 code hardening

> Am 07.08.2021 um 16:59 schrieb Mattia Verga via fpc-devel > : > > Fedora has recently moved to using glibc 2.34. That caused Free Pascal > Compiler to stop building with the following output: > > /usr/bin/ld: >

Re: [fpc-devel] Build failure in Fedora 35 due to glibc 2.34 code hardening

> Am 08.08.2021 um 10:44 schrieb Karoly Balogh via fpc-devel > : > > Hi > > On Sun, 8 Aug 2021, Florian Klämpfl via fpc-devel wrote: > >>> One of the guys responsible for glibc in Fedora gave this explanation: >>> >>>> It's related to

[fpc-devel] Fwd: Preparing 3.2.4, call for merge request and regressions

Reminder :) So far I have only the second avr merge list from Christo open. Anything else? > > As the dust of the switch to git settles we would like to start preparing the > next release (3.2.4). To do so, some stuff from main (former trunk) might > need to be merged as well as regressions

Re: [fpc-devel] Register renaming and false dependency question

> Am 17.10.2021 um 13:25 schrieb J. Gareth Moreton via fpc-devel > : > > Hi everyone, > > While reading up on some algorithms, I came across a recommendation of using > a shorter arithmetic function to change the value of a constant in a register > rather than loading the new value

Re: [fpc-devel] Peephole optimizer tai class change proposals

> Am 11.10.2021 um 10:00 schrieb J. Gareth Moreton via fpc-devel > : > > One for Jonas mainly, but also for Florian. This is a new "extra > optimisation information" feature that allows the peephole optimizer to leave > 'notes' and other extra information on individual tai objects for later

Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions

Am 28.09.21 um 08:07 schrieb LacaK via fpc-devel: Thank you! Will there be also https://wiki.freepascal.org/FPC_New_Features_3.2.4 ? (I would like add there note) Now there is one ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions

Am 29.09.21 um 15:19 schrieb Gabor Boros via fpc-devel: 2021.09.26. 10:42 keltezéssel, Florian Klämpfl via fpc-devel írta: To do so, some stuff from main (former trunk) might need to be merged as well as regressions against 3.2.2 need to be fixed. Florian

Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions

Am 29.09.21 um 18:10 schrieb Christo Crause via fpc-devel: On Sun, Sep 26, 2021 at 10:42 AM Florian Klämpfl via fpc-devel mailto:fpc-devel@lists.freepascal.org>> wrote: A log of not yet considered commits can be found at https://gitlab.com/freepascal.org/fpc/merging/-/blo

Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions

> Am 01.10.2021 um 23:03 schrieb Christo Crause via fpc-devel > : > > On Wed, Sep 29, 2021 at 8:42 PM Florian Klämpfl via fpc-devel > mailto:fpc-devel@lists.freepascal.org>> > wrote: > Am 29.09.21 um 18:10 schrieb Christo Crause via fpc-devel: > > There is

Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions

>> >> Problematic - seems to require commits that affect other targets: >> 8fd0a27875abb2636a1388876f590a3a56d83b56 - commit doesn't compile, missing >> definition of labelcnt >> ae04e5d7f0c2527677b7c4ce6be2c235a4635c82 - doesn't compile, requires >> definition of TransferUsedRegs in

Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions

> Am 27.09.2021 um 08:47 schrieb LacaK via fpc-devel > : > > Hello, > > > Sorry for so long list, No problem, a list is probably much easier to use than the web interface. I cherry picked all mentioned commits into fixes. ___ fpc-devel maillist

[fpc-devel] Preparing 3.2.4, call for merge request and regressions

As the dust of the switch to git settles we would like to start preparing the next release (3.2.4). To do so, some stuff from main (former trunk) might need to be merged as well as regressions against 3.2.2 need to be fixed. To propose commits to be merged to fixes, either propose them here or

Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions

Am 24.10.21 um 16:52 schrieb Marco van de Voort via fpc-devel: Op 24-10-2021 om 14:09 schreef Florian Klämpfl via fpc-devel: Am 10.10.2021 um 15:55 schrieb Florian Klämpfl via fpc-devel : Reminder :) So far I have only the second avr merge list from Christo open. Anything else? Next

Re: [fpc-devel] FPC xtensa-freertos configuration for different esp-idf versions

> Am 24.10.2021 um 09:14 schrieb Christo Crause via fpc-devel > : > > Recently I updated my esp-idf version to 4.3 and ran into issues with > different linker scripts and library requirements. The design of this SDK is > still changing even between minor version updates. It seems

Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions

> Am 10.10.2021 um 15:55 schrieb Florian Klämpfl via fpc-devel > : > > Reminder :) > > So far I have only the second avr merge list from Christo open. Anything else? Next reminder, meanwhile, I merged the avr stuff. ___ fpc-deve

Re: [fpc-devel] Incorrect debug info for ESP32, linker error?

Am 04.12.2021 um 14:04 schrieb Christo Crause via fpc-devel: When compiling a simple test for esp32 (xtensa-freertos), the incorrect values for DW_AT_low_PC and DW_AT_high_PC are generated.  From my inspection of the generated assembler I cannot see anything wrong, but the values supplied by the

Re: [fpc-devel] Windows avr-embedded binutils binaries

> Am 07.12.2021 um 13:15 schrieb Dimitrios Chr. Ioannidis via fpc-devel > : > > Hi, > > where can I found the avr-embedded windows binaries from the build > repocitory ( https://svn.freepascal.org/svn/fpcbuild/binaries/i386-win32 ) ? > The link, of course, does not work now . I have

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do ...

> Am 19.12.2021 um 14:38 schrieb Jonas Maebe via fpc-devel > : > > On 19/12/2021 14:21, Nikolai Zhubr via fpc-devel wrote: >> Just out of curiosity, couldn't bochs' x87 fpu implementation be of some use >> here? >> It is approx 12k of C code and it is LGPL. Supposedly it is not fast but >>

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

> Am 19.12.2021 um 09:45 schrieb Sven Barth via fpc-devel > : > > Ben Grasset via fpc-devel > schrieb am So., 19. Dez. 2021, 08:33: > To be very clear, to me, this is absolutely nothing more than just a matter > of building the compiler completely

Re: [fpc-devel] fpc bug with M1

> Am 30.12.2021 um 20:57 schrieb Jonas Maebe via fpc-devel > : > > On 30/12/2021 20:55, Martin Frb via fpc-devel wrote: >> On 30/12/2021 20:46, Jonas Maebe via fpc-devel wrote: >>> On 30/12/2021 18:06, Florian Klämpfl via fpc-devel wrote: >>>>

Re: [fpc-devel] fpc bug with M1

> Am 30.12.2021 um 21:07 schrieb Jonas Maebe via fpc-devel > : > > On 30/12/2021 21:03, Florian Klämpfl via fpc-devel wrote: >>> Am 30.12.2021 um 20:57 schrieb Jonas Maebe via fpc-devel >>> : >>> >>> On 30/12/2021 20:55, Martin Frb via fpc-de

Re: [fpc-devel] jUnit output for fpcunit

Am 29.12.2021 um 14:50 schrieb Joost van der Sluis via fpc-devel: Hi all, I'm trying to run my fpcunit unit-tests on Gitlab, and let Gitlab show the results. But it can only handle JUnit-like xml. Does someone already have something lying around to convert the fpcunit format into junit?

Re: [fpc-devel] fpc bug with M1

Am 30.12.21 um 14:52 schrieb Jonas Maebe via fpc-devel: On 29/12/2021 00:48, Martin Frb via fpc-devel wrote: I don't have an M1 myself, but according to the data from the thread on the lazarus mail list, there is a bug in the 3.3.1 asm generator for M1 var pn8: pint8; // pointer signed byte

Re: [fpc-devel] fpc bug with M1

> Am 30.12.2021 um 17:51 schrieb Jonas Maebe via fpc-devel > : > > On 30/12/2021 17:16, Florian Klämpfl via fpc-devel wrote: >> Am 30.12.21 um 14:52 schrieb Jonas Maebe via fpc-devel: >>> On 29/12/2021 00:48, Martin Frb via fpc-devel wrote: >>>> I

Re: [fpc-devel] Optimisation and thread safety

> Am 13.11.2021 um 00:55 schrieb J. Gareth Moreton via fpc-devel > : > > Hi everyone, > > I have a question when it comes to optimising memory reads and writes. What > are the rules for FPC when it comes to writing to memory and then reading > from it later within a single subroutine? For

Re: [fpc-devel] FPC trunk building lazarus trunk fails with compiler AV ?

Am 12.12.2021 um 15:18 schrieb Marco van de Voort via fpc-devel: On 12-12-2021 14:47, Yuriy Sydorov via fpc-devel wrote: Any pointers? I've tried to reproduce the AV while building Lazarus on i386-win32 with -O2 and -O3 options, but it works for me. What compiler options have you used to

Re: [fpc-devel] Incorrect debug info for ESP32, linker error?

> Am 05.12.2021 um 06:09 schrieb Christo Crause via fpc-devel > : > > > On Sat, Dec 4, 2021 at 5:23 PM Florian Klämpfl via fpc-devel > mailto:fpc-devel@lists.freepascal.org>> > wrote: > Am 04.12.2021 um 14:04 schrieb Christo Crause via fpc-devel: > > Wh

Re: [fpc-devel] Double-checking an optimisation

> Am 09.01.2022 um 15:08 schrieb J. Gareth Moreton via fpc-devel > : > > On 09/01/2022 12:35, Florian Klämpfl via fpc-devel wrote: >>> It removes a jump and a label, which might permit other long-range >>> optimisations, but it's 3 instructions that are in a d

Re: [fpc-devel] Plans for 2022

> Am 09.01.2022 um 08:09 schrieb J. Gareth Moreton via fpc-devel > : > > Some people requested a Patreon post as to my plans for 2022 with FPC, so I > was happy to oblige. Plans may change a bit though depending on what happens > in life and also what Florian's own vision is with the

Re: [fpc-devel] Double-checking an optimisation

Am 09.01.2022 um 01:37 schrieb J. Gareth Moreton via fpc-devel: Hi everyone, So a merge request of mine was just approved that allows the peephole optimizer access to more registers when it needs one for temporary storage.  It allows it to make an optimisation on x86_64-win64 that wasn't

Re: [fpc-devel] @Gareth - Feedback on optimizations

> Am 09.01.2022 um 18:59 schrieb Martin Frb via fpc-devel > : > > Just thought this may be interesting. > Though the results are for "eyeballing" at best -- see the video linked in > Jonas' recent mail: > https://lists.freepascal.org/pipermail/fpc-devel/2022-January/044336.html > > I run my

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

> > 5) When CPU is the bottleneck (antivirus turned off), the 32-bit hosted > compiler is faster. This still needs confirmation, though, because your > results show 32-bit being slower, but you didn't say whether antivirus was > off. Compilation speed of FPC is typically memory

Re: [fpc-devel] Issue 3.2.3 (ok in 3.3.1) Win64 "raise exception" does not go to "except"

Am 13.01.2022 um 16:49 schrieb Martin Frb via fpc-devel: In the  below code compiled with 3.2.3 (today and early Dec) when the exception is reached the app exits. There is no code from finally, nor from except block executed. The "randomize" is just to put some code into each block. No special

Re: [fpc-devel] Questions about cross-compiling (z80)

Am 11.02.2022 um 22:20 schrieb BogDan via fpc-devel: Hi, Thanks a lot for your quick reply. Adding ihxutil to path fixed the problem. But the size problem is stil there, a simple 2 lines of code "begin; end."  generates over 32k of code. That code should not generate more than 8 bytes of

Re: [fpc-devel] Questions about cross-compiling (z80)

Am 12.02.2022 um 10:18 schrieb BogDan: Hey, zx spectrum has ~41k or ram available for apps (it has 48k in total but ~7k are needed for screen). If RTL needs has over 32k it will not be too much left for the application itself. IMHO the z80 port RTL should have at least two implementations: -

Re: [fpc-devel] Questions regarding m68k-atari target

> Am 12.02.2022 um 11:46 schrieb Karoly Balogh : > > Hi, > > On Sat, 12 Feb 2022, Florian Klämpfl via fpc-devel wrote: > >>>> My config file has -Tatari set, so the LINUX define is no issue. But if >>>> i invoke the compiler without excplicit

Re: [fpc-devel] Questions regarding m68k-atari target

Am 12.02.2022 um 10:54 schrieb Karoly Balogh via fpc-devel: Hi, On Sat, 12 Feb 2022, Thorsten Otto via fpc-devel wrote: I'm currently trying to set this up and have a problem with the cross-compiler. Although that was configured for atari and 68000, it still has LINUX and CPU68020 defined

Re: [fpc-devel] Package build failure under i386-win32

> Am 03.04.2022 um 15:44 schrieb J. Gareth Moreton via fpc-devel > : > > Hi everyone, > > It seems at some point, something was introduced to the compiler that causes > a package to fail to build (specifically packages\chm\src\chmwriter.pas) with > an assembler-level range check error. If

Re: [fpc-devel] case is

> Am 24.03.2022 um 02:40 schrieb Hairy Pixels via fpc-devel > : > > > >> On Mar 24, 2022, at 7:21 AM, Michael Van Canneyt via fpc-devel >> wrote: >> >> I am all for merging the implementation of Ryan, but this is not my domain, >> so one of the compiler people needs to look at it. >> >

Re: [fpc-devel] Any word on this ARM / AArch64 optimisation?

> Am 21.01.2022 um 18:23 schrieb J. Gareth Moreton via fpc-devel > : > > Hi everyone, > > Any word on the validity of this ARM / AArch64 optimisation? It's quite good > at increasing speed and shrinking code size by concatenating writes to the > stack, among other things: >

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do ...

Am 19.12.21 um 14:52 schrieb Florian Klämpfl: Am 19.12.2021 um 14:38 schrieb Jonas Maebe via fpc-devel : On 19/12/2021 14:21, Nikolai Zhubr via fpc-devel wrote: Just out of curiosity, couldn't bochs' x87 fpu implementation be of some use here? It is approx 12k of C code and it is LGPL.

Re: [fpc-devel] x86: Efficiency of opposing CMOVs

> Am 16.04.2022 um 06:49 schrieb J. Gareth Moreton via fpc-devel > : > > Hi everyone, > > In the x86_64 assembly dumps, I frequently come across combinations such as > the following: > > cmpl%ebx,%edx > cmovll%ebx,%eax > cmovnll%edx,%eax > > This is essentially the

  1   2   >