[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 15:21 --- INT_MAX/-1 is undefined. and signed overflow is undefined. Why file this bug when the comments on the list say this is not a bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27 15:33 --- This is a bug because std::numeric_limitssigned::is_modulo should be true only if singed overflow is defined. This is not the case with gcc, because gcc does not have the extension signed oveflow == module then is_modulo should not lie. The undefinedness referse to MAX_INT+1 not to is_modulo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 15:40 --- I think we need to read: ISO/IEC 10967-1 Language Independent Arithmetic, part 1 since that is what the standard references for is_modulo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at integrable-solutions dot net 2005-06-27 16:06 --- Subject: Re: numeric_limitssigned::is_modulo is inconsistend with gcc pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | INT_MAX/-1 is undefined. | and signed overflow is undefined. | | Why file this bug when the comments on the list say this is not a bug? Maybe the real question is why you feel you must send your message. Please do consider the issue as raised on the main list and the discussion there. The point is we must say something about numerci_limits, and this consistently with the behaviour of GCC. This probably is not an issue for C, but it is for C++. For all useful purposes, do remember that GCC used to define is_modulo as false for signed integer types. It was consciously changed to true by RTH. See the reference I gave. Now, if you do not understand the issue, please refrain from sending unhelpful messages. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 16:07 --- Actually it is modulo for all operations. and INT_MAX/-1 does not raise a trap. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at integrable-solutions dot net 2005-06-27 16:09 --- Subject: Re: numeric_limitssigned::is_modulo is inconsistend with gcc pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | I think we need to read: | ISO/IEC 10967-1 Language Independent Arithmetic, part 1 since that | is what the standard references for is_modulo. yes, as pointed out in the message I sent. It was pointed out that the loop optimizers was making some assumtpions. If the only is only for the loop optimizers, then we can also consider the option of explicitly allowing specific behaviour for induction variables. At any rate, a proper resolution for this PR is hardly the standard says it is undefined behaviour. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at gcc dot gnu dot org 2005-06-27 16:21 --- (In reply to comment #1) INT_MAX/-1 is undefined. and signed overflow is undefined. Why file this bug when the comments on the list say this is not a bug? (In reply to comment #5) Actually it is modulo for all operations. and INT_MAX/-1 does not raise a trap. Andrew -- You do not seem to understand this PR. Please DO NOT close it. Your eagerness to close PRs is doing harms -- that was already debated last couple o weeks and I do not want to repeat that again. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
Re: [Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Actually it is modulo for all operations. But then do read the comment as far as the loop optimizer is concerned. It does not seem like it understands that it is modulo arithmetic. | and INT_MAX/-1 does not raise a trap. It that is the case, then it is one issue less. But that wasn't the purpose of this PR. The issue is far from resolved just because you assert that INT_MAX/-1 does not trap. -- Gaby
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at integrable-solutions dot net 2005-06-27 16:25 --- Subject: Re: numeric_limitssigned::is_modulo is inconsistend with gcc pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Actually it is modulo for all operations. But then do read the comment as far as the loop optimizer is concerned. It does not seem like it understands that it is modulo arithmetic. | and INT_MAX/-1 does not raise a trap. It that is the case, then it is one issue less. But that wasn't the purpose of this PR. The issue is far from resolved just because you assert that INT_MAX/-1 does not trap. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-27 16:32 --- (In reply to comment #1) Why file this bug when the comments on the list say this is not a bug? It's for the potentially long debate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27 16:35 --- In Comment #5 Andrew Pinski writes: Actually it is modulo for all operations. and INT_MAX/-1 does not raise a trap. That was a typo on my part. It was supposed to be INT_MIN/-1 INT_MAX/-1 does not require modulo because in 2's complement INT_MIN==-INT_MAX-1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
Re: [Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
On Jun 27, 2005, at 12:25 PM, gdr at integrable-solutions dot net wrote: | Actually it is modulo for all operations. But then do read the comment as far as the loop optimizer is concerned. It does not seem like it understands that it is modulo arithmetic. But that is because overflow is undefined, read what other people have written. It is modulo for all normal operations but it is still undefined at what the output will be. -- Pinski
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From pinskia at physics dot uc dot edu 2005-06-27 16:53 --- Subject: Re: numeric_limitssigned::is_modulo is inconsistend with gcc On Jun 27, 2005, at 12:25 PM, gdr at integrable-solutions dot net wrote: | Actually it is modulo for all operations. But then do read the comment as far as the loop optimizer is concerned. It does not seem like it understands that it is modulo arithmetic. But that is because overflow is undefined, read what other people have written. It is modulo for all normal operations but it is still undefined at what the output will be. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 17:29 --- (In reply to comment #7) Andrew -- You do not seem to understand this PR. Please DO NOT close it. Your eagerness to close PRs is doing harms -- that was already debated last couple o weeks and I do not want to repeat that again. yes it will be debated until the end of time. INT_MIN/-1 is undefined as declared by the C/C++ standards so this is invalid. we get modulo results most of the time, but again since this is undefined, we may as well say it is modulo because it is. I think the standard say that if two postive values are added to and you __may__ get a value that is less than both of them, then is_modulo should be set to true. (I don't have the copy right in front of me right now but IIRC that is what it says) In fact from the comment in std_limits.h says if possible meaning may: /** True if the type is @e modulo, that is, if it is possible to add two positive numbers and have a result that wraps around to a third number that is less. Typically false for floating types, true for unsigned integers, and true for signed integers. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 17:34 --- Invalid as the C++ standard says: True if the type is modulo.203) A type is modulo if it is possible to add two positive numbers and have a result that wraps around to a third number that is less. Generally, this is false for floating types, true for unsigned integers, and true for signed integers on it says if possible which means not always but some of the time. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From schlie at comcast dot net 2005-06-27 18:00 --- (In reply to comment #13) Invalid as the C++ standard says: True if the type is modulo.203) A type is modulo if it is possible to add two positive numbers and have a result that wraps around to a third number that is less. Generally, this is false for floating types, true for unsigned integers, and true for signed integers on it says if possible which means not always but some of the time. It's only possible because the sum of two positive numbers may not exceed that type's MAX value; not because if a type is modulo it may not produce a modulo result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at integrable-solutions dot net 2005-06-27 18:19 --- Subject: Re: numeric_limitssigned::is_modulo is inconsistend with gcc pinskia at physics dot uc dot edu [EMAIL PROTECTED] writes: | Subject: Re: numeric_limitssigned::is_modulo is inconsistend with gcc | | | On Jun 27, 2005, at 12:25 PM, gdr at integrable-solutions dot net wrote: | | | Actually it is modulo for all operations. | | But then do read the comment as far as the loop optimizer is | concerned. It does not seem like it understands that it is modulo | arithmetic. | | But that is because overflow is undefined, read what other people | have written. I read what other people say. But you do not seem to understand what is_modulo means, even when you point to the LIA-1 part. Please, do consider the semantics described there and the quote I provided. Basically, you can decide that it overflows and send a notification of overlfow but wrap with defined meaning. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at integrable-solutions dot net 2005-06-27 18:23 --- Subject: Re: numeric_limitssigned::is_modulo is inconsistend with gcc pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 17:29 --- | (In reply to comment #7) | Andrew -- | | You do not seem to understand this PR. Please DO NOT close it. | Your eagerness to close PRs is doing harms -- that was already debated | last couple o weeks and I do not want to repeat that again. | | yes it will be debated until the end of time. INT_MIN/-1 is undefined as declared by the C/C++ | standards so this is invalid. we get modulo results most of the time, but again since this is undefined, The issue is whether that modulo result is taken to be the definition that GCC gives to the operation. At this point, saying the standard says it is undefined behaviour is pointless and unhelpful. | we may as well say it is modulo because it is. Yes, that is part of the issue. | I think the standard say that if two postive values are | added to and you __may__ get a value that is less than both of them, yes, but at this point we're more interesting in what GCC decides that behaviour should be. It is irrelevant to say the standard says it is undefined behaviour. | then is_modulo should be set to true. (I don't have the copy right in front of me right now but IIRC that is what it says) | | | In fact from the comment in std_limits.h says if possible meaning may: | /** True if the type is @e modulo, that is, if it is possible to add two | positive numbers and have a result that wraps around to a third number | that is less. Typically false for floating types, true for unsigned | integers, and true for signed integers. */ Thanks, I'm the author of limits. For all useful purposes, please Andrew go back and read the link I gave to RTH's message. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at gcc dot gnu dot org 2005-06-27 18:25 --- Andrew is being silly. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at integrable-solutions dot net 2005-06-27 18:27 --- Subject: Re: numeric_limitssigned::is_modulo is inconsistend with gcc pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 17:34 --- | Invalid as the C++ standard says: Andrew -- Stop this unhelpful behaviour. If you don't understand the issue, refrain from closing it. There is a consistency problem between numeric_limimts::is_modulo and GCC's optimizations assumptions. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 18:34 --- (In reply to comment #16) Thanks, I'm the author of limits. For all useful purposes, please Andrew go back and read the link I gave to RTH's message. Yes and RTH's comment about trapping is wrong, because PPC does not trap at all. See PR 22203 for that bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From gdr at integrable-solutions dot net 2005-06-27 18:46 --- Subject: Re: numeric_limitssigned::is_modulo is inconsistend with gcc pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 18:34 --- | (In reply to comment #16) | Thanks, I'm the author of limits. For all useful purposes, please | Andrew go back and read the link I gave to RTH's message. | | Yes and RTH's comment about trapping is wrong, because PPC does not trap at all. See PR 22203 for | that bug. You seem to confuse all issues. Please be careful in trying issues. The fact that you assert that integers don't trap does not make RTH's comment wrong. Furtheremore, are you claiming that 1 / 0 does not trap on PPC? (I do not have a PPC to check). If that is true, you're welcoome to submit a patch to rectify the value for PPC. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27
20:28 ---
(In reply to comment #13)
Invalid as the C++ standard says:
True if the type is modulo.203) A type is modulo if it is possible to add
two positive numbers and
have a result that wraps around to a third number that is less. Generally,
this is false for floating types,
true for unsigned integers, and true for signed integers on
it says if possible which means not always but some of the time.
It seems to me you are being subtly inconsistent.
Correct me if I misread your comments:
1. signed overflow is undefined
[letting the compiler do whatever it likes.
In that case the compiler may decide, among other things, to trap,
saturate or modulo].
2. It is OK for a compiler to set is_modulo because as it is undefined,
modulo result may be recieved from the random junk that undefined
produces. And to prove your point you refer to ...it is possible to
add two positive numbers and have a result that wraps around..
The logic of 2. works both ways. Any logical conclusion will be
valid in the presense of undefined. I can say that since limits
does not know exactly what gcc does or does not do, it wll *may*
be possible that the undefined behavior always leads to MAX_INT.
So, if we want to have a reasonable meaning for the sentance
...it is possible to add ..., it should be read as
...it is possible to choose such values that when added
Reading any other way does not make sense, especially if you put
the nondeterministic undefined into the mix.
This requires a DR to get a formal clarification, for people with
Andrew's point of view, and avoid future confusion.
Andrew: Don't you think that all this noise indicates that this is
not a clear cut case? When there is a dispute, aren't we choose
the most pragmatic and useful point of view (until a formal clarification
is given)? Don't you agree that:
1. Sometimes using undefined simplifies the compiler and improves
generated code.
2. (OTOH) Undefind situations are unhelpful the the users, they complicate
debugging, and make programming harder. Reducing rules that imply
undefined behavior semantics is good for the users.
3. Each language strikes a different balance between 1 and 2.
4. Claiming that numeric_limitssigned::is_modulo based on undefined
does not help the user, because as a result you lose all the benefits of
is_modulo to begin with. Consider the example:
template class T T foo(T a, T b)
{
// For example simplicity, this if is not generic.
if (numeric_limitsT::is_modulo)
return trivial_code (a+b); // undefined for signed
else
return contorted_slow_code(a, b);
}
is_modulo = true is unhelpful, it will trigger the undefined case,
a case that the code tries to avoid. It makes it more difficult to
write generic code that avoids the trouble.
It is much more helpful to go for is_modulo = false.
5. There is no performance penatly for is_modulo = false, so item 1 does
not come into play.
6. According to 3, the language should strike a balance between 1 and 2.
Since 1 is not playing any role here, then 2 wins and the language
should go for the semantics that does not depend on undefined.
7. The text of the standard may be interpreded both ways (a fact: several
people draw contradictory conclusions from the document). In that
case we should choose what makes more sense if we would write the
document.
8. When interpreting an ambiguous document (7), we should take the motives
of the writers and the whole document objectives into account.
According to 6, is_modulo = false strikes the best balance, as a result
it would have been preferred by any reasonable committy.
Michael
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-27 21:02 --- (In reply to comment #21) 1. Sometimes using undefined simplifies the compiler and improves generated code. 2. (OTOH) Undefind situations are unhelpful the the users, they complicate debugging, and make programming harder. Reducing rules that imply undefined behavior semantics is good for the users. No I disagree with that, most undefined behaviors are very easy to debug, the most obvious one and most invoked undefined behavior in terms of bug reports is violating C/C++ aliasing rules (see PR 21920 which has 69 duplicates). In fact if you look at GCC, it is the only compiler were people run into violating C/C++ aliasing rules beause we use them to check if two addresses can alias. This is unlike almost all other compilers which represent their aliasing info as base+address and they only invoke the C/C++ aliasing rules when they cannot figure out if they point to the same address. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug libstdc++/22200] numeric_limitssigned::is_modulo is inconsistend with gcc
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27 22:00 --- (In reply to comment #22) (In reply to comment #21) 2. (OTOH) Undefind situations are unhelpful the the users, they complicate debugging, and make programming harder. Reducing rules that imply undefined behavior semantics is good for the users. No I disagree with that, most undefined behaviors are very easy to debug, the most obvious one and most invoked undefined behavior in terms of bug reports is violating C/C++ aliasing rules (see PR 21920 which has 69 duplicates). What you disagree with? You're claiming that undefined behavior does not complicate debugging? Isn't it true that with undefined behavior you're most likely to bump into behavioral differences between -O2 and -O0? Isn't it true that debugging an -O2 code is more complicated than -O0 ? Q.E.D. Also, how did you come to the conclusion that most undefined behaviors are very easy to debug? You don't know how much time it took the user to reduce 100 KLOC to simple test cases of these 69 dups of PR 21920. Once the test case is reduced, it is pretty trival to understand it. In fact if you look at GCC, it is the only compiler were people run into violating C/C++ aliasing rules beause we use them to check if two addresses can alias. This is unlike almost all other compilers which represent their aliasing info as base+address and they only invoke the C/C++ aliasing rules when they cannot figure out if they point to the same address. The first time I got into trouble with aliasing rules was with xlC, not with gcc. It was in template inline code (STL allocators). Trivial base+address would have detected that free_list_element* and T* alias (they were copies of one another!). Because I used a temporary copy of u.next_free_element, instead of accessing u.next_free_element directly, xlC would think that the pointers do not alias. Now since most normal people don't write STL allocators at their leisure, they have less chance to bump into such a complex scenario as I did. The aliasing rules were violated only due to inlining, a very difficult thing for a user to spot. I had to debug PPC assembly code to figure out what went wrong (remember that debugging with -O2 has a very limited utility). And yes, I was aware of the aliasing rules, just make a subtle mistake. Would I not have been aware of the aliasing rules, then it would take me 3 days instead of 1 to analyze it. I could I reduce my 100 KLOC (no valgrind for AIX to find this memory corruption) to 15 trival lines, which any competent C/C++ programmer would find to be invalid. Please, pretty please, take into account that the distance between the C++ text, and assembly (and probably GIMPLE) is significantly greater than that of C, due to generic programming. It is much harder to analyze the subtalties of undefined behavior in C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
