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

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

[marc.glisse at normalesup dot org]

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

Marc Glisse <marc.glisse at normalesup dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marc.glisse at normalesup
                   |                            |dot org

--- Comment #40 from Marc Glisse <marc.glisse at normalesup dot org> 2012-02-29 12:32:10 UTC ---
I haven't seen it mentioned in the discussion here, but in C++11, the
definition of is_modulo was clarified as:

"True if the type is modulo. A type is modulo if, for any operation involving
+, -, or * on values of that type whose result would fall outside the range
[min(),max()], the value returned differs from the true value by an integer
multiple of max() - min() + 1."

Do people have objections to switching numeric_limits<signed>::is_modulo to
false (setting it to true when -fwrapv is used can still be discussed
afterwards)?

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

[gdr at gcc dot gnu.org]

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

Gabriel Dos Reis <gdr at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr at gcc dot gnu.org

--- Comment #41 from Gabriel Dos Reis <gdr at gcc dot gnu.org> 2012-02-29 13:36:59 UTC ---
(In reply to comment #40)
> I haven't seen it mentioned in the discussion here, but in C++11, the
> definition of is_modulo was clarified as:
> 
> "True if the type is modulo. A type is modulo if, for any operation involving
> +, -, or * on values of that type whose result would fall outside the range
> [min(),max()], the value returned differs from the true value by an integer
> multiple of max() - min() + 1."
> 
> Do people have objections to switching numeric_limits<signed>::is_modulo to
> false (setting it to true when -fwrapv is used can still be discussed
> afterwards)?


I agree with this.  Thanks, Marc.

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

[paolo at gcc dot gnu.org]

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

--- Comment #42 from paolo at gcc dot gnu.org <paolo at gcc dot gnu.org> 2012-04-29 09:25:24 UTC ---
Author: paolo
Date: Sun Apr 29 09:25:17 2012
New Revision: 186944

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186944
Log:
2012-04-29  Marc Glisse  <marc.glisse@inria.fr>

    PR libstdc++/22200
        * include/std/limits (numeric_limits<>::is_modulo): False for
        signed types.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/std/limits

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

[glisse at gcc dot gnu.org]

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

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glisse at gcc dot gnu.org

--- Comment #43 from Marc Glisse <glisse at gcc dot gnu.org> 2012-05-05 01:11:47 UTC ---
(In reply to comment #25)
> It would probably be useful to add a preprocessor macro when -fwrapv is
> in effect.

What would be the preferred form, macros __GCC_WRAPV, __GCC_TRAPV,
__GCC_STRICT_OVERFLOW, etc, defined only when the matching flag is passed? Or
maybe a macro __GCC_INTEGER_OVERFLOW that is 0 for undefined, 1 for wrapping, 2
for trapping, etc?

Maybe I should file this as a different PR? adding the macros doesn't mean we
have to use them in is_modulo. By the way, for is_modulo, we could probably
arrange so that the values don't have to be in libstdc++.so, if that helps.

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #44 from Jonathan Wakely <redi at gcc dot gnu.org> ---
If I'm reading the history correctly, there's nothing else for libstdc++ to do
here. If the compiler starts to define a macro for -fwrapv then we could use it
in the library, but that hasn't happened in over a decade with this bug open.

Should we close it or reassign it to a different component?

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.0
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

--- Comment #45 from Jonathan Wakely <redi at gcc dot gnu.org> ---
https://cplusplus.github.io/LWG/issue2422 changed the spec for is_modulo to
remove the "on most machines" text and add:

  -??- [Example: is_modulo is false for signed integer types
([basic.fundamental])
  unless an implementation, as an extension to this International Standard,
defines signed
  integer overflow to wrap. — end example]

This seems very clear that numeric_limits<int>::is_modulo should be false
*unless* -fwrapv is used. I'm going to close this now. If GCC gets a macro that
allows us to detect the presence of -fwrapv we can revisit it.

N.B. Since C++17 is_modulo is an inline variable and so no extern definition in
libstdc++.so is needed. If we made it depend on -fwrapv then you would still
get ODR violations between different translation units compiled with different
-fwrapv states, but at least you wouldn't get a value from libstdc++.so that
ignores the current TU.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #46 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #45)
> 
> This seems very clear that numeric_limits<int>::is_modulo should be false
> *unless* -fwrapv is used. I'm going to close this now. If GCC gets a macro
> that allows us to detect the presence of -fwrapv we can revisit it.

One thing that should be noted is that fwrapv setting could be even per
function so I suspect it is more complex than that.

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

[gdr at integrable-solutions dot net]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2047 bytes --]



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

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

[veksler at il dot ibm dot com]

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

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

[gdr at integrable-solutions dot net]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]



