On Fri, Jun 01, 2018 at 12:00:09PM +0200, Richard Biener wrote: > On Tue, May 29, 2018 at 10:32 PM David Malcolm <dmalc...@redhat.com> 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. > > >