2012-09-20  

  * 708d173a man/man1/papi_avail.1 man/man1/papi_clockres.1
  man/man1/papi_command_line.1...: Rebuild the manpages for a 5.0.1 release.

2012-09-19  

  * 29cdd839 doc/Doxyfile-common papi.spec src/Makefile.in...: Bump the version
  number for a 5.0.1 release.

  * bb7727f6 src/libpfm4/examples/fo src/libpfm4/examples/injectevt.c
  .../bin/usr/local/include/perfmon/perf_event.h...: Cleanup a botched libpfm4
  update.  As Steve Kaufmann noted, I botched an update of libpfm4.

2012-09-18  

  * dc117410 src/configure src/configure.in: Remove a trailing slash in libpfm4
  pathing.  Addresses an issue in rpmbuild when using bundled libpfm4. Reported
  and patched by William Cohen <wcohen@redhat.com>

2012-09-17  

  * e196b89b src/components/cuda/configure src/components/cuda/configure.in:
  Minor changes to CUDA configure necessary to get it running smoothly on the
  Kepler architecture.

2012-09-11  

  * 866bd51c src/papi_internal.c src/papi_preset.c: Fix preset bug  The preset
  code was only initializing the first element of the preset code[] array. 
  Thus any event with more than one subevent was not terminated at all, and the
  preset code would use random garbage as presets.  This exposed another
  problem; half our code assumed a 0 terminated code[] array, the rest was
  looking for PAPI_NULL (-1).  This standardizes on PAPI_NULL, with comments. 
  Hopefully this might fix PAPI bug #150.  This is a serious bug and should be
  included in the next stable release.

2012-08-29  

  * b978a744 src/configure src/configure.in: configure: fix autodetect perfmon
  case  The fixes I made yesterday to libpfm include finding broke on perfmon2
  PAPI if you were letting the library be autodetected. This change should fix
  things.  Tested on an actual 2.6.30 perfmon2 system.

  * 4386e6e5 src/libpfm4/Makefile src/libpfm4/README src/libpfm4/config.mk...:
  Update libpfm4 included with papi to 4.3

2012-08-28  

  * 729a8721 src/configure src/configure.in: configure: don't check for libpfm
  if incdir specified  When various --with-pfm values are passed, extra checks
  are done against the libpfm library.  This was being done even if only the
  include path was specified, which probably shouldn't be necessary.  This
  broke things because a recent change I made had the libpfm include path be
  always valid.

  * bc9ddffc src/configure src/configure.in: Fix compiling with separate
  libpfm4  The problem was if you used any of the --with-pfm-incdir type
  directives to configure, it would them assume you wanted a perfmon2 build. 
  This removes that assumption.  I did check this with perfmon2, perfctr, and
  perf_event builds so hopefully I didn't break anything.

2012-08-27  

  * 3b737198 src/papi.c src/papi_libpfm4_events.c src/papi_preset.c...: Hack
  around debugging macros.  Under NO_VARARG_MACROS configs the debug printing
  guys become two expression statements. This is bad for code expecting eg
  SUBDBG(); to be one statement.  --ie-- if ( foo ) SUBDBG("Danger Will
  Robinson"); ------  In order to keep the useful file and line number
  expansions with out variadic macro support, we split SUBDBG into two parts; A
  call to DEBUGLABEL() and friends and then a call to a function to capture the
  actual informative message.  So if(foo) stmt(); becomes if (foo)
  print_the_debug_label(); print_your_message(...); And your message is always
  printed.  See papi_debug.h for what actually happens.  I'm not clever enough
  to work around this any other way, so I exaustivly put { }s around every case
  of the above I found. (I only searched on 'DBG' so its possible I missed
  some)