Re: [C++ Patch] PR 71464 ("[6/7/8 Regression] ICE on invalid code (with redeclared constructor) at -Os: Segmentation fault")

[Jason Merrill]

On Fri, Mar 2, 2018 at 4:02 PM, Paolo Carlini  wrote:
> this error recovery ICE happens only with -Os and is just a P5 - on the
> other hand I would argue the reproducer isn't that exotic! - but seems
> fixable easily and safely: cdtor_comdat_group immediately calls
> DECL_ASSEMBLER_NAME on both arguments and of course crashes if they are
> null. Tested x86_64-linux.

It would make more sense to me to do this check and return right after
populate_clone_array.

Jason

Simplification and a zero sized array

[Steve Kargl]

All,

I would like to commit the attach patch, which fixes
a number of ICE's when simplification runs into a
size zero array.  gfortran does not have a nice
easy way to determine if an array is size zero.  Thus,
the new function is_size_zero_array was written after
staring at several gdb sessions.

This patch does not fix all of the problems with 
size zero arrays:

1) findloc isn't implemented, so obviously it's not fixed.
2) I skipped looking at minloc and maxloc.  These will take
   more effort.
3) I skipped looking at associated.  There are special
   conditions with size zero arrays mentioned, but I
   haven't tried to cause an ICE, yet.
4) The pad dummy argument to the spread has special condition
   when she is size zero.  I haven't tried to cause an
   ICE, yet.

5) minval and maxval can take a size zero array of strings.
   The requirements will call for someone with widechar
   gfortran hacking experience to fix.  At the moment, 
   gfortran will issue an error and die.  So, anyone game
   in handling the widechar stuff?

6) I haven't looked at any of the old g77 compatibility 
   functions.  These may (or may not!) have issues.

Regression tested on x86_64-*-freebsd.  OK to commit?


2018-03-02  Steven G. Kargl  

PR fortran/66128
* simplify.c (is_size_zero_array): New function to check for size
zero array.
(gfc_simplify_all, gfc_simplify_any, gfc_simplify_count, 
 gfc_simplify_iall, gfc_simplify_iany, gfc_simplify_iparity,
 gfc_simplify_minval, gfc_simplify_maxval, gfc_simplify_norm2,
 gfc_simplify_product, gfc_simplify_sum): Use it, and implement
requirements from F2018.

2018-03-02  Steven G. Kargl  

PR fortran/66128

* gfortran.dg/zero_sized_8.f90: New test.



-- 
Steve
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c	(revision 258116)
+++ gcc/fortran/simplify.c	(working copy)
@@ -257,7 +257,30 @@ is_constant_array_expr (gfc_expr *e)
   return true;
 }
 
+/* Test for a size zero array.  */
+static bool
+is_size_zero_array (gfc_expr *array)
+{
+  gfc_expr *e;
+  bool t;
 
+  e = gfc_copy_expr (array);
+  gfc_simplify_expr (e, 1);
+
+  if (e->expr_type == EXPR_CONSTANT && e->rank > 0 && !e->shape)
+ t = true;
+  else if (e->expr_type == EXPR_ARRAY && e->rank > 0 
+	   && !e->shape && !e->value.constructor)
+ t = true;
+  else
+ t = false;
+
+  gfc_free_expr (e);
+
+  return t;
+}
+
+
 /* Initialize a transformational result expression with a given value.  */
 
 static void
@@ -950,6 +973,9 @@ gfc_simplify_aint (gfc_expr *e, gfc_expr *k)
 gfc_expr *
 gfc_simplify_all (gfc_expr *mask, gfc_expr *dim)
 {
+  if (is_size_zero_array (mask))
+return gfc_get_logical_expr (mask->ts.kind, >where, true);
+
   return simplify_transformation (mask, dim, NULL, true, gfc_and);
 }
 
@@ -1039,6 +1065,9 @@ gfc_simplify_and (gfc_expr *x, gfc_expr *y)
 gfc_expr *
 gfc_simplify_any (gfc_expr *mask, gfc_expr *dim)
 {
+  if (is_size_zero_array (mask))
+return gfc_get_logical_expr (mask->ts.kind, >where, false);
+
   return simplify_transformation (mask, dim, NULL, false, gfc_or);
 }
 
