This is the mail archive of the
mailing list for the GCC project.
Re: Impact of bugs on different versions.
El 21 set 2017, a les 17:50, Martin Sebor <firstname.lastname@example.org> va escriure:
> On 09/21/2017 06:22 AM, Vicent Brocal wrote:
>> For a C standalone application (no libs) I selected the following
>> components: c, inline-asm, ipa, preprocessor, regression,
>> rtl-optimization, target, tree-optimization.
>> Am I missing any that could be relevant?
>> A search only filtering for these components shows >4k results. I guess
>> that I need to find some way to trim it down.
> You should also include middle-end. If you are using LTO then
> also lto. Ditto for sanitizer. It's possible that there could
> also be relevant bugs under driver and other (the classification
> isn't perfect).
I see that I am not being very successful trying to reduce the scope, though :)
>> Thanks anyway for the indications.
>> On 21/09/17 14:02, Jonathan Wakely wrote:
>>> On 21 September 2017 at 12:56, Vicent Brocal wrote:
>>>> Hello everyone,
>>>> I am trying to figure out which are the problems affecting a specific
>>>> version of GCC (4.4.2) from the information in the bug tracker
>>>> So far I have been able to get a list of the bugs restricted to
>>>> standalone C components (c, inline-asm, ipa, preprocessor, regression,
>>>> rtl-optimization, target, tree-optimization) and filtering "known to
>>>> fail" field to 4.4.2.
>>>> Does that cover the case when for example a bug was detected for 4.4.5
>>>> that also impacts 4.4.2?
>>>> How exhaustively previous versions in the same
>>>> series (e.g 4.4) are checked when a problem is discovered in a newer
>>>> version (e.g 4.4.5)?
>>> Not at all exhaustively. Even if someone tests it and confirms it's
>>> present in that version, typically it wouldn't get listed in the Known
>>> to fail field.
>>> In general if a bug affects 4.4.5 and is not marked as a Regression
>>> (in the bug summary) then it is safe to assume it also affected all
>>> earlier 4.4.x releases
>>> That field isn't even always populated (it's only required for
>>> regressions). You also need to look at the Version field.
>>> A bug could have been detected in 4.4.1 and not fixed until 4.4.3, in
>>> which case it would be present in 4.4.2 but that wouldn't be in the
>>> Known to fail field, or the Version field.
>>> Or a bug could have been detected in 4.5.0 and fixed for 4.5.1, but
>>> also present in older versions too, including 4.4.2. But you wouldn't
>>> find any 4.4.x number in any field.
>>> You're going to need to do a **lot** more work than simply inspecting
>>> the Known to fail field, or any simple combination of fields.