From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19272 invoked by alias); 4 Jul 2013 19:08:39 -0000 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 Received: (qmail 19210 invoked by uid 48); 4 Jul 2013 19:08:32 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/29776] result of ffs/clz/ctz/popcount/parity are already sign-extended Date: Thu, 04 Jul 2013 19:08:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.3.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-07/txt/msg00278.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776 --- Comment #12 from Jakub Jelinek --- Not all CPUs that have defined behavior for 0 define it to the precision though, and even on i?86 it is undefined even when using lzcnt/tzcnt on older CPUs. Even the libgcc routines provide various return values for 0 depending on target (look for COUNT_LEADING_ZEROS_0). So it is not an option to redefine the builtins, they are undefined behavior for 0 and that can't change. There is __builtin_ffs that provides defined behavior for 0.