Merged trunk to gccgo branch
I merged trunk revision 183826 to the gccgo branch. Ian
Re: [PATCH] Don't ICE in vectorizer when testing if a pattern stmt is used by another pattern stmt (PR tree-optimization/52073)
Jakub Jelinek wrote on 01/02/2012 06:40:13 PM:
> Hi!
>
Hi,
> vinfo_for_stmt can't be used on stmts outside of the current loop.
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Yes.
Thanks,
Ira
>
> 2012-02-01 Jakub Jelinek
>
>PR tree-optimization/52073
>* tree-vect-stmts.c (vect_mark_relevant): When checking uses of
>a pattern stmt for pattern uses, ignore uses outside of the loop.
>
>* gcc.c-torture/compile/pr52073.c: New test.
>
> --- gcc/tree-vect-stmts.c.jj 2012-01-22 16:02:10.0 +0100
> +++ gcc/tree-vect-stmts.c 2012-02-01 10:33:58.847815421 +0100
> @@ -150,6 +150,8 @@ vect_mark_relevant (VEC(gimple,heap) **w
>use_operand_p use_p;
>gimple use_stmt;
>tree lhs;
> + loop_vec_info loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_info);
> + struct loop *loop = LOOP_VINFO_LOOP (loop_vinfo);
>
>if (is_gimple_assign (stmt))
> lhs = gimple_assign_lhs (stmt);
> @@ -166,6 +168,9 @@ vect_mark_relevant (VEC(gimple,heap) **w
> continue;
>use_stmt = USE_STMT (use_p);
>
> + if (!flow_bb_inside_loop_p (loop, gimple_bb (use_stmt)))
> +continue;
> +
>if (vinfo_for_stmt (use_stmt)
>&& STMT_VINFO_IN_PATTERN_P (vinfo_for_stmt (use_stmt)))
> {
> --- gcc/testsuite/gcc.c-torture/compile/pr52073.c.jj 2012-02-01
> 10:39:13.041003562 +0100
> +++ gcc/testsuite/gcc.c-torture/compile/pr52073.c 2012-02-01 10:
> 38:51.0 +0100
> @@ -0,0 +1,28 @@
> +/* PR tree-optimization/52073 */
> +
> +int a, b, c, d, e, f;
> +
> +void
> +foo (int x)
> +{
> + e = 1;
> + for (;;)
> +{
> + int g = c;
> + if (x)
> + {
> + if (e)
> + continue;
> + while (a)
> + --f;
> + }
> + else
> + for (b = 5; b; b--)
> + {
> + d = g;
> + g = 0 == d;
> + }
> + if (!g)
> + x = 0;
> +}
> +}
>
>Jakub
>
libgo patch committed: Add syscall.Times
This patch to libgo adds the syscall.Times function, which corresponds
to the POSIX function times. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 492a0c57d461 libgo/go/syscall/libcall_posix.go
--- a/libgo/go/syscall/libcall_posix.go Wed Feb 01 22:22:41 2012 -0800
+++ b/libgo/go/syscall/libcall_posix.go Wed Feb 01 22:38:30 2012 -0800
@@ -133,15 +133,15 @@
}
func FDSet(fd int, set *FdSet) {
- set.Bits[fd / nfdbits] |= (1 << (uint)(fd % nfdbits))
+ set.Bits[fd/nfdbits] |= (1 << (uint)(fd%nfdbits))
}
func FDClr(fd int, set *FdSet) {
- set.Bits[fd / nfdbits] &^= (1 << (uint)(fd % nfdbits))
+ set.Bits[fd/nfdbits] &^= (1 << (uint)(fd%nfdbits))
}
func FDIsSet(fd int, set *FdSet) bool {
- if set.Bits[fd / nfdbits] & (1 << (uint)(fd % nfdbits)) != 0 {
+ if set.Bits[fd/nfdbits]&(1<<(uint)(fd%nfdbits)) != 0 {
return true
} else {
return false
@@ -323,9 +323,8 @@
// //sysnb Time(t *Time_t) (tt Time_t, err error)
// //time(t *Time_t) Time_t
-// FIXME: mksysinfo Tms
-// //sysnb Times(tms *Tms) (ticks uintptr, err error)
-// //times(tms *Tms) _clock_t
+//sysnb Times(tms *Tms) (ticks uintptr, err error)
+//times(tms *Tms) _clock_t
//sysnb Umask(mask int) (oldmask int)
//umask(mask Mode_t) Mode_t
diff -r 492a0c57d461 libgo/mksysinfo.sh
--- a/libgo/mksysinfo.sh Wed Feb 01 22:22:41 2012 -0800
+++ b/libgo/mksysinfo.sh Wed Feb 01 22:38:30 2012 -0800
@@ -66,6 +66,7 @@
#include
#include
#include
+#include
#include
#include
#if defined(HAVE_SYS_USER_H)
@@ -368,6 +369,15 @@
-e 's/tv_nsec *[a-zA-Z0-9_]*/Nsec Timestruc_nsec_t/' >> ${OUT}
fi
+# The tms struct.
+grep '^type _tms ' gen-sysinfo.go | \
+sed -e 's/type _tms/type Tms/' \
+ -e 's/tms_utime/Utime/' \
+ -e 's/tms_stime/Stime/' \
+ -e 's/tms_cutime/Cutime/' \
+ -e 's/tms_cstime/Cstime/' \
+>> ${OUT}
+
# The stat type.
# Prefer largefile variant if available.
stat=`grep '^type _stat64 ' gen-sysinfo.go || true`
Go patch committed: Fix method expression parameter references
The Go frontend had a couple of bugs when using method expressions with
parameters. It crashed if the parameters had no names. And it did the
wrong thing if the types were imported. This patch fixes both
problems. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 0192d111870c go/expressions.cc
--- a/go/expressions.cc Wed Feb 01 13:27:58 2012 -0800
+++ b/go/expressions.cc Wed Feb 01 22:10:52 2012 -0800
@@ -11711,10 +11711,21 @@
const Typed_identifier_list* method_parameters = method_type->parameters();
if (method_parameters != NULL)
{
+ int i = 0;
for (Typed_identifier_list::const_iterator p = method_parameters->begin();
p != method_parameters->end();
- ++p)
- parameters->push_back(*p);
+ ++p, ++i)
+ {
+ if (!p->name().empty() && p->name() != Import::import_marker)
+ parameters->push_back(*p);
+ else
+ {
+ char buf[20];
+ snprintf(buf, sizeof buf, "$param%d", i);
+ parameters->push_back(Typed_identifier(buf, p->type(),
+ p->location()));
+ }
+ }
}
const Typed_identifier_list* method_results = method_type->results();
@@ -11774,14 +11785,14 @@
}
Expression_list* args;
- if (method_parameters == NULL)
+ if (parameters->size() <= 1)
args = NULL;
else
{
args = new Expression_list();
- for (Typed_identifier_list::const_iterator p = method_parameters->begin();
- p != method_parameters->end();
- ++p)
+ Typed_identifier_list::const_iterator p = parameters->begin();
+ ++p;
+ for (; p != parameters->end(); ++p)
{
vno = gogo->lookup(p->name(), NULL);
go_assert(vno != NULL);
Re: Configuring gcc without symlink support
On 02/02/2012 12:41 AM, Earl Chew wrote: Some environments don't support symbolic links :-( If ln -s is not supported, configure can figure it out, and as a last resort uses: LN_S = cp -p I've found two problems with this. The first problem is that LN_S is not propagated past the top-level Makefile. This can manifest as strange GCC_NO_EXECUTABLES messages: Link tests are not allowed after GCC_NO_EXECUTABLES The patch (against an older gcc 4.2.4) addresses this first problem. The second is that: cp -p $1 $2 mimics ln -s $1 $2 only if $1 is an absolute path, or $2 does not contain any path separators. This is not always true. For example: gcc/gcc/config/t-slibgcc-elf-ver: $(LN_S) $(SHLIB_SONAME) $(SHLIB_DIR)/$(SHLIB_SOLINK) There doesn't seem to be any straightforward way around this except diligence: cd $(SHLIB_DIR)&& $(LN_S) $(SHLIB_SONAME) $(SHLIB_SOLINK) Additionally building in directory libada requires symlinking directories, so 'cp -p' in not enough. I have tried to use there 'cp -pR' instead. Andris PS. I have not tested with 4.7 yet, but with 4.6 it was so
Re: [PATCH, rs6000] Add support for the POWER7 dcffix instruction
On Wed, Feb 1, 2012 at 10:00 PM, Peter Bergner wrote: > The POWER Toolchain IPC team who is adding POWER7 support to valgrind > reminded me that Power ISA 2.06 added a new convert from integer to > decimal64 dfp instruction. The following patch adds support for it. > > This passed bootstrap and regression testing with no regressions. > Is this ok? If so, when can this be committed? Now or stage1? Stage 1. - David
Re: [PATCH] [MIPS] fix mips_prepend insn.
diff --git a/gcc/config/mips/mips-dspr2.md
b/gcc/config/mips/mips-dspr2.mdindex 5ae902f..6853b9d 100644---
a/gcc/config/mips/mips-dspr2.md+++ b/gcc/config/mips/mips-dspr2.md@@
-345,7 +345,7 @@ (set_attr "mode""SI")]) (define_insn
"mips_prepend"- [(set (match_operand:SI 0 "register_operand" "=d")+
[(set (match_operand:DI 0 "register_operand" "=d")
According to the manual, it should be DI, not SI here.
(unspec:SI [(match_operand:SI 1 "register_operand" "0")
(match_operand:SI 2 "reg_or_0_operand" "dJ") (match_operand:SI 3
"const_int_operand" "n")]@@ -353,7 +353,7 @@ "ISA_HAS_DSPR2" { if
(INTVAL (operands[3]) & ~(unsigned HOST_WIDE_INT) 31)- operands[2]
= GEN_INT (INTVAL (operands[2]) & 31);+ operands[3] = GEN_INT
(INTVAL (operands[3]) & 31);
I think here should be operands[3] but operands[2], because it is
operate sa not rs.
return "prepend\t%0,%z2,%3"; } [(set_attr "type" "arith")
On Thu, Feb 2, 2012 at 10:37 AM, Liu wrote:
> Hi all
>
> This is the bugfix patch for mips_prepend, please review.
>
>
> Jia Liu
Re: [wwwdocs] Add section on diagnostics conventions
Thanks. I've incorporated your feedback in the attached patch. OK for wwwdocs? Diego. ? 00.diff ? codingconventions.html.orig Index: codingconventions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v retrieving revision 1.63 diff -u -d -u -p -r1.63 codingconventions.html --- codingconventions.html 12 Feb 2011 15:49:51 - 1.63 +++ codingconventions.html 2 Feb 2012 03:06:00 - @@ -157,6 +157,57 @@ regression-checkers distinguish a true r to the test suite. +Diagnostics Conventions + + +Use of the input_location global, and of the +diagnostic functions that implicitly use input_location, +is deprecated; the preferred technique is to pass around locations +ultimately derived from the location of some explicitly chosen source +code token. + +Diagnostics using the GCC diagnostic functions should generally +use the GCC-specific formats such as %qs or +%< and %> for quoting and +%m for errno numbers. + +Identifiers should generally be formatted with %E or +%qE; use of identifier_to_locale is needed +if the identifier text is used directly. + +Formats such as %wd should be used with types such as +HOST_WIDE_INT (HOST_WIDE_INT_PRINT_DEC is a +format for the host printf functions, not for the GCC +diagnostic functions). + +error is for defects in the user's code. + +sorry is for correct user input programs but +unimplemented functionalities. + +warning is for advisory diagnostics; it +may be used for diagnostics that have severity less than an +error. + +inform is for adding additional explanatory +information to a diagnostic. + +internal_error is used for conditions that should not +be triggered by any user input whether valid or invalid and including +invalid asms and LTO binary data (sometimes, as an exception, there is +a call to error before further information is printed and +an ICE is triggered). Assertion failures should not be triggered by +invalid input. + +inform is for informative notes accompanying errors +and warnings. + +All diagnostics should be full sentences without English +fragments substituted in them, to facilitate translation. + + + + Miscellaneous Conventions Code should use gcc_assert(EXPR) to check invariants.
Re: [wwwdocs] Add section on diagnostics conventions
On Wed Feb 1 09:15:51 2012, Georg-Johann Lay wrote: Diego Novillo wrote: This is the first of a few patches to update GCC's documentation with the proposed conventions in the GCC Development Conventions document that Joseph and I published last year (https://docs.google.com/a/google.com/document/pub?id=10LO8y0YhjlKHya_PKM3jEGrJu0rllv-Nc9qP5LXqH_I#h.qpg2rjcas9fw) I am just starting to get back to these documents, so I will start with the "easy" parts. Joseph, Gabriel, I'm sending this patch to you since you folks maintain these areas. Other changes to the documentation may need global reviewers. OK for wwwdocs? Diego. Index: codingconventions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v retrieving revision 1.63 diff -u -d -u -p -r1.63 codingconventions.html --- codingconventions.html 12 Feb 2011 15:49:51 - 1.63 +++ codingconventions.html 29 Jan 2012 21:51:56 - @@ -157,6 +157,45 @@ regression-checkers distinguish a true r to the test suite. +Diagnostics Conventions + + +Use of theinput_location global, and of the +diagnostic functions that implicitly useinput_location, +is deprecated; the preferred technique is to pass around locations +ultimately derived from the location of some explicitly chosen source +code token. + +Diagnostics using the GCC diagnostic functions should generally +use the GCC-specific formats such as%qs or +%< and%> for quoting and +%m forerrno numbers. A link to respective documentation would be greatly appreciated, i.e. a link to the internals section describing the %-codes for diagnostic or a link to the source file's comments. Yes, I know it's in the sources. But guess you searched for documentation and correct usage of %D. It will take you quite some time to find it in the sources... Sadly, these modifiers are not documented in gcc/doc/, the only documentation I know of is in gcc/pretty-print.c. I think it would be a great idea to also document them in the .texi sources. Would you be willing to prepare a patch? Thanks. Diego.
[PATCH, rs6000] Add support for the POWER7 dcffix instruction
The POWER Toolchain IPC team who is adding POWER7 support to valgrind reminded me that Power ISA 2.06 added a new convert from integer to decimal64 dfp instruction. The following patch adds support for it. This passed bootstrap and regression testing with no regressions. Is this ok? If so, when can this be committed? Now or stage1? Peter * config/rs6000/dfp.md (floatdidd2): New define_insn. Index: gcc/config/rs6000/dfp.md === --- gcc/config/rs6000/dfp.md(revision 183808) +++ gcc/config/rs6000/dfp.md(working copy) @@ -546,6 +546,13 @@ (define_insn "*cmptd_internal1" "dcmpuq %0,%1,%2" [(set_attr "type" "fpcompare")]) +(define_insn "floatdidd2" + [(set (match_operand:DD 0 "gpc_reg_operand" "=d") + (float:DD (match_operand:DI 1 "gpc_reg_operand" "d")))] + "TARGET_DFP && TARGET_POPCNTD" + "dcffix %0,%1" + [(set_attr "type" "fp")]) + (define_insn "floatditd2" [(set (match_operand:TD 0 "gpc_reg_operand" "=d") (float:TD (match_operand:DI 1 "gpc_reg_operand" "d")))]
[pph] More GC fixes (issue5606049)
This patch extends the hack I added in
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01031.html to pacify the garbage
collector.
I have to keep using the same fake GC root because these trees are
added to structures that I can't seem to get properly annotated for
GC. In particular, I'm having trouble with 'FILE' pointers. I will
try to figure this out at some point, but we've got bigger issues to
address at the moment.
The specific problem this time was that bitsizetype was being
GC'd out while we were reading a PPH image. This was causing
ICEs when we were trying to read many PPH images.
2012-02-01 Diego Novillo
* config-lang.in (gtfiles): Remove pph-out.c. Add pph-core.c.
* pph-core.c: Include gt-cp-pph-core.h.
(pph_cached_trees): Declare.
(pph_cache_insert_at): If adding a tree to the cache, also
add it to pph_cached_trees.
(pph_streamer_init): Set pph_cached_trees to NULL.
(pph_streamer_finish): Likewise.
Call ggc_collect.
* pph-out.c (pph_decls_in_symtab): Remove. Update all users.
---
gcc/cp/ChangeLog.pph | 12
gcc/cp/config-lang.in |2 +-
gcc/cp/pph-core.c | 25 +
gcc/cp/pph-out.c | 22 --
4 files changed, 38 insertions(+), 23 deletions(-)
diff --git a/gcc/cp/ChangeLog.pph b/gcc/cp/ChangeLog.pph
index 8e8080d..ec80b56 100644
--- a/gcc/cp/ChangeLog.pph
+++ b/gcc/cp/ChangeLog.pph
@@ -1,3 +1,15 @@
+2012-02-01 Diego Novillo
+
+ * config-lang.in (gtfiles): Remove pph-out.c. Add pph-core.c.
+ * pph-core.c: Include gt-cp-pph-core.h.
+ (pph_cached_trees): Declare.
+ (pph_cache_insert_at): If adding a tree to the cache, also
+ add it to pph_cached_trees.
+ (pph_streamer_init): Set pph_cached_trees to NULL.
+ (pph_streamer_finish): Likewise.
+ Call ggc_collect.
+ * pph-out.c (pph_decls_in_symtab): Remove. Update all users.
+
2012-02-01 Lawrence Crowl
* pph-streamer.h (pph_trace_tree): Add name parameter. Adjust callers
diff --git a/gcc/cp/config-lang.in b/gcc/cp/config-lang.in
index ab8e686..7dbfe95 100644
--- a/gcc/cp/config-lang.in
+++ b/gcc/cp/config-lang.in
@@ -30,4 +30,4 @@ compilers="cc1plus\$(exeext)"
target_libs="target-libstdc++-v3"
-gtfiles="\$(srcdir)/cp/rtti.c \$(srcdir)/cp/mangle.c
\$(srcdir)/cp/name-lookup.h \$(srcdir)/cp/name-lookup.c \$(srcdir)/cp/cp-tree.h
\$(srcdir)/cp/decl.h \$(srcdir)/cp/call.c \$(srcdir)/cp/decl.c
\$(srcdir)/cp/decl2.c \$(srcdir)/cp/pt.c \$(srcdir)/cp/repo.c
\$(srcdir)/cp/semantics.c \$(srcdir)/cp/tree.c \$(srcdir)/cp/parser.h
\$(srcdir)/cp/parser.c \$(srcdir)/cp/method.c \$(srcdir)/cp/typeck2.c
\$(srcdir)/c-family/c-common.c \$(srcdir)/c-family/c-common.h
\$(srcdir)/c-family/c-objc.h \$(srcdir)/c-family/c-lex.c
\$(srcdir)/c-family/c-pragma.h \$(srcdir)/c-family/c-pragma.c
\$(srcdir)/cp/class.c \$(srcdir)/cp/cp-objcp-common.c \$(srcdir)/cp/cp-lang.c
\$(srcdir)/cp/except.c \$(srcdir)/cp/pph-out.c"
+gtfiles="\$(srcdir)/cp/rtti.c \$(srcdir)/cp/mangle.c
\$(srcdir)/cp/name-lookup.h \$(srcdir)/cp/name-lookup.c \$(srcdir)/cp/cp-tree.h
\$(srcdir)/cp/decl.h \$(srcdir)/cp/call.c \$(srcdir)/cp/decl.c
\$(srcdir)/cp/decl2.c \$(srcdir)/cp/pt.c \$(srcdir)/cp/repo.c
\$(srcdir)/cp/semantics.c \$(srcdir)/cp/tree.c \$(srcdir)/cp/parser.h
\$(srcdir)/cp/parser.c \$(srcdir)/cp/method.c \$(srcdir)/cp/typeck2.c
\$(srcdir)/c-family/c-common.c \$(srcdir)/c-family/c-common.h
\$(srcdir)/c-family/c-objc.h \$(srcdir)/c-family/c-lex.c
\$(srcdir)/c-family/c-pragma.h \$(srcdir)/c-family/c-pragma.c
\$(srcdir)/cp/class.c \$(srcdir)/cp/cp-objcp-common.c \$(srcdir)/cp/cp-lang.c
\$(srcdir)/cp/except.c \$(srcdir)/cp/pph-core.c"
diff --git a/gcc/cp/pph-core.c b/gcc/cp/pph-core.c
index d20d45b..814060f 100644
--- a/gcc/cp/pph-core.c
+++ b/gcc/cp/pph-core.c
@@ -90,6 +90,19 @@ struct pph_stream_registry_d {
static struct pph_stream_registry_d pph_stream_registry;
+/* List of all the trees added to PPH pickle caches.
+
+ FIXME pph, the *only* purpose of this list is to act as a GC root
+ to avoid these trees from being garbage collected.
+
+ The parser will invoke garbage collection, which may clobber some
+ trees in the pickle caches (because the pickle caches are stored on
+ the heap). Ideally, we would put all these data structures on GC
+ memory. */
+static GTY(()) VEC(tree,gc) *pph_cached_trees;
+
+
+
/*** pph logging */
@@ -540,6 +553,11 @@ pph_cache_insert_at (pph_cache *cache, void *data,
unsigned ix,
VEC_safe_grow_cleared (pph_cache_entry, heap, cache->v, ix + 1);
VEC_replace (pph_cache_entry, cache->v, ix, &e);
+ /* FIXME pph. Hack to prevent cached trees from being garbage
+ collected. */
+ if ((unsigned) tag <= (unsigned) PPH_any_tree)
+VEC_safe_push (tree, gc, pph_cached_trees, (tree) data);
+
return pph_cache_get_entry (cache, ix);
Re: [pph] Minimal type merging. (issue5620047)
On Wed, Feb 1, 2012 at 18:44, Lawrence Crowl wrote: > @@ -1393,7 +1393,12 @@ dump_function_decl (tree t, int flags) > } > > fntype = TREE_TYPE (t); > - parmtypes = FUNCTION_FIRST_USER_PARMTYPE (t); > + gcc_assert (fntype) You forgot a semi-colon :) Fixed. Diego.
[pph] Minimal type merging. (issue5620047)
This patch adds minimal type merging. It unifies the existence of
types for a struct decl. The method is to emit a merge key for the
type when we emit a merge key for the struct decl.
Test x4structover1.cc is now passing.
The next step is to merge struct definitions. For that we have test
cases x*incomplete*, which progressively add more information to the
classes in different configurations of pph files.
Tested on x64.
Index: gcc/testsuite/ChangeLog.pph
2012-02-01 Lawrence Crowl
* g++.dg/pph/x4structover1.cc: Mark fixed.
* g++.dg/pph/a0incomplete2.hi: New.
* g++.dg/pph/a0incomplete3.hi: New.
* g++.dg/pph/a0incomplete4.cci: New.
* g++.dg/pph/x0incomplete1.h: New.
* g++.dg/pph/x0incomplete2.h: New.
* g++.dg/pph/x0incomplete3.h: New.
* g++.dg/pph/x1incomplete3.h: New.
* g++.dg/pph/x1incomplete4.cc: New.
* g++.dg/pph/x2incomplete4.cc: New.
* g++.dg/pph/x3incomplete412.cc: New.
* g++.dg/pph/x3incomplete413.cc: New.
* g++.dg/pph/x4incomplete4123.cc: New.
* g++.dg/pph/x4incomplete4321.cc: New.
Index: gcc/cp/ChangeLog.pph
2012-02-01 Lawrence Crowl
* error.c (dump_function_decl): Add protection against NULL.
* pph-out.c (pph_out_merge_key_tree): Write merge keys for struct
types, as opposed to decls.
* pph-in.c (pph_in_merge_tree_body): Save chains in decls only.
(pph_in_merge_key_tree): Read merge keys for struct types. Split
handling into two phases, cache insertion (which is before the trace
front) and sub-tree reading.
Index: gcc/testsuite/g++.dg/pph/x1incomplete3.h
===
--- gcc/testsuite/g++.dg/pph/x1incomplete3.h(revision 0)
+++ gcc/testsuite/g++.dg/pph/x1incomplete3.h(revision 0)
@@ -0,0 +1,7 @@
+#ifndef X0INCOMPLETE3_H
+#define X0INCOMPLETE3_H
+
+#include "x0incomplete2.h"
+#include "a0incomplete3.hi"
+
+#endif
Index: gcc/testsuite/g++.dg/pph/x0incomplete2.h
===
--- gcc/testsuite/g++.dg/pph/x0incomplete2.h(revision 0)
+++ gcc/testsuite/g++.dg/pph/x0incomplete2.h(revision 0)
@@ -0,0 +1,6 @@
+#ifndef X0INCOMPLETE2_H
+#define X0INCOMPLETE2_H
+
+#include "a0incomplete2.hi"
+
+#endif
Index: gcc/testsuite/g++.dg/pph/x2incomplete4.cc
===
--- gcc/testsuite/g++.dg/pph/x2incomplete4.cc (revision 0)
+++ gcc/testsuite/g++.dg/pph/x2incomplete4.cc (revision 0)
@@ -0,0 +1,5 @@
+// { dg-xfail-if "ICE" { "*-*-*" } { "-fpph-map=pph.map" } }
+// { dg-bogus "internal compiler error: in import_export_decl, at cp/decl2.c"
"" { xfail *-*-* } 0 }
+
+#include "x1incomplete3.h"
+#include "a0incomplete4.cci"
Index: gcc/testsuite/g++.dg/pph/x0incomplete3.h
===
--- gcc/testsuite/g++.dg/pph/x0incomplete3.h(revision 0)
+++ gcc/testsuite/g++.dg/pph/x0incomplete3.h(revision 0)
@@ -0,0 +1,7 @@
+#ifndef X0INCOMPLETE3_H
+#define X0INCOMPLETE3_H
+
+#include "a0incomplete2.hi"
+#include "a0incomplete3.hi"
+
+#endif
Index: gcc/testsuite/g++.dg/pph/x1incomplete4.cc
===
--- gcc/testsuite/g++.dg/pph/x1incomplete4.cc (revision 0)
+++ gcc/testsuite/g++.dg/pph/x1incomplete4.cc (revision 0)
@@ -0,0 +1,2 @@
+#include "x0incomplete3.h"
+#include "a0incomplete4.cci"
Index: gcc/testsuite/g++.dg/pph/a0incomplete4.cci
===
--- gcc/testsuite/g++.dg/pph/a0incomplete4.cci (revision 0)
+++ gcc/testsuite/g++.dg/pph/a0incomplete4.cci (revision 0)
@@ -0,0 +1,5 @@
+int query( copies arg )
+{
+copies var( arg );
+return var.value();
+}
Index: gcc/testsuite/g++.dg/pph/x4incomplete4123.cc
===
--- gcc/testsuite/g++.dg/pph/x4incomplete4123.cc(revision 0)
+++ gcc/testsuite/g++.dg/pph/x4incomplete4123.cc(revision 0)
@@ -0,0 +1,4 @@
+#include "x0incomplete1.h"
+#include "x0incomplete2.h"
+#include "x0incomplete3.h"
+#include "a0incomplete4.cci"
Index: gcc/testsuite/g++.dg/pph/x3incomplete412.cc
===
--- gcc/testsuite/g++.dg/pph/x3incomplete412.cc (revision 0)
+++ gcc/testsuite/g++.dg/pph/x3incomplete412.cc (revision 0)
@@ -0,0 +1,4 @@
+#include "x0incomplete1.h"
+#include "x0incomplete2.h"
+#include "a0incomplete3.hi"
+#include "a0incomplete4.cci"
Index: gcc/testsuite/g++.dg/pph/a0incomplete2.hi
===
--- gcc/testsuite/g++.dg/pph/a0incomplete2.hi (revision 0)
+++ gcc/testsuite/g++.dg/pph/a0incomplete2.hi (revision 0)
@@ -0,0 +1,12 @@
+#ifndef A0INCOMPLETE2_HI
+#define A0INCOMPLETE2_HI
+
+struct copies
+{
+copies();
+copies( const copies &arg );
+in
[PATCH] [MIPS] fix mips_prepend insn.
Hi all
This is the bugfix patch for mips_prepend, please review.
Jia Liu
diff --git a/gcc/config/mips/mips-dspr2.md b/gcc/config/mips/mips-dspr2.md
index 5ae902f..6853b9d 100644
--- a/gcc/config/mips/mips-dspr2.md
+++ b/gcc/config/mips/mips-dspr2.md
@@ -345,7 +345,7 @@
(set_attr "mode""SI")])
(define_insn "mips_prepend"
- [(set (match_operand:SI 0 "register_operand" "=d")
+ [(set (match_operand:DI 0 "register_operand" "=d")
(unspec:SI [(match_operand:SI 1 "register_operand" "0")
(match_operand:SI 2 "reg_or_0_operand" "dJ")
(match_operand:SI 3 "const_int_operand" "n")]
@@ -353,7 +353,7 @@
"ISA_HAS_DSPR2"
{
if (INTVAL (operands[3]) & ~(unsigned HOST_WIDE_INT) 31)
-operands[2] = GEN_INT (INTVAL (operands[2]) & 31);
+operands[3] = GEN_INT (INTVAL (operands[3]) & 31);
return "prepend\t%0,%z2,%3";
}
[(set_attr "type""arith")
Configuring gcc without symlink support
Some environments don't support symbolic links :-( If ln -s is not supported, configure can figure it out, and as a last resort uses: LN_S = cp -p I've found two problems with this. The first problem is that LN_S is not propagated past the top-level Makefile. This can manifest as strange GCC_NO_EXECUTABLES messages: Link tests are not allowed after GCC_NO_EXECUTABLES The patch (against an older gcc 4.2.4) addresses this first problem. The second is that: cp -p $1 $2 mimics ln -s $1 $2 only if $1 is an absolute path, or $2 does not contain any path separators. This is not always true. For example: gcc/gcc/config/t-slibgcc-elf-ver: $(LN_S) $(SHLIB_SONAME) $(SHLIB_DIR)/$(SHLIB_SOLINK) There doesn't seem to be any straightforward way around this except diligence: cd $(SHLIB_DIR) && $(LN_S) $(SHLIB_SONAME) $(SHLIB_SOLINK) Earl --- gcc/gcc/Makefile.in.orig2012-02-01 11:27:52.783587886 -0800 +++ gcc/gcc/Makefile.in 2012-02-01 11:56:37.973586113 -0800 @@ -1465,6 +1465,7 @@ MULTILIB_OSDIRNAMES='$(MULTILIB_OSDIRNAMES)' \ ASM_HIDDEN_OP='$(ASM_HIDDEN_OP)' \ GCC_FOR_TARGET='$(GCC_FOR_TARGET)' \ + LN_S='$(LN_S)' \ mkinstalldirs='$(mkinstalldirs)' \ $(SHELL) mklibgcc > tmp-libgcc.mk mv tmp-libgcc.mk libgcc.mk --- gcc/Makefile.in.orig2012-02-01 15:08:00.353579677 -0800 +++ gcc/Makefile.in 2012-02-01 15:09:38.196088006 -0800 @@ -486,7 +486,8 @@ "`echo 'LANGUAGES=$(LANGUAGES)' | sed -e s'/[^=][^=]*=$$/XFOO=/'`" \ "LEAN=$(LEAN)" \ "CONFIG_SHELL=$(SHELL)" \ - "MAKEINFO=$(MAKEINFO) $(MAKEINFOFLAGS)" + "MAKEINFO=$(MAKEINFO) $(MAKEINFOFLAGS)" \ + "LN_S=$(LN_S)" # We leave this in just in case, but it is not needed anymore. RECURSE_FLAGS_TO_PASS = $(BASE_FLAGS_TO_PASS)
Too much memory in chan/select2.go used
On Wed, Feb 1, 2012 at 10:27 PM, Ian Lance Taylor wrote: >> (BTW: Do you have any idea on what to do with excessive memory usage >> in chan/select2.go? ) > > At this point I don't. It's sort of peculiar. Sending an int on a > channel should not use any memory. The test is careful to only measure > the memory allocated for sending and receiving, and as far as I can see > nothing else should be allocated during the test. You reported that the > test was allocating 2098576 bytes. When I run it I see it allocating > 1408 bytes on x86_64, 640 bytes on i386. 2098576 is much larger than > either number. What is allocating that memory? > > In other words, there appears to be a real bug here. You can probably > track it down by setting a breakpoint on runtime_mallocgc after the line > runtime.MemStats.Alloc = 0 > What is calling runtime_mallocgc? The backtrace says: After a couple of calls from __go_new_channel, __go_new,__go_alloc, the test starts to loop with allocations from newselect: Breakpoint 2, runtime_mallocgc (size=156, flag=0, dogc=1, zeroed=1) at ../../../gcc-svn/trunk/libgo/runtime/malloc.goc:41 41 m = runtime_m(); (gdb) bt #0 runtime_mallocgc (size=156, flag=0, dogc=1, zeroed=1) at ../../../gcc-svn/trunk/libgo/runtime/malloc.goc:41 #1 0x02510364 in runtime_mal (n=156) at ../../../gcc-svn/trunk/libgo/runtime/malloc.goc:414 #2 0x02506424 in newselect (selp=, size=2) at ../../../gcc-svn/trunk/libgo/runtime/chan.c:644 #3 runtime.newselect (size=) at ../../../gcc-svn/trunk/libgo/runtime/chan.c:c630 #4 0x000120001634 in main.receiver (c=0xf84020e000, dummy=0xf84020e7c0, n=10) at /space/uros/gcc-svn/trunk/gcc/testsuite/go.test/test/chan/select2.go:19 #5 0x000120001824 in main.main () at /space/uros/gcc-svn/trunk/gcc/testsuite/go.test/test/chan/select2.go:36 I didn't check where memory gets de-allocated, but there are really a lot of above calls. Uros.
[wwwdocs] libstdcxx_so_7-2-branch branch creation
Hello I have created yesterday the libstdcxx_so_7-2-branch in the gcc repo that only contains the libstdc++-v3 folder. This branch will contain all the abi breaking changes that are plan to be moved to trunk as soon as the decision to break the abi will have been taken. Paolo Carlini advise me to write you, and the mailing list, to ask if you could document it on this page: http://gcc.gnu.org/svn.html I don't know how to access it by myself. For info, libstdcxx_so_7-branch is not maintained anymore but some pieces of code in it might be reuse in this new branch, this is why we don't want to touch it for the moment. Thank you for your help. François
Go patch committed: Fix type checking for append
The Go language specification says that for
append(a1, a2)
a1 must be a slice. If the element type of a1 is T, then a2 must be
assignable to the type []T. The gccgo frontend was incorrectly
requiring that a2 be assignable to the type of a1. This patch corrects
that. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 7a89c4b7c106 go/expressions.cc
--- a/go/expressions.cc Wed Feb 01 12:44:12 2012 -0800
+++ b/go/expressions.cc Wed Feb 01 13:27:30 2012 -0800
@@ -7657,7 +7657,10 @@
this->set_is_error();
return this;
}
- this->lower_varargs(gogo, function, inserter, slice_type, 2);
+ Type* element_type = slice_type->array_type()->element_type();
+ this->lower_varargs(gogo, function, inserter,
+ Type::make_array_type(element_type, NULL),
+ 2);
}
break;
@@ -8624,16 +8627,20 @@
break;
}
+ // The language says that the second argument must be
+ // assignable to a slice of the element type of the first
+ // argument. We already know the first argument is a slice
+ // type.
+ Array_type* at = args->front()->type()->array_type();
+ Type* arg2_type = Type::make_array_type(at->element_type(), NULL);
std::string reason;
- if (!Type::are_assignable(args->front()->type(), args->back()->type(),
- &reason))
+ if (!Type::are_assignable(arg2_type, args->back()->type(), &reason))
{
if (reason.empty())
- this->report_error(_("arguments 1 and 2 have different types"));
+ this->report_error(_("argument 2 has invalid type"));
else
{
- error_at(this->location(),
- "arguments 1 and 2 have different types (%s)",
+ error_at(this->location(), "argument 2 has invalid type (%s)",
reason.c_str());
this->set_is_error();
}
Re: [PATCH, go]: Do not panic in test/nilptr.go
Uros Bizjak writes: > Attached is the patch I have committed. Thanks for taking care of that. > (BTW: Do you have any idea on what to do with excessive memory usage > in chan/select2.go? ) At this point I don't. It's sort of peculiar. Sending an int on a channel should not use any memory. The test is careful to only measure the memory allocated for sending and receiving, and as far as I can see nothing else should be allocated during the test. You reported that the test was allocating 2098576 bytes. When I run it I see it allocating 1408 bytes on x86_64, 640 bytes on i386. 2098576 is much larger than either number. What is allocating that memory? In other words, there appears to be a real bug here. You can probably track it down by setting a breakpoint on runtime_mallocgc after the line runtime.MemStats.Alloc = 0 What is calling runtime_mallocgc? Ian
Re: [trans-mem, PATCH] do not dereference node if null in expand_call_tm (PR middle-end/52047)
On 02/01/2012 03:59 AM, Richard Guenther wrote:
The patch looks ok, but I'm not sure why you do not get a cgraph node
here - cgraph doesn't really care for builtins as far as I can see. Honza?
I cannot help on this...
Don't you maybe want to handle builtins in a special way here?
Indeed, I think my patch is wrong. __builtin_prefetch should have the
transaction_pure attribute. I don't know how usually it should be done
but what about adding a gcc_assert before to dereference node
(potentially NULL)?
How the attached patch looks like now?
(Tested on i686)
> At least those that are const/pure?
About const/pure, we cannot consider those functions as transaction_pure
because they can read global and shared variable.
BTW, I will post a PR (and probably a patch) about this.
Thanks for your comment!
Patrick.
PR middle-end/52047
* trans-mem.c (expand_call_tm): Add an assertion.
* tree-ssa-loop-prefetch.c (issue_prefetch_ref): Add transaction_pure
attribute to __builtin_prefetch.
(tree_ssa_prefetch_arrays): Likewise.
Index: tree-ssa-loop-prefetch.c
===
--- tree-ssa-loop-prefetch.c(revision 183736)
+++ tree-ssa-loop-prefetch.c(working copy)
@@ -1,5 +1,5 @@
/* Array prefetching.
- Copyright (C) 2005, 2007, 2008, 2009, 2010, 2011
+ Copyright (C) 2005, 2007, 2008, 2009, 2010, 2011, 2012
Free Software Foundation, Inc.
This file is part of GCC.
@@ -1096,6 +1096,8 @@ issue_prefetch_ref (struct mem_ref *ref, unsigned
for (ap = 0; ap < n_prefetches; ap++)
{
+ tree decl;
+
if (cst_and_fits_in_hwi (ref->group->step))
{
/* Determine the address to prefetch. */
@@ -1116,9 +1118,11 @@ issue_prefetch_ref (struct mem_ref *ref, unsigned
addr = force_gimple_operand_gsi (&bsi, unshare_expr (addr), true,
NULL, true, GSI_SAME_STMT);
}
+ decl = builtin_decl_explicit (BUILT_IN_PREFETCH);
+ if (flag_tm)
+ apply_tm_attr (decl, get_identifier ("transaction_pure"));
/* Create the prefetch instruction. */
- prefetch = gimple_build_call (builtin_decl_explicit (BUILT_IN_PREFETCH),
- 3, addr, write_p, local);
+ prefetch = gimple_build_call (decl, 3, addr, write_p, local);
gsi_insert_before (&bsi, prefetch, GSI_SAME_STMT);
}
}
@@ -1917,6 +1921,8 @@ tree_ssa_prefetch_arrays (void)
BUILT_IN_PREFETCH, BUILT_IN_NORMAL,
NULL, NULL_TREE);
DECL_IS_NOVOPS (decl) = true;
+ if (flag_tm)
+ apply_tm_attr (decl, get_identifier ("transaction_pure"));
set_builtin_decl (BUILT_IN_PREFETCH, decl, false);
}
Index: trans-mem.c
===
--- trans-mem.c (revision 183736)
+++ trans-mem.c (working copy)
@@ -1,5 +1,5 @@
/* Passes for transactional memory support.
- Copyright (C) 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
+ Copyright (C) 2008, 2009, 2010, 2011, 2012 Free Software Foundation, Inc.
This file is part of GCC.
@@ -2267,6 +2267,7 @@ expand_call_tm (struct tm_region *region,
}
node = cgraph_get_node (fn_decl);
+ gcc_assert (node);
if (node->local.tm_may_enter_irr)
transaction_subcode_ior (region, GTMA_MAY_ENTER_IRREVOCABLE);
Index: testsuite/gcc.dg/tm/pr52047.c
===
--- testsuite/gcc.dg/tm/pr52047.c (revision 0)
+++ testsuite/gcc.dg/tm/pr52047.c (revision 0)
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fgnu-tm -fprefetch-loop-arrays -w" } */
+
+int test2 (int x[])
+{
+ return x[12];
+}
+
+int test1 (void)
+{
+ int x[1000], i;
+ for (i = 0; i < 1000; i++)
+x[i] = i;
+ return test2 (x);
+}
+
+int
+main ()
+{
+ __transaction_atomic
+ {
+if (test1 ())
+ __transaction_cancel;
+ }
+ return 0;
+}
libgo patch committed: Make sure file is not closed early
This patch to libgo fixes the test for leaked file descriptors. In some
cases the file, expected to be open, could be collected by the garbage
collector and closed. This then caused the next call to open to return
that descriptor rather than the expected one, causing the test to fail.
This patch adds an explicit close, ensuring that the file can not be
collected. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
Index: libgo/go/os/exec/exec_test.go
===
--- libgo/go/os/exec/exec_test.go (revision 183650)
+++ libgo/go/os/exec/exec_test.go (working copy)
@@ -292,6 +292,7 @@ func TestHelperProcess(*testing.T) {
f.Close()
}
}
+ fd3.Close()
os.Stderr.Write(bs)
case "exit":
n, _ := strconv.Atoi(args[0])
Re: Out-of-order update of new_spill_reg_store[]
Thanks for looking at this.
"Ulrich Weigand" writes:
> Richard Sandiford wrote:
>> Either way, the idea is that new_spill_reg_store[R] is only valid
>> for reload registers R that reach the end of the reload sequence.
>> We really should check that H1 reaches the end before using
>> new_spill_reg_store[H1].
>
> I'm a bit confused why it is necessary to check that the register reaches
> the end of the reload sequence *both* when *setting* new_spill_reg_store,
> and again when *using* the contents of new_spill_reg_store ... Wouldn't
> the latter be redundant if we already guarantee the former?
The idea was to handle the case where we use the same register for
two reloads. One of them reaches the end but the other one doesn't.
(In the testcase, the one that reaches the end is from the second
copy in a secondary output reload, while the first is a normal
copy-out reload.)
We need to check when setting because we set new_spill_reg_store[]
in rld[] order, which isn't necessarily the same as the order in
which the reloads are actually emitted into the insn stream.
So the entry for the wrong reload can end up overwriting the
right one.
We also need to check when using new_spill_reg_store[] because we
consider recording inheritance information for both reloads. Only one
of them actually reaches the end, and new_spill_reg_store[] is only valid
for that one. We shouldn't record any inheritance information for the other.
>> [A] (but not [B]). I think this is for optional reloads that we
>> decided not to make, in cases where the source of the set needs
>> no reloads. E.g. the pre-reload instruction might be:
>>
>>(set (reg P1) (reg H1))
>>
>> and P1 has an optional output reload that we decided not to make.
>> Here we record that H1 holds P1 as a possible inheritance.
>> If inheritance causes the P1 <- H1 move to become unnecessary,
>> we can delete it as dead.
>>
>> There doesn't seem to be any kind of "reaches end" check, but I
>> suppose the hope is that instructions like this are going to be so
>> simple that there's no point. Although I'm not sure whether for:
>>
>> (parallel [(set (reg P1) (reg H1))
>> (clobber (scratch))])
>>
>> we'd ever consider using H1 for the scratch in cases where the
>> clobber isn't an earlyclobber.
>
> Well, there could still be an output reload on the instruction, I guess
> (pre/post modify of an address register in the SET_DEST ?), which might
> even involve secondary reloads ... and if H1 is dead in the insn, it
> could possibly be chosen as the reload reg for one of these.
Hopefully that particular case wouldn't be a problem because autoinc
reloads need a register that is free both before and after the instruction.
But I agree this code doesn't look particularly robust.
> In any case, it seems strange to use some random SET_SRC register for
> spill_reg_store purposes. I'd have expected this array to only track
> spill registers. In fact, the comment says:
> /* If this is an optional reload, try to find the source reg
> from an input reload. */
> So at least the comment seems to indicate that only case [B] was ever
> intended to be handled here, not case [A].
In that case though, I don't really see what the src_reg assignment:
if (set && SET_DEST (set) == rld[r].out)
{
int k;
src_reg = SET_SRC (set);
is doing, since it is only used if we can't find an input reload.
>> [B] I think this is similar to [A], but for cases where the source
>> is reloaded. E.g. the pre-reload instruction might be:
>>
>>(set (reg P1) (reg P2))
>>
>> where P1 has an optional reload that we decided not to make and
>> P2 is reloaded into H2. The final sequence would look like:
>>
>>(set (reg H2) (reg P2))
>>(set (reg P1) (reg H2))
>>
>> and the code would record P1 <- H2 for inheritance.
>>
>> There does seem to be a real danger here that H2 could be reused
>> for clobbers (except again for earlyclobbers), so it seemed best
>> to test reload_reg_rtx_reaches_end_p. However, this change was
>> by inspection, and isn't directly related to the new handling
>> of new_spill_reg_store[], since the inherited "reload" is
>> actually the reloaded instruction itself.
>>
>> If H2 doesn't reach the end, the patch falls back to [A].
>> This means that if the original source is a hard register
>> of the wrong class (instead of a pseudo as in the example above),
>> we can continue to record an inheritance for that.
>
> This has again the problem whether we even want/can handle case [A]
> correctly. And even if so, there's the additional problem that if
> there is an input reload, the SET_SRC is most likely going to be
> replaced by some reload register (note that emit_rel
Re: [PATCH] Fix PR 51910, -frepo/linker demangling interaction
On 02/01/2012 12:31 PM, Jason Merrill wrote: Why do you want the link map to be demangled? It seems more reliable to deal with mangled symbols; there's always c++filt if you want to check what the symbols demangle to. It's certainly more reliable for automated tools to deal with mangled symbols, but users (especially users who are not also compiler implementors!) have a very hard time translating mangled names into names that actually appear in their program source code. Additionally, demangling is the documented default behavior of ld and it's not exactly user-friendly for the linker to completely ignore both its usual default and explicit requests for demangled output when invoked via collect2. Using gcc to link your program instead of invoking ld directly is supposed to make things *easier* for users, not harder. -Sandra
Go patch committed: Don't crash on switch _ := v.(type)
This patch to the Go compiler avoids crashing on switch _ := v.(type).
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 6cc0b85ab55c go/parse.cc
--- a/go/parse.cc Wed Feb 01 11:15:32 2012 -0800
+++ b/go/parse.cc Wed Feb 01 12:38:57 2012 -0800
@@ -4311,9 +4311,16 @@
Named_object* switch_no = NULL;
if (!type_switch.name.empty())
{
- Variable* switch_var = new Variable(NULL, type_switch.expr, false, false,
- false, type_switch.location);
- switch_no = this->gogo_->add_variable(type_switch.name, switch_var);
+ if (Gogo::is_sink_name(type_switch.name))
+ error_at(type_switch.location,
+ "no new variables on left side of %<:=%>");
+ else
+ {
+ Variable* switch_var = new Variable(NULL, type_switch.expr, false,
+ false, false,
+ type_switch.location);
+ switch_no = this->gogo_->add_variable(type_switch.name, switch_var);
+ }
}
Type_switch_statement* statement =
Re: [google] Propagate profile information to RTL level during switch expansion
thanks. ok for google/gcc_46 branch.
David
On Wed, Feb 1, 2012 at 11:52 AM, Easwaran Raman wrote:
> On Tue, Jan 31, 2012 at 10:16 PM, Xinliang David Li
> wrote:
>> Ok for google branch with minor changes below.
>>
>> thanks,
>>
>> David
>>
+#define case_probability(x, y) ((y) ? ((x) * REG_BR_PROB_BASE / (y)) :
-1)
+
>>
>> Using upper case for macro?
> From http://gcc.gnu.org/codingconventions.html,
>
> "Macros names should be in ALL_CAPS when it's important to be aware
> that it's a macro (e.g. accessors and simple predicates), but in
> lowercase (e.g., size_int) where the macro is a wrapper for efficiency
> that should be considered as a function"
>
> In this case case_probability is a wrapper for efficiency and hence I
> decided to go with the lower case name.
>
>
+ count -= default_count;
+ default_count = 0;
>>
>> Why resetting it to 0?
>
> If there are no gaps, then the indirect jump can't jump to the default
> label. Later I set
> default_edge->count = default_count;
> and this value should be 0 if there are no gaps.
>
> I have addressed the rest of your comments.
>
> -Easwaran
>
>
>>
>>
+
+static void
+add_prob_note_to_last_insn(int probability)
+{
>>
>> Missing document.
Re: Adding html documentation for svn mobile branches
On 2/1/12 11:44 AM, Ahmad Sharif wrote: Diego, does this patch look OK for submission? Looks fine. Thanks. Diego.
Re: [google] Propagate profile information to RTL level during switch expansion
On Tue, Jan 31, 2012 at 10:16 PM, Xinliang David Li wrote:
> Ok for google branch with minor changes below.
>
> thanks,
>
> David
>
>>> +#define case_probability(x, y) ((y) ? ((x) * REG_BR_PROB_BASE / (y)) :
>>> -1)
>>> +
>
> Using upper case for macro?
From http://gcc.gnu.org/codingconventions.html,
"Macros names should be in ALL_CAPS when it's important to be aware
that it's a macro (e.g. accessors and simple predicates), but in
lowercase (e.g., size_int) where the macro is a wrapper for efficiency
that should be considered as a function"
In this case case_probability is a wrapper for efficiency and hence I
decided to go with the lower case name.
>>> + count -= default_count;
>>> + default_count = 0;
>
> Why resetting it to 0?
If there are no gaps, then the indirect jump can't jump to the default
label. Later I set
default_edge->count = default_count;
and this value should be 0 if there are no gaps.
I have addressed the rest of your comments.
-Easwaran
>
>
>>> +
>>> +static void
>>> +add_prob_note_to_last_insn(int probability)
>>> +{
>
> Missing document.
Re: [patch, fortran] Fix PR 51958, wrong-code regression with function elimination
Hi Steve, On Wed, Feb 01, 2012 at 12:47:28AM +0100, Thomas Koenig wrote: Hi Steve, + else_stmt->expr1 = NULL; + else_stmt->next = c_if1; + else_stmt->block = NULL; + else_stmt->next = c_if1; Is one of the else_stmt->next = c_if1; redundant? Definitely. I'll take it out when I commit the patch. Patch looks fine, then. OK to commit. Committed as rev. 183812, with one of the double lines taken out. Thanks for the review! Thomas
Re: [PATCH, go]: Do not panic in test/nilptr.go
On Tue, Jan 31, 2012 at 8:36 PM, Ian Lance Taylor wrote:
>> There is no need for a panic in test/nilptr.go if array doesn't get
>> allocated in first 256 meg of memory. The compiler has nothing to do
>> with this.
>
> This is true but this does not seem like the right patch.
> I think I would prefer to just change go-test.exp to mark this test as
> xfail on Alpha. A patch to do that is preapproved.
Attached is the patch I have committed.
2012-02-01 Uros Bizjak
* go.test/go-test.exp (go-gc-tests): xfail test/nilptr.go runtime
test on alpha*-*-*.
Tested on alphaev68-pc-linux-gnu, committed to mainline SVN.
(BTW: Do you have any idea on what to do with excessive memory usage
in chan/select2.go? )
Uros.
Index: go.test/go-test.exp
===
--- go.test/go-test.exp (revision 183805)
+++ go.test/go-test.exp (working copy)
@@ -305,6 +305,14 @@
}
}
+ # Handle certain tests in a target-dependant way.
+ if [istarget "alpha*-*-*"] {
+ if { [string match "*go.test/test/nilptr.go" $test] } {
+ go-execute-xfail $test
+ continue
+ }
+ }
+
if { [string match "*bug347*" $test] \
|| [string match "*bug348*" $test] } {
# These bugs rely on runtime.Caller which currently fails.
Re: [PATCH] Fix PR 51910, -frepo/linker demangling interaction
On 02/01/2012 01:51 PM, Sandra Loosemore wrote: I don't think this is even really a regression. The testcase works with 4.6 and not with pre-4.7; that makes it a regression. I haven't actually sat down to try to reproduce this, but backing out the previous patch would leave the -frepo behavior even more broken on Windows hosts than it is now; one of the bugs fixed by the previous patch was that on Windows collect2 *always* told ld to demangle names and there was no way for users to override this via a command-line option or setting COLLECT_NO_DEMANGLE. And, I think the -frepo bug was present on Linux hosts too if you explicitly configured your GCC build with --with-demangler-in-ld, which is what you need to do if you want ld to be able to produce demangled link maps at all. Yep. (BTW, the CodeSourcery IDE adds -Wl,-Map to the link line by default because it's easier to always generate a link map than to have to explain to users how to get one. Especially in the embedded space, it's something many of our users actually do look at.) Why do you want the link map to be demangled? It seems more reliable to deal with mangled symbols; there's always c++filt if you want to check what the symbols demangle to. Jason
libgo patch committed: Update to weekly.2012-01-27
I have committed a patch to libgo to update to the weekly.2012-01-27 release. In this release a bunch of less-used packages were moved to sub-repositories, which means that the number of files in libgo has actually gone down. As usual in this e-mail I have only appended the changes to gccgo-specific files, which in this case is really just the Makefile. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian diff -r 3176203b44ca libgo/MERGE --- a/libgo/MERGE Wed Feb 01 06:27:46 2012 -0800 +++ b/libgo/MERGE Wed Feb 01 11:06:06 2012 -0800 @@ -1,4 +1,4 @@ -9f2be4fbbf69 +1107a7d3cb07 The first line of this file holds the Mercurial revision number of the last merge done from the master library sources. diff -r 3176203b44ca libgo/Makefile.am --- a/libgo/Makefile.am Wed Feb 01 06:27:46 2012 -0800 +++ b/libgo/Makefile.am Wed Feb 01 11:06:06 2012 -0800 @@ -116,7 +116,6 @@ mime.gox \ net.gox \ os.gox \ - patch.gox \ path.gox \ reflect.gox \ regexp.gox \ @@ -128,8 +127,7 @@ syscall.gox \ testing.gox \ time.gox \ - unicode.gox \ - websocket.gox + unicode.gox toolexeclibgoarchivedir = $(toolexeclibgodir)/archive @@ -157,40 +155,22 @@ toolexeclibgocrypto_DATA = \ crypto/aes.gox \ - crypto/bcrypt.gox \ - crypto/blowfish.gox \ - crypto/cast5.gox \ crypto/cipher.gox \ crypto/des.gox \ crypto/dsa.gox \ crypto/ecdsa.gox \ crypto/elliptic.gox \ crypto/hmac.gox \ - crypto/md4.gox \ crypto/md5.gox \ - crypto/ocsp.gox \ - crypto/openpgp.gox \ crypto/rand.gox \ crypto/rc4.gox \ - crypto/ripemd160.gox \ crypto/rsa.gox \ crypto/sha1.gox \ crypto/sha256.gox \ crypto/sha512.gox \ crypto/subtle.gox \ crypto/tls.gox \ - crypto/twofish.gox \ - crypto/x509.gox \ - crypto/xtea.gox - -toolexeclibgocryptoopenpgpdir = $(toolexeclibgocryptodir)/openpgp - -toolexeclibgocryptoopenpgp_DATA = \ - crypto/openpgp/armor.gox \ - crypto/openpgp/elgamal.gox \ - crypto/openpgp/errors.gox \ - crypto/openpgp/packet.gox \ - crypto/openpgp/s2k.gox + crypto/x509.gox toolexeclibgocryptox509dir = $(toolexeclibgocryptodir)/x509 @@ -225,7 +205,6 @@ encoding/base64.gox \ encoding/binary.gox \ encoding/csv.gox \ - encoding/git85.gox \ encoding/gob.gox \ encoding/hex.gox \ encoding/json.gox \ @@ -243,11 +222,10 @@ toolexeclibgoexp_DATA = \ exp/ebnf.gox \ + exp/html.gox \ $(exp_inotify_gox) \ exp/norm.gox \ exp/proxy.gox \ - exp/spdy.gox \ - exp/ssh.gox \ exp/terminal.gox \ exp/types.gox \ exp/utf8string.gox @@ -317,7 +295,6 @@ toolexeclibgonetdir = $(toolexeclibgodir)/net toolexeclibgonet_DATA = \ - net/dict.gox \ net/http.gox \ net/mail.gox \ net/rpc.gox \ @@ -577,16 +554,8 @@ go/hash/hash.go go_html_files = \ - go/html/const.go \ - go/html/doc.go \ - go/html/doctype.go \ go/html/entity.go \ - go/html/escape.go \ - go/html/foreign.go \ - go/html/node.go \ - go/html/parse.go \ - go/html/render.go \ - go/html/token.go + go/html/escape.go go_image_files = \ go/image/format.go \ @@ -821,12 +790,6 @@ go/os/types.go \ signal_unix.go -go_patch_files = \ - go/patch/apply.go \ - go/patch/git.go \ - go/patch/patch.go \ - go/patch/textdiff.go - go_path_files = \ go/path/match.go \ go/path/path.go @@ -929,13 +892,6 @@ go/unicode/letter.go \ go/unicode/tables.go -go_websocket_files = \ - go/websocket/client.go \ - go/websocket/hixie.go \ - go/websocket/hybi.go \ - go/websocket/server.go \ - go/websocket/websocket.go - go_archive_tar_files = \ go/archive/tar/common.go \ @@ -959,8 +915,7 @@ go/compress/flate/huffman_code.go \ go/compress/flate/inflate.go \ go/compress/flate/reverse_bits.go \ - go/compress/flate/token.go \ - go/compress/flate/util.go + go/compress/flate/token.go go_compress_gzip_files = \ go/compress/gzip/gzip.go \ @@ -987,15 +942,6 @@ go/crypto/aes/block.go \ go/crypto/aes/cipher.go \ go/crypto/aes/const.go -go_crypto_bcrypt_files = \ - go/crypto/bcrypt/base64.go \ - go/crypto/bcrypt/bcrypt.go -go_crypto_blowfish_files = \ - go/crypto/blowfish/block.go \ - go/crypto/blowfish/const.go \ - go/crypto/blowfish/cipher.go -go_crypto_cast5_files = \ - go/crypto/cast5/cast5.go go_crypto_cipher_files = \ go/crypto/cipher/cbc.go \ go/crypto/cipher/cfb.go \ @@ -1017,28 +963,15 @@ go/crypto/elliptic/p224.go go_crypto_hmac_files = \ go/crypto/hmac/hmac.go -go_crypto_md4_files = \ - go/crypto/md4/md4.go \ - go/crypto/md4/md4block.go go_crypto_md5_files = \ go/crypto/md5/md5.go \ go/crypto/md5/md5block.go -go_crypto_ocsp_files = \ - go/crypto/ocsp/ocsp.go -go_crypto_openpgp_files = \ - go/crypto/openpgp/canonical_text.go \ - go/crypto/openpgp/keys.go \ - go/crypto/openpgp/read.go \ - go/crypto/openpgp/write.go go_crypto_rand_files = \ go/crypto/rand/rand.go \ go/crypto/rand/rand_unix.go \ go/crypto/rand/util.go go_crypto_rc4_files = \ go/crypto/rc4/rc4.go -go_crypto_ripemd160_files = \ - go/crypto/ripemd160/ripemd160.go \ - go/crypto/ripemd160/ripemd160block.
[pph] Make tracing more robust. (issue5616043)
This patch makes tracing more robust. It attempts to use type dumping
where possible, use the PPH merge name where possible, and otherwise
use "?". It protects protecting existing type dump machinery against
some unexpected nulls. It changes tree streaming to write decl
minimal fields first, so that they can be used while reading other
fields.
The patch adds some new tests for the upcoming type merging.
Tested on x64.
Index: gcc/testsuite/ChangeLog.pph
2012-02-01 Lawrence Crowl
* g++.dg/pph/c0struct.h: Rename to c0struct2.h.
* g++.dg/pph/c0struct1.h: New. Has no typedefs.
* g++.dg/pph/c1struct.cc: Rename to c1struct2.cc.
* g++.dg/pph/c1struct1.cc: New. Has no typedefs.
* g++.dg/pph/x0struct0.h: Rename to x0struct2.h.
* g++.dg/pph/x0struct1.h: New. Has no typedefs.
* g++.dg/pph/x1struct2.h: Rename to x1struct3.h.
* g++.dg/pph/x1struct1.h: Rename to x1struct2.h.
* g++.dg/pph/x1struct1.h: New. Has no typedefs.
* g++.dg/pph/x2struct2.cc: Rename to x2struct3.cc.
* g++.dg/pph/x2struct1.cc: Rename to x2struct2.cc.
* g++.dg/pph/x2struct1.cc: New. Has no typedefs.
Index: gcc/cp/ChangeLog.pph
2012-02-01 Lawrence Crowl
* pph-streamer.h (pph_trace_tree): Add name parameter. Adjust callers
to match.
* pph-core.c (pph_trace_tree): Add name parameter to override
pretty-printing the tree.
* error.c (dump_type): Protect against null TYPE_NAME.
(dump_aggr_type): Factor out test for template.
(is_template): New. Protect against null DECL_TEMPLATE_PARMS.
* pph-out.c (pph_out_merge_body_namespace_decl): Factor out assert for
mergable trees into separate cases. Merging of types is currently
unexpected and disabled.
* pph-in.c (pph_in_merge_key_namespace_decl): Remove redundant assert
for mergable trees.
(pph_in_merge_key_namespace_decl): Factor out assert for mergable trees
into separate cases. Merging of types is currently unexpected and
disabled.
Index: gcc/ChangeLog.pph
2012-02-01 Lawrence Crowl
* tree-streamer-out.c (streamer_write_tree_body): Write decl minimal
fields first, so that they can be used when reading other fields.
* tree-streamer-in.c (streamer_write_tree_body): Read decl minimal
fields first, so that they can be used when reading other fields.
Index: gcc/testsuite/g++.dg/pph/c0struct2.h
===
--- gcc/testsuite/g++.dg/pph/c0struct2.h(revision 183736)
+++ gcc/testsuite/g++.dg/pph/c0struct2.h(working copy)
@@ -1,5 +1,5 @@
-#ifndef C0STRUCT_H
-#define C0STRUCT_H
+#ifndef C0STRUCT2_H
+#define C0STRUCT2_H
typedef int type;
type gbl = 1;
struct B {
Index: gcc/testsuite/g++.dg/pph/x0struct1.h
===
--- gcc/testsuite/g++.dg/pph/x0struct1.h(revision 0)
+++ gcc/testsuite/g++.dg/pph/x0struct1.h(revision 0)
@@ -0,0 +1,5 @@
+#ifndef X0STRUCT1_H
+#define X0STRUCT1_H
+struct B {
+};
+#endif
Index: gcc/testsuite/g++.dg/pph/c0struct.h
===
--- gcc/testsuite/g++.dg/pph/c0struct.h (revision 183805)
+++ gcc/testsuite/g++.dg/pph/c0struct.h (working copy)
@@ -1,9 +0,0 @@
-#ifndef C0STRUCT_H
-#define C0STRUCT_H
-typedef int type;
-type gbl = 1;
-struct B {
-type fld;
-};
-typedef B thing;
-#endif
Index: gcc/testsuite/g++.dg/pph/x0struct2.h
===
--- gcc/testsuite/g++.dg/pph/x0struct2.h(revision 183736)
+++ gcc/testsuite/g++.dg/pph/x0struct2.h(working copy)
@@ -1,5 +1,5 @@
-#ifndef X0STRUCT0_H
-#define X0STRUCT0_H
+#ifndef X0STRUCT2_H
+#define X0STRUCT2_H
typedef int type;
struct B {
};
Index: gcc/testsuite/g++.dg/pph/c1struct1.cc
===
--- gcc/testsuite/g++.dg/pph/c1struct1.cc (revision 0)
+++ gcc/testsuite/g++.dg/pph/c1struct1.cc (revision 0)
@@ -0,0 +1,4 @@
+#include "c0struct1.h"
+
+B var1;
+B var2 = { 3 };
Index: gcc/testsuite/g++.dg/pph/x2struct1.cc
===
--- gcc/testsuite/g++.dg/pph/x2struct1.cc (revision 183805)
+++ gcc/testsuite/g++.dg/pph/x2struct1.cc (working copy)
@@ -1,10 +1,9 @@
#include "x1struct1.h"
-type D::method()
+int D::method()
{ static int x = 2;
return fld + mbr; }
-type D::mbr = 4;
-typedef D D2;
-D2 var1;
-D2 var2 = var1;
+int D::mbr = 4;
+D var1;
+D var2 = var1;
Index: gcc/testsuite/g++.dg/pph/c1struct.cc
===
--- gcc/testsuite/g++.dg/pph/c1struct.cc(revision 183805)
+++ gcc/testsuite/g++.dg/pph/c1struct.cc(working copy)
@@ -1,4 +0,0 @@
-#include "c0struct.h"
-
-thing var1;
-thing var2 = { 3 };
[PATCH] Support TImode in go types_for_mode langhook (PR target/52079)
Hi!
ARM backend uses some libcalls that return TImode, so we need
lang_hooks.types.type_for_mode (TImode, ) to return non-NULL. Other
FEs already handle it (except perhaps for Java), Go doesn't.
Fixed thusly, approved in the PR by Ian, committed to trunk.
2012-02-01 Jakub Jelinek
PR target/52079
* go-lang.c (go_langhook_type_for_mode): For TImode and 64-bit HWI
return build_nonstandard_integer_type result if possible.
--- gcc/go/go-lang.c.jj 2012-01-13 21:47:31.0 +0100
+++ gcc/go/go-lang.c2012-02-01 14:50:33.951279531 +0100
@@ -277,6 +277,7 @@ go_langhook_type_for_size (unsigned int
static tree
go_langhook_type_for_mode (enum machine_mode mode, int unsignedp)
{
+ tree type;
/* Go has no vector types. Build them here. FIXME: It does not
make sense for the middle-end to ask the frontend for a type
which the frontend does not support. However, at least for now
@@ -291,7 +292,22 @@ go_langhook_type_for_mode (enum machine_
return NULL_TREE;
}
- return go_type_for_mode (mode, unsignedp);
+ type = go_type_for_mode (mode, unsignedp);
+ if (type)
+return type;
+
+#if HOST_BITS_PER_WIDE_INT >= 64
+ /* The middle-end and some backends rely on TImode being supported
+ for 64-bit HWI. */
+ if (mode == TImode)
+{
+ type = build_nonstandard_integer_type (GET_MODE_BITSIZE (TImode),
+unsignedp);
+ if (type && TYPE_MODE (type) == TImode)
+ return type;
+}
+#endif
+ return NULL_TREE;
}
/* Record a builtin function. We just ignore builtin functions. */
Jakub
Re: [PATCH] Fix PR 51910, -frepo/linker demangling interaction
On 02/01/2012 06:56 AM, Jakub Jelinek wrote: Do users really want to demangle linker maps? I would never want that, e.g. because it is ambiguous and less compact. IMHO the best is just to back out the changes that introduced this regression. I don't think this is even really a regression. I haven't actually sat down to try to reproduce this, but backing out the previous patch would leave the -frepo behavior even more broken on Windows hosts than it is now; one of the bugs fixed by the previous patch was that on Windows collect2 *always* told ld to demangle names and there was no way for users to override this via a command-line option or setting COLLECT_NO_DEMANGLE. And, I think the -frepo bug was present on Linux hosts too if you explicitly configured your GCC build with --with-demangler-in-ld, which is what you need to do if you want ld to be able to produce demangled link maps at all. The patch I posted the other day does reconcile the problem when the user wants both a demangled link map and -frepo processing, although it does add the two extra link steps. Maybe we can figure out a way to bypass the extra steps so that they only happen when the user has specified -Wl,-Map and not --no-demangle? And/or make explicit -frepo on the link command line shortcut some of it? (BTW, the CodeSourcery IDE adds -Wl,-Map to the link line by default because it's easier to always generate a link map than to have to explain to users how to get one. Especially in the embedded space, it's something many of our users actually do look at.) -Sandra
Re: [google] Backport ThreadSanitizer instrumentation pass from google/main to google/gcc-4_6 (issue5610048)
On 2/1/12 3:16 AM, Dmitriy Vyukov wrote:
This is for google/gcc-4_6 branch.
Backport ThreadSanitizer (tsan) instrumentation pass from google/main.
Have you used the validator script to test this patch? Your patch
should not affect regular builds, but you want to make sure that the
tsan tests don't produce failures in any configuration.
+
+#include
+#include
These includes are not needed. They are handled by system.h (GCC defers
all/most system includes to these files).
+ /* Check if a user has defined it for testing. */
+ id = get_identifier (name);
+ var = varpool_node_for_asm (id);
+ if (var != NULL)
+{
+ decl = var->decl;
+ gcc_assert (TREE_CODE (decl) == VAR_DECL);
+ return decl;
+}
+
+ decl = build_decl (UNKNOWN_LOCATION, VAR_DECL, id, typ);
It would be slightly more useful to give this decl a known location. How
about passing it in from the caller? DECL_SOURCE_LOCATION
(current_function_decl) may work when you have no other location (like a
statement or another symbol).
At worst, you pass UNKNOWN_LOCATION when you don't even have that in the
caller.
+get_thread_ignore_decl (void)
+{
+ static tree decl;
+
+ if (decl == NULL)
+decl = build_var_decl (integer_type_node, TSAN_IGNORE);
+ return decl;
+}
+
+/* Returns a definition of a runtime functione with type TYP and name NAME. */
s/functione/function/
+ static tree decl;
+
+ if (decl != NULL)
+return decl;
+
+ typ = build_function_type_list (void_type_node, NULL_TREE);
+ decl = build_func_decl (typ, TSAN_INIT);
+ return decl;
+}
+
+/* Adds new ignore definition to the global list.
+ TYPE is the ignore type (see tsan_ignore_type).
The code uses TYPE and TYP. Please change to always use TYPE.
+}
+
+/* Checks as to whether identifier STR matches template TEMPL.
+ Templates can only contain '*', e.g. 'std*string*insert'.
+ Templates implicitly start and end with '*'
+ since they are matched against mangled names.
+ Returns non-zero if STR is matched against TEMPL. */
+
+static int
Use 'bool' instead of 'int'.
+ char buf [PATH_MAX];
+
+ if(getenv("GCCTSAN_PAUSE"))
+{
+ int res;
+ printf("ATTACH A DEBUGGER AND PRESS ENTER\n");
+ res = scanf("%s", buf);
+ (void)res;
+}
No debugging getenv(), please. Either use a flag or remove this code.
+}
+}
+ if (f == NULL)
+{
+ error ("failed to open ignore file '%s'\n", flag_tsan_ignore);
This should be a fatal_error, not error (error is for problems with the
input code, not the flags).
+ if (do_dec)
+{
+ size_val = -size_val;
+ size_valhi = -1;
+}
+ op_size = build_int_cst_wide (sizetype, size_val, size_valhi);
+ sstack_decl = get_shadow_stack_decl ();
+ op_expr = build2 (POINTER_PLUS_EXPR, ptr_type_node, sstack_decl, op_size);
fold_build2_loc() (likewise in other places). Get the location from
the sequence you are given.
+ addr_expr = force_gimple_operand (expr_ptr, gseq, true, NULL_TREE);
+ expr_type = TREE_TYPE (expr);
+ while (TREE_CODE (expr_type) == ARRAY_TYPE)
+expr_type = TREE_TYPE (expr_type);
+ expr_size = TYPE_SIZE (expr_type);
+ size = tree_to_double_int (expr_size);
+ gcc_assert (size.high == 0&& size.low != 0);
+ if (size.low> 128)
+size.low = 128;
Could you add a comment here? I'm not sure what this 128 means.
+/* Checks as to whether EXPR refers to constant var/field/param.
+ Don't bother to instrument them. */
+
+static int
+is_load_of_const (tree expr, int is_store)
+{
s/int/bool/
+static void
+handle_gimple (gimple_stmt_iterator gsi, VEC (mop_desc, heap) **mop_list)
+{
+ unsigned i;
+ struct mop_desc mop;
+ gimple stmt;
+ enum gimple_code gcode;
+ tree rhs;
+ tree lhs;
+
+ stmt = gsi_stmt (gsi);
+ gcode = gimple_code (stmt);
+ if (gcode>= LAST_AND_UNUSED_GIMPLE_CODE)
+return;
If GCODE is not a valid gimple code, I would assert here. It means that
something has gone wrong upstream.
Property changes on: gcc/tree-tsan.c
___
Added: svn:eol-style
+ LF
Please remove this attribute. There are other instances of this.
OK with those changes.
Diego.
Re: [wwwdocs] Add section on diagnostics conventions
Diego Novillo wrote: > > This is the first of a few patches to update GCC's documentation with > the proposed conventions in the GCC Development Conventions document > that Joseph and I published last year > (https://docs.google.com/a/google.com/document/pub?id=10LO8y0YhjlKHya_PKM3jEGrJu0rllv-Nc9qP5LXqH_I#h.qpg2rjcas9fw) > > > I am just starting to get back to these documents, so I will start with > the "easy" parts. Joseph, Gabriel, I'm sending this patch to you since > you folks maintain these areas. Other changes to the documentation may > need global reviewers. > > OK for wwwdocs? > > > Diego. > > > Index: codingconventions.html > === > RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v > retrieving revision 1.63 > diff -u -d -u -p -r1.63 codingconventions.html > --- codingconventions.html 12 Feb 2011 15:49:51 - 1.63 > +++ codingconventions.html 29 Jan 2012 21:51:56 - > @@ -157,6 +157,45 @@ regression-checkers distinguish a true r > to the test suite. > > > +Diagnostics Conventions > + > + > +Use of the input_location global, and of the > +diagnostic functions that implicitly use input_location, > +is deprecated; the preferred technique is to pass around locations > +ultimately derived from the location of some explicitly chosen source > +code token. > + > +Diagnostics using the GCC diagnostic functions should generally > +use the GCC-specific formats such as %qs or > +%< and %> for quoting and > +%m for errno numbers. A link to respective documentation would be greatly appreciated, i.e. a link to the internals section describing the %-codes for diagnostic or a link to the source file's comments. Yes, I know it's in the sources. But guess you searched for documentation and correct usage of %D. It will take you quite some time to find it in the sources... Johann
Re: PR middle-end/24306 revisited: va_arg and zero-sized objects
Hi Richard, [ Nick, you might remember mentioning this bug a few months back. I think I've finally got a proper fix, rather than the failed attempt I originally sent. ] Thanks for fixing this. I am going to copy your patch into our internal sources and mark it as a local fix on the assumption that it will be approved soon and a merge will make it official. Cheers Nick
[PATCH] Fix expansion of constants with -fsection-anchors (PR middle-end/52074)
Hi!
For EXPAND_NORMAL we shouldn't be returning (plus (reg) (const_int)),
that should be limited to EXPAND_SUM and higher modifiers.
But with -fsection-anchors we sometimes do.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
tested with cross to powerpc64-linux on the testcase. Ok for trunk?
2012-02-01 Jakub Jelinek
PR middle-end/52074
* expr.c (expand_expr_addr_expr_1): For CONSTANT_CLASS_P or CONST_DECL
if modifier < EXPAND_SUM call force_operand on the result.
* gcc.c-torture/compile/pr52074.c: New test.
--- gcc/expr.c.jj 2012-01-30 00:10:01.0 +0100
+++ gcc/expr.c 2012-02-01 13:00:03.468835769 +0100
@@ -7414,7 +7414,12 @@ expand_expr_addr_expr_1 (tree exp, rtx t
generating ADDR_EXPR of something that isn't an LVALUE. The only
exception here is STRING_CST. */
if (CONSTANT_CLASS_P (exp))
-return XEXP (expand_expr_constant (exp, 0, modifier), 0);
+{
+ result = XEXP (expand_expr_constant (exp, 0, modifier), 0);
+ if (modifier < EXPAND_SUM)
+ result = force_operand (result, target);
+ return result;
+}
/* Everything must be something allowed by is_gimple_addressable. */
switch (TREE_CODE (exp))
@@ -7433,7 +7438,11 @@ expand_expr_addr_expr_1 (tree exp, rtx t
case CONST_DECL:
/* Expand the initializer like constants above. */
- return XEXP (expand_expr_constant (DECL_INITIAL (exp), 0, modifier), 0);
+ result = XEXP (expand_expr_constant (DECL_INITIAL (exp),
+ 0, modifier), 0);
+ if (modifier < EXPAND_SUM)
+ result = force_operand (result, target);
+ return result;
case REALPART_EXPR:
/* The real part of the complex number is always first, therefore
--- gcc/testsuite/gcc.c-torture/compile/pr52074.c.jj2012-02-01
13:03:26.236788697 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr52074.c 2012-02-01
13:03:07.0 +0100
@@ -0,0 +1,10 @@
+/* PR middle-end/52074 */
+
+struct S { const char *d, *e; } __attribute__((packed));
+
+void
+foo (const char **p, struct S *q)
+{
+ *p = "abcdef";
+ q->d = "ghijk";
+}
Jakub
Re: Static branch prediction: compare IV to loop bound variable (issue 5504086)
ok.
thanks,
David
On Wed, Feb 1, 2012 at 7:33 AM, Dehao Chen wrote:
> There are still some minor bugs in the current implementation, which
> is fixed by the attached patch:
>
> passed bootstrap/regression tests for both google-4_6 and google-main branch.
>
> ok for google branch?
>
> Thanks,
> Dehao
>
> gcc/ChangeLog.google-4_6
> 2012-01-31 Dehao Chen
>
> * predict.c (predict_iv_comparison): Add new parameter, ensure that
> the loop_iv_base and compare_base are identical.
>
> Index: gcc/predict.c
> ===
> --- gcc/predict.c (revision 183783)
> +++ gcc/predict.c (working copy)
> @@ -1126,8 +1126,8 @@
> }
>
> /* Predict branch probability of BB when BB contains a branch that compares
> - an induction variable in LOOP to LOOP_BOUND_VAR. The loop exit is
> - compared using LOOP_BOUND_CODE, with step of LOOP_BOUND_STEP.
> + an induction variable with LOOP_IV_BASE_VAR in LOOP to LOOP_BOUND_VAR. The
> + loop exit is compared using LOOP_BOUND_CODE, with step of LOOP_BOUND_STEP.
>
> E.g.
> for (int i = 0; i < bound; i++) {
> @@ -1142,6 +1142,7 @@
> static void
> predict_iv_comparison (struct loop *loop, basic_block bb,
> tree loop_bound_var,
> + tree loop_iv_base_var,
> enum tree_code loop_bound_code,
> int loop_bound_step)
> {
> @@ -1184,7 +1185,8 @@
> return;
> }
>
> - if (!expr_coherent_p (loop_bound_var, compare_var))
> + if (!expr_coherent_p (loop_bound_var, compare_var)
> + || loop_iv_base_var != compare_base)
> return;
>
> /* If loop bound, base and compare bound are all constents, we can
> @@ -1213,13 +1215,17 @@
> compare_count ++;
> if (loop_bound_code == LE_EXPR || loop_bound_code == GE_EXPR)
> loop_count ++;
> + if (compare_count < 0)
> + compare_count = 0;
> + if (loop_count < 0)
> + loop_count = 0;
>
> if (loop_count == 0)
> probability = 0;
> else if (compare_count > loop_count)
> - probability = 1;
> + probability = REG_BR_PROB_BASE;
> else
> - probability = REG_BR_PROB_BASE * compare_count / loop_count;
> + probability = (double) REG_BR_PROB_BASE * compare_count / loop_count;
> predict_edge (then_edge, PRED_LOOP_IV_COMPARE, probability);
> return;
> }
> @@ -1405,7 +1411,7 @@
> predict_edge (e, PRED_LOOP_EXIT, probability);
> }
> if (loop_bound_var)
> - predict_iv_comparison (loop, bb, loop_bound_var,
> + predict_iv_comparison (loop, bb, loop_bound_var, loop_iv_base,
> loop_bound_code,
> loop_bound_step);
> }
>
> On Mon, Jan 30, 2012 at 5:25 PM, wrote:
>> Ok for google branches for now.
>>
>> thanks,
>>
>> David
>>
>>
>> http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c
>> File gcc/predict.c (right):
>>
>> http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode958
>> gcc/predict.c:958: find_qualified_ssa_name (tree t1, tree t2)
>> Better change the name into 'strips_small_constant'
>>
>> http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode991
>> gcc/predict.c:991: Return NULL if T does not satisfy IV_COMPARE
>> condition. */
>> Fix comment -- there is no IV_COMPARE used here.
>>
>> http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode995
>> gcc/predict.c:995: {
>> Better change the name into 'get_base_value (tree t)' because the method
>> basically strips the constant 'offset' away.
>>
>> http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode1102
>> gcc/predict.c:1102: a similar variable. */
>> Fix the comments. Returns true if T1 and T2 are value coherent.
>>
>> http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode1106
>> gcc/predict.c:1106: {
>> May be changing the name to
>>
>> expr_coherent_p (tree t1, tree t2)
>>
>> http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode1206
>> gcc/predict.c:1206: && (compare_code == LT_EXPR || compare_code ==
>> LE_EXPR))
>> Fix indentation.
>>
>> http://codereview.appspot.com/5504086/
[PATCH] Don't ICE in vectorizer when testing if a pattern stmt is used by another pattern stmt (PR tree-optimization/52073)
Hi!
vinfo_for_stmt can't be used on stmts outside of the current loop.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-02-01 Jakub Jelinek
PR tree-optimization/52073
* tree-vect-stmts.c (vect_mark_relevant): When checking uses of
a pattern stmt for pattern uses, ignore uses outside of the loop.
* gcc.c-torture/compile/pr52073.c: New test.
--- gcc/tree-vect-stmts.c.jj2012-01-22 16:02:10.0 +0100
+++ gcc/tree-vect-stmts.c 2012-02-01 10:33:58.847815421 +0100
@@ -150,6 +150,8 @@ vect_mark_relevant (VEC(gimple,heap) **w
use_operand_p use_p;
gimple use_stmt;
tree lhs;
+ loop_vec_info loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_info);
+ struct loop *loop = LOOP_VINFO_LOOP (loop_vinfo);
if (is_gimple_assign (stmt))
lhs = gimple_assign_lhs (stmt);
@@ -166,6 +168,9 @@ vect_mark_relevant (VEC(gimple,heap) **w
continue;
use_stmt = USE_STMT (use_p);
+ if (!flow_bb_inside_loop_p (loop, gimple_bb (use_stmt)))
+ continue;
+
if (vinfo_for_stmt (use_stmt)
&& STMT_VINFO_IN_PATTERN_P (vinfo_for_stmt (use_stmt)))
{
--- gcc/testsuite/gcc.c-torture/compile/pr52073.c.jj2012-02-01
10:39:13.041003562 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr52073.c 2012-02-01
10:38:51.0 +0100
@@ -0,0 +1,28 @@
+/* PR tree-optimization/52073 */
+
+int a, b, c, d, e, f;
+
+void
+foo (int x)
+{
+ e = 1;
+ for (;;)
+{
+ int g = c;
+ if (x)
+ {
+ if (e)
+ continue;
+ while (a)
+ --f;
+ }
+ else
+ for (b = 5; b; b--)
+ {
+ d = g;
+ g = 0 == d;
+ }
+ if (!g)
+ x = 0;
+}
+}
Jakub
Re: Out-of-order update of new_spill_reg_store[]
Richard Sandiford wrote: > Bernd Schmidt writes: > >> gcc/ > >>* reload1.c (reload_regs_reach_end_p): Replace with... > >>(reload_reg_rtx_reaches_end_p): ...this function. > >>(new_spill_reg_store): Update commentary. > >>(emit_input_reload_insns): Don't clear new_spill_reg_store here. > >>(emit_output_reload_insns): Check reload_reg_rtx_reaches_end_p > >>before setting new_spill_reg_store. > >>(emit_reload_insns): Use a separate loop to clear new_spill_reg_store. > >>Use reload_reg_rtx_reaches_end_p instead of reload_regs_reach_end_p. > >>Also use reload_reg_rtx_reaches_end_p when recording inheritance > >>information for non-spill reload registers. > > > > Just an update to say that based on our discussion I think the general > > approach is OK, but I'm still trying to figure out what exactly this > > piece of code is doing, and whether the changes to it make sense: Not sure whether Bernd was planning to get back to this, but just a couple of comments from my side ... > Either way, the idea is that new_spill_reg_store[R] is only valid > for reload registers R that reach the end of the reload sequence. > We really should check that H1 reaches the end before using > new_spill_reg_store[H1]. I'm a bit confused why it is necessary to check that the register reaches the end of the reload sequence *both* when *setting* new_spill_reg_store, and again when *using* the contents of new_spill_reg_store ... Wouldn't the latter be redundant if we already guarantee the former? > [A] (but not [B]). I think this is for optional reloads that we > decided not to make, in cases where the source of the set needs > no reloads. E.g. the pre-reload instruction might be: > >(set (reg P1) (reg H1)) > > and P1 has an optional output reload that we decided not to make. > Here we record that H1 holds P1 as a possible inheritance. > If inheritance causes the P1 <- H1 move to become unnecessary, > we can delete it as dead. > > There doesn't seem to be any kind of "reaches end" check, but I > suppose the hope is that instructions like this are going to be so > simple that there's no point. Although I'm not sure whether for: > > (parallel [(set (reg P1) (reg H1)) > (clobber (scratch))]) > > we'd ever consider using H1 for the scratch in cases where the > clobber isn't an earlyclobber. Well, there could still be an output reload on the instruction, I guess (pre/post modify of an address register in the SET_DEST ?), which might even involve secondary reloads ... and if H1 is dead in the insn, it could possibly be chosen as the reload reg for one of these. In any case, it seems strange to use some random SET_SRC register for spill_reg_store purposes. I'd have expected this array to only track spill registers. In fact, the comment says: /* If this is an optional reload, try to find the source reg from an input reload. */ So at least the comment seems to indicate that only case [B] was ever intended to be handled here, not case [A]. > [B] I think this is similar to [A], but for cases where the source > is reloaded. E.g. the pre-reload instruction might be: > >(set (reg P1) (reg P2)) > > where P1 has an optional reload that we decided not to make and > P2 is reloaded into H2. The final sequence would look like: > >(set (reg H2) (reg P2)) >(set (reg P1) (reg H2)) > > and the code would record P1 <- H2 for inheritance. > > There does seem to be a real danger here that H2 could be reused > for clobbers (except again for earlyclobbers), so it seemed best > to test reload_reg_rtx_reaches_end_p. However, this change was > by inspection, and isn't directly related to the new handling > of new_spill_reg_store[], since the inherited "reload" is > actually the reloaded instruction itself. > > If H2 doesn't reach the end, the patch falls back to [A]. > This means that if the original source is a hard register > of the wrong class (instead of a pseudo as in the example above), > we can continue to record an inheritance for that. This has again the problem whether we even want/can handle case [A] correctly. And even if so, there's the additional problem that if there is an input reload, the SET_SRC is most likely going to be replaced by some reload register (note that emit_reload_insns is called *before* subst_reloads), which makes it really unclear how valid it is to use the original value of SET_SRC before substitution ... Maybe the conservative fix would be to not handle case [A], and neither case [B] when the register does not reach the end. Not sure if this would show up as performance regression somewhere, but it seems unlikely to me. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@d
Re: Static branch prediction: compare IV to loop bound variable (issue 5504086)
There are still some minor bugs in the current implementation, which
is fixed by the attached patch:
passed bootstrap/regression tests for both google-4_6 and google-main branch.
ok for google branch?
Thanks,
Dehao
gcc/ChangeLog.google-4_6
2012-01-31 Dehao Chen
* predict.c (predict_iv_comparison): Add new parameter, ensure that
the loop_iv_base and compare_base are identical.
Index: gcc/predict.c
===
--- gcc/predict.c (revision 183783)
+++ gcc/predict.c (working copy)
@@ -1126,8 +1126,8 @@
}
/* Predict branch probability of BB when BB contains a branch that compares
- an induction variable in LOOP to LOOP_BOUND_VAR. The loop exit is
- compared using LOOP_BOUND_CODE, with step of LOOP_BOUND_STEP.
+ an induction variable with LOOP_IV_BASE_VAR in LOOP to LOOP_BOUND_VAR. The
+ loop exit is compared using LOOP_BOUND_CODE, with step of LOOP_BOUND_STEP.
E.g.
for (int i = 0; i < bound; i++) {
@@ -1142,6 +1142,7 @@
static void
predict_iv_comparison (struct loop *loop, basic_block bb,
tree loop_bound_var,
+ tree loop_iv_base_var,
enum tree_code loop_bound_code,
int loop_bound_step)
{
@@ -1184,7 +1185,8 @@
return;
}
- if (!expr_coherent_p (loop_bound_var, compare_var))
+ if (!expr_coherent_p (loop_bound_var, compare_var)
+ || loop_iv_base_var != compare_base)
return;
/* If loop bound, base and compare bound are all constents, we can
@@ -1213,13 +1215,17 @@
compare_count ++;
if (loop_bound_code == LE_EXPR || loop_bound_code == GE_EXPR)
loop_count ++;
+ if (compare_count < 0)
+ compare_count = 0;
+ if (loop_count < 0)
+ loop_count = 0;
if (loop_count == 0)
probability = 0;
else if (compare_count > loop_count)
- probability = 1;
+ probability = REG_BR_PROB_BASE;
else
- probability = REG_BR_PROB_BASE * compare_count / loop_count;
+ probability = (double) REG_BR_PROB_BASE * compare_count / loop_count;
predict_edge (then_edge, PRED_LOOP_IV_COMPARE, probability);
return;
}
@@ -1405,7 +1411,7 @@
predict_edge (e, PRED_LOOP_EXIT, probability);
}
if (loop_bound_var)
- predict_iv_comparison (loop, bb, loop_bound_var,
+ predict_iv_comparison (loop, bb, loop_bound_var, loop_iv_base,
loop_bound_code,
loop_bound_step);
}
On Mon, Jan 30, 2012 at 5:25 PM, wrote:
> Ok for google branches for now.
>
> thanks,
>
> David
>
>
> http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c
> File gcc/predict.c (right):
>
> http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode958
> gcc/predict.c:958: find_qualified_ssa_name (tree t1, tree t2)
> Better change the name into 'strips_small_constant'
>
> http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode991
> gcc/predict.c:991: Return NULL if T does not satisfy IV_COMPARE
> condition. */
> Fix comment -- there is no IV_COMPARE used here.
>
> http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode995
> gcc/predict.c:995: {
> Better change the name into 'get_base_value (tree t)' because the method
> basically strips the constant 'offset' away.
>
> http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode1102
> gcc/predict.c:1102: a similar variable. */
> Fix the comments. Returns true if T1 and T2 are value coherent.
>
> http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode1106
> gcc/predict.c:1106: {
> May be changing the name to
>
> expr_coherent_p (tree t1, tree t2)
>
> http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode1206
> gcc/predict.c:1206: && (compare_code == LT_EXPR || compare_code ==
> LE_EXPR))
> Fix indentation.
>
> http://codereview.appspot.com/5504086/
Re: [PATCH] Fix PR 51910, -frepo/linker demangling interaction
On 02/01/2012 08:56 AM, Jakub Jelinek wrote: Sure, but would they ever be provided by different CUs? If some CU says it can provide _ZN1SD1Ev, doesn't it either always say that it can provide _ZN1SD2Ev, or none of the CU is able to provide the latter (at least in valid C++ without ODR violations)? Yes. I meant if the linker says it wants S::~S(), you'd see that in CU25 the rpo file offers both of them and you'd mark both for compilation. That might result in emitting variants that aren't needed, but I suppose that isn't so bad. I'll give it a shot. Do users really want to demangle linker maps? I would never want that, e.g. because it is ambiguous and less compact. I'm surprised by that too, but apparently CodeSourcery clients do want that. Jason
Go patch committed: Accept general expression in case x := <-c
The Go language specification permits a general expression in
select {
case x := <-c:
}
which basically means that it can look like
case x := (<-c):
The gccgo parser was failing to handle that case. This patch fixes it.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 36a50b3d3a7d go/parse.cc
--- a/go/parse.cc Tue Jan 31 16:00:53 2012 -0800
+++ b/go/parse.cc Wed Feb 01 06:26:31 2012 -0800
@@ -4640,9 +4640,14 @@
if (token->is_op(OPERATOR_COLONEQ))
{
// case rv := <-c:
- if (!this->advance_token()->is_op(OPERATOR_CHANOP))
+ this->advance_token();
+ Expression* e = this->expression(PRECEDENCE_NORMAL, false, false,
+ NULL);
+ Receive_expression* re = e->receive_expression();
+ if (re == NULL)
{
- error_at(this->location(), "expected %<<-%>");
+ if (!e->is_error_expression())
+ error_at(this->location(), "expected receive expression");
return false;
}
if (recv_var == "_")
@@ -4653,8 +4658,7 @@
}
*is_send = false;
*varname = gogo->pack_hidden_name(recv_var, is_rv_exported);
- this->advance_token();
- *channel = this->expression(PRECEDENCE_NORMAL, false, true, NULL);
+ *channel = re->channel();
return true;
}
else if (token->is_op(OPERATOR_COMMA))
@@ -4671,9 +4675,15 @@
if (token->is_op(OPERATOR_COLONEQ))
{
// case rv, rc := <-c:
- if (!this->advance_token()->is_op(OPERATOR_CHANOP))
+ this->advance_token();
+ Expression* e = this->expression(PRECEDENCE_NORMAL, false,
+ false, NULL);
+ Receive_expression* re = e->receive_expression();
+ if (re == NULL)
{
- error_at(this->location(), "expected %<<-%>");
+ if (!e->is_error_expression())
+ error_at(this->location(),
+ "expected receive expression");
return false;
}
if (recv_var == "_" && recv_closed == "_")
@@ -4689,9 +4699,7 @@
if (recv_closed != "_")
*closedname = gogo->pack_hidden_name(recv_closed,
is_rc_exported);
- this->advance_token();
- *channel = this->expression(PRECEDENCE_NORMAL, false, true,
- NULL);
+ *channel = re->channel();
return true;
}
Re: Ping #1: [Patch,testsuite]: Fix testcase that bangs long and int against void*
Jakub Jelinek wrote: > On Wed, Feb 01, 2012 at 02:00:53PM +0100, Georg-Johann Lay wrote: >>> * gcc.dg/lto/20091013-1_1.c: xfail for avr. >>> * gcc.dg/lto/20091013-1_2.c: xfail for avr. > > If it is just because of the warnings, can't you > add > -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast > to dg-options? dg-additional-options triggers WARNING: lto.exp does not support dg-additional-options > Also, not sure how effective is dg-xfail-if in the secondary > source files, the *_0.c is where all the dg directives are for it. The FAILs return if dg-xfail-if is removed from 1.c/2.c and added to 0.c dg-xfail-if only works if added in each and every individual source that triggers a warning. Johann
Re: [PATCH] Fix PR 51910, -frepo/linker demangling interaction
On Mon, Jan 30, 2012 at 03:26:32PM -0500, Jason Merrill wrote: > On 01/30/2012 11:11 AM, Jakub Jelinek wrote: > >Can't tlink just take into account that sometimes different > >symbols mangle the same, and handle those as a group (i.e. if > >the linker output requests S::~S(), and *.rpo files contain > >several _ZN1SD[0-9]Ev symbols, mark or tweak them all)? > > Emitting one doesn't necessary imply emitting all of them. Perhaps Sure, but would they ever be provided by different CUs? If some CU says it can provide _ZN1SD1Ev, doesn't it either always say that it can provide _ZN1SD2Ev, or none of the CU is able to provide the latter (at least in valid C++ without ODR violations)? I meant if the linker says it wants S::~S(), you'd see that in CU25 the rpo file offers both of them and you'd mark both for compilation. > we could change the demangler to distinguish between the symbols, > but of course that wouldn't affect current linkers. > > What if we use linker demangling only if the user has specified > creating a linker map? Do users really want to demangle linker maps? I would never want that, e.g. because it is ambiguous and less compact. IMHO the best is just to back out the changes that introduced this regression. Jakub
Re: [arm] Improve longlong.h umul_ppmm, count_trailing_zeros
On 31/01/12 05:15, Richard Henderson wrote:
> I noticed this accidentally, while looking for something else.
> There are significant improvements in the DImode multiplication
> and division routines for armv4+.
>
> Despite how trivial this is, I assume this must wait for stage1.
> Ok?
>
>
> r~
>
>
> * longlong.h [arm] (umul_ppmm): Use umull.
> [arm] (count_trailing_zeros): Use __builtin_ctz.
armv3m also has the widening multiply operation (it's what the M stands
for).
Otherwise ok for stage1
R.
>
> diff --git a/libgcc/longlong.h b/libgcc/longlong.h
> index 30cc2e3..7204679 100644
> --- a/libgcc/longlong.h
> +++ b/libgcc/longlong.h
> @@ -220,9 +220,12 @@ UDItype __umulsidi3 (USItype, USItype);
>"rI" ((USItype) (bh)), \
>"r" ((USItype) (al)), \
>"rI" ((USItype) (bl)) __CLOBBER_CC)
> -#define umul_ppmm(xh, xl, a, b) \
> -{register USItype __t0, __t1, __t2; \
> - __asm__ ("%@ Inlined umul_ppmm\n" \
> +# if defined(__ARM_ARCH_2__) || defined(__ARM_ARCH_2A__) \
> + || defined(__ARM_ARCH_3__) || defined(__ARM_ARCH_3M__)
> +# define umul_ppmm(xh, xl, a, b)\
> + do {
> \
> +register USItype __t0, __t1, __t2;
> \
> +__asm__ ("%@ Inlined umul_ppmm\n"
> \
> "mov %2, %5, lsr #16\n" \
> "mov %0, %6, lsr #16\n" \
> "bic %3, %5, %2, lsl #16\n" \
> @@ -239,14 +242,26 @@ UDItype __umulsidi3 (USItype, USItype);
>"=r" ((USItype) (xl)), \
>"=&r" (__t0), "=&r" (__t1), "=r" (__t2)\
> : "r" ((USItype) (a)), \
> - "r" ((USItype) (b)) __CLOBBER_CC );}
> -#define UMUL_TIME 20
> -#define UDIV_TIME 100
> + "r" ((USItype) (b)) __CLOBBER_CC );\
> + } while (0)
> +# define UMUL_TIME 20
> +# else
> +# define umul_ppmm(xh, xl, a, b)\
> + do {
> \
> +/* Generate umull, under compiler control. */ \
> +register UDItype __t0 = (UDItype)(USItype)(a) * (USItype)(b);\
> +(xl) = (USItype)__t0;\
> +(xh) = (USItype)(__t0 >> 32);\
> + } while (0)
> +# define UMUL_TIME 3
> +# endif
> +# define UDIV_TIME 100
> #endif /* __arm__ */
>
> #if defined(__arm__)
> /* Let gcc decide how best to implement count_leading_zeros. */
> #define count_leading_zeros(COUNT,X) ((COUNT) = __builtin_clz (X))
> +#define count_trailing_zeros(COUNT,X) ((COUNT) = __builtin_ctz (X))
> #define COUNT_LEADING_ZEROS_0 32
> #endif
>
>
[PATCH][RFC] Fix PR48124
This fixes PR48124 where a bitfield store leaks into adjacent
decls if the decl we store to has bigger alignment than what
its type requires (thus there is another decl in that "padding").
What we need to do is limit what get_best_mode returns and we
can do so by specifying a mode on the MEM we pass down to
store_fixed_bit_field.
The fix for this particular issue could be made less agressive
by also checking bitpos + bitsize whether it can possibly overlap
the last mode-sized word of the decl.
I'm not sure what to do for non-constant DECL_SIZE (I suppose
the same issue can pop up for VLA stack variables with an
explicit alignment and adjacent vars). Should we unconditionally
use TYPE_ALIGN instead assuming that DECL_SIZE is a multiple
of that? That would of course pessimize things even more,
so maybe only fall back to that if DECL_SIZE is non-constant?
This simply seemed the least invasive fix, it won't fix things
for indirect references where the known alignment is bigger
than what we'd expect from the size. But then we'd have
to fall back to using TYPE_SIZE and probably MEM_ALIGN
(which is what we pass down to get_best_mode in the end).
We could also fixup the interface of get_best_mode to also
pass down an object size so it can properly adjust the mode
according to that. But as it already has a mode argument
the callers might be the better place(s) to fix, possibly
using a helper function (the caller in question could use
MEM_SIZE).
Thoughts?
Bootstraped on x86_64-unknown-linux-gnu, testing in progress.
Thanks,
Richard.
2012-02-01 Richard Guenther
PR middle-end/48124
* expr.c (expand_assignment): For bitfield stores to a decl
that does not have a size that is a multiple of its alignment
restrict the mode we use for the bitfield accesses to make
sure they do not cross the object boundary.
* gcc.dg/torture/pr48124-1.c: New testcase.
* gcc.dg/torture/pr48124-2.c: Likewise.
* gcc.dg/torture/pr48124-3.c: Likewise.
Index: gcc/expr.c
===
--- gcc/expr.c (revision 183791)
+++ gcc/expr.c (working copy)
@@ -4705,6 +4705,22 @@ expand_assignment (tree to, tree from, b
to_rtx = adjust_address (to_rtx, mode1, 0);
else if (GET_MODE (to_rtx) == VOIDmode)
to_rtx = adjust_address (to_rtx, BLKmode, 0);
+ /* If the alignment of tem is larger than its size and we
+are performing a bitfield access limit the mode we use
+for the access to make sure we do not access the decl
+beyond its end. See PR48124. */
+ else if (GET_MODE (to_rtx) == BLKmode
+ && mode1 == VOIDmode
+ && DECL_P (tem)
+ && TREE_CODE (DECL_SIZE (tem)) == INTEGER_CST
+ && (TREE_INT_CST_LOW (DECL_SIZE (tem))
+ & (DECL_ALIGN (tem) - 1)) != 0)
+ {
+ unsigned HOST_WIDE_INT mis;
+ mis = TREE_INT_CST_LOW (DECL_SIZE (tem)) & (DECL_ALIGN (tem) - 1);
+ mode1 = mode_for_size (mis & -mis, MODE_INT, 0);
+ to_rtx = adjust_address (to_rtx, mode1, 0);
+ }
}
if (offset != 0)
Index: gcc/testsuite/gcc.dg/torture/pr48124-1.c
===
--- gcc/testsuite/gcc.dg/torture/pr48124-1.c(revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr48124-1.c(revision 0)
@@ -0,0 +1,33 @@
+/* { dg-do run } */
+/* { dg-options "-fno-toplevel-reorder" } */
+
+extern void abort (void);
+
+struct S
+{
+ signed a : 26;
+ signed b : 16;
+ signed c : 10;
+ volatile signed d : 14;
+};
+
+static struct S e = { 0, 0, 0, 1 };
+static int f = 1;
+
+void __attribute__((noinline))
+foo (void)
+{
+ e.d = 0;
+ f = 2;
+}
+
+int
+main ()
+{
+ if (e.a || e.b || e.c || e.d != 1 || f != 1)
+abort ();
+ foo ();
+ if (e.a || e.b || e.c || e.d || f != 2)
+abort ();
+ return 0;
+}
Index: gcc/testsuite/gcc.dg/torture/pr48124-2.c
===
--- gcc/testsuite/gcc.dg/torture/pr48124-2.c(revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr48124-2.c(revision 0)
@@ -0,0 +1,27 @@
+/* { dg-do run } */
+
+extern void abort (void);
+
+static volatile struct S0 {
+short f3[9];
+unsigned f8 : 15;
+} s = {1};
+static unsigned short sh = 0x1234;
+
+struct S0 a, b;
+int vi = 0;
+
+void func_4()
+{
+ s.f8 |= 1;
+ sh = 15;
+ if (vi) a = b;
+}
+
+int main()
+{
+ func_4();
+ if (sh != 15)
+abort ();
+ return 0;
+}
Index: gcc/testsuite/gcc.dg/torture/pr48124-3.c
===
--- gcc/testsuite/gcc.dg/torture/pr48124-3.c(revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr48124-3.c(revision 0)
@@ -0,0 +1,32 @@
+/* { dg-do run } */
+
+extern void abort (void);
+struct S1
+{
+ int f0;
+ int:1;
+ int f3;
+ int:1;
+ int:0;
+ int
Re: Ping #1: [Patch,testsuite]: Fix testcase that bangs long and int against void*
On Wed, Feb 01, 2012 at 02:00:53PM +0100, Georg-Johann Lay wrote: > > * gcc.dg/lto/20091013-1_1.c: xfail for avr. > > * gcc.dg/lto/20091013-1_2.c: xfail for avr. If it is just because of the warnings, can't you add -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast to dg-options? Also, not sure how effective is dg-xfail-if in the secondary source files, the *_0.c is where all the dg directives are for it. Jakub
Ping #1: [Patch,testsuite]: Fix testcase that bangs long and int against void*
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01502.html
Georg-Johann Lay wrote:
> Jakub Jelinek wrote:
>> On Fri, Jan 13, 2012 at 07:40:59PM +0100, Georg-Johann Lay wrote:
>>> The ilp32 is the closes match:
>>>
>>> The source casts pointer to int, int to pointer, long to int, uses 32-bit
>>> initializers for int, assumes size_t is unsigned long any maybe others.
>> No. The source is just fine for any target where sizeof (long) == sizeof
>> (void *).
>> So both ilp32 and lp64.
>
> Now just factored out avr. There is no dg-requite to filter out long!=void*,
> or
> did I miss something?
>
> Ok to apply?
>
> Johann
>
> * gcc.dg/lto/20091013-1_1.c: xfail for avr.
> * gcc.dg/lto/20091013-1_2.c: xfail for avr.
>
>
>
> Index: gcc.dg/lto/20091013-1_1.c
> ===
> --- gcc.dg/lto/20091013-1_1.c (revision 183472)
> +++ gcc.dg/lto/20091013-1_1.c (working copy)
> @@ -1,3 +1,4 @@
> +/* { dg-xfail-if "cast to pointer of different size" { "avr-*-*" } { "*" } {
> "" } } */
> 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 183472)
> +++ gcc.dg/lto/20091013-1_2.c (working copy)
> @@ -1,3 +1,4 @@
> +/* { dg-xfail-if "cast to pointer of different size" { "avr-*-*" } { "*" } {
> "" } } */
> typedef struct HDC__ { int unused; } *HDC;
> typedef struct HFONT__ { int unused; } *HFONT;
>
>
[AVR,testsuite,trunk,4.6,committed]: Add test case for PR51374.
http://gcc.gnu.org/viewcvs?view=revision&revision=183796 http://gcc.gnu.org/viewcvs?view=revision&revision=183797 Johann
Re: [Patch, Fortran] PR 52024 - fix .mod issue with type-bound operator check
On 31.01.2012 23:41, Tobias Burnus wrote: Tobias Burnus wrote: Unfortunately, it turns out that the check does not handle inheritance well. At least I would expect that the attached test case is valid (and it compiles with NAG 5.1), but it is rejected with GCC 4.6 and 4.7. Actually, I withdraw that comment. OK without the FIXME then. Thanks Mikael
Re: [wwwdocs] Add section on diagnostics conventions
On Tue, Jan 31, 2012 at 7:50 PM, Diego Novillo wrote: > On Mon, Jan 30, 2012 at 15:21, Joseph S. Myers > wrote: >> On Sun, 29 Jan 2012, Diego Novillo wrote: >> >>> +internal_error is used for conditions that should not >>> +be triggered by any user input whether valid or invalid and including >>> +invalid asms and LTO binary data (sometimes, as an exception, there is >>> +a call to error before further information is printed and >>> +an ICE is triggered). >>> + >>> +Assertion failures should not be triggered by invalid input. >>> +inform is for informative notes accompanying errors and >>> +warnings. All diagnostics should be full sentences without English >>> +fragments substituted in them, to facilitate translation. >> >> The three sentences in this last list item are actually three independent >> and unrelated points. I think the first one about assertion failures >> should be moved up into the previous list item, while the remaining two >> sentences should each be a list item on its own. > > Thanks. Fixed with the patch below. > > > Index: codingconventions.html > === > RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v > retrieving revision 1.63 > diff -u -d -u -p -r1.63 codingconventions.html > --- codingconventions.html 12 Feb 2011 15:49:51 - 1.63 > +++ codingconventions.html 1 Feb 2012 01:47:55 - > @@ -157,6 +157,47 @@ regression-checkers distinguish a true r > to the test suite. > > > +Diagnostics Conventions > + > + > +Use of the input_location global, and of the > +diagnostic functions that implicitly use input_location, > +is deprecated; the preferred technique is to pass around locations > +ultimately derived from the location of some explicitly chosen source > +code token. Yes. > + > +Diagnostics using the GCC diagnostic functions should generally > +use the GCC-specific formats such as %qs or > +%< and %> for quoting and > +%m for errno numbers. Yes. > + > +Identifiers should generally be formatted with %E or > +%qE; use of identifier_to_locale is needed > +if the identifier text is used directly. Yes. > + > +Formats such as %wd should be used with types such as > +HOST_WIDE_INT (HOST_WIDE_INT_PRINT_DEC is a > +format for the host printf functions, not for the GCC > +diagnostic functions). OK. > + > +error is for defects in the user's code. Yes. sorry is for correct user input programs but unimplemented functionalities. warning is for advisory diagnostics; it may be used for diagnostics that have severity less than an error. inform is for adding additional explanatory information to a diagnostic. > + > +internal_error is used for conditions that should not > +be triggered by any user input whether valid or invalid and including > +invalid asms and LTO binary data (sometimes, as an exception, there is > +a call to error before further information is printed and > +an ICE is triggered). Assertion failures should not be triggered by > +invalid input. OK. > + > +inform is for informative notes accompanying errors > +and warnings. > + > +All diagnostics should be full sentences without English > +fragments substituted in them, to facilitate translation. > + > + > + > + > Miscellaneous Conventions > > Code should use gcc_assert(EXPR) to check invariants.
Re: [Patch, Fortran] PR52059 - Scalarizing fix - only add array ref to a variable
On 31.01.2012 23:22, Tobias Burnus wrote: Dear all, I have no idea about the scalarizer, but the attached patch fixes the test case and somehow adding an array ref to a scalar looks odd to me ... ?? The condition is about an array without array ref, isn't it? We can't access the "array" part of the "data" union without checking before that it is an array. To be clear the added if branch is there to catch temporaries created by the trans-stmt.c part of the regressing patch. Those had no array ref, but gfc_conv_variable (they are temporaries for variables) expects one. I thought I would have to revert the trans-expr.c part and try to detect temporaries somewhere else, but it seems your patch would do just fine. (Before the regression-causing patch, only the "else" branch existed.) Build and regtested on x86-64-linux. OK for the trunk? OK, and thanks for it. Mikael PS: gfc_conv_derived_to_class has only the "else" branch, but has to handle elementals too; I wouldn't be surprised if there was a problem with it.
[google] Backport ThreadSanitizer instrumentation pass from google/main to google/gcc-4_6 (issue5610048)
This is for google/gcc-4_6 branch.
Backport ThreadSanitizer (tsan) instrumentation pass from google/main.
* tree-tsan.c: New file.
* tree-tsan.h: New file.
* tree-pass.h: Add tsan pass.
* passes.c: Add tsan pass.
* toplev.c (compile_file): Call tsan_finish_file.
* common.opt: Add -ftsan, -ftsan-ignore flags.
* doc/invoke.texi: Document the new flags.
* Makefile.in: Add tree-tsan.c.
* testsuite/gcc.dg/tsan.h: New file.
* testsuite/gcc.dg/tsan-mop.c: New file.
* testsuite/gcc.dg/tsan-stack.c: New file.
* testsuite/gcc.dg/tsan-ignore.c: New file.
* testsuite/gcc.dg/tsan-ignore.h: New file.
* testsuite/gcc.dg/tsan-ignore.ignore: New file.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 183790)
+++ gcc/doc/invoke.texi (working copy)
@@ -306,6 +306,7 @@
-fdump-tree-ssa@r{[}-@var{n}@r{]} -fdump-tree-pre@r{[}-@var{n}@r{]} @gol
-fdump-tree-ccp@r{[}-@var{n}@r{]} -fdump-tree-dce@r{[}-@var{n}@r{]} @gol
-fdump-tree-gimple@r{[}-raw@r{]} -fdump-tree-mudflap@r{[}-@var{n}@r{]} @gol
+-fdump-tree-tsan@r{[}-@var{n}@r{]} @gol
-fdump-tree-dom@r{[}-@var{n}@r{]} @gol
-fdump-tree-dse@r{[}-@var{n}@r{]} @gol
-fdump-tree-phiprop@r{[}-@var{n}@r{]} @gol
@@ -376,8 +377,8 @@
-floop-parallelize-all -flto -flto-compression-level
-flto-partition=@var{alg} -flto-report -fmerge-all-constants @gol
-fmerge-constants -fmodulo-sched -fmodulo-sched-allow-regmoves @gol
--fmove-loop-invariants fmudflap -fmudflapir -fmudflapth -fno-branch-count-reg
@gol
--fno-default-inline @gol
+-fmove-loop-invariants -fmudflap -fmudflapir -fmudflapth -fno-branch-count-reg
@gol
+-ftsan -ftsan-ignore -fno-default-inline @gol
-fno-defer-pop -fno-function-cse -fno-guess-branch-probability @gol
-fno-inline -fno-math-errno -fno-peephole -fno-peephole2 @gol
-fno-sched-interblock -fno-sched-spec -fno-signed-zeros @gol
@@ -5812,6 +5813,11 @@
Dump each function after adding mudflap instrumentation. The file name is
made by appending @file{.mudflap} to the source file name.
+@item tsan
+@opindex fdump-tree-tsan
+Dump each function after adding ThreadSanitizer instrumentation. The file
name is
+made by appending @file{.tsan} to the source file name.
+
@item sra
@opindex fdump-tree-sra
Dump each function after performing scalar replacement of aggregates. The
@@ -6589,6 +6595,12 @@
some protection against outright memory corrupting writes, but allows
erroneously read data to propagate within a program.
+@item -ftsan -ftsan-ignore
+@opindex ftsan
+@opindex ftsan-ignore
+Add ThreadSanitizer instrumentation. Use @option{-ftsan-ignore} to specify
+an ignore file. Refer to http://go/tsan for details.
+
@item -fthread-jumps
@opindex fthread-jumps
Perform optimizations where we check to see if a jump branches to a
Index: gcc/tree-tsan.c
===
--- gcc/tree-tsan.c (revision 0)
+++ gcc/tree-tsan.c (revision 0)
@@ -0,0 +1,1123 @@
+/* ThreadSanitizer, a data race detector.
+ Copyright (C) 2011 Free Software Foundation, Inc.
+ Contributed by Dmitry Vyukov
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3. If not see
+
Re: [patch libjava]: Fix PR target/51500
On 02/01/2012 09:47 AM, Kai Tietz wrote: > I sent update-patch to ML for libffi to support closure-code for > thiscall. So the hunk in patch for java/lang/reflect/natVMProxy.cc > (ncode): Force SYSV closure for 32-bit Windows. Isn't necessary, if > the fix in libffi gets applied. > > Ok to commit patch without that hunk? The standard-thiscall call > feature is already in libffi. Yes. A goal is to minimize divergence from upstream libffi. Several of us have done a lot of work to make this happen. Andrew.
Ping^5: Out-of-order update of new_spill_reg_store[]
Ping for this reload inheritance patch: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00266.html or perhaps the original: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00663.html It fixes some wrong-code regressions in execute/scal-to-vec1.c on mips64-linux-gnu and mips64-elf. Richard
[Patch/ada] Fix thinko in Loop_Statement_to_gnu
Hi,
this patchlet fixes a thinko in Loop_Statement_to_gnu: size_type_node was used
instead of sizetype.
Privately approved by Eric.
Committed on trunk.
Tristan.
gcc/ada
2012-02-01 Tristan Gingold
* gcc-interface/trans.c (Loop_Statement_to_gnu): Use sizetype
instead of size_type_node.
Index: ada/gcc-interface/trans.c
===
--- ada/gcc-interface/trans.c (revision 183790)
+++ ada/gcc-interface/trans.c (working copy)
@@ -2380,15 +2380,14 @@
/* Otherwise, use the do-while form with the help of a special
induction variable in the unsigned version of the base type
-or the unsigned version of the size type, whichever is the
+or the unsigned version of sizetype, whichever is the
largest, in order to have wrap-around arithmetics for it. */
else
{
- if (TYPE_PRECISION (gnu_base_type)
- > TYPE_PRECISION (size_type_node))
+ if (TYPE_PRECISION (gnu_base_type) > TYPE_PRECISION (sizetype))
gnu_base_type = gnat_unsigned_type (gnu_base_type);
else
- gnu_base_type = size_type_node;
+ gnu_base_type = sizetype;
gnu_first = convert (gnu_base_type, gnu_first);
gnu_last = convert (gnu_base_type, gnu_last);
Re: [patch libjava]: Fix PR target/51500
2012/1/30 Andrew Haley : > On 01/29/2012 02:15 PM, Kai Tietz wrote: >> 2012-01-29 Kai Tietz >> >> PR target/51500 >> * interpret.cc (_Jv_init_cif): Handle thiscall >> convention for 32-bit Windows. >> * java/lang/reflect/natMethod.cc (_Jv_CallAnyMethodA): >> Likewise. >> * java/lang/reflect/natVMProxy.cc (ncode): Force SYSV >> closure for 32-bit Windows. >> (invoke_t): Add thiscall-attribute for 32-bit Windows. >> >> Patch tested for i686-w64-mingw32, i686-pc-cygwin, and >> x86_64-unknown-linux-gnu. Ok for apply? > > Is it upstream? OK if so. > > Andrew. Andrew, I sent update-patch to ML for libffi to support closure-code for thiscall. So the hunk in patch for java/lang/reflect/natVMProxy.cc (ncode): Force SYSV closure for 32-bit Windows. Isn't necessary, if the fix in libffi gets applied. Ok to commit patch without that hunk? The standard-thiscall call feature is already in libffi. Regards, Kai
Re: [PATCH] Clarify inline flag documentation
On Tue, 31 Jan 2012, Richard Guenther wrote:
>
> Thus, the following tries to clarify the documentation of
> -fno-inline and -finline-functions.
>
> Does that help?
lxo noticed a completely off comment in common.opt so I adjusted
documentation therein as well.
Committed.
Richard.
2012-02-01 Richard Guenther
* doc/invoke.texi (fno-inline): Clarify documentation.
(finline-small-functions): Likewise.
(finline-functions): Likewise.
* common.opt (finline): Adjust comment and documentation.
(finline-small-functions): Clarify documentation.
(finline-functions): Likewise.
(finline-functions-called-once): Likewise.
Index: gcc/doc/invoke.texi
===
*** gcc/doc/invoke.texi (revision 183751)
--- gcc/doc/invoke.texi (working copy)
*** Enabled at levels @option{-O2}, @option{
*** 6335,6350
@item -fno-inline
@opindex fno-inline
! Don't pay attention to the @code{inline} keyword. Normally this option
! is used to keep the compiler from expanding any functions inline.
! Note that if you are not optimizing, no functions can be expanded inline.
@item -finline-small-functions
@opindex finline-small-functions
Integrate functions into their callers when their body is smaller than
expected
function call code (so overall size of program gets smaller). The compiler
heuristically decides which functions are simple enough to be worth
integrating
! in this way.
Enabled at level @option{-O2}.
--- 6335,6354
@item -fno-inline
@opindex fno-inline
! Do not expand any functions inline apart from those marked with
! the @code{always_inline} attribute. This is the default when not
! optimizing.
!
! Single functions can be exempted from inlining by marking them
! with the @code{noinline} attribute.
@item -finline-small-functions
@opindex finline-small-functions
Integrate functions into their callers when their body is smaller than
expected
function call code (so overall size of program gets smaller). The compiler
heuristically decides which functions are simple enough to be worth
integrating
! in this way. This inlining applies to all functions, even those not declared
! inline.
Enabled at level @option{-O2}.
*** Enabled at level @option{-O2}.
*** 6359,6367
@item -finline-functions
@opindex finline-functions
! Integrate all simple functions into their callers. The compiler
! heuristically decides which functions are simple enough to be worth
! integrating in this way.
If all calls to a given function are integrated, and the function is
declared @code{static}, then the function is normally not output as
--- 6363,6371
@item -finline-functions
@opindex finline-functions
! Consider all functions for inlining, even if they are not declared inline.
! The compiler heuristically decides which functions are worth integrating
! in this way.
If all calls to a given function are integrated, and the function is
declared @code{static}, then the function is normally not output as
Index: gcc/common.opt
===
--- gcc/common.opt (revision 183791)
+++ gcc/common.opt (working copy)
@@ -1245,26 +1245,23 @@ findirect-inlining
Common Report Var(flag_indirect_inlining)
Perform indirect inlining
-; Nonzero means that functions declared `inline' will be treated
-; as `static'. Prevents generation of zillions of copies of unused
-; static inline functions; instead, `inlines' are written out
-; only when actually used. Used in conjunction with -g. Also
-; does the right thing with #pragma interface.
+; General flag to enable inlining. Specifying -fno-inline will disable
+; all inlining apart from always-inline functions.
finline
Common Report Var(flag_no_inline,0) Init(0)
-Pay attention to the \"inline\" keyword
+Enable inlining of function declared \"inline\", disabling disables all
inlining
finline-small-functions
Common Report Var(flag_inline_small_functions) Optimization
-Integrate simple functions into their callers when code size is known to not
growth
+Integrate functions into their callers when code size is known not to grow
finline-functions
Common Report Var(flag_inline_functions) Optimization
-Integrate simple functions into their callers
+Integrate functions not declared \"inline\" into their callers when profitable
finline-functions-called-once
Common Report Var(flag_inline_functions_called_once) Optimization
-Integrate functions called once into their callers
+Integrate functions only required by their single caller
finline-limit-
Common RejectNegative Joined Alias(finline-limit=)
Re: [trans-mem, PATCH] do not dereference node if null in expand_call_tm (PR middle-end/52047)
On Tue, Jan 31, 2012 at 6:11 PM, Patrick Marlier wrote: > In the PR testcase, a call to __builtin_prefetch is done. When this function > call comes into expand_call_tm, there is no cgraph_node associated for this > builtin and thus node->local fails. > > trans-mem.c (expand_call_tm): > ... > node = cgraph_get_node (fn_decl); > if (node->local.tm_may_enter_irr) > transaction_subcode_ior (region, GTMA_MAY_ENTER_IRREVOCABLE); > ... > > The attached patch adds a check for non-NULL node. I have added the testcase > but I don't know if it is relevant. > > Currently bootstrapping on i686-pc-linux-gnu. Tested on i686-pc-linux-gnu. > > OK? The patch looks ok, but I'm not sure why you do not get a cgraph node here - cgraph doesn't really care for builtins as far as I can see. Honza? Don't you maybe want to handle builtins in a special way here? At least those that are const/pure? Richard. > (I am almost sure I already proposed this modification few time ago but it > have been lost somewhere.) > -- > Patrick. > > 2012-01-31 Patrick Marlier > > PR middle-end/52047 > * trans-mem.c (expand_call_tm): Dereference node only if > non-NULL.
Re: Adjust omp-low test for alignment
On Sat, Nov 26, 2011 at 04:05:08PM -0800, Richard Henderson wrote: > The m68k-linux failure for the various omp atomic tests > is due to the fact that BIGGEST_ALIGNMENT is 16 bits on > that platform. I think it's pretty reasonable to assume > that if something is aligned to BIGGEST_ALIGNEMENT, then > it can be considered "aligned". > > Tested on x86_64-linux and m68k-linux cross. > > > r~ > * omp-low.c (expand_omp_atomic): Assume anything aligned to > BIGGEST_ALIGNMENT is aligned. That broke the atomic-2.c libgomp testcase on s390x. We have BIGGEST_ALIGNMENT of 64. A 128 bit long double does not need to be aligned better than 64 bit in memory. However, the 128bit compare and swap instruction we have requires the operands to be naturally aligned. In the testcase a compare and swap double instruction is used on a long double value which is only 8 byte aligned in memory. This seem to have caused problems on CRIS as well. The proposed solution was to force the alignment of the types using that aligned attribute. While this is a good idea anyway in order to get the proper hardware instructions, I think omp-low should be able to pick a fallback solution if necessary. Otherwise, we will silently insert bugs which are difficult to find. The atomic-2 testcase for example succeeds very often since the long double happens to be naturally aligned in a lot of cases. So to my understanding the change above is incorrect. Bye, -Andreas-
