Re: -Ofast/-ffast-math and SPEC 511.pov miscompilation with gcc 13.0

> Am 03.02.2023 um 19:47 schrieb Vineet Gupta : > >  >> On 2/2/23 23:36, Richard Biener wrote: >> There's a CLOSED INVALID bug in bugzilla >> about the povray failure as well. > > Thx for the pointer ! For the record it is > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107021 > > > The quest

Re: -Ofast/-ffast-math and SPEC 511.pov miscompilation with gcc 13.0

On 2/2/23 23:36, Richard Biener wrote: There's a CLOSED INVALID bug in bugzilla about the povray failure as well. Thx for the pointer ! For the record it is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107021 > The question is what to do with 511.povray_r as we want to support SPECs with -O

Re: -Ofast/-ffast-math and SPEC 511.pov miscompilation with gcc 13.0

On Fri, Feb 3, 2023 at 12:39 AM Vineet Gupta wrote: > > Hi, > > I've noticed SPEC 2017, 511.pov failing for RV64 on bleeding edge gcc. > This is with -Ofast -march=rv64gcv_zba_zbb_zbc_zbs. > Problem also happens with -O3 -ffast-math (and goes away with fast-math > removed) > > I've bisected it to

Re: -Ofast/-ffast-math and SPEC 511.pov miscompilation with gcc 13.0

