Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2013-03

Should the compiler work, if compiled with -Cr?

17 messages · 8 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Martin

revision 23848

As reported recently:

make clean
make.exe all LINKSMART=1 CREATESMART=1 DEBUG=1 OPTIMIZE=0 OPT="-gl -O2"

Fatal: Compilation aborted
An unhandled exception occurred at $004A7A0E:
ERangeError: Range check error
$004A7A0E line 2638 of scanner.pas
$004AA76D line 3944 of scanner.pas
$005094C8 line 133 of pbase.pas
$00525BCE line 3095 of pexpr.pas
$00527050 line 3422 of pexpr.pas
$0052707D line 3427 of pexpr.pas
$0052707D line 3427 of pexpr.pas
$0052707D line 3427 of pexpr.pas
$00527AC8 line 3694 of pexpr.pas
$0050C28C line 1189 of pstatmnt.pas
$0050C666 line 1316 of pstatmnt.pas
$00502503 line 335 of psub.pas
$00505223 line 1699 of psub.pas
$00505696 line 1847 of psub.pas
$00505B22 line 2002 of psub.pas
$00505F2D line 2126 of psub.pas
$005023D1 line 279 of psub.pas

Reply by email

Paul Ishenin
to Martin
Martin wrote 7 lines
revision 23848 As reported recently: make clean make.exe all LINKSMART=1 CREATESMART=1 DEBUG=1 OPTIMIZE=0 OPT="-gl -O2"

No, it does not work. Testsuite has many failures too when the compiler is built with -Cr.

Why this is a problem for you?

Best regards,
Paul Ishenin

Reply by email

Martin
to Paul Ishenin
Paul Ishenin wrote 13 lines
16.03.13, 1:54, Martin wrote: > revision 23848 > > As reported recently: > > make clean > make.exe all LINKSMART=1 CREATESMART=1 DEBUG=1 OPTIMIZE=0 OPT="-gl > -O2" No, it does not work. Testsuite has many failures too when the compiler is built with -Cr. Why this is a problem for you?

It is not a problem.
But it did work (or at least compile itself) for a long time now. (Or at least until recently every of the revisions that I got did work).

On my last email, you simple said, it was caused by the -Cr. But it wasn't clear to me if that was acknowledging the crash as a bug, or if that meant it crashes by design.

So I brought it up again.

Reply by email

Martin
to Martin
Martin wrote 17 lines
On 16/03/2013 01:35, Paul Ishenin wrote: > > No, it does not work. Testsuite has many failures too when the > compiler is built with -Cr. > > Why this is a problem for you? It is not a problem. But it did work (or at least compile itself) for a long time now. (Or at least until recently every of the revisions that I got did work). On my last email, you simple said, it was caused by the -Cr. But it wasn't clear to me if that was acknowledging the crash as a bug, or if that meant it crashes by design. So I brought it up again.

Leaves the question: Can the RTL (and packages) be build (and used afterwards) with -Cr ?

This was possible in the past and I remember that at some time (when that broke) bug reports about it were accepted and fixed.

However, if it can, then how? specifying -Cr for the make does no longer work, as it will also build the compiler.

Not important, hardly ever using it.

Reply by email

Jonas Maebe
to Paul Ishenin: No, it does not work. Testsuite has many failures too when the compiler is built with -Cr.
Paul Ishenin wrote 10 lines
16.03.13, 1:54, Martin wrote: > revision 23848 > > As reported recently: > > make clean > make.exe all LINKSMART=1 CREATESMART=1 DEBUG=1 OPTIMIZE=0 OPT="-gl > -O2" No, it does not work.

