Re: Fw: Failing matrix tests
David Edelsohn <[EMAIL PROTECTED]> wrote on 19/07/2007 16:39:40: > Razya, > >Many of the tests fail on AIX as well. > > David > Ok, Looking into it. Thanks > > FAIL: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times Flattened 3 dimensions > 1 > FAIL: gcc.dg/matrix/matrix-2.c scan-ipa-dump-times Flattened 2 dimensions > 1 > FAIL: gcc.dg/matrix/matrix-3.c scan-ipa-dump-times Flattened 2 dimensions > 1 > FAIL: gcc.dg/matrix/matrix-6.c scan-ipa-dump-times Flattened 2 dimensions > 1 > FAIL: gcc.dg/matrix/transpose-1.c scan-ipa-dump-times Flattened 3 > dimensions 1 > FAIL: gcc.dg/matrix/transpose-1.c scan-ipa-dump-times Transposed 3 > FAIL: gcc.dg/matrix/transpose-2.c scan-ipa-dump-times Flattened 3 > dimensions 1 > FAIL: gcc.dg/matrix/transpose-4.c scan-ipa-dump-times Flattened 3 > dimensions 1 > FAIL: gcc.dg/matrix/transpose-4.c scan-ipa-dump-times Transposed 2 > FAIL: gcc.dg/matrix/transpose-5.c scan-ipa-dump-times Flattened 3 > dimensions 1 > FAIL: gcc.dg/matrix/transpose-6.c scan-ipa-dump-times Flattened 3 > dimensions 1 >
assembly: control flow graphs (and optimizations)
hi list, is there a meaning for control flow graphs of assembly files (.S) (e.g. those that are emitted using -fdump-rtl-*) ? if not - then how are assembly file being optimized ? I guess that assembly files can be made more efficient by many of gcc's optimizations too, can't they ? thanks !! sunzir
Re: assembly: control flow graphs (and optimizations)
Sunzir Deepur wrote: hi list, is there a meaning for control flow graphs of assembly files (.S) (e.g. those that are emitted using -fdump-rtl-*) ? if not - then how are assembly file being optimized ? I guess that assembly files can be made more efficient by many of gcc's optimizations too, can't they ? possibly, but the only reasonable use of assembly these days is for low level programming where you absolutely do NOT want any any optimization. For instance, the hardware may have timing requirements that require instructions to be emitted in some very precise order. So this is neither possible nor desirable. thanks !! sunzir
Refactoring tool
gcc, Recently I have been interested in creating an open source refactoring tool. I did not have much luck finding an application that does what I need and thought that I could get some feedback from the gcc community. In particular I would like to add a flag which would cause gcc to emit symbol definition and use information. The -fdump-* flags provide much of this information in various formats. I would like to combine the salient information into a denser binary format that could be consumed by a subsequent application which would then modify the original source text. I would like this second application to be a command line tool which uses a syntax similar to gdb. For example "show unused headers in test.cpp" would print the header files which were included but not required in test.cpp. I have been able to come up with a small set of functions that I would like to be available, these include: rename [function|class|variable]+ [in scope] old_name new_name //rename a function or variable or class move [function|class|variable]+ to file //move a function class or variable definition to a different source code location remove using [namespace name] from file //fully qualify each symbol use with the appropriate namespace create function from file.begin_line file.end_line //create a function out of a block of code Having spent some time looking at the code for gcc it seems reasonably easy(with some suggestions) to traverse the tree generated and write the relevant information to a file. Any suggestions or pointers to related work would be much appreciated. Patrick Get the Yahoo! toolbar and be alerted to new email wherever you're surfing. http://new.toolbar.yahoo.com/toolbar/features/mail/index.php
Re: Refactoring tool
Patrick Flannery wrote: Any suggestions or pointers to related work would be much appreciated. The GNAT front end generates the kind of information you are suggesting for Ada (see format of ali files), and GPS has a refactoring tool that makes use of this information, so that might be one place to look for ideas.
Re: PATCH: Add myself as libbid maintainer
On Thu, 5 Jul 2007, Tom Tromey wrote: > In this case the library has to follow the external project policy: > > http://gcc.gnu.org/ml/gcc/2006-03/msg00558.html > > It at least needs an entry on the "coding conventions" page. Good point. HJ, would you mind updating our coding conventions page (http://gcc.gnu.org/codingconventions.html) accordingly? Gerald
GCC for Symbian
First of all, thanks for your work. You made the most powerful compiler, i think. I am programmer, i am writing C/C++ programs for Nokia Series 60 devices, and often i need to run some parts of code directly on device. I think, not only me, but other symbian developers got same problem. There are no C compiler, that runs directly on such devices. That's why i want to ask: is there any version of gcc under Symbian already exist or planned. If second, i can help to develope it.
debugging info considered harmful to lto.
At the summit, I discovered two things about the internal representation of debugging information: 1) According to Honza, the instances of the BLOCK tree type take 30% of the space in a compilation. 2) The BLOCKS structure is linked in a way so that the blocks for one function link to the blocks of other functions. These two facts conspire to create a big problem for GCC/LTO, especially when we progress to trying to compile very large programs. Unlike many other essential parts of gcc, the current representation of debugging information is not one that can be divided into moderate sized pieces that can be processed independently. Honza's last lto patch "solves" the problem in the very short term by simply creating a single BLOCK for each function. This provides enough information to allow our testing to continue, but means that no useful debugging information will be generated. This is not acceptable in even the medium term, but it allows the problem to be deferred while Mark and I get the basics of reading and writing gimple working. I find it somewhat surprising that we need so many blocks. My experience is that in real programs few blocks actually have any local declarations and it appears that we do not bother to get rid of the blocks that have no local decls. However the biggest problem for lto is that when a procedure is inlined, the set of blocks for the inlined function is copied and the new copies have a cross link to the original version. It would help a lot if that pointer could be replaced with something like a pointer to a function decl and the dfs number of the block in the original function. I do not know the semantics of what is needed by the debuggers, but some representation where each function can be managed as a separate unit is going to be required to process large programs. Suggestions are welcome, but volunteers willing to attack this problem are truly needed. I do not think that anyone would take lto seriously if we cannot support debugging; only toy compilers do not have debugging. Kenny
