On Wed, Sep 02, 2015 at 05:05:35PM -0400, Rich Felker wrote: > On Wed, Sep 02, 2015 at 07:59:45PM +0000, Joseph Myers wrote: > > On Wed, 2 Sep 2015, Rich Felker wrote: > > > > > Also, according to Joseph Myers, there was some unresolved > > > disagreement that stalled (and eventually sunk) the old patch, so if > > > anyone's still around who has objections to it, could you speak up and > > > let me know what's wrong? Kaz Kojima seems to have approved the patch > > > at the time so I'm confused what the issue was/is. > > > > It's patch 1/3 (architecture-independent) that had the disagreement (and > > patch 3/3 depends on patch 1/3). > > > > https://gcc.gnu.org/ml/gcc-patches/2010-08/msg01462.html > > So this is only for __fpscr_values? In that case I think the right > solution is just to follow up with getting rid of __fpscr_values, if > it's not already done: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60138 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513 > > 53513 is marked fixed, but I didn't follow up to confirm that the > actual problems I reported in 60138 are fixed; I'll do some more > research on this. But if all goes well, we can just drop 1/3.
I've confirmed that gcc 5.2 does not produce references to __fpscr_values; instead, it does: mov.l .L4,r3 ... sts fpscr,r1 xor r3,r1 lds r1,fpscr ... .L4: .long 524288 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. Rich