This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: correctness and comprehensiveness of compilers [was: Re: C compiletime]
- From: <tm_gccmail at mail dot kloo dot net>
- To: Vladimir Makarov <vmakarov at redhat dot com>
- Cc: Karel Gardas <kgardas at objectsecurity dot com>,Scott Robert Ladd <coyote at coyotegulch dot com>,Dara Hazeghi <dhazeghi at yahoo dot com>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Wed, 18 Jun 2003 14:11:45 -0700 (PDT)
- Subject: Re: correctness and comprehensiveness of compilers [was: Re: C compiletime]
On Wed, 18 Jun 2003, Vladimir Makarov wrote:
> Karel Gardas wrote:
> >
> > On Wed, 18 Jun 2003, Scott Robert Ladd wrote:
> >
> > Just one example: all last three releases of Intel C++ compiler for Linux
> > (I mean 6.0, 7.0 and 7.1) miscompile MICO (http://www.mico.org) such that
> > its IDL compiler is either crashing (6.0 + 7.0) or loops infinitely (7.1).
> >
>
> I don't know about MICO test. But it is amazing for me how such
> respectable company as Intel could make a release (7.1) which can not
> compile correctly some SPECINT2000 tests (vpr and gcc) with -O2 and -O3
> for P4 (their mainstream processor). I found that a week ago using the
> demo CD which we got on the gcc summit.
>
> Vlad
I've noticed hardware vendor's compilers usually are pretty buggy. They're
basically vehicles for getting good numbers on certain benchmarks, and
often contain optimizations useless in the real world and/or fail to
contain basic optimizations necessary for good performance on real-world
programs.
(Evidently they don't use icc for SPEC...)
For example, the Renesas H8 compiler generates the worst code ever for
switch() that I've ever seen - it generates a completely linear sequence
of compares and branches - no binary searching at all. Guess what happens
when you compile a bytecode interpreter which decodes bytecodes using a
huge switch() statement with this compiler...
Toshi