I'm trying to iterate over uses of operand of store inst. I follow the programmer's manual to do this but I get error.
//x is store instruction pointing to [store i32 5, i32* %a, align 4]
Value *op2 = x->getOperand(1);
for (Value::use_iterator useItr=op2->use_begin(),useEnd=op2->use_end(); useItr!=useEnd;useItr++){
if (Instruction *Inst = dyn_cast_or_null<Instruction>(*useItr))
errs()<<"done";
}
I get this error message:
IR/Use.h:204: UserTy *llvm::value_use_iterator::operator*() const [UserTy = llvm::User]: Assertion `U && "Cannot dereference end iterator!"' failed.
In my understanding, If casting is not possible dyn_cast should return a null pointer not an error. I also tried dyn_cast_or_null, but same error.
Well, the problem seems to be with latest llvm code as I used the svn checkout for latest code. I finally took 3.4 stable release and everything works fine now.
Your error is from dereferencing useItr, not from the dyn_cast. Your code looks fine to me, so I took a look at the implementation of value_use_iterator, and the only way I can think of for your error to occur is if one of the value's uses is NULL.
A use of NULL is not something that can occur in a legal module, though. So I recommend running the verifier pass on your module before your code to see if it can spot the problem - otherwise you'll have to carefully examine the module yourself.
Related
When attempting to print out a custom hash map variable named "table" I seem to get this error with lldb:
error: expression failed to parse:
error: <lldb wrapper prefix>:45:31: no member named 'table' in namespace '$__lldb_local_vars'
using $__lldb_local_vars::table;
~~~~~~~~~~~~~~~~~~~~^
error: <user expression 2>:1:1: use of undeclared identifier 'table'
YES the variable is declared in this scope and in fact when switching to my laptop I can use LLDB just fine and print out the table contents.
I also notice other issues when printing out a different vector. It is clearly populated when adding print statements however when using lldb to print out the vector it shows it as unpopulated and all of size 0.
I am running Fedora 35 and I have tried updating and reinstalling lldb. As I said before, my laptop is able to print everything out just fine.
I have also tried following this post:
LLDB gives "use of undeclared identifier" error for local variable
using image lookup -va $pc yields the following results indicating that the table is present:
Variable: id = {0x00018088}, name = "table", type = "HashTable &", location = DW_OP_fbreg -904, decl = main.cpp:113:24
I can share the chunk of code giving me problems but I am not sure it is relevant. I simply pass this variable into the function by reference and print it. I can print it no where else in the program.
Note:
This extends beyond printing, I cannot access the size, capacity, or anything else relating to the 'table' variable. LLDB just throws this error.
Also perhaps on an unrelated note I noticed a few weeks ago that clearly deleted objects were still showing up and printable in LLDB. I could still access the variable and manipulate the data and what not but it was very clearly deleted. Again perhaps unrelated I suspected it was just that LLDB hadn't updated the variable list or something of this nature but it cost me a bit of time figuring out why the variable wasn't deleted.
Thanks for any help in advance
EDIIT:
Compiling with clang++ seems to fix my issue on my desktop? I could just use clang instead of g++ but I still am curious how this difference in compilers changes it? I suppose I understand it fundamentally but using g++ and lldb works without issue on my laptop. Is using lldb and g++ together a big no no?
(I must use lldb on my laptop as it is an M1 and only supports lldb I believe so I just opted to use lldb on my desktop as well)
I am getting this error while Deserializing an object in AX. To make it more weird its fine in my local but failing in other.
str sampleString = conpeek(nodeData, 1);
JArray jArray = JsonConvert::DeserializeObject(sampleString );
I just had this same issue. I don't know if your issue is the same as mine, but in my case, it was coming from an attempt to grab a boolean value from a deserialized container. It would work when running from the AX client, but didn't work when running from CIL. (CLR stuff sometimes behaves differently running locally vs on the server in CIL.) Solved the issue by grabbing the value as a string, then converting to boolean.
I keep on getting this error when trying to view objects in the Debugger in PyCharm:
Unable to display children:Attribute not found: value
I have deduced that it is an error with Pycharm itself, not my code
(I get the same error on multiple scripts, but no error on with an older version of Pycharm on 2 different computers)
I'm on PyCharm Community 2017.3.4
Any ideas for workarounds, other than installing an older version?
I am finding similar issues. I too think there is something up with PyCharm it does not work as expected or previous version as you mention. I also found Pyscripter to debug as expected.
In some instances I would rely on the result object, result[0] or result.getOutput(0) to pass to next tool. Instead one can use a variable for the "output" or use the string (name) directly as input for the next tool.
For example,
facility_staging_polygons = os.path.join(outGDB, 'facility_staging_polygons\Polygon_1')
result = arcpy.MakeFeatureLayer_management(facility_staging_polygons, 'facility_staging_polygons_Layer')
# Process: Update Attributes
arcpy.AddField_management('facility_staging_polygons_Layer', "area_calc", "LONG")
Why it is giving error
While deleting: i32 %
Use still stuck around after Def is destroyed: %in = alloca [3000 x i32], align 4
opt: Value.cpp:79: virtual llvm::Value::~Value(): Assertion `use_empty() && "Uses remain
when a value is destroyed!"' failed.
when I am running my LLVM Pass containing these lines
.
.
.
Type *t3=dyn_cast<Type>(ArrayType::get(Type::getInt32Ty(context),50));
AllocaInst *al2=new AllocaInst(t3,"ar",ins1);
.
.
.
Here I am trying to allocate a new array.
I assume your pass is doing more than emit an alloca? Your error line above has a 3000 element array while the code snippet below generates a 50 element one.
Are you doing possibly an eraseFromParent() on the alloca instruction above? An instruction cannot have any uses when it is being destroyed; You may want to look at replaceAllUsesWith() though I can't say much more without more information as to what your pass is doing.
I am trying to determine for certain Load instructions from my pass their corresponding Alloca instructions (that can be in other previous blocks). The chain can be something like : TargetLoad(var) -> other stores/loads that use var (or dependencies on var) -> alloca(var). , linked on several basic blocks. Do you know how can I do it?
I tried to use the methods from DependenceAnalysis and MemoryDependenceAnalysis, but the results were not correct. For instance, MemoryDependenceAnalysis::getDependency should be good with option "Def", but works only for stores, not for loads. Also I have a segfault when trying to use MemoryDependenceAnalysis::getNonLocalPointerDependency or MemoryDependenceAnalysis::getPointerDependencyFrom . When I try to check my result using MemDepResult::getDef(), the result for Load instructions is the same instruction ! So its depending on itself, that being weird since it is using a variable that is previously defined in the code.
The alternative of making the intersection for identifying common parts between all the variables used by target_load_instructions and all the allocated variables is not an option. Because there might be something like : alloca(a) ... c=a*b+4 .... load(c).
It seems also that DependenceAnalysis::depends() is not ok for my pass. The next line of code is only for reference: if(DA.depends(allocaInstrArray[i],loadInstrArray[j],true)) is always false. And it should be true in several cases. I think I am not using it correctly.
However, I made the assumption that maybe depends() does not work for Alloca. So I checked the dependencies among all Load instructions kept in an array. Some results are not based on the loaded variable as they should. For example: LOAD %3 = load i32* %c, align 4 IS DEPENDENT ON %1 = load i32* %j, align 4. As you can see, one is loading c and one is loading j. In my Test.cpp target code there is no dependence between j and c. Maybe the dependence is not based on variables/memory locations used?
Thank you for any suggestion !
First, use getOperand(0) or getOperand(1) of the ICMP instructions. If there is isa<LoadInst> valid, then cast them to LoadInst. getPointerOperand() will get the Value* that is the actual variable which is searched.
Second, do the same procedure between Load instructions and Alloca instructions. getOperand(0) applied on Load gives the corresponding Alloca instruction.
Finally, link the two results together, by checking the dependencies.