Hi,
I updated the patch. In general, the GCC tree for struct initialization
contains two chains. One is for field information (name, type, size, etc)
and the other is for the initial value. For example:
struct A { int f1; int f2; };
struct B { struct A f3; int f4; };
struct B b = {1, 2, 3};
The GCC tree to initialize b looks like:
VAR_DECL (b)
CONSTRUCTOR
RECORD_TYPE for B
construct_elements_index
FIELD_DECL for f3
FIELD_DECL for f2
construct_elements_value
CONSTRUCTOR
RECORD_TYPE for A
construct_elements_index
FIELD_DECL for f1
FIELD_DECL for f2
construct_elements_value
INT_CONST 1
INT_CONST 2
INT_CONST 3
We only need to go through the construct_elements_index for type information
and construct_elements_value for initial value.
The new patch is attached and the new implementation of
Is_Aggregate_Init_Zero_Struct() is listed below:
INT length = gs_constructor_length(init_list);
for (INT idx = 0; idx < length; idx++) {
gs_t element_index = gs_constructor_elts_index(init_list, idx);
gs_t element_value = gs_constructor_elts_value(init_list, idx);
gs_t element_type = gs_tree_type(element_index);
INT element_size = gs_get_integer_value(gs_type_size(element_type)) /
BITSPERBYTE;
if (gs_tree_code(element_value) == GS_CONSTRUCTOR) {
// recursively process nested ARRAYs and STRUCTs
if (!Is_Aggregate_Init_Zero (element_value, element_type))
return FALSE;
}
else if (gs_type_ptrmemfunc_p(element_type)) {
return FALSE;
}
else if (gs_tree_code(element_value) == GS_REAL_CST) {
if (!Is_Real_Init_Zero (element_value, element_size))
return FALSE;
}
else if (gs_tree_code(element_value) == GS_INTEGER_CST) {
// SCALARs and POINTERs
if (gs_get_integer_value (element_value) != 0)
return FALSE;
}
else {
return FALSE;
}
}
return TRUE;
2011/3/26 Sun Chan <sun.c...@gmail.com>
> will your fix handle nested structs correctly?
> Sun
>
> On Fri, Mar 25, 2011 at 9:33 PM, Jian-Xin Lai <laij...@gmail.com> wrote:
> > Hi,
> >
> > Could a gate keeper review the patch for #746?
> > For the first case, the TY for c4 is:
> > [54]: c4 : (f: 0x1800 return_in_mem content_seen) size 4 M:
> > STRUCT
> > 0 arg .predef_I4 (#4) align 4
> > fl:0x0001 last_field
> > For the thrid case, the TY for c4 is:
> > [57]: c4 : (f: 0x1800 return_in_mem content_seen) size 4 M:
> > STRUCT
> > 0 .anonymous.4 c0 (#55) align 4
> > fl:0x0180
> > 0 .anonymous.5 c1 (#58) align 4
> > fl:0x0180
> > 0 m0 .predef_I4 (#4) align 4
> > fl:0x0001 last_field
> >
> > In GCC tree, there are a lot of empty base classes. When we trying to
> > traverse the GCC tree and advance the FLD in the TY, we don't ignore
> these
> > empty class correctly. The segmentation fault happens wwhen we go beyond
> the
> > last field of the TY. My patch is to remove all WHIRL FLD and only
> traverse
> > the GCC tree to find out if all fields are initialized by zero.
> >
> > Hi Suneel,
> > Is this patch going to be included in open64 4.2.4 release or not? Thank
> you
> > very much.
> >
> > --
> > Regards,
> > Lai Jian-Xin
> >
> >
> ------------------------------------------------------------------------------
> > Enable your software for Intel(R) Active Management Technology to meet
> the
> > growing manageability and security demands of your customers. Businesses
> > are taking advantage of Intel(R) vPro (TM) technology - will your
> software
> > be a part of the solution? Download the Intel(R) Manageability Checker
> > today! http://p.sf.net/sfu/intel-dev2devmar
> > _______________________________________________
> > Open64-devel mailing list
> > Open64-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/open64-devel
> >
> >
>
--
Regards,
Lai Jian-Xin
wgen_decl.746.diff
Description: Binary data
------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
