Re: [fpc-pascal] Floating point question

[Jonas Maebe via fpc-pascal]

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 + 33.0 / 1440.0; // treat all constants all "single"
 d := 8427.0 + 33.0 / 1440.0; // treat all constants all "double"
 e := 8427.0 + 33.0 / 1440.0; // treat all constants all "extended"
end.


You cannot do this in Pascal. The evaluation of the expression on the 
right of := does not

know (and should not know) what the type is of the expression on the left.


It's even theoretically impossible to do in case the result is passed to 
a function or intrinsic that is overloaded with single/double/extended 
parameters.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Floating point question

[Jonas Maebe via fpc-pascal]

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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Floating point question

[Jonas Maebe via fpc-pascal]

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 good way to get the maximum supported floating 
point precision by the target platform.


However, adding support for an option called -CFMax or similar should be 
no problem.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Floating point question

[Jonas Maebe via fpc-pascal]

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 represented exactly as a single precision 
floating point number. Nor as a double or extended precision floating 
point number for that matter, and in that case the compiler uses the 
maximum precision is supported by the target platform.




Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Floating point question

[Jonas Maebe via fpc-pascal]

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 release notes for that compiler version (aka the "user 
changes" wiki doc).



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Floating point question

[Jonas Maebe via fpc-pascal]

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  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Floating point question

[Jonas Maebe via fpc-pascal]

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 
be done in extended by the compiler, or the answer is just wrong.


See 
https://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants and https://www.freepascal.org/daily/doc/prog/progsu19.html


I think this discussion shows that the 2.2 compiler change was a bad 
idea (for modes other than Delphi).


This is not just about Delphi. It's also about being able to perform 
floating point calculations efficiently and getting rid of useless warnings.



Jonas



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Floating point question

[Jonas Maebe via fpc-pascal]

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 
https://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants 
and https://www.freepascal.org/daily/doc/prog/progsu19.html



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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! Progress?


You forgot the 1MB Mac ROM :)

That's also the main difference between C and FPC: C programs by default 
are dynamically linked, so all of the standard RTL functionality that 
gets linked into an FPC program is not there in a C program most of the 
time.


It's also why golang programs are larger: those are statically linked as 
well.



Jonas

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 is documented here: 
https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#varargs



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 processors the expanded sequence is much faster than the 
single enter instruction
2) enter is limited to allocating stack frames of 32kb or 64kb (so we 
had to support non-enter-based entry code anyway)
3) IIRC the Linux kernel doesn't support the enter instruction (if it 
requires a new page to be allocated for the stack, I believe it can 
crash the program)


TP did use it.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Quick question

[Jonas Maebe via fpc-pascal]

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 using vectors of 4 elements,

would that  effect the code the compiler generates to give wrong results?


Since FPC enables floating point exceptions, it would probably at least 
generate spurious exceptions (trying to divide 0.0 by 0.0 and things 
like that).


FPC does support the -Sv command line option that enables using arrays 
as vectors (if they fit in a vector register for the current target 
architecture; there's no automatic splitting of large arrays into a 
sequence of smaller vector operations afaik). It's not very well tested 
though.



Jonas

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] LLVM LTO

[Jonas Maebe via fpc-pascal]

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 RTL 
is not compiled with LTO.



Then I could run my unit tests:

FPC alone: 25 seconds
LLVM: 21 seconds
LLVM LTO: 20 seconds

does not seem to matter much


It depends on the program.


Jonas

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Barriers semantics

[Jonas Maebe via fpc-pascal]

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
https://www.sobyte.net/post/2022-08/cpu-cache-and-memory-barriers/ . In
practice, I don't think any currently used cpu architectures still
require such barriers though.


Ok. I assume I got it right.
This field lacks common terms for some reason.


Again: Read, Write, ReadWrite and ReadDependency barrier _are_ common 
terms. However, they're computer architecture terms. When using these 
barrier functions, you should be familiar with memory models and memory 
ordering. Use higher level primitives if you want to reason using higher 
level concepts like acquire/release.



Jonas

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Barriers semantics

[Jonas Maebe via fpc-pascal]

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 cases, 
and when it's not in the best case it's usually just highly inefficient. 
volatile in FPC/C++ is unrelated to volatile in Java or C# in that respect.



Documentation states we have following barriers - ReadBarrier, WriteBarrier, 
ReadDependencyBarrier, ReadWriteBarrier.

I'd like to get an idea how those related to more common / standard terms - 
Acquire/Release & their combinations?


