Re: Bootstrap broken on mipsel-linux...
David Daney <[EMAIL PROTECTED]> wrote:
> From svn r119726 (Sun, 10 Dec 2006) I am getting an ICE during
> bootstrap on mipsel-linux. This is a new failure since Wed Dec 6
> 06:34:07 UTC 2006 (revision 119575) which bootstrapped and tested just
> fine. I don't really want to do a regression hunt as bootstraps take 3
> or 4 days for me. I will update and try it again.
While I've looked at a wrong code problem on sh-elf, I've
noticed that it happens also on mips-elf. It might affect
mipsel-linux.
Now gcc.c-torture/execute/20010422-1.c is compiled like as
foo:
.frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0
.mask 0x,0
.fmask 0x,0
.setnoreorder
.setnomacro
sltu$2,$2,5
beq $2,$0,$L2
nop
...
which looks wrong. The binary search shows that before
r119711 | amacleod | 2006-12-11 06:25:40 +0900 (Mon, 11 Dec 2006) | 103 lines
the assembler output is
foo:
.frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0
.mask 0x,0
.fmask 0x,0
.setnoreorder
.setnomacro
sltu$4,$4,5
beq $4,$0,$L2
nop
...
It seems that the first tree dump which differs before and
after r119711 is .099t.optimized.
[r119710 .099t.optimized]
;; Function foo (foo)
Analyzing Edge Insertions.
foo (x)
{
unsigned int x.24;
:
if (x <= 4) goto ; else goto ;
:;
x.24 = 4;
goto ();
:;
x.24 = 8;
:;
return x.24;
}
[r119711 .099t.optimized]
;; Function foo (foo)
Analyzing Edge Insertions.
foo (x)
{
unsigned int x.24;
:
if (x.24 <= 4) goto ; else goto ;
:;
x = 4;
goto ();
:;
x = 8;
:;
return x;
}
Regards,
kaz
Re: Bootstrap broken on mipsel-linux...
"Steven Bosscher" <[EMAIL PROTECTED]> wrote: > In that case, this is a different problem, probably caused by the new > out-of-SSA pass. But to be sure, I suggest you revert my CSE patch > and see if that makes the problem go away for you. I've confirmed that that problem is remained after reverting r119706 changes of cse.c. So it may be another problem, though it might produce a wrong stage 1 compiler for mipsel-linux and end up with the ICE in stage 2. Regards, kaz
Re: Bootstrap broken on mipsel-linux...
"Steven Bosscher" <[EMAIL PROTECTED]> wrote: > In the mipsel-linux case, we ended up with a diamond region where the > jump in the IF-block was folded, so that we could extend the path > along one of the diamond's arms with the JOIN-block. This could > happen because cse_main traversed the basic blocks in DFS order > instead of in topological order. I have just posted a hopeful fix for > this. Thanks for the explanation. I'd like to file the problem in http://gcc.gnu.org/ml/gcc/2006-12/msg00284.html as an independent PR. Regards, kaz
Re: GCC 4.0.1 RC3
Mark Mitchell <[EMAIL PROTECTED]> wrote: > GCC 4.0.1 RC3 is now available here: > >ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050702/ > > With luck, this will be the last 4.0.1 release candidate. > > Please do download tarballs from the above URL and confirm that they > work OK on your systems. sh4-unknown-linux-gnu is ok: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00354.html Regards, kaz
Re: sh64 support deteriorating
Joern RENNECKE <[EMAIL PROTECTED]> wrote:
> I can't justify spending the amount time that it would take to make the
> sh64 port regression free.
> The lack of a debugger that works reliably with recent gcc versions has
> led to an increasing
> backlog of uninvestigated execution failures.
Although I know nothing about the execution failures, I've seen
some compile time errors in c/c++ test for sh64-unknown-linux-elf
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00466.html
3 tests
gcc.c-torture/compile/simd-4.c
gcc.c-torture/execute/20050604-1.c
gcc.dg/torture/pr21817-1.c
fail with the similar ICE:
gcc/gcc/testsuite/gcc.c-torture/compile/simd-4.c: In function 'tempf':
gcc/gcc/testsuite/gcc.c-torture/compile/simd-4.c:15: error: unable to find a
register to spill in class 'GENERAL_REGS'
gcc/gcc/testsuite/gcc.c-torture/compile/simd-4.c:15: error: this is the insn:
(insn 53 52 54 0 (set (subreg:DI (reg:V4SF 68 fr4 [196]) 0)
(and:DI (subreg:DI (reg:V4SF 68 fr4 [196]) 0)
(const_int -4294967296 [0x]))) 85 {anddi3} (nil)
(nil))
It seems odd that the DImode subregs of V4SFmode registers are used
as the operands of logical operations, though I don't understand why
reload complains as above.
Regards,
kaz
Re: GCC 4.0.2 RC1 Available
> It's important to test the actual tarballs, rather than CVS, to check > for any packaging issues. If you can, download and build the tarballs, > post test results to the gcc-testresults mailing list with and > contrib/test_summary. sh4-unknown-linux-gnu is ok: http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00742.html Regards, kaz
Re: GCC 4.0.2 RC2
> Please test, post test results to gcc-testresults, and send me an email > pointing at the results. OK for sh4-unknown-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00902.html Regards, kaz
Re: Expanding sh maintainership for Kaz Kojima
Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > In accordance with the two maintainers of the sh port (Alexandre > Oliva and Joern Rennecke) the steering committee is happy to extend > Kaz Kojima's maintainership from the current sh-linux-gnu to also > include "sh: libraries, configure.gcc, Makefiles". > > Congratulations, Kaz! Would you mind updating your entry in the > MAINTAINERS file? Thanks a lot! BTW, where is the appropriate place to add it in the MAINTAINERS file? Is it enough to modify the currnet line like this?: @@ -96,7 +96,7 @@ freebsdLoren J. Rittle [EMAIL PROTECTED] netbsd Jason Thorpe[EMAIL PROTECTED] sco5, unixware, sco udkKean Johnston [EMAIL PROTECTED] -sh-linux-gnu Kaz Kojima [EMAIL PROTECTED] +sh-linux-gnu, sh libs Kaz Kojima [EMAIL PROTECTED] RTEMS PortsJoel Sherrill [EMAIL PROTECTED] RTEMS PortsRalf Corsepius [EMAIL PROTECTED] VxWorks ports Nathan Sidwell [EMAIL PROTECTED] Or should I add a new entry to the "Various Maintainers" part? Regards, kaz
Re: Expanding sh maintainership for Kaz Kojima
Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > The current line is under "OS Ports"; have you considered adding a > new, third line for sh to the "CPU Port Maintainers" section? Like this? @@ -76,6 +76,7 @@ s390 port Ulrich Weigand [EMAIL PROTECTED] sh portJoern Rennecke [EMAIL PROTECTED] sh portAlexandre Oliva [EMAIL PROTECTED] +sh libraries Kaz Kojima [EMAIL PROTECTED] sparc port Richard Henderson [EMAIL PROTECTED] sparc port David S. Miller davem@redhat.com sparc port Jakub Jelinek [EMAIL PROTECTED] Regards, kaz
Re: Expanding sh maintainership for Kaz Kojima
Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > Yes -- and you can also include configure.gcc and Makefiles. ;-) Ah. There is no room to include all, though. :-) How about sh libraries/configury Kaz Kojima [EMAIL PROTECTED] ? Regards, kaz
Re: Expanding sh maintainership for Kaz Kojima
Gerald Pfeifer <[EMAIL PROTECTED]> wrote: >> sh libraries/configury Kaz Kojima [EMAIL PROTECTED] >> >> ? > > Looks fine. Thanks! I'll send a patch to the list and check it in. Regards, kaz
peep2_next_insn returns PEEP2_EOB
Hi, I've got an ICE during glibc build with the current mainline on sh4-unknown-linux-gnu: ../sysdeps/ieee754/flt-32/k_rem_pio2f.c: In function '__kernel_rem_pio2f': ../sysdeps/ieee754/flt-32/k_rem_pio2f.c:213: internal compiler error: Segmentation fault It doesn't fail with 20051003 compiler. The segfault occurs in insn-recog.c at the code like ... tem = peep2_next_insn (2); x1 = PATTERN (tem); ... where peep2_next_insn (2) returns (pc) which is the PEEP2_EOB marker. It looks quite similar to that in PR target/23832. It seems that the above two lines of code are generated by chage_state of genrecog.c, though I know almost nothing about these materials. Is it assumed that peep2_next_insn never return PEEP2_EOB in change_state? If so, what target bug is most likely? Regards, kaz
Re: peep2_next_insn returns PEEP2_EOB
Richard Henderson <[EMAIL PROTECTED]> wrote: > Yes. We check peep2_current_count to validate this. I'd like to take a look at why peep2_current_count doesn't work as expected for the problematic case. Thanks for the suggestion. Regards, kaz
SH: PR target/24445
Hi,
I've tried to see what is gonig on for PR target/24445 which is
a 4.1 regression of SH.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24445
Comparing rtl dumps for the reduced testcase in the audit trail #4
of that PR with and without Jan's patch in #10, there is no return
value copy in the rtl generated with the patched compiler in the first
place.
[.expand after the patch]
(set (reg/f:SI 160) (const:SI (unspec [(symbol_ref:SI ("baz"))] 7)))
(set (reg:SI 161) (plus:SI (reg:SI 12 r12) (reg/f:SI 160)))
(set (reg/f:SI 159) (mem/u/c:SI (reg:SI 161)))
(set (reg:SI 0 r0) (call (mem:SI (symbol_ref:SI ("bar")
(set (mem/c/i:SI (reg/f:SI 159)) (reg:SI 0 r0)))
[.expand before the patch]
(set (reg/f:SI 160) (const:SI (unspec [(symbol_ref:SI ("baz"))] 7)))
(set (reg:SI 161) (plus:SI (reg:SI 12 r12) (reg/f:SI 160)))
(set (reg/f:SI 159) (mem/u/c:SI (reg:SI 161)))
(set (reg:SI 0 r0) (call (mem:SI (symbol_ref:SI ("bar")
(set (reg:SI 164) (reg:SI 0 r0))
(set (mem/c/i:SI (reg/f:SI 159)) (reg:SI 164))
The 2nd and 3rd insns are combined to
(set (reg/f:SI 159) (mem/u/c:SI (plus:SI (reg:SI 12 r12) (reg/f:SI 160
at the combine pass.
An optimization in local-alloc moves the PLT address calculation after
the function call:
[.lreg after the patch]
(set (reg:SI 0 r0) (call (mem:SI (symbol_ref:SI ("bar")
(set (reg/f:SI 160) (const:SI (unspec [(symbol_ref:SI ("baz"))] 7)))
(set (reg/f:SI 159) (mem/u/c:SI (plus:SI (reg:SI 12 r12) (reg/f:SI 160
(set (mem/c/i:SI (reg/f:SI 159)) (reg:SI 0 r0)))
[.lreg before the patch]
(set (reg:SI 0 r0) (call (mem:SI (symbol_ref:SI ("bar")
(set (reg:SI 164) (reg:SI 0 r0))
(set (reg/f:SI 160) (const:SI (unspec [(symbol_ref:SI ("baz"))] 7)))
(set (reg/f:SI 159) (mem/u/c:SI (plus:SI (reg:SI 12 r12) (reg/f:SI 160
(set (mem/c/i:SI (reg/f:SI 159)) (reg:SI 164))
Then the reload pass complains that r0 can't be allocated to pseudo
160 in the former case because r0 is the unique index register of SH.
I don't understand which part is problematic, though. How this PR
should be fixed?
Regards,
kaz
Re: SH: PR target/24445
Joern RENNECKE <[EMAIL PROTECTED]> wrote:
>>[.expand after the patch]
>>(set (reg/f:SI 160) (const:SI (unspec [(symbol_ref:SI ("baz"))] 7)))
>>(set (reg:SI 161) (plus:SI (reg:SI 12 r12) (reg/f:SI 160)))
>>(set (reg/f:SI 159) (mem/u/c:SI (reg:SI 161)))
>>(set (reg:SI 0 r0) (call (mem:SI (symbol_ref:SI ("bar")
>>(set (mem/c/i:SI (reg/f:SI 159)) (reg:SI 0 r0)))
>>
>>
> The last insn is invalid. Before reload, a return value in a
> CLASS_LIKELY_SPILLED
> hard reg cannot be used in arbitrary instructions, but has to be copied
> to a plain register
> first.
Thanks for pointing it out. Now I'm testing the patch below.
How does it look like?
Regards,
kaz
--
--- ORIG/trunk/gcc/calls.c 2005-10-29 06:52:11.0 +0900
+++ LOCAL/trunk/gcc/calls.c 2005-11-03 09:15:47.0 +0900
@@ -2774,6 +2774,17 @@ expand_call (tree exp, rtx target, int i
emit_insn (insns);
valreg = temp;
}
+ /* We have to copy a return value in a CLASS_LIKELY_SPILLED hard
+reg to a plain register, even for pure functions. */
+ else if (pass && (flags & ECF_PURE)
+ && REGNO (valreg) < FIRST_PSEUDO_REGISTER
+ && CLASS_LIKELY_SPILLED_P (REGNO_REG_CLASS (REGNO (valreg
+ {
+ rtx temp = gen_reg_rtx (GET_MODE (valreg));
+
+ emit_move_insn (temp, valreg);
+ valreg = temp;
+ }
/* For calls to `setjmp', etc., inform flow.c it should complain
if nonvolatile values are live. For functions that cannot return,
Re: SH: PR target/24445
Ian Lance Taylor wrote:
> I don't see what this has to do with pure functions.
>
> It seems to me that instead you want to put something here:
>
> else if (target
> && GET_MODE (target) == TYPE_MODE (TREE_TYPE (exp))
> && GET_MODE (target) == GET_MODE (valreg))
> {
> /* TARGET and VALREG cannot be equal at this point because the
>latter would not have REG_FUNCTION_VALUE_P true, while the
>former would if it were referring to the same register.
>
>If they refer to the same register, this move will be a no-op,
>except when function inlining is being done. */
> emit_move_insn (target, valreg);
>
> i.e.
>
> if (REG_P (valreg)
> && HARD_REGISTER_P (valreg)
> && CLASS_LIKELY_SPILLED_P (REGNO_REG_CLASS (REGNO (valreg
> valreg = copy_to_reg (valreg);
> emit_move_insn (target, valreg);
Like this?
@@ -2861,6 +2861,12 @@ expand_call (tree exp, rtx target, int i
If they refer to the same register, this move will be a no-op,
except when function inlining is being done. */
+ /* We have to copy a return value in a CLASS_LIKELY_SPILLED hard
+reg to a plain register. */
+ if (REG_P (valreg)
+ && HARD_REGISTER_P (valreg)
+ && CLASS_LIKELY_SPILLED_P (REGNO_REG_CLASS (REGNO (valreg
+ valreg = copy_to_reg (valreg);
emit_move_insn (target, valreg);
/* If we are setting a MEM, this code must be executed. Since it is
Regards,
kaz
Re: SH: PR target/24445
Ian Lance Taylor wrote: > In general, yes. But looking at it we should probably only call > copy_to_reg if TARGET is not itself a pseudo-register. > > And I think I would put the new code before the "TARGET and VALREG > cannot be equal" comment. > > That patch is OK if it works and passes testing, and if you add a test > case and a ChangeLog entry. I'll come up to gcc-patches with the patch which incorporates your suggestions and a testcase after the tests. Thanks for suggestions. Regards, kaz
Re: SH -ml not turning into -EL to ld
Joel Sherrill wrote:
> We have a few build failures on the RTEMS target where it appears
> that the -ml argument to make a relocatable is not turned into a
> -EL argument to ld by gcc 4.8.2.
>
> This is the output of invoking gcc with "-v". Below that I invoked
> the same LD command with -EL on the command line and it
> worked.
>
> Any ideas or suggestions?
[snip]
> /users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/4.8.2/collect2
-dc -dp -N -o cache.rel -r
Usually some linker emulation option like -m shlelf is used here
to specify endian. Looks that bsp_specs overrides the default
linker options and doesn't give linker emulation option.
Could you check *link with -dumpspecs and see if something like
-m
%(link_emul_prefix)%{m5-compact*|m5-32media*:32}%{m5-64media*:64}%{!m1:%{!m2:%{!m3*:%{!m4*:%{!m5*:%(link_default_cpu_emul)}%(subtarget_link_emul_suffix)
is there?
Regards,
kaz
Move myself to Write After Approval section
Hi all, I am stepping down as the SH backend maintainer for personal reasons. I might still send tiny SH patches and sh-linux testresults if the HDD of my SH machine can be recovered. I've moved myself to write after approval section. I didn't think that I could be involved with such huge and highly sophisticated software when I sent my first awful patch. It was full of fun to participate in this great community. I've learned what is the right thing and how it can be done on the list. Thanks to all members of gcc community! Best Regards, kaz -- 2017-05-09 Kaz Kojima * MAINTAINERS: Move myself to Write After Approval section. Index: MAINTAINERS === --- MAINTAINERS (revision 247819) +++ MAINTAINERS (working copy) @@ -101,7 +101,6 @@ s390 port Andreas Krebbel score port Chen Liqin sh portAlexandre Oliva -sh port Kaz Kojima sh portOleg Endo sparc port Richard Henderson sparc port David S. Miller @@ -449,6 +448,7 @@ Jeff Knaggs Michael Koch Nicolas Koenig +Kaz Kojima Dave Korn Matt Kraai Jan Kratochvil
a new write after approval maintainer
Hi, I'll sponsor Oleg Endo as a new write after approval maintainer. He has written several good patches for SH targets and has filed good PRs. He is working on the issues which will require larger patches and being write after approval looks to be helpful. His paper work with FSF has done. OK? Regards, kaz
Re: a new write after approval maintainer
Gerald Pfeifer wrote: > Sure. Since you are a maintainer of this port/these ports, just > ask Oleg to submit the new account form at > http://sourceware.org/cgi-bin/pdw/ps_form.cgi > and name you as a sponsor. (If Oleg already has an account on > gcc.gnu.org/sourceware.org, ask overse...@gcc.gnu.org to add him > to the gcc group.) Thanks! Oleg, please go ahead. Regards, kaz
A question about df_get_live_in
Hi,
I hope DF/middle-end experts will comment about this.
PR target/40710
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40710
is a wrong code problem on SH. A delayed slot of a conditional
branch insn is wrongly filled with an insn changing stack pointer
in the failing case. I've tried to see what is going on.
Before the dbr optimization, the code looks like as
(note 6 1 5 [bb 2] NOTE_INSN_BASIC_BLOCK)
...
(jump_insn 13 12 31 fs/ext3/balloc.c:57 (set (pc)
(if_then_else (eq (reg:SI 147 t)
(const_int 0 [0x0]))
(label_ref:SI 129)
(pc))) 208 {branch_false} (expr_list:REG_DEAD (reg:SI 147 t)
(expr_list:REG_BR_PROB (const_int 184 [0xb8])
(nil
(note 31 13 46 [bb 3] NOTE_INSN_BASIC_BLOCK)
(note 46 31 32 NOTE_INSN_DELETED)
(insn 32 46 35 fs/ext3/balloc.c:66 (parallel [
(asm_operands/v ("") ("") 0 []
[] 2935777)
(clobber (mem:BLK (scratch) [0 A8]))
]) -1 (nil))
...
...
(barrier 126 125 129)
(code_label 129 126 14 9 "" [1 uses])
(note 14 129 109 [bb 8] NOTE_INSN_BASIC_BLOCK)
(insn 109 14 15 fs/ext3/balloc.c:58 (set (reg/f:SI 1 r1 [176])
(mem/u/c:SI (label_ref 146) [0 S4 A32])) 172 {movsi_ie}
(expr_list:REG_EQUIV (symbol_ref:SI ("ext3_error") [flags 0x41] )
(nil)))
(insn 15 109 24 fs/ext3/balloc.c:58 (set (reg/f:SI 15 r15)
(plus:SI (reg/f:SI 15 r15)
(const_int -4 [0xfffc]))) 35 {*addsi3_compact} (nil))
reorg.c:fill_slots_from_thread fills that delay slot of insn 13
with insn 15 from bb 8. Since r15 is the stack pointer register
for SH, this fill makes it wrong when the conditional jmp isn't
taken. fill_slots_from_thread computes the resource set for
the follow-through block of that jmp insn with
mark_target_live_regs (get_insns (), opposite_thread, &opposite_needed);
and mark_target_live_regs uses df_get_live_in to get live regs
for the basic block including the opposite_thread insn which is
insn 32. gdb shows the resulting opposite_needed is
$1 = {memory = 0x1, unch_memory = 0x0, volatil = 0x0, cc = 0x0,
regs = {0xf6, 0x0, 0x0, 0x0, 0x4}}
i.e. it seems that df_get_live_in doesn't count r15 as an live
register and fill_slots_from_thread picks insn 15 up as
an eligible insn to fill that delayed slot.
Is this the expected behavior of df_get_live_in? If so, is
there something problematic in the target?
I thought that the stack pointer register should be live here.
The first part of DF dump in .compgotos which is the last dump
before dbr pass is:
;; Start of basic block ( 0) -> 2
;; bb 2 artificial_defs: { }
;; bb 2 artificial_uses: { u-1(15){ }}
;; lr in4 [r4] 5 [r5] 6 [r6] 15 [r15] 146 [pr] 151 []
;; lr use 4 [r4] 5 [r5] 15 [r15] 146 [pr]
;; lr def 1 [r1] 2 [r2] 3 [r3] 15 [r15] 147 [t]
;; live in 4 [r4] 5 [r5] 6 [r6] 146 [pr]
;; live gen 1 [r1] 2 [r2] 3 [r3] 15 [r15] 147 [t]
;; live kill
...
;; End of basic block 2 -> ( 8 3)
;; lr out 1 [r1] 2 [r2] 3 [r3] 4 [r4] 5 [r5] 6 [r6] 15 [r15] 151 []
;; live out 1 [r1] 2 [r2] 3 [r3] 4 [r4] 5 [r5] 6 [r6] 15 [r15]
...
;; Start of basic block ( 2) -> 3
;; bb 3 artificial_defs: { }
;; bb 3 artificial_uses: { u-1(15){ }}
;; lr in1 [r1] 2 [r2] 4 [r4] 5 [r5] 6 [r6] 15 [r15] 151 []
;; lr use 1 [r1] 2 [r2] 5 [r5] 15 [r15]
;; lr def 0 [r0] 1 [r1] 2 [r2] 3 [r3] 7 [r7] 147 [t]
;; live in 1 [r1] 2 [r2] 4 [r4] 5 [r5] 6 [r6] 15 [r15]
;; live gen 0 [r0] 1 [r1] 2 [r2] 3 [r3] 7 [r7] 147 [t]
;; live kill
...
;; End of basic block 3 -> ( 9 4)
;; lr out 1 [r1] 2 [r2] 4 [r4] 5 [r5] 6 [r6] 7 [r7] 15 [r15] 151 []
;; live out 1 [r1] 2 [r2] 4 [r4] 5 [r5] 6 [r6] 7 [r7] 15 [r15]
Regards,
kaz
Re: A question about df_get_live_in
[I'd like to add kenny to the CC list.] Steven Bosscher wrote: > So when the CFG is still valid, r15 is live-out in basic block 2 and > live-in in basic block 3 (which contains insns 32, whatever that means > for an invalid CFG). For which bb does mark_target_live_regs call > df_get_live_in? gdb says 920 b = find_basic_block (target, MAX_DELAY_SLOT_LIVE_SEARCH); returns 2. Regards, kaz
Re: A question about df_get_live_in
Steven Bosscher wrote:
> OK, so isn't the bug obvious then? You said: "mark_target_live_regs
> uses df_get_live_in to get live regs for the basic block including the
> opposite_thread insn which is insn 32.". And you had insn 32 in basic
> block 3. So find_basic_block returns the wrong basic block.
>
> reorg.c:find_basic_block uses BLOCK_FOR_INSN, which is not valid after
> freeing the CFG. The bug you see occurs now because your backport of
> the other DF/reorg fixes (your patch for PR40105) also introduces a
> call to free_bb_for_insn which clears BLOCK_FOR_INSN. And since
> find_basic_block skips over NOTE_INSN_BASIC_BLOCK notes (it uses
> {prev,next}_nonnote_insn) and basic block 3 doesn't start with a
> label, find_basic_block never sees the start of basic block 3.
Ugh.
> I am not even sure why it finds basic block 2. Is there a label in
> basic block 2 that you were not showing in the original post?
There are no labels in basic block2. gdb says it hits the start
of the function and returns with
150 else if (insn == 0)
151 return ENTRY_BLOCK_PTR->next_bb->index;
> Why does find_basic_block ignore NOTE_INSN_BASIC_BLOCK notes?
The same question arises to me.
Regards,
kaz
Re: A question about df_get_live_in
Eric Botcazou wrote: > Patch attached. I'll give it a whirl on SPARC but not immediately so, Kaz, > if > you can test it on SH in the meantime, you can apply it on all branches. > > > 2009-07-14 Eric Botcazou > > PR rtl-optimization/40710 > * resource.c (mark_target_live_regs): Reset DF problem to LR. Thanks for taking a look at this! I've just fired the tests with it on sh4-unknown-linux-gnu. Regards, kaz
Re: [LTO] Request for testing: Last merge from trunk before final merge
Diego Novillo wrote: > In preparation for the final merge into mainline. I need to test > the branch on various platforms. Richi is currently testing on > i586, ppc, ppc64, ia64, s390, s390x. > > If anyone has free cycles I would appreciate results from other > ELF-capable targets. > > $ svn co svn://gcc.gnu.org/svn/gcc/branches/lto > $ mkdir bld && cd bld > $ ../lto/configure --enable-lto && make > > You will need to have libelf 0.8.12 installed > (http://www.mr511.de/software/libelf-0.8.12.tar.gz) The result for x86 cross sh4-unknown-linux-gnu looks similar to those reported for other targets. The cross compiler was configured with ../TMP/lto/configure --host=i686-pc-linux-gnu --target=sh4-unknown-linux-gnu --enable-lto --enable-shared --enable-threads=posix --enable-clocale=gnu --enable-libgcj --with-ld=/usr/local/bin/sh4-unknown-linux-gnu-ld --with-as=/usr/local/bin/sh4-unknown-linux-gnu-as --with-sysroot=/exp/ldroot --with-mpfr=/opt2/i686-pc-linux-gnu --with-gmp=/opt2/i686-pc-linux-gnu --with-mpc=/opt2/i686-pc-linux-gnu --enable-languages=c,c++,fortran,java,objc The host is Fedora 11 and the version of cross ld is 2.20.51.20090913. The result of compare_tests against the head http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02758.html is here. New tests that FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O0 -fwhopr g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o link, (internal compiler error) g++.dg/lto/20090106 cp_lto_20090106_0.o-cp_lto_20090106_0.o link g++.dg/lto/20090106 cp_lto_20090106_0.o-cp_lto_20090106_0.o link terminate called after throwing an instance of 'int' g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link, (internal compiler error) g++.dg/lto/20090311-1 cp_lto_20090311-1_0.o-cp_lto_20090311-1_1.o link, (internal compiler error) lto1: internal compiler error: Segmentation fault gcc.dg/lto/20081112 c_lto_20081112_0.o-c_lto_20081112_1.o link, (internal compiler error) gcc.dg/lto/20081118 c_lto_20081118_0.o-c_lto_20081118_2.o link, (internal compiler error) gcc.dg/lto/20090218 c_lto_20090218_0.o-c_lto_20090218_3.o link, (internal compiler error) gcc.dg/lto/20090218-2 c_lto_20090218-2_0.o-c_lto_20090218-2_1.o link, (internal compiler error) lto1: internal compiler error: Segmentation fault gcc.dg/torture/builtin-math-7.c -O2 -flto (internal compiler error) gcc.dg/torture/builtin-math-7.c -O2 -flto (test for excess errors) gcc.dg/torture/builtin-math-7.c -O2 -fwhopr (internal compiler error) gcc.dg/torture/builtin-math-7.c -O2 -fwhopr (test for excess errors) /exp/ldroot/dodes/TMP/lto/gcc/testsuite/gcc.dg/torture/builtin-math-7.c:59:5: internal compiler error: Segmentation fault gfortran.dg/lto/pr40724 f_lto_pr40724_0.o-f_lto_pr40724_1.o link, (internal compiler error) gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o execute -O2 -flto gfortran.dg/lto/pr40725 f_lto_pr40725_0.o-f_lto_pr40725_1.o execute -O2 -fwhopr lto1: internal compiler error: Segmentation fault Regards, kaz
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
"Kaveh R. GHAZI" wrote: > Please test this MPC package and report back the results of running > "make check" along with your target triplet, the compiler version you > used, and the versions of gmp/mpfr used to compile it. You do not > necessarily need to bootstrap mainline GCC with this MPC, but if you > have the spare time and cycles it would be nice too. === All 57 tests passed === sh4-unknown-linux-gnu gcc 4.2.4 gmp 4.2.2 mpfr 2.3.2 Regards, kaz
Re: MPC version 0.8 released!
"Kaveh R. GHAZI" wrote: > Please test this version and report back in this thread (not to me > privately) the results of "make check". Also include your target triplet, > and the versions of your compiler, gmp and mpfr. === All 57 tests passed === sh4-unknown-linux-gnu gcc 4.2.4 gmp 4.2.2 mpfr 2.3.2 Regards, kaz
Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax
Paolo Bonzini wrote: > I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000 > (which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which > do not define it at all) it is right that shift counts are never > truncated. sh defines SHIFT_COUNT_TRUNCATED according to target and there are comments for it: /* Immediate shift counts are truncated by the output routines (or was it the assembler?). Shift counts in a register are truncated by SH. Note that the native compiler puts too large (> 32) immediate shift counts into a register and shifts by the register, letting the SH decide what to do instead of doing that itself. */ /* ??? The library routines in lib1funcs.asm truncate the shift count. However, the SH3 has hardware shifts that do not truncate exactly as gcc expects - the sign bit is significant - so it appears that we need to leave this zero for correct SH3 code. */ #define SHIFT_COUNT_TRUNCATED (! TARGET_SH3 && ! TARGET_SH2A) Is this enough information for you? Regards, kaz
Re: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax
Paolo Bonzini wrote:
> So you have that in the RTL stream we should canonicalize "a << 32" to
> "a", but "a << (b & 31)" is not the same as "a << b"?
Yes when the msb of b is set.
> Also, how is the sign bit is significant? Does it determine whether the
> value is left- or right-shifted?
Yep. SH3 uses SHLD (SHift Logical Dynamically) insn which
is modeled like as:
SHLD (Rm, Rn)
{
int sign = Rm & 0x8000;
if (sign == 0)
Rn <<= (Rm & 0x1f);
else if ((Rm & 0x1f) == 0)
Rn = 0;
else
Rn = (unsigned)Rn >> ((~Rm & 0x1f)+1);
}
> Finally, is SH2A the same as SH3?
Although SH2A has a new arithmetic shift instruction, it's
same as SH3 in this regard, I think.
Regards,
kaz
Re: How to test SH64 on a simulator
Steven Bosscher wrote: > Is there a simulator for SH64 available? If so, how do I run the > testsuite with it? I built a cross-compiler from AMD64 to > sh64-unknown-elf and tried to test on sh-sim (with "make -k check > RUNTESTFLAGS=--target_board=sh-sim") but that doesn't work. Help? sh64-unknown-elf-run will be there if sim was configured for sh64-unknown-elf. For testing, there is one missing file sh64-sim.exp which should be added to dejagnu/baseboards directory: http://lists.gnu.org/archive/html/dejagnu/2008-02/msg00056.html RUNTESTFLAGS=--target_board=sh64-sim will work with it. Hope this helps. Regards, kaz
Re: How to test SH64 on a simulator
Steven Bosscher wrote: >> sh64-unknown-elf-run will be there if sim was configured >> for sh64-unknown-elf. > > Do I have to configure this explicitly? > > I just followed the instructions of > http://gcc.gnu.org/simtest-howto.html. If something special must be > done for sh64, perhaps you could add an explanation there? I did the same thing and nothing special, though I'm not using the combined tree for a while. My combined tree was configured with /home/kkojima/kaz/xsh64-elf-combined/combined/configure --target=sh64-unknown-elf --disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --disable-shared --with-newlib --disable-nls --prefix=/home/kkojima/kaz/xsh64-elf-combined/install --with-headers=yes --disable-gdbtk and I've got sim/sh64/run which is installed as sh64-unknown-elf-run. Do you have sim/sh64/run in your build directory? Regards, kaz
Re: [RFC] Thoughts on reordering the source tree
Steven Bosscher wrote: [snip] > config/sh/sh.c:#include "c-pragma.h" FYI, I've confirmed that there are no problems without this line for sh4-unknown-linux-gnu. Regards, kaz
Re: [RFC] Thoughts on reordering the source tree
Steven Bosscher wrote: > Kaz, can you commit a patch for sh.c? I've just applied the patch below. Regards, kaz -- 2009-05-08 Kaz Kojima * config/sh/sh.c: Do not include c-pragma.h. --- ORIG/trunk/gcc/config/sh/sh.c 2009-05-06 07:11:59.0 +0900 +++ trunk/gcc/config/sh/sh.c2009-05-08 12:25:36.0 +0900 @@ -37,7 +37,6 @@ along with GCC; see the file COPYING3. #include "insn-attr.h" #include "toplev.h" #include "recog.h" -#include "c-pragma.h" #include "integrate.h" #include "dwarf2.h" #include "tm_p.h"
Re: SH optimized software floating point routines
"Naveen H. S" wrote: > Software floating point(libgcc) routines were implemented for SH in the > following links:- > http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00063.html > http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00614.html > http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00624.html > > There were some discussions regarding the testing of these routines. > We had briefly tested those routines and found that they did not have > any major issues. > http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00791.html > Please let me know whether these routines can be used in SH toolchain. SH currently uses fp-bit.c implementation of soft fp which is known as a rather inefficient one. PowerPC uses a more efficient soft-fp derived from glibc. Other targets like arm, ia64, sparc and also some new targets use it. Please see config/*/t-*softfp and config/*/sfp-machine.h. We can expect the best performance from Joern's assembly soft fp, but in general the maintenance of hand crafted assembly codes will be hard. If I remember correctly, there were some arguments for this target specific one vs. generic one when soft-fp was introduced in gcc. It would be better to try soft-fp on SH and see numbers with current fp-bit, soft-fp and assembly one. If soft-fp is yet too inefficient for you, you can free to propose a complete and regtested patch for SH assembly soft fp against trunk. The original Joern's patch touched not only SH specific part but also the generic part of the compiler. The revised patch is needed to test it for various targets too. Regards, kaz
Re: SH optimized software floating point routines
"Naveen H. S" wrote: >>> you can free to propose a complete and regtested patch for SH >>> assembly soft fp against trunk. > > Please find attached the ported soft float patch "sh_softfloat.patch". > The original patch was posted at the following link by Joern RENNECKE. > http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00614.html Your patches are for 4.5.0 and sh_softfloat.patch can't be applicable for trunk cleanly. Please provide patches against svn trunk and the ChangeLog entries for them. Here is an incomplete list of comments for sh_softfloat.patch: *target*: New macro TARGET_MATCH_ADJUST requires a doc patch. reload.c: config/sh/lib1funcs.asm: config/sh/lib1funcs.h: Copyright years of these files should be updated. All copyright of IEEE-754/* files should be GPLv3 with Runtime library exception instead of v2 and 2010 should be added to their copyright years. Please see the one used in sh/lib1funcs.asm for example. config/sh/sh.c: >+/* Saved operands from the last compare to use when we generate an scc >+ or bcc insn. */ >+ >+rtx sh_compare_op0; >+rtx sh_compare_op1; It looks that sh_compare_op0 snd sh_compare_op1 are set but not used. >+ REG_NOTES (last) = gen_rtx_EXPR_LIST (REG_EQUAL, equiv, REG_NOTES (last)); Use add_reg_note here. Several other similar cases. > Please find attached the patch ""sh_softfp.patch" which implements basic > support of soft-fp for SH target. There were no regressions found with > the patch. Please let us know if there should be any further improvements > required for complete soft-fp support. sh_softfp.patch looks basically OK to me, though I'm curious with numbers for fp-bit.c/softfp/softfloat. Could you show us some real speed&size numbers? Regards, kaz
Re: SH optimized software floating point routines
Joern Rennecke wrote: > I don't have any sh[1234] hardware to EEMBC tests on, but the runtime > difference of 'make check' on i686-pc-linux-gnu X sh-elf using a core2 quad > for fp-bit vs. softfloat (w/ compare/conversion/divsf) is two hours 4 minutes > versus 38 minutes. Very impressive. Thanks! Reducing 124 minutes to 38 minutes is too attractive. Regards, kaz
Re: SH optimized software floating point routines
Joern Rennecke wrote: > I've found two bugs in truncdfsf2; > I've also added back a number of hunks that Naveen had dropped. > > Note that most of the patch has been prepared in 2006, so that is the > proper most recent copyright date for those files that haven't been touched > save for swapping the Copyright notice. I've got some regressions with "make check" on sh4-unknown-linux-gnu. It looks that all of them are failed with the undefined references to __unorddf2/__unordsf2 when -mieee enabled. I'm trying the attached patch over sh-softfp-20100718-2131 patch. All regressions go away with it on cross sh4-unknown-linux-gnu, though the native bootstrap will take a few days more. BTW, it looks that softfp __unord?f2 routines check signaling NaNs only. This makes __builtin_isnan return false for quiet NaNs for which current fp-bit ones return true when -mieee enabled. Perhaps that change of behavior might be OK for software FP. Regards, kaz -- diff -uprN ORIG/trunk/gcc/config/sh/ieee-754-df.S trunk/gcc/config/sh/ieee-754-df.S --- ORIG/trunk/gcc/config/sh/ieee-754-df.S 2010-07-20 11:39:29.0 +0900 +++ trunk/gcc/config/sh/ieee-754-df.S 2010-07-20 11:36:15.0 +0900 @@ -23,11 +23,11 @@ see the files COPYING3 and COPYING.RUNTI !! STMicroelectronics ST40 CPUs !! Contributed by J"orn Rennecke joern.renne...@st.com -#ifndef __SH_FPU_DOUBLE__ - #include "lib1funcs.h" #include "insn-constants.h" +#ifndef __SH_FPU_DOUBLE__ + /* Double-precision floating-point emulation. We handle NANs, +-infinity, and +-zero. However, we assume that for NANs, the topmost bit of the fraction is set. */ @@ -123,7 +123,7 @@ GLOBAL(unorddf2): mov.l LOCAL(c_DF_NAN_MASK),r1 not DBL0H,r0 tst r1,r0 - not r6,r0 + not DBL1H,r0 bt LOCAL(unord) tst r1,r0 LOCAL(unord): @@ -788,4 +788,52 @@ LOCAL(x7ff8): #endif /* L_divdf3 */ #endif /* DYN_SHIFT */ +#else /* __SH_FPU_DOUBLE__ */ + +#ifdef L_unorddf2 + .balign 4 + .global GLOBAL(unorddf2) + FUNC(GLOBAL(unorddf2)) +GLOBAL(unorddf2): + fldsfr4,fpul + sts fpul,r4 + shllr4 + mov.l LOCAL(c_DF_QNAN_MASK),r1 + shlrr4 + cmp/eq r4,r1 + bf/sLOCAL(unord_check_qnan0) + fldsfr5,fpul + sts fpul,r5 + tst r5,r5 + bt LOCAL(unord_next) +LOCAL(unord_check_qnan0): + not r4,r0 + tst r1,r0 + bt LOCAL(unord) +LOCAL(unord_next): + fldsfr6,fpul + sts fpul,r6 + shllr6 + shlrr6 + cmp/eq r6,r1 + bf/sLOCAL(unord_check_qnan1) + fldsfr7,fpul + sts fpul,r7 + tst r7,r7 + bt LOCAL(unord_fail) +LOCAL(unord_check_qnan1): + not r6,r0 + tst r1,r0 +LOCAL(unord): + rts + movtr0 +LOCAL(unord_fail): + rts + mov #0,r0 + .balign 4 +LOCAL(c_DF_QNAN_MASK): + .long 0x7ff0 + ENDFUNC(GLOBAL(unorddf2)) +#endif /* L_unorddf2 */ + #endif /* __SH_FPU_DOUBLE__ */ diff -uprN ORIG/trunk/gcc/config/sh/ieee-754-sf.S trunk/gcc/config/sh/ieee-754-sf.S --- ORIG/trunk/gcc/config/sh/ieee-754-sf.S 2010-07-20 11:39:30.0 +0900 +++ trunk/gcc/config/sh/ieee-754-sf.S 2010-07-20 11:35:58.0 +0900 @@ -23,11 +23,11 @@ see the files COPYING3 and COPYING.RUNTI !! STMicroelectronics ST40 CPUs !! Contributed by J"orn Rennecke joern.renne...@st.com -#ifndef __SH_FPU_ANY__ - #include "lib1funcs.h" #include "insn-constants.h" +#ifndef __SH_FPU_ANY__ + /* Single-precision floating-point emulation. We handle NANs, +-infinity, and +-zero. However, we assume that for NANs, the topmost bit of the fraction is set. */ @@ -689,4 +689,42 @@ LOCAL(tab): #endif /* L_hypotf */ #endif /* DYN_SHIFT */ +#else /* __SH_FPU_ANY__ */ + +#ifdef L_unordsf2 + .balign 4 + .global GLOBAL(unordsf2) + FUNC(GLOBAL(unordsf2)) +GLOBAL(unordsf2): + fldsfr5,fpul + sts fpul,r4 + shllr4 + mov.l LOCAL(c_SF_QNAN_MASK),r1 + shlrr4 + cmp/eq r4,r1 + bt/sLOCAL(unord_next) + not r4,r0 + tst r1,r0 + bt LOCAL(unord) +LOCAL(unord_next): + fldsfr4,fpul + sts fpul,r5 + shllr5 + shlrr5 + cmp/eq r5,r1 + bt/sLOCAL(unord_fail) + not r5,r0 + tst r1,r0 +LOCAL(unord): + rts + movtr0 +LOCAL(unord_fail): + rts + mov #0,r0 + .balign 4 +LOCAL(c_SF_QNAN_MASK): + .long 0x7f80 + ENDFUNC(GLOBAL(unordsf2)) +#endif /* L_unordsf2 */ + #endif /* __SH_FPU_ANY__ */
Re: SH optimized software floating point routines
> I'm trying the attached patch over sh-softfp-20100718-2131 patch.
> All regressions go away with it on cross sh4-unknown-linux-gnu,
> though the native bootstrap will take a few days more.
There are a few warnings in bootstrap:
../trunk/gcc/config/sh/sh.c: In function 'sh_soft_fp_cmp':
../trunk/gcc/config/sh/sh.c:2193:8: error: enum conversion in initialization is
invalid in C++ [-Werror=c++-compat]
../trunk/gcc/config/sh/sh.c:2248:3: error: enum conversion when passing
argument 1 of 'gen_rtx_fmt_ee_stat' is invalid in C++ [-Werror=c++-compat]
./genrtl.h:24:1: note: expected 'enum rtx_code' but argument is of type 'int'
../trunk/gcc/config/sh/sh.c: In function 'expand_sfunc_op':
../trunk/gcc/config/sh/sh.c:8744:19: error: variable 'insn' set but not used
[-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
The attached is a fixup for them.
Unfortunately, the bootstrap has failed with stage2/stage3
comparison failure, though it might be irrelevant with softfp
patches. I'll try again with some older revision.
Regards,
kaz
--
--- ORIG/trunk/gcc/config/sh/sh.c 2010-07-19 10:58:36.0 +0900
+++ trunk/gcc/config/sh/sh.c2010-07-21 06:45:18.0 +0900
@@ -2185,12 +2185,13 @@ sh_emit_cheap_store_flag (enum machine_m
}
static rtx
-sh_soft_fp_cmp (int code, enum machine_mode op_mode, rtx op0, rtx op1)
+sh_soft_fp_cmp (enum rtx_code code, enum machine_mode op_mode, rtx op0,
+ rtx op1)
{
const char *name = NULL;
rtx (*fun) (rtx, rtx), addr, tmp, last, equiv;
int df = op_mode == DFmode;
- enum machine_mode mode = CODE_FOR_nothing; /* shut up warning. */
+ enum machine_mode mode = MAX_MACHINE_MODE; /* shut up warning. */
switch (code)
{
@@ -8741,13 +8742,13 @@ expand_sfunc_op (int nargs, enum machine
const char *name, rtx equiv, rtx *operands)
{
int next_reg = FIRST_PARM_REG, i;
- rtx addr, last, insn;
+ rtx addr, last;
addr = gen_reg_rtx (Pmode);
function_symbol (addr, name, SFUNC_FREQUENT);
for ( i = 1; i <= nargs; i++)
{
- insn = emit_move_insn (gen_rtx_REG (mode, next_reg), operands[i]);
+ emit_move_insn (gen_rtx_REG (mode, next_reg), operands[i]);
next_reg += GET_MODE_SIZE (mode) / UNITS_PER_WORD;
}
last = emit_insn ((*fun) (operands[0], addr));
Re: SH optimized software floating point routines
Joern Rennecke wrote: > That's a bug, then; we shouldn't use a library function there, > but the cmpordered[sd]f_t_4 patterns. Argh, I've missed the required patterns are incorporated already in your patch. I'll test it again with sh-softfp-predicate-fix when the tests for 4.5.1-rc are done. Thanks! Regards, kaz
Re: SH optimized software floating point routines
> Joern Rennecke wrote:
>> That's a bug, then; we shouldn't use a library function there,
>> but the cmpordered[sd]f_t_4 patterns.
>
> Argh, I've missed the required patterns are incorporated already
> in your patch. I'll test it again with sh-softfp-predicate-fix
> when the tests for 4.5.1-rc are done. Thanks!
I've tested sh-softfp-20100718-2131 + sh-softfp-predicate-fix
on -m1, -m2, -m3, -m3 -ml, -m2a on sh-elf, sh4-linux and
sh64-linux. sh64-linux required the first hunk of the attached
patch to build. The test with -m3 -ml shows some regressions
which look to be solved with the second hunk of the patch.
Now all test results look clean.
For NaN issue, I'd like to wait a full patch from Christian.
I'm curious again about the numbers with/without it.
Regards,
kaz
--
* config/sh/sh.md (cstoresf4): Fix typos.
* config/sh/ieee-754-df.S (unorddf2): Use DBL1H instead of r6.
diff -upr ORIG/trunk/gcc/config/sh/sh.md trunk/gcc/config/sh/sh.md
--- ORIG/trunk/gcc/config/sh/sh.md Wed Jul 21 08:12:23 2010
+++ trunk/gcc/config/sh/sh.md Thu Jul 22 10:36:36 2010
@@ -9462,10 +9462,10 @@ mov.l\\t1f,r0\\n\\
"TARGET_SH1 || TARGET_SHMEDIA_FPU"
"if (TARGET_SHMEDIA)
{
- if (!arith_operand (operands[2], DFmode))
-operands[2] = copy_to_mode_reg (DFmode, operands[2]);
- if (!arith_operand (operands[3], DFmode))
-operands[3] = copy_to_mode_reg (DFmode, operands[3]);
+ if (!arith_operand (operands[2], SFmode))
+operands[2] = copy_to_mode_reg (SFmode, operands[2]);
+ if (!arith_operand (operands[3], SFmode))
+operands[3] = copy_to_mode_reg (SFmode, operands[3]);
emit_insn (gen_cstore4_media (operands[0], operands[1],
operands[2], operands[3]));
DONE;
diff -uprN ORIG/trunk/gcc/config/sh/ieee-754-df.S
trunk/gcc/config/sh/ieee-754-df.S
--- ORIG/trunk/gcc/config/sh/ieee-754-df.S 2010-07-20 11:39:29.0
+0900
+++ trunk/gcc/config/sh/ieee-754-df.S 2010-07-22 13:16:07.0 +0900
@@ -123,7 +123,7 @@ GLOBAL(unorddf2):
mov.l LOCAL(c_DF_NAN_MASK),r1
not DBL0H,r0
tst r1,r0
- not r6,r0
+ not DBL1H,r0
bt LOCAL(unord)
tst r1,r0
LOCAL(unord):
Re: SH optimized software floating point routines
"Naveen H. S" wrote: > The SH toolchain was built with the following patches and regression > is completed. > 1. sh-softfp-20100718-2131 > 2. sh-softfp-predicate-fix > 3. Patch by Kaz Kojima-san at following link > http://gcc.gnu.org/ml/gcc/2010-07/msg00352.html Thanks for testing. > However, there were some regressions compared to fresh toolchain. > The following list summarizes the regressions for each target. [snip] >>> Now all test results look clean > > Please let me know whether these regressions are known and okay? "clean" might be a bad choice of words. I meant that results are expected i.e. regressions I saw are NaN issues we discussed in the list. Although your list of arches and regressions is different from mine, some regressions you've caught > gcc.c-torture/execute/2605-1.c (-O0) > gcc.c-torture/execute/20060420-1.c (-Os) > gcc.c-torture/execute/loop-ivopts-1.c > gcc.c-torture/execute/pr39228.c(-O0) > gcc.dg/pr41963.c > c-c++-common/torture/complex-sign-mixed-mul.c > gcc.target/sh/sh4a-fprun.c don't look like NaN issues and we should know what is going on in these cases. Regards, kaz
Re: GCC 4.0.3 RC1
Mark Mitchell <[EMAIL PROTECTED]> wrote:
> GCC 4.0.3 RC1 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.3-20060303
>
> Please download and test!
There are failures on sh4-*-linux-gnu during libjava build and 65
unusual regressions for C++ testsuite. I don't file PRs for them
because it looks these are the same problems as PR target/22553
and PR target/23706 which are the target issues for the exception
solved at 4.1:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23706
It seems that the recent changes on 4.0 branch reveal these target
problems which are latent on 4.0. There are patches for these PRs,
though the patch for 23706 touches the middle end file. I'm unsure
whether to backport it to 4.0.3 is appropriate or not at this last
stage.
Anyway the attached backport patches are tested with bootstrap and
"make -k check" on i686-pc-linux-gnu with no new failures.
Although bootstrap on sh4-unknown-linux-gnu is on going, the result
of the toplevel "make -k check" on x86 cross sh4-unknown-linux-gnu
looks fine.
Regards,
kaz
--
2006-03-06Kaz Kojima <[EMAIL PROTECTED]>
PR target 23706
Backport from 4.1:
* lcm.c (optimize_mode_switching): Clear transp bit for
block with incomming abnormal edges.
PR target 22553
Backport from 4.1:
* config/sh/sh.h (OPTIMIZATION_OPTIONS): Set flag_schedule_insns
to 2 if it's already non-zero.
(OVERRIDE_OPTIONS): Clear flag_schedule_insns if flag_exceptions
is set and warn about it if flag_schedule_insns is 1.
diff -uprN ORIG/gcc-4.0.3-20060303/gcc/lcm.c TMP/gcc-4.0.3-20060303/gcc/lcm.c
--- ORIG/gcc-4.0.3-20060303/gcc/lcm.c 2005-01-18 20:36:31.0 +0900
+++ TMP/gcc-4.0.3-20060303/gcc/lcm.c2006-03-06 10:07:51.0 +0900
@@ -1223,6 +1223,18 @@ optimize_mode_switching (FILE *file)
REG_SET_TO_HARD_REG_SET (live_now,
bb->global_live_at_start);
+
+ /* Pretend the mode is clobbered across abnormal edges. */
+ {
+ edge_iterator ei;
+ edge e;
+ FOR_EACH_EDGE (e, ei, bb->preds)
+ if (e->flags & EDGE_COMPLEX)
+ break;
+ if (e)
+ RESET_BIT (transp[bb->index], j);
+ }
+
for (insn = BB_HEAD (bb);
insn != NULL && insn != NEXT_INSN (BB_END (bb));
insn = NEXT_INSN (insn))
diff -uprN ORIG/gcc-4.0.3-20060303/gcc/config/sh/sh.h
TMP/gcc-4.0.3-20060303/gcc/config/sh/sh.h
--- ORIG/gcc-4.0.3-20060303/gcc/config/sh/sh.h 2006-01-05 08:07:24.0
+0900
+++ TMP/gcc-4.0.3-20060303/gcc/config/sh/sh.h 2006-03-06 10:30:51.0
+0900
@@ -695,6 +695,10 @@ do {
\
if (! (SIZE))\
target_flags |= SAVE_ALL_TR_BIT;\
} \
+ /* If flag_schedule_insns is 1, we set it to 2 here so we know if\
+ the user explicitly requested this to be on or off. */ \
+ if (flag_schedule_insns > 0) \
+flag_schedule_insns = 2; \
} while (0)
#define ASSEMBLER_DIALECT assembler_dialect
@@ -796,6 +800,17 @@ do {
\
SH3 and lower as they give spill failures for R0. */ \
if (!TARGET_HARD_SH4)\
flag_schedule_insns = 0; \
+ /* ??? Current exception handling places basic block boundaries \
+after call_insns. It causes the high pressure on R0 and gives \
+spill failures for R0 in reload. See PR 22553 and the thread \
+on gcc-patches \
+ <http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00816.html>. */
\
+ else if (flag_exceptions)
\
+ { \
+ if (flag_schedule_insns == 1) \
+ warning (0, "ignoring -fschedule-insns because of exception
handling bug"); \
+ flag_schedule_insns = 0; \
+ } \
} \
\
if (align_loops == 0)
\
Re: GCC 4.0.3 RC1
Mark Mitchell <[EMAIL PROTECTED]> wrote: > If these patches show an improvement on SH4, please go ahead and check > them in. Please inform me of the status ASAP. I've checked it in as 111792. Sorry for the delay. Regards, kaz
Re: SH: Should libgcc_s.so not be actually linker script ?
SUGIOKA Toshinobu <[EMAIL PROTECTED]> wrote: > But now, "gcc -v -o hello hello.c" gives following output on linking phase. > > /usr/libexec/gcc/sh4-unknown-linux/4.1.0/collect2 --eh-frame-hdr -m > shlelf_linux -dynamic-linker /lib/ld-linux.so.2 -o hello > /usr/lib/gcc/sh4-unknown-linux/4.1.0/../../../crt1.o > /usr/lib/gcc/sh4-unknown-linux/4.1.0/../../../crti.o > /usr/lib/gcc/sh4-unknown-linux/4.1.0/crtbegin.o > -L/usr/lib/gcc/sh4-unknown-linux/4.1.0 -L/usr/lib/gcc/sh4-unknown-linux/4.1.0 > -L/usr/lib/gcc/sh4-unknown-linux/4.1.0/../../.. /tmp/ccer52C9.o -lgcc > --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s > --no-as-needed /usr/lib/gcc/sh4-unknown-linux/4.1.0/crtend.o > /usr/lib/gcc/sh4-unknown-linux/4.1.0/../../../crtn.o > > It seems that libgcc.a is linked automatically, so it would be work if > libgcc_s.so is a symbolic link to libgcc_s.so.1. > > If libgcc_s.so were symbolic link, unneeded dependency on libgcc_s.so.1 would > not be written to the executable. > ( '--as-needed' seems not work for linker script ) Thanks for pointing it out. Could you propose the patch for it on trunk to gcc-patches? Regards, kaz
Re: sh64 support
Joern RENNECKE <[EMAIL PROTECTED]> wrote: > My simulator now segfaults for every single execution test built with > mainline; when I try gdb, it also segfaults, > somewhere in the dwarf handling code. > Unless someone comes up with a viable concept how to maintain sh64 > support in gcc, I think we have to deprecate > it now, since at the time of the gcc 4.3 release it can be expected to > have bitrotted too much to be more useful than > or even as useful as a vintage release. I agree with Joern about the disastrous status of the simulator test, though not every execution tests fail in my environment: === g++ Summary === # of expected passes12270 # of unexpected failures235 # of unexpected successes 1 # of expected failures 65 # of unresolved testcases 50 # of unsupported tests 140 === gcc Summary === # of expected passes38606 # of unexpected failures610 # of unexpected successes 2 # of expected failures 73 # of unresolved testcases 42 # of untested testcases 28 # of unsupported tests 413 === libstdc++ Summary === # of expected passes2390 # of unexpected failures491 # of unexpected successes 1 # of expected failures 10 # of unsupported tests 153 Compiler version: 4.2.0 20060823 (experimental) Platform: sh64-unknown-elf configure flags: --host=i686-pc-linux-gnu --target=sh64-unknown-elf --with-ld=/usr/local/bin/sh64-unknown-elf-ld --with-as=/usr/local/bin/sh64-unknown-elf-as --disable-libssp --with-headers --with-newlib --disable-gdb --enable-languages=c,c++ Perhaps it's because I gave up the unified tree and use older sim and binutils. Oddly the result of the regtest on sh64-unknown-linux-gnu looks not so broken: http://gcc.gnu.org/ml/gcc-testresults/2006-08/msg01073.html Regards, kaz
Re: Simulator testing for sh and sh64
Thomas Schwinge wrote: > This is about sh and sh64 GDB sim testing for the whole toolchain. (I > also do have sh4a hardware available, where testing is working fine.) > Kaz, could you please have a look whether this looks basically sane, that > my assumptions and the results I'm getting are about right, etc.? You are right, I think. > Kaz, is my understanding correct, that I simply use sh64-elf as target, > and again the sh-sim board? Should I be setting a specific CPU when > configuring GCC, or any other customization? I used sh64-sim board for sh64-elf. sh64-sim.exp baseboard can be seen in http://lists.gnu.org/archive/html/dejagnu/2008-02/msg00056.html > This means, for sh-elf sim testing, we have a bit too many failures in > GCC and GDB, and some ld test harness issue. For sh64-elf we have a GCC > trunk ICE, some section overlap issue, and even more GDB issues. Yep. About sh64, I had used sh64-linux as my testing target, but unfortunately that real sh64 system stopped working after the earthquake. Regards, kaz
Re: sh-elf vs profiling
DJ Delorie <[EMAIL PROTECTED]> wrote: > Is sh-elf/sim supposed to support profiling? My latest tests show all > the profiling tests failing. For example, the bprob executable has > the name of the gcda file in it, but doesn't attempt to write it out > (verified with strace against the simulator). Is your gcc configured with --with-newlib --with-headers? I thought that those options are required to get a working libgcov on newlib targets. Regards, kaz
Re: sh-elf vs profiling
DJ Delorie <[EMAIL PROTECTED]> wrote: >> Is your gcc configured with --with-newlib --with-headers? > > $TOP/gcc/gcc/configure --prefix=$PREFIX --target=$TARGET \ > --enable-languages=c,c++ --with-newlib --with-mpfr=/usr/local > > I do a two-phase build. I build gcc (and let it fail for libgcc) to > get xgcc/cc1, then build and install newlib, then go back and build > gcc. > > But it fails even in one of our recent combined-tree builds too. Hmm... Did you try --with-headers? I've configured my unified tree like as ../TMP/combined/configure --target=sh-elf --prefix=/exp/ldroot/dodes/install-combined --with-newlib --with-headers --disable-gdbtk --enable-languages=c and got Running /exp/ldroot/dodes/TMP/combined/gcc/testsuite/gcc.misc-tests/bprob.exp ... === gcc Summary === # of expected passes56 for "make check-gcc RUNTESTFLAGS='--target_board=sh-sim bprob.exp'. Regards, kaz
Re: -mfmovd enabled by default for SH2A but not for SH4
"Naveen H.S." <[EMAIL PROTECTED]> wrote: > The option "-mfmovd" is enabled by default for SH2A which generates > "fmov.d" instruction by default. However, SH4 and SH4A targets > generates "fmov.d" instruction only after passing the option "-mfmovd". fmov.d has a byte order problem in little endian. I guess that -mfmovd is default on SH2A because SH2A is big endian only, though I know nothing about the history of SH2A support. > The following testcase results in address error at "fmov.d" instruction. I can't reproduce it with my unified tree&sim and couldn't find any description for 8-byte alignment restriction for double data on memory in my SH2A manual, though I could be wrong about that. Have you got this error on the real SH2A-FPU hardware? Regards, kaz
Re: -mfmovd enabled by default for SH2A but not for SH4
"Naveen H.S." <[EMAIL PROTECTED]> wrote:
> Yes, we got this error on SH72513(SH2A) hardware. When the same code
> is run on simulator, the "address error" occurs on encountering the
> "fmov.d" instruction.
[snip]
> It is mentioned that "Double longword data accessed from other than
> double longword boundary" results in address error.
I thought that fmov.d does two long word accesses as Christian
has pointed out in his comment.
Anyway, the address error on the real hardware would suggest
that the double long word access occurs in your case.
Although one can explicitly provide his own fpscr setting as
Christian said and can use appropriate options, defaulting
-mdalign for TARGET_SH2A_DOUBLE might be more robust for users.
Could you please try the appended patch? Christian, how does
it look?
Regards,
kaz
--
* config/sh/sh.h (OVERRIDE_OPTIONS): Set MASK_ALIGN_DOUBLE
for TARGET_SH2A_DOUBLE.
--- ORIG/trunk/gcc/config/sh/sh.h 2007-12-07 09:11:38.0 +0900
+++ LOCAL/trunk/gcc/config/sh/sh.h 2008-02-25 19:09:48.0 +0900
@@ -553,7 +553,7 @@ do {
\
{ \
sh_cpu = CPU_SH2A; \
if (TARGET_SH2A_DOUBLE) \
-target_flags |= MASK_FMOVD;\
+target_flags |= MASK_FMOVD | MASK_ALIGN_DOUBLE;
\
} \
if (TARGET_SH3) \
sh_cpu = CPU_SH3; \
Re: -mfmovd enabled by default for SH2A but not for SH4
"Naveen H.S." <[EMAIL PROTECTED]> wrote: > Yes, we completely agree that using the option "-mdalign" would solve > the "address error" problem in the present testcase. We had tried the > similar way to solve the problem. However, we observed that "-mdlaign" > option would not guarantee the stack variables to be 8 byte aligned. > Please refer the following link which explains the same. > http://gcc.gnu.org/ml/gcc/2008-02/msg00508.html TARGET_ALIGN_DOUBLE means that PREFERRED_STACK_BOUNDARY is set to 64. I remember that such problem exists in older compilers as Toshi pointed out, but thought that they are fixed on trunk. You could file it to the bugzilla with your testcase. Regards, kaz
Re: -mfmovd enabled by default for SH2A but not for SH4
> --- ORIG/trunk/gcc/config/sh/sh.h 2007-12-07 09:11:38.0 +0900
> +++ LOCAL/trunk/gcc/config/sh/sh.h2008-02-25 19:09:48.0 +0900
> @@ -553,7 +553,7 @@ do {
> \
> {
> \
>sh_cpu = CPU_SH2A; \
>if (TARGET_SH2A_DOUBLE)
> \
> -target_flags |= MASK_FMOVD; \
> +target_flags |= MASK_FMOVD | MASK_ALIGN_DOUBLE;
> \
I've played with this patch and recognize that it's not that
simple, unfortunately. -mdalign changes not only alignment
of doubles but also calling conventions. If you compile
void foo () { bar (1, 0x12345678abcdLL); }
with/without -mdalign, for example, you can see that effect.
This behavior with -mdalign is consistent from 3.4.
It seems that such change is too big for SH2A users. Perhaps
this was one reason of not defaulting -mdalign for SH2A.
Regards,
kaz
Re: Draft SH uClinux FDPIC ABI
"Joseph S. Myers" <[EMAIL PROTECTED]> wrote: > Here is a draft FDPIC ABI for SH uClinux, based on the FR-V FDPIC ABI. > Please send any comments; CodeSourcery will be implementing the final ABI > version in GCC and Binutils. Wow, great news! One minor point I'm curious is the choice of the physical numbers for new relocations, though proposed numbers 70-77 look good. Regards, kaz
Re: RFH: Building and testing gimple-tuples-branch
Diego Novillo <[EMAIL PROTECTED]> wrote:
> So, for folks with free cycles to spare, could you build the branch on
> your favourite target and report bugs? Bugzilla and/or email reports
> are OK. If you are creating a bugzilla report, please add my address to
> the CC field.
With the attached patch, SH cross can be built for gimple-tuples-branch.
The testresult for sh4-unknown-linux-gnu cross x86-linux is:
http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg00801.html
Regards,
kaz
--
* config/sh/sh.c (sh_gimplify_va_arg_expr): Change pre_p and
post_p types to gimple_seq *.
diff -uprN ORIG/gimple-tuples-branch/gcc/config/sh/sh.c
LOCAL/gimple-tuples-branch/gcc/config/sh/sh.c
--- ORIG/gimple-tuples-branch/gcc/config/sh/sh.c2008-05-09
17:39:13.0 +0900
+++ LOCAL/gimple-tuples-branch/gcc/config/sh/sh.c 2008-05-09
18:12:37.0 +0900
@@ -261,7 +261,7 @@ static bool sh_strict_argument_naming (C
static bool sh_pretend_outgoing_varargs_named (CUMULATIVE_ARGS *);
static tree sh_build_builtin_va_list (void);
static void sh_va_start (tree, rtx);
-static tree sh_gimplify_va_arg_expr (tree, tree, tree *, tree *);
+static tree sh_gimplify_va_arg_expr (tree, tree, gimple_seq *, gimple_seq *);
static bool sh_pass_by_reference (CUMULATIVE_ARGS *, enum machine_mode,
const_tree, bool);
static bool sh_callee_copies (CUMULATIVE_ARGS *, enum machine_mode,
@@ -7255,8 +7255,8 @@ find_sole_member (tree type)
/* Implement `va_arg'. */
static tree
-sh_gimplify_va_arg_expr (tree valist, tree type, tree *pre_p,
-tree *post_p ATTRIBUTE_UNUSED)
+sh_gimplify_va_arg_expr (tree valist, tree type, gimple_seq *pre_p,
+gimple_seq *post_p ATTRIBUTE_UNUSED)
{
HOST_WIDE_INT size, rsize;
tree tmp, pptr_type_node;
libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets
Hi, I've noticed that some libjava tests fail for SH on trunk and 4.2.0 RC3. New tests that FAIL: Divide_1 -O3 -findirect-dispatch output - bytecode->native test Divide_1 -O3 output - bytecode->native test Divide_1 -O3 output - source compiled test Divide_1 -findirect-dispatch output - bytecode->native test Divide_1 output - bytecode->native test Divide_1 output - source compiled test pr6388 -O3 -findirect-dispatch output - bytecode->native test pr6388 -O3 output - bytecode->native test pr6388 -O3 output - source compiled test pr6388 -findirect-dispatch output - bytecode->native test pr6388 output - bytecode->native test pr6388 output - source compiled test I see same FAILs in the RC3 testresults for x86_64, hppa, ia64, ppc, sparc and s390 at gcc-testresults, though not for i686. Is this a known issue? Regards, kaz
Bootstrap failure on x86
Hi, My i686-pc-linux-gnu build fails with libtool: link: /exp/ldroot/dodes/i686-gcc-orig/gcc/gcj -B/exp/ldroot/dodes/i686-gcc-orig/i686-pc-linux-gnu/libjava/ -B/exp/ldroot/dodes/i686-gcc-orig/gcc/ -ffloat-store -fomit-frame-pointer -Usun -g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc -L/exp/ldroot/dodes/i686-gcc-orig/i686-pc-linux-gnu/libjava/.libs -L/exp/ldroot/dodes/i686-gcc-orig/i686-pc-linux-gnu/libjava ./.libs/libgcj.so -lpthread -lrt -ldl -Wl,-rpath -Wl,/usr/local/lib ./.libs/libgcj.so: undefined reference to `FFI_TYPE_DOUBLE' ./.libs/libgcj.so: undefined reference to `FFI_TYPE_SINT64' ./.libs/libgcj.so: undefined reference to `FFI_TYPE_LONGDOUBLE' ./.libs/libgcj.so: undefined reference to `FFI_TYPE_INT' ./.libs/libgcj.so: undefined reference to `FFI_TYPE_FLOAT' ... on revision 126435. Anyone else sees this failure? It looks cc1 -E -lang-asm outputs cmpl $FOO,%ecx instead of cmpl $3,%ecx for #define FOO 3 cmpl $FOO,%ecx Regards, kaz
Re: Bootstrap failure on x86
"Andrew Pinski" <[EMAIL PROTECTED]> wrote: >> on revision 126435. Anyone else sees this failure? > > Well this is obviously caused by: > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00617.html > > This is not the first time this has happened. I've confirmed that x86 bootstraps again with reverting that patch and filed this issue as PR 32670. Thanks! Regards, kaz
