[llvm-bugs] [Bug 32333] New: Odd type confuses OpenMP outlined Function Signature, result is "calling a function with a bad signature"

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Mar 17 16:29:56 PDT 2017


http://bugs.llvm.org/show_bug.cgi?id=32333

            Bug ID: 32333
           Summary: Odd type confuses OpenMP outlined Function Signature,
                    result is "calling a function with a bad signature"
           Product: OpenMP
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Clang Compiler Support
          Assignee: unassignedclangbugs at nondot.org
          Reporter: erich.keane at intel.com
                CC: llvm-bugs at lists.llvm.org

The following error happens on current trunk:

void llvm::CallInst::init(llvm::FunctionType*, llvm::Value*,
llvm::ArrayRef<llvm::Value*>,
llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, const llvm::Twine&):
Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) ==
Args[i]->getType()) && "Calling a function with a bad signature!"' failed.  

when compiling the SECOND function below.  First included for
discussion/comparison sake.

int a;
void fn1 ()
{
    int *c[a];
    #pragma omp parallel if(0)
    c[0][0];
}

void fn2 ()
{
    int(*b)[a];
    #pragma omp parallel if(0)
    b[0][0];
}

The issue is that the outlined function is generated with a different
signature, despite the Args being the same by the time the call comes around:

fn1 (good function), generates @.omp_outlined. with the signature:
define internal void @.omp_outlined.(i32* noalias %.global_tid., i32* noalias
%.bound_tid., i64 %vla, i32** %c) #2

fn2 (bad function) generates a similar function with the following signature
(note the last param!):
define internal void @.omp_outlined..1(i32* noalias %.global_tid., i32* noalias
%.bound_tid., i64 %vla, i32* %b) #0 


I debugged this down to CodeGenFunction::GenerateOpenMPCapturedStmtFunction. 
FuncInfo seems to be generated correctly, with its last param being
(gdb) p (FuncInfo.arg_begin() + 3)->type.Stored.dump() 
PointerType 0x99d6ac0 'int **'                         
`-PointerType 0x99d6550 'int *'                        
  `-BuiltinType 0x997b680 'int'  

AND
(gdb) p (FuncInfo.arg_begin() + 3)->type.Stored.dump()      
PointerType 0x99deea0 'int (*)[*]' variably_modified        
`-VariableArrayType 0x99dee60 'int [*]' variably_modified  *
  |-BuiltinType 0x997b680 'int'                             
  `-<<<NULL>>>                                              
RESPECTIVELY.

However, the conversion to FuncLLVMTy ends up switching these to int** and int*
instead of int** for both.

I'm basically lost as to where to debug from here.  I THINK that int *c[a] and
int (*c)[a] should eventually decay to the same type, but CGM doesn't seem to
think so.  Anyone have guidance or an idea on where to go next?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170317/2603634c/attachment.html>


More information about the llvm-bugs mailing list