GCC Bugzilla Bug 11901

set_fpscr contains the line "mov.l LOCAL(set_fpscr_L1),r1"
which generates non-PIC code.  This causes the glibc-2.3.2
check-textrel regression test to fail, and probably gets
in the way of prelinking.  
A patch by Kaz to fix this is at 
http://www.kegel.com/crosstool/current/gcc-3.3-patches/sh-pic-set_fpscr.patch
It seems to fix the problem for me.
Please include this patch in gcc-3.3.2.

Since this is fixed on the mainline by kkojima at gcc dot gnu dot org assigning
to him.
I would just ask for inclusion of the patch:
2003-08-11  Kaz Kojima

        * config/sh/lib1funcs.asm (__udivdi3): Add .type and .size
        information in SHmedia case too.
        (__divdi3, __umoddi3, __moddi3, __init_trampoline, __ic_invalidate):
        Likewise.
        (__set_fpscr): Use an access via GOT for PIC case.

Subject: Re:  [3.3 only] set_fpscr isn't PIC even when __PIC__
 defined; bad for prelinking, causes glibc-3.2.3 check-textrel test to
 fail

> Since this is fixed on the mainline by kkojima at gcc dot gnu dot org assigning to him.
> I would just ask for inclusion of the patch:

I think that this is not a regression from 3.2 and the former and
not critical since the current __set_fpscr doesn't include any
illegal relocation but only a text relocation. It's indeed bad for
prelinking but the current SH port doesn't support prelinking.

I can't argue with Kaz, he knows his stuff.  However, 
anyone building glibc-2.3.2 and running its regression tests
should expect to fail.  I dunno, that sounds kind of critical,
if only because it gets in the way of regression testing.

Subject: Re:  [3.3 only] set_fpscr isn't PIC even when __PIC__
 defined; bad for prelinking, causes glibc-3.2.3 check-textrel test to
 fail

> I can't argue with Kaz, he knows his stuff.  However, 
> anyone building glibc-2.3.2 and running its regression tests
> should expect to fail.  I dunno, that sounds kind of critical,
> if only because it gets in the way of regression testing.

I believe that that glibc test is mainly for prelinking. Text
relocation is not so problem in usual sense. You are right if
the prelinking is supported by SH port already. But it's not
the case and we can live with that regression. So it would be
against the rule of changes for 3.3.2.

Closing as not going to be fixed for 3.3.x.