CFG traversal
Hi, Is there functionality in gcc based on which the CFG can be traversed in such a way that a node gets visited once all of its predecessors have been visited? thanks, Alex
Re: CFG traversal
On Tue, 6 Jul 2010, Alex Turjan wrote: > Hi, > Is there functionality in gcc based on which the CFG can be traversed in > such a way that a node gets visited once all of its predecessors have been > visited? (Assuming you mean when there are no loops) Yes, see post_order_compute in cfganal.c. It computes topological sort order (which is what you need) in reverse: nodes that must be visited last come first in the array. Hope that helps. Alexander
Re: question about if_marked construct
On Mon, Jul 5, 2010 at 5:57 PM, Tom de Vries wrote: > Hi, > >>> The tree_map_base_marked_p checks ggc_marked_p on the from field. During >>> ggc_scan_cache_tab, if the from field is live, also the to field is >>> marked >>> live. >>> I wrote some code to do sanity testing and found a similar scenario as >>> before: >>> - a register attribute is not marked live during root marking >>> - reg_attrs_htab is traversed, and the hash table entry corresponding to >>> the >>> register attribute is removed >>> - value_expr_for_decl is traversed, a from field is found live, so the to >>> field is also marked live, marking the register attribute live. >>> >>> Is this valid use of the garbage collector? >> >> Originally the if_marked hook was supposed to be used only for >> caching purposes. So it doesn't matter whether an element is >> collected or not for correctness. If we now have accumulated other >> uses we indeed have to worry about this scenario (and I think it >> won't work very well there). >> >> Richard. > > > For my understanding: is it correct if I translate 'to be used only for > caching purposes' to 'the compiler is free to ignore the if_marked function > and remove all if_marked hash table entries'? > I just tried that in a bootstrap build, and that breaks already in stage 1. > > From looking at all the if_marked functions in gcc, a typical use case seems > to be the one of uniqueness (also the use case described in the docs): > making sure there is only a single object with certain properties, such that > a test for structural equality can be replaced with a pointer equality > comparison. This is well supported by the current implementation, but > correctness does depend on whether a hash table element is collected or not. > > What is not well supported, is marking live something else than hash table > entries during ggc_scan_cache_tab. Following the scenario I mention above, > we can end up with 2 structurally equal objects, while the code assumes > that's not possible, and tests structural equality by pointer comparison. > This is the scenario I worry about. > > I can image a few ways to go from here: > - leave as is, fix this when it really bothers us (risk: exchange a known > problem for unknown hard-to-debug and/or hard-to-reproduce problems) > - instrument if_marked functions like the one for value_expr_for_decl to > assert if the from field is live and the to field is not live, and fix the > asserts > - extend garbage colllector to handle the problematic case (problem: more > runtime and/or memory usage for garbage collection) > Any suggestions on which way to go? Or make sure to walk all if_marked roots last (isn't the problem an ordering one only?) Richard. > Regards > Tom >
Re: Delegating constructors patch
On 07/05/2010 09:57 PM, Rodolfo Schulz de Lima wrote: > Hi, I'd like to know if there's plans to merge Pedro Lamarão's > implementation of delegating constructors into trunk. That work is incomplete, cannot be merged as-is: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43674 Paolo.
Re: Delegating constructors patch
Em 06-07-2010 07:46, Paolo Carlini escreveu: > That work is incomplete, cannot be merged as-is: Thanks for pointing it out for me, Paolo. []s, rod
Re: Plug-ins on Windows
> The attached patch still has some rough edges, like missing main gcc > ChangeLog, missing documentation, no dso building implemented (should > eventually work both in-tree to be installed in the plugin dir and > out-of-tree with a previous built compiler). > Well, I definitely owe you some beer. The gcc I am using isn't trunk but the majority of the changes applied cleanly. I had to back port some changes from trunk to my version and do a little extra hack or two to get it to work on Windows but it works like a charm! On Windows, when you configure gcc it doesn't set ENABLE_PLUGIN because dynamically linked plugins are (rightfully so) unsupported and LINK_PLUGIN_NAMES doesn't get set by configure. Therefore I had to add LINK_PLUGIN_NAMES define to the compile options for opts.o in the gcc/Makefile.in. The exact same options your patch added for plugin.o, after that and fixing a missing return type and semi colon in plugin.c everything works like a charm. You definitely saved me quite a bit of time thanks again! I think if this patch was polished up it could be at least a short term solution for plugin support on Windows. Plus it's a cool feature on other platforms as well. Cheers, Kyle
Build report for AIX 5.3
Hi, i just successfully built GCC 4.5.0 on AIX 5.3 using the following commands: setenv LDR_CNTRL MAXDATA=0x5000 ../gcc-4.5.0/configure --disable-multilib --with-gmp=/usr/local make bootstrap-lean make install $ config.guess powerpc-ibm-aix5.3.0.0 $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/powerpc-ibm-aix5.3.0.0/4.5.0/lto-wrapper Target: powerpc-ibm-aix5.3.0.0 Configured with: ../gcc-4.5.0/configure --disable-multilib --with-gmp=/usr/local Thread model: aix gcc version 4.5.0 (GCC) The system is an IBM System p JS21 Blade with AIX 5.3 at the latest patchlevel. The building c-complier is IBM XL C 10.1.0.1 Make is gnu-make 3.80 The whole build took about 90 minutes The disable-multilib configure-option is used for buildtime- and space-saving reasons. Mario Linke
Re: Plug-ins on Windows
Joern Rennecke wrote: > The main utility of plugins is that they make developing, testing and > deploying modifications to gcc easier. This may be true now, but I certainly hope it will not be true in future. I view the current plug-in mechanism as a prototype. I think that we should be working toward a much more robust mechanism, similar to plug-ins for Eclipse, Firefox, MySQL, or other popular software stacks. I certainly see no reason that plug-ins cannot work on any system that has something roughly equivalent to dlopen (which Windows and OS X certainly do). There's lots of prior art here. The key change we need to make is that instead of the current "unstructured" approach where we essentially expose the entirety of the GCC internals, we provide a stable, documented API that exposes a portion of the internals. (It's fine with me if there's an expert mode in which you can do anything you want, but it should be easy to stay within the stable API if you want to do that.) I would start with an API for "observing" (rather than modifying) the internal representation, and add modification later. With observation alone, you could start to build interesting static-checking tools, including, for example, domain-specific tools that could check requirements of the Linux kernel. This would be a powerful and exciting feature to have in GCC. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
RE: Plug-ins on Windows
>I view the current plug-in mechanism as a prototype. I think that we >should be working toward a much more robust mechanism, similar to >plug-ins for Eclipse, Firefox, MySQL, or other popular software stacks. >I certainly see no reason that plug-ins cannot work on any system that >has something roughly equivalent to dlopen (which Windows and OS X >certainly do). There's lots of prior art here. > >The key change we need to make is that instead of the current >"unstructured" approach where we essentially expose the entirety of the >GCC internals, we provide a stable, documented API that exposes a >portion of the internals. (It's fine with me if there's an expert mode >in which you can do anything you want, but it should be easy to stay >within the stable API if you want to do that.) I would start with an >API for "observing" (rather than modifying) the internal representation, > and add modification later. > >With observation alone, you could start to build interesting >static-checking tools, including, for example, domain-specific tools >that could check requirements of the Linux kernel. This would be a >powerful and exciting feature to have in GCC. Agree with this vision, but it will take some time I guess ;) ... Grigori
Re: gengtype & many GTY tags for same union component?
> "Basile" == Basile Starynkevitch writes:
Basile> My understanding of the description of the tag GTY option in
Basile> http://gcc.gnu.org/onlinedocs/gccint/GTY-Options.html#GTY-Options
Basile> is that a given discriminated union case can have several
Basile> tags.
It seems like a reasonable feature, but I didn't see any text there
indicating that this is already supported.
Basile> struct meltspecial_st
Basile> GTY ((tag ("OBMAG_SPEC_FILE"),
Basile> tag ("OBMAG_SPEC_RAWFILE"),
Basile> tag ("OBMAG_SPEC_MPFR"),
Basile> tag ("OBMAG_SPECPPL_COEFFICIENT"),
Basile> tag ("OBMAG_SPECPPL_LINEAR_EXPRESSION"),
Basile> tag ("OBMAG_SPECPPL_CONSTRAINT"),
Basile> tag ("OBMAG_SPECPPL_CONSTRAINT_SYSTEM"),
Basile> tag ("OBMAG_SPECPPL_GENERATOR"),
Basile> tag ("OBMAG_SPECPPL_GENERATOR_SYSTEM"),
Basile> tag ("OBMAG_SPECPPL_POLYHEDRON"))
Basile> ) u_special;
One thing you can do here is provide a "desc" tag for the union that
collapses all these tags to a single tag.
Instead of:
GTY ((desc ("%0.u_discr->object_magic")))
You would have:
int
magic_for_ggc (int magic)
{
if (magic == OBMAG_SPEC_FILE
|| magic == OBMAG_SPEC_RAWFILE
|| ...)
return OBMAG_SPEC_RAWFILE;
return magic;
}
.. and
GTY ((desc ("magic_for_ggc (%0.u_discr->object_magic)")))
Tom
Re: question about if_marked construct
Hi Richard, I can image a few ways to go from here: - leave as is, fix this when it really bothers us (risk: exchange a known problem for unknown hard-to-debug and/or hard-to-reproduce problems) - instrument if_marked functions like the one for value_expr_for_decl to assert if the from field is live and the to field is not live, and fix the asserts - extend garbage colllector to handle the problematic case (problem: more runtime and/or memory usage for garbage collection) Any suggestions on which way to go? Or make sure to walk all if_marked roots last (isn't the problem an ordering one only?) That is already done. The problem is not what happens after that walk, but during that walk. The code at that point assumes that the set of marked non-hashtable-entry objects is already stable, while the problematic if_marked functions have the effect that that set is enlarged during that walk. If we want to fix that in the garbage collector, we could walk the problematic if_marked roots iteratively (without deleting unmarked entries), until fixed point is reached. After that we would walk (and delete unmarked entries) for both problematic and normal if_marked roots. However, I don't have good idea how we can iterate to fixed- point efficiently. Tom
Re: RFD: test requirements for slow platforms
Ian Lance Taylor wrote: > I'm personally reluctant to codify it, because it's really hard to > codify good judgment. But if you say in your patch how you tested it, > the reviewers should be able to consider whether that is sufficient. I agree. I always claim that my most valuable contribution to GCC was the argument I started a decade ago that culminated in us deciding that you had to run the regression testsuites before check-in. So, I'm a big fan of testing, and the general idea that you shouldn't have to deal with breakage because I was too lazy to test. On the other hand, I think we can get obsessive about it. Testing Ada and Java libraries for every C front-end change seems excessive to me. Testing is not free. Similarly, doing a bootstrap on Super-H GNU/Linux is possible, but it takes a *long* time. I doubt that's worthwhile most of the time. I think we should allow some judgment, and, as you say, we should provide transparency with respect to which testing was done. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Plug-ins on Windows
On 6 July 2010 17:54, Grigori Fursin wrote: >>I view the current plug-in mechanism as a prototype. I think that we >>should be working toward a much more robust mechanism, similar to >>plug-ins for Eclipse, Firefox, MySQL, or other popular software stacks. >>I certainly see no reason that plug-ins cannot work on any system that >>has something roughly equivalent to dlopen (which Windows and OS X >>certainly do). There's lots of prior art here. >> >>The key change we need to make is that instead of the current >>"unstructured" approach where we essentially expose the entirety of the >>GCC internals, we provide a stable, documented API that exposes a >>portion of the internals. (It's fine with me if there's an expert mode >>in which you can do anything you want, but it should be easy to stay >>within the stable API if you want to do that.) I would start with an >>API for "observing" (rather than modifying) the internal representation, >> and add modification later. "We need to make"? Are there any plans (or even interest) on designing such an API in the future? My understanding is that we hope an API will slowly arise from the requirements of external tools. So plugins' authors should not wait for such an API but instead start proposing it, ideally, with patches. >>With observation alone, you could start to build interesting >>static-checking tools, including, for example, domain-specific tools >>that could check requirements of the Linux kernel. This would be a >>powerful and exciting feature to have in GCC. > > Agree with this vision, but it will take some time I guess ;) ... I don't think it requires time. It requires people asking for it and working on it. Current GCC developers do not need this and they will not work on this (as far as I know), so no one should be waiting for such tools to magically appear. However, now that the plugins framework is in-place, anyone is welcome to not only develop such tools but to propose changes that make developing such tools easier. The plugins framework is a statement of the willingness of the GCC community, despite the initial opposition from the FSF, to open the project to external contributions and usages. GCC internals have been (and are still being) renovated, and there is ongoing work to make GCC more modular. However, if there is no one proposing the particular changes required by external usages, those changes won't be made. This is also a warning against working around and second-guessing GCC. Please, don't. Instead contribute the changes (API, code, and documentation) required to make GCC more open and easier to use. I know that this is the hardest route, but it is the only one that makes us progress. Cheers, Manuel.
Re: Massive performance regression from switching to gcc 4.5
> > On 06/30/2010 02:26 PM, Basile Starynkevitch wrote: > >> On Wed, 2010-06-30 at 14:23 -0700, Taras Glek wrote: > >> > >>> I tried 4.5 -O2 and it's actually faster than 4.3 -Os. > >>> > >>> I am happy that -O2 performance is actually pretty good, but -Os > >>> regression is going to hurt on mobile. > >>> > >> Did you try gcc-4.5 -flto -Os or gcc-4.5 -flto -O2? > >> > >> It would be interesting to hear that GCC is able to LTO a program as big > >> as Mozilla! And figures (notably RAM, CPU time, wallclock time for > >> build) would be interesting. > >> > > > > Both whopr and flto cause gcc to segfault while building Mozilla. > > 4.5 WHOPR is completely broken. LTO is in better shape but I am not sure if > we > can resonably expect it to build mozilla. However I would be very happy to > help > getting WHOPR working for 4.6. Hi, I now got the 4.6 WHOPR build up to libxul.so that seems to be one of bigger files. WHOPR linking consists of serial stage (WPA) merging whole program and doing interprocedural optimization followed by parallel build. The serial stage needs 3.7GB of RAM, 10 minutes, most of it is spent by writting out the files for parallel builds that are around 5GB overall. The size of files can be significantly cut down by sane partitioning algorithm, since we produce over 1000 partitions where 40 would do the job. (this is with enable-checking compiler) Later build still die for me, but it seems that libxul is not too large for WHOPR. (I hope all parameters to reduce significantly before 4.6 is out) What are the other big components I should be affraid of? Oprofile of WPA stage is as follows: 3825078.4240 lto_output_1_stream 3791588.3503 htab_find_slot_with_hash 2073304.5661 bp_pack_value 1557933.4311 iterative_hash_hashval_t 1351322.9760 lto_output_uleb128_stream 1011102.2268 gimple_types_compatible_p 92828 2.0444 cgraph_node_in_set_p 83205 1.8324 lto_promote_cross_file_statics 76243 1.6791 htab_expand 75993 1.6736 htab_hash_string 75790 1.6691 eq_string_slot_node 75020 1.6522 bp_unpack_value 73403 1.6166 linemap_lookup 65353 1.4393 lto_output_sleb128_stream 64864 1.4285 inflate_fast 64508 1.4207 verify_cgraph_node 60076 1.3231 lto_output_tree 57120 1.2580 referenced_from_this_partition_p 56225 1.2383 lto_input_uleb128 53620 1.1809 lto_streamer_cache_insert_1 52973 1.1666 htab_find_slot 45728 1.0071 lto_output_tree_or_ref 43428 0.9564 lto_input_1_unsigned 41556 0.9152 tree_map_base_eq 39232 0.8640 hash_cgraph_node_set_element 35695 0.7861 ggc_set_mark So not much of surprise - streaming is ineffecient and we need a lot of time for type merging too. I am compiling to get time report. Honza
Re: Massive performance regression from switching to gcc 4.5
... and time report Execution times (seconds) garbage collection: 12.48 ( 2%) usr 0.00 ( 0%) sys 12.50 ( 2%) wall 0 kB ( 0%) ggc callgraph optimization: 0.21 ( 0%) usr 0.00 ( 0%) sys 0.21 ( 0%) wall 2743 kB ( 0%) ggc varpool construction : 0.97 ( 0%) usr 0.02 ( 0%) sys 0.97 ( 0%) wall 44476 kB ( 1%) ggc ipa cp: 2.82 ( 0%) usr 0.05 ( 0%) sys 2.90 ( 0%) wall 65189 kB ( 2%) ggc ipa lto gimple in : 4.96 ( 1%) usr 0.30 ( 2%) sys 5.28 ( 1%) wall 8 kB ( 0%) ggc ipa lto gimple out: 26.51 ( 4%) usr 0.73 ( 4%) sys 27.54 ( 4%) wall 0 kB ( 0%) ggc ipa lto decl in : 100.69 (14%) usr 2.76 (15%) sys 103.69 (14%) wall 3069230 kB (87%) ggc ipa lto decl out : 405.60 (55%) usr 0.05 ( 0%) sys 406.86 (54%) wall 0 kB ( 0%) ggc ipa lto decl init I/O : 2.21 ( 0%) usr 0.03 ( 0%) sys 2.25 ( 0%) wall 82822 kB ( 2%) ggc ipa lto cgraph I/O: 1.85 ( 0%) usr 0.26 ( 1%) sys 2.11 ( 0%) wall 247249 kB ( 7%) ggc ipa lto decl merge: 54.30 ( 7%) usr 1.20 ( 6%) sys 55.63 ( 7%) wall 283 kB ( 0%) ggc ipa lto cgraph merge : 1.35 ( 0%) usr 0.00 ( 0%) sys 1.35 ( 0%) wall 5259 kB ( 0%) ggc whopr wpa : 79.05 (11%) usr 0.14 ( 1%) sys 79.35 (11%) wall 22146 kB ( 1%) ggc whopr wpa I/O : 10.07 ( 1%) usr 12.89 (69%) sys 22.82 ( 3%) wall 0 kB ( 0%) ggc ipa reference : 1.83 ( 0%) usr 0.00 ( 0%) sys 1.79 ( 0%) wall 0 kB ( 0%) ggc ipa profile : 0.19 ( 0%) usr 0.00 ( 0%) sys 0.20 ( 0%) wall 0 kB ( 0%) ggc ipa pure const: 1.44 ( 0%) usr 0.01 ( 0%) sys 1.46 ( 0%) wall 0 kB ( 0%) ggc inline heuristics : 14.37 ( 2%) usr 0.00 ( 0%) sys 14.41 ( 2%) wall 2825 kB ( 0%) ggc callgraph verifier: 9.22 ( 1%) usr 0.19 ( 1%) sys 9.42 ( 1%) wall 0 kB ( 0%) ggc varconst : 0.02 ( 0%) usr 0.03 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc TOTAL : 732.4218.73 753.13 3543343 kB decl out time definitly will reduce with sane partitioning. Also it seems that osme of my simple minded partitioning code should be optimized to avoid quadratic behaviour. Honza
complete list of emulated TLS targets.
I'd like to compile a complete list of targets affected by changes in emulated TLS. *-*-darwin* hppa64-hp-hpux11.11 cris-*-elf I think also; *-*-mingw *-*-cygwin could people please add to the list/confirm as appropriate? thanks Iain
RE: Plug-ins on Windows
I don't disagree with your comments too, Manuel. I spent some years developing plugin framework for pass selection and reordering, and later we managed to get minimal hooks to mainline GCC based on our needs. Of course, I personally would like to see a coherent and stable API for most of the parts of GCC, but as you said it will not happen itself. Still I believe that through gradual API-zation of different parts of GCC, there will be an eventual convergence to the global and stable API ... Cheers, Grigori -Original Message- From: ctuning-discussi...@googlegroups.com [mailto:ctuning-discussi...@googlegroups.com] On Behalf Of Manuel Lopez-Ibanez Sent: Tuesday, July 06, 2010 6:42 PM To: Grigori Fursin Cc: ctuning-discussi...@googlegroups.com; Joern Rennecke; David Brown; gcc@gcc.gnu.org Subject: Re: Plug-ins on Windows On 6 July 2010 17:54, Grigori Fursin wrote: >>I view the current plug-in mechanism as a prototype. I think that we >>should be working toward a much more robust mechanism, similar to >>plug-ins for Eclipse, Firefox, MySQL, or other popular software stacks. >>I certainly see no reason that plug-ins cannot work on any system that >>has something roughly equivalent to dlopen (which Windows and OS X >>certainly do). There's lots of prior art here. >> >>The key change we need to make is that instead of the current >>"unstructured" approach where we essentially expose the entirety of the >>GCC internals, we provide a stable, documented API that exposes a >>portion of the internals. (It's fine with me if there's an expert mode >>in which you can do anything you want, but it should be easy to stay >>within the stable API if you want to do that.) I would start with an >>API for "observing" (rather than modifying) the internal representation, >> and add modification later. "We need to make"? Are there any plans (or even interest) on designing such an API in the future? My understanding is that we hope an API will slowly arise from the requirements of external tools. So plugins' authors should not wait for such an API but instead start proposing it, ideally, with patches. >>With observation alone, you could start to build interesting >>static-checking tools, including, for example, domain-specific tools >>that could check requirements of the Linux kernel. This would be a >>powerful and exciting feature to have in GCC. > > Agree with this vision, but it will take some time I guess ;) ... I don't think it requires time. It requires people asking for it and working on it. Current GCC developers do not need this and they will not work on this (as far as I know), so no one should be waiting for such tools to magically appear. However, now that the plugins framework is in-place, anyone is welcome to not only develop such tools but to propose changes that make developing such tools easier. The plugins framework is a statement of the willingness of the GCC community, despite the initial opposition from the FSF, to open the project to external contributions and usages. GCC internals have been (and are still being) renovated, and there is ongoing work to make GCC more modular. However, if there is no one proposing the particular changes required by external usages, those changes won't be made. This is also a warning against working around and second-guessing GCC. Please, don't. Instead contribute the changes (API, code, and documentation) required to make GCC more open and easier to use. I know that this is the hardest route, but it is the only one that makes us progress. Cheers, Manuel. -- You received this message because you are subscribed to the Google Groups "ctuning-discussions" group. To post to this group, send email to ctuning-discussi...@googlegroups.com. To unsubscribe from this group, send email to ctuning-discussions+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/ctuning-discussions?hl=en.
Re: Plug-ins on Windows
On 6 July 2010 23:05, Grigori Fursin wrote: > I don't disagree with your comments too, Manuel. > > I spent some years developing plugin framework for pass selection and > reordering, and later we managed to get minimal hooks to mainline GCC based on > our needs. Of course, I personally would like to see a coherent and stable API > for most of the parts of GCC, but as you said it will not happen itself. > Still I believe > that through gradual API-zation of different parts of GCC, there will be an > eventual > convergence to the global and stable API ... Yes, but I would like our language to explicitly encourage external forces to make this happen. Even despite (perceived or real) resistance from "the powers that decide" in GCC, progress happens when enough people push for it (in the right way and with the right force, just pushing will get you nowhere). So I would prefer that GCC developers do not say "We want to provide an API" when what is actually meant is "We will be happy if people contribute patches towards providing an API". The first gives the impression that people wishing for such API just have to sit and wait. When nothing happens, they will feel frustrated and betrayed. The latter invites those same people to scratch their itch by working together with the GCC community. "Together" means progressively and interactively, dumping a complete API design+huge patch will certainly fail. Cheers, Manuel.
gcc-4.4-20100706 is now available
Snapshot gcc-4.4-20100706 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100706/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 161892 You'll find: gcc-4.4-20100706.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20100706.tar.bz2 C front end and core compiler gcc-ada-4.4-20100706.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20100706.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20100706.tar.bz2 C++ front end and runtime gcc-java-4.4-20100706.tar.bz2 Java front end and runtime gcc-objc-4.4-20100706.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20100706.tar.bz2The GCC testsuite Diffs from 4.4-20100629 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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: Plug-ins on Windows
Manuel López-Ibáñez wrote: > So I would prefer that GCC developers do not say "We want to provide > an API" when what is actually meant is "We will be happy if people > contribute patches towards providing an API". OK, I agree with that. As far as I know, nobody right now is actively working on improving the plug-in API in the way that I suggested. So, yes, I would be happy if someone would like to work on that and to contribute patches. I will volunteer to help review patches that move in this direction. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
