[fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems

2013-08-08 Thread Mark Morgan Lloyd
I'm having one of my periodic attempts to check FPC trunk on various architectures, this was going to be a question about an exception when trying to link libgdb into 2.6.2 but I find the behaviour has changed so I mention that for information only. Also for information only, when I used -j 8

RE: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems

2013-08-08 Thread Pierre Free Pascal
Hi Mark, this is one of the problems with fpmake, sometimes we seems to loose the output of the calls to the assembler or the linker :( Could you try to run make inside ide directory and add -Xd option to OPT? Does this solve your problem? I get the same kind of error on i386-linux system

[fpc-devel] Cross-compile compiler itself

2013-08-08 Thread Joost van der Sluis
Hi all, How can I cross-compile the compiler itself? I tried it by: make clean all CPU_TARGET=arm Then: make all CPU_TARGET=arm PP=ppcrossarm But that one failes, because the first step it does is compiling the rtl for the host platform (x86_64). Which fails when ppcrossarm is used for

Re: [fpc-devel] Cross-compile compiler itself

2013-08-08 Thread Jonas Maebe
On 08 Aug 2013, at 12:51, Joost van der Sluis wrote: How can I cross-compile the compiler itself? I tried it by: make clean all CPU_TARGET=arm Then: make all CPU_TARGET=arm PP=ppcrossarm But that one failes, because the first step it does is compiling the rtl for the host platform

Re: [fpc-devel] Cross-compile compiler itself

2013-08-08 Thread Joost van der Sluis
On 08/08/2013 12:54 PM, Jonas Maebe wrote: On 08 Aug 2013, at 12:51, Joost van der Sluis wrote: How can I cross-compile the compiler itself? I tried it by: make clean all CPU_TARGET=arm Then: make all CPU_TARGET=arm PP=ppcrossarm But that one failes, because the first step it does is

Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems

2013-08-08 Thread Mark Morgan Lloyd
Pierre Free Pascal wrote: -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd Envoyé : jeudi 8 août 2013 11:02 À : fpc-devel@lists.freepascal.org Objet : [fpc-devel] Compiling for libgdb, and

Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems

2013-08-08 Thread Sven Barth
External command /usr/local/bin/ppcsparc -Tlinux -FEbin/sparc-linux -FUunits/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/rtl/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/fv/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/chm/units/sparc-linux/

Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems

2013-08-08 Thread Mark Morgan Lloyd
Mark Morgan Lloyd wrote: Fatal: Compilation aborted An unhandled exception occurred at $001E61C0 : EDivByZero : Division by zero $001E61C0 TCGASSIGNMENTNODE__PASS_GENERATE_CODE, line 785 of ncgld.pas At this point: what's actually running, i.e. what command should I apply gdb to to get a

Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems

2013-08-08 Thread Sven Barth
On 08.08.2013 19:08, Mark Morgan Lloyd wrote: Mark Morgan Lloyd wrote: Fatal: Compilation aborted An unhandled exception occurred at $001E61C0 : EDivByZero : Division by zero $001E61C0 TCGASSIGNMENTNODE__PASS_GENERATE_CODE, line 785 of ncgld.pas At this point: what's actually running,

Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems

2013-08-08 Thread Mark Morgan Lloyd
Sven Barth wrote: If I revert to 2.6.2 and run ppcsparc under gdb, I get this as a backtrace: Program received signal SIGFPE, Arithmetic exception. 0x001e61c0 in TCGASSIGNMENTNODE__PASS_GENERATE_CODE (this=0xf5d6abe0) at ncgld.pas:785 785 if

RE: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems

2013-08-08 Thread Pierre Free Pascal
Hi, I am sorry, but Ihave no access to a sprac machine anymore. But I remember that we already had a problem like this coming from the fact that we declare somewhere an empty record and this lead to troubles... TVectorREgss from fpregs unit might still be empty for sparc. This was fixed in