Re: optimization/10189: pentium4 breaks suns libm code for __ieee754_pow(double x, double y)

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_at_freebsd.org to the crowd_at_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 i
 t 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