Re: Re: [Patch ARM-AArch64/testsuite Neon intrinsics 00/20] Executable tests

[Christophe Lyon]

On 2 November 2015 at 15:20, Jiong Wang  wrote:
> On 27 May 2015 at 22:15, Christophe Lyon  wrote:
>>>
>>>  * gcc.target/aarch64/advsimd-intrinsics/vtbX.c: Likewise.
>>>
>
> Noticed this testcase failed on big-endian on my local test
>
>   gcc.target/aarch64/advsimd-intrinsics/vtbX.c line 188 in buffer
> 'expected_vtbl3') at type int8x8 index 0: got 0x0 != 0xfff8
>
which version of trunk are you using?

This with the case indeed when I committed the tests, but I fixed
those intrinsics a few weeks ago,
as commit 228716.

[c++-delayed-folding] Introduce convert_to_complex_nofold

[Marek Polacek]

The following introduces convert_to_complex_nofold, similarly to what
I've done with convert_to_pointer.  Nothing too surprising in the patch,
I suppose.

Now, what remains to do is to also introduce convert_to_real.  Then we
should be done with convert.c as convert_to_vector doesn't fold and
convert_to_fixed isn't used in the C++ FE at all.  More tomorrow.

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

diff --git gcc/convert.c gcc/convert.c
index ab3eb20..ec6ff37 100644
--- gcc/convert.c
+++ gcc/convert.c
@@ -40,6 +40,9 @@ along with GCC; see the file COPYING3.  If not see
 #define maybe_fold_build1_loc(FOLD_P, LOC, CODE, TYPE, EXPR) \
   ((FOLD_P) ? fold_build1_loc (LOC, CODE, TYPE, EXPR)   \
: build1_loc (LOC, CODE, TYPE, EXPR))
+#define maybe_fold_build2_loc(FOLD_P, LOC, CODE, TYPE, EXPR1, EXPR2) \
+  ((FOLD_P) ? fold_build2_loc (LOC, CODE, TYPE, EXPR1, EXPR2)   \
+   : build2_loc (LOC, CODE, TYPE, EXPR1, EXPR2))
 
 /* Convert EXPR to some pointer or reference type TYPE.
EXPR must be pointer, reference, integer, enumeral, or literal zero;
@@ -968,11 +971,13 @@ convert_to_integer_nofold (tree type, tree expr)
   return convert_to_integer_1 (type, expr, CONSTANT_CLASS_P (expr));
 }
 
-/* Convert EXPR to the complex type TYPE in the usual ways.  */
+/* Convert EXPR to the complex type TYPE in the usual ways.  If FOLD_P is
+   true, try to fold the expression.  */
 
-tree
-convert_to_complex (tree type, tree expr)
+static tree
+convert_to_complex_1 (tree type, tree expr, bool fold_p)
 {
+  location_t loc = EXPR_LOCATION (expr);
   tree subtype = TREE_TYPE (type);
 
   switch (TREE_CODE (TREE_TYPE (expr)))
@@ -993,43 +998,63 @@ convert_to_complex (tree type, tree expr)
  return expr;
else if (TREE_CODE (expr) == COMPOUND_EXPR)
  {
-   tree t = convert_to_complex (type, TREE_OPERAND (expr, 1));
+   tree t = convert_to_complex_1 (type, TREE_OPERAND (expr, 1),
+  fold_p);
if (t == TREE_OPERAND (expr, 1))
  return expr;
return build2_loc (EXPR_LOCATION (expr), COMPOUND_EXPR,
   TREE_TYPE (t), TREE_OPERAND (expr, 0), t);
- }
+ }
else if (TREE_CODE (expr) == COMPLEX_EXPR)
- return fold_build2 (COMPLEX_EXPR, type,
- convert (subtype, TREE_OPERAND (expr, 0)),
- convert (subtype, TREE_OPERAND (expr, 1)));
+ return maybe_fold_build2_loc (fold_p, loc, COMPLEX_EXPR, type,
+   convert (subtype,
+TREE_OPERAND (expr, 0)),
+   convert (subtype,
+TREE_OPERAND (expr, 1)));
else
  {
expr = save_expr (expr);
-   return
- fold_build2 (COMPLEX_EXPR, type,
-  convert (subtype,
-   fold_build1 (REALPART_EXPR,
-TREE_TYPE (TREE_TYPE (expr)),
-expr)),
-  convert (subtype,
-   fold_build1 (IMAGPART_EXPR,
-TREE_TYPE (TREE_TYPE (expr)),
-expr)));
+   tree realp = maybe_fold_build1_loc (fold_p, loc, REALPART_EXPR,
+   TREE_TYPE (TREE_TYPE (expr)),
+   expr);
+   tree imagp = maybe_fold_build1_loc (fold_p, loc, IMAGPART_EXPR,
+   TREE_TYPE (TREE_TYPE (expr)),
+   expr);
+   return maybe_fold_build2_loc (fold_p, loc, COMPLEX_EXPR, type,
+ convert (subtype, realp),
+ convert (subtype, imagp));
  }
   }
 
 case POINTER_TYPE:
 case REFERENCE_TYPE:
   error ("pointer value used where a complex was expected");
-  return convert_to_complex (type, integer_zero_node);
+  return convert_to_complex_1 (type, integer_zero_node, fold_p);
 
 default:
   error ("aggregate value used where a complex was expected");
-  return convert_to_complex (type, integer_zero_node);
+  return convert_to_complex_1 (type, integer_zero_node, fold_p);
 }
 }
 
+/* A wrapper around convert_to_complex_1 that always folds the
+   expression.  */
+
+tree
+convert_to_complex (tree type, tree expr)
+{
+  return convert_to_complex_1 (type, expr, true);
+}
+
+/* A wrapper around convert_to_complex_1 that only folds the
+   expression if it is CONSTANT_CLASS_P.  */
+
+tree
+convert_to_complex_nofold (tree type, tree expr)
+{
+  return convert_to_complex_1 (type, expr, 

Re: [v3 PATCH] Make the default constructors of tuple and pair conditionally explicit.

[Paolo Carlini]

Hi Ville,

On 11/01/2015 04:27 AM, Ville Voutilainen wrote:

In the last meeting, while processing LWG 2510, LWG's guidance
was to make the default constructors of pair and tuple conditionally
explicit. This patch implements a new trait and uses it in pair and tuple.

Paolo, Jonathan is traveling and somewhat unlikely to be able to review
this for quite some time, could you please review this patch?
Sure, Jonathan told me a few weeks ago. Note anyway that I would not 
expect major issues with committing this kind of patch even after the 
end of Stage 1...


Anyway, so far the only detail which makes me a little nervous is the 
following:


+  template 
+struct __is_implicitly_default_constructible
+  : public integral_constant::value
+&& __is_implicitly_default_constructible_safe<_Tp>::value)>


I think we want to use __and_ (note that there isn't a single logical && 
in the whole type_traits, outside macros).


Paolo.

Re: [PATCH, 3/6] Add recursion to make_param_constraints

[Richard Biener]

On Sun, 1 Nov 2015, Tom de Vries wrote:

> On 01/11/15 19:03, Tom de Vries wrote:
> > 
> > So, the new patch series is:
> > 
> >   1Rename make_restrict_var_constraints to make_param_constraints
> >   2Handle recursive restrict in function parameter
> > 
> > I'll repost in reply to this message.
> 
> This no-functional-changes patch:
> - moves the one constraint handling loop left in
>intra_create_variable_infos to make_restrict_var_constraints
> - renames make_restrict_var_constraints to make_param_constraints
> - adds a parameter toplevel to make_param_constraints to distinguish
>between the two calling contexts
> - adds a parmeter restrict_name that allows to pass in the name of
>   restrict vars
> 
> This patch was posted before at
> https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03111.html .

+ if (toplevel)
+   make_constraint_from (vi, nonlocal_id);
+ else
+   make_copy_constraint (vi, nonlocal_id);

I think make_constraint_from is what we want in both cases.

Ok with this change (thus drop the toplevel parameter).

Richard.

Re: [RFC, PATCH v2] Disable -fprofile-use related optimizations if corresponding .gcda file not found.

[Richard Biener]

On Tue, Oct 27, 2015 at 10:14 AM, Maxim Ostapenko
 wrote:
> Hi!
>
> As was pointed out in previous thread
> (https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00723.html), sometimes
> PGO-built binaries can actually introduce performance regressions. We could
> identify affected object files and disable PGO for them by simply removing
> corresponding .gcda file.

Did you analyze where the performance regressions came from?

> My previous patch was incomplete and had two major drawbacks:
>
> * It disabled unrelated options (e.g. -frename-registers) and PGO-related
> options, set up by user explicitly, if corresponding .gcda file is not
> found.
> * As Markus pointed out, in many cases we actually don't want to disable
> PGO-related options even if .gcda file is missing.
>
> This patch tries to solve these issues in the following way:
>
> * Introduce new -fprofile-use-partial switch.
> * If -fprofile-use-partial is ON, try to find corresponding .gcda file in
> the very early stage during compiler invoking (actually, when common command
> line options are parsed). If .gcda file exists, enable PGO-related
> optimizations and emit warning otherwise. I believe this should not break
> existing code.
>
> Regtested and bootstrapped on x86_64-unknown-linux-gnu.
>
> Does the patch look sensible?

It still somehow feels like a hack.

I think it should operate on a function granularity and the user
should be able to specify
a fallback to use (do we actually guess the profile if it fails to
read?  what if the profile
is missing just for some functions, like if the gcda file is older
than sources?).

Which means that we should be able to somehow "late" disable some options
from inside the IPA tree-profile pass.  In principle we have
DECL_FUNCTION_SPECIFIC_OPTIMIZATION
nodes on each function so disabling of flags should be possible (but
we've lost whether
they were the default or user-controlled at that point).

Honza, any further ideas here?

Thanks,
Richard.

> Thanks,
> -Maxim

Re: [PATCH 3/4] bb-reorder: Add -freorder-blocks-algorithm= and wire it up

[Alan Lawrence]

On 02/11/15 14:38, Alan Lawrence wrote:
>

I'm a bit puzzled as to why nobody else has been seeing this, as it's been
happening to me as part of building gcc on x86_64, but since this patch I've
been seeing an ICE in vec::operator[] in reorder_basic_blocks_simple, building
libitm/beginend.cc. Preprocessed source attached


OK, so I realize now just how big that preprocessed source was (1.4MB) - 
apologies! I've filed PR/68182 with a .gz for now

Re: [PATCH] PR fortran/68151 -- Check CASE selector for valid type

[Steve Kargl]

On Mon, Nov 02, 2015 at 12:33:25PM +0100, Mikael Morin wrote:
> 
> Le 01/11/2015 22:16, Steve Kargl a écrit :
> > The attach patch add checking for a valid type during
> > matching of a CASE selector.  Built and regression
> > tested on i386-*-freebsd.  OK to commit?
> 
> [...]
> 
> > Index: gcc/fortran/match.c
> > ===
> > --- gcc/fortran/match.c (revision 229634)
> > +++ gcc/fortran/match.c (working copy)
> > @@ -5036,6 +5036,15 @@ match_case_selector (gfc_case **cp)
> > goto need_expr;
> >if (m == MATCH_ERROR)
> > goto cleanup;
> > +
> > +  /* F08:C830 case-expr shall be of type character, integer, or 
> > logical.  */
> case-expr is the expression appearing in a SELECT CASE statement (k in 
> the test), while here the problem is in a CASE statement, dealing with 
> value-expr's.
> So I think C830 doesn't apply here.  But you can rely on F08:C832 saying:
>"For a given case-construct, each case-value shall be of the same 
> type as case-expr"
> The type of case-expr is only checked in resolve_select, so the check 
> for the value-expr's should probably happen there as well.
> 

Thanks for the correction.  I'll update the comment
and check to see if F08:C832 is enforced

-- 
Steve

Re: [Patch ARM-AArch64/testsuite Neon intrinsics 00/20] Executable tests

[Jiong Wang]

On 02/11/15 14:38, Christophe Lyon wrote:

On 2 November 2015 at 15:20, Jiong Wang  wrote:

On 27 May 2015 at 22:15, Christophe Lyon  wrote:

  * gcc.target/aarch64/advsimd-intrinsics/vtbX.c: Likewise.


Noticed this testcase failed on big-endian on my local test

   gcc.target/aarch64/advsimd-intrinsics/vtbX.c line 188 in buffer
'expected_vtbl3') at type int8x8 index 0: got 0x0 != 0xfff8


which version of trunk are you using?

This with the case indeed when I committed the tests, but I fixed
those intrinsics a few weeks ago,
as commit 228716.

Um... I forget to update my big-endian test tree, sorry for the noise.

commit 7d1cd01c170b4730d05c1b8137d818415ae31cd8
Author: spop 
Date:   Wed Oct 7 16:19:09 2015 +

Re: libgo patch committed: Update to Go 1.5 release

[Lynn A. Boger]

I see this error when building gccgo from trunk on ppc64le and running 
the libgo tests:


exec_unix_test.go:174:43: error: reference to undefined identifier 
'syscall.TIOCGPGRP'
  errno := syscall.Ioctl(tty.Fd(), syscall.TIOCGPGRP, 
uintptr(unsafe.Pointer()))

   ^
FAIL: syscall
make[3]: *** [syscall/check] Error 1


On 11/02/2015 03:37 AM, Andreas Schwab wrote:

Ian Lance Taylor  writes:


On Sun, Nov 1, 2015 at 1:39 AM, Andreas Schwab  wrote:

../../../../libgo/go/syscall/exec_linux.go:185:37: error: reference to 
undefined name 'TIOCSPGRP'
_, err1 = raw_ioctl_ptr(sys.Ctty, TIOCSPGRP, unsafe.Pointer())
  ^

$ grep TIOCSPGRP gen-sysinfo.go
// unknowndefine TIOCSPGRP _IOW('t', 118, int)

I have committed this patch which may fix the problem.  Let me know if
it still happens for you.  Thanks.

../../../../libgo/go/syscall/exec_linux.go:185:37: error: integer constant 
overflow
_, err1 = raw_ioctl_ptr(sys.Ctty, TIOCSPGRP, unsafe.Pointer())

// unknowndefine TIOCSPGRP _IOW('t', 118, int)
const _TIOCSPGRP_val = 2147775606

Andreas.

Re: Try to update dominance info in tree-call-cdce.c

[Richard Sandiford]

Steven Bosscher  writes:
> On Fri, Oct 30, 2015 at 2:11 PM, Richard Sandiford
>  wrote:
>> Is the split_block change really so bad?
>
> IMHO: Yes.

Fair enough :-)

> split_block just splits some basic block B into two blocks B1/B2
> somewhere in the middle of B. The dominance relations between B1 and
> B2 are obvious and intuitive. The new flag to split_block is not. The
> dominance info is not updated but the loops are? Confusing, if you ask
> me...
>
> Your situation, where a pass knows the dominance relations will
> change, is unusual. The extra work to fix up the ET tree twice should
> be negligible anyway.

I just thought that the cfg was in practice never going to stay in the
state that it is on return from split_block.  The caller is bound to
add (at least) another edge somewhere.

Here's a version that works with split_block rather than against it.
Tested on x86_64-linux-gnu, arm-linux-gnueabi and aarch64-linux-gnu.
OK to install?

Thanks,
Richard


gcc/
* tree-call-cdce.c (shrink_wrap_one_built_in_call): Try to update
the dominance info; free it if we can't.
(pass_call_cdce::execute): Don't free the dominance info here.

diff --git a/gcc/tree-call-cdce.c b/gcc/tree-call-cdce.c
index ffc1c4e..a5f38ce 100644
--- a/gcc/tree-call-cdce.c
+++ b/gcc/tree-call-cdce.c
@@ -731,6 +731,32 @@ shrink_wrap_one_built_in_call (gcall *bi_call)
   if (nconds == 0)
 return false;
 
+  /* The cfg we want to create looks like this:
+
+  [guard n-1] <- guard_bb (old block)
+|\
+| [guard n-2]   }
+|/ \}
+|   /  ...  } new blocks
+|  /  [guard 0] }
+| //   |}
+   [ call ]| <- bi_call_bb  }
+| \|
+|  \   |
+|   [ join ] <- join_tgt_bb (old iff call must end bb)
+|
+possible EH edges (only if [join] is old)
+
+ When [join] is new, the immediate dominators for these blocks are:
+
+ 1. [guard n-1]: unchanged
+ 2. [call]: [guard n-1]
+ 3. [guard m]: [guard m+1] for 0 <= m <= n-2
+ 4. [join]: [guard n-1]
+
+ We punt for the more complex case case of [join] being old and
+ simply free the dominance info.  We also punt on postdominators,
+ which aren't expected to be available at this point anyway.  */
   bi_call_bb = gimple_bb (bi_call);
 
   /* Now find the join target bb -- split bi_call_bb if needed.  */
@@ -741,6 +767,7 @@ shrink_wrap_one_built_in_call (gcall *bi_call)
   join_tgt_in_edge_from_call = find_fallthru_edge (bi_call_bb->succs);
   if (join_tgt_in_edge_from_call == NULL)
 return false;
+  free_dominance_info (CDI_DOMINATORS);
 }
   else
 join_tgt_in_edge_from_call = split_block (bi_call_bb, bi_call);
@@ -820,6 +847,15 @@ shrink_wrap_one_built_in_call (gcall *bi_call)
   guard_bb_in_edge->count = guard_bb->count - bi_call_in_edge->count;
 }
 
+  if (dom_info_available_p (CDI_DOMINATORS))
+{
+  /* The split_blocks leave [guard 0] as the immediate dominator
+of [call] and [call] as the immediate dominator of [join].
+Fix them up.  */
+  set_immediate_dominator (CDI_DOMINATORS, bi_call_bb, guard_bb);
+  set_immediate_dominator (CDI_DOMINATORS, join_tgt_bb, guard_bb);
+}
+
   if (dump_file && (dump_flags & TDF_DETAILS))
 {
   location_t loc;
@@ -927,7 +963,6 @@ pass_call_cdce::execute (function *fun)
 
   if (something_changed)
 {
-  free_dominance_info (CDI_DOMINATORS);
   free_dominance_info (CDI_POST_DOMINATORS);
   /* As we introduced new control-flow we need to insert PHI-nodes
  for the call-clobbers of the remaining call.  */

Re: [OpenACC] internal fn folding

[Nathan Sidwell]

On 10/28/15 14:40, Nathan Sidwell wrote:

Richard,
this patch adds folding for the new GOACC_DIM_POS and GOACC_DIM_SIZE internal
functions.  IIUC gimple_fold_call is the right place to add this.

The size of a compute dimension is very often a compile-time constant.  On the
host, in particular it's 1, which means we can deduce the POS must be zero.

ok?


https://gcc.gnu.org/ml/gcc-patches/2015-10/threads.html#03095

Ping?


nathan

OpenACC declare directive updates

[James Norris]

This patch updates the processing of OpenACC declare directive for
Fortran in the following areas:

1) module support
2) device_resident and link clauses
3) clause checking
4) directive generation

Commentary on the changes is included as an attachment (NOTES).

All of the code is in the gomp-4_0-branch.

Regtested on x86_64-linux.

Thanks!
Jim
Background

The declare directive is used to allocate device memory for the
entire scope of a variable / array within a program, function,
or subroutine. Consider the following example.

module vars
  integer b
  !$acc declare device_resident (b)
  integer c
  !$acc declare link (c)
end module vars

program main
  use vars
  integer, parameter :: N = 8
  integer :: a(N)

  a(:) = 2
  c = 12

  !$acc parallel copy (a) present (b) copyin(c)
  do i = 1, N
b = a(i)
c = b
a(i) = c + i
  end do
  !$acc end parallel

end program

In the example, 'b' will be allocated on the device at the outset
of device activity and be available for the duration. Whereas the
allocation of 'c' will be delayed until the parallel region is
entered. The device memory for 'c' will be deallocated upon exit
of the parallel region.

Fortran front-end

The changes are concentrated into four (4) areas.

1) module support
The neccesary functionality has been added to handle the
reading in and writing out of the appropriate attributes
for the declare directive. Additional functionality has
been added at read in time to setup the required declare
handling.

2) device_resident and link clauses
Add the functionality necessary to process the link and
device_resident clauses.

3) clause checking
The clause checking has been cleaned up to better check
for duplicates and correctness.

4) directive generation

Prior to handling the fortran execution body a code
body is created to handle the clause(s) that accompany
the declare directive(s). Each clause is examined and
determined whether the clause need to be modified to 
perform an action at the beginning of the module, function,
subroutine, or program. Furthermore, an additional
clause may be added to the list to perform an action
at the time the function or subroutine returns.

Once all the clauses have been handled, the code body
is added to the chain.

libgomp

TODO

Testing

New compile and runtime tests have been added. Also some have
been modified.
diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
index 83ecbaa..e953160 100644
--- a/gcc/fortran/dump-parse-tree.c
+++ b/gcc/fortran/dump-parse-tree.c
@@ -2572,10 +2572,14 @@ show_namespace (gfc_namespace *ns)
 
   if (ns->oacc_declare_clauses)
 {
+  struct gfc_oacc_declare *decl;
   /* Dump !$ACC DECLARE clauses.  */
-  show_indent ();
-  fprintf (dumpfile, "!$ACC DECLARE");
-  show_omp_clauses (ns->oacc_declare_clauses);
+  for (decl = ns->oacc_declare_clauses; decl; decl = decl->next)
+	{
+	  show_indent ();
+	  fprintf (dumpfile, "!$ACC DECLARE");
+	  show_omp_clauses (decl->clauses);
+	}
 }
 
   fputc ('\n', dumpfile);
diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c
index 67b0bac..2758a28 100644
--- a/gcc/fortran/f95-lang.c
+++ b/gcc/fortran/f95-lang.c
@@ -103,6 +103,8 @@ static const struct attribute_spec gfc_attribute_table[] =
affects_type_identity } */
   { "omp declare target", 0, 0, true,  false, false,
 gfc_handle_omp_declare_target_attribute, false },
+  { "oacc declare", 0, 0, true,  false, false,
+gfc_handle_omp_declare_target_attribute, false },
   { NULL,		  0, 0, false, false, false, NULL, false }
 };
 
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 90f63cf..17c2357 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -840,6 +840,13 @@ typedef struct
   /* Mentioned in OMP DECLARE TARGET.  */
   unsigned omp_declare_target:1;
 
+  /* Mentioned in OACC DECLARE.  */
+  unsigned oacc_declare_create:1;
+  unsigned oacc_declare_copyin:1;
+  unsigned oacc_declare_deviceptr:1;
+  unsigned oacc_declare_device_resident:1;
+  unsigned oacc_declare_link:1;
+
   /* Attributes set by compiler extensions (!GCC$ ATTRIBUTES).  */
   unsigned ext_attr:EXT_ATTR_NUM;
 
@@ -1105,7 +1112,9 @@ enum gfc_omp_map_op
   OMP_MAP_FORCE_FROM,
   OMP_MAP_FORCE_TOFROM,
   

Re: Re: [Patch ARM-AArch64/testsuite Neon intrinsics 00/20] Executable tests

[Jiong Wang]

On 27 May 2015 at 22:15, Christophe Lyon  
wrote:

 * gcc.target/aarch64/advsimd-intrinsics/vtbX.c: Likewise.



Noticed this testcase failed on big-endian on my local test

  gcc.target/aarch64/advsimd-intrinsics/vtbX.c line 188 in buffer 
'expected_vtbl3') at type int8x8 index 0: got 0x0 != 0xfff8

Re: [PATCH] New attribute to create target clones

[Evgeny Stupachenko]

Yes, that is exactly what should fix the tests.
Unfortunately I don't have access to darwin machine right now.
Can you please test if the patch (attached) fixes the tests?

gcc/
* multiple_target.c (create_dispatcher_calls): Add target check
on ifunc.
(create_target_clone): Change assembler name for versioned declarations.

gcc/testsuite
* gcc.dg/mvc1.c: Add dg-require-ifunc condition.
* gcc.dg/mvc4.c: Ditto.
* gcc.dg/mvc5.c: Ditto.
* g++.dg/ext/mvc1.C: Ditto.
* g++.dg/ext/mvc4.C: Ditto.
* gcc.dg/mvc7.c: Add dg-require-ifunc condition and checks on resolver.

Thanks,
Evgeny

On Sat, Oct 31, 2015 at 1:40 PM, Dominique d'Humières
 wrote:
> Evgeny,
> On darwin I see the following failures
> FAIL: g++.dg/ext/mvc1.C  -std=c++11 (test for excess errors)
> UNRESOLVED: g++.dg/ext/mvc1.C  -std=c++11 compilation failed to produce 
> executable
> FAIL: g++.dg/ext/mvc1.C  -std=c++14 (test for excess errors)
> UNRESOLVED: g++.dg/ext/mvc1.C  -std=c++14 compilation failed to produce 
> executable
> FAIL: g++.dg/ext/mvc1.C  -std=c++98 (test for excess errors)
> UNRESOLVED: g++.dg/ext/mvc1.C  -std=c++98 compilation failed to produce 
> executable
> FAIL: g++.dg/ext/mvc4.C  -std=gnu++11 (internal compiler error)
> FAIL: g++.dg/ext/mvc4.C  -std=gnu++11 (test for excess errors)
> FAIL: g++.dg/ext/mvc4.C  -std=gnu++14 (internal compiler error)
> FAIL: g++.dg/ext/mvc4.C  -std=gnu++14 (test for excess errors)
> FAIL: g++.dg/ext/mvc4.C  -std=gnu++98 (internal compiler error)
> FAIL: g++.dg/ext/mvc4.C  -std=gnu++98 (test for excess errors)
>
> FAIL: gcc.dg/mvc1.c (internal compiler error)
> FAIL: gcc.dg/mvc1.c (test for excess errors)
> UNRESOLVED: gcc.dg/mvc1.c compilation failed to produce executable
> FAIL: gcc.dg/mvc4.c (internal compiler error)
> FAIL: gcc.dg/mvc4.c (test for excess errors)
> UNRESOLVED: gcc.dg/mvc4.c compilation failed to produce executable
> FAIL: gcc.dg/mvc5.c (internal compiler error)
> FAIL: gcc.dg/mvc5.c (test for excess errors)
> FAIL: gcc.dg/mvc5.c scan-assembler-times foo.ifunc 6
> FAIL: gcc.dg/mvc7.c (internal compiler error)
> FAIL: gcc.dg/mvc7.c (test for excess errors)
> FAIL: gcc.dg/mvc7.c scan-assembler-times foo.ifunc 4
>
> The errors are of the kind
>
> /opt/gcc/_clean/gcc/testsuite/gcc.dg/mvc7.C:5:5: error: multiversioning needs 
> ifunc which is not supported on this target
>
> These tests probably require something such as
>
> /* { dg-require-ifunc "" } */
>
> I have no opinion if this should also used in the tests for warnings or 
> errors.
>
> The ICEs are of the kind
>
> /opt/gcc/_clean/gcc/testsuite/gcc.dg/mvc7.C:10:1: internal compiler error: 
> Segmentation fault: 11
>  }
>  ^
>
> TIA
>
> Dominique
>


target_clones_tests_fix.patch
Description: Binary data

[PATCH] Fix warning in tree-diagnostic.h.

[Dominik Vogt]

The attached patch fixes the annoying warnings generated by
diagnostic_set_last_function.

Can this be committed?

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany
gcc/ChangeLog

* tree-diagnostic.h (diagnostic_set_last_function): Fix warning.
>From b09e69bd66f157a2aaf0167b7419f47e9953950a Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Mon, 2 Nov 2015 13:58:53 +0100
Subject: [PATCH] Fix warning in tree-diagnostic.h.

---
 gcc/tree-diagnostic.h | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/gcc/tree-diagnostic.h b/gcc/tree-diagnostic.h
index c1cc1c5..60c6f1c 100644
--- a/gcc/tree-diagnostic.h
+++ b/gcc/tree-diagnostic.h
@@ -43,10 +43,13 @@ along with GCC; see the file COPYING3.  If not see
 /* Remember the current function as being the last one in which we report
a diagnostic.  */
 #define diagnostic_set_last_function(DC, DI)		\
-  diagnostic_context_auxiliary_data (DC)		\
-= (((DI) && diagnostic_abstract_origin (DI))	\
-   ? diagnostic_abstract_origin (DI)		\
-   : current_function_decl)
+  do {			\
+__typeof__ (DI) __x = (DI);\
+diagnostic_context_auxiliary_data (DC)		\
+  = (((__x) && diagnostic_abstract_origin (__x))	\
+	 ? diagnostic_abstract_origin (__x)		\
+	 : current_function_decl);			\
+  } while (0)
 
 void diagnostic_report_current_function (diagnostic_context *,
 	 diagnostic_info *);
-- 
2.3.0

Re: [AArch64] Update comments on the usage of X30 in FIXED_REGISTERS and CALL_USED_REGISTERS

[Richard Earnshaw]

On 02/11/15 12:58, Jiong Wang wrote:
> 
> 
> On 02/11/15 12:01, Richard Earnshaw wrote:
>> On 16/10/15 15:36, Jiong Wang wrote:
>>> The patch https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02654.html
>>> from last year changed the definition of LR in CALL_USED_REGISTERS,
>>> but didn't update the comment above the #define to reflect the new
>>> usage.
>>>
>>> This patch bring the comment inline with the implementation.
>>>
>>> OK for trunk?
>>>
>>> Thanks.
>>>
>>> 2015-10-16  Jiong. Wang  
>>>
>>> gcc/
>>>* config/aarch64/aarch64.h: Update the comments on usage of X30.
>>>
>>>
>>> fix-comment.patch
>>>
>>>
>>> diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
>>> index 5a8db76..1eaaca0 100644
>>> --- a/gcc/config/aarch64/aarch64.h
>>> +++ b/gcc/config/aarch64/aarch64.h
>>> @@ -210,14 +210,17 @@ extern unsigned aarch64_architecture_version;
>>>  significant bits.  Unlike AArch32 S1 is not packed into D0,
>>>  etc.  */
>>>   -/* Note that we don't mark X30 as a call-clobbered register.  The
>>> idea is
>>> -   that it's really the call instructions themselves which clobber X30.
>>> -   We don't care what the called function does with it afterwards.
>>> -
>>> -   This approach makes it easier to implement sibcalls.  Unlike normal
>>> -   calls, sibcalls don't clobber X30, so the register reaches the
>>> -   called function intact.  EPILOGUE_USES says that X30 is useful
>>> -   to the called function.  */
>>> +/* We don't mark X30 as a fixed register while we mark it as a
>>> caller-saved
>>> +   register.  The idea is we want X30 to be allocable as a caller-saved
>>> +   register when possible.
>>> +
>>> +   NOTE: although X30 is marked as caller-saved, it's callee-saved
>>> at the same
>>> +   time.  The caller-saved attribute makes sure if X30 is allocated
>>> as free
>>> +   register to hold any temporary value then the value is saved
>>> properly across
>>> +   function call.  While on AArch64, the call instruction writes the
>>> return
>>> +   address to LR.  If the called function is a non-leaf function, it
>>> is the
>>> +   responsibility of the callee to save and restore LR appropriately
>>> in it's
>>> +   prologue / epilogue.  */
>>>   
>> Sorry, but I find that just confusing.
>>
>> Wouldn't it be easier just to say:
>>
>>   X30 is clobbered by call instructions, so must be treated as a
>>   caller-saved register.
> 
> Richard, thanks for the review, but I am not convinced by your change.
> 
> "caller-saved" in gcc just means if the live range of the register is
> across function call then the caller will make sure it will be saved and
> restored properly. this is completely a calling convention concept and
> have not relationship with how call instruction works.
> 
> So, we mark X30 as caller-saved not because it will be clobbered by the
> call instructions but because we relax it as free register and want it
> to be saved by caller whenever it's allocated by register allocation and
> life range is across function call.
> 
> And from my understanding, if one register if clobbered by call
> instruction, it's not must be treated as a caller-saved register,
> instead it must be treated as a *callee-saved* register. Because the call
> instruction is actually assigning a new value to the register then jump
> to the callee in an atomic way thus there is no save/restore from the
> caller of this "new value", callee is full responsible for this. The
> "NOTE" part in the patch is trying to highlight this so following extra
> check in aarch64_layout_frame with be eaiser to understand for others.
> 
>   /* ... and any callee saved register that dataflow says is live. */
>   for (regno = R0_REGNUM; regno <= R30_REGNUM; regno++)
> if (df_regs_ever_live_p (regno)
> && (regno == R30_REGNUM   <--- X30, a caller-save, is
> callee-save as well.
> || !call_used_regs[regno]))
>   cfun->machine->frame.reg_offset[regno] = SLOT_REQUIRED;
> 
> Regards,
> Jiong

Right, I think I now understand what you are trying to say, but I still
think the wording does not convey that.

We have two statements of fact
1) On entry to a function LR contains the return address (by the
architecture)
2) LR cannot retain values across a function call (it is a caller-saved
register by the PCS)

We then have an implementation perspective on how to use LR given these
constraints: we treat the register as a callee-saved register and put
explicit clobbers on all call instructions.

So how does the following sound?

