[mlir] Fix gcc 5.5 build break

[rriddle]

mlir/lib/Dialect/Linalg/Utils/Utils.cpp

101

Have you checked to see if this actually fixes the issue? Last time I ran into this, I had to explicitly wrap the def in:

namespace ... {

}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56480

[nicolasvasilache]

Pushing a patch that wraps in the namespace as Jacques and River suggested.

mlir/lib/Dialect/Linalg/Utils/Utils.cpp

101

I submitted this as a hotpatch and you're right.
Problem is that we can't get easy access to a gcc-5 ..
Jacques tested the wrapper version through docker and it works, sending another hotpatch now.

[nicolasvasilache]

This should be unnecessary now.

[asaadaldien]

Thanks @nicolasvasilache

mlir/lib/Dialect/Linalg/Utils/Utils.cpp

if (fun)
     fun();
   for (auto &lit : reverse(loops)) {
     lit({});
   }
   return ValueHandle::null();
 }
 
 template <>
-GenericLoopNestRangeBuilder<loop::ForOp>::GenericLoopNestRangeBuilder(
-    ArrayRef<edsc::ValueHandle *> ivs, ArrayRef<Value> ranges) {
+mlir::edsc::GenericLoopNestRangeBuilder<
+    loop::ForOp>::GenericLoopNestRangeBuilder(ArrayRef<edsc::ValueHandle *> ivs,
+                                              ArrayRef<Value> ranges) {
   builder = std::make_unique<LoopNestRangeBuilder>(ivs, ranges);
 }
 
 template <>
-GenericLoopNestRangeBuilder<AffineForOp>::GenericLoopNestRangeBuilder(
-    ArrayRef<ValueHandle *> ivs, ArrayRef<Value> ranges) {
+mlir::edsc::GenericLoopNestRangeBuilder<
+    AffineForOp>::GenericLoopNestRangeBuilder(ArrayRef<ValueHandle *> ivs,
+                                              ArrayRef<Value> ranges) {
   SmallVector<ValueHandle, 4> lbs;
   SmallVector<ValueHandle, 4> ubs;
   SmallVector<int64_t, 4> steps;
   for (const Value range : ranges) {
     assert(range.getType() && "expected linalg.range type");
     assert(range.getDefiningOp() && "need operations to extract range parts");
     RangeOp rangeOp = cast<RangeOp>(range.getDefiningOp());
     lbs.emplace_back(ValueHandle(rangeOp.min()));