This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: DB 3.0.55, memset() and overoptimizacion [#1395]

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

Can we find out if they have some justification for this?

Amy Adams

Amy Adams			Berkeley DB Product Manager
Sleepycat Software Inc.
394 E. Riding Dr.
Carlisle, MA 01741-1601

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]