Re: [patch, libfortran] Fix thead sanitizer issue with libgfortran

2017-09-29 Thread Janne Blomqvist
On Fri, Sep 29, 2017 at 9:03 AM, Thomas Koenig  wrote:
> I wrote:
>
>> This gets rid of the thread sanitizer issue; the thread sanitizer
>> output is clean.  However, I would appreciate feedback about whether
>> this approach (and my code) is correct.
>>
>> Regression-tested.
>>
>
>
> Here is an update: The previous version of the patch had a regression,
> which is removed (with a test case) with the current version.
> Also regression-tested.
>
> So,
>
>> Comments? Suggestions for improvements/other approaches? Close the PR
>> as WONTFIX instead? OK for trunk?

In general, I do think this is an issue that should be fixed.
Multithreading is only going get more pervasive, and gfortran spewing
false positives from tools such as threadsanitizer is definitely
unhelpful.

Now, for the patch itself, AFAICT the general approach is correct.
However, I have a couple of questions and/or suggestions for
improvements:

1) I'm confused why fbuf_destroy is modified. The fbuf structure is
part of gfc_unit, and should be accessed with the same locking rules
as the rest of the gfc_unit components. When closing the unit, I think
the same should apply here, no?

2) I think the mutex init stuff can remain in insert_unit, just the
locking needs to move out and below freeing unit_lock like you have
done.




-- 
Janne Blomqvist


Re: [RFA gfortran] PR 25071: dummy argument larger than actual argument

2017-09-29 Thread Janne Blomqvist
On Thu, Sep 28, 2017 at 3:57 PM, Dominique d'Humières
 wrote:
> Hi all,
>
> In the PR there was some consensus to turn the warnings into errors.
>
> This is what the patch does: the warnings are kept with -std=legacy, errors 
> are emitted otherwise.
>  I am sure it may exist a better solution, but I did not find it.
>
> While regtesting I have found several regressions on top of 
> gfortran.dg/warn_argument_mismatch_1.f90
>
> At this point, I had two options: use -std=legacy everywhere or replace the 
> dg-warning with dg-error. I have chosen the later except for 
> warn_argument_mismatch_1.f90.
>
> Regtested on x86_64-apple-darwin16.
>
> Comments are welcome and I’ll provide the change logs once the dust has 
> settled.

Thanks for picking this up. I do think your solution is good enough,
and I also agree with how you've dealt with the testsuite changes.

So from my point of view, Ok for trunk along with a ChangeLog entry.



-- 
Janne Blomqvist


[LIBGO PATCH] Fix compilation error against uClibc-ng: runtime_sysinfo.go: error: use of undefined type ‘___uclibc_locale_struct’

2017-09-29 Thread Alex Potapenko
Hi!

Building GCC 7.2.0 libgo against uClibc-ng 1.0.26 results in the following
error:

> runtime_sysinfo.go:418:17: error: use of undefined type
> ‘___uclibc_locale_struct’


This happens because -fdump-go-spec probably generates types only from
typedef declarations, ignoring structs, like "struct
__uclibc_locale_struct;" in uClibc-ng  header. Adding
"typedef struct __uclibc_locale_struct __uclibc_locale_struct;" to
libgo/sysinfo.c remedies this issue:

--- a/libgo/sysinfo.c
+++ b/libgo/sysinfo.c
@@ -277,3 +277,7 @@
   epoll_data_offset = offsetof(struct epoll_event, data)
 };
 #endif
+
+#ifdef __UCLIBC__
+typedef struct __uclibc_locale_struct __uclibc_locale_struct;
+#endif

Best regards,
Alex


[PATCH][GRAPHITE] Abstract away codegen_error setting

2017-09-29 Thread Richard Biener

This moves it to a function to make it easy to enable ICEin on them
in one place.

Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.

Richard.

2017-09-29  Richard Biener  

* graphite-isl-ast-to-gimple.c
(translate_isl_ast_to_gimple::set_codegen_error): New function.
(binary_op_to_tree): Use it.
(get_rename_from_scev): Likewise.
(copy_loop_phi_nodes): Likewise.
(copy_bb_and_scalar_dependences): Likewise.
(translate_pending_phi_nodes): Likewise.

Index: gcc/graphite-isl-ast-to-gimple.c
===
--- gcc/graphite-isl-ast-to-gimple.c(revision 253249)
+++ gcc/graphite-isl-ast-to-gimple.c(working copy)
@@ -240,6 +240,7 @@ class translate_isl_ast_to_gimple
   void gsi_insert_earliest (gimple_seq seq);
   tree rename_all_uses (tree new_expr, basic_block new_bb, basic_block old_bb);
   bool codegen_error_p () const { return codegen_error; }
