------- Comment #8 from sebor at roguewave dot com 2007-03-15 23:51 -------
Some additional comments on the request precipitated by a discussion with the
implementers of another compiler:
The rationale for allowing the attribute on individual members is to provide
fine-grained control over which members the compiler should be allowed to
reorder and which it shouldn't.
For instance, I might want to define an aggregate struct that's optimally laid
out for space except for the first member which needs to be aligned at a
specific boundary:
template <class T, class U>
struct S __attribute ((aligned (16))) {
size_t refcount;
public: T first __attribute ((reorder));
public: U second __attribute ((reorder));
};
I know I could put T and U in a nested struct but I shouldn't need to do that.
Btw., since today's compiles are allowed to reorder first and second (but not
refcount), I think it's important that the the __attribute ((reorder)) be
considered in conjunction with the access specifier(s) so that when the
compiler implements reordering by default (i.e., w/o the attribute), the layout
of structs with members marked up with the attribute will stay the same even
after removing it. I.e., when gcc 5 comes out in 201X, it would be useful if
struct S below were laid out exactly the same as the struct S above generated
by gcc 4:
template <class T, class U>
struct S __attribute ((aligned (16)) {
size_t refcount;
public: T first; // no attribute
public: U second; // no attribute
};
Declaring S members with __attribute((reorder)) but without the access
specifiers otherwise necessary to allow the members to be reordered should have
no effect and give a diagnostic (warning or remark):
template <class T, class U>
struct S __attribute ((aligned (16)) {
size_t refcount;
public:
T first __attribute ((reorder));
U second __attribute ((reorder));
};
Ditto if only first or only second (and not both) had an access specifier.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
