[Mlir-commits] [mlir] [mlir] Fix conflict of user defined reserved functions with internal prototypes (PR #123378)

[llvmlistbot at llvm.org]

================
@@ -48,53 +48,74 @@ static constexpr llvm::StringRef kMemRefCopy = "memrefCopy";
 LLVM::LLVMFuncOp mlir::LLVM::lookupOrCreateFn(Operation *moduleOp,
                                               StringRef name,
                                               ArrayRef<Type> paramTypes,
-                                              Type resultType, bool isVarArg) {
+                                              Type resultType, bool isVarArg,
+                                              bool isReserved) {
   assert(moduleOp->hasTrait<OpTrait::SymbolTable>() &&
          "expected SymbolTable operation");
   auto func = llvm::dyn_cast_or_null<LLVM::LLVMFuncOp>(
       SymbolTable::lookupSymbolIn(moduleOp, name));
-  if (func)
+  auto funcT = LLVMFunctionType::get(resultType, paramTypes, isVarArg);
+  // Assert the signature of the found function is same as expected
+  if (func) {
+    if (funcT != func.getFunctionType()) {
+      if (isReserved) {
+        func.emitError("redefinition of reserved function '" + name +
+                       "' of different type ")
+            .append(func.getFunctionType())
+            .append(" is prohibited");
+        exit(0);
----------------
jeanPerier wrote:

As far as flang is concerned, this could be a user error I think.

If one of the LLVM IR utility is used in the flow (I do not think flang is using those utilities directly, but flang is using the LLVM IR dialect, so they could be used indirectly in some pass) this could be hit if the Fortran user declares malloc "incorrectly" (as far as Fortran is concerned, the names are not reserved, the front-end is not enforcing a particular signature).

https://github.com/llvm/llvm-project/pull/123378