Remove a hack that tries to understand incorrect triples from the
Triple class constructor. Only valid triples should now be used
inside LLVM - front-ends are now responsable for rejecting or
correcting invalid target triples. The Triple::normalize method
can be used to straighten out funky triples provided by users.
Give this a whirl through the buildbots to see if I caught all
places where triples enter LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112470 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html
index f9f492c..b937f7d 100644
--- a/docs/ReleaseNotes.html
+++ b/docs/ReleaseNotes.html
@@ -348,6 +348,11 @@
SMDiagnostic takes different parameters now. //FIXME: how to upgrade?
</li>
<li>
+ The constructor for the Triple class no longer tries to understand odd triple
+ specifications. Frontends should ensure that they only pass valid triples to
+ LLVM. The Triple::normalize utility method has been added to help front-ends
+ deal with funky triples.
+<li>
Some APIs got renamed:
<ul>
<li>llvm_report_error -> report_fatal_error</li>
diff --git a/lib/Support/Triple.cpp b/lib/Support/Triple.cpp
index 7806aec..3a95b65 100644
--- a/lib/Support/Triple.cpp
+++ b/lib/Support/Triple.cpp
@@ -323,22 +323,6 @@
Vendor = ParseVendor(getVendorName());
OS = ParseOS(getOSName());
- // Handle some exceptional cases where the OS / environment components are
- // stuck into the vendor field.
- // TODO: Remove this logic and have places that need it use 'normalize'.
- if (StringRef(getTriple()).count('-') == 1) {
- StringRef VendorName = getVendorName();
-
- if (VendorName.startswith("mingw32")) { // 'i386-mingw32', etc.
- Vendor = PC;
- OS = MinGW32;
- return;
- }
-
- // arm-elf is another example, but we don't currently parse anything about
- // the environment.
- }
-
assert(isInitialized() && "Failed to initialize!");
}