It definitely should work (there's even a special extcycle target in the compiler Makefile to test it), and has worked mostly in the past. It's not always checked and occasionally does get broken though.

Jonas

Reply by email

Paul Ishenin
to Jonas Maebe

16.03.13, 17:55, Jonas Maebe пишет:

It definitely should work (there's even a special extcycle target in the compiler Makefile to test it), and has worked mostly in the past. It's not always checked and occasionally does get broken though.

I tried to run a testsuite with compiler and packages built with -Cr. It has more failures than a regular build.

Best regards,
Paul Ishenin

Reply by email

Martin
to Jonas Maebe: It definitely should work (there's even a special extcycle target in the compiler…
Jonas Maebe wrote 18 lines
On 16 Mar 2013, at 02:35, Paul Ishenin wrote: > 16.03.13, 1:54, Martin wrote: >> revision 23848 >> >> As reported recently: >> >> make clean >> make.exe all LINKSMART=1 CREATESMART=1 DEBUG=1 OPTIMIZE=0 OPT="-gl >> -O2" > > No, it does not work. It definitely should work (there's even a special extcycle target in the compiler Makefile to test it), and has worked mostly in the past. It's not always checked and occasionally does get broken though.

The above "make" did not match my question. I have a batch and build several different configurations (mainly differ in debug related -gs/gw -O1/2 --- the -Cr was just for fun)

The -Cr make is

make clean
make.exe all LINKSMART=1 CREATESMART=1 DEBUG=1 OPTIMIZE=0 OPT="-gl -gw -godwarfsets -O-1 -Cr"

And started to crash a few weeks (maybe few month) back.

I did never run the testcases for it. Only build it, and used it to build my tests.

--------------------------

The particular crash in question is by
   cstringpattern: AnsiString;
               len:=length(cstringpattern);
               recordtokenbuf.write(cstringpattern[1],len);
with a len of zero, writing 0 bytes from an address that is out of range.
Could be solved by using
  {$PUSH} {$R-}
  {$POP}
around those lines.

Reply by email

Flávio Etrusco
to Martin
Show quoted text 13 lines
The particular crash in question is by cstringpattern: AnsiString; len:=length(cstringpattern); recordtokenbuf.write(cstringpattern[1],len); with a len of zero, writing 0 bytes from an address that is out of range. Could be solved by using {$PUSH} {$R-} {$POP} around those lines.

Or typecast it to PChar...
I always found it a PITA that Delphi raises an Exception when accessing the ending #0 with $R+ :-/

-Flávio

Reply by email

Bruce Tulloch
to Flávio Etrusco

FWIW, I ran into this problem trying to use the RTL from the FPC 2.6.2 release branch when built with -Cr. Attached is a patch that works around the problematic code (in sockets.inc).

It does not fix the underlying problem (type mismatch upon invocation of ntohl() and friends) but it does allow the RTL to be built and used with -Cr (without it, the RTL generates ERangeError).

I presume it's the intention that the RTL and packages build and run with -Cr, right?

Cheers, Bruce.

Reply by email

Michael Van Canneyt
to Bruce Tulloch
Bruce Tulloch wrote 7 lines
FWIW, I ran into this problem trying to use the RTL from the FPC 2.6.2 release branch when built with -Cr. Attached is a patch that works around the problematic code (in sockets.inc). It does not fix the underlying problem (type mismatch upon invocation of ntohl() and friends) but it does allow the RTL to be built and used with -Cr (without it, the RTL generates ERangeError). I presume it's the intention that the RTL and packages build and run with -Cr, right?

No. I would not put my money on that.

Michael.

Reply by email

Florian Klämpfl
to Michael Van Canneyt
Michael Van Canneyt wrote 16 lines
On Sun, 5 May 2013, Bruce Tulloch wrote: > FWIW, I ran into this problem trying to use the RTL from the FPC 2.6.2 > release branch when built with -Cr. Attached is a patch that > works around the problematic code (in sockets.inc). > > It does not fix the underlying problem (type mismatch upon invocation > of ntohl() and friends) but it does allow the RTL to be built > and used with -Cr (without it, the RTL generates ERangeError). > > I presume it's the intention that the RTL and packages build and run > with -Cr, right? No. I would not put my money on that.

Nevertheless it should.

Reply by email

Michael Van Canneyt
to Florian Klämpfl
Florian Klämpfl wrote 19 lines
Am 05.05.2013 09:56, schrieb Michael Van Canneyt: > > > On Sun, 5 May 2013, Bruce Tulloch wrote: > >> FWIW, I ran into this problem trying to use the RTL from the FPC 2.6.2 >> release branch when built with -Cr. Attached is a patch that >> works around the problematic code (in sockets.inc). >> >> It does not fix the underlying problem (type mismatch upon invocation >> of ntohl() and friends) but it does allow the RTL to be built >> and used with -Cr (without it, the RTL generates ERangeError). >> >> I presume it's the intention that the RTL and packages build and run >> with -Cr, right? > > No. I would not put my money on that. Nevertheless it should.

Compiler, rtl: maybe.

But packages ? With all the C imports, DB access routines ? I seriously doubt that.

Michael.

Reply by email

Marco van de Voort
to Michael Van Canneyt

In our previous episode, Michael Van Canneyt said:

Show quoted text 10 lines
>>> with -Cr, right? >> >> No. I would not put my money on that. > > Nevertheless it should. Compiler, rtl: maybe. But packages ? With all the C imports, DB access routines ? I seriously doubt that.

It was bad, but it has improved for the more used packages in the last couple of years.

fcl-passrc, chm and fpdoc are afaik fairly clean. When debugging fpdoc I always build those packages with -CRriot and fixed all issues.

I've also done whole make all builds with that, and fixed some issues, but didn't see it through till the end.

Reply by email

Michael Van Canneyt
to Marco van de Voort
Marco van de Voort wrote 20 lines
In our previous episode, Michael Van Canneyt said: >>>> with -Cr, right? >>> >>> No. I would not put my money on that. >> >> Nevertheless it should. > > Compiler, rtl: maybe. > > But packages ? With all the C imports, DB access routines ? > I seriously doubt that. It was bad, but it has improved for the more used packages in the last couple of years. fcl-passrc, chm and fpdoc are afaik fairly clean. When debugging fpdoc I always build those packages with -CRriot and fixed all issues. I've also done whole make all builds with that, and fixed some issues, but didn't see it through till the end.

I just wanted to indicate what you now confirm:
No concerted effort was made to ensure that -Cr can be used safely on packages.

I can't comment on RTL/Compiler, but for packages, I would not count on being able to use -Cr

Michael.

Reply by email

Marco van de Voort
to Michael Van Canneyt

In our previous episode, Michael Van Canneyt said:

Show quoted text 11 lines
> fcl-passrc, chm and fpdoc are afaik fairly clean. When debugging fpdoc I > always build those packages with -CRriot and fixed all issues. > > I've also done whole make all builds with that, and fixed some issues, but > didn't see it through till the end. I just wanted to indicate what you now confirm: No concerted effort was made to ensure that -Cr can be used safely on packages. I can't comment on RTL/Compiler, but for packages, I would not count on being able to use -Cr

More importantly, since there are only few nightly tests for packages/ there is no way to keep it that way once it has been done.

That needs tests that stress the most important codepaths.

Reply by email

Florian Klämpfl
to Marco van de Voort
Marco van de Voort wrote 17 lines
In our previous episode, Michael Van Canneyt said: >> fcl-passrc, chm and fpdoc are afaik fairly clean. When debugging fpdoc I >> always build those packages with -CRriot and fixed all issues. >> >> I've also done whole make all builds with that, and fixed some issues, but >> didn't see it through till the end. > > I just wanted to indicate what you now confirm: > No concerted effort was made to ensure that -Cr can be used safely on packages. > > I can't comment on RTL/Compiler, but for packages, I would not count on being > able to use -Cr More importantly, since there are only few nightly tests for packages/ there is no way to keep it that way once it has been done. That needs tests that stress the most important codepaths.

Yes, but if there is some obvious range check error which could be fixed, it should be done so.

Reply by email

Marco van de Voort
to Florian Klämpfl

In our previous episode, Florian Kl?mpfl said:

Show quoted text 7 lines
> More importantly, since there are only few nightly tests for packages/ there is no > way to keep it that way once it has been done. > > That needs tests that stress the most important codepaths. Yes, but if there is some obvious range check error which could be fixed, it should be done so.

I've been fixing such problems when I encounter them for about couple of years now. IIRC Jonas asked me to, in response to a "fix rangecheck" related bugreport.

Reply by email