Re: [fpc-devel] How to view .ll files generated by LLVM backend?

[Pierre Muller via fpc-devel]

Le 25/07/2023 à 17:52, Lucian Popescu via fpc-devel a écrit :

Hi,

I followed the instructions for building FPC with LLVM presented here [1].

Now I am interested in generating LLVM assembly from the corresponding
Pascal code. Is there any method to achieve this?


 Just use -al option, this will leave the generated .ll file present after 
compilation.

 You can also use -vx option to see how clang is called:


Pierre

muller@gcc187:~/pas/check$ fpc -al -vx hello.pp
Free Pascal Compiler version 3.3.1-13440-ge4911588c5-unpushed-dirty 
[2023/07/26] for x86_64
Copyright (c) 1993-2023 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling hello.pp
Assembling program
Executing "/home/muller/bin/clang" with command line "-x ir -O0 
-fno-omit-frame-pointer -static -target x86_64-unknown-linux-gnu -c -o hello.o hello.ll "
Linking hello
Executing "/usr/bin/ld.bfd" with command line "-b elf64-x86-64 -m elf_x86_64  
--dynamic-linker=/lib64/ld-linux-x86-64.so.2   -s-L. -o hello -T link3003900.res -e _start 
--eh-frame-hdr"
Size of Code: 336615 bytes
Size of initialized data: 9568 bytes
Size of initialized data: 6648 bytes
Size of uninitialized data: 7016 bytes
3 lines compiled, 0.1 sec, 336615 bytes code, 23232 bytes data
muller@gcc187:~/pas/check$ ls -altr hello*
-rw-rw-r--. 1 muller muller 32 Aug  4  2022 hello.pp
-rw-rw-r--. 1 muller muller   5220 Jul 26 11:43 hello.ll
-rw-rw-r--. 1 muller muller   2584 Jul 26 11:43 hello.o
-rwxrwxr-x. 1 muller muller 447584 Jul 26 11:43 hello
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Haiku

[Pierre Muller via fpc-devel]

  Hi Paul,


  The web site is not up to date, but if you go to:
https://sourceforge.net/projects/freepascal/files/Haiku/3.2.2/

you will find the 3.2.2 release for x86_64 CPU.

I used it only very little, and I am not sure it works for all beta/alpha 
releases...

  Please let us know if it works for you,
and on which release!

Pierre

Le 04/02/2023 à 23:48, Paul Renaud via fpc-devel a écrit :

Is there any plan to release a version of the compiler for 64-bit Haiku?


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

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

Re: [fpc-devel] Attn Florian, commit 1b698210 10/10/2022 22:45:31 breaks DWARF info

[Pierre Muller via fpc-devel]

  Hi Martin,

could you tell me if
https://gitlab.com/freepascal.org/fpc/source/-/issues/39928#note_1140122898

fixes your troubles?

Thanks in advance,

Pierre

Le 19/10/2022 à 19:47, Martin Frb via fpc-devel a écrit :

Revision: 1b6982107f1ac4b4111e37be0a3649d155a2bc1e
Author: florian 
Date: 10/10/2022 22:45:31
Message:
    * TDebugInfoDwarf3.appenddef_object should not write an extra
finish_entry for objects and C++ classes

This adds extra DW_OP_... statements in 2 places

In
procedure addstringdef(const name: shortstring; chardef: tdef; deref:
boolean; lensize: aint);

+
current_asmdata.asmlists[al_dwarf_info].concat(tai_const.create_8bit(ord(DW_OP_nop)));

However it does not increase the byte count "upperopcodes" in the
    append_entry(DW_TAG_subrange_type,false,[
      DW_AT_lower_bound,DW_FORM_udata,1,
      DW_AT_upper_bound,DW_FORM_block1,upperopcodes
      ]);

Similar in:
      procedure tdebuginfodwarf3.appenddef_array(list: tasmlist; def:
tarraydef);

--

I am still puzzled at the effect from what I saw in the data I got from
a reporter.
He send me an objdump (which failed mid way)


   <2><2617>: Abbrev Number: 18 (DW_TAG_subrange_type)
      <2618>   DW_AT_lower_bound : 1
      <2619>   DW_AT_upper_bound : 13 byte block: 97 6 12 28 4 0 30 2f 3
