One drawback I've noticed is that there's no clean way to free the
optinfo pointer when the tai object is destroyed, plus there's the
danger of the pointer being used as a plain integer instead of pointing
to an actual structure (conversely, the Tag property in components was
often used to hold
On Fri, Oct 1, 2021 at 11:03 PM Christo Crause
wrote:
> On Wed, Sep 29, 2021 at 8:42 PM Florian Klämpfl via fpc-devel <
> fpc-devel@lists.freepascal.org> wrote:
>
>> Am 29.09.21 um 18:10 schrieb Christo Crause via fpc-devel:
>> > There is a long list of AVR commits dating back to 2018. Is someon
That's useful to know - thanks Jonas.
On 03/10/2021 13:10, Jonas Maebe via fpc-devel wrote:
On 03/10/2021 14:04, J. Gareth Moreton via fpc-devel wrote:
I'm aware that the tai class declares an "optinfo" field, although I'm
uncertain if this is safe to use or not given it's wrapped by an
conditi
On 03/10/2021 14:04, J. Gareth Moreton via fpc-devel wrote:
> I'm aware that the tai class declares an "optinfo" field, although I'm
> uncertain if this is safe to use or not given it's wrapped by an
> conditional define and is of type Pointer.
It's wrapped under {$ifndef NOOPT}, because it's inte
Hi everyone,
So as my optimisations get more and more sophisticated and intelligent,
I'm realising that I may need ways to store more information than is
currently possible. Obviously I want to avoid enlarging the internal
state too much or making the code unwieldly, but the additions I have
On Sat, Oct 2, 2021 at 10:53 PM Dimitrios Chr. Ioannidis <
d.ioanni...@nephelae.eu> wrote:
> I think that the CIE dwarf fix should be included also, commit
> 1e960a9aeb12ae75877ef9321efbb89f34bbbdce .
>
Even though that particular commit is simple, it is entangled with commit
65aebd22b0cb4e1709648