Re: [fpc-devel] duplicate internal error numbers

On 07/10/2020 13:02, Marģers . via fpc-devel wrote: > found total 4300+ > 1001 error number has to be changed to make all error number unique > > as there are so huge number of changes to make i have question > 1) would it be desirable to change all (or most) duplicate error  > numbers in one

Re: [fpc-devel] Policy on platform-specific compiler code

On 16/10/2020 10:14, J. Gareth Moreton via fpc-devel wrote: > Before I go optimising the wrong thing, I have a question to ask.  > What's the policy on platform-specific assembly language in the > compiler, or any code designed to run on a specific (source) platform > (and using a more generic

Re: [fpc-devel] Support for FreeBSD PowerPC

On 14/10/2020 17:45, Curtis Hamilton via fpc-devel wrote: > I’ve been able to create a cross compiler using the guidance and some > additional information.  But I’ve been unable to create the proper FPC > startup code (prt0.as) needed. > > Any help would be appreciated. I believe these files

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

On 18/10/2020 13:34, J. Gareth Moreton via fpc-devel wrote: > I've just seen the change you've made Sven (just looking it via diff, > not actually testing the code)... do the standard Pascal comments > seriously cause a problem in AArch64 assembly blocks?  Do the braces > have an actual syntactic

Re: [fpc-devel] Question about internal compiler functions

On 23/08/2020 12:48, J. Gareth Moreton via fpc-devel wrote: > I've found a pretty big optimisation that benefits most ARM platforms, > including AArch64, but I'm getting a few random test failures. My > investigations suggest that functions like "fpc_chararray_to_unicodestr" and > other string

Re: [fpc-devel] Compiler development guides

On 18/08/2020 15:39, Florian Klämpfl via fpc-devel wrote: > Best is to use an existing backend and ask questions here. The AArch64 backend should be fairly clean as a starting point. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Planning to experiment with FPC extentions

On 26/08/2020 02:57, Boian Mitov via fpc-devel wrote: > I have been planning for long time to try to add support for advanced > RTTI to FPC, but never had the chance to work on it. > I don’t even know how to start. Is there any information on how to setup > for recompiling the compiler sources and

Re: [fpc-devel] Planning to experiment with FPC extentions

