Re: Branch created for PR46489 (target macro elimination from frontends / tree optimizers)
> Is there sufficient interest to post the branch patches to gcc-patches as I > go? If not that could be a substantial review headache at merge time. On 18/12/2010, Joern Rennecke wrote: > I have created the branch: > svn://gcc.gnu.org/svn/gcc/branches/pr46489-20101217-branch > to continue working on PR46489 while trunk is in slush / freeze mode. > > The branch does not use the usual distributed ChangeLog scheme, but a single > ChangeLog.46489 in > svn://gcc.gnu.org/svn/gcc/branches/pr46489-20101217-branch/gcc that has > entries like for a patch submission. That keep our options open to > either review the branch as a whole, or to convert the check-ins back > into patches and submit them when 4.7 phase 1 opens. > > Yesterday I checked in two of the still unreviewed patches I had posted > previously on gcc-patches. > > As the goal is no longer inclusion in 4.6 phase 3, but but 4.7 phase 1 or 2, > it now makes sense to look beyond the issue of front-end instability, and > also include further macro->hook conversions that make the design more > consistent. > > In that spirit, I've checked a patch into the branch today to hookize > INIT_CUMULATIVE_ARGS and its two variants into a single hook. > > Is there sufficient interest to post the branch patches to gcc-patches > as I go? > > FWIW my current contract under which I do this work ends at the end of > December, so I might not have much time to discuss the patches afterwards. > >
gcc-4.3-20101219 is now available
Snapshot gcc-4.3-20101219 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20101219/ 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 168070 You'll find: gcc-4.3-20101219.tar.bz2 Complete GCC (includes all of below) MD5=d0cb20ac1d8d46a87568d84ce911d307 SHA1=03ed96761f8026e2da5cbdeaf134d6d5685e3eb5 gcc-core-4.3-20101219.tar.bz2C front end and core compiler MD5=01a04da72b4e085698a7bd0c04179b70 SHA1=2544a4bde3e87231bab036d3715fad5103bc82d4 gcc-ada-4.3-20101219.tar.bz2 Ada front end and runtime MD5=e459ebf1cc9206782c3ff5b8416d551a SHA1=07a227b461f4f918a448c93d692a49da142de6b6 gcc-fortran-4.3-20101219.tar.bz2 Fortran front end and runtime MD5=075dfd5c4a4e3ed6c4fb21570ed1b401 SHA1=3c26c7546fb21fb0ff022a5bd3fee0d072ed2e71 gcc-g++-4.3-20101219.tar.bz2 C++ front end and runtime MD5=39df32f4ef6c1ad19b52ab9e05945e39 SHA1=7e0a093759c466b911a838a590c6c5916d65daca gcc-go-4.3-20101219.tar.bz2 Go front end and runtime MD5=b968b4638a59d9a629742cbbf06af8eb SHA1=6ac22a86c7bb2f1e043bd7b5062705fa78ac21c3 gcc-java-4.3-20101219.tar.bz2Java front end and runtime MD5=9b2e0c98aa11e97aa3764721884f9dd7 SHA1=a447585afda857a76399dab2a97f6ad8b8763237 gcc-objc-4.3-20101219.tar.bz2Objective-C front end and runtime MD5=71aa864d7fed26e84e3955f48ea671ed SHA1=6d119f9e1066bae9c0ae0217261a4d1d3d5ccc98 gcc-testsuite-4.3-20101219.tar.bz2 The GCC testsuite MD5=b7f12e7c45856f75aab6fc3473397fbd SHA1=465523defa8eedcb804c462dacc86061cbe35cde Diffs from 4.3-20101212 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.
cscope replacement
Hi, I believe I asked this question about four years ago and as I recall, there was things on the horizon that seemed hopeful so I thought I would ask again. Is there a way to have gcc produce some type of intermediate file that could be used to generate a cscope like database. (Perhaps a better way to phrase the question is 'which intermediate file, if any, could be used') I have a few issues with cscope that I keep hoping to solve somehow someday. Here is a short list of them: 1) cscope doesn't really parse the input so it very often gets rather confused. It does a wonderful job over all but it isn't 100%. My thought is to produce some file for each compile run. e.g. from foo.c, an extra file perhaps called foo.t would be produced. The foo.t files would then be processed and a unified database created. Then tools would be written to rummage around in the database. 2) If struct dog x; x.y = 5; is seen, then cscope does not know that y is a field of dog. Often, programmers use too simple of a name and if I do cscope for "y",I get way too many hits. It would be nice if I could search for dog.y and find places where it is referenced. Separating l and r values would be nice too. This implies that the foo.t files be fairly sophisticated in what they are reporting. But, it is obviously nothing that the compiler doesn't already know at the time it is doing the compile. 3) I don't know what to do about CPP macros. cscope does not look inside of them so you can search for the macros directly. With output coming from the latter stages of the compiler, the original text may have been lost. Perhaps the foo.t output might need to be combined with an intermediate file from CPP. Thank you for your time, Perry
Re: Help with reloading
On 12/15/10 07:14, Mohamed Shafi wrote: Hi, I am doing a port in GCC 4.5.1. The target supports storing immediate values into memory location represented by a symbolic address. So in the move pattern i have given constraints to represent this. Presumably the target does not support storing an immediate value into other MEMs? ie, the only store-immediate is to a symbolic memory operand, right? I think this is a case where you're going to need a secondary reload to force the immediate into a register if the destination is a non-symbolic MEM or a pseudo without a hard reg and its equivalent address is non-symbolic. Jeff
