public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization/10189: pentium4 breaks suns libm code for __ieee754_pow(double x, double y)
@ 2003-05-15 14:32 bangerth
  0 siblings, 0 replies; 6+ messages in thread
From: bangerth @ 2003-05-15 14:32 UTC (permalink / raw)
  To: freebsd-current, gcc-bugs, gcc-prs, nobody, till

Synopsis: pentium4 breaks suns libm code for __ieee754_pow(double x, double y)

State-Changed-From-To: feedback->closed
State-Changed-By: bangerth
State-Changed-When: Thu May 15 14:32:07 2003
State-Changed-Why:
    Reported fixed:
      http://gcc.gnu.org/ml/gcc-bugs/2003-05/msg01365.html

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10189


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: optimization/10189: pentium4 breaks suns libm code for __ieee754_pow(double x, double y)
@ 2003-03-29  4:06 David O'Brien
  0 siblings, 0 replies; 6+ messages in thread
From: David O'Brien @ 2003-03-29  4:06 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR optimization/10189; it has been noted by GNATS.

From: "David O'Brien" <obrien@freebsd.org>
To: Alexander Leidinger <Alexander@Leidinger.net>
Cc: gcc-gnats@gcc.gnu.org, freebsd-current@freebsd.org, gcc-bugs@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, ljrittle@gcc.gnu.org
Subject: Re: optimization/10189: pentium4 breaks suns libm code for __ieee754_pow(double x, double y)
Date: Fri, 28 Mar 2003 19:46:27 -0800

 On Wed, Mar 26, 2003 at 10:09:34PM +0100, Alexander Leidinger wrote:
 > And trust me, as long as gcc ships with a description of other
 > optimizations beneath "-O" there will be (clueless or smart... does it
 > really matter here?) people which will try those optimizations on
 > everything
 
 Not to mention bullshit ones like "-O9".  I see that all the time.  What
 do these poeple think they are buying with that?????
 
 GCC should stop accepting -O values higher than what does anything.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: optimization/10189: pentium4 breaks suns libm code for __ieee754_pow(double x, double y)
@ 2003-03-26 21:27 Alexander Leidinger
  0 siblings, 0 replies; 6+ messages in thread
From: Alexander Leidinger @ 2003-03-26 21:27 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR optimization/10189; it has been noted by GNATS.

From: Alexander Leidinger <Alexander@Leidinger.net>
To: gcc-gnats@gcc.gnu.org
Cc: ljrittle@gcc.gnu.org, freebsd-current@freebsd.org, gcc-bugs@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, till@f111.hadiko.de
Subject: Re: optimization/10189: pentium4 breaks suns libm code for
 __ieee754_pow(double x, double y)
Date: Wed, 26 Mar 2003 22:09:34 +0100

 On 26 Mar 2003 13:01:18 -0000
 ljrittle@gcc.gnu.org wrote:
 
 > Synopsis: pentium4 breaks suns libm code for __ieee754_pow(double x, double y)
 
 [...]
 
 >  FreeBSD src tree; and (c) that really cares about building FreeBSD
 >  src with special CPU settings (do you guys really see enough speedup
 >  to warrant this extra nightmare? ;-)
 
 Without knowing anything about the FreeBSD related PRs in the gcc PR
 database I just comment on the last part of the quoted sentence...
 
 The official "allowed" optimization is "-O". But it is as easy as
 setting 'CFLAGS=-my-special-optim' in /etc/make.conf and start "make
 buildworld" in /usr/src to rebuild the userland with new optimizations.
 And trust me, as long as gcc ships with a description of other
 optimizations beneath "-O" there will be (clueless or smart... does it
 really matter here?) people which will try those optimizations on
 everything (after I managed to convince the Linux version of icc to
 generate FreeBSD object files and committed a port into our ports
 collection one of the first questions was "Are we are able to build the
 userland/kernel with it?", and now after icc is also able to link files
 without the help of gcc they ask "How much does it gain us to build the
 userland/kernel with icc?", even if it isn't possible to use icc to
 build the entire (or even large parts of the) kernel/userland yet). So
 it isn't a matter of "does it improve things if I do it this way" or "is
 it possible to do it this way", it's a matter of "how many PRs does it
 generate when -march=pentium4 breaks something but other -march=pentiumX
 optimizations don't"...
 
 Thanks for your insightful mail,
 Alexander.
 
 -- 
             0 and 1. Now what could be so hard about that?
 
 http://www.Leidinger.net                       Alexander @ Leidinger.net
   GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: optimization/10189: pentium4 breaks suns libm code for __ieee754_pow(double x, double y)
@ 2003-03-26 18:06 David O'Brien
  0 siblings, 0 replies; 6+ messages in thread
From: David O'Brien @ 2003-03-26 18:06 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR optimization/10189; it has been noted by GNATS.

From: "David O'Brien" <obrien@freebsd.org>
To: ljrittle@gcc.gnu.org, freebsd-current@freebsd.org, gcc-bugs@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, till@f111.hadiko.de,
   gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: optimization/10189: pentium4 breaks suns libm code for __ieee754_pow(double x, double y)
