Yes, when IPA is enabled WOPT is run later, so I wonder whether the file number is still maintained correctly at the time the diagnostic is emitted.
For an example, the original example can be used, but compile with -IPA: opencc 1.c -WOPT:warn_uninit=1 -IPA But when I do this with our compiler, I don't get any diagnostic at all. I haven't investigated why. Sun, it must have been an early design decision for the symbol table, to decide whether symbol table entries should have an attribute for source position. Do you remember any discussions in SGI about that? It's not important, I'm just curious to understand the rationale ... Regards, Steve. Sun Chan wrote: > I thought for IPA, the additional thing one needs to worry about is the > file number > Sun > > On Thu, Oct 13, 2011 at 7:23 PM, shenrfen <shenr...@gmail.com > <mailto:shenr...@gmail.com>> wrote: > > Thx for you good example, I am working for this. > But I do not familiar with IPA. > Could you please give me a small example? Thx very much. > > -----Original Message----- > From: Stephen Clarke [mailto:stephen.cla...@st.com > <mailto:stephen.cla...@st.com>] > Sent: Thursday, October 13, 2011 10:08 PM > To: shenrfen > Cc: 'Jian-Xin Lai'; open64-devel@lists.sourceforge.net > <mailto:open64-devel@lists.sourceforge.net> > Subject: Re: [Open64-devel] Please help to review the patch for [Bug > 879]: > Missing line number of uninitialized variable warning > > Here's another example that doesn't work quite right now, and could > be used > as motivation to use a full source coordinate, rather than just line > number: > > $ cat testa.c > int main () > { > #include "z.h" > return z; > } > $ cat z.h > int z; > $ opencc -O -Wuninitialized -c testa.c > testa.c: In function 'main': > testa.c:: warning: Variable z in main might be used uninitialized > > > Steve. > > shenrfen wrote: > > Hi, jianxin. > > > > Thx very much for your suggestion. > > > > > > > > (1) SRCPOS is defined to mUINT64. > > > > In fact, mUINT32 is big enough for line number even if 16bit > machine. > > > > And in gcc-front-end, decl_line is declared as INT. > > > > (2) IN STMT_NODE, linenum is defined as mUINT64, not a macro > > > > If use a macro to define line in ST, > > > > The print format will take a little bit more work > > > > > > > > *From:* Jian-Xin Lai [mailto:laij...@gmail.com > <mailto:laij...@gmail.com>] > > *Sent:* Wednesday, October 12, 2011 3:19 PM > > *To:* shenrfen > > *Cc:* open64-devel@lists.sourceforge.net > <mailto:open64-devel@lists.sourceforge.net> > > *Subject:* Re: [Open64-devel] Please help to review the patch for > [Bug > > 879]: Missing line number of uninitialized variable warning > > > > > > > > I mean replacing the type of the line with SRCPOS. > > > > 2011/10/12 shenrfen <shenr...@gmail.com > <mailto:shenr...@gmail.com> <mailto:shenr...@gmail.com > <mailto:shenr...@gmail.com>>> > > > > All chi_node are added to entry_bb. > > > > We cannot get the exactly line number from source code position. > > > > > > > > *From:* Jian-Xin Lai [mailto:laij...@gmail.com > <mailto:laij...@gmail.com> <mailto:laij...@gmail.com > <mailto:laij...@gmail.com>>] > > *Sent:* Wednesday, October 12, 2011 3:06 PM > > *To:* shenrfen > > *Cc:* open64-devel@lists.sourceforge.net > <mailto:open64-devel@lists.sourceforge.net> > > <mailto:open64-devel@lists.sourceforge.net > <mailto:open64-devel@lists.sourceforge.net>> > > *Subject:* Re: [Open64-devel] Please help to review the patch for > [Bug > > 879]: Missing line number of uninitialized variable warning > > > > > > > > I think using SRCPOS is better. > > > > 2011/10/11 shenrfen <shenr...@gmail.com > <mailto:shenr...@gmail.com> <mailto:shenr...@gmail.com > <mailto:shenr...@gmail.com>>> > > > > Hi, all. > > > > Could a gatekeeper help to review the patch for bug879. > > > > Please find the detail: > > https://bugs.open64.net/show_bug.cgi?id=879 > > > > I would like to add a member "line" to Class "ST". > > > > > > > > + mUINT32 line; // The line num where > > define the sym in the source file. > > > > With this field we can get the line info which define > symbol. > > > > Attached Please fine the whole patch. The patch has > passed SL's > > regression test. > > > > Thx very much. > > > > > > > > -----Original Message----- > > From: bugzilla-dae...@open64.net > <mailto:bugzilla-dae...@open64.net> > <mailto:bugzilla-dae...@open64.net <mailto:bugzilla-dae...@open64.net>> > > [mailto:bugzilla-dae...@open64.net > <mailto:bugzilla-dae...@open64.net> > <mailto:bugzilla-dae...@open64.net <mailto:bugzilla-dae...@open64.net>>] > > Sent: Tuesday, October 11, 2011 2:56 PM > > To: shenr...@gmail.com <mailto:shenr...@gmail.com> > <mailto:shenr...@gmail.com <mailto:shenr...@gmail.com>> > > Subject: [Bug 879] New: Missing line number of uninitialized variable > > warning > > > > > > > > https://bugs.open64.net/show_bug.cgi?id=879 > > > > > > > > Summary: Missing line number of uninitialized variable > warning > > > > Product: Open64 Compiler > > > > Version: 4.2.4 > > > > Platform: Itanium > > > > OS/Version: Linux > > > > Status: NEW > > > > Severity: normal > > > > Priority: P2 > > > > Component: WOPT > > > > AssignedTo: shenr...@gmail.com > <mailto:shenr...@gmail.com> <mailto:shenr...@gmail.com > <mailto:shenr...@gmail.com>> > > > > ReportedBy: shenr...@gmail.com > <mailto:shenr...@gmail.com> <mailto:shenr...@gmail.com > <mailto:shenr...@gmail.com>> > > > > > > > > > > > > Test case: 1.c > > > > int main() > > > > { > > > > int z; > > > > return z; > > > > } > > > > > > > > CMD: > > > > opencc 1.c -WOPT:warn_uninit=1 > > > > > > > > Building output: > > > > "1.c": Warning: Variable z in main might be used uninitialized > > > > > > > > Error: > > > > There is missing line number of variable, Which is difficult > to locate > > > > variable. > > > > > > > > -- > > > > Configure bugmail: https://bugs.open64.net/userprefs.cgi?tab=email > > > > ------- You are receiving this mail because: ------- > > > > You are the assignee for the bug. > > > > You reported the bug. > > > > > > > > ---------------------------------------------------------------------------- > -- > > 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. Business sense. IT sense. Common sense. > > http://p.sf.net/sfu/splunk-d2d-oct > > _______________________________________________ > > Open64-devel mailing list > > Open64-devel@lists.sourceforge.net > <mailto:Open64-devel@lists.sourceforge.net> > > <mailto:Open64-devel@lists.sourceforge.net > <mailto:Open64-devel@lists.sourceforge.net>> > > https://lists.sourceforge.net/lists/listinfo/open64-devel > > > > > > > > > > -- > > Regards, > > Lai Jian-Xin > > > > > > > > > > -- > > Regards, > > Lai Jian-Xin > > > > > > ------------------------------------------------------------------------------ > 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. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > Open64-devel mailing list > Open64-devel@lists.sourceforge.net > <mailto: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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
