* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-4@http.gcc.gnu.org/bugzilla/>
@ 2012-02-29 12:41 ` marc.glisse at normalesup dot org
2012-02-29 13:41 ` gdr at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 23+ messages in thread
From: marc.glisse at normalesup dot org @ 2012-02-29 12:41 UTC (permalink / raw)
To: gcc-bugs
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)?
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-4@http.gcc.gnu.org/bugzilla/>
2012-02-29 12:41 ` [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc marc.glisse at normalesup dot org
@ 2012-02-29 13:41 ` gdr at gcc dot gnu.org
2012-04-29 9:26 ` paolo at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 23+ messages in thread
From: gdr at gcc dot gnu.org @ 2012-02-29 13:41 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-4@http.gcc.gnu.org/bugzilla/>
2012-02-29 12:41 ` [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc marc.glisse at normalesup dot org
2012-02-29 13:41 ` gdr at gcc dot gnu.org
@ 2012-04-29 9:26 ` paolo at gcc dot gnu.org
2012-05-05 1:13 ` glisse at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 23+ messages in thread
From: paolo at gcc dot gnu.org @ 2012-04-29 9:26 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2012-04-29 9:26 ` paolo at gcc dot gnu.org
@ 2012-05-05 1:13 ` glisse at gcc dot gnu.org
2023-06-01 9:37 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 23+ messages in thread
From: glisse at gcc dot gnu.org @ 2012-05-05 1:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2012-05-05 1:13 ` glisse at gcc dot gnu.org
@ 2023-06-01 9:37 ` redi at gcc dot gnu.org
2024-02-07 10:09 ` redi at gcc dot gnu.org
2024-02-07 11:46 ` pinskia at gcc dot gnu.org
6 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2023-06-01 9:37 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2023-06-01 9:37 ` redi at gcc dot gnu.org
@ 2024-02-07 10:09 ` redi at gcc dot gnu.org
2024-02-07 11:46 ` pinskia at gcc dot gnu.org
6 siblings, 0 replies; 23+ messages in thread
From: redi at gcc dot gnu.org @ 2024-02-07 10:09 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2024-02-07 10:09 ` redi at gcc dot gnu.org
@ 2024-02-07 11:46 ` pinskia at gcc dot gnu.org
6 siblings, 0 replies; 23+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-02-07 11:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-2544@http.gcc.gnu.org/bugzilla/>
@ 2010-02-18 22:03 ` paolo dot carlini at oracle dot com
2010-02-19 10:22 ` rguenth at gcc dot gnu dot org
` (14 subsequent siblings)
15 siblings, 0 replies; 23+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-02-18 22:03 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-2544@http.gcc.gnu.org/bugzilla/>
2010-02-18 22:03 ` paolo dot carlini at oracle dot com
@ 2010-02-19 10:22 ` rguenth at gcc dot gnu dot org
2010-02-19 10:30 ` paolo dot carlini at oracle dot com
` (13 subsequent siblings)
15 siblings, 0 replies; 23+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-02-19 10:22 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-2544@http.gcc.gnu.org/bugzilla/>
2010-02-18 22:03 ` paolo dot carlini at oracle dot com
2010-02-19 10:22 ` rguenth at gcc dot gnu dot org
@ 2010-02-19 10:30 ` paolo dot carlini at oracle dot com
2010-02-19 11:13 ` joseph at codesourcery dot com
` (12 subsequent siblings)
15 siblings, 0 replies; 23+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-02-19 10:30 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-2544@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2010-02-19 10:30 ` paolo dot carlini at oracle dot com
@ 2010-02-19 11:13 ` joseph at codesourcery dot com
2010-02-19 11:19 ` paolo dot carlini at oracle dot com
` (11 subsequent siblings)
15 siblings, 0 replies; 23+ messages in thread
From: joseph at codesourcery dot com @ 2010-02-19 11:13 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-2544@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2010-02-19 11:13 ` joseph at codesourcery dot com
@ 2010-02-19 11:19 ` paolo dot carlini at oracle dot com
2010-02-19 11:26 ` paolo dot carlini at oracle dot com
` (10 subsequent siblings)
15 siblings, 0 replies; 23+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-02-19 11:19 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-2544@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2010-02-19 11:19 ` paolo dot carlini at oracle dot com
@ 2010-02-19 11:26 ` paolo dot carlini at oracle dot com
2010-02-21 7:53 ` veksler at il dot ibm dot com
` (9 subsequent siblings)
15 siblings, 0 replies; 23+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-02-19 11:26 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-2544@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2010-02-19 11:26 ` paolo dot carlini at oracle dot com
@ 2010-02-21 7:53 ` veksler at il dot ibm dot com
2010-02-21 9:51 ` paolo dot carlini at oracle dot com
` (8 subsequent siblings)
15 siblings, 0 replies; 23+ messages in thread
From: veksler at il dot ibm dot com @ 2010-02-21 7:53 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-2544@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2010-02-21 7:53 ` veksler at il dot ibm dot com
@ 2010-02-21 9:51 ` paolo dot carlini at oracle dot com
2010-02-21 12:44 ` veksler at il dot ibm dot com
` (7 subsequent siblings)
15 siblings, 0 replies; 23+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-02-21 9:51 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-2544@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2010-02-21 9:51 ` paolo dot carlini at oracle dot com
@ 2010-02-21 12:44 ` veksler at il dot ibm dot com
2010-02-21 12:54 ` paolo dot carlini at oracle dot com
` (6 subsequent siblings)
15 siblings, 0 replies; 23+ messages in thread
From: veksler at il dot ibm dot com @ 2010-02-21 12:44 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-2544@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2010-02-21 12:44 ` veksler at il dot ibm dot com
@ 2010-02-21 12:54 ` paolo dot carlini at oracle dot com
2010-02-21 13:04 ` rguenth at gcc dot gnu dot org
` (5 subsequent siblings)
15 siblings, 0 replies; 23+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-02-21 12:54 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-2544@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2010-02-21 12:54 ` paolo dot carlini at oracle dot com
@ 2010-02-21 13:04 ` rguenth at gcc dot gnu dot org
2010-02-21 13:33 ` veksler at il dot ibm dot com
` (4 subsequent siblings)
15 siblings, 0 replies; 23+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2010-02-21 13:04 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-2544@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2010-02-21 13:04 ` rguenth at gcc dot gnu dot org
@ 2010-02-21 13:33 ` veksler at il dot ibm dot com
2010-02-21 13:37 ` rguenther at suse dot de
` (3 subsequent siblings)
15 siblings, 0 replies; 23+ messages in thread
From: veksler at il dot ibm dot com @ 2010-02-21 13:33 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-2544@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2010-02-21 13:33 ` veksler at il dot ibm dot com
@ 2010-02-21 13:37 ` rguenther at suse dot de
2010-02-21 18:04 ` gdr at integrable-solutions dot net
` (2 subsequent siblings)
15 siblings, 0 replies; 23+ messages in thread
From: rguenther at suse dot de @ 2010-02-21 13:37 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-2544@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2010-02-21 13:37 ` rguenther at suse dot de
@ 2010-02-21 18:04 ` gdr at integrable-solutions dot net
2010-02-21 18:20 ` veksler at il dot ibm dot com
2010-02-21 18:50 ` gdr at integrable-solutions dot net
15 siblings, 0 replies; 23+ messages in thread
From: gdr at integrable-solutions dot net @ 2010-02-21 18:04 UTC (permalink / raw)
To: gcc-bugs
[-- 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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-2544@http.gcc.gnu.org/bugzilla/>
` (13 preceding siblings ...)
2010-02-21 18:04 ` gdr at integrable-solutions dot net
@ 2010-02-21 18:20 ` veksler at il dot ibm dot com
2010-02-21 18:50 ` gdr at integrable-solutions dot net
15 siblings, 0 replies; 23+ messages in thread
From: veksler at il dot ibm dot com @ 2010-02-21 18:20 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug libstdc++/22200] numeric_limits<signed>::is_modulo is inconsistent with gcc
[not found] <bug-22200-2544@http.gcc.gnu.org/bugzilla/>
` (14 preceding siblings ...)
2010-02-21 18:20 ` veksler at il dot ibm dot com
@ 2010-02-21 18:50 ` gdr at integrable-solutions dot net
15 siblings, 0 replies; 23+ messages in thread
From: gdr at integrable-solutions dot net @ 2010-02-21 18:50 UTC (permalink / raw)
To: gcc-bugs
[-- 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
^ permalink raw reply [flat|nested] 23+ messages in thread