Re: [fpc-pascal] Floating point question

On 12/02/2024 10:55, Michael Van Canneyt via fpc-pascal wrote: On Mon, 12 Feb 2024, Thomas Kurz via fpc-pascal wrote: I wouldn't say so. Or at least, not generally. Why can't the compiler do what the programer intends to do: var  s: single;  d: double;  e: extended; begin  s := 8427.0 +

Re: [fpc-pascal] Floating point question

On 11/02/2024 23:21, Bernd Oppolzer via fpc-pascal wrote: and this would IMHO be the solution which is the easiest to document and maybe to implement and which would satisfy the users. And generate the slowest code possible on most platforms. Jonas

Re: [fpc-pascal] Floating point question

On 09/02/2024 14:04, James Richters via fpc-pascal wrote: Is there any way we can please get -CF80 or {$MINFPCONSTPREC 80} or some other way to turn off the new behavior for applications that use Extended. The reason I didn't add it back then is because when parsing the options, there is no

Re: [fpc-pascal] Floating point question

On 05/02/2024 01:31, James Richters via fpc-pascal wrote: So I need to do this? AA = Extended(8427+Extended(33/Extended(1440.0))); Just typecasting 1440.0 to extended should be enough. This is inconsistent, why didn't the 1440.1 version reduce to a single? Because 1440.1 cannot be

Re: [fpc-pascal] Floating point question

On 06/02/2024 16:23, James Richters via fpc-pascal wrote: Great if -CF80 worked, but even if you are happy with -CF64, my problem is: how is anyone coming into FPC after 2.2 supposed to know that their constants that always worked before are going to no longer be accurate?? By reading the

Re: [fpc-pascal] Floating point question

On 04/02/2024 23:21, James Richters via fpc-pascal wrote: Shouldn’t this do all calculations as Extended? AA = Extended(8427+33/1440.0); No, this only tells the compiler to interpret the result as extended. Jonas ___ fpc-pascal maillist -

Re: [fpc-pascal] Floating point question

On 04/02/2024 13:50, Adriaan van Os via fpc-pascal wrote: Jonas Maebe via fpc-pascal wrote: On 03/02/2024 18:42, James Richters via fpc-pascal wrote: Constants are also evaluated wrong,you don’t know what that constant is going to be used for, so all steps of evaluating a constant MUST

Re: [fpc-pascal] Floating point question

On 03/02/2024 18:42, James Richters via fpc-pascal wrote: Constants are also evaluated wrong,you don’t know what that constant is going to be used for, so all steps of evaluating a constant MUST be done in extended by the compiler, or the answer is just wrong. See

Re: [fpc-pascal] What's in Hello World

On 07/01/2024 13:21, Ingemar Ragnemalm via fpc-pascal wrote: Just for comparison, I fired up Think Pascal and made Hello world! Plain Hello world, closes so quickly that you don't have time to see it: 4625 bytes. Including ShowText and while not Button do; 4639 bytes. Yes, less than 5k!

Re: [fpc-pascal] Does the varargs specifier behave differently on 32 and 64 bit platforms?

On 05/01/2024 14:38, Thomas Kurz via fpc-pascal wrote: The CDECL calling convention should pass all arguments on the stack It does not do that in all (or even most) cases. The CDECL calling convention passes arguments according to what the platform's ABI prescribes. For Windows/x64, that

Re: [fpc-pascal] Does the compiler make prodigious use of use ENTER instruction?

On 12/12/2023 17:48, Anthony Walter via fpc-pascal wrote: Do any of the compiler devs know if Pascal programs for the x86 instruction set are using ENTER and its second argument to the best possible effect? I am curious. FPC used it in the past, but stopped using it because 1) on modern

Re: [fpc-pascal] Quick question

On 15/09/2023 18:02, Paul Renaud via fpc-pascal wrote: A quick question about FreePascal for Arm32. Does the floating point code generated by the compiler depend on the vector length being set at zero? If I were to change the vector length that the VFP processes to 3 which would enable

Re: [fpc-pascal] LLVM LTO

On 15/08/2023 17:24, Benito van der Zander via fpc-pascal wrote: Hi -Clflto -Clflto-no-system -k-fuse-ld=gold -k-plugin=/path/to/LLVMgold.so that helped, but I have to do it without -Clflto-no-system, or it gives an error That was a typo, it's -Clfltonosystem. But it doesn't matter if the

Re: [fpc-pascal] Barriers semantics

