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 for 2.6.2 there was a message about left-over directories, I similarly don't get that with trunk (or it's intermittent) so let's leave it.

So the current situation is this: when building FPC trunk on Debian Linux on SPARC, everything is fine if I use NOGDB=1. However, if I try to use libgdb (which has in the past but not particularly recently worked OK on this system) I get this

make GDB_V603=1 OPT='-O- -gl' all
..
./fpmake compile --localunitdir=.. --globalunitdir=../packages --os=linux --cpu=sparc -o -Ur -o -Xs -o -O2 -o -n -o -Fu/usr/local/src/fpc/fpc-trunk/rtl/units/sparc-linux -o -Fu/usr/local/src/fpc/fpc-trunk/packages/paszlib/units/sparc-linux -o -Fu/usr/local/src/fpc/fpc-trunk/packages/fcl-process/units/sparc-linux -o -Fu/usr/local/src/fpc/fpc-trunk/packages/hash/units/sparc-linux -o -Fu/usr/local/src/fpc/fpc-trunk/packages/libtar/units/sparc-linux -o -Fu/usr/local/src/fpc/fpc-trunk/packages/fpmkunit/units/sparc-linux -o -O- -o -gl -o -vt -o -dRELEASE
--compiler=/usr/local/src/fpc/fpc-trunk/compiler/ppcsparc -bu Start compiling package ide for target sparc-linux. LibGDB was found, build IDE with debugger support
Warning: Unable to determine the libgcc path.
Compiling compiler/compunit.pas
Compiling /usr/local/src/fpc/fpc-trunk/compiler/ppheap.pas Compiling /usr/local/src/fpc/fpc-trunk/compiler/cutils.pas ..
Compiling /usr/local/src/fpc/fpc-trunk/compiler/dbgdwarf.pas Compiling /usr/local/src/fpc/fpc-trunk/compiler/browcol.pas Warning: Unable to determine the libgcc path.
Compiling fp.pas
Compiling fpcatch.pas
Compiling fpcompil.pas
..
Compiling fpcodtmp.pas
Compiling fptemplt.pas
Linking bin/sparc-linux/fp
The installer encountered the following error:
External command "/usr/local/src/fpc/fpc-trunk/compiler/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/ -Fu/usr/local/src/fpc/fpc-trunk/packages/fcl-xml/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/fcl-base/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/fcl-res/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/iconvenc/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/regexpr/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/gdbint/units/sparc-linux/ -Fl -Ur -Xs -O2 -n -Fu/usr/local/src/fpc/fpc-trunk/rtl/units/sparc-linux -Fu/usr/local/src/fpc/fpc-trunk/packages/paszlib/units/sparc-linux -Fu/usr/local/src/fpc/fpc-trunk/packages/fcl-process/units/sparc-linux -Fu/usr/local/src/fpc/fpc-trunk/packages/hash/units/sparc-linux -Fu/usr/local/src/fpc/fpc-trunk/packages/libtar/units/sparc-linux -Fu/usr/local/src/fpc/fpc-trunk/packages/fpmkunit/units/sparc-linux -O- -gl -vt -dRELEASE -Ur -dNOCATCH -dBrowserCol -dGDB -dsparc -Fu../compiler -Fu../compiler/sparc -Fu../compiler/targets -Fu../compiler/systems -Fi../compiler/sparc -Fi../compiler -Sg -Fl../libgdb/linux/sparc/ -viq fp.pas" failed with exit code 1. Console output:
Target OS: Linux for SPARC
Compiling fp.pas
fp.pas(27,2) (2004) Start reading includefile globdir.inc Compiling fpcatch.pas
..
Writing Resource String Table file: fpcatch.rst
Assembling fpcatch
Writing Resource String Table file: fp.rst
Assembling fp
Linking bin/sparc-linux/fp
fp.pas(554) Error: Error while linking
fp.pas(554) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted

make[2]: Leaving directory `/usr/local/src/fpc/fpc-trunk/ide' make[1]: Leaving directory `/usr/local/src/fpc/fpc-trunk'

The obvious first question is: are those references to libgcc significant, and what file is being looked for? The normal binary installer hasn't been run on this system since FPC's been built on it from source since something like 2.0.

