Re: Compilation problem in ndisc.c / 2.5.1-pre2 : possible gcc bug?

[Brian Gerst <bgerst@didntduck.org>]

"Richard B. Johnson" wrote:
> 
> On Wed, 28 Nov 2001, Martin Eriksson wrote:
> 
> > ----- Original Message -----
> > From: "Richard B. Johnson" <root@chaos.analogic.com>
> > To: <erik@hensema.net>
> > Cc: <linux-kernel@vger.kernel.org>
> > Sent: Wednesday, November 28, 2001 8:09 PM
> > Subject: Re: Compilation problem in ndisc.c / 2.5.1-pre2 : possible gcc bug?
> >
> >
> > > On 28 Nov 2001, Erik Hensema wrote:
> > >
> > > >
> > > > I've been looking into the compile problems of net/ipv6/ndisc.c in
> > > > 2.5.1-pre2 and I found that the asm generated by gcc (2.95.3) is wrong:
> > > >
> > > > This is a small part of a diff betweem two asm files generated by gcc,
> > note
> > > > the missing \n's in the wrong code:
> > > >
> > > > -
> > > > - addl 0(%ebp), %edx
> > > > - adcl 4(%ebp), %edx
> > > > - adcl 8(%ebp), %edx
> > > > - adcl 12(%ebp), %edx
> > > > - adcl 0(%ecx), %edx
> > > > - adcl 4(%ecx), %edx
> > > > - adcl 8(%ecx), %edx
> > > > - adcl 12(%ecx), %edx
> > > > - adcl %edi, %edx
> > > > - adcl %eax, %edx
> > > > - adcl $0, %edx
> > > > -
> > > > + addl 0(%ebp), %edxadcl 4(%ebp), %edxadcl 8(%ebp), %edxadcl 12(%ebp),
> > %edxadcl 0(%ecx), %edxadcl 4(%ecx), %edxadcl 8(%ecx), %edxadcl 12(%ecx),
> > %edxadcl %edi, %edxadcl %eax, %edxadcl $0, %edx
> > >
> > >
> > > This is probably just some loop unrolling, not some as you say "wrong
> > > code".
> >
> > Correct me if I'm wrong, but I don't think "%edxadcl" really assembles....
> 
> No, but an edited 'diff' of the assembly output of a 'C' compiler doesn't
> really tell much. Note, no line numbers, no clue as to what the diff
> was about. The actual defective section of code would be much more
> instructive. For instance, is this as a result of an in-line macro
> expansion; the result of a <CR><LF> 'dos' file; the true output of
> a 'C' file with no __inline__ __asm__?

It's from include/asm-i386/checksum.h, specifically csum_ipv6_magic(). 
The asm statements in this header file need semicolons or explicit
newlines after each opcode.

--

				Brian Gerst