Read/Write barriers are terms used in cpu architecture manuals. 
Acquire/Release are high level parallel programming terms.



Is it safe to assume that:

ReadBarrier - Acquire
WriteBarrier - Release
ReadWriteBarrier - Acquire+Release
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 
https://www.sobyte.net/post/2022-08/cpu-cache-and-memory-barriers/ . In 
practice, I don't think any currently used cpu architectures still 
require such barriers though.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Volatile store usage

[Jonas Maebe via fpc-pascal]

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
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] LLVM crash

[Jonas Maebe via fpc-pascal]

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 SYSTEM_$$_SYSGETMEM_FIXED$QWORD$$POINTER()
#1 0x0041b92ain fpc_ansistr_setlength()
#2 0x00558d52in RESETBUFFER(ABUFFER=0x7fffd560, 
BASECAPACITY=130) at bbutils.pas:1650
#3 INIT(ABUFFER=0x7fffd560, BASECAPACITY=130, AENCODING=65001) at 
bbutils.pas:1639
#4 STRDECODEHTMLENTITIES(result=0x0, P=, L=130, 
ENCODING=65001, FLAGS=...) at bbutils.pas:5527


anyone has seen sysgetmem crash before?


It suggests heap corruption.


Perhaps that is exactly the kind of things ASAN was supposed to detect.


Possibly, yes.

But with ASAN, I get an error somewhere entirely else. And I do not 
understand it, because the function is shown as ~ 5000 lines of assembly.


How can I see the mixed code with disassemble /rm in gdb? I tried to 
call fpc -gl, -gs and -gw, and nothing helps


On which platform? When I compile the attached tt.pp file with -gw4 
-Clfsanitize=address (LLVM 13, Debian 11, x86-64) and then run it, I get 
the output in tt.txt. It includes line information.


You could try lldb instead of gdb, although gdb should also be able to 
handle debug information generated by LLVM.



And there are a lot of weird ASAN calls for trivial movs. Like:

0x006f577c<+22204>: 48 8b bb c8 00 00 00 movrdi,QWORDPTR[rbx+0xc8]
0x006f5783<+22211>: e8 18 cc d0 ff 
call0x4023a0<__asan_report_load8@plt>
0x006f5788<+22216>: e8 13 cc d0 ff 
call0x4023a0<__asan_report_load8@plt>
0x006f578d<+1>: e8 0e cc d0 ff 
call0x4023a0<__asan_report_load8@plt>
0x006f5792<+6>: e8 09 cc d0 ff 
call0x4023a0<__asan_report_load8@plt>

0x006f5797<+22231>: 48 89 c7 movrdi,rax
0x006f579a<+22234>: e8 01 cc d0 ff 
call0x4023a0<__asan_report_load8@plt>

0x006f579f<+22239>: 48 89 cf movrdi,rcx
0x006f57a2<+22242>: e8 09 ca d0 ff 
call0x4021b0<__asan_report_store8@plt>


Are they supposed to be there?


These are generated by LLVM's own code generator, so yes.


Jonas
uses
  unit1;

var
  p: pbyte;
begin
  getmem(p,1);
  p[2]:=0;
end.
=
==12076==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x60300022 at pc 0x00401383 bp 0x7ffd4259e170 sp 0x7ffd4259e168
WRITE of size 1 at 0x60300022 thread T0
#0 0x401382 in PASCALMAIN /home/jmaebe/fpcgit/test/tt.pp:8:3
#1 0x4012a9 in SI_C_$$_MAIN_STUB (/home/jmaebe/fpcgit/test/tt+0x4012a9)
#2 0x7fcfa3dd3d09 in __libc_start_main csu/../csu/libc-start.c:308:16

0x60300022 is located 1 bytes to the right of 17-byte region 
[0x60300010,0x60300021)
allocated by thread T0 here:
#0 0x7fcfa407f5dd in __interceptor_malloc 
(/usr/lib/llvm-13/lib/clang/13.0.1/lib/linux/libclang_rt.asan-x86_64.so+0xca5dd)
#1 0x430b6c in CMEM_$$_CGETMEM$QWORD$$POINTER 
(/home/jmaebe/fpcgit/test/tt+0x430b6c)

SUMMARY: AddressSanitizer: heap-buffer-overflow 
/home/jmaebe/fpcgit/test/tt.pp:8:3 in PASCALMAIN
Shadow bytes around the buggy address:
  0x0c067fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c067fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c067fff8000: fa fa 00 00[01]fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==12076==ABORTING
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] LLVM LTO

