This is the mail archive of the
glibc-bugs@sources.redhat.com
mailing list for the glibc project.
[Bug libc/206] malloc does not align memory correctly for sse capable systems
- From: "bangerth at ices dot utexas dot edu" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs at sources dot redhat dot com
- Date: 7 Jun 2004 14:23:48 -0000
- Subject: [Bug libc/206] malloc does not align memory correctly for sse capable systems
- References: <20040605142238.206.ma1flfs@bath.ac.uk>
- Reply-to: sourceware-bugzilla at sources dot redhat dot com
------- Additional Comments From bangerth at ices dot utexas dot edu 2004-06-07 14:23 -------
Subject: Re: malloc does not align memory correctly for sse
capable systems
> Ok, surely _the_ C standard doesn't specify "SSE data types".
While that may be true, it is a quality of implementation issue.
Also, note footnote 34 in the C99 standard. It says:
An implementation may define new keywords that provide ways to designate
a basic (*or any other*) type; [...]
(emphasis mine). This would seem to imply that we are quite allowed to use
an SSE type as another basic type, and if we do so the same provisions of
the standard should apply to it.
> > I know that this is unfortunate, but there really is no other
> > way of fixing malloc; for example, consider a program that uses
> > std::vector<__m128> x(13);
> > Here, std::vector has to call 'operator new' which itself has to call
> > malloc(). If malloc doesn't return sufficiently aligned pointers, the
> > resulting std::vector is unusable. Note that here the memory allocation
> > has to happen inside gcc's libstdc++, and is this out of user's control
> > -- so one can't use posix_memalign here.
>
> Couldn't you use a non-default allocator?
> (I know it is not as convenient.)
That may be very hard to do. Consider this case:
template <typename T> class MyClass {
std::vector<T> member;
};
One would only need to use the special allocator if T==some SSe type, but
not otherwise. That can be done via some really awkward template hacking,
but isn't very nice. In addition, MyClass may be in a third-party (not
compiler, not application) library, over which I have no control. So there
definitely are cases where we can't do this.
W.
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ices.utexas.edu
www: http://www.ices.utexas.edu/~bangerth/
--
http://sources.redhat.com/bugzilla/show_bug.cgi?id=206
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.