Skip to content
  1. Oct 02, 2013
    • Tim Northover's avatar
      MCJIT: skip some more new multi-module tests on unsupported platforms. · 39ddb3f9
      Tim Northover authored
      This should fix the i386 Darwin build-bot.
      
      llvm-svn: 191840
      39ddb3f9
    • Filip Pizlo's avatar
      This threads SectionName through the allocateCodeSection/allocateDataSection... · 7aa695e0
      Filip Pizlo authored
      This threads SectionName through the allocateCodeSection/allocateDataSection APIs, both in C++ and C land.  
      It's useful for the memory managers that are allocating a section to know what the name of the section is.  
      At a minimum, this is useful for low-level debugging - it's customary for JITs to be able to tell you what 
      memory they allocated, and as part of any such dump, they should be able to tell you some meta-data about 
      what each allocation is for.  This allows clients that supply their own memory managers to do this.  
      Additionally, we also envision the SectionName being useful for passing meta-data from within LLVM to an LLVM 
      client.
      
      This changes both the C and C++ APIs, and all of the clients of those APIs within LLVM.  I'm assuming that 
      it's safe to change the C++ API because that API is allowed to change.  I'm assuming that it's safe to change 
      the C API because we haven't shipped the API in a release yet (LLVM 3.3 doesn't include the MCJIT memory 
      management C API).
      
      llvm-svn: 191804
      7aa695e0
  2. Oct 01, 2013
    • Tareq A. Siraj's avatar
      Add non-blocking Wait() for launched processes · d88b9832
      Tareq A. Siraj authored
      - New ProcessInfo class to encapsulate information about child processes.
      - Generalized the Wait() to support non-blocking wait on child processes.
      - ExecuteNoWait() now returns a ProcessInfo object with information about
        the launched child. Users will be able to use this object to
        perform non-blocking wait.
      - ExecuteNoWait() now accepts an ExecutionFailed param that tells if execution
        failed or not.
      
      These changes will allow users to implement basic process parallel
      tools.
      
      Differential Revision: http://llvm-reviews.chandlerc.com/D1728
      
      llvm-svn: 191763
      d88b9832
    • Andrew Kaylor's avatar
      Tests for MCJIT multiple module support · 6bbb2c9f
      Andrew Kaylor authored
      llvm-svn: 191723
      6bbb2c9f
  3. Sep 30, 2013
  4. Sep 29, 2013
  5. Sep 27, 2013
  6. Sep 20, 2013
  7. Sep 11, 2013
  8. Sep 10, 2013
    • Rui Ueyama's avatar
      Try to unbreak mingw32 buildbot. · 754a3ead
      Rui Ueyama authored
      llvm-svn: 190438
      754a3ead
    • Rui Ueyama's avatar
      Add getenv() wrapper that works on multibyte environment variable. · 471d0c57
      Rui Ueyama authored
      On Windows, character encoding of multibyte environment variable varies
      depending on settings. The only reliable way to handle it I think is to use
      GetEnvironmentVariableW().
      
      GetEnvironmentVariableW() works on wchar_t string, which is on Windows UTF16
      string. That's not ideal because we use UTF-8 as the internal encoding in LLVM.
      This patch defines a wrapper function which takes and returns UTF-8 string for
      GetEnvironmentVariableW().
      
      The wrapper function does not do any conversion and just forwards the argument
      to getenv() on Unix.
      
      Differential Revision: http://llvm-reviews.chandlerc.com/D1612
      
      llvm-svn: 190423
      471d0c57
  9. Sep 09, 2013
    • Bob Wilson's avatar
      Update CMake file to fix buildbots. · 6b28b318
      Bob Wilson authored
      llvm-svn: 190331
      6b28b318
    • Bob Wilson's avatar
      Revert patches to add case-range support for PR1255. · e407736a
      Bob Wilson authored
      The work on this project was left in an unfinished and inconsistent state.
      Hopefully someone will eventually get a chance to implement this feature, but
      in the meantime, it is better to put things back the way the were.  I have
      left support in the bitcode reader to handle the case-range bitcode format,
      so that we do not lose bitcode compatibility with the llvm 3.3 release.
      
      This reverts the following commits: 155464, 156374, 156377, 156613, 156704,
      156757, 156804 156808, 156985, 157046, 157112, 157183, 157315, 157384, 157575,
      157576, 157586, 157612, 157810, 157814, 157815, 157880, 157881, 157882, 157884,
      157887, 157901, 158979, 157987, 157989, 158986, 158997, 159076, 159101, 159100,
      159200, 159201, 159207, 159527, 159532, 159540, 159583, 159618, 159658, 159659,
      159660, 159661, 159703, 159704, 160076, 167356, 172025, 186736
      
      llvm-svn: 190328
      e407736a
  10. Sep 04, 2013
  11. Sep 03, 2013
  12. Aug 30, 2013
    • Eli Friedman's avatar
      Change default # of digits for APFloat::toString · e72f1320
      Eli Friedman authored
      This is a re-commit of r189442; I'll follow up with clang changes.
      
      The previous default was almost, but not quite enough digits to
      represent a floating-point value in a manner which preserves the
      representation when it's read back in.  The larger default is much
      less confusing.
      
      I spent some time looking into printing exactly the right number of
      digits if a precision isn't specified, but it's kind of complicated,
      and I'm not really sure I understand what APFloat::toString is supposed
      to output for FormatPrecision != 0 (or maybe the current API specification
      is just silly, not sure which).  I have a WIP patch if anyone is interested.
      
      llvm-svn: 189624
      e72f1320
  13. Aug 28, 2013
  14. Aug 22, 2013
  15. Aug 21, 2013
  16. Aug 19, 2013
  17. Aug 16, 2013
Loading