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
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
On Sun, 5 May 2013, Florian Klämpfl wrote:
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
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
On Sun, 5 May 2013, Marco van de Voort wrote:
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.
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
Am 05.05.2013 11:14, schrieb Marco van de Voort:
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
In our previous episode, Florian Kl?mpfl said:
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
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
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 allLINKSMART=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
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
On 16/03/2013 09:55, Jonas Maebe wrote:
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 allLINKSMART=1 CREATESMART=1 DEBUG=1 OPTIMIZE=0 OPT=-gl
-O2
No, it does not work.
It definitely should work
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-}
revision 23848
As reported recently:
make clean
make.exe allLINKSMART=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
16.03.13, 1:54, Martin wrote:
revision 23848
As reported recently:
make clean
make.exe allLINKSMART=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,
On 16/03/2013 01:35, Paul Ishenin wrote:
16.03.13, 1:54, Martin wrote:
revision 23848
As reported recently:
make clean
make.exe allLINKSMART=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
On 16/03/2013 02:13, Martin wrote:
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
17 matches
Mail list logo
