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 alignmentrequirement<>0) 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 - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
