public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug tree-optimization/60577] New: inefficient FDO instrumentation code @ 2014-03-19 3:02 carrot at google dot com 2014-03-19 10:02 ` [Bug tree-optimization/60577] [4.9 Regression] " rguenth at gcc dot gnu.org ` (10 more replies) 0 siblings, 11 replies; 12+ messages in thread From: carrot at google dot com @ 2014-03-19 3:02 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577 Bug ID: 60577 Summary: inefficient FDO instrumentation code Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: carrot at google dot com This is actually a regression caused by r175916. Compile the following code with options -O2 -fno-strict-aliasing -fprofile-generate struct thread_param { long* buf; long iterations; long accesses; } param; void access_buf(struct thread_param* p) { long i,j; long iterations = p->iterations; long accesses = p->accesses; for (i=0; i<iterations; i++) { long* pbuf = p->buf; for (j=0; j<accesses; j++) pbuf[j] += 1; } } Trunk gcc generates following for innermost loop: .L9: addq $1, __gcov0.access_buf(%rip) addq $1, (%rax) addq $8, %rax cmpq %rdx, %rax jne .L9 The fdo counter in memory is incremented in each iteration. GCC at revision r175915 generates following for innermost loop movq .LPBX1(%rip), %rsi ... .L4: addq $1, (%rax) addq $8, %rax cmpq %rdx, %rax jne .L4 leaq 1(%rsi,%r9), %rsi ... movq %rsi, .LPBX1(%rip) The fdo counter doesn't bring any overhead to the innermost loop. GCC at revision r175916 generates following for innermost loop movq .LPBX1(%rip), %rcx xorl %eax, %eax leaq 1(%rcx), %r8 .p2align 4,,10 .p2align 3 .L4: leaq (%r8,%rax), %rcx movq %rcx, .LPBX1(%rip) addq $1, (%rdx,%rax,8) addq $1, %rax cmpq %rsi, %rax jne .L4 The fdo counter is incremented and written to memory in each iteration. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug tree-optimization/60577] [4.9 Regression] inefficient FDO instrumentation code 2014-03-19 3:02 [Bug tree-optimization/60577] New: inefficient FDO instrumentation code carrot at google dot com @ 2014-03-19 10:02 ` rguenth at gcc dot gnu.org 2014-03-19 10:54 ` [Bug tree-optimization/60577] [4.7/4.8/4.9 " rguenth at gcc dot gnu.org ` (9 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: rguenth at gcc dot gnu.org @ 2014-03-19 10:02 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Last reconfirmed| |2014-03-19 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|inefficient FDO |[4.9 Regression] |instrumentation code |inefficient FDO | |instrumentation code Ever confirmed|0 |1 --- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> --- I will have a look. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug tree-optimization/60577] [4.7/4.8/4.9 Regression] inefficient FDO instrumentation code 2014-03-19 3:02 [Bug tree-optimization/60577] New: inefficient FDO instrumentation code carrot at google dot com 2014-03-19 10:02 ` [Bug tree-optimization/60577] [4.9 Regression] " rguenth at gcc dot gnu.org @ 2014-03-19 10:54 ` rguenth at gcc dot gnu.org 2014-03-19 11:51 ` rguenth at gcc dot gnu.org ` (8 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: rguenth at gcc dot gnu.org @ 2014-03-19 10:54 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nathan at acm dot org --- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- In 4.6 for some unknown reason we are able to disambiguate *.LPBX1[0] and p_3(D)->buf and *D.1606_14 we built the static decls with !TREE_ADDRESSABLE, but starting with 4.7 we unconditionally set TREE_ADDRESSABLE on the decl (which formerly was only set in case we asked for the address of it via tree_coverage_counter_addr). This happened with the big re-org in r181105 but undoing that change does not fix the regression. This is because the TREE_ADDRESSABLE flag is set again in canonicalize_constructor_val: #0 0x0000000000932775 in canonicalize_constructor_val ( cval=<addr_expr 0x7ffff6d74900>, from_decl=<tree 0x0>) at /space/rguenther/src/svn/trunk/gcc/gimple-fold.c:207 #1 0x0000000000798015 in record_reference (tp=0x7ffff6d73698, walk_subtrees=0x7fffffffd858, data=0x7fffffffdb50) at /space/rguenther/src/svn/trunk/gcc/cgraphbuild.c:62 #2 0x0000000000e6859f in walk_tree_1 (tp=0x7ffff6d73698, func=0x797fdd <record_reference(tree*, int*, void*)>, data=0x7fffffffdb50, pset=0x1ea9240, lh=0x0) at /space/rguenther/src/svn/trunk/gcc/tree.c:10921 #3 0x0000000000e6892c in walk_tree_1 (tp=0x7ffff6d736d0, func=0x797fdd <record_reference(tree*, int*, void*)>, data=0x7fffffffdb50, pset=0x1ea9240, lh=0x0) at /space/rguenther/src/svn/trunk/gcc/tree.c:10998 #4 0x0000000000e6892c in walk_tree_1 (tp=0x7ffff6d78808, func=0x797fdd <record_reference(tree*, int*, void*)>, data=0x7fffffffdb50, pset=0x1ea9240, lh=0x0) at /space/rguenther/src/svn/trunk/gcc/tree.c:10998 #5 0x0000000000e6892c in walk_tree_1 (tp=0x7ffff6d788a0, func=0x797fdd <record_reference(tree*, int*, void*)>, data=0x7fffffffdb50, pset=0x1ea9240, lh=0x0) at /space/rguenther/src/svn/trunk/gcc/tree.c:10998 #6 0x0000000000798d82 in record_references_in_initializer ( decl=<var_decl 0x7ffff6d78850 __gcov_.access_buf>, only_vars=false) at /space/rguenther/src/svn/trunk/gcc/cgraphbuild.c:435 #7 0x0000000000eac7fa in varpool_analyze_node (node=0x7ffff6d498f0) at /space/rguenther/src/svn/trunk/gcc/varpool.c:398 thus we _do_ take the address of the variable, from the global constructor of __gcov.access_buf which looks like {.D.1783=&*.LPBX0, .D.1784=1, .D.1785=4186437761, .D.1786=449688241, .D.1787={{.D.1780=3, .D.1781=&__gcov0.access_buf}, {.D.1780=1, .D.1781=&__gcov8.access_buf}}} thus indeed p->buf may point to __gcov0.access_buf[1] and we can't optimize those accesses. This object was simply not present in GCC 4.6 and thus TREE_ADDRESSABLE was never set and thus we could optimize this. Which means the revision cited doesn't cause the regression (I highly doubt so at least), but instead whoever added code to build that record or whoever added code to record references in initializers (and set TREE_ADDRESSABLE in that path... - coverage.c fails to do that and builds a lot of addresses from the counters in places). The idea of canonicalize_constructor_value is that the result will end up in actual stmts, thus the addressable flag is important. In this case we only record references for the IPA references struct - thus setting the flag there isn't important (well, that's not entirely true ... alias disambiguation depends on the order of processing functions then). Fixing both fixes the regression. Index: gcc/coverage.c =================================================================== --- gcc/coverage.c (revision 208642) +++ gcc/coverage.c (working copy) @@ -466,6 +466,8 @@ tree_coverage_counter_addr (unsigned cou gcc_assert (no < fn_n_ctrs[counter] - fn_b_ctrs[counter]); no += fn_b_ctrs[counter]; + TREE_ADDRESSABLE (fn_v_ctrs[counter]) = 1; + /* "no" here is an array index, scaled to bytes later. */ return build_fold_addr_expr (build4 (ARRAY_REF, gcov_type_node, fn_v_ctrs[counter], @@ -720,7 +722,6 @@ build_var (tree fn_decl, tree type, int memcpy (buf + len, fn_name, fn_name_len + 1); DECL_NAME (var) = get_identifier (buf); TREE_STATIC (var) = 1; - TREE_ADDRESSABLE (var) = 1; DECL_ALIGN (var) = TYPE_ALIGN (type); return var; Index: gcc/gimple-fold.h =================================================================== --- gcc/gimple-fold.h (revision 208642) +++ gcc/gimple-fold.h (working copy) @@ -22,6 +22,7 @@ along with GCC; see the file COPYING3. #ifndef GCC_GIMPLE_FOLD_H #define GCC_GIMPLE_FOLD_H +extern tree canonicalize_constructor_val_1 (tree, tree, bool); extern tree canonicalize_constructor_val (tree, tree); extern tree get_symbol_constant_value (tree); extern void gimplify_and_update_call_from_tree (gimple_stmt_iterator *, tree); Index: gcc/gimple-fold.c =================================================================== --- gcc/gimple-fold.c (revision 208642) +++ gcc/gimple-fold.c (working copy) @@ -169,7 +169,8 @@ can_refer_decl_in_current_unit_p (tree d FROM_DECL (if non-NULL) specify variable whose constructor contains CVAL. */ tree -canonicalize_constructor_val (tree cval, tree from_decl) +canonicalize_constructor_val_1 (tree cval, tree from_decl, + bool mark_addressable) { tree orig_cval = cval; STRIP_NOPS (cval); @@ -203,7 +204,8 @@ canonicalize_constructor_val (tree cval, || TREE_CODE (base) == FUNCTION_DECL) && !can_refer_decl_in_current_unit_p (base, from_decl)) return NULL_TREE; - if (TREE_CODE (base) == VAR_DECL) + if (TREE_CODE (base) == VAR_DECL + && mark_addressable) TREE_ADDRESSABLE (base) = 1; else if (TREE_CODE (base) == FUNCTION_DECL) { @@ -225,6 +227,12 @@ canonicalize_constructor_val (tree cval, return orig_cval; } +tree +canonicalize_constructor_val (tree cval, tree from_decl) +{ + return canonicalize_constructor_val_1 (cval, from_decl, true); +} + /* If SYM is a constant variable with known value, return the value. NULL_TREE is returned otherwise. */ but I am not sure this is a valid thing to do... (I can imagine producing a testcase that breaks with the delayed TREE_ADDRESSABLE setting) Why do we have to record addresses of these arrays? ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug tree-optimization/60577] [4.7/4.8/4.9 Regression] inefficient FDO instrumentation code 2014-03-19 3:02 [Bug tree-optimization/60577] New: inefficient FDO instrumentation code carrot at google dot com 2014-03-19 10:02 ` [Bug tree-optimization/60577] [4.9 Regression] " rguenth at gcc dot gnu.org 2014-03-19 10:54 ` [Bug tree-optimization/60577] [4.7/4.8/4.9 " rguenth at gcc dot gnu.org @ 2014-03-19 11:51 ` rguenth at gcc dot gnu.org 2014-03-19 12:04 ` rguenth at gcc dot gnu.org ` (7 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: rguenth at gcc dot gnu.org @ 2014-03-19 11:51 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577 --- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- So - if we delay marking any decl addressable during IPA reference recording then we need an IPA pass that computes whether any of the taken IPA_REF_ADDR may leak into the IL. We need to do that conservatively before any alias queries (thus eventually again at WPA stage to optimize more). So if there isn't any reference to __gcov_.access_buf inside the program this would make us optimize things again. But there is one from .LPBX1 in the testcase which is refered to from .LPBX0 which is refered from _GLOBAL__sub_I_65535_0_access_buf, so it doesn't help ... (and it seems it really is necessary to have those addresses) Considering LTO-ing libgcov there is no way we can magically mark those decls to be disregarded from alias analysis either. Which leaves the possibility of more cleverly instrumenting the program in the first place ... ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug tree-optimization/60577] [4.7/4.8/4.9 Regression] inefficient FDO instrumentation code 2014-03-19 3:02 [Bug tree-optimization/60577] New: inefficient FDO instrumentation code carrot at google dot com ` (2 preceding siblings ...) 2014-03-19 11:51 ` rguenth at gcc dot gnu.org @ 2014-03-19 12:04 ` rguenth at gcc dot gnu.org 2014-03-19 12:36 ` rguenth at gcc dot gnu.org ` (6 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: rguenth at gcc dot gnu.org @ 2014-03-19 12:04 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577 --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Richard Biener from comment #3) > Which leaves the possibility of more cleverly instrumenting the program > in the first place ... Which shouldn't be so hard as we are in SSA form and have loop structures set up. But it's of course "old" code (profile.c:branch_prob) which was written with "only" a CFG in mind. Unfortunately the code chooses to instrument a non-latch edge in the testcase (loop latches would have been easy to special-case in gimple_gen_edge_profiler). This is the other edge out of a block with a loop exit - so we can special-case single-exit loops that have such edge instrumented where the edge source dominates the loop latch. Or find some even more clever way of placing the loads / stores (you can always use a scalar as counter and load/store in a dominating / post-dominating block of course, but that may have detrimental effects on register pressure ...). Maybe still do that, but only if the counter update is in a loop. Note that applying store motion here may introduce no-op load/store which may have issues with thread safety. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug tree-optimization/60577] [4.7/4.8/4.9 Regression] inefficient FDO instrumentation code 2014-03-19 3:02 [Bug tree-optimization/60577] New: inefficient FDO instrumentation code carrot at google dot com ` (3 preceding siblings ...) 2014-03-19 12:04 ` rguenth at gcc dot gnu.org @ 2014-03-19 12:36 ` rguenth at gcc dot gnu.org 2014-03-20 11:36 ` rguenth at gcc dot gnu.org ` (5 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: rguenth at gcc dot gnu.org @ 2014-03-19 12:36 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577 --- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- Created attachment 32393 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32393&action=edit hack Like this (hack alert). Applies store motion one level for a restricted set of loops. Requires us to add preheaders and record exits (and disambiguate multiple latches) and compute dominators. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug tree-optimization/60577] [4.7/4.8/4.9 Regression] inefficient FDO instrumentation code 2014-03-19 3:02 [Bug tree-optimization/60577] New: inefficient FDO instrumentation code carrot at google dot com ` (4 preceding siblings ...) 2014-03-19 12:36 ` rguenth at gcc dot gnu.org @ 2014-03-20 11:36 ` rguenth at gcc dot gnu.org 2014-03-21 11:53 ` [Bug tree-optimization/60577] [4.7/4.8 " rguenth at gcc dot gnu.org ` (4 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: rguenth at gcc dot gnu.org @ 2014-03-20 11:36 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577 --- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> --- Created attachment 32403 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32403&action=edit alternative patch This restores previous behavior by considering all coverage/profile related counters to not alias with any other access through a pointer. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug tree-optimization/60577] [4.7/4.8 Regression] inefficient FDO instrumentation code 2014-03-19 3:02 [Bug tree-optimization/60577] New: inefficient FDO instrumentation code carrot at google dot com ` (5 preceding siblings ...) 2014-03-20 11:36 ` rguenth at gcc dot gnu.org @ 2014-03-21 11:53 ` rguenth at gcc dot gnu.org 2014-03-21 11:53 ` rguenth at gcc dot gnu.org ` (3 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: rguenth at gcc dot gnu.org @ 2014-03-21 11:53 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Known to work| |4.9.0 Summary|[4.7/4.8/4.9 Regression] |[4.7/4.8 Regression] |inefficient FDO |inefficient FDO |instrumentation code |instrumentation code --- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> --- Fixed on trunk. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug tree-optimization/60577] [4.7/4.8 Regression] inefficient FDO instrumentation code 2014-03-19 3:02 [Bug tree-optimization/60577] New: inefficient FDO instrumentation code carrot at google dot com ` (6 preceding siblings ...) 2014-03-21 11:53 ` [Bug tree-optimization/60577] [4.7/4.8 " rguenth at gcc dot gnu.org @ 2014-03-21 11:53 ` rguenth at gcc dot gnu.org 2014-04-22 11:38 ` jakub at gcc dot gnu.org ` (2 subsequent siblings) 10 siblings, 0 replies; 12+ messages in thread From: rguenth at gcc dot gnu.org @ 2014-03-21 11:53 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577 --- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> --- Author: rguenth Date: Fri Mar 21 11:52:50 2014 New Revision: 208746 URL: http://gcc.gnu.org/viewcvs?rev=208746&root=gcc&view=rev Log: 2014-03-21 Richard Biener <rguenther@suse.de> PR tree-optimization/60577 * tree-core.h (struct tree_base): Document nothrow_flag use in VAR_DECL_NONALIASED. * tree.h (VAR_DECL_NONALIASED): New. (may_be_aliased): Adjust. * coverage.c (build_var): Set VAR_DECL_NONALIASED. * gcc.dg/tree-ssa/ssa-lim-11.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-11.c Modified: trunk/gcc/ChangeLog trunk/gcc/coverage.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-core.h trunk/gcc/tree.h ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug tree-optimization/60577] [4.7/4.8 Regression] inefficient FDO instrumentation code 2014-03-19 3:02 [Bug tree-optimization/60577] New: inefficient FDO instrumentation code carrot at google dot com ` (7 preceding siblings ...) 2014-03-21 11:53 ` rguenth at gcc dot gnu.org @ 2014-04-22 11:38 ` jakub at gcc dot gnu.org 2014-07-16 13:31 ` [Bug tree-optimization/60577] [4.8 " jakub at gcc dot gnu.org 2014-10-30 10:43 ` jakub at gcc dot gnu.org 10 siblings, 0 replies; 12+ messages in thread From: jakub at gcc dot gnu.org @ 2014-04-22 11:38 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|4.9.0 |4.9.1 --- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> --- GCC 4.9.0 has been released ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug tree-optimization/60577] [4.8 Regression] inefficient FDO instrumentation code 2014-03-19 3:02 [Bug tree-optimization/60577] New: inefficient FDO instrumentation code carrot at google dot com ` (8 preceding siblings ...) 2014-04-22 11:38 ` jakub at gcc dot gnu.org @ 2014-07-16 13:31 ` jakub at gcc dot gnu.org 2014-10-30 10:43 ` jakub at gcc dot gnu.org 10 siblings, 0 replies; 12+ messages in thread From: jakub at gcc dot gnu.org @ 2014-07-16 13:31 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|4.9.1 |4.9.2 --- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> --- GCC 4.9.1 has been released. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug tree-optimization/60577] [4.8 Regression] inefficient FDO instrumentation code 2014-03-19 3:02 [Bug tree-optimization/60577] New: inefficient FDO instrumentation code carrot at google dot com ` (9 preceding siblings ...) 2014-07-16 13:31 ` [Bug tree-optimization/60577] [4.8 " jakub at gcc dot gnu.org @ 2014-10-30 10:43 ` jakub at gcc dot gnu.org 10 siblings, 0 replies; 12+ messages in thread From: jakub at gcc dot gnu.org @ 2014-10-30 10:43 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60577 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|4.9.2 |4.9.3 --- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> --- GCC 4.9.2 has been released. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-10-30 10:43 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-03-19 3:02 [Bug tree-optimization/60577] New: inefficient FDO instrumentation code carrot at google dot com 2014-03-19 10:02 ` [Bug tree-optimization/60577] [4.9 Regression] " rguenth at gcc dot gnu.org 2014-03-19 10:54 ` [Bug tree-optimization/60577] [4.7/4.8/4.9 " rguenth at gcc dot gnu.org 2014-03-19 11:51 ` rguenth at gcc dot gnu.org 2014-03-19 12:04 ` rguenth at gcc dot gnu.org 2014-03-19 12:36 ` rguenth at gcc dot gnu.org 2014-03-20 11:36 ` rguenth at gcc dot gnu.org 2014-03-21 11:53 ` [Bug tree-optimization/60577] [4.7/4.8 " rguenth at gcc dot gnu.org 2014-03-21 11:53 ` rguenth at gcc dot gnu.org 2014-04-22 11:38 ` jakub at gcc dot gnu.org 2014-07-16 13:31 ` [Bug tree-optimization/60577] [4.8 " jakub at gcc dot gnu.org 2014-10-30 10:43 ` jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).