HiGautam,
I made a minor change to this patch to put the new code enclosed by #ifdef
OPEN64_SPIN and flag_spin_file to make the check only valid for emitting
spin file.
Index: osprey-gcc-4.2.0/gcc/tree.c
===================================================================
--- osprey-gcc-4.2.0/gcc/tree.c (revision 3731)
+++ osprey-gcc-4.2.0/gcc/tree.c (working copy)
@@ -10916,6 +10916,18 @@
/* bug 12598: Try to fold OBJ_TYPE_REF if it is present
under the CALL_EXPR. Code adapted from fold_stmt() . */
tree callee = get_callee_fndecl (t);
+#ifdef OPEN64_SPIN
+ if (flag_spin_file &&
+ callee && TREE_CODE(callee) == FUNCTION_DECL)
+ {
+ /* we need to emit the function be calleed, no matter
+ if the call is removed later by gcc cfg cleanup, so
+ the open64 backend wouldn't be surprised by missing
+ function definition. */
+ TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (callee)) = 1;
+ mark_decl_referenced(callee);
+ }
+#endif
if (!(callee && DECL_BUILT_IN(callee)))
{
callee = TREE_OPERAND(t,0);
Could you please take a look at the new patch? Thank you very much.
2011/9/18 Gautam Chakrabarti <gautam.c...@yahoo.com>
> I am a bit cautious with this change, but please go ahead assuming the
> testing turns out okay.
>
> Gautam
>
>
> *From:* Jian-Xin Lai <laij...@gmail.com>
> *To:* Gautam Chakrabarti <gautam.c...@yahoo.com>
> *Cc:* open64-devel <open64-devel@lists.sourceforge.net>
> *Sent:* Friday, September 16, 2011 12:27 AM
>
> *Subject:* Re: [Open64-devel] Code review for bug #827 [GCC FE]
>
> The flag is set when the asm code of caller is emitted. Here is the stack
> trace:
> #0 mark_referenced (id=0x55877288) at
> ../../../osprey-gcc-4.2.0/gcc/varasm.c:2067
> #1 0x085062eb in assemble_name (file=0x8855788, name=0x8856a31 "_Z1fv") at
> ../../../osprey-gcc-4.2.0/gcc/varasm.c:2155
> #2 0x082aa373 in output_addr_const (file=0x8855788, x=0x5586f840) at
> ../../../osprey-gcc-4.2.0/gcc/final.c:3213
> #3 0x0855451f in print_operand (file=0x8855788, x=0x5586f840, code=80) at
> ../../../osprey-gcc-4.2.0/gcc/config/i386/i386.c:8167
> #4 0x082aa298 in output_operand (x=0x5586f840, code=80) at
> ../../../osprey-gcc-4.2.0/gcc/final.c:3177
> #5 0x082a9ff5 in output_asm_insn (template=0x86fb45c "call\t%P0",
> operands=0x880fc60) at ../../../osprey-gcc-4.2.0/gcc/final.c:3087
> #6 0x082a925b in final_scan_insn (insn=0x55741084, file=0x8855788,
> optimize=0, nopeepholes=0, seen=0xffffcfcc) at ../../../osprey-gcc-4.2.0/\
> gcc/final.c:2472
> #7 0x082a8413 in final (first=0x557470a0, file=0x8855788, optimize=0) at
> ../../../osprey-gcc-4.2.0/gcc/final.c:1614
> #8 0x082ab17d in rest_of_handle_final () at
> ../../../osprey-gcc-4.2.0/gcc/final.c:3920
> #9 0x0851b8c5 in execute_one_pass (pass=0x8779200) at
> ../../../osprey-gcc-4.2.0/gcc/passes.c:900
> #10 0x0851ba06 in execute_pass_list (pass=0x8779200) at
> ../../../osprey-gcc-4.2.0/gcc/passes.c:951
> #11 0x0851ba22 in execute_pass_list (pass=0x8779f40) at
> ../../../osprey-gcc-4.2.0/gcc/passes.c:952
> #12 0x0851ba22 in execute_pass_list (pass=0x8779f00) at
> ../../../osprey-gcc-4.2.0/gcc/passes.c:952
> #13 0x0815a158 in tree_rest_of_compilation (fndecl=0x55873700) at
> ../../../osprey-gcc-4.2.0/gcc/tree-optimize.c:483
> #14 0x080e1468 in expand_body (fn=0x55873700) at
> ../../../osprey-gcc-4.2.0/gcc/cp/semantics.c:3100
> #15 0x0857ef86 in cgraph_expand_function (node=0x55740a20) at
> ../../../osprey-gcc-4.2.0/gcc/cgraphunit.c:1244
> #16 0x0857f0bb in cgraph_expand_all_functions () at
> ../../../osprey-gcc-4.2.0/gcc/cgraphunit.c:1309
> #17 0x0857f8ab in cgraph_optimize () at
> ../../../osprey-gcc-4.2.0/gcc/cgraphunit.c:1588
> #18 0x0809b40d in cp_finish_file () at
> ../../../osprey-gcc-4.2.0/gcc/cp/decl2.c:3410
> #19 0x08049e28 in finish_file () at
> ../../../osprey-gcc-4.2.0/gcc/cp/cp-lang.c:160
> #20 0x08139017 in c_common_parse_file (set_yydebug=0) at
> ../../../osprey-gcc-4.2.0/gcc/c-opts.c:1193
> #21 0x084dcfc3 in compile_file () at
> ../../../osprey-gcc-4.2.0/gcc/toplev.c:1077
> #22 0x084de743 in do_compile () at
> ../../../osprey-gcc-4.2.0/gcc/toplev.c:2094
> #23 0x084de7a8 in toplev_main (argc=11, argv=0xffffd334) at
> ../../../osprey-gcc-4.2.0/gcc/toplev.c:2126
> #24 0x08143fa5 in main (argc=11, argv=0xffffd334) at
> ../../../osprey-gcc-4.2.0/gcc/main.c:52
>
> mark_referenced() is only called when the compiler assemble the symbol name
> during the final asm emit phase. Since we skipped all the
> "tree_rest_of_compilation", the flag is not set in the modified front end.
>
> 2011/9/16 Gautam Chakrabarti <gautam.c...@yahoo.com>
>
> What phase is it? Is it really not run, or just that it is run after
> tree->gs translation? If the phase is run after the translation, then there
> are other instances of this scenario, and we use gs_set_flag_value() to
> update the flag of the already created gs node.
>
> The proposed change in itself is small, but I wanted to be cautious because
>
>
> 1. that particular place is just a (mostly faithful) translation phase from
> tree -> gs, so it would be good to not have to update the tree there.
> 2. And in the past the matter of setting what functions need to be
> defined/emitted has proved tricky because differences between our notion of
> needing to emit a function and g++'s notion can cause trouble.
>
> Gautam
>
>
> *From:* Jian-Xin Lai <laij...@gmail.com>
> *To:* Gautam Chakrabarti <gautam.c...@yahoo.com>
> *Cc:* open64-devel <open64-devel@lists.sourceforge.net>
> *Sent:* Thursday, September 15, 2011 1:15 AM
>
> *Subject:* Re: [Open64-devel] Code review for bug #827 [GCC FE]
>
> GCC checks this and set the flag in the later phase but we skip all those
> phase.
>
> 2011/9/15 Gautam Chakrabarti <gautam.c...@yahoo.com>
>
> Hi Jian-Xin,
>
> Where does normal g++ execution set this flag? I.e., why is it not getting
> set for us?
>
> Thanks,
> Gautam
>
>
> *From:* Jian-Xin Lai <laij...@gmail.com>
>
> *To:* open64-devel <open64-devel@lists.sourceforge.net>
> *Sent:* Tuesday, September 13, 2011 12:49 AM
> *Subject:* Re: [Open64-devel] Code review for bug #827 [GCC FE]
>
> Hi,
> Could a gate keeper review this patch? Thank you very much.
>
> 2011/9/7 Jian-Xin Lai <laij...@gmail.com>
>
> Hi,
>
> Could a gate keeper review the patch for #827? Thank you very much.
>
> The error message should be reported at toplev.c, line 884:
> 874 if (TREE_CODE (decl) == FUNCTION_DECL
> 875 && DECL_INITIAL (decl) == 0
> 876 && DECL_EXTERNAL (decl)
> 877 && ! DECL_ARTIFICIAL (decl)
> 878 && ! TREE_NO_WARNING (decl)
> 879 && ! TREE_PUBLIC (decl)
> 880 && (warn_unused_function
> 881 || TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl))))
> 882 {
> 883 if (TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl)))
> 884 pedwarn ("%q+F used but never defined", decl);
> 885 else
> 886 warning (0, "%q+F declared %<static%> but never defined",
> decl);
> 887 /* This symbol is effectively an "extern" declaration now.
> */
> 888 TREE_PUBLIC (decl) = 1;
> 889 assemble_external (decl);
> 890 }
>
>
> But because the TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl)) is not
> set for the callee in this case, the compiler doesn't report any error on
> this case. The patch is to set this flag when handle the CALL_EXPR:
>
> Index: /open64/open64-trunk/osprey-gcc-4.2.0/gcc/tree.c
> ===================================================================
> --- /open64/open64-trunk/osprey-gcc-4.2.0/gcc/tree.c (revision 3731)
> +++ /open64/open64-trunk/osprey-gcc-4.2.0/gcc/tree.c (working copy)
> @@ -10916,6 +10916,16 @@
> /* bug 12598: Try to fold OBJ_TYPE_REF if it is present
> under the CALL_EXPR. Code adapted from fold_stmt() . */
> tree callee = get_callee_fndecl (t);
> + if (callee && TREE_CODE(callee) == FUNCTION_DECL)
> + {
> + /* we need to emit the function be calleed, no matter
> + if the call is removed later by gcc cfg cleanup, so
> + the open64 backend wouldn't be surprised by missing
> + function definition. */
> + TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (callee)) =
> 1;
> + mark_decl_referenced(callee);
> + }
> +
> if (!(callee && DECL_BUILT_IN(callee)))
> {
> callee = TREE_OPERAND(t,0);
>
>
> --
> Regards,
> Lai Jian-Xin
>
>
>
>
> --
> Regards,
> Lai Jian-Xin
>
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> Learn about the latest advances in developing for the
> BlackBerry® mobile platform with sessions, labs & more.
> See new tools and technologies. Register for BlackBerry® DevCon today!
> http://p.sf.net/sfu/rim-devcon-copy1
> _______________________________________________
> 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
>
>
>
--
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-d2dcopy1
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
