Skip to content
  1. Jan 30, 2013
  2. Jan 15, 2013
    • David Greene's avatar
      Disable Uninitialized Use Warnings for Broken gcc Versions · 57ad4297
      David Greene authored
      Some versions of gcc accept unsupported -W flags and run just fine if
      there are no warnings, but die with an unsupported flag error if a
      warning is encountered.  gcc 4.3 and gcc 4.4 both exhibit this
      behavior for -Wno-maybe-uninitialized.  Therefore, if the flag check
      for -Wno-maybe-uninitialized succeeds, only use
      -Wno-maybe-uninitialized if we are using gcc version 4.7 or greater.
      Use -Wno-uninitialized otherwise.
      
      llvm-svn: 172543
      57ad4297
  3. Jan 09, 2013
    • David Greene's avatar
      Disable -Wuninitialized for gcc · 9ff8d471
      David Greene authored
      If the compiler is gcc, disable variants of -Wuninitialized depending
      on the gcc version.  This gets a lot of false positive warnings out of
      the build.
      
      Generate a new configure for the gcc -Wno-uninitialized fix.
      
      Pick up -Wno-uninitialized from configure
      
      Add the option -Wno[-maybe]-uninitialized as determined by configure.
      
      llvm-svn: 172006
      9ff8d471
    • Dmitri Gribenko's avatar
      Configure: if we compile with clang, check that it is not broken · 06358bd0
      Dmitri Gribenko authored
      Some linux distibutions (for example, Mageia 2, Fedora 17) ship Clang that is
      essentially broken for the end user.  Clang can not find or compile libstdc++
      headers.
      
      The issue is that our configure prefers clang over gcc, thus selecting a broken
      Clang when a working GCC is available.
      
      Now we detect this issue by compiling a simple program.  If it does not
      compile, configure stops with an error suggesting the user to select a
      different compiler.
      
      llvm-svn: 171975
      06358bd0
  4. Jan 05, 2013
    • Chandler Carruth's avatar
      Finally, fix the autoconf setup to allow for a missing clock_gettime; · d121a7b0
      Chandler Carruth authored
      the source code should now be set up to handle this.
      
      llvm-svn: 171570
      d121a7b0
    • Chandler Carruth's avatar
      Add time getters to the process interface for requesting the elapsed · ef7f968e
      Chandler Carruth authored
      wall time, user time, and system time since a process started.
      
      For walltime, we currently use TimeValue's interface and a global
      initializer to compute a close approximation of total process runtime.
      
      For user time, this adds support for an somewhat more precise timing
      mechanism -- clock_gettime with the CLOCK_PROCESS_CPUTIME_ID clock
      selected.
      
      For system time, we have to do a full getrusage call to extract the
      system time from the OS. This is expensive but unavoidable.
      
      In passing, clean up the implementation of the old APIs and fix some
      latent bugs in the Windows code. This might have manifested on Windows
      ARM systems or other systems with strange 64-bit integer behavior.
      
      The old API for this both user time and system time simultaneously from
      a single getrusage call. While this results in fewer system calls, it
      also results in a lower precision user time and if only user time is
      desired, it introduces a higher overhead. It may be worthwhile to switch
      some of the pass timers to not track system time and directly track user
      and wall time. The old API also tracked walltime in a confusing way --
      it just set it to the current walltime rather than providing any measure
      of wall time since the process started the way buth user and system time
      are tracked. The new API is more consistent here.
      
      The plan is to eventually implement these methods for a *child* process
      by using the wait3(2) system call to populate an rusage struct
      representing the whole subprocess execution. That way, after waiting on
      a child process its stats will become accurate and cheap to query.
      
      llvm-svn: 171551
      ef7f968e
  5. Jan 02, 2013
  6. Jan 01, 2013
  7. Dec 26, 2012
  8. Dec 13, 2012
  9. Nov 19, 2012
  10. Nov 17, 2012
  11. Nov 14, 2012
  12. Oct 29, 2012
  13. Oct 01, 2012
    • Jordan Rose's avatar
      Re-enable support for --program-prefix. · 3c837abd
      Jordan Rose authored
      The Apple buildbots have been modified not to pass --target,
      so they shouldn't choke on a default program prefix anymore.
      
      Patch by Rick Foos!
      
      llvm-svn: 164956
      3c837abd
  14. Sep 28, 2012
  15. Sep 26, 2012
    • Jordan Rose's avatar
      Revert "Add --program-prefix support to build" · 2998d25a
      Jordan Rose authored
      The Apple buildbots are set up to pass --target to configure for both
      cross- and non-cross-compile builds, and the standard autoconf response
      to this is to set the program prefix to '<target>-'. Until we can figure
      out the proper way to handle this (don't pass --target? pass an explicit
      --program-prefix=""? don't auto-populate program_prefix with target_alias?)
      it's more important to keep the buildbots running.
      
      This reverts r164633 / ba48ceb1a3802e20e781ef04ea2573ffae2ac414.
      
      llvm-svn: 164651
      2998d25a
  16. Sep 25, 2012
  17. Sep 22, 2012
  18. Aug 28, 2012
  19. Aug 14, 2012
  20. Aug 09, 2012
  21. Aug 06, 2012
  22. Aug 03, 2012
  23. Jul 22, 2012
  24. Jul 16, 2012
  25. Jun 28, 2012
  26. May 24, 2012
  27. May 17, 2012
    • Danil Malyshev's avatar
      - Added ExecutionEngine/MCJIT tests · 7c5db453
      Danil Malyshev authored
      - Added HOST_ARCH to Makefile.config.in
      The HOST_ARCH will be used by MCJIT tests filter, because MCJIT supported only x86 and ARM architectures now.
      
      llvm-svn: 157015
      7c5db453
  28. May 08, 2012
  29. May 05, 2012
Loading