Hi Feng, where is the test case from? Why people create such weird code? Is it a legal one?
Handong On Thu, Jan 20, 2011 at 9:09 AM, Feng Zhou <fengzho...@gmail.com> wrote: > Hello, all > > Attached is my fix for bug > #585(https://bugs.open64.net/show_bug.cgi?id=585). There are three > test cases attached to the bug report. They all experience same > problem: compile time segmentation fault at wgen phase. However, each > of them is caused by a different problem. > > pr22061-2.c > =========== > The test case is shown below: > > int *x; > static void bar (char a[2][(*x)++]) {} > > The problem is that when generating type information for bar function, > (*x)++ needs to be expanded since `a` is a variable length array. > However, current wgen assumes that WHIRL node for current function > (`Current_Entry_Wn()`) already exists. However, this is not true at > the time of generating function type information. > > crash2.C > ======== > The part of code causing problems is shown below: > > R1::R1( const R& a ) : > m_( a.empty() ? get_empty().m_ : C() ) > > The gspin expression for the select is organized as follows: > > COND_EXPR > |-- COND > |-- TARGET_EXPR > |-- COMPONENT_REF (S1) > |-- INDIRECT_REF > |-- ... > |-- COMPONENT_REF (S2) > |-- TARGET_REF > |-- ... > |-- ... > > S1 is actually a VAR_DECL expression in gspin file. It is changed to > COMPONENT_REF when converting COND_EXPR (see wgen_expr.cxx:6056, added > for bug 15210). However, the presence of INDIRECT_REF causes target > symbol being NULL and this caused segmentation fault in WN_Lda > function. > > ftp.i > ===== > The following code snippet caused the problem: > > struct string { > unsigned char *source; > }; > struct ftp_file_info { > struct string name; > struct string symlink; > long size; > time_t mtime; > unsigned int local_time_zone:1; > mode_t permissions; > }; > static int ftp_process_dirlist() > { > int ret = 0; > while (1) { > struct ftp_file_info ftp_info = { FTP_FILE_UNKNOWN, {"", 0}, > {"", 0}, -1, 0, 0 }; > } > } > > The compiler tries to generate initialization code for each field of > `ftp_info`. For each field, `Advance_Field_Id` is called to advance to > next field after generating initialization code for current field. Due > to the presence of `struct string`, the field_id and fld is no long in > sync. For example, after generating initialization code for > ftp_info.symlink, the field_id is the for the last field of symlink > struct (ftp_info.symlink.source) while fld still points to > ftp_info.symlink field. This caused field_id being incremented > incorrectly and caused segmentation fault in `FLD_get_to_field` > function. > > > Thanks. > ------------------------------- > Feng Zhou > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Open64-devel mailing list > Open64-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/open64-devel > > -- Thanks. Handong ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