/* Technically, LR should be treated as a caller-saved register (since
it is modified during a subroutine call to contain the return address).
 However, from the compiler's perspective, it is best to treat it as a
callee-saved register and then to put explicit clobber instructions on
each call instruction to ensure that live values are not retained in it
across call instructions.  This allows us to use the register as a
scratch register between function 

Re: OpenACC atomic directive

[Jakub Jelinek]

On Mon, Nov 02, 2015 at 02:09:38PM +0100, Thomas Schwinge wrote:
> The OpenACC atomic directive matches OpenMP's atomic directive (got that
> clarified by the OpenACC committee), so they can share the same
> implementation.  OK for trunk?

Ok.

Jakub

[patch] New remainder of front end header reduction

[Andrew MacLeod]

On 11/02/2015 01:41 AM, Jeff Law wrote:

On 10/30/2015 07:37 AM, Andrew MacLeod wrote:

OK, here's the much delayed front end reduction patch based on the
reordering already being checked in.

I discovered that my targets builds were only building c/c++, so the
other languages were being reduced based only on the host
x86_64-pc-linux-gnu build.   Thats *probably* ok, but I wanted to be
sure.  This is when I discovered that the other languages have varying
amounts of support amongst the targets. Simply building all the targets
to compile, say ada, doesn't actually work quite right.

So this patch covers all the languages which do have full support.. the
ones enabled by 'all' languages.

I am determining which targets build the other languages now, and will
submit separate reduction patches for those languages.

Here's the rest of the front end files.  I will temporarily hold off 
checking in the other front end file due to the ENABLE_OFFLOADING and 
ENABLE_FOLD_CHECKING issues brought up.  I'll rerun the tool with all 
the ENABLE_* macros I can fine predefined in the tool to avoid this 
issue, and adjust he front end patches if necessary.. ie, if the tool 
finds a reduction that shouldnt happen.


Anyway, here's the rest of the header files which should be the final 
patch  I ran the tool on the coverage components of config-list.mk that 
supported each of the languages, then did a full build of all targets.


bootstraps on x86_64-pc-linux-gnu with no new regressions, and passes 
all of config-list.mk


Andrew

ada
	* gcc-interface/decl.c: Remove unused header files.
	* gcc-interface/misc.c: Likewise.
	* gcc-interface/targtyps.c: Likewise.
	* gcc-interface/trans.c: Likewise.
	* gcc-interface/utils.c: Likewise.

go
	* go-backend.c: Remove unused header files.
	* go-gcc.cc: Likewise.
	* go-lang.c: Likewise.
	* gospec.c: Likewise.

java
	* boehm.c: Remove unused header files.
	* builtins.c: Likewise.
	* class.c: Likewise.
	* constants.c: Likewise.
	* decl.c: Likewise.
	* except.c: Likewise.
	* expr.c: Likewise.
	* java-gimplify.c: Likewise.
	* jcf-dump.c: Likewise.
	* jcf-io.c: Likewise.
	* jcf-parse.c: Likewise.
	* jvgenmain.c: Likewise.
	* lang.c: Likewise.
	* mangle.c: Likewise.
	* mangle_name.c: Likewise.
	* resource.c: Likewise.
	* typeck.c: Likewise.
	* verify-glue.c: Likewise.
	* verify-impl.c: Likewise.
	* zextract.c: Likewise.

jit
	* dummy-frontend.c: Remove unused header files.
	* jit-builtins.c: Likewise.
	* jit-playback.c: Likewise.
	* jit-recording.c: Likewise.
	* jit-spec.c: Likewise.
	* libgccjit.c: Likewise.

objcp
	* objcp-decl.c: Remove unused header files.
	* objcp-lang.c: Likewise.
Index: ada/gcc-interface/decl.c
===
*** ada/gcc-interface/decl.c	(revision 229584)
--- ada/gcc-interface/decl.c	(working copy)
***
*** 26,32 
  #include "config.h"
  #include "system.h"
  #include "coretypes.h"
- #include "ggc.h"
  #include "target.h"
  #include "tree.h"
  #include "stringpool.h"
--- 26,31 
***
*** 34,41 
  #include "alias.h"
  #include "fold-const.h"
  #include "stor-layout.h"
- #include "flags.h"
- #include "toplev.h"
  #include "tree-inline.h"
  
  #include "ada.h"
--- 33,38 
***
*** 46,52 
  #include "nlists.h"
  #include "repinfo.h"
  #include "snames.h"
- #include "stringt.h"
  #include "uintp.h"
  #include "fe.h"
  #include "sinfo.h"
--- 43,48 
Index: ada/gcc-interface/misc.c
===
*** ada/gcc-interface/misc.c	(revision 229584)
--- ada/gcc-interface/misc.c	(working copy)
***
*** 26,32 
  #include "config.h"
  #include "system.h"
  #include "coretypes.h"
- #include "ggc.h"
  #include "target.h"
  #include "tree.h"
  #include "diagnostic.h"
--- 26,31 
***
*** 35,42 
  #include "fold-const.h"
  #include "stor-layout.h"
  #include "print-tree.h"
- #include "flags.h"
- #include "debug.h"
  #include "toplev.h"
  #include "langhooks.h"
  #include "langhooks-def.h"
--- 34,39 
***
*** 48,57 
  #include "adadecode.h"
  #include "types.h"
  #include "atree.h"
- #include "elists.h"
  #include "namet.h"
  #include "nlists.h"
- #include "stringt.h"
  #include "uintp.h"
  #include "fe.h"
  #include "sinfo.h"
--- 45,52 
Index: ada/gcc-interface/targtyps.c
===
*** ada/gcc-interface/targtyps.c	(revision 229584)
--- ada/gcc-interface/targtyps.c	(working copy)
***
*** 30,51 
  #include "coretypes.h"
  #include "tm.h"
  #include "tree.h"
- #include "tm_p.h"
- #include "alias.h"
  
  #include "ada.h"
  #include "types.h"
- #include "atree.h"
- #include "elists.h"
- #include "namet.h"
- #include "nlists.h"
- #include "snames.h"
- #include "stringt.h"
- #include "uintp.h"
- #include "urealp.h"
- #include "fe.h"
- #include "sinfo.h"
- #include "einfo.h"
  #include "ada-tree.h"
  #include 

[PATCH][combine][RFC] Don't transform sign and zero extends inside mults

[Kyrill Tkachov]

Hi all,

This patch attempts to restrict combine from transforming ZERO_EXTEND and 
SIGN_EXTEND operations into and-bitmask
and weird SUBREG expressions when they appear inside MULT expressions. This is 
because a MULT rtx containing these
extend operations is usually a well understood widening multiply operation.
However, if the costs for simple zero or sign-extend moves happen to line up in 
a particular way,
expand_compound_operation will end up mangling a perfectly innocent 
extend+mult+add rtx like:
 (set (reg/f:DI 393)
(plus:DI (mult:DI (sign_extend:DI (reg/v:SI 425 [ selected ]))
(sign_extend:DI (reg:SI 606)))
 (reg:DI 600)))

into:
 (set (reg/f:DI 393)
(plus:DI (mult:DI (and:DI (subreg:DI (reg:SI 606) 0)
(const_int 202 [0xca]))
(sign_extend:DI (reg/v:SI 425 [ selected ])))
 (reg:DI 600)))

because it decides that the and-subreg form is cheaper than a sign-extend, even 
though
the resultant expression can't hope to match a widening multiply-add pattern 
anymore.
The and-subreg form may well be cheaper as the SET_SRC of a simple set, but is 
unlikely
to be meaningful when inside a MULT expression.
AFAIK the accepted way of representing widening multiplies is with MULT 
expressions containing
zero/sign-extends, so rather than adding duplicate patterns in the backend to 
represent the different
ways an extend operation can be expressed by combine, I think we should stop 
combine from mangling
the representation where possible.

This patch fixes that by stopping the transformation on the extend operands of 
a MULT if the target
has a mode-appropriate widening multiply optab in the two places where I saw 
this happen.

With this patch on aarch64 I saw increased generation of smaddl and umaddl 
instructions where
before the combination of smull and add instructions were rejected because the 
extend operands
were being transformed into these weird equivalent expressions.

Overall, I see 24% more [su]maddl instructions being generated for SPEC2006 and 
with no performance regressions.

The testcase in the patch is the most minimal one I could get that demonstrates 
the issue I'm trying to solve.

Does this approach look ok?

Thanks,
Kyrill

2015-11-01  Kyrylo Tkachov  

* combine.c (subst): Restrict transformation when handling extend
ops inside a MULT.
(force_to_mode, binop case): Likewise.

2015-11-01  Kyrylo Tkachov  

* gcc.target/aarch64/umaddl_combine_1.c: New test.
commit 2005243d896cbeb3d22421a63f080699ab357610
Author: Kyrylo Tkachov 
Date:   Fri Oct 30 13:56:10 2015 +

[combine] Don't transform sign and zero extends inside mults

diff --git a/gcc/combine.c b/gcc/combine.c
index fa1a93f..be0f5ae 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -5369,6 +5369,7 @@ subst (rtx x, rtx from, rtx to, int in_dest, int in_cond, int unique_copy)
 		  n_occurrences++;
 		}
 	  else
+		{
 		/* If we are in a SET_DEST, suppress most cases unless we
 		   have gone inside a MEM, in which case we want to
 		   simplify the address.  We assume here that things that
@@ -5376,15 +5377,33 @@ subst (rtx x, rtx from, rtx to, int in_dest, int in_cond, int unique_copy)
 		   parts in the first expression.  This is true for SUBREG,
 		   STRICT_LOW_PART, and ZERO_EXTRACT, which are the only
 		   things aside from REG and MEM that should appear in a
-		   SET_DEST.  */
-		new_rtx = subst (XEXP (x, i), from, to,
+		   SET_DEST.  Also, restrict transformations on SIGN_EXTENDs
+		   and ZERO_EXTENDs if they appear inside multiplications if
+		   the target supports widening multiplies.  This is to avoid
+		   mangling such expressions beyond recognition.  */
+		  bool restrict_extend_p = false;
+		  rtx_code inner_code = GET_CODE (XEXP (x, i));
+
+		  if (code == MULT
+		  && (inner_code == SIGN_EXTEND
+			  || inner_code == ZERO_EXTEND)
+		  && widening_optab_handler (inner_code == ZERO_EXTEND
+		? umul_widen_optab
+		: smul_widen_optab,
+		  GET_MODE (x),
+		  GET_MODE (XEXP (XEXP (x, i), 0)))
+			 != CODE_FOR_nothing)
+		restrict_extend_p = true;
+
+		  new_rtx = subst (XEXP (x, i), from, to,
 			 (((in_dest
 && (code == SUBREG || code == STRICT_LOW_PART
 || code == ZERO_EXTRACT))
 			   || code == SET)
-			  && i == 0),
+			  && i == 0) || restrict_extend_p,
  code == IF_THEN_ELSE && i == 0,
  unique_copy);
+		}
 
 	  /* If we found that we will have to reject this combination,
 		 indicate that by returning the CLOBBER ourselves, rather than
@@ -8509,8 +8528,30 @@ force_to_mode (rtx x, machine_mode mode, unsigned HOST_WIDE_INT mask,
   /* For most binary operations, just propagate into the operation and
 	 change the mode if we have an operation of that mode.  */
 
-  op0 = force_to_mode (XEXP (x, 0), mode, mask, next_select);
-  op1 = force_to_mode (XEXP (x, 1), mode, 

Re: [PATCH] New attribute to create target clones

[Dominique d'Humières]

Evgeny,

I have already checked that the addition of

+/* { dg-require-ifunc "" } */

fixes the failures. I’ll test your full patch later today (currently chasing 
regression with gfortran).

Thanks,

Dominique

> Le 2 nov. 2015 à 15:50, Evgeny Stupachenko  a écrit :
> 
> Yes, that is exactly what should fix the tests.
> Unfortunately I don't have access to darwin machine right now.
> Can you please test if the patch (attached) fixes the tests?
> 
> gcc/
>* multiple_target.c (create_dispatcher_calls): Add target check
>on ifunc.
>(create_target_clone): Change assembler name for versioned 
> declarations.
> 
> gcc/testsuite
>* gcc.dg/mvc1.c: Add dg-require-ifunc condition.
>* gcc.dg/mvc4.c: Ditto.
>* gcc.dg/mvc5.c: Ditto.
>* g++.dg/ext/mvc1.C: Ditto.
>* g++.dg/ext/mvc4.C: Ditto.
>* gcc.dg/mvc7.c: Add dg-require-ifunc condition and checks on resolver.
> 
> Thanks,
> Evgeny
> 

Re: [ping] Re: Fix PR debug/66728

[Richard Sandiford]

Richard Sandiford  writes:
> gcc/
>   PR debug/66728
>   * dwarf2out.c (loc_descriptor): Remove redundant GET_MODE of
>   CONST_WIDE_INTs.  Handle BLKmode for CONST_WIDE_INT too.
>   (add_const_value_attribute): Add a mode parameter.
>   Check it for CONST_INT and CONST_WIDE_INT.  Use it to build
>   wide_int values.
>   (add_location_or_const_value_attribute): Update call.
>   (tree_add_const_value_attribute): Likewise.
> 
> gcc/testsuite/
>   PR debug/66728
>   * gcc.dg/debug/dwarf2/pr66728.c: New test.

And this time with the testsuite fix that Uros pointed out, sorry.

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 9ce3f09..cd84af6 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -3252,7 +3252,7 @@ static HOST_WIDE_INT field_byte_offset (const_tree);
 static void add_AT_location_description(dw_die_ref, enum 
dwarf_attribute,
 dw_loc_list_ref);
 static void add_data_member_location_attribute (dw_die_ref, tree);
-static bool add_const_value_attribute (dw_die_ref, rtx);
+static bool add_const_value_attribute (dw_die_ref, machine_mode, rtx);
 static void insert_int (HOST_WIDE_INT, unsigned, unsigned char *);
 static void insert_wide_int (const wide_int &, unsigned char *, int);
 static void insert_float (const_rtx, unsigned char *);
@@ -13799,10 +13799,9 @@ loc_descriptor (rtx rtl, machine_mode mode,
   break;
 
 case CONST_WIDE_INT:
-  if (mode == VOIDmode)
-   mode = GET_MODE (rtl);
-
-  if (mode != VOIDmode && (dwarf_version >= 4 || !dwarf_strict))
+  if (mode != VOIDmode
+ && mode != BLKmode
+ && (dwarf_version >= 4 || !dwarf_strict))
{
  loc_result = new_loc_descr (DW_OP_implicit_value,
  GET_MODE_SIZE (mode), 0);
@@ -15577,25 +15576,33 @@ insert_float (const_rtx rtl, unsigned char *array)
constants do not necessarily get memory "homes".  */
 
 static bool
-add_const_value_attribute (dw_die_ref die, rtx rtl)
+add_const_value_attribute (dw_die_ref die, machine_mode mode, rtx rtl)
 {
   switch (GET_CODE (rtl))
 {
 case CONST_INT:
-  {
-   HOST_WIDE_INT val = INTVAL (rtl);
+  if (mode != BLKmode)
+   {
+ gcc_checking_assert (SCALAR_INT_MODE_P (mode));
+ HOST_WIDE_INT val = INTVAL (rtl);
 
-   if (val < 0)
- add_AT_int (die, DW_AT_const_value, val);
-   else
- add_AT_unsigned (die, DW_AT_const_value, (unsigned HOST_WIDE_INT) 
val);
-  }
-  return true;
+ if (val < 0)
+   add_AT_int (die, DW_AT_const_value, val);
+ else
+   add_AT_unsigned (die, DW_AT_const_value,
+(unsigned HOST_WIDE_INT) val);
+ return true;
+   }
+  return false;
 
 case CONST_WIDE_INT:
-  add_AT_wide (die, DW_AT_const_value,
-  std::make_pair (rtl, GET_MODE (rtl)));
-  return true;
+  if (mode != BLKmode)
+   {
+ gcc_checking_assert (SCALAR_INT_MODE_P (mode));
+ add_AT_wide (die, DW_AT_const_value, std::make_pair (rtl, mode));
+ return true;
+   }
+  return false;
 
 case CONST_DOUBLE:
   /* Note that a CONST_DOUBLE rtx could represent either an integer or a
@@ -15672,7 +15679,7 @@ add_const_value_attribute (dw_die_ref die, rtx rtl)
 
 case CONST:
   if (CONSTANT_P (XEXP (rtl, 0)))
-   return add_const_value_attribute (die, XEXP (rtl, 0));
+   return add_const_value_attribute (die, mode, XEXP (rtl, 0));
   /* FALLTHROUGH */
 case SYMBOL_REF:
   if (!const_ok_for_output (rtl))
@@ -16175,7 +16182,7 @@ add_location_or_const_value_attribute (dw_die_ref die, 
tree decl, bool cache_p)
 
   rtl = rtl_for_decl_location (decl);
   if (rtl && (CONSTANT_P (rtl) || GET_CODE (rtl) == CONST_STRING)
-  && add_const_value_attribute (die, rtl))
+  && add_const_value_attribute (die, DECL_MODE (decl), rtl))
 return true;
 
   /* See if we have single element location list that is equivalent to
@@ -16196,7 +16203,7 @@ add_location_or_const_value_attribute (dw_die_ref die, 
tree decl, bool cache_p)
   if (GET_CODE (rtl) == EXPR_LIST)
rtl = XEXP (rtl, 0);
   if ((CONSTANT_P (rtl) || GET_CODE (rtl) == CONST_STRING)
- && add_const_value_attribute (die, rtl))
+ && add_const_value_attribute (die, DECL_MODE (decl), rtl))
 return true;
 }
   /* If this decl is from BLOCK_NONLOCALIZED_VARS, we might need its
@@ -16399,7 +16406,7 @@ tree_add_const_value_attribute (dw_die_ref die, tree t)
 
   rtl = rtl_for_decl_init (init, type);
   if (rtl)
-return add_const_value_attribute (die, rtl);
+return add_const_value_attribute (die, TYPE_MODE (type), rtl);
   /* If the host and target are sane, try harder.  */
   else if (CHAR_BIT == 8 && BITS_PER_UNIT == 8
   && initializer_constant_valid_p (init, type))
diff --git 

Re: [AArch64] Update comments on the usage of X30 in FIXED_REGISTERS and CALL_USED_REGISTERS

[Jiong Wang]

On 02/11/15 12:01, Richard Earnshaw wrote:

On 16/10/15 15:36, Jiong Wang wrote:

The patch https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02654.html
from last year changed the definition of LR in CALL_USED_REGISTERS,
but didn't update the comment above the #define to reflect the new usage.

This patch bring the comment inline with the implementation.

OK for trunk?

Thanks.

2015-10-16  Jiong. Wang  

gcc/
   * config/aarch64/aarch64.h: Update the comments on usage of X30.


fix-comment.patch


diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 5a8db76..1eaaca0 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -210,14 +210,17 @@ extern unsigned aarch64_architecture_version;
 significant bits.  Unlike AArch32 S1 is not packed into D0,
 etc.  */
  
-/* Note that we don't mark X30 as a call-clobbered register.  The idea is

-   that it's really the call instructions themselves which clobber X30.
-   We don't care what the called function does with it afterwards.
-
-   This approach makes it easier to implement sibcalls.  Unlike normal
-   calls, sibcalls don't clobber X30, so the register reaches the
-   called function intact.  EPILOGUE_USES says that X30 is useful
-   to the called function.  */
+/* We don't mark X30 as a fixed register while we mark it as a caller-saved
+   register.  The idea is we want X30 to be allocable as a caller-saved
+   register when possible.
+
+   NOTE: although X30 is marked as caller-saved, it's callee-saved at the same
+   time.  The caller-saved attribute makes sure if X30 is allocated as free
+   register to hold any temporary value then the value is saved properly across
+   function call.  While on AArch64, the call instruction writes the return
+   address to LR.  If the called function is a non-leaf function, it is the
+   responsibility of the callee to save and restore LR appropriately in it's
+   prologue / epilogue.  */
  

Sorry, but I find that just confusing.

Wouldn't it be easier just to say:

  X30 is clobbered by call instructions, so must be treated as a
  caller-saved register.


Richard, thanks for the review, but I am not convinced by your change.

"caller-saved" in gcc just means if the live range of the register is
across function call then the caller will make sure it will be saved and
restored properly. this is completely a calling convention concept and
have not relationship with how call instruction works.

So, we mark X30 as caller-saved not because it will be clobbered by the
call instructions but because we relax it as free register and want it
to be saved by caller whenever it's allocated by register allocation and
life range is across function call.

And from my understanding, if one register if clobbered by call
instruction, it's not must be treated as a caller-saved register,
instead it must be treated as a *callee-saved* register. Because the call
instruction is actually assigning a new value to the register then jump
to the callee in an atomic way thus there is no save/restore from the
caller of this "new value", callee is full responsible for this. The
"NOTE" part in the patch is trying to highlight this so following extra
check in aarch64_layout_frame with be eaiser to understand for others.

  /* ... and any callee saved register that dataflow says is live. */
  for (regno = R0_REGNUM; regno <= R30_REGNUM; regno++)
if (df_regs_ever_live_p (regno)
&& (regno == R30_REGNUM   <--- X30, a caller-save, is 
callee-save as well.

|| !call_used_regs[regno]))
  cfun->machine->frame.reg_offset[regno] = SLOT_REQUIRED;

Regards,
Jiong

OpenACC atomic directive

[Thomas Schwinge]

Hi!

The OpenACC atomic directive matches OpenMP's atomic directive (got that
clarified by the OpenACC committee), so they can share the same
implementation.  OK for trunk?

commit 826c7022d0e2b9e225215b168a95487823dce925
Author: Thomas Schwinge 
Date:   Mon Nov 2 10:35:44 2015 +0100

OpenACC atomic directive

-MM-DD  Thomas Schwinge  
Chung-Lin Tang  

gcc/c-family/
* c-pragma.c (oacc_pragmas): Add "atomic".
* c-pragma.h (pragma_kind): Add PRAGMA_OACC_ATOMIC.
gcc/c/
* c-parser.c (c_parser_omp_construct): Handle PRAGMA_OACC_ATOMIC.
gcc/cp/
* parser.c (cp_parser_omp_construct, cp_parser_pragma): Handle
PRAGMA_OACC_ATOMIC.
gcc/fortran/
* gfortran.h (gfc_statement): Add ST_OACC_ATOMIC,
ST_OACC_END_ATOMIC.
(gfc_exec_op): Add EXEC_OACC_ATOMIC.
* match.h (gfc_match_oacc_atomic): New prototype.
* openmp.c (gfc_match_omp_atomic, gfc_match_oacc_atomic): New
wrapper functions around...
(gfc_match_omp_oacc_atomic): ... this new function.
(oacc_code_to_statement, gfc_resolve_oacc_directive): Handle
EXEC_OACC_ATOMIC.
* parse.c (decode_oacc_directive): Handle "atomic", "end atomic".
(case_exec_markers): Add ST_OACC_ATOMIC.
(gfc_ascii_statement): Handle ST_OACC_ATOMIC, ST_OACC_END_ATOMIC.
(parse_omp_atomic): Rename to...
(parse_omp_oacc_atomic): ... this new function.  Add omp_p formal
parameter.  Adjust all users.
(parse_executable): Handle ST_OACC_ATOMIC.
(is_oacc): Handle EXEC_OACC_ATOMIC.
* resolve.c (gfc_resolve_blocks, gfc_resolve_code): Handle
EXEC_OACC_ATOMIC.
* st.c (gfc_free_statement): Handle EXEC_OACC_ATOMIC.
* trans-openmp.c (gfc_trans_oacc_directive): Handle
EXEC_OACC_ATOMIC.
* trans.c (trans_code): Handle EXEC_OACC_ATOMIC.
gcc/
* omp-low.c (check_omp_nesting_restrictions): Allow
GIMPLE_OMP_ATOMIC_LOAD, GIMPLE_OMP_ATOMIC_STORE inside OpenACC
contexts.

-MM-DD  Thomas Schwinge  

gcc/testsuite/
* c-c++-common/goacc-gomp/nesting-fail-1.c: Move "atomic" tests
from here to...
* c-c++-common/goacc-gomp/nesting-1.c: ... here, and expect them
to succeed.

-MM-DD  James Norris  

libgomp/
* testsuite/libgomp.oacc-c-c++-common/atomic_capture-1.c: New
file.
* testsuite/libgomp.oacc-c-c++-common/atomic_capture-2.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/atomic_rw-1.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/atomic_update-1.c: Likewise.
* testsuite/libgomp.oacc-fortran/atomic_capture-1.f90: Likewise.
* testsuite/libgomp.oacc-fortran/atomic_rw-1.f90: New file.
* testsuite/libgomp.oacc-fortran/atomic_update-1.f90: Likewise.

-MM-DD  Julian Brown  
Thomas Schwinge  

libgomp/
* testsuite/libgomp.oacc-c-c++-common/par-reduction-1.c: New file.
* testsuite/libgomp.oacc-c-c++-common/par-reduction-2.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/worker-single-1a.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/worker-single-4.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/worker-single-6.c: Likewise.
---
 gcc/c-family/c-pragma.c|1 +
 gcc/c-family/c-pragma.h|1 +
 gcc/c/c-parser.c   |3 +
 gcc/cp/parser.c|4 +
 gcc/fortran/gfortran.h |3 +-
 gcc/fortran/match.h|1 +
 gcc/fortran/openmp.c   |   22 +-
 gcc/fortran/parse.c|   40 +-
 gcc/fortran/resolve.c  |2 +
 gcc/fortran/st.c   |1 +
 gcc/fortran/trans-openmp.c |2 +
 gcc/fortran/trans.c|1 +
 gcc/omp-low.c  |5 +-
 gcc/testsuite/c-c++-common/goacc-gomp/nesting-1.c  |   44 +-
 .../c-c++-common/goacc-gomp/nesting-fail-1.c   |   26 -
 .../libgomp.oacc-c-c++-common/atomic_capture-1.c   |  866 +++
 .../libgomp.oacc-c-c++-common/atomic_capture-2.c   | 1626 
 .../libgomp.oacc-c-c++-common/atomic_rw-1.c|   34 +
 .../libgomp.oacc-c-c++-common/atomic_update-1.c|  760 +
 .../libgomp.oacc-c-c++-common/par-reduction-1.c|   44 +
 .../libgomp.oacc-c-c++-common/par-reduction-2.c|   48 +
 .../libgomp.oacc-c-c++-common/worker-single-1a.c   |   28 +
 

Re: [c++-delayed-folding] Introduce convert_to_complex_nofold

[Jason Merrill]

OK, thanks.

Jason

Re: [gomp4.1] Handle new form of #pragma omp declare target

[Jakub Jelinek]

On Mon, Nov 02, 2015 at 07:54:17PM +0300, Ilya Verbin wrote:
> Here is the patch.
> make check RUNTESTFLAGS=gomp.exp and check-target-libgomp passed.
> OK for gomp-4_5-branch?
> 
> 
> gcc/c/
>   * c-parser.c: Include context.h.
>   (c_parser_omp_declare_target): If decl has "omp declare target" or
>   "omp declare target link" attribute, and cgraph or varpool node already
>   exists, then set corresponding flags.
> gcc/cp/
>   * parser.c: Include context.h.
>   (cp_parser_omp_declare_target): If decl has "omp declare target" or
>   "omp declare target link" attribute, and cgraph or varpool node already
>   exists, then set corresponding flags.
> libgomp/
>   * testsuite/libgomp.c++/target-13.C: Add global variable with "omp
>   declare target ()" directive, use it in foo.
>   * testsuite/libgomp.c/target-28.c: Likewise.

Yes, thanks.

Jakub

[0/3] OpenACC reductions

[Nathan Sidwell]

Jakub,
the following patch series implements the reduction handling for OpenACC:

01-trunk-reductions-core-1102.patch  Core  execution changes
02-trunk-reductions-ptx-1102.patch   PTX backend bits
03-trunk-reductions-tests-1102.patch Testcases


The reduction mechanism relies on a new internal builtin -- IFN_GOACC_REDUCTION, 
which is used in 4 different places.  IYR the loop partionining is managed with 
FORK and JOIN unique_fn markers.  The reductions go around these as follows:


IFN_UNIQUE (HEAD_MARKER ...)
IFN_REDUCTION (SETUP ...)
IFN_UNIQUE (FORK ...)
IFN_REDUCTION (INIT ...)
IFN_UNIQUE (HEAD_MARKER)

IFN_UNIQUE (TAIL_MARKER ...)
IFN_REDUCTION (FINI ...)
IFN_UNIQUE (JOIN ...)
IFN_REDUCTION (TEARDOWN ...)
IFN_UNIQUE (TAIL_MARKER)


There's a quad of functions for each reduction variable of the loop.  If a loop 
is partitioned over multiple dimensions, there are additional quads for each 
dimension, surrounding the fork/join for that dimension.


All the reduction calls look similar and are:

V = REDUCTION (KIND, REF_TO_RES, LOCAL_VAR, LEVEL, OP, OFFSET)

REF_TO_RES is a pointer to a reciever object.  it is a null pointer constant if 
there is no such object.

LOCAL_VAR is the executing thread's instance of the reduction variable.
LEVEL is the dimension across which this reduction is partitiong (gang, worker, 
vector).  As with the head/tail markers,this assignment of level is deferred to 
the target compiler.

OP is the reduction operator
OFFSET is an offset into a hypothetical buffer allocated for all the reductions 
of this particular loop.  It's a way of identifying which quad of reductions 
apply to the same logical variable, and happens to be useful in some use cases 
(I'll expand on that in the PTX fragment).


All these functions return a new value for the local variable.

When everything collapses to a single thread (i.e. on the host), the 
implementation of these functions is trivial.


SETUP
   - if REF_TO_RES is not  nullptrconst, return *REF_TO_RES, else return 
LOCAL_VAR (this is  a compile-time check)

INIT & FINI
  - return LOCAL_VAR
TEARDOWN
  - if REF_TO_RES is not nullptrconst *REF_TO_RES = LOCAL_VAR.
always return LOCAL_VAR

Re: [PATCH 4/4] Add -Wmisleading-indentation to -Wall

[David Malcolm]

On Sun, 2015-11-01 at 17:06 -0500, Patrick Palka wrote:
> On Fri, Oct 30, 2015 at 5:03 AM, Richard Biener
>  wrote:
> > On Thu, Oct 29, 2015 at 6:38 PM, Jeff Law  wrote:
> >> On 10/29/2015 10:49 AM, David Malcolm wrote:
> >>>
> >>> Our documentation describes -Wall as enabling "all the warnings about
> >>> constructions that some users consider questionable, and that are easy to
> >>> avoid
> >>> (or modify to prevent the warning), even in conjunction with macros."
> >>>
> >>> I believe that -Wmisleading-indentation meets these criteria, and is
> >>> likely to be of benefit to users who may not read release notes; it
> >>> warns for indentation that's misleading, but not for indentation
> >>> that's merely bad: the former are places where a user will likely
> >>> want to fix the code.
> >>>
> >>> The fix is usually easy and obvious: fix the misleadingly-indented
> >>> code.  If that isn't an option for some reason, pragmas can be used to
> >>> turn off the warning for a particular fragment of code:
> >>>
> >>>#pragma GCC diagnostic push
> >>>#pragma GCC diagnostic ignored "-Wmisleading-indentation"
> >>>  if (flag)
> >>>x = 3;
> >>>y = 2;
> >>>#pragma GCC diagnostic pop
> >>>
> >>> -Wmisleading-indentation has been tested with a variety of indentation
> >>> styles (see gcc/testsuite/c-c++-common/Wmisleading-indentation.c)
> >>> and on a variety of real-world projects.  For example, in:
> >>>https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg119790.html
> >>> Patrick reports:
> >>> "Tested by building the linux, git, vim, sqlite and gdb-binutils sources
> >>>   with -Wmisleading-indentation."
> >>>
> >>> With the tweak earlier in this kit I believe we now have a good
> >>> enough signal:noise ratio for this warning to be widely used; hence this
> >>> patch adds the warning to -Wall.
> >>>
> >>> Bootstrapped with x86_64-pc-linux-gnu.
> >>>
> >>> OK for trunk?
> >>>
> >>> gcc/c-family/ChangeLog:
> >>> * c.opt (Wmisleading-indentation): Add to -Wall for C and C++.
> >>>
> >>> gcc/ChangeLog:
> >>> * doc/invoke.texi (-Wall): Add -Wmisleading-indentation to the
> >>> list.
> >>> (-Wmisleading-indentation): Update documentation to reflect
> >>> being enabled by -Wall in C/C++.
> >>
> >> I'm sure we'll get some grief for this :-)
> >>
> >> Approved once we're clean in GCC.  I'm going to explicitly say that we'll
> >> have to watch for fallout, particularly as we start getting feedback from
> >> Debian & Fedora mass-rebuilds as we approach release time.  If the fallout
> >> is too bad, we'll have to reconsider.
> >>
> >> I'll pre-approve patches which fix anything caught by this option in GCC as
> >> long as the fix just adjusts whitespace :-)
> >
> > Please at least check also binutils and gdb and other packages that use 
> > -Werror
> > (well, just rebuild Fedora world).
> 
> FYI binutils, gdb and glibc, from git, all fail to build due to
> -Wmisleading-indentation warnings/errors. (None of the warnings are
> bogus (IMO), though I don't think any of the warnings expose a real
> bug either.)

Bother.   Do you happen to have the logs handy? (or could you upload the
somewhere?)

I tried building binutils+gdb 854eb72b00ba46d65ce36dc3432f01e223ce44cb
with gcc6+this kit (on x86_64) but I get:
In file included from ../../src/bfd/archive.c:143:0:
../../src/bfd/../include/bfdlink.h:452:38: error: field ‘compress_debug’
has incomplete type
   enum compressed_debug_section_type compress_debug;
  ^
../../src/bfd/archive.c: In function ‘open_nested_file’:
../../src/bfd/archive.c:393:12: error: ‘bfd {aka struct bfd}’ has no
member named ‘lto_output’
   n_bfd->lto_output = archive->lto_output;
^
which appears to be unrelated snafu from the binutils+gdb side.

Thanks
Dave

Re: [v3 PATCH] Make the default constructors of tuple and pair conditionally explicit.

[Ville Voutilainen]

On 2 November 2015 at 17:19, Paolo Carlini  wrote:
> Anyway, so far the only detail which makes me a little nervous is the
> following:
>
> +  template 
> +struct __is_implicitly_default_constructible
> +  : public integral_constant +(is_default_constructible<_Tp>::value
> +&&
> __is_implicitly_default_constructible_safe<_Tp>::value)>
>
>
> I think we want to use __and_ (note that there isn't a single logical && in
> the whole type_traits, outside macros).


Yep. New patch, tested on Linux-PPC64. Minor typo fixes for the
changelog. Ok for trunk?


2015-11-01  Ville Voutilainen  

Make the default constructors of tuple and pair conditionally explicit.
* include/std/type_traits (
__do_is_implicitly_default_constructible_impl,
__is_implicitly_default_constructible_impl,
__is_implicitly_default_constructible_safe,
__is_implicitly_default_constructible): New.
* include/bits/stl_pair.h (pair::pair()): Use it.
* include/std/tuple (tuple<_T1, _T2>::tuple): Use it.
* include/std/tuple (_ImplicitlyDefaultConstructibleTuple): New.
* include/std/tuple (tuple<_Types...>::tuple()): Use it.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust.
* 
testsuite/20_util/is_implicitly_default_constructible/requirements/explicit_instantiation.cc:
New.
* 
testsuite/20_util/is_implicitly_default_constructible/requirements/typedefs.cc:
Likewise.
* testsuite/20_util/is_implicitly_default_constructible/value.cc: Likewise.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Adjust.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Likewise.
* testsuite/20_util/pair/cons/explicit_construct.cc: Likewise.
* testsuite/20_util/tuple/cons/explicit_construct.cc: Likewise.
diff --git a/libstdc++-v3/include/bits/stl_pair.h 
b/libstdc++-v3/include/bits/stl_pair.h
index a5a7898..dfcd357 100644
--- a/libstdc++-v3/include/bits/stl_pair.h
+++ b/libstdc++-v3/include/bits/stl_pair.h
@@ -141,13 +141,27 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template ,
- is_default_constructible<_U2>>
+ 
__is_implicitly_default_constructible<_U1>,
+ 
__is_implicitly_default_constructible<_U2>>
::value, bool>::type = true>
 #endif
   _GLIBCXX_CONSTEXPR pair()
   : first(), second() { }
 
+#if __cplusplus >= 201103L
+  template ,
+   is_default_constructible<_U2>,
+   __not_<
+ __and_<__is_implicitly_default_constructible<_U1>,
+__is_implicitly_default_constructible<_U2
+   ::value, bool>::type = false>
+  explicit constexpr pair()
+  : first(), second() { }
+#endif
+
   /** Two objects may be passed to a @c pair constructor to be copied.  */
 #if __cplusplus < 201103L
   pair(const _T1& __a, const _T2& __b)
diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 8af01f4..e6c32b3 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -551,16 +551,31 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
   return __and_...>::value;
 }
+static constexpr bool _ImplicitlyDefaultConstructibleTuple()
+{
+  return __and_<__is_implicitly_default_constructible<_Elements>...>
+::value;
+}
   };
 
 public:
   template::
-_DefaultConstructibleTuple(),
+_ImplicitlyDefaultConstructibleTuple(),
   bool>::type = true>
   constexpr tuple()
   : _Inherited() { }
 
+  template::
+_DefaultConstructibleTuple()
+  &&
+  !_TC2<_Dummy>::
+_ImplicitlyDefaultConstructibleTuple(),
+  bool>::type = false>
+  explicit constexpr tuple()
+  : _Inherited() { }
+
   // Shortcut for the cases where constructors taking _Elements...
   // need to be constrained.
   template using _TCC =
@@ -837,13 +852,27 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template ,
- is_default_constructible<_U2>>
+ 
__is_implicitly_default_constructible<_U1>,
+ 
__is_implicitly_default_constructible<_U2>>
::value, bool>::type = true>
 
   constexpr tuple()
   : _Inherited() { }
 
+  template ,
+is_default_constructible<_U2>,
+__not_<
+  

Re: [PATCH 4/4] Add -Wmisleading-indentation to -Wall

[David Malcolm]

On Mon, 2015-11-02 at 11:21 -0500, David Malcolm wrote:
> On Sun, 2015-11-01 at 17:06 -0500, Patrick Palka wrote:
> > On Fri, Oct 30, 2015 at 5:03 AM, Richard Biener
> >  wrote:
> > > On Thu, Oct 29, 2015 at 6:38 PM, Jeff Law  wrote:
> > >> On 10/29/2015 10:49 AM, David Malcolm wrote:
> > >>>
> > >>> Our documentation describes -Wall as enabling "all the warnings about
> > >>> constructions that some users consider questionable, and that are easy 
> > >>> to
> > >>> avoid
> > >>> (or modify to prevent the warning), even in conjunction with macros."
> > >>>
> > >>> I believe that -Wmisleading-indentation meets these criteria, and is
> > >>> likely to be of benefit to users who may not read release notes; it
> > >>> warns for indentation that's misleading, but not for indentation
> > >>> that's merely bad: the former are places where a user will likely
> > >>> want to fix the code.
> > >>>
> > >>> The fix is usually easy and obvious: fix the misleadingly-indented
> > >>> code.  If that isn't an option for some reason, pragmas can be used to
> > >>> turn off the warning for a particular fragment of code:
> > >>>
> > >>>#pragma GCC diagnostic push
> > >>>#pragma GCC diagnostic ignored "-Wmisleading-indentation"
> > >>>  if (flag)
> > >>>x = 3;
> > >>>y = 2;
> > >>>#pragma GCC diagnostic pop
> > >>>
> > >>> -Wmisleading-indentation has been tested with a variety of indentation
> > >>> styles (see gcc/testsuite/c-c++-common/Wmisleading-indentation.c)
> > >>> and on a variety of real-world projects.  For example, in:
> > >>>https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg119790.html
> > >>> Patrick reports:
> > >>> "Tested by building the linux, git, vim, sqlite and gdb-binutils sources
> > >>>   with -Wmisleading-indentation."
> > >>>
> > >>> With the tweak earlier in this kit I believe we now have a good
> > >>> enough signal:noise ratio for this warning to be widely used; hence this
> > >>> patch adds the warning to -Wall.
> > >>>
> > >>> Bootstrapped with x86_64-pc-linux-gnu.
> > >>>
> > >>> OK for trunk?
> > >>>
> > >>> gcc/c-family/ChangeLog:
> > >>> * c.opt (Wmisleading-indentation): Add to -Wall for C and C++.
> > >>>
> > >>> gcc/ChangeLog:
> > >>> * doc/invoke.texi (-Wall): Add -Wmisleading-indentation to the
> > >>> list.
> > >>> (-Wmisleading-indentation): Update documentation to reflect
> > >>> being enabled by -Wall in C/C++.
> > >>
> > >> I'm sure we'll get some grief for this :-)
> > >>
> > >> Approved once we're clean in GCC.  I'm going to explicitly say that we'll
> > >> have to watch for fallout, particularly as we start getting feedback from
> > >> Debian & Fedora mass-rebuilds as we approach release time.  If the 
> > >> fallout
> > >> is too bad, we'll have to reconsider.
> > >>
> > >> I'll pre-approve patches which fix anything caught by this option in GCC 
> > >> as
> > >> long as the fix just adjusts whitespace :-)
> > >
> > > Please at least check also binutils and gdb and other packages that use 
> > > -Werror
> > > (well, just rebuild Fedora world).
> > 
> > FYI binutils, gdb and glibc, from git, all fail to build due to
> > -Wmisleading-indentation warnings/errors. (None of the warnings are
> > bogus (IMO), though I don't think any of the warnings expose a real
> > bug either.)
> 
> Bother.   Do you happen to have the logs handy? (or could you upload the
> somewhere?)
> 
> I tried building binutils+gdb 854eb72b00ba46d65ce36dc3432f01e223ce44cb
> with gcc6+this kit (on x86_64) but I get:
> In file included from ../../src/bfd/archive.c:143:0:
> ../../src/bfd/../include/bfdlink.h:452:38: error: field ‘compress_debug’
> has incomplete type
>enum compressed_debug_section_type compress_debug;
>   ^
> ../../src/bfd/archive.c: In function ‘open_nested_file’:
> ../../src/bfd/archive.c:393:12: error: ‘bfd {aka struct bfd}’ has no
> member named ‘lto_output’
>n_bfd->lto_output = archive->lto_output;
> ^
> which appears to be unrelated snafu from the binutils+gdb side.