On 14/08/2023 21:55, denisgolovan via fpc-pascal wrote: On 14/08/2023 18:19, denisgolovan via fpc-pascal wrote: ReadDependencyBarrier - which one is that? You cannot express a ReadDependencyBarrier in terms of acquire/release. See e.g. the explanation of "data dependency barrier" at

Re: [fpc-pascal] Barriers semantics

On 14/08/2023 18:19, denisgolovan via fpc-pascal wrote: Now we have "volatile" intrinsic for assignments in place, I'd like to ask for another clarification. Just to make sure given your questions below: using volatile in the context of multithreaded code is completely wrong in 99.9% of the

Re: [fpc-pascal] Volatile store usage

On 11/08/2023 18:05, denisgolovan via fpc-pascal wrote: Are "volatile" stores supported? They weren't, but I've added support for it now. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] LLVM crash

On 10/08/2023 23:27, Benito van der Zander via fpc-pascal wrote: i tried to run my program under LLVM (from july fpc)  and it crashes? Program received signal SIGSEGV, Segmentation fault. 0x0042e5f1in SYSTEM_$$_SYSGETMEM_FIXED$QWORD$$POINTER() (gdb) bt #0 0x0042e5f1in

Re: [fpc-pascal] LLVM LTO

On 10/08/2023 17:06, Benito van der Zander via fpc-pascal wrote: I tried to use the LLVM Link-Time-Optimization, -Clflto I should update the wiki page. Under Debian 11, I can tell FPC to use gold with lto by specifying the following command line parameters: -Clflto -Clflto-no-system

Re: [fpc-pascal] $IMPLICITEXCEPTIONS vs early function return

On 15/07/2023 16:53, Hairy Pixels via fpc-pascal wrote: On Jul 15, 2023, at 7:18 AM, Jonas Maebe via fpc-pascal wrote: It also sets up an exception frame. FPC uses setjmp/longjmp for that, which means that while restoring everything when an exception happens is fast, saving the exception

Re: [fpc-pascal] $IMPLICITEXCEPTIONS vs early function return

On 15/07/2023 04:25, Hairy Pixels via fpc-pascal wrote: The manual says it makes all functions slower, 5-10%?? Does that apply to all functions or just ones with managed types in them? It's also curious why the try..finally block would have the kind of impact, all it does is call finalize

Re: [fpc-pascal] What is -CO ?

On 09/06/2023 12:03, Mattias Gaertner via fpc-pascal wrote: What is -CO? In the docs I can only find this sentence: "Check for possible overflow of integer operations" It prints a warning whenever the compiler inserts an implicit type conversion to a type that cannot represent every value of

Re: [fpc-pascal] FPC ARM inline Assembler

On 06/04/2023 19:06, Vern via fpc-pascal wrote: .. the ARM version fails (similar code : ignore the fact it is the reverse of BSR) ... what am I missing ? procedure MSBitTest ( DataIn : longword); var  MSBit : longword; begin  asm   clz w4 , DataIn   mov MsBit , w4  end; end;

Re: [fpc-pascal] Converting old pascal written for Pascal/MT+ compiler

On 04/04/2023 16:14, Bart via fpc-pascal wrote: If your local "writeable constant" is of type string, and strings are longstrings, and the writeable const is assigned a value that is the result of a string concatenation, then you'll have a memory leak. That does not matter in practice (*),

Re: [fpc-pascal] Cache-line alignment for records

On 29/03/2023 16:00, Matias Ezequiel Vara Larsen via fpc-pascal wrote: So if I have a type like: test = record r: DWord; s: Word; end; Then, I define the variable `nada` as an array of `test` type: var nada: array[0..2] of test; Is the `@nada[1].r` element aligned to 4-bytes?

Re: [fpc-pascal] Cache-line alignment for records

On 27/03/2023 21:25, denisgolovan via fpc-pascal wrote: But it's still not possible to attach alignment to type itself instead of variable, right? It is possible (https://gitlab.com/freepascal.org/fpc/source/-/blob/main/tests/test/talignrec1.pp), but it is subject to the same limitations

Re: [fpc-pascal] Cache-line alignment for records

On 27/03/2023 09:28, Matias Ezequiel Vara Larsen via fpc-pascal wrote: Apologies in the case this subject has been already discussed. I require that some global variables be cache-line aligned. This is a requirement for per-CPU variables that are statically defined to prevent cache ping-pong. Is

Re: [fpc-pascal] Building compiler which stalls

