Re: Tutorial Proposal for GCC Summit
On 10-08-18 12:50 , Uday Khedker wrote: Looking forward to getting some feedback. I would also be happy to modify the tutorial based on the feedback. Thank you very much for organizing this tutorial. I think it's an excellent idea. In the context of the GCC Summit, I believe your presentation may be useful as a way of finding areas not covered by the original material. The GCC Summit audience will have deep understanding of the various topics in the tutorial. But an overview of the whole system is still useful. I would also suggest proposing a similar tutorial for next year's CGO. GROW 2011 will be co-located with CGO 2011. A tutorial like this one seems like a very good fit for it. Diego.
gcc-4.5-20100819 is now available
Snapshot gcc-4.5-20100819 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100819/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 163387 You'll find: gcc-4.5-20100819.tar.bz2 Complete GCC (includes all of below) MD5=a02d6eddca205f13b3b6b6a15a481dce SHA1=36c03200e3187bab49916b59e367d3d15f397cb7 gcc-core-4.5-20100819.tar.bz2C front end and core compiler MD5=b79f033fb58a18fc575fd1ed91c61d5b SHA1=fdc8d2e7f41648d6e954393ec95c27611a2c7901 gcc-ada-4.5-20100819.tar.bz2 Ada front end and runtime MD5=4166047c3384d95ae1d78aaa7deb1d1e SHA1=b11f3d1da4577b063bbe262b3ea5e74f672c1675 gcc-fortran-4.5-20100819.tar.bz2 Fortran front end and runtime MD5=e1ce1e787dbc4964ad6b3cfd060f81f4 SHA1=2d78bc40741ce6213cede37ed610543141f08c20 gcc-g++-4.5-20100819.tar.bz2 C++ front end and runtime MD5=62dd31dea8461a07296cb278702c2bd3 SHA1=49fd99747b2d51b063920f8ba2ad5798226d3dff gcc-java-4.5-20100819.tar.bz2Java front end and runtime MD5=ddee2511ee4fa1140102fadd0a11da0f SHA1=37329dd23640988db0ba3fc902841b713f4658b1 gcc-objc-4.5-20100819.tar.bz2Objective-C front end and runtime MD5=982ab678c2325922c73fc6ed5a0d0dc9 SHA1=2aac61d70eb7ced382cb93445f30b6664afbc34e gcc-testsuite-4.5-20100819.tar.bz2 The GCC testsuite MD5=0b6987c0a83cc2dfad160a74940aafda SHA1=3a2b0af6385dc439418fd9144a8c0863299a5ba1 Diffs from 4.5-20100812 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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.
Re: Irreducible loops in generated code
Hi, > > I'm working on decompiling x86-64 binary programs, using branches to rebuild > > a control-flow graph and looking for loops. I've found a significant number > > of irreducible loops in gcc-produced code (irreducible loops are loops with > > more than one entry point), especially in -O3 optimized binaries, even when > > the source code is "well" structured. My experiments are done mainly on the > > SPEC CPU-2006 benchmarks. > > > > My question is: where do these irreducible loops come from? Which > > optimization pass leads to irreducible regions? Thanks in advance for any > > pointer. > > Questions right back at you: What compiler version are you using? Got > a specific exampe (test case)? > > In older releases of GCC4, jump threading sometimes resulted in > irreducible regions, but more recent GCCs carefully try to avoid them. I am not sure that is actually true. Afaik, we only avoid this on gimple, while rtl jump threading does not care, Zdenek
Could we use VIEW_CONVERT_EXPR to build ADDR_EXPR ?
Hi, I am working on bug 45260 and found that the problem is related to VIEW_CONVERT_EXPR. In the prefetching pass, we generate the base address for the prefetching: tree-ssa-loop-prefetch.c (issue_prefetch_ref): addr_base = build_fold_addr_expr_with_type (ref->mem, ptr_type_node); + gcc_assert (is_gimple_address (addr_base)); Here ref->mem is a COMPONENT_REF and contains a VIEW_CONVERT_EXPR. When I put an assert after build_fold_addr_expr_with_type, I found that the addr_base is not a gimple address at all. The direct reason is that the TREE_OPERAND of the VIEW_CONVERT_EXPR is a SSA_NAME. My questions are: (1) Can we generate address expression for COMPONENT_REF and contains VIEW_CONVERT expression (is it legal to do so)? (2) The assert in the bug actually occurs in verify_expr in tree-cfg.c, is this assert valid? I need to understand whether the bug is in the VIEW_CONVERT_EXPR generation or in build_fold_addr_expr_with_type. Thanks for your inputs. Changpeng
Re: Could we use VIEW_CONVERT_EXPR to build ADDR_EXPR ?
On Thu, Aug 19, 2010 at 4:55 PM, Fang, Changpeng wrote: > My questions are: > > (1) Can we generate address expression for COMPONENT_REF and contains > VIEW_CONVERT > expression (is it legal to do so)? No you should not generate addresses for VCEs that contain a SSA_NAME. I think you should check if get_base_address is a is_gimple_addressable inside gather_memory_references_ref. Thanks, Andrew Pinski
Re: Could we use VIEW_CONVERT_EXPR to build ADDR_EXPR ?
> No you should not generate addresses for VCEs that contain a SSA_NAME. True, because it should be an ADDR_EXPR of the SSA_NAME and the a convert to the appropriate pointer type. But the question here was trickier: there was a COMPONENT_REF of the VCE of an SSA_NAME. I don't know the answer to that one.
