Re: const versus __attribute__((const))

[H. Peter Anvin]

Linus Torvalds wrote:
> And as far as I know, it won't. Newer gcc's will _require_ memory
> arguments to be lvalues (well, it will warn if they aren't), and will
> always turn them into addressables of that particular lvalue.

Well, I get no warning from the following code, with gcc 3.2.2 and -W -Wall:

int foo(int x)
{
  int y, z, w;

  asm("movl %1,%0" : "=r" (y) : "r" (x));
  asm("movl %1,%0" : "=r" (z) : "m" (y+1));
  asm("movl %1,%0" : "=r" (w) : "m" (33));

  return z+w;
}

The memory operand is definitely not an lvalue.  gcc allocates a stack slot
for the y+1 value as a temporary automatic and passes it in.  The value 33
is put in the .rodata segment:

00000000 <foo>:
   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   50                      push   %eax
   4:   8b 45 08                mov    0x8(%ebp),%eax
   7:   89 c0                   mov    %eax,%eax
   9:   40                      inc    %eax
   a:   89 45 fc                mov    %eax,0xfffffffc(%ebp)
   d:   8b 15 00 00 00 00       mov    0x0,%edx
                        f: R_386_32     .rodata.cst4
  13:   8b 45 fc                mov    0xfffffffc(%ebp),%eax
  16:   01 d0                   add    %edx,%eax
  18:   c9                      leave
  19:   c3                      ret

> This is actually an issue, because some asm code depends on getting the
> proper address - not just the proper value. Things like locks etc care
> _deeply_ about more than just the value.

That would be a very bad thing indeed.  Fortunately I think it would take
some rather odd contortions on the part of the compiler for that situation
to occur at all, I would think, and if the gcc people have since been
made aware of it it should be pretty easy for them to make sure it will not
happen.

	-hpa

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/