Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
On Thu, 29 Oct 2009, Kaveh R. GHAZI wrote: > Please test this MPC package and report back the results of running > "make check" along with your target triplet, the compiler version you > used, and the versions of gmp/mpfr used to compile it. You do not > necessarily need to bootstrap mainline GCC with this MPC, but if you > have the spare time and cycles it would be nice too. === All 57 tests passed === i386-unknown-freebsd7.2 gcc version 4.2.1 20070719 [FreeBSD] mpfr-2.4.1_1 (FWIW, on FreeBSD I have made MPC a hard requirement for the GCC 4.5 port already. I assume the next steps on your side are waiting for the official releaes of MPC 0.8 and then making that a requirement for our configure scripts?) Gerald
Re: undefined reference to `gt_pch_nx_tree_code'
Hi, It's hard to tell. The normal definition of tree_code is enum in tree.h and it is an atomic type with respect GCC garbage collection. But the names like gt_gcc_mx_tree_code suggest that GCC internals try to treat it as a struct or some other non atomic type. Any chance that your source does not include tree.h and defines some tree_code type of its own? 2009/10/27 Aravinda : > Hi, > > I am writing a new pass for gcc that uses the GTY markers, > 1. I have included the source file in GTFILES_H in gcc/Makefile.in. > 2. I have the gt-path.h mentioned in the compilation for source file > 3. I have the #include "gt-path.h" at the very end of the code of source file. > > I see the gt-path.h is getting created in the build/gcc directory. But > I am getting the below error. Is there something I am missing in the > Makefile, I tried to look at a similar example of tree-mudflap.c that > uses GTY markers, I do not see any difference in the steps I have > followed. I havent done gcc dev before, so I'd really appreciate any > help in this regard. > > main.o tree-browser.o libbackend.a ../libcpp/libcpp.a > ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a > ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpfr -lgmp > -rdynamic -ldl > libbackend.a(gtype-desc.o): In function `gt_ggc_m_P9tree_code4htab': > /home/aravinda/svnbuild/gcc/gtype-desc.c:1968: undefined reference to > `gt_ggc_mx_tree_code' > libbackend.a(gtype-desc.o): In function `gt_pch_n_P9tree_code4htab': > /home/aravinda/svnbuild/gcc/gtype-desc.c:4133: undefined reference to > `gt_pch_nx_tree_code' > collect2: ld returned 1 exit status > make[3]: *** [cc1-dummy] Error 1 > Thanks, > Aravinda > -- Laurynas
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
"Kaveh R. GHAZI" wrote: > Please test this MPC package and report back the results of running > "make check" along with your target triplet, the compiler version you > used, and the versions of gmp/mpfr used to compile it. You do not > necessarily need to bootstrap mainline GCC with this MPC, but if you > have the spare time and cycles it would be nice too. === All 57 tests passed === sh4-unknown-linux-gnu gcc 4.2.4 gmp 4.2.2 mpfr 2.3.2 Regards, kaz
Re: undefined reference to `gt_pch_nx_tree_code'
Hi,
Thanks a lot for the reply. No, I am not using any specific tree_code
definitions and I have included tree.h in the pass file.
I dont know if some code will help, but, this is what I am doing
gcc-svn/gcc/tree-boud.c
...
static GTY(( is_param(union tree_code) )) htab_t boud_ins = NULL;
...
#include "gt-tree-boud.h"
The generated gt-tree-boud.h in the build/gcc directory looks like,
const struct ggc_root_tab gt_ggc_r_gt_tree_boud_h[] = {
{
&boud_ins,
1,
sizeof(boud_ins),
>_ggc_m_P9tree_code4htab,
>_pch_n_P9tree_code4htab
},
LAST_GGC_ROOT_TAB
};
The function `gt_pch_n_P9tree_code4htab' and
`gt_ggc_m_P9tree_code4htab' are defined in build/gcc/gtypes-desc.c
which references `gt_ggc_mx_tree_code'. And I dont know where this is
coming from, gtypes-desc only has an extern definition. Do you think I
need to include some library (which has its definition) in the
Makefile for compiling tree-boud.o ?
Thanks,
Aravinda
On Sun, Nov 1, 2009 at 3:27 PM, Laurynas Biveinis
wrote:
>
> Hi,
>
> It's hard to tell. The normal definition of tree_code is enum in
> tree.h and it is an atomic type with respect GCC garbage collection.
> But the names like gt_gcc_mx_tree_code suggest that GCC internals try
> to treat it as a struct or some other non atomic type. Any chance
> that your source does not include tree.h and defines some tree_code
> type of its own?
>
> 2009/10/27 Aravinda :
> > Hi,
> >
> > I am writing a new pass for gcc that uses the GTY markers,
> > 1. I have included the source file in GTFILES_H in gcc/Makefile.in.
> > 2. I have the gt-path.h mentioned in the compilation for source file
> > 3. I have the #include "gt-path.h" at the very end of the code of source
> > file.
> >
> > I see the gt-path.h is getting created in the build/gcc directory. But
> > I am getting the below error. Is there something I am missing in the
> > Makefile, I tried to look at a similar example of tree-mudflap.c that
> > uses GTY markers, I do not see any difference in the steps I have
> > followed. I havent done gcc dev before, so I'd really appreciate any
> > help in this regard.
> >
> > main.o tree-browser.o libbackend.a ../libcpp/libcpp.a
> > ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a
> > ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpfr -lgmp
> > -rdynamic -ldl
> > libbackend.a(gtype-desc.o): In function `gt_ggc_m_P9tree_code4htab':
> > /home/aravinda/svnbuild/gcc/gtype-desc.c:1968: undefined reference to
> > `gt_ggc_mx_tree_code'
> > libbackend.a(gtype-desc.o): In function `gt_pch_n_P9tree_code4htab':
> > /home/aravinda/svnbuild/gcc/gtype-desc.c:4133: undefined reference to
> > `gt_pch_nx_tree_code'
> > collect2: ld returned 1 exit status
> > make[3]: *** [cc1-dummy] Error 1
> > Thanks,
> > Aravinda
> >
>
>
>
> --
> Laurynas
Re: undefined reference to `gt_pch_nx_tree_code'
> static GTY(( is_param(union tree_code) )) htab_t boud_ins = NULL; Ah, now it's clear. You probably wanted "union tree_node" with n, not c, here. -- Laurynas
gcc-4.3-20091101 is now available
Snapshot gcc-4.3-20091101 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20091101/ 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/branches/gcc-4_3-branch revision 153796 You'll find: gcc-4.3-20091101.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20091101.tar.bz2 C front end and core compiler gcc-ada-4.3-20091101.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20091101.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20091101.tar.bz2 C++ front end and runtime gcc-java-4.3-20091101.tar.bz2 Java front end and runtime gcc-objc-4.3-20091101.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20091101.tar.bz2The GCC testsuite Diffs from 4.3-20091025 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Three old entries from PROBLEMS
At http://gcc.gnu.org/projects/#the_old_problems_file we have a short list coming from the GCC 2 PROBLEMS file. Instead of carrying this around forever, I am wondering whether we could quickly review these and either remove (as not applicable any longer) or move to Bugzilla? Possible special combination pattern: If the two operands to a comparison die there and both come from insns that are identical except for replacing one operand with the other, throw away those insns. Ok if insns being discarded are known 1 to 1. An andl #1 after a seq is 1 to 1, but how should compiler know that? Any number of slow zero-extensions in one loop, that have their clr insns moved out of the loop, can share one register if their original life spans are disjoint. But it may be hard to be sure of this since the life span data that regscan produces may be hard to interpret validly or may be incorrect after cse. In cse, when a bfext insn refers to a register, if the field corresponds to a halfword or a byte and the register is equivalent to a memory location, it would be possible to detect this and replace it with a simple memory reference. I'll be glad to take care of it, provided guidance from subject matter experts what to do about these three. Gerald
Re: Three old entries from PROBLEMS
Possible special combination pattern: If the two operands to a comparison die there and both come from insns that are identical except for replacing one operand with the other, throw away those insns. Ok if insns being discarded are known 1 to 1. An andl #1 after a seq is 1 to 1, but how should compiler know that? That would be: add r4, r1, r2 (or sub by inverting the compare operands, or xor if used in an equality/inequality comparison) add r5, r1, r3 cmp r4, r5 -> cmp r2, r3 We don't do this, but it doesn't seem hard to do on the tree level (e.g. in reassoc) or in combine for -fstrict-overflow. Nice trick, worth a Bugzilla entry IMO. I don't understand the last sentence. Any number of slow zero-extensions in one loop, that have their clr insns moved out of the loop, can share one register if their original life spans are disjoint. But it may be hard to be sure of this since the life span data that regscan produces may be hard to interpret validly or may be incorrect after cse. That would be: clr r7 clr r8 ... move strict-low-part(r7), r0 ... move strict-low-part(r8), r1 --> could reuse r7 This is not implemented but IMHO obsolete, most of the targets will just use an AND to implement zero extension. In cse, when a bfext insn refers to a register, if the field corresponds to a halfword or a byte and the register is equivalent to a memory location, it would be possible to detect this and replace it with a simple memory reference. I think we do this in combine now. Paolo
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
From: "Gerald Pfeifer" === All 57 tests passed === i386-unknown-freebsd7.2 gcc version 4.2.1 20070719 [FreeBSD] mpfr-2.4.1_1 (FWIW, on FreeBSD I have made MPC a hard requirement for the GCC 4.5 port already. I assume the next steps on your side are waiting for the official releaes of MPC 0.8 and then making that a requirement for our configure scripts?) Yes. There remains a few cleanups (see PR40302), but the heavy lifting is all done. --Kaveh
Re: Three old entries from PROBLEMS
Quoting Paolo Bonzini : Possible special combination pattern: If the two operands to a comparison die there and both come from insns that are identical except for replacing one operand with the other, throw away those insns. Ok if insns being discarded are known 1 to 1. An andl #1 after a seq is 1 to 1, but how should compiler know that? That would be: add r4, r1, r2 (or sub by inverting the compare operands, or xor if used in an equality/inequality comparison) add r5, r1, r3 cmp r4, r5 -> cmp r2, r3 We don't do this, but it doesn't seem hard to do on the tree level (e.g. in reassoc) or in combine for -fstrict-overflow. Nice trick, worth a Bugzilla entry IMO. This would only be valid if the comparison is in an equality context (or for special input operand ranges). So (unless the target is CC0) you'd either have to use dataflow analysis to look at all the contexts the comparison result is used in, or you'd need a target hook to classify CCmode modes to check if they are used only for equality comparisons and can have their inputs altered. I don't understand the last sentence. Any number of slow zero-extensions in one loop, that have their clr insns moved out of the loop, can share one register if their original life spans are disjoint. But it may be hard to be sure of this since the life span data that regscan produces may be hard to interpret validly or may be incorrect after cse. That would be: clr r7 clr r8 ... move strict-low-part(r7), r0 ... move strict-low-part(r8), r1 --> could reuse r7 This is not implemented but IMHO obsolete, most of the targets will just use an AND to implement zero extension. If the target can actually write to partial registers and refer to the entire register without undue delay, you won't need and zero_extend or AND operation at all. So this is obsolete only to the extent that such targets have become fewer / more arcane. FWIW the ARC mxp had that feature, but it doesn't look like that port will get into gcc mainline.
Re: Three old entries from PROBLEMS
Quoting Joern Rennecke : Quoting Paolo Bonzini : ... That would be: clr r7 clr r8 ... move strict-low-part(r7), r0 ... move strict-low-part(r8), r1 --> could reuse r7 This is not implemented but IMHO obsolete, most of the targets will just use an AND to implement zero extension. If the target can actually write to partial registers and refer to the entire register without undue delay, you won't need and zero_extend or AND operation at all. So this is obsolete only to the extent that such targets have become fewer / more arcane. FWIW the ARC mxp had that feature, but it doesn't look like that port will get into gcc mainline. P.S.: more common in contemporary targets is the availability of vector operations. In order to use these to save zero extensions, instead of the result register you need the inputs to be prepared with a zero highpart. E.g. to do a loop with an unsigned short biv, you zero-extend the initial biv value and the loop increment value, then use a vector add for the biv increment operation.
