sunfishcode added a subscriber: sunfishcode.
================
Comment at: lib/Basic/Targets.cpp:6943-6944
@@ +6942,4 @@
+
+ Diags.Report(diag::err_opt_not_valid_with_opt) << Feature
+ << "-target-feature";
+ return false;
----------------
echristo wrote:
> The backend should handle any weirdness here with missing features especially
> as this will report an error based on -cc1 compilation and not the main
> command line.
>
> I.e. it's not necessary, that said if you feel wedded to it there's no
> problem either.
I do feel more comfortable rejecting anything that I'm not specifically
expecting in this area.
================
Comment at: lib/Basic/Targets.cpp:7643-7649
@@ +7642,9 @@
+ case llvm::Triple::wasm64:
+ // Until specific variations are defined, don't permit any.
+ if (!(Triple == llvm::Triple("wasm64-unknown-unknown")) ||
+ (!Triple.getVendorName().empty() &&
+ Triple.getVendorName() != "unknown") ||
+ (!Triple.getOSName().empty() && Triple.getOSName() != "unknown") ||
+ (Triple.hasEnvironment() && Triple.getEnvironmentName() != "unknown"))
+ return nullptr;
+ return new WebAssemblyOSTargetInfo<WebAssembly64TargetInfo>(Triple);
----------------
echristo wrote:
> Ditto.
>
> (I said this just below, but it seems to have gotten munged in the newer
> version)
I actually did see your comment and updated the code accordingly. It now does a
positive test, `Triple == llvm::Triple("wasm64-unknown-unknown")`, which is
simpler than what it did before.
However, it's also doing additional tests, because the Triple class's
operator== doesn't distinguish between an Unknown that was actually "unknown"
or an unknown that was some other string. Until we figure out what "vendor",
"OS", and "environment" variations of wasm make sense (if any), we want to
avoid dealing with accidental alternate triples.
Repository:
rL LLVM
http://reviews.llvm.org/D12002
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
