Maciej Izak schrieb am Sa., 30. Juni 2018, 08:16:
> Hi,
>
> renaming for TMormotHashFactory to TGenericsHashFactory is somehow
> acceptable (but IMO bad taste) but change for default hashing algorithm in
> such important library is really really really bad idea.
>
No, the bad taste is too have a
Maciej Izak schrieb am Sa., 30. Juni 2018, 08:15:
> 2018-06-28 22:13 GMT+02:00 Sven Barth via fpc-devel <
> fpc-devel@lists.freepascal.org>:
>
>> - why is it that you adjusted DaThoX' copyright range, but not yours at
>> the top?
>>
>
> on the top is date of creation :) (it seems like standard, b
Willibald Krenn schrieb am Sa., 30. Juni 2018,
08:01:
> TBH, I didn't know this issue existed in Delphi and I've done my share of
> Delphi over time. I still maintain that for managed types the compiler is
> responsible for some minimal initialization (like it's done for records
> etc, no?).
>
On Sat, 30 Jun 2018, Maciej Izak wrote:
Hi,
renaming for TMormotHashFactory to TGenericsHashFactory is somehow
acceptable (but IMO bad taste) but change for default hashing algorithm in
such important library is really really really bad idea.
As noted in the bugreport, your own examples did
Hi,
renaming for TMormotHashFactory to TGenericsHashFactory is somehow
acceptable (but IMO bad taste) but change for default hashing algorithm in
such important library is really really really bad idea.
This was not consulted, change like that or proposition should be reported
here :
https://git
2018-06-28 22:13 GMT+02:00 Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org>:
> - why is it that you adjusted DaThoX' copyright range, but not yours at
> the top?
>
on the top is date of creation :) (it seems like standard, but maybe I am
wrong).
--
Best regards,
Maciej Izak
__
2018-06-28 22:10 GMT+02:00 Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org>:
>
> Sorry that it took me so long, but I wanted to reread your proposed
> FastRTTI changes before deciding and I only found the time this evening.
>
> I'm currently indeed leaning towards option 2.
>
This is goo
Hi Jonas,
(Sorry for TOFU, I'm doing this from a web interface.)
First, how you implement things cannot dictate the semantics of the language. It is the other way around. Similarly and by analogy, Spectre/Meltdown for sure are bugs that need fixing and you don't treat them as features b
On 29/06/18 22:02, Stefan Glienke wrote:
If I am not mistaken (this is from my observarion and might not be 100%
accurate) usually the rule in Delphi (possibly similar in FPC) when it
allows to directly pass the LHS as hidden result parameter is when it is
a local variable.
FPC does it when i
Am 29.06.2018 um 20:10 schrieb Jonas Maebe:
That does not make any sense to me from a language design point of
view. Either the language guarantees that managed function results are
initialised to empty, or it does not. The fact that these are the same
or different temps, or if there are no te
Am 29.06.2018 um 18:14 schrieb Ondrej Pokorny:
> On 21.06.2018 22:34, Ondrej Pokorny wrote:
>> Because there have been rumours about merging 3.2, I'd like to request
>> to review 2 bug fixes that I'd like to have in 3.2 and therefore
>> before merging:
>>
>> https://bugs.freepascal.org/view.php?id=
> -Original Message-
> From: fpc-devel On Behalf Of
> Mattias Gaertner
>
> > [...] COM interface methods can't logically not be virtual,
>
> I think you are confusing things here. They can be virtual or not
> virtual in COM and CORBA.
I think a lot of people simply don't understand how
On 29/06/18 19:03, Stefan Glienke wrote:
Delphi does not reuse them, every call to a function generates a temp
variable. Sure, if you call it in a loop it of course uses the same one.
That does not make any sense to me from a language design point of view.
Either the language guarantees that
On Fri, 29 Jun 2018 14:25:19 +0200
Martok wrote:
> Am 29.06.2018 um 12:43 schrieb Michael Van Canneyt:
> > Out of curiosity, can you give a simple example of such a funny behaviour
> > in such a chaining pattern ?
> We've had this topic about 2 years ago with regard to automatic file close on
>
> -Original Message-
> From: fpc-devel On Behalf Of
> Martok
> Sent: Saturday, 30 June 2018 03:15
> To: fpc-devel@lists.freepascal.org
> Subject: Re: [fpc-devel] Managed Types, Undefined Bhaviour
>
> Okay, then why does the calling convention change matters so much?
>
> Maybe a COM/CORBA
On Fri, 29 Jun 2018 19:15:00 +0200
Martok wrote:
> Am 29.06.2018 um 16:37 schrieb Thorsten Engler:
> > The specific functions that implement an interface get baked into the class
> > at the moment when the interface is defined as part of the class. This
> > results in important differences in b
> -Original Message-
> From: fpc-devel On Behalf Of
> Michael Van Canneyt
> Sent: Saturday, 30 June 2018 03:11
> To: FPC developers' list
> Subject: Re: [fpc-devel] Managed Types, Undefined Bhaviour
>
>
> Please explain. Exactly how does it demonstrate this ?
>
> What is the expected o
On Fri, 29 Jun 2018 19:11:14 +0200 (CEST)
Michael Van Canneyt wrote:
> On Sat, 30 Jun 2018, Thorsten Engler wrote:
>
> >> -Original Message-
> >> From: fpc-devel On Behalf Of
> >> Michael Van Canneyt
> >> Sent: Saturday, 30 June 2018 01:07
> >> To: FPC developers' list
> >> Subject: Re
Am 29.06.2018 um 16:37 schrieb Thorsten Engler:
> The specific functions that implement an interface get baked into the class
> at the moment when the interface is defined as part of the class. This
> results in important differences in behaviour, depending if methods (in the
> class) are define
On Sat, 30 Jun 2018, Thorsten Engler wrote:
-Original Message-
From: fpc-devel On Behalf Of
Michael Van Canneyt
Sent: Saturday, 30 June 2018 01:07
To: FPC developers' list
Subject: Re: [fpc-devel] Managed Types, Undefined Bhaviour
what does this demo actually demonstrate other than
Delphi does not reuse them, every call to a function generates a temp
variable. Sure, if you call it in a loop it of course uses the same one.
But if you have 2 calls after each other the compiler generates two
variables. Even if they are in seperate code branches. I have often
enough optimized
On 29/06/18 17:57, Stefan Glienke wrote:
Now we are back to using temp variables (both Delphi and FPC do) but FPC again
reuses its temp variable for A and B while Delphi uses different ones. Now for
some integer this might not be a big issue but imagine you have something else
in these arrays
On 21.06.2018 22:34, Ondrej Pokorny wrote:
Because there have been rumours about merging 3.2, I'd like to request
to review 2 bug fixes that I'd like to have in 3.2 and therefore
before merging:
https://bugs.freepascal.org/view.php?id=33563
https://bugs.freepascal.org/view.php?id=33564
Why I
Let me add some information to this issue - as I think this is one - before
this drifted into the interface chaining thing:
When you execute this code in Delphi it will print 0 while on FPC it prints 42:
type
Vector = array of integer;
function DoSomething (len: Integer): Vector;
begin
SetL
> -Original Message-
> From: fpc-devel On Behalf Of
> Michael Van Canneyt
> Sent: Saturday, 30 June 2018 01:07
> To: FPC developers' list
> Subject: Re: [fpc-devel] Managed Types, Undefined Bhaviour
>
> what does this demo actually demonstrate other than that the compiler
> functions ?
On Fri, 29 Jun 2018, Mattias Gaertner wrote:
Pressed send too quickly.
home:~> ./tirc
Chain: 7FA5948CF040
Chain: 7FA5948CF040
Done: 7FA5948CF040
"stdcall" is wrong for Linux. It must be
{$IFNDEF WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
Then you get under Linux:
Addref: 7F0B93
On Fri, 29 Jun 2018 16:18:04 +0200 (CEST)
Michael Van Canneyt wrote:
> On Fri, 29 Jun 2018, Michael Van Canneyt wrote:
>
> >
> >
> > On Fri, 29 Jun 2018, Martok wrote:
> >
> >> Am 29.06.2018 um 14:41 schrieb Michael Van Canneyt:
> >>> As far as I can see, you get 2 chain and 1 done call. Whi
> -Original Message-
> From: fpc-devel On Behalf Of
> Martok
> Sent: Friday, 29 June 2018 23:55
> To: fpc-devel@lists.freepascal.org
> Interface functions are always virtual and implemented by the
> actually instantiated class. The "override" keyword is neither
> allowed nor needed,
With
On Fri, 29 Jun 2018, Martok wrote:
Am 29.06.2018 um 16:05 schrieb Michael Van Canneyt:
The expected output would be 3 Addrefs and 3 Releases.
I don't get that.
Somewhat current FPC trunk output, annotations added manually:
==
Addref: 0022FAA
On Fri, 29 Jun 2018, Michael Van Canneyt wrote:
On Fri, 29 Jun 2018, Michael Van Canneyt wrote:
On Fri, 29 Jun 2018, Martok wrote:
Am 29.06.2018 um 14:41 schrieb Michael Van Canneyt:
As far as I can see, you get 2 chain and 1 done call. Which is what I'd
expect.
The overrides of the
Am 29.06.2018 um 16:05 schrieb Michael Van Canneyt:
>> The expected output would be 3 Addrefs and 3 Releases.
>
> I don't get that.
Somewhat current FPC trunk output, annotations added manually:
==
Addref: 0022FAA8 Refcount: 1 at 00404961
On Fri, 29 Jun 2018, Michael Van Canneyt wrote:
On Fri, 29 Jun 2018, Martok wrote:
Am 29.06.2018 um 14:41 schrieb Michael Van Canneyt:
As far as I can see, you get 2 chain and 1 done call. Which is what I'd
expect.
The overrides of the _* calls are useless, since they are not virtual in
On Fri, 29 Jun 2018, Martok wrote:
Am 29.06.2018 um 14:41 schrieb Michael Van Canneyt:
As far as I can see, you get 2 chain and 1 done call. Which is what I'd expect.
The overrides of the _* calls are useless, since they are not virtual in
TInterfacedObject and hence never called. So that's O
Am 29.06.2018 um 14:41 schrieb Michael Van Canneyt:
> As far as I can see, you get 2 chain and 1 done call. Which is what I'd
> expect.
> The overrides of the _* calls are useless, since they are not virtual in
> TInterfacedObject and hence never called. So that's OK too.
Interface functions are a
On Fri, 29 Jun 2018, Martok wrote:
Am 29.06.2018 um 12:43 schrieb Michael Van Canneyt:
Out of curiosity, can you give a simple example of such a funny behaviour
in such a chaining pattern ?
We've had this topic about 2 years ago with regard to automatic file close on
interface release. Inter
Am 29.06.2018 um 12:43 schrieb Michael Van Canneyt:
> Out of curiosity, can you give a simple example of such a funny behaviour
> in such a chaining pattern ?
We've had this topic about 2 years ago with regard to automatic file close on
interface release. Interestingly, something must have changed
So I've made a breakthrough. The memory corruption is due to both parts of
the CMOV optimization under OptPass2Jcc, not my Jcc addition (although it
might have unintentionally accentuated it). The first part sets p to a
dangling pointer, while the 2nd part is a little more complicated, but I'll
tr
On Fri, 29 Jun 2018, Martok wrote:
I hope this issue gets addressed, as I deem the current behaviour completely
broken and also going totally against the spirit of Pascal, feeling much more
like some very obscure behaviour I'd expect from some C compiler.
Discovering the handling of this issue
It turns out that it's invalid memory. Trying to call "ClassName" raises
an access violation (other aligns work fine). There's a dangling pointer
somewhere. I found one in the CMOV optimisation code, but that hasn't
fixed the crash.
Gareth
On Fri 29/06/18 10:27 , Martok list...@martoks-plac
> I hope this issue gets addressed, as I deem the current behaviour completely
> broken and also going totally against the spirit of Pascal, feeling much more
> like some very obscure behaviour I'd expect from some C compiler.
> Discovering the handling of this issue, however, makes me wonder
> whe
> A clue that leads me to believe there's internal corruption is that a produced
> .s file yields an alignment field of ".balign 119,0x90", which should never
> happen.
Could you set a breakpoint on aggas.pas:721 (the call to doalign) with a
conditional on "tai_align_abstract(hp).aligntype=119" and
Hi everyone,
I'm having some difficulty with fixing issue #33909, and I may have
stumbled a more severe problem that might be causing some internal
corruption. I have raised a new issue about it, #33926. Given the
recent e-mail from Pierre, there might be something amiss going on inside
the com
42 matches
Mail list logo
