I attached the new diff file. Changed the macro from "KEY" to "OPEN64_SPIN", and modified related makefiles. I changed old front end also.
Pls help to review. Regards, Roger -----Original Message----- From: Jian-Xin Lai [mailto:laij...@gmail.com] Sent: 2010年8月21日 4:34 To: Mike Murphy Cc: open64-devel@lists.sourceforge.net Subject: Re: [Open64-devel] duplicate_decls bug I'd prefer using 'OPEN64_SPIN' since 'OPEN64' might be a little confusion with the predefined macro '__OPEN64__'. In general, the patch looks good to me. Any other comments? 2010/8/17 Mike Murphy <mmur...@nvidia.com>: > I agree that we shouldn't use KEY anymore (it has an obscure history that is > no longer relevant). Better to use something like #ifdef OPEN64 in the gcc > files. > > -----Original Message----- > From: Suneel Jain [mailto:suneel.j...@gmail.com] > Sent: Tuesday, August 17, 2010 3:56 PM > To: Jian-Xin Lai > Cc: open64-devel@lists.sourceforge.net > Subject: Re: [Open64-devel] duplicate_decls bug > > I agree these changes should be under an ifdef so we can easily > identify > Open64 specific changes in the gcc directories. This makes it easier > to merge with future versions of gcc frontends. > > However, I think we should use a macro name that conveys this more > explicitly instead of using "#ifdef KEY". Do we have a convention for > names of such macros and where they should be defined ? > > Some possibilities for the macros name: > > OPEN64_SPIN > GCC_SPIN_GEN > > Comments ? > > - Suneel > > > > On Mon, Aug 16, 2010 at 3:43 PM, Jian-Xin Lai <laij...@gmail.com> wrote: >> I think these changes should be enclosed by some macro ( shall we use >> the #ifdef KEY? ). Also, these changes should be only applied under >> "if (flag_spin_file)". >> For example: >> >> if (flag_spin_file) { >> TREE_TO_TRANSLATED_GS(olddecl) = TREE_TO_TRANSLATED_GS(newdecl); >> FULLY_TRANSLATED_TO_GS(olddecl) = FULLY_TRANSLATED_TO_GS(newdecl); } >> >> 2010/8/15 Chen, Rui (Roger, TSG-GDCC-SH) <rui.c...@hp.com>: >>> Hi all, >>> >>> >>> >>> This is the fix for bug 582 (https://bugs.open64.net/show_bug.cgi?id=582). >>> Can gatekeeper help to review it? >>> >>> >>> >>> I attached the test case (min.i) and patch (582.patch). You can >>> reproduce the problem with "openCC -O0 -g -c min.i". >>> >>> >>> >>> This bug caused by merge user declared "log" function with built-in "log" >>> function. The front-end forgets to copy GSPIN related fields and >>> declaration assembler name. >>> >>> >>> >>> If you are interested in the analysis process, here it is: >>> >>> >>> >>> Breakpoints you need to setup: >>> >>> b name-lookup.c:615 if strcmp(name.identifier.id.str, "log") == 0 >>> >>> b passes.c:148 >>> >>> >>> >>> Compiler will initial built-in functions first, so those functions >>> declared in osprey-gcc-4.2.0/gcc/builtins.def will be translated to >>> gcc tree. And built-in "log" will be translated twice, one into >>> global namespace, one into std namespace. >>> >>> >>> >>> Then the second breakpoint is triggered. This method checks whether >>> the declared function has "alias" attribute or not. If the answer is >>> yes, it will translate gcc tree to open64 gspin tree: >>> >>> >>> >>> #ifdef KEY >>> >>> /* Put aliases into the list of decls emitted by g++ so that >>> we can >>> >>> * iterate through the list when expanding aliases to WHIRL. >>> An alias >>> >>> * can be expanded only if its target, which can be another >>> alias, is >>> >>> * expanded. Bug 4393. */ >>> >>> if (flag_spin_file) >>> >>> gspin_gxx_emits_decl(decl); >>> >>> #endif >>> >>> >>> >>> In this test case, it declares: >>> >>> >>> >>> extern __typeof(pthread_once) __gthrw_pthread_once >>> __attribute__ ((__weakref__("pthread_once"))); >>> >>> >>> >>> __weakref__ means "alias" attribute, so compiler start translation >>> at this time. At this time, only built-in log can be found by compiler. >>> >>> >>> >>> After that, compiler parsed user defined "log". It then find out we >>> have already defined a "log" in the global namespace. >>> (name-lookup.c, line 623) So it tries to merge the declarations. >>> (duplicate_decls function in decl.c) >>> >>> >>> >>> I patched this file, to let it also copy gspin related fields and >>> declaration assembler name. >>> >>> >>> >>> Then after compiler parsed the whole file, it will translate gcc >>> tree to gspin tree again. Without the patch, it just re-use the >>> built-in log gspin tree. With this patch, it will rebuild the log >>> gspin tree using the new log declaration. >>> >>> >>> >>> Regards, >>> >>> Roger >>> >>> -------------------------------------------------------------------- >>> ---------- >>> This SF.net email is sponsored by >>> >>> Make an app they can't live without >>> Enter the BlackBerry Developer Challenge >>> http://p.sf.net/sfu/RIM-dev2dev >>> _______________________________________________ >>> Open64-devel mailing list >>> Open64-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/open64-devel >>> >>> >> >> >> >> -- >> Regards, >> Lai Jian-Xin >> >> --------------------------------------------------------------------- >> --------- >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> Open64-devel mailing list >> Open64-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/open64-devel >> > > ---------------------------------------------------------------------- > -------- > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Open64-devel mailing list > Open64-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/open64-devel > ---------------------------------------------------------------------- > ------------- This email message is for the sole use of the intended > recipient(s) and may contain confidential information. Any > unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please contact the sender by > reply email and destroy all copies of the original message. > ---------------------------------------------------------------------- > ------------- > -- Regards, Lai Jian-Xin ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
new.diff
Description: new.diff
------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
