Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Aug 1998 15:45:53 -0700 (PDT)
From:      Alex <garbanzo@hooked.net>
To:        Alexander Sanda <entropy@compufit.at>
Cc:        wwoods@cybcon.com, freebsd-current@FreeBSD.ORG
Subject:   Re: gcc 2.8
Message-ID:  <Pine.BSF.4.00.9808221538220.254-100000@zippy.dyn.ml.org>
In-Reply-To: <19980822135031.A358@compufit.at>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 22 Aug 1998, Alexander Sanda wrote:
[...]
> However, I have installed gcc-2.8.1 from the packages collection, and I
> have the vague feeling, that this compiler has some problems. I
> compiled one of my kde apps, using -O2 and -mpentiumpro and the app
> started to segfault occasionally. Since I recompiled with gcc-2.7.2.1,
> it never segfaulted again...

I think this is an a.out problem.  I'm using egcs from their anon cvs
repository, and after building ELF libs and X (and all other X related
goodies), egcs works wonderfully.  I don't have any major cli C++
programs, so I didn't bother with building an ELF world.  gdb seems to be
the only stumbling block for me.
[...]
> Once a while ago, I did some experiments with compiling the Linux kernel
> using different compilers (stock gcc-2.7, egcs, pgcc) and benchmarking
> them with lmbench or byte. The results: They all ranged within
> measurement tolerance, imho. Even if you run lmbench twice on the same
> system, the results will slightly differ.

I think the P5 (not clones) benefits more from compiler optimizations than
do other chips (esp. the P6).

> For kernel code, any compiler-induced problem can be lethal and will
> probably result in an unstable system. Bad enough, those bugs would be
> extremely hard to track.

Fair enough, but I've built kernels with gcc 2.8 and earlier egcs
snapshots, and pgcc and it's worked well for me.

> As far as we all know, gcc-2.7.2.1 produces ok code. Known problems (if
> any, I'am not an expert here) can be workarounded by the really skilled
> kernel hackers. Moving to another compiler will perhaps introduce new
> problems - as long as the performance gain is practically non-existant,
> this is not very desireable.

gcc 2.7 produces OK code, however, it's C++ support is really quite
lacking.  If you bend over backwards far enough to support it (which I
have done) you really do miss out on some of the more fun features.  Even
Windows has the Unix world beat here (IBM and Sun's C++ compilers are far
more broken than any post 2.6 gcc).

I think most of the problems you'll encounter with newer compilers will be
related to using a.out, and shared a.out libs, I think that since x86
Linux is such a popular platform, most code generation problems that would
inflict pain on the FreeBSD will have been quashed long ago.

- alex

A person who has both feet planted firmly in the air can be safely called
a liberal.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.00.9808221538220.254-100000>