[Jonas Maebe via fpc-pascal]

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 -k-fuse-ld=gold -k-plugin=/path/to/LLVMgold.so


Note that compiling the FPC RTL with LTO currently doesn't work under 
Linux, because LLVM does not rename local labels in pure assembler 
procedures when doing so, resulting in duplicate labels.


It works fine when compiling FPC and its units normally, and then only 
using LTO for your program.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 frame itself is relatively slow.


Ok so just to confirm does disabling   $IMPLICITEXCEPTIONS leak memory with ref 
counted types if a function exists early?


No, local variables are still finalised on exiting the function. Only 
when an exception happens, the the exit code that contains this 
finalisation won't execute



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 
functions on managed types right?


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 frame itself is relatively slow.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 the source type.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC ARM inline Assembler

[Jonas Maebe via fpc-pascal]

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;


ARM is a load/store architecture, which means it only supports 
operations on values loaded in registers. Local variables are always 
allocated on the stack in procedures/functions with inline assembler 
blocks, so you need to use the "str" instruction to store w4 into MsBit. 
"mov" only works for register-register transfers on ARM.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 (*), since when the program terminates 
all memory gets released to the OS anyway. And before that, the memory 
would never be released, even if that bug got fixed.



Jonas

(*) unless you are using heaptrc to hunt for other, non-benign memory 
leaks, since then it will be a bit harder to identify those.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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?


Records always get padded to a multiple of their internal alignment 
requirement. Unless you're on a system where the default packrecords 
value is 2 (msdos-i8086 has that probably), the above record's internal 
field alignment is 4 and hence its size will also be padded to a 
multiple of 4.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 when declaring variables of 
those types.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 there any way to do this at fpc when the record is
declared?


{$push}
{$codealign varmin=16}
{$codealign constmin=16}
const
  constdata: array[0..3] of longint = (1,2,3,4);

var
  x: array[0..15] of longint;
{$pop}

However, the maximum alignment you can specify this way is limited per 
target (hardcoded in the compiler). In 3.2.x, it's 16 bytes for most 
desktop targets. On 3.3.x, it's 64 bytes for most desktop targets.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Building compiler which stalls

[Jonas Maebe via fpc-pascal]

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 there is a native 
ppca64 in the latest FPC release (3.2.2). So you can start directly with 
your step 3 (removing the "FPC=$PWD/ppca64" so it uses the globally 
installed ppca64). If you do that, it works.


I can reproduce the issue when following your steps. My best guess is 
that one of the new x86 optimisations is breaking things when 
cross-compiling the native AArch64 compiler.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Building compiler which stalls

[Jonas Maebe via fpc-pascal]

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 run 
the compiler at compiler/ppca64 and it just stalls out, spinning the CPU at 100% in 
an infinite loop and never prints the normal FPC header.


You can add "-Xs- -gw -Xg" to OPT to prevent symbol stripping and add 
debug info, and then when it's stuck either attach a debugger or run 
"sample ppcx64"



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 {$excessprecision on} to force the 
compiler to evaluate all floating point expressions always using the 
maximum precision supported by the FPU.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 size will have no effect. Changing the order 
of your procedures could help, and adding dummy code in between as well.


BTW, is there chance that these problems will go away with newer 
hardware, like some AM5? New CPUs have at least bigger caches


The problems will probably at best move to different spots in your code, 
unless someone figures out how to make fully associative caches that 
don't require insane power budgets.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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.


And after next change - if it causes slower code - I can solve it 
reversely: -OaJUMP=1 to -OaJUMP=2.


Of course, I'd like some persistent solution.


That's not easy, unfortunately: https://www.youtube.com/watch?v=r-TLSBdHe1A


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] iOS

[Jonas Maebe via fpc-pascal]

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 upload that installer. I've uploaded it now 
to Sourceforge and to the main FPC download mirror.


Never mind, I deleted them again. They contained FPC 3.2.0 installers, 
not 3.2.2 ones. I remember again that FPC 3.2.2 didn't build for iOS, 
and somehow I had accidentally packaged the 3.2.0 files in the 3.2.2 
installers. The building has been fixed on main IIRC, but I don't know 
if all necessary changes were merged back to the fixes branch.


Unless you need FPC 3.2.2-specific fixes, you can probably just use FPC 
3.2.0 instead for iOS.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] iOS

