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 [EMAIL PROTECTED] to the
[EMAIL PROTECTED] 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
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
