Date: Mon, 14 Apr 2003 22:38:02 -0500 (CDT) From: Loren James Rittle <rittle@latour.rsch.comm.mot.com> To: ports@freebsd.org Cc: friend@vortex4.net Subject: Re: -march=pca56 blows up nethack34-nox11 (fwd) Message-ID: <200304150338.h3F3c2hN073639@latour.rsch.comm.mot.com> In-Reply-To: <20030413091004.N84868@vortex4.net> References: <20030412021505.E84868@vortex4.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <20030413091004.N84868@vortex4.net> Dave writes: >> Upgrade to a newer 5.0 (which has a newer gcc). If it still fails, >> report it to the gcc people. Yes, please report it to the gcc people but please do so in a manner that is helpful to them (I'm one of them). At a minimum, that means reading http://gcc.gnu.org/bugs.html before submitting the actual PR. Better yet, factor in the following process which I'm still editing. > Verified the problem still repeats. Is there a FreeBSD gcc contact in > particular who I can report this to? /usr/src/contrib/gcc/MAINTAINERS > says to use http://gcc.gnu.org/bugs.html to report gcc bugs, and I don't > know enough to be able to identify the code snippet in particular that's > causing the problems. I tried adding -Wall to CFLAGS in make.conf, but I > didn't get any warnings that might be pertinent. If you don't know how to identify the code snippet to report in the PR, then start here. You must be able to identify a self-contained test case, or else you will likely receive little help. From the context of this thread, I hereby assume that this port builds for you without the -march flag. The *best* course of action for you, if you want this problem fixed by the gcc team, is the following: (0) Build and install the gcc mainline from the FSF tree on your platform. (Note: FSF gcc mainline is quite stable for both FreeBSD-stable and FreeBSD-current. It might fail to build with GNU make ~1 out of 10 random CVS updates. If it fails to bootstrap for you, then wait a day and try again.) I suggest that read http://gcc.gnu.org/install/specific.html#*-*-freebsd* and then http://gcc.gnu.org/install/ . Use a non-standard prefix which is completely empty, such as /usr/local/beta-gcc, while configuring. (1) Verify that the complex software of interest (a.k.a. FreeBSD port) still fails to build/run properly with that latest gcc with the CPU and/or optimization flags that you favor. If the problem is not seen when the complex software of interest is built against the compiler built in step (0), then: (2a) assuming you want to get the fix in the system compiler sooner rather than later, restart at step (0) use the most recent release branch working back until the release branch of the system compiler with the bug. If the problem is still seen when the complex software of interest is built against the compiler built in step (0), then do the following: (2b) Verify that the complex software of interest builds with only -O2 or -O0 with the compiler installed in step (0). (3b) Install dejagnu (on BSD, from the ports collection). (4b) Run the entire gcc testsuite with 'gmake -sk check' in the working tree that you built gcc within (i.e. don't blow it away after you install from it). (5b) Save all testsuite .log and .sum files. Note: If you run `$gcc-cvs-src/contrib/test_summary | sh' in the working tree you built and tested gcc within, then you will be posting an e-mail to gcc-testresults (in itself a good thing) and saving all .log and .sum files as .log.sent and .sum.sent. (6b) Put RUNTESTFLAGS='--target_board "unix{-march=pca56}"' in your exported shell environment. (7b) Run the entire gcc testsuite again with 'gmake -sk check'. If you note any differences, then report one PR per set of related test cases that fail. Please use some personal judgment in understanding why extra test cases are failing. If you notice a class of failure by looking at the logs, then sumbit only one PR for the root difference you detected. Refer to the (related) test case(s) that fails. Perhaps compare your results in (4b) against those posted daily to http://gcc.gnu.org/ml/gcc-testresults/ for same CPU, different OS and same CPU and same OS. In the quite unlikely possibility that zero extra tests are failing with your extra CPU flags, then you will have to do more work to synthesize a one-file new test case that displays the problem. DO NOT submit a PR to gcc.gnu.org that says, port X fails to build on FreeBSD. The part of the gcc team that would be willing to work on per-CPU code generation bugs has no context for that nebulous report and will not look at it seriously. GCC depends on users being willing to do this work when a bug appears. If you are unwilling to do this extra work to report the PR properly, then you probably shouldn't be adding CPU flags to random port builds. The compiler is very well tested without extra CPU flags. It is entirely possible that *zero* people have tested it with the CPU flag you are adding. Regards, Loren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200304150338.h3F3c2hN073639>