[Jonas Maebe via fpc-pascal]

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 the main FPC download mirror.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 enabled, the CSE algorithm assumes 
that
-- If something is written to a local/global register or a 
procedure/function parameter, this value doesn't overwrite the value 
to which a pointer points.
-- If something is written to memory pointed to by a pointer variable, 
this value doesn't overwrite the value of a local/global variable or a 
procedure/function parameter."


is it doing that? did it ever do that?


It did that when the old assembler-level CSE optimiser still existed. 
It's been removed for a long time now.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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,

Is it? With "ppca" I'd think that was Power PC Architecture
(Apple/IBM/Motorola => "AIM")https://en.wikipedia.org/wiki/PowerPC  -- and
is NOT related to ARM architecture.


ppc ~= .pp compiler. All of our compiler binaries start with ppc. The 
PowerPC compiler is ppcppc.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 object" types?


The downside is that a "reference to" always gets wrapped in a 
reference-counted interface, and hence is much more expensive than a 
place procedural variable ("of object" or not).



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] alloca

[Jonas Maebe via fpc-pascal]

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 loop?)


This is handled via dwarf call frame information, which is also 
generated by the compiler. It describes how to restore the stack pointer 
for every instruction address where it changes.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] alloca

[Jonas Maebe via fpc-pascal]

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 that memory already).

I thought the stack had a fixed size of memory that’s in every frame and it’s 
just a matter of if it’s occupied by any local variables or not. Seems 
conceptually simple to advance the pointer as if a local variable was declared 
but maybe this needs to happen at compile time making alloca more of a compiler 
intrinsic.


Only the part between the current address in the stack pointer register 
and the base of the stack when the program started is valid to address 
(barring some minor exceptions). The stack pointer register gets 
adjusted by the compiler any time the stack needs to grow or shrink, 
which indeed generally mostly happens on function entry/exit.



Jonas

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] alloca

[Jonas Maebe via fpc-pascal]

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 that
pointer x bytes and get a new location in the stack?


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 that memory already).



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] alloca

[Jonas Maebe via fpc-pascal]

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 
examplehttps://man7.org/linux/man-pages/man3/alloca.3.html

No such function exists in FPC.
Is alloca something which is part of the OS or can this be implemented 
by programmers or used from other libraries?


It compiler support for the allocation to actually happen on the stack. 
When it's actually implemented in a library (rather than redirect to a 
compiler intrinsic via a C macro), it will generally just allocate on 
the heap instead.


It *requires* compiler support for...


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] alloca

[Jonas Maebe via fpc-pascal]

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 function exists in FPC.

Is alloca something which is part of the OS or can this be implemented by 
programmers or used from other libraries?


It compiler support for the allocation to actually happen on the stack. 
When it's actually implemented in a library (rather than redirect to a 
compiler intrinsic via a C macro), it will generally just allocate on 
the heap instead.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 compiler for declaring intrinsics in units 
other than the system unit (so we can't declare it in the macpas unit 
instead), and we don't have a different system unit for each supported 
syntax mode either (otherwise it would not be possible to mix units 
compiled in different syntax modes in a single program), which is why 
you see this behaviour.



Jonsa
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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


I forgot to reply to this: as Michael mentioned, this does not mean 
fpcmake needs to be run. Even after running fpcmake, the target "-" 
would still not be supported.


The issue is probably that the ppc or fpc binary in the compiler 
subdirectory was in your path, and then got deleted by "make clean" 
while in parallel "make all" tried to use it for compilation.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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. You 
have to run them separately.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] bug or feature?

[Jonas Maebe via fpc-pascal]

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 update the docs :-)


I wouldn't consider this to be working by design, but rather because 
of implementation limitations.


Why do you consider it a limitation ?

Because the compiler currently has no way to distinguish the types when 
resolving the

name "T" (as used in my example)?


Indeed.


Then it is a strange coincidence that Delphi has it too :-)


The simplest way to implement alias types is to just have them refer to 
the original type...



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] bug or feature?

[Jonas Maebe via fpc-pascal]

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.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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:
   "_main", referenced from:
      implicit entry/start for main executable
      (maybe you meant: _SDL_main)

Why is this?


It only works in your main program, not in a unit or so. Maybe that's 
the reason?



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 to my host and uxe -Xr -Xd, but it does not work.


You'd mainly need -XR in that case.

Does someone has a tool of other good trick to copy everything to the 
target machine, and link there?


(I almost started to add a separate option to the compiler to create a 
script do this, but there must be some other way to do this)


