[PATCH] Fix ICE with COMPLEX_EXPR in fold_negate_expr (PR middle-end/79536)

[Marek Polacek]

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 

[doc, committed] Re: Doc question: is "templatized" a word?

[Sandra Loosemore]

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 

Re: [PATCH PR71437/V2]Simplify cond with assertions in threading

[Jeff Law]

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

[Koval, Julia]

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, 

Re: [PATCH PR77536]Generate correct profiling information for vectorized loop

[Pat Haugen]

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

[Jeff Law]

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

[Jeff Law]

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)

[Joseph Myers]

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)

[Jeff Law]

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)

[Jeff Law]

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)

[Martin Sebor]

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

[Jeff Law]

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

[Jeff Law]

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.

[Koval, Julia]

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=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.

[Koval, Julia]

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=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

[Andreas Tobler]

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=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

[Jakub Jelinek]

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

[Andreas Tobler]

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)

[Bill Schmidt]

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: 

Re: [C++ RFC] Fix up attribute handling in templates (PR c++/79502)

[Jason Merrill]

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 = _ATTRIBUTES (*decl_p);
+  /* DECL_ATTRIBUTES comes from copy_node in tsubst_decl, and identical
+ to our attributes parameter.  */
+  gcc_assert (*p == attributes);
 }
   else
-p = _ATTRIBUTES (*decl_p);
+{
+  p = _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 = _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 = _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

[Vladimir Makarov]

  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]

[Gerald Pfeifer]

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

[Bernd Schmidt]

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*

[Andreas Tobler]

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
+.  */
+
+/* Identify a signal frame, and set the frame state data appropriately.
+   See unwind-dw2.c for the structs. */
+
+/* Always include AArch64 unwinder header file.  */
+#include "config/aarch64/aarch64-unwind.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_NAME(reg)   mc_gpregs.gp_## reg
+#define XREG(num)   mc_gpregs.gp_x[num]
+#define DARC__LIBGCC_DWARF_ALT_FRAME_RETURN_COLUMN__
+
+#define MD_FALLBACK_FRAME_STATE_FOR aarch64_freebsd_fallback_frame_state
+
+static int
+aarch64_outside_sigtramp_range (unsigned char *pc)
+{
+  static int sigtramp_range_determined = 0;
+  static unsigned char *sigtramp_start, *sigtramp_end;
+
+  if (sigtramp_range_determined == 0)
+{
+  struct kinfo_sigtramp kst = {0};
+  size_t len = sizeof (kst);
+  int mib[4] = { CTL_KERN, KERN_PROC, KERN_PROC_SIGTRAMP, getpid() };
+
+  sigtramp_range_determined = 1;
+  if (sysctl (mib, 4, , , NULL, 0) == 0)
+  {
+sigtramp_range_determined = 2;
+sigtramp_start = kst.ksigtramp_start;
+sigtramp_end   = kst.ksigtramp_end;
+  }
+}
+  if (sigtramp_range_determined < 2)  /* sysctl failed if < 2 */
+return 1;
+
+  return (pc < sigtramp_start || pc >= sigtramp_end);
+}
+
+static _Unwind_Reason_Code
+aarch64_freebsd_fallback_frame_state
+(struct _Unwind_Context *context, _Unwind_FrameState *fs)
+{
+  int n;
+  struct sigframe *sf;
+  mcontext_t *sc;
+  _Unwind_Ptr new_cfa;
+
+  if (aarch64_outside_sigtramp_range(context->ra))
+return _URC_END_OF_STACK;
+
+  sf = (struct sigframe *) context->cfa;
+  sc = >sf_uc.uc_mcontext;
+
+  new_cfa = (_Unwind_Ptr) sc;
+  fs->regs.cfa_how = CFA_REG_OFFSET;
+  fs->regs.cfa_reg = __LIBGCC_STACK_POINTER_REGNUM__;
+  fs->regs.cfa_offset = new_cfa - (_Unwind_Ptr) context->cfa;
+
+  for (n = 0; n < 32; n++)
+fs->regs.reg[n].how = REG_SAVED_OFFSET;
+
+  for (n = 0; n < 30; n++)
+fs->regs.reg[n].loc.offset = (_Unwind_Ptr) &(sc->XREG(n)) - new_cfa;
+
+  fs->regs.reg[30].loc.offset = (_Unwind_Ptr) &(sc->REG_NAME(lr)) - new_cfa;
+  fs->regs.reg[31].loc.offset = (_Unwind_Ptr) &(sc->REG_NAME(sp)) - new_cfa;
+
+  fs->regs.reg[DARC].how = REG_SAVED_OFFSET;
+  fs->regs.reg[DARC].loc.offset = (_Unwind_Ptr) &(sc->REG_NAME(elr)) - new_cfa;
+
+  fs->retaddr_column = DARC;
+  fs->signal_frame = 1;
+
+  return _URC_NO_REASON;
+}