0 38 1c 6  (DW_OP_push_object_address; DW_OP_deref; >
   <2><2627>: Abbrev Number: 22 (DW_TAG_subprogram)

It should be followed by "Abbrev Number; 0" (end of the nested block)

Of course FPC would now write 14 bytes (while the header still says 13),
bot the 14th byte should be
      DW_OP_nop   = $96

So I am puzzled where the 22 comes from.
Though that could be something that objdump did. (I don't have the exe
in question / and I haven't reproduced myself)

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

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

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

[Pierre Muller via fpc-devel]

2. Is it possible to add z80 cross compilation target to FP IDE? The FP IDe 
shows me a few targets, but z80 is not there.



The text mode IDE can only ever compile for one CPU platform, so you need to 
build it for Z80. Though I don't know right now whether this is enabled.


  I just added basic support for a few more CPUs: riscv32, riscv64, wasm32, 
xtensa and z80.

 You can generate them in newest trunk by moving to packages/ide directory and 
issuing a:

make all_targets OPT=""
with  being you usual OPT.

Or you can simply use:
make z80 OPT=""
followed by
make z80_install OPT=""

  This should add z80-fp executable in the same location as
your latest trunk compiler...

  Most CPUs do not have CPU specific options encoded inside
the IDE sources, thus you might need to add the options you
want to use to the
  Please report if you discover any problems.

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

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

[Pierre Muller via fpc-devel]

Le 01/02/2022 à 06:28, Thorsten Otto via fpc-devel a écrit :

On Freitag, 28. Januar 2022 13:55:11 CET Thorsten Otto via fpc-devel wrote:

 > Then i tried -Aas, but then the compiler also complains:

 >

 >

 >

 > Warning: (treated as error) Assembler output selected "AS" is not compatible

 > with "Atari ST/STE"

 >

 > Warning: (treated as error) "VASM" assembler use forced

Bump ;)

Any solution to this? Currently seems to be impossible to use gas at all.


  Sometimes, you need to dig into the sources:
look at compiler/m68k/ag68kgas.pas unit.

  You will see that atari is listed there:
muller@gcc120:~/pas/trunk/fpcsrc/compiler/m68k$ grep -inC7 atari ag68kgas.pas
370-
371-   as_m68k_as_aout_info : tasminfo =
372-  (
373-id : as_m68k_as_aout;
374-idtxt  : 'AS-AOUT';
375-asmbin : 'as';
376-asmcmd : '$ARCH -o $OBJ $EXTRAOPT $ASM';
377:supported_targets : [system_m68k_Amiga,system_m68k_Atari];
378-flags : [af_needar];
379-labelprefix : '.L';
380-labelmaxlen : -1;
381-comment : '# ';
382-dollarsign: '$';
383-  );


The idtxt field is the string you need to use to enable GNU assembler for aout 
format,
thus you should use
  -Aas-out
compiler option. It is true that this entry is missing in
ppc68k -h
output...

Pierre

Pierre

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

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

[Pierre Muller via fpc-devel]

Le 10/11/2021 à 21:19, Sergey Organov via fpc-devel a écrit :

Hello,

Using cross-compiler from x86-linux to arm-linux, I keep getting a lot
of warnings at the linking stage of my programs, in the form:

/opt/[...]/arm-linux-gnueabihf-ld: warning: library search path 
"/usr/lib/eject/" is unsafe for cross-compilation
/opt/[...]/arm-linux-gnueabihf-ld: warning: warning: library search path 
"/usr/lib/console-setup/" is unsafe for cross-compilation
[...]

for virtually every sub-directory in /usr/lib. FPC 3.2.0 and 3.2.2 both
have this issue.

This makes me suspect FPC cross produces instructions for the linker to
search for files in wrong directories, where host libraries reside, that
could lead to unpredictable results, and then tons of the warnings are
really annoying.

What's the way to fix this?


  Try to use -Xd compiler option
~/bin$ fpc -h | grep -- -Xd
  -XdDo not search default library path (sometimes required for 
cross-compiling when not using -XR)


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

Re: [fpc-devel] Anyone an idea were/how to look for the missing merge in 3.0.2

[Pierre Muller via fpc-devel]

Le 09/06/2021 à 00:31, Martin Frb via fpc-devel a écrit :

I have the following issue.

A testcase (LazDebuggerFp/test) works fine. Except for 3.2.0 and 3.2.2 (win 64) 
with -O3 or -O2

In detail:
- It works in 32 bit   3.2.2 --  O3
- It works in 64 bit  3.0.4 / 3.3.1  -- O1 O2 and O3   (My 3.3.1 is 2 weeks 
old.)
- It works in 64 bit  LINUX  3.2.2 --  O3
- It works in 64 bit   3.2.0 / 3.2.2  -- O1
- It works in 64 bit   3.2.2  -- O3  with {$implicitexceptions off} in several 
units

* It does not work in 64bit  3.2.0 / 3.2.2  -O2 or O3  with default 
{$implicitexceptions ON}

Yes, it could be a bug in my code, but at this point, my primary suspicion 
points to a different origin for the trouble.

I could not find the faulty code yet. I suspect that it is a random memory 
write (dangling pointer) that causes an error long after.
And  given that I can't use valgrind

So anyone can thing of any bug fixed (as it works with 3.3.1), that may not 
have been merged?
I have not checked 3.2.1 yet. / Will be a while, I am away a couple of days.


  Martin,

could you check if this relates to bug #38973?

https://bugs.freepascal.org/view.php?id=38973

 This bug also does not show in current trunk.

 If you get the same pattern of failures, it is most probably related to this 
wrong optimization.


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

Re: [fpc-devel] Odd test failure on x86_64-win64

[Pierre Muller via fpc-devel]

Please look at:


https://www.freepascal.org/testsuite/cgi-bin/new-testsuite2.cgi?action=4=5630

.rdata support, i.e. read-only data sections,
is not supported in several CPU-OS combination,
and  IIRC, it is even worse for PIC code,
but I don't really know if these special limitations
should not be removed...

See TGNUAssembler.sectionname method in compiler/aggas.pas unit,
and difference between secnames and secnames_pic inside that method.

Pierre

Le 12/05/2021 à 20:13, J. Gareth Moreton via fpc-devel a écrit :

Hi everyone,

So I stumbled across this during my optimisation development:

Under x86_64-win64 (I'm not sure about other platforms), the test
"test/tarray15.pp" fails with exitcode 19 if you run the test suite with
TEST_OPT=-a to create assembly dumps.  The failure is because the code
attempts to write to a constant but doesn't raise an exception while
doing so.  Can anyone else confirm this?

Gareth aka. Kit



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

Re: [fpc-devel] FPC 3.2.2-RC1 released!

[Pierre Muller via fpc-devel]

Le 24/03/2021 à 12:10, Marco van de Voort via fpc-devel a écrit :

Hello,

We have placed the first release candidate of the Free Pascal Compiler
version 3.2.2 on our ftp servers.

You can help improve the upcoming 3.2.2 release by downloading and
testing this release. If you want you can report what you have done here:
http://wiki.freepascal.org/Testers_3.2.2 or in the maillist.

Changes that may break backwards compatibility will be documented at:
http://wiki.freepascal.org/User_Changes_3.2.2

Downloads are available at the main FTP server and

ftp://freepascal.stack.nl/pub/mirrors/fpc/beta/3.2.2-rc1/


You need to open that directory to world!

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

Re: [fpc-devel] FPC 3.2.0RC1 released!

[Pierre Muller]

Le 30/03/2020 à 15:33, Mattias Gaertner via fpc-devel a écrit :
> On Sun, 29 Mar 2020 20:18:19 +0200
> Marco van de Voort  wrote:
> 
>> [...]
>> You can help improve the upcoming 3.2.0 release by downloading and
>> testing this release. If you want you can report what you have done
>> here: http://wiki.freepascal.org/Testers_3.2.0 or in the maillist.
> 
> It seems libpas2jslib.so needs some adjustments under debian:
> 
> From lintian:
> 
> Errors:
> unstripped-binary-or-object usr/lib/libpas2jslib.so
> library-not-linked-against-libc usr/lib/libpas2jslib.so
> shlib-with-executable-bit usr/lib/libpas2jslib.so 0755
> package-must-activate-ldconfig-trigger usr/lib/libpas2jslib.so
> 
> Warnings:
> 
> shlib-without-versioned-soname usr/lib/libpas2jslib.so libpas2jslib.so

  Michael,

  I remember that I was also asking why you did not put the shared lib
into the lib/fpc/3.2.0/lib subdirectory, but I forgot your explanation...


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

Re: [fpc-devel] generate assembler with no clear purpose MOV

[Pierre Muller]

Le 05/02/2020 à 07:17, Marģers . via fpc-devel a écrit :
>  
> 
> From:  J. Gareth Moreton 
> To:  
>> Are you able to dump the nodes as well with -an? (You'll need to define
>> -dEXTDEBUG though) That might give some clues behind the presence of
>> that movslq instruction.
> 
> building compiler with -dEXTDEBUG does not work for me
> make singlezipinstall OS_TARGET=linux CPU_TARGET=x86_64  OPT="-dEXTDEBUG 
> -CpCOREAVX2 -OpCOREAVX2 
> -Fu/home/user/fpc304/lib/fpc/3.0.4/units/x86_64-linux/rtl/"
> 
> constexp.pas(125,13) Warning: Location (LOC_CSSETREG) not equal to expectloc 
> (LOC_REG): typeconvn
> constexp.pas(594) Fatal: There were 1 errors compiling module, stopping

  Some extra warnings are generated when -dEXTDEBUG is iused which lead to 
errors because -Sew option is used by default.

  You will need to also add ALLOW_WARNINGS=1 to the make call.

Pierre

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

Re: [fpc-devel] error compiling trunk 42843

[Pierre Muller]

Le 27/08/2019 à 13:44, Martin a écrit :
> Compiling trunk ON win10/64
> Compiling FOR 32bit
> with   -gl -O4 -Or
> 
>  From the make output
> 
> make.exe compiler
> make.exe[5]: Entering directory `c:/FPC/fpc_3.3.1/source/compiler'
> B:/FPC/SVN/build_trunk/install/binw32/gmkdir.exe -p i386/units/i386-win32
> B:/FPC/SVN/build_trunk/install/binw32/gmkdir.exe -p i386/bin/i386-win32
> c:/FPC/fpc_3.3.1/source/compiler/ppc1.exe -XX -CX -Ur -Xs -O2 -n -O2 
> -Fui386 -Fusystems -Fuc:/FPC/fpc_3.3.1/source/rtl/units/i386-win32 
> -Fii386 -FEi386/bin/i386-win32 -FUi386/units/i386-win32 -dRELEASE -gl 
> -O4 -Or    -di386 -dGDB -dBROWSERLOG -Fux86 -Sew pp.pas
> symtable.pas(4363,28) Warning: Variable "srsym" does not seem to be 
> initialized
> symtable.pas(4769) Fatal: There were 1 errors compiling module, stopping
> Fatal: Compilation aborted


  Should be fixed in commit #42857

Thanks for reporting the problem, which only happened with -O3 or -O4 option.

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

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

[Pierre Muller]

Le 05/07/2019 à 17:42, J. Gareth Moreton a écrit :
> 
> On 05/07/2019 15:51, Pierre Muller wrote:
>> Just one point from current compiler implementation:
>>
>> in trunk/fpcsrc/compiler/ninl.pas (around line 3180)
>>
>>in_pred_x,
>>in_succ_x:
>>  begin
>> set_varstate(left,vs_read,[vsf_must_be_valid]);
>> resultdef:=left.resultdef;
>> if is_ordinal(resultdef) or is_typeparam(resultdef) then
>>   begin
>> if (resultdef.typ=enumdef) and
>>(tenumdef(resultdef).has_jumps) and
>>not(m_delphi in current_settings.modeswitches) and
>>not(nf_internal in flags) then
>>   
>> CGMessage(type_e_succ_and_pred_enums_with_assign_not_possible);
>>   end
>>
>>
>> This means that using pred() or succ() intrinsics on enumerated types with
>> holes will generate a Compile Time Error.
>>
>>To be consistent, I would propose that we also generate
>> a Compile Time Error if 'is' or 'as' keyword is used on such a type,
>> unless there is a code that really check that the value is not in
>> one of the holes ...
>>
>> Pierre
> 
> That seems fair.  The main problem is what happens if, when allowed, 
> Prec or Succ are used on such a type on an element that is adjacent to 
> one of these holes.  Should it skip to the first element at the other 
> end of the hole or raise an exception? Granted, what happens if you use 
> Prec or Succ on the first or last element respectively?
> 
> I can theoretically design an algorithm to cover these gaps with Boolean 
> conditions for the sake of "is", but it's a little bit complex.
> 
> Sorry to bring you in on this particular point, Pierre, but if you call 
> "Value is TEnum" and Value is of type TEnum but contains an invalid 
> value (due to being read from an external stream, for example), should 
> it return True or False?

  My answer would be:

in FPC modes, simply generate a CompileTimeError as above,

in Delphi mode, as Delphi states stat the holes are also valid values of the 
range,
then indeed, pred() and succ() can do the simple thing they do when there are 
no holes,
and 'is' or 'as' should then also do the same, i.e. only check that the value 
is inside
the range defined by the lowest and highest values!

  But on course this means that in Delphi mode,
even after validating with 'is' you could still have a valid enum value that 
has no
name, i.e. that is in one of those black holes ...

  I don't need to tell you that I do have a preference for the ordinary Free 
Pascal way!

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

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

[Pierre Muller]

Just one point from current compiler implementation:

in trunk/fpcsrc/compiler/ninl.pas (around line 3180)

  in_pred_x,
  in_succ_x:
begin
   set_varstate(left,vs_read,[vsf_must_be_valid]);
   resultdef:=left.resultdef;
   if is_ordinal(resultdef) or is_typeparam(resultdef) then
 begin
   if (resultdef.typ=enumdef) and
  (tenumdef(resultdef).has_jumps) and
  not(m_delphi in current_settings.modeswitches) and
  not(nf_internal in flags) then
 
CGMessage(type_e_succ_and_pred_enums_with_assign_not_possible);
 end


This means that using pred() or succ() intrinsics on enumerated types with
holes will generate a Compile Time Error.

  To be consistent, I would propose that we also generate
a Compile Time Error if 'is' or 'as' keyword is used on such a type,
unless there is a code that really check that the value is not in
one of the holes ...

Pierre

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

[fpc-devel] XML node dump, how to use them?

[Pierre Muller]

  Hi all,

  I start a new thread on the xml node dump
developed by Gareth that I recently committed.

 I think we need at least two missing features:

 I would like to be able to visualize them,
for this a CSS would be a minimal requirement,
but it would be much better to a a xml schema.

  I had no idea what a 'schema' is until a few days ago...
so I am probably not the one who will add this...

  Another important missing information is
the class of a method, which should probably simply be
added to the procedure name as 'TClass.' prefix.



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

Re: [fpc-devel] Pending approval...

[Pierre Muller]

Le 18/06/2019 à 04:21, J. Gareth Moreton a écrit :
> Hi everyone,
> 
> So I sent my last update/fix/patch for the XML core dump feature 3 weeks 
> ago, but my main liaison, Pierre, seems to have vanished for the time 
> being.  Hopefully he's okay, but it means the feature is currently in 
> limbo and I could greatly benefit from its use in developing future 
> ideas, and I'm sure other developers will find use in it too. 
> https://bugs.freepascal.org/view.php?id=35017

  Hi all,

as you might remember, there are only afew volonteers behind this project,
which all have also 'a real life' which makes them not available
at all times for 'Free Pascal' project.

  Besides, there are numerous other problems that I am also trying to
tackle and resolve.

  Otherwise, thank you very much for your concern, but I am OK,
just not as available as I would like...

  Coming back to the XML dump feature that you developed,
I do think that it is now in a better state, and it will probably be
integrated into main trunk after I find time to re-run the different checks
that I used for the mutual feedback.

  I cannot give you any fixed date for this, as it will depend greatly on
the time I can find for Free Pascal, and on those other tasks.


> On another note, I've made some fixes to compiler issues when it comes 
> to x86 assembly language, specifically the SSE and AVX instructions that 
> deal with single rather than packed data, because a number of 
> instructions would throw false warnings or errors due to incorrect 
> operand sizes, even though they are actually correct.  Details can be 
> found here: https://bugs.freepascal.org/view.php?id=35700 (this one has 
> a couple of linked issues too).

  My knowledge about those i386/x86_64 extensions is too vague,
so you will need to find another core developer to handle this bug report.

  Keep on the good work, and try to be patient with
other members that have less time to dedicate to Free Pascal!

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

Re: [fpc-devel] [Core] Haiku merges: Revision 42117

[Pierre Muller]

  The merge of the two commits generate 3 conflicts, but those are easily 
solved.
See attached patch.

  Olivier, did you test the fixes_3_2 branch?
Do you think it is reasonable to enable x86_64-haiku target in that branch?

  charlie, you wrote those patches, thus
it is probably best if you or Olivier decide:
Should I merge them?

Pierre


Le 26/05/2019 à 15:17, Pierre Muller a écrit :
>   Hi al,
> 
> almost every haiku RTL changes have been merged,
> but there are also two compiler changes:
> 
> [muller@gcc121 pas]$ svn log -v -c 40753 trunk/fpcsrc/
> 
> r40753 | karoly | 2019-01-04 02:16:24 + (Fri, 04 Jan 2019) | 1 line
> Changed paths:
>M /trunk/compiler/options.pas
>M /trunk/compiler/systems/i_haiku.pas
>M /trunk/compiler/systems/t_haiku.pas
>M /trunk/compiler/systems.inc
>M /trunk/compiler/utils/ppuutils/ppudump.pp
>M /trunk/compiler/x86/agx86att.pas
>M /trunk/compiler/x86_64/cpuelf.pas
>M /trunk/compiler/x86_64/cputarg.pas
>M /trunk/packages/fpmkunit/src/fpmkunit.pp
>M /trunk/utils/fpcm/fpcmmain.pp
> 
> haiku-x86_64: add target to the compiler and ppudump, enable it in fpmake and 
> fpcmake
> 
> [muller@gcc121 pas]$ svn log -v -c 40756 trunk/fpcsrc/
> 
> r40756 | karoly | 2019-01-04 03:00:03 + (Fri, 04 Jan 2019) | 1 line
> Changed paths:
>M /trunk/compiler/systems/t_haiku.pas
>M /trunk/compiler/systems.pas
> 
> haiku: linker support code for internal sysinit and make the x86_64 port use 
> it
> 
> 
> 
> Shoudln't these two be also merged to fixes?
> 
> 
> Pierre
> 
> 
> 
> <https://svn.freepascal.org/cgi-bin/viewvc.cgi?root=fpc=rev=42117>
> 
> ___
> core site list
> c...@freepascal.org
> https://idefix.freepascal.org/cgi-bin/mailman/listinfo/core
> 
Index: .
===
--- .   (revision 42129)
+++ .   (working copy)

Property changes on: .
___
Modified: svn:mergeinfo
   Merged /trunk:r40753,40756
Index: compiler/options.pas
===
--- compiler/options.pas(revision 42129)
+++ compiler/options.pas(working copy)
@@ -138,7 +138,7 @@
 + [system_i386_wdosx];
 
   suppported_targets_x_smallr = systems_linux + systems_solaris + 
systems_android
- + [system_i386_haiku]
+ + [system_i386_haiku,system_x86_64_haiku]
  + [system_i386_beos]
  + [system_m68k_amiga];
 
Index: compiler/systems/i_haiku.pas
===
--- compiler/systems/i_haiku.pas(revision 42129)
+++ compiler/systems/i_haiku.pas(working copy)
@@ -105,6 +105,76 @@
 llvmdatalayout : 
'e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32';
   );
 
+const
+   system_x86_64_haiku_info : tsysteminfo =
+  (
+system   : system_x86_64_Haiku;
+name : 'Haiku for x86_64';
+shortname: 'Haiku';
+flags: 
[tf_under_development,tf_needs_symbol_size,tf_files_case_sensitive,
+
tf_pic_default,tf_library_needs_pic,tf_smartlink_sections,
+tf_has_winlike_resources];
+cpu  : cpu_x86_64;
+unit_env : 'HAIKUUNITS';
+extradefines : 'BEOS;UNIX;HASUNIX';
+exeext   : '';
+defext   : '.def';
+scriptext: '.sh';
+smartext : '.sl';
+unitext  : '.ppu';
+unitlibext   : '.ppl';
+asmext   : '.s';
+objext   : '.o';
+resext   : '.res';
+resobjext: '.or';
+sharedlibext : '.so';
+staticlibext : '.a';
+staticlibprefix : 'libp';
+sharedlibprefix : 'lib';
+sharedClibext : '.so';
+staticClibext : '.a';
+staticClibprefix : 'lib';
+sharedClibprefix : 'lib';
+importlibprefix : 'libimp';
+importlibext : '.a';
+Cprefix  : '';
+newline  : #10;
+dirsep   : '/';
+assem: as_x86_64_elf64;
+assemextern  : as_gas;
+l

Re: [fpc-devel] Packed record integers and x86_86

[Pierre Muller]

> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org 
> 
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> 
> 
> Pointer arithmetic:
> *for Indx := 0 to SizeOf(TTCPPackageHeader) - 1 do 
> Dec(Byte(Pointer(Cardinal(@x) + Indx)^), ARollCount);*
the error has nothing to do with your record,
its that part:
Pointer(Cardinal(@x) + Indx)^)

The problem is that Cardinale is an unsigned 32-bit integer,
while on 64-bit, you will need UINT64,

  You should use PtrUInt type that is an unsigned type
that always have the size of an address instead of cardinal here!


Pierre
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TRegistry fixes

[Pierre Muller]

  Hi Bart,

Le 11/02/2019 à 15:29, Bart a écrit :
> Hi,
> 
> The new (W-API based) TRegistry in trunk and 3.2 fixes has some
> problems on Windows, amongst which at least one regression.
> 
> https://bugs.freepascal.org/view.php?id=35060
> The use of Utf8Decode on strings that are not guaranteed to be CP_UTF8 is 
> wrong.
> As a result Keys with unicode characters in their name cannot be read
> anymore (nor written to).
> (This is a regression)
> 
> https://bugs.freepascal.org/view.php?id=34876
> The implementation of ReadStringList/WriteStringList treats a sequence
> of Unicode chars (WideChar) as if they were AnsiChar (a.o.).
> 
> https://bugs.freepascal.org/view.php?id=35022
> TRegIniFile writes data to the wrong Key.
> 
> All these issues have patches and sample programs attached.
> 
> The patch for https://bugs.freepascal.org/view.php?id=35022 also
> resolves https://bugs.freepascal.org/view.php?id=35023 and
> https://bugs.freepascal.org/view.php?id=33980
> 
> Attached to https://bugs.freepascal.org/view.php?id=35022  is also a
> test, intended to be added to tests/test/packages/fcl-registry.
> (Currently the only test there is a trivial one.)
> 
> I can try to write tests for the other issues as well, but verifying
> in code that WriteStringList yields the correct result may be a little
> tricky, because it would depend on ReadStringList.
> The patch for that issue will write a StringList and read that back
> again and regedit does not complain that data is wrong.
> 
> It would be very nice if some devel who actually uses Windows (and has
> at least rudimentary knowledge of the use of TRegistry) can have a
> look at it and give some feedback.
> Especially since these bugs will be in the upcoming 3.2.0 if they are
> not fixed (and merged).
> 


  I am one of the rare regular users of Windows OS in the core team,
but I must also confess that I am neither knowledgeable in TRegistry fields,
nor in all what concerns UniCode matters, which is still the main point
of those modifications...

  If nobody else steps up, I will try to look into it,
but I hope someone else from core team will be able to check and commit
those changes...


Pierre
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Sorry for poor testing

[Pierre Muller]

Hi all,


Le 14/01/2019 à 15:01, J. Gareth Moreton a écrit :
> Hi everyone,
> 
> I apologise I didn't properly test my case block improvements, especially 
> where optimising for size is concerned.  As someone who has worked in SQA, I 
> should have known better.
> 
> I've also spotted a potential overflow condition (in some situations, 
> max_dist can become negative) - this is thankfully disguised, but I would 
> like to properly trap it and handle it cleanly and safely.

  You should try to add
  -CriotR to OPT when cycliing the compiler,
as it might find the overfows for you...
and even also do
make  fullcycle OPT="-n -CriotR -gl"
as testing the change for 16 bit address
CPU can also reveal more range checking/overflow exceptions.

Pierre

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Proposal to adapt search patch under Haiku using a target specific option (-WH).

[Pierre Muller]

  Hi Olivier,

if you want, I can integrate those changes into trunk for you.

 Did you already start working on other CPU support for Haiku?

 Do you have any compile-farm similar to gcc-farm?

 It would be nice to also get regular testsuite results for Haiku OS!


Have a nice new year celebration!

Pierre

PS: I don't remember if you speak French,
but, just in case,
Bonne et heureuse année
else
Happy New Year!



Le 30/12/2018 à 14:58, Olivier Coursière via fpc-devel a écrit :
> Some background :
> 
> Haiku currently supports two compilers toolchains with two sets of 
> libraries and ABI for its 32 bits flavor :
>   - gcc 2 for BeOS compatibility
>   - gcc 4 (or above : currently 7.3) for newer libraries like Qt (and 
> Lazarus).
> 
> The default gcc toolchain can be changed using a command line : setarch 
> currently accepting x86_gcc2 or x86.
> Once this is done, the only practical difference from Freepascal point 
> of view is that the search patch should be adapted to use the rights 
> libraries according to the context.
> 
> A few years ago, i have open the bug 26486 
> (https://bugs.freepascal.org/view.php?id=26486) with a first proposal 
> that was too hacky to be committed. Since then, i have made another 
> proposition involving a new command line switch to let specifying the 
> set of search paths when targeting gcc4. This alternative proposal got 
> unnoticed since then.
> 
> I am currently looking at packaging Lazarus for Haiku and it would 
> simplify the process a lot in our Haikuports system (our equivalent of 
> Ports in FreeBSD).
> 
> So here is the proposal :
> 
> I propose to add a -WH option that can accept a "gcc4" parameter to 
> specify the alternative option. This is similar to others -W options 
> used to specify the kind of applications on the same platform (like -WA 
> or -WG for Windows).
> It would simplify lazarus building under Haiku using a command like that :
> 
> make LCL_PLATFORM=qt OPT="-WHgcc4"
> 
> Do you think that kind of options could be upstreamed ? If so, i can 
> update the patch to match current sources and maybe use the same option 
> names as setarch to specify the platform.
> 
> If not, i can still patch freepascal sources before packaging freepascal 
> for Haiku through our haikuports system. But it would be, in my opinion, 
> less practical on the long term.
> 
> Or maybe someone will come up with a better idea to handle that kind of 
> problems ?
> 
> What do you think about this proposal ?
> 
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Sparc64 on solaris

[Pierre Muller]

r/sparc64/cpugas.pas
===
--- fpcsrc/compiler/sparc64/cpugas.pas  (revision 40515)
+++ fpcsrc/compiler/sparc64/cpugas.pas  (working copy)
@@ -235,7 +235,7 @@
 {$else}
asmcmd : '$ARCH $PIC -o $OBJ $EXTRAOPT $ASM';
 {$endif}
-   supported_targets : [system_sparc64_linux];
+   supported_targets : [system_sparc64_linux,system_sparc64_solaris];
flags : [af_needar,af_smartlink_sections];
labelprefix : '.L';
comment : '# ';
@@ -248,7 +248,7 @@
idtxt  : 'GAS';
asmbin : 'gas';
asmcmd : '$ARCH $PIC -o $OBJ $EXTRAOPT $ASM';
-   supported_targets : [system_sparc64_linux];
+   supported_targets : [system_sparc64_linux,system_sparc64_solaris];
flags : [af_needar,af_smartlink_sections];
labelprefix : '.L';
comment : '# ';


Le 10/12/2018 à 13:11, Pierre Muller a écrit :
>   Did you check if the snapshots are working?
> 
> ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/sparc64-linux/
> 
> contains both native snapshots and cross-snapshots created on a x86_64-linux 
> machine.
> 
>   For sparc64-solaris, the situation is different,
> because it is not yet enabled in trunk.
> 
>   I had some local changes on stadler.debian.net machine,
> but this machine did not re-appear after a machine upgrade that
> probably did not work out as expected ...
> 
> 
> Pierre
> 
> 
> Le 09/12/2018 à 22:33, Peter Popov a écrit :
>> Hi All
>>
>> I noticed that the trunk version of the compiler has a Sparc64/Linux target. 
>> Did a little work to create a Sparc64/Solaris target. Had little luck 
>> producing an executable.
>>
>>  
>>
>> What is the current status of Sparc64/Linux?
>>
>>  
>>
>> Any interest in uploading the Sparc64/Solaris patches (could not produce an 
>> working executable)?
>>
>>  
>>
>> Peter Popov
>>
>>  
>>
>>  
>>
>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 
>> 10
>>
>>  
>>
>>
>> ___
>> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>>
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Sparc64 on solaris

[Pierre Muller]

  Did you check if the snapshots are working?

ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/sparc64-linux/

contains both native snapshots and cross-snapshots created on a x86_64-linux 
machine.

  For sparc64-solaris, the situation is different,
because it is not yet enabled in trunk.

  I had some local changes on stadler.debian.net machine,
but this machine did not re-appear after a machine upgrade that
probably did not work out as expected ...


Pierre


Le 09/12/2018 à 22:33, Peter Popov a écrit :
> Hi All
> 
> I noticed that the trunk version of the compiler has a Sparc64/Linux target. 
> Did a little work to create a Sparc64/Solaris target. Had little luck 
> producing an executable.
> 
>  
> 
> What is the current status of Sparc64/Linux?
> 
>  
> 
> Any interest in uploading the Sparc64/Solaris patches (could not produce an 
> working executable)?
> 
>  
> 
> Peter Popov
> 
>  
> 
>  
> 
> Sent from Mail  for Windows 10
> 
>  
> 
> 
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] max_operands for AVR after rev 40170

[Pierre Muller]

Le 02/11/2018 à 11:06, Christo Crause a écrit :
> I've noted that r.40170 defines MAX_OPTS_2 for AVR in aoptutils.pas. Should 
> the constant  max_operands in avr/cpubase.pas not also be changed to 2 to be 
> internally consistent?  If so then I can adapt avr/raavr.pas to be consistent 
> with a maximum number of operands of 2.

  Hi Christo,

I simply checked the value of maxops constant for the different CPUs:

$ grep -iw maxops */*pas
aarch64/aoptcpub.pas:  MaxOps = 4;
arm/aoptcpub.pas:  MaxOps = 4;
avr/aoptcpub.pas:  MaxOps = 2;
i386/aoptcpub.pas:  MaxOps = 3;
i8086/aoptcpub.pas:  MaxOps = 3;
jvm/aoptcpub.pas:  MaxOps = 2;
m68k/aoptcpub.pas:  MaxOps = 3;
mips/aoptcpub.pas:  MaxOps = 3;
powerpc/aoptcpub.pas:  MaxOps = 5;
powerpc64/aoptcpub.pas:  MaxOps = 5;
riscv32/aoptcpub.pas:  MaxOps = 5;
riscv64/aoptcpub.pas:  MaxOps = 5;
sparcgen/aoptcpub.pas:  MaxOps = 3;
x86_64/aoptcpub.pas:  MaxOps = 3;

As I found only avr and jvm having a value of 2,
I defined the macro MAX_OPTS_2 (which by the way should rather be renamed 
MAX_OPS_2...)

max_operands seems to be ddeclared in cpubase units:
$ grep -i "max_operands *=" */*pas
aarch64/cpubase.pas:  max_operands = 6;
arm/cpubase.pas:  max_operands = 6;
avr/cpubase.pas:  max_operands = 4;
jvm/cpubase.pas:  max_operands = 2;
llvm/llvmbase.pas:max_operands = ((-ord(cpubase.max_operands<=7)) and 7) or 
((-ord(cpubase.max_operands>7)) and cpubase.max_operands);
m68k/cpubase.pas:  max_operands = 4;
mips/cpubase.pas:  max_operands = 4;
powerpc/cpubase.pas:  max_operands = 5;
powerpc64/cpubase.pas:  max_operands = 5;
riscv32/cpubase.pas:  max_operands = 5;
riscv64/cpubase.pas:  max_operands = 5;
sparcgen/cpubase.pas:  max_operands = 3;
x86/cpubase.pas:  max_operands = 4;

But you can see that the numbers are quite different...
aarch64:6/4!
arm:6/4!
i3864/3 (the 4 is common to i386,x86_64 and i8086 from x86/cpubase 
unit)
i8086   4/3, as for i386
jvm 2/2, OK!!
m68k4/3
mips4/3
powerpc 5/5, OK!!
powerpc64   5/5, OK!!
riscv32 5/5, OK!!
riscv64 5/5, OK!!
sparcgen3/3, OK!!
x86_64  4/3, as for i386

Hopefully someone else can explain that discrepancy,
I have no idea why this exists,
it might be simply related to the CPU instructions
with most parameters that are considered for optimization!

Pierre


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] r40027 break. Patch available.

[Pierre Muller]

Hi all,

Le 25/10/2018 à 07:50, J. Gareth Moreton a écrit :
> Hi everyone,
> 
> As Pascal Riekenberg reported, the recent update to the trunk causes FPC to 
> not compile on some platforms, specifically x86_64.  I have provided what is 
> hopefully a long-term fix over here: 
> https://bugs.freepascal.org/view.php?id=34456
> 
> Considering this is a critical bug, I request that the patch be tested by 
> others as soon as is practical to ensure it is up to standard and fixes the 
> problem.


  I was he cause of this compilation error,
and I apologize for this, the problem whould
be fixed by commit # 40028.

In the hope that it willl fix the problem for all targets.


Pierre Muller
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Fix CamelCase in unit and method names

[Pierre Muller]

Le 23/03/2018 à 23:12, Michael Van Canneyt a écrit :
> 
> 
> On Fri, 23 Mar 2018, Sven Barth via fpc-devel wrote:
> 
>> R0b0t1 <r03...@gmail.com> schrieb am Fr., 23. März 2018, 16:07:
>>
>>>>
>>>> IMHO preferably not the unit names (as in 'unit XxX') - with case
>>>> sensitive file names on Unix, this change might increase time for
>>>> searching the respective file (somewhat). Obviously, all further
>>>> references of the unit (as in 'SysUtils.Execute') should be fine.
>>>>
>>>
>>> I don't understand how it would increase the search time. I believe
>>> what happens is all names are converted to lowercase for the search,
>>> as in the strings taken from the user or their files and the names
>>> taken from the disk are both converted to lower case before
>>> comparisons are made.
>>>
>>
>> FPC first looks for the unit with the name as is, then lower case and
>> finally upper case.
> 
> Yes, but this is done in memory in the directory cache.

But isn't the problem more that if you have a SysUtils.pp unit
and a sysutils.pp both in your unit search path,
on a case sensitive partition, it might now find SysUtils.pp before sysutils.pp
and end up with some total different source?


Pierre Muller

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 3.0.2 for SPARC

[Pierre Muller]

Le 05/05/2017 à 13:00, Mark Morgan Lloyd a écrit :
> This is something that was discussed on the FPC-Pascal ML but it died.
> 
> I am able to build installation bundles for SPARC running Linux (Debian) 
> and Solaris (OpenSXCE). The fp IDE works but doesn't have libgdb 
> support, and I've got limited time to struggle up the learning curve. 
> Would these be of use for the downloads area, which at present only has 
> 2.6.2 and 2.4.2 respectively?
> 

  I have uploaded the files that Mark sent to me
to both main ftp server and SourceForge,
and adapted html pages.

  You should now be able to download 3.0.2 sparc-solaris and sparc-linux
installation tar files by following the links starting at:


https://www.freepascal.org/download.var

  If you encounter any problems, to download the files or to
install the new 3.0.2 sparc compiler, please let us know!


Thanks Mark!


Pierre
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 3.0.2 for SPARC

[Pierre Muller]

Le 07/05/2017 à 16:35, Mark Morgan Lloyd a écrit :
> On 05/05/17 16:00, Pierre Muller wrote:
> 
>>   You probably need to add the -Xn option into the makepack script!
> 
> Thanks for the pointer as to where it goes: those last words stopped me 
> spending days looking for the appropriate makefile :-)
> 
> If I do this it builds successfully:
> 
>   *sunos*) MAKE=gmake
>  EXTRAOPT='-Xn'
>   # Use GNU tar if present
>   if [ "`which gtar`" != "" ]; then
> TAR=`which gtar`
>   fi
>   ;;
> 
> Should I raise a bug on Mantis for this? can anybody comment on what 
> impact this would have on the Intel target for Solaris?
> 
> I'll add a note to the existing stuff on the Wiki.

  I committed the patch below,
which basically restricts your change to native compilation.


Pierre



muller@gcc45:~/pas/trunk$ svn diff -c 1302
Index: install/makepack
===
--- install/makepack(revision 1301)
+++ install/makepack(revision 1302)
@@ -45,6 +45,10 @@
   ;;

  *sunos*) MAKE=gmake
+ # Use system linker if on solaris machine
+ if [ "$SOURCEOS" == "solaris" ]; then
+   EXTRAOPT="-Xn"
+ fi
  # Use GNU tar if present
  if [ "`which gtar`" != "" ]; then
TAR=`which gtar`
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Object checks

[Pierre Muller]

Le 06/05/2017 à 09:56, C Western a écrit :
> On 05/05/17 12:54, Pierre Muller wrote:
>>
>>I applied a patch in commit 36113 to trunk that
>> substitutes RunError with HandleError.
>> It has been applied to three functions:
>> fpc_help_destructor, fpc_check_object and fpc_check_object_ext
>>
> Thank you for doing this. In the meantime I put a slightly updated patch 
> in 31745 in the bug tracker, which gives slightly better stack traces.
  Hi Colin,

  thanks for this improvement,
I committed it in rev 36134.

Pierre
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 3.0.2 for SPARC

[Pierre Muller]

> gmake NOGDB=1 OPT='-V3.0.0 -O- -gl -Xn -vt' all
> 
> but the full build is giving me a linking error.
> 
> Following Pierre's instructions I'm using
> 
> CHECKLIBGDB=no install/makepack
> 
> which is eventually failing with
> 
> /usr/local/src/fpc/fpcbuild-3.0.2/fpcsrc/compiler$ 
> /usr/local/bin/ppcsparc -Ur -Xs -O2 -n -Fusparc -Fusystems 
> -Fu/usr/local/src/fpc/fpcbuild-3.0.2/fpcsrc/rtl/units/sparc-solaris 
> -Fisparc -FE. -FUsparc/units/sparc-solaris -dRELEASE-dsparc -dGDB 
> -dBROWSERLOG  -Sew pp.pas
> 
> /usr/bin/gld:built in linker script:21: syntax error
> pp.pas(238,36) Error: Error while linking
> pp.pas(238,36) Fatal: There were 1 errors compiling module, stopping
> Fatal: Compilation aborted
> 
> I'm pretty sure I've come across this one before and that the cause is 
> something like the wrong linker being invoked by the makefile, leave it 
> with me so I can go through my notes.
> 
> I'll be back ;-)

  You probably need to add the -Xn option into the makepack script!

Pierre
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 3.0.2 for SPARC

[Pierre Muller]

Hi Mark,

Le 05/05/2017 à 13:00, Mark Morgan Lloyd a écrit :
> This is something that was discussed on the FPC-Pascal ML but it died.
> 
> I am able to build installation bundles for SPARC running Linux (Debian) 
> and Solaris (OpenSXCE). The fp IDE works but doesn't have libgdb 
> support, and I've got limited time to struggle up the learning curve. 
> Would these be of use for the downloads area, which at present only has 
> 2.6.2 and 2.4.2 respectively?

  Yes it would be very nice,
libgdb missing for IDE is really not a big deal...

Please let me know how you can send me the files.

Thanks again,

Pierre
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Object checks

[Pierre Muller]

Hi Colin,

Le 30/04/2017 à 10:53, C Western a écrit :
> If I may, a couple of queries about code generated for object checking 
> when range checks are on (-Cr):
> 
> An explicit check for nil is generated, which seems redundant, as any 
> attempt to use the value will generate a SIGSEGV anyway on most 
> platforms, or am I missing something?
> 
> If the fpc_check_object fails it calls RunError, which forces the 
> application to terminate, whereas a SIGSEGV will raise an exception and 
> give the user the option of continuing (at least in an LCL app). Is 
> there any reason why fpc_check_object does not call HandleError?

  Thanks for the suggestion,

  I applied a patch in commit 36113 to trunk that
substitutes RunError with HandleError.
It has been applied to three functions:
fpc_help_destructor, fpc_check_object and fpc_check_object_ext



Pierre
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] mips-linux and mipsel-linux snapshots available

[Pierre Muller]

Due to numerous question about mips/mipsel linux,
I decided to try to generate snapshot for those systems.
It finally worked (with OPT=-O- option added)

You can test them at:
ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/mipsel-linux/
or
ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/mips-linux/


Please give feedback,


Pierre Muller

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: [fpc-devel] custom ThreadManager and MemoryMutexManager for hard realtime

[Pierre Muller]

  To complement what Jonas said,
if there is no room in the currently allocated 
Free Pascal heap, the system memory manager calls the 
system specific function SysOSAlloc 
defined in rtl/unix/sysheap.inc, for unix systems.
  This in turn calls Fpmmap function 
which does a syscall syscall_nr_mmap...
code is in rtl/linux/ossysc.inc.

  None of these two functions are function variables,
which would mean that you need to modify the rtl,
make SysOSAlloc return nil everytime,
alloc enough memory at startup to avoid
running out of memory within a run,
and recompile it if your memory manager still
calls the standard RTL underneath.

  Of course, if your own memory manager does not 
call the standard one, you should be safe.

Pierre Muller
 

 -Message d'origine-
 De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
 boun...@lists.freepascal.org] De la part de Jonas Maebe
 Envoyé : Wednesday, January 06, 2010 3:38 PM
 À : FPC developers' list
 Objet : Re: [fpc-devel] custom ThreadManager and MemoryMutexManager for
 hard realtime
 
 
 On 06 Jan 2010, at 15:25, Stefan Kisdaroczi wrote:
 
  AFAIK the RTL allocs the heap on app startup, or on thread-creation
  with 2.4.0.
  In my code im using getmem() to alloc mem from the heap, this will
  not generate
  syscalls because the heap is already allocated and the RTL has its
  own MemoryManager.
 
 This is not entirely correct: while the rtl does pre-allocate some
 memory from the system on startup, it can still allocate more later if
 necessary, and it can also free memory back to the system.
 
 
 Jonas
 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-devel

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: [fpc-devel] fp IDE with libgdb

[Pierre Muller]

True in principle,
but XML library used for GDb
is expat, so you should
add {$linklib expat.a}
in gdbint.pp

It is generally easier to 
first try to compile
testgdb executable 
in packages/gdbint directory.

Once this executable links without errors,
with the same libraries, it should
also work for the IDE.

Pierre Muller

 -Message d'origine-
 De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
 boun...@lists.freepascal.org] De la part de Felipe Monteiro de Carvalho
 Envoyé : Wednesday, October 07, 2009 1:28 PM
 À : FPC developers' list
 Objet : Re: [fpc-devel] fp IDE with libgdb
 
 On Mon, Oct 5, 2009 at 10:27 AM, Mark Morgan Lloyd
 markmll.fpc-de...@telemetry.co.uk wrote:
  Linking testgdb
  /usr/local/lib/fpc/2.2.4/units/powerpc-linux/gdbint/gdbint.o: In
 function
  `GDBINT_INITLIBGDB':
  gdbint.pp:(.text+0x1a60): undefined reference to `error_init'
  libgdb.a(xml-support.o): In function `gdb_xml_use_dtd':
  /usr/local/src/fpc/libgdb/gdb-6.7.1/gdb/xml-support.c:522: undefined
  reference to `XML_SetParamEntityParsing'
  /usr/local/src/fpc/libgdb/gdb-6.7.1/gdb/xml-support.c:524: undefined
  reference to `XML_SetExternalEntityRefHandler'
  /usr/local/src/fpc/libgdb/gdb-6.7.1/gdb/xml-support.c:528: undefined
  reference to `XML_UseForeignDTD'
 
 If libgdb wants more functions then just link more libraries to get
 the necessary functions until it is happy.
 
 Find out which library offers the routines it wants and link them to
 your application too. I would guess it wants libxml, so something like
 {$linklib xml} or {$linklib libxml)
 
 --
 Felipe Monteiro de Carvalho
 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-devel

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Beta Dos testers for 2.2.0a wanted

[Pierre Muller]

  As you might know, there is no Dos
distribution of 2.2.0 release yet.
  There are several reasons for this, but 
I am started a small branch that tries to 
get the minimal changes to get a usable Dos
release.

  This branch is on the svn repository under fixes_2_2_0_dos.
Using the 2.2.0 release sources to create a
Dos distribution results in a program that does not work at all
under raw Dos, mainly because of the fact that
you need to look for '*.*' to get all files under Dos
and '*' only lists files without extensions.

  The other more subtle problem seems to be related to
problems in the IDE while debugging when compiling with
optimizations set to -O2.

 Another problem was that the install.dat file,
used by the installer, was out of sync with the current
sources at release date. As this file is only used for
go32v2 and os2 and nobody really tried to generate them,
it got unnoticed.

  I uploaded to ftp.freepascal.org
under ftp://ftp.freepascal.org/pub/fpc/beta/2.2.0a/go32v2
separate zip files, with install.exe and install.dat
files.

  The directory shortsep is for people
adventurous enough to try to test the installation
of the beta dist onto a system without LFN support.
The separate directory is for people who would like
to test the beta dist on Windows 95/98/Me/2000/XP/Vista
or on any Dos distribution having LFN or with
a TSR that adds LFN support on your favorite Dos 
system.

  I would like to get feedback on the stability of the
IDE (especially while debugging executables).
  If people are willing to help, it would be great to have
persons that would try to do a complete rebuilding
of the beta dist of their Dos system. Beware that you will need
quite a lot of free disk space for that...

  I am not really sure that using the sources included
in the same directory will work for that purpose, but 
attempts and failures should be reported on that list.

  The first step would be to install the sources,
and try to recompile everything by doing a
'make all OPT=-gl -O- -dDEBUG UPXPROG=echo'
at source level.
  You should basically regenerate the same executable
(alltough the will not match completely as the date
is written somewhere inside the debugging information,
together with absolute pathes to the sources...)

  If someone is really willing to try to inspect deeper,
doing a second build, removing the -O- option
and check if the IDE generated that way behave 
as smoothly as when I tested the IDE compiled with 
-O-.

  By the way, the IDE being compiled with -dDEBUG, should have the 
ability to switch back and forth between graphic and text mode
and thus support debugging for graphic Dos application,
provided that you are only using modes defined in the Graph unit.

  For all answers, please state in the subject 
that you are usng the beta 2.2.0a for Dos,
I am not reading all threads of this mailing list.


Pierre Muller



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] patch for heaptrc

[Pierre Muller]

 Pierre Muller schreef:
 Attached patch add the same sanity check for the frame pointer in
 TraceReAllocMem as
 already is in TraceGetMem. It fixed crashes of Lazarus on win64 when
 compiled with
 heaptrc.

 Tested with fpc 2.1.3. fpc 2.3.1 is currently broken on win64, see mail
 of
 8 April.
 I applied that to trunk,
 is it needed fro fixes_2_2 branch also?

 Yes, please.
Merged in fixes_2_2 rev 7115.

Pierre


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] patch for heaptrc

[Pierre Muller]

 Attached patch add the same sanity check for the frame pointer in
 TraceReAllocMem as
 already is in TraceGetMem. It fixed crashes of Lazarus on win64 when
 compiled with
 heaptrc.

 Tested with fpc 2.1.3. fpc 2.3.1 is currently broken on win64, see mail of
 8 April.
I applied that to trunk,
is it needed fro fixes_2_2 branch also?

Pierre
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] arm-wince errors

[Pierre Muller]

 Michael Schnell schrieb:


 I guess not much help is needed. Just open the Debugger Options and
 select GNU debugger through SSH (gdb), would be my first guess.
 Never done this though.


 Great (sorry for my being cynical :-[ ) !

 So I gather that you are convinced that it does work as well PC-PC as
 PC-ARM (Linux and windows).


 At least Windows XP - WinCE works, see
 http://www.freepascal.org/wiki/index.php/WinCE_port

  I had a similar stuff working for a cross text mode IDE
linked with the m68k PDA using the emulator from Palm,
but this was with version 1.0.X
a looong time ago.

Pierre
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Nasm under FPC Go32v2

[Pierre Muller]

 Hi, I prepared some modifications for the 2.0.4 version to the
 ag386nsm.pas file which fixes the output of the strings (bug id 7210, but
 the patch in attachement now works against the old one) under this
 assembler, try the following code before and after its application with
 the command line fpc -al -Anasmcoff worldcrash.pas:

  The file you are changing is not go32v2 specific, thus
if a change is only for the go32v2 target, we need to
add a target test for the given change.

 program worldcrash;
 begin
 writeln('Hello, world!');
 end.

 These are the issues:
 - substitution of the .rodata with the .data section;
  Is this a general or go32v2 limitation of NASM?
 - avoiding of a double assignement of the LastSecType by the WriteSection,
 cosmetic;
 - correction of the #0 character with the db reserve operator and placing
 of the string in a single line, it is possible to clean;
  The problem is that very long line have problems with
editors (like fp for instance...) that is why the splitting was introduced,
I don't understand the advantage of removing that.

 - insert of the global key for the label of the string;
 Why is this glbal modifier needed?
 - correction of the skip of near sections in the cutobject, not related
 with the actual problem.

  Could you please explain the reason of that change?


Pierre Muller
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]intolerable sets incompatibility!

[Pierre Muller]

At 13:40 05/03/2003, Pavel V. Ozerski wrote:
Hello all,
I tried to use some set types as fields in database.
I would put into datebase a structure

 tInfo=packed record
  date:set of 1..36;
  hour:set of 0..23;
 end;

 Of cource, I must reserve correct count of bytes for database field.
 Therefore I checked SizeOf value for this structure. But I compared
 results of working of FPC-compiled, Delphi-compiled and
 VirtualPascal-compiled program that wrote this value. Results:
 Delphi and VP - 9 bytes, FPC - 36 bytes. I must conclude: using FPC
 for this databse should cause: 1) its unwarrantable bloating; 2)
 impossibility to use the same code in Delphi and in FPC (at least the
 same type definitions) to access this database. May be, the sets
 handling in FPC may be rewritten?

Please Pavel, 
you are very welcome if you want to do that.

But honestly, this is not a top priority of the core developper list
for the moment, so don't expect that this will be 
implemented in near future by one of us...

So, but sometiles, I prefer to disappoint you 
right away, rather than letting you hope for
something that has only little chance to happen
in a decent time distance.

Explicit typecasting will be your only way out of this incompatibility 
for now and for quite a while.

___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel