On 02/17/2017 11:48 AM, Alex Peshkoff wrote: > On 02/16/17 15:52, Stephan Bergmann wrote: >> Forgive me if this has already been discussed or even fixed in later >> versions: At least the Firebird 3.0 we build as part of LibreOffice >> defines global operator new replacement functions in >> src/common/classes/alloc.h (forwarding to MemoryPool) that do not in >> general fulfil the alignment requirements for such functions. >> >> Came across this when Firebird compiled with a recent trunk Clang (with >> -O, and DEBUG_GDS_ALLOC being undefined) on x86_64-unknown-linux-gnu >> causes SEGV from misaligned MOVAPS instructions. >> > > Yes - allocated memory is aligned at 8 bytes boundary now. > I've tried to set alignment to 16 but looks like that's far not 5 lines > patch - sometimes we were choosing between 4/8 bytes alignment, but last > years only 8 bytes alignment was used. > May be finding specific compiler flag to avoid this instruction is > simpler choice for today?
(The way I work around this for now in LibreOffice is by always defining DEBUG_GDS_ALLOC when building with Clang on Linux X86-64, <https://cgit.freedesktop.org/libreoffice/core/commit/?id=8ea07101c1613d213fd7cea17f094a947b14cd00> "external/firebird: Work around operator new alignment violations". Since LibreOffice builds intended for widespread distribution are on Linux usually done with GCC not Clang, this shouldn't have a performance impact.) ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
