From mboxrd@z Thu Jan 1 00:00:00 1970 From: Borislav Petkov Subject: Re: PROPOSAL: Extend inline asm syntax with size spec Date: Sat, 13 Oct 2018 23:30:15 +0200 Message-ID: <20181013213015.GG31650@zn.tnic> References: <20181009145330.GT29268@gate.crashing.org> <20181010072240.GB103159@gmail.com> <20181010080324.GV29268@gate.crashing.org> <20181010081906.GA5533@zn.tnic> <20181010185432.GB29268@gate.crashing.org> <20181010191427.GF5533@zn.tnic> <20181013193335.GD31650@zn.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Alexander Monakov Cc: Kate Stewart , Peter Zijlstra , Christopher Li , virtualization@lists.linux-foundation.org, Masahiro Yamada , Nadav Amit , Jan Beulich , "H. Peter Anvin" , Sam Ravnborg , Ingo Molnar , x86@kernel.org, linux-sparse@vger.kernel.org, Ingo Molnar , linux-xtensa@linux-xtensa.org, Kees Cook , Segher Boessenkool , Chris Zankel , Michael Matz , Josh Poimboeuf , Alok Kataria , Juergen Gross , gcc@gcc.gnu.org, Richard Biener , Max Filippov , Greg Kroah-Hartman linux List-Id: linux-sparse@vger.kernel.org On Sun, Oct 14, 2018 at 12:14:02AM +0300, Alexander Monakov wrote: > I apologize for coming in late here with an alternative proposal, but would > you be happy if GCC gave you a way to designate a portion of the asm template > string that shouldn't be counted as its cost because it doesn't go into the > .text section? This wouldn't interact with your redefinitions of the inline > keyword, and you could do something like (assuming we go with %` ... %` > delimiters) I don't mind it but I see you guys are still discussing what would be the better solution here, on the gcc ML. And we, as one user, are a happy camper as long as it does what it is meant to do. But how the feature looks like syntactically is something for gcc folk to decide as they're going to support it for the foreseeable future and I'm very well aware of how important it is for a supportable feature to be designed properly. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.