Any and all suggestions appreciated.

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 because the compiler chooses a system library for libreadline.a instead of the one that is in GDBLIBDIR...

Pierre Muller

SPARC

colleagues]

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

That looks like it fixes the problem I described earlier, and takes me back to the one I saw on 2.6.2 (plus possibly some slightly older ones).

../fpc-trunk/ide$ make GDB_V603=1 OPT='-O- -gl -Xd' all ./fpmake compile --localunitdir=.. --globalunitdir=../packages --os=linux --cpu=sparc -o -Fu../rtl/units/sparc-linux -o -Fu../packages/paszlib/units/sparc-linux -o
-Fu../packages/fcl-process/units/sparc-linux -o
-Fu../packages/hash/units/sparc-linux -o
-Fu../packages/libtar/units/sparc-linux -o
-Fu../packages/fpmkunit/units/sparc-linux -o -O- -o -gl -o -Xd --compiler=/usr/local/bin/ppcsparc -bu
Start compiling package ide for target sparc-linux. LibGDB was found, build IDE with debugger support
Warning: Unable to determine the libgcc path.
Compiling fp.pas
..
Compiling fpcalc.pas
The installer encountered the following error:
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/ -Fu/usr/local/src/fpc/fpc-trunk/packages/fcl-xml/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/fcl-base/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/fcl-res/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/iconvenc/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/regexpr/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/gdbint/units/sparc-linux/ -Fl -Fu../rtl/units/sparc-linux -Fu../packages/paszlib/units/sparc-linux -Fu../packages/fcl-process/units/sparc-linux
-Fu../packages/hash/units/sparc-linux
-Fu../packages/libtar/units/sparc-linux
-Fu../packages/fpmkunit/units/sparc-linux -O- -gl -Xd -Ur -dNOCATCH -dBrowserCol -dGDB -dsparc -Fu../compiler -Fu../compiler/sparc -Fu../compiler/targets -Fu../compiler/systems -Fi../compiler/sparc -Fi../compiler -Sg -Fl../libgdb/linux/sparc/ -viq fp.pas" failed with exit code 217. Console output:
Free Pascal Compiler version 2.6.2 [2013/08/05] for sparc Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Linux for SPARC
Compiling fp.pas
..
Compiling /usr/local/src/fpc/fpc-trunk/compiler/sparc/itcpugas.pas Assembling itcpugas
Compiling fpswitch.pas
Compiling fpvars.pas
Compiling fpdebug.pas
Compiling fpregs.pas
Compiling fpvars.pas
Compiling fputils.pas
Compiling fpvars.pas
Compiling fpcalc.pas
fpcalc.pas(236,3) Note: Local variable "fpucw" not used Writing Resource String Table file: fpcalc.rst
Assembling fpcalc
Assembling fpvars
fputils.pas(239,5) Note: Local variable "C" is assigned but never used Assembling fputils
fpregs.pas(281,8) Note: Local variable "code" is assigned but never used fpregs.pas(822,12) Note: Local variable "value" not used fpregs.pas(825,8) Note: Local variable "res" is assigned but never used fpregs.pas(827,8) Note: Local variable "err" is assigned but never used fpregs.pas(997,8) Note: Local variable "top" not used fpregs.pas(1002,7) Note: Local variable "TypeStr" not used fpregs.pas(1251,8) Note: Local variable "reg" is assigned but never used fpregs.pas(1251,12) Note: Local variable "value" not used fpregs.pas(1254,8) Note: Local variable "res" is assigned but never used fpregs.pas(1256,8) Note: Local variable "err" is assigned but never used fpregs.pas(1381,8) Note: Local variable "top" not used fpregs.pas(1382,8) Note: Local variable "color" is assigned but never used fpregs.pas(1384,8) Note: Local variable "i" not used fpregs.pas(1386,7) Note: Local variable "TypeStr" not used 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 decent backtrace?

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/ -Fu/usr/local/src/fpc/fpc-trunk/packages/fcl-xml/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/fcl-base/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/fcl-res/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/iconvenc/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/regexpr/units/sparc-linux/ -Fu/usr/local/src/fpc/fpc-trunk/packages/gdbint/units/sparc-linux/ -Fl -Fu../rtl/units/sparc-linux -Fu../packages/paszlib/units/sparc-linux -Fu../packages/fcl-process/units/sparc-linux
-Fu../packages/hash/units/sparc-linux
-Fu../packages/libtar/units/sparc-linux
-Fu../packages/fpmkunit/units/sparc-linux -O- -gl -Xd -Ur -dNOCATCH -dBrowserCol -dGDB -dsparc -Fu../compiler -Fu../compiler/sparc -Fu../compiler/targets -Fu../compiler/systems -Fi../compiler/sparc -Fi../compiler -Sg -Fl../libgdb/linux/sparc/ -viq fp.pas" failed with exit code 217. Console output:

gdb to to get a decent backtrace?

I think the command at the top is running, because tcgassignmentnode is a class in the compiler.

Regards,
Sven

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 (right.location.reference.offset mod alignmentrequirement0) or
(gdb) bt
#0 0x001e61c0 in TCGASSIGNMENTNODE__PASS_GENERATE_CODE (this=0xf5d6abe0) at ncgld.pas:785
#1 0x0014d9c4 in SECONDPASS (P=0xf5d6abe0) at pass_2.pas:195 #2 0x001daf94 in TCGBLOCKNODE__PASS_GENERATE_CODE (this=0xf5b1d320) at ncgbas.pas:366
#3 0x0014d9c4 in SECONDPASS (P=0xf5b1d320) at pass_2.pas:195 #4 0x001dc2b4 in TCGIFNODE__PASS_GENERATE_CODE (this=0xf5d737f0) at ncgflw.pas:275
#5 0x0014d9c4 in SECONDPASS (P=0xf5d737f0) at pass_2.pas:195 #6 0x001daf94 in TCGBLOCKNODE__PASS_GENERATE_CODE (this=0xf5b1c0a0) at ncgbas.pas:366
#7 0x0014d9c4 in SECONDPASS (P=0xf5b1c0a0) at pass_2.pas:195 #8 0x001daf94 in TCGBLOCKNODE__PASS_GENERATE_CODE (this=0xf5b1eaa0) at ncgbas.pas:366
#9 0x0014d9c4 in SECONDPASS (P=0xf5b1eaa0) at pass_2.pas:195 #10 0x0014db14 in DO_SECONDPASS (P=0xf5b1eaa0) at pass_2.pas:227 #11 0x0016a368 in TCGPROCINFO__GENERATE_CODE (this=0xf6357cd0) at psub.pas:1048
#12 0x0016c170 in DO_GENERATE_CODE (PI=0xf6357cd0, parentfp=0xffed8790) at psub.pas:1557
..

Also (if I'm doing this right)

(gdb) print alignmentrequirement
$1 = 0

Any thoughts appreciated.

This is strange. If you take a look at the code there are at least two checks that should ensure that alignmentrequirement is not 0... Could you maybe step into Min and Max to check whether they produce sane results? (you'll likely need to recompile the RTL with debug information; I'd suggest you to use 2.7.1 for debugging) If you can't recompile the RTL with debug information you could try to break up the assignment statement for "alignmentrequirement" into single steps and print the values so that we can have a complete picture.

Regards,
Sven

I'll take a look at that in the morning, probably by printing temporary values etc. since I'm not very confident trying to single-step somebody else's complex code. Allowing that this is apparently a compiler rather than an fp/libgdb issue, is there test code for this case anywhere?

Misbehaving min()/max() rings a horrible bell, but I can't remember the context.

I'm glad to say that at least removing the -O- has no beneficial effect :-)

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
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/ncgld.pas?sortby =date&r1=19338&r2=19337&pathrev=19338
in May 2011...

But I was hoping it was fixed in 2.6.2 ...

Could you try to recompile trunk compiler and check that that one does not crash.

Pierre

PS :Test bug is tiny:
Try to compile the following, with either 2.6.2 or current trunk binary,

type
  emptyrec = record
  end;
var
  x, y : emptyrec;
begin
  x:=y;
end.

at

:-)

colleagues]

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

Trunk /does/ crash- that's where we started. I only reverted to 2.6.2 since it's slightly easier to put a debugger on it to get a backtrace.