The only one I saw in glibc was this:

../stdlib/strtol_l.c: In function ‘strtoul_l_internal’:
../stdlib/strtol_l.c:356:9: error: statement is indented as if it were
guarded by... [-Werror=misleading-indentation]
 cnt < thousands_len; })
 ^
../stdlib/strtol_l.c:353:9: note: ...this ‘for’ clause, but it is not
   && ({ for (cnt = 0; cnt < thousands_len; ++cnt)
 ^

where the code is question looks like this:

   348for (c = *end; c != L_('\0'); c = *++end)
   349  if (((STRING_TYPE) c < L_('0') || (STRING_TYPE) c > L_('9'))
   350  # ifdef USE_WIDE_CHAR
   351  && (wchar_t) c != thousands
   352  # else
   353  && ({ for (cnt = 0; cnt < thousands_len; ++cnt)
   354if (thousands[cnt] != end[cnt])
   355  break;
   356   

Re: [PATCH][AArch64] Fix ICE on (const_double:HF 0.0)

[James Greenhalgh]

On Mon, Nov 02, 2015 at 06:03:58PM +, Alan Lawrence wrote:
> On 26/10/15 16:26, Alan Lawrence wrote:
> >The included testcase demonstrates the ICE: aarch64_valid_floating_const
> >(via aarch64_float_const_representable_p) disables HFmode immediates, but
> >allows 0.0. However, *movhf_aarch64 does not allow this insn:
> >
> >(insn 7 6 10 2 (set (mem:HF (reg/f:DI 73) [0 *f_2(D)+0 S2 A16])
> > (const_double:HF 0.0 [0x0.0p+0])) test.c:8 -1
> >  (nil))
> >
> >Fix is to allow the second operand to be zero, in the same way as
> >*movsf_aarch64.
> >
> >Bootstrapped + check-gcc on aarch64-none-linux-gnu.
> >New test also passing on arm-none-eabi.
> >
> >OK for trunk?
> >
> >gcc/ChangeLog:
> >
> > * config/aarch64/aarch64.md (*movhf_aarch64): Use
> > aarch64_reg_or_fp_zero for second operand.
> >
> >gcc/testsuite/ChangeLog:
> >
> > * gcc.target/aarch64/fp16/set_zero_1.c: New.
> >---
> >  gcc/config/aarch64/aarch64.md  |  2 +-
> >  gcc/testsuite/gcc.target/aarch64/fp16/set_zero_1.c | 22 
> > ++
> >  2 files changed, 23 insertions(+), 1 deletion(-)
> >  create mode 100644 gcc/testsuite/gcc.target/aarch64/fp16/set_zero_1.c
> >
> >diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> >index 78b9ae2..8895a4e 100644
> >--- a/gcc/config/aarch64/aarch64.md
> >+++ b/gcc/config/aarch64/aarch64.md
> >@@ -1120,7 +1120,7 @@
> >[(set (match_operand:HF 0 "nonimmediate_operand" "=w, ?r,w,w,m,r,m ,r")
> > (match_operand:HF 1 "general_operand"  "?rY, w,w,m,w,m,rY,r"))]
> >"TARGET_FLOAT && (register_operand (operands[0], HFmode)
> >-|| register_operand (operands[1], HFmode))"
> >+|| aarch64_reg_or_fp_zero (operands[1], HFmode))"
> >"@
> > mov\\t%0.h[0], %w1
> > umov\\t%w0, %1.h[0]
> >diff --git a/gcc/testsuite/gcc.target/aarch64/fp16/set_zero_1.c 
> >b/gcc/testsuite/gcc.target/aarch64/fp16/set_zero_1.c
> >new file mode 100644
> >index 000..36cadfd
> >--- /dev/null
> >+++ b/gcc/testsuite/gcc.target/aarch64/fp16/set_zero_1.c
> >@@ -0,0 +1,22 @@
> >+/* { dg-do run } */
> >+/* { dg-options "-O2" } */
> >+/* { dg-additional-options "-mfp16-format=ieee" { target "arm*-*-*" } } */
> >+
> >+extern void abort (void);
> >+
> >+__attribute__ ((noinline))
> >+void
> >+setfoo (__fp16 *f)
> >+{
> >+  *f = 0.0;
> >+}
> >+
> >+int
> >+main (int argc, char **argv)
> >+{
> >+  __fp16 a = 1.0;
> >+  setfoo ();
> >+  if (a != 0.0)
> >+abort ();
> >+  return 0;
> >+}
> >
> 
> Ping.

OK.

Thanks,
James

[0/2] OpenACC routine support

[Nathan Sidwell]

The following pair of patches add support for routines.

01-trunk-routine-code-1102.patch: Compiler changes
02-trunk-routine-tests-1102.patch: Tests

The  changes are pretty straight forwards, as the execution model patch set laid 
the groundwork.  Routines are decorated with the 'oacc routine' pragma, so they 
go through essentially the same processing as a parallels region, except of 
course they're already a device-side function.


As with existing offloading the design is forward compatible with device_type 
support, which would operate in the same manner as an openacc offloaded region 
function WRT processing the attribute.


nathan

Re: Allow matching of side effects in operand_equal_p

[Jan Hubicka]

> 
> But you don't even need the call case for tailmerge or ICF as we don't
> have CALL_EXPRs in GIMPLE.  No?

Sure, it will do the trick only if ?: generic folding is updated to pass 
OEP_MATCH_SIDE_EFFECTS
> 
> And you mean the difference of OEP_CONSTANT_ADDRESS_OF to
> OEP_ADDRESS_OF | OEP_MATCH_SIDE_EFFECTS then, right?
> 
> Ok if you go forward with that and do not change the CALL_EXPR case
> for now (you may add a FIXME comment).

OK.

Honza

Re: [Bulk] [OpenACC 0/7] host_data construct

[Julian Brown]

On Mon, 26 Oct 2015 19:34:22 +0100
Jakub Jelinek  wrote:

> Your use_device sounds very similar to use_device_ptr clause in
> OpenMP, which is allowed on #pragma omp target data construct and is
> implemented quite a bit differently from this; it is unclear if the
> OpenACC standard requires this kind of implementation, or you just
> chose to implement it this way.  In particular, the GOMP_target_data
> call puts the variables mentioned in the use_device_ptr clauses into
> the mapping structures (similarly how map clause appears) and the
> corresponding vars are privatized within the target data region
> (which is a host region, basically a fancy { } braces), where the
> private variables contain the offloading device's pointers.

As the author of the original patch, I have to say using the mapping
structures seems like a far better approach, but I've hit some trouble
with the details of adapting OpenACC to use that method.

Firstly, on trunk at least, use_device_ptr variables are restricted to
pointer or array types: that restriction doesn't exist in OpenACC, nor
actually could I find it in the OpenMP 4.1 document (my guess is the
standards are supposed to match in this regard). I think that a program
such as this should work:

void target_fn (int *targ_data);

int
main (int argc, char *argv[])
{
  char out;
  int myvar;
#pragma omp target enter data map(to: myvar)

#pragma omp target data use_device_ptr(myvar) map(from:out)
  {
target_fn ();
out = 5;
  }

  return 0;
}

"myvar" would have its address taken in the use_device_ptr region, and
places where the corresponding mapped variable has its address taken
would be replaced by a direct use of the mapped pointer. (Or is that
not a well-formed thing to do, in general?). This fails with "error:
'use_device_ptr' variable is neither a pointer nor an array".

Secondly, attempts to use use_device_ptr on (e.g.
dynamically-allocated) arrays accessed through a pointer cause an ICE
with the existing trunk OpenMP code:

#include 

void target_fn (char *targ_data);

int
main (int argc, char *argv[])
{
  char *myarr, out;

  myarr = malloc (1024);

#pragma omp target data map(to: myarr[0:1024])
  {
#pragma omp target data use_device_ptr(myarr) map(from:out)
{
  target_fn (myarr);
  out = 5;
}
  }

  return 0;
}

udp3.c: In function 'main':
udp3.c:6:1: internal compiler error: in make_decl_rtl, at varasm.c:1298
 main (int argc, char *argv[])
 ^
0x111256b make_decl_rtl(tree_node*)
/scratch/jbrown/openacc-trunk/src/gcc-mainline/gcc/varasm.c:1294
0x9ea005 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
expand_modifier, rtx_def**, bool)
/scratch/jbrown/openacc-trunk/src/gcc-mainline/gcc/expr.c:9559
0x9e31c2 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, 
rtx_def**, bool)
/scratch/jbrown/openacc-trunk/src/gcc-mainline/gcc/expr.c:7892
0x9cb4ae expand_expr
/scratch/jbrown/openacc-trunk/src/gcc-mainline/gcc/expr.h:255
0x9d907d expand_assignment(tree_node*, tree_node*, bool)
/scratch/jbrown/openacc-trunk/src/gcc-mainline/gcc/expr.c:5089
0x89e219 expand_gimple_stmt_1
/scratch/jbrown/openacc-trunk/src/gcc-mainline/gcc/cfgexpand.c:3576
0x89e60d expand_gimple_stmt
/scratch/jbrown/openacc-trunk/src/gcc-mainline/gcc/cfgexpand.c:3672
0x8a5773 expand_gimple_basic_block
/scratch/jbrown/openacc-trunk/src/gcc-mainline/gcc/cfgexpand.c:5676
0x8a72d4 execute
/scratch/jbrown/openacc-trunk/src/gcc-mainline/gcc/cfgexpand.c:6288

Furthermore, this looks strange to me (006t.omplower):

  .omp_data_arr.5.out = 
  myarr.8 = myarr;
  .omp_data_arr.5.myarr = myarr.8;
  #pragma omp target data map(from:out [len: 1]) use_device_ptr(myarr)
{
  D.2436 = .omp_data_arr.5.myarr;
  myarr = D.2436;

That's clobbering the original myarr variable, right?

Any clues on these two? The omp-low.c code is rather opaque to me...

Thanks,

Julian

Re: [PATCH 4/4] Add -Wmisleading-indentation to -Wall

[Patrick Palka]

On Mon, 2 Nov 2015, David Malcolm wrote:


On Sun, 2015-11-01 at 17:06 -0500, Patrick Palka wrote:

On Fri, Oct 30, 2015 at 5:03 AM, Richard Biener
 wrote:

On Thu, Oct 29, 2015 at 6:38 PM, Jeff Law  wrote:

On 10/29/2015 10:49 AM, David Malcolm wrote:


Our documentation describes -Wall as enabling "all the warnings about
constructions that some users consider questionable, and that are easy to
avoid
(or modify to prevent the warning), even in conjunction with macros."

I believe that -Wmisleading-indentation meets these criteria, and is
likely to be of benefit to users who may not read release notes; it
warns for indentation that's misleading, but not for indentation
that's merely bad: the former are places where a user will likely
want to fix the code.

The fix is usually easy and obvious: fix the misleadingly-indented
code.  If that isn't an option for some reason, pragmas can be used to
turn off the warning for a particular fragment of code:

   #pragma GCC diagnostic push
   #pragma GCC diagnostic ignored "-Wmisleading-indentation"
 if (flag)
   x = 3;
   y = 2;
   #pragma GCC diagnostic pop

-Wmisleading-indentation has been tested with a variety of indentation
styles (see gcc/testsuite/c-c++-common/Wmisleading-indentation.c)
and on a variety of real-world projects.  For example, in:
   https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg119790.html
Patrick reports:
"Tested by building the linux, git, vim, sqlite and gdb-binutils sources
  with -Wmisleading-indentation."

With the tweak earlier in this kit I believe we now have a good
enough signal:noise ratio for this warning to be widely used; hence this
patch adds the warning to -Wall.

Bootstrapped with x86_64-pc-linux-gnu.

OK for trunk?

gcc/c-family/ChangeLog:
* c.opt (Wmisleading-indentation): Add to -Wall for C and C++.

gcc/ChangeLog:
* doc/invoke.texi (-Wall): Add -Wmisleading-indentation to the
list.
(-Wmisleading-indentation): Update documentation to reflect
being enabled by -Wall in C/C++.


I'm sure we'll get some grief for this :-)

Approved once we're clean in GCC.  I'm going to explicitly say that we'll
have to watch for fallout, particularly as we start getting feedback from
Debian & Fedora mass-rebuilds as we approach release time.  If the fallout
is too bad, we'll have to reconsider.

I'll pre-approve patches which fix anything caught by this option in GCC as
long as the fix just adjusts whitespace :-)


Please at least check also binutils and gdb and other packages that use -Werror
(well, just rebuild Fedora world).


FYI binutils, gdb and glibc, from git, all fail to build due to
-Wmisleading-indentation warnings/errors. (None of the warnings are
bogus (IMO), though I don't think any of the warnings expose a real
bug either.)


Bother.   Do you happen to have the logs handy? (or could you upload the
somewhere?)

I tried building binutils+gdb 854eb72b00ba46d65ce36dc3432f01e223ce44cb
with gcc6+this kit (on x86_64) but I get:
In file included from ../../src/bfd/archive.c:143:0:
../../src/bfd/../include/bfdlink.h:452:38: error: field ‘compress_debug’
has incomplete type
  enum compressed_debug_section_type compress_debug;
 ^
../../src/bfd/archive.c: In function ‘open_nested_file’:
../../src/bfd/archive.c:393:12: error: ‘bfd {aka struct bfd}’ has no
member named ‘lto_output’
  n_bfd->lto_output = archive->lto_output;
   ^
which appears to be unrelated snafu from the binutils+gdb side.

Thanks
Dave




I don't have build logs but I have diffs that indicates where in the
code the warnings appear and how to address the warnings (roughly).

For binutils-gdb:

diff --git a/bfd/coff-i386.c b/bfd/coff-i386.c
index a9725c4..fca7887 100644
--- a/bfd/coff-i386.c
+++ b/bfd/coff-i386.c
@@ -139,7 +139,7 @@ coff_i386_reloc (bfd *abfd,
 #define DOIT(x) \
   x = ((x & ~howto->dst_mask) | (((x & howto->src_mask) + diff) & 
howto->dst_mask))

-if (diff != 0)
+  if (diff != 0)
   {
reloc_howto_type *howto = reloc_entry->howto;
unsigned char *addr = (unsigned char *) data + reloc_entry->address;
diff --git a/bfd/coff-x86_64.c b/bfd/coff-x86_64.c
index 4e6420a..23ffecb 100644
--- a/bfd/coff-x86_64.c
+++ b/bfd/coff-x86_64.c
@@ -138,7 +138,7 @@ coff_amd64_reloc (bfd *abfd,
 #define DOIT(x) \
   x = ((x & ~howto->dst_mask) | (((x & howto->src_mask) + diff) & 
howto->dst_mask))

-if (diff != 0)
+  if (diff != 0)
   {
reloc_howto_type *howto = reloc_entry->howto;
unsigned char *addr = (unsigned char *) data + reloc_entry->address;
diff --git a/gdb/ada-lang.c b/gdb/ada-lang.c
index fff4862..2559a36 100644
--- a/gdb/ada-lang.c
+++ b/gdb/ada-lang.c
@@ -11359,9 +11359,11 @@ ada_evaluate_subexp (struct type *expect_type, struct 
expression *exp,
   return value_zero (ada_aligned_type (type), lval_memory);
 }
   else
-arg1 = 

Re: [PATCH][AArch64] Fix ICE on (const_double:HF 0.0)

[Alan Lawrence]

On 26/10/15 16:26, Alan Lawrence wrote:

The included testcase demonstrates the ICE: aarch64_valid_floating_const
(via aarch64_float_const_representable_p) disables HFmode immediates, but
allows 0.0. However, *movhf_aarch64 does not allow this insn:

(insn 7 6 10 2 (set (mem:HF (reg/f:DI 73) [0 *f_2(D)+0 S2 A16])
 (const_double:HF 0.0 [0x0.0p+0])) test.c:8 -1
  (nil))

Fix is to allow the second operand to be zero, in the same way as
*movsf_aarch64.

Bootstrapped + check-gcc on aarch64-none-linux-gnu.
New test also passing on arm-none-eabi.

OK for trunk?

gcc/ChangeLog:

* config/aarch64/aarch64.md (*movhf_aarch64): Use
aarch64_reg_or_fp_zero for second operand.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/fp16/set_zero_1.c: New.
---
  gcc/config/aarch64/aarch64.md  |  2 +-
  gcc/testsuite/gcc.target/aarch64/fp16/set_zero_1.c | 22 ++
  2 files changed, 23 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/gcc.target/aarch64/fp16/set_zero_1.c

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 78b9ae2..8895a4e 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -1120,7 +1120,7 @@
[(set (match_operand:HF 0 "nonimmediate_operand" "=w, ?r,w,w,m,r,m ,r")
(match_operand:HF 1 "general_operand"  "?rY, w,w,m,w,m,rY,r"))]
"TARGET_FLOAT && (register_operand (operands[0], HFmode)
-|| register_operand (operands[1], HFmode))"
+|| aarch64_reg_or_fp_zero (operands[1], HFmode))"
"@
 mov\\t%0.h[0], %w1
 umov\\t%w0, %1.h[0]
diff --git a/gcc/testsuite/gcc.target/aarch64/fp16/set_zero_1.c 
b/gcc/testsuite/gcc.target/aarch64/fp16/set_zero_1.c
new file mode 100644
index 000..36cadfd
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/fp16/set_zero_1.c
@@ -0,0 +1,22 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+/* { dg-additional-options "-mfp16-format=ieee" { target "arm*-*-*" } } */
+
+extern void abort (void);
+
+__attribute__ ((noinline))
+void
+setfoo (__fp16 *f)
+{
+  *f = 0.0;
+}
+
+int
+main (int argc, char **argv)
+{
+  __fp16 a = 1.0;
+  setfoo ();
+  if (a != 0.0)
+abort ();
+  return 0;
+}



Ping.

--Alan

Re: libgo patch committed: Update to Go 1.5 release

[Uros Bizjak]

Hello!

> I have committed a patch to libgo to update it to the Go 1.5 release.
>
> As usual for libgo updates, the actual patch is too large to attach to
> this e-mail message.  I've attached the changes to the gccgo-specific
> files.
>
> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
> to mainline.
>
> This may cause trouble on non-GNU/Linux operating systems.  Please let
> me know about any problems you encounter.

There is one new testsuite failure on CentOS 5.11 (kernel 2.6.18),
where namespaces are not supported:

exec_linux_test.go:29:23: error: reference to undefined identifier
'syscall.CLONE_NEWUSER'
   Cloneflags: syscall.CLONE_NEWUSER,
   ^
FAIL: syscall

The test would be skipped, since "/proc/self/ns/user" doesn't exist,
however, the test doesn't compile due to missing CLONE_NEWUSER define.

Uros.

Re: [patch 4/3] Header file reduction - Tools for contrib - second cut

[Jeff Law]

On 10/14/2015 09:14 AM, Andrew MacLeod wrote:

Here's the latest version of the tools for a sub directory in contrib.
I've handled all the feedback, except I have not fully commented the
python code in the tools, nor followed any particular coding
convention...   Documentation has been handled, and I've added some
additional comments to the places which were noted as being unclear. Ive
also removed all tabs from the source files.

Ive also updated show-headers slightly to be a little more
error-resistant and to put some emphasis on any header files specified
on the command as being of interest . (when there are 140 shown, it can
be hard to find the one you are looking for sometimes)

Do we wish to impose anything in particular on the source for  tools
going into this sub-directory of contrib? The other tools in contrib
don't seem to have much in the way of coding standards. I also
wonder if anyone other than me will look at them much :-)

I'm certainly interested in them.

Do you have any sense of whether or not coverage of the tools has 
improved over short time since we started squashing out conditional 
compilation?  I was running the header file reordering bits on the trunk 
and was a bit surprised of how many things they're still changing.  But 
that would make sense if some files are now being processed that weren't 
before because we've squashed out the conditional compilation.


It certainly is true that the total result is smaller than any of the 
backend, config/ or languages changes that you posted, and I'm running 
it across the entire source tree, but I'm still surprised at how much 
churn I'm seeing.


If it weren't for the level of churn, I'd probably be suggesting we just 
have this stuff run regularly (weekly, monthly, whatever) and commit the 
result after a sanity looksie.  I've yet to see this tool botch anything 
and if we're not unnecessarily churning the sources, keeping us clean 
WRT canononical ordering and duplicate removal automatically seems like 
a good place to be.


Maybe do another commit of the reordering output and evaluate again in a 
month?


I don't think we're quite there on the reducer and it obviously requires 
more infrastructure in place to test.  But it'd be nice to get to a 
similar state on that tool.


Which reminds me, you ought to add a VMS target to your tests.  The 
reducer botched vmsdbgout.c.



alpha64-dec-vms
alpha-dec-vms
ia64-hp-vms

Covering any one of those ought to do the trick.

Thoughts?

jeff

Re: [PATCH] replace BITS_PER_UNIT with __CHAR_BIT__ in target libs

[Jeff Law]

On 10/30/2015 05:05 AM, tbsaunde+...@tbsaunde.org wrote:

From: Trevor Saunders 

Hi,

$subject as far as I am aware these are the same on all supported targets.

Trev

libgcc/ChangeLog:

2015-10-30  Trevor Saunders  

* config/visium/lib2funcs.c (__set_trampoline_parity): Use
__CHAR_BIT__ instead of BITS_PER_UNIT.
* fixed-bit.h: Likewise.
* fp-bit.h: Likewise.
* libgcc2.c (__popcountSI2): Likewise.
(__popcountDI2): Likewise.
* libgcc2.h: Likewise.
* libgcov.h: Likewise.

libobjc/ChangeLog:

2015-10-30  Trevor Saunders  

PR libobjc/24775
* encoding.c (_darwin_rs6000_special_round_type_align): Use
__CHAR_BIT__ instead of BITS_PER_UNIT.
(objc_sizeof_type): Likewise.
(objc_layout_structure): Likewise.
(objc_layout_structure_next_member): Likewise.
(objc_layout_finish_structure): Likewise.
(objc_layout_structure_get_info): Likewise.
Based on Bernd's comments, I think this is fine.  Any sense of how much 
work there is left to cleanup the runtime's inclusion of gcc's config/ 
target headers?


Jeff

Re: [2/2] OpenACC routine support

[Nathan Sidwell]

Here are the tests for the routine support.  The compiler tests check invalid 
combinations of gang, worker, vector & seq.  The libgomp execution tests check 
the expected partioning occurs within loops.  As  with the reduction tests, 
these ones  are taken from the execution model loop tests.


ok?

nathan
2015-11-02  Nathan Sidwell  

	gcc/testsuite/
	* c-c++-common/goacc/routine-1.c: New.
	* c-c++-common/goacc/routine-2.c: New.
	* c-c++-common/goacc/routine-3.c: New.
	* c-c++-common/goacc/routine-4.c: New.

	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/routine-g-1.c: New.
	* testsuite/libgomp.oacc-c-c++-common/routine-gwv-1.c: New.
	* testsuite/libgomp.oacc-c-c++-common/routine-v-1.c: New.
	* testsuite/libgomp.oacc-c-c++-common/routine-w-1.c: New.
	* testsuite/libgomp.oacc-c-c++-common/routine-wv-1.c: New.

Index: gcc/testsuite/c-c++-common/goacc/routine-1.c
===
--- gcc/testsuite/c-c++-common/goacc/routine-1.c	(revision 0)
+++ gcc/testsuite/c-c++-common/goacc/routine-1.c	(working copy)
@@ -0,0 +1,34 @@
+
+#pragma acc routine gang
+void gang (void)
+{
+}
+
+#pragma acc routine worker
+void worker (void)
+{
+}
+
+#pragma acc routine vector
+void vector (void)
+{
+}
+
+#pragma acc routine seq
+void seq (void)
+{
+}
+
+int main ()
+{
+
+#pragma acc parallel num_gangs (32) num_workers (32) vector_length (32)
+  {
+gang ();
+worker ();
+vector ();
+seq ();
+  }
+
+  return 0;
+}
Index: gcc/testsuite/c-c++-common/goacc/routine-2.c
===
--- gcc/testsuite/c-c++-common/goacc/routine-2.c	(revision 0)
+++ gcc/testsuite/c-c++-common/goacc/routine-2.c	(working copy)
@@ -0,0 +1,21 @@
+#pragma acc routine gang worker /* { dg-error "multiple loop axes" } */
+void gang (void)
+{
+}
+
+#pragma acc routine worker vector /* { dg-error "multiple loop axes" } */
+void worker (void)
+{
+}
+
+#pragma acc routine vector seq /* { dg-error "multiple loop axes" } */
+void vector (void)
+{
+}
+
+#pragma acc routine seq gang /* { dg-error "multiple loop axes" } */
+void seq (void)
+{
+}
+
+#pragma acc routine (nothing) gang /* { dg-error "not been declared" } */
Index: gcc/testsuite/c-c++-common/goacc/routine-3.c
===
--- gcc/testsuite/c-c++-common/goacc/routine-3.c	(revision 0)
+++ gcc/testsuite/c-c++-common/goacc/routine-3.c	(working copy)
@@ -0,0 +1,53 @@
+#pragma acc routine gang
+void gang (void) /* { dg-message "declared here" 3 } */
+{
+}
+
+#pragma acc routine worker
+void worker (void) /* { dg-message "declared here" 2 } */
+{
+}
+
+#pragma acc routine vector
+void vector (void) /* { dg-message "declared here" 1 } */
+{
+}
+
+#pragma acc routine seq
+void seq (void)
+{
+}
+
+int main ()
+{
+
+#pragma acc parallel num_gangs (32) num_workers (32) vector_length (32)
+  {
+#pragma acc loop gang /* { dg-message "loop here" 1 } */
+for (int i = 0; i < 10; i++)
+  {
+	gang (); /*  { dg-error "routine call uses same" } */
+	worker ();
+	vector ();
+	seq ();
+  }
+#pragma acc loop worker /* { dg-message "loop here" 2 } */
+for (int i = 0; i < 10; i++)
+  {
+	gang (); /*  { dg-error "routine call uses same" } */
+	worker (); /*  { dg-error "routine call uses same" } */
+	vector ();
+	seq ();
+  }
+#pragma acc loop vector /* { dg-message "loop here" 3 } */
+for (int i = 0; i < 10; i++)
+  {
+	gang (); /*  { dg-error "routine call uses same" } */
+	worker (); /*  { dg-error "routine call uses same" } */
+	vector (); /*  { dg-error "routine call uses same" } */
+	seq ();
+  }
+  }
+
+  return 0;
+}
Index: gcc/testsuite/c-c++-common/goacc/routine-4.c
===
--- gcc/testsuite/c-c++-common/goacc/routine-4.c	(revision 0)
+++ gcc/testsuite/c-c++-common/goacc/routine-4.c	(working copy)
@@ -0,0 +1,41 @@
+
+void gang (void);
+void worker (void);
+void vector (void);
+
+#pragma acc routine (gang) gang
+#pragma acc routine (worker) worker
+#pragma acc routine (vector) vector
+  
+#pragma acc routine seq
+void seq (void)
+{
+  gang ();  /* { dg-error "routine call uses" } */
+  worker ();  /* { dg-error "routine call uses" } */
+  vector ();  /* { dg-error "routine call uses" } */
+  seq ();
+}
+
+void vector (void) /* { dg-message "declared here" 1 } */
+{
+  gang ();  /* { dg-error "routine call uses" } */
+  worker ();  /* { dg-error "routine call uses" } */
+  vector ();
+  seq ();
+}
+
+void worker (void) /* { dg-message "declared here" 2 } */
+{
+  gang ();  /* { dg-error "routine call uses" } */
+  worker ();
+  vector ();
+  seq ();
+}
+
+void gang (void) /* { dg-message "declared here" 3 } */
+{
+  gang ();
+  worker ();
+  vector ();
+  seq ();
+}
Index: libgomp/testsuite/libgomp.oacc-c-c++-common/routine-g-1.c
===
--- 

Re: [Bulk] [OpenACC 0/7] host_data construct

[Jakub Jelinek]

On Mon, Nov 02, 2015 at 06:33:39PM +, Julian Brown wrote:
> As the author of the original patch, I have to say using the mapping
> structures seems like a far better approach, but I've hit some trouble
> with the details of adapting OpenACC to use that method.
> 
> Firstly, on trunk at least, use_device_ptr variables are restricted to
> pointer or array types: that restriction doesn't exist in OpenACC, nor
> actually could I find it in the OpenMP 4.1 document (my guess is the

^^ 4.5 ;)

> standards are supposed to match in this regard). I think that a program
> such as this should work:
> 
> void target_fn (int *targ_data);
> 
> int
> main (int argc, char *argv[])
> {
>   char out;
>   int myvar;
> #pragma omp target enter data map(to: myvar)
> 
> #pragma omp target data use_device_ptr(myvar) map(from:out)
>   {
> target_fn ();
> out = 5;
>   }
> 
>   return 0;
> }

