Re: Reviving SH FDPIC target

[Rich Felker <dalias@libc.org>]

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