Re: jacks oddities

[Andreas Tobler <toa at pop dot agri dot ch>]

Tom Tromey wrote:

> > > > > > "Andreas" == Andreas Tobler <toa@pop.agri.ch> writes:
>
>
> Andreas> Looking for the cause I found that the gcj.log file from src
> Andreas> jacks/logging was taken. This one only had about 1400 passes.
> Andreas> Now running jacks out side dejagnu and copying the gcj.log
> Andreas> file into the src dir of jacks made me happy :) I don't know
> Andreas> where it came from.
>
> Jacks has this file checked in.  In theory running jacks should
> generate a new gcj.log file, which we should then read.  Do you know
> what is going wrong here?

Not really. All I know is that I never ran jacks inside the source tree 
itself. I only ran jacks via make check in libjava. Doing so copies the 
whole tree inside the objdir of libjava, also the old out-of-date gcj.log.

We then run 'jacks gcj' and parse the logging/gcj.log.

  verbose "Running Jacks..."
  # Just ignore error exits from the jacks program.
  # It will always error exit for us, since don't completely pass.
  catch {exec ./jacks gcj} msg

  gcj_jacks_parse logging/gcj.log

Here I'm not sure if this is the place where you think we generate the 
new gcj.log file?


> Andreas> Anyway, during this investigation I wondered why we do not set
> Andreas> JAVAC_DEPRECATION_FLAG to -Wdeprecated in the gcj_setup?
>
> No idea.

We have it in the gcj_setup sample but not in the jacks.exp part when we 
write our own setup file.

> Andreas> Doing so would give us another 60 XPASSES.
>
> Please check in your patch, but also update the xfail file at the same
> time.

I verify again and in case of success I will checkin the jacks.exp part 
plus the update xfail file.

Andreas