llvm/lib/Bitcode/Reader, branch release_33 http://llvm.org https://git.amat.us/llvm/atom/lib/Bitcode/Reader?h=release_33 2013-05-05T00:40:33Z Add ArrayRef constructor from None, and do the cleanups that this constructor enables 2013-05-05T00:40:33Z Dmitri Gribenko gribozavr@gmail.com 2013-05-05T00:40:33Z urn:sha1:5c332dbd30d9398ed25b30c3080506f7b8e92290 Patch by Robert Wilhelm. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181138 91177308-0d34-0410-b5e6-96231b3b80d8 This patch breaks up Wrap.h so that it does not have to include all of 2013-05-01T20:59:00Z Filip Pizlo fpizlo@apple.com 2013-05-01T20:59:00Z urn:sha1:40be1e85665d10f5444186f0e7106e368dd735b8 the things, and renames it to CBindingWrapping.h. I also moved CBindingWrapping.h into Support/. This new file just contains the macros for defining different wrap/unwrap methods. The calls to those macros, as well as any custom wrap/unwrap definitions (like for array of Values for example), are put into corresponding C++ headers. Doing this required some #include surgery, since some .cpp files relied on the fact that including Wrap.h implicitly caused the inclusion of a bunch of other things. This also now means that the C++ headers will include their corresponding C API headers; for example Value.h must include llvm-c/Core.h. I think this is harmless, since the C API headers contain just external function declarations and some C types, so I don't believe there should be any nasty dependency issues here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180881 91177308-0d34-0410-b5e6-96231b3b80d8 Move C++ code out of the C headers and into either C++ headers 2013-04-22T22:47:22Z Eric Christopher echristo@gmail.com 2013-04-22T22:47:22Z urn:sha1:3e39731e88f2d4f597cebc74388fd6650ca4f604 or the C++ files themselves. This enables people to use just a C compiler to interoperate with LLVM. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180063 91177308-0d34-0410-b5e6-96231b3b80d8 Whitespace cleanup 2013-04-01T02:28:07Z Joe Abbey jabbey@arxan.com 2013-04-01T02:28:07Z urn:sha1:ef7964c1b78f57e277e74bda4f38e1143d1363fe git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178454 91177308-0d34-0410-b5e6-96231b3b80d8 Simplify code. No functionality change. 2013-02-19T09:48:30Z Jakub Staszak kubastaszak@gmail.com 2013-02-19T09:48:30Z urn:sha1:c61e83e6de778e5bd937e401564fe6bd0836b727 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175501 91177308-0d34-0410-b5e6-96231b3b80d8 Have the bitcode writer and reader handle the new attribute references. 2013-02-12T08:13:50Z Bill Wendling isanbard@gmail.com 2013-02-12T08:13:50Z urn:sha1:48fbcfe6b959df628a6455e00ac8d94fa6ade87a The bitcode writer emits a reference to the attribute group that the object at the given index refers to. The bitcode reader is modified to read this in and map it back to the attribute group. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174952 91177308-0d34-0410-b5e6-96231b3b80d8 Use a std::map so that we record the group ID. 2013-02-11T22:32:29Z Bill Wendling isanbard@gmail.com 2013-02-11T22:32:29Z urn:sha1:04ef4be048934f8acf15c4ed6e3ebdd410c252bb git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174910 91177308-0d34-0410-b5e6-96231b3b80d8 [tsan/msan] adding thread_safety and uninitialized_checks attributes 2013-02-11T08:13:54Z Kostya Serebryany kcc@google.com 2013-02-11T08:13:54Z urn:sha1:ab39afa9d9b99c61842c8e3d0eb706bd16efdcf3 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174864 91177308-0d34-0410-b5e6-96231b3b80d8 Add support in the bitcode reader to read the attribute groups. 2013-02-10T23:24:25Z Bill Wendling isanbard@gmail.com 2013-02-10T23:24:25Z urn:sha1:c3ba0a821b359060d76453023f3852954e6a5ee3 This reads the attribute groups. It currently doesn't do anything with them. NOTE: In the commit to the bitcode writer, the format *may* change in the near future. Which means that this code would also change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174849 91177308-0d34-0410-b5e6-96231b3b80d8 Fix the underlying problem that was causing read(0) to be called: sometimes the 2013-02-09T07:07:29Z Chris Lattner sabre@nondot.org 2013-02-09T07:07:29Z urn:sha1:b24f5b7c0838f22abc6f1ba5de2a17d25293cd17 bitcode writer would generate abbrev records saying that the abbrev should be filled with fixed zero-bit bitfields (this happens in the .bc writer when the number of types used in a module is exactly one, since log2(1) == 0). In this case, just handle it as a literal zero. We can't "just fix" the writer without breaking compatibility with existing bc files, so have the abbrev reader do the substitution. Strengthen the assert in read to reject reads of zero bits so we catch such crimes in the future, and remove the special case designed to handle this. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174801 91177308-0d34-0410-b5e6-96231b3b80d8