Add plain udivsi3 (not _i4*) for gcc-4.1 and lower.

As shown in arch/sh/lib/udivsi3.S (and -Os.S),

.global __udivsi3_i4i
.global __udivsi3_i4
.global __udivsi3
__udivsi3_i4i:
...

Three symbols are sharing one code, which is actually udivsi3_i4i. But, this results unwanted code with gcc 4.1.

In gcc, these three are treated as pseudo instructions that have own
clobber list apart from usual calling convention.
According to sh's machine description. The clobber list is like below.
- udivsi3_i4i : t,r1,pr,mach,macl
- udivsi3_i4 : t,r0,r1,r4,r5,pr,dr0,dr2,dr4
- udivsi3 : t,r4,pr
I don't think udivsi3_i4 is used in kernel, though.
Caller of udivsi3 will be trouble with broken r1 and mac*.

gcc-4.1.x and older(at least to 3.4) generate udivsi3. # ST's gcc-4.1.1 seems to be OK because it has _i4i.

I checked git:lethal/master for ap325rxa.
the one compiled by gcc 4.1.2 was NG (No output to console), while gcc 4.2.4 was OK
I have added plain udivsi3 as a patch below.
After that, both gcc 4.1.2 and 4.2.4 are OK

The patch is big because I renamed udivsi3*.S to udivsi3_i4i*.S. Another idea is giving new name to old udivsi3, like
udivsi3_gcc41x_and_lower.S

Any comment?
/yoshii

We chan't share code for udivsi3 and udivsi3_i4, because they have different clobber list. Copied udivsi3 from gcc-4.1.2.

---
 arch/sh/lib/Makefile         |    7 +-
 arch/sh/lib/udivsi3-Os.S     |  151 ----------
 arch/sh/lib/udivsi3.S        |  667 +++---------------------------------------
 arch/sh/lib/udivsi3_i4i-Os.S |  149 ++++++++++
 arch/sh/lib/udivsi3_i4i.S    |  666 +++++++++++++++++++++++++++++++++++++++++
 5 files changed, 862 insertions(+), 778 deletions(-)
 delete mode 100644 arch/sh/lib/udivsi3-Os.S
 create mode 100644 arch/sh/lib/udivsi3_i4i-Os.S
 create mode 100644 arch/sh/lib/udivsi3_i4i.S

index a30acb8..aaea580 100644
@@ -10,12 +10,13 @@ lib-y += movmem.o ashldi3.o ashrdi3.o lshrdi3.o \
 	 ashlsi3.o ashrsi3.o ashiftrt.o lshrsi3.o \
 	 udiv_qrnnd.o
 
-udivsi3-y			:= udivsi3-Os.o
+udivsi3-y			:= udivsi3_i4i-Os.o
 
 ifneq ($(CONFIG_CC_OPTIMIZE_FOR_SIZE),y)
-udivsi3-$(CONFIG_CPU_SH3)	:= udivsi3.o
-udivsi3-$(CONFIG_CPU_SH4)	:= udivsi3.o
+udivsi3-$(CONFIG_CPU_SH3)	:= udivsi3_i4i.o
+udivsi3-$(CONFIG_CPU_SH4)	:= udivsi3_i4i.o
 endif
+udivsi3-y			+= udivsi3.o
 
 obj-y				+= io.o
 

-- 1.5.6.4

Thanks Yoshii-san

(snip)

(snip)

This patch works well on my environment.
Thank you.

Best regards
--
Kuninori Morimoto

Please use -C option.

Best regards,
Nobuhiro

Wow! Amazing! .... but, result was not super good.

What I got was a record doing
mv udivsi3-Os.S udivsi3_i4i-Os.S; edit udivsi3_i4i-Os.S cp udivsi3.S udivsi3_i4i.S; edit udivsi3_i4i.S edit udivsi3.S
while I did
mv udivsi3-Os.S udivsi3_i4i-Os.S; edit udivsi3_i4i-Os.S mv udivsi3.S udivsi3_i4i.S; edit udivsi3_i4i.S create udivsi3.S
.

I known I can record them correctly in two commits, mvmv and create. I wonder if I should send two patch or no...
Or, is there a way to do in one shot?

Cheers,
/yoshii

It is a bit difficult to see what precisely you changed given that the changes are lost in the rename. If you do a rename first and then a follow-up patch with your actual changes, then it is easier to see what actually happened. Given that these are just from gcc directly though, the changes aren't likely to be terribly interesting, so simply fixing things up in a single change seems reasonable.