This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [options] Allow Var() and Mask() to be used together
DJ Delorie <dj@redhat.com> writes:
>> ...why? Do you really have > 31 masks that need to be controlled
>> by the configury machinery? If not, you can just use Var(...)s.
>> (And that was the reason why I started on the target .opt thing
>> in the first place.)
>
> It's for grouping flags that have nothing to do with the target.
Hmm. In that case, the names of the macros seem a bit confusing:
> for (i = 0; i < n_opts; i++) {
> name = opt_args("Mask", flags[i])
> + vname = var_name(flags[i])
> + if (vname == "")
> + vname = "target_flags"
> if (name != "" && !flag_set_p("MaskExists", flags[i]))
> print "#define TARGET_" name \
> - " ((target_flags & MASK_" name ") != 0)"
> + " ((" vname " & MASK_" name ") != 0)"
It sounds like we'll have TARGET_* macros associated with non-target
things. Using MASK_* constants for non-target options might also be
dangerous because of the risk of a name clash.
I think it would also make sense to extend:
> -if (masknum > 31)
> +if (masknum[""] > 31)
> print "#error too many target masks"
so that it applies to all variables, not just target_flags.
(Not that I can approve this anyway of course. It's just an opinion. ;)
> The case I was considering was a group of warnings, where you want to
> quickly test to see if ANY of the warnings are enabled, but allow
> individual testing as well. Having the warnings be bits sharing an
> int variable makes testing them as a group trivial. This is in the
> context of the warning control project I'm working on, where we want
> to add fine grained control over warnings without sacrificing
> performance.
Ah, OK, I hadn't realised that was why you wanted it. I can see why
that makes sense.
Richard