Re: Miscompilation...

On Apr 8, 2007, at 11:35 PM, Dave Korn wrote: I believe I got the TOT -- .svn/entries says "svn://gcc.gnu.org/svn/ gcc/trunk". Is this a known problem? It's the first I've heard of it, please file a PR. I'm slightly amazed this hasn't been causing bootstrap breakage already, it looks real

RE: Miscompilation...

On 09 April 2007 02:51, Bill Wendling wrote: > (on my iMac). The problem seems to be that, in the TConvertType > function passes > "type->precision" as an HI instead of SI to the "bork" function. The > asm code is: > > movl $1104150528, (%esp) > movl$0, -4(%ebp) > m

Re: Miscompilation...

On Apr 8, 2007, at 6:50 PM, Bill Wendling wrote: Hi all, This program: #include struct tree_type { unsigned int precision : 9; }; void *bork(const void *Ty, unsigned Subpart) { printf("Subpart == %08x\n", Subpart); return 0; } const void *TConvertType(tree_type* type) { asm("movl $

Re: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

David Daney wrote: MIPS does *not* seem to suffer from this 'defect', [...] In my opinion, if this is not a defect, then the only thing that needs to be done is writing a few lines in some "Known Issues" section of the documentation. This because, at least for me, standard conformance is the f

Re: Miscompilation of remainder expressions

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 a given instruction? > > > >M. > >

Re: Miscompilation of remainder expressions

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 a given instruction? M. Sure it traps, but what happens when that trap occurs is of course O/S dependent, ther

Re: Miscompilation of remainder expressions

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.

Re: Miscompilation of remainder expressions

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 gene

Re: Miscompilation of remainder expressions

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,

Re: Miscompilation of remainder expressions

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 unimpor

Re: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

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 is receiving :-) > >> > >> I guess the diff

Re: Miscompilation of remainder expressions

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.

Re: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

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 doc

Re: Miscompilation of remainder expressions

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 translat

Re: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

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 def

Re: Miscompilation of remainder expressions

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 cha

Re: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

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 si

Re: Miscompilation of remainder expressions

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 ...

Re: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

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 that

Re: Miscompilation of remainder expressions

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 s

Re: Miscompilation of remainder expressions

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"

Re: Miscompilation of remainder expressions

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 gc

Re: Miscompilation of remainder expressions

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 reall

Re: Miscompilation of remainder expressions

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 thes

Re: Miscompilation of remainder expressions

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 re

Re: Miscompilation of remainder expressions

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 | >

Re: Miscompilation of remainder expressions

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 pe

Re: Miscompilation of remainder expressions

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 opi

RE: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

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 a

Re: Miscompilation of remainder expressions

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 d

Re: Miscompilation of remainder expressions

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'

Re: Miscompilation of remainder expressions

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. | > | >

Re: Miscompilation of remainder expressions

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 alter

Re: Miscompilation of remainder expressions

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. > | > >

Re: Miscompilation of remainder expressions

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 conveni

Re: Miscompilation of remainder expressions

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.

Re: Miscompilation of remainder expressions

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 G

Re: Miscompilation of remainder expressions

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 > > # >

Re: Miscompilation of remainder expressions

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 := | > > #

Re: Miscompilation of remainder expressions

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 > >

Re: Miscompilation of remainder expressions

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 > > > a

Re: Miscompilation of remainder expressions

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 be

Re: Miscompilation of remainder expressions

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 targ

Re: Miscompilation of remainder expressions

> > 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

Re: Miscompilation of remainder expressions

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. Onc

Re: Miscompilation of remainder expressions

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. -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web:

Re: Miscompilation of remainder expressions

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. > > Doi

Re: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

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 a b > # > # On x86 processors tha

Re: Miscompilation of remainder expressions

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 k

Re: Miscompilation of remainder expressions

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 t

Re: Miscompilation of remainder expressions

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 > > > > efficien

Re: Miscompilation of remainder expressions

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 > > pipe

Re: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

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 wit

Re: Miscompilation of remainder expressions

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 th

Re: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

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 SIGF

Re: Miscompilation of remainder expressions

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 wro

Re: Miscompilation of remainder expressions

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/

Re: Miscompilation of remainder expressions

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 that a bug

Re: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

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 by

Re: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

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 -- s

Re: Miscompilation of remainder expressions

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.

RE: Miscompilation of remainder expressions

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!)

Re: Miscompilation of remainder expressions

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 test

Re: Miscompilation of remainder expressions

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 l

Re: Miscompilation of remainder expressions

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

RE: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

David Daney wrote: Roberto Bagnara wrote: Everyone knows that dividing a number by -1 or 1 gives a 0 remainder. To the contrary, no one expects a%b to raise SIFPE when b != 0. On the contrary, since the beginning of time SIGFPE has been generated on GCC/x86/linux under these conditions. T

Re: Miscompilation of remainder expressions

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 div

Re: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

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 t

Re: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

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 | > > > misco

Re: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

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 a b On x86 processors that have conditional moves, why not do the equivalent of neg_b =

Re: Miscompilation of remainder expressions

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 tha

Re: Miscompilation of remainder expressions

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 SIGF

Re: Miscompilation of remainder expressions

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 ther

Re: Miscompilation of remainder expressions

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 bu

Re: Miscompilation of remainder expressions

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 bu

Re: Miscompilation of remainder expressions

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 rem

Re: Miscompilation of remainder expressions

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 & po

Re: Miscompilation of remainder expressions

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

Re: Miscompilation of remainder expressions

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 expres

Re: Miscompilation of remainder expressions

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 >

Re: Miscompilation of remainder expressions

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_MI

Re: Miscompilation of remainder expressions

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 f

Re: Miscompilation of remainder expressions

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 & po

  1   2   >