[llvmlinux] Multiple storage class error

[Renato Golin]

On 16 November 2013 21:54, Behan Webster <behanw at converseincode.com> wrote:

>  We'd actually like to replace it's use with __builtin_stack_pointer()
> (something we're trying to get added to both clang and gcc).
>

I know. Did you get far in the GCC list? I think we all agree it would be a
good addition in Clang.


#else /* gcc */
>>
>
>  This is horrendous! Is this in the kernel, or is it one of our local
> patches?
>
> That is the way it is currently done in the kernel with gcc. I've merely
> moved it to one place from the various places it is copied to in the ARM
> portion of the kernel.
>
> The x86 kernel does exactly this (define a global named register variable
> to access "esp").
>

I expected as much. ;) Sigh...


#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
>
> Which is exactly what this patch does.
>

Not really. The #else code contains a GCC extension, which is not in the C
standard, is using undefined behaviour and was not an extension agreed
across multiple compilers (like __builtin_stack_pointer would be).


 * An error message
>
> Which would break the kernel. gcc IS the default case.
>

Well, isn't that what we're trying to change?

What I'm saying is that, since we're now changing the kernel to become
compiler-agnostic, we might just as well fix the GCC-specific assumptions,
at least on the parts we touch.

So, in that case, you could have an #elif __gcc with the GCC case and an
#else with an error message "Compiler doesnt support builtin_whatever".
Once the builtin is accepted on both compilers, you can merge them all, but
still leave the #error, so that new compilers will have a very nice message
telling them to implement the builtin.

Of course, discussing the best course of action and the final solution
would be something the kernel maintainers would have to agree 100%, even if
they don't agree with me. ;)


Currently in the ARM kernel they are all spread out as local register
> variables. In the x86 kernel they are done as a global (like my patch is
> trying to do now for ARM).
>

Got it. Keeping in mind that different compilers have different linkage
types for static/global/register variables, I believe that this could work.
Having the builtin would be better in that aspect, too, since all compilers
could agree on the linkage type for that.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20131117/f807b40a/attachment.html>