2009/12/6 Frédéric L. W. Meunier :
> Will there be a 4.3.5 release ?
>
> Looking at http://gcc.gnu.org/ml/gcc/2009-08/msg00066.html , yes, but 4.4.2
> was released almost two months ago.
I expect so.
Richard.
Well I have good news to report.
I applied most of your recommended changes, but it still crashed,
still at the same spot:
:0: internal compiler error: Segmentation fault
However, I managed to track it down to some floating point stuff
in the i370 code, and got rid of that, and now I can compil
Jeff Law wrote:
> >
> > I had an epiphany this morning and came up with an idea to achieve
> the
> > lookahead I thought I needed, thereby making the costs created by '?'
> a
> > lot more concrete and reliable.
> >
> > Firstly, I have altered the alt_cost adjustment (for '?') in ira-
> costs.c,
> >
Hi,
x86-64 psABI says _Bool has 1 byte and aligned at 1 byte. It also says:
---
When a value of type _Bool is passed in a register or on the stack,
the upper 63 bits of the eightbyte shall be zero.
---
However, gcc treats _Bool as char:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324
Given
On 12/07/2009 10:33 AM, H.J. Lu wrote:
> Hi,
>
>
> x86-64 psABI says _Bool has 1 byte and aligned at 1 byte. It also says:
>
> ---
> When a value of type _Bool is passed in a register or on the stack,
> the upper 63 bits of the eightbyte shall be zero.
> ---
>
> However, gcc treats _Bool as cha
On 12/07/2009 10:33 AM, H.J. Lu wrote:
> Hi,
>
>
> x86-64 psABI says _Bool has 1 byte and aligned at 1 byte. It also says:
>
> ---
> When a value of type _Bool is passed in a register or on the stack,
> the upper 63 bits of the eightbyte shall be zero.
> ---
>
> However, gcc treats _Bool as cha
Hi -
Please be aware of an impending temporary outage machines hosting
gcc.gnu.org, sourceware.org, sources.redhat.com, cygwin.com, and a few
other sites. All email, web, ftp, cvs, git, etc. services will be off
line while the machines are being moved between two colocation
facilities this coming
Note that the m32c port uses PSImode, so it may offer some suggestions
as example code.
Hi,
It seems that many current uses of list::merge( ) fail to compile
with -std=c++0x, but I don't see a bug in bugzilla for this. Itseems to
result from:
list<_Tp, _Alloc>::
#ifdef __GXX_EXPERIMENTAL_CXX0X__
merge(list&& __x)
#else
merge(list& __x)
#endif
For c++0x, don't we need BOTH vers
On 12/06/09 20:10, daniel tian wrote:
You might start by monitoring emit_reload_insns's behavior when it handles
your insn.
I just debug the source code with your advice. Check the function
emit_reload_insns.
That insn was deleted before entering funcion emit_reload_insns. It
was deleted
> Note that the m32c port uses PSImode, so it may offer some suggestions
> as example code.
Yes, that's right, but the m32c port uses it as a mode for pointers,
while I'm trying to do it with scalars.
Anyway, thank you very much.
Hi Jeff:
I have already fixed the bug. this occurs due to register
allocation failed in function global_alloc. After calling the
find_reg(), the reg_renumber still keep the value -1 in it. So the
reload() in reload1.c delete the insns.
I didn't set any call saved registers which means ever
12 matches
Mail list logo
