From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7352 invoked by alias); 25 Mar 2013 22:36:05 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 7320 invoked by uid 48); 25 Mar 2013 22:35:58 -0000 From: "chip at pobox dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/56726] i386: MALLOC_ABI_ALIGNMENT is too small (usually) Date: Mon, 25 Mar 2013 22:36:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: chip at pobox dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 X-SW-Source: 2013-03/txt/msg01844.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56726 --- Comment #4 from Chip Salzenberg 2013-03-25 22:35:57 UTC --- If I'm reading that correctly, it seems to agree with my patch. It looks like MALLOC_ABI_ALIGNMENT of POINTER_SIZE*2 is always either correct or smaller than necessary, but never too large. If MALLOC_ABI_ALIGNMENT is smaller than necessary then optimizations may be missed (depending on the values). But if it is too large then performance *will* suffer. It might even cause exceptions from unaligned accesses, but i386 is very forgiving, so it'll just be slower for no apparent reason. Perhaps the glibc version differences in malloc should be advertised with __attribute__ on the malloc declarations. Perhaps a new pragma or attribute is required to do this 100% right. But in the meantime I like POINTER_SIZE*2.