Where have all the conditional moves gone?
Hello, I have disassembled my program produced by g++ 4.0.0 and I see a very strange behaviour -- the compiler doesn't generate cmov-s (-O3 -march=pentium3). G++ 3.4 generates them. So, how can I reactivate cmov-s in the newest version of the compiler? fif-conversion doesn't work... Best regards Piotr Wyderski
Re: how to compile gcc
On Friday 19 August 2005 20:26, Jiang Long wrote: > Hello, > > I 'd like to dig into gcc internals, and would like to compile it with -g. > > I can't find any document on how to do that? I tried > > make BOOT_CFLAGS=-g CFLAGS=-g, > > but it still will add '-O2' later on. > > Any documentation on how GCC is compiled? what are the stages of the > compilation? yes, http://gcc.gnu.org/install/configure.html look at --enable-checking and http://gcc.gnu.org/install/build.html There are more cflags... The gcc/Makefile.in is also a good reference :) > Thanks, > > -Jiang Rafael pgpJvr4GvqxLD.pgp Description: PGP signature
Re: how to compile gcc
If you are objective is to debug gcc, then all the necessary setup is already done...Check this documentation http://gcc.gnu.org/wiki/DebuggingGCC. dz On 8/20/05, Rafael Ávila de Espíndola <[EMAIL PROTECTED]> wrote: > On Friday 19 August 2005 20:26, Jiang Long wrote: > > Hello, > > > > I 'd like to dig into gcc internals, and would like to compile it with -g. > > > > I can't find any document on how to do that? I tried > > > > make BOOT_CFLAGS=-g CFLAGS=-g, > > > > but it still will add '-O2' later on. > > > > Any documentation on how GCC is compiled? what are the stages of the > > compilation? > yes, > http://gcc.gnu.org/install/configure.html > look at --enable-checking > and > http://gcc.gnu.org/install/build.html > There are more cflags... > > The gcc/Makefile.in is also a good reference :) > > > Thanks, > > > > -Jiang > > > Rafael > > >
Re: how to compile gcc
On Friday, August 19, 2005, at 04:26 PM, Jiang Long wrote: I 'd like to dig into gcc internals, and would like to compile it with -g. cd /gcc && make cc1 is another way to do it.
Help with Dependency question
Hi,
For this simple loop, I get the following distance and direction vector
Distance {1,-1)
Direction (2,0)
for(J = 1; J <= N-1; J++)
for(I = 1; I <= N-1; I++)
{
XX = X[I+1][J];
XY = X[I][J+1];
}
Can some body explain why thats so ?
thanks
Shreyas
Problem with instrumenting GIMPLE for adding a global variable
Hi,
I am trying to implement a prototype pass that instruments a function
to check for safe memory accesses. As a starting point I looked at
mudflap1 pass, in tree-mudflap.c and decided that I should write a
dummy pass ( very simple, but similar to mudflap) that instruments the
code to count the number of functions in the source file.
I am unable to add a global variable in the file scope. The global
VAR_DECL building function looks like this:
{
tree decl = build_decl (VAR_DECL, get_identifier ("my_var"),
integer_type_node);
TREE_PUBLIC (decl) = 0;
DECL_EXTERNAL (decl) = 0;
TREE_STATIC (decl) = 1;
gimplify_stmt (my_variable);
lang_hooks.decls.pushdecl (decl);
return decl;
}
It is called from within my call-back function "execute_my_pass" ( as
specified by me in the tree_opt_pass structure ).
I increment "my_var" in every function. But, the instrumented object
file doesnot have a storage allocated for this variable in the .data
section. The problem is that DECL_CONTEXT of this VAR_DECL is always
getting assigned to a function, and not to global file scope. Why is
that?
Any help would be appreciated.
Thanks,
Prateek.
Re: Problem with instrumenting GIMPLE for adding a global variable
Sorry, my mistake. I initialized it with a value, and it appeared in
the .data. :)
> Hi,
>
> I am trying to implement a prototype pass that instruments a function
> to check for safe memory accesses. As a starting point I looked at
> mudflap1 pass, in tree-mudflap.c and decided that I should write a
> dummy pass ( very simple, but similar to mudflap) that instruments the
> code to count the number of functions in the source file.
>
> I am unable to add a global variable in the file scope. The global
> VAR_DECL building function looks like this:
>
> {
> tree decl = build_decl (VAR_DECL, get_identifier ("my_var"),
> integer_type_node);
> TREE_PUBLIC (decl) = 0;
> DECL_EXTERNAL (decl) = 0;
> TREE_STATIC (decl) = 1;
> gimplify_stmt (my_variable);
> lang_hooks.decls.pushdecl (decl);
> return decl;
> }
>
> It is called from within my call-back function "execute_my_pass" ( as
> specified by me in the tree_opt_pass structure ).
>
> I increment "my_var" in every function. But, the instrumented object
> file doesnot have a storage allocated for this variable in the .data
> section. The problem is that DECL_CONTEXT of this VAR_DECL is always
> getting assigned to a function, and not to global file scope. Why is
> that?
>
> Any help would be appreciated.
>
> Thanks,
> Prateek.
Re: Bootstrap failure on powerpc-apple-darwin8 with Ada
On Fri, Aug 19, 2005 at 09:34:35PM -0400, Daniel Berlin wrote: > But for general IPA working on the cgraph + GIMPLE level, as is what is > happening here, I think we really need to do something about static > variable initializers so they are in GIMPLE. No. How could that possibly be? We can't execute code for static variable initializers, so how can we gimplify? > Or do you have another idea? You didn't say why analyze_expr was wrong. I still think it's right. r~
Re: Bootstrap failure on powerpc-apple-darwin8 with Ada
On Sat, 2005-08-20 at 19:15 -0700, Richard Henderson wrote:
> On Fri, Aug 19, 2005 at 09:34:35PM -0400, Daniel Berlin wrote:
> > But for general IPA working on the cgraph + GIMPLE level, as is what is
> > happening here, I think we really need to do something about static
> > variable initializers so they are in GIMPLE.
>
> No. How could that possibly be?
> We can't execute code for static
> variable initializers, so how can we gimplify?
What do you mean by this, exactly?
>
> > Or do you have another idea?
>
> You didn't say why analyze_expr was wrong. I still think it's right.
Because analyze_expr doesn't give us any of the info we want.
The call that was failing in our case was a get_base_var of an
ADDR_EXPR in a static variable initial, called from static
variable address taken analysis.
analyze_expr would not help here.
The docs for analyze_expr says:
This function is responsible for lowering tree nodes not
understood by
generic code into understandable ones or alternatively marking
callgraph and varpool nodes referenced by the as needed.
It's the "alternatively" part that makes it useless.
cxx_callgraph_analyze_expr, an implementation of this hook, simply marks
a bunch of varpool nodes as "used" (and it doesn't even tell us which
ones).
We don't care to know whether or not it should be marked used.
We want to know what's actually in the trees on the initializer them so
we can do analysis.
IE if we have something very funky like:
static int c;
static int d;
static struct foo *a = &{&c, &d};
(and if you look, andrew found a case where we are producing
&, so this is a possibility, AFAICT)
In the above case, we need to see the &c, &d part.
How does analyze_expr help us here?
>
> r~
Building of fixincludes with 4.0.1 uses wrong gcc
Dear Sirs, 1. bootstrapping the gcc 4.0.1 under Sparc/Solaris I found that the building in "fixincludes" uses the gcc (with no PATH specification) instead of the xgcc build by the last stage. It may crash, it happens on my environment, because I've migrated from Solaris 9 to Solaris 10 where the includes are not compatible. The build is: > gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/configure --prefix=/usr/local/GCC/4.0/1/Solaris --with-mpfr=/usr/local/Maths/Gmp --with-gmp=/usr/local/Maths/Gmp --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-languages=c,ada --enable-threads=solaris Thread model: solaris gcc version 4.0.1 2. A question: The gcc 4.0 uses the built-in specs. Is it correct, that a "specs" file will not be used as in the 2.x and 3.x versions of the gcc? With regards Michael Foerster make[1]: Entering directory `/usr/usr/ready/gnu/tmp/GCC/4.0.1/Sol10/gcc' rm -f .bad_compare case "fastcompare" in *compare | *compare-lean ) stage=2 ;; * ) stage=`echo fastcompare | sed -e 's,^[a-z]*compare\([0-9][0-9]*\).*,\1 ,'` ;; esac; \ for dir in . ada build; do \ if [ "`echo $dir/*.o`" != "$dir/*.o" ] ; then \ for file in $dir/*.o; do \ case "fastcompare" in \ slowcompare* ) \ tail +16c ./$file > tmp-foo1; \ tail +16c stage$stage/$file > tmp-foo2 \ && (cmp tmp-foo1 tmp-foo2 > /dev/null 2>&1 || echo $file differs >> .bad_compare) || true; \ ;; \ fastcompare* ) \ cmp $file stage$stage/$file 16 16 > /dev/null 2>&1; \ test $? -eq 1 && echo $file differs >> .bad_compare || true; \ ;; \ gnucompare* ) \ cmp --ignore-initial=16 $file stage$stage/$file > /dev/null 2>&1; \ test $? -eq 1 && echo $file differs >> .bad_compare || true; \ ;; \ esac ; \ done; \ else true; fi; \ done rm -f tmp-foo* case "fastcompare" in *compare | *compare-lean ) stage=2 ;; * ) stage=`echo fastcompare | sed -e 's,^[a-z]*compare\([0-9][0-9]*\).*,\1 ,'` ;; esac; \ if [ -f .bad_compare ]; then \ echo "Bootstrap comparison failure!"; \ cat .bad_compare; \ exit 1; \ else \ case "fastcompare" in \ *-lean ) rm -rf stage$stage ;; \ *) ;; \ esac; true; \ fi make[1]: Leaving directory `/usr/usr/ready/gnu/tmp/GCC/4.0.1/Sol10/gcc' Building runtime libraries make[1]: Entering directory `/usr/usr/ready/gnu/tmp/GCC/4.0.1/Sol10' make[2]: Entering directory `/usr/usr/ready/gnu/tmp/GCC/4.0.1/Sol10/libiberty' make[3]: Entering directory `/usr/usr/ready/gnu/tmp/GCC/4.0.1/Sol10/libiberty/testsuite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/usr/usr/ready/gnu/tmp/GCC/4.0.1/Sol10/libiberty/testsuite' make[2]: Leaving directory `/usr/usr/ready/gnu/tmp/GCC/4.0.1/Sol10/libiberty' make[2]: Entering directory `/usr/usr/ready/gnu/tmp/GCC/4.0.1/Sol10/fixincludes' gcc -c -g -O2 -DHAVE_CONFIG_H -I. -I/usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes -I../include -I/usr/usr/ready/gnu/tmp/GCC/ 4.0.1/gcc-4.0.1/fixincludes/../include /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/fixincl.c In file included from /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/system.h:226, from /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/fixlib.h:30, from /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/fixincl.c:24: /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/../include/libiberty.h:118: warning: `__sentinel__' attribute directive ignored /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/../include/libiberty.h:127: warning: `__sentinel__' attribute directive ignored /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/../include/libiberty.h:133: warning: `__sentinel__' attribute directive ignored /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/../include/libiberty.h:140: warning: `__sentinel__' attribute directive ignored /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/../include/libiberty.h:147: warning: `__sentinel__' attribute directive ignored In file included from /usr/local/GCC/3.5-ex/bin/../lib/gcc/sparc-sun-solaris2.9/3.5.0/include/sys/signal.h:44, from /usr/include/signal.h:26, from /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/fixlib.h:31, from /usr/usr/ready/gnu/tmp/GCC/4.0.1/gcc-4.0.1/fixincludes/fixincl.c:24:
