can you check a case where the use of undef() is implicit? From your
change,it's not clear to me you covered this case
Sun
On Tue, Sep 27, 2011 at 3:00 PM, Jian-Xin Lai <laij...@gmail.com> wrote:
> Hi,
>
> Could a gate keeper review this patch? The bug broken the triple boot test
> for a while. Thank you very much.
>
>
> 2011/9/23 Jian-Xin Lai <laij...@gmail.com>
>
>> 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
>>
>
>
>
> --
> 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
>
>
------------------------------------------------------------------------------
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
