[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Impact of bugs on different versions.
From:       Vicent Brocal Tortosa <vbrocal () fentiss ! com>
Date:       2017-09-21 16:20:15
Message-ID: 93706D59-63A3-4B44-864A-1B8EF696C5E7 () fentiss ! com
[Download RAW message or body]


El 21 set 2017, a les 17:50, Martin Sebor <msebor@gmail.com> 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).
> 
> Martin

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
>>>> (https://gcc.gnu.org/bugzilla/).
>>>> 
>>>> 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?
>>> No.
>>> 
>>>> 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.
>> 
>> ------------------------------------------------------------------------



[prev in list] [next in list] [prev in thread] [next in thread]