[FFmpeg-devel] [PATCH] fix h264_deblock_sse2.asm segfaults on clang/x86-32

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Thu, Sep 02, 2010 at 10:09:20AM +0100, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > On Wed, Sep 01, 2010 at 06:06:11PM +0200, Reimar D?ffinger wrote:
>> >> On Wed, Sep 01, 2010 at 07:43:29AM -0400, Ronald S. Bultje wrote:
>> >> > We can optimize the code for compilers that do realign the way we want
>> >> > if people prefer that.
>> >> 
>> >> If there's no measurable slowdown that would just make things worse
>> >> in the maintainability sense I think.
>> >> But since the majority does not seem to consider "ignore clang for now"
>> >> an option I withdraw any objections (well, I mostly meant to ask rather
>> >> than object anyway).
>> >
>> > supporting plain C with clang is all fine but to support clang with
>> > asm optimizations clang first must support the feature set we require
>> > for that and maintaining alignment is one of these.
>> > I dont mind if people disable optimized code for clang or add such
>> > workarounds conditional on the compiler being clang.
>> > But iam against such workarounds being added as if it was a bugfix
>> > because once clang will be fixed all these hacks would then be forgoten
>> > without ifdef clang/buggy_whatever. And there are enough hacks in the
>> > code that noone knows why they where added
>> 
>> Not aligning the stack is not a bug.
>
> is there any relation between your statement and the discussion or what i
> said?

You keep talking about workarounds and fixes when the truth is that
clang is following the published x86 ABI specs, which do not mandate
an aligned stack.  There is thus nothing to fix per se in clang.  You
could try submitting a feature request for preserving 16-byte
alignment since this would be a useful feature.  However, lack of
something which isn't required can never be considered a bug.

-- 
M?ns Rullg?rd
mans at mansr.com