On Jan 28, 2006, at 10:22 AM, Carlos Barros wrote:
anyone can explain me this??
Wrong list, you might try gcc-help, otherwise you can find the
answers in the source code to the compiler, if you wish to dig into
it. In short, gcc has lots of latitude to do just about anything it
wants wit
> "Adam" == Adam Megacz <[EMAIL PROTECTED]> writes:
>> I think our technical approach should be to have ecj emit class files,
>> which would then be compiled by jc1. In particular I think we could
>> change ecj to emit a single .jar file.
Adam> I (and David Crawshaw) have actually done this
I have fixed the svn-mailer bug that would cause large diffs of
configure, et al to be sent to both gcc-cvs, and bug reports, when a
property changed.
Sorry bout that.
(I also fixed the bug that caused it to send these things to a large
number of bug reports. Regexp was a little too loose).
Tom Tromey wrote:
While investigating I realized that we would also lose a small
optimization related to String "+" operations. When translating from
.java we currently use a non-synchronizing variant of StringBuffer to
do this.
In Java-5-mode I would expect ecj to use the unsynchronized
java.
Daniel Berlin wrote:
We already update life info way too much, even without struct-equiv
(Before struct equiv, this was done because flow's dce relied on
register liveness, and we called it from everywhere under the sun,
usually deep within other functions nobody realized were doing it). I
can t
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> Tom Tromey wrote:
>> While investigating I realized that we would also lose a small
>> optimization related to String "+" operations. When translating from
>> .java we currently use a non-synchronizing variant of StringBuffer to
>> do th
Tom Tromey wrote:
"Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> Tom Tromey wrote:
While investigating I realized that we would also lose a small
optimization related to String "+" operations. When translating from
.java we currently use a non-synchronizing variant of StringBuffer to
Joern RENNECKE wrote:
Because the new code as of December actually updated life information
incorrectly, the global updates that were done had also quite a lot of
work to do (and didn't really do it right, because of the presence of
fake edges).
Could you elaborate on the problem with fake e
Hi all,
In reply to an earlier posting this month, from:
From: Michal Dovciak
To: gcc at gcc dot gnu dot org
Date: Thu, 05 Jan 2006 16:41:10 +0100
Subject: Successful built of 3.4.5, failing gctest from testsuite
A colleague (CC'd, not subscribed) experienced the same problem, described
Sounds like /bin/sh puked...What shell was that GCC configured with?
P.S. That looks to be a boehm-gc test that failed...which really
doesn't matter much (from an end-user perspective) unless you use GCJ...
David Fang wrote:
Hi all,
In reply to an earlier posting this month, from:
Bernd Schmidt <[EMAIL PROTECTED]> writes:
> Let me ask a really stupid question. Where are we supposed to be
> clearing BB_DIRTY flags?
>
> I instrumented the old version of the struct-equiv patches to give me
> some information about the basic blocks it's being called for, and
> noticed that bl
> Sounds like /bin/sh puked...What shell was that GCC configured with?
> P.S. That looks to be a boehm-gc test that failed...which really
> doesn't matter much (from an end-user perspective) unless you use GCJ...
Hi,
On the contrary, it wasn't /bin/sh that died, it was gcc that
seg-faulte
12 matches
Mail list logo