+  void set_codegen_error () { codegen_error = true; }
   bool is_constant (tree op) const
   {
 return TREE_CODE (op) == INTEGER_CST
@@ -347,7 +348,7 @@ binary_op_to_tree (tree type, __isl_take
 division by 2^64 that is folded to 0.  */
   if (integer_zerop (tree_rhs_expr))
{
- codegen_error = true;
+ set_codegen_error ();
  return NULL_TREE;
}
   return fold_build2 (EXACT_DIV_EXPR, type, tree_lhs_expr, tree_rhs_expr);
@@ -357,7 +358,7 @@ binary_op_to_tree (tree type, __isl_take
 division by 2^64 that is folded to 0.  */
   if (integer_zerop (tree_rhs_expr))
{
- codegen_error = true;
+ set_codegen_error ();
  return NULL_TREE;
}
   return fold_build2 (TRUNC_DIV_EXPR, type, tree_lhs_expr, tree_rhs_expr);
@@ -368,7 +369,7 @@ binary_op_to_tree (tree type, __isl_take
 division by 2^64 that is folded to 0.  */
   if (integer_zerop (tree_rhs_expr))
{
- codegen_error = true;
+ set_codegen_error ();
  return NULL_TREE;
}
   return fold_build2 (TRUNC_MOD_EXPR, type, tree_lhs_expr, tree_rhs_expr);
@@ -378,7 +379,7 @@ binary_op_to_tree (tree type, __isl_take
 division by 2^64 that is folded to 0.  */
   if (integer_zerop (tree_rhs_expr))
{
- codegen_error = true;
+ set_codegen_error ();
  return NULL_TREE;
}
   return fold_build2 (FLOOR_DIV_EXPR, type, tree_lhs_expr, tree_rhs_expr);
@@ -1497,7 +1498,7 @@ get_rename_from_scev (tree old_name, gim
   tree new_expr;
   if (chrec_contains_undetermined (scev))
 {
-  codegen_error = true;
+  set_codegen_error ();
   return build_zero_cst (TREE_TYPE (old_name));
 }
 
@@ -1510,7 +1511,7 @@ get_rename_from_scev (tree old_name, gim
   if (chrec_contains_undetermined (new_expr)
   || tree_contains_chrecs (new_expr, NULL))
 {
-  codegen_error = true;
+  set_codegen_error ();
   return build_zero_cst (TREE_TYPE (old_name));
 }
 
@@ -1519,7 +1520,7 @@ get_rename_from_scev (tree old_name, gim
   basic_block bb = gimple_bb (SSA_NAME_DEF_STMT (new_expr));
   if (bb && !dominated_by_p (CDI_DOMINATORS, new_bb, bb))
{
- codegen_error = true;
+ set_codegen_error ();
  return build_zero_cst (TREE_TYPE (old_name));
}
 }
@@ -1539,7 +1540,7 @@ get_rename_from_scev (tree old_name, gim
  basic_block bb = gimple_bb (SSA_NAME_DEF_STMT (new_ssa_name));
  if (bb && !dominated_by_p (CDI_DOMINATORS, new_bb, bb))
{
- codegen_error = true;
+ set_codegen_error ();
  return build_zero_cst (TREE_TYPE (old_name));
}
}
@@ -1820,8 +1822,8 @@ copy_loop_phi_nodes (basic_block bb, bas
   tree new_res = create_new_def_for (res, new_phi,
 gimple_phi_result_ptr (new_phi));
   set_rename (res, new_res);
-  codegen_error = !copy_loop_phi_args (phi, ibp_old_bb, new_phi,
-  ibp_new_bb, true);
+  if (!copy_loop_phi_args (phi, ibp_old_bb, new_phi, ibp_new_bb, true))
+   set_codegen_error ();
   update_stmt (new_phi);
 
   if (dump_file)
@@ -2593,7 +2595,7 @@ copy_bb_and_scalar_dependences (basic_bl
 outside the region.  */
   if (num_phis)
{
- codegen_error = true;
+ set_codegen_error ();
  return NULL;
}
 }
@@ -2608,7 +2610,7 @@ copy_bb_and_scalar_dependences (basic_bl
   edge e = edge_for_new_close_phis (bb);
   if (!e)
{
- codegen_error = true;
+ set_codegen_error ();
  return NULL;
}
 
@@ -2622,7 +2624,7 @@ copy_bb_and_scalar_dependences (basic_bl
 
   if (!copy_loop_close_phi_nodes (bb, phi_bb, iv_map))
{
- codegen_error = true;
+ set_codegen_error ();
  return NULL;
}
 
@@ -2644,7 +2646,7 @@ copy_bb_an

Re: [PATCH][GRAPHITE] Allow --param graphite-max-arrays-per-scop=0

2017-09-29 Thread Richard Biener
On Thu, 28 Sep 2017, Sebastian Pop wrote:

> On Wed, Sep 27, 2017 at 6:51 AM, Richard Biener  wrote:
> >
> > The following is to allow making --param graphite-max-arrays-per-scop
> > unbounded.  That's a little tricky because the bound is used when
> > computing "alias-sets" for scalar constraints.  There's an easy way
> > out though as we know the maximum alias-set assigned in the SCOP,
> > we only have to remember it.  The advantage (if it matters at all)
> > is that we avoid a constraint coefficient gap between that last
> > used alias-set and the former PARAM_GRAPHITE_MAX_ARRAYS_PER_SCOP.
> >
> > Bootstrap and regtest running on x86_64-unknown-linux-gnu, SPEC CPU 2006
> > tested.  Will apply after testing finished.
> >
> > Richard.
> >
> > 2017-09-27  Richard Biener  
> >
> > * graphite.h (scop::max_alias_set): New member.
> > * graphite-scop-detection.c: Remove references to non-existing
> > --param in comments.
> > (build_alias_sets): Record the maximum alias set used for drs.
> > (build_scops): Support zero as unlimited for
> > --param graphite-max-arrays-per-scop.
> > * graphite-sese-to-poly.c (add_scalar_version_numbers): Remove
> > and inline into ...
> > (build_poly_sr_1): ... here.  Compute alias set based on the
> > maximum alias set used for drs rather than
> > PARAM_GRAPHITE_MAX_ARRAYS_PER_SCOP
> >
> 
> Maybe we should keep this limit, and instead of failing to handle
> huge scops, we could stop the scop detection to expand the
> scop past this limit?

Yes, I believe we should put all the checks we do to discard SCOPs
at SESE region build time and try if smaller regions would fit within
the limits.

Of course it's hard to guess whether ISL will eventually time-out or 
not...

Another check that kills quite many SCOPs in the end is verifying
whether we can handle the dependences - unfortunately that one is
necessarily quadratic in the number of DRs... (hacking this away
as in if we'd do versioning on a proper condition gets us 10 times
more SCOPs in SPEC CPU 2006 but only 50 more transforms because
code-gen errors sky-rocket).

I'm going to leave the limits in place right now as I'm shifting
towards fixing existing code-gen issues at the moment.

Richard.


Patch ping

2017-09-29 Thread Jakub Jelinek
Hi!

I'd like to ping the following patch:

  http://gcc.gnu.org/ml/gcc-patches/2017-09/msg01540.html
  libgcc __mulvDI3 fix - missed detection of overflow for
  0x * 0x
  __builtin_mul_overflow{,_p} fix for the same

Thanks

Jakub


Re: [PATCH] Fix fortran/81509

2017-09-29 Thread Janus Weil
Hi Steve,

> As aside effect, the patch removes a questionable GNU Fortran
> extension that allowed arguments to IAND, IOR, and IEOR to have
> different kind type parameters.  The behavior of this extension
> was not documented.

I don't really like that part. We were using the nice and convenient
mechanism of gfc_notify_std here, which allows the developer to choose
via the -std flag whether to strictly adhere to a chosen Fortran
standard or to allow GNU extensions etc. You're taking away that
flexibility and replacing it by an unconditional error. I don't
actually think that's a good idea.

In general one can argue about whether or not it's a good idea to use
non-std extensions. But I think gfortran should rather leave the
choice to its users, whether they want to use 'dirty and covenient'
code or have very strict checking. We have nice mechanisms for this,
and I do think we should keep them.

Cheers,
Janus



> 2017-09-27  Steven G. Kargl  
>
> PR fortran/81509
> * check.c: Rename function gfc_check_iand to gfc_check_iand_ieor_ior.
> * check.c (boz_args_check): New function.  Check I and J not both BOZ.
> (gfc_check_dshift,gfc_check_iand_ieor_ior, gfc_check_ishft,
>  gfc_check_and, gfc_check_merge_bits): Use it.
> * check.c (gfc_check_iand_ieor_ior): Force conversion of BOZ to kind
> type of other agrument.  Remove silly GNU extension.
> (gfc_check_ieor, gfc_check_ior): Delete now unused functions.
> * intrinsic.c (add_functions): Use gfc_check_iand_ieor_ior. Wrap long
> line.
> * intrinsic.h: Rename gfc_check_iand to gfc_check_iand_ieor_ior.
> Delete prototype for bool gfc_check_ieor and gfc_check_ior
> * intrinsic.texi: Update documentation for boz-literal-constant.
>
> 2017-09-27  Steven G. Kargl  
>
> PR fortran/81509
> * gfortran.dg/graphite/id-26.f03: Fix non-conforming use of IAND.
> * gfortran.dg/pr81509_1.f90: New test.
> * gfortran.dg/pr81509_2.f90: New test.
>
> --
> Steve
> 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
> 20161221 https://www.youtube.com/watch?v=IbCHE-hONow


Re: [PATCH][GRAPHITE] More TLC

2017-09-29 Thread Richard Biener
On Thu, 28 Sep 2017, Sebastian Pop wrote:

> On Wed, Sep 27, 2017 at 9:33 AM, Richard Biener  wrote:
> > Looks like even when hacking the Fortran FE to produce nested
> > ARRAY_REFs we run into the same issue for
> >
> > (gdb) p debug_data_reference (dr)
> > #(Data Ref:
> > #  bb: 17
> > #  stmt:
> > VIEW_CONVERT_EXPR(*y_117(D))[_24]{lb:
> > 1 sz: _20 * 8}[_26]{lb: 1 sz: _21 * 8}[_28]{lb: 1 sz: _22 * 8}[_29]{lb: 1
> > sz: 8} = 0.0;
> > #  ref:
> > VIEW_CONVERT_EXPR(*y_117(D))[_24]{lb:
> > 1 sz: _20 * 8}[_26]{lb: 1 sz: _21 * 8}[_28]{lb: 1 sz: _22 * 8}[_29]{lb: 1
> > sz: 8};
> > #  base_object:
> > VIEW_CONVERT_EXPR(*y_117(D));
> > #  Access function 0: {1, +, 1}_4
> > #  Access function 1: (integer(kind=8)) {(unsigned long) stride.88_92, +,
> > (unsigned long) stride.88_92}_3;
> > #  Access function 2: (integer(kind=8)) {(unsigned long) stride.90_96, +,
> > (unsigned long) stride.90_96}_2;
> > #  Access function 3: (integer(kind=8)) {(unsigned long) stride.92_100, +,
> > (unsigned long) stride.92_100}_1;
> >
> > so it looks like simple strided (where stride is a parameter) access
> > is not handled either.
> 
> Yes, this is the first option I was mentioning: it could work,
> could you please make sure that you don't have a bug in the "hack patch"
> where the outer dimension should not contain the parameter
> (inner array dimension) times the access function.
> 
> Example in C:
> int A[100][N];
> A[i][j] is linearized as *(A + i * N * 4 + j * 4)
> and you may have a bug if you delinearized it in the Fortran FE as A[i * N][j]
> Could you please check that it would delinearize back to A[i][j]?

I fixed the "hack patch" somewhat but realized it's not really possible
ATM to get back at this form because the array descriptor contains only
information to generate the linearized form.  So while I get now correct
values they end up with runtime divisions which aren't handled by
SCEV.

I fear emitting delinearized code from the Fortran FE would be an
ABI breakage as we'd have to change the array descriptor contents.

> >
> > GCCs dependence analysis can at least compute distances of two
> > DRs when the difference of the access CHRECs is constant.  Within
> > the polyhedral model those cases cannot be handled?
> 
> The difficulty for the polyhedral model is in the representation
> of a multiplication of parameter times loop index variable.
> The delinearization removes these difficulties by creating linear expressions.
> 
> Think about multiplication as something introducing exponentiality
> and you realize that any such expression would not fit in the
> linear model of polyhedra.
> A parameter is nothing else than an outer loop index to which we don't
> have access to that loop level as it may be outside the current function
> in which we get that parameter in.

Yeah, I see that now.

Richard.


[PATCH][GRAPHITE] Avoid CHRECs with evolution in loops not in the nest

2017-09-29 Thread Richard Biener

For gcc.dg/graphite/scop-4.c when we analyze data-refs of the fist
two inner loops (with the scalar BB in between)

  for (i = 1; i < 100; i++) /// loop 1
{
-- scop start
  for (j = 1; j < 80; j++)  /// loop 2
a[j][i] = a[j+1][2*i-1*j] + 12;

  b[i] = b[i-1] + 10;

  for (j = 1; j < 60; j++)  /// loop 3
a[j][i] = a[j+1][i-1] + 8;
-- scop end

  bar ();

  if (i == 23)
b[i] = a[i-1][i] + 6;
}

we end up asking data-ref analysis to analyze b[i] and b[i-1] with
respect to loop == nest == 2.  That doesn't make much sense in
itself and thus we get some weird answers.  The one that confuses
us is {0, +, 1}_1 because later when we try to extract_affine_chrec
on that ISL aborts because we feed it -1 as the dimension for the
loop.

While we can with some effort suppress those CHRECs I think the
better solution is to make GRAPHITE not ask SCEV to do this
kind of analysis but consistently analyze DRs in the containing
loop even if that loop is not within the current region.

The idea is that we'd transform the above to

  for (i = 1; i < 100; i++) /// loop 1
{
-- scop start
 do
  {
  i' = i;

  for (j = 1; j < 80; j++)  /// loop 2
a[j][i'] = a[j+1][2*i'-1*j] + 12;

  b[i'] = b[i'-1] + 10;

  for (j = 1; j < 60; j++)  /// loop 3
a[j][i'] = a[j+1][i'-1] + 8;
  }
 while (0);
-- scop end

  bar ();

  if (i == 23)
b[i] = a[i-1][i] + 6;
}

basically wrap each SCOP inside a loop that doesn't iterate.

This should make analyzing the data-refs possible and enable
dependence analysis for them.

I needed to create an extra dimension for this "loop" and
adjust some +- 1 stuff (ugh, this can need some better abstraction...).

On the way the stmt_has_simple_data_refs_p/try_generate_gimple_bb
changes fix PR82355 as well.

The copy_bb_and_scalar_dependences change is to avoid extra
code-gen errors on some existing graphite testcases where we now
perform more elaborate transforms.


I probably started with one of the more difficult code-gen errors
here so bear with my lack of GRAPHITE knowledge.

Does this look reasonable?

Bootstrapped and tested on x86_64-unknown-linux-gnu (with & without
-floop-nest-optimize -fgraphite-identity).

I've verified that the graphite testsuite now has less ICEs when
turning code-gen errors into ICEs.

Results of throwing this onto SPEC CPU 2006 are somewhat hard to
interpret.  Before the patch we see

loop nest optimized: 105
loop nest not optimized, code generation error: 42
loop nest not optimized, optimized schedule is identical to original 
schedule: 119
loop nest not optimized, optimization timed out: 36
loop nest not optimized, ISL signalled an error: 6
loop nest: 308

and after

loop nest optimized: 87
loop nest not optimized, code generation error: 93
loop nest not optimized, optimized schedule is identical to original 
schedule: 216
loop nest not optimized, optimization timed out: 46
loop nest not optimized, ISL signalled an error: 8
loop nest: 450

first of all this means we've rejected fewer SCOPs initially
(very likely because of alias-sets now matching and maybe because
asking SCEV for sth sensible turns out to result in less
scev_not_known stuff in affected DRs).  I'm not sure why
we end up optimizing less (maybe because I don't analyze DRs
in loops contained in the region with respect to the containing loop
as well -- I'd have to pre-compute that loop).

Anyway.

Ok for trunk?

Thanks,
Richard.

2017-09-29  Richard Biener  

PR tree-optimization/82355
* graphite-isl-ast-to-gimple.c (build_iv_mapping): Also build
a mapping for the enclosing loop but avoid generating one for
the loop tree root.
(copy_bb_and_scalar_dependences): Remove premature codegen
error on PHIs in blocks duplicated into multiple places.
* graphite-scop-detection.c
(scop_detection::stmt_has_simple_data_refs_p): For a loop not
in the region use it as loop and nest to analyze the DR in.
(try_generate_gimple_bb): Likewise.
* graphite-sese-to-poly.c (extract_affine_chrec): Adjust.
(add_loop_constraints): For blocks in a loop not in the region
create a dimension with a single iteration.
* sese.h (gbb_loop_at_index): Remove assert.

* gcc.dg/graphite/fuse-1.c: Adjust.
* gcc.dg/graphite/fuse-2.c: Likewise.
* gcc.dg/graphite/pr82355.c: New testcase.

Index: gcc/graphite-isl-ast-to-gimple.c
===
--- gcc/graphite-isl-ast-to-gimple.c(revision 253282)
+++ gcc/graphite-isl-ast-to-gimple.c(working copy)
@@ -774,8 +775,10 @@ build_iv_mapping (vec iv_map, gimp
   if (codegen_error_p ())
t = integer_zero_node;
 
-  loop_p old_loop = gbb_loop_at_index (gbb, region, i - 1);
-  iv_map[old_loop->num] = t;
+  loop_p old_loop = gbb_loop_at_index (gbb, region, i - 2);
+  /* Record sth onl

Re: [PATCH] Fix PR82337 (SLSR and abnormal PHIs)

2017-09-29 Thread Richard Biener
On Wed, Sep 27, 2017 at 9:15 PM, Bill Schmidt
 wrote:
> Hi,
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82337 reports a problem
> with SLSR performing an invalid optimization across an abnormal PHI.
> This is easy to avoid by ensuring that SSA names used in an abnormal
> PHI never appear as a basis or as a PHI basis in the candidate table.
> We won't optimize what we can't see...
>
> I've cleaned up the test case in the bug report so that it compiles
> without warnings and added it to the torture tests.  Bootstrapped and
> tested on powerpc64le-linux-gnu with no regressions.  Is this ok for
> trunk?  I would also like to backport it to all open releases after a
> short wait.

Ok for trunk and branches.

Thanks,
Richard.

> Thanks,
> Bill
>
>
> 2017-09-26  Bill Schmidt  
>
> PR tree-optimization/82337
> * gimple-ssa-strength-reduction.c (find_phi_def): Don't record a
> phi definition if the PHI result appears in an abnormal PHI.
> (find_basis_for_base_expr): Don't record a basis if the LHS of the
> basis appears in an abnormal PHI.
>
>
> Index: gcc/gimple-ssa-strength-reduction.c
> ===
> --- gcc/gimple-ssa-strength-reduction.c (revision 253232)
> +++ gcc/gimple-ssa-strength-reduction.c (working copy)
> @@ -488,7 +488,8 @@ find_phi_def (tree base)
>
>c = base_cand_from_table (base);
>
> -  if (!c || c->kind != CAND_PHI)
> +  if (!c || c->kind != CAND_PHI
> +  || SSA_NAME_OCCURS_IN_ABNORMAL_PHI (gimple_phi_result (c->cand_stmt)))
>  return 0;
>
>return c->cand_num;
> @@ -557,6 +558,11 @@ find_basis_for_base_expr (slsr_cand_t c, tree base
>   gimple_bb (one_basis->cand_stmt)))
> continue;
>
> +  tree lhs = gimple_assign_lhs (one_basis->cand_stmt);
> +  if (lhs && TREE_CODE (lhs) == SSA_NAME
> + && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (lhs))
> +   continue;
> +
>if (!basis || basis->cand_num < one_basis->cand_num)
> basis = one_basis;
>  }
> Index: gcc/testsuite/gcc.c-torture/compile/pr82337.c
> ===
> --- gcc/testsuite/gcc.c-torture/compile/pr82337.c   (nonexistent)
> +++ gcc/testsuite/gcc.c-torture/compile/pr82337.c   (working copy)
> @@ -0,0 +1,25 @@
> +/* PR82337: SLSR needs to prevent abnormal SSA names from
> +   serving as a basis. */
> +char *a, *b, *c;
> +
> +struct d {
> +  short e;
> +  char f[];
> +};
> +
> +extern void j (void);
> +
> +void
> +g() {
> +  struct d *h;
> +  char *i;
> +  int d;
> +  do {
> +i = h->f + d;
> +20 ? j() : 0;
> +i = c;
> +if (__builtin_setjmp (h))
> +  b = h->f + d;
> +d = (int)(*i);
> +  } while (a);
> +}
>


[C++ PATCH] C++2A P0683R1 - default member initializers for bit-fields (take 2)

2017-09-29 Thread Jakub Jelinek
Hi!

On Wed, Sep 27, 2017 at 07:55:20AM -0700, Nathan Sidwell wrote:
>   1) fix the parsing bug you found and move to (ab)using
> DECL_BIT_FIELD_REPRESENTATIVE
> 
>   2) the new c++2a feature

And here is the 2) patch, on top of the previous 3 ones. 
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2017-09-29  Jakub Jelinek  

P0683R1 - default member initializers for bit-fields
cp/
* cp-tree.h (grokbitfield): Add INIT parameter.
* parser.c (cp_parser_constant_expression): Add STRICT_P argument,
if true, parse a conditional-expression rather than
assignment-expression.
(cp_parser_member_declaration): For C++11 and later pass true
as STRICT_P to cp_parser_constant_expression.  Parse C++2A bitfield
NSDMIs.  Adjust grokbitfield caller.  Handle DECL_INITIAL also for
DECL_C_BIT_FIELDs.
(cp_parser_objc_class_ivars): Adjust grokbitfield caller.
* class.c (check_field_decl): Recurse even for DECL_C_BIT_FIELDs.
(check_field_decls): Call check_field_decl even for DECL_C_BIT_FIELDs.
* decl2.c (grokbitfield): Add INIT parameter, pass it to
cp_finish_decl.
* pt.c (tsubst_decl): Handle DECL_INITIAL for all FIELD_DECLs, not
just non-bitfields.
testsuite/
* g++.dg/ext/bitfield6.C: New test.
* g++.dg/cpp2a/bitfield1.C: New test.
* g++.dg/cpp2a/bitfield2.C: New test.
* g++.dg/cpp2a/bitfield3.C: New test.

--- gcc/cp/cp-tree.h.jj 2017-09-29 09:07:33.554063918 +0200
+++ gcc/cp/cp-tree.h2017-09-29 10:24:26.846373177 +0200
@@ -6159,7 +6159,7 @@ extern void check_member_template (tree
 extern tree grokfield (const cp_declarator *, cp_decl_specifier_seq *,
   tree, bool, tree, tree);
 extern tree grokbitfield (const cp_declarator *, cp_decl_specifier_seq *,
- tree, tree);
+ tree, tree, tree);
 extern bool any_dependent_type_attributes_p(tree);
 extern tree cp_reconstruct_complex_type(tree, tree);
 extern bool attributes_naming_typedef_ok   (tree);
--- gcc/cp/parser.c.jj  2017-09-29 09:47:43.978411525 +0200
+++ gcc/cp/parser.c 2017-09-29 10:55:51.364348848 +0200
@@ -2089,7 +2089,7 @@ static enum tree_code cp_parser_assignme
 static cp_expr cp_parser_expression
   (cp_parser *, cp_id_kind * = NULL, bool = false, bool = false);
 static cp_expr cp_parser_constant_expression
-  (cp_parser *, bool = false, bool * = NULL);
+  (cp_parser *, bool = false, bool * = NULL, bool = false);
 static cp_expr cp_parser_builtin_offsetof
   (cp_parser *);
 static cp_expr cp_parser_lambda_expression
@@ -9626,12 +9626,15 @@ cp_parser_expression (cp_parser* parser,
   If ALLOW_NON_CONSTANT_P a non-constant expression is silently
   accepted.  If ALLOW_NON_CONSTANT_P is true and the expression is not
   constant, *NON_CONSTANT_P is set to TRUE.  If ALLOW_NON_CONSTANT_P
-  is false, NON_CONSTANT_P should be NULL.  */
+  is false, NON_CONSTANT_P should be NULL.  If STRICT_P is true,
+  only parse a conditional-expression, otherwise parse an
+  assignment-expression.  See below for rationale.  */
 
 static cp_expr
 cp_parser_constant_expression (cp_parser* parser,
   bool allow_non_constant_p,
-  bool *non_constant_p)
+  bool *non_constant_p,
+  bool strict_p)
 {
   bool saved_integral_constant_expression_p;
   bool saved_allow_non_integral_constant_expression_p;
@@ -9665,16 +9668,27 @@ cp_parser_constant_expression (cp_parser
   parser->allow_non_integral_constant_expression_p
 = (allow_non_constant_p || cxx_dialect >= cxx11);
   parser->non_integral_constant_expression_p = false;
-  /* Although the grammar says "conditional-expression", we parse an
- "assignment-expression", which also permits "throw-expression"
- and the use of assignment operators.  In the case that
- ALLOW_NON_CONSTANT_P is false, we get better errors than we would
+  /* Although the grammar says "conditional-expression", when not STRICT_P,
+ we parse an "assignment-expression", which also permits
+ "throw-expression" and the use of assignment operators.  In the case
+ that ALLOW_NON_CONSTANT_P is false, we get better errors than we would
  otherwise.  In the case that ALLOW_NON_CONSTANT_P is true, it is
  actually essential that we look for an assignment-expression.
  For example, cp_parser_initializer_clauses uses this function to
  determine whether a particular assignment-expression is in fact
  constant.  */
-  expression = cp_parser_assignment_expression (parser);
+  if (strict_p)
+{
+  /* Parse the binary expressions (logical-or-expression).  */
+  expression = cp_parser_binary_expression (parser, false, false, false,
+   PREC_NOT_OPERATOR, NULL);
+  /* If the next token

Re: [PATCH] Improve -Ofast vectorization of std::sin etc. (PR libstdc++/81706)

2017-09-29 Thread Jakub Jelinek
On Tue, Sep 12, 2017 at 09:49:20AM +0200, Jakub Jelinek wrote:
> On Sat, Sep 09, 2017 at 03:42:35PM +0200, Jason Merrill wrote:
> > On Fri, Sep 1, 2017 at 1:12 PM, Jakub Jelinek  wrote:
> > > + tree s = lookup_attribute ("omp declare simd",
> > > +DECL_ATTRIBUTES (newdecl));
> > > + if (s)
> > > +   {
> > > + tree b
> > > +   = builtin_decl_explicit (DECL_FUNCTION_CODE 
> > > (newdecl));
> > > + if (b)
> > > +   duplicate_one_attribute (&DECL_ATTRIBUTES (b), s,
> > > +"omp declare simd");
> > > +   }
> > 
> > Is there a reason not to set b first and move the lookup of s into the
> > function as well?
> 
> I wanted to handle the most common case (no DECL_ATTRIBUTES at all) and the
> second most common case (lookup_attribute returning NULL) inline, otherwise
> we'll do an extra function call for all builtins in all cases.
> But if you strongly prefer that lookup to be in duplicate_one_attribute,
> I can change the patch and retest.

Here is a patch which does that.  Also bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?

2017-09-29  Jakub Jelinek  

PR libstdc++/81706
* attribs.c (attribute_value_equal): Use omp_declare_simd_clauses_equal
for comparison of OMP_CLAUSEs regardless of flag_openmp{,_simd}.
(duplicate_one_attribute): New function.
* attribs.h (duplicate_one_attribute): New declaration.

* c-decl.c (merge_decls): Copy "omp declare simd" attributes from
newdecl to corresponding __builtin_ if any.

* decl.c (duplicate_decls): Copy "omp declare simd" attributes from
newdecl to corresponding __builtin_ if any.

* gcc.target/i386/pr81706.c: New test.
* g++.dg/ext/pr81706.C: New test.

--- gcc/attribs.c.jj2017-09-12 21:57:57.872456129 +0200
+++ gcc/attribs.c   2017-09-29 11:20:02.163793301 +0200
@@ -1125,9 +1125,9 @@ attribute_value_equal (const_tree attr1,
 TREE_VALUE (attr2)) == 1);
 }
 
-  if ((flag_openmp || flag_openmp_simd)
-  && TREE_VALUE (attr1) && TREE_VALUE (attr2)
+  if (TREE_VALUE (attr1)
   && TREE_CODE (TREE_VALUE (attr1)) == OMP_CLAUSE
+  && TREE_VALUE (attr2)
   && TREE_CODE (TREE_VALUE (attr2)) == OMP_CLAUSE)
 return omp_declare_simd_clauses_equal (TREE_VALUE (attr1),
   TREE_VALUE (attr2));
@@ -1319,6 +1319,32 @@ merge_decl_attributes (tree olddecl, tre
   DECL_ATTRIBUTES (newdecl));
 }
 
+/* Duplicate all attributes with name NAME in ATTR list to *ATTRS if
+   they are missing there.  */
+
+void
+duplicate_one_attribute (tree *attrs, tree attr, const char *name)
+{
+  attr = lookup_attribute (name, attr);
+  if (!attr)
+return;
+  tree a = lookup_attribute (name, *attrs);
+  while (attr)
+{
+  tree a2;
+  for (a2 = a; a2; a2 = lookup_attribute (name, TREE_CHAIN (a2)))
+   if (attribute_value_equal (attr, a2))
+ break;
+  if (!a2)
+   {
+ a2 = copy_node (attr);
+ TREE_CHAIN (a2) = *attrs;
+ *attrs = a2;
+   }
+  attr = lookup_attribute (name, TREE_CHAIN (attr));
+}
+}
+
 #if TARGET_DLLIMPORT_DECL_ATTRIBUTES
 
 /* Specialization of merge_decl_attributes for various Windows targets.
--- gcc/attribs.h.jj2017-09-12 21:57:57.872456129 +0200
+++ gcc/attribs.h   2017-09-29 11:19:27.965206860 +0200
@@ -77,6 +77,11 @@ extern tree remove_attribute (const char
 
 extern tree merge_attributes (tree, tree);
 
+/* Duplicate all attributes with name NAME in ATTR list to *ATTRS if
+   they are missing there.  */
+
+extern void duplicate_one_attribute (tree *, tree, const char *);
+
 /* Given two Windows decl attributes lists, possibly including
dllimport, return a list of their union .  */
 extern tree merge_dllimport_decl_attributes (tree, tree);
--- gcc/c/c-decl.c.jj   2017-09-29 09:57:12.582423577 +0200
+++ gcc/c/c-decl.c  2017-09-29 11:21:17.525881957 +0200
@@ -2569,6 +2569,13 @@ merge_decls (tree newdecl, tree olddecl,
set_builtin_decl_declared_p (fncode, true);
  break;
}
+
+ tree b
+   = builtin_decl_explicit (DECL_FUNCTION_CODE (newdecl));
+ if (b)
+   duplicate_one_attribute (&DECL_ATTRIBUTES (b),
+DECL_ATTRIBUTES (newdecl),
+"omp declare simd");
}
}
  else
--- gcc/cp/decl.c.jj2017-09-29 09:07:33.530064213 +0200
+++ gcc/cp/decl.c   2017-09-29 11:21:55.618421309 +0200
@@ -2470,6 +2470,12 @@ next_arg:;
  break;
}
}
+
+ tree b = builtin

Re: [LIBGO PATCH] Fix compilation error against uClibc-ng: runtime_sysinfo.go: error: use of undefined type ‘___uclibc_locale_struct’

2017-09-29 Thread Ian Lance Taylor
On Fri, Sep 29, 2017 at 1:38 AM, Alex Potapenko  wrote:
>
> Building GCC 7.2.0 libgo against uClibc-ng 1.0.26 results in the following
> error:
>
>> runtime_sysinfo.go:418:17: error: use of undefined type
>> ‘___uclibc_locale_struct’
>
>
> This happens because -fdump-go-spec probably generates types only from
> typedef declarations, ignoring structs, like "struct
> __uclibc_locale_struct;" in uClibc-ng  header. Adding
> "typedef struct __uclibc_locale_struct __uclibc_locale_struct;" to
> libgo/sysinfo.c remedies this issue:
>
> --- a/libgo/sysinfo.c
> +++ b/libgo/sysinfo.c
> @@ -277,3 +277,7 @@
>epoll_data_offset = offsetof(struct epoll_event, data)
>  };
>  #endif
> +
> +#ifdef __UCLIBC__
> +typedef struct __uclibc_locale_struct __uclibc_locale_struct;
> +#endif

-fdump-go-spec doesn't ignore structs, so I feel like there may be
something else going on.  Could you send the generated gen-sysinfo.go
file (without your patch)?  Thanks.

Ian


Re: [PATCH][GRAPHITE] Avoid CHRECs with evolution in loops not in the nest

2017-09-29 Thread Richard Biener
On Fri, 29 Sep 2017, Richard Biener wrote:

> 
> For gcc.dg/graphite/scop-4.c when we analyze data-refs of the fist
> two inner loops (with the scalar BB in between)
> 
>   for (i = 1; i < 100; i++) /// loop 1
> {
> -- scop start
>   for (j = 1; j < 80; j++)  /// loop 2
> a[j][i] = a[j+1][2*i-1*j] + 12;
> 
>   b[i] = b[i-1] + 10;
> 
>   for (j = 1; j < 60; j++)  /// loop 3
> a[j][i] = a[j+1][i-1] + 8;
> -- scop end
> 
>   bar ();
> 
>   if (i == 23)
> b[i] = a[i-1][i] + 6;
> }
> 
> we end up asking data-ref analysis to analyze b[i] and b[i-1] with
> respect to loop == nest == 2.  That doesn't make much sense in
> itself and thus we get some weird answers.  The one that confuses
> us is {0, +, 1}_1 because later when we try to extract_affine_chrec
> on that ISL aborts because we feed it -1 as the dimension for the
> loop.
> 
> While we can with some effort suppress those CHRECs I think the
> better solution is to make GRAPHITE not ask SCEV to do this
> kind of analysis but consistently analyze DRs in the containing
> loop even if that loop is not within the current region.
> 
> The idea is that we'd transform the above to
> 
>   for (i = 1; i < 100; i++) /// loop 1
> {
> -- scop start
>  do
>   {
>   i' = i;
> 
>   for (j = 1; j < 80; j++)  /// loop 2
> a[j][i'] = a[j+1][2*i'-1*j] + 12;
> 
>   b[i'] = b[i'-1] + 10;
> 
>   for (j = 1; j < 60; j++)  /// loop 3
> a[j][i'] = a[j+1][i'-1] + 8;
>   }
>  while (0);
> -- scop end
> 
>   bar ();
> 
>   if (i == 23)
> b[i] = a[i-1][i] + 6;
> }
> 
> basically wrap each SCOP inside a loop that doesn't iterate.
> 
> This should make analyzing the data-refs possible and enable
> dependence analysis for them.
> 
> I needed to create an extra dimension for this "loop" and
> adjust some +- 1 stuff (ugh, this can need some better abstraction...).
> 
> On the way the stmt_has_simple_data_refs_p/try_generate_gimple_bb
> changes fix PR82355 as well.
> 
> The copy_bb_and_scalar_dependences change is to avoid extra
> code-gen errors on some existing graphite testcases where we now
> perform more elaborate transforms.
> 
> 
> I probably started with one of the more difficult code-gen errors
> here so bear with my lack of GRAPHITE knowledge.
> 
> Does this look reasonable?
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu (with & without
> -floop-nest-optimize -fgraphite-identity).
> 
> I've verified that the graphite testsuite now has less ICEs when
> turning code-gen errors into ICEs.
> 
> Results of throwing this onto SPEC CPU 2006 are somewhat hard to
> interpret.  Before the patch we see
> 
> loop nest optimized: 105
> loop nest not optimized, code generation error: 42
> loop nest not optimized, optimized schedule is identical to original 
> schedule: 119
> loop nest not optimized, optimization timed out: 36
> loop nest not optimized, ISL signalled an error: 6
> loop nest: 308
> 
> and after
> 
> loop nest optimized: 87
> loop nest not optimized, code generation error: 93
> loop nest not optimized, optimized schedule is identical to original 
> schedule: 216
> loop nest not optimized, optimization timed out: 46
> loop nest not optimized, ISL signalled an error: 8
> loop nest: 450
> 
> first of all this means we've rejected fewer SCOPs initially
> (very likely because of alias-sets now matching and maybe because
> asking SCEV for sth sensible turns out to result in less
> scev_not_known stuff in affected DRs).  I'm not sure why
> we end up optimizing less (maybe because I don't analyze DRs
> in loops contained in the region with respect to the containing loop
> as well -- I'd have to pre-compute that loop).

So fixing the build_iv_mapping hunk to

  /* Record sth only for real loops.  */
  if (loop_in_sese_p (old_loop, region))
iv_map[old_loop->num] = t;

changes statistics to a favorable

loop nest optimized: 134
loop nest not optimized, code generation error: 46
loop nest not optimized, optimized schedule is identical to original 
schedule: 216
loop nest not optimized, optimization timed out: 46
loop nest not optimized, ISL signalled an error: 8
loop nest: 450

Consider the patch changed that way.

I guess I'll add a -fgraphite-no-codegen-error to force ICEing on them
and enable that on the graphite.exp testcases while explicitely
sticking on a -fno-graphite-no-codegen-error on those who'll ICE
and scan for a codegen error message on them.

That makes it easier to avoid regressing in that area.

Richard.

> Anyway.
> 
> Ok for trunk?
> 
> Thanks,
> Richard.
> 
> 2017-09-29  Richard Biener  
> 
>   PR tree-optimization/82355
>   * graphite-isl-ast-to-gimple.c (build_iv_mapping): Also build
>   a mapping for the enclosing loop but avoid generating one for
>   the loop tree root.
>   (copy_bb_and_scalar_dependences): Remove premature codegen
>   error on PHIs in blocks duplicated into multiple places.
>   *

[Ada] Spurious error in nested generic containing expression function

2017-09-29 Thread Pierre-Marie de Rodat
This patch removes spurious visibility errors from the instantiation of a
generic package nested within another generic, when the inner package
contains an expression function that is the completion of a visible
function of that package, and the expression includes an object of a
tagged type local to the generic.

No small example available.

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-09-29  Ed Schonberg  

* sem_ch6.adb (Analyze_Expression_Function): Do not emit freeze nodes
for types in expression if the function is within a generic unit.
* sem_res.adb (Resolve): In a generic context do not freeze an
expression, unless it is an entity. This exception is solely for the
purpose of detecting illegal uses of deferred constants in generic
units.
* sem_res.adb: Minor reformatting.

Index: sem_ch6.adb
===
--- sem_ch6.adb (revision 253283)
+++ sem_ch6.adb (working copy)
@@ -568,8 +568,11 @@
  --  Note that we cannot defer this freezing to the analysis of the
  --  expression itself, because a freeze node might appear in a nested
  --  scope, leading to an elaboration order issue in gigi.
+ --  As elsewhere, we do not emit freeze nodes within a generic unit.
 
- Freeze_Expr_Types (Def_Id);
+ if not Inside_A_Generic then
+Freeze_Expr_Types (Def_Id);
+ end if;
 
  --  For navigation purposes, indicate that the function is a body
 
Index: sem_res.adb
===
--- sem_res.adb (revision 253283)
+++ sem_res.adb (working copy)
@@ -3070,8 +3070,15 @@
  --  Here we are resolving the corresponding expanded body, so we do
  --  need to perform normal freezing.
 
- Freeze_Expression (N);
+ --  As elsewhere we do not emit freeze node within a generic. We make
+ --  an exception for entities that are expressions, only to detect
+ --  misuses of deferred constants and preserve the output of various
+ --  tests.
 
+ if not Inside_A_Generic or else Is_Entity_Name (N) then
+Freeze_Expression (N);
+ end if;
+
  --  Now we can do the expansion
 
  Expand (N);


Re: [RFA gfortran] PR 25071: dummy argument larger than actual argument

2017-09-29 Thread Dominique d'Humières
Thanks for the quick review. The change logs are

2017-09-29  Dominique d'Humieres  

PR fortran/25071
* interface.c (compare_actual_formal): Change warnings to errors
when "Actual argument contains too few elements for dummy
argument", unless -std=legacy is used.

2017-09-29  Dominique d'Humieres  

PR fortran/25071
* gfortran.dg/argument_checking_3.f90: Change warnings to errors.
* gfortran.dg/argument_checking_4.f90: Likewise.
* gfortran.dg/argument_checking_5.f90: Likewise.
* gfortran.dg/argument_checking_6.f90: Likewise.
* gfortran.dg/argument_checking_10.f90: Likewise.
* gfortran.dg/argument_checking_13.f90: Likewise.
* gfortran.dg/argument_checking_15.f90: Likewise.
* gfortran.dg/argument_checking_18.f90: Likewise.
* gfortran.dg/gomp/udr8.f90: Likewise.
* gfortran.dg/warn_argument_mismatch_1.f90: Add -std=legacy to
the dg-options.

Dominique

> Le 28 sept. 2017 à 14:57, Dominique d'Humières  a écrit :
> 
> Hi all,
> 
> In the PR there was some consensus to turn the warnings into errors. 
> 
> This is what the patch does: the warnings are kept with -std=legacy, errors 
> are emitted otherwise.
> I am sure it may exist a better solution, but I did not find it. 
> 
> While regtesting I have found several regressions on top of 
> gfortran.dg/warn_argument_mismatch_1.f90
> 
> At this point, I had two options: use -std=legacy everywhere or replace the 
> dg-warning with dg-error. I have chosen the later except for 
> warn_argument_mismatch_1.f90.
> 
> Regtested on x86_64-apple-darwin16.
> 
> Comments are welcome and I’ll provide the change logs once the dust has 
> settled.
> 
> TIA
> 
> Dominique
> 



[patch committed FT32] Add watchdog vector and FT930 support

2017-09-29 Thread James Bowman
The attached patch adds a watchdog reset vector and FT930 support
to the base interrupt code.

[libgcc]

2017-09-28  James Bowman  

* config/ft32/crti-hw.S: Add watchdog vector, FT930
IRQ support.

Index: libgcc/config/ft32/crti-hw.S
===
--- libgcc/config/ft32/crti-hw.S(revision 253084)
+++ libgcc/config/ft32/crti-hw.S(working copy)
@@ -1,8 +1,8 @@
 .global _start
 _start:
 # START Interrupt Vector Table [[
-jmp __PMSIZE-4
-jmp watchdog_init
+jmp __PMSIZE-4 # RESET Vector
+jmp interrupt_33   # Watchdog reset vector
 jmp interrupt_0
 jmp interrupt_1
 jmp interrupt_2
@@ -35,24 +35,29 @@
 jmp interrupt_29
 jmp interrupt_30
 jmp interrupt_31
-jmp __PMSIZE-8
+jmp __PMSIZE-8 # Interrupt vector 32 (NMI)
 # ]] END Interrupt Vector Table
 
 codestart:
 jmpinit
-
+
 .global _exithook
 _exithook:   # Debugger uses '_exithook' at 0x90 to catch program 
exit
 return
-
-watchdog_init:
-ldk$r0,1
+
 init:
 ldk $sp,__RAMSIZE
 # Disable all interrupts
-ldk $r4,0x80
-sta.b   0x100e3,$r4
-
+lda   $r1,0x1
+lshr  $r1,$r1,20
+cmp   $r1,0x90
+ldk   $r1,0x100e3   # FT900 IRQ Control Register
+jmpc  z,1f
+ldk   $r1,0x10123   # FT930 IRQ Control Register
+1:
+ldk   $r4,0x80
+sti.b $r1,0,$r4
+
 # Initialize DATA by copying from program memory
 ldk.l   $r4,__data_load_start
 ldk.l   $r1,__data_load_end
@@ -139,6 +144,7 @@
 inth30
 inth31
 inth32
+inth33
 
 # On entry: r0, already saved, holds the handler function
 interrupt_common:
@@ -182,7 +188,7 @@
 .section .data
 .global vector_table
 vector_table:
-.rept 33
+.rept 34
 .long   nullvector
 .endr
 


[Ada] Compiler hangs on evaluation of use-clause within package context

2017-09-29 Thread Pierre-Marie de Rodat
Due to the installation order of packages within a context clause it is
possible to create circularities within the Prev_Use_Clause clain. This patch
corrects this issue by identifying this case through the use of an extra check.

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-09-29  Justin Squirek  

* sem_ch8.adb (Analyze_Use_Package): Add sanity check to avoid
circularities in the use-clause chain.

Index: sem_ch8.adb
===
--- sem_ch8.adb (revision 253285)
+++ sem_ch8.adb (working copy)
@@ -3782,9 +3782,10 @@
   --  before setting its previous use clause.
 
   if Ekind (Pack) = E_Package
- and then Present (Current_Use_Clause (Pack))
- and then Current_Use_Clause (Pack) /= N
- and then No (Prev_Use_Clause (N))
+and then Present (Current_Use_Clause (Pack))
+and then Current_Use_Clause (Pack) /= N
+and then No (Prev_Use_Clause (N))
+and then Prev_Use_Clause (Current_Use_Clause (Pack)) /= N
   then
  Set_Prev_Use_Clause (N, Current_Use_Clause (Pack));
   end if;


[Ada] Pragma Unchecked_Union on derived discriminated type

2017-09-29 Thread Pierre-Marie de Rodat
The compiler reports an spurious error processing a derived type
of a non-tagged record type that has discriminants, pragma
Unchecked_Union and pragma Convention C.

After this patch the following test compiles silently.

procedure Conversion is
   type small_array is array (0 .. 2) of Integer;
   type big_array   is array (0 .. 3) of Integer;

   type small_record is record
  field1 : aliased Integer := 0;
  field2 : aliased small_array := (0, 0, 0);
   end record;

   type big_record is record
  field1 : aliased Integer   := 0;
  field2 : aliased big_array := (0, 0, 0, 0);
   end record;

   type myUnion (discr : Integer := 0) is record
  case discr is
 when 0 =>
record1 : aliased small_record;
 when others =>
record2 : aliased big_record;
  end case;
   end record;

   type UU_myUnion3 (discr : Integer := 0) is new myUnion (discr); -- Test
   pragma Unchecked_Union (UU_myUnion3);
   pragma Convention (C, UU_myUnion3);

   procedure Convert (A : in UU_myUnion3; B : out UU_myUnion3);
   pragma Import (C, Convert);

begin
   null;
end Conversion;

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

2017-09-29  Javier Miranda  

* sem_ch3.adb (Replace_Components): Update references to discriminants
located in variant parts inherited from the parent type.

gcc/testsuite/

2017-09-29  Javier Miranda  

* gnat.dg/unchecked_union2.adb: New testcase.
Index: sem_ch3.adb
===
--- sem_ch3.adb (revision 253283)
+++ sem_ch3.adb (working copy)
@@ -21932,6 +21932,17 @@
Next_Discriminant (Comp);
 end loop;
 
+ elsif Nkind (N) = N_Variant_Part then
+Comp := First_Discriminant (Typ);
+while Present (Comp) loop
+   if Chars (Comp) = Chars (Name (N)) then
+  Set_Entity (Name (N), Comp);
+  exit;
+   end if;
+
+   Next_Component (Comp);
+end loop;
+
  elsif Nkind (N) = N_Component_Declaration then
 Comp := First_Component (Typ);
 while Present (Comp) loop
Index: ../testsuite/gnat.dg/unchecked_union2.adb
===
--- ../testsuite/gnat.dg/unchecked_union2.adb   (revision 0)
+++ ../testsuite/gnat.dg/unchecked_union2.adb   (revision 0)
@@ -0,0 +1,35 @@
+--  { dg-do compile }
+
+procedure Unchecked_Union2 is
+   type small_array is array (0 .. 2) of Integer;
+   type big_array   is array (0 .. 3) of Integer;
+
+   type small_record is record
+  field1 : aliased Integer := 0;
+  field2 : aliased small_array := (0, 0, 0);
+   end record;
+
+   type big_record is record
+  field1 : aliased Integer   := 0;
+  field2 : aliased big_array := (0, 0, 0, 0);
+   end record;
+
+   type myUnion (discr : Integer := 0) is record
+  case discr is
+ when 0 =>
+record1 : aliased small_record;
+ when others =>
+record2 : aliased big_record;
+  end case;
+   end record;
+
+   type UU_myUnion3 (discr : Integer := 0) is new myUnion (discr); -- Test
+   pragma Unchecked_Union (UU_myUnion3);
+   pragma Convention (C, UU_myUnion3);
+
+   procedure Convert (A : in UU_myUnion3; B : out UU_myUnion3);
+   pragma Import (C, Convert);
+
+begin
+   null;
+end Unchecked_Union2;


[Ada] Copy of Unchecked_Union derived discriminated types

2017-09-29 Thread Pierre-Marie de Rodat
The compiler crashes processing an assignment to a discriminated
record type that has pragma Unchecked_Union and Convention C and
is a derivation of a non-tagged record type with discriminants.

After this patch the following test compiles silently.

procedure Conversion is
   type small_array is array (0 .. 2) of Integer;
   type big_array   is array (0 .. 3) of Integer;

   type small_record is record
  field1 : aliased Integer := 0;
  field2 : aliased small_array := (0, 0, 0);
   end record;

   type big_record is record
  field1 : aliased Integer   := 0;
  field2 : aliased big_array := (0, 0, 0, 0);
   end record;

   type myUnion (discr : Integer := 0) is record
  case discr is
 when 0 =>
record1 : aliased small_record;
 when others =>
record2 : aliased big_record;
  end case;
   end record;

   type UU_myUnion1 is new myUnion;
   pragma Unchecked_Union (UU_myUnion1);
   pragma Convention (C, UU_myUnion1);

   procedure Convert (A : in myUnion; B : out UU_myUnion1) is
  L : UU_myUnion1 := UU_myUnion1 (A);  --  Test
   begin
  B := L;
   end Convert;

begin
   null;
end Conversion;

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

2017-09-29  Javier Miranda  

* exp_ch5.adb (Expand_Assign_Record): Do not generate code to copy
discriminants if the target is an Unchecked_Union record type.

gcc/testsuite/

2017-09-29  Javier Miranda  

* gnat.dg/unchecked_union3.adb: New testcase.
Index: exp_ch5.adb
===
--- exp_ch5.adb (revision 253283)
+++ exp_ch5.adb (working copy)
@@ -1577,7 +1577,14 @@
  --  suppressed in this case). It is unnecessary but harmless in
  --  other cases.
 
- if Has_Discriminants (L_Typ) then
+ --  Special case: no copy if the target has no discriminants.
+
+ if Has_Discriminants (L_Typ)
+   and then Is_Unchecked_Union (Base_Type (L_Typ))
+ then
+null;
+
+ elsif Has_Discriminants (L_Typ) then
 F := First_Discriminant (R_Typ);
 while Present (F) loop
 
Index: ../testsuite/gnat.dg/unchecked_union3.adb
===
--- ../testsuite/gnat.dg/unchecked_union3.adb   (revision 0)
+++ ../testsuite/gnat.dg/unchecked_union3.adb   (revision 0)
@@ -0,0 +1,38 @@
+--  { dg-do compile }
+
+procedure Unchecked_Union3 is
+   type small_array is array (0 .. 2) of Integer;
+   type big_array   is array (0 .. 3) of Integer;
+
+   type small_record is record
+  field1 : aliased Integer := 0;
+  field2 : aliased small_array := (0, 0, 0);
+   end record;
+
+   type big_record is record
+  field1 : aliased Integer   := 0;
+  field2 : aliased big_array := (0, 0, 0, 0);
+   end record;
+
+   type myUnion (discr : Integer := 0) is record
+  case discr is
+ when 0 =>
+record1 : aliased small_record;
+ when others =>
+record2 : aliased big_record;
+  end case;
+   end record;
+
+   type UU_myUnion1 is new myUnion;
+   pragma Unchecked_Union (UU_myUnion1);
+   pragma Convention (C, UU_myUnion1);
+
+   procedure Convert (A : in myUnion; B : out UU_myUnion1) is
+  L : UU_myUnion1 := UU_myUnion1 (A);  --  Test
+   begin
+  B := L;
+   end Convert;
+
+begin
+   null;
+end Unchecked_Union3;


[Ada] Crash on illegal use of iterated component association

2017-09-29 Thread Pierre-Marie de Rodat
An iterated component association is an Ada2020 extension that simplifies
the construction of array aggregates.  This patch properly rejects the use
of this construct as a named association in an aggregate for a record type.

compiling
   gcc -c -gnat2020 klurigt-m2.adb

must yield:

   klurigt-m2.adb:11:12:
 iterated component association can only appear in an array aggregate
   compilation abandoned

---
with Klurigt.Conv;use Klurigt.Conv;
procedure Klurigt.M2 is

   function Bar_Of
 (Bar : in Bar_Type)
  return My_Bar_Type
   is
   begin
  return Result : constant My_Bar_Type
:= (for Index in 1 .. Foo_Index_Type (Bar.Foos'Last) =>
Foo_Of (Bar.Foos (Foo_Index_Type (Index
  do
 null;
  end return; 
   end Bar_Of;
begin
   null;
end Klurigt.M2;
---
package Klurigt is
   type Foo_Type
   is record
  Kalle : Natural := 0;
  Olle  : Integer := 0;
   end record;

   type Foo_Index_Type is new Natural;

   MAX_FOO_ARRAY_SIZE : constant Foo_Index_Type := 10;

   type Foo_Array_Type is array (1 .. MAX_FOO_ARRAY_SIZE) of Foo_Type;

   type Bar_Type
   is record
  Foos : Foo_Array_Type;
   end record;

   type My_Natural_Type is new Natural;
   type My_Integer_Type is new Integer;

   type My_Foo_Type
   is record
  Kalle : My_Natural_Type := 0;
  Olle  : My_Integer_Type := 0;
   end record;

   type My_Foo_Array_Index_Type is new Integer;

   MAX_MY_FOO_ARRAY_SIZE : constant My_Foo_Array_Index_Type := 10;

   type My_Foo_Array_Type is array (1 .. MAX_MY_FOO_ARRAY_SIZE) of My_Foo_Type;

   type My_Bar_Type
   is record
  Foos : My_Foo_Array_Type;
   end record;
end Klurigt;
---
package Klurigt.Conv is
   function Foo_Of
 (Foo : in Foo_Type)
  return My_Foo_Type
   is (Kalle => My_Natural_Type (Foo.Kalle),
   Olle  => My_Integer_Type (Foo.Olle));
end Klurigt.Conv;

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-09-29  Ed Schonberg  

* sem_aggr.adb (Resolve_Record_Aggregate): Reject the use of an
iterated component association in an aggregate for a record type.

Index: sem_aggr.adb
===
--- sem_aggr.adb(revision 253283)
+++ sem_aggr.adb(working copy)
@@ -4108,15 +4108,22 @@
  begin
 Assoc := First (Component_Associations (N));
 while Present (Assoc) loop
-   if List_Length (Choices (Assoc)) > 1 then
-  Check_SPARK_05_Restriction
-("component association in record aggregate must "
- & "contain a single choice", Assoc);
-   end if;
+   if Nkind (Assoc) = N_Iterated_Component_Association then
+  Error_Msg_N ("iterated component association can only "
+& "appear in an array aggregate", N);
+  raise Unrecoverable_Error;
 
-   if Nkind (First (Choices (Assoc))) = N_Others_Choice then
-  Check_SPARK_05_Restriction
-("record aggregate cannot contain OTHERS", Assoc);
+   else
+  if List_Length (Choices (Assoc)) > 1 then
+ Check_SPARK_05_Restriction
+   ("component association in record aggregate must "
+& "contain a single choice", Assoc);
+  end if;
+
+  if Nkind (First (Choices (Assoc))) = N_Others_Choice then
+ Check_SPARK_05_Restriction
+   ("record aggregate cannot contain OTHERS", Assoc);
+  end if;
end if;
 
Assoc := Next (Assoc);


Re: [RFA gfortran] PR 25071: dummy argument larger than actual argument

2017-09-29 Thread Dominique d'Humières
Committed as revisions r253286 and r253287.

Dominique

 
> Le 29 sept. 2017 à 15:07, Dominique d'Humières  a écrit :
> 
> Thanks for the quick review. The change logs are
> 
> 2017-09-29  Dominique d'Humieres  
> 
>   PR fortran/25071
>   * interface.c (compare_actual_formal): Change warnings to errors
>   when "Actual argument contains too few elements for dummy
>   argument", unless -std=legacy is used.
> 
> 2017-09-29  Dominique d'Humieres  
> 
>   PR fortran/25071
>   * gfortran.dg/argument_checking_3.f90: Change warnings to errors.
>   * gfortran.dg/argument_checking_4.f90: Likewise.
>   * gfortran.dg/argument_checking_5.f90: Likewise.
>   * gfortran.dg/argument_checking_6.f90: Likewise.
>   * gfortran.dg/argument_checking_10.f90: Likewise.
>   * gfortran.dg/argument_checking_13.f90: Likewise.
>   * gfortran.dg/argument_checking_15.f90: Likewise.
>   * gfortran.dg/argument_checking_18.f90: Likewise.
>   * gfortran.dg/gomp/udr8.f90: Likewise.
>   * gfortran.dg/warn_argument_mismatch_1.f90: Add -std=legacy to
>   the dg-options.
> 
> Dominique
> 



Re: [LIBGO PATCH] Fix compilation error against uClibc-ng: runtime_sysinfo.go: error: use of undefined type ‘___uclibc_locale_struct’

2017-09-29 Thread Alex Potapenko
(Sorry for the rerepost: the list doesn't accept any attachments)

Hi Ian,

On Fri, Sep 29, 2017 at 3:56 PM, Ian Lance Taylor  wrote:

> On Fri, Sep 29, 2017 at 1:38 AM, Alex Potapenko 
> wrote:
> >
> > Building GCC 7.2.0 libgo against uClibc-ng 1.0.26 results in the
> following
> > error:
> >
> >> runtime_sysinfo.go:418:17: error: use of undefined type
> >> ‘___uclibc_locale_struct’
> >
> >
> > This happens because -fdump-go-spec probably generates types only from
> > typedef declarations, ignoring structs, like "struct
> > __uclibc_locale_struct;" in uClibc-ng  header.
> Adding
> > "typedef struct __uclibc_locale_struct __uclibc_locale_struct;" to
> > libgo/sysinfo.c remedies this issue:
> >
> > --- a/libgo/sysinfo.c
> > +++ b/libgo/sysinfo.c
> > @@ -277,3 +277,7 @@
> >epoll_data_offset = offsetof(struct epoll_event, data)
> >  };
> >  #endif
> > +
> > +#ifdef __UCLIBC__
> > +typedef struct __uclibc_locale_struct __uclibc_locale_struct;
> > +#endif
>
> -fdump-go-spec doesn't ignore structs, so I feel like there may be
> something else going on.  Could you send the generated gen-sysinfo.go
> file (without your patch)?  Thanks.
>
> Ian
>

Maybe, -fdump-go-spec chokes on declared structs that are missing
definition? In uClibc-ng struct __uclibc_locale_struct definition is
private, in the  header (see below for the reference)
it's defined as an abstract struct:

> struct __uclibc_locale_struct;


The list doesn't accept attachments, so I'm using paste.bin.

uClibc_locale.h first: https://pastebin.com/NPscqw1j

And gen-sysinfo.go next: https://pastebin.com/ts54YD3A

Thanks,
Alex


[reviewed] qsort comparator consistency checking

2017-09-29 Thread Alexander Monakov
Hello,

I'm going to install the following patch on trunk in the next few hours.
This revision doesn't offer per-callsite opt-out anymore as suggested by
Richi on the Cauldron (made possible by fixing all known issues on trunk).
Thus this patch has a few minor differences compared to the previous
revision that was ack'ed by Jeff.

Tested on x86_64-linux, i686-linux and ppc64le-linux.

Alexander

* genmodes.c (calc_wider_mode): Suppress qsort macro.
* system.h [CHECKING_P] (qsort): Redirect to qsort_chk.
(qsort_chk): Declare.
* vec.c [CHECKING_P] (qsort_chk_error): New static function.
(qsort_chk): New function.

diff --git a/gcc/genmodes.c b/gcc/genmodes.c
index 97ed949c255..4eb8ee56d88 100644
--- a/gcc/genmodes.c
+++ b/gcc/genmodes.c
@@ -880,7 +880,7 @@ calc_wider_mode (void)
  for (i = 0, m = modes[c]; m; i++, m = m->next)
sortbuf[i] = m;
 
- qsort (sortbuf, i, sizeof (struct mode_data *), cmp_modes);
+ (qsort) (sortbuf, i, sizeof (struct mode_data *), cmp_modes);
 
  sortbuf[i] = 0;
  for (j = 0; j < i; j++)
diff --git a/gcc/system.h b/gcc/system.h
index 59449f1942b..f0664e93fc8 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -1181,4 +1181,14 @@ helper_const_non_const_cast (const char *p)
 /* Get definitions of HOST_WIDE_INT.  */
 #include "hwint.h"
 
+/* qsort comparator consistency checking: except in release-checking compilers,
+   redirect 4-argument qsort calls to qsort_chk; keep 1-argument invocations
+   corresponding to vec::qsort (cmp): they use C qsort internally anyway.  */
+#if CHECKING_P
+#define PP_5th(a1, a2, a3, a4, a5, ...) a5
+#undef qsort
+#define qsort(...) PP_5th (__VA_ARGS__, qsort_chk, 3, 2, qsort, 0) 
(__VA_ARGS__)
+void qsort_chk (void *, size_t, size_t, int (*)(const void *, const void *));
+#endif
+
 #endif /* ! GCC_SYSTEM_H */
diff --git a/gcc/vec.c b/gcc/vec.c
index d612703184b..9a80f3421db 100644
--- a/gcc/vec.c
+++ b/gcc/vec.c
@@ -31,6 +31,12 @@ along with GCC; see the file COPYING3.  If not see
 #include "coretypes.h"
 #include "hash-table.h"
 #include "selftest.h"
+#ifdef GENERATOR_FILE
+#include "errors.h"
+#else
+#include "input.h"
+#include "diagnostic-core.h"
+#endif
 
 /* vNULL is an empty type with a template cast operation that returns
a zero-initialized vec instance.  Use this when you want
@@ -190,6 +196,93 @@ dump_vec_loc_statistics (void)
   vec_mem_desc.dump (VEC_ORIGIN);
 }
 
+#if CHECKING_P
+/* Report qsort comparator CMP consistency check failure with P1, P2, P3 as
+   witness elements.  */
+ATTRIBUTE_NORETURN ATTRIBUTE_COLD
+static void
+qsort_chk_error (const void *p1, const void *p2, const void *p3,
+int (*cmp) (const void *, const void *))
+{
+  if (!p3)
+{
+  int r1 = cmp (p1, p2), r2 = cmp (p2, p1);
+  error ("qsort comparator not anti-commutative: %d, %d", r1, r2);
+}
+  else if (p1 == p2)
+{
+  int r = cmp (p1, p3);
+  error ("qsort comparator non-negative on sorted output: %d", r);
+}
+  else
+{
+  int r1 = cmp (p1, p2), r2 = cmp (p2, p3), r3 = cmp (p1, p3);
+  error ("qsort comparator not transitive: %d, %d, %d", r1, r2, r3);
+}
+  internal_error ("qsort checking failed");
+}
+
+/* Wrapper around qsort with checking that CMP is consistent on given input.
+
+   Strictly speaking, passing invalid (non-transitive, non-anti-commutative)
+   comparators to libc qsort can result in undefined behavior.  Therefore we
+   should ideally perform consistency checks prior to invoking qsort, but in
+   order to do that optimally we'd need to sort the array ourselves beforehand
+   with a sorting routine known to be "safe".  Instead, we expect that most
+   implementations in practice will still produce some permutation of input
+   array even for invalid comparators, which enables us to perform checks on
+   the output array.  */
+void
+qsort_chk (void *base, size_t n, size_t size,
+  int (*cmp)(const void *, const void *))
+{
+  (qsort) (base, n, size, cmp);
+#if 0
+#define LIM(n) (n)
+#else
+  /* Limit overall time complexity to O(n log n).  */
+#define LIM(n) ((n) <= 16 ? (n) : 12 + floor_log2 (n))
+#endif
+#define ELT(i) ((const char *) base + (i) * size)
+#define CMP(i, j) cmp (ELT (i), ELT (j))
+#define ERR2(i, j) qsort_chk_error (ELT (i), ELT (j), NULL, cmp)
+#define ERR3(i, j, k) qsort_chk_error (ELT (i), ELT (j), ELT (k), cmp)
+  size_t i1, i2, i, j;
+  /* This outer loop iterates over maximum spans [i1, i2) such that
+ elements within each span compare equal to each other.  */
+  for (i1 = 0; i1 < n; i1 = i2)
+{
+  /* Position i2 one past last element that compares equal to i1'th.  */
+  for (i2 = i1 + 1; i2 < n; i2++)
+   if (CMP (i1, i2))
+ break;
+   else if (CMP (i2, i1))
+ return ERR2 (i1, i2);
+  size_t lim1 = LIM (i2 - i1), lim2 = LIM (n - i2);
+  /* Verify that other pairs within current span compare equal.  */
+  for (i = i1

Re: [LIBGO PATCH] Fix compilation error against uClibc-ng: runtime_sysinfo.go: error: use of undefined type ‘___uclibc_locale_struct’

2017-09-29 Thread Ian Lance Taylor
On Fri, Sep 29, 2017 at 6:28 AM, Alex Potapenko  wrote:
> (Sorry for the rerepost: the list doesn't accept any attachments)
>
> Hi Ian,
>
> On Fri, Sep 29, 2017 at 3:56 PM, Ian Lance Taylor  wrote:
>>
>> On Fri, Sep 29, 2017 at 1:38 AM, Alex Potapenko 
>> wrote:
>> >
>> > Building GCC 7.2.0 libgo against uClibc-ng 1.0.26 results in the
>> > following
>> > error:
>> >
>> >> runtime_sysinfo.go:418:17: error: use of undefined type
>> >> ‘___uclibc_locale_struct’
>> >
>> >
>> > This happens because -fdump-go-spec probably generates types only from
>> > typedef declarations, ignoring structs, like "struct
>> > __uclibc_locale_struct;" in uClibc-ng  header.
>> > Adding
>> > "typedef struct __uclibc_locale_struct __uclibc_locale_struct;" to
>> > libgo/sysinfo.c remedies this issue:
>> >
>> > --- a/libgo/sysinfo.c
>> > +++ b/libgo/sysinfo.c
>> > @@ -277,3 +277,7 @@
>> >epoll_data_offset = offsetof(struct epoll_event, data)
>> >  };
>> >  #endif
>> > +
>> > +#ifdef __UCLIBC__
>> > +typedef struct __uclibc_locale_struct __uclibc_locale_struct;
>> > +#endif
>>
>> -fdump-go-spec doesn't ignore structs, so I feel like there may be
>> something else going on.  Could you send the generated gen-sysinfo.go
>> file (without your patch)?  Thanks.
>>
>> Ian
>
>
> Maybe, -fdump-go-spec chokes on declared structs that are missing
> definition? In uClibc-ng struct __uclibc_locale_struct definition is
> private, in the  header (see below for the reference)
> it's defined as an abstract struct:
>>
>> struct __uclibc_locale_struct;
>
>
> The list doesn't accept attachments, so I'm using paste.bin.
>
> uClibc_locale.h first: https://pastebin.com/NPscqw1j
>
> And gen-sysinfo.go next: https://pastebin.com/ts54YD3A

Thanks.  Yes, the problem is that -fdump-go-spec is faithfully
reporting a dangling type definition, which is fine in C but not in
Go.  Since we don't care about any of the locale stuff anyhow, I'm
inclined to a patch like the appended.  Can you see if this fixes the
problem on your system?  Thanks.

Ian
diff --git a/libgo/mksysinfo.sh b/libgo/mksysinfo.sh
index f7e88a6d..cbe5b979 100755
--- a/libgo/mksysinfo.sh
+++ b/libgo/mksysinfo.sh
@@ -34,6 +34,7 @@ grep -v '^// ' gen-sysinfo.go | \
   grep -v '^type _timespec ' | \
   grep -v '^type _timestruc_t ' | \
   grep -v '^type _epoll_' | \
+  grep -v '^type _*locale[_ ]' | \
   grep -v 'in6_addr' | \
   grep -v 'sockaddr_in6' | \
   sed -e 's/\([^a-zA-Z0-9_]\)_timeval\([^a-zA-Z0-9_]\)/\1Timeval\2/g' \


[Ada] Build in place for nonlimited types

2017-09-29 Thread Pierre-Marie de Rodat
First cut at build-in-place for nonlimited types.
This is a work in progress; the build-in-place
support is currently disabled.

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-09-29  Bob Duff  

* exp_ch6.adb (Expand_Call_Helper): Handle case of build-in-place
functions returning nonlimited types. Allow for qualified expressions
and type conversions.
(Expand_N_Extended_Return_Statement): Correct the computation of
Func_Bod to allow for child units.
(Expand_Simple_Function_Return): Remove assumption that b-i-p implies
limited (initialization of In_Place_Expansion), and implies >= Ada
2005.
(Is_Build_In_Place_Result_Type): New function to accompany
Is_Build_In_Place_Function and Is_Build_In_Place_Function_Call, because
sometimes we just have the type on our hands, not the function.  For
now, does the same thing as the old version, so build-in-place is
disabled for nonlimited types, except that you can use -gnatd.9 to
enable it.
* exp_ch6.ads (Is_Build_In_Place_Result_Type): New function to
accompany Is_Build_In_Place_Function and
Is_Build_In_Place_Function_Call, because sometimes we just have the
type on our hands, not the function.
(Make_Build_In_Place_Call_In_...): Handle nonlimited build-in-place
cases.
(Make_Build_In_Place_Call_In_Object_Declaration): Remove the
questionable code at the end that was setting the Etype.
* exp_aggr.adb (Is_Build_In_Place_Aggregate_Return): New function to
determine whether "return (...agg...);" is returning from a
build-in-place function.
(Initialize_Ctrl_Array_Component, Initialize_Ctrl_Record_Component):
Remove assumption that b-i-p implies limited (initialization of
In_Place_Expansion).
(Build_Record_Aggr_Code): AI-287: fix comment; it can't be wrapped in
an unchecked conversion.  Add assertions.
(Convert_Aggr_In_Object_Decl): Establish_Transient_Scope -- no need for
secondary stack here, just because the type needs finalization.  That
code is obsolete.
(Convert_To_Assignments): Only set Unc_Decl if Nkind (N) = N_Aggregate.
For "return (...agg...);" don't assume b-i-p implies limited.
Needs_Finalization does not imply secondary stack.
(Expand_Array_Aggregate): Named notation.  Reverse the sense of
Component_OK_For_Backend -- more readability with fewer double
negatives.
* exp_attr.adb (Expand_N_Attribute_Reference): Remove assumptions that
b-i-p implies >= Ada 2005.
* exp_ch3.adb (Expand_N_Object_Declaration): Remove assumptions that
b-i-p implies >= Ada 2005.  Remove Adjust if we're building the return
object of an extended return statement in place.
* exp_ch4.adb (Expand_Allocator_Expression, Expand_N_Indexed_Component,
Expand_N_Selected_Component, Expand_N_Slice): Remove assumptions that
b-i-p implies >= Ada 2005.
* exp_ch5.adb (Expand_N_Assignment_Statement): Remove assumption that
b-i-p implies >= Ada 2005.
* exp_ch7.adb: Comment fix.
* exp_ch8.adb (Expand_N_Object_Renaming_Declaration): Remove
assumptions that b-i-p implies >= Ada 2005.
* exp_disp.adb (Expand_Interface_Actuals): Remove assumptions that
b-i-p implies >= Ada 2005.
* exp_util.adb (Build_Allocate_Deallocate_Proc): Look at Storage_Pool
(Expr), in case Pool_Id is not set.
(Initialized_By_Aliased_BIP_Func_Call): Handle case where the call is
qualified or converted.
(Is_Secondary_Stack_BIP_Func_Call): Don't check if Nkind (Selector_Name
(Param)) = N_Identifier; that's all it could be.
* sinfo.ads: Comment fixes.
* snames.ads-tmpl: Comment fixes.
* debug.adb: Add flag gnatd.9, to enable the build-in-place machinery.

Index: exp_aggr.adb
===
--- exp_aggr.adb(revision 253285)
+++ exp_aggr.adb(working copy)
@@ -175,6 +175,10 @@
-- Local subprograms for Record Aggregate Expansion --
--
 
+   function Is_Build_In_Place_Aggregate_Return (N : Node_Id) return Boolean;
+   --  True if N is an aggregate (possibly qualified or converted) that is
+   --  being returned from a build-in-place function.
+
function Build_Record_Aggr_Code
  (N   : Node_Id;
   Typ : Entity_Id;
@@ -186,10 +190,9 @@
--  types.
 
procedure Convert_To_Assignments (N : Node_Id; Typ : Entity_Id);
-   --  N is an N_Aggregate or an N_Extension_Aggregate. Typ is the type of the
-   --  aggregate (which can only be a record type, this procedure is only used
-   --  for record types). Transform the given aggregate into a sequence of
-   --  assignments performed component by component.
+   --

Re: [LIBGO PATCH] Fix compilation error against uClibc-ng: runtime_sysinfo.go: error: use of undefined type ‘___uclibc_locale_struct’

2017-09-29 Thread Alex Potapenko
On Fri, Sep 29, 2017 at 4:44 PM, Ian Lance Taylor  wrote:
>
> Thanks.  Yes, the problem is that -fdump-go-spec is faithfully
> reporting a dangling type definition, which is fine in C but not in
> Go.  Since we don't care about any of the locale stuff anyhow, I'm
> inclined to a patch like the appended.  Can you see if this fixes the
> problem on your system?  Thanks.
>

After I apply your patch, and additionally patch libgo/mkrsysinfo.sh in the
similar fashion, it does fix the problem:

--- a/libgo/mkrsysinfo.sh
+++ b/libgo/mkrsysinfo.sh
@@ -23,6 +23,7 @@
   grep -v '^type _timespec_t ' | \
   grep -v '^type _timespec ' | \
   grep -v '^type _epoll_' | \
+  grep -v '^type _*locale[_ ]' | \
   grep -v 'in6_addr' | \
   grep -v 'sockaddr_in6' | \
   sed -e 's/\([^a-zA-Z0-9_]\)_timeval\([^a-zA-Z0-9_]\)/\1timeval\2/g' \


Thanks,
Alex


Re: [PATCH] Fix fortran/81509

2017-09-29 Thread Steve Kargl
On Fri, Sep 29, 2017 at 11:15:47AM +0200, Janus Weil wrote:
> Hi Steve,
> 
> > As aside effect, the patch removes a questionable GNU Fortran
> > extension that allowed arguments to IAND, IOR, and IEOR to have
> > different kind type parameters.  The behavior of this extension
> > was not documented.
> 
> I don't really like that part. We were using the nice and convenient
> mechanism of gfc_notify_std here, which allows the developer to choose
> via the -std flag whether to strictly adhere to a chosen Fortran
> standard or to allow GNU extensions etc. You're taking away that
> flexibility and replacing it by an unconditional error. I don't
> actually think that's a good idea.
> 
> In general one can argue about whether or not it's a good idea to use
> non-std extensions. But I think gfortran should rather leave the
> choice to its users, whether they want to use 'dirty and covenient'
> code or have very strict checking. We have nice mechanisms for this,
> and I do think we should keep them.
> 

It is undefined behavior.  I withdraw the patch.

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow


Re: [LIBGO PATCH] Fix compilation error against uClibc-ng: runtime_sysinfo.go: error: use of undefined type ‘___uclibc_locale_struct’

2017-09-29 Thread Ian Lance Taylor
On Fri, Sep 29, 2017 at 7:08 AM, Alex Potapenko  wrote:
> On Fri, Sep 29, 2017 at 4:44 PM, Ian Lance Taylor  wrote:
>>
>> Thanks.  Yes, the problem is that -fdump-go-spec is faithfully
>> reporting a dangling type definition, which is fine in C but not in
>> Go.  Since we don't care about any of the locale stuff anyhow, I'm
>> inclined to a patch like the appended.  Can you see if this fixes the
>> problem on your system?  Thanks.
>
>
> After I apply your patch, and additionally patch libgo/mkrsysinfo.sh in the
> similar fashion, it does fix the problem:
>
> --- a/libgo/mkrsysinfo.sh
> +++ b/libgo/mkrsysinfo.sh
> @@ -23,6 +23,7 @@
>grep -v '^type _timespec_t ' | \
>grep -v '^type _timespec ' | \
>grep -v '^type _epoll_' | \
> +  grep -v '^type _*locale[_ ]' | \
>grep -v 'in6_addr' | \
>grep -v 'sockaddr_in6' | \
>sed -e 's/\([^a-zA-Z0-9_]\)_timeval\([^a-zA-Z0-9_]\)/\1timeval\2/g' \

Thanks.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 253236)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-11b7dae7de94215e92eb46e703cfecd76c0a3282
+9a9d526a4c0a7f5b3635034b3e1dc3bbe6380dd2
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/mkrsysinfo.sh
===
--- libgo/mkrsysinfo.sh (revision 253025)
+++ libgo/mkrsysinfo.sh (working copy)
@@ -23,6 +23,7 @@ grep -v '^// ' gen-sysinfo.go | \
   grep -v '^type _timespec_t ' | \
   grep -v '^type _timespec ' | \
   grep -v '^type _epoll_' | \
+  grep -v '^type _*locale[_ ]' | \
   grep -v 'in6_addr' | \
   grep -v 'sockaddr_in6' | \
   sed -e 's/\([^a-zA-Z0-9_]\)_timeval\([^a-zA-Z0-9_]\)/\1timeval\2/g' \
Index: libgo/mksysinfo.sh
===
--- libgo/mksysinfo.sh  (revision 253025)
+++ libgo/mksysinfo.sh  (working copy)
@@ -34,6 +34,7 @@ grep -v '^// ' gen-sysinfo.go | \
   grep -v '^type _timespec ' | \
   grep -v '^type _timestruc_t ' | \
   grep -v '^type _epoll_' | \
+  grep -v '^type _*locale[_ ]' | \
   grep -v 'in6_addr' | \
   grep -v 'sockaddr_in6' | \
   sed -e 's/\([^a-zA-Z0-9_]\)_timeval\([^a-zA-Z0-9_]\)/\1Timeval\2/g' \


Re: [C++ PATCH] C++2A P0683R1 - default member initializers for bit-fields (take 2)

2017-09-29 Thread Nathan Sidwell

On 09/29/2017 05:26 AM, Jakub Jelinek wrote:

Hi!

On Wed, Sep 27, 2017 at 07:55:20AM -0700, Nathan Sidwell wrote:

1) fix the parsing bug you found and move to (ab)using
DECL_BIT_FIELD_REPRESENTATIVE

2) the new c++2a feature


And here is the 2) patch, on top of the previous 3 ones.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?


Ok.  One nit ...


--- gcc/cp/decl2.c.jj   2017-09-29 09:57:12.586423527 +0200
+++ gcc/cp/decl2.c  2017-09-29 10:24:26.864372956 +0200
@@ -978,10 +978,11 @@ grokfield (const cp_declarator *declarat
  
  tree

  grokbitfield (const cp_declarator *declarator,
- cp_decl_specifier_seq *declspecs, tree width,
+ cp_decl_specifier_seq *declspecs, tree width, tree init,
  tree attrlist)


The new parm needs documenting.  I notice the current description of 
WIDTH is wonky:

  WIDTH is non-NULL for bit fields only, and is an INTEGER_CST node.
while true, makes one wonder if it could be NULL.  Feel free to make 
that comment saner.


thanks

nathan

--
Nathan Sidwell


Re: [PATCH][GRAPHITE] Avoid CHRECs with evolution in loops not in the nest

2017-09-29 Thread Sebastian Pop
On Fri, Sep 29, 2017 at 6:18 AM, Richard Biener  wrote:
> The idea is that we'd transform the above to
> basically wrap each SCOP inside a loop that doesn't iterate.
>
> Does this look reasonable?

Yes, I think your solution looks good.

> 2017-09-29  Richard Biener  
>
> PR tree-optimization/82355
> * graphite-isl-ast-to-gimple.c (build_iv_mapping): Also build
> a mapping for the enclosing loop but avoid generating one for
> the loop tree root.
> (copy_bb_and_scalar_dependences): Remove premature codegen
> error on PHIs in blocks duplicated into multiple places.
> * graphite-scop-detection.c
> (scop_detection::stmt_has_simple_data_refs_p): For a loop not
> in the region use it as loop and nest to analyze the DR in.
> (try_generate_gimple_bb): Likewise.
> * graphite-sese-to-poly.c (extract_affine_chrec): Adjust.
> (add_loop_constraints): For blocks in a loop not in the region
> create a dimension with a single iteration.
> * sese.h (gbb_loop_at_index): Remove assert.
>
> * gcc.dg/graphite/fuse-1.c: Adjust.
> * gcc.dg/graphite/fuse-2.c: Likewise.
> * gcc.dg/graphite/pr82355.c: New testcase.

The change looks good to me.  Thank you!


RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling

2017-09-29 Thread Tsimbalist, Igor V
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Friday, September 29, 2017 12:44 AM
> To: Tsimbalist, Igor V ; gcc-
> patc...@gcc.gnu.org
> Cc: richard.guent...@gmail.com
> Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> 
> On 09/19/2017 07:39 AM, Tsimbalist, Igor V wrote:
> > Here is an updated patch (version #2). The main differences are:
> >
> > - Change attribute and option names;
> > - Add additional parameter to gimple_build_call_from_tree by adding a
> type parameter and
> >   use it 'nocf_check' attribute propagation;
> > - Reimplement fixes in expand_call_stmt to propagate 'nocf_check'
> > attribute;
> > - Consider 'nocf_check' attribute in Identical Code Folding (ICF)
> > optimization;
> > - Add warning for type inconsistency regarding 'nocf_check' attribute;
> > - Many small fixes;
> >
> > gcc/c-family/
> > * c-attribs.c (handle_nocf_check_attribute): New function.
> > (c_common_attribute_table): Add 'nocf_check' handling.
> > * c-common.c (check_missing_format_attribute): New function.
> > * c-common.h: Likewise.
> >
> > gcc/c/
> > * c-typeck.c (convert_for_assignment): Add check for nocf_check
> > attribute.
> > * gimple-parser.c: Add second argument NULL to
> > gimple_build_call_from_tree.
> >
> > gcc/cp/
> > * typeck.c (convert_for_assignment): Add check for nocf_check
> > attribute.
> >
> > gcc/
> > * cfgexpand.c (expand_call_stmt): Set REG_CALL_NOCF_CHECK for
> > call insn.
> > * combine.c (distribute_notes): Add REG_CALL_NOCF_CHECK
> handling.
> > * common.opt: Add fcf-protection flag.
> > * emit-rtl.c (try_split): Add REG_CALL_NOCF_CHECK handling.
> > * flag-types.h: Add enum cf_protection_level.
> > * gimple.c (gimple_build_call_from_tree): Add second parameter.
> > Add 'nocf_check' attribute propagation to gimple call.
> > * gimple.h (gf_mask): Add GF_CALL_NOCF_CHECK.
> > (gimple_call_nocf_check_p): New function.
> > (gimple_call_set_nocf_check): Likewise.
> > * gimplify.c: Add second argument to gimple_build_call_from_tree.
> > * ipa-icf.c: Add nocf_check attribute in statement hash.
> > * recog.c (peep2_attempt): Add REG_CALL_NOCF_CHECK handling.
> > * reg-notes.def: Add REG_NOTE (CALL_NOCF_CHECK).
> > * toplev.c (process_options): Add flag_cf_protection handling.
> >
> > Is it ok for trunk?
> >
> > Thanks,
> > Igor
> >
> >
> 
> 
> >
> > diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c index
> > 0337537..77d1909 100644
> > --- a/gcc/c-family/c-attribs.c
> > +++ b/gcc/c-family/c-attribs.c
> > @@ -65,6 +65,7 @@ static tree handle_asan_odr_indicator_attribute
> > (tree *, tree, tree, int,  static tree handle_stack_protect_attribute
> > (tree *, tree, tree, int, bool *);  static tree
> > handle_noinline_attribute (tree *, tree, tree, int, bool *);  static
> > tree handle_noclone_attribute (tree *, tree, tree, int, bool *);
> > +static tree handle_nocf_check_attribute (tree *, tree, tree, int,
> > +bool *);
> >  static tree handle_noicf_attribute (tree *, tree, tree, int, bool *);
> > static tree handle_noipa_attribute (tree *, tree, tree, int, bool *);
> > static tree handle_leaf_attribute (tree *, tree, tree, int, bool *);
> > @@ -367,6 +368,8 @@ const struct attribute_spec
> c_common_attribute_table[] =
> >{ "patchable_function_entry",1, 2, true, false, false,
> >   handle_patchable_function_entry_attribute,
> >   false },
> > +  { "nocf_check",0, 0, false, true, true,
> > + handle_nocf_check_attribute, false },
> >{ NULL, 0, 0, false, false, false, NULL, false }
> >  };
> >
> > @@ -783,6 +786,26 @@ handle_noclone_attribute (tree *node, tree
> name,
> >return NULL_TREE;
> >  }
> >
> > +/* Handle a "nocf_check" attribute; arguments as in
> > +   struct attribute_spec.handler.  */
> > +
> > +static tree
> > +handle_nocf_check_attribute (tree *node, tree name,
> > + tree ARG_UNUSED (args),
> > + int ARG_UNUSED (flags), bool *no_add_attrs) {
> > +  if (TREE_CODE (*node) != FUNCTION_TYPE
> > +  && TREE_CODE (*node) != METHOD_TYPE
> > +  && TREE_CODE (*node) != FIELD_DECL
> > +  && TREE_CODE (*node) != TYPE_DECL)
> So curious, is this needed for FIELD_DECL and TYPE_DECL?  ISTM the attribute
> is applied to function/method types.
> 
> If we do need to handle FIELD_DECL and TYPE_DECL here, can you add a
> quick comment why?

You are right. Probably it was left from the attribute transition from decl to 
type.
I removed these two lines. All CET tests passed.

> > diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c index
> > b3ec3a0..78a730e 100644
> > --- a/gcc/c-family/c-common.c
> > +++ b/gcc/c-family/c-common.c
> > @@ -7253,6 +7253,26 @@ check_missing_format_attribute (tree ltype,
> tree rtype)
> >  return false;
> >  }
> >
> > +/* Chec

Re: [PATCH][GRAPHITE] Abstract away codegen_error setting

2017-09-29 Thread Sebastian Pop
On Fri, Sep 29, 2017 at 3:52 AM, Richard Biener  wrote:
>
> This moves it to a function to make it easy to enable ICEin on them
> in one place.
>
> Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
>
> Richard.
>
> 2017-09-29  Richard Biener  
>
> * graphite-isl-ast-to-gimple.c
> (translate_isl_ast_to_gimple::set_codegen_error): New function.
> (binary_op_to_tree): Use it.
> (get_rename_from_scev): Likewise.
> (copy_loop_phi_nodes): Likewise.
> (copy_bb_and_scalar_dependences): Likewise.
> (translate_pending_phi_nodes): Likewise.

Looks good.  Thanks.


Re: [libgo] Support 32-bit SPARC relocs

2017-09-29 Thread Ian Lance Taylor
On Tue, Sep 12, 2017 at 6:01 AM, Rainer Orth
 wrote:
> A couple of gotools tests were FAILing on 32-bit Solaris/SPARC like
> this:
>
> FAIL: TestCgoHandlesWlORIGIN
> go_test.go:267: running testgo [build origin]
> go_test.go:286: standard error:
> go_test.go:287: # origin
> cannot load DWARF output from $WORK/origin/_obj//_cgo_.o: 
> applyRelocations: not implemented
>
> go_test.go:296: go [build origin] failed unexpectedly: exit status 2
>
> The following patch fixes this by implementing applyRelocationsSPARC.
> It's a straightforward derivative of applyRelocationsSPARC64.  The only
> point of not is support for the SPARC V8Plus ABI, which is the default
> on Solaris these days.  The testcase above PASSes now, a couple of
> others still FAIL for different reasons.
>
> Rainer
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
>
> 2017-09-11  Rainer Orth  
>
> * go/debug/elf/file.go (applyRelocations): Handle 32-bit SPARC.
> (applyRelocationsSPARC): New function.


Thanks.  Committed.

Ian


Re: [LIBGO PATCH] Fix compilation error against uClibc-ng: runtime_sysinfo.go: error: use of undefined type ‘___uclibc_locale_struct’

2017-09-29 Thread Alex Potapenko
On Fri, Sep 29, 2017 at 5:15 PM, Ian Lance Taylor  wrote:
>
> Thanks.  Committed to mainline.
>

Great, thanks!

-- 
Best regards,
Alex Potapenko


Re: [PATCH][GRAPHITE] More TLC

2017-09-29 Thread Sebastian Pop
On Fri, Sep 29, 2017 at 6:17 AM, Richard Biener  wrote:
> I fixed the "hack patch" somewhat but realized it's not really possible
> ATM to get back at this form because the array descriptor contains only
> information to generate the linearized form.  So while I get now correct
> values they end up with runtime divisions which aren't handled by
> SCEV.

You are right, SCEV has some limits on representing and folding
those division expressions.

There is a proposal in LLVM from Johannes Doerfert
https://reviews.llvm.org/D38255
to use isl as a representation and expression folder instead of the
chains of recurrences for the scalar evolution analysis.  isl would
be able to handle some of the semantics of the div_exprs, and the
semantics of wrap-around variables, and of course it would have
some other limits to represent multiplications (as we spoke about
yesterday, i * N or M * N for example,) and thus that polyhedral
analysis would need to rely on the delinearization of array indices.


[RFA][PATCH] Stack clash protection 07/08 -- V4 (aarch64 bits)

2017-09-29 Thread Jeff Law
Wilco has done most of the design/implementation review work to-date and
should have state on most of this code.

--


Here's the current aarch64 patch for stack clash protection.  It's the
only bits for stack clash protection that haven't been committed to the
trunk.

Looking through my archives I can't find the V3 patch.  So I'm going to
describe what's changed since the V2 patch.

aarch64_output_probe_stack_range changes were slightly simplified.
There was no need to set reg1 to stack_pointer_rtx for stack-clash
protection.

We have PARAMS for the size of the guard and the probe interval.  For
aarch64 we override the default guard size and set it to 64k. The guard
size determines if we need probing and once we need probing the interval
is determined by the probe interval.  The reserved 1k for outgoing args
doesn't have a PARAM since it's target specific.

The code tries to handle probe intervals > ARITH_FACTOR, but I haven't
thoroughly tested that.

The code should add the appropriate notes to get the dwarf2 CFI records
we need, including the case when we have a probing loop.


The epilogue would sometimes elide setting IP0_REGNUM or IP1_REGNUM
assuming the prologue had done so and left them in a usable state.
However, those registers won't have the expected values when stack-clash
protection is enabled.  The epilogue has been updated to handle that
case and avoid the incorrect optimization.  This was tickled during testing.

We emit REG_STACK_CHECK notes and blockage insns to prevent
combine-stack-adjustments and/or the scheduler from mucking up the
probing sequences.  A testcase for this issue is included.  This was
discovered during binary scanning of glibc built with stack clash
protection.

The trailing probe to ensure that a caller always has a probe within 1k
of the end of the outgoing args should be correct now.Testcases for
a couple instances of this problem (from Wilco)  are included.

Similarly we turn on the hook to do the same for the alloca space.

We no longer track the most recent probe.  A better understanding of the
aarch64 prologue code shows this wasn't really needed.

This has been bootstrapped and regression tested on aarch64 linux.  I've
also bootstrapped and regression tested with stack clash protections
enabled by default to exercise the code further (regressions in that
case are related to mixing stack-clash and stack-check as well as the
usual guality problems).  Earlier versions have been used to build and
test glibc as well.


OK for the trunk?

Jeff
commit 7fcdc6933501f9a6b124174e8b2c4113c3adcf1d
Author: root 
Date:   Fri Jul 7 11:17:06 2017 -0400

* config/aarch/aarch64.c (aarch64_output_probe_stack_range): Handle
-fstack-clash-protection probing too.
(aarch64_allocate_and_probe_stack_space): New function.
(aarch64_expand_prologue): Assert we never have both an initial
adjustment and callee save adjustment.  Probe and dump as needed 
when
-fstack-clash-protection is enabled.
(aarch64_expand_epilogue): Do not assume the prologue has
set IP1_REGNUM or IP0_REGNUM to useful values when
-fstack-clash-protection is active.
(aarch64_override_options_internal): Assume 64kb of guard space.
(aarch64_stack_clash_protection_final_dynamic_probe): New function.
(TARGET_STACK_CLASH_PROTECTION_FINAL_DYNAMIC_PROBE): define.
* aarch64.md (probe_stack_range): Fix constraint on destination
operand.

* lib/target-supports.exp
(check_effective_target_supports_stack_clash_protection): Enable for
aarch64 targets.
* gcc.target/aarch64/stack-check-12.c: New test.
* gcc.target/aarch64/stack-check-13.c: New test.
* gcc.target/aarch64/stack-check-14.c: New test.
* gcc.target/aarch64/stack-check-15.c: New test.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 71b1408496a..c7224237572 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,20 @@
+2017-09-27  Jeff Law  
+
+   * config/aarch/aarch64.c (aarch64_output_probe_stack_range): Handle
+   -fstack-clash-protection probing too.
+   (aarch64_allocate_and_probe_stack_space): New function.
+   (aarch64_expand_prologue): Assert we never have both an initial
+   adjustment and callee save adjustment.  Probe and dump as needed when
+   -fstack-clash-protection is enabled. 
+   (aarch64_expand_epilogue): Do not assume the prologue has
+   set IP1_REGNUM or IP0_REGNUM to useful values when
+   -fstack-clash-protection is active.
+   (aarch64_override_options_internal): Assume 64kb of guard space.
+   (aarch64_stack_clash_protection_final_dynamic_probe): New function.
+   (TARGET_STACK_CLASH_PROTECTION_FINAL_DYNAMIC_PROBE): define.
+   * aarch64.md (probe_stack_range): Fix constraint on destination
+   operand.
+
 2017-09-27  Christophe Lyon  

Re: [PING][patch] PR81794: have "would be stringified in traditional C" warning in libcpp/macro.c be controlled by -Wtraditional

2017-09-29 Thread David Malcolm
On Sun, 2017-09-17 at 20:00 -0400, Eric Gallager wrote:
> Attached is a version of
> https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00481.html that
> contains
> a combination of both the fix and the testcase update, as requested
> in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81794#c2
> 
> I had to use a different computer than I usually use to send this
> email, as the hard drive that originally had this patch is currently
> unresponsive. Since it's also the one with my ssh keys on it, I can't
> commit with it. Sorry if the ChangeLogs get mangled.

Thanks for putting this together; sorry about the delay in reviewing
it.

The patch mostly looks good.

Did you perform a full bootstrap and run of the testsuite with this
patch?  If so, it's best to state this in the email, so that we know
that the patch has survived this level of testing.

Some nits below:

> libcpp/ChangeLog:
> 
> 2017-03-24  Eric Gallager  
> 
>  * macro.c (check_trad_stringification): Have warning be
> controlled by
>  -Wtraditional.
> 
> gcc/testsuite/ChangeLog:
> 
> 2017-09-17  Eric Gallager  
> 
> PR preprocessor/81794
> * gcc.dg/pragma-diag-7.c: Update to include check for
> stringification.
> 
> On Sat, May 6, 2017 at 11:33 AM, Eric Gallager 
> wrote:
> > Pinging this: https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01325.h
> > tml
> > 
> > On 3/24/17, Eric Gallager  wrote:
> > > It seemed odd to me that gcc was issuing a warning about
> > > compatibility
> > > with traditional C that I couldn't turn off by pushing/popping
> > > -Wtraditional over the problem area, so I made the attached
> > > (minor)
> > > patch to fix it. Survives bootstrap, but the only testing I've
> > > done
> > > with it has been compiling the one file that was giving me issues
> > > previously, which I'd need to reduce further to turn it into a
> > > proper
> > > test case.
> > > 
> > > Thanks,
> > > Eric Gallager
> > > 
> > > libcpp/ChangeLog:
> > > 
> > > 2017-03-24  Eric Gallager  
> > > 
> > >   * macro.c (check_trad_stringification): Have warning be
> > > controlled by
> > >   -Wtraditional.
> > > 
> > 
> > So I did the reducing I mentioned above and now have a testcase for
> > it; it was pretty similar to the one from here:
> > https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01319.html
> > so I combined them into a single testcase and have attached the
> > combined version. I can confirm that the testcase passes with my
> > patch
> > applied.

[...]

> diff --git a/gcc/testsuite/gcc.dg/pragma-diag-7.c 
> b/gcc/testsuite/gcc.dg/pragma-diag-7.c
> index 402ee56..e06c410 100644
> --- a/gcc/testsuite/gcc.dg/pragma-diag-7.c
> +++ b/gcc/testsuite/gcc.dg/pragma-diag-7.c
> @@ -7,3 +7,16 @@ unsigned long bad = 1UL; /* { dg-warning "suffix" } */
>  /* Note the extra space before the pragma on this next line: */
>   #pragma GCC diagnostic pop
>  unsigned long ok_again = 2UL; /* { dg-bogus "suffix" } */
> +
> +/* Redundant with the previous pop, but just shows that it fails to stop the
> + * following warning with an unpatched GCC: */
> +#pragma GCC diagnostic ignored "-Wtraditional"
> +
> +/* { dg-bogus "would be stringified" .+1 } */

As far as I can tell, this dg-bogus line doesn't actually get matched;
when I run the testsuite without the libcpp fix, I get:

  FAIL: gcc.dg/pragma-diag-7.c (test for excess errors)

If I update the dg-bogus line to read:

  /* { dg-bogus "would be stringified" "" { target *-*-* } .+1 } */

then it's matched, and I get:

  FAIL: gcc.dg/pragma-diag-7.c  (test for bogus messages, line 16)

I believe that as written the ".+1" 2nd argument is interpreted as a
human-readable description of the problem, rather than as a line
offset; I believe you would need to add positional args for the
description and filter so that the line offset is argument 4.

That said, I think the dg-bogus here is unnecessary: if the warning is
erroneously emitted, we get:

  FAIL: gcc.dg/pragma-diag-7.c (test for excess errors)

(where "errors" really means "excess errors, warnings and extraneous
gunk that isn't a note").

So this testcase hunk is good without the dg-bogus line.

> +#define UNW_DEC_PROLOGUE(fmt, body, rlen, arg) \
> +  do {   
> \
> +  unw_rlen = rlen;   
> \
> +  *(int *)arg = body;\
> +  printf("%s:%s(rlen=%lu)\n",
> \
> + fmt, (body ? "body" : "prologue"), (unsigned long)rlen);
> \
> +  } while (0)
> diff --git a/libcpp/macro.c b/libcpp/macro.c
> index de18c22..71363b5 100644
> --- a/libcpp/macro.c
> +++ b/libcpp/macro.c
> @@ -3316,7 +3316,7 @@ check_trad_stringification (cpp_reader *pfile, const 
> cpp_macro *macro,
> if (NODE_LEN (node) == len
> && !memcmp (p, NODE_NAME (node), len))
>   {
> -   cpp_error (pfile, CPP_DL_WARNING,
> +   cp

Re: [PING][patch] PR81794: have "would be stringified in traditional C" warning in libcpp/macro.c be controlled by -Wtraditional

2017-09-29 Thread David Malcolm
On Fri, 2017-09-29 at 11:15 -0400, David Malcolm wrote:
> On Sun, 2017-09-17 at 20:00 -0400, Eric Gallager wrote:
> > Attached is a version of
> > https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00481.html that
> > contains
> > a combination of both the fix and the testcase update, as requested
> > in
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81794#c2
> > 
> > I had to use a different computer than I usually use to send this
> > email, as the hard drive that originally had this patch is
> > currently
> > unresponsive. Since it's also the one with my ssh keys on it, I
> > can't
> > commit with it. Sorry if the ChangeLogs get mangled.
> 
> Thanks for putting this together; sorry about the delay in reviewing
> it.
> 
> The patch mostly looks good.
> 
> Did you perform a full bootstrap and run of the testsuite with this
> patch?  If so, it's best to state this in the email, so that we know
> that the patch has survived this level of testing.
> 
> Some nits below:
> 
> > libcpp/ChangeLog:
> > 
> > 2017-03-24  Eric Gallager  
> > 
> >  * macro.c (check_trad_stringification): Have warning be
> > controlled by
> >  -Wtraditional.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > 2017-09-17  Eric Gallager  
> > 
> > PR preprocessor/81794
> > * gcc.dg/pragma-diag-7.c: Update to include check for
> > stringification.

Another nit: both ChangeLog entries ought to have the "PR
preprocessor/81794" heading (currently only the testsuite one does).


[Ada] Misleading warning when no read access for source file

2017-09-29 Thread Pierre-Marie de Rodat
This patch corrects an issue whereby source files that did not have read
permissions were incorrectly referred to as "not found'. Now, these different
cases are explicitly identified and warned about properly.


-- Source --


--  toto.c

void toto(void)
{
}

--  hello.adb

with Ada.Text_IO; use Ada.Text_IO;
procedure Hello is
begin
   Put_Line ("Hello, world!");
end Hello;


-- Compilation and output --


& chmod a-r hello.adb
& gcc -c hello.adb
& chmod a+r hello.adb
& chmod a-r toto.c
& gcc -c toto.c
& chmod a+r toto.c

no read access for file "hello.adb"
cc1: fatal error: toto.c: Permission denied
compilation terminated.

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-09-29  Justin Squirek  

* ali-util.adb, comperr.adb, errout.adb, fmap.adb, fname-sf.adb,
frontend.adb, lib-xref-spark_specific.adb, gnat1drv.adb, gnatls.adb,
lib.adb, lib-load.adb, lib-writ.adb, prepcomp.adb, sinput-d.adb,
sinput-l.adb, sprint.adb, targparm.adb: Update comparison for checking
source file status and error message and/or call to Read_Source_File.
* libgnat/s-os_lib.ads: Add new potential value constant for
uninitialized file descriptors.
* osint.adb, osint.ads (Read_Source_File): Add extra parameter to
return result of IO to encompass a read access failure in addition to a
file-not-found error.

Index: lib.adb
===
--- lib.adb (revision 253283)
+++ lib.adb (working copy)
@@ -626,7 +626,7 @@
 Source_File := Get_Source_File_Index (S);
 
 if Unwind_Instances then
-   while Template (Source_File) /= No_Source_File loop
+   while Template (Source_File) > No_Source_File loop
   Source_File := Template (Source_File);
end loop;
 end if;
Index: frontend.adb
===
--- frontend.adb(revision 253283)
+++ frontend.adb(working copy)
@@ -126,7 +126,7 @@
 
--  Return immediately if the main source could not be found
 
-   if Sinput.Main_Source_File = No_Source_File then
+   if Sinput.Main_Source_File <= No_Source_File then
   return;
end if;
 
@@ -167,7 +167,7 @@
 
  --  Case of gnat.adc file present
 
- if Source_gnat_adc /= No_Source_File then
+ if Source_gnat_adc > No_Source_File then
 --  Parse the gnat.adc file for configuration pragmas
 
 Initialize_Scanner (No_Unit, Source_gnat_adc);
@@ -213,7 +213,7 @@
 
   Source_Config_File := Load_Config_File (Config_Name);
 
-  if Source_Config_File = No_Source_File then
+  if Source_Config_File <= No_Source_File then
  Osint.Fail
("cannot find configuration pragmas file "
 & Config_File_Names (Index).all);
Index: lib-xref-spark_specific.adb
===
--- lib-xref-spark_specific.adb (revision 253283)
+++ lib-xref-spark_specific.adb (working copy)
@@ -249,7 +249,7 @@
   --  Source file could be inexistant as a result of an error, if option
   --  gnatQ is used.
 
-  if File = No_Source_File then
+  if File <= No_Source_File then
  return;
   end if;
 
Index: sprint.adb
===
--- sprint.adb  (revision 253283)
+++ sprint.adb  (working copy)
@@ -3752,7 +3752,7 @@
   --  Ignore if there is no current source file, or we're not in dump
   --  source text mode, or if in freeze actions.
 
-  if Current_Source_File /= No_Source_File
+  if Current_Source_File > No_Source_File
 and then Dump_Source_Text
 and then Freeze_Indent = 0
   then
Index: fmap.adb
===
--- fmap.adb(revision 253283)
+++ fmap.adb(working copy)
@@ -175,6 +175,7 @@

 
procedure Initialize (File_Name : String) is
+  FD  : File_Descriptor;
   Src : Source_Buffer_Ptr;
   Hi  : Source_Ptr;
 
@@ -297,10 +298,14 @@
 
begin
   Empty_Tables;
-  Read_Source_File (Name_Enter (File_Name), 1, Hi, Src, Config);
+  Read_Source_File (Name_Enter (File_Name), 1, Hi, Src, FD, Config);
 
   if Null_Source_Buffer_Ptr (Src) then
- Write_Str ("warning: could not read mapping file """);
+ if FD = Null_FD then
+Write_Str ("warning: could not locate mapping file """);
+ else
+Write_Str ("warning: no read access for mapping file """);
+ end if;
  Write_Str (File_Name);
  Write_Line ();
  No_Mapping_File := True;
Index: gnatls.adb
===
--- 

[Ada] Avoid single colon in comment markup

2017-09-29 Thread Pierre-Marie de Rodat
This change allows our style-checker to implement a heuristic to detect
either only typed one ':' or mistyped one of the characters, causing the
entire markup block to disappear as it is then unexpectedly being
treated as a comment instead.

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-09-29  Joel Brobecker  

* doc/gnat_ugn/building_executable_programs_with_gnat.rst,
doc/gnat_ugn/the_gnat_compilation_model.rst: Avoid use of single colon
in comment markup.
* gnat_ugn.texi: Regenerate.

Index: doc/gnat_ugn/building_executable_programs_with_gnat.rst
===
--- doc/gnat_ugn/building_executable_programs_with_gnat.rst (revision 
253283)
+++ doc/gnat_ugn/building_executable_programs_with_gnat.rst (working copy)
@@ -559,7 +559,7 @@
   -f, it is equivalent to calling the compiler directly. Note that using
   -u with a project file and no main has a special meaning.
 
-.. --Comment:
+.. --Comment
   (See :ref:`Project_Files_and_Main_Subprograms`.)
 
 
Index: doc/gnat_ugn/the_gnat_compilation_model.rst
===
--- doc/gnat_ugn/the_gnat_compilation_model.rst (revision 253283)
+++ doc/gnat_ugn/the_gnat_compilation_model.rst (working copy)
@@ -1569,7 +1569,7 @@
 If you are using project file, a separate mechanism is provided using
 project attributes.
 
-.. --Comment:
+.. --Comment
See :ref:`Specifying_Configuration_Pragmas` for more details.
 
 
Index: gnat_ugn.texi
===
--- gnat_ugn.texi   (revision 253285)
+++ gnat_ugn.texi   (working copy)
@@ -3193,7 +3193,7 @@
 If you are using project file, a separate mechanism is provided using
 project attributes.
 
-@c --Comment:
+@c --Comment
 @c See :ref:`Specifying_Configuration_Pragmas` for more details.
 
 @node Generating Object Files,Source Dependencies,Configuration Pragmas,The 
GNAT Compilation Model
@@ -7925,7 +7925,7 @@
 -u with a project file and no main has a special meaning.
 @end table
 
-@c --Comment:
+@c --Comment
 @c (See :ref:`Project_Files_and_Main_Subprograms`.)
 
 @geindex -U (gnatmake)


RE: 0002-Part-2.-Document-finstrument-control-flow-and-notrack attribute

2017-09-29 Thread Tsimbalist, Igor V
> -Original Message-
> From: Sandra Loosemore [mailto:san...@codesourcery.com]
> Sent: Friday, September 29, 2017 6:57 AM
> To: Tsimbalist, Igor V ; 'gcc-
> patc...@gcc.gnu.org' 
> Cc: Jeff Law 
> Subject: Re: 0002-Part-2.-Document-finstrument-control-flow-and-notrack
> attribute
> 
> On 09/27/2017 06:27 AM, Tsimbalist, Igor V wrote:
> > Updated version #4.
> >
> > [snip]
> > @@ -11348,6 +11349,31 @@ is used to link a program, the GCC driver
> > automatically links  against @file{libmpxwrappers}.  See also @option{-
> static-libmpxwrappers}.
> >  Enabled by default.
> >
> > +@item -fcf-
> protection==@r{[}full@r{|}branch@r{|}return@r{|}none@r{]}
> > +@opindex fcf-protection
> > +Enable code instrumentation of control-flow transfers to increase
> > +program security by checking that target addresses of control-flow
> > +transfer instructions (such as indirect function call, function
> > +return, indirect jump) are valid.  This prevents diverting the flow
> > +of control to an unexpected target.  This is intended to protect
> > +against such threats as Return-oriented Programming (ROP), and
> > +similarly call/jmp-oriented programming (COP/JOP).
> > +
> > +For all targets, which do not support the @option{-fcf-protection}
> > +option, the option usage results in an error message.
> 
> Please take this sentence out.  It's ungrammatical and verbose and
> unnecessary.

Removed.

> Note that several of the other options described in this section are not
> enabled on all targets either.  E.g., I've just been looking at fixing the 
> nios2
> backend to make -fstack-protector work, and there is nothing in the manual
> to say that GCC issues an error if there's no target support, even though
> that's what it does.
> 
> The patch is OK to commit with that change.

Thanks,
Igor

> -Sandra



Re: correct attribute ifunc C++ type safety (PR 82301)

2017-09-29 Thread Martin Sebor

On 09/28/2017 05:23 AM, Pedro Alves wrote:

On 09/25/2017 02:03 AM, Martin Sebor wrote:


+a @option{-Wincompatible-pointer-types} warning for mismatches.  To suppress
+a warning for the necessary cast from a pointer to the implementation member
+function to the type of the corresponding non-member function use the
+@option{-Wno-pmf-conversions} option.  For example:


FWIW, it seems odd to me to tell users they need to suppress warnings, when
the compiler surely could provide better/safer means to avoid needing
to use the reinterpret_cast hammer.   See below.


+
+@smallexample
+class S
+@{
+private:
+  int debug_impl (int);
+  int optimized_impl (int);
+
+  typedef int Func (S*, int);
+
+  static Func* resolver ();
+public:
+
+  int interface (int);
+@};
+
+int S::debug_impl (int) @{ /* @r{@dots{}} */ @}
+int S::optimized_impl (int) @{ /* @r{@dots{}} */ @}
+
+S::Func* S::resolver ()
+@{
+  int (S::*pimpl) (int)
+= getenv ("DEBUG") ? &S::debug_impl : &S::optimized_impl;
+
+  // Cast triggers -Wno-pmf-conversions.
+  return reinterpret_cast(pimpl);
+@}
+


If I were writing code like this, I'd write a reinterpret_cast-like
function specifically for pointer-to-member-function to free-function
casting, and only suppress the warning there instead of disabling
the warning for the whole translation unit.  Something like:

#include 

template struct pmf_as_func;

template
struct pmf_as_func
{
  typedef Ret (func_type) (S *, Args...);
  typedef S struct_type;
};

template
typename pmf_as_func::func_type *
pmf_as_func_cast (Pmf pmf)
{
  static_assert (!std::is_polymorphic::struct_type>::value,
 "");
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wpmf-conversions"
  return reinterpret_cast::func_type *> (pmf);
#pragma GCC diagnostic pop
}


and then write:
 return pmf_as_func_cast (pimpl);

instead of:
  return reinterpret_cast(pimpl);

The point being of course to make it harder to misuse the casts.

But that may be a bit too much for the manual.


Yes, that's a much nicer solution but as you say, more code than
the manual typically includes for warnings.  (It would be a good
example for a Users Guide if GCC had one.)


It also wouldn't work as is with C++03 (because variatic templates).
Which leads me to think that if GCC guarantees this cast works, then
it'd be nice to have GCC provide it (like a __pmf_as_func_cast function)
as builtin.  Then it'd work on C++03 as well, and the compiler of course
can precisely validate whether the cast is valid.  (It's quite possible
that there's a better check than is_polymorphic as I've written above.)


I also don't like the cast and have been thinking about how to
suppress the warning in this case (the ifunc resolver).  But
the only way I can think to make it possible is to defer
-Wno-pmf-conversions until after all function declarations in
the translation unit have been processed.  In other words, run
it in a separate pass and suppress it for functions that have
been aliased via attribute ifunc.  I don't know if there already
is a pass like that it could be hooked into.  If there is, it
should be feasible.

Nathan or Jason, is there something like this?

Martin


RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling

2017-09-29 Thread Tsimbalist, Igor V
Updated patch, version #3.

Igor


> -Original Message-
> From: Tsimbalist, Igor V
> Sent: Friday, September 29, 2017 4:32 PM
> To: Jeff Law ; gcc-patches@gcc.gnu.org
> Cc: richard.guent...@gmail.com; Tsimbalist, Igor V
> 
> Subject: RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> 
> > -Original Message-
> > From: Jeff Law [mailto:l...@redhat.com]
> > Sent: Friday, September 29, 2017 12:44 AM
> > To: Tsimbalist, Igor V ; gcc-
> > patc...@gcc.gnu.org
> > Cc: richard.guent...@gmail.com
> > Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> >
> > On 09/19/2017 07:39 AM, Tsimbalist, Igor V wrote:
> > > Here is an updated patch (version #2). The main differences are:
> > >
> > > - Change attribute and option names;
> > > - Add additional parameter to gimple_build_call_from_tree by adding
> > > a
> > type parameter and
> > >   use it 'nocf_check' attribute propagation;
> > > - Reimplement fixes in expand_call_stmt to propagate 'nocf_check'
> > > attribute;
> > > - Consider 'nocf_check' attribute in Identical Code Folding (ICF)
> > > optimization;
> > > - Add warning for type inconsistency regarding 'nocf_check'
> > > attribute;
> > > - Many small fixes;
> > >
> > > gcc/c-family/
> > >   * c-attribs.c (handle_nocf_check_attribute): New function.
> > >   (c_common_attribute_table): Add 'nocf_check' handling.
> > >   * c-common.c (check_missing_format_attribute): New function.
> > >   * c-common.h: Likewise.
> > >
> > > gcc/c/
> > >   * c-typeck.c (convert_for_assignment): Add check for nocf_check
> > >   attribute.
> > >   * gimple-parser.c: Add second argument NULL to
> > >   gimple_build_call_from_tree.
> > >
> > > gcc/cp/
> > >   * typeck.c (convert_for_assignment): Add check for nocf_check
> > >   attribute.
> > >
> > > gcc/
> > >   * cfgexpand.c (expand_call_stmt): Set REG_CALL_NOCF_CHECK for
> > >   call insn.
> > >   * combine.c (distribute_notes): Add REG_CALL_NOCF_CHECK
> > handling.
> > >   * common.opt: Add fcf-protection flag.
> > >   * emit-rtl.c (try_split): Add REG_CALL_NOCF_CHECK handling.
> > >   * flag-types.h: Add enum cf_protection_level.
> > >   * gimple.c (gimple_build_call_from_tree): Add second parameter.
> > >   Add 'nocf_check' attribute propagation to gimple call.
> > >   * gimple.h (gf_mask): Add GF_CALL_NOCF_CHECK.
> > >   (gimple_call_nocf_check_p): New function.
> > >   (gimple_call_set_nocf_check): Likewise.
> > >   * gimplify.c: Add second argument to gimple_build_call_from_tree.
> > >   * ipa-icf.c: Add nocf_check attribute in statement hash.
> > >   * recog.c (peep2_attempt): Add REG_CALL_NOCF_CHECK handling.
> > >   * reg-notes.def: Add REG_NOTE (CALL_NOCF_CHECK).
> > >   * toplev.c (process_options): Add flag_cf_protection handling.
> > >
> > > Is it ok for trunk?
> > >
> > > Thanks,
> > > Igor
> > >
> > >
> >
> >
> > >
> > > diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
> > > index
> > > 0337537..77d1909 100644
> > > --- a/gcc/c-family/c-attribs.c
> > > +++ b/gcc/c-family/c-attribs.c
> > > @@ -65,6 +65,7 @@ static tree handle_asan_odr_indicator_attribute
> > > (tree *, tree, tree, int,  static tree
> > > handle_stack_protect_attribute (tree *, tree, tree, int, bool *);
> > > static tree handle_noinline_attribute (tree *, tree, tree, int, bool
> > > *);  static tree handle_noclone_attribute (tree *, tree, tree, int,
> > > bool *);
> > > +static tree handle_nocf_check_attribute (tree *, tree, tree, int,
> > > +bool *);
> > >  static tree handle_noicf_attribute (tree *, tree, tree, int, bool
> > > *); static tree handle_noipa_attribute (tree *, tree, tree, int,
> > > bool *); static tree handle_leaf_attribute (tree *, tree, tree, int,
> > > bool *); @@ -367,6 +368,8 @@ const struct attribute_spec
> > c_common_attribute_table[] =
> > >{ "patchable_function_entry",  1, 2, true, false, false,
> > > handle_patchable_function_entry_attribute,
> > > false },
> > > +  { "nocf_check",  0, 0, false, true, true,
> > > +   handle_nocf_check_attribute, false },
> > >{ NULL, 0, 0, false, false, false, NULL, false }
> > >  };
> > >
> > > @@ -783,6 +786,26 @@ handle_noclone_attribute (tree *node, tree
> > name,
> > >return NULL_TREE;
> > >  }
> > >
> > > +/* Handle a "nocf_check" attribute; arguments as in
> > > +   struct attribute_spec.handler.  */
> > > +
> > > +static tree
> > > +handle_nocf_check_attribute (tree *node, tree name,
> > > +   tree ARG_UNUSED (args),
> > > +   int ARG_UNUSED (flags), bool *no_add_attrs) {
> > > +  if (TREE_CODE (*node) != FUNCTION_TYPE
> > > +  && TREE_CODE (*node) != METHOD_TYPE
> > > +  && TREE_CODE (*node) != FIELD_DECL
> > > +  && TREE_CODE (*node) != TYPE_DECL)
> > So curious, is this needed for FIELD_DECL and TYPE_DECL?  ISTM the
> > attribute is applied to function/method types.
> >
> > If we do need to handle FIELD_DECL and TYPE_

Patch I have Formatted in Git

2017-09-29 Thread nick
Greetings All,
I have this patch formatted in git, I was unable to figure out how the whole 
svn works. I
am new to svn. Here is the patch below so any comments on this patch or how to 
format it
properly would be great:
>From a86173b1cab13a8fe5615c53005adcfafb97415f Mon Sep 17 00:00:00 2001
From: Nicholas Krause 
Date: Fri, 29 Sep 2017 11:39:46 -0400
Subject: [PATCH] Fix maybe_complain_about_tail_call_arises
 This patch fixes, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80188 which 
 reports that the char* pointer reason is not being translated properly when 
the 
 error message from the function, maybe_complain_about_tail_call arises. Fix it 
 by wrapping it in the N_ marco to translate to the proper lanuage of the user. 
 No new testcases are required due to the triviality of the bug.

Signed-off-by: Nicholas Krause 
---
 gcc/calls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/calls.c b/gcc/calls.c
index 6bd025ed197..cfdd6b2cf6b 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -1516,7 +1516,7 @@ maybe_complain_about_tail_call (tree call_expr, const 
char *reason)
   if (!CALL_EXPR_MUST_TAIL_CALL (call_expr))
 return;
 
-  error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s", reason);
+  error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s", N_(reason));
 }
 
 /* Fill in ARGS_SIZE and ARGS array based on the parameters found in
-- 
2.11.0



Re: [PATCH,AIX] Initial support for DWARF debug sections in XCOFF.

2017-09-29 Thread Ian Lance Taylor via gcc-patches
On Tue, Aug 1, 2017 at 8:41 AM, REIX, Tony  wrote:
>
> Description:
>  * This patch provides an initial support for DWARF debug sections in XCOFF.
>
> Tests:
>  * AIX: Build: SUCCESS
>- build made by means of gmake.
>
> ChangeLog:
>   * xcoff.c: Initial support for DWARF debug sections in XCOFF.

Sorry, I dropped this one.  Now committed, with this ChangeLog entry.

Ian

2017-09-29  Tony Reix  

* xcoff.c: Initial support for DWARF debug sections in XCOFF.
(STYP_DWARF, SSUBTYP_DW*): Define.
(enum dwarf_section): Define.
(struct dwsect_info): Define.
(xcoff_add): Look for DWARF sections, pass them to
backtrace_dwarf_add.


[PATCH,rs6000] Correct dejagnu directives in several newly added tests

2017-09-29 Thread Kelvin Nilsen

This patch corrects an error in several newly added test programs that
was causing these programs to be SUPPORTED on platforms where they were
not supposed to be SUPPORTED, which was causing unexpected FAILS.

The patch has been preapproved by seg...@gcc.gnu.org.

gcc/testsuite/ChangeLog:

2017-09-29  Kelvin Nilsen  

* gcc.target/powerpc/swaps-p8-30.c: Exchange the order of dg-do
and dg-require-effective-target directives to correct testing
behavior.
* gcc.target/powerpc/swaps-p8-32.c: Likewise.
* gcc.target/powerpc/swaps-p8-41.c: Likewise.
* gcc.target/powerpc/swaps-p8-34.c: Likewise.
* gcc.target/powerpc/swaps-p8-43.c: Likewise.
* gcc.target/powerpc/swaps-p8-36.c: Likewise.
* gcc.target/powerpc/swaps-p8-45.c: Likewise.
* gcc.target/powerpc/swaps-p8-29.c: Likewise.
* gcc.target/powerpc/swaps-p8-38.c: Likewise.
* gcc.target/powerpc/swaps-p8-31.c: Likewise.
* gcc.target/powerpc/swaps-p8-40.c: Likewise.
* gcc.target/powerpc/swaps-p8-33.c: Likewise.
* gcc.target/powerpc/swaps-p8-42.c: Likewise.
* gcc.target/powerpc/swaps-p8-35.c: Likewise.
* gcc.target/powerpc/swaps-p8-44.c: Likewise.
* gcc.target/powerpc/swaps-p8-28.c: Likewise.
* gcc.target/powerpc/swaps-p8-37.c: Likewise.
* gcc.target/powerpc/swaps-p8-39.c: Likewise.


Index: gcc/testsuite/gcc.target/powerpc/swaps-p8-30.c
===
--- gcc/testsuite/gcc.target/powerpc/swaps-p8-30.c  (revision 253294)
+++ gcc/testsuite/gcc.target/powerpc/swaps-p8-30.c  (working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile { target { powerpc64le-*-* } } } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
-/* { dg-do compile { target { powerpc64le-*-* } } } */
 /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } } */
 /* { dg-options "-mcpu=power8 -O3 " } */
 /* { dg-final { scan-assembler-not "xxpermdi" } } */
Index: gcc/testsuite/gcc.target/powerpc/swaps-p8-32.c
===
--- gcc/testsuite/gcc.target/powerpc/swaps-p8-32.c  (revision 253294)
+++ gcc/testsuite/gcc.target/powerpc/swaps-p8-32.c  (working copy)
@@ -1,5 +1,5 @@
+/* { dg-do run { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target p8vector_hw } */
-/* { dg-do run { target { powerpc*-*-* } } } */
 /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } } */
 /* { dg-options "-mcpu=power8 -O3 " } */
 
Index: gcc/testsuite/gcc.target/powerpc/swaps-p8-41.c
===
--- gcc/testsuite/gcc.target/powerpc/swaps-p8-41.c  (revision 253294)
+++ gcc/testsuite/gcc.target/powerpc/swaps-p8-41.c  (working copy)
@@ -1,5 +1,5 @@
+/* { dg-do run { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target p8vector_hw } */
-/* { dg-do run { target { powerpc*-*-* } } } */
 /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } } */
 /* { dg-options "-mcpu=power8 -O3 " } */
 
Index: gcc/testsuite/gcc.target/powerpc/swaps-p8-34.c
===
--- gcc/testsuite/gcc.target/powerpc/swaps-p8-34.c  (revision 253294)
+++ gcc/testsuite/gcc.target/powerpc/swaps-p8-34.c  (working copy)
@@ -1,5 +1,5 @@
+/* { dg-do run { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target p8vector_hw } */
-/* { dg-do run { target { powerpc*-*-* } } } */
 /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } } */
 /* { dg-options "-mcpu=power8 -O3 " } */
 
Index: gcc/testsuite/gcc.target/powerpc/swaps-p8-43.c
===
--- gcc/testsuite/gcc.target/powerpc/swaps-p8-43.c  (revision 253294)
+++ gcc/testsuite/gcc.target/powerpc/swaps-p8-43.c  (working copy)
@@ -1,5 +1,5 @@
+/* { dg-do run { target { powerpc*-*-* } } } */
 /* { dg-require-effective-target p8vector_hw } */
-/* { dg-do run { target { powerpc*-*-* } } } */
 /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } } */
 /* { dg-options "-mcpu=power8 -O3 " } */
 
Index: gcc/testsuite/gcc.target/powerpc/swaps-p8-36.c
===
--- gcc/testsuite/gcc.target/powerpc/swaps-p8-36.c  (revision 253294)
+++ gcc/testsuite/gcc.target/powerpc/swaps-p8-36.c  (working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile { target { powerpc64le-*-* } } } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
-/* { dg-do compile { target { powerpc64le-*-* } } } */
 /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } } */
 /* { dg-options "-mcpu=power8 -O3 " } */
 /* { dg-final { scan-assembler-not "xxpermdi" } } */
Index: gcc/t

[C++ Patch] PR 68754 ("Explicitly defaulted constexpr assignment operator fails to compile")

2017-09-29 Thread Paolo Carlini

Hi,

the main issue, a C++14 rejects-valid, is already fixed in trunk, and a 
while ago I added a testcase for that. However, Andrew noticed that in 
C++11 mode we emit redundant and also a bit puzzling diagnostic (ending 
with one of those annoying "... because:" and nothing after which 
unfortunately we emit in some other cases too). Comparing to, eg, clang 
too, I think we can make progress by simply returning early after the 
first hard error. Also, as an additional tweak, we might replace the 
second error with an inform, per the usual scheme. Tested x86_64-linux.


Thanks, Paolo.

//

/cp
2017-09-29  Paolo Carlini  

PR c++/68754
* method.c (defaulted_late_check): Early return if the defaulted
declaration does not match the expected signature.

/testsuite
2017-09-29  Paolo Carlini  

PR c++/68754
* g++.dg/cpp1y/constexpr-68754.C: Move...
* g++.dg/cpp0x/constexpr-68754.C: ... here, adjust.
Index: cp/method.c
===
--- cp/method.c (revision 253283)
+++ cp/method.c (working copy)
@@ -2191,9 +2191,11 @@ defaulted_late_check (tree fn)
   || !compparms (TYPE_ARG_TYPES (TREE_TYPE (fn)),
 TYPE_ARG_TYPES (TREE_TYPE (implicit_fn
 {
-  error ("defaulted declaration %q+D", fn);
-  error_at (DECL_SOURCE_LOCATION (fn),
-   "does not match expected signature %qD", implicit_fn);
+  error ("defaulted declaration %q+D does not match the "
+"expected signature", fn);
+  inform (DECL_SOURCE_LOCATION (fn),
+ "expected signature: %qD", implicit_fn);
+  return;
 }
 
   if (DECL_DELETED_FN (implicit_fn))
Index: testsuite/g++.dg/cpp0x/constexpr-68754.C
===
--- testsuite/g++.dg/cpp0x/constexpr-68754.C(revision 253283)
+++ testsuite/g++.dg/cpp0x/constexpr-68754.C(working copy)
@@ -1,7 +1,7 @@
 // PR c++/68754
-// { dg-do compile { target c++14 } }
+// { dg-do compile { target c++11 } }
 
 struct base { };
 struct derived : base {
-  constexpr derived& operator=(derived const&) = default;
+  constexpr derived& operator=(derived const&) = default; // { dg-error 
"defaulted declaration" "" { target { ! c++14 } } }
 };
Index: testsuite/g++.dg/cpp1y/constexpr-68754.C
===
--- testsuite/g++.dg/cpp1y/constexpr-68754.C(revision 253283)
+++ testsuite/g++.dg/cpp1y/constexpr-68754.C(working copy)
@@ -1,7 +0,0 @@
-// PR c++/68754
-// { dg-do compile { target c++14 } }
-
-struct base { };
-struct derived : base {
-  constexpr derived& operator=(derived const&) = default;
-};


Re: [PATCH], Add PowerPC ISA 3.0 IEEE 128-bit floating point round to odd built-in functions

2017-09-29 Thread Segher Boessenkool
Hi Mike,

On Thu, Sep 28, 2017 at 06:34:23PM -0400, Michael Meissner wrote:
> This patch addss built-in functions on PowerPC ISA 3.0 (power9) that allow the
> user to access the round to odd IEEE 128-bit floating point instructions.

> --- gcc/config/rs6000/rs6000.md   (revision 253267)
> +++ gcc/config/rs6000/rs6000.md   (working copy)
> @@ -14505,7 +14505,9 @@ (define_insn_and_split "truncsf2_h
>"#"
>"&& 1"
>[(set (match_dup 2)
> - (unspec:DF [(match_dup 1)] UNSPEC_ROUND_TO_ODD))
> + (unspec:DF [(float_truncate:DF
> +  (match_dup 1))]
> +UNSPEC_ROUND_TO_ODD))
> (set (match_dup 0)
>   (float_truncate:SF (match_dup 2)))]
>  {

I don't think this is correct.  It says to first truncate the f128 to DF,
and then round it to odd; I think you want to do the truncation with
round-to-odd rounding mode already.

> +(define_insn "mul3_odd"
> +  [(set (match_operand:IEEE128 0 "altivec_register_operand" "=v")
> + (unspec:IEEE128
> +  [(mult:IEEE128
> +(match_operand:IEEE128 1 "altivec_register_operand" "v")
> +(match_operand:IEEE128 2 "altivec_register_operand" "v"))]
> +  UNSPEC_ROUND_TO_ODD))]
> +  "TARGET_FLOAT128_HW && FLOAT128_IEEE_P (mode)"
> +  "xsmulqpo %0,%1,%2"
> +  [(set_attr "type" "vecfloat")
> +   (set_attr "size" "128")])

Similar here (and everywhere else): it does an f128 mul, so rounding
with whatever rounding mode is current, and *then* it rounds to odd.

> +(define_insn "sqrt2_odd"
> +  [(set (match_operand:IEEE128 0 "altivec_register_operand" "=v")
> + (unspec:IEEE128
> +  [(sqrt:IEEE128
> +(match_operand:IEEE128 1 "altivec_register_operand" "v"))]
> +  UNSPEC_ROUND_TO_ODD))]
> +  "TARGET_FLOAT128_HW && FLOAT128_IEEE_P (mode)"
> +   "xssqrtqpo %0,%1"

(One space too many here).

Everything else looks fine, but that unspec thing needs fixing.  Can be
later, things will likely work for now, so okay for trunk.  Thanks.

How do other ports deal with this?  Insns with a specific rounding mode?
Have a separate unspec for every operation?  Not very nice either :-(


Segher


patch to fix PR82338

2017-09-29 Thread Vladimir Makarov

The following patch fixes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82338

The patch was bootstrapped and tested on x86-64.

Committed as rev. 253259.

Index: ChangeLog
===
--- ChangeLog   (revision 253298)
+++ ChangeLog   (working copy)
@@ -1,3 +1,8 @@
+2017-09-29  Vladimir Makarov 
+
+   PR rtl-optimization/82338
+   * lra-constraints.c (inherit_in_ebb): Check usage_insns check.
+
 2017-09-29  Alexander Monakov 

* genmodes.c (calc_wider_mode): Suppress qsort macro.
Index: lra-constraints.c
===
--- lra-constraints.c   (revision 253298)
+++ lra-constraints.c   (working copy)
@@ -6219,6 +6219,7 @@ inherit_in_ebb (rtx_insn *head, rtx_insn
  && ((cheap = XEXP (cheap, 0)), true)
  && (regno = REGNO (cheap)) >= FIRST_PSEUDO_REGISTER
  && (hard_regno = reg_renumber[regno]) >= 0
+ && usage_insns[regno].check == curr_usage_insns_check
  /* If there are pending saves/restores, the
 optimization is not worth.  */
  && usage_insns[regno].calls_num == calls_num - 1



Patch that fix PR80188

2017-09-29 Thread nick
Greetings,

I don't have write access so can someone commit this bug fix as it fixes,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80188. 

Author: Nicholas Krause 
Date:   Fri Sep 29 11:39:46 2017 -0400

This patch fixes, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80188
which reports that the char* pointer reason is not being translated
properly when the error message from the function,
maybe_complain_about_tail_call arises. Fix it by wrapping it in the
N_ macro to translate to the proper language of the user. No new
test cases are required due to the triviality of the bug.

diff --git a/gcc/calls.c b/gcc/calls.c
index 6bd025ed197..cfdd6b2cf6b 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -1516,7 +1516,7 @@ maybe_complain_about_tail_call (tree call_expr, const 
char *reason)
   if (!CALL_EXPR_MUST_TAIL_CALL (call_expr))
 return;
 
-  error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s", reason);
+  error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s", N_(reason));
 }
 
 /* Fill in ARGS_SIZE and ARGS array based on the parameters found in

Thanks,

Nick 


patch to fix PR81481

2017-09-29 Thread Vladimir Makarov

The following patch fixes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81481

The patch was bootstrapped and tested on x86-64.

Committed as rev. 253300.


Index: ira-costs.c
===
--- ira-costs.c (revision 253253)
+++ ira-costs.c (working copy)
@@ -1471,7 +1471,10 @@ scan_one_insn (rtx_insn *insn)
  && targetm.legitimate_constant_p (GET_MODE (SET_DEST (set)),
XEXP (note, 0))
  && REG_N_SETS (REGNO (SET_DEST (set))) == 1))
-  && general_operand (SET_SRC (set), GET_MODE (SET_SRC (set
+  && general_operand (SET_SRC (set), GET_MODE (SET_SRC (set)))
+  /* LRA does not use equiv with a symbol for PIC code.  */
+  && (! ira_use_lra_p || ! pic_offset_table_rtx
+ || ! contains_symbol_ref_p (XEXP (note, 0
 {
   enum reg_class cl = GENERAL_REGS;
   rtx reg = SET_DEST (set);
bash-4.3$ svn diff --diff-cmd diff -x -up ChangeLog testsuite/ChangeLog 
ira-costs.c testsuite/gcc.target/i386/pr81481.c

Index: ChangeLog
===
--- ChangeLog   (revision 253299)
+++ ChangeLog   (working copy)
@@ -1,5 +1,11 @@
 2017-09-29  Vladimir Makarov 

+   PR target/81481
+   * ira-costs.c (scan_one_insn): Don't take into account PIC equiv
+   with a symbol for LRA.
+
+2017-09-29  Vladimir Makarov 
+
PR rtl-optimization/82338
* lra-constraints.c (inherit_in_ebb): Check usage_insns check.

Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (revision 253299)
+++ testsuite/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2017-09-29  Vladimir Makarov 
+
+   PR target/81481
+   * gcc.target/i386/pr81481.c: New.
+
 2017-09-29  Kelvin Nilsen  

* gcc.target/powerpc/swaps-p8-30.c: Exchange the order of dg-do
Index: ira-costs.c
===
--- ira-costs.c (revision 253253)
+++ ira-costs.c (working copy)
@@ -1471,7 +1471,10 @@ scan_one_insn (rtx_insn *insn)
  && targetm.legitimate_constant_p (GET_MODE (SET_DEST (set)),
XEXP (note, 0))
  && REG_N_SETS (REGNO (SET_DEST (set))) == 1))
-  && general_operand (SET_SRC (set), GET_MODE (SET_SRC (set
+  && general_operand (SET_SRC (set), GET_MODE (SET_SRC (set)))
+  /* LRA does not use equiv with a symbol for PIC code.  */
+  && (! ira_use_lra_p || ! pic_offset_table_rtx
+ || ! contains_symbol_ref_p (XEXP (note, 0
 {
   enum reg_class cl = GENERAL_REGS;
   rtx reg = SET_DEST (set);
Index: testsuite/gcc.target/i386/pr81481.c
===
--- testsuite/gcc.target/i386/pr81481.c (nonexistent)
+++ testsuite/gcc.target/i386/pr81481.c (working copy)
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target ssse3 } */
+/* { dg-options "-O2 -fpic -mssse3" } */
+/* { dg-final { scan-assembler-not "pshufb\[ \t\]\\(%esp\\)" } } */
+#include 
+
+extern const signed char c[31] __attribute__((visibility("hidden")));
+
+__m128i f(__m128i *x, void *v)
+{
+  int i;
+  asm("# %0" : "=r"(i));
+  __m128i t = _mm_loadu_si128((void*)&c[i]);
+  __m128i xx = *x;
+  xx =  _mm_shuffle_epi8(xx, t);
+  asm("# %0 %1 %2" : "+x"(xx) : "r"(c), "r"(i));
+  return xx;
+}



Re: [reviewed] qsort comparator consistency checking

2017-09-29 Thread Christophe Lyon
Hi,


On 29 September 2017 at 15:29, Alexander Monakov  wrote:
> Hello,
>
> I'm going to install the following patch on trunk in the next few hours.
> This revision doesn't offer per-callsite opt-out anymore as suggested by
> Richi on the Cauldron (made possible by fixing all known issues on trunk).
> Thus this patch has a few minor differences compared to the previous
> revision that was ack'ed by Jeff.
>
> Tested on x86_64-linux, i686-linux and ppc64le-linux.
>
> Alexander
>
> * genmodes.c (calc_wider_mode): Suppress qsort macro.
> * system.h [CHECKING_P] (qsort): Redirect to qsort_chk.
> (qsort_chk): Declare.
> * vec.c [CHECKING_P] (qsort_chk_error): New static function.
> (qsort_chk): New function.
>

This patch (r253295) breaks the gcc build for aarch64-linux-gnu:
libtool: compile:
/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/./gcc/xgcc
-shared-libgcc -B/tmp/3041688_6.t
mpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/./gcc
-nostdinc++ -L/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj
-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/src
-L/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-g
nu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/src/.libs
-L/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64
-none-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-linux-gnu/bin/
-B/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-linux-gnu/lib/
-isystem 
/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-linux-gnu/include
-isystem 
/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-linux-gnu/sys-include
-I/tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/../libgcc
-I/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/aarch64-none-linux-gnu
-I/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include
-I/tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++
-D_GLIBCXX_SHARED -std=gnu++14 -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=ops.lo -g -O2 -D_GNU_SOURCE -c
/tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/filesystem/ops.cc
 -fPIC -DPIC -D_GLIBCXX_SHARED -o ops.o
In file included from
/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/deque:66:0,
 from
/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/stack:60,
 from
/tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/filesystem/ops.cc:32:
/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/bits/deque.tcc:
In member function 'void std::deque<_Tp,
_Alloc>::_M_range_insert_aux(std::deque<_Tp, _Alloc>::iterator,
_ForwardIterator, _ForwardIterator, std::forward_iterator_tag) [with
_ForwardIterator =
std::experimental::filesystem::v1::__cxx11::path::iterator; _Tp =
std::experimental::filesystem::v1::__cxx11::path; _Alloc =
std::allocator]':
/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/bits/deque.tcc:626:7:
error: qsort comparator non-negative on sorted output: 8
   }
   ^
during RTL pass: sched2
/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/bits/deque.tcc:626:7:
internal compiler error: qsort checking failed
0x55f7a1 qsort_chk_error
/tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/vec.c:222
0x15337d8 qsort_chk(void*, unsigned long, unsigned long, int (*)(void
const*, void const*))
/tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/vec.c:274
0x14360e0 ready_sort_real

/tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/haifa-sched.c:3087
0x143de85 schedule_block(basic_block_def**, void*)

/tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/haifa-sched.c:6749
0xd42132 schedule_region

/tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-rgn.c:3174
0xd42132 schedule_insns()

/tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-rgn.c:3513
0xd424ee rest_of_handle_sched2

/tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-rgn.c:3737
0xd424ee execute

/tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-r

Re: Patch that fix PR80188

2017-09-29 Thread Bernd Edlinger
 > Greetings,
 >
 > I don't have write access so can someone commit this bug fix as it
 > fixes,
 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80188.
 >
 > Author: Nicholas Krause 
 > Date:   Fri Sep 29 11:39:46 2017 -0400
 >
 >This patch fixes, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80188
 >which reports that the char* pointer reason is not being translated
 >properly when the error message from the function,
 >maybe_complain_about_tail_call arises. Fix it by wrapping it in the
 >N_ macro to translate to the proper language of the user. No new
 >test cases are required due to the triviality of the bug.
 >
 > diff --git a/gcc/calls.c b/gcc/calls.c
 > index 6bd025ed197..cfdd6b2cf6b 100644
 > --- a/gcc/calls.c
 > +++ b/gcc/calls.c
 > @@ -1516,7 +1516,7 @@ maybe_complain_about_tail_call (tree call_expr, 
const char *reason)
 >if (!CALL_EXPR_MUST_TAIL_CALL (call_expr))
 >  return;
 >
 > -  error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s", reason);
 > +  error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s", 
N_(reason));
 > }
 >
 > /* Fill in ARGS_SIZE and ARGS array based on the parameters found in
 >
 > Thanks,
 >
 > Nick

No, this does obviously not fix the problem.

The main problem is that po/gcc.pot does contain the "cannot tail-call"
string but not the various reasons for it, so the translators have
noting to translate.

You should wrap all strings that need to be translated in N_,
and where you do use N_ you should use _(reason).
So that make -C gcc gcc.pot picks them up when the gcc.pot is created,
which is only done on request, but it would be good to check
that the gcc.pot file looks right with your patch at least.

But most importantly a patch like this is worthless when it was not
tested, so the minimum is you have to state that you did bootstrap with
your patch and the test suite did not produce any new failures
that were not there without your patch.


Bernd.


Re: [reviewed] qsort comparator consistency checking

2017-09-29 Thread Andrew Pinski
On Fri, Sep 29, 2017 at 10:46 AM, Christophe Lyon
 wrote:
> Hi,
>
>
> On 29 September 2017 at 15:29, Alexander Monakov  wrote:
>> Hello,
>>
>> I'm going to install the following patch on trunk in the next few hours.
>> This revision doesn't offer per-callsite opt-out anymore as suggested by
>> Richi on the Cauldron (made possible by fixing all known issues on trunk).
>> Thus this patch has a few minor differences compared to the previous
>> revision that was ack'ed by Jeff.
>>
>> Tested on x86_64-linux, i686-linux and ppc64le-linux.
>>
>> Alexander
>>
>> * genmodes.c (calc_wider_mode): Suppress qsort macro.
>> * system.h [CHECKING_P] (qsort): Redirect to qsort_chk.
>> (qsort_chk): Declare.
>> * vec.c [CHECKING_P] (qsort_chk_error): New static function.
>> (qsort_chk): New function.
>>
>
> This patch (r253295) breaks the gcc build for aarch64-linux-gnu:


I was just about to report the same thing.

Thanks,
Andrew

> libtool: compile:
> /tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/./gcc/xgcc
> -shared-libgcc -B/tmp/3041688_6.t
> mpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/./gcc
> -nostdinc++ -L/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj
> -aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/src
> -L/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-g
> nu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/src/.libs
> -L/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64
> -none-linux-gnu/libstdc++-v3/libsupc++/.libs
> -B/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-linux-gnu/bin/
> -B/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-linux-gnu/lib/
> -isystem 
> /tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-linux-gnu/include
> -isystem 
> /tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-linux-gnu/sys-include
> -I/tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/../libgcc
> -I/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/aarch64-none-linux-gnu
> -I/tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include
> -I/tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++
> -D_GLIBCXX_SHARED -std=gnu++14 -Wall -Wextra -Wwrite-strings
> -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections
> -fdata-sections -frandom-seed=ops.lo -g -O2 -D_GNU_SOURCE -c
> /tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/filesystem/ops.cc
>  -fPIC -DPIC -D_GLIBCXX_SHARED -o ops.o
> In file included from
> /tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/deque:66:0,
>  from
> /tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/stack:60,
>  from
> /tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/src/filesystem/ops.cc:32:
> /tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/bits/deque.tcc:
> In member function 'void std::deque<_Tp,
> _Alloc>::_M_range_insert_aux(std::deque<_Tp, _Alloc>::iterator,
> _ForwardIterator, _ForwardIterator, std::forward_iterator_tag) [with
> _ForwardIterator =
> std::experimental::filesystem::v1::__cxx11::path::iterator; _Tp =
> std::experimental::filesystem::v1::__cxx11::path; _Alloc =
> std::allocator]':
> /tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/bits/deque.tcc:626:7:
> error: qsort comparator non-negative on sorted output: 8
>}
>^
> during RTL pass: sched2
> /tmp/3041688_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/bits/deque.tcc:626:7:
> internal compiler error: qsort checking failed
> 0x55f7a1 qsort_chk_error
> /tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/vec.c:222
> 0x15337d8 qsort_chk(void*, unsigned long, unsigned long, int (*)(void
> const*, void const*))
> /tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/vec.c:274
> 0x14360e0 ready_sort_real
> 
> /tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/haifa-sched.c:3087
> 0x143de85 schedule_block(basic_block_def**, void*)
> 
> /tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/haifa-sched.c:6749
> 0xd42132 schedule_region
> 
> /tmp/3041688_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-rgn.c:3174
> 0xd42132 schedule_insns()
> 
> /tmp/3041688_6.tm

[committed][PATCH] Fix minor typos and whitespace errors

2017-09-29 Thread Jeff Law

As pointed out by Bernhard.  Installing on the trunk as obvious.

Jeff
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 63db7ac..1a8f965 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -13967,7 +13967,7 @@ ix86_adjust_stack_and_probe_stack_clash (const 
HOST_WIDE_INT size)
 
  ?!? This should be revamped to work like aarch64 and s390 where
  we track the offset from the most recent probe.  Normally that
- offset would be zero.  For a non-return function we would reset
+ offset would be zero.  For a noreturn function we would reset
  it to PROBE_INTERVAL - (STACK_BOUNDARY / BITS_PER_UNIT).   Then
  we just probe when we cross PROBE_INTERVAL.  */
   if (TREE_THIS_VOLATILE (cfun->decl))
@@ -14047,7 +14047,7 @@ ix86_adjust_stack_and_probe_stack_clash (const 
HOST_WIDE_INT size)
plus_constant (Pmode, sr.reg,
   m->fs.cfa_offset + rounded_size));
  RTX_FRAME_RELATED_P (insn) = 1;
-}
+   }
 
   /* Step 3: the loop.  */
   rtx size_rtx = GEN_INT (rounded_size);
@@ -14060,7 +14060,7 @@ ix86_adjust_stack_and_probe_stack_clash (const 
HOST_WIDE_INT size)
plus_constant (Pmode, stack_pointer_rtx,
   m->fs.cfa_offset));
  RTX_FRAME_RELATED_P (insn) = 1;
-}
+   }
   m->fs.sp_offset += rounded_size;
   emit_insn (gen_blockage ());
 
diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index f7854e9..4e023af 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -1042,7 +1042,7 @@
 (define_predicate "SImode_address_operand"
   (match_code "subreg,zero_extend,and"))
 
-;; Return true if op if a valid address for LEA, and does not contain
+;; Return true if op is a valid address for LEA, and does not contain
 ;; a segment override.  Defined as a special predicate to allow
 ;; mode-less const_int operands pass to address_operand.
 (define_special_predicate "address_no_seg_operand"
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index d2671ba..52a82df 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -11359,7 +11359,7 @@ s390_emit_prologue (void)
   /* When probing for stack-clash mitigation, we have to track the distance
  between the stack pointer and closest known reference.
 
- Most of the time we have to make a worst cast assumption.  The
+ Most of the time we have to make a worst case assumption.  The
  only exception is when TARGET_BACKCHAIN is active, in which case
  we know *sp (offset 0) was written.  */
   HOST_WIDE_INT probe_interval


Re: [reviewed] qsort comparator consistency checking

2017-09-29 Thread Alexander Monakov
On Fri, 29 Sep 2017, Andrew Pinski wrote:
> > This patch (r253295) breaks the gcc build for aarch64-linux-gnu:
> 
> I was just about to report the same thing.

I think autoprefetch ranking heuristic is still wrong if multi_mem_insn_p
may be true; please try this patch.

* haifa-sched.c (autopref_rank_data): Remove.
(autopref_rank_for_schedule): Only use min_offset difference.

diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
index 549e8961411..cea1242e1f1 100644
--- a/gcc/haifa-sched.c
+++ b/gcc/haifa-sched.c
@@ -5647,62 +5647,6 @@ autopref_multipass_init (const rtx_insn *insn, int write)
 }
 
 
-/* Helper for autopref_rank_for_schedule.  Given the data of two
-   insns relevant to the auto-prefetcher modelling code DATA1 and DATA2
-   return their comparison result.  Return 0 if there is no sensible
-   ranking order for the two insns.  */
-
-static int
-autopref_rank_data (autopref_multipass_data_t data1,
-autopref_multipass_data_t data2)
-{
-  /* Simple case when both insns are simple single memory ops.  */
-  if (!data1->multi_mem_insn_p && !data2->multi_mem_insn_p)
-return data1->min_offset - data2->min_offset;
-
-  /* Two load/store multiple insns.  Return 0 if the offset ranges
- overlap and the difference between the minimum offsets otherwise.  */
-  else if (data1->multi_mem_insn_p && data2->multi_mem_insn_p)
-{
-  int min1 = data1->min_offset;
-  int max1 = data1->max_offset;
-  int min2 = data2->min_offset;
-  int max2 = data2->max_offset;
-
-  if (max1 < min2 || min1 > max2)
-   return min1 - min2;
-  else
-   return 0;
-}
-
-  /* The other two cases is a pair of a load/store multiple and
- a simple memory op.  Return 0 if the single op's offset is within the
- range of the multi-op insn and the difference between the single offset
- and the minimum offset of the multi-set insn otherwise.  */
-  else if (data1->multi_mem_insn_p && !data2->multi_mem_insn_p)
-{
-  int max1 = data1->max_offset;
-  int min1 = data1->min_offset;
-
-  if (data2->min_offset >= min1
- && data2->min_offset <= max1)
-   return 0;
-  else
-   return min1 - data2->min_offset;
-}
-  else
-{
-  int max2 = data2->max_offset;
-  int min2 = data2->min_offset;
-
-  if (data1->min_offset >= min2
- && data1->min_offset <= max2)
-   return 0;
-  else
-   return data1->min_offset - min2;
-}
-}
-
 /* Helper function for rank_for_schedule sorting.  */
 static int
 autopref_rank_for_schedule (const rtx_insn *insn1, const rtx_insn *insn2)
@@ -5725,7 +5669,7 @@ autopref_rank_for_schedule (const rtx_insn *insn1, const 
rtx_insn *insn2)
   int irrel2 = data2->status == AUTOPREF_MULTIPASS_DATA_IRRELEVANT;
 
   if (!irrel1 && !irrel2)
-   r = autopref_rank_data (data1, data2);
+   r = data1->min_offset - data2->min_offset;
   else
r = irrel2 - irrel1;
 }


[c-family] Tidy up implementation of -fdump-ada-spec

2017-09-29 Thread Eric Botcazou
This renames a few functions for the sake of consistency as well as merges 
some of them.  No functional changes.

Tested on x86_64-suse-linux, applied on the mainline.


2017-09-29  Eric Botcazou  

* c-ada-spec.c (max_ada_macros): Move around.
(store_ada_macro_index): Likewise.
(source_file): Rename into...
(macro_source_file): ...this.
(count_ada_macro): Move around.
(store_ada_macro): Likewise.
(compare_macro): Likewise.
(print_ada_macros): Merge in...
(dump_ada_macros): ...this.
(source_file_base): Rename into...
(current_source_file): ...this.
(print_comment): Move around.
(dump_ada_nodes): Call dump_ada_declaration directly.
(struct with): Change type of limited field to bool.
(append_withs): Change type of limited_access parameter to bool.
(pp_ada_tree_identifie): Likewise.
(dump_ada_decl_nam): Likewise.
(dump_generic_ada_node): Likewise.  Do not print the return type.
(to_ada_name): Change type of space_found parameter to bool.
(dump_ada_function_declaration): Return void and change type of
parameters to bool.  Also print the return type for a function.
(print_ada_methods): Rename into...
(dump_ada_methods): ...this.
(print_ada_declaration): Rename into ...
(dump_ada_declaration): ...this.  Do not print the return type.
(print_ada_struct_decl): Rename into...
(dump_ada_struct_decl): ...this.

-- 
Eric BotcazouIndex: c-ada-spec.c
===
--- c-ada-spec.c	(revision 253187)
+++ c-ada-spec.c	(working copy)
@@ -32,21 +32,11 @@ along with GCC; see the file COPYING3.
 #include "attribs.h"
 
 /* Local functions, macros and variables.  */
-static int dump_generic_ada_node (pretty_printer *, tree, tree, int, int,
-  bool);
-static int print_ada_declaration (pretty_printer *, tree, tree, int);
-static void print_ada_struct_decl (pretty_printer *, tree, tree, int, bool);
-static void dump_sloc (pretty_printer *buffer, tree node);
-static void print_comment (pretty_printer *, const char *);
-static void print_generic_ada_decl (pretty_printer *, tree, const char *);
-static char *get_ada_package (const char *);
-static void dump_ada_nodes (pretty_printer *, const char *);
-static void reset_ada_withs (void);
-static void dump_ada_withs (FILE *);
-static void dump_ads (const char *, void (*)(const char *),
-		  int (*)(tree, cpp_operation));
-static char *to_ada_name (const char *, int *);
-static bool separate_class_package (tree);
+static int  dump_generic_ada_node (pretty_printer *, tree, tree, int, bool,
+   bool);
+static int  dump_ada_declaration (pretty_printer *, tree, tree, int);
+static void dump_ada_struct_decl (pretty_printer *, tree, tree, int, bool);
+static char *to_ada_name (const char *, bool *);
 
 #define INDENT(SPACE) \
   do { int i; for (i = 0; ivalue.macro;
+
+  if (node->type == NT_MACRO && !(node->flags & NODE_BUILTIN)
+  && macro->count
+  && *NODE_NAME (node) != '_'
+  && LOCATION_FILE (macro->line) == macro_source_file)
+max_ada_macros++;
+
+  return 1;
+}
+
+/* Callback used to store relevant macros from cpp_forall_identifiers.
+   PFILE is not used.  NODE is the current macro to store if relevant.
+   MACROS is an array of cpp_hashnode* used to store NODE.  */
+
+static int
+store_ada_macro (cpp_reader *pfile ATTRIBUTE_UNUSED,
+		 cpp_hashnode *node, void *macros)
+{
+  const cpp_macro *macro = node->value.macro;
+
+  if (node->type == NT_MACRO && !(node->flags & NODE_BUILTIN)
+  && macro->count
+  && *NODE_NAME (node) != '_'
+  && LOCATION_FILE (macro->line) == macro_source_file)
+((cpp_hashnode **) macros)[store_ada_macro_index++] = node;
+
+  return 1;
+}
+
+/* Callback used to compare (during qsort) macros.  NODE1 and NODE2 are the
+   two macro nodes to compare.  */
+
+static int
+compare_macro (const void *node1, const void *node2)
+{
+  typedef const cpp_hashnode *const_hnode;
+
+  const_hnode n1 = *(const const_hnode *) node1;
+  const_hnode n2 = *(const const_hnode *) node2;
+
+  return n1->value.macro->line - n2->value.macro->line;
+}
+
+/* Dump in PP all relevant macros appearing in FILE.  */
 
 static void
-print_ada_macros (pretty_printer *pp, cpp_hashnode **macros, int max_ada_macros)
+dump_ada_macros (pretty_printer *pp, const char* file)
 {
-  int j, num_macros = 0, prev_line = -1;
+  int num_macros = 0, prev_line = -1;
+  cpp_hashnode **macros;
+
+  /* Initialize file-scope variables.  */
+  max_ada_macros = 0;
+  store_ada_macro_index = 0;
+  macro_source_file = file;
+
+  /* Count all potentially relevant macros, and then sort them by sloc.  */
+  cpp_forall_identifiers (parse_in, count_ada_macro, NULL);
+  macros = XALLOCAVEC (cpp_hashnode *, max_ada_macros);
+  cpp_forall_identifiers (parse_in, store_ada_macro, macros);
+  qsort (macros, max_ada_ma

Re: Patch that fix PR80188

2017-09-29 Thread nick


On 2017-09-29 01:48 PM, Bernd Edlinger wrote:
>  > Greetings,
>  >
>  > I don't have write access so can someone commit this bug fix as it
>  > fixes,
>  > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80188.
>  >
>  > Author: Nicholas Krause 
>  > Date:   Fri Sep 29 11:39:46 2017 -0400
>  >
>  >This patch fixes, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80188
>  >which reports that the char* pointer reason is not being translated
>  >properly when the error message from the function,
>  >maybe_complain_about_tail_call arises. Fix it by wrapping it in the
>  >N_ macro to translate to the proper language of the user. No new
>  >test cases are required due to the triviality of the bug.
>  >
>  > diff --git a/gcc/calls.c b/gcc/calls.c
>  > index 6bd025ed197..cfdd6b2cf6b 100644
>  > --- a/gcc/calls.c
>  > +++ b/gcc/calls.c
>  > @@ -1516,7 +1516,7 @@ maybe_complain_about_tail_call (tree call_expr, 
> const char *reason)
>  >if (!CALL_EXPR_MUST_TAIL_CALL (call_expr))
>  >  return;
>  >
>  > -  error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s", reason);
>  > +  error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s", 
> N_(reason));
>  > }
>  >
>  > /* Fill in ARGS_SIZE and ARGS array based on the parameters found in
>  >
>  > Thanks,
>  >
>  > Nick
> 
> No, this does obviously not fix the problem.
> 
> The main problem is that po/gcc.pot does contain the "cannot tail-call"
> string but not the various reasons for it, so the translators have
> noting to translate.
> 
> You should wrap all strings that need to be translated in N_,
> and where you do use N_ you should use _(reason).
> So that make -C gcc gcc.pot picks them up when the gcc.pot is created,
> which is only done on request, but it would be good to check
> that the gcc.pot file looks right with your patch at least.
> 

So I understand correctly the gcc.pot is used for something and that the
cannot tail call but not the various reasons for it. So this N_ marco 
is a way to get debugging or symbol information or something more like:

error_at (EXPR_LOCATION (call_expr),N_("cannot tail-call: %s"),

gcc.pot for that line is: 
#: calls.c:1516
▸ prev-zlib/   |16905 #, gcc-internal-format, 
gfc-internal-format
▸ stage1-fixincludes/  |16906 msgid "cannot tail-call: %s"
▸ stage1-gcc/  |16907 msgstr ""

This seems wrong to me but I am new so double checking would be nice. Or our to 
talking
about all lines in gcc.pot requiring something similar? I am a bit confused by 
is it
just this area or all of the output that needs fixing in gcc.pot?
> But most importantly a patch like this is worthless when it was not
> tested, so the minimum is you have to state that you did bootstrap with
> your patch and the test suite did not produce any new failures
> that were not there without your patch.
> 
> 
I ran the test suite and got no known new failures. I assumed that I didn't need
to report that but if so that's fine. This is something I always do if possible.
Thanks for the quick reply, 
Nick  
> Bernd.
> 


[c-family] Implement support for overloading in -fdump-ada-spec

2017-09-29 Thread Eric Botcazou
Tested on x86_64-suse-linux, applied on the mainline.


2017-09-29  Eric Botcazou  

* c-ada-spec.c (to_ada_name): Add index parameter.
(pp_ada_tree_identifier): Likewise.
(dump_ada_macros): Adjust call to to_ada_name.
(struct overloaded_name_hash): New type.
(struct overloaded_name_hasher): Likewise.
(overloaded_names): New hash table.
(compute_overloading_index): New function.
(dump_ada_decl_name): Call it and pass the result to
pp_ada_tree_identifier.
(dump_ada_double_name): Adjust calls to pp_ada_tree_identifier.
(dump_ada_function_declaration): Likewise.
(dump_generic_ada_node): Likewise.
(print_constructor): Likewise.
(print_destructor): Likewise.
(dump_ada_specs): Delete overloaded_names table.


2017-09-29  Eric Botcazou  

* g++.dg/other/dump-ada-spec-10.C: New test.

-- 
Eric BotcazouIndex: c-ada-spec.c
===
--- c-ada-spec.c	(revision 253304)
+++ c-ada-spec.c	(working copy)
@@ -36,7 +36,7 @@ static int  dump_generic_ada_node (prett
    bool);
 static int  dump_ada_declaration (pretty_printer *, tree, tree, int);
 static void dump_ada_struct_decl (pretty_printer *, tree, tree, int, bool);
-static char *to_ada_name (const char *, bool *);
+static char *to_ada_name (const char *, unsigned int, bool *);
 
 #define INDENT(SPACE) \
   do { int i; for (i = 0; i homonyms;
+};
+
+struct overloaded_name_hasher : delete_ptr_hash
+{
+  static inline hashval_t hash (overloaded_name_hash *t)
+{ return t->hash; }
+  static inline bool equal (overloaded_name_hash *a, overloaded_name_hash *b)
+{ return a->name == b->name && a->context == b->context; }
+};
+
+static hash_table *overloaded_names;
+
+/* Compute the overloading index of function DECL in its context.  */
+
+static unsigned int
+compute_overloading_index (tree decl)
+{
+  const hashval_t hashcode
+= iterative_hash_hashval_t (htab_hash_pointer (DECL_NAME (decl)),
+			htab_hash_pointer (DECL_CONTEXT (decl)));
+  struct overloaded_name_hash in, *h, **slot;
+  unsigned int index, *iter;
+
+  if (!overloaded_names)
+overloaded_names = new hash_table (512);
+
+  /* Look up the list of homonyms in the table.  */
+  in.hash = hashcode;
+  in.name = DECL_NAME (decl);
+  in.context = DECL_CONTEXT (decl);
+  slot = overloaded_names->find_slot_with_hash (&in, hashcode, INSERT);
+  if (*slot)
+h = *slot;
+  else
+{
+  h = new overloaded_name_hash;
+  h->hash = hashcode;
+  h->name = DECL_NAME (decl);
+  h->context = DECL_CONTEXT (decl);
+  h->homonyms.create (0);
+  *slot = h;
+}
+
+  /* Look up the function in the list of homonyms.  */
+  FOR_EACH_VEC_ELT (h->homonyms, index, iter)
+if (*iter == DECL_UID (decl))
+  break;
+
+  /* If it is not present, push it onto the list.  */
+  if (!iter)
+h->homonyms.safe_push (DECL_UID (decl));
+
+  return index;
+}
+
 /* Dump in BUFFER the name of a DECL node if set, following Ada syntax.
LIMITED_ACCESS indicates whether NODE can be accessed via a limited
'with' clause rather than a regular 'with' clause.  */
@@ -1434,7 +1505,13 @@ static void
 dump_ada_decl_name (pretty_printer *buffer, tree decl, bool limited_access)
 {
   if (DECL_NAME (decl))
-pp_ada_tree_identifier (buffer, DECL_NAME (decl), decl, limited_access);
+{
+  const unsigned int index
+	= (TREE_CODE (decl) == FUNCTION_DECL && cpp_check)
+	  ? compute_overloading_index (decl) : 0;
+  pp_ada_tree_identifier (buffer, DECL_NAME (decl), decl, index,
+			  limited_access);
+}
   else
 {
   tree type_name = TYPE_NAME (TREE_TYPE (decl));
@@ -1448,7 +1525,7 @@ dump_ada_decl_name (pretty_printer *buff
 	pp_scalar (buffer, "%d", TYPE_UID (TREE_TYPE (decl)));
 	}
   else if (TREE_CODE (type_name) == IDENTIFIER_NODE)
-	pp_ada_tree_identifier (buffer, type_name, decl, limited_access);
+	pp_ada_tree_identifier (buffer, type_name, decl, 0, limited_access);
 }
 }
 
@@ -1458,7 +1535,7 @@ static void
 dump_ada_double_name (pretty_printer *buffer, tree t1, tree t2)
 {
   if (DECL_NAME (t1))
-pp_ada_tree_identifier (buffer, DECL_NAME (t1), t1, false);
+pp_ada_tree_identifier (buffer, DECL_NAME (t1), t1, 0, false);
   else
 {
   pp_string (buffer, "anon");
@@ -1468,7 +1545,7 @@ dump_ada_double_name (pretty_printer *bu
   pp_underscore (buffer);
 
   if (DECL_NAME (t2))
-pp_ada_tree_identifier (buffer, DECL_NAME (t2), t2, false);
+pp_ada_tree_identifier (buffer, DECL_NAME (t2), t2, 0, false);
   else
 {
   pp_string (buffer, "anon");
@@ -1622,7 +1699,7 @@ dump_ada_function_declaration (pretty_pr
 	  if (DECL_NAME (arg))
 	{
 	  check_name (buffer, arg);
-	  pp_ada_tree_identifier (buffer, DECL_NAME (arg), NULL_TREE,
+	  pp_ada_tree_identifier (buffer, DECL_NAME (arg), NULL_TREE, 0,
   false);
 	  pp_string (buf

Re: [patch, libfortran] Fix thead sanitizer issue with libgfortran

2017-09-29 Thread Thomas Koenig

Am 29.09.2017 um 10:03 schrieb Janne Blomqvist:



1) I'm confused why fbuf_destroy is modified. The fbuf structure is
part of gfc_unit, and should be accessed with the same locking rules
as the rest of the gfc_unit components. When closing the unit, I think
the same should apply here, no?


It is to avoid a data race for

program main
  use omp_lib
  !$OMP PARALLEL NUM_THREADS(2)
  call file_open(OMP_get_thread_num())
  !$OMP END PARALLEL
contains
  recursive subroutine file_open(i)
  integer :: i
  integer :: nunit
  nunit = i + 20
  write (nunit,*) 'asdf'
  end subroutine file_open
end program main

which leads to

  Read of size 4 at 0x7b58ff30 by main thread (mutexes: write M16):
#0 close_unit_1 ../../../trunk/libgfortran/io/unit.c:699 
(libgfortran.so.5+0x00283ba6)
#1 _gfortrani_close_units ../../../trunk/libgfortran/io/unit.c:767 
(libgfortran.so.5+0x00283f59)
#2 cleanup ../../../trunk/libgfortran/runtime/main.c:113 
(libgfortran.so.5+0x0001fe22)

#3 _dl_fini  (ld-linux-x86-64.so.2+0xfb62)

  Previous write of size 4 at 0x7b58ff30 by thread T1 (mutexes: 
write M17):
#0 finalize_transfer ../../../trunk/libgfortran/io/transfer.c:3934 
(libgfortran.so.5+0x00281aa1)
#1 _gfortran_st_write_done 
../../../trunk/libgfortran/io/transfer.c:4125 
(libgfortran.so.5+0x00281e35)

#2 file_open.3528  (a.out+0x00400c1b)
#3 MAIN__._omp_fn.0  (a.out+0x00400d27)
#4 gomp_thread_start ../../../trunk/libgomp/team.c:120 
(libgomp.so.1+0x0001756f)


Note that not all problems with implicit close at the end are resolved
so far, but that is a different problem.


2) I think the mutex init stuff can remain in insert_unit, just the
locking needs to move out and below freeing unit_lock like you have
done.


I can change that one easily.

Any other comments?

Regards

Thomas



Re: [C++ Patch] PR 68754 ("Explicitly defaulted constexpr assignment operator fails to compile")

2017-09-29 Thread Nathan Sidwell

On 09/29/2017 10:04 AM, Paolo Carlini wrote:

Hi,

the main issue, a C++14 rejects-valid, is already fixed in trunk, and a 
while ago I added a testcase for that. However, Andrew noticed that in 
C++11 mode we emit redundant and also a bit puzzling diagnostic (ending 
with one of those annoying "... because:" and nothing after which 
unfortunately we emit in some other cases too). Comparing to, eg, clang 
too, I think we can make progress by simply returning early after the 
first hard error. Also, as an additional tweak, we might replace the 
second error with an inform, per the usual scheme. Tested x86_64-linux.


Looks good, thanks.

nathan

--
Nathan Sidwell


Re: [RFC] propagate malloc attribute in ipa-pure-const pass

2017-09-29 Thread Jan Hubicka
> > I wonder what happens here when, say, ipa-icf redirect the call to eqivaelnt
> > function and removes the callee?  Perhaps we realy want to have set of call
> > sites rahter than nodes stored from analysis to execution. Call sites have
> > unique stmts and uids, so it will be possible to map them back and forth.
> IIUC, call site is represented using cgraph_edge ?

Yes, there is call_stmt pointer when gimple is read and uid in WPA mode which
are unique.  There is call_summary class which lets you to associate info with
a call site. While it is not most memory effecient to store one bit of 
information
this way, i guess it may be easiest to use it in anticipation of it becoming
more useful in foreseeable future.  We have some bits in call edge itself that
may be shuffled to the summary as well.

> So change return_callees_map to be the mapping from node to subset of
> it's call-sites where
> node returns the value of one of it's callees:
> static hash_map< cgraph_node *, vec *> *return_callees_map; ?

This should work too, though storing direct pointers to edges is something we
probably want to avoid to keep memory representation of edges in bounds.

I would go with call_summary - everything else seems like bit of premature
optimization.  If we will decide to optimize it later, we may invent a variant
of summary datatype for that.

Thanks,
Honza


isl scheduler and spatial locality (Re: [PATCH][GRAPHITE] More TLC)

2017-09-29 Thread Sven Verdoolaege
On Wed, Sep 27, 2017 at 02:18:51PM +0200, Richard Biener wrote:
> Ah, so I now see why we do not perform interchange on trivial cases like
> 
> double A[1024][1024], B[1024][1024];
> 
> void foo(void)
> {
>   for (int i = 0; i < 1024; ++i)
> for (int j = 0; j < 1024; ++j)
>   A[j][i] = B[j][i];
> }

I didn't see you mentioning _why_ you expect an interchange here.
Are you prehaps interested in spatial locality?
If so, then there are several approaches for taking
that into account.
- pluto performs an intra-tile loop interchange to
  improve temporal and/or spatial locality.  It shouldn't
  be too hard to do something similar on an isl generated
  schedule
- Alex (Oleksandr) has been working on an extension of
  the isl scheduler that takes into account spatial locality.
  I'm not sure if it's publicly available.
- I've been working on a special case of spatial locality
  (consecutivity).  The current version is available in
  the consecutivity branch.  Note that it may get rebased and
  it may not necessarily get merged into master.

There are also other approaches, but they may not be that
easy to combine with the isl scheduler.

skimo


isl scheduler and spatial locality (Re: [PATCH][GRAPHITE] More TLC)

2017-09-29 Thread Sven Verdoolaege
[Sorry for the resend; I used the wrong email address to CC Alex]

On Wed, Sep 27, 2017 at 02:18:51PM +0200, Richard Biener wrote:
> Ah, so I now see why we do not perform interchange on trivial cases like
> 
> double A[1024][1024], B[1024][1024];
> 
> void foo(void)
> {
>   for (int i = 0; i < 1024; ++i)
> for (int j = 0; j < 1024; ++j)
>   A[j][i] = B[j][i];
> }

I didn't see you mentioning _why_ you expect an interchange here.
Are you prehaps interested in spatial locality?
If so, then there are several approaches for taking
that into account.
- pluto performs an intra-tile loop interchange to
  improve temporal and/or spatial locality.  It shouldn't
  be too hard to do something similar on an isl generated
  schedule
- Alex (Oleksandr) has been working on an extension of
  the isl scheduler that takes into account spatial locality.
  I'm not sure if it's publicly available.
- I've been working on a special case of spatial locality
  (consecutivity).  The current version is available in
  the consecutivity branch.  Note that it may get rebased and
  it may not necessarily get merged into master.

There are also other approaches, but they may not be that
easy to combine with the isl scheduler.

skimo


Re: [reviewed] qsort comparator consistency checking

2017-09-29 Thread Steve Ellcey
On Fri, 2017-09-29 at 21:14 +0300, Alexander Monakov wrote:
> On Fri, 29 Sep 2017, Andrew Pinski wrote:
> > 
> > > 
> > > This patch (r253295) breaks the gcc build for aarch64-linux-gnu:
> > I was just about to report the same thing.
> I think autoprefetch ranking heuristic is still wrong if
> multi_mem_insn_p
> may be true; please try this patch.
> 
>   * haifa-sched.c (autopref_rank_data): Remove.
>   (autopref_rank_for_schedule): Only use min_offset difference.

This fixed the build for me on aarch64.  I am still running the
testsuite.

Steve Ellcey
sell...@cavium.com


Re: [reviewed] qsort comparator consistency checking

2017-09-29 Thread Christophe Lyon
On 29 September 2017 at 21:39, Steve Ellcey  wrote:
> On Fri, 2017-09-29 at 21:14 +0300, Alexander Monakov wrote:
>> On Fri, 29 Sep 2017, Andrew Pinski wrote:
>> >
>> > >
>> > > This patch (r253295) breaks the gcc build for aarch64-linux-gnu:
>> > I was just about to report the same thing.
>> I think autoprefetch ranking heuristic is still wrong if
>> multi_mem_insn_p
>> may be true; please try this patch.
>>
>>   * haifa-sched.c (autopref_rank_data): Remove.
>>   (autopref_rank_for_schedule): Only use min_offset difference.
>
> This fixed the build for me on aarch64.  I am still running the
> testsuite.
>

It doesn't for me. I'm getting another build error:
/home/christophe.lyon/src/GCC/sources/gcc-fsf/aarch64-build/gcc/haifa-sched.c:
In function ‘int autopref_multipass_dfa_lookahead_guard_1(const
rtx_insn*, const rtx_insn*, int)’:
/home/christophe.lyon/src/GCC/sources/gcc-fsf/aarch64-build/gcc/haifa-sched.c:5700:42:
error: ‘autopref_rank_data’ was not declared in this scope

The removed autopref_rank_data function is still called by
autopref_multipass_dfa_lookahead_guard_1.

Christophe

> Steve Ellcey
> sell...@cavium.com


Re: [reviewed] qsort comparator consistency checking

2017-09-29 Thread Steve Ellcey
On Fri, 2017-09-29 at 21:43 +0200, Christophe Lyon wrote:
> On 29 September 2017 at 21:39, Steve Ellcey 
> wrote:
> > 
> > On Fri, 2017-09-29 at 21:14 +0300, Alexander Monakov wrote:
> > > 
> > > On Fri, 29 Sep 2017, Andrew Pinski wrote:
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > This patch (r253295) breaks the gcc build for aarch64-linux-
> > > > > gnu:
> > > > I was just about to report the same thing.
> > > I think autoprefetch ranking heuristic is still wrong if
> > > multi_mem_insn_p
> > > may be true; please try this patch.
> > > 
> > >   * haifa-sched.c (autopref_rank_data): Remove.
> > >   (autopref_rank_for_schedule): Only use min_offset
> > > difference.
> > This fixed the build for me on aarch64.  I am still running the
> > testsuite.
> > 
> It doesn't for me. I'm getting another build error:
> /home/christophe.lyon/src/GCC/sources/gcc-fsf/aarch64-
> build/gcc/haifa-sched.c:
> In function ‘int autopref_multipass_dfa_lookahead_guard_1(const
> rtx_insn*, const rtx_insn*, int)’:
> /home/christophe.lyon/src/GCC/sources/gcc-fsf/aarch64-
> build/gcc/haifa-sched.c:5700:42:
> error: ‘autopref_rank_data’ was not declared in this scope
> 
> The removed autopref_rank_data function is still called by
> autopref_multipass_dfa_lookahead_guard_1.

OK, I actually cheated and removed the call but not the function itself
because 'it couldn't possible matter, could it'?  :-)

Steve Ellcey


Re: Patch that fix PR80188

2017-09-29 Thread Bernd Edlinger
On 09/29/17 20:22, nick wrote:
> 
> 
> On 2017-09-29 01:48 PM, Bernd Edlinger wrote:
>>   > Greetings,
>>   >
>>   > I don't have write access so can someone commit this bug fix as it
>>   > fixes,
>>   > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80188.
>>   >
>>   > Author: Nicholas Krause 
>>   > Date:   Fri Sep 29 11:39:46 2017 -0400
>>   >
>>   >This patch fixes, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80188
>>   >which reports that the char* pointer reason is not being translated
>>   >properly when the error message from the function,
>>   >maybe_complain_about_tail_call arises. Fix it by wrapping it in the
>>   >N_ macro to translate to the proper language of the user. No new
>>   >test cases are required due to the triviality of the bug.
>>   >

BTW: the change log is not in GNU style. Please re-word.

>>   > diff --git a/gcc/calls.c b/gcc/calls.c
>>   > index 6bd025ed197..cfdd6b2cf6b 100644
>>   > --- a/gcc/calls.c
>>   > +++ b/gcc/calls.c
>>   > @@ -1516,7 +1516,7 @@ maybe_complain_about_tail_call (tree call_expr,
>> const char *reason)
>>   >if (!CALL_EXPR_MUST_TAIL_CALL (call_expr))
>>   >  return;
>>   >
>>   > -  error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s", reason);
>>   > +  error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s",
>> N_(reason));
>>   > }
>>   >
>>   > /* Fill in ARGS_SIZE and ARGS array based on the parameters found in
>>   >
>>   > Thanks,
>>   >
>>   > Nick
>>
>> No, this does obviously not fix the problem.
>>
>> The main problem is that po/gcc.pot does contain the "cannot tail-call"
>> string but not the various reasons for it, so the translators have
>> noting to translate.
>>
>> You should wrap all strings that need to be translated in N_,
>> and where you do use N_ you should use _(reason).
>> So that make -C gcc gcc.pot picks them up when the gcc.pot is created,
>> which is only done on request, but it would be good to check
>> that the gcc.pot file looks right with your patch at least.
>>
> 
> So I understand correctly the gcc.pot is used for something and that the
> cannot tail call but not the various reasons for it. So this N_ marco
> is a way to get debugging or symbol information or something more like:
> 

Yes, I don't know all the details, but I think from time to time
some one runs a script that extracts all english strings from the gcc
sources.  The result is in gcc.pot, and as you can see it already
contains the string "cannot tail-call: %s" because the used tool
knows what error_at does.  But it does not know what
maybe_complain_about_tail_call does.  Therefore gcc.pot misses the
string "a callee-copied argument is stored in the current function's frame".

Then a lot of people go over the strings and translate to lots of
different languages.  Result is checked in SVN and used at runtime
by the _() function, which is a data base lookup, while N_() does
only annotate the string, and expands to nothing at runtime.

> error_at (EXPR_LOCATION (call_expr),N_("cannot tail-call: %s"),
> 

Please do not fix something that is not broken.
error_at does internally translate the first argument.
But I believe that is not the case for the format arguments.
so I think reason needs to be passed thru _().

> gcc.pot for that line is:
> #: calls.c:1516
> ▸ prev-zlib/   |16905 #, gcc-internal-format, 
> gfc-internal-format
> ▸ stage1-fixincludes/  |16906 msgid "cannot tail-call: %s"
> ▸ stage1-gcc/  |16907 msgstr ""
> 
> This seems wrong to me but I am new so double checking would be nice. Or our 
> to talking
> about all lines in gcc.pot requiring something similar? I am a bit confused 
> by is it
> just this area or all of the output that needs fixing in gcc.pot?

I think this is only about the way how the cannot tail-call warning
is formatted.

>> But most importantly a patch like this is worthless when it was not
>> tested, so the minimum is you have to state that you did bootstrap with
>> your patch and the test suite did not produce any new failures
>> that were not there without your patch.
>>
>>
> I ran the test suite and got no known new failures. I assumed that I didn't 
> need
> to report that but if so that's fine. This is something I always do if 
> possible.
> Thanks for the quick reply,
> Nick

If you look at a few messages here, and you will see always a line
like "patch was boot-strapped and regression tested on
x86_64-pc-linux-gnu, is it OK for trunk?"

That's kind of required, otherwise we do not know what you have
actually tested.


Bernd.


Re: isl scheduler and spatial locality (Re: [PATCH][GRAPHITE] More TLC)

2017-09-29 Thread Sebastian Pop
On Fri, Sep 29, 2017 at 2:37 PM, Sven Verdoolaege
 wrote:
> [Sorry for the resend; I used the wrong email address to CC Alex]
>
> On Wed, Sep 27, 2017 at 02:18:51PM +0200, Richard Biener wrote:
>> Ah, so I now see why we do not perform interchange on trivial cases like
>>
>> double A[1024][1024], B[1024][1024];
>>
>> void foo(void)
>> {
>>   for (int i = 0; i < 1024; ++i)
>> for (int j = 0; j < 1024; ++j)
>>   A[j][i] = B[j][i];
>> }
>
> I didn't see you mentioning _why_ you expect an interchange here.
> Are you prehaps interested in spatial locality?
> If so, then there are several approaches for taking
> that into account.
> - pluto performs an intra-tile loop interchange to
>   improve temporal and/or spatial locality.  It shouldn't
>   be too hard to do something similar on an isl generated
>   schedule
> - Alex (Oleksandr) has been working on an extension of
>   the isl scheduler that takes into account spatial locality.
>   I'm not sure if it's publicly available.
> - I've been working on a special case of spatial locality
>   (consecutivity).  The current version is available in
>   the consecutivity branch.  Note that it may get rebased and
>   it may not necessarily get merged into master.
>
> There are also other approaches, but they may not be that
> easy to combine with the isl scheduler.

Would the following work?
Add to the proximity relation the array accesses from two
successive iterations of the innermost loop:
A[j][i] -> A[j][i+1] and B[j][i] -> B[j][i+1]
With these two extra relations in the proximity map,
isl should be able to interchange the above loop.

Sebastian


Re: [PATCH] Improve -Ofast vectorization of std::sin etc. (PR libstdc++/81706)

2017-09-29 Thread Joseph Myers
On Fri, 29 Sep 2017, Jakub Jelinek wrote:

> Here is a patch which does that.  Also bootstrapped/regtested on
> x86_64-linux and i686-linux, ok for trunk?

>   * c-decl.c (merge_decls): Copy "omp declare simd" attributes from
>   newdecl to corresponding __builtin_ if any.

The C front-end changes are OK.

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: Patch I have Formatted in Git

2017-09-29 Thread Joseph Myers
On Fri, 29 Sep 2017, nick wrote:

> -  error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s", reason);
> +  error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s", N_(reason));

This can't be right.  N_ only makes sense around a string literal (e.g. in 
a constant initializer); it marks a string for extraction for translation, 
but does not cause it to be translated at runtime.  You need _() to cause 
the translation at runtime (and then make sure that every string constant 
that can end up as a value of reason is surrounded by N_() - or just 
surround the string constants directly by _() if there isn't a reason that 
won't work).

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [Patch][aarch64] Use IFUNCs to enable LSE instructions in libatomic on aarch64

2017-09-29 Thread Steve Ellcey
On Thu, 2017-09-28 at 12:31 +0100, Szabolcs Nagy wrote:
> 
> i think this should be improved, see below.

Those were all good suggestions, here is a new patch that incorporates
the changes.  I fixed the IFUNC_OPTIONS argument,
renamed ARCH_AARCH64_LINUX_LSE, got rid of the auxv references, and
changed HWCAP_TYPE to IFUNC_RESOLVER_ARGS.

Here is the new patch, tested with no regressions.

Steve Ellcey
sell...@cavium.com


2017-09-29  Steve Ellcey  

* Makefile.am (ARCH_AARCH64_LINUX): Add IFUNC_OPTIONS and
libatomic_la_LIBADD.
* config/linux/aarch64/host-config.h: New file.
* configure.ac (IFUNC_RESOLVER_ARGS): Define.
(ARCH_AARCH64_LINUX): New conditional for IFUNC builds.
* configure.tgt (aarch64): Set ARCH and try_ifunc.
(aarch64*-*-linux*) Update config_path.
(aarch64*-*-linux*) Set IFUNC_RESOLVER_ARGS.
* libatomic_i.h (GEN_SELECTOR): Add IFUNC_RESOLVER_ARGS argument.
* Makefile.in: Regenerate.
* auto-config.h.in: Regenerate.
* configure: Regenerate.

diff --git a/libatomic/Makefile.am b/libatomic/Makefile.am
index d731406..92d19c6 100644
--- a/libatomic/Makefile.am
+++ b/libatomic/Makefile.am
@@ -122,6 +122,10 @@ libatomic_la_LIBADD = $(foreach s,$(SIZES),$(addsuffix _$(s)_.lo,$(SIZEOBJS)))
 
 ## On a target-specific basis, include alternates to be selected by IFUNC.
 if HAVE_IFUNC
+if ARCH_AARCH64_LINUX
+IFUNC_OPTIONS	 = -march=armv8.1-a
+libatomic_la_LIBADD += $(foreach s,$(SIZES),$(addsuffix _$(s)_1_.lo,$(SIZEOBJS)))
+endif
 if ARCH_ARM_LINUX
 IFUNC_OPTIONS	 = -march=armv7-a -DHAVE_KERNEL64
 libatomic_la_LIBADD += $(foreach s,$(SIZES),$(addsuffix _$(s)_1_.lo,$(SIZEOBJS)))
diff --git a/libatomic/config/linux/aarch64/host-config.h b/libatomic/config/linux/aarch64/host-config.h
index e69de29..08810a9 100644
--- a/libatomic/config/linux/aarch64/host-config.h
+++ b/libatomic/config/linux/aarch64/host-config.h
@@ -0,0 +1,36 @@
+/* Copyright (C) 2017 Free Software Foundation, Inc.
+
+   This file is part of the GNU Atomic Library (libatomic).
+
+   Libatomic is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   Libatomic is distributed in the hope that it will be useful, but WITHOUT ANY
+   WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
+   FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+   more details.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+
+   You should have received a copy of the GNU General Public License and
+   a copy of the GCC Runtime Library Exception along with this program;
+   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+   .  */
+
+#if HAVE_IFUNC
+#include 
+
+# ifdef HWCAP_ATOMICS
+#  define IFUNC_COND_1	(hwcap & HWCAP_ATOMICS)
+# else
+#  define IFUNC_COND_1	(false)
+# endif
+# define IFUNC_NCOND(N)	(1)
+
+#endif /* HAVE_IFUNC */
+
+#include_next 
diff --git a/libatomic/configure.ac b/libatomic/configure.ac
index 023f172..b717d3d 100644
--- a/libatomic/configure.ac
+++ b/libatomic/configure.ac
@@ -163,6 +163,10 @@ if test -n "$UNSUPPORTED"; then
   AC_MSG_ERROR([Configuration ${target} is unsupported.])
 fi
 
+# Write out the ifunc resolver arg type.
+AC_DEFINE_UNQUOTED(IFUNC_RESOLVER_ARGS, $IFUNC_RESOLVER_ARGS,
+	[Define ifunc resolver function argument.])
+
 # Disable fallbacks to __sync routines from libgcc.  Otherwise we'll
 # make silly decisions about what the cpu can do.
 CFLAGS="$save_CFLAGS -fno-sync-libcalls $XCFLAGS"
@@ -247,6 +251,8 @@ AC_SUBST(LIBS)
 AC_SUBST(SIZES)
 
 AM_CONDITIONAL(HAVE_IFUNC, test x$libat_cv_have_ifunc = xyes)
+AM_CONDITIONAL(ARCH_AARCH64_LINUX,
+	   [expr "$config_path" : ".* linux/aarch64 .*" > /dev/null])
 AM_CONDITIONAL(ARCH_ARM_LINUX,
 	   [expr "$config_path" : ".* linux/arm .*" > /dev/null])
 AM_CONDITIONAL(ARCH_I386,
diff --git a/libatomic/configure.tgt b/libatomic/configure.tgt
index b8af3ab..388ae95 100644
--- a/libatomic/configure.tgt
+++ b/libatomic/configure.tgt
@@ -40,6 +40,14 @@ case "${target_cpu}" in
   riscv*)		ARCH=riscv ;;
   sh*)			ARCH=sh ;;
 
+  aarch64*)
+	ARCH=aarch64
+	case "${target}" in
+	aarch64*-*-linux*)
+		try_ifunc=yes
+		;;
+	esac
+	;;
   arm*)
 	ARCH=arm
 	case "${target}" in
@@ -109,6 +117,11 @@ fi
 
 # Other system configury
 case "${target}" in
+  aarch64*-*-linux*)
+	# OS support for atomic primitives.
+	config_path="${config_path} linux/aarch64 posix"
+	;;
+
   arm*-*-linux*)
 	# OS support for atomic primitives.
 	config_path="${config_path} linux/arm posix"
@@ -153,3 +166,14 @@ case "${target}" in
 	UNSUPPORTED=1
 	;;
 esac
+
+# glibc will pass hwcap to ifunc r

Re: Patch I have Formatted in Git

2017-09-29 Thread nick


On 2017-09-29 04:25 PM, Joseph Myers wrote:
> On Fri, 29 Sep 2017, nick wrote:
> 
>> -  error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s", reason);
>> +  error_at (EXPR_LOCATION (call_expr), "cannot tail-call: %s", N_(reason));
> 
> This can't be right.  N_ only makes sense around a string literal (e.g. in 
> a constant initializer); it marks a string for extraction for translation, 
> but does not cause it to be translated at runtime.  You need _() to cause 
> the translation at runtime (and then make sure that every string constant 
> that can end up as a value of reason is surrounded by N_() - or just 
> surround the string constants directly by _() if there isn't a reason that 
> won't work).
> 
Exactly what was commented on my another developer I agree should be _(reason) 
as this will need to be used at runtime. I am just building and running
the tests for it now.

Thanks,
Nick


Re: [PATCH], Add PowerPC ISA 3.0 IEEE 128-bit floating point round to odd built-in functions

2017-09-29 Thread Joseph Myers
On Fri, 29 Sep 2017, Segher Boessenkool wrote:

> How do other ports deal with this?  Insns with a specific rounding mode?
> Have a separate unspec for every operation?  Not very nice either :-(

Well, ideally you'd have a machine-independent representation of constant 
rounding modes that could be used with the TS 18661-1 FENV_ROUND pragma, 
respectively FENV_DEC_ROUND for decimal floating point (as the standard 
machine-independent way of accessing such a facility at the C language 
level - you'd then need to extend it to handle round-to-odd, but given the 
basic facility, accepting additional rounding mode names with it should be 
easy).  But I don't know what that would look like in either GIMPLE or 
RTL, and I'd certainly expect it to be a large project (quite likely 
depending on other large projects to handle dynamic rounding modes 
properly through optimizers).  So you probably can't do much better than 
lots of unspecs and machine-specific built-in functions at present.

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [PATCH], Add PowerPC ISA 3.0 IEEE 128-bit floating point round to odd built-in functions

2017-09-29 Thread Joseph Myers
On Fri, 29 Sep 2017, Joseph Myers wrote:

> On Fri, 29 Sep 2017, Segher Boessenkool wrote:
> 
> > How do other ports deal with this?  Insns with a specific rounding mode?
> > Have a separate unspec for every operation?  Not very nice either :-(
> 
> Well, ideally you'd have a machine-independent representation of constant 
> rounding modes that could be used with the TS 18661-1 FENV_ROUND pragma, 
> respectively FENV_DEC_ROUND for decimal floating point (as the standard 
> machine-independent way of accessing such a facility at the C language 
> level - you'd then need to extend it to handle round-to-odd, but given the 
> basic facility, accepting additional rounding mode names with it should be 
> easy).  But I don't know what that would look like in either GIMPLE or 
> RTL, and I'd certainly expect it to be a large project (quite likely 
> depending on other large projects to handle dynamic rounding modes 
> properly through optimizers).  So you probably can't do much better than 
> lots of unspecs and machine-specific built-in functions at present.

(But the answer to your question seems to be that AVX512 uses something 
involving UNSPEC_EMBEDDED_ROUNDING.)

-- 
Joseph S. Myers
jos...@codesourcery.com


[PATCH] Fix up handle_noipa_attribute

2017-09-29 Thread Jakub Jelinek
Hi!

I've noticed a bogus attribute (stack_protector) on a function with noipa
attribute.

The reason seems to be misapplied patch of mine, the 4 lines below were
actually from handle_stack_protect_attribute, but instead of moving those
there, I'd like to remove them because they make no sense to me.
When handle_*_attribute doesn't set *no_add_attrs, the attribute is added
by the caller, so there is no point in it adding it by hand.

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

2017-09-29  Jakub Jelinek  

* c-attribs.c (handle_noipa_attribute): Don't add "stack_protect"
attribute.

--- gcc/c-family/c-attribs.c.jj 2017-09-29 09:57:12.0 +0200
+++ gcc/c-family/c-attribs.c2017-09-29 14:17:11.014438213 +0200
@@ -730,10 +730,6 @@ handle_noipa_attribute (tree *node, tree
   warning (OPT_Wattributes, "%qE attribute ignored", name);
   *no_add_attrs = true;
 }
-  else
-DECL_ATTRIBUTES (*node)
-  = tree_cons (get_identifier ("stack_protect"),
-  NULL_TREE, DECL_ATTRIBUTES (*node));
 
   return NULL_TREE;
 }

Jakub


Re: [PATCH] Fix up handle_noipa_attribute

2017-09-29 Thread Joseph Myers
On Fri, 29 Sep 2017, Jakub Jelinek wrote:

> Hi!
> 
> I've noticed a bogus attribute (stack_protector) on a function with noipa
> attribute.
> 
> The reason seems to be misapplied patch of mine, the 4 lines below were
> actually from handle_stack_protect_attribute, but instead of moving those
> there, I'd like to remove them because they make no sense to me.
> When handle_*_attribute doesn't set *no_add_attrs, the attribute is added
> by the caller, so there is no point in it adding it by hand.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com


[C++ PATCH] With -Wuseless-cast on direct enum init (PR c++/82299)

2017-09-29 Thread Jakub Jelinek
Hi!

The casts added for the C++17 direct enum initialization IMNSHO shouldn't
trigger -Wuseless-cast warnings.

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

2017-09-29  Jakub Jelinek  

PR c++/82299
* decl.c (reshape_init): Suppress warn_useless_cast for direct enum
init.
* typeck.c (convert_for_assignment): Likewise.

* g++.dg/cpp0x/pr82299.C: New test.

--- gcc/cp/decl.c.jj2017-09-29 11:21:55.0 +0200
+++ gcc/cp/decl.c   2017-09-29 15:19:02.549548102 +0200
@@ -6053,7 +6053,10 @@ reshape_init (tree type, tree init, tsub
   tree elt = CONSTRUCTOR_ELT (init, 0)->value;
   type = cv_unqualified (type);
   if (check_narrowing (ENUM_UNDERLYING_TYPE (type), elt, complain))
-   return cp_build_c_cast (type, elt, tf_warning_or_error);
+   {
+ warning_sentinel w (warn_useless_cast);
+ return cp_build_c_cast (type, elt, tf_warning_or_error);
+   }
   else
return error_mark_node;
 }
--- gcc/cp/typeck.c.jj  2017-09-29 09:07:33.0 +0200
+++ gcc/cp/typeck.c 2017-09-29 15:21:17.770926572 +0200
@@ -8527,7 +8527,10 @@ convert_for_assignment (tree type, tree
 {
   tree elt = CONSTRUCTOR_ELT (rhs, 0)->value;
   if (check_narrowing (ENUM_UNDERLYING_TYPE (type), elt, complain))
-   rhs = cp_build_c_cast (type, elt, complain);
+   {
+ warning_sentinel w (warn_useless_cast);
+ rhs = cp_build_c_cast (type, elt, complain);
+   }
   else
rhs = error_mark_node;
 }
--- gcc/testsuite/g++.dg/cpp0x/pr82299.C.jj 2017-09-29 15:24:18.909754416 
+0200
+++ gcc/testsuite/g++.dg/cpp0x/pr82299.C2017-09-29 15:29:15.589237065 
+0200
@@ -0,0 +1,9 @@
+// PR c++/82299
+// { dg-do compile { target c++11 } }
+// { dg-options "-Wuseless-cast" }
+
+enum Enum : char { A = 0, B = 1 };
+
+struct S {
+  Enum e { Enum::A };  // { dg-bogus "useless cast to type" }
+};

Jakub


[PATCH] Fix REG_EQUAL note in x86 -m8bit-idiv code

2017-09-29 Thread Jakub Jelinek
Hi!

While working on the following patch, I've discovered that the REG_EQUAL
notes for DImode signed/unsigned division/modulo are wrong, there is
e.g. (div:SI (reg:DI ...) (reg:DI ...)).

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

2017-09-29  Jakub Jelinek  

* config/i386/i386.c (ix86_split_idivmod): Use mode instead of
always SImode for DIV and MOD in REG_EQUAL notes.

--- gcc/config/i386/i386.c.jj   2017-09-28 20:35:14.0 +0200
+++ gcc/config/i386/i386.c  2017-09-29 19:15:27.822267844 +0200
@@ -21980,13 +21980,13 @@ ix86_split_idivmod (machine_mode mode, r
 
   if (signed_p)
 {
-  div = gen_rtx_DIV (SImode, operands[2], operands[3]);
-  mod = gen_rtx_MOD (SImode, operands[2], operands[3]);
+  div = gen_rtx_DIV (mode, operands[2], operands[3]);
+  mod = gen_rtx_MOD (mode, operands[2], operands[3]);
 }
   else
 {
-  div = gen_rtx_UDIV (SImode, operands[2], operands[3]);
-  mod = gen_rtx_UMOD (SImode, operands[2], operands[3]);
+  div = gen_rtx_UDIV (mode, operands[2], operands[3]);
+  mod = gen_rtx_UMOD (mode, operands[2], operands[3]);
 }
 
   /* Extract remainder from AH.  */

Jakub


[PATCH] Improve x86-64 32-bit div/mod followed by zero-extension to 64-bit (PR target/82361)

2017-09-29 Thread Jakub Jelinek
Hi!

The following patch adds patterns and splitters for {,u}divmodsi4 followed
by zero-extension, similarly to other 32-bit operand instructions divl and
idivl zero extends both results to 64-bit, so there is no need to extend it
again.  The REE pass ignores instructions that have more than one SET, but
at least the combiner doesn't.  The patch adds both patterns/splitters that
zero extend the quotient and patterns/splttiers that zero extend the modulo
(the combiner wants in that case the modulo to be the first operation).
I have a patch which I'll attach to the PR, which also has patterns for
both results zero extended, but as neither combiner nor anything else is
able to match them right now, I'm not including it here.

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

2017-09-29  Jakub Jelinek  

PR target/82361
* config/i386/i386.md
(TARGET_USE_8BIT_IDIV zext divmodsi4 splitter): New define_split.
(divmodsi4_zext_1, divmodsi4_zext_2, *divmodsi4_zext_1,
*divmodsi4_zext_2): New define_insn_and_split.
(*divmodsi4_noext_zext_1, *divmodsi4_noext_zext_2): New define_insn.
(TARGET_USE_8BIT_IDIV zext udivmodsi4 splitter): New define_split.
(udivmodsi4_zext_1, udivmodsi4_zext_2, *udivmodsi4_zext_1,
*udivmodsi4_zext_2, *udivmodsi4_pow2_zext_1, *udivmodsi4_pow2_zext_2):
New define_insn_and_split.
(*udivmodsi4_noext_zext_1, *udivmodsi4_noext_zext_2): New define_insn.
* config/i386/i386.c (ix86_split_idivmod): Handle operands[0] or
operands[1] having DImode when mode is SImode.

* gcc.target/i386/pr82361-1.c: New test.
* gcc.target/i386/pr82361-2.c: New test.

--- gcc/config/i386/i386.md.jj  2017-09-29 09:19:42.0 +0200
+++ gcc/config/i386/i386.md 2017-09-29 19:19:34.795293575 +0200
@@ -7635,6 +7635,36 @@ (define_split
   [(const_int 0)]
   "ix86_split_idivmod (mode, operands, true); DONE;")
 
+(define_split
+  [(set (match_operand:DI 0 "register_operand")
+   (zero_extend:DI
+ (div:SI (match_operand:SI 2 "register_operand")
+ (match_operand:SI 3 "nonimmediate_operand"
+   (set (match_operand:SI 1 "register_operand")
+   (mod:SI (match_dup 2) (match_dup 3)))
+   (clobber (reg:CC FLAGS_REG))]
+  "TARGET_USE_8BIT_IDIV
+   && TARGET_QIMODE_MATH
+   && can_create_pseudo_p ()
+   && !optimize_insn_for_size_p ()"
+  [(const_int 0)]
+  "ix86_split_idivmod (SImode, operands, true); DONE;")
+
+(define_split
+  [(set (match_operand:DI 1 "register_operand")
+   (zero_extend:DI
+ (mod:SI (match_operand:SI 2 "register_operand")
+ (match_operand:SI 3 "nonimmediate_operand"
+   (set (match_operand:SI 0 "register_operand")
+   (div:SI  (match_dup 2) (match_dup 3)))
+   (clobber (reg:CC FLAGS_REG))]
+  "TARGET_USE_8BIT_IDIV
+   && TARGET_QIMODE_MATH
+   && can_create_pseudo_p ()
+   && !optimize_insn_for_size_p ()"
+  [(const_int 0)]
+  "ix86_split_idivmod (SImode, operands, true); DONE;")
+
 (define_insn_and_split "divmod4_1"
   [(set (match_operand:SWI48 0 "register_operand" "=a")
(div:SWI48 (match_operand:SWI48 2 "register_operand" "0")
@@ -7670,6 +7700,79 @@ (define_insn_and_split "divmod4_1"
   [(set_attr "type" "multi")
(set_attr "mode" "")])
 
+(define_insn_and_split "divmodsi4_zext_1"
+  [(set (match_operand:DI 0 "register_operand" "=a")
+   (zero_extend:DI
+ (div:SI (match_operand:SI 2 "register_operand" "0")
+ (match_operand:SI 3 "nonimmediate_operand" "rm"
+   (set (match_operand:SI 1 "register_operand" "=&d")
+   (mod:SI (match_dup 2) (match_dup 3)))
+   (unspec [(const_int 0)] UNSPEC_DIV_ALREADY_SPLIT)
+   (clobber (reg:CC FLAGS_REG))]
+  "TARGET_64BIT"
+  "#"
+  "reload_completed"
+  [(parallel [(set (match_dup 1)
+  (ashiftrt:SI (match_dup 4) (match_dup 5)))
+ (clobber (reg:CC FLAGS_REG))])
+   (parallel [(set (match_dup 0)
+  (zero_extend:DI (div:SI (match_dup 2) (match_dup 3
+ (set (match_dup 1)
+  (mod:SI (match_dup 2) (match_dup 3)))
+ (use (match_dup 1))
+ (clobber (reg:CC FLAGS_REG))])]
+{
+  operands[5] = GEN_INT (GET_MODE_BITSIZE (SImode)-1);
+
+  if (optimize_function_for_size_p (cfun) || TARGET_USE_CLTD)
+operands[4] = operands[2];
+  else
+{
+  /* Avoid use of cltd in favor of a mov+shift.  */
+  emit_move_insn (operands[1], operands[2]);
+  operands[4] = operands[1];
+}
+}
+  [(set_attr "type" "multi")
+   (set_attr "mode" "SI")])
+
+(define_insn_and_split "divmodsi4_zext_2"
+  [(set (match_operand:DI 1 "register_operand" "=&d")
+   (zero_extend:DI
+ (mod:SI (match_operand:SI 2 "register_operand" "0")
+ (match_operand:SI 3 "nonimmediate_operand" "rm"
+   (set (match_operand:SI 0 "register_operand" "=a")
+   (div:SI (match_dup 2) (match_dup 3)))
+   (unspec [(const_int 0)] UNSPEC_DI

Re: isl scheduler and spatial locality (Re: [PATCH][GRAPHITE] More TLC)

2017-09-29 Thread Oleksandr Zinenko



On 29/09/17 21:58, Sebastian Pop wrote:

On Fri, Sep 29, 2017 at 2:37 PM, Sven Verdoolaege
 wrote:

[Sorry for the resend; I used the wrong email address to CC Alex]

On Wed, Sep 27, 2017 at 02:18:51PM +0200, Richard Biener wrote:

Ah, so I now see why we do not perform interchange on trivial cases like

double A[1024][1024], B[1024][1024];

void foo(void)
{
   for (int i = 0; i < 1024; ++i)
 for (int j = 0; j < 1024; ++j)
   A[j][i] = B[j][i];
}

I didn't see you mentioning _why_ you expect an interchange here.
Are you prehaps interested in spatial locality?
If so, then there are several approaches for taking
that into account.
- pluto performs an intra-tile loop interchange to
   improve temporal and/or spatial locality.  It shouldn't
   be too hard to do something similar on an isl generated
   schedule
- Alex (Oleksandr) has been working on an extension of
   the isl scheduler that takes into account spatial locality.
   I'm not sure if it's publicly available.
- I've been working on a special case of spatial locality
   (consecutivity).  The current version is available in
   the consecutivity branch.  Note that it may get rebased and
   it may not necessarily get merged into master.

There are also other approaches, but they may not be that
easy to combine with the isl scheduler.

Would the following work?
Add to the proximity relation the array accesses from two
successive iterations of the innermost loop:
A[j][i] -> A[j][i+1] and B[j][i] -> B[j][i+1]
With these two extra relations in the proximity map,
isl should be able to interchange the above loop.

Sebastian

Hi,

this looks very close to what we do for spatial locality in the 
scheduler, except that we separate proximity and "spatial proximity" 
maps.  There is a couple of caveats in just plugging those into 
proximity, in particular resolving conflicts between spatial and 
temporal locality and unnecessary skewing.


Cheers,
Alex

--
Oleksandr Zinenko,
Inria / École Normale Supérieure,
cont...@ozinenko.com, oleksandr.zine...@inria.fr
https://www.ozinenko.com



[PING^2][PATCH][compare-elim] Merge zero-comparisons with normal ops

2017-09-29 Thread Michael Collison
Ping ^ 2. Updated patch posted here:

https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00390.html



[PING][PATCH] [Aarch64] Optimize subtract in shift counts

2017-09-29 Thread Michael Collison
Ping. Updated patch posted here:

https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00964.htm
l


[PING][PATCH][Aarch64] Improve int<->FP conversions

2017-09-29 Thread Michael Collison
Ping. Original patch posted here:

https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00808.html





Re: [PATCH, rs6000] Follow-on fix for PR target/80210: ICE in extract_insn

2017-09-29 Thread Segher Boessenkool
Hi Peter,

On Thu, Sep 28, 2017 at 09:26:00PM -0500, Peter Bergner wrote:
> This patch fixes two new issues exposed (but not caused) by the original 
> test case added for PR80210 as well as a modified version of that test case.

[ .. snip ... ]

This all seems correct (but it is so complex that it is hard to be sure;
well it is _less_ complex now!)

> +   /* PowerPC 64-bit LE requires at least ISA 2.07.  */
> +   const char *default_cpu = ((!TARGET_POWERPC64)
> +  ? "powerpc"
> +  : ((BYTES_BIG_ENDIAN)
> + ? "powerpc64"
> + : "powerpc64le"));

Please remove the parens around !TARGET_POWERPC64 and BYTES_BIG_ENDIAN
while you're at it (one of the copies you removed had that already :-) )

Looks great to me, please commit.  But hold off until Monday please, it
will interfere with testing otherwise.

Thanks!


Segher


Re: [PATCH,rs6000] Correct dejagnu directives in several newly added tests

2017-09-29 Thread Segher Boessenkool
Hi Kelvin,

>   * gcc.target/powerpc/swaps-p8-30.c: Exchange the order of dg-do
>   and dg-require-effective-target directives to correct testing
>   behavior.
>   * gcc.target/powerpc/swaps-p8-32.c: Likewise.
>   * gcc.target/powerpc/swaps-p8-41.c: Likewise.
>   * gcc.target/powerpc/swaps-p8-34.c: Likewise.
>   * gcc.target/powerpc/swaps-p8-43.c: Likewise.
>   * gcc.target/powerpc/swaps-p8-36.c: Likewise.
>   * gcc.target/powerpc/swaps-p8-45.c: Likewise.
>   * gcc.target/powerpc/swaps-p8-29.c: Likewise.
>   * gcc.target/powerpc/swaps-p8-38.c: Likewise.
>   * gcc.target/powerpc/swaps-p8-31.c: Likewise.
>   * gcc.target/powerpc/swaps-p8-40.c: Likewise.
>   * gcc.target/powerpc/swaps-p8-33.c: Likewise.
>   * gcc.target/powerpc/swaps-p8-42.c: Likewise.
>   * gcc.target/powerpc/swaps-p8-35.c: Likewise.
>   * gcc.target/powerpc/swaps-p8-44.c: Likewise.
>   * gcc.target/powerpc/swaps-p8-28.c: Likewise.
>   * gcc.target/powerpc/swaps-p8-37.c: Likewise.
>   * gcc.target/powerpc/swaps-p8-39.c: Likewise.

In cases like this, please sort the entries :-)

(I've fixed it, nothing more to do).

Thanks for the patch,


Segher


Re: [PING][PATCH][Aarch64] Improve int<->FP conversions

2017-09-29 Thread James Greenhalgh
On Fri, Sep 29, 2017 at 10:42:14PM +0100, Michael Collison wrote:
> Ping. Original patch posted here:
> 
> https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00808.html

I don't see a patch attached there to review, nor can I see an earlier mail
threaded to it with the patch attached. Can you help?

Thanks,
James



Re: [PATCH] [Aarch64] Optimize subtract in shift counts

2017-09-29 Thread James Greenhalgh
On Fri, Sep 15, 2017 at 09:15:17AM +0100, Michael Collison wrote:
> Patch updated with comments to simplify pattern .from Richard Sandiford. Okay 
> for trunk?

OK.

Thanks,
James

> 
> 2017-09-14  Michael Collison 
> 
>   * config/aarch64/aarch64.md (*aarch64_reg__minus3):
>   New pattern.
> 
> 2017-09-14  Michael Collison 
> 
>   * gcc.target/aarch64/var_shift_mask_2.c: New test.
> 
> Richard Sandiford  writes:
> > Richard Sandiford  writes:
> >> Michael Collison  writes:
> >>> Richard,
> >>>
> >>> The problem with this approach for Aarch64 is that 
> >>> TARGET_SHIFT_TRUNCATION_MASK is based on SHIFT_COUNT_TRUNCATED which 
> >>> is normally 0 as it based on the TARGET_SIMD flag.
> >>
> >> Maybe I'm wrong, but that seems like a missed optimisation in itself.
> 
> Sorry to follow up on myself yet again, but I'd forgotten this was because we 
> allow the SIMD unit to do scalar shifts.  So I guess we have no choice, even 
> though it seems unfortunate.
> 
> > +(define_insn_and_split "*aarch64_reg__minus3"
> > +  [(set (match_operand:GPI 0 "register_operand" "=&r")
> > +   (ASHIFT:GPI
> > + (match_operand:GPI 1 "register_operand" "r")
> > + (minus:QI (match_operand 2 "const_int_operand" "n")
> > +   (match_operand:QI 3 "register_operand" "r"]
> > +  "INTVAL (operands[2]) == GET_MODE_BITSIZE (mode)"
> > +  "#"
> > +  "&& true"
> > +  [(const_int 0)]
> > +  {
> > +/* Handle cases where operand 3 is a plain QI register, or
> > +   a subreg with either a SImode or DImode register.  */
> > +
> > +rtx subreg_tmp = (REG_P (operands[3])
> > + ? gen_lowpart_SUBREG (SImode, operands[3])
> > + : SUBREG_REG (operands[3]));
> > +
> > +if (REG_P (subreg_tmp) && GET_MODE (subreg_tmp) == DImode)
> > +  subreg_tmp = gen_lowpart_SUBREG (SImode, subreg_tmp);
> 
> I think this all simplifies to:
> 
>   rtx subreg_tmp = gen_lowpart (SImode, operands[3]);
> 
> (or it would be worth having a comment that explains why not).
> As well as being shorter, it will properly simplify hard REGs to new hard 
> REGs.
> 
> > +rtx tmp = (can_create_pseudo_p () ? gen_reg_rtx (SImode)
> > +  : operands[0]);
> > +
> > +if (mode == DImode && !can_create_pseudo_p ())
> > +  tmp = gen_lowpart_SUBREG (SImode, operands[0]);
> 
> I think this too would be simpler with gen_lowpart:
> 
> rtx tmp = (can_create_pseudo_p () ? gen_reg_rtx (SImode)
>  : gen_lowpart (SImode, operands[0]));
> 
> > +
> > +emit_insn (gen_negsi2 (tmp, subreg_tmp));
> > +
> > +rtx and_op = gen_rtx_AND (SImode, tmp,
> > + GEN_INT (GET_MODE_BITSIZE (mode) - 1));
> > +
> > +rtx subreg_tmp2 = gen_lowpart_SUBREG (QImode, and_op);
> > +
> > +emit_insn (gen_3 (operands[0], operands[1], subreg_tmp2));
> > +DONE;
> > +  }
> > +)
> 
> The pattern should probably set the "length" attribute to 8.
> 
> Looks good to me with those changes FWIW.
> 
> Thanks,
> Richard