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

[Pierre Free Pascal]

  Hi,

I am sorry, but Ihave no access to a sprac machine anymore.
But I remember that we already had a problem like this coming
from the fact that we declare somewhere an empty record
and this lead to troubles...
  TVectorREgss from fpregs unit might still be empty for sparc.

This was fixed in
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/ncgld.pas?sortby
=date&r1=19338&r2=19337&pathrev=19338
in May 2011...

  But I was hoping it was fixed in 2.6.2 ...

  Could you try to recompile trunk compiler and check that that one
does not crash.

Pierre

PS :Test bug is tiny:
Try to compile the following, with either 2.6.2 or current trunk binary,

type
  emptyrec = record
  end;

var
  x, y : emptyrec;

begin
  x:=y;
end.

> -----Message d'origine-----
> De : fpc-devel-bounces at lists.freepascal.org [mailto:fpc-devel-
> bounces at lists.freepascal.org] De la part de Mark Morgan Lloyd
> Envoyé : jeudi 8 août 2013 22:22
> À : fpc-devel at lists.freepascal.org
> Objet : Re: [fpc-devel] Compiling for libgdb, and using make -j on larger
> SPARC systems
> 
> 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  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel