------- Comment #39 from gdr at integrable-solutions dot net 2010-02-21 18:50
-------
Subject: Re: numeric_limits<signed>::is_modulo is
inconsistent with gcc
On Sun, Feb 21, 2010 at 12:20 PM, veksler at il dot ibm dot com
<gcc-bugzi...@gcc.gnu.org> wrote:
> ------- 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.
Agreed.
>
> So if -fwrapv affects the definition of is_modulo then:
>
so the issue then is that you get two people who make incompatible
assumptions about the same type for the same program. If that is
case, I'm not sure what libstdc++ would have to do. After all, the resulting
program is out of the control of libstdc++.
> If libstdc++.so is compiled without -fwrapv, then the user can't
> use -fwrapv without a potential ODR violation.
agreed.
> 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.
agreed.
> 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.
my conclusion would be that is_modulo is not the right interface to
test whether a component in the program was compiled with -fwrapv.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