On 28/08/2020 10:20, Ryan Joseph via fpc-devel wrote: > Boian just today I made a little patch for a bug in the compiler > (https://bugs.freepascal.org/view.php?id=37650) and I recorded a short 8 min > video showing the process. I'm admittedly pretty terrible at making videos > but it may be

Re: [fpc-devel] TThread.Terminate;

On 22/08/2020 16:09, Martin via fpc-devel wrote: > procedure TThread.Terminate; > begin >   FTerminated := True; > end; > > Should that not in some way deal with memory barriers? E.g. > InterlockedExchange or similar? Very important: InterlockedExchange is not a memory barrier, except on x86. >

Re: [fpc-devel] Dwarf and "Result"

On 19/08/2020 20:01, Martin via fpc-devel wrote: > I just noted (testing with 3.3.1 from 2 or 3days ago) that -gw adds 3 > variables for result > "result" > "FUNCTIONNAME" > "RESULT" > > Why an upper, and lowercase result? "result" is the actual function result parameter. "FUNCTIONNAME" is an

Re: [fpc-devel] TThread.Terminate;

On 22/08/2020 17:39, Martin Frb via fpc-devel wrote: > I guess the "Terminate" field is actually about cache coherency. Yes, but as mentioned earlier it's in general completely useless to force the overhead of cache coherency for it. By design it's not something that will be checked immediately

Re: [fpc-devel] TThread.Terminate;

On 22/08/2020 17:39, Martin Frb via fpc-devel wrote: > Is there some really good article (better than the wikipedia > https://en.wikipedia.org/wiki/Memory_barrier) on > > - memory barrier > vs > - cache coherency > vs > interlocked > ? I think

[fpc-devel] macOS/AArch64 is now support by the LLVM backend

Hi, The latest FPC trunk can now generate code that targets macOS/AArch64. The testsuite results are good and Lazarus also works when compiled with this backend (although I haven't extensively tested it). Like for other targets, most additional testsuite failures compared to using the built-in

Re: [fpc-devel] WriteBarrier

On 24/08/2020 02:11, Martin via fpc-devel wrote: > Assuming the following >  (and not counting on Interlocked... doing any Barriers itself) > > Thread 1 >   Foo := val; // normal assign >   WriteBarrier; // make sure above write to Foo is executed, before the > next write to flag >  

Re: [fpc-devel] WriteBarrier

On 24/08/2020 19:20, Jonas Maebe via fpc-devel wrote: > It's not paranoid, it is the only correct way to write the code. * if you don't want to use regular synchronisation primitives, like mutexes/signals/events/... Jonas ___ fpc-devel maill

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

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

Re: [fpc-devel] Unknown compilerproc in r 46894

On 19/09/2020 14:11, Ryan Joseph via fpc-devel wrote: >> On Sep 19, 2020, at 5:43 PM, Jonas Maebe via fpc-devel >> wrote: >> >> It will work if you start your build with FPC 3.2.0 instead of 3.0.4. > yes, that worked. thanks. 3.0.4 is officially not possible to use f

Re: [fpc-devel] Unknown compilerproc in r 46894

On 19/09/2020 04:23, Ryan Joseph via fpc-devel wrote: > I was just going to test the applied patch > https://bugs.freepascal.org/view.php?id=36909 with revision 46894 and I got > this error. Any ideas? It will work if you start your build with FPC 3.2.0 instead of 3.0.4. Jonas

Re: [fpc-devel] Proposal/discussion: Simple nested functions and 'outlining'

On 01/10/2020 18:37, J. Gareth Moreton via fpc-devel wrote: > On a similar topic, one person mentioned that GCC and other compilers > sometimes 'outline' conditional branches by effectively moving the > branch into a nested procedure in order to help with caching.by giving > the main procedure a

Re: [fpc-devel] Proposal/discussion: Simple nested functions and 'outlining'

On 03/10/2020 18:43, J. Gareth Moreton via fpc-devel wrote: > Sounds like a fun thing to research, that's for sure.  Thanks Jonas. > > I'm under the impression that exception code tends to be separated > anyway, so it can't easily be separated much further. Implicit exception code, yes, but

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

On 29/12/2020 11:21, Pascal Riekenberg via fpc-devel wrote: > Windows 10 20H2 x86_64 > > How can i check binutils version? On Windows, FPC does not use binutils for assembling by default. What is your starting compiler version? Jonas ___ fpc-devel

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

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) Fatal: There were 3 errors compiling module, stopping On which OS is this? And

Re: [fpc-devel] Might need some help with this one

On 26/11/2020 16:34, J. Gareth Moreton via fpc-devel wrote: > P.S. Also, there seems to be a strange, unrelated glitch.  If I rename > the file to "break.pp" and change the program name to "break" (from > breakp), the compiled binary doesn't seem to write output (or it > immediately exits - can't

Re: [fpc-devel] Issue with Compiling FPC and MacOS Big Sur

On 2020-11-14 11:03, Michael Ring via fpc-devel wrote: > I recently upgraded to Big Sur on two devices and tried to compile > trunk based on official 3.2.0 compiler freshly downloaded from > sourceforge but compilation fails: That looks like you did not install the Xcode command line tools

Re: [fpc-devel] Compiler message colour scheme

On 22/11/2020 16:03, Ryan Joseph via fpc-devel wrote: > What version of the trunk is this in and what's the flag to enable it? My > trunk is maybe 30 days old and I don't see any way to get the colors. It's only enabled on Linux and Windows currently. Jonas

Re: [fpc-devel] Compiler message colour scheme

On 22/11/2020 17:42, Sven Barth via fpc-devel wrote: > Am 22.11.2020 um 17:40 schrieb J. Gareth Moreton via fpc-devel: >> Most modern Macs are Unix-based, so the escape sequences should work, >> right? Granted, I think we need someone with a Mac or a Mac virtual >> machine to test it for sure. >

Re: [fpc-devel] Issue with Compiling FPC and MacOS Big Sur

On 15/11/2020 17:16, Karoly Balogh (Charlie/SGR) via fpc-devel wrote: > e neither, but it's been like that ever since I upgrade to Mojave, that > these libs and objects are no longer in /usr/lib on my system. I used > Sierra on the same machine before, and that worked, then I updated to > Mojave

Re: [fpc-devel] Issue with Compiling FPC and MacOS Big Sur

On 15/11/2020 15:19, Karoly Balogh (Charlie/SGR) via fpc-devel wrote: > > Yes, I already had to dothis in my build scripts on Mojave. I defined an > "FIXMOJAVE" environment var, which contains that -XR/Library/... path you > wrote above, and in all my build scripts I just do: > > make

Re: [fpc-devel] Issue with Compiling FPC and MacOS Big Sur

On 14/11/2020 16:51, Michael Ring via fpc-devel wrote: > Hi Jonas, thank you for your answer! > > I cannot say if I did see a warning or not when installing fpc-package > but I did not reinstall commandline tools before or after installing the > 3.2.0 compiler. They have been on all of my Macs

Re: [fpc-devel] Support for FreeBSD PowerPC

On 20/10/2020 02:32, Curtis Hamilton via fpc-devel wrote: > I think I maybe in over my head on this. I've taken a look and now I'm not > sure what the issue is. The > segfault occurs in the FPC RTL initiazation code (see backtrace below). > > Any ideas? What does the prt0.as file that you

Re: [fpc-devel] initialization order of units

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 project with multiple units with initialization > section. And now > one of those units does not get initialized before it is

Re: [fpc-devel] Issue with Compiling FPC and MacOS Big Sur

On 24/12/2020 17:52, Joubert Nel via fpc-devel wrote: > When I delete the "fpc.cfg" file in my compilation directory, the > problem goes away.  > The same error occurs if I have an ".fpc.cfg" file in my home directory > so I avoid that too. Add the following line at the start of your custom

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

On 2021-01-09 16:01, Christo Crause via fpc-devel wrote: On Sat, Jan 9, 2021 at 3:52 PM Jonas Maebe via fpc-devel wrote: Could your idea not be simplified by allowing the use of the section directive when defining a pointer? type Peeprom = pointer; section '.eeprom'; This way when

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

On 08/01/2021 22:00, Christo Crause via fpc-devel wrote: > 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

Re: [fpc-devel] macos: -Xm leads to error while linking

On 24/01/2021 17:15, Виктор Матузенко via fpc-devel wrote: > It's official release, I've not tested with the trunk version. -Xm was > successfully > worked with fpc 2.6.x. That's strange, at first sight it did nothing for macOS in 2.6.x > Is this a bug? Should I create an issue in the bug

Re: [fpc-devel] 32 bit on linux -- /usr/bin/ld: cannot find -lpthread

On 31/12/2020 17:24, Martin via fpc-devel wrote: >> > I also tried to find any other potential dependency To no avail yet. > such as >  glibc-2.32-2.fc33.i686 => installed >  clthreads.i686 => installed (the only reasonable close match that came > up searching for thread) > > Any ideas? You

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

On 31/12/2020 20:32, Christo Crause via fpc-devel wrote: > For example I do not know how to generate the equivalent to the > following user assembler code: >   lds r0, EECR > where EECR is defined as follows in a different unit: > var EECR: byte absolute $1F; > > The following line illustrates

Re: [fpc-devel] Apple M1 processor

On 02/02/2021 16:48, C Western via fpc-devel wrote: > I have been trying out compiling my main application for the new Apple > M1 machines, and have two queries: > > The traceback on crashes does not include line numbers, when the same > flags on other architectures does. Is this something that

Re: [fpc-devel] Defer keyword

On 07/05/2021 07:26, Sven Barth via fpc-devel wrote: > Trunk also supports POSIX exceptions on selected *nix based systems, > though I haven't looked in depth yet in how far they incur a runtime > penalty (also they need to be enabled by enabling them in the compiler > and then recompiling

Re: [fpc-devel] Defer keyword

On 07/05/2021 18:41, Ryan Joseph via fpc-devel wrote: > Does that mean if you disable implicit exceptions then ALL ref counted types > leak memory? Only if an exception occurs. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Memory leak on BeginThread() when RTL compiled with -O2

On 24/05/2021 12:18, Yuriy Sydorov via fpc-devel wrote: > You can't first pass the -Mdelphi switch and then override it with > -Mfpc. -Mdelphi implicitly enables lot of other compiler options which > are not reverted by -Mfpc. That feels like a bug. Jonas

Re: [fpc-devel] Memory leak on BeginThread() when RTL compiled with -O2

On 25/05/2021 18:08, Yuriy Sydorov via fpc-devel wrote: > I've double checked this and the mode change seems to work fine. > The source of the issue is that specifying -Mfpc enables inlining which > triggers a bug in the Windows RTL. > I've fixed the bug in r49400. Thanks! Jonas

Re: [fpc-devel] Apple M1 processor

On 2021-02-09 23:30, C Western via fpc-devel wrote: I have located a possible fix; however I don't understand why I need to make the change I did. The variable reads/writes of concern currently use SetEvent in one thread and WaitFor in another - do these  not have implicit  memory barriers in

Re: [fpc-devel] Bug at SHA1File function..

On 04/04/2021 19:44, Daniel Gaspary via fpc-devel wrote: > I reported a bug at Sha1File function: > https://bugs.freepascal.org/view.php?id=38700 > > The FPC version I use is 3.0.4, because is the version available at > Ubuntu 20.04 LTS.. > > In the issue I received a reply warning that the

Re: [fpc-devel] [Core] Dangerous download on bug report

On 24/02/2021 12:11, Michael Van Canneyt via fpc-devel wrote: > > > On Wed, 24 Feb 2021, Bart via fpc-devel wrote: > >> The download links seems to have gone from the bugreport? >> (Or maybe I need new glasses) > > No, it is still there, comment from 2021-02-09 22:25: > >

Re: [fpc-devel] [Core] Dangerous download on bug report

On 2021-02-24 08:29, J. Gareth Moreton via fpc-devel wrote: It was through Mozilla Firefox though, so it might behave differently on different browsers. Perhaps a malicious ad on the site hijacked your click? If you don't use it yet, I'd strongly recommend adding

Re: [fpc-devel] FreeBSD PowerPC64 Port

On 19/04/2021 13:52, Karoly Balogh via fpc-devel wrote: > I have an older PowerMac, but honestly, I don't want to spend several days > trying to get FreeBSD running on it It's for PPC64LE. I think not even PowerMac G5s are supported by it. Jonas ___

Re: [fpc-devel] Quick question on VMT / writeable or protected memory

On 14/04/2021 17:49, Alfred via fpc-devel wrote: > The mORMot[1] sources could give you some info. > During runtime, it patches the exe-memory to redirect function calls. > Hard part was to get around the W^X memory protection on some BSD's. > > Look at: > > procedure PatchCode(Old,New: pointer;

Re: [fpc-devel] Generic class comparison operators

On 2021-04-17 22:02, Ryan Joseph via fpc-devel wrote: Since I'm working on generics right now can we finally, at the very least, allow class operators for comparison operators? This is literally the only way for a generic class to override the = operator (along with some others) so there's no

Re: [fpc-devel] Quick question on VMT / writeable or protected memory

On 14/04/2021 01:22, Martin Frb via fpc-devel wrote: > Opening a can of worms here. But leaving all pitfalls aside. > > If one wanted to write to the VMT of a class, would that be possible? > Would the VMT be stored in write-able memory, once the exe is loaded? It depends on the platforms. Most

Re: [fpc-devel] Adding new units to the compiler project

On 17/02/2021 20:06, J. Gareth Moreton via fpc-devel wrote: > I'm currently doing some experiments with vectorisation on x86 > platforms.  One thing this might entail is a new platform-specific unit > (e.g. "x86/nx86bas.pas").  What's the usual configuration required for > the projects to see the

Re: [fpc-devel] Apple M1 processor

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

Re: [fpc-devel] Apple M1 processor

On 02/02/2021 16:48, C Western via fpc-devel wrote: > > My application works fine single threaded, but crashes occasionally when > multi threaded, with what I think is some sort of memory corruption, but > I haven't been able to pin this down yet, and fixing the above two > points would help.

Re: [fpc-devel] Latest trunk - problems with codesign on MacOSX

On 12/02/2021 11:33, Michael Ring via fpc-devel wrote: > So, question one is if it is necessary to detect codesign path at all, > at least for my Mac's it is in /usr/bin It may not exist at all, e.g. on PowerPC Macs. > and, if this step is needed, > > please make the result of the detection

Re: [fpc-devel] Using -a or -s option forces change to external assembler

On 22/08/2021 16:48, Christo Crause via fpc-devel wrote: > Would it make sense to implement an alternative interpretation, where > the internal assembler is used if specified/default with just an output > writer for the -a case? The compiler only supports activating a single assembler writer at a

Re: [fpc-devel] Promote specific warning into error

On 24/09/2021 14:24, Marc Weustink via fpc-devel wrote: > Is there a way to promote a specific warning(4056) into an error ? {$warn 4056 error} There is no command line equivalent. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Merging identical procedure proposals

On 13/10/2021 19:33, J. Gareth Moreton via fpc-devel wrote: I figure this would be a whole-program optimization though due to inter-unit calls and comparisons and the like. Usually this is an optimisation that is performed at link-time because you don't need any compiler-level information for

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

On 03/10/2021 23:32, J. Gareth Moreton via fpc-devel wrote: > One drawback I've noticed is that there's no clean way to free the > optinfo pointer when the tai object is destroyed, The best way to handle this is by allocating the optinfo's from a pool (linked list of more or less arrays of

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

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 conformant. Or does it need to be (re-)implemented in Pascal itself? (Not implying

Re: [fpc-devel] fpc bug with M1

On 30/12/2021 21:07, Jonas Maebe via fpc-devel wrote: On 30/12/2021 21:03, Florian Klämpfl via fpc-devel wrote: Yes, but the question is: if we load a shortint into a register, do we need to sign extend it to 32/64 bit or not? I tend more and more to say that we shouldn’t require

Re: [fpc-devel] fpc bug with M1

On 30/12/2021 18:06, Florian Klämpfl via fpc-devel wrote: Ah yes, or like this. Nevertheless, the question is whether the ldrsb w0,[x0] is correct or not. Yes, I was unclear: with the "I don't know/remember where this is done" I meant "changing the load of the unsigned byte type into a

Re: [fpc-devel] fpc bug with M1

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-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: Ah

Re: [fpc-devel] fpc bug with M1

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: Ah yes, or like this. Nevertheless, the question is whether the ldrsb w0,[x0] is correct or not. Yes, I was unclear

Re: [fpc-devel] fpc bug with M1

On 30/12/2021 21:28, Martin Frb via fpc-devel wrote: Well the issue is, that at some time it needs to be extended, as the full expression is  Result := Result + (pn8^ shr 7) and ((not pn8^) shr 6); Result is either 64 or 32 depending on architecture. pn8 is pint8 On intel - only the byte is

Re: [fpc-devel] Unexpected range check error (64-bit only)

On 01/01/2022 13:01, Bart via fpc-devel wrote: OK, let me see if I understand it correctly now: 1. (Signed) Int64 := unsigned(32-16-8bit) + unsigned(32-16-8-bit) + signed(32-16-8-bit) gets evaluated with unsigned 64-bit arithmetic and then the test for Correct. How to workaround (1) then,

Re: [fpc-devel] Attn: J. Gareth // 3.3.1 opt = slower // Fwd: [Lazarus] Faster than popcnt

On 03/01/2022 12:54, Martin Frb via fpc-devel wrote: not sure if this is of interest to you, but I see you do a lot on the optimizer It's very likely unrelated to anything the optimiser does or does not do, and more regarding random differences in code layout. Charlie posted the

Re: [fpc-devel] Unexpected range check error (64-bit only)

On 2021-12-28 14:47, Bart via fpc-devel wrote: On Mon, Jun 28, 2021 at 8:33 PM Bart wrote: Int64 := Byte + Byte + (Signed integer type (8,16 or 32 bit) with value < 0) will always give a range check error on X86_64 platform (if range checking is enabled). Bump...

Re: [fpc-devel] Unexpected range check error (64-bit only)

On 28/12/2021 22:51, Bart via fpc-devel wrote: On Tue, Dec 28, 2021 at 9:38 PM Jonas Maebe via fpc-devel wrote: https://gitlab.com/freepascal.org/fpc/source/-/issues/37875 OK, but from reading that it is still unclear to me wether this is a bug or not. It's something that is annoying

Re: [fpc-devel] fpc bug with M1

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 In the below expression ...(not pn8^)... "pn8^" is

Re: [fpc-devel] fpc bug with M1

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 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

Re: [fpc-devel] Cross-compiling and warnings from linker

On 23/11/2021 17:17, Sergey Organov via fpc-devel wrote: Because it was not expected. I definitely can't point to any other user tool that, being installed in/opt/cross/bla-bla-bla/, would read configuration file from/etc/. Maybe I just didn't meet one yet. However, GCC, being most close to FPC

Re: [fpc-devel] Cross-compiling and warnings from linker

On 2021-11-12 10:20, Pierre Muller via fpc-devel wrote: Le 10/11/2021 à 21:19, Sergey Organov via fpc-devel a écrit : Hello, Using cross-compiler from x86-linux to arm-linux, I keep getting a lot of warnings at the linking stage of my programs, in the form: /opt/[...]/arm-linux-gnueabihf-ld:

Re: [fpc-devel] LLVM backend Pascal bindings?

On 2021-11-14 05:58, Ryan Joseph via fpc-devel wrote: As a fun weekend project I wanted to follow along with the tutorial at https://llvm.org/docs/tutorial/index.html but I noticed the API in in C++ so it wouldn't be possible to do this in Pascal without at least some plain C API. Afaik

Re: [fpc-devel] Cross-compiling and warnings from linker

On 12/11/2021 20:33, Sergey Organov via fpc-devel wrote: Thanks, I believe I already do use -XR, here is entire compilation line: /opt/cross/br/arm/armv7a/6.2.0.v6/usr/lib/fpc/3.2.0/ppcrossarm -O3 -CX -XX -Xs -veibq -vw-n-h- -MDelphiUnicode -Sg -Sc -XS -Tlinux -dCPU_ARM -Parm -CaEABIHF

Re: [fpc-devel] Cross-compiling and warnings from linker

On 21/11/2021 20:51, Sergey Organov via fpc-devel wrote: Then, in the /etc/fpc.cfg file, among a lot of statements inappropriate for cross-compilation (that happen to do no harm in my case), that is only expected for the file that belongs to installed native compiler, there is unconditional

Re: [fpc-devel] Cross-compiling and warnings from linker

On 22/11/2021 15:52, Jonas Maebe via fpc-devel wrote: On 21/11/2021 20:51, Sergey Organov via fpc-devel wrote: Then, in the /etc/fpc.cfg file, among a lot of statements inappropriate for cross-compilation (that happen to do no harm in my case), that is only expected for the file that belongs

Re: [fpc-devel] Need help!

On 30/10/2021 22:26, J. Gareth Moreton via fpc-devel wrote: Just to clarify, I cannot delete the branch because it's the default branch, and it won't update with the mirror because it's diverged, and I can't revert the accidental commit on Gitlab because it just adds a new commit saying the

Re: [fpc-devel] FreeBSD PowerPC64 Port

On 14/09/2021 06:38, Curtis Hamilton via fpc-devel wrote: I’m going to give this another try. I'm looking for some help with porting FPC to FreeBSD 13 on PowerPC64. Specifically, I’m looking for help with the startup code. I’m using a Raptor Blackbird Power9 system and will provide access if

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

On 13/01/2022 01:31, Ben Grasset via fpc-devel wrote: Isn't this specifically the kind of thing that the `FPC_SOFT_FPUX80` define solves? It's indeed what it's intended to solve, but currently it still generates different values compared to an actual x87 fpu. Jonas

Re: [fpc-devel] register calling convention for Apple M1 ?

On 16/02/2022 21:21, Dmitry Boyarintsev via fpc-devel wrote: On Wed, Feb 16, 2022 at 3:17 PM Martin Frb via fpc-devel mailto:fpc-devel@lists.freepascal.org>> wrote: Anything similar on M1? should it be ARM64 calling convention? https://en.wikipedia.org/wiki/Calling_convention#ARM_(A64)

Re: [fpc-devel] Prototype optimisation... Sliding Window

On 17/02/2022 20:25, J. Gareth Moreton via fpc-devel wrote: P.S. The term "sliding window" comes from the LZ77 compression algorithm and is used to track repeated sequences in ZIP files, among others. This prototype optimisation essentially uses the same construct, but built for instructions

Re: [fpc-devel] MacOS/dwarf: Was there any change to how/when relocation info is included.

On 24/03/2022 01:57, Martin Frb via fpc-devel wrote: It appears with 3.2.2  the address of a global var in dwarf already contains the relocation. Since fpdebug, does not retrieve any relocation info from lldb, it does not adjust any addresses. But with 3.3.1 it seems different.

Re: [fpc-devel] Problems with MM types (__m128 etc).

On 08/04/2022 20:31, J. Gareth Moreton via fpc-devel wrote: That might explain a few things.  The problem is that under vectorcall and the System V ABI (the default x86_64 calling convention for Linux), vector types are supposed to be fully supported, like an aligned array of 4 Singles should

Re: [fpc-devel] Problems with MM types (__m128 etc).

On 08/04/2022 19:57, J. Gareth Moreton via fpc-devel wrote: It looks like support for writing to arrays that are wholly stored in registers is a little limited and buggy Modifying individual elements of arrays stored in registers has never been enabled nor supported in the compiler. That is

Re: [fpc-devel] Problems with MM types (__m128 etc).

On 06/04/2022 22:58, J. Gareth Moreton via fpc-devel wrote: On 06/04/2022 21:16, Jonas Maebe via fpc-devel wrote: On 06/04/2022 19:20, J. Gareth Moreton via fpc-devel wrote: I recently made a merge request that initally just fixed the incorrect memory alignment for __m128 and similar types

Re: [fpc-devel] Problems with MM types (__m128 etc).

On 06/04/2022 19:20, J. Gareth Moreton via fpc-devel wrote: I recently made a merge request that initally just fixed the incorrect memory alignment for __m128 and similar types, but doing so revealed a whole plethora of other bugs.  First, when I fixed it, __m128 etc were no longer recognised

Re: [fpc-devel] JVM testing on x86_64

On 2022-06-08 14:42, J. Gareth Moreton via fpc-devel wrote: on x86_64-win64 after downloading the necessary runtimes, but how do I run the test suite for jvm-java? erroru.pp(25,3) Fatal: Unknown compilerproc "fpc_get_output". Check if you use the correct run time library. Fatal: Compilation

Re: [fpc-devel] JVM testing on x86_64

On 2022-06-08 15:15, J. Gareth Moreton via fpc-devel wrote: The testall.bat file took some modification since it doesn't handle parameters like testall.sh does.  I didn't get too far though: You have to install our own, patched version of Jasmin: https://wiki.freepascal.org/FPC_JVM#Download

Re: [fpc-devel] JVM testing on x86_64

On 2022-06-08 21:10, J. Gareth Moreton via fpc-devel wrote: Thanks for your help.  I've had to make a lot of changed to testall.bat since it was malformed in places.  I've got it working now though. Would there be interest in me creating a merge request with the improved TESTALL.BAT file for

Re: [fpc-devel] CFI

On 2022-06-07 11:09, Joost van der Sluis via fpc-devel wrote: This is a snippet of the information that the compiler typically generates: (x86_64-linux) fde: <0><0x00401090:0x004010c1> 0x00401090: 0x00401091: r16=-8(cfa) > 0x004010c0: This basically means

[fpc-devel] LLVM backend: support for address sanitizer

Hi, I have added support for LLVM's address sanitizer to the LLVM backend. You can find more information here: https://wiki.freepascal.org/LLVM#Using_Address_Sanitizer_.28asan.29 It caught a couple of (minor) errors in the compiler itself while I was testing it. Jonas

Re: [fpc-devel] What's the difference between -Cp and -Op?

On 2022-09-07 16:34, J. Gareth Moreton via fpc-devel wrote: So this one has eluded me a little bit... what's the exact difference between the -Cp and -Op options? -Cp: the code is only guaranteed to run on this cpu and usually also later ones (the code generator/optimiser can use

Re: [fpc-devel] M1 and Mac system support?

On 23/09/2022 10:16, Hairy Pixels via fpc-devel wrote: Come to think of it but there may be Swift-only frameworks starting to appear and I don’t know how/if they would be supported in FPC…. You can import Swift into Objective-C, so also in Objective-Pascal:

Re: [fpc-devel] Unicode RTL for FPC

On 06/01/2023 20:36, Adriaan van Os via fpc-devel wrote: Michael Van Canneyt via fpc-devel wrote: - String = UnicodeString, Char=WideChar UnicodeString ? ? I don't know what that is supposed to be. We have UCS-2, UCS-4, UTF-16 and UTF-8 Some marketing people, not understanding anything

Re: [fpc-devel] An interesting thought... AI

On 11/11/2022 00:44, J. Gareth Moreton via fpc-devel wrote: My slight concern is that the x86 peephole optimizer is becoming pretty bloated now An alternative could be to specify the peephole optimizations in a pattern matching format, and then either write a tool that converts them to a

Re: [fpc-devel] Using case statement instead of VTable

On 2023-04-11 07:23, Hairy Pixels via fpc-devel wrote: Strange question but I heard it brought up during a discussion and I was very curious what compiler people think about it. The question is, instead of using a virtual method table would it be feasible to use a case statement on the

Re: [fpc-devel] Unexpected "Range check error while evaluating constants" when compiling for Win64

On 12/02/2023 22:37, Yuriy Sydorov via fpc-devel wrote: property RootKey: HKey read FRootKey write FRootKey default HKEY_CURRENT_USER; Since HKEY = THandle = QWord on Win64, the reported range for it is incorrect. Afaik it's because "default" doesn't support qword values, iirc because of

Re: [fpc-devel] Cocoa and NOT relocatable

On 08/06/2023 18:40, Martin Frb via fpc-devel wrote: It seems that on Cocoa an exe is by default relocatable. At least a basic test shows that dumping a stack at runtime for each run (no new compile) gives new addresses. Fpc 3.2.2 Is there a way to turn this off? (some flag to pass to the

Re: [fpc-devel] Cocoa and NOT relocatable

On 08/06/2023 20:33, Martin Frb via fpc-devel wrote: 1) Afaik, FPC still can't resolve addresses with -gl (the line info unit, that produces nice dumps on other Platforms). FPC trunk can do it (provided you compile with -Xg) Jonas ___ fpc-devel

Re: [fpc-devel] Compiler for MacOS

On 08/02/2024 14:52, Adriaan van Os via fpc-devel wrote: Jonas Maebe via fpc-devel wrote: On 07/02/2024 15:35, Adriaan van Os via fpc-devel wrote: Unfortunately, there are some issues that make FPC at the moment unuseable on MacOS ... for people who use macpas mode. Indeed. But that raises

  1   2   >