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

Reply via email to