On 2019-11-08 22:33, Bart via fpc-devel wrote:
Hi,
> 2.
A rather more serious issue.
Compile time errors occur with e.g.
ANativeInt.SetBit(High(TNativeIntBitIndex)) in modes tp (32-bit), fpc
(32-bit), objfpc (32+64-bit) and delphi (32+64-bit)
Range check error while evaluating constants (21474
Am 10.11.2019 um 15:47 schrieb Marco van de Voort:
(and btw, if you are serious about these scenarios, drop all
optimization work immediately, and start working on packages :-)
I don't know if that would help much, cause especially on Windows every
application would probably provide its own set
Am 10.11.19 um 18:01 schrieb J. Gareth Moreton:
Fair enough - thank you.
This is a bit of a micro-optimisation for the compiler in regards to
what I've just done, but I've noticed that, a couple of times, commands
to the effect of the following appear:
tasmlabel(symbol).decrefs;
if tasmlabel
Fair enough - thank you.
This is a bit of a micro-optimisation for the compiler in regards to
what I've just done, but I've noticed that, a couple of times, commands
to the effect of the following appear:
tasmlabel(symbol).decrefs;
if tasmlabel(symbol).getrefs = 0 then
...
That is... derefer
Am 10.11.19 um 17:42 schrieb J. Gareth Moreton:
Some of the "condition_in" functions need expanding though, and I don't
yet have an answer if it's okay to do operator overloading in the
compiler source (so I can do things like "if (jmp1.cond in jmp2.cond)
then", for example, instead of the mo
That seems fair, yep. Currently, vectorcall, and the more intricate
parts of the System V ABI, is only really beneficial when interfacing
with third-party libraries or when programming in assembly language.
Sorry if I've given you a headache with my stubbornness and passion.
I'll try to beha
Il 10/11/2019 14:36, Jonas Maebe ha scritto:
Hi,
Does anyone know what the accepted/excepted behaviour is regarding the
capture of addresses of var/out/const-by-address/constref parameters?
For example:
var
g: longint;
p: plongint;
procedure test(var l: longint);
begin
p:=@l;
end;
b
Am 10.11.19 um 16:02 schrieb J. Gareth Moreton:
This message chain has proven to be a lot more educational and
insightful than I would have given it credit for. Thanks everybody!
I know a lot of the time, the size of binaries is just an illusion,
along with unfair comparisons with GCC (a behe
On Sun, 10 Nov 2019, J. Gareth Moreton wrote:
This message chain has proven to be a lot more educational and
insightful than I would have given it credit for. Thanks everybody!
I know a lot of the time, the size of binaries is just an illusion,
along with unfair comparisons with GCC (a beh
This message chain has proven to be a lot more educational and
insightful than I would have given it credit for. Thanks everybody!
I know a lot of the time, the size of binaries is just an illusion,
along with unfair comparisons with GCC (a behemoth with corporate
support) and Microsoft Visua
Op 09/11/2019 om 15:51 schreef J. Gareth Moreton:
Competitions aside, there are times where space is a premium, whether
it be from distributing an application on a DVD, bandwidth or data
limits (even some first world countries are still on dial-up in
places, or are otherwise monopolised by a
On 10/11/2019 15:05, Jonas Maebe wrote:
On 10/11/2019 14:58, Martin Frb wrote:
So I am trying to understand what the difference (in terms of safety)
is? (except that the none "var param" is always unsafe, the "var param"
is only sometimes unsafe)?
If you are talking about the safety of accesses
On 10/11/2019 14:58, Martin Frb wrote:
> So I am trying to understand what the difference (in terms of safety)
> is? (except that the none "var param" is always unsafe, the "var param"
> is only sometimes unsafe)?
If you are talking about the safety of accesses after the capturing
routine has exit
Op 10/11/2019 om 11:17 schreef Marģers . via fpc-devel
Most processors have a fairly large uop cache (up to 2048 for the newest
generations iirc), so this would only be for the first iteration? Do you
have a reference (agner fog page or so) or more explanation for this
that describes this?)
I
On 10/11/2019 14:36, Jonas Maebe wrote:
For example:
var
g: longint;
p: plongint;
procedure test(var l: longint);
begin
p:=@l;
end;
begin
test(g);
end.
After test() executes, p now contains the address of g (the '@' operator
does not return the address of g's address on the stack;
On Sun, 10 Nov 2019 02:23:03 +
"J. Gareth Moreton" wrote:
> Does the smart linker strip out LCL components that are not used, or
> must everything that's registered in a package or unit be included?
If you mean with "registered" the RegsiterClass or RegisterComponents
functions:
If it is r
Hi,
Does anyone know what the accepted/excepted behaviour is regarding the
capture of addresses of var/out/const-by-address/constref parameters?
For example:
var
g: longint;
p: plongint;
procedure test(var l: longint);
begin
p:=@l;
end;
begin
test(g);
end.
After test() executes, p now
Am 10.11.19 um 11:45 schrieb Jonas Maebe:
On 2019-11-10 10:54, Michael Van Canneyt wrote:
It's not just the waste of time, it's also the origanization of the
sources.
See my mail to Florian. I have 1 application that has all the tests. It's
easy to navigate & whatnot.
The nice thing about you
Am 10.11.19 um 10:54 schrieb Michael Van Canneyt:
On Sat, 9 Nov 2019, Jonas Maebe wrote:
On 09/11/2019 20:17, Michael Van Canneyt wrote:
On Sat, 9 Nov 2019, Jonas Maebe wrote:
I definitely want to help to integrate the tests somehow in the daily
testrun, but I will not use the slow tests
On 2019-11-10 10:54, Michael Van Canneyt wrote:
It's not just the waste of time, it's also the origanization of the
sources.
See my mail to Florian. I have 1 application that has all the tests.
It's
easy to navigate & whatnot.
The nice thing about your punit-based tests is that they can just
> Op 2019-11-09 om 02:24 schreef Marģers . via fpc-devel:
> >
> > 3) it changes code location (code cross page boundaries). For my particular
> > cpu there are 64 byte code page. If loop can fit in it, speed is twice as
> > it overlaps even one byte over page boundary. Jumping forward is ok (as
On Sat, 9 Nov 2019, Jonas Maebe wrote:
On 09/11/2019 20:17, Michael Van Canneyt wrote:
On Sat, 9 Nov 2019, Jonas Maebe wrote:
I definitely want to help to integrate the tests somehow in the daily
testrun, but I will not use the slow testsuite.
With parallel compilation, it will be barel
On Sat, 9 Nov 2019, Jonas Maebe wrote:
On 09/11/2019 20:17, Michael Van Canneyt wrote:
home:~/fpc> time make clean all PP=ppcx64-3.0.4 > out
/usr/bin/ld: warning: x86_64/bin/x86_64-linux/link.res contains output
sections; did you forget -T?
119.139u 11.763s 1:47.32 121.9% 0+0k 179800+1292024i
J. Gareth Moreton schrieb am So., 10. Nov.
2019, 03:23:
> Does the smart linker strip out LCL components that are not used, or must
> everything that's registered in a package or unit be included? Granted,
> since forms are being read from a resource file, I doubt it can really be
> tied into the
24 matches
Mail list logo