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
