Re: [PATCH] Avoid too complex debug insns during expansion (PR debug/56510)
On Tue, 5 Mar 2013, Jakub Jelinek wrote:
Hi!
cselib (probably among others) isn't prepared to handle arbitrarily
complex debug insns. The debug insns are usually created from debug stmts
which shouldn't have unbound complexity, but with TER we can actually end up
with arbitrarily large debug insns.
This patch fixes that up during expansion, by splitting subexpressions of
too large debug insn expressions into their own debug temporaries.
So far bootstrapped/regtested on x86_64-linux and i686-linux without the
first two hunks (it caused one failure on the latter because of invalid RTL
sharing), I'm going to bootstrap/regtest it again, ok for trunk if it
passes?
Works for me.
Richard.
2013-03-05 Jakub Jelinek ja...@redhat.com
PR debug/56510
* cfgexpand.c (expand_debug_parm_decl): Call copy_rtx on incoming.
(avoid_complex_debug_insns): New function.
(expand_debug_locations): Call it.
* gcc.dg/pr56510.c: New test.
--- gcc/cfgexpand.c.jj2013-03-05 15:12:15.071565689 +0100
+++ gcc/cfgexpand.c 2013-03-05 17:21:55.683602432 +0100
@@ -2622,6 +2622,8 @@ expand_debug_parm_decl (tree decl)
reg = gen_raw_REG (GET_MODE (reg), OUTGOING_REGNO (REGNO (reg)));
incoming = replace_equiv_address_nv (incoming, reg);
}
+ else
+ incoming = copy_rtx (incoming);
}
#endif
@@ -2637,7 +2639,7 @@ expand_debug_parm_decl (tree decl)
|| (GET_CODE (XEXP (incoming, 0)) == PLUS
XEXP (XEXP (incoming, 0), 0) == virtual_incoming_args_rtx
CONST_INT_P (XEXP (XEXP (incoming, 0), 1)
-return incoming;
+return copy_rtx (incoming);
return NULL_RTX;
}
@@ -3704,6 +3706,54 @@ expand_debug_source_expr (tree exp)
return op0;
}
+/* Ensure INSN_VAR_LOCATION_LOC (insn) doesn't have unbound complexity.
+ Allow 4 levels of rtl nesting for most rtl codes, and if we see anything
+ deeper than that, create DEBUG_EXPRs and emit DEBUG_INSNs before INSN. */
+
+static void
+avoid_complex_debug_insns (rtx insn, rtx *exp_p, int depth)
+{
+ rtx exp = *exp_p;
+ if (exp == NULL_RTX)
+return;
+ if ((OBJECT_P (exp) !MEM_P (exp)) || GET_CODE (exp) == CLOBBER)
+return;
+
+ if (depth == 4)
+{
+ /* Create DEBUG_EXPR (and DEBUG_EXPR_DECL). */
+ rtx dval = make_debug_expr_from_rtl (exp);
+
+ /* Emit a debug bind insn before INSN. */
+ rtx bind = gen_rtx_VAR_LOCATION (GET_MODE (exp),
+DEBUG_EXPR_TREE_DECL (dval), exp,
+VAR_INIT_STATUS_INITIALIZED);
+
+ emit_debug_insn_before (bind, insn);
+ *exp_p = dval;
+ return;
+}
+
+ const char *format_ptr = GET_RTX_FORMAT (GET_CODE (exp));
+ int i, j;
+ for (i = 0; i GET_RTX_LENGTH (GET_CODE (exp)); i++)
+switch (*format_ptr++)
+ {
+ case 'e':
+ avoid_complex_debug_insns (insn, XEXP (exp, i), depth + 1);
+ break;
+
+ case 'E':
+ case 'V':
+ for (j = 0; j XVECLEN (exp, i); j++)
+ avoid_complex_debug_insns (insn, XVECEXP (exp, i, j), depth + 1);
+ break;
+
+ default:
+ break;
+ }
+}
+
/* Expand the _LOCs in debug insns. We run this after expanding all
regular insns, so that any variables referenced in the function
will have their DECL_RTLs set. */
@@ -3724,7 +3774,7 @@ expand_debug_locations (void)
if (DEBUG_INSN_P (insn))
{
tree value = (tree)INSN_VAR_LOCATION_LOC (insn);
- rtx val;
+ rtx val, prev_insn, insn2;
enum machine_mode mode;
if (value == NULL_TREE)
@@ -3753,6 +3803,9 @@ expand_debug_locations (void)
}
INSN_VAR_LOCATION_LOC (insn) = val;
+ prev_insn = PREV_INSN (insn);
+ for (insn2 = insn; insn2 != prev_insn; insn2 = PREV_INSN (insn2))
+ avoid_complex_debug_insns (insn2, INSN_VAR_LOCATION_LOC (insn2), 0);
}
flag_strict_aliasing = save_strict_alias;
--- gcc/testsuite/gcc.dg/pr56510.c.jj 2013-03-05 16:57:54.498939220 +0100
+++ gcc/testsuite/gcc.dg/pr56510.c2013-03-05 16:57:54.499939214 +0100
@@ -0,0 +1,37 @@
+/* PR debug/56510 */
+/* { dg-do compile } */
+/* { dg-options -O2 -g } */
+
+struct S { unsigned long s1; void **s2[0]; };
+void **a, **b, **c, **d, **e, **f;
+
+static void **
+baz (long x, long y)
+{
+ void **s = f;
+ *f = (void **) (y 8 | (x 0xff));
+ f += y + 1;
+ return s;
+}
+
+void bar (void);
+void
+foo (void)
+{
+ void **g = b[4];
+ a = b[2];
+ b = b[1];
+ g[2] = e;
+ void **h
+= ((void **)
+
a)[1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][1][66];
+ void **i = ((struct S *) h)-s2[4];
+ d = baz (4, 3);
+ d[1] = b;
+ d[2] = a;
+ d[3] = bar;
+ b = d;
+ g[1] = i[2];
+ a = g;
+ ((void (*) (void)) (i[1])) ();
+}
Jakub
--
[PATCH] Fix install-plugin on arm and aarch64
Hi! https://bugzilla.redhat.com/show_bug.cgi?id=910926 reports that plugins aren't usable on arm, because arm-cores.def isn't installed into the plugins directory. arm-cores.def can't be included in tm_file list, because we don't want to include it directly, nor in HeaderInclude in arm.opt (that breaks the build). rs6000 has similar issue with its rs6000-builtin.def, and solves this by adding content to TM_H in Makefile fragment. Thus, the following patch does the same for arm (and apparently aarch64 has the same issue). Ok for trunk? 2013-03-06 Jakub Jelinek ja...@redhat.com * config/aarch64/t-aarch64 (TM_H, OPTIONS_H_EXTRA): Add aarch64-cores.def. * config/arm/t-arm (TM_H, OPTIONS_H_EXTRA): Add arm-cores.def. --- gcc/config/aarch64/t-aarch64.jj 2013-02-24 19:44:07.0 +0100 +++ gcc/config/aarch64/t-aarch642013-03-06 09:42:31.568042231 +0100 @@ -18,6 +18,9 @@ # along with GCC; see the file COPYING3. If not see # http://www.gnu.org/licenses/. +TM_H += $(srcdir)/config/aarch64/aarch64-cores.def +OPTIONS_H_EXTRA += $(srcdir)/config/aarch64/aarch64-cores.def + $(srcdir)/config/aarch64/aarch64-tune.md: $(srcdir)/config/aarch64/gentune.sh \ $(srcdir)/config/aarch64/aarch64-cores.def $(SHELL) $(srcdir)/config/aarch64/gentune.sh \ --- gcc/config/arm/t-arm.jj 2013-01-11 09:03:13.0 +0100 +++ gcc/config/arm/t-arm2013-03-06 09:41:09.607528642 +0100 @@ -18,6 +18,9 @@ # along with GCC; see the file COPYING3. If not see # http://www.gnu.org/licenses/. +TM_H += $(srcdir)/config/arm/arm-cores.def +OPTIONS_H_EXTRA += $(srcdir)/config/arm/arm-cores.def + # All md files - except for arm.md. # This list should be kept in alphabetical order and updated whenever an md # file is added or removed. Jakub [A
Re: [PATCH] Fix install-plugin on arm and aarch64
On 06/03/13 09:07, Jakub Jelinek wrote: Hi! https://bugzilla.redhat.com/show_bug.cgi?id=910926 reports that plugins aren't usable on arm, because arm-cores.def isn't installed into the plugins directory. arm-cores.def can't be included in tm_file list, because we don't want to include it directly, nor in HeaderInclude in arm.opt (that breaks the build). rs6000 has similar issue with its rs6000-builtin.def, and solves this by adding content to TM_H in Makefile fragment. Thus, the following patch does the same for arm (and apparently aarch64 has the same issue). Ok for trunk? 2013-03-06 Jakub Jelinek ja...@redhat.com * config/aarch64/t-aarch64 (TM_H, OPTIONS_H_EXTRA): Add aarch64-cores.def. * config/arm/t-arm (TM_H, OPTIONS_H_EXTRA): Add arm-cores.def. --- gcc/config/aarch64/t-aarch64.jj 2013-02-24 19:44:07.0 +0100 +++ gcc/config/aarch64/t-aarch642013-03-06 09:42:31.568042231 +0100 @@ -18,6 +18,9 @@ # along with GCC; see the file COPYING3. If not see # http://www.gnu.org/licenses/. +TM_H += $(srcdir)/config/aarch64/aarch64-cores.def +OPTIONS_H_EXTRA += $(srcdir)/config/aarch64/aarch64-cores.def + $(srcdir)/config/aarch64/aarch64-tune.md: $(srcdir)/config/aarch64/gentune.sh \ $(srcdir)/config/aarch64/aarch64-cores.def $(SHELL) $(srcdir)/config/aarch64/gentune.sh \ --- gcc/config/arm/t-arm.jj 2013-01-11 09:03:13.0 +0100 +++ gcc/config/arm/t-arm2013-03-06 09:41:09.607528642 +0100 @@ -18,6 +18,9 @@ # along with GCC; see the file COPYING3. If not see # http://www.gnu.org/licenses/. +TM_H += $(srcdir)/config/arm/arm-cores.def +OPTIONS_H_EXTRA += $(srcdir)/config/arm/arm-cores.def + # All md files - except for arm.md. # This list should be kept in alphabetical order and updated whenever an md # file is added or removed. Jakub [A AArch64 patch is OK. ARM looks fine but I can't OK that one. Cheers /Marcus
[PATCH] Fix update-ssa issue with -g vs. -g0 (PR56294)
The testcase in PR56294 shows that we may not depend on the
order symbols are registered for renaming for inserting new
PHI nodes for them. Instead we should always insert them
in order of their symbol UID. This is a regression from the
referenced_vars removal series as that introduced the
vec of to-be renamed symbols.
Bootstrap and regtest with -fno-ipa-sra running on
x86_64-unknown-linux-gnu.
Diego: we have vec.qsort (), but why does that insist on that
awful const void * argument interface ... some trivial template
forwarding (or use of std::qsort?) should be able to fix that.
Richard.
2013-03-06 Richard Biener rguent...@suse.de
PR middle-end/56294
* tree-into-ssa.c (insert_phi_nodes_for): Add dumping.
(insert_updated_phi_nodes_compare_uids): New function.
(update_ssa): Sort symbols_to_rename after UID before
traversing it to insert PHI nodes.
Index: gcc/tree-into-ssa.c
===
*** gcc/tree-into-ssa.c (revision 196487)
--- gcc/tree-into-ssa.c (working copy)
*** insert_phi_nodes_for (tree var, bitmap p
*** 969,974
--- 969,980
if (update_p)
mark_block_for_update (bb);
+ if (dump_file (dump_flags TDF_DETAILS))
+ {
+ fprintf (dump_file, creating PHI node in block #%d for , bb_index);
+ print_generic_expr (dump_file, var, TDF_SLIM);
+ fprintf (dump_file, \n);
+ }
phi = NULL;
if (TREE_CODE (var) == SSA_NAME)
*** insert_updated_phi_nodes_for (tree var,
*** 3040,3045
--- 3046,3062
BITMAP_FREE (idf);
}
+ /* Sort symbols_to_rename after their DECL_UID. */
+
+ static int
+ insert_updated_phi_nodes_compare_uids (const void *a, const void *b)
+ {
+ const_tree syma = *(const_tree *)a;
+ const_tree symb = *(const_tree *)b;
+ if (DECL_UID (syma) == DECL_UID (symb))
+ return 0;
+ return DECL_UID (syma) DECL_UID (symb) ? -1 : 1;
+ }
/* Given a set of newly created SSA names (NEW_SSA_NAMES) and a set of
existing SSA names (OLD_SSA_NAMES), update the SSA form so that:
*** update_ssa (unsigned update_flags)
*** 3250,3255
--- 3267,3273
sbitmap_free (tmp);
}
+ symbols_to_rename.qsort (insert_updated_phi_nodes_compare_uids);
FOR_EACH_VEC_ELT (symbols_to_rename, i, sym)
insert_updated_phi_nodes_for (sym, dfs, blocks_to_update,
update_flags);
Re: [patch][RFC] bitmaps as lists *or* trees
On Tue, Mar 5, 2013 at 5:16 PM, Steven Bosscher stevenb@gmail.com wrote: On Tue, Mar 5, 2013 at 3:48 PM, Michael Matz wrote: Iteration isn't easy on trees without a pointer to the parent (i.e. enlarging each node), you need to remember variably sized context in the iterator (e.g. the current stack of nodes). I was thinking of just making the tree a single forward-linked list, that's a valid splay tree and one that is compatible with the iterators, at least as long as the iterated bitmap are not modified (but I think that isn't allowed anyway?). Obviously the tree is not very well balanced after that, but splay trees have a way of re-balancing themselves quickly. The other possibility is to create vecs of bitmap_elements up front, but such iterators (fat iterators, as Richi just now called them in another mail :-) have the downside that you must always visit all bitmap elements, even if you want to be able to break the iteration before reaching the end. I do like the idea of reusing the same internal data structure to implement the tree. And I'm wondering about performance impact, I wouldn't be surprised either way (i.e. that it brings about a large improvement, or none at all), most bitmap membership tests in GCC are surprisingly clustered so that the bitmaps cache of last accessed element can work its magic (not all of them, as the testcase shows of course :) ). I've retained the cached last accessed element. In fact it's now cached twice, because the root of the splay tree is always the last accessed element. I've considered *not* updating bitmap-current if bitmap_tree_find_element doesn't find the element it's looking for. That way, the last accessed element would be the element that was *really* last accessed, i.e. with a valid membership test, instead of the element closest to the last tested bit. Not sure if that'd be a good idea. Anyway, updated patch attached. It compiles all my cc1-i files, and it compiles the PR55135 test case, in 410s (I terminated cc1plus unpatched after 7200s, more than 2 hours...). An interesting question is, how can you identify bitmaps that could benefit from viewing it as a tree (at least for some time). I have no ideas here. Something with detailed memory stats, of course, but then how to derive some measure for a trade-off between list or tree view. Thoughts? That's indeed a good question. The mem-stats help to print a useful location for where the bitmap was allocated. But whether to switch it or not is more fine-grained - any iteration / bitwise op should reset the stats we collect. For the rest I'd simply count # of elements walked for the find vs. # of splays done (where of course a splay is more expensive than a linked list element walk). That vs. of course doesn't work because we don't have both views at the same time, but counting the list walks vs. the number of searches would be a start (doesn't help deciding whether a switch to a tree was bad and should be undone, of course ... we'd have to compute the distance in bitmap_elts between successive searches). What about simply providing a bitmap_test_set_only () with no way to switch back and let the tree balance itself? Does the splay () overhead matter? Richard. Ciao! Steven
Re: [PATCH] Fix install-plugin on arm and aarch64
Am 06.03.2013 17:07, schrieb Jakub Jelinek: Hi! https://bugzilla.redhat.com/show_bug.cgi?id=910926 reports that plugins aren't usable on arm, because arm-cores.def isn't installed into the plugins directory. arm-cores.def can't be included in tm_file list, because we don't want to include it directly, nor in HeaderInclude in arm.opt (that breaks the build). rs6000 has similar issue with its rs6000-builtin.def, and solves this by adding content to TM_H in Makefile fragment. Thus, the following patch does the same for arm (and apparently aarch64 has the same issue). Ok for trunk? There is still vxworks-dummy.h, which is not installed, see PR45078. Would the same approach work? Matthias
Re: [PATCH] Fix install-plugin on arm and aarch64
On Wed, Mar 06, 2013 at 06:57:03PM +0800, Matthias Klose wrote:
Am 06.03.2013 17:07, schrieb Jakub Jelinek:
https://bugzilla.redhat.com/show_bug.cgi?id=910926
reports that plugins aren't usable on arm, because arm-cores.def isn't
installed into the plugins directory. arm-cores.def can't be included in
tm_file list, because we don't want to include it directly, nor in
HeaderInclude in arm.opt (that breaks the build). rs6000 has similar issue
with its rs6000-builtin.def, and solves this by adding content to TM_H
in Makefile fragment.
Thus, the following patch does the same for arm (and apparently aarch64 has
the same issue). Ok for trunk?
There is still vxworks-dummy.h, which is not installed, see PR45078. Would the
same approach work?
i386/x86_64 solves that by tm_file=vxworks-dummy.h ${tm_file} in
config.gcc. Perhaps arm, mips, sh and sparc should follow that.
Jakub
Re: [v3] Filter out basever symbols on Solaris
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
Andreas Schwab sch...@suse.de writes:
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
diff --git a/libstdc++-v3/scripts/extract_symvers.in
b/libstdc++-v3/scripts/extract_symvers.in
--- a/libstdc++-v3/scripts/extract_symvers.in
+++ b/libstdc++-v3/scripts/extract_symvers.in
@@ -49,9 +49,12 @@ SunOS)
if readelf --help | grep -- --wide /dev/null; then
readelf=$readelf --wide
fi
+ # Omit _DYNAMIC etc. for consistency with extract_symvers.pl, only
+ # present on Solaris.
${readelf} ${lib} |\
sed -e 's/ \[other: [A-Fa-f0-9]*\] //' -e '/\.dynsym/,/^$/p;d' |\
egrep -v ' (LOCAL|UND) ' |\
+ egrep -v
'(_DYNAMIC|_GLOBAL_OFFSET_TABLE_|_PROCEDURE_LINKAGE_TABLE_|_edata|_end|_etext)$'
|\
Shouldn't the regexp also be anchored (with a space) at the beginning?
This works indeed. I was a bit worried if a space was guaranteed at
that position, rather than general whitespace. Consider the patch
amended accordingly.
Any word on this patch? Is has remained unreviewed for a week.
Thanks.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[boehm-gc] Use thr_stksegment to determine Solaris stack base
Since Solaris 11.1/x86, a few 32-bit boehm-gc testcases started to FAIL:
FAIL: boehm-gc.c/gctest.c -O2 execution test
FAIL: boehm-gc.c/leak_test.c -O2 execution test
FAIL: boehm-gc.c/thread_leak_test.c -O2 execution test
FAIL: boehm-gc.lib/staticrootstest.c -O2 execution test
They all SEGV on the first call to GC_mark_from. This turns out to be a
side effect of the virtual memory system rewrite (VM 2.0) in that
Solaris version: one of the very few user-visible changes in that
release was that the 32-bit x86 stack base changed, unfortunately
without updating the USRSTACK definition in sys/vmparam.h.
Unlike the boehm-gc 6.6-based version in the gcc tree, the failure
doesn't happen with gc 7.2c. It turns out that this is case since that
version uses the thr_stksegment(3C) function instead of the macro. This
function exists since at least Solaris 2.5.1 and has the additional
advantage of also working with ASLR also introduced with VM2, where a
fixed stack base is wrong.
This patch fixes the failures by backporting the use of thr_stksegment
from gc 7.2c.
Bootstrapped without regressions on i386-pc-solaris2.{9,10,11} and
sparc-sun-solaris2.{9,10,11}, fixes the i386-pc-solaris2.11 failures.
Ok for mainline?
Rainer
2013-03-04 Rainer Orth r...@cebitec.uni-bielefeld.de
* os_dep.c [SOLARIS_STACKBOTTOM] (GC_solaris_stack_base): New
function.
[!BEOS !AMIGA !MSWIN32 !MSWINCE !OS2 !NOSYS
!ECOS] (GC_get_stack_base): Use it.
* include/private/gcconfig.h [SPARC SUNOS5]
(SOLARIS_STACKBOTTOM): Define.
(STACKBOTTOM, HEURISTIC2): Remove.
[I386 SUNOS5]
(SOLARIS_STACKBOTTOM): Define.
(STACKBOTTOM): Remove.
# HG changeset patch
# Parent 3b82ec434332de00d9006fa3985dd9180c0cf499
Use thr_stksegment to determine Solaris stack base
diff --git a/boehm-gc/include/private/gcconfig.h b/boehm-gc/include/private/gcconfig.h
--- a/boehm-gc/include/private/gcconfig.h
+++ b/boehm-gc/include/private/gcconfig.h
@@ -927,18 +927,7 @@
# define HEAP_START DATAEND
# endif
# define PROC_VDB
-/* HEURISTIC1 reportedly no longer works under 2.7. */
-/* HEURISTIC2 probably works, but this appears to be preferable. */
-/* Apparently USRSTACK is defined to be USERLIMIT, but in some */
-/* installations that's undefined. We work around this with a */
-/* gross hack: */
-# include sys/vmparam.h
-# ifdef USERLIMIT
- /* This should work everywhere, but doesn't. */
-# define STACKBOTTOM USRSTACK
-# else
-# define HEURISTIC2
-# endif
+# define SOLARIS_STACKBOTTOM
# include unistd.h
# define GETPAGESIZE() sysconf(_SC_PAGESIZE)
/* getpagesize() appeared to be missing from at least one */
@@ -1067,13 +1056,7 @@
extern ptr_t GC_SysVGetDataStart();
# define DATASTART GC_SysVGetDataStart(0x1000, _etext)
# define DATAEND (_end)
-/* # define STACKBOTTOM ((ptr_t)(_start)) worked through 2.7, */
-/* but reportedly breaks under 2.8. It appears that the stack */
-/* base is a property of the executable, so this should not break */
-/* old executables. */
-/* HEURISTIC2 probably works, but this appears to be preferable. */
-# include sys/vm.h
-# define STACKBOTTOM USRSTACK
+# define SOLARIS_STACKBOTTOM
/* At least in Solaris 2.5, PROC_VDB gives wrong values for dirty bits. */
/* It appears to be fixed in 2.8 and 2.9.*/
# ifdef SOLARIS25_PROC_VDB_BUG_FIXED
diff --git a/boehm-gc/os_dep.c b/boehm-gc/os_dep.c
--- a/boehm-gc/os_dep.c
+++ b/boehm-gc/os_dep.c
@@ -1008,13 +1008,62 @@ ptr_t GC_get_stack_base()
#endif /* FREEBSD_STACKBOTTOM */
+#ifdef SOLARIS_STACKBOTTOM
+
+# include thread.h
+# include signal.h
+# include pthread.h
+
+ /* These variables are used to cache ss_sp value for the primordial */
+ /* thread (it's better not to call thr_stksegment() twice for this*/
+ /* thread - see JDK bug #4352906).*/
+ static pthread_t stackbase_main_self = 0;
+/* 0 means stackbase_main_ss_sp value is unset. */
+ static void *stackbase_main_ss_sp = NULL;
+
+ ptr_t GC_solaris_stack_base(void)
+ {
+stack_t s;
+pthread_t self = pthread_self();
+if (self == stackbase_main_self)
+ {
+/* If the client calls GC_get_stack_base() from the main thread */
+/* then just return the cached value. */
+GC_ASSERT(stackbase_main_ss_sp != NULL);
+return stackbase_main_ss_sp;
+ }
+
+if (thr_stksegment(s)) {
+ /* According to the manual, the only failure error code returned */
+ /* is EAGAIN meaning the information is not available due to the */
+ /* thread is not yet completely initialized or it is an internal */
+ /* thread - this shouldn't happen here. */
+ ABORT(thr_stksegment failed);
+}
+/* s.ss_sp holds the pointer to the stack bottom. */
+GC_ASSERT((void *)s HOTTER_THAN
Re: [PATCH] Fix g++.dg/debug/dwarf2/thunk1.C on darwin
Jack Howarth howa...@bromo.med.uc.edu writes:
2013-03-05 Jack Howarth howa...@bromo.med.uc.edu
PR debug/53363
* g++.dg/debug/dwarf2/thunk1.C: Skip final scan on darwin.
Index: gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C
===
--- gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C(revision 196462)
+++ gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C(working copy)
@@ -1,7 +1,7 @@
// Test that we don't add the x86 PC thunk to .debug_ranges
// { dg-do compile { target { { i?86-*-* x86_64-*-* } ia32 } } }
// { dg-options -g -fpic -fno-dwarf2-cfi-asm }
-// { dg-final { scan-assembler-times LFB3 5 } }
+// { dg-final { scan-assembler-times LFB3 5 { target { ! *-*-darwin* } } }
}
Why not skip the whole test with dg-skip-if, since the scan is the whole
point of the testcase AFAICT? Also, please add a comment explaining why
the test is skipped, perhaps referencing the PR.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH] Fix install-plugin with vxworks-dummy.h (PR plugins/45078)
Hi!
On Wed, Mar 06, 2013 at 06:57:03PM +0800, Matthias Klose wrote:
There is still vxworks-dummy.h, which is not installed, see PR45078. Would the
same approach work?
Like this? Untested though, and no access to most of the targets.
2013-03-06 Jakub Jelinek ja...@redhat.com
PR plugins/45078
* config.gcc: On arm, mips, sh and sparc add vxworks-dummy.h to
tm_file.
--- gcc/config.gcc.jj 2013-02-22 17:04:41.0 +0100
+++ gcc/config.gcc 2013-03-06 13:38:19.711201446 +0100
@@ -536,6 +536,9 @@ x86_64-*-*)
fi
tm_file=vxworks-dummy.h ${tm_file}
;;
+arm*-*-* | mips*-*-* | sh*-*-* | sparc*-*-*)
+ tm_file=vxworks-dummy.h ${tm_file}
+ ;;
esac
# On a.out targets, we need to use collect2.
@@ -861,7 +864,7 @@ arm-wrs-vxworks)
tmake_file=${tmake_file} arm/t-arm arm/t-vxworks
;;
arm*-*-netbsdelf*)
- tm_file=dbxelf.h elfos.h netbsd.h netbsd-elf.h arm/elf.h arm/aout.h
arm/arm.h arm/netbsd-elf.h
+ tm_file=dbxelf.h elfos.h netbsd.h netbsd-elf.h arm/elf.h arm/aout.h
${tm_file} arm/netbsd-elf.h
extra_options=${extra_options} netbsd.opt netbsd-elf.opt
tmake_file=${tmake_file} arm/t-arm
;;
@@ -873,7 +876,7 @@ arm*-*-linux-*) # ARM GNU/Linux with E
;;
esac
tmake_file=${tmake_file} arm/t-arm arm/t-arm-elf arm/t-bpabi
arm/t-linux-eabi
- tm_file=$tm_file arm/bpabi.h arm/linux-eabi.h arm/aout.h arm/arm.h
+ tm_file=$tm_file arm/bpabi.h arm/linux-eabi.h arm/aout.h
vxworks-dummy.h arm/arm.h
# Define multilib configuration for arm-linux-androideabi.
case ${target} in
*-androideabi)
@@ -891,7 +894,7 @@ arm*-*-linux-*) # ARM GNU/Linux with E
arm*-*-uclinux*eabi*) # ARM ucLinux
tm_file=dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/linux-gas.h
arm/uclinux-elf.h glibc-stdint.h
tmake_file=arm/t-arm arm/t-arm-elf arm/t-bpabi
- tm_file=$tm_file arm/bpabi.h arm/uclinux-eabi.h arm/aout.h arm/arm.h
+ tm_file=$tm_file arm/bpabi.h arm/uclinux-eabi.h arm/aout.h
vxworks-dummy.h arm/arm.h
# The BPABI long long divmod functions return a 128-bit value in
# registers r0-r3. Correctly modeling that requires the use of
# TImode.
@@ -928,7 +931,7 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*
tmake_file=${tmake_file} arm/t-symbian
;;
esac
- tm_file=${tm_file} arm/aout.h arm/arm.h
+ tm_file=${tm_file} arm/aout.h vxworks-dummy.h arm/arm.h
;;
avr-*-rtems*)
tm_file=elfos.h avr/elf.h avr/avr-arch.h avr/avr.h dbxelf.h
avr/rtems.h rtems.h newlib-stdint.h
Jakub
Re: [v3] Filter out basever symbols on Solaris
Hi,
On 03/06/2013 12:08 PM, Rainer Orth wrote:
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
Andreas Schwab sch...@suse.de writes:
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
diff --git a/libstdc++-v3/scripts/extract_symvers.in
b/libstdc++-v3/scripts/extract_symvers.in
--- a/libstdc++-v3/scripts/extract_symvers.in
+++ b/libstdc++-v3/scripts/extract_symvers.in
@@ -49,9 +49,12 @@ SunOS)
if readelf --help | grep -- --wide /dev/null; then
readelf=$readelf --wide
fi
+ # Omit _DYNAMIC etc. for consistency with extract_symvers.pl, only
+ # present on Solaris.
${readelf} ${lib} |\
sed -e 's/ \[other: [A-Fa-f0-9]*\] //' -e '/\.dynsym/,/^$/p;d' |\
egrep -v ' (LOCAL|UND) ' |\
+ egrep -v
'(_DYNAMIC|_GLOBAL_OFFSET_TABLE_|_PROCEDURE_LINKAGE_TABLE_|_edata|_end|_etext)$'
|\
Shouldn't the regexp also be anchored (with a space) at the beginning?
This works indeed. I was a bit worried if a space was guaranteed at
that position, rather than general whitespace. Consider the patch
amended accordingly.
Any word on this patch? Is has remained unreviewed for a week.
Sorry about the delay. If you can convince me that the change is
guaranteed to affect only Solaris, then you will not need a specific
approval.
Paolo.
Re: [v3] Filter out basever symbols on Solaris
Hi Paolo,
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
diff --git a/libstdc++-v3/scripts/extract_symvers.in
b/libstdc++-v3/scripts/extract_symvers.in
--- a/libstdc++-v3/scripts/extract_symvers.in
+++ b/libstdc++-v3/scripts/extract_symvers.in
@@ -49,9 +49,12 @@ SunOS)
if readelf --help | grep -- --wide /dev/null; then
readelf=$readelf --wide
fi
+ # Omit _DYNAMIC etc. for consistency with extract_symvers.pl, only
+ # present on Solaris.
${readelf} ${lib} |\
sed -e 's/ \[other: [A-Fa-f0-9]*\] //' -e '/\.dynsym/,/^$/p;d' |\
egrep -v ' (LOCAL|UND) ' |\
+ egrep -v
'(_DYNAMIC|_GLOBAL_OFFSET_TABLE_|_PROCEDURE_LINKAGE_TABLE_|_edata|_end|_etext)$'
|\
Shouldn't the regexp also be anchored (with a space) at the beginning?
This works indeed. I was a bit worried if a space was guaranteed at
that position, rather than general whitespace. Consider the patch
amended accordingly.
Any word on this patch? Is has remained unreviewed for a week.
Sorry about the delay. If you can convince me that the change is guaranteed
to affect only Solaris, then you will not need a specific approval.
Unless those symbols were explicitly exported in config/abi/pre/gnu*.ver
(which they are not, otherwise the x86_64-unknown-linux-bootstrap would
have shown a failure), they couldn't make it into libstdc++.so. They
only occur on Solaris because gld explicitly adds them itself.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [v3] Filter out basever symbols on Solaris
On 03/06/2013 02:25 PM, Rainer Orth wrote: Unless those symbols were explicitly exported in config/abi/pre/gnu*.ver (which they are not, otherwise the x86_64-unknown-linux-bootstrap would have shown a failure), they couldn't make it into libstdc++.so. They only occur on Solaris because gld explicitly adds them itself. Ok then. In fact, I noticed only now that you already managed to boot test on x86_64-linux too. Thanks, Paolo.
Re: [boehm-gc] Use thr_stksegment to determine Solaris stack base
On Wed, Mar 6, 2013 at 11:31 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
This patch fixes the failures by backporting the use of thr_stksegment
from gc 7.2c.
Bootstrapped without regressions on i386-pc-solaris2.{9,10,11} and
sparc-sun-solaris2.{9,10,11}, fixes the i386-pc-solaris2.11 failures.
Ok for mainline?
Yes, thanks. Though of course, we really ought to update the entire GC tree!
Bryce
Re: [C++ Patch] PR 56534
It sounds like the underlying problem is that decl isn't a TYPE_DECL. So let's check for that instead. Jason
Re: [PATCH, ARM, RFC] Fix vect.exp failures for NEON in big-endian mode
Julian Brown wrote:
On Tue, 5 Mar 2013 10:42:59 +0100
Richard Biener richard.guent...@gmail.com wrote:
On Tue, Mar 5, 2013 at 12:47 AM, Paul Brook p...@codesourcery.com
wrote:
I somehow missed the Appendix A: Support for Advanced SIMD
Extensions in the AAPCS document (it's not in the TOC!). It looks
like the builtin vector types are indeed defined to be stored in
memory in vldm/vstm order -- I think that means we're back to
square one.
There's still the possibility of making gcc generic vector types
different from the ABI specified types[1], but that feels like it's
probably a really bad idea.
Having a distinct set of types just for the vectorizer may be a
more viable option. IIRC the type selection hooks are more flexible
than when we first looked at this problem.
Paul
[1] e.g. int gcc __attribute__((vector_size(8))); v.s. int32x2_t
eabi;
I think int32x2_t should not be a GCC vector type (thus not have a
vector mode). The ABI specified types should map to an integer mode
of the right size instead. The vectorizer would then still use
internal GCC vector types and modes and the backend needs to provide
instruction patterns that do the right thing with the element
ordering the vectorizer expects.
How are the int32x2_t types used? I suppose they are arguments to
the intrinsics. Which means that for _most_ operations element order
does not matter, thus a plus32x2 (int32x2_t x, int32x2_t y) can simply
use the equivalent of return (int32x2_t)((gcc_int32x2_t)x +
(gcc_int32x2_t)y). In intrinsics where order matters you'd insert
appropriate __builtin_shuffle()s.
Maybe there's no need to interpret the vector layout for any of the
intrinsics -- just treat all inputs outputs as opaque (there are
intrinsics for getting/setting lanes -- IMO these shouldn't attempt to
convert lane numbers at all, though they do at present). Several
intrinsics are currently implemented using __builtin_shuffle, e.g.:
__extension__ static __inline int8x8_t __attribute__ ((__always_inline__))
vrev64_s8 (int8x8_t __a)
{
return (int8x8_t) __builtin_shuffle (__a, (uint8x8_t) { 7, 6, 5, 4, 3, 2, 1,
0 });
}
I'd imagine that if int8x8_t are not actual vector types, we could
invent extra builtins to convert them to and from such types to be able
to still do this kind of thing (in arm_neon.h, not necessarily for
direct use by users), i.e.:
typedef char gcc_int8x8_t __attribute__((vector_size(8)));
int8x8_t
vrev64_s8 (int8x8_t __a)
{
gcc_int8x8_t tmp = __builtin_neon2generic (__a);
tmp = __builtin_shuffle (tmp, (gcc_int8x8_t) { 7, 6, 5, 4, ... });
return __builtin_generic2neon (tmp);
}
(On re-reading, that's basically the same as what you suggested, I
think.)
Oh, of course do the above only for big-endian mode ...
The other way around, mapping intrinsics and ABI vectors to vector
modes will have issues ... you'd have to guard all optab queries in
the middle-end to fail for arm big-endian as they expect instruction
patterns that deal with the GCC vector ordering.
Thus: model the backend after GCCs expectations and fixup the rest
by fixing the ABI types and intrinsics.
I think this plan will work fine -- it has the added advantage (which
looks like a disadvantage, but really isn't) that generic vector
operations like:
void foo (void)
{
int8x8_t x = { 0, 1, 2, 3, 4, 5, 6, 7 };
}
will *not* work -- nor will e.g. subscripting ABI-defined vectors using
[]s. At the moment using these features can lead to surprising results.
Unfortunately NEON's pretty complicated, and the ARM backend currently
uses vector modes quite heavily implementing it, so just using integer
modes for intrinsics is going to be tough. It might work to create a
shadow set of vector modes for use only by the intrinsics (O*mode for
opaque instead of V*mode, say), if the middle end won't barf at that.
I suspect the mid-end may not be too happy with opaque modes for vectors. I've
faced some issues in the past while experimenting with large int modes for
vector register lists while implementing permuted loads in AArch64 particularly
in the area of subreg generation where SUBREG_BYTE is generated based on
BITS_PER_WORD for all INT mode classes not taking into account which registers
the values of the particular mode end up in. This causes subreg_bytes to be
unaligned to vector register boundary. To illustrate this, here is an example
that exposed this issue:
For aarch64, I mirrored the approach that the arm/thumb backend employs and
defined 'large int' opaque modes to represent the register lists i.e. OImode,
CImode and XImode and defined the standard patterns that implement permuted
load/stores - vec_store_lanesINT_MODEVEC_MODE and
vec_load_lanesINT_MODEVEC_MODE.
At the time, I remember this test case
typedef unsigned short V __attribute__((vector_size(32)));
typedef V VI;
V in = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 };
VI mask = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, };
V out = { 1, 2, 3, 4, 5, 6, 7,
Re: [PATCH] Simplify -fwhole-program documentation
This removes all encouragement to use -fwhole-program with -flto from the documentation. As can be seen in PR56533 it can be most confusing ... instead advise to rely on a linker plugin. Ok? Seems resomable thing to do. However I guess a lot of users are still have non-linker-plugin enabled setup. Perhaps we can add a sentence how to figure out if your setup is plugin enabled and thus working well w/o -fwhole-program? Honza
[committed] Fix ICE in strip_typedefs (PR c++/56543)
Hi!
If the second argument to TEMPLATE_ID_EXPR is NULL, there are no
explicit arguments, but we can't call copy_node (NULL).
Fixed thusly, acked by Jason in the PR, bootstrapped/regtested on
x86_64-linux and i686-linux, committed to trunk.
2013-03-06 Jakub Jelinek ja...@redhat.com
PR c++/56543
* tree.c (strip_typedefs): Don't copy args if they are NULL.
* g++.dg/template/typename20.C: New test.
--- gcc/cp/tree.c.jj2013-02-24 19:44:07.0 +0100
+++ gcc/cp/tree.c 2013-03-06 13:49:38.182189955 +0100
@@ -1222,7 +1222,8 @@ strip_typedefs (tree t)
case TYPENAME_TYPE:
{
tree fullname = TYPENAME_TYPE_FULLNAME (t);
- if (TREE_CODE (fullname) == TEMPLATE_ID_EXPR)
+ if (TREE_CODE (fullname) == TEMPLATE_ID_EXPR
+TREE_OPERAND (fullname, 1))
{
tree args = TREE_OPERAND (fullname, 1);
tree new_args = copy_node (args);
--- gcc/testsuite/g++.dg/template/typename20.C.jj 2013-03-06
14:05:42.381512570 +0100
+++ gcc/testsuite/g++.dg/template/typename20.C 2013-03-06 14:05:29.0
+0100
@@ -0,0 +1,11 @@
+// PR c++/56543
+
+template typename
+struct S;
+
+template typename T
+struct U
+{
+ typedef typename S T::template V W;
+ S W x;
+};
Jakub
Re: [PATCH] Fix g++.dg/debug/dwarf2/thunk1.C on darwin
On 03/06/2013 06:33 AM, Rainer Orth wrote:
Why not skip the whole test with dg-skip-if, since the scan is the whole
point of the testcase AFAICT? Also, please add a comment explaining why
the test is skipped, perhaps referencing the PR.
Here's what I'm checking in:
commit cd378936f38da434298b7adb5e03dc53d1a35ab8
Author: Jason Merrill ja...@redhat.com
Date: Wed Mar 6 10:16:34 2013 -0500
PR debug/53363
* g++.dg/debug/dwarf2/thunk1.C: Skip on darwin.
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C b/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C
index 1eb1295..c47ade6 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C
@@ -3,6 +3,9 @@
// { dg-options -g -fpic -fno-dwarf2-cfi-asm }
// { dg-final { scan-assembler-times LFB3 5 } }
+// Darwin doesn't use the thunk for PIC.
+// { dg-skip-if { target *-*-darwin* } }
+
template class T void f(T t) { }
int main()
Re: [PATCH] Fix g++.dg/debug/dwarf2/thunk1.C on darwin
Jason,
The test fails with
ERROR: g++.dg/debug/dwarf2/thunk1.C -std=gnu++98: dg-skip-if 2: need 2, 3, or 4
arguments for dg-skip-if 7 { target *-*-darwin* }
From the test suite the syntax should be of the kind
/* { dg-skip-if no alignment constraints { avr-*-* } { * } { } } */
TIA
Dominique
Re: [PATCH] Fix g++.dg/debug/dwarf2/thunk1.C on darwin
domi...@lps.ens.fr (Dominique Dhumieres) writes:
The test fails with
ERROR: g++.dg/debug/dwarf2/thunk1.C -std=gnu++98: dg-skip-if 2: need 2, 3,
or 4 arguments for dg-skip-if 7 { target *-*-darwin* }
From the test suite the syntax should be of the kind
/* { dg-skip-if no alignment constraints { avr-*-* } { * } { } } */
include-opts and exclude-opts (the last two) are optional and should
only be specified if necessary.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH] Fix expand_cond_expr_using_cmove (PR middle-end/56548)
Hi!
The http://gcc.gnu.org/viewcvs?root=gccview=revrev=193539
change broke the following testcase on i386. The problem is
that it can return the result in wider mode than callers expect,
causing either ICEs or other issues later on.
It is fine to perform the cmove in promoted mode, but we should convert
it to the right mode at the end in order not to confuse callers.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-03-06 Jakub Jelinek ja...@redhat.com
PR middle-end/56548
* expr.c (expand_cond_expr_using_cmove): When expanding cmove in
promoted mode, convert the result back to the original mode.
* gcc.dg/pr56548.c: New test.
--- gcc/expr.c.jj 2013-02-25 20:29:52.0 +0100
+++ gcc/expr.c 2013-03-06 11:13:23.683387708 +0100
@@ -7884,6 +7884,7 @@ expand_cond_expr_using_cmove (tree treeo
tree type = TREE_TYPE (treeop1);
int unsignedp = TYPE_UNSIGNED (type);
enum machine_mode mode = TYPE_MODE (type);
+ enum machine_mode orig_mode = mode;
/* If we cannot do a conditional move on the mode, try doing it
with the promoted mode. */
@@ -7949,7 +7950,7 @@ expand_cond_expr_using_cmove (tree treeo
rtx seq = get_insns ();
end_sequence ();
emit_insn (seq);
- return temp;
+ return convert_modes (orig_mode, mode, temp, 0);
}
/* Otherwise discard the sequence and fall back to code with
--- gcc/testsuite/gcc.dg/pr56548.c.jj 2013-03-06 11:16:39.754325708 +0100
+++ gcc/testsuite/gcc.dg/pr56548.c 2013-03-06 11:16:12.0 +0100
@@ -0,0 +1,16 @@
+/* PR middle-end/56548 */
+/* { dg-do compile } */
+/* { dg-options -O3 } */
+/* { dg-additional-options -march=pentium3 { target { { i?86-*-* x86_64-*-*
} ia32 } } } */
+
+short
+foo (short x)
+{
+ int i;
+
+ for (i = 0; i 3; i++)
+if (x 0)
+ x--;
+
+ return x;
+}
Jakub
Re: [PATCH 1/2] [pr53679] libgo: add a --enable-werror configure flag
On Tue, Mar 5, 2013 at 12:31 AM, Ian Lance Taylor i...@google.com wrote: On Mon, Mar 4, 2013 at 4:11 PM, Mike Frysinger vap...@gentoo.org wrote: On Saturday 26 January 2013 21:40:44 Ian Lance Taylor wrote: On Fri, Jan 25, 2013 at 7:20 PM, Mike Frysinger wrote: On Friday 25 January 2013 19:13:55 Ian Lance Taylor wrote: On Tue, Jan 15, 2013 at 9:45 AM, Mike Frysinger wrote: On Tuesday 15 January 2013 09:56:06 Ian Lance Taylor wrote: On Sun, Dec 23, 2012 at 3:30 PM, Mike Frysinger wrote: diff --git a/libgo/configure.ac b/libgo/configure.ac index 8cde50b..63d8cbc 100644 --- a/libgo/configure.ac +++ b/libgo/configure.ac @@ -50,8 +50,11 @@ AC_PROG_AWK WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual' AC_SUBST(WARN_FLAGS) -dnl FIXME: This should be controlled by --enable-maintainer-mode. -WERROR=-Werror +AC_ARG_ENABLE(werror, [AS_HELP_STRING([--enable-werror], + [turns on -Werror @:@default=yes@:@])]) +if test x$enable_werror != xno; then + WERROR=-Werror +fi AC_SUBST(WERROR) glibgo_toolexecdir=no Can you say something about when you needed this? What errors were you seeing? the referenced PR describes one: /build/src/gcc-4.7.1/libgo/runtime/print.c: In function 'gwrite': /build/src/gcc-4.7.1/libgo/runtime/print.c:20:3: error: ignoring return value of 'write', declared with attribute warn_unused_result [-Werror=unused-result] cc1: all warnings being treated as errors this bites distros that enable security settings by default (such as fortify and ssp). but ignoring even that, i don't believe releases should build all the time with -Werror -- i'm fine with defaulting to on as long as there is a configure flag to turn it off which is what this does like is already handled in much of the sourceware tree. -Werror is great for development, but sucks when deployed on actual systems. the assumptions made at time of checkin rarely stay constant forever (in this case, a changing lib C can easily break it). -mike Thanks for the explanation. Committed to mainline. thanks! mind if i commit it to gcc-4.6 and gcc-4.7 too ? I certainly don't mind. You should probably get agreement from the release managers although this seems safe enough. can you approve merges to the google branches ? that's really where i want this :). No, I don't work on those branches. Sorry. I committed this patch to google/gcc-4_7 rev 196494. Feel free to commit to google/gcc-4_6 if you need to. Diego.
Re: [patch][RFC] bitmaps as lists *or* trees
An interesting question is, how can you identify bitmaps that could benefit from viewing it as a tree (at least for some time). I have no ideas here. Something with detailed memory stats, of course, but then how to derive some measure for a trade-off between list or tree view. Thoughts? Well, I guess we can simply accumulate the counter on linked list walks (when the one element cache is missed) and divide it by number of iterations. Where this number thends to grow and not be counstant bounded, we have nonlinear behaviour, right? Honza
Re: [patch][RFC] bitmaps as lists *or* trees
An interesting question is, how can you identify bitmaps that could benefit from viewing it as a tree (at least for some time). I have no ideas here. Something with detailed memory stats, of course, but then how to derive some measure for a trade-off between list or tree view. Thoughts? Well, I guess we can simply accumulate the counter on linked list walks (when the one element cache is missed) and divide it by number of iterations. Where this number thends to grow and not be counstant bounded, we have nonlinear behaviour, right? And for the RFC, i also find it interesting experiment. I implemented some time ago splay tree based bitmap with API same as bitmap's but never attempted to put it to mainline since Danny introduced his ebitmap and there was a lot of discussion about whether one needs more than one bitmap in the compiler. I never experimented with bitmap.c change itself, just tested that replacing all bitmaps by tree based ones causes quite some memory consumption on RA side (with old RA) because bitmaps are pretty good for regsets they were introduced for. Honza Honza
Re: [PATCH] Fix libcpp memory leak (PR middle-end/56461)
Jakub == Jakub Jelinek ja...@redhat.com writes:
Jakub 2013-02-28 Jakub Jelinek ja...@redhat.com
Jakub PR middle-end/56461
Jakub * internal.h (struct cpp_buffer): Add to_free field.
Jakub (_cpp_pop_file_buffer): Add third argument.
Jakub * files.c (_cpp_stack_file): Set buffer-to_free.
Jakub (_cpp_pop_file_buffer): Add to_free argument. Free to_free
Jakub if non-NULL, and if equal to file-buffer_start, also clear
Jakub file- buffer{,_start,_valid}.
Jakub * directives.c (_cpp_pop_buffer): Pass buffer-to_free
Jakub to _cpp_pop_file_buffer.
This is ok. Thanks, Jakub.
Tom
Re: [PATCH] Fix g++.dg/debug/dwarf2/thunk1.C on darwin
Whoops, I thought I had run that test to make sure the syntax was right, but apparently I ran a different thunk1.C instead. Fixed now. Jason
Re: [C++ Patch] PR 56534
On 03/06/2013 03:34 PM, Jason Merrill wrote:
It sounds like the underlying problem is that decl isn't a
TYPE_DECL. So let's check for that instead.
I see. Thus, also considering that the only other use of
check_elaborated_type_specifier happens when the decl is known to be a
TYPE_DECL, I thought we could change the caller, go back to something
very similar to 4_6-branch + the call when appropriate. Passes testing.
Thanks!
Paolo.
Index: cp/parser.c
===
--- cp/parser.c (revision 196487)
+++ cp/parser.c (working copy)
@@ -14248,12 +14248,15 @@ cp_parser_elaborated_type_specifier (cp_parser* pa
typename_type,
/*complain=*/tf_error);
/* If the `typename' keyword is in effect and DECL is not a type
-decl. Then type is non existant. */
+decl, then type is non existent. */
else if (tag_type == typename_type TREE_CODE (decl) != TYPE_DECL)
type = NULL_TREE;
- else
- type = check_elaborated_type_specifier (tag_type, decl,
+ else if (TREE_CODE (decl) == TYPE_DECL)
+type = check_elaborated_type_specifier (tag_type, decl,
/*allow_template_p=*/true);
+ else
+ /* NULL_TREE or error_mark_node (if decl is error_mark_node). */
+ type = TREE_TYPE (decl);
}
if (!type)
Index: testsuite/g++.dg/template/crash115.C
===
--- testsuite/g++.dg/template/crash115.C(revision 0)
+++ testsuite/g++.dg/template/crash115.C(working copy)
@@ -0,0 +1,3 @@
+// PR c++/56534
+
+template struct template rebind // { dg-error expected }
[wwwdocs, patch, committed] Update link to the 4.8.0 status report
I have committed the link update to the 4.8.0 status report. Tobias Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.871 diff -u -r1.871 index.html --- index.html 17 Feb 2013 12:47:43 - 1.871 +++ index.html 6 Mar 2013 16:35:15 - @@ -152,7 +152,7 @@ /dtdd Status: !--GCC 4.8 status below-- - a href=http://gcc.gnu.org/ml/gcc/2013-02/msg00177.html;2013-02-14/a + a href=http://gcc.gnu.org/ml/gcc/2013-03/msg00036.html;2013-03-06/a !--GCC 4.8 status above-- (regression fixes and docs only). br /
Re: [C++ Patch] PR 56534
... in fact, we could safely add this tiny clean-up too.
Paolo.
///
Index: cp/decl.c
===
--- cp/decl.c (revision 196497)
+++ cp/decl.c (working copy)
@@ -11712,9 +11712,6 @@ check_elaborated_type_specifier (enum tag_types ta
{
tree type;
- if (decl == error_mark_node)
-return error_mark_node;
-
/* In the case of:
struct S { struct S *p; };
Index: cp/parser.c
===
--- cp/parser.c (revision 196497)
+++ cp/parser.c (working copy)
@@ -14248,12 +14248,15 @@ cp_parser_elaborated_type_specifier (cp_parser* pa
typename_type,
/*complain=*/tf_error);
/* If the `typename' keyword is in effect and DECL is not a type
-decl. Then type is non existant. */
+decl, then type is non existent. */
else if (tag_type == typename_type TREE_CODE (decl) != TYPE_DECL)
type = NULL_TREE;
- else
- type = check_elaborated_type_specifier (tag_type, decl,
+ else if (TREE_CODE (decl) == TYPE_DECL)
+type = check_elaborated_type_specifier (tag_type, decl,
/*allow_template_p=*/true);
+ else
+ /* NULL_TREE or error_mark_node (if decl is error_mark_node). */
+ type = TREE_TYPE (decl);
}
if (!type)
Index: testsuite/g++.dg/template/crash115.C
===
--- testsuite/g++.dg/template/crash115.C(revision 0)
+++ testsuite/g++.dg/template/crash115.C(working copy)
@@ -0,0 +1,3 @@
+// PR c++/56534
+
+template struct template rebind // { dg-error expected }
[PATCH] Fix up adjust_return_value_with_ops (PR tree-optimization/56539)
Hi!
This patch fixes a bug where force_gimple_operand_gsi was called with
bogus last argument. The before argument is true, and the stmt that is
added at the end of course should be put in between the (optional) sequence
added by force_gimple_operand_gsi and gsi_stmt (gsi), so it should use
GSI_SAME_STMT, otherwise we end up using SSA_NAME in stmt defined later on
within the same bb.
Bootstrapped on i686-linux, bootstrap on x86_64-linux and both regtests
still pending, ok for trunk if it succeeds?
BTW, I think we still have a latent issue there, because in the testcase
the computations are done in unsigned short type (both multiplications
and additions), so they never cause undefined behavior on overflow, but
in what tail recursion generates, the updates on a_acc and m_acc look fine
(done in unsigned short type), the accumulators themselves are signed short
(in theory fine too), but at the end the additions and multiplications
with a_acc/m_acc are done in signed short type. I guess I should open a PR
for that. E.g. for the simpler:
short foo (const char *x, unsigned y) { return y 1 ? 10 * foo (x, y - 1) :
(*x - '0'); }
there is signed short multiplication at the end rather than unsigned already
in GCC 4.4.
2013-03-06 Jakub Jelinek ja...@redhat.com
PR tree-optimization/56539
* tree-tailcall.c (adjust_return_value_with_ops): Use GSI_SAME_STMT
instead of GSI_CONTINUE_LINKING as last argument to
force_gimple_operand_gsi.
* gcc.c-torture/compile/pr56539.c: New test.
--- gcc/tree-tailcall.c.jj 2013-02-08 13:16:55.0 +0100
+++ gcc/tree-tailcall.c 2013-03-06 15:02:35.836468072 +0100
@@ -622,7 +622,7 @@ adjust_return_value_with_ops (enum tree_
fold_convert (TREE_TYPE (op1), acc),
op1));
rhs = force_gimple_operand_gsi (gsi, rhs,
- false, NULL, true, GSI_CONTINUE_LINKING);
+ false, NULL, true, GSI_SAME_STMT);
stmt = gimple_build_assign (result, rhs);
}
--- gcc/testsuite/gcc.c-torture/compile/pr56539.c.jj2013-03-06
15:05:50.696330194 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr56539.c 2013-03-06
15:05:32.0 +0100
@@ -0,0 +1,7 @@
+/* PR tree-optimization/56539 */
+
+short
+foo (const char *x, unsigned y)
+{
+ return y 1 ? (x[y - 1] - '0') + 10 * foo (x, y - 1) : (*x - '0');
+}
Jakub
Re: [PATCH] Fix expand_cond_expr_using_cmove (PR middle-end/56548)
On 03/06/2013 07:47 AM, Jakub Jelinek wrote: Hi! The http://gcc.gnu.org/viewcvs?root=gccview=revrev=193539 change broke the following testcase on i386. The problem is that it can return the result in wider mode than callers expect, causing either ICEs or other issues later on. It is fine to perform the cmove in promoted mode, but we should convert it to the right mode at the end in order not to confuse callers. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2013-03-06 Jakub Jelinek ja...@redhat.com PR middle-end/56548 * expr.c (expand_cond_expr_using_cmove): When expanding cmove in promoted mode, convert the result back to the original mode. * gcc.dg/pr56548.c: New test. Ok. r~
Re: [C++ Patch] PR 56534
On 03/06/2013 11:42 AM, Paolo Carlini wrote: + /* NULL_TREE or error_mark_node (if decl is error_mark_node). */ + type = TREE_TYPE (decl); I'd prefer to avoid taking the TREE_TYPE of some random thing. If what we want is NULL_TREE or error_mark_node, let's write that rather than expect to get it from TREE_TYPE. Jason
[Ada] Minor tweak to emit_range_check
Just to stop the compiler properly instead of segfaulting on some ill-formed
inputs going through the FE down to here. No functional changes.
2013-03-06 Eric Botcazou ebotca...@adacore.com
* gcc-interface/trans.c (emit_range_check): Assert that the range type
is a numerical type and remove useless local variables.
--
Eric BotcazouIndex: gcc-interface/trans.c
===
--- gcc-interface/trans.c (revision 196487)
+++ gcc-interface/trans.c (working copy)
@@ -8119,8 +8119,6 @@ static tree
emit_range_check (tree gnu_expr, Entity_Id gnat_range_type, Node_Id gnat_node)
{
tree gnu_range_type = get_unpadded_type (gnat_range_type);
- tree gnu_low = TYPE_MIN_VALUE (gnu_range_type);
- tree gnu_high = TYPE_MAX_VALUE (gnu_range_type);
tree gnu_compare_type = get_base_type (TREE_TYPE (gnu_expr));
/* If GNU_EXPR has GNAT_RANGE_TYPE as its base type, no check is needed.
@@ -8128,6 +8126,10 @@ emit_range_check (tree gnu_expr, Entity_
if (gnu_compare_type == gnu_range_type)
return gnu_expr;
+ /* Range checks can only be applied to types with ranges. */
+ gcc_assert (INTEGRAL_TYPE_P (gnu_range_type)
+ || SCALAR_FLOAT_TYPE_P (gnu_range_type));
+
/* If GNU_EXPR has an integral type that is narrower than GNU_RANGE_TYPE,
we can't do anything since we might be truncating the bounds. No
check is needed in this case. */
@@ -8147,13 +8149,16 @@ emit_range_check (tree gnu_expr, Entity_
(build_binary_op (TRUTH_ORIF_EXPR, boolean_type_node,
invert_truthvalue
(build_binary_op (GE_EXPR, boolean_type_node,
- convert (gnu_compare_type, gnu_expr),
- convert (gnu_compare_type, gnu_low))),
+convert (gnu_compare_type, gnu_expr),
+convert (gnu_compare_type,
+ TYPE_MIN_VALUE
+ (gnu_range_type,
invert_truthvalue
(build_binary_op (LE_EXPR, boolean_type_node,
convert (gnu_compare_type, gnu_expr),
convert (gnu_compare_type,
- gnu_high,
+ TYPE_MAX_VALUE
+ (gnu_range_type),
gnu_expr, CE_Range_Check_Failed, gnat_node);
}
[Ada] Fix internal error on loop over array with misaligned index
This is a regression present on the mainline. The compiler aborts on a loop
running over an array whose index type is a misaligned scalar type at -O3.
We're just forgetting to lift the padding type around the scalar type.
Tested on x86_64-suse-linux, applied on the mainline.
2013-06-03 Eric Botcazou ebotca...@adacore.com
* gcc-interface/trans.c (Raise_Error_to_gnu) CE_Index_Check_Failed:
Record the unpadded type of the index type on the RCI stack.
2013-06-03 Eric Botcazou ebotca...@adacore.com
* gnat.dg/loop_optimization15.ad[sb]: New test.
--
Eric BotcazouIndex: gcc-interface/trans.c
===
--- gcc-interface/trans.c (revision 196500)
+++ gcc-interface/trans.c (working copy)
@@ -4944,7 +4944,7 @@ Raise_Error_to_gnu (Node_Id gnat_node, t
{
rci-low_bound = gnu_low_bound;
rci-high_bound = gnu_high_bound;
- rci-type = gnat_to_gnu_type (gnat_type);
+ rci-type = get_unpadded_type (gnat_type);
rci-invariant_cond = build1 (SAVE_EXPR, boolean_type_node,
boolean_true_node);
gnu_cond = build_binary_op (TRUTH_ANDIF_EXPR,
-- { dg-do compile }
-- { dg-options -O3 }
package body Loop_Optimization15 is
type Integer_Array_T is array (B16_T range ) of Integer;
Len : constant B16_T := 10;
Src : constant Integer_Array_T (1 .. Len) := (others = 0);
Dst : Integer_Array_T (1 .. Len);
procedure Proc (L : B16_T) is
begin
for I in 1 .. B16_T'Min (L, Len) loop
Dst (I) := Src (I);
end loop;
end;
end Loop_Optimization15;
package Loop_Optimization15 is
type B16_T is mod 2 ** 16;
for B16_T'Size use 16;
for B16_T'Alignment use 1;
procedure Proc (L : B16_T);
end Loop_Optimization15;
Re: [C++ Patch] PR 56534
Hi,
On 03/06/2013 06:32 PM, Jason Merrill wrote:
On 03/06/2013 11:42 AM, Paolo Carlini wrote:
+/* NULL_TREE or error_mark_node (if decl is error_mark_node). */
+type = TREE_TYPE (decl);
I'd prefer to avoid taking the TREE_TYPE of some random thing. If
what we want is NULL_TREE or error_mark_node, let's write that rather
than expect to get it from TREE_TYPE.
I hear you. Then since type is already initialized to NULL_TREE anyway,
we can do the below. I'm finishing testing it.
Paolo.
Index: cp/decl.c
===
--- cp/decl.c (revision 196497)
+++ cp/decl.c (working copy)
@@ -11712,9 +11712,6 @@ check_elaborated_type_specifier (enum tag_types ta
{
tree type;
- if (decl == error_mark_node)
-return error_mark_node;
-
/* In the case of:
struct S { struct S *p; };
Index: cp/parser.c
===
--- cp/parser.c (revision 196497)
+++ cp/parser.c (working copy)
@@ -14248,12 +14248,14 @@ cp_parser_elaborated_type_specifier (cp_parser* pa
typename_type,
/*complain=*/tf_error);
/* If the `typename' keyword is in effect and DECL is not a type
-decl. Then type is non existant. */
+decl, then type is non existent. */
else if (tag_type == typename_type TREE_CODE (decl) != TYPE_DECL)
-type = NULL_TREE;
- else
- type = check_elaborated_type_specifier (tag_type, decl,
+;
+ else if (TREE_CODE (decl) == TYPE_DECL)
+type = check_elaborated_type_specifier (tag_type, decl,
/*allow_template_p=*/true);
+ else if (decl == error_mark_node)
+ type = error_mark_node;
}
if (!type)
Index: testsuite/g++.dg/template/crash115.C
===
--- testsuite/g++.dg/template/crash115.C(revision 0)
+++ testsuite/g++.dg/template/crash115.C(working copy)
@@ -0,0 +1,3 @@
+// PR c++/56534
+
+template struct template rebind // { dg-error expected }
Re: [patch testsuite]: Fix some tests for LLP64 targets
On 03/06/2013 10:00 AM, Kai Tietz wrote: Hello, this patch fixes some regressions in testsuite for x64-targets. ChangeLog 2013-03-06 Kai Tietz kti...@redhat.com * gcc.dg/lto/20090914-2_0.c: Skip for mingw and cygwin targets. * gcc.dg/lto/20091013-1_1.c: Set x64-mingw as xfail. * gcc.dg/lto/20091013-1_2.c: Likewise. * gcc.dg/pr31490.c: Adjust for LLP64 targets. Ok for apply? Regards, Kai OK. Janis
Re: [patch][RFC] bitmaps as lists *or* trees
On Wed, Mar 6, 2013 at 5:06 PM, Jan Hubicka wrote: And for the RFC, i also find it interesting experiment. I implemented some time ago splay tree based bitmap with API same as bitmap's but never attempted to put it to mainline since Danny introduced his ebitmap and there was a lot of discussion about whether one needs more than one bitmap in the compiler. I Right, I think the ebitmap.c experiment shows that there is *not* room for another bitmap implementation. This is why I developed these splay-tree bitmaps using the same data structures as the existing linked-list sparse bitmaps: Not another bitmap, just another way of looking at the existing bitmap. I required that changing the view of the bitmap from linked-list to splay tree and vv. to be almost free. never experimented with bitmap.c change itself, just tested that replacing all bitmaps by tree based ones causes quite some memory consumption on RA side (with old RA) because bitmaps are pretty good for regsets they were introduced for. Memory consumption as in higher peak memory? That cannot happen with my splay-tree bitmaps. They take exactly the same amount of memory, independent of whether the current view on the bitmap is linked-list or splay tree. As for cache behavior or number of memory operations (loads, stores) I think this is directly correlated to the lookup success ratio, hence the access pattern, and so if the right view on the bitmap is selected for the right circumstances then the number of memory ops should also be no worse in splay tree view than in linked-list view. Another idea I'm currently (right now on gcc17 ;-) working on, is a trivial speed-up for bitmaps used as regsets. The idea is that bitmap_find_bit should look at head-first if head-current is not the element containing the sought bit, and *not* update head-current if head-first is the right element. This speeds up regsets because a common access pattern is to look at sets containing both pseudos and hardregs, and on most targets all hardregs are in head-first. Not updating head-current preserves a pointer to the latest accessed pseudos. I'll implement this idea and come back with some timings. Ciao! Steven
[Ada] Fix internal error on aggregate with small misaligned field
This is another regression present on the mainline. The compiler aborts on an
aggregate whose type is a record type with a misaligned scalar component and
with a representation clause for this component that gives it a size smaller
than the default. We're incorrectly laying out the type.
Tested on x86_64-suse-linux, applied on the mainline.
2013-03-06 Eric Botcazou ebotca...@adacore.com
* gcc-interface/decl.c (gnat_to_gnu_field): Remove the wrapper around
a misaligned integral type if a size is specified for the field.
2013-03-06 Eric Botcazou ebotca...@adacore.com
* gnat.dg/specs/aggr6.ads: New test.
--
Eric Botcazou-- { dg-do compile }
package Aggr6 is
type B15_T is mod 2 ** 15;
for B15_T'Size use 15;
for B15_T'Alignment use 1;
type B17_T is mod 2 ** 17;
for B17_T'Size use 17;
for B17_T'Alignment use 1;
type Rec_T is record
A : B17_T;
B : B15_T;
end record;
for Rec_T use record
A at 0 range 0 .. 16;
B at 0 range 17 .. 31;
end record;
for Rec_T'Size use 32;
C : constant Rec_T := (A = 1, B = 0);
end Aggr6;
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 196487)
+++ gcc-interface/decl.c (working copy)
@@ -6619,6 +6619,13 @@ gnat_to_gnu_field (Entity_Id gnat_field,
= 0)
gnu_field_type = TREE_TYPE (TYPE_FIELDS (gnu_field_type));
+ /* Similarly if the field's type is a misaligned integral type, but
+ there is no restriction on the size as there is no justification. */
+ if (!needs_strict_alignment
+ TYPE_IS_PADDING_P (gnu_field_type)
+ INTEGRAL_TYPE_P (TREE_TYPE (TYPE_FIELDS (gnu_field_type
+ gnu_field_type = TREE_TYPE (TYPE_FIELDS (gnu_field_type));
+
gnu_field_type
= make_type_from_size (gnu_field_type, gnu_size,
Has_Biased_Representation (gnat_field));
Re: [PATCH] Skip some vect tests on AIX.
David, 'dg-do run' and 'dg-do compile' cannot be mixed in the same test (if needed I can look for the thread) so the tests vect-82_64.c and vect-83_64.c are not doing what was expected. Dominique
[google/gcc-4_7-mobile] Merged with google/gcc-4_7
The merge includes the following 108 CLs from 190426 (excluded) up to 195968 (included) - 195968 195906 195905 195810 195782 195740 195672 195468 195460 195435 195427 195373 195356 195306 195282 195246 195214 195030 194932 194931 194926 194925 194921 194874 194831 194739 194737 194735 194725 194713 194678 194677 194664 194562 194483 194426 194422 194420 194400 194371 194264 194163 194047 194022 193870 193865 193861 193860 193854 193837 193828 193825 193387 193177 193176 193133 193085 192818 192639 192631 192630 192625 192602 192511 192383 192333 192321 192284 192278 192277 19 192217 191940 191834 191813 191763 191689 191682 191681 191495 191340 191312 191268 191234 191207 191163 191156 191084 191006 191005 190940 190798 190790 190640 190639 190637 190632 190610 190601 190600 190597 190553 190549 190539 190494 190491 190489 190450 Submitted as r196505. -- Han Shen
[patch testsuite]: Fix some tests for LLP64 targets
Hello,
this patch fixes some regressions in testsuite for x64-targets.
ChangeLog
2013-03-06 Kai Tietz kti...@redhat.com
* gcc.dg/lto/20090914-2_0.c: Skip for mingw and cygwin
targets.
* gcc.dg/lto/20091013-1_1.c: Set x64-mingw as xfail.
* gcc.dg/lto/20091013-1_2.c: Likewise.
* gcc.dg/pr31490.c: Adjust for LLP64 targets.
Ok for apply?
Regards,
Kai
Index: gcc.dg/lto/20090914-2_0.c
===
--- gcc.dg/lto/20090914-2_0.c (Revision 196485)
+++ gcc.dg/lto/20090914-2_0.c (Arbeitskopie)
@@ -1,6 +1,7 @@
/* { dg-lto-do run } */
/* { dg-skip-if x86 only { ! { x86_64-*-* i?86-*-* } } { * } { } } */
/* { dg-skip-if no .type { *-*-darwin* } { * } { } } */
+/* { dg-skip-if no @function { *-*-mingw* *-*-cygwin* } { * } { } } */
/* Doesn't work without this dummy function with -fwhopr. */
int foo(void) { }
Index: gcc.dg/lto/20091013-1_1.c
===
--- gcc.dg/lto/20091013-1_1.c (Revision 196485)
+++ gcc.dg/lto/20091013-1_1.c (Arbeitskopie)
@@ -1,4 +1,4 @@
-/* { dg-xfail-if cast to pointer of different size { avr-*-* } {
* } { } } */
+/* { dg-xfail-if cast to pointer of different size { avr-*-*
x86_64-*-mingw* } { * } { } } */
typedef struct HDC__ { int unused; } *HDC;
typedef struct HFONT__ { int unused; } *HFONT;
Index: gcc.dg/lto/20091013-1_2.c
===
--- gcc.dg/lto/20091013-1_2.c (Revision 196485)
+++ gcc.dg/lto/20091013-1_2.c (Arbeitskopie)
@@ -1,4 +1,4 @@
-/* { dg-xfail-if cast to pointer of different size { avr-*-* } {
* } { } } */
+/* { dg-xfail-if cast to pointer of different size { avr-*-*
x86_64-*-mingw* } { * } { } } */
typedef struct HDC__ { int unused; } *HDC;
typedef struct HFONT__ { int unused; } *HFONT;
Index: gcc.dg/pr31490.c
===
--- gcc.dg/pr31490.c(Revision 196485)
+++ gcc.dg/pr31490.c(Arbeitskopie)
@@ -3,6 +3,8 @@
/* { dg-require-named-sections } */
/* { dg-require-effective-target ptr32plus } */
+__extension__ typedef __UINTPTR_TYPE__ uintptr_t;
+
int cpu (void *attr) {}
-const unsigned long x __attribute__((section(foo))) = (unsigned long)cpu;
-const unsigned long g __attribute__((section(foo))) = 0;
+const uintptr_t x __attribute__((section(foo))) = (uintptr_t)cpu;
+const uintptr g __attribute__((section(foo))) = 0;
Re: [patch][RFC] bitmaps as lists *or* trees
On Wed, Mar 6, 2013 at 5:02 PM, Jan Hubicka wrote: An interesting question is, how can you identify bitmaps that could benefit from viewing it as a tree (at least for some time). I have no ideas here. Something with detailed memory stats, of course, but then how to derive some measure for a trade-off between list or tree view. Thoughts? Well, I guess we can simply accumulate the counter on linked list walks (when the one element cache is missed) and divide it by number of iterations. Where this number thends to grow and not be counstant bounded, we have nonlinear behaviour, right? Well, yes and no. This is not fine-grained enough to see if there are specific usages of bitmaps that can be better represented as a linked-list or as a tree. But yes, it's a place to start, and it's what I've started doing last night for a set of files (large PR test cases, cc1-i files, etc.). Ciao! Steven
Re: [patch][RFC] bitmaps as lists *or* trees
On Wed, Mar 6, 2013 at 5:02 PM, Jan Hubicka wrote: An interesting question is, how can you identify bitmaps that could benefit from viewing it as a tree (at least for some time). I have no ideas here. Something with detailed memory stats, of course, but then how to derive some measure for a trade-off between list or tree view. Thoughts? Well, I guess we can simply accumulate the counter on linked list walks (when the one element cache is missed) and divide it by number of iterations. Where this number thends to grow and not be counstant bounded, we have nonlinear behaviour, right? Well, yes and no. This is not fine-grained enough to see if there are specific usages of bitmaps that can be better represented as a linked-list or as a tree. But yes, it's a place to start, and it's what I've started doing last night for a set of files (large PR test cases, cc1-i files, etc.). Well, I meant with the --enable-gather-detailed-stats code. it should give you data about individual bitmaps used thorough the compiler. Honza Ciao! Steven
[Ada] Minor tweak to Attribute_to_gnu
Just to stop the compiler properly instead of erroring out on some ill-formed inputs going through the FE down to here. No functional changes. Tested on x86_64-suse-linux, applied on the mainline. 2013-03-06 Eric Botcazou ebotca...@adacore.com * gcc-interface/trans.c (Attribute_to_gnu): Abort instead of erroring out for an unimplemented attribute. -- Eric BotcazouIndex: gcc-interface/trans.c === --- gcc-interface/trans.c (revision 196504) +++ gcc-interface/trans.c (working copy) @@ -2066,13 +2066,8 @@ Attribute_to_gnu (Node_Id gnat_node, tre break; default: - /* Say we have an unimplemented attribute. Then set the value to be - returned to be a zero and hope that's something we can convert to - the type of this attribute. */ - post_error (unimplemented attribute, gnat_node); - gnu_result_type = get_unpadded_type (Etype (gnat_node)); - gnu_result = integer_zero_node; - break; + /* This abort means that we have an unimplemented attribute. */ + gcc_unreachable (); } /* If this is an attribute where the prefix was unused, force a use of it if
[Fortran, Patch] Improve documentation of the non-implemented RECORD STRUCTURE extension
During the discussion of UNION, I decided to have a look at the current
documentation. UNION is not mentioned (except for some commented lines),
but record structures are. Attached is an attempted to improve the
documentation.
The current version is at
http://gcc.gnu.org/onlinedocs/gfortran/STRUCTURE-and-RECORD.html
I tested it with make pdf and make info and looked at the output.
OK for the trunk?
Tobias
2013-03-06 Tobias Burnus bur...@net-b.de
* gfortran.texi (STRUCTURE and RECORD): State more clearly how
to convert them into derived types.
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 462b443..4f9008d 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -2004,10 +2004,19 @@ code that uses them running with the GNU Fortran compiler.
@cindex @code{STRUCTURE}
@cindex @code{RECORD}
-Structures are user-defined aggregate data types; this functionality was
-standardized in Fortran 90 with an different syntax, under the name of
-``derived types''. Here is an example of code using the non portable
-structure syntax:
+Record structures are a pre-Fortran-90 vendor extension to create
+user-defined aggregate data types. GNU Fortran does not support
+record structures, only Fortran 90's ``derived types'', which have
+a different syntax.
+
+In many cases, record structures can easily be converted to derived types.
+To convert, replace @code{STRUCTURE /}@var{structure-name}@code{/}
+by @code{TYPE} @var{type-name}. Additionally, replace
+@code{RECORD /}@var{structure-name}@code{/} by
+@code{TYPE(}@var{type-name}@code{)}. Finally, in the component access,
+replace the period (@code{.}) by the percent sign (@code{%}).
+
+Here is an example of code using the non portable record structure syntax:
@example
! Declaring a structure named ``item'' and containing three fields:
Re: [C++ Patch] PR 56534
OK, thanks.
Re: [PATCH] Skip some vect tests on AIX.
On Wed, Mar 6, 2013 at 1:54 PM, Dominique Dhumieres domi...@lps.ens.fr wrote: David, 'dg-do run' and 'dg-do compile' cannot be mixed in the same test (if needed I can look for the thread) so the tests vect-82_64.c and vect-83_64.c are not doing what was expected. I did not write the original dg-do and dg-run lines. I only disabled the tests on AIX. Thanks, David
Re: [PATCH] Fix up adjust_return_value_with_ops (PR tree-optimization/56539)
On 03/06/2013 09:43 AM, Jakub Jelinek wrote:
Hi!
This patch fixes a bug where force_gimple_operand_gsi was called with
bogus last argument. The before argument is true, and the stmt that is
added at the end of course should be put in between the (optional) sequence
added by force_gimple_operand_gsi and gsi_stmt (gsi), so it should use
GSI_SAME_STMT, otherwise we end up using SSA_NAME in stmt defined later on
within the same bb.
Bootstrapped on i686-linux, bootstrap on x86_64-linux and both regtests
still pending, ok for trunk if it succeeds?
BTW, I think we still have a latent issue there, because in the testcase
the computations are done in unsigned short type (both multiplications
and additions), so they never cause undefined behavior on overflow, but
in what tail recursion generates, the updates on a_acc and m_acc look fine
(done in unsigned short type), the accumulators themselves are signed short
(in theory fine too), but at the end the additions and multiplications
with a_acc/m_acc are done in signed short type. I guess I should open a PR
for that. E.g. for the simpler:
short foo (const char *x, unsigned y) { return y 1 ? 10 * foo (x, y - 1) :
(*x - '0'); }
there is signed short multiplication at the end rather than unsigned already
in GCC 4.4.
2013-03-06 Jakub Jelinek ja...@redhat.com
PR tree-optimization/56539
* tree-tailcall.c (adjust_return_value_with_ops): Use GSI_SAME_STMT
instead of GSI_CONTINUE_LINKING as last argument to
force_gimple_operand_gsi.
* gcc.c-torture/compile/pr56539.c: New test.
Doesn't the code in update_accumulator_with_ops need the same change?
Unrelated, but the block comment still refers to UPDATE, which is no
longer a parameter.
I see similar looking code in tree-inline.c::copy_bb... Does it need
updating as well?
Change looks OK to me, but please check those other two instances and
take appropriate action. If you could update the block comment before
adjust_return_value_with_ops it'd be appreciated as well.
jeff
Re: [SH, committed] PR 56529 - Calls to __sdivsi3_i4i and __udivsi3_i4i are generated on SH2
On Wed, 2013-03-06 at 01:43 +0100, Oleg Endo wrote:
Hi,
This is the patch that I posted in the PR and that was pre-approved by
Kaz, with some documentation bits added.
Tested with 'make info dvi pdf' and 'make all'.
Applied as revision 196484.
Will backport it to 4.7 branch.
I've backported the patch to the 4.7 branch.
Tested with 'make all' and 'make info dvi pdf'.
Committed as revision 196510.
Cheers,
Oleg
Index: libgcc/config/sh/lib1funcs.S
===
--- libgcc/config/sh/lib1funcs.S (revision 196509)
+++ libgcc/config/sh/lib1funcs.S (working copy)
@@ -3255,8 +3255,8 @@
.word 17136
.word 16639
-#elif defined (__SH3__) || defined (__SH3E__) || defined (__SH4__) || defined (__SH4_SINGLE__) || defined (__SH4_SINGLE_ONLY__) || defined (__SH4_NOFPU__)
-/* This code used shld, thus is not suitable for SH1 / SH2. */
+#elif defined (__SH2A__) || defined (__SH3__) || defined (__SH3E__) || defined (__SH4__) || defined (__SH4_SINGLE__) || defined (__SH4_SINGLE_ONLY__) || defined (__SH4_NOFPU__)
+/* This code uses shld, thus is not suitable for SH1 / SH2. */
/* Signed / unsigned division without use of FPU, optimized for SH4.
Uses a lookup table for divisors in the range -128 .. +128, and
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c (revision 196509)
+++ gcc/config/sh/sh.c (working copy)
@@ -686,7 +686,8 @@
|| (TARGET_HARD_SH4 TARGET_SH2E)
|| (TARGET_SHCOMPACT TARGET_FPU_ANY)))
sh_div_strategy = SH_DIV_CALL_FP;
- else if (! strcmp (sh_div_str, call-table) TARGET_SH2)
+ else if (! strcmp (sh_div_str, call-table)
+ (TARGET_SH3 || TARGET_SH2A))
sh_div_strategy = SH_DIV_CALL_TABLE;
else
/* Pick one that makes most sense for the target in general.
@@ -706,8 +707,6 @@
sh_div_strategy = SH_DIV_CALL_FP;
/* SH1 .. SH3 cores often go into small-footprint systems, so
default to the smallest implementation available. */
- else if (TARGET_SH2) /* ??? EXPERIMENTAL */
- sh_div_strategy = SH_DIV_CALL_TABLE;
else
sh_div_strategy = SH_DIV_CALL_DIV1;
}
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 196509)
+++ gcc/config.gcc (working copy)
@@ -2355,7 +2355,7 @@
sh[1234]*) sh_multilibs=${sh_cpu_target} ;;
sh64* | sh5*) sh_multilibs=m5-32media,m5-32media-nofpu,m5-compact,m5-compact-nofpu,m5-64media,m5-64media-nofpu ;;
sh-superh-*) sh_multilibs=m4,m4-single,m4-single-only,m4-nofpu ;;
- sh*-*-linux*) sh_multilibs=m1,m3e,m4 ;;
+ sh*-*-linux*) sh_multilibs=m1,m2,m2a,m3e,m4 ;;
sh*-*-netbsd*) sh_multilibs=m3,m3e,m4 ;;
*) sh_multilibs=m1,m2,m2e,m4,m4-single,m4-single-only,m2a,m2a-single ;;
esac
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 196509)
+++ gcc/doc/invoke.texi (working copy)
@@ -18066,44 +18066,95 @@
@item -mdiv=@var{strategy}
@opindex mdiv=@var{strategy}
-Set the division strategy to use for SHmedia code. @var{strategy} must be
-one of: call, call2, fp, inv, inv:minlat, inv20u, inv20l, inv:call,
-inv:call2, inv:fp .
-fp performs the operation in floating point. This has a very high latency,
+Set the division strategy to be used for integer division operations.
+For SHmedia @var{strategy} can be one of:
+
+@table @samp
+
+@item fp
+Performs the operation in floating point. This has a very high latency,
but needs only a few instructions, so it might be a good choice if
your code has enough easily-exploitable ILP to allow the compiler to
schedule the floating-point instructions together with other instructions.
Division by zero causes a floating-point exception.
-inv uses integer operations to calculate the inverse of the divisor,
+
+@item inv
+Uses integer operations to calculate the inverse of the divisor,
and then multiplies the dividend with the inverse. This strategy allows
-cse and hoisting of the inverse calculation. Division by zero calculates
+CSE and hoisting of the inverse calculation. Division by zero calculates
an unspecified result, but does not trap.
-inv:minlat is a variant of inv where if no cse / hoisting opportunities
+
+@item inv:minlat
+A variant of @samp{inv} where, if no CSE or hoisting opportunities
have been found, or if the entire operation has been hoisted to the same
place, the last stages of the inverse calculation are intertwined with the
final multiply to reduce the overall latency, at the expense of using a few
more instructions, and thus offering fewer scheduling opportunities with
other code.
-call calls a library function that usually implements the inv:minlat
+
+@item call
+Calls a library function that usually implements the @samp{inv:minlat}
strategy.
-This gives high code density for m5-*media-nofpu compilations.
-call2 uses a different entry point of the same library
Re: [PATCH] Fix install-plugin on arm and aarch64
On Wed, Mar 6, 2013 at 9:07 AM, Jakub Jelinek ja...@redhat.com wrote: Hi! https://bugzilla.redhat.com/show_bug.cgi?id=910926 reports that plugins aren't usable on arm, because arm-cores.def isn't installed into the plugins directory. arm-cores.def can't be included in tm_file list, because we don't want to include it directly, nor in HeaderInclude in arm.opt (that breaks the build). rs6000 has similar issue with its rs6000-builtin.def, and solves this by adding content to TM_H in Makefile fragment. Thus, the following patch does the same for arm (and apparently aarch64 has the same issue). Ok for trunk? 2013-03-06 Jakub Jelinek ja...@redhat.com * config/aarch64/t-aarch64 (TM_H, OPTIONS_H_EXTRA): Add aarch64-cores.def. * config/arm/t-arm (TM_H, OPTIONS_H_EXTRA): Add arm-cores.def. Ok. Thanks, Ramana --- gcc/config/aarch64/t-aarch64.jj 2013-02-24 19:44:07.0 +0100 +++ gcc/config/aarch64/t-aarch642013-03-06 09:42:31.568042231 +0100 @@ -18,6 +18,9 @@ # along with GCC; see the file COPYING3. If not see # http://www.gnu.org/licenses/. +TM_H += $(srcdir)/config/aarch64/aarch64-cores.def +OPTIONS_H_EXTRA += $(srcdir)/config/aarch64/aarch64-cores.def + $(srcdir)/config/aarch64/aarch64-tune.md: $(srcdir)/config/aarch64/gentune.sh \ $(srcdir)/config/aarch64/aarch64-cores.def $(SHELL) $(srcdir)/config/aarch64/gentune.sh \ --- gcc/config/arm/t-arm.jj 2013-01-11 09:03:13.0 +0100 +++ gcc/config/arm/t-arm2013-03-06 09:41:09.607528642 +0100 @@ -18,6 +18,9 @@ # along with GCC; see the file COPYING3. If not see # http://www.gnu.org/licenses/. +TM_H += $(srcdir)/config/arm/arm-cores.def +OPTIONS_H_EXTRA += $(srcdir)/config/arm/arm-cores.def + # All md files - except for arm.md. # This list should be kept in alphabetical order and updated whenever an md # file is added or removed. Jakub [A
[patch] minor bitmap.c GATHER_STATISTICS fix-ups
Hello,
This patch fixes a bunch of smaller issues with GATHER_STATISTICS for
bitmaps: overflows in counters and ugly output format.
Bootstrapped (with and without GATHER_STATISTICS) and regtested on
powerpc64-unknown-linux-gnu and on x86_64-unknown-linux-gnu. OK for
trunk?
Ciao!
Steven
* bitmap.c (struct bitmap_descriptor_d): Use unsigned HOST_WIDEST_INT
for all counters.
(struct output_info): Likewise.
(register_overhead): Remove bad gcc_assert.
(bitmap_find_bit): If there is only a single bitmap element, do not
count a miss as a search.
(print_statistics): Update for counter type changes.
(dump_bitmap_statistics): Likewise. Print headers such that they
are properly lined up with the printed counters.
* bitmap.c (struct bitmap_descriptor_d): Use unsigned HOST_WIDEST_INT
for all counters.
(struct output_info): Likewise.
(register_overhead): Remove bad gcc_assert.
(bitmap_find_bit): If there is only a single bitmap element, do not
count a miss as a search.
(print_statistics): Update for counter type changes.
(dump_bitmap_statistics): Likewise. Print headers such that they
are properly lined up with the printed counters.
Index: bitmap.c
===
--- bitmap.c(revision 196508)
+++ bitmap.c(working copy)
@@ -34,11 +34,11 @@ struct bitmap_descriptor_d
const char *file;
int line;
int created;
- HOST_WIDEST_INT allocated;
- HOST_WIDEST_INT peak;
- HOST_WIDEST_INT current;
- int nsearches;
- int search_iter;
+ unsigned HOST_WIDEST_INT allocated;
+ unsigned HOST_WIDEST_INT peak;
+ unsigned HOST_WIDEST_INT current;
+ unsigned HOST_WIDEST_INT nsearches;
+ unsigned HOST_WIDEST_INT search_iter;
};
typedef struct bitmap_descriptor_d *bitmap_descriptor;
@@ -121,7 +121,6 @@ register_overhead (bitmap b, int amount)
desc-current += amount;
if (amount 0)
desc-allocated += amount;
- gcc_assert (desc-current = 0);
if (desc-peak desc-current)
desc-peak = desc-current;
}
@@ -565,10 +564,15 @@ bitmap_find_bit (bitmap head, unsigned int bit)
bitmap_element *element;
unsigned int indx = bit / BITMAP_ELEMENT_ALL_BITS;
- if (head-current == 0
+ if (head-current == NULL
|| head-indx == indx)
return head-current;
+ if (head-current == head-first
+ head-first-next == NULL)
+return NULL;
+ /* This bitmap has more than one element, and we're going to look
+ through the elements list. Count that as a search. */
if (GATHER_STATISTICS)
bitmap_descriptors[head-descriptor_id]-nsearches++;
@@ -2132,8 +2136,8 @@ bitmap_print (FILE *file, const_bitmap head, const
/* Used to accumulate statistics about bitmap sizes. */
struct output_info
{
- HOST_WIDEST_INT size;
- int count;
+ unsigned HOST_WIDEST_INT size;
+ unsigned HOST_WIDEST_INT count;
};
/* Called via htab_traverse. Output bitmap descriptor pointed out by SLOT
@@ -2153,10 +2157,14 @@ print_statistics (void **slot, void *b)
s1 = s2 + 4;
sprintf (s, %s:%i (%s), s1, d-line, d-function);
s[41] = 0;
- fprintf (stderr, %-41s %8d %15HOST_WIDEST_INT_PRINTd %15
- HOST_WIDEST_INT_PRINTd %15HOST_WIDEST_INT_PRINTd %10d %10d\n,
- s, d-created, d-allocated, d-peak, d-current, d-nsearches,
- d-search_iter);
+ fprintf (stderr,
+ %-41s %9u
+ %15HOST_WIDEST_INT_PRINTd %15HOST_WIDEST_INT_PRINTd
+ %15HOST_WIDEST_INT_PRINTd
+ %10HOST_WIDEST_INT_PRINTd %10HOST_WIDEST_INT_PRINTd\n,
+ s, d-created,
+ d-allocated, d-peak, d-current,
+ d-nsearches, d-search_iter);
i-size += d-allocated;
i-count += d-created;
}
@@ -2175,15 +2183,18 @@ dump_bitmap_statistics (void)
if (!bitmap_desc_hash)
return;
- fprintf (stderr, \nBitmap Overall
-AllocatedPeakLeak searched
-search itr\n);
+ fprintf (stderr,
+ \n%-41s %9s %15s %15s %15s %10s %10s\n,
+ Bitmap, Overall,
+ Allocated, Peak, Leak,
+ searched, search_itr);
fprintf (stderr,
-\n);
info.count = 0;
info.size = 0;
htab_traverse (bitmap_desc_hash, print_statistics, info);
fprintf (stderr,
-\n);
- fprintf (stderr, %-40s %9d %15HOST_WIDEST_INT_PRINTd\n,
+ fprintf (stderr,
+ %-41s %9HOST_WIDEST_INT_PRINTd %15HOST_WIDEST_INT_PRINTd\n,
Total, info.count, info.size);
fprintf (stderr,
-\n);
}
Re: [PATCH] Fix up adjust_return_value_with_ops (PR tree-optimization/56539)
On Wed, Mar 06, 2013 at 03:00:49PM -0700, Jeff Law wrote: Doesn't the code in update_accumulator_with_ops need the same change? No, the difference is that it uses false as the next to last argument, i.e. inserts after gsi, in which case GSI_CONTINUE_LINKING is desirable, so that the stmt is inserted after that. Unrelated, but the block comment still refers to UPDATE, which is no longer a parameter. Adjusted. I see similar looking code in tree-inline.c::copy_bb... Does it need updating as well? That is again false, GSI_CONTINUE_LINKING pair, i.e. insert after and update gsi to point after the added stmts. Jakub
RE: [PATCH ARM-Embedded-4_7-branch] fixing incoorect instruction length in checkin r193980
My bad for missing the patch. As stated in previous message, the patch has already been applied to ARM-Embedded-4_7-Branch. Thanks. -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Bin Cheng Sent: Friday, March 01, 2013 1:18 PM To: gcc-patches@gcc.gnu.org Cc: Joey Ye Subject: [PATCH ARM-Embedded-4_7-branch] fixing incoorect instruction length in checkin r193980 Hi, On ARM-Embedded-4_7 branch, check-in(r193980) causes a branch out of range bug. Root cause is the incorrect instruction length set by that check-in. Since the length of instruction should strictly reflect the pattern it matches, this patch fixes it by correcting the length. Patch applied to ARM-Embedded-4_7-branch as r196368. Thanks. 2013-03-01 Bin Cheng bin.ch...@arm.com * config/arm/arm.md (*arm_addsi3, *arm_subsi3_insn, *arm_mulsi3_v6) (*arm_andsi3_insn, andsi_notsi_si, *iorsi3_insn, *arm_xorsi3) (*arm_shiftsi3): Change attribute length from 2 to 4 for all alternatives. Index: gcc/config/arm/arm.md === --- gcc/config/arm/arm.md (revision 196332) +++ gcc/config/arm/arm.md (working copy) @@ -746,7 +746,7 @@ operands[1], 0); DONE; - [(set_attr length 2,4,4,4,4,4,2,4,4,4,4,16) + [(set_attr length 4,4,4,4,4,4,4,4,4,4,4,16) (set_attr predicable yes) (set_attr arch t2,*,*,*,t2,t2,t2,*,*,t2,t2,*)] ) @@ -1234,7 +1234,7 @@ INTVAL (operands[1]), operands[0], operands[2], 0); DONE; - [(set_attr length 4,2,4,4,16) + [(set_attr length 4,4,4,4,16) (set_attr predicable yes) (set_attr arch *,t2,*,*,*)] ) @@ -1360,7 +1360,7 @@ (match_operand:SI 2 s_register_operand 0,r)))] TARGET_32BIT arm_arch6 mul%?\\t%0, %1, %2 - [(set_attr length 2,4) + [(set_attr length 4,4) (set_attr insn mul) (set_attr predicable yes) (set_attr arch t2,*)] @@ -2213,7 +2213,7 @@ INTVAL (operands[2]), operands[0], operands[1], 0); DONE; - [(set_attr length 2,2,4,4,16) + [(set_attr length 4,4,4,4,16) (set_attr predicable yes) (set_attr arch t2,t2,*,*,*)] ) @@ -2797,7 +2797,7 @@ (match_operand:SI 1 s_register_operand 0,r)))] TARGET_32BIT bic%?\\t%0, %1, %2 - [(set_attr length 2,4) + [(set_attr length 4,4) (set_attr predicable yes) (set_attr arch t2,*)] ) @@ -2943,7 +2943,7 @@ INTVAL (operands[2]), operands[0], operands[1], 0); DONE; } - [(set_attr length 2,4,4,16) + [(set_attr length 4,4,4,16) (set_attr arch t2,32,t2,32) (set_attr predicable yes)]) @@ -3080,7 +3080,7 @@ INTVAL (operands[2]), operands[0], operands[1], 0); DONE; } - [(set_attr length 2,4,16) + [(set_attr length 4,4,16) (set_attr predicable yes) (set_attr arch t2,*,*)] ) @@ -3692,7 +3692,7 @@ (match_operand:SI 2 reg_or_int_operand l,rM)]))] TARGET_32BIT * return arm_output_shift(operands, 0); - [(set_attr length 2,4) + [(set_attr length 4,4) (set_attr predicable yes) (set_attr shift 1) (set (attr type) (if_then_else (match_operand 2 const_int_operand )
[PING^2] [AArch64] Implement Bitwise AND and Set Flags
Hi, Please consider this as a reminder to review the patch posted at following link:- http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00678.html Please review the patch and let me know if its okay? Thanks Regards, Naveen.H.S
Re: [PATCH, combine] Fix host-specific behavior in simplify_compare_const()
2013/3/5 Eric Botcazou ebotca...@adacore.com:
In other words, any 32-bit target with 'need_64bit_hwint=yes' in config.gcc
is not able to have benefit from this optimization because it never
passes the condition test.
My solution is to use GET_MODE_MASK(mode) to filter out all bits not
in target mode. The following is my patch:
The patch is OK for 4.9 once stage #1 is open if it passes bootstrap/regtest.
Thanks for the approval. I will wait for 4.9 stage1 opening.
The following is the new patch according to your suggestions:
gcc/ChangeLog:
* combine.c (simplify_compare_const): Use GET_MODE_MASK to filter out
unnecessary bits in the constant power of two case.
diff --git a/gcc/combine.c b/gcc/combine.c
index 67bd776..ce2b583 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -10917,8 +10917,9 @@ simplify_compare_const (enum rtx_code code,
rtx op0, rtx *pop1)
(code == EQ || code == NE || code == GE || code == GEU
|| code == LT || code == LTU)
mode_width = HOST_BITS_PER_WIDE_INT
- exact_log2 (const_op) = 0
- nonzero_bits (op0, mode) == (unsigned HOST_WIDE_INT) const_op)
+ exact_log2 (const_op GET_MODE_MASK (mode)) = 0
+ (nonzero_bits (op0, mode)
+ == (unsigned HOST_WIDE_INT) (const_op GET_MODE_MASK (mode
{
code = (code == EQ || code == GE || code == GEU ? NE : EQ);
const_op = 0;
Best regards,
jasonwucj
Re: [PATCH 1/2] [pr53679] libgo: add a --enable-werror configure flag
On Wednesday 06 March 2013 10:49:23 Diego Novillo wrote: On Tue, Mar 5, 2013 at 12:31 AM, Ian Lance Taylor i...@google.com wrote: On Mon, Mar 4, 2013 at 4:11 PM, Mike Frysinger vap...@gentoo.org wrote: On Saturday 26 January 2013 21:40:44 Ian Lance Taylor wrote: On Fri, Jan 25, 2013 at 7:20 PM, Mike Frysinger wrote: On Friday 25 January 2013 19:13:55 Ian Lance Taylor wrote: On Tue, Jan 15, 2013 at 9:45 AM, Mike Frysinger wrote: On Tuesday 15 January 2013 09:56:06 Ian Lance Taylor wrote: On Sun, Dec 23, 2012 at 3:30 PM, Mike Frysinger wrote: diff --git a/libgo/configure.ac b/libgo/configure.ac index 8cde50b..63d8cbc 100644 --- a/libgo/configure.ac +++ b/libgo/configure.ac @@ -50,8 +50,11 @@ AC_PROG_AWK WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual' AC_SUBST(WARN_FLAGS) -dnl FIXME: This should be controlled by --enable-maintainer-mode. -WERROR=-Werror +AC_ARG_ENABLE(werror, [AS_HELP_STRING([--enable-werror], + [turns on -Werror @:@default=yes@:@])]) +if test x$enable_werror != xno; then + WERROR=-Werror +fi AC_SUBST(WERROR) glibgo_toolexecdir=no Can you say something about when you needed this? What errors were you seeing? the referenced PR describes one: /build/src/gcc-4.7.1/libgo/runtime/print.c: In function 'gwrite': /build/src/gcc-4.7.1/libgo/runtime/print.c:20:3: error: ignoring return value of 'write', declared with attribute warn_unused_result [-Werror=unused-result] cc1: all warnings being treated as errors this bites distros that enable security settings by default (such as fortify and ssp). but ignoring even that, i don't believe releases should build all the time with -Werror -- i'm fine with defaulting to on as long as there is a configure flag to turn it off which is what this does like is already handled in much of the sourceware tree. -Werror is great for development, but sucks when deployed on actual systems. the assumptions made at time of checkin rarely stay constant forever (in this case, a changing lib C can easily break it). -mike Thanks for the explanation. Committed to mainline. thanks! mind if i commit it to gcc-4.6 and gcc-4.7 too ? I certainly don't mind. You should probably get agreement from the release managers although this seems safe enough. can you approve merges to the google branches ? that's really where i want this :). No, I don't work on those branches. Sorry. I committed this patch to google/gcc-4_7 rev 196494. Feel free to commit to google/gcc-4_6 if you need to. nope, we just need it in 4.7, thanks! -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Fix PR 55473
On Wed, Mar 06, 2013 at 01:14:45PM +0530, Shakthi Kannan wrote: The libquadmath/quadmath.h file cannot be used with C++. The following patch allows inclusion and use of the quadmath.h header file. 2013-03-06 Shakthi Kannan shakthim...@gmail.com PR libquadmath/55473 * quadmath.h: Add ifdef __cplusplus macros. Thanks, committed (with different ChangeLog entry, both for formatting and description). Jakub
