This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Policy for wrong-code bugs


On 13 Jul, Daniel Berlin wrote:
>>>
>>> An intermediate policy would be to close them when a compiler that 
>>> fixes
>>> the bug is actually released to the public.
>>>
>>> In any case, it would be nice to be able to track wrong-code bugs that
>>> exist in current, shipping compilers.
>>>
>> I think that Volker's proposal makes sense in the abstract, but will 
>> be confusing in practice.  People are still using really old compilers 
>> -- we have a customer where we are still supporting GCC 2.8.1, for 
>> example.  Keeping PRs open for all current, shipping compilers means 
>> never closing any PR ever.  I think using "closed" to mean "a fix is 
>> available somewhere" is useful; for example, it means that you can 
>> perhaps backport the change to some older compiler.

Well, in the case of the bug that inspired my mail (PR 16471) there's
no backport available, since it was fixed by the merge of tree-ssa.
So there's a need for a different fix for the 3.3 and 3.4 branch.

Btw, perhaps the bug only got pasted over by tree-ssa. Maybe it
reappears in some different scenario. :-(

> Right.
> We have a known to work/fail field, so you can tell if the wrong code 
> bug you've got is fixed in a given version of the compiler to see if a 
> backport is needed at all.
> Also, it's not like closed bugs disappear of the face of the earth. you 
> can still find them with queries.

But that's not feasible in practice. You usually have some big chunk of
code that does not behave as expected. You have to spend quite a long
time to find out that this is in fact a compiler bug. Coming up with
a reduced example is often rather difficult since wrong-code bugs are
often caused by wrong optimizations. Heisenbugs come to mind.

After hours or even days of work (just try to reduce those nasty
POOMA testcases in the database) you might come up with a decent
testcase. And *then* you can start to have a look in the database
to see whether this might be fixable for you.

And this is the kind of pain, that we should not put on the user lightly
when we already have a decent testcase.

Regards,
Volker



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]