> From: Mike Stump wrote: > On Dec 31, 2005, at 10:51 AM, Paul Schlie wrote: >> As although C/C++ define some expressions as having undefined >> semantics; > > I'd rather it be called --do-what-i-mean. :-) > > Could you give us a hint at what all the semantics you would want to > change with this option? Are their any code bases that you're trying > to compile? Compilers that you're trying to be compatible with?
Yes, although I'd like to think of it as being: --do-what-i-said-given-the-semantics-specified-for-the-target More specifically for example: - enable the specification of a null-pointer value, and negative integer pointer conversions. (i.e. what does (int *)-2 + (int *)0 mean?) Thereby enabling a target which may concurrently map their registers to low-order addresses and be able define NULL as being some value other than 0. - enable the specification of null-pointer and generalized ordered pointer comparison semantics. (i.e. what does *a <= *b | *c >= (int *)0 mean?) Thereby being able to dereference 0 as possibly being r0 without presuming code execution is halted or have to resort to assembler; and/or determine if an address is within the range of some memory region bounds without having to explicitly cast pointers to integers, which may not be the right thing to do for targets which support differently sized pointers and integers, or who's pointers may have different arithmetic semantics than integers do, etc. etc. - enable the specification of arithmetic pointer and integer overflow semantics, not limited to invoking an undefined or modulo results, as being able to support saturating integer arithmetic optimization seems increasingly attractive as signal processing becomes more pervasive. - enable the specification of the result/behavior of a shift greater than the width of a operand, for same reasons as above. Etc. Etc. I believe all of these issues have been raised through the years by many, and typically dismissed as not being defined by the language standards, therefore GCC may do as it sees fit; which although true, misses the point that occasionally it's often more important and/or desirable to preserve behavior (although it may not be portable) during optimization, than risk unexpected behaviors which may result from optimizations presuming and/or relying on otherwise.
