RFR: 8177346: hotspot change for 8176513 breaks jdk9 build on Ubuntu 16.04

[Phil Race]

Please review a small JDK 9 build fix for a build failure due to

hotspot/src/share/vm/opto/library_call.cpp:2578:3: error: ‘need_mem_bar’ 
may be used uninitialized in this function [-Werror=maybe-uninitialized]
    if (need_mem_bar) insert_mem_bar(Op_MemBarCPUOrder);

https://bugs.openjdk.java.net/browse/JDK-8177346

I can't explain why GCC 5.4 woke up and decided to start reporting this 
warning when
nothing logically changed that would trigger it. However I think it 
should already have
been triggered -  it is clear to me that the compiler has a point.

The fix is simple and provided in-line below :-
---

hg diff src/share/vm/opto/library_call.cpp
diff --git a/src/share/vm/opto/library_call.cpp 
b/src/share/vm/opto/library_call.cpp
--- a/src/share/vm/opto/library_call.cpp
+++ b/src/share/vm/opto/library_call.cpp
@@ -2372,7 +2372,7 @@
    // the barriers get omitted and the unsafe reference begins to "pollute"
    // the alias analysis of the rest of the graph, either 
Compile::can_alias
    // or Compile::must_alias will throw a diagnostic assert.)
-  bool need_mem_bar;
+  bool need_mem_bar = false;
    switch (kind) {
        case Relaxed:
            need_mem_bar = mismatched && !adr_type->isa_aryptr();

---

In fact this initialisation pattern is already used in other nearly 
identical cases in
the same function.
eg this one about 20 lines before my update
   bool mismatched = false;

and this one about 20 lines after ..
   bool requires_atomic_access = false;

So there is ample precedent.

I will get the appropriate RDP2 approvals to push once code review is 
complete.
I also anticipate that by the time this happens I will need to push it to
http://hg.openjdk.java.net/jdk9/dev/hotspot/
as per the email here :
http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-March/026155.html

Let me know if you think otherwise.

JPRT is being used to build/test the fix.

-phil.