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? 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?). I'd probably, as a first step, simply put the typedef into coretypes.h. A patch doing that instead of sprinkling dumpfile.h everywhere is ok. Thanks, Richard. > Martin