>> ../fpc-trunk/ide$ make GDB_V603=1 OPT='-O- -gl -Xd' all >> ./fpmake compile --localunitdir=.. -...

..

>> 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 decent backtrace?

We don't have an explicit test case for Min/Max.

Misbehaving min()/max() rings a horrible bell, but I can't remember the context.

Maybe it isn't Min/Max itself, but the direct passing of the result of the inner call to the outer call that's faulty on Sparc...

Maybe you could compile a test program with a similar situation as the alignmentrequirement situation and check the parameter passing (if you can read Sparc assembly language)

Regards,
Sven

Generally working on it. I'll be back.

In both 2.6.2 and trunk registers are defined for SPARC, and even if they weren't it looks to my inexpert eye that there's a default of 128 dummies so I'd not expect the record to be empty.

I think min() and parameter passing are OK. The problem appears to be that the length of [whatever] is zero, and this is propagating via alignmentrequirement to the mod operation. From debugging output, this /only/ appears to happen when building fp with libgdb, 2.6.2 will compile e.g. Lazarus 1.0 and produce something which looks generally OK.

If as the worst-possible kind of hack I do this

else

                           begin

{ TODO: HACK: unaligned test, maybe remove all unaligned locations (array of char) from the compiler}
{ Use unaligned copy when the offset is not
aligned }

                             len:=left.resultdef.size;

if len <= 0 then

   len := sizeof(aint);
                             { data smaller than an aint has less

alignment requirements }

it fixes the compilation problem.

If nobody has any head-slappingly obvious quick fixes, is there any comparatively-simple way that I can at least report on what it's trying to compile that's causing the fault?

I'm left with issues like

