[EMAIL PROTECTED] (Gabriel Dos Reis) wrote on 27.06.05 in [EMAIL PROTECTED]:
Nathan Sidwell [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
|
| But a compiler could define them to be modulo -- that is the whole
| point. The paragraph does not say they don't modulo.
|
| of course
On Wed, 2005-06-29 at 18:46 +0200, Steven Bosscher wrote:
On Tuesday 28 June 2005 14:09, Steven Bosscher wrote:
On Tuesday 28 June 2005 14:02, Ulrich Weigand wrote:
Steven Bosscher wrote:
Anyway, I've started a SPEC run with -O2 vs. -O2 -fwrapv. Let's
see how big the damage would be
On Wednesday 29 June 2005 20:01, Daniel Berlin wrote:
So i would advise anyone arguing against turning on -fwrapv simply
because it doesn't seem to hurt us at O2.
wtf, doesn't seem to hurt us at -O2. Look again at the 64 bits
numbers! Losing 5% on the fp benchmarks is a serious regression.
Steven Bosscher wrote:
On Wednesday 29 June 2005 20:01, Daniel Berlin wrote:
So i would advise anyone arguing against turning on -fwrapv simply
because it doesn't seem to hurt us at O2.
wtf, doesn't seem to hurt us at -O2. Look again at the 64 bits
numbers! Losing 5% on the fp benchmarks
On Wed, 29 Jun 2005, Daniel Berlin wrote:
So i would advise anyone arguing against turning on -fwrapv simply
because it doesn't seem to hurt us at O2.
And i'll again point out that the exact opposite is the default in every
other compiler i'm aware of.
Sorry, I couldn't parse those
Mark Mitchell wrote:
Although the standard clearly makes signed overflow undefined, I think
it would be better if GCC defined it to be modulo arithmetic. The
degree to which that would result in inferior code seems likely to be
somewhat small, and the amount of user confusion we would
On Tuesday 28 June 2005 12:07, Robert Dewar wrote:
Mark Mitchell wrote:
Although the standard clearly makes signed overflow undefined, I think
it would be better if GCC defined it to be modulo arithmetic. The
degree to which that would result in inferior code seems likely to be
somewhat
Steven Bosscher wrote:
Anyway, I've started a SPEC run with -O2 vs. -O2 -fwrapv. Let's see
how big the damage would be ;-)
Please make sure to include a 64-bit target, where it actually makes any
difference. (I recall performance degradations of 20-30% in some
SPECfp cases from getting
On Tuesday 28 June 2005 14:02, Ulrich Weigand wrote:
Steven Bosscher wrote:
Anyway, I've started a SPEC run with -O2 vs. -O2 -fwrapv. Let's see
how big the damage would be ;-)
Please make sure to include a 64-bit target, where it actually makes any
difference. (I recall performance
Steven == Steven Bosscher [EMAIL PROTECTED] writes:
Steven Indeed. Frankly this seems likely guess confuses me. It
Steven is already well known that using unsigned types for loop
Steven counters may greatly improve the code gcc can generate for
Steven loops. With wrap-around semantics,
On Tuesday 28 June 2005 14:16, Paul Koning wrote:
Steven == Steven Bosscher [EMAIL PROTECTED] writes:
Steven Indeed. Frankly this seems likely guess confuses me. It
Steven is already well known that using unsigned types for loop
Steven counters may greatly improve the code gcc can
Steven Bosscher [EMAIL PROTECTED] wrote on 28/06/2005 15:30:27:
On Tuesday 28 June 2005 14:16, Paul Koning wrote:
I must be missing something.
Yes.
Unsigned has wraparound (modulo)
semantics.
The whole point is that it doesn't.
I think that you confuse between signed and
On Tuesday 28 June 2005 14:34, Michael Veksler wrote:
Steven Bosscher [EMAIL PROTECTED] wrote on 28/06/2005 15:30:27:
On Tuesday 28 June 2005 14:16, Paul Koning wrote:
I must be missing something.
Yes.
Unsigned has wraparound (modulo)
semantics.
The whole point is that it
Nathan Sidwell [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Michael Veksler [EMAIL PROTECTED] writes:
| [...]
| | The code is not very simple, and different codes will get optimized
| | differently.
| | The user will have to learn how to write this piece of code differently
for
|
On Jun 28, 2005, at 9:58 AM, Gabriel Dos Reis wrote:
Notice that in your rendition you're assuming that you can convert any
unsigned value INT_MAX to a int without invoking undefined behaviour.
If you read Nathan's mail correctly, the cast is implementation defined
and not undefined
Gabriel Dos Reis wrote:
Nathan Sidwell [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
| Michael Veksler [EMAIL PROTECTED] writes:
| [...]
| | The code is not very simple, and different codes will get optimized
| | differently.
| | The user will have to learn how to write this piece of
Andrew Pinski [EMAIL PROTECTED] writes:
| On Jun 28, 2005, at 9:58 AM, Gabriel Dos Reis wrote:
|
| Notice that in your rendition you're assuming that you can convert any
| unsigned value INT_MAX to a int without invoking undefined behaviour.
|
|
|
| If you read Nathan's mail correctly, the
Gabriel Dos Reis wrote on 28/06/2005 17:12:43:
Andrew Pinski [EMAIL PROTECTED] writes:
| On Jun 28, 2005, at 9:58 AM, Gabriel Dos Reis wrote:
|
| Notice that in your rendition you're assuming that you can convert
any
| unsigned value INT_MAX to a int without invoking undefined
Michael Veksler wrote:
So what does gcc gives for (int) (MAX_INT+1U)?
Maybe it is constrained such that
(int)(unsigned)a == a
For 1's complement the reverse seems to be incorrect:
unsigned a= 0x; // or was it 0x8000?
assert((unsigned)(int)a == a); // may fail
why are you
Michael Veksler [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote on 28/06/2005 17:12:43:
|
| Andrew Pinski [EMAIL PROTECTED] writes:
|
| | On Jun 28, 2005, at 9:58 AM, Gabriel Dos Reis wrote:
| |
| | Notice that in your rendition you're assuming that you can convert
| any
| | unsigned
Nathan Sidwell [EMAIL PROTECTED] wrote on 28/06/2005 18:48:26:
why are you talking about one's complement in the context of gcc. From
implement-c.texi
@cite{Whether signed integer types are represented using sign and
magnitude,
two's complement, or one's complement, and whether
On Jun 28, 2005, at 11:58 AM, Michael Veksler wrote:
Sorry, did not realize this was documented this way.
Is implement-c.texi part of the user visible documentation, or is it
targeted for gcc developers?
http://gcc.gnu.org/onlinedocs/gcc/C-Implementation.html#C-Implementation
in the normal
Michael Veksler [EMAIL PROTECTED] writes:
| Nathan Sidwell [EMAIL PROTECTED] wrote on 28/06/2005 18:48:26:
|
|
| why are you talking about one's complement in the context of gcc. From
| implement-c.texi
|
| @cite{Whether signed integer types are represented using sign and
| magnitude,
|
On Tue, 28 Jun 2005, Gabriel Dos Reis wrote:
Yes, we should document this. In general, implementation defined
aspects (and some of the undefined behaviour aspects) are missing
documentation for C++ -- JSM did some work for that for C.
Is there a convenient checklist for C++ similar to C99's
On Mon, Jun 27, 2005 at 08:05:48PM -0700, Mark Mitchell wrote:
Michael Veksler wrote:
Most programmers know that arithmetic is modulo wordsize. And those few
who know the right answer (only unsigned arithmetic is modulo) will
from time to time slip up and omit the unsigned keyword in their
Joe Buck wrote:
I don't think we should give the user any such promise, and if we do
give such a promise, we will never catch icc. The main problem is that
we will no longer be able to optimize many loops.
It's entirely possible that I was naive in assuming that this wouldn't
have a big
On Tue, 28 Jun 2005, Mark Mitchell wrote:
Joe Buck wrote:
I don't think we should give the user any such promise, and if we do
give such a promise, we will never catch icc. The main problem is that
we will no longer be able to optimize many loops.
It's entirely possible that I was naive
On Tue, 2005-06-28 at 10:02 -0700, Mark Mitchell wrote:
Joe Buck wrote:
int blah(int);
int func(int a, int b) {
if (b = 0) {
int c = a + b;
int count = 0;
for (int i = a; i = c; i++)
count++;
blah(count);
}
}
Yes, I understand.
I
Joseph S. Myers [EMAIL PROTECTED] writes:
| On Tue, 28 Jun 2005, Gabriel Dos Reis wrote:
|
| Yes, we should document this. In general, implementation defined
| aspects (and some of the undefined behaviour aspects) are missing
| documentation for C++ -- JSM did some work for that for C.
|
|
Daniel Berlin wrote:
On Tue, 28 Jun 2005, Mark Mitchell wrote:
Joe Buck wrote:
I don't think we should give the user any such promise, and if we do
give such a promise, we will never catch icc. The main problem is that
we will no longer be able to optimize many loops.
It's entirely
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_limitssigned type::is_modulo = true.
signed types are undefined on overflow. [5/5] and
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_limitssigned type::is_modulo = true.
|
Gabriel Dos Reis wrote:
But a compiler could define them to be modulo -- that is the whole
point. The paragraph does not say they don't modulo.
of course it could do so, but then to be useful it should document it, and it
would be an extension.
| 18.2.1.2/57 claims is_modulo is true 'for
| 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.
True, but you are going to have to deal with the run-time version of
(int)0x8000 / -1
which is
Nathan == Nathan Sidwell [EMAIL PROTECTED] writes:
And all useful programs we write rely on undefined behaviour of
one sort or the other, starting with GCC. In the case of
Nathan They do? I thought they usually relied on implementation
Nathan defined, documented extensions or were part
Nathan Sidwell [EMAIL PROTECTED] writes:
| Gabriel Dos Reis wrote:
|
| But a compiler could define them to be modulo -- that is the whole
| point. The paragraph does not say they don't modulo.
|
| of course it could do so, but then to be useful it should document it,
| and it would be an
Morten Welinder [EMAIL PROTECTED] writes:
| | 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.
|
| True, but you are going to have to deal with the
Paul Koning [EMAIL PROTECTED] wrote on 27/06/2005 17:47:12:
Nathan == Nathan Sidwell [EMAIL PROTECTED] writes:
And all useful programs we write rely on undefined behaviour of
one sort or the other, starting with GCC. In the case of
Nathan They do? I thought they usually relied
Michael Veksler wrote:
Most programmers know that arithmetic is modulo wordsize. And those few
who know the right answer (only unsigned arithmetic is modulo) will
from time to time slip up and omit the unsigned keyword in their
declarations.
I agree.
Although the standard clearly makes
Mark Mitchell [EMAIL PROTECTED] writes:
| Michael Veksler wrote:
|
| Most programmers know that arithmetic is modulo wordsize. And those few
| who know the right answer (only unsigned arithmetic is modulo) will
| from time to time slip up and omit the unsigned keyword in their
| declarations.
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_limitssigned type::is_modulo = true.
1. Is that a bug in limits, a bug in the standard, or is just C++
41 matches
Mail list logo
