public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "thomas dot orgis at awi dot de" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/38001] regression in 4.3: alignment checks wrongly optimized away (runtime failure) Date: Tue, 04 Nov 2008 08:54:00 -0000 [thread overview] Message-ID: <20081104085256.30727.qmail@sourceware.org> (raw) In-Reply-To: <bug-38001-15830@http.gcc.gnu.org/bugzilla/> ------- 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
next prev parent reply other threads:[~2008-11-04 8:54 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-11-03 13:26 [Bug c/38001] New: " thomas dot orgis at awi dot de 2008-11-03 13:27 ` [Bug c/38001] " thomas dot orgis at awi dot de 2008-11-03 13:33 ` jakub at gcc dot gnu dot org 2008-11-03 13:36 ` thomas dot orgis at awi dot de 2008-11-03 15:57 ` tg at mirbsd dot org 2008-11-03 16:09 ` thomas dot orgis at awi dot de 2008-11-03 16:19 ` jakub at gcc dot gnu dot org 2008-11-03 23:39 ` hjl dot tools at gmail dot com 2008-11-04 8:54 ` thomas dot orgis at awi dot de [this message] 2008-11-04 15:21 ` hjl dot tools at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20081104085256.30727.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).