[fpc-devel] Const optimization is a serious bug

[Hans-Peter Diettrich]

Alexander Klenin schrieb:

>>> 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.

The whole sentence applies to the byval/byref modification, nothing is 
said about the cases where references are passed even without const. In 
this case I agree that aliasing can change the semantics.


>>> 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?

To which data type do you want apply your "constval" modifier, with 
which concrete effects?


>> 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".

 From the user VP both affect code generation only. Both can be broken 
by by aliasing.

DoDi