Don't treat bitcode files specially in llvm-ar.

We really want bitcode files to behave as regular object files in archives, so
we don't need to track that a member is bitcode.

llvm-svn: 185681

1 files changed, 0 insertions, 5 deletions

diff --git a/llvm/tools/llvm-ar/Archive.h b/llvm/tools/llvm-ar/Archive.h
index 3922e375ae3..977fe62d602 100644
--- a/llvm/tools/llvm-ar/Archive.h
+++ b/llvm/tools/llvm-ar/Archive.h
@@ -52,7 +52,6 @@ class ArchiveMember : public ilist_node<ArchiveMember> {
     enum Flags {
       SVR4SymbolTableFlag = 1,     ///< Member is a SVR4 symbol table
       BSD4SymbolTableFlag = 2,     ///< Member is a BSD4 symbol table
-      BitcodeFlag         = 4,     ///< Member is bitcode
       HasLongFilenameFlag = 8,     ///< Member uses the long filename syntax
       StringTableFlag     = 16     ///< Member is an ar(1) format string table
     };
@@ -121,10 +120,6 @@ class ArchiveMember : public ilist_node<ArchiveMember> {
     /// @brief Determine if this member is the ar(1) string table.
     bool isStringTable() const { return flags&StringTableFlag; }
 
-    /// @returns true iff the archive member is a bitcode file.
-    /// @brief Determine if this member is a bitcode file.
-    bool isBitcode() const { return flags&BitcodeFlag; }
-
     /// Long filenames are an artifact of the ar(1) file format which allows
     /// up to sixteen characters in its header and doesn't allow a path
     /// separator character (/). To avoid this, a "long format" member name is