Hi Vladimir,
Firstly, thanks for looking into this.
> Analysis of 187.facerec problem was actually easier than applu one.
> It has one very hot (80%) function localmove::graphRoutines.f90 and
> there is only one hot loop in the function. Although the loop is
> pretty big because of inlining To
On Fri, 12 Sep 2008, Cary Coutant wrote:
> There are a couple of failures in the gdb test suite on i386 and
> x86_64 with gcc 4.3.0 or newer. The tests gdb.base/break.exp and
> gdb.base/sepdebug.exp are failing with a function begins with a while
> loop. The into_cfg_layout_mode pass was added in
There are a couple of failures in the gdb test suite on i386 and
x86_64 with gcc 4.3.0 or newer. The tests gdb.base/break.exp and
gdb.base/sepdebug.exp are failing with a function begins with a while
loop. The into_cfg_layout_mode pass was added in 4.3.0 (see
http://gcc.gnu.org/ml/gcc-patches/2007-
Hi to group. New source of yu tube.
http://videos.videosextube2009.com/yu-tube.html
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Miami Couples" group.
To post to this group, send email to Miami-Couples@googlegrou
Eric Botcazou <[EMAIL PROTECTED]> writes:
>> Applying the patch Adam created and posted in the message below resolved
>> the issue and the compiler successfully bootstrapped:
>>
>> http://gcc.gnu.org/ml/gcc/2008-09/msg00139.html
>
> Thanks for reporting this. I now can close PR 37424.
>
>> There w
Vladimir Makarov wrote:
Luis Machado wrote:
Upon further investigation on facerec's regression, it looks like the
code generated by the IRA-enabled gcc has many more spills than the one
with a disabled IRA, twice or sometimes three times more.
I'm trying to reduce the testcase a bit further so
MPFR 2.3.2 is now available for download from the MPFR web site:
http://www.mpfr.org/mpfr-2.3.2/
Thanks very much to those who sent us bug reports and/or tested
the release candidate.
The MD5's:
e02dff02dbcc813572395f20a89c4d96 mpfr-2.3.2.tar.lzma
527147c097874340cb9cee0579dacf3b mpfr-2.3.2.
> Even with the patch listed in the bug report below my bootstrap would
> still fail when the compiler tries to build libgcc.
>
> The bug report for the bootstrap failure is here:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37424
That patch is not the fix, this is explained in the audit trail.
Hi.
Even with the patch listed in the bug report below my bootstrap would
still fail when the compiler tries to build libgcc.
The bug report for the bootstrap failure is here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37424
The build failed while building libgcc - the code would trip up on an
DJ Delorie wrote:
Opening this up to the gcc public, since I appear to be unable to get
this to work right.
Still no luck defining a working IRA_COVER_CLASSES for m32c. My
latest attempt:
#define IRA_COVER_CLASSES \
{ \
HC_REGS, MEM_REGS, LIM_REG_CLASSES\
}
[ ... ]
I actually got a
> Sure, DJ. I'll look at this but unfortunately I can do it on next week
> because I am busy with numerous other IRA bugs.
Next week would be fine :-)
> As I wrote m32c is pretty nasty case and may be will need even insn
> description changes.
I'm OK with that.
DJ Delorie wrote:
Opening this up to the gcc public, since I appear to be unable to get
this to work right.
Still no luck defining a working IRA_COVER_CLASSES for m32c. My
latest attempt:
#define IRA_COVER_CLASSES \
{ \
HC_REGS, MEM_REGS, LIM_REG_CLASSES\
}
(effectively GENERAL_REGS (w
I'm trying to build a mips-elf toolchain hosted on Windows using
Linux as the build machine but I'm running into the following error:
mips-elf-gcc -nostdinc -isystem /tmp/gccbuild/build/gcc/./gcc/include
-B/tmp/gccbuild/build/gcc/mips-elf/newlib/ -isystem
/tmp/gccbuild/build/gcc/mips-elf/newlib/
Thomas A.M. Bernard wrote:
> Well I found another way to solve the problem by updating the dce for
> not taking out my instructions.
>
> I inserted "setallocate" as a native operator in the back-end which
> comes from a GIMPLE node and map to the RTL pattern. Earlier in the
> discussion, it's been
Well I found another way to solve the problem by updating the dce for
not taking out my instructions.
I inserted "setallocate" as a native operator in the back-end which
comes from a GIMPLE node and map to the RTL pattern. Earlier in the
discussion, it's been discussed that the dce was taking
> I think our mxp is more 'interesting'. [snip]
I think it's more like 'insane', :-) and a miracle that a retargetable
compiler can be ported to it.
Paolo
As I've said before, m32c is probably a "worst case" scenario for gcc
as it has not one, not two, not even three, but FOUR different types
of registers (8/16 bit general, 16 bit only general, 24 bit address
registers, and control (incl $fp) registers), and only a small number
(2) of each.
I think
DJ Delorie wrote:
Opening this up to the gcc public, since I appear to be unable to get
this to work right.
Still no luck defining a working IRA_COVER_CLASSES for m32c. My
latest attempt:
#define IRA_COVER_CLASSES \
{ \
HC_REGS, MEM_REGS, LIM_REG_CLASSES\
}
(effectively GENERAL_REGS (w
18 matches
Mail list logo
