On Fri, May 05, 2017 at 01:38:21PM +0200, Richard Biener wrote: > On Fri, May 5, 2017 at 12:41 PM, Martin Liška <mli...@suse.cz> wrote: > > Hello. > > > > There's first patch that just defines dump_flags_t as uint64_t and changes > > all > > corresponding interfaces that do use it. There's a problematic impact that > > all targets have to include dumpfile.h just right after coretypes.h. That > > makes > > the patch harder to properly test. I tried couple of cross-compilers and it > > works. > > > > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > > I've been also testing i686-linux-gnu bootstrap and x86_64-linux-gnu > > targets. > > > > Thoughts? > > So usually we get away with defining pervasive types in coretypes.h instead. > > Now I see how that can be not what we want if dump_flags_t becomes a > "class". Well, at least if it has too many (inline) methods. > > How many of our files end up including dumpfile.h? There's > > /* Most host source files will require the following headers. */ > #if !defined (GENERATOR_FILE) && !defined (USED_FOR_TARGET) > #include "machmode.h" > #include "signop.h" > #include "wide-int.h" > > at the end of coretypes.h so it might be possible to stuff dumpfile.h there. > > Or create a dump-flags.h header just containing the flag bits. I suppose > most files need it because they include some interfaces that have > dump_flags_t, not because they do dumping (they'd include dumpflags.h > already), right?
well, if a header uses dumpflags_t and a forward declaration won't do it should include it right? but continueing the coretypes.h hacks may be expedient. > Anyway, I think the patch is a good thing (how do we make sure we > don't "regress", aka people using 'int', not knowing about dump_flag_t?). does it make sense to define it as a struct whose only member is a uint64_t? That way you'd have to explicitly pull out the field wherever you want to pass it to something taking an int. That would require defining a bunch of operator &/| etc. However we could also move from there to a set of bitfields for most of the flags and usually not need to explicitly extract the bit we want. Trev
