Hi, fpc community!

I try to compile fpc on my Toshiba AC100 smartbook (tegra 2 - ARM Cortex-A9 CPU), with Ubuntu 11.04 Natty, but have a problem: First, I have download precompiled fpc from ftp://ftp.freepascal.org/pub/fpc/dist/2.4.4/arm-linux/ It installs good and makes "Hello world" program correctly.

Next I try to compile mseide. It does, but mseide crashes on start. Some detailed information about it is here (on Russian): http://freepascal.ru/forum/viewtopic.php?f=1&t=7300&start=15#p56281

Next step I try to update complier from svn (using "make all"), but it fails:

1) revision 19056:
compiler hangs on second cycle of system.pp (blank screen and 100% cpu load): ===============
make -C /home/sash0k/arm-coding/fpc/fpc/rtl 'OPT=' all make[6]: Вход в каталог `/home/sash0k/arm-coding/fpc/fpc/rtl' make -C linux all
make[7]: Вход в каталог `/home/sash0k/arm-coding/fpc/fpc/rtl/linux' as -o /home/sash0k/arm-coding/fpc/fpc/rtl/units/arm-linux/prt0.o arm/prt0.as as -o /home/sash0k/arm-coding/fpc/fpc/rtl/units/arm-linux/dllprt0.o arm/dllprt0.as as -o /home/sash0k/arm-coding/fpc/fpc/rtl/units/arm-linux/cprt0.o arm/cprt0.as as -o /home/sash0k/arm-coding/fpc/fpc/rtl/units/arm-linux/gprt0.o arm/gprt0.as as -o /home/sash0k/arm-coding/fpc/fpc/rtl/units/arm-linux/ucprt0.o arm/ucprt0.as /home/sash0k/arm-coding/fpc/fpc/compiler/ppc2 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../arm -Fi../unix -Fiarm -FE. -FU/home/sash0k/arm-coding/fpc/fpc/rtl/units/arm-linux -darm -dRELEASE -Us -Sg system.pp ===============
where "/home/sash0k/arm-coding/fpc/fpc" is path to compiler sources.

