================
@@ -3291,6 +3291,39 @@ void Darwin::addClangTargetOptions(
     if (!RequiresSubdirectorySearch)
       CC1Args.push_back("-fno-modulemap-allow-subdirectory-search");
   }
+
+  if (getTriple().isArm64e()) {
+    auto EnsureDefaultPtrauthFlag = [&](OptSpecifier Pos, OptSpecifier Neg) {
----------------
ahmedbougacha wrote:

> Does hasFlag(..) handle -ffoo -fno-foo correctly? I've assumed that it does 
> not?

It does;  per `ArgList.h`:

> If both the option and its negation are present, the last one wins.

and if it didn't, given how idiomatic it is in the driver, we should fix it

> The reason for the weird push_back setup is because the verbose 
> push_back("-ffoo") has always seemed error prone and difficult to maintain, 
> and given these are a series of identically structured args it seemed doing 
> the look up programmatically was better anyway?

In general I don't disagree, but I'd argue that would belong as a general 
utility we can recognize, same as `hasFlag`.  This being a special-purpose 
lambda just here makes it need a double-take to figure out that, yes, it does 
indeed behave the way you'd expect.


Note that `hasFlag` (or the lambda in the patch) vs. `hasArg` may subtly change 
the behavior here.  The `hasArg` version tries to only set a target default 
when neither `-f`/`-fno-` flag is passed, letting the earlier generic driver 
logic handle the forwarding of driver flags to cc1 (and this part could be 
generalized to all flags that follow the pattern).  With `hasFlag` I think 
you'd end up with the same flag twice in the cc1 command, which isn't wrong, 
just dumb.  Even after reading it, I'm not quite sure what this patch does;  I 
guess that's my point above ;)

In general, we should consider having the cc1 target machinery set these 
defaults, and only have the driver propagate overrides.  Some of the weirder 
darwin targets would need some thought (mkernel and whatnot), but that's a 
problem for another day.

https://github.com/llvm/llvm-project/pull/153722
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to