This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Profiling on mips-irix6? (Testcase gcc.dg/nest.c failure)
- From: Tim Prince <tprince at computer dot org>
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>, gcc-bugs at gcc dot gnu dot org,gcc at gcc dot gnu dot org
- Cc: David dot Billinghurst at riotinto dot com, echristo at redhat dot com
- Date: Wed, 2 Oct 2002 21:36:50 -0700
- Subject: Re: Profiling on mips-irix6? (Testcase gcc.dg/nest.c failure)
- References: <200210021422.KAA10736@caip.rutgers.edu>
- Reply-to: tprince at computer dot org
On Wednesday 02 October 2002 07:22, Kaveh R. Ghazi wrote:
> When running the testsuite on mips-sgi-irix6.5, I get a failure in
> gcc.dg/nest.c:
>
> http://gcc.gnu.org/ml/gcc-testresults/2002-09/msg01040.html
>
> > FAIL: gcc.dg/nest.c (test for excess errors)
> > WARNING: gcc.dg/nest.c compilation failed to produce executable
>
> Its not just me:
> http://gcc.gnu.org/ml/gcc-testresults/2002-09/msg01050.html
>
> This test passes in the -pg flag. Looking at gcc.log, I see:
> > ld32: FATAL 9 : I/O error (/usr/lib32/mips3/gcrt1.o): No such file or
> > directory collect2: ld returned 32 exit status
>
> I can't find gcrt1.o anywhere. Its not already installed on my system
> nor is it provided by and built by gcc itself.
As I used Irix-6.5 in a previous cloak, I'll take a stab:
-pg was not the way to do profiling on Irix-6.5; I'm not surprised the
support libraries are missing. It was done by building with -g and using
speedshop.
>
> So before I proceed I was wondering whether there is some place to get
> a gcrt1.o and/or libprof1.a for irix6.
> If not, I can open a PR/change-request for someone to provide one,
How about symlinking gcrt0.o to gcrt1.o, for example?
> and
> mark the testcase to only assemble on irix, not compile & run.
I've noticed that most cygwin testers are getting a link failure; a different
problem, caused by the typical (full) installation not supporting -pg without
over-riding the library search order. Simplest cure there is to un-install
the alternate mingw runtime.
I doubt it's feasible for gcc maintainers to fix target-specific things like
this. But you're right, this test fails for target-specific reasons which
aren't the fault of gcc. Apparently, it was meant specifically to diagnose a
power-pc specific problem; shouldn't that be noted without requiring web
research, for example, by making it run only on targets where it is relevant?
--
Tim Prince