[llvmlinux] Multiple storage class error

Renato Golin renato.golin at linaro.org
Sat Nov 16 15:17:31 UTC 2013

On 16 November 2013 13:38, Tinti <viniciustinti at gmail.com> wrote:

> Hi,
> I think we should change one of our patches to not use 'static register'
> as comment in this link http://www.lemoda.net/c/keywords/register.html

Hi Tinti,

The C standard (6.7.1p5) says:

"A declaration of an identifier for an object with storage-class specifier
suggests that access to the object be as fast as possible. The extent to
which such
suggestions are effective is implementation-defined."

Which basically means, "register" is just a hint. Compilers can, and do,
ignore such hints over optimizations, register pressure, vectorization, etc.

While the standard doesn't allow you to take the address of a register
variable (, all the other constraints are undefined behaviour.

The problem with "static register" is not that both cannot coexist, but
that "At most, one storage-class specifier may be given in the declaration
specifiers in a
declaration" (6.7.1p1).

#elif defined(__clang__)
> #define __builtin_stack_pointer() ({ \
>         unsigned long current_sp; \
>         asm ("mov %0, sp" : "=r" (current_sp)); \
>         current_sp; \
> })

I thought you guys were using the modified version, without the mov...

#else /* gcc */

This is horrendous! Is this in the kernel, or is it one of our local

We should never assume anything on the #else, but specifically require what
you want.

#else should *only* have one of:
 * A behaviour that is commonly known as global, generally as an
alternative to a very specific behaviour in the #if
 * An error message

> static register unsigned long current_stack_pointer asm ("sp");
>    <==================
> If we do so, we get kernel-gcc back to work on vexpress. What do you think?

Global register variables doesn't make sense. But this is clearly a special
case, which means all bets are off.

I'd be inclined to say that just "static" would be enough there, but that
depends on how GCC interpret asm variables. What is the original code for
that line in the vanilla kernel?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20131116/839ca61c/attachment.html>

More information about the LLVMLinux mailing list