From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7432 invoked by alias); 8 Jun 2010 15:09:47 -0000 Received: (qmail 7384 invoked by uid 48); 8 Jun 2010 15:09:33 -0000 Date: Tue, 08 Jun 2010 15:09:00 -0000 Message-ID: <20100608150933.7383.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/44413] inefficient code for std::string::compare on x86-64 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "paolo dot carlini at oracle dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-06/txt/msg00903.txt.bz2 ------- Comment #4 from paolo dot carlini at oracle dot com 2010-06-08 15:09 ------- I'm not convinced. The code at issue is used when memcmp returns zero, thus one string is a prefix of the other, a well defined situation. For *eons* we have been returning a number which is much larger (in modulo) if one string is much longer. Before considering changing this, I want to see a very solid real life example, with numbers, of code benefiting from this tuning. Otherwise, I guess we'll do it, but only when we'll break the ABI. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44413