On Fri, Jun 01, 2018 at 12:00:09PM +0200, Richard Biener wrote:
> On Tue, May 29, 2018 at 10:32 PM David Malcolm <[email protected]> wrote:
> >
> > The dump machinery uses "int" in a few places, for two different
> > sets of bitmasks.
> >
> > This patch makes things more self-documenting and type-safe by using
> > a new pair of enums: one for the dump_flags_t and another for the
> > optgroup_flags.
>
> Great! This should also make them accessible in gdb w/o using -g3.
>
> > This requires adding some overloaded bit operations to the enums
> > in question, which, in this patch is done for each enum . If the basic
> > idea is OK, should I add a template for this? (with some kind of
> > magic to express that bitmasking operations are only supported on
> > certain opt-in enums).
You may want to look at gdb's enum-flags.h which I think already
implements what your doing here.
>
> Does C++ allow > int enums? I think we want some way of knowing
> when either enum exceeds int (dump_flags_t was already uint64_t
> but you now make it effectively int again). That is, general wrapping
> for enum ops should chose an appropriate unsigned integer for
> the operation. So yes, a common implementation looks useful to me.
I don't remember very well, but istr C++ will actually use a 8 byte
integer if the enum contains constants larger than 2^32. Testing
sizeof enum x { A =0x400000000 }; gives the desired thing for me, but it
would still be good to check the standard.
Trev
>
> I think this patch is independently useful.
>
> Thanks,
> Richard.
>
> >
