It looks like it throws warnings if the compiler is able to recover
(e.g. by truncating the literal). If something is too short though,
then it can't recover because it has no idea what to fill the end with.
If you include the warnings, are there any places where messages are not
thrown? I
Gareth aka. Kit wrote:
> What happens if you run the program with these
> false negatives? If you get a buffer overrun, then
> it is pretty serious.
When running in debug mode, I get no range check or overflow errors.
A 9-byte sized value when assigned to an 8-byte sized variable gets
truncated
It does look like a bug on the surface. What happens if you run the
program with these false negatives? If you get a buffer overrun, then
it is pretty serious.
Gareth aka. Kit
On 16/04/2022 21:35, Wayne Sherman via fpc-devel wrote:
Tested with fpc 3.3.1 trunk (as of 2022-Mar-12) and 3.2.2
Tested with fpc 3.3.1 trunk (as of 2022-Mar-12) and 3.2.2 stable.
Ubuntu 20.04 64-bit
Good compile time error checking is one of the wonderful things about
Pascal. But some char array and shortstring assignments which are not
size compatible do not produce a compile error as expected. Please
It's funny - for some reason I was expecting a lot of opposition!
I knew about FillChar being written in assembly langauge and know from
experience that FPC will never support the inlining of pure assembler
routines (as Florian said, it will just open a huge can of worms). My
thought was how
That answers that. MOV/CMP/CMOV is faster than CMP/CMOV/CMOV. Thanks.
I've been finalising another peephole optimisation. What started as a
means to permit constants in CMOV instructions using a bit of trickery
became almost an entire rewrite of the optimisation if only because I
was
> Am 16.04.2022 um 12:31 schrieb Thorsten Otto via fpc-devel
> :
>
> On Samstag, 16. April 2022 06:49:07 CEST J. Gareth Moreton via fpc-devel
> wrote:
> > but I haven't been able to find an authoritive
> > source on this yet.
>
> Did you check what for example GCC generates for similar C
> Am 16.04.2022 um 01:26 schrieb J. Gareth Moreton via fpc-devel
> :
>
> Hi everyone,
>
> This is something that sprung to mind when thinking about code speed and the
> like, and one thing that cropped up is the initialisation of large variables
> such as arrays or records. A common means
Hi,
FillChar is on most platforms an assembly function and FPC *never*
inlines assembly functions.
even without inlining, rep stosb is faster than FillChar:
{$asmmode intel}
procedure repfillchar(var buffer; len: sizeuint; c: byte);
begin
asm
mov al, c
mov rdi, buffer
mov
On 4/16/22 16:41, Sven Barth via fpc-devel wrote:
Benito van der Zander via fpc-devel
schrieb am Sa., 16. Apr. 2022, 15:43:
Hi,
it could always inline it.
For small sizes do that mov and for large sizes do rep stosb on
x86. It is very fast nowadays. Faster than FillChar on
J. Gareth Moreton via fpc-devel schrieb am
Sa., 16. Apr. 2022, 01:33:
> Actual Pascal calls to FillChar would not change in any way and so
> theoretically it won't break existing code. The only drawback is that
> the intrinsic and the internal System functions would have to be named
> the same
Benito van der Zander via fpc-devel
schrieb am Sa., 16. Apr. 2022, 15:43:
> Hi,
>
> it could always inline it.
>
> For small sizes do that mov and for large sizes do rep stosb on x86. It is
> very fast nowadays. Faster than FillChar on my Intel laptop. (except for
> mid sizes like 128 bytes)
>
Hi,
it could always inline it.
For small sizes do that mov and for large sizes do rep stosb on x86. It
is very fast nowadays. Faster than FillChar on my Intel laptop. (except
for mid sizes like 128 bytes)
Bye,
Benito
On 16.04.22 01:26, J. Gareth Moreton via fpc-devel wrote:
Hi everyone,
On Samstag, 16. April 2022 06:49:07 CEST J. Gareth Moreton via fpc-devel
wrote:
> but I haven't been able to find an authoritive
> source on this yet.
Did you check what for example GCC generates for similar C constructs? I don't
think it uses cmov at all.
> Am 16.04.2022 um 06:49 schrieb J. Gareth Moreton via fpc-devel
> :
>
> Hi everyone,
>
> In the x86_64 assembly dumps, I frequently come across combinations such as
> the following:
>
> cmpl%ebx,%edx
> cmovll%ebx,%eax
> cmovnll%edx,%eax
>
> This is essentially the
15 matches
Mail list logo
