On Fri, Dec 14, 2007 at 02:47:02PM -0800, Doug Kwan (關振德) wrote:
> The new encoding format I am proposing fall between DW_ATE_lo_user and
> DW_ATE_hi_user. So they are vendor extensions. Currently gcc uses
> DW_ATE_lo_user, which collides with an HP vendor extension.
If we already have one vendor
> I've run a build for spec cpu2006 with -O3 -ftree-parallelize-loops=16
This is on amd64-linux.
Hi,
I've run a build for spec cpu2006 with -O3 -ftree-parallelize-loops=16
and interestingly there were some fails that I will investigate later.
So I'm just reporting these, and asking for somebody who could fix
the link options for autopar. I'm attaching a patch, not sure it will build.
Before
On 8 Dec 2007, Johannes Schindelin said:
> Hi,
>
> On Sat, 8 Dec 2007, J.C. Pizarro wrote:
>
>> On 2007/12/07, "Linus Torvalds" <[EMAIL PROTECTED]> wrote:
>>
>> > SHA1 is almost totally insignificant on x86. It hardly shows up. But
>> > we have a good optimized version there.
>>
>> If SHA1 is sl
Snapshot gcc-4.3-20071214 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20071214/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
The new encoding format I am proposing fall between DW_ATE_lo_user and
DW_ATE_hi_user. So they are vendor extensions. Currently gcc uses
DW_ATE_lo_user, which collides with an HP vendor extension.
-Doug
2007/12/14, Daniel Jacobowitz <[EMAIL PROTECTED]>:
> On Fri, Dec 14, 2007 at 02:30:36PM -0800
On Fri, Dec 14, 2007 at 02:30:36PM -0800, Doug Kwan (關振德) wrote:
> Is there anything I need to do in addition to changing gcc? Are
> there people I should talk to? And what documentation should be
> updated? Currently gdb (I checked 6.7) does not support complex
> integer properly. So it needs to
Hi,
I am working on the gcc LTO project and I found that gcc does not
generate sufficient debugging information for complex integer types.
Currently gcc uses encoding DW_ATE_lo_user ( 0x80) for complex integer
types but that 1) clashes with an HP extension and 2) does not
distinguish between c
Sebastian,
Here are (attached) results for testing HIRLAM with and without
-ftree-loop-linear.
As you can see, the results are neutral: 4 loops fewer vectorized, but
about 50 fewer recognized.
Now I like to redo that test with -ftree-loop-distribution. Can you
send me a patch against the
Laurent GUERBY wrote:
On Fri, 2007-12-14 at 14:45 -0600, Joel Sherrill wrote:
34400 is about slow compile but not about wrong code so I doubt it's the
issue. Could you send me privately the compressed log of the ACATS run?
Sure.
>From the log it looks like the reason f
On Fri, 2007-12-14 at 14:45 -0600, Joel Sherrill wrote:
> > 34400 is about slow compile but not about wrong code so I doubt it's the
> > issue. Could you send me privately the compressed log of the ACATS run?
> Sure.
>From the log it looks like the reason for most test FAIL is
because an expecte
Laurent GUERBY wrote:
On Fri, 2007-12-14 at 13:41 -0600, Joel Sherrill wrote:
Laurent GUERBY wrote:
ACATS is clean (0 FAIL) on trunk for x86. CXF3A03 is the
only FAIL for hppa-linux. c41328a is the only FAIL for powerpc64-linux.
cxb3014/16 are the only FAIL on ia64-linux.
You'll quickl
On Fri, 2007-12-14 at 13:41 -0600, Joel Sherrill wrote:
> Laurent GUERBY wrote:
> > ACATS is clean (0 FAIL) on trunk for x86. CXF3A03 is the
> > only FAIL for hppa-linux. c41328a is the only FAIL for powerpc64-linux.
> > cxb3014/16 are the only FAIL on ia64-linux.
> >
> > You'll quickly find up to
Laurent GUERBY wrote:
ACATS is clean (0 FAIL) on trunk for x86. CXF3A03 is the
only FAIL for hppa-linux. c41328a is the only FAIL for powerpc64-linux.
cxb3014/16 are the only FAIL on ia64-linux.
You'll quickly find up to date ACATS results here:
http://gcc.gnu.org/ml/gcc-testresults/2007-12/
ACATS is clean (0 FAIL) on trunk for x86. CXF3A03 is the
only FAIL for hppa-linux. c41328a is the only FAIL for powerpc64-linux.
cxb3014/16 are the only FAIL on ia64-linux.
You'll quickly find up to date ACATS results here:
http://gcc.gnu.org/ml/gcc-testresults/2007-12/
Laurent
On Fri, 2007-12-
Hi,
Even with the large gnat1 compile time issue, I
have managed to patiently run the ACATS on
powerpc-rtems. This configuration worked
well with gcc 4.2.2 (3 failures). I am seeing
lot of failures (total of 691) and they do not
appear to be RTEMS related.
Here is a sample. Do any of these lo
Hi,
> Uh what? Someone crank out his copy of "The Art of Computer
> Programming", I think volume 1. Best fit is known (analyzed and proven
> and documented decades ago) to be one of the worst strategies for memory
> allocation. Exactly because it leads to huge fragmentation problems.
Well, quo
Wolfram Gloger <[EMAIL PROTECTED]> writes:
> Hi,
>
>> Note that delta following involves patterns something like
>>
>>allocate (small) space for delta
>>for i in (1..depth) {
>> allocate large space for base
>> allocate large space for result
>> .. apply delta ..
>> fr
Hi,
> Maybe an malloc/free/mmap wrapper that records the requested sizes and
> alloc/free order and dumps them to file so that one can make a compact
> git-free standalone test case for the glibc maintainers might be a good
> thing.
I already have such a wrapper:
http://malloc.de/malloc/mtrace-2
Hi,
> Note that delta following involves patterns something like
>
>allocate (small) space for delta
>for i in (1..depth) {
> allocate large space for base
> allocate large space for result
> .. apply delta ..
> free large space for base
> free small space fo
Hi,
> >>if (progress->total) {
> >>unsigned percent = n * 100 / progress->total;
> >>if (percent != progress->last_percent || progress_update) {
> >> + struct mallinfo m = mallinfo();
> >>progress->last_percent = percent;
> >> -
Fan Zhang wrote:
> how to compile gcc4 on cygwin?
> thanks
The generic instructions are here http://gcc.gnu.org/install/
The mailing lists for asking questions are gcc-help
http://gcc.gnu.org/lists.html
and possibly http://cygwin.com/lists.html
You should be able to find useful hints on the archiv
On Fri, 14 Dec 2007, Paolo Bonzini wrote:
> > Hmmm... it is even documented in git-gc(1)... and git-index-pack(1) of
> > all things.
>
> I found that the .keep file is not transmitted over the network (at least I
> tried with git+ssh:// and http:// protocols), however.
That is a local policy.
On Dec 14, 2007 4:01 PM, Harvey Harrison <[EMAIL PROTECTED]> wrote:
> While it doesn't mark the packs as .keep, git will reuse all of the old
> deltas you got in the original clone, so you're not losing anything.
There is another reason I want it. I have an ~800MB pack and I don't
want git to rewr
"Nguyen Thai Ngoc Duy" <[EMAIL PROTECTED]> writes:
> On Dec 14, 2007 1:14 PM, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> > > Hmmm... it is even documented in git-gc(1)... and git-index-pack(1) of
> > > all things.
> >
> > I found that the .keep file is not transmitted over the network (at
> > leas
"Peter A. Felvegi" <[EMAIL PROTECTED]> writes:
> today i've run into this: if i cast a double value to an unsigned int
> using the C style cast when passing it to printf, it's fine. however, if
> i use the ctor style cast, i get a compile error.
This question is off-topic here, please use [EMAIL
On Fri, 2007-12-14 at 09:20 +0100, Paolo Bonzini wrote:
> > I'm thinking about "git clone --keep" to mark initial packs precious.
> > But 'git clone' is under rewrite to C. Let's wait until C rewrite is
> > done.
>
> It should be the default, IMHO.
>
While it doesn't mark the packs as .keep, git
I'm thinking about "git clone --keep" to mark initial packs precious.
But 'git clone' is under rewrite to C. Let's wait until C rewrite is
done.
It should be the default, IMHO.
Paolo
28 matches
Mail list logo
