[Bug c/38001] regression in 4.3: alignment checks wrongly optimized away (runtime failure)

[thomas dot orgis at awi dot de]

------- 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