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)