[fpc-devel] Const optimization is a serious bug

[Hans-Peter Diettrich]

Alexander Klenin schrieb:

> Martin, I do not know why you and Hans suddently have an urge to insult Chad,
> but he really did not deserve this.

Perhaps a threshold was reached, when the same wrong argumentation was 
refrained too often.


> As for the whole "optimization hint" angle, I'd like to note that:
> 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.

> 2) If "const" is indeed an optimization hint, that places it in the
> same category as,
>   say, "inline". 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).

> 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. The 
addressed byval/byref move doesn't change the semantics, provided that 
the item is not modified in user code - this can be verified for records 
or other simple types by the compiler.

The situation is very different for parameters, which already *are* 
references. In these cases the passed object can be modified, regardless 
of "const", the compiler only checks that the reference *itself* is not 
changed.

The situation is different again for *managed* types, which also are 
always passed byref. Here the removal of refcounting applies.


> 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

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.


> 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. The compiler instead should treat it as an error, when an 
unmanaged (object) reference is used with "const".

It's kidding when somebody requires that the compiler prevents him from 
inadvertently modifying an given value parameter. He who doesn't have 
enough coding discipline to care for such restrictions himself, will 
make more logical errors that no compiler can detect.

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.

</IMO>

DoDi