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

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

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]