Re: [PATCH, rs6000] gcc 5 back port of xvcvsxdsp and xvcvuxdsp RTL fixes

[Segher Boessenkool]

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

[Carl E. Love]

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

[Paul Richard Thomas]

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

[Jerry DeLisle]

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

[Bin Cheng]

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,
 _main_cond, _base, _step,
 _cmp, _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 

Re: [PATCH, wwwdocs/ARM] Deprecate ARMv5 and ARMv5E support

[Thomas Preudhomme]

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

[Segher Boessenkool]

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

[Jozef Lawrynowicz]

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)

[Jason Merrill]

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 = _exprs;
+ ctx_with_save_exprs.call = _call;
 
  tree jump_target = NULL_TREE;
  cxx_eval_constant_expression (_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)

[Jason Merrill]

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 = _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 = _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)

[Jakub Jelinek]

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 = _ATTRIBUTES (*decl_p);
+  *p = NULL_TREE;
 }
   else
 p = _ATTRIBUTES (*decl_p);
@@ -10094,6 +10095,7 @@ apply_late_template_attributes (tree *de
 {
   tree late_attrs = NULL_TREE;
   tree *q = _attrs;
+  tree prev = *p;
 
   for (*p = attributes; *p; )
{
@@ -10110,9 +10112,14 @@ apply_late_template_attributes (tree *de
  else
p = _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 @@
+// { 

Re: [PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745)

[Jakub Jelinek]

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)

[Alexander Monakov]

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)

[Jakub Jelinek]

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 = _attrs;
+  tree prev = *p;
 
   for (*p = attributes; *p; )
{
@@ -10110,9 +10111,14 @@ apply_late_template_attributes (tree *de
  else
p = _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

[Jan Hubicka]

> 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

[Richard Biener]

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

[Prathamesh Kulkarni]

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, );
+ 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

[Richard Biener]

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

[Jonathan Wakely]

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

[Jonathan Wakely]

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)

[Jakub Jelinek]

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

[Richard Biener]

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)

[Jakub Jelinek]

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

[Richard Biener]

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).

[Richard Biener]

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

[Paul Richard Thomas]

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", 
>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", 
>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, );
+ 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, ))
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++;
+ 
 

Re: [PATCH] Fix exgettext to handle multi-line help texts from *.opt files (PR translation/78745)

[Alexander Monakov]

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

[Uros Bizjak]

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).

[Aldy Hernandez]

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.

[Rainer Orth]

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)

[Thomas Schwinge]

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

[Koval, Julia]

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.

Re: [GIMPLE FE] avoid ICE with same ssa version number for multiple names

[Prathamesh Kulkarni]

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 

Re: Handle GIMPLE NOPs in is_maybe_undefined (PR, tree-optimization/79529).

[Martin Liška]

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.

[Uros Bizjak]

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=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

[Richard Biener]

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

[Uros Bizjak]

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)
>