This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: DB 3.0.55, memset() and overoptimizacion [#1395]
- To: jcea at argo dot es
- Subject: Re: DB 3.0.55, memset() and overoptimizacion [#1395]
- From: Sleepycat Software <db at abyssinian dot sleepycat dot com>
- Date: Tue, 30 Nov 1999 23:41:12 -0500 (EST)
- Cc: gcc at gcc dot gnu dot org
Thank you for your email.
> I was just trying to use the new DB 3.0.55, but my source core dumps
> consistently. I found the bug inside DB library, in "memset()" usage.
I'm sorry to hear this.
> The problem seems to be a over-optimization in the new GCC 2.95.2 (not
> checked using other compilers), UltraSparc (Sun Microsystems). When the
> pointer in "memset" points to a struct and the counter is a compiler
> time constant, GCC assumes 64bits alignment and emits "std" (store
> double: 64 bits) assembler instructions. But, at least in UltraSparc I,
> "std" needs to be aligned in 64 bit boundaries or you are dead.
We found (and fixed) several of these bugs when we did our last
release, but it looks like there are still more. (We only found
problems with memcpy, not memset.)
The compiler has no justification, of which I'm aware, for doing
this. The only solution I can think of is to replace all of
the calls to memmove, memcpy and memset with our own versions
of those functions so the compiler can't do this. I don't see
any other way to ensure this problem doesn't continue to occur.
As a workaround, you should use the Solaris compiler for Berkeley
DB on the Ultrasparc.
Do you know of any way to submit bug reports to the gcc development
group?
Can we find out if they have some justification for this?
Regards,
Amy Adams
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Amy Adams Berkeley DB Product Manager
Sleepycat Software Inc. db@sleepycat.com
394 E. Riding Dr. http://www.sleepycat.com
Carlisle, MA 01741-1601