[PATCH] D46300: [Clang] Implement function attribute no_stack_protector.

[Aaron Ballman via Phabricator via cfe-commits]

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