On 2/2/23 15:38, Vineet Gupta wrote: Hi, I've noticed SPEC 2017, 511.pov failing for RV64 on bleeding edge gcc. This is with -Ofast -march=rv64gcv_zba_zbb_zbc_zbs. Problem also happens with -O3 -ffast-math (and goes away with fast-math removed) I've bisected it to b7fd7fb50111 ("frange: dr

-Ofast/-ffast-math and SPEC 511.pov miscompilation with gcc 13.0

Hi, I've noticed SPEC 2017, 511.pov failing for RV64 on bleeding edge gcc. This is with -Ofast -march=rv64gcv_zba_zbb_zbc_zbs. Problem also happens with -O3 -ffast-math (and goes away with fast-math removed) I've bisected it to b7fd7fb50111 ("frange: drop endpoints to min/max representable nu

Re: GCC 12 miscompilation of volatile asm (was: Re: [PATCH] arm64/io: Remind compiler that there is a memory side effect)

Hi, On 4/11/22 05:31, Mark Rutland wrote: On Tue, Apr 05, 2022 at 01:51:30PM +0100, Mark Rutland wrote: Hi all, [adding kernel folk who work on asm stuff] As a heads-up, GCC 12 (not yet released) appears to erroneously optimize away calls to functions with volatile asm. Szabolcs has raised a

Re: GCC 12 miscompilation of volatile asm (was: Re: [PATCH] arm64/io: Remind compiler that there is a memory side effect)

On Tue, Apr 05, 2022 at 01:51:30PM +0100, Mark Rutland wrote: > Hi all, > > [adding kernel folk who work on asm stuff] > > As a heads-up, GCC 12 (not yet released) appears to erroneously optimize away > calls to functions with volatile asm. Szabolcs has raised an issue on the GCC > bugzilla: >

Re: GCC 12 miscompilation of volatile asm (was: Re: [PATCH] arm64/io: Remind compiler that there is a memory side effect)

On Tue, Apr 05, 2022 at 04:05:22PM +0200, Peter Zijlstra wrote: > On Tue, Apr 05, 2022 at 01:51:30PM +0100, Mark Rutland wrote: > > Hi all, > > > > [adding kernel folk who work on asm stuff] > > > > As a heads-up, GCC 12 (not yet released) appears to erroneously optimize > > away > > calls to fu

Re: GCC 12 miscompilation of volatile asm (was: Re: [PATCH] arm64/io: Remind compiler that there is a memory side effect)

On Tue, Apr 05, 2022 at 01:51:30PM +0100, Mark Rutland wrote: > Hi all, > > [adding kernel folk who work on asm stuff] > > As a heads-up, GCC 12 (not yet released) appears to erroneously optimize away > calls to functions with volatile asm. Szabolcs has raised an issue on the GCC > bugzilla: >

Re: GCC 12 miscompilation of volatile asm (was: Re: [PATCH] arm64/io: Remind compiler that there is a memory side effect)

On 05/04/2022 14:04, Mark Rutland wrote: > On Tue, Apr 05, 2022 at 01:51:30PM +0100, Mark Rutland wrote: > My x86_64 test case is: > > Per compiler explorer (https://godbolt.org/z/cveff9hq5) GCC trunk currently > compiles this as: > > | msr_rmw_set_bits: > | mov rcx, rdi > | rdm

Re: GCC 12 miscompilation of volatile asm (was: Re: [PATCH] arm64/io: Remind compiler that there is a memory side effect)

Sorry, I copied the wrong version of the x86_64 assembly as generated by GCC 11.2.0). Updated below. On Tue, Apr 05, 2022 at 01:51:30PM +0100, Mark Rutland wrote: > My x86_64 test case is: > > | unsigned long rdmsr(unsigned long reg) > | { > | unsigned int lo, hi; > | > | asm volatile( >

GCC 12 miscompilation of volatile asm (was: Re: [PATCH] arm64/io: Remind compiler that there is a memory side effect)

Hi all, [adding kernel folk who work on asm stuff] As a heads-up, GCC 12 (not yet released) appears to erroneously optimize away calls to functions with volatile asm. Szabolcs has raised an issue on the GCC bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105160 ... which is a P1 rele

Re: Tracking the source of an ARM miscompilation with gcc 4.6

On Thu, Mar 07, 2013 at 11:34:30AM +0100, Mikael Pettersson wrote: > > > This test case is not self-contained. Please file a proper bug report > > > with a self-contained test case. > > > > It is, as long as you don't want to make a library or program out of it: > > > > $ arm-linux-android

Re: Tracking the source of an ARM miscompilation with gcc 4.6

> > > > On Thu, Mar 07, 2013 at 12:28:22AM -0800, Andrew Pinski wrote: > > > > >> On Thu, Mar 7, 2013 at 12:24 AM, Mike Hommey > > wrote: > > > > >> > Hi, > > > > >> > > > > > >> > At

Re: Tracking the source of an ARM miscompilation with gcc 4.6

2AM -0800, Andrew Pinski wrote: > > > >> On Thu, Mar 7, 2013 at 12:24 AM, Mike Hommey > wrote: > > > >> > Hi, > > > >> > > > > >> > At Mozilla, we've encountered a GCC 4.6 miscompilation in the ARMv6 > > > >> &

Re: Tracking the source of an ARM miscompilation with gcc 4.6

> > >> wrote: > > >> > Hi, > > >> > > > >> > At Mozilla, we've encountered a GCC 4.6 miscompilation in the ARMv6 > > >> > build of Firefox for Android. We'd like to evaluate whether this bug > > >>

Re: Tracking the source of an ARM miscompilation with gcc 4.6

On Thu, Mar 7, 2013 at 12:33 AM, Mike Hommey wrote: > On Thu, Mar 07, 2013 at 12:28:22AM -0800, Andrew Pinski wrote: >> On Thu, Mar 7, 2013 at 12:24 AM, Mike Hommey wrote: >> > Hi, >> > >> > At Mozilla, we've encountered a GCC 4.6 miscompilation in th

Re: Tracking the source of an ARM miscompilation with gcc 4.6

On Thu, Mar 7, 2013 at 12:24 AM, Mike Hommey wrote: > Hi, > > At Mozilla, we've encountered a GCC 4.6 miscompilation in the ARMv6 > build of Firefox for Android. We'd like to evaluate whether this bug is > hitting us in more places than the one we spotted. To that end,

Tracking the source of an ARM miscompilation with gcc 4.6

Hi, At Mozilla, we've encountered a GCC 4.6 miscompilation in the ARMv6 build of Firefox for Android. We'd like to evaluate whether this bug is hitting us in more places than the one we spotted. To that end, we'd need to know what particular bug in GCC leads to this miscompilation

ARM miscompilation of __moddi3 on trunk

This simple test case: #include int ten = 10; int main() { printf ("%lld\n", 92233720368547758LL % ten); return 0; } returns 0 because (afaics) __moddi3 is miscompiled. Breakpoint 4, __moddi3 (u=92233720368547758, v=10) at /home/aph/gcc/trunk/libgcc/../gcc/libgcc2.c:923 (gdb) fin Ru

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 $

Miscompilation...

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 $1104150528, (%%esp)" : : ); const void *Ty = 0;

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

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 expr

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 caus

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 rema

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

  1   2   >