It looks fine to me. Please go ahead and commit it.
在 2010年8月30日 上午1:41，Chen, Rui (Roger, TSG-GDCC-SH) <rui.c...@hp.com>写道：
> Could front end gatekeeper or global gatekeeper help to review this
> changes? Thanks in advance.
>
> Regards,
> Roger
>
> -----Original Message-----
> From: Jian-Xin Lai [mailto:laij...@gmail.com]
> Sent: 2010年8月24日 11:57
> To: Chen, Rui (Roger, TSG-GDCC-SH)
> Cc: Mike Murphy; open64-devel@lists.sourceforge.net
> Subject: Re: [Open64-devel] duplicate_decls bug
>
> It looks fine to me. Please replace the tab with space in the first
> different location in decl.c (both FEs).
>
> 2010/8/23 Chen, Rui (Roger, TSG-GDCC-SH) <rui.c...@hp.com>:
> > 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
> >
>
>
>
> --
> Regards,
> Lai Jian-Xin
>
--
Regards,
Lai Jian-Xin
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
