Typedefs are stripping __alignof__ information. This is prohibiting work on TR1's aligned_storage. Which libstdc++ would like to use, both within the library and to implement a fixed-size, zero-allocation allocator for STL and string containers. Details here: http://gcc.gnu.org/ml/libstdc++/2004-09/msg00255.html -benjamin
Created attachment 7244 [details] test case test case
Add deps...
Actually this is the attribute aligned vs arrays. I cannot decode what the documenation means: Note that although you can ask the compiler to select a time-efficient alignment for a given type and then declare only individual stand-alone objects of that type, the compiler's ability to select a time- efficient alignment is primarily useful only when you plan to create arrays of variables having the relevant (efficiently aligned) type. If you declare or use arrays of variables of an efficiently-aligned type, then it is likely that your program will also be doing pointer arithmetic (or subscripting, which amounts to the same thing) on pointers to the relevant type, and the code that the compiler generates for these pointer arithmetic operations will often be more efficient for efficiently-aligned types than for other types.
Revert back some changes that I did not mean to do.
Subject: Re: __alignof__ vs. typedefs "pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | Actually this is the attribute aligned vs arrays. | | I cannot decode what the documenation means: | Note that although you can ask the compiler to select a | time-efficient alignment for a given type and | then declare only individual stand-alone objects of that type, the | compiler's ability to select a time- | efficient alignment is primarily useful only when you plan to create | arrays of variables having the | relevant (efficiently aligned) type. If you declare or use arrays of | variables of an efficiently-aligned type, | then it is likely that your program will also be doing pointer | arithmetic (or subscripting, which amounts | to the same thing) on pointers to the relevant type, and the code | that the compiler generates for these | pointer arithmetic operations will often be more efficient for | efficiently-aligned types than for other types. I don't see how much this is relevant to the different uses of the aligned attribute in the library. Right now, the compiler is just ignoring the aligned attribute. We're more intersted in the semantics than in the speed. What we want is to align a given *array object* at some alignment boundaries. We're not interested in pointer arithmetics on array types or speed -- although we may be doing pointer arithmetic on individual elements of the array, but that is a separate issue. The primarily thing is the ability to align an array object on a given boundary. -- Gaby
Benj, having a fix in time for 4.0 would help, or is it going to be 4.1 material anyway?
Subject: Re: __alignof__ vs. typedefs >Benj, having a fix in time for 4.0 would help, or is it going to be 4.1 >material anyway? Having a fix for this for 4.0.0 will definitely be useful. I'm kind of surprised that this isn't working right now, actually: I thought it was. See libstdc++-v3/src/globals*.cc. If somebody wants to change the subjet to something better go for it. -benjamin
Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01320.html
Subject: Re: __alignof__ vs. typedefs giovannibajo at libero dot it wrote: >------- Additional Comments From giovannibajo at libero dot it 2004-10-16 02:00 ------- >Patch submitted: >http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01320.html > > OK. But XFAIL the tr1 test cases so those do not show up as new FAILs.
Subject: Re: __alignof__ vs. typedefs >OK. But XFAIL the tr1 test cases so those do not show up as new FAILs. I think I just took care of this. Giovanni, thanks! -benjamin
Subject: Bug 17743 CVSROOT: /cvs/gcc Module name: gcc Changes by: giovannibajo@gcc.gnu.org 2004-10-17 04:39:46 Modified files: gcc/cp : ChangeLog decl2.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/ext: attrib17.C Log message: PR c++/17743 * decl2.c (grokfield): Apply attributes also to TYPE_DECLs. PR c++/17743 * g++.dg/ext/attrib17.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4440&r2=1.4441 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.753&r2=1.754 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4463&r2=1.4464 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/attrib17.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
OK, I fixed part of this for 4.0. The missing part is when the expression in attributes is dependent, like: template <class T> struct A { char foo __attribute__((aligned(__alignof__(T)))); }; This is non-trivial to fix. Benjamin, if you want you can keep this bugreport open to track this. I do not plan to be able to fix this in the 4.0 timeframe, so I have unassigned the bug (I will attempt something though). If somebody more expert than me wants to help the v3 guys, feel free. Otherwise, if you do not care about this, just close this bug.
Subject: Re: dependent expressions in attributes On Sat, 17 Oct 2004, giovannibajo at libero dot it wrote: | OK, I fixed part of this for 4.0. The missing part is when the expression in | attributes is dependent, like: | | template <class T> | struct A { | char foo __attribute__((aligned(__alignof__(T)))); | }; | | This is non-trivial to fix. Benjamin, if you want you can keep this bugreport | open to track this. I do not plan to be able to fix this in the 4.0 timeframe, | so I have unassigned the bug (I will attempt something though). If somebody | more expert than me wants to help the v3 guys, feel free. | | Otherwise, if you do not care about this, just close this bug. I do care. -- Gaby
Subject: Re: dependent expressions in attributes >> template <class T> >> struct A { >> char foo __attribute__((aligned(__alignof__(T)))); >> }; > > I do care. Is this a showstopper for tr1 work? Giovanni Bajo
Subject: Re: dependent expressions in attributes >Is this a showstopper for tr1 work? Not that I can see. From what I can tell, tr1::array is going to require default-constructable types. I think the library hackers are interested in this kind of stuff for our own selfish reasons. I guess I don't see why/how alignof should be different than sizeof here (which works): template <class T> struct A { char foo[sizeof(T)]; }; -benjamin
(In reply to comment #15) > I guess I don't see why/how alignof should be different than sizeof > here (which works): > template <class T> > struct A > { > char foo[sizeof(T)]; > }; Yes, but how do you force the compiler to ensure that the alignment of char foo [] is sufficient to placement-allocate an object of type T into it?
Giovanni, this is applicable to TR1 via 4.5.5 Other transformations [tr.meta.trans.other] template <std :: size_t Len , std :: size_t Align > struct aligned_storage { typedef unspecified type ; }; 1 type: an implementation defined POD type with size Len and alignment Align, and suitable for use as uninitialized storage for any object of a type whose size is Len and whose alignment is Align.
Subject: Re: dependent expressions in attributes >Yes, but how do you force the compiler to ensure that the alignment of char foo >[] is sufficient to placement-allocate an object of type T into it? ...get __alignof__(T) working? I don't see any other way, really. -benjamin
Jason, this is the bug I talked about briefly. Do you think the Redmond offsetof work is also applicable here?
(In reply to comment #19) > Jason, this is the bug I talked about briefly. Do you think > the Redmond offsetof work is also applicable here? Mind to share that?
Richard adding you.
Richard adding you. Any thoughts? We've been blocked on this for quite some time. There are a large number of issues that would be resolved or that we could try to make progress on if there was forward movement on this. -benjamin
I'm surprised this is considered tricky. Seems to me you just stuff the attribute away in the parse tree somewhere and pretend we've just read it in during template instantiation. That's what we do with everything else related to templates after all. "A mere matter of programming", I'd think.
Subject: Re: dependent expressions in attributes rth at gcc dot gnu dot org wrote: > ------- Comment #23 from rth at gcc dot gnu dot org 2005-10-05 21:16 ------- > I'm surprised this is considered tricky. Seems to me you just stuff the > attribute away in the parse tree somewhere and pretend we've just read it > in during template instantiation. That's what we do with everything else > related to templates after all. > > "A mere matter of programming", I'd think. I agree. There may be some attributes which need to be processed at parse-time, before instantiation-time, but that's just more programming. I'd expect it to involve touching rather more code than one would like, though...
Fixed for 4.3.0.
Change state.