Re: Potential issue with strstr on x86 with sse4.2 in glibc-2.18

[Rich Felker <dalias at aerifal dot cx>]

On Tue, Aug 20, 2013 at 01:28:56PM +1000, Allan McRae wrote:
> >> So does that just leave us the option of realigning the stack for the
> >> relevant calls?
> > 
> > Does -mincoming-stack-boundary=2 -mpreferred-stack-boundary=4 cause
> > realignment to take place in the prologue of every function, or only
> > functions that use SSE? If the latter, I think a safe solution would
> > be to use these options globally, and possibly the related
> > -mstackrealign or force_align_arg_pointer attribute on functions which
> > call back to application code. This would fix the problem not just for
> > the "relevant" calls, but for any functions in which GCC happens to
> > emit SSE code. Of course the size and performance costs would need to
> > be measured...
> 
> I would have assumed that it is gcc's responsibility to ensure alignment
> if it decides to use SSE and our responsibility if our functions
> explicitly use SSE.   Is that being too naive?

If by "explicitly use SSE" you mean using the intrinsics, alignment
_should_ be GCC's responsibility just as if GCC had chosen to use SSE
itself. However I don't know if the reality is like this. The only way
I can see that GCC would not be expected to take care of alignment is
when the SSE code resides in inline assembly.

Actually, it's not really the use of SSE, but the use of automatic
objects with 16-byte-alignment requirements that should cause GCC to
align the stack. For example, if you have a char array declared with
__attribute__((aligned(16))) with the intent to pass it to an external
function that uses SSE, GCC needs to ensure its alignment.

I'm unclear on what GCC's capabilities are in this area; that's why I
asked.

Rich