------- Comment #38 from veksler at il dot ibm dot com 2010-02-21 18:20 ------- (In reply to comment #37)
> is_modulo is intended to describe the implementation's choice, not necessarily > the CPU behaviour (which the implementation may choose to mask or not.) > > The issue here is that GCC does not always deliver the CPU behaviour, so it > is more a problem with GCC than with the standard. > > Users who want to make incompatible assumptions about types in the same > program > deserve what they get. > This is not that simple. libstdc++.so is out of user's control, libkde.so (or whatever its name is) is out of user's control. So if -fwrapv affects the definition of is_modulo then: If libstdc++.so is compiled without -fwrapv, then the user can't use -fwrapv without a potential ODR violation. What if libkde.so, which is supplied by a third party, was compiled with -fwrapv, while libsdc++.so was compiled by some sysadmin, accessible through NFS. They must be compiled with exactly the same flags, both out of user's control, otherwise they'll cause an ODR violation. Having is_modulo lie looks not as bad as it initially seemed. At least I have the option to ignore is_modulo altogether without going to the land of undefined behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200