Re: how to make sure an init routine is kept in the call graph?
On Fri, Apr 22, 2011 at 8:35 AM, Gary Funck wrote: > > 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? Try setting DECL_PRESERVE_P to 1. Richard. > thanks, > > - Gary >
Re: Traversing typedef hierarchy in C/C++ tree
Hi Ian, Ian Lance Taylor writes: > 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. I think fundamentally the requirements of those who use GCC as just a compiler and those who use it to do other things (via plugins) will be often at odds. The "compiler users" will always strive to keep as little syntactic information as possible to maximize performance. While the "plugin users" will want as much context as possible. A more general approach which could satisfy both camps would be to allow the "plugin users" to maintain the extra information if they need to. For example, I would be perfectly happy to build and use the typedef hierarchy outside of the AST. And all that I would need for this is a plugin event, similar to PLUGIN_FINISH_TYPE, that would give me base type, new type, and the decl nodes. In the parser source code the overhead would be an additional if-statement for each typedef: if (finish_typedef_callbacks_count != 0) /* Call registered callbacks. */ The nice thing about this approach is that it can be applied equally well to a lot of things without having to fit them into the existing tree. What do you think? Thanks, Boris
Re: Traversing typedef hierarchy in C/C++ tree
On Fri, 22 Apr 2011 14:15:11 + (UTC)
Boris Kolpackov wrote:
>
> I think fundamentally the requirements of those who use GCC as just a
> compiler and those who use it to do other things (via plugins) will be
> often at odds. The "compiler users" will always strive to keep as little
> syntactic information as possible to maximize performance. While the
> "plugin users" will want as much context as possible.
Yes. A general approach inside plugins would be to use a lot of
association tables (e.g. hash tables) to map existing GCC data to extra
(plugin) information. The MELT [meta-]plugin uses systematically this
approach, by providing hash tables keyed by every "ctype" (that is,
internal GCC GTY-ed data like gimple, edge, ...).
> A more general approach which could satisfy both camps would be to allow
> the "plugin users" to maintain the extra information if they need to. For
> example, I would be perfectly happy to build and use the typedef hierarchy
> outside of the AST. And all that I would need for this is a plugin event,
> similar to PLUGIN_FINISH_TYPE, that would give me base type, new type,
> and the decl nodes.
I fully agree with that. My (biased) feeling is that there should be
much more plugin hooks, and that adding such hooks should be more easy
than it is currently. In my opinion, plugin hooks should be added,
especially those hooks which don't
The current (sad) situation is a catch 22: extra plugin hooks are only
considered (by the GCC community) to be added only if there are real
plugins needing them, but plugins will be developped only if there are
enough relevant hooks to make them.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
libgcc helpers __cmpsi2/__ucmpsi2
I'm updating the machine description for a 16-bit microcontroller, and am trying to eliminate some hand-coded SImode and DImode insns because in general gcc generates better code automatically. So far, I've found no case where I seem to need to implement cbranchsi4 or cbranchdi4. However, gcc does generate a reference to __ucmpsi2 when compiling a switch statement with a default clause and a 32-bit integer as the selection expression. The mailing list archives suggest that cmpsi2 was at one point a library routine, but it is not documented in the internals (at least in the 4.5.x branch where I'm currently working). libgcc2 provides a presumably trusted implementation of __ucmpdi2, though except for a switch statement with a default clause and a 64-bit selection expression I've been unable to find any way to generate test code that actually uses it (gcc.c-torture/execute/cmpdi-1.c doesn't.) I've never been able to get the signed version __cmpdi2 to show up. One past message (http://gcc.gnu.org/ml/gcc/2007-08/msg00225.html) suggests that a similar evocation of __cmpsi2 might be a bug that arose because there are "two different sizes of signed integers both of which are larger than word_mode". Which is the case in the MSP430. GCC seems fully capable of reducing SImode and DImode comparisons to HImode in every other situation. Is generation of this undocumented helper function worth treating as a bug in the compiler, or is the documentation incomplete and back-ends (or libgcc2.c) should be providing an implementation? If the former, I'll spend some time trying to isolate it; if the latter, I won't bother. Peter
Re: libgcc helpers __cmpsi2/__ucmpsi2
Peter Bigot writes: > I'm updating the machine description for a 16-bit microcontroller, and am > trying to eliminate some hand-coded SImode and DImode insns because in > general gcc generates better code automatically. So far, I've found no case > where I seem to need to implement cbranchsi4 or cbranchdi4. > > However, gcc does generate a reference to __ucmpsi2 when compiling a switch > statement with a default clause and a 32-bit integer as the selection > expression. > > The mailing list archives suggest that cmpsi2 was at one point a library > routine, but it is not documented in the internals (at least in the 4.5.x > branch where I'm currently working). libgcc2 provides a presumably trusted > implementation of __ucmpdi2, though except for a switch statement with a > default clause and a 64-bit selection expression I've been unable to find > any way to generate test code that actually uses it > (gcc.c-torture/execute/cmpdi-1.c doesn't.) I've never been able to get the > signed version __cmpdi2 to show up. > > One past message (http://gcc.gnu.org/ml/gcc/2007-08/msg00225.html) suggests > that a similar evocation of __cmpsi2 might be a bug that arose because there > are "two different sizes of signed integers both of which are larger than > word_mode". Which is the case in the MSP430. > > GCC seems fully capable of reducing SImode and DImode comparisons to HImode > in every other situation. Is generation of this undocumented helper > function worth treating as a bug in the compiler, or is the documentation > incomplete and back-ends (or libgcc2.c) should be providing an > implementation? If the former, I'll spend some time trying to isolate it; > if the latter, I won't bother. I believe it is a documentation bug that __cmpdi2 and __ucmpdi2 are documented but __cmpsi2 and __ucmpsi2 are not. gcc can certainly generate calls to __cmpsi2 and __ucmpsi2 in some cases for some targets. It does appear that if you have a cbranchsi4 insn in your MD file, and you don't have a conditional move instruction, then I don't think __cmpsi2 or __ucmpsi2 will ever be called. Ian
Re: how to make sure an init routine is kept in the call graph?
On 04/22/11 11:14:11, Richard Guenther wrote: > GF: What is needed in the new scheme of things to ensure that this > GF: initialization function stays in the call graph? > > Try setting DECL_PRESERVE_P to 1. Richard, thanks. That worked. - Gary
RE: GCC 4.4/4.6/4.7 uninitialized warning regression?
> > 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. Is this related to this bug, which I filed a year or two ago? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42561 It would indeed be very nice to get this taken care of, as this kind of analysis would really help find a lot of bugs that currently require commercial tools.
Reminder - GCC Gathering in London 17/Jun to 19/Jun 2011
We are starting to run tight on space. If you are thinking of attending this event, please let us know soon. Thanks. Diego. -- Forwarded message -- From: Diego Novillo Date: Fri, Apr 15, 2011 at 09:44 Subject: Reminder - GCC Gathering in London 17/Jun to 19/Jun 2011 To: g...@gnu.org Please contact us before 22/Apr to confirm your assistance. We need to have an idea of how many people to expect for planning. Thanks. Diego. -- Forwarded message -- From: Diego Novillo Date: Fri, Apr 8, 2011 at 16:15 Subject: GCC Gathering in London 17/Jun to 19/Jun 2011 To: g...@gnu.org, Ian Taylor We are organizing a gathering of GCC developers and interested parties at the Google office in London, UK for the weekend of 17-Jun-2011. The gathering will be Friday evening, all day Saturday, and Sunday until some time in the afternoon. The idea is to simply get together and discuss current/future work, coordinate efforts, and perhaps do some collective GCC hacking. The format is going to be an informal unconference: - No papers. - No prepared presentations (unless it's really interesting). - No attendance fees. Google will provide meeting facilities and food. We have space for about 100 people. Attendees are responsible for travel and accommodations. We will meet Friday evening and coordinate a list of topics for discussion. We could also work something out in advance. At the moment, we need to know how many developers would attend. Please RSVP before 22-Apr-2011. Let us know if you might come; it's not a commitment. The Google London office is near Victoria Station at Belgrave House 76 Buckingham Palace Road London SW1W 9TQ United Kingdom http://maps.google.com/?q=Google%20London@51.495238,-0.146663&hl=en Diego and Ian.
gcc-4.6-20110422 is now available
Snapshot gcc-4.6-20110422 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110422/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 172880 You'll find: gcc-4.6-20110422.tar.bz2 Complete GCC (includes all of below) MD5=b020f8dab104f069a5a923c1ccadf532 SHA1=b33ef35393018059f663415985ad9e0db3ab375c gcc-core-4.6-20110422.tar.bz2C front end and core compiler MD5=44b5367bab81fdf2986bf2d61517cbac SHA1=ae2ab8e1dd935791f98dab04919b0bc7d08e1812 gcc-ada-4.6-20110422.tar.bz2 Ada front end and runtime MD5=0b009d9006c3a5b7338e734caf3800c1 SHA1=bffc1ff8d6c62a9e900fb92d9e02f5dea286b2f7 gcc-fortran-4.6-20110422.tar.bz2 Fortran front end and runtime MD5=d47693162452260c3778844a9f99b63b SHA1=8b560b41923fc95fade9a29e2cdd8276c532919f gcc-g++-4.6-20110422.tar.bz2 C++ front end and runtime MD5=e8a876934dfba161380a222a08464a28 SHA1=865192b7a4c3262a6a806180df389f04da4b8534 gcc-go-4.6-20110422.tar.bz2 Go front end and runtime MD5=f3a91995972a2edff205f56e483c2809 SHA1=50a914e84cfd0c807e5f9dd24e80f522b51daf3e gcc-java-4.6-20110422.tar.bz2Java front end and runtime MD5=f85f9326c4432f5dea26a02581337718 SHA1=f68f2aa4c89ccd51c2281ed1655ad9df6109ab03 gcc-objc-4.6-20110422.tar.bz2Objective-C front end and runtime MD5=8224f0c401c82c5e34c064862e1c2c67 SHA1=6f7a016704a150a29b55c3aceeb17323821d95e5 gcc-testsuite-4.6-20110422.tar.bz2 The GCC testsuite MD5=40c1ccb894a33be18419a87a897bf9cc SHA1=8798367d8167a542dffbd7bb73e47e9f9efa3de5 Diffs from 4.6-20110415 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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: Reminder - GCC Gathering in London 17/Jun to 19/Jun 2011
Looks like i should be in England at the time kind of nervous pop'ing along but i plant to be there so might as well :) --Phil
