On 31-Jul-18 12:41, Paul Koning wrote: > > > One thing that happens with newer compilers is that they take more advantage > of opportunities offered by the letter of the standard. If you do something > that is "undefined", the compiler can do with that whatever it wants to. If > you have code that appears to allow something undefined under certain > conditions, the compiler is free to assume that the undefined thing cannot > happen and therefore that scenario doesn't occur. > > For example: > extern int foo[100]; > > if (i < 0) > a += foo[i]; > > The compiler is allowed to delete that code because subscripting an array > with a negative number is undefined. And modern compilers often will. > > There is an excellent paper, I think from MIT, about many undefined things in > C that are not all that well understood by many programmers. Unfortunately > I've misplaced the reference. It mentions that Linux turns off a whole pile > of gcc optimizations by specific magic flags to avoid breaking things due to > undefined things it does in the existing code base. > > For integer arithmetic, what you mentioned is a key point. Unsigned is > defined to have wraparound semantics. With signed integers, overflow is > "undefined". So, for example, if you want to emulate the PDP11 arithmetic > operations, you have to use unsigned short (uint16_t). Using signed short > (int16_t) is incorrect because of the overflow rules. > > More generally, in SIMH you probably want the rule that every integer > variable is unsigned. Or at least, make every variable unsigned unless you > know there is a good reason why it needs to be signed, and no undefined > behavior is possible for that particular variable. > > If you compile (in gcc) with -Wall and get no warnings, that's a pretty good > sign. If you do get warnings, they almost certainly need to be fixed rather > than disabled. >
You probably mean https://people.csail.mit.edu/nickolai/papers/wang-stack-tocs.pdf For more reading, see, e.g. http://port70.net/~nsz/c/c99/n1256.html#J.2 <http://port70.net/%7Ensz/c/c99/n1256.html#J.2>, https://cacm.acm.org/magazines/2016/3/198849-a-differential-approach-to-undefined-behavior-detection/fulltext, https://blog.regehr.org/archives/1520, https://runtimeverification.com/blog/undefined-behavior-review-and-rv-match/ The last is a competitive analysis - but quite informative nonetheless. In additions to -Wall, I also used to compile SimH with -pedantic and -Werror. And usually one of the -std flags. Another big potential gotcha in SimH is the heavy use of casts, and type aliasing rules (the latter especially problematic in subroutine calls).
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
