Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures

Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures

[Kaveh R. Ghazi]

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

Re: Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures

[Kaveh R. Ghazi]

 >  > 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.

No luck, it didn't make a difference.

I'm kind of stuck, since this is a maze of dejagnu stuff.  If someone
has ideas I would appreciate some help on this one.

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

Re: Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures

[Janis Johnson]

On Sat, Dec 28, 2002 at 11:13:14AM -0500, Kaveh R. Ghazi wrote:
>  >  > 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.
> 
> No luck, it didn't make a difference.
> 
> I'm kind of stuck, since this is a maze of dejagnu stuff.  If someone
> has ideas I would appreciate some help on this one.

I wrote the framework for those tests, so perhaps I could figure out
what's going on.  I've never used multilibs; is that something I could
do with a cross compiler (and simulator) on my i686-pc-linux-gnu laptop
while I'm at home during the next few days?  It's cranking away looking
for patches that introduced regressions, but it could be put to work
doing something else for a while, and I can interrupt my weaving and
papermaking and baking and lazing about to try to remember what those
tests are doing.

Janis

Re: Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures

[Daniel Jacobowitz]

On Sat, Dec 28, 2002 at 06:26:29PM -0800, Janis Johnson wrote:
> On Sat, Dec 28, 2002 at 11:13:14AM -0500, Kaveh R. Ghazi wrote:
> >  >  > 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.
> > 
> > No luck, it didn't make a difference.
> > 
> > I'm kind of stuck, since this is a maze of dejagnu stuff.  If someone
> > has ideas I would appreciate some help on this one.
> 
> I wrote the framework for those tests, so perhaps I could figure out
> what's going on.  I've never used multilibs; is that something I could
> do with a cross compiler (and simulator) on my i686-pc-linux-gnu laptop
> while I'm at home during the next few days?  It's cranking away looking
> for patches that introduced regressions, but it could be put to work
> doing something else for a while, and I can interrupt my weaving and
> papermaking and baking and lazing about to try to remember what those
> tests are doing.

Sure.  Test any multilibbed target; I use SH.  Try giving
RUNTESTFLAGS="--target_board sh-hms-sim{,2}" to test sh1 and sh2, if I
remember correctly.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures

[Kaveh R. Ghazi]

 > From: Janis Johnson <janis187@us.ibm.com>
 > 
 > On Sat, Dec 28, 2002 at 11:13:14AM -0500, Kaveh R. Ghazi wrote:
 > > 
 > > I'm kind of stuck, since this is a maze of dejagnu stuff.  If someone
 > > has ideas I would appreciate some help on this one.
 > 
 > I wrote the framework for those tests, so perhaps I could figure out
 > what's going on.  I've never used multilibs; is that something I could
 > do with a cross compiler (and simulator) on my i686-pc-linux-gnu laptop
 > while I'm at home during the next few days?  It's cranking away looking
 > for patches that introduced regressions, but it could be put to work
 > doing something else for a while, and I can interrupt my weaving and
 > papermaking and baking and lazing about to try to remember what those
 > tests are doing.
 > Janis

Thanks Janis, that'll be a big help.  While you may be able to
recreate the error with a multilib simulator, I suspect you may be
able to use *any* multipass testsuite run.  For example, one regular
(plain vanilla) pass and one -fPIC pass.  That would work on a native
x86-linux-gnu box and should be much simpler since the cross stuff
won't come into play.  If you have the trunk already built and handy,
as a first guess try:

make RUNTESTFLAGS="--target_board 'unix{-fPIC,-fpic,}'" check-gcc-c++

see if that triggers it for you.  

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

Re: Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures

[R. Kelley Cook]

 >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

Kaveh,

I think I might know why.

I have a long open PR other/6480 regarding behavior that was very similar.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=6480

Basically, the g++ and gcc testsuites parse their additionaloptions in 
different order.  And I am guessing that specifying a multilib is an 
additional option

g++ does it the correct way, IMO. Specifically, that an individual test 
can override any global options.

I provided a one line patch with the PR, try it.  If it works great. 
More likely, if both gcc and g++ now exhibit the queerness that you 
noticed then you at least also have your answer: lib/profopt.exp (which 
is called by the bprob expect files) then already takes into account the 
backwards syntax of gcc.exp and attempted to correct it ahead of time.

It would be nice if this patch was reviewed.  The various testsuites do 
behave differently with --tool-opts specified.

Kelley Cook

Re: Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures

[Janis Johnson]

