Nathan Sidwell <[EMAIL PROTECTED]> writes:
| Michael Veksler wrote:
| > According to the (very) long discussion on VRP, signed char/short/int/etc
| > do not have modulo semantic, they have an undefined behavior on overflow.
| > However in <limits> defines numeric_limits<signed type>::is_modulo = true.
|
| signed types are undefined on overflow. [5/5] and [3.9.1/2,3]
But a compiler could define them to be modulo -- that is the whole
point. The paragraph does not say they don't "modulo".
| > 1. Is that a bug in <limits>, a bug in the standard, or is just C++
| > different
| > than C in this respect?
| a bug in limits, probably
|
| > 2. Maybe because overflow is undefined then is_modulo maybe
| > considered "unspecified". I don't like this option, because it does not
| > help
| > generic programming.
| it's also, I believe, wrong, in that some gcc optimizations will not
| preserve such behaviour. (I guess this is the whole VRP conversation
| you mention.)
|
| > 3. Do I understand what is_modulo stands for?
| yes
|
| > 4. What should be done (libstdc++ PR, C++ PR, DR, other)?
|
| 18.2.1.2/57 claims is_modulo is true 'for signed types on most
| machines'. Such an assertion is false when optimizations rely the
| undefinedness of signed overflow. A DR should probably be filed
| (maybe one is, I'm not at all familiar with library DRs).
Well, undefined behaviour does not mean unconditional hell or evil.
It is just behaviour left up to the compiler to whatever it wants.
And all useful programs we write rely on undefined behaviour of one
sort or the other, starting with GCC. In the case of
numeric_limits<>, it may help remembering two things:
(1) 18.2.1/1
The numeric_limits component provides a C++ program with
information about various properties of the implementation's
representation of the fundamental types.
(2) LIA-1, 5.1.2
If /bounded/ is true, the mathematical operations +, 1, *, /
(after rounding) can produce results that lie outside of the set
I. In such cases, the computations add_I, sub_I, mul_I and
div_I shall either cause a notification (if modulo == false), or
return a "wrapped" result (if modulo = true)
(1) is something that C++ provides (constains more information that
C's <limits.h> and <float.h>) user with. The intented semantics is
that that compiler informs users about their representation choices.
(2) gives the rationale behing "modulo". C++ does not require
notification (the passage you pointed to), so it is up to GCC to
define the behaviour should be and correspondingly amend the paragraph
so as to display consistent semantics.
Back in the dark ages, we used to define is_modulo false but we did not
raise notification, basing on the fact since C++ did not require
anything, it was already sufficient to tell user that we do not
promise modulo arithmetic.
When RTH helped cleanup the numeric_limits implementation in September
2002, he made a very good point (which I held to be true, since
obviously he is The Middle-end and Back-end Guy)
http://gcc.gnu.org/ml/libstdc++/2002-09/msg00207.html
Quote:
First, GCC does not support any targets for which is_modulo is false
for an integer type. This is made obvious by the fact that we do not
distinguish between signed and unsigned rtl modes, and eg do not have
different patterns for signed and unsigned addition. Thus is_modulo
should always be true for the integral types.
I don't think there is a DR for that (from the standard point). We do
have a consistency problem in GCC. I believe optimizations we do
should be consistent with semantics unless we also provide for
-finconsistent-semantics.
-- Gaby
