I have a test.c file which has this function call:
functiontest(2,x);
I would like to delete this function call (with an llvm pass) and when I try to use removeFromParent() function like this:
calledFunction1->removeFromParent();
this causes LLVM to produce the following error:
Referencing function in another module!
call void #functiontest(i32 2, float %tmp15)
LLVM ERROR: Broken function found, compilation aborted!
I also tried calling eraseFromParent() but this triggers an assert:
Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed.
I would prefer to use removeFromParent()
Any ideas what's wrong ?
First of all, it would be really helpful if you could post a minimal code sample that demonstrates your problem. Otherwise, we can only guess. Some observations though:
Why do you prefer removeFromParent? The call instruction has to be deleted too, that's what eraseFromParent does.
Did you call replaceAllUsesWith before erasing/removing? Otherwise, uses stick around.
Did you remove the function or the call instruction? This may explain the first error message.
Related
I am a fresh man on LLVM. Now I am trying figure out how to use the "getAnalysisUsage" method under the LLVM 7.0
In my (Module) pass, I just use:
void getAnalysisUsage(AnalysisUsage &AU) const {
AU.addRequired<AResultsWrapperPass>();
//AU.addRequired<AliasAnalysis>();
//AU.setPreservesAll();
}
When I try to compile it, I receive the following error:
error: ‘AResultsWrapperPass’ was not declared in this scope
error: no matching function for call to ‘llvm::AnalysisUsage::addRequired()’
I have search some similar question in this web:
LLVM Error When Using a Pass from Another Pass
However, it does not work. How can I fix this error?
It seems that you have a typo.
It should be AAResultsWrapperPass instead of AResultsWrapperPass
After adding the requirement, in order to make use of this analysis (e.g. in a runOnFunction method) you should do:
AliasAnalysis &aa = getAnalysis<AAResultsWrapperPass>().getAAResults();
I tried to run the makefile on https://github.com/nasadi/Zambezi. It shows an error like:-- "file included from src/driver/buildContiguous.c:7:0: src/shared/dictionary/Dictionary.h: In function ‘readDictionary’: src/shared/dictionary/Dictionary.h:132:8: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result [-Wunused-result] fread(&id, sizeof(int), 1, fp);" . Can anyone help me to run the program.Do i need to install any packages.I am new to c programming.
In fact, this is not an error, it is a warning. When compiler emits a warning, it means that code is syntactically correct but may potentially contain logic error.
In your case compiler says that return value of the fread function is not examined. Such ignorance can lead to a situation, where, for e.g., end of file is encountered, but the program is unaware of it and continues execution. Therefore, variable read from file have wrong value, and wrong (invalid) values may cause program crash later on.
Summarizing, if there are no other errors, then your program is successfully compiled and can be run.
I'm working with LuaJIT's FFI and I'm getting very strange results. This returns a PANIC: Unprotected Error (bad callback):
function idle(ms)
myDLL.myDLL_idle(session, ms)
end
But this simple print has fixed the problem.
function idle(ms)
print("anything")
myDLL.myDLL_idle(session, ms)
end
Another extremely odd solution is to use myDLL.myDLL_idle() inside the main function. How can this even be possible? It's not like I can just do any arbitrary function either if I put the call in a function, the only ones guaranteed to work are a print and sleep.
function idle(ms)
myDLL.myDLL_idle(session, ms)
end
myDLL.myDLL_idle(session, ms) -- works
idle(ms) -- doesn't work (unless first line of idle() is a print statement)
It's doing the same thing but just in another function. And the print fixing it if I try putting it in a function method just add to the complete weirdness of this. This is a huge problem.
According to the documentation, LuaJIT doesn't allow an FFI-call to be JIT-compiled if the FFI-code calls a C function that calls back into Lua via a stored callback. In most cases LuaJIT will detect those calls and avoid compilation, but if it doesn't, it aborts with the "bad callback" error message. The extra print helped, because it prevented JIT-compilation (print is not compiled atm.).
The proposed solution (instead of calling print) is to explicitly stop the FFI-call from being JIT-compiled using the jit.off function.
All of the samples I'm seeing show llvm::InitializeNativeTarget() being called on the first line.
I just finished building llvm and clang and am trying to get my first sample running and this function appears to be undefined. I'm not sure if it is actually undefined and these examples are stale, or if I did something wrong in a previous step.
Where would I find the definition of this function if it is supposed to exist? Is there something else I should be calling instead?
InitializeNativeTarget(); /* error, undefined */
llvm_start_multithreaded();
LLVMContext context;
string error;
llvm::OwningPtr<MemoryBuffer> buffer;
auto result = MemoryBuffer::getFile("test.bc", buffer);
auto m = ParseBitcodeFile(buffer.get(), context, &error);
auto ee = ExecutionEngine::create(m, true, &error);
With the code above, and a test.bc file compiled via clang I am getting a null ExecutionEngine so I'm assuming I'm not initializing something correctly.
Surprisingly hard to find but the function appears to have been renamed to:
LLVMInitializeNativeTarget()
Simply calling that function solved my problem.
(also I needed to call ExecutionEngine::create(m, false, &error) instead of true)
This is just a clarification. Actually, function llvm::InitializeNativeTarget can be found in
#include "llvm/Support/TargetSelect.h"
Your called function llvm::LLVMInitializeNativeTarget exists in
#include "llvm-c/Target.h"
The latter header file is already included by ExecutionEngine.h. Therefore you found it. Both functions seem identical (until v3.9.1 at least) except for their return value. However, the former is the one used in LLVM examples and I'd recommend sticking with it especially if you are using C++.
I would like to make compilation fail for some function call but not others. The function call that I want to fail are those that do not handle return values when the value is of a certain type. In the example below, not handling a function returning Error is a compilation error but not handling a function that returns anything else should succeed just fine.
Note: our runtime environment (embedded) does not allow us to use the following constructs: RTTI, exceptions.
This code only needs to compiler with Clang, I would prefer not having to annotate each function.
We prefer a solution that fails at compile time instead of at runtime.
enum class Error {
INVAL,
NOERR,
};
// do something that can fail.
Error DoThing();
// may return different return codes, we never care (we can't change prototype)
int DoIgnoredThing();
int main() {
DoThing(); // compilation failure here, unused "Error" result
DoIgnoredThing(); // compilation succeeds, OK to ignore unused "int" result
return 0;
}
I don't know of a way to do it with straight C++, but if you're using g++ you can use the warn_unused_result attribute along with the -Werror=unused-result command-line flag. See the documentation for warn_unused result for how to specify it (you'll have to specify it on every function unfortunately; I don't believe you can specify it for a type). Then the compiler flag will turn that warning into an error.
If you're not using g++, your compiler may have similar functionality.
You might find it easier to use a code analysis tool to scan the source code.
This might let you use the return type, as you requested, or a different marker for the functions to test like a comment to indicate which functions should be checked.
You might run the analysis tool as part of the compilation process or as part of a build server.
I've tried a few ways to make a class that would do what you want, but I haven't been successful. Have you considered making your "return value" an argument passed by reference? That's the most common way that I've seen APIs force you to pay attention to the return value. So instead of
Error DoThing();
you have
void DoThing(Error& e);
Anything that calls DoThing() has to pass in an Error object or they will get a compiler error. Again, not exactly what you asked for, but maybe good enough?