labrinea abandoned this revision.
labrinea added a comment.
Hi Renato, apologies for the long silence. Unfortunately this work is more
complicated than I initially thought. We'll have to rethink about it
thoroughly. I am going to abandon the patch for now. Thank you for reviewing
this.
labrinea added a comment.
Your suggestion that if all four options are mutually exclusive, then they
should be a single integer option, totally makes sense to me. We could use a
single integer option and make the old boolean flags deprecated (i.e. map
'-fshort-enums' and 'fno-short enums' to
rengolin added a comment.
How does GCC behave with those arguments?
Thinking back now, we may be required to follow, as the principle of least
surprise has to hold.
https://reviews.llvm.org/D26968
___
cfe-commits mailing list
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?
labrinea added inline comments.
Comment at: lib/Basic/Targets.cpp:5407
+ Builder.defineMacro("__ARM_SIZEOF_MINIMAL_ENUM",
+ Opts.ShortEnums || Opts.ABIEnums ? "1" : "4");
rengolin wrote:
> Isn't ABIEnums 4? Shouldn't this be:
>
>
rengolin added a comment.
Hi Alexandros,
My interpretation of `Tag_ABI_enum_size` is that value 3 is that **all** enums
are 32-bit and value 4 is that only those ABI-visible (ie. public interfaces)
have to be 32-bits. This is similar to the other PCS tags.
So, the table is:
- 0: no enums
-
