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 -
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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:
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
___
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
> 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
Sure. See attachment the bug I've created12:55, 4 июля 2021 г., "J. Gareth Moreton" :I just double-checked and my patch does fix the code example, at least for me, but there might be more at play. Do you have a Windows code example that still fails that you're testing it against?Gareth aka. KitOn
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 and
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
> 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
> 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
18 matches
Mail list logo
