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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
