Hi Nathan!

Merging back your trunk r230169 into gomp-4_0-branch, for the new
libgomp/testsuite/libgomp.oacc-c-c++-common/firstprivate-2.c test, I'm
seeing the compiler diagnose as follows (compile with "-Wall -O2"):

    source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/firstprivate-2.c: In function 'main._omp_fn.1':
    source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/firstprivate-2.c:20:17: warning: 'val' is used uninitialized in this function [-Wuninitialized]
           ok  = val == 7;
                     ^
    
    source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/firstprivate-2.c:9:7: note: 'val' was declared here
       int val = 2;
           ^

..., and execution fails ("return 1" from main), so I XFAILed the
execution in the merge commit r230214 on gomp-4_0-branch.  (..., and I
still think that it's a good idea to change the libgomp testsuite to run
with -Wall enabled...)

Do you have an idea what's going on?  Given your preparatory "[gomp4]
Rework gimplifyier region flags",
<http://news.gmane.org/find-root.php?message_id=%3C56434833.7010703%40acm.org%3E>
(thanks!), the merge commit r230214 on gomp-4_0-branch didn't contain any
changes to gcc/gimplify.c, so that can't be it.  It also can't be the
possibly inconsistent usage of gcc/omp-low.c:is_reference vs. "TREE_CODE
(TREE_TYPE ([...])) == REFERENCE_TYPE" in gcc/omp-low.c, because that
doesn't matter for C code anyway (no artificial REFERENCE_TYPEs
generated), right?  So it must be some other change installed on
gomp-4_0-branch but not on trunk.


Grüße
 Thomas