public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
To: gcc@gcc.gnu.org
Subject: Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures
Date: Fri, 27 Dec 2002 11:19:00 -0000	[thread overview]
Message-ID: <200212271716.MAA29305@caip.rutgers.edu> (raw)

On the 3.3. and 3.4 branches, I've noticed that
g++.dg/bprob/g++-bprob-1.C fails compilation when running multilib
passes.  E.g.:

http://gcc.gnu.org/ml/gcc-testresults/2002-12/msg00753.html
http://gcc.gnu.org/ml/gcc-testresults/2002-12/msg01074.html

It doesn't appear to be related to which particular multilib flag is
used, rather the first pass always succeeds and the second and all
subsequent ones fail.  Note here that one irix6.5 report starts with
-mabi=64 first and the other has it last.  In both cases whatever pass
goes first works.

http://gcc.gnu.org/ml/gcc-testresults/2002-12/msg00904.html
http://gcc.gnu.org/ml/gcc-testresults/2002-12/msg01108.html

Given this I believe it is a testsuite bug rather than a gcc bug.  I
looked in the log file to see what the compilation problem was and I
saw this output from the compilation:

 > g++: : No such file or directory
 > g++: : No such file or directory
 > compiler exited with status 1

Though it doesn't say *which* file g++ can't find, I'm suspecting that
the profiling intermediate files are removed in the first multilib
pass cleanup phase and not re-generated in the second and later
multilib passes.

Since I don't really understand the bprob tests, I tried checking to
see why the g77 and gcc bprob tests work with multilibs and the g++
ones don't.  The only real difference I can see between on one hand
g77.dg/bprob/bprob.exp & gcc.misc-tests/bprob.exp versus
g++.dg/bprob/bprob.exp is that the working languages have this extra
line:

 > set perf_ext tim

Since checking by running multilibs tests takes so long, I was hoping
someone could comment on this and let me know if I'm on the right
track.

		Thanks,
		--Kaveh

--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

             reply	other threads:[~2002-12-27 17:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-27 11:19 Kaveh R. Ghazi [this message]
2002-12-28 10:58 ` Kaveh R. Ghazi
2002-12-28 21:36   ` Janis Johnson
2002-12-28 21:41     ` Daniel Jacobowitz
2002-12-29 16:41     ` Kaveh R. Ghazi
2002-12-30 12:58       ` Janis Johnson
2002-12-31 12:56         ` Kaveh R. Ghazi
2002-12-30  8:56 ` R. Kelley Cook
2002-12-30 13:02   ` Janis Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200212271716.MAA29305@caip.rutgers.edu \
    --to=ghazi@caip.rutgers.edu \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).