Yes, 258 is st_idx instead of pointer. It is the first symbol (258>>8) of level 2 (258 & 0xff).
I suspect the symbol whose st-idx is 258 is reset for some reasons. Say, the compiler may replace the symbol with a PREG symbol. Set_ST_has_nested_ref(st) will prevent compiler from doing such opt. Shuxin Mike Murphy wrote: > 258 is probably the st_idx, rather than ST*. The idx is what is stored in > the whirl. > > -----Original Message----- > From: shuxin yang [mailto:shuxinyang2...@gmail.com] > Sent: Monday, June 21, 2010 1:22 PM > To: eirc.lew > Cc: open64-devel@lists.sourceforge.net > Subject: Re: [Open64-devel] Best way to get at a symbol name in whirl / > symbol table memory scoping? > > It sounds very weird to me. > I think the symbol with st-idx=258 is corrupted for some reasons. > > Do you call Set_ST_has_nested_ref(st) for the symbol defined in the > nesting func and > ref in the nested func? If you don't, you certainly has problem in WOPT > (where uplevel reference is lowed) > and downstream phases. I don't know if lacking such flags will incur > problems in earlier phases. > It is likely possible. > > Anyway, you can set a breakpoint at New_ST to catch the moment symbol > 258 is created, > and made a hw watch to its content. Then gdb will tell you when the > symbol is corrupted. > > If you cannot make a break at this function, you probably need to turn > on -fno-inline when > building the compiler. > > osprey/common/com/symtab.h > 94 inline ST* > 95 New_ST (SYMTAB_IDX level) > 96 { > 97 UINT idx; > 98 ST& s = Scope_tab[level].st_tab->New_entry (idx); > 99 // Clear the random padding bits in ST. > 100 // Otherwise, these random paddings may make bcmp/memcmp > mis-compare. > 101 memset(&s, 0, sizeof(ST)); // bug 14141 > 102 Set_ST_st_idx (s, make_ST_IDX (idx, level)); > 103 return &s; > 104 } > > Shuxin > > > eirc.lew wrote: > >> Hi, >> Thank you for your reply. >> The symbol I created is right, and the reason it encounters errors, I >> think it is because I create a child pu named childpu and the childpu >> nested in the parent pu of ppu, When I do the same thing in the ppu, >> it seems all right. >> What I want to do is to create a new symbol sym in childpu which >> correspond to the symbol of orig_st in ppu, and I want to do is: >> sym = orig_st; >> But, when I want to LDID orig_st, it seems I can't do it this way. >> >> Actually, what I want to do is like the inline_micro_task in OpenMP of >> open64, for example: >> >> int mian() >> { >> int sum = 10; >> int add() >> { >> for(int i = 0; i < 10; i++) >> L1: sum += i; >> return sum; >> } >> return 0; >> } >> >> I want to realize the L1 line by reconstruct the whirl tree of >> the program. >> >> >> >> >> // in this function ,I can access orig_st and new_st by >> ST_name(orig_st); >> Gen_MP_Load_Store(v->orig_st, v->orig_offset, v->new_st, >> v->new_offset, v->is_dynamic_array) >> // in this function, ST_name(from_st) returns "i", the >> result is right. >> Gen_MP_Load ( from_st, from_offset ) >> L1: WN_RLdid (rtype=4, desc=4, offset=0, *sym=0x80920dc*, >> align=14850);// ST_name(sym) return the right result >> L2 WN_RLdid (rtype=4, desc=4, offset=0, *sym=258*, >> align=14850) // sym is st_idx, and ST_name(sym) return error; >> >> >> L3: WN_CreateLdid (opr=OPR_LDID, rtype=4, desc=4, >> offset=0,* st=258*, ty=14850, field_id=0) >> >> because the WN return from WN_CreatedLdid include the symbol >> of st, but when I do like below: >> p dump_tree(wn), it corrupts, >> but When do: p dump_tree_no_st(wn)， it returns the right >> result as below: >> I4I4LDID 0 <null-st> T<### ERROR: null ptr> >> >> But, I find sometime the same operation on L2, it is also >> right, but this it fails. >> >> What is the reason? >> >> >> >> > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Open64-devel mailing list > Open64-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/open64-devel > ----------------------------------------------------------------------------------- > This email message is for the sole use of the intended recipient(s) and may > contain > confidential information. Any unauthorized review, use, disclosure or > distribution > is prohibited. If you are not the intended recipient, please contact the > sender by > reply email and destroy all copies of the original message. > ----------------------------------------------------------------------------------- > > ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
