On Thu, Sep 03, 2015 at 11:53:45AM -0400, Rich Felker wrote: > On Thu, Sep 03, 2015 at 02:58:39PM +0000, Joseph Myers wrote: > > On Wed, 2 Sep 2015, Rich Felker wrote: > > > > > So if __fpscr_values was the only reason for patch 1/3 in the FDPIC > > > patchset, I think we can safely drop it. And patch 2/3 was already > > > committed, so 3/3, the one I was originally looking at, seems to be > > > all we need. It was approved at the time, so I'll proceed with merging > > > it with 5.2.0. > > > > Well, obviously if trying dropping patch 1/3 you need to remove everything > > related to use_initial_val (the feature added in patch 1/3) from patch > > 3/3. > > As far as I can tell, the only "use" of use_initial_val is defining > the pseudo-instruction in the md file, which causes the code in patch > 1/3 to use it. I see no other references to it. As I understand, the > breakage from not having it (in the original 4.5-era patch) would be > when introducing references to __fpscr_values later, and no longer > having the GOT pointer, but that code is gone now.
I have this basically working -- obviously no heavy testing yet, and the specs glue is not sufficient to make it practical for others to try it yet, so it'll be a little longer til I have something to post. One thing I've noticed that's odd is that gcc -mfdpic -fPIC produces different (less efficient) code from just gcc -mfdpic, which seems wrong, but agrees with sh.c which has a number of checks for flag_pic not matched with a TARGET_FDPIC check. I'm thinking all of these should either be flag_pic||TARGET_PIC or flag_pic&&!TARGET_FDPIC, depending on whether the code applies to all PIC or is specific to the non-FDPIC PIC model where r12 is call-saved. Does this sound correct? I think we need spurious -fPIC to work (although it could be handled with spec magic) and not pessimize code, since most library builds will use -fPIC. Rich
