aaron.ballman edited reviewers, added: probinson; removed: void.
aaron.ballman added a subscriber: probinson.
aaron.ballman added a comment.
Adding in @probinson as he originally added the `optnone` attribute. Paul, do
you recall why you opted (haha, pun totally intended) to implement `optnone`
rather than `optimize("O0")` from GCC?
================
Comment at: include/clang/Basic/Attr.td:1494
+def NoStackProtector : InheritableAttr {
+ let Spellings = [GCC<"no_stack_protector">];
+ let Subjects = SubjectList<[Function]>;
----------------
manojgupta wrote:
> aaron.ballman wrote:
> > This is not a GCC attribute, so this should use the Clang spelling.
> >
> > However, why spell the attribute this way rather than use the GCC spelling
> > (`optimize("no-stack-protector")`?
> Thanks, I have changed it to use Clang spelling.
>
> Regarding __attribute__((optimize("..."))), it is a generic facility in GCC
> that works for many optimizer flags.
> Clang currently does not support this syntax currently instead preferring its
> own version for some options e.g. -O0.
> e.g.
> ```
> __attribute__((optimize("O0"))) // clang version is __attribute__((optnone))
> ```
> If we want to support the GCC syntax, future expectation would be support
> more flags under this syntax. Is that the path we want to take (I do not know
> the history related to previous syntax decisions but better GCC compatibility
> will be a nice thing to have)
The history of `optnone` predates my involvement with Clang and I've not been
able to find the original review thread (I did find the one where I gave my
LGTM on the original patch, but that was a resubmission after the original
design was signed off).
I'm not keen on attributes that have the same semantics but differ in spelling
from attributes supported by GCC unless there's a good reason to deviate. Given
that we've already deviated, I'd like to understand why better -- I don't want
to push you to implement something we've already decided was a poor design, but
I also don't want to accept code if we can instead use syntax that is
compatible with GCC.
Repository:
rC Clang
https://reviews.llvm.org/D46300
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
