Compiling with OpenMP results in a memory leak

According to valgrind, I can induce a memory leak when compiling a simple hello-world program with OpenMP. This doesn't make sense, because the hello-world program does not intentionally use any OpenMP functionality.

Suppose the program below is named hi.c and compiled according to

$ gcc -o hi hi.c

GCC version 4.8.3

#include <stdio.h>

int main( void )
{
  printf( "hi\n" );
  return 1;
}

We should expect a leak report from valgrind to verify the obvious: there are no leaks. My observations agree with this hypothesis:

$ valgrind --tool=memcheck ./hi
==13064== Memcheck, a memory error detector
==13064== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==13064== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==13064== Command: ./hi
==13064== 
hi
==13064== 
==13064== HEAP SUMMARY:
==13064==     in use at exit: 0 bytes in 0 blocks
==13064==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==13064== 
==13064== All heap blocks were freed -- no leaks are possible
==13064== 
==13064== For counts of detected and suppressed errors, rerun with: -v
==13064== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

I would also expect to receive the same report after compiling with other flags. However, this is not the case. When I compile with the -fopenmp flag, I observe a memory leak

$ gcc -fopenmp -o hi hi.c

$ valgrind --tool=memcheck ./hi
==13084== Memcheck, a memory error detector
==13084== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==13084== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==13084== Command: ./hi
==13084== 
hi
==13084== 
==13084== HEAP SUMMARY:
==13084==     in use at exit: 8 bytes in 1 blocks
==13084==   total heap usage: 2 allocs, 1 frees, 32,824 bytes allocated
==13084== 
==13084== LEAK SUMMARY:
==13084==    definitely lost: 0 bytes in 0 blocks
==13084==    indirectly lost: 0 bytes in 0 blocks
==13084==      possibly lost: 0 bytes in 0 blocks
==13084==    still reachable: 8 bytes in 1 blocks
==13084==         suppressed: 0 bytes in 0 blocks
==13084== Rerun with --leak-check=full to see details of leaked memory
==13084== 
==13084== For counts of detected and suppressed errors, rerun with: -v
==13084== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

Does anyone understand why compiling with OpenMP causes this memory leak? Although this particular program does not invoke OpenMP, I want to be sure that I am handling memory properly when I do eventually use it.

That valgrind report does not depict a memory leak. The heap memory remaining allocated at program exit is still reachable.

Very likely your compiler's openmp implementation injects a global variable into your program, and causes it to be dynamically allocated as part of program startup (i.e. before main()).