[Open64-devel] r3819 - trunk/osprey/be/cg/x8664

Author: yug Date: 2011-11-20 02:59:33 -0500 (Sun, 20 Nov 2011) New Revision: 3819 Modified: trunk/osprey/be/cg/x8664/cgtarget.cxx Log: Fix bug597. Implement the constraint 'p' for x86_64 target. Code Review: Sun Chan. Modified: trunk/osprey/be/cg/x8664/cgtarget.cxx ==

[Open64-devel] r3820 - trunk/osprey/common/com

Author: yug Date: 2011-11-20 03:09:09 -0500 (Sun, 20 Nov 2011) New Revision: 3820 Modified: trunk/osprey/common/com/wn_simp_code.h Log: fix bug906, i.e, guarded type check before TY_pointed. Code Review: Lai Jian-Xin Modified: trunk/osprey/common/com/wn_simp_code.h ==

[Open64-devel] Review request for fix bug921 (opencc O1/O2 does not delete non-callable static functions) [driver, inline]

Hi, could a gatekeeper help a review? any suggestions or comments are highly appreciated. This is an accidentally discovered issue when I review bug597cases: cat bug921 .c void static test(void) { as

Re: [Open64-devel] Review request for fix bug921 (opencc O1/O2 does not delete non-callable static functions) [driver, inline]

it's not clear what you meant by 'non-callable". please educate me. your change probably match the gcc behavior, but it's not clear it will actually accomplish what you want as "DFE" behavior. I don't believe O0/1/2/3 does no dfe, only IPA does. May be you can show me which part of compiler will d

Re: [Open64-devel] Two issues were found when build Open64 trunck on Debian testing AMD64

Hi Jian-Xin, I also ran into the first issue. In the svn history for osprey/ipa/local/Makefile.gbase, I see that r1411 adds the following lines: +ifeq ($(BUILD_COMPILER), OSP) +ipl_summarize_util.o: OPTIMIZER += -CG:all_sched=0 +endif Then r1950 removes the check for the OSP compiler: -ifeq ($

Re: [Open64-devel] Review request for fix bug921 (opencc O1/O2 does not delete non-callable static functions) [driver, inline]

Sun, Thanks for the input. 'non-callable' should be right called 'non-called', means the function marked MARK_DELETED(deletable) by function Mark_Deletable_Funcs at ipa_cg.cxx. Informally, those functions unreachable by the call-graph can be marked 'DELETABLE' or 'non-called'. I think yo

Re: [Open64-devel] Review request for fix bug921 (opencc O1/O2 does not delete non-callable static functions) [driver, inline]

1. I don't agree with "this patch must be updated". I don't see a bug here. A compatibility (behavior-wise) with other compilers, may be 2. I'd like to see some example where you don't accidentally "dfe" some functions that cannot be deleted. IOWs, I don't believe you thought about this problem and

Re: [Open64-devel] Review request for fix bug921 (opencc O1/O2 does not delete non-callable static functions) [driver, inline]

Sun: If you don't think this behavior compatibility is essential, I am OK with that. We can save time to do more relevant things, but I am still interested in this topic. Any comments or inputs are welcome. Thanks Regards Gang On Mon, Nov 21, 2011 at 11:27 AM, Sun Chan wrote: > 1. I don

Re: [Open64-devel] Two issues were found when build Open64 trunck on Debian testing AMD64

I'll do some tests about this issue and submit a patch for it. 2011/11/21 David Coakley : > Hi Jian-Xin, > > I also ran into the first issue.  In the svn history for > osprey/ipa/local/Makefile.gbase, I see that r1411 adds the following > lines: > > +ifeq ($(BUILD_COMPILER), OSP) > +ipl_summarize_

Re: [Open64-devel] Review request for fix bug921 (opencc O1/O2 does not delete non-callable static functions) [driver, inline]

priority is one issue, my second point, is more important, imho Sun On Mon, Nov 21, 2011 at 11:38 AM, Gang Yu wrote: > Sun: > >If you don't think this behavior compatibility is essential, I am OK > with that. We can save time to do more relevant things, but I am still > interested in this t

Re: [Open64-devel] Review request for fix bug921 (opencc O1/O2 does not delete non-callable static functions) [driver, inline]

DFE and real inlining are really separate steps. I don't think we will unsafely delete the non-deletable functions. The final patch is not ready, and before it is ready, as serious engineering, we will do plenty of tests, we will even dump the symbol table and compared it with the gcc's, clang's r