Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Mark Morgan Lloyd wrote:
Sven Barth wrote:
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.
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:
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.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Am 13.09.2013 12:20 schrieb Mark Morgan Lloyd
markmll.fpc-de...@telemetry.co.uk:
Mark Morgan Lloyd wrote:
Sven Barth wrote:
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.
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:
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.
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Apologies for my lousy threading, but the gateway here drops some messages.
Sven Barth wrote:
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.
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?
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 :-)
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Sven Barth wrote: 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. 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. 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Mark Morgan Lloyd wrote: Sven Barth wrote: 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? 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Am 26.08.2013 11:55, schrieb Mark Morgan Lloyd: Mark Morgan Lloyd wrote: Sven Barth wrote: 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? I'll be back. This isn't quite what you've asked, but I can duplicate it with a minimal program: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Sven Barth wrote: Am 26.08.2013 11:55, schrieb Mark Morgan Lloyd: Mark Morgan Lloyd wrote: Sven Barth wrote: 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? I'll be back. This isn't quite what you've asked, but I can duplicate it with a minimal program: 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. 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Am 26.08.2013 14:11, schrieb Mark Morgan Lloyd: Sven Barth wrote: Am 26.08.2013 11:55, schrieb Mark Morgan Lloyd: Mark Morgan Lloyd wrote: Sven Barth wrote: 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? I'll be back. This isn't quite what you've asked, but I can duplicate it with a minimal program: 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
On 26 Aug 2013, at 14:34, 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___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Am 26.08.2013 14:38, schrieb Jonas Maebe: On 26 Aug 2013, at 14:34, 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 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Sven Barth wrote: 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... 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. 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? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
On 12.08.2013 16:06, Mark Morgan Lloyd wrote: Sven Barth wrote: 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... 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. 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? 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Sven Barth wrote: 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? I'll be back. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
On 11.08.2013 15:15, Mark Morgan Lloyd wrote: Sven Barth wrote: On 09.08.2013 19:05, Mark Morgan Lloyd wrote: Sven Barth wrote: 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). 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... 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... 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Pierre Free Pascal wrote: 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 =dater1=19338r2=19337pathrev=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. 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? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Am 08.08.2013 22:22, schrieb 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 (right.location.reference.offset mod alignmentrequirement0) or (gdb) bt #0 0x001e61c0 in TCGASSIGNMENTNODE__PASS_GENERATE_CODE (this=0xf5d6abe0) at ncgld.pas:785 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. 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? 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Sven Barth wrote: Am 08.08.2013 22:22, schrieb 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 (right.location.reference.offset mod alignmentrequirement0) or (gdb) bt #0 0x001e61c0 in TCGASSIGNMENTNODE__PASS_GENERATE_CODE (this=0xf5d6abe0) at ncgld.pas:785 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. 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? 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) Generally working on it. I'll be back. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Pierre Free Pascal wrote: 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 =dater1=19338r2=19337pathrev=19338 in May 2011... But I was hoping it was fixed in 2.6.2 ... 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Mark Morgan Lloyd wrote:
Sven Barth wrote:
Am 08.08.2013 22:22, schrieb 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
(right.location.reference.offset
mod alignmentrequirement0) or
(gdb) bt
#0 0x001e61c0 in TCGASSIGNMENTNODE__PASS_GENERATE_CODE
(this=0xf5d6abe0) at ncgld.pas:785
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.
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?
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)
Generally working on it. I'll be back.
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.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
On 09.08.2013 18:04, Sven Barth wrote:
On 09.08.2013 14:55, Mark Morgan Lloyd wrote:
Mark Morgan Lloyd wrote:
Sven Barth wrote:
Am 08.08.2013 22:22, schrieb 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
(right.location.reference.offset
mod alignmentrequirement0) or
(gdb) bt
#0 0x001e61c0 in TCGASSIGNMENTNODE__PASS_GENERATE_CODE
(this=0xf5d6abe0) at ncgld.pas:785
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.
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?
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)
Generally working on it. I'll be back.
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?
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).
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Sven Barth wrote: 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). 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... 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
On 09.08.2013 19:05, Mark Morgan Lloyd wrote: Sven Barth wrote: 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). 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... 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Sven Barth wrote: On 09.08.2013 19:05, Mark Morgan Lloyd wrote: Sven Barth wrote: 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). 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... 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... 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Sven Barth wrote:
if len = 0 then
len := sizeof(aint);
So you changed the len = 0 to len = 0? Then this is very strange,
because that almost surely shouldn't happen.
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.
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).
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.
/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.
This isn't related to FPC itself however. Here libgdb has some
unresolved symbols.
[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.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
On 09.08.2013 21:03, Mark Morgan Lloyd wrote:
Sven Barth wrote:
if len = 0 then
len := sizeof(aint);
So you changed the len = 0 to len = 0? Then this is very strange,
because that almost surely shouldn't happen.
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.
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.
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).
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.
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
On 09.08.2013 21:20, Sven Barth wrote:
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).
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.
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.
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Sven Barth wrote:
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.
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.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
p.s. I now seem to have a Mac Classic II with a 68030. Wonder if it's
any use for anything?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
On 09.08.2013 23:19, Mark Morgan Lloyd wrote:
Sven Barth wrote:
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.
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
Sven Barth wrote:
On 09.08.2013 21:20, Sven Barth wrote:
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).
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.
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.
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 ===
== _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.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
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 -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 using make -j on larger SPARC systems 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
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
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 using make -j on larger SPARC systems 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
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
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? I think the command at the top is running, because tcgassignmentnode is a class in the compiler. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
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 decent backtrace? 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
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, i.e. what command should I apply gdb to to get a decent backtrace? 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
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 (right.location.reference.offset mod alignmentrequirement0) or (gdb) bt #0 0x001e61c0 in TCGASSIGNMENTNODE__PASS_GENERATE_CODE (this=0xf5d6abe0) at ncgld.pas:785 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. 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 :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems
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 =dater1=19338r2=19337pathrev=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. -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 22:22 À : fpc-devel@lists.freepascal.org Objet : Re: [fpc-devel] Compiling for libgdb, and using make -j on larger SPARC systems 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 (right.location.reference.offset mod alignmentrequirement0) or (gdb) bt #0 0x001e61c0 in TCGASSIGNMENTNODE__PASS_GENERATE_CODE (this=0xf5d6abe0) at ncgld.pas:785 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. 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 :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
