Hi Gautam,
The previoud patch checked in at rev 3739 for bug #827 caused an regression
bug #876:
https://bugs.open64.net/show_bug.cgi?id=876
Here is a case:
extern void undef();
static void foo() {
undef(); // <-- A
}
static void bar() {
int n;
switch(n) {
foo(); // <-- B
}
}
int global() {
bar();
}
The callsite B is dead code and eliminated by the GCC FE at O2. With the
patch to bug 827, function foo is still marked as referenced. Then function
foo() is emitted to the BE and generate the call to "undef". There will be
an error in the final linking phase: undefined reference to `undef()'. In
the previous patch, when we generate the CALL node to a function, both the
name and decl of the function are marked as referenced. That causes this
regression. Since the logic to detect if a static function is used but not
defined only check the name of the symbol, I made a new patch to only mark
the name of the function referenced:
Index: ../osprey-gcc-4.2.0/gcc/tree.c
===================================================================
--- ../osprey-gcc-4.2.0/gcc/tree.c (revision 3739)
+++ ../osprey-gcc-4.2.0/gcc/tree.c (working copy)
@@ -10924,7 +10924,6 @@
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)))
{
Could you please review this patch? Thank you very much.
--
Regards,
Lai Jian-Xin
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