2) update to revision 19149:
compilation process crashes after beginnig with Exception and "Error 217": ===============
make -C utils cleanall
make[6]: Вход в каталог `/home/sash0k/arm-coding/fpc/fpc/compiler/utils' /bin/rm -f fpc ppufiles ppudump ppumove fpcsubst mkarmins mkx86ins fpc.o ppufiles.o ppudump.o ppumove.o fpcsubst.o mkarmins.o mkx86ins.o libpfpc.a libpppufiles.a libpppudump.a libpppumove.a libpfpcsubst.a libpmkarmins.a libpmkx86ins.a libimpfpc.a libimpppufiles.a libimpppudump.a libimpppumove.a libimpfpcsubst.a libimpmkarmins.a libimpmkx86ins.a /bin/rm -f units/arm-linux/ppu.ppu units/arm-linux/crc.ppu units/arm-linux/usubst.ppu /bin/rm -rf units
/bin/rm -f *.o *.ppu *.rst *.s *.a *.so *.ppl
/bin/rm -rf *.sl
/bin/rm -f fpcmade.* Package.fpc ppas.sh script.res link.res /bin/rm -f *_ppas.sh
make[6]: Выход из каталога `/home/sash0k/arm-coding/fpc/fpc/compiler/utils' /bin/rm -rf arm/units
/bin/rm -f arm/*.o arm/*.ppu arm/*.rst arm/*.s arm/*.a arm/*.so arm/*.ppl /bin/rm -f arm/ppc386 arm/ppc68k arm/ppcx64 arm/ppcppc arm/ppcsparc arm/ppcppc64 arm/ppcarm arm/ppcmips arm/ppcmipsel arm/ppcarm /bin/rm -f ppcarm
/bin/mkdir -p arm/units/arm-linux
/usr/bin/ppcarm -Ur -Xs -O2 -n -Fuarm -Fusystems -Fu/home/sash0k/arm-coding/fpc/fpc/rtl/units/arm-linux -Fiarm -FE. -FUarm/units/arm-linux -dRELEASE -darm -dGDB -dBROWSERLOG pp.pas Fatal: Compilation aborted
An unhandled exception occurred at $000343AC :
EInOutError : File not found
$000343AC
$000FA478
$0010AB08
$0010E648
$0010E664
$0010E664
$0010E664
$0010ED90
$001130F0
$000FE6D8
$000FEC08
$00144F18
$001243AC
$0013A984
$001442A4
$00144E54
$001243AC

make[5]: *** [ppcarm] Ошибка 217
make[5]: Выход из каталога `/home/sash0k/arm-coding/fpc/fpc/compiler' make[4]: *** [next] Ошибка 2
make[4]: Выход из каталога `/home/sash0k/arm-coding/fpc/fpc/compiler' make[3]: *** [ppc1] Ошибка 2
make[3]: Выход из каталога `/home/sash0k/arm-coding/fpc/fpc/compiler' make[2]: *** [cycle] Ошибка 2
make[2]: Выход из каталога `/home/sash0k/arm-coding/fpc/fpc/compiler' make[1]: *** [compiler_cycle] Ошибка 2
make[1]: Выход из каталога `/home/sash0k/arm-coding/fpc/fpc' make: *** [build-stamp.arm-linux] Ошибка 2
===============

So, what can I do next? My goal is get stable fpc + mseide for Toshiba AC100 device.

a) use fpc 2.6 branch
b) use any revision before cpstrnew merge
c) wait while we fix new problems

Best regards,
Paul Ishenin

Sash0k wrote

So, what can I do next? My goal is get stable fpc + mseide for Toshiba AC100 device.

I've built fpc trunk successfully on my AC100. I will check which revision worked tonight.

Henry

To fix the problem with the linker EABI error, you need to override the call to the assembler from the compiler. You can do this by creating a shell script called "as", which calls the real "as" with the original parameters and an extra parameter, which goes something like -meabi=5

To get this to work, you'll have to revert to revision 18269, build the compiler, then use that compiler as a starting compiler to build trunk. This worked for me. I don't know how the fpc team deals with this normally.

Henry

Compiling the trunk compiler is only supported when using the latest release (currently 2.4.4) as a starting compiler.

Regards,
Sven

That's all very well, but if it crashes trying to build the compiler it's not much use to me.

Henry

I've now looked closer at the errors reported by Sash0k.

In the first case a compiler dev would try to fix the compiler, because the error happens in the newly compiled compiler.

The second case is interesting indeed. It's a pity that we don't know what failed exactly in the compile... one would need a 2.4.4 with included debug information for that.

Regards,
Sven

Sven Barth wrote

The second case is interesting indeed. It's a pity that we don't know what failed exactly in the compile... one would need a 2.4.4 with included debug information for that.

If I were to build one, what can be done to remedy the problem? This is what I meant by saying "I don't know how the fpc team deals with this..."

Henry

Which, stating the obvious, is difficult when the available binary is got from there to 2.4 via (I think) 2.5 with Jonas's help, and since then have moved it between local machines as a binary. I can confirm that 2.4.4 will build FPC trunk (2.7.1) on ARM, and that that can build Lazarus trunk.

In that case the debug trace would contain the line information and thus the problematic code could be spotted and probably fixed (normally in 2.4.5, 2.6 and trunk, if the error exists till today).

Another possiblity is to run the (2.4.4) compiler inside the IDE (don't know whether this would work that well on an ARM based computer) and debug down to the critical code.

Regards,
Sven

Yes, thanks, I know how line information works. Maybe I should state my question more bluntly: What is the point of debugging and old compiler?

ftp://ftp.freepascal.org/pub/fpc/dist/2.4.4/arm-linux/ Could it be that your system and the distributed 2.4.4 compiler have different settings (e.g. OABI vs. EABI, floating point)?

@Sash0k: maybe that would be interesting for you to check as well. Which ABI still does your computer use? And which floating point system? Can you use the distributed 2.4.4 compiler on your system for compiling a hello world application?

Though I need to admit that I'm not an ARM expert, so I might not be of much help here...

Regards,
Sven

Mark Morgan Lloyd wrote

I got from there to 2.4 via (I think) 2.5 with Jonas's help, and since then have moved it between local machines as a binary. I can confirm that 2.4.4 will build FPC trunk (2.7.1) on ARM, and that that can build Lazarus trunk.

I got 2.4.4 here:

ftp://ftp.freepascal.org/pub/fpc/dist/2.4.4/bootstrap/

Maybe we should upload your 2.4.4 ppcarm if it compiles trunk without problems.

Henry

As I said: The official statement regarding compiling trunk is that you must use the latest release to be on supported ground. If the promise of this statement is not kept by reality then this is a bad sign.

Of course one could try to reproduce the problem using a trunk compiler and then the fix could be backported to the old release.

In both cases (debugging the old one; using a trunk compiler) the target is to fix the old release so that a new release based on the old release branch (a hypothetical 2.4.6) would be able to compile trunk (or more importantly the next release (e.g. 2.6)) again.

Regards,
Sven

Toshiba AC100 is armel (arm eabi) while fpc arm-linux (arm oabi)? While this might work under certain circumstances, I wouldn't bet on it.

Hi,

That is a known issue with 2.4.4 that it does not compile trunk with optimization turned on. There seems to be a bug that has been existing for a long time that has been triggered by code changes in 18230; the ARM compiler is not as well maintained as others.

I think 2.4.4 definitely builds when specifying -O- as extra build options though. I am working on it, however I fear that -O- will need to be set for some time.

@henry: thanks for finding the revision when compilation broke.

The currently supported ABI is EABI on linux only. I do not think oabi still works (never tried). We also only do daily testsuite runs with soft fp (e.g. -Cfsoft enabled), armv5.

Thomas

2.4.4 ppcarm seems to be eabi:

readelf -h arm-linux-ppcarm | grep Flags
Flags: 0x4000002, has entry point, Version4 EABI

Henry

I think it breaks for me even if optimizations are turned off, but I'll double check.

@henry: thanks for finding the revision when compilation broke.

The revision I gave is just my last known good compile. I can try and bisect if that'll be useful.

Henry

Important caveat: it compiles trunk on a Qemu-emulated system as described at http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators However this being the case, such a system should be a good starting point if somebody then needed to progress to e.g. different FP support.

I routinely build enough for my own use using the contents of fpcbuild/fpcsrc, would that be adequate (and how do I do the final packaging stage) and whither should I upload it?

On the other hand it's worth noting that I too am using -O-, so if there's already a usable binary at the URL above I can't better it.

However I'd suggest that somebody update the main website to point to it, even if it has an attached health warning.

Sven Barth wrote

Compiling the trunk compiler is only supported when using the latest release (currently 2.4.4) as a starting compiler.

where in the SVN can this be pulled from, please. would it be (from memory) tags/release_2_4_4?

Yes, but you'll need a compiler of the previous release (2.4.2) for that one.

Regards,
Sven

Hi,

Unfortunately this seems to be true, need to investigate further. However there is another bug regarding optimizations.

> @henry: thanks for finding the revision when compilation broke. The revision I gave is just my last known good compile. I can try and bisect if that'll be useful.

I found that 18251 is okay, but the newer ones are not when compiling with -O2. It seems that one optimization that transforms expressions of type x*x into sqr(x) for floats in 18252 (and 18257 and 18263 that seem to have been fixing issues with the original implementation) causes troubles. With that in place, a compiler cycle hangs at ppc2 compiling something (processing real2str.inc from the system unit fyi).

Florian, Jonas, any ideas? Seems to be related to softfloat code generation because apparently other platforms are fine.

Thomas

So I wonder what version/revision Delphi uses?

Hi,

The build that is used is the build with softfloat support (it's the only one we provide), which may be the only one that is affected by the recent bug(s), i.e. it is used as a starting compiler (in the original email). Further, reading Sash0k's original email again, he might be able to avoid the issue by cross-compiling a start compiler to ARM from a current trunk compiler enabling VFP (hardware FP) support. See http://wiki.freepascal.org/iPhone/iPod_development#Building_an_ARM_Cross-compiler for ideas.

Btw, I'm not sure what FP type is using in his build because he does not specify.

Delphi cross-compiles too, so it might be okay.

Thomas

The optimization changes x*x into sqr(x). For ARM/softfloat, the compiler calls the fpc_sqr_real() helper from the RTL.

The code of this helper is:

     function fpc_sqr_real(d : ValReal) : ValReal;compilerproc;{$ifdef
MATHINLINE}inline;{$endif}
     begin
       result := d*d;
     end;

So yes, this clearly puts the compiler into an endless loop. I'm not sure what would be a clean fix for this (other than completely disabling the transformation; does it improve the generated code that much beyond what CSE can achieve?)

Jonas

Thomas Schatzl wrote

Btw, I'm not sure what FP type is using in his build because he does not specify.

He wrote it in the mail titled "Re: fpc-devel Digest, Vol 89, Issue 82":

=== quote begin ===

Toshiba AC100 have 2 Cortex-A9 cores. Arm architecture is "armv7" I use Ubuntu 11.04 armel. It means: ARM, EABI, Little Endian. Float point mode now is "softfloat".
But in the future I plan to migrate to Debian hardfloat port: http://wiki.debian.org/ArmHardFloatPort

=== quote end ===

Regards,
Sven

Hi,

Other options I see:
- disable if using softfloat knowing that the soft float code just transforms this into the same code sequence again
- move it to i386 specific optimizations since afaik it is the only arch which has an instruction which benefits from that.

disabling the transformation; does it improve the generated code that much beyond what CSE can achieve?)

I doubt it has any noticeable impact.

Thomas

-O2 doesn't optimize the follow into a new call to fpc_sqr_real (svn 18901):

function fpc_sqr_real(d : ValReal) : ValReal;compilerproc;inline;
Begin
  fpc_sqr_real:=d;
  fpc_sqr_real:=fpc_sqr_real*d;
End;

Ludo

i believe i do... i use macros douglas' (i think i got the name right) method from the wiki... one of the first steps is to pull down a bootstrap compiler and tools... i don't believe that that compiler is altered during the script/make run...