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

[Sven Barth]

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