On Sun, Dec 29, 2002 at 03:46:30PM -0500, Kaveh R. Ghazi wrote:
>  > From: Janis Johnson <janis187@us.ibm.com>
>  > 
>  > On Sat, Dec 28, 2002 at 11:13:14AM -0500, Kaveh R. Ghazi wrote:
>  > > 
>  > > I'm kind of stuck, since this is a maze of dejagnu stuff.  If someone
>  > > has ideas I would appreciate some help on this one.
>  > 
>  > I wrote the framework for those tests, so perhaps I could figure out
>  > what's going on.  I've never used multilibs; is that something I could
>  > do with a cross compiler (and simulator) on my i686-pc-linux-gnu laptop
>  > while I'm at home during the next few days?  It's cranking away looking
>  > for patches that introduced regressions, but it could be put to work
>  > doing something else for a while, and I can interrupt my weaving and
>  > papermaking and baking and lazing about to try to remember what those
>  > tests are doing.
>  > Janis
> 
> Thanks Janis, that'll be a big help.  While you may be able to
> recreate the error with a multilib simulator, I suspect you may be
> able to use *any* multipass testsuite run.  For example, one regular
> (plain vanilla) pass and one -fPIC pass.  That would work on a native
> x86-linux-gnu box and should be much simpler since the cross stuff
> won't come into play.  If you have the trunk already built and handy,
> as a first guess try:
> 
> make RUNTESTFLAGS="--target_board 'unix{-fPIC,-fpic,}'" check-gcc-c++
> 
> see if that triggers it for you.  

Yes, that did it.

This patch fixes the C++ bprob tests when running the C++ test suite
with multiple sets of options.  Those tests were using a global variable
that was also used in other tests, but this change affects only the
outcome of the bprob tests.  Tested with the gcc-20021202 snapshot with
and without the patch on i686-pc-linux-gnu with
  make RUNTESTFLAGS="--target_board 'unix{-fPIC,-fpic,}'" check-c++

I won't have CVS access for the next few days, so if this looks OK
please check it in.

2002-12-30  Janis Johnson  <janis187@us.ibm.com>

	* lib/profopt.exp: Change the name of a global variable to avoid
	possible clashes with other test suites.

--- testsuite/lib/profopt.exp.orig	Sun Dec 29 16:45:07 2002
+++ testsuite/lib/profopt.exp	Sun Dec 29 16:45:21 2002
@@ -66,7 +66,7 @@
 	{ -Os } ]
 }
 
-set option_list $PROFOPT_OPTIONS
+set prof_option_list $PROFOPT_OPTIONS
 
 #
 # profopt-cleanup -- remove profiling or performance results files.
@@ -126,7 +126,7 @@
 #
 proc profopt-execute { src } {
     global srcdir tmpdir
-    global option_list
+    global prof_option_list
     global tool profile_option feedback_option prof_ext perf_ext perf_delta
     global verbose
 
@@ -142,7 +142,7 @@
     set executable $tmpdir/[file tail [file rootname $src].x]
 
     set count 0
-    foreach option $option_list {
+    foreach option $prof_option_list {
 	set execname1 "${executable}${count}1"
 	set execname2 "${executable}${count}2"
 	set execname3 "${executable}${count}3"

Re: Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures

[Janis Johnson]

On Mon, Dec 30, 2002 at 10:10:40AM -0500, R. Kelley Cook wrote:
>  >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
> 
> Kaveh,
> 
> I think I might know why.
> 
> I have a long open PR other/6480 regarding behavior that was very similar.
> 
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=6480
> 
> Basically, the g++ and gcc testsuites parse their additionaloptions in 
> different order.  And I am guessing that specifying a multilib is an 
> additional option
> 
> g++ does it the correct way, IMO. Specifically, that an individual test 
> can override any global options.
> 
> I provided a one line patch with the PR, try it.  If it works great. 
> More likely, if both gcc and g++ now exhibit the queerness that you 
> noticed then you at least also have your answer: lib/profopt.exp (which 
> is called by the bprob expect files) then already takes into account the 
> backwards syntax of gcc.exp and attempted to correct it ahead of time.
> 
> It would be nice if this patch was reviewed.  The various testsuites do 
> behave differently with --tool-opts specified.

The problem Kaveh ran into was different.  Your patch makes sense to me
but I haven't yet tried it.

Janis

Re: Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures

[Kaveh R. Ghazi]

 > From: Janis Johnson <janis187@us.ibm.com>
 > > 
 > > make RUNTESTFLAGS="--target_board 'unix{-fPIC,-fpic,}'" check-gcc-c++
 > > 
 > > see if that triggers it for you.  
 > 
 > Yes, that did it.
 > 
 > This patch fixes the C++ bprob tests when running the C++ test suite
 > with multiple sets of options.  Those tests were using a global variable
 > that was also used in other tests, but this change affects only the
 > outcome of the bprob tests.  Tested with the gcc-20021202 snapshot with
 > and without the patch on i686-pc-linux-gnu with
 >   make RUNTESTFLAGS="--target_board 'unix{-fPIC,-fpic,}'" check-c++
 > 
 > I won't have CVS access for the next few days, so if this looks OK
 > please check it in.
 > 
 > 2002-12-30  Janis Johnson  <janis187@us.ibm.com>
 > 
 > 	* lib/profopt.exp: Change the name of a global variable to avoid
 > 	possible clashes with other test suites.

Yup that patch cured it for me.

Tested on mips-sgi-irix6.5 with 3 testsuite passes, g++ bprob works.

I'll check it in to 3.3 and 3.4 on your behalf.

		Thanks very much!
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu