Re: egcs-problem 1.0.2

Re: egcs-problem 1.0.2

[H.J. Lu]

> 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>


Please don't use anything from <linux/> or <asm/> directly in
the user codes unless it it is absolutely necessary.

> 
> 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. 
> 
> 
> 

# gcc -O2 -fno-strength-reduce foo.c
# a.out
zsh: 2924 segmentation fault  ./a.out

I am not sure if it is a bug or not. The problem is when an asm
statement marks a register as clobber, how can egcs safely use it
for the asm statement? I think when a register is marked as clobber,
egcs cannot use it inside the asm statement via %0, %1, %2, .... Is
there a fix for that? The bug may be in combine.

Thanks.


H.J.
---foo.c--
extern inline char * strstr(const char * cs,const char * ct)
{
register char * __res;
__asm__ __volatile__(
	"cld\n\t" \
	"movl %4,%%edi\n\t"
	"repne\n\t"
	"scasb\n\t"
	"notl %%ecx\n\t"
	"decl %%ecx\n\t"
	"movl %%ecx,%%edx\n"
	"1:\tmovl %4,%%edi\n\t"
	"movl %%esi,%%eax\n\t"
	"movl %%edx,%%ecx\n\t"
	"repe\n\t"
	"cmpsb\n\t"
	"je 2f\n\t"
	"xchgl %%eax,%%esi\n\t"
	"incl %%esi\n\t"
	"cmpb $0,-1(%%eax)\n\t"
	"jne 1b\n\t"
	"xorl %%eax,%%eax\n\t"
	"2:"
	:"=a" (__res):"0" (0),"c" (0xffffffff),"S" (cs),"g" (ct)
	:"cx","dx","di","si");
return __res;
}

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;
}

main ()
{
  char * haystacks [] = {"foobar", 0};
  char * needles  [] = {"foo", 0};

  if (count_substring_matches (haystacks, needles ) != 1)
    abort ();

  return 0;
}

Re: egcs-problem 1.0.2

[Jeffrey A Law]

  In message < m0yLfGJ-00058xC@ocean.lucon.org >you write:
  > > 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>
  > 
  > 
  > Please don't use anything from <linux/> or <asm/> directly in
  > the user codes unless it it is absolutely necessary.
  > 
  > > 
  > > 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;
  > > }
This is the "linux asm" problem that I haven't been able to look at
for the last month or so due to personal and company commitments.

Basically there's a couple problems:

  * The linux x86 asm for strstr is totally bogus.

  * GCC does not issue a warning/error when it encouters the bogus
  asm and instead generates incorrect code.

jeff

Re: egcs-problem 1.0.2

[H.J. Lu]

> This is the "linux asm" problem that I haven't been able to look at
> for the last month or so due to personal and company commitments.
> 
> Basically there's a couple problems:
> 
>   * The linux x86 asm for strstr is totally bogus.

Does the code below make sense?

> 
>   * GCC does not issue a warning/error when it encouters the bogus
>   asm and instead generates incorrect code.

Agreed. I don't think it is too hard to issue an error.


Thanks.


-- 
H.J. Lu (hjl@gnu.org)
----
extern inline char * strstr(const char * cs,const char * ct)
{
register char * __res;
__asm__ __volatile__(
	"cld\n\t" \
	"movl %4,%%edi\n\t"
	"repne\n\t"
	"scasb\n\t"
	"notl %%ecx\n\t"
	"decl %%ecx\n\t"
	"movl %%ecx,%%edx\n"
	"1:\tmovl %4,%%edi\n\t"
	"movl %%esi,%%eax\n\t"
	"movl %%edx,%%ecx\n\t"
	"repe\n\t"
	"cmpsb\n\t"
	"je 2f\n\t"
	"xchgl %%eax,%%esi\n\t"
	"incl %%esi\n\t"
	"cmpb $0,-1(%%eax)\n\t"
	"jne 1b\n\t"
	"xorl %%eax,%%eax\n\t"
	"2:"
	:"=a" (__res):"0" (0),"c" (0xffffffff),"S" (cs),"m" (ct)
	:"cx","dx","di","si");
return __res;
}

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;
}

main ()
{
  char * haystacks [] = {"foobar", 0};
  char * needles  [] = {"foo", 0};

  if (count_substring_matches (haystacks, needles ) != 1)
    abort ();

  return 0;
}

Re: egcs-problem 1.0.2

[Jeffrey A Law]

  In message < m0yLuSz-00058iC@ocean.lucon.org >you write:
  > > This is the "linux asm" problem that I haven't been able to look at
  > > for the last month or so due to personal and company commitments.
  > > 
  > > Basically there's a couple problems:
  > > 
  > >   * The linux x86 asm for strstr is totally bogus.
  > 
  > Does the code below make sense?
Not sure what you're asking.  If you want I can resend the analysis.
Basically the clobbers are bogus and the asm itself uses too many
registers to be safely compiled.

This is the exact code we're using as an example of the asm problems
that we need to address.

  > > 
  > >   * GCC does not issue a warning/error when it encouters the bogus
  > >   asm and instead generates incorrect code.
  > 
  > Agreed. I don't think it is too hard to issue an error.
The problem is that many linux asms use a invalid construct, so
the error has to be conditional so that the linux folks have the
opportunity to transition away from the bogus way they've been
writing asms.


jeff

Re: egcs-problem 1.0.2

[H.J. Lu]

> 
> 
>   In message < m0yLuSz-00058iC@ocean.lucon.org >you write:
>   > > This is the "linux asm" problem that I haven't been able to look at
>   > > for the last month or so due to personal and company commitments.
>   > > 
>   > > Basically there's a couple problems:
>   > > 
>   > >   * The linux x86 asm for strstr is totally bogus.
>   > 
>   > Does the code below make sense?
> Not sure what you're asking.  If you want I can resend the analysis.
> Basically the clobbers are bogus and the asm itself uses too many
> registers to be safely compiled.
> 

Why the clobbers are bogus? I changed one constraint from "g" to "m".
It seems to work fine for me. As long as the asm statement specifies
them as the clobbers and egcs doesn't use them inside the asm statement,
how can number of registers used in the asm statement be a problem with
egcs?

-- 
H.J. Lu (hjl@gnu.org)

Re: egcs-problem 1.0.2

[Jeffrey A Law]

  In message < m0yLupl-00058JC@ocean.lucon.org >you write:
  > > 
  > > 
  > >   In message < m0yLuSz-00058iC@ocean.lucon.org >you write:
  > >   > > This is the "linux asm" problem that I haven't been able to look at
  > >   > > for the last month or so due to personal and company commitments.
  > >   > > 
  > >   > > Basically there's a couple problems:
  > >   > > 
  > >   > >   * The linux x86 asm for strstr is totally bogus.
  > >   > 
  > >   > Does the code below make sense?
  > > Not sure what you're asking.  If you want I can resend the analysis.
  > > Basically the clobbers are bogus and the asm itself uses too many
  > > registers to be safely compiled.
  > > 
  > 
  > Why the clobbers are bogus? I changed one constraint from "g" to "m".
  > It seems to work fine for me. As long as the asm statement specifies
  > them as the clobbers and egcs doesn't use them inside the asm statement,
  > how can number of registers used in the asm statement be a problem with
  > egcs?
inputs and clobbers may not overlap.  The way to do what they want to
do is via matching input/output with an earlyclobber.

Additionally operands may come from memory which is accessed via
reg+reg addressing modes which will cause the compiler to run out
of asms.  This is the case even when the operand specifies a register
(it may need to be reloaded from a reg+reg address).

I've already discussed this at length with the Linux folks.

jeff