[llvmlinux] Multiple storage class error

[Behan Webster]

On 11/17/13 08:31, Renato Golin wrote:
> On 17 November 2013 15:45, Behan Webster <behanw at converseincode.com
> <mailto:behanw at converseincode.com>> wrote:
>
>>     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.
>     Hm. I see what you're suggesting. I suppose that would work.
>
>
> I believe all compilers that claim GCC compatibility, including older
> versions of GCC, will set the same flags, so #ifs and #ifdefs should
> work with them. If the kernel is currently compiled with the
> "alternatives", it should just continue to do so.
>
> The problem arises if there are other compilers building the kernel
> that don't define __gcc etc BUT implement the necessary GCC-extensions
> (proprietary ones, like icc). My guess is that there aren't that many
> proprietary compilers that try to compile the kernel, but that could
> be an issue upstream.
I don't know what icc does, and that theoretically still works (icc is
still technically/theoretically the "second compiler" for the kernel).
So I still lean to having the default case be the status quo (at least
for the moment).

My feeling at this point is enabling clang without breaking gcc (or
anything else) is more important than absolute correctness. Essentially
we need patches to be as easy to upstream as we can make them, with
little to no breakage. Part of this is putting clang in the best
possible light with little to no downside (breakage is a perceived
downside). As much as I personally would prefer to have the kernel code
follow the standard, as you know, it's not our call. I've used too many
compilers to count, and so I personally appreciate standards based C
code tremendously!

Correctness will come. Especially when you end up with large bodies of
people using clang with the kernel code (and not just gcc). Those are
the people whom we are trying to enable. :)

As far as icc is concerned we don't have the means to test our patches
with it. The reality is that, while most devs are aware of icc, almost
none of them give icc any thought when it comes to their code. Since few
have access to icc, the feeling seems to be that if code breaks for icc,
someone else will fix it. This is hardly ideal.

I'm hoping that clang will become the "theoretical" second compiler.
Essentially since both gcc and clang are now easily installable with
your distro (or from llvm.org) that checking your code with either is
straightforward. This will not only allow more people to use clang
instead of gcc as their primary compiler, but also allow people who
normally use gcc to also test with clang (if they choose to). I can
imagine a future where testing with both gcc and clang before you
upstream is encouraged. :)

I understand that icc now uses the clang frontend for their compiler. So
it seems that by enabling clang in the kernel we're likely also helping
icc (which will also help our efforts).

> All that said, this is just bad practice, not broken code. So don't
> sweat too much about it. ;)
Exactly. :)

Behan

-- 
Behan Webster
behanw at converseincode.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20131117/d42f5fc7/attachment-0001.html>