From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2629 invoked by alias); 16 Apr 2005 21:58:13 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 2595 invoked by alias); 16 Apr 2005 21:58:08 -0000 Date: Sat, 16 Apr 2005 21:58:00 -0000 Message-ID: <20050416215808.2594.qmail@sourceware.org> From: "aoliva at redhat dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050221214433.20126.jkohen@users.sourceforge.net> References: <20050221214433.20126.jkohen@users.sourceforge.net> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry X-Bugzilla-Reason: CC X-SW-Source: 2005-04/txt/msg02204.txt.bz2 List-Id: ------- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-16 21:58 ------- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On Apr 15, 2005, Roger Sayle wrote: > I agree with your proposed game plan of keeping the hard failure in > place temporarily, to discover whether there are any other "fallback" > strategies that would be useful. Ultimately though, I don't think we > should close PR20126 until a "soft failure" is implemented on mainline, > like we've (Jakub has) done on the gcc-4_0-branch (such as the > mainline code proposed in comment #30). But see, the problem with the soft failure mode is that, if it is ever legitimate to leave the giv alone and not make sure we set whatever register appears in it to the right value, then can't we always do it, removing all of the (thus useless) workarounds? And if there's any case in which it is not legitimate to do so, then the soft failure mode would be a disservice to the user, that would silently get a miscompiled program. We should probably at least warn in this case. Anyhow, here's a patch that was tested with bootstrap and regtest on amd64-linux-gnu on mainline, that brings in the soft failure mode from the 4.0 branch to mainline, without removing the potentially-useless workarounds. Index: gcc/loop.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/loop.c,v retrieving revision 1.526 diff -u -p -r1.526 loop.c --- gcc/loop.c 10 Apr 2005 04:00:45 -0000 1.526 +++ gcc/loop.c 16 Apr 2005 21:37:45 -0000 @@ -5494,11 +5494,23 @@ loop_givs_rescan (struct loop *loop, str rtx reg, seq; start_sequence (); reg = force_reg (v->mode, *v->location); - seq = get_insns (); - end_sequence (); - loop_insn_emit_before (loop, 0, v->insn, seq); - if (!validate_change_maybe_volatile (v->insn, v->location, reg)) - gcc_unreachable (); + if (validate_change_maybe_volatile (v->insn, v->location, reg)) + { + seq = get_insns (); + end_sequence (); + loop_insn_emit_before (loop, 0, v->insn, seq); + } + else + { + end_sequence (); + if (loop_dump_stream) + fprintf (loop_dump_stream, + "unable to reduce iv in insn %d\n", + INSN_UID (v->insn)); + bl->all_reduced = 0; + v->ignore = 1; + continue; + } } } else if (v->replaceable) -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126