Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Sun, 24 Jun 2001 11:00:39 -0700 (PDT)
From: <rbb@covalent.net>
To: Justin Erenkrantz <jerenkrantz@ebuilt.com>
Cc: <dev@apr.apache.org>
Subject: Re: GCC 2.96 optimization bug
In-Reply-To: <20010623194228.C25512@ebuilt.com>
Message-ID: <Pine.LNX.4.30.0106241059460.12921-100000@koj.rkbloom.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


> I just ran across a compiler bug when dealing with long long in the GCC
> shipped with Mandrake 8.0 (Intel).  When -O2 is specified (it's in the
> default), it seems to lose the upper 32 bits of the 64 bit integers.
> (I was playing with the XML code in apr-util and the return values from
> elem_size() were corrupted.)  Removing -O2 fixes this.
>
> % gcc -v
> Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.96/specs
> gcc version 2.96 20000731 (Linux-Mandrake 8.0 2.96-0.48mdk)
>
> This is a fairly old snapshot.  I am building gcc-3.0 now and going to
> see if the problem still exists (unlikely).  Even if it doesn't, we
> probably need to stick something in autoconf to avoid optimizations
> with this buggy compiler.
>
> Silly distros shipping beta compilers (2.96 was never a released
> version).  This is lame.
>
> Thoughts?  Should we just avoid this problem and tell anyone using a
> default install of Mandrake that they are screwed?  Or, do we just
> disable compiler optimizations with gcc 2.96?  -- justin

We shouldn't have to work around bugs in beta versions of the compiler.
If somebody is using a buggy compiler, then they are screwed.  Hopefully,
this will teach distributions that they have a responsability to use good
packages when they assemble their dist.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------