Looks good to me
Sun
On Wed, Nov 30, 2011 at 8:10 PM, Gang Yu <yugang...@gmail.com> wrote:
> Hi,
>
> Could a gatekeepler please help review the patch for fix bug908
> https://bugs.open64.net/show_bug.cgi?id=908?
>
> A cutdown bugcase:
>
> typedef unsigned int __u32;
> typedef unsigned long long __u64;
> typedef unsigned char __u8;
> struct in_core_key {
> __u32 k_dir_id; /* packing locality: by default parent
> directory object id */
> __u32 k_objectid; /* object identifier */
> __u64 k_offset;
> __u8 k_type;
> };
> typedef unsigned long sector_t;
> typedef __u32 b_blocknr_t;
> struct tree_balance {
> struct in_core_key key;
> };
> struct __reiserfs_blocknr_hint {
> void* inode;
> void *path;
> struct in_core_key key;
> sector_t block;
> void *th;
> b_blocknr_t beg, end;
> b_blocknr_t search_start;
> int prealloc_size;
> unsigned formatted_node:1;
> unsigned preallocate:1;
> };
> typedef struct __reiserfs_blocknr_hint reiserfs_blocknr_hint_t;
> extern void foo(reiserfs_blocknr_hint_t* t);
> struct tree_balance *p;
> void reiserfs_new_form_blocknrs(void)
> {
> reiserfs_blocknr_hint_t hint = {
> .key = p->key,
> .formatted_node = 1
> };
> foo(&hint);
> }
>
> compiler assert:
>
> opencc -S bug908-2.c
> ### Assertion failure at line 5197 of
> /fc/proj/ctires/open64/o64guru/src/Wed/trunk/osprey/be/com/wn_lower.cxx:
> ### Compiler Error in file bug908-2.c during Global Optimization --
> Mainopt Lowering phase:
> ### non-bit-field associated with bit-field access for OPR_STID
> opencc INTERNAL ERROR:
> /fc/proj/ctires/open64/o64guru/OPEN64_X86_DBG/LATEST/bits//lib/gcc-lib/x86_64-open64-linux/5.0/be
> returned non-zero status 1
> Analysis:
>
> When we dump the wgen generated .B file , we get:
> ...
> U4INTCONST 1 (0x1)
> BSSTID 0 <2,1,hint> T<53,__reiserfs_blocknr_hint,8> <field_id:10> {line:
> 1/37}
> U4INTCONST 0 (0x0)
> BSSTID 0 <2,1,hint> T<53,__reiserfs_blocknr_hint,8> <field_id:11> {line:
> 1/37}
> ...
>
> this is already wrong, formatted_node and preallocate should be field_id
> 13 and 14, so we can make sure wgen does something unexpected.
>
> examine the source code, we find when wgen iterates the fields of a STRUCT
> structure in function AGGINIT::Traverse_Aggregate_Struct , it increase the
> field_id by one when field comes to the next, so when a STRUCT field is
> initialized, the field_id is not rightly increased as to correspond current
> field.
>
> Suggested patch:
>
> index 8b37860..37c0ba7 100644
> --- a/osprey/wgen/wgen_decl.cxx
> +++ b/osprey/wgen/wgen_decl.cxx
> @@ -3443,6 +3443,16 @@ AGGINIT::Traverse_Aggregate_Struct (
> #endif
> is_bit_field, field_id, fld,
> emitted_bytes);
> // emitted_bytes updated by the call as reference parameter
> +
> + // bug908 open64.net. update field_id for the case of field is
> struct type.
> + if (TY_kind(fld_ty) == KIND_STRUCT) {
> + FLD_HANDLE field;
> + field = TY_fld(fld_ty); // get first field
> + while (!field.Is_Null()) {
> + field_id=Advance_Field_Id(field,field_id);
> + field=FLD_next(field);
> + }
> + }
> }
> }
> could a gatekeeper 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
