[C PATCH] Don't leak C_MAYBE_CONST_EXPRs into fold() (PR c/68412)

2015-11-18 Thread Marek Polacek
Since C++ delayed folding, warn_tautological_cmp needs to fold its arguments.
But sometimes this function gets C_MAYBE_CONST_EXPR from the C FE, and fold()
duly ICEs.

I was torn if I should just return from warn_tautological_cmp and not warn
when it gets C_MAYBE_CONST_EXPR as an argument, or if I should strip
C_MAYBE_CONST_EXPR before calling warn_tautological_cmp.  I decided for the
latter since I think warn_tautological_cmp probably should warn on code such
as
  int i = 10;
  bool b = ({ i; }) == ({ i; });
(ugh).

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

2015-11-18  Marek Polacek  

PR c/68412
* c-typeck.c (parser_build_binary_op): Strip C_MAYBE_CONST_EXPR
when passing arguments to warn_tautological_compare.

* gcc.dg/pr68412.c: New test.
* gcc.dg/pr68412-2.c: New test.

diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index c18c307..48c1a98 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -3512,7 +3512,11 @@ parser_build_binary_op (location_t location, enum 
tree_code code,
   code1, arg1.value, code2, arg2.value);
 
   if (warn_tautological_compare)
-warn_tautological_cmp (location, code, arg1.value, arg2.value);
+warn_tautological_cmp (location, code,
+  /* This function will try to fold both
+ args, so don't leak C_MAYBE_CONST_EXPR.  */
+  remove_c_maybe_const_expr (arg1.value),
+  remove_c_maybe_const_expr (arg2.value));
 
   if (warn_logical_not_paren
   && TREE_CODE_CLASS (code) == tcc_comparison
diff --git gcc/testsuite/gcc.dg/pr68412-2.c gcc/testsuite/gcc.dg/pr68412-2.c
index e69de29..be1dcfa 100644
--- gcc/testsuite/gcc.dg/pr68412-2.c
+++ gcc/testsuite/gcc.dg/pr68412-2.c
@@ -0,0 +1,15 @@
+/* PR c/68412 */
+/* { dg-do compile } */
+/* { dg-options "-Wall -Wextra" } */
+
+int
+fn1 (int i)
+{
+  return ({ i; }) == ({ i; }); /* { dg-warning "self-comparison always 
evaluates to true" } */
+}
+
+int
+fn2 (int i)
+{
+  return ({ i + 1; }) != ({ i + 1; }); /* { dg-warning "self-comparison always 
evaluates to false" } */
+}
diff --git gcc/testsuite/gcc.dg/pr68412.c gcc/testsuite/gcc.dg/pr68412.c
index e69de29..825eb63 100644
--- gcc/testsuite/gcc.dg/pr68412.c
+++ gcc/testsuite/gcc.dg/pr68412.c
@@ -0,0 +1,41 @@
+/* PR c/68412 */
+/* { dg-do compile } */
+/* { dg-options "-Wall -Wextra" } */
+
+#define M (sizeof (int) * __CHAR_BIT__)
+
+int
+fn1 (int i)
+{
+  return i == (-1 << 8); /* { dg-warning "left shift of negative value" } */
+}
+
+int
+fn2 (int i)
+{
+  return i == (1 << M); /* { dg-warning "left shift count" } */
+}
+
+int
+fn3 (int i)
+{
+  return i == 10 << (M - 1); /* { dg-warning "requires" } */
+}
+
+int
+fn4 (int i)
+{
+  return i == 1 << -1; /* { dg-warning "left shift count" } */
+}
+
+int
+fn5 (int i)
+{
+  return i == 1 >> M; /* { dg-warning "right shift count" } */
+}
+
+int
+fn6 (int i)
+{
+  return i == 1 >> -1; /* { dg-warning "right shift count" } */
+}

Marek


Re: teach delay folding in c++ about OACC_LOOPs

2015-11-18 Thread Nathan Sidwell

On 11/18/15 10:14, Cesar Philippidis wrote:

Jason,

Your recent delay folding patch broke libgomp.oacc-c++/loop-auto-1.c. It
looks like you forgot to handle OACC_LOOP in cp_fold_r. You probably
didn't notice this because Nathan committed his auto acc loop patch just
before you applied your patch. I'm not sure why only that test is
affected though.

Is this patch ok for trunk?


Hey, once again you've saved me an investigation :)

I'd say this counts as obvious, so go ahead and commit.

nathan



RE: [PATCH 1/4 v2][AArch64] Generalize CCMP support

2015-11-18 Thread Wilco Dijkstra
Bernd Schmidt wrote:
> Sent: 17 November 2015 22:16
> To: Wilco Dijkstra; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH 1/4][AArch64] Generalize CCMP support
> 
> On 11/13/2015 05:02 PM, Wilco Dijkstra wrote:
> > * gcc/ccmp.c (expand_ccmp_expr): Extract cmp_code from return
> value
> > of
> > expand_ccmp_expr_1.
> 
> I was trying to review this part of the patch in isolation and got very
confused
> because the patch also changes the return values of the ccmp target hooks,
> but does not update the documentation.
> 
> In this file, return values are also underdocumented in function comments.

I've updated the comments and documentation, see below. I hope it makes
sense now - returning rtx that computes the same value as the tree
expression
we're emitting is the most useful thing one can do. 

> Also,
> 
>  > +  enum rtx_code cmp_code = GET_CODE (tmp);
> 
> Lose the "enum". Elsewhere in the patch too.
> 
> Other than that this part is probably fine (leaving the aarch64 part to
the
> appropriate maintainers), but please resubmit with these issues fixed.

I removed the enum here and updated the other patches as well.

Wilco

2015-11-18  Wilco Dijkstra  

* gcc/target.def (gen_ccmp_first): Update documentation.
(gen_ccmp_next): Likewise.
* gcc/doc/tm.texi (gen_ccmp_first): Update documentation.
(gen_ccmp_next): Likewise.
* gcc/ccmp.c (expand_ccmp_expr): Extract cmp_code from return value
of
expand_ccmp_expr_1.  Improve comments.
* gcc/config/aarch64/aarch64.md (ccmp_and): Use if_then_else for
ccmp.
(ccmp_ior): Remove pattern.
(cmp): Remove expand.
(cmp): Globalize pattern.
(cstorecc4): Use cc_register.
(movcc): Remove ccmp_cc_register check.
* gcc/config/aarch64/aarch64.c (aarch64_get_condition_code_1):
Simplify after removal of CC_DNE/* modes.
(aarch64_ccmp_mode_to_code): Remove.
(aarch64_print_operand): Remove 'K' case.  Merge 'm' and 'M' cases.
In 'k' case use integer as condition.
(aarch64_nzcv_codes): Remove inverted cases.
(aarch64_code_to_ccmode): Remove.
(aarch64_gen_ccmp_first): Use cmp pattern directly.  Return the
correct 
comparison with CC register to be used in folowing CCMP/branch/CSEL.
(aarch64_gen_ccmp_next): Use previous comparison and mode in CCMP
pattern.  Return the comparison with CC register.  Invert conditions
when bitcode is OR.
* gcc/config/aarch64/aarch64-modes.def: Remove CC_DNE/* modes.
* gcc/config/aarch64/predicates.md (ccmp_cc_register): Remove.


---
 gcc/ccmp.c   |  21 ++-
 gcc/config/aarch64/aarch64-modes.def |  10 --
 gcc/config/aarch64/aarch64.c | 305
---
 gcc/config/aarch64/aarch64.md|  68 ++--
 gcc/config/aarch64/predicates.md |  17 --
 gcc/doc/tm.texi  |  36 ++---
 gcc/target.def   |  36 ++---
 7 files changed, 128 insertions(+), 365 deletions(-)

diff --git a/gcc/ccmp.c b/gcc/ccmp.c
index 20348d9..58ac126 100644
--- a/gcc/ccmp.c
+++ b/gcc/ccmp.c
@@ -65,6 +65,10 @@ along with GCC; see the file COPYING3.  If not see
 - gen_ccmp_first expands the first compare in CCMP.
 - gen_ccmp_next expands the following compares.
 
+   Both hooks return a comparison with the CC register that is
equivalent
+   to the value of the gimple comparison.  This is used by the next
CCMP
+   and in the final conditional store.
+
  * We use cstorecc4 pattern to convert the CCmode intermediate to
the integer mode result that expand_normal is expecting.
 
@@ -130,10 +134,12 @@ ccmp_candidate_p (gimple *g)
   return false;
 }
 
-/* PREV is the CC flag from precvious compares.  The function expands the
-   next compare based on G which ops previous compare with CODE.
+/* PREV is a comparison with the CC register which represents the
+   result of the previous CMP or CCMP.  The function expands the
+   next compare based on G which is ANDed/ORed with the previous
+   compare depending on CODE.
PREP_SEQ returns all insns to prepare opearands for compare.
-   GEN_SEQ returnss all compare insns.  */
+   GEN_SEQ returns all compare insns.  */
 static rtx
 expand_ccmp_next (gimple *g, enum tree_code code, rtx prev,
  rtx *prep_seq, rtx *gen_seq)
@@ -226,7 +232,7 @@ expand_ccmp_expr_1 (gimple *g, rtx *prep_seq, rtx
*gen_seq)
   return NULL_RTX;
 }
 
-/* Main entry to expand conditional compare statement G. 
+/* Main entry to expand conditional compare statement G.
Return NULL_RTX if G is not a legal candidate or expand fail.
Otherwise return the target.  */
 rtx
@@ -249,9 +255,10 @@ expand_ccmp_expr (gimple *g)
   enum insn_code icode;
   enum machine_mode cc_mode = CCmode;
   tree lhs = gimple_assign_lhs (g);
+  rtx_code cmp_code = GET_CODE (tmp);
 
 #ifdef SELECT_CC_MODE

Re: [PATCH 1/4 v2][AArch64] Generalize CCMP support

2015-11-18 Thread Bernd Schmidt

On 11/17/2015 07:35 PM, Wilco Dijkstra wrote:


I've updated the comments and documentation, see below. I hope it makes
sense now - returning rtx that computes the same value as the tree
expression
we're emitting is the most useful thing one can do.


The target-independent part is ok. Note that some of the documentation 
parts were word-wrapped; please check that you've not exceeded the line 
lengths, and make sure you send future patches in a way that doesn't 
suffer from that (text/plain attachments for example).



Bernd



Re: [gomp4.1] Handle linear clause modifiers in declare simd

2015-11-18 Thread Ilya Verbin
Hi!

On Wed, Jul 01, 2015 at 12:55:38 +0200, Jakub Jelinek wrote:
> I've committed following patch, which per the new ABI additions
> mangles and handles the various new linear clause modifiers in
> declare simd functions.  The vectorizer side is not done yet,
>
> [...]
>
> @@ -14195,12 +14216,25 @@ simd_clone_mangle (struct cgraph_node *n
>  {
>struct cgraph_simd_clone_arg arg = clone_info->args[n];
>  
> -  if (arg.arg_type == SIMD_CLONE_ARG_TYPE_UNIFORM)
> - pp_character (, 'u');
> -  else if (arg.arg_type == SIMD_CLONE_ARG_TYPE_LINEAR_CONSTANT_STEP)
> +  switch (arg.arg_type)
>   {
> -   gcc_assert (arg.linear_step != 0);
> + case SIMD_CLONE_ARG_TYPE_UNIFORM:
> +   pp_character (, 'u');
> +   break;
> + case SIMD_CLONE_ARG_TYPE_LINEAR_CONSTANT_STEP:
> pp_character (, 'l');
> +   goto mangle_linear;
> + case SIMD_CLONE_ARG_TYPE_LINEAR_REF_CONSTANT_STEP:
> +   pp_character (, 'R');
> +   goto mangle_linear;
> + case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_CONSTANT_STEP:
> +   pp_character (, 'L');
> +   goto mangle_linear;
> + case SIMD_CLONE_ARG_TYPE_LINEAR_UVAL_CONSTANT_STEP:
> +   pp_character (, 'U');
> +   goto mangle_linear;
> + mangle_linear:
> +   gcc_assert (arg.linear_step != 0);

Could you please point to where the new ABI additions are documented?
I can't find R/L/U parameter types in [1] and [2].

[1] 
https://sourceware.org/glibc/wiki/libmvec?action=AttachFile=view=VectorABI.txt
[2] https://groups.google.com/forum/#!topic/x86-64-abi/LmppCfN1rZ4

Thanks,
  -- Ilya


Re: [PATCH] Add clang-format config to contrib folder

2015-11-18 Thread Jeff Law

On 11/18/2015 10:34 AM, Manuel López-Ibáñez wrote:


Which is a sad demonstration of how the refusal of GCC's FEs being
re-used for other purposes by GNU tools (and others) was and is a
mistake, and it is leading to GNU tools being replaced by LLVM-based
ones (ultimately affecting GCC and GDB themselves).
I think most developers would agree at this point.  Some may have always 
agreed.  But it was the decision of the FSF long ago to design GCC in 
this way and anyone working on GCC had to abide by that decision.


Things are changing, but undoing that fundamental design decision is a 
*lot* of work.   Don't expect it to land anytime soon.



jeff




Re: [gomp4.1] Handle linear clause modifiers in declare simd

2015-11-18 Thread Jakub Jelinek
On Wed, Nov 18, 2015 at 08:30:53PM +0300, Ilya Verbin wrote:
> Could you please point to where the new ABI additions are documented?
> I can't find R/L/U parameter types in [1] and [2].
> 
> [1] 
> https://sourceware.org/glibc/wiki/libmvec?action=AttachFile=view=VectorABI.txt
> [2] https://groups.google.com/forum/#!topic/x86-64-abi/LmppCfN1rZ4

Xinmin should have those in the Intel ABI pdf, not sure if the latest pdf
is publicly available or not.

Jakub


Re: [Patch,testsuite]: Fix the tree-ssa/split-path-1.c testcase

2015-11-18 Thread Jeff Law

On 11/18/2015 07:21 AM, Ajit Kumar Agarwal wrote:


Hello Jeff:

Please ignore my previous mails as they bounced back. Sorry for that.

I have fixed the problem with the testcase. The splitting path optimization 
remains intact.
Attached is the patch.

The problem was related to the testcase as the loop bound goes beyond the 
malloced array.
There was also a problem with accessing the elements of EritePtr.

ChangeLog:
2015-11-18  Ajit Agarwal  

 * gcc.dg/tree-ssa/split-path-1.c: Fix the testcase.

THanks.  Installed.

I wasn't sure why you needed , but I left it as-is.

jeff



Re: [PATCH] Add clang-format config to contrib folder

2015-11-18 Thread Jeff Law

On 11/18/2015 07:10 AM, Martin Liška wrote:

Hello.

Following patch adds a clang-format config file that should respect the GNU 
coding standards.
As the file is not part of build process, I hope the patch can be applied even 
though
we've just skipped to stage3? The patch adds a hunk to Makefile which can 
create symlink
to the root directory of the GCC compiler. The clang-format automatically loads 
style from
the configuration file.

clang-format (version 3.8) provides rich variety of configuration options that 
can
ensure the GNU coding style.

Limitations:
+ placement of opening brace of an initializer can't be requested
+ sometimes, '(' is the trailing symbol at the end of a line, which can look 
weird

As we've been continuously converting our source base to C++, the clang-format 
should
provide better results than a collection of regular expressions 
(check_GNU_style.sh).

As a reference file I attach gcc/tree-ssa-uninit.c file.
Feel free to comment the suggested configuration file.
This is fine.  Given that gnu-indent seems to muck up C++ badly in my 
experience, clang-format may be a better long term solution.  I'd really 
like to get to a point one day where formatting is a commit hook so that 
things are always kept properly formatted.


jeff


Re: [PATCH] Add clang-format config to contrib folder

2015-11-18 Thread Manuel López-Ibáñez

On 18/11/15 17:05, Jeff Law wrote:

As we've been continuously converting our source base to C++, the
clang-format should
provide better results than a collection of regular expressions
(check_GNU_style.sh).

As a reference file I attach gcc/tree-ssa-uninit.c file.
Feel free to comment the suggested configuration file.

This is fine.  Given that gnu-indent seems to muck up C++ badly in my
experience, clang-format may be a better long term solution.  I'd really like
to get to a point one day where formatting is a commit hook so that things are
always kept properly formatted.


Which is a sad demonstration of how the refusal of GCC's FEs being re-used for 
other purposes by GNU tools (and others) was and is a mistake, and it is 
leading to GNU tools being replaced by LLVM-based ones (ultimately affecting 
GCC and GDB themselves).


Cheers,

Manuel.


Re: [C PATCH] Don't leak C_MAYBE_CONST_EXPRs into fold() (PR c/68412)

2015-11-18 Thread Marek Polacek
On Wed, Nov 18, 2015 at 05:24:34PM +0100, Bernd Schmidt wrote:
> That seems to change the behaviour of the code though. Most of the code in
> warn_tautological_cmp only looks at the unfolded form. Are you sure this is
> safe, for example wrt. the from_macro_expansion_at tests or the
> CONVERT_EXPR_P ones?

Of course the second version is wrong wrt CONVERT_EXPR_P, because it would
regress g++.dg/warn/Wtautological-compare.C -- with the fold() in the C++
FE we'd get rid of the CONVERT_EXPR_P completely and we'd warn.

Sorry :(.  So I guess scratch the second version and let's get back to the
first one.  Jason's r230471 was a correct thing to do.

Marek


Re: [PATCH] Fix memory leaks in tree-ssa-uninit.c

2015-11-18 Thread Jeff Law

On 11/18/2015 07:23 AM, Martin Liška wrote:

On 11/13/2015 08:19 PM, Jeff Law wrote:

On 11/13/2015 09:58 AM, Martin Liška wrote:

On 11/13/2015 05:32 PM, Jeff Law wrote:

On 11/13/2015 05:50 AM, Martin Liška wrote:

Hello.

Patch survives regbootstrap on x86_64-linux-gnu.
Ready for trunk?

Thanks,
Martin


0001-Fix-memory-leaks-in-tree-ssa-uninit.c.patch


   From 54851503251dee7a8bd074485db262715e628728 Mon Sep 17 00:00:00 2001
From: marxin
Date: Fri, 13 Nov 2015 12:23:22 +0100
Subject: [PATCH] Fix memory leaks in tree-ssa-uninit.c

gcc/ChangeLog:

2015-11-13  Martin Liska

  * tree-ssa-uninit.c (convert_control_dep_chain_into_preds):
  Fix GNU coding style.
  (find_def_preds): Use auto_vec.
  (destroy_predicate_vecs): Change signature of the function.
  (prune_uninit_phi_opnds_in_unrealizable_paths): Use the
  new signature.
  (simplify_preds_4): Use destroy_predicate_vecs instread of
  just releasing preds vector.
  (normalize_preds): Likewise.
  (is_use_properly_guarded): Use new signature of
  destroy_predicate_vecs.
  (find_uninit_use): Likewise.

OK.

FWIW, there's all kinds of spaces vs tabs issues in this file.  I'm curious why 
you chose to fix convert_control_dep_chain_into_preds, but didn't change any 
others.


Hi Jeff.

Thanks for confirmation, you are right, it's full of coding style issues. I can 
change these if it would be desired?

It's probably a good thing to do.  Given it'd strictly be formatting, I'd even 
consider it post-stage1.

jeff


Hello.

I'm sending the re-formatted source file.

The source file was formatted by clang-format ([1]) and some hunk were manually 
re-formatted.
No change in behavior.

Patch can regbootstrap on x86_64-linux-gnu.

Ready for trunk?

OK.

jeff



Re: [PATCH, VECTOR ABI] Add __attribute__((__simd__)) to GCC.

2015-11-18 Thread Jeff Law

On 11/18/2015 07:11 AM, Kirill Yukhin wrote:

Hello Andreas, Devid.

On 18 Nov 10:45, Andreas Schwab wrote:

Kirill Yukhin  writes:


diff --git a/gcc/testsuite/c-c++-common/attr-simd.c 
b/gcc/testsuite/c-c++-common/attr-simd.c
new file mode 100644
index 000..b4eda34
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/attr-simd.c
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+/* { dg-options "-fdump-tree-optimized" } */
+
+__attribute__((__simd__))
+extern
+int simd_attr (void)
+{
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump "simd_attr\[ \\t\]simdclone|vector" "optimized" 
} } */


On ia64:

FAIL: c-c++-common/attr-simd.c  -Wc++-compat   scan-tree-dump optimized "simd_attr[ 
\\t]simdclone|vector"
FAIL: c-c++-common/attr-simd.c  -Wc++-compat   scan-tree-dump optimized "simd_attr2[ 
\\t]simdclone|vector"

$ grep simd_attr attr-simd.c.194t.optimized
;; Function simd_attr (simd_attr, funcdef_no=0, decl_uid=1389, cgraph_uid=0, 
symbol_order=0)
simd_attr ()
;; Function simd_attr2 (simd_attr2, funcdef_no=1, decl_uid=1392, cgraph_uid=1, 
symbol_order=1)
simd_attr2 ()

As far as vABI is supported on x86_64/i?86 only, I am going to enable mentioned 
`scan-tree-dump' only
for these targets. This should cure both IA64 and Power.

Concerning attr-simd-3.c. It is known issue: PR68158.
And I believe this test should work everywhere as far as PR is resolved.
I'll put xfail into the test.
Which will lead to (in g++.log):
gcc/testsuite/c-c++-common/attr-simd-3.c:5:48: warning: '__simd__' attribute 
does not apply to types\
  [-Wattributes]^M
output is:
gcc/testsuite/c-c++-common/attr-simd-3.c:5:48: warning: '__simd__' attribute 
does not apply to types\
  [-Wattributes]^M

XFAIL: c-c++-common/attr-simd-3.c  -std=gnu++98 PR68158 (test for errors, line 
5)
FAIL: c-c++-common/attr-simd-3.c  -std=gnu++98 (test for excess errors)
Excess errors:
gcc/testsuite/c-c++-common/attr-simd-3.c:5:48: warning: '__simd__' attribute 
does not apply to types\
  [-Wattributes]

Patch in the bottom.

gcc/tessuite/
* c-c++-common/attr-simd-3.c: Put xfail (PR68158) on dg-error.
* c-c++-common/attr-simd.c: Limit scan of dump to x86_64/i?86.
This is fine.  Though we might consider whether or not we need another 
target-supports if we find ourselves sprinkling too many target 
conditionals on these tests.


jeff



Re: libgomp: Compile-time error for non-portable gomp_mutex_t initialization

2015-11-18 Thread Ilya Verbin
On Fri, Sep 25, 2015 at 17:28:25 +0200, Jakub Jelinek wrote:
> On Fri, Sep 25, 2015 at 05:04:47PM +0200, Thomas Schwinge wrote:
> > On Thu, 26 Mar 2015 23:41:30 +0300, Ilya Verbin  wrote:
> > > On Thu, Mar 26, 2015 at 13:09:19 +0100, Jakub Jelinek wrote:
> > > > the current code is majorly broken.  As I've said earlier, e.g. the lack
> > > > of mutex guarding gomp_target_init (which is using pthread_once 
> > > > guaranteed
> > > > to be run just once) vs. concurrent GOMP_offload_register calls
> > > > (if those are run from ctors, then I guess something like dl_load_lock
> > > > ensures at least on glibc that multiple GOMP_offload_register calls 
> > > > aren't
> > > > performed at the same time) in accessing/reallocating offload_images
> > > > and num_offload_images and the lack of support to register further
> > > > images after the gomp_target_init call (if you dlopen further shared
> > > > libraries) is really bad.  And it would be really nice to support the
> > > > unloading.
> > 
> > > Here is the latest patch for libgomp and mic plugin.
> > 
> > > libgomp/
> > 
> > >   * target.c (register_lock): New mutex for offload image registration.
> > 
> > >   (GOMP_offload_register): Add mutex lock.
> 
> That is definitely wrong.  You'd totally break --disable-linux-futex support
> on linux and bootstrap on e.g. Solaris and various other pthread targets.

I don't quite understand, do you mean that gcc 5 and trunk are broken, because
register_lock doesn't have initialization?  But it seems that bootstrap on
Solaris and other targets works fine...

> At least for ELF and dynamic linking, shared libraries that contain
> constructors that call GOMP_offload_register* should have DT_NEEDED libgomp
> and thus libgomp's constructors should be run before the constructors of
> the libraries that call GOMP_offload_register*.

So, libgomp should contain a constructor, which will call gomp_mutex_init
(_lock) before any call to GOMP_offload_register*, right?

> For the targets without known zero initializer for gomp_mutex_lock, either
> there is an option to use pthread_once to make sure it is initialized once,
> or there is an option to define a macro like GOMP_MUTEX_INITIALIZER,
> defined to PTHREAD_MUTEX_INITIALIZER in config/posix/mutex.h and to
> { 0 } in config/linux/mutex.h and something like {} or whatever in
> config/rtems/mutex.h.  Then for the non-automatic non-heap
> gomp_mutex_t's you could just initialize them in their initializers
> with GOMP_MUTEX_INITIALIZER.

  -- Ilya


Re: [patch] Fix PR middle-end/65958

2015-11-18 Thread Eric Botcazou
> Ah.  I think the patch is good and we should reflect this in the
> documentation.

OK, will do, thanks.

-- 
Eric Botcazou


Re: [PATCH, 10/16] Add pass_oacc_kernels pass group in passes.def

2015-11-18 Thread Bernhard Reutner-Fischer
On November 18, 2015 9:30:23 AM GMT+01:00, Richard Biener  
wrote:
>On Tue, 17 Nov 2015, Tom de Vries wrote:
>
>> On 17/11/15 16:18, Richard Biener wrote:
>> > > > IMHO autopar needs to handle induction itself.
>> > > >
>> > > >I'm not sure what you mean. Could you elaborate?  Autopar
>handles
>> > > induction
>> > > >variables, but it doesn't handle exit phis reading the final
>value of the
>> > > >induction variable. Is that what you want fixed? How?
>> > Yes.  Perform final value replacement.
>> > 
>> 
>> I see. Calling scev_const_prop in pass_parallelize_loops_oacc_kernels
>seems to
>> work fine.
>> 
>> Doing the same for pass_parallelize_loops like this:
>> ...
>> diff --git a/gcc/tree-parloops.c b/gcc/tree-parloops.c
>> index 17415a8..d944395 100644
>> --- a/gcc/tree-parloops.c
>> +++ b/gcc/tree-parloops.c
>> @@ -2787,6 +2787,9 @@ pass_parallelize_loops::execute (function *fun)
>>if (number_of_loops (fun) <= 1)
>>  return 0;
>> 
>> +  unsigned int sccp_todo = scev_const_prop ();
>> +  gcc_assert (sccp_todo == 0);
>> +
>>if (parallelize_loops ())
>>  {
>>fun->curr_properties &= ~(PROP_gimple_eomp);
>> ...
>> seems to fix PR 68373 - "autopar fails on loop exit phi with argument
>defined
>> outside loop".
>> 
>> The new scev_const_prop call in autopar rewrites this phi into an
>assignment,
>> and that allows parloops to succeed:
>> ...
>> final value replacement:
>>   n_2 = PHI 
>>   with
>>   n_2 = n_4(D);
>> ...
>
>That works for me but please factor out the final value replacement
>code from scev_const_prop.  I think best would be to have a
>helper that does final value replacement for a single loop so you
>can call it for loops to paralellize only.

Bonus points for fixing the dump_file to parse in:

>Parloops will fail because:
>...
>phi is n_2 = PHI 
>arg of phi to exit: value n_4(D) used outside loop
>checking if it a part of reduction pattern:

s/it a/it is/

>FAILED: it is not a part of reduction
>...

TIA,
>
>Richard.
>
>> Thanks,
>> - Tom
>> 
>> 




PR 68393: Handle SUBREG_PROMOTED_VAR_P in expand_direct_optab_fn

2015-11-18 Thread Richard Sandiford
Do the usual dance when assigning to SUBREG_PROMOTED_VAR_P destinations:
first convert to the outer mode, then extend to the inner mode.
This fixes the powerpc64le bootstrap failure reported in PR 68393.

Tested that it fixes the powerpc64le-linux-gnu breakage.  Also tested
on x86_64-linux-gnu and powerpc64-linux-gnu.  OK to install?

Thanks,
Richard

PS. Sorry for the delay in fixing this.  I posted a patch to bugzilla
yesterday to fix the case where the modes of the lhs and .md pattern
are different, but we need the same behaviour when the modes are the same.


gcc/
PR bootstrap/68393
* internal-fn.c (expand_direct_optab_fn): Handle SUBREG_PROMOTED_VAR_P
destinations.

diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
index df3b7dc..bc77bdc 100644
--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -2124,14 +2124,30 @@ expand_direct_optab_fn (internal_fn fn, gcall *stmt, 
direct_optab optab,
   expand_insn (icode, nargs + 1, ops);
   if (!rtx_equal_p (lhs_rtx, ops[0].value))
 {
-  if (INTEGRAL_TYPE_P (lhs_type))
-   /* Convert the operand to the required type, which is useful
-  for things that return an int regardless of the size of
-  the input.  If the value produced by the instruction is
-  smaller than required, assume that it is signed.  */
-   convert_move (lhs_rtx, ops[0].value, 0);
-  else
+  /* If the return value has an integral type, convert the instruction
+result to that type.  This is useful for things that return an
+int regardless of the size of the input.  If the instruction result
+is smaller than required, assume that it is signed.
+
+If the return value has a nonintegral type, its mode must match
+the instruction result.  */
+  if (GET_CODE (lhs_rtx) == SUBREG && SUBREG_PROMOTED_VAR_P (lhs_rtx))
+   {
+ /* If this is a scalar in a register that is stored in a wider
+mode than the declared mode, compute the result into its
+declared mode and then convert to the wider mode.  */
+ gcc_checking_assert (INTEGRAL_TYPE_P (lhs_type));
+ rtx tmp = convert_to_mode (GET_MODE (lhs_rtx), ops[0].value, 0);
+ convert_move (SUBREG_REG (lhs_rtx), tmp,
+   SUBREG_PROMOTED_SIGN (lhs_rtx));
+   }
+  else if (GET_MODE (lhs_rtx) == GET_MODE (ops[0].value))
emit_move_insn (lhs_rtx, ops[0].value);
+  else
+   {
+ gcc_checking_assert (INTEGRAL_TYPE_P (lhs_type));
+ convert_move (lhs_rtx, ops[0].value, 0);
+   }
 }
 }
 



Re: [patch] Fix PR middle-end/65958

2015-11-18 Thread Richard Biener
On Wed, Nov 18, 2015 at 3:28 PM, Eric Botcazou  wrote:
>> Looks good to me.  I also found the Arrays of Variable Length section
>> in extend.texi which also refers to alloca as doing the same.  We may
>> want to add a note there that you should not mix both and that only
>> VLAs (when not mixed with alloca) are freed at scope boundary.
>
> It's already there and in fact the current behavior is documented:
>
>  There are other differences between these two methods.  Space allocated
> with `alloca' exists until the containing _function_ returns.  The
> space for a variable-length array is deallocated as soon as the array
> name's scope ends.  (If you use both variable-length arrays and
> `alloca' in the same function, deallocation of a variable-length array
> also deallocates anything more recently allocated with `alloca'.)
>
> so we need to amend the documentation if we go for the patch.

Ah.  I think the patch is good and we should reflect this in the
documentation.

Richard.

> --
> Eric Botcazou


Re: [PATCH][ARM] PR 68149 Fix ICE in unaligned_loaddi split

2015-11-18 Thread Kyrill Tkachov

Ping.
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01253.html

Thanks,
Kyrill

On 10/11/15 17:32, Kyrill Tkachov wrote:

Hi all,

This ICE in this PR occurs when we're trying to split unaligned_loaddi into two 
SImode unaligned loads.
The problem is in the addressing mode.  When reload was picking the addressing 
mode we accepted an offset of
-256 because the mode in the pattern is advertised as DImode and that was 
accepted by the legitimate address
hooks because they thought it was a NEON load (DImode is in 
VALID_NEON_DREG_MODE). However, the splitter wants
to generate two normal SImode unaligned loads using that address, for which 
-256 is not valid, so we ICE
in gen_lowpart.

The only way unaligned_loaddi could be generated was through the 
gen_movmem_ldrd_strd expansion that implements
a memmove using LDRD and STRD sequences. If the memmove source is not aligned 
we can't use LDRDs so the code
generates unaligned_loaddi patterns and expects them to be split into two 
normal loads after reload. Similarly
for unaligned store destinations.

This patch just explicitly generates the two unaligned SImode loads or stores 
when appropriate inside
gen_movmem_ldrd_strd.  This makes the unaligned_loaddi and unaligned_storedi 
patterns unused, so we can remove them.

This patch fixes the ICe in gcc.target/aarch64/advsimd-intrinsics/vldX.c seen 
with
-mthumb -mcpu=cortex-a15 -mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee
so no new testcase is added.

Bootstrapped and tested on arm-none-linux-gnueabihf.

Ok for trunk?

Thanks,
Kyrill

2015-11-10  Kyrylo Tkachov  

PR target/68149
* config/arm/arm.md (unaligned_loaddi): Delete.
(unaligned_storedi): Likewise.
* config/arm/arm.c (gen_movmem_ldrd_strd): Don't generate
unaligned DImode memory ops.  Instead perform two back-to-back
unalgined SImode ops.




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

2015-11-18 Thread Richard Biener
On Wed, Nov 18, 2015 at 3:04 PM, Richard Biener
 wrote:
> On Sat, Nov 14, 2015 at 2:15 AM, Kugan
>  wrote:
>>
>> Attached is the latest version of the patch. With the patches
>> 0001-Add-new-SEXT_EXPR-tree-code.patch,
>> 0002-Add-type-promotion-pass.patch and
>> 0003-Optimize-ZEXT_EXPR-with-tree-vrp.patch.
>>
>> I did bootstrap on ppc64-linux-gnu, aarch64-linux-gnu and
>> x64-64-linux-gnu and regression testing on ppc64-linux-gnu,
>> aarch64-linux-gnu arm64-linux-gnu and x64-64-linux-gnu. I ran into three
>> issues in ppc64-linux-gnu regression testing. There are some other test
>> cases which needs adjustment for scanning for some patterns that are not
>> valid now.
>>
>> 1. rtl fwprop was going into infinite loop. Works with the following patch:
>> diff --git a/gcc/fwprop.c b/gcc/fwprop.c
>> index 16c7981..9cf4f43 100644
>> --- a/gcc/fwprop.c
>> +++ b/gcc/fwprop.c
>> @@ -948,6 +948,10 @@ try_fwprop_subst (df_ref use, rtx *loc, rtx
>> new_rtx, rtx_insn *def_insn,
>>int old_cost = 0;
>>bool ok;
>>
>> +  /* Value to be substituted is the same, nothing to do.  */
>> +  if (rtx_equal_p (*loc, new_rtx))
>> +return false;
>> +
>>update_df_init (def_insn, insn);
>>
>>/* forward_propagate_subreg may be operating on an instruction with
>
> Which testcase was this on?
>
>> 2. gcc.dg/torture/ftrapv-1.c fails
>> This is because we are checking for the  SImode trapping. With the
>> promotion of the operation to wider mode, this is i think expected. I
>> think the testcase needs updating.
>
> No, it is not expected.  As said earlier you need to refrain from promoting
> integer operations that trap.  You can use ! operation_no_trapping_overflow
> for this.
>
>> 3. gcc.dg/sms-3.c fails
>> It fails with  -fmodulo-sched-allow-regmoves  and OK when I remove it. I
>> am looking into it.
>>
>>
>> I also have the following issues based on the previous review (as posted
>> in the previous patch). Copying again for the review purpose.
>>
>> 1.
>>> you still call promote_ssa on both DEFs and USEs and promote_ssa looks
>>> at SSA_NAME_DEF_STMT of the passed arg.  Please call promote_ssa just
>>> on DEFs and fixup_uses on USEs.
>>
>> I am doing this to promote SSA that are defined with GIMPLE_NOP. Is
>> there anyway to iterate over this. I have added gcc_assert to make sure
>> that promote_ssa is called only once.
>
>   gcc_assert (!ssa_name_info_map->get_or_insert (def));
>
> with --disable-checking this will be compiled away so you need to do
> the assert in a separate statement.
>
>> 2.
>>> Instead of this you should, in promote_all_stmts, walk over all uses
>> doing what
>>> fixup_uses does and then walk over all defs, doing what promote_ssa does.
>>>
>>> +case GIMPLE_NOP:
>>> +   {
>>> + if (SSA_NAME_VAR (def) == NULL)
>>> +   {
>>> + /* Promote def by fixing its type for anonymous def.  */
>>> + TREE_TYPE (def) = promoted_type;
>>> +   }
>>> + else
>>> +   {
>>> + /* Create a promoted copy of parameters.  */
>>> + bb = single_succ (ENTRY_BLOCK_PTR_FOR_FN (cfun));
>>>
>>> I think the uninitialized vars are somewhat tricky and it would be best
>>> to create a new uninit anonymous SSA name for them.  You can
>>> have SSA_NAME_VAR != NULL and def _not_ being a parameter
>>> btw.
>>
>> I experimented with get_or_create_default_def. Here  we have to have a
>> SSA_NAME_VAR (def) of promoted type.
>>
>> In the attached patch I am doing the following and seems to work. Does
>> this looks OK?
>>
>> + }
>> +   else if (TREE_CODE (SSA_NAME_VAR (def)) != PARM_DECL)
>> + {
>> +   tree var = copy_node (SSA_NAME_VAR (def));
>> +   TREE_TYPE (var) = promoted_type;
>> +   TREE_TYPE (def) = promoted_type;
>> +   SET_SSA_NAME_VAR_OR_IDENTIFIER (def, var);
>> + }
>
> I believe this will wreck the SSA default-def map so you should do
>
>   set_ssa_default_def (cfun, SSA_NAME_VAR (def), NULL_TREE);
>   tree var = create_tmp_reg (promoted_type);
>   TREE_TYPE (def) = promoted_type;
>   SET_SSA_NAME_VAR_OR_IDENTIFIER (def, var);
>   set_ssa_default_def (cfun, var, def);
>
> instead.
>
>> I prefer to promote def as otherwise iterating over the uses and
>> promoting can look complicated (have to look at all the different types
>> of stmts again and do the right thing as It was in the earlier version
>> of this before we move to this approach)
>>
>> 3)
>>> you can also transparently handle constants for the cases where promoting
>>> is required.  At the moment their handling is interwinded with the def
>> promotion
>>> code.  That makes the whole thing hard to follow.
>>
>>
>> I have updated the comments with:
>>
>> +/* Promote constants in STMT to TYPE.  If PROMOTE_COND_EXPR is true,
>> +   promote only the constants in conditions part of the COND_EXPR.
>> +
>> +   We promote the constants when the associated 

Re: [C PATCH] Don't leak C_MAYBE_CONST_EXPRs into fold() (PR c/68412)

2015-11-18 Thread Marek Polacek
On Wed, Nov 18, 2015 at 05:03:48PM +0100, Marek Polacek wrote:
> Since C++ delayed folding, warn_tautological_cmp needs to fold its arguments.
> But sometimes this function gets C_MAYBE_CONST_EXPR from the C FE, and fold()
> duly ICEs.
> 
> I was torn if I should just return from warn_tautological_cmp and not warn
> when it gets C_MAYBE_CONST_EXPR as an argument, or if I should strip
> C_MAYBE_CONST_EXPR before calling warn_tautological_cmp.  I decided for the
> latter since I think warn_tautological_cmp probably should warn on code such
> as
>   int i = 10;
>   bool b = ({ i; }) == ({ i; });
> (ugh).
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?

Actually, no, I think we should do this instead.

Ok if testing passes?

2015-11-18  Marek Polacek  

PR c/68412
* c-common.c (warn_tautological_cmp): Don't fold arguments here.

* call.c (build_new_op_1): Fold arguments to warn_tautological_cmp.

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

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index f50ca48..06d857c 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -1924,7 +1924,7 @@ warn_tautological_cmp (location_t loc, enum tree_code 
code, tree lhs, tree rhs)
 
   /* We do not warn for constants because they are typical of macro
  expansions that test for features, sizeof, and similar.  */
