> Agreed. And I've got that message from Gabriel. But what I do
> not have is something I can compile which will show the bug. Can
> someone please send me an actual use of the asm which generates
> incorrect code? ie, something I can feed directly into the compiler
> so that I can analyze why the compiler is generating the wrong code.
I did send an example of bad code generation yesterday. I have appended it
again in case it got lost. But perhaps it's sitting idle somewhere in
between, I've already seen E-mail messages taking 2 months to reach me,
and 3 weeks is not uncommon here :-(
> The asm itself isn't enough, these kinds of bugs usually depend on
> the use and code surrounding the use.
True, and it also strongly depends on compiler options in this case. But
this code (I unfortunately deleted the example that generated bad code
when I had 2.7.2.1 but it was _very_ similar to this one).
It seems that the clobbered registers are not considered as early-clobbers
for address generation. When using explicit earlyclobbers, I've never been
able to generate similar code even when increasing register pressure,
instead the compiler exits claiming that a forbidden register was spilled,
for example %esp !
Regards,
Gabriel.
== Excerpt from yesterday's message ==
On Wed, 25 Feb 1998, Jeffrey A Law wrote:
> I think the best way to proceed is for someone to give me a hunk of
> code that I can feed the compiler that will show a case where a
> clobber is being used for input addressing. That way I can debug
> the compiler and see what's really happening.
I can't keep up with the weekly updates, so my GCC currently is:
gcc version egcs-2.91.06 980122 (gcc-2.8.0 release)
The following code breaks when compiled with -fno-strength-reduce, but
independantly of -O2/-O3, -fomit-frame-pointer, and -m[345]86:
===============================================================================
#include <linux/string.h>
int count_substring_matches(char **haystacks, char **needles)
{
int hits=0, i, j;
for(i=0; haystacks[i]; i++) {
for(j=0; needles[j]; j++) {
if (strstr(haystacks[i], needles[j])) hits++;
}
}
return hits;
}
===============================================================================
generates for the strstr function:
===============================================================================
#APP
cld
movl (%ebx,%edx,4),%edi
repne
scasb
notl %ecx
decl %ecx
movl %ecx,%edx
1: movl (%ebx,%edx,4),%edi
movl %esi,%eax
movl %edx,%ecx
repe
cmpsb
je 2f
xchgl %eax,%esi
incl %esi
cmpb $0,-1(%eax)
jne 1b
xorl %eax,%eax
2:
#NO_APP
===============================================================================
in this precise case the problem is with %edx. Other compilers/versions
used %edi in the address computation. Note that it generates correct code
when I exchange the order of the nested loops !
If I add -fpic the addressing mode is even able to use two
clobbered registers and becomes (%edx,%edi,4), and only -fstrength-reduce
-fomit-frame-pointer generates correct pic code. Otherwise the compiler
sometimes reloads %edi with movl (%edx),%edi.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu