https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081

--- Comment #50 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to David Edelsohn from comment #48)
> Based on Comment #45, is this a problem in the Stage 1 compilers?  Note that
> Alan and Segher adjusted the doloop patterns in this release cycle.  Does
> backporting that patch or bootstrapping with current trunk function better?

The stage2 compiler fails to build anything (libgcc in this case) because the
stage1 compiler miscompiled the testcase I posted.

I tried backporting the following two patches to no avail:

commit b2d4fe71855caaae720f7839d3e33b061d2069ca
Author: amodra <amodra@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Sat Jan 14 13:24:46 2017 +0000

    Avoid PR72749 by not using unspecs

    Rather than using unspecs in doloop insns to stop combine creating
    these insns, use legitimate_combined_insn.

            PR target/72749
            * combine.c (recog_for_combine_1): Set INSN_CODE before calling
            target legitimate_combined_insn.
            * config/rs6000/rs6000.c (TARGET_LEGITIMATE_COMBINED_INSN): Define.
            (rs6000_legitimate_combined_insn): New function.
            * config/rs6000/rs6000.md (UNSPEC_DOLOOP): Delete, and remove
            all uses.
            (ctr<mode>_internal3): Rename from *ctr<mode>_internal5.
            (ctr<mode>_internal4): Rename from *ctr<mode>_internal6.
            (ctr<mode>_internal1, ctr<mode>_internal2): Remove '*' from name.

commit d7a73763f9dfa9cec35bcf40d926ee03ae85fb2d
Author: amodra <amodra@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Mon Jul 11 10:28:48 2016 +0000

    [RS6000] Don't allow combine to form doloop pattern

            * config/rs6000/rs6000.md (UNSPEC_DOLOOP): New unspec.
            (ctr<mode>): Add unspec.
            (ctr<mode>_internal*): Likewise.

And yes, I'm sure bootstrapping the current trunk would work, but that would
have us back at square one, having no idea why the patch in question is now
bootstrapping ;-).

I suppose we could remove Richi's patch that makes the problem disappear, and
bisect forward to see if there's another set of patches that also fix the
problem but are related to doloop or the patch at hand.  Though at this point,
I'd rather we figure out why the erroneous code is being generated in comment
45.  Bisecting AIX and the hand-holding required takes a good hour and a half
at each of the 13 iterations it would at least take.

Reply via email to