looks good to me.
Please add a space after "//"
Personally, I prefer if you add comment instead of referring to bug number.
This is not representative of gatekeepers though
Sun
On Thu, Nov 24, 2011 at 10:21 PM, Gang Yu <yugang...@gmail.com> wrote:
> Hi,
>
> Could a gatekeeper please help review the fix for bug362
> http://bugs.open64.net/show_bug.cgi?id=362?
>
> This is an old linux kernel build bug, but it does still exist today.
> Source:
>
> static inline void cpuid_count(int op, int count, int *eax, int *ebx, int
> *ecx,
> int *edx)
> {
> __asm__("cpuid"
> : "=a" (*eax),
> "=b" (*ebx),
> "=c" (*ecx),
> "=d" (*edx)
> : "0" (op), "c" (count));
> }
> union _cpuid4_leaf_ebx {
> struct {
> unsigned int coherency_line_size:12;
> unsigned int physical_line_partition:10;
> unsigned int ways_of_associativity:10;
> } split;
> int full;
> };
>
> static int cpuid4_cache_lookup(int index)
> {
> union _cpuid4_leaf_ebx ebx;
> cpuid_count(4, 4, 0, &ebx.full, 0, 0);
> return ebx.split.physical_line_partition ;
> }
> void foo(){
> cpuid4_cache_lookup(1);
> }
> ### Assertion failure at line 638 of
> /fc/proj/ctires/open64/o64guru/src/Thu/trunk/osprey/be/opt/opt_verify.cxx:
> ### Compiler Error in file bug362.c during Global Optimization -- Verify
> CODEMAP phase:
> ### STMTREP::Verify_CODEMAP: inconsistent store operator with respect to
> bitfields
>
> Analyse:
> when control go the assertion, we get the assertion stmt:
> > LDID I4 I4 sym13v3 -3 ty=1026 <u=1 cr32> flags:0x10 b=-1
> >OPR_STID I4 I4 sym16v3 0 <u=1 cr37> b=-1 flags:0x2 pj2 Sid-1
>
> while its Lhs() can be printed as:
> >LDBITS I4 I4 sym16v3 0 ty=1026 <u=1 cr37> flags:0x100 b=-1
>
> sym16 is ebx in the source code, this is wrong, we can't STID a symbol
> with bit_field_valid propertie.
> sym16 has a bit_size 10, Lhs() is right, we can not change the OP for the
> stmt.
>
> Examine the source code, we find control follows the below path for sym16v3
>
> in opt_htable.cxx
> 4178 (opr == OPR_ISTORE &&
> 4179 (opt_stab->Aux_stab_entry(vaux)->Bit_size() == 0 ||
> 4180 opt_stab->Aux_stab_entry(vaux)->Field_id() ==
> WN_field_id(Wn())) ||
> 4181 opr == OPR_ISTBITS &&
> 4182 opt_stab->Aux_stab_entry(vaux)->Bit_ofst() ==
> WN_bit_offset(Wn()) &&
> 4183 opt_stab->Aux_stab_entry(vaux)->Bit_size() ==
> WN_bit_size(Wn()))) {
> 4184 VER_STAB_ENTRY *vse =
> opt_stab->Ver_stab_entry(cnode->Result());
> 4185 base_ccr.Tree()->DecUsecnt(); // for the LDA
> coderep
> 4186 Is_True(! vse->Real_use() ||
> 4187 vse->Coderep() == NULL && vse->Type() == CHI_STMT,
> 4188 ("Error in ISTORE to STID folding in htable"));
> 4189
> 4190 Set_lhs( htable->Add_def(vaux, vse->Version(), this,
> 4191 dtyp, dsctyp,
> 4192
> opt_stab->St_ofst(vaux)/*base_ccr.Scale()*/,
> 4193 TY_pointed(WN_ty(Wn())),
> 4194 WN_field_id(Wn()), TRUE) );
> 4218 Set_op(OPCODE_make_op(opr == OPR_ISTORE ? OPR_STID :
> OPR_STBITS, MTYPE_V, dsctyp));
> 4219 opt_stab->Push_coderep(vaux, Lhs());
> 4220 htable->Inc_istorefolds();
> 4179 (opt_stab->Aux_stab_entry(vaux)->Bit_size() == 0 ||
> 4180 opt_stab->Aux_stab_entry(vaux)->Field_id() == WN_field_id(Wn())
> || should be a typo.
>
> Suggested patch:
>
> --- a/osprey/be/opt/opt_htable.cxx
> +++ b/osprey/be/opt/opt_htable.cxx
> @@ -4176,7 +4176,7 @@ STMTREP::Enter_lhs(CODEMAP *htable, OPT_STAB
> *opt_stab, COPYPROP *copyprop)
> opt_stab->Aux_stab_entry(vaux)->Byte_size() * 8 ==
> MTYPE_size_min(_desc) &&
> (opr == OPR_ISTORE &&
> - (opt_stab->Aux_stab_entry(vaux)->Bit_size() == 0 ||
> + (opt_stab->Aux_stab_entry(vaux)->Bit_size() == 0 &&
> //bug362 open64.net
> opt_stab->Aux_stab_entry(vaux)->Field_id() ==
> WN_field_id(Wn())) ||
> opr == OPR_ISTBITS &&
> could a gatekeeper please help a review? Thanks
>
> Regards
> Gang
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
