cvs commit: src/sys/sparc64/include in_cksum.h

[Christoph Mallon]

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