ok. In this case, pls go ahead.
Sun
On Tue, Sep 27, 2011 at 3:51 PM, Jian-Xin Lai <laij...@gmail.com> wrote:
> No, this patch doesn't intend to cover such kind of case. It's only
> proposed to check some obvious problems about using undefined static
> functions in user's code.
>
> Also, I don't think it's possible to cover all cases about implicit using
> of undefined function, espcially at -O0 level.
>
>
> 2011/9/27 Sun Chan <sun.c...@gmail.com>
>
>> 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
>>>
>>>
>>
>
>
> --
> 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