You are right, I've been misreading the standard (the only testcases that
have been provided with the change were using arrays and so it was
non-obvious that it relies on array to pointer decay).
I'll work on changing the implementation accordingly tomorrow.

Jakub

Re: [PATCH 4/4] Add -Wmisleading-indentation to -Wall

[Marc Glisse]

On Mon, 2 Nov 2015, David Malcolm wrote:


I think we want the first kind of thing at -Wall, but I'm not so keen on
the second kind at -Wall.  Is there precedent for "levels" of a warning?
(so e.g. pedantry level 1 at -Wall, level 2 at -Wextra, and have patch 1
be the difference between levels 1 and 2?)


You mean something like -Wstrict-overflow=n?

--
Marc Glisse

Re: [PATCH 4/4] Add -Wmisleading-indentation to -Wall

[David Malcolm]

On Mon, 2015-11-02 at 13:39 -0500, Patrick Palka wrote:
> On Mon, 2 Nov 2015, David Malcolm wrote:
> 
> > On Sun, 2015-11-01 at 17:06 -0500, Patrick Palka wrote:
> >> On Fri, Oct 30, 2015 at 5:03 AM, Richard Biener
> >>  wrote:
> >>> On Thu, Oct 29, 2015 at 6:38 PM, Jeff Law  wrote:
>  On 10/29/2015 10:49 AM, David Malcolm wrote:
> >
> > Our documentation describes -Wall as enabling "all the warnings about
> > constructions that some users consider questionable, and that are easy 
> > to
> > avoid
> > (or modify to prevent the warning), even in conjunction with macros."
> >
> > I believe that -Wmisleading-indentation meets these criteria, and is
> > likely to be of benefit to users who may not read release notes; it
> > warns for indentation that's misleading, but not for indentation
> > that's merely bad: the former are places where a user will likely
> > want to fix the code.
> >
> > The fix is usually easy and obvious: fix the misleadingly-indented
> > code.  If that isn't an option for some reason, pragmas can be used to
> > turn off the warning for a particular fragment of code:
> >
> >#pragma GCC diagnostic push
> >#pragma GCC diagnostic ignored "-Wmisleading-indentation"
> >  if (flag)
> >x = 3;
> >y = 2;
> >#pragma GCC diagnostic pop
> >
> > -Wmisleading-indentation has been tested with a variety of indentation
> > styles (see gcc/testsuite/c-c++-common/Wmisleading-indentation.c)
> > and on a variety of real-world projects.  For example, in:
> >https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg119790.html
> > Patrick reports:
> > "Tested by building the linux, git, vim, sqlite and gdb-binutils sources
> >   with -Wmisleading-indentation."
> >
> > With the tweak earlier in this kit I believe we now have a good
> > enough signal:noise ratio for this warning to be widely used; hence this
> > patch adds the warning to -Wall.
> >
> > Bootstrapped with x86_64-pc-linux-gnu.
> >
> > OK for trunk?
> >
> > gcc/c-family/ChangeLog:
> > * c.opt (Wmisleading-indentation): Add to -Wall for C and C++.
> >
> > gcc/ChangeLog:
> > * doc/invoke.texi (-Wall): Add -Wmisleading-indentation to the
> > list.
> > (-Wmisleading-indentation): Update documentation to reflect
> > being enabled by -Wall in C/C++.
> 
>  I'm sure we'll get some grief for this :-)
> 
>  Approved once we're clean in GCC.  I'm going to explicitly say that we'll
>  have to watch for fallout, particularly as we start getting feedback from
>  Debian & Fedora mass-rebuilds as we approach release time.  If the 
>  fallout
>  is too bad, we'll have to reconsider.
> 
>  I'll pre-approve patches which fix anything caught by this option in GCC 
>  as
>  long as the fix just adjusts whitespace :-)
> >>>
> >>> Please at least check also binutils and gdb and other packages that use 
> >>> -Werror
> >>> (well, just rebuild Fedora world).
> >>
> >> FYI binutils, gdb and glibc, from git, all fail to build due to
> >> -Wmisleading-indentation warnings/errors. (None of the warnings are
> >> bogus (IMO), though I don't think any of the warnings expose a real
> >> bug either.)
> >
> > Bother.   Do you happen to have the logs handy? (or could you upload the
> > somewhere?)
> >
> > I tried building binutils+gdb 854eb72b00ba46d65ce36dc3432f01e223ce44cb
> > with gcc6+this kit (on x86_64) but I get:
> > In file included from ../../src/bfd/archive.c:143:0:
> > ../../src/bfd/../include/bfdlink.h:452:38: error: field ‘compress_debug’
> > has incomplete type
> >   enum compressed_debug_section_type compress_debug;
> >  ^
> > ../../src/bfd/archive.c: In function ‘open_nested_file’:
> > ../../src/bfd/archive.c:393:12: error: ‘bfd {aka struct bfd}’ has no
> > member named ‘lto_output’
> >   n_bfd->lto_output = archive->lto_output;
> >^
> > which appears to be unrelated snafu from the binutils+gdb side.
> >
> > Thanks
> > Dave
> >
> >
> 
> I don't have build logs but I have diffs that indicates where in the
> code the warnings appear and how to address the warnings (roughly).

Thanks.

> For binutils-gdb:
> 
> diff --git a/bfd/coff-i386.c b/bfd/coff-i386.c
> index a9725c4..fca7887 100644
> --- a/bfd/coff-i386.c
> +++ b/bfd/coff-i386.c
> @@ -139,7 +139,7 @@ coff_i386_reloc (bfd *abfd,
>   #define DOIT(x) \
> x = ((x & ~howto->dst_mask) | (((x & howto->src_mask) + diff) & 
> howto->dst_mask))
> 
> -if (diff != 0)
> +  if (diff != 0)
> {
>   reloc_howto_type *howto = reloc_entry->howto;
>   unsigned char *addr = (unsigned char *) data + reloc_entry->address;

This one has a fully blank line, so patch [1/4] would have suppressed
it.

> diff --git 

Re: [v3 PATCH] Make the default constructors of tuple and pair conditionally explicit.

[Ville Voutilainen]

On 2 November 2015 at 21:20, Paolo Carlini  wrote:
> Can we follow the terse style already used elsewhere (eg,
> __is_direct_constructible_new_safe) thus directly inherit from __and_ and
> avoid explicit integral_constant? Otherwise patch looks good to me.


Sure. Tested again on Linux-PPC64, tests adjusted due to line changes,
Changelog entry updated to have a correct date on it.

2015-11-02  Ville Voutilainen  

Make the default constructors of tuple and pair conditionally explicit.
* include/std/type_traits (
__do_is_implicitly_default_constructible_impl,
__is_implicitly_default_constructible_impl,
__is_implicitly_default_constructible_safe,
__is_implicitly_default_constructible): New.
* include/bits/stl_pair.h (pair::pair()): Use it.
* include/std/tuple (tuple<_T1, _T2>::tuple): Use it.
* include/std/tuple (_ImplicitlyDefaultConstructibleTuple): New.
* include/std/tuple (tuple<_Types...>::tuple()): Use it.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust.
* 
testsuite/20_util/is_implicitly_default_constructible/requirements/explicit_instantiation.cc:
New.
* 
testsuite/20_util/is_implicitly_default_constructible/requirements/typedefs.cc:
Likewise.
* testsuite/20_util/is_implicitly_default_constructible/value.cc: Likewise.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Adjust.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Likewise.
* testsuite/20_util/pair/cons/explicit_construct.cc: Likewise.
* testsuite/20_util/tuple/cons/explicit_construct.cc: Likewise.
diff --git a/libstdc++-v3/include/bits/stl_pair.h 
b/libstdc++-v3/include/bits/stl_pair.h
index a5a7898..dfcd357 100644
--- a/libstdc++-v3/include/bits/stl_pair.h
+++ b/libstdc++-v3/include/bits/stl_pair.h
@@ -141,13 +141,27 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template ,
- is_default_constructible<_U2>>
+ 
__is_implicitly_default_constructible<_U1>,
+ 
__is_implicitly_default_constructible<_U2>>
::value, bool>::type = true>
 #endif
   _GLIBCXX_CONSTEXPR pair()
   : first(), second() { }
 
+#if __cplusplus >= 201103L
+  template ,
+   is_default_constructible<_U2>,
+   __not_<
+ __and_<__is_implicitly_default_constructible<_U1>,
+__is_implicitly_default_constructible<_U2
+   ::value, bool>::type = false>
+  explicit constexpr pair()
+  : first(), second() { }
+#endif
+
   /** Two objects may be passed to a @c pair constructor to be copied.  */
 #if __cplusplus < 201103L
   pair(const _T1& __a, const _T2& __b)
diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 8af01f4..e6c32b3 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -551,16 +551,31 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
   return __and_...>::value;
 }
+static constexpr bool _ImplicitlyDefaultConstructibleTuple()
+{
+  return __and_<__is_implicitly_default_constructible<_Elements>...>
+::value;
+}
   };
 
 public:
   template::
-_DefaultConstructibleTuple(),
+_ImplicitlyDefaultConstructibleTuple(),
   bool>::type = true>
   constexpr tuple()
   : _Inherited() { }
 
+  template::
+_DefaultConstructibleTuple()
+  &&
+  !_TC2<_Dummy>::
+_ImplicitlyDefaultConstructibleTuple(),
+  bool>::type = false>
+  explicit constexpr tuple()
+  : _Inherited() { }
+
   // Shortcut for the cases where constructors taking _Elements...
   // need to be constrained.
   template using _TCC =
@@ -837,13 +852,27 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template ,
- is_default_constructible<_U2>>
+ 
__is_implicitly_default_constructible<_U1>,
+ 
__is_implicitly_default_constructible<_U2>>
::value, bool>::type = true>
 
   constexpr tuple()
   : _Inherited() { }
 
+  template ,
+is_default_constructible<_U2>,
+__not_<
+  __and_<__is_implicitly_default_constructible<_U1>,
+ __is_implicitly_default_constructible<_U2
+  ::value, bool>::type = false>
+
+  explicit constexpr tuple()
+  : _Inherited() { }
+
   

Re: libgo patch committed: Update to Go 1.5 release

[Ian Lance Taylor]

On Mon, Nov 2, 2015 at 1:37 AM, Andreas Schwab  wrote:
> Ian Lance Taylor  writes:
>
>> On Sun, Nov 1, 2015 at 1:39 AM, Andreas Schwab  wrote:
>>> ../../../../libgo/go/syscall/exec_linux.go:185:37: error: reference to 
>>> undefined name 'TIOCSPGRP'
>>>_, err1 = raw_ioctl_ptr(sys.Ctty, TIOCSPGRP, unsafe.Pointer())
>>>  ^
>>>
>>> $ grep TIOCSPGRP gen-sysinfo.go
>>> // unknowndefine TIOCSPGRP _IOW('t', 118, int)
>>
>> I have committed this patch which may fix the problem.  Let me know if
>> it still happens for you.  Thanks.
>
> ../../../../libgo/go/syscall/exec_linux.go:185:37: error: integer constant 
> overflow
>_, err1 = raw_ioctl_ptr(sys.Ctty, TIOCSPGRP, unsafe.Pointer())
>
> // unknowndefine TIOCSPGRP _IOW('t', 118, int)
> const _TIOCSPGRP_val = 2147775606

You still didn't say what system you are trying.  It makes any fix hard to test.

Still, I committed this patch in the hopes of fixing this problem.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 229645)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-6b4b969f552b8f9ac87a715d5ad06e52bd031b60
+e9550aa81d38ada037f675f50cbc09e6f1c35c12
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/syscall/exec_unix.go
===
--- libgo/go/syscall/exec_unix.go   (revision 229616)
+++ libgo/go/syscall/exec_unix.go   (working copy)
@@ -41,10 +41,10 @@ import (
 //sysnbraw_close(fd int) (err Errno)
 //close(fd _C_int) _C_int
 
-//sysnbraw_ioctl(fd int, cmd int, val int) (rval int, err Errno)
+//sysnbraw_ioctl(fd int, cmd uintptr, val int) (rval int, err Errno)
 //__go_ioctl(fd _C_int, cmd _C_int, val _C_int) _C_int
 
-//sysnb raw_ioctl_ptr(fd int, cmd int, val unsafe.Pointer) (rval int, err 
Errno)
+//sysnb raw_ioctl_ptr(fd int, cmd uintptr, val unsafe.Pointer) (rval int, err 
Errno)
 //__go_ioctl_ptr(fd _C_int, cmd _C_int, val unsafe.Pointer) _C_int
 
 //sysnbraw_execve(argv0 *byte, argv **byte, envv **byte) (err Errno)

[PR66326, Cilk+] Fix FP exception occured in CilkPlus runtime

[Zamyatin, Igor]

Hi!

This patches fixes FP exception that comes from CilkPlus runtime.

Bootstrapped and regtested for x86_64.
Is it ok for trunk?

Thanks,
Igor

Changelog:

libcilkrts

2015-10-30  Igor Zamyatin  

PR target/66326
* untime/config/x86/os-unix-sysdep.c (sysdep_save_fp_ctrl_state):
Use fnstcw instead fnstsw.


testsuite

2015-10-30  Igor Zamyatin  

PR target/66326
* g++.dg/cilk-plus/CK/pr66326.cc: New test.



diff --git a/gcc/testsuite/g++.dg/cilk-plus/CK/pr66326.cc 
b/gcc/testsuite/g++.dg/cilk-plus/CK/pr66326.cc
new file mode 100644
index 000..1114ebd
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cilk-plus/CK/pr66326.cc
@@ -0,0 +1,33 @@
+/* { dg-options "-fcilkplus" } */
+/* { dg-do run { target i?86-*-* x86_64-*-* } } */
+/* { dg-options "-fcilkplus -lcilkrts" { target { i?86-*-* x86_64-*-* } } } */
+
+#include 
+#include 
+#include 
+
+template 
+void do_not_optimize_away(T&& x) {
+  asm volatile("" : "+r"(x));
+}
+
+const int N = 1'000'000;
+
+auto compute() {
+  std::vector v(N);
+  auto rng = std::mt19937{std::random_device{}()};
+  std::uniform_real_distribution dist(0, 1);
+  for (int i = 0; i < N; ++i) v[i] = std::log(std::sqrt(dist(rng)));
+  return v;
+}
+
+int main() {
+  std::vector v1, v2, v3;
+  cilk_spawn [&] { v1 = compute(); }();
+  cilk_spawn [&] { v2 = compute(); }();
+  v3 = compute();
+  do_not_optimize_away(v1.data());
+  do_not_optimize_away(v2.data());
+  do_not_optimize_away(v3.data());
+  return 0;
+}
diff --git a/libcilkrts/runtime/config/x86/os-unix-sysdep.c 
b/libcilkrts/runtime/config/x86/os-unix-sysdep.c
index b505ddf..cbc7734 100644
--- a/libcilkrts/runtime/config/x86/os-unix-sysdep.c
+++ b/libcilkrts/runtime/config/x86/os-unix-sysdep.c
@@ -135,7 +135,7 @@ void sysdep_save_fp_ctrl_state(__cilkrts_stack_frame *sf)
 {
 __asm__ ("stmxcsr %0" : "=m" (sf->mxcsr));
 }
-__asm__ ("fnstsw %0" : "=m" (sf->fpcsr));
+   __asm__ ("fnstcw %0" : "=m" (sf->fpcsr));
 }
 #endif
 }

Re: [ping] Fix PR debug/66728

[Mike Stump]

