> Are rpaths as portable as shared libraries or do we support a host
> architecture that has shared libraries but no equivalent to rpath?
Windows (mingw) comes to mind at least.
Arno
On Wed, Dec 02, 2009 at 11:08:49PM +0100, Richard Guenther wrote:
> On Wed, 2 Dec 2009, Ralf Wildenhues wrote:
>
> > Hello Richard,
> >
> > * Richard Guenther wrote on Wed, Dec 02, 2...@01:32:24PM CET:
> > > The trunk is in regression and documentation fixes only mode,
> > > Stage 3 has ended yes
On 12/02/2009 02:46 PM, Matt Turner wrote:
Hi,
Could someone please take a look at these two bugs?
27468 - sign-extending Alpha instructions not exploited
27469 - zero extension not eliminated [on Alpha]
Andrew Pinski has confirmed both of them three and a half years ago.
My uninformed feeling
Hi,
Could someone please take a look at these two bugs?
27468 - sign-extending Alpha instructions not exploited
27469 - zero extension not eliminated [on Alpha]
Andrew Pinski has confirmed both of them three and a half years ago.
My uninformed feeling after seeing bugs 8603 and 42113 fixed is tha
2009/11/29 Basile STARYNKEVITCH :
> Hello All,
>
> I believe there are several plugin issues to fix before 4.5 releases:
>
> 1. use of libiberty from plugins.
>
> As several patches recently sent demonstrated, the current state of the
> trunk does not work with plugins calling some of the libibert
On Wed, 2 Dec 2009, Ralf Wildenhues wrote:
> Hello Richard,
>
> * Richard Guenther wrote on Wed, Dec 02, 2009 at 01:32:24PM CET:
> > The trunk is in regression and documentation fixes only mode,
> > Stage 3 has ended yesterday. Release branch rules are now
> > in effect for all changes to trunk
I think I would stop right there. Why can't the i370 port support
64-bit integers? Plenty of 32-bit hosts support them.
It got an internal error. I don't have the skills to get that to work,
but I do have the skills to bypass it one way or another (and I
demonstrated what I am doing now, but
Hello Richard,
* Richard Guenther wrote on Wed, Dec 02, 2009 at 01:32:24PM CET:
> The trunk is in regression and documentation fixes only mode,
> Stage 3 has ended yesterday. Release branch rules are now
> in effect for all changes to trunk that touch release critical
> parts of the compiler (pri
Jeff Law wrote:
> Ian Bolton wrote:
> > Initial results showed that IRA was moving input arguments out of
> their
> > BOTTOM_REGS (e.g. $c1) into TOP_CREGS to do work on them, since it
> > thought TOP_CREGS were less costly to use, despite the cost of the
> move
> > instruction to get the input ar
On 12/02/09 05:29, daniel tian wrote:
Hi,
Addition information, I just found. It was deleted in function: void
set_insn_deleted (rtx insn), in emit-rtl.c.
It is called by reload() in reload1.c.
Here is the code in reload():
/* If a pseudo has no hard reg, delete the insns that made the
daniel tian writes:
> Addition information, I just found. It was deleted in function: void
> set_insn_deleted (rtx insn), in emit-rtl.c.
You need to figure out how register 42 in the call insn got changed to
register 0 if reg_renumber[42] was not set to 0.
Ian
Status
==
The trunk is in regression and documentation fixes only mode,
Stage 3 has ended yesterday. Release branch rules are now
in effect for all changes to trunk that touch release critical
parts of the compiler (primary and secondary targets, C and
C++ and their runtimes).
There will be
Hi,
Addition information, I just found. It was deleted in function: void
set_insn_deleted (rtx insn), in emit-rtl.c.
It is called by reload() in reload1.c.
Here is the code in reload():
/* If a pseudo has no hard reg, delete the insns that made the equivalence.
If that insn didn't set t
Hi,
I met a bug in my gcc porting. It work fine when executing with -O0.
But with -Os, there is a insn missed. I dumped the RTL and checked them.
When in movebug.c.175r.lreg, it is fine. But in next phase --
movebug.c.176r.greg, the insn missed.
Here is the simple c program (movebu
14 matches
Mail list logo
