Hi Gabe, I don¹t dare say whether this specific c++11 feature is supported or not, but as Steve says, check what gcc 4.6 (and most importantly, the standard library shipped with it) is able to do.
clang is usually a step ahead on this front, so I do not expect any issues. Andreas On 14/12/2014 12:37, "Steve Reinhardt via gem5-dev" <[email protected]> wrote: >Basically, yes. Certainly any C++11 feature that's supported by our >minimum revs of both g++ (4.6) and clang (??) is fair game. > >Steve > >On Sun, Dec 14, 2014 at 3:07 AM, Gabe Black via gem5-dev ><[email protected]> >wrote: >> >> It sounds like from this: >> >> http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=556 >> >> and this: >> >> >> >>http://stackoverflow.com/questions/10693913/c11-anonymous-union-with-non- >>trivial-members >> >> it might now be fixable if we're using C++11. Are we? >> >> Gabe >> >> On Fri, Dec 12, 2014 at 12:41 AM, Gabe Black <[email protected]> >>wrote: >> >> > Hi folks. This is mostly addressed to people up on fancy new language >> > features. Back when I implemented the BitUnion stuff, I discovered >>that >> > there was an annoying and serious bug which resulted from a >>limitation of >> > C++. At the time, I think I saw that the missing feature would become >> > available in the future. >> > >> > The quick version of how BitUnions work is that they are a class >>holding >> > an anonymous union of bitfield classes. The only data inside the >>bitfield >> > class is an instance of the underlying type of the bitunion. When >> accessing >> > the bitfield, operator overloading makes it extract or set the >>particular >> > field in question. The way the underlying data is set or extracted is >> > arbitrary and, unlike C bitfields, can be independent of endianness. >> > >> > So for instance, if you have a BitUnion64, it might expand to >>something >> > like this (pseudo-code-ey) >> > >> > class BitUnion64 >> > { >> > union { >> > uint64_t data; >> > class Bitfield<3, 1> a >> > { >> > uint64_t data; >> > } >> > class Bitfield<5, 4> b >> > { >> > uint64_t data; >> > } >> > }; >> > >> > That works just fine, even if it is a little bit dodgy in the way it >> > assumes the Bitfield classes are laid out. The problem is if you have >>two >> > bitfields of the same type (signed vs. unsigned, bit positions) and >>you >> > assign one to the other. What you expect to happen is that the value >>will >> > be extracted from one Bitfield, and then that value will be used to >>fill >> in >> > the other. If the types aren't perfect matches for each other, that's >> what >> > happens. If they *are* perfect matches for each other though, they'll >>be >> > assigned directly from one to the other. Since each actually contains >>a >> > complete copy of the underlying data (shared with the other bitfields >>and >> > the parent class) the entire value will be overwritten with the entire >> > other value, not just the bitfields. >> > >> > The thing you might use to solve this problem is to define a copy >> > constructor/assignment operator for a Bitfield type that would force >>it >> to >> > extract the bitfield from one and then insert it in the other like >>you'd >> > expect. The problem here is that you're not allowed to have >>non-default >> > constructors or something like that on types that go into unions >>(maybe >> > just anonymous unions?). I forget exactly what you were going to be >> allowed >> > to do that would let you fix this (constructor on an anonymous >>union?), >> but >> > it sounded like it was coming down the pipe. >> > >> > Any idea what that feature was and if it's available now? I'd really >>like >> > to get this fixed. It's bugged me for years that it's been broken like >> that. >> > >> > Gabe >> > >> _______________________________________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/gem5-dev >> >_______________________________________________ >gem5-dev mailing list >[email protected] >http://m5sim.org/mailman/listinfo/gem5-dev > -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
