[fpc-devel] Const optimization is a serious bug

Marco van de Voort marcov at stack.nl
Sun Jul 10 12:33:50 CEST 2011


In our previous episode, Alexander Klenin said:
> 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,

This sentence is the main problem. If you define "working" as any code that
happens to run must remain working, you are moving away from building a
compiler, and starting to build an emulator.

A compiler produces a defined output for a defined input. But the input is
defined as adhering to the language rules.

An emulator produces a defined output for a set of inputs (existing
programs). The input is defined as is.

Of course in a project the size of FPC not every corner case is documented
to the last detail, so the rules are made up as we go. And of course the
frequency of the problem has a say in it too.

To be honest, I'm a bit surprised by the progression of this discussion. I
sympathise a bit with the proponents of a simple "disable this optimization"
switch, but to me the rest all sounds like people desperately defending
their turf, and losing sight of the big picture.

Specially since I already discussed this issue a bit with Martin before the
email discussion began.

The main argumentation for this switch for me is that in many cases
programmers don't have complete control of the codebase (yet).  Parts are
inherited from previous employees, taken of the net or simply bought.

In such cases remarks like "you shouldn't this" are totally useless since
you inherited a mountain of code, which will take years to comb through.

If you then have strange crashes, a simple recompile with such switch might
give you some information if such problem is happening, or not, somewhere
deep in your framework.

Just like you compile once with -gtt with -gh, run it through valgrind etc
etc.

I think the finegrained detection option that Martin proposes has a bad
work vs occuarance tradeoff, but a global killswitch for this might be
enough.




More information about the fpc-devel mailing list