On Tue, Sep 18, 2001 at 09:26:29PM +0200, Jean Francois Martinez wrote:
>Gcc 2.96 requires C++ functions being declared before their use. I have found
>many programs who need to be fixed.
C++ requires functions being declared before their use. Period. Always has.
All the way to the original cfront. C++ programs that have things used
before their decls are broken, and should not compile on *any* C++ compiler.
The issue is that the object layout and internal object management issues
including vtables, etc were in flux, and gcc-2.96 uses a format that is
compatible with neither 2.95 nor 3.0. This is called, in general, the C++
ABI, or Application Binary Interface.
The issue is whether there are constructs in the kernel for which the
optimizer generates bad code: bad in the sense of "not what was intended",
as there are pieces of code in the kernel that a good optimizer will want to
remove entirely, but which are necessary for correct functioning.
And, I'll point out, before suggesting that is too off-topic to continue
here, that since the kernel (1) doesn't contain C++ code and (2) doesn't
link against anything but kernel specific modules, C++ ABI changes are a
non-issue for us.
*This thread is hereby declared too off-topic to live. This thread is dead.
It's gone to meet it's maker. It's shuffled off the coil and gone to join
the choir invisible. It's an EX-THREAD. Let it rest in peace.*
>AFAIK kgscc is no longer shipped with 7.1. Reason kgcc was in 7.0 was because
Kgcc, which lives in the compat-egcs-* set of rpms, is present in Rawhide as
of this morning. As for RH 8.0, that's an open issue, as nothing has been
announced one way or the other. But then, RedHat doesn't often announce what
they're dropping.
>gcc 2.96 did not compile kernel 2.2. gcc 2.96 had its bugs but in that case it
>was due
>to broken code in kernel that old more tolerant compilers accepted but should
>not
>have.
>kernel 2.4 has no longer this problem.
See above.
>About compiling specifically for athlon:
>
>1) The thing who will get you real benefits are the assembler parts (ie
>unaffected by
>compiler flags).
Those are controlled by the kernel CONFIG_* defines, right?
>2) On a PIII, compiling specifically for i686 gives a 15% improvement on pure C
>programs
>(my benchmark) over the worst case (compiling for plain Pentium). AMD
>processors tend
>to be more tolerant to code not specifically compiled for them since most of
>the
>time they have
>to cope with code optimized for Intel.
>
>Thus on kernel (mix of assembler and C) a good strategy if you want to use kgcc
>(aka egcs) is
>to go under arch/i386 and fix the file containing the compiler flags to use the
>-D for athlon and
>-march=i686. This will be a bit faster than compiling for i686. Gcc 2.96
>genrates faster code than egcs but if you are wary of it the above is the best
>solution
Sounds good. You've seconded a previously made suggestion, so that means at
least 2 people have this working successfully. :)
--
Alan Eldridge
from std_disclaimer import *
|