Hi,
I have re-run GNAT/RTEMS on a number of targets
for 4.3.4, 4.4.1 and the SVN head. I kept the
binutils, gdb, newlib and RTEMS the same. The SVN head
has a lot of new failures for SPARC, MIPS, and x86.
The SPARC and MIPS have the same number of failures
(319) so I assume the same underlying
On 09/14/09 11:52:11, Richard Guenther wrote:
> Without reading all the details of your mail I suggest that you
> perform a custom walk over the function bodies right before
> the frontend calls cgraph_finalize_compilation_unit () that
> performs the necessary lowering (and function creation) to
>
On 09/14/2009 12:18 PM, Jean Christophe Beyler wrote:
[(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,R")
(match_operand:DI 1 "general_operand" "r,i,R,r"))]
Where R checks if the operand is a memory operand and if the offset is correct.
Did you use define_memory_const
Dear all,
I was working on simplifying the movdi in my port and I had put :
[(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,o")
(match_operand:DI 1 "general_operand" "r,i,o,r"))]
However, due to constraints on the offset that is allowed, I:
- Added the check of the offse
Another thing to look at, since you have hand-written routines and may
be able to specify that e.g. only a subset of the normal call clobbered
registers are actually modified, is to leave the call as a "compare"
insn. Something like
(define_insn "*cmpsf"
[(set (reg:CC status-reg)
(c
On 08/31/2009 12:57 AM, Jerry Quinn wrote:
On Thu, 2009-08-27 at 00:24 -0400, Jason Merrill wrote:
Do you know why r149964 makes a difference?
I understand now. The patch changed the anonymous namespace name to use
get_file_function_name in all cases, where previously we were using the
same
Paul Edwards wrote:
> int
> i370_branch_dest (branch)
> rtx branch;
> {
> rtx dest = SET_SRC (PATTERN (branch));
> int dest_uid;
> int dest_addr;
>
> /* first, compute the estimated address of the branch target */
> if (GET_CODE (dest) == IF_THEN_ELSE)
> dest = XEXP (dest, 1);
Paul Edwards wrote:
Just one comment on this particular point:
> 4. There is one thing that doesn't have proper ASCII to EBCDIC
> translation being done - the __FUNCTION__ builtin.
It looks this was indeed a bug that was fixed for GCC 4.0.0:
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01773.htm
On 09/14/2009 06:59 AM, Mohamed Shafi wrote:
Is there a way to let GCC know that the result for FP compare
are stored in the Status Register so that GCC generates directly a
jump operation? How can i implement this?
There is no way to do this via the standard libcall sequence.
In order to impl
On 09/14/2009 07:24 AM, Mohamed Shafi wrote:
Hello all,
I am doing a port for a 32bit target in GCC 4.4.0. I have to support a
40bit data (_Accum) in the port. The target has 40bit registers which
is a GPR and works as 32bit reg in other modes. The load and store for
_Accum happens in two step.
Az üzenet címzettje: József Czibere
Azért kapja ezt az e-mail, mert rajta van az Eurorest Akciók korábbi
résztvevőinek listáján.
---
Üdvözöljük József!
Olvassa el ezt az üzenetet, és tudja meg, hogy még az idén eltölthet
további 3 hétvégét a
Hello all,
I am doing a port for a 32bit target in GCC 4.4.0. I have to support a
40bit data (_Accum) in the port. The target has 40bit registers which
is a GPR and works as 32bit reg in other modes. The load and store for
_Accum happens in two step. The lower 32bit in one instruction and the
uppe
Hi all,
I am doing a GCC port for a 32bit target in GCC 4.4.0. The target uses
hand coded floating point compare routines. Generally the function
returns the values in the general purpose registers. But these fp cmp
routines return the result in the Status Register itself. So there is
no need to
On 09/14/2009 02:13 PM, Ryan Mansfield wrote:
Paolo Bonzini wrote:
4) some might fall under 2 or 3. Actually just one; he used to be at
QNX, couldn't find any data after 2005 on qnx.com but I'm CCing him:
> gp (Graeme Peterson ) 2003-08-06 3
Graeme left QNX back in 2006. He removed himself fr
Paolo Bonzini wrote:
4) some might fall under 2 or 3. Actually just one; he used to be at
QNX, couldn't find any data after 2005 on qnx.com but I'm CCing him:
>gp (Graeme Peterson )2003-08-063
Graeme left QNX back in 2006. He removed himself from the MAINTAI
On Mon, Sep 14, 2009 at 3:52 AM, John David Anglin
wrote:
> Hi Martin,
>
>> Having said that, if anybody has problems with this patch going in,
>> please speak out now rather than later.
>
> I very much appreciate the work you have done on this problem. However,
> the patch doesn't work as expect
On Mon, Sep 14, 2009 at 3:18 AM, Gary Funck wrote:
>
> Recently, we have been working on upgrading GCC/UPC (see
> http://gccupc.org) to the GCC trunk. Previously,
> we've sync'ed with the latest stable release, but
> now we want to stay more current.
>
> When built with GCC versions 4.0 through 4
Hi,
Do you have news regarding this?
Thanks
Sébastien
-- Forwarded message --
From: Sébastien Bourdeauducq
Date: Tue, 8 Sep 2009 20:46:01 +0200
Subject: LatticeMico32 support in GCC 4.5
To: g...@gnu.org
Hi,
Would you mind including support for the LatticeMico32 soft processor
18 matches
Mail list logo
