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

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

------- Comment #32 from veksler at il dot ibm dot com  2010-02-21 12:44 -------
(In reply to comment #31)
> (In reply to comment #30)
> > Wouldn't it be a violation of the one definition rule (ODR), 
> > when one translation unit is compiled with -fwrapv and another without?
> > In that case this would be a regression.
> 
> I don't know if this comes as a surprise to you, but in the library we have
> *tons* of potential violations of this type, due to command line switches, not
> just the big cases like debug-mode, but also rtti, exceptions, etc. That said,
> if people prefer a false value, always, just tell me and let's close this PR
> because I don't think the compiler is going to change any time soon to warrant
> a true value irrespective of any command line option ...

If this hazard is so prevalent shouldn't it deserve a separate PR?
If a method or function depend on a flag or macro then it can be handled
by overloading and specialization without ODR violation.

When this hazard is, like in this case, appears in a constant then things
are more difficult. An unexpected behavior may be observed when is_modulo
is passed by reference, and I don't see what can be done in this case,
not in 100% of the scenarios. Even if GCC annotates the two different 
variants of is_modulo differently, such that there will be two different
physical allocations of is_modulo, it will still be possible to get to
some misbehavior in weird cases. Oh well...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200