On 04/03/2023 07:24, Hairy Pixels via fpc-pascal wrote: # 1. Compile a native AArch64 compiler from the FPC trunk source make distclean make FPC=ppcx64 OPT="-ap -FD${TOOLCHAIN} -XR${MACOS_SDK}" CPU_TARGET=aarch64 -j 4 FPMAKEOPT="-T 4" all There is no need anymore to start with ppcx64 now that

Re: [fpc-pascal] Building compiler which stalls

On 04/03/2023 07:24, Hairy Pixels via fpc-pascal wrote: Here’s the build command I used and it builds the compiler up to step #2 but then when it copies the compiler to compiler/ppca64 things fall apart. I noticed the following command "make distclean” stalled out at some point so I tried to

Re: [fpc-pascal] Strange floating-point result

On 11/11/2022 11:49, Thomas Kurz via fpc-pascal wrote: Why do I have to explicitly cast Integer to Double here? Because 1.2E6 can be represented exactly by single precision. You can use -CF64 to force floating point constants to have at least 64 bits precision. Or you can use

Re: [fpc-pascal] Problem with code aligning (probably)

On 20/10/2022 16:46, Vojtěch Čihák via fpc-pascal wrote: Thanks, although it's not very optimistic. Is there anything else I can try except {$CODEALIGN ...}? For example change heap or stack size but I don't know what values should I try since I never needed it. Changing the heap or stack

Re: [fpc-pascal] Problem with code aligning (probably)

On 20/10/2022 00:24, Vojtěch Čihák via fpc-pascal wrote: Hi again, I moved directives from {$CODEALIGN JUMP=2} to -OaJUMP=2 in Project Options but I still did not found solution. I observed that when code is - after some change - slower, I can solve it by changing -OaJUMP=2 to -OaJUMP=1.

Re: [fpc-pascal] iOS

On 06/10/2022 21:50, Jonas Maebe via fpc-pascal wrote: On 06/10/2022 14:12, Adriaan van Os via fpc-pascal wrote: Also, the cross compilers for iOS don't seem to be available at <https://www.freepascal.org/download.html> on any of the listed mirrors. I indeed somehow forgot to

Re: [fpc-pascal] iOS

On 06/10/2022 14:12, Adriaan van Os via fpc-pascal wrote: Also, the cross compilers for iOS don't seem to be available at on any of the listed mirrors. I indeed somehow forgot to upload that installer. I've uploaded it now to Sourceforge and to

Re: [fpc-pascal] Access Violation When SetLength(DynArray, Value)

On 2022-09-08 09:30, Anthony Walter via fpc-pascal wrote: Is there a known edge case issue connected to setting the length of dynamic arrays? No, and the location where you're getting the crash suggests an issue in your program that has corrupted the heap manager state. Jonas

Re: [fpc-pascal] Arguments gets corrupted with anonymous nested function

On 2022-09-07 17:09, Benito van der Zander via fpc-pascal wrote: Hi, https://gitlab.com/freepascal.org/fpc/source/-/issues/38703 I'm afraid that with -O4 it is by design. -O4 enables -OoUNCERTAIN, and the documentation about -OoUNCERTAIN notes that: "If uncertain optimizations are

Re: [fpc-pascal] Cross-compiler for ARM64 on Windows available?

