[PATCH] Fix ICE with COMPLEX_EXPR in fold_negate_expr (PR middle-end/79536)
For "(int) -x", which is a NOP_EXPR, negate_expr_p returns true, which means
that fold_negate_expr cannot return NULL_TREE. But that's what happens here,
leading to a crash in fold_build2. negate_expr_p has (as well as negate_expr)
STRIP_SIGN_NOPS, so the "(int) -x" becomes "-x", but fold_negate_expr doesn't
have any STRIP_SIGN_NOPS. Richi suggested to add a wrapper for fold_negate_expr
that strips/restores such NOP_EXPRs, much like negate_expr, which is what this
patch does.
Bootstrapped/regtested on x86_64-linux, ok for trunk? And 6 after a while?
2017-02-16 Marek Polacek
PR middle-end/79536
* fold-const.c (fold_negate_expr_1): Renamed from fold_negate_expr.
(fold_negate_expr): New wrapper.
* gcc.dg/torture/pr79536.c: New test.
diff --git gcc/fold-const.c gcc/fold-const.c
index a8bb8af..ad4770b 100644
--- gcc/fold-const.c
+++ gcc/fold-const.c
@@ -139,6 +139,7 @@ static tree fold_relational_const (enum tree_code, tree,
tree, tree);
static tree fold_convert_const (enum tree_code, tree, tree);
static tree fold_view_convert_expr (tree, tree);
static bool vec_cst_ctor_to_array (tree, tree *);
+static tree fold_negate_expr (location_t, tree);
/* Return EXPR_LOCATION of T if it is not UNKNOWN_LOCATION.
@@ -522,7 +523,7 @@ negate_expr_p (tree t)
returned. */
static tree
-fold_negate_expr (location_t loc, tree t)
+fold_negate_expr_1 (location_t loc, tree t)
{
tree type = TREE_TYPE (t);
tree tem;
@@ -533,7 +534,7 @@ fold_negate_expr (location_t loc, tree t)
case BIT_NOT_EXPR:
if (INTEGRAL_TYPE_P (type))
return fold_build2_loc (loc, PLUS_EXPR, type, TREE_OPERAND (t, 0),
-build_one_cst (type));
+ build_one_cst (type));
break;
case INTEGER_CST:
@@ -581,14 +582,14 @@ fold_negate_expr (location_t loc, tree t)
case COMPLEX_EXPR:
if (negate_expr_p (t))
return fold_build2_loc (loc, COMPLEX_EXPR, type,
- fold_negate_expr (loc, TREE_OPERAND (t, 0)),
- fold_negate_expr (loc, TREE_OPERAND (t, 1)));
+ fold_negate_expr (loc, TREE_OPERAND (t, 0)),
+ fold_negate_expr (loc, TREE_OPERAND (t, 1)));
break;
case CONJ_EXPR:
if (negate_expr_p (t))
return fold_build1_loc (loc, CONJ_EXPR, type,
- fold_negate_expr (loc, TREE_OPERAND (t, 0)));
+ fold_negate_expr (loc, TREE_OPERAND (t, 0)));
break;
case NEGATE_EXPR:
@@ -605,7 +606,7 @@ fold_negate_expr (location_t loc, tree t)
{
tem = negate_expr (TREE_OPERAND (t, 1));
return fold_build2_loc (loc, MINUS_EXPR, type,
- tem, TREE_OPERAND (t, 0));
+ tem, TREE_OPERAND (t, 0));
}
/* -(A + B) -> (-A) - B. */
@@ -613,7 +614,7 @@ fold_negate_expr (location_t loc, tree t)
{
tem = negate_expr (TREE_OPERAND (t, 0));
return fold_build2_loc (loc, MINUS_EXPR, type,
- tem, TREE_OPERAND (t, 1));
+ tem, TREE_OPERAND (t, 1));
}
}
break;
@@ -623,7 +624,7 @@ fold_negate_expr (location_t loc, tree t)
if (!HONOR_SIGN_DEPENDENT_ROUNDING (element_mode (type))
&& !HONOR_SIGNED_ZEROS (element_mode (type)))
return fold_build2_loc (loc, MINUS_EXPR, type,
- TREE_OPERAND (t, 1), TREE_OPERAND (t, 0));
+ TREE_OPERAND (t, 1), TREE_OPERAND (t, 0));
break;
case MULT_EXPR:
@@ -638,11 +639,11 @@ fold_negate_expr (location_t loc, tree t)
tem = TREE_OPERAND (t, 1);
if (negate_expr_p (tem))
return fold_build2_loc (loc, TREE_CODE (t), type,
- TREE_OPERAND (t, 0), negate_expr (tem));
+ TREE_OPERAND (t, 0), negate_expr (tem));
tem = TREE_OPERAND (t, 0);
if (negate_expr_p (tem))
return fold_build2_loc (loc, TREE_CODE (t), type,
- negate_expr (tem), TREE_OPERAND (t, 1));
+ negate_expr (tem), TREE_OPERAND (t, 1));
}
break;
@@ -715,6 +716,19 @@ fold_negate_expr (location_t loc, tree t)
return NULL_TREE;
}
+/* A wrapper for fold_negate_expr_1. */
+
+static tree
+fold_negate_expr (location_t loc, tree t)
+{
+ tree type = TREE_TYPE (t);
+ STRIP_SIGN_NOPS (t);
+ tree tem = fold_negate_expr_1 (loc, t);
+ if (tem == NULL_TREE)
+return NULL_TREE;
+ return fold_convert_loc (loc, type, tem);
+}
+
/* Like fold_negate_expr, but return a NEGATE_EXPR tree, if T can not be
negated in a simpler way. Also allow for T to be NULL_TREE, in which case
return NULL_TREE. */
diff --git gcc/
[doc, committed] Re: Doc question: is "templatized" a word?
On 02/15/2017 01:17 PM, Jason Merrill wrote:
On Wed, Feb 15, 2017 at 1:57 PM, Jonathan Wakely wrote:
On 15 February 2017 at 15:53, Jason Merrill wrote:
On Sat, Feb 11, 2017 at 4:19 PM, Jonathan Wakely wrote:
On 11 February 2017 at 20:36, Sandra Loosemore wrote:
On 02/11/2017 06:21 AM, Jonathan Wakely wrote:
On 11 February 2017 at 08:48, Gerald Pfeifer wrote:
On Fri, 10 Feb 2017, Sandra Loosemore wrote:
The documentation for -Wno-non-template-friend refers to
"non-templatized
friend functions" and "templatized functions". I don't see the term
"templatized" used anywhere in the C++ standard. This paragraph also
uses
"nontemplate function", which I assume refers to the same thing the C++
standard spells "non-template function". So does "non-templatized
function"
also mean "non-template function"? Or does it have some other meaning?
I would avoid "templatized" and believe "non-template function" is
more appropriate in your example.
Yes,
s/non-templatized/non-template/
s/nontemplate/non-template/
s/templatized function/function template/
But I wonder if that warning is even useful nowadays. The example of
"friend foo(int);" is bogus and is correctly rejected:
fr.cc:2:17: error: ISO C++ forbids declaration of ‘foo’ with no type
[-fpermissive]
friend foo(int);
^
I hadn't actually gotten that far :-) but it looks like that's an
implicit-int error unrelated to the actual purpose of this option.
This ended up on my todo list firstly because "templatized" didn't
spell-check, and secondly because the "new compiler behavior" documented in
connection with this option has existed at least since 1998 and can hardly
be considered "new" any more. Also I think the reference to section 14.5.3
of the C++ standard is bit-rotten (it's 14.5.4 in the c++0x draft I have
handy).
I'll leave it up to the C++ experts to decide whether the option should just
be removed and the warning replaced with a hard error controlled by some
other flag.
It definitely shouldn't be turned into a hard error, the warning
complains about valid code, such as:
template struct A {
friend int foo(T);
};
int main() {
A a;
}
I think it warns because the meaning of that code changed, a *long*
time ago, so it's saying "if you wrote this code in the 1990s it might
do something different to what you expect."
I'm not sure how useful that warning is now, although EDG warns for it
too (with a fix-it hint that I think is bogus):
"fr.cc", line 2: warning: "int foo(T)" declares a non-template function -- add
<> to refer to a template instance
friend int foo(T);
^
That fix-it looks fine to me;
Where should I add the <> to make it valid?
If I change the example to "friend int foo<>(T);" EDG says it's not a template:
template struct A {
friend int foo<>(T);
};
int main() {
A a;
}
"fr.cc", line 2: error: foo is not a template
friend int foo<>(T);
Yep, you would also need to declare the foo template earlier in the TU.
Jason
Thanks everyone for the explanations and suggestions. I've checked in
the attached patch to clean this up.
-Sandra
2017-02-16 Sandra Loosemore
gcc/
* doc/invoke.texi (C++ Dialect Options) [-Wno-non-template-friend]:
Correct terminology and de-emphasize pre-standard behavior.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 245524)
+++ gcc/doc/invoke.texi (working copy)
@@ -2996,19 +2996,13 @@ But this use is not portable across diff
@item -Wno-non-template-friend @r{(C++ and Objective-C++ only)}
@opindex Wno-non-template-friend
@opindex Wnon-template-friend
-Disable warnings when non-templatized friend functions are declared
-within a template. Since the advent of explicit template specification
-support in G++, if the name of the friend is an unqualified-id (i.e.,
-@samp{friend foo(int)}), the C++ language specification demands that the
-friend declare or define an ordinary, nontemplate function. (Section
-14.5.3). Before G++ implemented explicit specification, unqualified-ids
-could be interpreted as a particular specialization of a templatized
-function. Because this non-conforming behavior is no longer the default
-behavior for G++, @option{-Wnon-template-friend} allows the compiler to
-check existing code for potential trouble spots and is on by default.
-This new compiler behavior can be turned off with
-@option{-Wno-non-template-friend}, which keeps the conformant compiler code
-but disables the helpful warning.
+Disable warnings when non-template friend functions are declared
+within a template. In very old versions of GCC that predate implementation
+of the ISO standard, declarations such as
+@samp{friend int foo(int)}, where the name of the friend is an unqualified-id,
+could be interpreted as a particular specialization of a template
+function; the warning exists to diagnose compatibility problems,
+and is enabled by
Re: [PATCH PR71437/V2]Simplify cond with assertions in threading
On 02/14/2017 03:05 AM, Bin Cheng wrote: Hi, This is the second try fixing PR71437. The old version patch tried to fix issue in VRP but it requires further non-trivial change in VRP, specifically, to better support variable value ranges. This is not appropriate at stage 4. Alternatively, this patch tries to fix issue by improving threading. It additionally simplifies condition by using assertion conditions. Bootstrap and test on x86_64 and AArch64. Is it OK? Thanks, bin 2017-02-13 Bin Cheng PR tree-optimization/71437 * tree-ssa-loop-niter.c (tree_simplify_using_condition): Only expand condition if new parameter says so. Also change it to global. * tree-ssa-loop-niter.h (tree_simplify_using_condition): New declaration. * tree-ssa-threadedge.c (tree-ssa-loop-niter.h): New include file. (simplify_control_stmt_condition_1): Simplify condition using assert conditions. gcc/testsuite/ChangeLog 2017-02-13 Bin Cheng PR tree-optimization/71437 * gcc.dg/tree-ssa/pr71437.c: New test. So following up. We're not going to get anywhere using the ranges in VRP. As Bin noted in the V1 patch, VRP prefers a useless range with constant bounds when a symbolic range would be better. Thus the callbacks into VRP are doomed to failure. Bin's patch works around this by using the ASSERT_EXPRs to recover the symbolic range. So it's a bit of a hack, but not a terrible one. If we want to continue this path, we might still look for ways to avoid simplify_using_condition. One idea would be to go ahead and record the equivalence from the ASSERT_EXPR into the expression hash table and use the expression hash table to simplify the condition. We didn't have that ability in the past, but should now after the refactorings from last year. It's slightly related to some ideas I've got around tackling 78496. I'm in/out of the office for until the 27th semi-randomly. I'll try to poke at this while on the road. Jeff
[PATCH][GCC5] Backport of PR76731 fix
Hi, This is GCC5 backport discussed in https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01034.html. Please commit it for me, if it is ok. PR target/76731 * config/i386/avx512fintrin.h (_mm512_i32gather_ps): Change __addr type to void const*. (_mm512_mask_i32gather_ps): Ditto. (_mm512_i32gather_pd): Ditto. (_mm512_mask_i32gather_pd): Ditto. (_mm512_i64gather_ps): Ditto. (_mm512_mask_i64gather_ps): Ditto. (_mm512_i64gather_pd): Ditto. (_mm512_mask_i64gather_pd): Ditto. (_mm512_i32gather_epi32): Ditto. (_mm512_mask_i32gather_epi32): Ditto. (_mm512_i32gather_epi64): Ditto. (_mm512_mask_i32gather_epi64): Ditto. (_mm512_i64gather_epi32): Ditto. (_mm512_mask_i64gather_epi32): Ditto. (_mm512_i64gather_epi64): Ditto. (_mm512_mask_i64gather_epi64): Ditto. (_mm512_i32scatter_ps): Change __addr type to void*. (_mm512_mask_i32scatter_ps): Ditto. (_mm512_i32scatter_pd): Ditto. (_mm512_mask_i32scatter_pd): Ditto. (_mm512_i64scatter_ps): Ditto. (_mm512_mask_i64scatter_ps): Ditto. (_mm512_i64scatter_pd): Ditto. (_mm512_mask_i64scatter_pd): Ditto. (_mm512_i32scatter_epi32): Ditto. (_mm512_mask_i32scatter_epi32): Ditto. (_mm512_i32scatter_epi64): Ditto. (_mm512_mask_i32scatter_epi64): Ditto. (_mm512_i64scatter_epi32): Ditto. (_mm512_mask_i64scatter_epi32): Ditto. (_mm512_i64scatter_epi64): Ditto. (_mm512_mask_i64scatter_epi64): Ditto. * config/i386/avx512pfintrin.h (_mm512_mask_prefetch_i32gather_pd): Change addr type to void const*. (_mm512_mask_prefetch_i32gather_ps): Ditto. (_mm512_mask_prefetch_i64gather_pd): Ditto. (_mm512_mask_prefetch_i64gather_ps): Ditto. (_mm512_prefetch_i32scatter_pd): Change addr type to void*. (_mm512_prefetch_i32scatter_ps): Ditto. (_mm512_mask_prefetch_i32scatter_pd): Ditto. (_mm512_mask_prefetch_i32scatter_ps): Ditto. (_mm512_prefetch_i64scatter_pd): Ditto. (_mm512_prefetch_i64scatter_ps): Ditto. (_mm512_mask_prefetch_i64scatter_pd): Ditto. (_mm512_mask_prefetch_i64scatter_ps): Ditto. * config/i386/avx512vlintrin.h (_mm256_mmask_i32gather_ps): Change __addr type to void const*. (_mm_mmask_i32gather_ps): Ditto. (_mm256_mmask_i32gather_pd): Ditto. (_mm_mmask_i32gather_pd): Ditto. (_mm256_mmask_i64gather_ps): Ditto. (_mm_mmask_i64gather_ps): Ditto. (_mm256_mmask_i64gather_pd): Ditto. (_mm_mmask_i64gather_pd): Ditto. (_mm256_mmask_i32gather_epi32): Ditto. (_mm_mmask_i32gather_epi32): Ditto. (_mm256_mmask_i32gather_epi64): Ditto. (_mm_mmask_i32gather_epi64): Ditto. (_mm256_mmask_i64gather_epi32): Ditto. (_mm_mmask_i64gather_epi32): Ditto. (_mm256_mmask_i64gather_epi64): Ditto. (_mm_mmask_i64gather_epi64): Ditto. (_mm256_i32scatter_ps): Change __addr type to void*. (_mm256_mask_i32scatter_ps): Ditto. (_mm_i32scatter_ps): Ditto. (_mm_mask_i32scatter_ps): Ditto. (_mm256_i32scatter_pd): Ditto. (_mm256_mask_i32scatter_pd): Ditto. (_mm_i32scatter_pd): Ditto. (_mm_mask_i32scatter_pd): Ditto. (_mm256_i64scatter_ps): Ditto. (_mm256_mask_i64scatter_ps): Ditto. (_mm_i64scatter_ps): Ditto. (_mm_mask_i64scatter_ps): Ditto. (_mm256_i64scatter_pd): Ditto. (_mm256_mask_i64scatter_pd): Ditto. (_mm_i64scatter_pd): Ditto. (_mm_mask_i64scatter_pd): Ditto. (_mm256_i32scatter_epi32): Ditto. (_mm256_mask_i32scatter_epi32): Ditto. (_mm_i32scatter_epi32): Ditto. (_mm_mask_i32scatter_epi32): Ditto. (_mm256_i32scatter_epi64): Ditto. (_mm256_mask_i32scatter_epi64): Ditto. (_mm_i32scatter_epi64): Ditto. (_mm_mask_i32scatter_epi64): Ditto. (_mm256_i64scatter_epi32): Ditto. (_mm256_mask_i64scatter_epi32): Ditto. (_mm_i64scatter_epi32): Ditto. (_mm_mask_i64scatter_epi32): Ditto. (_mm256_i64scatter_epi64): Ditto. (_mm256_mask_i64scatter_epi64): Ditto. (_mm_i64scatter_epi64): Ditto. (_mm_mask_i64scatter_epi64): Ditto. * config/i386/i386-builtin-types.def (V16SF_V16SF_PCFLOAT_V16SI_HI_INT) (V8DF_V8DF_PCDOUBLE_V8SI_QI_INT, V8SF_V8SF_PCFLOAT_V8DI_QI_INT) (V8DF_V8DF_PCDOUBLE_V8DI_QI_INT, V16SI_V16SI_PCINT_V16SI_HI_INT) (V8DI_V8DI_PCINT64_V8SI_QI_INT, V8SI_V8SI_PCINT_V8DI_QI_INT) (V8DI_V8DI_PCINT64_V8DI_QI_INT, V2DF_V2DF_PCDOUBLE_V4SI_QI_INT) (V4DF_V4DF_PCDOUBLE_V4SI_QI_INT, V2DF_V2DF_PCDOUBLE_V2DI_QI_INT) (V4DF_V4DF_PCDOUBLE_V4DI_QI_INT, V4SF_V4SF_PCFLOAT_V4SI_QI_INT) (V8SF_V8SF_PCFLOAT_V8SI_QI_INT, V4SF_V4SF_PCFLOAT_V
Re: [PATCH PR77536]Generate correct profiling information for vectorized loop
On 02/16/2017 11:48 AM, Bin Cheng wrote: > BTW, it may also help PR78116? Hi Pat, could you please help verify this? > Thanks! The first testcase in pr78116 no longer contains loads from spill in the loop even before your patch. When built with your patch, there are four additional register copies in the loop (vmovaps %zmm2, %zmm14). As for the second testcase, your patch gets rid of the 12 loads from spill in the loop. -Pat
Re: [PATCH PR71437/V2]Simplify cond with assertions in threading
On 02/16/2017 04:55 AM, Richard Biener wrote: On Tue, Feb 14, 2017 at 11:05 AM, Bin Cheng wrote: Hi, This is the second try fixing PR71437. The old version patch tried to fix issue in VRP but it requires further non-trivial change in VRP, specifically, to better support variable value ranges. This is not appropriate at stage 4. Alternatively, this patch tries to fix issue by improving threading. It additionally simplifies condition by using assertion conditions. Bootstrap and test on x86_64 and AArch64. Is it OK? Hmm. So I'm not a big fan of tree_simplify_using_condition ;) The case in question for the PR was an equivalent assert to the condition? Thus basically tree_simplify_using_condition (x <= 52, x <= 25)? + if (is_gimple_assign (def0) + && TREE_CODE (gimple_assign_rhs1 (def0)) == ASSERT_EXPR) gimple_assign_rhs_code (def0) == ASSERT_EXPR As you add a parameter to tree_simplify_using_condition you can as well fold it into tree_simplify_using_condition_1. And ideally I'd like to see us pass in a decomposed toplevel expression to avoid + tree res = fold_build2 (cond_code, boolean_type_node, + assert_op0, assert_op1); but I'm not sure that will work out ;) So, in the end I wonder if we can fix this in threading w/o usign tree_simplify_using_conditon (the main issue with it I have is the extensive tree building it does). Given that we've got a callback into VRP simplifiers, I'd think we ought to be able to avoid tree_simplify_using_condition. jeff
Re: [PATCH PR71437/V2]Simplify cond with assertions in threading
On 02/14/2017 03:05 AM, Bin Cheng wrote: Hi, This is the second try fixing PR71437. The old version patch tried to fix issue in VRP but it requires further non-trivial change in VRP, specifically, to better support variable value ranges. This is not appropriate at stage 4. Alternatively, this patch tries to fix issue by improving threading. It additionally simplifies condition by using assertion conditions. Bootstrap and test on x86_64 and AArch64. Is it OK? Thanks, bin 2017-02-13 Bin Cheng PR tree-optimization/71437 * tree-ssa-loop-niter.c (tree_simplify_using_condition): Only expand condition if new parameter says so. Also change it to global. * tree-ssa-loop-niter.h (tree_simplify_using_condition): New declaration. * tree-ssa-threadedge.c (tree-ssa-loop-niter.h): New include file. (simplify_control_stmt_condition_1): Simplify condition using assert conditions. gcc/testsuite/ChangeLog 2017-02-13 Bin Cheng PR tree-optimization/71437 * gcc.dg/tree-ssa/pr71437.c: New test. Looking at this code for the first time in a long time, I wonder if the handling of ASSERT_EXPRs ought to move into the callback provided by VRP. The code here has become rather convoluted. Given I want to remove the instances of the threader called by VRP that cleanup may not be worth the effort. Not sure. Punting that decition to gcc-8. I'm a bit surprised that this isn't detected by the callback into VRP. I'll take a peek at that next week. Jeff
Re: [PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745)
On Thu, 16 Feb 2017, Jakub Jelinek wrote:
> > #define SPEC_MESSAGE(msg) msg
> >
> > "... %e" SPEC_MESSAGE ("Message") "} ..."
> >
> > and then only handling SPEC_MESSAGE specially in exgettext, rather than %e?
>
> We have over 90 of these, plus it would make the specs even harder to read.
> Will defer this to Joseph anyway.
The general design in GCC is to keep down the number of places where
explicit markup for translation is needed. Thus the "msgid" convention
for parameter naming to avoid lots of explicit _() (see ABOUT-GCC-NLS,
though it may be out of date), and thus the detection of %e / %n. So I
think one of the local fixes to avoid this particular case being
misdetected as a spec string should be preferred.
--
Joseph S. Myers
jos...@codesourcery.com
Re: [PATCH] use zero as the lower bound for a signed-unsigned range (PR 79327)
On 02/14/2017 01:32 PM, Jakub Jelinek wrote:
On Tue, Feb 14, 2017 at 12:15:59PM -0700, Martin Sebor wrote:
That comment explains how the likely_adjust variable ("the adjustment")
is being used, or more precisely, how it was being used in the first
version of the patch. The comment became somewhat out of date with
the committed version of the patch (this was my bad).
The variable is documented where it's defined and again where it's
assigned to. With the removal of those comments it seems especially
important that the only remaining description of what's going on be
accurate.
The comment is outdated because it refers to "the adjustment" which
doesn't exist anymore. (It was replaced by a flag in my commit).
To bring it up to date it should say something like:
/* Set the LIKELY counter to MIN. In base 8 and 16, when
the argument is in range that includes zero, adjust it
upward to include the length of the base prefix since
in that case the MIN counter does include it. */
So for a comment, what about following then? With or without
the IMNSHO useless
&& (tree_int_cst_sgn (argmin) < 0 || tree_int_cst_sgn (argmax) > 0)
On a separate note, while testing the patch I noticed that it's
not exactly equivalent to what's on trunk. Trunk silently accepts
the call below but with the patch it complains. That's great (it
should complain) but the change should be tested. More to my point,
while in this case your change happened to fix a subtle bug (which
I'm certainly happy about), it could have just as easily introduced
one.
Yeah, indeed. That should be a clear argument for why writing it in
so many places is bad, it is simply much more error-prone, there are
too many cases to get right.
char d[2];
void f (unsigned i)
{
if (i < 1234 || 12345 < i)
i = 1234;
__builtin_sprintf (d, "%#hhx", i);
}
What happens is that because the original range doesn't contain zero
you set likely_adjust to false and then never update it again because
the implicit cast changed the range.
If some version of the patch is approved, I'll leave addition of this
testcase to you (incrementally).
2017-02-14 Jakub Jelinek
PR tree-optimization/79327
* gimple-ssa-sprintf.c (format_integer): Remove likely_adjust
variable, its initialization and use.
This is fine. And the addition of the test from Martin is pre-approved
as well.
jeff
Re: [PATCH] use zero as the lower bound for a signed-unsigned range (PR 79327)
On 02/14/2017 06:43 AM, Jakub Jelinek wrote:
On Tue, Feb 14, 2017 at 08:18:13AM +0100, Jakub Jelinek wrote:
On Mon, Feb 13, 2017 at 04:53:19PM -0700, Jeff Law wrote:
dirtype is one of the standard {un,}signed {char,short,int,long,long long}
types, all of them have 0 in their ranges.
For VR_RANGE we almost always set res.knownrange to true:
/* Set KNOWNRANGE if the argument is in a known subrange
of the directive's type (KNOWNRANGE may be reset below). */
res.knownrange
= (!tree_int_cst_equal (TYPE_MIN_VALUE (dirtype), argmin)
|| !tree_int_cst_equal (TYPE_MAX_VALUE (dirtype), argmax));
(the exception is in case that range clearly has to include zero),
and reset it only if adjust_range_for_overflow returned true, which means
it also set the range to TYPE_M{IN,AX}_VALUE (dirtype) and again
includes zero.
So IMNSHO likely_adjust in what you've committed is always true
when you use it and thus just a useless computation and something to make
the code harder to understand.
If KNOWNRANGE is false, then LIKELY_ADJUST will be true. But I don't see
how we can determine anything for LIKELY_ADJUST if KNOWNRANGE is true.
We can't, but that doesn't matter, we only use it if KNOWNRANGE is false.
The only user of LIKELY_ADJUST is:
if (res.knownrange)
res.range.likely = res.range.max;
else
{
// -- Here we know res.knownrage is false
res.range.likely = res.range.min;
if (likely_adjust && maybebase && base != 10)
// -- and here is the only user of likely_adjust
{
if (res.range.min == 1)
res.range.likely += base == 8 ? 1 : 2;
else if (res.range.min == 2
&& base == 16
&& (dir.width[0] == 2 || dir.prec[0] == 2))
++res.range.likely;
}
}
Duh. You're obviously right. Still reading the rest of the thread.
jeff
Re: [C++ RFC] Fix up attribute handling in templates (PR c++/79502)
On 02/16/2017 12:49 PM, Jason Merrill wrote:
On Thu, Feb 16, 2017 at 11:33 AM, Jakub Jelinek wrote:
PR c++/79502
* pt.c (apply_late_template_attributes): If there are
no dependent attributes, set *p to attributes. If there were
some attributes in *p previously with or without dependent
attributes, chain them after the new attributes.
Here's the variant of your patch that I'm applying.
Sorry to butt in but I feel like I'm missing something basic. Are
these attributes (nodiscard, noreturn, maybe_unused, and deprecated)
meant to apply to templates? The text in for nodiscard suggests
they're not:
The attribute-token nodiscard may be applied to the declarator-id
in a function declaration or to the declaration of a class or
enumeration.
Noreturn also doesn't mention templates:
The attribute may be applied to the declarator-id in a function
declaration.
Deprecated explicitly mentions template specializations but not
primary templates:
The attribute may be applied to the declaration of a class,
a typedef-name, a variable, a non-static data member, a function,
a namespace, an enumeration, an enumerator, or a template
specialization.
I can certainly see how applying attributes to the primary template
would be useful so it's puzzling to me that the standard seems to
preclude it.
I ask also because I was just looking at bug 79021 and scratching
my head about what to thing about it. While trying to understand
how GCC handles attributes for the primary template I came across
what doesn't make sense to me. Why would it apply the attribute
from the primary to the explicit specialization when the two are
distinct entities? Is that a bug?
template
[[noreturn]] int f () { throw ""; }
template <> int f () { return 0; }
t.C: In function ‘int f() [with T = void]’:
t.C:4:37: warning: function declared ‘noreturn’ has a ‘return’ statement
template <> int f () { return 0; }
^
t.C:4:37: warning: ‘noreturn’ function does return
template <> int f () { return 0; }
^
Clang complains on this too with similar errors, but then GCC
silently accepts this code (which makes sense to me) which Clang
5 rejects with what looks like a bug:
template
int g () { return 0; }
template <> [[noreturn]] int g () { throw ""; }
template <> [[noreturn]] int g () { throw ""; }
Thanks
Martin
Re: [PATCH] testsuite: pr59833.c and pr61441.c should use -fsignaling-nans
On 02/16/2017 10:46 AM, Segher Boessenkool wrote:
The testcases pr59833.c and pr61441.c check whether signaling NaNs as
input to some operation result in quiet NaNs. Without -fsignaling-nans
this is not guaranteed to happen. So, this patch add this option to
these testcases.
Tested on powerpc64-linux {-m32,-m64}, on aarch64-linux, and on
x86_64-linux (where there is no issignaling, huh -- I tested on gcc20).
Is this okay for trunk?
Segher
2017-02-16 Segher Boessenkool
gcc/testsuite/
* gcc.dg/pr59833.c: Add -fsignaling-nans to options.
* gcc.dg/pr61441.c: Ditto.
OK.
jeff
Re: PR79286, ira combine_and_move_insns in loops
On 02/10/2017 05:29 PM, Alan Modra wrote: On Fri, Feb 03, 2017 at 01:55:33AM -0700, Jeff Law wrote: That seems pretty pessimistic -- do we have dominance information at this point? If so we could check that the assignment to the register dominates the use. If they are in the same block, then you have to look at LUIDs or somesuch. That would address the problem you're trying to solve without pessimizing the code. Fair enough. Revised and regression tested x86_64-linux. PR rtl-optimization/79286 * ira.c (def_dominates_uses): New function. (update_equiv_regs): Don't create an equivalence for insns that may trap where the register def does not dominate the use. testsuite/ * gcc.c-torture/execute/pr79286.c: New. Thanks. Installed. I'm slightly concerned about the test and how it'll behave on targets with small address spaces. If it's a problem we can fault in adjustments. jeff
RE: [PATCH] Enable RDPID instruction.
Sorry, here is the right patch(previous one had a typo). Changelog is right. -Original Message- From: Koval, Julia Sent: Thursday, February 16, 2017 11:31 PM To: 'Uros Bizjak' Cc: GCC Patches Subject: RE: [PATCH] Enable RDPID instruction. Sorry, fixed it. gcc/ * common/config/i386/i386-common.c (OPTION_MASK_ISA_RDPID_SET): New. (OPTION_MASK_ISA_PKU_UNSET): New. (ix86_handle_option): Handle -mrdpid. * config/i386/cpuid.h (bit_RDPID): New. * config/i386/driver-i386.c (host_detect_local_cpu): Detect RDPID feature. * config/i386/i386-builtin.def (__builtin_ia32_rdpid): New. * config/i386/i386-c.c (ix86_target_macros_internal): Handle RDPID flag. * config/i386/i386.c (ix86_target_string): Add -mrdpid to isa2_opts. (ix86_valid_target_attribute_inner_p): Add "rdpid". (ix86_expand_builtin): Handle IX86_BUILTIN_RDPID. * config/i386/i386.h (TARGET_RDPID, TARGET_RDPID_P): New. * config/i386/i386.md (define_insn "rdpid"): New. * config/i386/i386.opt Add -mrdpid. * config/i386/immintrin.h (_rdpid_u32): New. gcc/testsuite/ * gcc.target/i386/rdpid.c New test. * gcc.target/i386/sse-12.c: Add -mrdpid. * gcc.target/i386/sse-13.c: Ditto. * gcc.target/i386/sse-14.c: Ditto. * gcc.target/i386/sse-22.c: Ditto. * gcc.target/i386/sse-23.c: Ditto. * g++.dg/other/i386-2.C: Ditto. * g++.dg/other/i386-3.C: Ditto. Julia -Original Message- From: Uros Bizjak [mailto:ubiz...@gmail.com] Sent: Thursday, February 16, 2017 9:33 AM To: Koval, Julia Cc: GCC Patches Subject: Re: [PATCH] Enable RDPID instruction. On Wed, Feb 15, 2017 at 3:09 PM, Koval, Julia wrote: > Hi, > > This patch enables RDPID intrinsic, described in SDM 4-534 Vol. 2B > https://software.intel.com/sites/default/files/managed/39/c5/325462-sd > m-vol-1-2abcd-3abcd.pdf > and intrinsic guide: > https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=rdp > i&expand=2778,2777,4219 > > gcc/ > * common/config/i386/i386-common.c (OPTION_MASK_ISA_RDPID_SET): New. > (OPTION_MASK_ISA_PKU_UNSET): New. > (ix86_handle_option): Handle -mrdpid. > * config/i386/cpuid.h > (bit_RDPID): New. > * config/i386/driver-i386.c (host_detect_local_cpu): Detect RDPID > feature. > * config/i386/i386-builtin.def (__builtin_ia32_rdpid): New. > * config/i386/i386-c.c (ix86_target_macros_internal): Handle RDPID > flag. > * config/i386/i386.c (ix86_target_string): Add -mrdpid to isa2_opts. > (ix86_valid_target_attribute_inner_p): Add "rdpid". > (ix86_expand_builtin): Handle IX86_BUILTIN_RDPID. > * config/i386/i386.h (TARGET_RDPID, TARGET_RDPID_P): New. > * config/i386/i386.md (define_insn "rdpid"): New. > * config/i386/i386.opt Add -mrdpid. > * config/i386/immintrin.h (_rdpid_u32): New. > * testsuite/gcc.target/i386/rdpid.c New test. > > Ok for trunk? This patch is missing testsuite changes. Additions to intrinsic headers need to update relevant tests, please see [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00764.html Uros. 0001-RDPID.PATCH Description: 0001-RDPID.PATCH
RE: [PATCH] Enable RDPID instruction.
Sorry, fixed it. gcc/ * common/config/i386/i386-common.c (OPTION_MASK_ISA_RDPID_SET): New. (OPTION_MASK_ISA_PKU_UNSET): New. (ix86_handle_option): Handle -mrdpid. * config/i386/cpuid.h (bit_RDPID): New. * config/i386/driver-i386.c (host_detect_local_cpu): Detect RDPID feature. * config/i386/i386-builtin.def (__builtin_ia32_rdpid): New. * config/i386/i386-c.c (ix86_target_macros_internal): Handle RDPID flag. * config/i386/i386.c (ix86_target_string): Add -mrdpid to isa2_opts. (ix86_valid_target_attribute_inner_p): Add "rdpid". (ix86_expand_builtin): Handle IX86_BUILTIN_RDPID. * config/i386/i386.h (TARGET_RDPID, TARGET_RDPID_P): New. * config/i386/i386.md (define_insn "rdpid"): New. * config/i386/i386.opt Add -mrdpid. * config/i386/immintrin.h (_rdpid_u32): New. gcc/testsuite/ * gcc.target/i386/rdpid.c New test. * gcc.target/i386/sse-12.c: Add -mrdpid. * gcc.target/i386/sse-13.c: Ditto. * gcc.target/i386/sse-14.c: Ditto. * gcc.target/i386/sse-22.c: Ditto. * gcc.target/i386/sse-23.c: Ditto. * g++.dg/other/i386-2.C: Ditto. * g++.dg/other/i386-3.C: Ditto. Julia -Original Message- From: Uros Bizjak [mailto:ubiz...@gmail.com] Sent: Thursday, February 16, 2017 9:33 AM To: Koval, Julia Cc: GCC Patches Subject: Re: [PATCH] Enable RDPID instruction. On Wed, Feb 15, 2017 at 3:09 PM, Koval, Julia wrote: > Hi, > > This patch enables RDPID intrinsic, described in SDM 4-534 Vol. 2B > https://software.intel.com/sites/default/files/managed/39/c5/325462-sd > m-vol-1-2abcd-3abcd.pdf > and intrinsic guide: > https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=rdp > i&expand=2778,2777,4219 > > gcc/ > * common/config/i386/i386-common.c (OPTION_MASK_ISA_RDPID_SET): New. > (OPTION_MASK_ISA_PKU_UNSET): New. > (ix86_handle_option): Handle -mrdpid. > * config/i386/cpuid.h > (bit_RDPID): New. > * config/i386/driver-i386.c (host_detect_local_cpu): Detect RDPID > feature. > * config/i386/i386-builtin.def (__builtin_ia32_rdpid): New. > * config/i386/i386-c.c (ix86_target_macros_internal): Handle RDPID > flag. > * config/i386/i386.c (ix86_target_string): Add -mrdpid to isa2_opts. > (ix86_valid_target_attribute_inner_p): Add "rdpid". > (ix86_expand_builtin): Handle IX86_BUILTIN_RDPID. > * config/i386/i386.h (TARGET_RDPID, TARGET_RDPID_P): New. > * config/i386/i386.md (define_insn "rdpid"): New. > * config/i386/i386.opt Add -mrdpid. > * config/i386/immintrin.h (_rdpid_u32): New. > * testsuite/gcc.target/i386/rdpid.c New test. > > Ok for trunk? This patch is missing testsuite changes. Additions to intrinsic headers need to update relevant tests, please see [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00764.html Uros. 0001-RDPID.patch Description: 0001-RDPID.patch
Re: [PATCH PR79562] fix bootstrap on FreeBSD
On 16.02.17 22:03, Jakub Jelinek wrote: On Thu, Feb 16, 2017 at 09:57:48PM +0100, Andreas Tobler wrote: is this patch ok for trunk? Fixes bootstrap for x86_64-*-freebsd12 where the internal struct rtentry has gone from userland. TIA, Andreas 2017-02-16 Andreas Tobler PR sanitizer/79562 * sanitizer_common/sanitizer_platform_limits_posix.cc: Cherry-pick upstream r294806. Ok, thanks. I'm just surprised by the "The problem was introduced within the last 8 days." comment in the PR, because this file has been modified last time on 2016-11-08. Yeah, I understand. This is due to the fact that on FreeBSD trunk (aka. *-*-freebsd12) this commit (https://svnweb.freebsd.org/base?view=revision&revision=313560) dropped the _WANT_RTENTRY from net/route.h. Iow, all version of FreeBSD < svn commit r313560 will build w/o patch. Thanks, Andreas Index: libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc === --- libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc (revision 245506) +++ libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc (working copy) @@ -21,11 +21,6 @@ #ifdef _FILE_OFFSET_BITS #undef _FILE_OFFSET_BITS #endif -#if SANITIZER_FREEBSD -#define _WANT_RTENTRY -#include -#include -#endif #include #include #include @@ -420,6 +415,7 @@ unsigned struct_input_absinfo_sz = sizeof(struct input_absinfo); unsigned struct_input_id_sz = sizeof(struct input_id); unsigned struct_mtpos_sz = sizeof(struct mtpos); + unsigned struct_rtentry_sz = sizeof(struct rtentry); unsigned struct_termio_sz = sizeof(struct termio); unsigned struct_vt_consize_sz = sizeof(struct vt_consize); unsigned struct_vt_sizes_sz = sizeof(struct vt_sizes); @@ -439,7 +435,6 @@ unsigned struct_midi_info_sz = sizeof(struct midi_info); unsigned struct_mtget_sz = sizeof(struct mtget); unsigned struct_mtop_sz = sizeof(struct mtop); - unsigned struct_rtentry_sz = sizeof(struct rtentry); unsigned struct_sbi_instrument_sz = sizeof(struct sbi_instrument); unsigned struct_seq_event_rec_sz = sizeof(struct seq_event_rec); unsigned struct_synth_info_sz = sizeof(struct synth_info); Jakub
Re: [PATCH PR79562] fix bootstrap on FreeBSD
On Thu, Feb 16, 2017 at 09:57:48PM +0100, Andreas Tobler wrote: > is this patch ok for trunk? > > Fixes bootstrap for x86_64-*-freebsd12 where the internal struct rtentry has > gone from userland. > > TIA, > Andreas > > 2017-02-16 Andreas Tobler > > PR sanitizer/79562 > * sanitizer_common/sanitizer_platform_limits_posix.cc: Cherry-pick > upstream r294806. Ok, thanks. I'm just surprised by the "The problem was introduced within the last 8 days." comment in the PR, because this file has been modified last time on 2016-11-08. > Index: libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc > === > --- libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc > (revision 245506) > +++ libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc > (working copy) > @@ -21,11 +21,6 @@ > #ifdef _FILE_OFFSET_BITS > #undef _FILE_OFFSET_BITS > #endif > -#if SANITIZER_FREEBSD > -#define _WANT_RTENTRY > -#include > -#include > -#endif > #include > #include > #include > @@ -420,6 +415,7 @@ >unsigned struct_input_absinfo_sz = sizeof(struct input_absinfo); >unsigned struct_input_id_sz = sizeof(struct input_id); >unsigned struct_mtpos_sz = sizeof(struct mtpos); > + unsigned struct_rtentry_sz = sizeof(struct rtentry); >unsigned struct_termio_sz = sizeof(struct termio); >unsigned struct_vt_consize_sz = sizeof(struct vt_consize); >unsigned struct_vt_sizes_sz = sizeof(struct vt_sizes); > @@ -439,7 +435,6 @@ >unsigned struct_midi_info_sz = sizeof(struct midi_info); >unsigned struct_mtget_sz = sizeof(struct mtget); >unsigned struct_mtop_sz = sizeof(struct mtop); > - unsigned struct_rtentry_sz = sizeof(struct rtentry); >unsigned struct_sbi_instrument_sz = sizeof(struct sbi_instrument); >unsigned struct_seq_event_rec_sz = sizeof(struct seq_event_rec); >unsigned struct_synth_info_sz = sizeof(struct synth_info); Jakub
[PATCH PR79562] fix bootstrap on FreeBSD
Hi all, is this patch ok for trunk? Fixes bootstrap for x86_64-*-freebsd12 where the internal struct rtentry has gone from userland. TIA, Andreas 2017-02-16 Andreas Tobler PR sanitizer/79562 * sanitizer_common/sanitizer_platform_limits_posix.cc: Cherry-pick upstream r294806. Index: libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc === --- libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc (revision 245506) +++ libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc (working copy) @@ -21,11 +21,6 @@ #ifdef _FILE_OFFSET_BITS #undef _FILE_OFFSET_BITS #endif -#if SANITIZER_FREEBSD -#define _WANT_RTENTRY -#include -#include -#endif #include #include #include @@ -420,6 +415,7 @@ unsigned struct_input_absinfo_sz = sizeof(struct input_absinfo); unsigned struct_input_id_sz = sizeof(struct input_id); unsigned struct_mtpos_sz = sizeof(struct mtpos); + unsigned struct_rtentry_sz = sizeof(struct rtentry); unsigned struct_termio_sz = sizeof(struct termio); unsigned struct_vt_consize_sz = sizeof(struct vt_consize); unsigned struct_vt_sizes_sz = sizeof(struct vt_sizes); @@ -439,7 +435,6 @@ unsigned struct_midi_info_sz = sizeof(struct midi_info); unsigned struct_mtget_sz = sizeof(struct mtget); unsigned struct_mtop_sz = sizeof(struct mtop); - unsigned struct_rtentry_sz = sizeof(struct rtentry); unsigned struct_sbi_instrument_sz = sizeof(struct sbi_instrument); unsigned struct_seq_event_rec_sz = sizeof(struct seq_event_rec); unsigned struct_synth_info_sz = sizeof(struct synth_info);
[PATCH, rs6000] Fix PR79261 (vec_xxpermdi is not endian-sensitive)
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79261 records that the interface
vec_xxpermdi isn't implemented in a bi-endian fashion; instead, it produces
results appropriate for big-endian vector element numbering even when run on
a little endian machine. This is not part of the "official vector API" from
the ELFv2 ABI document, but should still have appropriate bi-endian behavior.
The problem appears to have arisen because some of GCC's internal usages of
the xxpermdi instruction wanted to use them in big-endian form, which is
natural to the original hardware instruction. The define_expand used for this
(vsx_xxpermdi_) is also the one that is used for the built-in forms.
Since these two uses require different semantics, I've created a new
vsx_xxpermdi__be define_expand to be used for the internal uses, and
re-directed those usages there. That version retains the original semantics,
while the semantics for the built-ins are changed to be endian-sensitive.
I've added a runtime test to verify that the vec_xxpermdi intrinsics produce
correct results for the various vector modes in both big- and little-endian
environments.
Bootstrapped and tested on powerpc64[le]-unknown-linux-gnu with no regressions
in either environment. Is this ok for trunk, and after a suitable period, for
backport to GCC 5 and 6?
Thanks,
Bill
[gcc]
2017-02-16 Bill Schmidt
PR target/79261
* config/rs6000/rs6000.c (rs6000_expand_ternop_builtin): Add
support for CODE_FOR_vsx_xxpermdi_v2d[fi]_be.
* config/rs6000/rs6000.md (reload_gpr_from_vsx): Call
generator for vsx_xxpermdi__be.
* config/rs6000/vsx.md (vsx_xxpermdi_): Remove logic to
force big-endian semantics.
(vsx_xxpermdi__be): New define_expand with same
implementation as previous version of vsx_xxpermdi_.
[gcc/testsuite]
2017-02-16 Bill Schmidt
PR target/79261
* gcc.target/powerpc/vec-xxpermdi.c: New file.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 245490)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -15436,6 +15436,8 @@ rs6000_expand_ternop_builtin (enum insn_code icode
}
else if (icode == CODE_FOR_vsx_xxpermdi_v2df
|| icode == CODE_FOR_vsx_xxpermdi_v2di
+ || icode == CODE_FOR_vsx_xxpermdi_v2df_be
+ || icode == CODE_FOR_vsx_xxpermdi_v2di_be
|| icode == CODE_FOR_vsx_xxsldwi_v16qi
|| icode == CODE_FOR_vsx_xxsldwi_v8hi
|| icode == CODE_FOR_vsx_xxsldwi_v4si
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 245490)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -8419,7 +8419,7 @@
rtx gpr_lo_reg = gen_lowpart (DFmode, dest);
emit_insn (gen_p8_mfvsrd_3_ (gpr_hi_reg, src));
- emit_insn (gen_vsx_xxpermdi_ (tmp, src, src, GEN_INT (3)));
+ emit_insn (gen_vsx_xxpermdi__be (tmp, src, src, GEN_INT (3)));
emit_insn (gen_p8_mfvsrd_3_ (gpr_lo_reg, tmp));
DONE;
}
Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md(revision 245490)
+++ gcc/config/rs6000/vsx.md(working copy)
@@ -2461,6 +2461,38 @@
op1 = gen_lowpart (V2DImode, op1);
}
}
+ emit_insn (gen (target, op0, op1, perm0, perm1));
+ DONE;
+})
+
+;; Special version of xxpermdi that retains big-endian semantics.
+(define_expand "vsx_xxpermdi__be"
+ [(match_operand:VSX_L 0 "vsx_register_operand" "")
+ (match_operand:VSX_L 1 "vsx_register_operand" "")
+ (match_operand:VSX_L 2 "vsx_register_operand" "")
+ (match_operand:QI 3 "u5bit_cint_operand" "")]
+ "VECTOR_MEM_VSX_P (mode)"
+{
+ rtx target = operands[0];
+ rtx op0 = operands[1];
+ rtx op1 = operands[2];
+ int mask = INTVAL (operands[3]);
+ rtx perm0 = GEN_INT ((mask >> 1) & 1);
+ rtx perm1 = GEN_INT ((mask & 1) + 2);
+ rtx (*gen) (rtx, rtx, rtx, rtx, rtx);
+
+ if (mode == V2DFmode)
+gen = gen_vsx_xxpermdi2_v2df_1;
+ else
+{
+ gen = gen_vsx_xxpermdi2_v2di_1;
+ if (mode != V2DImode)
+ {
+ target = gen_lowpart (V2DImode, target);
+ op0 = gen_lowpart (V2DImode, op0);
+ op1 = gen_lowpart (V2DImode, op1);
+ }
+}
/* In little endian mode, vsx_xxpermdi2__1 will perform a
transformation we don't want; it is necessary for
rs6000_expand_vec_perm_const_1 but not for this use. So we
@@ -3870,7 +3902,7 @@
{
rtx op1 = operands[1];
rtx v4si_tmp = gen_reg_rtx (V4SImode);
- emit_insn (gen_vsx_xxpermdi_v4si (v4si_tmp, op1, op1, const1_rtx));
+ emit_insn (gen_vsx_xxpermdi_v4si_be (v4si_tmp, op1, op1, const1_rtx));
operands[1] = v4si_tmp;
operands[3] = GEN_INT (12 - INTVAL (operands[3]));
}
Index: gcc/testsuite/gcc.target/powerpc/vec-xxpermdi.c
Re: [C++ RFC] Fix up attribute handling in templates (PR c++/79502)
On Thu, Feb 16, 2017 at 11:33 AM, Jakub Jelinek wrote:
> PR c++/79502
> * pt.c (apply_late_template_attributes): If there are
> no dependent attributes, set *p to attributes. If there were
> some attributes in *p previously with or without dependent
> attributes, chain them after the new attributes.
Here's the variant of your patch that I'm applying.
commit 3a5098ff79743f89c2e0e3cfa6a00ee82ec26b78
Author: Jason Merrill
Date: Thu Feb 16 13:05:56 2017 -0500
PR c++/79502 - lost nodiscard attribute
* pt.c (apply_late_template_attributes): Do apply non-dependent
attributes to types.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 712fb69..c468268 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10073,29 +10073,43 @@ apply_late_template_attributes (tree *decl_p, tree
attributes, int attr_flags,
tree t;
tree *p;
- for (t = attributes; t; t = TREE_CHAIN (t))
-if (ATTR_IS_DEPENDENT (t))
- {
- last_dep = t;
- attributes = copy_list (attributes);
- break;
- }
+ if (attributes == NULL_TREE)
+return;
if (DECL_P (*decl_p))
{
if (TREE_TYPE (*decl_p) == error_mark_node)
return;
p = &DECL_ATTRIBUTES (*decl_p);
+ /* DECL_ATTRIBUTES comes from copy_node in tsubst_decl, and identical
+ to our attributes parameter. */
+ gcc_assert (*p == attributes);
}
else
-p = &TYPE_ATTRIBUTES (*decl_p);
+{
+ p = &TYPE_ATTRIBUTES (*decl_p);
+ /* TYPE_ATTRIBUTES was set up (with abi_tag and may_alias) in
+lookup_template_class_1, and should be preserved. */
+ gcc_assert (*p != attributes);
+ while (*p)
+ p = &TREE_CHAIN (*p);
+}
+ for (t = attributes; t; t = TREE_CHAIN (t))
+if (ATTR_IS_DEPENDENT (t))
+ {
+ last_dep = t;
+ attributes = copy_list (attributes);
+ break;
+ }
+
+ *p = attributes;
if (last_dep)
{
tree late_attrs = NULL_TREE;
tree *q = &late_attrs;
- for (*p = attributes; *p; )
+ for (; *p; )
{
t = *p;
if (ATTR_IS_DEPENDENT (t))
diff --git a/gcc/testsuite/g++.dg/cpp0x/attrib54.C
b/gcc/testsuite/g++.dg/cpp0x/attrib54.C
new file mode 100644
index 000..e5817c3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/attrib54.C
@@ -0,0 +1,21 @@
+// { dg-do compile { target c++11 } }
+
+inline namespace N __attribute__((__abi_tag__ ("foo"))) {}
+template struct A {};
+namespace N {
+template class B {};
+}
+template class __attribute__((__aligned__ (sizeof (T C {};
+template struct D {
+ template using G = C<_Up>;
+};
+template struct F {
+ template struct H {
+typedef typename D::template G I;
+ };
+};
+template > struct J {
+ C>> L;
+ typedef F>::H>>::I M;
+ J *a;
+};
diff --git a/gcc/testsuite/g++.dg/cpp0x/attrib55.C
b/gcc/testsuite/g++.dg/cpp0x/attrib55.C
new file mode 100644
index 000..79d0c8c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/attrib55.C
@@ -0,0 +1,21 @@
+// { dg-do compile { target c++11 } }
+
+inline namespace N __attribute__((__abi_tag__ ("foo"))) {}
+template struct A {};
+namespace N {
+template class B {};
+}
+template class __attribute__((__unused__)) C {};
+template struct D {
+ template using G = C<_Up>;
+};
+template struct F {
+ template struct H {
+typedef typename D::template G I;
+ };
+};
+template > struct J {
+ C>> L;
+ typedef F>::H>>::I M;
+ J *a;
+};
diff --git a/gcc/testsuite/g++.dg/cpp1z/nodiscard4.C
b/gcc/testsuite/g++.dg/cpp1z/nodiscard4.C
new file mode 100644
index 000..8a95c94
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/nodiscard4.C
@@ -0,0 +1,14 @@
+// PR c++/79502
+// { dg-do compile { target c++11 } }
+
+template
+struct [[nodiscard]] missiles {};
+
+missiles make() { return {}; }
+missiles (*fnptr)() = make;
+
+int main()
+{
+ make(); // { dg-warning "ignoring returned value of type" }
+ fnptr(); // { dg-warning "ignoring returned value of type" }
+}
diff --git a/gcc/testsuite/g++.dg/ext/attrib53.C
b/gcc/testsuite/g++.dg/ext/attrib53.C
new file mode 100644
index 000..408433d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/attrib53.C
@@ -0,0 +1,21 @@
+// { dg-do compile { target c++11 } }
+
+inline namespace N __attribute__((__abi_tag__ ("foo"))) {}
+template struct A;
+namespace N {
+template class B;
+}
+template class C {};
+template struct D {
+ template using G = C<_Up>;
+};
+template struct F {
+ template struct H {
+typedef typename D::template G I;
+ };
+};
+template > struct J {
+ C>> L;
+ typedef F>::H>>::I M;
+ J *a;
+};
patch to fix PR78287
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78127
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 245514.
Index: ChangeLog
===
--- ChangeLog (revision 245513)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2017-02-16 Vladimir Makarov
+
+ PR rtl-optimization/78127
+ * lra.c (lra): Call lra_eliminate before finish the loop after
+ lra_constraint.
+
2017-02-16 Richard Biener
* graphite.h: Do not include isl/isl_val_gmp.h, instead include
Index: lra.c
===
--- lra.c (revision 245513)
+++ lra.c (working copy)
@@ -2389,14 +2389,7 @@ lra (FILE *f)
{
for (;;)
{
- /* We should try to assign hard registers to scratches even
- if there were no RTL transformations in lra_constraints.
- Also we should check IRA assignments on the first
- iteration as they can be wrong because of early clobbers
- operands which are ignored in IRA. */
- if (! lra_constraints (lra_constraint_iter == 0)
- && lra_constraint_iter > 1)
- break;
+ bool reloads_p = lra_constraints (lra_constraint_iter == 0);
/* Constraint transformations may result in that eliminable
hard regs become uneliminable and pseudos which use them
should be spilled. It is better to do it before pseudo
@@ -2406,6 +2399,23 @@ lra (FILE *f)
RS6000_PIC_OFFSET_TABLE_REGNUM uneliminable if we started
to use a constant pool. */
lra_eliminate (false, false);
+ /* We should try to assign hard registers to scratches even
+ if there were no RTL transformations in lra_constraints.
+ Also we should check IRA assignments on the first
+ iteration as they can be wrong because of early clobbers
+ operands which are ignored in IRA. */
+ if (! reloads_p && lra_constraint_iter > 1)
+ {
+ /* Stack is not empty here only when there are changes
+ during the elimination sub-pass. */
+ if (bitmap_empty_p (lra_constraint_insn_stack_bitmap))
+ break;
+ else
+ /* If there are no reloads but changing due
+ elimination, restart the constraint sub-pass
+ first. */
+ continue;
+ }
/* Do inheritance only for regular algorithms. */
if (! lra_simple_p)
{
Re: [PATCH][RFA][target/79404] Fix uninitialized reference to ira_register_move_cost[mode]
On Wed, 15 Feb 2017, Jeff Law wrote: >> .../gerald/gcc-HEAD/libquadmath/math/remainderq.c:67:1: internal >> compiler error: in ira_init_register_move_cost, at ira.c:1580 > Already testing a fix. Thanks, Jeff. Just to confirm that things are back to bootstrap land. Gerald
fwprop fix for PR79405
We have two registers being assigned to each other:
(set (reg 213) (reg 209))
(set (reg 209) (reg 213))
These being the only definitions, we are happy to forward propagate reg
209 for reg 213 into a third insn, making a new use for reg 209. We are
then happy to forward propagate reg 213 for it in the same insn...
ending up in an infinite loop.
I don't really see an elegant way to prevent this, so the following just
tries to detect the situation (and more general ones) by brute force.
Bootstrapped and tested on x86_64-linux, verified that the test passes
with a ppc cross, ok?
Bernd
PR rtl-optimization/79405
* fwprop.c (forward_propagate_into): Detect potentially cyclic
replacements and bail out for them.
PR rtl-optimization/79405
* gcc.dg/torture/pr79405.c: New test.
Index: gcc/fwprop.c
===
--- gcc/fwprop.c (revision 244815)
+++ gcc/fwprop.c (working copy)
@@ -1374,13 +1374,42 @@ forward_propagate_into (df_ref use)
/* Only consider uses that have a single definition. */
def = get_def_for_use (use);
- if (!def)
+ if (!def || DF_REF_INSN_INFO (def) == NULL)
return false;
if (DF_REF_FLAGS (def) & DF_REF_READ_WRITE)
return false;
if (DF_REF_IS_ARTIFICIAL (def))
return false;
+ df_ref tmp_def = def;
+ /* There is a problematic case where a chain of assignments
+ rA = rB; rB = rC; ; rM = rN; rN = rA.
+ can cause us to replace these registers in an infinite cycle.
+ Walk backwards until we can guarantee that this situation is
+ not present. */
+ for (;;)
+{
+ rtx_insn *insn = DF_REF_INSN (tmp_def);
+ rtx set = single_set (insn);
+ if (set == NULL_RTX)
+ break;
+ rtx src = SET_SRC (set);
+ rtx dst = SET_DEST (set);
+ if (GET_CODE (src) != REG || GET_CODE (dst) != REG)
+ break;
+ if (rtx_equal_p (src, DF_REF_REG (use)))
+ return false;
+ df_ref tmp_use = df_single_use (DF_REF_INSN_INFO (tmp_def));
+ if (!tmp_use)
+ break;
+ tmp_def = get_def_for_use (tmp_use);
+ if (!tmp_def || DF_REF_INSN_INFO (tmp_def) == NULL)
+ break;
+ if (DF_REF_FLAGS (tmp_def) & DF_REF_READ_WRITE)
+ break;
+ if (DF_REF_IS_ARTIFICIAL (tmp_def))
+ break;
+}
/* Do not propagate loop invariant definitions inside the loop. */
if (DF_REF_BB (def)->loop_father != DF_REF_BB (use)->loop_father)
return false;
Index: gcc/testsuite/gcc.dg/torture/pr79405.c
===
--- gcc/testsuite/gcc.dg/torture/pr79405.c (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr79405.c (working copy)
@@ -0,0 +1,42 @@
+/* { dg-do compile } */
+char cz;
+long long int xx, u2;
+
+void
+qv (int js, int wl)
+{
+ if (js != 0)
+{
+ short int sc;
+ int *at = (int *)≻
+ long long int gx = 0;
+
+ for (;;)
+{
+ *at = 0;
+ js /= sc;
+
+ for (wl = 0; wl < 2; ++wl)
+{
+ xx = gx;
+ u2 %= xx > 0;
+ cz /= u2;
+
+ fa:
+ if (cz != u2)
+{
+ gx |= js;
+ cz = gx / js;
+}
+}
+}
+
+ yq:
+ wl /= 0x8000;
+ u2 = wl;
+ u2 |= (wl != 0) | (wl != 0 && gx != 0);
+ js = u2;
+ goto fa;
+}
+ goto yq;
+}
[PATCH, aarch64] add unwind support for aarch64-*-freebsd*
Hi all,
the attached patch adds unwind support for aarch64-*-freebsd*.
John used to catch unwind tests in ada.
So far it bootstraps and I see no regressions.
is this ok for trunk?
TIA,
Andreas
2017-02-16 John Marino
* config/aarch64/freebsd-unwind.h: New file.
* config.host: Add aarch64-*-freebsd unwinder.
Index: config.host
===
--- config.host (revision 245512)
+++ config.host (working copy)
@@ -340,7 +340,7 @@
extra_parts="$extra_parts crtfastmath.o"
tmake_file="${tmake_file} ${cpu_type}/t-aarch64"
tmake_file="${tmake_file} ${cpu_type}/t-softfp t-softfp t-crtfm"
- md_unwind_header=aarch64/aarch64-unwind.h
+ md_unwind_header=aarch64/freebsd-unwind.h
;;
aarch64*-*-linux*)
extra_parts="$extra_parts crtfastmath.o"
Index: config/aarch64/freebsd-unwind.h
===
--- config/aarch64/freebsd-unwind.h (nonexistent)
+++ config/aarch64/freebsd-unwind.h (working copy)
@@ -0,0 +1,108 @@
+/* DWARF2 EH unwinding support for FreeBSD/ARM64 (aarch64).
+ Copyright (C) 2017 Free Software Foundation, Inc.
+ Contributed by John Marino
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
+
Re: [PATCH, rs6000] gcc 5 back port of xvcvsxdsp and xvcvuxdsp RTL fixes
On Thu, Feb 16, 2017 at 10:46:46AM -0800, Carl E. Love wrote: > I have backported the mainline fixes for the RTL definitions for > xvcvsxdsp and xvcvuxdsp instructions, commit r245460 on 2017-02-14 to > the GCC 5 branch. > > The RTL defined the instructions with a V2DF argument and returning > V4SI. They should take a V2DI argument and return a V4SF based on the > Power ISA document. Additionally, the RTL define_insn for the xvcvuxdsp > was fixed to generate the correct xvcvuxdsp instruction instead of the > xvcvuxwdp instruction. > > The patch has been tested on powerpc64le-unknown-linux-gnu (Power 8 LE) > with no regressions. > > Is the patch OK for gcc 5 branch? This is okay, thanks! Segher
[PATCH, rs6000] gcc 5 back port of xvcvsxdsp and xvcvuxdsp RTL fixes
GCC Maintainers:
I have backported the mainline fixes for the RTL definitions for
xvcvsxdsp and xvcvuxdsp instructions, commit r245460 on 2017-02-14 to
the GCC 5 branch.
The RTL defined the instructions with a V2DF argument and returning
V4SI. They should take a V2DI argument and return a V4SF based on the
Power ISA document. Additionally, the RTL define_insn for the xvcvuxdsp
was fixed to generate the correct xvcvuxdsp instruction instead of the
xvcvuxwdp instruction.
The patch has been tested on powerpc64le-unknown-linux-gnu (Power 8 LE)
with no regressions.
Is the patch OK for gcc 5 branch?
Carl Love
---
gcc/ChangeLog:
2017-02-16 Carl Love
Backport from mainline commit r245460 on 2017-02-14
PR 79545
* config/rs6000/rs6000.c: Add case statement entry to make the xvcvuxdsp
built-in argument unsigned.
* config/rs6000/vsx.md: Fix the source and return operand types so they
match the instruction definitions from the ISA document. Fix typo
in the instruction generation for the (define_insn "vsx_xvcvuxdsp"
statement.
gcc/testsuite/ChangeLog:
2017-01-16 Carl Love
Backport from mainline commit r245460 on 2017-02-14
PR 79545
* gcc.target/powerpc/vsx-builtin-3.c: Add missing test case for the
xvcvsxdsp and xvcvuxdsp instructions.
---
gcc/config/rs6000/rs6000.c | 1 +
gcc/config/rs6000/vsx.md | 10 +-
gcc/testsuite/gcc.target/powerpc/vsx-builtin-3.c | 23 +++
3 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 5bba64e..234d277 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -15628,6 +15628,7 @@ builtin_function_type (machine_mode mode_ret,
machine_mode mode_arg0,
break;
/* unsigned args, signed return. */
+case VSX_BUILTIN_XVCVUXDSP:
case VSX_BUILTIN_XVCVUXDDP_UNS:
case ALTIVEC_BUILTIN_UNSFLOAT_V4SI_V4SF:
h.uns_p[1] = 1;
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index a689c2b..efbd3ec 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -1501,19 +1501,19 @@
[(set_attr "type" "vecdouble")])
(define_insn "vsx_xvcvsxdsp"
- [(set (match_operand:V4SI 0 "vsx_register_operand" "=wd,?wa")
- (unspec:V4SI [(match_operand:V2DF 1 "vsx_register_operand" "wf,wa")]
+ [(set (match_operand:V4SF 0 "vsx_register_operand" "=wd,?wa")
+ (unspec:V4SF [(match_operand:V2DI 1 "vsx_register_operand" "wf,wa")]
UNSPEC_VSX_CVSXDSP))]
"VECTOR_UNIT_VSX_P (V2DFmode)"
"xvcvsxdsp %x0,%x1"
[(set_attr "type" "vecfloat")])
(define_insn "vsx_xvcvuxdsp"
- [(set (match_operand:V4SI 0 "vsx_register_operand" "=wd,?wa")
- (unspec:V4SI [(match_operand:V2DF 1 "vsx_register_operand" "wf,wa")]
+ [(set (match_operand:V4SF 0 "vsx_register_operand" "=wd,?wa")
+ (unspec:V4SF [(match_operand:V2DI 1 "vsx_register_operand" "wf,wa")]
UNSPEC_VSX_CVUXDSP))]
"VECTOR_UNIT_VSX_P (V2DFmode)"
- "xvcvuxwdp %x0,%x1"
+ "xvcvuxdsp %x0,%x1"
[(set_attr "type" "vecdouble")])
;; Convert from 32-bit to 64-bit types
diff --git a/gcc/testsuite/gcc.target/powerpc/vsx-builtin-3.c
b/gcc/testsuite/gcc.target/powerpc/vsx-builtin-3.c
index f337c1c..ff5296c 100644
--- a/gcc/testsuite/gcc.target/powerpc/vsx-builtin-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/vsx-builtin-3.c
@@ -35,6 +35,8 @@
/* { dg-final { scan-assembler "xvcmpgesp" } } */
/* { dg-final { scan-assembler "xxsldwi" } } */
/* { dg-final { scan-assembler-not "call" } } */
+/* { dg-final { scan-assembler "xvcvsxdsp" } } */
+/* { dg-final { scan-assembler "xvcvuxdsp" } } */
extern __vector int si[][4];
extern __vector short ss[][4];
@@ -50,7 +52,9 @@ extern __vector __pixel p[][4];
#ifdef __VSX__
extern __vector double d[][4];
extern __vector long sl[][4];
+extern __vector long long sll[][4];
extern __vector unsigned long ul[][4];
+extern __vector unsigned long long ull[][4];
extern __vector __bool long bl[][4];
#endif
@@ -211,3 +215,22 @@ int do_xxsldwi (void)
d[i][0] = __builtin_vsx_xxsldwi (d[i][1], d[i][2], 3); i++;
return i;
}
+
+int do_xvcvsxdsp (void)
+{
+ int i = 0;
+
+ f[i][0] = __builtin_vsx_xvcvsxdsp (sll[i][1]); i++;
+
+ return i;
+}
+
+int do_xvcvuxdsp (void)
+{
+ int i = 0;
+
+ f[i][0] = __builtin_vsx_xvcvuxdsp (ull[i][1]); i++;
+
+ return i;
+}
+
--
1.9.1
Re: [Patch, fortran] PR79382 - DTIO ICE
Dear Jerry, > OK for trunk. Not applicable for 6-branch dh! Thanks > Yes OK as long as we are not in freeze. This is not, strictly speaking what we all agreed about a year ago; ie that we would try to abide by gcc conditions. However, I see that everybody else is committing to their heart's content so I might as well do so too. Fortunately, all four of my patches are for either DTIO or submodules and are therefore sufficiently enclosed that they will not break F95 and the rest of F2003 support. Best regards Paul
Re: [Patch, fortran] PR79382 - DTIO ICE
On 02/16/2017 03:31 AM, Paul Richard Thomas wrote: Dear All, The fix for the original bug is tested in dtio_24.f90. It is triggered by the PRIVATE statement in the module and occurs because there is no such generic interface in the module. Note, however, that there is a typebound generic interface, which should not be affected by the PRIVATE statement. The fix looks for the interface and issues an error if it is not present. It was found that the absence of a DTIO procedure in a formatted transfer, where a DT descriptor is present, caused a segfault. The fix in transfer.c was to check if a reference to the DTIO procedure is present and to issue an error if it is not. Unfortunately, since trans-io.c transfers the components of derived types, in the absence of a DTIO procedure, this negates the type check and requires that the test in dtio_10.f90 be changed. I think that it would be a good idea in the future to flag passing of components so that the type test can be recovered. For this reason, I have left the calls in place. Bootstrapped and regtested on FC23/x86_64 - OK for trunk and 6-branch? OK for trunk. Not applicable for 6-branch I am building up a backlog of approved patches: Including this one (if approved :-) ), PRs79402, 79434 & 79447. Would it be OK to commit these to trunk, even though it is in stage 4? Yes OK as long as we are not in freeze. Paul 2017-02-16 Paul Thomas PR fortran/79382 * decl.c (access_attr_decl): Test for presence of generic DTIO interface and emit error if not present. (gfc_match_end): Catch case where a procedure is contained in a module procedure and ensure that 'end procedure' is the correct termination. 2017-02-16 Paul Thomas PR fortran/79382 * io/transfer.c (check_dtio_proc): New function. (formatted_transfer_scalar_read): Use it. (formatted_transfer_scalar_write): ditto. 2017-02-16 Paul Thomas PR fortran/79382 * gfortran.dg/dtio_10.f90 : Change test of error message. * gfortran.dg/dtio_23.f90 : New test. * gfortran.dg/dtio_24.f90 : New test.
[PATCH PR77536]Generate correct profiling information for vectorized loop
Hi,
After fixing PR79347, the main problem with vectorizer is we scale down
profiling counters
for vect_loop by VF, regardless of context CFG's profiling information. This
is wrong and
sometimes makes vect_loop not hot code, which may confuses following
optimizers. This
patch generates well-formed profiling information as generic tree unroller
does. It borrows
code from tree-ssa-loop-manip.c and does small refactors to existing code.
Vectorizer will
not introduce mismatch counters with it, and unroll and vrp2 are the two major
passes
messing up profiling counters now. Though it removes all mismatch in
vectorizer, I am not
sure if this counts as a regression fix.
BTW, it may also help PR78116? Hi Pat, could you please help verify this?
Thanks!
Bootstrap and test on x86_64 and AArch64 ongoing. Is it OK if no failures?
Thanks,
bin
2017-02-16 Bin Cheng
PR tree-optimization/77536
* tree-ssa-loop-manip.c (niter_for_unrolled_loop): New function.
(tree_transform_and_unroll_loop): Use above function to compute the
estimated niter of unrolled loop.
* tree-ssa-loop-manip.h niter_for_unrolled_loop(): New declaration.
* tree-vect-loop.c (scale_profile_for_vect_loop): New function.
(vect_transform_loop): Call above function.
gcc/testsuite/ChangeLog
2017-02-16 Bin Cheng
PR tree-optimization/77536
* gcc.dg/vect/pr79347.c: Revise testing string.diff --git a/gcc/testsuite/gcc.dg/vect/pr79347.c
b/gcc/testsuite/gcc.dg/vect/pr79347.c
index 586c638..6825420 100644
--- a/gcc/testsuite/gcc.dg/vect/pr79347.c
+++ b/gcc/testsuite/gcc.dg/vect/pr79347.c
@@ -10,4 +10,4 @@ void n(void)
a[i]++;
}
-/* { dg-final { scan-tree-dump-times "Invalid sum of " 2 "vect" } } */
+/* { dg-final { scan-tree-dump-not "Invalid sum of " "vect" } } */
diff --git a/gcc/tree-ssa-loop-manip.c b/gcc/tree-ssa-loop-manip.c
index 43df29c..6d868c5 100644
--- a/gcc/tree-ssa-loop-manip.c
+++ b/gcc/tree-ssa-loop-manip.c
@@ -1093,6 +1093,31 @@ scale_dominated_blocks_in_loop (struct loop *loop,
basic_block bb,
}
}
+/* Return estimated niter for LOOP after unrolling by FACTOR times. */
+
+unsigned
+niter_for_unrolled_loop (struct loop *loop, unsigned factor)
+{
+ unsigned est_niter = expected_loop_iterations (loop);
+ gcc_assert (factor != 0);
+ unsigned new_est_niter = est_niter / factor;
+
+ /* Without profile feedback, loops for which we do not know a better estimate
+ are assumed to roll 10 times. When we unroll such loop, it appears to
+ roll too little, and it may even seem to be cold. To avoid this, we
+ ensure that the created loop appears to roll at least 5 times (but at
+ most as many times as before unrolling). */
+ if (new_est_niter < 5)
+{
+ if (est_niter < 5)
+ new_est_niter = est_niter;
+ else
+ new_est_niter = 5;
+}
+
+ return new_est_niter;
+}
+
/* Unroll LOOP FACTOR times. DESC describes number of iterations of LOOP.
EXIT is the exit of the loop to that DESC corresponds.
@@ -1170,12 +1195,11 @@ tree_transform_and_unroll_loop (struct loop *loop,
unsigned factor,
gimple_stmt_iterator bsi;
use_operand_p op;
bool ok;
- unsigned est_niter, prob_entry, scale_unrolled, scale_rest, freq_e, freq_h;
- unsigned new_est_niter, i, prob;
+ unsigned i, prob, prob_entry, scale_unrolled, scale_rest, freq_e, freq_h;
+ unsigned new_est_niter = niter_for_unrolled_loop (loop, factor);
unsigned irr = loop_preheader_edge (loop)->flags & EDGE_IRREDUCIBLE_LOOP;
auto_vec to_remove;
- est_niter = expected_loop_iterations (loop);
determine_exit_conditions (loop, desc, factor,
&enter_main_cond, &exit_base, &exit_step,
&exit_cmp, &exit_bound);
@@ -1207,22 +1231,6 @@ tree_transform_and_unroll_loop (struct loop *loop,
unsigned factor,
gcc_assert (new_loop != NULL);
update_ssa (TODO_update_ssa);
- /* Determine the probability of the exit edge of the unrolled loop. */
- new_est_niter = est_niter / factor;
-
- /* Without profile feedback, loops for that we do not know a better estimate
- are assumed to roll 10 times. When we unroll such loop, it appears to
- roll too little, and it may even seem to be cold. To avoid this, we
- ensure that the created loop appears to roll at least 5 times (but at
- most as many times as before unrolling). */
- if (new_est_niter < 5)
-{
- if (est_niter < 5)
- new_est_niter = est_niter;
- else
- new_est_niter = 5;
-}
-
/* Prepare the cfg and update the phi nodes. Move the loop exit to the
loop latch (and make its condition dummy, for the moment). */
rest = loop_preheader_edge (new_loop)->src;
diff --git a/gcc/tree-ssa-loop-manip.h b/gcc/tree-ssa-loop-manip.h
index 1e7531f..961b38a 100644
--- a/gcc/tree-ssa-loop-manip.h
+++ b/gcc/tree-ssa-loop-manip.h
@@ -48,6 +48,7 @@ extern bool gimple_duplicate_loop_to_header_edge (s
Re: [PATCH, wwwdocs/ARM] Deprecate ARMv5 and ARMv5E support
Thanks. Committed with the mentioned change. Patch in attachment for reference. Best regards, Thomas On 15/02/17 11:26, Richard Earnshaw (lists) wrote: On 15/02/17 11:23, Thomas Preudhomme wrote: Hi, ARMv5 and ARMv5E architectures have no known implementation. I therefore suggest that we deprecate these architectures. ARMv5T, ARMv5TE and ARMv5TEJ would remain supported though. Is this ok to commit? Best regards, Thomas deprecate_armv5_armv5e.patch cvs diff: Diffing . cvs diff: Diffing benchmarks cvs diff: Diffing bugs "cvs -q diff" is your friend :-) Index: gcc-7/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v retrieving revision 1.55 diff -u -r1.55 changes.html --- gcc-7/changes.html 2 Feb 2017 15:21:11 - 1.55 +++ gcc-7/changes.html 14 Feb 2017 09:21:23 - @@ -752,6 +752,13 @@ ARM + Support for the ARMv5 and ARMv5E architectures has been deprecated and Suggest "Support for the ARMv5 and ARMv5E architectures (which have no known implementations) has been ..." + will be removed in a future GCC release. Note that ARMv5T, ARMv5TE and + ARMv5TEJ architectures remain supported. + The values armv5 and armv5e of + -march are thus deprecated. + + The ARMv8.2-A architecture and the ARMv8.2-A 16-bit Floating-Point Extensions are now supported. They can be used by specifying the -march=armv8.2-a or -march=armv8.2-a+fp16 Otherwise OK. R. Index: htdocs/gcc-7/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v retrieving revision 1.55 diff -u -r1.55 changes.html --- htdocs/gcc-7/changes.html 2 Feb 2017 15:21:11 - 1.55 +++ htdocs/gcc-7/changes.html 15 Feb 2017 11:35:49 - @@ -752,6 +752,14 @@ ARM + Support for the ARMv5 and ARMv5E architectures has been deprecated + (which have no known implementations) and will be removed in a future + GCC release. Note that ARMv5T, ARMv5TE and ARMv5TEJ architectures + remain supported. + The values armv5 and armv5e of + -march are thus deprecated. + + The ARMv8.2-A architecture and the ARMv8.2-A 16-bit Floating-Point Extensions are now supported. They can be used by specifying the -march=armv8.2-a or -march=armv8.2-a+fp16
[PATCH] testsuite: pr59833.c and pr61441.c should use -fsignaling-nans
The testcases pr59833.c and pr61441.c check whether signaling NaNs as
input to some operation result in quiet NaNs. Without -fsignaling-nans
this is not guaranteed to happen. So, this patch add this option to
these testcases.
Tested on powerpc64-linux {-m32,-m64}, on aarch64-linux, and on
x86_64-linux (where there is no issignaling, huh -- I tested on gcc20).
Is this okay for trunk?
Segher
2017-02-16 Segher Boessenkool
gcc/testsuite/
* gcc.dg/pr59833.c: Add -fsignaling-nans to options.
* gcc.dg/pr61441.c: Ditto.
---
gcc/testsuite/gcc.dg/pr59833.c | 2 +-
gcc/testsuite/gcc.dg/pr61441.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/pr59833.c b/gcc/testsuite/gcc.dg/pr59833.c
index 45fcf7f..c75efde 100644
--- a/gcc/testsuite/gcc.dg/pr59833.c
+++ b/gcc/testsuite/gcc.dg/pr59833.c
@@ -1,5 +1,5 @@
/* { dg-do run { target { *-*-linux* *-*-gnu* } } } */
-/* { dg-options "-O0 -lm" } */
+/* { dg-options "-O0 -lm -fsignaling-nans" } */
/* { dg-add-options ieee } */
/* { dg-require-effective-target issignaling } */
diff --git a/gcc/testsuite/gcc.dg/pr61441.c b/gcc/testsuite/gcc.dg/pr61441.c
index 1b0f181..9408e85 100644
--- a/gcc/testsuite/gcc.dg/pr61441.c
+++ b/gcc/testsuite/gcc.dg/pr61441.c
@@ -1,5 +1,5 @@
/* { dg-do run { target { *-*-linux* *-*-gnu* } } } */
-/* { dg-options "-O1 -lm -fexcess-precision=standard" } */
+/* { dg-options "-O1 -lm -fexcess-precision=standard -fsignaling-nans" } */
/* { dg-require-effective-target issignaling } */
#define _GNU_SOURCE
--
1.9.3
[PATCH] [MSP430] PR78838: Do not add section name prefixes when section name is .lowtext
The MSP430 target supports the automatic placement of functions and
data in different memory regions when passing the
"-mdata-region=either" and "-mcode-region=either" options.
MSP430x devices support the large memory model, "-mlarge", which
enables 20 bit pointers, however the vector table across all MSP430
targets only accepts 16-bit pointers. To prevent the use of 20-bit
pointers in the vector table when the large memory model is used, the
MSP430 backend currently places functions specified with the interrupt
attribute in a section called ".lowtext". This section is placed at
the beginning of .text in the MSP430 linker scripts.
PR target/78838 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78838)
reports that a function with the interrupt attribute is placed in a
non-existent section ".either.lowtext" when "-mlarge",
"-mcode-region=either" and "-ffunction-sections" are passed. The
backend has correctly decided to place the function in .lowtext, but
has applied the .either prefix which is undesirable.
No additional .lower/.upper/.either prefixes should be applied to the
section name once it has been placed in .lowtext, the patch below
implements this.
I've built and tested successfully with no regressions reported:
Target is msp430-unknown-elf
Host is x86_64-unknown-linux-gnu
Testsuite variations:
msp430-sim/-mcpu=msp430x/-mlarge/-mdata-region=either/-mcode-region=either
The section .lowtext will only be utilised if the large memory model
is used, which is why I have only tested with this testsuite
variation.
I haven't run the g++ testsuite because msp430-elf doesn't build with
C++ support at the moment:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79242
I don't have write access to the GCC SVN repository, so if this patch
is satisfactory, I would appreciate if someone could commit it for me.
Thanks.
---
2017-02-XX Jozef Lawrynowicz
gcc/
PR target/78838
* config/msp430/msp430.c (gen_prefix): Return NULL when section name is .lowtext
(msp430_section_is_lowtext): New function.
gcc/testsuite
PR target/78838
* gcc.target/msp430/interrupt_fn_placement.c: New test
From: Jozef Lawrynowicz
Date: Wed, 15 Feb 2017 13:03:40 +
Subject: [PATCH] [MSP430] PR78838: Do not add section name prefixes
when the section name is .lowtext
---
gcc/config/msp430/msp430.c | 14 ++
gcc/testsuite/gcc.target/msp430/interrupt_fn_placement.c | 9 +
2 files changed, 23 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/msp430/interrupt_fn_placement.c
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index 6f63116..c9dffb1 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -1808,6 +1808,15 @@ is_critical_func (tree decl = current_function_decl)
return has_attr (ATTR_CRIT, decl);
}
+static bool
+msp430_section_is_lowtext (tree decl = current_function_decl)
+{
+ if (decl == NULL_TREE)
+return false;
+ const char * dec_name = DECL_SECTION_NAME (decl);
+ return dec_name && strcmp (".lowtext", dec_name) == 0;
+}
+
#undef TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS
#define TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS
msp430_allocate_stack_slots_for_args
@@ -2146,6 +2155,11 @@ gen_prefix (tree decl)
if (has_attr ("section", decl))
return NULL;
+ /* If the function has been put in the .lowtext section because it
is an interrupt
+ * handler, and the large memory model is used, then do not add any
prefixes. */
+ if (msp430_section_is_lowtext (decl))
+return NULL;
+
/* If the object has __attribute__((lower)) then use the ".lower."
prefix. */
if (has_attr (ATTR_LOWER, decl))
return lower_prefix;
diff --git a/gcc/testsuite/gcc.target/msp430/interrupt_fn_placement.c
b/gcc/testsuite/gcc.target/msp430/interrupt_fn_placement.c
new file mode 100644
index 000..d5d2113
--- /dev/null
+++ b/gcc/testsuite/gcc.target/msp430/interrupt_fn_placement.c
@@ -0,0 +1,9 @@
+/* { dg-do link } */
+/* { dg-options "-mlarge -mcode-region=either -ffunction-sections" } */
+
+void __attribute__((interrupt(2))) ir_1(void) {
+}
+
+int main(void) {
+ while(1);
+}
--
1.8.3.1
C++ PATCH for c++/78572 (ICE with self-modifying array initializer)
Here, the problem was that the constexpr code for handling assignments
within a constexpr function, or to a temporary object created within
the constant-expression, was also allowing assignment to the target of
the initialization. Fixed by specifically excluding that case.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 13c6ee3097eb21b4e1594504fda53c479b194796
Author: Jason Merrill
Date: Wed Feb 15 16:55:39 2017 -0500
PR c++/78572 - ICE with self-modifying array initializer
* constexpr.c (cxx_eval_store_expression): The object we're
initializing is outside the constant-expression.
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 004bb45..fc7d46c 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1635,6 +1635,7 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree
t,
constexpr_ctx ctx_with_save_exprs = *ctx;
hash_set save_exprs;
ctx_with_save_exprs.save_exprs = &save_exprs;
+ ctx_with_save_exprs.call = &new_call;
tree jump_target = NULL_TREE;
cxx_eval_constant_expression (&ctx_with_save_exprs, body,
@@ -3386,7 +3387,13 @@ cxx_eval_store_expression (const constexpr_ctx *ctx,
tree t,
/* And then find/build up our initializer for the path to the subobject
we're initializing. */
tree *valp;
- if (DECL_P (object))
+ if (object == ctx->object && VAR_P (object)
+ && DECL_NAME (object) && ctx->call == NULL)
+/* The variable we're building up an aggregate initializer for is outside
+ the constant-expression, so don't evaluate the store. We check
+ DECL_NAME to handle TARGET_EXPR temporaries, which are fair game. */
+valp = NULL;
+ else if (DECL_P (object))
valp = ctx->values->get (object);
else
valp = NULL;
diff --git a/gcc/testsuite/g++.dg/init/array47.C
b/gcc/testsuite/g++.dg/init/array47.C
new file mode 100644
index 000..e3cb1b8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/init/array47.C
@@ -0,0 +1,3 @@
+// PR c++/78572
+
+static int array[10] = { array[3]=5, array[7]=3, };
C++ PATCH for c++/79050 (ICE with undeduced auto and LTO)
LTO doesn't know how to stream undeduced auto, which shows up as a
TEMPLATE_TYPE_PARM. Such a declaration isn't useful, since any
reference to it would give an error, so let's just remove it from
BLOCK_VARS.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 3ea102f324537e5706400bfdc8d9f57137877be6
Author: Jason Merrill
Date: Wed Feb 15 16:33:00 2017 -0500
PR c++/79050 - ICE with undeduced auto and LTO
* decl.c (poplevel): Remove undeduced auto decls.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 353e7b5..70c44fb 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -792,14 +792,17 @@ poplevel (int keep, int reverse, int functionbody)
back ends won't understand OVERLOAD, so we remove them here.
Because the BLOCK_VARS are (temporarily) shared with
CURRENT_BINDING_LEVEL->NAMES we must do this fixup after we have
- popped all the bindings. */
+ popped all the bindings. Also remove undeduced 'auto' decls,
+ which LTO doesn't understand, and can't have been used by anything. */
if (block)
{
tree* d;
for (d = &BLOCK_VARS (block); *d; )
{
- if (TREE_CODE (*d) == TREE_LIST)
+ if (TREE_CODE (*d) == TREE_LIST
+ || (!processing_template_decl
+ && undeduced_auto_decl (*d)))
*d = TREE_CHAIN (*d);
else
d = &DECL_CHAIN (*d);
diff --git a/gcc/testsuite/g++.dg/lto/pr79050_0.C
b/gcc/testsuite/g++.dg/lto/pr79050_0.C
new file mode 100644
index 000..1f31b5d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lto/pr79050_0.C
@@ -0,0 +1,7 @@
+// PR c++/79050
+// { dg-lto-do assemble }
+
+int main ()
+{
+ auto foo ();
+}
Re: [C++ RFC] Fix up attribute handling in templates (PR c++/79502)
On Thu, Feb 16, 2017 at 04:57:54PM +0100, Jakub Jelinek wrote:
> Unfortunately it broke bootstrap, *p can already contain some
> other attributes (like abi_tag) and then we ICE in
> apply_identity_attributes. Note the attrib54.C testcase ICEs even
> on vanilla trunk, so if there are any dependent attribute, it is preexisting
> issue.
>
> The following patch bootstrapped successfully, but I see
> +FAIL: g++.dg/ext/vector32.C -std=c++* (internal compiler error)
> +FAIL: g++.dg/ext/vector32a.C -std=c++* (internal compiler error)
> +FAIL: g++.dg/gomp/declare-simd-1.C -std=gnu++* (internal compiler error)
> +FAIL: g++.dg/gomp/declare-simd-1.C -std=gnu++* (test for excess errors)
> +FAIL: g++.dg/lto/20091219 cp_lto_20091219_0.o assemble, -O3 -flto (internal
> compiler error)
> +FAIL: g++.dg/vect/simd-clone-4.cc -std=c++* (test for excess errors)
> +FAIL: g++.dg/vect/simd-clone-5.cc -std=c++* (test for excess errors)
> on i686-linux (x86_64-linux regtest still running). So there are further
> issues.
The issue with the above is that all those are DECL_ATTRIBUTES
which are copied over through copy_node inside of tsubst_decl or so.
Preserving the previous attributes in that case is harmful, they can
contain dependent attributes etc.
That compared to TYPE_ATTRIBUTES which start empty (at least for
classes, for enums there is that
t = start_enum (TYPE_IDENTIFIER (template_type), NULL_TREE,
tsubst (ENUM_UNDERLYING_TYPE (template_type),
arglist, complain, in_decl),
tsubst_attributes (TYPE_ATTRIBUTES
(template_type),
arglist, complain, in_decl),
SCOPED_ENUM_P (template_type), NULL);
) and then sometimes have something added there (such as the abi_tag
attributes) before apply_late_template_attributes is called.
With the following patch I have:
make check-g++ RUNTESTFLAGS="--target_board=unix\{-m32,-m64\} dg.exp='vector*.C
attrib* nodiscard*' gomp.exp=declare-simd* lto.exp=20091219*
vect.exp=simd-clone-*.cc"
without any FAILs. Not sure about the enums, wonder if the abi_tags
attributes couldn't be added even for those.
2017-02-16 Jakub Jelinek
PR c++/79502
* pt.c (apply_late_template_attributes): If there are
no dependent attributes, set *p to attributes. If there were
some attributes in *p previously with or without dependent
attributes, chain them after the new attributes.
* g++.dg/cpp1z/nodiscard4.C: New test.
* g++.dg/ext/attrib53.C: New test.
* g++.dg/ext/attrib54.C: New test.
* g++.dg/ext/attrib55.C: New test.
--- gcc/cp/pt.c.jj 2017-02-16 12:00:20.044455757 +0100
+++ gcc/cp/pt.c 2017-02-16 15:07:31.678727294 +0100
@@ -10086,6 +10086,7 @@ apply_late_template_attributes (tree *de
if (TREE_TYPE (*decl_p) == error_mark_node)
return;
p = &DECL_ATTRIBUTES (*decl_p);
+ *p = NULL_TREE;
}
else
p = &TYPE_ATTRIBUTES (*decl_p);
@@ -10094,6 +10095,7 @@ apply_late_template_attributes (tree *de
{
tree late_attrs = NULL_TREE;
tree *q = &late_attrs;
+ tree prev = *p;
for (*p = attributes; *p; )
{
@@ -10110,9 +10112,14 @@ apply_late_template_attributes (tree *de
else
p = &TREE_CHAIN (t);
}
+ *p = prev;
cplus_decl_attributes (decl_p, late_attrs, attr_flags);
}
+ else if (*p == NULL)
+*p = attributes;
+ else if (attributes)
+*p = chainon (copy_list (attributes), *p);
}
/* Perform (or defer) access check for typedefs that were referenced
--- gcc/testsuite/g++.dg/cpp1z/nodiscard4.C.jj 2017-02-16 14:04:22.602748039
+0100
+++ gcc/testsuite/g++.dg/cpp1z/nodiscard4.C 2017-02-16 14:04:22.601748053
+0100
@@ -0,0 +1,14 @@
+// PR c++/79502
+// { dg-do compile { target c++11 } }
+
+template
+struct [[nodiscard]] missiles {};
+
+missiles make() { return {}; }
+missiles (*fnptr)() = make;
+
+int main()
+{
+ make(); // { dg-warning "ignoring returned value of type" }
+ fnptr(); // { dg-warning "ignoring returned value of type" }
+}
--- gcc/testsuite/g++.dg/ext/attrib53.C.jj 2017-02-16 15:08:18.635107840
+0100
+++ gcc/testsuite/g++.dg/ext/attrib53.C 2017-02-16 15:09:50.210899761 +0100
@@ -0,0 +1,21 @@
+// { dg-do compile { target c++11 } }
+
+inline namespace N __attribute__((__abi_tag__ ("foo"))) {}
+template struct A;
+namespace N {
+template class B;
+}
+template class C {};
+template struct D {
+ template using G = C<_Up>;
+};
+template struct F {
+ template struct H {
+typedef typename D::template G I;
+ };
+};
+template > struct J {
+ C>> L;
+ typedef F>::H>>::I M;
+ J *a;
+};
--- gcc/testsuite/g++.dg/cpp0x/attrib54.C.jj2017-02-16 15:08:21.739066892
+0100
+++ gcc/testsuite/g++.dg/cpp0x/attrib54.C 2017-02-16 15:10:02.461738146
+0100
@@ -0,0 +1,21 @@
+// { dg-do com
Re: [PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745)
On Thu, Feb 16, 2017 at 07:08:00PM +0300, Alexander Monakov wrote:
> On Thu, 16 Feb 2017, Jakub Jelinek wrote:
> > On Thu, Feb 16, 2017 at 01:56:15PM +0300, Alexander Monakov wrote:
> > Are you sure you can't have them in *.c file (e.g. by setting some variable
> > to a spec string or similar)?
> > I think it is better to scan all those files.
>
> Hm, probably that idea was premature, but I hope you can bear with me a bit
> more
> here. It still strikes me as really odd that exgettext works by scanning all
> strings for %e/%n. Would it be possible to explicitly delimit translatable
> spec
> messages, by rewriting where we currently have
>
> "... %eMessage} ..."
>
> to
>
> #define SPEC_MESSAGE(msg) msg
>
> "... %e" SPEC_MESSAGE ("Message") "} ..."
>
> and then only handling SPEC_MESSAGE specially in exgettext, rather than %e?
We have over 90 of these, plus it would make the specs even harder to read.
Will defer this to Joseph anyway.
> > To avoid triggering this you can e.g. use
> > --- gcc/config/nvptx/nvptx.c.jj 2017-01-01 12:45:43.0 +0100
> > +++ gcc/config/nvptx/nvptx.c2017-02-16 12:31:49.261550375 +0100
> > @@ -1129,7 +1129,7 @@ write_omp_entry (FILE *file, const char
> > .reg.u32 %r<3>;\n\
> > .reg.u" PS " %R<4>;\n\
> > mov.u32 %r0, %tid.y;\n\
> > - mov.u32 %r1, %ntid.y;\n\
> > + mov.u32 %r1, %ntid.y;\n""\
> > mov.u32 %r2, %ctaid.x;\n\
> > cvt.u" PS ".u32 %R1, %r0;\n\
> > " MAD_PS_32 " %R1, %r1, %r2, %R1;\n\
>
> I believe this is preferable as a minimal fix, perhaps with a space between
> added quotes, or even:
>
> + mov.u32 %r1, %ntid.y;\n" /* Avoid %n processing in exgettext. */ "\
>
> (sorry for the bikeshed)
>
> > or change the macro so that it doesn't use multi-line string and instead
> > has say:
> > "\n\t" "mov.u32 %r1, %ntid.y;"
> > "\n\t" "mov.u32 %r2, %ctaid.x;"
> > etc. style. or even just
> > " mov.u32 %r1, %ntid.y;\n"
> > " mov.u32 %r2, %ctaid.x;\n"
>
> These variants need adding backslash-at-eol for continuing the macro body. If
> changing the macro is desired, this style can help keep the noise down:
>
> "\nmov.u32 %r1, %ntid.y;" \
Sorry for forgetting the final \ . And no particular preference.
Jakub
Re: [PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745)
On Thu, 16 Feb 2017, Jakub Jelinek wrote:
> On Thu, Feb 16, 2017 at 01:56:15PM +0300, Alexander Monakov wrote:
> Are you sure you can't have them in *.c file (e.g. by setting some variable
> to a spec string or similar)?
> I think it is better to scan all those files.
Hm, probably that idea was premature, but I hope you can bear with me a bit more
here. It still strikes me as really odd that exgettext works by scanning all
strings for %e/%n. Would it be possible to explicitly delimit translatable spec
messages, by rewriting where we currently have
"... %eMessage} ..."
to
#define SPEC_MESSAGE(msg) msg
"... %e" SPEC_MESSAGE ("Message") "} ..."
and then only handling SPEC_MESSAGE specially in exgettext, rather than %e?
> To avoid triggering this you can e.g. use
> --- gcc/config/nvptx/nvptx.c.jj 2017-01-01 12:45:43.0 +0100
> +++ gcc/config/nvptx/nvptx.c 2017-02-16 12:31:49.261550375 +0100
> @@ -1129,7 +1129,7 @@ write_omp_entry (FILE *file, const char
> .reg.u32 %r<3>;\n\
> .reg.u" PS " %R<4>;\n\
> mov.u32 %r0, %tid.y;\n\
> - mov.u32 %r1, %ntid.y;\n\
> + mov.u32 %r1, %ntid.y;\n""\
> mov.u32 %r2, %ctaid.x;\n\
> cvt.u" PS ".u32 %R1, %r0;\n\
> " MAD_PS_32 " %R1, %r1, %r2, %R1;\n\
I believe this is preferable as a minimal fix, perhaps with a space between
added quotes, or even:
+ mov.u32 %r1, %ntid.y;\n" /* Avoid %n processing in exgettext. */ "\
(sorry for the bikeshed)
> or change the macro so that it doesn't use multi-line string and instead
> has say:
> "\n\t""mov.u32 %r1, %ntid.y;"
> "\n\t""mov.u32 %r2, %ctaid.x;"
> etc. style. or even just
> " mov.u32 %r1, %ntid.y;\n"
> " mov.u32 %r2, %ctaid.x;\n"
These variants need adding backslash-at-eol for continuing the macro body. If
changing the macro is desired, this style can help keep the noise down:
"\nmov.u32 %r1, %ntid.y;" \
Thanks.
Alexander
Re: [C++ RFC] Fix up attribute handling in templates (PR c++/79502)
On Wed, Feb 15, 2017 at 03:19:23PM -0500, Jason Merrill wrote:
> OK.
>
> > 2017-02-15 Jakub Jelinek
> >
> > PR c++/79502
> > * pt.c (apply_late_template_attributes): If there are
> > no dependent attributes, set *p to attributes.
> >
> > * g++.dg/cpp1z/nodiscard4.C: New test.
Unfortunately it broke bootstrap, *p can already contain some
other attributes (like abi_tag) and then we ICE in
apply_identity_attributes. Note the attrib54.C testcase ICEs even
on vanilla trunk, so if there are any dependent attribute, it is preexisting
issue.
The following patch bootstrapped successfully, but I see
+FAIL: g++.dg/ext/vector32.C -std=c++* (internal compiler error)
+FAIL: g++.dg/ext/vector32a.C -std=c++* (internal compiler error)
+FAIL: g++.dg/gomp/declare-simd-1.C -std=gnu++* (internal compiler error)
+FAIL: g++.dg/gomp/declare-simd-1.C -std=gnu++* (test for excess errors)
+FAIL: g++.dg/lto/20091219 cp_lto_20091219_0.o assemble, -O3 -flto (internal
compiler error)
+FAIL: g++.dg/vect/simd-clone-4.cc -std=c++* (test for excess errors)
+FAIL: g++.dg/vect/simd-clone-5.cc -std=c++* (test for excess errors)
on i686-linux (x86_64-linux regtest still running). So there are further
issues.
2017-02-16 Jakub Jelinek
PR c++/79502
* pt.c (apply_late_template_attributes): If there are
no dependent attributes, set *p to attributes. If there were
some attributes in *p previously with or without dependent
attributes, chain them after the new attributes.
* g++.dg/cpp1z/nodiscard4.C: New test.
* g++.dg/ext/attrib53.C: New test.
* g++.dg/ext/attrib54.C: New test.
* g++.dg/ext/attrib55.C: New test.
--- gcc/cp/pt.c.jj 2017-02-16 12:00:20.044455757 +0100
+++ gcc/cp/pt.c 2017-02-16 15:07:31.678727294 +0100
@@ -10094,6 +10094,7 @@ apply_late_template_attributes (tree *de
{
tree late_attrs = NULL_TREE;
tree *q = &late_attrs;
+ tree prev = *p;
for (*p = attributes; *p; )
{
@@ -10110,9 +10111,14 @@ apply_late_template_attributes (tree *de
else
p = &TREE_CHAIN (t);
}
+ *p = prev;
cplus_decl_attributes (decl_p, late_attrs, attr_flags);
}
+ else if (*p == NULL)
+*p = attributes;
+ else if (attributes)
+*p = chainon (copy_list (attributes), *p);
}
/* Perform (or defer) access check for typedefs that were referenced
--- gcc/testsuite/g++.dg/cpp1z/nodiscard4.C.jj 2017-02-16 14:04:22.602748039
+0100
+++ gcc/testsuite/g++.dg/cpp1z/nodiscard4.C 2017-02-16 14:04:22.601748053
+0100
@@ -0,0 +1,14 @@
+// PR c++/79502
+// { dg-do compile { target c++11 } }
+
+template
+struct [[nodiscard]] missiles {};
+
+missiles make() { return {}; }
+missiles (*fnptr)() = make;
+
+int main()
+{
+ make(); // { dg-warning "ignoring returned value of type" }
+ fnptr(); // { dg-warning "ignoring returned value of type" }
+}
--- gcc/testsuite/g++.dg/ext/attrib53.C.jj 2017-02-16 15:08:18.635107840
+0100
+++ gcc/testsuite/g++.dg/ext/attrib53.C 2017-02-16 15:09:50.210899761 +0100
@@ -0,0 +1,21 @@
+// { dg-do compile { target c++11 } }
+
+inline namespace N __attribute__((__abi_tag__ ("foo"))) {}
+template struct A;
+namespace N {
+template class B;
+}
+template class C {};
+template struct D {
+ template using G = C<_Up>;
+};
+template struct F {
+ template struct H {
+typedef typename D::template G I;
+ };
+};
+template > struct J {
+ C>> L;
+ typedef F>::H>>::I M;
+ J *a;
+};
--- gcc/testsuite/g++.dg/cpp0x/attrib54.C.jj2017-02-16 15:08:21.739066892
+0100
+++ gcc/testsuite/g++.dg/cpp0x/attrib54.C 2017-02-16 15:10:02.461738146
+0100
@@ -0,0 +1,21 @@
+// { dg-do compile { target c++11 } }
+
+inline namespace N __attribute__((__abi_tag__ ("foo"))) {}
+template struct A {};
+namespace N {
+template class B {};
+}
+template class __attribute__((__aligned__ (sizeof (T C {};
+template struct D {
+ template using G = C<_Up>;
+};
+template struct F {
+ template struct H {
+typedef typename D::template G I;
+ };
+};
+template > struct J {
+ C>> L;
+ typedef F>::H>>::I M;
+ J *a;
+};
--- gcc/testsuite/g++.dg/cpp0x/attrib55.C.jj2017-02-16 15:08:26.801000114
+0100
+++ gcc/testsuite/g++.dg/cpp0x/attrib55.C 2017-02-16 15:10:11.422619933
+0100
@@ -0,0 +1,21 @@
+// { dg-do compile { target c++11 } }
+
+inline namespace N __attribute__((__abi_tag__ ("foo"))) {}
+template struct A {};
+namespace N {
+template class B {};
+}
+template class __attribute__((__unused__)) C {};
+template struct D {
+ template using G = C<_Up>;
+};
+template struct F {
+ template struct H {
+typedef typename D::template G I;
+ };
+};
+template > struct J {
+ C>> L;
+ typedef F>::H>>::I M;
+ J *a;
+};
Jakub
Re: [PATCH] Fix PR56888
> On Tue, Feb 23, 2016 at 12:32 PM, Richard Biener wrote:
> > On Tue, 23 Feb 2016, Jan Hubicka wrote:
> >
> >> >
> >> > Ok, so maybe a better question to symtab would be if there is an
> >> > actual definition for what __builtin_FOO will call. Not really
> >> > whether that definition is cfun. Of course all the fortify
> >> > always-inline wrappers should not count as such (just in case
> >> > the symtab code is confused about those).
> >>
> >> Also GNU extern inlines that are often used to deal special cases.
> >> >
> >> > So,
> >> >
> >> > bool symbol_table::have_definition (enum built_in_fn);
> >> >
> >> > ? Not sure how to best implement that either. asmname lookups are
> >> > expensive ...
> >>
> >> I am back from China trip, so i can handle you patch if you want.
>
> Honza - ping. Can you please think of a symtab predicate that tells me
> whether a cgraph node is an implementation for BUILT_IN_X? (see original
> patch in this thread).
>
> It's before another GCC release and we're trying to improve QOI wise for
> almost 3 releases now...
Hi,
I hope the following should do the trick...
Honza
Index: cgraph.h
===
--- cgraph.h(revision 245506)
+++ cgraph.h(working copy)
@@ -1214,6 +1214,9 @@ public:
direct calls. */
bool can_remove_if_no_direct_calls_p (bool will_inline = false);
+ /* Return true if symbol can possibly alias with implementation of FNCODE.
*/
+ bool implements(enum built_in_function fncode);
+
/* Return true when callgraph node is a function with Gimple body defined
in current unit. Functions can also be define externally or they
can be thunks with no Gimple representation.
Index: cgraph.c
===
--- cgraph.c(revision 245506)
+++ cgraph.c(working copy)
@@ -3814,4 +3814,45 @@ cgraph_node::has_thunk_p (cgraph_node *n
return false;
}
+/* Return true if symbol can possibly alias with implementation of FNCODE. */
+
+bool
+cgraph_node::implements (enum built_in_function fncode)
+{
+ struct cgraph_node *node = ultimate_alias_target ();
+ tree name = builtin_decl_explicit (fncode);
+
+ if (name)
+name = DECL_ASSEMBLER_NAME (name);
+ else
+name = NULL;
+
+ if ((DECL_BUILT_IN (node->decl)
+ && DECL_BUILT_IN_CLASS (node->decl) == BUILT_IN_NORMAL
+ && DECL_FUNCTION_CODE (node->decl) == fncode)
+ || (name && DECL_ASSEMBLER_NAME_SET_P (node->decl)
+ && symbol_table::assembler_names_equal_p
+ (IDENTIFIER_POINTER (name),
+ IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME
+(node->decl)
+return true;
+
+ ipa_ref *ref;
+ FOR_EACH_ALIAS (node, ref)
+{
+ cgraph_node *alias = dyn_cast (ref->referring);
+ if ((DECL_BUILT_IN (alias->decl)
+ && DECL_BUILT_IN_CLASS (alias->decl) == BUILT_IN_NORMAL
+ && DECL_FUNCTION_CODE (alias->decl) == fncode)
+ || (name && DECL_ASSEMBLER_NAME_SET_P (alias->decl)
+ && symbol_table::assembler_names_equal_p
+ (IDENTIFIER_POINTER (name),
+ IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME
+(alias->decl)
+ return true;
+}
+
+ return false;
+}
+
#include "gt-cgraph.h"
Re: [GIMPLE FE] add fma_expr
On Thu, 16 Feb 2017, Prathamesh Kulkarni wrote:
> Hi Richard,
> The attached patch handles fma_expr in gimple-fe.
> Does it look OK ?
+ tree arg0_type = TREE_TYPE (args[0]);
+ if (!SCALAR_FLOAT_TYPE_P (arg0_type))
+ {
+ error_at (loc, "operands to __FMA should have"
+" floating point type");
+ expr.value = error_mark_node;
+ return expr;
+ }
+
+ for (int pass = 1; pass < 3; ++pass)
+ {
+ tree type = TREE_TYPE (args[pass]);
+ if (arg0_type != type
+ || element_precision (arg0_type) !=
element_precision
(type))
+ {
+ error_at (loc, "operands to __FMA should have same
type");
+ expr.value = error_mark_node;
+ return expr;
+ }
+ }
please omit this, other types are ok and type verification is
done by the GIMPLE verifier in tree-cfg.c.
Ok with that change.
Thanks,
Richard.
[GIMPLE FE] add fma_expr
Hi Richard,
The attached patch handles fma_expr in gimple-fe.
Does it look OK ?
Thanks,
Prathamesh
diff --git a/gcc/c/gimple-parser.c b/gcc/c/gimple-parser.c
index d959877..fbd4c8c 100644
--- a/gcc/c/gimple-parser.c
+++ b/gcc/c/gimple-parser.c
@@ -856,6 +856,50 @@ c_parser_gimple_postfix_expression (c_parser *parser)
expr.value = fold_convert (type, val);
return expr;
}
+ else if (strcmp (IDENTIFIER_POINTER (id), "__FMA") == 0)
+ {
+ c_parser_consume_token (parser);
+ auto_vec args;
+
+ if (c_parser_require (parser, CPP_OPEN_PAREN, "expected %<(%>"))
+ {
+ c_parser_gimple_expr_list (parser, &args);
+ c_parser_skip_until_found (parser, CPP_CLOSE_PAREN,
+"expected %<)%>");
+ }
+ if (args.length () != 3)
+ {
+ error_at (loc, "invalid number of operands to __FMA");
+ expr.value = error_mark_node;
+ return expr;
+ }
+
+ tree arg0_type = TREE_TYPE (args[0]);
+ if (!SCALAR_FLOAT_TYPE_P (arg0_type))
+ {
+ error_at (loc, "operands to __FMA should have"
+" floating point type");
+ expr.value = error_mark_node;
+ return expr;
+ }
+
+ for (int pass = 1; pass < 3; ++pass)
+ {
+ tree type = TREE_TYPE (args[pass]);
+ if (arg0_type != type
+ || element_precision (arg0_type) != element_precision
(type))
+ {
+ error_at (loc, "operands to __FMA should have same type");
+ expr.value = error_mark_node;
+ return expr;
+ }
+ }
+
+ expr.value = build3_loc (loc, FMA_EXPR, TREE_TYPE (args[0]),
+ args[0], args[1], args[2]);
+ return expr;
+ }
+
/* SSA name. */
unsigned version, ver_offset;
if (! lookup_name (id)
diff --git a/gcc/testsuite/gcc.dg/gimplefe-26.c
b/gcc/testsuite/gcc.dg/gimplefe-26.c
new file mode 100644
index 000..fa5877e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/gimplefe-26.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fgimple -fdump-tree-ssa-gimple-raw" } */
+
+#define foo(type, num) \
+type __GIMPLE () foo_##num (type a, type b, type c) \
+{ \
+ type t0; \
+ t0_1 = __FMA (a, b, c); \
+ return t0_1; \
+}
+
+foo(float, 1)
+foo(double, 2)
+foo(long double, 3)
+
+/* { dg-final { scan-tree-dump-times "fma_expr" 3 "ssa" } } */
[PATCH] Fix PR79547
I am testing the following patch for PR79547. Those builtins do not
return anything that can be used to re-construct the pointer(s) passed
to them.
Queued for GCC 8.
Richard.
2017-02-16 Richard Biener
PR tree-optimization/79547
* tree-ssa-structalias.c (find_func_aliases_for_builtin_call):
Handle strlen, strcmp, strncmp, strcasecmp, strncasecmp, memcmp,
bcmp, strspn, strcspn, __builtin_object_size and __builtin_constant_p
without any constraints.
* gcc.dg/tree-ssa/strlen-2.c: New testcase.
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c (revision 245501)
+++ gcc/tree-ssa-structalias.c (working copy)
@@ -4474,6 +4474,22 @@ find_func_aliases_for_builtin_call (stru
process_all_all_constraints (lhsc, rhsc);
}
return true;
+ /* Pure functions that return something not based on any object. */
+ case BUILT_IN_STRLEN:
+ case BUILT_IN_STRCMP:
+ case BUILT_IN_STRNCMP:
+ case BUILT_IN_STRCASECMP:
+ case BUILT_IN_STRNCASECMP:
+ case BUILT_IN_MEMCMP:
+ case BUILT_IN_BCMP:
+ case BUILT_IN_STRSPN:
+ case BUILT_IN_STRCSPN:
+ case BUILT_IN_OBJECT_SIZE:
+ case BUILT_IN_CONSTANT_P:
+ /* We don't need to do anything here. No constraints are necessary
+ for the return value and call handling for pure functions is
+ special-cased in the alias oracle. */
+ return true;
/* Trampolines are special - they set up passing the static
frame. */
case BUILT_IN_INIT_TRAMPOLINE:
Index: gcc/testsuite/gcc.dg/tree-ssa/strlen-2.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/strlen-2.c(nonexistent)
+++ gcc/testsuite/gcc.dg/tree-ssa/strlen-2.c(working copy)
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-strlen" } */
+
+void f (unsigned);
+
+void f3 (void)
+{
+ char s[] = "1234";
+
+ f (__builtin_strlen (s));
+ f (__builtin_strlen (s));
+ f (__builtin_strlen (s));
+}
+
+/* { dg-final { scan-tree-dump-times "strlen" 1 "strlen" } } */
Re: Pretty printers for versioned namespace
On 15/02/17 22:44 +0100, François Dumont wrote: Hi Here is the end result. I eventually chose to detect usage of versioned namespace while generating the .gdb file. I haven't use any caching mecanism considering the limited number of test cases. Tested under Linux x86_64 with and without versioned namespace. * python/Makefile.am (use_versioned_namespace): New. (gdb.py): Subst use_versioned_namespace. * python/Makefile.in: Regenerate. * python/hook.in: Adapt. * python/libstdcxx/v6/printers.py (Printer.add_version): Add name versioned namespace if _versioned_namespace is defined. (Printer.add_one_template_type_printer): Likewise (add_one_type_printer): Likewise. (register_libstdcxx_printers): Add parameter to indicate if versioned namespace is active. * testsuite/lib/gdb-test.exp (get_use_versioned_namespace): New. (gdb-test): Use latter. * testsuite/libstdc++-prettyprinters/48362.cc: Prefer note-test to regexp-test. Ok to commit to trunk ? No, I thought the point of the use_versioned_namespace parameter was to optimise thigns later, if needed. Do we need to do it? We certainly don't need to do it during stage 4, as it's not actually fixing any bug. Let's reconsider during stage 1.
Re: [PATCH] PR libstdc++/60936 reduce coupling between objects in libstdc++.a
On 03/02/17 19:02 +, Jonathan Wakely wrote:
Move explicit instantiation definitions for string I/O functions into
their own files so that iostream and locale definitions are not needed
for uses of strings without I/O. Move functions for throwing C++11
exceptions into the individual files defining the exception types, so
that using any of the functions from functexcept.cc doesn't pull in
large pieces of the C++11 library. Finally, avoid using __int_to_char in
snprintf_lite.cc to avoid pulling in locale-inst.cc for one function.
This fixes a bug in the __concat_size_t function, pointed out in the
PR.
Tested powerpc64le-linux, committed to trunk.
commit 3980cad61df5e51faff2f1edba151417838cc7ef
Author: redi
Date: Thu Feb 16 12:06:28 2017 +
PR libstdc++/60936 fix length calculation
PR libstdc++/60936
* src/c++11/snprintf_lite.cc (__concat_size_t): Calculate length
written to buffer, not length remaining in buffer.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@245505 138bc75d-0d04-0410-961f-82ee72b054a4
diff --git a/libstdc++-v3/src/c++11/snprintf_lite.cc b/libstdc++-v3/src/c++11/snprintf_lite.cc
index 1a408ca..de132d9 100644
--- a/libstdc++-v3/src/c++11/snprintf_lite.cc
+++ b/libstdc++-v3/src/c++11/snprintf_lite.cc
@@ -81,7 +81,7 @@ namespace __gnu_cxx {
__val /= 10;
}
while (__val != 0);
-size_t __len = __out - __cs;
+size_t __len = __cs + __ilen - __out;
if (__bufsize < __len)
return -1;
[committed] Fix -fopenmp-simd #pragma omp target handling (PR c++/79512)
Hi!
Both C and C++ FE had forgotten case when #pragma omp target
is not followed by any identifier token. We need to ignore the pragma
in that case the same as we ignore it e.g. for #pragma omp target data
etc.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2017-02-16 Jakub Jelinek
PR c++/79512
c/
* c-parser.c (c_parser_omp_target): For -fopenmp-simd
ignore #pragma omp target even when not followed by identifier.
cp/
* parser.c (cp_parser_omp_target): For -fopenmp-simd
ignore #pragma omp target even when not followed by identifier.
testsuite/
* c-c++-common/gomp/pr79512.c: New test.
--- gcc/c/c-parser.c.jj 2017-02-13 22:55:31.0 +0100
+++ gcc/c/c-parser.c2017-02-15 15:48:19.688854692 +0100
@@ -16505,6 +16505,11 @@ c_parser_omp_target (c_parser *parser, e
return c_parser_omp_target_update (loc, parser, context);
}
}
+ if (!flag_openmp) /* flag_openmp_simd */
+{
+ c_parser_skip_to_pragma_eol (parser, false);
+ return false;
+}
stmt = make_node (OMP_TARGET);
TREE_TYPE (stmt) = void_type_node;
--- gcc/cp/parser.c.jj 2017-02-14 20:34:48.0 +0100
+++ gcc/cp/parser.c 2017-02-15 15:49:32.803895243 +0100
@@ -35993,6 +35993,11 @@ cp_parser_omp_target (cp_parser *parser,
return cp_parser_omp_target_update (parser, pragma_tok, context);
}
}
+ if (!flag_openmp) /* flag_openmp_simd */
+{
+ cp_parser_skip_to_pragma_eol (parser, pragma_tok);
+ return false;
+}
stmt = make_node (OMP_TARGET);
TREE_TYPE (stmt) = void_type_node;
--- gcc/testsuite/c-c++-common/gomp/pr79512.c.jj2017-02-15
15:51:33.835307012 +0100
+++ gcc/testsuite/c-c++-common/gomp/pr79512.c 2017-02-15 15:51:12.0
+0100
@@ -0,0 +1,14 @@
+/* PR c++/79512 */
+/* { dg-options "-fopenmp-simd" } */
+
+void
+foo (void)
+{
+ #pragma omp target
+ #pragma omp teams
+ {
+int i;
+for (i = 0; i < 10; i++)
+ ;
+ }
+}
Jakub
Re: [PATCH PR71437/V2]Simplify cond with assertions in threading
On Tue, Feb 14, 2017 at 11:05 AM, Bin Cheng wrote: > Hi, > This is the second try fixing PR71437. The old version patch tried to fix > issue in VRP but it requires further non-trivial change in VRP, specifically, > to better support variable value ranges. This is not appropriate at stage 4. > Alternatively, this patch tries to fix issue by improving threading. It > additionally simplifies condition by using assertion conditions. > > Bootstrap and test on x86_64 and AArch64. Is it OK? Hmm. So I'm not a big fan of tree_simplify_using_condition ;) The case in question for the PR was an equivalent assert to the condition? Thus basically tree_simplify_using_condition (x <= 52, x <= 25)? + if (is_gimple_assign (def0) + && TREE_CODE (gimple_assign_rhs1 (def0)) == ASSERT_EXPR) gimple_assign_rhs_code (def0) == ASSERT_EXPR As you add a parameter to tree_simplify_using_condition you can as well fold it into tree_simplify_using_condition_1. And ideally I'd like to see us pass in a decomposed toplevel expression to avoid + tree res = fold_build2 (cond_code, boolean_type_node, + assert_op0, assert_op1); but I'm not sure that will work out ;) So, in the end I wonder if we can fix this in threading w/o usign tree_simplify_using_conditon (the main issue with it I have is the extensive tree building it does). Richard. > Thanks, > bin > > 2017-02-13 Bin Cheng > > PR tree-optimization/71437 > * tree-ssa-loop-niter.c (tree_simplify_using_condition): Only > expand condition if new parameter says so. Also change it to > global. > * tree-ssa-loop-niter.h (tree_simplify_using_condition): New > declaration. > * tree-ssa-threadedge.c (tree-ssa-loop-niter.h): New include file. > (simplify_control_stmt_condition_1): Simplify condition using > assert conditions. > > gcc/testsuite/ChangeLog > 2017-02-13 Bin Cheng > > PR tree-optimization/71437 > * gcc.dg/tree-ssa/pr71437.c: New test.
Re: [PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745)
On Thu, Feb 16, 2017 at 01:56:15PM +0300, Alexander Monakov wrote: > I'm unfamiliar with exgettext (and not objecting to the patch), but from a > quick git-grep it appears that specs strings where this %n/%e capturing needs > to take place only appear in gcc.c and a few .h files. And on the other hand, > there's already a few other .c files under gcc/config/ that use %n/%e in > non-specs context, so I guess there's a risk of false positives elsewhere too. > > Would it be acceptable to future-proof it a bit by calling spec_error_string > in exgettext only on *.h files and gcc.c? Are you sure you can't have them in *.c file (e.g. by setting some variable to a spec string or similar)? I think it is better to scan all those files. To avoid triggering this you can e.g. use --- gcc/config/nvptx/nvptx.c.jj 2017-01-01 12:45:43.0 +0100 +++ gcc/config/nvptx/nvptx.c2017-02-16 12:31:49.261550375 +0100 @@ -1129,7 +1129,7 @@ write_omp_entry (FILE *file, const char .reg.u32 %r<3>;\n\ .reg.u" PS " %R<4>;\n\ mov.u32 %r0, %tid.y;\n\ - mov.u32 %r1, %ntid.y;\n\ + mov.u32 %r1, %ntid.y;\n""\ mov.u32 %r2, %ctaid.x;\n\ cvt.u" PS ".u32 %R1, %r0;\n\ " MAD_PS_32 " %R1, %r1, %r2, %R1;\n\ or change the macro so that it doesn't use multi-line string and instead has say: "\n\t" "mov.u32 %r1, %ntid.y;" "\n\t" "mov.u32 %r2, %ctaid.x;" etc. style. or even just " mov.u32 %r1, %ntid.y;\n" " mov.u32 %r2, %ctaid.x;\n" style. Jakub
Re: [RFA][PR tree-optimization/79095] [PATCH 1/4] Improve ranges for MINUS_EXPR and EXACT_DIV_EXPR
On Tue, Feb 14, 2017 at 10:41 PM, Jeff Law wrote: > On 02/14/2017 01:58 AM, Richard Biener wrote: >>> >>> >>> I spoke with Andrew a bit today, he's consistently seeing cases where the >>> union of 3 ranges is necessary to resolve the kinds of queries we're >>> interested in. He's made a design decision not to use anti-ranges in his >>> work, so y'all are in sync on that long term. >> >> >> Ok. I'd also not hard-code the number of union ranges but make the code >> agnostic. Still the actual implementation might take a #define / template >> param >> for an upper bound. > > Andrew was in-sync on not hard-coding the number of ranges either -- > essentially he's considering the possibility that consumers might want > different levels of detail and thus a different number of recorded union > ranges. > > I'm not 100% sure that level of engineering is needed, but a design which > accounts for that inherently avoids hard-coding the upper bound. Yeah. And then there's (independently) SSA_NAME_RANGE_INFO which needs a memory-compact representation which means it might make sense to retain anti-ranges for that and use at most one range/anti-range. Richard. > Jeff
Re: Handle GIMPLE NOPs in is_maybe_undefined (PR, tree-optimization/79529).
On Thu, Feb 16, 2017 at 11:45 AM, Aldy Hernandez wrote: > On 02/16/2017 03:46 AM, Martin Liška wrote: >> >> On 02/15/2017 05:06 PM, Aldy Hernandez wrote: >>> >>> On 02/15/2017 09:49 AM, Martin Liška wrote: Hi. As mentioned in the PR, gimple nops are wrongly handled in is_maybe_undefined function. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. >>> >>> gimple *def = SSA_NAME_DEF_STMT (t); + if (!def || gimple_nop_p (def)) +return true; + >>> >>> >>> >>> Out of curiosity, what is T? >> >> >> It's a SSA name which belongs to a result_decl: >> >> (gdb) p debug_tree(t) >> > type > type > needs-constructing BLK >> size >> unit size >> align 64 symtab 0 alias set -1 canonical type 0x766b0e70 >> fields context > 0x766954c0 icu_58> >> pointer_to_this >> reference_to_this chain > 0x70669428 UnicodeString>> >> public unsigned DI >> size >> unit size >> align 64 symtab 0 alias set -1 structural equality> >> var >> def_stmt GIMPLE_NOP >> version 1 >> ptr-info 0x7fffcc191000> >> >>> >>> Because we early bail out if ssa_undefined_value_p() right before calling >>> SSA_NAME_DEF_STMT, and ssa_undefined_value_p() will already bail if >>> gimple_nop_p. >>> >>> So T must be one of: >>> >>> >>> /* Parameters get their initial value from the function entry. */ >>> else if (TREE_CODE (var) == PARM_DECL) >>> return false; >>> /* When returning by reference the return address is actually a hidden >>> parameter. */ >>> else if (TREE_CODE (var) == RESULT_DECL && DECL_BY_REFERENCE (var)) >>> return false; >> >> >> This return statement is taken. >> >>> /* Hard register variables get their initial value from the ether. */ >>> else if (VAR_P (var) && DECL_HARD_REGISTER (var)) >>> return false; >>> >>> which I wonder if we should special case in is_maybe_undefined. >> >> >> Do we need a special case in the function? > > > It's up to Richi et al, but IMO we should probably treat this as we do > PARM_DECL's, since according to the comment in ssa_undefined_value_p, > returning by reference the return address is actually a hidden parameter. > And as such, we should 'continue' not return in is_maybe_undefined. This > way, we can process the rest of the items in the worklist. > > We already handle: > > /* A PARM_DECL will not have an SSA_NAME_DEF_STMT. Parameters > get their initial value from function entry. */ > if (SSA_NAME_VAR (t) && TREE_CODE (SSA_NAME_VAR (t)) == PARM_DECL) > continue; > > I say we should also handle the rest of the things we handle in > ssa_undefined_value_p: > > /* Parameters get their initial value from the function entry. */ > else if (TREE_CODE (var) == PARM_DECL) > return false; > /* When returning by reference the return address is actually a hidden > parameter. */ > else if (TREE_CODE (var) == RESULT_DECL && DECL_BY_REFERENCE (var)) > return false; > /* Hard register variables get their initial value from the ether. */ > else if (VAR_P (var) && DECL_HARD_REGISTER (var)) > return false; > > ...all doing a "continue", as opposed to a return. > > And if we're going to duplicate all that code, might as well abstract it out > to an inline function. > > Also, we should probably still gracefully handle an empty SSA_NAME_DEF_STMT > as you do in your patch, but with a continue as well. > > Richi, do you agree? Yes, we should handle all of the "hidden initialized" cases at /* A PARM_DECL will not have an SSA_NAME_DEF_STMT. Parameters get their initial value from function entry. */ if (SSA_NAME_VAR (t) && TREE_CODE (SSA_NAME_VAR (t)) == PARM_DECL) continue; maybe add a predicate for those, like ssa_defined_default_def_p () right next to ssa_undefined_value_p and use it from there as well. Richard. > > Aldy
[Patch, fortran] PR79382 - DTIO ICE
Dear All,
The fix for the original bug is tested in dtio_24.f90. It is triggered
by the PRIVATE statement in the module and occurs because there is no
such generic interface in the module. Note, however, that there is a
typebound generic interface, which should not be affected by the
PRIVATE statement. The fix looks for the interface and issues an error
if it is not present.
It was found that the absence of a DTIO procedure in a formatted
transfer, where a DT descriptor is present, caused a segfault. The fix
in transfer.c was to check if a reference to the DTIO procedure is
present and to issue an error if it is not. Unfortunately, since
trans-io.c transfers the components of derived types, in the absence
of a DTIO procedure, this negates the type check and requires that the
test in dtio_10.f90 be changed. I think that it would be a good idea
in the future to flag passing of components so that the type test can
be recovered. For this reason, I have left the calls in place.
Bootstrapped and regtested on FC23/x86_64 - OK for trunk and 6-branch?
I am building up a backlog of approved patches: Including this one (if
approved :-) ), PRs79402, 79434 & 79447. Would it be OK to commit
these to trunk, even though it is in stage 4?
Paul
2017-02-16 Paul Thomas
PR fortran/79382
* decl.c (access_attr_decl): Test for presence of generic DTIO
interface and emit error if not present.
(gfc_match_end): Catch case where a procedure is contained in
a module procedure and ensure that 'end procedure' is the
correct termination.
2017-02-16 Paul Thomas
PR fortran/79382
* io/transfer.c (check_dtio_proc): New function.
(formatted_transfer_scalar_read): Use it.
(formatted_transfer_scalar_write): ditto.
2017-02-16 Paul Thomas
PR fortran/79382
* gfortran.dg/dtio_10.f90 : Change test of error message.
* gfortran.dg/dtio_23.f90 : New test.
* gfortran.dg/dtio_24.f90 : New test.
Index: gcc/fortran/decl.c
===
*** gcc/fortran/decl.c (revision 245196)
--- gcc/fortran/decl.c (working copy)
*** gfc_set_constant_character_len (int len,
*** 1499,1505
if (expr->ts.type != BT_CHARACTER)
return;
!
if (expr->expr_type != EXPR_CONSTANT)
{
gfc_error_now ("CHARACTER length must be a constant at %L",
&expr->where);
--- 1499,1505
if (expr->ts.type != BT_CHARACTER)
return;
!
if (expr->expr_type != EXPR_CONSTANT)
{
gfc_error_now ("CHARACTER length must be a constant at %L",
&expr->where);
*** access_attr_decl (gfc_statement st)
*** 7566,7571
--- 7566,7586
case INTERFACE_GENERIC:
case INTERFACE_DTIO:
+
+ if (type == INTERFACE_DTIO
+ && gfc_current_ns->proc_name
+ && gfc_current_ns->proc_name->attr.flavor == FL_MODULE)
+ {
+ gfc_find_symbol (name, gfc_current_ns, 0, &sym);
+ if (sym == NULL)
+ {
+ gfc_error ("The GENERIC DTIO INTERFACE at %C is not "
+"present in the MODULE '%s'",
+gfc_current_ns->proc_name->name);
+ return MATCH_ERROR;
+ }
+ }
+
if (gfc_get_symbol (name, NULL, &sym))
goto done;
Index: libgfortran/io/transfer.c
===
*** libgfortran/io/transfer.c (revision 245196)
--- libgfortran/io/transfer.c (working copy)
*** require_type (st_parameter_dt *dtp, bt e
*** 1244,1249
--- 1244,1269
}
+ /* Check that the dtio procedure required for formatted IO is present. */
+
+ static int
+ check_dtio_proc (st_parameter_dt *dtp, const fnode *f)
+ {
+ char buffer[BUFLEN];
+
+ if (dtp->u.p.fdtio_ptr != NULL)
+ return 0;
+
+ snprintf (buffer, BUFLEN,
+ "Missing DTIO procedure or intrinsic type passed for item %d "
+ "in formatted transfer",
+ dtp->u.p.item_count - 1);
+
+ format_error (dtp, f, buffer);
+ return 1;
+ }
+
+
static int
require_numeric_type (st_parameter_dt *dtp, bt actual, const fnode *f)
{
*** formatted_transfer_scalar_read (st_param
*** 1436,1441
--- 1456,1464
case FMT_DT:
if (n == 0)
goto need_read_data;
+
+ if (check_dtio_proc (dtp, f))
+ return;
if (require_type (dtp, BT_CLASS, type, f))
return;
int unit = dtp->u.p.current_unit->unit_number;
*** formatted_transfer_scalar_write (st_para
*** 1938,1945
--- 1961,1972
child_iomsg_len = IOMSG_LEN;
}
+ if (check_dtio_proc (dtp, f))
+ return;
+
/* Call the user defined formatted WRITE procedure. */
dtp->u.p.current_unit->child_dtio++;
+
dtp->u.p.fdtio_ptr (p, &unit, io
Re: [PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745)
On Thu, 16 Feb 2017, Thomas Schwinge wrote:
> On Mon, 9 Jan 2017 17:21:41 +0100, I wrote:
> > On Thu, 29 Dec 2016 16:15:01 +0100, Jakub Jelinek wrote:
> > > PR translation/78745
> > > * exgettext: Handle multi-line help texts in *.opt files.
> >
> > With this committed in r243981, I noticed the following new snippet in
> > gcc/po/gcc.pot:
> >
> > +#: config/nvptx/nvptx.c:1132
> > +msgid "tid.y;"
> > +msgstr ""
> >
> > gcc/config/nvptx/nvptx.c:
> >
> >1126 #define ENTRY_TEMPLATE(PS, PS_BYTES, MAD_PS_32) "\
> >1127 (.param.u" PS " %arg, .param.u" PS " %stack, .param.u" PS " %sz)\n\
> >1128 {\n\
> >1129 .reg.u32 %r<3>;\n\
> >1130 .reg.u" PS " %R<4>;\n\
> >1131 mov.u32 %r0, %tid.y;\n\
> >1132 mov.u32 %r1, %ntid.y;\n\
> >1133 mov.u32 %r2, %ctaid.x;\n\
> >[...]
> >
> > As I understand it, this is because of the special handling to collect
> > "all %e and %n strings from driver specs, so those can be translated too"
> > (function spec_error_string). Probably harmless enough to just ignore
> > it?
>
> Well, this got reported as part of PR79332. OK to address as follows?
I'm unfamiliar with exgettext (and not objecting to the patch), but from a
quick git-grep it appears that specs strings where this %n/%e capturing needs
to take place only appear in gcc.c and a few .h files. And on the other hand,
there's already a few other .c files under gcc/config/ that use %n/%e in
non-specs context, so I guess there's a risk of false positives elsewhere too.
Would it be acceptable to future-proof it a bit by calling spec_error_string
in exgettext only on *.h files and gcc.c?
Thanks.
Alexander
Re: [PATCH][GCC6] Backport PR target/76731 fix
On Thu, Feb 16, 2017 at 11:21 AM, Koval, Julia wrote: > Can you commit it for me please? Also these intrinsics are very old, can I > also backport it to GCC5 and GCC4.9? Backport to gcc-5 is OK, but gcc-4.9 branch is closed. Uros.
Re: Handle GIMPLE NOPs in is_maybe_undefined (PR, tree-optimization/79529).
On 02/16/2017 03:46 AM, Martin Liška wrote: On 02/15/2017 05:06 PM, Aldy Hernandez wrote: On 02/15/2017 09:49 AM, Martin Liška wrote: Hi. As mentioned in the PR, gimple nops are wrongly handled in is_maybe_undefined function. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. gimple *def = SSA_NAME_DEF_STMT (t); + if (!def || gimple_nop_p (def)) +return true; + Out of curiosity, what is T? It's a SSA name which belongs to a result_decl: (gdb) p debug_tree(t) unit size align 64 symtab 0 alias set -1 canonical type 0x766b0e70 fields context pointer_to_this reference_to_this chain > public unsigned DI size unit size align 64 symtab 0 alias set -1 structural equality> var def_stmt GIMPLE_NOP version 1 ptr-info 0x7fffcc191000> Because we early bail out if ssa_undefined_value_p() right before calling SSA_NAME_DEF_STMT, and ssa_undefined_value_p() will already bail if gimple_nop_p. So T must be one of: /* Parameters get their initial value from the function entry. */ else if (TREE_CODE (var) == PARM_DECL) return false; /* When returning by reference the return address is actually a hidden parameter. */ else if (TREE_CODE (var) == RESULT_DECL && DECL_BY_REFERENCE (var)) return false; This return statement is taken. /* Hard register variables get their initial value from the ether. */ else if (VAR_P (var) && DECL_HARD_REGISTER (var)) return false; which I wonder if we should special case in is_maybe_undefined. Do we need a special case in the function? It's up to Richi et al, but IMO we should probably treat this as we do PARM_DECL's, since according to the comment in ssa_undefined_value_p, returning by reference the return address is actually a hidden parameter. And as such, we should 'continue' not return in is_maybe_undefined. This way, we can process the rest of the items in the worklist. We already handle: /* A PARM_DECL will not have an SSA_NAME_DEF_STMT. Parameters get their initial value from function entry. */ if (SSA_NAME_VAR (t) && TREE_CODE (SSA_NAME_VAR (t)) == PARM_DECL) continue; I say we should also handle the rest of the things we handle in ssa_undefined_value_p: /* Parameters get their initial value from the function entry. */ else if (TREE_CODE (var) == PARM_DECL) return false; /* When returning by reference the return address is actually a hidden parameter. */ else if (TREE_CODE (var) == RESULT_DECL && DECL_BY_REFERENCE (var)) return false; /* Hard register variables get their initial value from the ether. */ else if (VAR_P (var) && DECL_HARD_REGISTER (var)) return false; ...all doing a "continue", as opposed to a return. And if we're going to duplicate all that code, might as well abstract it out to an inline function. Also, we should probably still gracefully handle an empty SSA_NAME_DEF_STMT as you do in your patch, but with a continue as well. Richi, do you agree? Aldy
Re: [PATCH] PR 79356: Do not xfail attr-alloc_size-11.c on some targets.
Hi Dominik, > The attached patch removes the xfail on two sub tests of > attr-alloc_size-11.c for the targets who were reported to produce > an XPASS: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79356 > > Tested on s390x biarch and s390. Please check if the strings for > the other targets are correct. successfully tested on sparc-sun-solaris2.12. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745)
Hi!
On Mon, 9 Jan 2017 17:21:41 +0100, I wrote:
> On Thu, 29 Dec 2016 16:15:01 +0100, Jakub Jelinek wrote:
> > PR translation/78745
> > * exgettext: Handle multi-line help texts in *.opt files.
>
> With this committed in r243981, I noticed the following new snippet in
> gcc/po/gcc.pot:
>
> +#: config/nvptx/nvptx.c:1132
> +msgid "tid.y;"
> +msgstr ""
>
> gcc/config/nvptx/nvptx.c:
>
>1126 #define ENTRY_TEMPLATE(PS, PS_BYTES, MAD_PS_32) "\
>1127 (.param.u" PS " %arg, .param.u" PS " %stack, .param.u" PS " %sz)\n\
>1128 {\n\
>1129 .reg.u32 %r<3>;\n\
>1130 .reg.u" PS " %R<4>;\n\
>1131 mov.u32 %r0, %tid.y;\n\
>1132 mov.u32 %r1, %ntid.y;\n\
>1133 mov.u32 %r2, %ctaid.x;\n\
>[...]
>
> As I understand it, this is because of the special handling to collect
> "all %e and %n strings from driver specs, so those can be translated too"
> (function spec_error_string). Probably harmless enough to just ignore
> it?
Well, this got reported as part of PR79332. OK to address as follows?
commit d7e9c522704d9221659b1d752c33c708083a5ee0
Author: Thomas Schwinge
Date: Thu Feb 16 11:24:41 2017 +0100
[PR translation/79332] "%ntid.y" confuses gcc.pot generation
gcc/
* config/nvptx/nvptx.c (ENTRY_TEMPLATE): Single out "%ntid.y".
---
gcc/config/nvptx/nvptx.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git gcc/config/nvptx/nvptx.c gcc/config/nvptx/nvptx.c
index 98278d3..c52b090 100644
--- gcc/config/nvptx/nvptx.c
+++ gcc/config/nvptx/nvptx.c
@@ -1123,13 +1123,15 @@ write_omp_entry (FILE *file, const char *name, const
char *orig)
func_decls << ".extern .func gomp_nvptx_main (.param.u" << POINTER_SIZE
<< " %in_ar1, .param.u" << POINTER_SIZE << " %in_ar2);\n";
}
+ /* PR79332. Single out this string; it confuses gcc.pot generation. */
+#define NTID_Y "%ntid.y"
#define ENTRY_TEMPLATE(PS, PS_BYTES, MAD_PS_32) "\
(.param.u" PS " %arg, .param.u" PS " %stack, .param.u" PS " %sz)\n\
{\n\
.reg.u32 %r<3>;\n\
.reg.u" PS " %R<4>;\n\
mov.u32 %r0, %tid.y;\n\
- mov.u32 %r1, %ntid.y;\n\
+ mov.u32 %r1, " NTID_Y ";\n\
mov.u32 %r2, %ctaid.x;\n\
cvt.u" PS ".u32 %R1, %r0;\n\
" MAD_PS_32 " %R1, %r1, %r2, %R1;\n\
@@ -1157,6 +1159,7 @@ write_omp_entry (FILE *file, const char *name, const char
*orig)
static const char entry64[] = ENTRY_TEMPLATE ("64", "8", "mad.wide.u32");
static const char entry32[] = ENTRY_TEMPLATE ("32", "4", "mad.lo.u32 ");
#undef ENTRY_TEMPLATE
+#undef NTID_Y
const char *entry_1 = TARGET_ABI64 ? entry64 : entry32;
/* Position ENTRY_2 after the embedded nul using strlen of the prefix. */
const char *entry_2 = entry_1 + strlen (entry64) + 1;
Grüße
Thomas
RE: [PATCH][GCC6] Backport PR target/76731 fix
Can you commit it for me please? Also these intrinsics are very old, can I also backport it to GCC5 and GCC4.9? Thanks, Julia -Original Message- From: Uros Bizjak [mailto:ubiz...@gmail.com] Sent: Thursday, February 16, 2017 9:27 AM To: Koval, Julia Cc: GCC Patches Subject: Re: [PATCH][GCC6] Backport PR target/76731 fix On Wed, Feb 15, 2017 at 1:03 PM, Koval, Julia wrote: > Hi, > Is it ok to backport this fix to GCC6 branch? > > PR target/76731 > * config/i386/avx512fintrin.h > (_mm512_i32gather_ps): Change __addr type to void const*. > (_mm512_mask_i32gather_ps): Ditto. > (_mm512_i32gather_pd): Ditto. > (_mm512_mask_i32gather_pd): Ditto. > (_mm512_i64gather_ps): Ditto. > (_mm512_mask_i64gather_ps): Ditto. > (_mm512_i64gather_pd): Ditto. > (_mm512_mask_i64gather_pd): Ditto. > (_mm512_i32gather_epi32): Ditto. > (_mm512_mask_i32gather_epi32): Ditto. > (_mm512_i32gather_epi64): Ditto. > (_mm512_mask_i32gather_epi64): Ditto. > (_mm512_i64gather_epi32): Ditto. > (_mm512_mask_i64gather_epi32): Ditto. > (_mm512_i64gather_epi64): Ditto. > (_mm512_mask_i64gather_epi64): Ditto. > (_mm512_i32scatter_ps): Change __addr type to void*. > (_mm512_mask_i32scatter_ps): Ditto. > (_mm512_i32scatter_pd): Ditto. > (_mm512_mask_i32scatter_pd): Ditto. > (_mm512_i64scatter_ps): Ditto. > (_mm512_mask_i64scatter_ps): Ditto. > (_mm512_i64scatter_pd): Ditto. > (_mm512_mask_i64scatter_pd): Ditto. > (_mm512_i32scatter_epi32): Ditto. > (_mm512_mask_i32scatter_epi32): Ditto. > (_mm512_i32scatter_epi64): Ditto. > (_mm512_mask_i32scatter_epi64): Ditto. > (_mm512_i64scatter_epi32): Ditto. > (_mm512_mask_i64scatter_epi32): Ditto. > (_mm512_i64scatter_epi64): Ditto. > (_mm512_mask_i64scatter_epi64): Ditto. > * config/i386/avx512pfintrin.h > (_mm512_mask_prefetch_i32gather_pd): Change addr type to void const*. > (_mm512_mask_prefetch_i32gather_ps): Ditto. > (_mm512_mask_prefetch_i64gather_pd): Ditto. > (_mm512_mask_prefetch_i64gather_ps): Ditto. > (_mm512_prefetch_i32scatter_pd): Change addr type to void*. > (_mm512_prefetch_i32scatter_ps): Ditto. > (_mm512_mask_prefetch_i32scatter_pd): Ditto. > (_mm512_mask_prefetch_i32scatter_ps): Ditto. > (_mm512_prefetch_i64scatter_pd): Ditto. > (_mm512_prefetch_i64scatter_ps): Ditto. > (_mm512_mask_prefetch_i64scatter_pd): Ditto. > (_mm512_mask_prefetch_i64scatter_ps): Ditto. > * config/i386/avx512vlintrin.h > (_mm256_mmask_i32gather_ps): Change __addr type to void const*. > (_mm_mmask_i32gather_ps): Ditto. > (_mm256_mmask_i32gather_pd): Ditto. > (_mm_mmask_i32gather_pd): Ditto. > (_mm256_mmask_i64gather_ps): Ditto. > (_mm_mmask_i64gather_ps): Ditto. > (_mm256_mmask_i64gather_pd): Ditto. > (_mm_mmask_i64gather_pd): Ditto. > (_mm256_mmask_i32gather_epi32): Ditto. > (_mm_mmask_i32gather_epi32): Ditto. > (_mm256_mmask_i32gather_epi64): Ditto. > (_mm_mmask_i32gather_epi64): Ditto. > (_mm256_mmask_i64gather_epi32): Ditto. > (_mm_mmask_i64gather_epi32): Ditto. > (_mm256_mmask_i64gather_epi64): Ditto. > (_mm_mmask_i64gather_epi64): Ditto. > (_mm256_i32scatter_ps): Change __addr type to void*. > (_mm256_mask_i32scatter_ps): Ditto. > (_mm_i32scatter_ps): Ditto. > (_mm_mask_i32scatter_ps): Ditto. > (_mm256_i32scatter_pd): Ditto. > (_mm256_mask_i32scatter_pd): Ditto. > (_mm_i32scatter_pd): Ditto. > (_mm_mask_i32scatter_pd): Ditto. > (_mm256_i64scatter_ps): Ditto. > (_mm256_mask_i64scatter_ps): Ditto. > (_mm_i64scatter_ps): Ditto. > (_mm_mask_i64scatter_ps): Ditto. > (_mm256_i64scatter_pd): Ditto. > (_mm256_mask_i64scatter_pd): Ditto. > (_mm_i64scatter_pd): Ditto. > (_mm_mask_i64scatter_pd): Ditto. > (_mm256_i32scatter_epi32): Ditto. > (_mm256_mask_i32scatter_epi32): Ditto. > (_mm_i32scatter_epi32): Ditto. > (_mm_mask_i32scatter_epi32): Ditto. > (_mm256_i32scatter_epi64): Ditto. > (_mm256_mask_i32scatter_epi64): Ditto. > (_mm_i32scatter_epi64): Ditto. > (_mm_mask_i32scatter_epi64): Ditto. > (_mm256_i64scatter_epi32): Ditto. > (_mm256_mask_i64scatter_epi32): Ditto. > (_mm_i64scatter_epi32): Ditto. > (_mm_mask_i64scatter_epi32): Ditto. > (_mm256_i64scatter_epi64): Ditto. > (_mm256_mask_i64scatter_epi64): Ditto. > (_mm_i64scatter_epi64): Ditto. > (_mm_mask_i64scatter_epi64): Ditto. > * config/i386/i386-builtin-types.def > (V16SF_V16SF_PCFLOAT_
Re: [GIMPLE FE] avoid ICE with same ssa version number for multiple names
On 16 February 2017 at 14:01, Richard Biener wrote:
> On Wed, 15 Feb 2017, Prathamesh Kulkarni wrote:
>
>> Hi,
>> For the following (invalid) test-case:
>>
>> void __GIMPLE () foo (int a)
>> {
>> int t0;
>> int _1;
>> _1 = a;
>> t0_1 = a;
>> }
>>
>> results in following ICE:
>> gimplefe-error-4.c: In function ‘foo’:
>> gimplefe-error-4.c:20:1: error: SSA_NAME_DEF_STMT is wrong
>> }
>> ^
>> Expected definition statement:
>> _1 = a_2(D);
>>
>> Actual definition statement:
>> _1 = a_2(D);
>> gimplefe-error-4.c:20:1: internal compiler error: verify_ssa failed
>> 0xe1458b verify_ssa(bool, bool)
>> ../../gcc/gcc/tree-ssa.c:1184
>> 0xb0d1ed execute_function_todo
>> ../../gcc/gcc/passes.c:1973
>> 0xb0dad5 execute_todo
>> ../../gcc/gcc/passes.c:2016
>>
>> The reason for ICE is that in c_parser_parse_ssa_name, ssa_name (1)
>> returns tree node for _1, and "t0_1" gets replaced by "_1"
>> resulting in multiple definitions for _1.
>>
>> The attached patch checks if multiple ssa names have same version
>> number and emits a diagnostic in that case, for the above case:
>> gimplefe-error-4.c: In function ‘foo’:
>> gimplefe-error-4.c:10:3: error: ssa version ‘1’ used anonymously and in ‘t0’
>>t0_1 = a;
>>^~~~
>>
>> OK to commit after bootstrap+test ?
>
> Hmm, I'd rather (if at all -- I consider these kind of verification errors
> appropriate for valid GIMPLE FE input) do sth like
>
> Index: gcc/c/gimple-parser.c
> ===
> --- gcc/c/gimple-parser.c (revision 245501)
> +++ gcc/c/gimple-parser.c (working copy)
> @@ -315,6 +315,12 @@ c_parser_gimple_statement (c_parser *par
> else if (! FLOAT_TYPE_P (TREE_TYPE (lhs.value))
>&& FLOAT_TYPE_P (TREE_TYPE (rhs.value)))
> code = FIX_TRUNC_EXPR;
> + if (TREE_CODE (lhs.value) == SSA_NAME
> + && SSA_NAME_DEF_STMT (lhs.value))
> + {
> + c_parser_error (parser, "duplicate definition of SSA name");
> + /* point at previous definition, do not emit stmt */
> + }
> assign = gimple_build_assign (lhs.value, code, rhs.value);
> gimple_seq_add_stmt (seq, assign);
> gimple_set_location (assign, loc);
> @@ -347,6 +353,13 @@ c_parser_gimple_statement (c_parser *par
>rhs = c_parser_gimple_unary_expression (parser);
>if (rhs.value != error_mark_node)
> {
> + if (TREE_CODE (lhs.value) == SSA_NAME
> + && SSA_NAME_DEF_STMT (lhs.value))
> + {
> + c_parser_error (parser, "duplicate definition of SSA name");
> + /* point at previous definition, do not emit stmt */
> + }
> +
> assign = gimple_build_assign (lhs.value, rhs.value);
> gimple_set_location (assign, loc);
> gimple_seq_add_stmt (seq, assign);
> @@ -420,6 +433,13 @@ c_parser_gimple_statement (c_parser *par
>if (lhs.value != error_mark_node
>&& rhs.value != error_mark_node)
> {
> + if (TREE_CODE (lhs.value) == SSA_NAME
> + && SSA_NAME_DEF_STMT (lhs.value))
> + {
> + c_parser_error (parser, "duplicate definition of SSA name");
> + /* point at previous definition, do not emit stmt */
> + }
> +
>assign = gimple_build_assign (lhs.value, rhs.value);
>gimple_seq_add_stmt (seq, assign);
>gimple_set_location (assign, loc);
> @@ -692,8 +712,7 @@ c_parser_parse_ssa_name (c_parser *parse
> if (VECTOR_TYPE_P (TREE_TYPE (parent))
> || TREE_CODE (TREE_TYPE (parent)) == COMPLEX_TYPE)
> DECL_GIMPLE_REG_P (parent) = 1;
> - name = make_ssa_name_fn (cfun, parent,
> - gimple_build_nop (), version);
> + name = make_ssa_name_fn (cfun, parent, NULL, version);
> }
> }
>
>
> basically at the point we emit a SSA def diagnose existing ones.
> Should be split out into a verify_def () function, and the diagnostic
> should be more helpful of course.
Hi Richard,
Um IIUC, the issue is not about multiple definitions but when multiple names
are used for same version, we pick the first version.
For eg, the following invalid test-case is accepted by FE, and would not
get caught by gimple-verifiers because the FE generates valid gimple
but does not match the
source.
int __GIMPLE () foo (int a)
{
int t0;
int _1;
_1 = a;
return t0_1;
}
the ssa pass dump shows:
int __GIMPLE ()
foo (int a)
{
int _1;
bb_2:
_1 = a_2(D);
return _1;
}
This happens because c_parser_parse_ssa_name() calls lookup_name (1)
and since we have anonymous ssa
name associated with version number 1 that is returned, and t0_1 gets
replaced by _1 in return stmt.
The patch would reject the above test-case.
Thanks,
Prathamesh
>
> Richard.
>
>>
>> Thanks,
>> Prathamesh
>>
>
> --
> Richard Biener
> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Nor
Re: Handle GIMPLE NOPs in is_maybe_undefined (PR, tree-optimization/79529).
On 02/15/2017 05:06 PM, Aldy Hernandez wrote: > On 02/15/2017 09:49 AM, Martin Liška wrote: >> Hi. >> >> As mentioned in the PR, gimple nops are wrongly handled in >> is_maybe_undefined function. >> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > >> >> gimple *def = SSA_NAME_DEF_STMT (t); >> >> + if (!def || gimple_nop_p (def)) >> +return true; >> + > > > Out of curiosity, what is T? It's a SSA name which belongs to a result_decl: (gdb) p debug_tree(t) unit size align 64 symtab 0 alias set -1 canonical type 0x766b0e70 fields context pointer_to_this reference_to_this chain > public unsigned DI size unit size align 64 symtab 0 alias set -1 structural equality> var def_stmt GIMPLE_NOP version 1 ptr-info 0x7fffcc191000> > > Because we early bail out if ssa_undefined_value_p() right before calling > SSA_NAME_DEF_STMT, and ssa_undefined_value_p() will already bail if > gimple_nop_p. > > So T must be one of: > > > /* Parameters get their initial value from the function entry. */ > else if (TREE_CODE (var) == PARM_DECL) > return false; > /* When returning by reference the return address is actually a hidden > parameter. */ > else if (TREE_CODE (var) == RESULT_DECL && DECL_BY_REFERENCE (var)) > return false; This return statement is taken. > /* Hard register variables get their initial value from the ether. */ > else if (VAR_P (var) && DECL_HARD_REGISTER (var)) > return false; > > which I wonder if we should special case in is_maybe_undefined. Do we need a special case in the function? M. > > Aldy
Re: [PATCH] Enable RDPID instruction.
On Wed, Feb 15, 2017 at 3:09 PM, Koval, Julia wrote: > Hi, > > This patch enables RDPID intrinsic, described in SDM 4-534 Vol. 2B > https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf > and intrinsic guide: > https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=rdpi&expand=2778,2777,4219 > > gcc/ > * common/config/i386/i386-common.c (OPTION_MASK_ISA_RDPID_SET): New. > (OPTION_MASK_ISA_PKU_UNSET): New. > (ix86_handle_option): Handle -mrdpid. > * config/i386/cpuid.h > (bit_RDPID): New. > * config/i386/driver-i386.c (host_detect_local_cpu): Detect RDPID > feature. > * config/i386/i386-builtin.def (__builtin_ia32_rdpid): New. > * config/i386/i386-c.c (ix86_target_macros_internal): Handle RDPID > flag. > * config/i386/i386.c (ix86_target_string): Add -mrdpid to isa2_opts. > (ix86_valid_target_attribute_inner_p): Add "rdpid". > (ix86_expand_builtin): Handle IX86_BUILTIN_RDPID. > * config/i386/i386.h (TARGET_RDPID, TARGET_RDPID_P): New. > * config/i386/i386.md (define_insn "rdpid"): New. > * config/i386/i386.opt Add -mrdpid. > * config/i386/immintrin.h (_rdpid_u32): New. > * testsuite/gcc.target/i386/rdpid.c New test. > > Ok for trunk? This patch is missing testsuite changes. Additions to intrinsic headers need to update relevant tests, please see [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00764.html Uros.
Re: [GIMPLE FE] avoid ICE with same ssa version number for multiple names
On Wed, 15 Feb 2017, Prathamesh Kulkarni wrote:
> Hi,
> For the following (invalid) test-case:
>
> void __GIMPLE () foo (int a)
> {
> int t0;
> int _1;
> _1 = a;
> t0_1 = a;
> }
>
> results in following ICE:
> gimplefe-error-4.c: In function ‘foo’:
> gimplefe-error-4.c:20:1: error: SSA_NAME_DEF_STMT is wrong
> }
> ^
> Expected definition statement:
> _1 = a_2(D);
>
> Actual definition statement:
> _1 = a_2(D);
> gimplefe-error-4.c:20:1: internal compiler error: verify_ssa failed
> 0xe1458b verify_ssa(bool, bool)
> ../../gcc/gcc/tree-ssa.c:1184
> 0xb0d1ed execute_function_todo
> ../../gcc/gcc/passes.c:1973
> 0xb0dad5 execute_todo
> ../../gcc/gcc/passes.c:2016
>
> The reason for ICE is that in c_parser_parse_ssa_name, ssa_name (1)
> returns tree node for _1, and "t0_1" gets replaced by "_1"
> resulting in multiple definitions for _1.
>
> The attached patch checks if multiple ssa names have same version
> number and emits a diagnostic in that case, for the above case:
> gimplefe-error-4.c: In function ‘foo’:
> gimplefe-error-4.c:10:3: error: ssa version ‘1’ used anonymously and in ‘t0’
>t0_1 = a;
>^~~~
>
> OK to commit after bootstrap+test ?
Hmm, I'd rather (if at all -- I consider these kind of verification errors
appropriate for valid GIMPLE FE input) do sth like
Index: gcc/c/gimple-parser.c
===
--- gcc/c/gimple-parser.c (revision 245501)
+++ gcc/c/gimple-parser.c (working copy)
@@ -315,6 +315,12 @@ c_parser_gimple_statement (c_parser *par
else if (! FLOAT_TYPE_P (TREE_TYPE (lhs.value))
&& FLOAT_TYPE_P (TREE_TYPE (rhs.value)))
code = FIX_TRUNC_EXPR;
+ if (TREE_CODE (lhs.value) == SSA_NAME
+ && SSA_NAME_DEF_STMT (lhs.value))
+ {
+ c_parser_error (parser, "duplicate definition of SSA name");
+ /* point at previous definition, do not emit stmt */
+ }
assign = gimple_build_assign (lhs.value, code, rhs.value);
gimple_seq_add_stmt (seq, assign);
gimple_set_location (assign, loc);
@@ -347,6 +353,13 @@ c_parser_gimple_statement (c_parser *par
rhs = c_parser_gimple_unary_expression (parser);
if (rhs.value != error_mark_node)
{
+ if (TREE_CODE (lhs.value) == SSA_NAME
+ && SSA_NAME_DEF_STMT (lhs.value))
+ {
+ c_parser_error (parser, "duplicate definition of SSA name");
+ /* point at previous definition, do not emit stmt */
+ }
+
assign = gimple_build_assign (lhs.value, rhs.value);
gimple_set_location (assign, loc);
gimple_seq_add_stmt (seq, assign);
@@ -420,6 +433,13 @@ c_parser_gimple_statement (c_parser *par
if (lhs.value != error_mark_node
&& rhs.value != error_mark_node)
{
+ if (TREE_CODE (lhs.value) == SSA_NAME
+ && SSA_NAME_DEF_STMT (lhs.value))
+ {
+ c_parser_error (parser, "duplicate definition of SSA name");
+ /* point at previous definition, do not emit stmt */
+ }
+
assign = gimple_build_assign (lhs.value, rhs.value);
gimple_seq_add_stmt (seq, assign);
gimple_set_location (assign, loc);
@@ -692,8 +712,7 @@ c_parser_parse_ssa_name (c_parser *parse
if (VECTOR_TYPE_P (TREE_TYPE (parent))
|| TREE_CODE (TREE_TYPE (parent)) == COMPLEX_TYPE)
DECL_GIMPLE_REG_P (parent) = 1;
- name = make_ssa_name_fn (cfun, parent,
- gimple_build_nop (), version);
+ name = make_ssa_name_fn (cfun, parent, NULL, version);
}
}
basically at the point we emit a SSA def diagnose existing ones.
Should be split out into a verify_def () function, and the diagnostic
should be more helpful of course.
Richard.
>
> Thanks,
> Prathamesh
>
--
Richard Biener
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
Re: [PATCH][GCC6] Backport PR target/76731 fix
On Wed, Feb 15, 2017 at 1:03 PM, Koval, Julia wrote: > Hi, > Is it ok to backport this fix to GCC6 branch? > > PR target/76731 > * config/i386/avx512fintrin.h > (_mm512_i32gather_ps): Change __addr type to void const*. > (_mm512_mask_i32gather_ps): Ditto. > (_mm512_i32gather_pd): Ditto. > (_mm512_mask_i32gather_pd): Ditto. > (_mm512_i64gather_ps): Ditto. > (_mm512_mask_i64gather_ps): Ditto. > (_mm512_i64gather_pd): Ditto. > (_mm512_mask_i64gather_pd): Ditto. > (_mm512_i32gather_epi32): Ditto. > (_mm512_mask_i32gather_epi32): Ditto. > (_mm512_i32gather_epi64): Ditto. > (_mm512_mask_i32gather_epi64): Ditto. > (_mm512_i64gather_epi32): Ditto. > (_mm512_mask_i64gather_epi32): Ditto. > (_mm512_i64gather_epi64): Ditto. > (_mm512_mask_i64gather_epi64): Ditto. > (_mm512_i32scatter_ps): Change __addr type to void*. > (_mm512_mask_i32scatter_ps): Ditto. > (_mm512_i32scatter_pd): Ditto. > (_mm512_mask_i32scatter_pd): Ditto. > (_mm512_i64scatter_ps): Ditto. > (_mm512_mask_i64scatter_ps): Ditto. > (_mm512_i64scatter_pd): Ditto. > (_mm512_mask_i64scatter_pd): Ditto. > (_mm512_i32scatter_epi32): Ditto. > (_mm512_mask_i32scatter_epi32): Ditto. > (_mm512_i32scatter_epi64): Ditto. > (_mm512_mask_i32scatter_epi64): Ditto. > (_mm512_i64scatter_epi32): Ditto. > (_mm512_mask_i64scatter_epi32): Ditto. > (_mm512_i64scatter_epi64): Ditto. > (_mm512_mask_i64scatter_epi64): Ditto. > * config/i386/avx512pfintrin.h > (_mm512_mask_prefetch_i32gather_pd): Change addr type to void const*. > (_mm512_mask_prefetch_i32gather_ps): Ditto. > (_mm512_mask_prefetch_i64gather_pd): Ditto. > (_mm512_mask_prefetch_i64gather_ps): Ditto. > (_mm512_prefetch_i32scatter_pd): Change addr type to void*. > (_mm512_prefetch_i32scatter_ps): Ditto. > (_mm512_mask_prefetch_i32scatter_pd): Ditto. > (_mm512_mask_prefetch_i32scatter_ps): Ditto. > (_mm512_prefetch_i64scatter_pd): Ditto. > (_mm512_prefetch_i64scatter_ps): Ditto. > (_mm512_mask_prefetch_i64scatter_pd): Ditto. > (_mm512_mask_prefetch_i64scatter_ps): Ditto. > * config/i386/avx512vlintrin.h > (_mm256_mmask_i32gather_ps): Change __addr type to void const*. > (_mm_mmask_i32gather_ps): Ditto. > (_mm256_mmask_i32gather_pd): Ditto. > (_mm_mmask_i32gather_pd): Ditto. > (_mm256_mmask_i64gather_ps): Ditto. > (_mm_mmask_i64gather_ps): Ditto. > (_mm256_mmask_i64gather_pd): Ditto. > (_mm_mmask_i64gather_pd): Ditto. > (_mm256_mmask_i32gather_epi32): Ditto. > (_mm_mmask_i32gather_epi32): Ditto. > (_mm256_mmask_i32gather_epi64): Ditto. > (_mm_mmask_i32gather_epi64): Ditto. > (_mm256_mmask_i64gather_epi32): Ditto. > (_mm_mmask_i64gather_epi32): Ditto. > (_mm256_mmask_i64gather_epi64): Ditto. > (_mm_mmask_i64gather_epi64): Ditto. > (_mm256_i32scatter_ps): Change __addr type to void*. > (_mm256_mask_i32scatter_ps): Ditto. > (_mm_i32scatter_ps): Ditto. > (_mm_mask_i32scatter_ps): Ditto. > (_mm256_i32scatter_pd): Ditto. > (_mm256_mask_i32scatter_pd): Ditto. > (_mm_i32scatter_pd): Ditto. > (_mm_mask_i32scatter_pd): Ditto. > (_mm256_i64scatter_ps): Ditto. > (_mm256_mask_i64scatter_ps): Ditto. > (_mm_i64scatter_ps): Ditto. > (_mm_mask_i64scatter_ps): Ditto. > (_mm256_i64scatter_pd): Ditto. > (_mm256_mask_i64scatter_pd): Ditto. > (_mm_i64scatter_pd): Ditto. > (_mm_mask_i64scatter_pd): Ditto. > (_mm256_i32scatter_epi32): Ditto. > (_mm256_mask_i32scatter_epi32): Ditto. > (_mm_i32scatter_epi32): Ditto. > (_mm_mask_i32scatter_epi32): Ditto. > (_mm256_i32scatter_epi64): Ditto. > (_mm256_mask_i32scatter_epi64): Ditto. > (_mm_i32scatter_epi64): Ditto. > (_mm_mask_i32scatter_epi64): Ditto. > (_mm256_i64scatter_epi32): Ditto. > (_mm256_mask_i64scatter_epi32): Ditto. > (_mm_i64scatter_epi32): Ditto. > (_mm_mask_i64scatter_epi32): Ditto. > (_mm256_i64scatter_epi64): Ditto. > (_mm256_mask_i64scatter_epi64): Ditto. > (_mm_i64scatter_epi64): Ditto. > (_mm_mask_i64scatter_epi64): Ditto. > * config/i386/i386-builtin-types.def > (V16SF_V16SF_PCFLOAT_V16SI_HI_INT) > (V8DF_V8DF_PCDOUBLE_V8SI_QI_INT, V8SF_V8SF_PCFLOAT_V8DI_QI_INT) > (V8DF_V8DF_PCDOUBLE_V8DI_QI_INT, V16SI_V16SI_PCINT_V16SI_HI_INT) > (V8DI_V8DI_PCINT64_V8SI_QI_INT, V8SI_V8SI_PCINT_V8DI_QI_INT) > (V8DI_V8DI_PCINT64_V8DI_QI_INT, V2DF_V2DF_PCDOUBLE_V4SI_QI_INT) > (V4DF_V4DF_PCDOUBL
