[fpc-devel] Const optimization is a serious bug

Alexander Klenin klenin at gmail.com
Sun Jul 10 06:34:05 CEST 2011


On Sun, Jul 10, 2011 at 04:45, Martin <fpc at mfriebe.de> wrote:
> On 09/07/2011 17:12, Chad Berchek wrote:
>>
>> Wow, thanks for the insults guys. I didn't realize I was so stupid.
>>
>> You missed my point too, BTW. According to the link given:
>>
>> "A constant argument is passed by reference if its size is larger than a
>> pointer."
>>
>> So you always know what the size of a pointer is? If I have this record:
>>
>> TMyRec = record
>>  I: Integer;
>> end;
>>
>> Is that passed by value or ref? Is someone compiling on 32-bit or 64? You
>> don't know, and neither does anyone. And that is my point about why having
>> it defined is important.
>
> Thanks for ignoring half of my mail. If it matters to write code depended on
> the rev/value question, use $IFDEF. I did point that out.
>
> You did ask, if it was defined: it is defined. Full stop. You do not like
> the way it is defined, <and I stop the sentence here, for i do not know how
> to finish it without insult>

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

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

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.
3) Slowly migrate existing code to either "constref" or "constval",
  use "const" for legacy/compatibility/extreme optimization cases.

-- 
Alexander S. Klenin



More information about the fpc-devel mailing list