..
Using assembler: /usr/bin/as
/usr/local/src/fpc/fpcbuild-2.6.2/fpcsrc/libgdb/linux/sparc/libgdb.a(ada-lang.o): In function `scaling_factor':
/usr/local/src/fpc/libgdb/gdb-6.7.1/gdb/ada-lang.c:8651: undefined reference to `_Q_utoq'
/usr/local/src/fpc/libgdb/gdb-6.7.1/gdb/ada-lang.c:8651: undefined reference to `_Q_utoq'
..

which I've not seen previously. Unless anybody has any suggestions (and time permitting) I'll take a look at older versions and try to work out when things started going wrong.

So you changed the "len = 0" to "len <= 0"? Then this is very strange, because that almost surely shouldn't happen. Could you please print somehow (either debugging or Writeln) the value of left.resultdef.typ (yes, without "e" at the end!) when len <= 0? Then we could at least check which def produces problematic results here (is suspect records, but just to be sure).

This isn't related to FPC itself however. Here libgdb has some unresolved symbols.

Regards,
Sven

On the other hand the only def that I've found so far that does indeed return -1 in certain cases is the array... hmm...

Regards,
Sven

Noting Pierre's comments from earlier, TIntRegs contains arrays for SPARC and PPC (and also for the catch-all case) but not for i386 or 68k.

It seems to be a bug in the Sparc code generator nevertheless, because the IDE compiles (not assembles/links though :P ) using a Sparc cross compiler...

Regards,
Sven

No, I /added/ those two lines to make sure that len was never zero. I'm not saying that it's a valid hack, but after seeing that len == 0 only in that one place (i.e. never when compiling the remainder of the compiler etc.) I thought it a worthwhile experiment.

That of course was one of the things I was asking :-) With code as below (reformatted to avoid problems with wrap)

else

   begin

{ TODO: HACK: unaligned test, maybe remove all unaligned locations (array of char) from the compiler}
{ Use unaligned copy when the offset is not aligned }

     len:=left.resultdef.size;

if len = 0 then begin
   WriteLn('=====> len: ', len);
   WriteLn('=====> typ: ', left.resultdef.typ)
end;
// if len <= 0 then
//   len := sizeof(aint);

{ data smaller than an aint has less alignment requirements }

     alignmentrequirement:=min(len,sizeof(aint));
     if (right.location.reference.offset mod alignmentrequirement0) or

..

I get

=====> len: 0
=====> typ: recorddef

But it does appear to build properly on x86, without any zero-length types.

[Nod] I'm investigating, but I /think/ I've had this version (6.7) working in the past. Fixing up the gcc-lib path in fpc.cfg doesn't help, in fact -vt output suggests that fpc automagically finds the right file irrespective.

But so far it appears to affect only this one bit of the compiler: nothing else. If I were paranoid I'd be invoking Ken Thompson's "Trusting Trust" paper http://cm.bell-labs.com/who/ken/trust.html

I'll put a bit more time on IDE+libgdb on various platforms, and might look at slightly older versions on SPARC. In the past I've had it running reasonably successfully on everything except ARM... which is an unfortunate exception since the sort of alignment problems which affect SPARC also affect at least some ARM variants.

Ah, 2.7.1 already contains (since April 2012) the check for "len = 0", but this was never merged to 2.6.x, because it was part of the JVM port.

Ok, so it is indeed a record that calculates the wrong size. Could you please add the following code after the assignment of "len" and tell me the output, so that we'll know which record exactly is the one that fails?

=== code begin ===

if len=0 then
   begin
     if left.resultdef.typ=recorddef then
       writeln('=======> objname: ',trecorddef(left.resultdef).objname^);
     len:=sizeof(pint);
   end;

=== code end ===

I'll meanwhile investigate how a record calculates its size.

Regards,
Sven

You might additionally add the following code to the end of the these methods of "tabstractsymtable" in unit "symtable":
- setdatasize
- addfield
- addalignmentpadding
and also to "trecordsymtable.insertunionst" (also unit "symtable"):

=== code begin ===

if _datasize=0 then
   begin
     write('======> _datasize = 0 @', {$I %LINE%}, ': ');
     if assigned(defowner) and (defowner.typ=recorddef) then
       writeln(trecorddef(defowner).objname^)
     else
       writeln('<unknown>');
   end;

=== code end ===

Regards,
Sven

Code reads (indent adjusted):

len:=left.resultdef.size;
if len = 0 then begin
   WriteLn('=====> len: ', len);
   WriteLn('=====> typ: ', left.resultdef.typ)
end;
if len=0 then
   begin
     if left.resultdef.typ=recorddef then
       writeln('=======> objname: ',trecorddef(left.resultdef).objname^);
     len:=sizeof(pint);
   end;
// if len <= 0 then
//   len := sizeof(aint);
{ data smaller than an aint has less alignment requirements }
alignmentrequirement:=min(len,sizeof(aint));
if (right.location.reference.offset mod alignmentrequirement0) or
..

Output is:

..
Using assembler: /usr/bin/as
=====> len: 0
=====> typ: recorddef
=======> objname: TVECTORREGS
=====> len: 0
=====> typ: recorddef
=======> objname: TVECTORREGS
=====> len: 0
=====> typ: recorddef
=======> objname: TVECTORREGS
=====> len: 0
=====> typ: recorddef
=======> objname: TVECTORREGS
/usr/local/src/fpc/fpcbuild-2.6.2/fpcsrc/libgdb/linux/sparc/libgdb.a(ada-lang.o): In function `scaling_factor':
..

I'm just about to add your next tests and redo. Recompilation is slow, and I don't think that firing up a bigger machine and using make -j helps that much.

Ok, we now know that TVectorRegs is the culprit so we could try a simpler testcase than the whole IDE. Could you please try whether the following example triggers the exception as well? You can also speed up the compilation by just doing a "make cycle" in the compiler directory if this example works as intended.

=== code begin ===

program test;
const
   MaxRegs = 128;
type
   TVectorRegs = record
     reg : array [0..MaxRegs-1] of string;
   end;
   TVectorView = object
     OldRegs,NewRegs: TVectorRegs;
   end;
procedure DoAssignment(var aView: TVectorView);
begin
   aView.NewRegs := aView.OldRegs;
end;
var
   v: TVectorView;
begin
   DoAssignment(v);
end.

=== code end ===

Regards,
Sven

