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