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

[Sven Barth]

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)

Regards,
Sven