There is already an option for this: -st . I don't know how well it 
works though.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 as DWord.
I did some searches and didn't come across any overflow checking that wasn't 
for integers.

Am I missing something?  Or is this not even an issue because there is no 
overflow checking for DWord variables anyway?


See https://gitlab.com/freepascal.org/fpc/source/-/issues/25201 (first 
comment)



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Named optional arguments

[Jonas Maebe via fpc-pascal]

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, it's only there for IDispatch support: 
https://stackoverflow.com/questions/885942/named-optional-parameters-in-delphi



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Named optional arguments

[Jonas Maebe via fpc-pascal]

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 
much unless they can hilight the parameters in the editor.


That's exactly what Lazarus does: place your cursor on any of the 
parameters and press ctrl-shift-space. It will show you the declaration 
with the current parameter in bold.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 checked that build-essentials are installed on this Ubuntu machine.

Where do I go from here?


FPC needs a previous version of FPC to bootstrap. So first install fpc 
using apt-get on the VM.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Inline function parameters

[Jonas Maebe via fpc-pascal]

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 if this is an area where the proposed "pure" function 
modifier could be used to make it possible.


That's completely unrelated.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 -ap 
-XR/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk
 
-ao-isysroot/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk
 -k"-syslibroot 
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk"
-DD2021/09/20 -dx86_64 -dGDB -Fux86 -Fix86 -Sew 
-o/Users/ngps/src/fpc_source/compiler/ppcx64 pp.pas
ld: building for iOS, but linking in object file built for iOS Simulator, file 
'x86_64/units/x86_64-iphonesim/pp.o'
pp.pas(288,36) Error: Error while linking
pp.pas(288,36) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
make[3]: *** [ppcx64] Error 1
make[2]: *** [cycle] Error 2
make[1]: *** [compiler_cycle] Error 2
make: *** [build-stamp.x86_64-iphonesim] Error 2

Here's the error:

   ld: building for iOS, but linking in object file built for iOS Simulator, 
file 'x86_64/units/x86_64-iphonesim/pp.o'


I've finally looked into this and found the error: the compiler has to 
specify -ios_simulator_version_min rather than -iphoneos_version_min to 
the linker when targeting the simulator. This is fixed in latest trunk 
and in the fixes_3_2 branch.


You might be able to also work around it on 3.2.2 by adding 
CROSSOPT="-k-ios_simulator_version_min -9.0" to the make command line, 
and also add those parameters when compiling a program for the iphonesim 
target.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] String error on Windows

[Jonas Maebe via fpc-pascal]

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 gets installed with FPC on all platforms 
does enable them by default (it contains -Sgic). Compile with -vt and 
check where the compiler is getting its configuration file from.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 modulo
>> one more than the maximum value representable in the result type."
>>
>> I understand this as result of such operation does not grow over 32
>> bits, right?
>>
>> In Pascal I have:
>>   E1 shl E2
>> where E1 is of LongWord type.
>>
>> On 64-bit target this result of shl can overcome 32 bits (iow operates
>> on 32 bits)?

If E1 is 32 bits, the result will be 32 bits. From the compiler source code:

{ calculations for ordinals < 32 bit have to be done in
  32 bit for backwards compatibility. That way 'shl 33' is
  the same as 'shl 1'. It's ugly but compatible with delphi/tp/gcc }

Note that the "shl 33' is the same as 'shl 1'" part of the comment
refers to the specific behaviour of the x86 family of processors. That
is not necessarily the case on other systems (e.g. on 32 bit PowerPC,
the result will be 0 as you would normally expect).

> Can we say that in Pascal the result of:
>   E1 shl E2
> is of same type as E1 ?

No. If E1 is smaller than 32 bits, the result will be promoted to
1) on 32/64 bit platforms: 32 bits
2) on 8/16 bit platforms: the smallest integer type that can represent
both E1 and the native integer type of the platform

> What if there is an expression on left side:
>   (E1*x) shl E2
> Will E1*x promote to 64 bits (on 64 bit target)?

Expressions are always evaluated independently of how their result is
used. So, yes.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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: T; context: pointer): 
> integer is nested;

You can pass global functions to "is nested" procvars, so at least these
two don't need to be separate.

OTOH, there's another type: cblocks :)


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 it must be computable at compile time if
all of its arguments are also constexpr.

It's also basically explained at
https://github.com/PlummersSoftwareLLC/Primes/tree/drag-race/PrimeCPP/solution_3
: "Deviation: It does use the base algorithm but due to compile time
optimization, a lot of the actual calculation does not happen at runtime"