-  if (CONSTANT_CLASS_P (fold (lhs)) || CONSTANT_CLASS_P (fold (rhs)))
+  if (CONSTANT_CLASS_P (lhs) || CONSTANT_CLASS_P (rhs))
 return;
 
   /* Don't warn for e.g.
diff --git gcc/cp/call.c gcc/cp/call.c
index 8cdda62..77c2936 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -5741,7 +5741,7 @@ build_new_op_1 (location_t loc, enum tree_code code, int 
flags, tree arg1,
maybe_warn_bool_compare (loc, code, fold (arg1),
 fold (arg2));
   if (complain & tf_warning && warn_tautological_compare)
-   warn_tautological_cmp (loc, code, arg1, arg2);
+   warn_tautological_cmp (loc, code, fold (arg1), fold (arg2));
   /* Fall through.  */
 case PLUS_EXPR:
 case MINUS_EXPR:
diff --git gcc/testsuite/gcc.dg/pr68412.c gcc/testsuite/gcc.dg/pr68412.c
index e69de29..825eb63 100644
--- gcc/testsuite/gcc.dg/pr68412.c
+++ gcc/testsuite/gcc.dg/pr68412.c
@@ -0,0 +1,41 @@
+/* PR c/68412 */
+/* { dg-do compile } */
+/* { dg-options "-Wall -Wextra" } */
+
+#define M (sizeof (int) * __CHAR_BIT__)
+
+int
+fn1 (int i)
+{
+  return i == (-1 << 8); /* { dg-warning "left shift of negative value" } */
+}
+
+int
+fn2 (int i)
+{
+  return i == (1 << M); /* { dg-warning "left shift count" } */
+}
+
+int
+fn3 (int i)
+{
+  return i == 10 << (M - 1); /* { dg-warning "requires" } */
+}
+
+int
+fn4 (int i)
+{
+  return i == 1 << -1; /* { dg-warning "left shift count" } */
+}
+
+int
+fn5 (int i)
+{
+  return i == 1 >> M; /* { dg-warning "right shift count" } */
+}
+
+int
+fn6 (int i)
+{
+  return i == 1 >> -1; /* { dg-warning "right shift count" } */
+}

Marek


Re: [gomp4] OpenACC async clause regressions

2015-11-18 Thread Tom de Vries

On 22/10/15 20:27, Thomas Schwinge wrote:

diff --cc libgomp/testsuite/libgomp.oacc-c-c++-common/asyncwait-1.c
index d478ce2,22cef6d..f3b490a
--- libgomp/testsuite/libgomp.oacc-c-c++-common/asyncwait-1.c
+++ libgomp/testsuite/libgomp.oacc-c-c++-common/asyncwait-1.c
@@@ -1,4 -1,4 +1,6 @@@
   /* { dg-do run { target openacc_nvidia_accel_selected } } */
++/*.
++   { dg-xfail-run-if "TODO" { *-*-* } } */
   /* { dg-additional-options "-lcuda" } */

   #include 


This failure shows up on trunk. Should it also be xfailed there?

Thanks,
- Tom


Re: POWERPC64_TOC_POINTER_ALIGNMENT

2015-11-18 Thread David Edelsohn
On Tue, Nov 17, 2015 at 9:32 PM, Alan Modra  wrote:
> On Tue, Nov 17, 2015 at 07:53:18PM -0500, Michael Meissner wrote:
>> Here is the temporary patch I'm using to get past rs6000.c.  But I suspect 
>> the
>> TOC alignment should never be 256.
>
> Yes, it should be.  Recent GNU ld aligns .TOC. to a 256 byte boundary.
> I have this patch in my tree.
>
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index abc8eaa..e3ec042 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -8059,12 +8059,17 @@ rs6000_cannot_force_const_mem (machine_mode mode 
> ATTRIBUTE_UNUSED, rtx x)
>  static bool
>  use_toc_relative_ref (rtx sym, machine_mode mode)
>  {
> +  /* Silence complaint that the POWERPC64_TOC_POINTER_ALIGNMENT test
> + is always true.  */
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wtype-limits"
>return ((constant_pool_expr_p (sym)
>&& ASM_OUTPUT_SPECIAL_POOL_ENTRY_P (get_pool_constant (sym),
>get_pool_mode (sym)))
>   || (TARGET_CMODEL == CMODEL_MEDIUM
>   && SYMBOL_REF_LOCAL_P (sym)
>   && GET_MODE_SIZE (mode) <= POWERPC64_TOC_POINTER_ALIGNMENT));
> +#pragma GCC diagnostic pop
>  }
>
>  /* Our implementation of LEGITIMIZE_RELOAD_ADDRESS.  Returns a value to

I have applied Alan's work-around for now until there is a more robust solution.

Thanks, David


teach delay folding in c++ about OACC_LOOPs

2015-11-18 Thread Cesar Philippidis
Jason,

Your recent delay folding patch broke libgomp.oacc-c++/loop-auto-1.c. It
looks like you forgot to handle OACC_LOOP in cp_fold_r. You probably
didn't notice this because Nathan committed his auto acc loop patch just
before you applied your patch. I'm not sure why only that test is
affected though.

Is this patch ok for trunk?

Cesar
2015-11-17  Cesar Philippidis  

	gcc/cp/
	* cp-gimplify.c (cp_fold_r): Add support for OACC_LOOP.

diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index 8fe9e13..99d0cfb 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -933,7 +933,8 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void *data)
 
   code = TREE_CODE (stmt);
   if (code == OMP_FOR || code == OMP_SIMD || code == OMP_DISTRIBUTE
-  || code == OMP_TASKLOOP || code == CILK_FOR || code == CILK_SIMD)
+  || code == OMP_TASKLOOP || code == CILK_FOR || code == CILK_SIMD
+  || code == OACC_LOOP)
 {
   tree x;
   int i, n;


Re: [PATCH][ARM] Do not expand movmisalign pattern if not in 32-bit mode

2015-11-18 Thread Kyrill Tkachov

Ping.
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01392.html

Thanks,
Kyrill

On 11/11/15 16:10, Kyrill Tkachov wrote:

Hi all,

The attached testcase ICEs when compiled with -march=armv6k -mthumb -Os or any 
march
for which -mthumb gives Thumb1:
 error: unrecognizable insn:
 }
 ^
(insn 13 12 14 5 (set (reg:SI 116 [ x ])
(unspec:SI [
(mem:SI (reg/v/f:SI 112 [ s ]) [0 MEM[(unsigned char 
*)s_1(D)]+0 S4 A8])
] UNSPEC_UNALIGNED_LOAD)) besttry.c:9 -1
 (nil))

The problem is that the expands a movmisalign pattern but the resulting 
unaligned loads don't
match any define_insn because they are gated on unaligned_access && 
TARGET_32BIT.
The unaligned_access expander is gated only on unaligned_access.

This small patch fixes the issue by turning off unaligned_access if 
TARGET_32BIT is not true.
We can then remove TARGET_32BIT from the unaligned load/store patterns 
conditions as a cleanup.

Bootstrapped and tested on arm-none-linux-gnueabihf.

Ok for trunk?

Thanks,
Kyrill

2015-11-11  Kyrylo Tkachov  

* config/arm/arm.c (arm_option_override): Require TARGET_32BIT
for unaligned_access.
* config/arm/arm.md (unaligned_loadsi): Remove redundant TARGET_32BIT
from matching condition.
(unaligned_loadhis): Likewise.
(unaligned_loadhiu): Likewise.
(unaligned_storesi): Likewise.
(unaligned_storehi): Likewise.

2015-11-11  Kyrylo Tkachov  

* gcc.target/arm/armv6-unaligned-load-ice.c: New test.




Re: [PATCH PR52272]Be smart when adding iv candidates

2015-11-18 Thread Bernd Schmidt

On 11/10/2015 11:19 AM, Bin.Cheng wrote:

On Tue, Nov 10, 2015 at 6:06 PM, Bernd Schmidt  wrote:


Multi-line expressions should be wrapped in parentheses so that emacs/indent
can format them automatically. Two sets of parens are needed for this.
Operators should then line up appropriately.

Ah, thanks for teaching.  Here is the updated patch, hoping it's correct.
It looks like you're waiting to check it in - Richard's earlier approval 
still holds.



Bernd



Re: [C PATCH] Don't leak C_MAYBE_CONST_EXPRs into fold() (PR c/68412)

2015-11-18 Thread Bernd Schmidt

On 11/18/2015 05:16 PM, Marek Polacek wrote:

Actually, no, I think we should do this instead.

+++ gcc/c-family/c-common.c
@@ -1924,7 +1924,7 @@ warn_tautological_cmp (location_t loc, enum tree_code 
code, tree lhs, tree rhs)

/* We do not warn for constants because they are typical of macro
   expansions that test for features, sizeof, and similar.  */
-  if (CONSTANT_CLASS_P (fold (lhs)) || CONSTANT_CLASS_P (fold (rhs)))
+  if (CONSTANT_CLASS_P (lhs) || CONSTANT_CLASS_P (rhs))
  return;

/* Don't warn for e.g.
diff --git gcc/cp/call.c gcc/cp/call.c
index 8cdda62..77c2936 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -5741,7 +5741,7 @@ build_new_op_1 (location_t loc, enum tree_code code, int 
flags, tree arg1,
maybe_warn_bool_compare (loc, code, fold (arg1),
 fold (arg2));
if (complain & tf_warning && warn_tautological_compare)
-   warn_tautological_cmp (loc, code, arg1, arg2);
+   warn_tautological_cmp (loc, code, fold (arg1), fold (arg2));
/* Fall through.  */
  case PLUS_EXPR:
  case MINUS_EXPR:


That seems to change the behaviour of the code though. Most of the code 
in warn_tautological_cmp only looks at the unfolded form. Are you sure 
this is safe, for example wrt. the from_macro_expansion_at tests or the 
CONVERT_EXPR_P ones?



Bernd


[PATCH 2/4 v2][AArch64] Add support for FCCMP

2015-11-18 Thread Wilco Dijkstra
(v2 version removes 4 enums)

This patch adds support for FCCMP. This is trivial with the new CCMP
representation - remove the restriction of FP in ccmp.c and add FCCMP
patterns. Add a test to ensure FCCMP/FCCMPE are emitted as expected.

OK for commit?

ChangeLog:
2015-11-18  Wilco Dijkstra  

* gcc/ccmp.c (ccmp_candidate_p): Remove integer-only restriction.
* gcc/config/aarch64/aarch64.md (fccmp): New pattern.
(fccmpe): Likewise.
(fcmp): Rename to fcmp and globalize pattern.
(fcmpe): Likewise.
* gcc/config/aarch64/aarch64.c (aarch64_gen_ccmp_first): Add FP
support.
(aarch64_gen_ccmp_next): Add FP support.

gcc/testsuite/
* gcc.target/aarch64/ccmp_1.c: New testcase.


---
 gcc/ccmp.c|  6 ---
 gcc/config/aarch64/aarch64.c  | 24 +
 gcc/config/aarch64/aarch64.md | 34 -
 gcc/testsuite/gcc.target/aarch64/ccmp_1.c | 84
+++
 4 files changed, 140 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/ccmp_1.c

diff --git a/gcc/ccmp.c b/gcc/ccmp.c
index 58ac126..3698a7d 100644
--- a/gcc/ccmp.c
+++ b/gcc/ccmp.c
@@ -112,12 +112,6 @@ ccmp_candidate_p (gimple *g)
   || gimple_bb (gs0) != gimple_bb (g))
 return false;
 
