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