and

"Note: this solution is limited to numbers up to around 50,000,000
(stack size limit on Mac OS it seems)." (due to the compile-time evaluation)


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 failed pretty bad it looks like. ;)

If the only thing you do all day is run a particular implementation of
the sieve of Eratosthenes...


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 CPU_SOURCE=x86-64 to hack around the
issue)


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] -FNsystem

[Jonas Maebe via fpc-pascal]

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  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 calling such a method.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 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 manually formatted text file is
>> simply unsuitable for a GUI installer.
> 
> But if the tool didn't wordwrap, all would be OK, no ?

It's not the tool, it doesn't touch the files. It's the GUI of the
installer application, which shows a plain window that happens to be
slightly too narrow relative to our chosen line length (depending on the
kind of characters on the line, as it uses a proportional font).


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 manually formatted text file is
simply unsuitable for a GUI installer.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 performs wrapping
and it uses a proportional font, so many hard-wrapped lines get wrapped
again). So at least the changed/new parts need manual unwrapping every time.

For Mac OS X/PowerPC there is the additional issue that the tool to
create installer packages that work on Mac OS X 10.4 no longer works
under macOS 10.14, so they have to be created on an older Mac OS X
version (I don't know when it broke exactly).


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Abstract classes ignored

[Jonas Maebe via fpc-pascal]

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}


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Abstract classes ignored

[Jonas Maebe via fpc-pascal]

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,

People who want to compile code in both FPC and Delphi are developers
too. People who want to use their knowledge of Delphi to program in FPC
are developers too.

You can never make everyone happy, and sometimes we go for
incompatibility by default, and sometimes we don't. In this case, you
can easily make it an error yourself with {$warn 4046 error}.

> Such decisions really make me worry about the future of FPC. It ends up
> being NO better than Delphi, so why bother using FPC then. Stick to
> Delphi instead.

It's not like this is a new policy that you just discovered, so please
stop already with the flamebait drama about how this makes you worry
about the future of FPC.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Version 3.2.2 changes

[Jonas Maebe via fpc-pascal]

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 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 get updated when
>> fixes are backported. I used to spend days on going through all merges
>> and updating the merge revisions and fix versions when a release was
>> nearing, but I no longer have time for that.
> 
> As this is most likely pretty useful, I am willing to work on it. Anybody 
> else?

I can do it for the ones I merged.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Version 3.2.2 changes

[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 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 get updated when
fixes are backported. I used to spend days on going through all merges
and updating the merge revisions and fix versions when a release was
nearing, but I no longer have time for that.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 linker to know whether code is "really required". 
It doesn't know what code does. It only knows whether or not it 
(theoretically) can get executed.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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. Only again in
> finalization sections of above mentioned units.

They are used in your library as far as the linker is concerned, because
the init and finalisation sections are code like any other code.

> Does it means, that smart-linking can not remove this code due to usage
> of this global variables in finalization section (resp. initialization
> sections)?

Indeed.

> Probably it is too hard task for linker to determine which code is realy
> not needed ... WPO in this regard can not help?

No. There is no way for WPO to know what side effects the initialisation
of those variables could have.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 avr_save and avr_restore) Yes, then I have to change the
> parameters to const, and add {$WRITEABLECONST OFF} to the Arduino unit.
> 
> I doubt many (if any) compiler will/can do this. But that would be
> ideal. (I think we need the concept Gareth calls 'pure functions' for this)

No, but you would need to add support to the compiler for keeping a
symbolic representation of typed constants.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC PasCocoa/Differences

[Jonas Maebe via fpc-pascal]

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 PasCocoa/Differences wiki seems to ignore a crucial
> difference between ObjC categories and ObjC class extensions, namely the
> ability to add properties to an existing class.

I'm not sure that was already possible when that wiki page was written.
It was probably only added later in Objective-C 2.0.

> Am I correct that the latter is not possible in Objective-Pascal ?

You are correct. OTOH, it feels kind of useless in general, because

"A class extension bears some similarity to a category, but it can only
be added to a class for which you have the source code at compile time
(the class is compiled at the same time as the class extension)."

So there's not really much difference between a class extension with
fields and adding private fields to the class declaration itself. It's
more something to keep information completely out of the header files in
Objective-C. While you can use include files to separate your header and
implementation of a unit in Pascal, and then only distribute the header
include files so people can look at them, this feels like a rather niche
use case.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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.org/docs-html/prog/progse30.html#x195-207.3
>>>
>>> At least explain:
>>> - relation of -CX and -XX
>>
>> Indeed.
> 
> I am all for it.
> 
> But please explain them in plain language so I can update the
> documentation,
> because from the help pages, I don't know what exactly to explain.

