From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1956 invoked by alias); 15 Apr 2005 14:52:47 -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 1879 invoked by alias); 15 Apr 2005 14:52:39 -0000 Date: Fri, 15 Apr 2005 14:52:00 -0000 Message-ID: <20050415145239.1878.qmail@sourceware.org> From: "roger at eyesopen 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/msg02069.txt.bz2 List-Id: ------- Additional Comments From roger at eyesopen dot com 2005-04-15 14:52 ------- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On 15 Apr 2005, Alexandre Oliva wrote: > On Apr 12, 2005, Roger Sayle wrote: > > I still like your fallbacks, that by trying harder we perform > > better optimization, > > The more I think about this, the more I have the impression that > perhaps the fallbacks are not necessary. > ... > So I'm wondering if taking out all of the workarounds and going back > to something like what is now in the 4.0 branch, except for the use of > validate_change_maybe_volatile, wouldn't get us exactly what we want. > ... > Anyhow, in the meantime, could I check in the patch to fix Josh's > asm-elf build failure? > ... > It would be nice to keep the hard failure in place for a bit longer, > such that we stood a better chance of finding other situations that > might require work arounds. Sure. Your patch in comment #28 of bugzilla PR20126 is OK for mainline to resolve Josh's bootstrap failure. Sounds like you've already done the necessary testing, and I'll trust you on a suitable ChangeLog entry. 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). Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126