"Frederich, Eric P21322" wrote:
> You said that combining -march=i686 and -msse2 didn't make too much
> sense.
What I meant by that is that by specifying -msse2 you are setting the
bar a lot higher than -march=i686, generating code that won't run on a
number of i686 machines, so you might as well
> -Original Message-
> From: [EMAIL PROTECTED] On Behalf Of Brian Dessent
> Sent: Thursday, June 28, 2007 3:42 PM
> To: cygwin@cygwin.com
> Subject: Re: possible compiler optimization error
>
>
> But both of these are too new to be in Cygwin's gcc 3.4.x s
Mike Marchywka wrote:
> This doesn't have anything to do with cygwin but it can be an important
> point.
> Some compilers or applications , I think Intel IIRC, can figure out which
> processor you have
> at run time and pick which code to run- obviously the exe size gets large
> but
> if you need
"Frederich, Eric P21322" wrote:
> My using -march=i686 was because I couldn't find a list of all accepted
> values in the man page for gcc. After some googling I found that I can
> use -march=pentium-m for my Dell D600 Laptop. I am now happy to report
> that setting -march=pentium-m -O2 works fi
rian Dessent <[EMAIL PROTECTED]>
Reply-To: cygwin@cygwin.com
To: cygwin@cygwin.com
Subject: Re: possible compiler optimization error
Date: Thu, 28 Jun 2007 12:01:31 -0700
"Frederich, Eric P21322" wrote:
> I do realize that they may in fact differ way out there beyond 15
> decimal
> From: [EMAIL PROTECTED] On Behalf Of Brian Dessent
> Sent: Thursday, June 28, 2007 3:02 PM
> To: cygwin@cygwin.com
> Subject: Re: possible compiler optimization error
>
> I think Dave already explained it but in case it's not clear, on the
> i387, all floating po
"Frederich, Eric P21322" wrote:
> I do realize that they may in fact differ way out there beyond 15
> decimal places.
> What I don't understand is how two numbers pass a ==, then fail a >=,
> then pass a >= unless (after compiler optimizations) the second and
> third comparisons are actually compa
On 28 June 2007 19:28, Frederich, Eric P21322 wrote:
>> From: [EMAIL PROTECTED] On Behalf Of Brian Dessent
>> Sent: Thursday, June 28, 2007 1:53 PM
>> To: cygwin@cygwin.com
>> Subject: Re: possible compiler optimization error
>
> Thanks for looking at it.
> From: [EMAIL PROTECTED] On Behalf Of Dave Korn
> Sent: Thursday, June 28, 2007 1:39 PM
> To: cygwin@cygwin.com
> Subject: RE: possible compiler optimization error
>
> On 28 June 2007 18:19, Frederich, Eric P21322 wrote:
>
> Your code has a bug, most likely an uninitia
Send some disassembled code fragments- it should be pretty clear.
Or, you can probably cast and dump as hex/bin and see what is going on.
From: "Frederich, Eric P21322" <[EMAIL PROTECTED]>
To:
Subject: RE: possible compiler optimization error
Date: Thu, 28 Jun 200
> From: [EMAIL PROTECTED] On Behalf Of Brian Dessent
> Sent: Thursday, June 28, 2007 1:53 PM
> To: cygwin@cygwin.com
> Subject: Re: possible compiler optimization error
Thanks for looking at it. I am in unfamiliar water here.
> Try with -ffloat-store. Or if you have a sse2 cap
"Frederich, Eric P21322" wrote:
> If a program compiled with -O0 has different output than the same
> program compiled with -O1 or -O2, is that defiantly a compile error?
> I do realize that it could be a combination of compiler optimizations
> along with the platform's representation of floating
ook at the generated code to get some idea
what is going on but I would suspect precisions issues as much as
corruption/NaN etc.
From: "Dave Korn" <[EMAIL PROTECTED]>
To:
Subject: RE: possible compiler optimization error
Date: Thu, 28 Jun 2007 18:39:19 +0100
On 28 June 2007 18:
Frederich, Eric P21322 wrote, On 28.6.2007 19:18:
> On Windows I have found that a program I wrote fails when compiled with
> -O1 and -O2 but runs fine with -O0.
> The program behaves correctly on Linux and Solaris with or without
> optimizations.
>
> The place it starts behaving differently on
On 28 June 2007 18:19, Frederich, Eric P21322 wrote:
> On Windows I have found that a program I wrote fails when compiled with
> -O1 and -O2 but runs fine with -O0.
> The program behaves correctly on Linux and Solaris with or without
> optimizations.
Your code has a bug, most likely an uninitia
15 matches
Mail list logo
