From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-398779-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 6664 invoked by alias); 16 Aug 2012 12:43:26 -0000
Received: (qmail 6648 invoked by uid 22791); 16 Aug 2012 12:43:24 -0000
X-SWARE-Spam-Status: No, hits=-4.4 required=5.0	tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED
X-Spam-Check-By: sourceware.org
Received: from localhost (HELO gcc.gnu.org) (127.0.0.1)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 16 Aug 2012 12:43:11 +0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/54272] [SH] Add support for addv / subv instructions
Date: Thu, 16 Aug 2012 12:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: olegendo at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: olegendo at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-54272-4-QWuST8OFQE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-54272-4@http.gcc.gnu.org/bugzilla/>
References: <bug-54272-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2012-08/txt/msg01051.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54272

--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-08-16 12:43:09 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> 
> For linux environment, libc's abort function is a rather complex
> function and trapa handler should do equivalent things to keep
> complete binary compatibility.  I guess that it isn't worth to do
> so.  You can introduce simple trapa sequence as an ABI changing -m
> option on linux, though trap numbers < 32 are allocated for the
> syscalls and all other numbers are given for debug purposes and
> generate SIGTRAP with modified pc which points to trapa instruction
> itself.  If the user program uses its own SIGTRAP handlers, this
> might be problematic.  Perhaps the "sleep" instruction will be
> a candidate because current libc uses it for ABORT_INSTRUCTION,
> though it would be bad for bare metal cases.
> BTW, there is a known SH4 core bug for trapa instruction and we
> are using 5 or r0,r0 instructions just after trapa.  See libitm/
> config/sh/futex_bits.h for example.

Thanks a lot for the hints!

Just for the record, the SH7750 / SH7751 trapa bug is described here
http://documentation.renesas.com/doc/products/mpumcu/tu/tnsh7456ae.pdf

Taking this into account, the trapa insn suddenly seems very unattractive for
this
purpose ;)
How about small variation:

    mov.l  .Loverflow_trap, r1
    addv   r4,r5
    bf       0f
    jsr      @r1
0:
    nop
    ....

'overflow_trap' then would be a library function in libgcc lib1funcs.S,  like
e.g. the dynamic shift functions for SH2.  The default implementation of
overflow_trap could simply invoke abort to
stay in line with the other trapping operations in libgcc.
For bare metal cases, users can provide their own libgcc implementation and do
whatever they
want.