On 7/2/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
> I'm curious if it was the pre/fre changes. can you try -fno-tree-pre
> and -fno-tree-fre and see if it slows down again?
Adding -fno-tree-pre slows aermod back to 33.942s. Nice optimization. ;)
Thanks.
(You really should t
The release of MPFR 2.3.0 is imminent. Please help to make this
release as good as possible by downloading and testing this
release candidate:
http://www.mpfr.org/mpfr-2.3.0/mpfr-2.3.0-rc1.tar.bz2
http://www.mpfr.org/mpfr-2.3.0/mpfr-2.3.0-rc1.tar.gz
http://www.mpfr.org/mpfr-2.3.0/mpfr-2.3.0-rc1.zi
Hi,
just an heads-up: today 27_io/basic_stringbuf/setbuf/char/4.cc (and the
wchar_t counterpart) started failing at compile-time at least on x86 and
x86_64: at -O2 the compiler eats all the available memory.
You can see the issue reported here, for example:
http://gcc.gnu.org/ml/gcc-testre
Snapshot gcc-4.1-20070702 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070702/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Alinabi wrote:
Subject: sub-optimal code for packed boolean arrays in Ada -- bug or
inherent limitation
Certainly not a bug, the code generated is correct, it is just not
optimal. Surely it could be fixed if someone had the energy to do so.
I see no particular gain in filing a bug report, it i
On Jul 2, 2007, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-07-02 at 12:10 -0400, Kenneth Zadeck wrote:
>> I do not remember if it was stevenb or bonzini that observed that
>> because of changes that came with the dataflow branch it is now trivial
>> to get rid of no_new_pseudos.
-- Forwarded message --
From: Alinabi <[EMAIL PROTECTED]>
Date: Jul 2, 3:34 pm
Subject: sub-optimal code for packed boolean arrays in Ada -- bug or
inherent limitation
To: comp.lang.ada
Hello, everyone.
I am writing a chess program in Ada, using bitboards for position
represen
Daniel Berlin wrote:
I'm curious if it was the pre/fre changes. can you try -fno-tree-pre
and -fno-tree-fre and see if it slows down again?
Adding -fno-tree-pre slows aermod back to 33.942s. Nice optimization. ;)
BTW: I was looking if this speedup was due to yet uncommitted patch for
PR 32457
Hello,
The attached patch implements (partially) the first part of proposed
work: exporting and verification of data dependence information.
The implementation follows the outline presented in my initial message
on the project, here: http://gcc.gnu.org/ml/gcc/2007-03/msg00900.html
. Data refere
enchmark [1]. I can confirm this on
32bit nocona, and double-checked on 64bit core2:
gcc -O3 -funroll-loops -ftree-vectorize -ffast-math:
(GCC) 4.3.0 20070622 : 0m33.530s
(GCC) 4.3.0 20070702 : 0m11.805s
[1]:
http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-2-0.html
Uros.
) 4.3.0 20070702 : 0m11.805s
[1]:
http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-2-0.html
Uros.
> Kenneth Zadeck wrote:
> >I do not remember if it was stevenb or bonzini that observed that
> >because of changes that came with the dataflow branch it is now trivial
> >to get rid of no_new_pseudos.
>
> For the record, this was Steven's observation. And Kenner confirming
> that this was the or
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> There appears to be an idiom, (or at least a chunk of code that has been
> heavily copied) where *_output_mi_thunk sets reload_completed and
> no_new_pseudos at the top and clears them at the bottom.
>
> This appears to be the majority of the not triv
On Jul 2, 2007, at 2:48 AM, allozano wrote:
I need get the param type. For example
void f (std::string){...}
with Macros TYPE_NAME, TYPE_DECL,... i find the param is "string"
but I need "std::string"
Look for CONTEXT in *.h.
Richard Kenner wrote:
>> There are 199 uses of it in the backends; compared to 32 in the front
>> end.
>>
>> So it is quite heavily used by MD code.
>>
>
> That distinction shouldn't matter unless some of the MD code uses it instead
> of reload_completed, which is (unfortunately) a real possib
Kenneth Zadeck wrote:
I do not remember if it was stevenb or bonzini that observed that
because of changes that came with the dataflow branch it is now trivial
to get rid of no_new_pseudos.
For the record, this was Steven's observation. And Kenner confirming
that this was the original purpose
> There are 199 uses of it in the backends; compared to 32 in the front
> end.
>
> So it is quite heavily used by MD code.
That distinction shouldn't matter unless some of the MD code uses it instead
of reload_completed, which is (unfortunately) a real possibility.
So I fear those will have to b
On Mon, 2007-07-02 at 12:10 -0400, Kenneth Zadeck wrote:
> I do not remember if it was stevenb or bonzini that observed that
> because of changes that came with the dataflow branch it is now trivial
> to get rid of no_new_pseudos. All of the sets can just go away, as well
> as the tests of it that
> I believe that the original purpose of this was to protect certain
> datastructures that had to be resized manually when pseudos were added.
Correct.
> Does anyone think this is a bad idea? A grep for no_new_pseudos bears
> out that nothing is really going on here anymore.
Seems like a real
I do not remember if it was stevenb or bonzini that observed that
because of changes that came with the dataflow branch it is now trivial
to get rid of no_new_pseudos. All of the sets can just go away, as well
as the tests of it that occur in passes that only run before reload.
For those few pass
Hi,
I'm looking into a library issue and noticed that these lines:
-fmessage-length=n
Try to format error messages so that they fit on lines of
about n characters. The
default is 72 characters for g++ and 0 for the rest of the
front ends supported by
GCC.
On 7/2/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> So there we are. Any suggestions?
If I understand correctly, nested functions *are* what you want and
there is code to do exactly what you want in the implementation of OpenMP.
k, cool. Will look into it (mostly, though, I was *hoping* I wou
So there we are. Any suggestions?
If I understand correctly, nested functions *are* what you want and
there is code to do exactly what you want in the implementation of OpenMP.
However, I am not into that code enough to give you any further hint.
Paolo
Let's say I have a function that looks like this:
void a()
{
int n = x();
__try
{
y();
}
__finally
{
z(n);
w();
}
}
... assuming a hypothetical extension to C syntax that turns a __try {
... } __finally { ... } into the proper TRY_FINALLY_EXPR (maybe ju
On Mon, 2 Jul 2007, Rask Ingemann Lambertsen wrote:
>Soft-fp spews lots of warnings of this sort:
>
> /n/12/rask/src/all/libgcc/../gcc/config/soft-fp/floatuntitf.c: In function
> '__floatuntitf':
> /n/12/rask/src/all/libgcc/../gcc/config/soft-fp/floatuntitf.c:40: warning:
> comparison of un
I need get the param type. For example
void f (std::string){...}
with Macros TYPE_NAME, TYPE_DECL,... i find the param is "string" but I
need "std::string" for code generator.
I dont find the fields or macros in the files tree.h and cp/cp-tree.h
and don find information in google.
Thanks
Soft-fp spews lots of warnings of this sort:
/n/12/rask/src/all/libgcc/../gcc/config/soft-fp/floatuntitf.c: In function
'__floatuntitf':
/n/12/rask/src/all/libgcc/../gcc/config/soft-fp/floatuntitf.c:40: warning:
comparison of unsigned expression < 0 is always false
In file included from ../..
27 matches
Mail list logo
