Re: Compiling the kernel with pcc
Hi, clang still can't compile the kernel on amd64 and presumably all other architectures. And I had sent a email to that effect to clang list. I had a env CC=clang make clean make depend make in my build_kernel.sh file it only works when you have env CC=clang make The recent removal of make depend exposed me. I removed clean depend as I do a rm -rf of the compile/GENERIC.MP folder Sorry about that, amit On Mon, 4 Apr 2011, Philip Guenther wrote: On Mon, Apr 4, 2011 at 11:06 AM, Pascal Stumpf pascal.stu...@cubes.de wrote: pcc currently only chokes on some inline functions that need external linkage. gcc isn't pesky about that, but pcc and clang are (rightfully, imo). It's completely legal and defined (by the standard and not just gcc!) for a function to be inline in the file where it's defined and have external linkage. That just means inline if you can in this file, but still provide a copy callable from other files. That's exactly the semantic we want for pf_addr_compare(). If pcc or clang are complaining about it they're broken or their warning settings are misset. Philip Guenther
Re: Compiling the kernel with pcc
On Mon, Apr 04, 2011 at 11:18:26AM -0700, Philip Guenther wrote: On Mon, Apr 4, 2011 at 11:06 AM, Pascal Stumpf pascal.stu...@cubes.de wrote: pcc currently only chokes on some inline functions that need external linkage. gcc isn't pesky about that, but pcc and clang are (rightfully, imo). It's completely legal and defined (by the standard and not just gcc!) for a function to be inline in the file where it's defined and have external linkage. That just means inline if you can in this file, but still provide a copy callable from other files. Not if it's never declared as extern, according to the standard. In that case it's an inline definition, as they call it. That's exactly the semantic we want for pf_addr_compare(). If pcc or clang are complaining about it they're broken or their warning settings are misset. Philip Guenther
Re: Compiling the kernel with pcc
Date: Tue, 5 Apr 2011 09:44:21 +0200 From: Pascal Stumpf pascal.stu...@cubes.de On Mon, Apr 04, 2011 at 11:18:26AM -0700, Philip Guenther wrote: On Mon, Apr 4, 2011 at 11:06 AM, Pascal Stumpf pascal.stu...@cubes.de wrote: pcc currently only chokes on some inline functions that need external linkage. gcc isn't pesky about that, but pcc and clang are (rightfully, imo). It's completely legal and defined (by the standard and not just gcc!) for a function to be inline in the file where it's defined and have external linkage. That just means inline if you can in this file, but still provide a copy callable from other files. Not if it's never declared as extern, according to the standard. In that case it's an inline definition, as they call it. No that's not what the standard says. The standard says that something is an inline definition if *all* declarations of a functions have inline on them. That clearly isn't the case here. The standard also says that a function declaration with no starage-class specifier on it has external linkage. So while there is a (minor) ambuguity in the spec here, the logical conclusion would be that C99 should behave as we expect and that clang (according to you, but not according to jsg@) and pcc have a bug. As long as we're stuck with gcc2 and gcc3 for some of our architectures, working around those bugs in clang and pcc is not an option.
Re: Compiling the kernel with pcc
On Tue, Apr 05, 2011 at 10:21:18AM +0200, Mark Kettenis wrote: Date: Tue, 5 Apr 2011 09:44:21 +0200 From: Pascal Stumpf pascal.stu...@cubes.de On Mon, Apr 04, 2011 at 11:18:26AM -0700, Philip Guenther wrote: On Mon, Apr 4, 2011 at 11:06 AM, Pascal Stumpf pascal.stu...@cubes.de wrote: pcc currently only chokes on some inline functions that need external linkage. gcc isn't pesky about that, but pcc and clang are (rightfully, imo). It's completely legal and defined (by the standard and not just gcc!) for a function to be inline in the file where it's defined and have external linkage. That just means inline if you can in this file, but still provide a copy callable from other files. Not if it's never declared as extern, according to the standard. In that case it's an inline definition, as they call it. No that's not what the standard says. The standard says that something is an inline definition if *all* declarations of a functions have inline on them. That clearly isn't the case here. The standard also says that a function declaration with no starage-class specifier on it has external linkage. So while there is a (minor) ambuguity in the spec here, the logical conclusion would be that C99 should behave as we expect and that clang (according to you, but not according to jsg@) and pcc have a bug. Ok, I seem to have misread the standard there, sorry. Anyway, I've done some tests with all three compilers, and gotten three different behaviours: inline declaration in header file *and* definition: Should be an inline definition, but gcc still creates external linkage, violating the standard. pcc and clang fail. So adding __inline to the declaration in pfvar.h shouldn't fix, but break the build with clang. Maybe that behaviour was changed after 2.8. non-inline declaration in header, but inline for the definition: gcc and clang work, pcc does not. Probably a bug in pcc, although ragge says it's conforming. extern inline on both the declaration and definition: pcc and clang work, gcc fails (why?). As long as we're stuck with gcc2 and gcc3 for some of our architectures, working around those bugs in clang and pcc is not an option.
Re: Compiling the kernel with pcc
On Tue, Apr 05, 2011 at 11:09:14AM +0200, Pascal Stumpf wrote: Ok, I seem to have misread the standard there, sorry. Anyway, I've done some tests with all three compilers, and gotten three different behaviours: Can you please say explicitly which GCC version you are talking about? The behavior changed with 4.3 to follow the C99 semantic by default, which in turn is what clang and PCC should be implementing. Joerg
Re: Compiling the kernel with pcc
On Tue, Apr 05, 2011 at 01:04:22PM +0200, Joerg Sonnenberger wrote: On Tue, Apr 05, 2011 at 11:09:14AM +0200, Pascal Stumpf wrote: Ok, I seem to have misread the standard there, sorry. Anyway, I've done some tests with all three compilers, and gotten three different behaviours: Can you please say explicitly which GCC version you are talking about? The behavior changed with 4.3 to follow the C99 semantic by default, which in turn is what clang and PCC should be implementing. Joerg 4.2.1 from base.
Compiling the kernel with pcc
pcc currently only chokes on some inline functions that need external
linkage. gcc isn't pesky about that, but pcc and clang are (rightfully,
imo). Anyway, the functions in question are:
net/pf.c: pf_addr_compare (was probably ok before r1.729)
arch/{amd64,i386}/isa/clock.c: mc146818_read
Do those *have* to be inline?
Re: Compiling the kernel with pcc
On Mon, Apr 04, 2011 at 08:06:57PM +0200, Pascal Stumpf wrote:
pcc currently only chokes on some inline functions that need external
linkage. gcc isn't pesky about that, but pcc and clang are (rightfully,
imo). Anyway, the functions in question are:
net/pf.c: pf_addr_compare (was probably ok before r1.729)
compiles fine with clang here but not pcc, this should likely
be reported to ragge it doesn't look like it needs external linkage at all
arch/{amd64,i386}/isa/clock.c:mc146818_read
compiles fine with clang/pcc on i386 where it has no inline
It seems the amd64 version does though. It could be made static inline
or have inline removed like the i386 version.
Re: Compiling the kernel with pcc
On Mon, Apr 04, 2011 at 08:06:57PM +0200, Pascal Stumpf wrote: net/pf.c: pf_addr_compare (was probably ok before r1.729) The current implementation has been discussed. See also: http://www.greenend.org.uk/rjk/2003/03/inline.html The function should be inline within pf.c and callable from pf_norm.c. Defining it inline in pf.c allows faster code there, declaring it non-inline in pfvar.h creates callable code in pf.o. gcc always generates callable code, so it does not matter here. Do pcc and clang compile and link if you put an inline in the pfvar.h declaration? Do those *have* to be inline? Yes, pf_addr_compare() is used in pf state lookup. So it must be fast. The generated RB functions use it inline. bluhm
Re: Compiling the kernel with pcc
On Mon, Apr 4, 2011 at 11:06 AM, Pascal Stumpf pascal.stu...@cubes.de wrote: pcc currently only chokes on some inline functions that need external linkage. gcc isn't pesky about that, but pcc and clang are (rightfully, imo). It's completely legal and defined (by the standard and not just gcc!) for a function to be inline in the file where it's defined and have external linkage. That just means inline if you can in this file, but still provide a copy callable from other files. That's exactly the semantic we want for pf_addr_compare(). If pcc or clang are complaining about it they're broken or their warning settings are misset. Philip Guenther
Re: Compiling the kernel with pcc
On Mon, 4 Apr 2011, Alexander Bluhm wrote: On Mon, Apr 04, 2011 at 08:06:57PM +0200, Pascal Stumpf wrote: net/pf.c: pf_addr_compare (was probably ok before r1.729) The current implementation has been discussed. See also: http://www.greenend.org.uk/rjk/2003/03/inline.html The function should be inline within pf.c and callable from pf_norm.c. Defining it inline in pf.c allows faster code there, declaring it non-inline in pfvar.h creates callable code in pf.o. gcc always generates callable code, so it does not matter here. Do pcc and clang compile and link if you put an inline in the pfvar.h declaration? clang trunk v128001 has no problem if I __inline in pfvar.h. FYI, I am running on a kernel built using that clang revision. Do those *have* to be inline? Yes, pf_addr_compare() is used in pf state lookup. So it must be fast. The generated RB functions use it inline. bluhm
