On 03.07.2018 12:36, Dimitry Sibiryakov wrote:
02.07.2018 16:01, Alex Peshkoff via Firebird-devel wrote:
Should 16-byte alignment be enforced only for x64 builds or for x86 too?
I would invite it for 32 bits too as it would let to use AES and
other 128 bits CPU commands without need to
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
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
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
On 17/02/2017 09:39, Stephan Bergmann wrote:
> On 02/17/2017 12:24 PM, Alex Peshkoff wrote:
>> On 02/17/17 14:15, Stephan Bergmann wrote:
>>
>> This idea seems to be much better than DEBUG_GDS_ALLOC:
>>
>>> Since LibreOffice builds intended for widespread distribution are on
>>> Linux usually done
On 17/02/2017 09:39, Stephan Bergmann wrote:
> On 02/17/2017 12:24 PM, Alex Peshkoff wrote:
>> On 02/17/17 14:15, Stephan Bergmann wrote:
>>
>> This idea seems to be much better than DEBUG_GDS_ALLOC:
>>
>>> Since LibreOffice builds intended for widespread distribution are on
>>> Linux usually done
On 02/17/2017 12:24 PM, Alex Peshkoff wrote:
> On 02/17/17 14:15, Stephan Bergmann wrote:
>
> This idea seems to be much better than DEBUG_GDS_ALLOC:
>
>> Since LibreOffice builds intended for widespread distribution are on
>> Linux usually done with GCC not Clang, this shouldn't have a
On 02/17/2017 12:21 PM, Alex Peshkoff wrote:
> On 02/17/17 14:15, Stephan Bergmann wrote:
>> 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
On 02/17/17 14:15, Stephan Bergmann wrote:
This idea seems to be much better than DEBUG_GDS_ALLOC:
> Since LibreOffice builds intended for widespread distribution are on
> Linux usually done with GCC not Clang, this shouldn't have a performance
> impact.)
But what makes me surprised - I know
On 02/17/17 14:15, Stephan Bergmann wrote:
> 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
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
>>
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)
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
13 matches
Mail list logo