Overload resolution problem inside compiler
## Summary
<!-- Summarize the bug encountered concisely -->
The compiler chooses a wrong overload
when two variants differ only by the fact that one
parameter is by var in one overload and by value in the second,
but only if the type of that `var` variable is a pointer.
This bug also shows up currently inside trunk source,
for `netbsd`and `openbsd` OS targets with `sem_init` function overloads,
see for instance [i386-netbsd failure](https://www.freepascal.org/~pierre/checks/trunk/fpc/target-check-packages-i386-netbsd.txt.html)
```
Writing Resource String Table file: fptemplate.rsj
Compiling ./fcl-base/src/syncobjs.pp
syncobjs.pp(702,59) Error: Can't assign values to an address
syncobjs.pp(738,59) Error: Can't assign values to an address
syncobjs.pp(762,64) Error: Can't assign values to an address
```
## System Information
<!-- The more information are provided the easier it is to replicate the bug -->
- **Operating system:** Probably all <!-- Windows, Linux (if possible, also name the distro), FreeBSD, Android, ... -->
- **Processor architecture:** Probably all <!-- x86, x86-64, ARM, AARCH64, AVR, RISC-V, PowerPC, ... -->
- **Compiler version:** Tested on trunk compiler, but might be present in other versions <!-- 3.2, 3.2.2, 3.3, trunk, beta, ... (if possible, give also the git hash) -->
## Steps to reproduce
<!-- How one can reproduce the issue - this is very important! -->
Try to compile the file `toverload.pp` given below.
`fpc toverload.pp` results in this error:
```
fpc@idefix:~/pas/check$ fpc toverload.pp
Free Pascal Compiler version 3.3.1-14440-g51180e6823-unpushed [2023/11/22] for x86_64
Copyright (c) 1993-2023 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling toverload.pp
toverload.pp(38,7) Warning: Variable "i" does not seem to be initialized
toverload.pp(39,11) Error: Can't assign values to an address
toverload.pp(64) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /home/FPC/compilers/cross-compiling/pas/fpc-3.3.1/bin/ppcx64 returned an error exitcode
```
## Example Project
<!-- If possible, please create an example project that exhibits the problematic
behavior, and link to it here in the bug report. -->
```
fpc@idefix:~/pas/check$ cat toverload.pp
type
{$ifdef USE_RECORD}
trec = record
y : longint;
end;
{$else}
{$ifdef USE_PTRINT}
trec = ptrint;
{$else USE_PTRINT}
trec = pointer;
{$endif USE_PTRINT}
{$endif}
prec = ^trec;
const
value_version_used : longint = 0;
var_version_used : longint = 0;
has_error : boolean = false;
function test(p : prec;l : longint; k: dword) : boolean; overload;
begin
test:=(p<>nil);
inc(value_version_used);
end;
function test(var p : trec;l : longint; k: dword) : boolean; overload;
begin
test:=(@p<>nil);
inc(var_version_used);
end;
var
pt : trec;
i : trec;
begin
pt:=i;
test(@pt,23,56);
if (var_version_used>0) then
begin
writeln('call with @pt uses var version, which is wrong');
has_error:=true;
end
else
writeln('call with @pt uses value version');
var_version_used:=0;
value_version_used:=0;
test(pt,678,567890);
if (var_version_used>0) then
writeln('direct call uses var version')
else
writeln('direct call uses value version');
if has_error then
begin
writeln('This test revealed a problem');
halt(1);
end;
end.
```
## What is the current bug behavior?
<!-- What actually happens -->
Bug inside compiler leads, at line 39 of toverload.pp, to a wrong choice of the overloaded `test` function
having a by `var` first parameter, which is incompatible with the fact that this
`@pt` is incompatible with the `var`modifier.
## What is the expected (correct) behavior?
<!-- What you should see instead -->
The compiler should choose the correct overload without the `var`parameter.
## Relevant logs and/or screenshots
<!-- Paste any relevant logs - please use code blocks (```) to format console output, logs, and code, as
it's very hard to read otherwise.
You can also use syntax highlighting for Pascal with: ```pascal the code```
For more information see https://docs.gitlab.com/ee/user/markdown.html -->
## Possible fixes
<!-- If you can, link to the line of code that might be responsible for the problem -->
The fix is probably to change `choose_best` function
in order to also consider the `vs_value`or `vs_var` varspez field of the parameters.
issue