Re: GCC 4.4/4.6/4.7 uninitialized warning regression?
On Wed, Apr 20, 2011 at 9:06 PM, Xinliang David Li wrote: > On Wed, Apr 20, 2011 at 12:03 PM, Cary Coutant wrote: >>> This brings out 2 questions. Why don't GCC 4.4/4.6/4.7 warn it? >>> Why doesn't 64bit GCC 4.2 warn it? >> >> Good question. It seems that the difference is whether the compiler >> generates a field-by-field copy or a call to memcpy(). According to >> David, the trunk gcc in 32-bit mode doesn't call memcpy, but still >> doesn't warn. He's looking at it. > > It seems to be related to alias rewrite -- the use of single memory > token somehow blocks the warning (even though the struct read are > SRAed). The warning never really worked by design. It worked by luck if a read used the default definition of a non-aliased VOP. Which made it work for simple testcases but almost never for real code. A real uninitialized warning for memory wouldn't be difficult to write using the alias walking machinery (just use walk_aliased_vdefs, stop on the first callback assuming that's an initialization, warn if you don't get any callback). It's just going to be expensive. Richard.
GCC 4.5.3 Status Report (2011-04-21), branch now frozen
Status == A first release candidate for GCC 4.5.3 is beeing made. The branch is now frozen until after the final 4.5.3 release. All changes require explicit release manager approval. Quality Data Priority # Change from Last Report --- --- P10 P2 112 - 7 P30 - 9 --- --- Total 112 - 5 Previous Report === http://gcc.gnu.org/ml/gcc/2010-12/msg00389.html The next report will be sent after GCC 4.5.3 has been released.
Re: GCC 4.5.3 Status Report (2011-04-21), branch now frozen
On Thursday 21 April 2011 11:30:49 Richard Guenther wrote: > Status > == > > A first release candidate for GCC 4.5.3 is beeing made. The branch > is now frozen until after the final 4.5.3 release. All changes > require explicit release manager approval. > > > Quality Data > > > Priority # Change from Last Report > --- --- > P10 > P2 112 - 7 > P30 - 9 > --- --- > Total 112 - 5 Total 112 - 16 Do you think nobody reads your reports? :-p
GCC 4.5.3 Release Candidate available from gcc.gnu.org
A first release candidate for GCC 4.5.3 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.5.3-RC-20110421/ and shortly its mirrors. It has been generated from SVN revision 172803. I have sofar bootstrapped and tested the release candidate on x86_64-unknown-linux-gnu. Please test it and report any issues to bugzilla. If all goes well the final GCC 4.5.3 release will happen late next week.
Re: Traversing typedef hierarchy in C/C++ tree
Hi Ian, Ian Lance Taylor writes: > Boris Kolpackov writes: > > > Yes, that's what I suspect. Which is unfortunate since GCC already creates > > all the nodes. All that is left is to establish a link between two types. > > While this is not necessary for C/C++ compilation, it could be useful for > > other tools that can now be built with the GCC plugin architecture. > > If you can make that work without using any extra memory and without > making it more expensive to handle typedefs, I expect that the patch > would be acceptable. I took a look at it and did some pondering. It doesn't seem it will be easy to meet both of the above requirements. We have to keep the main_variant member in struct tree_type because getting to the main variant is a very frequent operation. I don't think replacing it with a loop that goes up the tree from a leaf node to the root is an option. We also have to keep the linked list of all the variants (the next_variant member) because there are a couple of places in the code that need to visit every variant. I also looked into reusing some of the existing members that are the same for all variants. In this case we could store the real value in the main variant and use the member in all other variants to organize the tree. binfo was a good candidate but then I discovered that there is a competition for member reuse ;-) and binfo is already taken. I was also thinking if adding an extra member would be a big deal, memory usage-wise. This member is only going to be added to the TYPE nodes (struct tree_type). I may be wrong, but I would expect that there aren't that many such nodes in a typical translation unit. Much fewer than, say, nodes that are used to build function bodies. Let's say we have 10,000 such nodes. Then on a 64-bit box we will use extra ~80Kb. What do you think? Thanks, Boris
Re: Traversing typedef hierarchy in C/C++ tree
Boris Kolpackov writes: > I was also thinking if adding an extra member would be a big deal, > memory usage-wise. This member is only going to be added to the > TYPE nodes (struct tree_type). I may be wrong, but I would expect > that there aren't that many such nodes in a typical translation > unit. Much fewer than, say, nodes that are used to build function > bodies. Let's say we have 10,000 such nodes. Then on a 64-bit > box we will use extra ~80Kb. Unfortunately we have discovered over time that all the memory usage matters. A rule of thumb for gcc is that compilation speed is roughly proportional to the amount of memory used. One of the main reasons that clang is faster than gcc is that clang uses smaller data structures. Ian
Hardware stream prefetching
Does any processor besides the PowerPC support varients of the prefetch instruction that you can tell it that there are hardware streams with a given stride at the beginning of the loop, rather than doing a prefetch inside the loop for a future cache entry? I'm just starting to look at adding support for the PowerPC's advanced forms of the dbct instruction that set up these hardware streams, and was wondering whether there were other architectures that could use this. I couldn't find anything in the AMD and Intel architecture manuals. The IBM XL compiler supports this, but I would like to add similar support in GCC. -- Michael Meissner, IBM 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Re: Supporting multiple pointer sizes in GCC
On Thu, Mar 31, 2011 at 01:32:24PM +0100, Paulo J. Matos wrote: > On 30/03/11 08:57, Claudiu Zissulescu wrote: > >Hi, > > > >I would try using the named address space for your issue (see > >TARGET_ADDR_SPACE_POINTER_MODE). Please check the SPU target for an > >implementation example. > > > > Hummm, I haven't noticed this hook before. Could this be used to > implement cases where function pointers have a different size than > data pointers (as in harvard archs). It looks like it but can > someone confirm? The SPU uses named address space to deal with local memory that the processor deals with normally, and global memory that the host powerpc can see, and it is moved in/out of the local memory. In -mea64 mode, the external memory is 64-bits, so it has two different sizes of pointer. The backend controls whether one named address is a subset of another, and whether you can convert between the named address spaces. The technical report (N1169) of the ISO C committee that the address space support is based on does not allow for function pointers to be different sizes, just the data pointers. The 2009 GCC summit proceedings has my paper describing adding the named address space support to the compiler. Note I have moved groups within IBM, and no longer work on the SPU compiler, so I haven't touched the named address space support since the early part of 2009. http://gcc.gnu.org/wiki/HomePage?action=AttachFile&do=view&target=2009-GCC-Summit-Proceedings.pdf -- Michael Meissner, IBM 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Re: Traversing typedef hierarchy in C/C++ tree
Ian Lance Taylor writes: > Boris Kolpackov writes: > > > I was also thinking if adding an extra member would be a big deal, > > memory usage-wise. This member is only going to be added to the > > TYPE nodes (struct tree_type). I may be wrong, but I would expect > > that there aren't that many such nodes in a typical translation > > unit. Much fewer than, say, nodes that are used to build function > > bodies. Let's say we have 10,000 such nodes. Then on a 64-bit > > box we will use extra ~80Kb. > > Unfortunately we have discovered over time that all the memory usage > matters. A rule of thumb for gcc is that compilation speed is roughly > proportional to the amount of memory used. One of the main reasons that > clang is faster than gcc is that clang uses smaller data structures. The reason for this, though, is that there's a lot of places in gcc (fewer in g++, because we worked on removing them) where operations are of the form for (every declaration in the program) do something; This causes these decls (or whatever the loop is looking at---identifiers, RTL, whatever) to have to be fetched from main memory, instead of L1 or L2 cache, and that's slow. Usually the 'do something' is very fast, perhaps only a single test most of the time, which means performance is dominated by the time required to fetch the decl, which is proportional to the size of the decl. It's easy to find these places with a performance measurement tool, just look for lines of code which cause a lot of L2 cache misses.
gcc-4.5-20110421 is now available
Snapshot gcc-4.5-20110421 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110421/ 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 172845 You'll find: gcc-4.5-20110421.tar.bz2 Complete GCC (includes all of below) MD5=9581cd5e7cea1edaa720d3954a2d6508 SHA1=1efaff0c7f76a6d03758d8a0bd8e005006ceaab7 gcc-core-4.5-20110421.tar.bz2C front end and core compiler MD5=fea99822b30ae0fef2120bbb1e3e13d0 SHA1=1b35a246daedd465a9cd20c9811f4ad64bdcf7df gcc-ada-4.5-20110421.tar.bz2 Ada front end and runtime MD5=b739360e6e507cc16905c5c9cd1092d2 SHA1=d5afa7f0b08133ecec136a9f71f35c3cd73d1247 gcc-fortran-4.5-20110421.tar.bz2 Fortran front end and runtime MD5=7d4c46b75cd68b56aa5bf0181357b377 SHA1=b02583ebdb3bf33d815db5335e899ae3ff15e39f gcc-g++-4.5-20110421.tar.bz2 C++ front end and runtime MD5=b3dede26b1ee8ef444fe05997bff69d1 SHA1=f1166f5c54244a3f6233875819e5c36c44cc6ce5 gcc-go-4.5-20110421.tar.bz2 Go front end and runtime MD5=a1d66dfbbedf9c9859bd4410900426da SHA1=de4c319a213ef408d28b3ade2582f982ff64992a gcc-java-4.5-20110421.tar.bz2Java front end and runtime MD5=f7f4992af69bbcc977fbab0f9026822d SHA1=8d6859e27cadd076b10c440f35fb642b0e84c8aa gcc-objc-4.5-20110421.tar.bz2Objective-C front end and runtime MD5=c1b94f5bbd19c7e43a3db9a454d14496 SHA1=8224d73c8dc73bef466078ac828b6f77dd949e19 gcc-testsuite-4.5-20110421.tar.bz2 The GCC testsuite MD5=762aa87ae04c8428f689bf0493272d56 SHA1=b5f776ed6e8908cce002fd8eecc2baf2b20d6c6c Diffs from 4.5-20110414 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.
how to make sure an init routine is kept in the call graph?
Recently, we tried to merge the GCC trunk into the GUPC branch and ran into an issue caused by a recent GCC update. The last successful merge was trunk version 172359, fyi. For certain UPC file scope static initializers, a per file initialization routine is created, its address is added to a global table (in its own section). The UPC runtime will call all the routines listed in that table before transferring control the user's main program. After the recent trial merge, we see the following on some of our test cases: ../../gcc/xupc -O2 -g -fdump-ipa-cgraph -fdump-tree-cfg test25.upc -o test25 /tmp/ccygQ8JN.o:(upc_init_array+0x0): undefined reference to `__upc_init_decls' The call graph dump entry for `__upc_init_decls' is as follows: __upc_init_decls/80(80) @0x71eb3de0 (asm: __upc_init_decls) body finalized called by: calls: References: Refering this function: As expected, no explicit references have been recorded. The compiler routine that creates this initialization routine is called from c_common_parse_file(): push_file_scope (); c_parse_file (); /* Generate UPC global initialization code, if required. */ if (c_dialect_upc ()) upc_write_global_declarations (); pop_file_scope (); The routine that builds the initialization function is upc_build_init_func() in gcc/upc/upc-act.c (on the gupc branch). This routine does the following to build the function, mark it as used and referenced, and to then add its address to the initialiaztion table: DECL_SOURCE_LOCATION (current_function_decl) = loc; TREE_PUBLIC (current_function_decl) = 0; TREE_USED (current_function_decl) = 1; DECL_SECTION_NAME (current_function_decl) = build_string (strlen (UPC_INIT_SECTION_NAME), UPC_INIT_SECTION_NAME); /* Swap the statement list that we've built up, for the current statement list. */ t_list = c_begin_compound_stmt (true); TREE_CHAIN (stmt_list) = TREE_CHAIN (t_list); cur_stmt_list = stmt_list; free_stmt_list (t_list); t_list = c_end_compound_stmt (loc, stmt_list, true); add_stmt (t_list); finish_function (); gcc_assert (DECL_RTL (init_func)); upc_init_array_section = get_section (UPC_INIT_ARRAY_SECTION_NAME, 0, NULL); mark_decl_referenced (init_func); init_func_symbol = XEXP (DECL_RTL (init_func), 0); assemble_addr_to_section (init_func_symbol, upc_init_array_section); In the past, setting TREE_USED() and calling mark_decl_referenced() was sufficient to make sure that this routine was not removed from the call graph. What is needed in the new scheme of things to ensure that this initialization function stays in the call graph? thanks, - Gary