Date: Wed, 26 Mar 2003 09:45:35 -0800

 On Wed, Mar 26, 2003 at 01:01:18PM -0000, ljrittle@gcc.gnu.org wrote:
 > Synopsis: pentium4 breaks suns libm code for __ieee754_pow(double x, double y)
 
 Beautiful email!!
  
 >     Special secret #2:  Although the FSF-side does want to improve all
 >     code generation (and I think proper PRs RE CPU switches will be
 >     looked at by someone given enough time) be aware that -O2 without
 >     special arch flags is probably the most stable for any given CPU
 >     for any given gcc release.  Do you really want to trust a kernel
 >     built with optimization flags and arch flags that near zero or zero
 >     people have fully tested?  Doubtful.  However, inline with secret
 >     #1 and by virtual of being digital, if even one person tests it
 >     (i.e. yourself) and it appears OK, then it is probably safe to at
 >     least attempt to build a kernel and run it.
 
 FreeBSD has for years recommended -O[1] vs. -O2.  Do you think there is
 value in having the GCC test suite runs you do at FreeBSD.org do runs
 with both settings?  To also do runs with the newer CPU types?


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: optimization/10189: pentium4 breaks suns libm code for __ieee754_pow(double x, double y)
@ 2003-03-26 14:02 ljrittle
  0 siblings, 0 replies; 6+ messages in thread
From: ljrittle @ 2003-03-26 14:02 UTC (permalink / raw)
  To: freebsd-current, gcc-bugs, gcc-prs, nobody, till

Synopsis: pentium4 breaks suns libm code for __ieee754_pow(double x, double y)

