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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
