This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: x86/64 alignment, optimization, -Wcast-align


On Tue, Oct 25, 2016 at 6:24 PM, Balázs Oroszi <orobalage@gmail.com> wrote:
> I don't allocate the memory, I write a DLL and memory is handed to me
> as a byte array.

In that case, you need to provide an allocator (and deallocator) so
users of the DLL can allocate memory used by the DLL.

Providing the allocator is similar to the way Microsoft's Net* APIs
work. It avoids the problems with mismatched allocs/frees among
programs and DLLs, and it ensures your alignment requirements are met.
See, for example, NetApiBufferAllocate, NetApiBufferFree and
https://msdn.microsoft.com/en-us/library/windows/desktop/aa370675(v=vs.85).aspx.

Jeff

> 2016-10-26 0:10 GMT+02:00 Jeffrey Walton <noloader@gmail.com>:
>> On Tue, Oct 25, 2016 at 5:58 PM, Balázs Oroszi <orobalage@gmail.com> wrote:
>> Usually, you go the other way: you either (1) align to 16 for stack
>> based allocations, or (2) allocate on the heap, which has 16-byte
>> alignment. It allows you the benefit of vectorization and AVX.
>>
>> You also have to avoid the unaligned data accesses and type punning.
>> The undefined behavior sanitizers are usually very good about finding
>> them at runtime. Just compile with -fsanitize=undefined, and then run
>> your test suite.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]