======> _datasize = 0 @1138:
======> _datasize = 0 @1138:
======> _datasize = 0 @1068: TVECTORREGS
=====> len: 0
=====> typ: recorddef
=======> objname: TVECTORREGS
=====> len: 0
=====> typ: recorddef
=======> objname: TVECTORREGS
=====> len: 0
=====> typ: recorddef
=======> objname: TVECTORREGS
=====> len: 0
=====> typ: recorddef
=======> objname: TVECTORREGS
======> _datasize = 0 @1068:
======> _datasize = 0 @1068:
======> _datasize = 0 @1068:
======> _datasize = 0 @1068:
======> _datasize = 0 @1068:
======> _datasize = 0 @1068:
======> _datasize = 0 @1068:
======> _datasize = 0 @1068:
/usr/local/src/fpc/fpcbuild-2.6.2/fpcsrc/libgdb/linux/sparc/libgdb.a(ada-lang.o): In function `scaling_factor':
/usr/local/src/fpc/libgdb/gdb-6.7.1/gdb/ada-lang.c:8651: undefined reference to `_Q_utoq'

1027 .addfield
1068 .addalignmentpadding
1138 .setdatasize

More later.

Using the same version of compiler that we've been testing, that compiles cleanly and runs without output (i.e. no visible exception etc.).

Does that mean that it /is/ or /isn't/ safe to use make cycle rather than a complete build?

"make cycle" should be safe anyway. As long as we don't find a simpler example you could just do a "make clean all
FPC=/path/to/freshly/cycled/ppcsparc" inside the "ide" directory to speed things up (as we only change some of the compiler's console output, but no unit structure you don't need to recompile the packages each time)

Regards,
Sven

On i386 Linux, 2.6.2 and 2.7.1 with libgdb 6.7.1 are OK.

On PPC (32-bit) Linux, 2.6.2 and 2.7.1 with libgdb 6.7.1 are OK.

The SPARC system I was using for test purposes lives under my desk and runs an older version of Debian (Etch rather than Lenny or later), I was avoiding powering anything else up because of heat issues. The linkage errors appear to be caused by using libgdb 6.7.1 on this combination, rather than the older 6.3.

2.4.2 and 2.4.4 are OK with libgdb 6.3, i.e. compilation and linkage are successful but I've not exercised the and later fail to compile with libgdb 6.3, giving the divide-by-zero error previously discussed.

Hold on: the IDE without libgdb compiles OK natively on SPARC. It's only adding libgdb which screws things.

This might be, but the problem nevertheless suggests a potentially serious compiler bug as the compiler should not raise exceptions (or internal errors) on valid code.

Regards,
Sven

OK, but I'm betting that it would fail if the SPARC cross compiler were asked to build with libgdb... is this something you can or do do?

Would it help if I were to build a cross-compiler here and try building the IDE both with and without libgdb?

It's not the libgdb itself which triggers problems (well, aside the missing dependency), but the inclusion of the fpregs unit which is not added if the IDE is not compiled with libgdb support.

Would it help if I were to build a cross-compiler here and try building the IDE both with and without libgdb?

It would help more if you'd be able to reduce the problem from "compile IDE with libgdb" to "compile this simple unit/program". Thus could you please try to reduce the ide/fpregs.pp unit (which contains the suspicious TVectorRegs record) so far that it can be compiled standalone (no further dependencies), but still triggers the exception?

Regards,
Sven

I'll be back.

This isn't quite what you've asked, but I can duplicate it with a minimal program:

program test_fp_ide;
(* This is a specific test of the fp IDE interface to libgdb, which
fails       *)
(* to compile on SPARC using fpc later than 2.4.x. MarkMLl.
         *)
uses FPRegs;
// var  vr: TVectorRegs;
begin
//  WriteLn(SizeOf(vr));
end.

#0 0x001e61c0 in TCGASSIGNMENTNODE__PASS_GENERATE_CODE (this=0xf58d6a40) at ncgld.pas:785
#1 0x0014d9c4 in SECONDPASS (P=0xf58d6a40) at pass_2.pas:195 ..

which takes us back to the same line

if (right.location.reference.offset mod alignmentrequirement0) or

with the implication that alignmentrequirement is unexpectedly zero.

Above is based on 2.6.2, running on SPARC Debian "Lenny". I'm omitting details of the paths etc. pending confirmation that what I've got is of some use.

-----

