Re: [fpc-devel] Smart-linking on linux/x86-64

[Sergei Gorelkin via fpc-devel]

05/07/2022 09:39, Sven Barth via fpc-devel wrote:
Joost van der Sluis via fpc-devel > schrieb am Di., 5. Juli 2022, 00:17:



But my real issue is this: on Windows, using the internal linker, this
procedure is also omitted *with* Dwarf debug-data. As you implied.

The problem is, though, that the CFI-information (the FDE) is not
omitted. This is 'solved' in the internal linker by replacing the
address with 0. Gdb doesn't mind and I've adapted FpDebug so that it
allows this too, but this is still invalid, imho.

But as the FDE is written now, as 'one block', without any sections, I
don't see how the linker could omit the corresponding FDE.

Any suggestions? Is it possible to place every fde in it's own section
to solve this?


The problem is that *something* would need to reference the debug sections otherwise they are 
stripped as well. But as soon as they're referenced whatever code or data *they* reference is kept 
as well.
One of the better solutions might be to write these references as weak symbols (on systems that 
support this) so at least the data/function isn't kept around.
Or the section of the data/function would have to contain a reference to its corresponding debug 
entry so that it is kept around as long as the function/data is kept around...

How does GCC do this?



As far as I had studied this issue, ld essentially "decompiles" the monolithic FDE's from object 
files into internal representation, and then "compiles" it back, omitting information for the code 
that won't go into executable due to smartlinking. It also optimizes for size by using 8- and 16-bit 
offsets instead of 32-bit ones when possible.


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

Re: [fpc-devel] Exceptions on wiki

[Sergei Gorelkin via fpc-devel]

02.08.2018 20:13, J. Gareth Moreton wrote:

The information in the Wiki about how exception frames are set up is pretty nice. I didn't know that 
'raise' creates an exception frame for the procedure it appears in, but explains why it's often 
shipped off to another local procedure. Very useful information!


Implicit exception frames in procedures with 'raise' clause come from string manipulations that are 
used to compose non-trivial exception messages, not from the 'raise' itself.


Regards,
Sergei


True though, it's hard to generalise the performance impact of exception handlers and try...finally 
blocks, although I think the simple rule of thumb is that there is a performance hit no matter what 
you try.


Gareth aka. Kit


On Thu 02/08/18 06:54 , Sven Barth via fpc-devel fpc-devel@lists.freepascal.org 
sent:

Kirinn mailto:kir...@mooncore.eu>> schrieb am Mi., 1. 
Aug. 2018, 23:30:

Hi all,

Inspired by Gareth aka. Kit's infectious enthusiasm, and the recent long
discussion on exceptions on this list, I wrote up an article on
Exceptions on the FPC wiki. (Strangely enough we didn't have one 
before.)

http://wiki.freepascal.org/Exceptions

I hope it'll be useful, and not entirely inaccurate! Particularly the
part about performance. If a programmer knows exactly what each
exception statement inserts in the code, that should help in deciding
when to worry about the performance, and when to embrace the 
convenience.


Please note that you can't generalize the performance impact as it depends 
on the used exception
handling mechanism. By default FPC uses setjmp/longjmp which exhibit the 
behavior you described.
On Win64 however SEH is used which - in that platform - relies on metadata 
inside the binary to
mark the areas for a protected block (no matter whether it's for "except" or 
"finally"). On
Win32 with SEH enabled (which isn't the default currently) it is again 
different. And should we
decide to support DWARF exception frames that would again be different.

Regards,
Sven

___
fpc-devel maillist - fpc-devel@lists.freepascal.org 

http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel <">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] *** GMX Spamverdacht *** Re: Broken frac function in FPC3.1.1 / Windows x86_64

[Sergei Gorelkin via fpc-devel]

27.04.2018 17:14, Sven Barth via fpc-devel wrote:
Thorsten Engler > schrieb am Fr., 27. Apr. 
2018, 16:09:


Highest integer that fits in a Int64:

9223372036854775808

1e20:

1

__ __

Your Int is overflowing.

__ __

You can’t implement Frac by going through an Integer, that will never work. 
Except if you have
an integer that can hold 1.8E308 (which would be a 1024 bit integer, or 
thereabouts)


Yes, I saw that now as well, though it's even worse as the cvttsd2si instruction in fact only works 
with 32-bit integers.
That additionally means that Trunc() and Round() are broken for such values as well as they rely on 
the same kind of functions. Int() works because it doesn't have an SSE version.




That's true for i386. But on x86_64 cvt(t)sd2si instuctions can deal with int64 range, if 
destination register is a 64-bit one.


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

Re: [fpc-devel] Regarding issue/patch 0032637

[Sergei Gorelkin via fpc-devel]

29.11.2017 15:12, J. Gareth Moreton wrote:

Thanks Christo.

Apologies for 4 messages coming in at once.  I think there were a few technical 
glitches with the mailing
list.  Either way, I have submitted an updated patch to the bug report in 
question that corrects the stack
unwinding for Windows.  Any testing would be greatly appreciated (I'm not in a 
position to rigorously test
the code for Linux).

Yeah, I got a little emotional with Thaddy's response (which has since been 
deleted), partly because he
mocked me a bit for even attempting to use assembly language for optimisation. 
Granted, I tend to do more
low-level and mathematical programming than higher-level components, where 
assembler optimisation can really
pay dividends. Plus in a perverted way, I actually enjoy trying to squeeze 
another microsecond out of
running time!

Gareth aka. Kit.



I should have read and answered earlier, but better late than never.

The x86-64 target (actually, all targets except i386 and m68k) use concept of fixed stack. This 
means: all changes to the stack pointer are done at the beginning and at the end of procedure. 
Pushing something in the middle is illegal. The stack pointer itself needs to be aligned only at the 
point of calling another procedure. As a consequence, simple procedures that don't call other 
procedures and don't use nonvolatile registers can have the stack pointer misaligned by 8 bytes as 
it naturally is at the first instruction (such procedures don't need any SEH annotations at all, 
which is a way to simplify things).
Now, several first instructions where is stack pointer is changed and nonvolatile registers are 
saved is called prologue. It is delimited by .seh_endprologue directive and can be at most 255 bytes 
in size.
The advice given at forum to insert .seh_endprologue at the very beginning is plain wrong. 
.seh_endprologue must be the last SEH directive in procedure. Compiler probably needs to do more 
checks and reject SEH directives coming after .seh_endprologue.


Regards,
Sergei

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

Re: [fpc-devel] FillWord, FillDWord and FillQWord are very poorly optimised on Win64 (not sure about x86-64 on Linux)

[Sergei Gorelkin via fpc-devel]

01.11.2017 10:46, Sven Barth via fpc-devel wrote:
Am 01.11.2017 05:58 schrieb "J. Gareth Moreton" >:


Would it be worth opening up a bug report for this, with the attached 
assembler routines as
suggestions? I
haven't worked out how to implement internal functions into the compiler 
yet, and I rather clear
it with you
guys first before I make such an addition.  I had a thought that the simple 
routines above could
be used for
when compiling for small code size, while larger, more advanced ones are 
used for when compiling
for speed.


Improvements like these are always welcome. Two points however:
The Fill* routines are not part of the compiler, but of the RTL (the Pascal routines are in 
rtl/inc/generic.inc, the assembly ones reside in rtl/CPU/CPU.inc) and they aren't handled 
differently depending on the current optimization flags, so a one-size-fits-all is needed (look at 
e.g. the i386 ones).
I also think that you might need to handle memory that isn't correctly aligned for the assembler 
instructions (I didn't look at your routines in detail so I don't know whether they'd need to be 
adjusted for that). A check of the i386 routines will probably help here as well.




Another important thing to note is that all modifications to stack pointer and nonvolatile registers 
on x86_64 need SEH annotations in win64 and CFI annotations on linux/bsd. The former is available 
only in AT syntax, the latter is not supported.
This requierment, together with different parameter locations, makes writing assembler routines for 
x86_64 much more complicated than for i386. For this reason, existing assembler routines in RTL 
avoid using nonvolatile registers as much as possible.

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

Re: [fpc-devel] Is there a way to make Register Allocation inside of Interrupt Service Routines more efficient when using inline-assembler?

[Sergei Gorelkin]

21.08.2016 14:32, Michael Ring пишет:

Was getting high hopes for a moment...

@Sergej: I just started wondering on usage of fp registers, when I call a 
routine that uses floating
point I see that the fp registers are not marked as reserved by the compiler, 
what do you think?

The procedure below (test) uses $f0 and $f2 but they are not marked as 
allocated:

 # Register at,v0,v1,a0,a1,a2,a3,t0,t1,t2,t3,t4,t5,t6,t7,t8,t9,ra 
allocated
 jal P$TEST_$$_TEST
 nop
 # Register at,v0,v1,a0,a1,a2,a3,t0,t1,t2,t3,t4,t5,t6,t7,t8,t9,ra 
released

could this be a bug? (I have also modified 
tcpuparamanager.get_volatile_registers_fp to return [] so
i'd expect to see $f0..$f19 pushed to stack but I see nothing)

Could of course be me causing this bug, but I checked my diff to trunk, I have 
not knowingly changed
fp behaviour besides changing get_volatile_registers_fp

It's either a bug or unimplemented feature, not your fault. Currently calls allocate non-integer 
register types only if caller uses registers of that type itself. This is good for calls between 
procedures with same calling convention (i.e. equal sets of volatile registers), but not for calls 
where callee's set of volatile registers is larger than one of caller's.


But probably you can force 'use' of fp registers by adding one of them after 
'asm' block.

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

Re: [fpc-devel] Is there a way to make Register Allocation inside of Interrupt Service Routines more efficient when using inline-assembler?

[Sergei Gorelkin]

21.08.2016 13:25, Karoly Balogh (Charlie/SGR) пишет:



Well, one possible optimization would be to only save all volatiles if the
interrupt routine actually calls another function. Otherwise only save the
ones used by the current proc. This would allow some very small and very
fast interrupt functions, right? I'm not sure though if there's an easy
way to determine if there is a function call inside the function I'm
generating code for.

Maybe at the point of generating a function call, if the current proc is
an interrupt, mark all volatiles as used somehow?


What you suggest is already implemented for ages. Any call node allocates all volatile registers 
before doing the call and releases them afterwards, to indicate that these registers are modified by 
callee. The same is done when a call to helper function is generated at low level (see 
thlcg.g_call_system_proc). Furthermore, any call sets pi_do_call in current_procinfo.flags, to 
simplify checking the case.
There's no difference in processing calls between 'interrupt' and regular caller procedures. The 
difference only appears when generating caller's prologue/epilogue: a regular procedure won't save 
volatile registers even if they are used, but 'interrupt' one will save them because it considers 
all registers non-volatile.


The things are a bit trickier with inline assembler, because in general author may write anything 
there, and compiler does no deep checks. For this reason, an assembler block without a list of 
modified registers is historically considered equal to a call (i.e. modifies all volatile 
registers). An explicit list of modified registers overrides that behavior, however.


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

Re: [fpc-devel] Is there a way to make Register Allocation inside of Interrupt Service Routines more efficient when using inline-assembler?

[Sergei Gorelkin]

21.08.2016 12:06, Karoly Balogh (Charlie/SGR) пишет:

Hi,

On Sun, 21 Aug 2016, Michael Ring wrote:


So unless there is a way to find out which registers get used by a procedure
the only thing I can do to make interrupt routines as lean as possible is to
not use procedures in them if possible.


There is a way, of course. Seems like the MIPS CG was never updated to
depend on cgobj.g_save_registers/cgobj.g_restore_registers (or implement
these on its own), which takes into account which registers were used in
the procedure, and only saves those. See g_save/restore_registers
implementation in cgobj.pas for an inspiration how it should be done. The
m68k CG also reimplements these methods with some CPU-specific extensions.

It seems to use the old-style approach of just always saving all volatile
registers, and do everything on its own in g_proc_entry/exit which is the
old way (and also still used in some other CGs).

Not sure why it was never updated tho' for MIPS, I don't know anything
about the MIPS CG, and very little about the architecture itself. But it
sounds like this definitely the improvement you want.




It is actually the opposite way around. g_save_registers/g_restore_registers 
methods
are only used for first implemented targets (i386 and maybe m68k). All newer targets are written 
without calling them, since they are completely inappropriate to implement stack frame optimizations 
or push/pop-alike instructions for register saving.


MIPS codegenerator does check which registers are actually used. The issue is, a procedure with 
'interrupt' modifier must not modify any registers at all because it can be called asynchronously. 
As soon as an 'interrupt' procedure calls another (regular) procedure, the callee may modify any 
registers from volatile list, and the caller has no way to know which ones. Therefore, it has no 
other option than to save/restore all volatile registers.


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

Re: [fpc-devel] patch for rtl/linux/aarch64/cprt0.as

[Sergei Gorelkin]

06.10.2015 1:08, Edmund Grimley Evans пишет:

Clearly I don't really know what I'm doing with these start-up
files... but I found I needed this patch to build the Debian package
on arm64, so it's probably something for the AArch64 fixes branch.

I tried running the test suite with and without this patch, and it
appeared that webtbs/tw28089 went into an infinite loop without the
patch and passed with it, but I've never seen that test fail before,
and I don't see any connection with the patch, so I suspect there was
some kind of random race and this patch does not really make any
difference for the test suite.

By the way, the failures on powerpc and ppc64 look rather as if they
might be start-up-file-related:

https://buildd.debian.org/status/package.php?p=fpc=experimental

Edmund

--- a/rtl/linux/aarch64/cprt0.as
+++ b/rtl/linux/aarch64/cprt0.as
@@ -41,23 +41,23 @@ _start:
 init, fini, rtld_fini, stack_end) */
