Hi Sun,
I investigate the bug a little bit, and the findings are:
0. Usually, -pic and -pie is linker option, while -fpic and -fpie is option
for BE (for opencc). And -pie and -pic have the same effect, and -fpie and
-fpic have the same effect, for open64 (or it would check if an executable
is being compiled? that is not sth interested in here.).
1. Ofast IPA would call BE with -TENV:PIC and -pic1 (which is effectively
-TENV:CPIC), if it is called with -TENV:PIC (or sth like -pie). While
without IPA, only when -fpie is specified, the BE would receive -TENV:PIC.
What is noticeable are:
a. -Ofast IPA would specify -pic1 for BE, if it receive -pic by itself.
b. IPA would specify -fpic.
2. While, the bug is about -TENV:PIC and -TENV:CPIC. If both the two options
are specified (i assume they are compatible to each other, is that right? ),
the compiler would simply failed, regardless -ipa be specified or not.
i.e.
opencc -pie -pic1 hello.c
hello.c
#include<stdio.h>
int main()
{
char * p;
p = malloc(10);
if (p != 0) return 0;
return 1;
}
The linker would complain that the call to malloc should go through PLT, as
the compiler is emitting the following.
.globl malloc
call malloc # [0] malloc
This issue should be sthing wrong about CG.
Best Regards,
yiran
On Fri, Feb 18, 2011 at 11:16 AM, Sun Chan <[email protected]> wrote:
> 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 <[email protected]> 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:[email protected]]
> > 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 <[email protected]> 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 <[email protected]> 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:[email protected]]
> >>> 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 <[email protected]> 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:[email protected]]
> >>>> 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 <[email protected]> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Open64-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/open64-devel
