Nice work, Gareth.
Vectorization is definitely a nice improvement for the compiler.
-- Regards,
Denis Golovan
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> It does seem incomplete that you can’t make a generic constrained for string
> types for example. Why don’t more languages have that? It seems like an
> obvious feature which should be supported.
Rust & Haskell do that.
But that's another story :)
-- Regards,
Denis Golovan
> On 9/8/2021 2:25 PM, denisgolovan via
> fpc-devel wrote:
>
>>>> Compiler builds release
> binaries fine.
>
> What do you mean - it should work on
> "trunk"?
No. I mean it should work when -g and stuff like that is _omitted_.
Thus compiler does
I believe it's the same issue I have in
https://gitlab.com/freepascal.org/fpc/source/-/issues/39140
Compiler builds release binaries fine.
-- Regards,
Denis Golovan
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/
Well.
Maybe it's not that complex after all?
I mean, Linux target (not cross-compiling) builds fine. It's Linux->Win64 build
fails with those errors.
That regards https://bugs.freepascal.org/view.php?id=39140 , of course.
-- Regards,
Denis Golovan
___
https://bugs.freepascal.org/view.php?id=39140Sorry, I forgot to send my bug13:33, 4 июля 2021 г., "denisgolovan via fpc-devel" :Sure. See attachment the bug I've created12:55, 4 июля 2021 г., "J. Gareth Moreton" <gar...@moreton-family.com>:I just double-checked
st?Gareth aka. KitOn 04/07/2021 10:19, denisgolovan wrote: I've posted a patch in the previous bug report, but I'll be the first to admit that it's a little hacky. Given the linker errors in #39140 are similar to those in #38827, does it fix those too? Nope, unfortunately it does no
> I've posted a patch in the previous bug report, but I'll be the first to
> admit that it's a little hacky. Given the linker errors in #39140 are
> similar to those in #38827, does it fix those too?
Nope, unfortunately it does not.
-- Regards,
Denis Golovan
__
Thanks, Gareth.
I've created another issue, possibly related -
https://bugs.freepascal.org/view.php?id=39140
Sven, could you take a look?
-- Regards,
Denis Golovan
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/
> Am 27.09.20 um 21:50 schrieb Florian Klämpfl via fpc-devel:
>> Not for 80 bit extended, but it would be the clean solution with
>> float128 support being optional in some architectures (RiscV, Sparc64,
>> PPC64). So if we change it, we should do it right as 80 Bit has the same
>> problem: missing
> See above. It perfectly shows why it is frightening (not the basic
> stuff, but the transcendent functions):
> - there are little libraries being really IEEE compliant for float128
> - if they are IEEE compliant, their license does not allow to use the
> code in the FPC rtl.
Ok, the license is t
> Am 27.09.20 um 18:21 schrieb Florian Klämpfl via fpc-devel:
> So we would need softfloat extended support. This is doable with one
> major obstacle: the "irrational" functions like ld, sin etc.: they need
> precise enough implementations for 80 bit (actually, just adding and
> using in the compil
> I think Gareth meant the address of V instead (Pointer(@V)).
>
> Regards,
> Sven
Hm. I have no idea why anyone would take pointer to pointer :)
BTW, Sven, what's your opinion on dynamic arrays alignment problem?
I don't have any viable solution besides maintaining my own compiler fork so
far
> One thing to be slightly aware of with
> dynamic pointers and alignment. For V: atray
> of Integer etc, make sure you check the
> alignment of V[0], not V. V points to an
> internal structure that is largely opaque,
> while V[0] points to the actual data, which I
> imagine is what you want to p
> In that instance, I think it's because TIntArray is not a record type
> (it's essentially a smart pointer) and so RECORDMIN doesn't apply to
> it. I do agree though that having an 'align' attribute of some kind
> will make life a lot easier since you don't have to play around with
> multiple pr
> From tests/test/cg/tvectorcall1.pp
>
> {$PUSH}
> {$CODEALIGN RECORDMIN=16}
> {$PACKRECORDS C}
> type
> TM128 = record
> case Byte of
> 0: (M128_F32: array[0..3] of Single);
> 1: (M128_F64: array[0..1] of Double);
> end;
> {$POP}
>
> (This declaration mimics how __m128 is defined in Microsoft Vi
> I did suggest it once - https://bugs.freepascal.org/view.php?id=32780 -
> it would make things useful and allow for cleaner typecasting with the
> internal __m128 type etc. It was assigned, but appears to have stalled.
Yeap. That's right it's a long awaited feature.
> There might be some portab
Hi
I think another related idea is adding some "attribute" to dynamic arrays types
to force them to be aligned to 32/64 bytes.
Precisely for this purpose, I am forced to maintain my own FPC fork.
-- Regards,
Denis Golovan
___
fpc-devel maillist - fpc
> Simply clearing all the compiled files results in correct
> compilation. Any thoughts on how to proceed with this? Am I the only one
> to see this?
>
> Colin
It happens sometimes.
Although it happens much less frequent in current trunk.
Please report in bugtracker if you have reproducible case.
> Anybody knows whats going on and why it stopped working? (I am on
> Windows and use the 32bit compiler. Today's FPC trunk, today's Lazarus
> trunk.)
Same story.
See https://bugs.freepascal.org/view.php?id=35877
-- Regards,
Denis Golovan
___
fpc-devel
> Here’s the results of "git log —graph” on the feature branch. Does that first
> part look right? I feel like I messed up something from the very start but
> I’m not sure what.
>
> Ryans-MacBook-Pro-2:fpc-git ryanjoseph$ git log --graph
> * commit c5a6c2c0822d6c869a788a98a144e739a97d517a (HE
> I tried doing "git rebase origin/master” on the feature branch BEFORE I
> merged the master but it says "Current branch gen-const-new is up to date.”.
> What is rebase doing that it thinks the feature branch is up to date?
Generally it means all your feature branch commits are on top of origin
> Complex types are built from primitive types. And if FPC can verify the
> "pure" attribute is valid, then LLVM can probably also come up with it.
> In fact, if FPC can verify it is valid, it can also come up with it
> itself and add it as an annotation in the LLVM bitcode.
AFAIU, "pure" attribut
> You don't need any kind of new source code constructs for optimizing
> that. The LLVM backend can already do that; in the worst case, only when
> LTO is enabled (in case the function is declared in another unit)
>
> Jonas
I am pretty sure LLVM is advanced enough to make that analysis itself for
> Long story short, it took me a brief moment to see how the optimisation
> would work until I thought about it a bit more, but if PureFunc is
> indeed pure, then that could certainly be a development goal.
Yes, you've got the idea.
The complete system has a lot of issues and edge cases.
However
> Can I have an example of "hoisting pure functions out of loops" that you
> speak of?
Sure.
I mean something like following (completely artificial example):
function PureFunc1: ...
function F(arg: Integer): Integer;
var s:Integer;
begin
s:=0;
for i:=0 to 100 do
s:=s+PureFunc(arg);
Res
Hi Gareth
I'd like to know if the scope of your interest in "pure" is just initialization
of constants or you plan to implement some optimizations as well?
I mean something like hoisting pure functions out loops.
--
Regards,
Denis Golovan
___
fpc-deve
> You can do it like this (yes, works in mode Delphi as well):
>
> === code begin ===
>
> {$mode objfpc}
> {$modeswitch advancedrecords}
>
> type
> generic TPointerType = record
> public type
> PT = ^T;
> end;
>
> generic procedure MemCopy(Dest, Src: specialize
> TPointerType.PT; Len: PtrUInt)
Hi Sven
Just my 50 cents.
Just stumbled upon the same problem today.
I mean typed pointer in generic function.
But "specialize TPointerType.PT" is just too much noise.
Personally, I consider this issue really annoying as for generics.
--
Regards,
Denis Golovan
_
> Really ?
> I wonder what kind of code you write to make this 'super buggy' statement.
>
> I myself write lots of code, and never encountered an issue.
> But then, I normally don't use dubious constructs to begin with.
>
> In general of course I agree 100% with your statement that we need a cl
> 1) In you example you are writing this with normal arrays:
>
> A[0].X := 0;
>
> And in my implementation it's exactly the same. Regarding writing the entire
> type directly
>
> A[0]^ := V;
>
> If using the caret symbol ^ or an Item property is a deal breaker, then this
> can be simplified
Exactly, alignment might be well attached to array or array element type.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Hi Jonas
Vector type in FPC is too good to be true.
I didn't dare to dream about it so far :)
BR,
Denis
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Hi Anthony
> The more that I think about it, the more I am believe that using my approach
> is probably the best solution. Hear me out please.
>
> First, it would be fairly easy to implement copy on write logic with a custom
> record class.
>
> Second, because it's Pascal code, it's entirely
Hi all
Sorry for possible starting a new thread as I've just managed to subscribe to
the list.
Could we discuss more options here?
Maybe separate aligned array is a better alternative?
I mean a new type fully backward compatible with dynamic arrays, but with
additional requirements (more spe
35 matches
Mail list logo
