================ @@ -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