From owner-cvs-all@FreeBSD.ORG Sun Jun 29 06:55:51 2008 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D4321065684 for ; Sun, 29 Jun 2008 06:55:51 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id AA6878FC1F for ; Sun, 29 Jun 2008 06:55:50 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 29 Jun 2008 06:55:48 -0000 Received: from p54A3F259.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.242.89] by mail.gmx.net (mp003) with SMTP; 29 Jun 2008 08:55:48 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/NkAo+Y6nNBM2nQvaRiDtncEoYBGeSNiyWBFff0q TvsKpxhcL2tbY0 Message-ID: <486731F4.9050400@gmx.de> Date: Sun, 29 Jun 2008 08:55:48 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.9 (X11/20071230) MIME-Version: 1.0 To: Bruce Evans References: <200806252105.m5PL5AUp064418@repoman.freebsd.org> <48654667.1040401@gmx.de> <20080628114028.M89039@delplex.bde.org> <4865F895.8030600@gmx.de> <20080629132901.Q92490@delplex.bde.org> In-Reply-To: <20080629132901.Q92490@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: cvs-src@freebsd.org, Marius Strobl , src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/sparc64/include in_cksum.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2008 06:55:51 -0000 Bruce Evans wrote: >> I think the bug was the following: >> subcc %foo, %bar, %g0 /* SPARC compare */ >> #APP >> /* inline assembler of in_addword() here, which modifies the condition >> codes */ >> #NO_APP >> bpl $somewhere /* condition branch depending on condition code */ > > Is the non-#APP part all from C code? Yes, this is an example what happend here: The compiler moved an assembler block between code generated from C. The C code uses the condition codes, but the assembler code destroys the contents. This happens, when "cc" is not in the clobber list, because the C compiler (correctly) assumes that the assembler code does not modify the condition codes. > Certainly if gcc wants to put asm block in the middle of generated code, > then > it needs to know all the clobbers. Exactly. It's always a good idea not to lie to your compiler. (: >>> % % For reasons similar to those described above, it is not possible to >>> ^^^^^^^^^^^^^^^^^^^^^ >>> % give an assembler instruction access to the condition code left by >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> % previous instructions. >>> ^^^^^^^^^^^^^^^^^^^^^^ >> >> I think the excerpt does not apply here, because the problem is the >> other way round (inline assembler interrupting C, not C interrupting >> multiple inline assembler blocks), see above. > > Yes, it doesn't apply to any asm code wrapped in inline functions (except > to the internals of the functions). No one would expect an inline function > to return results in the condition codes. This is not about returing values in condition codes or inline functions. It is about an assembler block, which simply destroys the contents of the condition codes and the compiler not expecting this (because nobody told it). >>> On i386, specifying cc has no effect (the compiler must always assume >>> that >>> cc is clobbered), and specifying cc in asms is a style bug in FreeBSD. >> >> I have to disagree. Where does the GCC documentation state, that "cc" >> has no effect on x86? It is the other way round: The compiler assumes, >> the condition codes are *not* modified, if it is not explicitely >> stated. Exactly this caused the bug (though here on SPARC), which was >> tried to be solved by volatile. I still am convinced that specifying >> "cc" in the clobber list and not using volatile is the correct >> solution. If it is a style bug to specify "cc", the style should be >> changed, otherwise you cannot use inline assembler correctly. > > Well, in gcc-1.40, gcc.info says nothing about "cc", apparently because > "cc" didn't exist in gcc-1.40. gcc-1.40 had to assume that cc was > always clobbered. I think there are enough old i386 asm statements GCC 1.4? Would you please bury this corpse again? It smells. (; > around (e.g., almost all in FreeBSD and many in Linux) for gcc to preserve > compatiblity by not changing its assumption (for insignificant benefits I've seen quite a bit assembler code break when going from 3.x to 4.x, because GCC moves assembler blocks more while scheduling and takes the given in/out constraints much more seriously. > since gcc doesn't really understand cc in asms). (Linux-2.6.10/include/ It's not about "understanding cc in asms", it's just about telling GCC that the "cc" does not survive the assembler block undamaged. > asm-i386/*.h has 177 __asm__ statements (133 with volatile) with only > 11 "cc"'s. Examples of ones without "cc"'s are everything in string.h, > where things like scasb for strcmp() normally clobber "cc".) > > Newer versions of gcc.info have to say to use it in clobber lists, to > support CPUs with a shorter history than i386 and to prepare for changing > the assumptions on i386. Three fourth of the assembler statements needing volatile seems way to high to me. I did not find the strcmp() implementation, which uses scasb. I only found strcmp.S, which is not inline assembler and does not use scas either, which would have suprised me (nor cmpsb, which would be more logical). Regards Christoph