------- Comment #37 from gdr at integrable-solutions dot net  2010-02-21 18:04 -------
Subject: Re:  numeric_limits<signed>::is_modulo is 
        inconsistent with gcc

On Sun, Feb 21, 2010 at 7:04 AM, rguenth at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:

> Or suspend it.  I think this warrants a defect report anyway since I think
> is_modulo was intended to describe CPU behavior as otherwise defining
> signed integer overflow as undefined in one piece of the standard and
> then requiring a sane answer for is_modulo in another part sounds
> like a conflict of interest.

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.


-- 


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

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

[rguenther at suse dot de]

------- Comment #36 from rguenther at suse dot de  2010-02-21 13:37 -------
Subject: Re:  numeric_limits<signed>::is_modulo is
 inconsistent with gcc

On Sun, 21 Feb 2010, veksler at il dot ibm dot com wrote:

> > Or suspend it.  I think this warrants a defect report anyway since I think
> > is_modulo was intended to describe CPU behavior as otherwise defining
> > signed integer overflow as undefined in one piece of the standard and
> > then requiring a sane answer for is_modulo in another part sounds
> > like a conflict of interest.
> > 
> Maybe it is better to make things clear, but I am not so sure of the 
> outcome. I think that is_modulo is meaningful only if it is true, otherwise,
> when false user's code can't rely on any specific behavior. 
> Maybe is_modulo=false is the right answer even for -fwrapv after all.

Or maybe is_modulo=true has only practical meaning for code that
doesn't invoke undefined behavior anyway (like adding two
signed integers when the operation will overflow).  That also
avoids the /-1 and %-1 issues.

It really depends on how is_modulo was supposed to be used.

Richard.


-- 


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

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

[veksler at il dot ibm dot com]