On Nov 2, 2015, at 8:29 AM, Richard Sandiford  wrote:
>   switch (GET_CODE (rtl))
> {
> case CONST_INT:
> -  {
> - HOST_WIDE_INT val = INTVAL (rtl);
> +  if (mode != BLKmode)

This changes BLKmode for CONST_INT, but I didn’t see this discussed.  I didn’t 
see a test case?  I’d like to think that BLKmode things here would be fine.  I 
think they would be use for 1024 bit things that are representable in 20 bits, 
for example.  A value that is 1 (representable in 20 bits) can be trivially 
communicated the debugger.  The existing add_AT_unsigned I think can represent 
them, no?  Similarly for wide-int BLKmode support.  I think the real problem is 
simply the precision 0 part.  In the CONST_INT and CONST_DOUBLE there is no 
code that handled precision 0, and there is no code in the wide-int case 
either.  From wide-int.h:

  The precision and length of a wide_int are always greater than 0.

If is was 0, then we have failed.  When that bug is fixed, then the precision 
won’t be 0 and the existing code will work.  Where is the 0 first generated, 
and from what?

Status of rich location work (was Re: [PATCH 06/10] Track expression ranges in C frontend)

[David Malcolm]

On Fri, 2015-10-30 at 00:15 -0600, Jeff Law wrote:
> On 10/23/2015 02:41 PM, David Malcolm wrote:
> > As in the previous version of this patch
> >   "Implement tree expression tracking in C FE (v2)"
> > the patch now captures ranges for all C expressions during parsing within
> > a new field of c_expr, and for all tree nodes with a location_t, it stores
> > them in ad-hoc locations for later use.
> >
> > Hence compound expressions get ranges; see:
> >
> > https://dmalcolm.fedorapeople.org/gcc/2015-09-22/diagnostic-test-expressions-1.html
> >
> > and for this example:
> >
> >int test (int foo)
> >{
> >  return foo * 100;
> > ^^^   ^^^
> >}
> >
> > we have access to the ranges of "foo" and "100" during C parsing via
> > the c_expr, but once we have GENERIC, all we have is a VAR_DECL and an
> > INTEGER_CST (the former's location is in at the top of the
> > function, and the latter has no location).
> >
> > gcc/ChangeLog:
> > * Makefile.in (OBJS): Add gcc-rich-location.o.
> > * gcc-rich-location.c: New file.
> > * gcc-rich-location.h: New file.
> > * print-tree.c (print_node): Print any source range information.
> > * tree.c (set_source_range): New functions.
> > * tree.h (CAN_HAVE_RANGE_P): New.
> > (EXPR_LOCATION_RANGE): New.
> > (EXPR_HAS_RANGE): New.
> > (get_expr_source_range): New inline function.
> > (DECL_LOCATION_RANGE): New.
> > (set_source_range): New decls.
> > (get_decl_source_range): New inline function.
> >
> > gcc/c-family/ChangeLog:
> > * c-common.c (c_fully_fold_internal): Capture existing souce_range,
> > and store it on the result.
> >
> > gcc/c/ChangeLog:
> > * c-parser.c (set_c_expr_source_range): New functions.
> > (c_token::get_range): New method.
> > (c_token::get_finish): New method.
> > (c_parser_expr_no_commas): Call set_c_expr_source_range on the ret
> > based on the range from the start of the LHS to the end of the
> > RHS.
> > (c_parser_conditional_expression): Likewise, based on the range
> > from the start of the cond.value to the end of exp2.value.
> > (c_parser_binary_expression): Call set_c_expr_source_range on
> > the stack values for TRUTH_ANDIF_EXPR and TRUTH_ORIF_EXPR.
> > (c_parser_cast_expression): Call set_c_expr_source_range on ret
> > based on the cast_loc through to the end of the expr.
> > (c_parser_unary_expression): Likewise, based on the
> > op_loc through to the end of op.
> > (c_parser_sizeof_expression) Likewise, based on the start of the
> > sizeof token through to either the closing paren or the end of
> > expr.
> > (c_parser_postfix_expression): Likewise, using the token range,
> > or from the open paren through to the close paren for
> > parenthesized expressions.
> > (c_parser_postfix_expression_after_primary): Likewise, for
> > various kinds of expression.
> > * c-tree.h (struct c_expr): Add field "src_range".
> > (c_expr::get_start): New method.
> > (c_expr::get_finish): New method.
> > (set_c_expr_source_range): New decls.
> > * c-typeck.c (parser_build_unary_op): Call set_c_expr_source_range
> > on ret for prefix unary ops.
> > (parser_build_binary_op): Likewise, running from the start of
> > arg1.value through to the end of arg2.value.
> >
> > gcc/testsuite/ChangeLog:
> > * gcc.dg/plugin/diagnostic-test-expressions-1.c: New file.
> > * gcc.dg/plugin/diagnostic_plugin_test_tree_expression_range.c:
> > New file.
> > * gcc.dg/plugin/plugin.exp (plugin_test_list): Add
> > diagnostic_plugin_test_tree_expression_range.c and
> > diagnostic-test-expressions-1.c.
> 
> >   /* Initialization routine for this file.  */
> >
> > @@ -6085,6 +6112,9 @@ c_parser_expr_no_commas (c_parser *parser, struct 
> > c_expr *after,
> > ret.value = build_modify_expr (op_location, lhs.value, 
> > lhs.original_type,
> >  code, exp_location, rhs.value,
> >  rhs.original_type);
> > +  set_c_expr_source_range (,
> > +  lhs.get_start (),
> > +  rhs.get_finish ());
> One line if it fits.
> 
> 
> > @@ -6198,6 +6232,9 @@ c_parser_conditional_expression (c_parser *parser, 
> > struct c_expr *after,
> >? t1
> >: NULL);
> >   }
> > +  set_c_expr_source_range (,
> > +  start,
> > +  exp2.get_finish ());
> Here too.
> 
> > @@ -6522,6 +6564,10 @@ c_parser_cast_expression (c_parser *parser, struct 
> > c_expr *after)
> > expr = convert_lvalue_to_rvalue (expr_loc, expr, true, true);
> > }
> > ret.value = c_cast_expr (cast_loc, type_name, expr.value);
> > +  if (ret.value && expr.value)
> > +   set_c_expr_source_range (,
> > +cast_loc,
> > +expr.get_finish ());
> And here?
> 
> With the nits fixed, 

Re: [1/2] OpenACC routine support

[Nathan Sidwell]

This is the core changes, an C & C++ FE parsing pieces.

Parsing only deals with the gang, worker, vector & seq clauses.  The nohost and 
bind clauses will be a later patch to port.


The parsing is very similar to the omp declare simd parsing, in the way that 
it's hooked into the rest of the parser.  conversion  of the gang, worker, 
vecto & seq clauses to the internal 'oacc function' attribute format is done by 
a new routine, build_oacc_routine_dims, in omp-low.c.  This sets the dimensions 
over which a routine might partition a loop to integer_zero_node, and sets 
TREE_PURPOSE of such dimensions to zero.  while those dimensions over which it 
must not partition a loop have TREE_PURPOSE set to non-zero.  the handling for 
validating this in the lower_oacc_device pass, and in the PTX backend is already 
there.


ok?

nathan
2015-11-02  Nathan Sidwell  

	* omp-low.h (replace_oacc_fn_attrib, build_oacc_routine_dims): Declare.
	* omp-low.c (build_oacc_routine_dims): New.

2015-11-02  Thomas Schwinge  
	Cesar Philippidis  
	James Norris  
	Julian Brown  
	Nathan Sidwell  

	c/
	* c-parser.c (c_parser_declaration_or_fndef): Add OpenACC
	routine arg.  Adjust all callers.
	(c_parser_declaration_or_fndef): Call c_finish_oacc_routine.
	(c_parser_pragma): Parse 'acc routine'.
	(OACC_ROUTINE_CLAUSE_MARK): Define.
	(c_parser_oacc_routine, (c_finish_oacc_routine): New.

2015-11-02  Thomas Schwinge  
	Cesar Philippidis  
	James Norris  
	Julian Brown  
	Nathan Sidwell  

	c-family/
	* c-pragma.c (oacc_pragmas): Add "routine".
	* c-pragma.h (pragma_kind): Add PRAGMA_OACC_ROUTINE.

2015-11-02  Thomas Schwinge  
	Cesar Philippidis  
	James Norris  
	Julian Brown  
	Nathan Sidwell  

	cp/
	* parser.h (struct cp_parser): Add oacc_routine field.
	* parser.c (cp_ensure_no_oacc_routine): New.
	(cp_parser_new): Initialize oacc_routine field.
	(cp_parser_linkage_specification): Call cp_ensure_no_oacc_routine.
	(cp_parser_namespace_definition,
	cp_parser_class_specifier_1): Likewise.
	(cp_parser_init_declarator): Call cp_finalize_oacc_routine.
	(cp_parser_function_definition,
	cp_parser_save_member_function_body): Likewise.
	(OACC_ROUTINE_CLAUSE_MASK): New.
	(cp_parser_finish_oacc_routine, cp_parser_oacc_routine,
	cp_finalize_oacc_routine): New.
	(cp_parser_pragma): Adjust omp_declare_simd checking.  Call
	cp_ensure_no_oacc_routine.
	(cp_parser_pragma): Add OpenACC routine handling.
	
Index: gcc/c/c-parser.c
===
--- gcc/c/c-parser.c	(revision 229667)
+++ gcc/c/c-parser.c	(working copy)
@@ -1160,7 +1160,8 @@ enum c_parser_prec {
 static void c_parser_external_declaration (c_parser *);
 static void c_parser_asm_definition (c_parser *);
 static void c_parser_declaration_or_fndef (c_parser *, bool, bool, bool,
-	   bool, bool, tree *, vec);
+	   bool, bool, tree *, vec,
+	   tree);
 static void c_parser_static_assert_declaration_no_semi (c_parser *);
 static void c_parser_static_assert_declaration (c_parser *);
 static void c_parser_declspecs (c_parser *, struct c_declspecs *, bool, bool,
@@ -1249,6 +1250,7 @@ static bool c_parser_omp_target (c_parse
 static void c_parser_omp_end_declare_target (c_parser *);
 static void c_parser_omp_declare (c_parser *, enum pragma_context);
 static bool c_parser_omp_ordered (c_parser *, enum pragma_context);
+static void c_parser_oacc_routine (c_parser *parser, enum pragma_context);
 
 /* These Objective-C parser functions are only ever called when
compiling Objective-C.  */
@@ -1428,12 +1430,13 @@ c_parser_external_declaration (c_parser
 	 only tell which after parsing the declaration specifiers, if
 	 any, and the first declarator.  */
   c_parser_declaration_or_fndef (parser, true, true, true, false, true,
- NULL, vNULL);
+ NULL, vNULL, NULL_TREE);
   break;
 }
 }
 
 static void c_finish_omp_declare_simd (c_parser *, tree, tree, vec);
+static void c_finish_oacc_routine (c_parser *, tree, tree, bool, bool);
 
 /* Parse a declaration or function definition (C90 6.5, 6.7.1, C99
6.7, 6.9.1).  If FNDEF_OK is true, a function definition is
@@ -1511,7 +1514,8 @@ c_parser_declaration_or_fndef (c_parser
 			   bool static_assert_ok, bool empty_ok,
 			   bool nested, bool start_attr_ok,
 			   tree *objc_foreach_object_declaration,
-			   vec omp_declare_simd_clauses)
+			   vec omp_declare_simd_clauses,
+			   tree oacc_routine_clauses)
 {
   struct c_declspecs *specs;
   tree prefix_attrs;
@@ -1581,6 +1585,9 @@ 

Re: [v3 PATCH] Make the default constructors of tuple and pair conditionally explicit.

[Paolo Carlini]

Hi,

+  template 
+struct __is_implicitly_default_constructible
+  : public integral_constant,
+__is_implicitly_default_constructible_safe<_Tp>
+   >::value)>


Can we follow the terse style already used elsewhere (eg, 
__is_direct_constructible_new_safe) thus directly inherit from __and_ 
and avoid explicit integral_constant? Otherwise patch looks good to me.


Thanks,
Paolo.

Re: libgo patch committed: Update to Go 1.5 release

[Ian Lance Taylor]

On Mon, Nov 2, 2015 at 7:39 AM, Lynn A. Boger
 wrote:
> I see this error when building gccgo from trunk on ppc64le and running the
> libgo tests:
>
> exec_unix_test.go:174:43: error: reference to undefined identifier
> 'syscall.TIOCGPGRP'
>   errno := syscall.Ioctl(tty.Fd(), syscall.TIOCGPGRP,
> uintptr(unsafe.Pointer()))
>^
> FAIL: syscall
> make[3]: *** [syscall/check] Error 1

I have committed this patch which I hope will fix this problem.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 229674)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-e9550aa81d38ada037f675f50cbc09e6f1c35c12
+3b06572039eb525abfecce15f066ad6ab0fdea05
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/mksysinfo.sh
===
--- libgo/mksysinfo.sh  (revision 229645)
+++ libgo/mksysinfo.sh  (working copy)
@@ -183,6 +183,9 @@ enum {
 #ifdef TIOCSCTTY
   TIOCSCTTY_val = TIOCSCTTY,
 #endif
+#ifdef TIOCGPGRP
+  TIOCGPGRP_val = TIOCGPGRP,
+#endif
 #ifdef TIOCSPGRP
   TIOCSPGRP_val = TIOCSPGRP,
 #endif
@@ -920,6 +923,11 @@ if ! grep '^const TIOCSCTTY' ${OUT} >/de
 echo 'const TIOCSCTTY = _TIOCSCTTY_val' >> ${OUT}
   fi
 fi
+if ! grep '^const TIOCGPGRP' ${OUT} >/dev/null 2>&1; then
+  if grep '^const _TIOCGPGRP_val' ${OUT} >/dev/null 2>&1; then
+echo 'const TIOCGPGRP = _TIOCGPGRP_val' >> ${OUT}
+  fi
+fi
 if ! grep '^const TIOCSPGRP' ${OUT} >/dev/null 2>&1; then
   if grep '^const _TIOCSPGRP_val' ${OUT} >/dev/null 2>&1; then
 echo 'const TIOCSPGRP = _TIOCSPGRP_val' >> ${OUT}

Re: [Boolean Vector, patch 1/5] Introduce boolean vector to be used as a vector comparison type

[Jeff Law]

On 10/29/2015 07:08 AM, Ilya Enkovich wrote:

On 28 Oct 22:37, Ilya Enkovich wrote:

Seems the problem occurs in this check in expand_vector_operations_1:

   /* A scalar operation pretending to be a vector one.  */
   if (VECTOR_BOOLEAN_TYPE_P (type)
   && !VECTOR_MODE_P (TYPE_MODE (type))
   && TYPE_MODE (type) != BLKmode)
 return;

This is to filter out scalar operations on boolean vectors.
The problem here is that TYPE_MODE (type) doesn't return
V4SImode assigned to the type but calls vector_type_mode
instead which tries to find an integer mode for it and returns
TImode. This causes function exit and we don't expand vector
comparison.

Suppose simple option to fix it is to change default get_mask_mode
hook to return BLKmode in case chosen integer vector mode is not
vector_mode_supported_p.

Thanks,
Ilya



Here is a patch which fixes the problem on ARM (and on i386 with -mno-sse 
also).  I checked it fixes the problem on ARM and also bootstrapped and checked 
it on x86_64-unknown-linux-gnu.  Is it OK?

Thanks,
Ilya
--
gcc/

2015-10-29  Ilya Enkovich  

* targhooks.c (default_get_mask_mode): Use BLKmode in
case target doesn't support required vector mode.
* stor-layout.c (layout_type): Check for BLKmode.
VOIDmode would probably be a better choice than BLKmode to signal when 
the target doesn't support the required vector mode.



Jeff

Re: [2/2] OpenACC routine support

[Jakub Jelinek]

On Mon, Nov 02, 2015 at 02:23:19PM -0500, Nathan Sidwell wrote:
> +#pragma acc routine gang
> +void __attribute__ ((noinline)) gang (int ary[N])
> +{
> +#pragma acc loop gang
> +for (unsigned ix = 0; ix < N; ix++)
> +  {
> + if (__builtin_acc_on_device (5))
> +   {
> + int g = 0, w = 0, v = 0;
> +
> + __asm__ volatile ("mov.u32 %0,%%ctaid.x;" : "=r" (g));
> + __asm__ volatile ("mov.u32 %0,%%tid.y;" : "=r" (w));
> + __asm__ volatile ("mov.u32 %0,%%tid.x;" : "=r" (v));
> + ary[ix] = (g << 16) | (w << 8) | v;
> +   }
> + else
> +   ary[ix] = ix;

Does this work even with -O0?  I mean, the assembler is invalid
for any target other than PTX, so you are relying on aggressively folding
this away.

Jakub

Re: Status of rich location work (was Re: [PATCH 06/10] Track expression ranges in C frontend)

[David Malcolm]

On Mon, 2015-11-02 at 14:14 -0500, David Malcolm wrote:
> On Fri, 2015-10-30 at 00:15 -0600, Jeff Law wrote:
> > On 10/23/2015 02:41 PM, David Malcolm wrote:
> > > As in the previous version of this patch
> > >   "Implement tree expression tracking in C FE (v2)"
> > > the patch now captures ranges for all C expressions during parsing within
> > > a new field of c_expr, and for all tree nodes with a location_t, it stores
> > > them in ad-hoc locations for later use.
> > >
> > > Hence compound expressions get ranges; see:
> > >
> > > https://dmalcolm.fedorapeople.org/gcc/2015-09-22/diagnostic-test-expressions-1.html
> > >
> > > and for this example:
> > >
> > >int test (int foo)
> > >{
> > >  return foo * 100;
> > > ^^^   ^^^
> > >}
> > >
> > > we have access to the ranges of "foo" and "100" during C parsing via
> > > the c_expr, but once we have GENERIC, all we have is a VAR_DECL and an
> > > INTEGER_CST (the former's location is in at the top of the
> > > function, and the latter has no location).
> > >
> > > gcc/ChangeLog:
> > >   * Makefile.in (OBJS): Add gcc-rich-location.o.
> > >   * gcc-rich-location.c: New file.
> > >   * gcc-rich-location.h: New file.
> > >   * print-tree.c (print_node): Print any source range information.
> > >   * tree.c (set_source_range): New functions.
> > >   * tree.h (CAN_HAVE_RANGE_P): New.
> > >   (EXPR_LOCATION_RANGE): New.
> > >   (EXPR_HAS_RANGE): New.
> > >   (get_expr_source_range): New inline function.
> > >   (DECL_LOCATION_RANGE): New.
> > >   (set_source_range): New decls.
> > >   (get_decl_source_range): New inline function.
> > >
> > > gcc/c-family/ChangeLog:
> > >   * c-common.c (c_fully_fold_internal): Capture existing souce_range,
> > >   and store it on the result.
> > >
> > > gcc/c/ChangeLog:
> > >   * c-parser.c (set_c_expr_source_range): New functions.
> > >   (c_token::get_range): New method.
> > >   (c_token::get_finish): New method.
> > >   (c_parser_expr_no_commas): Call set_c_expr_source_range on the ret
> > >   based on the range from the start of the LHS to the end of the
> > >   RHS.
> > >   (c_parser_conditional_expression): Likewise, based on the range
> > >   from the start of the cond.value to the end of exp2.value.
> > >   (c_parser_binary_expression): Call set_c_expr_source_range on
> > >   the stack values for TRUTH_ANDIF_EXPR and TRUTH_ORIF_EXPR.
> > >   (c_parser_cast_expression): Call set_c_expr_source_range on ret
> > >   based on the cast_loc through to the end of the expr.
> > >   (c_parser_unary_expression): Likewise, based on the
> > >   op_loc through to the end of op.
> > >   (c_parser_sizeof_expression) Likewise, based on the start of the
> > >   sizeof token through to either the closing paren or the end of
> > >   expr.
> > >   (c_parser_postfix_expression): Likewise, using the token range,
> > >   or from the open paren through to the close paren for
> > >   parenthesized expressions.
> > >   (c_parser_postfix_expression_after_primary): Likewise, for
> > >   various kinds of expression.
> > >   * c-tree.h (struct c_expr): Add field "src_range".
> > >   (c_expr::get_start): New method.
> > >   (c_expr::get_finish): New method.
> > >   (set_c_expr_source_range): New decls.
> > >   * c-typeck.c (parser_build_unary_op): Call set_c_expr_source_range
> > >   on ret for prefix unary ops.
> > >   (parser_build_binary_op): Likewise, running from the start of
> > >   arg1.value through to the end of arg2.value.
> > >
> > > gcc/testsuite/ChangeLog:
> > >   * gcc.dg/plugin/diagnostic-test-expressions-1.c: New file.
> > >   * gcc.dg/plugin/diagnostic_plugin_test_tree_expression_range.c:
> > >   New file.
> > >   * gcc.dg/plugin/plugin.exp (plugin_test_list): Add
> > >   diagnostic_plugin_test_tree_expression_range.c and
> > >   diagnostic-test-expressions-1.c.
> > 
> > >   /* Initialization routine for this file.  */
> > >
> > > @@ -6085,6 +6112,9 @@ c_parser_expr_no_commas (c_parser *parser, struct 
> > > c_expr *after,
> > > ret.value = build_modify_expr (op_location, lhs.value, 
> > > lhs.original_type,
> > >code, exp_location, rhs.value,
> > >rhs.original_type);
> > > +  set_c_expr_source_range (,
> > > +lhs.get_start (),
> > > +rhs.get_finish ());
> > One line if it fits.
> > 
> > 
> > > @@ -6198,6 +6232,9 @@ c_parser_conditional_expression (c_parser *parser, 
> > > struct c_expr *after,
> > >  ? t1
> > >  : NULL);
> > >   }
> > > +  set_c_expr_source_range (,
> > > +start,
> > > +exp2.get_finish ());
> > Here too.
> > 
> > > @@ -6522,6 +6564,10 @@ c_parser_cast_expression (c_parser *parser, struct 
> > > c_expr *after)
> > >   expr = convert_lvalue_to_rvalue (expr_loc, expr, true, true);
> > > }
> > > ret.value = c_cast_expr (cast_loc, type_name, expr.value);
> > > + 

Re: [2/2] OpenACC routine support

[Nathan Sidwell]

On 11/02/15 14:41, Jakub Jelinek wrote:


Does this work even with -O0?  I mean, the assembler is invalid
for any target other than PTX, so you are relying on aggressively folding
this away.


Correct.  As thread identification is inherently target-specific, I don't see 
how to do otherwise.


We know _builtin_acc_on_device is folded for a constant arg, and -O2 enables 
dead code elimination such that non-PTX targets (such as the host) don't see 
that assembler.



nathan

[PR68001, CilkPlus] Fix for PR68001

[Zamyatin, Igor]

Hi!

This patch attempts to enhance error diagnostic in case of CilkPlus and fixes 
PR68001.

Bootstrapped and regtested for x86_64.
Is it ok for trunk?

Thanks,
Igor

ChangeLog:

c-family

2015-11-02  Igor Zamyatin  

PR c++/68001
* c-gimplify.c (c_gimplify_expr): Stop the process if see an error.
* cilk.c (recognize_spawn): Determine location in a more precise
way.

cp

2015-11-02  Igor Zamyatin  

PR c++/68001
* cp-gimplify.c (cp_gimplify_expr): Stop the process if see an error.

testsuite

2015-11-02  Igor Zamyatin  

PR c++/68001
* g++.dg/cilk-plus/CK/pr68001.cc: New test.


diff --git a/gcc/c-family/c-gimplify.c b/gcc/c-family/c-gimplify.c
index 92987b5..5b173d5 100644
--- a/gcc/c-family/c-gimplify.c
+++ b/gcc/c-family/c-gimplify.c
@@ -283,15 +283,16 @@ c_gimplify_expr (tree *expr_p, gimple_seq *pre_p 
ATTRIBUTE_UNUSED,
 
 case CILK_SPAWN_STMT:
   gcc_assert
-   (fn_contains_cilk_spawn_p (cfun)
-&& cilk_detect_spawn_and_unwrap (expr_p));
+   (fn_contains_cilk_spawn_p (cfun)
+   && cilk_detect_spawn_and_unwrap (expr_p));
 
-  /* If errors are seen, then just process it as a CALL_EXPR.  */
   if (!seen_error ())
{
  cilk_gimplify_call_params_in_spawned_fn (expr_p, pre_p, post_p);
  return (enum gimplify_status) gimplify_cilk_spawn (expr_p);
}
+  return GS_ERROR;
+
 case MODIFY_EXPR:
 case INIT_EXPR:
 case CALL_EXPR:
diff --git a/gcc/c-family/cilk.c b/gcc/c-family/cilk.c
index 1c316a4..77cb6e4 100644
--- a/gcc/c-family/cilk.c
+++ b/gcc/c-family/cilk.c
@@ -82,6 +82,8 @@ struct wrapper_data
   tree block;
 };
 
+static tree
+contains_cilk_spawn_stmt_walker (tree *tp, int *, void *);
 static void extract_free_variables (tree, struct wrapper_data *,
enum add_variable_type);
 static HOST_WIDE_INT cilk_wrapper_count;
@@ -241,7 +243,19 @@ recognize_spawn (tree exp, tree *exp0)
 }
   /* _Cilk_spawn can't be wrapped in expression such as PLUS_EXPR.  */
   else if (contains_cilk_spawn_stmt (exp))
-error_at (EXPR_LOCATION (exp), "invalid use of %<_Cilk_spawn%>");
+{
+  location_t loc = EXPR_LOCATION (exp);
+  if (loc == UNKNOWN_LOCATION)
+   {
+ tree stmt = walk_tree (,
+contains_cilk_spawn_stmt_walker,
+NULL,
+NULL);
+ gcc_assert (stmt != NULL_TREE);
+ loc = EXPR_LOCATION (stmt);
+   }
+  error_at (loc, "invalid use of %<_Cilk_spawn%>");
+}
   return spawn_found;
 }
 
diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index e37cbc7..6b444d6 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -625,6 +625,9 @@ cp_gimplify_expr (tree *expr_p, gimple_seq *pre_p, 
gimple_seq *post_p)
  cilk_cp_gimplify_call_params_in_spawned_fn (expr_p, pre_p, post_p);
  return (enum gimplify_status) gimplify_cilk_spawn (expr_p);
}
+  else if (seen_error ())
+   return GS_ERROR;
+
   cp_gimplify_init_expr (expr_p);
   if (TREE_CODE (*expr_p) != INIT_EXPR)
return GS_OK;
@@ -733,16 +736,17 @@ cp_gimplify_expr (tree *expr_p, gimple_seq *pre_p, 
gimple_seq *post_p)
   break;
 
 case CILK_SPAWN_STMT:
-  gcc_assert 
-   (fn_contains_cilk_spawn_p (cfun) 
-&& cilk_detect_spawn_and_unwrap (expr_p));
+  gcc_assert
+   (fn_contains_cilk_spawn_p (cfun)
+   && cilk_detect_spawn_and_unwrap (expr_p));
 
-  /* If errors are seen, then just process it as a CALL_EXPR.  */
   if (!seen_error ())
{
  cilk_cp_gimplify_call_params_in_spawned_fn (expr_p, pre_p, post_p);
  return (enum gimplify_status) gimplify_cilk_spawn (expr_p);
}
+  return GS_ERROR;
+
 case CALL_EXPR:
   if (fn_contains_cilk_spawn_p (cfun)
  && cilk_detect_spawn_and_unwrap (expr_p)
diff --git a/gcc/testsuite/g++.dg/cilk-plus/CK/pr68001.cc 
b/gcc/testsuite/g++.dg/cilk-plus/CK/pr68001.cc
new file mode 100644
index 000..6137c07
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cilk-plus/CK/pr68001.cc
@@ -0,0 +1,19 @@
+/* PR middle-end/68001 */
+/* { dg-do compile } */
+/* { dg-options "-fcilkplus" } */
+
+#include 
+#include 
+
+std::vector f() {
+  std::vector v;
+  return v;
+}
+
+int main()
+{
+  std::vector x = cilk_spawn f(); /* { dg-error "invalid use of" } */
+  std::vector y = f();
+  cilk_sync;
+  return 0;
+}

Re: [PING] Re: [PATCH] c++/67913, 67917 - fix new expression with wrong number of elements

[Jason Merrill]

On 10/26/2015 10:06 PM, Martin Sebor wrote:

+  if (TREE_CONSTANT (maybe_constant_value (outer_nelts)))
+   {
+ if (tree_int_cst_lt (max_outer_nelts_tree, outer_nelts))


maybe_constant_value may return a constant, but that doesn't mean that 
outer_nelts was already constant; if it wasn't, the call to 
tree_int_cst_lt will fail.



+  tree nelts_save = nelts;
+  nelts = maybe_constant_value (nelts);
+
+  if (!TREE_CONSTANT (nelts))
+   nelts = nelts_save;
+
+  /* The expression in a noptr-new-declarator is erroneous if it's of
+non-class type and its value before converting to std::size_t is
+less than zero. ... If the expression is a constant expression,
+the program is ill-fomed.  */
+  if (TREE_CONSTANT (nelts) && tree_int_cst_sgn (nelts) == -1)
+   {
+ if (complain & tf_error)
+   error ("size of array is negative");
+ return error_mark_node;
+   }


Since we're moving toward delayed folding, I'd prefer to use the result 
of maybe_constant_value only for this diagnostic, and then continue to 
pass the unfolded value along.


Jason

Re: [v3 PATCH] Make the default constructors of tuple and pair conditionally explicit.

[Ville Voutilainen]

On 2 November 2015 at 23:07, Paolo Carlini  wrote:
> Great, thanks a lot. Thinking more about this detail, I wonder if we should
> therefore apply the below too? Anything I'm missing?

Tested again on Linux-PPC64. Ok for trunk?

2015-11-03  Ville Voutilainen  

Make the default constructors of tuple and pair conditionally explicit.
* include/std/type_traits (is_unsigned, __is_array_unknown_bounds,
__is_default_constructible_atom, __is_default_constructible_safe,
__is_direct_constructible_new_safe, __is_direct_constructible_ref_cast,
__is_nt_default_constructible_impl, is_nothrow_default_constructible,
is_nothrow_constructible, is_nothrow_assignable,
is_trivially_constructible, is_trivially_copy_constructible,
is_trivially_move_constructible, is_trivially_assignable,
is_trivially_copy_assignable, is_trivially_move_assignable,
is_trivially_destructible): Simplify.
* include/std/type_traits (
__do_is_implicitly_default_constructible_impl,
__is_implicitly_default_constructible_impl,
__is_implicitly_default_constructible_safe,
__is_implicitly_default_constructible): New.
* include/bits/stl_pair.h (pair::pair()): Use it.
* include/std/tuple (tuple<_T1, _T2>::tuple): Use it.
* include/std/tuple (_ImplicitlyDefaultConstructibleTuple): New.
* include/std/tuple (tuple<_Types...>::tuple()): Use it.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust.
* 
testsuite/20_util/is_implicitly_default_constructible/requirements/explicit_instantiation.cc:
New.
* 
testsuite/20_util/is_implicitly_default_constructible/requirements/typedefs.cc:
Likewise.
* testsuite/20_util/is_implicitly_default_constructible/value.cc: Likewise.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Adjust.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Likewise.
* testsuite/20_util/pair/cons/explicit_construct.cc: Likewise.
* testsuite/20_util/tuple/cons/explicit_construct.cc: Likewise.
diff --git a/libstdc++-v3/include/bits/stl_pair.h 
b/libstdc++-v3/include/bits/stl_pair.h
index a5a7898..dfcd357 100644
--- a/libstdc++-v3/include/bits/stl_pair.h
+++ b/libstdc++-v3/include/bits/stl_pair.h
@@ -141,13 +141,27 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template ,
- is_default_constructible<_U2>>
+ 
__is_implicitly_default_constructible<_U1>,
+ 
__is_implicitly_default_constructible<_U2>>
::value, bool>::type = true>
 #endif
   _GLIBCXX_CONSTEXPR pair()
   : first(), second() { }
 
+#if __cplusplus >= 201103L
+  template ,
+   is_default_constructible<_U2>,
+   __not_<
+ __and_<__is_implicitly_default_constructible<_U1>,
+__is_implicitly_default_constructible<_U2
+   ::value, bool>::type = false>
+  explicit constexpr pair()
+  : first(), second() { }
+#endif
+
   /** Two objects may be passed to a @c pair constructor to be copied.  */
 #if __cplusplus < 201103L
   pair(const _T1& __a, const _T2& __b)
diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 8af01f4..e6c32b3 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -551,16 +551,31 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
   return __and_...>::value;
 }
+static constexpr bool _ImplicitlyDefaultConstructibleTuple()
+{
+  return __and_<__is_implicitly_default_constructible<_Elements>...>
+::value;
+}
   };
 
 public:
   template::
-_DefaultConstructibleTuple(),
+_ImplicitlyDefaultConstructibleTuple(),
   bool>::type = true>
   constexpr tuple()
   : _Inherited() { }
 
+  template::
+_DefaultConstructibleTuple()
+  &&
+  !_TC2<_Dummy>::
+_ImplicitlyDefaultConstructibleTuple(),
+  bool>::type = false>
+  explicit constexpr tuple()
+  : _Inherited() { }
+
   // Shortcut for the cases where constructors taking _Elements...
   // need to be constrained.
   template using _TCC =
@@ -837,13 +852,27 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template ,
- is_default_constructible<_U2>>
+ 
__is_implicitly_default_constructible<_U1>,
+ 
__is_implicitly_default_constructible<_U2>>

Re: Multiply Optimization in match and Simplify

[Hurugalawadi, Naveen]

Hi,

Thanks for the review and suggestions.

>> Please do not drop A - B -> A + (-B) from fold-const as match.pd
>> doesn't implement all of fold-const.c negate_expr_p support.

Done.

>> which is more expensive.  This means that we miss a
>> (bit_and (bit_not @0) INTEGER_CST@1)

Should we have this pattern implemented in match.pd?

>> negate_expr_p doesn't capture everything
>> fold-const.c does so moving the above isn't a good idea.

Dropped the pattern. Was working on some more patterns
that had negate_expr_p. Will drop all of them.

>> fold-const.c only handles constant C, so we only need to 2nd pattern.

Yeah. Thought that even having variable would be optimized in a similar
manner and hence had that pattern.

Please find attached the modified pattern as per suggestions.
Please review the patch and let me know if there should be any further
modifications in it.

Thanks,
Naveendiff --git a/gcc/fold-const.c b/gcc/fold-const.c
index ee9b349..c34d462 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -9739,18 +9739,6 @@ fold_binary_loc (location_t loc,
 		  negate_expr (arg0)),
 tem);
 
-	  /* (A + A) * C -> A * 2 * C  */
-	  if (TREE_CODE (arg0) == PLUS_EXPR
-	  && TREE_CODE (arg1) == INTEGER_CST
-	  && operand_equal_p (TREE_OPERAND (arg0, 0),
-			  TREE_OPERAND (arg0, 1), 0))
-	return fold_build2_loc (loc, MULT_EXPR, type,
-omit_one_operand_loc (loc, type,
-		  TREE_OPERAND (arg0, 0),
-		  TREE_OPERAND (arg0, 1)),
-fold_build2_loc (loc, MULT_EXPR, type,
-	 build_int_cst (type, 2) , arg1));
-
 	  /* ((T) (X /[ex] C)) * C cancels out if the conversion is
 	 sign-changing only.  */
 	  if (TREE_CODE (arg1) == INTEGER_CST
@@ -9940,45 +9928,6 @@ fold_binary_loc (location_t loc,
   build_zero_cst (TREE_TYPE (tem)));
 	}
 
-  /* Fold (X ^ Y) & Y as ~X & Y.  */
-  if (TREE_CODE (arg0) == BIT_XOR_EXPR
-	  && operand_equal_p (TREE_OPERAND (arg0, 1), arg1, 0))
-	{
-	  tem = fold_convert_loc (loc, type, TREE_OPERAND (arg0, 0));
-	  return fold_build2_loc (loc, BIT_AND_EXPR, type,
-			  fold_build1_loc (loc, BIT_NOT_EXPR, type, tem),
-			  fold_convert_loc (loc, type, arg1));
-	}
-  /* Fold (X ^ Y) & X as ~Y & X.  */
-  if (TREE_CODE (arg0) == BIT_XOR_EXPR
-	  && operand_equal_p (TREE_OPERAND (arg0, 0), arg1, 0)
-	  && reorder_operands_p (TREE_OPERAND (arg0, 1), arg1))
-	{
-	  tem = fold_convert_loc (loc, type, TREE_OPERAND (arg0, 1));
-	  return fold_build2_loc (loc, BIT_AND_EXPR, type,
-			  fold_build1_loc (loc, BIT_NOT_EXPR, type, tem),
-			  fold_convert_loc (loc, type, arg1));
-	}
-  /* Fold X & (X ^ Y) as X & ~Y.  */
-  if (TREE_CODE (arg1) == BIT_XOR_EXPR
-	  && operand_equal_p (arg0, TREE_OPERAND (arg1, 0), 0))
-	{
-	  tem = fold_convert_loc (loc, type, TREE_OPERAND (arg1, 1));
-	  return fold_build2_loc (loc, BIT_AND_EXPR, type,
-			  fold_convert_loc (loc, type, arg0),
-			  fold_build1_loc (loc, BIT_NOT_EXPR, type, tem));
-	}
-  /* Fold X & (Y ^ X) as ~Y & X.  */
-  if (TREE_CODE (arg1) == BIT_XOR_EXPR
-	  && operand_equal_p (arg0, TREE_OPERAND (arg1, 1), 0)
-	  && reorder_operands_p (arg0, TREE_OPERAND (arg1, 0)))
-	{
-	  tem = fold_convert_loc (loc, type, TREE_OPERAND (arg1, 0));
-	  return fold_build2_loc (loc, BIT_AND_EXPR, type,
-			  fold_build1_loc (loc, BIT_NOT_EXPR, type, tem),
-			  fold_convert_loc (loc, type, arg0));
-	}
-
   /* Fold (X * Y) & -(1 << CST) to X * Y if Y is a constant
  multiple of 1 << CST.  */
   if (TREE_CODE (arg1) == INTEGER_CST)
diff --git a/gcc/match.pd b/gcc/match.pd
index f6c5c07..bd33ea2 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -492,6 +492,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (if (wi::bit_not (@2) == @1)
   (bit_xor @0 @1)))
 
+/* Fold X & (X ^ Y) as X & ~Y.  */
+(simplify
+ (bit_and:c (convert? @0) (convert? (bit_xor:c @0 @1)))
+  (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
+   (convert (bit_and @0 (bit_not @1)
+
 /* X % Y is smaller than Y.  */
 (for cmp (lt ge)
  (simplify
@@ -1608,6 +1614,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (if (SCALAR_FLOAT_TYPE_P (type))
   (mult @0 { build_real (type, dconst2); })))
 
+/* Convert (A + A) * C -> A * 2 * C.  */
+(simplify
+ (mult (convert? (plus @0 @0)) INTEGER_CST@1)
+  (mult (convert @0) (mult { build_int_cst (TREE_TYPE (@1), 2); } @1)))
+
 (simplify
  (minus integer_zerop @1)
  (negate @1))

Offload configurations (was: [patch] New backend header reduction)

[Thomas Schwinge]

Hi!

On Fri, 30 Oct 2015 15:31:26 -0600, Jeff Law  wrote:
> On 10/30/2015 02:23 PM, Cesar Philippidis wrote:
> > On 10/30/2015 01:20 PM, Andrew MacLeod wrote:
> >> On 10/30/2015 02:09 PM, Andrew MacLeod wrote:
> >>> On 10/30/2015 01:56 PM, Cesar Philippidis wrote:
>  On 10/23/2015 12:24 PM, Jeff Law wrote:
> > On 10/23/2015 10:53 AM, Andrew MacLeod wrote:
> >
>  There's a little bit of fallout with this patch when building an
>  offloaded compiler for openacc. It looks like cgraph.c needs to include
>  context.h and varpool.c needs context.h and omp-low.h. There's a couple
>  of ifdef ENABLE_OFFLOADING which may have gone undetected with your
>  script.
> >>> If they are defined on the command line or some other way I couldn't
> >>> see with the targets I built, then that is the common case when that
> >>> happens.  I don't think I did any openacc builds. OR maybe I need
> >>> to add nvptx to my coverage builds. Perhaps that is best.
>  I've bootstrapped the attached patch for an nvptx/x86_64-linux target.
>  I'm still testing that toolchain. If the testing comes back clean, is
>  this patch OK for trunk?
> >> Ah, I see.  there is no nvptx target in config-list.mk, so it never got
> >> covered.

(Now there is, but that's not actually the problem here.)

> > Yeah, you need to build two separate compilers. Thomas posted some
> > directions here . You could
> > probably reproduce it with openmp and Intel's MIC emulation target too.
> Oh, there's something specific to the offloading support that needs 
> context.h, it's not the ptx port.  Duh.  Anyway, it'd still be good to 
> get standard builds of the nvptx backend into config-list.mk.
> 
> Not sure how painful it'd be to add the offloading path.

Shouldn't actually be difficult: you ought (untested) to be able to
configure with, for example,
--enable-offload-targets=nvptx-none,x86_64-intelmicemul-linux-gnu even if
not actually having built these offloading compilers.  (Due to a
"strange" requirement of Intel MIC offloading configuration, that "the
GCC build reference[s]/depend[s] on the Intel MIC offloading compiler's
installation directory (which [thus has to be] built and installed
earlier)",
,
this would fail later on, but as config-list.mk testing only builds the
"all-gcc" target, that's not a problem.)

So, maybe add to config-list.mk one x86_64-linux-gnu target with
--enable-offload-targets=[...] to cover code guarded by the
ENABLE_OFFLOADING preprocessor conditional.  And, maybe add one
nvptx-none or x86_64-intelmic-linux-gnu target with
--enable-as-accelerator-for=[something] to cover code guarded by the
ACCEL_COMPILER preprocessor conditional.

> This is a great example of why we're trying to minimize/eliminate 
> conditional compilation :-)

Agreed.  For the longer term, I think we should get rid of the (only)
handful of ENABLE_OFFLOADING and ACCEL_COMPILER preprocessor
conditionals.  For the former we'll have to find something, but the
latter could just be replaced with "if (flag_offload_abi !=
OFFLOAD_ABI_UNSET)" or similar, I think.


Grüße
 Thomas


signature.asc
Description: PGP signature

Re: [PATCH][ARM] PR target/67929 Tighten vfp3_const_double_for_bits checks

[Ramana Radhakrishnan]

>>>
>>> 2015-10-12  Kyrylo Tkachov  
>>>
>>> PR target/67929
>>> * gcc.target/arm/pr67929_1.c: New test.
> 
> This test fails when tested on hard-float targets, adding the
> following line to avoid testing it in such cases will fix the issue,
> but I wonder if there is a better dejaGNU directives sequence to do
> that.
> 
> /* { dg-skip-if "avoid conflicting multilib options" { *-*-*eabihf } {
> "*" } { "" } } */

No, not without further investigation into why the test is failing.

regards
Ramana

> 
> Cheers,
> Yvan
> 

Re: [1/3] OpenACC reductions

[Nathan Sidwell]

This is the core execution bits of OpenACC reductions.

We have a new internal fn 'IFN_GOACC_REDUCTION' and a new target hook 
goacc.reduction, to lower it on the target compiler.


The omp-low changes are:
1) remove all the existing OpenACC reduction handling

2) when emitting an openacc loop head/tail markers, intersperse that with 
reduction calls.  This emission has to search the context stack to see if 
there's an outer context also reducing the same variable.  In that case this 
instance ignores any reciever object info, because that's handled by the outer 
reduction.  Similarly for loops over multiple  axes -- inner axes ignore  the 
receiver  object info.


3) To deal with reductions at the outermost level, i.e.:
  #pragma acc parallel reduction (+:r)
  {
...
  }
we insert REDUCTION calls for a (dummy) gang level around the entire body.  Note 
these calls will lack the surrounding HEAD/TAIL and FORK/JOIN functions of a 
real partitioning level.


4) In the target compiler, we assign axes to the reduction calls in the same 
manner we assigned fork/join axes.


5) In the target compiler we then lower these calls to device-specific gimple. 
The default host behaviour essentially turns them all into copies, with possible 
loads from or stores to the receiver object.


One thing not handled by this patch are reductions of variables of reference 
type.  We have an implementation on gomp4 branch, but I suspect theres going to 
be some simplification we can do there following the openmp merge.  This only 
affected one testcase (which was (a) broken anyway and (b) working by accident).


nathan
2015-11-02  Nathan Sidwell  
	Cesar Philippidis  

	* internal-fn.def (GOACC_REDUCTION): New.
	* internal-fn.h (enum ifn_goacc_reduction_kind): New.
	* internal-fn.c (expand_GOACC_REDUCTION): New.
	* target.def (goacc.reduction): New OpenACC hook.
	* targhooks.h (default_goacc_reduction): Declare.
	* doc/tm.texi.in: Add TARGET_GOACC_REDUCTION.
	* doc/tm.texi: Rebuilt.
	* omp-low.c (oacc_get_reduction_array_id, oacc_max_threads,
	scan_sharing_clauses): Remove oacc reduction handling here.
	(lower_rec_input_clauses): Don't handle OpenACC reductions here.
	(oacc_lower_reduction_var_helper): Delete.
	(lower_oacc_reductions): New.
	(lower_reduction_clauses): Don't handle OpenACC reductions here.
	(lower_oacc_head_tail): Call lower_oacc_reductions.
	(oacc_gimple_assign, oacc_init_reduction_array,
	oacc_initialize_reduction_data, oacc_finalize_reduction_data,
	oacc_process_reduction_data): Delete.
	(lower_omp_target): Remove old OpenACC reduction handling.  Insert
	dummy OpenACC gang reduction for reductions at outer level.
	(oacc_loop_xform_head_tail): Transform IFN_GOACC_REDUCTION.
	(default_goacc_reduction): New.
	(execute_oacc_device_lower): Handle IFN_GOACC_REDUCTION.

Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi	(revision 229667)
+++ gcc/doc/tm.texi	(working copy)
@@ -5787,6 +5787,15 @@ gimple has been inserted before it, or t
 The default hook returns false, if there are no RTL expanders for them.
 @end deftypefn
 