-  if (!(INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_rhs1 (gs0)))
-   || POINTER_TYPE_P (TREE_TYPE (gimple_assign_rhs1 (gs0
-  || !(INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_rhs1 (gs1)))
-  || POINTER_TYPE_P (TREE_TYPE (gimple_assign_rhs1 (gs1)
-return false;
-
   tcode0 = gimple_assign_rhs_code (gs0);
   tcode1 = gimple_assign_rhs_code (gs1);
   if (TREE_CODE_CLASS (tcode0) == tcc_comparison
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index c8bee3b..db4d190 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -12398,6 +12398,18 @@ aarch64_gen_ccmp_first (rtx *prep_seq, rtx
*gen_seq,
   icode = CODE_FOR_cmpdi;
   break;
 
+case SFmode:
+  cmp_mode = SFmode;
+  cc_mode = aarch64_select_cc_mode ((rtx_code) code, op0, op1);
+  icode = cc_mode == CCFPEmode ? CODE_FOR_fcmpesf : CODE_FOR_fcmpsf;
+  break;
+
+case DFmode:
+  cmp_mode = DFmode;
+  cc_mode = aarch64_select_cc_mode ((rtx_code) code, op0, op1);
+  icode = cc_mode == CCFPEmode ? CODE_FOR_fcmpedf : CODE_FOR_fcmpdf;
+  break;
+
 default:
   end_sequence ();
   return NULL_RTX;
@@ -12461,6 +12473,18 @@ aarch64_gen_ccmp_next (rtx *prep_seq, rtx *gen_seq,
rtx prev, int cmp_code,
   icode = CODE_FOR_ccmpdi;
   break;
 
+case SFmode:
+  cmp_mode = SFmode;
+  cc_mode = aarch64_select_cc_mode ((rtx_code) cmp_code, op0, op1);
+  icode = cc_mode == CCFPEmode ? CODE_FOR_fccmpesf : CODE_FOR_fccmpsf;
+  break;
+
+case DFmode:
+  cmp_mode = DFmode;
+  cc_mode = aarch64_select_cc_mode ((rtx_code) cmp_code, op0, op1);
+  icode = cc_mode == CCFPEmode ? CODE_FOR_fccmpedf : CODE_FOR_fccmpdf;
+  break;
+
 default:
   end_sequence ();
   return NULL_RTX;
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index fab65c6..7d728b5 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -279,6 +279,36 @@
   [(set_attr "type" "alus_sreg,alus_imm,alus_imm")]
 )
 
+(define_insn "fccmp"
+  [(set (match_operand:CCFP 1 "cc_register" "")
+   (if_then_else:CCFP
+ (match_operator 4 "aarch64_comparison_operator"
+  [(match_operand 0 "cc_register" "")
+   (const_int 0)])
+ (compare:CCFP
+   (match_operand:GPF 2 "register_operand" "w")
+   (match_operand:GPF 3 "register_operand" "w"))
+ (match_operand 5 "immediate_operand")))]
+  "TARGET_FLOAT"
+  "fccmp\\t%2, %3, %k5, %m4"
+  [(set_attr "type" "fcmp")]
+)
+
+(define_insn "fccmpe"
+  [(set (match_operand:CCFPE 1 "cc_register" "")
+(if_then_else:CCFPE
+ (match_operator 4 "aarch64_comparison_operator"
+  [(match_operand 0 "cc_register" "")
+ (const_int 0)])
+  (compare:CCFPE
+   (match_operand:GPF 2 "register_operand" "w")
+   (match_operand:GPF 3 "register_operand" "w"))
+ (match_operand 5 "immediate_operand")))]
+  "TARGET_FLOAT"
+  "fccmpe\\t%2, %3, %k5, %m4"
+  [(set_attr "type" "fcmp")]
+)
+
 ;; Expansion of signed mod by a power of 2 using CSNEG.
 ;; For x0 % n where n is a power of 2 produce:
 ;; negs   x1, x0
@@ -2794,7 +2824,7 @@
   [(set_attr "type" "alus_sreg,alus_imm,alus_imm")]
 )
 
-(define_insn "*cmp"
+(define_insn "fcmp"
   [(set (reg:CCFP CC_REGNUM)
 (compare:CCFP (match_operand:GPF 0 "register_operand" "w,w")
  (match_operand:GPF 1 "aarch64_fp_compare_operand"
"Y,w")))]
@@ -2805,7 +2835,7 @@
   [(set_attr "type" "fcmp")]
 )
 
-(define_insn "*cmpe"
+(define_insn "fcmpe"
   [(set (reg:CCFPE CC_REGNUM)
   

[PATCH 4/4 v2][AArch64] Cost CCMP instruction sequences to choose better expand order

2015-11-18 Thread Wilco Dijkstra
(v2 cleans up enum use)

This patch adds CCMP selection based on rtx costs. This is based on Jiong's
already approved patch
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01434.html with some minor
refactoring and enum cleanup plus the tests updated.

OK for commit?

ChangeLog:
2015-11-13  Jiong Wang  
2015-11-18  Wilco Dijkstra  

gcc/
* ccmp.c (expand_ccmp_expr_1): Cost the instruction sequences
generated from different expand order.  Cleanup enum use.
  
gcc/testsuite/
* gcc.target/aarch64/ccmp_1.c: Update test.


---
 gcc/ccmp.c| 65
---
 gcc/testsuite/gcc.target/aarch64/ccmp_1.c | 15 ++-
 2 files changed, 64 insertions(+), 16 deletions(-)

diff --git a/gcc/ccmp.c b/gcc/ccmp.c
index 3698a7d..0c677fd 100644
--- a/gcc/ccmp.c
+++ b/gcc/ccmp.c
@@ -51,6 +51,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-outof-ssa.h"
 #include "cfgexpand.h"
 #include "ccmp.h"
+#include "predict.h"
 
 /* The following functions expand conditional compare (CCMP) instructions.
Here is a short description about the over all algorithm:
@@ -88,7 +89,7 @@ ccmp_candidate_p (gimple *g)
   tree rhs = gimple_assign_rhs_to_tree (g);
   tree lhs, op0, op1;
   gimple *gs0, *gs1;
-  enum tree_code tcode, tcode0, tcode1;
+  tree_code tcode, tcode0, tcode1;
   tcode = TREE_CODE (rhs);
 
   if (tcode != BIT_AND_EXPR && tcode != BIT_IOR_EXPR)
@@ -135,10 +136,10 @@ ccmp_candidate_p (gimple *g)
PREP_SEQ returns all insns to prepare opearands for compare.
GEN_SEQ returns all compare insns.  */
 static rtx
-expand_ccmp_next (gimple *g, enum tree_code code, rtx prev,
+expand_ccmp_next (gimple *g, tree_code code, rtx prev,
  rtx *prep_seq, rtx *gen_seq)
 {
-  enum rtx_code rcode;
+  rtx_code rcode;
   int unsignedp = TYPE_UNSIGNED (TREE_TYPE (gimple_assign_rhs1 (g)));
 
   gcc_assert (code == BIT_AND_EXPR || code == BIT_IOR_EXPR);
@@ -165,13 +166,15 @@ expand_ccmp_next (gimple *g, enum tree_code code, rtx
prev,
 static rtx
 expand_ccmp_expr_1 (gimple *g, rtx *prep_seq, rtx *gen_seq)
 {
+  rtx prep_seq_1, gen_seq_1;
+  rtx prep_seq_2, gen_seq_2;
   tree exp = gimple_assign_rhs_to_tree (g);
-  enum tree_code code = TREE_CODE (exp);
+  tree_code code = TREE_CODE (exp);
   gimple *gs0 = get_gimple_for_ssa_name (TREE_OPERAND (exp, 0));
   gimple *gs1 = get_gimple_for_ssa_name (TREE_OPERAND (exp, 1));
   rtx tmp;
-  enum tree_code code0 = gimple_assign_rhs_code (gs0);
-  enum tree_code code1 = gimple_assign_rhs_code (gs1);
+  tree_code code0 = gimple_assign_rhs_code (gs0);
+  tree_code code1 = gimple_assign_rhs_code (gs1);
 
   gcc_assert (code == BIT_AND_EXPR || code == BIT_IOR_EXPR);
   gcc_assert (gs0 && gs1 && is_gimple_assign (gs0) && is_gimple_assign
(gs1));
@@ -180,19 +183,53 @@ expand_ccmp_expr_1 (gimple *g, rtx *prep_seq, rtx
*gen_seq)
 {
   if (TREE_CODE_CLASS (code1) == tcc_comparison)
{
- int unsignedp0;
- enum rtx_code rcode0;
+ int unsignedp0, unsignedp1;
+ rtx_code rcode0, rcode1;
+ int speed_p = optimize_insn_for_speed_p ();
+ rtx tmp2, ret, ret2;
+ unsigned cost1 = MAX_COST;
+ unsigned cost2 = MAX_COST;
 
  unsignedp0 = TYPE_UNSIGNED (TREE_TYPE (gimple_assign_rhs1 (gs0)));
+ unsignedp1 = TYPE_UNSIGNED (TREE_TYPE (gimple_assign_rhs1 (gs1)));
  rcode0 = get_rtx_code (code0, unsignedp0);
+ rcode1 = get_rtx_code (code1, unsignedp1);
 
- tmp = targetm.gen_ccmp_first (prep_seq, gen_seq, rcode0,
+ tmp = targetm.gen_ccmp_first (_seq_1, _seq_1, rcode0,
gimple_assign_rhs1 (gs0),
gimple_assign_rhs2 (gs0));
- if (!tmp)
+
+ tmp2 = targetm.gen_ccmp_first (_seq_2, _seq_2, rcode1,
+gimple_assign_rhs1 (gs1),
+gimple_assign_rhs2 (gs1));
+
+ if (!tmp && !tmp2)
return NULL_RTX;
 
- return expand_ccmp_next (gs1, code, tmp, prep_seq, gen_seq);
+ if (tmp != NULL)
+   {
+ ret = expand_ccmp_next (gs1, code, tmp, _seq_1,
_seq_1);
+ cost1 = seq_cost (safe_as_a  (prep_seq_1),
speed_p);
+ cost1 += seq_cost (safe_as_a  (gen_seq_1),
speed_p);
+   }
+ if (tmp2 != NULL)
+   {
+ ret2 = expand_ccmp_next (gs0, code, tmp2, _seq_2,
+  _seq_2);
+ cost2 = seq_cost (safe_as_a  (prep_seq_2),
speed_p);
+ cost2 += seq_cost (safe_as_a  (gen_seq_2),
speed_p);
+   }
+
+ if (cost2 < cost1)
+   {
+ *prep_seq = prep_seq_2;
+ *gen_seq = gen_seq_2;
+ return ret2;
+   }
+
+ *prep_seq = prep_seq_1;
+ *gen_seq = gen_seq_1;
+ return ret;
}
   

Re: [1/2] OpenACC routine support

2015-11-18 Thread Cesar Philippidis
On 11/10/2015 12:16 AM, Jakub Jelinek wrote:
> On Mon, Nov 09, 2015 at 09:28:47PM -0800, Cesar Philippidis wrote:
>> Here's the patch that Nathan was referring to. I ended up introducing a
>> boolean variable named first in the various functions which call
>> finalize_oacc_routines. The problem the original approach was having was
>> that the routine clauses is only applied to the first function
>> declarator in a declaration list. By using 'first', which is set to true
>> if the current declarator is the first in a sequence of declarators, I
>> was able to defer setting parser->oacc_routine to NULL.
> 
> The #pragma omp declare simd has identical restrictions, but doesn't need
> to add any of the first parameters to the C++ parser.
> So, what are you doing differently that you need it?  Handling both
> differently is a consistency issue, and unnecessary additional complexity to
> the parser.

I reworked how acc routines are handed in this patch to be more similar
to #pragma omp declare simd. Things get kind of messy though. For
starters, I had to add a new tree clauses member to
cp_omp_declare_simd_data. This serves two purposes:

  * It allows the c++ FE to record the location of the first
#pragma acc routine, which is nice because it allows test cases to
be shared with the c FE.

  * Unlike omp declare simd, only one acc routine may be associated with
a function decl. This meant that I had to defer attaching the acc
geometry and 'omp target' attributes to cp_finalize_oacc_routine
instead of in cp_parser_late_parsing_oacc_routine like in omp. So
what happens is, cp_parser_late_parsing_oacc_routine ends up
creating a function geometry clause.

I don't really like this approach. I did try to postpone parsing the
clauses till cp_finalize_oacc_routine, but that got messy. Plus, while
I'd be able to remove the clauses field from cp_omp_declare_simd_data,
we'd still need a location_t field for cp_ensure_no_oacc_routine.

Is this OK for trunk?

Cesar
2015-11-17  Cesar Philippidis  

	gcc/cp/
	* parser.h (struct cp_omp_declare_simd_data): Add clauses member.
	(struct cp_parser): Change type the of oacc_routine to
	cp_omp_declare_simd_data.
	* parser.c (cp_ensure_no_oacc_routine): Rework to use
	cp_omp_declare_simd_data.
	(cp_parser_simple_declaration): Remove boolean first.  Update call to
	cp_parser_init_declarator. Don't NULL out oacc_routine.
	(cp_parser_init_declarator): Remove boolean first parameter.  Update
	calls to cp_finalize_oacc_routine.
	(cp_parser_late_return_type_opt): Handle acc routines. 
	(cp_parser_member_declaration): Remove first variable.  Handle
	acc routines like omp declare simd.
	(cp_parser_function_definition_from_specifiers_and_declarator): Update
	call to cp_finalize_oacc_routine.
	(cp_parser_single_declaration): Update call to
	cp_parser_init_declarator.
	(cp_parser_save_member_function_body): Remove first_decl parameter.
	Update call to cp_finalize_oacc_routine.
	(cp_parser_finish_oacc_routine): Delete.
	(cp_parser_oacc_routine): Rework to use cp_omp_declare_simd_data.
	(cp_parser_late_parsing_oacc_routine): New function.
	(cp_finalize_oacc_routine): Remove first argument.  Add more error
	handling and set the acc routine and 'omp declare target' attributes.
	(cp_parser_pragma): Remove unnecessary call to
	cp_ensure_no_oacc_routine.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 0e1116b..8de3bce 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -241,7 +241,7 @@ static bool cp_parser_omp_declare_reduction_exprs
 static tree cp_parser_cilk_simd_vectorlength 
   (cp_parser *, tree, bool);
 static void cp_finalize_oacc_routine
-  (cp_parser *, tree, bool, bool);
+  (cp_parser *, tree, bool);
 
 /* Manifest constants.  */
 #define CP_LEXER_BUFFER_SIZE ((256 * 1024) / sizeof (cp_token))
@@ -1318,13 +1318,21 @@ cp_finalize_omp_declare_simd (cp_parser *parser, tree fndecl)
 }
 }
 
-/* Diagnose if #pragma omp routine isn't followed immediately
-   by function declaration or definition.   */
+/* Diagnose if #pragma acc routine isn't followed immediately by function
+   declaration or definition.  */
 
 static inline void
 cp_ensure_no_oacc_routine (cp_parser *parser)
 {
-  cp_finalize_oacc_routine (parser, NULL_TREE, false, true);
+  if (parser->oacc_routine && !parser->oacc_routine->error_seen)
+{
+  tree clauses = parser->oacc_routine->clauses;
+  location_t loc = OMP_CLAUSE_LOCATION (TREE_PURPOSE(clauses));
+
+  error_at (loc, "%<#pragma oacc routine%> not followed by function "
+		"declaration or definition");
+  parser->oacc_routine = NULL;
+}
 }
 
 /* Decl-specifiers.  */
@@ -2130,7 +2138,7 @@ static tree cp_parser_decltype
 
 static tree cp_parser_init_declarator
   (cp_parser *, cp_decl_specifier_seq *, vec *,
-   bool, bool, int, bool *, tree *, bool, location_t *);
+   bool, bool, int, bool *, tree *, location_t *);
 static cp_declarator *cp_parser_declarator
  

[Ada] Fix ICE on on indirect renaming of address at -O

2015-11-18 Thread Eric Botcazou
Addresses cannot be directly subject to a renaming, but they can nevertheless
be renamed through a constant and thus need to be dealt with as other rvalues.

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


2015-11-18  Eric Botcazou  

* gcc-interface/decl.c (gnat_to_gnu_entity) : Use case #1
for the renaming of an address.


2015-11-18  Eric Botcazou  

* gnat.dg/renaming7.adb: New test.
* gnat.dg/renaming7_pkg.ads: New helper.

-- 
Eric BotcazouIndex: gcc-interface/decl.c
===
--- gcc-interface/decl.c	(revision 230557)
+++ gcc-interface/decl.c	(working copy)
@@ -963,8 +963,8 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
 	   function call is a constant object.  Therefore, it can be the
 	   inner object of a constant renaming and the renaming must be
 	   fully instantiated, i.e. it cannot be a reference to (part of)
-	   an existing object.  And treat null expressions, constructors
-	   and literals the same way.  */
+	   an existing object.  And treat other rvalues (addresses, null
+	   expressions, constructors and literals) the same way.  */
 	tree inner = gnu_expr;
 	while (handled_component_p (inner) || CONVERT_EXPR_P (inner))
 	  inner = TREE_OPERAND (inner, 0);
@@ -974,6 +974,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
 	  inner = TREE_OPERAND (inner, 1);
 	if ((TREE_CODE (inner) == CALL_EXPR
 		 && !call_is_atomic_load (inner))
+		|| TREE_CODE (inner) == ADDR_EXPR
 		|| TREE_CODE (inner) == NULL_EXPR
 		|| TREE_CODE (inner) == CONSTRUCTOR
 		|| CONSTANT_CLASS_P (inner))
-- { dg-do compile }
-- { dg-options "-O" }

with Renaming7_Pkg; use Renaming7_Pkg;
with System;

procedure Renaming7 is
  C : constant System.Address := A'Address;
  D : System.Address renames C;
begin
  null;
end;
package Renaming7_Pkg is

  A : Integer;

end Renaming7_Pkg;


[nvptx] SESE region optimization

2015-11-18 Thread Nathan Sidwell

I've applied this to trunk, it adds the SESE region neutering from the gomp4 
branch.

The general idea is that when neutering partitioned execution, one can skip from 
 the entry of an SESE region straight to its exit, rather than do each block in 
the region individually.


Finding the regions involves:

1) Finding cycle-equivalent blocks.  These are blocks where a code path that 
reaches one of them is guaranteed to reach all of them.  This uses the algorithm 
described by 'Finding Regions Fast:  Single Entry Single Exit and control 
Regions in Linear Time' Johnson, Pearson & Pingali. (their algorithm doesn't 
actually find SESE regions, just the cycle-equivalent nodes)


2) Once those are found, we apply a DFS flood fill coloring algorithm, to 
determine the minimal set of SESE regions that cover the set of blocks we're 
interested in.  The order of discovery allows us to determine which is the entry 
node and which is the exit node.  Knowing the size of each equivalence set 
allows us to determine when we've found the exit node of an SESE region, or 
whether we're merely at a 'neck' within a larger region.


One tricky bit is that we're not dealing with the entire function graph, but a 
subset of it described by the partitioned loop structure.  I deal with this by 
treating all edges that traverse the partitioned region boundary as connected 
back to the function entry block (i.e. form a loop), when detecting SESE 
regions.  For the coloring algorithm we traverse them, but don't color outside 
the partitioned region (such traversal can never be within an SESE region).


nathan
2015-11-18  Nathan Sidwell  

	gcc/
	* config/nvptx/nvptx.c (bb_pair_t, bb_pair_vec_t): New types.
	(pseudo_node_t, struct bracket, bracket_vec_t): New types.
	(struct bb_sese): New struct.
	(bb_sese::~bb_sese, bb_sese::append, bb_sese::remove): New.
	(BB_GET_SESE, BB_SET_SESE): Define.
	(nvptx_sese_number, nvptx_sese_pseudo, nvptx_sese_color): New.
	(nvptx_find_sese): New.
	(nvptx_neuter_pars): Find SESE regions when optimizing.

	gcc/testsuite/
	* gcc.dg/goacc/nvptx-sese-1.c: New.

Index: gcc/config/nvptx/nvptx.c
===
--- gcc/config/nvptx/nvptx.c	(revision 230549)
+++ gcc/config/nvptx/nvptx.c	(working copy)
@@ -2605,6 +2605,631 @@ nvptx_discover_pars (bb_insn_map_t *map)
   return par;
 }
 
+/* Analyse a group of BBs within a partitioned region and create N
+   Single-Entry-Single-Exit regions.  Some of those regions will be
+   trivial ones consisting of a single BB.  The blocks of a
+   partitioned region might form a set of disjoint graphs -- because
+   the region encloses a differently partitoned sub region.
+
+   We use the linear time algorithm described in 'Finding Regions Fast:
+   Single Entry Single Exit and control Regions in Linear Time'
+   Johnson, Pearson & Pingali.  That algorithm deals with complete
+   CFGs, where a back edge is inserted from END to START, and thus the
+   problem becomes one of finding equivalent loops.
+
+   In this case we have a partial CFG.  We complete it by redirecting
+   any incoming edge to the graph to be from an arbitrary external BB,
+   and similarly redirecting any outgoing edge to be to  that BB.
+   Thus we end up with a closed graph.
+
+   The algorithm works by building a spanning tree of an undirected
+   graph and keeping track of back edges from nodes further from the
+   root in the tree to nodes nearer to the root in the tree.  In the
+   description below, the root is up and the tree grows downwards.
+
+   We avoid having to deal with degenerate back-edges to the same
+   block, by splitting each BB into 3 -- one for input edges, one for
+   the node itself and one for the output edges.  Such back edges are
+   referred to as 'Brackets'.  Cycle equivalent nodes will have the
+   same set of brackets.
+   
+   Determining bracket equivalency is done by maintaining a list of
+   brackets in such a manner that the list length and final bracket
+   uniquely identify the set.
+
+   We use coloring to mark all BBs with cycle equivalency with the
+   same color.  This is the output of the 'Finding Regions Fast'
+   algorithm.  Notice it doesn't actually find the set of nodes within
+   a particular region, just unorderd sets of nodes that are the
+   entries and exits of SESE regions.
+   
+   After determining cycle equivalency, we need to find the minimal
+   set of SESE regions.  Do this with a DFS coloring walk of the
+   complete graph.  We're either 'looking' or 'coloring'.  When
+   looking, and we're in the subgraph, we start coloring the color of
+   the current node, and remember that node as the start of the
+   current color's SESE region.  Every time we go to a new node, we
+   decrement the count of nodes with thet color.  If it reaches zero,
+   we remember that node as the end of the current color's SESE region
+   and return to 'looking'.  Otherwise we color the node 

[Ada] Fix stack usage increase for renaming of indexed component

2015-11-18 Thread Eric Botcazou
This fixes an oversight in the new fold_constant_decl_in_expr function, which 
causes the code generated by the compiler for the renaming of an indexed 
component whose prefix is a constant object and whose index is not to use 
significantly more stack than needed.

Tested on x86_64-suse-linux, applied on the mainline and 5.x branch.


2015-11-18  Eric Botcazou  

* gcc-interface/trans.c (fold_constant_decl_in_expr) : If
the index is not itself constant then bail out.

-- 
Eric BotcazouIndex: gcc-interface/trans.c
===
--- gcc-interface/trans.c	(revision 230542)
+++ gcc-interface/trans.c	(working copy)
@@ -975,6 +975,9 @@ fold_constant_decl_in_expr (tree exp)
 
 case ARRAY_REF:
 case ARRAY_RANGE_REF:
+  /* If the index is not itself constant, then nothing can be folded.  */
+  if (!TREE_CONSTANT (TREE_OPERAND (exp, 1)))
+	return exp;
   op0 = fold_constant_decl_in_expr (TREE_OPERAND (exp, 0));
   if (op0 == TREE_OPERAND (exp, 0))
 	return exp;


Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement

2015-11-18 Thread Jerry DeLisle
On 11/17/2015 12:34 PM, Steve Kargl wrote:
> Here's what looks like a fairly simple patch, but it leads
> to a question.  Why does gfortran not try to reduce the 
> components in a structure constructor in general?  I've
> hidden the gfc_reduce_init_expr() behind a check for a
> DATA statement, but I suspect gfc_reduce_init_expr() 
> may be useful for PARAMETER statements as well (need to
> check this!).
> 
> Anyway, the patch has been built and tested on x86_64-*-freebsd.
> A slightly different patch was built and tested on i386-*-freebsd.
> 
> OK to commit?
> 
OK, Can't answer your question above at the moment.

Jerry


Re: Re: OpenACC declare directive updates

2015-11-18 Thread Cesar Philippidis
On 11/08/2015 08:53 PM, James Norris wrote:

> The attached patch and ChangeLog reflect the updates from your
> review: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00714.html
> and Cesar's review:
> https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00885.html.
> 
> With the changes made in this patch I think I'm handling the
> situation that you pointed out here correctly:
> 
> "Also, wonder about BLOCK stmt in Fortran, that can give you variables that
> don't live through the whole function, but only a portion of it even in
> Fortran."

What block stmt? The most recent version of Fortran OpenACC 2.0a
supports is 2003. The block construct is a 2008 feature. I don't think
that's applicable to this version. Jim, maybe you should add an error
message for variables defined in blocks.

Thinking about this some more, I wonder if we should emit an error if
any acc constructs are used inside blocks? That's probably overly
pessimistic though.

Cesar


Re: Remove noce_mem_write_may_trap_or_fault_p in ifcvt

2015-11-18 Thread Bernd Schmidt
Ok, so this is a thorny problem. I thought I had a solution, and I'll 
start by describing it, but in the end I think it doesn't actually work.


On 11/06/2015 10:09 PM, Jeff Law wrote:

On 11/06/2015 12:30 PM, Bernd Schmidt wrote:

Well, I think if MEM_READONLY_P is insufficient (and I guess people
could cast away const - bother), then the current
noce_mem_write_may_trap_or_fault_p should be simplified to "return
true;" and eliminated.  We could try to special case stack accesses
within a known limit later on.

Maybe it doesn't even matter given that we call noce_can_store_speculate
immediately after this test.

may_trap_or_fault_p already has this kind of knowledge.  It just doesn't
know if the memory is a read or a write.  Hence my suggestion we should
fix may_trap_or_fault_p.


For the current issue I've come to the conclusion that this kind of 
analysis is irrelevant here (and that is not subject to the problem I'll 
describe later), because of the use of noce_can_store_speculate. See below.



Ripping out noce_mem_write_may_trap_or_fault_p without fixing
may_trap_or_fault_p introduces a latent code code generation issue.


I don't think so, actually. One safe option would be to rip it out and 
just stop transforming this case, but let's start by looking at the code 
just a bit further down, calling noce_can_store_speculate. This was 
added later than the code we're discussing, and it tries to verify that 
the same memory location will unconditionally be written to at a point 
later than the one we're trying to convert (but why aren't we testing 
for prior writes?). That should make any may_trap test unnecessary, and 
we can just simply delete the call to 
noce_mem_write_may_trap_or_fault_p. (We could leave such a test in as a 
compile-time focused early-out, but it may actually be too conservative. 
We may have an address which we can't prove safe in isolation, but if we 
know that we also have an unconditional store, it must be safe.)


So... I was about to propose the attached patch, which also fixes some 
oversights in the can_store_speculate path: we shouldn't allow autoinc 
addresses here. The added test in noce_can_store_speculate_p is not 
quite necessary given that the same one is also added to 
memory_must_be_modified_in_insn_p, but it avoids the need for an insn 
walk in cases where it isn't necessary. This bootstrapped and tested ok 
on x86_64-linux.


But then, I looked at noce_can_store_speculate again, and it seems 
broken. We walk over the post-dominators of the block, see if we find a 
store, and fail if something modifies the address:


  for (dominator = get_immediate_dominator (CDI_POST_DOMINATORS, top_bb);
   dominator != NULL;
   dominator = get_immediate_dominator (CDI_POST_DOMINATORS, 
dominator))

{
  rtx_insn *insn;

  FOR_BB_INSNS (dominator, insn)
{
[...]
  if (modified_in_p (XEXP (mem, 0), insn))
return false;
}

But what if the address is modified, but not in a post-dominator block? 
Let's say


 if (cond)
   *p = x; // this is the store we want to convert
 if (other_cond)
   p = some_pointer;
 else
   p = some_other_pointer;
 *p = y; // we'll see this store which postdominates the original
 // one, but not the modifications of p

So I think that algorithm doesn't work. My suggestion at this point 
would be to give up on converting stores entirely (deleting 
noce_can_store_speculate_p and noce_mem_write_may_trap_or_fault_p) until 
someone produces a reasonable scratchpad patch.



Bernd
	* alias.c (memory_must_be_modified_in_insn_p): Return false for
	addresses with side effects.
	* ifcvt.c (noce_mem_write_may_trap_or_fault_p): Delete function.
	(noce_can_store_speculate_p): Return false for addresses with side
	effects.
	(noce_process_if_block): Rely only on noce_can_store_speculate_p.

Index: gcc/alias.c
===
--- gcc/alias.c	(revision 230541)
+++ gcc/alias.c	(working copy)
@@ -2974,6 +2974,10 @@ memory_must_be_modified_in_insn_p (const
 {
   if (!INSN_P (insn))
 return false;
+  /* Our rtx_equal_p tests will not do the right thing in this case.  */
+  if (side_effects_p (XEXP (mem, 0)))
+return false;
+
   insn = PATTERN (insn);
   if (GET_CODE (insn) == SET)
 return set_dest_equal_p (insn, mem);
@@ -2984,7 +2988,7 @@ memory_must_be_modified_in_insn_p (const
 	{
 	  rtx sub = XVECEXP (insn, 0, i);
 	  if (GET_CODE (sub) == SET
-	  &&  set_dest_equal_p (sub, mem))
+	  && set_dest_equal_p (sub, mem))
 	return true;
 	}
 }
Index: gcc/ifcvt.c
===
--- gcc/ifcvt.c	(revision 230541)
+++ gcc/ifcvt.c	(working copy)
@@ -2919,59 +2919,6 @@ noce_operand_ok (const_rtx op)
   return ! may_trap_p (op);
 }
 
-/* Return true if a write into MEM may trap or fault.  */
-
-static bool
-noce_mem_write_may_trap_or_fault_p (const_rtx mem)
-{
-  rtx addr;
-
-  if 

Re: [patch, avr] Add new Atmel AVR devices

2015-11-18 Thread Denis Chertykov
2015-11-18 9:36 GMT+03:00 Sivanupandi, Pitchumani
:
> Attached patch adds new Atmel devices to avr-gcc.
> If Ok, could someone commit please? I do not have commit access.
>
> Regards,
> Pitchumani
>
> gcc/ChangeLog
>
> 2015-11-18  Pitchumani Sivanupandi  
>
> * config/avr/avr-mcus.def: Add new avr4 devices atmega48pb and
> atmega88pb. Add new avr5 devices ata5791, ata8210, ata8510, 
> atmega168pb
> and atmega328pb.
> * doc/avr-mmcu.texi: Regenerate.
>

Committed.

Denis.


Re: [PATCH] Avoid useless work in loop vectorization

2015-11-18 Thread Alan Lawrence

On 13/11/15 08:41, Richard Biener wrote:


Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2015-11-13  Richard Biener  

* tree-vect-loop.c (vect_analyze_loop_2): Add fatal parameter.
Signal fatal failure if early checks fail.
(vect_analyze_loop): If vect_analyze_loop_2 fails fatally
do not bother testing further vector sizes.


It seems that on AArch64 this causes:

FAIL: gcc.dg/vect/vect-outer-1-big-array.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "grouped access in outer loop" 2
FAIL: gcc.dg/vect/vect-outer-1-big-array.c scan-tree-dump-times vect "grouped 
access in outer loop" 2
FAIL: gcc.dg/vect/vect-outer-1.c -flto -ffat-lto-objects  scan-tree-dump-times 
vect "grouped access in outer loop" 2
FAIL: gcc.dg/vect/vect-outer-1.c scan-tree-dump-times vect "grouped access in 
outer loop" 2
FAIL: gcc.dg/vect/vect-outer-1a-big-array.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "grouped access in outer loop" 2
FAIL: gcc.dg/vect/vect-outer-1a-big-array.c scan-tree-dump-times vect "grouped 
access in outer loop" 2
FAIL: gcc.dg/vect/vect-outer-1a.c -flto -ffat-lto-objects  scan-tree-dump-times 
vect "grouped access in outer loop" 2
FAIL: gcc.dg/vect/vect-outer-1a.c scan-tree-dump-times vect "grouped access in 
outer loop" 2
FAIL: gcc.dg/vect/vect-outer-1b-big-array.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "grouped access in outer loop" 2
FAIL: gcc.dg/vect/vect-outer-1b-big-array.c scan-tree-dump-times vect "grouped 
access in outer loop" 2
FAIL: gcc.dg/vect/vect-outer-1b.c -flto -ffat-lto-objects  scan-tree-dump-times 
vect "grouped access in outer loop" 2
FAIL: gcc.dg/vect/vect-outer-1b.c scan-tree-dump-times vect "grouped access in 
outer loop" 2
FAIL: gcc.dg/vect/vect-outer-2b.c -flto -ffat-lto-objects  scan-tree-dump-times 
vect "grouped access in outer loop" 2
FAIL: gcc.dg/vect/vect-outer-2b.c scan-tree-dump-times vect "grouped access in 
outer loop" 2
FAIL: gcc.dg/vect/vect-outer-3b.c -flto -ffat-lto-objects  scan-tree-dump-times 
vect "grouped access in outer loop" 4
FAIL: gcc.dg/vect/vect-outer-3b.c scan-tree-dump-times vect "grouped access in 
outer loop" 4


Still there on r230556, I haven't dug any further yet.

Thanks, Alan



[PATCH] [4.9] Re: [PATCH][5] Backport ISL 0.15 support

2015-11-18 Thread Matthias Klose

On 12.10.2015 12:58, Richard Biener wrote:


This backports the patch to allow bootstrapping with ISL 0.15 to the
GCC 5 branch (the GCC 4.9 branch will require backporting of some
dependencies).


I don't think so. 4.8 and 4.9 don't use as much ISL code as 5 does.  I had a 
look at the backport and came up with something which is just mechanical changes 
for the cpp conditional.


The version check in the toplevel configure needs to be extended.  I'm currently 
not checking non matching isl and cloog versions.


Now build for 4.9 using ISL 0.15 and 0.14. Ok to commit to the branch?

Matthias


2015-11-18  Matthias Klose  

	* configure.ac: Permit also ISL 0.15 with CLooG.
	* configure: Regenerate.

gcc/
2015-11-18  Matthias Klose  

	Backport from the gcc-5-branch

	Backport from mainline
	2015-07-21  Mike Frysinger  
		Bernhard Reutner-Fischer  

	* configure.ac: Add check for new options in isl-0.15.
	* config.in, configure: Rebuilt.
	* graphite-blocking.c: Include 
	* graphite-interchange.c,  graphite-poly.c: Likewise.
	* graphhite-scop-detection.c, graphite-sese-to-poly.c: Likewise.
	* graphite.c, graphite-poly.c: Likewise.
	* graphite-dependences.c: Include .
	(max_number_of_out_dimensions): Returns isl_stat.
	(extend_schedule_1): Likewise
	(extend_schedule): Corresponding changes.
	* graphite-optimize-isl.c: Include  and
	.
	(getSingleMap): Change return type of isl_stat.
	(optimize_isl): Conditionally use
	isl_options_set_schedule_serialize_sccs.
	* graphite-poly.h (isl_stat, isl_stat_ok): Define fallbacks
	if not HAVE_ISL_OPTIONS_SET_SCHEDULE_SERIALIZE_SCCS.


Index: configure.ac
===
--- configure.ac	(revision 230544)
+++ configure.ac	(working copy)
@@ -1660,6 +1660,9 @@
   ISL_CHECK_VERSION(0,12)
   if test "${gcc_cv_isl}" = no ; then
 ISL_CHECK_VERSION(0,14)
+if test "${gcc_cv_isl}" = no ; then
+  ISL_CHECK_VERSION(0,15)
+fi
   fi
 fi
   fi
Index: gcc/config.in
===
--- gcc/config.in	(revision 230544)
+++ gcc/config.in	(working copy)
@@ -1223,6 +1223,12 @@
 #endif
 
 
+/* Define if isl_options_set_schedule_serialize_sccs exists. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_ISL_OPTIONS_SET_SCHEDULE_SERIALIZE_SCCS
+#endif
+
+
 /* Define if isl_schedule_constraints_compute_schedule exists. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_ISL_SCHED_CONSTRAINTS_COMPUTE_SCHEDULE
Index: gcc/configure.ac
===
--- gcc/configure.ac	(revision 230544)
+++ gcc/configure.ac	(working copy)
@@ -5535,6 +5535,8 @@
 
   # Check whether isl_schedule_constraints_compute_schedule is available;
   # it's new in ISL-0.13.
+  # Check whether isl_options_set_schedule_serialize_sccs is available;
+  # it's new in ISL-0.15.
   saved_CFLAGS="$CFLAGS"
   CFLAGS="$CFLAGS $ISLINC"
   saved_LIBS="$LIBS"
@@ -5547,6 +5549,13 @@
   [ac_has_isl_schedule_constraints_compute_schedule=no])
   AC_MSG_RESULT($ac_has_isl_schedule_constraints_compute_schedule)
 
+  AC_MSG_CHECKING([Checking for isl_options_set_schedule_serialize_sccs])
+  AC_TRY_LINK([#include ],
+  [isl_options_set_schedule_serialize_sccs (NULL, 0);],
+  [ac_has_isl_options_set_schedule_serialize_sccs=yes],
+  [ac_has_isl_options_set_schedule_serialize_sccs=no])
+  AC_MSG_RESULT($ac_has_isl_options_set_schedule_serialize_sccs)
+
   LIBS="$saved_LIBS"
   CFLAGS="$saved_CFLAGS"
 
@@ -5554,6 +5563,11 @@
  AC_DEFINE(HAVE_ISL_SCHED_CONSTRAINTS_COMPUTE_SCHEDULE, 1,
[Define if isl_schedule_constraints_compute_schedule exists.])
   fi
+
+  if test x"$ac_has_isl_options_set_schedule_serialize_sccs" = x"yes"; then
+ AC_DEFINE(HAVE_ISL_OPTIONS_SET_SCHEDULE_SERIALIZE_SCCS, 1,
+   [Define if isl_options_set_schedule_serialize_sccs exists.])
+  fi
 fi
 
 
Index: gcc/graphite-blocking.c
===
--- gcc/graphite-blocking.c	(revision 230544)
+++ gcc/graphite-blocking.c	(working copy)
@@ -24,6 +24,7 @@
 #include "config.h"
 
 #ifdef HAVE_cloog
+#include 
 #include 
 #include 
 #include 
Index: gcc/graphite-dependences.c
===
--- gcc/graphite-dependences.c	(revision 230544)
+++ gcc/graphite-dependences.c	(working copy)
@@ -22,6 +22,7 @@
 #include "config.h"
 
 #ifdef HAVE_cloog
+#include 
 #include 
 #include 
 #include 
@@ -183,7 +184,7 @@
 /* Helper function used on each MAP of a isl_union_map.  Computes the
maximal output dimension.  */
 
-static int
+static isl_stat
 max_number_of_out_dimensions (__isl_take isl_map *map, void *user)
 {
   int global_max = *((int *) user);
@@ -195,7 +196,7 @@
 
   isl_map_free (map);
   isl_space_free (space);
-  return 0;
+  return isl_stat_ok;
 }
 

Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement

2015-11-18 Thread Steve Kargl
On Tue, Nov 17, 2015 at 05:01:42PM -0800, Steve Kargl wrote:
> On Tue, Nov 17, 2015 at 04:36:01PM -0800, Steve Kargl wrote:
> > On Wed, Nov 18, 2015 at 12:24:29AM +0100, Dominique d'Humières wrote:
> > > > ??? but I suspect gfc_reduce_init_expr() 
> > > > may be useful for PARAMETER statements as well (need to
> > > > check this!).
> > > 
> > > As in the following test
> > > 
> > >   module m
> > > implicit none
> > > type t
> > >   integer :: i
> > > end type t
> > > type(t), dimension(2), parameter :: a1  = (/ t(1), t(2) /)
> > > type(t), dimension(1), parameter :: c = spread ( a1(1), 1, 1 )
> > >   end module m
> > 
> > Yep.  We again arrive at gfc_conv_array_initializer with
> > expr->expr_type == EXPR_FUNCTION, which isn't handled correctly.
> > 
> > The issue seems deeply rooted in the handling of derived types,
> > which is actually worse than this!  But, that is definitely for
> > another day.  See PR67817. :(
> 
> Ugh. gfc_simplify_spread does not actually the use of SPREAD
> here, because source->expr_type == EXPR_STRUCTURE which is not
> handled.

Dominiq,

I plan to commit my patch and close this PR as the patch
fixes the issue raised in the PR.  I think the above
code highlights a specific issue with SPREAD, and a new PR
should be committed.
-- 
Steve


RE: [gomp4.1] Handle linear clause modifiers in declare simd

2015-11-18 Thread Tian, Xinmin
Yes, I will send the updated version to Jakub when I come back from SC15. I am 
updating it based on discussion with Jakub. 

Thanks,
Xinmin

-Original Message-
From: Jakub Jelinek [mailto:ja...@redhat.com] 
Sent: Wednesday, November 18, 2015 9:41 AM
To: Ilya Verbin; Tian, Xinmin
Cc: gcc-patches@gcc.gnu.org; Kirill Yukhin; andrew.n.senkev...@gmail.com
Subject: Re: [gomp4.1] Handle linear clause modifiers in declare simd

On Wed, Nov 18, 2015 at 08:30:53PM +0300, Ilya Verbin wrote:
> Could you please point to where the new ABI additions are documented?
> I can't find R/L/U parameter types in [1] and [2].
> 
> [1] 
> https://sourceware.org/glibc/wiki/libmvec?action=AttachFile=view
> rget=VectorABI.txt [2] 
> https://groups.google.com/forum/#!topic/x86-64-abi/LmppCfN1rZ4

Xinmin should have those in the Intel ABI pdf, not sure if the latest pdf is 
publicly available or not.

Jakub


[nios2, committed] remove duplicates in || expression

2015-11-18 Thread Sandra Loosemore
I've checked in this patch to fix PR 68410.  David, thanks for pointing 
out the think-o here.


-Sandra

2015-11-18  Sandra Loosemore  

	PR target/68410
	* config/nios2/nios2.c (cdx_and_immed): Remove duplicate tests
	from || expression.
Index: gcc/config/nios2/nios2.c
===
--- gcc/config/nios2/nios2.c	(revision 230549)
+++ gcc/config/nios2/nios2.c	(working copy)
@@ -4120,8 +4120,8 @@ cdx_and_immed (rtx op)
   HOST_WIDE_INT ival = INTVAL (op);
   return (ival == 1 || ival == 2 || ival == 3 || ival == 4
 	  || ival == 8 || ival == 0xf || ival == 0x10
-	  || ival == 0x10 || ival == 0x1f || ival == 0x20
-	  || ival == 0x3f || ival == 0x3f || ival == 0x7f
+	  || ival == 0x1f || ival == 0x20
+	  || ival == 0x3f || ival == 0x7f
 	  || ival == 0x80 || ival == 0xff || ival == 0x7ff
 	  || ival == 0xff00 || ival == 0x);
 }


Re: [PATCHES, PING*5] Enhance standard DWARF for Ada

2015-11-18 Thread Jason Merrill

On 10/20/2015 04:13 PM, Pierre-Marie de Rodat wrote:

Sorry about the slow review on these patches.  In future please feel 
free to ping me as often as once a week.



+  /* DWARF operations all work on signed integers.


Note that this will no longer be the case in DWARF 5, where stack 
elements have associated types.  Let's add a comment about that so 
perhaps we can remove the workaround in a future release.



+  /* ??? Set of all DW_OP_nop operations we remove: is it really a good thing
+ to free them, or should we instead let the garbage collect do it?  */


Might as well free them if we know they're garbage, it lets us reuse 
that memory sooner.



+  /* Trailing nops from loc_descritor_from_tree (if any) cannot be removed


missing 'p' in loc_descriptor_from_tree.


+  /* When translating a function into a DWARF procedure, contains the frame
+ offset *before* evaluating this operation.  It is -1 when not yet
+ initialized.  */
+  int dw_loc_frame_offset;
+  /* For DW_OP_call* operations: contains the number of stack slots that were
+ added overall when returning from the procedure (so it's negative if the
+ procedure removes slots).  */
+  int dw_loc_frame_offset_increment;


I'm not excited about adding another couple of words to every loc insn 
for uses that occur so rarely.


dw_loc_frame_offset seems to be primarily used for checking, can we make 
it conditional on ENABLE_CHECKING and use a hash_set to remember already 
visited nodes?


Instead of dw_loc_frame_offset_increment, can we look up the number of 
arguments from the callee?



+  /* Return a type to used in the debug info instead of TYPE, or NULL_TREE to


"to use"


+ /* Arbitrary scale factors cannot be describe in standard DWARF,


"described"

Jason


Re: [patch] FreeBSD x86_64/i386 apply r125920

2015-11-18 Thread Andreas Tobler

On 16.11.15 23:20, Andreas Tobler wrote:

Hi all,

I'm going to apply the below patch to trunk if there are no objections.

There are no regressions. From our pov, we should be in sync with Linux
here.

Also, I'm going to push this one out to 5.x after one week.



Committed on trunk as r230565



2015-11-16  Andreas Tobler  

* config/i386/freebsd.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Bring in the
commit from r125920 for FreeBSD.





[PATCH] Fix declaration of pthread-structs in s-osinte-rtems.ads (ada/68169)

2015-11-18 Thread Jan Sommer
Hello,

The paperwork seems to have gone through.
Here is the patch again for the 4.9.x, 5.x and trunk respectively.
I just pulled the head of the corresponding branches and created a new diff, so 
it should apply properly.

Best regards,

   JanIndex: gcc/ada/ChangeLog
===
--- gcc/ada/ChangeLog	(Revision 230563)
+++ gcc/ada/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,9 @@
+2015-11-18  Jan Sommer 
+
+	* s-oscons-tmplt.c: Generate pthread constants for RTEMS
+	* s-osinte-rtems.ads: Declare pthread structs as opaque types in Ada
+	Fixes PR ada/68169
+
 2015-10-09  Eric Botcazou  
 
 	* gcc-interface/Make-lang.in: Make sure that GNAT1_OBJS and not just
Index: gcc/ada/s-oscons-tmplt.c
===
--- gcc/ada/s-oscons-tmplt.c	(Revision 230563)
+++ gcc/ada/s-oscons-tmplt.c	(Arbeitskopie)
@@ -154,7 +154,7 @@ pragma Style_Checks ("M32766");
 # include <_types.h>
 #endif
 
-#ifdef __linux__
+#if defined (__linux__) || defined (__rtems__)
 # include 
 # include 
 #endif
@@ -1441,7 +1441,8 @@ CND(CLOCK_THREAD_CPUTIME_ID, "Thread CPU clock")
 CNS(CLOCK_RT_Ada, "")
 #endif
 
-#if defined (__APPLE__) || defined (__linux__) || defined (DUMMY)
+#if defined (__APPLE__) || defined (__linux__) || defined (__rtems__) || \
+  defined (DUMMY)
 /*
 
--  Sizes of pthread data types
@@ -1484,7 +1485,7 @@ CND(PTHREAD_RWLOCKATTR_SIZE, "pthread_rwlockattr_t
 CND(PTHREAD_RWLOCK_SIZE, "pthread_rwlock_t")
 CND(PTHREAD_ONCE_SIZE,   "pthread_once_t")
 
-#endif /* __APPLE__ || __linux__ */
+#endif /* __APPLE__ || __linux__ || __rtems__*/
 
 /*
 
Index: gcc/ada/s-osinte-rtems.ads
===
--- gcc/ada/s-osinte-rtems.ads	(Revision 230563)
+++ gcc/ada/s-osinte-rtems.ads	(Arbeitskopie)
@@ -51,6 +51,8 @@
 --  It is designed to be a bottom-level (leaf) package.
 
 with Interfaces.C;
+with System.OS_Constants;
+
 package System.OS_Interface is
pragma Preelaborate;
 
@@ -60,6 +62,7 @@ package System.OS_Interface is
subtype rtems_id   is Interfaces.C.unsigned;
 
subtype intis Interfaces.C.int;
+   subtype char   is Interfaces.C.char;
subtype short  is Interfaces.C.short;
subtype long   is Interfaces.C.long;
subtype unsigned   is Interfaces.C.unsigned;
@@ -68,7 +71,6 @@ package System.OS_Interface is
subtype unsigned_char  is Interfaces.C.unsigned_char;
subtype plain_char is Interfaces.C.plain_char;
subtype size_t is Interfaces.C.size_t;
-
---
-- Errno --
---
@@ -76,11 +78,11 @@ package System.OS_Interface is
function errno return int;
pragma Import (C, errno, "__get_errno");
 
-   EAGAIN: constant := 11;
-   EINTR : constant := 4;
-   EINVAL: constant := 22;
-   ENOMEM: constant := 12;
-   ETIMEDOUT : constant := 116;
+   EAGAIN: constant := System.OS_Constants.EAGAIN;
+   EINTR : constant := System.OS_Constants.EINTR;
+   EINVAL: constant := System.OS_Constants.EINVAL;
+   ENOMEM: constant := System.OS_Constants.ENOMEM;
+   ETIMEDOUT : constant := System.OS_Constants.ETIMEDOUT;
 
-
-- Signals --
@@ -448,6 +450,7 @@ package System.OS_Interface is
   ss_low_priority : int;
   ss_replenish_period : timespec;
   ss_initial_budget   : timespec;
+  sched_ss_max_repl   : int;
end record;
pragma Convention (C, struct_sched_param);
 
@@ -621,43 +624,34 @@ private
end record;
pragma Convention (C, timespec);
 
-   CLOCK_REALTIME :  constant clockid_t := 1;
-   CLOCK_MONOTONIC : constant clockid_t := 4;
+   CLOCK_REALTIME :  constant clockid_t := System.OS_Constants.CLOCK_REALTIME;
+   CLOCK_MONOTONIC : constant clockid_t := System.OS_Constants.CLOCK_MONOTONIC;
 
+   subtype char_array is Interfaces.C.char_array;
+
type pthread_attr_t is record
-  is_initialized  : int;
-  stackaddr   : System.Address;
-  stacksize   : int;
-  contentionscope : int;
-  inheritsched: int;
-  schedpolicy : int;
-  schedparam  : struct_sched_param;
-  cputime_clocked_allowed : int;
-  detatchstate: int;
+  Data : char_array (1 .. OS_Constants.PTHREAD_ATTR_SIZE);
end record;
pragma Convention (C, pthread_attr_t);
+   for pthread_attr_t'Alignment use Interfaces.C.double'Alignment;
 
type pthread_condattr_t is record
-  flags   : int;
-  process_shared  : int;
+  Data : char_array (1 .. OS_Constants.PTHREAD_CONDATTR_SIZE);
end record;
pragma Convention (C, pthread_condattr_t);
+   for pthread_condattr_t'Alignment use Interfaces.C.double'Alignment;
 
type pthread_mutexattr_t is record
-  is_initialized  : int;
-  process_shared  : int;
-  prio_ceiling: int;
-  protocol: int;
-  mutex_type  : 

[Ada] Crash on illegal use of limited view of classwide type

2015-11-18 Thread Arnaud Charlet
This patch fixes a compiler crash on an attempt to assign to a record component
whose type is the limited view of a classwide type.

Compiling

   gcc -c c3a1004e.adb

must yield:

   c3a1004e.adb:9:07: invalid use of limited view of "Department'CLASS"

---
limited with C3A1004E;
package C3A1004D is -- Departments
   type Emp_Ptr is access all C3A1004E.Employee'Class;
   type Department is tagged private;

private
   subtype Dept_Name is String (1 .. 13);
   type T_List is array (Positive range <>) of Emp_Ptr;

   type Department is tagged record
  Id   : Dept_Name := "<>";
  List : T_List (1 .. 5);
  Tot  : Natural := 0;
  During_Mod : Boolean := False;
   end record;
end C3A1004D;
---
package C3A1004E.Stub_Data is
   type C3A1004D_Department_Class_Access is
   access all C3A1004D.Department'Class;

   type Stub_Data_Type_Assign_Employee_dacb0f_a2752f is record
  D : C3A1004D_Department_Class_Access;
   end record;
   Stub_Data_Assign_Employee_dacb0f_a2752f :
   Stub_Data_Type_Assign_Employee_dacb0f_a2752f;

end C3A1004E.Stub_Data;
---
with C3A1004E.Stub_Data; use C3A1004E.Stub_Data;
--  with C3A1004D;--  missing
package body C3A1004E
is
   procedure Assign_Employee
 (E : in out Employee;
  D : in out C3A1004D.Department'Class) is
   begin
  D := Stub_Data.Stub_Data_Assign_Employee_dacb0f_a2752f.D.all;
   end Assign_Employee;

end C3A1004E;
---
limited with C3A1004D;
package C3A1004E is -- Employees
   type Dept_Ptr is access all C3A1004D.Department'Class;
   type Employee is tagged private;

   type Emp_Ptr is access all Employee'Class; -- used by function 'hire'

   procedure Assign_Employee
 (E : in out Employee;
  D : in out C3A1004D.Department'Class);

private
   type Employee is tagged record
  Dept : Dept_Ptr;
  Id   : access String;
  During_Mod : Boolean := False;
   end record;
end C3A1004E;

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

2015-11-18  Ed Schonberg  

* sem_ch5.adb (Analyze_Assignment): Diagnose assignment where
left-hand side has a limited view of a class-wide type.
* sem_ch6.adb (Detected_And_Exchange): Do not install a non-limited
view if the scope of the type of the formal is visible through
a limited_with_clause, even if the non-limited view is available.

Index: sem_ch5.adb
===
--- sem_ch5.adb (revision 230522)
+++ sem_ch5.adb (working copy)
@@ -506,6 +506,15 @@
  Ghost_Mode := Save_Ghost_Mode;
  return;
 
+  --  A class-wide type may be a limited view. This illegal case is not
+  --  caught by previous checks.
+
+  elsif Ekind (T1) = E_Class_Wide_Type
+and then From_Limited_With (T1)
+  then
+ Error_Msg_NE ("invalid use of limited view of&", Lhs, T1);
+ return;
+
   --  Enforce RM 3.9.3 (8): the target of an assignment operation cannot be
   --  abstract. This is only checked when the assignment Comes_From_Source,
   --  because in some cases the expander generates such assignments (such
Index: sem_ch6.adb
===
--- sem_ch6.adb (revision 230526)
+++ sem_ch6.adb (working copy)
@@ -2786,7 +2786,10 @@
  procedure Detect_And_Exchange (Id : Entity_Id);
  --  Determine whether Id's type denotes an incomplete type associated
  --  with a limited with clause and exchange the limited view with the
- --  non-limited one when available.
+ --  non-limited one when available. Note that the non-limited view
+ --  may exist because of a with_clause in another unit in the context,
+ --  but cannot be used because the current view of the enclosing unit
+ --  is still a limited view.
 
  -
  -- Detect_And_Exchange --
@@ -2795,7 +2798,10 @@
  procedure Detect_And_Exchange (Id : Entity_Id) is
 Typ : constant Entity_Id := Etype (Id);
  begin
-if From_Limited_With (Typ) and then Has_Non_Limited_View (Typ) then
+if From_Limited_With (Typ)
+  and then Has_Non_Limited_View (Typ)
+  and then not From_Limited_With (Scope (Typ))
+then
Set_Etype (Id, Non_Limited_View (Typ));
 end if;
  end Detect_And_Exchange;


[Ada] Better handling of invalid switches in GNAT.Command_Line

2015-11-18 Thread Arnaud Charlet
When the switch is ending with a '=', actual switches not followed with
a space or '=' were raising Invalid_Parameter, which was mileading. This
patch fixes this: exception Invalid_Switch is now raised and Full_Switch
returns the full command line switch.

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

2015-11-18  Vincent Celier  

* g-comlin.adb (Find_Longest_Matching_Switch): Do not take into
account a switch ending with '=' when the actual command line
switch is not followed with a space or '='.

Index: g-comlin.adb
===
--- g-comlin.adb(revision 230522)
+++ g-comlin.adb(working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 1999-2014, Free Software Foundation, Inc. --
+--  Copyright (C) 1999-2015, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -556,6 +556,10 @@
and then Switches (Index .. Last) =
   Arg (Arg'First .. Arg'First + Last - Index)
and then Last - Index + 1 > Switch_Length
+   and then
+ (P /= Parameter_With_Space_Or_Equal
+   or else Arg'Last = Arg'First + Last - Index
+   or else Arg (Arg'First + Last - Index + 1) = '=')
  then
 Param := P;
 Index_In_Switches := Index;


[PATCH, PR target/68405, i386, committed] Add missing break

2015-11-18 Thread Ilya Enkovich
Hi,

This patch adds missing break for ix86_expand_mask_vec_cmp.  Bootstrapped and 
tested on x86_64-unknown-linux-gnu.  Committed to trunk as obvious.

Thanks,
Ilya
--
gcc/

2015-11-18  Ilya Enkovich  

PR target/68405
* config/i386/i386.c (ix86_expand_mask_vec_cmp): Add missing
break.


diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 6173dae..43cbdfb 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -22948,6 +22948,8 @@ ix86_expand_mask_vec_cmp (rtx operands[])
 case GEU:
 case LTU:
   unspec_code = UNSPEC_UNSIGNED_PCMP;
+  break;
+
 default:
   unspec_code = UNSPEC_PCMP;
 }


Re: [OpenACC 0/7] host_data construct

2015-11-18 Thread Julian Brown
On Thu, 12 Nov 2015 11:16:21 +
Julian Brown  wrote:

> Here's a version of the patch which (hopefully) brings OpenACC on par
> with OpenMP with respect to use_device/use_device_ptr variables. The
> implementation is essentially the same now for OpenACC as for OpenMP
> (i.e. using mapping structures): so for now, only array or pointer
> variables can be used as use_device variables. The included tests have
> been adjusted accordingly.

Here's a rebased version of the patch, since the previous version no
longer applies cleanly. Re-tested OK (libgomp tests). ChangeLog as
before. (Ping.)

Juliancommit 0201a5927c380da65d6400afad4a0e277fb85786
Author: Julian Brown 
Date:   Mon Nov 2 06:31:47 2015 -0800

OpenACC host_data support using mapping regions.

diff --git a/gcc/c-family/c-pragma.c b/gcc/c-family/c-pragma.c
index 12c3e75..56cf697 100644
--- a/gcc/c-family/c-pragma.c
+++ b/gcc/c-family/c-pragma.c
@@ -1251,6 +1251,7 @@ static const struct omp_pragma_def oacc_pragmas[] = {
   { "declare", PRAGMA_OACC_DECLARE },
   { "enter", PRAGMA_OACC_ENTER_DATA },
   { "exit", PRAGMA_OACC_EXIT_DATA },
+  { "host_data", PRAGMA_OACC_HOST_DATA },
   { "kernels", PRAGMA_OACC_KERNELS },
   { "loop", PRAGMA_OACC_LOOP },
   { "parallel", PRAGMA_OACC_PARALLEL },
diff --git a/gcc/c-family/c-pragma.h b/gcc/c-family/c-pragma.h
index 999ac67..dd246b9 100644
--- a/gcc/c-family/c-pragma.h
+++ b/gcc/c-family/c-pragma.h
@@ -33,6 +33,7 @@ enum pragma_kind {
   PRAGMA_OACC_DECLARE,
   PRAGMA_OACC_ENTER_DATA,
   PRAGMA_OACC_EXIT_DATA,
+  PRAGMA_OACC_HOST_DATA,
   PRAGMA_OACC_KERNELS,
   PRAGMA_OACC_LOOP,
   PRAGMA_OACC_PARALLEL,
@@ -167,6 +168,7 @@ enum pragma_omp_clause {
   PRAGMA_OACC_CLAUSE_SELF,
   PRAGMA_OACC_CLAUSE_SEQ,
   PRAGMA_OACC_CLAUSE_TILE,
+  PRAGMA_OACC_CLAUSE_USE_DEVICE,
   PRAGMA_OACC_CLAUSE_VECTOR,
   PRAGMA_OACC_CLAUSE_VECTOR_LENGTH,
   PRAGMA_OACC_CLAUSE_WAIT,
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 7b10764..0a5c8bb 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -10267,6 +10267,8 @@ c_parser_omp_clause_name (c_parser *parser)
 	result = PRAGMA_OMP_CLAUSE_UNTIED;
 	  else if (!strcmp ("use_device_ptr", p))
 	result = PRAGMA_OMP_CLAUSE_USE_DEVICE_PTR;
+	  else if (!strcmp ("use_device", p))
+	result = PRAGMA_OACC_CLAUSE_USE_DEVICE;
 	  break;
 	case 'v':
 	  if (!strcmp ("vector", p))
@@ -11619,6 +11621,15 @@ c_parser_oacc_clause_tile (c_parser *parser, tree list)
   return c;
 }
 
+/* OpenACC 2.0:
+   use_device ( variable-list ) */
+
+static tree
+c_parser_oacc_clause_use_device (c_parser *parser, tree list)
+{
+  return c_parser_omp_var_list_parens (parser, OMP_CLAUSE_USE_DEVICE, list);
+}
+
 /* OpenACC:
wait ( int-expr-list ) */
 
@@ -12928,6 +12939,10 @@ c_parser_oacc_all_clauses (c_parser *parser, omp_clause_mask mask,
 	  clauses = c_parser_oacc_data_clause (parser, c_kind, clauses);
 	  c_name = "self";
 	  break;
+	case PRAGMA_OACC_CLAUSE_USE_DEVICE:
+	  clauses = c_parser_oacc_clause_use_device (parser, clauses);
+	  c_name = "use_device";
+	  break;
 	case PRAGMA_OACC_CLAUSE_SEQ:
 	  clauses = c_parser_oacc_simple_clause (parser, OMP_CLAUSE_SEQ,
 		clauses);
@@ -13577,6 +13592,29 @@ c_parser_oacc_enter_exit_data (c_parser *parser, bool enter)
 
 
 /* OpenACC 2.0:
+   # pragma acc host_data oacc-data-clause[optseq] new-line
+ structured-block
+*/
+
+#define OACC_HOST_DATA_CLAUSE_MASK	\
+	( (OMP_CLAUSE_MASK_1 << PRAGMA_OACC_CLAUSE_USE_DEVICE) )
+
+static tree
+c_parser_oacc_host_data (location_t loc, c_parser *parser)
+{
+  tree stmt, clauses, block;
+
+  clauses = c_parser_oacc_all_clauses (parser, OACC_HOST_DATA_CLAUSE_MASK,
+   "#pragma acc host_data");
+
+  block = c_begin_omp_parallel ();
+  add_stmt (c_parser_omp_structured_block (parser));
+  stmt = c_finish_oacc_host_data (loc, clauses, block);
+  return stmt;
+}
+
+
+/* OpenACC 2.0:
 
# pragma acc loop oacc-loop-clause[optseq] new-line
  structured-block
@@ -16884,6 +16922,9 @@ c_parser_omp_construct (c_parser *parser)
 case PRAGMA_OACC_DATA:
   stmt = c_parser_oacc_data (loc, parser);
   break;
+case PRAGMA_OACC_HOST_DATA:
+  stmt = c_parser_oacc_host_data (loc, parser);
+  break;
 case PRAGMA_OACC_KERNELS:
 case PRAGMA_OACC_PARALLEL:
   strcpy (p_name, "#pragma acc");
diff --git a/gcc/c/c-tree.h b/gcc/c/c-tree.h
index 6bc216a..848131e 100644
--- a/gcc/c/c-tree.h
+++ b/gcc/c/c-tree.h
@@ -653,6 +653,7 @@ extern tree c_finish_goto_ptr (location_t, tree);
 extern tree c_expr_to_decl (tree, bool *, bool *);
 extern tree c_finish_omp_construct (location_t, enum tree_code, tree, tree);
 extern tree c_finish_oacc_data (location_t, tree, tree);
+extern tree c_finish_oacc_host_data (location_t, tree, tree);
 extern tree c_begin_omp_parallel (void);
 extern tree c_finish_omp_parallel (location_t, tree, tree);
 extern tree c_begin_omp_task (void);
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 

Re: [patch] Fix PR middle-end/65958

2015-11-18 Thread Eric Botcazou
> Ok.  I wonder if we document GCCs VLA implementation somewhere so we can add
> a note on the interaction with alloca.

I found this in 10.7.2 Blocks:

"Variable-length arrays (VLAs) complicate this process, as their size
often refers to variables initialized earlier in the block.  To handle
this, we currently split the block at that point, and move the VLA into
a new, inner `BIND_EXPR'.  This strategy may change in the future."

which sounds totally obsolete to me.  Proposed change:

Index: doc/generic.texi
===
--- doc/generic.texi(revision 230453)
+++ doc/generic.texi(working copy)
@@ -1950,11 +1950,15 @@ this initialization replaces the @code{D
 will never require cleanups.  The scope of these variables is just the
 body
 
-Variable-length arrays (VLAs) complicate this process, as their
-size often refers to variables initialized earlier in the block.
-To handle this, we currently split the block at that point, and
-move the VLA into a new, inner @code{BIND_EXPR}.  This strategy
-may change in the future.
+Variable-length arrays (VLAs) complicate this process, as their size
+often refers to variables initialized earlier in the block and their
+initialization involves an explicit stack allocation.  To handle this,
+we add an indirection and replace them with a pointer to stack space
+allocated by means of @code{alloca}.  In most cases, we also arrange
+for this space to be reclaimed when the enclosing @code{BIND_EXPR} is
+exited, the exception to this being when there is an explicit call to
+@code{alloca} in the source code, in which case the stack is left
+depressed on exit of the @code{BIND_EXPR}.
 
 A C++ program will usually contain more @code{BIND_EXPR}s than
 there are syntactic blocks in the source code, since several C++


-- 
Eric Botcazou


[PATCH, PR tree-optimization/68327] Compute vectype for live phi nodes when copmputing VF

2015-11-18 Thread Ilya Enkovich
Hi,

When we compute vectypes we skip non-relevant phi nodes.  But we process 
non-relevant alive statements and thus may need vectype of non-relevant live 
phi node to compute mask vectype.  This patch enables vectype computation for 
live phi nodes.  Botostrapped and regtested on x86_64-unknown-linux-gnu.  OK 
for trunk?

Thanks,
Ilya
--
gcc/

2015-11-18  Ilya Enkovich  

PR tree-optimization/68327
* tree-vect-loop.c (vect_determine_vectorization_factor): Don't
skip non-relevant live phi nodes.

gcc/testsuite/

2015-11-18  Ilya Enkovich  

PR tree-optimization/68327
* gcc.dg/pr68327.c: New test.


diff --git a/gcc/testsuite/gcc.dg/pr68327.c b/gcc/testsuite/gcc.dg/pr68327.c
new file mode 100644
index 000..c3e6a94
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr68327.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+
+int a, d;
+char b, c;
+
+void
+fn1 ()
+{
+  int i = 0;
+  for (; i < 1; i++)
+d = 1;
+  for (; b; b++)
+a = 1 && (d & b);
+}
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 80937ec..7dba027 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -216,7 +216,8 @@ vect_determine_vectorization_factor (loop_vec_info 
loop_vinfo)
 
  gcc_assert (stmt_info);
 
- if (STMT_VINFO_RELEVANT_P (stmt_info))
+ if (STMT_VINFO_RELEVANT_P (stmt_info)
+ || STMT_VINFO_LIVE_P (stmt_info))
 {
  gcc_assert (!STMT_VINFO_VECTYPE (stmt_info));
   scalar_type = TREE_TYPE (PHI_RESULT (phi));


Re: [PATCH] Fix debug fallout of proposed PR68162 fix

2015-11-18 Thread Marek Polacek
On Wed, Nov 18, 2015 at 09:50:26AM +0100, Richard Biener wrote:
> --- gcc/dwarf2out.c   (revision 230428)
> +++ gcc/dwarf2out.c   (working copy)
> @@ -20784,9 +20784,10 @@ gen_type_die_with_usage (tree type, dw_d
>/* We are going to output a DIE to represent the unqualified version
>   of this type (i.e. without any const or volatile qualifiers) so
>   get the main variant (i.e. the unqualified version) of this type
> - now.  (Vectors are special because the debugging info is in the
> + now.  (Vectors and arrays are special because the debugging info is in 
> the
>   cloned type itself).  */
> -  if (TREE_CODE (type) != VECTOR_TYPE)
> +  if (TREE_CODE (type) != VECTOR_TYPE

There's VECTOR_TYPE_P for this if you want to use that.

Marek


Re: [RFC PATCH] Do not sanitize left shifts for -fwrapv

2015-11-18 Thread Marek Polacek
On Tue, Nov 17, 2015 at 02:32:50PM +0100, Paolo Bonzini wrote:
> Left shifts into the sign bit is a kind of overflow, and the
> standard chooses to treat left shifts of negative values the
> same way.
> 
> However, the -fwrapv option modifies the language to one where
> integers are defined as two's complement---which also defines
> entirely the behavior of shifts.  Disable sanitization of left
> shifts when -fwrapv is in effect.
> 
> This needs test cases of course, but I wanted to be sure in advance
> whether this is an acceptable change and whether it is considered
> a bug (thus acceptable for stage 3).  The same change was proposed
> for LLVM at https://llvm.org/bugs/show_bug.cgi?id=25552.
> 
> Paolo
> 
> * c-family/c-ubsan.c (ubsan_instrument_shift): Disable sanitization
> of left shifts for wrapping signed types as well.
> 
> 
> Index: c-family/c-ubsan.c
> ===
> --- c-family/c-ubsan.c(revision 227511)
> +++ c-family/c-ubsan.c(working copy)
> @@ -150,7 +150,7 @@
>   (unsigned) x >> (uprecm1 - y)
>   if non-zero, is undefined.  */
>if (code == LSHIFT_EXPR
> -  && !TYPE_UNSIGNED (type0)
> +  && !TYPE_OVERFLOW_WRAPS (type0)
>&& flag_isoc99)
>  {
>tree x = fold_build2 (MINUS_EXPR, op1_utype, uprecm1,
> @@ -165,7 +165,7 @@
>   x < 0 || ((unsigned) x >> (uprecm1 - y))
>   if > 1, is undefined.  */
>if (code == LSHIFT_EXPR
> -  && !TYPE_UNSIGNED (type0)
> +  && !TYPE_OVERFLOW_WRAPS (type0)
>&& (cxx_dialect >= cxx11))
>  {
>tree x = fold_build2 (MINUS_EXPR, op1_utype, uprecm1,

I think this would be ok provided you add some testcases (unless I'm missing
something).  Note that this suppresses instrumenting not only left-shifting
into the sign bit, but also shift overflows, so e.g. 10 << 30.

And I think this might be viewed on as a bug, thus should be ok even at this
stage if you open a PR.

Marek


[Ada] Concurrent constituents of a single protected/task type

2015-11-18 Thread Arnaud Charlet
This patch modifies the analysis of variable contracts to enforce the following
SPARK RM rule:

   9.3 - If a variable or a package which declares a state abstraction
   is declared immediately within the same declarative region as a
   single_task_declaration or a single_protected_declaration, then the Part_Of
   aspect of the variable or state abstraction may denote the task or protected
   unit. This indicates that the object or state abstraction is not part of the
   visible state or private state of its enclosing package.

   An object or state abstraction which "belongs" to a task unit in this way is
   treated as a local object of the task (e.g., it cannot be named in a Global
   aspect specification occurring outside of the body of the task unit, just as
   an object declared immediately within the task body could not be). An object
   or state abstraction which "belongs" to a protected unit in this way is
   treated as a component of the (anonymous) protected type (e.g., it can never
   be named in any Global aspect specification, just as a protected component
   could not be).

   The notional equivalences described above break down in the case of package
   elaboration. The presence or absence of such a Part_Of aspect specification
   is ignored in determining the legality of an Initializes or
   Initial_Condition aspect specification.


-- Source --


--  pack.ads

package Pack
  with SPARK_Mode,
   Initializes   =>
 (Var_1, Var_2, Var_3, Var_4),   --  OK
   Initial_Condition =>
 (Var_1 = 1  --  OK
   and then Var_2 = 2--  OK
   and then Var_3 = 3--  OK
   and then Var_4 = 4)   --  OK
is
   Var_1 : Integer := 1 with Part_Of => Prot;
   Var_2 : Integer := 2 with Part_Of => Tsk;

   protected Prot is
  entry Error_1 (Formal : out Integer)
with Global  => (Input => Var_2),--  Error
 Depends => (Formal => Var_2);   --  Error

  procedure Error_2 (Formal : Integer)
with Global  => (Output => Var_2),   --  Error
 Depends => (Var_2 => Formal);   --  Error

  function Error_3 return Boolean
with Global  => (Input => Var_2),--  Error
 Depends => (Error_3'Result => Var_2);   --  Error

  entry OK_1 (Formal : out Integer)
with Global  => (Input => Var_1),--  OK
 Depends => (Formal => Var_1);   --  OK

  procedure OK_2 (Formal : Integer)
with Global  => (Output => Var_1),   --  OK
 Depends => (Var_1 => Formal);   --  OK

  function OK_3 return Boolean
with Global  => (Input => Var_1),--  OK
 Depends => (OK_3'Result => Var_1);  --  OK
   end Prot;

   task Error_4
 with Global  => (Input => Var_1),   --  Error
  Depends => (null => Var_1);--  Error

   task Tsk
 with Global  => (Input => Var_2),   --  OK
  Depends => (null => Var_2);--  OK

   procedure Error_5;

   procedure Error_6
 with Pre  => Var_1 = 1, --  Error
  Post => Var_2 > 3; --  Error

   package Error_7 is
  procedure Error_8;
   end Error_7;

   Var_3 : Integer := 3 with Part_Of => Prot;
   Var_4 : Integer := 4 with Part_Of => Tsk;
end Pack;

--  pack.adb

package body Pack with SPARK_Mode is
   protected body Prot is
  entry Error_1 (Formal : out Integer) when True is
 procedure Nested_Proc is
 begin
Var_2 := Var_4;  --  Error
 end Nested_Proc;
  begin
 Var_2 := Var_4; --  Error
  end Error_1;

  procedure Error_2 (Formal : Integer) is
 procedure Nested_Proc (Formal : Integer) is
 begin null; end Nested_Proc;
  begin
 Var_2 := Var_4; --  Error
 Nested_Proc (Var_2);--  Error
 Nested_Proc (Var_4);--  Error
  end Error_2;

  function Error_3 return Boolean is
  begin
 return Var_2 = Var_4;   --  Error
  end Error_3;

  entry OK_1 (Formal : out Integer) when True is
  begin
 Var_1 := Var_3; --  

Re: [PATCH 1/5] [AARCH64]: Move #undef into .def files.

2015-11-18 Thread Marcus Shawcroft
On 17 November 2015 at 22:10, Andrew Pinski  wrote:
>
> This moves the #undef from the header files to the .def files like was done
> for builtins.def (https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00662.html).
>
> OK?   Bootstrapped and tested on aarch64-linux-gnu with no regressions.
>
> Thanks,
> Andrew Pinski
>
> * config/aarch64/aarch64-arches.def (AARCH64_ARCH): #undef at the end.
> * config/aarch64/aarch64-cores.def (AARCH64_CORE): Likewise.
> * config/aarch64/aarch64-fusion-pairs.def (AARCH64_FUSION_PAIR): Likewise.
> * config/aarch64/aarch64-tuning-flags.def (AARCH64_EXTRA_TUNING_OPTION): 
> Likewise.
> * config/aarch64/aarch64-opts.h (AARCH64_CORE): Don't #undef here.
> (AARCH64_ARCH): Likewise.
> * config/aarch64/aarch64-protos.h (AARCH64_FUSION_PAIR): Likewise.
> (AARCH64_EXTRA_TUNING_OPTION): Likewise.
> * config/aarch64/aarch64.c (AARCH64_FUION_PAIR): Likewise.
> (AARCH64_EXTRA_TUNING_OPTION): Likewise.
> (AARCH64_ARCH): Likewise.
> (AARCH64_CORE): Likewise.
> (AARCH64_OPT_EXTENSION): Likewise.
> * config/aarch64/aarch64.h (AARCH64_CORE): Likewise.
> * config/aarch64/driver-aarch64.c (AARCH64_OPT_EXTENSION): Likewise.
> (AARCH64_CORE): Likewise.
> (AARCH64_ARCH): Likewise.
> * common/config/aarch64/aarch64-common.c: Likewise.

OK Thanks /Marcus


[Ada] PR ada/66242 Finalization with restriction No_Exception_Propagation

2015-11-18 Thread Arnaud Charlet
This patch adds abort defer / undefer pairs for partial finalization due to
failed initialization and as part of unchecked deallocation actions. The patch
also suppresses the generation of exception variables and handlers related to
finalization actions when restriction No_Exception_Propagation is in effect.

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

2015-11-18  Hristian Kirtchev  

PR ada/66242

* exp_ch3.adb (Default_Initialize_Object): Reimplemented. Abort
defer / undefer pairs are now encapsulated in a block with
an AT END handler. Partial finalization now takes restriction
No_Exception_Propagation into account when generating blocks.
* exp_ch7.adb Various reformattings.
(Create_Finalizer): Change
the generation of abort defer / undefer pairs and explain the
lack of an AT END handler.
(Process_Transient_Objects): Add generation of abort defer/undefer
pairs.
* exp_ch9.adb Various reformattings.
(Build_Protected_Subprogram_Body): Use
Build_Runtime_Call to construct a call to Abort_Defer.
(Build_Protected_Subprogram_Call_Cleanup): Use
Build_Runtime_Call to construct a call to Abort_Undefer.
(Expand_N_Asynchronous_Select): Use Build_Runtime_Call to
construct a call to Abort_Defer.
* exp_intr.adb (Expand_Unc_Deallocation): Abort defer
/ undefer pairs are now encapsulated in a block with
an AT END handler. Finalization now takes restriction
No_Exception_Propagation into account when generating blocks.
* exp_util.ads, exp_util.adb (Wrap_Cleanup_Procedure): Removed.

Index: exp_ch7.adb
===
--- exp_ch7.adb (revision 230522)
+++ exp_ch7.adb (working copy)
@@ -1323,13 +1323,6 @@
   --
 
   procedure Create_Finalizer is
- Body_Id: Entity_Id;
- Fin_Body   : Node_Id;
- Fin_Spec   : Node_Id;
- Jump_Block : Node_Id;
- Label  : Node_Id;
- Label_Id   : Entity_Id;
-
  function New_Finalizer_Name return Name_Id;
  --  Create a fully qualified name of a package spec or body finalizer.
  --  The generated name is of the form: xx__yy__finalize_[spec|body].
@@ -1380,6 +1373,15 @@
 return Name_Find;
  end New_Finalizer_Name;
 
+ --  Local variables
+
+ Body_Id: Entity_Id;
+ Fin_Body   : Node_Id;
+ Fin_Spec   : Node_Id;
+ Jump_Block : Node_Id;
+ Label  : Node_Id;
+ Label_Id   : Entity_Id;
+
   --  Start of processing for Create_Finalizer
 
   begin
@@ -1532,16 +1534,17 @@
 
  --  Protect the statements with abort defer/undefer. This is only when
  --  aborts are allowed and the clean up statements require deferral or
- --  there are controlled objects to be finalized.
+ --  there are controlled objects to be finalized. Note that the abort
+ --  defer/undefer pair does not require an extra block because each
+ --  finalization exception is caught in its corresponding finalization
+ --  block. As a result, the call to Abort_Defer always takes place.
 
  if Abort_Allowed and then (Defer_Abort or Has_Ctrl_Objs) then
 Prepend_To (Finalizer_Stmts,
-  Make_Procedure_Call_Statement (Loc,
-Name => New_Occurrence_Of (RTE (RE_Abort_Defer), Loc)));
+  Build_Runtime_Call (Loc, RE_Abort_Defer));
 
 Append_To (Finalizer_Stmts,
-  Make_Procedure_Call_Statement (Loc,
-Name => New_Occurrence_Of (RTE (RE_Abort_Undefer), Loc)));
+  Build_Runtime_Call (Loc, RE_Abort_Undefer));
  end if;
 
  --  The local exception does not need to be reraised for library-level
@@ -1596,7 +1599,8 @@
  Defining_Unit_Name => Body_Id),
  Declarations   => Finalizer_Decls,
  Handled_Statement_Sequence =>
-   Make_Handled_Sequence_Of_Statements (Loc, Finalizer_Stmts));
+   Make_Handled_Sequence_Of_Statements (Loc,
+ Statements => Finalizer_Stmts));
 
  --  Step 4: Spec and body insertion, analysis
 
@@ -2806,9 +2810,7 @@
 
  else
 --  Generate:
---[Deep_]Finalize (Obj);  --  No_Exception_Propagation
-
---begin   --  Exception handlers allowed
+--begin
 --   [Deep_]Finalize (Obj);
 
 --exception
@@ -4727,6 +4729,8 @@
  --   Raised : Boolean := False;
 
  --begin
+ --   Abort_Defer;
+
  --   begin
  --  Hook_N := null;
  --  [Deep_]Finalize (Ctrl_Trans_Obj_N);
@@ -4752,26 +4756,8 @@
  --   if Raised and not Abrt then
   

Re: vector lightweight debug mode

2015-11-18 Thread Jonathan Wakely

On 17/11/15 20:49 +0100, François Dumont wrote:

On 16/11/2015 11:29, Jonathan Wakely wrote:

Not doing the checks is also an option. That minimizes the cost :-)


This is controlled by a macro, users already have this option.


True, but we're talking about maybe enabling these checks by default
when building linux distributions.



For the full debug mode we want to check everything we can, and accept
that has a cost.

For the lightweight one we need to evaluate the relative benefits. Is
it worth adding checks for errors that only happen rarely? Does the
benefit outweigh the cost?

I'm still not convinced that's the case for the "valid range" checks.
I'm willing to be convinced, but am not convinced yet.


Ok so I will remove this check. And what about insert position check ? I
guess this one too so I will remove it too. Note that will only remain
checks on the most basic operations that is to say those on which the
check will have the biggest impact proportionally.


Yes, that's a good point.

But my unproven assumption is that it's more common to use operator[]
incorrectly, rather than pass invalid iterators to range insert, which
is a relatively "advanced" operation.



I would like we push the simplest version so that people can start
experimenting.

I would also prefer concentrate on _GLIBCXX_DEBUG mode :-)




   It would be great to have it for gcc 6.0. I am working on the same
for other containers.


Please don't do the valid range checks for std::deque, the checks are
undefined for iterators into different containers and will not give a
reliable answer.


But debug mode is full of those checks, no ?


They're supposed to be guarded by checks for _M_can_compare, if they
aren't that's a regression. For debug mode we can tell whether two
iterators are comparable, because they store a pointer back to their
parent container. We can't check that in normal mode.



Re: [2/2] i386 ROP mitigation

2015-11-18 Thread Bernd Schmidt

On 11/16/2015 07:18 PM, Uros Bizjak wrote:

On Fri, Nov 13, 2015 at 9:47 PM, Bernd Schmidt  wrote:

This adds a new -mmitigate-rop option to the i386 port. The idea is to
mitigate against certain forms of attack called "return oriented
programming" that some of our security folks are concerned about.>

LGTM, and since the whole thing is protected by a -mmitigate-rop it
looks safe for mainline SVN.


Thanks. Committed with some minor changes: I've added a sentence to the 
documentation to clarify that this is in an early stage of development:


@item -mmitigate-rop
+@opindex mmitigate-rop
+Try to avoid generating code sequences that contain unintended return
+opcodes, to mitigate against certain forms of attack. At the moment,
+this option is limited in what it can do and should not be relied
+on to provide serious protection.


Bernd


Re: vector lightweight debug mode

2015-11-18 Thread Jonathan Wakely

On 18/11/15 12:27 +, Jonathan Wakely wrote:

But my unproven assumption is that it's more common to use operator[]
incorrectly, rather than pass invalid iterators to range insert, which
is a relatively "advanced" operation.


It's worth noting that the google/integration branch doesn't have any
checks on range insert/erase, and they have entire teams who work on
analysing their code base to find common programming errors, and
identify ways to avoid problems.

That doesn't mean we shouldn't include any checks that aren't in the
google branch, and we also shouldn't use all their checks, but it's
useful to look at what they considered important to check.



[PATCH] Fix PR67790

2015-11-18 Thread Richard Biener

This PR exposes an issue with how we deal with vectorization of
reductions with minus (x -= ...).  We do that by re-writing the
IL to a plus and a new negate stmt.  Unfortunately that messes
up UIDs of stmts in the loop which are used for dominance
checks by the vectorizer.

I've tried using a pattern for this but this fails miserably
(requiring some larger re-org of reduction detection).

Instead the much simpler fix is to not do the IL rewriting
but just fix up the reduction epilogue to use a plus when
the reduction code is a minus.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2015-11-18  Richard Biener  

PR tree-optimization/67790
* tree-vect-loop.c (vect_is_simple_reduction_1): Remove
IL rewrite for MINUS_EXPR reductions, rename back to ...
(vect_is_simple_reduction): ... this, removing the wrapper.
(vect_force_simple_reduction): Adjust.
(vectorizable_reduction): Adjust reduc_index for MINUS_EXPR
reductions and make use if reduc_index in all places.  For
the final reduction of MINUS_EXPR use PLUS_EXPR.

* gcc.dg/vect/pr67790.c: New testcase.

Index: gcc/tree-vect-loop.c
===
*** gcc/tree-vect-loop.c(revision 230455)
--- gcc/tree-vect-loop.c(working copy)
*** vect_is_slp_reduction (loop_vec_info loo
*** 2468,2483 
 if (a[i] < val)
ret_val = a[i];
  
-If MODIFY is true it tries also to rework the code in-place to enable
-detection of more reduction patterns.  For the time being we rewrite
-"res -= RHS" into "rhs += -RHS" when it seems worthwhile.
  */
  
  static gimple *
! vect_is_simple_reduction_1 (loop_vec_info loop_info, gimple *phi,
!   bool check_reduction, bool *double_reduc,
!   bool modify, bool need_wrapping_integral_overflow,
!   enum vect_reduction_type *v_reduc_type)
  {
struct loop *loop = (gimple_bb (phi))->loop_father;
struct loop *vect_loop = LOOP_VINFO_LOOP (loop_info);
--- 2477,2489 
 if (a[i] < val)
ret_val = a[i];
  
  */
  
  static gimple *
! vect_is_simple_reduction (loop_vec_info loop_info, gimple *phi,
! bool check_reduction, bool *double_reduc,
! bool need_wrapping_integral_overflow,
! enum vect_reduction_type *v_reduc_type)
  {
struct loop *loop = (gimple_bb (phi))->loop_father;
struct loop *vect_loop = LOOP_VINFO_LOOP (loop_info);
*** vect_is_simple_reduction_1 (loop_vec_inf
*** 2634,2640 
   gimple instruction for the first simple tests and only do this
   if we're allowed to change code at all.  */
if (code == MINUS_EXPR
-   && modify
&& (op1 = gimple_assign_rhs1 (def_stmt))
&& TREE_CODE (op1) == SSA_NAME
&& SSA_NAME_DEF_STMT (op1) == phi)
--- 2640,2645 
*** vect_is_simple_reduction_1 (loop_vec_inf
*** 2791,2813 
}
  }
  
-   /* If we detected "res -= x[i]" earlier, rewrite it into
-  "res += -x[i]" now.  If this turns out to be useless reassoc
-  will clean it up again.  */
-   if (orig_code == MINUS_EXPR)
- {
-   tree rhs = gimple_assign_rhs2 (def_stmt);
-   tree negrhs = make_ssa_name (TREE_TYPE (rhs));
-   gimple *negate_stmt = gimple_build_assign (negrhs, NEGATE_EXPR, rhs);
-   gimple_stmt_iterator gsi = gsi_for_stmt (def_stmt);
-   set_vinfo_for_stmt (negate_stmt, new_stmt_vec_info (negate_stmt, 
- loop_info));
-   gsi_insert_before (, negate_stmt, GSI_NEW_STMT);
-   gimple_assign_set_rhs2 (def_stmt, negrhs);
-   gimple_assign_set_rhs_code (def_stmt, PLUS_EXPR);
-   update_stmt (def_stmt);
- }
- 
/* Reduction is safe. We're dealing with one of the following:
   1) integer arithmetic and no trapv
   2) floating point arithmetic, and special flags permit this optimization
--- 2796,2801 
*** vect_is_simple_reduction_1 (loop_vec_inf
*** 2863,2869 
== vect_internal_def
  && !is_loop_header_bb_p (gimple_bb (def2)))
  {
!   if (check_reduction)
  {
  if (code == COND_EXPR)
{
--- 2851,2858 
== vect_internal_def
  && !is_loop_header_bb_p (gimple_bb (def2)))
  {
!   if (check_reduction
! && orig_code != MINUS_EXPR)
  {
  if (code == COND_EXPR)
{
*** vect_is_simple_reduction_1 (loop_vec_inf
*** 2915,2935 
return NULL;
  }
  
- /* Wrapper around vect_is_simple_reduction_1, that won't modify code
-in-place.  Arguments as there.  */
- 
- static gimple *
- vect_is_simple_reduction (loop_vec_info loop_info, gimple *phi,
-

Re: [Patch, vrp] Allow VRP type conversion folding only for widenings upto word mode

2015-11-18 Thread Richard Biener
On Wed, 18 Nov 2015, Senthil Kumar Selvaraj wrote:

> On Mon, Nov 16, 2015 at 10:02:15AM +0100, Richard Biener wrote:
> > On Sat, 14 Nov 2015, Senthil Kumar Selvaraj wrote:
> > 
> > > On Sat, Nov 14, 2015 at 09:57:40AM +0100, Richard Biener wrote:
> > > > On November 14, 2015 9:49:28 AM GMT+01:00, Senthil Kumar Selvaraj 
> > > >  wrote:
> > > > >On Sat, Nov 14, 2015 at 09:13:41AM +0100, Marc Glisse wrote:
> > > > >> On Sat, 14 Nov 2015, Senthil Kumar Selvaraj wrote:
> > > > >> 
> > > > >> >This patch came out of a discussion held in the gcc mailing list
> > > > >> >(https://gcc.gnu.org/ml/gcc/2015-11/msg00067.html).
> > > > >> >
> > > > >> >The patch restricts folding of conditional exprs with lhs previously
> > > > >> >set by a type conversion to occur only if the source of the type
> > > > >> >conversion's mode is word mode or smaller.
> > > > >> >
> > > > >> >Bootstrapped and reg tested on x86_64 (with
> > > > >--enable-languages=c,c++).
> > > > >> >
> > > > >> >If ok, could you commit please? I don't have commit access.
> > > > >> >
> > > > >> >Regards
> > > > >> >Senthil
> > > > >> >
> > > > >> >gcc/ChangeLog
> > > > >> >
> > > > >> >2015-11-11  Senthil Kumar Selvaraj 
> > > > >
> > > > >> >
> > > > >> >* tree-vrp.c (simplify_cond_using_ranges): Fold only
> > > > >> >if innerop's mode is word_mode or smaller.
> > > > >> >
> > > > >> >
> > > > >> >diff --git gcc/tree-vrp.c gcc/tree-vrp.c
> > > > >> >index e2393e4..c139bc6 100644
> > > > >> >--- gcc/tree-vrp.c
> > > > >> >+++ gcc/tree-vrp.c
> > > > >> >@@ -9467,6 +9467,8 @@ simplify_cond_using_ranges (gcond *stmt)
> > > > >> >  innerop = gimple_assign_rhs1 (def_stmt);
> > > > >> >
> > > > >> >  if (TREE_CODE (innerop) == SSA_NAME
> > > > >> >+ && (GET_MODE_SIZE(TYPE_MODE(TREE_TYPE(innerop)))
> > > > >> >+   <= GET_MODE_SIZE(word_mode))
> > > > >> >  && !POINTER_TYPE_P (TREE_TYPE (innerop)))
> > > > >> >{
> > > > >> >  value_range *vr = get_value_range (innerop);
> > > > >> 
> > > > >> I thought the result of the discussion was that the transformation is
> > > > >ok if
> > > > >> either it is narrowing or it widens but to something no bigger than
> > > > >> word_mode. So you should have 2 comparisons, or 1 with a max.
> > > > >
> > > > >Hmm, I came to the opposite conclusion - I thought Richard only okayed
> > > > >"widening upto word-mode", not the narrowing. 
> > > > 
> > > > I didn't mean to suggest narrowing is not OK.  In fact narrowing is 
> > > > always OK.
> > > 
> > > My bad. Here's a revised patch that checks for both conditions, using
> > > max as Marc suggested to limit to word_mode or narrowing conversions.
> > > 
> > > Bootstrapped and regtested for x86_64 with c and c++.
> > > 
> > > Is this ok? If yes, would you commit it
> > > for me please? I don't have commit access.
> > > 
> > > gcc/ChangeLog
> > > 2015-11-14  Senthil Kumar Selvaraj  
> > > 
> > >   * tree-vrp.c (simplify_cond_using_ranges): Fold only
> > >   if innerop's mode smaller or equal to word_mode or op0's mode.
> > > 
> > > 
> > > diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
> > > index e2393e4..cfd90e7 100644
> > > --- a/gcc/tree-vrp.c
> > > +++ b/gcc/tree-vrp.c
> > > @@ -9467,7 +9467,10 @@ simplify_cond_using_ranges (gcond *stmt)
> > >innerop = gimple_assign_rhs1 (def_stmt);
> > >  
> > >if (TREE_CODE (innerop) == SSA_NAME
> > > -   && !POINTER_TYPE_P (TREE_TYPE (innerop)))
> > > +   && !POINTER_TYPE_P (TREE_TYPE (innerop))
> > > + && (GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (innerop)))
> > > +   <= std::max (GET_MODE_SIZE (word_mode),
> > > +GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (op0))
> > 
> > Please use TYPE_PRECISION (...) and GET_MODE_PRECISION (word_mode) and
> > add a comment as to what we are testing here and why.
> > 
> > Btw, ideally we'd factor out a
> > 
> > bool
> > desired_pro_or_demotion_p (tree to_type, tree from_type) {}
> > 
> > function somewhere as we have similar tests throughout the compiler
> > that we might want to unify (and also have a central place to
> > eventually add a target hook if ever desired).
> > 
> > In fact in other places we also check that the type we promote/demote
> > to matches its mode precision or the type we promote/demote from
> > already does not.
> > 
> > I'd suggest tree.[ch] for that function.
> > 
> > Please also add a testcase.
> 
> How does the below patch look? Bootstrapped, but not regtested yet.
> 
> The testcase was rather tricky to write - I wasn't sure how to reliably
> get a type bigger than a word for all targets. I resorted to __int128,
> not sure it's a good idea though - I should probably add dg-skip-if for
> targets that don't support that. Do you know of a better way to write
> that?

Ah, I was hoping for an avr specific testcase (as you have that already)
scanning assembler output - after all we want to check 

Re: Port libvtv to Solaris

2015-11-18 Thread Richard Biener
On Tue, Nov 17, 2015 at 9:09 PM, Jeff Law  wrote:
> On 11/17/2015 06:24 AM, Rainer Orth wrote:
>>
>>
>> I'm still investigating what causes those timeouts, it seems to be a
>> scalability issue in libc.
>>
>> While I realize that we are past stage1, maybe the fact that this patch
>> is for an off-by-default feature and well localized still could allow it
>> into mainline at this point?
>
> Jakub, Richi & Joseph have the final decision, but my inclination would be
> to allow it.  As you note, it's well localized and for a default-off feature
> and we've allowed stuff like that to go through post stage1 in the past.

Works for me.

Richard.

> jeff
>


Re: RFA (GGC): PATCH to support GGC finalizers with PCH

2015-11-18 Thread Richard Biener
On Tue, Nov 17, 2015 at 8:46 PM, Jason Merrill  wrote:
> On 11/17/2015 09:39 AM, Richard Biener wrote:
>>
>> On Tue, Nov 17, 2015 at 3:09 PM, Jason Merrill  wrote:
>>>
>>> While I was looking at the interaction of delayed folding with GGC, I
>>> noticed that ggc_handle_finalizers currently runs no finalizers if
>>> G.context_depth != 0.  So any GC objects in a greater depth will still be
>>> collected, but they won't have their finalizers run.  This specifically
>>> affects compiles that use a PCH file, since G.context_depth is set to 1
>>> after loading the PCH.
>>>
>>> This patch fixes ggc_handle_finalizers to look at the depth of each
>>> finalizer so that we still don't try to run finalizers for
>>> non-collectable
>>> objects loaded from the PCH, but we do run finalizers for collectable
>>> objects allocated after loading the PCH.
>>>
>>> I ended up not relying on this for delayed folding, but it still seems
>>> like
>>> a good bug fix.
>>>
>>> Tested x86_64-pc-linux-gnu.  OK for trunk?
>>
>>
>> Hmm, this enlarges finalizer/vec_finalizer.  Wouldn't it be better to
>> add separate finalizer vectors for context_depth != 0?  (I'm proposing
>> to add one for exactly context_depth == 1)
>>
>> When is context_depth increased other than for PCH?
>
>
> That seems to be the only place it's changed currently.  I was assuming that
> the generalized way ggc-page handles context_depth was intended to support
> more depths in the future (perhaps for collecting after processing a nested
> function?), so my patch was following that model.
>
> How about this?

Looks good apart from the .safe_grow_cleared () which should probably
better do a .safe_push (vNULL)?  ("cleared" exposes too much of an
implementation detail for vec<>)

Thanks,
Richard.

>
> Jason
>


[Ada] Crash on function returning limited view of class-wide type

2015-11-18 Thread Arnaud Charlet
THis patch fixes a compiler crash on a function that returns a class-wide
type, when the type is first obtained by means of a limited view.

The following must compile quietly:

---
with New_Network;
limited with New_Network.Bus;

package Topology is

   type Vertex
 (Nb_Terminals : New_Network.Terminal_Count) is tagged null record;

   function Get_Bus
 (Bus_Name : in New_Network.Name) return New_Network.Bus.Object'Class;
end Topology;
---
with New_Network.Bus;

package body Topology is

   function Get_Bus
 (Bus_Name : in New_Network.Name) return New_Network.Bus.Object'Class
   is
  O : New_Network.Bus.Object;
   begin
  return O;
   end Get_Bus;

end Topology;
---
package New_Network is

   --  General dimensioning named numbers

   Max_Element_Terminals : constant := 6;
   --  Max number of terminals an element or a bus can have

   Max_Bus_Terminals : constant := 4;
   --  Max number of bonds a bus can have

   type Terminal_Count is range
 0 .. Integer'Max (Max_Bus_Terminals, Max_Element_Terminals);

   subtype Name is String
 with Dynamic_Predicate => Name'Length > 0;

end New_Network;
---
with Topology;
package New_Network.Bus is
   type Object is new Topology.Vertex (10) with null record;
end New_Network.Bus;

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

2015-11-18  Ed Schonberg  

* sem_ch6.adb (Process_Formals): A function declaration that
returns a class-wide type must have freeing deferred, so that it
is not frozen before the class-wide type and its root type are
frozen. This is significant when there may be a limited view of
the class_wide type in another package.

Index: sem_ch6.adb
===
--- sem_ch6.adb (revision 230522)
+++ sem_ch6.adb (working copy)
@@ -10423,6 +10423,17 @@
 
   if Nkind (Related_Nod) = N_Function_Specification then
  Analyze_Return_Type (Related_Nod);
+
+ --  If return type is class-wide, subprogram freezing may be
+ --  delayed as well.
+
+ if Is_Class_Wide_Type (Etype (Current_Scope))
+   and then not Is_Thunk (Current_Scope)
+   and then Nkind (Unit_Declaration_Node (Current_Scope)) =
+ N_Subprogram_Declaration
+ then
+Set_Has_Delayed_Freeze (Current_Scope);
+ end if;
   end if;
 
   --  Now set the kind (mode) of each formal


[Ada] Normalize_Pathname with unresolved reference directory

2015-11-18 Thread Arnaud Charlet
This change removes an unnecessary limitation whereby Normalize_Pathname
would not accept an unresolved path name as the reference directory, and
would furthermore return incorrect results, rather than an error diagnostic,
in the case where input did not comply with this limitation.

The following test case must produce the indicated output:

$ gnatmake -q resolve_against_dotdot
$ ./resolve_against_dotdot
/a/b/dir
/a/b/dir
/tmp/bar/dir

with Ada.Text_IO; use Ada.Text_IO;
with GNAT.OS_Lib; use GNAT.OS_Lib;

procedure Resolve_Against_DotDot is
begin
   Put_Line (Normalize_Pathname ("../dir", "/a/b/c"));
   Put_Line (Normalize_Pathname ("../dir", "/a/b/c/SUB/.."));
   Put_Line (Normalize_Pathname ("/tmp/foo/../bar/dir", "/a/b/c/SUB/.."));
end;

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

2015-11-18  Thomas Quinot  

* s-os_lib.ads, s-os_lib.adb(Normalize_Pathname): Support the case of
an unresolved Directory argument, by recursively resolving it
against the current dir.

Index: s-os_lib.adb
===
--- s-os_lib.adb(revision 230522)
+++ s-os_lib.adb(working copy)
@@ -2081,34 +2081,35 @@
   ---
 
   function Get_Directory (Dir : String) return String is
- Result : String (1 .. Dir'Length + 1);
- Length : constant Natural := Dir'Length;
-
   begin
  --  Directory given, add directory separator if needed
 
- if Length > 0 then
-Result (1 .. Length) := Dir;
+ if Dir'Length > 0 then
+declare
+   Result : String   :=
+  Normalize_Pathname (Dir, "") & Directory_Separator;
+   Last   : Positive := Result'Last - 1;
 
---  On Windows, change all '/' to '\'
+begin
+   --  On Windows, change all '/' to '\'
 
-if On_Windows then
-   for J in 1 .. Length loop
-  if Result (J) = '/' then
- Result (J) := Directory_Separator;
-  end if;
-   end loop;
-end if;
+   if On_Windows then
+  for J in Result'First .. Last - 1 loop
+ if Result (J) = '/' then
+Result (J) := Directory_Separator;
+ end if;
+  end loop;
+   end if;
 
---  Add directory separator, if needed
+   --  Include additional directory separator, if needed
 
-if Result (Length) = Directory_Separator then
-   return Result (1 .. Length);
-else
-   Result (Result'Length) := Directory_Separator;
-   return Result;
-end if;
+   if Result (Last) /= Directory_Separator then
+  Last := Last + 1;
+   end if;
 
+   return Result (Result'First .. Last);
+end;
+
  --  Directory name not given, get current directory
 
  else
Index: s-os_lib.ads
===
--- s-os_lib.ads(revision 230522)
+++ s-os_lib.ads(working copy)
@@ -505,19 +505,17 @@
   Resolve_Links  : Boolean := True;
   Case_Sensitive : Boolean := True) return String;
--  Returns a file name as an absolute path name, resolving all relative
-   --  directories, and symbolic links. The parameter Directory is a fully
-   --  resolved path name for a directory, or the empty string (the default).
-   --  Name is the name of a file, which is either relative to the given
-   --  directory name, if Directory is non-null, or to the current working
-   --  directory if Directory is null. The result returned is the normalized
-   --  name of the file. For most cases, if two file names designate the same
-   --  file through different paths, Normalize_Pathname will return the same
-   --  canonical name in both cases. However, there are cases when this is not
-   --  true; for example, this is not true in Unix for two hard links
-   --  designating the same file.
+   --  directories, and symbolic links. If Name is a relative path, it is
+   --  interpreted relative to Directory, or to the current directory if
+   --  Directory is the empty string (the default). The result returned is
+   --  the normalized name of the file, containing no "." or ".." components,
+   --  and no duplicated directory separators. For most cases, if two file
+   --  names designate the same file through different paths,
+   --  Normalize_Pathname will return the same canonical name in both cases.
+   --  However, there are cases when this is not true; for example, this is
+   --  not true in Unix for two hard links designating the same file.
--
-   --  On Windows, the returned path will start with a drive letter except
-   --  when Directory is not empty and does not include a 

Re: [patch] Fix PR middle-end/65958

2015-11-18 Thread Richard Biener
On Wed, Nov 18, 2015 at 11:06 AM, Eric Botcazou  wrote:
> Hi,
>
> this is the underlying issue of PR middle-end/65958: the compiler generates
> wrong code when alloca is used in conjunction with a VLA since the latter
> causes the stack space allocated to the former to be wrongly reclaimed.
> So the proposed fix is not to reclaim any stack space in this case.
>
> Bootstrapped/regtested on x86_64-suse-linux, OK for mainline and 5.x branch?

Ok.  I wonder if we document GCCs VLA implementation somewhere so we can add
a note on the interaction with alloca.

Thanks,
Richard.

>
> 2015-11-18  Eric Botcazou  
>
> PR middle-end/65958
> * gimplify.c (struct gimplify_ctx): Turn boolean fields into 1-bit
> fields, add keep_stack and reorder them.
> (gimplify_bind_expr): Save gimplify_ctxp->keep_stack on entry then
> set it to false.  Do not insert a stack save/restore pair if it has
> been set to true by the gimplification of the statements.
> Restore it to the saved value on exit if it is still false.
> (gimplify_vla_decl): Do not set gimplify_ctxp->save_stack here.
> (gimplify_call_expr) : New case.  Set
> either save_stack or keep_stack depending on CALL_ALLOCA_FOR_VAR_P.
>
>
> 2015-11-18  Eric Botcazou  
>
> * gcc.dg/vla-24.c: New test.
>
> --
> Eric Botcazou


Re: [PATCH, VECTOR ABI] Add __attribute__((__simd__)) to GCC.

2015-11-18 Thread Andreas Schwab
Kirill Yukhin <kirill.yuk...@gmail.com> writes:

> diff --git a/gcc/testsuite/c-c++-common/attr-simd-3.c 
> b/gcc/testsuite/c-c++-common/attr-simd-3.c
> new file mode 100644
> index 000..2bbdf04
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/attr-simd-3.c
> @@ -0,0 +1,5 @@
> +/* { dg-do compile } */
> +/* { dg-options "-fcilkplus" } */
> +/* { dg-prune-output "undeclared here \\(not in a function\\)|\[^\n\r\]* was 
> not declared in this scope" } */
> +
> +void f () __attribute__((__simd__, __vector__)); /* { dg-error "in the same 
> function marked as a Cilk Plus" } */

FAIL: c-c++-common/attr-simd-3.c  -std=gnu++11  (test for errors, line 5)
FAIL: c-c++-common/attr-simd-3.c  -std=gnu++11 (test for excess errors)
Excess errors:
/usr/local/gcc/gcc-20151118/gcc/testsuite/c-c++-common/attr-simd-3.c:5:48: 
warning: '__simd__' attribute does not apply to types [-Wattributes]

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: Add gencfn-macros.c

2015-11-18 Thread Tom de Vries

On 07/11/15 13:35, Richard Sandiford wrote:

This patch automatically generates case macros such as:

 CASE_CFN_SQRT

for each {F,,L} floating-point built-in function and each {,L,LL,IMAX}
integer built-in function.  The macros match the same built-in
functions as CASE_FLT_FN and CASE_INT_FN but in addition include
the associated internal function, if any.

The idea is to make sure that users of combined_fn don't need to know
which built-in functions have internal-function equivalents.  If we add
a new function to internal-fn.def, all combined_fn users should pick it
up automatically.

The generator wants to use "hash_set ",
so the patch follows hash_map in using the types given by the
traits as the key.  This is a no-op for current users of hash_set.

Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabi.


Hi,

this seems to have caused:

PR68406 - dbxout.c:2570:16: error: no matching function for call to 
'hash_set::traverse(vec*)'


Thanks,
- Tom



[PATCH] Fix reassoci ICE (PR tree-optimization/68157)

2015-11-18 Thread Jakub Jelinek
Hi!

attempt_builtin_powi and its caller does not set uids of the stmts it adds,
which in some cases may lead to reassoc ICEs.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk/5.3?

2015-11-18  Jakub Jelinek  

PR tree-optimization/68157
* tree-ssa-reassoc.c (attempt_builtin_powi): Set uid of
pow_stmt or mul_stmt from stmt's uid.
(reassociate_bb): Set uid of mul_stmt from stmt's uid.

* g++.dg/opt/pr68157.C: New test.

--- gcc/tree-ssa-reassoc.c.jj   2015-11-04 11:12:19.0 +0100
+++ gcc/tree-ssa-reassoc.c  2015-11-16 12:46:51.749495480 +0100
@@ -4451,6 +4451,7 @@ attempt_builtin_powi (gimple *stmt, vec<
   power));
  gimple_call_set_lhs (pow_stmt, iter_result);
  gimple_set_location (pow_stmt, gimple_location (stmt));
+ gimple_set_uid (pow_stmt, gimple_uid (stmt));
  gsi_insert_before (, pow_stmt, GSI_SAME_STMT);
 
  if (dump_file && (dump_flags & TDF_DETAILS))
@@ -4534,6 +4535,7 @@ attempt_builtin_powi (gimple *stmt, vec<
  mul_stmt = gimple_build_assign (target_ssa, MULT_EXPR,
  op1, op2);
  gimple_set_location (mul_stmt, gimple_location (stmt));
+ gimple_set_uid (mul_stmt, gimple_uid (stmt));
  gsi_insert_before (, mul_stmt, GSI_SAME_STMT);
  rf1->repr = target_ssa;
 
@@ -4551,6 +4553,7 @@ attempt_builtin_powi (gimple *stmt, vec<
   power));
  gimple_call_set_lhs (pow_stmt, iter_result);
  gimple_set_location (pow_stmt, gimple_location (stmt));
+ gimple_set_uid (pow_stmt, gimple_uid (stmt));
  gsi_insert_before (, pow_stmt, GSI_SAME_STMT);
}
 
@@ -4562,6 +4565,7 @@ attempt_builtin_powi (gimple *stmt, vec<
  mul_stmt = gimple_build_assign (new_result, MULT_EXPR,
  result, iter_result);
  gimple_set_location (mul_stmt, gimple_location (stmt));
+ gimple_set_uid (mul_stmt, gimple_uid (stmt));
  gsi_insert_before (, mul_stmt, GSI_SAME_STMT);
  gimple_set_visited (mul_stmt, true);
  result = new_result;
@@ -4919,6 +4923,7 @@ reassociate_bb (basic_block bb)
  mul_stmt = gimple_build_assign (lhs, MULT_EXPR,
  powi_result, target_ssa);
  gimple_set_location (mul_stmt, gimple_location (stmt));
+ gimple_set_uid (mul_stmt, gimple_uid (stmt));
  gsi_insert_after (, mul_stmt, GSI_NEW_STMT);
}
}
--- gcc/testsuite/g++.dg/opt/pr68157.C.jj   2015-11-16 12:41:41.583871551 
+0100
+++ gcc/testsuite/g++.dg/opt/pr68157.C  2015-11-16 12:54:30.613990591 +0100
@@ -0,0 +1,18 @@
+// PR tree-optimization/68157
+// { dg-do compile }
+// { dg-options "-Ofast" }
+
+double a, b, c, d;
+int h, foo ();
+
+void
+bar ()
+{
+  while (foo ())
+{
+  double e = b * a * a;
+  double f = b * d;
+  if (h)
+   c = e + f;
+}
+}

Jakub


Re: [PATCH] PR/67682, break SLP groups up if only some elements match

2015-11-18 Thread Richard Biener
On Tue, Nov 17, 2015 at 5:46 PM, Alan Lawrence  wrote:
> On 16/11/15 14:42, Christophe Lyon wrote:
>>
>>
>> Hi Alan,
>>
>> I've noticed that this new test (gcc.dg/vect/bb-slp-subgroups-3.c)
>> fails for armeb targets.
>> I haven't had time to look at more details yet, but I guess you can
>> reproduce it quickly enough.
>>
>
> Thanks - yes I see it now.
>
> -fdump-tree-optimized looks sensible:
>
> __attribute__((noinline))
> test ()
> {
>   vector(4) int vect__14.21;
>   vector(4) int vect__2.20;
>   vector(4) int vect__2.19;
>   vector(4) int vect__3.13;
>   vector(4) int vect__2.12;
>
>   :
>   vect__2.12_24 = MEM[(int *)];
>   vect__3.13_27 = vect__2.12_24 + { 1, 2, 3, 4 };
>   MEM[(int *)] = vect__3.13_27;
>   vect__2.19_31 = MEM[(int *) + 16B];
>   vect__2.20_33 = VEC_PERM_EXPR  }>;
>   vect__14.21_35 = vect__2.20_33 * { 3, 4, 5, 7 };
>   MEM[(int *) + 16B] = vect__14.21_35;
>   return;
> }
>
> but while a[0...3] end up containing 5 7 9 11 as expected,
> a[4..7] end up with 30 32 30 28 rather than the expected 12 24 40 70.
> That is, we end up with (10 8 6 4), rather than the expected (4 6 8 10),
> being multiplied by {3,4,5,7}. Looking at the RTL, those values come from a
> UZP1/2 pair that should extract elements {0,2,4,6} of b. Assembler, with my
> workings as to what's in each register:
>
> test:
> @ args = 0, pretend = 0, frame = 0
> @ frame_needed = 0, uses_anonymous_args = 0
> @ link register save eliminated.
> movwr2, #:lower16:b
> movtr2, #:upper16:b
> vldrd22, .L11
> vldrd23, .L11+8
> ;; So d22 = (3 4), d23 = (5 7), q11 = (5 7 3 4)
> movwr3, #:lower16:a
> movtr3, #:upper16:a
> vld1.64 {d16-d17}, [r2:64]
> ;; So d16 = (b[0] b[1]), d17 = (b[2] b[3]), q8 = (b[2] b[3] b[0] b[1])
> vmovq9, q8  @ v4si
> ;; q9 = (b[2] b[3] b[0] b[1])
> vldrd20, [r2, #16]
> vldrd21, [r2, #24]
> ;; So d20 = (b[4] b[5]), d21 = (b[6] b[7]), q10 = (b[6] b[7] b[4] b[5])
> vuzp.32 q10, q9
> ;; So  q10 = (b[3] b[1] b[7] b[5]), i.e. d20 = (b[7] b[5]) and d21 = (b[3]
> b[1])
> ;; and q9 = (b[2] b[0] b[6] b[4]), i.e. d18 = (b[6] b[4]) and d19 = (b[2]
> b[0])
> vldrd20, .L11+16
> vldrd21, .L11+24
> ;; d20 = (1 2), d21 = (3 4), q10 = (3 4 1 2)
> vmul.i32q9, q9, q11
> ;; q9 = (b[2]*5 b[0]*7 b[6]*3 b[4]*4)
> ;; i.e. d18 = (b[6]*3 b[4]*4) and d19 = (b[2]*5 b[0]*7)
> vadd.i32q8, q8, q10
> ;; q8 = (b[2]+3 b[3]+4 b[0]+1 b[1]+2)
> ;; i.e. d16 = (b[0]+1 b[1]+2), d17 = (b[2]+3 b[3]+4)
> vst1.64 {d16-d17}, [r3:64]
> ;; a[0] = b[0]+1, a[1] = b[1]+2, a[2] = b[2]+3, a[3]=b[3]+4 all ok
> vstrd18, [r3, #16]
> ;; a[4] = b[6]*3, a[5] = b[4]*4
> vstrd19, [r3, #24]
> ;; a[6] = b[2]*5, a[7] = b[0]*7
> bx  lr
> .L12:
> .align  3
> .L11:
> .word   3
> .word   4
> .word   5
> .word   7
> .word   1
> .word   2
> .word   3
> .word   4
>
> Which is to say - the bit order in the q-registers, is neither big- nor
> little-endian, but the elements get stored back to memory in a consistent
> order with how they were loaded, so we're OK as long as there are no
> permutes. Unfortunately for UZP this lane ordering mixup is not idempotent
> and messes everything up...
>
> Hmmm. I'm feeling that "properly" fixing this testcase, amounts to fixing
> armeb's whole register-numbering/lane-flipping scheme, and might be quite a
> large task. OTOH it might also fix the significant number of failing
> vectorizer tests. A simpler solution might be to disable...some part of
> vector supporton armeb, but I'm not sure which part would be best, yet.
>
> Thoughts (CC maintainers)?

As most of the permutation support in the arm backend is disabled
for armeb I suppose disabling some more of it is appropriate ...

Or finally sitting down and fixing the mess.  For constant permutes
fixing it on the constant side would be an option I guess.

Richard.

> --Alan
>


[Ada] Spurious visibility error with private subtye, inlining and instance

2015-11-18 Thread Arnaud Charlet
This patch fixes an oversight in the restoring of proper use visibility on
the full view of a private subtype, when a use clause for the enclosing
package appears before an instantiation of a child unit of the package, the
instantiation is followed by a use of the private subtype, and the compilation
has inlining enabled.

The following must compile quietly;

   gcc -c -gnatn p.adb

---
with Q; use Q;
with S.Data;

package body P is

   package My_Data is new S.Data (Integer);

   procedure Process_Commands (Commands : S.Symbol_Ref) is
 Ret : constant S.Symbol_Ref := Func (Commands);
   begin
 null;
   end;

end P;
---
with S;

package P is

   procedure Process_Commands (Commands : S.Symbol_Ref);

end P;
---
with R; use R;

package body Q is

  function Func (Symbol : S.Symbol_Ref) return S.Symbol_Ref is
procedure Do_Query is new Query (0);
  begin
return Symbol;
  end;

end Q;
---
with S;

package Q is

  function Func (Symbol : S.Symbol_Ref) return S.Symbol_Ref;
  pragma Inline (Func);

end Q;
---
with S.Data;

package body R is

   use S;

   package My_Data is new S.Data (Integer);

   procedure Query (Symbol : Not_Null_Symbol_Ref) is
   begin
  null;
   end;

end R;
---
with S;

package R is

   generic
  I : Integer;
   procedure Query (Symbol : S.Not_Null_Symbol_Ref);

end R;
---
private with T;

package S is

   type Symbol_Ref is private;

   subtype Not_Null_Symbol_Ref is Symbol_Ref;

private

   type Symbol_Ref is new T.Pointer_Type;

end S;
---
package body T is

   package body Define_Field is

  function Access_Field (Object : Pointer_Type) return access Field_Type is
  begin
 return null;
  end Access_Field;

   end Define_Field;

end T;
---
package T is

   type Pointer_Type is private;

   generic
  type Field_Type is limited private;
   package Define_Field is
  function Access_Field (Object : Pointer_Type) return access Field_Type;
   end Define_Field;

private

   type Pointer_Type is access Integer;

end T;
---
package body S.Data is

   package My_Field is new T.Define_Field (Data_Type);

   function Access_Data (Symbol : Symbol_Ref) return access Data_Type is
  Pointer : constant T.Pointer_Type := T.Pointer_Type (Symbol);
   begin
  return My_Field.Access_Field (Pointer);
   end Access_Data;

end S.Data;
---
generic
   type Data_Type is limited private;
package S.Data is

   function Access_Data (Symbol : Symbol_Ref) return access Data_Type;

end S.Data;

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

2015-11-18  Ed Schonberg  

* sem_ch7.adb (Uninstall_Declarations): Before swapping private
and full views, ensure that the potential use visbility of the
two views is consistent.

Index: sem_ch7.adb
===
--- sem_ch7.adb (revision 230522)
+++ sem_ch7.adb (working copy)
@@ -2675,10 +2675,13 @@
  --  If this is a private type with a full view (for example a local
  --  subtype of a private type declared elsewhere), ensure that the
  --  full view is also removed from visibility: it may be exposed when
- --  swapping views in an instantiation.
+ --  swapping views in an instantiation. Similarly, ensure that the
+ --  use-visibility is properly set on both views.
 
  if Is_Type (Id) and then Present (Full_View (Id)) then
-Set_Is_Immediately_Visible (Full_View (Id), False);
+Set_Is_Immediately_Visible (Full_View (Id), False);
+Set_Is_Potentially_Use_Visible (Full_View (Id),
+  Is_Potentially_Use_Visible (Id));
  end if;
 
  if Is_Tagged_Type (Id) and then Ekind (Id) = E_Record_Type then


[PATCH] Fix ICE with mangling aliases (PR c++/67354)

2015-11-18 Thread Jakub Jelinek
Hi!

This is an attempt to fix an ICE on the following testcase.
Normally (when !at_eof), note_mangling_alias just queues up the mangling
aliases in a vector, but when maybe_thunk_body is called at_eof,
it calls cdtor_comdat_group which mangles first the names of both the
fns to determine the name of the comdat group, and as it is at_eof,
it emits the mangling aliases right away.  That means the base ctor is
put into one same_comdat_group (together with its mangling alias),
and comp ctor into a different same_comdat_group.  Then a few lines later
we want to put the base ctor as same body alias with the comp ctor, but ICE,
because the two are already having non-NULL same_comdat_group.
The patch in this case temporarily queues up the mangling aliases in the
vector and only after putting the two ctors into the same comdat group
adds the mangling aliases.
If changing at_eof for this is too big hack, perhaps we could have a
different bool just to affect the mangling aliases (and set it to true
in generate_mangling_aliases or so).

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

2015-11-18  Jakub Jelinek  

PR c++/67354
* cp-tree.h (generate_mangling_aliases): New prototype.
* decl2.c (generate_mangling_aliases): No longer static.
* optimize.c (maybe_thunk_body): Defer emitting mangling aliases
if at_eof until the fns are put into the same comdat group.

* g++.dg/abi/mangle67.C: New test.

--- gcc/cp/cp-tree.h.jj 2015-11-14 19:35:53.0 +0100
+++ gcc/cp/cp-tree.h2015-11-16 15:58:44.143844060 +0100
@@ -5772,6 +5772,7 @@ extern tree cxx_maybe_build_cleanup   (tr
 
 /* in decl2.c */
 extern void note_mangling_alias(tree, tree);
+extern void generate_mangling_aliases  (void);
 extern bool check_java_method  (tree);
 extern tree build_memfn_type   (tree, tree, cp_cv_quals, 
cp_ref_qualifier);
 extern tree build_pointer_ptrmemfn_type(tree);
--- gcc/cp/decl2.c.jj   2015-11-14 19:35:53.0 +0100
+++ gcc/cp/decl2.c  2015-11-16 15:58:09.944330046 +0100
@@ -4399,7 +4399,7 @@ note_mangling_alias (tree decl ATTRIBUTE
 #endif
 }
 
-static void
+void
 generate_mangling_aliases ()
 {
   while (!vec_safe_is_empty (mangling_aliases))
--- gcc/cp/optimize.c.jj2015-11-14 19:35:53.0 +0100
+++ gcc/cp/optimize.c   2015-11-16 16:01:56.467111088 +0100
@@ -270,7 +270,11 @@ maybe_thunk_body (tree fn, bool force)
 }
   else if (HAVE_COMDAT_GROUP)
 {
+  /* Avoid creating mangling aliases if at_eof.  */
+  int save_at_eof = at_eof;
+  at_eof = 0;
   tree comdat_group = cdtor_comdat_group (fns[1], fns[0]);
+  at_eof = save_at_eof;
   cgraph_node::get_create (fns[0])->set_comdat_group (comdat_group);
   cgraph_node::get_create (fns[1])->add_to_same_comdat_group
(cgraph_node::get_create (fns[0]));
@@ -281,6 +285,9 @@ maybe_thunk_body (tree fn, bool force)
   virtual, it goes into the same comdat group as well.  */
cgraph_node::get_create (fns[2])->add_to_same_comdat_group
  (symtab_node::get (fns[0]));
+  /* Emit them now that the thunks are same comdat group aliases.  */
+  if (save_at_eof)
+   generate_mangling_aliases ();
   TREE_PUBLIC (fn) = false;
   DECL_EXTERNAL (fn) = false;
   DECL_INTERFACE_KNOWN (fn) = true;
--- gcc/testsuite/g++.dg/abi/mangle67.C.jj  2015-11-16 16:07:05.614620070 
+0100
+++ gcc/testsuite/g++.dg/abi/mangle67.C 2015-11-16 16:06:35.0 +0100
@@ -0,0 +1,21 @@
+// PR c++/67354
+// { dg-do compile { target c++11 } }
+// { dg-options "-fabi-version=5 -Os" }
+
+class A
+{
+};
+
+template 
+void
+foo ()
+{
+  T ();
+}
+
+struct B : virtual A
+{
+  template  B () {}
+};
+
+auto f = foo;

Jakub


Re: [PATCH][RTL-ree] PR rtl-optimization/68194: Restrict copy instruction in presence of conditional moves

2015-11-18 Thread Kyrill Tkachov


On 17/11/15 23:11, Bernd Schmidt wrote:

On 11/17/2015 02:03 PM, Kyrill Tkachov wrote:

+  || !reg_overlap_mentioned_p (tmp_reg, SET_SRC (PATTERN (cand->insn
 return false;



Well, I think the statement we want to make is
"return false from this function if the two expressions contain the same
register number".


I looked at it again and I think I'll need more time to really figure out 
what's going on in this pass.

However, about the above... either I'm very confused, or the actual statement here is "return false _unless_ the two expressions contain the same register number". In the testcase, the regs in question are ax and bx, which is then 
rejected if the patch has been applied.


I'm sorry, it is my mistake in explaining. I meant to say:
"return false from this function unless the two expressions contain the same
 register number"



(gdb) p tmp_reg
(reg:SI 0 ax)
(gdb) p cand->insn
(insn 59 117 60 7 (set (reg:SI 4 si [orig:107 D.1813 ] [107])
(sign_extend:SI (reg:HI 3 bx [orig:99 D.1813 ] [99])))

And I think it would be better to strengthen that to "return false unless registers 
are identical". (From the above it's clear however that a plain rtx_equal_p wouldn't 
work since there's an extension in the operand).


So the three relevant instructions are:
I1: (set (reg:HI 0 ax)
 (mem:HI (symbol_ref:DI ("f"

I2: (set (reg:SI 3 bx)
 (if_then_else:SI (eq (reg:CCZ 17 flags)
(const_int 0))
(reg:SI 0 ax)
(reg:SI 3 bx)))

I3: (set (reg:SI 4 si)
 (sign_extend:SI (reg:HI 3 bx)))

I1 is def_insn, I3 is cand->insn. tmp_reg is 'ax'. What we want to do is reject 
this transformation
because the destination of def_insn (aka I1), that is 'ax', is not the operand 
of the extend operation
in cand->insn (aka I3). As you said, rtx_equal won't work on just SET_SRC (PATTERN 
(cand->insn)) because
it's an extend operation. So reg_overlap_mentioned should be appropriate.
Hope this helps.



Also, I had another look at the testcase. It uses __builtin_printf and dg-output, which 
is at least unusual. Try to use the normal "if (cond) abort ()".



I did not try to remove the __builtin_printf because the use of 'f' there is 
needed to trigger this.
There are at least two other dups of this PR: 68328 and 68185 the testcases for which 
have an "if (cond) abort ();" form.
I'll use them instead.




Bernd





Re: Incorrect code due to indirect tail call of varargs function with hard float ABI

2015-11-18 Thread Ramana Radhakrishnan
On 18/11/15 00:32, Kugan wrote:
>> > Hi Ramana,
>> > 
>> > Thanks for the review. I have opened a gcc bug-report for this. I tested
>> > the attached patch for  arm-none-linux-gnueabihf and
>> > arm-none-linux-gnueabi with no new regressions. Is this OK?
>> > 
>> > 
>> > Thanks,
>> > Kugan
>> > 
>> > gcc/ChangeLog:
>> > 
>> > 2015-11-18  Kugan Vivekanandarajah  
>> > 
>> >PR target/68390
>> >* config/arm/arm.c (arm_function_ok_for_sibcall): Get function type
>> >for indirect function call.
>> > 
>> > gcc/testsuite/ChangeLog:
>> > 
>> > 2015-11-18  Kugan Vivekanandarajah  
>> > 
>> >PR target/68390
>> >* gcc.target/arm/PR68390.c: New test.
>> > 
>> > 
> Hi Ramana,
> 
> With further testing on bare-metal, I found that for the following decl
> has to be null for indirect functions.
> 
>   if (TARGET_AAPCS_BASED
>   && arm_abi == ARM_ABI_AAPCS
>   && decl
>   && DECL_WEAK (decl))
> return false;

Ok .. yes that's right.

> 
> Here is the updated patch and ChangeLog. Sorry for the noise.
> 
> Thanks,
> Kugan
> 
> 
> gcc/ChangeLog:
> 
> 2015-11-18  Kugan Vivekanandarajah  
> 
>   PR target/68390
>   * config/arm/arm.c (arm_function_ok_for_sibcall): Get function type
>   for indirect function call.
> 
> gcc/testsuite/ChangeLog:
> 
> 2015-11-18  Kugan Vivekanandarajah  
> 
>   PR target/68390
>   * gcc.target/arm/PR68390.c: New test.
> 

s/PR/pr in the test name and put this in gcc.c-torture/execute instead - there 
is nothing ARM specific about the test. Tests in gcc.target/arm should really 
only be architecture specific. This isn't.

> 
> 
> 
> p.txt
> 
> 
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index a379121..0dae7da 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -6680,8 +6680,13 @@ arm_function_ok_for_sibcall (tree decl, tree exp)
>a VFP register but then need to transfer it to a core
>register.  */
>rtx a, b;
> +  tree fn_decl = decl;

Call it decl_or_type instead - it's really that ... 

>  
> -  a = arm_function_value (TREE_TYPE (exp), decl, false);
> +  /* If it is an indirect function pointer, get the function type.  */
> +  if (!decl)
> + fn_decl = TREE_TYPE (TREE_TYPE (CALL_EXPR_FN (exp)));
> +

This is probably just my mail client - but please watch out for indentation.

> +  a = arm_function_value (TREE_TYPE (exp), fn_decl, false);
>b = arm_function_value (TREE_TYPE (DECL_RESULT (cfun->decl)),
> cfun->decl, false);
>if (!rtx_equal_p (a, b))


OK with those changes.

Ramana



Re: [PATCH][GCC][ARM] Disable neon testing for armv7-m

2015-11-18 Thread Andre Vieira

On 17/11/15 10:10, James Greenhalgh wrote:

On Mon, Nov 16, 2015 at 01:15:32PM +, Andre Vieira wrote:

On 16/11/15 12:07, James Greenhalgh wrote:

On Mon, Nov 16, 2015 at 10:49:11AM +, Andre Vieira wrote:

Hi,

   This patch changes the target support mechanism to make it
recognize any ARM 'M' profile as a non-neon supporting target. The
current check only tests for armv6 architectures and earlier, and
does not account for armv7-m.

   This is correct because there is no 'M' profile that supports neon
and the current test is not sufficient to exclude armv7-m.

   Tested by running regressions for this testcase for various ARM targets.

   Is this OK to commit?

   Thanks,
   Andre Vieira

gcc/testsuite/ChangeLog:
2015-11-06  Andre Vieira  

 * gcc/testsuite/lib/target-supports.exp
   (check_effective_target_arm_neon_ok_nocache): Added check
   for M profile.



 From 2c53bb9ba3236919ecf137a4887abf26d4f7fda2 Mon Sep 17 00:00:00 2001
From: Andre Simoes Dias Vieira 
Date: Fri, 13 Nov 2015 11:16:34 +
Subject: [PATCH] Disable neon testing for armv7-m

---
  gcc/testsuite/lib/target-supports.exp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 
75d506829221e3d02d454631c4bd2acd1a8cedf2..8097a4621b088a93d58d09571cf7aa27b8d5fba6
 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2854,7 +2854,7 @@ proc check_effective_target_arm_neon_ok_nocache { } {
int dummy;
/* Avoid the case where a test adds -mfpu=neon, but the 
toolchain is
   configured for -mcpu=arm926ej-s, for example.  */
-   #if __ARM_ARCH < 7
+   #if __ARM_ARCH < 7 || __ARM_ARCH_PROFILE == 'M'
#error Architecture too old for NEON.


Could you fix this #error message while you're here?

Why we can't change this test to look for the __ARM_NEON macro from ACLE:

#if __ARM_NEON < 1
   #error NEON is not enabled
#endif

Thanks,
James



There is a check for this already:
'check_effective_target_arm_neon'. I think the idea behind
arm_neon_ok is to check whether the hardware would support neon,
whereas arm_neon is to check whether neon was enabled, i.e.
-mfpu=neon was used or a mcpu was passed that has neon enabled by
default.

The comments for 'check_effective_target_arm_neon_ok_nocache'
highlight this, though maybe the comments for
check_effective_target_arm_neon could be better.

# Return 1 if this is an ARM target supporting -mfpu=neon
# -mfloat-abi=softfp or equivalent options.  Some multilibs may be
# incompatible with these options.  Also set et_arm_neon_flags to the
# best options to add.

proc check_effective_target_arm_neon_ok_nocache
...
/* Avoid the case where a test adds -mfpu=neon, but the toolchain is
configured for -mcpu=arm926ej-s, for example.  */
...


and

# Return 1 if this is a ARM target with NEON enabled.

proc check_effective_target_arm_neon


OK, got it - sorry for my mistake, I had the two procs confused.

I'd still like to see the error message fixed "Architecture too old for NEON."
is not an accurate description of the problem.

Thanks,
James



This OK?

Cheers,
Andre
From cd58546931221197f83a82afa7ac14291d675d48 Mon Sep 17 00:00:00 2001
From: Andre Simoes Dias Vieira 
Date: Fri, 13 Nov 2015 11:16:34 +
Subject: [PATCH] Disable neon testing for armv7-m

---
 gcc/testsuite/lib/target-supports.exp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 75d506829221e3d02d454631c4bd2acd1a8cedf2..91ff64f3d0d6ede50dcdb30cccf43be90e376a44 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2854,8 +2854,8 @@ proc check_effective_target_arm_neon_ok_nocache { } {
 		int dummy;
 		/* Avoid the case where a test adds -mfpu=neon, but the toolchain is
 		   configured for -mcpu=arm926ej-s, for example.  */
-		#if __ARM_ARCH < 7
-		#error Architecture too old for NEON.
+		#if __ARM_ARCH < 7 || __ARM_ARCH_PROFILE == 'M'
+		#error Architecture does not support NEON.
 		#endif
 	} "$flags"] } {
 		set et_arm_neon_flags $flags
-- 
1.9.1



Re: [PATCH, 10/16] Add pass_oacc_kernels pass group in passes.def

2015-11-18 Thread Richard Biener
On Tue, 17 Nov 2015, Tom de Vries wrote:

> On 17/11/15 16:18, Richard Biener wrote:
> > > > IMHO autopar needs to handle induction itself.
> > > >
> > > >I'm not sure what you mean. Could you elaborate?  Autopar handles
> > > induction
> > > >variables, but it doesn't handle exit phis reading the final value of the
> > > >induction variable. Is that what you want fixed? How?
> > Yes.  Perform final value replacement.
> > 
> 
> I see. Calling scev_const_prop in pass_parallelize_loops_oacc_kernels seems to
> work fine.
> 
> Doing the same for pass_parallelize_loops like this:
> ...
> diff --git a/gcc/tree-parloops.c b/gcc/tree-parloops.c
> index 17415a8..d944395 100644
> --- a/gcc/tree-parloops.c
> +++ b/gcc/tree-parloops.c
> @@ -2787,6 +2787,9 @@ pass_parallelize_loops::execute (function *fun)
>if (number_of_loops (fun) <= 1)
>  return 0;
> 
> +  unsigned int sccp_todo = scev_const_prop ();
> +  gcc_assert (sccp_todo == 0);
> +
>if (parallelize_loops ())
>  {
>fun->curr_properties &= ~(PROP_gimple_eomp);
> ...
> seems to fix PR 68373 - "autopar fails on loop exit phi with argument defined
> outside loop".
> 
> The new scev_const_prop call in autopar rewrites this phi into an assignment,
> and that allows parloops to succeed:
> ...
> final value replacement:
>   n_2 = PHI 
>   with
>   n_2 = n_4(D);
> ...

That works for me but please factor out the final value replacement
code from scev_const_prop.  I think best would be to have a
helper that does final value replacement for a single loop so you
can call it for loops to paralellize only.

Richard.

> Thanks,
> - Tom
> 
> 

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


Re: [PATCH, VECTOR ABI] Add __attribute__((__simd__)) to GCC.

2015-11-18 Thread Andreas Schwab
Kirill Yukhin  writes:

> diff --git a/gcc/testsuite/c-c++-common/attr-simd.c 
> b/gcc/testsuite/c-c++-common/attr-simd.c
> new file mode 100644
> index 000..b4eda34
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/attr-simd.c
> @@ -0,0 +1,32 @@
> +/* { dg-do compile } */
> +/* { dg-options "-fdump-tree-optimized" } */
> +
> +__attribute__((__simd__))
> +extern
> +int simd_attr (void)
> +{
> +  return 0;
> +}
> +
> +/* { dg-final { scan-tree-dump "simd_attr\[ \\t\]simdclone|vector" 
> "optimized" } } */

On ia64:

FAIL: c-c++-common/attr-simd.c  -Wc++-compat   scan-tree-dump optimized 
"simd_attr[ \\t]simdclone|vector"
FAIL: c-c++-common/attr-simd.c  -Wc++-compat   scan-tree-dump optimized 
"simd_attr2[ \\t]simdclone|vector"

$ grep simd_attr attr-simd.c.194t.optimized 
;; Function simd_attr (simd_attr, funcdef_no=0, decl_uid=1389, cgraph_uid=0, 
symbol_order=0)
simd_attr ()
;; Function simd_attr2 (simd_attr2, funcdef_no=1, decl_uid=1392, cgraph_uid=1, 
symbol_order=1)
simd_attr2 ()

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


[Ada] Undefined symbols with pragma Initialize_Scalars

2015-11-18 Thread Arnaud Charlet
This patch modifies the generation of a constrained array subtype for an object
declaration to use an external name. This ensures that a reference to the array
subtype bounds are consistent when compiling with various switches and pragmas
such as Initialize_Scalars. No simple reproducer possible.

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

2015-11-18  Hristian Kirtchev  

* exp_util.adb (Expand_Subtype_From_Expr): Add new formal
parameter Related_Id and propagate it to Make_Subtype_From_Expr.
(Make_Subtype_From_Expr): Add new formal parameter
Related_Id. Create external entities when requested by the caller.
* exp_util.ads (Expand_Subtype_From_Expr): Add new formal
parameter Related_Id. Update the comment on usage.
(Make_Subtype_From_Expr): Add new formal parameter
Related_Id. Update the comment on usage.
* sem_ch3.adb (Analyze_Object_Declaration): Add local variable
Related_Id. Generate an external constrained subtype when the
object is a public symbol.

Index: sem_ch3.adb
===
--- sem_ch3.adb (revision 230522)
+++ sem_ch3.adb (working copy)
@@ -3390,6 +3390,7 @@
   --  Local variables
 
   Save_Ghost_Mode : constant Ghost_Mode_Type := Ghost_Mode;
+  Related_Id  : Entity_Id;
 
--  Start of processing for Analyze_Object_Declaration
 
@@ -4015,7 +4016,25 @@
return;
 
 else
-   Expand_Subtype_From_Expr (N, T, Object_Definition (N), E);
+   --  Ensure that the generated subtype has a unique external name
+   --  when the related object is public. This guarantees that the
+   --  subtype and its bounds will not be affected by switches or
+   --  pragmas that may offset the internal counter due to extra
+   --  generated code.
+
+   if Is_Public (Id) then
+  Related_Id := Id;
+   else
+  Related_Id := Empty;
+   end if;
+
+   Expand_Subtype_From_Expr
+ (N => N,
+  Unc_Type  => T,
+  Subtype_Indic => Object_Definition (N),
+  Exp   => E,
+  Related_Id=> Related_Id);
+
Act_T := Find_Type_Of_Object (Object_Definition (N), N);
 end if;
 
Index: exp_util.adb
===
--- exp_util.adb(revision 230522)
+++ exp_util.adb(working copy)
@@ -2152,7 +2152,8 @@
  (N : Node_Id;
   Unc_Type  : Entity_Id;
   Subtype_Indic : Node_Id;
-  Exp   : Node_Id)
+  Exp   : Node_Id;
+  Related_Id: Entity_Id := Empty)
is
   Loc : constant Source_Ptr := Sloc (N);
   Exp_Typ : constant Entity_Id  := Etype (Exp);
@@ -2357,7 +2358,7 @@
   else
  Remove_Side_Effects (Exp);
  Rewrite (Subtype_Indic,
-   Make_Subtype_From_Expr (Exp, Unc_Type));
+   Make_Subtype_From_Expr (Exp, Unc_Type, Related_Id));
   end if;
end Expand_Subtype_From_Expr;
 
@@ -6566,8 +6567,9 @@
--  3. If Expr is class-wide, creates an implicit class-wide subtype
 
function Make_Subtype_From_Expr
- (E   : Node_Id;
-  Unc_Typ : Entity_Id) return Node_Id
+ (E  : Node_Id;
+  Unc_Typ: Entity_Id;
+  Related_Id : Entity_Id := Empty) return Node_Id
is
   List_Constr : constant List_Id:= New_List;
   Loc : constant Source_Ptr := Sloc (E);
@@ -6584,18 +6586,32 @@
   if Is_Private_Type (Unc_Typ)
 and then Has_Unknown_Discriminants (Unc_Typ)
   then
+ --  The caller requests a unque external name for both the private and
+ --  the full subtype.
+
+ if Present (Related_Id) then
+Full_Subtyp :=
+  Make_Defining_Identifier (Loc,
+Chars => New_External_Name (Chars (Related_Id), 'C'));
+Priv_Subtyp :=
+  Make_Defining_Identifier (Loc,
+Chars => New_External_Name (Chars (Related_Id), 'P'));
+
+ else
+Full_Subtyp := Make_Temporary (Loc, 'C');
+Priv_Subtyp := Make_Temporary (Loc, 'P');
+ end if;
+
  --  Prepare the subtype completion. Use the base type to find the
  --  underlying type because the type may be a generic actual or an
  --  explicit subtype.
 
- Utyp:= Underlying_Type (Base_Type (Unc_Typ));
- Full_Subtyp := Make_Temporary (Loc, 'C');
- Full_Exp:=
+ Utyp := Underlying_Type (Base_Type (Unc_Typ));
+
+ Full_Exp :=
Unchecked_Convert_To (Utyp, Duplicate_Subexpr_No_Checks (E));
  Set_Parent (Full_Exp, Parent (E));
 
- Priv_Subtyp := Make_Temporary (Loc, 'P');
-

[Ada] Malformed argument with pragma Refined_State

2015-11-18 Thread Arnaud Charlet
This patch modifies the grammars of pragmas Abstract_State, Depends, Global,
Initializes, Refined_Depends, Refined_Global and Refined_State to explicitly
request a single argument. No need for a test as this is a documentation
enhancement.

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

2015-11-18  Hristian Kirtchev  

* sem_prag.adb (Analyze_Pragma): Update the grammars of pragmas
Abstract_State, Depends, Global, Initializes, Refined_Depends,
Refined_Global and Refined_State.

Index: sem_prag.adb
===
--- sem_prag.adb(revision 230522)
+++ sem_prag.adb(working copy)
@@ -9998,7 +9998,7 @@
  --  ABSTRACT_STATE_LIST ::=
  -- null
  --  |  STATE_NAME_WITH_OPTIONS
- --  | (STATE_NAME_WITH_OPTIONS {, STATE_NAME_WITH_OPTIONS} )
+ --  | (STATE_NAME_WITH_OPTIONS {, STATE_NAME_WITH_OPTIONS})
 
  --  STATE_NAME_WITH_OPTIONS ::=
  -- STATE_NAME
@@ -10018,7 +10018,7 @@
 
  --  EXTERNAL_PROPERTY_LIST ::=
  -- EXTERNAL_PROPERTY
- --  | (EXTERNAL_PROPERTY {, EXTERNAL_PROPERTY} )
+ --  | (EXTERNAL_PROPERTY {, EXTERNAL_PROPERTY})
 
  --  EXTERNAL_PROPERTY ::=
  --Async_Readers[=> boolean_EXPRESSION]
@@ -13412,8 +13412,8 @@
  --  pragma Depends (DEPENDENCY_RELATION);
 
  --  DEPENDENCY_RELATION ::=
- --null
- --  | DEPENDENCY_CLAUSE {, DEPENDENCY_CLAUSE}
+ -- null
+ --  | (DEPENDENCY_CLAUSE {, DEPENDENCY_CLAUSE})
 
  --  DEPENDENCY_CLAUSE ::=
  --OUTPUT_LIST =>[+] INPUT_LIST
@@ -14945,9 +14945,9 @@
  --  pragma Global (GLOBAL_SPECIFICATION);
 
  --  GLOBAL_SPECIFICATION ::=
- --null
- --  | GLOBAL_LIST
- --  | MODED_GLOBAL_LIST {, MODED_GLOBAL_LIST}
+ -- null
+ --  | (GLOBAL_LIST)
+ --  | (MODED_GLOBAL_LIST {, MODED_GLOBAL_LIST})
 
  --  MODED_GLOBAL_LIST ::= MODE_SELECTOR => GLOBAL_LIST
 
@@ -15689,20 +15689,18 @@
  -- Initializes --
  -
 
- --  pragma Initializes (INITIALIZATION_SPEC);
+ --  pragma Initializes (INITIALIZATION_LIST);
 
- --  INITIALIZATION_SPEC ::= null | INITIALIZATION_LIST
-
  --  INITIALIZATION_LIST ::=
- --INITIALIZATION_ITEM
- --| (INITIALIZATION_ITEM {, INITIALIZATION_ITEM})
+ -- null
+ --  | (INITIALIZATION_ITEM {, INITIALIZATION_ITEM})
 
  --  INITIALIZATION_ITEM ::= name [=> INPUT_LIST]
 
  --  INPUT_LIST ::=
- --null
- --| INPUT
- --| (INPUT {, INPUT})
+ -- null
+ --  |  INPUT
+ --  | (INPUT {, INPUT})
 
  --  INPUT ::= name
 
@@ -19287,8 +19285,8 @@
  --  pragma Refined_Depends (DEPENDENCY_RELATION);
 
  --  DEPENDENCY_RELATION ::=
- --null
- --  | DEPENDENCY_CLAUSE {, DEPENDENCY_CLAUSE}
+ -- null
+ --  | (DEPENDENCY_CLAUSE {, DEPENDENCY_CLAUSE})
 
  --  DEPENDENCY_CLAUSE ::=
  --OUTPUT_LIST =>[+] INPUT_LIST
@@ -19363,9 +19361,9 @@
  --  pragma Refined_Global (GLOBAL_SPECIFICATION);
 
  --  GLOBAL_SPECIFICATION ::=
- --null
- --  | GLOBAL_LIST
- --  | MODED_GLOBAL_LIST {, MODED_GLOBAL_LIST}
+ -- null
+ --  | (GLOBAL_LIST)
+ --  | (MODED_GLOBAL_LIST {, MODED_GLOBAL_LIST})
 
  --  MODED_GLOBAL_LIST ::= MODE_SELECTOR => GLOBAL_LIST
 
@@ -19488,15 +19486,14 @@
  --  pragma Refined_State (REFINEMENT_LIST);
 
  --  REFINEMENT_LIST ::=
- --REFINEMENT_CLAUSE
- --| (REFINEMENT_CLAUSE {, REFINEMENT_CLAUSE})
+ --(REFINEMENT_CLAUSE {, REFINEMENT_CLAUSE})
 
  --  REFINEMENT_CLAUSE ::= state_NAME => CONSTITUENT_LIST
 
  --  CONSTITUENT_LIST ::=
- --null
- --| CONSTITUENT
- --| (CONSTITUENT {, CONSTITUENT})
+ -- null
+ --  |  CONSTITUENT
+ --  | (CONSTITUENT {, CONSTITUENT})
 
  --  CONSTITUENT ::= object_NAME | state_NAME
 


[PATCH] Fix debug fallout of proposed PR68162 fix

2015-11-18 Thread Richard Biener

The following patch makes sure we still emit a DW_TAG_typedef for
the element typedef in gcc.dg/debug/dwarf2/pr47939-4.c after a change
to how the C frontend structures the variant chain of arrays.

It makes dwarf2out _not_ re-build the variant for arrays (like it
does for vectors).

Patch was tested by Joseph (also on gdb testsuite?) and I'm currently
re-testing on x86_64-unknown-linux-gnu.

Ok for trunk and GCC 5 branch?

Thanks,
Richard.

2015-11-18  Richard Biener  

PR c/68162
* dwarf2out.c (gen_type_die_with_usage): Keep variant types
of arrays.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 230428)
+++ gcc/dwarf2out.c (working copy)
@@ -20784,9 +20784,10 @@ gen_type_die_with_usage (tree type, dw_d
   /* We are going to output a DIE to represent the unqualified version
  of this type (i.e. without any const or volatile qualifiers) so
  get the main variant (i.e. the unqualified version) of this type
- now.  (Vectors are special because the debugging info is in the
+ now.  (Vectors and arrays are special because the debugging info is in the
  cloned type itself).  */
-  if (TREE_CODE (type) != VECTOR_TYPE)
+  if (TREE_CODE (type) != VECTOR_TYPE
+  && TREE_CODE (type) != ARRAY_TYPE)
 type = type_main_variant (type);
 
   /* If this is an array type with hidden descriptor, handle it first.  */


[patch] Fix PR middle-end/65958

2015-11-18 Thread Eric Botcazou
Hi,

this is the underlying issue of PR middle-end/65958: the compiler generates 
wrong code when alloca is used in conjunction with a VLA since the latter 
causes the stack space allocated to the former to be wrongly reclaimed.
So the proposed fix is not to reclaim any stack space in this case.

Bootstrapped/regtested on x86_64-suse-linux, OK for mainline and 5.x branch?


2015-11-18  Eric Botcazou  

PR middle-end/65958
* gimplify.c (struct gimplify_ctx): Turn boolean fields into 1-bit
fields, add keep_stack and reorder them.
(gimplify_bind_expr): Save gimplify_ctxp->keep_stack on entry then
set it to false.  Do not insert a stack save/restore pair if it has
been set to true by the gimplification of the statements.
Restore it to the saved value on exit if it is still false.
(gimplify_vla_decl): Do not set gimplify_ctxp->save_stack here.
(gimplify_call_expr) : New case.  Set
either save_stack or keep_stack depending on CALL_ALLOCA_FOR_VAR_P.


2015-11-18  Eric Botcazou  

* gcc.dg/vla-24.c: New test.

-- 
Eric Botcazou/* PR middle-end/65958 */

/* { dg-do run } */
/* { dg-options "-std=gnu99" } */

extern void abort (void);

int foo (int n)
{
  char *p, *q;

  if (1)
{
  char i[n];
  p = __builtin_alloca (8);
  p[0] = 1;
}

  q = __builtin_alloca (64);
  __builtin_memset (q, 0, 64);

  return !p[0];
}

int main (void)
{
  if (foo (48) != 0)
abort ();

  return 0;
}
Index: gimplify.c
===
--- gimplify.c	(revision 230453)
+++ gimplify.c	(working copy)
@@ -148,10 +148,11 @@ struct gimplify_ctx
   hash_table *temp_htab;
 
   int conditions;
-  bool save_stack;
-  bool into_ssa;
-  bool allow_rhs_cond_expr;
-  bool in_cleanup_point_expr;
+  unsigned into_ssa : 1;
+  unsigned allow_rhs_cond_expr : 1;
+  unsigned in_cleanup_point_expr : 1;
+  unsigned keep_stack : 1;
+  unsigned save_stack : 1;
 };
 
 struct gimplify_omp_ctx
@@ -1073,6 +1074,7 @@ static enum gimplify_status
 gimplify_bind_expr (tree *expr_p, gimple_seq *pre_p)
 {
   tree bind_expr = *expr_p;
+  bool old_keep_stack = gimplify_ctxp->keep_stack;
   bool old_save_stack = gimplify_ctxp->save_stack;
   tree t;
   gbind *bind_stmt;
@@ -1122,9 +1124,10 @@ gimplify_bind_expr (tree *expr_p, gimple
 }
 
   bind_stmt = gimple_build_bind (BIND_EXPR_VARS (bind_expr), NULL,
-   BIND_EXPR_BLOCK (bind_expr));
+ BIND_EXPR_BLOCK (bind_expr));
   gimple_push_bind_expr (bind_stmt);
 
+  gimplify_ctxp->keep_stack = false;
   gimplify_ctxp->save_stack = false;
 
   /* Gimplify the body into the GIMPLE_BIND tuple's body.  */
@@ -1147,7 +1150,10 @@ gimplify_bind_expr (tree *expr_p, gimple
 
   cleanup = NULL;
   stack_save = NULL;
-  if (gimplify_ctxp->save_stack)
+
+  /* If the code both contains VLAs and calls alloca, then we cannot reclaim
+ the stack space allocated to the VLAs.  */
+  if (gimplify_ctxp->save_stack && !gimplify_ctxp->keep_stack)
 {
   gcall *stack_restore;
 
@@ -1229,7 +1235,11 @@ gimplify_bind_expr (tree *expr_p, gimple
   gimple_bind_set_body (bind_stmt, new_body);
 }
 
+  /* keep_stack propagates all the way up to the outermost BIND_EXPR.  */
+  if (!gimplify_ctxp->keep_stack)
+gimplify_ctxp->keep_stack = old_keep_stack;
   gimplify_ctxp->save_stack = old_save_stack;
+
   gimple_pop_bind_expr ();
 
   gimplify_seq_add_stmt (pre_p, bind_stmt);
@@ -1386,10 +1396,6 @@ gimplify_vla_decl (tree decl, gimple_seq
   t = build2 (MODIFY_EXPR, TREE_TYPE (addr), addr, t);
 
   gimplify_and_add (t, seq_p);
-
-  /* Indicate that we need to restore the stack level when the
- enclosing BIND_EXPR is exited.  */
-  gimplify_ctxp->save_stack = true;
 }
 
 /* A helper function to be called via walk_tree.  Mark all labels under *TP
@@ -2370,6 +2376,18 @@ gimplify_call_expr (tree *expr_p, gimple
   && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
 switch (DECL_FUNCTION_CODE (fndecl))
   {
+  case BUILT_IN_ALLOCA:
+  case BUILT_IN_ALLOCA_WITH_ALIGN:
+	/* If the call has been built for a variable-sized object, then we
+	   want to restore the stack level when the enclosing BIND_EXPR is
+	   exited to reclaim the allocated space; otherwise, we precisely
+	   need to do the opposite and preserve the latest stack level.  */
+	if (CALL_ALLOCA_FOR_VAR_P (*expr_p))
+	  gimplify_ctxp->save_stack = true;
+	else
+	  gimplify_ctxp->keep_stack = true;
+	break;
+
   case BUILT_IN_VA_START:
 {
 	  builtin_va_start_p = TRUE;


[PATCH][4.9] Backport fix for PR sanitizer/64820.

2015-11-18 Thread Maxim Ostapenko

Hi,

this small patch fixes the logic in ASan vs SSP interaction to provide 
correct "size" parameter to asan_stack_malloc_[N] routines. With current 
logic, we would have assertion failure in libsanitizer in UAR mode on 
32-bit targets due to wrong granularity of resulting addr + size address.


Regtested via make check RUNTESTFLAGS="--target_board=unix'{-m32,-m64}' 
-j12 on x86_64-unknown-linux-gnu and bootstrapped on 
x86_64-unknown-linux-gnu.


Ok for gcc-4_9-branch?

-Maxim
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 4df00bf..f1f2744 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,14 @@
+2015-11-18  Max Ostapenko  
+
+	Backport from mainline.
+	2015-03-16  Max Ostapenko  
+
+	PR sanitizer/64820
+	* cfgexpand.c (align_base): New function.
+	(alloc_stack_frame_space): Call it.
+	(expand_stack_vars): Align prev_frame to be sure
+	data->asan_vec elements aligned properly.
+
 2015-11-12  Eric Botcazou  
 
 	PR target/67265
diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 14511e1..8bebd85 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -248,6 +248,15 @@ align_local_variable (tree decl)
   return align / BITS_PER_UNIT;
 }
 
+/* Align given offset BASE with ALIGN.  Truncate up if ALIGN_UP is true,
+   down otherwise.  Return truncated BASE value.  */
+
+static inline unsigned HOST_WIDE_INT
+align_base (HOST_WIDE_INT base, unsigned HOST_WIDE_INT align, bool align_up)
+{
+  return align_up ? (base + align - 1) & -align : base & -align;
+}
+
 /* Allocate SIZE bytes at byte alignment ALIGN from the stack frame.
Return the frame offset.  */
 
@@ -256,20 +265,17 @@ alloc_stack_frame_space (HOST_WIDE_INT size, unsigned HOST_WIDE_INT align)
 {
   HOST_WIDE_INT offset, new_frame_offset;
 
-  new_frame_offset = frame_offset;
   if (FRAME_GROWS_DOWNWARD)
 {
-  new_frame_offset -= size + frame_phase;
-  new_frame_offset &= -align;
-  new_frame_offset += frame_phase;
+  new_frame_offset
+	= align_base (frame_offset - frame_phase - size,
+		  align, false) + frame_phase;
   offset = new_frame_offset;
 }
   else
 {
-  new_frame_offset -= frame_phase;
-  new_frame_offset += align - 1;
-  new_frame_offset &= -align;
-  new_frame_offset += frame_phase;
+  new_frame_offset
+	= align_base (frame_offset - frame_phase, align, true) + frame_phase;
   offset = new_frame_offset;
   new_frame_offset += size;
 }
@@ -983,13 +989,16 @@ expand_stack_vars (bool (*pred) (size_t), struct stack_vars_data *data)
 	  base = virtual_stack_vars_rtx;
 	  if ((flag_sanitize & SANITIZE_ADDRESS) && ASAN_STACK && pred)
 	{
-	  HOST_WIDE_INT prev_offset = frame_offset;
+	  HOST_WIDE_INT prev_offset
+		= align_base (frame_offset,
+			  MAX (alignb, ASAN_RED_ZONE_SIZE),
+			  FRAME_GROWS_DOWNWARD);
 	  tree repr_decl = NULL_TREE;
-
 	  offset
 		= alloc_stack_frame_space (stack_vars[i].size
 	   + ASAN_RED_ZONE_SIZE,
 	   MAX (alignb, ASAN_RED_ZONE_SIZE));
+
 	  data->asan_vec.safe_push (prev_offset);
 	  data->asan_vec.safe_push (offset + stack_vars[i].size);
 	  /* Find best representative of the partition.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 0072132..3d565ec 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,11 @@
+2015-11-18  Max Ostapenko  
+
+	Backport from mainline.
+	2015-03-16  Max Ostapenko  
+
+	PR sanitizer/64820
+	* c-c++-common/asan/pr64820.c: New test.
+
 2015-11-12  Eric Botcazou  
 
 	* gcc.target/i386/pr67265-2.c: New test.
diff --git a/gcc/testsuite/c-c++-common/asan/pr64820.c b/gcc/testsuite/c-c++-common/asan/pr64820.c
new file mode 100644
index 000..885a662
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/asan/pr64820.c
@@ -0,0 +1,31 @@
+/* { dg-do run } */
+/* { dg-require-effective-target fstack_protector } */
+/* { dg-options "-fstack-protector-strong" } */
+/* { dg-set-target-env-var ASAN_OPTIONS "detect_stack_use_after_return=1" } */
+/* { dg-shouldfail "asan" } */
+
+__attribute__((noinline))
+char *Ident(char *x) {
+  return x;
+}
+
+__attribute__((noinline))
+char *Func1() {
+  char local[1 << 12];
+  return Ident(local);
+}
+
+__attribute__((noinline))
+void Func2(char *x) {
+  *x = 1;
+}
+int main(int argc, char **argv) {
+  Func2(Func1());
+  return 0;
+}
+
+/* { dg-output "AddressSanitizer: stack-use-after-return on address 0x\[0-9a-f\]+\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "WRITE of size 1 at .* thread T0.*" } */
+/* { dg-output "#0.*(Func2)?.*pr64820.(c:21)?.*" } */
+/* { dg-output "is located in stack of thread T0 at offset.*" } */
+/* { dg-output "\'local\' <== Memory access at offset 32 is inside this variable" } */


[Ada] Missing error on volatile return type of non-volatile function

2015-11-18 Thread Arnaud Charlet
This patch modifies the predicate which determines whether a function is
volatile to correctly recognize a protected function.


-- Source --


--  vol_func.ads

package Vol_Func with SPARK_Mode is
   protected type Prot is
   end Prot;

   type Vol_Typ is null record with Volatile;

   function F (X : Prot) return Vol_Typ;
   function Greturn Vol_Typ;
end Vol_Func;


-- Compilation and output --


$ gcc -c vol_func.ads
vol_func.ads:7:16: nonvolatile function "F" cannot have a volatile parameter
vol_func.ads:7:33: nonvolatile function "F" cannot have a volatile return type
vol_func.ads:8:33: nonvolatile function "G" cannot have a volatile return type

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

2015-11-18  Hristian Kirtchev  

* sem_util.adb (Check_Nonvolatile_Function_Profile): Place the error
message concerning the return type on the result definition.
(Is_Volatile_Function): A function with a parameter of a protected
type is a protected function if it is defined within a protected
definition.

Index: sem_util.adb
===
--- sem_util.adb(revision 230521)
+++ sem_util.adb(working copy)
@@ -3120,9 +3120,9 @@
   --  Inspect the return type
 
   if Is_Effectively_Volatile (Etype (Func_Id)) then
- Error_Msg_N
+ Error_Msg_NE
("nonvolatile function & cannot have a volatile return type",
-Func_Id);
+Result_Definition (Parent (Func_Id)), Func_Id);
   end if;
end Check_Nonvolatile_Function_Profile;
 
@@ -14010,6 +14010,7 @@
   if Is_Primitive (Func_Id)
 and then Present (First_Formal (Func_Id))
 and then Is_Protected_Type (Etype (First_Formal (Func_Id)))
+and then Etype (First_Formal (Func_Id)) = Scope (Func_Id)
   then
  return True;
 


Re: [PATCH] Fix reassoci ICE (PR tree-optimization/68157)

2015-11-18 Thread Richard Biener
On Wed, 18 Nov 2015, Jakub Jelinek wrote:

> Hi!
> 
> attempt_builtin_powi and its caller does not set uids of the stmts it adds,
> which in some cases may lead to reassoc ICEs.
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk/5.3?

Ok.

Thanks,
Richard.

> 2015-11-18  Jakub Jelinek  
> 
>   PR tree-optimization/68157
>   * tree-ssa-reassoc.c (attempt_builtin_powi): Set uid of
>   pow_stmt or mul_stmt from stmt's uid.
>   (reassociate_bb): Set uid of mul_stmt from stmt's uid.
> 
>   * g++.dg/opt/pr68157.C: New test.
> 
> --- gcc/tree-ssa-reassoc.c.jj 2015-11-04 11:12:19.0 +0100
> +++ gcc/tree-ssa-reassoc.c2015-11-16 12:46:51.749495480 +0100
> @@ -4451,6 +4451,7 @@ attempt_builtin_powi (gimple *stmt, vec<
>  power));
> gimple_call_set_lhs (pow_stmt, iter_result);
> gimple_set_location (pow_stmt, gimple_location (stmt));
> +   gimple_set_uid (pow_stmt, gimple_uid (stmt));
> gsi_insert_before (, pow_stmt, GSI_SAME_STMT);
>  
> if (dump_file && (dump_flags & TDF_DETAILS))
> @@ -4534,6 +4535,7 @@ attempt_builtin_powi (gimple *stmt, vec<
> mul_stmt = gimple_build_assign (target_ssa, MULT_EXPR,
> op1, op2);
> gimple_set_location (mul_stmt, gimple_location (stmt));
> +   gimple_set_uid (mul_stmt, gimple_uid (stmt));
> gsi_insert_before (, mul_stmt, GSI_SAME_STMT);
> rf1->repr = target_ssa;
>  
> @@ -4551,6 +4553,7 @@ attempt_builtin_powi (gimple *stmt, vec<
>  power));
> gimple_call_set_lhs (pow_stmt, iter_result);
> gimple_set_location (pow_stmt, gimple_location (stmt));
> +   gimple_set_uid (pow_stmt, gimple_uid (stmt));
> gsi_insert_before (, pow_stmt, GSI_SAME_STMT);
>   }
>  
> @@ -4562,6 +4565,7 @@ attempt_builtin_powi (gimple *stmt, vec<
> mul_stmt = gimple_build_assign (new_result, MULT_EXPR,
> result, iter_result);
> gimple_set_location (mul_stmt, gimple_location (stmt));
> +   gimple_set_uid (mul_stmt, gimple_uid (stmt));
> gsi_insert_before (, mul_stmt, GSI_SAME_STMT);
> gimple_set_visited (mul_stmt, true);
> result = new_result;
> @@ -4919,6 +4923,7 @@ reassociate_bb (basic_block bb)
> mul_stmt = gimple_build_assign (lhs, MULT_EXPR,
> powi_result, target_ssa);
> gimple_set_location (mul_stmt, gimple_location (stmt));
> +   gimple_set_uid (mul_stmt, gimple_uid (stmt));
> gsi_insert_after (, mul_stmt, GSI_NEW_STMT);
>   }
>   }
> --- gcc/testsuite/g++.dg/opt/pr68157.C.jj 2015-11-16 12:41:41.583871551 
> +0100
> +++ gcc/testsuite/g++.dg/opt/pr68157.C2015-11-16 12:54:30.613990591 
> +0100
> @@ -0,0 +1,18 @@
> +// PR tree-optimization/68157
> +// { dg-do compile }
> +// { dg-options "-Ofast" }
> +
> +double a, b, c, d;
> +int h, foo ();
> +
> +void
> +bar ()
> +{
> +  while (foo ())
> +{
> +  double e = b * a * a;
> +  double f = b * d;
> +  if (h)
> + c = e + f;
> +}
> +}
> 
>   Jakub
> 
> 

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


[Ada] State refinement predicates for GNATprove

2015-11-18 Thread Arnaud Charlet
This patch implements two predicates that allow for state revinement queries
while ignoring the region over which a state refinement is visible. No test
possible as this requires an external client of the compiler.

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

2015-11-18  Hristian Kirtchev  

* einfo.adb (Has_Non_Null_Refinement): Rename to
Has_Non_Null_Visible_Refinement.
(Has_Null_Refinement): Rename to Has_Null_Visible_Refinement.
* einfo.ads Update the documentation of
attribute Has_Non_Null_Refinement and attribute Has_Null_Refinement.
(Has_Non_Null_Refinement): Rename to Has_Non_Null_Visible_Refinement
and update occurrences in entities.
(Has_Null_Refinement): Rename to Has_Null_Visible_Refinement and update
occurrences in entities.
* sem_prag.adb (Check_In_Out_States): Update the calls to
Has_[Non_]Null_Refinement.
(Check_Input_States): Update the
calls to Has_[Non_]Null_Refinement.
(Check_Output_States): Update the calls to Has_[Non_]Null_Refinement.
(Check_Proof_In_States): Update the calls to Has_[Non_]Null_Refinement.
(Collect_Global_Item): Update the calls to Has_[Non_]Null_Refinement.
(Is_Null_Refined_State): Update the calls to Has_[Non_]Null_Refinement.
(Match_Item): Update the calls to Has_[Non_]Null_Refinement.
* sem_util.adb (Has_Non_Null_Refinement): New routine.
(Has_Null_Refinement): New routine.
* sem_util.ads (Has_Non_Null_Refinement): New routine.
(Has_Null_Refinement): New routine.

Index: einfo.adb
===
--- einfo.adb   (revision 230522)
+++ einfo.adb   (working copy)
@@ -7301,11 +7301,11 @@
 and then Present (Non_Limited_View (Id));
end Has_Non_Limited_View;
 
-   -
-   -- Has_Non_Null_Refinement --
-   -
+   -
+   -- Has_Non_Null_Visible_Refinement --
+   -
 
-   function Has_Non_Null_Refinement (Id : E) return B is
+   function Has_Non_Null_Visible_Refinement (Id : E) return B is
begin
   --  "Refinement" is a concept applicable only to abstract states
 
@@ -7322,7 +7322,7 @@
   end if;
 
   return False;
-   end Has_Non_Null_Refinement;
+   end Has_Non_Null_Visible_Refinement;
 
-
-- Has_Null_Abstract_State --
@@ -7337,11 +7337,11 @@
   and then Is_Null_State (Node (First_Elmt (Abstract_States (Id;
end Has_Null_Abstract_State;
 
-   -
-   -- Has_Null_Refinement --
-   -
+   -
+   -- Has_Null_Visible_Refinement --
+   -
 
-   function Has_Null_Refinement (Id : E) return B is
+   function Has_Null_Visible_Refinement (Id : E) return B is
begin
   --  "Refinement" is a concept applicable only to abstract states
 
@@ -7358,7 +7358,7 @@
   end if;
 
   return False;
-   end Has_Null_Refinement;
+   end Has_Null_Visible_Refinement;
 

-- Has_Unmodified --
Index: einfo.ads
===
--- einfo.ads   (revision 230522)
+++ einfo.ads   (working copy)
@@ -1761,9 +1761,10 @@
 --   E_Abstract_State entities. True if their Non_Limited_View attribute
 --   is present.
 
---Has_Non_Null_Refinement (synth)
---   Defined in E_Abstract_State entities. True if the state has at least
---   one variable or state constituent in aspect/pragma Refined_State.
+--Has_Non_Null_Visible_Refinement (synth)
+--   Defined in E_Abstract_State entities. True if the state has a visible
+--   refinement of at least one variable or state constituent as expressed
+--   in aspect/pragma Refined_State.
 
 --Has_Non_Standard_Rep (Flag75) [implementation base type only]
 --   Defined in all type entities. Set when some representation clause
@@ -1779,9 +1780,9 @@
 --   Defined in package entities. True if the package is subject to a null
 --   Abstract_State aspect/pragma.
 
---Has_Null_Refinement (synth)
---   Defined in E_Abstract_State entities. True if the state has a null
---   refinement in aspect/pragma Refined_State.
+--Has_Null_Visible_Refinement (synth)
+--   Defined in E_Abstract_State entities. True if the state has a visible
+--   null refinement as expressed in aspect/pragma Refined_State.
 
 --Has_Object_Size_Clause (Flag172)
 --   Defined in entities for types and subtypes. Set if an Object_Size
@@ -5525,8 +5526,8 @@
--From_Limited_With   (Flag159)
--Has_Visible_Refinement  (Flag263)
--Has_Non_Limited_View(synth)
-   --Has_Non_Null_Refinement (synth)
-   --

Re: [patch] Fix PR middle-end/65958

2015-11-18 Thread Eric Botcazou
> Looks good to me.  I also found the Arrays of Variable Length section
> in extend.texi which also refers to alloca as doing the same.  We may
> want to add a note there that you should not mix both and that only
> VLAs (when not mixed with alloca) are freed at scope boundary.

It's already there and in fact the current behavior is documented:

 There are other differences between these two methods.  Space allocated
with `alloca' exists until the containing _function_ returns.  The
space for a variable-length array is deallocated as soon as the array
name's scope ends.  (If you use both variable-length arrays and
`alloca' in the same function, deallocation of a variable-length array
also deallocates anything more recently allocated with `alloca'.)

so we need to amend the documentation if we go for the patch.

-- 
Eric Botcazou


[PTX] OpenACC complex double reductions

2015-11-18 Thread Nathan Sidwell

Here's the version of the complex double reduction patch I've committed to 
trunk.

There's no atomic cmp larger than 64 bits, so we have to do something else. 
 I  started with a patch to synthesize such an operation using a global lock, 
and fitted it into the current scheme.  But that (a) ended  up looking 
complicated and (b) had a lock.  As we have to use a lock, one might as well go 
for a mutex scheme.


The lock variable has to be in global memory, even if it's  protecting .shared 
state.  Locking in .shared memory can introduce resource starvation as there's 
then no descheduling of the thread attempting to get the lock.   Nvidia have 
confirmed that global locks do not suffer this problem.


nathan
2015-11-18  Nathan Sidwell  

	gcc/
	* config/nvptx/nvptx.c (global_lock_var): New.
	(nvptx_global_lock_addr): New.
	(nvptx_lockless_update): Recomment and adjust for clarity.
	(nvptx_lockfull_update): New.
	(nvptx_reduction_update): New.
	(nvptx_goacc_reduction_fini): Call it.

	libgcc/
	* config/nvptx/reduction.c: New.
	* config/nvptx/t-nvptx (LIB2ADD): Add it.

	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/reduction-cplx-flt.c: Add
	worker & gang cases.
	* testsuite/libgomp.oacc-c-c++-common/reduction-cplx-dbl.c: Likewise.

Index: gcc/config/nvptx/nvptx.c
===
--- gcc/config/nvptx/nvptx.c	(revision 230544)
+++ gcc/config/nvptx/nvptx.c	(working copy)
@@ -114,6 +114,9 @@ static unsigned worker_red_align;
 #define worker_red_name "__worker_red"
 static GTY(()) rtx worker_red_sym;
 
+/* Global lock variable, needed for 128bit worker & gang reductions.  */
+static GTY(()) tree global_lock_var;
+
 /* Allocate a new, cleared machine_function structure.  */
 
 static struct machine_function *
@@ -3681,8 +3684,45 @@ nvptx_generate_vector_shuffle (location_
   gimplify_assign (dest_var, expr, seq);
 }
 
-/* Insert code to locklessly update  *PTR with *PTR OP VAR just before
-   GSI.  */
+/* Lazily generate the global lock var decl and return its address.  */
+
+static tree
+nvptx_global_lock_addr ()
+{
+  tree v = global_lock_var;
+  
+  if (!v)
+{
+  tree name = get_identifier ("__reduction_lock");
+  tree type = build_qualified_type (unsigned_type_node,
+	TYPE_QUAL_VOLATILE);
+  v = build_decl (BUILTINS_LOCATION, VAR_DECL, name, type);
+  global_lock_var = v;
+  DECL_ARTIFICIAL (v) = 1;
+  DECL_EXTERNAL (v) = 1;
+  TREE_STATIC (v) = 1;
+  TREE_PUBLIC (v) = 1;
+  TREE_USED (v) = 1;
+  mark_addressable (v);
+  mark_decl_referenced (v);
+}
+
+  return build_fold_addr_expr (v);
+}
+
+/* Insert code to locklessly update *PTR with *PTR OP VAR just before
+   GSI.  We use a lockless scheme for nearly all case, which looks
+   like:
+ actual = initval(OP);
+ do {
+   guess = actual;
+   write = guess OP myval;
+   actual = cmp (ptr, guess, write)
+ } while (actual bit-different-to guess);
+   return write;
+
+   This relies on a cmp instruction, which is available for 32-
+   and 64-bit types.  Larger types must use a locking scheme.  */
 
 static tree
 nvptx_lockless_update (location_t loc, gimple_stmt_iterator *gsi,
@@ -3690,46 +3730,30 @@ nvptx_lockless_update (location_t loc, g
 {
   unsigned fn = NVPTX_BUILTIN_CMP_SWAP;
   tree_code code = NOP_EXPR;
-  tree type = unsigned_type_node;
-
-  enum machine_mode mode = TYPE_MODE (TREE_TYPE (var));
+  tree arg_type = unsigned_type_node;
+  tree var_type = TREE_TYPE (var);
 
-  if (!INTEGRAL_MODE_P (mode))
+  if (TREE_CODE (var_type) == COMPLEX_TYPE
+  || TREE_CODE (var_type) == REAL_TYPE)
 code = VIEW_CONVERT_EXPR;
-  if (GET_MODE_SIZE (mode) == GET_MODE_SIZE (DImode))
+
+  if (TYPE_SIZE (var_type) == TYPE_SIZE (long_long_unsigned_type_node))
 {
+  arg_type = long_long_unsigned_type_node;
   fn = NVPTX_BUILTIN_CMP_SWAPLL;
-  type = long_long_unsigned_type_node;
 }
 
+  tree swap_fn = nvptx_builtin_decl (fn, true);
+
   gimple_seq init_seq = NULL;
-  tree init_var = make_ssa_name (type);
-  tree init_expr = omp_reduction_init_op (loc, op, TREE_TYPE (var));
-  init_expr = fold_build1 (code, type, init_expr);
+  tree init_var = make_ssa_name (arg_type);
+  tree init_expr = omp_reduction_init_op (loc, op, var_type);
+  init_expr = fold_build1 (code, arg_type, init_expr);
   gimplify_assign (init_var, init_expr, _seq);
   gimple *init_end = gimple_seq_last (init_seq);
 
   gsi_insert_seq_before (gsi, init_seq, GSI_SAME_STMT);
   
-  gimple_seq loop_seq = NULL;
-  tree expect_var = make_ssa_name (type);
-  tree actual_var = make_ssa_name (type);
-  tree write_var = make_ssa_name (type);
-  
-  tree write_expr = fold_build1 (code, TREE_TYPE (var), expect_var);
-  write_expr = fold_build2 (op, TREE_TYPE (var), write_expr, var);
-  write_expr = fold_build1 (code, type, write_expr);
-  gimplify_assign (write_var, write_expr, _seq);
-
-  tree swap_expr = nvptx_builtin_decl (fn, 

Re: [PATCH, PR tree-optimization/68327] Compute vectype for live phi nodes when copmputing VF

2015-11-18 Thread Ilya Enkovich
2015-11-18 16:44 GMT+03:00 Richard Biener :
> On Wed, Nov 18, 2015 at 12:34 PM, Ilya Enkovich  
> wrote:
>> Hi,
>>
>> When we compute vectypes we skip non-relevant phi nodes.  But we process 
>> non-relevant alive statements and thus may need vectype of non-relevant live 
>> phi node to compute mask vectype.  This patch enables vectype computation 
>> for live phi nodes.  Botostrapped and regtested on x86_64-unknown-linux-gnu. 
>>  OK for trunk?
>
> Hmm.  What breaks if you instead skip all !relevant stmts and not
> compute vectype for life but not relevant ones?  We won't ever
> "vectorize" !relevant ones, that is, we don't need their vector type.

I tried it and got regression in SLP.  It expected non-null vectype
for non-releveant but live statement. Regression was in
gcc/gcc/testsuite/gfortran.fortran-torture/execute/pr43390.f90

Ilya

>
> Richard.
>
>> Thanks,
>> Ilya


[PATCH] Add clang-format config to contrib folder

2015-11-18 Thread Martin Liška
Hello.

Following patch adds a clang-format config file that should respect the GNU 
coding standards.
As the file is not part of build process, I hope the patch can be applied even 
though
we've just skipped to stage3? The patch adds a hunk to Makefile which can 
create symlink
to the root directory of the GCC compiler. The clang-format automatically loads 
style from
the configuration file. 

clang-format (version 3.8) provides rich variety of configuration options that 
can
ensure the GNU coding style.

Limitations:
+ placement of opening brace of an initializer can't be requested
+ sometimes, '(' is the trailing symbol at the end of a line, which can look 
weird

As we've been continuously converting our source base to C++, the clang-format 
should
provide better results than a collection of regular expressions 
(check_GNU_style.sh).

As a reference file I attach gcc/tree-ssa-uninit.c file.
Feel free to comment the suggested configuration file.

Thanks,
Martin

From 5f5eab4f9bbe76ec4d91f80dd3fb6909abd39695 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Wed, 18 Nov 2015 14:40:58 +0100
Subject: [PATCH] Add clang-format config to contrib folder

ChangeLog:

2015-11-18  Martin Liska  

	* Makefile.in: Add clang-format.
	* Makefile.tpl: Likewise.

contrib/ChangeLog:

2015-11-18  Martin Liska  

	* clang-format: New file.
---
 Makefile.in  |  9 +
 Makefile.tpl |  9 +
 contrib/clang-format | 51 +++
 3 files changed, 69 insertions(+)
 create mode 100644 contrib/clang-format

diff --git a/Makefile.in b/Makefile.in
index bc2bae6..75caafd 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -2461,6 +2461,15 @@ vimrc: $(srcdir)/.local.vimrc $(srcdir)/.lvimrc
 
 .PHONY: vimrc
 
+# clang-format config
+
+$(srcdir)/.clang-format:
+	$(LN_S) contrib/clang-format $@
+
+clang-format: $(srcdir)/.clang-format
+
+.PHONY: clang-format
+
 # Installation targets.
 
 .PHONY: install uninstall
diff --git a/Makefile.tpl b/Makefile.tpl
index 660e1e4..beabadc 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -889,6 +889,15 @@ vimrc: $(srcdir)/.local.vimrc $(srcdir)/.lvimrc
 
 .PHONY: vimrc
 
+# clang-format config
+
+$(srcdir)/.clang-format:
+	$(LN_S) contrib/clang-format $@
+
+clang-format: $(srcdir)/.clang-format
+
+.PHONY: clang-format
+
 # Installation targets.
 
 .PHONY: install uninstall
diff --git a/contrib/clang-format b/contrib/clang-format
new file mode 100644
index 000..2d358ec
--- /dev/null
+++ b/contrib/clang-format
@@ -0,0 +1,51 @@
+# Copyright (C) 2015 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program 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 this program.  If not, see .
+
+# clang-format 3.8+ is required
+
+---
+Language: Cpp
+AccessModifierOffset: -2
+AlwaysBreakAfterDefinitionReturnType: All
+BinPackArguments: true
+BinPackParameters: true
+BraceWrapping:
+  AfterClass: true
+  AfterControlStatement: true
+  AfterEnum: true
+  AfterFunction: true
+  AfterNamespace: false
+  AfterObjCDeclaration: true
+  AfterStruct: true
+  AfterUnion: true
+  BeforeCatch: true
+  BeforeElse: true
+  IndentBraces: true
+BreakBeforeBinaryOperators: All
+BreakBeforeBraces: Custom
+BreakBeforeTernaryOperators: true
+ColumnLimit: 80
+ConstructorInitializerIndentWidth: 2
+ContinuationIndentWidth: 2
+ForEachMacros: 

Re: [PATCH, VECTOR ABI] Add __attribute__((__simd__)) to GCC.

2015-11-18 Thread Kirill Yukhin
Hello Andreas, Devid.

On 18 Nov 10:45, Andreas Schwab wrote:
> Kirill Yukhin  writes:
> 
> > diff --git a/gcc/testsuite/c-c++-common/attr-simd.c 
> > b/gcc/testsuite/c-c++-common/attr-simd.c
> > new file mode 100644
> > index 000..b4eda34
> > --- /dev/null
> > +++ b/gcc/testsuite/c-c++-common/attr-simd.c
> > @@ -0,0 +1,32 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-fdump-tree-optimized" } */
> > +
> > +__attribute__((__simd__))
> > +extern
> > +int simd_attr (void)
> > +{
> > +  return 0;
> > +}
> > +
> > +/* { dg-final { scan-tree-dump "simd_attr\[ \\t\]simdclone|vector" 
> > "optimized" } } */
> 
> On ia64:
> 
> FAIL: c-c++-common/attr-simd.c  -Wc++-compat   scan-tree-dump optimized 
> "simd_attr[ \\t]simdclone|vector"
> FAIL: c-c++-common/attr-simd.c  -Wc++-compat   scan-tree-dump optimized 
> "simd_attr2[ \\t]simdclone|vector"
> 
> $ grep simd_attr attr-simd.c.194t.optimized 
> ;; Function simd_attr (simd_attr, funcdef_no=0, decl_uid=1389, cgraph_uid=0, 
> symbol_order=0)
> simd_attr ()
> ;; Function simd_attr2 (simd_attr2, funcdef_no=1, decl_uid=1392, 
> cgraph_uid=1, symbol_order=1)
> simd_attr2 ()
As far as vABI is supported on x86_64/i?86 only, I am going to enable mentioned 
`scan-tree-dump' only
for these targets. This should cure both IA64 and Power.

Concerning attr-simd-3.c. It is known issue: PR68158.
And I believe this test should work everywhere as far as PR is resolved.
I'll put xfail into the test.
Which will lead to (in g++.log):
gcc/testsuite/c-c++-common/attr-simd-3.c:5:48: warning: '__simd__' attribute 
does not apply to types\
 [-Wattributes]^M
output is:
gcc/testsuite/c-c++-common/attr-simd-3.c:5:48: warning: '__simd__' attribute 
does not apply to types\
 [-Wattributes]^M

XFAIL: c-c++-common/attr-simd-3.c  -std=gnu++98 PR68158 (test for errors, line 
5)
FAIL: c-c++-common/attr-simd-3.c  -std=gnu++98 (test for excess errors)
Excess errors:
gcc/testsuite/c-c++-common/attr-simd-3.c:5:48: warning: '__simd__' attribute 
does not apply to types\
 [-Wattributes]

Patch in the bottom.

gcc/tessuite/
* c-c++-common/attr-simd-3.c: Put xfail (PR68158) on dg-error.
* c-c++-common/attr-simd.c: Limit scan of dump to x86_64/i?86.

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

diff --git a/gcc/testsuite/c-c++-common/attr-simd-3.c 
b/gcc/testsuite/c-c++-common/attr-simd-3.c
index 2bbdf04..35dd4c0 100644
--- a/gcc/testsuite/c-c++-common/attr-simd-3.c
+++ b/gcc/testsuite/c-c++-common/attr-simd-3.c
@@ -2,4 +2,4 @@
 /* { dg-options "-fcilkplus" } */
 /* { dg-prune-output "undeclared here \\(not in a function\\)|\[^\n\r\]* was 
not declared in this scope" } */

-void f () __attribute__((__simd__, __vector__)); /* { dg-error "in the same 
function marked as a Cilk Plus" } */
+void f () __attribute__((__simd__, __vector__)); /* { dg-error "in the same 
function marked as a Cilk Plus" "PR68158" { xfail c++ } } */
diff --git a/gcc/testsuite/c-c++-common/attr-simd.c 
b/gcc/testsuite/c-c++-common/attr-simd.c
index 61974e3..7674588 100644
--- a/gcc/testsuite/c-c++-common/attr-simd.c
+++ b/gcc/testsuite/c-c++-common/attr-simd.c
@@ -11,7 +11,7 @@ int simd_attr (void)
   return 0;
 }

-/* { dg-final { scan-tree-dump "simd_attr\[ \\t\]simdclone|vector" "optimized" 
} } */
+/* { dg-final { scan-tree-dump "simd_attr\[ \\t\]simdclone|vector" "optimized" 
{ target { i?86-*-* x86_64-*-* } } } } */
 /* { dg-final { scan-assembler-times "_ZGVbN4_simd_attr:" 1 { target { 
i?86-*-* x86_64-*-* } } } } */
 /* { dg-final { scan-assembler-times "_ZGVbM4_simd_attr:" 1 { target { 
i?86-*-* x86_64-*-* } } } } */
 /* { dg-final { scan-assembler-times "_ZGVcN4_simd_attr:" 1 { target { 
i?86-*-* x86_64-*-* } } } } */
@@ -29,7 +29,7 @@ int simd_attr2 (void)
   return 0;
 }

-/* { dg-final { scan-tree-dump "simd_attr2\[ \\t\]simdclone|vector" 
"optimized" } } */
+/* { dg-final { scan-tree-dump "simd_attr2\[ \\t\]simdclone|vector" 
"optimized" { target { i?86-*-* x86_64-*-* } } } } */
 /* { dg-final { scan-assembler-times "_ZGVbN4_simd_attr2:" 1 { target { 
i?86-*-* x86_64-*-* } } } } */
 /* { dg-final { scan-assembler-times "_ZGVbM4_simd_attr2:" 1 { target { 
i?86-*-* x86_64-*-* } } } } */
 /* { dg-final { scan-assembler-times "_ZGVcN4_simd_attr2:" 1 { target { 
i?86-*-* x86_64-*-* } } } } */


RE: [Patch,testsuite]: Fix the tree-ssa/split-path-1.c testcase

2015-11-18 Thread Ajit Kumar Agarwal

Hello Jeff:

Please ignore my previous mails as they bounced back. Sorry for that.

I have fixed the problem with the testcase. The splitting path optimization 
remains intact.
Attached is the patch.

The problem was related to the testcase as the loop bound goes beyond the 
malloced array.
There was also a problem with accessing the elements of EritePtr.

ChangeLog:
2015-11-18  Ajit Agarwal  

    * gcc.dg/tree-ssa/split-path-1.c: Fix the testcase.

Signed-off-by:Ajit Agarwal ajit...@xilinx.com

Thanks & Regards
Ajit


testcase.patch
Description: testcase.patch


RE: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation

2015-11-18 Thread Ajit Kumar Agarwal


-Original Message-
From: Tom de Vries [mailto:tom_devr...@mentor.com] 
Sent: Wednesday, November 18, 2015 1:14 PM
To: Jeff Law; Richard Biener
Cc: Ajit Kumar Agarwal; GCC Patches; Vinod Kathail; Shail Aditya Gupta; 
Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa 
representation

On 14/11/15 00:35, Jeff Law wrote:
> Anyway, bootstrapped and regression tested on x86_64-linux-gnu.
> Installed on the trunk.

>  [Patch,tree-optimization]: Add new path Splitting pass on tree ssa
>  representation
>
>   * Makefile.in (OBJS): Add gimple-ssa-split-paths.o
>   * common.opt (-fsplit-paths): New flag controlling path splitting.
>   * doc/invoke.texi (fsplit-paths): Document.
>   * opts.c (default_options_table): Add -fsplit-paths to -O2.
>   * passes.def: Add split_paths pass.
>   * timevar.def (TV_SPLIT_PATHS): New timevar.
>   * tracer.c: Include "tracer.h"
>   (ignore_bb_p): No longer static.
>   (transform_duplicate): New function, broken out of tail_duplicate.
>   (tail_duplicate): Use transform_duplicate.
>   * tracer.h (ignore_bb_p): Declare
>   (transform_duplicate): Likewise.
>   * tree-pass.h (make_pass_split_paths): Declare.
>   * gimple-ssa-split-paths.c: New file.
>
>   * gcc.dg/tree-ssa/split-path-1.c: New test.

>>I've filed PR68402 - FAIL: gcc.dg/tree-ssa/split-path-1.c execution test with 
>>-m32.

I have fixed the above PR and the patch is submitted.

https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02217.html

Thanks & Regards
Ajit

Thanks,
- Tom



PPC bootstrap failure builtin clz

2015-11-18 Thread David Edelsohn
Richard,

One of the patches in your recent series caused bootstrap failure on PPC:

In file included from /nasfarm/edelsohn/src/src/libgcc/libgcov-driver.c:49:0:
/nasfarm/edelsohn/src/src/libgcc/../gcc/gcov-io.c: In function 'gcov_do_dump':
/nasfarm/edelsohn/src/src/libgcc/../gcc/gcov-io.c:731:51: internal
compiler error: in convert_move, at expr.c:286
   r = sizeof (long long) * __CHAR_BIT__ - 1 - __builtin_clzll (v);


 ^~~~


David


[Ada] Crahs on indexing operation with named associations

2015-11-18 Thread Arnaud Charlet
This patch fixes a crash on a variable indexing operation appearing on the
left-hand side of an assignment, when the index expressions are given by
parameter associations.

The following must compile quietly:

   gcc -c -gnatct test_indexing.adb

---
with Ada.Text_IO; use Ada.Text_IO;
with Project; use Project;
with Matrix_3x3s; use Matrix_3x3s;
with Vector_3s;   use Vector_3s;
procedure Test_Indexing is
   V : Vector_3 := Create (X => 12.34,
   Y => 123.4,
   Z => 1234.0);
   M : Matrix_3x3 := (Create (X => V,
  Y => V * 2.0,
  Z => V * 4.0));
   Idx1 : Integer := 1;

   type Arr_Type is array (1 .. 10) of Integer;
   Arr : Arr_Type;
begin
   M (X => Idx1, Y=>1) := 20.0;
   M (Idx1, 2) := 20.0;
   M (1, 1) := 20.0;

   Arr (1) := 10;
end Test_Indexing;
---
with Project; use Project;
with Project.Real_Arrays; use Project.Real_Arrays;
with Vector_3s;   use Vector_3s;
package Matrix_3x3s is
   pragma Pure (Matrix_3x3s);
   subtype An_Axis is Integer range 1 .. 3;
   type Matrix_3x3 is tagged private
 with Constant_Indexing => Matrix_3x3s.Constant_Reference,
  Variable_Indexing => Matrix_3x3s.Variable_Reference;
   function Create (X, Y, Z : Vector_3) return Matrix_3x3;
   type Constant_Reference_Type (Value : not null access constant Real) is
 private with Implicit_Dereference => Value;
   function Constant_Reference (This : Matrix_3x3;
X, Y : An_Axis) return Constant_Reference_Type;
   type Reference_Type (Value : not null access Real) is
 private with Implicit_Dereference => Value;
   function Variable_Reference (This : Matrix_3x3;
X, Y : An_Axis) return Reference_Type;
private
   type Matrix_3x3 is tagged record
  M : Real_Matrix (An_Axis, An_Axis);
   end record;
   function Create (X, Y, Z : Vector_3) return Matrix_3x3 is
 (M => (1 => (X.Get_X, X.Get_Y, X.Get_Z),
2 => (Y.Get_X, Y.Get_Y, Y.Get_Z),
3 => (Z.Get_X, Z.Get_Y, Z.Get_Z)));
   type Constant_Reference_Type (Value : not null access constant Real) is
 null record;
   type Reference_Type (Value : not null access Real) is
 null record;
   function Constant_Reference (This : Matrix_3x3;
X, Y : An_Axis)
return Constant_Reference_Type is
  (Value => This.M (X, Y)'Unrestricted_Access);
   function Variable_Reference (This : Matrix_3x3;
X, Y : An_Axis)
return Reference_Type is
  (Value => This.M (X, Y)'Unrestricted_Access);
end Matrix_3x3s;
---
with Ada.Numerics.Long_Real_Arrays;
package Project.Real_Arrays
   renames Ada.Numerics.Long_Real_Arrays;
package Project is
   pragma Pure (Project);
   subtype Real is Long_Float;
   pragma Assert (Real'Size >= 64);
   subtype Non_Negative_Real is Real range 0.0 .. Real'Last;
   subtype Positive_Real is Real range Real'Succ (0.0) .. Real'Last;
end Project;
---
with Project; use Project;
with Project.Real_Arrays; use Project.Real_Arrays;
package Vector_3s is
   pragma Pure (Vector_3s);
   subtype An_Axis is Integer range 1 .. 3;
   type Vector_3 is tagged private
 with Constant_Indexing => Vector_3s.Constant_Reference,
  Variable_Indexing => Vector_3s.Variable_Reference;
   function Create (X, Y, Z : Real) return Vector_3;
   function Get_X (This : Vector_3) return Real;
   function Get_Y (This : Vector_3) return Real;
   function Get_Z (This : Vector_3) return Real;
   function "*" (Left : Vector_3;
 Right : Real'Base)
 return Vector_3;
   subtype Real_Vector_3 is Real_Vector (An_Axis);
   type Constant_Reference_Type (Value : not null access constant Real) is
 private with Implicit_Dereference => Value;
   function Constant_Reference (This : Vector_3;
Axis : An_Axis)
return Constant_Reference_Type;
   type Reference_Type (Value : not null access Real) is
 private with Implicit_Dereference => Value;
   function Variable_Reference (This : Vector_3;
Axis : An_Axis)
return Reference_Type;
private
   type Vector_3 is tagged record
  V : Real_Vector (An_Axis);
   end record;
   function Create (X, Y, Z : Real) return Vector_3 is
 (V => (1 => X, 2 => Y, 3 => Z));
   function Get_X (This : Vector_3) return Real is
 (This.V (1));
   function Get_Y (This : Vector_3) return Real is
 (This.V (2));
   function Get_Z (This : Vector_3) return Real is
 (This.V (3));
   function "*" (Left : Vector_3; Right : Real'Base) return Vector_3 is
 (V => Left.V * Right);
   type Constant_Reference_Type (Value : not null access constant Real) is
 null record;
   type Reference_Type (Value : not null access Real) is
 null record;
   

RFC/RFA: Fix bug with REE optimization corrupting extended registers

2015-11-18 Thread Nick Clifton
Hi Guys,

  I recently discovered a bug in the current Redundant Extension
  Elimination optimization.  If the candidate extension instruction
  increases the number of hard registers used, the pass does not check
  to see if these extra registers are live between the definition and
  the extension.

  For example:

(insn  44 (set (reg:QI r11) (mem:QI (reg:HI r20))) 
(insn  45 (set (reg:QI r10) (mem:QI (reg:HI r18))) 
[...]
(insn  71 (set (reg:HI r14) (zero_extend:HI (reg:QI r11)))
[...]  
(insn  88 (set (reg:HI r10) (zero_extend:HI (reg:QI r10)))

  (This is on the RL78 target where HImode values occupy two hard
  registers and QImode values only one.  The bug however is generic, not
  RL78 specific).
  
  The REE pass transforms this into:

(insn  44 (set (reg:QI r11) (mem:QI (reg:HI r20))) 
(insn  45 (set (reg:HI r10) (zero_extend:HI (mem:QI (reg:HI r18 
[...]
(insn  71 (set (reg:HI r14) (zero_extend:HI (reg:QI r11)))
[...]
(insn  88 deleted)

  Note how the new set at insn 45 clobbers the value loaded by insn 44
  into r11.

  The patch below is my attempt to fix this.  It is not correct
  however.  I could not work out how to determine if a given hard
  register is live at any point between two insns.  So instead I used
  the liveness information associated with the basic block containing
  the definition.  If one of the extended registers is live or becomes
  live in this block, and this block is not the same block as the one
  containing the extension insn, then I stop the optimization.  This
  works for the RL78 for all of the cases that I could find.

  So ... comments please ?

  Will gcc ever generate a single basic block that contains both the
  definition and the extension instructions, but also where the extra
  hard registers are used for another purpose as well ?

  Tested with no regressions (or fixes) on an x86-pc-linux-gnu target.
  Also tested with no regression and 7 fixes on an rl78-elf target.

Cheers
  Nick

gcc/ChangeLog
2015-11-18  Nick Clifton  

* ree.c (regs_live_between): New function.
(add_removable_extension): If the extension uses more hard
registers than the definition then check that the extra hard
registers are not live between the definition and the
extension.

Index: gcc/ree.c
===
--- gcc/ree.c   (revision 230517)
+++ gcc/ree.c   (working copy)
@@ -952,6 +952,49 @@
   return false;
 }
 
+/* Returns TRUE if any of the registers [start, stop) are live between DEF and 
up
+   to, but not including, INSN.  */
+
+static bool
+regs_live_between (rtx_insn * insn,
+  struct df_link * def,
+  unsigned int start,
+  unsigned int stop)
+{
+  basic_block bb;
+
+  /* FIXME: This is an incomplete test.  It only checks the DEF and USE states 
of the
+ registers in basic block of DEF.  If any of them match the start-stop 
range and
+ the INSN is not in the same block, then it is assumed that the registers 
must be
+ live.  */
+  /* These first few checks are just paranoia... */
+  if (def != NULL
+  && def->ref != NULL
+  && def->ref->base.insn_info != NULL
+  && def->ref->base.insn_info->insn != NULL
+  && (bb = BLOCK_FOR_INSN (def->ref->base.insn_info->insn)) != NULL
+  && bb != BLOCK_FOR_INSN (insn))
+{
+  struct df_lr_bb_info * bb_info = df_lr_get_bb_info (bb->index);
+  bitmap_iterator bi;
+  unsigned int reg;
+
+  EXECUTE_IF_SET_IN_BITMAP (& bb_info->def, 0, reg, bi)
+   {
+ if (reg >= start && reg < stop)
+   return true;
+   }
+
+  EXECUTE_IF_SET_IN_BITMAP (& bb_info->out, 0, reg, bi)
+   {
+ if (reg >= start && reg < stop)
+   return true;
+   }
+}
+
+  return false;
+}
+
 /* Add an extension pattern that could be eliminated.  */
 
 static void
@@ -1080,6 +1123,30 @@
  }
  }
 
+  /* Fourth, if the extended version occupies more registers than
+the original version then make sure that these extra registers
+are not live between the definition and the extension.  */
+  if (HARD_REGNO_NREGS (REGNO (dest), mode)
+ > HARD_REGNO_NREGS (REGNO (reg), GET_MODE (reg)))
+   {
+ unsigned int start_reg = REGNO (reg) + HARD_REGNO_NREGS (REGNO (reg), 
GET_MODE (reg));
+ unsigned int stop_reg  = REGNO (reg) + HARD_REGNO_NREGS (REGNO 
(dest), mode);
+
+ for (def = defs; def; def = def->next)
+   {
+ if (regs_live_between (insn, def, start_reg, stop_reg))
+   {
+ if (dump_file)
+   {
+ fprintf (dump_file, "Cannot eliminate extension:\n");
+ print_rtl_single (dump_file, insn);
+ fprintf (dump_file, " because extended 

Re: [PATCH] Fix memory leaks in tree-ssa-uninit.c

2015-11-18 Thread Martin Liška
On 11/13/2015 08:19 PM, Jeff Law wrote:
> On 11/13/2015 09:58 AM, Martin Liška wrote:
>> On 11/13/2015 05:32 PM, Jeff Law wrote:
>>> On 11/13/2015 05:50 AM, Martin Liška wrote:
 Hello.

 Patch survives regbootstrap on x86_64-linux-gnu.
 Ready for trunk?

 Thanks,
 Martin


 0001-Fix-memory-leaks-in-tree-ssa-uninit.c.patch


   From 54851503251dee7a8bd074485db262715e628728 Mon Sep 17 00:00:00 2001
 From: marxin
 Date: Fri, 13 Nov 2015 12:23:22 +0100
 Subject: [PATCH] Fix memory leaks in tree-ssa-uninit.c

 gcc/ChangeLog:

 2015-11-13  Martin Liska

  * tree-ssa-uninit.c (convert_control_dep_chain_into_preds):
  Fix GNU coding style.
  (find_def_preds): Use auto_vec.
  (destroy_predicate_vecs): Change signature of the function.
  (prune_uninit_phi_opnds_in_unrealizable_paths): Use the
  new signature.
  (simplify_preds_4): Use destroy_predicate_vecs instread of
  just releasing preds vector.
  (normalize_preds): Likewise.
  (is_use_properly_guarded): Use new signature of
  destroy_predicate_vecs.
  (find_uninit_use): Likewise.
>>> OK.
>>>
>>> FWIW, there's all kinds of spaces vs tabs issues in this file.  I'm curious 
>>> why you chose to fix convert_control_dep_chain_into_preds, but didn't 
>>> change any others.
>>
>> Hi Jeff.
>>
>> Thanks for confirmation, you are right, it's full of coding style issues. I 
>> can change these if it would be desired?
> It's probably a good thing to do.  Given it'd strictly be formatting, I'd 
> even consider it post-stage1.
> 
> jeff

Hello.

I'm sending the re-formatted source file.

The source file was formatted by clang-format ([1]) and some hunk were manually 
re-formatted.
No change in behavior.

Patch can regbootstrap on x86_64-linux-gnu.

Ready for trunk?
Thanks,
Martin

[1] https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02214.html
>From bef9e38d9c63868ee569b1c3da253b8baa523eb0 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Wed, 18 Nov 2015 10:20:11 +0100
Subject: [PATCH 1/2] Reformat tree-ssa-uninit.c

---
 gcc/tree-ssa-uninit.c | 1391 -
 1 file changed, 678 insertions(+), 713 deletions(-)

diff --git a/gcc/tree-ssa-uninit.c b/gcc/tree-ssa-uninit.c
index 0709cce..fcdb774 100644
--- a/gcc/tree-ssa-uninit.c
+++ b/gcc/tree-ssa-uninit.c
@@ -35,16 +35,15 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-cfg.h"
 
 /* This implements the pass that does predicate aware warning on uses of
-   possibly uninitialized variables. The pass first collects the set of
-   possibly uninitialized SSA names. For each such name, it walks through
-   all its immediate uses. For each immediate use, it rebuilds the condition
-   expression (the predicate) that guards the use. The predicate is then
+   possibly uninitialized variables.  The pass first collects the set of
+   possibly uninitialized SSA names.  For each such name, it walks through
+   all its immediate uses.  For each immediate use, it rebuilds the condition
+   expression (the predicate) that guards the use.  The predicate is then
examined to see if the variable is always defined under that same condition.
This is done either by pruning the unrealizable paths that lead to the
default definitions or by checking if the predicate set that guards the
defining paths is a superset of the use predicate.  */
 
-
 /* Pointer set of potentially undefined ssa names, i.e.,
ssa names that are defined by phi with operands that
are not defined or potentially undefined.  */
@@ -56,7 +55,7 @@ static hash_set *possibly_undefined_names = 0;
 #define MASK_EMPTY(mask) (mask == 0)
 
 /* Returns the first bit position (starting from LSB)
-   in mask that is non zero. Returns -1 if the mask is empty.  */
+   in mask that is non zero.  Returns -1 if the mask is empty.  */
 static int
 get_mask_first_set_bit (unsigned mask)
 {
@@ -75,18 +74,17 @@ get_mask_first_set_bit (unsigned mask)
 static bool
 has_undefined_value_p (tree t)
 {
-  return (ssa_undefined_value_p (t)
-  || (possibly_undefined_names
-  && possibly_undefined_names->contains (t)));
+  return ssa_undefined_value_p (t)
+	 || (possibly_undefined_names
+	 && possibly_undefined_names->contains (t));
 }
 
-
-
 /* Like has_undefined_value_p, but don't return true if TREE_NO_WARNING
is set on SSA_NAME_VAR.  */
 
 static inline bool
-uninit_undefined_value_p (tree t) {
+uninit_undefined_value_p (tree t)
+{
   if (!has_undefined_value_p (t))
 return false;
   if (SSA_NAME_VAR (t) && TREE_NO_WARNING (SSA_NAME_VAR (t)))
@@ -112,13 +110,13 @@ uninit_undefined_value_p (tree t) {
 /* Emit a warning for EXPR based on variable VAR at the point in the
program T, an SSA_NAME, is used being uninitialized.  The exact
warning text is in MSGID and DATA is 

Re: [PATCH] Add clang-format config to contrib folder

2015-11-18 Thread Markus Trippelsdorf
On 2015.11.18 at 15:37 +0100, Markus Trippelsdorf wrote:
> On 2015.11.18 at 15:10 +0100, Martin Liška wrote:
> > Hello.
> > 
> > Following patch adds a clang-format config file that should respect the GNU 
> > coding standards.
> > As the file is not part of build process, I hope the patch can be applied 
> > even though
> > we've just skipped to stage3? The patch adds a hunk to Makefile which can 
> > create symlink
> > to the root directory of the GCC compiler. The clang-format automatically 
> > loads style from
> > the configuration file. 
> > 
> > clang-format (version 3.8) provides rich variety of configuration options 
> > that can
> > ensure the GNU coding style.
> > 
> > Limitations:
> > + placement of opening brace of an initializer can't be requested
> > + sometimes, '(' is the trailing symbol at the end of a line, which can 
> > look weird
> > 
> > As we've been continuously converting our source base to C++, the 
> > clang-format should
> > provide better results than a collection of regular expressions 
> > (check_GNU_style.sh).
> > 
> > As a reference file I attach gcc/tree-ssa-uninit.c file.
> > Feel free to comment the suggested configuration file.
> 
> Thanks for doing this. It works fine except one problem: You should
> delete "SortIncludes: false" from the contrib/clang-format file, because
> it is the default for custom styles and doesn't work in .clang-format
> (it is a command line option instead):
> 
> markus@x4 gcc % clang-format -style=file gcc-main.c
> YAML:47:15: error: unknown key 'SortIncludes'

Ah, the option was added only yesterday to clang-format! 
My version wasn't new enough...

-- 
Markus


Re: [patch] Fix PR middle-end/65958

2015-11-18 Thread Richard Biener
On Wed, Nov 18, 2015 at 12:12 PM, Eric Botcazou  wrote:
>> Ok.  I wonder if we document GCCs VLA implementation somewhere so we can add
>> a note on the interaction with alloca.
>
> I found this in 10.7.2 Blocks:
>
> "Variable-length arrays (VLAs) complicate this process, as their size
> often refers to variables initialized earlier in the block.  To handle
> this, we currently split the block at that point, and move the VLA into
> a new, inner `BIND_EXPR'.  This strategy may change in the future."
>
> which sounds totally obsolete to me.  Proposed change:

Looks good to me.  I also found the Arrays of Variable Length section
in extend.texi which also refers to alloca as doing the same.  We may
want to add a note there that you should not mix both and that only
VLAs (when not mixed with alloca) are freed at scope boundary.

Richard.

> Index: doc/generic.texi
> ===
> --- doc/generic.texi(revision 230453)
> +++ doc/generic.texi(working copy)
> @@ -1950,11 +1950,15 @@ this initialization replaces the @code{D
>  will never require cleanups.  The scope of these variables is just the
>  body
>
> -Variable-length arrays (VLAs) complicate this process, as their
> -size often refers to variables initialized earlier in the block.
> -To handle this, we currently split the block at that point, and
> -move the VLA into a new, inner @code{BIND_EXPR}.  This strategy
> -may change in the future.
> +Variable-length arrays (VLAs) complicate this process, as their size
> +often refers to variables initialized earlier in the block and their
> +initialization involves an explicit stack allocation.  To handle this,
> +we add an indirection and replace them with a pointer to stack space
> +allocated by means of @code{alloca}.  In most cases, we also arrange
> +for this space to be reclaimed when the enclosing @code{BIND_EXPR} is
> +exited, the exception to this being when there is an explicit call to
> +@code{alloca} in the source code, in which case the stack is left
> +depressed on exit of the @code{BIND_EXPR}.
>
>  A C++ program will usually contain more @code{BIND_EXPR}s than
>  there are syntactic blocks in the source code, since several C++
>
>
> --
> Eric Botcazou


[PATCH] S/390: Clobber r1 in patterns resulting in pfpo instruction.

2015-11-18 Thread Dominik Vogt
The attached patch fixes the S/390 patterns using the "pfpo"
instruction in s390.md.  The instructions clobber r1, but the
patterns did not reflect that.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany
gcc/ChangeLog

* config/s390/s390.md (GPR1_REGNUM): New constant.
("*trunc2")
("*trunc2")
("trunc2")
("trunc2")
("*extend2")
("*extend2")
("extend2")
("extend2"): Clobber r1.

gcc/testsuite/ChangeLog

* gcc.target/s390/pfpo.c: New test.
>From c7ddb09c08d4d3e4d394588aa8aa43331582db86 Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Tue, 17 Nov 2015 20:10:04 +0100
Subject: [PATCH] S/390: Clobber r1 in patterns resulting in pfpo
 instruction.

---
 gcc/config/s390/s390.md  | 25 +
 gcc/testsuite/gcc.target/s390/pfpo.c | 21 +
 2 files changed, 38 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/s390/pfpo.c

diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index ea65c74..f2bb24c 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -301,6 +301,7 @@
   [
; General purpose registers
(GPR0_REGNUM  0)
+   (GPR1_REGNUM  1)
; Floating point registers.
(FPR0_REGNUM 16)
(FPR1_REGNUM 20)
@@ -4895,7 +4896,8 @@
   [(set (reg:DFP_ALL FPR0_REGNUM)
 (float_truncate:DFP_ALL (reg:BFP FPR4_REGNUM)))
(use (reg:SI GPR0_REGNUM))
-   (clobber (reg:CC CC_REGNUM))]
+   (clobber (reg:CC CC_REGNUM))
+   (clobber (reg:SI GPR1_REGNUM))]
   "TARGET_HARD_DFP"
   "pfpo")
 
@@ -4903,7 +4905,8 @@
   [(set (reg:BFP FPR0_REGNUM)
 (float_truncate:BFP (reg:DFP_ALL FPR4_REGNUM)))
(use (reg:SI GPR0_REGNUM))
-   (clobber (reg:CC CC_REGNUM))]
+   (clobber (reg:CC CC_REGNUM))
+   (clobber (reg:SI GPR1_REGNUM))]
   "TARGET_HARD_DFP"
   "pfpo")
 
@@ -4914,7 +4917,8 @@
 [(set (reg:DFP_ALL FPR0_REGNUM)
   (float_truncate:DFP_ALL (reg:BFP FPR4_REGNUM)))
  (use (reg:SI GPR0_REGNUM))
- (clobber (reg:CC CC_REGNUM))])
+ (clobber (reg:CC CC_REGNUM))
+ (clobber (reg:SI GPR1_REGNUM))])
(set (match_operand:DFP_ALL 0 "nonimmediate_operand" "")
 (reg:DFP_ALL FPR0_REGNUM))]
   "TARGET_HARD_DFP
@@ -4936,7 +4940,8 @@
(parallel
 [(set (reg:BFP FPR0_REGNUM) (float_truncate:BFP (reg:DFP_ALL FPR4_REGNUM)))
  (use (reg:SI GPR0_REGNUM))
- (clobber (reg:CC CC_REGNUM))])
+ (clobber (reg:CC CC_REGNUM))
+ (clobber (reg:SI GPR1_REGNUM))])
(set (match_operand:BFP 0 "nonimmediate_operand" "") (reg:BFP FPR0_REGNUM))]
   "TARGET_HARD_DFP
&& GET_MODE_SIZE (mode) >= GET_MODE_SIZE (mode)"
@@ -4957,14 +4962,16 @@
 (define_insn "*extend2"
   [(set (reg:DFP_ALL FPR0_REGNUM) (float_extend:DFP_ALL (reg:BFP FPR4_REGNUM)))
(use (reg:SI GPR0_REGNUM))
-   (clobber (reg:CC CC_REGNUM))]
+   (clobber (reg:CC CC_REGNUM))
+   (clobber (reg:SI GPR1_REGNUM))]
   "TARGET_HARD_DFP"
   "pfpo")
 
 (define_insn "*extend2"
   [(set (reg:BFP FPR0_REGNUM) (float_extend:BFP (reg:DFP_ALL FPR4_REGNUM)))
(use (reg:SI GPR0_REGNUM))
-   (clobber (reg:CC CC_REGNUM))]
+   (clobber (reg:CC CC_REGNUM))
+   (clobber (reg:SI GPR1_REGNUM))]
   "TARGET_HARD_DFP"
   "pfpo")
 
@@ -4975,7 +4982,8 @@
 [(set (reg:DFP_ALL FPR0_REGNUM)
   (float_extend:DFP_ALL (reg:BFP FPR4_REGNUM)))
  (use (reg:SI GPR0_REGNUM))
- (clobber (reg:CC CC_REGNUM))])
+ (clobber (reg:CC CC_REGNUM))
+ (clobber (reg:SI GPR1_REGNUM))])
(set (match_operand:DFP_ALL 0 "nonimmediate_operand" "")
 (reg:DFP_ALL FPR0_REGNUM))]
   "TARGET_HARD_DFP
@@ -4997,7 +5005,8 @@
(parallel
 [(set (reg:BFP FPR0_REGNUM) (float_extend:BFP (reg:DFP_ALL FPR4_REGNUM)))
  (use (reg:SI GPR0_REGNUM))
- (clobber (reg:CC CC_REGNUM))])
+ (clobber (reg:CC CC_REGNUM))
+ (clobber (reg:SI GPR1_REGNUM))])
(set (match_operand:BFP 0 "nonimmediate_operand" "") (reg:BFP FPR0_REGNUM))]
   "TARGET_HARD_DFP
&& GET_MODE_SIZE (mode) < GET_MODE_SIZE (mode)"
diff --git a/gcc/testsuite/gcc.target/s390/pfpo.c b/gcc/testsuite/gcc.target/s390/pfpo.c
new file mode 100644
index 000..ff8b09a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/pfpo.c
@@ -0,0 +1,21 @@
+/* The pfpo instruction generated by this code clobbers the r1 register while
+   it was still in use.  */
+
+/* { dg-do run } */
+/* { dg-options "-O0 -march=z10" } */
+
+int foo(int x)
+{
+  return x;
+}
+
+int bar(int i, float f)
+{
+  return i;
+}
+
+int main()
+{
+  _Decimal32 d = 7;
+  return bar(foo(0x10203040), (float)d) == 0x10203040 ? 0 : 1;
+}
-- 
2.3.0



[Ada] Freezing of contracts, Part_Of and current instance of a concurrent type

2015-11-18 Thread Arnaud Charlet
This patch addresses several areas:

The freezing of contracts has been enhanced. A body continues to freeze the
contract of the nearest enclosing package and now freezes the contracts of
all eligible constructs in the same declarative list that precede the body.

A concurrent constituent is no longer considered a visible state of a package
body because it is already part of a single protected/task type.

The current instance of a concurrent type now correctly includes single
protected/task types. As a result, the current instance of such a type will
appear as an implicit formal parameter of a protected subprogram or a single
task type as per SPARK RM 6.1.4.


-- Source --


--  subprogram_freezing.ads

package Subprogram_Freezing with SPARK_Mode is
   procedure Force_Freeze;
end Subprogram_Freezing;

--  subprogram_freezing.adb

package body Subprogram_Freezing with SPARK_Mode is
   function Func (Formal : Integer) return Integer
 with Contract_Cases =>
(Var + Formal = 1 => Var + Func'Result = 0,  --  Error
 others   => Var - Func'Result = 1), --  Error
  Pre=> (Var > 2),   --  Error
  Post   => (Var + Func'Result = 100);   --  Error

   procedure Force_Freeze is begin null; end Force_Freeze;

   Var : Integer := 1;

   function Func (Formal : Integer) return Integer is
   begin return Formal; end Func;
end Subprogram_Freezing;

--  variable_freezing.ads

package Variable_Freezing with SPARK_Mode is
   procedure Force_Freeze;
end Variable_Freezing;

--  variable_freezing.adb

package body Variable_Freezing with SPARK_Mode is
   Error_1 : Integer := 1 with Part_Of => Prot;  --  Error

   procedure Force_Freeze is begin null; end Force_Freeze;

   protected Prot is
   end Prot;

   protected body Prot is
   end Prot;
end Variable_Freezing;


-- Compilation and output --


$ gcc -c subprogram_freezing.adb
$ gcc -c variable_freezing.adb
subprogram_freezing.adb:2:13: body "Force_Freeze" declared at line 9 freezes
  the contract of "Func"
subprogram_freezing.adb:2:13: all contractual items must be declared before
  body at line 9
subprogram_freezing.adb:6:30: "Var" is undefined (more references follow)
variable_freezing.adb:2:04: body "Force_Freeze" declared at line 4 freezes the
  contract of "Error_1"
variable_freezing.adb:2:04: all contractual items must be declared before body
  at line 4
variable_freezing.adb:2:43: "Prot" is undefined

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

2015-11-18  Hristian Kirtchev  

* contracts.adb (Analyze_Contracts): New routine.
(Analyze_Enclosing_Package_Body_Contract): Removed.
(Analyze_Entry_Or_Subprogram_Contract): Add formal parameter
Freeze_Id.  Propagate the entity of the freezing body to vaious
analysis routines.
(Analyze_Initial_Declaration_Contract): Removed.
(Analyze_Object_Contract): Add formal parameter
Freeze_Id. Propagate the entity of the freezing body to vaious
analysis routines.
(Analyze_Previous_Contracts): New routine.
* contracts.ads (Analyze_Enclosing_Package_Body_Contract): Removed.
(Analyze_Contracts): New routine.
(Analyze_Entry_Or_Subprogram_Contract): Add formal
parameter Freeze_Id and update the comment on usage.
(Analyze_Initial_Declaration_Contract): Removed.
(Analyze_Object_Contract): Add formal parameter Freeze_Id and
update the comment on usage.
(Analyze_Previous_Contracts): New routine.
* sem_ch3.adb (Analyze_Declarations): Use Analyze_Contracts to
analyze all contracts of eligible constructs.
* sem_ch6.adb (Analyze_Generic_Subprogram_Body):
A body no longer freezes the contract of its initial
declaration. This effect is achieved through different means.
(Analyze_Subprogram_Body_Helper): A body now freezes the contracts
of all eligible constructs that precede it. A body no longer
freezes the contract of its initial declaration. This effect is
achieved through different means.
* sem_ch7.adb (Analyze_Package_Body_Helper): A body now freezes
the contracts of all eligible constructs that precede it. A body
no longer freezes the contract of its initial declaration. This
effect is achieved through different means.
* sem_ch9.adb (Analyze_Entry_Body): A body now freezes
the contracts of all eligible constructs that precede
it. A body no longer freezes the contract of its initial
declaration. This effect is achieved through different means.
(Analyze_Protected_Body): A body now freezes the contracts
of all eligible constructs that precede it. A body no longer
freezes the contract of its 

  1   2   >