State-Changed-From-To: open->feedback
State-Changed-By: ljrittle
State-Changed-When: Wed Mar 26 13:01:17 2003
State-Changed-Why:
    (Noting where this response was set to go, I decided to indulged to send an updated general statement on this matter of when it is even sane to set the exact CPU.  It is not my goal to stop the flow of related PRs from the crowd@freebsd.org to the crowd@gcc.gnu.org.  Rather, I hope it will help those that bother to read and fully understand it since there is a minor disconnect between expectations and SOPs.  I feel I know much less about any one piece than many others, but I think there is a basic outline of steps and points of information that will help improve the PR flow from freebsd.org to gcc.gnu.org.  I am speaking for myself here but I am speaking after having personally gone through all the open PRs registered in the gcc GNATs which matched FreeBSD.)
    
    FYI, this PR (which looks somewhat important to me) would probably not be looked at by anyone at this end since it is in the wrong form.  The PR submitter that helps himself gets more help. (This is the same informal rule as the freebsd.org side but you must assume that people that can really help you at this end don't even have full and direct access to freebsd-src.  I estimate that maybe 3 people who read gcc.gnu.org GNATs will have the access and the skill set to review a freebsd PR which requires any construction; however, if it is a CPU-specific problem or in any way "below the libc" line, then the number drops to about 1 or more likely zero.)  You need to provide a complete, self-contained test case (this usually means "preprocessed").  Once you do that, the number of people that can easily look at your test case increases *greatly* (anything over 0 is a great increase ;-).  Now, in this particular case, I'd be capable of putting it in the right form and reposting it since I have the freebsd-src CVS repo handy; however, I am not capable of seeing the problem since I don't have a P4 (thus nor the real motivation).  Someone with (a) a P4; (b) easy access to full FreeBSD src tree; and (c) that really cares about building FreeBSD src with special CPU settings (do you guys really see enough speedup to warrant this extra nightmare? ;-)
    
    I will now reveal the special secret #1: Have you (I mean all of you that wish to build FreeBSD kernels, libm, libc and/or FreeBSD applications with non-standard CPU settings) actually run the entire gcc testsuite with the extra CPU options?  I suggest that if you see *any* extra failures between 'make -sk check' and e.g.
    make -sk check 'RUNTESTFLAGS=--target_board unix{-march=pentium4}'
    then it is quite likely you have a basic problem to address before you ever possibly consider trusting a kernel, library or application built with the pet CPU switch.  As a bonus, your test case is much smaller.  E.g. (no basis in fact) "gcc.dg/20011214-1.c fails with -march=pentium4"
    is a very concise statement of a problem.  A gcc maintainer that cares about, e.g. P4 but perhaps not FreeBSD, may take an interest in that report whereas "pentium4 breaks suns libm code for __ieee754_pow"
    really has little or no contextual meaning over here especially when the referred test case is not easy to assemble outside your environment.  It might also be the case that there is a problem with the mapping to the arch-layer in gcc from the OS-support layer that is royally breaking just one CPU (it has been known to happen ;-).  If you run the testsuite, then it will stick out like like a sore thumb.  Now, I grant it is possible that there will be no extra gcc testsuite failures for a CPU arch flag even when the kernel would be subtly broken when built with that arch flag.  This is actually unlikely in my experience, a whole profile of gcc test cases will light up when I break something.
    
    Special secret #2:  Although the FSF-side does want to improve all code generation (and I think proper PRs RE CPU switches will be looked at by someone given enough time) be aware that -O2 without special arch flags is probably the most stable for any given CPU for any given gcc release.  Do you really want to trust a kernel built with optimization flags and arch flags that near zero or zero people have fully tested?  Doubtful.  However, inline with secret #1 and by virtual of being digital, if even one person tests it (i.e. yourself) and it appears OK, then it is probably safe to at least attempt to build a kernel and run it.
    
    Perhaps I have a misconception but are the mass of people attempting
    to build random applications from ports or libraries or the kernel with special flags actually first testing as I propose above?  I have to doubt it given the form of PR submissions.  What looks like a bit of extra work on your end (actually testing the base compiler with the exact flags you want to use), will actually come back ten-fold in my experience since most of the testing is automatic once you set it up once.
    
    Ah, final though. If you do manage to find the CPU bug that is not covered by the testsuite, then by all means prepare a new test case in the self-contained form that people on other OSes (but same CPU) can test.  Once you do that, the bug will probably be fixed in a matter of time.
    
    Regards,
    Loren
    
    PS, I realize I have left how you actually run the testsuite unsaid.  I grant this is a little complex (it is not as simple as installing and running
    a FreeBSD port or a port's Makefile yet, last I looked).  It is possible that we need to do some more basic work to make it trivial for those people that want to build a FreeBSD kernel against the system compiler with non-standard CPU flags to first run the compiler testsuite against said system compiler.  Really, IMHO, it is almost unsafe at any speed to skip that step unless you are sure someone (i.e. you) ran the testsuite with the CPU flags of interest.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10189


^ permalink raw reply	[flat|nested] 6+ messages in thread

* optimization/10189: pentium4 breaks suns libm code for __ieee754_pow(double x, double y)
@ 2003-03-22 12:46 till
  0 siblings, 0 replies; 6+ messages in thread
From: till @ 2003-03-22 12:46 UTC (permalink / raw)
  To: gcc-gnats; +Cc: freebsd-current


>Number:         10189
>Category:       optimization
>Synopsis:       pentium4 breaks suns libm code for __ieee754_pow(double x, double y)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Sat Mar 22 12:46:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Mikhail Teterin <mi@aldan.algebra.com>
>Release:        gcc version 3.2.1 [FreeBSD] 20021119 (release)
>Organization:
>Environment:
FreeBSD 5.x
>Description:
pow function will return 0x0 (double 1) when compiled with -march=pentium4 and -O
see also http://www.freebsd.org/cgi/query-pr.cgi?pr=43299
>How-To-Repeat:
compile libm and call pow or  __ieee754_pow
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="e_pow.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="e_pow.c"

LyogQCgjKWVfcG93LmMgNS4xIDkzLzA5LzI0ICovCi8qCiAqID09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KICogQ29weXJpZ2h0IChDKSAxOTkzIGJ5
IFN1biBNaWNyb3N5c3RlbXMsIEluYy4gQWxsIHJpZ2h0cyByZXNlcnZlZC4KICoKICogRGV2ZWxv
cGVkIGF0IFN1blBybywgYSBTdW4gTWljcm9zeXN0ZW1zLCBJbmMuIGJ1c2luZXNzLgogKiBQZXJt
aXNzaW9uIHRvIHVzZSwgY29weSwgbW9kaWZ5LCBhbmQgZGlzdHJpYnV0ZSB0aGlzCiAqIHNvZnR3
YXJlIGlzIGZyZWVseSBncmFudGVkLCBwcm92aWRlZCB0aGF0IHRoaXMgbm90aWNlCiAqIGlzIHBy
ZXNlcnZlZC4KICogPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PQogKi8KCiNpZm5kZWYgbGludApzdGF0aWMgY2hhciByY3NpZFtdID0gIiRGcmVlQlNE
OiBzcmMvbGliL21zdW4vc3JjL2VfcG93LmMsdiAxLjkgMjAwMi8wNi8xNyAxNToyODo1OSBiZGUg
RXhwICQiOwojZW5kaWYKCi8qIF9faWVlZTc1NF9wb3coeCx5KSByZXR1cm4geCoqeQogKgogKgkJ
ICAgICAgbgogKiBNZXRob2Q6ICBMZXQgeCA9ICAyICAgKiAoMStmKQogKgkxLiBDb21wdXRlIGFu
ZCByZXR1cm4gbG9nMih4KSBpbiB0d28gcGllY2VzOgogKgkJbG9nMih4KSA9IHcxICsgdzIsCiAq
CSAgIHdoZXJlIHcxIGhhcyA1My0yNCA9IDI5IGJpdCB0cmFpbGluZyB6ZXJvcy4KICoJMi4gUGVy
Zm9ybSB5KmxvZzIoeCkgPSBuK3knIGJ5IHNpbXVsYXRpbmcgbXV0aS1wcmVjaXNpb24KICoJICAg
YXJpdGhtZXRpYywgd2hlcmUgfHknfDw9MC41LgogKgkzLiBSZXR1cm4geCoqeSA9IDIqKm4qZXhw
KHknKmxvZzIpCiAqCiAqIFNwZWNpYWwgY2FzZXM6CiAqCTEuICAoYW55dGhpbmcpICoqIDAgIGlz
IDEKICoJMi4gIChhbnl0aGluZykgKiogMSAgaXMgaXRzZWxmCiAqCTMuICAoYW55dGhpbmcpICoq
IE5BTiBpcyBOQU4KICoJNC4gIE5BTiAqKiAoYW55dGhpbmcgZXhjZXB0IDApIGlzIE5BTgogKgk1
LiAgKy0ofHh8ID4gMSkgKiogICtJTkYgaXMgK0lORgogKgk2LiAgKy0ofHh8ID4gMSkgKiogIC1J
TkYgaXMgKzAKICoJNy4gICstKHx4fCA8IDEpICoqICArSU5GIGlzICswCiAqCTguICArLSh8eHwg
PCAxKSAqKiAgLUlORiBpcyArSU5GCiAqCTkuICArLTEgICAgICAgICAqKiArLUlORiBpcyBOQU4K
ICoJMTAuICswICoqICgrYW55dGhpbmcgZXhjZXB0IDAsIE5BTikgICAgICAgICAgICAgICBpcyAr
MAogKgkxMS4gLTAgKiogKCthbnl0aGluZyBleGNlcHQgMCwgTkFOLCBvZGQgaW50ZWdlcikgIGlz
ICswCiAqCTEyLiArMCAqKiAoLWFueXRoaW5nIGV4Y2VwdCAwLCBOQU4pICAgICAgICAgICAgICAg
aXMgK0lORgogKgkxMy4gLTAgKiogKC1hbnl0aGluZyBleGNlcHQgMCwgTkFOLCBvZGQgaW50ZWdl
cikgIGlzICtJTkYKICoJMTQuIC0wICoqIChvZGQgaW50ZWdlcikgPSAtKCArMCAqKiAob2RkIGlu
dGVnZXIpICkKICoJMTUuICtJTkYgKiogKCthbnl0aGluZyBleGNlcHQgMCxOQU4pIGlzICtJTkYK
ICoJMTYuICtJTkYgKiogKC1hbnl0aGluZyBleGNlcHQgMCxOQU4pIGlzICswCiAqCTE3LiAtSU5G
ICoqIChhbnl0aGluZykgID0gLTAgKiogKC1hbnl0aGluZykKICoJMTguICgtYW55dGhpbmcpICoq
IChpbnRlZ2VyKSBpcyAoLTEpKiooaW50ZWdlcikqKCthbnl0aGluZyoqaW50ZWdlcikKICoJMTku
ICgtYW55dGhpbmcgZXhjZXB0IDAgYW5kIGluZikgKiogKG5vbi1pbnRlZ2VyKSBpcyBOQU4KICoK
ICogQWNjdXJhY3k6CiAqCXBvdyh4LHkpIHJldHVybnMgeCoqeSBuZWFybHkgcm91bmRlZC4gSW4g
cGFydGljdWxhcgogKgkJCXBvdyhpbnRlZ2VyLGludGVnZXIpCiAqCWFsd2F5cyByZXR1cm5zIHRo
ZSBjb3JyZWN0IGludGVnZXIgcHJvdmlkZWQgaXQgaXMKICoJcmVwcmVzZW50YWJsZS4KICoKICog
Q29uc3RhbnRzIDoKICogVGhlIGhleGFkZWNpbWFsIHZhbHVlcyBhcmUgdGhlIGludGVuZGVkIG9u
ZXMgZm9yIHRoZSBmb2xsb3dpbmcKICogY29uc3RhbnRzLiBUaGUgZGVjaW1hbCB2YWx1ZXMgbWF5
IGJlIHVzZWQsIHByb3ZpZGVkIHRoYXQgdGhlCiAqIGNvbXBpbGVyIHdpbGwgY29udmVydCBmcm9t
IGRlY2ltYWwgdG8gYmluYXJ5IGFjY3VyYXRlbHkgZW5vdWdoCiAqIHRvIHByb2R1Y2UgdGhlIGhl
eGFkZWNpbWFsIHZhbHVlcyBzaG93bi4KICovCgojaW5jbHVkZSAibWF0aC5oIgojaW5jbHVkZSAi
bWF0aF9wcml2YXRlLmgiCgpzdGF0aWMgY29uc3QgZG91YmxlCmJwW10gPSB7MS4wLCAxLjUsfSwK
ZHBfaFtdID0geyAwLjAsIDUuODQ5NjI0ODcyMjA3NjQxNjAxNTZlLTAxLH0sIC8qIDB4M0ZFMkI4
MDMsIDB4NDAwMDAwMDAgKi8KZHBfbFtdID0geyAwLjAsIDEuMzUwMDM5MjAyMTI5NzQ4OTcxMjhl
LTA4LH0sIC8qIDB4M0U0Q0ZERUIsIDB4NDNDRkQwMDYgKi8KemVybyAgICA9ICAwLjAsCm9uZQk9
ICAxLjAsCnR3bwk9ICAyLjAsCnR3bzUzCT0gIDkwMDcxOTkyNTQ3NDA5OTIuMCwJLyogMHg0MzQw
MDAwMCwgMHgwMDAwMDAwMCAqLwpodWdlCT0gIDEuMGUzMDAsCnRpbnkgICAgPSAgMS4wZS0zMDAs
CgkvKiBwb2x5IGNvZWZzIGZvciAoMy8yKSoobG9nKHgpLTJzLTIvMypzKiozICovCkwxICA9ICA1
Ljk5OTk5OTk5OTk5OTk0NjQ4NzI1ZS0wMSwgLyogMHgzRkUzMzMzMywgMHgzMzMzMzMwMyAqLwpM
MiAgPSAgNC4yODU3MTQyODU3ODU1MDE4NDI1MmUtMDEsIC8qIDB4M0ZEQjZEQjYsIDB4REI2RkFC
RkYgKi8KTDMgID0gIDMuMzMzMzMzMjk4MTgzNzc0MzI5MThlLTAxLCAvKiAweDNGRDU1NTU1LCAw
eDUxOEYyNjREICovCkw0ICA9ICAyLjcyNzI4MTIzODA4NTM0MDA2NDg5ZS0wMSwgLyogMHgzRkQx
NzQ2MCwgMHhBOTFENDEwMSAqLwpMNSAgPSAgMi4zMDY2MDc0NTc3NTU2MTc1NDA2N2UtMDEsIC8q
IDB4M0ZDRDg2NEEsIDB4OTNDOURCNjUgKi8KTDYgID0gIDIuMDY5NzUwMTc4MDAzMzg0MTc3ODRl
LTAxLCAvKiAweDNGQ0E3RTI4LCAweDRBNDU0RUVGICovClAxICAgPSAgMS42NjY2NjY2NjY2NjY2
NjAxOTAzN2UtMDEsIC8qIDB4M0ZDNTU1NTUsIDB4NTU1NTU1M0UgKi8KUDIgICA9IC0yLjc3Nzc3
Nzc3NzcwMTU1OTMzODQyZS0wMywgLyogMHhCRjY2QzE2QywgMHgxNkJFQkQ5MyAqLwpQMyAgID0g
IDYuNjEzNzU2MzIxNDM3OTM0MzYxMTdlLTA1LCAvKiAweDNGMTE1NjZBLCAweEFGMjVERTJDICov
ClA0ICAgPSAtMS42NTMzOTAyMjA1NDY1MjUxNTM5MGUtMDYsIC8qIDB4QkVCQkJENDEsIDB4QzVE
MjZCRjEgKi8KUDUgICA9ICA0LjEzODEzNjc5NzA1NzIzODQ2MDM5ZS0wOCwgLyogMHgzRTY2Mzc2
OSwgMHg3MkJFQTREMCAqLwpsZzIgID0gIDYuOTMxNDcxODA1NTk5NDUyODYyMjdlLTAxLCAvKiAw
eDNGRTYyRTQyLCAweEZFRkEzOUVGICovCmxnMl9oICA9ICA2LjkzMTQ3MTgyNDY0NTk5NjA5Mzc1
ZS0wMSwgLyogMHgzRkU2MkU0MywgMHgwMDAwMDAwMCAqLwpsZzJfbCAgPSAtMS45MDQ2NTQyOTk5
NTc3NjgwNDUyNWUtMDksIC8qIDB4QkUyMDVDNjEsIDB4MENBODZDMzkgKi8Kb3Z0ID0gIDguMDA4
NTY2MjU5NTM3Mjk0NDM3MmUtMDAxNywgLyogLSgxMDI0LWxvZzIob3ZmbCsuNXVscCkpICovCmNw
ICAgID0gIDkuNjE3OTY2OTM5MjU5NzU1NTQzMjllLTAxLCAvKiAweDNGRUVDNzA5LCAweERDM0Ew
M0ZEID0yLygzbG4yKSAqLwpjcF9oICA9ICA5LjYxNzk2NzAwOTU0NDM3MjU1ODU5ZS0wMSwgLyog
MHgzRkVFQzcwOSwgMHhFMDAwMDAwMCA9KGZsb2F0KWNwICovCmNwX2wgID0gLTcuMDI4NDYxNjUw
OTUyNzU4MjY1MTZlLTA5LCAvKiAweEJFM0UyRkUwLCAweDE0NUIwMUY1ID10YWlsIG9mIGNwX2gq
LwppdmxuMiAgICA9ICAxLjQ0MjY5NTA0MDg4ODk2MzM4NzAwZSswMCwgLyogMHgzRkY3MTU0Nywg
MHg2NTJCODJGRSA9MS9sbjIgKi8KaXZsbjJfaCAgPSAgMS40NDI2OTUwMjE2MjkzMzM0OTYwOWUr
MDAsIC8qIDB4M0ZGNzE1NDcsIDB4NjAwMDAwMDAgPTI0YiAxL2xuMiovCml2bG4yX2wgID0gIDEu
OTI1OTYyOTkxMTI2NjE3NDY4ODdlLTA4OyAvKiAweDNFNTRBRTBCLCAweEY4NURERjQ0ID0xL2xu
MiB0YWlsKi8KCmRvdWJsZQpfX2llZWU3NTRfcG93KGRvdWJsZSB4LCBkb3VibGUgeSkKewoJZG91
YmxlIHosYXgsel9oLHpfbCxwX2gscF9sOwoJZG91YmxlIHkxLHQxLHQyLHIscyx0LHUsdix3OwoJ
aW50MzJfdCBpLGosayx5aXNpbnQsbjsKCWludDMyX3QgaHgsaHksaXgsaXk7Cgl1X2ludDMyX3Qg
bHgsbHk7CgoJRVhUUkFDVF9XT1JEUyhoeCxseCx4KTsKCUVYVFJBQ1RfV09SRFMoaHksbHkseSk7
CglpeCA9IGh4JjB4N2ZmZmZmZmY7ICBpeSA9IGh5JjB4N2ZmZmZmZmY7CgogICAgLyogeT09emVy
bzogeCoqMCA9IDEgKi8KCWlmKChpeXxseSk9PTApIHJldHVybiBvbmU7CgogICAgLyogKy1OYU4g
cmV0dXJuIHgreSAqLwoJaWYoaXggPiAweDdmZjAwMDAwIHx8ICgoaXg9PTB4N2ZmMDAwMDApJiYo
bHghPTApKSB8fAoJICAgaXkgPiAweDdmZjAwMDAwIHx8ICgoaXk9PTB4N2ZmMDAwMDApJiYobHkh
PTApKSkKCQlyZXR1cm4geCt5OwoKICAgIC8qIGRldGVybWluZSBpZiB5IGlzIGFuIG9kZCBpbnQg
d2hlbiB4IDwgMAogICAgICogeWlzaW50ID0gMAkuLi4geSBpcyBub3QgYW4gaW50ZWdlcgogICAg
ICogeWlzaW50ID0gMQkuLi4geSBpcyBhbiBvZGQgaW50CiAgICAgKiB5aXNpbnQgPSAyCS4uLiB5
IGlzIGFuIGV2ZW4gaW50CiAgICAgKi8KCXlpc2ludCAgPSAwOwoJaWYoaHg8MCkgewoJICAgIGlm
KGl5Pj0weDQzNDAwMDAwKSB5aXNpbnQgPSAyOyAvKiBldmVuIGludGVnZXIgeSAqLwoJICAgIGVs
c2UgaWYoaXk+PTB4M2ZmMDAwMDApIHsKCQlrID0gKGl5Pj4yMCktMHgzZmY7CSAgIC8qIGV4cG9u
ZW50ICovCgkJaWYoaz4yMCkgewoJCSAgICBqID0gbHk+Pig1Mi1rKTsKCQkgICAgaWYoKGo8PCg1
Mi1rKSk9PWx5KSB5aXNpbnQgPSAyLShqJjEpOwoJCX0gZWxzZSBpZihseT09MCkgewoJCSAgICBq
ID0gaXk+PigyMC1rKTsKCQkgICAgaWYoKGo8PCgyMC1rKSk9PWl5KSB5aXNpbnQgPSAyLShqJjEp
OwoJCX0KCSAgICB9Cgl9CgogICAgLyogc3BlY2lhbCB2YWx1ZSBvZiB5ICovCglpZihseT09MCkg
ewoJICAgIGlmIChpeT09MHg3ZmYwMDAwMCkgewkvKiB5IGlzICstaW5mICovCgkgICAgICAgIGlm
KCgoaXgtMHgzZmYwMDAwMCl8bHgpPT0wKQoJCSAgICByZXR1cm4gIHkgLSB5OwkvKiBpbmYqKist
MSBpcyBOYU4gKi8KCSAgICAgICAgZWxzZSBpZiAoaXggPj0gMHgzZmYwMDAwMCkvKiAofHh8PjEp
KiorLWluZiA9IGluZiwwICovCgkJICAgIHJldHVybiAoaHk+PTApPyB5OiB6ZXJvOwoJICAgICAg
ICBlbHNlCQkJLyogKHx4fDwxKSoqLSwraW5mID0gaW5mLDAgKi8KCQkgICAgcmV0dXJuIChoeTww
KT8teTogemVybzsKCSAgICB9CgkgICAgaWYoaXk9PTB4M2ZmMDAwMDApIHsJLyogeSBpcyAgKy0x
ICovCgkJaWYoaHk8MCkgcmV0dXJuIG9uZS94OyBlbHNlIHJldHVybiB4OwoJICAgIH0KCSAgICBp
ZihoeT09MHg0MDAwMDAwMCkgcmV0dXJuIHgqeDsgLyogeSBpcyAgMiAqLwoJICAgIGlmKGh5PT0w
eDNmZTAwMDAwKSB7CS8qIHkgaXMgIDAuNSAqLwoJCWlmKGh4Pj0wKQkvKiB4ID49ICswICovCgkJ
cmV0dXJuIF9faWVlZTc1NF9zcXJ0KHgpOwoJICAgIH0KCX0KCglheCAgID0gZmFicyh4KTsKICAg
IC8qIHNwZWNpYWwgdmFsdWUgb2YgeCAqLwoJaWYobHg9PTApIHsKCSAgICBpZihpeD09MHg3ZmYw
MDAwMHx8aXg9PTB8fGl4PT0weDNmZjAwMDAwKXsKCQl6ID0gYXg7CQkJLyp4IGlzICstMCwrLWlu
ZiwrLTEqLwoJCWlmKGh5PDApIHogPSBvbmUvejsJLyogeiA9ICgxL3x4fCkgKi8KCQlpZihoeDww
KSB7CgkJICAgIGlmKCgoaXgtMHgzZmYwMDAwMCl8eWlzaW50KT09MCkgewoJCQl6ID0gKHoteikv
KHoteik7IC8qICgtMSkqKm5vbi1pbnQgaXMgTmFOICovCgkJICAgIH0gZWxzZSBpZih5aXNpbnQ9
PTEpCgkJCXogPSAtejsJCS8qICh4PDApKipvZGQgPSAtKHx4fCoqb2RkKSAqLwoJCX0KCQlyZXR1
cm4gejsKCSAgICB9Cgl9CgogICAgLyogKHg8MCkqKihub24taW50KSBpcyBOYU4gKi8KICAgIC8q
IENZR05VUyBMT0NBTDogVGhpcyB1c2VkIHRvIGJlCglpZigoKChoeD4+MzEpKzEpfHlpc2ludCk9
PTApIHJldHVybiAoeC14KS8oeC14KTsKICAgICAgIGJ1dCBBTlNJIEMgc2F5cyBhIHJpZ2h0IHNo
aWZ0IG9mIGEgc2lnbmVkIG5lZ2F0aXZlIHF1YW50aXR5IGlzCiAgICAgICBpbXBsZW1lbnRhdGlv
biBkZWZpbmVkLiAgKi8KCWlmKCgoKCh1X2ludDMyX3QpaHg+PjMxKS0xKXx5aXNpbnQpPT0wKSBy
ZXR1cm4gKHgteCkvKHgteCk7CgogICAgLyogfHl8IGlzIGh1Z2UgKi8KCWlmKGl5PjB4NDFlMDAw
MDApIHsgLyogaWYgfHl8ID4gMioqMzEgKi8KCSAgICBpZihpeT4weDQzZjAwMDAwKXsJLyogaWYg
fHl8ID4gMioqNjQsIG11c3Qgby91ZmxvdyAqLwoJCWlmKGl4PD0weDNmZWZmZmZmKSByZXR1cm4g
KGh5PDApPyBodWdlKmh1Z2U6dGlueSp0aW55OwoJCWlmKGl4Pj0weDNmZjAwMDAwKSByZXR1cm4g
KGh5PjApPyBodWdlKmh1Z2U6dGlueSp0aW55OwoJICAgIH0KCS8qIG92ZXIvdW5kZXJmbG93IGlm
IHggaXMgbm90IGNsb3NlIHRvIG9uZSAqLwoJICAgIGlmKGl4PDB4M2ZlZmZmZmYpIHJldHVybiAo
aHk8MCk/IGh1Z2UqaHVnZTp0aW55KnRpbnk7CgkgICAgaWYoaXg+MHgzZmYwMDAwMCkgcmV0dXJu
IChoeT4wKT8gaHVnZSpodWdlOnRpbnkqdGlueTsKCS8qIG5vdyB8MS14fCBpcyB0aW55IDw9IDIq
Ki0yMCwgc3VmZmljZSB0byBjb21wdXRlCgkgICBsb2coeCkgYnkgeC14XjIvMit4XjMvMy14XjQv
NCAqLwoJICAgIHQgPSBheC0xOwkJLyogdCBoYXMgMjAgdHJhaWxpbmcgemVyb3MgKi8KCSAgICB3
ID0gKHQqdCkqKDAuNS10KigwLjMzMzMzMzMzMzMzMzMzMzMzMzMzMzMtdCowLjI1KSk7CgkgICAg
dSA9IGl2bG4yX2gqdDsJLyogaXZsbjJfaCBoYXMgMjEgc2lnLiBiaXRzICovCgkgICAgdiA9IHQq
aXZsbjJfbC13Kml2bG4yOwoJICAgIHQxID0gdSt2OwoJICAgIFNFVF9MT1dfV09SRCh0MSwwKTsK
CSAgICB0MiA9IHYtKHQxLXUpOwoJfSBlbHNlIHsKCSAgICBkb3VibGUgczIsc19oLHNfbCx0X2gs
dF9sOwoJICAgIG4gPSAwOwoJLyogdGFrZSBjYXJlIHN1Ym5vcm1hbCBudW1iZXIgKi8KCSAgICBp
ZihpeDwweDAwMTAwMDAwKQoJCXtheCAqPSB0d281MzsgbiAtPSA1MzsgR0VUX0hJR0hfV09SRChp
eCxheCk7IH0KCSAgICBuICArPSAoKGl4KT4+MjApLTB4M2ZmOwoJICAgIGogID0gaXgmMHgwMDBm
ZmZmZjsKCS8qIGRldGVybWluZSBpbnRlcnZhbCAqLwoJICAgIGl4ID0ganwweDNmZjAwMDAwOwkJ
Lyogbm9ybWFsaXplIGl4ICovCgkgICAgaWYoajw9MHgzOTg4RSkgaz0wOwkJLyogfHh8PHNxcnQo
My8yKSAqLwoJICAgIGVsc2UgaWYoajwweEJCNjdBKSBrPTE7CS8qIHx4fDxzcXJ0KDMpICAgKi8K
CSAgICBlbHNlIHtrPTA7bis9MTtpeCAtPSAweDAwMTAwMDAwO30KCSAgICBTRVRfSElHSF9XT1JE
KGF4LGl4KTsKCgkvKiBjb21wdXRlIHMgPSBzX2grc19sID0gKHgtMSkvKHgrMSkgb3IgKHgtMS41
KS8oeCsxLjUpICovCgkgICAgdSA9IGF4LWJwW2tdOwkJLyogYnBbMF09MS4wLCBicFsxXT0xLjUg
Ki8KCSAgICB2ID0gb25lLyhheCticFtrXSk7CgkgICAgcyA9IHUqdjsKCSAgICBzX2ggPSBzOwoJ
ICAgIFNFVF9MT1dfV09SRChzX2gsMCk7CgkvKiB0X2g9YXgrYnBba10gSGlnaCAqLwoJICAgIHRf
aCA9IHplcm87CgkgICAgU0VUX0hJR0hfV09SRCh0X2gsKChpeD4+MSl8MHgyMDAwMDAwMCkrMHgw
MDA4MDAwMCsoazw8MTgpKTsKCSAgICB0X2wgPSBheCAtICh0X2gtYnBba10pOwoJICAgIHNfbCA9
IHYqKCh1LXNfaCp0X2gpLXNfaCp0X2wpOwoJLyogY29tcHV0ZSBsb2coYXgpICovCgkgICAgczIg
PSBzKnM7CgkgICAgciA9IHMyKnMyKihMMStzMiooTDIrczIqKEwzK3MyKihMNCtzMiooTDUrczIq
TDYpKSkpKTsKCSAgICByICs9IHNfbCooc19oK3MpOwoJICAgIHMyICA9IHNfaCpzX2g7CgkgICAg
dF9oID0gMy4wK3MyK3I7CgkgICAgU0VUX0xPV19XT1JEKHRfaCwwKTsKCSAgICB0X2wgPSByLSgo
dF9oLTMuMCktczIpOwoJLyogdSt2ID0gcyooMSsuLi4pICovCgkgICAgdSA9IHNfaCp0X2g7Cgkg
ICAgdiA9IHNfbCp0X2grdF9sKnM7CgkvKiAyLygzbG9nMikqKHMrLi4uKSAqLwoJICAgIHBfaCA9
IHUrdjsKCSAgICBTRVRfTE9XX1dPUkQocF9oLDApOwoJICAgIHBfbCA9IHYtKHBfaC11KTsKCSAg
ICB6X2ggPSBjcF9oKnBfaDsJCS8qIGNwX2grY3BfbCA9IDIvKDMqbG9nMikgKi8KCSAgICB6X2wg
PSBjcF9sKnBfaCtwX2wqY3ArZHBfbFtrXTsKCS8qIGxvZzIoYXgpID0gKHMrLi4pKjIvKDMqbG9n
MikgPSBuICsgZHBfaCArIHpfaCArIHpfbCAqLwoJICAgIHQgPSAoZG91YmxlKW47CgkgICAgdDEg
PSAoKCh6X2grel9sKStkcF9oW2tdKSt0KTsKCSAgICBTRVRfTE9XX1dPUkQodDEsMCk7CgkgICAg
dDIgPSB6X2wtKCgodDEtdCktZHBfaFtrXSktel9oKTsKCX0KCglzID0gb25lOyAvKiBzIChzaWdu
IG9mIHJlc3VsdCAtdmUqKm9kZCkgPSAtMSBlbHNlID0gMSAqLwoJaWYoKCgoKHVfaW50MzJfdClo
eD4+MzEpLTEpfCh5aXNpbnQtMSkpPT0wKQoJICAgIHMgPSAtb25lOy8qICgtdmUpKioob2RkIGlu
dCkgKi8KCiAgICAvKiBzcGxpdCB1cCB5IGludG8geTEreTIgYW5kIGNvbXB1dGUgKHkxK3kyKSoo
dDErdDIpICovCgl5MSAgPSB5OwoJU0VUX0xPV19XT1JEKHkxLDApOwoJcF9sID0gKHkteTEpKnQx
K3kqdDI7CglwX2ggPSB5MSp0MTsKCXogPSBwX2wrcF9oOwoJRVhUUkFDVF9XT1JEUyhqLGkseik7
CglpZiAoaj49MHg0MDkwMDAwMCkgewkJCQkvKiB6ID49IDEwMjQgKi8KCSAgICBpZigoKGotMHg0
MDkwMDAwMCl8aSkhPTApCQkJLyogaWYgeiA+IDEwMjQgKi8KCQlyZXR1cm4gcypodWdlKmh1Z2U7
CQkJLyogb3ZlcmZsb3cgKi8KCSAgICBlbHNlIHsKCQlpZihwX2wrb3Z0PnotcF9oKSByZXR1cm4g
cypodWdlKmh1Z2U7CS8qIG92ZXJmbG93ICovCgkgICAgfQoJfSBlbHNlIGlmKChqJjB4N2ZmZmZm
ZmYpPj0weDQwOTBjYzAwICkgewkvKiB6IDw9IC0xMDc1ICovCgkgICAgaWYoKChqLTB4YzA5MGNj
MDApfGkpIT0wKSAJCS8qIHogPCAtMTA3NSAqLwoJCXJldHVybiBzKnRpbnkqdGlueTsJCS8qIHVu
ZGVyZmxvdyAqLwoJICAgIGVsc2UgewoJCWlmKHBfbDw9ei1wX2gpIHJldHVybiBzKnRpbnkqdGlu
eTsJLyogdW5kZXJmbG93ICovCgkgICAgfQoJfQogICAgLyoKICAgICAqIGNvbXB1dGUgMioqKHBf
aCtwX2wpCiAgICAgKi8KCWkgPSBqJjB4N2ZmZmZmZmY7CglrID0gKGk+PjIwKS0weDNmZjsKCW4g
PSAwOwoJaWYoaT4weDNmZTAwMDAwKSB7CQkvKiBpZiB8enwgPiAwLjUsIHNldCBuID0gW3orMC41
XSAqLwoJICAgIG4gPSBqKygweDAwMTAwMDAwPj4oaysxKSk7CgkgICAgayA9ICgobiYweDdmZmZm
ZmZmKT4+MjApLTB4M2ZmOwkvKiBuZXcgayBmb3IgbiAqLwoJICAgIHQgPSB6ZXJvOwoJICAgIFNF
VF9ISUdIX1dPUkQodCxuJn4oMHgwMDBmZmZmZj4+aykpOwoJICAgIG4gPSAoKG4mMHgwMDBmZmZm
Zil8MHgwMDEwMDAwMCk+PigyMC1rKTsKCSAgICBpZihqPDApIG4gPSAtbjsKCSAgICBwX2ggLT0g
dDsKCX0KCXQgPSBwX2wrcF9oOwoJU0VUX0xPV19XT1JEKHQsMCk7Cgl1ID0gdCpsZzJfaDsKCXYg
PSAocF9sLSh0LXBfaCkpKmxnMit0KmxnMl9sOwoJeiA9IHUrdjsKCXcgPSB2LSh6LXUpOwoJdCAg
PSB6Kno7Cgl0MSAgPSB6IC0gdCooUDErdCooUDIrdCooUDMrdCooUDQrdCpQNSkpKSk7CglyICA9
ICh6KnQxKS8odDEtdHdvKS0odyt6KncpOwoJeiAgPSBvbmUtKHIteik7CglHRVRfSElHSF9XT1JE
KGoseik7CglqICs9IChuPDwyMCk7CglpZigoaj4+MjApPD0wKSB6ID0gc2NhbGJuKHosbik7CS8q
IHN1Ym5vcm1hbCBvdXRwdXQgKi8KCWVsc2UgU0VUX0hJR0hfV09SRCh6LGopOwoJcmV0dXJuIHMq
ejsKfQo=


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2003-05-15 14:32 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-15 14:32 optimization/10189: pentium4 breaks suns libm code for __ieee754_pow(double x, double y) bangerth
  -- strict thread matches above, loose matches on Subject: below --
2003-03-29  4:06 David O'Brien
2003-03-26 21:27 Alexander Leidinger
2003-03-26 18:06 David O'Brien
2003-03-26 14:02 ljrittle
2003-03-22 12:46 till

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).