> I thought I had sent you mail approving the changes 2 weeks ago.
> Perhaps I misremembered, or perhaps it got lost somewhere. All of
> my comments about the internals of the mep would be things to do if
> you desired, but as port maintainer, I don't see that we have to
> apply standards set for
Edward Peschko wrote:
> 3. ecj not part of the build, hence causing at runtime:
>
> ld.so.1: ecj1: fatal: libgcc_s.so.1: version `GCC_4.2.0' not
> found (required by file
> /userdata/ebay/interface/FI/tools/beta/lib/libgcj.so.10)
> ld.so.1: ecj1: fatal: libgcc_s.so.1: open f
On Wed, Jun 17, 2009 at 12:52:33AM -0400, DJ Delorie wrote:
>
> > Pending initial (technical) approval
>
> Ping? Still waiting for technical approval from a global maintainer.
>
> http://people.redhat.com/dj/mep/
I thought I had sent you mail approving the changes 2 weeks ago. Perhaps I
misre
Hi guys.
The last class of warning I have from the machine definition is this:
./config/i370/i370.md:784: warning: destination operand 0 allows non-lvalue
which is because I have used r_or_s_operand like this:
;
; movdi instruction pattern(s).
;
(define_insn ""
[(set (match_operand:DI 0 "r_o
On Thu, Jun 18, 2009 at 12:10:53PM -0400, NightStrike wrote:
> Given the recent issues with libffi being so drastically out of synch
> with upstream, I was curious about boehm-gc and how that is handled.
> In getting gcj to work on Win64, the next step is boehm-gc now that
> libffi works just fine.
All,
I'm just curious - what version of gcc has the latest stable gcj? I've
been trying to build gcc-4.4.0 on solaris and have been running into
multiple issues:
1. gperf (version 3.0.4) generates incorrect code killing the build:
../.././gcc/cp/cfns.gperf:84: error: 'gnu_inline'
Snapshot gcc-4.5-20090618 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090618/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Thu, Jun 18, 2009 at 5:25 PM, Hans Boehm wrote:
> What has been a problem is that while the 6.8 -> 7.0 changes cleaned
> up the code substantially, and a lot of contributed patches since then
> have done a lot more of that, that step also introduced a fair amount of
> instability. I think we're
Hi,
Hopeful, this release has all IFUNC bugs fixed.
Thanks.
H.J.
This is the beta release of binutils 2.19.51.0.10 for Linux, which is
based on binutils 2009 0618 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to th
On Thu, 18 Jun 2009, NightStrike wrote:
So it seems that boehm-gc is in the exact state as libffi.
This is yet another example of why we shouldn't duplicate sources...
Hans, would you be willing to bring boehm-gc up to speed so that we
can start getting it to work for Win64? Without this,
On Jun 18, 2009, Diego Novillo wrote:
> On Mon, Jun 8, 2009 at 17:03, Alexandre Oliva wrote:
>> For the measurements, I won't use the last merge, but rather the trunk
> Comparing trunk as of the last merge point is the easiest thing to do
> (just checkout trunk at the revision that you last merg
NightStrike wrote:
> On Thu, Jun 18, 2009 at 2:02 PM, Andrew Haley wrote:
>> NightStrike wrote:
>>> Given the recent issues with libffi being so drastically out of synch
>>> with upstream, I was curious about boehm-gc and how that is handled.
>>> In getting gcj to work on Win64, the next step is bo
On Thu, Jun 18, 2009 at 2:02 PM, Andrew Haley wrote:
> NightStrike wrote:
>> Given the recent issues with libffi being so drastically out of synch
>> with upstream, I was curious about boehm-gc and how that is handled.
>> In getting gcj to work on Win64, the next step is boehm-gc now that
>> libffi
On Thu, 18 Jun 2009, Diego Novillo wrote:
> Nice. Could you upload them to http://gcc.gnu.org/wiki/PerformanceTesting?
How about gcc/contrib?
Gerald
NightStrike wrote:
> Given the recent issues with libffi being so drastically out of synch
> with upstream, I was curious about boehm-gc and how that is handled.
> In getting gcj to work on Win64, the next step is boehm-gc now that
> libffi works just fine. However, the garbage collector is in ter
It seems that the problem comes from CALL instructions. If I remove
them then my code works. I have not figured out why my code would pose
a problem in the case of calls but I can work around that for the
moment.
If anyone has an idea why this is a problem, I'll integrate the change
into the code
NightStrike wrote:
On Thu, Jun 18, 2009 at 12:58 PM, Andrew Haley wrote:
NightStrike wrote:
On Thu, Jun 18, 2009 at 12:27 PM, David Daney wrote:
NightStrike wrote:
Given the recent issues with libffi being so drastically out of synch
with upstream, I was curious about boehm-gc and how that is
On Thu, Jun 18, 2009 at 12:58 PM, Andrew Haley wrote:
> NightStrike wrote:
>> On Thu, Jun 18, 2009 at 12:27 PM, David Daney
>> wrote:
>>> NightStrike wrote:
Given the recent issues with libffi being so drastically out of synch
with upstream, I was curious about boehm-gc and how that is h
Andrew Haley wrote:
NightStrike wrote:
On Thu, Jun 18, 2009 at 12:27 PM, David Daney wrote:
NightStrike wrote:
Given the recent issues with libffi being so drastically out of synch
with upstream, I was curious about boehm-gc and how that is handled.
In getting gcj to work on Win64, the next st
NightStrike wrote:
> On Thu, Jun 18, 2009 at 12:27 PM, David Daney
> wrote:
>> NightStrike wrote:
>>> Given the recent issues with libffi being so drastically out of synch
>>> with upstream, I was curious about boehm-gc and how that is handled.
>>> In getting gcj to work on Win64, the next step is
On Thu, Jun 18, 2009 at 12:27 PM, David Daney wrote:
> NightStrike wrote:
>>
>> Given the recent issues with libffi being so drastically out of synch
>> with upstream, I was curious about boehm-gc and how that is handled.
>> In getting gcj to work on Win64, the next step is boehm-gc now that
>> lib
I also notice a few remotes with @ in them like milepost-bra...@129596
which seem to be git-svn artifacts.
Jason
NightStrike wrote:
Given the recent issues with libffi being so drastically out of synch
with upstream, I was curious about boehm-gc and how that is handled.
In getting gcj to work on Win64, the next step is boehm-gc now that
libffi works just fine. However, the garbage collector is in terrible
Dear all,
I've been working on renaming registers using the DF framework but am
wondering if I'm doing things correctly. This is done in the REORG
pass because I need to ensure that I have consecutive registers for
loads in order to get a load multiple generated.
Basically, the beginning of the c
Given the recent issues with libffi being so drastically out of synch
with upstream, I was curious about boehm-gc and how that is handled.
In getting gcj to work on Win64, the next step is boehm-gc now that
libffi works just fine. However, the garbage collector is in terrible
shape and will need a
Hi folks.
Fold needs some serious surgery to make it location friendly. I'm
currently revamping the whole thing to take locations, so if you're
thinking of adding locations to any of the functions, please hold off
until I'm done, to avoid duplication of work as well as a conflict
nightmare.
Some
On Thu, Jun 18, 2009 at 08:31, Michael Matz wrote:
> The memory tester is based on the attached scripts, using strace for
> tracking, not polling on /proc output.
Nice. Could you upload them to http://gcc.gnu.org/wiki/PerformanceTesting?
Thanks. Diego.
Hello All
in gcc/plugin.c of trunk rev148566 function add_new_plguin line 147, I
am reading
/* If the same plugin (name) has been specified earlier, either emit an
error or a warning message depending on if they have identical full
(path) names. */
if (*slot)
{
plugin = (st
Hi,
On Thu, 18 Jun 2009, Paolo Bonzini wrote:
> > > - Memory consumption in cc1/cc1plus at -Ox -g over that set of apps.
>
> People usually just look at top's output, but Honza has a memory tester
> so I thought maybe you can script it... Indeed here is a script to do
> that
The memory teste
On Mon, Jun 8, 2009 at 17:03, Alexandre Oliva wrote:
> For the measurements, I won't use the last merge, but rather the trunk
Comparing trunk as of the last merge point is the easiest thing to do
(just checkout trunk at the revision that you last merged with the
branch). That's why I suggested t
Is there any pointers you might have?
What are the pros and cons I should be looking out for? Any info much
appreciated.
Thank you very much. John
- Memory consumption in cc1/cc1plus at -Ox -g over that set of apps.
Wouldn't this be expected to be strongly correlated with the above? Is
-fmem-report processed by mem-stats what you're after?
People usually just look at top's output, but Honza has a memory tester
so I thought maybe you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
seen on i686-pc-cygwin and x86_64-unknown-linux-gnu at least since revision
148309 and binutils HEAD from 6th of June.
Affected is the assembler. Here a part of the testsuite gas.sum on
i686-pc-cygwin:
Running
/home/rainer/software/src/binutils-cvs-
Hi,
Sorry that it's taking me so long to get back to you on this. I wanted
to finish a bunch of patches and check them in, then perform a merge,
before proceeding to the tests, so that the performance results could be
easily duplicated. This took longer than I'd anticipated.
On Jun 8, 2009, Di
34 matches
Mail list logo
