On 1/19/07, Joe Buck [EMAIL PROTECTED] wrote:
On Thu, Jan 18, 2007 at 05:36:23PM -0500, Robert Dewar wrote:
Morten Welinder wrote:
For sure a/b is undefined
In C, it is. In assembler it is perfectly well defined, i.e., it
traps. But how is the
trap handler supposed to know the source of
Ian Lance Taylor writes:
Robert Dewar [EMAIL PROTECTED] writes:
Ian Lance Taylor wrote:
We do want to generate a trap for x / 0, of course.
Really? Is this really defined to generate a trap in C?
I would be surprised if so ...
As far as I know, but I think it would
On Thu, 18 Jan 2007, Andrew Haley wrote:
| Robert Dewar writes:
| Joe Buck wrote:
|
| (off topic!)
|
|On Wed, Jan 17, 2007 at 06:40:21PM -0500, Robert Dewar wrote:
|H .. I wish some of the more important bugs in gcc received
|the attention that this very unimportant issue
Andrew Haley wrote:
Mm, but although the problem being dicussed here is trivial, some of
the proposed solutions aren't. As the saying goes, the cure is worse
than the disease.
Indeed! Well whenever you have umpteen people all trying to solve
a simple problem, things always get out of hand,
Gabriel Dos Reis wrote:
I would say that is a bit extreme. I don't think we're going to
implement any of the solutions without giving people options to
disable the correct instruction generation when they don't care about
it.
I would hesitate a bit about options in this general class of
For sure a/b is undefined
In C, it is. In assembler it is perfectly well defined, i.e., it
traps. But how is the
trap handler supposed to know the source of a given instruction?
M.
On Wed, Jan 17, 2007 at 12:43:40AM +0100, Vincent Lefevre wrote:
On 2007-01-16 21:27:42 +, Andrew Haley wrote:
Ian Lance Taylor writes:
I suspect that the best fix, in the sense of generating the best
code, would be to do this at the tree level. That will give loop
and VRP
Ian Lance Taylor writes:
Gabriel Dos Reis [EMAIL PROTECTED] writes:
Ian, do you believe something along the line of
# I mean, could not we generate the following for %:
#
# rem a b :=
#if abs(b) == 1
# return 0
#return
On Wed, 17 Jan 2007, Andrew Haley wrote:
| Ian Lance Taylor writes:
| Gabriel Dos Reis [EMAIL PROTECTED] writes:
|
|Ian, do you believe something along the line of
|
| # I mean, could not we generate the following for %:
| #
| # rem a b :=
| #if abs(b) ==
Andrew Haley wrote:
Ian Lance Taylor writes:
Gabriel Dos Reis [EMAIL PROTECTED] writes:
Ian, do you believe something along the line of
# I mean, could not we generate the following for %:
#
# rem a b :=
#if abs(b) == 1
# return 0
#
Gabriel Dos Reis writes:
On Wed, 17 Jan 2007, Andrew Haley wrote:
|
| From a performance/convenience angle, the best place to handle this is
| either libc or the kernel.
Hmm, that is predicated on assumptions not convenient to users
on targets that are not glibc-based or
David Daney writes:
That only works if the operation causes a trap.
Which it does in almost all cases. Let PPC do something different, if
that's what really PPC needs.
Andrew.
On Wed, 17 Jan 2007, Andrew Haley wrote:
| Gabriel Dos Reis writes:
| On Wed, 17 Jan 2007, Andrew Haley wrote:
|
| |
| | From a performance/convenience angle, the best place to handle this is
| | either libc or the kernel.
|
| Hmm, that is predicated on assumptions not convenient to
Gabriel Dos Reis writes:
On Wed, 17 Jan 2007, Andrew Haley wrote:
| Gabriel Dos Reis writes:
| On Wed, 17 Jan 2007, Andrew Haley wrote:
|
| |
| | From a performance/convenience angle, the best place to handle this is
| | either libc or the kernel.
|
| Hmm, that
Andrew Haley wrote:
From a performance/convenience angle, the best place to handle this is
either libc or the kernel. Either of these can quite easily fix up
the operands when a trap happens, with zero performance degradation of
existing code. I don't think there's any need for gcc to be
On Wed, 17 Jan 2007, Andrew Haley wrote:
[...]
| | To a man with a hammer, all things look like a nail. It's very
| | tempting for us in gcc-land always to fix things in gcc, not because
| | it's technically the right place but because it's what we control
| | ourselves.
|
| well,
Gabriel Dos Reis writes:
On Wed, 17 Jan 2007, Andrew Haley wrote:
[...]
| | To a man with a hammer, all things look like a nail. It's very
| | tempting for us in gcc-land always to fix things in gcc, not because
| | it's technically the right place but because it's what we
On Wed, Jan 17, 2007 at 05:48:34PM +, Andrew Haley wrote:
From a performance/convenience angle, the best place to handle this is
either libc or the kernel. Either of these can quite easily fix up
the operands when a trap happens, with zero performance degradation of
existing code. I
On Wed, Jan 17, 2007 at 06:03:08PM +, Andrew Haley wrote:
Gabriel Dos Reis writes:
On Wed, 17 Jan 2007, Andrew Haley wrote:
|
| From a performance/convenience angle, the best place to handle this is
| either libc or the kernel.
Hmm, that is predicated on assumptions not
On 17 January 2007 19:09, Joe Buck wrote:
On Wed, Jan 17, 2007 at 05:48:34PM +, Andrew Haley wrote:
From a performance/convenience angle, the best place to handle this is
either libc or the kernel. Either of these can quite easily fix up
the operands when a trap happens, with zero
On Wed, Jan 17, 2007 at 07:03:43PM +, Andrew Haley wrote:
It's an engineering problem. We have a widget that does the wrong
thing*. We have several ways to make it do the right thing, only one
of which has no adverse impact on the existing users of the widget.
* (in some people's
Joe Buck [EMAIL PROTECTED] writes:
On Wed, Jan 17, 2007 at 05:48:34PM +, Andrew Haley wrote:
From a performance/convenience angle, the best place to handle this is
either libc or the kernel. Either of these can quite easily fix up
the operands when a trap happens, with zero
On Wed, 17 Jan 2007, Andrew Haley wrote:
| Gabriel Dos Reis writes:
| On Wed, 17 Jan 2007, Andrew Haley wrote:
|
| [...]
|
| | | To a man with a hammer, all things look like a nail. It's very
| | | tempting for us in gcc-land always to fix things in gcc, not because
| | |
Ian Lance Taylor wrote:
Joe Buck [EMAIL PROTECTED] writes:
How will the kernel know whether the overflow in the divide instruction
is because the user's source code has a '%' and not a '/'? We generate
the exact same instruction for i / minus_one(), after all, and in that
case the trap
On Wed, Jan 17, 2007 at 11:17:36AM -0800, Ian Lance Taylor wrote:
Joe Buck [EMAIL PROTECTED] writes:
On Wed, Jan 17, 2007 at 05:48:34PM +, Andrew Haley wrote:
From a performance/convenience angle, the best place to handle this is
either libc or the kernel. Either of these can quite
Dave Korn wrote:
On 17 January 2007 19:09, Joe Buck wrote:
How will the kernel know whether the overflow in the divide instruction
is because the user's source code has a '%' and not a '/'? We generate
the exact same instruction for i / minus_one(), after all, and in that
case the trap
Gabriel Dos Reis writes:
On Wed, 17 Jan 2007, Andrew Haley wrote:
| Gabriel Dos Reis writes:
| On Wed, 17 Jan 2007, Andrew Haley wrote:
|
| [...]
|
| | | To a man with a hammer, all things look like a nail. It's very
| | | tempting for us in gcc-land always to
On Wed, Jan 17, 2007 at 07:42:38PM +, Andrew Haley wrote:
Gabriel Dos Reis writes:
You believe there is one solution, except that it does not work for
the supported target.
Sorry, I don't understand what you mean by that.
I suspect that he meant to write one supported target; it
On Wed, 17 Jan 2007, Joe Buck wrote:
| On Wed, Jan 17, 2007 at 07:42:38PM +, Andrew Haley wrote:
| Gabriel Dos Reis writes:
|You believe there is one solution, except that it does not work for
|the supported target.
|
| Sorry, I don't understand what you mean by that.
|
| I suspect
H .. I wish some of the more important bugs in gcc received
the attention that this very unimportant issue is receiving :-)
I guess the difference is that lots of people can understand
this issue.
Reminds me of the hullabaloo over the Pentium division problem.
The fact of the matter was
Joe Buck wrote:
If GCC winds up having to fix the bug in the compiler itself for PPC,
then everyone could have the option of using a kernel fix or a compiler
fix. But how are you going to do the kernel fix? What if the user did
an integer divide and not a modulo? I suppose you could just say
Ian Lance Taylor wrote:
We do want to generate a trap for x / 0, of course.
Really? Is this really defined to generate a trap in C?
I would be surprised if so ...
Robert Dewar [EMAIL PROTECTED] writes:
Ian Lance Taylor wrote:
We do want to generate a trap for x / 0, of course.
Really? Is this really defined to generate a trap in C?
I would be surprised if so ...
As far as I know, but I think it would be a surprising change for x /
0 to silently
Ian Lance Taylor [EMAIL PROTECTED] writes:
| Robert Dewar [EMAIL PROTECTED] writes:
|
| Ian Lance Taylor wrote:
|
| We do want to generate a trap for x / 0, of course.
|
| Really? Is this really defined to generate a trap in C?
| I would be surprised if so ...
|
| As far as I know, but
On Wed, Jan 17, 2007 at 04:15:08PM -0800, Ian Lance Taylor wrote:
Robert Dewar [EMAIL PROTECTED] writes:
Ian Lance Taylor wrote:
We do want to generate a trap for x / 0, of course.
Really? Is this really defined to generate a trap in C?
I would be surprised if so ...
As far as
Ian Lance Taylor wrote:
Robert Dewar [EMAIL PROTECTED] writes:
Ian Lance Taylor wrote:
We do want to generate a trap for x / 0, of course.
Really? Is this really defined to generate a trap in C?
I would be surprised if so ...
As far as I know, but I think it would be a surprising
Gabriel Paubert [EMAIL PROTECTED] writes:
| On Wed, Jan 17, 2007 at 04:15:08PM -0800, Ian Lance Taylor wrote:
| Robert Dewar [EMAIL PROTECTED] writes:
|
| Ian Lance Taylor wrote:
|
|We do want to generate a trap for x / 0, of course.
|
| Really? Is this really defined to generate
On Wed, Jan 17, 2007 at 06:40:21PM -0500, Robert Dewar wrote:
H .. I wish some of the more important bugs in gcc received
the attention that this very unimportant issue is receiving :-)
I guess the difference is that lots of people can understand
this issue.
Yes, this phenomenon has
On Jan 17, 2007, at 4:44 PM, Gabriel Dos Reis wrote:
C++ forces compilers to reveal their semantics for built-in types
through numeric_limits. Every time you change the behaviour,
you also implicilty break an ABI.
No, the ABI does not document that the answer never changes between
On Wed, 17 Jan 2007, Mike Stump wrote:
| On Jan 17, 2007, at 4:44 PM, Gabriel Dos Reis wrote:
| C++ forces compilers to reveal their semantics for built-in types
| through numeric_limits. Every time you change the behaviour,
| you also implicilty break an ABI.
|
| No, the ABI does not
On Jan 17, 2007, at 6:46 PM, Gabriel Dos Reis wrote:
(1) the ABI I was talking about is that of libstdc++
(2) numeric_limits cannot change from translation unit to
translation
unit, within the same program otherwise you break the ODR. I
guess
we all agree on that.
Doh! Did I
Joe Buck wrote:
(off topic!)
On Wed, Jan 17, 2007 at 06:40:21PM -0500, Robert Dewar wrote:
H .. I wish some of the more important bugs in gcc received
the attention that this very unimportant issue is receiving :-)
I guess the difference is that lots of people can understand
this issue.
Gabriel Paubert wrote:
On Mon, Jan 15, 2007 at 10:34:23PM +0200, Michael Veksler wrote:
Once the kernel sees the FP trap (whatever its i368 name is),
it decodes the machine code and finds:
idivl (%ecx).
As far as I remember, this will put the result in two registers
one for div_res and one
Compared to the slow idivl, abs could be negligible, right. However, abs
does introduce new data dependence which might add a noticeable cost.
Is there an abs instruction in the i386 instruction set?
No, the closest thing (input in eax, output in edx) is
cltq
addl %edx, %eax
xorl %eax,
Paolo Bonzini wrote:
Compared to the slow idivl, abs could be negligible, right. However, abs
does introduce new data dependence which might add a noticeable cost.
Is there an abs instruction in the i386 instruction set?
No, the closest thing (input in eax, output in edx) is
cltq
cltq
addl %edx, %eax
xorl %eax, %edx
But the register allocations constraints are pretty heavy considering
that idivl already puts strain on the RA.
Paolo, what does the cltq instruction do? I cannot find it in my x86
reference manuals...
Uhm, I meant cltd and it is the same as cdq in the
Michael Veksler writes:
Roberto Bagnara wrote:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386
Andrew Haley [EMAIL PROTECTED] writes:
| Michael Veksler writes:
| Roberto Bagnara wrote:
|
|Reading the thread Autoconf manual's coverage of signed integer
|overflow portability I was horrified to discover about GCC's
|miscompilation of the remainder expression that causes
Gabriel Dos Reis writes:
Andrew Haley [EMAIL PROTECTED] writes:
| Michael Veksler writes:
| Roberto Bagnara wrote:
|
|Reading the thread Autoconf manual's coverage of signed integer
|overflow portability I was horrified to discover about GCC's
|miscompilation of
Andrew Haley [EMAIL PROTECTED] writes:
| Gabriel Dos Reis writes:
| Andrew Haley [EMAIL PROTECTED] writes:
|
| | Michael Veksler writes:
| | Roberto Bagnara wrote:
| |
| |Reading the thread Autoconf manual's coverage of signed integer
| |overflow portability I was
Andrew Haley wrote:
Roberto Bagnara writes:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family.
Roberto Bagnara writes:
Andrew Haley wrote:
Roberto Bagnara writes:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to
On Tuesday 16 January 2007 16:50, Andrew Haley wrote:
Roberto Bagnara writes:
Andrew Haley wrote:
Roberto Bagnara writes:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of
Andrew Haley wrote:
Roberto Bagnara writes:
Andrew Haley wrote:
Roberto Bagnara writes:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of the remainder expression that causes
Roberto Bagnara writes:
Andrew Haley wrote:
If the quotient a/b is *not* representable, is the behaviour of %
well-defined or not? It doesn't say.
To the point that, when a/b is not representable, raising SIGFPE
for a%b is standard conformant behavior?
Note however that I am
On 16/01/07, Duncan Sands [EMAIL PROTECTED] wrote:
On Tuesday 16 January 2007 16:50, Andrew Haley wrote:
Roberto Bagnara writes:
Andrew Haley wrote:
Roberto Bagnara writes:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was
It's interesting that the same issue arose with GNAT, but
we had no option to ignore the special case, since one of
the official Ada validation test programs tested this case,
and indeed as you see below there is a special test:
function q (a, b : integer) return integer is
begin
return a
Roberto Bagnara wrote:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family. Are there plans to
fix this bug
Roberto Bagnara wrote:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family. Are there plans to
fix this bug
Robert Dewar wrote:
Roberto Bagnara wrote:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family. Are there
Roberto Bagnara wrote:
Andrew Haley wrote:
Roberto Bagnara writes:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on
Roberto Bagnara wrote:
To the point that, when a/b is not representable, raising SIGFPE
for a%b is standard conformant behavior?
possibly so ..
Note however that I am not saying that the standard is not defective.
Who knows how to write and submit C/C++ standard defect reports?
Let us do
On Tue, Jan 16, 2007 at 08:22:10AM -0600, Gabriel Dos Reis wrote:
I mean, could not we generate the following for %:
rem a b :=
if abs(b) == 1
return 0
return machine-instruction a b
On x86 processors that have conditional moves, why not do the equivalent
of
Robert Dewar wrote:
Roberto Bagnara wrote:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family. Are there
Andrew Haley [EMAIL PROTECTED] writes:
| Roberto Bagnara writes:
| Andrew Haley wrote:
|Roberto Bagnara writes:
|
| Reading the thread Autoconf manual's coverage of signed integer
| overflow portability I was horrified to discover about GCC's
| miscompilation of the
Duncan Sands [EMAIL PROTECTED] writes:
[...]
| Ada semantics require INT_MIN rem -1 to be zero.
I cannot see any other value as a result.
-- Gaby
Roberto Bagnara wrote:
Robert Dewar wrote:
Roberto Bagnara wrote:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the
Robert Dewar wrote:
Roberto Bagnara wrote:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family. Are there
Gabriel Paubert wrote:
\
No, because the instruction has actually two result values:
- the remainder, which you could safely set to zero (not 1!)
- the quotient, which is affected by the overflow and there may be
compiler and languages that rely on the exception being generated.
But the
On 16 January 2007 18:23, Robert Dewar wrote:
Gabriel Paubert wrote:
\
No, because the instruction has actually two result values:
- the remainder, which you could safely set to zero (not 1!)
- the quotient, which is affected by the overflow and there may be
compiler and languages
Robert Dewar wrote:
Roberto Bagnara wrote:
Andrew Haley wrote:
Roberto Bagnara writes:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to
Dave Korn wrote:
On 16 January 2007 18:23, Robert Dewar wrote:
Gabriel Paubert wrote:
\
No, because the instruction has actually two result values:
- the remainder, which you could safely set to zero (not 1!)
- the quotient, which is affected by the overflow and there may be
compiler and
Roberto Bagnara wrote:
I am sorry if I brought you to think that I am asking something
for me. There is no longer a problem for me personally: I will
simply stop using % in my projects (which, by the way are in C++)
and will use custom functions instead. I have almost finished
an Autoconf
On 16 January 2007 18:42, Robert Dewar wrote:
Dave Korn wrote:
On 16 January 2007 18:23, Robert Dewar wrote:
Gabriel Paubert wrote:
\
No, because the instruction has actually two result values:
- the remainder, which you could safely set to zero (not 1!)
- the quotient, which is
On Tue, Jan 16, 2007 at 12:05:12PM -0600, Gabriel Dos Reis wrote:
By definition, the absolute value of a % b is always less than the
absolute value of b. Consequently, a % b is always defined.
Nitpick: for nonzero b.
On Tue, 16 Jan 2007, Joe Buck wrote:
| On Tue, Jan 16, 2007 at 12:05:12PM -0600, Gabriel Dos Reis wrote:
| By definition, the absolute value of a % b is always less than the
| absolute value of b. Consequently, a % b is always defined.
|
| Nitpick: for nonzero b.
yes, I assumed that -- since
David Daney wrote:
Roberto Bagnara wrote:
Robert Dewar wrote:
Roberto Bagnara wrote:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a
Roberto Bagnara wrote:
You are right: I am not familiar with DO-178B certification.
Fair enough, but it means you should never use avionics code
as an example in such discussions. No life has ever been lost
due to a software bug in the realm of commercial aviation, and
that was not achieved
Roberto Bagnara wrote:
Hmmm, it says nothing about the remainder. Can some Google guru
suggest how to prove or disprove the claim that what we are
talking about is wildly known?
The point really is not how widely/wildly known the issue is. Really
the thing we consider on gcc@ is: What is
On Tue, Jan 16, 2007 at 11:05:20AM -0800, David Daney wrote:
Roberto Bagnara wrote:
Hmmm, it says nothing about the remainder. Can some Google guru
suggest how to prove or disprove the claim that what we are
talking about is wildly known?
The point really is not how widely/wildly known
Andrew Haley wrote:
Roberto Bagnara writes:
Robert Dewar wrote:
Yes, it's a bug, is it a serious bug, no? Will real software
be affected? no. Indeed I find any program that actually
does this remainder operation in practice to be highly
suspect.
But I am not wrong if I say
On 2007-01-16 12:31:00 -0500, Robert Dewar wrote:
Roberto Bagnara wrote:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs
Vincent Lefevre wrote:
On 2007-01-16 12:31:00 -0500, Robert Dewar wrote:
Roberto Bagnara wrote:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to
Joe Buck [EMAIL PROTECTED] writes:
I suggest that those who think this is a severe problem are the ones who
are highly motivated to work on a solution. An efficient solution could
be tricky: you don't want to disrupt pipelines, or interfere with
optimizations that rely on recognizing that
Ian Lance Taylor writes:
Joe Buck [EMAIL PROTECTED] writes:
I suggest that those who think this is a severe problem are the
ones who are highly motivated to work on a solution. An
efficient solution could be tricky: you don't want to disrupt
pipelines, or interfere with
On 2007-01-16 15:50:09 +, Andrew Haley wrote:
This is a disgreement about interpretation of the langauge in the
standard, which is:
The result of the / operator is the quotient from the division of the
first operand by the second; the result of the % operator is the
remainder. In both
Andrew Haley wrote:
Ian Lance Taylor writes:
Joe Buck [EMAIL PROTECTED] writes:
I suggest that those who think this is a severe problem are the
ones who are highly motivated to work on a solution. An
efficient solution could be tricky: you don't want to disrupt
pipelines, or
David Daney [EMAIL PROTECTED] writes:
Andrew Haley wrote:
Ian Lance Taylor writes:
Joe Buck [EMAIL PROTECTED] writes:
I suggest that those who think this is a severe problem are
the
ones who are highly motivated to work on a solution. An
efficient solution could be
On Tue, Jan 16, 2007 at 01:31:06PM -0800, David Daney wrote:
Andrew Haley wrote:
Ian Lance Taylor writes:
I suspect that the best fix, in the sense of generating the best
code, would be to do this at the tree level. That will give loop
and VRP optimizations the best chance to eliminate
Joe Buck [EMAIL PROTECTED] writes:
| On Tue, Jan 16, 2007 at 11:05:20AM -0800, David Daney wrote:
| Roberto Bagnara wrote:
|
| Hmmm, it says nothing about the remainder. Can some Google guru
| suggest how to prove or disprove the claim that what we are
| talking about is wildly known?
|
Gabriel Dos Reis [EMAIL PROTECTED] writes:
Ian, do you believe something along the line of
# I mean, could not we generate the following for %:
#
# rem a b :=
#if abs(b) == 1
# return 0
#return machine-instruction a b
#
# On x86 processors
On 2007-01-16 13:08:18 -0800, David Daney wrote:
The difference is that your program didn't get killed by SIGFPE, it
just gave incorrect results.
An incorrect result is worse, but being killed by SIGFPE is still very
bad.
But I was mainly answering the claim hard to believe this case appears
On 2007-01-16 21:27:42 +, Andrew Haley wrote:
Ian Lance Taylor writes:
I suspect that the best fix, in the sense of generating the best
code, would be to do this at the tree level. That will give loop
and VRP optimizations the best chance to eliminate the test for -1.
Doing it
Vincent Lefevre [EMAIL PROTECTED] writes:
| On 2007-01-16 13:41:16 -0800, Ian Lance Taylor wrote:
| To be clear, in my opinion, this should always be selected by an
| option, it should never be default behaviour for any target.
|
| I disagree. One should get correct results by default.
Once
Vincent Lefevre [EMAIL PROTECTED] writes:
| On 2007-01-16 13:41:16 -0800, Ian Lance Taylor wrote:
| To be clear, in my opinion, this should always be selected by an
| option, it should never be default behaviour for any target.
|
| I disagree. One should get correct results by
Andrew Pinski [EMAIL PROTECTED] writes:
|
| Vincent Lefevre [EMAIL PROTECTED] writes:
|
| | On 2007-01-16 13:41:16 -0800, Ian Lance Taylor wrote:
| | To be clear, in my opinion, this should always be selected by an
| | option, it should never be default behaviour for any target.
| |
|
On Tue, Jan 16, 2007 at 06:55:45PM -0500, Andrew Pinski wrote:
Vincent Lefevre [EMAIL PROTECTED] writes:
| On 2007-01-16 13:41:16 -0800, Ian Lance Taylor wrote:
| To be clear, in my opinion, this should always be selected by an
| option, it should never be default behaviour for any
Hi Roberto,
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family. Are there plans to
fix this bug (which, to
Roberto Bagnara writes:
Reading the thread Autoconf manual's coverage of signed integer
overflow portability I was horrified to discover about GCC's
miscompilation of the remainder expression that causes INT_MIN % -1
to cause a SIGFPE on CPUs of the i386 family. Are there plans to
Paolo Carlini writes:
I would like to understand the issue better, however...
What more is there to understand? It's an integer overflow. The
processor generates a trap on integer overflows during division
operations.
Andrew.
1 - 100 of 111 matches
Mail list logo
