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

[Bruce Evans]

On Sat, 28 Jun 2008, Christoph Mallon wrote:

> Bruce Evans wrote:
>> Does sparc64 do anything good with this?  Later it says that this is
                                       [cc clobber in asm statements]
>> irrelevant for the type type of bug in in_cksum.* (expecting cc to
>> be preserved across separate asms).  From gcc.info:
>
> 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?

> The bpl is supposed to jump depending on the condition of the subcc, but if 
> the compiler schedules the inline assembler block between the subcc and the 
> bpl, it jumps depending on garbage.
> It was not expected to preserve the condition codes across separate inline 
> assembler blocks, but it was not specified that the single inline assembler 
> block did 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.

>> % code left by the assembler instruction.  However, when we attempted to
>> % implement this, we found no way to make it work reliably.  The problem
>>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> % is that output operands might need reloading, which would result in
>> % additional following "store" instructions.  On most machines, these
>> % instructions would alter the condition code before there was time to
>> % test it.  This problem doesn't arise for ordinary "test" and "compare"
>> % instructions because they don't have any output operands.
>> % %  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.

>> 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
around (e.g., almost all in FreeBSD and many in Linux) for gcc to preserve
compatiblity by not changing its assumption (for insignificant benefits
since gcc doesn't really understand cc in asms).  (Linux-2.6.10/include/
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.

Bruce