Skip to content
  1. Nov 30, 2012
    • Chandler Carruth's avatar
      Switch LLVM_USE_RVALUE_REFERENCES to LLVM_HAS_RVALUE_REFERENCES. · f12e3a67
      Chandler Carruth authored
      Rationale:
      1) This was the name in the comment block. ;]
      2) It matches Clang's __has_feature naming convention.
      3) It matches other compiler-feature-test conventions.
      
      Sorry for the noise. =]
      
      I've also switch the comment block to use a \brief tag and not duplicate
      the name.
      
      llvm-svn: 168996
      f12e3a67
  2. Nov 15, 2012
    • Daniel Dunbar's avatar
      PathV2: Fix a possible infinite loop. · 61d59f29
      Daniel Dunbar authored
       - The code could infinite loop trying to create unique files, if the directory
         containing the unique file exists, but open() calls on non-existent files in
         the path return ENOENT. This is true on the /dev/fd filesystem, for example.
      
       - Will add a clang side test case for this.
      
      llvm-svn: 168081
      61d59f29
  3. Oct 17, 2012
  4. Sep 28, 2012
  5. Sep 26, 2012
  6. Sep 22, 2012
  7. Sep 19, 2012
  8. Sep 11, 2012
  9. Sep 06, 2012
  10. Aug 15, 2012
  11. Aug 10, 2012
  12. Aug 06, 2012
  13. Jul 20, 2012
  14. Jul 12, 2012
  15. Jun 20, 2012
  16. Jun 16, 2012
    • Chandler Carruth's avatar
      Don't call 'FilesToRemove[0]' when the vector is empty, even to compute · 52de271d
      Chandler Carruth authored
      the address of it. Found by a checking STL implementation used on
      a dragonegg builder. Sorry about this one. =/
      
      llvm-svn: 158582
      52de271d
    • Chandler Carruth's avatar
      Harden the Unix signals code to be more async signal safe. · e6196eba
      Chandler Carruth authored
      This is likely only the tip of the ice berg, but this particular bug
      caused any double-free on a glibc system to turn into a deadlock! It is
      not generally safe to either allocate or release heap memory from within
      the signal handler. The 'pop_back()' in RemoveFilesToRemove was deleting
      memory and causing the deadlock. What's worse, eraseFromDisk in PathV1
      has lots of allocation and deallocation paths. We even passed 'true' in
      a place that would have caused the *signal handler* to try to run the
      'system' system call and shell out to 'rm -rf'. That was never going to
      work...
      
      This patch switches the file removal to use a vector of strings so that
      the exact text needed for the 'unlink' system call can be stored there.
      It switches the loop to be a boring indexed loop, and directly calls
      unlink without looking at the error. It also works quite hard to ensure
      that calling 'c_str()' is safe, by ensuring that the non-signal-handling
      code path that manipulates the vector always leaves it in a state where
      every element has already had 'c_str()' called at least once.
      
      I dunno exactly how overkill this is, but it fixes the
      deadlock-on-double free issue, and seems likely to prevent any other
      issues from sneaking up.
      
      Sorry for not having a test case, but I *really* don't know how to test
      signal handling code easily....
      
      llvm-svn: 158580
      e6196eba
  17. Jun 02, 2012
    • Benjamin Kramer's avatar
      Use access(2) instead of stat(2) to check if a file exists. · 172f8084
      Benjamin Kramer authored
      Apart from being slightly cheaper, this fixes a real bug that hits 32 bit
      linux systems. When passing a file larger than 2G to be linked (which isn't
      that uncommon with large projects such as WebKit), clang's driver checks
      if the file exists but the file size doesn't fit in an off_t and stat(2)
      fails with EOVERFLOW. Clang then says that the file doesn't exist instead
      of passing it to the linker.
      
      llvm-svn: 157891
      172f8084
  18. May 11, 2012
  19. May 08, 2012
  20. May 06, 2012
  21. May 05, 2012
  22. Apr 23, 2012
    • Michael J. Spencer's avatar
      [Support/Unix] Unconditionally include time.h. · 04b795bc
      Michael J. Spencer authored
      When building LLVM on Linux with libc++ with CMake TIME_WITH_SYS_TIME is
      undefined, and HAVE_SYS_TIME_H is defined. This ends up including
      sys/time.h but not time.h. Unix/TimeValue.inc requires time.h for asctime_r
      and localtime. libstdc++ seems to include time.h anyway, but libc++ does
      not.
      
      Fix this by always including time.h
      
      llvm-svn: 155382
      04b795bc
    • Sylvestre Ledru's avatar
      Conflict with st_dev/st_ino identifiers under Debian GNU/Hurd · 3099f4bd
      Sylvestre Ledru authored
      The problem is that the struct file_status on UNIX systems has two
      members called st_dev and st_ino; those are also members of the
      struct stat, and they are reserved identifiers which can also be
      provided as #define (and this is the case for st_dev on Hurd).
      The solution (attached) is to rename them, for example adding a
      "fs_" prefix (= file status) to them.
      
      Patch by Pino Toscano
      
      llvm-svn: 155354
      3099f4bd
  23. Apr 16, 2012
  24. Apr 11, 2012
  25. Mar 26, 2012
  26. Mar 24, 2012
  27. Feb 09, 2012
    • David Blaikie's avatar
      Change default error_code ctor to a 'named ctor' so it's more self-documenting. · 18544b96
      David Blaikie authored
      Unify default construction of error_code uses on this idiom so that users don't
      feel compelled to make static globals for naming convenience. (unfortunately I
      couldn't make the original ctor private as some APIs don't return their result,
      instead using an out parameter (that makes sense to default construct) - which
      is a bit of a pity. I did, however, find/fix some cases of unnecessary default
      construction of error_code before I hit the unfixable cases)
      
      llvm-svn: 150197
      18544b96
  28. Jan 15, 2012
    • Chandler Carruth's avatar
      Remove SetWorkingDirectory from the Process interface. Nothing in LLVM · da22f30e
      Chandler Carruth authored
      or Clang is using this, and it would be hard to use it correctly given
      the thread hostility of the function. Also, it never checked the return
      which is rather dangerous with chdir. If someone was in fact using this,
      please let me know, as well as what the usecase actually is so that
      I can add it back and make it more correct and secure to use. (That
      said, it's never going to be "safe" per-se, but we could at least
      document the risks...)
      
      llvm-svn: 148211
      da22f30e
  29. Jan 11, 2012
  30. Jan 05, 2012
  31. Jan 04, 2012
  32. Dec 14, 2011
Loading