On 21/06/2022 20:15, Dennis Lee Bieber via fpc-pascal wrote: On Tue, 21 Jun 2022 18:08:31 +0200, Tomas Hajny via fpc-pascal declaimed the following: but not usable together with the included ppca64.exe binary (because the included ppca64.exe binary is a native compiler for aarch64-win64,

Re: [fpc-pascal] Are there any drawbacks to "reference to"?

On 2022-06-05 18:20, Anthony Walter via fpc-pascal wrote: As the "reference to" feature was recently added to fpc trunk, I'd like to ask if internally there are any penalties (performance perhaps) or drawbacks to using them in place of the more traditional "procedure" and "procedure of

Re: [fpc-pascal] alloca

On 14/05/2022 17:31, Marco van de Voort via fpc-pascal wrote: Also when an exception happens, the stack pointer is not as expected in exception frames (don't know if that really is an issue, but I can image).  It would be interesting how C handles this (e.g. exceptions while alloca called in a

Re: [fpc-pascal] alloca

On 14/05/2022 16:37, Hairy Pixels via fpc-pascal wrote: On May 14, 2022, at 4:04 PM, Jonas Maebe via fpc-pascal wrote: No, because most modern OSes don't allow you to address memory below the stack pointer (and for the ones that do to a limited extent, the compiler could be using

Re: [fpc-pascal] alloca

On 2022-05-14 10:52, Hairy Pixels via fpc-pascal wrote: On May 14, 2022, at 1:01 PM, Jonas Maebe via fpc-pascal wrote: It *requires* compiler support for... The RTL has get_frame but that just tells you the start of the frame right? If you had the stack pointer address you could advance

Re: [fpc-pascal] alloca

On 14/05/2022 07:45, Jonas Maebe via fpc-pascal wrote: On 14/05/2022 03:34, Hairy Pixels via fpc-pascal wrote: On May 13, 2022, at 11:08 PM, Michael Van Canneyt via fpc-pascal  wrote: Is there an “alloca" like function in the RTL which allocates memory from the stack? For example

Re: [fpc-pascal] alloca

On 14/05/2022 03:34, Hairy Pixels via fpc-pascal wrote: On May 13, 2022, at 11:08 PM, Michael Van Canneyt via fpc-pascal wrote: Is there an “alloca" like function in the RTL which allocates memory from the stack? For examplehttps://man7.org/linux/man-pages/man3/alloca.3.html No such

Re: [fpc-pascal] What's wrong with Leave?

On 24/04/2022 15:30, Виктор Матузенко via fpc-pascal wrote: The test program: begin {$IF Declared(Leave)} Leave; {$ENDIF} end. "Leave" is declared as an intrinsic in the system unit because in MacPas mode it means the same as "break" in UCSD-derivates. We don't have support in the

Re: [fpc-pascal] Just out of curiosity: Compiling FPC trunk and fpcmake

On 21/03/2022 22:17, Victor Campillo via fpc-pascal wrote: make: -iVSPTPSOTO: Command not found Makefile:235: *** The Makefile doesn't support target -, please run fpcmake first.  Stop. I just run fpcmake before call "make clean all" and "make -j 9 all install", and everything works as

Re: [fpc-pascal] Just out of curiosity: Compiling FPC trunk and fpcmake

On 21/03/2022 22:17, Victor Campillo via fpc-pascal wrote: For years I have been using the same script to compile FPC, I have multiple version of FPC installed in the same machine, mainly my script do: make -j 9 clean all This is wrong. You cannot safely run "clean" and "all" in parallel.

Re: [fpc-pascal] bug or feature?

On 12/02/2022 17:47, Michael Van Canneyt via fpc-pascal wrote: On Sat, 12 Feb 2022, Jonas Maebe via fpc-pascal wrote: On 12/02/2022 17:36, Michael Van Canneyt via fpc-pascal wrote: PS. Just tested, the compiler accepts both... Amazing, I never thought this would be possible. I'd better

Re: [fpc-pascal] bug or feature?

On 12/02/2022 17:36, Michael Van Canneyt via fpc-pascal wrote: PS. Just tested, the compiler accepts both... Amazing, I never thought this would be possible. I'd better update the docs :-) I wouldn't consider this to be working by design, but rather because of implementation limitations.

Re: [fpc-pascal] $PASCALMAINNAME error with SDL/IPhone

On 31/01/2022 03:49, Ryan Joseph via fpc-pascal wrote: I thought I had this working some years ago but I'm confused again. :) When trying to use SDL on iPhone I include:  {$PASCALMAINNAME SDL_main} But when I compile I get a linker error: Undefined symbols for architecture x86_64:  

Re: [fpc-pascal] Link on another host - how to collect and copy all files?

On 13/12/2021 18:02, Joost van der Sluis via fpc-pascal wrote: I've got into troubles with a dynamic library on Linux. It uses pthreads but on the target system glibc 2.24 is used, while on my development machine 2.34 is being used. I've tried to copy the libc-libraries from the target system

Re: [fpc-pascal] Getting Last User Input reliably

On 05/12/2021 17:10, James Richters via fpc-pascal wrote: I did some tests and went to go turn on Overflow checking just to see what would happen... and noticed it was on already... but I noticed it's called "Integer Overflow Checking" which seems it would not apply to things specifically set

Re: [fpc-pascal] Named optional arguments

On 28/11/2021 10:18, Mattias Gaertner via fpc-pascal wrote: On 26.11.21 04:10, Ryan Joseph via fpc-pascal wrote: [...]The majority of the infrastructure is already there so it needs to merely be extended. What do you mean? Is there already some call by arg names in some mode(switch)? No,

Re: [fpc-pascal] Named optional arguments

On 27/11/2021 03:32, Ryan Joseph via fpc-pascal wrote: 1) Original form (the compiler doesn't use spaces between punctuation). Very difficult to read if nothing else because the lack of spaces but it's also not clear at all which params are which. Even code tools are going to not help very

Re: [fpc-pascal] Make clean error when building fpc 3.2.2 from sources

On 22/11/2021 16:02, Bo Berglund via fpc-pascal wrote: This is what happens when I execute the first make command inside the fpc source dir: ~/devel/fpc/3.2.2$ make clean make: -iVSPTPSOTO: Command not found /usr/bin/rm -f build-stamp.* /usr/bin/rm -f base.build-stamp.* I have

Re: [fpc-pascal] Inline function parameters

On 07/11/2021 05:26, Ryan Joseph via fpc-pascal wrote: Is there anyway a function parameter could be inlined in FPC? This would go a long way in helping to parameterize functions that have tight loops in them. It's theoretically possible through constant propagation. If there isn't I wonder

Re: [fpc-pascal] Trying to update to: Xcode 12.5, FPC 3.2.2

On 21/09/2021 06:59, Ng Pheng Siong via fpc-pascal wrote: /Users/ngps/src/fpc_source/compiler/ppcrossx64 -Tiphonesim -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu/Users/ngps/src/fpc_source/rtl/units/x86_64-iphonesim -Fix86_64 -FEx86_64/bin/x86_64-iphonesim -FUx86_64/units/x86_64-iphonesim -dRELEASE

Re: [fpc-pascal] String error on Windows

On 31/10/2021 05:35, Ryan Joseph via fpc-pascal wrote: I thought they were behind a mode switch called "c operators" or something but either way I don't see why Windows would disable them. The compiler itself does enable them by the default on any platform. However, the fpc.cfg file that

Re: [fpc-pascal] FPC 3.2.2 Build Error on Mac

On 18/10/2021 01:51, lazarus--- via fpc-pascal wrote: [You might want to post Mac issues in the MacPascal list in future] This list is fine too. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] Conversion from C to Pascal - Left bit shift

On 03/09/2021 08:02, LacaK via fpc-pascal wrote: >> I have code in C like this: >>   E1 << E2 >> If E1 is of unsigned type then "The value of E1 << E2 is E1 >> left-shifted E2 bit positions; vacated bits are zero-filled. If E1 has >> an unsigned type, the value of the result is E1 × 2^E2, reduced

Re: [fpc-pascal] Better way to handle callback types

On 21/08/2021 20:06, Ryan Joseph via fpc-pascal wrote: > type > generic TSList = class > type > TComparator = record > private type > TFuncProc = function (constref left, right: T; context: pointer): > integer; > TFuncNested = function (constref left, right:

Re: [fpc-pascal] How does FPC perform in the FASTEST Computer Language Race

On 10/07/2021 18:46, Ryan Joseph via fpc-pascal wrote: > Here's the C++ version that won. Looks like the magic comes from constexpr, > which I don't understand very well in C++ except that it's a constant > expression. Can anyone explain how constexpr works here? A constexpr function means that

Re: [fpc-pascal] How does FPC perform in the FASTEST Computer Language Race

On 10/07/2021 00:56, Ryan Joseph via fpc-pascal wrote: > > >> On Jul 9, 2021, at 11:40 AM, Wayne Sherman via fpc-pascal >> wrote: >> >> Current standings at the time of this video >> Iterations per sec: >> Ada: 67 >> Pascal: 143 >> Fastest language: 7301 >> Slowest language: 1 > > So Pascal

Re: [fpc-pascal] Trying to update to: Xcode 12.5, FPC 3.2.2

On 09/06/2021 01:15, conlin664 via fpc-pascal wrote: > So, I figured I'd jump to 3.2.2 Sorry, I didn't get around yet to building and uploading the iOS cross-compiler and units for 3.2.2 As your build problem, don't start with that 3.0.5 compiler, but with plain 3.0.4 or 3.2.2 ppcx64 (or add

Re: [fpc-pascal] -FNsystem

On 27/05/2021 14:28, Michael Van Canneyt via fpc-pascal wrote: > With recent changes by Jonas in fpmake, this can now be created with > more ease. FWIW, I've barely started on the latest proposal for the fpmkunit changes. Jonas ___ fpc-pascal maillist

Re: [fpc-pascal] non-virtual class methods called from virtual regular method

On 29/04/2021 13:04, LacaK via fpc-pascal wrote: > In regular virtual method, I expect, that Self resolves to runtime class > type, thust calling CP1 should resolve to runtime type class method. It works the same for class methods and non-class methods: no virtual = no dynamic resolution when

Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal

On 19/04/2021 11:28, Michael Van Canneyt via fpc-pascal wrote: > > > On Mon, 19 Apr 2021, Jonas Maebe via fpc-pascal wrote: > >> On 19/04/2021 09:28, Michael Van Canneyt via fpc-pascal wrote: >>> >>> >>> From what you say, both problems are relate

Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal

On 19/04/2021 09:28, Michael Van Canneyt via fpc-pascal wrote: > > > From what you say, both problems are related to the tool you use. Are > there no other tools that can be used ? The wrapping problem is unrelated to the tool, but to the console mode focus of our installation files. Such a

Re: [fpc-pascal] Separate release cycle for RTL and compiler proposal

On 19/04/2021 07:59, Michael Van Canneyt via fpc-pascal wrote: > > But MacOS is a problem. macOS is also perfectly scriptable, I just have to finish automating it. The main remaining problem is our hard-wrapped readme and whatsnew files that look terrible in its installer (because it also

Re: [fpc-pascal] Abstract classes ignored

On 18/04/2021 18:08, Jonas Maebe via fpc-pascal wrote: > In this case, you > can easily make it an error yourself with {$warn 4046 error}. Correction: that's make it an error to construct a classes that contain abstract methods. For abstract classes, it's {$warn 4122 error}

Re: [fpc-pascal] Abstract classes ignored

On 18/04/2021 17:55, Graeme Geldenhuys via fpc-pascal wrote: > On 17/04/2021 10:09 pm, Sven Barth via fpc-pascal wrote: >> but Delphi compatbility is more >> important here, thus the default is a warning and not an error. > > How is this beneficial? The compiler should help the developer,

Re: [fpc-pascal] Version 3.2.2 changes

On 09/04/2021 10:42, Florian Klämpfl via fpc-pascal wrote: > > >> Am 08.04.2021 um 21:27 schrieb Jonas Maebe via fpc-pascal >> : >> >> On 08/04/2021 21:07, Peter via fpc-pascal wrote: >>> Does anyone have a link to useful list of changes or b

Re: [fpc-pascal] Version 3.2.2 changes

On 08/04/2021 21:07, Peter via fpc-pascal wrote: > Does anyone have a link to useful list of changes or bug fixes for 3.2.2? Unfortunately, no. In theory you could see it on https://bugs.freepascal.org/changelog_page.php (for the 3.2.1 version), but the "fix version" of most bug reports does not

Re: [fpc-pascal] Minimal size of compiled library (DLL under Windows)

On 2021-04-06 12:22, LacaK via fpc-pascal wrote: May be, that important word is here "referenced" code. Once some code (procedure, class) is referenced then this code is linked / included. It does not play role if it is really required by program / library ... right? It is impossible for a

Re: [fpc-pascal] Minimal size of compiled library (DLL under Windows)

On 06/04/2021 09:33, LacaK via fpc-pascal wrote: > So we see that classes like TComponent and also interfaces are touched, > but they are used only in conjuction with initilizing some global > variables like InitHandlerList, GlobalNameSpace. > > But these variables are never used in my library.

Re: [fpc-pascal] Pascal Ardiono (avr) library

On 04/04/2021 12:50, Joost van der Sluis via fpc-pascal wrote: > One thing is constant-propagation in combination with auto-inlining. It > would be really nice when calling PinMode with two constant parameters, > would only lead to setting the constant value at two memory locations. > (Between

Re: [fpc-pascal] FPC PasCocoa/Differences

On 27/03/2021 19:11, Adriaan van Os via fpc-pascal wrote: > "The only way to add a traditional property—backed by a new instance > variable—to an existing class is to use a class extension, as described > in Class Extensions Extend the Internal Implementation." > > So, the FPC

Re: [fpc-pascal] Smart-linking versus Whole Program Optimization

On 10/03/2021 14:51, Michael Van Canneyt via fpc-pascal wrote: > On Wed, 10 Mar 2021, Jonas Maebe via fpc-pascal wrote: > >> On 10/03/2021 14:33, LacaK via fpc-pascal wrote: >>> It will be nice have this in documentation. For example in >>> https://www.freepascal.or

Re: [fpc-pascal] Smart-linking versus Whole Program Optimization

On 10/03/2021 14:33, LacaK via fpc-pascal wrote: > It will be nice have this in documentation. For example in > https://www.freepascal.org/docs-html/prog/progse30.html#x195-207.3 > > At least explain: > - relation of -CX and -XX Indeed. > - what is to be removed: non-referenced non-virtual

Re: [fpc-pascal] Smart-linking versus Whole Program Optimization

On 10/03/2021 13:17, Yuriy Sydorov via fpc-pascal wrote: > On 10.03.2021 11:34, LacaK via fpc-pascal wrote: >> >> A.) I compile my (units) program/library with -CX -XX (set in Project >> Options) >> > > Just a small note: > > -CX -XX are not needed for the top-tier targets nowadays. The section

Re: [fpc-pascal] Smart-linking versus Whole Program Optimization

On 10/03/2021 10:34, LacaK via fpc-pascal wrote: > 1. I did not notice difference between A and B (it seems like WPO did > not reduce size of EXE (may be that I do something wrong)) > 1.1 is there way how I can check which procedures were striped out or > vice-versa included? You can generate

Re: [fpc-pascal] Unicode chars losing information

On 08/03/2021 19:16, Ryan Joseph via fpc-pascal wrote: > I agree it would be nice to have some warning that indexing the unicodeString > wouldn't work as expected. Then the compiler would have to give a warning for any indexing of unicodestring. That would render it useless, because everyone

Re: [fpc-pascal] Statically linked-in fpc code

On 05/02/2021 10:50, Adriaan van Os via fpc-pascal wrote: > Also > > 1. Section 1.3.31 of the Programmer's manual says "By default, no stack > checking is performed." That is correct. > 2. If it is broken with gpc-3.2.0, such the more reason to put it off. > It doesn't do real stack-checking

Re: [fpc-pascal] Statically linked-in fpc code

On 2021-02-05 09:24, Adriaan van Os via fpc-pascal wrote: It's crazy ! The default fpc.cfg file contains this (both in 3.0.4 and 3.2.0): # For a debug version compile with debuginfo and all codegeneration checks on #IFDEF DEBUG -gl -Crtoi

Re: [fpc-pascal] Statically linked-in fpc code

On 04/02/2021 21:26, Adriaan van Os via fpc-pascal wrote: > I am getting crashes on Mac OS X 10.8.5 in a C-program with statically > linked-in fpc code. The crashes seem related to fpc unit initialisation. > This happens with fpc-3.2.0 but not when compiling the same code with > fpc-3.0.4. Has

Re: [fpc-pascal] CP_NONE string disappearing

On 27/12/2020 18:36, Benito van der Zander via fpc-pascal wrote: > this code: > > program Project1; > {$mode objfpc}{$H+} > var a,b, c: string; > begin >   a := 'x'; >   b := 'y'; >   SetCodePage(RawByteString(b), CP_NONE, false); >   c := a+b; >   writeln(c); > end. > > prints x without y on

Re: [fpc-pascal] heaptrc unit troubles with New() & Dispose() calls

On 13/12/2020 22:50, Graeme Geldenhuys via fpc-pascal wrote: > Are there any known issues with heaptrc unit via compiler parameters > -gl -gh, when using New() and Dispose() to manually allocate and free > memory. No. New and Dispose eventually result in calls to plain getmem/freemem anyway.

Re: [fpc-pascal] callback from c with varargs

On 20/12/2020 14:43, Tomas Hajny via fpc-pascal wrote: > On 2020-12-20 14:00, Jonas Maebe via fpc-pascal wrote: >> On 20/12/2020 13:01, Luca Olivetti via fpc-pascal wrote: >>> El 19/12/20 a les 23:15, Jonas Maebe via fpc-pascal ha escrit: >>>> It is indeed not po

Re: [fpc-pascal] callback from c with varargs

On 20/12/2020 13:01, Luca Olivetti via fpc-pascal wrote: > El 19/12/20 a les 23:15, Jonas Maebe via fpc-pascal ha escrit: >> It is indeed not possible to implement a function with C varargs in FPC. > > I was afraid that's the answer :-( > > as an ugly workaround

Re: [fpc-pascal] callback from c with varargs

On 19/12/2020 22:35, Luca Olivetti via fpc-pascal wrote: > I'm trying to use a c library where I can define a logging plugin. > > The c prototype for the callback is > >     void (*log)(void *logContext, UA_LogLevel level, UA_LogCategory > category, const char *msg, va_list args); > > >

Re: [fpc-pascal] Compilation speed on Apple M1

On 27/11/2020 01:46, Ryan Joseph via fpc-pascal wrote: >> On Nov 22, 2020, at 4:08 AM, Florian Klämpfl via fpc-pascal >> wrote: >> >>> Well... If the compiler can make such a difference, >> This are the big low hanging fruits, their are only a few :) In particular >> the compiler benefits a lot

Re: [fpc-pascal] Compilation speed on Apple M1

On 21/11/2020 17:22, Ryan Joseph via fpc-pascal wrote: > It sounds like the LLVM backend is superior so is it the plan to start > distributing compiler releases built from LLVM? Not in the near future. > What are the plans for the native code generator if it's being outperformed > by the LLVM

Re: [fpc-pascal] Compilation speed on Apple M1

On 21/11/2020 14:15, Florian Klämpfl via fpc-pascal wrote: > Am 21.11.2020 um 12:54 schrieb Tobias Giesen via fpc-pascal: >> >> According to Geekbench, the single core performance on the new Mac is >> around 1.8x as fast as my Intel Mac. Multicore is also much faster. I >> wonder why I don't see

Re: [fpc-pascal] Compilation speed on Apple M1

On 21/11/2020 15:52, Marco van de Voort via fpc-pascal wrote: > Do the x86(_64) OSX(I) FPC compilers use binary object writers? No. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] Compilation speed on Apple M1

On 21/11/2020 12:54, Tobias Giesen via fpc-pascal wrote: > According to Geekbench, the single core performance on the new Mac is > around 1.8x as fast as my Intel Mac. Geekbench scores cannot be compared across different architectures. > I wonder why I don't see the speed increase in compiling

Re: [fpc-pascal] link.res search dirs when cross compiling

On 18/11/2020 19:21, Benito van der Zander via fpc-pascal wrote: > where do the SEARCH_DIRs in link.res come from? > > My build has started failing, after trying it on a new computer with > "/home/benito/bin/arm-linux-androideabi-ld.bfd:android/libs/armeabi/link42815.res:17: > ignoring invalid

Re: [fpc-pascal] Enum range check error

On 21/10/2020 22:46, Ryan Joseph via fpc-pascal wrote: >> On Oct 21, 2020, at 2:43 PM, Jonas Maebe via fpc-pascal >> wrote: >> >> I tried to explain in the rest of my message why that cannot be done. It >> might be possible in some cases, but that would just creat

Re: [fpc-pascal] Enum range check error

On 21/10/2020 22:34, Ryan Joseph via fpc-pascal wrote: > > >> On Oct 21, 2020, at 2:08 PM, Jonas Maebe via fpc-pascal >> wrote: >> >> See https://bugs.freepascal.org/view.php?id=34972 for some comments >> about Default. So this is a bug in the usage

Re: [fpc-pascal] Enum range check error

On 21/10/2020 21:59, Ryan Joseph via fpc-pascal wrote: > Is this a bug in generics with default()? > > = > > type > TEnum = (Unused = '.'); > generic TSomething = class > function Get: T; > end; > TEnumeratedSomething = specialize TSomething; > > function

Re: [fpc-pascal] FPC for FreeBSD/PowerPC64

On 13/09/2020 10:36, Karoly Balogh (Charlie/SGR) via fpc-pascal wrote: > See systems/t_linux.pas for an example, and do something similar in the > PPC64 FreeBSD port. You should also set the ABI in systems/i_bsd.pas already. The code in t_linux is because of the support for both big and little

Re: [fpc-pascal] String literals and code page of .pas source file

On 12/09/2020 18:44, Sven Barth via fpc-pascal wrote: > Jonas Maebe via fpc-pascal <mailto:fpc-pascal@lists.freepascal.org>> schrieb am Sa., 12. Sep. 2020, > 17:47: > > > All the doubts, questions, and discussions prove that current > system is > >

Re: [fpc-pascal] String literals and code page of .pas source file

On 12/09/2020 16:58, Santiago A. via fpc-pascal wrote: > https://wiki.freepascal.org/Unicode_Support_in_Lazarus#Assign_string_literals_to_different_string_types > is scaring. The first table is useless. If you don't tell the compiler what the code page is of the source file, it's normal that you

  1   2   >