================
@@ -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
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
