[fpc-devel] Const optimization is a serious bug

[Martin]

On 10/07/2011 05:34, Alexander Klenin wrote:
>
> 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.
Jonas himself pointed out that this documentation is at least misleading.

Anyway: I have at no point said or implied (or at lest have I not mean 
to do so) that the documentation was perfect. In fact, I do thing the 
documentation has severe shortcomings.

Anyway, so far I have talked about the feature. The feature is correctly 
implemented (if the defintition is known).

> 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.
I guess an inline can make a program crash. I the inlined procedure 
contains code trying to access it's own stack frame, and being inlined 
actually access the stackframe of the would-be-caller...
I am not going to try to prove this, but I guess with enough 
determination it can be done.

Anyway, as we well know by now "const" is more than that, hence it can 
not be compared with inline.

...and never mind any issues with the documentation of it. If the docs 
are wrong, then correct them, but do not blame the feature as bad, 
because the docs are bad...

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

No argument with that. As I pointed out, the correctness (or 
incorrectness)  were never my point

> On the more constructive note, I have yet another proposal:
> 1) Leave current "const" implementation broken as-is.
<sarcasm>
You made a typo:
1) Leave current "const" implementation WORKING as-is.
;-p  SCNR
</sarcasm>

> 2) Introduce new "constval" modifier which is similar to "const",
>    but guarantees correct "by-value" semantics.
no problem with that.

> 3) Slowly migrate existing code to either "constref" or "constval",
>    use "const" for legacy/compatibility/extreme optimization cases.
Maybe...

BUT: I have actually used "const" in some places with exactly the intend 
to have it doing what it does.
I have used const with the very intention of the ref-count not being 
increased, and by this with the effect of the implicit exception frame 
not being needed.

Given that, I would not migrate that code to anything else.

BTW: when I first did that, I made the very mistake of doing it wrong 
myself too. I learned, I corrected my code, I started using it as it is 
meant to..

Best Regards
Martin