Re: code generation bug

["Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>]

> 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.

> 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.

Please note that, for new bugs in the mainline, it is quite unlikely
that the people fixing bugs will check whether there is an open
report. It works the other way 'round - if, say, Nathan Sidwell, looks
at the PR base to see what needs fixing, he'll likely close the report
when he's done. Other bugs that get fixed in the process won't have
their status changed. There is no magic that determines whether a bug
has been fixed - it all requires hard work.

> Making the bugs database publicly available was a really great idea!

Maybe there's a misconception here as well. It is not something that
was always there and is now made public - this is an all-new database,
which is public right from the beginning.

Regards,
Martin