+@deftypefn {Target Hook} void TARGET_GOACC_REDUCTION (gcall *@var{call})
+This hook is used by the oacc_transform pass to expand calls to the
+@var{GOACC_REDUCTION} internal function, into a sequence of gimple
+instructions.  @var{call} is gimple statement containing the call to
+the function.  This hook removes statement @var{call} after the
+expanded sequence has been inserted.  This hook is also responsible
+for allocating any storage for reductions when necessary.
+@end deftypefn
+
 @node Anchored Addresses
 @section Anchored Addresses
 @cindex anchored addresses
Index: gcc/doc/tm.texi.in
===
--- gcc/doc/tm.texi.in	(revision 229667)
+++ gcc/doc/tm.texi.in	(working copy)
@@ -4264,6 +4264,8 @@ address;  but often a machine-dependent
 
 @hook TARGET_GOACC_FORK_JOIN
 
+@hook TARGET_GOACC_REDUCTION
+
 @node Anchored Addresses
 @section Anchored Addresses
 @cindex anchored addresses
Index: gcc/internal-fn.c
===
--- gcc/internal-fn.c	(revision 229667)
+++ gcc/internal-fn.c	(working copy)
@@ -2045,6 +2045,14 @@ expand_GOACC_LOOP (gcall *stmt ATTRIBUTE
   gcc_unreachable ();
 }
 
+/* This is expanded by oacc_device_lower pass.  */
+
+static void
+expand_GOACC_REDUCTION (gcall *stmt ATTRIBUTE_UNUSED)
+{
+  gcc_unreachable ();
+}
+
 /* Routines to expand each internal function, indexed by function number.
Each routine has the prototype:
 
Index: gcc/internal-fn.def
===
--- gcc/internal-fn.def	(revision 229667)
+++ gcc/internal-fn.def	(working copy)
@@ -83,3 +83,6 @@ DEF_INTERNAL_FN (GOACC_DIM_POS, ECF_PURE
 
 /* OpenACC looping abstraction.  See internal-fn.h for usage.  */
 DEF_INTERNAL_FN 

Re: [3/3] OpenACC reductions

[Nathan Sidwell]

This patch are the initial set of tests.  The libgomp tests use an idiom of 
summing thread identifiers and then checking the expected set of threads 
participated.  They are all derived from the loop tests I recently added for the 
execution model itself.


The fortran test was duplicated in both the gfortran testsuite and the libgomp 
testsuite.   I deleted it from the former.  It was slightly bogus as it asked 
for a vector-length of 40, and appeared to be working by accident by not 
actually partitioning the loop.  I fixed that up and reworked it to avoid 
needing a reduction on a reference variable.  Reference handling will be a later 
patch.


nathan
2015-11-02  Nathan Sidwell  

	libgomp/
	* libgomp.oacc-c-c++-common/loop-red-g-1.c: New.
	* libgomp.oacc-c-c++-common/loop-red-gwv-1.c: New.
	* libgomp.oacc-c-c++-common/loop-red-v-1.c: New.
	* libgomp.oacc-c-c++-common/loop-red-v-2.c: New.
	* libgomp.oacc-c-c++-common/loop-red-w-1.c: New.
	* libgomp.oacc-c-c++-common/loop-red-w-2.c: New.
	* libgomp.oacc-c-c++-common/loop-red-wv-1.c: New.
	* libgomp.oacc-fortran/reduction-5.f90: Avoid reference var.

	gcc/testsuite/
	* gfortran.dg/goacc/reduction-2.f95: Delete.

Index: libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-g-1.c
===
--- libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-g-1.c	(revision 0)
+++ libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-g-1.c	(working copy)
@@ -0,0 +1,54 @@
+/* { dg-do run } */
+/* { dg-additional-options "-O2" */
+
+#include 
+
+#define N (32*32*32+17)
+int main ()
+{
+  int ix;
+  int ondev = 0;
+  int t = 0, h = 0;
+  
+#pragma acc parallel num_gangs(32) vector_length(32) copy(t) copy(ondev)
+  {
+#pragma acc loop gang  reduction (+:t)
+for (unsigned ix = 0; ix < N; ix++)
+  {
+	int val = ix;
+	
+	if (__builtin_acc_on_device (5))
+	  {
+	int g = 0, w = 0, v = 0;
+
+	__asm__ volatile ("mov.u32 %0,%%ctaid.x;" : "=r" (g));
+	__asm__ volatile ("mov.u32 %0,%%tid.y;" : "=r" (w));
+	__asm__ volatile ("mov.u32 %0,%%tid.x;" : "=r" (v));
+	val = (g << 16) | (w << 8) | v;
+	ondev = 1;
+	  }
+	t += val;
+  }
+  }
+
+  for (ix = 0; ix < N; ix++)
+{
+  int val = ix;
+  if(ondev)
+	{
+	  int g = ix / ((N + 31) / 32);
+	  int w = 0;
+	  int v = 0;
+
+	  val = (g << 16) | (w << 8) | v;
+	}
+  h += val;
+}
+  if (t != h)
+{
+  printf ("t=%x expected %x\n", t, h);
+  return 1;
+}
+  
+  return 0;
+}
Index: libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-gwv-1.c
===
--- libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-gwv-1.c	(revision 0)
+++ libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-gwv-1.c	(working copy)
@@ -0,0 +1,56 @@
+/* { dg-do run } */
+/* { dg-additional-options "-O2" */
+
+#include 
+
+#define N (32*32*32+17)
+int main ()
+{
+  int ix;
+  int ondev = 0;
+  int t = 0, h = 0;
+  
+#pragma acc parallel num_gangs(32) num_workers(32) vector_length(32) copy(t) copy(ondev)
+  {
+#pragma acc loop gang worker vector reduction(+:t)
+for (unsigned ix = 0; ix < N; ix++)
+  {
+	int val = ix;
+	
+	if (__builtin_acc_on_device (5))
+	  {
+	int g = 0, w = 0, v = 0;
+
+	__asm__ volatile ("mov.u32 %0,%%ctaid.x;" : "=r" (g));
+	__asm__ volatile ("mov.u32 %0,%%tid.y;" : "=r" (w));
+	__asm__ volatile ("mov.u32 %0,%%tid.x;" : "=r" (v));
+	val = (g << 16) | (w << 8) | v;
+	ondev = 1;
+	  }
+	t += val;
+  }
+  }
+
+  for (ix = 0; ix < N; ix++)
+{
+  int val = ix;
+  if(ondev)
+	{
+	  int chunk_size = (N + 32*32*32 - 1) / (32*32*32);
+	  
+	  int g = ix / (chunk_size * 32 * 32);
+	  int w = ix / 32 % 32;
+	  int v = ix % 32;
+
+	  val = (g << 16) | (w << 8) | v;
+	}
+  h += val;
+}
+  if (t != h)
+{
+  printf ("t=%x expected %x\n", t, h);
+  return 1;
+}
+  
+  return 0;
+}
Index: libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-v-1.c
===
--- libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-v-1.c	(revision 0)
+++ libgomp/testsuite/libgomp.oacc-c-c++-common/loop-red-v-1.c	(working copy)
@@ -0,0 +1,56 @@
+/* { dg-do run } */
+/* { dg-additional-options "-O2" */
+
+#include 
+
+#define N (32*32*32+17)
+
+int main ()
+{
+  int ix;
+  int ondev = 0;
+  int t = 0,  h = 0;
+
+#pragma acc parallel vector_length(32) copy(t) copy(ondev)
+  {
+#pragma acc loop vector reduction (+:t)
+for (unsigned ix = 0; ix < N; ix++)
+  {
+	int val = ix;
+	
+	if (__builtin_acc_on_device (5))
+	  {
+	int g = 0, w = 0, v = 0;
+
+	__asm__ volatile ("mov.u32 %0,%%ctaid.x;" : "=r" (g));
+	__asm__ volatile ("mov.u32 %0,%%tid.y;" : "=r" (w));
+	__asm__ volatile ("mov.u32 %0,%%tid.x;" : "=r" (v));
+	val = (g << 16) | (w << 8) | v;
+	ondev = 1;
+	  }
+	t += val;
+  }
+  }
+
+  for (ix = 0; ix < N; ix++)
+{

Re: [PATCH] Fix warning in tree-diagnostic.h.

[Jeff Law]

On 11/02/2015 06:26 AM, Dominik Vogt wrote:

The attached patch fixes the annoying warnings generated by
diagnostic_set_last_function.

Can this be committed?
Can you point out what warning you're fixing?  Inline or pointer to a 
build log would be fine.


jeff

Re: [PATCH] Pr fortran/68153 -- Enhance checking of RESHAPE shape arg

[Dominique d'Humières]

Steve,

The error for the test

program p
   integer, parameter :: sh(2) = [2, 2]
   integer, parameter :: a(2,2) = reshape([1, 2, 3, 4], -sh)
   print *, a
end

is

pr68153_2.f90:2:34:

integer, parameter :: sh(2) = [2, 2]
  1
Error: 'shape' argument of 'reshape' intrinsic at (1) has negative element (-2)

I am pretty sure that some day a user will complain about a confusing error 
message!-(

Dominique

Re: [2/3] OpenACC reductions

[Nathan Sidwell]

This patch contains the PTX backend pieces of OpenACC reduction handling.  These 
functions are lowered to gimple, using a couple of PTX-specific builtins for 
some functionality.  Expansion to RTL introduced no new patterns.


We need 3 different schemes for the 3 different partitioning axes, but 
fortunately there is still a lot of commonality.


For the gang level, there is usually a receiver object (if there isn't, the 
program is not well formed).  Each gang of execution has it's own instance of 
the reduction variable, which it initializes with an operator-specific init 
value (a zero or all-bits of appropriate type).  To merge, we use a lockless[1] 
update scheme on the receiver object.  Thus, setup and teardown are simply 
copies of local var.  INIT is a constant initializer and FINI is the update.


For worker level, we need to allocate a buffer in .shared memory local to the 
CTA.  This buffer is reused for each set of reductions, so we only need to size 
it to the maximum value across the program, in a similar manner to the worker 
propagation buffer.  (Unfortunately both need to be live concurrently, so we 
can't share them).


At the setup call, we copy the incoming value (from receiver object or 
LOCAL_VAR) to a slot in the buffer.  At the init call, we initialize to the 
operator-specific value.  At the fini call we do a  lockless update on the 
worker reduction buffer slot.  At the teardown call we read from the reduction 
buffer and possibly write to the receiver object.


The worker reduction buffer slots are the OFFSET argument of the reduction 
calls.  This is the only use we make of this operand for PTX.


For vector level, we  can use shuffle instructions to copy from another vector 
and arrange to use a  binary-tree of combinations to provide a final value.  The 
setup call reads the reciever object, if there is  one.  The init call 
initializes all but vector-zero with an operator-specific value.  Vector zero 
carries the incoming value.  The finalize call expands to the binary tree of 
shuffles.  For PTX this is 5 steps[2].  The teardown call writes back to the 
receiver object, if there is one.


[1] We use a lockless update for gang and worker level that looks somewhat like:

actual = INIT_VAL  (OP)
do
  guess = actual;
  result = guess OP myval
  actual = atomic_cmp_exchange (*REF_TO_RES, guess, result)
while (actual != guess)

The reason for this scheme is that a locking scheme doesn't work across workers 
-- it deadlocks apparently due to resource starvation.  The above is guaranteed 
to make progress.  Further it is easier to optimize to  target-specific 
atomics, should OP be supported directly.


[2] We have to emit an unrolled loop for this tree.   If it were a loop, we'd 
need to mark the loop branch as unified, and don't have a mechanism for that at 
the gimple level.  I have some ideas as to how to do that, but not had time to 
investigate.  We're fixing the vector_length to 32 in this manner, which is what 
other compilers appear to do anyway.


Bernd, I think the builtin fn bits you originally wrote got completely rewritten 
by me several times.


nathan
2015-11-02  Nathan Sidwell  
	Cesar Philippidis  

	* config/nvptx/nvptx.c: Include gimple headers.
	(worker_red_size, worker_red_align, worker_red_name,
	worker_red_sym): New.
	(nvptx_option_override): Initialize worker reduction buffer.
	(nvptx_file_end): Write out worker reduction buffer var.
	(nvptx_expand_shuffle, nvptx_expand_worker_addr,
	nvptx_expand_cmp_swap): New builtin expanders.
	(enum nvptx_builtins): New.
	(nvptx_builtin_decls): New.
	(nvptx_builtin_decl, nvptx_init_builtins, nvptx_expand_builtin): New
	(PTX_VECTOR_LENGTH, PTX_WORKER_LENGTH): New.
	(nvptx_get_worker_red_addr, nvptx_generate_vector_shuffle,
	nvptx_lockless_update): New helpers.
	(nvptx_goacc_reduction_setup, nvptx_goacc_reduction_init,
	nvptx_goacc_reduction_fini, nvptx_goacc_reduction_teaddown): New.
	(nvptx_goacc_reduction): New.
	(TARGET_INIT_BUILTINS, TARGET_EXPAND_BUILTIN,
	TARGET_BUILTIN_DECL): Override.
	(TARGET_GOACC_REDUCTION): Override.

Index: gcc/config/nvptx/nvptx.c
===
--- gcc/config/nvptx/nvptx.c	(revision 229667)
+++ gcc/config/nvptx/nvptx.c	(working copy)
@@ -57,6 +57,15 @@
 #include "omp-low.h"
 #include "gomp-constants.h"
 #include "dumpfile.h"
+#include "internal-fn.h"
+#include "gimple-iterator.h"
+#include "stringpool.h"
+#include "tree-ssa-operands.h"
+#include "tree-ssanames.h"
+#include "gimplify.h"
+#include "tree-phinodes.h"
+#include "cfgloop.h"
+#include "fold-const.h"
 
 /* This file should be included last.  */
 #include "target-def.h"
@@ -98,6 +107,14 @@ static unsigned worker_bcast_align;
 #define worker_bcast_name "__worker_bcast"
 static GTY(()) rtx worker_bcast_sym;
 
+/* Size of buffer needed for worker reductions.  This has to be
+   distinct from the worker broadcast array, as both 

Re: [gomp4.1] Handle new form of #pragma omp declare target

[Ilya Verbin]

On Fri, Oct 30, 2015 at 20:12:25 +0100, Jakub Jelinek wrote:
> On Fri, Oct 30, 2015 at 08:44:07PM +0300, Ilya Verbin wrote:
> > On Wed, Oct 28, 2015 at 00:11:03 +0300, Ilya Verbin wrote:
> > > On Fri, Jul 17, 2015 at 15:05:59 +0200, Jakub Jelinek wrote:
> > > > As the testcases show, #pragma omp declare target has now a new form 
> > > > (well,
> > > > two; with some issues on it pending), where it is used just as a single
> > > > declarative directive rather than a pair of them and allows marking
> > > > vars and functions by name as "omp declare target" vars/functions 
> > > > (which the
> > > > middle-end etc. already handles),
> > > 
> > > There is an issue - such variables are not added to the offloading tables,
> > > because when varpool_node::get_create is called for the first time, the 
> > > variable
> > > doesn't yet have "omp declare target" attribute, and when it's called for 
> > > the
> > > second time, it just returns existing node.  Functions also aren't marked 
> > > as
> > > offloadable.  I tried to fix this by moving the code from
> > > varpool_node::get_create to varpool_node::finalize_decl, but it helped 
> > > only C,
> > > but doesn't fix C++.  Therefore, I decided to iterate through all 
> > > functions and
> > > variables, like in the patch bellow.  But it doesn't work for static vars,
> > > declared inside functions, because they do not appear in symtab :(
> > 
> > Ping?  Where should I set node->offloadable for "omp declare target to 
> > (list)"
> > functions, global and static vars?
> 
> Perhaps already somewhere in the FEs?  I mean, when the varpool node is
> created after the decl has that attribute, it already should set offsetable
> itself, so perhaps when adding the attribute check if corresponding varpool
> node exists already (but don't create it) and if yes, set offloadable?

Here is the patch.
make check RUNTESTFLAGS=gomp.exp and check-target-libgomp passed.
OK for gomp-4_5-branch?


gcc/c/
* c-parser.c: Include context.h.
(c_parser_omp_declare_target): If decl has "omp declare target" or
"omp declare target link" attribute, and cgraph or varpool node already
exists, then set corresponding flags.
gcc/cp/
* parser.c: Include context.h.
(cp_parser_omp_declare_target): If decl has "omp declare target" or
"omp declare target link" attribute, and cgraph or varpool node already
exists, then set corresponding flags.
libgomp/
* testsuite/libgomp.c++/target-13.C: Add global variable with "omp
declare target ()" directive, use it in foo.
* testsuite/libgomp.c/target-28.c: Likewise.


diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index a169457..049417c 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -67,6 +67,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gomp-constants.h"
 #include "c-family/c-indentation.h"
 #include "gimple-expr.h"
+#include "context.h"
 
 
 /* Initialization routine for this file.  */
@@ -15600,7 +15601,22 @@ c_parser_omp_declare_target (c_parser *parser)
  continue;
}
   if (!at1)
-   DECL_ATTRIBUTES (t) = tree_cons (id, NULL_TREE, DECL_ATTRIBUTES (t));
+   {
+ symtab_node *node = symtab_node::get (t);
+ DECL_ATTRIBUTES (t) = tree_cons (id, NULL_TREE, DECL_ATTRIBUTES (t));
+ if (node != NULL)
+   {
+ node->offloadable = 1;
+#ifdef ENABLE_OFFLOADING
+ g->have_offload = true;
+ if (is_a  (node))
+   {
+ vec_safe_push (offload_vars, t);
+ node->force_output = 1;
+   }
+#endif
+   }
+   }
 }
 }
 
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index a374e6c..de77a4b 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -49,6 +49,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "omp-low.h"
 #include "gomp-constants.h"
 #include "c-family/c-indentation.h"
+#include "context.h"
 
 
 /* The lexer.  */
@@ -34773,7 +34774,22 @@ cp_parser_omp_declare_target (cp_parser *parser, 
cp_token *pragma_tok)
  continue;
}
   if (!at1)
-   DECL_ATTRIBUTES (t) = tree_cons (id, NULL_TREE, DECL_ATTRIBUTES (t));
+   {
+ symtab_node *node = symtab_node::get (t);
+ DECL_ATTRIBUTES (t) = tree_cons (id, NULL_TREE, DECL_ATTRIBUTES (t));
+ if (node != NULL)
+   {
+ node->offloadable = 1;
+#ifdef ENABLE_OFFLOADING
+ g->have_offload = true;
+ if (is_a  (node))
+   {
+ vec_safe_push (offload_vars, t);
+ node->force_output = 1;
+   }
+#endif
+   }
+   }
 }
 }
 
diff --git a/libgomp/testsuite/libgomp.c++/target-13.C 
b/libgomp/testsuite/libgomp.c++/target-13.C
index 376672d..5279ac0 100644
--- a/libgomp/testsuite/libgomp.c++/target-13.C
+++ b/libgomp/testsuite/libgomp.c++/target-13.C
@@ -1,11 +1,14 @@
 extern "C" void abort 

Re: [PATCH] New attribute to create target clones

[Jeff Law]

On 11/02/2015 07:50 AM, Evgeny Stupachenko wrote:

Yes, that is exactly what should fix the tests.
Unfortunately I don't have access to darwin machine right now.
Can you please test if the patch (attached) fixes the tests?

gcc/
 * multiple_target.c (create_dispatcher_calls): Add target check
 on ifunc.
 (create_target_clone): Change assembler name for versioned 
declarations.

gcc/testsuite
 * gcc.dg/mvc1.c: Add dg-require-ifunc condition.
 * gcc.dg/mvc4.c: Ditto.
 * gcc.dg/mvc5.c: Ditto.
 * g++.dg/ext/mvc1.C: Ditto.
 * g++.dg/ext/mvc4.C: Ditto.
 * gcc.dg/mvc7.c: Add dg-require-ifunc condition and checks on resolver.


OK.

jeff

Re: [PR66326, Cilk+] Fix FP exception occured in CilkPlus runtime

[Jeff Law]

On 11/02/2015 01:10 PM, Zamyatin, Igor wrote:

Hi!

This patches fixes FP exception that comes from CilkPlus runtime.

Bootstrapped and regtested for x86_64.
Is it ok for trunk?

Thanks,
Igor

Changelog:

libcilkrts

2015-10-30  Igor Zamyatin  

PR target/66326
* untime/config/x86/os-unix-sysdep.c (sysdep_save_fp_ctrl_state):
Use fnstcw instead fnstsw.


testsuite

2015-10-30  Igor Zamyatin  

PR target/66326
* g++.dg/cilk-plus/CK/pr66326.cc: New test.

OK.
jeff

Re: [ping] Fix PR debug/66728

[Richard Sandiford]

