[Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc

["veksler at il dot ibm dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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