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
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:
>
> C
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 behavi
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
> >
> > On Mon, Apr 04, 2011 at 11:18:26AM -0700, Philip Guenther wrote:
> > > On Mon, Apr 4, 2011 at 11:06 AM, Pascal Stumpf
> > > wrote:
> > > > pcc currently only c
> Date: Tue, 5 Apr 2011 09:44:21 +0200
> From: Pascal Stumpf
>
> On Mon, Apr 04, 2011 at 11:18:26AM -0700, Philip Guenther wrote:
> > On Mon, Apr 4, 2011 at 11:06 AM, Pascal Stumpf
> > wrote:
> > > pcc currently only chokes on some inline functions that need external
> > > linkage. gcc isn't pe
On Mon, Apr 04, 2011 at 09:10:45PM +0200, 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/i
On Mon, Apr 04, 2011 at 11:18:26AM -0700, Philip Guenther wrote:
> On Mon, Apr 4, 2011 at 11:06 AM, 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).
>
> It's complet
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 f
On Mon, Apr 4, 2011 at 11:06 AM, 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).
It's completely legal and defined (by the standard and not just gcc!)
for a function to b
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 p
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 pro
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
12 matches
Mail list logo
