On 16.04.2018 15:59, Alex Peshkoff via Firebird-devel wrote:
On 04/16/18 15:08, Stephan Bergmann wrote:
On 17/02/17 11:48, 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?
Has this meanwhile been addressed in Firebird? LibreOffice still
uses Firebird 3.0.0, and the issue I've described now also hits with
recent Apple Xcode Clang on macOS (see
<https://gerrit.libreoffice.org/#/c/52956/> "external/firebird:
Better workaround for Clang alignment expectations").
Sorry - not yet. But looks like it's time to do it...
Stephan, one question. Should 16-byte alignment be enforced only for x64
builds or for x86 too?
A.
------------------------------------------------------------------------------
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
