On Sun, Feb 28, 2016 at 9:48 AM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Sat, Feb 27, 2016 at 3:59 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>> On Thu, Feb 25, 2016 at 11:50 PM, Jeff Law <l...@redhat.com> wrote:
>>> On 02/25/2016 03:00 AM, Richard Biener wrote:
>>>>
>>>>
>>>> So I fail to see how only successor edges are relevant. Isn't the
>>>> important
>>>> case to catch whether we remove an edge marked EDGE_IRREDUCIBLE_LOOP?
>>>> Even if the BB persists we might have exposed a new loop here.
>>>>
>>>> Note that it is not safe to look at {BB,EDGE}_IRREDUCIBLE_LOOP if the loop
>>>> state does not have LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS set
>>>> (the flags may be stale or missing). So it might be that we can't rely on
>>>> non-loop passes modifying the CFG to handle this optimistically.
>>>>
>>>> Thus, how about (my main point) moving this to remove_edge instead, like
>>>
>>> Yea. That works. The !loops_state_satisfies_p check will almost certainly
>>> cause us to trigger loop cleanups more often, but I think it's the
>>> right/safe thing to do to catch cases where we haven't go the
>>> IRREDUCIBLE_LOOP flags set.
>>>
>>>
>>> Bootstrapped and regression tested on x86_64-linux-gnu. OK for the trunk?
>>>
>>> Thanks,
>>> Jeff
>>>
>>>
>>> PR tree-optimization/69740
>>> * cfghooks.c (remove_edge): Request loop fixups if we delete
>>> an edge that might turn an irreducible loop into a natural
>>> loop.
>>>
>>> PR tree-optimization/69740
>>> * gcc.c-torture/compile/pr69740-1.c: New test.
>>> * gcc.c-torture/compile/pr69740-2.c: New test.
>>>
>>
>> This caused:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69996
>>
>> and may be other build failures in SPEC CPU 2006.
>>
>
> I checked this patch into trunk and will backport it to GCC 5 branch.
> This test doesn't fail and all SPEC CPU 2000/2006 benchmarks pass
> on GCC 5 branch with the fix for PR 69740 applied. Is it possible that
> the fix for PR 69740 exposed a latent bug on trunk?
>
This will also show up on GCC 5 if ENABLE_CHECKING is defined.
--
H.J.
