Re: [Patch, Fortran] PR 58099: [4.8/4.9 Regression] [F03] over-zealous procedure-pointer error checking
Hi, Regtested on x86_64-unknown-linux-gnu. Ok for trunk? >>> This looks good to me >>> but I let Tobias have the final word as he >>> expressed some concerns in the PR audit trail. > > Sorry for the very belated replay. I played with the patch and it looks > okay. thanks. Committed as r202766. > (Except for an issue with intrinsic elemental, but that's a separate bug. > See PR for the details.) Thanks for catching this. I will have a look. Cheers, Janus
Re: [PATCH] Simplify & refactor a bit of tree-ssa-dom.c
On Thu, Sep 19, 2013 at 2:48 PM, Jeff Law wrote:
>
> I find it amazing to look at code I wrote in the past, the occasional WTF
> always makes it worth it.
>
> The code to manage the temporary expression & const/copies tables in
> tree-ssa-dom.c around jump threading looks overly convoluted. In particular
> the code reused an existing unwind point for the temporary expression stack
> when threading one outgoing edge of a block.
>
> I can only guess this was in response to that code at one time being much
> more expensive than it is now. Given how cheap this code is now, handling
> the temporary expression stack in the most obvious way seems much wiser.
>
> The refactoring should also make it easier to get some missing expressions
> into the table without tons of unwanted code duplication.
>
> Bootstrapped and regression tested on x86_64-unknown-linux-gnu. Installed on
> the trunk.
>
>
>
> commit f71b6fa579d113c2de9ec0ab921bbd2dcc7be43c
> Author: Jeff Law
> Date: Thu Sep 19 05:54:23 2013 -0600
>
>* tree-ssa-dom.c (record_temporary_equivalences): New function
> split out of dom_opt_dom_walker::after_dom_children.
> (dom_opt_dom_walker::thread_across_edge): Move common code
> in here from dom_opt_dom_walker::after_dom_children.
> (dom_opt_dom_walker::after_dom_children): Corresponding
> simplifictions.
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index be5b1d9..6c5f5d6 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,11 @@
> +2013-09-17 Jeff Law
> +
> + * tree-ssa-dom.c (record_temporary_equivalences): New function
> + split out of dom_opt_dom_walker::after_dom_children.
> + (dom_opt_dom_walker::thread_across_edge): Move common code
> + in here from dom_opt_dom_walker::after_dom_children.
> + (dom_opt_dom_walker::after_dom_children): Corresponding
> simplifictions.
> +
> 2013-09-19 Jan Hubicka
>
> * cgraph.c (cgraph_create_edge_1): Avoid uninitialized read
> diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
> index aac7aa4..f561386 100644
> --- a/gcc/tree-ssa-dom.c
> +++ b/gcc/tree-ssa-dom.c
> @@ -1070,6 +1070,31 @@ simplify_stmt_for_jump_threading (gimple stmt,
>return lookup_avail_expr (stmt, false);
> }
>
> +static void
> +record_temporary_equivalences (edge e)
> +{
This new function lacks a comment.
Richard.
> + int i;
> + struct edge_info *edge_info = (struct edge_info *) e->aux;
> +
> + /* If we have info associated with this edge, record it into
> + our equivalence tables. */
> + if (edge_info)
> +{
> + cond_equivalence *eq;
> + tree lhs = edge_info->lhs;
> + tree rhs = edge_info->rhs;
> +
> + /* If we have a simple NAME = VALUE equivalence, record it. */
> + if (lhs && TREE_CODE (lhs) == SSA_NAME)
> + record_const_or_copy (lhs, rhs);
> +
> + /* If we have 0 = COND or 1 = COND equivalences, record them
> +into our expression hash tables. */
> + for (i = 0; edge_info->cond_equivalences.iterate (i, &eq); ++i)
> + record_cond (eq);
> +}
> +}
> +
> /* Wrapper for common code to attempt to thread an edge. For example,
> it handles lazily building the dummy condition and the bookkeeping
> when jump threading is successful. */
> @@ -1083,9 +1108,27 @@ dom_opt_dom_walker::thread_across_edge (edge e)
> integer_zero_node, integer_zero_node,
> NULL, NULL);
>
> + /* Push a marker on both stacks so we can unwind the tables back to their
> + current state. */
> + avail_exprs_stack.safe_push (NULL);
> + const_and_copies_stack.safe_push (NULL_TREE);
> +
> + /* Traversing E may result in equivalences we can utilize. */
> + record_temporary_equivalences (e);
> +
> + /* With all the edge equivalences in the tables, go ahead and attempt
> + to thread through E->dest. */
>::thread_across_edge (dummy_cond_, e, false,
> &const_and_copies_stack,
> simplify_stmt_for_jump_threading);
> +
> + /* And restore the various tables to their state before
> + we threaded this edge.
> +
> + XXX The code in tree-ssa-threadedge.c will restore the state of
> + the const_and_copies table. We we just have to restore the expression
> + table. */
> + remove_local_expressions_from_table ();
> }
>
> /* PHI nodes can create equivalences too.
> @@ -1905,9 +1948,6 @@ dom_opt_dom_walker::after_dom_children (basic_block
> bb)
>&& (single_succ_edge (bb)->flags & EDGE_ABNORMAL) == 0
>&& potentially_threadable_block (single_succ (bb)))
> {
> - /* Push a marker on the stack, which thread_across_edge expects
> -and will remove. */
> - const_and_copies_stack.safe_push (NULL_TREE);
>thread_across_edge (single_succ_edge (bb));
> }
>else if ((last = last_stmt (bb))
> @@ -1923,79 +1963,15 @@ dom_opt_dom_walker::after_dom_children (basic_blo
Re: gimple build interface
On Thu, Sep 19, 2013 at 3:20 PM, Andrew MacLeod wrote:
> I'm looking at pulling ssa specific bits out of gimple.c so that it doesn't
> require the ssa headers, and can concentrate on basic gimple support. I
> stumbled across the "new" build interface in gimple.c consisting of these
> routines:
>
> * Helper functions to build GIMPLE statements. */
> tree create_gimple_tmp (tree, enum ssa_mode = M_SSA);
> gimple build_assign (enum tree_code, tree, int, enum ssa_mode = M_SSA);
> gimple build_assign (enum tree_code, gimple, int, enum ssa_mode = M_SSA);
> gimple build_assign (enum tree_code, tree, tree, enum ssa_mode = M_SSA);
> gimple build_assign (enum tree_code, gimple, tree, enum ssa_mode = M_SSA);
> gimple build_assign (enum tree_code, tree, gimple, enum ssa_mode = M_SSA);
> gimple build_assign (enum tree_code, gimple, gimple, enum ssa_mode = M_SSA);
> gimple build_type_cast (tree, tree, enum ssa_mode = M_SSA);
> gimple build_type_cast (tree, gimple, enum ssa_mode = M_SSA);
>
>
>
> currently only used in asan.c
>
> the routine giving me trouble is:
>
> tree
> create_gimple_tmp (tree type, enum ssa_mode mode)
> {
> return (mode == M_SSA)
> ? make_ssa_name (type, NULL)
> : create_tmp_var (type, NULL);
> }
>
>
> Other than one other routine that doesn't belong in gimple.c anyway, this
> call to make_ssa_name() is the only thing preventing gimple.c from not
> requiring tree-ssa.h.
>
> This new interface is really trying to bridge the gap between gimple and ssa
> and simplify the life of anyone needing to generate a series of
> instructions. Before actually making any code changes, I wanted to get a
> consensus on the future direction of this interface.
>
> I see the benefit in the streamlined asan.c code, but I detest that
> ssa_mode flag. And as long as it supports SSA, I don't think it should be
> in gimple.c.
>
> I think this is of most use to ssa passes that need to construct code
> snippets, so I propose we make this ssa specific and put it in tree-ssa.c
> (renaming it ssa_build_assign), *OR* we could leave it general purpose and
> put it in its own set of files, gimple-ssa-build.[ch] or something that
> crosses the border between the two representations.
>
> I'd also suggest that the final optional parameter be changed to tree *lhs
> = NULL_TREE, which would allow the caller to specify the LHS if they want,
> otherwise make_ssa_name would be called. If we want to leave it supporting
> both gimple and ssa, then anyone from gimple land could pass in a gimple LHS
> variable thus avoiding the call to make_ssa_name
Well, I didn't like this new interface at all ... it should have
consolidated the
existing one.
Richarrd.
> Thoughts?
> Andrew
Re: gimple build interface
On Thu, Sep 19, 2013 at 6:56 PM, Andrew MacLeod wrote: > On 09/19/2013 09:24 AM, Andrew MacLeod wrote: >> >> >> I think this is of most use to ssa passes that need to construct code >> snippets, so I propose we make this ssa specific and put it in tree-ssa.c >> (renaming it ssa_build_assign), *OR* we could leave it general purpose and >> put it in its own set of files, gimple-ssa-build.[ch] or something that >> crosses the border between the two representations. >> >> I'd also suggest that the final optional parameter be changed to tree *lhs >> = NULL_TREE, which would allow the caller to specify the LHS if they want, >> otherwise make_ssa_name would be called. If we want to leave it supporting >> both gimple and ssa, then anyone from gimple land could pass in a gimple LHS >> variable thus avoiding the call to make_ssa_name >> >> Thoughts? >> Andrew > > Anyway, here is a patch which does that and a bit more. I didn't rename > build_assign() to ssa_build_assign().. even though those are the only kind > actually created right now. we can leave that for the day someone actually > decides to flush this interface out, and maybe we'll want to pass in > gimple_tmps and call them from front ends or other places... then it would > have to be renamed again. So I just left it as is for the moment, but that > could be changed. > > I also moved gimple_replace_lhs() to tree-ssa.c and renamed it > ssa_replace_lhs(). It calls insert_debug_temp_for_var_def() from tree-ssa.c > and that only works with the immediate use operands.. so that is an SSA > specific routine, which makes this one SSA specific as well. > > Those 2 changes allow tree-ssa.h to no longer be included, it is replaced > with tree-flow.h. Some preliminary work to enable removing immediate use > routines out of tree-flow.h include: > > struct count_ptr_d, count_ptr_derefs(), count_uses_and_derefs() also get > moved to tree-ssa.c since those are also require the immediate use > mechanism, and thus is also SSA dependent. > > This bootstraps on x86_64-unknown-linux-gnu and has no new regressions. > OK? Can you move the builders to asan.c please? From a quick glance it seems to have various issues so it shouldn't be used (I wonder who approved them in the end ... maybe it was even me). ssa_replace_lhs sounds odd (a 'SSA' has a lhs?), but maybe it's just me. I'd have chosen gimple_replace_ssa_lhs? Anyway, it looks ok to me modulo the pre-existing broken builder stuff (whether it's in tree-ssa.h or gimple.h doesn't really matter for that fact). Thanks, Richard. > Andrew
Re: [PATCH] manage dom-walk_data initialization and finalization with constructors and destructors
On Thu, Sep 19, 2013 at 7:24 PM, Trevor Saunders wrote:
> On Thu, Sep 19, 2013 at 03:23:21PM +0200, Michael Matz wrote:
>> > I don't see anything in Trevor's work that requires jumping through
>> > hoops.
>>
>> Me neither, from that perspective it's okay. It's merely that I doubt the
>> value of any syntactic privatization like it's implemented in C++, you can
>> #define it away, hence the compiler can't make use of that information for
>
> no, it can't make use of it if someone does something crazy like #define
> it away which is atleast a little tricky because of the ':'. I believe
> clang does infact make use of private to find unused fields (maybe it
> does something else, but I can't imagine what that would be).
>
>> code generation, and the cognitive value for the developer ("hey I
>> shouldn't look at this member from outside") is dubious, as that probably
>> is a general rule, no direct data member access from non-members (although
>> I have problems with that too).
>
> The value is that when you read code you *know* that something is only
> used in certain places instead of hoping that is true.
>
>> And I think the fact that Trevor made one data member non-private to
>> access it from a non-member function (move_computations_dom_walker::todo)
>> just underlines my point: private is useless and gets in the way.
>
> It certainly shows a case where that's true, but it doesn't really show
> that's always true.
>
>> > > What's the benefit of reading and writing such noisy lines? :
>> > >
>> > >*out_mode = mode_;
>> > >mode_ = GET_MODE_WIDER_MODE (mode_);
>> > >count_++;
>> >
>> > It makes it very clear to the reader that we're dealing with objects that
>> > belong to a class instance rather than direct access to an auto or static.
>> > That can be important.
>>
>> this->x.
>>
>> From the wiki it seems that was dicussed (on the wiki, not the mailing
>> list) and rejected by Lawrence on the grounds of indroducing too long
>> lines. I agree with that, but I don't agree that therefore members should
>> be named foo_.
>
> this-> also has the disadvantage that you always have to rember it, and
> fundimentally doesn't help you know where a member could possibly be
> used.
Sure, there is no way to syntactically force the use of this-> - that's a
disadvantage (though we've had private -Wxxx warnings which we could
add for this). The extra advantage of this-> is that it makes name-lookup
unambiguous to those not 100% familiar with it (and who really is ...)
Richard.
> Trev
>
>>
>> > Given it's recommended by our C++ guidelines which were discussed at
>> > length, I'm going to explicitly NAK your patch.
>>
>> Hmmkay.
>>
>> > FWIW, I have worked on large C++ codebases
>>
>> Me too.
>>
>> > that were a free-for-all and found them *amazingly* painful.
>>
>> I don't think any of my mails about style can be interpreted as advocating
>> free-for-all.
>>
>> > The restricted set allowed for GCC is actually quite reasonable IMHO,
>> > particularly for projects where the main body of code is evolving from a
>> > pure C base.
>>
>> Funnily it's the small things that weren't much discussed (probably
>> because they are deemed not very important) in the convention that give
>> me a hard time, nits such as these syntactic uglifications. The larger
>> things indeed mostly are okayish.
>>
>>
>> Ciao,
>> Michael.
Re: gimple build interface
On Fri, Sep 20, 2013 at 10:08:20AM +0200, Richard Biener wrote: > Can you move the builders to asan.c please? From a quick glance it seems > to have various issues so it shouldn't be used (I wonder who approved them > in the end ... maybe it was even me). Moving them to asan.c looks wrong. If we don't want them, the change that introduced them should be just reverted. There is nothing special in asan.c that would require using different APIs than everything else. Jakub
Re: [PATCH] manage dom-walk_data initialization and finalization with constructors and destructors
On Thu, Sep 19, 2013 at 8:11 PM, Richard Sandiford wrote: > Michael Matz writes: >> What's the benefit of reading and writing such noisy lines? : >> >> *out_mode = mode_; >> mode_ = GET_MODE_WIDER_MODE (mode_); >> count_++; >> >> The uglification merely makes code harder to write and read, it should be >> used in cases where you _don't_ want developers to write such names. > > Heh. Since it's my code being used as the example here: I also find it > very ugly FWIW. I only added the underscores because that's what the > conventions said. > > But we're never going to get consensus on this kind of thing. E.g. I > know some people really hate the GNU formatting style (although I very > much like it). So I just held my nose while writing the patch. Btw, I've come around multiple coding-styles in the past and I definitely would prefer m_mode / m_count to mark members vs. mode_ and count_. (and s_XXX for static members IIRC). Richard. > Thanks, > Richard
Re: [PATCH] Handle bit-fields in ubsan.c (PR sanitizer/58413)
On Mon, Sep 16, 2013 at 06:18:11PM +0200, Marek Polacek wrote:
> On Mon, Sep 16, 2013 at 06:04:23PM +0200, Jakub Jelinek wrote:
> > On Mon, Sep 16, 2013 at 05:59:28PM +0200, Marek Polacek wrote:
> > > Regtested/ran bootstrap-ubsan on x86_64-linux.
> >
> > That looks wrong. ubsan_type_descriptor shouldn't change TYPE_PRECISION of
> > the type it has been called with, whether type is a bitfield or not can
> > change what typedescriptor is generated, but not unrelated code.
>
> Ok, that was weird. What about this one? We use the TYPE_SIZE precision
> if we're dealing with bit-fields, but don't change the type in any
> way.
>
> Ubsan testsuite passes...
>
> 2013-09-16 Marek Polacek
>
> PR sanitizer/58413
> * ubsan.c (get_ubsan_type_info_for_type): For bit-fields, use the
> precision of its TYPE_SIZE.
Is this one ok? (With testcase from
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01212.html .)
> --- gcc/ubsan.c.mp2013-09-16 18:13:01.075903156 +0200
> +++ gcc/ubsan.c 2013-09-16 18:13:20.514974154 +0200
> @@ -233,7 +233,13 @@ ubsan_source_location (location_t loc)
> static unsigned short
> get_ubsan_type_info_for_type (tree type)
> {
> - int prec = exact_log2 (TYPE_PRECISION (type));
> + int prec = TYPE_PRECISION (type);
> +
> + /* Handle bit-fields. */
> + if (compare_tree_int (TYPE_SIZE (type), prec) == 1)
> +prec = tree_low_cst (TYPE_SIZE (type), 1);
> +
> + prec = exact_log2 (prec);
>if (prec == -1)
> error ("unexpected size of type %qT", type);
Marek
Re: [PATCH] Fix PR58417
On Thu, 19 Sep 2013, David Edelsohn wrote: > This patch has caused 6 new libstdc++ failures on AIX. All look like: > > /home/dje/src/src/libstdc++-v3/testsuite/ext/random/normal_mv_distribution/cons/default.cc:49:1: > internal compiler error: in build_polynomial_chrec, at > tree-chrec.h:148 > } Andreas filed PR58473 for this - seems to be a latent issue for which I have a trivial fix (the assert is overly strict). Richard.
Re: [PATCH] Handle bit-fields in ubsan.c (PR sanitizer/58413)
On Fri, Sep 20, 2013 at 10:22:43AM +0200, Marek Polacek wrote:
> > --- gcc/ubsan.c.mp 2013-09-16 18:13:01.075903156 +0200
> > +++ gcc/ubsan.c 2013-09-16 18:13:20.514974154 +0200
> > @@ -233,7 +233,13 @@ ubsan_source_location (location_t loc)
> > static unsigned short
> > get_ubsan_type_info_for_type (tree type)
> > {
> > - int prec = exact_log2 (TYPE_PRECISION (type));
> > + int prec = TYPE_PRECISION (type);
> > +
> > + /* Handle bit-fields. */
> > + if (compare_tree_int (TYPE_SIZE (type), prec) == 1)
> > +prec = tree_low_cst (TYPE_SIZE (type), 1);
Makes me wonder why you are using then TYPE_PRECISION at all, when
you actually want to use TYPE_SIZE.
Note that TYPE_SIZE can be NULL (for incomplete types)
or non-constant (VLAs) or big enough not to fit into a HWI.
But you are so far dealing only with integral/scalar float types, right?
So perhaps just gcc_assert (TYPE_SIZE (type) && host_integerp (TYPE_SIZE
(type), 1)
or something.
> > +
> > + prec = exact_log2 (prec);
> >if (prec == -1)
> > error ("unexpected size of type %qT", type);
This sounds like it should be gcc_assert (prec != -1); or
sorry, it doesn't look like a bug in user program if we hit that.
Jakub
[PATCH]Construct canonical scaled address expression in IVOPT
Hi,
For now IVOPT constructs scaled address expression in the form of
"scaled*index" and checks whether backend supports it. The problem is the
address expression is invalid on ARM, causing scaled expression disabled in
IVOPT on ARM. This patch fixes the IVOPT part by constructing rtl address
expression like "index*scaled+base".
Hi Richard,
I thought about the suggestion constructing TARGET_MEM[.] and adding new
target hook to check whether backend supports such target memory accesses,
but still want to give this patch a try because:
1) RTL pattern "index*scaled+base" is some kind of canonical form of scaled
address expression and it works fine.
2) It won't save us any inconvenience by constructing TARGET_MEM node, on
contrary, we have to add new target hook checking whether scaled addressing
mode is supported, which in essence is nothing else than current
implementation.
Also "base+index*scaled" is re-structured to canonical form
"index*scaled+base", I constructed the latter form in patch.
Bootstrapped and tested on x86_64 and arm_a15. Is it OK?
Thanks.
bin
2013-09-20 Bin Cheng
* tree-ssa-loop-ivopts.c (multiplier_allowed_in_address_p):
Construct canonical scaled rtl address expression.Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c (revision 202599)
+++ gcc/tree-ssa-loop-ivopts.c (working copy)
@@ -3134,15 +3134,22 @@ multiplier_allowed_in_address_p (HOST_WIDE_INT rat
{
enum machine_mode address_mode = targetm.addr_space.address_mode (as);
rtx reg1 = gen_raw_REG (address_mode, LAST_VIRTUAL_REGISTER + 1);
- rtx addr;
+ rtx addr, index;
HOST_WIDE_INT i;
valid_mult = sbitmap_alloc (2 * MAX_RATIO + 1);
bitmap_clear (valid_mult);
- addr = gen_rtx_fmt_ee (MULT, address_mode, reg1, NULL_RTX);
+ /* Construct address expression in the canonical form of
+"base+index*scale" and call memory_address_addr_space_p
+to see whether it is allowed by target processors. */
+ index = gen_rtx_fmt_ee (MULT, address_mode, reg1, NULL_RTX);
for (i = -MAX_RATIO; i <= MAX_RATIO; i++)
{
- XEXP (addr, 1) = gen_int_mode (i, address_mode);
+ if (i == 1)
+ continue;
+
+ XEXP (index, 1) = gen_int_mode (i, address_mode);
+ addr = gen_rtx_fmt_ee (PLUS, address_mode, index, reg1);
if (memory_address_addr_space_p (mode, addr, as))
bitmap_set_bit (valid_mult, i + MAX_RATIO);
}
[PATCH] Fix PR58473
This fixes a fallout of the fix for PR58417 - the assert in
build_polynomial_chrec is too strict and I wonder why we haven't
been running into this before.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-09-20 Richard Biener
PR middle-end/58473
* tree-chrec.h (build_polynomial_chrec): Use gcc_checking_assert,
make type comparison less strict.
Index: gcc/tree-chrec.h
===
*** gcc/tree-chrec.h(revision 202766)
--- gcc/tree-chrec.h(working copy)
*** build_polynomial_chrec (unsigned loop_nu
*** 137,151
|| !val)
return chrec_dont_know;
! /* Pointer types should occur only on the left hand side, i.e. in
! the base of the chrec, and not in the step. */
! gcc_assert (!POINTER_TYPE_P (TREE_TYPE (right)));
!
! /* Types of left and right sides of a chrec should be compatible. */
if (POINTER_TYPE_P (TREE_TYPE (left)))
! gcc_assert (ptrofftype_p (TREE_TYPE (right)));
else
! gcc_assert (TREE_TYPE (left) == TREE_TYPE (right));
if (chrec_zerop (right))
return left;
--- 137,154
|| !val)
return chrec_dont_know;
! /* Types of left and right sides of a chrec should be compatible, but
! pointer CHRECs are special in that the evolution is of ptroff type. */
if (POINTER_TYPE_P (TREE_TYPE (left)))
! gcc_checking_assert (ptrofftype_p (TREE_TYPE (right)));
else
! {
! /* Pointer types should occur only on the left hand side, i.e. in
!the base of the chrec, and not in the step. */
! gcc_checking_assert (!POINTER_TYPE_P (TREE_TYPE (right))
! && types_compatible_p (TREE_TYPE (left),
! TREE_TYPE (right)));
! }
if (chrec_zerop (right))
return left;
[PATCH] Ensure testing is done with -fdiagnostics-color=never in the testsuite
Hi!
When testing gcc with GCC_COLORS=' ' in the environment,
gcc/testsuite/lib/*.exp makes sure -fdiagnostics-color=never is added
and thus doesn't confuse the regexps checking for gcc output (which
in dejagnu goes to a pseudo tty and thus can be colorized even with
-fdiagnostics-color=auto), but apparently libstdc++-v3, libgomp and
libmudflap testsuites don't do that, so some tests FAIL because of that.
Fixed thusly, ok for trunk?
2013-09-20 Jakub Jelinek
libstdc++-v3/
* testsuite/lib/libstdc++.exp (libstdc++_init): Prepend
-fdiagnostics-color=never to cxxflags.
libmudflap/
* testsuite/lib/libmudflap.exp (libmudflap-init): Append
-fdiagnostics-color=never to cxxflags.
libgomp/
* testsuite/lib/libgomp.exp: Add -fdiagnostics-color=never to
ALWAYS_CFLAGS.
--- libstdc++-v3/testsuite/lib/libstdc++.exp.jj 2013-08-12 21:18:45.0
+0200
+++ libstdc++-v3/testsuite/lib/libstdc++.exp2013-09-20 12:13:41.342720820
+0200
@@ -283,7 +283,7 @@ proc libstdc++_init { testfile } {
v3track cxxflags 2
# Always use MO files built by this test harness.
-set cxxflags "$cxxflags -DLOCALEDIR=\".\""
+set cxxflags "-fdiagnostics-color=never $cxxflags -DLOCALEDIR=\".\""
set ccflags "$cxxflags -DLOCALEDIR=\".\""
# If a PCH file is available, use it. We must delay performing
--- libmudflap/testsuite/lib/libmudflap.exp.jj 2013-02-04 14:49:32.0
+0100
+++ libmudflap/testsuite/lib/libmudflap.exp 2013-09-20 12:16:31.760710659
+0200
@@ -85,7 +85,7 @@ proc libmudflap-init { language } {
append ld_library_path ":${blddir}/.libs"
set libs "-L${blddir}/.libs"
-set cxxflags "-ggdb3 -DDEBUG_ASSERT"
+set cxxflags "-ggdb3 -DDEBUG_ASSERT -fdiagnostics-color=never"
set includes "-I${srcdir} -I${srcdir}/.. -I.."
if {$language == "c++"} {
--- libgomp/testsuite/lib/libgomp.exp.jj2013-06-25 11:47:20.0
+0200
+++ libgomp/testsuite/lib/libgomp.exp 2013-09-20 11:51:32.885800025 +0200
@@ -167,6 +167,9 @@ proc libgomp_init { args } {
# Disable caret
lappend ALWAYS_CFLAGS "additional_flags=-fno-diagnostics-show-caret"
+# Disable color diagnostics
+lappend ALWAYS_CFLAGS "additional_flags=-fdiagnostics-color=never"
+
# And, gee, turn on OpenMP.
lappend ALWAYS_CFLAGS "additional_flags=-fopenmp"
}
Jakub
[PATCH] Fix PR58453
The following "fixes" the bogus loop distribution that breaks
434.zeusmp by applying the cost model for -ftree-loop-distribute-patterns
as well (with -O3 -ftree-loop-distribution the bug doesn't reproduce).
This papers over the real issue only but it is part of the real
fix I am developing (a missing feature I pushed back for too long as
well). So as it unbreaks 434.zeusmp I'll apply this beforehand.
The real fix, while complete, needs some TLC and compile-time work.
Bootstrap and regtest running on x86_64-unknown-linux-gnu, I'll
double-check SPEC 2k6 before committing this as well.
Thanks,
Richard.
2013-09-20 Richard Biener
PR tree-optimization/58453
* tree-loop-distribution.c (distribute_loop): Apply the cost
model for -ftree-loop-distribute-patterns, too.
* gcc.dg/tree-ssa/ldist-23.c: New testcase.
Index: gcc/tree-loop-distribution.c
===
*** gcc/tree-loop-distribution.c(revision 202774)
--- gcc/tree-loop-distribution.c(working copy)
*** distribute_loop (struct loop *loop, vec<
*** 1514,1531
any_builtin |= partition_builtin_p (partition);
}
/* If we are only distributing patterns fuse all partitions that
! were not properly classified as builtins. Else fuse partitions
! with similar memory accesses. */
if (!flag_tree_loop_distribution)
{
partition_t into;
- /* If we did not detect any builtin simply bail out. */
- if (!any_builtin)
- {
- nbp = 0;
- goto ldist_done;
- }
/* Only fuse adjacent non-builtin partitions, see PR53616.
??? Use dependence information to improve partition ordering. */
i = 0;
--- 1514,1564
any_builtin |= partition_builtin_p (partition);
}
+ /* If we did not detect any builtin but are not asked to apply
+ regular loop distribution simply bail out. */
+ if (!flag_tree_loop_distribution
+ && !any_builtin)
+ {
+ nbp = 0;
+ goto ldist_done;
+ }
+
+ /* Apply our simple cost model - fuse partitions with similar
+ memory accesses. */
+ partition_t into;
+ for (i = 0; partitions.iterate (i, &into); ++i)
+ {
+ if (partition_builtin_p (into))
+ continue;
+ for (int j = i + 1;
+ partitions.iterate (j, &partition); ++j)
+ {
+ if (!partition_builtin_p (partition)
+ && similar_memory_accesses (rdg, into, partition))
+ {
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ {
+ fprintf (dump_file, "fusing partitions\n");
+ dump_bitmap (dump_file, into->stmts);
+ dump_bitmap (dump_file, partition->stmts);
+ fprintf (dump_file, "because they have similar "
+ "memory accesses\n");
+ }
+ bitmap_ior_into (into->stmts, partition->stmts);
+ if (partition->kind == PKIND_REDUCTION)
+ into->kind = PKIND_REDUCTION;
+ partitions.ordered_remove (j);
+ partition_free (partition);
+ j--;
+ }
+ }
+ }
+
/* If we are only distributing patterns fuse all partitions that
! were not properly classified as builtins. */
if (!flag_tree_loop_distribution)
{
partition_t into;
/* Only fuse adjacent non-builtin partitions, see PR53616.
??? Use dependence information to improve partition ordering. */
i = 0;
*** distribute_loop (struct loop *loop, vec<
*** 1549,1586
}
while ((unsigned) i < partitions.length ());
}
- else
- {
- partition_t into;
- int j;
- for (i = 0; partitions.iterate (i, &into); ++i)
- {
- if (partition_builtin_p (into))
- continue;
- for (j = i + 1;
- partitions.iterate (j, &partition); ++j)
- {
- if (!partition_builtin_p (partition)
- && similar_memory_accesses (rdg, into, partition))
- {
- if (dump_file && (dump_flags & TDF_DETAILS))
- {
- fprintf (dump_file, "fusing partitions\n");
- dump_bitmap (dump_file, into->stmts);
- dump_bitmap (dump_file, partition->stmts);
- fprintf (dump_file, "because they have similar "
- "memory accesses\n");
- }
- bitmap_ior_into (into->stmts, partition->stmts);
- if (partition->kind == PKIND_REDUCTION)
- into->kind = PKIND_REDUCTION;
- partitions.ordered_remove (j);
- partition_free (partition);
- j--;
- }
- }
- }
- }
/* Fuse all reduction partitions into the l
Re: [PATCH] manage dom-walk_data initialization and finalization with constructors and destructors
On Fri, Sep 20, 2013 at 10:13:27AM +0200, Richard Biener wrote: > On Thu, Sep 19, 2013 at 8:11 PM, Richard Sandiford > wrote: > > Michael Matz writes: > >> What's the benefit of reading and writing such noisy lines? : > >> > >> *out_mode = mode_; > >> mode_ = GET_MODE_WIDER_MODE (mode_); > >> count_++; > >> > >> The uglification merely makes code harder to write and read, it should be > >> used in cases where you _don't_ want developers to write such names. > > > > Heh. Since it's my code being used as the example here: I also find it > > very ugly FWIW. I only added the underscores because that's what the > > conventions said. > > > > But we're never going to get consensus on this kind of thing. E.g. I > > know some people really hate the GNU formatting style (although I very > > much like it). So I just held my nose while writing the patch. > > Btw, I've come around multiple coding-styles in the past and I definitely > would prefer m_mode / m_count to mark members vs. mode_ and count_. > (and s_XXX for static members IIRC). what about a_foo for arguments? I'd prefer m_/s_foo for members / static things too fwiw. Trev > > Richard. > > > Thanks, > > Richard
Re: [v3] More noexcept -- 5th
On 09/20/2013 09:46 AM, Marc Glisse wrote: Hello, for basic_string, I tried not to add lies about exceptions, but I didn't remove existing ones. Of course we should not have lies, I thought we didn't, besides maybe special cases having to do with the FULLY_DYNAMIC string thing, really a C++98 legacy wa, which will not exist in the future. Can you please send an updated patch fixing those? Thanks, Paolo.
Re: [PATCH] manage dom-walk_data initialization and finalization with constructors and destructors
Hi, On Fri, 20 Sep 2013, Trevor Saunders wrote: > > > very ugly FWIW. I only added the underscores because that's what > > > the conventions said. > > > > > > But we're never going to get consensus on this kind of thing. E.g. > > > I know some people really hate the GNU formatting style (although I > > > very much like it). So I just held my nose while writing the patch. > > > > Btw, I've come around multiple coding-styles in the past and I > > definitely would prefer m_mode / m_count to mark members vs. mode_ and > > count_. (and s_XXX for static members IIRC). > > what about a_foo for arguments? That would go too far. If we're marking member for reasons of reminding ourself that the access involves an indirection (amongst other reasons), i.e. it's slower than accessing a local variable, then the same can't be said from arguments. It's just another local variable mostly. And about remembering that it's in current scope, well, it's just there at the very top of the function. (Or IOW, we could do without the last 20 years :) ) > I'd prefer m_/s_foo for members / static things too fwiw. Me as well. It's still ugly, but not so unsymmetric as the trailing underscore. Ciao, Michael.
Re: [PATCH] Handle bit-fields in ubsan.c (PR sanitizer/58413)
On Fri, Sep 20, 2013 at 10:37:57AM +0200, Jakub Jelinek wrote:
> On Fri, Sep 20, 2013 at 10:22:43AM +0200, Marek Polacek wrote:
> > > --- gcc/ubsan.c.mp2013-09-16 18:13:01.075903156 +0200
> > > +++ gcc/ubsan.c 2013-09-16 18:13:20.514974154 +0200
> > > @@ -233,7 +233,13 @@ ubsan_source_location (location_t loc)
> > > static unsigned short
> > > get_ubsan_type_info_for_type (tree type)
> > > {
> > > - int prec = exact_log2 (TYPE_PRECISION (type));
> > > + int prec = TYPE_PRECISION (type);
> > > +
> > > + /* Handle bit-fields. */
> > > + if (compare_tree_int (TYPE_SIZE (type), prec) == 1)
> > > +prec = tree_low_cst (TYPE_SIZE (type), 1);
>
> Makes me wonder why you are using then TYPE_PRECISION at all, when
> you actually want to use TYPE_SIZE.
Yeah, we might as well use TYPE_SIZE directly...
> Note that TYPE_SIZE can be NULL (for incomplete types)
> or non-constant (VLAs) or big enough not to fit into a HWI.
> But you are so far dealing only with integral/scalar float types, right?
Yes, so far only INTEGER_TYPEs. I added the assert nonetheless.
> So perhaps just gcc_assert (TYPE_SIZE (type) && host_integerp (TYPE_SIZE
> (type), 1)
> or something.
>
> > > +
> > > + prec = exact_log2 (prec);
> > >if (prec == -1)
> > > error ("unexpected size of type %qT", type);
>
> This sounds like it should be gcc_assert (prec != -1); or
> sorry, it doesn't look like a bug in user program if we hit that.
Agreed. Added that assert in there. How does it look now?
Regtested/bootstrap-ubsan passed on x86_64-linux.
2013-09-20 Marek Polacek
PR sanitizer/58413
* ubsan.c (get_ubsan_type_info_for_type): Use TYPE_SIZE instead of
TYPE_PRECISION. Add asserts.
testsuite/
* c-c++-common/ubsan/shift-4.c: New test.
--- gcc/ubsan.c.mp 2013-09-20 13:31:31.491652058 +0200
+++ gcc/ubsan.c 2013-09-20 13:36:31.159335560 +0200
@@ -233,10 +233,9 @@ ubsan_source_location (location_t loc)
static unsigned short
get_ubsan_type_info_for_type (tree type)
{
- int prec = exact_log2 (TYPE_PRECISION (type));
- if (prec == -1)
-error ("unexpected size of type %qT", type);
-
+ gcc_assert (TYPE_SIZE (type) && host_integerp (TYPE_SIZE (type), 1));
+ int prec = exact_log2 (tree_low_cst (TYPE_SIZE (type), 1));
+ gcc_assert (prec != -1);
return (prec << 1) | !TYPE_UNSIGNED (type);
}
--- gcc/testsuite/c-c++-common/ubsan/shift-4.c.mp 2013-09-20
13:34:36.245909813 +0200
+++ gcc/testsuite/c-c++-common/ubsan/shift-4.c 2013-09-20 13:34:25.419870385
+0200
@@ -0,0 +1,14 @@
+/* { dg-do run } */
+/* { dg-options "-fsanitize=shift -w" } */
+
+struct S { unsigned long long int b:40; } s;
+
+int
+main ()
+{
+ s.b = 2;
+ s.b <<= 120;
+ return 0;
+}
+
+/* { dg-output "shift exponent 120 is too large\[^\n\r]*(\n|\r\n|\r)" } */
Marek
Re: [PATCH] Handle bit-fields in ubsan.c (PR sanitizer/58413)
On Fri, Sep 20, 2013 at 02:33:25PM +0200, Marek Polacek wrote: > Agreed. Added that assert in there. How does it look now? Ok. > 2013-09-20 Marek Polacek > > PR sanitizer/58413 > * ubsan.c (get_ubsan_type_info_for_type): Use TYPE_SIZE instead of > TYPE_PRECISION. Add asserts. > > testsuite/ > * c-c++-common/ubsan/shift-4.c: New test. Jakub
Re: [v3] More noexcept -- 5th
.. first blush, I think we have to remove the noexcept from the non-const forms of begin and end and from clear. Because the string can be shared... Thanks, Paolo.
Re: [Patch] match_results::format and regex_replace
Great indeed! More comments later. First nit: please review the various regex_replace overloads vs inline: if I'm not misreading the diff I see large ones inline and small ones out of line!?! Should we have a regex.tcc? Also, old story about ChangeLogs ;) This is not ok: * include/bits/regex.h: Implement match_results::format and regex_replace. use something like: * include/bits/regex.h (match_results::format, regex_replace): Implement. That is, function names *always* between round brackets. Paolo.
Re: gimple build interface
On Thu, Sep 19, 2013 at 9:20 AM, Andrew MacLeod wrote: > I see the benefit in the streamlined asan.c code, but I detest that > ssa_mode flag. And as long as it supports SSA, I don't think it should be > in gimple.c. Yeah, at the time that I introduced it, I had a hard time with the normal/ssa form duality. I think it would be fine to only support SSA form in this interface. The code that deals with gimple in normal form is very short and low-level, anyway. I don't expect most developers to need it. The only potential users are those generating normal code and then putting it into ssa form, but that should be rare. > I'd also suggest that the final optional parameter be changed to tree *lhs > = NULL_TREE, which would allow the caller to specify the LHS if they want, > otherwise make_ssa_name would be called. If we want to leave it supporting > both gimple and ssa, then anyone from gimple land could pass in a gimple LHS > variable thus avoiding the call to make_ssa_name Sure. Diego.
Re: gimple build interface
On Fri, Sep 20, 2013 at 4:08 AM, Richard Biener wrote: > On Thu, Sep 19, 2013 at 6:56 PM, Andrew MacLeod wrote: >> On 09/19/2013 09:24 AM, Andrew MacLeod wrote: >>> >>> >>> I think this is of most use to ssa passes that need to construct code >>> snippets, so I propose we make this ssa specific and put it in tree-ssa.c >>> (renaming it ssa_build_assign), *OR* we could leave it general purpose and >>> put it in its own set of files, gimple-ssa-build.[ch] or something that >>> crosses the border between the two representations. >>> >>> I'd also suggest that the final optional parameter be changed to tree *lhs >>> = NULL_TREE, which would allow the caller to specify the LHS if they want, >>> otherwise make_ssa_name would be called. If we want to leave it supporting >>> both gimple and ssa, then anyone from gimple land could pass in a gimple LHS >>> variable thus avoiding the call to make_ssa_name >>> >>> Thoughts? >>> Andrew >> >> Anyway, here is a patch which does that and a bit more. I didn't rename >> build_assign() to ssa_build_assign().. even though those are the only kind >> actually created right now. we can leave that for the day someone actually >> decides to flush this interface out, and maybe we'll want to pass in >> gimple_tmps and call them from front ends or other places... then it would >> have to be renamed again. So I just left it as is for the moment, but that >> could be changed. >> >> I also moved gimple_replace_lhs() to tree-ssa.c and renamed it >> ssa_replace_lhs(). It calls insert_debug_temp_for_var_def() from tree-ssa.c >> and that only works with the immediate use operands.. so that is an SSA >> specific routine, which makes this one SSA specific as well. >> >> Those 2 changes allow tree-ssa.h to no longer be included, it is replaced >> with tree-flow.h. Some preliminary work to enable removing immediate use >> routines out of tree-flow.h include: >> >> struct count_ptr_d, count_ptr_derefs(), count_uses_and_derefs() also get >> moved to tree-ssa.c since those are also require the immediate use >> mechanism, and thus is also SSA dependent. >> >> This bootstraps on x86_64-unknown-linux-gnu and has no new regressions. >> OK? > > Can you move the builders to asan.c please? No. They don't belong there. This is a high-level wrapper for the low-level instruction builders. > to have various issues so it shouldn't be used (I wonder who approved them > in the end ... maybe it was even me). Not really. I put it in and still need to flush it out a bit more. I'll work on it. Diego.
[PATCH] Fix PR58484
I am testing the following patch which fixes PR58484, the ICE
compiling 416.gamess after my PR58417 fix.
The issue is that now the chrec cache during instantiation is
again dependent on the block we instantiate below due to the
possible recursion through analyze_scalar_evolution. Thus the
patch re-instantiates the original hash (still in the more
allocation friendly variant).
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2013-09-20 Richard Biener
PR middle-end/58484
* tree-scalar-evolution.c (struct scev_info_str): Shrink by
remembering SSA name version and block index.
(new_scev_info_str): Adjust.
(hash_scev_info): Likewise. Also hash the block index.
(eq_scev_info): Adjust.
(find_var_scev_info): Likewise.
(struct instantiate_cache_entry): Remove.
(struct instantiate_cache_type): Use a htab to map name, block
to chrec.
(instantiate_cache_type::~instantiate_cache_type): Adjust.
(get_instantiated_value_entry): Likewise.
(hash_idx_scev_info, eq_idx_scev_info): New functions.
(instantiate_scev_name): Adjust.
* gfortran.dg/pr58484.f: New testcase.
Index: gcc/tree-scalar-evolution.c
===
*** gcc/tree-scalar-evolution.c (revision 202775)
--- gcc/tree-scalar-evolution.c (working copy)
*** static tree analyze_scalar_evolution_1 (
*** 269,281
static tree analyze_scalar_evolution_for_address_of (struct loop *loop,
tree var);
! /* The cached information about an SSA name VAR, claiming that below
!basic block INSTANTIATED_BELOW, the value of VAR can be expressed
!as CHREC. */
struct GTY(()) scev_info_str {
! basic_block instantiated_below;
! tree var;
tree chrec;
};
--- 269,281
static tree analyze_scalar_evolution_for_address_of (struct loop *loop,
tree var);
! /* The cached information about an SSA name with version NAME_VERSION,
!claiming that below basic block with index INSTANTIATED_BELOW, the
!value of the SSA name can be expressed as CHREC. */
struct GTY(()) scev_info_str {
! unsigned int name_version;
! int instantiated_below;
tree chrec;
};
*** new_scev_info_str (basic_block instantia
*** 309,317
struct scev_info_str *res;
res = ggc_alloc_scev_info_str ();
! res->var = var;
res->chrec = chrec_not_analyzed_yet;
! res->instantiated_below = instantiated_below;
return res;
}
--- 309,317
struct scev_info_str *res;
res = ggc_alloc_scev_info_str ();
! res->name_version = SSA_NAME_VERSION (var);
res->chrec = chrec_not_analyzed_yet;
! res->instantiated_below = instantiated_below->index;
return res;
}
*** new_scev_info_str (basic_block instantia
*** 319,327
/* Computes a hash function for database element ELT. */
static inline hashval_t
! hash_scev_info (const void *elt)
{
! return SSA_NAME_VERSION (((const struct scev_info_str *) elt)->var);
}
/* Compares database elements E1 and E2. */
--- 319,328
/* Computes a hash function for database element ELT. */
static inline hashval_t
! hash_scev_info (const void *elt_)
{
! const struct scev_info_str *elt = (const struct scev_info_str *) elt_;
! return elt->name_version ^ elt->instantiated_below;
}
/* Compares database elements E1 and E2. */
*** eq_scev_info (const void *e1, const void
*** 332,338
const struct scev_info_str *elt1 = (const struct scev_info_str *) e1;
const struct scev_info_str *elt2 = (const struct scev_info_str *) e2;
! return (elt1->var == elt2->var
&& elt1->instantiated_below == elt2->instantiated_below);
}
--- 333,339
const struct scev_info_str *elt1 = (const struct scev_info_str *) e1;
const struct scev_info_str *elt2 = (const struct scev_info_str *) e2;
! return (elt1->name_version == elt2->name_version
&& elt1->instantiated_below == elt2->instantiated_below);
}
*** find_var_scev_info (basic_block instanti
*** 355,362
struct scev_info_str tmp;
PTR *slot;
! tmp.var = var;
! tmp.instantiated_below = instantiated_below;
slot = htab_find_slot (scalar_evolution_info, &tmp, INSERT);
if (!*slot)
--- 356,363
struct scev_info_str tmp;
PTR *slot;
! tmp.name_version = SSA_NAME_VERSION (var);
! tmp.instantiated_below = instantiated_below->index;
slot = htab_find_slot (scalar_evolution_info, &tmp, INSERT);
if (!*slot)
*** analyze_scalar_evolution_in_loop (struct
*** 2065,2080
instantiating a CHREC or resolving mixers. For this use
instantiated_below is always the same. */
- struct instantiate_cache_entry
- {
- tree name;
- tree chrec;
- };
-
Re: gimple build interface
On Fri, Sep 20, 2013 at 3:07 PM, Diego Novillo wrote: > On Fri, Sep 20, 2013 at 4:08 AM, Richard Biener > wrote: >> On Thu, Sep 19, 2013 at 6:56 PM, Andrew MacLeod wrote: >>> On 09/19/2013 09:24 AM, Andrew MacLeod wrote: I think this is of most use to ssa passes that need to construct code snippets, so I propose we make this ssa specific and put it in tree-ssa.c (renaming it ssa_build_assign), *OR* we could leave it general purpose and put it in its own set of files, gimple-ssa-build.[ch] or something that crosses the border between the two representations. I'd also suggest that the final optional parameter be changed to tree *lhs = NULL_TREE, which would allow the caller to specify the LHS if they want, otherwise make_ssa_name would be called. If we want to leave it supporting both gimple and ssa, then anyone from gimple land could pass in a gimple LHS variable thus avoiding the call to make_ssa_name Thoughts? Andrew >>> >>> Anyway, here is a patch which does that and a bit more. I didn't rename >>> build_assign() to ssa_build_assign().. even though those are the only kind >>> actually created right now. we can leave that for the day someone actually >>> decides to flush this interface out, and maybe we'll want to pass in >>> gimple_tmps and call them from front ends or other places... then it would >>> have to be renamed again. So I just left it as is for the moment, but that >>> could be changed. >>> >>> I also moved gimple_replace_lhs() to tree-ssa.c and renamed it >>> ssa_replace_lhs(). It calls insert_debug_temp_for_var_def() from tree-ssa.c >>> and that only works with the immediate use operands.. so that is an SSA >>> specific routine, which makes this one SSA specific as well. >>> >>> Those 2 changes allow tree-ssa.h to no longer be included, it is replaced >>> with tree-flow.h. Some preliminary work to enable removing immediate use >>> routines out of tree-flow.h include: >>> >>> struct count_ptr_d, count_ptr_derefs(), count_uses_and_derefs() also get >>> moved to tree-ssa.c since those are also require the immediate use >>> mechanism, and thus is also SSA dependent. >>> >>> This bootstraps on x86_64-unknown-linux-gnu and has no new regressions. >>> OK? >> >> Can you move the builders to asan.c please? > > No. They don't belong there. This is a high-level wrapper for the > low-level instruction builders. > >> to have various issues so it shouldn't be used (I wonder who approved them >> in the end ... maybe it was even me). > > Not really. I put it in and still need to flush it out a bit more. > I'll work on it. Maybe put it into a separate .c/.h file combo then? Richard. > > Diego.
Re: Ping^2: small patch to accept = inside GCC plugin arguments
On Mon, Sep 16, 2013 at 4:23 AM, Basile Starynkevitch wrote: > Hello All, > > I'm pinging again my small patch to accept = inside plugin arguments > http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00382.html OK. Diego.
Re: Ping patch to enable *.cc files in gengtype
On 2013-09-16 04:19 , Basile Starynkevitch wrote: Hello all, I'm pinging the patch (of september 2nd) on http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00036.html gcc/ChangeLog entry 2013-09-16 Basile Starynkevitch * gengtype.c (file_rules): Added rule for *.cc files. (get_output_file_with_visibility): Give fatal message when no rules found. OK. Diego.
Re: Drop generic32 cost model
On Fri, Sep 20, 2013 at 6:00 AM, Zamyatin, Igor wrote: > > For x86 32-bit is still important due to mobile market so we would like to > make some measurements first to see how this new generic model works on 32 > bits I would expect people compiling code for the mobile market to use an appropriate -mtune option. What this patch affects is the default tuning. Ian
[PATCH 2/3] Handle simple inheritance in gengtype.
Treat GTY structs that have a "desc" as being the root of an inheritance
hierarchy. Generate a switch on desc within the marking function with
cases for each subclass, visiting all fields of the type (including
inherited ones).
Don't create marking functions for subclasses, instead using the base
class marking functions. Use walk_type on them within walk_subclasses
to generate the case within the switch for handling the tag, directly
walking all fields of the type.
* gengtype.c (output_mangled_typename): Convert references
to classes within an inheritance hierarchy to reference the
ultimate base class, since only it will have gt_ functions.
(get_string_option): New.
(walk_subclasses): New.
(walk_type): Treat GTY structs that have a "desc" as being the
root of an inheritance hierarchy. Generate a switch on it
within the marking function which walks all subclasses, adding
cases for them via walk_subclasses. For subclasses, visit all
fields of the type (including inherited ones).
(write_func_for_structure): Don't write fns for subclasses, only
for the ultimate base class within an inheritance hierarchy.
Subclasses-marking will be handled by the base class marking
functions.
(write_types): Likewise.
(write_local_func_for_structure): Likewise.
(USED_BY_TYPED_GC_P): Emit allocators for subclasses.
(write_root): Use the marker function for the ultimate base class.
* gengtype.h (FOR_ALL_INHERITED_FIELDS): New.
---
gcc/gengtype.c | 100 ++---
gcc/gengtype.h | 5 +++
2 files changed, 100 insertions(+), 5 deletions(-)
diff --git a/gcc/gengtype.c b/gcc/gengtype.c
index a6dc221..a078b44 100644
--- a/gcc/gengtype.c
+++ b/gcc/gengtype.c
@@ -2534,6 +2534,11 @@ output_mangled_typename (outf_p of, const_type_p t)
case TYPE_LANG_STRUCT:
case TYPE_USER_STRUCT:
{
+ /* For references to classes within an inheritance hierarchy,
+only ever reference the ultimate base class, since only
+it will have gt_ functions. */
+ while (t->u.s.base_class)
+ t = t->u.s.base_class;
const char *id_for_tag = filter_type_name (t->u.s.tag);
oprintf (of, "%lu%s", (unsigned long) strlen (id_for_tag),
id_for_tag);
@@ -2596,6 +2601,42 @@ output_escaped_param (struct walk_type_data *d, const
char *param,
}
}
+const char *
+get_string_option (options_p opt, const char *key)
+{
+ for (; opt; opt = opt->next)
+if (strcmp (opt->name, key) == 0)
+ return opt->info.string;
+ return NULL;
+}
+
+static void
+walk_subclasses (type_p base, struct walk_type_data *d)
+{
+ for (type_p sub = structures; sub != NULL; sub = sub->next)
+{
+ if (sub->u.s.base_class == base)
+ {
+ const char *type_tag = get_string_option (sub->u.s.opt, "tag");
+ oprintf (d->of, "%*scase %s:\n", d->indent, "", type_tag);
+ d->indent += 2;
+ oprintf (d->of, "%*s{\n", d->indent, "");
+ d->indent += 2;
+ oprintf (d->of, "%*s%s *sub = static_cast <%s *> (x);\n",
+ d->indent, "", sub->u.s.tag, sub->u.s.tag);
+ const char *old_val = d->val;
+ d->val = "(*sub)";
+ walk_type (sub, d);
+ d->val = old_val;
+ d->indent -= 2;
+ oprintf (d->of, "%*s}\n", d->indent, "");
+ oprintf (d->of, "%*sbreak;\n", d->indent, "");
+ d->indent -= 2;
+
+ walk_subclasses (sub, d);
+ }
+}
+}
/* Call D->PROCESS_FIELD for every field (or subfield) of D->VAL,
which is of type T. Write code to D->OF to constrain execution (at
@@ -2613,6 +2654,7 @@ walk_type (type_p t, struct walk_type_data *d)
{
const char *length = NULL;
const char *desc = NULL;
+ const char *type_tag = NULL;
int maybe_undef_p = 0;
int use_param_num = -1;
int use_params_p = 0;
@@ -2641,7 +2683,7 @@ walk_type (type_p t, struct walk_type_data *d)
else if (strcmp (oo->name, "dot") == 0)
;
else if (strcmp (oo->name, "tag") == 0)
- ;
+ type_tag = oo->info.string;
else if (strcmp (oo->name, "special") == 0)
;
else if (strcmp (oo->name, "skip") == 0)
@@ -2960,8 +3002,21 @@ walk_type (type_p t, struct walk_type_data *d)
d->indent += 2;
oprintf (d->of, "%*s{\n", d->indent, "");
}
+ else
+ {
+ if (desc)
+ {
+ oprintf (d->of, "%*sswitch (", d->indent, "");
+ output_escaped_param (d, desc, "desc");
+ oprintf (d->of, ")\n");
+ d->indent += 2;
+ oprintf (d->of, "%*s{\n", d->indent, "");
+ oprintf (d->of, "%*scase %s:\n", d->indent, "", type_tag);
+ d->indent += 2;
+ }
+ }
- for (f = t->u.s.fields; f; f =
[PATCH 3/3] Convert symtab, cgraph and varpool nodes into a real class hierarchy
This patch is the handwritten part of the conversion of these types
to C++; it requires the followup patch, which is autogenerated.
It converts:
struct symtab_node_base
to:
class symtab_node_base
and converts:
struct cgraph_node
to:
struct cgraph_node : public symtab_node_base
and:
struct varpool_node
to:
class varpool_node : public symtab_node_base
dropping the symtab_node_def union.
This patch is essentially the same as older versions of this patch [1],
but drops the hand-written GTY markers and ugly dummy roots needed as
workarounds for bugs in how GTY((user)) works.
Instead, this version of the patch makes uses of the gengtype
inheritance support introduced earlier in the series.
The above types are actually:
class GTY((desc ("%h.type"), tag ("SYMTAB_SYMBOL"))) symtab_node_base
i.e. "use type as the discriminator for this class hierarchy" and
"for the base class symtab_node_base, type==SYMTAB_SYMBOL"
along with:
struct GTY((tag ("SYMTAB_FUNCTION"))) cgraph_node : public symtab_node_base
and:
class GTY((tag ("SYMTAB_VARIABLE"))) varpool_node : public symtab_node_base
The new gengtype is able to correctly generate marker functions for
the base class:
void
gt_ggc_mx_symtab_node_base (void *x_p);
void
gt_pch_nx_symtab_node_base (void *x_p);
void
gt_pch_p_16symtab_node_base (ATTRIBUTE_UNUSED void *this_obj,
void *x_p,
ATTRIBUTE_UNUSED gt_pointer_operator op,
ATTRIBUTE_UNUSED void *cookie);
and uses these for any of the types within the inheritance hierarchy.
[1] http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00672.html
gcc/
* cgraph.h (symtab_node_base): Convert to a class;
add GTY((desc ("%h.type"), tag ("SYMTAB_SYMBOL"))).
(cgraph_node): Inherit from symtab_node; add GTY option
tag ("SYMTAB_FUNCTION").
(varpool_node): Inherit from symtab_node; add GTY option
tag ("SYMTAB_VARIABLE").
(symtab_node_def): Remove.
(is_a_helper ::test (symtab_node_def *)): Convert to...
(is_a_helper ::test (symtab_node_base *)): ...this.
(is_a_helper ::test (symtab_node_def *)): Convert to...
(is_a_helper ::test (symtab_node_base *)): ...this.
* ipa-ref.h (symtab_node_def): Drop.
(symtab_node): Change underlying type from symtab_node_def to
symtab_node_base.
(const_symtab_node): Likwise.
* is-a.h: Update examples in comment.
* symtab.c (symtab_hash): Change symtab_node_def to symtab_node_base.
(assembler_name_hash): Likewise.
---
gcc/cgraph.h | 38 +++---
gcc/ipa-ref.h | 6 +++---
gcc/is-a.h| 6 +++---
gcc/symtab.c | 4 ++--
4 files changed, 19 insertions(+), 35 deletions(-)
diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index 50e8743..615067c 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -40,8 +40,9 @@ enum symtab_type
/* Base of all entries in the symbol table.
The symtab_node is inherited by cgraph and varpol nodes. */
-struct GTY(()) symtab_node_base
+class GTY((desc ("%h.type"), tag ("SYMTAB_SYMBOL"))) symtab_node_base
{
+public:
/* Type of the symbol. */
ENUM_BITFIELD (symtab_type) type : 8;
@@ -252,25 +253,19 @@ struct GTY(()) cgraph_clone_info
/* The cgraph data structure.
Each function decl has assigned cgraph_node listing callees and callers. */
-struct GTY(()) cgraph_node {
- struct symtab_node_base symbol;
+struct GTY((tag ("SYMTAB_FUNCTION"))) cgraph_node : public symtab_node_base {
+public:
struct cgraph_edge *callees;
struct cgraph_edge *callers;
/* List of edges representing indirect calls with a yet undetermined
callee. */
struct cgraph_edge *indirect_calls;
/* For nested functions points to function the node is nested in. */
- struct cgraph_node *
-GTY ((nested_ptr (union symtab_node_def, "(struct cgraph_node *)(%h)",
"(symtab_node)%h")))
-origin;
+ struct cgraph_node *origin;
/* Points to first nested function, if any. */
- struct cgraph_node *
-GTY ((nested_ptr (union symtab_node_def, "(struct cgraph_node *)(%h)",
"(symtab_node)%h")))
-nested;
+ struct cgraph_node *nested;
/* Pointer to the next function with same origin, if any. */
- struct cgraph_node *
-GTY ((nested_ptr (union symtab_node_def, "(struct cgraph_node *)(%h)",
"(symtab_node)%h")))
-next_nested;
+ struct cgraph_node *next_nested;
/* Pointer to the next clone. */
struct cgraph_node *next_sibling_clone;
struct cgraph_node *prev_sibling_clone;
@@ -518,9 +513,8 @@ typedef struct cgraph_edge *cgraph_edge_p;
/* The varpool data structure.
Each static variable decl has assigned varpool_node. */
-struct GTY(()) varpool_node {
- struct symtab_node_base symbol;
-
+class GTY((tag ("SYMTAB_VARIABLE"))) varpool_node : public symtab_node_base {
+public:
/* Set when variable is scheduled to be assembled. */
unsigned output : 1;
};
@@ -536,22 +530,12 @@ struct GTY(()) asm_node {
int order;
};
[PATCH 1/3] Parse base classes for GTY-marked types
Extend gengtype (and gtype.state reading/writing) so that it is able to
parse base classes in simple cases, and only attempt to do it for
GTY-marked types.
* gengtype-parse.c (require_without_advance): New.
(type): For GTY-marked types, parse any base classes, requiring
them to be single-inheritance, and not be templates. For
non-GTY-marked types, continued to skip over any C++ inheritance
specification.
* gengtype-state.c (state_writer::write_state_struct_type):
Write base class of type (if any).
(read_state_struct_type): Read base class of type (if any).
* gengtype.c (new_structure): Add a "base_class" parameter.
(create_optional_field_): Update for new parameter to
new_structure.
(adjust_field_rtx_def): Likewise.
(adjust_field_tree_exp): Likewise.
* gengtype.h (struct type): Add "base_class" field to the s
union field.
(new_structure): Add "base" parameter.
---
gcc/gengtype-parse.c | 47 +++
gcc/gengtype-state.c | 2 ++
gcc/gengtype.c | 15 ---
gcc/gengtype.h | 4 +++-
4 files changed, 56 insertions(+), 12 deletions(-)
diff --git a/gcc/gengtype-parse.c b/gcc/gengtype-parse.c
index 68d372e..aae2c6c 100644
--- a/gcc/gengtype-parse.c
+++ b/gcc/gengtype-parse.c
@@ -165,6 +165,21 @@ require (int t)
return v;
}
+/* As per require, but do not advance. */
+static const char *
+require_without_advance (int t)
+{
+ int u = token ();
+ const char *v = T.value;
+ if (u != t)
+{
+ parse_error ("expected %s, have %s",
+ print_token (t, 0), print_token (u, v));
+ return 0;
+}
+ return v;
+}
+
/* If the next token does not have one of the codes T1 or T2, report a
parse error; otherwise return the token's value. */
static const char *
@@ -818,6 +833,7 @@ type (options_p *optsp, bool nested)
case STRUCT:
case UNION:
{
+ type_p base_class = NULL;
options_p opts = 0;
/* GTY annotations follow attribute syntax
GTY_BEFORE_ID is for union/struct declarations
@@ -859,9 +875,31 @@ type (options_p *optsp, bool nested)
if (token () == ':')
{
- /* Skip over C++ inheritance specification. */
- while (token () != '{')
- advance ();
+ if (is_gty)
+ {
+ /* For GTY-marked types, parse some C++ inheritance
+ specifications.
+ We require single-inheritance from a non-template type. */
+ advance ();
+ const char *basename = require (ID);
+ /* This may be either an access specifier, or the base name. */
+ if (0 == strcmp (basename, "public")
+ || 0 == strcmp (basename, "protected")
+ || 0 == strcmp (basename, "private"))
+ basename = require (ID);
+ base_class = find_structure (basename, TYPE_STRUCT);
+ if (!base_class)
+ parse_error ("unrecognized base class: %s", basename);
+ require_without_advance ('{');
+ }
+ else
+ {
+ /* For types lacking GTY-markings, skip over C++ inheritance
+ specification (and thus avoid having to parse e.g. template
+ types). */
+ while (token () != '{')
+ advance ();
+ }
}
if (is_gty)
@@ -889,7 +927,8 @@ type (options_p *optsp, bool nested)
return create_user_defined_type (s, &lexer_line);
}
- return new_structure (s, kind, &lexer_line, fields, opts);
+ return new_structure (s, kind, &lexer_line, fields, opts,
+ base_class);
}
}
else if (token () == '{')
diff --git a/gcc/gengtype-state.c b/gcc/gengtype-state.c
index ba7948a..54e4287 100644
--- a/gcc/gengtype-state.c
+++ b/gcc/gengtype-state.c
@@ -957,6 +957,7 @@ state_writer::write_state_struct_type (type_p current)
{
write_state_struct_union_type (current, "struct");
write_state_type (current->u.s.lang_struct);
+ write_state_type (current->u.s.base_class);
}
/* Write a GTY user-defined struct type. */
@@ -1613,6 +1614,7 @@ read_state_struct_type (type_p type)
read_state_options (&(type->u.s.opt));
read_state_lang_bitmap (&(type->u.s.bitmap));
read_state_type (&(type->u.s.lang_struct));
+ read_state_type (&(type->u.s.base_class));
}
else
{
diff --git a/gcc/gengtype.c b/gcc/gengtype.c
index c3dffe8..a6dc221 100644
--- a/gcc/gengtype.c
+++ b/gcc/gengtype.c
@@ -674,7 +674,7 @@ resolve_typedef (const char *s, struct fileloc *pos)
type_p
new_structure (const char *name, enum typekind kind, struct fileloc *pos,
- pair_p fields, options_p
[PATCH 0/3] Support some cases of inheritance in gengtype; use it for symtab
There have been various discussions about how to handle inheritance
within ggc and PCH: whether to extend gengtype to support C++ syntax
such as templates, or to require people to use GTY((user)) and manually
write field-traversal.
I've attempted to introduce class hierarchies in a few places recently,
for example for the symtab types:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00668.html
and the gimple types:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01788.html
In each case the GTY((user)) is always the most painful part: it
requires ugly hand-written code which must be kept up-to-date with
changes to the underlying types, lest we run into
difficult-to-track-down crashes inside the GC and PCH.
I got sick of writing and debugging these GTY((user)) traversal
functions, for IMHO quite modest use of C++ (no templates etc), so I had
a go at implementing support for inheritance in gengtype, as seen in the
following patch series.
The key compromise I'm introducing, as I see it, is to require the user
to "opt in" to the support for the inheritance, on a class-by-class
basis, and not attempt to support all of C++, but only single
inheritance, without templates.
The idea is that if you add a GTY marker to a subclass, you are
"opting in" to gengtype, and on any restrictions on the base class that
gengtype needs to impose to avoid having to deal with all of C++ syntax:
specifically, no multiple inheritance, and the base class can't be a
template.
If those restrictions are too much, e.g. you have something like:
struct alloc_pool_hasher : typed_noop_remove
then don't GTY-mark the class, and gengtype won't attempt to parse the
base class (as per the current parser).
I can tweak things so that GTY((user)) classes are also excluded.
This compromise allows gengtype to autogenerate traversal functions for
simple uses of inheritance, avoiding the need for hand-maintaining them,
whilst allowing all of C++ for places that need it, without having to
support parsing all of that C++ syntax in gengtype - IMHO the best of
both approaches.
You put a "desc" GTY option on the base class to signify how to
discriminate between subclasses in the marker function. Every concrete
subclass should have a "tag" GTY option, and gengtype builds a single
set of traversal functions, for the base class of the hierarchy, with
a big switch statement on the desc, using the tag values as the cases.
This is of course very similar to how unions are handled, and is similar
to the first part of this proposal from Lawrence Crowl:
http://gcc.gnu.org/ml/gcc/2012-08/msg00267.html
Within such a hierarchy, traversal functions are only generated for the
base class.
I was able to use this to reimplement my port of the symtab types to a
C++ class hierarchy. The old, ugly version of the patch can be seen at:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00672.html
I've attached an updated version of the above patch to the following
patch series, which uses the new gengtype inheritance support to
eliminate all of the horrible hand-written traversal functions, and the
ugly dummy GTY roots that are needed to workaround bugs in GTY((user)).
Successfully bootstrapped and regtested this (plus the followup
autogenerated symtab refactoring from:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00669.html )
OK for trunk? IMHO this is a much simpler approach; it avoids
having to deal with GTY((user)) and manually-written markers.
Presumably I would also need to update the docs.
For reference, here's what one of the generated functions looks like (I
believe this is not significantly uglier that what gtype-desc.c already
contains). Note how the fields appear in reverse order of *types*
(i.e. from deepest subclass up to parent), within a field they appear in
natural order. So, for example, in "case SYMTAB_FUNCTION:" the cgraph
fields appear, then the base symtab fields. The two pch functions are
similar.
void
gt_ggc_mx_symtab_node_base (void *x_p)
{
struct symtab_node_base * const x = (struct symtab_node_base *)x_p;
if (ggc_test_and_set_mark (x))
{
switch (((*x)).type)
{
case SYMTAB_SYMBOL:
gt_ggc_m_9tree_node ((*x).decl);
gt_ggc_m_16symtab_node_base ((*x).next);
gt_ggc_m_16symtab_node_base ((*x).previous);
gt_ggc_m_16symtab_node_base ((*x).next_sharing_asm_name);
gt_ggc_m_16symtab_node_base ((*x).previous_sharing_asm_name);
gt_ggc_m_16symtab_node_base ((*x).same_comdat_group);
gt_ggc_m_20vec_ipa_ref_t_va_gc_ ((*x).ref_list.references);
gt_ggc_m_9tree_node ((*x).alias_target);
gt_ggc_m_18lto_file_decl_data ((*x).lto_file_data);
break;
case SYMTAB_VARIABLE:
{
varpool_node *sub = static_cast (x);
gt_ggc_m_9tree_node ((*sub).decl);
gt_ggc_m_16symtab_node_base ((*sub).next);
gt_ggc_m_16symtab_node_base ((*sub).previous);
gt_ggc_m_16symt
Re: [v3] More noexcept -- 5th
On Fri, 20 Sep 2013, Paolo Carlini wrote: On 09/20/2013 09:46 AM, Marc Glisse wrote: Hello, for basic_string, I tried not to add lies about exceptions, but I didn't remove existing ones. Of course we should not have lies, I thought we didn't, besides maybe special cases having to do with the FULLY_DYNAMIC string thing, really a C++98 legacy wa, which will not exist in the future. Can you please send an updated patch fixing those? Would you mind if we did that as a separate follow-up patch, unless there are other problems with the patch? One is adding noexcept for optimization, the other one would be removing some (no intersection) for correctness. I'll do it this WE. I'll also need to remove the corresponding noexcept from debug/profile mode... -- Marc Glisse
Re: [v3] More noexcept -- 5th
On 09/20/2013 04:09 PM, Marc Glisse wrote: On Fri, 20 Sep 2013, Paolo Carlini wrote: On 09/20/2013 09:46 AM, Marc Glisse wrote: Hello, for basic_string, I tried not to add lies about exceptions, but I didn't remove existing ones. Of course we should not have lies, I thought we didn't, besides maybe special cases having to do with the FULLY_DYNAMIC string thing, really a C++98 legacy wa, which will not exist in the future. Can you please send an updated patch fixing those? Would you mind if we did that as a separate follow-up patch, unless there are other problems with the patch? One is adding noexcept for optimization, the other one would be removing some (no intersection) for correctness. I'll do it this WE. I'll also need to remove the corresponding noexcept from debug/profile mode... Ok It's fine like that, and thank you for doing the work, please also add a one-line comment before the noexcept you remove explaining that we are non-conforming in not having those decorations but that's life until we get rid of the reference-counted implementation. Thanks again! By the way, I would be curious at some point to actually see with my eyes the effect of those optimizations in the assembly: is it easy to produce examples? Even at say -O2? Thanks, Paolo.
[PATCH][AARCH64]Replace gen_rtx_PLUS with plus_constant
Hello all,
This patch will replace all explicit calls to gen_rtx_PLUS and GEN_INT
with plus_constant.
This has been tested for aarch64-none-elf on the model.
OK for trunk?
Kind regards,
Renlin Li
gcc/ChangeLog:
2013-09-20 Renlin Li
* config/aarch64/aarch64.c (aarch64_expand_prologue): Use
plus_constant.
(aarch64_expand_epilogue): Likewise.
(aarch64_legitimize_reload_address): Likewise.diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index e8ae20a..c65d845 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -2065,9 +2065,9 @@ aarch64_expand_prologue (void)
emit_insn (gen_add2_insn (stack_pointer_rtx, op0));
aarch64_set_frame_expr (gen_rtx_SET
(Pmode, stack_pointer_rtx,
- gen_rtx_PLUS (Pmode,
- stack_pointer_rtx,
- GEN_INT (-frame_size;
+ plus_constant (Pmode,
+ stack_pointer_rtx,
+ -frame_size)));
}
else if (frame_size > 0)
{
@@ -2151,9 +2151,9 @@ aarch64_expand_prologue (void)
GEN_INT (fp_offset)));
aarch64_set_frame_expr (gen_rtx_SET
(Pmode, hard_frame_pointer_rtx,
- gen_rtx_PLUS (Pmode,
- stack_pointer_rtx,
- GEN_INT (fp_offset;
+ plus_constant (Pmode,
+ stack_pointer_rtx,
+ fp_offset)));
RTX_FRAME_RELATED_P (insn) = 1;
insn = emit_insn (gen_stack_tie (stack_pointer_rtx,
hard_frame_pointer_rtx));
@@ -2349,9 +2349,9 @@ aarch64_expand_epilogue (bool for_sibcall)
emit_insn (gen_add2_insn (stack_pointer_rtx, op0));
aarch64_set_frame_expr (gen_rtx_SET
(Pmode, stack_pointer_rtx,
- gen_rtx_PLUS (Pmode,
- stack_pointer_rtx,
- GEN_INT (frame_size;
+ plus_constant (Pmode,
+ stack_pointer_rtx,
+ frame_size)));
}
else if (frame_size > 0)
{
@@ -2373,10 +2373,10 @@ aarch64_expand_epilogue (bool for_sibcall)
}
}
- aarch64_set_frame_expr (gen_rtx_SET (Pmode, stack_pointer_rtx,
- gen_rtx_PLUS (Pmode,
- stack_pointer_rtx,
- GEN_INT (offset;
+aarch64_set_frame_expr (gen_rtx_SET (Pmode, stack_pointer_rtx,
+ plus_constant (Pmode,
+ stack_pointer_rtx,
+ offset)));
}
emit_use (gen_rtx_REG (DImode, LR_REGNUM));
@@ -4014,9 +4014,9 @@ aarch64_legitimize_reload_address (rtx *x_p,
/* Reload high part into base reg, leaving the low part
in the mem instruction. */
- x = gen_rtx_PLUS (xmode,
- gen_rtx_PLUS (xmode, XEXP (x, 0), cst),
- GEN_INT (low));
+ x = plus_constant (xmode,
+ gen_rtx_PLUS (xmode, XEXP (x, 0), cst),
+ low);
push_reload (XEXP (x, 0), NULL_RTX, &XEXP (x, 0), NULL,
BASE_REG_CLASS, xmode, VOIDmode, 0, 0,
[PATCH][ARM]Replace gen_rtx_PLUS with plus_constant
Hello all,
This patch will replace all explicit calls to gen_rtx_PLUS and GEN_INT
with plus_constant.
This has been tested for arm-none-linux-gnueabi on the model.
OK for trunk?
Kind regards,
Renlin Li
gcc/ChangeLog:
2013-09-20 Renlin Li
* config/arm/arm.c (arm_legitimize_reload_address): use
plus_constant().
(arm_output_mi_thunk): Likewise.diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index f9027dd..7004eef 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -7016,10 +7016,10 @@ arm_legitimize_reload_address (rtx *p,
/* Reload the high part into a base reg; leave the low part
in the mem. */
- *p = gen_rtx_PLUS (GET_MODE (*p),
- gen_rtx_PLUS (GET_MODE (*p), XEXP (*p, 0),
- GEN_INT (high)),
- GEN_INT (low));
+ *p = plus_constant (GET_MODE (*p),
+ plus_constant (GET_MODE (*p), XEXP (*p, 0),
+ high),
+ low);
push_reload (XEXP (*p, 0), NULL_RTX, &XEXP (*p, 0), NULL,
MODE_BASE_REG_CLASS (mode), GET_MODE (*p),
VOIDmode, 0, 0, opnum, (enum reload_type) type);
@@ -25335,7 +25335,7 @@ arm_output_mi_thunk (FILE *file, tree thunk ATTRIBUTE_UNUSED,
{
/* Output ".word .LTHUNKn-7-.LTHUNKPCn". */
rtx tem = XEXP (DECL_RTL (function), 0);
- tem = gen_rtx_PLUS (GET_MODE (tem), tem, GEN_INT (-7));
+ tem = plus_constant (GET_MODE (tem), tem, -7);
tem = gen_rtx_MINUS (GET_MODE (tem),
tem,
gen_rtx_SYMBOL_REF (Pmode,
Re: [v3] More noexcept -- 5th
On Fri, 20 Sep 2013, Paolo Carlini wrote: By the way, I would be curious at some point to actually see with my eyes the effect of those optimizations in the assembly: is it easy to produce examples? Even at say -O2? If you use "if(noexcept(container.shrink_to_fit()))", you can easily cause different code to be used. Now whether for regular code it somehow produces fewer implicit try-catch or some optimization like that, I have no idea. If it ever makes code worse, please beat the core- people who required std::terminate with a screen showing the benchmarks (I keep wanting to introduce -fno-abort -fno-terminate flags to turn those 2 calls into __builtin_unreachable). Note that I am still a proponent of noexcept(auto), if it can't be the default. If someone feels like implementing it as an extension, we could use it in the library. -- Marc Glisse
Re: [PATCH][AARCH64]Replace gen_rtx_PLUS with plus_constant
Thank you, can you please commit it for me? Kind regards, Renlin Li On 09/20/13 15:26, Marcus Shawcroft wrote: On 20 September 2013 15:18, Renlin Li wrote: 2013-09-20 Renlin Li * config/aarch64/aarch64.c (aarch64_expand_prologue): Use plus_constant. (aarch64_expand_epilogue): Likewise. (aarch64_legitimize_reload_address): Likewise. OK /Marcus
Re: [PATCH][AARCH64]Replace gen_rtx_PLUS with plus_constant
On 20 September 2013 15:18, Renlin Li wrote: > 2013-09-20 Renlin Li > > * config/aarch64/aarch64.c (aarch64_expand_prologue): Use plus_constant. > (aarch64_expand_epilogue): Likewise. > (aarch64_legitimize_reload_address): Likewise. OK /Marcus
Re: [PATCH 2/3] Handle simple inheritance in gengtype.
Hi,
On Fri, 20 Sep 2013, David Malcolm wrote:
> Treat GTY structs that have a "desc" as being the root of an inheritance
> hierarchy. Generate a switch on desc within the marking function with
> cases for each subclass, visiting all fields of the type (including
> inherited ones).
Yay! Thanks for working on that. I miss a change in set_gc_used_type
to mark base classes. When you construct a testcase where only derived
classes are used it should break because the base class marker isn't
emitted.
Apart from that I think I like it, there's a potential quadratic loop in
walk_subclasses, but I guess it doesn't really matter for the number of
gty types we have (and could be changed via a list of all derived classes
per base class if necessary).
Yes, it needs some updates to the documentation. Some minor nits:
> @@ -2960,8 +3002,21 @@ walk_type (type_p t, struct walk_type_data *d)
> d->indent += 2;
> oprintf (d->of, "%*s{\n", d->indent, "");
> }
> + else
> + {
> + if (desc)
> + {
else if (desc)
{
> }
> + else
> + {
> + if (desc)
> + {
Same.
> @@ -4076,7 +4162,9 @@ write_local (outf_p output_header, type_p structures,
> type_p param_structs)
> || ((s)->gc_used == GC_MAYBE_POINTED_TO \
> && s->u.s.line.file != NULL) \
> || ((s)->gc_used == GC_USED \
> -&& strncmp (s->u.s.tag, "anonymous", strlen ("anonymous"))
> +&& strncmp (s->u.s.tag, "anonymous", strlen ("anonymous"))) \
> +|| (s->u.s.base_class
> +
>
>
Watch for vertical white space.
Ciao,
Michael.
[PR58463][Backport to 4.8] Adjust dumping for ref nodes
Can we please backport this to 4.8 (it will fix PR58463)? I attach Richard's patch to master, let me know if instead I should create one specific for 4.8.1. I tested this against 4.8 branch and everything looks fine. 2013-03-27 Richard Biener PR tree-optimization/56716 * tree-ssa-structalias.c (perform_var_substitution): Adjust dumping for ref nodes. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-structalias.c Paulo Matos pr58463.patch Description: pr58463.patch
Re: [PATCH 3/3] Convert symtab, cgraph and varpool nodes into a real class hierarchy
> This patch is the handwritten part of the conversion of these types
> to C++; it requires the followup patch, which is autogenerated.
>
> It converts:
> struct symtab_node_base
> to:
> class symtab_node_base
>
> and converts:
> struct cgraph_node
> to:
> struct cgraph_node : public symtab_node_base
> and:
> struct varpool_node
> to:
> class varpool_node : public symtab_node_base
>
> dropping the symtab_node_def union.
Yep, incrementally we should continue with the grand renaming
retiring symtab_node_base and getting things symmetric.
>
> * cgraph.h (symtab_node_base): Convert to a class;
> add GTY((desc ("%h.type"), tag ("SYMTAB_SYMBOL"))).
> (cgraph_node): Inherit from symtab_node; add GTY option
> tag ("SYMTAB_FUNCTION").
> (varpool_node): Inherit from symtab_node; add GTY option
> tag ("SYMTAB_VARIABLE").
> (symtab_node_def): Remove.
> (is_a_helper ::test (symtab_node_def *)): Convert to...
> (is_a_helper ::test (symtab_node_base *)): ...this.
> (is_a_helper ::test (symtab_node_def *)): Convert to...
> (is_a_helper ::test (symtab_node_base *)): ...this.
>
> * ipa-ref.h (symtab_node_def): Drop.
> (symtab_node): Change underlying type from symtab_node_def to
> symtab_node_base.
> (const_symtab_node): Likwise.
>
> * is-a.h: Update examples in comment.
>
> * symtab.c (symtab_hash): Change symtab_node_def to symtab_node_base.
> (assembler_name_hash): Likewise.
This patch is OK. Thanks for working on this!
Honza
[PR58463] New testcase for pr58463
Please find the patch attached. I have added the test to gcc.c-torture, please let me know if this is not the right place. 2013-09-20 Paulo Matos * gcc.c-torture/pr58463.c: New testcase. Paulo Matos pr58463-testcase.patch Description: pr58463-testcase.patch
Re: [PATCH, AArch64] Fix the pointer-typed function argument expansion in aarch64_simd_expand_args
On 10 September 2013 18:12, Yufeng Zhang wrote: > gcc/ > > * config/aarch64/aarch64-builtins.c (aarch64_simd_expand_args): > Call aarch64_simd_expand_args to update op[argc]. OK /Marcus
Re: Drop generic32 cost model
> On Fri, Sep 20, 2013 at 6:00 AM, Zamyatin, Igor > wrote: > > > > For x86 32-bit is still important due to mobile market so we would like to > > make some measurements first to see how this new generic model works on 32 > > bits I assume by mobile market you mean atom CPU these days (not Pentium-M generic32 was tuned for). > > I would expect people compiling code for the mobile market to use an > appropriate -mtune option. What this patch affects is the default > tuning. I agree here. Moreover the 32bit generic model is not at all that new. It is same as the old code only flipping the four flags I mentioned plus changing the scheduling to K8 instead of PPro based model. The flags changed are: use_leave - this was there because pentium-M was slow on leave instructions. How does atom behave here? avoid_vector_decode - this is affecting gneration of integer->FP conversions K8 preferred to use vector instructions to avoid penalty. We now enable the flag: m_CORE_ALL | m_K8 | m_GENERIC64 I suppose we enabled it for Generic as a result of the overall ideology of not using instructions in generic that have evil performance on one of CPUs we consider important for generic. I think the flag was copied to CORE as a result of core tunning being based on generic tuning and hsould be dropped - both from core and generic based on fact that newer AMD CPUs do not care. slow_imul_imm32_mem slow_imul_imm8 This enables splitting of those instructions into move+mul that should not be terrible for atom either. Again, I think this flag is mistakely enabled for core. I need to dig up the thread we had last year about dropping some of these - as I recall, all except for inc/dec was fine. Honza > > Ian
Re: Ping patch to enable *.cc files in gengtype
On Fri, Sep 20, 2013 at 09:53:10AM -0400, Diego Novillo wrote:
> On 2013-09-16 04:19 , Basile Starynkevitch wrote:
> >Hello all,
> >
> >I'm pinging the patch (of september 2nd) on
> >http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00036.html
> >
> >
> > gcc/ChangeLog entry
> >
> >2013-09-16 Basile Starynkevitch
> >
> > * gengtype.c (file_rules): Added rule for *.cc files.
> > (get_output_file_with_visibility): Give fatal message when no
> > rules found.
>
> OK.
Thanks for the review and the approval. I just commited revision 202782.
BTW, I believe this patch should be back ported, at least to next GCC 4.8.2
(and perhaps even to 4.7). What do you think?
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Ping^2: small patch to accept = inside GCC plugin arguments
On Fri, Sep 20, 2013 at 09:49:34AM -0400, Diego Novillo wrote:
> On Mon, Sep 16, 2013 at 4:23 AM, Basile Starynkevitch
> wrote:
> > Hello All,
> >
> > I'm pinging again my small patch to accept = inside plugin arguments
> > http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00382.html
>
> OK.
Thanks for the review and the approval. I also think that the above patch
should be backported to 4.7 & 4.8
Committed revision 202783.
What do you think?
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Ping patch to enable *.cc files in gengtype
On Fri, Sep 20, 2013 at 05:52:38PM +0200, Basile Starynkevitch wrote: > On Fri, Sep 20, 2013 at 09:53:10AM -0400, Diego Novillo wrote: > > On 2013-09-16 04:19 , Basile Starynkevitch wrote: > > >Hello all, > > > > > >I'm pinging the patch (of september 2nd) on > > >http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00036.html > > > > > > > > > gcc/ChangeLog entry > > > > > >2013-09-16 Basile Starynkevitch > > > > > > * gengtype.c (file_rules): Added rule for *.cc files. > > > (get_output_file_with_visibility): Give fatal message when no > > > rules found. > > > > OK. > > Thanks for the review and the approval. I just commited revision 202782. > > BTW, I believe this patch should be back ported, at least to next GCC 4.8.2 > (and perhaps even to 4.7). What do you think? Why? There are no *.cc files in 4.8.x and I don't see why this patch would be desirable for the release branches. Jakub
Re: [gomp4] C++ OpenMP user defined reductions (take 2)
On 09/12/2013 04:55 AM, Jakub Jelinek wrote:
- if (t1 != t2)
+ if (t1 != t2 && !DECL_OMP_DECLARE_REDUCTION_P (newdecl))
return 0;
What's the theory here? Why should decls_match return true for
reductions with mismatching templates?
+ && ! (DECL_OMP_DECLARE_REDUCTION_P (newdecl)
+ && DECL_CONTEXT (newdecl) == NULL_TREE
+ && DECL_CONTEXT (olddecl) == current_function_decl))
And this looks like you need to set DECL_CONTEXT sooner on reductions.
+ if (TREE_CODE (argtype) == REFERENCE_TYPE)
+ error_at (DECL_SOURCE_LOCATION (t),
+ "function, array or reference type in "
+ "%<#pragma omp declare reduction%>");
Let's just say "reference type", since we know that's what it is.
+&& DECL_CONTEXT (pattern_decl)
+&& TREE_CODE (DECL_CONTEXT (pattern_decl))
+ == FUNCTION_DECL)
This is DECL_FUNCTION_SCOPE_P.
+ return TREE_CODE (TREE_TYPE (decl)) == REFERENCE_TYPE
+|| is_invisiref_parm (decl);
Needs parens to protect indentation.
+/* Instantiate the special body of the artificial DECL_OMP_DECLARE_REDUCTION
+ function. */
We could use documentation of what this special body looks like, either
here, in cp_check_omp_declare_reduction, or elsewhere.
+ for (ix = 0; BINFO_BASE_ITERATE (binfo, ix, base_binfo); ix++)
+ {
+ id = omp_reduction_lookup (loc, orig_id, BINFO_TYPE (base_binfo));
+ if (id != NULL_TREE)
+ return id;
This should check for ambiguity rather than returning the first match.
+ Also append INIT_EXPR for DECL_INITIAL of omp_priv after its
+ DECL_EXPR. */
Why not let the DECL_EXPR handle initialization?
Let's break out the finish_omp_clauses reduction code into a separate
function, as it's rather large.
+ if (DECL_TEMPLATE_INFO (id))
+ id = instantiate_decl (id, /*defer_ok*/0, true);
Let's use mark_used instead.
+ if (TREE_CODE (body) == STATEMENT_LIST)
+ {
Maybe this should be an assert?
Jason
Re: [PR58463] New testcase for pr58463
On Fri, Sep 20, 2013 at 03:45:17PM +, Paulo Matos wrote:
> Please find the patch attached.
>
> I have added the test to gcc.c-torture, please let me know if this is not the
> right place.
>
> 2013-09-20 Paulo Matos
>
> * gcc.c-torture/pr58463.c: New testcase.
That is not the right place (and, note the ChangeLog entry refers to a
different path than the testcase, and doesn't have space before <.), such
test should go into gcc.dg/. But, more importantly, the test doesn't
cleanup after itself. I bet it is enough to test just one dump that
was actually crashing rather than all of them, so please change that
to -fdump-tree--all and add corresponding:
/* { dg-final { cleanup-tree-dump "" } } */
line. Or, if you really want to test more than one pass dump, add
the individual -fdump-tree-pass1-all -fdump-tree-otherpass2-all
and corresponding cleanup-tree-dump lines for each of them. I don't think
there is a way to get all dumps cleaned up.
Jakub
Re: [PATCH] Fixing improper conversion from sin() to sinf() in optimization mode.
Any comment or more suggestions on this patch?
thanks,
Cong
On Mon, Sep 9, 2013 at 7:28 PM, Cong Hou wrote:
> On Mon, Sep 9, 2013 at 6:26 PM, Xinliang David Li wrote:
>> On Fri, Sep 6, 2013 at 3:24 PM, Cong Hou wrote:
>>> First, thank you for your detailed comments again! Then I deeply
>>> apologize for not explaining my patch properly and responding to your
>>> previous comment. I didn't understand thoroughly the problem before
>>> submitting the patch.
>>>
>>> Previously I only considered the following three conversions for sqrt():
>>>
>>>
>>> 1: (float) sqrt ((double) float_val) -> sqrtf (float_val)
>>> 2: (float) sqrtl ((long double) float_val) -> sqrtf (float_val)
>>> 3: (double) sqrtl ((long double) double_val) -> sqrt (double_val)
>>>
>>>
>>> We have four types here:
>>>
>>> TYPE is the type to which the result of the function call is converted.
>>> ITYPE is the type of the math call expression.
>>> TREE_TYPE(arg0) is the type of the function argument (before type
>>> conversion).
>>> NEWTYPE is chosen from TYPE and TREE_TYPE(arg0) with higher precision.
>>> It will be the type of the new math call expression after conversion.
>>>
>>> For all three cases above, TYPE is always the same as NEWTYPE. That is
>>> why I only considered TYPE during the precision comparison. ITYPE can
>>> only be double_type_node or long_double_type_node depending on the
>>> type of the math function. That is why I explicitly used those two
>>> types instead of ITYPE (no correctness issue). But you are right,
>>> ITYPE is more elegant and better here.
>>>
>>> After further analysis, I found I missed two more cases. Note that we
>>> have the following conditions according to the code in convert.c:
>>>
>>> TYPE_PRECISION(NEWTYPE) >= TYPE_PRECISION(TYPE)
>>> TYPE_PRECISION(NEWTYPE) >= TYPE_PRECISION(TREE_TYPE(arg0))
>>> TYPE_PRECISION (NEWTYPE) < TYPE_PRECISION (ITYPE)
>>>
>>> the last condition comes from the fact that we only consider
>>> converting a math function call into another one with narrower type.
>>> Therefore we have
>>>
>>> TYPE_PRECISION(TYPE) < TYPE_PRECISION (ITYPE)
>>> TYPE_PRECISION(TREE_TYPE(arg0)) < TYPE_PRECISION (ITYPE)
>>>
>>> So for sqrt(), TYPE and TREE_TYPE(arg0) can only be float, and for
>>> sqrtl(), TYPE and TREE_TYPE(arg0) can be either float or double with
>>> four possible combinations. Therefore we have two more conversions to
>>> consider besides the three ones I mentioned above:
>>>
>>>
>>> 4: (float) sqrtl ((long double) double_val) -> (float) sqrt (double_val)
>>> 5: (double) sqrtl ((long double) float_val) -> sqrt ((double) float_val)
>>>
>>>
>>> For the first conversion here, TYPE (float) is different from NEWTYPE
>>> (double), and my previous patch doesn't handle this case.The correct
>>> way is to compare precisions of ITYPE and NEWTYPE now.
>>>
>>> To sum up, we are converting the expression
>>>
>>> (TYPE) sqrtITYPE ((ITYPE) expr)
>>>
>>> to
>>>
>>> (TYPE) sqrtNEWTYPE ((NEWTYPE) expr)
>>>
>>> and we require
>>>
>>> PRECISION (ITYPE) >= PRECISION (NEWTYPE) * 2 + 2
>>>
>>> to make it a safe conversion.
>>>
>>>
>>> The new patch is pasted below.
>>>
>>> I appreciate your detailed comments and analysis, and next time when I
>>> submit a patch I will be more carefully about the reviewer's comment.
>>>
>>>
>>> Thank you!
>>>
>>> Cong
>>>
>>>
>>>
>>> Index: gcc/convert.c
>>> ===
>>> --- gcc/convert.c (revision 201891)
>>> +++ gcc/convert.c (working copy)
>>> @@ -135,16 +135,19 @@ convert_to_real (tree type, tree expr)
>>>CASE_MATHFN (COS)
>>>CASE_MATHFN (ERF)
>>>CASE_MATHFN (ERFC)
>>> - CASE_MATHFN (FABS)
>>>CASE_MATHFN (LOG)
>>>CASE_MATHFN (LOG10)
>>>CASE_MATHFN (LOG2)
>>>CASE_MATHFN (LOG1P)
>>> - CASE_MATHFN (LOGB)
>>>CASE_MATHFN (SIN)
>>> - CASE_MATHFN (SQRT)
>>>CASE_MATHFN (TAN)
>>>CASE_MATHFN (TANH)
>>> +/* The above functions are not safe to do this conversion. */
>>> +if (!flag_unsafe_math_optimizations)
>>> + break;
>>> + CASE_MATHFN (SQRT)
>>> + CASE_MATHFN (FABS)
>>> + CASE_MATHFN (LOGB)
>>> #undef CASE_MATHFN
>>> {
>>>tree arg0 = strip_float_extensions (CALL_EXPR_ARG (expr, 0));
>>> @@ -155,6 +158,27 @@ convert_to_real (tree type, tree expr)
>>>if (TYPE_PRECISION (TREE_TYPE (arg0)) > TYPE_PRECISION (type))
>>> newtype = TREE_TYPE (arg0);
>>>
>>> + /* We consider to convert
>>> +
>>> + (T1) sqrtT2 ((T2) exprT3)
>>> + to
>>> + (T1) sqrtT4 ((T4) exprT3)
>>
>> Should this be
>>
>> (T4) sqrtT4 ((T4) exprT3)
>
> T4 is not necessarily the same as T1. For the conversion:
>
> (float) sqrtl ((long double) double_val) -> (float) sqrt (double_val)
>
> T4 is double and T1 is float.
>
>
>>> +
>>> + , where T1 is TYPE, T2 is ITYPE, T3 is TREE_TYPE (ARG0),
>>> + and T4 is NEWTYPE.
>>
>> NEWTYPE is also the wider one between T1 and T3.
>
> Right. Actually this is easy to catch from the context just before
> th
Re: [gomp4] C++ OpenMP user defined reductions (take 2)
Hi!
On Fri, Sep 20, 2013 at 12:00:41PM -0400, Jason Merrill wrote:
Thanks for the review, I'll try to get to most of that next week.
> On 09/12/2013 04:55 AM, Jakub Jelinek wrote:
> >- if (t1 != t2)
> >+ if (t1 != t2 && !DECL_OMP_DECLARE_REDUCTION_P (newdecl))
> > return 0;
>
> What's the theory here? Why should decls_match return true for
> reductions with mismatching templates?
In templates the UDRs are always FUNCTION_DECLs in classes or
at function block scope, the above one liner was I believe for the latter,
where without it duplicate_decls was returning incorrectly 0; the UDRs
from mismatching templates would actually never be seen by duplicate_decls,
but t1 was different from t2. That was before the changes to
add the mangled names to the UDR DECL_NAMEs though, I can try to remove it
and see if the whole testsuite still passes.
> >+ && ! (DECL_OMP_DECLARE_REDUCTION_P (newdecl)
> >+&& DECL_CONTEXT (newdecl) == NULL_TREE
> >+&& DECL_CONTEXT (olddecl) == current_function_decl))
>
> And this looks like you need to set DECL_CONTEXT sooner on reductions.
I know it is ugly, but setting FUNCTION_DECL DECL_CONTEXT too early resulted
in all kinds of problems, when the C++ frontend doesn't support nested
functions. So the patch doesn't set DECL_CONTEXT until it is pushdecled
into the block scope. The combiner/initializer expressions can't use vars
other than omp_{out,in,priv,orig}, so the UDRs aren't really nested in the
C nested function sense, and after all, after parsing the FUNCTION_DECL
for UDRs is just a container holding the expressions and artificial
VAR_DECLs, and is a FUNCTION_DECL so that normal C++ lookups can be
performed on it.
But like with the above, perhaps it isn't needed anymore, as with the
mangled type names in DECL_NAMEs we shouldn't really use overloads for UDRs.
> >+if (TREE_CODE (argtype) == REFERENCE_TYPE)
> >+ error_at (DECL_SOURCE_LOCATION (t),
> >+"function, array or reference type in "
> >+"%<#pragma omp declare reduction%>");
>
> Let's just say "reference type", since we know that's what it is.
That is true, but I wanted to match the same error message elsewhere,
otherwise the error will be different (more specific) for instantiation
vs. in non-template code. Though, I could of course in that second spot
just special case REFERENCE_TYPE with a separate error message
and just have one about function or array type.
>
> >+ && DECL_CONTEXT (pattern_decl)
> >+ && TREE_CODE (DECL_CONTEXT (pattern_decl))
> >+== FUNCTION_DECL)
>
> This is DECL_FUNCTION_SCOPE_P.
>
> >+ return TREE_CODE (TREE_TYPE (decl)) == REFERENCE_TYPE
> >+ || is_invisiref_parm (decl);
>
> Needs parens to protect indentation.
>
> >+/* Instantiate the special body of the artificial DECL_OMP_DECLARE_REDUCTION
> >+ function. */
>
> We could use documentation of what this special body looks like,
> either here, in cp_check_omp_declare_reduction, or elsewhere.
3xOk.
>
> >+ for (ix = 0; BINFO_BASE_ITERATE (binfo, ix, base_binfo); ix++)
> >+{
> >+ id = omp_reduction_lookup (loc, orig_id, BINFO_TYPE (base_binfo));
> >+ if (id != NULL_TREE)
> >+return id;
>
> This should check for ambiguity rather than returning the first match.
I believe I need to discuss that on omp-lang, what exactly is the intended
behavior (and get the standard clarified). Returning the first base class
is an option (and, depth-first vs. breadth-first?), or erroring out if more
than one base class has an UDR is another.
> >+ Also append INIT_EXPR for DECL_INITIAL of omp_priv after its
> >+ DECL_EXPR. */
>
> Why not let the DECL_EXPR handle initialization?
I can try that.
> Let's break out the finish_omp_clauses reduction code into a
> separate function, as it's rather large.
Will try that.
>
> >+if (DECL_TEMPLATE_INFO (id))
> >+ id = instantiate_decl (id, /*defer_ok*/0, true);
>
> Let's use mark_used instead.
Will that always instantiate it?
Jakub
[PATCH] Missing dg-final for cleanup in test
ssa-dom-thread-3.c was missing its dg-final clause to clean up the log
files. Installed onto the trunk.
Jeff
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 0d6438b..a9a1513 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2013-09-17 Jeff Law
+
+ * gcc.dg/tree-ssa/ssa-dom-thread-3.c: Add missing dg-final clause.
+
2013-09-20 Bernd Edlinger
PR middle-end/57748
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-3.c
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-3.c
index c2efd15..d2a1fbb 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-3.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-3.c
@@ -45,3 +45,5 @@ expand_one_var (tree var, unsigned char toplevel, unsigned
char really_expand)
/* { dg-final { scan-tree-dump-times "Threaded" 1 "dom1"} } */
/* { dg-final { scan-tree-dump-times "Registering jump thread .through joiner
block.: \\(.*\\); \\(.*\\); \\(.*\\);" 1 "dom1"} } */
+/* { dg-final { cleanup-tree-dump "dom1" } } */
+
Re: [PATCH] manage dom-walk_data initialization and finalization with constructors and destructors
On 09/20/2013 02:13 AM, Richard Biener wrote: On Thu, Sep 19, 2013 at 8:11 PM, Richard Sandiford wrote: Michael Matz writes: What's the benefit of reading and writing such noisy lines? : *out_mode = mode_; mode_ = GET_MODE_WIDER_MODE (mode_); count_++; The uglification merely makes code harder to write and read, it should be used in cases where you _don't_ want developers to write such names. Heh. Since it's my code being used as the example here: I also find it very ugly FWIW. I only added the underscores because that's what the conventions said. But we're never going to get consensus on this kind of thing. E.g. I know some people really hate the GNU formatting style (although I very much like it). So I just held my nose while writing the patch. Btw, I've come around multiple coding-styles in the past and I definitely would prefer m_mode / m_count to mark members vs. mode_ and count_. (and s_XXX for static members IIRC). That would be fine with me. If you want to propose this as a change to our coding standards, I'd support it. Then it's just a matter of changing the existing code.. Sigh.. jeff
Re: [PATCH] Simplify & refactor a bit of tree-ssa-dom.c
On 09/20/2013 02:00 AM, Richard Biener wrote:
diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index aac7aa4..f561386 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -1070,6 +1070,31 @@ simplify_stmt_for_jump_threading (gimple stmt,
return lookup_avail_expr (stmt, false);
}
+static void
+record_temporary_equivalences (edge e)
+{
This new function lacks a comment.
Thanks. I'll take care of it.
jeff
[PATCH] Fix missing comment
Richi noticed I'd added a function without a block comment. This patch
fixes that oversight.
Installed onto the trunk after a stage1 build to ensure I didn't do
something stupid like forget to close a comment :-)
Jeff
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 6d93bab..e2fff6c 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2013-09-20 Jeff Law
+
+ * tree-ssa-dom.c (record_temporary_equivalences): Add comment.
+
2013-09-20 Yufeng Zhang
* config/aarch64/aarch64-builtins.c (aarch64_simd_expand_args):
diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index f561386..f0cc0ee 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -1070,6 +1070,10 @@ simplify_stmt_for_jump_threading (gimple stmt,
return lookup_avail_expr (stmt, false);
}
+/* Record into the equivalence tables any equivalences implied by
+ traversing edge E (which are cached in E->aux).
+
+ Callers are responsible for managing the unwinding markers. */
static void
record_temporary_equivalences (edge e)
{
Re: [C++1y] [PATCH 1/4] Use translation-unit-global rather than parameter-list-local counter for generic type names to facilitate nested implicit function templates.
On 09/19/2013 02:37 PM, Adam Butcher wrote: + static int i = 0; I think this needs to be global and GTY so that it works properly with PCH. Jason
Re: [C++1y] [PATCH 3/4] Ensure implicit template parameters have distinct canonical types.
Why is canonical_type_parameter not doing the right thing here? I don't see a reason we should need to treat these differently from normal template parms. Jason
Re: [PATCH] target/56875: Work around buggy GAS
On Sep 20, 2013, at 9:58 AM, Jan-Benedict Glaw wrote: > Hi! > > VAX GAS has a glitch when generating a 64bit value from a small > negative integer, which isn't properly sign-extended. (I'll see if > this can be fixed without breaking other cases.) > > However, GCC should work around this by simply using the already > prepared formatting operand code 'D'. The patch also introduces a new > vax.exp fragment (under gcc.target). > > Ok? Yes.
Re: [C++1y] [PATCH 4/4] Generate more intuitive name for 'auto' parameters.
OK. Jason
Re: [PATCH 1/3] Parse base classes for GTY-marked types
On Sep 20, 2013, at 7:05 AM, David Malcolm wrote: > Extend gengtype (and gtype.state reading/writing) so that it is able to > parse base classes in simple cases, and only attempt to do it for > GTY-marked types. I endorse this, and look forward to using it in the wide-int branch. I expect it should remove my lower quality handling of bases in that branch (my derived classes had no data, and I only had to support types with no pointers, no complexity, just integral types). Looks nice, simple and clean.
[PATCH] target/56875: Work around buggy GAS
Hi!
VAX GAS has a glitch when generating a 64bit value from a small
negative integer, which isn't properly sign-extended. (I'll see if
this can be fixed without breaking other cases.)
However, GCC should work around this by simply using the already
prepared formatting operand code 'D'. The patch also introduces a new
vax.exp fragment (under gcc.target).
Ok?
diff --git a/gcc/config/vax/vax.c b/gcc/config/vax/vax.c
index 53189a7..6b643d1 100644
--- a/gcc/config/vax/vax.c
+++ b/gcc/config/vax/vax.c
@@ -1187,7 +1187,7 @@ vax_output_int_move (rtx insn ATTRIBUTE_UNUSED, rtx
*operands,
{
operands[1] = GEN_INT (lval);
operands[2] = GEN_INT (n);
- return "ashq %2,%1,%0";
+ return "ashq %2,%D1,%0";
}
#if HOST_BITS_PER_WIDE_INT == 32
}
@@ -1199,7 +1199,7 @@ vax_output_int_move (rtx insn ATTRIBUTE_UNUSED, rtx
*operands,
{
operands[1] = GEN_INT (hval >> n);
operands[2] = GEN_INT (n + 32);
- return "ashq %2,%1,%0";
+ return "ashq %2,%D1,%0";
#endif
}
}
diff --git a/gcc/config/vax/vax.md b/gcc/config/vax/vax.md
index eadde18..2c05d00 100644
--- a/gcc/config/vax/vax.md
+++ b/gcc/config/vax/vax.md
@@ -697,14 +697,14 @@
(ashift:DI (match_operand:DI 1 "general_operand" "g")
(match_operand:QI 2 "general_operand" "g")))]
""
- "ashq %2,%1,%0")
+ "ashq %2,%D1,%0")
(define_insn ""
[(set (match_operand:DI 0 "nonimmediate_operand" "=g")
(ashiftrt:DI (match_operand:DI 1 "general_operand" "g")
(neg:QI (match_operand:QI 2 "general_operand" "g"]
""
- "ashq %2,%1,%0")
+ "ashq %2,%D1,%0")
;; We used to have expand_shift handle logical right shifts by using extzv,
;; but this make it very difficult to do lshrdi3. Since the VAX is the
diff --git a/gcc/testsuite/gcc.target/vax/pr56875.c
b/gcc/testsuite/gcc.target/vax/pr56875.c
new file mode 100644
index 000..f409afe
--- /dev/null
+++ b/gcc/testsuite/gcc.target/vax/pr56875.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O0" } */
+/* { dg-final { scan-assembler "ashq .*,\\\$0x," } } */
+/* { dg-final { scan-assembler-not "ashq .*,\\\$-1," } } */
+
+void
+a (void)
+{
+ unsigned long i = 1;
+ unsigned long long v;
+
+ v = ~ (unsigned long long) 0 << i;
+}
diff --git a/gcc/testsuite/gcc.target/vax/vax.exp
b/gcc/testsuite/gcc.target/vax/vax.exp
new file mode 100644
index 000..2aec4ee
--- /dev/null
+++ b/gcc/testsuite/gcc.target/vax/vax.exp
@@ -0,0 +1,41 @@
+# Copyright (C) 2013 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+#
Re: [PATCH] target/56875: Work around buggy GAS
On Fri, 2013-09-20 18:58:23 +0200, Jan-Benedict Glaw wrote: > VAX GAS has a glitch when generating a 64bit value from a small > negative integer, which isn't properly sign-extended. (I'll see if > this can be fixed without breaking other cases.) > > However, GCC should work around this by simply using the already > prepared formatting operand code 'D'. The patch also introduces a new > vax.exp fragment (under gcc.target). > > Ok? [...] Forgot the ChangeLog entry: PR56875: 2013-09-20 Martin Husemann Jan-Benedict Glaw gcc/ * config/vax/vax.c (vax_output_int_move): Use D format specifier. * config/vax/vax.md (ashldi3, ): Ditto gcc/testsuite/ * gcc.target/vax/vax.exp: New. * gcc.target/vax/pr56875.c: Ditto. MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: http://perl.plover.com/Questions.html the second : signature.asc Description: Digital signature
Re: [C++1y] [PATCH 2/4] Support nested generic lambdas.
OK. Jason
[PATCH] Silence an unused variable warning
Hi!
With the VAX target, I see this warning:
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I.
-I. -I../../../../gcc/gcc -I../../../../gcc/gcc/.
-I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include
-I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../../../gcc/gcc/../libbacktrace
../../../../gcc/gcc/lra-eliminations.c -o lra-eliminations.o
../../../../gcc/gcc/lra-eliminations.c: In function ‘void init_elim_table()’:
../../../../gcc/gcc/lra-eliminations.c:1162:8: warning: unused variable
‘value_p’ [-Wunused-variable]
bool value_p;
^
This is because we don't eliminate any registers (beyond GCC's
internal default). Fixed by moving this variable into the #ifdef block
to which it belongs.
2013-09-20 Jan-Benedict Glaw
gcc/
* lra-eliminations.c (update_reg_eliminate): Guard value_p.
diff --git a/gcc/lra-eliminations.c b/gcc/lra-eliminations.c
index f2a5751..c332575 100644
--- a/gcc/lra-eliminations.c
+++ b/gcc/lra-eliminations.c
@@ -1159,9 +1159,9 @@ update_reg_eliminate (bitmap insns_with_changed_offsets)
static void
init_elim_table (void)
{
- bool value_p;
struct elim_table *ep;
#ifdef ELIMINABLE_REGS
+ bool value_p;
const struct elim_table_1 *ep1;
#endif
MfG, JBG
--
Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481
Signature of: 17:44 <@uschebit> Evangelist ist doch ein Vertriebler
the second : für unverkäufliche Produkte, oder? (#korsett, 20120821)
signature.asc
Description: Digital signature
Re: [PATCH] Ensure testing is done with -fdiagnostics-color=never in the testsuite
On Sep 20, 2013, at 3:28 AM, Jakub Jelinek wrote: > When testing gcc with GCC_COLORS=' ' in the environment, > gcc/testsuite/lib/*.exp makes sure -fdiagnostics-color=never is added > and thus doesn't confuse the regexps checking for gcc output (which > in dejagnu goes to a pseudo tty and thus can be colorized even with > -fdiagnostics-color=auto), but apparently libstdc++-v3, libgomp and > libmudflap testsuites don't do that, so some tests FAIL because of that. > > Fixed thusly, ok for trunk? Ok.
Re: [C++ Patch] PR 58481
OK. Jason
[google, patch] Google-local version of fix for PR58312, libssp cross-compiling
Diego - In http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00174.html I proposed a patch to fix PR58312, which is that libssp when cross-compiled assumes that vnsprintf is broken [1]. This is causing our libssp.so to be missing some symbols that are referenced by some pre-existing binaries. The proper trunk patch from that link is going to take a good bit of work to resolve to the point where it's ok to commit, because it needs to handle all possible systems in an explicit list, some unknown number of which are broken. However, on the Google branch we only care about glibc/Linux systems, where we know this works. Thus, this Google-local patch addresses our immediate need in a simple way. Ok to commit to google/main and merge to google/gcc-4_8? Thanks, - Brooks [1] For values of "broken" that are basically "some implementations that predate the Posix standardization of the snprintf function return a non-standard result when given overlength input." 2013-09-20_google-fix-libssp-config.diff Description: Binary data
[C++ Patch] PR 58481
Hi,
this bug looks superficially similar to the already fixed c++/50089: an
ICE on valid in build_base_path for a qualified-id call in a lambda,
which can be worked around by qualifying with this->. It seems to me
that in this case too a fix may boil down to simply using
current_nonlambda_class_type () instead of current_class_type: here too
its return value ends up as the third argument of
adjust_result_of_qualified_name_lookup.
Tested x86_64-linux.
Thanks,
Paolo.
/
/cp
2013-09-20
PR c++/58481
* pt.c (tsubst_copy): Use current_nonlambda_class_type to
call tsubst_baselink.
/testsuite
2013-09-20
PR c++/58481
* g++.dg/cpp0x/lambda/lambda-this17.C: New.
Index: cp/pt.c
===
--- cp/pt.c (revision 202785)
+++ cp/pt.c (working copy)
@@ -12434,7 +12438,8 @@ tsubst_copy (tree t, tree args, tsubst_flags_t com
return t;
case BASELINK:
- return tsubst_baselink (t, current_class_type, args, complain, in_decl);
+ return tsubst_baselink (t, current_nonlambda_class_type (),
+ args, complain, in_decl);
case TEMPLATE_DECL:
if (DECL_TEMPLATE_TEMPLATE_PARM_P (t))
Index: testsuite/g++.dg/cpp0x/lambda/lambda-this17.C
===
--- testsuite/g++.dg/cpp0x/lambda/lambda-this17.C (revision 0)
+++ testsuite/g++.dg/cpp0x/lambda/lambda-this17.C (working copy)
@@ -0,0 +1,21 @@
+// PR c++/58481
+// { dg-require-effective-target c++11 }
+
+struct Test {
+ template inline void triggerTest (Args&&... fargs) { }
+};
+
+struct TestPickled : Test {
+ template void triggerTest (Args&&... fargs) {
+[=](Args... as) {
+ Test::triggerTest (as...);
+} ();
+ }
+};
+
+int main()
+{
+ TestPickled test;
+ test.triggerTest ();
+ return 0;
+}
Re: [PATCH] disable use_vector_fp_converts for m_CORE_ALL
Ping.
> -Original Message-
> From: Wei Mi [mailto:w...@google.com]
> Sent: Thursday, September 12, 2013 2:51 AM
> To: GCC Patches
> Cc: David Li; Zamyatin, Igor
> Subject: [PATCH] disable use_vector_fp_converts for m_CORE_ALL
>
> For the following testcase 1.c, on westmere and sandybridge, performance with
> the option -mtune=^use_vector_fp_converts is better (improves from 3.46s to
> 2.83s). It means cvtss2sd is often better than
> unpcklps+cvtps2pd on recent x86 platforms.
>
> 1.c:
> float total = 0.2;
> int k = 5;
>
> int main() {
> int i;
>
> for (i = 0; i < 10; i++) {
>total += (0.5 + k);
> }
>
> return total == 0.3;
> }
>
> assembly generated by gcc-r201963 without -mtune=^use_vector_fp_converts
> .L2:
> unpcklps%xmm0, %xmm0
> subl$1, %eax
> cvtps2pd%xmm0, %xmm0
> addsd %xmm1, %xmm0
> unpcklpd%xmm0, %xmm0
> cvtpd2ps%xmm0, %xmm0
> jne .L2
>
> assembly generated by gcc-r201963 with -mtune=^use_vector_fp_converts
> .L2:
> cvtss2sd%xmm0, %xmm0
> subl$1, %eax
> addsd %xmm1, %xmm0
> cvtsd2ss%xmm0, %xmm0
> jne .L2
>
> But for testcase 2.c (Thanks to Igor Zamyatin for the testcase), performance
> with the option -mtune=^use_vector_fp_converts is worse.
> Analysis to the assembly shows the performance degradation comes from partial
> reg stall caused by cvtsd2ss. Adding pxor %xmm0, %xmm0 before cvtsd2ss
> b(,%rdx,8), %xmm0 gets the performance back.
>
> 2.c:
> double b[1024];
>
> float a[1024];
>
> int main()
> {
> int i;
> for(i = 0 ; i < 1024 * 1024 * 256; i++)
> a[i & 1023] = a[i & 1023] * (float)b[i & 1023];
> return (int)a[512];
> }
>
> without -mtune-crtl=^use_vector_fp_converts
> .L2:
> movl%eax, %edx
> addl$1, %eax
> andl$1023, %edx
> cmpl$268435456, %eax
> movsd b(,%rdx,8), %xmm0
> cvtpd2ps%xmm0, %xmm0==> without partial reg stall
> because of movsd.
> mulss a(,%rdx,4), %xmm0
> movss %xmm0, a(,%rdx,4)
> jne .L2
>
> with -mtune-crtl=^use_vector_fp_converts
> .L2:
> movl%eax, %edx
> addl$1, %eax
> andl$1023, %edx
> cmpl$268435456, %eax
> cvtsd2ssb(,%rdx,8), %xmm0 ==> with partial reg
> stall. Needs to insert "pxor %xmm0, %xmm0" before current insn.
> mulss a(,%rdx,4), %xmm0
> movss %xmm0, a(,%rdx,4)
> jne .L2
>
> So the patch is to turn off use_vector_fp_converts for m_CORE_ALL to use
> cvtss2sd/cvtsd2ss directly, and add "pxor %xmmreg %xmmreg" before
> cvtss2sd/cvtsd2ss to break partial reg stall (similar as what r201308 does
> for cvtsi2ss/cvtsi2sd). bootstrap and regression pass. ok for trunk?
>
> Thanks,
> Wei Mi.
>
> 2013-09-11 Wei Mi
>
> * config/i386/x86-tune.def (DEF_TUNE): Remove
> m_CORE_ALL.
> * config/i386/i386.md: Add define_peephole2 to
> break partial reg stall for cvtss2sd/cvtsd2ss.
>
> Index: config/i386/x86-tune.def
> ===
> --- config/i386/x86-tune.def(revision 201963)
> +++ config/i386/x86-tune.def(working copy)
> @@ -189,7 +189,7 @@ DEF_TUNE (X86_TUNE_NOT_VECTORMODE, "not_
> /* X86_TUNE_USE_VECTOR_FP_CONVERTS: Prefer vector packed SSE conversion
> from FP to FP. */
> DEF_TUNE (X86_TUNE_USE_VECTOR_FP_CONVERTS, "use_vector_fp_converts",
> - m_CORE_ALL | m_AMDFAM10 | m_GENERIC)
> + m_AMDFAM10 | m_GENERIC)
> /* X86_TUNE_USE_VECTOR_CONVERTS: Prefer vector packed SSE conversion
> from integer to FP. */
> DEF_TUNE (X86_TUNE_USE_VECTOR_CONVERTS, "use_vector_converts", m_AMDFAM10)
> Index: config/i386/i386.md
> ===
> --- config/i386/i386.md (revision 201963)
> +++ config/i386/i386.md (working copy)
> @@ -5075,6 +5075,63 @@
>emit_move_insn (operands[0], CONST0_RTX (mode));
> })
>
> +;; Break partial reg stall for cvtsd2ss.
> +
> +(define_peephole2
> + [(set (match_operand:SF 0 "register_operand")
> +(float_truncate:SF
> + (match_operand:DF 1 "nonimmediate_operand")))]
> + "TARGET_SSE2 && TARGET_SSE_MATH
> + && TARGET_SSE_PARTIAL_REG_DEPENDENCY
> + && optimize_function_for_speed_p (cfun)
> + && reload_completed && SSE_REG_P (operands[0])
> + && peep2_reg_dead_p (0, operands[0])
> + && (!SSE_REG_P (operands[1])
> + || REGNO (operands[0]) != REGNO (operands[1]))"
> + [(set (match_dup 0)
> + (vec_merge:V4SF
> + (vec_duplicate:V4SF
> + (float_truncate:V2SF
> + (match_dup 1)))
> + (match_dup 0)
> + (const_int 1)))]
> +{
> + operands[0] = simplify_gen_subreg (V4SFmode, operands[0],
> +SFmode, 0);
> + operands[1] = simplify_gen_subreg (V2DFmode, operands[1],
>
Re: [GOOGLE] Patch to fix AutoFDO LIPO performance regression
Now that both statement fixup and cfg cleanup are moved after
annotation. So setting of cgraph node's count is still needed, right?
Thanks,
Dehao
On Thu, Sep 19, 2013 at 9:28 PM, Xinliang David Li wrote:
> I did not catch this in the last review. The cleanup CFG should be
> done before afdo_annotate_cfg and just after call statement fixup.
> Otherwise the cfg cleanup will zero out all profile counts. After
> moving this up, you don't need the follow up patch which sets the
> cgraph node's count -- that should be done in the
> rebuild_cgraph_edges.
>
> David
>
> On Thu, Sep 19, 2013 at 10:10 AM, Dehao Chen wrote:
>> Thanks, patch updated:
>>
>> Index: gcc/Makefile.in
>> ===
>> --- gcc/Makefile.in (revision 202725)
>> +++ gcc/Makefile.in (working copy)
>> @@ -2960,7 +2960,7 @@ coverage.o : coverage.c $(GCOV_IO_H) $(CONFIG_H) $
>> auto-profile.o : auto-profile.c $(CONFIG_H) $(SYSTEM_H) $(FLAGS_H) \
>> $(BASIC_BLOCK_H) $(DIAGNOSTIC_CORE_H) $(GCOV_IO_H) $(INPUT_H) profile.h \
>> $(LANGHOOKS_H) $(OPTS_H) $(TREE_PASS_H) $(CGRAPH_H) $(GIMPLE_H)
>> value-prof.h \
>> - $(COVERAGE_H) coretypes.h $(TREE_H) $(PARAMS_H) $(AUTO_PROFILE_H)
>> + $(COVERAGE_H) coretypes.h $(TREE_H) $(PARAMS_H) l-ipo.h $(AUTO_PROFILE_H)
>> cselib.o : cselib.c $(CONFIG_H) $(SYSTEM_H) coretypes.h dumpfile.h
>> $(TM_H) $(RTL_H) \
>> $(REGS_H) hard-reg-set.h $(FLAGS_H) insn-config.h $(RECOG_H) \
>> $(EMIT_RTL_H) $(DIAGNOSTIC_CORE_H) $(FUNCTION_H) \
>> Index: gcc/auto-profile.c
>> ===
>> --- gcc/auto-profile.c (revision 202725)
>> +++ gcc/auto-profile.c (working copy)
>> @@ -46,6 +46,7 @@ along with GCC; see the file COPYING3. If not see
>> #include "value-prof.h"
>> #include "coverage.h"
>> #include "params.h"
>> +#include "l-ipo.h"
>> #include "auto-profile.h"
>>
>> /* The following routines implements AutoFDO optimization.
>> @@ -1290,6 +1291,13 @@ auto_profile (void)
>>init_node_map ();
>>profile_info = autofdo::afdo_profile_info;
>>
>> + cgraph_pre_profiling_inlining_done = true;
>> + cgraph_process_module_scope_statics ();
>> + /* Now perform link to allow cross module inlining. */
>> + cgraph_do_link ();
>> + varpool_do_link ();
>> + cgraph_unify_type_alias_sets ();
>> +
>>FOR_EACH_FUNCTION (node)
>> {
>>if (!gimple_has_body_p (node->symbol.decl))
>> @@ -1301,21 +1309,33 @@ auto_profile (void)
>>
>>push_cfun (DECL_STRUCT_FUNCTION (node->symbol.decl));
>>
>> + if (L_IPO_COMP_MODE)
>> +{
>> + basic_block bb;
>> + FOR_EACH_BB (bb)
>> +{
>> + gimple_stmt_iterator gsi;
>> + for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
>> + {
>> + gimple stmt = gsi_stmt (gsi);
>> + if (is_gimple_call (stmt))
>> +lipo_fixup_cgraph_edge_call_target (stmt);
>> + }
>> +}
>> + }
>> +
>>autofdo::afdo_annotate_cfg ();
>>compute_function_frequency ();
>>update_ssa (TODO_update_ssa);
>>
>> + /* Local pure-const may imply need to fixup the cfg. */
>> + if (execute_fixup_cfg () & TODO_cleanup_cfg)
>> + cleanup_tree_cfg ();
>> +
>>current_function_decl = NULL;
>>pop_cfun ();
>> }
>>
>> - cgraph_pre_profiling_inlining_done = true;
>> - cgraph_process_module_scope_statics ();
>> - /* Now perform link to allow cross module inlining. */
>> - cgraph_do_link ();
>> - varpool_do_link ();
>> - cgraph_unify_type_alias_sets ();
>> -
>>return TODO_rebuild_cgraph_edges;
>> }
>>
>> On Wed, Sep 18, 2013 at 5:16 PM, Xinliang David Li
>> wrote:
>>> On Wed, Sep 18, 2013 at 4:51 PM, Dehao Chen wrote:
This patch fixup the call graph edge targets during AutoFDO pass, so
that when rebuilding call graph edges, it can find the correct callee.
Bootstrapped and passed regression test. Benchmark tests on-going.
Ok for google-4_8 branch?
Thanks,
Dehao
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 202725)
+++ gcc/Makefile.in (working copy)
@@ -2960,7 +2960,7 @@ coverage.o : coverage.c $(GCOV_IO_H) $(CONFIG_H) $
auto-profile.o : auto-profile.c $(CONFIG_H) $(SYSTEM_H) $(FLAGS_H) \
$(BASIC_BLOCK_H) $(DIAGNOSTIC_CORE_H) $(GCOV_IO_H) $(INPUT_H)
profile.h \
$(LANGHOOKS_H) $(OPTS_H) $(TREE_PASS_H) $(CGRAPH_H) $(GIMPLE_H)
value-prof.h \
- $(COVERAGE_H) coretypes.h $(TREE_H) $(PARAMS_H) $(AUTO_PROFILE_H)
+ $(COVERAGE_H) coretypes.h $(TREE_H) $(PARAMS_H) l-ipo.h
$(AUTO_PROFILE_H)
cselib.o : cselib.c $(CONFIG_H) $(SYSTEM_H) coretypes.h dumpfile.h
$(TM_H) $(RTL_H) \
$(REGS_H) hard-reg-set.h $(FLAGS_H) insn-config.h $(RECOG_H) \
$(EMIT_RTL_H) $(DIAGNOSTIC_CORE_H) $(FUNCTION_H) \
Index: gcc/auto-profile.c
===
Re: [committed] Accept "const_int 0" operand 1 in PA "scc" insns
The attached change fixes a regression in my last change. Detected on
4.8 branch. Tested on
hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
Dave
--
John David Anglin dave.ang...@bell.net
2013-09-20 John David Anglin
* config/pa/pa.md: In "scc" insn patterns, change output template to
handle const0_rtx in reg_or_0_operand operands.
Index: config/pa/pa.md
===
--- config/pa/pa.md (revision 202752)
+++ config/pa/pa.md (working copy)
@@ -836,7 +836,7 @@
[(match_operand:SI 1 "reg_or_0_operand" "rM")
(match_operand:SI 2 "arith11_operand" "rI")]))]
""
- "{com%I2clr|cmp%I2clr},%B3 %2,%1,%0\;ldi 1,%0"
+ "{com%I2clr|cmp%I2clr},%B3 %2,%r1,%0\;ldi 1,%0"
[(set_attr "type" "binary")
(set_attr "length" "8")])
@@ -846,7 +846,7 @@
[(match_operand:DI 1 "reg_or_0_operand" "rM")
(match_operand:DI 2 "arith11_operand" "rI")]))]
"TARGET_64BIT"
- "cmp%I2clr,*%B3 %2,%1,%0\;ldi 1,%0"
+ "cmp%I2clr,*%B3 %2,%r1,%0\;ldi 1,%0"
[(set_attr "type" "binary")
(set_attr "length" "8")])
@@ -859,7 +859,7 @@
[(match_operand:SI 4 "reg_or_0_operand" "rM")
(match_operand:SI 5 "arith11_operand"
"rI")])))]
""
- "{com%I2clr|cmp%I2clr},%S3 %2,%1,%%r0\;{com%I5clr|cmp%I5clr},%B6
%5,%4,%0\;ldi 1,%0"
+ "{com%I2clr|cmp%I2clr},%S3 %2,%r1,%%r0\;{com%I5clr|cmp%I5clr},%B6
%5,%r4,%0\;ldi 1,%0"
[(set_attr "type" "binary")
(set_attr "length" "12")])
@@ -872,7 +872,7 @@
[(match_operand:DI 4 "reg_or_0_operand" "rM")
(match_operand:DI 5 "arith11_operand"
"rI")])))]
"TARGET_64BIT"
- "cmp%I2clr,*%S3 %2,%1,%%r0\;cmp%I5clr,*%B6 %5,%4,%0\;ldi 1,%0"
+ "cmp%I2clr,*%S3 %2,%r1,%%r0\;cmp%I5clr,*%B6 %5,%r4,%0\;ldi 1,%0"
[(set_attr "type" "binary")
(set_attr "length" "12")])
@@ -884,7 +884,7 @@
[(match_operand:SI 1 "reg_or_0_operand" "rM")
(match_operand:SI 2 "arith11_operand" "rI")])))]
""
- "{com%I2clr|cmp%I2clr},%B3 %2,%1,%0\;ldi -1,%0"
+ "{com%I2clr|cmp%I2clr},%B3 %2,%r1,%0\;ldi -1,%0"
[(set_attr "type" "binary")
(set_attr "length" "8")])
@@ -894,7 +894,7 @@
[(match_operand:DI 1 "reg_or_0_operand" "rM")
(match_operand:DI 2 "arith11_operand" "rI")])))]
"TARGET_64BIT"
- "cmp%I2clr,*%B3 %2,%1,%0\;ldi -1,%0"
+ "cmp%I2clr,*%B3 %2,%r1,%0\;ldi -1,%0"
[(set_attr "type" "binary")
(set_attr "length" "8")])
Re: [GOOGLE] Patch to fix AutoFDO LIPO performance regression
Yes -- in current form, it is still needed. As you explained, the
linking & stmt fixup will need to be done after profile annotation as
autofdo uses assembler name for icall target matching.
David
On Fri, Sep 20, 2013 at 3:29 PM, Dehao Chen wrote:
> Now that both statement fixup and cfg cleanup are moved after
> annotation. So setting of cgraph node's count is still needed, right?
>
> Thanks,
> Dehao
>
> On Thu, Sep 19, 2013 at 9:28 PM, Xinliang David Li wrote:
>> I did not catch this in the last review. The cleanup CFG should be
>> done before afdo_annotate_cfg and just after call statement fixup.
>> Otherwise the cfg cleanup will zero out all profile counts. After
>> moving this up, you don't need the follow up patch which sets the
>> cgraph node's count -- that should be done in the
>> rebuild_cgraph_edges.
>>
>> David
>>
>> On Thu, Sep 19, 2013 at 10:10 AM, Dehao Chen wrote:
>>> Thanks, patch updated:
>>>
>>> Index: gcc/Makefile.in
>>> ===
>>> --- gcc/Makefile.in (revision 202725)
>>> +++ gcc/Makefile.in (working copy)
>>> @@ -2960,7 +2960,7 @@ coverage.o : coverage.c $(GCOV_IO_H) $(CONFIG_H) $
>>> auto-profile.o : auto-profile.c $(CONFIG_H) $(SYSTEM_H) $(FLAGS_H) \
>>> $(BASIC_BLOCK_H) $(DIAGNOSTIC_CORE_H) $(GCOV_IO_H) $(INPUT_H) profile.h
>>> \
>>> $(LANGHOOKS_H) $(OPTS_H) $(TREE_PASS_H) $(CGRAPH_H) $(GIMPLE_H)
>>> value-prof.h \
>>> - $(COVERAGE_H) coretypes.h $(TREE_H) $(PARAMS_H) $(AUTO_PROFILE_H)
>>> + $(COVERAGE_H) coretypes.h $(TREE_H) $(PARAMS_H) l-ipo.h
>>> $(AUTO_PROFILE_H)
>>> cselib.o : cselib.c $(CONFIG_H) $(SYSTEM_H) coretypes.h dumpfile.h
>>> $(TM_H) $(RTL_H) \
>>> $(REGS_H) hard-reg-set.h $(FLAGS_H) insn-config.h $(RECOG_H) \
>>> $(EMIT_RTL_H) $(DIAGNOSTIC_CORE_H) $(FUNCTION_H) \
>>> Index: gcc/auto-profile.c
>>> ===
>>> --- gcc/auto-profile.c (revision 202725)
>>> +++ gcc/auto-profile.c (working copy)
>>> @@ -46,6 +46,7 @@ along with GCC; see the file COPYING3. If not see
>>> #include "value-prof.h"
>>> #include "coverage.h"
>>> #include "params.h"
>>> +#include "l-ipo.h"
>>> #include "auto-profile.h"
>>>
>>> /* The following routines implements AutoFDO optimization.
>>> @@ -1290,6 +1291,13 @@ auto_profile (void)
>>>init_node_map ();
>>>profile_info = autofdo::afdo_profile_info;
>>>
>>> + cgraph_pre_profiling_inlining_done = true;
>>> + cgraph_process_module_scope_statics ();
>>> + /* Now perform link to allow cross module inlining. */
>>> + cgraph_do_link ();
>>> + varpool_do_link ();
>>> + cgraph_unify_type_alias_sets ();
>>> +
>>>FOR_EACH_FUNCTION (node)
>>> {
>>>if (!gimple_has_body_p (node->symbol.decl))
>>> @@ -1301,21 +1309,33 @@ auto_profile (void)
>>>
>>>push_cfun (DECL_STRUCT_FUNCTION (node->symbol.decl));
>>>
>>> + if (L_IPO_COMP_MODE)
>>> +{
>>> + basic_block bb;
>>> + FOR_EACH_BB (bb)
>>> +{
>>> + gimple_stmt_iterator gsi;
>>> + for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
>>> + {
>>> + gimple stmt = gsi_stmt (gsi);
>>> + if (is_gimple_call (stmt))
>>> +lipo_fixup_cgraph_edge_call_target (stmt);
>>> + }
>>> +}
>>> + }
>>> +
>>>autofdo::afdo_annotate_cfg ();
>>>compute_function_frequency ();
>>>update_ssa (TODO_update_ssa);
>>>
>>> + /* Local pure-const may imply need to fixup the cfg. */
>>> + if (execute_fixup_cfg () & TODO_cleanup_cfg)
>>> + cleanup_tree_cfg ();
>>> +
>>>current_function_decl = NULL;
>>>pop_cfun ();
>>> }
>>>
>>> - cgraph_pre_profiling_inlining_done = true;
>>> - cgraph_process_module_scope_statics ();
>>> - /* Now perform link to allow cross module inlining. */
>>> - cgraph_do_link ();
>>> - varpool_do_link ();
>>> - cgraph_unify_type_alias_sets ();
>>> -
>>>return TODO_rebuild_cgraph_edges;
>>> }
>>>
>>> On Wed, Sep 18, 2013 at 5:16 PM, Xinliang David Li
>>> wrote:
On Wed, Sep 18, 2013 at 4:51 PM, Dehao Chen wrote:
> This patch fixup the call graph edge targets during AutoFDO pass, so
> that when rebuilding call graph edges, it can find the correct callee.
>
> Bootstrapped and passed regression test. Benchmark tests on-going.
>
> Ok for google-4_8 branch?
>
> Thanks,
> Dehao
>
> Index: gcc/Makefile.in
> ===
> --- gcc/Makefile.in (revision 202725)
> +++ gcc/Makefile.in (working copy)
> @@ -2960,7 +2960,7 @@ coverage.o : coverage.c $(GCOV_IO_H) $(CONFIG_H) $
> auto-profile.o : auto-profile.c $(CONFIG_H) $(SYSTEM_H) $(FLAGS_H) \
> $(BASIC_BLOCK_H) $(DIAGNOSTIC_CORE_H) $(GCOV_IO_H) $(INPUT_H)
> profile.h \
> $(LANGHOOKS_H) $(OPTS_H) $(TREE_PASS_H) $(CGRAPH_H) $(GIMPLE_H)
> value-prof.h \
> - $(COVERAGE_H) coretypes.h $(TREE_H) $(PARAMS_H) $(AUTO_PROFILE_H)
> +
[rl78] various tweaks
Mostly whitespace and comment tweaks, with a few random bug fixes.
Committed.
Note: the net result of our recent batch of patches is an
approximately 50% speed improvement :-)
* config/rl78/rl78.c: Various whitespace and comment tweaks.
(need_to_save): Save bank 0 on interrupts.
(characterize_address): Strip far address wrappers.
(rl78_as_legitimate_address): Likewise.
(transcode_memory_rtx): Likewise.
(rl78_peep_movhi_p): Disable this peephole after devirt.
(rl78_propogate_register_origins): Forget all origins when a
CLOBBER is seen.
* config/rl78/rl78-virt.md: Various whitespace tweaks.
* config/rl78/rl78-real.md: Various whitespace tweaks. Additional
peephole2's.
* config/rl78/rl78.md (sel_rb): Disable for G10 just in case.
* config/rl78/rl78-expand.md (movqi): Check for subregs of consts.
* config/rl78/rl78.h (LINK_SPEC): Pass -gc-sections unless
relocating.
* config/rl78/constraints.md: Various whitespace and paren tweaks.
Index: config/rl78/rl78.h
===
--- config/rl78/rl78.h (revision 202798)
+++ config/rl78/rl78.h (working copy)
@@ -49,12 +49,13 @@
%{mg10} \
"
#undef LINK_SPEC
#define LINK_SPEC "\
%{mrelax:-relax} \
+%{!r:--gc-sections} \
"
#undef LIB_SPEC
#define LIB_SPEC " \
--start-group \
-lc\
Index: config/rl78/constraints.md
===
--- config/rl78/constraints.md (revision 202798)
+++ config/rl78/constraints.md (working copy)
@@ -59,33 +59,37 @@
(define_constraint "Iv08"
"@internal
Integer constant equal to 8."
(and (match_code "const_int")
(match_test "IN_RANGE (ival, 8, 8)")))
+
(define_constraint "Iv16"
"@internal
Integer constant equal to 16."
(and (match_code "const_int")
(match_test "IN_RANGE (ival, 16, 16)")))
+
(define_constraint "Iv24"
"@internal
Integer constant equal to 24."
(and (match_code "const_int")
(match_test "IN_RANGE (ival, 24, 24)")))
(define_constraint "Is09"
"@internal
Integer constant in the range 9 @dots{} 15 (for shifts)."
(and (match_code "const_int")
(match_test "IN_RANGE (ival, 9, 15)")))
+
(define_constraint "Is17"
"@internal
Integer constant in the range 17 @dots{} 23 (for shifts)."
(and (match_code "const_int")
(match_test "IN_RANGE (ival, 17, 23)")))
+
(define_constraint "Is25"
"@internal
Integer constant in the range 25 @dots{} 31 (for shifts)."
(and (match_code "const_int")
(match_test "IN_RANGE (ival, 25, 31)")))
@@ -213,13 +217,13 @@
(ior (match_test "CONSTANT_P (XEXP (op, 0))")
(match_test "GET_CODE (XEXP (op, 0)) == PLUS && GET_CODE (XEXP
(XEXP (op, 0), 0)) == SYMBOL_REF"))
)
)
(define_memory_constraint "Wab"
"es:[addr]"
- (match_test "rl78_es_addr (op) && satisfies_constraint_Cab (rl78_es_base
(op))
+ (match_test "(rl78_es_addr (op) && satisfies_constraint_Cab (rl78_es_base
(op)))
|| satisfies_constraint_Cab (op)")
)
(define_memory_constraint "Cbc"
"word16[BC]"
(and (match_code "mem")
@@ -231,49 +235,49 @@
(match_test "REGNO (XEXP (XEXP (op, 0), 0)) == BC_REG"))
(match_test "uword_operand (XEXP (XEXP (op, 0), 1),
VOIDmode)"
)
)
(define_memory_constraint "Wbc"
"es:word16[BC]"
- (match_test "rl78_es_addr (op) && satisfies_constraint_Cbc (rl78_es_base
(op))
+ (match_test "(rl78_es_addr (op) && satisfies_constraint_Cbc (rl78_es_base
(op)))
|| satisfies_constraint_Cbc (op)")
)
(define_memory_constraint "Cde"
"[DE]"
(and (match_code "mem")
(and (match_code "reg" "0")
(match_test "REGNO (XEXP (op, 0)) == DE_REG")))
)
(define_memory_constraint "Wde"
"es:[DE]"
- (match_test "rl78_es_addr (op) && satisfies_constraint_Cde (rl78_es_base
(op))
+ (match_test "(rl78_es_addr (op) && satisfies_constraint_Cde (rl78_es_base
(op)))
|| satisfies_constraint_Cde (op)")
)
(define_memory_constraint "Cca"
"[AX..HL] for calls"
(and (match_code "mem")
(and (match_code "reg" "0")
(match_test "REGNO (XEXP (op, 0)) <= HL_REG")))
)
(define_memory_constraint "Wca"
"es:[AX..HL] for calls"
- (match_test "rl78_es_addr (op) && satisfies_constraint_Cca (rl78_es_base
(op))
+ (match_test "(rl78_es_addr (op) && satisfies_constraint_Cca (rl78_es_base
(op)))
|| satisfies_constraint_Cca (op)")
)
(define_memory_constraint "Ccv"
"[AX..HL,r8-r31] for calls"
(and (match_code "mem")
(and (match_code "reg" "0")
- (match_test "REGNO (XEXP (op, 0)) < 31")))
+ (match_test "REGNO (X
Re: [PATCH, powerpc] Rework#2 VSX scalar floating point support, patch #1
I am now breaking the patches down to be more bite size. Ultimately, I hope
these patches will provide support to allow scalar floating point to occupy the
Altivec (upper) registers if the ISA allows it (ISA 2.06 for DFmode, ISA 2.07
for SFmode). One effect of later patches will be to go back to using the
traditional DFmode instructions for VSX if all of the registers come from the
traditional floating point register set.
This patch adds the new switches, and constraints that will be used in future
patches. It produces exactly the same code on the targets I tested on and
passes the bootstrap/make check stages. Is it ok to apply this patch?
I have tested the code generation for the following targets:
power4, power5, power5+, power6, power6x, power7, power8 for 64/32-bit
power7 with VSX disabled using altivec instructions for 64/32-bit
power7 with both VSX and altivec disabled for 64/32-bit
cell 64/32-bit
e5500, e6500 64/32-bit
G4 32-bit
G5 64/32-bit
linuxpaired 32-bit
linuxspe 32-bit
2013-09-20 Michael Meissner
* config/rs6000/rs6000.h (enum r6000_reg_class_enum): Add new
constraints: wu, ww, and wy. Repurpose wv constraint added during
power8 changes. Put wg constraint in alphabetical order.
* config/rs6000/rs6000.opt (-mvsx-scalar-float): New debug switch
for future work to add ISA 2.07 VSX single precision support.
(-mvsx-scalar-double): Change default from -1 to 1, update
documentation comment.
(-mvsx-scalar-memory): Rename debug switch to -mupper-regs-df.
(-mupper-regs-df): New debug switch to control whether DF values
can go in the traditional Altivec registers.
(-mupper-regs-sf): New debug switch to control whether SF values
can go in the traditional Altivec registers.
* config/rs6000/rs6000.c (rs6000_debug_reg_global): Print wu, ww,
and wy constraints.
(rs6000_init_hard_regno_mode_ok): Use ssize_t instead of int for
loop variables. Rename -mvsx-scalar-memory to -mupper-regs-df.
Add new constraints, wu/ww/wy. Repurpose wv constraint.
(rs6000_debug_legitimate_address_p): Print if we are running
before, during, or after reload.
(rs6000_secondary_reload): Add a comment.
(rs6000_opt_masks): Add -mupper-regs-df, -mupper-regs-sf.
* config/rs6000/constraints.md (wa constraint): Sort w
constraints. Update documentation string.
(wd constraint): Likewise.
(wf constraint): Likewise.
(wg constraint): Likewise.
(wn constraint): Likewise.
(ws constraint): Likewise.
(wt constraint): Likewise.
(wx constraint): Likewise.
(wz constraint): Likewise.
(wu constraint): New constraint for ISA 2.07 SFmode scalar
instructions.
(ww constraint): Likewise.
(wy constraint): Likewise.
(wv constraint): Repurpose ISA 2.07 constraint that we not used in
the previous submissions.
* doc/md.texi (PowerPC and IBM RS6000): Likewise.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.h
===
--- gcc/config/rs6000/rs6000.h (revision 202793)
+++ gcc/config/rs6000/rs6000.h (working copy)
@@ -1403,15 +1403,18 @@ enum r6000_reg_class_enum {
RS6000_CONSTRAINT_v, /* Altivec registers */
RS6000_CONSTRAINT_wa,/* Any VSX register */
RS6000_CONSTRAINT_wd,/* VSX register for V2DF */
- RS6000_CONSTRAINT_wg,/* FPR register for -mmfpgpr */
RS6000_CONSTRAINT_wf,/* VSX register for V4SF */
+ RS6000_CONSTRAINT_wg,/* FPR register for -mmfpgpr */
RS6000_CONSTRAINT_wl,/* FPR register for LFIWAX */
RS6000_CONSTRAINT_wm,/* VSX register for direct move */
RS6000_CONSTRAINT_wr,/* GPR register if 64-bit */
RS6000_CONSTRAINT_ws,/* VSX register for DF */
RS6000_CONSTRAINT_wt,/* VSX register for TImode */
- RS6000_CONSTRAINT_wv,/* Altivec register for power8 vector */
+ RS6000_CONSTRAINT_wu,/* Altivec register for float
load/stores. */
+ RS6000_CONSTRAINT_wv,/* Altivec register for double
load/stores. */
+ RS6000_CONSTRAINT_ww,/* FP or VSX register for vsx float
ops. */
RS6000_CONSTRAINT_wx,/* FPR register for STFIWX */
+ RS6000_CONSTRAINT_wy,/* VSX register for SF */
RS6000_CONSTRAINT_wz,/* FPR register for LFIWZX */
RS6000_CONSTRAINT_MAX
};
Index: gcc/config/rs6000/rs6000.opt
===
--- gcc/config/rs6000/
[commited] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_[1,2,4] on PA linux
I noticed recently in looking at the configure output of glib2.0 that
the __GCC_HAVE_SYNC_COMPARE_AND_SWAP_[1,2,4]
defines are not defined on hppa-linux because the corresponding
builtins are implemented as library functions.
Tested on hppa-linux. Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2013-09-20 John David Anglin
* config/pa/pa-linux.h (TARGET_OS_CPP_BUILTINS): Define
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1, __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2,
and __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4.
Index: config/pa/pa-linux.h
===
--- config/pa/pa-linux.h(revision 202154)
+++ config/pa/pa-linux.h(working copy)
@@ -22,6 +22,9 @@
#define TARGET_OS_CPP_BUILTINS() \
do \
{ \
+ builtin_define ("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1"); \
+ builtin_define ("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2"); \
+ builtin_define ("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4"); \
GNU_USER_TARGET_OS_CPP_BUILTINS(); \
builtin_assert ("machine=bigendian"); \
} \
[committed] Work around auto increment/decrement reload issue on PA
The attached change works around a problem that results in wrong code on hppa1.1-*-hpux*. The wrong code causes a bootstrap error. The problem does not occur when generating PA2.0 code, or on linux because the generation of auto increment/decrement instructions is disabled. The comment in the code indicates that this was done on PA2.0 because it is not profitable. The real problem seems to be in reload. It appears to handle spills for auto increment/decrements insns incorrectly, sometimes generating the reload insns in the wrong order. I couldn't see any way to correct this in the PA backend as the insns are emitted independently. So, I decided to disable the generation of auto increment/decrement insns until after reload. Tested on hppa2.0-hp-hpux11.11, hppa64-hp-hpux11.11 and hppa-unknown- linux-gnu. Bootstrap tested on hppa1.1-hp-hpux11.11. Committed to trunk and 4.8. Dave -- John David Anglin dave.ang...@bell.net 2013-09-20 John David Anglin PR middle-end/56791 * config/pa/pa.c (pa_option_override): Disable auto increment and decrement instructions until reload is completed. Index: config/pa/pa.c === --- config/pa/pa.c (revision 202481) +++ config/pa/pa.c (working copy) @@ -513,6 +513,12 @@ write_symbols = NO_DEBUG; } +#ifdef AUTO_INC_DEC + /* FIXME: Disable auto increment and decrement processing until reload + is completed. See PR middle-end 56791. */ + flag_auto_inc_dec = reload_completed; +#endif + /* We only support the "big PIC" model now. And we always generate PIC code when in 64bit mode. */ if (flag_pic == 1 || TARGET_64BIT)
