[fpc-devel] Const optimization is a serious bug

[Alexander Klenin]

On Sun, Jul 10, 2011 at 18:53, Hans-Peter Diettrich
<DrDiettrich1 at aol.com> wrote:
> Alexander Klenin schrieb:
>> 1) This is contrary to previous posts in this same thread, where
>>  FPC developers insisted that "const" semantics is defined as
>>  "no refcounting", which is quite different from a hint.
> Refcounting is one optimization aspect, passing large data byref another one.
Yes, but the argument was made that "no refcounting" is the required feature
of const, not merely an "optimization aspect".

>> What would you say if adding "inline" keyword to a procedure
>> converted working program into randomly crashing one? I'd say this
>> is optimization bug,  much like the title of this thread.
>
> IMO the situation is very different for "inline". Both optimizations have
> very little in common (from the compiler VP).

Having no common implementation code does not prevent those features
from being similar from user's POV.
BTW they are not as independent as you might think -- did you know
that adding "inline" currently changes semantics of "const"?

>> 3) Current documentation
>> (http://www.freepascal.org/docs-html/ref/refsu58.html)
>>  declares that "const" modifier is "retaining the semantics of
>> passing by value",
>> so there is definitely a bug here -- you can declare it to be bug in
>> specification, but still.
>
> Sorry, I cannot find anything like this statement in the link.
It is a direct quote -- you can use "find on page" feature of your browser
(usually activated by pressing Ctrl+F) to locate it.

>> On the more constructive note, I have yet another proposal:
>> 1) Leave current "const" implementation broken as-is.
>> 2) Introduce new "constval" modifier which is similar to "const",
>>  but guarantees correct "by-value" semantics.
>
> If you want to introduce different keywords, then please different for
> beforementioned cases. E.g.
> constval x: integer; //all value-types
> constref r: Trecord; //also ShortString
> const??? o: TObject; //all references, except following
> const??? s: AnsiString; //all managed types

I am not quite sure what are you asking here. Can you elaborate?

> BTW the "constref" keyword has been introduced for *external* subroutines
> (MacOS ABI), which require that a value is always passed by reference,
> independent from SizeOf(param) and SizeOf(pointer). Its use should be
> restricted accordingly.
Why? It is well-defined and useful construct, certainly better then "const".

>> 3) Slowly migrate existing code to either "constref" or "constval",
>>  use "const" for legacy/compatibility/extreme optimization cases.
>
> <IMO> "const" is already used far too often in the FPC/Lazarus libraries.
Totally agree.

> The compiler instead should treat it as an error, when an unmanaged (object)
> reference is used with "const".
Good idea, BTW! Probably error is out of question for compatibility reasons,
but a warning would certainly be good.
FPC developers: maybe I'll create feature request for this?
It is quite independent of the rest of thread.

> When the meaning of "const"/"constref" is documented as kind of a *calling
> convention*, that allows the compiler to optimize the code, no more
> discussion is required.

"constref" is a calling convention, but "const" is not, since it is
"optimization hint".
As you said above, this is the reason why "constref" was invented in
the first place.

-- 
Alexander S. Klenin