Tried this too, but i have the feeling the kernel compiled with this gcc
3.0 is somehow slower. context switch is slower
no benchs (no time to make them) to sustain my feeling, just a feeling...
On Wed, 20 Jun 2001, Eric Lammerts wrote:
>
> On Tue, 19 Jun 2001, Alan Cox wrote:
> > > Is it
Tried this too, but i have the feeling the kernel compiled with this gcc
3.0 is somehow slower. context switch is slower
no benchs (no time to make them) to sustain my feeling, just a feeling...
On Wed, 20 Jun 2001, Eric Lammerts wrote:
On Tue, 19 Jun 2001, Alan Cox wrote:
Is it mean
On Tue, 19 Jun 2001, Alan Cox wrote:
> > Is it mean now kernel 2.2 with prepatch is (or will be) gcc 3.0 ready ?
> > If not what must be fixed/chenged to be ready ?
>
> It wont build with gcc 3.0 yet. To start with gcc 3.0 will assume it can
> insert calls to 'memcpy'
I tried it, but didn't run
On Tue, 19 Jun 2001, Alan Cox wrote:
Is it mean now kernel 2.2 with prepatch is (or will be) gcc 3.0 ready ?
If not what must be fixed/chenged to be ready ?
It wont build with gcc 3.0 yet. To start with gcc 3.0 will assume it can
insert calls to 'memcpy'
I tried it, but didn't run into
Philip Blundell wrote:
> I don't think -fno-builtin has any bearing on whether gcc will emit calls to
> memcpy;
Good point. The subject was about the compiler adding function calls to
code, and I started talking about the compiler removing them...
--
Jeff Garzik | Andre the Giant has a
Alan Cox wrote:
> > why not always -fno-builtin,
> > and then call __builtin_foo when we really want the compiler's version..
> That may well be the right thing to do. Of course we rely on the compiler
> providing some of them too
true, it wouldn't be a completely transparent switchover, but it
>> It wont build with gcc 3.0 yet. To start with gcc 3.0 will assume it can
>> insert calls to 'memcpy'
>
>IMHO omitting -fno-builtin when compiling the kernel was always a risky
>proposition... Since we provide our own copies of many of the builtins
>[which are used in the kernel] anyway... why
> IMHO omitting -fno-builtin when compiling the kernel was always a risky
> proposition... Since we provide our own copies of many of the builtins
> [which are used in the kernel] anyway... why not always -fno-builtin,
> and then call __builtin_foo when we really want the compiler's version..
> On Tue, 19 Jun 2001, Alan Cox wrote:
> [..]
> > o Fix refclock build with newer gcc (Jari Ruusu)
>
> Is it mean now kernel 2.2 with prepatch is (or will be) gcc 3.0 ready ?
> If not what must be fixed/chenged to be ready ?
It wont build with gcc 3.0 yet. To start with gcc 3.0
Hi again,
On 19 Jun 2001, Jochen Striepe <[EMAIL PROTECTED]> wrote:
>
> Now it stops with
OK, this resolved to nothing (my mistake). Now it works fine. Until it
reaches
ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext
arch/i386/kernel/head.o
Hi,
On 19 Jun 2001, Alan Cox <[EMAIL PROTECTED]> wrote:
>
> > sched.c:52: conflicting types for `xtime'
> > /usr/src/linux/include/linux/sched.h:509: previous declaration of `xtime'
>
> Stick a volatile in the declaration. Thats a real bug it found
Um...
I made it
extern volatile
> Just to keep you informed... (I think there was a saying that there was
> interest in experiences with compiling the kernel with non-recommended
> gcc's ...)
> sched.c:52: conflicting types for `xtime'
> /usr/src/linux/include/linux/sched.h:509: previous declaration of `xtime'
Stick a
Hi,
On 19 Jun 2001, Alan Cox <[EMAIL PROTECTED]> wrote:
>
> 2.2.20pre4
Just to keep you informed... (I think there was a saying that there was
interest in experiences with compiling the kernel with non-recommended
gcc's ...)
I tried the newly released gcc-3.0 compiling 2.2.20pre4
Linux 2.2 is now firmly into maintainance state. Patches for neat new ideas
belong in 2.4. Generally new drivers belong in 2.4 (possibly in 2.2 as well
after 2.4 shows them stable). Expect me to be very picky on changes to the
core code now.
2.2.20pre4
o Fix small corruption bug in 82596
Linux 2.2 is now firmly into maintainance state. Patches for neat new ideas
belong in 2.4. Generally new drivers belong in 2.4 (possibly in 2.2 as well
after 2.4 shows them stable). Expect me to be very picky on changes to the
core code now.
2.2.20pre4
o Fix small corruption bug in 82596
Hi,
On 19 Jun 2001, Alan Cox [EMAIL PROTECTED] wrote:
2.2.20pre4
Just to keep you informed... (I think there was a saying that there was
interest in experiences with compiling the kernel with non-recommended
gcc's ...)
I tried the newly released gcc-3.0 compiling 2.2.20pre4 (yes, I
Hi,
On 19 Jun 2001, Alan Cox [EMAIL PROTECTED] wrote:
sched.c:52: conflicting types for `xtime'
/usr/src/linux/include/linux/sched.h:509: previous declaration of `xtime'
Stick a volatile in the declaration. Thats a real bug it found
Um...
I made it
extern volatile struct
Hi again,
On 19 Jun 2001, Jochen Striepe [EMAIL PROTECTED] wrote:
Now it stops with
OK, this resolved to nothing (my mistake). Now it works fine. Until it
reaches
ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext
arch/i386/kernel/head.o arch/i386/kernel/init_task.o
Just to keep you informed... (I think there was a saying that there was
interest in experiences with compiling the kernel with non-recommended
gcc's ...)
sched.c:52: conflicting types for `xtime'
/usr/src/linux/include/linux/sched.h:509: previous declaration of `xtime'
Stick a volatile in
IMHO omitting -fno-builtin when compiling the kernel was always a risky
proposition... Since we provide our own copies of many of the builtins
[which are used in the kernel] anyway... why not always -fno-builtin,
and then call __builtin_foo when we really want the compiler's version..
That
It wont build with gcc 3.0 yet. To start with gcc 3.0 will assume it can
insert calls to 'memcpy'
IMHO omitting -fno-builtin when compiling the kernel was always a risky
proposition... Since we provide our own copies of many of the builtins
[which are used in the kernel] anyway... why not
Alan Cox wrote:
why not always -fno-builtin,
and then call __builtin_foo when we really want the compiler's version..
That may well be the right thing to do. Of course we rely on the compiler
providing some of them too
true, it wouldn't be a completely transparent switchover, but it seems
Philip Blundell wrote:
I don't think -fno-builtin has any bearing on whether gcc will emit calls to
memcpy;
Good point. The subject was about the compiler adding function calls to
code, and I started talking about the compiler removing them...
--
Jeff Garzik | Andre the Giant has a
On Tue, 19 Jun 2001, Alan Cox wrote:
[..]
o Fix refclock build with newer gcc (Jari Ruusu)
Is it mean now kernel 2.2 with prepatch is (or will be) gcc 3.0 ready ?
If not what must be fixed/chenged to be ready ?
It wont build with gcc 3.0 yet. To start with gcc 3.0 will
24 matches
Mail list logo