The general explanation is:
-CX: create object files that can be smartlinked
-XX: perform smartlinking during the linking phase (this requires that
the units were compiled with -CX)

On some targets, -CX is a no-op and -XX works even when -CX was not
specified (e.g. Linux), or both -CX and -XX are no-ops and smart linking
is always enabled (Windows).


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 methods, global
> variables, and regular procedures/functions

Disagreed. Those are implementation details, may vary from target to
target, may depend on the assembler/linker rather than on FPC, etc. What
I wrote is just the high level idea. When you have e.g. published
properties and their RTTI, you can easily start having a lot of hidden
references.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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
> based smart linking is a default option in recent FPC versions.

At least -XX is still necessary, otherwise we don't enable dead
code/data stripping in the linker (at least not on Linux). And on macOS,
-CX is also needed, otherwise the compiler does not emit a directive in
the object files that dead code/data stripping should be enabled based
on whether or not there are references to the global symbols preceding them.

Neither parameter may be necessary on Windows, but that's probably the
only one.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 link maps (-Xm) and compare those.

> 2. Is smart-linking/WPO capable to remove unused:
> 2.1  regular procedures/functions ?
> 2.2  methods of classes (non virtual, virtual) ?
> 2.3  class methods of classes ?

Smartlinking can remove any non-referenced non-virtual methods, global
variables, and regular procedures/functions.

Regarding what WPO can do, see
https://wiki.freepascal.org/Whole_Program_Optimization


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Unicode chars losing information

[Jonas Maebe via fpc-pascal]

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 would just
turn it off. It's not possible to safely use unicodestring without
knowing how 16bit unicode works. The compiler can't solve that.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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

It's not broken in general. E.g. the compiler cycles fine with -Ct on
Darwin.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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
  #WRITE Compiling Debug Version
#ENDIF

It seems the stack checking code causes issues for you in 3.2.0 for some 
reason.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 something changed from 3.0.4 to 3.2.0 related to unit
> initialisation ?

Not that I remember. Where exactly does it crash?


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] CP_NONE string disappearing

[Jonas Maebe via fpc-pascal]

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 win32/wine.
> 
> Is that supposed to happen?

https://wiki.freepascal.org/FPC_Unicode_support#Code_page_identifiers

"CP_NONE: this value indicates that no code page information has been
associated with the string data. The result of any operation on a string
that has this dynamic code page is undefined."


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 possible to implement a function with C varargs in
>>>> FPC.
>>>
>>> I was afraid that's the answer :-(
>>>
>>> as an ugly workaround, I wrote a c library that vsnprintf msg and args
>>> to a buffer and then calls a pascal function with no varargs.
>>>
>>> It works but, as I said, it's ugly and I'd need to provide a .a for
>>> every platform I plan to use.
>>>
>>> Is there a better/simpler way (apart from asking the library developers
>>> to use a callback with no varargs)?
>>
>> No.
> 
> Not necessarily better than platform specific .a files mentioned by
> Luca, but the required playing with stack and registers should be still
> doable with a function written in assembler (inside the Pascal sources),
> shouldn't it?

Yes, but you'd have to write it separately for each ABI.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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, I wrote a c library that vsnprintf msg and args
> to a buffer and then calls a pascal function with no varargs.
> 
> It works but, as I said, it's ugly and I'd need to provide a .a for
> every platform I plan to use.
> 
> Is there a better/simpler way (apart from asking the library developers
> to use a callback with no varargs)?

No.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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);
> 
> 
> however I couldn't find a way to define a suitable callback in fpc since
> the "array of const" construct is not allowed with cdecl without
> external, i.e.

It is indeed not possible to implement a function with C varargs in FPC.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 from this as it iterates linked lists a lot.
> Just curious, how does the "prefetch intrinsic" help with iterating linked 
> lists?

By prefetching the next element in the background while processing the
current element. Since the elements are not necessarily placed behind
each other in memory, the processor's built-in prefetcher can't handle this.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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

