On 31-Jul-18 13:46, Paul Koning wrote: > No, but thanks for that pointer. The paper I was thinking about is > listed in the references: > Xi Wang, Haogang Chen, Alvin Cheung, Zhihao Jia, Nickolai Zeldovich, and M. > Frans Kaashoek. 2012a. Undefined behavior: What happened to my code? In > Proceedings of the 3rd Asia-Pacific Workshop on Systems. https://people.csail.mit.edu/nickolai/papers/wang-undef-2012-08-21.pdf
Seems to be a rehash of some well-known stuff - that was pretty well known even in 2012. In additions to -Wall, I also used to compile SimH with -pedantic and -Werror. And usually one of the -std flags. > Hm, -pedantic is specificially intended to be "the warnings that aren't > really useful for general use and real code". But I often found that if I tripped one, my mind was wandering and something else was likely not quite right :-) >> Another big potential gotcha in SimH is the heavy use of casts, and type >> aliasing rules (the latter especially problematic in subroutine calls). > Yes, aliasing is a big problem area. If you get any warnings about strict > aliasing, fixing them (via unions) is a good idea. Alternatively, > fno-strict-aliasing can be used but that comes with a performance cost and is > not the best answer. > I'm of the school that says "fix, don't disable". Especially if you want your code to work with more than one compiler. But it can be painful with legacy code. I also recommend "C is not a low-level language <https://queue.acm.org/detail.cfm?id=3212479>" in the July issue of CACM. It makes some useful points that apply here.
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
