[fpc-devel] Possible idea... "safe" subroutines/methods

[Sven Barth]

J. Gareth Moreton <gareth at moreton-family.com> schrieb am So., 5. Mai 2019,
05:11:

> One problem I do have with FPC and its optimiser is that -O4 is
> specifically said that it may cause side-effects and even tongue-in-cheek
> says "beware".  To me, this is bad design because it discourages the end
> users from using the option and if an optimisation causes well-behaved code
> to suddenly start malfunctioning, then that is a bug in my eyes.  To me,
> I'd like -O4 to be that aggressive, deep optimisation that may take a few
> hours on the largest of projects (although in reality it will probably only
> be a few minutes), but which isn't going to create something questionable
> that will break things.
>
The "beware" is only related to code that relies on implementation details.
E.g. the order of fields in a class which everyone assumes is the same in
memory as the one its written in the code.

It's partly why I was wondering about marking certain procedures or
> variables as non-volatile so they can be moved to local storage without
> having to do it programmatically and making the code unmaintainable.  By
> specifically telling the compiler "this value is thread-safe", it can make
> those assumptions because you've assured it that you're not doing something
> tricky with it, rather than attempting to let the compiler work it out for
> itself (which is probably impossible) and hence assume it's not thread-safe
> and hence volatile.
>
And you can get malfunctioning with such modifiers as well, namely if the
user does not adhere to what to what they told the compiler. This might
even happen by accident if one uses third party code and does not know that
the code uses that (the known problems with "const" are an existing example
of that).

Regards,
Sven

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190505/b9e00bfa/attachment.html>