From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423288AbcFHJBT (ORCPT ); Wed, 8 Jun 2016 05:01:19 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:32948 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751666AbcFHJBR (ORCPT ); Wed, 8 Jun 2016 05:01:17 -0400 Date: Wed, 8 Jun 2016 11:01:12 +0200 From: Ingo Molnar To: "H. Peter Anvin" Cc: Peter Zijlstra , "H. Peter Anvin" , Thomas Gleixner , Linux Kernel Mailing List , Andy Lutomirski , Borislav Petkov Subject: Re: [PATCH 02/10] x86, asm: use bool for bitops and other assembly outputs Message-ID: <20160608090111.GA11390@gmail.com> References: <1465342269-492350-1-git-send-email-hpa@linux.intel.com> <1465342269-492350-3-git-send-email-hpa@linux.intel.com> <20160608074956.GO30154@twins.programming.kicks-ass.net> <20160608082835.GB9645@gmail.com> <20160608083340.GC9645@gmail.com> <02ee64ce-257a-ba93-1f49-6877f5e4f6db@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02ee64ce-257a-ba93-1f49-6877f5e4f6db@zytor.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * H. Peter Anvin wrote: > On 06/08/16 01:33, Ingo Molnar wrote: > > > > Note that this particular build error was introduced by b0bdba9825fe, a later > > patch in this series - but in generaly I'm uneasy about allowing function > > signatures diverge between architectures. > > > > For the bitops, they already do: PowerPC, for example, have "unsigned > long" in places where x86 has "int". This is obviously undesirable, but > apparently we have not found it enough of a problem to deal with. > > One could easily argue the ppc definition is the better one; I was myself > considering promoting the x86 side to "long" to handle enormous bitmaps. At the > same time, it is hard to avoid the fact that ppc has unsigned bitops operations > and x86 has signed ones when they are both native instructions. That's a divergence with an underlying reason - but not harmonizing the return code is an unforced error AFAICS and can be fixed. Thanks, Ingo