adrpx0,:got:PASCALMAIN
ldr x0,[x0,#:got_lo12:PASCALMAIN]
-   adrpx3,:got:__libc_csu_init
-   ldr x3,[x3,#:got_lo12:__libc_csu_init]
-   adrpx4,:got:__libc_csu_fini
-   ldr x4,[x4,#:got_lo12:__libc_csu_fini]
+   adrpx3,:got:_init_dummy
+   ldr x3,[x3,#:got_lo12:_init_dummy]
+   adrpx4,:got:_fini_dummy
+   ldr x4,[x4,#:got_lo12:_fini_dummy]
bl  __libc_start_main

/* This should never happen */
b   abort

-   .globl  _init
-   .type   _init,#function
-_init:
+   .globl  _init_dummy
+   .type   _init_dummy,#function
+_init_dummy:
ret

-   .globl  _fini
-   .type   _fini,#function
-_fini:
+   .globl  _fini_dummy
+   .type   _fini_dummy,#function
+_fini_dummy:
ret

.globl  _haltproc


This is absolutely wrong thing to do. Replacing __libc_csu_init with a dummy routine effectively 
defeats the entire libc/ELF startup. While doing so can make simple fpc-only programs linked with 
libc appear as working, any more complex programs will experience very obscure and hard to debug 
errors as soon as they touch the stuff that is normally initialized at startup.


The inability to find symbol "_init" during linking is typically caused by missing gcc (_init comes 
from crtbegin.o which belongs to gcc package, while another startup file crti.o belongs to libc 
package, or vice versa - I don't remember exactly), or by improperly installed fpc (it cannot find 
the crtbegin.o and other startup files).
I don't know exactly why FPC had chosen such dirty hack to hide this issue early in its history, but 
once it was used for one target, it became copy-pasted to many other targets as well. But stopping 
this practice is the good thing to do.


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

Re: [fpc-devel] Linux assembler start-up: rtl/linux/*/*.as

[Sergei Gorelkin]

28.05.2015 10:49, Marco van de Voort пишет:

In our previous episode, Edmund Grimley Evans said:


- How to do the equivalent of C longjmp in Pascal, used in
   x86_64/gprt0.as, for example?


There are fpc_longjmp and fpc_setjmp symbols but they are related to
exception handling. In an emergency, simply asm jmp $x end;

It is not an emergency case. Libc expects 'main' to return and then executes finalization code. 
FPC's PASCALMAIN terminates the process and does not return. So in order to get correct library 
finalization (including profiling with grpof) we have to simulate a return using something like longjmp.
It's basically a dirty hack. A much cleaner solution could be to change code generation so it calls 
FPC_LIB_EXIT instead of FPC_EXIT at the end of PASCALMAIN (so that _haltproc is not called and 
PASCALMAIN normally returns), and call _haltproc explicitly in code of prt0.as. But whoever goes for 
that will have to change and test all startup files for all targets, which is pretty time-consuming.


Regards,
Sergei

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

Re: [fpc-devel] about commit r29324

[Sergei Gorelkin]

28.12.2014 17:36, Michael Van Canneyt пишет:



On Sun, 28 Dec 2014, Mattias Gaertner wrote:


Hi,

forwarded from Zeljko:

It's about fpc issue
http://bugs.freepascal.org/view.php?id=26370

It seems that TVariantArrayIterator.AtEnd loops for all Dims for no reason, so 
have
impact on performance.

*current implementation*
function TVariantArrayIterator.AtEnd: Boolean;
var
  i : sizeint;
begin
  result:=false;
  for i:=0 to Pred(Dims) do
if Coords^[i] = Bounds^[i].LowBound + Bounds^[i].ElementCount then
  result:=true;
end;

*optimized implementation*
function TVariantArrayIterator.AtEnd: Boolean;
var
  i : sizeint;
begin
  result:=false;
  for i:=0 to Pred(Dims) do
if Coords^[i] = Bounds^[i].LowBound + Bounds^[i].ElementCount then
begin
  result:=true;
  break;
end;
end;


Or, better yet

var
   i : sizeint;
begin
   Result:=false;
   I:=0;
   While (Not Result) and (I=Pred(Dims)) do
 begin
 Result:= Coords^[i] = Bounds^[i].LowBound + Bounds^[i].ElementCount;
 Inc(I);
 end;
end;

People really don't seem to get booleans, and why they scorn While is beyond 
me. All these ugly
break statements :(

You may optimize even more by calculating Max:=pred(dims) once and doing I=Max;


Actually, in this particular case performance optimizations are pretty useless:
- TVariantArrayIterator.AtEnd method is called just once to decide whether it is necessary to 
iterate the array. Its usage is not typical for iterators, where such methods are called in a loop.
- To return False, it has to iterate all dimensions. After that, iterating the data of variant array 
will take orders of magnitude more time.
- Early exit can happen only for arrays with zero-sized dimension, which is basically invalid and 
indicates programmer's mistake elsewhere.


Regards,
Sergei

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

Re: [fpc-devel] CMem allocator memory alignment experiment

[Sergei Gorelkin]

19.11.2014 15:16, Marco van de Voort пишет:

In our previous episode, Mark Morgan Lloyd said:

introduces a very significant performance overhead;


Linux also does this.


On some but by no means all platforms. I'm specifically trying to
highlight the fact that on SPARC, Solaris can fix alignment issues (at a
price) but Linux doesn't try to. I don't know to what extent there are
comparable issues on other platforms (in particular x86_64) for which
both Solaris and Linux are implemented.


On PPC (603), Linux did, but netbsd didn't :-)  Though that is 1.9.0 times
experience and thus slightly dated.


On mips-linux, I observe no crashes when doing unaligned access with integer instructions, but it 
still crashes upon unaligned access using floating-point instructions.


Sergei

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

Re: [fpc-devel] RTL: high CPU load in heap manager

[Sergei Gorelkin]

11.11.2014 12:35, Jonas Maebe пишет:

On 11/11/14 10:28, Adriaan van Os wrote:

Jonas Maebe wrote:

On 10/11/14 18:47, Karoly Balogh (Charlie/SGR) wrote:

It's remove_freed_fixed_chunks(). Can someone explain to me under what
condition this code is triggered very often and/or could take long to
execute (there's a loop in there)?


This was reported earlier too, but I couldn't reproduce it:
http://bugs.freepascal.org/view.php?id=18079 (especially comment 47405
by Sergei).


I suggest to use cmem and compare the results.

I will also note that malloc uses mremap


None of that would explain the differences experienced in the referred
bug report, because we don't use mremap-like functionality on any
platform at this time. The issue there appears to be a corner case that
makes the heap manager reformat/free/reallocate its internal heap blocks
all the time on some systems, while on other systems it won't do that
even though it's presented with exactly the same memory
allocation/reallocation pattern.

This behavior apparently depends on all memory serviced by memory manager, including blocks 
allocated (and maybe also freed) during RTL initialization. That's why it differs between targets, 
and that's why the issue 18079 was no longer reproducible after time. Most probably some (unrelated) 
change was made to RTL initialization code, which also changes the pattern in user code that is 
required to reproduce issue.


Regards,
Sergei

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

Re: [fpc-devel] Masm

[Sergei Gorelkin]

07.11.2014 17:01, Pierre Free Pascal пишет:

   The is no COFF magic.
the first 2 bytes indicate normally a MACHINE type.

   The files I produced start etiher by:
0x8664 indicating a x86 coff header
or
0x014c indicating a i386 coff header.

Nevertheless,
0x is also listed as IMAGE_FILE_MACHINE_UNKNOWN

Could it be that your coff object only contains raw data,
so that it is usable on different formats?

After some searching, I think that the
answer to your problem is here:
http://llvm.org/docs/doxygen/html/structllvm_1_1COFF_1_1BigObjHeader.html

Your header looks like a BigObjHeader
This means that the object is prepared to handle relocation that are not in
the 4-byte
range... A feature that Free Pascal indeed does not support IIRC...

   There is probably an option somewhere to use normal 32-bit relocation type
objects in you Visual C++ configuration, unless you really need those 64-bit
relocations...

Even if this issue is resolved, linking together binutils-compatible and VC-compatible COFF files is 
next to impossible, due to significant differences in processing of COMDAT sections, debug 
information, section naming, etc.


Sergei

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

Re: [fpc-devel] Registers allocation technique

[Sergei Gorelkin]

30.09.2014 23:34, Sven Barth пишет:

On 30.09.2014 18:37, Lag Programming wrote:

1) Unless a function calls another function, the function result
register will always be in rax. Calling for inlined functions doesn't
change this behaviour as it's not a real function call.


RAX will only then be used for the function result when it is really needed 
(e.g. the last
assignment in a function).


To somewhat clarify: the reqirement is to place result into RAX at the function exit point. This is 
unrelated to assignments to the 'result' variable in code.


 Before that the compiler might reuse RAX as it pleases.
Likewise, the value of 'result' may be placed into any register or even to 
memory.

Regards,
Sergei

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

Re: [fpc-devel] MIPS big-endian program starts but does nothing

[Sergei Gorelkin]

09.09.2014 9:53, Sven Barth пишет:

On 08.09.2014 22:54, Michael Ring wrote:

This smells like a problem I had on pic32. In my case the pic32 chips do
not have a floating point unit and the processor creates an illegal
instruction (or something similar) exception.

I solved this for me by patching out the call to the hardware
coprocessor when softfpu is selected.


Which should be the correct approach for softfpu anyway. Afterall the premise 
of softfpu is that
there is no hardware FPU to use and thus corresponding CPU instructions are 
useless (or as it seems
in this case lead to nothing).



This patch is correct only if the goal is do disable floating-point completely. If the goal is to 
have floating-point calculations available using emulation, then the entire procedures SysInitFPU 
and SysResetFPU together with {$define FPC_SYSTEM_HAS_SYSRESETFPU} and {$define 
FPC_SYSTEM_HAS_SYSINITFPU} must be disabled. Doing so will cause softfpu-specific routines from 
generic.inc to be used.


I also wonder what is the correct way to generate code that calls softfpu:
1) -SfSOFTFPU
2) -CfSOFT
3) -Ce
?

Regards,
Sergei

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

Re: [fpc-devel] MIPS big-endian program starts but does nothing

[Sergei Gorelkin]

09.09.2014 13:19, Sven Barth пишет:

Am 09.09.2014 08:53 schrieb Sergei Gorelkin sergei_gorel...@mail.ru
mailto:sergei_gorel...@mail.ru:
 
  09.09.2014 9:53, Sven Barth пишет:
 
  On 08.09.2014 22:54, Michael Ring wrote:
 
  This smells like a problem I had on pic32. In my case the pic32 chips do
  not have a floating point unit and the processor creates an illegal
  instruction (or something similar) exception.
 
  I solved this for me by patching out the call to the hardware
  coprocessor when softfpu is selected.
 
 
  Which should be the correct approach for softfpu anyway. Afterall the 
premise of softfpu is that
  there is no hardware FPU to use and thus corresponding CPU instructions are 
useless (or as it seems
  in this case lead to nothing).
 
 
  This patch is correct only if the goal is do disable floating-point 
completely. If the goal is to
have floating-point calculations available using emulation, then the entire 
procedures SysInitFPU
and SysResetFPU together with {$define FPC_SYSTEM_HAS_SYSRESETFPU} and {$define
FPC_SYSTEM_HAS_SYSINITFPU} must be disabled. Doing so will cause 
softfpu-specific routines from
generic.inc to be used.

Well, according to Reinier's test at least the route seems to be correct. So we 
need to ensure that
softfpu code for MIPS works correctly.

  I also wonder what is the correct way to generate code that calls softfpu:
  1) -SfSOFTFPU
  2) -CfSOFT
  3) -Ce
  ?

I only know -CfSOFT and that is what I use for m68k. -Ce likely only does the 
same as -CfSOFT, but I
don't know what -SfSOFTFPU is supposed to do.

Well, for m68k you can omit -CfSOFT and nothing will change, because currently nothing else is 
supported there.
As for -Ce, the compiler code sometimes checks for it (cs_fp_emulation in 
current_settings.moduleswitches), sometimes for -CfSOFT (current_settings.fputype=fpu_soft), 
sometimes for both. That's why I wonder.
-SfSOFTFPU is for embedded targets where it enables softfpu feature, for non-embedded targets it 
is assumed to be permanently present (?), but again it's unclear if this feature replaces hardware 
FPU (if present) or appends to it.


Regards,
Sergei

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

Re: [fpc-devel] MIPS big-endian program starts but does nothing

[Sergei Gorelkin]

09.09.2014 14:33, Michael Ring пишет:

Sergei, I have reworked the patch based on your comment:

http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revisionrevision=28634

Do you think this is solved better now?

No, my point was that routines SysInitFPU and SysResetFPU from inc/generic.inc must be called 
instead of ones in mips/mips.inc. Therefore changes to fpc_cpuinit aren't necessary.


Regards,
Sergei

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

Re: [fpc-devel] Which platforms have internal linkers

[Sergei Gorelkin]

07.09.2014 20:22, Marco van de Voort пишет:

In our previous episode, Sven Barth said:

others? (Related: how can one find out/is there a list somewhere?)
(Helps me update my ego-boosting fpcup cross compiler conversion table :) )


Linux has an internal linker, but it's AFAIK not yet the default one.
All the Windows platforms (i386-win32/-wince, x86_64-win64, arm-wince
and *-nativent) use the internal linker.


Afaik in trunk also go32v2, and if default is determined by order of
registration, it is not default either.


It does not depend on registration order: an internal linker is always a default one. For this 
reason, internal ELF linkers are not yet registered and cannot be used without modification of 
compiler code.


And yes, on go32v2 the internal linker enabled and used by default.

Regards,
Sergei

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

Re: [fpc-devel] MIPS big-endian program starts but does nothing

[Sergei Gorelkin]

06.09.2014 14:53, Reinier Olislagers пишет:

On 06/09/2014 12:20, Mark Morgan Lloyd wrote:

I think the previous discussion wound down with the consensus that the
distro had custom libraries, possibly derived from ulibc, and that the
compiler etc. would have to be specially built for those. I was hoping
to set a Qemu-based system to investigate, but didn't get anywhere due
to other commitments.


Ok. It's running openwrt (also so that may well be the case; however I
copied over [1] the libs [2] from the device to my desktop, so that
should be a step in the right direction but presumably I need to
match the cross binutils [3] ld with the uclibc ld one?!?

Also tested with fpc at
ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/mips-linux/
which (perhaps unsurprisingly given the above) shows the same problem.

The reason could be that uclinux kernel passes argc,argv and envp on startup different to regular 
linux, which is not yet supported for mips targets.


Regards,
Sergei

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

Re: [fpc-devel] fpc libraries do not work in freeBSD...

[Sergei Gorelkin]

05.08.2014 22:02, Sven Barth пишет:

Am 05.08.2014 15:35 schrieb Marco van de Voort mar...@stack.nl 
mailto:mar...@stack.nl:
  But the FPC version has these symbols in the main program, maybe you must
  make sure that those (operatingsystem*) systems are available from the
  mainprogram too and preloaded with the proper values.

The main program should not need to do anything here. It's more likely that 
there is a problem in
our FreeBSD startup files for libraries.

FreeBSD loader does not pass argc,argv and envp to shared library initialization procedure, like it 
happens on Linux. Since FPC does not have a shared RTL, such hack with exporting symbols from 
executable is likely an only way to initialize RTLs compiled into shared libraries.


However starting from version 9.2 IIRC, FreeBSD loader looks more like Linux one, but it passes 
argc,argv and envp only to initialization procedures pointed at by DT_INIT_ARRAY, not to one pointed 
at by DT_INIT. I.e. fixing the issue requires changes to startup files/link scripts and means that 
no support for versions 9.2 will be available.


Regards,
Sergei


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

Re: [fpc-devel] errorr.msg wrong comment about the encoding (attn: Sergei)

[Sergei Gorelkin]

27.05.2014 22:07, Dmitry Boyarintsev пишет:

Hello,

The message file contains the comment (introduced in r13815)
#   Russian (utf-8) Language File for Free Pascal

The file is in fact CP 866. This (non) issue is small enough to skip the bug 
tracker.

I'm not sure that it's worth changing, the errorr.msg file was not independently edited, but is a 
transcoded copy of errorru.msg. Any manual change to it will be very likely overwritten on the next 
update.


Regards,
Sergei



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

Re: [fpc-devel] errorr.msg wrong comment about the encoding (attn: Sergei)

[Sergei Gorelkin]

27.05.2014 22:28, Dmitry Boyarintsev пишет:

I thought it would be good for consistency with other translation files:
errorpl.msg / errorpli.msg
errorhe.msg / errorheu.msg
...and sanity.
Could transcoder update the comment as well?


Stock one (the iconv program) does not change contents of the file.

Anyway, errorr.msg updated in r27819.

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

Re: [fpc-devel] Need heap manager -gv explanation

[Sergei Gorelkin]

28.04.2014 23:14, Petr Kristan пишет:

On Mon, Apr 28, 2014 at 06:12:18PM +0200, Tomas Hajny wrote:

On Mon, April 28, 2014 17:56, Mattias Gaertner wrote:

On Mon, 28 Apr 2014 17:20:17 +0200
Petr Kristan petr.kris...@epos.cz wrote:


Hi

I have some application with huge usage ReAllocMem and I found the big
performance difference if application is compiled with -gv option (cca
20x faster) then without -gv option.


-gv generates code for valgrind.
It should be slower with -gv.


I suspect fpc heap manager. Is possible to tune fpc heap manager?
Is some difference in heap manager if application is comiled with -gv or
without -gv option?


Use of valgrind requires/triggers use of cmem. Depending on the particular
use case (and potentially also the target platform), cmem may indeed be
faster.

Platform is x86_64 Linux.


Others would be better positioned for more detailed comparison among
various heap managers with regard to speed in different use cases, overall
memory requirements achieved by reuse of previously allocated memory, etc.

Reuse of previously allocated memory - it really can be my problem.
Here is about 200x call ReAllocMem increasing buffer from 4kB to 80MB.

It looks like as buffer is increasing ReAllocMem is slowing.
But I must verify this feeling.

-gv switch in command line disables the optimized i386 Move procedure (and that's basically the only 
thing it does), so it indeed should cause slowdown. Comments say that valgrind (some pretty old 
version of it) is unable to handle the optimizied Move code. In the meantime, valgrind was 
presumably fixed. At least since my involvement with FPC back in 2005 I was able to use valgrind to 
profile programs without any trouble, and without recompiling them with -gv.

So maybe it's time reconsider the action of -gv switch, or to remove it 
altogether.

Regards,
Sergei



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

Re: [fpc-devel] Need heap manager -gv explanation

[Sergei Gorelkin]

29.04.2014 13:00, Jonas Maebe пишет:

On 29/04/14 08:45, Sergei Gorelkin wrote:

-gv switch in command line disables the optimized i386 Move procedure
(and that's basically the only thing it does), so it indeed should cause
slowdown. Comments say that valgrind (some pretty old version of it) is
unable to handle the optimizied Move code. In the meantime, valgrind was
presumably fixed. At least since my involvement with FPC back in 2005 I
was able to use valgrind to profile programs without any trouble, and
without recompiling them with -gv.
So maybe it's time reconsider the action of -gv switch, or to remove it
altogether.


As Tomas mentioned, -gv also causes the use of the C memory manager. This is 
required because while
Valgrind also recognises mmap (as used by our memory manager), the result is 
not fine grained enough
to be of any use: Valgrind can't magically determine that our heap manager 
divides the mmap'ed
blocks into smaller allocations.

Regarding the SSE support in Valgrind: its assembler and disassembler have 
supported those
instructions since a long time, but memcheck didn't. In particular, it didn't 
support memory
initialisations using the movaps instruction. And at least in 2010, it still 
didn't:
https://code.google.com/p/nativeclient/issues/detail?id=2251

Maybe it's finally fixed in the latest Valgrind release (from October last 
year), as the changelog
lists various SSE fixes for optimized string copy routines (search for SSE in
https://lwn.net/Articles/572790/ )

Thanks for the explanation. I was mostly interested in performance data, using callgrind and 
cachegrind tools, not memcheck. Also I did not compile with SSE floating-point options. That 
explains why I didn't encounter the mentioned issues with cmem/SSE support.


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

Re: [fpc-devel] Need heap manager -gv explanation [tests]

[Sergei Gorelkin]

On 29.04.2014 14:37, Tomas Hajny wrote:


I don't know the reason of your difference, but no time necessary at all
(0 ms) for the valgrind variant looks very suspicious to me.

But compiling by kylix compiler, i get the same results as by fpc with
-gv option in linux.
This is the reason why I start to hunt where is my program to slow if
compiled by fpc against kylix.


Can't it be somehow related to the method used for measuring the time
under Linux? Is the result shown inside consistent to the overall time
necessary for the program run?

Time measurement appears to be correct. Strace shows that reallocation happens using mremap 
syscalls, which apparently rearranges pages within address space without actual moving the data. 
This indeed can be done with almost zero overhead, but is hardly portable.


Regards,
Sergei

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

Re: [fpc-devel] Need an elegant way to preset a specific memory area in elf files

[Sergei Gorelkin]

23.04.2014 12:34, Michael Ring пишет:

Thanks,
but does not solve the problem, it's not about reading the data, it's about 
defining the data so
that it is included in the elf file in the correct section so that the 
microcontroller is programmed
with the values when the elf file is uploaded to the microcontroller.

You may specify a name of section to place your data (if this feature is enabled for the target you 
use -- but it should be enabled for all embedded targets):


const
  FreePascal_TLS_callback : pointer = @Exec_Tls_callback;
public name '__FPC_tls_callbacks' section '.CRT$XLFPC';


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

Re: [fpc-devel] -dTEST_WIN32_SEH

[Sergei Gorelkin]

13.04.2014 18:20, Martin Frb пишет:

Just been looking at this, and trying to thing of how to catch in the debugger.

 From a very brief look at the sources (please correct me, if I got it wrong, 
or missed anything)

An error handler is installed to the OS, the handler is
function syswin32_i386_exception_handler(excep : PExceptionPointers) : 
Longint;stdcall;

This handler returns instructions (ignore, or alternative instruction pointer) 
to the OS ?
If this exception is handled it goes to JumpToHandleErrorFrame ?

Then in there the longjmp is triggered, and presumingly goes to the except 
block ?

With TEST_WIN32_SEH defined, syswin32_i386_exception_hander, longjmp, JumpToHandleErrorFrame and all 
other stuff from system.pp is no longer used. Instead, code from seh32.inc is used.
For every try..except or try..finally block, an individual handler is installed on stack, 
consisiting of pointer to one of __FPC_finally_handler, __FPC_except_handler, __FPC_on_handler or 
__FPC_except_safecall routines, and an argument, which points to except block, finally code or 
an array of TFilterRec records preceded by 4-byte count, depending on the handler kind.



If so, how can the debugger get notified (before the longjmp), in a way, that 
it can get the address
where the problem occurred?

with raise exception the debugger can set a breakpoint, because raise exception 
is defined [public
alias ...] so the debugger can read the address by knowing the name.
But the new code does not have that


The new fpc_raiseexception procedure has the same public alias as before. Each of the handler 
routines mentioned above also has a public alias.


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

Re: [fpc-devel] -dTEST_WIN32_SEH

[Sergei Gorelkin]

13.04.2014 19:06, Martin Frb пишет:

On 13/04/2014 16:02, Martin Frb wrote:

Sorry.

But the below on hold.

I just found the log at the issue. And it seems fpc_raise was called.

My fault


OK, I excuse it by being Sunday afternoon. reread. Definitely  not called.

Since the new exception handling is compilant with official way to do it, I'd expect the debugger 
to be notified about exception by Windows directly. But I have no idea about how gdb is compatible 
with that. Maybe it must be configured in certain way.


Anyway, the exception information including its original address is still available when control is 
passed to __FPC_except_handler. This handler is called twice, first time it initiates unwinding and 
the second time restores the stack and jumps to code of except block.


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

Re: [fpc-devel] Changed Math functions in FPC development trunk 2.7

[Sergei Gorelkin]

10.04.2014 20:24, Jonas Maebe пишет:

On 09/04/14 14:10, i...@wolfgang-ehrhardt.de wrote:

A year ago there was a post from Jonas Maebe on this list
(http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg28483.html)
asking about the possibility to reuse parts of AMath/DAMath in FPC.

Today I downloaded the development source files from
(ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/source/fpc.zip)
and found very close source code similarity between the changed
(compared with FPC264) math.pp routines and AMath routines.
See the list below.

Although, as Jonas wrote, zlib is compatible with FPC, there is the
need to give references and/or mark the changes. Unfortunately this
is not done.


You are absolutely correct that code that comes from your library should be 
credited properly. I've
asked Sergei, who committed these changes, to look into it and make sure that 
credit is given where
it is due.

Sorry about these errors and thanks for the friendly reminder.


Jonas


Credits added in revision 27518. Please let me know if anything else needs to 
be done.

Regards,
Sergei


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

Re: [fpc-devel] Fwd: overload question (variant vs enum subrange)

[Sergei Gorelkin]

31.03.2014 17:32, Martin Frb пишет:

Just asking this again, as I did not get any answer yet?

Is that the indented behaviour, and if so what is the reasoning for it?



This behavior is hardly intended.
To get clues about what's going on, you can compile the compiler with 
OPT=-dEXTDEBUG,
then use it with -vd to compile your tests.

So, in case of subrange of integer/byte, the overloaded procedures are matched 
as follows:

  Bar(TFoo);
   invalid
  Bar(LongInt);
   ex: 0 eq: 1 l1: 0 l2: 0 l3: 0 l4: 0 l5: 0 l6: 0 oper: 0 ord:  
4.2949672930047684E+0009
- LongInt : equal
  Bar(Variant);
   ex: 0 eq: 0 l1: 0 l2: 0 l3: 0 l4: 0 l5: 0 l6: 0 oper: 1 ord:  
0.E+
- Variant : convert_operator

And in case of subrange of enum, it becomes as follows:

  Bar(TFoo);
   ex: 0 eq: 0 l1: 1 l2: 0 l3: 0 l4: 0 l5: 0 l6: 0 oper: 0 ord:  
0.E+
- TFoo : convert_l1
  Bar(LongInt);
   invalid
  Bar(Variant);
   ex: 0 eq: 0 l1: 1 l2: 0 l3: 0 l4: 0 l5: 0 l6: 0 oper: 0 ord:  
0.E+
- Variant : convert_l1

Here Variant gets the same degree of compatibility with TFoo1 as TFoo, that's probably a bug in 
compiler (Variant should probably have same compatibility as in first case, i.e. convert_operator, 
if not incompatible at all).
Also, the subrange may receive the same treatment as in the first case, i.e. considered equal to its 
base type but with some ordinal distance.


Regards,
Sergei


 Original Message 
Subject:overload question (variant vs enum subrange)
Date:   Sun, 26 Jan 2014 19:48:42 +
From:   Martin Frb laza...@mfriebe.de
To: FPC-Pascal users discussions fpc-pas...@lists.freepascal.org



TFoo1  is a sub range of  FFoo

And it seems to match both TFoo and variant.

project1.lpr(24,3) Error: Can't determine which overloaded function to
call
project1.lpr(15,11) Hint: Found declaration: Bar(TFoo);
project1.lpr(11,11) Hint: Found declaration: Bar(Variant);


No other type seems to be bothered by variant.
Also variant is the only type, that I found that conflicts with TFoo1

Why?

I know I can declare
   procedure Bar(a: TFoo1); overload;
and it will solve it (even if I leave all the others, because it is an
exact match).

But why does a subrange of integer/byte work? Subrange of integer does
not give the error, even so it could match both.



program Project1;
{$mode objfpc}
{// $mode delpti}
type
   TFoo = (a1,a2,a3,a4,a5);
   TFoo1 = a2..a4;
   TFoo2 = 1..3;
   TFoo3 = byte(1)..(3);


procedure Bar(a: Variant); overload;
begin   end;
procedure Bar(a: Integer); overload;
begin   end;
procedure Bar(a: TFoo); overload;
begin   end;

var
   f1: TFoo;
   f2: TFoo1;
   f3: TFoo2;
   f4: TFoo3;
begin
   Bar(f2);
end.





___
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] Fwd: overload question (variant vs enum subrange)

[Sergei Gorelkin]

31.03.2014 23:46, Martin Frb пишет:

On 31/03/2014 20:29, Sergei Gorelkin wrote:

31.03.2014 17:32, Martin Frb пишет:

Just asking this again, as I did not get any answer yet?

Is that the indented behaviour, and if so what is the reasoning for it?



This behavior is hardly intended.
To get clues about what's going on, you can compile the compiler with 
OPT=-dEXTDEBUG,
then use it with -vd to compile your tests.


Thanks.

I had already reported it. http://bugs.freepascal.org/view.php?id=25697

If ok I will add your findings to the report?


Feel free to do it.

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

Re: [fpc-devel] XML / SAX - Removing redundancies

[Sergei Gorelkin]

12.03.2014 1:32, Daniel Gaspary пишет:

I have uploaded a patch[1] to remove the TSaxInputSource, it is
redundant with TXmlInputSource from XmlReader unit.

I believe the TSAXXMLReader.Parse method have almost the same
functionality of xmltextreader.TXMLTextReader.

I would like to know if and how it can be modified. The base class,
TSaxReader, needs much more changing and could affect users of the
class.


I had an idea of replacing SAX with proxy to TXMLTextReader once I've written the latter, but it 
appears that SAX is just beyond redemption. One case is that it reports attribute names in LocalName 
property instead of QualifiedName, which means that any code using SAX reads them from wrong place 
and *will* break if SAX is made compliant.


OTOH, if we go for breaking user's code, then it is much better to drop SAX altogether and switch 
over to TXMLTextReader.


From these points of view the best way is probably to document TXMLTextReader, deprecate SAX and 
leave it alone.


All above is about sax-xml; sax-html, unfortunately, does not have a better 
alternative in FPC packages.

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

Re: [fpc-devel] XML / SAX - Removing redundancies

[Sergei Gorelkin]

12.03.2014 18:10, Daniel Gaspary пишет:

On Wed, Mar 12, 2014 at 11:04 AM, Daniel Gaspary dgasp...@gmail.com wrote:

On other topic, a new StaX[1] class, using TXMLTextReader,


I mean, *classes*.

Creating the writer part too.


Why would you want to use S[t]AX approach in the first place? The interface of .net-based 
XML[Text]Reader and XMLWriter is IMHO much more straightforward and easy to use.


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

Re: [fpc-devel] XML / SAX - Removing redundancies

[Sergei Gorelkin]

12.03.2014 18:58, Daniel Gaspary пишет:

On Wed, Mar 12, 2014 at 11:42 AM, Sergei Gorelkin
sergei_gorel...@mail.ru wrote:

Why would you want to use S[t]AX approach in the first place?


No special reason at the moment. I didn't examine TXmlTextReader so much yet.


The interface of .net-based XML[Text]Reader and XMLWriter is IMHO
much more straightforward and easy to use.


A xmlwriter unit, equivalent to xmlreader, would be interesting.To
have a XML writer independent of DOM.


Here I fully agree, and in the meantime I've already committed some initial changes to TXMLWriter to 
make it function like .net XMLTextWriter.


Regards,
Sergei



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

Re: [fpc-devel] XML / SAX - Removing redundancies

[Sergei Gorelkin]

12.03.2014 21:46, Daniel Gaspary пишет:

On Wed, Mar 12, 2014 at 2:36 PM, Michael Van Canneyt
mich...@freepascal.org wrote:

What can be achieved at the most seems to be the parsing of the expression
and the resulting parse tree.


Is exactly what I'm trying to say(my lack of English grammar skills
doesn't help). :)


I seriously doubt this is doable, since XPath works directly on the DOM tree
?


Is possible if TXmlReader keeps track of the it's current path. Let's say:

TMyXmlReader = class(TXmlTextReader)
private
  FPath: TStrings; //or another dedicated new CLass to keep a
list of nodes.
public
 Register(XPathExpression: string; MethodToCall);
end;

At each step of processing, FPath is updated and is compared to XPathExpression.


A certain subset of expressions (forward iteration only) can be handled that 
way, yes.
But in general, XPath requires a source with non-sequential access.

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

Re: [fpc-devel] Heaptrace + cwstring cause SIGSEGV at the end

[Sergei Gorelkin]

10.03.2014 19:40, Jonas Maebe пишет:


On 10 Mar 2014, at 16:13, Petr Kristan wrote:


If memoryleak occurs and program ends, then i get SIGSEGV in cwstring.pp:481 
(iconv call)
because cwstring unit is finalized before heaptrc.



If you use -gh, then heaptrc will be the first unit of the uses clause and will 
be finalized after
any manually added unit.

That's exactly the issue. Being finalized last, heaptrc must not do anything that depends on 
functionality from other units, except system, but it does due to recent Unicode-related changes 
(indirectly, see the stack trace).


Even further, in case of error RTL tries to print a backtrace right after finalizing all units (see 
InternalExit procedure in system.inc), which can lead to similar problems.


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

Re: [fpc-devel] extend unreachable code warning for more cases?

[Sergei Gorelkin]

26.02.2014 12:09, Sven Barth пишет:

Hello together!

In context of Apple's recent security bug where a goto fail; at the wrong 
place disabled
certificate checking or something along that lines I've thought whether it 
would 1) be worthwhile to
extend FPC with the capability to detect such cases as well and 2) to see 
whether it would be
currently feasible at all.

So, how hard would it be to let the compiler detect cases like these:

=== code begin ===

procedure Test1;
begin
   Writeln('Test1');
   Exit;
   Writeln('Test1');
end;

procedure Test2;
label
   stop;
begin
   Writeln('Test2');
   goto stop;
   Writeln('Test2');
stop:
end;

=== code end ===

and of course potentially more complex ones...

Also would you think it would be worthwhile to spend time on this?



The definite assignment analysis ported by me four years ago 
(http://bugs.freepascal.org/view.php?id=15523) detects all cases of unreachable code, except 
backward goto's. Everything but backward goto's is almost trivial, backward goto's are more 
complicated because they require multiple iterations over code tree, but are certainly feasible.


Regards,
Sergei


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

Re: [fpc-devel] extend unreachable code warning for more cases?

[Sergei Gorelkin]

26.02.2014 13:28, Sven Barth пишет:

Am 26.02.2014 09:41, schrieb Sergei Gorelkin:

26.02.2014 12:09, Sven Barth пишет:

Hello together!

In context of Apple's recent security bug where a goto fail; at the wrong 
place disabled
certificate checking or something along that lines I've thought whether it 
would 1) be worthwhile to
extend FPC with the capability to detect such cases as well and 2) to see 
whether it would be
currently feasible at all.

So, how hard would it be to let the compiler detect cases like these:

=== code begin ===

procedure Test1;
begin
   Writeln('Test1');
   Exit;
   Writeln('Test1');
end;

procedure Test2;
label
   stop;
begin
   Writeln('Test2');
   goto stop;
   Writeln('Test2');
stop:
end;

=== code end ===

and of course potentially more complex ones...

Also would you think it would be worthwhile to spend time on this?



The definite assignment analysis ported by me four years ago
(http://bugs.freepascal.org/view.php?id=15523) detects all cases of unreachable 
code, except
backward goto's. Everything but backward goto's is almost trivial, backward 
goto's are more
complicated because they require multiple iterations over code tree, but are 
certainly feasible.

Nice... does that code still work with current trunk?

Didn't test it, but should not be difficult to fix anyway.


How does it look in light of Florian's recent work on SSA? (though it's not yet 
fully in trunk AFAIK)
They are probably two independent things. I've abandoned experiments with trying to use definite 
assignment analysis to determine variable lifetime.



Regards,
Sergei


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

Re: [fpc-devel] 2.6.2 messes up stackframe pointer /// Fwd: Re: [Lazarusdev] crash in View Forms Dialog - codetools

[Sergei Gorelkin]

06.02.2014 4:32, Martin Frb пишет:

Only  tested with 2.6.2 yet. Will see yf/when I get to test with trunk.

Also not reproduced on simple code yet, only in the IDE (on 2 different pieces 
of code, both
involving for ...in)
Maybe it is already known?


Looks very much like http://bugs.freepascal.org/view.php?id=20827

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

Re: [fpc-devel] Optimizations

[Sergei Gorelkin]

24.01.2014 3:04, Martin Frb пишет:

On 23/01/2014 22:26, August Oktobar wrote:

Hello, I have seen your mails about peephole optimization, so I wonder if you 
could look at this
reports
http://bugs.freepascal.org/view.php?id=23595

or perhaps optimize slow array access using operator [] (it is faster to use 
pointer arithmetics)

thanks!


1) I am just getting started on this, so I can only answer with limited 
knowledge.
 @experts, please correct me below, where needed
2) The peephole opt is only something I do on the side as it currently is.

 From a quick glance, this does not look like something for the peephole opt.

The peephole opt currently looks at statements that are close together (follow 
each other immediately).
I am not sure to which extend (if at all) it would be acceptable to break that 
limit (it is doable,
question is if desired).

In this specific case:
1) between the fstpl and the mov (half_the_data), %edi are other statements.
   detecting the connection would either:
   - need scanning several statements ahead. This would be slow, because it had 
to be done after
each storing something to memory (so very often)
   - keeping state of all the involved registers and memory (do-able / 
interesting at least from a
theoretical view / but not sure if desired)
2) only half the mem is accessed, and then the other half. That means to detect 
the connection
between the mem read and the register, it is needed to analyse 4 statements. 
Very unlikely to see
this in the peephole opt.

The livelihood of a[i] needs to be checked where the code is generated.



1) You are right that it's not the job for peephole analyzer, it is typical common subexpression 
elimination.
2) Reporter's assumption about fstp is wrong: the first fstp instruction removes value from fpu 
stack, so it cannot be used for the second time without first reloading value onto stack.
3) The assignments of floating-point values are currently being generated using integer 
instructions, hence the subsequent code. This way it doesn't depend on number of available FPU 
registers, which is hard to know at any point.


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

Re: [fpc-devel] Inc() and Dec() on properties

[Sergei Gorelkin]

On 21.12.2013 02:11, Mark Morgan Lloyd wrote:

Sven Barth wrote:

On 20.12.2013 22:02, Mark Morgan Lloyd wrote:

A question if I may, leading on from
http://bugs.freepascal.org/view.php?id=25440

  - inc(x)/dec(x) with range checking enabled are optimized with
  taking address of x.

Is that why Inc() and Dec() can't be applied to properties, or are there
other issues?


http://wiki.freepascal.org/User_Changes_2.4.0#Treating_direct-mapped_properties_as_regular_fields


Noted, but I think my real question is whether the compiler could recognise 
that the optimisation is
inappropriate and instead generate +=n (with range checking).

Yes, the compiler was recognizing case with enabled range checking and generating x:=x+n. However 
if x involves a function call (e.g. inc(somearray[foo()+2]); ) it is still necessary to avoid 
calling it twice, hence the optimization. I used quotes because the end result was opposite to the 
expected one.


Regards,
Sergei

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

Re: [fpc-devel] Problem with bitpacked records and STM32F107 Controller

[Sergei Gorelkin]

11.12.2013 12:28, Sven Barth пишет:

Am 11.12.2013 08:43, schrieb Michael Ring:

The strb command seems to be the problem, documentation from STM states:

Each I/O port bit is freely programmable, however the I/O port registers have 
to be accessed as
32-bit words (half-word or byte accesses are not allowed).

So, is there some way to make the bitset operations word-aligned?

Better say 32-bit aligned to avoid confusion. Words in Pascal are 16-bit 
although I know that you
are talking about the CPUs word size...

Are there any good reasons for not doing so?

What when you really have a byte that you want ot access? Then using 32-bit 
writes/reads could(*)
result in unnecessary cycles.

* I don't know about ARM especially, but I know that for e.g. the m68k a 32-bit 
store is more
expensive than a 16-bit or 8-bit store

That said I don't have a solution for your specific problem except by doing it 
by hand.

Maybe size of memory access must be guided by size of record? For ARM the record will be 32-bit, and 
for m68k it can be 8 or 16-bit.


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

Re: [fpc-devel] bug or feature?

[Sergei Gorelkin]

25.11.2013 3:31, Paul Ishenin пишет:

22.11.2013 23:09, Sergei Gorelkin пишет:

Hello together,

The following compiles and executes correctly in objfpc mode (and rejected by 
Delphi and by FPC in
mode Delphi). Is implicit taking address of array there by design?

Yes, it is a FPC feature which is widely used by Lazarus.


This is good to know, thanks!

Sergei


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

[fpc-devel] bug or feature?

[Sergei Gorelkin]

Hello together,

The following compiles and executes correctly in objfpc mode (and rejected by Delphi and by FPC in 
mode Delphi). Is implicit taking address of array there by design?


type
  PReal = ^Real;
const
  xa: array[0..3] of Real = (1.0,2.0,3.0,4.0);

procedure test(x: PReal);
begin
  writeln(x[3]);
end;

begin
  test(xa);   // prints 4.0e+0
end.

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

Re: [fpc-devel] Performance of string handling in trunk

[Sergei Gorelkin]

On 21.06.2013 17:11, luiz americo pereira camara wrote:

2013/6/21 Michael Schnell mschn...@lumino.de:

On 06/20/2013 05:31 PM, luiz americo pereira camara wrote:


Maybe in that example there's going an (unneeded) conversion?


If you use the same string type all over the place it would be a severe bug
if _any_ conversion is done.

Please check.



The affected code can be seen here
http://forum.lazarus.freepascal.org/index.php/topic,21223.0.html .

I don't have a 2.7.1 setup so i cant debug myself. I'm just reporting
what the user found

I've profiled the code and found no conversions taking place. All the slowdown appears to be caused 
by other reasons, hard to tell the topmost contributor. What catches the eye is the large amount of 
calls to UniqueString, and the fact that SetCodePage goes through implicit try..finally block even 
if it does not need to convert the string.


Regards,
Sergei

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

Re: [fpc-devel] Performance of string handling in trunk

[Sergei Gorelkin]

20.06.2013 16:15, luiz americo pereira camara пишет:

I looked at http://forum.lazarus.freepascal.org/index.php/topic,21223.0.html

There's a significant performance drop in fpc trunk

The difference of generated code is a call to fpc_ansistr_assign and a
different implementation of fpc_AnsiStr_Concat

AFAIK there should be significant performance hit only when assigning
string with different code pages. It does not seem to be the case.

Is there anything wrong or this is the expected result?

Some slowdown is of course the expected result: it is impossible to add all codepage stuff without 
performance impact. Even though conversions happen only when codepages differ, the code which checks 
the codepages is executed anyway on every operation. The question is, which part of observed 
slowdown is unavoidable and which can be eliminated by more accurate implementation.


Regards,
Sergei

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

Re: [fpc-devel] Performance of string handling in trunk

[Sergei Gorelkin]

20.06.2013 19:31, luiz americo pereira camara пишет:


Maybe in that example there's going an (unneeded) conversion?


This is possible. One needs to profile the example to tell for sure.

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

Re: [fpc-devel] how to produce object codes that do not reference symbolic registers

[Sergei Gorelkin]

17.06.2013 19:20, Dennis пишет:

I am trying to create a cross compiler from x86 Debian-Linus - mips-eb (endian 
big) Linux (OpenWrt).
The target platform is a netgear 3700 router.

I downloaded the toolchain for openwrt mips-eb and try to make the cross 
compiler.
when I run
make all CPU_TARGET=mips OS_TARGET=linux BINUTILSPREFIX=/usr/bin/mips-linux-gnu-

there were errors:
/home/dennis/toolchains/staging_dir_mips/bin/mips-linux-as -32 -mips32 -EB -o
/home/dennis/fpc/2.7.1/rtl/units/mips-linux/prt0.o mips/prt0.as
mips/prt0.as: Assembler messages:
mips/prt0.as:23: Error: illegal operands `lui $a2,%hi(__dl_fini)'


looks like the mips-linux-as  assembler cannot understand the symbolic register 
$a2.

May be the assembler version is too old (late 2009) but I cannot find a newer 
assembler so I am
wondering if I can make the fpc compiler product object files that DO NOT 
REFERENCE symbolic registers.

If you know of any options parameters that I can pass to fpc to achieve that, 
please kindly let me know.

Thanks a lot.



There are no compiler switches that influence output of symbolic registers. Moreover, the code in 
prt0.as

is written by hand, so compiler has nothing to do with it.
At the same time, on one of the testing machines we use even older gas 2.18.50.20080506 (May 2008) 
and it gives no such issues.


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

Re: [fpc-devel] Some Opcodes missing in internal assembler for mips32r2

[Sergei Gorelkin]

16.06.2013 22:17, Michael Ring пишет:

I have now browsed through the current mips documentation and have created a 
file that includes all
opcodes, the version they are first in (starting with mips32) and a small 
comment what the mnemonic
does.
This file is attached to this mail.

The problem here is that MIPS32 is not the first, but fifth version of MIPS instruction sets, 
preceded by MIPS I, MIPS II, MIPS III and MIPS IV. Currently there is no separation between 
instructions sets in compiler sources, but they need to appear one day. MIPS32 documentation is not 
correct in this respect, as it says e.g. that ADD is first supported by MIPS32, while it is actually 
MIPS I instruction.


The most accurate source is probably the GNU Opcode library, which is part of 
binutils.


Out of this file it is easy to create both compiler/mips/strinst.inc and 
compiler/mips/opcode.inc.

Now I am looking for additional lines that I will need to add to this file, to 
find out what is
necessary I have created a list of mnemonics that exist only in the original 
opcode.inc file (see
later)

there are a number of entries in the form xxx64xxx and xxx32, xxxg and dxxx, 
all those do not seem
to be valid for mips32  up, where do those come from and which of those do I 
need to add?

xxx64xxx and xxxg are likely subject for removal, I've no idea where they came from. dxxx and xxx32 
are MIPS III instructions, as well as sdr,sdl,lwu and alike. A lot of other stuff (la, li, neg, 
mulo, seq, etc.) are macros that are expanded into several instructions.



There's one very strange entry in opcode.inc: 'b '

there is also 'b', is it necessary to have 'b ' ?

The codegenerator and optimizer expect conditional and unconditional branches to have distinct 
opcodes, this strange construction provides that.


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

Re: [fpc-devel] How can I distribute code in two different memory areas? (.section)

[Sergei Gorelkin]

16.06.2013 23:39, Michael Ring пишет:

I had some time this weekend (while beeing grilled by the sun on my balcony) to 
work on another
thing that did not work correct and that I did not understand (Now I do, I 
least I hope ;-)

As said before in this thread, I wanted to distribute Code in two different 
memory areas because
this needs to be done so that pic32 startup code works correctly.

But when I linked my binary the elf-file had always a startup address somewhere 
in the wrong memory
area.

This is what I tried:

procedure reset; assembler; nostackframe; public name'_reset';
asm
   .section .reset,\ax\,@progbits
   la  $k0, _startup
   jr  $k0  //Jump to startup code
   nop
   .text
end;



In general, the custom section support in compiler needs a lot of improvement...

Try the following, maybe it could work:

procedure anyname; assembler; nostackframe;
asm
   .section .reset,\ax\,@progbits
.globl _reset
_reset:   // -- correct name here
   la  $k0, _startup
   jr  $k0
   nop
.text
end;


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

Re: [fpc-devel] Some Opcodes missing in internal assembler for mips32r2

[Sergei Gorelkin]

29.05.2013 21:44, Michael Ring пишет:

This is looking good now on first view, all statements seem to pass through now.

The only thing not working is the register error in mfc0 (and friends) command.

Now I will wade through some more code to find out why my nice param 
-CpMIPS32R2 is ignored by
assembler, it still defaults to MIPS2:


I hopefully fixed this issue in r24643, and the register naming issue in r24799.
Should you encounter more issues, do not hesitate to report them.

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

Re: [fpc-devel] Some Opcodes missing in internal assembler for mips32r2

[Sergei Gorelkin]

29.05.2013 2:08, Sergei Gorelkin пишет:

29.05.2013 1:26, Michael Ring пишет:

I did the changes, parts of the opcodes now work fine, I think I have found the 
problem with the li
+ and + mfc0 op-codes, if last parameter is 0 then the asm statement is 
generated wrong:

This works:
 and$a0,$a0,1

this does not work:
 and$a0,$a0,0

result is:

pic32mx1xxfxxxb.s:107: Error: absolute expression required `and $a0,$a0,'


So it is the value of operand that matters. I'll try to look at it, probably a 
bug in the parsing
part, because the output part doesn't have anything suspicious.


Fixed in r24630. The parsing part is buggy as hell (it interprets numbers as references rather than 
as constants), but the output part wasn't correct either at outputting such references.


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

Re: [fpc-devel] Status of SEH in FPC

[Sergei Gorelkin]

03.03.2013 2:53, Flávio Etrusco пишет:

Hello,

what's the current state of the SEH in FPC trunk?
IIRC - and according to wikipedia ;-) - SEH, at least for Windows, was
in the 2.7 roadmap, but I can't find any related brach, or commit, or
post.
Also AFAIU would have some gains in both executable size and speed, correct?

By now SEH is fully implemented for Win64 target, but you need to cycle the compiler with 
OPT=-dTEST_WIN64_SEH to enable it.

The most of it was committed in revision 20098.

The effect of SEH is two-fold: it gives some performance gain when running without exceptions, but 
big penalty when exceptions occur. It somewhat reduces code size but at the same time adds some 
data, so executable size may not reduce.


The main advantage of SEH is the conformance with OS exception handing scheme. Without it, it was 
almost impossible to use DLLs that raise exceptions.


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

Re: [fpc-devel] Image size is too big for target even if external debug file is used

[Sergei Gorelkin]

05.02.2013 19:32, Sven Barth пишет:

Hello together!

I have a arm-wince project (using LCL) where I have a stacktrace and I'd like 
to resolve the symbol
information. As I'm not cross debugging I'm using an offline (post mortem) 
process for which I
compile my application with debug information, but also -Xg to get a seperate 
symbol file which I
can use with GDB. Now the problem is that since the last time I needed these 
symbols my application
seems to have gotten big enough that the debug information triggers the 
Executable image size too
big for arm-wince target error.

I'm currently using 2.6.0 on i386-win32. If compiled for i386-win32 the 
application's size is 3.7 MB
while the debug information size is 42 MB (the application size for arm-wince 
is 4.3 MB).

I've looked a bit inside the compiler and shouldn't it be possible and 
worthwhile to not raise this
error if one is cross compiling and currently the debug file is generated (the 
corresponding
location is - in trunk - ogbase.TExeOutput.SetCurMemPos)? Or maybe define a 
list of targets where it
should be allowed when cross compiling.



An interesting issue. On ELF targets all debug sections are placed at zero address, so such error 
can arise only if size of a single section exceeds limit, but on COFF targets like arm-wince debug 
sections consume address space (although they are not loaded).
Maybe we should simply ignore the address limit for debug sections, or maybe only when generating 
external debug file.


Regards,
Sergei

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

Re: [fpc-devel] Forwarded message about FPC status

[Sergei Gorelkin]

17.12.2012 13:55, Sven Barth пишет:

smart linking MSEide on
64 bit Linux is not possible with 2GB ram,

Linking is a problem of ld, not of Free Pascal. ld was not designed for the 
workload we put on it
(especially regarding smart linking). You could try however if the new internal 
ELF linker solves
this problem for you (I don't know whether it already supports smart linking; 
this is something that
Sergei should answer)


The problem here is that smartlinking is still being done with archives (.a) on 
x86 Linux targets,
while ld's preferred mode of operation is section-based smartlinking. Switching to section-based 
smartlinking will probably reduce memory requirements to acceptable level. However, FPC does not 
handle exported symbols correctly and they get lost if section-based smartlinking is used.


The internal linker of course supports smartlinking, moreover it is not sensitive to the mentioned 
exported symbol issue.


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

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

[Sergei Gorelkin]

30.11.2012 1:46, Mark Morgan Lloyd wrote:


Running the program using the modified GDB, I get the same as before:

0 1markMLl@pye-dev-07d:~$ which gdb
/usr/local/bin/gdb
0 1markMLl@pye-dev-07d:~$ gdb /usr/local/bin/ppcmips
GNU gdb (GDB) 7.0.1-debian
..
(gdb) set arg -h
(gdb) run
Starting program: /usr/local/bin/ppcmips -h

Program received signal SIGBUS, Bus error.
0x0043eb88 in SYSUTILS_$$_UNIXTOWINAGE$LONGINT$$LONGINT ()
(gdb) bt
#0  0x0043eb88 in SYSUTILS_$$_UNIXTOWINAGE$LONGINT$$LONGINT ()
#1  0x0043fa6c in SYSUTILS_$$_FINDGETFILEINFO$ANSISTRING$TSEARCHREC$$BOOLEAN ()
#2  0x0043fdc4 in SYSUTILS_$$_FINDNEXT$TSEARCHREC$$LONGINT ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)


This was caused by insufficient alignment of Double-typed temp variables, fixed 
in r23146.
Moreover, it appeared that function UnixToWinAge wasn't doing anything useful since year 2005, so it 
was removed in r23145, making FindFirst/FindNext routines somewhat faster (and able to run without FPU).


Now I am able to run the big-endian MIPS compiler on QEMU. Hoping you'll be 
able to reproduce it, too.

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

Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K)

[Sergei Gorelkin]

11.12.2012 1:27, Sven Barth пишет:


It's putting a significant number of AT_NONE entries into the table, and
the first one it tries to take out (which obviously isn't the first
entry in the list) causes the internal error. When being put in, this
entry had a call stack like

#0 TASMDATA__REFASMSYMBOL('PBGetCatInfoSync', error reading variable)
at aasmdata.pas:443


I had also made out this location as the only plausible one for these AT_NONE 
entries. Maybe the
external handling was changed since Mac OS last worked and the MPW writer 
wasn't adjusted then...

Well, all ELF targets emit external symbols in object files with STT_NOTYPE type field, which 
corresponds to AT_NONE internal representation. COFF targets also accept this, although recent 
GCC/MinGW versions are marking external functions with proper type.


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

Re: [fpc-devel] Interface usage causes FPC to crash

[Sergei Gorelkin]

30.11.2012 17:20, David Ballesteros пишет:

Hi,

Im interested on known the answers to Graeme  questions.


Delegation to interface-type properties is fully supported.
Delegation to class-type properties is supported, but it requires the delegate class to implement 
the interface (this requirement is absent in Delphi).


Method resolution also works, but it is mutually exclusive with delegation.

The crash at compilation of course needs to be fixed.

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

Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing

[Sergei Gorelkin]

On 05.11.2012 18:00, Jonas Maebe wrote:


On 05 Nov 2012, at 14:40, Vincent Snijders wrote:


I found out the cause of *my* problem. The ld provided by Ubuntu
(version 2.22) was in /usr/bin. There was also an older version 2.21
in /usr/local/bin which was actually chosen. Fixing that solved my
problem.


Yes, the default system linker's built-in linker script contains the search 
path for all system
libraries. That is the reason why we don't use the -T option the linker 
complains about, because
doing so would tell the linker to ignore the built-in linker script and hence 
also those
system-specific library search paths.

We could also very easily get rid of the -T warning by getting rid of all the 
built-in linker
scripts in the compiler, and replacing them with just the parts that are 
FPC-specific (basically
keeping the .fpc section), but for reasons I still don't understand some 
people think this would
cause problems.

The current setup causes *everything* except sections (symbols, constants, etc) to be linked 
incorrectly, because the script is being executed twice, first time the built-in script, the second 
time FPC-supplied one. Fortunately, most linking is governed by built-in script, and most of 
FPC-supplied script is effectively ignored, that's why we get working executables in the end.


I've experimented with removing all but .fpc section from linker script on x86_64-linux and 
i386-linux targets, and encountered no issues. In the nearest future, I'm going to commit these 
changes, and also write a test that will fail if linking with current setup.



The only argument in favour of keeping the compiler-internal linker scripts for 
Linux targets that I
currently can think of is that it would probably make the built-in ELF linker 
harder to realise (it
would probably have to ask the system linker for the default linker script 
then). We could also let
the internal linker use a compiler-internal linker script and the external 
linker the system default
one, but that's probably not a good idea (ideally the internal and external 
linker would use the
same settings, both from a support and from a predictability perspective).

The internal ELF linker has been already implemented for x86 targets, it only misses appropriate 
RegisterInternalLinker calls in initialization section of t_linux.pas. It uses an internal script.
Reusing the system-default script in its entirety would require closely following ld inner structure 
(e.g. ld composes .rela.dyn section from .rela.text,.rela.data,etc input sections, while internal 
linker writes it directly), and probably is not worth the trouble. At the same time, I had to 
implement a basic parser of ld script files anyway, so partially using the system-default script for 
e.g. search paths can be done fairly easily.


Regards,
Sergei

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

Re: [fpc-devel] XML Components

[Sergei Gorelkin]

02.11.2012 17:08, Michael Van Canneyt пишет:



On Fri, 2 Nov 2012, Andrew Brunner wrote:



I think it would be a good solution and even prove faster in controlled 
environments.  Plus all
data is stored as widestrings in the DOM.

The first question I have is if there was such an option would the patch be 
accepted.


I don't see how you can fix the problem. If the input is UTF8, and the result 
must be converted to a
widestring for the DOM, then a conversion MUST take place, there is no way to 
avoid it.
And a conversion means scanning the input byte for byte.

In each case, the input must be scanned byte for byte anyway, to detect all the 
tags. That's what
makes XML slow and unusable for large amount of data.


The next question is what is the problem with the uf8 routine that it left the 
offending byte
sequence intact without converting the bytes in my sample data?


Without error message, it is impossible to tell.

In this case, the issue is not encoding, but literal ESC (#27) code used in data. XML specification 
does not allow codepoints below 32, except TAB,CR and LF, to appear in data, both in literal and 
escaped forms.
In other words, XML is wrong technology to work with binary data, unless it is encoded into textual 
form (Base64 or alike).


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

Re: [fpc-devel] XML Components

[Sergei Gorelkin]

02.11.2012 17:44, Mattias Gaertner пишет:


Sergei Gorelkin sergei_gorel...@mail.ru hat am 2. November 2012 um 14:32
geschrieben:

In this case, the issue is not encoding, but literal ESC (#27) code used in
data. XML specification
does not allow codepoints below 32, except TAB,CR and LF, to appear in data,
both in literal and
escaped forms.


Actually the specification only defines legal characters and that processors
must accept them.
It does not say what to do with the other characters.

Besides specification, there is a test suite containing lots of tests with illegal characters and 
expecting them all to fail.


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

Re: [fpc-devel] XML Components

[Sergei Gorelkin]

02.11.2012 21:06, Jeppe Græsdal Johansen пишет:

Den 02-11-2012 18:04, Michael Van Canneyt skrev:



On Fri, 2 Nov 2012, Jeppe Græsdal Johansen wrote:


and LF, to appear in data, both in literal and escaped forms.
In other words, XML is wrong technology to work with binary data, unless it is 
encoded into
textual form (Base64 or alike).

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

XML 1.1 allows anything down to #1, but the current parser doesn't seem to 
allow that. I guess
that should solve most of the problems here.

Specifically, TXMLDecodingSource.SkipUntil doesn't allow #1..#31 if FXML11Rules 
is true, which I
think it should.


But the document prolog specified XML version 1.0,
so these characters are not allowed.

If of course Andrew creates the XML himself, he can specify 1.1 as the XML 
version, then that may
well be a solution.

Yes, but changing the version still generates the same error, even though it 
shouldn't

Note that the specs of 1.1 still say that

The characters defined in the following ranges are also discouraged. They are 
either control
characters or permanently undefined Unicode characters:

[#x1-#x8], [#xB-#xC], [#xE-#x1F], [#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDDF],
[#x1FFFE-#x1], [#x2FFFE-#x2], [#x3FFFE-#x3],
[#x4FFFE-#x4], [#x5FFFE-#x5], [#x6FFFE-#x6],
[#x7FFFE-#x7], [#x8FFFE-#x8], [#x9FFFE-#x9],
[#xAFFFE-#xA], [#xBFFFE-#xB], [#xCFFFE-#xC],
[#xDFFFE-#xD], [#xEFFFE-#xE], [#xE-#xF],
[#x10FFFE-#x10].

So it would be wise to replace the characters with encoded data.

Michael.

It's true that it's not a good idea, but it should work at least :)


To my knowledge, XML 1.1 supports codes below 32 only in escaped forms. #27; is valid in XML 1.1 
but not in XML 1.0.


Regards,
Sergei



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

Re: [fpc-devel] XML Components

[Sergei Gorelkin]

02.11.2012 19:57, Andrew Brunner пишет:

So where in the specs does it say that parsers must reject certain byte 
sequences between cdata tags excepting XML tags.

If this is supported by specs it would help shape a viable solution.

This is not supported. Encoding processing, line-feed normalization and invalid character rejection 
happens before attempting to detect any markup. This is necessary to support encodings like 
ISO-2022-jp, which uses ESC sequences to switch between meaning of subsequent chars.


CDATA is, in fact, even more restricted than text content. Outside of CDATA, a 
character
unrepresentable in target encoding can be ampersand-escaped. Within CDATA this 
cannot be done.
CDATA is intended only to handle '' and '' as plaintext, nothing more.

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

Re: [fpc-devel] XML Components

[Sergei Gorelkin]

02.11.2012 21:22, Jeppe Græsdal Johansen пишет:

Den 02-11-2012 18:19, Sergei Gorelkin skrev:

02.11.2012 21:06, Jeppe Græsdal Johansen пишет:

Den 02-11-2012 18:04, Michael Van Canneyt skrev:



On Fri, 2 Nov 2012, Jeppe Græsdal Johansen wrote:


and LF, to appear in data, both in literal and escaped forms.
In other words, XML is wrong technology to work with binary data, unless it is 
encoded into
textual form (Base64 or alike).

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

XML 1.1 allows anything down to #1, but the current parser doesn't seem to 
allow that. I guess
that should solve most of the problems here.

Specifically, TXMLDecodingSource.SkipUntil doesn't allow #1..#31 if FXML11Rules 
is true, which I
think it should.


But the document prolog specified XML version 1.0,
so these characters are not allowed.

If of course Andrew creates the XML himself, he can specify 1.1 as the XML 
version, then that may
well be a solution.

Yes, but changing the version still generates the same error, even though it 
shouldn't

Note that the specs of 1.1 still say that

The characters defined in the following ranges are also discouraged. They are 
either control
characters or permanently undefined Unicode characters:

[#x1-#x8], [#xB-#xC], [#xE-#x1F], [#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDDF],
[#x1FFFE-#x1], [#x2FFFE-#x2], [#x3FFFE-#x3],
[#x4FFFE-#x4], [#x5FFFE-#x5], [#x6FFFE-#x6],
[#x7FFFE-#x7], [#x8FFFE-#x8], [#x9FFFE-#x9],
[#xAFFFE-#xA], [#xBFFFE-#xB], [#xCFFFE-#xC],
[#xDFFFE-#xD], [#xEFFFE-#xE], [#xE-#xF],
[#x10FFFE-#x10].

So it would be wise to replace the characters with encoded data.

Michael.

It's true that it's not a good idea, but it should work at least :)


To my knowledge, XML 1.1 supports codes below 32 only in escaped forms. #27; 
is valid in XML
1.1 but not in XML 1.0.

Regards,
Sergei

According to the spec, cdata should allow them unescaped.

[2]   Char   ::=   [#x1-#xD7FF] | [#xE000-#xFFFD] | 
[#x1-#x10]

[20]   CData   ::=   (Char* - (Char* ']]' Char*))


I see now, they were allowed in second edition of the specs, while the first edition did not allow 
them. Current fcl-xml implementation corresponds to the first edition. So it's indeed time to update.


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

Re: [fpc-devel] URIParser is not up to spec

[Sergei Gorelkin]

19.09.2012 11:45, Graeme Geldenhuys пишет:

Hi,

I have to deal with complex URL's in a new part in my project, and thought I 
would take advantage of
the already existing URIParser unit in FPC. At closer inspection I noticed that 
the URIParser is not
up to RFC-3986 specs. Even some of the terminology and values used in URIParser 
is different to the
official RFC's.

Would anybody mind if I updated the URIParser unit to be more correct, or is 
it the FPC
pereference to leave it as it is, and I'll make my own amendments for my 
project.

   http://tools.ietf.org/rfc/rfc3986.txt

Originally uriParser code was written to handle only URLs, without RFC3986 in mind. Later I updated 
it so the logic became closer to RFC3986, but had to keep URI syntax components as is in order to 
preserve compatibility with existing code.


So I think if we go after strict RFC compliance, we should introduce a new unit and deprecate an old 
one.


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

Re: [fpc-devel] push [rdx]

[Sergei Gorelkin]

30.08.2012 2:50, Martin пишет:

Does anyone know if that is valid intel style assembler?
   push [rdx]


When an instruction has no register operands, it needs operand size to be 
explicitly specified:
 push qword ptr [rdx]


FPC complains (on intel /win 64 bit).

It's from PascalScript code. (Source\x64.inc) I wonder how to get it work...


Regards,
Sergei


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

Re: [fpc-devel] FPC -Rintel and -alr options

[Sergei Gorelkin]

21.08.2012 5:38, ABorka пишет:

Is there a way to see the generated .s assembly files as Intel syntax instead of 
the ATT one?
The -Rintel flag does not seem to work, or I am doing something wrong.

Tried command line and fpc.cfg both, on win32 and win64, latest SVN .


-R switch controls parsing assembler blocks in the code.
The output format is set with -A  (e.g. -Amasm will produce Intel syntax).

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

[fpc-devel] About tests/tbf/tb0002.pp

[Sergei Gorelkin]

Hello,

tests/tbf/tb0002.pp is intended to fail, but currently it fails because the VMT symbol 
(VMT_$P$PROGRAM_$$_TA) is unresolved while linking. Shouldn't compiler detect usage of typeof() on 
an object type without VMT and report error at compile stage instead?


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

Re: [fpc-devel] Cross compiling x86 on amd64, linking to crtbegin.o etc.

[Sergei Gorelkin]

17.07.2012 2:51, Jonas Maebe пишет:


On 17 Jul 2012, at 00:36, Konstantin wrote:


The bad thing is
that these paths are determined by the FPC function
librarysearchpath.FindFile and as this function does not honor the
target architecture. It always returns /usr/lib/. as the default
architecture version of these files is located there. This of course
fails when compiling 32 bit on a 64 bit Gentoo machine where the 32 bit
versions are in /usr/lib32/. and linking fails due to invalid files.

So again my second question is, why are absolute paths used for
crtbegin.o, crti.o, crtend.o and crtn.o?


Because based on the information provided to the compiler via command line 
parameters and the knowledge hardcoded into the compiler, those are the files 
that should be linked. Specifying their explicit path ensures that the linker 
will link the object files that compiler wants it to link, rather than some 
random files with the same names that the linker find somewhere else. Those 
files may be the wrong ones in your particular scenario, but most cases this 
strategy will prevent the exact opposite problem.

What you can do is add something like this to the default configuration file on 
64 bit hosts:

#ifdef cpui386
#ifdef linux
# prevent searching the default library directories
-Xd
# add the 32 bit-specific library directories
-Fl/usr/lib32
-Fl/other/32bit/directory
#endif
#endif

Patching the compiler source should not be necessary.

I'm afraid this isn't entirely correct. The problems arise when using -n in the command line (one 
example is compiling fpmake for packages directory). In this case any paths from fpc.cfg are 
ignored. Moreover, compiler silently ignores the absense of crti.o and company. The resulting 
executable manages to work somehow, but it is mostly by chance.


Regards,
Sergei



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

Re: [fpc-devel] Windows 64bit SEH exception handling

[Sergei Gorelkin]

19.06.2012 23:43, tomek пишет:

Hello,

with reference to http://bugs.freepascal.org/view.php?id=12742 about random 
crash with Windows
OpenDialog Box only on Win7 64bit.

Today I compile trunk-fpc with TEST_WIN64_SEH support and it seems that this 
bug is resolved with SEH.
I checked a few times to make sure that this is due to SEH support.

My question is, why? how is it possible that support for SEH exceptions 
handling fix OpenDialog issue ?
or perhaps an exception is hidden ? as described in 
http://support.microsoft.com/kb/976038

do have you any suggestions ?

Non-SEH exception handling on Win64 is known to handle exceptions too early, bypassing frame-based 
handlers and therefore disrupting the intended control flow. Most probably the exception under 
question was meant to be handled within OS libraries and not passed to the application.


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

Re: [fpc-devel] question about parameter loading code

[Sergei Gorelkin]

10.06.2012 20:26, Florian Klämpfl пишет:

Am 10.06.2012 08:15, schrieb Fuxin Zhang:

Dear sirs,

   When trying to generate code debuggable by GDB, I meet a problem:

* it seems mips C code will expect a frame pointer = sp after stack
adjustment
* but in cpupara.pas, when we create para info, we don't know yet the
whole stack size, thus the reference offset cannot be set correctly



This is exactly the point where I'am already stuck with MIPS for several
days/weeks. I'am still no sure what's the best solution ...

As far as I can understand, basically the same problem stands in the way of implementing compliant 
stack frames for x86_64-win64. I was thinking about a having a virtual framepointer register. We'll 
need to:

 - keep a list of all assembler instructions that reference this virtual FP 
register
 - after final frame size becomes known, fixup these instructions to reference a real FP with 
adjusted offset. Or maybe not keep a separate list of instructions, but instead just iterate the 
entire procedure asmlist (because about every second instruction is subject to fixup).


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

Re: [fpc-devel] WinCE support degraded?

[Sergei Gorelkin]

25.05.2012 15:53, Thaddy пишет:

AFAIK! and tested today, and only for kolce and fpc 2.5.1 wince works. Anything 
newer doesn't. (No
wince above 6.5)
I have no clue if it is the compiler or the libraries yet.

It is RTL, cpstrnew code imports GetConsoleCP and GetConsoleOutputCP functions which are absent in 
WinCE.


Sergei

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

[fpc-devel] Build failure on win64

[Sergei Gorelkin]

Hello,

I've just encountered 'make clean all OPT=-dTEST_WIN64_SEH' in trunk failure:

make ./msg2inc.exe
make[5]: Entering directory `C:/trunk/compiler'
C:/trunk/compiler/ppc3.exe -Ur -Xs -O2 -n -Fux86_64 -Fusystems -FuC:/trunk/rtl/units/x86_64-win64 
-Fix86_64 -FE. -FUx86_64/units/x86_64-win64 -dRELEASE -dTEST_WIN64_SEH -dx86_64 -dGDB -dBROWSERLOG 
-Fux86 -Sew -Owdevirtcalls,optvmts -FwC:/trunk/compiler/pp1.wpo -OWdevirtcalls,optvmts 
-FWC:/trunk/compiler/pp2.wpo -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew -FE. utils/msg2inc.pp

msg2inc.pp(823,1) Error: Undefined symbol: 
SYSUTILS$_$TMULTIREADEXCLUSIVEWRITESYNCHRONIZER_$__$$_DESTROY
msg2inc.pp(823,1) Fatal: There were 1 errors compiling module, stopping

While I'm not entirely sure whether this is caused by my local changes, the failed command looks 
suspicious at least.
Isn't it plain wrong to use WPO information from compiler to optimize msg2inc, a completely 
independent executable?


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

Re: [fpc-devel] Build failure on win64

[Sergei Gorelkin]

17.05.2012 15:44, Jonas Maebe пишет:


On 17 May 2012, at 13:39, Sergei Gorelkin wrote:


I've just encountered 'make clean all OPT=-dTEST_WIN64_SEH' in trunk failure:

make ./msg2inc.exe
make[5]: Entering directory `C:/trunk/compiler'
C:/trunk/compiler/ppc3.exe -Ur -Xs -O2 -n -Fux86_64 -Fusystems 
-FuC:/trunk/rtl/units/x86_64-win64 -Fix86_64 -FE. -FUx86_64/units/x86_64-win64 
-dRELEASE -dTEST_WIN64_SEH -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew 
-Owdevirtcalls,optvmts -FwC:/trunk/compiler/pp1.wpo -OWdevirtcalls,optvmts 
-FWC:/trunk/compiler/pp2.wpo -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew -FE. 
utils/msg2inc.pp
msg2inc.pp(823,1) Error: Undefined symbol: 
SYSUTILS$_$TMULTIREADEXCLUSIVEWRITESYNCHRONIZER_$__$$_DESTROY
msg2inc.pp(823,1) Fatal: There were 1 errors compiling module, stopping

While I'm not entirely sure whether this is caused by my local changes, the 
failed command looks suspicious at least.
Isn't it plain wrong to use WPO information from compiler to optimize msg2inc, 
a completely independent executable?


It indeed shouldn't be used for that. On the other hand, I don't understand why 
it would be recompiled during the WPO cycle, since how can the message files 
have changed since the last compilation of the regular cycle? (msg2inc should 
only be compiled if the message include files have to be regenerated)

This turned out to be a bug in 64-bit 'make' program that I was using. For some reason it started 
thinking that errore.msg is always newer than msgtxt.inc (although it was working fine last 8 months).
Using 32-bit make, the trunk builds successfully. This software is truly a never-ending source of 
surprises...


Regards,
Sergei

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

Re: [fpc-devel] Testing Intel/AMD AVX-Implemenation

[Sergei Gorelkin]

04.05.2012 10:39, Sven Barth пишет:

Am 03.05.2012 22:34, schrieb Torsten:

While we follow only a few formatting rules in the compiler,
I think this is very hard to read.
- What does rax86.IntToStr?

i need this for create warnings (check memory reference size) and i
don't like include a rtl unit.


SysUtils is already used in ~100 units in the compiler, so you can use it as 
well.


The compiler itself uses tostr function from cutils unit.

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

Re: [fpc-devel] Interface: Method resolution clauses

[Sergei Gorelkin]

30.04.2012 19:06, Marcos Douglas пишет:

Hi,

Can I, using FPC trunk, do this sintaxe?

type
   TMemoryManager = class(TInterfacedObject, IMalloc, IErrorInfo)
  function IMalloc.Alloc = Allocate;
  procedure IMalloc.Free = Deallocate;
 ...
end;

I'm using 2.6.1 and do not works.


To my knowledge, this kind of stuff should work.
What exact problem are you experiencing?

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

Re: [fpc-devel] Re: Whole Program Optimization with FPC 2.6.0?

[Sergei Gorelkin]

08.04.2012 11:33, Martin Schreiber пишет:

Am 07.04.2012 18:09, schrieb Martin Schreiber:

Am 07.04.2012 11:31, schrieb Martin Schreiber:

Hi,
A minimal MSEgui program compiled with FPC 2.6.0 is 711KB on
i386-win32 and
796KB on i386-linux.


BTW, the same MSEgui minimal program compiled with Delphi 7 has an exe
size of 571KB.


I made MSEgit Delphi compatible too:

FPC 2.6.0: 1.92MB
Delphi 7: 1.61MB

You might want to compare with FPC 2.7.1 after revision 20119, it is expected to generate smaller 
code for string and other managed type operations. For Lazarus executable I got about 10% total size 
decrease.


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

Re: [fpc-devel] Copy function and dynamic array

[Sergei Gorelkin]

29.02.2012 17:05, Sven Barth пишет:


It's not a bug in Delphi if they write it in the documentation. Whether we 
should copy this behavior
is the question (maybe only in Delphi mode).


It cannot be fixed for Delphi mode only because a single copy of RTL is used 
for all compiler modes.
The current situation where out of range 'length' parameter is adjusted but 'index' out of range 
raises exception is simply self-inconsistent. It is also inconsistent with behavior of Copy for strings.

Adjusting index will neither cause any buffer overflows nor make code slower, 
so it should be fixed.

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

Re: [fpc-devel] Copy function and dynamic array

[Sergei Gorelkin]

29.02.2012 18:21, LacaK пишет:

It cannot be fixed for Delphi mode only because a single copy of RTL is used 
for all compiler modes.
The current situation where out of range 'length' parameter is adjusted but 
'index' out of range
raises exception is simply self-inconsistent. It is also inconsistent with 
behavior of Copy for
strings.
Adjusting index will neither cause any buffer overflows nor make code slower, 
so it should be fixed.

Will you do it or should I register bug in bug tracker?


Please create a Mantis issue, so it won't be forgotten.

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

Re: [fpc-devel] TBytes

[Sergei Gorelkin]

28.02.2012 16:31, Marco van de Voort пишет:

In our previous episode, Sven Barth said:

handling completely again which seems to be possible according a thread
with Allen Bauer in Embarcadero forum. And please implement it before
AnsiStrings can't be used for the purpose anymore.


If you care about the repeated addition stuff, you should probably be check
out tstringbuilder.  It is said to performance better with string
concatenation then ansistring.  I never use it though, but that is partially
also because currently I don't work much with character data.


Do we already have a TStringBuilder?


I don't know. As said I don't use it :)


I use something like that in fcl-xml package, not in the form of a class but a record and a set of 
procedures (see xmlutils.pp: TWideStringBuf, BufAppend(), etc).


Regards,
Sergei

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

Re: [fpc-devel] Faster InitObject

[Sergei Gorelkin]

23.02.2012 13:16, Sven Barth пишет:


In August 2010 Florian already said that maybe FillChar should be optimized:
http://lists.freepascal.org/lists/fpc-devel/2010-July/021146.html (at the 
bottom)

In early 2011 I wrote an assembler implementation of FillChar for x86_64 (cannot be used for FreeBSD 
due to its toolchain problems), it executes approximately 4 times less instructions than generic 
version.


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

Re: [fpc-devel] copy for PChar

[Sergei Gorelkin]

19.02.2012 18:38, Mattias Gaertner пишет:

Hi,

When I use copy on a PChar (e.g. copy(p,1,1)), it is very slow,
because the compiler converts the PChar to a string.

Not sure why it is allowed in the first place. If out of Delphi compatibility, maybe we should leave 
it enabled for {$mode delphi} only (should be possible because copy is partially handled by compiler).



Is there already a function for PChar?

Can an overloaded version of copy be added?


It is a question how to interpret indices then (PChar is zero-based while 
strings are 1-based).
And actually it will mean 4 overloads: PChar, PWideChar, array of char, array 
of widechar.

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

Re: [fpc-devel] copy for PChar

[Sergei Gorelkin]

19.02.2012 20:34, Mattias Gaertner пишет:


Is there already a function

function Copy(StartPos: PChar; Count: PtrUInt; StopAt0: boolean =
true): string;

I don't know about an already existing such function (well, actually SetString used to work that way 
in the past, but no longer), but here's one (assuming StartPosnil):


var
  len: sizeint;
begin
  if StopAt0 then
  begin
len:=IndexByte(StartPos^,Count,0);
if len=-1 then
  len:=Count;
  end
  else
len:=Count;
  SetString(result,StartPos,len);
end;

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

Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT

[Sergei Gorelkin]

06.02.2012 20:39, Felipe Monteiro de Carvalho пишет:

Hello,

SysUtils for Windows utilizes only A Windows APIs, while it could use
W APIs in Windows NT. The attached patch starts correcting improving
the situation.

Advantages of the patch:

* Allows for unicode file names in TStringList.LoadFromFile if you
install paswstrings as the unicode manager.

Disadvantages of the patch:

* None that I can imagine.

Waiting for comments.

So, this is basically a first step of locking Windows RTL to use utf-8 by default and reducing 
chances it ever will call 'W' API without conversions?


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

Re: [fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT

[Sergei Gorelkin]

06.02.2012 23:45, Marco van de Voort пишет:

In our previous episode, Felipe Monteiro de Carvalho said:


1  makes it impossible to support Unicode and support Windows 9x at
the same time, but I doubt that Free Pascal wants to drop Windows 9x
support (even if it is obsolete).


Afaik we already have. Recent versions require patches for win9x

Just in case: I have written a small unicows.dll loader unit (under 10KBytes source code, in 
contrast with 300KByte Rob Kennedy's one) that can be used as a 'last goodbye' for win9x, allowing 
to switch most APIs to 'W'.
The only issue is that it needs to be executed as early as possible, ideally before system.pp 
initialization. This probably can be solved by redefining the entry point passed to linker, or by 
placing its code into yet another sysinit unit, which is selected for win9x.


If this is interesting I can provide more details.

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

Re: [fpc-devel] x86ins.dat

[Sergei Gorelkin]

07.01.2012 16:53, tgrundke пишет:

Hi,

i am working on the AVX-support for the fp-compiler.

Some AVX-assembler instructions have 4 operant e.g.


VBLENDVPD xmm1, xmm2, xmm3/m128, xmm4



INTEL Def.

3.1.1.2 Opcode Column in the Instruction Summary Table (Instructions
with VEX prefix)

/is4: An 8-bit immediate byte is present containing a source register specifier 
in
imm[7:4] and instruction-specific payload in imm[3:0].



I need a idea, how can i encode (in file x86ins.dat)  the 4th operant.

My idea:

new flag \77 = 4th operand is coded in bit 4-7 and the follow byte define the 
bits 0-3
e.g.

[VBLENDVPD]
(Ch_All, Ch_None, Ch_None)
xmmreg,xmmreg,xmmrm,xmmreg  \361\362\372\1\x4B\75\120\77\x00
AVX,SANDYBRIDGE

\ 361 = prefix 066h for SSE instruction
\ 362 = new flag VEX (starting with 0xC5 or 0xC4)
\ 372 = new flag VEX-CODE include prefix 0x0F3A
\ 75   = VEX-BYTE contains operand no. 2
\ 120 = operands 1 and 3 encoded in MODRM-Byte
\ 77   = immediate byte (bit 4-7) contains 4th operand
\ 00   = immediate byte (bit 0-3) = 0


i look forward to comments.

IMHO, since fpc's x86 assembler is based on NASM, the best way would be to stay as close to NASM 
format as possible.


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

Re: [fpc-devel] Manual reload of a DLL snapshot (with relocations) causes multiple AV

[Sergei Gorelkin]

06.01.2012 18:07, Gennadiy Poryev пишет:

= Preamble =



First, I'd like to know why calling of DLL entry point anew does not 
re-initialize _all_ RTL
internals regardless of what was remembered prior to taking the snapshot. Is it 
just assuming good
behavior of system loader that carefully zeroes data segment while I don't?

The data segment is not necessarily zeroed, it can contain non-zero initial values. Once you load 
DLL using LoadLibrary and let its entrypoint run, it will overwrite initialized part with new values 
and there is no way to recover the original values.

In particular, tlsindex global variable is initalized with value of -1, not 0.

Several APIs exist which allow to load the image without invoking its entrypoint. LoadLibraryEx, 
MapImage, etc. They vary in processing imports and relocations, though.


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

Re: [fpc-devel] Pointer cache for fast class/pointer access.

[Sergei Gorelkin]

05.01.2012 15:45, Marco van de Voort пишет:

In our previous episode, Sven Barth said:

Object instead Class?


They are basically similar to records with methods (which we now have
as well...) if you use them directly (this means: not as pointer types):
they are located on the stack and nested objects are part of the memory
structure of the object. But if you use references to objects you work
more like with classes as you have constructors, virtual methods and the
objects are then located on the heap (thus you need to care for the
memory management yourself).


Afaik records with methods is more advanced since they are initialized.

Afaik stack based TP Objects are not initialized and thus not safe for
automated types. (I looked into upgrading TV with ansistring a few years
back)


This is no longer correct, stack based objects are initialized and finalized if 
necessary.
There was indeed an issue with inheritance (if both ancestor and descendant contain managed members, 
then members of ancestor were not handled), but I personally fixed that in r16335 a year ago.


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

Re: [fpc-devel] Pointer cache for fast class/pointer access.

[Sergei Gorelkin]

05.01.2012 16:12, Marco van de Voort пишет:

In our previous episode, Sergei Gorelkin said:


This is no longer correct, stack based objects are initialized and
finalized if necessary.  There was indeed an issue with inheritance (if
both ancestor and descendant contain managed members, then members of
ancestor were not handled), but I personally fixed that in r16335 a year
ago.


r16335 is a commit by Michael?

r16335 | michael | 2010-11-13 16:51:43 +0100 (Sat, 13 Nov 2010) | 1 line

* Correction of PAFProtocols (Ivan Shikhalev, bug ID 17924


Mantis 16335 neither, that's about makefiles.


Oops... revision 16635 it is (more precisely, both 16632 and 16635). Sorry.

Sergei

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

Re: [fpc-devel] Misterious error

[Sergei Gorelkin]

04.01.2012 15:58, José Mejuto пишет:

Hello FPC,

Tuesday, January 3, 2012, 10:01:54 PM, you wrote:


Do you know which kind of code I must look for to isolate the problem
?

SG  I'd suggest looking at the constructors containing an 'exit' statement,
SG  but I'm not entirely sure.
SG  Does restoring removed line 287 of psub.pas remove the segfault?
SG  (The line was:
SG include(current_procinfo.flags,pi_needs_implicit_finally); )

No, it does not :( The problem seems to happend in a destroy process,
but as it only happends on close window, and in the close process a
lot of objects and interfaces are destroyed I can not track each one
:(

I was hoping otherwise... Actually it is very strange that reverting changes at line 700 (which you 
mentioned earlier) removes the crash, while reverting line 287 does not, because removing 
pi_needs_implicit_finally flag is the condition under which code at line 700 could ever execute.



I'll try to create a minimun project that fails, it would need a
firebird and zeoslib.


This is of course the best thing to do.

However, you can as well try the attached simple patch. It prevents temps referenced from 'finally' 
blocks from being placed to registers.


Regards,
Sergei
Index: nflw.pas
===
--- nflw.pas(revision 19960)
+++ nflw.pas(working copy)
@@ -2000,12 +2000,23 @@
 {*
TTRYFINALLYNODE
 *}
+function reset_regvars(var n: tnode; arg: pointer): foreachnoderesult;
+  begin
+case n.nodetype of
+  temprefn:
+make_not_regable(n,[]);
+end;
+result:=fen_true;
+  end;
 
 constructor ttryfinallynode.create(l,r:tnode);
   begin
 inherited create(tryfinallyn,l,r,nil,nil);
 include(current_procinfo.flags,pi_uses_exceptions);
 implicitframe:=false;
+{ Setting pi_uses_exceptions forces local vars to memory, but not 
temps.
+  Make temps non-regable here. }
+foreachnodestatic(r,@reset_regvars,nil);
   end;
 
 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Misterious error

[Sergei Gorelkin]

03.01.2012 23:54, José Mejuto пишет:

Hello FPC,

Monday, January 2, 2012, 9:27:50 PM, you wrote:


The solution to optimize the unnecessary finally blocks without
breaking exit behavior is still to
be found.

SG  More sophisticated patch applied in r19955. If you can test
SG  your project with it, that would be just
SG  great.

I had updated to 19958 and it still fails with the same SIGSEGV. Again
adding the try..finally..end in the function cures the problem.

[Updating to 19959 to test as my code uses Variants...Done]

No sorry, still the same SIGSEGV :(

Do you know which kind of code I must look for to isolate the problem
?


I'd suggest looking at the constructors containing an 'exit' statement,
but I'm not entirely sure.

Does restoring removed line 287 of psub.pas remove the segfault?
(The line was:
  include(current_procinfo.flags,pi_needs_implicit_finally); )

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

Re: [fpc-devel] Misterious error

[Sergei Gorelkin]

31.12.2011 23:17, José Mejuto пишет:


SG  Plain removal of this if..else breaks a couple of tests in
SG  the testsuite. But the information you
SG  provided gives some pointers to look at. At least, adding a
SG  check that constructor without
SG  pi_needs_implicit_finally flag doesn't have any implicit
SG  finalization code either will help
SG  detecting the actual place of trouble.
SG  I'll review it.

I'll be very happy in test any change you may want to try before
commit to SVN. This kind of problems seems to be very difficult to
catch, so I'll try to not change my codebase while you investigate in
order to be able to raise the error as needed.

Another hint, my problem appears at close time and only if a debugger
is present. If no debugger the operative system eats the error and
nothing is reported.


The problem appears to be that the implicit finally block in constructors does not only finalize 
managed variables and temps, but also reposition the exit label so 'exit' statements do not jump 
over the AfterConstruction call. Removing this implicit finally block, as well as compiling with 
{$implicitexceptions off}, breaks the correct behavior.
For now, I reverted part of r19668 in r19948, so implicit finally blocks are not optimized, and 
added a test.
The solution to optimize the unnecessary finally blocks without breaking exit behavior is still to 
be found.


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

Re: [fpc-devel] Misterious error

[Sergei Gorelkin]

02.01.2012 14:16, Sergei Gorelkin пишет:

31.12.2011 23:17, José Mejuto пишет:


I'll be very happy in test any change you may want to try before
commit to SVN. This kind of problems seems to be very difficult to
catch, so I'll try to not change my codebase while you investigate in
order to be able to raise the error as needed.

Another hint, my problem appears at close time and only if a debugger
is present. If no debugger the operative system eats the error and
nothing is reported.


The problem appears to be that the implicit finally block in constructors does 
not only finalize
managed variables and temps, but also reposition the exit label so 'exit' 
statements do not jump
over the AfterConstruction call. Removing this implicit finally block, as well 
as compiling with
{$implicitexceptions off}, breaks the correct behavior.
For now, I reverted part of r19668 in r19948, so implicit finally blocks are 
not optimized, and
added a test.
The solution to optimize the unnecessary finally blocks without breaking exit 
behavior is still to
be found.

More sophisticated patch applied in r19955. If you can test your project with it, that would be just 
great.


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

Re: [fpc-devel] Misterious error

[Sergei Gorelkin]

31.12.2011 16:58, José Mejuto пишет:

Hello Jonas,

Wednesday, December 28, 2011, 2:43:16 PM, you wrote:

JM  The most likely problem is memory corruption by your program.
[...]
JM  give more accurate diagnostics).

A bit more information:

Environment is win32.

The line that raises the exception is in win32callback.inc 2474:

---
 if (Msg=WM_CHAR) and (WParam=VK_RETURN) and
((lWinControl is TCustomCombobox) or
 ((lWinControl is TCustomEdit) and not (lWinControl is TCustomMemo ))
)
 then
   // this thing will beep, don't call defaultWindowProc
 else
   PLMsg^.Result := CallDefaultWindowProc(Window, Msg, WParam, LParam);
---

The CallDefaultWindowProc.

If I change the line to:

   try
   PLMsg^.Result := CallDefaultWindowProc(Window, Msg, WParam, LParam);
   finally
   end;

The problem dissapears.

* In the same function, if I declare an ansistring type, just the
declare only, it works.

When you do either of the above, it effectively disables optimizations, forcing a ebp-based stack 
frame and putting all variables to memory. The same effect should be achievable by compiling with 
-O- or -O1 switches.



* If the CallDefaultWindowProc declaration is changed to stdcall it
also works fine.


Don't know what's actually changed in this case.

r19668 affects codegeneration of constructors and custom enumerators, and fixes 
http://bugs.freepascal.org/view.php?id=20827
The reported location of crash in your case is likely unrelated to the actual location of problem. 
At least, function WindowProc from win32callback.inc is not affected by r19668, as it isn't a 
constructor and doesn't involve exception handling in unmodified form.
If your code contains constructors which use interfaces, I'd suggest them as the place to look at or 
try to modify.


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

Re: [fpc-devel] -Oodfa

[Sergei Gorelkin]

30.12.2011 14:42, Jonas Maebe пишет:


On 30 Dec 2011, at 10:26, Florian Klämpfl wrote:


Beta. I'am not aware of any missing stuff, but it's mainly untested.


I tried to activate by default it during the development of the JVM port (since 
the JVM will abort if it detects an uninitialized read), but it caused compiler 
crashes. I'll see if I can create isolated test cases.

The present DFA doesn't work for code which uses exceptions, including implicit exception handling 
(read: a good 50% of all codebase).
In the meantime I tried adapting DFA, or more precisely, definite assignment analyzer, from Mono 
compiler (Mantis #15523). It uses a different approach, which works fine with exceptions, but is not 
suited well (if at all) for determining live range of variables. See notes on Mantis #15523 for details.
With #15523 applied, the compiler can be cycled, but it emits hundreds of warnings which have to be 
fixed because cycling is done with -Sew these days. In particular, we have to solve the FillChar() 
issue before any DFA is enabled by default.


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

Re: [fpc-devel] -Oodfa

[Sergei Gorelkin]

30.12.2011 15:18, Florian Klämpfl пишет:


I played with this yesterday and what about extended Initialize to
support unmanaged types? In case of an unmanaged type it just calls
fillchar.


I was rather thinking about 'varout' (or so) parameter type, which was suggested already several 
times in the past.
Extending Initialize is a) different from Delphi (Delphi ignores initialize(unmanaged_type)), b) 
does not affect already existing code, c) not applicable to all cases where FillChar is used (e.g. 
FillChar(x, sizeof(foo)+n*sizeof(bar))


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

Re: [fpc-devel] Paramstr trailing spaces, bug or not?

[Sergei Gorelkin]

23.12.2011 16:18, Marco van de Voort пишет:

- syswin.inc code looks like any number of delimiters between parameters
   are skipped.


.. unless quoted.


- this extra whitespace is added by the makefile, suggesting some 
buggy/incorrect processing in
make.exe or makefile itself.


It could be that the makefile logic quotes every argument on windows, in
case of spaces. We would need a kind of strace tool for Windows to find out.


... it is the trailing backslash escaping the following character (C style).
I could reproduce the issue, by using the following command in 'packages' 
directory:

make install PP=f:\trunk\compiler\ppc386.exe PREFIX=f:\lazarus\fpc\2.7.1\

Note the quotes, and also note where they end up in output:

make -C fcl-base install
make[1]: Entering directory `F:/trunk/packages/fcl-base'
.\fpmake.exe install --localunitdir=../.. --globalunitdir=.. --os=win32 --cpu=i386 -o 
-Fu../../rtl/units/i386-win32 -o -Fu../../packages/hash/units/i386-win32 -o 
-Fu../../packages/paszlib/units/i386-win32 -o -Fu../../packages/fcl-process/units/i386-win32 -o 
-Fu../../packages/fpmkunit/units/i386-win32 -o -FE. -o -FUunits/i386-win32 -o -di386 
--compiler=f:/trunk/compiler/ppc386.exe --prefix=f:\lazarus\fpc\2.7.1 
--unitinstalldir=f:\lazarus\fpc\2.7.1/units/i386-win32/fcl-base

The installer encountered the following error:
Failed to create directory f:\lazarus\fpc\2.7.1 
--unitinstalldir=f:\lazarus\fpc\2.7.1\units\i386-win32\fcl-base\units\i386-win32\fcl-base\

make[1]: *** [install] Error 1

Without quotes the result is basically the same:

.\fpmake.exe install --localunitdir=../.. --globalunitdir=.. --os=win32 --cpu=i386 -o 
-Fu../../rtl/units/i386-win32 -o -Fu../../packages/hash/units/i386-win32 -o 
-Fu../../packages/paszlib/units/i386-win32 -o -Fu../../packages/fcl-process/units/i386-win32 -o 
-Fu../../packages/fpmkunit/units/i386-win32 -o -FE. -o -FUunits/i386-win32 -o -di386 
--compiler=f:/trunk/compiler/ppc386.exe --prefix=f:\lazarus\fpc\2.7.1\ 
--unitinstalldir=f:\lazarus\fpc\2.7.1\/units/i386-win32/fcl-base

The installer encountered the following error:
Failed to create directory f:\lazarus\fpc\2.7.1 
--unitinstalldir=f:\lazarus\fpc\2.7.1\\units\i386-win32\fcl-base\units\i386-win32\fcl-base\


Finally, when trailing backslash is duplicated, everything runs successfully.

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

Re: [fpc-devel] Paramstr trailing spaces, bug or not?

[Sergei Gorelkin]

23.12.2011 1:26, Joost van der Sluis пишет:


What I did was this: 'make install PREFIX=c:\lazarus\fpc\2.7.1\' the
trailing backslash is important...

Then make runs (among others) the following command:
.\fpmake.exe install --localunitdir=../.. --globalunitdir=.. --os=win32 
--cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o 
-FuC:/svn/fpc-trunk/rtl/units/i386-win32 -o 
-FuC:/svn/fpc-trunk/packages/hash/units/i386-win32 -o 
-FuC:/svn/fpc-trunk/packages/paszlib/units/i386-win32 -o 
-FuC:/svn/fpc-trunk/packages/fcl-process/units/i386-win32 -o 
-FuC:/svn/fpc-trunk/packages/fpmkunit/units/i386-win32 -o -FE. -o 
-FUunits/i386-win32 -o -di386 -o -dRELEASE 
--compiler=C:/svn/fpc-trunk/compiler/ppc386.exe --prefix=c:\lazarus\fpc\2.7.1\  
--unitinstalldir=c:\lazarus\fpc\2.7.1\/units/i386-win32/fcl-base -ie -d

Note the two spaces after the prefix. Which result in the error message
that the directory c:\lazarus\fpc\2.7.1 \bin coudn't be created. (Note
the space)

Can you reproduce that? I tried with a simple hello-world kind of
application and in that case I can't reproduce it either.

This is on Windows 7 in a virtual machine. (kvm)


Just some notes:
- syswin.inc code looks like any number of delimiters between parameters are 
skipped.
- this extra whitespace is added by the makefile, suggesting some buggy/incorrect processing in 
make.exe or makefile itself.
- the extra character may be not a whitespace (#32), but something looking like one (e.g. 
non-breaking space with code #160)


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

Re: [fpc-devel] Re: out vs. var

[Sergei Gorelkin]

28.11.2011 14:26, Sven Barth пишет:

Am 28.11.2011 12:02, schrieb Michael Müller:

Additionally, if you use the -gt command line option then the compiler will 
overwrite the
contents of (non-reference-counted) out-parameters in the function entry code. 
This switch will
do nothing for open array parameters though, because it lacks support for using the 
hidden high
parameter to determine the bounds of the array at run time.


I don't understand this restriction. In the code High() works for open arrays 
at run time.


I suppose that the -gt code is generated on a lower level, so it can't just 
use High(), but would
need to access the hidden parameter that contains the array length directly. 
And that part is simply
not implemented, so open arrays are not handled.


Yes, this is simply an unimplemented feature.

Sergei

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