From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12572 invoked by alias); 4 Nov 2008 08:54:17 -0000 Received: (qmail 30728 invoked by uid 48); 4 Nov 2008 08:52:56 -0000 Date: Tue, 04 Nov 2008 08:54:00 -0000 Message-ID: <20081104085256.30727.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c/38001] regression in 4.3: alignment checks wrongly optimized away (runtime failure) In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "thomas dot orgis at awi dot de" 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 X-SW-Source: 2008-11/txt/msg00266.txt.bz2 ------- Comment #8 from thomas dot orgis at awi dot de 2008-11-04 08:52 ------- Ok, first, let me apologize for the "& 15 check is miscompiled" statement... operator precedence got me there. The feature for stack-realignment I meant is __attribute__((force_align_arg_pointer)) I use this already for the API entry functions of the library when gcc >= 4.2 is available. It _does_ solve the issue for misaligned stack from the caller, doesn't it? So, strictly, current gcc does not need the checks, except for the case where the user asked for trouble with -mpreferred-stack-boundary (which still should throw an error: __attribute__((aligned(16))) clearly is in conflict with that). I still need a way to handle the issue with older gccs, as I provide a source package and want to avoid bug reports about mysterious segfaults: The SSE stuff that needs alignment is an internal detail of the library, users should not need to specifically compile their programs for that detail. Now, since older gccs don't optimize away the check, it is still of use there. But I am wondering about the power of __attribute__((aligned(16))); gcc-3.4 seems to be unable to align double __attribute__((aligned(16))) altest[1]; as opposed to double __attribute__((aligned(16))) altest[2]; It sort of makes sense, the data structure should not be smaller than the alignment... but gcc-4.3 does align that correctly. Is that a bug in the older gcc or just coincidence? Well, I think I will go with the simple check with altest[2] for old compilers that don't know force_align_arg_pointer and luckily don't optimize away the check at the same time -- without need for the optimization barrier. Is that a good strategy? I can imagine that gcc folks are not that keen on caring for old gcc versions, but with mpg123 we want to support any C89 compiler, basically, however old. As for -mincoming-stack-boundary=2: __attribute__((force_align_arg_pointer)) does solve the problem equivalently, doesn't it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38001