* Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures @ 2002-12-27 11:19 Kaveh R. Ghazi 2002-12-28 10:58 ` Kaveh R. Ghazi 2002-12-30 8:56 ` R. Kelley Cook 0 siblings, 2 replies; 9+ messages in thread From: Kaveh R. Ghazi @ 2002-12-27 11:19 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures 2002-12-27 11:19 Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures Kaveh R. Ghazi @ 2002-12-28 10:58 ` Kaveh R. Ghazi 2002-12-28 21:36 ` Janis Johnson 2002-12-30 8:56 ` R. Kelley Cook 1 sibling, 1 reply; 9+ messages in thread From: Kaveh R. Ghazi @ 2002-12-28 10:58 UTC (permalink / raw) To: gcc > > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures 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 0 siblings, 2 replies; 9+ messages in thread From: Janis Johnson @ 2002-12-28 21:36 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures 2002-12-28 21:36 ` Janis Johnson @ 2002-12-28 21:41 ` Daniel Jacobowitz 2002-12-29 16:41 ` Kaveh R. Ghazi 1 sibling, 0 replies; 9+ messages in thread From: Daniel Jacobowitz @ 2002-12-28 21:41 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures 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 1 sibling, 1 reply; 9+ messages in thread From: Kaveh R. Ghazi @ 2002-12-29 16:41 UTC (permalink / raw) To: janis187; +Cc: gcc > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures 2002-12-29 16:41 ` Kaveh R. Ghazi @ 2002-12-30 12:58 ` Janis Johnson 2002-12-31 12:56 ` Kaveh R. Ghazi 0 siblings, 1 reply; 9+ messages in thread From: Janis Johnson @ 2002-12-30 12:58 UTC (permalink / raw) To: Kaveh R. Ghazi; +Cc: janis187, gcc 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" ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures 2002-12-30 12:58 ` Janis Johnson @ 2002-12-31 12:56 ` Kaveh R. Ghazi 0 siblings, 0 replies; 9+ messages in thread From: Kaveh R. Ghazi @ 2002-12-31 12:56 UTC (permalink / raw) To: janis187; +Cc: gcc > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures 2002-12-27 11:19 Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures Kaveh R. Ghazi 2002-12-28 10:58 ` Kaveh R. Ghazi @ 2002-12-30 8:56 ` R. Kelley Cook 2002-12-30 13:02 ` Janis Johnson 1 sibling, 1 reply; 9+ messages in thread From: R. Kelley Cook @ 2002-12-30 8:56 UTC (permalink / raw) To: Kaveh R. Ghazi, gcc >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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures 2002-12-30 8:56 ` R. Kelley Cook @ 2002-12-30 13:02 ` Janis Johnson 0 siblings, 0 replies; 9+ messages in thread From: Janis Johnson @ 2002-12-30 13:02 UTC (permalink / raw) To: R. Kelley Cook; +Cc: Kaveh R. Ghazi, gcc 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2002-12-31 19:53 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-12-27 11:19 Analysis of g++.dg/bprob/g++-bprob-1.C multilib failures Kaveh R. Ghazi 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
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).