On Thu, 24 Nov 2022 18:51:12 +
"J. Gareth Moreton via fpc-devel" wrote:
> Hi everyone,
>
> I just need to touch on the knowledge base. What tests exist that test
> the functionality of rtl/inc/sortbase.pp? As Olly suggested, I'm
> looking at creating Introsort for this unit as well, but
On Fri, 25 Feb 2022 05:08:48 +
"J. Gareth Moreton via fpc-devel" wrote:
> Almost every source file in the compiler and the RTL shows some kind of
> improvement. A lot of them are just redundant pointer deallocations, so
> this will help with cache misses and the like - that aside though,
Il giorno ven, 31/12/2021 alle 17.32 +0200, Christo Crause ha scritto:
> On Fri, Dec 31, 2021 at 4:41 PM Marco Borsari via fpc-devel
> wrote:
> > Hi,
> > on Linux with FPC 3.2.2 the executable size of programs compiled
> > with
> > fpc -On -a (tried with n 2
Hi,
on Linux with FPC 3.2.2 the executable size of programs compiled with
fpc -On -a (tried with n 2 or 4)
is smaller than when the assembler files are deleted (-a omitted).
Does it is an expected behaviour?
___
fpc-devel maillist -
, while they should all start at 0.
I am not sure that solves the problem, anyway it is an error.
Marco Borsari
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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;
Il 31/07/2019 08:37, thaddy ha scritto:
On 2019-07-31 08:26, Marco Borsari via fpc-devel wrote:
What
needs to be detected if all *used* labels are within the confines of the
used ordinal, but a selector without label should throw an error.
In the case of my patch it behaves like extended
of a lack of correspondence in a case
statement list should be of the same level of attention of the index
limits of an array, except there is no memory corruption risk. The
solution could be to insert a run time check in presence of the
switch {$R+}, if the latter is allowed in iso mode.
Greetings
when not all of the ordinal range for the case are processed. It
> simply does not exist as far as I am concerned, unless someone can
> convince be by a reputable source that such implementation exists
> elsewhere.
Pascal-S of Wirth does it.
Marco Borsari
--
;Deep Optimizer" but is otherwise just basic data flow analysis.
Thank you for your interest and your work,
greetings Marco Borsari
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
her parts of
the code).
Thank you for any response, Marco Borsari
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On Fri, 17 May 2019 18:06:13 +0200
Ondrej Pokorny wrote:
> On 17.05.2019 10:47, Marco Borsari via fpc-devel wrote:
> > Does this is an effect of some multiplication overflow, or is it a bug?
>
> Both the bit operations and the arithmetic opretaions return integers as
> res
On Fri, 17 May 2019 16:45:52 +0200
gabor wrote:
> Can you provide c source code?
> I'm not sure about this:
> ...(a SHL 5+b SHR 2)...
> Maybe it should look like this:
> ((a SHL 5+b) SHR 2)
>
> Regards, Michał.
Please look at
https://burtleburtle.net/bob/hash/doobs.html
for the Rotating
On Fri, 17 May 2019 14:36:52 +0200
Marco Borsari via fpc-devel wrote:
> Thank you, your answer make it clear the nature of the problem, i.e.
> operation size extension.
> Anyway, if I understand correct, the masking as reported in the code
> does not operate over the 16 bit limit
On Fri, 17 May 2019 11:55:55 +0100
"J. Gareth Moreton" wrote:
> On a slightly different note, I would be careful about only using a
> 16-bit hash, because the chance of a collision is only about 1 in 320
> (see "Birthday attack")
>
> Gareth aka. Kit
Thank you, but in my use case collisions
On Fri, 17 May 2019 11:51:20 +0100
"J. Gareth Moreton" wrote:
> One thing to be aware of is that the compiler will extend intermediate
> expressions to the CPU size, so if the multiplication overflows into 32
> bits in h1 (which it does for the given values of a and b), it will
> preserve
,
or is it a bug?
Regards, Marco Borsari
--
Simplex sigillum veri
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Il 01/01/2019 22:10, Martok ha scritto:
- If a case statement on an ordinal does not contain labels for all values of
the ordinal, and no else statement is given, raise a new warning (W6059). This
is actually defined as an error in ISO7185 and a dynamic-violation in IEC10206.
* in ISO mode,
Il 14/08/2018 12:37, Martok ha scritto:
label label0,label1,label2,{...,}afterend;
const table: array [lowestcaselabel..highestcaselabel] of CodePointer =
(@label0, @label1, @label2{,...});
if (xhighestcaselabel) then
goto @afterend;
goto table[x];
label0:
code;
goto afterend;
label1:
Il 14/08/2018 10:00, Martok ha scritto:
array of index = array of pointers, sorry
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Il 14/08/2018 10:00, Martok ha scritto:
What Kit said, but a correction: the threshold is not 50, it is 19. And what is
generated is not technically a jump table, but a
typed dispatch table.
From what I can read from Wikipedia, every compound of the case is
enclosed in
a procedure (or in a
Il 13/08/2018 16:29, J. Gareth Moreton ha scritto:
I haven't explored it too deeply myself, but from what I understand, a
jump table is only generated if there are a large number of branches
(over 50). If it's just a handful of branches, it simply subtracts
values from the input corresponding
Hello,
I would need a clarification about the way the case statement is
translated into assembler by FPC. When the list of alternatives is
continous, does the compiler generate a jump table? And if yes, there is
some conditions for which a fall-through is performed anyway?
Thank you, Marco
On Wed, 9 Aug 2017 11:55:44 +0200 (CEST)
mar...@stack.nl (Marco van de Voort) wrote:
> I hadn't built FPC for a while on this machine, and the error I get this
> morning flabbergasts me. (I also get this error when cycling when it should
> start building the compiler after the RTL. I cleaned and
Does it is possible that the LineInfo trace (-gl option) are broken (no output)
in 3.0.2 version on Linux (at least)?
--
Marco Borsari <bors...@libero.it>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/c
I've been noticed these routines are inlined in the FPC, but consulting
ninl.pas in the relate section I don't be able to understand whether the
code takes care - in case operand will be a generic pointer or a pointer
to structure of size 1 - to avoid the implicit multiplication.
Could someone
Il 28/02/2012 23:34, Tomas Hajny ha scritto:
Jonas is right, it is no bug. The difference you get between the case
of having LFN enabled or not is most likely related to the fact that
you search for '*' mask rather than '*.*' in your example. As you
might know, '*' matches
I missed that,
Hi all,
on system with long file name support activated (I have FreeDos with
doslfn), the example below types all files instead of directory only.
program test;
uses dos;
var f:searchrec;
begin
findfirst('*',directory,f);
while doserror=0 do begin
writeln(f.name);
findnext(f);
end;
Jonas Maebe wrote:
That is by design, see
http://www.freepascal.org/docs-html/rtl/sysutils/findfirst.html (the same goes
for the findfirst from the Dos unit)
You have to check the attributes of the returned entries to see whether they
match what you want. This is TP/Delphi-compatible.
I
29 matches
Mail list logo
