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
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 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
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
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
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
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
> -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
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
> -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
> -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 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:
> 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"
> 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
>
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
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
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
> -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,
> -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 ?
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 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.
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:
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
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
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
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
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.
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
29 matches
Mail list logo
