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
