Re: [eigen] Alignment issues

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


Il giorno 13/feb/2014, alle ore 15:01, Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> ha scritto:

> On 13.02.2014 14:42, Nicola Gigante wrote:
>> In fact, code that you warn the user about in the documentation seems to actually work in the same way:
>> class B {
>>     char c;
>>     Vector4f a;
>> };
> 
> With the above, could you try:
> 
> #include <vector>
> #include <iostream>
> 
> int main() {
> 	B* b = new B;
> 	B* b_arr = new B[10];
> 	std::vector<B> b_vec(10);
> 
> 	std::cout << b << "\n" << b_arr << "\n" << b_vec.data() << std::endl;
> }
> 
> These are basically the things that used to get wrong. Maybe those have been fixed by now, but they all fail on my gcc4.7 and clang3.1 on 32bit Linux.
> gcc does not even like the alignas(16) syntax (clang accepts it, but it does not influence the outcome).
> 

I can’t test that snippet because on OS X memory is always at least aligned at 16 bytes.
From the malloc man page:
"The allocated memory is aligned such that it can be used for any data type, including AltiVec- and SSE-related types.”
The same goes for C++ standard library implementations.

For that reason, in my previous email I paid attention at printing the value of alignof() instead of printing an actual address. If someone
can test that on Linux or Windows it would be great. However, operator new have to guarantee alignment requirements of
the allocated type (it’s a very basic feature of the language), so the allocation of ‘b’ should be always right (modulo compiler bugs, of course).
What I’m not sure about is the behavior of std::vector. I’m quite sure C++11 containers are required to pay attention to alignment 
requirements of the contained data type, and it’s not difficult given language support and library components as std::align and 
std::aligned_storage.

Please note that, especially regarding C++11 support, clang 3.1 is too old, and that gcc 4.7.0 have terrible bugs, so
everybody have to use at least 4.7.1 anyway.

What I’d suggest is to make a survey of the behaviors of various compiler/library/OS combinations, and clarify in the documentation
what is needed with a fully standard-compilant platform (in C++11, I suppose actually nothing) and what instead are workarounds for specific 
compiler bugs or limitations.


> Christoph

Nicola




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/