Mark Morgan Lloyd wrote:
Sven Barth wrote:
It will be interesting to see what minimal code will trigger the
problem. Maybe it will point to a more serious problem inside the
compiler.
I've now got a standalone test_fpregs.pas which fails to compile in
the expected way, i.e. a compile-time
Am 13.09.2013 12:20 schrieb Mark Morgan Lloyd
markmll.fpc-de...@telemetry.co.uk:
Mark Morgan Lloyd wrote:
Sven Barth wrote:
It will be interesting to see what minimal code will trigger the
problem. Maybe it will point to a more serious problem inside the compiler.
I've now got a
Apologies for my lousy threading, but the gateway here drops some messages.
Sven Barth wrote:
The divide-by-zero is caused when the compiler attempts to compile an
assignment of a tVectorregs inside TVectorView.Draw, i.e. as minimal code:
procedure TVectorView.Draw;
var
rs :
Sven Barth wrote:
It will be interesting to see what minimal code will trigger the
problem. Maybe it will point to a more serious problem inside the
compiler.
I've now got a standalone test_fpregs.pas which fails to compile in
the expected way, i.e. a compile-time error in ncgld.pas. I've
Mark Morgan Lloyd wrote:
Sven Barth wrote:
Would it help if I were to build a cross-compiler here and try building
the IDE both with and without libgdb?
It would help more if you'd be able to reduce the problem from
compile IDE with libgdb to compile this simple unit/program. Thus
could
Am 26.08.2013 11:55, schrieb Mark Morgan Lloyd:
Mark Morgan Lloyd wrote:
Sven Barth wrote:
Would it help if I were to build a cross-compiler here and try
building
the IDE both with and without libgdb?
It would help more if you'd be able to reduce the problem from
compile IDE with libgdb
Sven Barth wrote:
Am 26.08.2013 11:55, schrieb Mark Morgan Lloyd:
Mark Morgan Lloyd wrote:
Sven Barth wrote:
Would it help if I were to build a cross-compiler here and try
building
the IDE both with and without libgdb?
It would help more if you'd be able to reduce the problem from
Am 26.08.2013 14:11, schrieb Mark Morgan Lloyd:
Sven Barth wrote:
Am 26.08.2013 11:55, schrieb Mark Morgan Lloyd:
Mark Morgan Lloyd wrote:
Sven Barth wrote:
Would it help if I were to build a cross-compiler here and try
building
the IDE both with and without libgdb?
It would help more if
On 26 Aug 2013, at 14:34, Sven Barth wrote:
Take your time. A few hours/days more or less won't hurt and at
least we already know a fix for the resulting problem, but I'd also
like to fix the cause :)
It's already fixed in trunk in r19338
Am 26.08.2013 14:38, schrieb Jonas Maebe:
On 26 Aug 2013, at 14:34, Sven Barth wrote:
Take your time. A few hours/days more or less won't hurt and at least
we already know a fix for the resulting problem, but I'd also like to
fix the cause :)
It's already fixed in trunk in r19338
No, the
Sven Barth wrote:
It seems to be a bug in the Sparc code generator nevertheless, because
the IDE compiles (not assembles/links though :P ) using a Sparc cross
compiler...
Hold on: the IDE without libgdb compiles OK natively on SPARC. It's only
adding libgdb which screws things.
This might
On 12.08.2013 16:06, Mark Morgan Lloyd wrote:
Sven Barth wrote:
It seems to be a bug in the Sparc code generator nevertheless, because
the IDE compiles (not assembles/links though :P ) using a Sparc cross
compiler...
Hold on: the IDE without libgdb compiles OK natively on SPARC. It's only
Sven Barth wrote:
Would it help if I were to build a cross-compiler here and try building
the IDE both with and without libgdb?
It would help more if you'd be able to reduce the problem from compile
IDE with libgdb to compile this simple unit/program. Thus could you
please try to reduce the
On 11.08.2013 15:15, Mark Morgan Lloyd wrote:
Sven Barth wrote:
On 09.08.2013 19:05, Mark Morgan Lloyd wrote:
Sven Barth wrote:
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
Pierre Free Pascal wrote:
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
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
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
Pierre Free Pascal wrote:
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
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
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
Sven Barth wrote:
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
On 09.08.2013 19:05, Mark Morgan Lloyd wrote:
Sven Barth wrote:
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
Sven Barth wrote:
On 09.08.2013 19:05, Mark Morgan Lloyd wrote:
Sven Barth wrote:
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,
Sven Barth wrote:
if len = 0 then
len := sizeof(aint);
So you changed the len = 0 to len = 0? Then this is very strange,
because that almost surely shouldn't happen.
No, I /added/ those two lines to make sure that len was never zero. I'm
not saying that it's a valid hack, but after
On 09.08.2013 21:03, Mark Morgan Lloyd wrote:
Sven Barth wrote:
if len = 0 then
len := sizeof(aint);
So you changed the len = 0 to len = 0? Then this is very strange,
because that almost surely shouldn't happen.
No, I /added/ those two lines to make sure that len was never zero. I'm
On 09.08.2013 21:20, Sven Barth wrote:
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
Sven Barth wrote:
Ok, so it is indeed a record that calculates the wrong size. Could you
please add the following code after the assignment of len and tell me
the output, so that we'll know which record exactly is the one that fails?
=== code begin ===
if len=0 then
begin
if
On 09.08.2013 23:19, Mark Morgan Lloyd wrote:
Sven Barth wrote:
Ok, so it is indeed a record that calculates the wrong size. Could you
please add the following code after the assignment of len and tell
me the output, so that we'll know which record exactly is the one that
fails?
=== code
Sven Barth wrote:
On 09.08.2013 21:20, Sven Barth wrote:
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,
Hi Mark,
this is one of the problems with fpmake, sometimes we seems to loose
the output of the calls to the assembler or the linker :(
Could you try to run make inside ide directory
and add -Xd option to OPT?
Does this solve your problem?
I get the same kind of error on i386-linux system
Pierre Free Pascal wrote:
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Mark Morgan Lloyd
Envoyé : jeudi 8 août 2013 11:02
À : fpc-devel@lists.freepascal.org
Objet : [fpc-devel] Compiling for libgdb, and
External command /usr/local/bin/ppcsparc -Tlinux -FEbin/sparc-linux
-FUunits/sparc-linux/
-Fu/usr/local/src/fpc/fpc-trunk/rtl/units/sparc-linux/
-Fu/usr/local/src/fpc/fpc-trunk/packages/fv/units/sparc-linux/
-Fu/usr/local/src/fpc/fpc-trunk/packages/chm/units/sparc-linux/
Mark Morgan Lloyd wrote:
Fatal: Compilation aborted
An unhandled exception occurred at $001E61C0 :
EDivByZero : Division by zero
$001E61C0 TCGASSIGNMENTNODE__PASS_GENERATE_CODE, line 785 of ncgld.pas
At this point: what's actually running, i.e. what command should I apply
gdb to to get a
On 08.08.2013 19:08, Mark Morgan Lloyd wrote:
Mark Morgan Lloyd wrote:
Fatal: Compilation aborted
An unhandled exception occurred at $001E61C0 :
EDivByZero : Division by zero
$001E61C0 TCGASSIGNMENTNODE__PASS_GENERATE_CODE, line 785 of
ncgld.pas
At this point: what's actually running,
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
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
36 matches
Mail list logo
