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 ../..
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
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
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
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
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
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.
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
> 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
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
> 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
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
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
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.
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
> 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
) 4.3.0 20070702 : 0m11.805s
[1]:
http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-2-0.html
Uros.
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.
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
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
-- 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
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.
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
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
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
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
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
27 matches
Mail list logo
