On Thu, 27 Dec 2018, 23:37 Florian Klämpfl
> Thanks, I have applied it in r40678 (with a small fix to make it
> compilable). I am not aware of other places where
> changes could be necessary.
Apologies for missing the tempreg2 declaration in the patch. I make
modifications to the compiler in git
Is it possible to still consider these
changes? They do give big time savings
when compiling large projects under x86_64
and a couple of the rewritten functions
perform better in finding optimisations
with jumps. I'm holding off doing
additional peephole additions until I know
whether this
Ok I have this really weird issue. fpc 3.0.4 64 bit / built from svn tag.
At this stage I am just happy for any idea
There is a function with several try finally blocks.
It also has one implicit finally block. This is for freeing the memory
of an open array.
When the open array gets passe
Am 23.12.2018 um 06:58 schrieb Christo Crause:
> According to AVR manuals 16 bit timer registers share a temp register which
> requires a specific sequence for
> reading/writing: "To do a 16-bit write, the high byte must be written before
> the low byte. For a 16-bit read, the low
> byte must be
Seems fair. Users probably wouldn't find much use for it anyway, and it
would only increase the size of the compiler binary.
I figure though it could be very useful for, say, allowing compilation and
linking with C++ code (if https://www.freepascal.org/future.html is still
accurate!)
I'm happ
Am 27.12.2018 um 20:48 schrieb Jonas Maebe:
> No, there is not. If a def needs to be different depending on the
> language mode, you have to store it in the def.
Thought so. Thank you for confirming!
Cheers,
Martok
___
fpc-devel maillist - fpc-devel
Am 23.12.2018 um 17:09 schrieb J. Gareth Moreton:
> Hi everyone,
>
> I've developed a feature to output the compiler-generated node trees into XML
> files that could prove useful for
> debugging purposes. While the ability to print the nodes to the console or a
> log file already exist, it gets
On 2018-12-27 20:46, Martok wrote:
Is there a (ppu-persisted) way to find out in what language mode (fpc,
iso,
tp..) a tdef was originally declared? The current_settings.modeswitches
obviously refer to the module it is currently used in.
No, there is not. If a def needs to be different depend
Hi all,
just a very quick question - I think the answer is no, but that doesn't mean
anything:
Is there a (ppu-persisted) way to find out in what language mode (fpc, iso,
tp..) a tdef was originally declared? The current_settings.modeswitches
obviously refer to the module it is currently used in.
Hi everyone.
This is just a follow-up on https://bugs.freepascal.org/view.php?id=34762,
since the issue has been marked as resolved now.
The apparent regression doesn't seem to exist. Both the trunk (before it
was updated) and the patch produce a linear list for the test in question -
e.g.:
Jonas Maebe wrote:
On 2018-12-02 11:26, Jonas Maebe wrote:
The LLVM version of the code generator has been significantly improved
in the mean time:
Good work !
Regards,
Adriaan van Os
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
On Wed, 26 Dec 2018, Franz Müller wrote:
In the current implementation of TStringlist, there is a property
SortStyle, which is somewhat similar to the property Sorted. However, it
is different from sorted in that it allows 3 values: sslnone, which
corresponds to sorted=false, sslAuto, which
In the current implementation of TStringlist, there is a property
SortStyle, which is somewhat similar to the property Sorted. However, it
is different from sorted in that it allows 3 values: sslnone, which
corresponds to sorted=false, sslAuto, which corresponds to sorted=true,
and sslUser, whi
So I've been doing a bit more research, and I think my binary search
algorithm is, unfortunately, a failure. Even after restructuring my
lookup table and making some minute optimisations, it's still slower
overall in my test program, and slower than a jump tree if that gets
used. I'm figuring th
14 matches
Mail list logo
