search for: lvalue

...; <i64*> [#uses=1] %6 = load i64* %key_token2_addr, align 8 ; <i64> [#uses=1] store i64 %6, i64* %5, align 8 ... The store alignment 8 is wrong. The address iospec has 4-byte alignment. The problem is llvm-gcc TreeToLLVM::EmitMODIFY_EXPR: LValue LV = EmitLV(lhs); bool isVolatile = TREE_THIS_VOLATILE(lhs); unsigned Alignment = expr_align(exp) / 8 It's using the alignment of the expression, rather than the memory object of LValue. The patch saves the alignment of the memory object in LValue returned by EmitLV(). Please review...

Hi Evan, > LValue LV = EmitLV(lhs); > bool isVolatile = TREE_THIS_VOLATILE(lhs); > unsigned Alignment = expr_align(exp) / 8 > > It's using the alignment of the expression, rather than the memory > object of LValue. can't you just use expr_align(lhs) instead? > The patch saves the...

...declaration of function 'RAX_sig' signal_x86_64.c:176: error: 'sigcontext' undeclared (first use in this function) signal_x86_64.c:176: error: (Each undeclared identifier is reported only once signal_x86_64.c:176: error: for each function it appears in.) signal_x86_64.c:176: error: lvalue required as left operand of assignment signal_x86_64.c:177: warning: implicit declaration of function 'RCX_sig' signal_x86_64.c:177: error: lvalue required as left operand of assignment signal_x86_64.c:178: warning: implicit declaration of function 'RDX_sig' signal_x86_64.c:178: err...

Daniel, > This is an aggregate type that includes a type compatible > with the effective type of the object. In particular, > x->i is an lvalue expression of type "int" > b->a is an lvalue expression of type "struct A" > "struct A" is an aggregate type that includes "int" among > its members. > Therefore, the b->a object may access x->i by TBAA My understanding is in x->i...

...ol:32, col:37> col:37 used curr_frame 'cv::Mat &' | |-ParmVarDecl 0x7ff113148780 <col:49, col:54> col:54 used frame_id 'int &' | `-CompoundStmt 0x7ff1131537d8 <col:64, line:486:1> | |-UnaryOperator 0x7ff113148930 <line:482:5, col:7> 'int' lvalue prefix '++' | | `-DeclRefExpr 0x7ff113148908 <col:7> 'int' lvalue ParmVar 0x7ff113148780 'frame_id' 'int &' | |-ExprWithCleanups 0x7ff1131536e8 <line:483:5, line:484:32> 'cv::VideoCapture' | | `-ConditionalOperator 0x7ff1131536b8 &...

...t pointer related > for (i =0; i< 2; i++) { <- not pointer related > printf("i is %d, aa is %d\n", i, aa); <- not pointer related > ptr[i]->index = 0; <- Here is where it gets wonky. > > <rest of codeis irrelevan> > > First, ptr[i] is an lvalue, of type struct heap *, and ptr[i]-> is an > lvalue of type struct heap (in C++03, this is 5.2.5 paragraph 3, check > footnote 59). > This is where we get the undefined behavior. 3.8/6: "[If you have a glvalue referring to storage but where there is no corresponding object, the]...

...t promote the p->x expression. Assuming above is C11 code, I think the relevant section in the C spec is the following: This is a paragraph from a C11 draft ("N1570 Committee Draft — April 12, 2011") . Assuming my interpretation of it is correct: It seems to imply that a store to an lvalue can change its subsequent effective type? This would preclude any purely based TBAA solution. And would, in general, require to take access/points-to information into account. --- 6.5 Expressions 6: "The effective type of an object for an access to its stored value is the declared type of th...

...expression. > > > Assuming above is C11 code, I think the relevant section in the C spec is the following: > > This is a paragraph from a C11 draft ("N1570 Committee Draft — April 12, 2011") . Assuming my interpretation of it is correct: It seems to imply that a store to an lvalue can change its subsequent effective type? This would preclude any purely based TBAA solution. And would, in general, require to take access/points-to information into account. > > --- > 6.5 Expressions > > 6: "The effective type of an object for an access to its stored value is...

...417/c-when-is-casting-between-pointer-types-not-undefined-behavior > > > > I don't think it's quite that simple.The type-based aliasing rules > > come from 6.5p7 of C11, I think. That says: > > > > "An object shall have its stored value accessed only by an lvalue > > expression that has one of > > the following types: > > + a type compatible with the effective type of the object, > > [...] > > + an aggregate or union type that includes one of the > > aforementioned > > types among its members [...]" &gt...

...; to other sections of the >> service file, when I do I don't get my error from postgresql I see this >> in /var/log/messages >> >> Aug 17 08:38:47 db1 systemd: Reloading. >> Aug 17 08:38:47 db1 systemd: >> [/usr/lib/systemd/system/dm-event.socket:10] Unknown lvalue >> 'RemoveOnStop' in section 'Socket' >> Aug 17 08:38:47 db1 systemd: >> [/usr/lib/systemd/system/lvm2-lvmetad.socket:9] Unknown lvalue >> 'RemoveOnStop' in section 'Socket' >> Aug 17 08:38:49 db1 systemd: Starting PostgreSQL 9.4 databas...

...lobalContext()), value, false); } void *visit(symbolic_variable_c *symbol) { std::string varName; AllocaInst *alloc; varName = get_var_name_c::get_name(symbol->var_name)->value; alloc = locals[varName]; return (void *)alloc; } void *visit(equ_expression_c *symbol) { Value *lValue; Value *rValue; lValue = (Value *)symbol->l_exp->accept(*this); rValue = (Value *)symbol->r_exp->accept(*this); return Builder.CreateICmpEQ (lValue, rValue, "cond"); } Cheers, Manuele

...he value of the variable, as opposed to its memory address, or the value that it points to. Within LLVM, where we don't have DW_OP_reg/DW_OP_breg but instead simply refer to a generic SSA value, this could mean either a register location or stack value. > At the moment we don't make the lvalue/rvalue distinction in LLVM at all. We make an educated guess in AsmPrinter. But that's wrong and something we should strive to fix during this redesigning. I think the opposite; I don't believe there's any reason we need to make the explicit lvalue/rvalue distinction until we're wr...

...I have tried moving the 'LimitSTACK=12288' to other sections of the service file, when I do I don't get my error from postgresql I see this in /var/log/messages Aug 17 08:38:47 db1 systemd: Reloading. Aug 17 08:38:47 db1 systemd: [/usr/lib/systemd/system/dm-event.socket:10] Unknown lvalue 'RemoveOnStop' in section 'Socket' Aug 17 08:38:47 db1 systemd: [/usr/lib/systemd/system/lvm2-lvmetad.socket:9] Unknown lvalue 'RemoveOnStop' in section 'Socket' Aug 17 08:38:49 db1 systemd: Starting PostgreSQL 9.4 database server... Aug 17 08:38:49 db1 kernel: po...

...>> >> Assuming above is C11 code, I think the relevant section in the C spec is the following: >> >> This is a paragraph from a C11 draft ("N1570 Committee Draft — April 12, 2011") . Assuming my interpretation of it is correct: It seems to imply that a store to an lvalue can change its subsequent effective type? This would preclude any purely based TBAA solution. And would, in general, require to take access/points-to information into account. >> >> --- >> 6.5 Expressions >> >> 6: "The effective type of an object for an access to...

...nction ''RS_DBI_allocOutput'': RS-DBI.c:426: warning: assignment makes pointer from integer without a cast RS-DBI.c: In function ''RS_DBI_copyfields'': RS-DBI.c:627: warning: implicit declaration of function ''CHR_EL'' RS-DBI.c:627: error: invalid lvalue in assignment RS-DBI.c:628: warning: passing argument 1 of ''INTEGER'' makes pointer from integer without a cast RS-DBI.c:629: warning: passing argument 1 of ''INTEGER'' makes pointer from integer without a cast RS-DBI.c:630: warning: passing argument 1 of '...

> The program I gave was well typed :) Hi, Daniel: Thank you for sharing your insight. I didn't realized it is well-typed -- I'm basically a big nut of any std. I'd admit std/spec is one of the most boring material on this planet:-). So, if I understand correct, your point is: if a std call a type-casting (could be one which is in bad-taste:-), TBAA has to

...std::string varName; > AllocaInst *alloc; > > varName = get_var_name_c::get_name(symbol->var_name)->value; > alloc = locals[varName]; > > return (void *)alloc; > } > > void *visit(equ_expression_c *symbol) { > Value *lValue; > Value *rValue; > > lValue = (Value *)symbol->l_exp->accept(*this); > rValue = (Value *)symbol->r_exp->accept(*this); > > return Builder.CreateICmpEQ (lValue, rValue, "cond"); > > } > > Ch...

Full_Name: Simon Anders Version: 2.6.2 OS: Ubuntu Linux Submission from: (NULL) (86.22.75.91) This is a rather minor "documentation bug", certainly not at all urgent. The manual "Writing R extensions" explains in section 5.10 ("Evaluating R expressions from C") how to use the eval function. Without going into much details, an example is given how to build up a

Daniel, Hal, I'm trying to figure out what we would need to do in terms of the current approach, accepting its limitations, to support unions, member arrays, aggregate accesses and type identifiers and what I get looks suspiciously simple. Can you please check it out and let me know if I'm missing something? For unions: TBAA, regardless of a specific approach, cannot guarantee

...39; | `-ObjCMessageExpr 0x112791ba0 <col:5, col:39> 'void' selector=addObject: | |-PseudoObjectExpr 0x112791b48 <col:6, col:11> 'NSMutableArray *' | | |-ObjCPropertyRefExpr 0x112791ad0 <col:6, col:11> '<pseudo-object type>' lvalue objcproperty Kind=PropertyRef Property="dataModels" Messaging=Getter | | | `-OpaqueValueExpr 0x112791ab0 <col:6> 'DFDataModelContainer *' | | | `-ImplicitCastExpr 0x112791a40 <col:6> 'DFDataModelContainer *' <LValueToRValue> |...