On Wed, Feb 07, 2001 at 07:22:19PM +, Alan Cox wrote:
> > In file included from init.c:30:
> > ../../prolog.h:344:8: invalid #ident
>
> It doesnt say #ident isnt supported it says your use of it is invalid. What
> precisely does that line read ?
JJ tried it and it worked on some version he
> In file included from init.c:30:
> ../../prolog.h:344:8: invalid #ident
It doesnt say #ident isnt supported it says your use of it is invalid. What
precisely does that line read ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Wed, Feb 07, 2001 at 10:37:19AM -0800, Tim Wright wrote:
> Umm, I don't know what compiler you've got etc. Jeff, but I just tried gcc-2.96
> (-69) here, and '#ident' is supported and works perfectly. The only way to even
> get a warning is to use '-ansi -pedantic' which yields:
> junk.c:1:2:
> > That would explain the %age certainly. How it happened is the next question
>
> I'll gen some code, and send to you.
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
On Wed, Feb 07, 2001 at 07:06:55PM +, Alan Cox wrote:
> > I looked into this, and discovered that the gcc 2.96 compiler turned my
> > rep movsd code into a rep movsb (???) with some evil looking C++ style
>
> If its hand coded asm then gcc shouldnt have touched it. If its an implicit
>
> I looked into this, and discovered that the gcc 2.96 compiler turned my
> rep movsd code into a rep movsb (???) with some evil looking C++ style
If its hand coded asm then gcc shouldnt have touched it. If its an implicit
memcpy then gcc will generate inline code designed for main memory
On Wed, Feb 07, 2001 at 07:02:26PM +, Alan Cox wrote:
> > Hummm. Where are the patches for 2.4 to correct this? They are not posted
> > with the 7.1 release. They need to be. The compiler not supporting
>
> They don't need to be because the thing is just a warning. The kernel has
>
> Hummm. Where are the patches for 2.4 to correct this? They are not posted
> with the 7.1 release. They need to be. The compiler not supporting
They don't need to be because the thing is just a warning. The kernel has
plenty of warnings and this one is 100% harmless.
> #ident for CVS is a
Umm, I don't know what compiler you've got etc. Jeff, but I just tried gcc-2.96
(-69) here, and '#ident' is supported and works perfectly. The only way to even
get a warning is to use '-ansi -pedantic' which yields:
junk.c:1:2: warning: ISO C does not allow #ident
I don't think the problem is
On Wed, Feb 07, 2001 at 12:32:13PM -0500, Jakub Jelinek wrote:
> On Wed, Feb 07, 2001 at 11:08:52AM -0700, Jeff V. Merkey wrote:
> > Not supporting #ident for CVS managed code bases would see to
> > me, at first glance, to be a show stopper to shipping a release
> > of anything, since many
On Wed, Feb 07, 2001 at 11:08:52AM -0700, Jeff V. Merkey wrote:
> Not supporting #ident for CVS managed code bases would see to
> me, at first glance, to be a show stopper to shipping a release
> of anything, since many folks need CVS support.
Could you please explain what you mean by not
On Wed, Feb 07, 2001 at 09:22:43AM +, Alan Cox wrote:
> > kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
> > 7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
> > from the gcc 2.91 compiled version on the identical SAME 2.4.1
> > source tree.
>
>
On Wed, Feb 07, 2001 at 09:15:39AM +, Alan Cox wrote:
> > always assume a stock kernel layout and will point to
> > /usr/src/linux/include for modversioned includes and files.
>
> You can't assume that. The big problem is right now nobody has set an
> agreed location for kernel sources,
On Wed, Feb 07, 2001 at 09:01:49AM +, David Howells wrote:
>
> > More to add on the gcc 2.96 problems. After compiling a Linux 2.4.1
> > kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
> > 7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
> > from
On Tue, Feb 06, 2001 at 09:07:31PM -0500, Gregory Maxwell wrote:
> So.. It's likely that calling your performance issues 'gcc bugs' is about
> the same as saying that SGI cc is buggy because it can't compile the kernel.
>
> At least you managed to avoid calling RedHat names. :)
I really have
> kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
> 7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
> from the gcc 2.91 compiled version on the identical SAME 2.4.1
> source tree.
30% is too big to be caused by a compiler. Way too big.I suggest you
> always assume a stock kernel layout and will point to
> /usr/src/linux/include for modversioned includes and files.
You can't assume that. The big problem is right now nobody has set an
agreed location for kernel sources, you also cant assume they will be
present.
Its something the FHS
> More to add on the gcc 2.96 problems. After compiling a Linux 2.4.1
> kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
> 7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
> from the gcc 2.91 compiled version on the identical SAME 2.4.1
> source tree.
More to add on the gcc 2.96 problems. After compiling a Linux 2.4.1
kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
from the gcc 2.91 compiled version on the identical SAME 2.4.1
source tree.
always assume a stock kernel layout and will point to
/usr/src/linux/include for modversioned includes and files.
You can't assume that. The big problem is right now nobody has set an
agreed location for kernel sources, you also cant assume they will be
present.
Its something the FHS needs
kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
from the gcc 2.91 compiled version on the identical SAME 2.4.1
source tree.
30% is too big to be caused by a compiler. Way too big.I suggest you
On Tue, Feb 06, 2001 at 09:07:31PM -0500, Gregory Maxwell wrote:
So.. It's likely that calling your performance issues 'gcc bugs' is about
the same as saying that SGI cc is buggy because it can't compile the kernel.
At least you managed to avoid calling RedHat names. :)
I really have no
On Wed, Feb 07, 2001 at 09:01:49AM +, David Howells wrote:
More to add on the gcc 2.96 problems. After compiling a Linux 2.4.1
kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
from the gcc
On Wed, Feb 07, 2001 at 09:22:43AM +, Alan Cox wrote:
kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
from the gcc 2.91 compiled version on the identical SAME 2.4.1
source tree.
30% is too
On Wed, Feb 07, 2001 at 11:08:52AM -0700, Jeff V. Merkey wrote:
Not supporting #ident for CVS managed code bases would see to
me, at first glance, to be a show stopper to shipping a release
of anything, since many folks need CVS support.
Could you please explain what you mean by not
On Wed, Feb 07, 2001 at 12:32:13PM -0500, Jakub Jelinek wrote:
On Wed, Feb 07, 2001 at 11:08:52AM -0700, Jeff V. Merkey wrote:
Not supporting #ident for CVS managed code bases would see to
me, at first glance, to be a show stopper to shipping a release
of anything, since many folks need
Umm, I don't know what compiler you've got etc. Jeff, but I just tried gcc-2.96
(-69) here, and '#ident' is supported and works perfectly. The only way to even
get a warning is to use '-ansi -pedantic' which yields:
junk.c:1:2: warning: ISO C does not allow #ident
I don't think the problem is
Hummm. Where are the patches for 2.4 to correct this? They are not posted
with the 7.1 release. They need to be. The compiler not supporting
They don't need to be because the thing is just a warning. The kernel has
plenty of warnings and this one is 100% harmless.
#ident for CVS is a
I looked into this, and discovered that the gcc 2.96 compiler turned my
rep movsd code into a rep movsb (???) with some evil looking C++ style
If its hand coded asm then gcc shouldnt have touched it. If its an implicit
memcpy then gcc will generate inline code designed for main memory
On Wed, Feb 07, 2001 at 07:02:26PM +, Alan Cox wrote:
Hummm. Where are the patches for 2.4 to correct this? They are not posted
with the 7.1 release. They need to be. The compiler not supporting
They don't need to be because the thing is just a warning. The kernel has
plenty
On Wed, Feb 07, 2001 at 07:06:55PM +, Alan Cox wrote:
I looked into this, and discovered that the gcc 2.96 compiler turned my
rep movsd code into a rep movsb (???) with some evil looking C++ style
If its hand coded asm then gcc shouldnt have touched it. If its an implicit
memcpy
That would explain the %age certainly. How it happened is the next question
I'll gen some code, and send to you.
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Wed, Feb 07, 2001 at 10:37:19AM -0800, Tim Wright wrote:
Umm, I don't know what compiler you've got etc. Jeff, but I just tried gcc-2.96
(-69) here, and '#ident' is supported and works perfectly. The only way to even
get a warning is to use '-ansi -pedantic' which yields:
junk.c:1:2:
In file included from init.c:30:
../../prolog.h:344:8: invalid #ident
It doesnt say #ident isnt supported it says your use of it is invalid. What
precisely does that line read ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Wed, Feb 07, 2001 at 07:22:19PM +, Alan Cox wrote:
In file included from init.c:30:
../../prolog.h:344:8: invalid #ident
It doesnt say #ident isnt supported it says your use of it is invalid. What
precisely does that line read ?
JJ tried it and it worked on some version he was
On Tue, Feb 06, 2001 at 07:06:24PM -0700, Jeff V. Merkey wrote:
> More to add on the gcc 2.96 problems. After compiling a Linux 2.4.1
> kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
> 7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
> from the gcc
On Tue, Feb 06, 2001 at 06:25:01PM -0700, Jeff V. Merkey wrote:
>
> Also, the GCC 2.96 compiler shipped with RedHat 7.1 is terribly
> broken, and does not support #ident lines in the source code,
> which also means that RedHat 7.1 will not work properly with
> CVS (Code Versioning System)
The PCI-SCI v1.1-7 Drivers for Dolphin's Scalable Coherent
Interface Adapters have been posted and are available for download
at vger.timpanogas.org:\sci\pci-sci-1.1-7 in tar.gz and RPM
(RedHat Package Manager Formats). This version supports Linux kernels
2.2.X up through 2.4.1. These
The PCI-SCI v1.1-7 Drivers for Dolphin's Scalable Coherent
Interface Adapters have been posted and are available for download
at vger.timpanogas.org:\sci\pci-sci-1.1-7 in tar.gz and RPM
(RedHat Package Manager Formats). This version supports Linux kernels
2.2.X up through 2.4.1. These
On Tue, Feb 06, 2001 at 06:25:01PM -0700, Jeff V. Merkey wrote:
Also, the GCC 2.96 compiler shipped with RedHat 7.1 is terribly
broken, and does not support #ident lines in the source code,
which also means that RedHat 7.1 will not work properly with
CVS (Code Versioning System) projects
On Tue, Feb 06, 2001 at 07:06:24PM -0700, Jeff V. Merkey wrote:
More to add on the gcc 2.96 problems. After compiling a Linux 2.4.1
kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat
7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput
from the gcc 2.91
41 matches
Mail list logo
