> Jim Blandy wrote: > On 1/2/06, Paul Schlie wrote: >> - at the most basic level, I feel like I've too often needlessly wasted >> time debugging programs at one level of optimization, to only see a >> different behavior needlessly expressed at a different level of >> optimization (which I understand means something isn't portable, but >> isn't the correct way to inform one of non-portable code, but is one >> hell of a way to unknowingly interject bugs into a program which didn't >> exist at a different level of optimization); however if a compiler >> supported the means by which a target could define the semantics left >> undefined by a language, an optimizing compiler could then both satisfy >> the formal constrains of language, while simultaneously enabling target >> specific semantics to be supported, and preserved through optimization. >> (which seems like a win-win to me) > > Okay, this makes sense to me now. If there were a switch that changed > the language from ISO C to a very similar language that actually > specified a fixed behavior for all the behaviors that ISO C says are > unspecified or undefined, then you'd have a language that might not be > possible to compile as efficiently in some cases, but in which every > program had a unique correct behavior. (Setting aside inherently > unpredictable things like threads and signals.) For example, the > language would actually have to specify some default value for all > variables, or require them to be assigned before their first use in a > way that the compiler could statically verify (as in Java). > > This is what the Java folks were shooting for, if you ignore the > non-determinism introduced by threads. Standard ML also specifies a > particular result for all programs. If my copies of both those specs > weren't still packed, I think I could actually find quotes from each > where they state being fully defined as a goal. So I think it's clear > there are a lot of people who think this is a worthwhile principle. > > Paul is combining this suggestion with the further idea that the > unspecified and undefined behaviors could be tied down in a way > comfortable for the particular target. I guess he's trying to reduce > the performance impact. That concession would allow the changes in > behavior that annoy him now when he switches optimization levels to > re-appear when one switches targets. The opposite extreme to Paul's > concession would be to eliminate all target-dependent characteristics > from the language, including type size differences and alignment > requirements, yielding a language which specified a unique correct > result for all programs (again, setting aside threads and signals) on > all targets. As ML and Java do. > Or, there could be a middle ground: you could specify some > characteristics (say, integral type sizes and wrap-around on overflow) > for all targets, but leave others (say, pointer size and alignment) > target-specific.
Yes.