------- Comment #35 from veksler at il dot ibm dot com  2010-02-21 13:33 -------
(In reply to comment #34)
> (In reply to comment #33)
> > (In reply to comment #32)
> > > 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.
> > 
> > It would be closed immediately as WONTFIX, to be clear. There is nothing we can
> > do in the foreseeable future, it's **everywhere** and totally unfixable without
> > breaking ABI and much more than that.

Yes, it is a big task which is probably not worth it, but is it unfixable?
Is it possible that these ODR violations will ever be translated to security
issues? For example, the data structure is updated in one translation 
unit in a way that causes memory corruption when accessed by a different
definition in a different translation unit? This is all theoretic but
as history has shown, theoretic security threats become real - eventually.

> > I see that I'm not going to work on it. Actually, I'll wait one month or so,
> > and then if I will not get at least one concrete proposal, I will close this
> > one as WONTFIX.
> 
> Or suspend it.  I think this warrants a defect report anyway since I think
> is_modulo was intended to describe CPU behavior as otherwise defining
> signed integer overflow as undefined in one piece of the standard and
> then requiring a sane answer for is_modulo in another part sounds
> like a conflict of interest.
> 
Maybe it is better to make things clear, but I am not so sure of the 
outcome. I think that is_modulo is meaningful only if it is true, otherwise,
when false user's code can't rely on any specific behavior. 
Maybe is_modulo=false is the right answer even for -fwrapv after all.


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #34 from rguenth at gcc dot gnu dot org  2010-02-21 13:04 -------
(In reply to comment #33)
> (In reply to comment #32)
> > 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.
> 
> It would be closed immediately as WONTFIX, to be clear. There is nothing we can
> do in the foreseeable future, it's **everywhere** and totally unfixable without
> breaking ABI and much more than that.
> 
> > 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...
> 
> I see that I'm not going to work on it. Actually, I'll wait one month or so,
> and then if I will not get at least one concrete proposal, I will close this
> one as WONTFIX.

Or suspend it.  I think this warrants a defect report anyway since I think
is_modulo was intended to describe CPU behavior as otherwise defining
signed integer overflow as undefined in one piece of the standard and
then requiring a sane answer for is_modulo in another part sounds
like a conflict of interest.


-- 


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

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

[paolo dot carlini at oracle dot com]

------- Comment #33 from paolo dot carlini at oracle dot com  2010-02-21 12:53 -------
(In reply to comment #32)
> 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.

It would be closed immediately as WONTFIX, to be clear. There is nothing we can
do in the foreseeable future, it's **everywhere** and totally unfixable without
breaking ABI and much more than that.

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

I see that I'm not going to work on it. Actually, I'll wait one month or so,
and then if I will not get at least one concrete proposal, I will close this
one as WONTFIX.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
                   |dot com                     |dot org
             Status|ASSIGNED                    |NEW


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

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

[veksler at il dot ibm dot com]

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

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

[paolo dot carlini at oracle dot com]

------- Comment #31 from paolo dot carlini at oracle dot com  2010-02-21 09:51 -------
(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 ...


-- 


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

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

[veksler at il dot ibm dot com]

------- Comment #30 from veksler at il dot ibm dot com  2010-02-21 07:52 -------
(In reply to comment #25)
> It would probably be useful to add a preprocessor macro when -fwrapv is
> in effect.
> 
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.


-- 


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

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

[paolo dot carlini at oracle dot com]

------- Comment #29 from paolo dot carlini at oracle dot com  2010-02-19 11:26 -------
So, if I understand correctly the dependencies, I think we should mark this as
blocked by 30484: when -fwrapv makes INT_MIN / -1 and INT_MIN % -1 have modulo
semantics we can conditionalize numeric_limits<signed>::is_modulo on the new
pre-processor macro.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |30484


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

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

[paolo dot carlini at oracle dot com]

------- Comment #28 from paolo dot carlini at oracle dot com  2010-02-19 11:18 -------
Thanks Joseph. Indeed, I remember well when my friend Roberto opened that
issue, but didn't expect it was still open ;)


-- 


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

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

[joseph at codesourcery dot com]

------- Comment #27 from joseph at codesourcery dot com  2010-02-19 11:13 -------
Subject: Re:  numeric_limits<signed>::is_modulo is
 inconsistent with gcc

The issue with -fwrapv not making INT_MIN / -1 and INT_MIN % -1 have 
modulo semantics is discussed in bug 30484.


-- 


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

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

[paolo dot carlini at oracle dot com]

------- Comment #26 from paolo dot carlini at oracle dot com  2010-02-19 10:30 -------
Ah, thanks, that pre-processor macro idea looks very nice to me. Let's see what
people think, and in case, I'll take  care of that as soon as 4.5 branches.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr at integrable-solutions
                   |                            |dot net
         AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
                   |dot org                     |dot com
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-02-19 10:30:40
               date|                            |


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #25 from rguenth at gcc dot gnu dot org  2010-02-19 10:22 -------
(In reply to comment #24)
> Richard, can you comment on this issue? Do you think it's currently correct to
> have numeric_limits<>:is_modulo == true for all our signed integral types? We
> are not making any progress on this issue :(

Well, it's certainly not 100% correct to claim signed ints have modulo
semantics.
I don't know if it is helpful to say numeric_limits<>:is_modulo == false to
our users.

It would probably be useful to add a preprocessor macro when -fwrapv is
in effect.


-- 


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

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

[paolo dot carlini at oracle dot com]

------- Comment #24 from paolo dot carlini at oracle dot com  2010-02-18 22:03 -------
Richard, can you comment on this issue? Do you think it's currently correct to
have numeric_limits<>:is_modulo == true for all our signed integral types? We
are not making any progress on this issue :(


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


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