I'm having problems reducing fpregs to a simple program, I'll post more details once I've been able to look at it on the machine I've moved onto for test purposes.

Well, at least it isn't *that* bad. You should now be able to just cycle the compiler (cd compiler && make cycle) and then compile the test program to check when things go wrong.

I'm having problems reducing fpregs to a simple program, I'll post more details once I've been able to look at it on the machine I've moved onto for test purposes.

It will be interesting to see what minimal code will trigger the problem. Maybe it will point to a more serious problem inside the compiler.

Regards,
Sven

I've now got a standalone test_fpregs.pas which fails to compile in the expected way, i.e. a compile-time error in ncgld.pas. I've got other jobs to do for a few hours but will see what I can rip out without losing the erroneous behaviour.

Take your time. A few hours/days more or less won't hurt and at least we already know a fix for the resulting problem, but I'd also like to fix the cause :)

Regards,
Sven

Sven Barth wrote

Take your time. A few hours/days more or less won't hurt and at least we already know a fix for the resulting problem, but I'd also like to fix the cause :)

It's already fixed in trunk in r19338

Jonas

No, the fix is the one added by you (the one with "if len = 0 then ..."), but the record in question does not fit the criteria mentioned and thus I'd like to know why as this could point to a more serious problem on Sparc that we aren't aware of yet.

Regards,
Sven

It's not triggered by fpregs.pas. It's triggered by importing one or more of FPViews FPVars FPDebug which suggests to me that it's in some common file that those three (but not FPConst) themselves import.

I wish I'd got one of my elderly ARM systems available, since it would be interesting to know if it happens on another architecture that's picky about alignment.

Work continues intermittently.

Wrong. The problem with that approach is that those three files themselves import an unmodified fpregs.pas, so investigation has to be done "in vivo".

The divide-by-zero is caused when the compiler attempts to compile an assignment of a tVectorregs inside TVectorView.Draw, i.e. as minimal code:

   procedure TVectorView.Draw;
     var
        rs : tVectorregs; { stuff commented out here }
     begin
       rs := rs; { more stuff commented out here }
     end;

All of the tVectorregs assignments in that method cause the problem, not just the artificial one I show above.

I ended up doing a full build for tests, since I think I found a situation where once a compiler was OK it stayed OK and I wanted to be absolutely certain of my facts rather than crying wolf over a problem that might be difficult to reproduce.

Am 13.09.2013 12:20 schrieb "Mark Morgan Lloyd" <

problem. Maybe it will point to a more serious problem inside the compiler.

>>> >>> >>> I've now got a standalone test_fpregs.pas which fails to compile in

the expected way, i.e. a compile-time error in ncgld.pas. I've got other jobs to do for a few hours but will see what I can rip out without losing the erroneous behaviour.

>>> >> >> Take your time. A few hours/days more or less won't hurt and at least

we already know a fix for the resulting problem, but I'd also like to fix the cause :)

> > > It's not triggered by fpregs.pas. It's triggered by importing one or

more of FPViews FPVars FPDebug which suggests to me that it's in some common file that those three (but not FPConst) themselves import.

Wrong. The problem with that approach is that those three files

themselves import an unmodified fpregs.pas, so investigation has to be done "in vivo".

The divide-by-zero is caused when the compiler attempts to compile an

assignment of a tVectorregs inside TVectorView.Draw, i.e. as minimal code:

just the artificial one I show above.

I ended up doing a full build for tests, since I think I found a

situation where once a compiler was OK it stayed OK and I wanted to be absolutely certain of my facts rather than crying wolf over a problem that might be difficult to reproduce.

So if you put the declaration of TVectorRegs in a program and add a function that does the above assignment, you can reproduce it as well?

Regards,
Sven

Apologies for my lousy threading, but the gateway here drops some messages.

So far, no :-( But I'll keep trying.

I can confirm that a stripped-down function as above still triggers the problem, i.e. it's not something odd in the commented-out bits.

I can also say, with more confidence than earlier, that the full build is necessary since otherwise once the IDE has built successfully it keeps on building even if fpregs.pas is modified to induce the fault and a compiler make cycle is done (but the machine running the build is in somebody else's office, so I'm not the one with the extra heat :-)