[PATCH] D26968: [ARM] Add Driver support for emitting the missing Tag_ABI_enum_size build attribute values
Renato Golin via cfe-commits
cfe-commits at lists.llvm.org
Tue Nov 22 06:56:51 PST 2016
rengolin added inline comments.
================
Comment at: lib/Basic/Targets.cpp:5407
+ Builder.defineMacro("__ARM_SIZEOF_MINIMAL_ENUM",
+ Opts.ShortEnums || Opts.ABIEnums ? "1" : "4");
----------------
labrinea wrote:
> rengolin wrote:
> > Isn't ABIEnums 4? Shouldn't this be:
> >
> > Opts.ShortEnums || !Opts.ABIEnums
> >
> > Is it even valid to have ABIEnums && ShortEnums at the same time?
> My understanding is that ABIEnums requires 32-bit enums across an ABI-complying interface, but allows short enums outside of it. Therefore __ARM_SIZEOF_MINIMAL_ENUM could be any of 1 or 4.
>
> ABIEnums && ShortEnums cannot be both set at the same time.
If all four options are mutually exclusive, than they should be a single integer option, not multiple boolean ones.
================
Comment at: lib/Driver/Tools.cpp:5731
+
+ // The last of -fno-enums, -fshort-enums, -fabi-enums wins.
+ Arg *Enum;
----------------
labrinea wrote:
> rengolin wrote:
> > If this is true, why go the extra complexity of mapping all possible states? Why not just use one line:
> >
> > Enum = Args.getLastArg(options::OPT_fno_enums, options::OPT_fshort_enums, options::OPT_fabi_enums);
> >
> > and be done with it? Short and ABI are not compatible, it's either one or the other.
> I don't like this complicated logic either but it can handle cases like:
> -fshort-enums -fno-enums -fabi-enums -fno-abi-enums
> where -fno-enums should win. I've added a test for this sequence (test/Driver/clang_f_opts.c, line 459)
> The suggested logic would ignore '-fno-abi-enums', which is the last argument. If we are happy with rejecting all the preceding flags and keeping just the last one this would work:
> ```
> Args.getLastArg(options::OPT_fno_enums, options::OPT_fshort_enums, options::OPT_fno_short_enums,
> options::OPT_fabi_enums, options::OPT_fno_abi_enums);
> ```
> Alternatively an equally ugly logic that handles complicated sequences is:
> ```
> if (Arg *Enum = Args.getLastArg(options::OPT_fno_enums,
> ShortEnums ? options::OPT_fshort_enums : options::OPT_INVALID,
> ABIEnums ? options::OPT_fabi_enums : options::OPT_INVALID)) {
> ```
I disagree. These are different flags controlling the same thing, so the last-option wins.
How does -ffast-math vs its internal options are handled? How is -O handled? Or the other ABI flags like vfp, hard-float?
Easier still, have a look at unsigned/signed char below. Last arg wins.
https://reviews.llvm.org/D26968
More information about the cfe-commits
mailing list