This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: code generation bug
"Martin v. Loewis" wrote:
>
> > The problem is still present in today's (20000312) version and
> > I have not found a GNATS entry concerning this bug, so I think
> > it might have been forgotten during the last weeks of bootstrapping
> > problems.
>
> I personally use a number of criteria to decide what reports I
> process. Among those criteria is whether there was a response to the
> report, in this case, I neither read the report, nor the response.
> That's why I did not notice the first two reports at all. Another
> criterion is whether it is a bug only in the mainline compiler and not
> in the release branch; here I don't investigate it because I trust
> that the submitters will re-report it if it does not get fixed.
You disagree with Alexandre Oliva here, who writes
(http://gcc.gnu.org/ml/gcc-bugs/2000-02/msg00617.html)
Alexandre> Yup, no need to re-report a problem, unless somebody told you it was
Alexandre> supposed to have been fixed.
I will gladly resubmit a bug report if it has not been resolved after a month
or so; on the other hand, I don't want to overflow the list with redundant
traffic and pssibly annoy the developers. Maybe GNATS will help to alleviate
this problem.
> > Would it be possible to put the bug into GNATS, so that people can
> > keep themselves informed about the progress that's being made?
>
> Sure! For example, you can use the gccbug script that should have just
> appeared in the mainline. If you enter a report in place of somebody
> else, make sure to fill-in the X-GNATS-Notify: field - that will
> arrange to have the originators notified in case the status changes.
I will do this, thanks! It would be good to know what the different bug
categories exactly mean, though. If you could give me a pointer to more
information about GNATS and special GCC GNATS issues (like bug types etc.)
I could provide a patch for the HTML docs.
Regards,
Martin