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