search for: force_align_arg_pointer

Hello, Daniel. > glibc < 2.4 don't reliably keep stack at 16 bytes through some calls > (qsort, etc), but otherwise, it stays 16 byte aligned. Interesting, but why in this case stuff like 'force_align_arg_pointer' required? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

...t. :-) Evan On Sep 30, 2007, at 10:47 AM, Anton Korobeynikov wrote: > Hello, Daniel. > >> glibc < 2.4 don't reliably keep stack at 16 bytes through some calls >> (qsort, etc), but otherwise, it stays 16 byte aligned. > Interesting, but why in this case stuff like 'force_align_arg_pointer' > required? > > -- > With best regards, Anton Korobeynikov. > > Faculty of Mathematics & Mechanics, Saint Petersburg State University. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu htt...

Chuck, > It is dying trying to store a our working vector into one of the LLVM > vectors created on the stack. Despite the align-16 directive on the > alloca instruction, it is not always aligning to a 16-byte boundary. The stack is not necessary 16 bytes aligned on linux/windows. The vector is really sotred aligned relative to %esp, but %esp value is not good. This is known problem

...t. :-) Evan On Sep 30, 2007, at 10:47 AM, Anton Korobeynikov wrote: > Hello, Daniel. > >> glibc < 2.4 don't reliably keep stack at 16 bytes through some calls >> (qsort, etc), but otherwise, it stays 16 byte aligned. > Interesting, but why in this case stuff like 'force_align_arg_pointer' > required? > > -- > With best regards, Anton Korobeynikov. > > Faculty of Mathematics & Mechanics, Saint Petersburg State University. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu htt...

Jean-Marc Valin wrote: > Duane Storey a ?crit : >> Actually, it might just be an OS "feature".. On most linux and mac >> platforms, the memory managers align memory on proper boundaries -- this >> doesn't occur on most versions of windows. I don't have all the code in >> front of me, but it's possible that it's simply a side effect of windows

> I don't know how GCC handles this case. They may do the padding in the > compiler. You are going to have to look at exactly what GCC does and > whatever hotpatch loader Wine uses to figure out what to do, but it > will most likely be incompatible with the Windows implementation. Why? I don't see how this might be incompatible with what MS linker does; in any case the end

...is unaligned. Since GCC maintains 16-byte alignment relative to the > starting SP, either ALL stack loads are aligned or they are all unaligned. FFMpeg had problems with SSE missaligned stack variables under Windows too. Now, with gcc 4.2 available on Windows they solved it with __attribute__((force_align_arg_pointer)) set for publicly visible functions. You may find their patch and short description in this mail: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-August/034010.html Speex may follow similar way to solve this problem. -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Con...

On Mon, Mar 9, 2015 at 5:15 PM, lvqcl <lvqcl.mail at gmail.com> wrote: > Janne Hyv?rinen wrote: > >> I compiled flac.exe without NASM and verified that >> FLAC__lpc_restore_signal_16_intrin_sse2 is used. Decoding the same file >> that made VLC 2.2 crash decoded without issues. Would be nice if VLC was >> compilable with MSVC and we could use its debugger.

...src/libFLAC/include/private/cpu.h index 8927897..bd40012 100644 --- a/src/libFLAC/include/private/cpu.h +++ b/src/libFLAC/include/private/cpu.h @@ -72,8 +72,13 @@ #define FLAC__FMA_SUPPORTED 1 #endif #elif defined __GNUC__ + #ifdef __MINGW32__ + #define FLAC__STACK_ALIGN __attribute__((force_align_arg_pointer)) + #else + #define FLAC__STACK_ALIGN + #endif /* SSE stack alignment fixups */ #if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 9)) /* since GCC 4.9 -msse.. compiler options aren't necessary */ - #define FLAC__SSE_TARGET(x) __attribute__ ((__target__ (x))) +...

.... In addition, it would allow clients to use the existing LLVM optimization and analysis passes on machine code, without the need to implement special tools to operate directly on MCInst objects. Experience: I have been working with LLVM for over two and a half years. I implemented support for the force_align_arg_pointer attribute, as well as the beginnings of Win64 exception-handling support. In GSoC 2010, I added support for multiple C++ ABIs, and the beginnings of support for the Microsoft Visual C++ ABI. In addition, I have also contributed to the Wine project--some of which was making it easier to compile with...