Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

[Paul Schlie <schlie at comcast dot net>]

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