2 Sep 2010 14:28
Re: [PATCH] fix h264_deblock_sse2.asm segfaults on clang/x86-32
Måns Rullgård <mans <at> mansr.com>
2010-09-02 12:28:00 GMT
2010-09-02 12:28:00 GMT
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
RSS Feed