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