This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Target-specific bugs (was Re: Number of 3.3 hi-pri PRs goingup)
Nathanael Nerode wrote:
>
> Joseph S. Myers wrote:
> > On Sat, 22 Feb 2003, Nathanael Nerode wrote:
> >
> >
> >>1. Platforms for which no 3.x build has been reported: Close all
> >>target-specific bugs immediately and possibly deprecate the platform.
> >
> >
> > We should close such bugs when support for the target is *removed* from
> > mainline, not when the target is deprecated. (And this is something that
> > does need to be done as part of the target removal process, just as stray
> > references to the target and its problems need to be removed from
> > trouble.texi and elsewhere in the manual and sources - preferably as part
> > of the target removal rather than left for someone else to do later.)
> >
> > This may make sense for native platforms, but in general people do not
> > seem to report their cross builds at all or submit testresults for them.
> How sad...
I don't know that this is entirely true. I have been reporting on my
results of building about 35-40 cross targets on a GNU/Linux. On those
with simulators I have been submitting the test results to the mailing
list. And periodically, I have been writing up a cross build status.
It only covers the non-OS and RTEMS targets (hence the 35-40 number)
but that's a lot more than you are indicating.
And recently I began to Canadian cross on a GNU/Linux box cross toolsets
binaries hosted on Cygwin and Solaris. The first batch for RTEMS is out
now but I haven't tried the Canadian cross for the non-RTEMS ones.
> > I would like to see a list of all supported platforms (which I think ought
> > to go in install.texi, host/target specific notes, even where there are no
> > specific notes for a system, just so that users can see exactly which
> > systems are supported and what their target triples are) together with the
> This would be a very, very good idea.
Janis (I think) and I had a discussion about this a while back. The
first issue
is a format/structure that is easy to plug data for test results, hints,
etc.
into without being unwieldy.
> > list of those native systems which haven't had a 3.x build report or
> > testresults sent and so are candidates for deprecation. (Also indicate
> > which if any of those have had any user interest at all - questions asked
> > about them, or bug reports saying they don't work.)
> >
> > Also remember that some target-specific bugs are in fact bugs in generic
> > code that just happen only to show up on certain platforms.
> Yeah. I'm trying to make suggestions which will help clear the bug
> reports down to a managable quantity, though. Bugs which can't be
> reproduced on maintained systems have no value in the bug tracking
> system, unfortunately.
>
> For another thought, I strongly suggest that any bug in feedback and
> without feedback for 3 months be closed, and that this be documented
> somewhere. (The standard I've been using is 6 months, which I think is
> overly generous.)
I think that will end up closing some that are simply being ignored
without
ever being addressed or fixed. For example, I filed PR 3587
on "Fri Jul 06 06:46:02 PDT 2001", it still applies to the 3.2 and 3.3
branches
(no testing on trunk), and has never gotten a bit of attention.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp dot com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985