cvs commit: src/sys/sparc64/include in_cksum.h
christoph.mallon at gmx.de
Sun Jun 29 06:55:51 UTC 2008
Bruce Evans wrote:
>> I think the bug was the following:
>> subcc %foo, %bar, %g0 /* SPARC compare */
>> /* inline assembler of in_addword() here, which modifies the condition
>> codes */
>> 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
> Certainly if gcc wants to put asm block in the middle of generated code,
> 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
>>> 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 information about the cvs-all