@@ -1935,6 +1964,13 @@ gfc_simplify_count (gfc_expr *mask, gfc_expr *dim, gfc
 {
   gfc_expr *result;
 
+  if (is_size_zero_array (mask))
+{
+  int k;
+  k = kind ? mpz_get_si (kind->value.integer) : gfc_default_integer_kind;
+  return gfc_get_int_expr (k, NULL, 0);
+}
+
   if (!is_constant_array_expr (mask)
   || !gfc_is_constant_expr (dim)
   || !gfc_is_constant_expr (kind))
@@ -3226,6 +3262,9 @@ do_bit_and (gfc_expr *result, gfc_expr *e)
 gfc_expr *
 gfc_simplify_iall (gfc_expr *array, gfc_expr *dim, gfc_expr *mask)
 {
+  if (is_size_zero_array (array))
+return gfc_get_int_expr (array->ts.kind, NULL, -1);
+
   return simplify_transformation (array, dim, mask, -1, do_bit_and);
 }
 
@@ -3245,6 +3284,9 @@ do_bit_ior (gfc_expr *result, gfc_expr *e)
 gfc_expr *
 gfc_simplify_iany (gfc_expr *array, gfc_expr *dim, gfc_expr *mask)
 {
+  if (is_size_zero_array (array))
+return gfc_get_int_expr (array->ts.kind, NULL, 0);
+
   return simplify_transformation (array, dim, mask, 0, do_bit_ior);
 }
 
@@ -3685,6 +3727,9 @@ do_bit_xor (gfc_expr *result, gfc_expr *e)
 gfc_expr *
 gfc_simplify_iparity (gfc_expr *array, gfc_expr *dim, gfc_expr *mask)
 {
+  if (is_size_zero_array (array))
+return gfc_get_int_expr (array->ts.kind, NULL, 0);
+
   return simplify_transformation (array, dim, mask, 0, do_bit_xor);
 }
 
@@ -4992,6 +5037,43 @@ gfc_min (gfc_expr *op1, gfc_expr *op2)
 gfc_expr *
 gfc_simplify_minval (gfc_expr *array, gfc_expr* dim, gfc_expr *mask)
 {
+  if (is_size_zero_array (array))
+{
+  gfc_expr *result;
+  int i;
+
+  i = gfc_validate_kind (array->ts.type, array->ts.kind, false);
+  result = gfc_get_constant_expr (array->ts.type, array->ts.kind,
+  >where);
+

Re: [PATCH] RISC-V: Add and document the "-mno-relax" option

[Jim Wilson]

On 03/01/2018 01:26 PM, Palmer Dabbelt wrote:

+@item -mrelax
+@itemx -mno-relax
+Take advantage of linker relaxations to reduce the number of instructions
+required to materalize symbol addresses.


materalize->materialize

This is not just number of instructions, it is also code size, since 
linker relaxation can convert non-compressed instructions into 
compressed instructions.


Also, this isn't clear which option is the default.  If you look at the 
other options descriptions, I tried to make it clear which was the 
default when there was more than one choice.  I don't think you should 
rely on @item or @itemx to define which is the default.


Jim

[committed][PATCH] Handle DEBUG_INSNs in reorg.c/resource.c

[Jeff Law]

The kernel builds with -fno-var-tracking-assignments.  For MIPS (and
likely other delay slot targets) this results in DEBUG_INSNs appearing
in the IL and neither reorg.c nor resource.c is prepared for that.

I don't doubt there's more of these problems lurking, but this patch is
enough to get the MIPS ports bootstrapping with
-fno-var-tracking-assignments and linux kernels to build.

Committing to the trunk.

Jeff
* reorg.c (stop_search_p): Handle DEBUG_INSN.
(redundant_insn, fill_simple_delay_slots): Likewise.
(fill_slots_from_thread): Likewise.
* resource.c (mark_referenced_resources): Likewise.
(mark_set_resources, find_dead_or_set_registers): Likewise.

diff --git a/gcc/reorg.c b/gcc/reorg.c
index ecdc3752af3..904d91ec9e8 100644
--- a/gcc/reorg.c
+++ b/gcc/reorg.c
@@ -276,6 +276,7 @@ stop_search_p (rtx_insn *insn, int labels_p)
 {
 case NOTE:
 case CALL_INSN:
+case DEBUG_INSN:
   return 0;
 
 case CODE_LABEL:
@@ -1493,6 +1494,9 @@ redundant_insn (rtx insn, rtx_insn *target, const 
vec _list)
   if (GET_CODE (pat) == USE || GET_CODE (pat) == CLOBBER)
continue;
 
+  if (GET_CODE (trial) == DEBUG_INSN)
+   continue;
+
   if (rtx_sequence *seq = dyn_cast  (pat))
{
  /* Stop for a CALL and its delay slots because it is difficult to
@@ -1588,6 +1592,9 @@ redundant_insn (rtx insn, rtx_insn *target, const 
vec _list)
   if (GET_CODE (pat) == USE || GET_CODE (pat) == CLOBBER)
continue;
 
+  if (GET_CODE (trial) == DEBUG_INSN)
+   continue;
+
   if (rtx_sequence *seq = dyn_cast  (pat))
{
  bool annul_p = false;
@@ -2020,6 +2027,10 @@ fill_simple_delay_slots (int non_jumps_p)
  if (GET_CODE (pat) == USE || GET_CODE (pat) == CLOBBER)
continue;
 
+ /* And DEBUG_INSNs never go into delay slots.  */
+ if (GET_CODE (trial) == DEBUG_INSN)
+   continue;
+
  /* Check for resource conflict first, to avoid unnecessary
 splitting.  */
  if (! insn_references_resource_p (trial, , true)
@@ -2142,6 +2153,10 @@ fill_simple_delay_slots (int non_jumps_p)
  if (GET_CODE (pat) == USE || GET_CODE (pat) == CLOBBER)
continue;
 
+ /* And DEBUG_INSNs do not go in delay slots.  */
+ if (GET_CODE (trial) == DEBUG_INSN)
+   continue;
+
  /* If this already has filled delay slots, get the insn needing
 the delay slots.  */
  if (GET_CODE (pat) == SEQUENCE)
@@ -2211,8 +2226,8 @@ fill_simple_delay_slots (int non_jumps_p)
  && ! can_throw_internal (trial))
{
  /* See comment in relax_delay_slots about necessity of using
-next_real_insn here.  */
- rtx_insn *new_label = next_real_insn (next_trial);
+next_real_nondebug_insn here.  */
+ rtx_insn *new_label = next_real_nondebug_insn (next_trial);
 
  if (new_label != 0)
new_label = get_label_before (new_label, JUMP_LABEL (trial));
@@ -2406,6 +2421,9 @@ fill_slots_from_thread (rtx_jump_insn *insn, rtx 
condition,
   if (GET_CODE (pat) == USE || GET_CODE (pat) == CLOBBER)
continue;
 
+  if (GET_CODE (trial) == DEBUG_INSN)
+   continue;
+
   /* If TRIAL conflicts with the insns ahead of it, we lose.  Also,
 don't separate or copy insns that set and use CC0.  */
   if (! insn_references_resource_p (trial, , true)
@@ -3309,10 +3327,10 @@ relax_delay_slots (rtx_insn *first)
 
   /* If the first insn at TARGET_LABEL is redundant with a previous
 insn, redirect the jump to the following insn and process again.
-We use next_real_insn instead of next_active_insn so we
+We use next_real_nondebug_insn instead of next_active_insn so we
 don't skip USE-markers, or we'll end up with incorrect
 liveness info.  */
-  trial = next_real_insn (target_label);
+  trial = next_real_nondebug_insn (target_label);
   if (trial && GET_CODE (PATTERN (trial)) != SEQUENCE
  && redundant_insn (trial, insn, vNULL)
  && ! can_throw_internal (trial))
@@ -3327,7 +3345,7 @@ relax_delay_slots (rtx_insn *first)
{
  /* Insert the special USE insn and update dataflow info.
 We know "trial" is an insn here as it is the output of
-next_real_insn () above.  */
+next_real_nondebug_insn () above.  */
  update_block (as_a  (trial), tmp);
  
  /* Now emit a label before the special USE insn, and
diff --git a/gcc/resource.c b/gcc/resource.c
index ff194bb0be0..0822daebde7 100644
--- a/gcc/resource.c
+++ b/gcc/resource.c
@@ -212,6 +212,7 @@ mark_referenced_resources (rtx x, struct resources *res,
 case PC:
 case SYMBOL_REF:
 case LABEL_REF:
+case 

New Spanish PO file for 'gcc' (version 8.1-b20180128)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators.  The file is available at:

http://translationproject.org/latest/gcc/es.po

(This file, 'gcc-8.1-b20180128.es.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [RFA][PATCH][PR middle-end/61118] Improve tree CFG accuracy for setjmp/longjmp

[Jeff Law]

On 03/02/2018 04:07 PM, Jakub Jelinek wrote:
> On Fri, Mar 02, 2018 at 03:18:05PM -0700, Jeff Law wrote:
>> On 02/28/2018 03:43 AM, Richard Biener wrote:
>> [ More snipping ]
>>
>>>
 It's actually pretty easy to fix the CFG.  We  just need to recognize
 that a "returns twice" function returns not to the call, but to the
 point immediately after the call.  So if we have a call to a returns
 twice function that ends a block with a single successor, when we wire
 up the abnormal dispatcher, we target the single successor rather than
 the block containing the returns-twice call.
>>>
>>> Hmm, I think you need to check whether the successor has a single
>>> predecessor, not whether we have a single successor (we always have
>>> that unless setjmp also throws).  If you fix that you keep the CFG
>>> "incorrect" if there are multiple predecessors so I think in addition
>>> to properly creating the edges you have to work on the BB building
>>> part to ensure that there's a single-predecessor block after
>>> returns-twice function calls.  Note that currently we force returns-twice
>>> to be the first (and only) stmt of a block -- your fix would relax this,
>>> returns-twice no longer needs to start a new BB.
>> So I found the code which makes the setjmp start a new block. But I
>> haven't found the code which makes setjmp end a block.  I'm going to
>> have to throw things into the debugger  to find the latter.
>>
>>
>> We ought to remove the code that makes the setjmp start a new block.
>> That's just unnecessary.   setjmp certainly needs to end the block though.
> 
> At least in gimple, having setjmp start the block is intentional;
> we have abnormal edges from all the (possible) spots which might have
> longjmp to abnormal dispatcher artificial bb and from that block abnormal
> edges to all the sigjmp starts, which is how we emulate the fact that
> longjmp might return in a setjmp location.  Edges are created by
> handle_abnormal_edges.
But the longjmp should not return to the setjmp call, it should return
to the point immediately after the setjmp call.  That's the core of the
issue with 61118.

jeff

Re: [RFA][PATCH][PR middle-end/61118] Improve tree CFG accuracy for setjmp/longjmp

[Jakub Jelinek]

On Fri, Mar 02, 2018 at 03:18:05PM -0700, Jeff Law wrote:
> On 02/28/2018 03:43 AM, Richard Biener wrote:
> [ More snipping ]
> 
> > 
> >> It's actually pretty easy to fix the CFG.  We  just need to recognize
> >> that a "returns twice" function returns not to the call, but to the
> >> point immediately after the call.  So if we have a call to a returns
> >> twice function that ends a block with a single successor, when we wire
> >> up the abnormal dispatcher, we target the single successor rather than
> >> the block containing the returns-twice call.
> > 
> > Hmm, I think you need to check whether the successor has a single
> > predecessor, not whether we have a single successor (we always have
> > that unless setjmp also throws).  If you fix that you keep the CFG
> > "incorrect" if there are multiple predecessors so I think in addition
> > to properly creating the edges you have to work on the BB building
> > part to ensure that there's a single-predecessor block after
> > returns-twice function calls.  Note that currently we force returns-twice
> > to be the first (and only) stmt of a block -- your fix would relax this,
> > returns-twice no longer needs to start a new BB.
> So I found the code which makes the setjmp start a new block. But I
> haven't found the code which makes setjmp end a block.  I'm going to
> have to throw things into the debugger  to find the latter.
> 
> 
> We ought to remove the code that makes the setjmp start a new block.
> That's just unnecessary.   setjmp certainly needs to end the block though.

At least in gimple, having setjmp start the block is intentional;
we have abnormal edges from all the (possible) spots which might have
longjmp to abnormal dispatcher artificial bb and from that block abnormal
edges to all the sigjmp starts, which is how we emulate the fact that
longjmp might return in a setjmp location.  Edges are created by
handle_abnormal_edges.

Jakub

Re: [RFA][PATCH][PR middle-end/61118] Improve tree CFG accuracy for setjmp/longjmp

[Jeff Law]

On 02/28/2018 03:43 AM, Richard Biener wrote:
[ More snipping ]

> 
>> It's actually pretty easy to fix the CFG.  We  just need to recognize
>> that a "returns twice" function returns not to the call, but to the
>> point immediately after the call.  So if we have a call to a returns
>> twice function that ends a block with a single successor, when we wire
>> up the abnormal dispatcher, we target the single successor rather than
>> the block containing the returns-twice call.
> 
> Hmm, I think you need to check whether the successor has a single
> predecessor, not whether we have a single successor (we always have
> that unless setjmp also throws).  If you fix that you keep the CFG
> "incorrect" if there are multiple predecessors so I think in addition
> to properly creating the edges you have to work on the BB building
> part to ensure that there's a single-predecessor block after
> returns-twice function calls.  Note that currently we force returns-twice
> to be the first (and only) stmt of a block -- your fix would relax this,
> returns-twice no longer needs to start a new BB.
So I found the code which makes the setjmp start a new block. But I
haven't found the code which makes setjmp end a block.  I'm going to
have to throw things into the debugger  to find the latter.


We ought to remove the code that makes the setjmp start a new block.
That's just unnecessary.   setjmp certainly needs to end the block though.




> 
> -   handle_abnormal_edges (dispatcher_bbs, bb, bb_to_omp_idx,
> -  _edge_call, false);
> +   {
> + bool target_after_setjmp = false;
> +
> + /* If the returns twice statement looks like a setjmp
> +call at the end of a block with a single successor
> +then we want the edge from the dispatcher to target
> +that single successor.  That more accurately reflects
> +actual control flow.  The more accurate CFG also
> +results in fewer false positive warnings.  */
> + if (gsi_stmt (gsi_last_nondebug_bb (bb)) == call_stmt
> + && gimple_call_fndecl (call_stmt)
> + && setjmp_call_p (gimple_call_fndecl (call_stmt))
> + && single_succ_p (bb))
> +   target_after_setjmp = true;
> + handle_abnormal_edges (dispatcher_bbs, bb, bb_to_omp_idx,
> +_edge_call, false,
> +target_after_setjmp);
> +   }
> 
> I don't exactly get the hops you jump through here -- I think it's
> better to split the returns-twice (always last stmt of a block after
> the fixing) and the setjmp-receiver (always first stmt of a block) cases.
> So, remove the handling of returns-twice from the above case and
> handle returns-twice via
Just wanted to verify the setjmp was the last statement in the block and
the block passed control to a single successor.  If the setjmp is not
the last statement, then having the longjmp pass control to the
successor block potentially skips over statements between the setjmp and
the end of the block.  That obviously would be bad.

As I mentioned before the single_succ_p test was just my paranoia.

Note that GSI can point to a setjmp receiver at this point.  We don't
want to treat that like a setjmp.


> 
>   gimple *last = last_stmt (bb);
>   if (last && ...)
> 
> also handle all returns-twice calls this way, not only setjmp_call_p.
Note that setjmp_call_p returns true for any returns-twice function.  So
we are handling those.


So I think the open issue with this patch is removal of making the
setjmp start a block and verification that we always have it end the
block.  The latter should allow some simplifications to the code I added
in make_edges and provide a level of consistency that is desirable.

Jeff

[C++ Patch] PR 71464 ("[6/7/8 Regression] ICE on invalid code (with redeclared constructor) at -Os: Segmentation fault")

[Paolo Carlini]

Hi,

this error recovery ICE happens only with -Os and is just a P5 - on the 
other hand I would argue the reproducer isn't that exotic! - but seems 
fixable easily and safely: cdtor_comdat_group immediately calls 
DECL_ASSEMBLER_NAME on both arguments and of course crashes if they are 
null. Tested x86_64-linux.


Thanks, Paolo.

//

/cp
2018-03-02  Paolo Carlini  

PR c++/71464
* optimize.c (maybe_thunk_body): When HAVE_COMDAT_GROUP is true,
bail out immediately if either fns[1] or fns[0] is null.

/testsuite
2018-03-02  Paolo Carlini  

PR c++/71464
* g++.dg/torture/pr71464.C: New.
Index: cp/optimize.c
===
--- cp/optimize.c   (revision 258151)
+++ cp/optimize.c   (working copy)
@@ -276,6 +276,9 @@ maybe_thunk_body (tree fn, bool force)
 {
   /* At eof, defer creation of mangling aliases temporarily.  */
   bool save_defer_mangling_aliases = defer_mangling_aliases;
+  if (!fns[1] || !fns[0])
+   /* Can happen during error recovery (c++/71464).  */
+   return 0;
   defer_mangling_aliases = true;
   tree comdat_group = cdtor_comdat_group (fns[1], fns[0]);
   defer_mangling_aliases = save_defer_mangling_aliases;
Index: testsuite/g++.dg/torture/pr71464.C
===
--- testsuite/g++.dg/torture/pr71464.C  (nonexistent)
+++ testsuite/g++.dg/torture/pr71464.C  (working copy)
@@ -0,0 +1,7 @@
+struct A {}; 
+
+struct B : virtual A
+{
+  B () {};
+  B () {};  // { dg-error "cannot be overloaded" }
+};

[PATCH, fortran] PR71085 - ICE with some intrinsic functions specifying array function result dimension

[Harald Anlauf]

The fix to the PR probably counts as obvious, but here it is, along
with a testcase.  Changelogs below.

Regtested on i686-pc-linux-gnu.

Whoever reviews this, please feel free to commit.

Thanks,
Harald


2018-03-02  Harald Anlauf  

PR fortran/71085
* trans-expr.c (gfc_apply_interface_mapping_to_expr): Do not
dereference NULL pointer.


2018-03-02  Harald Anlauf  

PR fortran/71085
* gfortran.dg/pr71085.f90: New test.

Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 258112)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -4349,6 +4349,8 @@
 
   if (expr->value.function.esym == NULL
&& expr->value.function.isym != NULL
+   && expr->value.function.actual
+   && expr->value.function.actual->expr
&& expr->value.function.actual->expr->symtree
&& gfc_map_intrinsic_function (expr, mapping))
break;
Index: gcc/testsuite/gfortran.dg/pr71085.f90
===
--- gcc/testsuite/gfortran.dg/pr71085.f90   (revision 0)
+++ gcc/testsuite/gfortran.dg/pr71085.f90   (revision 0)
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! PR 71085
+!
+! Testcase from PR by Vladimir Fuka 
+!
+program pr71085
+  print *, f()
+contains
+  function f()
+integer :: f(iargc()*10)
+  end
+end

Re: [PATCH][OBVIOUS] Fix ifunc detection.

[Jakub Jelinek]

On Fri, Mar 02, 2018 at 09:55:22AM -0700, Jeff Law wrote:
> On 03/02/2018 09:38 AM, Thomas Schwinge wrote:
> > Hi!
> > 
> > On Fri, 26 Jan 2018 16:24:48 +0100, Martin Liška  wrote:
> >> This fixes detection of ifunc target capability.
> >> I'm going to install the patch.
> > 
> > You could also just have approved the patch I had sent two months before:
> > .
> > ;-)
> > 
> > One remark:
> > 
> >> --- a/gcc/testsuite/lib/target-supports.exp
> >> +++ b/gcc/testsuite/lib/target-supports.exp
> >> @@ -449,7 +449,7 @@ proc check_ifunc_available { } {
> >>extern "C" {
> >>#endif
> >>typedef void F (void);
> >> -  F* g (void) {}
> >> +  F* g (void) { return 0; }
> >>void f () __attribute__ ((ifunc ("g")));
> >>#ifdef __cplusplus
> >>}
> > 
> > Is it OK to "return 0" from this ifunc handler, or might some analysis in
> > GCC trip over that (at some later point)?  In my patch, I returned the
> > address of an "extern" function.
> ISTM the question is whether or not ifuncs are ever allowed to return
> NULL.  Maybe ping the glibc folks since that's where the extension started?

Returning NULL means immediate segfault if somebody tries to call that
function.

Jakub

[og7] vector_length extension part 5: libgomp and tests

[Cesar Philippidis]

The attached patch is the last one in the vector length extension
series. It consists of some tweaks to the libgomp nvptx plugin to
accommodate larger vectors along with two test cases.

I only added two test cases because there's really not much interesting
going on with longer vector lengths. We should eventually add more tests
cases to handle situations where the nvptx BE falls back to using a
shorter vector length. But right now GCC just makes those changes
silently. There is precedent for the nvptx BE to emit a warning when
vector length != 32, but that might be too verbose. On one hand, it
could be argued that the compiler should error if it cannot satisfy the
user's request. On the other hand, falling back to a smaller vector
length ensures correctness.

Thomas, do you have any thoughts on the warnings/errors or there lack of?

I'll apply this patch to openacc-gcc-7-branch once the reduction changes
have been approved.

Cesar
2018-03-02  Cesar Philippidis  

	libgomp/
	* plugin/plugin-nvptx.c (nvptx_exec): Adjust calculations of
	workers and vectors.
	* testsuite/libgomp.oacc-c-c++-common/vred2d-128.c: New test.
	* testsuite/libgomp.oacc-fortran/gemm.f90: New test.


>From 37e83baa6ae7e867e6203d7554e8381660488421 Mon Sep 17 00:00:00 2001
From: Cesar Philippidis 
Date: Fri, 2 Mar 2018 06:54:25 -0800
Subject: [PATCH] runtime changes and tests

---
 libgomp/plugin/plugin-nvptx.c  |  10 +-
 .../libgomp.oacc-c-c++-common/vred2d-128.c |  55 +++
 libgomp/testsuite/libgomp.oacc-fortran/gemm.f90| 108 +
 3 files changed, 169 insertions(+), 4 deletions(-)
 create mode 100644 libgomp/testsuite/libgomp.oacc-c-c++-common/vred2d-128.c
 create mode 100644 libgomp/testsuite/libgomp.oacc-fortran/gemm.f90

diff --git a/libgomp/plugin/plugin-nvptx.c b/libgomp/plugin/plugin-nvptx.c
index bdc0c30e1f5..9b4768f0e59 100644
--- a/libgomp/plugin/plugin-nvptx.c
+++ b/libgomp/plugin/plugin-nvptx.c
@@ -734,8 +734,6 @@ nvptx_exec (void (*fn), size_t mapnum, void **hostaddrs, void **devaddrs,
   int threads_per_block = threads_per_sm > block_size
 ? block_size : threads_per_sm;
 
-  threads_per_block /= warp_size;
-
   if (threads_per_sm > cpu_size)
 threads_per_sm = cpu_size;
 
@@ -802,6 +800,10 @@ nvptx_exec (void (*fn), size_t mapnum, void **hostaddrs, void **devaddrs,
 
   if (seen_zero)
 {
+  int vectors = dims[GOMP_DIM_VECTOR] > 0
+	? dims[GOMP_DIM_VECTOR] : warp_size;
+  int workers = threads_per_block / vectors;
+
   for (i = 0; i != GOMP_DIM_MAX; i++)
 	if (!dims[i])
 	  {
@@ -819,10 +821,10 @@ nvptx_exec (void (*fn), size_t mapnum, void **hostaddrs, void **devaddrs,
 		  : 2 * dev_size;
 		break;
 	  case GOMP_DIM_WORKER:
-		dims[i] = threads_per_block;
+		dims[i] = workers;
 		break;
 	  case GOMP_DIM_VECTOR:
-		dims[i] = warp_size;
+		dims[i] = vectors;
 		break;
 	  default:
 		abort ();
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/vred2d-128.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/vred2d-128.c
new file mode 100644
index 000..0fbd30e77b9
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/vred2d-128.c
@@ -0,0 +1,55 @@
+/* Test large vector lengths.  */
+
+#include 
+
+#define n 1
+int a1[n], a2[n];
+
+#define gentest(name, outer, inner)		\
+  void name ()	\
+  {		\
+  long i, j, t1, t2, t3;			\
+  _Pragma(outer)\
+  for (i = 0; i < n; i++)			\
+{		\
+  t1 = 0;	\
+  t2 = 0;	\
+  _Pragma(inner)\
+  for (j = i; j < n; j++)			\
+	{	\
+	  t1++;	\
+	  t2--;	\
+	}	\
+  a1[i] = t1;\
+  a2[i] = t2;\
+}		\
+  for (i = 0; i < n; i++)			\
+{		\
+  assert (a1[i] == n-i);			\
+  assert (a2[i] == -(n-i));			\
+}		\
+  }		\
+  
+gentest (test1, "acc parallel loop gang vector_length (128)",
+	 "acc loop vector reduction(+:t1) reduction(-:t2)")
+
+gentest (test2, "acc parallel loop gang vector_length (128)",
+	 "acc loop worker vector reduction(+:t1) reduction(-:t2)")
+
+gentest (test3, "acc parallel loop gang worker vector_length (128)",
+	 "acc loop vector reduction(+:t1) reduction(-:t2)")
+
+gentest (test4, "acc parallel loop",
+	 "acc loop reduction(+:t1) reduction(-:t2)")
+
+
+int
+main ()
+{
+  test1 ();
+  test2 ();
+  test3 ();
+  test4 ();
+
+  return 0;
+}
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/gemm.f90 b/libgomp/testsuite/libgomp.oacc-fortran/gemm.f90
new file mode 100644
index 000..ad67dce5cad
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-fortran/gemm.f90
@@ -0,0 +1,108 @@
+! Exercise three levels of parallelism using SGEMM from BLAS.
+
+! { dg-additional-options "-fopenacc-dim=-:-:128" }
+
+! Implicitly set vector_length to 128 using -fopenacc-dim.
+subroutine openacc_sgemm (m, n, k, alpha, a, b, beta, c)
+  integer :: m, n, k
+  real :: alpha, beta
+  real :: a(k,*), b(k,*), c(m,*)
+
+  integer :: 

Re: [gcc-7 backport PATCH, rs6000/pr84371] Update butilins-3*.c tests for power9 codegen.

[Segher Boessenkool]

On Fri, Mar 02, 2018 at 12:33:25PM -0600, Will Schmidt wrote:
> Hi, 
>   This is a backport of the relevant pieces to fix pr84371 (builtins-3.c
> fails on Power9) in the gcc-7 branch.
> 
> sniff-tested OK on p7,p8,p9.
> OK for backport to gcc-7 ?

Okay.  Thanks!

> 2018-03-02  Will Schmidt  
> 
>   Backport from trunk.
> 
>   PR target/84371
>   * gcc.target/powerpc/builtins-3.c: Update dg-options and dg-skip-if
>   stanzas.
>   * gcc.target/powerpc/builtins-3.p8.c: Add dg-skip-if stanza.
>   * gcc.target/powerpc/builtins-3.p9.c: Add dg-skip-if stanza.

Put the original header line (date+name+email, indented with a tab) in
there as well?


Segher

Re: C++ PATCH for c++/84578, ICE when initializing flexarr

[Jason Merrill]

OK.

On Fri, Mar 2, 2018 at 12:36 PM, Marek Polacek  wrote:
> We ICE in cxx_eval_vec_init_1 whereby we try to initialize a flexible array
> member, because the code computing the number of elements of ATYPE wasn't
> prepared to handle arrays with no bounds.  Fixed by using
> get_array_or_vector_nelts, broken out of existing code.
>
> Martin suggested to reject this code, but I decided to leave this as-is for
> now; we already reject code that actually tries to initialize the flexible
> array member with some data, e.g.:
>
> struct A {
>   constexpr A() : i(), x("foo") {}
>   int i;
>   char x[];
> };
> A a;
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-03-02  Marek Polacek  
>
> PR c++/84578
> * constexpr.c (get_array_or_vector_nelts): New.
> (cxx_eval_array_reference): Use it.
> (cxx_eval_vec_init_1): Likewise.
> (cxx_eval_store_expression): Likewise.
>
> * g++.dg/ext/flexary29.C: New test.
>
> diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
> index 39e6cdfb33d..27f841db38f 100644
> --- gcc/cp/constexpr.c
> +++ gcc/cp/constexpr.c
> @@ -2300,6 +2300,32 @@ diag_array_subscript (const constexpr_ctx *ctx, tree 
> array, tree index)
>  }
>  }
>
> +/* Return the number of elements for TYPE (which is an ARRAY_TYPE or
> +   a VECTOR_TYPE).  */
> +
> +static tree
> +get_array_or_vector_nelts (const constexpr_ctx *ctx, tree type,
> +  bool *non_constant_p, bool *overflow_p)
> +{
> +  tree nelts;
> +  if (TREE_CODE (type) == ARRAY_TYPE)
> +{
> +  if (TYPE_DOMAIN (type))
> +   nelts = array_type_nelts_top (type);
> +  else
> +   nelts = size_zero_node;
> +}
> +  else if (VECTOR_TYPE_P (type))
> +nelts = size_int (TYPE_VECTOR_SUBPARTS (type));
> +  else
> +gcc_unreachable ();
> +
> +  /* For VLAs, the number of elements won't be an integer constant.  */
> +  nelts = cxx_eval_constant_expression (ctx, nelts, false,
> +   non_constant_p, overflow_p);
> +  return nelts;
> +}
> +
>  /* Extract element INDEX consisting of CHARS_PER_ELT chars from
> STRING_CST STRING.  */
>
> @@ -2379,22 +2405,8 @@ cxx_eval_array_reference (const constexpr_ctx *ctx, 
> tree t,
> }
>  }
>
> -  tree nelts;
> -  if (TREE_CODE (TREE_TYPE (ary)) == ARRAY_TYPE)
> -{
> -  if (TYPE_DOMAIN (TREE_TYPE (ary)))
> -   nelts = array_type_nelts_top (TREE_TYPE (ary));
> -  else
> -   nelts = size_zero_node;
> -}
> -  else if (VECTOR_TYPE_P (TREE_TYPE (ary)))
> -nelts = size_int (TYPE_VECTOR_SUBPARTS (TREE_TYPE (ary)));
> -  else
> -gcc_unreachable ();
> -
> -  /* For VLAs, the number of elements won't be an integer constant.  */
> -  nelts = cxx_eval_constant_expression (ctx, nelts, false, non_constant_p,
> -   overflow_p);
> +  tree nelts = get_array_or_vector_nelts (ctx, TREE_TYPE (ary), 
> non_constant_p,
> + overflow_p);
>VERIFY_CONSTANT (nelts);
>if ((lval
> ? !tree_int_cst_le (index, nelts)
> @@ -2895,7 +2907,6 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree 
> atype, tree init,
>  bool *non_constant_p, bool *overflow_p)
>  {
>tree elttype = TREE_TYPE (atype);
> -  unsigned HOST_WIDE_INT max = tree_to_uhwi (array_type_nelts_top (atype));
>verify_ctor_sanity (ctx, atype);
>vec **p = _ELTS (ctx->ctor);
>bool pre_init = false;
> @@ -2924,6 +2935,9 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree 
> atype, tree init,
>pre_init = true;
>  }
>
> +  tree nelts = get_array_or_vector_nelts (ctx, atype, non_constant_p,
> + overflow_p);
> +  unsigned HOST_WIDE_INT max = tree_to_uhwi (nelts);
>for (i = 0; i < max; ++i)
>  {
>tree idx = build_int_cst (size_type_node, i);
> @@ -3480,19 +3494,8 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, 
> tree t,
> case ARRAY_REF:
>   tree nelts, ary;
>   ary = TREE_OPERAND (probe, 0);
> - if (TREE_CODE (TREE_TYPE (ary)) == ARRAY_TYPE)
> -   {
> - if (TYPE_DOMAIN (TREE_TYPE (ary)))
> -   nelts = array_type_nelts_top (TREE_TYPE (ary));
> - else
> -   nelts = size_zero_node;
> -   }
> - else if (VECTOR_TYPE_P (TREE_TYPE (ary)))
> -   nelts = size_int (TYPE_VECTOR_SUBPARTS (TREE_TYPE (ary)));
> - else
> -   gcc_unreachable ();
> - nelts = cxx_eval_constant_expression (ctx, nelts, false,
> -   non_constant_p, overflow_p);
> + nelts = get_array_or_vector_nelts (ctx, TREE_TYPE (ary),
> +non_constant_p, overflow_p);
>   VERIFY_CONSTANT (nelts);
>   gcc_assert (TREE_CODE (nelts) == INTEGER_CST
>  

[og7] vector_length extension part 4: target hooks and automatic parallelism

[Cesar Philippidis]

The attached patch adjusts the existing goacc validate_dims target hook
and introduces a new goacc adjust_parallelism target hook. Now that
vector length is no longer hard-coded to 32, there are four different
ways to set it:

  1) compiler default
  2) explicitly via the vector_length clause
  3) compile time using -fopenacc-dim or the GOMP_OPENACC_DIM
 environment variable
  4) fallback to vector_length = 32 due to insufficient parallelism

The compiler default is activated in the absence of 2) and 3). It is
controlled by the macro PTX_VECTOR_LENGTH in nvptx.c. While working on
this patch set, I had it set to 128 to get more test coverage. But in
order to maintain backwards compatibility with acc routines (which is
still a work in progress), I've kept the default vector length to 32.
Besides, large vector reductions are expected to run slower until the
parallel reduction finalizer is ready.

The new default_dims arguments to validate_dims represents is necessary
to accommodate option 3) from above. validate_dims is called after
oaccdevlow has assigned parallelism to each acc loop.

Prior to this patch, oaccdevlow automatically assigned parallelism to
acc loops using oacc_loop_fixed_partitions and
oacc_loop_auto_partitions. Both of those functions were
processor-agnostic. In the case of nvptx, due to the current limitations
in this patch set, the nvptx BE needs to fallback to using a
vector_length of 32 whenever a vector loop is nested inside a worker
loop. By supplying the parallelism mask for both the current loop and
the outer loops, the goacc adjust_parallelism hook allows the back ends
to fine tune any parallelism as necessary.

Inside the nvptx BE, nvptx_goacc_adjust_parallelism uses a new "nvptx vl
warp" function attribute to denote that the offloaded function must
fallback to using a vector length of 32. Later,
nvptx_goacc_validate_dims uses the attribute to adjust vector_length
accordingly.

Going forward, in addition to adding a new parallel reduction finalizer,
the nvptx BE would benefit from merging synchronization and reduction
code for combined worker-reduction loops, e.g.

  #pragma acc loop worker vector

At present, GCC partitions acc loops with internal function markers for
each level of parallelism associated with the loop. If a loop has both
worker and vector level parallelism, it will have a dummy outer worker
loop, and dummy inner vector loop. On CUDA hardware, there's no strong
difference between workers and vectors as CUDA blocks are a loose
collection of warps. Therefore, it would make more sense to merge the
two loops together into a special WV loop. That would at least require
some changes in the BE in addition to oacc_loop_{auto,fixed}_partitions.
There were some problems in the past where CUDA hardware would lock up
because the synchronization requirements for those two levels of
parallelism. Merging them ought to simplify the synchronization code and
enable the PTX JIT to generate better code.

Overall, the changes in this patch are mild. I'll apply it to
openacc-gcc-7-branch after Tom approves the reduction patch.

Cesar

2018-03-02  Cesar Philippidis  

	gcc/
	* config/nvptx/nvptx.c (NVPTX_GOACC_VL_WARP): Define.
	(nvptx_goacc_needs_vl_warp): New function.
	(nvptx_goacc_validate_dims): Add new default_dims argument and take
	larger vector lengths into account.
	(nvptx_adjust_parallelism): New function.
	(TARGET_GOACC_ADJUST_PARALLELISM): Define.
	* doc/tm.texi: Regenerate.
	* doc/tm.texi.in: Add placeholder for TARGET_GOACC_ADJUST_PARALLELISM.
	* omp-offload.c (oacc_parse_default_dims): Update usage of the
	targetm.goacc_valdate_dims hook.
	(oacc_validate_dims): Add default_dims argument.
	(oacc_loop_fixed_partitions): Use the adjust_parallelism hook to
	modify this_mask.
	(oacc_loop_auto_partitions): Use the adjust_parallelism hook to
	modify this_mask and loop->mask.
	(execute_oacc_device_lower): Update call to oacc_validate_dims.
	(default_goacc_adjust_parallelism): New function.
	* target.def (validate_dims): Add new default_dims argument.
	(adjust_parallelism): New hook.
	* targhooks.h (default_goacc_validate_dims): Add new argument.
	(default_goacc_adjust_parallelism): Declare.

>From 1ee16b267dfbb0a148e8ec3b83ca463c21cbac1d Mon Sep 17 00:00:00 2001
From: Cesar Philippidis 
Date: Fri, 2 Mar 2018 10:08:23 -0800
Subject: [PATCH] New target hooks

---
 gcc/config/nvptx/nvptx.c | 139 +--
 gcc/doc/tm.texi  |  15 +++--
 gcc/doc/tm.texi.in   |   2 +
 gcc/omp-offload.c|  35 ++--
 gcc/target.def   |  17 --
 gcc/targhooks.h  |   3 +-
 6 files changed, 190 insertions(+), 21 deletions(-)

diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 5642941c6a3..507c8671704 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -5205,14 +5205,36 @@ nvptx_simt_vf ()
   return PTX_WARP_SIZE;
 }
 
+#define 

Re: [PR c++/84492] return stmt expr ending with overload

[Jason Merrill]

OK.

On Fri, Mar 2, 2018 at 2:57 AM, Alexandre Oliva  wrote:
> On Feb 28, 2018, Jason Merrill  wrote:
>
>> On Wed, Feb 28, 2018 at 7:06 AM, Alexandre Oliva  wrote:
>>> We ICEd when returning a stmt expr that ends with an overloaded
>>> function.  It's ill-formed when we can't convert the function name to
>>> the return type, but we should say that, not ICE.
>
>> Hmm, what about the case where we could convert the function name to
>> the return type?  I think it should still be ill-formed for a
>> statement-expression to have an unresolved overload as its value.
>
> I was (not :-) thinking in those terms; I suppose one might wish ({x;})
> to be equivalent to (x), but one might also wish for stmt exprs to be
> self-contained, and I suppose you prefer the latter, or that there's
> consensus about how the stmt expr extension should be handled in this
> regard, so...
>
>> So finish_stmt_expr_expr should check type_unknown_p.
>
> [PR c++/84492] stmt expr ending with overload
>
> We ICEd when returning a stmt expr that ends with an overloaded
> function, because instantiate_type did not know what to do with
> STMT_EXPRs.  And it shouldn't have to: the expected type of a stmt
> expr cannot be used to resolve its value: an unresolved overload
> cannot supply the result of a stmt expr.  Catch that and report the
> error in the stmt expr before we have a chance to instantiate it.
>
> Regstrapped on i686- and x86_64-linux-gnu.  Ok?
>
> for  gcc/cp/ChangeLog
>
> PR c++/84492
> * semantics.c (finish_stmt_expr_expr): Reject unresolved
> overloads used as stmt expr values.
>
> for  gcc/testsuite/ChangeLog
>
> PR c++/84492
> * g++.dg/pr84492.C: New.
> ---
>  gcc/cp/semantics.c |9 -
>  gcc/testsuite/g++.dg/pr84492.C |   40 
> 
>  2 files changed, 48 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/g++.dg/pr84492.C
>
> diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
> index 1ac1d23e7610..af401866b569 100644
> --- a/gcc/cp/semantics.c
> +++ b/gcc/cp/semantics.c
> @@ -2115,7 +2115,14 @@ finish_stmt_expr_expr (tree expr, tree stmt_expr)
>  {
>tree type = TREE_TYPE (expr);
>
> -  if (processing_template_decl)
> +  if (type && type_unknown_p (type))
> +   {
> + error ("a statement expression is an insufficient context"
> +" for overload resolution");
> + TREE_TYPE (stmt_expr) = error_mark_node;
> + return error_mark_node;
> +   }
> +  else if (processing_template_decl)
> {
>   expr = build_stmt (input_location, EXPR_STMT, expr);
>   expr = add_stmt (expr);
> diff --git a/gcc/testsuite/g++.dg/pr84492.C b/gcc/testsuite/g++.dg/pr84492.C
> new file mode 100644
> index ..1a2922096d19
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/pr84492.C
> @@ -0,0 +1,40 @@
> +// { dg-do compile }
> +// { dg-options "-fpermissive" }
> +
> +template int foo()
> +{
> +  return ({ foo; }); // { dg-error "insufficient context" }
> +}
> +
> +int bar()
> +{
> +  return ({ foo; }); // { dg-error "insufficient context" }
> +}
> +
> +void bar(int);
> +
> +typedef void (*bart)(int);
> +
> +bart barf()
> +{
> +  return ({ bar; }); // { dg-error "insufficient context" }
> +}
> +
> +bool bark()
> +{
> +  return ({ barf; }); // ok, no overload
> +}
> +
> +template 
> +class C
> +{
> +  static int f();
> +  bool g()
> +  {
> +return ({ f; }); // ok, no overload
> +  }
> +  bool g(int)
> +  {
> +return ({ g; }); // { dg-error "insufficient context" }
> +  }
> +};
>
>
> --
> Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/   FSF Latin America board member
> Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: [PR c++/84593] ice on braced init with uninit ref field

[Jason Merrill]

On Fri, Mar 2, 2018 at 2:57 AM, Alexandre Oliva  wrote:
> On Feb 28, 2018, Jason Merrill  wrote:
>
>> On Wed, Feb 28, 2018 at 7:08 AM, Alexandre Oliva  wrote:
>>> Don't allow the initializer expr to be NULL in a ctor initializer
>>> list, make it error_marker_node instead.
>
>> I don't want error_mark_nodes in a CONSTRUCTOR, either.  When there
>> isn't an NSDMI to worry about, we zero-initialize the reference, and
>> it seems reasonable to continue doing that, by fixing
>> build_zero_init_1 to return something non-null for a reference.
>
> Like this?  Regstrapped on i686- and x86_64-linux-gnu.
>
> [PR c++/84593] ice on braced init with uninit ref field
>
> If an initializer expr is to be NULL in a ctor initializer list, we
> ICE in picflag_from_initializer and elsewhere.
>
> If we're missing an initializer for a reference field, we report the
> error, but then build a zero initializer to avoid the ICE.
>
> for  gcc/cp/ChangeLog
>
> PR c++/84593
> * init.c (build_zero_init_1): Zero-initialize references.
>
> for  gcc/testsuite/ChangeLog
>
> PR c++/84593
> * g++.dg/cpp1y/pr84593.C: New.
> ---
>  gcc/cp/init.c|5 -
>  gcc/testsuite/g++.dg/cpp1y/pr84593.C |8 
>  2 files changed, 12 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr84593.C
>
> diff --git a/gcc/cp/init.c b/gcc/cp/init.c
> index d0d14abdc9fa..ed28e9a46dbc 100644
> --- a/gcc/cp/init.c
> +++ b/gcc/cp/init.c
> @@ -284,7 +284,10 @@ build_zero_init_1 (tree type, tree nelts, bool 
> static_storage_p,
>else if (VECTOR_TYPE_P (type))
>  init = build_zero_cst (type);
>else
> -gcc_assert (TREE_CODE (type) == REFERENCE_TYPE);
> +{
> +  gcc_assert (TREE_CODE (type) == REFERENCE_TYPE);
> +  init = fold (convert (type, integer_zero_node));

Maybe build_zero_cst?

OK either way.

Jason

Re: [PR c++/84497] ref to undefined tls init

[Jason Merrill]

On Fri, Mar 2, 2018 at 11:07 AM, Nathan Sidwell  wrote:
> Jason, Jakub,
> I've simplified the testcase Padraig provided and attached it to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84497
>
> Notice that 'Base::Base ()' is not a constexpr ctor, because the integer
> member is not initialized.  That means 10.1.4/4.5 is unsatisfied.  So struct
> Base gets its 'has_constexpr' flag set via the Base::Base (int) ctor.
> struct Derived is not so lucky, and 'has_constexpr' is unset.
>
> Thus we end up with an unsatisfied strong reference to _ZTH11derived_obj
>
> NEEDS_CONSTRUCTING && !HAS_CONSTEXPR_CTOR is insufficient to determine
> whether there must be an init fn.
>
> While the patch does indeed work, it may be too pessimal, making the
> reference weak in more cases than necessary.
>
> NEEDS_CONSTRUCTING && !HAS_CONSTEXPR_CTOR && !HAS_DEFAULT_CONSTRUCTOR seems
> like it would be sufficient. and indeed that works in this case.

Do you mean !HAS_TRIVIAL_DFLT rather than !HAS_DEFAULT_CONSTRUCTOR?
That makes sense to me.

Jason

[gcc-7 backport PATCH, rs6000/pr84371] Update butilins-3*.c tests for power9 codegen.

[Will Schmidt]

Hi, 
  This is a backport of the relevant pieces to fix pr84371 (builtins-3.c
fails on Power9) in the gcc-7 branch.

sniff-tested OK on p7,p8,p9.
OK for backport to gcc-7 ?

Thanks,
-Will

[testsuite]

2018-03-02  Will Schmidt  

Backport from trunk.

PR target/84371
* gcc.target/powerpc/builtins-3.c: Update dg-options and dg-skip-if
stanzas.
* gcc.target/powerpc/builtins-3.p8.c: Add dg-skip-if stanza.
* gcc.target/powerpc/builtins-3.p9.c: Add dg-skip-if stanza.

---

Index: gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c
===
--- gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c(revision 258140)
+++ gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c(working copy)
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
 /* { dg-options "-mcpu=power8" } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } } */
 
 #include 
 
Index: gcc/testsuite/gcc.target/powerpc/builtins-3-p9.c
===
--- gcc/testsuite/gcc.target/powerpc/builtins-3-p9.c(revision 258140)
+++ gcc/testsuite/gcc.target/powerpc/builtins-3-p9.c(working copy)
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
 /* { dg-options "-mcpu=power9" } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power9" } } */
 
 #include 
 
Index: gcc/testsuite/gcc.target/powerpc/builtins-3.c
===
--- gcc/testsuite/gcc.target/powerpc/builtins-3.c   (revision 258140)
+++ gcc/testsuite/gcc.target/powerpc/builtins-3.c   (working copy)
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target powerpc_vsx_ok } */
-/* { dg-options "-maltivec -mvsx" } */
+/* { dg-options "-O2 -mvsx -mcpu=power6" } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power6" } } */
 
 #include 
 

RFA (make_dispatcher_decl): PATCH for c++/83911, ICE with multiversioned constructor

[Jason Merrill]

As I mentioned in the PR, the problem here is that we're replacing a
constructor with a dispatcher function which doesn't look much like a
constructor.  This patch adjusts make_dispatcher_decl to make it look
more like the functions it dispatches to, but other things are certain
to break for similar reasons down the road.  A proper solution should
be more transparent, like thunks.

Tested x86_64-pc-linux-gnu.  Does this seem worth applying to fix the
regression?
commit d3b4453834bb2e3cc1c875e76fe593c16f263f77
Author: Jason Merrill 
Date:   Fri Feb 16 16:53:47 2018 -0500

PR c++/83911 - ICE with multiversioned constructor.

gcc/
* attribs.c (make_dispatcher_decl): Copy METHOD_TYPE,
DECL_CXX_{CON,DE}STRUCTOR_P.
gcc/cp/
* cp-tree.h (DECL_CONSTRUCTOR_P): Use DECL_CXX_CONSTRUCTOR_P.
(DECL_DESTRUCTOR_P): Use DECL_CXX_DESTRUCTOR_P.
* mangle.c (write_unqualified_name): Check IDENTIFIER_[CD]TOR_P.

diff --git a/gcc/attribs.c b/gcc/attribs.c
index bfadf124dcb..2e9e69904f0 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -1063,9 +1063,14 @@ make_dispatcher_decl (const tree decl)
   func_name = xstrdup (IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)));
 
   fn_type = TREE_TYPE (decl);
-  func_type = build_function_type (TREE_TYPE (fn_type),
-  TYPE_ARG_TYPES (fn_type));
-  
+  if (TREE_CODE (fn_type) == METHOD_TYPE)
+func_type = build_method_type_directly (TYPE_METHOD_BASETYPE (fn_type),
+   TREE_TYPE (fn_type),
+   TYPE_ARG_TYPES (fn_type));
+  else
+func_type = build_function_type (TREE_TYPE (fn_type),
+TYPE_ARG_TYPES (fn_type));
+
   func_decl = build_fn_decl (func_name, func_type);
   XDELETEVEC (func_name);
   TREE_USED (func_decl) = 1;
@@ -1078,6 +1083,9 @@ make_dispatcher_decl (const tree decl)
   /* This will be of type IFUNCs have to be externally visible.  */
   TREE_PUBLIC (func_decl) = 1;
 
+  DECL_CXX_CONSTRUCTOR_P (func_decl) = DECL_CXX_CONSTRUCTOR_P (decl);
+  DECL_CXX_DESTRUCTOR_P (func_decl) = DECL_CXX_DESTRUCTOR_P (decl);
+
   return func_decl;  
 }
 
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 17d8c6d2650..268be0fd543 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -2695,7 +2695,7 @@ struct GTY(()) lang_decl {
 /* For FUNCTION_DECLs and TEMPLATE_DECLs: nonzero means that this function
is a constructor.  */
 #define DECL_CONSTRUCTOR_P(NODE) \
-  IDENTIFIER_CTOR_P (DECL_NAME (NODE))
+  DECL_CXX_CONSTRUCTOR_P (STRIP_TEMPLATE (NODE))
 
 /* Nonzero if NODE (a FUNCTION_DECL) is a constructor for a complete
object.  */
@@ -2724,7 +2724,7 @@ struct GTY(()) lang_decl {
 /* Nonzero if NODE (a FUNCTION_DECL or TEMPLATE_DECL)
is a destructor.  */
 #define DECL_DESTRUCTOR_P(NODE)\
-  IDENTIFIER_DTOR_P (DECL_NAME (NODE))
+  DECL_CXX_DESTRUCTOR_P (STRIP_TEMPLATE (NODE))
 
 /* Nonzero if NODE (a FUNCTION_DECL) is a destructor, but not the
specialized in-charge constructor, in-charge deleting constructor,
diff --git a/gcc/cp/mangle.c b/gcc/cp/mangle.c
index 94c4bed2848..ecd4eb066d4 100644
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -1351,9 +1351,9 @@ write_unqualified_name (tree decl)
   else if (DECL_DECLARES_FUNCTION_P (decl))
 {
   found = true;
-  if (DECL_CONSTRUCTOR_P (decl))
+  if (IDENTIFIER_CTOR_P (DECL_NAME (decl)))
write_special_name_constructor (decl);
-  else if (DECL_DESTRUCTOR_P (decl))
+  else if (IDENTIFIER_DTOR_P (DECL_NAME (decl)))
write_special_name_destructor (decl);
   else if (DECL_CONV_FN_P (decl))
{
diff --git a/gcc/testsuite/g++.dg/ext/mv27.C b/gcc/testsuite/g++.dg/ext/mv27.C
new file mode 100644
index 000..443a54be765
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/mv27.C
@@ -0,0 +1,18 @@
+// PR c++/83911
+// { dg-do compile { target i?86-*-* x86_64-*-* } }
+// { dg-require-ifunc "" }
+
+class SimdFloat
+{
+public:
+__attribute__ ((target ("default")))
+SimdFloat(float x) {}
+
+__attribute__ ((target ("avx2")))
+SimdFloat(float x) {}
+};
+
+SimdFloat foo()
+{
+return 1;
+}

Re: C++ PATCH to fix static init with () in a template (PR c++/84582)

[Marek Polacek]

On Fri, Mar 02, 2018 at 01:17:55PM -0500, Jason Merrill wrote:
> Actually, this is redundant; an expression can only be dependent if
> processing_template_decl.  I'll fix.

Ah, that makes a lot of sense.  Thanks,

Marek

Re: C++ PATCH to fix static init with () in a template (PR c++/84582)

[Jason Merrill]

On Mar 1, 2018 4:57 PM, "Jason Merrill"  wrote:

> Ok.
>
> On Mar 1, 2018 4:40 PM, "Marek Polacek"  wrote:
>
>> On Thu, Mar 01, 2018 at 01:56:50PM -0500, Jason Merrill wrote:
>> > On Thu, Mar 1, 2018 at 8:17 AM, Marek Polacek 
>> wrote:
>> > > On Wed, Feb 28, 2018 at 04:50:39PM -0500, Jason Merrill wrote:
>> > >> On Wed, Feb 28, 2018 at 4:19 PM, Marek Polacek 
>> wrote:
>> > >> > On Wed, Feb 28, 2018 at 10:51:17AM -0500, Jason Merrill wrote:
>> > >> >> On Wed, Feb 28, 2018 at 9:32 AM, Marek Polacek <
>> pola...@redhat.com> wrote:
>> > >> >> > On Tue, Feb 27, 2018 at 04:16:31PM -0500, Jason Merrill wrote:
>> > >> >> >> On 02/27/2018 02:13 PM, Marek Polacek wrote:
>> > >> >> >> > My recent change introducing cxx_constant_init caused this
>> code
>> > >> >> >> >
>> > >> >> >> > template  class A {
>> > >> >> >> >static const long b = 0;
>> > >> >> >> >static const unsigned c = (b);
>> > >> >> >> > };
>> > >> >> >> >
>> > >> >> >> > to be rejected.  The reason is that force_paren_expr turns
>> "b" into "*(const
>> > >> >> >> > long int &) ", where the former is not value-dependent but
>> the latter is
>> > >> >> >> > value-dependent.  So when we get to maybe_constant_init_1:
>> > >> >> >> > 5147   if (!is_nondependent_static_init_expression (t))
>> > >> >> >> > 5148 /* Don't try to evaluate it.  */;
>> > >> >> >> > it's not evaluated and we get the non-constant
>> initialization error.
>> > >> >> >> > (Before we'd always evaluated the expression.)
>> > >> >> >> >
>> > >> >> >> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
>> > >> >> >> >
>> > >> >> >> > 2018-02-27  Marek Polacek  
>> > >> >> >> >
>> > >> >> >> > PR c++/84582
>> > >> >> >> > * semantics.c (force_paren_expr): Avoid creating a
>> static cast
>> > >> >> >> > when processing a template.
>> > >> >> >> >
>> > >> >> >> > * g++.dg/cpp1z/static1.C: New test.
>> > >> >> >> > * g++.dg/template/static37.C: New test.
>> > >> >> >> >
>> > >> >> >> > diff --git gcc/cp/semantics.c gcc/cp/semantics.c
>> > >> >> >> > index 35569d0cb0d..b48de2df4e2 100644
>> > >> >> >> > --- gcc/cp/semantics.c
>> > >> >> >> > +++ gcc/cp/semantics.c
>> > >> >> >> > @@ -1697,7 +1697,7 @@ force_paren_expr (tree expr)
>> > >> >> >> >   expr = build1 (PAREN_EXPR, TREE_TYPE (expr), expr);
>> > >> >> >> > else if (VAR_P (expr) && DECL_HARD_REGISTER (expr))
>> > >> >> >> >   /* We can't bind a hard register variable to a
>> reference.  */;
>> > >> >> >> > -  else
>> > >> >> >> > +  else if (!processing_template_decl)
>> > >> >> >>
>> > >> >> >> Hmm, this means that we forget about the parentheses in a
>> template.  I'm
>> > >> >> >> surprised that this didn't break anything in the testsuite.
>> In particular,
>> > >> >> >> auto-fn15.C.  I've attached an addition to auto-fn15.C to
>> catch this issue.
>> > >> >> >
>> > >> >> > Thanks, you're right.  I'll use it.
>> > >> >> >
>> > >> >> >> Can we use PAREN_EXPR instead of the static_cast in a template?
>> > >> >> >
>> > >> >> > I don't think so, it would fix the issue you pointed out in
>> auto-fn15.C but
>> > >> >> > it wouldn't fix the original test.  The problem with using
>> PAREN_EXPR in a
>> > >> >> > template is that instantiate_non_dependent_expr will turn in
>> into the
>> > >> >> > static cast anyway; tsubst_copy_and_build has
>> > >> >> > case PAREN_EXPR:
>> > >> >> >   RETURN (finish_parenthesized_expr (RECUR (TREE_OPERAND
>> (t, 0;
>> > >> >> > so it calls force_paren_expr and this time we're not in a
>> template.  And
>> > >> >> > then when calling cxx_constant_init we have the same issue.
>> > >> >>
>> > >> >> Then maybe we need something like fold_non_dependent_expr, which
>> > >> >> checks for dependency before substitution and then immediately
>> > >> >> evaluates the result.
>> > >> >
>> > >> > I hope you meant something like this.  Further testing also
>> revealed that
>> > >> > maybe_undo_parenthesized_ref should be able to unwrap PAREN_EXPR
>> (so that
>> > >> > (fn1)(); in paren2.C is handled correctly), and that lvalue_kind
>> should look
>> > >> > into PAREN_EXPR so as to give the correct answer regarding
>> lvalueness: we
>> > >> > should accept
>> > >> >
>> > >> > template
>> > >> > void foo (int i)
>> > >> > {
>> > >> >   ++(i);
>> > >> > }
>> > >> >
>> > >> > Apologies if I'm on the wrong track.
>> > >> >
>> > >> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
>> > >> >
>> > >> > 2018-02-28  Marek Polacek  
>> > >> > Jason Merrill  
>> > >> >
>> > >> > PR c++/84582
>> > >> > * semantics.c (force_paren_expr): Avoid creating the
>> static cast
>> > >> > when in a template.  Create a PAREN_EXPR when in a
>> template.
>> > >> > (maybe_undo_parenthesized_ref): Unwrap PAREN_EXPR.
>> > >> > * typeck2.c (store_init_value): Call
>> fold_non_dependent_expr 

[og7] vector_length extension part 3: reductions

[Cesar Philippidis]

This patch teaches the nvptx BE how to process vector reductions with
large vector lengths. The original vector reduction finalizer won't work
because it uses a warp shuffle operations. Now that vectors may contain
multiple warps, they need to store the partial reductions into
shared-memory like workers. Once the reduction variable is placed in
shared-memory, it will use the same atomic finalizer to update it as the
workers.

Much like the shared-memory spill-and-fill vector state propagation
extension, the nvptx BE needs to reserve enough shared-memory for each
worker that may encounter a vector reduction. That's why the reduction
functions have been augmented with an offload_attrs arguments. The
offload_attrs contains a max_workers field. Unlike vector_length, which
is fixed as a compile-time constant, num_workers can be altered
dynamically at runtime. Given that the size of a CUDA block is fixed,
max_workers is set to max_block_size / vector_length. This will be
discussed further in the next patch.

Effectively, the nvptx BE will now maintain a shared-memory reduction
buffer, named vector_red_sym, that contains max_workers logical
reduction partitions, where each partition contains enough shared-memory
for all of the reductions used by a single vector. By design, OpenACC
reductions are expanded relatively early during oaccdevlow. Because
accessing the reduction partition is a common operation, the partition
offset is placed in a register stored in cfun->machine_red_partition and
initialized in nvptx_init_axis_predicate. Due to how late that register
becomes available, nvptx_expand_shared_addr emits a
gen_nvptx_red_partition instruction to acquire share-memory address for
the reduction variable indirectly.

You may notice a hack in nvptx_declare_function_name. I observed that
sometimes GCC will mark red_partition as dead and not emit PTX code to
declare it. That's why nvptx_declare_function_name manually inserts it
into regno_reg_rtx prior to declaring all of the PTX registers. I think
there might be something wrong with nvptx_red_partition instruction.
Tom, can you take a look at it?

Ultimately, I suspect that large workers would greatly benefit by using
a new parallel tree reduction finalizer. Whereas the atomic finalizer
may have been suitable for a maximum of 32 workers, vector_length can be
up to 1024 threads, and a sequential finalizer will be slow. However,
that's a project for another day.

I'll commit this patch to openacc-gcc-7-branch after Tom reviews the new
nvptx_red_partition insn.

Cesar
2018-03-02  Cesar Philippidis  

	gcc/
	* config/nvptx/nvptx-protos.h (nvptx_output_red_partition): Declare.
	* config/nvptx/nvptx.c (vector_red_size, vector_red_align,
	vector_red_partition, vector_red_sym): New global variables.
	(nvptx_option_override): Initialize vector_red_sym.
	(nvptx_declare_function_name): Restore red_partition register.
	(nvptx_file_end): Emit code to declare the vector reduction variables.
	(nvptx_output_red_partition): New function.
	(nvptx_expand_shared_addr): Add vector argument. Use it to handle
	large vector reductions.
	(enum nvptx_builtins): Add NVPTX_BUILTIN_VECTOR_ADDR.
	(nvptx_init_builtins): Add VECTOR_ADDR.
	(nvptx_expand_builtin): Update call to nvptx_expand_shared_addr.
	Handle nvptx_expand_shared_addr.
	(nvptx_get_shared_red_addr): Add vector argument and handle large
	vectors.
	(nvptx_goacc_reduction_setup): Add offload_attrs argument and handle
	large vectors.
	(nvptx_goacc_reduction_init): Likewise.
	(nvptx_goacc_reduction_fini): Likewise.
	(nvptx_goacc_reduction_teardown): Likewise.
	(nvptx_goacc_reduction): Update calls to nvptx_goacc_reduction_{setup,
	init,fini,teardown}.
	* config/nvptx/nvptx.md (UNSPECV_RED_PART): New unspecv.
	(nvptx_red_partition): New insn.

>From 3834101d5144666f30d8798e983e276bd2c66636 Mon Sep 17 00:00:00 2001
From: Cesar Philippidis 
Date: Fri, 2 Mar 2018 07:36:11 -0800
Subject: [PATCH] reductions

---
 gcc/config/nvptx/nvptx-protos.h |   1 +
 gcc/config/nvptx/nvptx.c| 146 +++-
 gcc/config/nvptx/nvptx.md   |  12 
 3 files changed, 128 insertions(+), 31 deletions(-)

diff --git a/gcc/config/nvptx/nvptx-protos.h b/gcc/config/nvptx/nvptx-protos.h
index 16b316f12b8..326c38c5dc7 100644
--- a/gcc/config/nvptx/nvptx-protos.h
+++ b/gcc/config/nvptx/nvptx-protos.h
@@ -55,5 +55,6 @@ extern const char *nvptx_output_return (void);
 extern const char *nvptx_output_set_softstack (unsigned);
 extern const char *nvptx_output_simt_enter (rtx, rtx, rtx);
 extern const char *nvptx_output_simt_exit (rtx);
+extern const char *nvptx_output_red_partition (rtx, rtx);
 #endif
 #endif
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 4a48d44f44c..9d77176c638 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -142,6 +142,14 @@ static unsigned worker_red_size;
 static unsigned worker_red_align;
 static GTY(()) rtx 

Re: [PATCH] i18n fixes in gimple-ssa-sprintf.c (take 2)

[Jakub Jelinek]

On Fri, Mar 02, 2018 at 08:42:22AM +0100, Jakub Jelinek wrote:
> I've verified generated gcc.pot is the same between previous and this
> patch, except for line numbers in the comments, and if I comment out
> the (int) casts from dir.len in both one of fmtwarn and one of fmtwarn_n
> calls, gcc properly warns.  Ok for trunk if it passes bootstrap/regtest?

Successfully bootstrapped/regtested on x86_64-linux and i686-linux.
> 
> 2018-03-02  Jakub Jelinek  
> 
>   * substring-locations.h (format_warning_va): Formatting fix for
>   ATTRIBUTE_GCC_DIAG.
>   (format_warning_at_substring): Fix up ATTRIBUTE_GCC_DIAG second
>   argument.
>   (format_warning_n_va, format_warning_at_substring_n): New prototypes.
>   * substring-locations.c: Include intl.h.
>   (format_warning_va): Turned into small wrapper around
>   format_warning_n_va, renamed to ...
>   (format_warning_n_va): ... this, add N and PLURAL_GMSGID arguments,
>   rename GMSGID to SINGULAR_GMSGID, if SINGULAR_GMSGID != PLURAL_GMSGID,
>   use ngettext.
>   (format_warning_at_substring_n): New function.
>   * gimple-ssa-sprintf.c: Remove GCC diagnostic ignored pragma.
>   (fmtwarn): Add ATTRIBUTE_GCC_DIAG.  Turn into a copy of
>   format_warning_at_substring with just a shorter name instead of
>   const function pointer.
>   (fmtwarn_n): New function.
>   (maybe_warn, format_directive, parse_directive): Use fmtwarn_n where
>   appropriate, get rid of all the fmtstr temporaries, move conditionals
>   with G_() wrapped string literals directly into fmtwarn arguments,
>   cast dir.len to (int), formatting fixes.

Jakub

Re: [PATCH] Fix PR84427, PRE ANTIC iteration (again)

[Richard Biener]

On March 2, 2018 6:11:40 PM GMT+01:00, Jeff Law  wrote:
>On 03/01/2018 06:57 AM, Richard Biener wrote:
>> 
>> This fixes another testcase that shows that our ANTIC iteration can
>> fail to converge.  The fix continues what we did with previous fixes,
>> avoid spuriously removing stuff from the expression side of the sets.
>> This time going full-in and allowing multiple expressions for the
>> same value in the sets.  I've added verification that the value-sets
>> never grow during iteration which barfed on some of the related
>> existing testcases and thus helped finishing this and fixing all
>> places where we end up somewhat randomly choosing one or another
>> expression to drop.
>> 
>> I've verified with a GIMPLE testcase that if at insertion time
>> we have multiple partially redundant expressions for the same value
>> we insert/hoist it only once.  So the only "bad" effect of the
>> patch is that the expression part of the ANTIC sets grows -- by
>> not throwing away random stuff we might also arrive at larger
>> (value) solutions for ANTIC which means we may catch previously
>> missed optimizations (or pessimizations as you know PRE...).
>> 
>> I'm not entirely happy with the timing but I'm quite confident in
>> the approach also (again) having heavily discussed this with Micha.
>> 
>> Re-boostrap and regtest running on x86_64-unknown-linux-gnu.
>> 
>> I managed to go into a different solution at the beginning asking
>> for that pred/phiblock->edge cleanup and decided to leave that in...
>> 
>> The new verification is guarded with flag_checking so if it would
>> trigger but wouldn't result in not converging a release build
>> should be not affected.
>> 
>> Richard.
>> 
>> 2018-01-03  Richard Biener  
>> 
>>  PR tree-optimization/84427
>>  * tree-ssa-pre.c (bitmap_remove_expr_from_set): Remove.
>>  (bitmap_set_subtract_values): Rewrite to handle multiple
>>  exprs per value.
>>  (clean): Likewise.
>>  (prune_clobbered_mems): Likewise.
>>  (phi_translate): Take edge instead of pred/phiblock.
>>  (phi_translate_1): Likewise.
>>  (phi_translate_set): Likewise.  Insert all translated
>>  exprs for a value into the set, keeping possibly multiple
>>  expressions per value.
>>  (compute_antic_aux): Adjust for phi_translate changes.
>>  When intersecting union the expressions and prune those
>>  not in the final value set, keeping possibly multiple
>>  expressions per value.  Do not use value-insertion
>>  for unioning ANTIC_OUT U EXP_GEN - TMP_GEN but merge
>>  all expressions.  Add verification that the value-sets
>>  only shrink during iteration.
>>  (compute_partial_antic_aux): Adjust for the phi_translate changes.
>>  (do_pre_regular_insertion): Likewise.
>>  (do_pre_partial_partial_insertion): Likewise.
>> 
>>  * gcc.dg/torture/pr84427.c: New testcase.
>It looks like Zdenek has already filed a report against this change.
>I'll wait for resolution on that before reducing the various linux
>kernel build failures.

Can you attach the i686 one to the PR? the two existing ones are different 
causes already... 

Richard. 

>jeff

Re: C++ PATCH for c++/84663, ICE with incomplete array

[Jason Merrill]

OK.

On Fri, Mar 2, 2018 at 12:38 PM, Marek Polacek  wrote:
> Another ICE-on-invalid where we should check for error_mark_node otherwise
> we're toast.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-03-02  Marek Polacek  
>
> PR c++/84663
> * decl.c (cp_complete_array_type): Check error_mark_node.
>
> * g++.dg/parse/array-size3.C: New test.
>
> diff --git gcc/cp/decl.c gcc/cp/decl.c
> index 735ed5d63d2..1866e8f3574 100644
> --- gcc/cp/decl.c
> +++ gcc/cp/decl.c
> @@ -8323,7 +8323,7 @@ cp_complete_array_type (tree *ptype, tree 
> initial_value, bool do_default)
>   bits.  See also complete_type which does the same thing for arrays
>   of fixed size.  */
>type = *ptype;
> -  if (TYPE_DOMAIN (type))
> +  if (type != error_mark_node && TYPE_DOMAIN (type))
>  {
>elt_type = TREE_TYPE (type);
>TYPE_NEEDS_CONSTRUCTING (type) = TYPE_NEEDS_CONSTRUCTING (elt_type);
> diff --git gcc/testsuite/g++.dg/parse/array-size3.C 
> gcc/testsuite/g++.dg/parse/array-size3.C
> index e69de29bb2d..c3a824a91d7 100644
> --- gcc/testsuite/g++.dg/parse/array-size3.C
> +++ gcc/testsuite/g++.dg/parse/array-size3.C
> @@ -0,0 +1,7 @@
> +// PR c++/84663
> +
> +struct S {
> +  typedef S T[8];
> +  int f : -1ULL; // { dg-warning "exceeds its type" }
> +  S () { struct { T d; } e[]; } // { dg-error "size" }
> +};
>
> Marek

Re: C++ PATCH for c++/84664, ICE on invalid in lambda

[Jason Merrill]

OK.

On Fri, Mar 2, 2018 at 12:37 PM, Marek Polacek  wrote:
> This patch fixes an ICE-on-invalid by checking the result of mark_rvalue_use,
> similarly to perform_implicit_conversion_flags.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-03-02  Marek Polacek  
>
> PR c++/84664
> * typeck.c (cp_perform_integral_promotions): Check the result of
> mark_rvalue_use.
>
> * g++.dg/cpp0x/lambda/lambda-ice28.C: New test.
>
> diff --git gcc/cp/typeck.c gcc/cp/typeck.c
> index 0e7c63dd197..f535902231d 100644
> --- gcc/cp/typeck.c
> +++ gcc/cp/typeck.c
> @@ -2161,6 +2161,8 @@ cp_perform_integral_promotions (tree expr, 
> tsubst_flags_t complain)
>tree promoted_type;
>
>expr = mark_rvalue_use (expr);
> +  if (error_operand_p (expr))
> +return error_mark_node;
>
>/* [conv.prom]
>
> diff --git gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice28.C 
> gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice28.C
> index e69de29bb2d..5fe32129744 100644
> --- gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice28.C
> +++ gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice28.C
> @@ -0,0 +1,9 @@
> +// PR c++/84664
> +// { dg-do compile { target c++11 } }
> +
> +void
> +foo ()
> +{
> +  auto  = 1; // { dg-error "cannot bind" }
> +  [] { b > 0; }; // { dg-error ".b. is not captured" }
> +}
>
> Marek

Re: C++ PATCH for c++/84171, ICE in warn_for_sign_compare

[Jason Merrill]

OK.

On Fri, Mar 2, 2018 at 12:39 PM, Marek Polacek  wrote:
> Let's beef up warn_for_sign_compare checks; we'd folded the operands
> and they could've become garbage.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-03-02  Marek Polacek  
>
> PR c++/84171
> * c-warn.c (warn_for_sign_compare): Bail out if any of the operands
> is erroneous.
>
> * g++.dg/warn/Wsign-compare-8.C: New test.
>
> diff --git gcc/c-family/c-warn.c gcc/c-family/c-warn.c
> index f3fb62c7e62..7c385959c4f 100644
> --- gcc/c-family/c-warn.c
> +++ gcc/c-family/c-warn.c
> @@ -1931,6 +1931,9 @@ warn_for_sign_compare (location_t location,
>tree op0, tree op1,
>tree result_type, enum tree_code resultcode)
>  {
> +  if (error_operand_p (orig_op0) || error_operand_p (orig_op1))
> +return;
> +
>int op0_signed = !TYPE_UNSIGNED (TREE_TYPE (orig_op0));
>int op1_signed = !TYPE_UNSIGNED (TREE_TYPE (orig_op1));
>int unsignedp0, unsignedp1;
> diff --git gcc/testsuite/g++.dg/warn/Wsign-compare-8.C 
> gcc/testsuite/g++.dg/warn/Wsign-compare-8.C
> index e69de29bb2d..237ba84d526 100644
> --- gcc/testsuite/g++.dg/warn/Wsign-compare-8.C
> +++ gcc/testsuite/g++.dg/warn/Wsign-compare-8.C
> @@ -0,0 +1,8 @@
> +// PR c++/84171
> +// { dg-options "-Wsign-compare" }
> +
> +bool foo (char c)
> +{
> +  const int i = 0 = 0; // { dg-error "lvalue" }
> +  return c = i;
> +} // { dg-warning "control reaches" }
>
> Marek

C++ PATCH for c++/84171, ICE in warn_for_sign_compare

[Marek Polacek]

Let's beef up warn_for_sign_compare checks; we'd folded the operands
and they could've become garbage.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2018-03-02  Marek Polacek  

PR c++/84171
* c-warn.c (warn_for_sign_compare): Bail out if any of the operands
is erroneous.

* g++.dg/warn/Wsign-compare-8.C: New test.

diff --git gcc/c-family/c-warn.c gcc/c-family/c-warn.c
index f3fb62c7e62..7c385959c4f 100644
--- gcc/c-family/c-warn.c
+++ gcc/c-family/c-warn.c
@@ -1931,6 +1931,9 @@ warn_for_sign_compare (location_t location,
   tree op0, tree op1,
   tree result_type, enum tree_code resultcode)
 {
+  if (error_operand_p (orig_op0) || error_operand_p (orig_op1))
+return;
+
   int op0_signed = !TYPE_UNSIGNED (TREE_TYPE (orig_op0));
   int op1_signed = !TYPE_UNSIGNED (TREE_TYPE (orig_op1));
   int unsignedp0, unsignedp1;
diff --git gcc/testsuite/g++.dg/warn/Wsign-compare-8.C 
gcc/testsuite/g++.dg/warn/Wsign-compare-8.C
index e69de29bb2d..237ba84d526 100644
--- gcc/testsuite/g++.dg/warn/Wsign-compare-8.C
+++ gcc/testsuite/g++.dg/warn/Wsign-compare-8.C
@@ -0,0 +1,8 @@
+// PR c++/84171
+// { dg-options "-Wsign-compare" }
+
+bool foo (char c)
+{
+  const int i = 0 = 0; // { dg-error "lvalue" }
+  return c = i;
+} // { dg-warning "control reaches" }

Marek

C++ PATCH for c++/84663, ICE with incomplete array

[Marek Polacek]

Another ICE-on-invalid where we should check for error_mark_node otherwise
we're toast.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2018-03-02  Marek Polacek  

PR c++/84663
* decl.c (cp_complete_array_type): Check error_mark_node.

* g++.dg/parse/array-size3.C: New test.

diff --git gcc/cp/decl.c gcc/cp/decl.c
index 735ed5d63d2..1866e8f3574 100644
--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -8323,7 +8323,7 @@ cp_complete_array_type (tree *ptype, tree initial_value, 
bool do_default)
  bits.  See also complete_type which does the same thing for arrays
  of fixed size.  */
   type = *ptype;
-  if (TYPE_DOMAIN (type))
+  if (type != error_mark_node && TYPE_DOMAIN (type))
 {
   elt_type = TREE_TYPE (type);
   TYPE_NEEDS_CONSTRUCTING (type) = TYPE_NEEDS_CONSTRUCTING (elt_type);
diff --git gcc/testsuite/g++.dg/parse/array-size3.C 
gcc/testsuite/g++.dg/parse/array-size3.C
index e69de29bb2d..c3a824a91d7 100644
--- gcc/testsuite/g++.dg/parse/array-size3.C
+++ gcc/testsuite/g++.dg/parse/array-size3.C
@@ -0,0 +1,7 @@
+// PR c++/84663
+
+struct S {
+  typedef S T[8];
+  int f : -1ULL; // { dg-warning "exceeds its type" }
+  S () { struct { T d; } e[]; } // { dg-error "size" }
+};

Marek

Re: [PATCH] i18n fixes in gimple-ssa-sprintf.c (take 2)

[Jeff Law]

On 03/02/2018 12:42 AM, Jakub Jelinek wrote:
> On Thu, Mar 01, 2018 at 06:05:30PM -0700, Martin Sebor wrote:
>>> --- gcc/gimple-ssa-sprintf.c.jj 2018-02-27 23:16:19.747948912 +0100
>>> +++ gcc/gimple-ssa-sprintf.c2018-03-01 21:26:37.728861287 +0100
>>> @@ -592,14 +592,12 @@ get_format_string (tree format, location
>>>  /* The format_warning_at_substring function is not used here in a way
>>> that makes using attribute format viable.  Suppress the warning.  */
>>>
>>> -#pragma GCC diagnostic push
>>> -#pragma GCC diagnostic ignored "-Wsuggest-attribute=format"
>>> -
>>
>> The comment above the #pragmas should be removed too.
> 
> Done below.
> 
>>>  /* For convenience and brevity.  */
>>>
>>>  static bool
>>>(* const fmtwarn) (const substring_loc &, location_t,
>>>  const char *, int, const char *, ...)
>>> +  ATTRIBUTE_GCC_DIAG (5, 6)
>>>= format_warning_at_substring;
>>
>> So add
>>
>>   static bool
>> (* const fmtwarn_n) (const substring_loc &, location_t,
>>   const char *, int, unsigned HOST_WIDE_INT,
>>  const char *, const char*, ...)
>> ATTRIBUTE_GCC_DIAG (5, 6)
> 
> That would have to be ATTRIBUTE_GCC_DIAG (6, 8) ATTRIBUTE_GCC_DIAG (7, 8)
> 
>> = format_warning_at_substring_n;
>>
>> and use the pointer instead?
> 
> As I said, that doesn't really work; it works for -Wformat, but doesn't
> work with exgettext.  Which is why for fmtwarn one has to use
>   fmtwarn (.., G_("foobarbaz"), ...);
> instead of
>   fmtwarn (.., "foobarbaz", ...);
> even when it is not conditional.
> 
> What we can do though is just duplicate the
> format_warning_at_substring and format_warning_at_substring_n functions
> (which are short and simple enough) as static under the shorter names.
> This way we can also get rid of the G_( ... ) wrapping of non-conditional
> fmtwarn arguments.
> 
> I've verified generated gcc.pot is the same between previous and this
> patch, except for line numbers in the comments, and if I comment out
> the (int) casts from dir.len in both one of fmtwarn and one of fmtwarn_n
> calls, gcc properly warns.  Ok for trunk if it passes bootstrap/regtest?
> 
> 2018-03-02  Jakub Jelinek  
> 
>   * substring-locations.h (format_warning_va): Formatting fix for
>   ATTRIBUTE_GCC_DIAG.
>   (format_warning_at_substring): Fix up ATTRIBUTE_GCC_DIAG second
>   argument.
>   (format_warning_n_va, format_warning_at_substring_n): New prototypes.
>   * substring-locations.c: Include intl.h.
>   (format_warning_va): Turned into small wrapper around
>   format_warning_n_va, renamed to ...
>   (format_warning_n_va): ... this, add N and PLURAL_GMSGID arguments,
>   rename GMSGID to SINGULAR_GMSGID, if SINGULAR_GMSGID != PLURAL_GMSGID,
>   use ngettext.
>   (format_warning_at_substring_n): New function.
>   * gimple-ssa-sprintf.c: Remove GCC diagnostic ignored pragma.
>   (fmtwarn): Add ATTRIBUTE_GCC_DIAG.  Turn into a copy of
>   format_warning_at_substring with just a shorter name instead of
>   const function pointer.
>   (fmtwarn_n): New function.
>   (maybe_warn, format_directive, parse_directive): Use fmtwarn_n where
>   appropriate, get rid of all the fmtstr temporaries, move conditionals
>   with G_() wrapped string literals directly into fmtwarn arguments,
>   cast dir.len to (int), formatting fixes.
OK.
jeff

C++ PATCH for c++/84664, ICE on invalid in lambda

[Marek Polacek]

This patch fixes an ICE-on-invalid by checking the result of mark_rvalue_use,
similarly to perform_implicit_conversion_flags.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2018-03-02  Marek Polacek  

PR c++/84664
* typeck.c (cp_perform_integral_promotions): Check the result of
mark_rvalue_use.

* g++.dg/cpp0x/lambda/lambda-ice28.C: New test.

diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index 0e7c63dd197..f535902231d 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -2161,6 +2161,8 @@ cp_perform_integral_promotions (tree expr, tsubst_flags_t 
complain)
   tree promoted_type;
 
   expr = mark_rvalue_use (expr);
+  if (error_operand_p (expr))
+return error_mark_node;
 
   /* [conv.prom]
 
diff --git gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice28.C 
gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice28.C
index e69de29bb2d..5fe32129744 100644
--- gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice28.C
+++ gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice28.C
@@ -0,0 +1,9 @@
+// PR c++/84664
+// { dg-do compile { target c++11 } }
+
+void
+foo ()
+{
+  auto  = 1; // { dg-error "cannot bind" }
+  [] { b > 0; }; // { dg-error ".b. is not captured" }
+}

Marek

C++ PATCH for c++/84578, ICE when initializing flexarr

[Marek Polacek]

We ICE in cxx_eval_vec_init_1 whereby we try to initialize a flexible array
member, because the code computing the number of elements of ATYPE wasn't
prepared to handle arrays with no bounds.  Fixed by using
get_array_or_vector_nelts, broken out of existing code.

Martin suggested to reject this code, but I decided to leave this as-is for
now; we already reject code that actually tries to initialize the flexible
array member with some data, e.g.:

struct A {
  constexpr A() : i(), x("foo") {}
  int i;
  char x[];
};
A a;

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2018-03-02  Marek Polacek  

PR c++/84578
* constexpr.c (get_array_or_vector_nelts): New.
(cxx_eval_array_reference): Use it.
(cxx_eval_vec_init_1): Likewise.
(cxx_eval_store_expression): Likewise.

* g++.dg/ext/flexary29.C: New test.

diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index 39e6cdfb33d..27f841db38f 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -2300,6 +2300,32 @@ diag_array_subscript (const constexpr_ctx *ctx, tree 
array, tree index)
 }
 }
 
+/* Return the number of elements for TYPE (which is an ARRAY_TYPE or
+   a VECTOR_TYPE).  */
+
+static tree
+get_array_or_vector_nelts (const constexpr_ctx *ctx, tree type,
+  bool *non_constant_p, bool *overflow_p)
+{
+  tree nelts;
+  if (TREE_CODE (type) == ARRAY_TYPE)
+{
+  if (TYPE_DOMAIN (type))
+   nelts = array_type_nelts_top (type);
+  else
+   nelts = size_zero_node;
+}
+  else if (VECTOR_TYPE_P (type))
+nelts = size_int (TYPE_VECTOR_SUBPARTS (type));
+  else
+gcc_unreachable ();
+
+  /* For VLAs, the number of elements won't be an integer constant.  */
+  nelts = cxx_eval_constant_expression (ctx, nelts, false,
+   non_constant_p, overflow_p);
+  return nelts;
+}
+
 /* Extract element INDEX consisting of CHARS_PER_ELT chars from
STRING_CST STRING.  */
 
@@ -2379,22 +2405,8 @@ cxx_eval_array_reference (const constexpr_ctx *ctx, tree 
t,
}
 }
 
-  tree nelts;
-  if (TREE_CODE (TREE_TYPE (ary)) == ARRAY_TYPE)
-{
-  if (TYPE_DOMAIN (TREE_TYPE (ary)))
-   nelts = array_type_nelts_top (TREE_TYPE (ary));
-  else
-   nelts = size_zero_node;
-}
-  else if (VECTOR_TYPE_P (TREE_TYPE (ary)))
-nelts = size_int (TYPE_VECTOR_SUBPARTS (TREE_TYPE (ary)));
-  else
-gcc_unreachable ();
-
-  /* For VLAs, the number of elements won't be an integer constant.  */
-  nelts = cxx_eval_constant_expression (ctx, nelts, false, non_constant_p,
-   overflow_p);
+  tree nelts = get_array_or_vector_nelts (ctx, TREE_TYPE (ary), non_constant_p,
+ overflow_p);
   VERIFY_CONSTANT (nelts);
   if ((lval
? !tree_int_cst_le (index, nelts)
@@ -2895,7 +2907,6 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree 
atype, tree init,
 bool *non_constant_p, bool *overflow_p)
 {
   tree elttype = TREE_TYPE (atype);
-  unsigned HOST_WIDE_INT max = tree_to_uhwi (array_type_nelts_top (atype));
   verify_ctor_sanity (ctx, atype);
   vec **p = _ELTS (ctx->ctor);
   bool pre_init = false;
@@ -2924,6 +2935,9 @@ cxx_eval_vec_init_1 (const constexpr_ctx *ctx, tree 
atype, tree init,
   pre_init = true;
 }
 
+  tree nelts = get_array_or_vector_nelts (ctx, atype, non_constant_p,
+ overflow_p);
+  unsigned HOST_WIDE_INT max = tree_to_uhwi (nelts);
   for (i = 0; i < max; ++i)
 {
   tree idx = build_int_cst (size_type_node, i);
@@ -3480,19 +3494,8 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, 
tree t,
case ARRAY_REF:
  tree nelts, ary;
  ary = TREE_OPERAND (probe, 0);
- if (TREE_CODE (TREE_TYPE (ary)) == ARRAY_TYPE)
-   {
- if (TYPE_DOMAIN (TREE_TYPE (ary)))
-   nelts = array_type_nelts_top (TREE_TYPE (ary));
- else
-   nelts = size_zero_node;
-   }
- else if (VECTOR_TYPE_P (TREE_TYPE (ary)))
-   nelts = size_int (TYPE_VECTOR_SUBPARTS (TREE_TYPE (ary)));
- else
-   gcc_unreachable ();
- nelts = cxx_eval_constant_expression (ctx, nelts, false,
-   non_constant_p, overflow_p);
+ nelts = get_array_or_vector_nelts (ctx, TREE_TYPE (ary),
+non_constant_p, overflow_p);
  VERIFY_CONSTANT (nelts);
  gcc_assert (TREE_CODE (nelts) == INTEGER_CST
  && TREE_CODE (TREE_OPERAND (probe, 1)) == INTEGER_CST);
diff --git gcc/testsuite/g++.dg/ext/flexary29.C 
gcc/testsuite/g++.dg/ext/flexary29.C
index e69de29bb2d..a696fd9804f 100644
--- gcc/testsuite/g++.dg/ext/flexary29.C
+++ gcc/testsuite/g++.dg/ext/flexary29.C
@@ -0,0 +1,12 @@
+// PR c++/84578
+// { dg-do compile { target 

Re: [PATCH][AArch64][2/3] PR target/84164: Add ZERO_EXTRACT + LSHIFTRT pattern for BFXIL instruction

[Kyrill Tkachov]

Hi all,

I'm pinging this patch 
(https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00444.html)
now that Jeff has approved the prerequisite simplify-rtx.c change 
(https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00143.html) (thanks!)

Thanks,
Kyrill

On 08/02/18 17:10, Kyrill Tkachov wrote:

Hi all,

This is a followup to the other PR target/84164 patch [1] that fixes the 
testsuite regression
gcc.target/aarch64/bfxil_1.c.
The regression is that with the new subreg+masking simplification we no longer 
match the
pattern for BFXIL that has the form:
(set (zero_extract:DI (reg/v:DI 76 [ a ])
(const_int 8 [0x8])
(const_int 0 [0]))
(zero_extract:DI (reg/v:DI 76 [ a ])
(const_int 8 [0x8])
(const_int 16 [0x10])))

This is now instead represented as:
(set (zero_extract:DI (reg/v:DI 93 [ a ])
(const_int 8 [0x8])
(const_int 0 [0]))
(lshiftrt:DI (reg/v:DI 93 [ a ])
(const_int 16 [0x10])))

As far as I can see the two are equivalent semantically and the LSHIFTRT form 
is a bit
simpler, so I think the simplified form is valid, but we have no pattern to 
match it.
This patch adds that pattern to catch this form as well.
This fixes the aforementioned regression and bootstrap and testing on 
aarch64-none-linux-gnu
shows no problem.

Is this ok for trunk if the first patch goes in?
Thanks,
Kyrill

[1] https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00443.html

2018-02-08  Kyrylo Tkachov  

PR target/84164
* config/aarch64/aarch64.md (*extr_insv_lower_reg_lshiftrt):
New pattern.

Re: [PATCH][AArch64][1/3] PR target/84164: Simplify subreg + redundant AND-immediate

[Jeff Law]

On 03/01/2018 08:19 AM, Kyrill Tkachov wrote:
> Ping.
> 
> Thanks,
> Kyrill
> 
> On 19/02/18 11:35, Kyrill Tkachov wrote:
>> Ping.
>>
>> https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00649.html
>>
>> CC'ing Eric and Jeff as the patch contains a simplify-rtx.c component
>> that I'll need midend approval on.
>>
>> Thanks everyone for your comments so far.
>> Kyrill
>>
>> On 12/02/18 15:18, Kyrill Tkachov wrote:
>>> Hi Richard,
>>>
>>> On 08/02/18 20:29, Richard Sandiford wrote:
 Thanks for doing this.

 Kyrill  Tkachov  writes:
> diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
> index
> 2e7aa5c12952ab1a9b49b5adaf23710327e577d3..af06d7502cebac03cefc689b2646874b8397e767
> 100644
> --- a/gcc/simplify-rtx.c
> +++ b/gcc/simplify-rtx.c
> @@ -6474,6 +6474,18 @@ simplify_subreg (machine_mode outermode, rtx
> op,
>     return NULL_RTX;
>   }
>   +  /* Simplify (subreg:QI (and:SI (reg:SI) (const_int 0x)) 0)
> + into (subreg:QI (reg:SI) 0).  */
> +  scalar_int_mode int_outermode, int_innermode;
> +  if (!paradoxical_subreg_p (outermode, innermode)
> +  && is_a  (outermode, _outermode)
> +  && is_a  (innermode, _innermode)
> +  && GET_CODE (op) == AND && CONST_INT_P (XEXP (op, 1))
> +  && known_eq (subreg_lowpart_offset (outermode, innermode),
> byte)
> +  && (~INTVAL (XEXP (op, 1)) & GET_MODE_MASK (int_outermode))
> == 0
> +  && validate_subreg (outermode, innermode, XEXP (op, 0), byte))
> +    return gen_rtx_SUBREG (outermode, XEXP (op, 0), byte);
> +
>     /* A SUBREG resulting from a zero extension may fold to zero if
>    it extracts higher bits that the ZERO_EXTEND's source bits.  */
>     if (GET_CODE (op) == ZERO_EXTEND && SCALAR_INT_MODE_P (innermode))
 I think it'd be better to do this in simplify_truncation (shared
 by the subreg code and the TRUNCATE code).  The return would then
 be simplify_gen_unary (TRUNCATE, ...), which will become a subreg
 if TRULY_NOOP_TRUNCATION.
>>>
>>> Thanks, that does look cleaner.
>>> Bootstrapped and tested on arm-none-linux-gnueabihf,
>>> aarch64-none-linux-gnu and x86_64-unknown-linux-gnu.
>>> The other two patches are still needed to address the fallout.
>>>
>>> Is this ok?
>>>
>>> Thanks,
>>> Kyrill
>>>
>>> 2018-02-12  Kyrylo Tkachov  
>>>
>>>     PR target/84164
>>>     * simplify-rtx.c (simplify_truncation): Simplify truncation of
>>> masking
>>>     operation.
>>>     * config/aarch64/aarch64.md (*aarch64_reg_3_neg_mask2):
>>>     Use simplify_gen_unary creating a SUBREG.
>>>     (*aarch64_reg_3_minus_mask): Likewise.
>>>     (*aarch64__reg_di3_mask2): Use const_int_operand predicate
>>>     for operand 3.
>>>
>>> 2018-02-12  Kyrylo Tkachov  
>>>
>>>     PR target/84164
>>>     * gcc.c-torture/compile/pr84164.c: New test.
Sorry.  I suspect I dropped this from my inbox when it had the AArch64
marker -- I didn't realize it had a target independent component.

The simplify-rtx bits are fine.  The version in simplify_truncation is
much better than the original in simplify_subreg (which I think needed
to verify that you were looking at the lowpart before optimizing).

jeff
>>
> 

Re: Patch ping

[Jeff Law]

On 03/02/2018 01:17 AM, Jakub Jelinek wrote:
> Hi!
> 
> I'd like to ping 2 patches:
> 
> http://gcc.gnu.org/ml/gcc-patches/2018-02/msg01340.html
>   - PR target/84524 avx512* wrong-code bug
Hoping Kirill will chime in here.


> 
> http://gcc.gnu.org/ml/gcc-patches/2018-02/msg01337.html
>   - fix c-c++-common/Warray-bounds-2.c testcase for -fpic
OK.

jeff

Re: [C++] [PR84231] overload on cond_expr in template

[Jason Merrill]

On Fri, Mar 2, 2018 at 2:57 AM, Alexandre Oliva  wrote:
> On Feb 28, 2018, Jason Merrill  wrote:
>
>> On Wed, Feb 28, 2018 at 12:24 AM, Alexandre Oliva  wrote:
>>> +  if (processing_template_decl)
>>> +result_type = cp_build_reference_type (result_type, !is_lvalue);
>
>> If !is_lvalue, we don't want a reference type at all, as the result is
>> a prvalue.  is_lvalue should probably rename to is_glvalue.
>
> I ended up moving the above to the path in which we deal with lvalues
> and xvalues.  I still renamed the variable as suggested, though I no
> longer use it.
>
>> The second argument to cp_build_reference_type should be xvalue_p (arg2).
>
> I thought of adding a comment as to why testing just arg2 was correct,
> but then moving the code kind of made it obvious, didn't it?
>
>>> +  /* Except for type-dependent exprs, a REFERENCE_TYPE will
>>> +indicate whether its result is an lvalue or so.
>
>> "or not" ?
>
> I meant "or so" as in "or other kinds of reference values".
>
>>> +  if (processing_template_decl
>>> + && !type_dependent_expression_p (CONST_CAST_TREE (ref)))
>>> +   return clk_none;
>
>> I think we want to return clk_class for a COND_EXPR of class type.
>
> or array, like the default case, I suppose.
>
>> Can we actually get here for a type-dependent expression?  I'd think
>> we'd never get as far as asking whether a type-dependent expression is
>> an lvalue, since in general we can't answer that question.
>
> We shouldn't, indeed.  And AFAICT we don't; I've added an assert to make
> sure.
>
> [C++] [PR84231] overload on cond_expr in template
>
> A non-type-dependent COND_EXPR within a template is reconstructed with
> the original operands, after one with non-dependent proxies is built to
> determine its result type.  This is problematic because the operands of
> a COND_EXPR determined to be an rvalue may have been converted to denote
> their rvalue nature.  The reconstructed one, however, won't have such
> conversions, so lvalue_kind may not recognize it as an rvalue, which may
> lead to e.g. incorrect overload resolution decisions.
>
> If we mistake such a COND_EXPR for an lvalue, overload resolution might
> regard a conversion sequence that binds it to a non-const reference as
> viable, and then select that over one that binds it to a const
> reference.  Only after template substitution would we rebuild the
> COND_EXPR, realize it is an rvalue, and conclude the reference binding
> is ill-formed, but at that point we'd have long discarded any alternate
> candidates we could have used.
>
> This patch modifies the logic that determines whether a
> (non-type-dependent) COND_EXPR in a template is an lvalue, to rely on
> its type, more specifically, on the presence of a REFERENCE_TYPE
> wrapper.  In order to avoid a type bootstrapping problem, the
> REFERENCE_TYPE that wraps the type of some such COND_EXPRs is
> introduced earlier, so that we don't have to test for lvalueness of
> the expression using the very code that we wish to change.
>
>
> for  gcc/cp/ChangeLog
>
> PR c++/84231
> * tree.c (lvalue_kind): Use presence/absence of REFERENCE_TYPE
> only while processing template decls.
> * typeck.c (build_x_conditional_expr): Move wrapping of
> reference type around type...
> * call.c (build_conditional_expr_1): ... here.  Rename
> is_lvalue to is_glvalue.
> * parser.c (cp_parser_fold_expression): Catch REFERENCE_REF_P
> INDIRECT_REF of COND_EXPR too.
>
> for  gcc/testsuite/ChangeLog
>
> PR c++/84231
> * g++.dg/pr84231.C: New.
> ---
>  gcc/cp/call.c  |   11 +++
>  gcc/cp/parser.c|4 +++-
>  gcc/cp/tree.c  |   15 +++
>  gcc/cp/typeck.c|4 
>  gcc/testsuite/g++.dg/pr84231.C |   29 +
>  5 files changed, 54 insertions(+), 9 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/pr84231.C
>
> diff --git a/gcc/cp/call.c b/gcc/cp/call.c
> index 11fe28292fb1..6707aa2d3f02 100644
> --- a/gcc/cp/call.c
> +++ b/gcc/cp/call.c
> @@ -4782,7 +4782,7 @@ build_conditional_expr_1 (location_t loc, tree arg1, 
> tree arg2, tree arg3,
>tree arg3_type;
>tree result = NULL_TREE;
>tree result_type = NULL_TREE;
> -  bool is_lvalue = true;
> +  bool is_glvalue = true;
>struct z_candidate *candidates = 0;
>struct z_candidate *cand;
>void *p;
> @@ -5037,7 +5037,7 @@ build_conditional_expr_1 (location_t loc, tree arg1, 
> tree arg2, tree arg3,
>   return error_mark_node;
> }
>
> -  is_lvalue = false;
> +  is_glvalue = false;
>goto valid_operands;
>  }
>/* [expr.cond]
> @@ -5155,6 +5155,9 @@ build_conditional_expr_1 (location_t loc, tree arg1, 
> tree arg2, tree arg3,
>&& same_type_p (arg2_type, arg3_type))
>  {
>result_type = arg2_type;
> +  if 

Re: [PATCH] Fix PR84427, PRE ANTIC iteration (again)

[Jeff Law]

On 03/01/2018 06:57 AM, Richard Biener wrote:
> 
> This fixes another testcase that shows that our ANTIC iteration can
> fail to converge.  The fix continues what we did with previous fixes,
> avoid spuriously removing stuff from the expression side of the sets.
> This time going full-in and allowing multiple expressions for the
> same value in the sets.  I've added verification that the value-sets
> never grow during iteration which barfed on some of the related
> existing testcases and thus helped finishing this and fixing all
> places where we end up somewhat randomly choosing one or another
> expression to drop.
> 
> I've verified with a GIMPLE testcase that if at insertion time
> we have multiple partially redundant expressions for the same value
> we insert/hoist it only once.  So the only "bad" effect of the
> patch is that the expression part of the ANTIC sets grows -- by
> not throwing away random stuff we might also arrive at larger
> (value) solutions for ANTIC which means we may catch previously
> missed optimizations (or pessimizations as you know PRE...).
> 
> I'm not entirely happy with the timing but I'm quite confident in
> the approach also (again) having heavily discussed this with Micha.
> 
> Re-boostrap and regtest running on x86_64-unknown-linux-gnu.
> 
> I managed to go into a different solution at the beginning asking
> for that pred/phiblock->edge cleanup and decided to leave that in...
> 
> The new verification is guarded with flag_checking so if it would
> trigger but wouldn't result in not converging a release build
> should be not affected.
> 
> Richard.
> 
> 2018-01-03  Richard Biener  
> 
>   PR tree-optimization/84427
>   * tree-ssa-pre.c (bitmap_remove_expr_from_set): Remove.
>   (bitmap_set_subtract_values): Rewrite to handle multiple
>   exprs per value.
>   (clean): Likewise.
>   (prune_clobbered_mems): Likewise.
>   (phi_translate): Take edge instead of pred/phiblock.
>   (phi_translate_1): Likewise.
>   (phi_translate_set): Likewise.  Insert all translated
>   exprs for a value into the set, keeping possibly multiple
>   expressions per value.
>   (compute_antic_aux): Adjust for phi_translate changes.
>   When intersecting union the expressions and prune those
>   not in the final value set, keeping possibly multiple
>   expressions per value.  Do not use value-insertion
>   for unioning ANTIC_OUT U EXP_GEN - TMP_GEN but merge
>   all expressions.  Add verification that the value-sets
>   only shrink during iteration.
>   (compute_partial_antic_aux): Adjust for the phi_translate changes.
>   (do_pre_regular_insertion): Likewise.
>   (do_pre_partial_partial_insertion): Likewise.
> 
>   * gcc.dg/torture/pr84427.c: New testcase.
It looks like Zdenek has already filed a report against this change.
I'll wait for resolution on that before reducing the various linux
kernel build failures.

jeff

Re: [PATCH][OBVIOUS] Fix ifunc detection.

[Jeff Law]

On 03/02/2018 10:00 AM, Jakub Jelinek wrote:
> On Fri, Mar 02, 2018 at 09:55:22AM -0700, Jeff Law wrote:
>> On 03/02/2018 09:38 AM, Thomas Schwinge wrote:
>>> Hi!
>>>
>>> On Fri, 26 Jan 2018 16:24:48 +0100, Martin Liška  wrote:
 This fixes detection of ifunc target capability.
 I'm going to install the patch.
>>>
>>> You could also just have approved the patch I had sent two months before:
>>> .
>>> ;-)
>>>
>>> One remark:
>>>
 --- a/gcc/testsuite/lib/target-supports.exp
 +++ b/gcc/testsuite/lib/target-supports.exp
 @@ -449,7 +449,7 @@ proc check_ifunc_available { } {
extern "C" {
#endif
typedef void F (void);
 -  F* g (void) {}
 +  F* g (void) { return 0; }
void f () __attribute__ ((ifunc ("g")));
#ifdef __cplusplus
}
>>>
>>> Is it OK to "return 0" from this ifunc handler, or might some analysis in
>>> GCC trip over that (at some later point)?  In my patch, I returned the
>>> address of an "extern" function.
>> ISTM the question is whether or not ifuncs are ever allowed to return
>> NULL.  Maybe ping the glibc folks since that's where the extension started?
> 
> Returning NULL means immediate segfault if somebody tries to call that
> function.
I understand that.  I'm referring to the semantic definition of an
ifunc.  It's an extension and we ought to have a crisp definition of
whether or not it can return NULL.

THe fact that returning NULL will cause the vast majority of systems to
segfault isn't the issue.  The issue is how have we defined the extension.

jeff

Re: [PATCH] Fix ICE caused by a missing check for DECL_LANG_SPECIFIC

[Jason Merrill]

On Fri, Mar 2, 2018 at 8:25 AM, Matthew Fortune  wrote:
> Jason Merrill  writes:
>> On Thu, Mar 1, 2018 at 7:02 AM, Matthew Fortune 
>> wrote:
>> > Hi,
>> >
>> > It seems we have had a bug for some time that causes an ICE and
>> prevents the
>> > MIPS16 library builds from completing but is likely unrelated to
>> MIPS16.
>> > The problem is when we call target_reinit and library functions get
>> created
>> > as shown in the call stack at the end of this message. The first
>> builtin
>> > that triggers the problem happens to be one of the MIPS16 helpers but
>> I
>> > don't think there is anything unique about it. The issue appeared
>> after some
>> > refactoring work in r253600 where code testing DECL_CLASS_SCOPE_P and
>> > DECL_FRIEND_P was previously guarded by a check for
>> DECL_LANG_SPECIFIC but
>> > not after.
>> >
>> > https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00604.html
>> >
>> > I don’t know if this is the correct solution or whether we need to
>> change the
>> > way builtins are initialised in the MIPS backend but I suspect this
>> fix
>> > is the right way to go.
>> >
>> > Cc: Jason as author of the original change.
>> >
>> > Thanks,
>> > Matthew
>> >
>> > gcc/cp/
>> > * pt.c (type_dependent_expression_p): Add missing check for
>> > DECL_LANG_SPECIFIC.
>> > ---
>> >  gcc/cp/pt.c | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
>> > index 7345119..c88304f 100644
>> > --- a/gcc/cp/pt.c
>> > +++ b/gcc/cp/pt.c
>> > @@ -24635,6 +24635,7 @@ type_dependent_expression_p (tree expression)
>> >   type-dependent.  Checking this is important for functions with
>> auto return
>> >   type, which looks like a dependent type.  */
>> >if (TREE_CODE (expression) == FUNCTION_DECL
>> > +  && DECL_LANG_SPECIFIC (expression)
>> >&& !(DECL_CLASS_SCOPE_P (expression)
>> >&& dependent_type_p (DECL_CONTEXT (expression)))
>> >&& !(DECL_FRIEND_P (expression)
>>
>> I think we want to go into this block when DECL_LANG_SPECIFIC is NULL.
>> Does this also fix the issue for you?
>
> Thanks. Yes, this fixes it too. I wasn't sure which of the accessors were
> dependent on DECL_LANG_SPECIFIC so ended up with a sledgehammer.

Applied.

Jason

Re: [PATCH][OBVIOUS] Fix ifunc detection.

[H.J. Lu]

On Fri, Mar 2, 2018 at 8:55 AM, Jeff Law  wrote:
> On 03/02/2018 09:38 AM, Thomas Schwinge wrote:
>> Hi!
>>
>> On Fri, 26 Jan 2018 16:24:48 +0100, Martin Liška  wrote:
>>> This fixes detection of ifunc target capability.
>>> I'm going to install the patch.
>>
>> You could also just have approved the patch I had sent two months before:
>> .
>> ;-)
>>
>> One remark:
>>
>>> --- a/gcc/testsuite/lib/target-supports.exp
>>> +++ b/gcc/testsuite/lib/target-supports.exp
>>> @@ -449,7 +449,7 @@ proc check_ifunc_available { } {
>>>  extern "C" {
>>>  #endif
>>>  typedef void F (void);
>>> -F* g (void) {}
>>> +F* g (void) { return 0; }
>>>  void f () __attribute__ ((ifunc ("g")));
>>>  #ifdef __cplusplus
>>>  }
>>
>> Is it OK to "return 0" from this ifunc handler, or might some analysis in
>> GCC trip over that (at some later point)?  In my patch, I returned the
>> address of an "extern" function.
> ISTM the question is whether or not ifuncs are ever allowed to return
> NULL.  Maybe ping the glibc folks since that's where the extension started?

No, ifunc selector should never return NULL.

-- 
H.J.

Re: [PATCH][OBVIOUS] Fix ifunc detection.

[Jeff Law]

On 03/02/2018 09:38 AM, Thomas Schwinge wrote:
> Hi!
> 
> On Fri, 26 Jan 2018 16:24:48 +0100, Martin Liška  wrote:
>> This fixes detection of ifunc target capability.
>> I'm going to install the patch.
> 
> You could also just have approved the patch I had sent two months before:
> .
> ;-)
> 
> One remark:
> 
>> --- a/gcc/testsuite/lib/target-supports.exp
>> +++ b/gcc/testsuite/lib/target-supports.exp
>> @@ -449,7 +449,7 @@ proc check_ifunc_available { } {
>>  extern "C" {
>>  #endif
>>  typedef void F (void);
>> -F* g (void) {}
>> +F* g (void) { return 0; }
>>  void f () __attribute__ ((ifunc ("g")));
>>  #ifdef __cplusplus
>>  }
> 
> Is it OK to "return 0" from this ifunc handler, or might some analysis in
> GCC trip over that (at some later point)?  In my patch, I returned the
> address of an "extern" function.
ISTM the question is whether or not ifuncs are ever allowed to return
NULL.  Maybe ping the glibc folks since that's where the extension started?

jeff

[og7] vector_length extension part 2: Generalize state propagation and synchronization

[Cesar Philippidis]

The attached patch generalizes the worker state propagation and
synchronization code to handle large vectors. When the vector_length is
larger than a CUDA warp, the nvptx BE will now use shared-memory to
spill-and-fill vector state when transitioning from vector-single mode
to vector partitioned.

In addition, nvptx_cta_sync and the corresponding nvptx_barsync insn,
have been extended to take a barrier ID and a thread count. The idea
here is to assign one barrier for each logical vector. Worker-single
synchronization is controlled by barrier 0. Therefore, the vector
barrier ID is set to tid.y+1 (because there's one vector unit per
worker) in nvptx_init_oacc_workers and placed into a register stored in
cfun->machine->sync_bar. If no workers are present, then the barrier ID
falls back to 0.

As a follow up patch will show, the nvptx BE falls back to using
vector_length = 32 when a vector loop is nested inside a worker loop.
This is because I observed that the PTX JIT does not reliable generate
SASS code to keep warps convergent in large vectors. While it works for
99% of the libgomp test cases, the ones that fail usually deadlock
because the PTX JIT generates BRA instructions for the vector code
instead of SSY/SYNC. At this point, I'm not sure if the nvptx is
generating back code, or if there is a bug in the PTX JIT. Hopefully,
Volta's warp sync functionality will resolve this problem regardless.

These changes are relatively straightforward and noncontroversial. I'll
commit this patch to openacc-gcc-7-branch once the other patches are
ready. There will be three more patches in this series.

Cesar
2018-03-02  Cesar Philippidis  

	gcc/
	* config/nvptx/nvptx.c (oacc_bcast_partition): Declare.
	(nvptx_init_axis_predicate): Initialize vector_red_partition.
	(nvptx_init_oacc_workers): New function.
	(nvptx_declare_function_name): Emit a .maxntid directive hint and
	call nvptx_init_oacc_workers.
	(MACH_VECTOR_LENGTH, MACH_MAX_WORKERS): Define.
	(nvptx_mach_max_workers): New function.
	(nvptx_mach_vector_length): New function.
	(nvptx_needs_shared_bcast): New function.
	(nvptx_find_par): Generalize to enable vectors to use shared-memory
	to propagate state.
	(nvptx_shared_propagate): Iniitalize vector bcast partition and
	synchronization state.
	(nvptx_cta_sync): Change arguments to take in a lock and thread count.
	Update call to gen_nvptx_barsync.
	(nvptx_single):  Generalize to enable vectors to use shared-memory
	to propagate state.
	(nvptx_process_pars): Likewise.
	(populate_offload_attrs): Handle the situation where the default
	runtime geometry has not been initialized yet for reductions.
	(nvptx_reorg): Set function-specific axis_dim's.
	* config/nvptx/nvptx.h (struct machine_function): Add axis_dims,
	bcast_partition, red_partition and sync_bar members.
	* config/nvptx/nvptx.md (nvptx_barsync): Adjust operands.

>From 0a1dd1d85e47feeaa6f7a2e070baba69dadea444 Mon Sep 17 00:00:00 2001
From: Cesar Philippidis 
Date: Fri, 2 Mar 2018 07:39:25 -0800
Subject: [PATCH] bar and sync

---
 gcc/config/nvptx/nvptx.c  | 226 --
 gcc/config/nvptx/nvptx.h  |   8 ++
 gcc/config/nvptx/nvptx.md |  10 +-
 3 files changed, 214 insertions(+), 30 deletions(-)

diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 9d77176c638..507c8671704 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -133,6 +133,7 @@ static GTY((cache)) hash_table *needed_fndecls_htab;
memory.  It'd be nice if PTX supported common blocks, because then
this could be shared across TUs (taking the largest size).  */
 static unsigned oacc_bcast_size;
+static unsigned oacc_bcast_partition;
 static unsigned oacc_bcast_align;
 static GTY(()) rtx oacc_bcast_sym;
 
@@ -1104,8 +1105,53 @@ nvptx_init_axis_predicate (FILE *file, int regno, const char *name)
 {
   fprintf (file, "\t{\n");
   fprintf (file, "\t\t.reg.u32\t%%%s;\n", name);
-  fprintf (file, "\t\tmov.u32\t%%%s, %%tid.%s;\n", name, name);
+  if (strcmp (name, "x") == 0 && cfun->machine->red_partition)
+{
+  fprintf (file, "\t\t.reg.u64\t%%t_red;\n");
+  fprintf (file, "\t\t.reg.u64\t%%y64;\n");
+}
+  fprintf (file, "\t\tmov.u32\t\t%%%s, %%tid.%s;\n", name, name);
   fprintf (file, "\t\tsetp.ne.u32\t%%r%d, %%%s, 0;\n", regno, name);
+  if (strcmp (name, "x") == 0 && cfun->machine->red_partition)
+{
+  fprintf (file, "\t\tcvt.u64.u32\t%%y64, %%tid.y;\n");
+  fprintf (file, "\t\tcvta.shared.u64\t%%t_red, __vector_red;\n");
+  fprintf (file, "\t\tmad.lo.u64\t%%r%d, %%y64, %d, %%t_red; "
+	   "// vector reduction buffer\n",
+	   REGNO (cfun->machine->red_partition),
+	   vector_red_partition);
+}
+  fprintf (file, "\t}\n");
+}
+
+/* Emit code to initialize OpenACC worker broadcast and synchronization
+   registers.  */
+
+static void
+nvptx_init_oacc_workers (FILE *file)
+{
+  fprintf (file, "\t{\n");
+  fprintf (file, 

Re: [wwwdocs] Release notes for SVE

[Jeff Law]

On 03/02/2018 09:49 AM, Richard Sandiford wrote:
> This patch updates the release notes to mention SVE.  OK to install?
OK.
jeff

[wwwdocs] Release notes for SVE

[Richard Sandiford]

This patch updates the release notes to mention SVE.  OK to install?

Thanks,
Richard

Index: wwwdocs/htdocs/gcc-8/changes.html
===
--- wwwdocs.orig/htdocs/gcc-8/changes.html
+++ wwwdocs/htdocs/gcc-8/changes.html
@@ -243,7 +243,18 @@ a work-in-progress.
   +sha3 New SHA3 and SHA2 instructions from Armv8.4-A.  
This implies +sha2.
   +sm4 New SM3 and SM4 instructions from Armv8.4-A.
 
- 
+  
+  
+The Scalable Vector Extension (SVE) is now supported as an
+optional extension to the Armv8.2-A architecture and newer.
+This support includes automatic vectorization with SVE instructions,
+but it does not yet include the SVE Arm C Language Extensions (ACLE).
+It can be enabled by specifying the +sve architecture
+extension (for example, -march=armv8.2-a+sve).
+By default, the generated code works with all vector lengths,
+but it can be made specific to N-bit vectors using
+-msve-vector-bits=N.
+  
   
Support has been added for the following processors
(GCC identifiers in parentheses):

[committed] Fix unnecessary -Wnarrowing warning in predict.c

[Jakub Jelinek]

Hi!

branch_predictor::probability has int type, so using -1U produces
-Wnarrowing warning.

Fixed thusly, committed as obvious to trunk.

2018-03-02  Jakub Jelinek  

* predict.c (test_prediction_value_range): Use PROB_UNINITIALIZED
instead of -1U in last predictors element's probability member.

--- gcc/predict.c.jj2018-01-26 12:43:25.139922494 +0100
+++ gcc/predict.c   2018-03-02 15:24:21.735715210 +0100
@@ -4204,7 +4204,7 @@ test_prediction_value_range ()
 {
   branch_predictor predictors[] = {
 #include "predict.def"
-{NULL, -1U}
+{ NULL, PROB_UNINITIALIZED }
   };
 
   for (unsigned i = 0; predictors[i].name != NULL; i++)

Jakub

Re: [C++ PATCH] Fix C++ ICE due to CONVERT_EXPR of error_mark_node (PR c++/84662)

[Nathan Sidwell]

On 03/02/2018 11:25 AM, Jakub Jelinek wrote:

Hi!

Various spots in the FE don't really like if error_mark_node is deeply
embedded in expression operands, in this case tsubst_copy_and_build
creates CONVERT_EXPR  on which
is_bitfield_expr_with_lowered_type ICEs.

Fixed by just returning error_mark_node (various other spots in
tsubst_copy_and_build do the same).

While at it, I've discovered 3 spots in the function which were using
return instead of RETURN and thus wouldn't properly restore input_location;
I wonder if eventually this shouldn't be done through some sentinel class
where the destructor would restore input_location and just use return
instead of RETURN.

Anyway, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?


ok, thanks

nathan


--
Nathan Sidwell

Re: [PATCH] Fix PR84427, PRE ANTIC iteration (again)

[Jeff Law]

On 03/01/2018 06:57 AM, Richard Biener wrote:
> 
> This fixes another testcase that shows that our ANTIC iteration can
> fail to converge.  The fix continues what we did with previous fixes,
> avoid spuriously removing stuff from the expression side of the sets.
> This time going full-in and allowing multiple expressions for the
> same value in the sets.  I've added verification that the value-sets
> never grow during iteration which barfed on some of the related
> existing testcases and thus helped finishing this and fixing all
> places where we end up somewhat randomly choosing one or another
> expression to drop.
> 
> I've verified with a GIMPLE testcase that if at insertion time
> we have multiple partially redundant expressions for the same value
> we insert/hoist it only once.  So the only "bad" effect of the
> patch is that the expression part of the ANTIC sets grows -- by
> not throwing away random stuff we might also arrive at larger
> (value) solutions for ANTIC which means we may catch previously
> missed optimizations (or pessimizations as you know PRE...).
> 
> I'm not entirely happy with the timing but I'm quite confident in
> the approach also (again) having heavily discussed this with Micha.
> 
> Re-boostrap and regtest running on x86_64-unknown-linux-gnu.
> 
> I managed to go into a different solution at the beginning asking
> for that pred/phiblock->edge cleanup and decided to leave that in...
> 
> The new verification is guarded with flag_checking so if it would
> trigger but wouldn't result in not converging a release build
> should be not affected.
> 
> Richard.
> 
> 2018-01-03  Richard Biener  
> 
>   PR tree-optimization/84427
>   * tree-ssa-pre.c (bitmap_remove_expr_from_set): Remove.
>   (bitmap_set_subtract_values): Rewrite to handle multiple
>   exprs per value.
>   (clean): Likewise.
>   (prune_clobbered_mems): Likewise.
>   (phi_translate): Take edge instead of pred/phiblock.
>   (phi_translate_1): Likewise.
>   (phi_translate_set): Likewise.  Insert all translated
>   exprs for a value into the set, keeping possibly multiple
>   expressions per value.
>   (compute_antic_aux): Adjust for phi_translate changes.
>   When intersecting union the expressions and prune those
>   not in the final value set, keeping possibly multiple
>   expressions per value.  Do not use value-insertion
>   for unioning ANTIC_OUT U EXP_GEN - TMP_GEN but merge
>   all expressions.  Add verification that the value-sets
>   only shrink during iteration.
>   (compute_partial_antic_aux): Adjust for the phi_translate changes.
>   (do_pre_regular_insertion): Likewise.
>   (do_pre_partial_partial_insertion): Likewise.
> 
>   * gcc.dg/torture/pr84427.c: New testcase.
Note most of my testers are failing with:


during GIMPLE pass: pre
../net/packet/af_packet.c: In function 'packet_setsockopt':
../net/packet/af_packet.c:3611:1: internal compiler error: in
compute_antic_aux, at tree-ssa-pre.c:2148
 packet_setsockopt(struct socket *sock, int level, int optname, char
__user *optval, unsigned int optlen)
 ^
0xdfdb02 compute_antic_aux
../../../gcc/gcc/tree-ssa-pre.c:2148
0xdfdb02 compute_antic
../../../gcc/gcc/tree-ssa-pre.c:2364
0xdfdb02 execute
../../../gcc/gcc/tree-ssa-pre.c:4131


aarch, alpha, arm, nios, s390, riscv, mips, hppa, microblaze, i686,
powerpc.  On a positive note, sh seems unaffected :-)

I'll try to get a testcase extracted.

jeff

Re: [patch] remove cilk-plus

[Jeff Law]

On 03/02/2018 09:36 AM, Thomas Schwinge wrote:
> Hi!
> 
> On Thu, 16 Nov 2017 15:33:40 +, "Koval, Julia"  
> wrote:
>> Hi, this patch removes cilkplus.
> 
> I noticed a few remaining bits, that I convinced myself are obvious
> enough; committed to trunk in r258141:
> 
> commit bd571ec47012c4ee50ef028024276ab02f5c15ec
> Author: tschwinge 
> Date:   Fri Mar 2 16:35:26 2018 +
> 
> More Cilk Plus removal
> 
> contrib/
> * update-copyright.py: Remove "libcilkrts" reference.
> gcc/c-family/
> * c-attribs.c (c_common_attribute_table): Remove "cilk simd
> function".
> gcc/
> * doc/invoke.texi: Remove "Cilk Plus" references.
Thanks.  Yea, this certainly qualifies as obvious :-)

jeff

Re: [PATCH] libiberty: fix URL for demangler ABI

[Jeff Law]

On 03/02/2018 09:44 AM, David Malcolm wrote:
> The comment at the top of cp-demangle.c lists:
>   http://www.codesourcery.com/cxx-abi/abi.html#mangling
> which redirects to:
>   https://mentorembedded.github.io/cxx-abi/abi.html#mangling
> but this is a 404: the latter site is empty.
> 
> I looked on archive.org; the final version before the redirect
> seems to be:
>   
> https://web.archive.org/web/20110903075217/http://www.codesourcery.com:80/public/cxx-abi/abi.html
> 
> Some searching showed up:
>   https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling
> 
> I don't know how canonical this page is, but:
>   https://itanium-cxx-abi.github.io/cxx-abi/
> has "Revised March 14, 2017", which seems relatively up-to-date, so this
> patch updates the comment to point to that site.
> 
> OK for trunk?
> 
> libiberty/ChangeLog:
>   * cp-demangle.c: Update URL for g++ V3 ABI.
OK.
jeff

[PATCH] libiberty: fix URL for demangler ABI

[David Malcolm]

The comment at the top of cp-demangle.c lists:
  http://www.codesourcery.com/cxx-abi/abi.html#mangling
which redirects to:
  https://mentorembedded.github.io/cxx-abi/abi.html#mangling
but this is a 404: the latter site is empty.

I looked on archive.org; the final version before the redirect
seems to be:
  
https://web.archive.org/web/20110903075217/http://www.codesourcery.com:80/public/cxx-abi/abi.html

Some searching showed up:
  https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling

I don't know how canonical this page is, but:
  https://itanium-cxx-abi.github.io/cxx-abi/
has "Revised March 14, 2017", which seems relatively up-to-date, so this
patch updates the comment to point to that site.

OK for trunk?

libiberty/ChangeLog:
* cp-demangle.c: Update URL for g++ V3 ABI.
---
 libiberty/cp-demangle.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index 1d5b855..3f2a097 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -30,7 +30,7 @@
 
 /* This code implements a demangler for the g++ V3 ABI.  The ABI is
described on this web page:
-   http://www.codesourcery.com/cxx-abi/abi.html#mangling
+   https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling
 
This code was written while looking at the demangler written by
Alex Samuel .
-- 
1.8.5.3

Re: [PATCH][OBVIOUS] Fix ifunc detection.

[Thomas Schwinge]

Hi!

On Fri, 26 Jan 2018 16:24:48 +0100, Martin Liška  wrote:
> This fixes detection of ifunc target capability.
> I'm going to install the patch.

You could also just have approved the patch I had sent two months before:
.
;-)

One remark:

> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -449,7 +449,7 @@ proc check_ifunc_available { } {
>   extern "C" {
>   #endif
>   typedef void F (void);
> - F* g (void) {}
> + F* g (void) { return 0; }
>   void f () __attribute__ ((ifunc ("g")));
>   #ifdef __cplusplus
>   }

Is it OK to "return 0" from this ifunc handler, or might some analysis in
GCC trip over that (at some later point)?  In my patch, I returned the
address of an "extern" function.


Grüße
 Thomas

Re: [PATCH] Fix test-suite fallout of default -Wreturn-type.

[Thomas Schwinge]

Hi!

On Mon, 20 Nov 2017 09:11:19 -0500, Jason Merrill  wrote:
> On Sun, Nov 19, 2017 at 7:56 AM, Thomas Schwinge
>  wrote:
> > OK to fix the first four issues as follows?
> 
> OK.
> 
> Reviewed-by: Jason Merrill 

Better late than never, committed to trunk in r258142:

commit 0e793314b12e82e8a70971e509572d67b773
Author: tschwinge 
Date:   Fri Mar 2 16:35:36 2018 +

Fix "dg-lto-options" misuse

gcc/testsuite/
* g++.dg/lto/20080915_0.C: Don't use "dg-lto-options".
* g++.dg/lto/20080907_0.C: Use "#pragma GCC" instead of
"dg-lto-options".
* g++.dg/lto/20101010-1_0.C: Likewise.
* g++.dg/lto/20101010-2_0.C: Likewise.

Reviewed-by: Jason Merrill 

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@258142 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/testsuite/ChangeLog | 8 
 gcc/testsuite/g++.dg/lto/20080907_0.C   | 4 +++-
 gcc/testsuite/g++.dg/lto/20080915_0.C   | 1 -
 gcc/testsuite/g++.dg/lto/20101010-1_0.C | 4 +++-
 gcc/testsuite/g++.dg/lto/20101010-2_0.C | 4 +++-
 5 files changed, 17 insertions(+), 4 deletions(-)

diff --git gcc/testsuite/ChangeLog gcc/testsuite/ChangeLog
index 84ebf2e..3864204 100644
--- gcc/testsuite/ChangeLog
+++ gcc/testsuite/ChangeLog
@@ -1,3 +1,11 @@
+2018-03-02  Thomas Schwinge  
+
+   * g++.dg/lto/20080915_0.C: Don't use "dg-lto-options".
+   * g++.dg/lto/20080907_0.C: Use "#pragma GCC" instead of
+   "dg-lto-options".
+   * g++.dg/lto/20101010-1_0.C: Likewise.
+   * g++.dg/lto/20101010-2_0.C: Likewise.
+
 2018-03-02  Jakub Jelinek  
 
PR ipa/84628
diff --git gcc/testsuite/g++.dg/lto/20080907_0.C 
gcc/testsuite/g++.dg/lto/20080907_0.C
index a423196..153d0ab 100644
--- gcc/testsuite/g++.dg/lto/20080907_0.C
+++ gcc/testsuite/g++.dg/lto/20080907_0.C
@@ -1,5 +1,7 @@
 // { dg-lto-do assemble }
-// { dg-lto-options "-Wno-return-type" }
+
+/* "WARNING: lto.exp does not support dg-additional-options" */
+#pragma GCC diagnostic ignored "-Wreturn-type"
 
 struct Foo { void func (); }; Foo & bar () { } struct Baz { Baz (Baz &); };
 Baz dummy() { bar().func(); }
diff --git gcc/testsuite/g++.dg/lto/20080915_0.C 
gcc/testsuite/g++.dg/lto/20080915_0.C
index 40c5042..c91e756 100644
--- gcc/testsuite/g++.dg/lto/20080915_0.C
+++ gcc/testsuite/g++.dg/lto/20080915_0.C
@@ -1,5 +1,4 @@
 // { dg-lto-do assemble }
-// { dg-lto-options "-Wno-return-type" }
 
 struct Foo {
  static const int dummy;
diff --git gcc/testsuite/g++.dg/lto/20101010-1_0.C 
gcc/testsuite/g++.dg/lto/20101010-1_0.C
index 8f694c7..bb3e6d4 100644
--- gcc/testsuite/g++.dg/lto/20101010-1_0.C
+++ gcc/testsuite/g++.dg/lto/20101010-1_0.C
@@ -1,5 +1,7 @@
 // { dg-lto-do link }
-// { dg-lto-options "-Wno-return-type" }
+
+/* "WARNING: lto.exp does not support dg-additional-options" */
+#pragma GCC diagnostic ignored "-Wreturn-type"
 
 typedef long size_t;
 template < class, class > struct pair
diff --git gcc/testsuite/g++.dg/lto/20101010-2_0.C 
gcc/testsuite/g++.dg/lto/20101010-2_0.C
index a26956f..721ac01 100644
--- gcc/testsuite/g++.dg/lto/20101010-2_0.C
+++ gcc/testsuite/g++.dg/lto/20101010-2_0.C
@@ -1,5 +1,7 @@
 // { dg-lto-do link }
-// { dg-lto-options "-Wno-return-type" }
+
+/* "WARNING: lto.exp does not support dg-additional-options" */
+#pragma GCC diagnostic ignored "-Wreturn-type"
 
 typedef int size_t;
 template < size_t _Nw > struct _Base_bitset


Grüße
 Thomas

Re: [patch] remove cilk-plus

[Thomas Schwinge]

Hi!

On Thu, 16 Nov 2017 15:33:40 +, "Koval, Julia"  
wrote:
> Hi, this patch removes cilkplus.

I noticed a few remaining bits, that I convinced myself are obvious
enough; committed to trunk in r258141:

commit bd571ec47012c4ee50ef028024276ab02f5c15ec
Author: tschwinge 
Date:   Fri Mar 2 16:35:26 2018 +

More Cilk Plus removal

contrib/
* update-copyright.py: Remove "libcilkrts" reference.
gcc/c-family/
* c-attribs.c (c_common_attribute_table): Remove "cilk simd
function".
gcc/
* doc/invoke.texi: Remove "Cilk Plus" references.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@258141 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 contrib/ChangeLog   | 4 
 contrib/update-copyright.py | 3 +--
 gcc/ChangeLog   | 4 
 gcc/c-family/ChangeLog  | 5 +
 gcc/c-family/c-attribs.c| 2 --
 gcc/doc/invoke.texi | 4 ++--
 6 files changed, 16 insertions(+), 6 deletions(-)

diff --git contrib/ChangeLog contrib/ChangeLog
index 627cafd..6bb3b6f 100644
--- contrib/ChangeLog
+++ contrib/ChangeLog
@@ -1,3 +1,7 @@
+2018-03-02  Thomas Schwinge  
+
+   * update-copyright.py: Remove "libcilkrts" reference.
+
 2018-02-19  Yury Gribov  
 
* compare_tests: Use TMPDIR when set.
diff --git contrib/update-copyright.py contrib/update-copyright.py
index 85be1e1..9295c6b 100755
--- contrib/update-copyright.py
+++ contrib/update-copyright.py
@@ -1,6 +1,6 @@
 #!/usr/bin/python
 #
-# Copyright (C) 2013-2017 Free Software Foundation, Inc.
+# Copyright (C) 2013-2018 Free Software Foundation, Inc.
 #
 # This script is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -708,7 +708,6 @@ class GCCCmdLine (CmdLine):
 self.add_dir ('libatomic')
 self.add_dir ('libbacktrace')
 self.add_dir ('libcc1')
-# libcilkrts is imported from upstream.
 self.add_dir ('libcpp', LibCppFilter())
 self.add_dir ('libdecnumber')
 # libffi is imported from upstream.
diff --git gcc/ChangeLog gcc/ChangeLog
index 447d563..662b72f 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,7 @@
+2018-03-02  Thomas Schwinge  
+
+   * doc/invoke.texi: Remove "Cilk Plus" references.
+
 2018-03-02  Jakub Jelinek  
Richard Biener  
 
diff --git gcc/c-family/ChangeLog gcc/c-family/ChangeLog
index c10b7bf..27cc43e 100644
--- gcc/c-family/ChangeLog
+++ gcc/c-family/ChangeLog
@@ -1,3 +1,8 @@
+2018-03-02  Thomas Schwinge  
+
+   * c-attribs.c (c_common_attribute_table): Remove "cilk simd
+   function".
+
 2018-03-01  Marek Polacek  
 
PR c++/84639
diff --git gcc/c-family/c-attribs.c gcc/c-family/c-attribs.c
index 3ebb2d6..cebc0b2 100644
--- gcc/c-family/c-attribs.c
+++ gcc/c-family/c-attribs.c
@@ -439,8 +439,6 @@ const struct attribute_spec c_common_attribute_table[] =
  handle_returns_nonnull_attribute, NULL },
   { "omp declare simd",   0, -1, true,  false, false, false,
  handle_omp_declare_simd_attribute, NULL },
-  { "cilk simd function", 0, -1, true,  false, false, false,
- handle_omp_declare_simd_attribute, NULL },
   { "simd",  0, 1, true,  false, false, false,
  handle_simd_attribute, NULL },
   { "omp declare target", 0, 0, true, false, false, false,
diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
index 8d366c6..ad0fec6 100644
--- gcc/doc/invoke.texi
+++ gcc/doc/invoke.texi
@@ -6710,7 +6710,7 @@ Requires @option{-flto-odr-type-merging} to be enabled.  
Enabled by default.
 
 @item -Wopenmp-simd
 @opindex Wopenm-simd
-Warn if the vectorizer cost model overrides the OpenMP or the Cilk Plus
+Warn if the vectorizer cost model overrides the OpenMP
 simd directive set by user.  The @option{-fsimd-cost-model=unlimited}
 option can be used to relax the cost model.
 
@@ -8953,7 +8953,7 @@ either @samp{dynamic} or @samp{cheap}.
 @item -fsimd-cost-model=@var{model}
 @opindex fsimd-cost-model
 Alter the cost model used for vectorization of loops marked with the OpenMP
-or Cilk Plus simd directive.  The @var{model} argument should be one of
+simd directive.  The @var{model} argument should be one of
 @samp{unlimited}, @samp{dynamic}, @samp{cheap}.  All values of @var{model}
 have the same meaning as described in @option{-fvect-cost-model} and by
 default a cost model defined with @option{-fvect-cost-model} is used.


Grüße
 Thomas

[C++ PATCH] Fix C++ ICE due to CONVERT_EXPR of error_mark_node (PR c++/84662)

[Jakub Jelinek]

Hi!

Various spots in the FE don't really like if error_mark_node is deeply
embedded in expression operands, in this case tsubst_copy_and_build
creates CONVERT_EXPR  on which
is_bitfield_expr_with_lowered_type ICEs.

Fixed by just returning error_mark_node (various other spots in
tsubst_copy_and_build do the same).

While at it, I've discovered 3 spots in the function which were using
return instead of RETURN and thus wouldn't properly restore input_location;
I wonder if eventually this shouldn't be done through some sentinel class
where the destructor would restore input_location and just use return
instead of RETURN.

Anyway, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-03-02  

PR c++/84662
* pt.c (tsubst_copy_and_build) : Use
RETURN instead of return.
: Likewise.
: If op0 is error_mark_node, just return
it instead of wrapping it into CONVERT_EXPR.

* g++.dg/cpp1y/pr84662.C: New test.

--- gcc/cp/pt.c.jj  2018-03-02 00:15:54.097781049 +0100
+++ gcc/cp/pt.c 2018-03-02 12:30:38.127232430 +0100
@@ -17318,14 +17318,14 @@ tsubst_copy_and_build (tree t,
if (targs)
  targs = tsubst_template_args (targs, args, complain, in_decl);
if (targs == error_mark_node)
- return error_mark_node;
+ RETURN (error_mark_node);
 
if (TREE_CODE (templ) == SCOPE_REF)
  {
tree name = TREE_OPERAND (templ, 1);
tree tid = lookup_template_function (name, targs);
TREE_OPERAND (templ, 1) = tid;
-   return templ;
+   RETURN (templ);
  }
 
if (variable_template_p (templ))
@@ -17401,6 +17401,8 @@ tsubst_copy_and_build (tree t,
   {
tree type = tsubst (TREE_TYPE (t), args, complain, in_decl);
tree op0 = RECUR (TREE_OPERAND (t, 0));
+   if (op0 == error_mark_node)
+ RETURN (error_mark_node);
RETURN (build1 (CONVERT_EXPR, type, op0));
   }
 
@@ -17549,7 +17551,7 @@ tsubst_copy_and_build (tree t,
   {
tree op0 = RECUR (TREE_OPERAND (t, 0));
tree op1 = RECUR (TREE_OPERAND (t, 1));
-   return fold_build_pointer_plus (op0, op1);
+   RETURN (fold_build_pointer_plus (op0, op1));
   }
 
 case SCOPE_REF:
--- gcc/testsuite/g++.dg/cpp1y/pr84662.C.jj 2018-03-02 12:32:23.012209212 
+0100
+++ gcc/testsuite/g++.dg/cpp1y/pr84662.C2018-03-02 12:32:59.159201202 
+0100
@@ -0,0 +1,6 @@
+// PR c++/84662
+// { dg-do compile { target c++14 } }
+// { dg-options "" }
+
+double b;
+a (__attribute__((c (0 && int() - ([] {} && b) || auto;// { dg-error 
"expected constructor, destructor, or type conversion before" }

Jakub

Re: [PATCH] Fix combiner move_deaths DEBUG_INSN handling (PR target/84614)

[Jeff Law]

On 03/01/2018 04:13 PM, Jakub Jelinek wrote:
> Hi!
> 
> prev_real_insn doesn't skip over DEBUG_INSNs, on aarch64 on this
> testcase we get both -fcompare-debug failure and wrong-code with -g.
> 
> Instead of adding yet another two:
>   do
> insn = prev_real_insn (insn);
>   while (DEBUG_INSN_P (insn));
> loops, this patch introduces new functions that stop only at
> NONDEBUG_INSN_P.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, tested with
> cross to aarch64-linux on the testcase, ok for trunk?
> 
> 2018-03-02  Jakub Jelinek  
> 
>   PR target/84614
>   * rtl.h (prev_real_nondebug_insn, next_real_nondebug_insn): New
>   prototypes.
>   * emit-rtl.c (next_real_insn, prev_real_insn): Fix up function
>   comments.
>   (next_real_nondebug_insn, prev_real_nondebug_insn): New functions.
>   * cfgcleanup.c (try_head_merge_bb): Use prev_real_nondebug_insn
>   instead of a loop around prev_real_insn.
>   * combine.c (move_deaths): Use prev_real_nondebug_insn instead of
>   prev_real_insn.
> 
>   * gcc.dg/pr84614.c: New test.
THanks.  We're going to need the {next,prev}_real_nondebug_insn routines
in reorg/resource as well.  MIPS can't currently build a linux kernel
because we fail all over the place with DEBUG_INSNs within reorg.

I've got a patch that's enough to get mips to bootstrap and build
kernels, but haven't posted it yet.

jeff

Re: [PATCH] [Microblaze]: PIC Data Text Relative

[Andrew Sadek]

Hello Michael,

I tried running the whole GCC test suite on the current head (without my
patch) along with 'microblaze-qemu' but I have the following problems:

1) The test is hanging at 'gcc.c-torture/string-large-1.c' , the gcc is
making a 100% CPU usage and the machine stucks.
I tried compiling the file alone, it generated a couple of warnings than it
hangs.
 warning: '__builtin_memchr' specified size 4294967295 exceeds maximum
object size 2147483647 [-Wstringop-overflow=]
   vp1 = __builtin_memchr (a, b, SIZE1);

Is it a bug? Is there something wrong with my configuration ?
GCC configured with options :  --with-newlib --enable-threads=no
--disable-shared --with-pkgversion='crosstool-NG
crosstool-ng-1.23.0-280-g01e3290' --enable-__cxa_atexit --disable-libgomp
--disable-libmudflap --disable-libmpx --disable-libssp
--disable-libquadmath --disable-libquadmath-support --enable-lto
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--enable-target-optspace --disable-nls --enable-multiarch
--enable-languages=c,c++

2) For running QEMU, I have no problem with elf execution. But I do not
know how to auto terminate the QEMU itself  as it remains up even after
program execution.
Is there some command to be passed to QEMU in order make system shut down
after program termination with its exit code ?


On Tue, Feb 27, 2018 at 10:13 AM, Andrew Sadek 
wrote:

> Thanks Micheal for your response.
> I shall re-submit patches separately after re-running the whole GCC Test
> suite and re-checking code conventions.
> For sending to gdb-patches, it was a conflict from my side as actually I
> thought it is also for binutils.
>
> On Tue, Feb 27, 2018 at 2:07 AM, Michael Eager  wrote:
>
>> On 02/25/2018 11:44 PM, Andrew Guirguis wrote:
>>
>>> Dears,
>>>
>>> Kindly find attached the patch bundle for Microblaze
>>> '-mpic-data-text-relative' feature.
>>>
>>> Description of the feature in the following link:
>>> https://github.com/andrewsadek/microblaze-pic-data-text-rel/
>>> blob/pic_data_text_rel/README.md >> k/microblaze-pic-data-text-rel/blob/pic_data_text_rel/README.md>
>>>
>>> Bundle includes:
>>> 1) Change logs for GCC, binutils
>>> 2) GCC Test results and comparison with the original.
>>> 3) New Test case (picdtr.c)
>>> 4) The Patches (against current heads)
>>>
>>
>> Hi Andrew --
>>
>> Thanks for the submission.  I have the following recommendations:
>>
>> Submit each patch to the appropriate project mailing list.  Only submit
>> the patch for the specific project, without patches for other projects.
>>
>> Include a description of the changes with each patch as well as the
>> changelog.  Include the patch in your email or as an attachment.
>>
>> It isn't clear why you sent your submission to the gdb-patches mailing
>> list, since there don't appear to be any GDB changes.  Conversely, it is
>> not clear why you did not include the binutils mailing list, since you
>> include a patch to that project.
>>
>> Be sure to follow GNU coding conventions,  Check brace placement,
>> indent, maximum line length, if statements, etc.  I noticed a number
>> of places where these conventions are not followed in your patches.
>>
>> GCC regression tests should include all tests (e.g., gcc.dg), not just
>> the limited number of MicroBlaze-specific tests.
>>
>> --
>> Michael Eagerea...@eagerm.com
>> 1960 Park Blvd., Palo Alto, CA 94306
>>
>
>
>
> --
>
> Andrew
>



-- 

Andrew

Re: [PATCH] Predefine __SIZEOF_{FPREG,FLOAT{80,128}}__ on ia64 (PR target/56540)

[Jeff Law]

On 03/02/2018 08:04 AM, Jakub Jelinek wrote:
> Hi!
> 
> GCC predefines __SIZEOF_*__ macros for the types it provides, so that
> 1) one can easily test if those types are available
> 2) can use it even in places where sizeof is not usable, like preprocessor
>conditionals
> Unfortunately, this isn't done for target types that the middle-end doesn't
> know about.  On x86 __SIZEOF_FLOAT128__=16 and __SIZEOF_FLOAT80__={16,12}
> are already predefined.  For consistency and above reasons it would be nice
> to do the same on ia64, hppa and powerpc* too.
> 
> Tested with a cross to ia64 on the testcase, ok for trunk?
> 
> 2018-03-02  Jakub Jelinek  
> 
>   PR target/56540
>   * config/ia64/ia64.h (TARGET_CPU_CPP_BUILTINS): Predefine
>   __SIZEOF_{FPREG,FLOAT{80,128}}__ macros.
> 
>   * gcc.target/ia64/pr56540.c: New test.
OK.
jeff

Re: [PATCH] Predefine __SIZEOF_FLOAT128__ on hppa hpux (PR target/56540)

[Jeff Law]

On 03/02/2018 08:07 AM, Jakub Jelinek wrote:
> Hi!
> 
> Similarly to the ia64 patch, on hppa __float128 seems to be conditionally
> provided (guarded with HPUX_LONG_DOUBLE_LIBRARY), so this patch also
> conditionally predefines __SIZEOF_FLOAT128__.
> 
> Ok for trunk?
> 
> 2018-03-02  Jakub Jelinek  
> 
>   PR target/56540
>   * config/pa/pa.h (TARGET_CPU_CPP_BUILTINS): Predefine
>   __SIZEOF_128__ macro if HPUX_LONG_DOUBLE_LIBRARY.
OK.
jeff

[PR c++/84497] ref to undefined tls init

[Nathan Sidwell]

Jason, Jakub,
I've simplified the testcase Padraig provided and attached it to 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84497


Notice that 'Base::Base ()' is not a constexpr ctor, because the integer 
member is not initialized.  That means 10.1.4/4.5 is unsatisfied.  So 
struct Base gets its 'has_constexpr' flag set via the Base::Base (int) 
ctor.  struct Derived is not so lucky, and 'has_constexpr' is unset.


Thus we end up with an unsatisfied strong reference to _ZTH11derived_obj

NEEDS_CONSTRUCTING && !HAS_CONSTEXPR_CTOR is insufficient to determine 
whether there must be an init fn.


While the patch does indeed work, it may be too pessimal, making the 
reference weak in more cases than necessary.


NEEDS_CONSTRUCTING && !HAS_CONSTEXPR_CTOR && !HAS_DEFAULT_CONSTRUCTOR 
seems like it would be sufficient. and indeed that works in this case.


WDYT?

nathan

--
Nathan Sidwell

[PATCH] Predefine __SIZEOF_{FPREG,FLOAT{80,128}}__ on ia64 (PR target/56540)

[Jakub Jelinek]

Hi!

GCC predefines __SIZEOF_*__ macros for the types it provides, so that
1) one can easily test if those types are available
2) can use it even in places where sizeof is not usable, like preprocessor
   conditionals
Unfortunately, this isn't done for target types that the middle-end doesn't
know about.  On x86 __SIZEOF_FLOAT128__=16 and __SIZEOF_FLOAT80__={16,12}
are already predefined.  For consistency and above reasons it would be nice
to do the same on ia64, hppa and powerpc* too.

Tested with a cross to ia64 on the testcase, ok for trunk?

2018-03-02  Jakub Jelinek  

PR target/56540
* config/ia64/ia64.h (TARGET_CPU_CPP_BUILTINS): Predefine
__SIZEOF_{FPREG,FLOAT{80,128}}__ macros.

* gcc.target/ia64/pr56540.c: New test.

--- gcc/config/ia64/ia64.h.jj   2018-01-03 10:20:09.144536194 +0100
+++ gcc/config/ia64/ia64.h  2018-03-02 15:12:44.006654878 +0100
@@ -38,6 +38,9 @@ do {  \
builtin_define("__itanium__");  \
if (TARGET_BIG_ENDIAN)  \
  builtin_define("__BIG_ENDIAN__"); \
+   builtin_define("__SIZEOF_FPREG__=16");  \
+   builtin_define("__SIZEOF_FLOAT80__=16");\
+   builtin_define("__SIZEOF_FLOAT128__=16");\
 } while (0)
 
 #ifndef SUBTARGET_EXTRA_SPECS
--- gcc/testsuite/gcc.target/ia64/pr56540.c.jj  2018-03-02 15:28:20.464781858 
+0100
+++ gcc/testsuite/gcc.target/ia64/pr56540.c 2018-03-02 15:30:12.728813200 
+0100
@@ -0,0 +1,6 @@
+/* PR target/56540 */
+/* { dg-do compile } */
+
+extern int a[__SIZEOF_FPREG__ != sizeof (__fpreg) ? -1 : 1];
+extern int b[__SIZEOF_FLOAT80__ != sizeof (__float80) ? -1 : 1];
+extern int c[__SIZEOF_FLOAT128__ != sizeof (__float128) ? -1 : 1];

Jakub

[PATCH] Fix ICF with error/warning attribute (PR ipa/84628, take 3)

[Jakub Jelinek]

Hi!

On Fri, Mar 02, 2018 at 10:54:36AM +0100, Jakub Jelinek wrote:
> On Fri, Mar 02, 2018 at 09:31:16AM +0100, Richard Biener wrote:
> > On Fri, 2 Mar 2018, Jakub Jelinek wrote:
> > 
> > > On Fri, Mar 02, 2018 at 09:15:07AM +0100, Richard Biener wrote:
> > > > You probably need a virtual return thunk as otherwise we expand them
> > > > directly to asm?
> > > 
> > > I was trying x86_64 -m32 -fpic regparm (3) method with thunks so that
> > > the asm isn't emitted.  But the thunk was still using call to .LTHUNKN
> > > rather than the actual method FUNCTION_DECL.  Perhaps on targets without
> > > proper alias support...
> > > 
> > > > > Would you prefer just being silent in all thunks?
> > > > 
> > > > Yes, I think all warnings from thunks are ultimately going to be 
> > > > bogus...
> > > 
> > > Ok, I'll change the patch.
> 
> Unfortunately it doesn't work, see patch below.

But this works, ok if it passes bootstrap/regtest?

2018-03-02  Jakub Jelinek  
Richard Biener  

PR ipa/84628
* expr.c (expand_expr_real_1) : Don't emit diagnostics
for error or warning attributes if CALL_FROM_THUNK_P is set.
Formatting fixes.

* gcc.dg/pr84628.c: New test.

--- gcc/expr.c.jj   2018-02-09 19:11:29.094068531 +0100
+++ gcc/expr.c  2018-03-02 11:12:19.299665926 +0100
@@ -10963,18 +10963,30 @@ expand_expr_real_1 (tree exp, rtx target
tree fndecl = get_callee_fndecl (exp), attr;
 
if (fndecl
+   /* Don't diagnose the error attribute in thunks, those are
+  artificially created.  */
+   && !CALL_FROM_THUNK_P (exp)
&& (attr = lookup_attribute ("error",
 DECL_ATTRIBUTES (fndecl))) != NULL)
- error ("%Kcall to %qs declared with attribute error: %s",
-exp, identifier_to_locale (lang_hooks.decl_printable_name 
(fndecl, 1)),
-TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
+ {
+   const char *ident = lang_hooks.decl_printable_name (fndecl, 1);
+   error ("%Kcall to %qs declared with attribute error: %s", exp,
+  identifier_to_locale (ident),
+  TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
+ }
if (fndecl
+   /* Don't diagnose the warning attribute in thunks, those are
+  artificially created.  */
+   && !CALL_FROM_THUNK_P (exp)
&& (attr = lookup_attribute ("warning",
 DECL_ATTRIBUTES (fndecl))) != NULL)
- warning_at (tree_nonartificial_location (exp),
- 0, "%Kcall to %qs declared with attribute warning: %s",
- exp, identifier_to_locale (lang_hooks.decl_printable_name 
(fndecl, 1)),
- TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
+ {
+   const char *ident = lang_hooks.decl_printable_name (fndecl, 1);
+   warning_at (tree_nonartificial_location (exp), 0,
+   "%Kcall to %qs declared with attribute warning: %s",
+   exp, identifier_to_locale (ident),
+   TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
+ }
 
/* Check for a built-in function.  */
if (fndecl && DECL_BUILT_IN (fndecl))
--- gcc/testsuite/gcc.dg/pr84628.c.jj   2018-03-02 10:24:08.975815667 +0100
+++ gcc/testsuite/gcc.dg/pr84628.c  2018-03-02 10:24:08.975815667 +0100
@@ -0,0 +1,8 @@
+/* PR ipa/84628 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int f0 (void);
+__attribute__((error ("err"))) void f1 (void) { f0 (); f0 (); }
+__attribute__((error ("err"))) void f2 (void) { f0 (); f0 (); }
+/* { dg-bogus "declared with attribute error" "" { target *-*-* } 0 } */


Jakub

[PATCH] Predefine __SIZEOF_FLOAT128__ on hppa hpux (PR target/56540)

[Jakub Jelinek]

Hi!

Similarly to the ia64 patch, on hppa __float128 seems to be conditionally
provided (guarded with HPUX_LONG_DOUBLE_LIBRARY), so this patch also
conditionally predefines __SIZEOF_FLOAT128__.

Ok for trunk?

2018-03-02  Jakub Jelinek  

PR target/56540
* config/pa/pa.h (TARGET_CPU_CPP_BUILTINS): Predefine
__SIZEOF_128__ macro if HPUX_LONG_DOUBLE_LIBRARY.

--- gcc/config/pa/pa.h.jj   2018-01-17 11:54:19.035804335 +0100
+++ gcc/config/pa/pa.h  2018-03-02 15:34:11.080879742 +0100
@@ -177,6 +177,8 @@ do {
\
builtin_define("_PA_RISC1_1");  \
  else  \
builtin_define("_PA_RISC1_0");  \
+ if (HPUX_LONG_DOUBLE_LIBRARY) \
+   builtin_define("__SIZEOF_FLOAT128__=16");   \
 } while (0)
 
 /* An old set of OS defines for various BSD-like systems.  */

Jakub

RE: [patch][i386] Adding pconfig, wbnoinvd and wbinvd intrinsics

[Makhotina, Olga]

Hi,

I have made changes to this patch.
I attached a new version.

02.03.2018  Olga Makhotina  

gcc/
* common/config/i386/i386-common.c (OPTION_MASK_ISA_PCONFIG_SET,
OPTION_MASK_ISA_PCONFIG_UNSET, OPTION_MASK_ISA_WBNOINVD_SET,
OPTION_MASK_ISA_WBNOINVD_UNSET): New definitions.
(ix86_handle_option): Handle -mpconfig and -mwbnoinvd.
* config.gcc (pconfigintrin.h, wbnoinvdintrin.h) : Add headers.
* config/i386/cpuid.h (bit_PCONFIG, bit_WBNOINVD): New.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect -mpconfig
and -mwbnoinvd.
* config/i386/i386-builtin.def (__builtin_ia32_wbnoinvd,
__builtin_ia32_wbinvd): New builtins.
(SPECIAL_ARGS2): New.
* config/i386/i386-c.c (__WBNOINVD__, __PCONFIG__): New.
(SPECIAL_ARGS2): New.
* config/i386/i386.c (ix86_target_string): Add -mpconfig and -mwbnoinvd.
(ix86_valid_target_attribute_inner_p): Ditto.
(ix86_init_mmx_sse_builtins): Add special_args2.
* config/i386/i386.h (TARGET_PCONFIG, TARGET_PCONFIG_P, TARGET_WBNOINVD,
TARGET_WBNOINVD_P): New.
* config/i386/i386.md (UNSPECV_WBINVD, UNSPECV_WBNOINVD): New.
(define_insn "wbinvd", define_insn "wbnoinvd"): New.
* config/i386/i386.opt: Add -mpconfig and -mwbnoinvd.
* config/i386/immintrin.h (_wbinvd): New intrinsic.
* config/i386/pconfigintrin.h: New file.
* config/i386/wbnoinvdintrin.h: Ditto.
* config/i386/x86intrin.h: Add headers pconfigintrin.h and 
wbnoinvdintrin.h.
* doc/invoke.texi (-mpconfig, -mwbnoinvd): New.

gcc/testsuite/
* g++.dg/other/i386-2.C: Add -mpconfig and -mwbnoinvd.
* g++.dg/other/i386-3.C: Ditto.
* gcc.target/i386/sse-12.c: Ditto.
* gcc.target/i386/sse-13.c: Ditto.
* gcc.target/i386/sse-14.c: Ditto.
* gcc.target/i386/sse-23.c: Add pconfig and wbnoinvd.
* gcc.target/i386/wbinvd-1.c: New test.
* gcc.target/i386/wbnoinvd-1.c: Ditto.
* gcc.target/i386/pconfig-1.c: Ditto.   

Is it ok for trunk?

Thanks, Olga.

-Original Message-
From: Uros Bizjak [mailto:ubiz...@gmail.com] 
Sent: Tuesday, February 6, 2018 10:51 AM
To: gcc-patches@gcc.gnu.org
Cc: Makhotina, Olga ; Kirill Yukhin 

Subject: Re: [patch][i386] Adding pconfig, wbnoinvd and wbinvd intrinsics

> This patch adds new intrinsics: pconfig, wbnoinvd and wbinvd.
>
> 05.02.2018  Olga Makhotina  
>
> gcc/
> * common/config/i386/i386-common.c (OPTION_MASK_ISA_PCONFIG_SET, 
> OPTION_MASK_ISA_PCONFIG_UNSET, OPTION_MASK_ISA_WBNOINVD_SET,
> OPTION_MASK_ISA_WBNOINVD_UNSET): New definitions.
> (ix86_handle_option): Handle -mpconfig and -mwbnoinvd.
> * config.gcc (pconfigintrin.h, wbnoinvdintrin.h) : Add headers.
> * config/i386/cpuid.h (bit_PCONFIG, bit_WBNOINVD): New.
> * config/i386/driver-i386.c (host_detect_local_cpu): Detect -mpconfig 
> and -mwbnoinvd.
> * config/i386/i386-builtin.def (__builtin_ia32_wbnoinvd,
> __builtin_ia32_wbinvd): New builtins.
> (SPECIAL_ARGS2): New.
> * config/i386/i386-c.c (__WBNOINVD__, __PCONFIG__): New.
> (SPECIAL_ARGS2): New.
> * config/i386/i386.c (ix86_target_string): Add -mpconfig and -mwbnoinvd.
> (ix86_valid_target_attribute_inner_p): Ditto.
> (ix86_init_mmx_sse_builtins): Add special_args2.
> * config/i386/i386.h (TARGET_PCONFIG, TARGET_PCONFIG_P, 
> TARGET_WBNOINVD,
> TARGET_WBNOINVD_P): New.
> * config/i386/i386.md (UNSPECV_WBINVD, UNSPECV_WBNOINVD): New.
> (define_insn "wbinvd", define_insn "wbnoinvd"): New.
> * config/i386/i386.opt: Add -mpconfig and -mwbnoinvd.
> * config/i386/immintrin.h (_wbinvd): New intrinsic.
> * config/i386/sgxintrin.h (_enclv_u32): Ditto.
> * config/i386/pconfigintrin.h: New file.
> * config/i386/wbnoinvdintrin.h: Ditto.
> * config/i386/x86intrin.h: Add headers pconfigintrin.h and wbnoinvdintrin.h.
> * doc/invoke.texi (-mpconfig, -mwbnoinvd): New.
>
> gcc/testsuite/
> * g++.dg/other/i386-2.C: Add -mpconfig and -mwbnoinvd.
> * g++.dg/other/i386-3.C: Ditto.
> * gcc.target/i386/sse-12.c: Ditto.
> * gcc.target/i386/sse-13.c: Ditto.
> * gcc.target/i386/sse-14.c: Ditto.
> * gcc.target/i386/sgx.c (_enclv_u32): New tests.
> * gcc.target/i386/sse-23.c: Add pconfig and wbnoinvd.
> * gcc.target/i386/wbinvd-1.c: New test.
> * gcc.target/i386/wbnoinvd-1.c: Ditto.
> * gcc.target/i386/pconfig-1.c: Ditto.
>
> Is it ok for trunk?

Please split out SGX changes to a separate patch.

OK for mainline with the above change.

Thanks,
Uros.


0001-wbnoinvd_pconfig.patch
Description: 0001-wbnoinvd_pconfig.patch

Re: Don't vectorise zero-step rmw operations (PR 84485)

[Richard Sandiford]

Richard Biener  writes:
> On Thu, Mar 1, 2018 at 12:38 PM, Richard Sandiford
>  wrote:
>> Richard Biener  writes:
>>> On Wed, Feb 28, 2018 at 3:20 PM, Richard Sandiford
>>>  wrote:
 GCC 6 and 7 would vectorise:

 void
 f (unsigned long incx, unsigned long incy,
float *restrict dx, float *restrict dy)
 {
   unsigned long ix = 0, iy = 0;
   for (unsigned long i = 0; i < 512; ++i)
 {
   dy[iy] += dx[ix];
   ix += incx;
   iy += incy;
 }
 }

 without first proving that incy is nonzero.  This is a regression from
 GCC 5.  It was fixed on trunk in r223486, which versioned the loop based
 on whether incy is zero, but that's obviously too invasive to backport.
 This patch instead bails out for non-constant steps in the place that
 trunk would try a check for zeroness.

 I did wonder about trying to use range information to prove nonzeroness
 for SSA_NAMEs, but that would be entirely new code and didn't seem
 suitable for a release branch.

 Tested on aarch64-linux-gnu.  OK for GCC 7 and 6?  I'll add the testcase
 to trunk too.
>>>
>>> Given dist == 0 isn't it enough to test either DR_STEP (dra) or
>>> DR_STEP (drb)?
>>> That seems what trunk is doing (just look at dr_zero_step_indicator of dra).
>>> Even when not using range-info I think that using !
>>> tree_expr_nonzero_p (DR_STEP (dra))
>>> is more to the point of the issue we're fixing -- that also would catch
>>> integer_zerop (DR_STEP (dra)) which trunk handles by failing as well but 
>>> your
>>> patch wouldn't so it looks like a more "complete" fix.
>>
>> OK.
>>
>>> Last but not least trunk and your patch guards all this by
>>> !loop->force_vectorize.
>>> But force_vectorize doesn't give any such guarantee that step isn't
>>> zero so I wonder
>>> why we deliberately choose to possibly miscompile stuff here?
>>
>> This was based on the pre-existing:
>>
>>   if (loop_vinfo && integer_zerop (step))
>> {
>>   GROUP_FIRST_ELEMENT (vinfo_for_stmt (stmt)) = NULL;
>>   if (!nested_in_vect_loop_p (loop, stmt))
>> return DR_IS_READ (dr);
>>   /* Allow references with zero step for outer loops marked
>>  with pragma omp simd only - it guarantees absence of
>>  loop-carried dependencies between inner loop iterations.  */
>>   if (!loop->force_vectorize)
>> {
>>   if (dump_enabled_p ())
>> dump_printf_loc (MSG_NOTE, vect_location,
>>  "zero step in inner loop of nest\n");
>>   return false;
>> }
>> }
>>
>> AIUI #pragma omp simd really does guarantee that iterations of
>> the loop can be executed concurrently (up to the limit given by
>> safelen if present).  So something like:
>>
>>   #pragma omp simd
>>   for (int i = 0; i < n; ++i)
>> a[i * step] += 1;
>>
>> would be incorrect for step==0.  (#pragma ordered simd forces
>> things to be executed in order where necessary.)
>
> But then we should check safelen, not force_vectorize...

OK.  Following on from irc, this version uses expr_not_equal_to
instead of tree_expr_nonzero_p.  It also adds safelen to the existing
use of force_vectorize (which seemed safer than replacing it).

Tested on aarch64-linux-gnu.  OK to install?

Richard


2018-02-28  Richard Sandiford  

gcc/
PR tree-optimization/84485
* tree-vect-data-refs.c (vect_analyze_data_ref_dependence): Return
true for zero dependence distances if the step might be zero,
and if there is no metadata that guarantees correctness.
(vect_analyze_data_ref_access): Check safelen as well as
force_vectorize.

gcc/testsuite/
PR tree-optimization/84485
* gcc.dg/vect/pr84485.c: New test.

Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c   2018-02-28 14:19:22.326678337 +
+++ gcc/tree-vect-data-refs.c   2018-03-02 13:28:06.339321095 +
@@ -394,6 +394,16 @@ vect_analyze_data_ref_dependence (struct
}
}
 
+ unsigned int step_prec = TYPE_PRECISION (TREE_TYPE (DR_STEP (dra)));
+ if (loop->safelen < 2
+ && !expr_not_equal_to (DR_STEP (dra), wi::zero (step_prec)))
+   {
+ if (dump_enabled_p ())
+   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+"step could be zero.\n");
+ return true;
+   }
+
  continue;
}
 
@@ -2515,7 +2525,7 @@ vect_analyze_data_ref_access (struct dat
   /* Allow references with zero step for outer loops marked
 with pragma omp simd only - it guarantees absence of
 loop-carried dependencies between inner loop iterations.  */
-  if 

RE: [PATCH] Fix ICE caused by a missing check for DECL_LANG_SPECIFIC

[Matthew Fortune]

Jason Merrill  writes:
> On Thu, Mar 1, 2018 at 7:02 AM, Matthew Fortune 
> wrote:
> > Hi,
> >
> > It seems we have had a bug for some time that causes an ICE and
> prevents the
> > MIPS16 library builds from completing but is likely unrelated to
> MIPS16.
> > The problem is when we call target_reinit and library functions get
> created
> > as shown in the call stack at the end of this message. The first
> builtin
> > that triggers the problem happens to be one of the MIPS16 helpers but
> I
> > don't think there is anything unique about it. The issue appeared
> after some
> > refactoring work in r253600 where code testing DECL_CLASS_SCOPE_P and
> > DECL_FRIEND_P was previously guarded by a check for
> DECL_LANG_SPECIFIC but
> > not after.
> >
> > https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00604.html
> >
> > I don’t know if this is the correct solution or whether we need to
> change the
> > way builtins are initialised in the MIPS backend but I suspect this
> fix
> > is the right way to go.
> >
> > Cc: Jason as author of the original change.
> >
> > Thanks,
> > Matthew
> >
> > gcc/cp/
> > * pt.c (type_dependent_expression_p): Add missing check for
> > DECL_LANG_SPECIFIC.
> > ---
> >  gcc/cp/pt.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> > index 7345119..c88304f 100644
> > --- a/gcc/cp/pt.c
> > +++ b/gcc/cp/pt.c
> > @@ -24635,6 +24635,7 @@ type_dependent_expression_p (tree expression)
> >   type-dependent.  Checking this is important for functions with
> auto return
> >   type, which looks like a dependent type.  */
> >if (TREE_CODE (expression) == FUNCTION_DECL
> > +  && DECL_LANG_SPECIFIC (expression)
> >&& !(DECL_CLASS_SCOPE_P (expression)
> >&& dependent_type_p (DECL_CONTEXT (expression)))
> >&& !(DECL_FRIEND_P (expression)
> 
> I think we want to go into this block when DECL_LANG_SPECIFIC is NULL.
> Does this also fix the issue for you?

Thanks. Yes, this fixes it too. I wasn't sure which of the accessors were
dependent on DECL_LANG_SPECIFIC so ended up with a sledgehammer. 

Matthew

Re: [PATCH] Fix ICF with error/warning attribute (PR ipa/84628, take 3)

[Richard Biener]

On Fri, 2 Mar 2018, Jakub Jelinek wrote:

> Hi!
> 
> On Fri, Mar 02, 2018 at 10:54:36AM +0100, Jakub Jelinek wrote:
> > On Fri, Mar 02, 2018 at 09:31:16AM +0100, Richard Biener wrote:
> > > On Fri, 2 Mar 2018, Jakub Jelinek wrote:
> > > 
> > > > On Fri, Mar 02, 2018 at 09:15:07AM +0100, Richard Biener wrote:
> > > > > You probably need a virtual return thunk as otherwise we expand them
> > > > > directly to asm?
> > > > 
> > > > I was trying x86_64 -m32 -fpic regparm (3) method with thunks so that
> > > > the asm isn't emitted.  But the thunk was still using call to .LTHUNKN
> > > > rather than the actual method FUNCTION_DECL.  Perhaps on targets without
> > > > proper alias support...
> > > > 
> > > > > > Would you prefer just being silent in all thunks?
> > > > > 
> > > > > Yes, I think all warnings from thunks are ultimately going to be 
> > > > > bogus...
> > > > 
> > > > Ok, I'll change the patch.
> > 
> > Unfortunately it doesn't work, see patch below.
> 
> But this works, ok if it passes bootstrap/regtest?

Ok.

Thanks,
Richard.

> 2018-03-02  Jakub Jelinek  
>   Richard Biener  
> 
>   PR ipa/84628
>   * expr.c (expand_expr_real_1) : Don't emit diagnostics
>   for error or warning attributes if CALL_FROM_THUNK_P is set.
>   Formatting fixes.
> 
>   * gcc.dg/pr84628.c: New test.
> 
> --- gcc/expr.c.jj 2018-02-09 19:11:29.094068531 +0100
> +++ gcc/expr.c2018-03-02 11:12:19.299665926 +0100
> @@ -10963,18 +10963,30 @@ expand_expr_real_1 (tree exp, rtx target
>   tree fndecl = get_callee_fndecl (exp), attr;
>  
>   if (fndecl
> + /* Don't diagnose the error attribute in thunks, those are
> +artificially created.  */
> + && !CALL_FROM_THUNK_P (exp)
>   && (attr = lookup_attribute ("error",
>DECL_ATTRIBUTES (fndecl))) != NULL)
> -   error ("%Kcall to %qs declared with attribute error: %s",
> -  exp, identifier_to_locale (lang_hooks.decl_printable_name 
> (fndecl, 1)),
> -  TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
> +   {
> + const char *ident = lang_hooks.decl_printable_name (fndecl, 1);
> + error ("%Kcall to %qs declared with attribute error: %s", exp,
> +identifier_to_locale (ident),
> +TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
> +   }
>   if (fndecl
> + /* Don't diagnose the warning attribute in thunks, those are
> +artificially created.  */
> + && !CALL_FROM_THUNK_P (exp)
>   && (attr = lookup_attribute ("warning",
>DECL_ATTRIBUTES (fndecl))) != NULL)
> -   warning_at (tree_nonartificial_location (exp),
> -   0, "%Kcall to %qs declared with attribute warning: %s",
> -   exp, identifier_to_locale (lang_hooks.decl_printable_name 
> (fndecl, 1)),
> -   TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
> +   {
> + const char *ident = lang_hooks.decl_printable_name (fndecl, 1);
> + warning_at (tree_nonartificial_location (exp), 0,
> + "%Kcall to %qs declared with attribute warning: %s",
> + exp, identifier_to_locale (ident),
> + TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
> +   }
>  
>   /* Check for a built-in function.  */
>   if (fndecl && DECL_BUILT_IN (fndecl))
> --- gcc/testsuite/gcc.dg/pr84628.c.jj 2018-03-02 10:24:08.975815667 +0100
> +++ gcc/testsuite/gcc.dg/pr84628.c2018-03-02 10:24:08.975815667 +0100
> @@ -0,0 +1,8 @@
> +/* PR ipa/84628 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +int f0 (void);
> +__attribute__((error ("err"))) void f1 (void) { f0 (); f0 (); }
> +__attribute__((error ("err"))) void f2 (void) { f0 (); f0 (); }
> +/* { dg-bogus "declared with attribute error" "" { target *-*-* } 0 } */
> 
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: [PATCH] Fix ICF with error/warning attribute (PR ipa/84628)

[Jakub Jelinek]

On Fri, Mar 02, 2018 at 09:31:16AM +0100, Richard Biener wrote:
> On Fri, 2 Mar 2018, Jakub Jelinek wrote:
> 
> > On Fri, Mar 02, 2018 at 09:15:07AM +0100, Richard Biener wrote:
> > > You probably need a virtual return thunk as otherwise we expand them
> > > directly to asm?
> > 
> > I was trying x86_64 -m32 -fpic regparm (3) method with thunks so that
> > the asm isn't emitted.  But the thunk was still using call to .LTHUNKN
> > rather than the actual method FUNCTION_DECL.  Perhaps on targets without
> > proper alias support...
> > 
> > > > Would you prefer just being silent in all thunks?
> > > 
> > > Yes, I think all warnings from thunks are ultimately going to be bogus...
> > 
> > Ok, I'll change the patch.

Unfortunately it doesn't work, see patch below.

The cgraph code unhelpfully clears the thunk.thunk_p bit very early, in
cgraph_node::expand_thunk:
  /* Since we want to emit the thunk, we explicitly mark its name as
 referenced.  */
  thunk.thunk_p = false;
  lowered = true;
  bitmap_obstack_release (NULL);
and afterwards it is not possible to find out it is a thunk.
Honza, could we have some other bit which would tell us if a cgraph node is
a thunk that would stay until expansion?

> > > > That said, wonder about thunks (the non-ICF ones) from false-negative
> > > > diagnostic point as well, if I have some method with error/warning 
> > > > attribute
> > > > and call a thunk instead, wonder if we get the diagnostic or not, thunks
> > > > likely don't have the attribute copied over to them.
> > > 
> > > True...
> > > 
> > > I guess we should not warn from thunks but instead move those attributes
> > > to the thunks so see if those get called in the end.
> > 
> > Or in the expr.c code look through thunks to find the underlying function
> > and take DECL_ARGUMENTS from there.
> 
> If that's easily possible that sounds good as well of course.

It isn't possible, due to the same reason as above, plus also expand_thunk
clearing thunk.thunk_p for the asm thunks too:
  targetm.asm_out.output_mi_thunk (asm_out_file, thunk_fndecl,
   fixed_offset, virtual_value, alias);

  assemble_end_function (thunk_fndecl, fnname);
  insn_locations_finalize ();
  init_insn_lengths ();
  free_after_compilation (cfun);
  TREE_ASM_WRITTEN (thunk_fndecl) = 1;
  thunk.thunk_p = false;

A testcase is like:
struct A {
  int a;
  __attribute__((noinline, warning ("bar1"))) virtual int
  bar () { asm (""); return 1; }
};
struct B {
  int a;
  __attribute__((noinline, warning ("bar2"))) virtual int
  bar () { asm (""); asm (""); return 2; }
};
struct C : public A, public B {
  int c;
  __attribute__((noinline, warning ("bar3"))) virtual int
  bar () { asm (""); asm (""); asm (""); return 3; }
};

int
baz (B *b)
{
  return b->bar ();
}

void
foo ()
{
  B b;
  baz ();
  C c;
  baz ();
}
where we do warning: call to ‘B::bar’ declared with attribute warning: bar2
i.e. on call _ZN1B3barEv
but not on call _ZThn16_N1C3barEv
Though, admittedly warning/error attribute on a method which often is called
only indirectly doesn't make a lot of sense, the indirect calls will not
emit any warning or error, so it is all matter of luck or lack thereof if
you get diagnostic or not (whether devirtualization manages to devirtualize
and on the other side we don't inline it).  So perhaps that isn't worth the
trouble.

Here is the unsuccessful attempt.
I lean towards the the original patch unless we want to add another cgraph
bit for the thunks.

2018-03-02  Jakub Jelinek  

PR ipa/84628
* expr.c (expand_expr_real_1): Don't warn about calls to fndecls
with error or warning attributes from thunks.

* gcc.dg/pr84628.c: New test.

--- gcc/expr.c.jj   2018-02-09 19:11:29.094068531 +0100
+++ gcc/expr.c  2018-03-02 10:26:51.718741734 +0100
@@ -10961,14 +10961,19 @@ expand_expr_real_1 (tree exp, rtx target
error ("%Kinvalid use of %<__builtin_va_arg_pack ()%>", exp);
   {
tree fndecl = get_callee_fndecl (exp), attr;
+   struct cgraph_node *node = cgraph_node::get (current_function_decl);
 
+   /* Don't diagnose these attributes in thunks, those are artificially
+  created.  */
if (fndecl
+   && (!node || !node->thunk.thunk_p)
&& (attr = lookup_attribute ("error",
 DECL_ATTRIBUTES (fndecl))) != NULL)
  error ("%Kcall to %qs declared with attribute error: %s",
 exp, identifier_to_locale (lang_hooks.decl_printable_name 
(fndecl, 1)),
 TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
if (fndecl
+   && (!node || !node->thunk.thunk_p)
&& (attr = lookup_attribute ("warning",
 DECL_ATTRIBUTES (fndecl))) != NULL)
  warning_at (tree_nonartificial_location (exp),
--- gcc/testsuite/gcc.dg/pr84628.c.jj   

Re: [PATCH] Fix ICF with error/warning attribute (PR ipa/84628)

[Jakub Jelinek]

On Fri, Mar 02, 2018 at 08:58:34AM +0100, Richard Biener wrote:
> On Fri, 2 Mar 2018, Jakub Jelinek wrote:
> 
> > Hi!
> > 
> > If we need to use thunks for ICF to functions with warning or error
> > attribute, their expansion will warn or error.  This patch just punts
> > in those cases instead.
> > 
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> Looks ok but I wonder if marking the call in the thunk with no-warning
> would work as well?

No, expr.c doesn't test anything like that (and adding it might regress
other things, TREE_NO_WARNING is way too overloaded now).

I was also considering an alternative to add something like:
  struct cgraph_node *node = cgraph_node::get (current_function_decl);
and add
  && (!node || !node->thunk.thunk_p)
to the two conditions for error/warning attribute:
if (fndecl
&& (attr = lookup_attribute ("error",
 DECL_ATTRIBUTES (fndecl))) != NULL)
  error ("%Kcall to %qs declared with attribute error: %s",
 exp, identifier_to_locale (lang_hooks.decl_printable_name 
(fndecl, 1)),
 TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
if (fndecl
&& (attr = lookup_attribute ("warning",
 DECL_ATTRIBUTES (fndecl))) != NULL)
  warning_at (tree_nonartificial_location (exp),
  0, "%Kcall to %qs declared with attribute warning: %s",
  exp, identifier_to_locale (lang_hooks.decl_printable_name 
(fndecl, 1)),
  TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
I've tried to come up with a testcase where generic thunks are used for C++,
but failed to do something that would trigger an invalid warning or error.

Would you prefer just being silent in all thunks?

That said, wonder about thunks (the non-ICF ones) from false-negative
diagnostic point as well, if I have some method with error/warning attribute
and call a thunk instead, wonder if we get the diagnostic or not, thunks
likely don't have the attribute copied over to them.

Jakub

Re: Fix PR ipa/83983 (partially)

[Richard Biener]

On Fri, Mar 2, 2018 at 9:49 AM, Eric Botcazou  wrote:
> Hi,
>
> this PR reports the failure of g++.dg/lto/pr83121 on multiple platforms.
>
> There are 2 differents issues and this message is about the missing warning on
> Aarch64 and SPARC.  On these platforms the LTO compiler issues:
>
> /home/ebotcazou/src/gcc/testsuite/g++.dg/lto/pr83121_0.C:6:8: warning: type
> 'struct Environment' violates the C++ One Definition Rule [-Wodr]
> /home/ebotcazou/src/gcc/testsuite/g++.dg/lto/pr83121_1.C:1:8: note: a type
> with different size is defined in another translation unit
>
> instead of the expected more verbose warning, as for example on x86.  The
> discrepancy between x86 and Aarch64/SPARC comes from:
>
>   /* For ODR types be sure to compare their names.
>  To support -wno-odr-type-merging we allow one type to be non-ODR
>  and other ODR even though it is a violation.  */
>   if (types_odr_comparable (t1, t2, true))
> {
>   if (!types_same_for_odr (t1, t2, true))
> return false;
>   /* Limit recursion: If subtypes are ODR types and we know
>  that they are same, be happy.  */
>   if (!odr_type_p (t1) || !get_odr_type (t1, true)->odr_violated)
> return true;
> }
>
> The call to get_odr_type (t1, true) is supposed to yield the warning, but this
> depends on the order in which types t1 and t2 have been inserted in the table.
>
> In other words, get_odr_type (t1, true) works on x86 while on Aarch64/SPARC
> get_odr_type (t2, true) works instead.  Hence the propose fix.
>
> Tested on x86-64/Linux and SPARC64/Linux, OK for the mainline?

Ok with a comment explaining why we call both even though
types_same_for_odr holds true.

Thanks,
Richard.

>
> 2018-03-02  Eric Botcazou  
>
> PR ipa/83983
> * ipa-devirt.c (odr_subtypes_equivalent_p): Get the ODR type of both
> arguments if they are comparable.
>
> --
> Eric Botcazou

Re: [Patch, fortran] PR84219 - [8 Regression] ICE: Invalid expression in gfc_target_interpret_expr

[Paul Richard Thomas]

Hi Christophe,

I committed the wrong test :-(  Corrected r258128.

Many thanks

Paul


On 2 March 2018 at 08:38, Paul Richard Thomas
 wrote:
> Hi Christophe,
>
> I was not aware. Thanks for letting me know.
>
> It's wierd that there is no error message or an ICE. Previously, an
> ICE would occur instead of the intended error message.
>
> I do not have access to either targets. Would you be so kind as to run
> coarray_47.f90 separately to see what happens? Note that 7-branch
> behaves correctly.
>
> Cheers
>
> Paul
>
> On 2 March 2018 at 08:26, Christophe Lyon  wrote:
>> On 1 March 2018 at 14:28, Paul Richard Thomas
>>  wrote:
>>> Committed as 'obvious' in revision 258098.
>>>
>>> Paul
>>>
>>> 2018-03-01  Paul Thomas  
>>>
>>> PR fortran/84219
>>> * target-memory.c (gfc_interpret_derived): Assert that BT_VOID
>>> components are caf tokens.
>>> (gfc_target_interpret_expr): Treat BT_VOID expressions as
>>> integers.
>>>
>>> 2018-03-01  Paul Thomas  
>>>
>>> PR fortran/84219
>>> * gfortran.dg/coarray_47.f90: New test.
>>
>>
>> Hi Paul,
>>
>> You may already be aware of that, but the new test fails at least on
>> aarch64 and arm targets:
>> FAIL: gfortran.dg/coarray_47.f90   -O   (test for errors, line 12)
>> As a matter of fact, I can see no error message in gfortran.log, hence
>> dg-error fails to match.
>>
>> Christophe
>
>
>
> --
> "If you can't explain it simply, you don't understand it well enough"
> - Albert Einstein



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 patches:

http://gcc.gnu.org/ml/gcc-patches/2018-02/msg01340.html
  - PR target/84524 avx512* wrong-code bug

http://gcc.gnu.org/ml/gcc-patches/2018-02/msg01337.html
  - fix c-c++-common/Warray-bounds-2.c testcase for -fpic

Thanks

Jakub

[PATCH] i18n fixes in gimple-ssa-sprintf.c (take 2)

[Jakub Jelinek]

On Thu, Mar 01, 2018 at 06:05:30PM -0700, Martin Sebor wrote:
> > --- gcc/gimple-ssa-sprintf.c.jj 2018-02-27 23:16:19.747948912 +0100
> > +++ gcc/gimple-ssa-sprintf.c2018-03-01 21:26:37.728861287 +0100
> > @@ -592,14 +592,12 @@ get_format_string (tree format, location
> >  /* The format_warning_at_substring function is not used here in a way
> > that makes using attribute format viable.  Suppress the warning.  */
> > 
> > -#pragma GCC diagnostic push
> > -#pragma GCC diagnostic ignored "-Wsuggest-attribute=format"
> > -
> 
> The comment above the #pragmas should be removed too.

Done below.

> >  /* For convenience and brevity.  */
> > 
> >  static bool
> >(* const fmtwarn) (const substring_loc &, location_t,
> >  const char *, int, const char *, ...)
> > +  ATTRIBUTE_GCC_DIAG (5, 6)
> >= format_warning_at_substring;
> 
> So add
> 
>   static bool
> (* const fmtwarn_n) (const substring_loc &, location_t,
>const char *, int, unsigned HOST_WIDE_INT,
>  const char *, const char*, ...)
> ATTRIBUTE_GCC_DIAG (5, 6)

That would have to be ATTRIBUTE_GCC_DIAG (6, 8) ATTRIBUTE_GCC_DIAG (7, 8)

> = format_warning_at_substring_n;
> 
> and use the pointer instead?

As I said, that doesn't really work; it works for -Wformat, but doesn't
work with exgettext.  Which is why for fmtwarn one has to use
  fmtwarn (.., G_("foobarbaz"), ...);
instead of
  fmtwarn (.., "foobarbaz", ...);
even when it is not conditional.

What we can do though is just duplicate the
format_warning_at_substring and format_warning_at_substring_n functions
(which are short and simple enough) as static under the shorter names.
This way we can also get rid of the G_( ... ) wrapping of non-conditional
fmtwarn arguments.

I've verified generated gcc.pot is the same between previous and this
patch, except for line numbers in the comments, and if I comment out
the (int) casts from dir.len in both one of fmtwarn and one of fmtwarn_n
calls, gcc properly warns.  Ok for trunk if it passes bootstrap/regtest?

2018-03-02  Jakub Jelinek  

* substring-locations.h (format_warning_va): Formatting fix for
ATTRIBUTE_GCC_DIAG.
(format_warning_at_substring): Fix up ATTRIBUTE_GCC_DIAG second
argument.
(format_warning_n_va, format_warning_at_substring_n): New prototypes.
* substring-locations.c: Include intl.h.
(format_warning_va): Turned into small wrapper around
format_warning_n_va, renamed to ...
(format_warning_n_va): ... this, add N and PLURAL_GMSGID arguments,
rename GMSGID to SINGULAR_GMSGID, if SINGULAR_GMSGID != PLURAL_GMSGID,
use ngettext.
(format_warning_at_substring_n): New function.
* gimple-ssa-sprintf.c: Remove GCC diagnostic ignored pragma.
(fmtwarn): Add ATTRIBUTE_GCC_DIAG.  Turn into a copy of
format_warning_at_substring with just a shorter name instead of
const function pointer.
(fmtwarn_n): New function.
(maybe_warn, format_directive, parse_directive): Use fmtwarn_n where
appropriate, get rid of all the fmtstr temporaries, move conditionals
with G_() wrapped string literals directly into fmtwarn arguments,
cast dir.len to (int), formatting fixes.

--- gcc/substring-locations.h.jj2018-03-02 00:15:43.663782300 +0100
+++ gcc/substring-locations.h   2018-03-02 08:11:45.825500655 +0100
@@ -80,13 +80,29 @@ extern bool format_warning_va (const sub
   location_t param_loc,
   const char *corrected_substring,
   int opt, const char *gmsgid, va_list *ap)
-  ATTRIBUTE_GCC_DIAG (5,0);
+  ATTRIBUTE_GCC_DIAG (5, 0);
+
+extern bool format_warning_n_va (const substring_loc _loc,
+location_t param_loc,
+const char *corrected_substring,
+int opt, unsigned HOST_WIDE_INT n,
+const char *singular_gmsgid,
+const char *plural_gmsgid, va_list *ap)
+  ATTRIBUTE_GCC_DIAG (6, 0) ATTRIBUTE_GCC_DIAG (7, 0);
 
 extern bool format_warning_at_substring (const substring_loc _loc,
 location_t param_loc,
 const char *corrected_substring,
 int opt, const char *gmsgid, ...)
-  ATTRIBUTE_GCC_DIAG (5,0);
+  ATTRIBUTE_GCC_DIAG (5, 6);
+
+extern bool format_warning_at_substring_n (const substring_loc _loc,
+  location_t param_loc,
+  const char *corrected_substring,
+  int opt, unsigned HOST_WIDE_INT n,
+  const char *singular_gmsgid,
+  

Fix PR ipa/83983 (partially)

[Eric Botcazou]

Hi,

this PR reports the failure of g++.dg/lto/pr83121 on multiple platforms.

There are 2 differents issues and this message is about the missing warning on 
Aarch64 and SPARC.  On these platforms the LTO compiler issues:

/home/ebotcazou/src/gcc/testsuite/g++.dg/lto/pr83121_0.C:6:8: warning: type 
'struct Environment' violates the C++ One Definition Rule [-Wodr]
/home/ebotcazou/src/gcc/testsuite/g++.dg/lto/pr83121_1.C:1:8: note: a type 
with different size is defined in another translation unit

instead of the expected more verbose warning, as for example on x86.  The 
discrepancy between x86 and Aarch64/SPARC comes from:

  /* For ODR types be sure to compare their names.
 To support -wno-odr-type-merging we allow one type to be non-ODR
 and other ODR even though it is a violation.  */
  if (types_odr_comparable (t1, t2, true))
{
  if (!types_same_for_odr (t1, t2, true))
return false;
  /* Limit recursion: If subtypes are ODR types and we know
 that they are same, be happy.  */
  if (!odr_type_p (t1) || !get_odr_type (t1, true)->odr_violated)
return true;
}

The call to get_odr_type (t1, true) is supposed to yield the warning, but this 
depends on the order in which types t1 and t2 have been inserted in the table.

In other words, get_odr_type (t1, true) works on x86 while on Aarch64/SPARC 
get_odr_type (t2, true) works instead.  Hence the propose fix.

Tested on x86-64/Linux and SPARC64/Linux, OK for the mainline?


2018-03-02  Eric Botcazou  

PR ipa/83983
* ipa-devirt.c (odr_subtypes_equivalent_p): Get the ODR type of both
arguments if they are comparable.

-- 
Eric BotcazouIndex: ipa-devirt.c
===
--- ipa-devirt.c	(revision 258068)
+++ ipa-devirt.c	(working copy)
@@ -686,7 +686,10 @@ odr_subtypes_equivalent_p (tree t1, tree t2,
 return false;
   /* Limit recursion: If subtypes are ODR types and we know
  that they are same, be happy.  */
-  if (!odr_type_p (t1) || !get_odr_type (t1, true)->odr_violated)
+  if (!odr_type_p (t1)
+	  || !odr_type_p (t2)
+	  || (!get_odr_type (t1, true)->odr_violated
+	  && !get_odr_type (t2, true)->odr_violated))
 return true;
 }
 

Re: [Patch, fortran] PR84219 - [8 Regression] ICE: Invalid expression in gfc_target_interpret_expr

[Paul Richard Thomas]

By golly you are right!

Je vous en remercie :-)

Paul


On 2 March 2018 at 08:41, Christophe Lyon  wrote:
> On 2 March 2018 at 09:38, Paul Richard Thomas
>  wrote:
>> Hi Christophe,
>>
>> I was not aware. Thanks for letting me know.
>>
>> It's wierd that there is no error message or an ICE. Previously, an
>> ICE would occur instead of the intended error message.
>>
>> I do not have access to either targets. Would you be so kind as to run
>> coarray_47.f90 separately to see what happens? Note that 7-branch
>> behaves correctly.
>>
>> Cheers
>
> According to https://gcc.gnu.org/ml/gcc-testresults/2018-03/
> it also happens on x86_64, I suspect that's easier for you?
>
> Thanks,
>
> Christophe
>
>>
>> Paul
>>
>> On 2 March 2018 at 08:26, Christophe Lyon  wrote:
>>> On 1 March 2018 at 14:28, Paul Richard Thomas
>>>  wrote:
 Committed as 'obvious' in revision 258098.

 Paul

 2018-03-01  Paul Thomas  

 PR fortran/84219
 * target-memory.c (gfc_interpret_derived): Assert that BT_VOID
 components are caf tokens.
 (gfc_target_interpret_expr): Treat BT_VOID expressions as
 integers.

 2018-03-01  Paul Thomas  

 PR fortran/84219
 * gfortran.dg/coarray_47.f90: New test.
>>>
>>>
>>> Hi Paul,
>>>
>>> You may already be aware of that, but the new test fails at least on
>>> aarch64 and arm targets:
>>> FAIL: gfortran.dg/coarray_47.f90   -O   (test for errors, line 12)
>>> As a matter of fact, I can see no error message in gfortran.log, hence
>>> dg-error fails to match.
>>>
>>> Christophe
>>
>>
>>
>> --
>> "If you can't explain it simply, you don't understand it well enough"
>> - Albert Einstein



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: [PATCH,PTX] Add support for CUDA 9

[Thomas Schwinge]

Hi!

On Tue, 27 Feb 2018 15:12:47 +0100, Richard Biener  wrote:
> On Tue, 27 Feb 2018, Thomas Schwinge wrote:
> > Given that several users have run into this, is this (trunk r256891) OK
> > to commit to open release branches, too.
> 
> Sure.

Committed to gcc-7-branch in r258126:

commit f0888f115525785d8876d1718fcb0580996e2f30
Author: tschwinge 
Date:   Fri Mar 2 08:39:31 2018 +

[nvptx] Add support for CUDA 9

Backport trunk r256891:

gcc/
2018-01-19  Cesar Philippidis  

PR target/83790
* config/nvptx/nvptx.c (output_init_frag): Don't use generic address
spaces for function labels.

gcc/testsuite/
2018-01-19  Cesar Philippidis  

PR target/83790
* gcc.target/nvptx/indirect_call.c: New test.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-7-branch@258126 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog  |  9 +
 gcc/config/nvptx/nvptx.c   | 10 --
 gcc/testsuite/ChangeLog|  8 
 gcc/testsuite/gcc.target/nvptx/indirect_call.c | 19 +++
 4 files changed, 44 insertions(+), 2 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index def6171..5390d49 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,12 @@
+2017-03-02  Thomas Schwinge  
+
+   Backport from trunk r256891:
+   2018-01-19  Cesar Philippidis  
+
+   PR target/83790
+   * config/nvptx/nvptx.c (output_init_frag): Don't use generic address
+   spaces for function labels.
+
 2018-02-26  Carl Love  
 
Backport from mainline: commit 257747 on 2018-02-16.
diff --git gcc/config/nvptx/nvptx.c gcc/config/nvptx/nvptx.c
index e89b314..70a8f0d 100644
--- gcc/config/nvptx/nvptx.c
+++ gcc/config/nvptx/nvptx.c
@@ -1875,9 +1875,15 @@ output_init_frag (rtx sym)
   
   if (sym)
 {
-  fprintf (asm_out_file, "generic(");
+  bool function = (SYMBOL_REF_DECL (sym)
+  && (TREE_CODE (SYMBOL_REF_DECL (sym)) == FUNCTION_DECL));
+  if (!function)
+   fprintf (asm_out_file, "generic(");
   output_address (VOIDmode, sym);
-  fprintf (asm_out_file, val ? ") + " : ")");
+  if (!function)
+   fprintf (asm_out_file, ")");
+  if (val)
+   fprintf (asm_out_file, " + ");
 }
 
   if (!sym || val)
diff --git gcc/testsuite/ChangeLog gcc/testsuite/ChangeLog
index 359cbac..2d94cd1 100644
--- gcc/testsuite/ChangeLog
+++ gcc/testsuite/ChangeLog
@@ -1,3 +1,11 @@
+2017-03-02  Thomas Schwinge  
+
+   Backport from trunk r256891:
+   2018-01-19  Cesar Philippidis  
+
+   PR target/83790
+   * gcc.target/nvptx/indirect_call.c: New test.
+
 2017-03-01  Thomas Preud'homme  
 
Backport from mainline
diff --git gcc/testsuite/gcc.target/nvptx/indirect_call.c 
gcc/testsuite/gcc.target/nvptx/indirect_call.c
new file mode 100644
index 000..39992a7
--- /dev/null
+++ gcc/testsuite/gcc.target/nvptx/indirect_call.c
@@ -0,0 +1,19 @@
+/* { dg-options "-O2 -msoft-stack" } */
+/* { dg-do run } */
+
+int
+f1 (int a)
+{
+  return a + 1;
+}
+  
+int (*f2)(int) = f1;
+
+int
+main ()
+{
+  if (f2 (100) != 101)
+__builtin_abort();
+
+  return 0;
+}

Committed to gcc-6-branch in r258127:

commit 5eec276cf6e2721ba60e187edeb00af5f6b7565f
Author: tschwinge 
Date:   Fri Mar 2 08:40:04 2018 +

[nvptx] Add support for CUDA 9

Backport trunk r256891:

gcc/
2018-01-19  Cesar Philippidis  

PR target/83790
* config/nvptx/nvptx.c (output_init_frag): Don't use generic address
spaces for function labels.

gcc/testsuite/
2018-01-19  Cesar Philippidis  

PR target/83790
* gcc.target/nvptx/indirect_call.c: New test.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-6-branch@258127 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog  |  9 +
 gcc/config/nvptx/nvptx.c   | 10 --
 gcc/testsuite/ChangeLog|  8 
 gcc/testsuite/gcc.target/nvptx/indirect_call.c | 19 +++
 4 files changed, 44 insertions(+), 2 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index cebcf85..23296f2 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,12 @@
+2017-03-02  Thomas Schwinge  
+
+   Backport from trunk r256891:
+   2018-01-19  Cesar Philippidis  
+
+   PR target/83790
+  

Re: [Patch, fortran] PR84219 - [8 Regression] ICE: Invalid expression in gfc_target_interpret_expr

[Christophe Lyon]

On 2 March 2018 at 09:38, Paul Richard Thomas
 wrote:
> Hi Christophe,
>
> I was not aware. Thanks for letting me know.
>
> It's wierd that there is no error message or an ICE. Previously, an
> ICE would occur instead of the intended error message.
>
> I do not have access to either targets. Would you be so kind as to run
> coarray_47.f90 separately to see what happens? Note that 7-branch
> behaves correctly.
>
> Cheers

According to https://gcc.gnu.org/ml/gcc-testresults/2018-03/
it also happens on x86_64, I suspect that's easier for you?

Thanks,

Christophe

>
> Paul
>
> On 2 March 2018 at 08:26, Christophe Lyon  wrote:
>> On 1 March 2018 at 14:28, Paul Richard Thomas
>>  wrote:
>>> Committed as 'obvious' in revision 258098.
>>>
>>> Paul
>>>
>>> 2018-03-01  Paul Thomas  
>>>
>>> PR fortran/84219
>>> * target-memory.c (gfc_interpret_derived): Assert that BT_VOID
>>> components are caf tokens.
>>> (gfc_target_interpret_expr): Treat BT_VOID expressions as
>>> integers.
>>>
>>> 2018-03-01  Paul Thomas  
>>>
>>> PR fortran/84219
>>> * gfortran.dg/coarray_47.f90: New test.
>>
>>
>> Hi Paul,
>>
>> You may already be aware of that, but the new test fails at least on
>> aarch64 and arm targets:
>> FAIL: gfortran.dg/coarray_47.f90   -O   (test for errors, line 12)
>> As a matter of fact, I can see no error message in gfortran.log, hence
>> dg-error fails to match.
>>
>> Christophe
>
>
>
> --
> "If you can't explain it simply, you don't understand it well enough"
> - Albert Einstein

Re: [Patch, fortran] PR84219 - [8 Regression] ICE: Invalid expression in gfc_target_interpret_expr

[Paul Richard Thomas]

Hi Christophe,

I was not aware. Thanks for letting me know.

It's wierd that there is no error message or an ICE. Previously, an
ICE would occur instead of the intended error message.

I do not have access to either targets. Would you be so kind as to run
coarray_47.f90 separately to see what happens? Note that 7-branch
behaves correctly.

Cheers

Paul

On 2 March 2018 at 08:26, Christophe Lyon  wrote:
> On 1 March 2018 at 14:28, Paul Richard Thomas
>  wrote:
>> Committed as 'obvious' in revision 258098.
>>
>> Paul
>>
>> 2018-03-01  Paul Thomas  
>>
>> PR fortran/84219
>> * target-memory.c (gfc_interpret_derived): Assert that BT_VOID
>> components are caf tokens.
>> (gfc_target_interpret_expr): Treat BT_VOID expressions as
>> integers.
>>
>> 2018-03-01  Paul Thomas  
>>
>> PR fortran/84219
>> * gfortran.dg/coarray_47.f90: New test.
>
>
> Hi Paul,
>
> You may already be aware of that, but the new test fails at least on
> aarch64 and arm targets:
> FAIL: gfortran.dg/coarray_47.f90   -O   (test for errors, line 12)
> As a matter of fact, I can see no error message in gfortran.log, hence
> dg-error fails to match.
>
> Christophe



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: [PATCH] Fix ICF with error/warning attribute (PR ipa/84628)

[Richard Biener]

On Fri, 2 Mar 2018, Jakub Jelinek wrote:

> On Fri, Mar 02, 2018 at 09:15:07AM +0100, Richard Biener wrote:
> > You probably need a virtual return thunk as otherwise we expand them
> > directly to asm?
> 
> I was trying x86_64 -m32 -fpic regparm (3) method with thunks so that
> the asm isn't emitted.  But the thunk was still using call to .LTHUNKN
> rather than the actual method FUNCTION_DECL.  Perhaps on targets without
> proper alias support...
> 
> > > Would you prefer just being silent in all thunks?
> > 
> > Yes, I think all warnings from thunks are ultimately going to be bogus...
> 
> Ok, I'll change the patch.
> 
> > > That said, wonder about thunks (the non-ICF ones) from false-negative
> > > diagnostic point as well, if I have some method with error/warning 
> > > attribute
> > > and call a thunk instead, wonder if we get the diagnostic or not, thunks
> > > likely don't have the attribute copied over to them.
> > 
> > True...
> > 
> > I guess we should not warn from thunks but instead move those attributes
> > to the thunks so see if those get called in the end.
> 
> Or in the expr.c code look through thunks to find the underlying function
> and take DECL_ARGUMENTS from there.

If that's easily possible that sounds good as well of course.

Richard.

Re: [Patch, fortran] PR84219 - [8 Regression] ICE: Invalid expression in gfc_target_interpret_expr

[Christophe Lyon]

On 1 March 2018 at 14:28, Paul Richard Thomas
 wrote:
> Committed as 'obvious' in revision 258098.
>
> Paul
>
> 2018-03-01  Paul Thomas  
>
> PR fortran/84219
> * target-memory.c (gfc_interpret_derived): Assert that BT_VOID
> components are caf tokens.
> (gfc_target_interpret_expr): Treat BT_VOID expressions as
> integers.
>
> 2018-03-01  Paul Thomas  
>
> PR fortran/84219
> * gfortran.dg/coarray_47.f90: New test.


Hi Paul,

You may already be aware of that, but the new test fails at least on
aarch64 and arm targets:
FAIL: gfortran.dg/coarray_47.f90   -O   (test for errors, line 12)
As a matter of fact, I can see no error message in gfortran.log, hence
dg-error fails to match.

Christophe

Re: Avoid _VINFO_MASKS for bb vectorisation (PR 84634)

[Richard Biener]

On Thu, Mar 1, 2018 at 7:30 PM, Richard Sandiford
 wrote:
> We were computing _VINFO_MASKS even for bb vectorisation,
> which is UB.
>
> Tested on aarch64-linux-gnu.  OK to install?

Ok.

Richard.

> Richard
>
>
> 2018-03-01  Richard Sandiford  
>
> gcc/
> PR tree-optimization/84634
> * tree-vect-stmts.c (vectorizable_store, vectorizable_load): Replace
> masks and masked_loop_p with a single loop_masks, making sure it's
> null for bb vectorization.
>
> Index: gcc/tree-vect-stmts.c
> ===
> --- gcc/tree-vect-stmts.c   2018-02-20 09:39:34.536228161 +
> +++ gcc/tree-vect-stmts.c   2018-03-01 18:29:15.280350088 +
> @@ -6703,13 +6703,16 @@ vectorizable_store (gimple *stmt, gimple
>
>alignment_support_scheme = vect_supportable_dr_alignment (first_dr, false);
>gcc_assert (alignment_support_scheme);
> -  bool masked_loop_p = (loop_vinfo && LOOP_VINFO_FULLY_MASKED_P 
> (loop_vinfo));
> +  vec_loop_masks *loop_masks
> += (loop_vinfo && LOOP_VINFO_FULLY_MASKED_P (loop_vinfo)
> +   ? _VINFO_MASKS (loop_vinfo)
> +   : NULL);
>/* Targets with store-lane instructions must not require explicit
>   realignment.  vect_supportable_dr_alignment always returns either
>   dr_aligned or dr_unaligned_supported for masked operations.  */
>gcc_assert ((memory_access_type != VMAT_LOAD_STORE_LANES
>&& !mask
> -  && !masked_loop_p)
> +  && !loop_masks)
>   || alignment_support_scheme == dr_aligned
>   || alignment_support_scheme == dr_unaligned_supported);
>
> @@ -6783,7 +6786,6 @@ vectorizable_store (gimple *stmt, gimple
>
>prev_stmt_info = NULL;
>tree vec_mask = NULL_TREE;
> -  vec_loop_masks *masks = _VINFO_MASKS (loop_vinfo);
>for (j = 0; j < ncopies; j++)
>  {
>
> @@ -6900,8 +6902,9 @@ vectorizable_store (gimple *stmt, gimple
> }
>
>   tree final_mask = NULL;
> - if (masked_loop_p)
> -   final_mask = vect_get_loop_mask (gsi, masks, ncopies, vectype, j);
> + if (loop_masks)
> +   final_mask = vect_get_loop_mask (gsi, loop_masks, ncopies,
> +vectype, j);
>   if (vec_mask)
> final_mask = prepare_load_store_mask (mask_vectype, final_mask,
>   vec_mask, gsi);
> @@ -6949,8 +6952,9 @@ vectorizable_store (gimple *stmt, gimple
>   unsigned align, misalign;
>
>   tree final_mask = NULL_TREE;
> - if (masked_loop_p)
> -   final_mask = vect_get_loop_mask (gsi, masks, vec_num * 
> ncopies,
> + if (loop_masks)
> +   final_mask = vect_get_loop_mask (gsi, loop_masks,
> +vec_num * ncopies,
>  vectype, vec_num * j + i);
>   if (vec_mask)
> final_mask = prepare_load_store_mask (mask_vectype, 
> final_mask,
> @@ -6960,7 +6964,7 @@ vectorizable_store (gimple *stmt, gimple
> {
>   tree scale = size_int (gs_info.scale);
>   gcall *call;
> - if (masked_loop_p)
> + if (loop_masks)
> call = gimple_build_call_internal
>   (IFN_MASK_SCATTER_STORE, 5, dataref_ptr, vec_offset,
>scale, vec_oprnd, final_mask);
> @@ -7790,13 +7794,16 @@ vectorizable_load (gimple *stmt, gimple_
>
>alignment_support_scheme = vect_supportable_dr_alignment (first_dr, false);
>gcc_assert (alignment_support_scheme);
> -  bool masked_loop_p = (loop_vinfo && LOOP_VINFO_FULLY_MASKED_P 
> (loop_vinfo));
> +  vec_loop_masks *loop_masks
> += (loop_vinfo && LOOP_VINFO_FULLY_MASKED_P (loop_vinfo)
> +   ? _VINFO_MASKS (loop_vinfo)
> +   : NULL);
>/* Targets with store-lane instructions must not require explicit
>   realignment.  vect_supportable_dr_alignment always returns either
>   dr_aligned or dr_unaligned_supported for masked operations.  */
>gcc_assert ((memory_access_type != VMAT_LOAD_STORE_LANES
>&& !mask
> -  && !masked_loop_p)
> +  && !loop_masks)
>   || alignment_support_scheme == dr_aligned
>   || alignment_support_scheme == dr_unaligned_supported);
>
> @@ -7956,7 +7963,6 @@ vectorizable_load (gimple *stmt, gimple_
>tree vec_mask = NULL_TREE;
>prev_stmt_info = NULL;
>poly_uint64 group_elt = 0;
> -  vec_loop_masks *masks = _VINFO_MASKS (loop_vinfo);
>for (j = 0; j < ncopies; j++)
>  {
>/* 1. Create the vector or array pointer update chain.  */
> @@ -8037,8 +8043,9 @@ vectorizable_load (gimple *stmt, gimple_
>   vec_array = create_vector_array (vectype, vec_num);
>
> 

Re: Use loop->safelen rather than loop->force_vectorize

[Richard Biener]

On Thu, Mar 1, 2018 at 7:20 PM, Richard Sandiford
 wrote:
> ...since the latter doesn't guarantee independence by itself.
>
> Tested on aarch64-linux-gnu.  OK to install?

Ok.

Richard.

> Richard
>
>
> 2018-03-01  Richard Sandiford  
>
> gcc/
> * tree-vect-data-refs.c (vect_analyze_data_ref_dependence)
> (vect_analyze_data_ref_access): Use loop->safe_len rather than
> loop->force_vectorize to check whether there is no alias.
>
> gcc/testsuite/
> * gcc.dg/vect/vect-alias-check-13.c: New test.
>
> Index: gcc/tree-vect-data-refs.c
> ===
> --- gcc/tree-vect-data-refs.c   2018-02-10 09:49:47.950776097 +
> +++ gcc/tree-vect-data-refs.c   2018-03-01 18:17:41.631482331 +
> @@ -466,7 +466,7 @@ vect_analyze_data_ref_dependence (struct
>   return true;
> }
>
> - if (!loop->force_vectorize)
> + if (loop->safelen < 2)
> {
>   tree indicator = dr_zero_step_indicator (dra);
>   if (TREE_CODE (indicator) != INTEGER_CST)
> @@ -2720,7 +2720,7 @@ vect_analyze_data_ref_access (struct dat
>/* Allow references with zero step for outer loops marked
>  with pragma omp simd only - it guarantees absence of
>  loop-carried dependencies between inner loop iterations.  */
> -  if (!loop->force_vectorize)
> +  if (loop->safelen < 2)
> {
>   if (dump_enabled_p ())
> dump_printf_loc (MSG_NOTE, vect_location,
> Index: gcc/testsuite/gcc.dg/vect/vect-alias-check-13.c
> ===
> --- /dev/null   2018-03-01 08:17:49.562264353 +
> +++ gcc/testsuite/gcc.dg/vect/vect-alias-check-13.c 2018-03-01 
> 18:17:41.630484279 +
> @@ -0,0 +1,21 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target vect_int } */
> +
> +void
> +f1 (int *x, long step1, int n)
> +{
> +  for (int i = 0; i < n; ++i)
> +x[i * step1] += 1;
> +}
> +
> +void
> +f2 (int *x, long step2, int n)
> +{
> +#pragma GCC ivdep
> +  for (int i = 0; i < n; ++i)
> +x[i * step2] += 2;
> +}
> +
> +/* { dg-final { scan-tree-dump {need run-time check that [^\n]*step1[^\n]* 
> is nonzero} "vect" } } */
> +/* { dg-final { scan-tree-dump-not {need run-time check that 
> [^\n]*step2[^\n]* is nonzero} "vect" } } */
> +/* { dg-final { scan-tree-dump-times {LOOP VECTORIZED} 2 "vect" } } */

Re: [PATCH] Fix ICF with error/warning attribute (PR ipa/84628)

[Jakub Jelinek]

On Fri, Mar 02, 2018 at 09:15:07AM +0100, Richard Biener wrote:
> You probably need a virtual return thunk as otherwise we expand them
> directly to asm?

I was trying x86_64 -m32 -fpic regparm (3) method with thunks so that
the asm isn't emitted.  But the thunk was still using call to .LTHUNKN
rather than the actual method FUNCTION_DECL.  Perhaps on targets without
proper alias support...

> > Would you prefer just being silent in all thunks?
> 
> Yes, I think all warnings from thunks are ultimately going to be bogus...

Ok, I'll change the patch.

> > That said, wonder about thunks (the non-ICF ones) from false-negative
> > diagnostic point as well, if I have some method with error/warning attribute
> > and call a thunk instead, wonder if we get the diagnostic or not, thunks
> > likely don't have the attribute copied over to them.
> 
> True...
> 
> I guess we should not warn from thunks but instead move those attributes
> to the thunks so see if those get called in the end.

Or in the expr.c code look through thunks to find the underlying function
and take DECL_ARGUMENTS from there.

Jakub

Re: [PATCH] Fix ICF with error/warning attribute (PR ipa/84628)

[Richard Biener]

On Fri, 2 Mar 2018, Jakub Jelinek wrote:

> On Fri, Mar 02, 2018 at 08:58:34AM +0100, Richard Biener wrote:
> > On Fri, 2 Mar 2018, Jakub Jelinek wrote:
> > 
> > > Hi!
> > > 
> > > If we need to use thunks for ICF to functions with warning or error
> > > attribute, their expansion will warn or error.  This patch just punts
> > > in those cases instead.
> > > 
> > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > 
> > Looks ok but I wonder if marking the call in the thunk with no-warning
> > would work as well?
> 
> No, expr.c doesn't test anything like that (and adding it might regress
> other things, TREE_NO_WARNING is way too overloaded now).
> 
> I was also considering an alternative to add something like:
>   struct cgraph_node *node = cgraph_node::get (current_function_decl);
> and add
>   && (!node || !node->thunk.thunk_p)
> to the two conditions for error/warning attribute:
> if (fndecl
> && (attr = lookup_attribute ("error",
>  DECL_ATTRIBUTES (fndecl))) != NULL)
>   error ("%Kcall to %qs declared with attribute error: %s",
>  exp, identifier_to_locale (lang_hooks.decl_printable_name 
> (fndecl, 1)),
>  TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
> if (fndecl
> && (attr = lookup_attribute ("warning",
>  DECL_ATTRIBUTES (fndecl))) != NULL)
>   warning_at (tree_nonartificial_location (exp),
>   0, "%Kcall to %qs declared with attribute warning: %s",
>   exp, identifier_to_locale 
> (lang_hooks.decl_printable_name (fndecl, 1)),
>   TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (attr;
> I've tried to come up with a testcase where generic thunks are used for C++,
> but failed to do something that would trigger an invalid warning or error.

You probably need a virtual return thunk as otherwise we expand them
directly to asm?

> Would you prefer just being silent in all thunks?

Yes, I think all warnings from thunks are ultimately going to be bogus...

> That said, wonder about thunks (the non-ICF ones) from false-negative
> diagnostic point as well, if I have some method with error/warning attribute
> and call a thunk instead, wonder if we get the diagnostic or not, thunks
> likely don't have the attribute copied over to them.

True...

I guess we should not warn from thunks but instead move those attributes
to the thunks so see if those get called in the end.

Richard.

Re: [PATCH] deprecate -finline-limit and make it an optimization option (PR 84603)

[Richard Biener]

On Thu, 1 Mar 2018, Martin Sebor wrote:

> While testing my recent changes to the handling of attributes
> on C++ templates I noticed that the -finline-limit=N option
> is not recognized in attribute or pragma optimize.  In response
> to the bug I raised, Richard you said the option is deprecated,
> so I went ahead and documented the deprecation in the manual
> and also added a deprecation warning.  I also added it to
> Optimization options.  The attached patch reflects these
> changes.
> 
> I also tried to put together a test to verify that the option
> works as expected, both in attributes and in pragmas.  I wasn't
> able to get it to work reliably or sensibly.
> 
> In C, #pragma optimize ("inline-limit=1") has a global effect
> on all functions in the file, even those lexically before the
> pragma.  In C++, the pragma has no effect.  Both of these
> effects are contrary to my reading of the manual.
> 
> Attribute optimize ("inline-limit") behaves similarly, which
> seems even more unexpected and even more contrary to the manual
> which by referring to Function Specific Option Pragmas suggests
> that both the pragma and especially the attribute apply
> optimizations to just the functions they're specified for.

It can't really work so please do _not_ add the option to
the set of Optimize options.  Inlining is an IPA task so
"per function" parameters do not make sense at all.

IMHO the bug is simply INVALID.

Richard.