User account creation filtered due to spam.

Bug 23242 - Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0
Summary: Invalid %sil register chosen when dereferenced pointer used in inline asm wit...
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: inline-asm (show other bugs)
Version: 4.1.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 23243 36514 37018 37887 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-08-05 00:32 UTC by ianw
Modified: 2008-10-21 21:42 UTC (History)
5 users (show)

See Also:
Host: i486-linux-gnu
Target: i486-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ianw 2005-08-05 00:32:05 UTC
Hi,

See the following snippet 

ianw@morrison:~$ gcc-snap -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,obj-c++,ada,treelang
--prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --disable-nls
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--with-java-home=/usr/lib/gcc-snapshot/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror i486-linux-gnu
Thread model: posix
gcc version 4.1.0 20050719 (experimental)

ianw@morrison:~$ cat test.c
int main()
{
  volatile unsigned char old, new, *newp;

  newp = &new;

  /* this one works OK */
  __asm__ __volatile__("xchgb %0, %1"
  : "=r"(old), "=m"(new)
  : "0"(0xff), "m"(new) : "memory");

#ifdef DEREF
  /* this one doesn't */
    __asm__ __volatile__("xchgb %0, %1"
  : "=r"(old), "=m"(*newp)
  : "0"(0xff), "m"(*newp) : "memory");
#endif

  return 0;
}

ianw@morrison:~$ gcc-snap -Wall -o test test.c

ianw@morrison:~$ gcc-snap -DDEREF -Wall -o test test.c
/tmp/cc8YTeKG.s: Assembler messages:
/tmp/cc8YTeKG.s:30: Error: bad register name `%sil'

ianw@morrison:~$ gcc-snap -O2 -DDEREF -Wall -o test test.c

I believe this to be the cause of Debian bug #321291
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321291) filed against the
libatomic_ops package (original author CC'd)
Comment 1 Andrew Pinski 2005-08-05 01:35:46 UTC
Subject: Re:  New: Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0


On Aug 4, 2005, at 8:32 PM, ianw at gelato dot unsw dot edu dot au 
wrote:

>   /* this one doesn't */
>     __asm__ __volatile__("xchgb %0, %1"
>   : "=r"(old), "=m"(*newp)
>   : "0"(0xff), "m"(*newp) : "memory");


This is not a bug.

r is selecting %sil which is a valid register for x86_64.

"r" is assuming that it is a full size register.

Use "Q" instead.

-- Pinski

PS The reason why I am CC you instead of writing this into bugzilla is 
because
bugzilla seems dead.

Comment 2 ianw 2005-08-05 02:17:15 UTC
Subject: Re:  Invalid %sil register chosen when dereferenced pointer used in inline asm with -O0

On Fri, Aug 05, 2005 at 01:35:51AM -0000, pinskia at physics dot uc dot edu wrote:
> On Aug 4, 2005, at 8:32 PM, ianw at gelato dot unsw dot edu dot au 
> wrote:
> 
> >   /* this one doesn't */
> >     __asm__ __volatile__("xchgb %0, %1"
> >   : "=r"(old), "=m"(*newp)
> >   : "0"(0xff), "m"(*newp) : "memory");
>
> This is not a bug.
> 
> r is selecting %sil which is a valid register for x86_64.

Sorry if I'm missing something, I don't work with x86-64 much, but
isn't it a wrong to consider that register when I'm building for i486?

-i
Comment 3 Richard Henderson 2005-08-05 03:14:12 UTC
No, because you still need to use "Q" to get a register that may be used
with a low-part.  Even on i486.
Comment 4 Andrew Pinski 2005-08-05 03:32:11 UTC
*** Bug 23243 has been marked as a duplicate of this bug. ***
Comment 5 Hans Boehm 2005-08-12 18:51:07 UTC
Could we reopen this as a documentation bug?  I'm still confused, and the 
amount of discussion suggests I'm not alone.  Currently "r" is documented as 
meaning "general register", with no comments about operand size.  I naively 
interpreted this to mean that the size is infered from the operand, which it 
seems to be in other cases.

"Q" means "a, b, c, or d register for 8-bit instructions that do use upper 
halves".  I don't understand why this applies to xchg.  Did you mean "q"?

Why are 8 bit registers treated separately, but not 16-bit registers?  Why does 
this only appear to be true for X86?  This is unintuitive since it seems that 
the compiler has enough information to get this right; it just choses not to.

Hans

Comment 6 Andrew Pinski 2008-06-12 21:22:06 UTC
*** Bug 36514 has been marked as a duplicate of this bug. ***
Comment 7 Andreas Schwab 2008-08-04 07:44:51 UTC
*** Bug 37018 has been marked as a duplicate of this bug. ***
Comment 8 Andreas Schwab 2008-10-21 21:42:23 UTC
*** Bug 37887 has been marked as a duplicate of this bug. ***