This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Bug reporting instructions (was Re: optimization/10189: pentium4breaks suns libm...)
- From: Zack Weinberg <zack at codesourcery dot com>
- To: ljrittle at gcc dot gnu dot org
- Cc: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 26 Mar 2003 08:57:41 -0800
- Subject: Bug reporting instructions (was Re: optimization/10189: pentium4breaks suns libm...)
- References: <20030326130118.8374.qmail@sources.redhat.com>
[GNATS and others removed from cc: line as this ceases to be relevant
to a specific bug report]
...
> 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.
I think this is really good advice, and advice that should probably be
added to GCC's bug-reporting instructions. Could I persuade you to
turn this into a patch for the web page?
zw