Hi everyone,

I have a little question.  I'm having problems compiling fpc under x86_64-linux.  At first I thought it was a bug in one of my changes, but it seems to occur on the trunk as well.  After successfully compiling the compiler a few times, the following happens:

/usr/bin/diff ppc3 ppcx64
Binary files ppc3 and ppcx64 differ

And then it drops out.  I've tried the usual things of doing a "make distclean", but am I missing something obvious?  Preliminary Linux testing is the only thing I'm missing before I'm ready to present a patch.

Gareth aka. Kit

Never mind.  Got it working after I got a clean copy ("svn update" then "svn revert -R .") - now the adventure continues!

Gareth aka. Kit

On Fri 30/11/18 13:39 , "J. Gareth Moreton"
sent:
Hi everyone,

I have a little question.  I'm having problems compiling fpc under x86_64-linux.  At first I thought it was a bug in one of my changes, but it seems to occur on the trunk as well.  After successfully compiling the compiler a few times, the following happens:

/usr/bin/diff ppc3 ppcx64
Binary files ppc3 and ppcx64 differ

And then it drops out.  I've tried the usual things of doing a "make distclean", but am I missing something obvious?  Preliminary Linux testing is the only thing I'm missing before I'm ready to present a patch.

Gareth aka. Kit

Actually still having lots of problems here.  Can anyone give me some advice?  Admittedly my skills with Linux are lacking, but I would like to get it to build on x86_64-linux before I submit my patch to everyone.

What I've discovered so far is that if I pull a clean copy from the SVN trunk, it builds without a problem, but if I change one of the source files or do "make clean", it fails with that diff error.

Gareth aka. Kit

On Fri 30/11/18 15:36 , "J. Gareth Moreton"
sent:
Never mind.  Got it working after I got a clean copy ("svn update" then "svn revert -R .") - now the adventure continues!

Gareth aka. Kit

On Fri 30/11/18 13:39 , "J. Gareth Moreton"
sent:
Hi everyone,

I have a little question.  I'm having problems compiling fpc under x86_64-linux.  At first I thought it was a bug in one of my changes, but it seems to occur on the trunk as well.  After successfully compiling the compiler a few times, the following happens:

/usr/bin/diff ppc3 ppcx64
Binary files ppc3 and ppcx64 differ

And then it drops out.  I've tried the usual things of doing a "make distclean", but am I missing something obvious?  Preliminary Linux testing is the only thing I'm missing before I'm ready to present a patch.

Gareth aka. Kit

The following make command worked (and has worked many times) for me with latest trunk to rebuild trunk:

make FPC=~/fpc/installs/lib/3.0.4/ppcx64 clean all

Linux Mint 19 64 bit

This means that the compiler generates wrong code which results in wrong code generation :). These things are very hard to debug. The only way is to compare the disassembly manually to find out where it differs and then to debug why it generates this particular code at that location.

Preliminary Linux testing is the only thing I'm missing before I'm ready to present a patch.

Did you run regression tests?

The only thing I've managed to run so far
is the standard "make all". What's
mysterious though is that if I grab a
clean copy from the trunk, it builds fine.
However, if I do "make clean" first, that
error appears. Does anyone else get this?
(I'm using Ubuntu and compiling on x86_64)

I managed to get an assembly dump of
system.pp and compare the output between
ppc1, ppc2 and ppc3. Some procedures in
ppc3 look very different, as if compiled
by an older version of the compiler. It's
confusing, but I'll don't want to scrap my changes, because so far I've managed to make -O3 about 15%
faster.

Gareth aka. Kit

On Sat 01/12/18 09:05 , "Florian Klämpfl"
sent:

Am 30.11.2018 um 14:39 schrieb J. Gareth

Moreton:

linux.  At first I thought it was

a bug in one > of my changes, but it seems to occur

on the

trunk as well.  After successfully

compiling the compiler a few times,

distclean", but am I missing

something obvious? This means that the compiler generates

wrong code which results in wrong

code generation :). These things are

very hard

to debug. The only way is to compare the

disassembly manually to find out

where it differs and then to debug why

it

generates this particular code at that

location.

> Preliminary Linux testing is the only

thing I'm

missing before I'm ready to present a

patch.

I must have something configured incorrectly - I'm still getting the error.  Apologies for bugging everyone.

Gareth aka. Kit

On Sat 01/12/18 06:14 , "Christo Crause" sent:
On Sat, 1 Dec 2018, 01:37 J. Gareth Moreton