Mike Stump  writes:
> On Nov 2, 2015, at 8:29 AM, Richard Sandiford  
> wrote:
>>   switch (GET_CODE (rtl))
>> {
>> case CONST_INT:
>> -  {
>> -HOST_WIDE_INT val = INTVAL (rtl);
>> +  if (mode != BLKmode)
>
> This changes BLKmode for CONST_INT, but I didn’t see this discussed.  I
> didn’t see a test case?  I’d like to think that BLKmode things here
> would be fine.  I think they would be use for 1024 bit things that are
> representable in 20 bits, for example.

This was:

  ... Sometimes structure decls
  have BLKmode but are assigned an integer-mode rtl (e.g. when passing
  3-byte structures by value to functions).
  [...]
  loc_descriptor refuses to use CONST_INT for BLKmode decls (which aren't
  actually integers at the source level).  That seems like the right
  behaviour, so this patch does that for add_const_value_attribute too.
  It asserts that the mode is otherwise sensible for both CONST_INT
  and CONST_WIDE_INT.  Asserting for CONST_INT isn't strictly necessary
  but means that the assumption will get much more coverage than asserting
  only for CONST_WIDE_INT does.

Integer types always have an integer mode, not BLKmode.  E.g.
layout_type has:

case BOOLEAN_TYPE:
case INTEGER_TYPE:
case ENUMERAL_TYPE:
  SET_TYPE_MODE (type,
 smallest_mode_for_size (TYPE_PRECISION (type), MODE_INT));

where the smallest_mode_for_size is guaranteed to return something
that isn't BLKmode (or VOIDmode).

The BLKmodes are for non-integer things that nevertheless get passed
as integers.  I don't think debuggers would be expecting an integer
DIE to be used for them.  (loc_descriptor already punts in that case.)

> A value that is 1 (representable
> in 20 bits) can be trivially communicated the debugger.  The existing
> add_AT_unsigned I think can represent them, no?  Similarly for wide-int
> BLKmode support.  I think the real problem is simply the precision 0
> part.  In the CONST_INT and CONST_DOUBLE there is no code that handled
> precision 0, and there is no code in the wide-int case either.  From
> wide-int.h:
>
>   The precision and length of a wide_int are always greater than 0.
>
> If is was 0, then we have failed.  When that bug is fixed, then the
> precision won’t be 0 and the existing code will work.  Where is the 0
> first generated, and from what?

It's generated from:

case CONST_WIDE_INT:
  add_AT_wide (die, DW_AT_const_value,
  std::make_pair (rtl, GET_MODE (rtl)));
  return true;

where the precision is evaluated as:

  inline unsigned int
  wi::int_traits ::get_precision (const rtx_mode_t )
  {
return GET_MODE_PRECISION (x.second);
  }

GET_MODE (rtl) is always VOIDmode and the precision of VOIDmode is 0,
so the precision of the wide_int passed to add_AT_wide is always 0.

Like CONST_INT, the "real" mode of a CONST_WIDE_INT is determined by
context rather than being stored in the rtx itself.  The point of the
patch is to use that mode instead of VOIDmode in the make_pair.

Thanks,
Richard

Re: libgo patch committed: Update to Go 1.5 release

[Lynn A. Boger]

I'll try it  That was the only error I hit with the go and libgo 
tests with Go 1.5.


I assume there will be a different number for the libgo.so for Go 1.5?

On 11/02/2015 02:23 PM, Ian Lance Taylor wrote:

On Mon, Nov 2, 2015 at 7:39 AM, Lynn A. Boger
 wrote:

I see this error when building gccgo from trunk on ppc64le and running the
libgo tests:

exec_unix_test.go:174:43: error: reference to undefined identifier
'syscall.TIOCGPGRP'
   errno := syscall.Ioctl(tty.Fd(), syscall.TIOCGPGRP,
uintptr(unsafe.Pointer()))
^
FAIL: syscall
make[3]: *** [syscall/check] Error 1

I have committed this patch which I hope will fix this problem.

Ian

Re: [PATCH] add self-tuning to x86 hardware fast path in libitm

[Andi Kleen]

Nuno Diegues  writes:

> Hello everyone,
>
> gently pinging to bring this back to life given the last patch I emailed.

The patch is fine for me, but I cannot approve it.
-Andi

[PING] [PATCH] clarify documentation of -Q --help=optimizers

[Martin Sebor]

Ping. Thanks in advance for a review.

On 10/22/2015 08:12 PM, Martin Sebor wrote:

[Sending to the right list this time]

The documentation of the -Q --help=optimizers options leads some
to expect that when options are reported as enabled imply the
corresponding optimization will take place.  (See the following
question on gcc-help:
https://gcc.gnu.org/ml/gcc-help/2015-10/msg00133.html)

The patch below tries to make it clear that that's not always
the case.

Martin

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 4f89fa1..337639e 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1506,6 +1506,16 @@ options, an indication is given as to whether the
option is enabled,
  disabled or set to a specific value (assuming that the compiler
  knows this at the point where the @option{--help=} option is used).

+It's important to note that when a given optimization option is
+enabled, either explicitly on the command line or implicitly, whether
+or not the optimization it controls will be performed during an
+invocation of the compiler may depend on other options.  This is
+so because many options control various finer aspects of other more
+general optimizations that must be enabled in order for the former
+option to have any effect.  There is currently no command line
+interface to determine such dependencies between optimization
+options.
+
  Here is a truncated example from the ARM port of @command{gcc}:

  @smallexample

Re: [patch] gcc5 FreeBSD rs6000 PIE handling

[Andreas Tobler]

On 31.10.15 22:28, Andreas Tobler wrote:

Hi,

I forgot to adapt the pie bits for powerpc64 FreeBSD back in May when I
committed the pie support for FreeBSD.
Without the below patch I'm not able to bootstrap a current gcc on
FreeBSD powerpc64.

The patch is against gcc-5, the patch for trunk will follow.

If there are no objections I'll commit this bit in the next days. It is
FreeBSD only.



Committed: r229679

Andreas



2015-10-31  Andreas Tobler  

* config/rs6000/freebsd64.h (ASM_SPEC32): Adapt spec to handle PIE
executables.

Index: gcc/config/rs6000/freebsd64.h
===
--- gcc/config/rs6000/freebsd64.h   (revision 229623)
+++ gcc/config/rs6000/freebsd64.h   (working copy)
@@ -130,7 +130,7 @@
   #define  LINK_OS_FREEBSD_SPEC
"%{m32:%(link_os_freebsd_spec32)}%{!m32:%(link_os_freebsd_spec64)}"

   #define ASM_SPEC32 "-a32 \
-%{mrelocatable} %{mrelocatable-lib} %{fpic:-K PIC} %{fPIC:-K PIC} \
+%{mrelocatable} %{mrelocatable-lib} %{fpic|fpie|fPIC|fPIE:-K PIC} \
   %{memb} %{!memb: %{msdata=eabi: -memb}} \
   %{!mlittle: %{!mlittle-endian: %{!mbig: %{!mbig-endian: \
   %{mcall-freebsd: -mbig} \

Re: [PR68001, CilkPlus] Fix for PR68001

[Jeff Law]

On 11/02/2015 01:08 PM, Zamyatin, Igor wrote:

Hi!

This patch attempts to enhance error diagnostic in case of CilkPlus and fixes 
PR68001.

Bootstrapped and regtested for x86_64.
Is it ok for trunk?

Thanks,
Igor

ChangeLog:

c-family

2015-11-02  Igor Zamyatin  
k
PR c++/68001
* c-gimplify.c (c_gimplify_expr): Stop the process if see an error.
* cilk.c (recognize_spawn): Determine location in a more precise
way.

cp

2015-11-02  Igor Zamyatin  

PR c++/68001
* cp-gimplify.c (cp_gimplify_expr): Stop the process if see an error.

testsuite

2015-11-02  Igor Zamyatin  

PR c++/68001
* g++.dg/cilk-plus/CK/pr68001.cc: New test.


diff --git a/gcc/c-family/c-gimplify.c b/gcc/c-family/c-gimplify.c
index 92987b5..5b173d5 100644
--- a/gcc/c-family/c-gimplify.c
+++ b/gcc/c-family/c-gimplify.c
@@ -283,15 +283,16 @@ c_gimplify_expr (tree *expr_p, gimple_seq *pre_p 
ATTRIBUTE_UNUSED,

  case CILK_SPAWN_STMT:
gcc_assert
-   (fn_contains_cilk_spawn_p (cfun)
-&& cilk_detect_spawn_and_unwrap (expr_p));
+   (fn_contains_cilk_spawn_p (cfun)
+   && cilk_detect_spawn_and_unwrap (expr_p));

If you're trying to fix the formatting here, I think it ought to look like:

  gcc_assert (fn_contains_cilk_spawn_p (cfun)
  && cilk_detect_spawn_and_unwrap (expr_p));

ie, go ahead and start the expression on the same line as the 
gcc_assert, line break before the &&, and indent the && just inside the 
open-paren.





+static tree
+contains_cilk_spawn_stmt_walker (tree *tp, int *, void *);
  static void extract_free_variables (tree, struct wrapper_data *,
enum add_variable_type);
Please format in the same way the call to extract_free_variables is 
formatted.




@@ -733,16 +736,17 @@ cp_gimplify_expr (tree *expr_p, gimple_seq *pre_p, 
gimple_seq *post_p)

break;

  case CILK_SPAWN_STMT:
-  gcc_assert
-   (fn_contains_cilk_spawn_p (cfun)
-&& cilk_detect_spawn_and_unwrap (expr_p));
+  gcc_assert
+   (fn_contains_cilk_spawn_p (cfun)
+   && cilk_detect_spawn_and_unwrap (expr_p));

Same formatting nit as c-gimplify.c


With the formatting nits fixed, this is fine.
jeff

Re: [PATCH 3/4] bb-reorder: Add -freorder-blocks-algorithm= and wire it up

[Segher Boessenkool]

On Mon, Nov 02, 2015 at 02:38:33PM +, Alan Lawrence wrote:
> On 23/09/15 23:06, Segher Boessenkool wrote:
> >This adds an -freorder-blocks-algorithm=[simple|stc] flag, with "simple"
> >as default.  For -O2 and up (except -Os) it is switched to "stc" instead.
> >Targets that never want STC can override this.  This changes 
> >-freorder-blocks
> >to be on at -O1 and up (was -O2 and up).
> >
> >In effect, the changes are for -O1 (which now gets "simple" instead of
> >nothing), -Os (which now gets "simple" instead of "stc", since STC results
> >in much bigger code), and for targets that wish to never use STC (not in
> >this patch though).
> >
> >
> >2015-09-23   Segher Boessenkool  
> >
> > * bb-reorder.c (reorder_basic_blocks): Use the algorithm selected
> > with flag_reorder_blocks_algorithm.
> > * common.opt (freorder-blocks-algorithm=): New flag.
> > (reorder_blocks_algorithm): New enum.
> > * flag-types.h (reorder_blocks_algorithm): New enum.
> > * opts.c (default_options_table): Use -freorder-blocks at -O1 and up,
> > and -freorder-blocks-algorithm=stc at -O2 and up (not at -Os).
> 
> I'm a bit puzzled as to why nobody else has been seeing this, as it's been 
> happening to me as part of building gcc on x86_64, but since this patch 
> I've been seeing an ICE in vec::operator[] in reorder_basic_blocks_simple, 
> building libitm/beginend.cc. Preprocessed source attached, command line 
> reduced to:
> 
> $ /work/alalaw01/build/./gcc/xg++ -B/work/alalaw01/build/./gcc/ -mrtm -O1 
> -g -m32 -c temp.ii
> /work/alalaw01/src/gcc/libitm/beginend.cc: In static member function 
> ‘static uint32_t GTM::gtm_thread::begin_transaction(uint32_t, const 
> gtm_jmpbuf*)’:
> /work/alalaw01/src/gcc/libitm/beginend.cc:400:1: internal compiler error: 
> in operator[], at vec.h:714
>  }
>  ^
> 0x1310783 vec::operator[](unsigned int)
>   /work/alalaw01/src/gcc/gcc/vec.h:714
> 0x1310783 reorder_basic_blocks_simple
>   /work/alalaw01/src/gcc/gcc/bb-reorder.c:2322

That seems to be happening in the FOR_EACH_BB_FN then?  Or one of the
EDGE_SUCCs?  I cannot match up that line # with anything.  Both cases
suggest things are broken before already.

> 0x1310783 reorder_basic_blocks
>   /work/alalaw01/src/gcc/gcc/bb-reorder.c:2450
> 0x1310783 execute
>   /work/alalaw01/src/gcc/gcc/bb-reorder.c:2551
> 
> Compilation succeeds at -O2 (instead of -O1).

reorder_basic_blocks_simple isn't used at -O2 (it uses STC instead).

I'll have a look at this wednesday.


Segher

Re: [v3 PATCH] Make the default constructors of tuple and pair conditionally explicit.

[Paolo Carlini]

Hi,

On 11/02/2015 09:20 PM, Ville Voutilainen wrote:

On 2 November 2015 at 21:20, Paolo Carlini  wrote:

Can we follow the terse style already used elsewhere (eg,
__is_direct_constructible_new_safe) thus directly inherit from __and_ and
avoid explicit integral_constant? Otherwise patch looks good to me.


Sure. Tested again on Linux-PPC64, tests adjusted due to line changes,
Changelog entry updated to have a correct date on it.
Great, thanks a lot. Thinking more about this detail, I wonder if we 
should therefore apply the below too? Anything I'm missing?


Paolo.

///


Index: type_traits
===
--- type_traits (revision 229652)
+++ type_traits (working copy)
@@ -715,7 +715,7 @@
   /// is_unsigned
   template
 struct is_unsigned
-: public __and_, __not_>>::type
+: public __and_, __not_>>
 { };
 
 
@@ -744,7 +744,7 @@
 
   template
 struct __is_array_unknown_bounds
-: public __and_, __not_>>::type
+: public __and_, __not_>>
 { };
 
   // In N3290 is_destructible does not say anything about function
@@ -862,7 +862,7 @@
   template
 struct __is_default_constructible_atom
 : public __and_<__not_>,
-__is_default_constructible_impl<_Tp>>::type
+__is_default_constructible_impl<_Tp>>
 { };
 
   template::value>
@@ -877,7 +877,7 @@
 struct __is_default_constructible_safe<_Tp, true>
 : public __and_<__is_array_known_bounds<_Tp>,
__is_default_constructible_atom::type>>::type
+  remove_all_extents<_Tp>::type>>
 { };
 
   template
@@ -957,7 +957,7 @@
   template
 struct __is_direct_constructible_new_safe
 : public __and_,
-__is_direct_constructible_impl<_Tp, _Arg>>::type
+__is_direct_constructible_impl<_Tp, _Arg>>
 { };
 
   template
@@ -1029,7 +1029,7 @@
 : public __and_<__is_static_castable<_Arg, _Tp>,
 __not_<__or_<__is_base_to_derived_ref<_Arg, _Tp>,
  __is_lvalue_to_rvalue_ref<_Arg, _Tp>
-   >>>::type
+   >>>
 { };
 
   template
@@ -1144,7 +1144,7 @@
 struct __is_nt_default_constructible_impl<_Tp, true>
 : public __and_<__is_array_known_bounds<_Tp>,
__is_nt_default_constructible_atom::type>>::type
+  remove_all_extents<_Tp>::type>>
 { };
 
   template
@@ -1156,7 +1156,7 @@
   template
 struct is_nothrow_default_constructible
 : public __and_,
-__is_nt_default_constructible_impl<_Tp>>::type
+__is_nt_default_constructible_impl<_Tp>>
 { };
 
   template
@@ -1179,7 +1179,7 @@
   template
 struct is_nothrow_constructible
 : public __and_,
-   __is_nt_constructible_impl<_Tp, _Args...>>::type
+   __is_nt_constructible_impl<_Tp, _Args...>>
 { };
 
   template::value>
@@ -1285,7 +1285,7 @@
   template
 struct is_nothrow_assignable
 : public __and_,
-   __is_nt_assignable_impl<_Tp, _Up>>::type
+   __is_nt_assignable_impl<_Tp, _Up>>
 { };
 
   template::value>
@@ -1328,7 +1328,7 @@
   template
 struct is_trivially_constructible
 : public __and_, integral_constant>::type
+   __is_trivially_constructible(_Tp, _Args...)>>
 { };
   
   /// is_trivially_default_constructible
@@ -1342,7 +1342,7 @@
 struct is_trivially_copy_constructible
 : public __and_, 
integral_constant>::type
+   __is_trivially_constructible(_Tp, const _Tp&)>>
 { };
   
   /// is_trivially_move_constructible
@@ -1350,7 +1350,7 @@
 struct is_trivially_move_constructible
 : public __and_, 
integral_constant>::type
+   __is_trivially_constructible(_Tp, _Tp&&)>>
 { };
 
   /// is_trivially_assignable
@@ -1358,7 +1358,7 @@
 struct is_trivially_assignable
 : public __and_, 
integral_constant>::type
+   __is_trivially_assignable(_Tp, _Up)>>
 { };
 
   /// is_trivially_copy_assignable
@@ -1366,7 +1366,7 @@
 struct is_trivially_copy_assignable
 : public 

Re: [patch] gcc6 FreeBSD rs6000 PIE handling

[Andreas Tobler]

On 31.10.15 22:34, Andreas Tobler wrote:

Hi,

this is the part for gcc trunk. As mentioned in the previous mail (same
subject for gcc5) I forgot to adapt the PIE bits for FreeBSD powerpc64.

The patch below lets me bootstrap a current gcc with itself.

I'll commit this part if there are no objections.


Committed: r229680

Andreas


2015-10-31  Andreas Tobler  

* config/rs6000/freebsd64.h (ASM_SPEC32): Adust spec to handle
PIE executables.

Index: rs6000/freebsd64.h
===
--- rs6000/freebsd64.h  (revision 229634)
+++ rs6000/freebsd64.h  (working copy)
@@ -130,7 +130,7 @@
   #define  LINK_OS_FREEBSD_SPEC
"%{m32:%(link_os_freebsd_spec32)}%{!m32:%(link_os_freebsd_spec64)}"

   #define ASM_SPEC32 "-a32 \
-%{mrelocatable} %{mrelocatable-lib} %{" FPIC_SPEC ":-K PIC} \
+%{mrelocatable} %{mrelocatable-lib} %{" FPIE_OR_FPIC_SPEC ":-K PIC} \
   %{memb} %{!memb: %{msdata=eabi: -memb}} \
   %{!mlittle: %{!mlittle-endian: %{!mbig: %{!mbig-endian: \
   %{mcall-freebsd: -mbig} \

Re: Try to update dominance info in tree-call-cdce.c

[Jeff Law]

On 11/02/2015 08:53 AM, Richard Sandiford wrote:

Steven Bosscher  writes:

On Fri, Oct 30, 2015 at 2:11 PM, Richard Sandiford
 wrote:

Is the split_block change really so bad?


IMHO: Yes.


Fair enough :-)
I tend to agree.  If the caller needs a more complex control flow and 
dominance/post-dominance relationship set up, then it seems like it 
belongs in the caller.


If there's enough commonality in cases where the caller is going to do 
something more complex with the CFG, then perhaps there could be a 
function to (as Richi suggests) create diamonds, half diamonds or 
something else commonly needed.




I just thought that the cfg was in practice never going to stay in the
state that it is on return from split_block.  The caller is bound to
add (at least) another edge somewhere.
Perhaps.  But that functionality (assuming it's common) can be layered 
on top of split_block pretty easily it seems.





Here's a version that works with split_block rather than against it.
Tested on x86_64-linux-gnu, arm-linux-gnueabi and aarch64-linux-gnu.
OK to install?

Thanks,
Richard


gcc/
* tree-call-cdce.c (shrink_wrap_one_built_in_call): Try to update
the dominance info; free it if we can't.
(pass_call_cdce::execute): Don't free the dominance info here.

OK.

Thoughts on emitting something into the dump file in tree-call-cdce.c 
which indicates when the dominators/post-dominators are invalidated?  Or 
better yet, put it in free_dominance_info.  Then we could have a 
testcase which verifies that we're updating rather than recomputing in 
the case which led to this change, and in cases where there's EH bits to 
update that we recompute.


Jeff

Re: [PATCH 1/2] s/390: Implement "target" attribute.

[Dominik Vogt]

(@Uli: I'd like to hear your opinion on this issue.
Original message:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03403.html).

On Fri, Oct 30, 2015 at 03:09:39PM +0100, Andreas Krebbel wrote:
> Why do we need x_s390_arch_specified and x_s390_tune_specified?  You
> should be able to use opts_set->x_s390_arch and opts_set->x_s390_tune
> instead? (patch attached, your tests keep working with that change).

The idea was that -mtune on the command line is *not* overridden
by the "arch" target attribute.  This would allow to change the
architecture for a specific function and keep the -mtune= option
from the command line.  But as a matter of fact, the current patch
doesn't do it either (bug?).

Example:

  -- foo.c --
  __attribute__ ((target("arch=z1EC12")))
  void foo(void) { ... }
  -- foo.c --

  $ gcc -c -mtune=z13 foo.c -o foo-z13.c   # ==> tuned for zEC12
  $ gcc -c -mtune=z10 foo.c -o foo-z10.c   # ==> tuned for zEC12

If this requirement is dropped, it should be possible to get rid
of the s390_..._specified thing as it is not used for anything
else (it probably was in earlier patches).

(Your patch:) 
> +  /* A single -march overwrites a former -mtune.  */
> +  if (new_opts_set.x_s390_arch && !new_opts_set.x_s390_tune)
> + opts_set->x_s390_tune = (enum processor_type)0;

We cannot just overwrite the old *opts structure.  There may not
be a backup of it ...

> +  /* Make a joined copy of the original and the additional option
> +  flags.  */
> +  joined_opts_set = *opts_set;
> +  for (i = 0; i < sizeof(*opts_set); i++)
> + dest[i] |= src[i];

... rather reset the bit in the joined structure.

  if (new_opts_set.x_s390_arch && !new_opts_set.x_s390_tune)
joined_opts_set->x_s390_tune = new_opts_set->x_s390_tune;

(The opts_set parameter should really be const; I'll check if this
can be done.)

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: [PATCH] add self-tuning to x86 hardware fast path in libitm

[Nuno Diegues]

Hello everyone,

gently pinging to bring this back to life given the last patch I emailed.


Best regards,
-- Nuno Diegues

On Mon, Aug 24, 2015 at 12:51 PM, Nuno Diegues  wrote:
> Hello everyone,
>
> after a summer internship and some backlog catching up in the past
> weeks, I have finally got around to review the patch according to the
> latest discussion.
>
> The changes have not caused regression, and the latest speedup results
> are coherent with what we had before.
>
>
> In the following I add some comments inline to the discussion, and
> after that paste the updated patch.
>
>
>> >
>> > So let's iterate on this in parallel with the other changes that we need
>> > to get in place.  I'd prefer to have some more confidence that measuring
>> > txn throughput in epochs is the best way forward.
>> >
>> > Here are a few thoughts:
>> >
>> > Why do we actually need to measure succeeded transactions?  If a HW txn
>> > is just getting committed without interfering with anything else, is
>> > this really different from, say, two HW txns getting committed?  Aren't
>> > we really just interested in wasted work, or delayed txns?  That may
>> > help taking care of the nontxnal vs. txnal problem.
>> >
>> > Measuring committed txns during a time that might otherwise be spent by
>> > a serial txns could be useful to figure out how much other useful work a
>> > serial txn prevents.  But we'd see that as well if we'd just go serial
>> > during the auto-tuning because then concurrent txns will have to wait;
>> > and in this case we could measure it in the slow path of those
>> > concurrent txns (ie, during waiting, where measurement overhead wouldn't
>> > matter as much).
>> >
>> > If a serial txn is running, concurrent txns (that wait) are free to sync
>> > and tell the serial how much cost it creates for the concurrent txns.
>> > There, txn length could matter, but we won't find out for real until
>> > after the concurrent ones have run (they could be pretty short, so we
>> > can't simply assume that the concurrent ones are as long as the serial
>> > one, so that simply the number of concurrent ones can be used to
>> > calculate delayed work).
>
>
> I understand you concern: measuring failure in a slow path rather than
> success in
> the fast/common path.
>
> My problem is that the approach taken in our work is tailored for accessing 
> one
> given metric, in our case some form of throughput of successfully
> executed atomic
> blocks.
> However, to measure failure, we seem to need two things:
>  1) the rate of failed hardware transactions
>  2) the time spent waiting for the serial lock
>
> In short, the performance will be bad if there is a mix of those two
> issues that is bad
> enough. The problem is how to define a metric that considers those two 
> together?
> It is not obvious to me that there is one. Furthermore, that deviates
> significantly from
> our approach, and in the end --- even if there is a solution that
> works in that way ---
> that is a different approach, not one that can be applied to our
> self-tuning framework.
>
> What we are doing right now is incrementing a counter in a (most
> likely cached line)
> that is single-writer and multiple-reader. Most often, it will be
> owned by the single-writer.
> As such, the cost should be quite negligible compared to the execution
> of the atomic
> block, more so in the case that a Hardware transaction was used, as
> the commit itself
> should be a hundred cycles or more.
>
> A good way to measure this impact is to use the new "htm_notune" flag
> and compare
> its performance with the non-changed libitm that I use as a baseline above.
> The average results are similar, without any trend noticeable outside
> the standard
> deviation for one side or the other.
>
>
>
>
>>
>> >
>> >>
>> >> > Also, note that the mitigation strategy for rdtsc
>> >> > short-comings that you mention in the paper is not applicable in
>> >> > general, specifically not in libitm.
>> >>
>> >>
>> >> I suppose you mean the preemption of threads inflating the cycles 
>> >> measured?
>> >
>> > Yes, preemption and migration of threads (in case there's no global
>> > sync'ed TSC or similar) -- you mentioned in the paper that you pin
>> > threads to cores...
>> >
>> >> This would be similarly a problem to any time source that tries to 
>> >> measure the
>> >> amount of work performed; not sure how we can avoid it in general. Any 
>> >> thoughts?
>> >
>> > Not really as long as we keep depending on measuring time in a
>> > light-weight way.  Measuring smaller time intervals could make it less
>> > likely that preemption happens during such an interval, though.
>> >
>
>
> Note that in this patch we use no such pinning. In fact, I've measured
> that it does not
> have a noticeable impact in performance. Maybe that could be the case with 
> heavy
> over-subscription of the cores with lots of threads.
> Still, it is not a correctness issue, so I believe that the fact this
> 

Re: [PATCH][ARM] PR target/67929 Tighten vfp3_const_double_for_bits checks

[Kyrill Tkachov]

On 02/11/15 08:38, Ramana Radhakrishnan wrote:

2015-10-12  Kyrylo Tkachov  

 PR target/67929
 * gcc.target/arm/pr67929_1.c: New test.

This test fails when tested on hard-float targets, adding the
following line to avoid testing it in such cases will fix the issue,
but I wonder if there is a better dejaGNU directives sequence to do
that.

/* { dg-skip-if "avoid conflicting multilib options" { *-*-*eabihf } {
"*" } { "" } } */

No, not without further investigation into why the test is failing.


I believe it's the same issue that Christophe reported
in the comment for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67929.
It's because /* { dg-add-options arm_vfp3 } */ added -mfloat-abi=softfp but
the crt* files were compiled for hardfp. It's a testism.
I think adding an explicit -mfloat-abi=hard and gating on arm_hard_vfp_ok?


regards
Ramana


Cheers,
Yvan

Re: libgo patch committed: Update to Go 1.5 release

[Andreas Schwab]

Ian Lance Taylor  writes:

> On Sun, Nov 1, 2015 at 1:39 AM, Andreas Schwab  wrote:
>> ../../../../libgo/go/syscall/exec_linux.go:185:37: error: reference to 
>> undefined name 'TIOCSPGRP'
>>_, err1 = raw_ioctl_ptr(sys.Ctty, TIOCSPGRP, unsafe.Pointer())
>>  ^
>>
>> $ grep TIOCSPGRP gen-sysinfo.go
>> // unknowndefine TIOCSPGRP _IOW('t', 118, int)
>
> I have committed this patch which may fix the problem.  Let me know if
> it still happens for you.  Thanks.

../../../../libgo/go/syscall/exec_linux.go:185:37: error: integer constant 
overflow
   _, err1 = raw_ioctl_ptr(sys.Ctty, TIOCSPGRP, unsafe.Pointer())

// unknowndefine TIOCSPGRP _IOW('t', 118, int)
const _TIOCSPGRP_val = 2147775606

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH][ARM] PR target/67929 Tighten vfp3_const_double_for_bits checks

[Yvan Roux]

On 2 November 2015 at 09:38, Ramana Radhakrishnan
 wrote:
>

 2015-10-12  Kyrylo Tkachov  

 PR target/67929
 * gcc.target/arm/pr67929_1.c: New test.
>>
>> This test fails when tested on hard-float targets, adding the
>> following line to avoid testing it in such cases will fix the issue,
>> but I wonder if there is a better dejaGNU directives sequence to do
>> that.
>>
>> /* { dg-skip-if "avoid conflicting multilib options" { *-*-*eabihf } {
>> "*" } { "" } } */
>
> No, not without further investigation into why the test is failing.

Sorry, it fails because of the ABI mismatch between the built libs for
HF targets and the testcase which is built with the flag
-mfloat-abi=softfp (which is added by the directive arm_vfpv3_ok)

Yvan

> regards
> Ramana
>
>>
>> Cheers,
>> Yvan
>>

Re: [PATCH][ARM] PR target/67929 Tighten vfp3_const_double_for_bits checks

[Christophe Lyon]

On 2 November 2015 at 09:51, Yvan Roux  wrote:
> On 2 November 2015 at 09:38, Ramana Radhakrishnan
>  wrote:
>>
>
> 2015-10-12  Kyrylo Tkachov  
>
> PR target/67929
> * gcc.target/arm/pr67929_1.c: New test.
>>>
>>> This test fails when tested on hard-float targets, adding the
>>> following line to avoid testing it in such cases will fix the issue,
>>> but I wonder if there is a better dejaGNU directives sequence to do
>>> that.
>>>
>>> /* { dg-skip-if "avoid conflicting multilib options" { *-*-*eabihf } {
>>> "*" } { "" } } */
>>
>> No, not without further investigation into why the test is failing.
>
> Sorry, it fails because of the ABI mismatch between the built libs for
> HF targets and the testcase which is built with the flag
> -mfloat-abi=softfp (which is added by the directive arm_vfpv3_ok)
>
I think that's what I meant in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67929#c7

Christophe.

> Yvan
>
>> regards
>> Ramana
>>
>>>
>>> Cheers,
>>> Yvan
>>>

Re: [PATCH][ARM] PR target/67929 Tighten vfp3_const_double_for_bits checks

[Ramana Radhakrishnan]

On 02/11/15 09:20, Kyrill Tkachov wrote:
> 
> On 02/11/15 08:38, Ramana Radhakrishnan wrote:
> 2015-10-12  Kyrylo Tkachov  
>
>  PR target/67929
>  * gcc.target/arm/pr67929_1.c: New test.
>>> This test fails when tested on hard-float targets, adding the
>>> following line to avoid testing it in such cases will fix the issue,
>>> but I wonder if there is a better dejaGNU directives sequence to do
>>> that.
>>>
>>> /* { dg-skip-if "avoid conflicting multilib options" { *-*-*eabihf } {
>>> "*" } { "" } } */
>> No, not without further investigation into why the test is failing.
> 
> I believe it's the same issue that Christophe reported
> in the comment for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67929.
> It's because /* { dg-add-options arm_vfp3 } */ added -mfloat-abi=softfp but
> the crt* files were compiled for hardfp. It's a testism.
> I think adding an explicit -mfloat-abi=hard and gating on arm_hard_vfp_ok?

No, see my other response. 

Looking at it again, I can't see anything ARM specific in the source
that causes this to remain in gcc.target/arm.

Instead remove all the special casing and move it into gcc.c-torture/execute.

regards
Ramana

> 
>> regards
>> Ramana
>>
>>> Cheers,
>>> Yvan
>>>
> 

Re: [PATCH][ARM] PR target/67929 Tighten vfp3_const_double_for_bits checks

[Ramana Radhakrishnan]

On 02/11/15 09:01, Christophe Lyon wrote:
> On 2 November 2015 at 09:51, Yvan Roux  wrote:
>> On 2 November 2015 at 09:38, Ramana Radhakrishnan
>>  wrote:
>>>
>>
>> 2015-10-12  Kyrylo Tkachov  
>>
>> PR target/67929
>> * gcc.target/arm/pr67929_1.c: New test.

 This test fails when tested on hard-float targets, adding the
 following line to avoid testing it in such cases will fix the issue,
 but I wonder if there is a better dejaGNU directives sequence to do
 that.

 /* { dg-skip-if "avoid conflicting multilib options" { *-*-*eabihf } {
 "*" } { "" } } */
>>>
>>> No, not without further investigation into why the test is failing.
>>
>> Sorry, it fails because of the ABI mismatch between the built libs for
>> HF targets and the testcase which is built with the flag
>> -mfloat-abi=softfp (which is added by the directive arm_vfpv3_ok)
>>
> I think that's what I meant in:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67929#c7

Ah, I see what you mean - instead I would just remove all the special options 
and move this test into gcc.c-torture/execute.

There are enough testers that test by default to armhf now for us to be worried 
about testing the exact combination.

regards
Ramana

> 
> Christophe.
> 
>> Yvan
>>
>>> regards
>>> Ramana
>>>

 Cheers,
 Yvan

Re: [PATCH][ARM] PR target/67929 Tighten vfp3_const_double_for_bits checks

[Kyrill Tkachov]

On 02/11/15 09:28, Yvan Roux wrote:

On 2 November 2015 at 10:24, Ramana Radhakrishnan
 wrote:


On 02/11/15 09:01, Christophe Lyon wrote:

On 2 November 2015 at 09:51, Yvan Roux  wrote:

On 2 November 2015 at 09:38, Ramana Radhakrishnan
 wrote:

2015-10-12  Kyrylo Tkachov  

 PR target/67929
 * gcc.target/arm/pr67929_1.c: New test.

This test fails when tested on hard-float targets, adding the
following line to avoid testing it in such cases will fix the issue,
but I wonder if there is a better dejaGNU directives sequence to do
that.

/* { dg-skip-if "avoid conflicting multilib options" { *-*-*eabihf } {
"*" } { "" } } */

No, not without further investigation into why the test is failing.

Sorry, it fails because of the ABI mismatch between the built libs for
HF targets and the testcase which is built with the flag
-mfloat-abi=softfp (which is added by the directive arm_vfpv3_ok)


I think that's what I meant in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67929#c7

Ah, I see what you mean - instead I would just remove all the special options 
and move this test into gcc.c-torture/execute.

There are enough testers that test by default to armhf now for us to be worried 
about testing the exact combination.

Ha yes that's ture and I remember that we ended to that same
conclusion for one testcase I tried to find the exact float ABI flag
combination several months ago.


Ok, moving the test to the torture suite sounds best.
I'll prepare a patch.

Sorry for the trouble,
Kyrill




Yvan

regards
Ramana


Christophe.


Yvan


regards
Ramana


Cheers,
Yvan

Re: Add VIEW_CONVERT_EXPR to operand_equal_p

[Andreas Schwab]

Eric Botcazou <ebotca...@adacore.com> writes:

>   * gnat.dg/discr45.adb: New test.

This fails on ia64.

raised CONSTRAINT_ERROR : discr45.adb:19 range check failed

#0  <__gnat_rcheck_CE_Range_Check> (file=(system.address) 0x40022e98, 
line=19) at a-except.adb:1286
#1  0x40010470 in discr45.proc (signal=true)
at /usr/local/gcc/gcc-20151102/gcc/testsuite/gnat.dg/discr45.adb:19
#2  0x400104a0 in discr45 ()
at /usr/local/gcc/gcc-20151102/gcc/testsuite/gnat.dg/discr45.adb:43

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PR68083] stop ifcombine from moving uninitialized uses before their guards

[Richard Biener]

On Fri, Oct 30, 2015 at 7:02 PM, Alexandre Oliva  wrote:
> On Oct 30, 2015, Alexandre Oliva  wrote:
>
>> Incidentally, bb_no_side_effects_p (inner_cond_bb) is called in all four
>> tests in tree_ssa_ifcombine_bb_1, for each outer_cond_bb that
>> tree_ssa_ifcombine_bb might choose.  Is there any reason to not factor
>> it out to the test that checks whether the inner_cond_bb is indeed an
>> if_then_else block, early in tree_ssa_ifcombine_bb, so as to
>> short-circuit the whole thing when the inner block is not viable?
>
> Like this...
>
> Bail out early if the inner block has side effects or is otherwise not
> eligible for ifcombine.
>
> Regstrapped on x86_64-linux-gnu.  Ok to install?

Ok.

Thanks,
Richard.

>
> for  gcc/ChangeLog
>
> * tree-ssa-ifcombine.c (tree_ssa_ifcombine_bb_1): Factor out
> bb_no_side_effects_p tests...
> (tree_ssa_ifcombine_bb): ... here.
> ---
>  gcc/tree-ssa-ifcombine.c |   15 ++-
>  1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/gcc/tree-ssa-ifcombine.c b/gcc/tree-ssa-ifcombine.c
> index 622dc6b..3b60968 100644
> --- a/gcc/tree-ssa-ifcombine.c
> +++ b/gcc/tree-ssa-ifcombine.c
> @@ -579,8 +579,7 @@ tree_ssa_ifcombine_bb_1 (basic_block inner_cond_bb, 
> basic_block outer_cond_bb,
>   the inner cond_bb having no side-effects.  */
>if (phi_pred_bb != else_bb
>&& recognize_if_then_else (outer_cond_bb, _cond_bb, _bb)
> -  && same_phi_args_p (outer_cond_bb, phi_pred_bb, else_bb)
> -  && bb_no_side_effects_p (inner_cond_bb))
> +  && same_phi_args_p (outer_cond_bb, phi_pred_bb, else_bb))
>  {
>/* We have
>
> @@ -598,8 +597,7 @@ tree_ssa_ifcombine_bb_1 (basic_block inner_cond_bb, 
> basic_block outer_cond_bb,
>/* And a version where the outer condition is negated.  */
>if (phi_pred_bb != else_bb
>&& recognize_if_then_else (outer_cond_bb, _bb, _cond_bb)
> -  && same_phi_args_p (outer_cond_bb, phi_pred_bb, else_bb)
> -  && bb_no_side_effects_p (inner_cond_bb))
> +  && same_phi_args_p (outer_cond_bb, phi_pred_bb, else_bb))
>  {
>/* We have
>
> @@ -620,8 +618,7 @@ tree_ssa_ifcombine_bb_1 (basic_block inner_cond_bb, 
> basic_block outer_cond_bb,
>   having no side-effects.  */
>if (phi_pred_bb != then_bb
>&& recognize_if_then_else (outer_cond_bb, _bb, _cond_bb)
> -  && same_phi_args_p (outer_cond_bb, phi_pred_bb, then_bb)
> -  && bb_no_side_effects_p (inner_cond_bb))
> +  && same_phi_args_p (outer_cond_bb, phi_pred_bb, then_bb))
>  {
>/* We have
>
> @@ -638,8 +635,7 @@ tree_ssa_ifcombine_bb_1 (basic_block inner_cond_bb, 
> basic_block outer_cond_bb,
>/* And a version where the outer condition is negated.  */
>if (phi_pred_bb != then_bb
>&& recognize_if_then_else (outer_cond_bb, _cond_bb, _bb)
> -  && same_phi_args_p (outer_cond_bb, phi_pred_bb, then_bb)
> -  && bb_no_side_effects_p (inner_cond_bb))
> +  && same_phi_args_p (outer_cond_bb, phi_pred_bb, then_bb))
>  {
>/* We have
>
> @@ -676,7 +672,8 @@ tree_ssa_ifcombine_bb (basic_block inner_cond_bb)
> if (a && b)
>  ;
>   This requires a single predecessor of the inner cond_bb.  */
> -  if (single_pred_p (inner_cond_bb))
> +  if (single_pred_p (inner_cond_bb)
> +  && bb_no_side_effects_p (inner_cond_bb))
>  {
>basic_block outer_cond_bb = single_pred (inner_cond_bb);
>
>
>
> --
> Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/   FSF Latin America board member
> Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: [PR68083] stop ifcombine from moving uninitialized uses before their guards

[Richard Biener]

On Fri, Oct 30, 2015 at 2:41 PM, Alexandre Oliva  wrote:
> The ifcombine pass may move a conditional access to an uninitialized
> value before the condition that ensures it is always well-defined,
> thus introducing undefined behavior.  Stop it from doing so.
>
> Regstrapped on x86_64-linux-gnu and i686-linux-gnu.  Ok to install?

Ok.

Thanks,
Richard.

>
> Incidentally, bb_no_side_effects_p (inner_cond_bb) is called in all four
> tests in tree_ssa_ifcombine_bb_1, for each outer_cond_bb that
> tree_ssa_ifcombine_bb might choose.  Is there any reason to not factor
> it out to the test that checks whether the inner_cond_bb is indeed an
> if_then_else block, early in tree_ssa_ifcombine_bb, so as to
> short-circuit the whole thing when the inner block is not viable?
>
>
> for  gcc/ChangeLog
>
> PR tree-optimization/68083
> * tree-ssa-ifcombine.c: Include tree-ssa.h.
> (bb_no_side_effects_p): Test for undefined uses too.
> * tree-ssa.c (gimple_uses_undefined_value_p): New.
> * tree-ssa.h (gimple_uses_undefined_value_p): Declare.
>
> for  gcc/testsuite/ChangeLog
>
> PR tree-optimization/68083
> * gcc.dg/torture/pr68083.c: New.  From Zhendong Su.
> ---
>  gcc/testsuite/gcc.dg/torture/pr68083.c |   35 
> 
>  gcc/tree-ssa-ifcombine.c   |2 ++
>  gcc/tree-ssa.c |   18 
>  gcc/tree-ssa.h |1 +
>  4 files changed, 56 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.dg/torture/pr68083.c
>
> diff --git a/gcc/testsuite/gcc.dg/torture/pr68083.c 
> b/gcc/testsuite/gcc.dg/torture/pr68083.c
> new file mode 100644
> index 000..ae24781
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/pr68083.c
> @@ -0,0 +1,35 @@
> +/* { dg-do run } */
> +
> +int a = 2, b = 1, c = 1;
> +
> +int
> +fn1 ()
> +{
> +  int d;
> +  for (; a; a--)
> +{
> +  for (d = 0; d < 4; d++)
> +   {
> + int k;
> + if (c < 1)
> +   if (k)
> + c = 0;
> + if (b)
> +   continue;
> + return 0;
> +   }
> +  b = !1;
> +}
> +  return 0;
> +}
> +
> +int
> +main ()
> +{
> +  fn1 ();
> +
> +  if (a != 1)
> +__builtin_abort ();
> +
> +  return 0;
> +}
> diff --git a/gcc/tree-ssa-ifcombine.c b/gcc/tree-ssa-ifcombine.c
> index ca55b57..622dc6b 100644
> --- a/gcc/tree-ssa-ifcombine.c
> +++ b/gcc/tree-ssa-ifcombine.c
> @@ -41,6 +41,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "gimple-iterator.h"
>  #include "gimplify-me.h"
>  #include "tree-cfg.h"
> +#include "tree-ssa.h"
>
>  #ifndef LOGICAL_OP_NON_SHORT_CIRCUIT
>  #define LOGICAL_OP_NON_SHORT_CIRCUIT \
> @@ -125,6 +126,7 @@ bb_no_side_effects_p (basic_block bb)
> continue;
>
>if (gimple_has_side_effects (stmt)
> + || gimple_uses_undefined_value_p (stmt)
>   || gimple_could_trap_p (stmt)
>   || gimple_vuse (stmt))
> return false;
> diff --git a/gcc/tree-ssa.c b/gcc/tree-ssa.c
> index c7be442..8dc2d61 100644
> --- a/gcc/tree-ssa.c
> +++ b/gcc/tree-ssa.c
> @@ -1210,6 +1210,24 @@ ssa_undefined_value_p (tree t, bool partial)
>  }
>
>
> +/* Return TRUE iff STMT, a gimple statement, references an undefined
> +   SSA name.  */
> +
> +bool
> +gimple_uses_undefined_value_p (gimple *stmt)
> +{
> +  ssa_op_iter iter;
> +  tree op;
> +
> +  FOR_EACH_SSA_TREE_OPERAND (op, stmt, iter, SSA_OP_USE)
> +if (ssa_undefined_value_p (op))
> +  return true;
> +
> +  return false;
> +}
> +
> +
> +
>  /* If necessary, rewrite the base of the reference tree *TP from
> a MEM_REF to a plain or converted symbol.  */
>
> diff --git a/gcc/tree-ssa.h b/gcc/tree-ssa.h
> index 5a409e5..3b5bd70 100644
> --- a/gcc/tree-ssa.h
> +++ b/gcc/tree-ssa.h
> @@ -51,6 +51,7 @@ extern bool tree_ssa_useless_type_conversion (tree);
>  extern tree tree_ssa_strip_useless_type_conversions (tree);
>
>  extern bool ssa_undefined_value_p (tree, bool = true);
> +extern bool gimple_uses_undefined_value_p (gimple *);
>  extern void execute_update_addresses_taken (void);
>
>  /* Given an edge_var_map V, return the PHI arg definition.  */
>
>
> --
> Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/   FSF Latin America board member
> Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: [PATCH][PR tree-optimization/67892] Use FSM threader to handle backedges

[Richard Biener]

On Fri, Oct 30, 2015 at 9:27 PM, Jeff Law  wrote:
> On 10/30/2015 07:57 AM, Andreas Schwab wrote:
>>
>> I'm getting this regression on m68k:
>>
>> FAIL: gcc.dg/tree-ssa/ssa-thread-11.c scan-tree-dump vrp2 "FSM"
>>
>> The generated code looks equivalent, though.
>
> Definitely an artifact of differences in branch costing.  Pondering the best
> way to fix.

The usual list of targets and a dg-skip ...

Or work towards eliminating those "early" target dependences
introduced in our IL.
Major effects are from LOGICAL_OP_NON_SHORT_CIRCUIT (boiling down to
BRANCH_COST as default) and from PUSH_ARGS_REVERSED.  Esp. the
logical-op-non-short-circuit decisions are done a bit early (before
profile-reading
for example).  So I'd rather keep the short-circuiting for all targets (for the
GENERIC folding) and let ifcombine do the "heavy" lifting also taking
into account
branch predictability (and target preferences).

Richard.

> jeff

Re: Add VIEW_CONVERT_EXPR to operand_equal_p

[Richard Biener]

On Fri, Oct 30, 2015 at 4:19 PM, Jan Hubicka  wrote:
>>
>> Yeah, I suppose we'd need to either build a new function type for each
>> variadic call
>> then or somehow represent 'fntype' differently (note that function
>> attributes also
>> need to be preserved).
>
> Why we can't keep fntype as it is, but simply add a new set of parameters to 
> call stmt
> that lists their types?  We can then feed those types to expand_call (since 
> we still go
> back to generic here I suppose we will just re-insert those VCEs in 
> expand-cfg.c)

That would be quite expensive though ... (the extra list of parameters).

> Honza

Re: [0/7] Type promotion pass and elimination of zext/sext

[Kugan]

On 29/10/15 02:45, Richard Biener wrote:
> On Tue, Oct 27, 2015 at 1:50 AM, kugan
>  wrote:
>>
>>
>> On 23/10/15 01:23, Richard Biener wrote:
>>>
>>> On Thu, Oct 22, 2015 at 12:50 PM, Kugan
>>>  wrote:



 On 21/10/15 23:45, Richard Biener wrote:
>
> On Tue, Oct 20, 2015 at 10:03 PM, Kugan
>  wrote:
>>
>>
>>
>> On 07/09/15 12:53, Kugan wrote:
>>>
>>>
>>> This a new version of the patch posted in
>>> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00226.html. I have done
>>> more testing and spitted the patch to make it more easier to review.
>>> There are still couple of issues to be addressed and I am working on
>>> them.
>>>
>>> 1. AARCH64 bootstrap now fails with the commit
>>> 94f92c36a83d66a893c3bc6f00a038ba3dbe2a6f. simplify-rtx.c is
>>> mis-compiled
>>> in stage2 and fwprop.c is failing. It looks to me that there is a
>>> latent
>>> issue which gets exposed my patch. I can also reproduce this in x86_64
>>> if I use the same PROMOTE_MODE which is used in aarch64 port. For the
>>> time being, I am using  patch
>>> 0006-temporary-workaround-for-bootstrap-failure-due-to-co.patch as a
>>> workaround. This meeds to be fixed before the patches are ready to be
>>> committed.
>>>
>>> 2. vector-compare-1.c from c-c++-common/torture fails to assemble with
>>> -O3 -g Error: unaligned opcodes detected in executable segment. It
>>> works
>>> fine if I remove the -g. I am looking into it and needs to be fixed as
>>> well.
>>
>>
>> Hi Richard,
>>
>> Now that stage 1 is going to close, I would like to get these patches
>> accepted for stage1. I will try my best to address your review comments
>> ASAP.
>
>
> Ok, can you make the whole patch series available so I can poke at the
> implementation a bit?  Please state the revision it was rebased on
> (or point me to a git/svn branch the work resides on).
>

 Thanks. Please find the patched rebated against trunk@229156. I have
 skipped the test-case readjustment patches.
>>>
>>>
>>> Some quick observations.  On x86_64 when building
>>
>>
>> Hi Richard,
>>
>> Thanks for the review.
>>
>>>
>>> short bar (short y);
>>> int foo (short x)
>>> {
>>>short y = bar (x) + 15;
>>>return y;
>>> }
>>>
>>> with -m32 -O2 -mtune=pentiumpro (which ends up promoting HImode regs)
>>> I get
>>>
>>>:
>>>_1 = (int) x_10(D);
>>>_2 = (_1) sext (16);
>>>_11 = bar (_2);
>>>_5 = (int) _11;
>>>_12 = (unsigned int) _5;
>>>_6 = _12 & 65535;
>>>_7 = _6 + 15;
>>>_13 = (int) _7;
>>>_8 = (_13) sext (16);
>>>_9 = (_8) sext (16);
>>>return _9;
>>>
>>> which looks fine but the VRP optimization doesn't trigger for the
>>> redundant sext
>>> (ranges are computed correctly but the 2nd extension is not removed).

Thanks for the comments. Please fond the attached patches with which I
am now getting
cat .192t.optimized

;; Function foo (foo, funcdef_no=0, decl_uid=1406, cgraph_uid=0,
symbol_order=0)

foo (short int x)
{
  signed int _1;
  int _2;
  signed int _5;
  unsigned int _6;
  unsigned int _7;
  signed int _8;
  int _9;
  short int _11;
  unsigned int _12;
  signed int _13;

  :
  _1 = (signed int) x_10(D);
  _2 = _1;
  _11 = bar (_2);
  _5 = (signed int) _11;
  _12 = (unsigned int) _11;
  _6 = _12 & 65535;
  _7 = _6 + 15;
  _13 = (signed int) _7;
  _8 = (_13) sext (16);
  _9 = _8;
  return _9;

}


There are still some redundancies. The asm difference after RTL
optimizations is

-   addl$15, %eax
+   addw$15, %ax


>>>
>>> This also makes me notice trivial match.pd patterns are missing, like
>>> for example
>>>
>>> (simplify
>>>   (sext (sext@2 @0 @1) @3)
>>>   (if (tree_int_cst_compare (@1, @3) <= 0)
>>>@2
>>>(sext @0 @3)))
>>>
>>> as VRP doesn't run at -O1 we must rely on those to remove rendudant
>>> extensions,
>>> otherwise generated code might get worse compared to without the pass(?)
>>
>>
>> Do you think that we should enable this pass only when vrp is enabled.
>> Otherwise, even when we do the simple optimizations you mentioned below, we
>> might not be able to remove all the redundancies.
>>
>>>
>>> I also notice that the 'short' argument does not get it's sign-extension
>>> removed
>>> as redundand either even though we have
>>>
>>> _1 = (int) x_8(D);
>>> Found new range for _1: [-32768, 32767]
>>>
>>
>> I am looking into it.
>>
>>> In the end I suspect that keeping track of the "simple" cases in the
>>> promotion
>>> pass itself (by keeping a lattice) might be a good idea (after we fix VRP
>>> to do
>>> its work).  In some way whether the ABI guarantees promoted argument
>>> registers might need some other target hook queries.

I tried adding it in the attached patch with record_visit_stmt to track
whether 

Re: Move constant folds for maths functions to new file

[Richard Biener]

On Fri, Oct 30, 2015 at 4:07 PM, Richard Sandiford
 wrote:
> The new routines operate on the built-in enum rather than on tree decls.
> The idea is to extend this to handle internal functions too, with a
> combined enum for both.
>
> The patch also moves fold_fma too, with the same prototype.  The long-term
> plan is to replace FMA_EXPR with an internal function, for consistency
> with the way that things like SQRT will be handled.
>
> Tested on x86_64-linux-gnu, arm-linux-gnueabi and aarch64-linux-gnu.
> OK to install?

Ok.

Thanks,
Richard.

> Thanks,
> Richard
>
>
> gcc/
> * builtins.h (fold_fma): Move to fold-const-call.h.
> * builtins.c: Include fold-const-call.h.
> (mathfn_built_in_2): New function, split out from...
> (mathfn_built_in_1): ...here.
> (do_real_to_int_conversion, fold_const_builtin_pow)
> (fold_const_builtin_logb, fold_const_builtin_significand)
> (fold_const_builtin_load_exponent, do_mpfr_arg1, do_mpfr_arg2)
> (do_mpfr_arg3, do_mpfr_sincos, do_mpfr_bessel_n, do_mpc_arg1): Delete.
> (fold_builtin_sincos): Use fold_const_call to handle constants.
> (fold_builtin_1, fold_builtin_2, fold_builtin_3): Add explicit
> checks for ERROR_MARK.  Use fold_const_call to handle constant
> folds for math functions.
> (fold_fma): Move to fold-const-call.c.
> * fold-const.c: Include fold-const-call.h.
> * Makefile.in (OBJS): Add fold-const-call.o.
> (PLUGIN_HEADERS): Add fold-const-call.h.
> * realmpfr.h (real_from_mpfr): Allow the format to be specified
> directly.
> * realmpfr.c (real_from_mpfr): Likewise.
> * fold-const-call.h, fold-const-call.c: New files.
>
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 9a544e7..33b0481 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -1260,6 +1260,7 @@ OBJS = \
> final.o \
> fixed-value.o \
> fold-const.o \
> +   fold-const-call.o \
> function.o \
> fwprop.o \
> gcse.o \
> @@ -3272,10 +3273,10 @@ PLUGIN_HEADERS = $(TREE_H) $(CONFIG_H) $(SYSTEM_H) 
> coretypes.h $(TM_H) \
>prefix.h tree-inline.h $(GIMPLE_PRETTY_PRINT_H) realmpfr.h \
>$(IPA_PROP_H) $(TARGET_H) $(RTL_H) $(TM_P_H) $(CFGLOOP_H) $(EMIT_RTL_H) \
>version.h stringpool.h gimplify.h gimple-iterator.h gimple-ssa.h \
> -  fold-const.h tree-cfg.h tree-into-ssa.h tree-ssanames.h print-tree.h \
> -  varasm.h context.h tree-phinodes.h stor-layout.h ssa-iterators.h \
> -  $(RESOURCE_H) tree-cfgcleanup.h attribs.h calls.h cfgexpand.h \
> -  diagnostic-color.h gcc-symtab.h gimple-builder.h gimple-low.h \
> +  fold-const.h fold-const-call.h tree-cfg.h tree-into-ssa.h tree-ssanames.h \
> +  print-tree.h varasm.h context.h tree-phinodes.h stor-layout.h \
> +  ssa-iterators.h $(RESOURCE_H) tree-cfgcleanup.h attribs.h calls.h \
> +  cfgexpand.h diagnostic-color.h gcc-symtab.h gimple-builder.h gimple-low.h \
>gimple-walk.h gimplify-me.h pass_manager.h print-rtl.h stmt.h \
>tree-dfa.h tree-hasher.h tree-nested.h tree-object-size.h tree-outof-ssa.h 
> \
>tree-parloops.h tree-ssa-address.h tree-ssa-coalesce.h tree-ssa-dom.h \
> diff --git a/gcc/builtins.c b/gcc/builtins.c
> index 11c34e6..36b76d7 100644
> --- a/gcc/builtins.c
> +++ b/gcc/builtins.c
> @@ -42,6 +42,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "diagnostic-core.h"
>  #include "alias.h"
>  #include "fold-const.h"
> +#include "fold-const-call.h"
>  #include "stor-layout.h"
>  #include "calls.h"
>  #include "varasm.h"
> @@ -68,8 +69,6 @@ along with GCC; see the file COPYING3.  If not see
>  #include "rtl-chkp.h"
>
>
> -static tree do_mpc_arg1 (tree, tree, int (*)(mpc_ptr, mpc_srcptr, 
> mpc_rnd_t));
> -
>  struct target_builtins default_target_builtins;
>  #if SWITCHABLE_TARGET
>  struct target_builtins *this_target_builtins = _target_builtins;
> @@ -194,16 +193,6 @@ static unsigned HOST_WIDE_INT target_s;
>  char target_percent_c[3];
>  char target_percent_s[3];
>  char target_percent_s_newline[4];
> -static tree do_mpfr_arg1 (tree, tree, int (*)(mpfr_ptr, mpfr_srcptr, 
> mp_rnd_t),
> - const REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *, 
> bool);
> -static tree do_mpfr_arg2 (tree, tree, tree,
> - int (*)(mpfr_ptr, mpfr_srcptr, mpfr_srcptr, 
> mp_rnd_t));
> -static tree do_mpfr_arg3 (tree, tree, tree, tree,
> - int (*)(mpfr_ptr, mpfr_srcptr, mpfr_srcptr, 
> mpfr_srcptr, mp_rnd_t));
> -static tree do_mpfr_sincos (tree, tree, tree);
> -static tree do_mpfr_bessel_n (tree, tree, tree,
> - int (*)(mpfr_ptr, long, mpfr_srcptr, mp_rnd_t),
> - const REAL_VALUE_TYPE *, bool);
>  static tree do_mpfr_remquo (tree, tree, tree);
>  static tree do_mpfr_lgamma_r (tree, tree, tree);
>  static void expand_builtin_sync_synchronize (void);
> @@ -1800,15 

Re: [PATCH][ARM] PR target/67929 Tighten vfp3_const_double_for_bits checks

[Yvan Roux]

On 2 November 2015 at 10:24, Ramana Radhakrishnan
 wrote:
>
>
> On 02/11/15 09:01, Christophe Lyon wrote:
>> On 2 November 2015 at 09:51, Yvan Roux  wrote:
>>> On 2 November 2015 at 09:38, Ramana Radhakrishnan
>>>  wrote:

>>>
>>> 2015-10-12  Kyrylo Tkachov  
>>>
>>> PR target/67929
>>> * gcc.target/arm/pr67929_1.c: New test.
>
> This test fails when tested on hard-float targets, adding the
> following line to avoid testing it in such cases will fix the issue,
> but I wonder if there is a better dejaGNU directives sequence to do
> that.
>
> /* { dg-skip-if "avoid conflicting multilib options" { *-*-*eabihf } {
> "*" } { "" } } */

 No, not without further investigation into why the test is failing.
>>>
>>> Sorry, it fails because of the ABI mismatch between the built libs for
>>> HF targets and the testcase which is built with the flag
>>> -mfloat-abi=softfp (which is added by the directive arm_vfpv3_ok)
>>>
>> I think that's what I meant in:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67929#c7
>
> Ah, I see what you mean - instead I would just remove all the special options 
> and move this test into gcc.c-torture/execute.
>
> There are enough testers that test by default to armhf now for us to be 
> worried about testing the exact combination.

Ha yes that's ture and I remember that we ended to that same
conclusion for one testcase I tried to find the exact float ABI flag
combination several months ago.


Yvan
> regards
> Ramana
>
>>
>> Christophe.
>>
>>> Yvan
>>>
 regards
 Ramana

>
> Cheers,
> Yvan
>

[HSA] libgomp and hsa-gen.c header file refactoring

[Martin Liška]

Hello.

Following patch moves content of hsa-traits.h to gomp-constants.h.

Martin
>From 40179af53541cf3318f8710ac23b9908b90353e8 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 26 Oct 2015 11:49:02 +0100
Subject: [PATCH] HSA: move content of hsa-traits.h to gomp-constants.h

include/ChangeLog:

2015-10-26  Martin Liska  

	* gomp-constants.h (struct hsa_kernel_dispatch): New structure.

gcc/ChangeLog:

2015-10-26  Martin Liska  

	* hsa-gen.c (struct hsa_kernel_dispatch): Remove the
	declaration.

libgomp/ChangeLog:

2015-10-26  Martin Liska  

	* hsa-traits.h: Remove.
	* plugin/plugin-hsa.c: Include gomp-constants.h.
---
 gcc/hsa-gen.c   | 30 +
 include/gomp-constants.h| 31 ++
 libgomp/hsa-traits.h| 54 -
 libgomp/plugin/plugin-hsa.c |  1 -
 4 files changed, 32 insertions(+), 84 deletions(-)
 delete mode 100644 libgomp/hsa-traits.h

diff --git a/gcc/hsa-gen.c b/gcc/hsa-gen.c
index c36c9e0..ec5cd81 100644
--- a/gcc/hsa-gen.c
+++ b/gcc/hsa-gen.c
@@ -78,6 +78,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "cfganal.h"
 #include "builtins.h"
 #include "params.h"
+#include "gomp-constants.h"
 
 /* Print a warning message and set that we have seen an error.  */
 
@@ -112,35 +113,6 @@ along with GCC; see the file COPYING3.  If not see
 /* Following structures are defined in the final version
of HSA specification.  */
 
-/* HSA kernel dispatch is collection of informations needed for
-   a kernel dispatch.  */
-
-struct hsa_kernel_dispatch
-{
-  /* Pointer to a command queue associated with a kernel dispatch agent.  */
-  void *queue;
-  /* Pointer to reserved memory for OMP data struct copying.  */
-  void *omp_data_memory;
-  /* Pointer to a memory space used for kernel arguments passing.  */
-  void *kernarg_address;
-  /* Kernel object.  */
-  uint64_t object;
-  /* Synchronization signal used for dispatch synchronization.  */
-  uint64_t signal;
-  /* Private segment size.  */
-  uint32_t private_segment_size;
-  /* Group segment size.  */
-  uint32_t group_segment_size;
-  /* Number of children kernel dispatches.  */
-  uint64_t kernel_dispatch_count;
-  /* Number of threads.  */
-  uint32_t omp_num_threads;
-  /* Debug purpose argument.  */
-  uint64_t debug;
-  /* Kernel dispatch structures created for children kernel dispatches.  */
-  struct hsa_kernel_dispatch **children_dispatches;
-};
-
 /* HSA queue packet is shadow structure, originally provided by AMD.  */
 
 struct hsa_queue_packet
diff --git a/include/gomp-constants.h b/include/gomp-constants.h
index 228d933..839081b 100644
--- a/include/gomp-constants.h
+++ b/include/gomp-constants.h
@@ -144,4 +144,35 @@ enum gomp_map_kind
 #define GOMP_LAUNCH_OP(X) (((X) >> GOMP_LAUNCH_OP_SHIFT) & 0x)
 #define GOMP_LAUNCH_OP_MAX 0x
 
+/* HSA specific data structures.  */
+
+/* HSA kernel dispatch is collection of informations needed for
+   a kernel dispatch.  */
+
+struct hsa_kernel_dispatch
+{
+  /* Pointer to a command queue associated with a kernel dispatch agent.  */
+  void *queue;
+  /* Pointer to reserved memory for OMP data struct copying.  */
+  void *omp_data_memory;
+  /* Pointer to a memory space used for kernel arguments passing.  */
+  void *kernarg_address;
+  /* Kernel object.  */
+  uint64_t object;
+  /* Synchronization signal used for dispatch synchronization.  */
+  uint64_t signal;
+  /* Private segment size.  */
+  uint32_t private_segment_size;
+  /* Group segment size.  */
+  uint32_t group_segment_size;
+  /* Number of children kernel dispatches.  */
+  uint64_t kernel_dispatch_count;
+  /* Number of threads.  */
+  uint32_t omp_num_threads;
+  /* Debug purpose argument.  */
+  uint64_t debug;
+  /* Kernel dispatch structures created for children kernel dispatches.  */
+  struct hsa_kernel_dispatch **children_dispatches;
+};
+
 #endif
diff --git a/libgomp/hsa-traits.h b/libgomp/hsa-traits.h
deleted file mode 100644
index 6fb7e48..000
--- a/libgomp/hsa-traits.h
+++ /dev/null
@@ -1,54 +0,0 @@
-/* HSA traits.
-   Copyright (C) 2015 Free Software Foundation, Inc.
-
-This file is part of GCC.
-
-GCC is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 3, or (at your option)
-any later version.
-
-GCC is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with GCC; see the file COPYING3.  If not see
-.  */
-
-
-
-#ifndef HSA_TRAITS_H_
-#define HSA_TRAITS_H_
-
-/* 

[HSA] Back-end enhancement and various fixes

[Martin Liška]

Hello.

In the following series, I enhance HSA BE to correctly support aggregate types 
(as function call arguments and return types).
Apart from that, we should not ICE in situations where we have a non-trivial 
memory reference. Finally, many memory leaks were
fixed and a lot of refactoring is included.

Martin
>From c5006ca75912bdab8256fe4670645d5f1ad54a14 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 26 Oct 2015 16:58:26 +0100
Subject: [PATCH 1/9] HSA: fix generation of address that end as SSA_NAME or
 VAR_DECL.

gcc/ChangeLog:

2015-10-22  Martin Liska  

	* hsa-brig.c (emit_function_directives): Emit private variables.
	* hsa-gen.c (hsa_function_representation::~hsa_function_representation):
	Release the container.
	(hsa_function_representation::create_hsa_temporary): New function.
	(gen_hsa_addr): Handle properly SSA_NAMEs and VAR_DECLs.
	* hsa.h (hsa_function_representation::m_private_variables):
	Declare new variable.
---
 gcc/hsa-brig.c |  7 ++-
 gcc/hsa-gen.c  | 55 ++-
 gcc/hsa.h  | 14 ++
 3 files changed, 70 insertions(+), 6 deletions(-)

diff --git a/gcc/hsa-brig.c b/gcc/hsa-brig.c
index be7ef59..0c26b58 100644
--- a/gcc/hsa-brig.c
+++ b/gcc/hsa-brig.c
@@ -626,6 +626,7 @@ emit_function_directives (hsa_function_representation *f, bool is_declaration)
 	if (TREE_CODE ((*iter)->m_decl) == VAR_DECL)
 	  count++;
   count += f->m_spill_symbols.length ();
+  count += f->m_private_variables.length ();
 }
 
   next_toplev_off = scoped_off + count * sizeof (struct BrigDirectiveVariable);
@@ -685,7 +686,11 @@ emit_function_directives (hsa_function_representation *f, bool is_declaration)
 	  emit_directive_variable (sym);
 	  brig_insn_count++;
 	}
-
+  for (unsigned i = 0; i < f->m_private_variables.length (); i++)
+	{
+	  emit_directive_variable (f->m_private_variables[i]);
+	  brig_insn_count++;
+	}
 }
 
   return ptr_to_fndir;
diff --git a/gcc/hsa-gen.c b/gcc/hsa-gen.c
index c36c9e0..15f9050 100644
--- a/gcc/hsa-gen.c
+++ b/gcc/hsa-gen.c
@@ -228,10 +228,10 @@ hsa_function_representation::hsa_function_representation
   (tree fdecl, bool kernel_p): m_name (NULL),
   m_input_args_count (0), m_reg_count (0), m_input_args (NULL),
   m_output_arg (NULL), m_spill_symbols (vNULL), m_readonly_variables (vNULL),
-  m_called_functions (vNULL), m_hbb_count (0), m_in_ssa (true),
-  m_kern_p (kernel_p), m_declaration_p (false), m_decl (fdecl),
+  m_private_variables (vNULL), m_called_functions (vNULL), m_hbb_count (0),
+  m_in_ssa (true), m_kern_p (kernel_p), m_declaration_p (false), m_decl (fdecl),
   m_shadow_reg (NULL), m_kernel_dispatch_count (0), m_maximum_omp_data_size (0),
-  m_seen_error (false)
+  m_seen_error (false), m_temp_symbol_count (0)
 {
   int sym_init_len = (vec_safe_length (cfun->local_decls) / 2) + 1;;
   m_local_symbols = new hash_table  (sym_init_len);
@@ -251,6 +251,7 @@ hsa_function_representation::~hsa_function_representation ()
 
   m_spill_symbols.release ();
   m_readonly_variables.release ();
+  m_private_variables.release ();
   m_called_functions.release ();
 }
 
@@ -284,6 +285,24 @@ bool hsa_function_representation::has_shadow_reg_p ()
   return m_shadow_reg != NULL;
 }
 
+void
+hsa_function_representation::init_extra_bbs ()
+{
+  hsa_init_new_bb (ENTRY_BLOCK_PTR_FOR_FN (cfun));
+  hsa_init_new_bb (EXIT_BLOCK_PTR_FOR_FN (cfun));
+}
+
+hsa_symbol *
+hsa_function_representation::create_hsa_temporary (BrigType16_t type)
+{
+  hsa_symbol *s = new hsa_symbol (type, BRIG_SEGMENT_PRIVATE,
+  BRIG_LINKAGE_FUNCTION);
+  s->m_name_number = m_temp_symbol_count++;
+
+  hsa_cfun->m_private_variables.safe_push (s);
+  return s;
+}
+
 /* Allocate HSA structures that we need only while generating with this.  */
 
 static void
@@ -1711,6 +1730,13 @@ process_mem_base (tree base, hsa_symbol **symbol, BrigType16_t *addrtype,
 gcc_unreachable ();
 }
 
+/* Forward declaration of a function.  */
+
+static void
+gen_hsa_addr_insns (tree val, hsa_op_reg *dest, hsa_bb *hbb,
+		vec  *ssa_map);
+
+
 /* Generate HSA address operand for a given tree memory reference REF.  If
instructions need to be created to calculate the address, they will be added
to the end of HBB, SSA_MAP is an array mapping gimple SSA names to HSA
@@ -1731,6 +1757,7 @@ gen_hsa_addr (tree ref, hsa_bb *hbb, vec  *ssa_map,
   tree varoffset = NULL_TREE;
   BrigType16_t addrtype = hsa_get_segment_addr_type (BRIG_SEGMENT_FLAT);
   HOST_WIDE_INT bitsize = 0, bitpos = 0;
+  BrigType16_t flat_addrtype = hsa_get_segment_addr_type (BRIG_SEGMENT_FLAT);
 
   if (TREE_CODE (ref) == STRING_CST)
 {
@@ -1762,8 +1789,27 @@ gen_hsa_addr (tree ref, hsa_bb *hbb, vec  *ssa_map,
   switch (TREE_CODE (ref))
 {
 case ADDR_EXPR:
-  gcc_unreachable ();
+  {
+	addrtype = hsa_get_segment_addr_type (BRIG_SEGMENT_PRIVATE);
+	symbol = hsa_cfun->create_hsa_temporary (flat_addrtype);
+	hsa_op_reg *r = new 

Re: [PATCH 9/9] ENABLE_CHECKING refactoring: C family front ends

[Jeff Law]

On 11/01/2015 07:58 AM, Mikhail Maltsev wrote:

Hi all!

This patch was intended to be the last one in this series (but I'll send one
more cleanup patch today). It removes ENABLE_CHECKING macros in the C++ front
end (and also touches a small piece of common C family code in OpenMP).

I could convert most of "#ifdef ENABLE_CHECKING" conditions into checks
performed at run time (i.e. flag_checking), except for
GET_NON_DEFAULT_TEMPLATE_ARGS_COUNT logic. The definition of this macro depends
on ENABLE_CHECKING (now CHECKING_P) and frankly speaking I don't know how these
checks should work (though I did not try hard to understand the details, I hope
Jason will give some comments), so I left them as-is, just got rid of
conditional compilation (i.e., used CHECKING_P).

Also, the patch renames 'check_unstripped_args' into 'verify_unstripped_args'
because I think it's more consistent with names of other internal state checking
functions.

Bootstrapped and regtested on x86_64-pc-linux-gnu with --enable-checking=yes and
--enable-checking=release. (there were some problems with languages other than C
and C++, not related to the patch, but ISTM they were fixed, so I'm currently
running a second check after rebasing).




@@ -14279,8 +14272,9 @@ tsubst_copy (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
return tsubst_binary_right_fold (t, args, complain, in_decl);

  default:
-  /* We shouldn't get here, but keep going if !ENABLE_CHECKING.  */
-  gcc_checking_assert (false);
+  /* We shouldn't get here, but keep going if !flag_checking.  */
+  if (!flag_checking)
+   gcc_unreachable ();
return t;
  }
  }

I think this condition was reversed, right?

Please fix that and install on the trunk.

Thanks again!

jeff

Re: [PATCH, 3/6] Add recursion to make_param_constraints

[Tom de Vries]

On 02/11/15 16:25, Richard Biener wrote:

On Sun, 1 Nov 2015, Tom de Vries wrote:


>On 01/11/15 19:03, Tom de Vries wrote:

> >
> >So, the new patch series is:
> >
> >   1Rename make_restrict_var_constraints to make_param_constraints
> >   2Handle recursive restrict in function parameter
> >
> >I'll repost in reply to this message.

>
>This no-functional-changes patch:
>- moves the one constraint handling loop left in
>intra_create_variable_infos to make_restrict_var_constraints
>- renames make_restrict_var_constraints to make_param_constraints
>- adds a parameter toplevel to make_param_constraints to distinguish
>between the two calling contexts
>- adds a parmeter restrict_name that allows to pass in the name of
>   restrict vars
>
>This patch was posted before at
>https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03111.html  .

+ if (toplevel)
+   make_constraint_from (vi, nonlocal_id);
+ else
+   make_copy_constraint (vi, nonlocal_id);

I think make_constraint_from is what we want in both cases.



Committed as separate patch, as attached (1st patch).


Ok with this change (thus drop the toplevel parameter).



Committed as attached (2nd patch).

Thanks,
- Tom

Replace make_copy_constraint with make_constraint_from in make_restrict_var_constraints

2015-11-02  Tom de Vries  

	* tree-ssa-structalias.c (make_restrict_var_constraints): Replace
	make_copy_constraint call with make_constraint_from call.
---
 gcc/tree-ssa-structalias.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index 55f72a2..773731d 100644
--- a/gcc/tree-ssa-structalias.c
+++ b/gcc/tree-ssa-structalias.c
@@ -5890,7 +5890,7 @@ make_restrict_var_constraints (varinfo_t vi)
 	if (vi->only_restrict_pointers)
 	  make_constraint_from_global_restrict (vi, "GLOBAL_RESTRICT", true);
 	else
-	  make_copy_constraint (vi, nonlocal_id);
+	  make_constraint_from (vi, nonlocal_id);
   }
 }
 
-- 
1.9.1

Rename make_restrict_var_constraints to make_param_constraints

2015-10-27  Tom de Vries  

	* tree-ssa-structalias.c (make_restrict_var_constraints): Rename to ...
	(make_param_constraints): ... this.  Add and handle restrict_name
	parameter.  Handle is_full_var case.
	(intra_create_variable_infos): Use make_param_constraints.
---
 gcc/tree-ssa-structalias.c | 33 ++---
 1 file changed, 14 insertions(+), 19 deletions(-)

diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index 773731d..ded5a1e 100644
--- a/gcc/tree-ssa-structalias.c
+++ b/gcc/tree-ssa-structalias.c
@@ -5879,19 +5879,22 @@ debug_solution_for_var (unsigned int var)
   dump_solution_for_var (stderr, var);
 }
 
-/* Register the constraints for restrict var VI.  */
+/* Register the constraints for function parameter related VI.  Use RESTRICT_NAME
+   as the base name of created restrict vars.  */
 
 static void
-make_restrict_var_constraints (varinfo_t vi)
+make_param_constraints (varinfo_t vi, const char *restrict_name)
 {
   for (; vi; vi = vi_next (vi))
-if (vi->may_have_pointers)
-  {
-	if (vi->only_restrict_pointers)
-	  make_constraint_from_global_restrict (vi, "GLOBAL_RESTRICT", true);
-	else
-	  make_constraint_from (vi, nonlocal_id);
-  }
+{
+  if (vi->only_restrict_pointers)
+	make_constraint_from_global_restrict (vi, restrict_name, true);
+  else if (vi->may_have_pointers)
+	make_constraint_from (vi, nonlocal_id);
+
+  if (vi->is_full_var)
+	break;
+}
 }
 
 /* Create varinfo structures for all of the variables in the
@@ -5928,19 +5931,11 @@ intra_create_variable_infos (struct function *fn)
 	  vi->is_restrict_var = 1;
 	  insert_vi_for_tree (heapvar, vi);
 	  make_constraint_from (p, vi->id);
-	  make_restrict_var_constraints (vi);
+	  make_param_constraints (vi, "GLOBAL_RESTRICT");
 	  continue;
 	}
 
-  for (; p; p = vi_next (p))
-	{
-	  if (p->only_restrict_pointers)
-	make_constraint_from_global_restrict (p, "PARM_RESTRICT", true);
-	  else if (p->may_have_pointers)
-	make_constraint_from (p, nonlocal_id);
-	  if (p->is_full_var)
-	break;
-	}
+  make_param_constraints (p, "PARM_RESTRICT");
 }
 
   /* Add a constraint for a result decl that is passed by reference.  */
-- 
1.9.1

Re: [gofrontend-dev] Re: libgo patch committed: Update to Go 1.5 release

[Ian Lance Taylor]

On Mon, Nov 2, 2015 at 12:59 PM, Lynn A. Boger
 wrote:
>
> I assume there will be a different number for the libgo.so for Go 1.5?

Thanks for the reminder.  I committed this patch to bump the version number.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 229676)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-3b06572039eb525abfecce15f066ad6ab0fdea05
+28fbc7f42702ce081ef5f3ce9a1dbc1ed3f3c89e
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/configure.ac
===
--- libgo/configure.ac  (revision 228306)
+++ libgo/configure.ac  (working copy)
@@ -11,7 +11,7 @@ AC_INIT(package-unused, version-unused,,
 AC_CONFIG_SRCDIR(Makefile.am)
 AC_CONFIG_HEADER(config.h)
 
-libtool_VERSION=7:0:0
+libtool_VERSION=8:0:0
 AC_SUBST(libtool_VERSION)
 
 AM_ENABLE_MULTILIB(, ..)