This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PROPOSAL: Policy for obsoleting targets
Janis Johnson wrote:
>
> On Fri, May 16, 2003 at 12:33:50PM -0500, Joel Sherrill wrote:
> > Peter Barada wrote:
> > >
> > > > At the time GCC version 3.n is released, all targets which have not
> > > > had a successful build and test report posted to gcc-testresults
> > > > for prereleases of minor version n, or releases n-1 and n-2, go on
> > > > the obsoletion list for version n+1. "Successful" means minimum
> > > > useful functionality: it's okay if only the C compiler works.
> > >
> > > http://gcc.gnu.org/gcc-3.2/buildstat.html or
> > > http://gcc.gnu.org/ml/gcc-testresults/2003-04/ only shows host
> > > compilers, and no embedded targets(such as ppc-eabi, m68k-elf, etc).
> > >
> > > How do we prevent embedded targets(that are know to work fine) from
> > > from being placed on the obsoletion list?
> >
> [snip]
> > This is why I try to report fairly regularly on targets I honestly
> > don't use for real work. My thinking is that CPU-elf or CPU-coff is
> > so close to CPU-rtems that any code generation problems are shared.
> >
> > Importantly for embedded targets without simulators, it can be painful
> > to even run the suite requiring some significant effort to setup.
>
> I might regret this, but I'm now willing to add cross build reports to
> the GCC build status lists. If someone wants to suggest a list of what
> information such a report should include it could be linked from the
> beginning of the document. The list itself would probably just include
> something like
>
> <target triple> Cross build: 3.3
>
> where the "3.3" is a link to the archived message. In previous
> discussions about listing cross builds in the status lists, I've
> assumed that I would need to pull relevant information out of the
> messages about the host, target, and possibly build machine, and put
> it all into the entry in some organized way. If I can get away with
> merely adding simple-minded links, I no longer have objections to
> adding them to the list.
How would you deal with multiple people reporting on the same build?
It is really nice to see at least target and host but I know that
is work on your side. So I would like to see 3 columns: target, host,
and gcc version.
The linked to message should include more information like binutils
version, C library, configure command, and did the test suite get run.
If there is a patch or hack needed to build it, hopefully that will
get included in the writeup.
> It would be fine, by the way, for a report to include a long list
> of successful cross builds like the ones Joel does for RTEMS targets.
I generate the summary reports because it is easier for me. Would it
be better to generate one message per target? [Hoping you say no. :)]
I try to report on about 30 embedded targets with a GNU/Linux host. I
also have GNU/Linux -> Solaris and Cygwin cross compilers so I can
Canadian cross builds for those. Are the results of those builds
important?
> So, back to the point of this thread: what kind of information would
> need to be included in reports of cross builds in order for those
> targets to be considered active?
Personal opinion here. A report target X builds on host Y is the
minimum.
The problem is that many people build crosses for a specific application
and if that works for them, that's all they care about.
I would personally like to know that the target compiler could run
the testsuite (if a simulator in gdb is available). If a simulator
is not available, then it would be wonderful to have a gcc test suite
setting/mode where you can do everything but run and have meaningful
results. If we had this mode, then my periodic automated test builds
would give more information on targets like m68k and x86 embedded.
Another option would be a webpage that submits a record to a database of
build information. Then queries would be easier. But this is pie in
the sky thinking.
> Janis
I don't want to make this a huge burden on you. I know that proposals
in the past have done that.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985