See https://wiki.freepascal.org/LLVM#Frequently_Asked_Questions


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 the speed increase in compiling though. Yes I am
>> using different FPC and XCode versions, but I wonder what else could
>> have an influence? My project is very large and not divided into
>> packages, so I frequently need to recompile the whole project.
> 
> Large parts of FPC are memory throughput limited so I suspect the M1 is
> not that much better in this regard, not to mention that most likely the
> AAarch code generator is worse than the x86 one. x86 received a lot of
> work in this field.
> 
> Maybe it's possible that you build using an LLVM compiler the FPC with
> native backend. As I do not use macOS, I have no clue how to do this
> though.

For compiling the compiler itself, excluding assembling and linking, a
compiler compiled using the LLVM backend (but that generates code using
our native code generator (*) ) is 18.85% faster than one compiled using
our native code generator (on a Developer Transition Kit, but I guess it
will be similar on the M1).

If you include assembling and linking (which you obviously always have
to do), the speed difference shrinks to 8.5%. So more time is spent in
the assembler (clang) and ld than in the compiler.

As to how to do build a compiler on macOS that uses the LLVM backend,
that's the same as on Linux, except that you don't need special command
line options to find libgcc: https://wiki.freepascal.org/LLVM


Jonas

(*) using the LLVM backend is slower because clang's code generator is
much slower than FPC's.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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

The fact that you get similar speed on a cpu that probably uses quite a
bit less than half the power of your previous one is quite impressive.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 character `'' in expression"

How are you specifying your cross-compilation sysroot? Make sure you use
the -XR parameter for that, and not -Fl or so. -Fl just instructs the
compiler/linker to add a directory to the list of standard directories
to search, rather than to completely ignore your host system and only
look for libraries in the hierarchy below the sysroot.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Enum range check error

[Jonas Maebe via fpc-pascal]

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 create a false
>> sense of security and unpredictable results (because no compile-time
>> range checking is possible for variant records).
> Not even for enums? I get that records should just return zero'd memory but 
> enums seem to be a special case.

A record field whose type is an enum should be handled exactly the same
as an individual enum.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Enum range check error

[Jonas Maebe via fpc-pascal]

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 of Default, since Default
>> cannot be guaranteed to return a valid value for a type.
> 
> I thought default would just return the first value in the enum but I guess 
> it's just zeros. Maybe we need a better default for objfpc mode.

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 create a false
sense of security and unpredictable results (because no compile-time
range checking is possible for variant records).


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Enum range check error

[Jonas Maebe via fpc-pascal]

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 TSomething.Get: T;
> begin
>   // Range check error while evaluating constants (0 must be between 46 and 
> 46)
>   exit(Default(T));
> end;

See https://bugs.freepascal.org/view.php?id=34972 for some comments
about Default. So this is a bug in the usage of Default, since Default
cannot be guaranteed to return a valid value for a type.

It is even technically impossible to make Default return a valid value
for every type due to variant records (you could have overlapping
"field1: 1..3;" and "field2: 4..6;").


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 endian
PowerPC64 (which FreeBSD also has, so you'll indeed have to do the same
there).


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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
> > counter-intuitive and confusing.
> 
> The issue in this thread is caused by a bug in the LCL: it blindly
> assumes that the dynamic code page of the caption string is always
> utf-8. That is simply wrong (unless you put the burden on the user to
> always assign an utf-8-encoded string to it, but _that_ is
> counter-intuitive and confusing).
> 
> 
> But shouldn't the compiler insert a conversion if the string is declared
> as CP_1250 and the destination is CP_ACP? 

There are two things:
1) regardless of how the static code page of a string is declared, it is
never guaranteed that its dynamic code page will match it. The simplest
example is when you assign a RawByteString to it. There is, however,
also a second case (and this one indeed is counter-intuitive, but needed
for backward compatibility):
2) the second bullet under
https://wiki.freepascal.org/FPC_Unicode_support#Dynamic_code_page

That's what gets triggered here: the source file CP is CP_1250 and the
string is also ansistring(1250). That case would be solved by declaring
Label as UTF8String though.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Jonas Maebe via fpc-pascal]

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 will get issues all
over the place.

The second table looks more worrying. Where are the bug reports for the
cases where it fails? I would have to look at them more in detail to
find the causes, but at first sight it indicates several implementation
bugs.

> All the doubts, questions, and discussions prove that current system is
> counter-intuitive and confusing.

The issue in this thread is caused by a bug in the LCL: it blindly
assumes that the dynamic code page of the caption string is always
utf-8. That is simply wrong (unless you put the burden on the user to
always assign an utf-8-encoded string to it, but _that_ is
counter-intuitive and confusing).


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal