I don't know who did this code in config_targ.cxx. Whoever did that
has no clue what he's doing. I know exactly how to deal with
call_shared. I believe even gcc has a lot of people who know how to
take advantage of cpic now.
It could be the case that with call_shared turned off, bugs have been
introduced. I believe we should fix the introduced bugs instead of
turning off a good optimization.
Sun

On Fri, Feb 18, 2011 at 9:54 AM, Zhao, Min <min.z...@hp.com> wrote:
>
>
> Maybe a better fix is to remove config_targ.cxx
>   822   if (Gen_PIC_Call_Shared)
>   823     Gen_PIC_Call_Shared = FALSE;
>
> But the comment (// TMP: ignore cpic until we figure out what to do with it) 
> makes us not comfortable to keep Gen_PIC_Call_Shared to be TRUE.
>
> Thanks,
>
> Min
>
>
> -----Original Message-----
> From: Sun Chan [mailto:sun.c...@gmail.com]
> Sent: Thursday, February 17, 2011 5:40 PM
> To: Zhao, Min
> Cc: Shin, Jaewook
> Subject: Re: [Open64-devel] Code Review Request (bug #721)
>
> Note that CPIC is a subset of PIC. Apparently there are 2 variables
> governing them. So, turn off PIC if CPIC is set is fine.
> Sun
>
> On Fri, Feb 18, 2011 at 9:38 AM, Sun Chan <sun.c...@gmail.com> wrote:
>> this is the original proposed fix:
>> At first, the effect of -TNEV:PIC option is nullified by -TENV:CPIC in
>> common/com/config.cxx:1457 (if (Gen_PIC_Call_Shared && Gen_PIC_Shared)
>> Gen_PIC_Shared = FALSE). Then, the effect of -TENV:CPIC is reset by
>> common//com/x8664/config_targ.cxx:822:
>>
>> // TMP: ignore cpic until we figure out what to do with it
>>  if (Gen_PIC_Call_Shared)
>>    Gen_PIC_Call_Shared = FALSE;
>>
>> which I think is incorrect.
>>
>> Can we start with what is the suggested fix now?
>>
>> Sun
>>
>> On Fri, Feb 18, 2011 at 9:28 AM, Zhao, Min <min.z...@hp.com> wrote:
>>>
>>> Exactly. That's why we say the option is wrong.
>>>
>>> In config.cxx
>>> #1457 if (Gen_PIC_Call_Shared && Gen_PIC_Shared) Gen_PIC_Shared = FALSE;
>>>
>>> In config_targ.cxx
>>> #822   if (Gen_PIC_Call_Shared)
>>> #823     Gen_PIC_Call_Shared = FALSE;
>>>
>>> In -ipa, we are NOT doing any -pic handling.
>>>
>>> Thanks,
>>>
>>> Min
>>>
>>> -----Original Message-----
>>> From: Sun Chan [mailto:sun.c...@gmail.com]
>>> Sent: Thursday, February 17, 2011 5:08 PM
>>> To: Zhao, Min
>>> Cc: Shin, Jaewook
>>> Subject: Re: [Open64-devel] Code Review Request (bug #721)
>>>
>>> this make no sense. This implies the code becomes a static object,
>>> which is not correct. Neither of this flag should be tinkered with.
>>> One can change PIC to PIC_Call_Shared by ipa
>>> Sun
>>>
>>> On Fri, Feb 18, 2011 at 8:51 AM, Zhao, Min <min.z...@hp.com> wrote:
>>>>
>>>> NO. From the code, it seems that both Gen_PIC_Call_Shared and 
>>>> Gen_PIC_Shared are explicitly set to FALSE with -ipa. That's why I said we 
>>>> are not doing any -IPC handling in -ipa.
>>>>
>>>> Thanks,
>>>>
>>>> Min
>>>>
>>>> -----Original Message-----
>>>> From: Sun Chan [mailto:sun.c...@gmail.com]
>>>> Sent: Thursday, February 17, 2011 4:23 PM
>>>> To: Zhao, Min
>>>> Cc: Shin, Jaewook
>>>> Subject: Re: [Open64-devel] Code Review Request (bug #721)
>>>>
>>>> depends on the default. I think compiler defaults to -PIC, with IPA,
>>>> it can know that it is really CPIC, not .so, would you agree? So, IPA
>>>> could make up these flags to down stream and linker (at least this is
>>>> how it works back at SGI)
>>>> Sun
>>>>
>>>> On Fri, Feb 18, 2011 at 8:17 AM, Zhao, Min <min.z...@hp.com> wrote:
>>>>> Sun,
>>>>>
>>>>> Just a quick point: with -ipa, we do *NOT* have any -PIC handling at all 
>>>>> (since Gen_PIC_Call_Shared and Gen_PIC_Shared are false).
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Min
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel

Reply via email to