Thanks Bart,
I managed to get it to build after reinstalling the FPC compiler 3.0.4 - it seems it was getting confused between two different versions on my virtual machine - but after all that it does look like a bug in my new code.  I've managed to get it to compile from a clean build and with a couple of modified files that don't do anything drastic, so now I'll try to isolate the issue and update my patch file.  An overhauled peephole optimizer is no use if it breaks Linux!

Thanks for the tips everyone.

Gareth aka. Kit

On Sat 01/12/18 17:03 , "Bart" sent:

PM J. Gareth Moreton wrote

/usr/bin/diff ppc3 ppcx64 Binary files ppc3 and ppcx64 differ And then it drops out. I've tried the usual things of doing a "make

distclean", but am I missing something obvious? Preliminary Linux testing is the only thing I'm missing before I'm ready to present a patch.

Works for me here.
svn co https://svn.freepascal.org/svn/fpc/trunk [1] . make

# after succesfull make:
make clean all

Fpc r40425, on Linux Mint 18.2 64-bit using fpc 3.0.4 as starting compiler.

PM J. Gareth Moreton wrote

/usr/bin/diff ppc3 ppcx64 Binary files ppc3 and ppcx64 differ And then it drops out. I've tried the usual things of doing a "make distclean", but am I missing something obvious? Preliminary Linux testing is the only thing I'm missing before I'm ready to present a patch.

Works for me here.
svn co https://svn.freepascal.org/svn/fpc/trunk .
make

# after succesfull make:
make clean all

Fpc r40425, on Linux Mint 18.2 64-bit using fpc 3.0.4 as starting compiler.

Aw, okay.  Well, post peephole is still a separate stage, since that prevents a lot of other optimisations (e.g. changing mov 0,%reg into xor %reg,%reg).

I'll start breaking it up into smaller chunks.

Gareth aka. Kit

On Sat 01/12/18 19:54 , Florian Klämpfl sent:

J. Gareth Moreton wrote

Thanks Bart, I managed to get it to build after reinstalling the FPC compiler 3.0.4 -

it seems it was getting confused between two

different versions on my virtual machine - but after all that it does

look like a bug in my new code.  I've managed to

get it to compile from a clean build and with a couple of modified files

that don't do anything drastic, so now I'll try

to isolate the issue and update my patch file.  An overhauled peephole

optimizer is no use if it breaks Linux!

I had a quick look at the patch and I strongly recommend to split it in multiple patches which can be reviewed more
easily. This allows also to detect easier which change breaks things and also to measure which change increases speed
and which change is not needed.

In general, I am not happy with the merge of the four passes as it makes maintenance much harder.

I admit I do wonder how hard maintenance will be.  True, there is some more looking ahead, but it's not really any more complex than what it is already (e.g. take a look at OptPass1MOV in the trunk).

When it comes to debugging the peephole optimiser, one thing I did was write a function that wrote the assembly of the current block to the console, so I could visually see the commands ahead.  It's not part of the submitted patches because it only works for i386 and x86_64 under Windows, but it's proven useful.
If there's interest, I can submit it as a separate patch, but it's not really suitable as a permanent fixture unless someone wants to try to make it a feature only enabled with debug defines.

Gareth aka. Kit

On Sat 01/12/18 18:57 , "J. Gareth Moreton"
sent:
Aw, okay.  Well, post peephole is still a separate stage, since that prevents a lot of other optimisations (e.g. changing mov 0,%reg into xor %reg,%reg).

I'll start breaking it up into smaller chunks.

Gareth aka. Kit

On Sat 01/12/18 19:54 , Florian Klämpfl sent:

J. Gareth Moreton wrote

Thanks Bart, I managed to get it to build after reinstalling the FPC compiler 3.0.4 -

it seems it was getting confused between two

different versions on my virtual machine - but after all that it does

look like a bug in my new code.  I've managed to

get it to compile from a clean build and with a couple of modified files

that don't do anything drastic, so now I'll try

to isolate the issue and update my patch file.  An overhauled peephole

optimizer is no use if it breaks Linux!

I had a quick look at the patch and I strongly recommend to split it in multiple patches which can be reviewed more
easily. This allows also to detect easier which change breaks things and also to measure which change increases speed
and which change is not needed.

In general, I am not happy with the merge of the four passes as it makes maintenance much harder.

I had a quick look at the patch and I strongly recommend to split it in multiple patches which can be reviewed more easily. This allows also to detect easier which change breaks things and also to measure which change increases speed and which change is not needed.

In general, I am not happy with the merge of the four passes as it makes maintenance much harder.