Bug Digest 5/9

[Giovanni Bajo]

Dara Hazeghi wrote:

>my daily list of bug reports to modify or close, some may be from
>yesterday's too. Thanks to everyone, especially Wolfgang and Giovanni for
>doing all the GNATs stuff for me, since I don't have write access.

No problem. Would you mind CC to me directly your bug digests from now on?

>Please mark as confirmed (and where appropriate, include version numbers in
>PR title):

We include version number in the PR synopsys if (and only if) it's a
regression. Which means that the same testcode works on a previous GCC
version. I briefly checked if this was true by looking at the audit trail.

>[...]

Done, except for:

>7595 (3.3 and 3.4)

There is no analysys of this bug in the audit trail

>8623 (3.3 and 3.4)

This looks fixed in 3.3/mainline, isn't it? Or at least, it does not ICE
anymore. .


>Please close as resolved:
>[....]

Done.

>7254 - target obsolete in 3.3, and will be removed in 3.4

I went for suspended. We can close it later when the target is removed from
all the active branches.


>Please change status to feedback

>[....]

Done, except for:

>5519

No question in the audit trail.



>Change status from feedback to open (or analyzed, whichever is deemed
>appropriate)
>10620
>8751
>8303
>8082
>7881
>7198
>7093
>7076
>6522
>4784

I will look into this tomorrow or another day, if nobody does it for me. No
more time right now.
For a bug to be analyzed we need:

- Confirmation that it can be reproduced on at least one active branch /
mainline
- A small distillated testcase that can be used to reproduce the bug
- Regression analysys (does the bug show up in previous GCC version up to
2.95?)
- Analysys of the class and category of the PR (is it ice-on-legal,
ice-on-illegal, accept-illegal, rejects-legal? Is it c, c++, target,
middle-end, optimization?)

Volker is updating the documentation at gcc.gnu.org to reflect this more
clearly.

>In feedback for a long time without response (let me know if I should stop
>doing this, or if the cutoff should be different. 2 months seems good to
me,
>because if we've not heard from them in 2 months, I rather doubt we
will...)

The cutoff is 3 months.


>9544 - 3 months
>9495 - 3 months
>9417 - 3 months
>9205 - 4 months, Richard Earnshaw believes it's fixed
>9111 - 5 months, no feedback, same issue described in 7076
>9110 - 4 months, no testcase or feedback
>8421 - 4 months
>8125 - 7 months
>7933 - 5 months
>7867 - 5 months
>6524 - 4 months, a very old version of gcc, probably as assembler bug too
>4977 - 5 months
>3313 - 6 months

I closed all these bugs (>= 3 months).


>Other questions:
>8440 - We no longer ICE, so this is miscategorized. However with
>optimization, the assembler rejects the code, and without optimization, the
>compiler does. I think we should be consistent about the issue, but this is
>clearly beyond my level of expertise.
>7892 - looks like the proposed solution works, but also that original
>submitter hasn't confirmed. So is this a bug?

I will look into this tomorrow or another day, if nobody does it for me. No
more time right now.

>5256 - I've reproduce the bug on 3.0.3, but not on 3.0.4, 3.2, 3.3 or
>mainline, should I still ask for user feedback?

Absolutely not. If you can reproduce the bug _and_ you can confirm that it's
fixed in new versions, why should we ask for feedback? It means that the bug
has been fixed. You can ask for feedback if you can _never_ reproduce the
bug, and you can't be sure that it's been actually fixed.

Giovanni Bajo