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
