From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32219 invoked by alias); 8 Jun 2004 15:56:28 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 32168 invoked by uid 48); 8 Jun 2004 15:56:25 -0000 Date: Tue, 08 Jun 2004 15:56:00 -0000 Message-ID: <20040608155625.32166.qmail@sourceware.org> From: "bangerth at dealii dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040603143635.15795.ma1flfs@bath.ac.uk> References: <20040603143635.15795.ma1flfs@bath.ac.uk> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/15795] No way to teach operator new anything about alignment requirements X-Bugzilla-Reason: CC X-SW-Source: 2004-06/txt/msg00931.txt.bz2 List-Id: ------- Additional Comments From bangerth at dealii dot org 2004-06-08 15:55 ------- The glibc people have decided that they will not change malloc to provide the alignment requirements one would need for the case in this PR (see http://sources.redhat.com/bugzilla/show_bug.cgi?id=206): --------------------------- MALLOC_ALIGNMENT in glibc is really not going to change, it is a quality of implementation, sure, by making it bigger the quality implementation would drop a lot for most of the programs out there. SSE types are certainly out of the scope of the C standard. GCC allows to create objects with arbitrary alignment, not just __m128, but you can use say: __attribute__((aligned (256))). With the same argumentation, you could request that all malloc memory is 256 bytes aligned (or 4K or whatever you choose). If you want to make C++ new working on these types, the compiler will simply need to do its part and call some (non-standard) new operator with additional alignment argument, which would in turn call posix_memalign, perhaps guarded with some compiler option which will otherwise result in a compile time error if new is used on types with too big alignment requirement. -------------------------------- In other words, the ball is back in our field. Anyone got ideas as to what to do? How do other compilers do this? (I just verified that icc 8.0 also segfaults on the small testcase in comment #11, but maybe some compiler is more clever there...) W. -- What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at redhat dot com Status|RESOLVED |UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795