Re: building pg 8.0.1 with gcc-4.0.1: MemSet problems on SPARC?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Morrow <andrew(dot)c(dot)morrow(at)gmail(dot)com>
Cc: pgsql-ports(at)postgresql(dot)org
Subject: Re: building pg 8.0.1 with gcc-4.0.1: MemSet problems on SPARC?
Date: 2005-07-18 14:35:58
Message-ID: 3168.1121697358@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-ports

Andrew Morrow <andrew(dot)c(dot)morrow(at)gmail(dot)com> writes:
> I am no language laywer, so I don't know for certain what is going on
> here, but it does seem to be that one of the following must be true:
> 1) There is something illegal/undefined about the address argument to
> memset in the original version, due to the int32 * and char * casts.

I think you are absolutely right --- the cast to int32* allows the
compiler to assume that the pointer is word-aligned, and even casting
it back to char * or void * at the memset call wouldn't really undo
the damage. So really, correct coding of the macro should be along
the lines of

{ void *_vstart = (void *)(start); \
int _val = (val); \
Size _len = (len); \
\
if ((((long) _vstart) & INT_ALIGN_MASK) == 0 && \
(_len & INT_ALIGN_MASK) == 0 && \
_val == 0 && \
_len <= MEMSET_LOOP_LIMIT) \
{ \
int32 * _start = (int32 *) (_vstart); \
int32 * _stop = (int32 *) ((char *) _start + _len); \
while (_start < _stop) \
*_start++ = 0; \
} \
else \
memset(_vstart, _val, _len); \
} while (0)

Interesting that we have not seen this before.

regards, tom lane

In response to

Browse pgsql-ports by date

  From Date Subject
Next Message Tom Lane 2005-07-18 16:01:33 Re: building pg 8.0.1 with gcc-4.0.1: MemSet problems on SPARC?
Previous Message Andrew Morrow 2005-07-18 13:51:14 building pg 8.0.1 with gcc-4.0.1: MemSet problems on SPARC?