This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 1/N] Introduce dump_flags_t type and use it instead of int type.
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 <mliska@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