[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistent with gcc
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_limitssigned::is_modulo is inconsistent with gcc
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=gccview=revrev=186944 Log: 2012-04-29 Marc Glisse marc.gli...@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_limitssigned::is_modulo is inconsistent with gcc
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_limitssigned::is_modulo to false (setting it to true when -fwrapv is used can still be discussed afterwards)?
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistent with gcc
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_limitssigned::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_limitssigned::is_modulo is inconsistent with gcc
--- 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_limitssigned::is_modulo is inconsistent with gcc
--- 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_limitssigned::is_modulo is inconsistent with gcc
--- 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_limitssigned::is_modulo is inconsistent with gcc
--- 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_limitssigned::is_modulo is inconsistent with gcc
--- 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_limitssigned::is_modulo is inconsistent with gcc
--- Comment #36 from rguenther at suse dot de 2010-02-21 13:37 --- Subject: Re: numeric_limitssigned::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_limitssigned::is_modulo is inconsistent with gcc
--- Comment #37 from gdr at integrable-solutions dot net 2010-02-21 18:04 --- Subject: Re: numeric_limitssigned::is_modulo is inconsistent with gcc On Sun, Feb 21, 2010 at 7:04 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@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_limitssigned::is_modulo is inconsistent with gcc
--- 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_limitssigned::is_modulo is inconsistent with gcc
--- Comment #39 from gdr at integrable-solutions dot net 2010-02-21 18:50 --- Subject: Re: numeric_limitssigned::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
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistent with gcc
--- 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_limitssigned::is_modulo is inconsistent with gcc
--- 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_limitssigned::is_modulo is inconsistent with gcc
--- 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|-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_limitssigned::is_modulo is inconsistent with gcc
--- Comment #27 from joseph at codesourcery dot com 2010-02-19 11:13 --- Subject: Re: numeric_limitssigned::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_limitssigned::is_modulo is inconsistent with gcc
--- 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_limitssigned::is_modulo is inconsistent with gcc
--- 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_limitssigned::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_limitssigned::is_modulo is inconsistent with gcc
--- 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
