Re: doubled words
Mike Stump wrote:
> On Apr 10, 2011, at 2:07 PM, Jim Meyering wrote:
>> $ git ls-files .|xargs perl -0777 -n -e 'while (/\b(it)\s+\1\b/gms)'
>> -e '{$n=($` =~ tr/\n/\n/ + 1); ($v=$&)=~s/\n/\\n/g; print
>> "$ARGV:$n:$v\n"}'|grep -v ChangeLog
>> gcc/config/cris/cris.opt:152:it it
>> gcc/gensupport.c:1066:it\n it
>
> These are obvious to me, so I checked in fixes for them.
Likewise for this:
gcc/ada/gnat_ugn.texi:12636:it\nit
>From 9eeae941081b3d6a0dd2c7db2b4752a3f04b1541 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 23 Apr 2011 08:47:04 +0200
Subject: [PATCH] * gnat_ugn.texi (Examples of gnatxref Usage): Fix typo: s/it
it/it is/
---
gcc/ada/ChangeLog |4
gcc/ada/gnat_ugn.texi |2 +-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/gcc/ada/ChangeLog b/gcc/ada/ChangeLog
index 70df175..f6e705e 100644
--- a/gcc/ada/ChangeLog
+++ b/gcc/ada/ChangeLog
@@ -1,3 +1,7 @@
+2011-04-23 Jim Meyering
+
+ * gnat_ugn.texi (Examples of gnatxref Usage): Fix typo: s/it it/it is/
+
2011-04-22 Eric Botcazou
* gcc-interface/decl.c (make_packable_type): Copy DECL_PARALLEL_TYPE
diff --git a/gcc/ada/gnat_ugn.texi b/gcc/ada/gnat_ugn.texi
index d843106..463662a 100644
--- a/gcc/ada/gnat_ugn.texi
+++ b/gcc/ada/gnat_ugn.texi
@@ -12634,7 +12634,7 @@ that is the entity @code{Main} is declared in main.ads,
line 2, column 9,
its body is in main.adb, line 1, column 14 and is not referenced any where.
The entity @code{Print} is declared in bar.ads, line 2, column 15 and it
-it referenced in main.adb, line 6 column 12 and line 7 column 12.
+is referenced in main.adb, line 6 column 12 and line 7 column 12.
@item gnatxref package1.adb package2.ads
@code{gnatxref} will generates cross-reference information for
--
1.7.5.rc3.291.g63e4e
[PATCH] Fix up fold_convert_loc for MODIFY_EXPR converted to void (PR c/48685)
Hi!
Roger changed fold_convert* back in 2007 to not actually convert to void
GIMPLE_MODIFY_STMT:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00279.html
as GIMPLE_MODIFY_STMT didn't have TREE_TYPE and thus converting it to
void has been difficult.
That == GIMPLE_MODIFY_STMT check has been changed into == MODIFY_EXPR
during real tuplification apparently, but MODIFY_EXPR has a type
and can be converted to void_type_node type just fine. Not doing so
breaks e.g. following testcase, because fold_convert_loc (void_type_node,
modify_expr);
doesn't actually yield a void_type_node tree and if it is inside of
NON_LVALUE_EXPR with void type, the NON_LVALUE_EXPR won't be removed.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk/4.6?
2011-04-23 Jakub Jelinek
PR c/48685
* fold-const.c (fold_convert_loc): Add NOP_EXPR when casting
to VOID_TYPE even around MODIFY_EXPR.
* gcc.dg/pr48685.c: New test.
--- gcc/fold-const.c.jj 2011-04-18 11:28:05.0 +0200
+++ gcc/fold-const.c2011-04-22 21:21:51.0 +0200
@@ -2029,8 +2029,6 @@ fold_convert_loc (location_t loc, tree t
case VOID_TYPE:
tem = fold_ignored_result (arg);
- if (TREE_CODE (tem) == MODIFY_EXPR)
- goto fold_convert_exit;
return fold_build1_loc (loc, NOP_EXPR, type, tem);
default:
--- gcc/testsuite/gcc.dg/pr48685.c.jj 2011-04-22 21:24:01.0 +0200
+++ gcc/testsuite/gcc.dg/pr48685.c 2011-04-22 21:24:14.0 +0200
@@ -0,0 +1,11 @@
+/* PR c/48685 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int
+main ()
+{
+ int v = 1;
+ (void) (1 == 2 ? (void) 0 : (v = 0));
+ return v;
+}
Jakub
Re: doubled words
On Apr 10, 2011, at 2:07 PM, Jim Meyering wrote:
> $ git ls-files .|xargs perl -0777 -n -e 'while (/\b(it)\s+\1\b/gms)' -e
> '{$n=($` =~ tr/\n/\n/ + 1); ($v=$&)=~s/\n/\\n/g; print "$ARGV:$n:$v\n"}'|grep
> -v ChangeLog
> gcc/config/cris/cris.opt:152:it it
> gcc/gensupport.c:1066:it\n it
These are obvious to me, so I checked in fixes for them.
fix typo
Applied an obvious fix to a typo.
* gensupport.c (read_md_rtx): Fix typo in comment.
2011-04-22 Mike Stump
* gensupport.c (read_md_rtx): Fix typo in comment.
Index: gensupport.c
===
--- gensupport.c(revision 172889)
+++ gensupport.c(working copy)
@@ -1304,7 +1304,7 @@ read_md_rtx (int *lineno, int *seqnr)
their C test is provably always false). If insn_elision is
false, our caller needs to see all the patterns. Note that the
elided patterns are never counted by the sequence numbering; it
- it is the caller's responsibility, when insn_elision is false, not
+ is the caller's responsibility, when insn_elision is false, not
to use elided pattern numbers for anything. */
switch (GET_CODE (desc))
{
Re: [Patch, Fortran] PR18918 - small coarray fixes
On 04/22/2011 02:48 PM, Tobias Burnus wrote: Another two simple coarray fixes: (a) when reading a module, the cotype was not set. The consequence was that one could not use associate alloctable coarray module variables (b) The coindexed check was overeager and also rejected "alloctate( x%b(3)[*])" claiming that the expression is coindexed. Attached patch has been built and regtested on x86-64-linux. Okay for the trunk? Tobias OK, thanks for patch. Jerry
fix typo in comment
* config/cris/cris.opt (moverride-best-lib-options): Fix typo in comment. 2011-04-22 Mike Stump * config/cris/cris.opt (moverride-best-lib-options): Fix typo in comment. Index: config/cris/cris.opt === --- config/cris/cris.opt(revision 172670) +++ config/cris/cris.opt(working copy) @@ -149,7 +149,7 @@ Target Report RejectNegative Use the most feature-enabling options allowed by other options ; FIXME: The following comment relates to gcc before cris.opt. -; Check it it's still valid: +; Check if it's still valid: ; We must call it "override-" since calling it "no-" will cause ; gcc.c to forget it, if there's a "later" -mbest-lib-options. ; Kludgy, but needed for some multilibbed files.
Re: [pph] Macro Validation Correction (issue4425041)
On Sat, 16 Apr 2011, Diego Novillo wrote: > On Thu, Apr 14, 2011 at 22:01, Lawrence Crowl wrote: > > +unsigned char too_many_directives_for_bitfield[ > > + N_DIRECTIVES <= (1 << CPP_HASHNODE_INDEX_BITS) > > + ? 1 : -1]; > > Heh, I'm not sure what to think of this trick. I think I like it, though. One up: better make it a declaration: prepend with "extern". brgds, H-P
Re: [libgo] Reduce fmt_test.TestScanInts recursion depth (PR go/48553)
Rainer Orth writes:
> As described in the PR, fmt FAILs on targets without split-stack support
> (anything but Linux, it seems) since the 32-bit TestScanInts tests
> overflows the default thread stack of 1 MB. To avoid this, I've reduced
> the recursion depth from 1000 to 800 which lets the test pass.
Thanks. Committed upstream and brought back to libgo as follows.
Committed to mainline.
Ian
diff -r 62a12171bf58 libgo/go/fmt/scan_test.go
--- a/libgo/go/fmt/scan_test.go Fri Apr 22 17:00:44 2011 -0700
+++ b/libgo/go/fmt/scan_test.go Fri Apr 22 17:06:09 2011 -0700
@@ -810,7 +810,9 @@
})
}
-const intCount = 1000
+// 800 is small enough to not overflow the stack when using gccgo on a
+// platform that does not support split stack.
+const intCount = 800
func testScanInts(t *testing.T, scan func(*RecursiveInt, *bytes.Buffer) os.Error) {
r := new(RecursiveInt)
go patch committed: Change gcc_unreachable to go_unreachable
This patch to the Go frontend changes uses of gcc_unreachable to be
go_unreachable instead. The patch is from Evan Shaw. Bootstrapped and
ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 969c61627ab5 go/README
--- a/go/README Fri Apr 22 11:33:30 2011 -0700
+++ b/go/README Fri Apr 22 17:00:20 2011 -0700
@@ -24,8 +24,6 @@
features such as %<%> for appropriate quoting.
+ Localization may be an issue.
-* Use of gcc_unreachable.
-
This compiler works, but the code is a work in progress. Notably, the
support for garbage collection is ineffective and needs a complete
rethinking. The frontend pays little attention to its memory usage
diff -r 969c61627ab5 go/dataflow.cc
--- a/go/dataflow.cc Fri Apr 22 11:33:30 2011 -0700
+++ b/go/dataflow.cc Fri Apr 22 17:00:20 2011 -0700
@@ -201,7 +201,7 @@
// We can't have two variables with the same name in the same
// location.
- gcc_unreachable();
+ go_unreachable();
}
// Class Dataflow.
diff -r 969c61627ab5 go/expressions.cc
--- a/go/expressions.cc Fri Apr 22 11:33:30 2011 -0700
+++ b/go/expressions.cc Fri Apr 22 17:00:20 2011 -0700
@@ -148,7 +148,7 @@
void
Expression::do_export(Export*) const
{
- gcc_unreachable();
+ go_unreachable();
}
// Warn that the value of the expression is not used.
@@ -665,7 +665,7 @@
return build_complex(type, real, imag);
}
else
-gcc_unreachable();
+go_unreachable();
}
// Return a tree for VAL in TYPE.
@@ -703,7 +703,7 @@
return build_complex(type, build_real(TREE_TYPE(type), r2), imag);
}
else
-gcc_unreachable();
+go_unreachable();
}
// Return a tree for REAL/IMAG in TYPE.
@@ -731,7 +731,7 @@
build_real(TREE_TYPE(type), r4));
}
else
-gcc_unreachable();
+go_unreachable();
}
// Return a tree which evaluates to true if VAL, of arbitrary integer
@@ -880,7 +880,7 @@
tree
do_get_tree(Translate_context*)
- { gcc_unreachable(); }
+ { go_unreachable(); }
private:
// The type which we are representing as an expression.
@@ -939,7 +939,7 @@
else if (this->variable_->is_result_variable())
return this->variable_->result_var_value()->type();
else
-gcc_unreachable();
+go_unreachable();
}
// Determine the type of a reference to a variable.
@@ -964,7 +964,7 @@
else if (this->variable_->is_result_variable())
this->variable_->result_var_value()->set_address_taken();
else
-gcc_unreachable();
+go_unreachable();
}
// Get the tree for a reference to a variable.
@@ -983,7 +983,7 @@
else if (this->variable_->is_result_variable())
is_in_heap = this->variable_->result_var_value()->is_in_heap();
else
-gcc_unreachable();
+go_unreachable();
if (is_in_heap)
{
ret = build_fold_indirect_ref_loc(this->location(), ret);
@@ -1160,7 +1160,7 @@
else if (this->function_->is_function_declaration())
return this->function_->func_declaration_value()->type();
else
-gcc_unreachable();
+go_unreachable();
}
// Get the tree for a function expression without evaluating the
@@ -1175,7 +1175,7 @@
else if (this->function_->is_function_declaration())
fntype = this->function_->func_declaration_value()->type();
else
-gcc_unreachable();
+go_unreachable();
// Builtin functions are handled specially by Call_expression. We
// can't take their address.
@@ -1198,7 +1198,7 @@
else if (no->is_function_declaration())
fndecl = no->func_declaration_value()->get_or_make_decl(gogo, no, id);
else
-gcc_unreachable();
+go_unreachable();
if (fndecl == error_mark_node)
return error_mark_node;
@@ -1321,7 +1321,7 @@
error_at(location, "unexpected reference to package");
return Expression::make_error(location);
default:
- gcc_unreachable();
+ go_unreachable();
}
}
@@ -1980,7 +1980,7 @@
max_exp = 1024;
break;
default:
- gcc_unreachable();
+ go_unreachable();
}
if (exp > max_exp)
{
@@ -2220,7 +2220,7 @@
max_exp = 1024;
break;
default:
- gcc_unreachable();
+ go_unreachable();
}
// A NaN or Infinity always fits in the range of the type.
@@ -2780,7 +2780,7 @@
else if (TREE_CODE(type_tree) == COMPLEX_TYPE)
ret = fold(convert_to_complex(type_tree, const_tree));
else
-gcc_unreachable();
+go_unreachable();
return ret;
}
@@ -2899,12 +2899,12 @@
protected:
Expression*
do_lower(Gogo*, Named_object*, int)
- { gcc_unreachable(); }
+ { go_unreachable(); }
// There should only ever be one of these.
Expression*
do_copy()
- { gcc_unreachable(); }
+ { go_unreachable(); }
};
// Make an iota expression. This is only called for one case: the
@@ -3368,7 +3368,7 @@
|| expr_type->is_unsafe_pointer_type())
ret = fold(convert_to_integer(type_tree, expr_tree));
else
- gcc_unreachable();
+ go_unreachable();
}
else if (type->float_type()
Re: Fix 20020425-1.c
On Apr 22, 2011, at 2:05 AM, Richard Guenther wrote: > I think we shouldn't worry about this kind of testsuite fails. There are only two testcases in this class. I'd rather have zero. How do you propose to fix them? For some reason, please just ignore the failures in the test suite doesn't seem right to me. The next best option would be to trim the recursion required by the testcase until it passes. Do you prefer that solution?
Re: [RFC] Context sensitive inline analysis
Hi, the patch also solves inliner compile time problems for mozilla: garbage collection: 15.88 ( 4%) usr 0.00 ( 0%) sys 15.89 ( 4%) wall 0 kB ( 0%) ggc callgraph optimization: 3.10 ( 1%) usr 0.00 ( 0%) sys 3.09 ( 1%) wall 15604 kB ( 1%) ggc varpool construction : 0.69 ( 0%) usr 0.01 ( 0%) sys 0.69 ( 0%) wall 51621 kB ( 3%) ggc ipa cp: 1.99 ( 1%) usr 0.08 ( 1%) sys 2.06 ( 1%) wall 123497 kB ( 8%) ggc ipa lto gimple in : 0.04 ( 0%) usr 0.02 ( 0%) sys 0.07 ( 0%) wall 0 kB ( 0%) ggc ipa lto gimple out: 11.70 ( 3%) usr 0.58 ( 8%) sys 12.29 ( 3%) wall 0 kB ( 0%) ggc ipa lto decl in : 318.89 (81%) usr 3.73 (53%) sys 323.19 (80%) wall 722318 kB (47%) ggc ipa lto decl out : 10.45 ( 3%) usr 0.23 ( 3%) sys 10.67 ( 3%) wall 0 kB ( 0%) ggc ipa lto decl init I/O : 0.13 ( 0%) usr 0.04 ( 1%) sys 0.16 ( 0%) wall 31 kB ( 0%) ggc ipa lto cgraph I/O: 1.88 ( 0%) usr 0.26 ( 4%) sys 2.14 ( 1%) wall 433578 kB (28%) ggc ipa lto decl merge: 20.51 ( 5%) usr 0.14 ( 2%) sys 20.65 ( 5%) wall 962 kB ( 0%) ggc ipa lto cgraph merge : 2.43 ( 1%) usr 0.00 ( 0%) sys 2.43 ( 1%) wall 14538 kB ( 1%) ggc whopr wpa : 0.59 ( 0%) usr 0.02 ( 0%) sys 0.62 ( 0%) wall 1 kB ( 0%) ggc whopr wpa I/O : 0.61 ( 0%) usr 1.75 (25%) sys 2.38 ( 1%) wall 0 kB ( 0%) ggc ipa reference : 1.02 ( 0%) usr 0.00 ( 0%) sys 1.02 ( 0%) wall 0 kB ( 0%) ggc ipa profile : 0.16 ( 0%) usr 0.00 ( 0%) sys 0.17 ( 0%) wall 0 kB ( 0%) ggc ipa pure const: 0.85 ( 0%) usr 0.02 ( 0%) sys 0.89 ( 0%) wall 0 kB ( 0%) ggc parser: 0.66 ( 0%) usr 0.00 ( 0%) sys 0.66 ( 0%) wall 10372 kB ( 1%) ggc inline heuristics : 1.22 ( 0%) usr 0.07 ( 1%) sys 1.28 ( 0%) wall 159368 kB (10%) ggc callgraph verifier: 0.11 ( 0%) usr 0.02 ( 0%) sys 0.12 ( 0%) wall 0 kB ( 0%) ggc varconst : 0.02 ( 0%) usr 0.03 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc unaccounted todo : 0.74 ( 0%) usr 0.00 ( 0%) sys 0.76 ( 0%) wall 0 kB ( 0%) ggc TOTAL : 394.08 7.10 401.76 1533113 kB one second for inlining seems acceptable. There is however growth from 20MB to 159MB of inliner GGC usage. It is because of moving inline_summary vector into GGC memory. ipa-cp summaries seems to have similar footprint as seen above. The problem is that cgraph_node->uid will be sparse after merging. I wonder if we want to solve this by adding new uids to the analyzed nodes that will be denser? Most of summaries are actually attached to the analyzed nodes only. Sadly libxul won't build again for apparently problem: [Leaving LTRANS /abuild/jh/tmp//ccIgav2O.args] [Leaving LTRANS libxul.so.ltrans.out] g++: warning: -pipe ignored because -save-temps specified Reading command line options: libxul.so.ltrans0.olto1: error: ELF section name out of range It seems that for some irrational reason we now decide to stream everything into single partition that is bad idea, but still our ELF infrastructure should not give up. the .o file seems wrong: jh@evans:/abuild/jh/build-mozilla-new11-lto-noelfhackO3/toolkit/library> objdump -h libxul.so.ltrans0.o BFD: libxul.so.ltrans0.o: invalid string offset 4088662 >= 348 for section `.shstrtab' BFD: libxul.so.ltrans0.o: invalid string offset 407 >= 348 for section `(null)' objdump: libxul.so.ltrans0.o: File format not recognized Honza
Re: (build) Patch to fix cp/cfns.gperf building issues
On Apr 22, 2011, at 8:12 AM, Nicola Pero wrote: > This patch fixes a building annoyance that I had when building on a new > machine (an x86_64 gnu/linux box). > > The building failed. It was down to two problems: > > * due to how I got a copy of the GCC source code on the machine, the timestamp > of each source file was the timestamp of when it was copied to the machine > (ie, > a random timestamp from the point of view of the building system). This > caused > the build system to decide that $(srcdir)/cp/cfns.h needed to be rebuilt from > $(srcdir)/cp/cfns.gperf (it didn't, obviously; the source code was trunk with > no changes). Additionally, contrib/gcc_update --touch can be used to to fix the time stamps until such time as someone changes the gperf rule to be under maintainer mode. So, only the dependency should go away under a maintainer rules, as in the below, not the entire rule. Ok? 2011-04-22 Mike Stump * Make-lang.in: Only run gperf in maintainer mode. Index: cp/Make-lang.in === --- cp/Make-lang.in (revision 172670) +++ cp/Make-lang.in (working copy) @@ -105,7 +105,10 @@ cc1plus$(exeext): $(CXX_OBJS) cc1plus-ch $(CXX_OBJS) cc1plus-checksum.o $(BACKEND) $(LIBS) $(BACKENDLIBS) # Special build rules. +ifneq ($(MAINT),) $(srcdir)/cp/cfns.h: $(srcdir)/cp/cfns.gperf +endif +$(srcdir)/cp/cfns.h: gperf -o -C -E -k '1-6,$$' -j1 -D -N 'libc_name_p' -L ANSI-C \ $(srcdir)/cp/cfns.gperf > $(srcdir)/cp/cfns.h
Re: [patch] Split Parse Timevar (issue4378056)
On 4/21/11, Jason Merrill wrote: > On 04/21/2011 07:17 PM, Lawrence Crowl wrote: @@ -1911,7 +1911,7 @@ ggc_collect (void) - timevar_push (TV_GC); + timevar_start (TV_GC); >>> >>> Why this change? GC time shouldn't be counted against whatever we >>> happen to be parsing when it happens. >> >> If not, then code that generates lots of garbage does not get >> charged for the cost to collect it. I thought it best to separate >> these issues. > > Sure, but the problem is that the collection doesn't always happen in > the same place that generated most of the garbage. True, but I expect it usually does. At any rate, I will revert the timevar to push/pop. +DEFTIMEVAR (TV_PHASE_C_WRAPUP_CHECK , "phase C wrapup& check") +DEFTIMEVAR (TV_PHASE_CP_DEFERRED , "phase C++ deferred") >>> >>> Why do these need to be different timevars? >> >> The are measuring different things. They are less different now >> than they were during earlier development. We can make them the >> same if you want. > > I think we could describe both as language-specific finalization. Okay. +DEFTIMEVAR (TV_PARSE_INMETH , "parser inl. meth. body") >>> >>> Is it really important to distinguish this from other functions? >> >> This distinction is here to help evaluate potential speedup due to >> lazy parsing. It might make some sense to separate functions and >> inline functions, which also wouldn't have to be parsed immediately. > > That makes sense. Inlines in the class aren't significantly different > from inlines outside the class, but inlines are significantly different > from non-inlines for our purposes. Do you have a quick hint for how to make that distinction? -DEFTIMEVAR (TV_TEMPLATE_INSTANTIATION, "template instantiation") +DEFTIMEVAR (TV_INSTANTIATE_TEMPLATE , "instantiate template") >>> >>> Why these changes? >> >> Just to shorten the names. > > I'd prefer to keep it in the noun form. Okay. This on in particular was making the output wide. -DEFTIMEVAR (TV_NAME_LOOKUP , "name lookup") -DEFTIMEVAR (TV_OVERLOAD , "overload resolution") +DEFTIMEVAR (TV_NAME_LOOKUP , "|name lookup") +DEFTIMEVAR (TV_RESOLVE_OVERLOAD , "|overload resolution") > > And here you significantly lengthened one. :) Ah, but it wasn't the long pole and hence more clarity didn't hurt. >> The "|" (also in TV_GC) indicates that these vars are collecting >> time concurrently with the other non-phase variables. It is intended >> to remind readers not to add those times into totals. > > Hmm, I guess that makes sense, but it should be documented. And perhaps > move these timevars to the beginning or end so that they don't look like > subsets of template instantiation. Okay. @@ -564,6 +564,8 @@ compile_file (void) + timevar_start (TV_PHASE_PARSING); >>> >>> Why does this happen before... >>> + timevar_push (TV_PARSE_GLOBAL); >>> >>> ...this? I would think the bits in there should be part of _SETUP. >> >> We could do that, though it would involve splitting the start/stop >> calls into different functions. That seemed hard to manage. >> As it stands, TV_PHASE_SETUP is entirely before compile_file() >> and TV_PHASE_FINALIZE is entirely after. Thoughts? > > The code is cleaner the way you have it, but not as correct, as there's > some initialization being charged to parsing. Would you prefer moving that initialization out or placing the start/stop into different routines? -- Lawrence Crowl
[wwwdocs] Update i960 link in readings.html
Corporate webmasters, I love them. Installed. Gerald Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.211 diff -u -r1.211 readings.html --- readings.html 7 Feb 2011 01:18:01 - 1.211 +++ readings.html 22 Apr 2011 22:28:25 - @@ -698,7 +698,7 @@ i960 Manufacturer: Intel - http://www.intel.com/design/i960/";>i960 home page + http://edc.intel.com/Platforms/Previous/Processors/i960/";>i960 home page GDB includes a simulator.
Re: (build) Patch to fix cp/cfns.gperf building issues
> We have a --enable-maintainer-mode configure option. Thanks - I had missed that option. It's an excellent suggestion - here is a new patch that uses it. :-) Ok to commit ? Thanks PS: Regarding how I detect --enable-maintainer-mode in this new patch, cp/Make-lang.in is used at it is, without going through configure, so I can't use @MAINT@ in it. I can't use MAINT either, because it's always empty. I added a FIXME as the intention in the code was probably different. I could actually fix MAINT to end up being exactly '#' when --disable-maintainer-mode is used, but why would we want that ? It would be a literal value, which you can't use to comment out bits of code in the same way as you can with @MAINT@. Of course, people may still try, and waste time trying to figure out why it doesn't work. It just doesn't make sense; you can't comment out make code by putting a variable with a value of '#' in front of something. If you ask me, I'd just remove the MAINT variable altogether - it's a bad idea and would/will confuse people. I added a new readable variable instead, ENABLE_MAINTAINER_RULES, which is 'true' or empty, so you can do ifeq ($(ENABLE_MAINTAINER_RULES), true) ... maintainer rules ... endif which is readable, expressive, simple and robust. Index: ChangeLog === --- ChangeLog (revision 172860) +++ ChangeLog (working copy) @@ -1,3 +1,7 @@ +2011-04-22 Nicola Pero + + * Makefile.in (ENABLE_MAINTAINER_RULES): New. + 2011-04-22 Jakub Jelinek PR c/48716 Index: cp/Make-lang.in === --- cp/Make-lang.in (revision 172860) +++ cp/Make-lang.in (working copy) @@ -104,10 +104,15 @@ cc1plus$(exeext): $(CXX_OBJS) cc1plus-checksum.o $ +$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ $(CXX_OBJS) cc1plus-checksum.o $(BACKEND) $(LIBS) $(BACKENDLIBS) -# Special build rules. +ifeq ($(ENABLE_MAINTAINER_RULES), true) +# Special build rule. This is a maintainer rule, that is only +# available when GCC is configured with --enable-maintainer-mode. In +# other cases, it is not available to avoid triggering rebuilds if a +# user has the source checked out with unusual timestamps. $(srcdir)/cp/cfns.h: $(srcdir)/cp/cfns.gperf gperf -o -C -E -k '1-6,$$' -j1 -D -N 'libc_name_p' -L ANSI-C \ - $(srcdir)/cp/cfns.gperf > $(srcdir)/cp/cfns.h + $(srcdir)/cp/cfns.gperf --output-file $(srcdir)/cp/cfns.h +endif #^L # Build hooks: Index: cp/ChangeLog === --- cp/ChangeLog(revision 172860) +++ cp/ChangeLog(working copy) @@ -1,3 +1,10 @@ +2011-04-23 Nicola Pero + + * Make-lang.in ($(srcdir)/cp/cfns.h): Enable the rule only in + maintainer mode. Use the --output-file option of gperf instead of + > to prevent creating an empty cp/cfns.h when gperf is not + available. + 2011-04-20 Jason Merrill * semantics.c (finish_compound_literal): Don't put an array Index: Makefile.in === --- Makefile.in (revision 172860) +++ Makefile.in (working copy) @@ -165,8 +165,19 @@ C_STRICT_WARN = @c_strict_warn@ NOCOMMON_FLAG = @nocommon_flag@ # This is set by --disable-maintainer-mode (default) to "#" +# FIXME: 'MAINT' will always be set to an empty string, no matter if +# --disable-maintainer-mode is used or not. This is because the +# following will expand to "MAINT := " in maintainer mode, and to +# "MAINT := #" in non-maintainer mode, but because '#' starts a comment, +# they mean exactly the same thing for make. MAINT := @MAINT@ +# The following provides the variable ENABLE_MAINTAINER_RULES that can +# be used in language Make-lang.in makefile fragments to enable +# maintainer rules. So, ENABLE_MAINTAINER_RULES is 'true' in +# maintainer mode, and '' otherwise. +@MAINT@ ENABLE_MAINTAINER_RULES = true + # These are set by --enable-checking=valgrind. RUN_GEN = @valgrind_command@ VALGRIND_DRIVER_DEFINES = @valgrind_path_defines@
Re: fix up hot/cold partitioning on ports that don't have long conditional branches
On Apr 22, 2011, at 3:28 AM, Eric Botcazou wrote:
>> This patch fixes up hot/cold partitioning on ports that don't have long
>> conditional branches. I'll note that the entire file has lots of other
>> jump optimizations that are suspect.
>
> Do you have a testcase for one of the ports in the tree?
Nope. Found via an out of tree port with tree-prof.exp=pr34999.c.
> Note that parameters of function must be documented in the head comment.
Fixed.
> The patch contains long lines.
Didn't know we had switched over to caring that much. Want me to fix all of
gcc/*.[ch]?
> The ChangeLog entry doesn't look correct (relax_delay_slots mentioned
> twice, no mention of the new parameter of follow_jumps, etc).
Fixed.
> How was the patch tested?
make check-gcc.
> Please generate patches with diff -p.
Done.
Ok?
2011-04-21 Mike Stump
* reorg.c (relax_delay_slots): Don't delete a jump that
crosses a section boundary. Pass insn to follow_jumps.
(follow_jumps): Add jump parameter. Don't replace a short
conditional jump with a long conditional jump when the port
doesn't have long conditional jumps.
(fill_slots_from_thread): Pass insn to follow_jumps.
Index: reorg.c
===
--- reorg.c (revision 1301)
+++ reorg.c (working copy)
@@ -2501,15 +2501,18 @@ fill_simple_delay_slots (int non_jumps_p
#endif
}
-/* Follow any unconditional jump at LABEL;
- return the ultimate label reached by any such chain of jumps.
- Return null if the chain ultimately leads to a return instruction.
- If LABEL is not followed by a jump, return LABEL.
- If the chain loops or we can't find end, return LABEL,
- since that tells caller to avoid changing the insn. */
+/* Follow any unconditional jump at LABEL; return the ultimate label
+ reached by any such chain of jumps. Return null if the chain
+ ultimately leads to a return instruction. If LABEL is not followed
+ by a jump, return LABEL. If the chain loops or we can't find end,
+ return LABEL, since that tells caller to avoid changing the insn.
+ If the chain of jumps ever crosses a section boundary, and the port
+ doesn't have long condition branches and the JUMP that we are
+ performing this analysis for was a conditional branch, return the
+ first such label before any such crossing. */
static rtx
-follow_jumps (rtx label)
+follow_jumps (rtx label, rtx jump)
{
rtx insn;
rtx next;
@@ -2529,6 +2532,16 @@ follow_jumps (rtx label)
{
rtx tem;
+ /* If a label crosses a section boundary and we're thinking
+about changing a conditional jump to be a conditional jump
+across that boundary, don't do it if the port doesn't have
+long conditional branches. We can however jump to the label
+just before we cross such a boundary. */
+ if (!HAS_LONG_COND_BRANCH
+ && find_reg_note (insn, REG_CROSSING_JUMP, NULL_RTX)
+ && any_condjump_p (jump))
+ return value;
+
/* If we have found a cycle, make the insn jump to itself. */
if (JUMP_LABEL (insn) == label)
return label;
@@ -2991,7 +3004,7 @@ fill_slots_from_thread (rtx insn, rtx co
&& redirect_with_delay_list_safe_p (insn,
JUMP_LABEL (new_thread),
delay_list))
- new_thread = follow_jumps (JUMP_LABEL (new_thread));
+ new_thread = follow_jumps (JUMP_LABEL (new_thread), new_thread);
if (new_thread == 0)
label = find_end_label ();
@@ -3342,12 +3355,14 @@ relax_delay_slots (rtx first)
&& (condjump_p (insn) || condjump_in_parallel_p (insn))
&& (target_label = JUMP_LABEL (insn)) != 0)
{
- target_label = skip_consecutive_labels (follow_jumps (target_label));
+ target_label = skip_consecutive_labels (follow_jumps (target_label,
+ insn));
if (target_label == 0)
target_label = find_end_label ();
if (target_label && next_active_insn (target_label) == next
- && ! condjump_in_parallel_p (insn))
+ && ! condjump_in_parallel_p (insn)
+ && find_reg_note (insn, REG_CROSSING_JUMP, NULL_RTX) == NULL_RTX)
{
delete_jump (insn);
continue;
@@ -3492,7 +3507,8 @@ relax_delay_slots (rtx first)
{
/* If this jump goes to another unconditional jump, thread it, but
don't convert a jump into a RETURN here. */
- trial = skip_consecutive_labels (follow_jumps (target_label));
+ trial = skip_consecutive_labels (follow_jumps (target_label,
+delay_insn));
if (trial == 0)
trial = find_end_label ();
[Patch, Fortran] PR18918 - small coarray fixes
Another two simple coarray fixes: (a) when reading a module, the cotype was not set. The consequence was that one could not use associate alloctable coarray module variables (b) The coindexed check was overeager and also rejected "alloctate( x%b(3)[*])" claiming that the expression is coindexed. Attached patch has been built and regtested on x86-64-linux. Okay for the trunk? Tobias coarray-fixes-v2.diff Description: application/unknown
Re: [PATCH, i386]: Fix PR target/48723
> Attached one-liner fixes PR target/48723, ICE in > ix86_expand_prologue() with -fstack-check + function returning struct, > on corei7-avx. The problem was, that we forgot to update accounting > info when ix86_adjust_stack_and_probe adjusted stack pointer (in this > particular case, m->fs.sp_offset was set by stack realignment code for > AVX 32byte stack alignment. Take a look at line 10165 of config/i386/i386.c. -- Eric Botcazou
Re: Improve DSE in the presence of calls
On Fri, Apr 22, 2011 at 1:26 PM, Jakub Jelinek wrote: > On Fri, Apr 22, 2011 at 01:19:17PM -0700, Easwaran Raman wrote: > > The ChangeLog entry has various issues: > >> 2011-04-22 Easwaran Raman >> >> PR rtl-optimization/44194 > > This should have tab before PR as well. > >> * dse.c (header files): Include tree-flow.h. > > This should be just > * dse.c: Include tree-flow.h. > >> (group_info): Add fields. > > (struct group_info): Add escaped_n and escaped_p fields. > > (it is always better to be be explicit on what you added). > >> (globals): Add a new variable kill_on_calls. > > (kill_on_calls): New variable. > >> (get_group_info): Initialize added fields. > > Instead of added fields again mention which fields were added. > >> 2011-04-22 Easwaran Raman >> >> PR rtl-optimization/44194 > > Again, tab before PR. > >> * gcc.dg/pr44194-1.c: New test. > > Jakub > Thanks for the comments. The fixed ChangeLog given below. -Easwaran 2011-04-22 Easwaran Raman PR rtl-optimization/44194 * dse.c: Include tree-flow.h. (group_info): Add escaped_n and escaped_p fields. (kill_on_calls): New variable. (get_group_info): Initialize gi->escaped_n and gi->escaped_p. (dse_step0): Initialize kill_on_calls. (can_escape): New function. (record_store): Pass EXPR corresponding to MEM to set_usage_bits. (dse_step2_nospill): Set kill_on_calls based on group->escaped_n and group->escaped_n. (scan_reads_nospill): Handle call instructions. (find_insn_before_first_wild_read): Remove the function. (dse_step3_scan): Remove call to find_insn_before_first_wild_read. (dse_step5_nospill): Do not kill everything on call. testsuite/ChangeLog: 2011-04-22 Easwaran Raman PR rtl-optimization/44194 * gcc.dg/pr44194-1.c: New test.
Re: [google] Port self-assign warning to google/main branch (issue4442075)
This patch ports the implementation of -Wself-assign warning from a GCC-4.4.3 based tree to google/main branch. The warning checks for self-assignment and self-initialization. It is intended for detecting accidental self-assignment due to typos, and therefore does not warn on a statement that is semantically a self-assignment after constant folding (e.g. x = x + 0). The patch also includes another new (sub-)flag -Wself-assign-non-pod that controls whether or not to warn about self-assignment of non-POD variables. Bootstrapped and passed gcc regression testsuite on x86_64. Le-chun On Fri, Apr 22, 2011 at 1:08 PM, Le-Chun Wu wrote: > > 2011-04-22 Le-Chun Wu > > gcc/c-family/ChangeLog: > * c-common.c (check_for_self_assign): New function. > * c-common.h: New function declaration. > * c.opt: New option. > > gcc/ChangeLog: > * c-parser.c (c_parser_declaration_or_fndef): Check for self-assign. > (c_parser_expr_no_commas): Check for self-assign. > * common.opt: New option. > * doc/invoke.texi: Documentation for new options. > * fold-const.c (operand_equal_p): Allow operands without typres to > compare. > (fold_unary_loc_1): Renamed from fold_unary_loc. > (fold_unary_loc): New wrapper function. > (fold_binary_loc_1): Renamed from fold_binary_loc. > (fold_binary_loc): New wrapper function. > (fold_ternary_loc_1): Renamed from fold_ternary_loc. > (fold_ternary_loc): New wrapper function. > * tree.h (struct tree_base): New flag for folded expr. > (enum operand_equal_flag): New flags. > > gcc/cp/ChangeLog: > * init.c (perform_member_init): Check for self-assign. > * parser.c (expr_is_pod): New function. > (cp_parser_assignment_expression): Check for self-assign. > (cp_parser_init_declarator): Check for self-assign. > > gcc/testsuite/ChangeLog: > * testsuite/g++.dg/plugin/selfassign.c (check_self_assign): Renamed > from warn_self_assign. > (execute_warn_self_assign): Call a function by its new name. > * testsuite/g++.dg/warn/Wself-assign-1.C: New test case. > * testsuite/g++.dg/warn/Wself-assign-2.C: Likewise. > * testsuite/g++.dg/warn/Wself-assign-3.C: Likewise. > * testsuite/g++.dg/warn/Wself-assign-4.C: Likewise. > * testsuite/g++.dg/warn/Wself-assign-5.C: Likewise. > * testsuite/g++.dg/warn/Wself-assign-non-pod-1.C: Likewise. > * testsuite/g++.dg/warn/Wself-assign-non-pod-2.C: Likewise. > * testsuite/g++.dg/warn/Wself-assign-non-pod-3.C: Likewise. > * testsuite/g++.dg/warn/Wself-assign-non-pod-4.C: Likewise. > * testsuite/g++.dg/warn/Wself-assign-non-pod-5.C: Likewise. > * testsuite/gcc.dg/plugin/selfassign.c (check_self_assign): Renamed > from warn_self_assign. > (execute_warn_self_assign): Call a function by its new name.: > * testsuite/gcc.dg/wself-assign-1.c: New test case. > * testsuite/gcc.dg/wself-assign-2.c: Likewise. > > > -- > This patch is available for review at http://codereview.appspot.com/4442075
Re: Improve DSE in the presence of calls
On Fri, Apr 22, 2011 at 01:19:17PM -0700, Easwaran Raman wrote: The ChangeLog entry has various issues: > 2011-04-22 Easwaran Raman > > PR rtl-optimization/44194 This should have tab before PR as well. > * dse.c (header files): Include tree-flow.h. This should be just * dse.c: Include tree-flow.h. > (group_info): Add fields. (struct group_info): Add escaped_n and escaped_p fields. (it is always better to be be explicit on what you added). > (globals): Add a new variable kill_on_calls. (kill_on_calls): New variable. > (get_group_info): Initialize added fields. Instead of added fields again mention which fields were added. > 2011-04-22 Easwaran Raman > > PR rtl-optimization/44194 Again, tab before PR. > * gcc.dg/pr44194-1.c: New test. Jakub
Improve DSE in the presence of calls
Hi,
This patch improves RTL DSE by not assuming that calls read all
memory locations. With this patch, calls are assumed to read any
non-frame memory and any stack variables that can potentially escape.
This patch partly addresses PR rtl-optimization/44194. Bootstraps and
no test regressions. OK for trunk?
Thanks,
Easwaran
2011-04-22 Easwaran Raman
PR rtl-optimization/44194
* dse.c (header files): Include tree-flow.h.
(group_info): Add fields.
(globals): Add a new variable kill_on_calls.
(get_group_info): Initialize added fields.
(dse_step0): Initialize kill_on_calls.
(can_escape): New function.
(record_store): Pass EXPR corresponding to MEM to
set_usage_bits.
(dse_step2_nospill): Set kill_on_calls based on
group->escaped_*.
(scan_reads_nospill): Handle call instructions.
(find_insn_before_first_wild_read): Remove the function.
(dse_step3_scan): Remove call to find_insn_before_first_wild_read.
(dse_step5_nospill): Do not kill everything on call.
testsuite/ChangeLog:
2011-04-22 Easwaran Raman
PR rtl-optimization/44194
* gcc.dg/pr44194-1.c: New test.
Index: gcc/testsuite/gcc.dg/pr44194-1.c
===
--- gcc/testsuite/gcc.dg/pr44194-1.c (revision 0)
+++ gcc/testsuite/gcc.dg/pr44194-1.c (revision 0)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-rtl-dse1" } */
+#include
+
+struct twoints { uint64_t a, b; } foo();
+void bar(uint64_t a, uint64_t b);
+
+void func() {
+ struct twoints s = foo();
+ bar(s.a, s.b);
+}
+/* { dg-final { scan-rtl-dump "global deletions = 2" "dse1" } } */
+/* { dg-final { cleanup-rtl-dump "dse1" } } */
Index: gcc/dse.c
===
--- gcc/dse.c (revision 172844)
+++ gcc/dse.c (working copy)
@@ -48,6 +48,7 @@ along with GCC; see the file COPYING3. If not see
#include "dbgcnt.h"
#include "target.h"
#include "params.h"
+#include "tree-flow.h"
/* This file contains three techniques for performing Dead Store
Elimination (dse).
@@ -501,6 +502,11 @@ struct group_info
deleted. */
bitmap store1_n, store1_p, store2_n, store2_p;
+ /* These bitmaps keep track of offsets in this group escape this function.
+ An offset escapes if it corresponds to a named variable whose
+ addressable flag is set. */
+ bitmap escaped_n, escaped_p;
+
/* The positions in this bitmap have the same assignments as the in,
out, gen and kill bitmaps. This bitmap is all zeros except for
the positions that are occupied by stores for this group. */
@@ -588,6 +594,9 @@ static int spill_deleted;
static bitmap all_blocks;
+/* Locations that are killed by calls in the global phase. */
+static bitmap kill_on_calls;
+
/* The number of bits used in the global bitmaps. */
static unsigned int current_position;
@@ -692,6 +701,8 @@ get_group_info (rtx base)
gi->store1_p = BITMAP_ALLOC (NULL);
gi->store2_n = BITMAP_ALLOC (NULL);
gi->store2_p = BITMAP_ALLOC (NULL);
+ gi->escaped_p = BITMAP_ALLOC (NULL);
+ gi->escaped_n = BITMAP_ALLOC (NULL);
gi->group_kill = BITMAP_ALLOC (NULL);
gi->process_globally = false;
gi->offset_map_size_n = 0;
@@ -714,6 +725,8 @@ get_group_info (rtx base)
gi->store1_p = BITMAP_ALLOC (NULL);
gi->store2_n = BITMAP_ALLOC (NULL);
gi->store2_p = BITMAP_ALLOC (NULL);
+ gi->escaped_p = BITMAP_ALLOC (NULL);
+ gi->escaped_n = BITMAP_ALLOC (NULL);
gi->group_kill = BITMAP_ALLOC (NULL);
gi->process_globally = false;
gi->frame_related =
@@ -739,6 +752,7 @@ dse_step0 (void)
spill_deleted = 0;
scratch = BITMAP_ALLOC (NULL);
+ kill_on_calls = BITMAP_ALLOC (NULL);
rtx_store_info_pool
= create_alloc_pool ("rtx_store_info_pool",
@@ -881,31 +895,48 @@ delete_dead_store_insn (insn_info_t insn_info)
insn_info->wild_read = false;
}
+/* Check if EXPR can possibly escape the current function scope. */
+static bool
+can_escape (tree expr)
+{
+ tree base;
+ if (!expr)
+return true;
+ base = get_base_address (expr);
+ if (DECL_P (base)
+ && !may_be_aliased (base))
+return false;
+ return true;
+}
/* Set the store* bitmaps offset_map_size* fields in GROUP based on
OFFSET and WIDTH. */
static void
-set_usage_bits (group_info_t group, HOST_WIDE_INT offset, HOST_WIDE_INT width)
+set_usage_bits (group_info_t group, HOST_WIDE_INT offset, HOST_WIDE_INT width,
+tree expr)
{
HOST_WIDE_INT i;
-
+ bool expr_escapes = can_escape (expr);
if (offset > -MAX_OFFSET && offset + width < MAX_OFFSET)
for (i=offset; istore1_n;
store2 = group->store2_n;
+ escaped = group->escaped_n;
ai = -i;
}
else
{
store1 = group->store1_p;
store2 = group->store2_p;
+ escaped = group->escaped_p;
ai = i;
}
@@ -924,6 +955,8 @@ static void
[google] Port self-assign warning to google/main branch (issue4442075)
2011-04-22 Le-Chun Wu
gcc/c-family/ChangeLog:
* c-common.c (check_for_self_assign): New function.
* c-common.h: New function declaration.
* c.opt: New option.
gcc/ChangeLog:
* c-parser.c (c_parser_declaration_or_fndef): Check for self-assign.
(c_parser_expr_no_commas): Check for self-assign.
* common.opt: New option.
* doc/invoke.texi: Documentation for new options.
* fold-const.c (operand_equal_p): Allow operands without typres to
compare.
(fold_unary_loc_1): Renamed from fold_unary_loc.
(fold_unary_loc): New wrapper function.
(fold_binary_loc_1): Renamed from fold_binary_loc.
(fold_binary_loc): New wrapper function.
(fold_ternary_loc_1): Renamed from fold_ternary_loc.
(fold_ternary_loc): New wrapper function.
* tree.h (struct tree_base): New flag for folded expr.
(enum operand_equal_flag): New flags.
gcc/cp/ChangeLog:
* init.c (perform_member_init): Check for self-assign.
* parser.c (expr_is_pod): New function.
(cp_parser_assignment_expression): Check for self-assign.
(cp_parser_init_declarator): Check for self-assign.
gcc/testsuite/ChangeLog:
* testsuite/g++.dg/plugin/selfassign.c (check_self_assign): Renamed
from warn_self_assign.
(execute_warn_self_assign): Call a function by its new name.
* testsuite/g++.dg/warn/Wself-assign-1.C: New test case.
* testsuite/g++.dg/warn/Wself-assign-2.C: Likewise.
* testsuite/g++.dg/warn/Wself-assign-3.C: Likewise.
* testsuite/g++.dg/warn/Wself-assign-4.C: Likewise.
* testsuite/g++.dg/warn/Wself-assign-5.C: Likewise.
* testsuite/g++.dg/warn/Wself-assign-non-pod-1.C: Likewise.
* testsuite/g++.dg/warn/Wself-assign-non-pod-2.C: Likewise.
* testsuite/g++.dg/warn/Wself-assign-non-pod-3.C: Likewise.
* testsuite/g++.dg/warn/Wself-assign-non-pod-4.C: Likewise.
* testsuite/g++.dg/warn/Wself-assign-non-pod-5.C: Likewise.
* testsuite/gcc.dg/plugin/selfassign.c (check_self_assign): Renamed
from warn_self_assign.
(execute_warn_self_assign): Call a function by its new name.:
* testsuite/gcc.dg/wself-assign-1.c: New test case.
* testsuite/gcc.dg/wself-assign-2.c: Likewise.
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index ca17bd2..13f13a8 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -10495,4 +10495,21 @@ keyword_is_decl_specifier (enum rid keyword)
}
}
+/* Check for and warn about self-assignment or self-initialization.
+ LHS and RHS are the tree nodes for the left-hand side and right-hand side
+ of the assignment or initialization we are checking.
+ LOCATION is the source location for RHS. */
+
+void
+check_for_self_assign (location_t location, tree lhs, tree rhs)
+{
+ /* Only emit a warning if RHS is not a folded expression so that we don't
+ warn on something like x = x / 1. */
+ if (!EXPR_FOLDED (rhs)
+ && operand_equal_p (lhs, rhs,
+ OEP_PURE_SAME | OEP_ALLOW_NULL | OEP_ALLOW_NO_TYPE))
+warning_at (location, OPT_Wself_assign, G_("%qE is assigned to itself"),
+lhs);
+}
+
#include "gt-c-family-c-common.h"
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 406def9..566aba7 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -957,6 +957,7 @@ extern VEC(tree,gc) *make_tree_vector (void);
extern void release_tree_vector (VEC(tree,gc) *);
extern VEC(tree,gc) *make_tree_vector_single (tree);
extern VEC(tree,gc) *make_tree_vector_copy (const VEC(tree,gc) *);
+extern void check_for_self_assign (location_t, tree, tree);
/* In c-gimplify.c */
extern void c_genericize (tree);
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index bb928fa..af38a1f 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -319,6 +319,10 @@ Wconversion-null
C++ ObjC++ Var(warn_conversion_null) Init(1) Warning
Warn for converting NULL from/to a non-pointer type
+Wself-assign-non-pod
+C++ ObjC++ Var(warn_self_assign_non_pod) Init(0) Warning
+Warn when a variable of a non-POD type is assigned to itself
+
Wsign-conversion
C ObjC C++ ObjC++ Var(warn_sign_conversion) Init(-1)
Warn for implicit type conversions between signed and unsigned integers
diff --git a/gcc/c-parser.c b/gcc/c-parser.c
index 25bd790..72a9f6c 100644
--- a/gcc/c-parser.c
+++ b/gcc/c-parser.c
@@ -1626,6 +1626,11 @@ c_parser_declaration_or_fndef (c_parser *parser, bool
fndef_ok,
maybe_warn_string_init (TREE_TYPE (d), init);
finish_decl (d, init_loc, init.value,
init.original_type, asm_name);
+ /* Check for and warn about self-initialization if
+ -Wself-assign is enabled. Don't warn if there is
+ already an error for the initializer. */
+
[patch, fortran] Make block names unique
Hello world,
the attached patch makes block names unique, so that
-fdump-fortran-original dumps are easier to read.
Regression-tested. OK for trunk?
Thomas
2011-04-22 Thomas Koenig
* decl.c (gfc_match_end): Check that the block name starts
with "block@".
* parse.c (gfc_build_block_ns): Make block names unique by
numbering them.
Index: decl.c
===
--- decl.c (Revision 172856)
+++ decl.c (Arbeitskopie)
@@ -5746,7 +5746,7 @@ gfc_match_end (gfc_statement *st)
{
case COMP_ASSOCIATE:
case COMP_BLOCK:
- if (!strcmp (block_name, "block@"))
+ if (!strncmp (block_name, "block@", strlen("block@")))
block_name = NULL;
break;
Index: parse.c
===
--- parse.c (Revision 172856)
+++ parse.c (Arbeitskopie)
@@ -3135,6 +3135,7 @@ gfc_namespace*
gfc_build_block_ns (gfc_namespace *parent_ns)
{
gfc_namespace* my_ns;
+ static int numblock = 1;
my_ns = gfc_get_namespace (parent_ns, 1);
my_ns->construct_entities = 1;
@@ -3149,8 +3150,10 @@ gfc_build_block_ns (gfc_namespace *parent_ns)
else
{
gfc_try t;
+ char buffer[20]; /* Enough to hold "block@2147483648\n". */
- gfc_get_symbol ("block@", my_ns, &my_ns->proc_name);
+ snprintf(buffer, sizeof(buffer), "block@%d", numblock++);
+ gfc_get_symbol (buffer, my_ns, &my_ns->proc_name);
t = gfc_add_flavor (&my_ns->proc_name->attr, FL_LABEL,
my_ns->proc_name->name, NULL);
gcc_assert (t == SUCCESS);
Re: libstdc++.exp patch
Attached patch applied.
2011-04-21 François Dumont
* testsuite/lib/libstdc++.exp (check_v3_target_time): Discard
unused compilation result thanks to /dev/null.
* testsuite/lib/libstdc++.exp (check_v3_target_debug_mode
check_v3_target_profile_mode check_v3_target_normal_mode
check_v3_target_cstdint check_v3_target_cmath
check_v3_target_atomic_builtins check_v3_target_gthreads
check_v3_target_nanosleep check_v3_target_sched_yield
check_v3_target_string_conversions check_v3_target_swprintf
check_v3_target_binary_io): Use simple preprocessing rather than
compilation. Discard unused preprocessing result thanks to
/dev/null.
I kept check_v3_target_time execution target for the moment, I check
that it is used within tests. Do not hesitate to signal an issue Ralf.
Regards
On 04/22/2011 05:06 PM, Paolo Carlini wrote:
Hi,
Here is the patch I submitted some months ago before 4.6.0 release.
My only concern regarding this patch is on the portability of
/dev/null.
I would say it's Ok: in acinclude.m4 we have quite a few of /dev/null
and nobody complained so far. I'm adding Ralf in CC, I trust his
opinion about portability issues (in particular ;)
I also wonder if check_v3_target_time could not simply use the object
or even assembly target rather than executable, what do you think ?
Can you figure out when / why it has been added? Because that function
is C89 and should be unconditionally available. If we have the test,
likely it's because of some target I'm not familiar with, which can
well declare time it in and then end up not providing it in
the library, thus the failure happens at *link* time... (would not be
the fist time we have to live with this kind of annoying situation)
Paolo.
Index: testsuite/lib/libstdc++.exp
===
--- testsuite/lib/libstdc++.exp (revision 172870)
+++ testsuite/lib/libstdc++.exp (working copy)
@@ -824,7 +824,6 @@
# Set up and compile a C++ test program that tries to use
# the time function
set src time[pid].cc
- set exe time[pid].x
set f [open $src "w"]
puts $f "#include "
@@ -835,13 +834,12 @@
puts $f "}"
close $f
- set lines [v3_target_compile $src $exe executable ""]
+ set lines [v3_target_compile $src /dev/null executable ""]
file delete $src
if [string match "" $lines] {
# No error message, compilation succeeded.
verbose "check_v3_target_time: compilation succeeded" 2
- remote_file build delete $exe
set et_time_saved 1
} else {
verbose "check_v3_target_time: compilation failed" 2
@@ -927,25 +925,21 @@
} else {
set et_debug_mode 0
- # Set up and compile a C++ test program that depends
+ # Set up and preprocess a C++ test program that depends
# on debug mode activated.
set src debug_mode[pid].cc
- set exe debug_mode[pid].exe
set f [open $src "w"]
puts $f "#ifndef _GLIBCXX_DEBUG"
puts $f "# error No debug mode"
puts $f "#endif"
- puts $f "int main()"
- puts $f "{ return 0; }"
close $f
- set lines [v3_target_compile $src $exe executable ""]
+ set lines [v3_target_compile $src /dev/null preprocess ""]
file delete $src
if [string match "" $lines] {
- # No error message, compilation succeeded.
- remote_file build delete $exe
+ # No error message, preprocessing succeeded.
set et_debug_mode 1
}
}
@@ -977,25 +971,21 @@
} else {
set et_profile_mode 0
- # Set up and compile a C++ test program that depends
+ # Set up and preprocess a C++ test program that depends
# on profile mode activated.
set src profile_mode[pid].cc
- set exe profile_mode[pid].exe
set f [open $src "w"]
puts $f "#ifndef _GLIBCXX_PROFILE"
puts $f "# error No profile mode"
puts $f "#endif"
- puts $f "int main()"
- puts $f "{ return 0; }"
close $f
- set lines [v3_target_compile $src $exe executable ""]
+ set lines [v3_target_compile $src /dev/null preprocess ""]
file delete $src
if [string match "" $lines] {
- # No error message, compilation succeeded.
- remote_file build delete $exe
+ # No error message, preprocessing succeeded.
set et_profile_mode 1
}
}
@@ -1030,17 +1020,14 @@
# Set up and compile a C++ test program that depends
# on normal mode activated.
set src normal_mode[pid].cc
- set exe normal_mode[pid].exe
set f [open $src "w"]
puts $f "#if defined(_GLIBCXX_DEBUG) || defined(_GLIBCXX_PROFILE) || defined(_GLIBCXX_PARALLEL)"
puts $f "# error No normal mode"
puts $f "#endif"
- puts $f "int main()"
- puts $f "{ return 0; }"
close $f
- set lines [v3_target_compile $src $exe executable ""]
+ set lines [v3_target_compile $src /dev/null preprocess ""]
file delete $src
if [string match "" $lines] {
@@ -1115,28 +1102,26 @@
} else {
set et_cstdint 0
- # Set up and compile a C++0x test program that depends
+ # Set up and preprocess a C++0x test progra
Re: FDO usability patch -- cfg and lineno checksum
> Please review the new patch which only implements cfg checksum. > > The auto version generation was introduced in 2002 before FDO support > was added (so the old way never existed), so it might be better to > make the change independent of this one. FDO support was there well before 2002, just with funny combination of flags. (-fprofile-arcs and -fbranch-probabilities) 2002 was about the time of GCOV format rewrite, but yes, lets change it independently I will look into the patch ASAP. Honza
Re: [PATCH] Properly build integer constants
On Fri, Apr 22, 2011 at 09:27:50PM +0200, Richard Guenther wrote: > There is a scary comment before build_int_cst_type why build_int_cst > can't be sane. Fortunately it is not true. If it were there would > be other code to be fixed. > > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02297.html suggests that at least back then the old semantics of build_int_cst was needed in round_up and build_prim_array_type. > 2011-04-22 Richard Guenther > > * tree.c (build_int_cst): Properly create canonicalized integer > constants. > (build_int_cst_type): Remove scary comments. Jakub
Re: [patch, PR 48690] fix compilation for m68k-*-netbesdelf
Andreas Tobler writes: > How does linux/m68k handle this? It does not support the 68010. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: better wpa [1/n]: merge types during read-in
> Yes, that's very likely. If we'd get around to re-do the LTO option saving > code > we might want to forbid -g0 compile and -g link (dropping -g at link > time as soon > as we see a single module compiled with -g0). Then we can free some more > stuff, at least with -g0 - though I'm not sure -g0 matters in practice. I would a lot preffer if dwaf2out was able to do the right thing here: output debug info for things that came with debug info in (i.e. was originally compiled with -g) and not for thing that did not. Traditionally it was not neccesary to set -g or -g0 at linktime and we should just get to the same behaviour, perhaps with option to overwrite to -g0 explicitely. Honza
Re: [patch, PR 48690] fix compilation for m68k-*-netbesdelf
On 22.04.11 21:05, Andreas Schwab wrote: Andreas Tobler writes: Index: config/m68k/netbsd-elf.h === --- config/m68k/netbsd-elf.h(revision 172861) +++ config/m68k/netbsd-elf.h(working copy) @@ -97,7 +97,11 @@ #undef PTRDIFF_TYPE #define PTRDIFF_TYPE "int" +/* for 68k machines this only needs to be TRUE for the 68000 */ +#undef STRICT_ALIGNMENT +#define STRICT_ALIGNMENT 0 The 68010 still requires strict alignment. I am not familiar with m68k. I just tried to fix the build issue from 48690. How does linux/m68k handle this? Or was your comment only about the 'comment'? Andreas
[PATCH] Properly build integer constants
There is a scary comment before build_int_cst_type why build_int_cst can't be sane. Fortunately it is not true. If it were there would be other code to be fixed. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2011-04-22 Richard Guenther * tree.c (build_int_cst): Properly create canonicalized integer constants. (build_int_cst_type): Remove scary comments. Index: gcc/tree.c === --- gcc/tree.c (revision 172832) +++ gcc/tree.c (working copy) @@ -1004,7 +1004,7 @@ copy_list (tree list) } -/* Create an INT_CST node with a LOW value sign extended. */ +/* Create an INT_CST node with a LOW value sign extended to TYPE. */ tree build_int_cst (tree type, HOST_WIDE_INT low) @@ -1013,17 +1013,10 @@ build_int_cst (tree type, HOST_WIDE_INT if (!type) type = integer_type_node; - return build_int_cst_wide (type, low, low < 0 ? -1 : 0); + return double_int_to_tree (type, shwi_to_double_int (low)); } -/* Create an INT_CST node with a LOW value in TYPE. The value is sign extended - if it is negative. This function is similar to build_int_cst, but - the extra bits outside of the type precision are cleared. Constants - with these extra bits may confuse the fold so that it detects overflows - even in cases when they do not occur, and in general should be avoided. - We cannot however make this a default behavior of build_int_cst without - more intrusive changes, since there are parts of gcc that rely on the extra - precision of the integer constants. */ +/* Create an INT_CST node with a LOW value sign extended to TYPE. */ tree build_int_cst_type (tree type, HOST_WIDE_INT low)
Re: [PATCH] centralize builtin function type building
On Fri, Apr 22, 2011 at 02:58:31PM -0400, Michael Meissner wrote:
> On Thu, Apr 21, 2011 at 11:04:47AM -0400, Nathan Froyd wrote:
> > - centralizes some infrastructure for defining builtin function types
> > for frontends by providing a common function that
> > DEF_FUNCTION_TYPE_FOO macros can call; and
> >
> > - in order to do that well, it also introduces
> > build{,_varargs}_function_type_array for cases when
> > build_function_type_list's interface doesn't work so well.
>
> 1) For the DEF_FUNCTION_* replacements, the lines exceed the normal 79
>character limits we use as coding guidelines.
Will fix.
> 2) I'm not a fan of having a varargs function with an explicit count. I tend
>to prefer a marker element (like NULL_TREE) as the last element. In this
>case, since it is being used in macros that do have fixed elements, it
> isn't
>a problem.
We have both kinds of varargs usage in-tree; I think the explicit count
version ought to be preferred, as it makes sharing code between the
takes-varargs version and the takes-count-and-pointer (or the takes-VEC
or takes-std::vector) version easier. (The explicit count version makes
future function overloading with takes-count-and-pointer more difficult,
though, and of course there's __attribute__((sentinel)) support for
varargs-with-marker functions.)
I suppose you could just write the macros to use
build_function_type_list instead, but it seems nice to delegate all the
accesses to someplace else.
> 3) I'm also not a fan of passing the index into the type array, instead of a
>tree value to the call. If you pass a tree, then it allows MD builtins to
>call it before we switch to having the MD and front end builtins share the
>bultin index.
Yes, I suppose so.
-Nathan
Re: [patch, PR 48690] fix compilation for m68k-*-netbesdelf
Andreas Tobler writes: > Index: config/m68k/netbsd-elf.h > === > --- config/m68k/netbsd-elf.h (revision 172861) > +++ config/m68k/netbsd-elf.h (working copy) > @@ -97,7 +97,11 @@ > #undef PTRDIFF_TYPE > #define PTRDIFF_TYPE "int" > > +/* for 68k machines this only needs to be TRUE for the 68000 */ > > +#undef STRICT_ALIGNMENT > +#define STRICT_ALIGNMENT 0 The 68010 still requires strict alignment. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: FDO usability patch -- cfg and lineno checksum
Please review the new patch which only implements cfg checksum.
The auto version generation was introduced in 2002 before FDO support
was added (so the old way never existed), so it might be better to
make the change independent of this one.
Thanks,
David
On Thu, Apr 21, 2011 at 2:15 PM, Xinliang David Li wrote:
> On Thu, Apr 21, 2011 at 1:43 PM, Jan Hubicka wrote:
>>> > I don't really follow the logic here. buffer is allocated to be size of
>>> > block+4 and it is expected that gcov_write_words is not executed on size
>>> > greater than 4. Since gcov_write_string now seems to be expected to
>>> > handle
>>> > strings of bigger size, I think you acually need to make write_string to
>>> > write
>>> > in chunks when you reach block boundary?
>>>
>>> gcov_write_words is used to reserve words*4 bytes in buffer for data
>>> write later. The the old logic is wrong -- if 'words' is large enough,
>>> it will lead to out of bound access.
>>
>> The old logic assumes that writes are not bigger than 4 and it is documented
>> somewhere in gcov-io.h if I remember right (it is not my code).
>> I however still think your change won't solve it in general, since you might
>> want to write more than block size, so you need write_string update.
>
> Right, 'words; can be large for string. -- the memcpy code following
> does not look right either.
>
>
>>> >
>>> > What gets into libgcov is very problematic busyness for embedded targets,
>>> > where you really want
>>> > libgcov to be small. Why do you need to store strings now?
>>>
>>> It is needed to store the assembler name for functions. It allows
>>> lookup of the profile data using assembler name as key instead of
>>> using function ids. For gcc, the total size of gcda files is about 59k
>>> bytes without storing the names, and about 65k with names -- about 10%
>>> increase. For eon, the size changes from 27k to 35k bytes.
>>>
>>> I can split the patches into two parts -- one with cfg checksum and
>>> one with the name string.
>>
>> Well, lets make it incremental change then at time we will have use for it
>> once
>> we agree it makes sense.
>
> Ok.
>
>> So you want to do symbol name resolving at GCOV
>> runtime?
>
> For now, it is just passed through as a tag for the profile data for
> each function.
>
>> I duno about embedded targets, 10% increase is not too bad, but I don't know.
>> libgcov has quite inflexible coding style just to be small and fit there, so
>> I don't know what are the space constraints that are considered acceptable
>> in that world.
>
> I will delay the string writing patch for now.
>
>>> > We also need to bump gcov version, right?
>>>
>>> Yes -- but the version is currently derived from gcc version number
>>> and phase number --- this is wrong -- different version of gcc may
>>> have compatible coverage data format. Any suggestions to change this?
>>> --- probably just hard code the GCOV_VERSION string?
>>
>> Hmm, I am pretty sure we used to have minor/major numbering on the file
>> format.
>> Perhaps it went away with Nathan's changes. For -fprofile-use the
>> compatibility
>> across versions is pointless,
>
> Right, but also equally unnecessary to force version mismatch between
> compiler releases.
>
>>at least now, but for gcov utility it makes sense.
>
> Yes.
>
>> So I would go for explicit versioning again.
>>
>
> Will dig through the revision history ..
>
> David
>
>> Honza
>>
>
Index: tree.c
===
--- tree.c (revision 172802)
+++ tree.c (working copy)
@@ -8513,14 +8513,12 @@ dump_tree_statistics (void)
#define FILE_FUNCTION_FORMAT "_GLOBAL__%s_%s"
-/* Generate a crc32 of a string. */
+/* Generate a crc32 of a byte. */
unsigned
-crc32_string (unsigned chksum, const char *string)
+crc32_byte (unsigned chksum, char byte)
{
- do
-{
- unsigned value = *string << 24;
+ unsigned value = (unsigned) byte << 24;
unsigned ix;
for (ix = 8; ix--; value <<= 1)
@@ -8531,6 +8529,18 @@ crc32_string (unsigned chksum, const cha
chksum <<= 1;
chksum ^= feedback;
}
+ return chksum;
+}
+
+
+/* Generate a crc32 of a string. */
+
+unsigned
+crc32_string (unsigned chksum, const char *string)
+{
+ do
+{
+ chksum = crc32_byte (chksum, *string);
}
while (*string++);
return chksum;
@@ -8554,8 +8564,10 @@ clean_symbol_name (char *p)
*p = '_';
}
-/* Generate a name for a special-purpose function function.
+/* Generate a name for a special-purpose function.
The generated name may need to be unique across the whole link.
+ Changes to this function may also require corresponding changes to
+ xstrdup_mask_random.
TYPE is some string to identify the purpose of this function to the
linker or collect2; it must start with an uppercase letter,
one of:
Index: tree.h
===
--- tree.h (revision 172802)
+++ tree.h (working copy)
@@ -4998,6 +49
Re: [PATCH] centralize builtin function type building
On Thu, Apr 21, 2011 at 11:04:47AM -0400, Nathan Froyd wrote:
> This patch does two things:
>
> - centralizes some infrastructure for defining builtin function types
> for frontends by providing a common function that
> DEF_FUNCTION_TYPE_FOO macros can call; and
>
> - in order to do that well, it also introduces
> build{,_varargs}_function_type_array for cases when
> build_function_type_list's interface doesn't work so well.
>
> build_function_type_list could have been used instead, but it would lose
> the error_mark_node handling provided in the C/C++/Ada/LTO frontends.
> This new interface will be necessary for eliminating other uses of
> build_function_type anyway.
>
> It would have been easier to move all of the builtin-types stuff into
> the middle-end, but Fortran doesn't use builtin-types.def. Even if it
> did, I suppose it's possible that some new front-end could have its own
> set of builtin types, so I'm leaving things as they are.
>
> The new functions can eliminate some of the games that were played with
> the recent backend changes to use build_function_type_list; if this
> patch is approved, I'll make the (currently uncommitted) patches that
> could use build_function_type_array do so.
>
> Bootstrap and testing in progress on x86_64-unknown-linux-gnu. OK to
> commit if successful?
Now that I've looked at the patch, a couple of things jump out:
1) For the DEF_FUNCTION_* replacements, the lines exceed the normal 79
character limits we use as coding guidelines.
2) I'm not a fan of having a varargs function with an explicit count. I tend
to prefer a marker element (like NULL_TREE) as the last element. In this
case, since it is being used in macros that do have fixed elements, it isn't
a problem.
3) I'm also not a fan of passing the index into the type array, instead of a
tree value to the call. If you pass a tree, then it allows MD builtins to
call it before we switch to having the MD and front end builtins share the
bultin index.
I'm enclosing the beginnings of the patch that I was working on to allow the MD
to specify *.def files to be included in the master builtin list. Obviously we
need to tie in the front end builtins into the scheme. I've been waiting to
see what Kenny Z was doing in his patches before continuing out.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
[gcc]
2011-04-05 Michael Meissner
* tree.h (enum built_in_function): Add support for machine
dependent builtins to be generated along with normal builtins.
Create new include files that include the standard .def files as
well as any optional machine dependent files.
* builtins.c (built_in_names): Ditto.
* configure.ac (extra_builtin_attrs): Ditto.
(extra_builtin_types): Ditto.
(extra_builtin_md): Ditto.
* config.gcc (extra_builtin_attrs): Ditto.
(extra_builtin_types): Ditto.
(extra_builtin_md): Ditto.
* Makefile.in (builtin-types.h): Ditto.
(builtin-attrs.h): Ditto.
(builtin-md.h): Ditto.
(BUILTIN_MD_H): Rename from BUILTINS_DEF, and add machine
dependent includes. Change all uses.
(BUILTIN_ATTRS_H): New variable for builtin attribute include
files.
(BUILTIN_TYPES_H): New variable for builtin types include files.
* configure: Regenerate.
[gcc/c-family]
2011-04-05 Michael Meissner
* c-common.c (enum built_in_attribute): Add support for MD
builtins to be generated along with normal builtins.
(enum c_builtin_type): Ditto.
(c_define_builtins): Ditto.
(c_init_attributes): Ditto.
[gcc/lto]
2011-04-05 Michael Meissner
* lto-lang.c (enum built_in_attribute): Add support for machine
dependent builtins to be generated along with normal builtins.
(enum lto_builtin_type): Ditto.
(def_fn_type): Ditto.
(lto_init_attributes): Ditto.
(lto_define_builtins): Ditto.
(lto_register_builtin_type): Ditto.
* Make-lang.in (lto/lto-lang.o): Ditto.
Index: gcc/tree.h
===
--- gcc/tree.h (revision 171948)
+++ gcc/tree.h (working copy)
@@ -1,6 +1,6 @@
/* Front-end tree definitions for GNU compiler.
Copyright (C) 1989, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
- 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
+ 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
Free Software Foundation, Inc.
This file is part of GCC.
@@ -226,7 +226,7 @@ extern const char *const built_in_class_
#define DEF_BUILTIN(ENUM, N, C, T, LT, B, F, NA, AT, IM, COND) ENUM,
enum built_in_function
{
-#include "builtins.def"
+#include "builtin-md.h"
/* Complex division routines in libgcc. These are done via builtins
because emit_library_call_value
Re: [PATCH] Fix associate_plusminus A + ~A optimization (PR tree-optimization/48717)
On Fri, Apr 22, 2011 at 04:50:26PM +0200, Richard Guenther wrote: > build_int_cst looks seriously broken, I think we want to make it > an alias of build_int_cst_type, or rather call that from > build_int_cst. The comment above build_int_cst_type talks about it: "We cannot however make this a default behavior of build_int_cst without more intrusive changes, since there are parts of gcc that rely on the extra precision of the integer constants." Jakub
Re: [build] Support multilib testing in libgo
Rainer Orth writes:
> 2011-02-13 Rainer Orth
>
> * Makefile.am (CHECK): Remove -Wl,-R from $GC.
> Add LD_LIBRARY_PATH.
> (check): Depend on check-multi, check-tail.
> (check-recursive): Depend on check-head.
> (check-am): Move header, footer generation ...
> (check-head, check-tail): ... here.
> New targets.
> (check-multi): New target.
> (MOSTLYCLEAN_FILES): Replace libgo.tail by libgo.head, add
> libgo.sum.sep, libgo.log.sep.
> * Makefile.in: Regenerate.
Thanks a lot for writing this. I tweaked it a bit, and committed it as
follows. Let me know if my tweaks caused any problem.
Ian
diff -r fd5c88df5eb8 libgo/Makefile.am
--- a/libgo/Makefile.am Fri Apr 22 11:14:30 2011 -0700
+++ b/libgo/Makefile.am Fri Apr 22 11:25:39 2011 -0700
@@ -1544,12 +1544,16 @@
# Check a package.
CHECK = \
- GC="$(GOC) -L `${PWD_COMMAND}` -L `${PWD_COMMAND}`/.libs -Wl,-R,`${PWD_COMMAND}`/.libs"; \
+ GC="$(GOC) -L `${PWD_COMMAND}` -L `${PWD_COMMAND}`/.libs"; \
export GC; \
RUNTESTFLAGS="$(RUNTESTFLAGS)"; \
export RUNTESTFLAGS; \
MAKE="$(MAKE)"; \
export MAKE; \
+ libgccdir=`${GOC} -print-libgcc-file-name | sed -e 's|/[^/]*$$||'`; \
+ LD_LIBRARY_PATH="`${PWD_COMMAND}`/.libs:$${libgccdir}:${LD_LIBRARY_PATH}"; \
+ LD_LIBRARY_PATH=`echo $${LD_LIBRARY_PATH} | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; \
+ export LD_LIBRARY_PATH; \
rm -f $@-testsum $@-testlog; \
prefix=`if test "$(@D)" = "regexp"; then echo regexp-test; else dirname $(@D); fi`; \
test "$${prefix}" != "." || prefix="$(@D)"; \
@@ -3065,55 +3069,103 @@
testing/quick/check \
testing/script/check
+check: check-tail
+check-recursive: check-head
+
+check-head:
+ @echo "Test Run By $${USER} on `date`" > libgo.head
+ @echo "Native configuration is $(host_triplet)" >> libgo.head
+ @echo >> libgo.head
+ @echo " === libgo tests ===" >> libgo.head
+ @echo >> libgo.head
+
+check-tail: check-recursive check-multi
+ @lib=`${PWD_COMMAND} | sed -e 's,^.*/\([^/][^/]*\)$$,\1,'`; \
+ for dir in . $(MULTIDIRS); do \
+ mv ../$${dir}/$${lib}/libgo.sum ../$${dir}/$${lib}/libgo.sum.sep; \
+ mv ../$${dir}/$${lib}/libgo.log ../$${dir}/$${lib}/libgo.log.sep; \
+ done; \
+ mv libgo.head libgo.sum; \
+ cp libgo.sum libgo.log; \
+ echo "Schedule of variations:" >> libgo.sum; \
+ for dir in . $(MULTIDIRS); do \
+ multidir=../$${dir}/$${lib}; \
+ multivar=`cat $${multidir}/libgo.var`; \
+ echo "$${multivar}" >> libgo.sum; \
+ done; \
+ echo >> libgo.sum; \
+ pass=0; fail=0; untested=0; \
+ for dir in . $(MULTIDIRS); do \
+ multidir=../$${dir}/$${lib}; \
+ multivar=`cat $${multidir}/libgo.var`; \
+ echo "Running target $${multivar}" >> libgo.sum; \
+ echo "Running $(srcdir)/libgo.exp ..." >> libgo.sum; \
+ cat $${multidir}/libgo.sum.sep >> libgo.sum; \
+ cat $${multidir}/libgo.log.sep >> libgo.log; \
+ if test -n "${MULTIDIRS}"; then \
+ echo " === libgo Summary for $${multivar} ===" >> libgo.sum; \
+ echo >> libgo.sum; \
+ fi; \
+ p=`grep -c PASS $${multidir}/libgo.sum.sep`; \
+ pass=`expr $$pass + $$p`; \
+ if test "$$p" -ne "0" && test -n "${MULTIDIRS}"; then \
+ echo "# of expected passes $$p" >> libgo.sum; \
+ fi; \
+ p=`grep -c FAIL $${multidir}/libgo.sum.sep`; \
+ fail=`expr $$fail + $$p`; \
+ if test "$$p" -ne "0" && test -n "${MULTIDIRS}"; then \
+ echo "# of unexpected failures $$p" >> libgo.sum; \
+ fi; \
+ p=`grep -c UNTESTED $${multidir}/libgo.sum.sep`; \
+ untested=`expr $$untested + $$p`; \
+ if test "$$p" -ne "0" && test -n "${MULTIDIRS}"; then \
+ echo "# of untested testcases $$p" >> libgo.sum; \
+ fi; \
+ done; \
+ echo >> libgo.sum; \
+ echo " === libgo Summary ===" >> libgo.sum; \
+ echo >> libgo.sum; \
+ if test "$$pass" -ne "0"; then \
+ echo "# of expected passes $$pass" >> libgo.sum; \
+ fi; \
+ if test "$$fail" -ne "0"; then \
+ echo "# of unexpected failures $$fail" >> libgo.sum; \
+ fi; \
+ if test "$$untested" -ne "0"; then \
+ echo "# of untested testcases $$untested" >> libgo.sum; \
+ fi; \
+ echo `echo $(GOC) | sed -e 's/ .*//'` `$(GOC) -v 2>&1 | grep " version" | sed -n -e 's/.* \(version.*$$\)/\1/p'` >> libgo.sum; \
+ echo >> libgo.log; \
+ echo "runtest completed at `date`" >> libgo.log; \
+ if test "$$fail" -ne "0"; then \
+ status=1; \
+ else \
+ status=0; \
+ fi; \
+ exit $$status
+
check-am:
@rm -f libgo.sum libgo.log libgo.tail
- @echo "Test Run By $${USER} on `date`" > libgo.sum
- @echo "Native configuration is $(host_triplet)" >> libgo.sum
- @echo >> libgo.sum
- @echo " === libgo tests ===" >> libgo.sum
- @echo >> libgo.sum
- @echo "Schedule of variations:" >> libgo.sum
- @echo "unix" >> libgo.sum
- @echo >> libgo.sum
- @echo "Running target unix" >> libgo.sum
- @echo "Running $(srcdir)/libgo.exp ..." >> libgo.sum
- @cp libgo.sum libgo.log
- @echo > libgo.tail
- @echo " === libgo summary ===" >> libgo.tail
- @echo >> libgo.tail
+ @multivar="unix"; \
+ [ -z "$(MULTIFLAGS)" ]
[PATCH, i386]: Fix PR target/48723
Hello!
Attached one-liner fixes PR target/48723, ICE in
ix86_expand_prologue() with -fstack-check + function returning struct,
on corei7-avx. The problem was, that we forgot to update accounting
info when ix86_adjust_stack_and_probe adjusted stack pointer (in this
particular case, m->fs.sp_offset was set by stack realignment code for
AVX 32byte stack alignment.
2011-04-22 Uros Bizjak
PR target/48723
* config/i386/i386.c (ix86_expand_prologue): Update m->fs.sp_offset
after the call to ix86_adjust_stack_and_probe.
testsuite/ChangeLog:
2011-04-22 Uros Bizjak
PR target/48723
* gcc.target/i386/pr48723.c: New test.
Tested on x86_64-pc-linux-gnu {,-m32} AVX target.
Patch was committed to mainline and 4.6 branch.
Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 172860)
+++ config/i386/i386.c (working copy)
@@ -10628,6 +10628,7 @@ ix86_expand_prologue (void)
if (STACK_CHECK_MOVING_SP)
{
ix86_adjust_stack_and_probe (allocate);
+ m->fs.sp_offset += allocate;
allocate = 0;
}
else
Index: testsuite/gcc.target/i386/pr48723.c
===
--- testsuite/gcc.target/i386/pr48723.c (revision 0)
+++ testsuite/gcc.target/i386/pr48723.c (revision 0)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-fstack-check -mavx" } */
+
+struct S0
+{
+ int f0, f1, f2, f3;
+} g_106;
+
+struct S0
+func_99 ()
+{
+ return (g_106);
+}
libgo patch committed: Inherit environment in http/cgi
This libgo patch brings over a patch to the master Go library to inherit
environment variables in http/cgi. This should fix PR go/48503.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 9457f9a2e900 libgo/go/http/cgi/host.go
--- a/libgo/go/http/cgi/host.go Thu Apr 21 15:51:28 2011 -0700
+++ b/libgo/go/http/cgi/host.go Fri Apr 22 11:12:38 2011 -0700
@@ -25,20 +25,30 @@
"os"
"path/filepath"
"regexp"
+ "runtime"
"strconv"
"strings"
)
var trailingPort = regexp.MustCompile(`:([0-9]+)$`)
+var osDefaultInheritEnv = map[string][]string{
+ "darwin": []string{"DYLD_LIBRARY_PATH"},
+ "freebsd": []string{"LD_LIBRARY_PATH"},
+ "hpux":[]string{"LD_LIBRARY_PATH", "SHLIB_PATH"},
+ "linux": []string{"LD_LIBRARY_PATH"},
+ "windows": []string{"SystemRoot", "COMSPEC", "PATHEXT", "WINDIR"},
+}
+
// Handler runs an executable in a subprocess with a CGI environment.
type Handler struct {
Path string // path to the CGI executable
Root string // root URI prefix of handler or empty for "/"
- Env[]string// extra environment variables to set, if any
- Logger *log.Logger // optional log for errors or nil to use log.Print
- Args []string// optional arguments to pass to child process
+ Env[]string// extra environment variables to set, if any, as "key=value"
+ InheritEnv []string// environment variables to inherit from host, as "key"
+ Logger *log.Logger // optional log for errors or nil to use log.Print
+ Args []string// optional arguments to pass to child process
}
func (h *Handler) ServeHTTP(rw http.ResponseWriter, req *http.Request) {
@@ -110,6 +120,24 @@
env = append(env, h.Env...)
}
+ path := os.Getenv("PATH")
+ if path == "" {
+ path = "/bin:/usr/bin:/usr/ucb:/usr/bsd:/usr/local/bin"
+ }
+ env = append(env, "PATH="+path)
+
+ for _, e := range h.InheritEnv {
+ if v := os.Getenv(e); v != "" {
+ env = append(env, e+"="+v)
+ }
+ }
+
+ for _, e := range osDefaultInheritEnv[runtime.GOOS] {
+ if v := os.Getenv(e); v != "" {
+ env = append(env, e+"="+v)
+ }
+ }
+
cwd, pathBase := filepath.Split(h.Path)
if cwd == "" {
cwd = "."
[patch, PR 48690] fix compilation for m68k-*-netbesdelf
Hi all, the attached patch fixes the build for m68k-netbsdelf1.6.1. Tested with a cross build for c,c++ and fortran. The breakage is alive since r121736. The patch does the same as m68k linux does. Ok for trunk? Thanks, Andreas 2011-04-22 Andreas Tobler PR target/48690 * config/m68k/netbsd-elf.h: Undef STRICT_ALIGNMENT. Index: config/m68k/netbsd-elf.h === --- config/m68k/netbsd-elf.h(revision 172861) +++ config/m68k/netbsd-elf.h(working copy) @@ -97,7 +97,11 @@ #undef PTRDIFF_TYPE #define PTRDIFF_TYPE "int" +/* for 68k machines this only needs to be TRUE for the 68000 */ +#undef STRICT_ALIGNMENT +#define STRICT_ALIGNMENT 0 + /* XXX Here is a bunch of stuff lifted from m68kelf.h. We don't use that file directly, because it has a lot of baggage we don't want. */
Ping: [PATCH, 4.7] Add float/double vector reductions to VSX
I'm wondering whether the following patch to add V4SF and V2DF reductions fell through the cracks? http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01525.html -- Michael Meissner, IBM 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
[Ada] Do not silently drop parallel types
This fixes an oversight in the support for parallel types: they are silently dropped when a type goes through make_packable_type. Fixed thusly, tested on i586-suse-linux, applied on the mainline. 2011-04-22 Eric Botcazou * gcc-interface/decl.c (make_packable_type): Copy DECL_PARALLEL_TYPE onto the new type. -- Eric Botcazou Index: gcc-interface/decl.c === --- gcc-interface/decl.c (revision 172862) +++ gcc-interface/decl.c (working copy) @@ -6334,6 +6334,8 @@ make_packable_type (tree type, bool in_r finish_record_type (new_type, nreverse (field_list), 2, false); relate_alias_sets (new_type, type, ALIAS_SET_COPY); + SET_DECL_PARALLEL_TYPE (TYPE_STUB_DECL (new_type), + DECL_PARALLEL_TYPE (TYPE_STUB_DECL (type))); /* If this is a padding record, we never want to make the size smaller than what was specified. For QUAL_UNION_TYPE, also copy the size. */
[Ada] Filter out -Winline messages for compiler-generated code
This patch prevents the compiler from issuing -Winline warnings for functions
that are compiler-generated. There are a lot of them in Ada and the warnings
are too cryptic to be useful for the average user in this case.
Tested on i586-suse-linux, applied on the mainline.
2011-04-22 Eric Botcazou
* gcc-interface/gigi.h (create_subprog_decl): Add ARTIFICIAL_FLAG
parameter.
* gcc-interface/utils.c (create_subprog_decl): Likewise. Set
DECL_ARTIFICIAL and DECL_NO_INLINE_WARNING_P on the DECL accordingly.
* gcc-interface/decl.c (gnat_to_gnu_entity) : Add
ARTIFICIAL_FLAG local variable and pass it to create_subprog_decl.
: Do not set flags on the reused DECL node coming from an alias.
Set DECL_IGNORED_P on the DECL node built for subprograms if they
don't need debug info here...
* gcc-interface/trans.c (Subprogram_Body_to_gnu): ...and not here.
(gigi): Adjust calls to create_subprog_decl.
(build_raise_check): Likewise.
(establish_gnat_vms_condition_handler): Likewise.
(Compilation_Unit_to_gnu): Likewise.
(gnat_to_gnu): Likewise.
--
Eric Botcazou
Index: gcc-interface/utils.c
===
--- gcc-interface/utils.c (revision 172811)
+++ gcc-interface/utils.c (working copy)
@@ -1795,7 +1795,7 @@ value_factor_p (tree value, HOST_WIDE_IN
return false;
}
-/* Given 2 consecutive field decls PREV_FIELD and CURR_FIELD, return true
+/* Given two consecutive field decls PREV_FIELD and CURR_FIELD, return true
unless we can prove these 2 fields are laid out in such a way that no gap
exist between the end of PREV_FIELD and the beginning of CURR_FIELD. OFFSET
is the distance in bits between the end of PREV_FIELD and the starting
@@ -1841,7 +1841,7 @@ potential_alignment_gap (tree prev_field
return true;
}
-/* Returns a LABEL_DECL node for LABEL_NAME. */
+/* Return a LABEL_DECL node for LABEL_NAME. */
tree
create_label_decl (tree label_name)
@@ -1856,24 +1856,26 @@ create_label_decl (tree label_name)
return label_decl;
}
-/* Returns a FUNCTION_DECL node. SUBPROG_NAME is the name of the subprogram,
+/* Return a FUNCTION_DECL node. SUBPROG_NAME is the name of the subprogram,
ASM_NAME is its assembler name, SUBPROG_TYPE is its type (a FUNCTION_TYPE
node), PARAM_DECL_LIST is the list of the subprogram arguments (a list of
PARM_DECL nodes chained through the TREE_CHAIN field).
- INLINE_FLAG, PUBLIC_FLAG, EXTERN_FLAG, and ATTR_LIST are used to set the
- appropriate fields in the FUNCTION_DECL. GNAT_NODE gives the location. */
+ INLINE_FLAG, PUBLIC_FLAG, EXTERN_FLAG, ARTIFICIAL_FLAG and ATTR_LIST are
+ used to set the appropriate fields in the FUNCTION_DECL. GNAT_NODE is
+ used for the position of the decl. */
tree
-create_subprog_decl (tree subprog_name, tree asm_name,
- tree subprog_type, tree param_decl_list, bool inline_flag,
- bool public_flag, bool extern_flag,
- struct attrib *attr_list, Node_Id gnat_node)
+create_subprog_decl (tree subprog_name, tree asm_name, tree subprog_type,
+ tree param_decl_list, bool inline_flag, bool public_flag,
+ bool extern_flag, bool artificial_flag,
+ struct attrib *attr_list, Node_Id gnat_node)
{
tree subprog_decl = build_decl (input_location, FUNCTION_DECL, subprog_name,
subprog_type);
tree result_decl = build_decl (input_location, RESULT_DECL, NULL_TREE,
TREE_TYPE (subprog_type));
+ DECL_ARGUMENTS (subprog_decl) = param_decl_list;
/* If this is a non-inline function nested inside an inlined external
function, we cannot honor both requests without cloning the nested
@@ -1887,13 +1889,15 @@ create_subprog_decl (tree subprog_name,
&& DECL_EXTERNAL (current_function_decl))
DECL_DECLARED_INLINE_P (current_function_decl) = 0;
- DECL_EXTERNAL (subprog_decl) = extern_flag;
- TREE_PUBLIC (subprog_decl)= public_flag;
- TREE_READONLY (subprog_decl) = TYPE_READONLY (subprog_type);
+ DECL_ARTIFICIAL (subprog_decl) = artificial_flag;
+ DECL_EXTERNAL (subprog_decl) = extern_flag;
+ DECL_DECLARED_INLINE_P (subprog_decl) = inline_flag;
+ DECL_NO_INLINE_WARNING_P (subprog_decl) = inline_flag && artificial_flag;
+
+ TREE_PUBLIC (subprog_decl) = public_flag;
+ TREE_READONLY (subprog_decl) = TYPE_READONLY (subprog_type);
TREE_THIS_VOLATILE (subprog_decl) = TYPE_VOLATILE (subprog_type);
TREE_SIDE_EFFECTS (subprog_decl) = TYPE_VOLATILE (subprog_type);
- DECL_DECLARED_INLINE_P (subprog_decl) = inline_flag;
- DECL_ARGUMENTS (subprog_decl) = param_decl_list;
DECL_ARTIFICIAL (result_decl) = 1;
DECL_IGNORED_P (result_decl) = 1;
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 172811)
+++ gcc-interface/decl.c (working copy)
@@ -3934,6 +3934,7 @@ gnat_t
Re: new option -Wno-maybe-uninitialized
Looks like we won't get consensus (as Jeff mentioned) on the naming etc. Shall I just commit this one? Thanks, David On Fri, Apr 22, 2011 at 9:23 AM, Gabriel Dos Reis wrote: > On Fri, Apr 22, 2011 at 3:52 AM, Richard Guenther > wrote: > > >>> Maybe-uninitialized matches case 3) -- different from case 2 which is >>> actually 'maybe-used-uninitialized'. >> >> Other diagnostics use a level to indicate their noise level. So, why not >> do something like -Wuninitialized=N, with N from 1 to 3, covering all >> three cases. > > because numbers are good for machines, but terrible as user-interface :-) >
Re: (build) Patch to fix cp/cfns.gperf building issues
On Fri, 22 Apr 2011, Nicola Pero wrote: > In general, I personally feel that the building system should not depend > on the relative timestamps of source files unless it's doing something > in "maintainer mode" where it's being explicitly asked to rebuild one > source file from the other. We have a --enable-maintainer-mode configure option. I think you should use that instead of having a special rule for a particular file. -- Joseph S. Myers jos...@codesourcery.com
Re: FDO usage: -Wcoverage-mismatch should not ignore -Wno-error
On Thu, 21 Apr 2011, Xinliang David Li wrote: > Please review the new patch. The new patch is OK with a suitable ChangeLog entry. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH PING] c++-specific bits of tree-slimming patches
On Apr 22, 2011, at 8:55 AM, Jason Merrill wrote: > On 04/22/2011 02:13 AM, Mike Stump wrote: >> http://gcc.gnu.org/ml/gcc/2005-04/msg00161.html >> >> has the details of why the code was put in. > > Right. At the time, we were sorting the goto queue based on pointer values, > which caused the problem. We no longer do that, Excellent. That was the only concern I knew of.
Re: new option -Wno-maybe-uninitialized
On Fri, Apr 22, 2011 at 3:52 AM, Richard Guenther wrote: >> Maybe-uninitialized matches case 3) -- different from case 2 which is >> actually 'maybe-used-uninitialized'. > > Other diagnostics use a level to indicate their noise level. So, why not > do something like -Wuninitialized=N, with N from 1 to 3, covering all > three cases. because numbers are good for machines, but terrible as user-interface :-)
Re: new option -Wno-maybe-uninitialized
Sounds like a good idea, but does -Werror=xxx work for this ? I tried cases with -Wstrict-aliasing, -Werror handling seems broken. Thanks, David On Fri, Apr 22, 2011 at 1:52 AM, Richard Guenther wrote: > On Thu, Apr 21, 2011 at 7:43 PM, Xinliang David Li wrote: >> On Thu, Apr 21, 2011 at 10:21 AM, Jeff Law wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 04/07/11 18:24, Xinliang David Li wrote: Hi, the following patch implements the option to fine control the emitted warnings -- 1) allow suppressing warnings for use of values that may be uninitialized. Definitely uninitialized values that may be used warning is not affected 2) allow fine grain control on promotion of warnings to errors: -Wno-error=maybe-uninitialized This is useful for users who only care about definite uninitialized variable warnings. >>> I'm definitely in favor of having the ability for the user to be able to >>> fine tune the warnings they want. However, I have some concerns. >>> >>> First, I'm not sure how reconcile the may vs must inconsistency. We can >>> have an object which is used in a real statement in the IL, which we >>> currently would classify as must-be-uninitialized, even if the path >>> leading to the statement is unexecutable. I guess I want to find >>> better ways to describe this kind of stuff in our documentation and >>> switch names >> >> There are three different kind of uninit warnings: >> >> 1) definitely uninitialized, and the use the variable dominates the >> exit -- this is the must be used uninitialized case >> 2) definitely uninitialized, but the use may not be executed at runtime; >> 3) Only initialized in some paths from entry to the use (the use may >> or may not be executed). >> >> Currently 2) and 3) uses the same warning message, which may be misleading. >> >> The proposed new option only controls 3). >> >>> >>> Second, I'm concerned about changing the default behaviour of >>> - -Wuninitialized. I don't think we ever reached a consensus on that >>> issue last time we tried to hash through this stuff. Maybe I missed >>> something, but it appears to me your patch makes -Wuninitialized only >>> warn about real uses and ignore uses in PHIs. >> >> No, the patch does not change the default behavior of -Wuninitialized >> wihch will turn on -Wmaybe-uninitialized as well. The only useful >> scenarios for the new option are: >> >> 1) -Wuninitialized -Wno-maybe-uninitialized >> 2) -Wuninitialized -Werror=uninitialized -Wno-error=maybe-uninitialized >> >>> >>> Given the lack of consensus (and I believe there will never be a >>> consensus), I believe we should keep -Wuninitialized behavior as-is and >>> use -Wno-maybe-uninitialized to override -Wuninitialized. >> >> Yes, that is this patch is supposed to do -- the attached test case is >> testing it. >> >>> >>> If we can come up with better switch name than -Wno-maybe-uninitialized, >>> that would be a good step as well. However, I'm not offhand sure what >>> name to use given the issues surrounding may vs must be used uninitialized. >> >> Maybe-uninitialized matches case 3) -- different from case 2 which is >> actually 'maybe-used-uninitialized'. > > Other diagnostics use a level to indicate their noise level. So, why not > do something like -Wuninitialized=N, with N from 1 to 3, covering all > three cases. Also note that 1 and 2 are not really different as the function > in question may be never executed, so 1 becomes 2 as well. > > Richard. > >> Thanks, >> >> David >> >>> >>> jeff >>> >>> -BEGIN PGP SIGNATURE- >>> Version: GnuPG v1.4.11 (GNU/Linux) >>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >>> >>> iQEcBAEBAgAGBQJNsGecAAoJEBRtltQi2kC7BugH/01X2ppdVUONq2fBzztxF+YR >>> Qn85yccwI45iizNG1dlmyZlYpATYcfTGwDkBYTjiVllhOJa64Ri6bIP3ErySPllk >>> OrSAbwFT96TK9/h1eGfVj45mZS3MO0Pa+sxp93noGnxIMWWOt+7LiyrfJEHHLaUK >>> rPhREXodzLnN0KpXTD8+RS2uzTV+YODAuiWQDkiyQ0XpjCw5w2ccc7dWnrzgvEn5 >>> 6x/baTqQxunV8t3/ezUlHiMcUNyMigXccFgIeRRsvMengY/reLxy7eg1i+vdeets >>> DyWR/Hg3HewLAQidL3SAJLLGuqTrNUZ0wswgqghqh9VllAFoUdKn0xk8GFt0wbk= >>> =4aA4 >>> -END PGP SIGNATURE- >>> >> >
Re: [PATCH] centralize builtin function type building
On Thu, Apr 21, 2011 at 05:36:42PM +0200, Richard Guenther wrote:
> On Thu, Apr 21, 2011 at 5:04 PM, Nathan Froyd
> wrote:
> > This patch does two things:
> >
> > - centralizes some infrastructure for defining builtin function types
> > for frontends by providing a common function that
> > DEF_FUNCTION_TYPE_FOO macros can call; and
> >
> > - in order to do that well, it also introduces
> > build{,_varargs}_function_type_array for cases when
> > build_function_type_list's interface doesn't work so well.
> >
> > It would have been easier to move all of the builtin-types stuff into
> > the middle-end, but Fortran doesn't use builtin-types.def. Even if it
> > did, I suppose it's possible that some new front-end could have its own
> > set of builtin types, so I'm leaving things as they are.
>
> But this is what should be done, at least for all builtins in the
> BUILT_IN_NORMAL category. ISTR Fortran was once running into
> the issue of assigning different DECL_FUNCTION_CODE numbers to
> those builtins than other languages, breaking LTO.
>
> So, it would be indeed nice to have a central middle-end place to
> instantiate those builtins and their required types. I'm not sure how
> far we are from that and am too lazy to look right now ...
I agree that it would be better to have a central middle-end place for
this; I'm not entirely sure why Fortran opts to use a separate set of
types; AFAICS, it's a strict subset. Fortran folks...?
The question of decls is something different and unrelated to this
patch, IMHO. Is the patch OK as-is, or should I work on merging the
types into the middle-end in addition?
-Nathan
Re: [PATCH PING] c++-specific bits of tree-slimming patches
On 04/22/2011 02:13 AM, Mike Stump wrote: http://gcc.gnu.org/ml/gcc/2005-04/msg00161.html has the details of why the code was put in. Right. At the time, we were sorting the goto queue based on pointer values, which caused the problem. We no longer do that, so we shouldn't need this workaround (deferring creation of case label labels) anymore. What do you think, Alex? Jason
[PATCH] Canonicalize compares in combine [3/3] ARM backend part
Hi Richard, this part's for you.
The ARM backend changes needed are very little after the prior patches,
basically just a case in arm_canonicalize_comparison() to detect
(zero_extend:SI (subreg:QI (reg:SI ...) 0)), and swap it into (and:SI
(reg:SI) #255).
Had we not tried the combine modifications, this testcase probably could
have also be solved by implementing another version of the corresponding
*andsi3_compare0/_scratch patterns, with ZERO_EXTEND in the body, and
"ands" in the output assembly. Maybe that's an acceptable solution too...
About the (ab)use of CANONICALIZE_COMPARISON, if it really should be
another macro/hook, then this ARM patch will need updating, but the code
should be similar.
Thanks,
Chung-Lin
Index: config/arm/arm.c
===
--- config/arm/arm.c(revision 172860)
+++ config/arm/arm.c(working copy)
@@ -3276,6 +3276,19 @@
return code;
}
+ /* If *op0 is (zero_extend:SI (subreg:QI (reg:SI) 0)) and comparing
+ with const0_rtx, change it to (and:SI (reg:SI) (const_int 255)),
+ to facilitate possible combining with a cmp into 'ands'. */
+ if (mode == SImode
+ && GET_CODE (*op0) == ZERO_EXTEND
+ && GET_CODE (XEXP (*op0, 0)) == SUBREG
+ && GET_MODE (XEXP (*op0, 0)) == QImode
+ && GET_MODE (SUBREG_REG (XEXP (*op0, 0))) == SImode
+ && SUBREG_BYTE (XEXP (*op0, 0)) == 0
+ && *op1 == const0_rtx)
+*op0 = gen_rtx_AND (SImode, SUBREG_REG (XEXP (*op0, 0)),
+ GEN_INT (255));
+
/* Comparisons smaller than DImode. Only adjust comparisons against
an out-of-range constant. */
if (GET_CODE (*op1) != CONST_INT
Index: testsuite/gcc.target/arm/combine-movs.c
===
--- testsuite/gcc.target/arm/combine-movs.c (revision 0)
+++ testsuite/gcc.target/arm/combine-movs.c (revision 0)
@@ -0,0 +1,10 @@
+/* { dg-options "-O" } */
+
+void foo (unsigned long r[], unsigned int d)
+{
+ int i, n = d / 32;
+ for (i = 0; i < n; ++i)
+r[i] = 0;
+}
+
+/* { dg-final { scan-assembler "movs\tr\[0-9\]" } } */
Index: testsuite/gcc.target/arm/unsigned-extend-2.c
===
--- testsuite/gcc.target/arm/unsigned-extend-2.c(revision 0)
+++ testsuite/gcc.target/arm/unsigned-extend-2.c(revision 0)
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-options "-O -march=armv6" } */
+
+unsigned short foo (unsigned short x)
+{
+ unsigned char i = 0;
+ for (i = 0; i < 8; i++)
+{
+ x >>= 1;
+ x &= 0x7fff;
+}
+ return x;
+}
+
+/* { dg-final { scan-assembler "ands" } } */
+/* { dg-final { scan-assembler-not "uxtb" } } */
+/* { dg-final { scan-assembler-not "cmp" } } */
[PATCH] Canonicalize compares in combine [2/3] Modifications to try_combine()
This patch is the main bulk of this submission. It modifies the compare
combining part of try_combine(), adding a call of
CANONICALIZE_COMPARISON into the entire logic.
Also, instead of testing for XEXP(SET_SRC(PATTERN(i3)),1) == const0_rtx
at the top, it now allows CONST_INT_P(XEXP(SET_SRC(PATTERN(i3)),1)),
tries to adjust it by simplify_compare_const() from the last patch, and
then tests if op1 == const0_rtx. This is a small improvement in some cases.
(if you remove the call to simplify_compare_const(), and if
CANONICALIZE_COMPARISON is not defined for the target, then this entire
patch should be an 'idempotent patch', nothing should be changed to the
effective combine results)
One issue that I would like to RFC, is the use of
CANONICALIZE_COMPARISON here; I'm afraid I might be abusing it. Since
added_sets_2 is set here, the value of i2src/op0 is needed afterwards.
This might not be conformant to the description of
CANONICALIZE_COMPARISON in the internals manual, which doesn't say it
can't trash op0 under arbitrary conditions while only preserving the
comparison result.
OTOH, I don't see another suitable macro/hook (with a close enough
meaning), and the current definitions of CANONICALIZE_COMPARISON across
the targets do not seem to clash with my use here. Does this macro use
look okay, or does this justify creating a new one?
Thanks,
Chung-Lin
Index: combine.c
===
--- combine.c (revision 172860)
+++ combine.c (working copy)
@@ -3046,58 +3047,89 @@
if (i1 == 0 && added_sets_2 && GET_CODE (PATTERN (i3)) == SET
&& GET_CODE (SET_SRC (PATTERN (i3))) == COMPARE
- && XEXP (SET_SRC (PATTERN (i3)), 1) == const0_rtx
+ && CONST_INT_P (XEXP (SET_SRC (PATTERN (i3)), 1))
&& rtx_equal_p (XEXP (SET_SRC (PATTERN (i3)), 0), i2dest))
{
-#ifdef SELECT_CC_MODE
- rtx *cc_use;
- enum machine_mode compare_mode;
-#endif
+ rtx newpat_dest;
+ rtx *cc_use_loc = NULL, cc_use_insn = NULL_RTX;
+ rtx op0 = i2src, op1 = XEXP (SET_SRC (PATTERN (i3)), 1);
+ enum machine_mode compare_mode, orig_compare_mode;
+ enum rtx_code compare_code = UNKNOWN, orig_compare_code = UNKNOWN;
newpat = PATTERN (i3);
- SUBST (XEXP (SET_SRC (newpat), 0), i2src);
+ newpat_dest = SET_DEST (newpat);
+ compare_mode = orig_compare_mode = GET_MODE (newpat_dest);
- i2_is_used = 1;
-
-#ifdef SELECT_CC_MODE
- /* See if a COMPARE with the operand we substituted in should be done
-with the mode that is currently being used. If not, do the same
-processing we do in `subst' for a SET; namely, if the destination
-is used only once, try to replace it with a register of the proper
-mode and also replace the COMPARE. */
if (undobuf.other_insn == 0
- && (cc_use = find_single_use (SET_DEST (newpat), i3,
- &undobuf.other_insn))
- && ((compare_mode = SELECT_CC_MODE (GET_CODE (*cc_use),
- i2src, const0_rtx))
- != GET_MODE (SET_DEST (newpat
+ && (cc_use_loc = find_single_use (SET_DEST (newpat), i3,
+ &cc_use_insn)))
{
- if (can_change_dest_mode (SET_DEST (newpat), added_sets_2,
- compare_mode))
+ compare_code = orig_compare_code = GET_CODE (*cc_use_loc);
+ compare_code = simplify_compare_const (compare_code,
+op0, &op1);
+#ifdef CANONICALIZE_COMPARISON
+ CANONICALIZE_COMPARISON (compare_code, op0, op1);
+#endif
+ }
+
+ /* Do the rest only if op1 is const0_rtx, which may be the
+result of simplification. */
+ if (op1 == const0_rtx)
+ {
+ if (cc_use_loc)
{
- unsigned int regno = REGNO (SET_DEST (newpat));
- rtx new_dest;
-
- if (regno < FIRST_PSEUDO_REGISTER)
- new_dest = gen_rtx_REG (compare_mode, regno);
- else
+#ifdef SELECT_CC_MODE
+ enum machine_mode new_mode
+ = SELECT_CC_MODE (compare_code, op0, op1);
+ if (new_mode != orig_compare_mode
+ && can_change_dest_mode (SET_DEST (newpat),
+ added_sets_2, new_mode))
{
- SUBST_MODE (regno_reg_rtx[regno], compare_mode);
- new_dest = regno_reg_rtx[regno];
+ unsigned int regno = REGNO (newpat_dest);
+ compare_mode = new_mode;
+ if (regno < FIRST_PSEUDO_REGISTER)
+ newpat_dest = gen_rtx_REG (compare_mode, regno);
+ else
+ {
+ SUBST_MODE (regno_reg_rtx[regno], compare_mode);
+ newpat_dest = regno_reg_rtx[regno];
+ }
}
+#en
[PATCH] Canonicalize compares in combine [1/3] Abstract out parts of simplify_comparison()
This patch abstracts out a small part of simplify_comparison(), into a
new function simplify_compare_const(). The parts are basically where the
comparison RTX code and a constant operand (op1) can be simplified
towards "compare with zero". Note this part leaves op0 untouched, thus
not passed into simplify_compare_const() by reference.
By itself this patch should only be a code reorganization, and changes
nothing to the compiler.
This is part of a small improvement to the compare combining code in the
later patch. During before, the entire case required operand[1] of i3 to
be const0_rtx, now we can try a little tweaking of the code and
constant, and see if it then changes to a cmp zero.
This abstracted patch was bootstrapped and tested independently on i686,
to be sure it was only a reorg.
Index: combine.c
===
--- combine.c (revision 172860)
+++ combine.c (working copy)
@@ -450,6 +450,7 @@
int);
static int recog_for_combine (rtx *, rtx, rtx *);
static rtx gen_lowpart_for_combine (enum machine_mode, rtx);
+static enum rtx_code simplify_compare_const (enum rtx_code, rtx, rtx *);
static enum rtx_code simplify_comparison (enum rtx_code, rtx *, rtx *);
static void update_table_tick (rtx);
static void record_value_for_reg (rtx, rtx, rtx);
@@ -10808,6 +10840,188 @@
return gen_rtx_CLOBBER (omode, const0_rtx);
}
+/* Try to simplify a comparison between OP0 and a constant OP1,
+ where CODE is the comparison code that will be tested, into a
+ (CODE OP0 const0_rtx) form. */
+
+static enum rtx_code
+simplify_compare_const (enum rtx_code code, rtx op0, rtx *pop1)
+{
+ enum machine_mode mode = GET_MODE (op0);
+ unsigned int mode_width = GET_MODE_BITSIZE (mode);
+ HOST_WIDE_INT const_op = INTVAL (*pop1);
+
+ /* Get the constant we are comparing against and turn off all bits
+ not on in our mode. */
+ if (mode != VOIDmode)
+const_op = trunc_int_for_mode (const_op, mode);
+
+ /* If we are comparing against a constant power of two and the value
+ being compared can only have that single bit nonzero (e.g., it was
+ `and'ed with that bit), we can replace this with a comparison
+ with zero. */
+ if (const_op
+ && (code == EQ || code == NE || code == GE || code == GEU
+ || code == LT || code == LTU)
+ && mode_width <= HOST_BITS_PER_WIDE_INT
+ && exact_log2 (const_op) >= 0
+ && nonzero_bits (op0, mode) == (unsigned HOST_WIDE_INT) const_op)
+{
+ code = (code == EQ || code == GE || code == GEU ? NE : EQ);
+ const_op = 0;
+}
+
+ /* Similarly, if we are comparing a value known to be either -1 or
+ 0 with -1, change it to the opposite comparison against zero. */
+ if (const_op == -1
+ && (code == EQ || code == NE || code == GT || code == LE
+ || code == GEU || code == LTU)
+ && num_sign_bit_copies (op0, mode) == mode_width)
+{
+ code = (code == EQ || code == LE || code == GEU ? NE : EQ);
+ const_op = 0;
+}
+
+ /* Do some canonicalizations based on the comparison code. We prefer
+ comparisons against zero and then prefer equality comparisons.
+ If we can reduce the size of a constant, we will do that too. */
+ switch (code)
+{
+case LT:
+ /* < C is equivalent to <= (C - 1) */
+ if (const_op > 0)
+ {
+ const_op -= 1;
+ code = LE;
+ /* ... fall through to LE case below. */
+ }
+ else
+ break;
+
+case LE:
+ /* <= C is equivalent to < (C + 1); we do this for C < 0 */
+ if (const_op < 0)
+ {
+ const_op += 1;
+ code = LT;
+ }
+
+ /* If we are doing a <= 0 comparison on a value known to have
+a zero sign bit, we can replace this with == 0. */
+ else if (const_op == 0
+ && mode_width <= HOST_BITS_PER_WIDE_INT
+ && (nonzero_bits (op0, mode)
+ & ((unsigned HOST_WIDE_INT) 1 << (mode_width - 1)))
+ == 0)
+ code = EQ;
+ break;
+
+case GE:
+ /* >= C is equivalent to > (C - 1). */
+ if (const_op > 0)
+ {
+ const_op -= 1;
+ code = GT;
+ /* ... fall through to GT below. */
+ }
+ else
+ break;
+
+case GT:
+ /* > C is equivalent to >= (C + 1); we do this for C < 0. */
+ if (const_op < 0)
+ {
+ const_op += 1;
+ code = GE;
+ }
+
+ /* If we are doing a > 0 comparison on a value known to have
+a zero sign bit, we can replace this with != 0. */
+ else if (const_op == 0
+ && mode_width <= HOST_BITS_PER_WIDE_INT
+ && (nonzero_bits (op0, mode)
+ & ((unsigned HOST_WIDE_INT) 1 << (mode_width - 1)))
+ == 0)
+ code = NE;
+ break;
+
+case LTU:
+ /* < C is equivalent to <= (C - 1). */
+ if (const_op > 0)
+ {
+ cons
[PATCH] Canonicalize compares in combine [0/3]
Hi, this patch set solves a case seen on ARM when -march= is set to armv6 or above. ARMv6 has a uxtb (unsigned extend byte) instruction, corresponding to a ZERO_EXTEND rtx, which is equivalent to 'and reg, reg, #255'. The problem with 'uxtb' is that, unlike 'and', it does not have a 's' condition flag setting form. Which means that for -march=armv5 and earlier, and+cmp can be combined to 'ands', while under armv6/v7 uxtb+cmp currently ends up as separate insns, causing a performance regression. A possible solution is to add patterns in the ARM backend to match the ZERO_EXTEND compares, and fake them as 'ands'. However, I think a better solution would be to have a chance in combine for the backend to canonicalize the compare insn operands, e.g. for ARM here, a chance to change (zero_extend:SI (subreg:QI (reg:SI ...))) into (and:SI (reg:SI) 255), and match the existing patterns. And to those wondering, yes this is a specific effort towards the crcu8() routine in CoreMark :) This patch is not too large, but I split it into 3 parts to be clearer. Descriptions are in the following mails. The entire patch set has been bootstrapped and regtested for i686 and x86_64 without regressions. ARM cross-testing also completed without regressions, and currently doing a native bootstrap test. Thanks, Chung-Lin 2011-04-22 Chung-Lin Tang * combine.c (simplify_comparison): Abstract out parts into... (simplify_compare_const): ... new function. (try_combine): Generalize parallel arithmetic/compare combining to call simplify_compare_const() and CANONICALIZE_COMPARE(). * config/arm/arm.c (arm_canonicalize_comparison): Add case to canonicalize left operand from ZERO_EXTEND to AND. testsuite/ * gcc.target/arm/combine-movs.c: New. * gcc.target/arm/unsigned-extend-2.c: New.
(build) Patch to fix cp/cfns.gperf building issues
This patch fixes a building annoyance that I had when building on a new
machine (an x86_64 gnu/linux box).
The building failed. It was down to two problems:
* due to how I got a copy of the GCC source code on the machine, the timestamp
of each source file was the timestamp of when it was copied to the machine (ie,
a random timestamp from the point of view of the building system). This caused
the build system to decide that $(srcdir)/cp/cfns.h needed to be rebuilt from
$(srcdir)/cp/cfns.gperf (it didn't, obviously; the source code was trunk with
no changes).
* when the automated rebuild failed because gperf was not there, it also
created
an empty cp/cfns.h, basically corrupting my source tree. Further attempts to
rebuild (with or without gperf) would then fail due to a missing definition of
"libc_name_p" (because cp/cfns.h now existed, and was newer than cp/cfns.gperf,
it wouldn't be rebuilt, and I was stuck with the empty cp/cfns.h). Searching
on the internet, I found that a number of people got stuck at this stage and
couldn't finish their build. So, rather than just manually fixing my source
tree, I'm posting a patch that will remove the problems at the root.
This patch fixes both problems, making the build more robust:
* it only rebuilds cp/cfns.h when a specific command ("make rebuild-cp-cfns")
is used.
According to the ChangeLogs, cp/cfns.gperf was edited about 5 times in 10
years,
so it does not seem unreasonable to require developers/maintainers to use an
explicit
command to rebuild cp/cfns.h from cp/cfns.gperf for the once-every-two-years
occasion when
it is changed. I documented the process clearly in cfns.gperf itself.
This makes the build more robust for end users, who are not bugged by
timestamp
issues in the source tree causing unexpected rebuilds or complications
requiring
gperf.
In general, I personally feel that the building system should not depend on
the relative
timestamps of source files unless it's doing something in "maintainer mode"
where it's being
explicitly asked to rebuild one source file from the other. The average
user who downloads
the GCC source code to build it should not be expected to keep the
timestamps of each
source file religiously unchanged! Timestamps may change as the source code
is moved
around by users and the building system should not have a problem with that.
* it fails gracefully when the rebuild is triggered and gperf is not
available. Instead
of creating en empty cp/cfns.h file, it creates no file at all, so that if
you then install
gperf, it will rebuild cp/cfns.h correctly, and if you don't, you'll keep
getting the
error the gperf is not available (not an error about libc_name_p not being
defined),
which is the correct one.
Ok to commit ?
Thanks
Index: cfns.gperf
===
--- cfns.gperf (revision 172858)
+++ cfns.gperf (working copy)
@@ -15,7 +15,18 @@ 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] Fix associate_plusminus A + ~A optimization (PR tree-optimization/48717)
On Fri, Apr 22, 2011 at 3:41 PM, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase associate_plusminus optimizes
> A + ~A into INTEGER_CST { -1, -1 } with type unsigned short, which
> confuses enough following passes on (int) cast of that into
> assuming it is -1 instead of 65535.
Ick.
> Fixed by using build_int_cst_type, which is what e.g. fold-const.c
> uses when optimizing X + ~X.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk
> and 4.6 (where the bug is just latent)? 4.5 didn't have
> associate_plusminus.
Ok for both.
build_int_cst looks seriously broken, I think we want to make it
an alias of build_int_cst_type, or rather call that from
build_int_cst.
Thanks,
Richard.
> 2011-04-22 Jakub Jelinek
>
> PR tree-optimization/48717
> * tree-ssa-forwprop.c (associate_plusminus): For A + ~A and
> ~A + A optimizations use build_int_cst_type instead of build_int_cst.
>
> * gcc.c-torture/execute/pr48717.c: New test.
>
> --- gcc/tree-ssa-forwprop.c.jj 2011-04-01 23:09:21.0 +0200
> +++ gcc/tree-ssa-forwprop.c 2011-04-22 11:57:10.0 +0200
> @@ -1815,7 +1815,7 @@ associate_plusminus (gimple stmt)
> {
> /* ~A + A -> -1. */
> code = INTEGER_CST;
> - rhs1 = build_int_cst (TREE_TYPE (rhs2), -1);
> + rhs1 = build_int_cst_type (TREE_TYPE (rhs2), -1);
> rhs2 = NULL_TREE;
> gimple_assign_set_rhs_with_ops (&gsi, code, rhs1, NULL_TREE);
> gcc_assert (gsi_stmt (gsi) == stmt);
> @@ -1915,7 +1915,7 @@ associate_plusminus (gimple stmt)
> {
> /* A + ~A -> -1. */
> code = INTEGER_CST;
> - rhs1 = build_int_cst (TREE_TYPE (rhs1), -1);
> + rhs1 = build_int_cst_type (TREE_TYPE (rhs1), -1);
> rhs2 = NULL_TREE;
> gimple_assign_set_rhs_with_ops (&gsi, code, rhs1, NULL_TREE);
> gcc_assert (gsi_stmt (gsi) == stmt);
> --- gcc/testsuite/gcc.c-torture/execute/pr48717.c.jj 2011-04-22
> 11:59:23.0 +0200
> +++ gcc/testsuite/gcc.c-torture/execute/pr48717.c 2011-04-22
> 11:58:48.0 +0200
> @@ -0,0 +1,26 @@
> +/* PR tree-optimization/48717 */
> +
> +extern void abort (void);
> +
> +int v = 1, w;
> +
> +unsigned short
> +foo (unsigned short x, unsigned short y)
> +{
> + return x + y;
> +}
> +
> +void
> +bar (void)
> +{
> + v = foo (~w, w);
> +}
> +
> +int
> +main ()
> +{
> + bar ();
> + if (v != (unsigned short) -1)
> + abort ();
> + return 0;
> +}
>
> Jakub
>
Re: better wpa [1/n]: merge types during read-in
> > Yes, that's very likely. If we'd get around to re-do the LTO option saving > > code > > we might want to forbid -g0 compile and -g link (dropping -g at link > > time as soon > > as we see a single module compiled with -g0). Then we can free some more > > stuff, at least with -g0 - though I'm not sure -g0 matters in practice. > > Don't know if it matters to care about it terribly much, but definitely > default > mozilla builds are -g0. > > I assume that now we want to be more selective about what to save for -g and > also > try to push more stuff to bypass WPA. I don't see need for all the type > merging > for stuff that is only referred from debug info. It will be fun to get this > done > however. (either by early debug info output that goes to extra section and is > distributed to ltrans same way as we distribute bodies or by some other means) But overall 2GB of IL for Mozilla is not that bad. Ohter compilers consume easilly more. However we need to figure out where the other 4GB is going (mmap pool is obviously just part of it, probably hashtables consume good part of it, too) and do something about those 10 minutes of hashtable lookups needed to read and write out data. Problem is amount of data we produce for ltrans, that is partly because we ship debug info into units that won't output it. I guess I should look into perf and try to produce low overhead profile with backtraces so we know what hashtables are worse than others. Though we probably won't see there much surprises. Honza
Re: better wpa [1/n]: merge types during read-in
> Yes, that's very likely. If we'd get around to re-do the LTO option saving > code > we might want to forbid -g0 compile and -g link (dropping -g at link > time as soon > as we see a single module compiled with -g0). Then we can free some more > stuff, at least with -g0 - though I'm not sure -g0 matters in practice. Don't know if it matters to care about it terribly much, but definitely default mozilla builds are -g0. I assume that now we want to be more selective about what to save for -g and also try to push more stuff to bypass WPA. I don't see need for all the type merging for stuff that is only referred from debug info. It will be fun to get this done however. (either by early debug info output that goes to extra section and is distributed to ltrans same way as we distribute bodies or by some other means) You had the tree code memory use statistics patch. If you send me pointer or commit it, I can generate tree code statistics. Honza > > Maybe we can shift numbers back from ipa lto decl in to ipa lto decl > merge by some > timevar adjustments? > > Richard. > > > Honza > >
Re: better wpa [1/n]: merge types during read-in
On Fri, Apr 22, 2011 at 1:58 PM, Jan Hubicka wrote:
> Hi,
> I run the patch on Mozilla. W/o the patch it is:
> Execution times (seconds)
> garbage collection : 20.19 ( 3%) usr 0.02 ( 0%) sys 20.22 ( 3%) wall
> 0 kB ( 0%) ggc
> callgraph optimization: 3.53 ( 1%) usr 0.01 ( 0%) sys 3.53 ( 1%) wall
> 15248 kB ( 1%) ggc
> varpool construction : 0.77 ( 0%) usr 0.02 ( 0%) sys 0.80 ( 0%) wall
> 51607 kB ( 4%) ggc
> ipa cp : 2.12 ( 0%) usr 0.10 ( 1%) sys 2.23 ( 0%) wall
> 119701 kB (10%) ggc
> ipa lto gimple in : 0.07 ( 0%) usr 0.02 ( 0%) sys 0.07 ( 0%) wall
> 0 kB ( 0%) ggc
> ipa lto gimple out : 11.63 ( 2%) usr 1.01 ( 8%) sys 12.63 ( 2%) wall
> 0 kB ( 0%) ggc
> ipa lto decl in : 182.15 (28%) usr 4.06 (32%) sys 188.10 (28%) wall
> 392863 kB (31%) ggc
> ipa lto decl out : 149.86 (23%) usr 0.32 ( 3%) sys 150.25 (22%) wall
> 0 kB ( 0%) ggc
> ipa lto decl init I/O : 0.14 ( 0%) usr 0.03 ( 0%) sys 0.16 ( 0%) wall
> 31 kB ( 0%) ggc
> ipa lto cgraph I/O : 2.09 ( 0%) usr 0.27 ( 2%) sys 2.37 ( 0%) wall
> 428623 kB (34%) ggc
> ipa lto decl merge : 219.70 (33%) usr 1.93 (15%) sys 221.75 (33%) wall
> 162687 kB (13%) ggc
> ipa lto cgraph merge : 2.68 ( 0%) usr 0.00 ( 0%) sys 2.69 ( 0%) wall
> 15895 kB ( 1%) ggc
> whopr wpa : 1.65 ( 0%) usr 0.04 ( 0%) sys 1.71 ( 0%) wall
> 1 kB ( 0%) ggc
> whopr wpa I/O : 2.20 ( 0%) usr 4.55 (36%) sys 7.20 ( 1%) wall
> 0 kB ( 0%) ggc
> ipa reference : 4.12 ( 1%) usr 0.00 ( 0%) sys 4.09 ( 1%) wall
> 0 kB ( 0%) ggc
> ipa profile : 0.18 ( 0%) usr 0.00 ( 0%) sys 0.17 ( 0%) wall
> 0 kB ( 0%) ggc
> ipa pure const : 3.15 ( 0%) usr 0.04 ( 0%) sys 3.19 ( 0%) wall
> 0 kB ( 0%) ggc
> parser : 1.56 ( 0%) usr 0.00 ( 0%) sys 1.56 ( 0%) wall
> 37684 kB ( 3%) ggc
> inline heuristics : 47.26 ( 7%) usr 0.05 ( 0%) sys 47.33 ( 7%) wall
> 21988 kB ( 2%) ggc
> callgraph verifier : 0.42 ( 0%) usr 0.04 ( 0%) sys 0.47 ( 0%) wall
> 0 kB ( 0%) ggc
> varconst : 0.02 ( 0%) usr 0.01 ( 0%) sys 0.06 ( 0%) wall
> 0 kB ( 0%) ggc
> unaccounted todo : 1.19 ( 0%) usr 0.00 ( 0%) sys 1.17 ( 0%) wall
> 0 kB ( 0%) ggc
> TOTAL : 657.07 12.64 672.26
> 1247550 kB
>
> note that total GGC use seems obviously wrong. The peak GGC report reads: {GC
> 4079042k -> 4043085k}
>
> with the patch
> Execution times (seconds)
> garbage collection : 13.85 ( 3%) usr 0.02 ( 0%) sys 13.88 ( 3%) wall
> 0 kB ( 0%) ggc
> callgraph optimization: 2.40 ( 0%) usr 0.00 ( 0%) sys 2.40 ( 0%) wall
> 15248 kB ( 1%) ggc
> varpool construction : 0.69 ( 0%) usr 0.03 ( 0%) sys 0.71 ( 0%) wall
> 51621 kB ( 4%) ggc
> ipa cp : 1.86 ( 0%) usr 0.11 ( 1%) sys 1.97 ( 0%) wall
> 119697 kB ( 9%) ggc
> ipa lto gimple in : 0.04 ( 0%) usr 0.02 ( 0%) sys 0.06 ( 0%) wall
> 0 kB ( 0%) ggc
> ipa lto gimple out : 11.86 ( 2%) usr 0.92 ( 9%) sys 12.80 ( 2%) wall
> 0 kB ( 0%) ggc
> ipa lto decl in : 287.52 (54%) usr 3.49 (35%) sys 291.13 (54%) wall
> 713694 kB (51%) ggc
> ipa lto decl out : 127.76 (24%) usr 0.94 ( 9%) sys 128.79 (24%) wall
> 0 kB ( 0%) ggc
> ipa lto decl init I/O : 0.13 ( 0%) usr 0.02 ( 0%) sys 0.15 ( 0%) wall
> 31 kB ( 0%) ggc
> ipa lto cgraph I/O : 1.66 ( 0%) usr 0.29 ( 3%) sys 1.94 ( 0%) wall
> 428623 kB (30%) ggc
> ipa lto decl merge : 18.12 ( 3%) usr 0.13 ( 1%) sys 18.26 ( 3%) wall
> 978 kB ( 0%) ggc
> ipa lto cgraph merge : 1.90 ( 0%) usr 0.00 ( 0%) sys 1.91 ( 0%) wall
> 15143 kB ( 1%) ggc
> whopr wpa : 1.99 ( 0%) usr 0.05 ( 0%) sys 2.01 ( 0%) wall
> 1 kB ( 0%) ggc
> whopr wpa I/O : 2.40 ( 0%) usr 3.77 (38%) sys 6.47 ( 1%) wall
> 0 kB ( 0%) ggc
> ipa reference : 4.56 ( 1%) usr 0.00 ( 0%) sys 4.58 ( 1%) wall
> 0 kB ( 0%) ggc
> ipa profile : 0.16 ( 0%) usr 0.00 ( 0%) sys 0.15 ( 0%) wall
> 0 kB ( 0%) ggc
> ipa pure const : 3.33 ( 1%) usr 0.03 ( 0%) sys 3.36 ( 1%) wall
> 0 kB ( 0%) ggc
> parser : 1.85 ( 0%) usr 0.03 ( 0%) sys 1.87 ( 0%) wall
> 37684 kB ( 3%) ggc
> inline heuristics : 47.34 ( 9%) usr 0.04 ( 0%) sys 47.42 ( 9%) wall
> 21988 kB ( 2%) ggc
> tree CFG construction : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
> 1 kB ( 0%) ggc
> callgraph verifier : 0.45 ( 0%) usr 0.05 ( 0%) sys 0.55 ( 0%) wall
> 0 kB ( 0%) ggc
> varconst : 0.00 ( 0%) usr 0.03 ( 0%) sys 0.03 ( 0%) wall
> 0 kB ( 0%) ggc
> unaccounted todo : 1.38 ( 0%) usr 0.00 ( 0%) sys 1.37 ( 0%) wall
[committed] Fix default(none) diagnostic about block local statics (PR c/48716)
Hi!
OpenMP 3.0 says that static variables that are declared in a scope inside
the construct are predetermined shared. OpenMP 2.5 was silent about it.
I've asked on OpenMP forum about the local externs, if those should be
predetermined shared too, I'll drop the && !DECL_EXTERNAL (t).
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
and 4.6.
2011-04-22 Jakub Jelinek
PR c/48716
* gimplify.c (gimplify_bind_expr): Mark as GOVD_LOCAL also
TREE_STATIC variables declared inside of some OpenMP construct.
* gcc.dg/gomp/pr48716.c: New test.
* g++.dg/gomp/pr48716.C: New test.
--- gcc/gimplify.c.jj 2011-04-18 11:28:05.0 +0200
+++ gcc/gimplify.c 2011-04-22 12:52:07.0 +0200
@@ -1144,7 +1144,7 @@ gimplify_bind_expr (tree *expr_p, gimple
struct gimplify_omp_ctx *ctx = gimplify_omp_ctxp;
/* Mark variable as local. */
- if (ctx && !is_global_var (t)
+ if (ctx && !DECL_EXTERNAL (t)
&& (! DECL_SEEN_IN_BIND_EXPR_P (t)
|| splay_tree_lookup (ctx->variables,
(splay_tree_key) t) == NULL))
--- gcc/testsuite/gcc.dg/gomp/pr48716.c.jj 2011-04-22 13:21:32.0
+0200
+++ gcc/testsuite/gcc.dg/gomp/pr48716.c 2011-04-22 13:21:13.0 +0200
@@ -0,0 +1,24 @@
+/* PR c/48716 */
+/* { dg-do compile } */
+/* { dg-options "-fopenmp" } */
+
+int
+main (void)
+{
+ #pragma omp parallel default(none)
+ {
+static int s;
+int t = 0;
+#pragma omp atomic
+s++;
+t++;
+ }
+ #pragma omp task default(none)
+ {
+static int s;
+int t = 0;
+#pragma omp atomic
+s++;
+t++;
+ }
+}
--- gcc/testsuite/g++.dg/gomp/pr48716.C.jj 2011-04-22 13:21:49.0
+0200
+++ gcc/testsuite/g++.dg/gomp/pr48716.C 2011-04-22 13:21:59.0 +0200
@@ -0,0 +1,24 @@
+// PR c/48716
+// { dg-do compile }
+// { dg-options "-fopenmp" }
+
+int
+main (void)
+{
+ #pragma omp parallel default(none)
+ {
+static int s;
+int t = 0;
+#pragma omp atomic
+s++;
+t++;
+ }
+ #pragma omp task default(none)
+ {
+static int s;
+int t = 0;
+#pragma omp atomic
+s++;
+t++;
+ }
+}
Jakub
[PATCH] Fix associate_plusminus A + ~A optimization (PR tree-optimization/48717)
Hi!
On the following testcase associate_plusminus optimizes
A + ~A into INTEGER_CST { -1, -1 } with type unsigned short, which
confuses enough following passes on (int) cast of that into
assuming it is -1 instead of 65535.
Fixed by using build_int_cst_type, which is what e.g. fold-const.c
uses when optimizing X + ~X.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk
and 4.6 (where the bug is just latent)? 4.5 didn't have
associate_plusminus.
2011-04-22 Jakub Jelinek
PR tree-optimization/48717
* tree-ssa-forwprop.c (associate_plusminus): For A + ~A and
~A + A optimizations use build_int_cst_type instead of build_int_cst.
* gcc.c-torture/execute/pr48717.c: New test.
--- gcc/tree-ssa-forwprop.c.jj 2011-04-01 23:09:21.0 +0200
+++ gcc/tree-ssa-forwprop.c 2011-04-22 11:57:10.0 +0200
@@ -1815,7 +1815,7 @@ associate_plusminus (gimple stmt)
{
/* ~A + A -> -1. */
code = INTEGER_CST;
- rhs1 = build_int_cst (TREE_TYPE (rhs2), -1);
+ rhs1 = build_int_cst_type (TREE_TYPE (rhs2), -1);
rhs2 = NULL_TREE;
gimple_assign_set_rhs_with_ops (&gsi, code, rhs1, NULL_TREE);
gcc_assert (gsi_stmt (gsi) == stmt);
@@ -1915,7 +1915,7 @@ associate_plusminus (gimple stmt)
{
/* A + ~A -> -1. */
code = INTEGER_CST;
- rhs1 = build_int_cst (TREE_TYPE (rhs1), -1);
+ rhs1 = build_int_cst_type (TREE_TYPE (rhs1), -1);
rhs2 = NULL_TREE;
gimple_assign_set_rhs_with_ops (&gsi, code, rhs1, NULL_TREE);
gcc_assert (gsi_stmt (gsi) == stmt);
--- gcc/testsuite/gcc.c-torture/execute/pr48717.c.jj2011-04-22
11:59:23.0 +0200
+++ gcc/testsuite/gcc.c-torture/execute/pr48717.c 2011-04-22
11:58:48.0 +0200
@@ -0,0 +1,26 @@
+/* PR tree-optimization/48717 */
+
+extern void abort (void);
+
+int v = 1, w;
+
+unsigned short
+foo (unsigned short x, unsigned short y)
+{
+ return x + y;
+}
+
+void
+bar (void)
+{
+ v = foo (~w, w);
+}
+
+int
+main ()
+{
+ bar ();
+ if (v != (unsigned short) -1)
+abort ();
+ return 0;
+}
Jakub
Re: [PATCH PING] c++-specific bits of tree-slimming patches
On Fri, Apr 22, 2011 at 11:12:01AM +0200, Richard Guenther wrote: > On Fri, Apr 22, 2011 at 8:13 AM, Mike Stump wrote: > > Unsurprising... It will never fail during testsuite run, and won't > > always fail during a bootstrap. > > > >> I can't think what the comment would be talking about with pointers > >> not providing a stable order; I don't see anything that would rely > >> on that. > > > > http://gcc.gnu.org/ml/gcc/2005-04/msg00161.html > > > > has the details of why the code was put in. Essentially, the Ada > > boostrap on x86 linux. What's worse is, at the time, it would only > > occasionally fail, so, a bootstrap that works won't prove anything. > > Well, unless we are not walking a pointer-based hashtable I don't see > how this matters here. I can't see the pointer traversal, either--unless there's some subtlety in how things are added to the goto_queue. I'm going to leave the code alone for the moment. > To Nathan: yes, UNKNOWN_LOCATION would be correct. Whoever then sets > the label should adjust it accordingly. Will commit with that change in build_case_label, then. I will leave the location-setting to a separate commit, if any. -Nathan
[PATCH, C++] Remove unused cp_fold_obj_type_ref
Hi,
last year I removed the last use of cp_fold_obj_type_ref (which was a
language hook) but forgot to remove the function itself. So I'm about
to do it now.
I'm currently bootstrapping and testing the following patch. I
consider it obvious enough to commit it myself on Tuesday if it
passes.
Thanks,
Martin
2011-04-22 Martin Jambor
* class.c (cp_fold_obj_type_ref): Remove.
* cp-tree.h (cp_fold_obj_type_ref): Remove declaration.
Index: src/gcc/cp/class.c
===
--- src.orig/gcc/cp/class.c
+++ src/gcc/cp/class.c
@@ -8377,32 +8377,4 @@ build_rtti_vtbl_entries (tree binfo, vtb
CONSTRUCTOR_APPEND_ELT (vid->inits, NULL_TREE, init);
}
-/* Fold a OBJ_TYPE_REF expression to the address of a function.
- KNOWN_TYPE carries the true type of OBJ_TYPE_REF_OBJECT(REF). */
-
-tree
-cp_fold_obj_type_ref (tree ref, tree known_type)
-{
- HOST_WIDE_INT index = tree_low_cst (OBJ_TYPE_REF_TOKEN (ref), 1);
- HOST_WIDE_INT i = 0;
- tree v = BINFO_VIRTUALS (TYPE_BINFO (known_type));
- tree fndecl;
-
- while (i != index)
-{
- i += (TARGET_VTABLE_USES_DESCRIPTORS
- ? TARGET_VTABLE_USES_DESCRIPTORS : 1);
- v = TREE_CHAIN (v);
-}
-
- fndecl = BV_FN (v);
-
-#ifdef ENABLE_CHECKING
- gcc_assert (tree_int_cst_equal (OBJ_TYPE_REF_TOKEN (ref),
- DECL_VINDEX (fndecl)));
-#endif
-
- return build_address (fndecl);
-}
-
#include "gt-cp-class.h"
Index: src/gcc/cp/cp-tree.h
===
--- src.orig/gcc/cp/cp-tree.h
+++ src/gcc/cp/cp-tree.h
@@ -4713,7 +4713,6 @@ extern void note_name_declared_in_class
extern tree get_vtbl_decl_for_binfo(tree);
extern void debug_class(tree);
extern void debug_thunks (tree);
-extern tree cp_fold_obj_type_ref (tree, tree);
extern void set_linkage_according_to_type (tree, tree);
extern void determine_key_method (tree);
extern void check_for_override (tree, tree);
[PATCH, PR 48585] Do not create edges when materializing zombie clones
Hi,
the following one-liner fixes LTO build of SPEC 2006 483.xalancbmk.
The problem is that code that adds new call graph edges for
newly-direct calls is triggered for "zombie clones," clones which
exist only to facilitate materialization of their descendant clones
and will be thrown away afterwards, and which do not have and should
not have any outgoing edges.
I have successfully bootstrapped and tested this patch on
x86-64-linux. I have also verified that 483.xalancbmk builds (with
-g0) with it. It was approved by Honza in bugzilla and it just looks
so safe that I'm going to commit it now even though it's Friday :-)
Thanks,
Martin
2011-04-22 Martin Jambor
PR middle-end/48585
* tree-inline.c (copy_bb): Create new edges only for analyzed
nodes.
Index: src/gcc/tree-inline.c
===
--- src.orig/gcc/tree-inline.c
+++ src/gcc/tree-inline.c
@@ -1725,6 +1725,7 @@ copy_bb (copy_body_data *id, basic_block
if ((!edge
|| (edge->indirect_inlining_edge
&& id->transform_call_graph_edges == CB_CGE_MOVE_CLONES))
+ && id->dst_node->analyzed
&& (fn = gimple_call_fndecl (stmt)) != NULL)
{
struct cgraph_node *dest = cgraph_get_node (fn);
Re: better wpa [1/n]: merge types during read-in
Hi,
I run the patch on Mozilla. W/o the patch it is:
Execution times (seconds)
garbage collection: 20.19 ( 3%) usr 0.02 ( 0%) sys 20.22 ( 3%) wall
0 kB ( 0%) ggc
callgraph optimization: 3.53 ( 1%) usr 0.01 ( 0%) sys 3.53 ( 1%) wall
15248 kB ( 1%) ggc
varpool construction : 0.77 ( 0%) usr 0.02 ( 0%) sys 0.80 ( 0%) wall
51607 kB ( 4%) ggc
ipa cp: 2.12 ( 0%) usr 0.10 ( 1%) sys 2.23 ( 0%) wall
119701 kB (10%) ggc
ipa lto gimple in : 0.07 ( 0%) usr 0.02 ( 0%) sys 0.07 ( 0%) wall
0 kB ( 0%) ggc
ipa lto gimple out: 11.63 ( 2%) usr 1.01 ( 8%) sys 12.63 ( 2%) wall
0 kB ( 0%) ggc
ipa lto decl in : 182.15 (28%) usr 4.06 (32%) sys 188.10 (28%) wall
392863 kB (31%) ggc
ipa lto decl out : 149.86 (23%) usr 0.32 ( 3%) sys 150.25 (22%) wall
0 kB ( 0%) ggc
ipa lto decl init I/O : 0.14 ( 0%) usr 0.03 ( 0%) sys 0.16 ( 0%) wall
31 kB ( 0%) ggc
ipa lto cgraph I/O: 2.09 ( 0%) usr 0.27 ( 2%) sys 2.37 ( 0%) wall
428623 kB (34%) ggc
ipa lto decl merge: 219.70 (33%) usr 1.93 (15%) sys 221.75 (33%) wall
162687 kB (13%) ggc
ipa lto cgraph merge : 2.68 ( 0%) usr 0.00 ( 0%) sys 2.69 ( 0%) wall
15895 kB ( 1%) ggc
whopr wpa : 1.65 ( 0%) usr 0.04 ( 0%) sys 1.71 ( 0%) wall
1 kB ( 0%) ggc
whopr wpa I/O : 2.20 ( 0%) usr 4.55 (36%) sys 7.20 ( 1%) wall
0 kB ( 0%) ggc
ipa reference : 4.12 ( 1%) usr 0.00 ( 0%) sys 4.09 ( 1%) wall
0 kB ( 0%) ggc
ipa profile : 0.18 ( 0%) usr 0.00 ( 0%) sys 0.17 ( 0%) wall
0 kB ( 0%) ggc
ipa pure const: 3.15 ( 0%) usr 0.04 ( 0%) sys 3.19 ( 0%) wall
0 kB ( 0%) ggc
parser: 1.56 ( 0%) usr 0.00 ( 0%) sys 1.56 ( 0%) wall
37684 kB ( 3%) ggc
inline heuristics : 47.26 ( 7%) usr 0.05 ( 0%) sys 47.33 ( 7%) wall
21988 kB ( 2%) ggc
callgraph verifier: 0.42 ( 0%) usr 0.04 ( 0%) sys 0.47 ( 0%) wall
0 kB ( 0%) ggc
varconst : 0.02 ( 0%) usr 0.01 ( 0%) sys 0.06 ( 0%) wall
0 kB ( 0%) ggc
unaccounted todo : 1.19 ( 0%) usr 0.00 ( 0%) sys 1.17 ( 0%) wall
0 kB ( 0%) ggc
TOTAL : 657.0712.64 672.26
1247550 kB
note that total GGC use seems obviously wrong. The peak GGC report reads: {GC
4079042k -> 4043085k}
with the patch
Execution times (seconds)
garbage collection: 13.85 ( 3%) usr 0.02 ( 0%) sys 13.88 ( 3%) wall
0 kB ( 0%) ggc
callgraph optimization: 2.40 ( 0%) usr 0.00 ( 0%) sys 2.40 ( 0%) wall
15248 kB ( 1%) ggc
varpool construction : 0.69 ( 0%) usr 0.03 ( 0%) sys 0.71 ( 0%) wall
51621 kB ( 4%) ggc
ipa cp: 1.86 ( 0%) usr 0.11 ( 1%) sys 1.97 ( 0%) wall
119697 kB ( 9%) ggc
ipa lto gimple in : 0.04 ( 0%) usr 0.02 ( 0%) sys 0.06 ( 0%) wall
0 kB ( 0%) ggc
ipa lto gimple out: 11.86 ( 2%) usr 0.92 ( 9%) sys 12.80 ( 2%) wall
0 kB ( 0%) ggc
ipa lto decl in : 287.52 (54%) usr 3.49 (35%) sys 291.13 (54%) wall
713694 kB (51%) ggc
ipa lto decl out : 127.76 (24%) usr 0.94 ( 9%) sys 128.79 (24%) wall
0 kB ( 0%) ggc
ipa lto decl init I/O : 0.13 ( 0%) usr 0.02 ( 0%) sys 0.15 ( 0%) wall
31 kB ( 0%) ggc
ipa lto cgraph I/O: 1.66 ( 0%) usr 0.29 ( 3%) sys 1.94 ( 0%) wall
428623 kB (30%) ggc
ipa lto decl merge: 18.12 ( 3%) usr 0.13 ( 1%) sys 18.26 ( 3%) wall
978 kB ( 0%) ggc
ipa lto cgraph merge : 1.90 ( 0%) usr 0.00 ( 0%) sys 1.91 ( 0%) wall
15143 kB ( 1%) ggc
whopr wpa : 1.99 ( 0%) usr 0.05 ( 0%) sys 2.01 ( 0%) wall
1 kB ( 0%) ggc
whopr wpa I/O : 2.40 ( 0%) usr 3.77 (38%) sys 6.47 ( 1%) wall
0 kB ( 0%) ggc
ipa reference : 4.56 ( 1%) usr 0.00 ( 0%) sys 4.58 ( 1%) wall
0 kB ( 0%) ggc
ipa profile : 0.16 ( 0%) usr 0.00 ( 0%) sys 0.15 ( 0%) wall
0 kB ( 0%) ggc
ipa pure const: 3.33 ( 1%) usr 0.03 ( 0%) sys 3.36 ( 1%) wall
0 kB ( 0%) ggc
parser: 1.85 ( 0%) usr 0.03 ( 0%) sys 1.87 ( 0%) wall
37684 kB ( 3%) ggc
inline heuristics : 47.34 ( 9%) usr 0.04 ( 0%) sys 47.42 ( 9%) wall
21988 kB ( 2%) ggc
tree CFG construction : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
1 kB ( 0%) ggc
callgraph verifier: 0.45 ( 0%) usr 0.05 ( 0%) sys 0.55 ( 0%) wall
0 kB ( 0%) ggc
varconst : 0.00 ( 0%) usr 0.03 ( 0%) sys 0.03 ( 0%) wall
0 kB ( 0%) ggc
unaccounted todo : 1.38 ( 0%) usr 0.00 ( 0%) sys 1.37 ( 0%) wall
0 kB ( 0%) ggc
TOTAL : 531.6610.05 542.31
1405930 kB
and peak memory use 2688637k -> 2136908k. So 50% GGC memory (we need another
about 4G for non-GGC memory, probaly largely in mmap pool) and
Re: fix up hot/cold partitioning on ports that don't have long conditional branches
> This patch fixes up hot/cold partitioning on ports that don't have long > conditional branches. I'll note that the entire file has lots of other > jump optimizations that are suspect. Do you have a testcase for one of the ports in the tree? Note that parameters of function must be documented in the head comment. The patch contains long lines. The ChangeLog entry doesn't look correct (relax_delay_slots mentioned twice, no mention of the new parameter of follow_jumps, etc). How was the patch tested? Please generate patches with diff -p. -- Eric Botcazou
Re: [PATCH PING] c++-specific bits of tree-slimming patches
On Fri, Apr 22, 2011 at 8:13 AM, Mike Stump wrote: > On Apr 21, 2011, at 9:59 PM, Jason Merrill wrote: >> On 04/21/2011 10:55 PM, Nathan Froyd wrote: >>> On Thu, Apr 21, 2011 at 10:49:05PM -0400, Jason Merrill wrote: Hunh. How does that work? They fill in CASE_LABEL later? Can that be changed? >>> >>> Yeah, tree-eh.c:lower_try_finally_switch. I don't know how easy it is >>> to fix; it certainly looks non-trivial. >> >> Well, I tried adjusting it and regression testing seems fine so far. > > Unsurprising... It will never fail during testsuite run, and won't always > fail during a bootstrap. > >> I can't think what the comment would be talking about with pointers not >> providing a stable order; I don't see anything that would rely on that. > > http://gcc.gnu.org/ml/gcc/2005-04/msg00161.html > > has the details of why the code was put in. Essentially, the Ada boostrap on > x86 linux. What's worse is, at the time, it would only occasionally fail, > so, a bootstrap that works won't prove anything. Well, unless we are not walking a pointer-based hashtable I don't see how this matters here. To Nathan: yes, UNKNOWN_LOCATION would be correct. Whoever then sets the label should adjust it accordingly. Richard.
Re: Fix 20020425-1.c
On Fri, Apr 22, 2011 at 3:40 AM, Mike Stump wrote: > Ping? The patch makes the testcase pointless. It also makes the AST differ more from the source form, so I don't think it's a particularly good idea. I think we shouldn't worry about this kind of testsuite fails. Richard. > On Apr 12, 2011, at 4:36 PM, Mike Stump wrote: > >> This fixes 20020425-1.c when the compiler under test is built with -O0 and >> we're on a machine with an 8 meg stack. >> >> Ok? >> >> 2011-04-12 Mike Stump >> >> * c-typeck.c (c_finish_if_stmt): Fold result. >> * fold-const.c (fold_ternary_loc): Handle an empty else. >> >> > >
Re: RFA: Improve jump threading #2 of N
On Thu, Apr 21, 2011 at 5:47 PM, Jeff Law wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > For some dumb reason I thought handling threading through a SWITCH_EXPR > was hard in VRP; that's definitely not the case, it's no more difficult > than handling a COND_EXPR. > > This patch allows tree-vrp.c to thread through a SWITCH_EXPR when we > know the switch index via a particular path. Most of these would have > eventually been caught by DOM, but we get to pick up more secondary > effects if we can catch them in VRP. > > Bootstrapped and regression tested on x86_64-unknown-linux-gnu. OK for > trunk? Ok. Can you add a testcase? Thanks, Richard. > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJNsFGKAAoJEBRtltQi2kC7wP4IAJZ6e/jF5WAnFdG5/G6lWdEp > D1mBlaFvrSgAXp/Qx9y8uLQfnpzSvcgb59naTH2p+rDILjAs9Bw1eXZN0MCwTN4H > tylFm3w4a9BMzHbzgiwGzDBTkUyzIQyQ1XzqSHbOTWtzEuFGbAmRzSgDoFPbZEPD > cWXsh7yRLr/aqOFLCoEbN/Wp87aBDSXi+I7d5rU+la97En3FWBSNku84dZf1F+8C > 9qW4wCW7lX1LVnWy3LmeSxXf0k9JmJGkUvdmSr2TYtZVPvPLqHg97NOWG9CAfUVO > cTZW5QOFuyEGg/vbYOFmfWRI7uw+YjggV/v0LzUYjRV00fj+rygjgUfgA5f3rGA= > =NPtm > -END PGP SIGNATURE- >
Re: new option -Wno-maybe-uninitialized
On Thu, Apr 21, 2011 at 7:43 PM, Xinliang David Li wrote: > On Thu, Apr 21, 2011 at 10:21 AM, Jeff Law wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 04/07/11 18:24, Xinliang David Li wrote: >>> Hi, >>> >>> the following patch implements the option to fine control the emitted >>> warnings -- >>> 1) allow suppressing warnings for use of values that may be >>> uninitialized. Definitely uninitialized values that may be used >>> warning is not affected >>> 2) allow fine grain control on promotion of warnings to errors: >>> -Wno-error=maybe-uninitialized >>> >>> This is useful for users who only care about definite uninitialized >>> variable warnings. >> I'm definitely in favor of having the ability for the user to be able to >> fine tune the warnings they want. However, I have some concerns. >> >> First, I'm not sure how reconcile the may vs must inconsistency. We can >> have an object which is used in a real statement in the IL, which we >> currently would classify as must-be-uninitialized, even if the path >> leading to the statement is unexecutable. I guess I want to find >> better ways to describe this kind of stuff in our documentation and >> switch names > > There are three different kind of uninit warnings: > > 1) definitely uninitialized, and the use the variable dominates the > exit -- this is the must be used uninitialized case > 2) definitely uninitialized, but the use may not be executed at runtime; > 3) Only initialized in some paths from entry to the use (the use may > or may not be executed). > > Currently 2) and 3) uses the same warning message, which may be misleading. > > The proposed new option only controls 3). > >> >> Second, I'm concerned about changing the default behaviour of >> - -Wuninitialized. I don't think we ever reached a consensus on that >> issue last time we tried to hash through this stuff. Maybe I missed >> something, but it appears to me your patch makes -Wuninitialized only >> warn about real uses and ignore uses in PHIs. > > No, the patch does not change the default behavior of -Wuninitialized > wihch will turn on -Wmaybe-uninitialized as well. The only useful > scenarios for the new option are: > > 1) -Wuninitialized -Wno-maybe-uninitialized > 2) -Wuninitialized -Werror=uninitialized -Wno-error=maybe-uninitialized > >> >> Given the lack of consensus (and I believe there will never be a >> consensus), I believe we should keep -Wuninitialized behavior as-is and >> use -Wno-maybe-uninitialized to override -Wuninitialized. > > Yes, that is this patch is supposed to do -- the attached test case is > testing it. > >> >> If we can come up with better switch name than -Wno-maybe-uninitialized, >> that would be a good step as well. However, I'm not offhand sure what >> name to use given the issues surrounding may vs must be used uninitialized. > > Maybe-uninitialized matches case 3) -- different from case 2 which is > actually 'maybe-used-uninitialized'. Other diagnostics use a level to indicate their noise level. So, why not do something like -Wuninitialized=N, with N from 1 to 3, covering all three cases. Also note that 1 and 2 are not really different as the function in question may be never executed, so 1 becomes 2 as well. Richard. > Thanks, > > David > >> >> jeff >> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >> >> iQEcBAEBAgAGBQJNsGecAAoJEBRtltQi2kC7BugH/01X2ppdVUONq2fBzztxF+YR >> Qn85yccwI45iizNG1dlmyZlYpATYcfTGwDkBYTjiVllhOJa64Ri6bIP3ErySPllk >> OrSAbwFT96TK9/h1eGfVj45mZS3MO0Pa+sxp93noGnxIMWWOt+7LiyrfJEHHLaUK >> rPhREXodzLnN0KpXTD8+RS2uzTV+YODAuiWQDkiyQ0XpjCw5w2ccc7dWnrzgvEn5 >> 6x/baTqQxunV8t3/ezUlHiMcUNyMigXccFgIeRRsvMengY/reLxy7eg1i+vdeets >> DyWR/Hg3HewLAQidL3SAJLLGuqTrNUZ0wswgqghqh9VllAFoUdKn0xk8GFt0wbk= >> =4aA4 >> -END PGP SIGNATURE- >> >
