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 <gabebl...@google.com> 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 gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev