James Dennett wrote:
I don't know how much work it would be to disable this optimization in gcc.
To me, it is always troublesome to talk of "disable this optimization" in a context like this. The program in question is not C, and its semantics cannot be determined from the C standard. If the appropriate gcc switch to "disable" the optimization is set, then the status of the program does not change, it is still undefined nonsense. Yes, it may happen to "work" for some definition of "work" that is in your mind, but is not defined or guaranteed by any coherent language definition. It seems worrisome to be operating under such circumstances, so surely the best advice in a situation like this is to fix the program. Yes, you may be in a situation with legacy code where that is not practical, but it is important to be aware of the precarious situation that you leave yourself in if you take the road of working with a C compiler and a program not written in C! This general point of course is not language specific, you can substitute any language for C in the above including Ada. Interestingly, my viewpoint on this from the compiler domain might seem to be quite inconsistent. I think it is generally a bad idea for compilers to aggressively optimize based on assumptions that programs are free of these kinds of mistakes. I would only be in favor of such an optimization if you can really show convincingly that it really makes a difference to performance. In these days when 10% performance gain corresponds to a month or two progress in hardware, it is not so easy to make such convincing arguments. And I am all in favor of options that disable such agressiveness and indeed I prefer the non-aggressive mode to be the default. In the Ada/GNAT world I have argued for some time that we should make -fno-strict-aliasing the default, but we have seen programs where this can make a noticeable difference in time and more importantly space, so I have lost this argument so far (you can see what the GNAT documentation has to say about -fno-strict-aliasing if you search for this phrase). But even though I think compilers should generaly be tolerant of junk code with incorrect expectations, I prefer a rather intolerant attitude to programmers who produce the junk code in the first place, since this kind of non-portable incorrect coding is the source of *so* much trouble in code reuse and porting, even when the porting is from one version of a compiler to another. One of the first responsibilities of any programmer programming in a given language X is to understand the semantics of language X, not just to know what works on the target they happen to be using. Robert Dewar
