Fix coverage inaccuracy with return in C/C++

2014-11-10 Thread Eric Botcazou
We just remarked that there is a coverage inaccuracy in C/C++ for something as 
simple as:

void
foo (int i)
{
  if (i > 1)
return;

  bar ();
}

The return line is always reported as covered, even at -O0.  That's because 
the return is used as the "representative return" for the entire function 
and then reused for the fallthru as-is.   The interesting thing is that this 
doesn't happen in Ada for an equivalent code, because the Ada compiler always 
adds a final return to functions:

void
foo (int i)
{
  if (i > 1)
return;

  bar ();
  return;
}

In this case of 2 or more returns, the machinery in gimple-low.c properly 
clears the location on the representative return:

  /* Remove the line number from the representative return statement.
 It now fills in for many such returns.  Failure to remove this
 will result in incorrect results for coverage analysis.  */
  gimple_set_location (tmp_rs.stmt, UNKNOWN_LOCATION);

Hence the attached patch, which does the same when a representative return is 
reused for the fallthru.

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


2014-11-10  Eric Botcazou  

* gimple-low.c (lower_function_body): Clear the location of the first
inserted representative return if it also fills in for the fallthru.


2014-11-10  Eric Botcazou  

* gcc.misc-tests/gcov-15.c: New test.


-- 
Eric BotcazouIndex: gimple-low.c
===
--- gimple-low.c	(revision 217259)
+++ gimple-low.c	(working copy)
@@ -129,7 +129,8 @@ lower_function_body (void)
   /* If the function falls off the end, we need a null return statement.
  If we've already got one in the return_statements vector, we don't
  need to do anything special.  Otherwise build one by hand.  */
-  if (gimple_seq_may_fallthru (lowered_body)
+  bool may_fallthru = gimple_seq_may_fallthru (lowered_body);
+  if (may_fallthru
   && (data.return_statements.is_empty ()
 	  || (gimple_return_retval (data.return_statements.last().stmt)
 	  != NULL)))
@@ -138,6 +139,7 @@ lower_function_body (void)
   gimple_set_location (x, cfun->function_end_locus);
   gimple_set_block (x, DECL_INITIAL (current_function_decl));
   gsi_insert_after (&i, x, GSI_CONTINUE_LINKING);
+  may_fallthru = false;
 }
 
   /* If we lowered any return statements, emit the representative
@@ -148,6 +150,14 @@ lower_function_body (void)
   x = gimple_build_label (t.label);
   gsi_insert_after (&i, x, GSI_CONTINUE_LINKING);
   gsi_insert_after (&i, t.stmt, GSI_CONTINUE_LINKING);
+  if (may_fallthru)
+	{
+	  /* Remove the line number from the representative return statement.
+	 It now fills in for the fallthru too.  Failure to remove this
+	 will result in incorrect results for coverage analysis.  */
+	  gimple_set_location (t.stmt, UNKNOWN_LOCATION);
+	  may_fallthru = false;
+	}
 }
 
   /* Once the old body has been lowered, replace it with the new/* { dg-options "-fprofile-arcs -ftest-coverage" } */
/* { dg-do run { target native } } */

void
bar (void)
{}

void
foo (int i)
{
  if (i > 1)  /* count(1) */
return;   /* count(#) */

  bar ();  /* count(1) */
}

int
main (void)
{
  foo (0);
  return 0;
}

/* { dg-final { run-gcov gcov-15.c } } */

[PATCH][14/n] Merge from match-and-simplify, more conversion patterns

2014-11-10 Thread Richard Biener

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

Richard.

2014-11-10  Richard Biener  

* match.pd: Move rest of the conversion combining patterns
from tree-ssa-forwprop.c.
* tree-ssa-forwprop.c (combine_conversions): Remove.
(pass_forwprop::execute): Do not call it.

Index: trunk/gcc/match.pd
===
*** trunk.orig/gcc/match.pd 2014-11-09 12:22:38.846998253 +0100
--- trunk/gcc/match.pd  2014-11-09 12:32:38.109972029 +0100
*** along with GCC; see the file COPYING3.
*** 411,414 
&& ! (final_ptr && inside_prec != inter_prec)
&& ! (final_prec != GET_MODE_PRECISION (TYPE_MODE (type))
  && TYPE_MODE (type) == TYPE_MODE (inter_type)))
! (ocvt @0))
--- 411,433 
&& ! (final_ptr && inside_prec != inter_prec)
&& ! (final_prec != GET_MODE_PRECISION (TYPE_MODE (type))
  && TYPE_MODE (type) == TYPE_MODE (inter_type)))
! (ocvt @0))
! 
!/* A truncation to an unsigned type (a zero-extension) should be
!   canonicalized as bitwise and of a mask.  */
!(if (final_int && inter_int && inside_int
!   && final_prec == inside_prec
!   && final_prec > inter_prec
!   && inter_unsignedp)
! (convert (bit_and @0 { wide_int_to_tree
!(inside_type,
! wi::mask (inter_prec, false,
!   TYPE_PRECISION (inside_type))); })))
! 
!/* If we are converting an integer to a floating-point that can
!   represent it exactly and back to an integer, we can skip the
!   floating-point conversion.  */
!(if (inside_int && inter_float && final_int &&
!   (unsigned) significand_size (TYPE_MODE (inter_type))
!   >= inside_prec - !inside_unsignedp)
! (convert @0))
Index: trunk/gcc/tree-ssa-forwprop.c
===
*** trunk.orig/gcc/tree-ssa-forwprop.c  2014-11-09 12:22:39.165998239 +0100
--- trunk/gcc/tree-ssa-forwprop.c   2014-11-09 12:34:28.933967179 +0100
*** out:
*** 2345,2458 
return false;
  }
  
- /* Combine two conversions in a row for the second conversion at *GSI.
-Returns 1 if there were any changes made, 2 if cfg-cleanup needs to
-run.  Else it returns 0.  */
-  
- static int
- combine_conversions (gimple_stmt_iterator *gsi)
- {
-   gimple stmt = gsi_stmt (*gsi);
-   gimple def_stmt;
-   tree op0, lhs;
-   enum tree_code code = gimple_assign_rhs_code (stmt);
-   enum tree_code code2;
- 
-   gcc_checking_assert (CONVERT_EXPR_CODE_P (code)
-  || code == FLOAT_EXPR
-  || code == FIX_TRUNC_EXPR);
- 
-   lhs = gimple_assign_lhs (stmt);
-   op0 = gimple_assign_rhs1 (stmt);
-   if (useless_type_conversion_p (TREE_TYPE (lhs), TREE_TYPE (op0)))
- {
-   gimple_assign_set_rhs_code (stmt, TREE_CODE (op0));
-   return 1;
- }
- 
-   if (TREE_CODE (op0) != SSA_NAME)
- return 0;
- 
-   def_stmt = SSA_NAME_DEF_STMT (op0);
-   if (!is_gimple_assign (def_stmt))
- return 0;
- 
-   code2 = gimple_assign_rhs_code (def_stmt);
- 
-   if (CONVERT_EXPR_CODE_P (code2) || code2 == FLOAT_EXPR)
- {
-   tree defop0 = gimple_assign_rhs1 (def_stmt);
-   tree type = TREE_TYPE (lhs);
-   tree inside_type = TREE_TYPE (defop0);
-   tree inter_type = TREE_TYPE (op0);
-   int inside_int = INTEGRAL_TYPE_P (inside_type);
-   unsigned int inside_prec = TYPE_PRECISION (inside_type);
-   int inside_unsignedp = TYPE_UNSIGNED (inside_type);
-   int inter_int = INTEGRAL_TYPE_P (inter_type);
-   int inter_float = FLOAT_TYPE_P (inter_type);
-   unsigned int inter_prec = TYPE_PRECISION (inter_type);
-   int inter_unsignedp = TYPE_UNSIGNED (inter_type);
-   int final_int = INTEGRAL_TYPE_P (type);
-   unsigned int final_prec = TYPE_PRECISION (type);
- 
-   /* Don't propagate ssa names that occur in abnormal phis.  */
-   if (TREE_CODE (defop0) == SSA_NAME
- && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (defop0))
-   return 0;
- 
-   /* A truncation to an unsigned type should be canonicalized as
-bitwise and of a mask.  */
-   if (final_int && inter_int && inside_int
- && final_prec == inside_prec
- && final_prec > inter_prec
- && inter_unsignedp)
-   {
- tree tem;
- tem = fold_build2 (BIT_AND_EXPR, inside_type,
-defop0,
-wide_int_to_tree
-(inside_type,
- wi::mask (inter_prec, false,
-   TYPE_PRECISION (inside_type;
- if (!useless_type_conversion_p (type, inside_type))
-   {
- tem = force_gimple_operand_gsi (gsi, tem, true, NULL_TREE, true,
- GSI_SAME_STMT);
- 

Re: RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?

2014-11-10 Thread Roman Gareev
> The patch looks great. The only piece I think we missed is the
> fgraphite-code-generator flag. I would propose to remove it as well in this
> commit, as it does not have any effect any more.

In this case, we’ll also have to change tests which use
fgraphite-code-generator flag (isl-ast-gen-blocks-1.c,
isl-ast-gen-blocks-2.c, isl-ast-gen-blocks-3.c,
isl-ast-gen-blocks-4.c, isl-ast-gen-if-1.c, isl-ast-gen-if-2.c,
isl-ast-gen-single-loop-1.c, isl-ast-gen-single-loop-2.c,
isl-ast-gen-user-1.c, isl-codegen-loop-dumping.c). Maybe we should do
this in the next patch?


-- 
Cheers, Roman Gareev.


[PATCH GCC]Fix checking on MAX_PENDING_LIST_LENGTH

2014-11-10 Thread Bin Cheng
Hi,
There is parameter max-pending-list-length in gcc scheduler, but the
parameter is checked using greater than condition.  As a result, the real
max pending list length is actually "max-pending-list-length + 1".  This
patch fixes this by using ">=" rather than ">" comparison operator.  Though
it is kind of nit-picking, I want to change this: a) it breaks sched-fusion
because the 33rd couldn't be paired; b) when sched-fusion tries to sort many
consecutive stores, it breaks dcache line alignment at large probability.  I
mean without cache sensitive optimizer, GCC breaks dcache line alignment
randomly, but 33 is definitely worse than 32.  Of course, this only happens
in very restricted case.

Bootstrap and test on x86_64.  Is it OK?

2014-11-10  Bin Cheng  

* sched-deps.c (sched_analyze_1): Check pending list if it is not
less than MAX_PENDING_LIST_LENGTH.
(sched_analyze_2, sched_analyze_insn, deps_analyze_insn): Ditto.
Index: gcc/sched-deps.c
===
--- gcc/sched-deps.c(revision 217273)
+++ gcc/sched-deps.c(working copy)
@@ -2504,7 +2504,7 @@ sched_analyze_1 (struct deps_desc *deps, rtx x, rt
   /* Pending lists can't get larger with a readonly context.  */
   if (!deps->readonly
   && ((deps->pending_read_list_length + 
deps->pending_write_list_length)
-  > MAX_PENDING_LIST_LENGTH))
+  >= MAX_PENDING_LIST_LENGTH))
{
  /* Flush all pending reads and writes to prevent the pending lists
 from getting any larger.  Insn scheduling runs too slowly when
@@ -2722,7 +2722,7 @@ sched_analyze_2 (struct deps_desc *deps, rtx x, rt
  {
if ((deps->pending_read_list_length
 + deps->pending_write_list_length)
-   > MAX_PENDING_LIST_LENGTH
+   >= MAX_PENDING_LIST_LENGTH
&& !DEBUG_INSN_P (insn))
  flush_pending_lists (deps, insn, true, true);
add_insn_mem_dependence (deps, true, insn, x);
@@ -3227,8 +3227,8 @@ sched_analyze_insn (struct deps_desc *deps, rtx x,
  EXECUTE_IF_SET_IN_REG_SET (reg_pending_clobbers, 0, i, rsi)
{
  struct deps_reg *reg_last = &deps->reg_last[i];
- if (reg_last->uses_length > MAX_PENDING_LIST_LENGTH
- || reg_last->clobbers_length > MAX_PENDING_LIST_LENGTH)
+ if (reg_last->uses_length >= MAX_PENDING_LIST_LENGTH
+ || reg_last->clobbers_length >= MAX_PENDING_LIST_LENGTH)
{
  add_dependence_list_and_free (deps, insn, ®_last->sets, 0,
REG_DEP_OUTPUT, false);
@@ -3661,7 +3661,7 @@ deps_analyze_insn (struct deps_desc *deps, rtx_ins
&& sel_insn_is_speculation_check (insn)))
 {
   /* Keep the list a reasonable size.  */
-  if (deps->pending_flush_length++ > MAX_PENDING_LIST_LENGTH)
+  if (deps->pending_flush_length++ >= MAX_PENDING_LIST_LENGTH)
 flush_pending_lists (deps, insn, true, true);
   else
deps->pending_jump_insns


[PATCH] Fix a few UNRESOLVEDs

2014-11-10 Thread Marek Polacek
This fixes a few UNRESOLVEDs because I forgot to skip -fno-fat-lto-objects
when I introduced the tests.

Ok for trunk?

2014-11-10  Marek Polacek  

* c-c++-common/ubsan/align-7.c: Skip for -flto -fno-fat-lto-objects.
* c-c++-common/ubsan/align-8.c: Likewise.
* g++.dg/ubsan/null-4.C: Likewise.
* g++.dg/ubsan/null-5.C: Likewise.

diff --git gcc/testsuite/c-c++-common/ubsan/align-7.c 
gcc/testsuite/c-c++-common/ubsan/align-7.c
index 4a18d8d..68c9135 100644
--- gcc/testsuite/c-c++-common/ubsan/align-7.c
+++ gcc/testsuite/c-c++-common/ubsan/align-7.c
@@ -1,6 +1,7 @@
 /* Limit this to known non-strict alignment targets.  */
 /* { dg-do run { target { i?86-*-linux* x86_64-*-linux* } } } */
 /* { dg-options "-O -fsanitize=alignment -fno-sanitize-recover=alignment 
-fdump-tree-sanopt-details" } */
+/* { dg-skip-if "" { *-*-* } { "-flto -fno-fat-lto-objects" } } */
 /* { dg-shouldfail "ubsan" } */
 
 struct S { int a; char b; long long c; short d[10]; };
@@ -27,6 +28,6 @@ main ()
   return 0;
 }
 
-/* { dg-output "\.c:15:\[0-9]*: \[^\n\r]*member access within misaligned 
address 0x\[0-9a-fA-F]* for type 'struct S', which requires \[48] byte 
alignment.*" } */
+/* { dg-output "\.c:16:\[0-9]*: \[^\n\r]*member access within misaligned 
address 0x\[0-9a-fA-F]* for type 'struct S', which requires \[48] byte 
alignment.*" } */
 /* { dg-final { scan-tree-dump-times "Optimizing" 4 "sanopt"} } */
 /* { dg-final { cleanup-tree-dump "sanopt" } } */
diff --git gcc/testsuite/c-c++-common/ubsan/align-8.c 
gcc/testsuite/c-c++-common/ubsan/align-8.c
index b930162..4e43a09 100644
--- gcc/testsuite/c-c++-common/ubsan/align-8.c
+++ gcc/testsuite/c-c++-common/ubsan/align-8.c
@@ -1,6 +1,7 @@
 /* Limit this to known non-strict alignment targets.  */
 /* { dg-do run { target { i?86-*-linux* x86_64-*-linux* } } } */
 /* { dg-options "-O -fsanitize=alignment -fsanitize-undefined-trap-on-error 
-fdump-tree-sanopt-details" } */
+/* { dg-skip-if "" { *-*-* } { "-flto -fno-fat-lto-objects" } } */
 /* { dg-shouldfail "ubsan" } */
 
 struct S { int a; char b; long long c; short d[10]; };
diff --git gcc/testsuite/g++.dg/ubsan/null-4.C 
gcc/testsuite/g++.dg/ubsan/null-4.C
index 9cb04ef..55944a4 100644
--- gcc/testsuite/g++.dg/ubsan/null-4.C
+++ gcc/testsuite/g++.dg/ubsan/null-4.C
@@ -1,5 +1,6 @@
 // { dg-do run }
 // { dg-options "-O -fsanitize=null -fno-sanitize-recover=null 
-fdump-tree-sanopt-details" }
+// { dg-skip-if "" { *-*-* } { "-flto -fno-fat-lto-objects" } }
 // { dg-shouldfail "ubsan" }
 
 int
diff --git gcc/testsuite/g++.dg/ubsan/null-5.C 
gcc/testsuite/g++.dg/ubsan/null-5.C
index d8e4a68..fbda96f 100644
--- gcc/testsuite/g++.dg/ubsan/null-5.C
+++ gcc/testsuite/g++.dg/ubsan/null-5.C
@@ -1,5 +1,6 @@
 // { dg-do run }
 // { dg-options "-O -fsanitize=null -fsanitize-undefined-trap-on-error 
-fdump-tree-sanopt-details" }
+// { dg-skip-if "" { *-*-* } { "-flto -fno-fat-lto-objects" } }
 // { dg-shouldfail "ubsan" }
 
 int

Marek


Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s

2014-11-10 Thread Michael Haubenwallner

Am 2014-11-07 20:52, schrieb David Edelsohn:
> First, please explicitly copy me on AIX or PowerPC patches sent to 
> gcc-patches.
> 
> I don't have a fundamental objection to including this option, but
> note that Richi, Honza and I have discovered that using AIX runtime
> linking option interacts badly with some GCC optimizations and can
> result in applications that hang in a loop.

Feels like adding the "aix-soname" linking procedure becomes more important:

> All code on AIX is position independent (PIC) by default.  Executables
> and shared libraries essentially are PIE.  Because of this, AIX does
> not provide separate "static" libraries and one can link statically
> with a shared library.
> 
> Creating a library enabled for runtime linking with -G (-brtl), causes
> a lot of problems, including a newly recognized failure mode.  Without
> careful control over AIX symbol export, all global calls with use
> glink code (equivalent to ELF PLTs). This also creates a TOC entry for
> every global call, possibly overflowing the TOC.

About to define "careful control over AIX symbol export":
The symbols listed in the import file are those found in the object files
only, not the ones created at linktime (like __GLOBAL*) or from the static
objects found in libc.a. While I do this in libtool from the beginning here,
I have had a helper script wrapping ld to support '--soname=' for non-libtool
packages, where creating the import file from the final shared object also
included static libc-provided symbols, which turned out as dependency pitfall.

While I haven't focussed on nor explicitly tested, I do believe that this
also solves problems with global C++ constructor/destructor call orders.

> But the main problem is GCC uses aliases and functions declared as
> weak to support some C++ features.

This is another reason why I do force runtime linking for our application,
which uses these C++ features while its main target platform is Linux.

> Functions declared weak interact
> badly with shared libraries compiled for AIX runtime linking and
> linked statically.

The "aix-soname" proposal does not support statically linking shared objects
built with -brtl, but provides lib.a archives either with pure static objects
only (aix-soname=svr4), or with the traditional shared object linked without
-brtl (aix-soname=both).

> This can result in the static binary binding with
> the glink code that loads its own address from the TOC instead of the
> target function, causing endless looping.  Honza made some changes to
> GCC code generation for AIX, but there still are problems and I have
> disabled building libstdc++ enabled for runtime linking.

So as long as shared objects built with -brtl actually work for /shared/ 
linking,
the "aix-soname" linking procedure seems /necessary/ to support all features.

> libgcc always explicitly creates a static library and uses it for
> static linking.  All shared libraries for AIX that use this scheme
> (through libtool) would have to follow the same convention to create
> both shared and static libraries.  This new option only makes sense if
> it fully emulates SVR4/ELF behavior and always creates both shared .so
> and static .a libraries.

This exactly is what I do in Gentoo Prefix/AIX, with best experience using
gcc-4.2.4 for the moment. As I do provide the complete tool- & library-chain
(like /opt/freeware/), I don't create traditional AIX shared objects at all,
but static only lib.a archives whenever --enable-static is true - which is
the "--with-aix-soname=svr4" use case.

Slightly modified the patch to not create the libgcc_s.a symlink with
aix-soname=svr4 now.
And the Makefile target also has to be libgcc_s.so (via SHLIB_EXT) now.

Thanks!
/haubi/
>From ab834013e504ddfbbc0a04aca2bd94ef0b49ace5 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner 
Date: Fri, 16 Mar 2012 14:49:20 +0100
Subject: [PATCH] AIX: Filename-based shlib versioning for libgcc_s

2014-11-10  Michael Haubenwallner 

	(libgcc_s) Optional filename-based shared library versioning on AIX.
	* gcc/doc/install.texi: Describe --with-aix-soname option.
	* Makefile.in (with_aix_soname): Define.
	* config/rs6000/t-slibgcc-aix: Act upon --with-aix-soname option.
	* configure.in: Accept --with-aix-soname=aix|svr4|both option.
	* configure: Recreate.
---
 gcc/doc/install.texi   | 102 +
 libgcc/Makefile.in |   1 +
 libgcc/config/rs6000/t-slibgcc-aix |  82 +++--
 libgcc/configure   |  28 ++
 libgcc/configure.ac|  17 +++
 5 files changed, 214 insertions(+), 16 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 3df78ff..161f7e5 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -1414,6 +1414,102 @@ particularly useful if you intend to use several versions of GCC in
 parallel.  This is currently supported by @samp{libgfortran},
 @samp{libjava}, @samp{libstdc++

[PATCH] Fix PR63798

2014-11-10 Thread Richard Biener

The following patch fixes a latent bug uncovered by stmt folding
that expansion of FMA_EXPR didn't consider the multiplication
commutative when looking for feeding negates.

Bootstrap & regtest pending.

Richard.

2014-11-10  Richard Biener  

PR middle-end/63798
* expr.c (expand_expr_real_2): When expanding FMA_EXPRs
properly treat the embedded multiplication as commutative
when looking for feeding negates.

Index: gcc/expr.c
===
--- gcc/expr.c  (revision 217281)
+++ gcc/expr.c  (working copy)
@@ -8621,6 +8621,19 @@ expand_expr_real_2 (sepops ops, rtx targ
  }
 
def0 = get_def_for_expr (treeop0, NEGATE_EXPR);
+   /* The multiplication is commutative - look at its 2nd operand
+  if the first isn't fed by a negate.  */
+   if (!def0)
+ {
+   def0 = get_def_for_expr (treeop1, NEGATE_EXPR);
+   /* Swap operands if the 2nd operand is fed by a negate.  */
+   if (def0)
+ {
+   tree tem = treeop0;
+   treeop0 = treeop1;
+   treeop1 = tem;
+ }
+ }
def2 = get_def_for_expr (treeop2, NEGATE_EXPR);
 
op0 = op2 = NULL;


Re: [PATCH] Fix a few UNRESOLVEDs

2014-11-10 Thread Jakub Jelinek
On Mon, Nov 10, 2014 at 10:41:36AM +0100, Marek Polacek wrote:
> This fixes a few UNRESOLVEDs because I forgot to skip -fno-fat-lto-objects
> when I introduced the tests.
> 
> Ok for trunk?
> 
> 2014-11-10  Marek Polacek  
> 
>   * c-c++-common/ubsan/align-7.c: Skip for -flto -fno-fat-lto-objects.
>   * c-c++-common/ubsan/align-8.c: Likewise.
>   * g++.dg/ubsan/null-4.C: Likewise.
>   * g++.dg/ubsan/null-5.C: Likewise.

Ok, thanks.

Jakub


[PATCH] IPA ICF fallout: disable IPA ICF for a test

2014-11-10 Thread Martin Liška

Hello.

In gcc.dg/tree-ssa/ldist-19.c, there's a pair of functions (one with 'char' and 
second with 'unsigned char'). These two functions are merged by IPA ICF on 
targets that where 'char' == 'unsigned char'. So that it would be easier to 
disable the optimization.

Ready for trunk?

Thanks,
Martin
gcc/testsuite/ChangeLog:

2014-11-10  Martin Liska  

* gcc.dg/tree-ssa/ldist-19.c: ICF is disabled
for the test because of default char signedness
on powerpc64 target.
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ldist-19.c b/gcc/testsuite/gcc.dg/tree-ssa/ldist-19.c
index 8ea9cea..9ab681f 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ldist-19.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ldist-19.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O3 -fdump-tree-ldist-details" } */
+/* { dg-options "-O3 -fno-ipa-icf -fdump-tree-ldist-details" } */
 
 struct Foo
 {


[PATCH][15/n] Merge from match-and-simplify, last conversion pattern

2014-11-10 Thread Richard Biener

This merges the last conversion pattern from tree-ssa-forwprop.c.

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

Richard.

2014-11-10  Richard Biener  

* match.pd: Implement pattern from simplify_conversion_from_bitmask.
* tree-ssa-forwprop.c (simplify_conversion_from_bitmask): Remove.
(pass_forwprop::execute): Do not call simplify_conversion_from_bitmask.

Index: trunk/gcc/match.pd
===
*** trunk.orig/gcc/match.pd 2014-11-10 10:15:49.325550358 +0100
--- trunk/gcc/match.pd  2014-11-10 10:17:12.413546722 +0100
*** along with GCC; see the file COPYING3.
*** 431,433 
--- 431,445 
(unsigned) significand_size (TYPE_MODE (inter_type))
>= inside_prec - !inside_unsignedp)
  (convert @0))
+ 
+ /* If we have a narrowing conversion to an integral type that is fed by a
+BIT_AND_EXPR, we might be able to remove the BIT_AND_EXPR if it merely
+masks off bits outside the final type (and nothing else).  */
+ (simplify
+   (convert (bit_and @0 INTEGER_CST@1))
+   (if (INTEGRAL_TYPE_P (type)
+&& INTEGRAL_TYPE_P (TREE_TYPE (@0))
+&& TYPE_PRECISION (type) <= TYPE_PRECISION (TREE_TYPE (@0))
+&& operand_equal_p (@1, build_low_bits_mask (TREE_TYPE (@1),
+   TYPE_PRECISION (type)), 0))
+(convert @0)))
Index: trunk/gcc/tree-ssa-forwprop.c
===
*** trunk.orig/gcc/tree-ssa-forwprop.c  2014-11-10 10:15:49.60343 +0100
--- trunk/gcc/tree-ssa-forwprop.c   2014-11-10 10:20:47.391537314 +0100
*** bailout:
*** 1214,1291 
  }
  
  
- /* GSI_P points to a statement which performs a narrowing integral
-conversion.
- 
-Look for cases like:
- 
-  t = x & c;
-  y = (T) t;
- 
-Turn them into:
- 
-  t = x & c;
-  y = (T) x;
- 
-If T is narrower than X's type and C merely masks off bits outside
-of (T) and nothing else.
- 
-Normally we'd let DCE remove the dead statement.  But no DCE runs
-after the last forwprop/combine pass, so we remove the obviously
-dead code ourselves.
- 
-Return TRUE if a change was made, FALSE otherwise.  */
- 
- static bool 
- simplify_conversion_from_bitmask (gimple_stmt_iterator *gsi_p)
- {
-   gimple stmt = gsi_stmt (*gsi_p);
-   gimple rhs_def_stmt = SSA_NAME_DEF_STMT (gimple_assign_rhs1 (stmt));
- 
-   /* See if the input for the conversion was set via a BIT_AND_EXPR and
-  the only use of the BIT_AND_EXPR result is the conversion.  */
-   if (is_gimple_assign (rhs_def_stmt)
-   && gimple_assign_rhs_code (rhs_def_stmt) == BIT_AND_EXPR
-   && has_single_use (gimple_assign_lhs (rhs_def_stmt)))
- {
-   tree rhs_def_operand1 = gimple_assign_rhs1 (rhs_def_stmt);
-   tree rhs_def_operand2 = gimple_assign_rhs2 (rhs_def_stmt);
-   tree lhs_type = TREE_TYPE (gimple_assign_lhs (stmt));
- 
-   /* Now verify suitability of the BIT_AND_EXPR's operands.
-The first must be an SSA_NAME that we can propagate and the
-second must be an integer constant that masks out all the
-bits outside the final result's type, but nothing else.  */
-   if (TREE_CODE (rhs_def_operand1) == SSA_NAME
- && ! SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs_def_operand1)
- && TREE_CODE (rhs_def_operand2) == INTEGER_CST
- && operand_equal_p (rhs_def_operand2,
- build_low_bits_mask (TREE_TYPE (rhs_def_operand2),
-  TYPE_PRECISION (lhs_type)),
-  0))
-   {
- /* This is an optimizable case.  Replace the source operand
-in the conversion with the first source operand of the
-BIT_AND_EXPR.  */
- gimple_assign_set_rhs1 (stmt, rhs_def_operand1);
- stmt = gsi_stmt (*gsi_p);
- update_stmt (stmt);
- 
- /* There is no DCE after the last forwprop pass.  It's
-easy to clean up the first order effects here.  */
- gimple_stmt_iterator si;
- si = gsi_for_stmt (rhs_def_stmt);
- gsi_remove (&si, true);
- fwprop_invalidate_lattice (gimple_get_lhs (rhs_def_stmt));
- release_defs (rhs_def_stmt);
- return true;
-   }
- }
- 
-   return false;
- }
- 
- 
  /* Helper function for simplify_gimple_switch.  Remove case labels that
 have values outside the range of the new type.  */
  
--- 1214,1219 
*** pass_forwprop::execute (function *fun)
*** 2940,2963 
&& maybe_clean_or_replace_eh_stmt (stmt, stmt))
  bitmap_set_bit (to_purge, bb->index);
  }
-   else if (CONVERT_EXPR_CODE_P (code)
-|| code == FLOAT_EXPR
-|| code == FIX_TRUNC_EXPR)
-

Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto

2014-11-10 Thread Richard Biener
On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu  wrote:
> Hi,
>
> r216964 disables bootstrap for libcc1 which exposed 2 things:
>
> 1. libcc1 isn't compiled with LTO even when GCC is configured with
> "--with-build-config=bootstrap-lto".  It may be intentional since
> libcc1 is disabled for bootstrap.
> 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is
> compiled with LTO which remembers PIC option.

Why is this any special to LTO?  If it is then it looks like a LTO
(driver) issue to me?  Why are we linking the pic libibterty into
a non-pic libcc1?

Richard.

> libiberty is bootstrapped with LTO.  When libcc1 isn't compiled with
> LTO, we are creating libcc1.so without -fPIC, which leads to linker
> failure when linking with slim-lto libiberty.  This patch from
>
> https://gcc.gnu.org/ml/gcc-patches/2012-09/msg00991.html
>
> adds -fPIC to -shared so that -fPIC is always used to create shared
> object.  Tested on Linux/x86-64.  OK for trunk?
>
> Thanks.
>
>
> H.J.
> ---
> 2014-11-09  Markus Trippelsdorf  
>
> PR bootstrap/63784
> * libtool.m4: Add $pic_flag with -shared.
>
> boehm-gc/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> gcc/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libatomic/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libbacktrace/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libcc1/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libcilkrts/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libffi/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libgfortran/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libgomp/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libitm/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libjava/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libjava/classpath/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libobjc/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libquadmath/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libsanitizer/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libssp/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libstdc++-v3/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libvtv/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> lto-plugin/
>
> 2014-11-09  H.J. Lu  
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> diff --git a/ChangeLog b/ChangeLog
> index 5c7f649..25bc026 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,8 @@
> +2014-11-09  Markus Trippelsdorf  
> +
> +   PR bootstrap/63784
> +   * libtool.m4: Add $pic_flag with -shared.
> +
>  2014-10-31  Jakub Jelinek  
>
> * Makefile.def (libcc1): Remove bootstrap=true;.
> diff --git a/boehm-gc/ChangeLog b/boehm-gc/ChangeLog
> index 1c8cbda..7a2750f 100644
> --- a/boehm-gc/ChangeLog
> +++ b/boehm-gc/ChangeLog
> @@ -1,3 +1,8 @@
> +2014-11-09  H.J. Lu  
> +
> +   PR bootstrap/63784
> +   * configure: Regenerated.
> +
>  2014-10-23  Rainer Orth  
>
> * include/gc.h [(sparc || __sparc) && sun] (GC_INIT): Remove
> diff --git a/boehm-gc/configure b/boehm-gc/configure
> index 025003c..efaf7b8 100755
> --- a/boehm-gc/configure
> +++ b/boehm-gc/configure
> @@ -9081,7 +9081,7 @@ _LT_EOF
>if $LD --help 2>&1 | $EGREP ': supported targets:.* elf' > /dev/null \
>  && test "$tmp_diet" = no
>then
> -   tmp_addflag=
> +   tmp_addflag=' $pic_flag'
> tmp_sharedflag='-shared'
> case $cc_basename,$host_cpu in
>  pgcc*) # Portland Group C compiler
> @@ -12019,8 +12019,8 @@ with_gnu_ld=$lt_cv_prog_gnu_ld
># Check if GNU C++ uses GNU ld as the underlying linker, since the
># archiving commands below assume that GNU ld is being used.
>if test "$with_gnu_ld" = yes; then
> -archive_cmds_CXX='$CC -shared -nostdlib $predep_objects $libobjs 
> $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o $lib'
> -archive_expsym_cmds_CXX='$CC -shared -nostdlib $predep_objects 
> $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname 
> ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
> +archive_cm

Re: [PATCH][Revisedx2] Fix PR63750

2014-11-10 Thread Richard Biener
On Sun, Nov 9, 2014 at 5:57 PM, Jack Howarth  wrote:
> Iain,
>  It doesn't look like it will be that simple. If I replace the
> proposed patches with a change like...
>
> Index: gcc/system.h
> ===
> --- gcc/system.h(revision 217238)
> +++ gcc/system.h(working copy)
> @@ -194,6 +194,13 @@ extern int fprintf_unlocked (FILE *, con
>  #undef fread_unlocked
>  #undef fwrite_unlocked
>
> +/* Include  before "safe-ctype.h" to avoid avoid GCC poisoning
> +the ctype macros through safe-ctype.h */
> +
> +#ifdef __cplusplus
> +# include 
> +#endif
> +

Indeed  is a system header and should not have been included
from tree-chkp.c but system.h.

Richard.

>  /* There are an extraordinary number of issues with .
> The last straw is that it varies with the locale.  Use libiberty's
> replacement instead.  */
>
> The bootstrap fails at a new place with...
>
> make[3]: Entering directory
> '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc'
> g++ -c   -g  -DIN_GCC-fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
> -Wcast-qual -Wno-format -Wmissing-format-attribute
> -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
> -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I.
> -I../../gcc-5.0-20141107/gcc -I../../gcc-5.0-20141107/gcc/.
> -I../../gcc-5.0-20141107/gcc/../include
> -I../../gcc-5.0-20141107/gcc/../libcpp/include -I/sw/include
> -I/sw/include  -I../../gcc-5.0-20141107/gcc/../libdecnumber
> -I../../gcc-5.0-20141107/gcc/../libdecnumber/dpd -I../libdecnumber
> -I../../gcc-5.0-20141107/gcc/../libbacktrace -DCLOOG_INT_GMP
> -I/sw/include -DCLOOG_INT_GMP -I/sw/include -I/sw/include -o
> simplify-rtx.o -MT simplify-rtx.o -MMD -MP -MF
> ./.deps/simplify-rtx.TPo ../../gcc-5.0-20141107/gcc/simplify-rtx.c
> clang: warning: treating 'c' input as 'c++' when in C++ mode, this
> behavior is deprecated
> In file included from ../../gcc-5.0-20141107/gcc/simplify-rtx.c:23:
> ../../gcc-5.0-20141107/gcc/coretypes.h:62:1: warning: class 'rtx_def'
> was previously declared as a struct [-Wmismatched-tags]
> class rtx_def;
> ^
> ../../gcc-5.0-20141107/gcc/coretypes.h:55:8: note: previous use is here
> struct rtx_def;
>^
> In file included from ../../gcc-5.0-20141107/gcc/simplify-rtx.c:25:
> In file included from ../../gcc-5.0-20141107/gcc/rtl.h:27:
> In file included from ../../gcc-5.0-20141107/gcc/real.h:25:
> ../../gcc-5.0-20141107/gcc/wide-int.h:370:3: warning: extraneous
> template parameter list in template specialization
>   template <>
>   ^~~
> ../../gcc-5.0-20141107/gcc/wide-int.h:377:3: warning: extraneous
> template parameter list in template specialization
>   template <>
>   ^~~
> ../../gcc-5.0-20141107/gcc/wide-int.h:384:3: warning: extraneous
> template parameter list in template specialization
>   template <>
>   ^~~
> ../../gcc-5.0-20141107/gcc/wide-int.h:394:3: warning: extraneous
> template parameter list in template specialization
>   template <>
>   ^~~
> ../../gcc-5.0-20141107/gcc/wide-int.h:401:3: warning: extraneous
> template parameter list in template specialization
>   template <>
>   ^~~
> ../../gcc-5.0-20141107/gcc/wide-int.h:411:3: warning: extraneous
> template parameter list in template specialization
>   template <>
>   ^~~
> ../../gcc-5.0-20141107/gcc/wide-int.h:422:3: warning: extraneous
> template parameter list in template specialization
>   template <>
>   ^~~
> ../../gcc-5.0-20141107/gcc/wide-int.h:886:3: warning: extraneous
> template parameter list in template specialization
>   template <>
>   ^~~
> ../../gcc-5.0-20141107/gcc/wide-int.h:965:3: warning: extraneous
> template parameter list in template specialization
>   template <>
>   ^~~
> ../../gcc-5.0-20141107/gcc/wide-int.h:1127:1: warning:
> 'fixed_wide_int_storage' defined as a class template here but
> previously declared as a struct template
>   [-Wmismatched-tags]
> class GTY(()) fixed_wide_int_storage
> ^
> ../../gcc-5.0-20141107/gcc/wide-int.h:286:18: note: did you mean class here?
> template  struct fixed_wide_int_storage;
>  ^~
>  class
> ../../gcc-5.0-20141107/gcc/wide-int.h:1152:3: warning: extraneous
> template parameter list in template specialization
>   template <>
>   ^~~
> In file included from ../../gcc-5.0-20141107/gcc/simplify-rtx.c:25:
> In file included from ../../gcc-5.0-20141107/gcc/rtl.h:28:
> In file included from ../../gcc-5.0-20141107/gcc/vec.h:44:
> ../../gcc-5.0-20141107/gcc/ggc.h:315:15: warning: struct 'rtx_def' was
> previously declared as a class [-Wmismatched-tags]
> static inline struct rtx_def *
>   ^
> ../../gcc-5.0-20141107/gcc/coretypes.h:62:7: note: previous use is here
> class rtx_def;
>   ^
> In file included from ../../gcc-5.0-20141107/gcc/simplify-rtx.c:25:
> In file included from ../../gcc-5

Re: RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?

2014-11-10 Thread Tobias Grosser

On 10.11.2014 10:03, Roman Gareev wrote:

The patch looks great. The only piece I think we missed is the
fgraphite-code-generator flag. I would propose to remove it as well in this
commit, as it does not have any effect any more.


In this case, we’ll also have to change tests which use
fgraphite-code-generator flag (isl-ast-gen-blocks-1.c,
isl-ast-gen-blocks-2.c, isl-ast-gen-blocks-3.c,
isl-ast-gen-blocks-4.c, isl-ast-gen-if-1.c, isl-ast-gen-if-2.c,
isl-ast-gen-single-loop-1.c, isl-ast-gen-single-loop-2.c,
isl-ast-gen-user-1.c, isl-codegen-loop-dumping.c). Maybe we should do
this in the next patch?


Sure. We should drop the flag in these test cases.

This seems to make sense, as they now test something different and the 
flag removal would reflect this.


I personally would include this in the same patch. Would this be difficult?

Cheers,
Tobias



Re: [PATCH] Fix PR 63748

2014-11-10 Thread Richard Biener
On Mon, Nov 10, 2014 at 2:33 AM, Patrick Palka 
wrote:
> PR 63748 reports a false-positive uninitialized warning under the
> presence of abnormal edges.  The statements for which the uninitialized
> warnings are emitted all look like:
>
>   buf_117(ab) = buf_317(D)(ab);
>
> This PR is similar to PR 57287 which also reports false-positive
> uninitialized warnings under the presence of abnormal edges.  That PR
> fixed the reported issue by allowing to propagate default definitions
> which appear in abnormal PHI nodes.  That is, it allowed propagating the
> following kinds of copies:
>
>   buf_24 = buf_16(D)(ab);
>
> But it still did not allow propagating copies whose destination operand
> occurs in an abnormal PHI node.  To fix PR 63748, this patch extends the
> fix to PR 57287 to allow propagating such copies too.

Thus you allow

   buf_24(ab) = buf_16(D)(ab);

to be propagated.

This is only valid if you propagate into all uses of buf_24(ab) as otherwise
you create overlapping life-ranges with the default definition.  Which
may be a moot issue now as Marcs patch to ignore undefined SSA names
in the out-of-SSA live compute, thus ...

> Full bootstrap + regtesting on x86_64-unknown-linux-gnu is in progress.
> Is this patch OK if testing succeeds with no new regressions?

... ok.  But please watch for fallout.

Thanks,
Richard.

> 2014-11-10  Patrick Palka  
>
> gcc/
> PR middle-end/63748
> * tree-ssa-propagate.c (may_propagate_copy): Allow propagating
> SSA copies whose source and destination names both occur in
> abnormal edges.
>
> gcc/testsuite/
> PR middle-end/63748
> * gcc.dg/pr63748.c: New testcase.
> ---
>  gcc/testsuite/gcc.dg/pr63748.c | 36 
>  gcc/tree-ssa-propagate.c   | 27 +++
>  2 files changed, 51 insertions(+), 12 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/pr63748.c
>
> diff --git a/gcc/testsuite/gcc.dg/pr63748.c b/gcc/testsuite/gcc.dg/pr63748.c
> new file mode 100644
> index 000..2e50445
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr63748.c
> @@ -0,0 +1,36 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -Wall" } */
> +
> +#include 
> +
> +jmp_buf *alloc_jmp_buf ();
> +int foo (void *);
> +
> +int
> +test (int op, int noside)
> +{
> +  void *argvec = 0;
> +
> +  if (op)
> +{
> +  jmp_buf *buf = alloc_jmp_buf (); /* { dg-bogus "uninitialized" } */
> +  setjmp (*buf);
> +
> +  if (noside)
> +goto nosideret;
> +
> +do_call_it:
> +
> +  if (noside)
> +goto nosideret;
> +
> +  return foo (argvec);
> +}
> +
> +  argvec = __builtin_alloca (1);
> +  goto do_call_it;
> +
> +nosideret:
> +  return 1;
> +}
> +
> diff --git a/gcc/tree-ssa-propagate.c b/gcc/tree-ssa-propagate.c
> index 9f4d381..9e61baf 100644
> --- a/gcc/tree-ssa-propagate.c
> +++ b/gcc/tree-ssa-propagate.c
> @@ -1275,21 +1275,24 @@ may_propagate_copy (tree dest, tree orig)
>tree type_d = TREE_TYPE (dest);
>tree type_o = TREE_TYPE (orig);
>
> -  /* If ORIG flows in from an abnormal edge, it cannot be propagated.  */
> +  /* If ORIG is a default definition which flows in from an abnormal edge
> + then the copy can be propagated.  It is important that we do so to avoid
> + uninitialized regular copies.  */
>if (TREE_CODE (orig) == SSA_NAME
>&& SSA_NAME_OCCURS_IN_ABNORMAL_PHI (orig)
> -  /* If it is the default definition and an automatic variable then
> - we can though and it is important that we do to avoid
> -uninitialized regular copies.  */
> -  && !(SSA_NAME_IS_DEFAULT_DEF (orig)
> -  && (SSA_NAME_VAR (orig) == NULL_TREE
> -  || TREE_CODE (SSA_NAME_VAR (orig)) == VAR_DECL)))
> +  && SSA_NAME_IS_DEFAULT_DEF (orig)
> +  && (SSA_NAME_VAR (orig) == NULL_TREE
> + || TREE_CODE (SSA_NAME_VAR (orig)) == VAR_DECL))
> +;
> +  /* Otherwise if ORIG just flows in from an abnormal edge then the copy 
> cannot
> + be propagated.  */
> +  else if (TREE_CODE (orig) == SSA_NAME
> +  && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (orig))
>  return false;
> -
> -  /* If DEST is an SSA_NAME that flows from an abnormal edge, then it
> - cannot be replaced.  */
> -  if (TREE_CODE (dest) == SSA_NAME
> -  && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (dest))
> +  /* Similarly if DEST flows in from an abnormal edge then the copy cannot be
> + propagated.  */
> +  else if (TREE_CODE (dest) == SSA_NAME
> +  && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (dest))
>  return false;
>
>/* Do not copy between types for which we *do* need a conversion.  */
> --
> 2.2.0.rc0.18.ga1ad247
>


Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto

2014-11-10 Thread Jakub Jelinek
On Mon, Nov 10, 2014 at 12:50:44PM +0100, Richard Biener wrote:
> On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu  wrote:
> > Hi,
> >
> > r216964 disables bootstrap for libcc1 which exposed 2 things:
> >
> > 1. libcc1 isn't compiled with LTO even when GCC is configured with
> > "--with-build-config=bootstrap-lto".  It may be intentional since
> > libcc1 is disabled for bootstrap.
> > 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is
> > compiled with LTO which remembers PIC option.
> 
> Why is this any special to LTO?  If it is then it looks like a LTO
> (driver) issue to me?  Why are we linking the pic libibterty into
> a non-pic libcc1?

I admit I haven't tried LTO bootstrap, but from normal bootstrap logs,
libcc1 is built normally using libtool using -fPIC only, and linked into
libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the
pic/libiberty.a, because we need PIC code in the shared libraries.
So, I don't understand the change at all.

Jakub


Re: [PATCH GCC]Fix checking on MAX_PENDING_LIST_LENGTH

2014-11-10 Thread Richard Biener
On Mon, Nov 10, 2014 at 10:16 AM, Bin Cheng  wrote:
> Hi,
> There is parameter max-pending-list-length in gcc scheduler, but the
> parameter is checked using greater than condition.  As a result, the real
> max pending list length is actually "max-pending-list-length + 1".  This
> patch fixes this by using ">=" rather than ">" comparison operator.  Though
> it is kind of nit-picking, I want to change this: a) it breaks sched-fusion
> because the 33rd couldn't be paired; b) when sched-fusion tries to sort many
> consecutive stores, it breaks dcache line alignment at large probability.  I
> mean without cache sensitive optimizer, GCC breaks dcache line alignment
> randomly, but 33 is definitely worse than 32.  Of course, this only happens
> in very restricted case.
>
> Bootstrap and test on x86_64.  Is it OK?

Ok.

Thanks,
Richard.

> 2014-11-10  Bin Cheng  
>
> * sched-deps.c (sched_analyze_1): Check pending list if it is not
> less than MAX_PENDING_LIST_LENGTH.
> (sched_analyze_2, sched_analyze_insn, deps_analyze_insn): Ditto.


Re: [PATCH] IPA ICF fallout: disable IPA ICF for a test

2014-11-10 Thread Richard Biener
On Mon, Nov 10, 2014 at 11:51 AM, Martin Liška  wrote:
> Hello.
>
> In gcc.dg/tree-ssa/ldist-19.c, there's a pair of functions (one with 'char'
> and second with 'unsigned char'). These two functions are merged by IPA ICF
> on targets that where 'char' == 'unsigned char'. So that it would be easier
> to disable the optimization.
>
> Ready for trunk?

Ok.

Thanks,
Richard.

> Thanks,
> Martin


Re: [PATCH] Fix PR 63748

2014-11-10 Thread Eric Botcazou
> > Full bootstrap + regtesting on x86_64-unknown-linux-gnu is in progress.
> > Is this patch OK if testing succeeds with no new regressions?
> 
> ... ok.  But please watch for fallout.

I'd do a bootstrap with Ada enabled, the Ada compiler is the only serious user 
of abnormal edges in GIMPLE on Linux platforms.

-- 
Eric Botcazou


Re: [PATCH] Fix PR63798

2014-11-10 Thread Václav Zeman
On 10 November 2014 10:55, Richard Biener wrote:
>
>
> The following patch fixes a latent bug uncovered by stmt folding
> that expansion of FMA_EXPR didn't consider the multiplication
> commutative when looking for feeding negates.
>
> Bootstrap & regtest pending.
>
> Richard.
>
> 2014-11-10  Richard Biener  
>
> PR middle-end/63798
> * expr.c (expand_expr_real_2): When expanding FMA_EXPRs
> properly treat the embedded multiplication as commutative
> when looking for feeding negates.
>
> Index: gcc/expr.c
> ===
> --- gcc/expr.c  (revision 217281)
> +++ gcc/expr.c  (working copy)
> @@ -8621,6 +8621,19 @@ expand_expr_real_2 (sepops ops, rtx targ
>   }
>
> def0 = get_def_for_expr (treeop0, NEGATE_EXPR);
> +   /* The multiplication is commutative - look at its 2nd operand
> +  if the first isn't fed by a negate.  */
> +   if (!def0)
> + {
> +   def0 = get_def_for_expr (treeop1, NEGATE_EXPR);
> +   /* Swap operands if the 2nd operand is fed by a negate.  */
> +   if (def0)
> + {
> +   tree tem = treeop0;
> +   treeop0 = treeop1;
> +   treeop1 = tem;

What about using std::swap() maybe?

> + }
> + }
> def2 = get_def_for_expr (treeop2, NEGATE_EXPR);
>
> op0 = op2 = NULL;


-- 
VZ


Re: [RFC] Elimination of zext/sext - type promotion pass

2014-11-10 Thread Richard Biener
On Mon, Nov 10, 2014 at 12:29 AM, Kugan
 wrote:
>
>> Well - the best way would be to expose the target specifics to GIMPLE
>> at some point in the optimization pipeline.  My guess would be that it's
>> appropriate after loop optimizations (but maybe before induction variable
>> optimization).
>>
>> That is, have a pass that applies register promotion to all SSA names
>> in the function, inserting appropriate truncations and extensions.  That
>> way you'd never see (set (subreg...) on RTL.  The VRP and DOM
>> passes running after that pass would then be able to aggressively
>> optimize redundant truncations and extensions.
>>
>> Effects on debug information are to be considered.  You can change
>> the type of SSA names in-place but you don't want to do that for
>> user DECLs (and we can't have the SSA name type and its DECL
>> type differ - and not sure if we might want to lift that restriction).
>
>
> Thanks for the comments. Here is a prototype patch that implements a
> type promotion pass. This pass records SSA variables that will have
> values in higher bits (than the original type precision) if promoted and
> uses this information in inserting appropriate truncations and
> extensions. This pass also classifies some of the stmts that sets ssa's
> to be unsafe to promote. Here is a gimple difference for the type
> promotion as compared to previous dump for a testcase.

Note that while GIMPLE has a way to zero-extend (using BIT_AND_EXPR)
it has no convenient way to sign-extend other than truncating to a signed
(non-promoted) type and then extending to the promoted type.  Thus
I think such pass should be accompanied with a new tree code,
SEXT_EXPR.  Otherwise we end up with "spurious" un-promoted
signed types which later optimizations may be confused about.

Not sure if that is the actual issue though.

Instead op "prmt" and "prmtn" I'd spell out promote and tree-type-prmtn
should be gimple-ssa-type-promote.c.  In the end all targets with
non-trivial PROMOTE_MODE should run the pass as a lowering step
so it should be enabled even at -O0 (and not disablable).

I'd definitely run the pass _after_ pass_lower_vector_ssa (and in the
end I'd like to run it before IVOPTs ... which means moving IVOPTs
later, after VRP which should be the pass optimizing away some of
the extensions).

In get_promoted_type I don't understand why you preserve qualifiers.
Also even for targets without PROMOTE_MODE it may be
beneficial to expose truncations required by expanding bit-precision
arithmetic earlier (that is, if !PROMOTE_MODE at least promote
to GET_MODE_PRECISION (TYPE_MODE (type))).  A testcase
for that is for example

struct { long i : 33; long j : 33; } a;
return a.i + a.j;

where bitfields of type > int do not promote so you get a
33 bit add which we expand to a 64bit add plus a sign-extension
(and nothing optimizes that later usually).

insert_next_bb sounds like you want to use insert_on_edge
somewhere.

in assign_rhs_promotable_p you handle comparisons special
but the ternary COND_EXPR and VEC_COND_EXPR can have
comparisons embedded in their first operand.  The comment
confuses me though - with proper sign- or zero-extensions inserted
you should be able to promote them anyway?

You seem to miss that a GIMPLE_ASSIGN can have 3 operands
in promote_cst_in_stmt as well.

In promote_assign_stmt_use I consider a default: case that ends
up doing nothing dangerous ;)  Please either use gcc_unreachable ()
or do the safe thing (fix = true;?).  You seem to be working with
a lattice of some kind - fixing up stmt uses the way you do - walking
over immediate uses - is not very cache friendly.  Why not use
a lattice for this - record promoted vars to be used for old SSA names
and walk over all stmts instead, replacing SSA uses on them?
Btw, you don't need to call update_stmt if you SET_USE and not
replace an SSA name with a constant.

You seem to "fix" with a single stmt but I don't see where you insert
zero- or sign-extensions for ssa_overflows_p cases?

Note that at least for SSA names with !SSA_NAME_VAR (thus
anonymous vars) you want to do a cheaper promotion by not
allocating a new SSA name but simply "fixing" its type by
assigning to its TREE_TYPE.   For SSA names with SSA_NAME_VAR
there is of course debug-info to consider and thus doing what you
do is better (but probably still will wreck debuginfo?).

GIMPLE_NOPs are not only used for parameters but also uninitialized
uses - for non-parameters you should simply adjust their type.  No
need to fixup their value.

The pass needs more comments.

It looks like you are not promoting all variables but only those
where compensation code (zero-/sign-extensions) is not necessary?

Thanks for trying to work on this.
Richard.

>  crc2 (short unsigned int crc, unsigned char data)
>  {
>unsigned char carry;
>unsigned char x16;
>unsigned char i;
> -  unsigned char ivtmp_5;
> +  unsigned int _2;
> +  unsigned char _3;
> +  unsigned int _4;
> +  unsigned int _5;
>unsigned ch

[PATCH] Plug SSA stmt operand leak

2014-11-10 Thread Richard Biener

The following patch plugs a leak in SSA stmt operands.  finalize_ssa_uses
always frees all old operands and then allocates new ones - but in
freeing the old operands it only inserts the first freed one into
the freelist.  The following patch makes us use the same trick
as free_stmt_operands to link all old uses to the freelist.

As the stmt operands have their own allocator and we dispose
of its memory in one-go (per function) it may not be a too
big deal - but SSA form is live for a lot of functions at the
same time.

I was of course working on sth else here that requires not
throwing away the old uses unconditionally for efficiency
but the patch applies to active branches as well which is
why I am testing the fix anyway.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

Richard.

2014-11-10  Richard Biener  

* tree-ssa-operands.c (finalize_ssa_uses): Properly put
released operands on the free list.

Index: gcc/tree-ssa-operands.c
===
--- gcc/tree-ssa-operands.c (revision 216973)
+++ gcc/tree-ssa-operands.c (working copy)
@@ -409,9 +410,10 @@ finalize_ssa_uses (struct function *fn,
   /* If there is anything in the old list, free it.  */
   if (old_ops)
 {
-  for (ptr = old_ops; ptr; ptr = ptr->next)
+  for (ptr = old_ops; ptr->next; ptr = ptr->next)
delink_imm_use (USE_OP_PTR (ptr));
-  old_ops->next = gimple_ssa_operands (fn)->free_uses;
+  delink_imm_use (USE_OP_PTR (ptr));
+  ptr->next = gimple_ssa_operands (fn)->free_uses;
   gimple_ssa_operands (fn)->free_uses = old_ops;
 }
 



Re: [PATCH][Revisedx2] Fix PR63750

2014-11-10 Thread Ilya Enkovich
2014-11-10 14:53 GMT+03:00 Richard Biener :
> On Sun, Nov 9, 2014 at 5:57 PM, Jack Howarth  wrote:
>> Iain,
>>  It doesn't look like it will be that simple. If I replace the
>> proposed patches with a change like...
>>
>> Index: gcc/system.h
>> ===
>> --- gcc/system.h(revision 217238)
>> +++ gcc/system.h(working copy)
>> @@ -194,6 +194,13 @@ extern int fprintf_unlocked (FILE *, con
>>  #undef fread_unlocked
>>  #undef fwrite_unlocked
>>
>> +/* Include  before "safe-ctype.h" to avoid avoid GCC poisoning
>> +the ctype macros through safe-ctype.h */
>> +
>> +#ifdef __cplusplus
>> +# include 
>> +#endif
>> +
>
> Indeed  is a system header and should not have been included
> from tree-chkp.c but system.h.

Since attempt to put it into system.h causes such errors I may just
get rid of string usage in ipa-chkp.c at all.  It's not hardly used.

Ilya

>
> Richard.
>
>>  /* There are an extraordinary number of issues with .
>> The last straw is that it varies with the locale.  Use libiberty's
>> replacement instead.  */
>>
>> The bootstrap fails at a new place with...
>>
>> make[3]: Entering directory
>> '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc'
>> g++ -c   -g  -DIN_GCC-fno-exceptions -fno-rtti
>> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
>> -Wcast-qual -Wno-format -Wmissing-format-attribute
>> -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
>> -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I.
>> -I../../gcc-5.0-20141107/gcc -I../../gcc-5.0-20141107/gcc/.
>> -I../../gcc-5.0-20141107/gcc/../include
>> -I../../gcc-5.0-20141107/gcc/../libcpp/include -I/sw/include
>> -I/sw/include  -I../../gcc-5.0-20141107/gcc/../libdecnumber
>> -I../../gcc-5.0-20141107/gcc/../libdecnumber/dpd -I../libdecnumber
>> -I../../gcc-5.0-20141107/gcc/../libbacktrace -DCLOOG_INT_GMP
>> -I/sw/include -DCLOOG_INT_GMP -I/sw/include -I/sw/include -o
>> simplify-rtx.o -MT simplify-rtx.o -MMD -MP -MF
>> ./.deps/simplify-rtx.TPo ../../gcc-5.0-20141107/gcc/simplify-rtx.c
>> clang: warning: treating 'c' input as 'c++' when in C++ mode, this
>> behavior is deprecated
>> In file included from ../../gcc-5.0-20141107/gcc/simplify-rtx.c:23:
>> ../../gcc-5.0-20141107/gcc/coretypes.h:62:1: warning: class 'rtx_def'
>> was previously declared as a struct [-Wmismatched-tags]
>> class rtx_def;
>> ^
>> ../../gcc-5.0-20141107/gcc/coretypes.h:55:8: note: previous use is here
>> struct rtx_def;
>>^
>> In file included from ../../gcc-5.0-20141107/gcc/simplify-rtx.c:25:
>> In file included from ../../gcc-5.0-20141107/gcc/rtl.h:27:
>> In file included from ../../gcc-5.0-20141107/gcc/real.h:25:
>> ../../gcc-5.0-20141107/gcc/wide-int.h:370:3: warning: extraneous
>> template parameter list in template specialization
>>   template <>
>>   ^~~
>> ../../gcc-5.0-20141107/gcc/wide-int.h:377:3: warning: extraneous
>> template parameter list in template specialization
>>   template <>
>>   ^~~
>> ../../gcc-5.0-20141107/gcc/wide-int.h:384:3: warning: extraneous
>> template parameter list in template specialization
>>   template <>
>>   ^~~
>> ../../gcc-5.0-20141107/gcc/wide-int.h:394:3: warning: extraneous
>> template parameter list in template specialization
>>   template <>
>>   ^~~
>> ../../gcc-5.0-20141107/gcc/wide-int.h:401:3: warning: extraneous
>> template parameter list in template specialization
>>   template <>
>>   ^~~
>> ../../gcc-5.0-20141107/gcc/wide-int.h:411:3: warning: extraneous
>> template parameter list in template specialization
>>   template <>
>>   ^~~
>> ../../gcc-5.0-20141107/gcc/wide-int.h:422:3: warning: extraneous
>> template parameter list in template specialization
>>   template <>
>>   ^~~
>> ../../gcc-5.0-20141107/gcc/wide-int.h:886:3: warning: extraneous
>> template parameter list in template specialization
>>   template <>
>>   ^~~
>> ../../gcc-5.0-20141107/gcc/wide-int.h:965:3: warning: extraneous
>> template parameter list in template specialization
>>   template <>
>>   ^~~
>> ../../gcc-5.0-20141107/gcc/wide-int.h:1127:1: warning:
>> 'fixed_wide_int_storage' defined as a class template here but
>> previously declared as a struct template
>>   [-Wmismatched-tags]
>> class GTY(()) fixed_wide_int_storage
>> ^
>> ../../gcc-5.0-20141107/gcc/wide-int.h:286:18: note: did you mean class here?
>> template  struct fixed_wide_int_storage;
>>  ^~
>>  class
>> ../../gcc-5.0-20141107/gcc/wide-int.h:1152:3: warning: extraneous
>> template parameter list in template specialization
>>   template <>
>>   ^~~
>> In file included from ../../gcc-5.0-20141107/gcc/simplify-rtx.c:25:
>> In file included from ../../gcc-5.0-20141107/gcc/rtl.h:28:
>> In file included from ../../gcc-5.0-20141107/gcc/vec.h:44:
>> ../../gcc-5.0-20141107/gcc/ggc.h:315:15: warning: struct 'rtx_def' was
>>

Re: [PATCH 7/8] Model cache auto-prefetcher in scheduler

2014-11-10 Thread Maxim Kuvyrkov
On Oct 21, 2014, at 8:06 AM, Maxim Kuvyrkov  wrote:

> Hi,
> 
> This patch adds auto-prefetcher modeling to GCC scheduler.  The 
> auto-prefetcher model is currently enabled only for ARM Cortex-A15, since 
> this is the only CPU that I know of to have the hardware auto-prefetcher unit.
> 
> The documentation on the auto-prefetcher is very sparse, and all I have are 
> my empirical studies and a short note in Cortex-A15 manual (search for "L2 
> cache auto-prefether").  This patch, therefore, implements a very abstract 
> model that makes scheduler prefer "mem_op (base+8); mem_op (base+12)" over 
> "mem_op (base+12); mem_op (base+8)".  In other words, memory operations are 
> tried to be issued in order of increasing memory offsets.
> 
> The auto-prefetcher model implementation is based on max_issue mutlipass 
> lookahead scheduling, and its "guard" hook.  The guard hook examines contents 
> of the ready list and the queue, and, if it finds instructions with lower 
> memory offsets, marks instructions with higher memory offset as unavailable 
> for immediate scheduling.
> 
> This patch has been in works since beginning of the year, and many of my 
> previous scheduler cleanup patches were to prepare the infrastructure for 
> this feature. 
> 
> Ramana, this change requires benchmarking, which I can't easily do at the 
> moment.  I would appreciate any benchmarking results that you can share.  In 
> particular, the value of PARAM_SCHED_AUTOPREF_QUEUE_DEPTH needs to be 
> tuned/confirmed for Cortex-A15.
> 
> At the moment the parameter is set to "2", which means that the autopref 
> model will look through ready list and 1-stall queue in search of relevant 
> instructions.  Values of -1 (disable autopref), 0 (use autopref only in 
> rank_for_schedule), 1 (look through ready list), 2 (look through ready list 
> and 1-stall queue), and 3 (look through ready list and 2-stall queue) should 
> be considered and benchmarked.
> 
> Bootstrapped on x86_64-linux-gnu and regtested on arm-linux-gnueaihf and 
> aarch64-linux-gnu.  OK to apply, provided no performance or correctness 
> regressions?
> 
> [ChangeLog is part of the git patch]

Ping?

All prerequisite patches for this one are now approved and [mostly] checked in. 
 This is the last outstanding item from my patch series to improve scheduling.

Thank you,

--
Maxim Kuvyrkov
www.linaro.org



Re: Fix libgomp crash without TLS (PR42616)

2014-11-10 Thread Varvara Rainchik
*Ping*

2014-10-13 14:48 GMT+04:00 Varvara Rainchik :
>> Now, I wonder on which OS and why does config/tls.m4 CHECK_GCC_TLS
>> actually fail?  Can you figure that out?
>>
>
> On Android check passes with --disable-tls (standard while building
> gcc for Android as TLS is not supported in bionic) and fails with
> --enable-tls (i686-linux-android/libgomp/conftest.c:32: undefined
> reference to `___tls_get_addr'). So, HAVE_TLS is not defined in both
> cases.
>
>> If we get rid of HAVE_TLS code altogether, we might lose support of
>> some very old OSes, e.g. some Linux distros with a recent gcc and binutils
>> (so that emutls isn't used), but very old glibc (that doesn't support
>> TLS or supports it incorrectly, think of pre-2002 glibc).  So, if we get
>> rid of !HAVE_TLS code in libgomp, it would be nice if config/tls.m4 detected
>> it properly and we'd just fail at configure time.
>
> How can we check this in config/tls.m4? Can we just combine tests on
> TLS and emutls? E.g. check whether HAVE_TLS and USE_EMUTLS are both
> defined.
>
>> And if we don't, just make sure that on Android, Darwin and/or M$Win (or
>> whatever other OS you had in mind which does support pthreads, but doesn't
>> support native TLS) find out why HAVE_AS_TLS is not defined (guess
>> config.log should explain that).
>
> HAVE_AS_TLS is also not defined for Android as it depends on --enable-tls.


Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto

2014-11-10 Thread H.J. Lu
On Mon, Nov 10, 2014 at 4:05 AM, Jakub Jelinek  wrote:
> On Mon, Nov 10, 2014 at 12:50:44PM +0100, Richard Biener wrote:
>> On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu  wrote:
>> > Hi,
>> >
>> > r216964 disables bootstrap for libcc1 which exposed 2 things:
>> >
>> > 1. libcc1 isn't compiled with LTO even when GCC is configured with
>> > "--with-build-config=bootstrap-lto".  It may be intentional since
>> > libcc1 is disabled for bootstrap.
>> > 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is
>> > compiled with LTO which remembers PIC option.
>>
>> Why is this any special to LTO?  If it is then it looks like a LTO
>> (driver) issue to me?  Why are we linking the pic libibterty into
>> a non-pic libcc1?
>
> I admit I haven't tried LTO bootstrap, but from normal bootstrap logs,
> libcc1 is built normally using libtool using -fPIC only, and linked into
> libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the
> pic/libiberty.a, because we need PIC code in the shared libraries.
> So, I don't understand the change at all.
>
> Jakub

This is the command line to build libcc1.la:

/bin/sh ./libtool --tag=CXX   --mode=link
/export/project/git/gcc-regression-bootstrap/master/216981/bld/./gcc/xg++
-B/export/project/git/gcc-regression-bootstrap/master/216981/bld/./gcc/
-nostdinc++ `if test -f
/export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags;
then /bin/sh 
/export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags
--build-includes; else echo -funconfigured-libstdc++-v3 ; fi`
-L/export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/export/project/git/gcc-regression-bootstrap/master/216981/usr/x86_64-unknown-linux-gnu/bin/
-B/export/project/git/gcc-regression-bootstrap/master/216981/usr/x86_64-unknown-linux-gnu/lib/
-isystem 
/export/project/git/gcc-regression-bootstrap/master/216981/usr/x86_64-unknown-linux-gnu/include
-isystem 
/export/project/git/gcc-regression-bootstrap/master/216981/usr/x86_64-unknown-linux-gnu/sys-include
   -W -Wall  -fvisibility=hidden -g -O2 -D_GNU_SOURCE -module
-export-symbols
/export/project/git/gcc-regression/gcc/libcc1/libcc1.sym  -Xcompiler
'-static-libstdc++' -Xcompiler '-static-libgcc' -o libcc1.la -rpath
/export/project/git/gcc-regression-bootstrap/master/216981/usr/lib/../lib64
findcomp.lo libcc1.lo names.lo callbacks.lo connection.lo marshall.lo
-Wc,../libiberty/pic/libiberty.a

There are no -fPIC nor any other options, like -O2.  Since *.lo aren't
compiled with LTO
and libiberty/pic/libiberty.a is compiled with LTO, linker uses
libtool command line to
compile libiberty/pic/libiberty.a  LTO IR into regular object.   Since
libtool command line
doesn't have -fPIC, it fails to create shared object.  Since it
doesn't have -O2, it isn't
optimized and misses other options.

Both ld and gold pull the compiler options from the first .o file with
LTO IR.  We can
argue if linker should pull compiler option from the first LTO IR in
.o and .a.  But it
doesn't happen today and may not be desirable at all.

-- 
H.J.


[match-and-simplify] operator-lists in expression

2014-11-10 Thread Prathamesh Kulkarni
Hi,
  This patch adds support for operator-lists to be used in expression.

I reuse operator-list as the iterator. This is not really valid since
user-defined operator-lists cannot be iterator in 'for', but it was
convenient to reuse operator-list as a 'for' iterator
and lower_for doesn't care about that.
eg:
(define_operator_list  list1 plus minus)

(simplify
  (list1 @x integer_zerop)
  (non_lvalue @x))

is wrapped into 'for' as: (lower_operator_list):
(for list1 (plus minus)
  (simplify
(list1 @x integer_zerop)
(non_lvalue @x)))

this is not really valid since we reject list1 to be used as iterator if
it were written by user.

Is this okay or should I introduce an explicit temporary iterator ?
so it gets lowered to something like:
(for tmp1 (list1)
  (simplify
(tmp1 @x integer_zerop)
(non_lvalue @x)))

* genmatch.c
  (fatal_at): New overloaded function.
  (simplify::oper_lists): New member.
  (simplify::simplify): Add default argument.
  (lower_commutative): Adjust call to simplify::simplify.
  (lower_opt_convert): Likewise.
  (lower_operator_list): New function.
  (lower): Call lower_operator_list.
  (parser::parsing_for_p): New member function.
  (parser::oper_lists): New member.
  (parser::parse_operation): Check for operator-list.
  (parser::parse_c_expr): Likewise.
  (parser::parse_simplify): Reset parser::oper_lists.
Adjust call to simplify::simplify.
  (parser::parser): Initialize parser::oper_lists.

* match-builtin.pd:
  Adjust patten to use SQRTs and POWs.

Thanks,
Prathamesh
Index: gcc/genmatch.c
===
--- gcc/genmatch.c	(revision 217284)
+++ gcc/genmatch.c	(working copy)
@@ -110,6 +110,18 @@
 #if GCC_VERSION >= 4001
 __attribute__((format (printf, 2, 3)))
 #endif
+fatal_at (source_location loc, const char *msg, ...)
+{
+  va_list ap;
+  va_start (ap, msg);
+  error_cb (NULL, CPP_DL_FATAL, 0, loc, 0, msg, &ap);
+  va_end (ap);
+}
+
+static void
+#if GCC_VERSION >= 4001
+__attribute__((format (printf, 2, 3)))
+#endif
 warning_at (const cpp_token *tk, const char *msg, ...)
 {
   va_list ap;
@@ -549,11 +561,11 @@
   simplify (operand *match_, source_location match_location_,
 	struct operand *result_, source_location result_location_,
 	vec ifexpr_vec_, vec > for_vec_,
-	cid_map_t *capture_ids_)
+	cid_map_t *capture_ids_, vec oper_lists_ = vNULL)
   : match (match_), match_location (match_location_),
   result (result_), result_location (result_location_),
   ifexpr_vec (ifexpr_vec_), for_vec (for_vec_),
-  capture_ids (capture_ids_), capture_max (capture_ids_->elements () - 1) {}
+  capture_ids (capture_ids_), capture_max (capture_ids_->elements () - 1), oper_lists (oper_lists_) {}
 
   /* The expression that is matched against the GENERIC or GIMPLE IL.  */
   operand *match;
@@ -572,6 +584,8 @@
   /* A map of capture identifiers to indexes.  */
   cid_map_t *capture_ids;
   int capture_max;
+  /* collected operator-list used in expression */
+  vec oper_lists;
 };
 
 /* Debugging routines for dumping the AST.  */
@@ -721,7 +735,7 @@
 {
   simplify *ns = new simplify (matchers[i], s->match_location,
    s->result, s->result_location, s->ifexpr_vec,
-   s->for_vec, s->capture_ids);
+   s->for_vec, s->capture_ids, s->oper_lists);
   simplifiers.safe_push (ns);
 }
 }
@@ -837,7 +851,7 @@
 {
   simplify *ns = new simplify (matchers[i], s->match_location,
    s->result, s->result_location, s->ifexpr_vec,
-   s->for_vec, s->capture_ids);
+   s->for_vec, s->capture_ids, s->oper_lists);
   simplifiers.safe_push (ns);
 }
 }
@@ -934,6 +948,38 @@
 simplifiers.safe_push (worklist[i]);
 }
 
+static void
+lower_operator_list (simplify *s, vec& simplifiers)
+{
+  vec oper_lists = s->oper_lists;
+  if (oper_lists == vNULL)
+{
+  simplifiers.safe_push (s);
+  return;
+} 
+
+  unsigned min = oper_lists[0]->substitutes.length ();
+  for (unsigned i = 1; i < oper_lists.length (); ++i)
+if (min > oper_lists[i]->substitutes.length ())
+  min = oper_lists[i]->substitutes.length ();
+
+  for (unsigned i = 0; i < oper_lists.length (); ++i)
+if (oper_lists[i]->substitutes.length () % min != 0)
+  fatal_at (s->match_location, "All user-defined identifiers must have a multiple number "
+   "of operator substittions of the smallest number of substitutions");
+
+  vec< vec > for_vec = vNULL;
+  for_vec.safe_push (oper_lists);
+
+  simplify ns (s->match, s->match_location,
+	   s->result, s->result_location,
+	   s->ifexpr_vec, for_vec,
+	   s->capture_ids);
+
+  lower_for (&ns, simplifiers);
+}
+
+
 /* Lower the AST for everything in SIMPLIFIERS.  */
 
 static void
@@ -947,14 +993,15 @@
   for (unsigned i = 0; i < out_simplifiers0.length (); ++i)
 lower_commutative (out_simplifiers0[i], out_simplifiers1);
 
+  auto_vec out_simplifiers2;
+  for (unsigned i = 0;  i < out_simplifiers1.length (); ++i)
+

Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto

2014-11-10 Thread Jakub Jelinek
On Mon, Nov 10, 2014 at 05:32:32AM -0800, H.J. Lu wrote:
> On Mon, Nov 10, 2014 at 4:05 AM, Jakub Jelinek  wrote:
> > On Mon, Nov 10, 2014 at 12:50:44PM +0100, Richard Biener wrote:
> >> On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu  wrote:
> >> > Hi,
> >> >
> >> > r216964 disables bootstrap for libcc1 which exposed 2 things:
> >> >
> >> > 1. libcc1 isn't compiled with LTO even when GCC is configured with
> >> > "--with-build-config=bootstrap-lto".  It may be intentional since
> >> > libcc1 is disabled for bootstrap.
> >> > 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is
> >> > compiled with LTO which remembers PIC option.
> >>
> >> Why is this any special to LTO?  If it is then it looks like a LTO
> >> (driver) issue to me?  Why are we linking the pic libibterty into
> >> a non-pic libcc1?
> >
> > I admit I haven't tried LTO bootstrap, but from normal bootstrap logs,
> > libcc1 is built normally using libtool using -fPIC only, and linked into
> > libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the
> > pic/libiberty.a, because we need PIC code in the shared libraries.
> > So, I don't understand the change at all.
> >
> > Jakub
> 
> This is the command line to build libcc1.la:

Sure, but there was -fPIC used to compile all the *.o files that are being
linked into libcc1.so, so LTO should know that.

Jakub


Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto

2014-11-10 Thread Richard Biener
On Mon, Nov 10, 2014 at 2:43 PM, Jakub Jelinek  wrote:
> On Mon, Nov 10, 2014 at 05:32:32AM -0800, H.J. Lu wrote:
>> On Mon, Nov 10, 2014 at 4:05 AM, Jakub Jelinek  wrote:
>> > On Mon, Nov 10, 2014 at 12:50:44PM +0100, Richard Biener wrote:
>> >> On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu  wrote:
>> >> > Hi,
>> >> >
>> >> > r216964 disables bootstrap for libcc1 which exposed 2 things:
>> >> >
>> >> > 1. libcc1 isn't compiled with LTO even when GCC is configured with
>> >> > "--with-build-config=bootstrap-lto".  It may be intentional since
>> >> > libcc1 is disabled for bootstrap.
>> >> > 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is
>> >> > compiled with LTO which remembers PIC option.
>> >>
>> >> Why is this any special to LTO?  If it is then it looks like a LTO
>> >> (driver) issue to me?  Why are we linking the pic libibterty into
>> >> a non-pic libcc1?
>> >
>> > I admit I haven't tried LTO bootstrap, but from normal bootstrap logs,
>> > libcc1 is built normally using libtool using -fPIC only, and linked into
>> > libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the
>> > pic/libiberty.a, because we need PIC code in the shared libraries.
>> > So, I don't understand the change at all.
>> >
>> > Jakub
>>
>> This is the command line to build libcc1.la:
>
> Sure, but there was -fPIC used to compile all the *.o files that are being
> linked into libcc1.so, so LTO should know that.

And it does.  If not please file a bug with a smaller testcase than libcc1
and libiberty.

Richard.

> Jakub


Re: [PATCH] Fix PR 63748

2014-11-10 Thread Patrick Palka
On Mon, Nov 10, 2014 at 7:22 AM, Eric Botcazou  wrote:
>> > Full bootstrap + regtesting on x86_64-unknown-linux-gnu is in progress.
>> > Is this patch OK if testing succeeds with no new regressions?
>>
>> ... ok.  But please watch for fallout.
>
> I'd do a bootstrap with Ada enabled, the Ada compiler is the only serious user
> of abnormal edges in GIMPLE on Linux platforms.
>
> --
> Eric Botcazou

Bootstrap (with --enable-languages=all,ada) + regtesting has finished
with no new regressions.  I will commit this later today when I have
more free time ahead of me.  Thanks for reviewing.


Re: [gofrontend-dev] [PATCH 4/4] Gccgo port to s390[x] -- part II

2014-11-10 Thread Dominik Vogt
> I'd still like to avoid the rampant duplication if possible.  One
> approach would be to put most of the test in something like
> nilptr_tests.go marked with "// skip".  Then we can have top-level
> nilptrXX.go tests with +build lines that use "// run nilptr_tests.go".

I fail to see how that could be done with "// run".  There is one
example use, namely cmplxdivide.go".  That is not run in gcc
because the "run" line does not match anything in go-test.exp.  If
I add a rule for that, how does that help me to compile a test
that consists of multiple files?

At the moment, I've no idea how to tackle the multi file problem
with the existing go-test.exp.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany



Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto

2014-11-10 Thread Jakub Jelinek
On Mon, Nov 10, 2014 at 02:44:55PM +0100, Richard Biener wrote:
> >> > I admit I haven't tried LTO bootstrap, but from normal bootstrap logs,
> >> > libcc1 is built normally using libtool using -fPIC only, and linked into
> >> > libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the
> >> > pic/libiberty.a, because we need PIC code in the shared libraries.
> >> > So, I don't understand the change at all.
> >> >
> >> > Jakub
> >>
> >> This is the command line to build libcc1.la:
> >
> > Sure, but there was -fPIC used to compile all the *.o files that are being
> > linked into libcc1.so, so LTO should know that.
> 
> And it does.  If not please file a bug with a smaller testcase than libcc1
> and libiberty.

Ah, supposedly we should add $(POSTSTAGE1_HOST_EXPORTS) after $(HOST_EXPORTS)
to the libcc1 rules iff the libcc1 module is built by the newly built
bootstrapped compiler (but not when the compiler is not bootstrapped and
thus it is built by the host compiler), because if we first bootstrap the
compiler and build libcc1 by stage3, it is really post-stage1 building.

Paolo, any thoughts how to arrange that?

Jakub


[PATCH] Fix PR63800

2014-11-10 Thread Richard Biener

This fixes PR63800 which shows that PRE eliminate() avail handling
is too simplistic with the code to avoid vectorization regressions.
The following patch makes it properly restore old availability.

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

Richard.

2014-11-10  Richard Biener  

PR tree-optimization/63800
* tree-ssa-pre.c (eliminate_push_avail): Push in a way so
we can restore the previous availability in after_dom_children.
(eliminate_dom_walker::after_dom_children): Restore
previous availability.

* gcc.dg/torture/pr63800.c: New testcase.

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 216973)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -3904,8 +3926,11 @@ eliminate_push_avail (tree op)
 {
   if (el_avail.length () <= SSA_NAME_VERSION (valnum))
el_avail.safe_grow_cleared (SSA_NAME_VERSION (valnum) + 1);
+  tree pushop = op;
+  if (el_avail[SSA_NAME_VERSION (valnum)])
+   pushop = el_avail[SSA_NAME_VERSION (valnum)];
+  el_avail_stack.safe_push (pushop);
   el_avail[SSA_NAME_VERSION (valnum)] = op;
-  el_avail_stack.safe_push (op);
 }
 }
 
@@ -4449,7 +4468,14 @@ eliminate_dom_walker::after_dom_children
 {
   tree entry;
   while ((entry = el_avail_stack.pop ()) != NULL_TREE)
-el_avail[SSA_NAME_VERSION (VN_INFO (entry)->valnum)] = NULL_TREE;
+{
+  tree valnum = VN_INFO (entry)->valnum;
+  tree old = el_avail[SSA_NAME_VERSION (valnum)];
+  if (old == entry)
+   el_avail[SSA_NAME_VERSION (valnum)] = NULL_TREE;
+  else
+   el_avail[SSA_NAME_VERSION (valnum)] = entry;
+}
 }
 
 /* Eliminate fully redundant computations.  */
Index: gcc/testsuite/gcc.dg/torture/pr63800.c
===
--- gcc/testsuite/gcc.dg/torture/pr63800.c  (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr63800.c  (working copy)
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+
+int a, b, c, d[2];
+
+int
+fn1 ()
+{
+  int f = 0;
+  d[1] = b = 1; 
+  for (; b; b--)
+{
+  for (c = 0; c < 2; c++)
+   {
+ d[b] & 1 & b;
+ if (d[0])
+   f = d[b] * a;
+ if (f)
+   return 0;
+   }
+  d[b] && (d[0] = 0);
+}
+  return 0;
+}


Re: [PATCH 3/4] Add libgomp plugin for Intel MIC

2014-11-10 Thread Ilya Verbin
On 06 Nov 19:25, Jakub Jelinek wrote:
> Oh, one more point, if mic_lib_path is NULL, what is the point
> to do the alloca/malloc and string copying?  Can't you just
>   setenv (MIC_LD_LIBRARY_PATH_ENV, ld_lib_path, 1);
> in that case early?
> 
> Otherwise LGTM.

Done.

Thanks,
  -- Ilya


---

diff --git a/liboffloadmic/configure.ac b/liboffloadmic/configure.ac
index fb575b3..81fae8f 100644
--- a/liboffloadmic/configure.ac
+++ b/liboffloadmic/configure.ac
@@ -42,6 +42,7 @@ AC_PROG_CC
 AC_PROG_CXX
 AC_CONFIG_FILES([Makefile liboffloadmic_host.spec liboffloadmic_target.spec])
 AM_ENABLE_MULTILIB(, ..)
+AC_CONFIG_SUBDIRS(plugin)
 AC_FUNC_ALLOCA
 AC_CHECK_HEADERS([mm_malloc.h], [], [AC_MSG_ERROR(["Couldn't find 
mm_malloc.h"])])
 AC_CHECK_FUNCS([__secure_getenv secure_getenv])
diff --git a/liboffloadmic/plugin/Makefile.am b/liboffloadmic/plugin/Makefile.am
new file mode 100644
index 000..0baf70d
--- /dev/null
+++ b/liboffloadmic/plugin/Makefile.am
@@ -0,0 +1,123 @@
+# Plugin for offload execution on Intel MIC devices.
+#
+# Copyright (C) 2014 Free Software Foundation, Inc.
+#
+# Contributed by Ilya Verbin  and
+# Andrey Turetskiy .
+#
+# This file is part of the GNU OpenMP Library (libgomp).
+#
+# Libgomp is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# Libgomp is distributed in the hope that it will be useful, but WITHOUT ANY
+# WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
+# FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+# more details.
+#
+# Under Section 7 of GPL version 3, you are granted additional
+# permissions described in the GCC Runtime Library Exception, version
+# 3.1, as published by the Free Software Foundation.
+#
+# You should have received a copy of the GNU General Public License and
+# a copy of the GCC Runtime Library Exception along with this program;
+# see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+# .
+
+
+AUTOMAKE_OPTIONS = foreign
+ACLOCAL_AMFLAGS = -I ../.. -I ../../config
+
+# Directories
+build_dir = $(top_builddir)
+source_dir = $(top_srcdir)
+coi_inc_dir = $(top_srcdir)/../include/coi
+myo_inc_dir = $(top_srcdir)/../include/myo
+libgomp_src_dir = $(top_srcdir)/../../libgomp
+libgomp_dir = $(build_dir)/../../libgomp
+liboffload_src_dir = $(top_srcdir)/../runtime
+liboffload_dir = $(top_builddir)/..
+
+# May be used by toolexeclibdir.
+gcc_version := $(shell cat $(top_srcdir)/../../gcc/BASE-VER)
+libsubincludedir = 
$(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include
+# Search for main_target_image.h in these directories
+target_prefix_dir = $(libdir)/gcc/$(accel_target)/$(gcc_version)$(MULTISUBDIR)
+target_build_dir = 
$(accel_search_dir)/$(accel_target)$(MULTISUBDIR)/liboffloadmic/plugin
+target_install_dir = 
$(accel_search_dir)/lib/gcc/$(accel_target)/$(gcc_version)$(MULTISUBDIR)
+
+if PLUGIN_HOST
+  toolexeclib_LTLIBRARIES = libgomp-plugin-intelmic.la
+  libgomp_plugin_intelmic_la_SOURCES = libgomp-plugin-intelmic.cpp
+  libgomp_plugin_intelmic_la_CPPFLAGS = $(CPPFLAGS) -DLINUX 
-DCOI_LIBRARY_VERSION=2 -DMYO_SUPPORT -DOFFLOAD_DEBUG=1 -DSEP_SUPPORT 
-DTIMING_SUPPORT -DHOST_LIBRARY=1 -I$(coi_inc_dir) -I$(myo_inc_dir) 
-I$(liboffload_src_dir) -I$(libgomp_src_dir) -I$(libgomp_dir) 
-I$(target_prefix_dir)/include -I$(target_build_dir) 
-I$(target_install_dir)/include
+  libgomp_plugin_intelmic_la_LDFLAGS = -L$(liboffload_dir)/.libs 
-loffloadmic_host -version-info 1:0:0
+else # PLUGIN_TARGET
+  plugin_includedir = $(libsubincludedir)
+  plugin_include_HEADERS = main_target_image.h
+  AM_CPPFLAGS = $(CPPFLAGS) -DLINUX -DCOI_LIBRARY_VERSION=2 -DMYO_SUPPORT 
-DOFFLOAD_DEBUG=1 -DSEP_SUPPORT -DTIMING_SUPPORT -DHOST_LIBRARY=0 
-I$(coi_inc_dir) -I$(myo_inc_dir) -I$(liboffload_src_dir) -I$(libgomp_dir)
+  AM_CXXFLAGS = $(CXXFLAGS)
+  AM_LDFLAGS = -L$(liboffload_dir)/.libs -L$(libgomp_dir)/.libs 
-loffloadmic_target -lcoi_device -lmyo-service -lgomp -rdynamic
+endif
+
+main_target_image.h: offload_target_main
+   @echo -n "const int image_size = " > $@
+   @stat -c '%s' $< >> $@
+   @echo ";" >> $@
+   @echo "struct MainTargetImage {" >> $@
+   @echo "  int64_t size;" >> $@
+   @echo "  char name[sizeof \"offload_target_main\"];" >> $@
+   @echo "  char data[image_size];" >> $@
+   @echo "};" >> $@
+   @echo "extern \"C\" const MainTargetImage main_target_image = {" >> $@
+   @echo "  image_size, \"offload_target_main\"," >> $@
+   @cat $< | xxd -include >> $@
+   @echo "};" >> $@
+
+offload_target_main: $(liboffload_dir)/ofldbegin.o offload_target_main.o 
$(liboffload_dir)/ofldend.o
+   $(CXX) $(AM_LDFLAGS) $^ -o $@
+
+offload_target_main.o: offload_target_main.cpp
+   $(CXX) $(AM_CXXFLAGS) $(AM_CPPFLAGS) -c $< -o $@
+
+# Work around what a

Re: Ping: FR-V rtx iterator patches

2014-11-10 Thread Nicholas Clifton

Hi Richard,


Ping for these FR-V patches:

https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02645.html
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02646.html
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02647.html
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02648.html

which convert callers of for_each_rtx to the new rtx iterators in
rtl-iter.h.  (These are the only uses of for_each_rtx left -- thanks
for all the reviews to get this far.)


Sorry for missing these.  The patches are fine - please apply.

Cheers
  Nick




Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

2014-11-10 Thread Ilya Verbin
On 06 Nov 18:55, Jakub Jelinek wrote:
> Looks mostly good, but:
> 
> > +# We need more things in site.exp, but automake completely controls the
> > +# creation of that file; there's no way to append to it without messing up
> > +# the dependancy chains.  So we overrule automake.  This rule is exactly
> > +# what it would have generated, plus our own additions.
> > +site.exp: Makefile
> > +   @echo 'Making a new site.exp file...'
> > +   @echo '## these variables are automatically generated by make ##' 
> > >site.tmp
> > +   @echo '# Do not edit here.  If you wish to override these values' 
> > >>site.tmp
> > +   @echo '# edit the last section' >>site.tmp
> > +   @echo 'set srcdir $(srcdir)' >>site.tmp
> > +   @echo "set objdir `pwd`" >>site.tmp
> > +   @echo 'set build_alias "$(build_alias)"' >>site.tmp
> > +   @echo 'set build_triplet $(build_triplet)' >>site.tmp
> > +   @echo 'set host_alias "$(host_alias)"' >>site.tmp
> > +   @echo 'set host_triplet $(host_triplet)' >>site.tmp
> > +   @echo 'set target_alias "$(target_alias)"' >>site.tmp
> > +   @echo 'set target_triplet $(target_triplet)' >>site.tmp
> > +   @echo 'set offload_targets "$(offload_targets)"' >>site.tmp
> > +   @echo 'set offload_additional_options "$(offload_additional_options)"' 
> > >>site.tmp
> > +   @echo 'set offload_additional_lib_paths 
> > "$(offload_additional_lib_paths)"' >>site.tmp
> > +   @echo '## All variables above are generated by configure. Do Not Edit 
> > ##' >>site.tmp
> > +   @test ! -f site.exp || \
> > + sed '1,/^## All variables above are.*##/ d' site.exp >> site.tmp
> > +   @-rm -f site.bak
> > +   @test ! -f site.exp || mv site.exp site.bak
> > +   @mv site.tmp site.exp
> 
> I don't like this, that is too fragile.  If automake is changed, we'll
> forget to update this.
> If all you are about are the 3 additional variables, can't you instead
> put them into env vars and query them in the tcl code using getenv?
> Or append them into AM_RUNTESTFLAGS ?
> AM_RUNTESTFLAGS += @something@

Done, I put them into env vars.

> > +lappend ALWAYS_CFLAGS "additional_flags=${offload_additional_options}"
> >  }
> 
> Perhaps add this only if offload_additional_options is non-empty?

Done.

Thanks,
  -- Ilya


---

diff --git a/libgomp/Makefile.in b/libgomp/Makefile.in
index 5cd666f..8e4774f 100644
--- a/libgomp/Makefile.in
+++ b/libgomp/Makefile.in
@@ -268,6 +268,9 @@ lt_host_flags = @lt_host_flags@
 mandir = @mandir@
 mkdir_p = @mkdir_p@
 multi_basedir = @multi_basedir@
+offload_additional_lib_paths = @offload_additional_lib_paths@
+offload_additional_options = @offload_additional_options@
+offload_targets = @offload_targets@
 oldincludedir = @oldincludedir@
 pdfdir = @pdfdir@
 prefix = @prefix@
diff --git a/libgomp/configure b/libgomp/configure
index 97c9be6..aabf25f 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -616,6 +616,9 @@ OMP_LOCK_SIZE
 USE_FORTRAN_FALSE
 USE_FORTRAN_TRUE
 link_gomp
+offload_additional_lib_paths
+offload_additional_options
+offload_targets
 XLDFLAGS
 XCFLAGS
 config_path
@@ -11094,7 +11097,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11097 "configure"
+#line 11100 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11200,7 +11203,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11203 "configure"
+#line 11206 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -16207,9 +16210,13 @@ else
   multilib_arg=
 fi
 
+# Get accel target and path to install tree of accel compiler
+offload_additional_options=
+offload_additional_lib_paths=
 offload_targets=
 if test x"$enable_offload_targets" != x; then
   for tgt in `echo $enable_offload_targets | sed -e 's#,# #g'`; do
+tgt_dir=`echo $tgt | grep '=' | sed 's/.*=//'`
 tgt=`echo $tgt | sed 's/=.*//'`
 case $tgt in
   *-intelmic-* | *-intelmicemul-*)
@@ -16222,6 +16229,13 @@ if test x"$enable_offload_targets" != x; then
 else
   offload_targets=$offload_targets,$tgt_name
 fi
+if test x"$tgt_dir" != x; then
+  offload_additional_options="$offload_additional_options 
-B$tgt_dir/libexec/gcc/\$(target_alias)/\$(gcc_version) -B$tgt_dir/bin"
+  
offload_additional_lib_paths="$offload_additional_lib_paths:$tgt_dir/lib64:$tgt_dir/lib"
+else
+  offload_additional_options="$offload_additional_options 
-B\$(libexecdir)/gcc/\$(target_alias)/\$(gcc_version) -B\$(bindir)"
+  
offload_additional_lib_paths="$offload_additional_lib_paths:$toolexeclibdir"
+fi
   done
 fi
 
@@ -16230,6 +16244,9 @@ cat >>confdefs.h <<_ACEOF
 _ACEOF
 
 
+
+
+
 # Set up the set of libraries that we need to link against for libgomp.
 # Note that the GOMP_SELF_SPEC in gcc.c may force -pthread,
 # which will force linkage against -lpthread (or equivalent for the system).
diff --git a/libgomp/configure.ac b/libgomp/configure.ac
index 3f34ff8..cea6

Re: [PATCH][Revisedx2] Fix PR63750

2014-11-10 Thread FX
> Indeed  is a system header and should not have been included from 
> tree-chkp.c but system.h

Indeed.
My knowledge of C++ is limited, but I think this additional patch to wide-int.h 
is the proper fix to the issue reported by Jack, no?
I’m bootstrapping it right now, it already passed stage 2.

Richard, I’d appreciate if you could review it.

Cheers,
FX




string.diff
Description: Binary data


string.ChangeLog
Description: Binary data


Re: [PATCH][Revisedx2] Fix PR63750

2014-11-10 Thread FX
> My knowledge of C++ is limited, but I think this additional patch to 
> wide-int.h is the proper fix to the issue reported by Jack, no?
> I’m bootstrapping it right now, it already passed stage 2.

Boostrapped succeeded on x86_64-apple-darwin14.
OK to commit to trunk?



string.diff
Description: Binary data


string.ChangeLog
Description: Binary data


Re: [testsuite,ARM] PR61153 Fix vbic and vorn tests

2014-11-10 Thread Christophe Lyon
On 30 October 2014 23:02, Christophe Lyon  wrote:
> On 29 October 2014 16:28, Ramana Radhakrishnan
>  wrote:
>> On Wed, Oct 29, 2014 at 3:26 PM, Christophe Lyon
>>  wrote:
>>> Hi,
>>>
>>> In PR61153, the vbic and vorn tests fail because when compiled at -O0
>>> the expected Neon instructions are not generated, making
>>> scan-assembler fail.
>>>
>>> This patch:
>>> - replaces -O0 by -O2
>>> - moves the declaration of local variables used as intrinsics
>>> parameters and results to global declarations, to prevent the compiler
>>> from optimizing the whole test away.
>>>
>>> OK?
>>>
>>
>> If you really want to do it , do it in neon-testgen.ml and do it for
>> the whole lot.
>>
>
> I thought it wasn't used anymore.
>
> At -O2 I have many more failures :-(
>
> (vdup, vget_lane, vget_low, vmov, vset_lane)
>
> And -O1 doesn't do the trick either...
>
> Christophe.
>
Hi Ramana,

Based on your request and on my above comment, I have modified
neon-testgen.ml so that it sets -O2 in some testcases and -O0 by
default.

I've achieved this by adding a new value in the 'features' list in
neon.ml, and set it to -O2 for vbic and vorn cases. neon-testgen.ml
parses this value, and defaults to -O0.
When not -O0, it also moves the input/output variables to global scope
to avoid the whole test to be optimized out.

I also fixed 3 warnings about 'or' being deprecated in neon.ml.

OK?

Christophe.

2014-11-10  Christophe Lyon  

gcc/
* config/arm/neon-testgen.ml (emit_prologue): Handle new
compile_test_optim argument.
(emit_automatics): Rename to emit_variables. Support variable
indentation of its output.
(compile_test_optim): New function.
(test_intrinsic): Call compile_test_optim.
* config/arm/neon.ml (features): Add Compiler_optim.
(ops): Add Compiler_optim feature to Vbic and Vorn.
(type_in_crypto_only): Replace 'or' by '||'.
(reinterp): Likewise.
(reinterpq): Likewise.

testsuite/
* gcc.target/arm/neon/vbicQs16.c: Regenerate.
* gcc.target/arm/neon/vbicQs32.c: Likewise.
* gcc.target/arm/neon/vbicQs64.c: Likewise.
* gcc.target/arm/neon/vbicQs8.c: Likewise.
* gcc.target/arm/neon/vbicQu16.c: Likewise.
* gcc.target/arm/neon/vbicQu32.c: Likewise.
* gcc.target/arm/neon/vbicQu64.c: Likewise.
* gcc.target/arm/neon/vbicQu8.c: Likewise.
* gcc.target/arm/neon/vbics16.c: Likewise.
* gcc.target/arm/neon/vbics32.c: Likewise.
* gcc.target/arm/neon/vbics64.c: Likewise.
* gcc.target/arm/neon/vbics8.c: Likewise.
* gcc.target/arm/neon/vbicu16.c: Likewise.
* gcc.target/arm/neon/vbicu32.c: Likewise.
* gcc.target/arm/neon/vbicu64.c: Likewise.
* gcc.target/arm/neon/vbicu8.c: Likewise.
* gcc.target/arm/neon/vornQs16.c: Likewise.
* gcc.target/arm/neon/vornQs32.c: Likewise.
* gcc.target/arm/neon/vornQs64.c: Likewise.
* gcc.target/arm/neon/vornQs8.c: Likewise.
* gcc.target/arm/neon/vornQu16.c: Likewise.
* gcc.target/arm/neon/vornQu32.c: Likewise.
* gcc.target/arm/neon/vornQu64.c: Likewise.
* gcc.target/arm/neon/vornQu8.c: Likewise.
* gcc.target/arm/neon/vorns16.c: Likewise.
* gcc.target/arm/neon/vorns32.c: Likewise.
* gcc.target/arm/neon/vorns64.c: Likewise.
* gcc.target/arm/neon/vorns8.c: Likewise.
* gcc.target/arm/neon/vornu16.c: Likewise.
* gcc.target/arm/neon/vornu32.c: Likewise.
* gcc.target/arm/neon/vornu64.c: Likewise.
* gcc.target/arm/neon/vornu8.c: Likewise.

>> regards
>> Ramana
>>> Christophe.
>>>
>>> 2014-10-29  Christophe Lyon  
>>>
>>> PR target/61153
>>> * gcc.target/arm/neon/vbicQs16.c: Compile at O2 and move variables
>>> declarations from local to global.
>>> * gcc.target/arm/neon/vbicQs16.c: Likewise.
>>> * gcc.target/arm/neon/vbicQs32.c: Likewise.
>>> * gcc.target/arm/neon/vbicQs64.c: Likewise.
>>> * gcc.target/arm/neon/vbicQs8.c: Likewise.
>>> * gcc.target/arm/neon/vbicQu16.c: Likewise.
>>> * gcc.target/arm/neon/vbicQu32.c: Likewise.
>>> * gcc.target/arm/neon/vbicQu64.c: Likewise.
>>> * gcc.target/arm/neon/vbicQu8.c: Likewise.
>>> * gcc.target/arm/neon/vbics16.c: Likewise.
>>> * gcc.target/arm/neon/vbics32.c: Likewise.
>>> * gcc.target/arm/neon/vbics64.c: Likewise.
>>> * gcc.target/arm/neon/vbics8.c: Likewise.
>>> * gcc.target/arm/neon/vbicu16.c: Likewise.
>>> * gcc.target/arm/neon/vbicu32.c: Likewise.
>>> * gcc.target/arm/neon/vbicu64.c: Likewise.
>>> * gcc.target/arm/neon/vbicu8.c: Likewise.
>>> * gcc.target/arm/neon/vornQs16.c: Likewise.
>>> * gcc.target/arm/neon/vornQs32.c: Likewise.
>>> * gcc.target/arm/neon/vornQs64.c: Likewise.
>>> * gcc.target/arm/neon/vornQs8.c: Likewise.
>>> * gcc.target/arm/neon/vornQu16.c: Likewise.
>>> * gcc.target/arm/neon/vornQu32.c: Likewise.
>>> * gcc.target/arm/neon/vornQu64.c: Likewise.
>>> * gcc.target/arm/neon/vornQu8.c: Likewise.
>>> * gcc.target/arm/neon/vorns16.c: Likewise.
>>> * gcc.target/arm/neon/v

[PATCH] c++98/mt_allcoator.cc: Fix assumption sizeof(void *) == sizeof(size_t)

2014-11-10 Thread Joel Sherrill
2014-11-10  Joel Sherrill 

* src/c++98/mt_allocator.cc: Fix assumption that sizeof(void *) is
equal to sizeof(size_t). The m32c breaks this assumption.
---
 libstdc++-v3/src/c++98/mt_allocator.cc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/src/c++98/mt_allocator.cc 
b/libstdc++-v3/src/c++98/mt_allocator.cc
index 38e17df..04dd8ad 100644
--- a/libstdc++-v3/src/c++98/mt_allocator.cc
+++ b/libstdc++-v3/src/c++98/mt_allocator.cc
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 namespace
 {
@@ -74,7 +75,7 @@ namespace
 __freelist& freelist = get_freelist();
 {
   __gnu_cxx::__scoped_lock sentry(get_freelist_mutex());
-  size_t _M_id = reinterpret_cast(__id);
+  uintptr_t _M_id = reinterpret_cast(__id);
   
   typedef __gnu_cxx::__pool::_Thread_record _Thread_record;
   _Thread_record* __tr = &freelist._M_thread_freelist_array[_M_id - 1];
@@ -627,7 +628,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
__freelist& freelist = get_freelist();
void* v = __gthread_getspecific(freelist._M_key);
-   size_t _M_id = (size_t)v;
+   uintptr_t _M_id = (uintptr_t)v;
if (_M_id == 0)
  {
{
-- 
1.9.3



[match-and-simplify] Remove supposedly dead code

2014-11-10 Thread Richard Biener

"supposedly" because there are a few regressions.

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

Richard.

2014-11-10  Richard Biener  

* tree-ssa-forwprop.c (simplify_conversion_from_bitmask): Remove.
(associate_plusminus): Likewise.
(combine_conversions): Likewise.
(simplify_mult): Likewise.
(pass_forwprop::execute): Adjust.
* gimple-fold.c (fold_gimple_assign): Remove dispatches to
fold_binary_loc and fold_ternary_loc.
(gimple_fold_stmt_to_constant_1): Likewise.

Index: gcc/tree-ssa-forwprop.c
===
--- gcc/tree-ssa-forwprop.c (revision 217279)
+++ gcc/tree-ssa-forwprop.c (working copy)
@@ -1214,78 +1214,6 @@ bailout:
 }
 
 
-/* GSI_P points to a statement which performs a narrowing integral
-   conversion.
-
-   Look for cases like:
-
- t = x & c;
- y = (T) t;
-
-   Turn them into:
-
- t = x & c;
- y = (T) x;
-
-   If T is narrower than X's type and C merely masks off bits outside
-   of (T) and nothing else.
-
-   Normally we'd let DCE remove the dead statement.  But no DCE runs
-   after the last forwprop/combine pass, so we remove the obviously
-   dead code ourselves.
-
-   Return TRUE if a change was made, FALSE otherwise.  */
-
-static bool 
-simplify_conversion_from_bitmask (gimple_stmt_iterator *gsi_p)
-{
-  gimple stmt = gsi_stmt (*gsi_p);
-  gimple rhs_def_stmt = SSA_NAME_DEF_STMT (gimple_assign_rhs1 (stmt));
-
-  /* See if the input for the conversion was set via a BIT_AND_EXPR and
- the only use of the BIT_AND_EXPR result is the conversion.  */
-  if (is_gimple_assign (rhs_def_stmt)
-  && gimple_assign_rhs_code (rhs_def_stmt) == BIT_AND_EXPR
-  && has_single_use (gimple_assign_lhs (rhs_def_stmt)))
-{
-  tree rhs_def_operand1 = gimple_assign_rhs1 (rhs_def_stmt);
-  tree rhs_def_operand2 = gimple_assign_rhs2 (rhs_def_stmt);
-  tree lhs_type = TREE_TYPE (gimple_assign_lhs (stmt));
-
-  /* Now verify suitability of the BIT_AND_EXPR's operands.
-The first must be an SSA_NAME that we can propagate and the
-second must be an integer constant that masks out all the
-bits outside the final result's type, but nothing else.  */
-  if (TREE_CODE (rhs_def_operand1) == SSA_NAME
- && ! SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs_def_operand1)
- && TREE_CODE (rhs_def_operand2) == INTEGER_CST
- && operand_equal_p (rhs_def_operand2,
- build_low_bits_mask (TREE_TYPE (rhs_def_operand2),
-  TYPE_PRECISION (lhs_type)),
-  0))
-   {
- /* This is an optimizable case.  Replace the source operand
-in the conversion with the first source operand of the
-BIT_AND_EXPR.  */
- gimple_assign_set_rhs1 (stmt, rhs_def_operand1);
- stmt = gsi_stmt (*gsi_p);
- update_stmt (stmt);
-
- /* There is no DCE after the last forwprop pass.  It's
-easy to clean up the first order effects here.  */
- gimple_stmt_iterator si;
- si = gsi_for_stmt (rhs_def_stmt);
- gsi_remove (&si, true);
- fwprop_invalidate_lattice (gimple_get_lhs (rhs_def_stmt));
- release_defs (rhs_def_stmt);
- return true;
-   }
-}
-
-  return false;
-}
-
-
 /* Helper function for simplify_gimple_switch.  Remove case labels that
have values outside the range of the new type.  */
 
@@ -1992,467 +1920,6 @@ simplify_rotate (gimple_stmt_iterator *g
   return true;
 }
 
-/* Perform re-associations of the plus or minus statement STMT that are
-   always permitted.  Returns true if the CFG was changed.  */
-
-static bool
-associate_plusminus (gimple_stmt_iterator *gsi)
-{
-  gimple stmt = gsi_stmt (*gsi);
-  tree rhs1 = gimple_assign_rhs1 (stmt);
-  tree rhs2 = gimple_assign_rhs2 (stmt);
-  enum tree_code code = gimple_assign_rhs_code (stmt);
-  bool changed;
-
-  /* We can't reassociate at all for saturating types.  */
-  if (TYPE_SATURATING (TREE_TYPE (rhs1)))
-return false;
-
-  /* First contract negates.  */
-  do
-{
-  changed = false;
-
-  /* A +- (-B) -> A -+ B.  */
-  if (TREE_CODE (rhs2) == SSA_NAME)
-   {
- gimple def_stmt = SSA_NAME_DEF_STMT (rhs2);
- if (is_gimple_assign (def_stmt)
- && gimple_assign_rhs_code (def_stmt) == NEGATE_EXPR
- && can_propagate_from (def_stmt))
-   {
- code = (code == MINUS_EXPR) ? PLUS_EXPR : MINUS_EXPR;
- gimple_assign_set_rhs_code (stmt, code);
- rhs2 = gimple_assign_rhs1 (def_stmt);
- gimple_assign_set_rhs2 (stmt, rhs2);
- gimple_set_modified (stmt, true);
- changed = true;
-   }
-   }
-
-  /* (-A) + B -> B - A.  */
-  if (TREE_CODE (rhs1) == SSA_NAME
- && code == P

[PATCH][16/n] Merge from match-and-simplify, simplify_mult pattern

2014-11-10 Thread Richard Biener

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

Richard.

2014-11-10  Richard Biener  

* match.pd: Implement pattern from simplify_mult.
* tree-ssa-forwprop.c (simplify_mult): Remove.
(pass_forwprop::execute): Do not call simplify_mult.

Index: trunk/gcc/match.pd
===
*** trunk.orig/gcc/match.pd 2014-11-10 12:12:11.603244811 +0100
--- trunk/gcc/match.pd  2014-11-10 12:13:09.013242299 +0100
*** along with GCC; see the file COPYING3.
*** 443,445 
--- 443,453 
 && operand_equal_p (@1, build_low_bits_mask (TREE_TYPE (@1),
TYPE_PRECISION (type)), 0))
 (convert @0)))
+ 
+ 
+ /* (X /[ex] A) * A -> X.  */
+ (simplify
+   (mult (convert? (exact_div @0 @1)) @1)
+   /* Look through a sign-changing conversion.  */
+   (if (TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (type))
+(convert @0)))
Index: trunk/gcc/tree-ssa-forwprop.c
===
*** trunk.orig/gcc/tree-ssa-forwprop.c  2014-11-10 12:12:11.636244810 +0100
--- trunk/gcc/tree-ssa-forwprop.c   2014-11-10 12:14:33.640238595 +0100
*** simplify_vector_constructor (gimple_stmt
*** 2588,2641 
return true;
  }
  
- /* Simplify multiplications.
-Return true if a transformation applied, otherwise return false.  */
- 
- static bool
- simplify_mult (gimple_stmt_iterator *gsi)
- {
-   gimple stmt = gsi_stmt (*gsi);
-   tree arg1 = gimple_assign_rhs1 (stmt);
-   tree arg2 = gimple_assign_rhs2 (stmt);
- 
-   if (TREE_CODE (arg1) != SSA_NAME)
- return false;
- 
-   gimple def_stmt = SSA_NAME_DEF_STMT (arg1);
-   if (!is_gimple_assign (def_stmt))
- return false;
- 
-   /* Look through a sign-changing conversion.  */
-   if (CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt)))
- {
-   if (TYPE_PRECISION (TREE_TYPE (gimple_assign_lhs (def_stmt)))
- != TYPE_PRECISION (TREE_TYPE (gimple_assign_rhs1 (def_stmt)))
- || TREE_CODE (gimple_assign_rhs1 (def_stmt)) != SSA_NAME)
-   return false;
-   def_stmt = SSA_NAME_DEF_STMT (gimple_assign_rhs1 (def_stmt));
-   if (!is_gimple_assign (def_stmt))
-   return false;
- }
- 
-   if (gimple_assign_rhs_code (def_stmt) == EXACT_DIV_EXPR)
- {
-   if (operand_equal_p (gimple_assign_rhs2 (def_stmt), arg2, 0))
-   {
- tree res = gimple_assign_rhs1 (def_stmt);
- if (useless_type_conversion_p (TREE_TYPE (arg1), TREE_TYPE (res)))
-   gimple_assign_set_rhs_with_ops (gsi, TREE_CODE (res), res,
-   NULL_TREE);
- else
-   gimple_assign_set_rhs_with_ops (gsi, NOP_EXPR, res, NULL_TREE);
- gcc_assert (gsi_stmt (*gsi) == stmt);
- update_stmt (stmt);
- return true;
-   }
- }
- 
-   return false;
- }
- 
  
  /* Primitive "lattice" function for gimple_simplify.  */
  
--- 2588,2593 
*** pass_forwprop::execute (function *fun)
*** 2853,2865 
  || code == BIT_XOR_EXPR)
 && simplify_rotate (&gsi))
  changed = true;
-   else if (code == MULT_EXPR)
- {
-   changed = simplify_mult (&gsi);
-   if (changed
-   && maybe_clean_or_replace_eh_stmt (stmt, stmt))
- bitmap_set_bit (to_purge, bb->index);
- }
else if (code == PLUS_EXPR
 || code == MINUS_EXPR)
  {
--- 2805,2810 


Re: [PATCH] Reset contexts in possible_polymorphic_call_targets properly

2014-11-10 Thread Jan Hubicka
> Hi
> 
> in a patch I work on I store ipa_polymorphic_call_contexts in a vector
> and thus they do not get properly constructed, merely memset to zero.
> This means that I happen to be using "know nothing" contexts which
> have their outer_type set to NULL but the various flags are also
> false, unlike in the properly constructed ones.
> 
> When I pass such context to possible_polymorphic_call_targets, I get
> wrong complete results of size one because it sets the outer_type to
> otr_type but leaves the maybe_derived_type flag cleared.  So I changed
> the function to reset the context using clear_outer_type(otr_type)
> instead, which I believe is the proper way of doing it.  However, I
> had to make that method public to do so.
> 
> Bootstrapped and tested on x86_64-linux.  OK for trunk?
> 
> Thanks,
> 
> Martin
> 
> 
> 2014-11-08  Martin Jambor  
> 
>   * cgraph.h (clear_outer_type): Make public.  Fix comment.
>   * ipa-devirt.c (possible_polymorphic_call_targets): Use

Hmm, it is kind of hack (it would be better to avoid using malformed contextes 
around)
but OK.

Honza


[PATCH] Fix for PR63766 (handle removed functions in do_per_function_toporder)

2014-11-10 Thread Ilya Enkovich
Hi,

Here is a fix for PR63766.  Currently all functions are transformed into SSA 
before local optimizations and it allows function to be inlined and removed 
before it goes through local optimzations.  But this requires removal of these 
functions from working queue.

Bootstrapped and tested on x86_64-unknown-linux-gnu.  OK for trunk?

Thanks,
Ilya
--
gcc/

2014-11-10  Ilya Enkovich  

* passes.c (remove_cgraph_node_from_order): New.
(do_per_function_toporder): Register cgraph removal
hook.

gcc/testsuite/

2014-11-10  Ilya Enkovich  

* g++.dg/pr63766.C: New.


diff --git a/gcc/passes.c b/gcc/passes.c
index 5e91a79..b6a0b0c 100644
--- a/gcc/passes.c
+++ b/gcc/passes.c
@@ -1609,6 +1609,24 @@ do_per_function (void (*callback) (function *, void 
*data), void *data)
 static int nnodes;
 static GTY ((length ("nnodes"))) cgraph_node **order;
 
+/* Hook called when NODE is removed and therefore should be
+   excluded from order vector.  DATA is an array of integers.
+   DATA[0] holds max index it may be accessed by.  For cgraph
+   node DATA[node->uid + 1] holds index of this node in order
+   vector.  */
+static void
+remove_cgraph_node_from_order (cgraph_node *node, void *data)
+{
+  int *order_idx = (int *)data;
+
+  if (node->uid >= order_idx[0])
+return;
+
+  int idx = order_idx[node->uid + 1];
+  if (idx >= 0 && idx < nnodes && order[idx] == node)
+order[idx] = NULL;
+}
+
 /* If we are in IPA mode (i.e., current_function_decl is NULL), call
function CALLBACK for every function in the call graph.  Otherwise,
call CALLBACK on the current function.
@@ -1622,13 +1640,29 @@ do_per_function_toporder (void (*callback) (function *, 
void *data), void *data)
 callback (cfun, data);
   else
 {
+  cgraph_node_hook_list *hook;
+  int *order_idx;
   gcc_assert (!order);
   order = ggc_vec_alloc (symtab->cgraph_count);
+
+  order_idx = (int *)xmalloc (sizeof(int) * (symtab->cgraph_max_uid + 1));
+  memset (order_idx + 1, -1, sizeof (int) * symtab->cgraph_max_uid);
+  order_idx[0] = symtab->cgraph_max_uid;
+
   nnodes = ipa_reverse_postorder (order);
   for (i = nnodes - 1; i >= 0; i--)
-order[i]->process = 1;
+   {
+ order[i]->process = 1;
+ order_idx[order[i]->uid + 1] = i;
+   }
+  hook = symtab->add_cgraph_removal_hook (remove_cgraph_node_from_order,
+ order_idx);
   for (i = nnodes - 1; i >= 0; i--)
{
+ /* Function could be inlined and removed as unreachable.  */
+ if (!order[i])
+   continue;
+
  struct cgraph_node *node = order[i];
 
  /* Allow possibly removed nodes to be garbage collected.  */
@@ -1637,6 +1671,8 @@ do_per_function_toporder (void (*callback) (function *, 
void *data), void *data)
  if (node->has_gimple_body_p ())
callback (DECL_STRUCT_FUNCTION (node->decl), data);
}
+  symtab->remove_cgraph_removal_hook (hook);
+  free (order_idx);
 }
   ggc_free (order);
   order = NULL;
diff --git a/gcc/testsuite/g++.dg/pr63766.C b/gcc/testsuite/g++.dg/pr63766.C
new file mode 100644
index 000..1414fbe
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr63766.C
@@ -0,0 +1,48 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c++11 -O2" } */
+
+class A
+{
+ public:
+  void
+getValueType ()
+  {
+  }
+  void getTypeClass ();
+};
+template  class B
+{
+ public:
+  void
+Visit (A *p1)
+  {
+p1->getTypeClass ();
+static_cast (0)->VisitAtomicType (0);
+  }
+};
+class C : B
+{
+  template 
+  void
+dumpChild (Fn p1)
+{
+  p1 ();
+}
+
+ public:
+  void dumpTypeAsChild (int);
+  void
+VisitAtomicType (A *p1)
+  {
+p1->getValueType ();
+dumpTypeAsChild (0);
+  }
+};
+void
+C::dumpTypeAsChild (int)
+{
+  dumpChild ([=]
+ {
+   Visit (0);
+ });
+}


Re: Add the latest C++ SD-6 additions.

2014-11-10 Thread Ed Smith-Rowland

On 11/09/2014 11:45 PM, Jason Merrill wrote:

On 11/09/2014 08:33 PM, Ed Smith-Rowland wrote:

+  //cpp_hashnode *node = 0;
+  //node = token->val.node.node;
+  //if (node)
+  //  pfile->mi_ind_cmacro = node;


Remove this commented-out code?

The patch is OK.

Jason


Here is the committed patch.  It has those comments removed and has some 
test case cleanup.


Would a 4.9 version be accepted?

Thanks,

Ed

Index: libcpp/include/cpplib.h
===
--- libcpp/include/cpplib.h (revision 217269)
+++ libcpp/include/cpplib.h (working copy)
@@ -580,6 +580,9 @@
  Second argument is the location of the start of the current expansion.  */
   void (*used) (cpp_reader *, source_location, cpp_hashnode *);
 
+  /* Callback to identify whether an attribute exists.  */
+  int (*has_attribute) (cpp_reader *);
+
   /* Callback that can change a user builtin into normal macro.  */
   bool (*user_builtin_macro) (cpp_reader *, cpp_hashnode *);
 };
Index: libcpp/internal.h
===
--- libcpp/internal.h   (revision 217269)
+++ libcpp/internal.h   (working copy)
@@ -261,6 +261,9 @@
   /* Nonzero if in a __has_include__ or __has_include_next__ statement.  */
   unsigned char in__has_include__;
 
+  /* Nonzero if in a __has_attribute__ statement.  */
+  unsigned char in__has_attribute__;
+
   /* Nonzero if prevent_expansion is true only because output is
  being discarded.  */
   unsigned char discarding_output;
@@ -284,6 +287,7 @@
   cpp_hashnode *n__VA_ARGS__;  /* C99 vararg macros */
   cpp_hashnode *n__has_include__;  /* __has_include__ operator */
   cpp_hashnode *n__has_include_next__; /* __has_include_next__ operator */
+  cpp_hashnode *n__has_attribute__;/* __has_attribute__ operator */
 };
 
 typedef struct _cpp_line_note _cpp_line_note;
Index: libcpp/directives.c
===
--- libcpp/directives.c (revision 217269)
+++ libcpp/directives.c (working copy)
@@ -571,6 +571,10 @@
 || node == pfile->spec_nodes.n__has_include_next__))
cpp_error (pfile, CPP_DL_ERROR,
   "\"__has_include__\" cannot be used as a macro name");
+  else if (is_def_or_undef
+   && node == pfile->spec_nodes.n__has_attribute__)
+   cpp_error (pfile, CPP_DL_ERROR,
+  "\"__has_attribute__\" cannot be used as a macro name");
   else if (! (node->flags & NODE_POISONED))
return node;
 }
Index: libcpp/expr.c
===
--- libcpp/expr.c   (revision 217269)
+++ libcpp/expr.c   (working copy)
@@ -65,6 +65,7 @@
 static void check_promotion (cpp_reader *, const struct op *);
 
 static cpp_num parse_has_include (cpp_reader *, enum include_type);
+static cpp_num parse_has_attribute (cpp_reader *);
 
 /* Token type abuse to create unary plus and minus operators.  */
 #define CPP_UPLUS ((enum cpp_ttype) (CPP_LAST_CPP_OP + 1))
@@ -1054,6 +1055,8 @@
return parse_has_include (pfile, IT_INCLUDE);
   else if (token->val.node.node == pfile->spec_nodes.n__has_include_next__)
return parse_has_include (pfile, IT_INCLUDE_NEXT);
+  else if (token->val.node.node == pfile->spec_nodes.n__has_attribute__)
+   return parse_has_attribute (pfile);
   else if (CPP_OPTION (pfile, cplusplus)
   && (token->val.node.node == pfile->spec_nodes.n_true
   || token->val.node.node == pfile->spec_nodes.n_false))
@@ -2147,3 +2150,21 @@
 
   return result;
 }
+
+/* Handle meeting "__has_attribute__" in a preprocessor expression.  */
+static cpp_num
+parse_has_attribute (cpp_reader *pfile)
+{
+  pfile->state.in__has_attribute__++;
+
+  cpp_num result;
+  result.unsignedp = false;
+  result.high = 0;
+  result.overflow = false;
+
+  result.low = pfile->cb.has_attribute (pfile);
+
+  pfile->state.in__has_attribute__--;
+
+  return result;
+}
Index: libcpp/identifiers.c
===
--- libcpp/identifiers.c(revision 217269)
+++ libcpp/identifiers.c(working copy)
@@ -72,6 +72,7 @@
   s->n__VA_ARGS__->flags |= NODE_DIAGNOSTIC;
   s->n__has_include__   = cpp_lookup (pfile, DSC("__has_include__"));
   s->n__has_include_next__ = cpp_lookup (pfile, DSC("__has_include_next__"));
+  s->n__has_attribute__   = cpp_lookup (pfile, DSC("__has_attribute__"));
 }
 
 /* Tear down the identifier hash table.  */
Index: libcpp/pch.c
===
--- libcpp/pch.c(revision 217269)
+++ libcpp/pch.c(working copy)
@@ -835,6 +835,7 @@
 s->n__VA_ARGS__ = cpp_lookup (r, DSC("__VA_ARGS__"));
 s->n__has_include__ = cpp_lookup (r, DSC("__has_include__"));
 s->n__has_include_next__ = cpp_lookup (r, DSC("__has_include_next__"));
+s->n__has_attribute__ = cpp_look

Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s

2014-11-10 Thread David Edelsohn
On Mon, Nov 10, 2014 at 4:59 AM, Michael Haubenwallner
 wrote:
>
> Am 2014-11-07 20:52, schrieb David Edelsohn:
>> First, please explicitly copy me on AIX or PowerPC patches sent to 
>> gcc-patches.
>>
>> I don't have a fundamental objection to including this option, but
>> note that Richi, Honza and I have discovered that using AIX runtime
>> linking option interacts badly with some GCC optimizations and can
>> result in applications that hang in a loop.
>
> Feels like adding the "aix-soname" linking procedure becomes more important:
>
>> All code on AIX is position independent (PIC) by default.  Executables
>> and shared libraries essentially are PIE.  Because of this, AIX does
>> not provide separate "static" libraries and one can link statically
>> with a shared library.
>>
>> Creating a library enabled for runtime linking with -G (-brtl), causes
>> a lot of problems, including a newly recognized failure mode.  Without
>> careful control over AIX symbol export, all global calls with use
>> glink code (equivalent to ELF PLTs). This also creates a TOC entry for
>> every global call, possibly overflowing the TOC.
>
> About to define "careful control over AIX symbol export":
> The symbols listed in the import file are those found in the object files
> only, not the ones created at linktime (like __GLOBAL*) or from the static
> objects found in libc.a. While I do this in libtool from the beginning here,
> I have had a helper script wrapping ld to support '--soname=' for non-libtool
> packages, where creating the import file from the final shared object also
> included static libc-provided symbols, which turned out as dependency pitfall.

AIX added ELF-like visibility support to XCOFF, which would be
preferred.  Except it was not added in a formal release, like AIX 8.1
and apparently was back-ported to at least AIX 6.1, so its difficult
to phase in the support. One would need to add a configure test for
the feature and not all users are upgrading the system. So one cannot
build and distribute "GCC for AIX 7.1" and know the feature is
available in the system tools.  GCC builds would be incompatible and
object files, libraries, executables created by GCC would be
incompatible.  Basically, a mess.

> While I haven't focussed on nor explicitly tested, I do believe that this
> also solves problems with global C++ constructor/destructor call orders.

Why? There still is the problem of the AIX kernel runtime loader
ordering dependent shared objects.

>> But the main problem is GCC uses aliases and functions declared as
>> weak to support some C++ features.
>
> This is another reason why I do force runtime linking for our application,
> which uses these C++ features while its main target platform is Linux.

You have not explained how this has any fix / benefit affecting the
problem, other than separate shared and static libraries.  Forcing
runtime linking seems irrelevant.  It was linking shared before and
linking shared after your patch (with runtime linking) so the net
effect is zero.

Again, runtime linking of all global symbols affects performance and
bloats the TOC, making TOC overflow more likely.

I don't have a fundamental objection to the patch, but you have not
really responded to the potential problems and any motivation for this
feature other than greater SVR4 emulation.  For better or worse, AIX
is not SVR4.  Every library built with this option hurts performance
on AIX and potentially causes mysterious TOC overflow errors, which
confuse users unfamiliar with AIX and whose workarounds hurt
performance even more.

Thanks, David


Re: [gofrontend-dev] [PATCH 4/4] Gccgo port to s390[x] -- part II

2014-11-10 Thread Ian Taylor
On Mon, Nov 10, 2014 at 6:00 AM, Dominik Vogt  wrote:
>> I'd still like to avoid the rampant duplication if possible.  One
>> approach would be to put most of the test in something like
>> nilptr_tests.go marked with "// skip".  Then we can have top-level
>> nilptrXX.go tests with +build lines that use "// run nilptr_tests.go".
>
> I fail to see how that could be done with "// run".  There is one
> example use, namely cmplxdivide.go".  That is not run in gcc
> because the "run" line does not match anything in go-test.exp.  If
> I add a rule for that, how does that help me to compile a test
> that consists of multiple files?

That test is run (all tests are run or explicitly skipped or marked
unsupported).  In go-test.exp look for
$test_line == "// run cmplxdivide1.go"

Ian


Re: [2/6] nvptx testsuite patches: typed assembly

2014-11-10 Thread Bernd Schmidt

On 10/21/2014 05:32 PM, Bernd Schmidt wrote:

On 10/21/2014 05:16 PM, Jeff Law wrote:

On 10/21/14 14:15, Bernd Schmidt wrote:

Since everything in ptx assembly is typed, K&R C is problematic. There
are a number of testcases that call functions with the wrong number of
arguments, or arguments of the wrong type. I've added a new feature,
untyped_assembly, which these tests now require. I've also used this for
tests using builtin_apply/builtin_return.

I'd kind of prefer to see the tests fixed, but I can live with this.


Most of these are quite old, and it seems likely that they should be
kept as they are for test coverage - it's desirable to know that the
compiler doesn't crash when a K&R function is called with varying
numbers of arguments for example.


Just a note that I'm assuming that your mail was an approval and 
checking this in.



Bernd



Re: The nvptx port [10/11+] Target files

2014-11-10 Thread Bernd Schmidt

On 10/30/2014 12:35 AM, Jeff Law wrote:

A "nit" -- Richard S. recently removed the need to include the "enum"
for "enum machine_mode".  I believe he had a script to handle the
mundane parts of that change.  Please make sure to update the nvptx port
to conform to that new convention, obviously feel free to use the script
if you want.

You may need to update with James Greenhalgh's changes to
MOVE_BY_PIECES_P and friends.

With those two issues addressed as needed, this is OK for the trunk.


I've now committed it, in the following form. Other than the enum thing, 
this also adds some atomic instructions.


The scripts (11/11) I've put up on github, along with a hacked up 
newlib. These are at


https://github.com/bernds/nvptx-tools
https://github.com/bernds/nvptx-newlib

They are likely to migrate to MentorEmbedded from bernds, but that had 
some permissions problems last week.



Bernd

commit 659744a99d815b168716b4460e32f6a21593e494
Author: Bernd Schmidt 
Date:   Thu Nov 6 19:03:57 2014 +0100

Add the nvptx port.

	* configure.ac: Handle nvptx-*-*.
	* configure: Regenerate.

	gcc/
	* config/nvptx/nvptx.c: New file.
	* config/nvptx/nvptx.h: New file.
	* config/nvptx/nvptx-protos.h: New file.
	* config/nvptx/nvptx.md: New file.
	* config/nvptx/t-nvptx: New file.
	* config/nvptx/nvptx.opt: New file.
	* common/config/nvptx/nvptx-common.c: New file.
	* config.gcc: Handle nvptx-*-*.

	libgcc/
	* config.host: Handle nvptx-*-*.
	* shared-object.mk (as-flags-$o): Define.
	($(base)$(objext), $(base)_s$(objext)): Use it instead of
	-xassembler-with-cpp.
	* static-object.mk: Identical changes.
	* config/nvptx/t-nvptx: New file.
	* config/nvptx/crt0.s: New file.
	* config/nvptx/free.asm: New file.
	* config/nvptx/malloc.asm: New file.
	* config/nvptx/realloc.c: New file.

diff --git a/ChangeLog b/ChangeLog
index fd6172a..e83d1e6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2014-11-06  Bernd Schmidt  
+
+	* configure.ac: Handle nvptx-*-*.
+	* configure: Regenerate.
+
 2014-11-06  Prachi Godbole  
 
 	* MAINTAINERS (Write After Approval): Add myself.
diff --git a/configure b/configure
index d0c760b..0e014a3 100755
--- a/configure
+++ b/configure
@@ -3779,6 +3779,10 @@ case "${target}" in
   mips*-*-*)
 noconfigdirs="$noconfigdirs gprof"
 ;;
+  nvptx*-*-*)
+# nvptx is just a compiler
+noconfigdirs="$noconfigdirs target-libssp target-libstdc++-v3 target-libobjc"
+;;
   sh-*-* | sh64-*-*)
 case "${target}" in
   sh*-*-elf)
diff --git a/configure.ac b/configure.ac
index 2f0af4a..b1ef069 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1138,6 +1138,10 @@ case "${target}" in
   mips*-*-*)
 noconfigdirs="$noconfigdirs gprof"
 ;;
+  nvptx*-*-*)
+# nvptx is just a compiler
+noconfigdirs="$noconfigdirs target-libssp target-libstdc++-v3 target-libobjc"
+;;
   sh-*-* | sh64-*-*)
 case "${target}" in
   sh*-*-elf)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 731a7bc8b..c170e69 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,14 @@
+2014-11-10  Bernd Schmidt  
+
+	* config/nvptx/nvptx.c: New file.
+	* config/nvptx/nvptx.h: New file.
+	* config/nvptx/nvptx-protos.h: New file.
+	* config/nvptx/nvptx.md: New file.
+	* config/nvptx/t-nvptx: New file.
+	* config/nvptx/nvptx.opt: New file.
+	* common/config/nvptx/nvptx-common.c: New file.
+	* config.gcc: Handle nvptx-*-*.
+
 2014-11-10  Richard Biener  
 
 	* tree-ssa-operands.c (finalize_ssa_uses): Properly put
diff --git a/gcc/common/config/nvptx/nvptx-common.c b/gcc/common/config/nvptx/nvptx-common.c
new file mode 100644
index 000..80ab076
--- /dev/null
+++ b/gcc/common/config/nvptx/nvptx-common.c
@@ -0,0 +1,38 @@
+/* NVPTX common hooks.
+   Copyright (C) 2014 Free Software Foundation, Inc.
+   Contributed by Bernd Schmidt 
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "diagnostic-core.h"
+#include "tm.h"
+#include "tm_p.h"
+#include "common/common-target.h"
+#include "common/common-target-def.h"
+#include "opts.h"
+#include "flags.h"
+
+#undef TARGET_HAVE_NAMED_SECTIONS
+#define TARGET_HAVE_NAMED_SECTIONS false
+
+#undef TARGET_DEFAULT_TARGET_FLAGS
+#define TARGET_DEFAULT_TARGET_FLAGS MASK_ABI64
+
+struct gcc_targetm_common targetm_common =

[C++ Patch] PR 63265

2014-11-10 Thread Paolo Carlini

Hi,

as far as I can see this 4.9/5 regression, where we spuriously warn 
about the left shifts in the templates, has to do with r208183, where 
Jason replaced c_inhibit_evaluation_warnings fiddling in 
tsubst_copy_and_build with two warning_sentinels, on warn_type_limits 
and warn_div_by_zero. In the present testcase, the triggering warning is 
the one about left shift count >= width of type, which currently doesn't 
have a name. Thus I think we can easily solve the issue by giving the 
warning a name (likewise for the negative count warning) and using again 
warning_sentinel. The names I picked are the same already used by clang.


Tested x86_64-linux. In case, what about 4.9?

Thanks,
Paolo.

//


2014-11-10  Paolo Carlini  

PR c++/63265
* c-family/c.opt ([Wshift-count-negative, Wshift-count-overflow]): Add.
* doc/invoke.texi: Document the latter.

/cp
2014-11-10  Paolo Carlini  

PR c++/63265
* pt.c (tsubst_copy_and_build, case LSHIFT_EXPR): Use warning_sentinels
on warn_shift_count_negative and warn_shift_count_overflow.
* typeck.c (cp_build_binary_op): Use OPT_Wshift_count_negative and
OPT_Wshift_count_overflow in the warnings.

/c
2014-11-10  Paolo Carlini  

PR c++/63265
* c-typeck.c (build_binary_op): Use OPT_Wshift_count_negative and
OPT_Wshift_count_overflow in the warnings.

/testsuite
2014-11-10  Paolo Carlini  

PR c++/63265
* g++.dg/cpp0x/constexpr-63265.C: New.
Index: c/c-typeck.c
===
--- c/c-typeck.c(revision 217282)
+++ c/c-typeck.c(working copy)
@@ -10545,7 +10545,8 @@ build_binary_op (location_t location, enum tree_co
{
  int_const = false;
  if (c_inhibit_evaluation_warnings == 0)
-   warning_at (location, 0, "left shift count is negative");
+   warning_at (location, OPT_Wshift_count_negative,
+   "left shift count is negative");
}
 
  else if (compare_tree_int (op1, TYPE_PRECISION (type0)) >= 0)
@@ -10552,8 +10553,8 @@ build_binary_op (location_t location, enum tree_co
{
  int_const = false;
  if (c_inhibit_evaluation_warnings == 0)
-   warning_at (location, 0, "left shift count >= width of "
-   "type");
+   warning_at (location, OPT_Wshift_count_overflow,
+   "left shift count >= width of type");
}
}
 
Index: c-family/c.opt
===
--- c-family/c.opt  (revision 217282)
+++ c-family/c.opt  (working copy)
@@ -760,14 +760,22 @@ Wselector
 ObjC ObjC++ Var(warn_selector) Warning
 Warn if a selector has multiple methods
 
+Wsequence-point
+C ObjC C++ ObjC++ Var(warn_sequence_point) Warning LangEnabledBy(C ObjC C++ 
ObjC++,Wall)
+Warn about possible violations of sequence point rules
+
 Wshadow-ivar
 ObjC ObjC++ Var(warn_shadow_ivar) EnabledBy(Wshadow) Init(1) Warning
 Warn if a local declaration hides an instance variable
 
-Wsequence-point
-C ObjC C++ ObjC++ Var(warn_sequence_point) Warning LangEnabledBy(C ObjC C++ 
ObjC++,Wall)
-Warn about possible violations of sequence point rules
+Wshift-count-negative
+C ObjC C++ ObjC++ Var(warn_shift_count_negative) Init(1) Warning
+Warn if left shift count is negative
 
+Wshift-count-overflow
+C ObjC C++ ObjC++ Var(warn_shift_count_overflow) Init(1) Warning
+Warn if left shift count >= width of type
+
 Wsign-compare
 C ObjC C++ ObjC++ Var(warn_sign_compare) Warning LangEnabledBy(C++ ObjC++,Wall)
 Warn about signed-unsigned comparisons
Index: cp/pt.c
===
--- cp/pt.c (revision 217282)
+++ cp/pt.c (working copy)
@@ -14680,6 +14680,8 @@ tsubst_copy_and_build (tree t,
   {
warning_sentinel s1(warn_type_limits);
warning_sentinel s2(warn_div_by_zero);
+   warning_sentinel s3(warn_shift_count_negative);
+   warning_sentinel s4(warn_shift_count_overflow);
tree op0 = RECUR (TREE_OPERAND (t, 0));
tree op1 = RECUR (TREE_OPERAND (t, 1));
tree r = build_x_binary_op
Index: cp/typeck.c
===
--- cp/typeck.c (revision 217282)
+++ cp/typeck.c (working copy)
@@ -4328,7 +4328,8 @@ cp_build_binary_op (location_t location,
{
  if ((complain & tf_warning)
  && c_inhibit_evaluation_warnings == 0)
-   warning (0, "left shift count is negative");
+   warning (OPT_Wshift_count_negative,
+"left shift count is negative");
}
  else if (compare_tree_int (const_op1,
  

Re: [C++ Patch] PR 63265

2014-11-10 Thread Jakub Jelinek
On Mon, Nov 10, 2014 at 05:32:49PM +0100, Paolo Carlini wrote:
>   PR c++/63265
>   * c-family/c.opt ([Wshift-count-negative, Wshift-count-overflow]): Add.

Note, c-family/ has its own ChangeLog.

Jakub


Re: [PING][PATCH][AARCH64]Fix PR63424 by adding v2di3 pattern

2014-11-10 Thread Renlin Li

On 06/11/14 15:00, Renlin Li wrote:

Hi all,

Dose anybody have time to review this?

Kind regards,
Renlin Li

On 31/10/14 14:51, Renlin Li wrote:

Hi all,

This is a patch which will fix PR63424.

It implements signed/unsigned max/min pattern for V2DI mode in terms 
of vcondv2div2di pattern.


In this particular case, VEC_COND_EXPR (V2DImode) is generated as 
aarch64 target supports it (vcond for VALL). The 
VEC_COND_EXPR will further folded into MIN_EXPR/MAX_EXPR in dom pass 
unconditionally. Later in expand pass, the compiler tries to expand 
min_expr using standard RTL operation. It fails, because aarch64 
target don't have minv2di3 pattern implemented. It then tries to 
generate conditional move and compare&branch sequence, all fails. At 
last it falls into libfunc call, no luck either. An ICE to complain 
about this.


aarch64-none-elf toolchain has been tested on the model, no regressions.

Is it Okay for trunk?

gcc/ChangeLog:

2014-10-31  Renlin Li  
PR target/63424
* config/aarch64/aarch64-simd.md (v2di3): New.

gcc/testsuite/ChangeLog:

2014-10-31  Renlin Li  
PR target/63424
* gcc.target/aarch64/pr63424.c: New.



Hi,

Dose anybody have time to review this?

Thank you so much!

Regards,
Renlin Li



[PING][PATCH]Partially fix PR61529, bound basic block frequency

2014-11-10 Thread Renlin Li

On 06/11/14 18:07, Renlin Li wrote:

On 06/11/14 17:59, Teresa Johnson wrote:

Thanks for fixing the test case. Can you also add the comment I
suggested to the source change?

Please add a comment that this is needed due to insane incoming 
frequencies.




Sorry, I mistakenly add it to the ChangeLog. Should be correct now.


x86_64-unknown-linux-gnu bootstrap and regression test have been done, 
no new issue.

aarch64-none-elf toolchain has been test on the model. No new regression.

gcc/ChangeLog:

2014-11-06  Renlin Li 
PR middle-end/61529
* tree-ssa-threadupdate.c (compute_path_counts): Bound path_in_freq.

gcc/testsuite/ChangeLog:

2014-11-06  Renlin Li 
PR middle-end/61529
* gcc.dg/pr61529.c: New.


Hi,

Can anybody help to review or approve this?

Kind regards,
Renlin Li




Re: [PING][PATCH]Partially fix PR61529, bound basic block frequency

2014-11-10 Thread Teresa Johnson
Hi Renlin,

Looks like Jeff already approved it:

>Can you add a testcase please?  With a testcase, this patch is OK for the 
>trunk.

Teresa

On Mon, Nov 10, 2014 at 8:59 AM, Renlin Li  wrote:
> On 06/11/14 18:07, Renlin Li wrote:
>>
>> On 06/11/14 17:59, Teresa Johnson wrote:
>>>
>>> Thanks for fixing the test case. Can you also add the comment I
>>> suggested to the source change?
>>>
 Please add a comment that this is needed due to insane incoming
 frequencies.

>>
>> Sorry, I mistakenly add it to the ChangeLog. Should be correct now.
>>
>>
>> x86_64-unknown-linux-gnu bootstrap and regression test have been done, no
>> new issue.
>> aarch64-none-elf toolchain has been test on the model. No new regression.
>>
>> gcc/ChangeLog:
>>
>> 2014-11-06  Renlin Li 
>> PR middle-end/61529
>> * tree-ssa-threadupdate.c (compute_path_counts): Bound path_in_freq.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2014-11-06  Renlin Li 
>> PR middle-end/61529
>> * gcc.dg/pr61529.c: New.
>
>
> Hi,
>
> Can anybody help to review or approve this?
>
> Kind regards,
> Renlin Li
>
>



-- 
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413


Re: Add the latest C++ SD-6 additions.

2014-11-10 Thread Jason Merrill

On 11/10/2014 10:55 AM, Ed Smith-Rowland wrote:

Would a 4.9 version be accepted?


Sure.

What do you think about defining the macros for unsupported features to 
0 rather than leaving them undefined?  The document doesn't seem to specify.


Jason



Re: [C++ Patch] PR 63265

2014-11-10 Thread Jason Merrill

On 11/10/2014 12:16 PM, Jason Merrill wrote:

I don't think we want to suppress this warning in general.  The problem
in this PR is that the warning code is failing to recognize that the
first operand is constant false.


But adding the warning options is OK.

Jason




Re: [C++ Patch] PR 63265

2014-11-10 Thread Jason Merrill
I don't think we want to suppress this warning in general.  The problem 
in this PR is that the warning code is failing to recognize that the 
first operand is constant false.


Jason


Re: [PATCH][Revisedx2] Fix PR63750

2014-11-10 Thread Jack Howarth
Also confirmed that FX's proposed string.diff patch solves both
PR63699 and PR63750 on x86_64-apple-darwin13 against Xcode 6.1.

On Mon, Nov 10, 2014 at 9:58 AM, FX  wrote:
>> My knowledge of C++ is limited, but I think this additional patch to 
>> wide-int.h is the proper fix to the issue reported by Jack, no?
>> I’m bootstrapping it right now, it already passed stage 2.
>
> Boostrapped succeeded on x86_64-apple-darwin14.
> OK to commit to trunk?
>


Re: [C++ Patch] PR 63265

2014-11-10 Thread Paolo Carlini

Hi,

On 11/10/2014 06:16 PM, Jason Merrill wrote:

On 11/10/2014 12:16 PM, Jason Merrill wrote:

I don't think we want to suppress this warning in general.  The problem
in this PR is that the warning code is failing to recognize that the
first operand is constant false.


But adding the warning options is OK.
Thanks, but I just noticed that the patch is incomplete about that, 
doesn't handle right shifts. Let's say that for time being I'm going to 
resubmit a complete patch for the warnings and I unassign myself from 
the regression proper.


Paolo.


Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s

2014-11-10 Thread Michael Haubenwallner


Am 2014-11-10 17:06, schrieb David Edelsohn:
> On Mon, Nov 10, 2014 at 4:59 AM, Michael Haubenwallner
>  wrote:
>>
>> Am 2014-11-07 20:52, schrieb David Edelsohn:
>>> First, please explicitly copy me on AIX or PowerPC patches sent to 
>>> gcc-patches.
>>>
>>> I don't have a fundamental objection to including this option, but
>>> note that Richi, Honza and I have discovered that using AIX runtime
>>> linking option interacts badly with some GCC optimizations and can
>>> result in applications that hang in a loop.
>>
>> Feels like adding the "aix-soname" linking procedure becomes more important:
>>
>>> All code on AIX is position independent (PIC) by default.  Executables
>>> and shared libraries essentially are PIE.  Because of this, AIX does
>>> not provide separate "static" libraries and one can link statically
>>> with a shared library.
>>>
>>> Creating a library enabled for runtime linking with -G (-brtl), causes
>>> a lot of problems, including a newly recognized failure mode.  Without
>>> careful control over AIX symbol export, all global calls with use
>>> glink code (equivalent to ELF PLTs). This also creates a TOC entry for
>>> every global call, possibly overflowing the TOC.
>>
>> About to define "careful control over AIX symbol export":
>> The symbols listed in the import file are those found in the object files
>> only, not the ones created at linktime (like __GLOBAL*) or from the static
>> objects found in libc.a. While I do this in libtool from the beginning here,
>> I have had a helper script wrapping ld to support '--soname=' for non-libtool
>> packages, where creating the import file from the final shared object also
>> included static libc-provided symbols, which turned out as dependency 
>> pitfall.
> 
> AIX added ELF-like visibility support to XCOFF, which would be
> preferred.  Except it was not added in a formal release, like AIX 8.1
> and apparently was back-ported to at least AIX 6.1, so its difficult
> to phase in the support. One would need to add a configure test for
> the feature and not all users are upgrading the system. So one cannot
> build and distribute "GCC for AIX 7.1" and know the feature is
> available in the system tools.  GCC builds would be incompatible and
> object files, libraries, executables created by GCC would be
> incompatible.  Basically, a mess.

As I've seen the "weak" information on an older AIX 5.3 TL8 already:
Is this visibility support something different than what "nm -l" or "nm -P" 
shows?

>> While I haven't focussed on nor explicitly tested, I do believe that this
>> also solves problems with global C++ constructor/destructor call orders.
> 
> Why? There still is the problem of the AIX kernel runtime loader
> ordering dependent shared objects.

Feels like I indeed haven't digged deep enough into that topic yet:
To be ignored here then.

>>> But the main problem is GCC uses aliases and functions declared as
>>> weak to support some C++ features.
>>
>> This is another reason why I do force runtime linking for our application,
>> which uses these C++ features while its main target platform is Linux.
> 
> You have not explained how this has any fix / benefit affecting the
> problem, other than separate shared and static libraries.  Forcing
> runtime linking seems irrelevant.  It was linking shared before and
> linking shared after your patch (with runtime linking) so the net
> effect is zero.

My main reason here is to allow for *filename*-based sharedlib versioning,
which I haven't been able to achive without import files.
In-archive versioning is a pita from a package manager's point of view.

For a second reason:
Due to its Linux-centric history (well, HP-UX and Solaris before), our
application architecture does rely on runtime linking in some corner cases.
This is why I force that for AIX in our development- and runtime-platform,
which is similar to /opt/freeware/, but based on Gentoo Prefix.

For a third reason (maybe I don't have deep enough insight as well):
If I understand correctly, you switched to build libstdc++ without runtime
linking, because of problems when linking statically against the rtl-enabled
libstdc++, no? For this case, by incident "aix-soname" does prevent shared
objects built with runtime linking from being statically linked.

For another reason: I can imaging to provide an rtl_enable'd libc.so as
well, to allow for easier use of memory debuggers that intercept the
malloc/free &co libc calls... But AFAICT these rely on every sharedlib
to be built with runtime linking enabled.

> Again, runtime linking of all global symbols affects performance and
> bloats the TOC, making TOC overflow more likely.

Well, I don't have need to care for performance that much. So do I force
-mminimal-toc as well, where the only reason I have seen so far to avoid
the -bbigtoc linker flag instead is that gdb has problems with that.

> I don't have a fundamental objection to the patch, but you have not
> really responded to the potential problems and

Re: [PATCH] c++98/mt_allcoator.cc: Fix assumption sizeof(void *) == sizeof(size_t)

2014-11-10 Thread Joel Sherrill
cc'ing since both lists should be included.

The m32c has 24-bit pointers and 16-bit size_t. This changes
pushing a pointer through a size_t to pushing it through a
uintptr_t.

--joel
On 11/10/2014 9:36 AM, Joel Sherrill wrote:
> 2014-11-10  Joel Sherrill 
>
>   * src/c++98/mt_allocator.cc: Fix assumption that sizeof(void *) is
>   equal to sizeof(size_t). The m32c breaks this assumption.
> ---
>  libstdc++-v3/src/c++98/mt_allocator.cc | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libstdc++-v3/src/c++98/mt_allocator.cc 
> b/libstdc++-v3/src/c++98/mt_allocator.cc
> index 38e17df..04dd8ad 100644
> --- a/libstdc++-v3/src/c++98/mt_allocator.cc
> +++ b/libstdc++-v3/src/c++98/mt_allocator.cc
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  namespace
>  {
> @@ -74,7 +75,7 @@ namespace
>  __freelist& freelist = get_freelist();
>  {
>__gnu_cxx::__scoped_lock sentry(get_freelist_mutex());
> -  size_t _M_id = reinterpret_cast(__id);
> +  uintptr_t _M_id = reinterpret_cast(__id);
>
>typedef __gnu_cxx::__pool::_Thread_record _Thread_record;
>_Thread_record* __tr = &freelist._M_thread_freelist_array[_M_id - 1];
> @@ -627,7 +628,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>{
>   __freelist& freelist = get_freelist();
>   void* v = __gthread_getspecific(freelist._M_key);
> - size_t _M_id = (size_t)v;
> + uintptr_t _M_id = (uintptr_t)v;
>   if (_M_id == 0)
> {
>   {

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985



PATCH: PR tree-optimization/63778: [5 Regression] Segfault with r217178 building 416.gamess from cpu2006

2014-11-10 Thread H.J. Lu
I checked in this patch to add a testcase for PR tree-optimization/63778.

H.J.
---
Index: ChangeLog
===
--- ChangeLog   (revision 217303)
+++ ChangeLog   (working copy)
@@ -1,3 +1,8 @@
+2014-11-10  H.J. Lu  
+
+   PR tree-optimization/63778
+   * gfortran.dg/pr63778.f: New test.
+
 2014-11-10  Renlin Li  
 
PR middle-end/61529
Index: gfortran.dg/pr63778.f
===
--- gfortran.dg/pr63778.f   (revision 0)
+++ gfortran.dg/pr63778.f   (working copy)
@@ -0,0 +1,46 @@
+! { dg-do compile }
+! { dg-options "-O3 -ffast-math" }
+
+  SUBROUTINE ZUNG2L( M, N, K, A, LDA, TAU, WORK, INFO )
+  COMPLEX*16 A( LDA, * ), TAU( * ), WORK( * )
+  IF( M.LT.0 ) THEN
+  END IF
+ CALL ZLARF( 'LEFT', M-N+II, II-1, A( 1, II ), 1, TAU( I ), A,
+ $   LDA, WORK )
+ CALL ZSCAL( M-N+II-1, -TAU( I ), A( 1, II ), 1 )
+ A( M-N+II, II ) = ONE - TAU( I )
+  END
+  SUBROUTINE ZLARF( SIDE, M, N, V, INCV, TAU, C, LDC, WORK )
+  CHARACTER SIDE(*)
+  LOGICALLSAME
+  COMPLEX*16 C( LDC, * ), V(*), WORK(*), TAU
+  IF( LSAME( SIDE, 'L' ) ) THEN
+ IF( TAU.NE.ZERO ) THEN
+CALL ZGEMV( 'CONJUGATE TRANSPOSE', M, N, ONE, C, LDC, V,
+ $  INCV, ZERO, WORK, 1 )
+ END IF
+  END IF
+  END
+  LOGICAL  FUNCTION LSAME( CA, CB )
+  CHARACTER CA(*), CB(*)
+  END
+  SUBROUTINE ZGEMV ( TRANS, M, N, ALPHA, A, LDA, X, INCX,
+ $   BETA, Y, INCY )
+  COMPLEX*16 A( LDA, * ), X( * ), Y( * )
+  CHARACTER TRANS(*)
+  LOGICALLSAME
+  IF( LSAME( TRANS, 'N' ) )THEN
+ IF( INCY.EQ.1 )THEN
+   IF( X( JX ).NE.ZERO )THEN
+ Y( I ) = Y( I ) + TEMP*A( I, J )
+   END IF
+ END IF
+  END IF
+  END
+  SUBROUTINE  ZSCAL(N,ZA,ZX,INCX)
+  COMPLEX*16 ZA,ZX(1)
+  IF( N.LE.0 .OR. INCX.LE.0 )RETURN
+   20 DO 30 I = 1,N
+ZX(I) = ZA*ZX(I)
+   30 CONTINUE
+  END


Re: [PATCH][Revisedx2] Fix PR63750

2014-11-10 Thread Mike Stump
On Nov 10, 2014, at 6:58 AM, FX  wrote:
>> My knowledge of C++ is limited, but I think this additional patch to 
>> wide-int.h is the proper fix to the issue reported by Jack, no?
>> I’m bootstrapping it right now, it already passed stage 2.
> 
> Boostrapped succeeded on x86_64-apple-darwin14.
> OK to commit to trunk?

I’m ok with this version.

I’’ve asked Jack for the header in question that makes max/min ambiguous.  I 
think this is a bug in the system libraries, that said, I’m ok with working 
around the bug in the wide-int source code as expedient.  I think including 
string in system.h is unfortunate, and I think the whole 
do_not_use_toupper_with_safe_ctype thing is unfortunate.  Unless someone wants 
to reengineer ctype… or require the removal of string and all other system 
headers that are not in system.h…  I think this is as good as we can do for now.

Re: [PATCH][ARM] testsuite, use arm_eabi iso arm*-*-*eabi*

2014-11-10 Thread Mike Stump
On Nov 9, 2014, at 12:33 PM, Andreas Tobler  wrote:
> The upcoming FreeBSD ARM target does not have eabi in the target triplet. But 
> it is EABI based.

> Ok for trunk?

Ok.


[Patch] Add -Wshift-count-negative and -Wshift-count-overflow

2014-11-10 Thread Paolo Carlini

Hi again,

thus the below only adds the warnings. Would be mainline only of course.

Thanks!
Paolo.


2014-11-10  Paolo Carlini  

* doc/invoke.texi ([-Wshift-count-negative, -Wshift-count-overflow]):
Add.

/c-family
2014-11-10  Paolo Carlini  

* c.opt ([Wshift-count-negative, Wshift-count-overflow]): Add.

/cp
2014-11-10  Paolo Carlini  

* typeck.c (cp_build_binary_op): Use OPT_Wshift_count_negative and
OPT_Wshift_count_overflow in the warnings.

/c
2014-11-10  Paolo Carlini  

* c-typeck.c (build_binary_op): Use OPT_Wshift_count_negative and
OPT_Wshift_count_overflow in the warnings.

/testsuite
2014-11-10  Paolo Carlini  

* c-c++-common/Wshift-count-overflow-1.c: New.
* c-c++-common/Wshift-count-overflow-2.c: Likewise.
* c-c++-common/Wshift-count-negative-1.c: Likewise.
* c-c++-common/Wshift-count-negative-2.c: Likewise.
Index: c/c-typeck.c
===
--- c/c-typeck.c(revision 217282)
+++ c/c-typeck.c(working copy)
@@ -10491,7 +10491,8 @@ build_binary_op (location_t location, enum tree_co
{
  int_const = false;
  if (c_inhibit_evaluation_warnings == 0)
-   warning_at (location, 0, "right shift count is negative");
+   warning_at (location, OPT_Wshift_count_negative,
+   "right shift count is negative");
}
  else
{
@@ -10502,8 +10503,8 @@ build_binary_op (location_t location, enum tree_co
{
  int_const = false;
  if (c_inhibit_evaluation_warnings == 0)
-   warning_at (location, 0, "right shift count >= width "
-   "of type");
+   warning_at (location, OPT_Wshift_count_overflow,
+   "right shift count >= width of type");
}
}
}
@@ -10545,7 +10546,8 @@ build_binary_op (location_t location, enum tree_co
{
  int_const = false;
  if (c_inhibit_evaluation_warnings == 0)
-   warning_at (location, 0, "left shift count is negative");
+   warning_at (location, OPT_Wshift_count_negative,
+   "left shift count is negative");
}
 
  else if (compare_tree_int (op1, TYPE_PRECISION (type0)) >= 0)
@@ -10552,8 +10554,8 @@ build_binary_op (location_t location, enum tree_co
{
  int_const = false;
  if (c_inhibit_evaluation_warnings == 0)
-   warning_at (location, 0, "left shift count >= width of "
-   "type");
+   warning_at (location, OPT_Wshift_count_overflow,
+   "left shift count >= width of type");
}
}
 
Index: c-family/c.opt
===
--- c-family/c.opt  (revision 217282)
+++ c-family/c.opt  (working copy)
@@ -760,14 +760,22 @@ Wselector
 ObjC ObjC++ Var(warn_selector) Warning
 Warn if a selector has multiple methods
 
+Wsequence-point
+C ObjC C++ ObjC++ Var(warn_sequence_point) Warning LangEnabledBy(C ObjC C++ 
ObjC++,Wall)
+Warn about possible violations of sequence point rules
+
 Wshadow-ivar
 ObjC ObjC++ Var(warn_shadow_ivar) EnabledBy(Wshadow) Init(1) Warning
 Warn if a local declaration hides an instance variable
 
-Wsequence-point
-C ObjC C++ ObjC++ Var(warn_sequence_point) Warning LangEnabledBy(C ObjC C++ 
ObjC++,Wall)
-Warn about possible violations of sequence point rules
+Wshift-count-negative
+C ObjC C++ ObjC++ Var(warn_shift_count_negative) Init(1) Warning
+Warn if shift count is negative
 
+Wshift-count-overflow
+C ObjC C++ ObjC++ Var(warn_shift_count_overflow) Init(1) Warning
+Warn if shift count >= width of type
+
 Wsign-compare
 C ObjC C++ ObjC++ Var(warn_sign_compare) Warning LangEnabledBy(C++ ObjC++,Wall)
 Warn about signed-unsigned comparisons
Index: cp/typeck.c
===
--- cp/typeck.c (revision 217302)
+++ cp/typeck.c (working copy)
@@ -4280,7 +4280,8 @@ cp_build_binary_op (location_t location,
{
  if ((complain & tf_warning)
  && c_inhibit_evaluation_warnings == 0)
-   warning (0, "right shift count is negative");
+   warning (OPT_Wshift_count_negative,
+"right shift count is negative");
}
  else
{
@@ -4287,7 +4288,8 @@ cp_build_binary_op (location_t location,
  if (compare_tree_int (const_op1, TYPE_PRECISION (type0)) >= 0
  && (complain & tf_war

Re: [Patch, libstdc++/63775] Fix regex bracket expression parsing

2014-11-10 Thread Jonathan Wakely

On 09/11/14 10:17 -0800, Tim Shen wrote:

__matcher._M_add_equivalence_class(_M_value);
  else if (_M_match_token(_ScannerT::_S_token_char_class_name))
__matcher._M_add_character_class(_M_value, false);
-  else if (_M_try_char()) // [a
+  // POSIX doesn't permit '-' as a start-range char (say [a-z--0]),
+  // except that the '-' is the first character in the bracket expression


Should be "except when" in this comment


+  // ([--0]). ECMAScript treats all '-' after a range as a normal 
character.
+  // Also see above, where _M_expression_term gets called.
+  //
+  // As a result, POSIX rejects [-], but ECMAScript doesn't.
+  // Boost (1.57.0) always uses POSIX style even in its ECMAScript syntax.
+  // Clang (3.5) always uses ECMAScript style even in its POSIX syntax.
+  //
+  // It turns out that no one reads BNFs ;)


Ha :-)

OK for trunk with the small change above - thanks!



Re: [PATCH] c++98/mt_allcoator.cc: Fix assumption sizeof(void *) == sizeof(size_t)

2014-11-10 Thread Jonathan Wakely

On 10/11/14 12:01 -0600, Joel Sherrill wrote:

cc'ing since both lists should be included.

The m32c has 24-bit pointers and 16-bit size_t. This changes
pushing a pointer through a size_t to pushing it through a
uintptr_t.


I'm OK with this change if Paolo is.

If it breaks any targets without uintptr_t they can either add
 as Joseph suggested, or add some nasty #ifdef (it's only in
a .cc file not a public header ... and we don't really care about the
mt_allocator extension much now).



Re: RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?

2014-11-10 Thread Andi Kleen
Roman Gareev  writes:

> Hi Tobias,
>
> I've attached a patch which removes using of CLooG library from
> Graphite. Is it fine for trunk?

Could you please also remove -Werror by default from cloog?

Currently with LTO builds warnings in one of these libraries
usually break the build, unless --disable-werror is used.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only


Re: __float128 typeinfo

2014-11-10 Thread Jonathan Wakely

On 09/11/14 01:41 +0100, Marc Glisse wrote:

Hello,

I am digging out https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00637.html

It isn't completely clear if the libstdc++ part was accepted or not. I 
won't commit immediately (waiting on another patch), but I'd like to 
be ready.


The libstdc++ part is OK.



Re: [C++ PING^3] Re: [PATCH 5/5] Add illegal cilk checks to C++ front.

2014-11-10 Thread Andi Kleen
Andi Kleen  writes:

Ping!^3

> Andi Kleen  writes:
>
> Ping!^2
>
>> Andi Kleen  writes:
>>
>> Ping!
>>
>> Can someone from the C++ side please approve this patch?
>> That's the only patch not approved in this patch kit, but blocking
>> the commit.
>>
>> -Andi
>>
>>> From: Andi Kleen 
>>>
>>> Add calls for several illegal Cilk cases to the C++ frontend.
>>> C++ usually doesn't ICE unlike C on illegal cilk, but it's
>>> better to match C in what is allowed and what is not.
>>>
>>> if (_Cilk_spawn ...) is still not errored, but at least it doesn't ICE.
>>>
>>> gcc/cp/:
>>>
>>> 2014-09-30  Andi Kleen  
>>>
>>> * semantics.c (finish_goto_stmt): Call check_no_cilk.
>>> (finish_while_stmt_cond): Dito.
>>> (finish_do_stmt): Dito.
>>> (finish_for_cond): Dito.
>>> (finish_switch_cond): Dito.
>>> ---
>>>  gcc/cp/semantics.c | 12 
>>>  1 file changed, 12 insertions(+)
>>>
>>> diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
>>> index 7569826..9ca03be 100644
>>> --- a/gcc/cp/semantics.c
>>> +++ b/gcc/cp/semantics.c
>>> @@ -621,6 +621,8 @@ finish_goto_stmt (tree destination)
>>>  TREE_USED (destination) = 1;
>>>else
>>>  {
>>> +  if (check_no_cilk (destination, "as a computed goto expression"))
>>> +   destination = error_mark_node;
>>>destination = mark_rvalue_use (destination);
>>>if (!processing_template_decl)
>>> {
>>> @@ -792,6 +794,8 @@ begin_while_stmt (void)
>>>  void
>>>  finish_while_stmt_cond (tree cond, tree while_stmt, bool ivdep)
>>>  {
>>> +  if (check_no_cilk (cond, "as a condition for while statement"))
>>> +cond = error_mark_node;
>>>cond = maybe_convert_cond (cond);
>>>finish_cond (&WHILE_COND (while_stmt), cond);
>>>begin_maybe_infinite_loop (cond);
>>> @@ -847,6 +851,8 @@ finish_do_body (tree do_stmt)
>>>  void
>>>  finish_do_stmt (tree cond, tree do_stmt, bool ivdep)
>>>  {
>>> +  if (check_no_cilk (cond, "as a condition for a do-while statement"))
>>> +cond = error_mark_node;
>>>cond = maybe_convert_cond (cond);
>>>end_maybe_infinite_loop (cond);
>>>if (ivdep && cond != error_mark_node)
>>> @@ -956,6 +962,8 @@ finish_for_init_stmt (tree for_stmt)
>>>  void
>>>  finish_for_cond (tree cond, tree for_stmt, bool ivdep)
>>>  {
>>> +  if (check_no_cilk (cond, "in a condition for a for-loop"))
>>> +cond = error_mark_node;
>>>cond = maybe_convert_cond (cond);
>>>finish_cond (&FOR_COND (for_stmt), cond);
>>>begin_maybe_infinite_loop (cond);
>>> @@ -1118,6 +1126,10 @@ void
>>>  finish_switch_cond (tree cond, tree switch_stmt)
>>>  {
>>>tree orig_type = NULL;
>>> +
>>> +  if (check_no_cilk (cond, "as a condition for switch statement"))
>>> +cond = error_mark_node;
>>> +
>>>if (!processing_template_decl)
>>>  {
>>>/* Convert the condition to an integer or enumeration type.  */

-- 
a...@linux.intel.com -- Speaking for myself only


[PING] Re: [PATCH] Add memory barriers to xbegin/xend/xabort

2014-11-10 Thread Andi Kleen
Andi Kleen  writes:

Ping!

> From: Andi Kleen 
>
> xbegin/xend/xabort were missing memory barriers. This can
> lead to memory operations being moved out of transactions, which would
> cause unexpected races.
>
> Always generate implicit memory barriers for these intrinsics.
>
> The compat header versions always generated memory barriers,
> so this also improves compatibility.
>
> Passes test suite. Ok for release branches?
>
> gcc/:
>
> 2014-10-28  Andi Kleen  
>
>   PR target/63672
>   * config/i386/i386.c (ix86_expand_builtin): Generate memory
>   barrier after abort.
>   * config/i386/i386.md (xbegin): Add memory barrier.
>   (xend): Rename to ...
>   (xend_1): New. Generate memory barrier and emit xend.
> ---
>  gcc/config/i386/i386.c  |  1 +
>  gcc/config/i386/i386.md | 18 +-
>  2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index ec3e056..ec0df40 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -36413,6 +36413,7 @@ addcarryx:
> return const0_rtx;
>   }
>emit_insn (gen_xabort (op0));
> +  emit_insn (gen_memory_blockage ());
>return 0;
>  
>  default:
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index 7ba07c3..3544e60 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -18530,6 +18530,9 @@
>  
>emit_move_insn (operands[0], ax_reg);
>  
> +  operands[0] = gen_rtx_MEM (BLKmode, gen_rtx_SCRATCH (Pmode));
> +  MEM_VOLATILE_P (operands[0]) = 1;
> +
>DONE;
>  })
>  
> @@ -18546,13 +18549,26 @@
>[(set_attr "type" "other")
> (set_attr "length" "6")])
>  
> -(define_insn "xend"
> +(define_insn "xend_1"
>[(unspec_volatile [(const_int 0)] UNSPECV_XEND)]
>"TARGET_RTM"
>"xend"
>[(set_attr "type" "other")
> (set_attr "length" "3")])
>  
> +(define_expand "xend"
> +  [(set (match_dup 0)
> + (unspec:BLK [(const_int 0)] UNSPECV_XEND))] /* or match_dup 0 ? */
> +  "TARGET_RTM"
> +{
> +  emit_insn (gen_xend_1 ());
> +
> +  operands[0] = gen_rtx_MEM (BLKmode, gen_rtx_SCRATCH (Pmode));
> +  MEM_VOLATILE_P (operands[0]) = 1;
> +
> +  DONE;
> +})
> +
>  (define_insn "xabort"
>[(unspec_volatile [(match_operand:SI 0 "const_0_to_255_operand" "n")]
>   UNSPECV_XABORT)]

-- 
a...@linux.intel.com -- Speaking for myself only


Re: [Patch] Add -Wshift-count-negative and -Wshift-count-overflow

2014-11-10 Thread Jason Merrill

OK.

Jason


Re: [PR c/52952] More precise locations within format strings

2014-11-10 Thread Joseph Myers
On Sat, 8 Nov 2014, Manuel López-Ibáñez wrote:

> On 7 November 2014 22:39, Joseph Myers  wrote:
> >> Neither Per nor Tom are active in GCC anymore. If the FE maintainers
> >> do not feel comfortable reviewing line-map changes, could you nominate
> >> Dodji as line-map maintainer if he is willing to accept it? I think he
> >> is currently the person that understands that code best.
> >
> > I think Dodji as diagnostics maintainer is better placed than I am to
> > review line-map patches.
> 
> Then, do you mean that line-map falls under the reach of the
> diagnostics maintainer? I agree, but Dodji himself does not seem to be
> sure about this:

I think we should consider it to be covered by diagnostics maintainers.

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

Re: [PATCH driver/36312] should refuse to overwrite input file with output file

2014-11-10 Thread Joseph Myers
On Sat, 8 Nov 2014, Manuel López-Ibáñez wrote:

> This patch is a minor variant of the one approved here:
> 
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00246.html
> 
> fixing the problem with linker parameters (which are stored in infiles).
> 
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00391.html
> 
> The only part that has changed, and thus requires approval, is in
> gcc/gcc.c, in particular the condition:
> 
> +if ((!infiles[i].language || infiles[i].language[0] != '*')
> +&& canonical_filename_eq (infiles[i].name, output_file))
> 
> is new.

That part is OK.


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

Re: [PATCH][Revisedx2] Fix PR63750

2014-11-10 Thread Mike Stump
On Nov 10, 2014, at 10:10 AM, Mike Stump  wrote:
> I’’ve asked Jack for the header in question that makes max/min ambiguous.

Ok, found it, page 903 of c++14.  Also in the 97 version.  We need the wi:: 
qualifications for wide-int with min and max.  That part of the patch is Ok.


Re: [PATCH] c++98/mt_allcoator.cc: Fix assumption sizeof(void *) == sizeof(size_t)

2014-11-10 Thread Paolo Carlini

Hi,

On 11/10/2014 07:34 PM, Jonathan Wakely wrote:

On 10/11/14 12:01 -0600, Joel Sherrill wrote:

cc'ing since both lists should be included.

The m32c has 24-bit pointers and 16-bit size_t. This changes
pushing a pointer through a size_t to pushing it through a
uintptr_t.


I'm OK with this change if Paolo is.
No problem with the experiment (frankly, I'm not at all sure that the 
targets not providing  are *that* much uncommon than the 
target which we are fixing with the patch), but please add a comment 
about  in the code, then if bootstrap actually breaks the 
issue is clear...


Paolo.


Re: [RFC, C] add warning for unpromoted bit-field uses

2014-11-10 Thread Joseph Myers
On Sat, 8 Nov 2014, Sandra Loosemore wrote:

> I thought that the point at which integral promotions are applied would be a
> good place to catch this, as it excludes places where bit-fields are already
> being converted by assignment or explicit cast.  I think we also want to

Formally of course that's the place where C and C++ differ, but 
practically that seems likely to catch cases such as

  sp->b <<= 1;

where the way the values are used means it doesn't actually matter what 
type was used (modulo undefined integer overflow cases).  It might avoid 
such unnecessary warnings if warnings were instead given at the time such 
a bit-field type wider than int is converted to a type wider than the 
bit-field, if the expression being converted is the result of some 
arithmetic operation rather than just a direct reference to a bit-field 
member of a structure.

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


[PATCH v4] warning about const multidimensional array as function parameter

2014-11-10 Thread Martin Uecker

For completeness, this version adds the missing warning if the 
'const' is lost in a conditional expression with a void* on the
other branch. The only code change relative to the previous
version is in c/c-typeck.c in build_conditional_expr (otherwise 
I added the warnings to the testsuite and fixed some typos and 
trailing whitespace errors).

I would rather have the 'const' propagate to the result
of the conditional expression as with regular pointers to
const, but I do not see an easy way to make the warnings
(or errors) which could result from this be dependent on 
-Wdiscarded-array-qualifiers.

Joseph Myers :

> On Thu, 6 Nov 2014, Martin Uecker wrote:
> > This patch implements a new proposed behaviour for 
> > pointers to arrays with qualifiers in C.
> > 
> > I found some time to work on this again, so here is another 
> > revision. Main changes to the previous version of the patch:
> > 
> > - add more test cases for cast from/to (const) void*
> > - correctly uses pedwarn/warning_at
> 
> Thanks.  I'll review this in more detail later, but I suspect it's quite 
> close to being ready to go in once the paperwork has been processed.

Thank you. I got the form and have sent it back, but did not get
a reply yet.
 
Martin


2014-11-10 Martin Uecker 

* doc/invoke.texi: Document -Wdiscarded-array-qualifiers
* doc/extend.texi: Document new behavior for pointers to arrays with 
qualifies
c/
* c-typeck.c: New behavious for pointers to arrays with qualifiers
(common-pointer-type): For pointers to arrays take qualifiers from 
element type.
(build_conditional_expr): Add warnings for lost qualifiers.
(comp-target-types): Allow pointers to arrays with different qualifiers.
(convert-for-assignment): Adapt warnings for discarded qualifiers. Add
WARNING_FOR_QUALIFIERS macro and rename WARN_FOR_QUALIFIERS 
to PEDWARN_FOR_QUALIFIERS.
c-family/
* c.opt (Wdiscarded-array-qualifiers): New option
testsuite/
* gcc.dg/Wwrite-strings-1.c: Change dg-warning
* gcc.dg/array-quals-1.c: Use -Wno-discarded-array-qualifiers
* gcc.dg/array-quals-2.c: Change dg-options, dg-warning
* gcc.dg/pointer-array-atomic.c: New test
* gcc.dg/pointer-array-quals-1.c: New test
* gcc.dg/pointer-array-quals-2.c: New test (-pedantic-errors)




Index: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c(Revision 217273)
+++ gcc/c/c-typeck.c(Arbeitskopie)
@@ -673,12 +673,13 @@ common_pointer_type (tree t1, tree t2)
 mv2 = TYPE_MAIN_VARIANT (pointed_to_2);
   target = composite_type (mv1, mv2);
 
+  /* Strip array types to get correct qualifier for pointers to arrays */
+  quals1 = TYPE_QUALS_NO_ADDR_SPACE (strip_array_types (pointed_to_1));
+  quals2 = TYPE_QUALS_NO_ADDR_SPACE (strip_array_types (pointed_to_2));
+
   /* For function types do not merge const qualifiers, but drop them
  if used inconsistently.  The middle-end uses these to mark const
  and noreturn functions.  */
-  quals1 = TYPE_QUALS_NO_ADDR_SPACE (pointed_to_1);
-  quals2 = TYPE_QUALS_NO_ADDR_SPACE (pointed_to_2);
-
   if (TREE_CODE (pointed_to_1) == FUNCTION_TYPE)
 target_quals = (quals1 & quals2);
   else
@@ -1224,6 +1225,7 @@ static int
 comp_target_types (location_t location, tree ttl, tree ttr)
 {
   int val;
+  int val_ped;
   tree mvl = TREE_TYPE (ttl);
   tree mvr = TREE_TYPE (ttr);
   addr_space_t asl = TYPE_ADDR_SPACE (mvl);
@@ -1235,19 +1237,32 @@ comp_target_types (location_t location, tree ttl,
   if (!addr_space_superset (asl, asr, &as_common))
 return 0;
 
-  /* Do not lose qualifiers on element types of array types that are
- pointer targets by taking their TYPE_MAIN_VARIANT.  */
-  if (TREE_CODE (mvl) != ARRAY_TYPE)
-mvl = (TYPE_ATOMIC (mvl)
-  ? c_build_qualified_type (TYPE_MAIN_VARIANT (mvl), TYPE_QUAL_ATOMIC)
-  : TYPE_MAIN_VARIANT (mvl));
-  if (TREE_CODE (mvr) != ARRAY_TYPE)
-mvr = (TYPE_ATOMIC (mvr)
-  ? c_build_qualified_type (TYPE_MAIN_VARIANT (mvr), TYPE_QUAL_ATOMIC)
-  : TYPE_MAIN_VARIANT (mvr));
+  /* For pedantic record result of comptypes on arrays before losing
+ qualifiers on the element type below. */
+  val_ped = 1;
+
+  if (TREE_CODE (mvl) == ARRAY_TYPE
+  && TREE_CODE (mvr) == ARRAY_TYPE)
+val_ped = comptypes (mvl, mvr);
+
+  /* Qualifiers on element types of array types that are
+ pointer targets are lost by taking their TYPE_MAIN_VARIANT.  */
+
+  mvl = (TYPE_ATOMIC (strip_array_types (mvl))
+? c_build_qualified_type (TYPE_MAIN_VARIANT (mvl), TYPE_QUAL_ATOMIC)
+: TYPE_MAIN_VARIANT (mvl));
+
+  mvr = (TYPE_ATOMIC (strip_array_types (mvr))
+? c_build_qualified_type (TYPE_MAIN_VARIANT (mvr), TYPE_QUAL_ATOMIC)
+: TYPE_MAIN_VARIANT (mvr));
+
   enum_and_int_p = false;
   val = comptypes_check_enum_int (mvl, mvr, &enum_and_int_p);
 
+  if (val == 1 && val_p

Re: [RFC, C] add warning for unpromoted bit-field uses

2014-11-10 Thread Joseph Myers
On Sun, 9 Nov 2014, Sandra Loosemore wrote:

> Hrmmm.  In C, sp->a has type "3-bit unsigned integer" which is promoted to int
> by the integral promotions since all values are representable as int.   sp->c
> has type "5-bit unsigned integer" which is likewise promoted to int.  In C++,
> sp->a has type "unsigned char" and sp->c has type "unsigned long long".  By
> the C++ conversion rules, "unsigned char" is promoted to int (again since all
> values are representable), and "unsigned long long" is not promoted to
> anything else.

But C++ does still promote the unsigned long long:5 bit-field to int (4.5 
[conv.prom]#5, in C++11: "A prvalue for an integral bit-field (9.6) can be 
converted to a prvalue of type int if int can represent all the values of 
the bit-field; otherwise, it can be converted to unsigned int if unsigned 
int can represent all the values of the bit-field. If the bit-field is 
larger yet, no integral promotion applies to it. If the bit-field has an 
enumerated type, it is treated as any other value of that type for 
promotion purposes.").

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


Re: RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?

2014-11-10 Thread Roman Gareev
> Sure. We should drop the flag in these test cases.
>
> This seems to make sense, as they now test something different and the flag
> removal would reflect this.
>
> I personally would include this in the same patch. Would this be difficult?

I don’t think that it could be difficult. I just wanted to reduce the
size of a patch which can be found below.



-- 
Cheers, Roman Gareev.
2014-11-9 Roman Gareev  

[gcc/]

* Makefile.in: Remove the compilation of graphite-clast-to-gimple.o.
* common.opt: Remove using of fgraphite-code-generator flag.
* flag-types.h: Likewise.
* graphite.c: Remove using of CLooG.
* graphite-blocking.c: Likewise.
* graphite-dependences.c: Likewise.
* graphite-poly.c: Likewise.
* graphite-poly.h: Likewise.
* graphite-scop-detection.c: Likewise.
* graphite-sese-to-poly.c: Likewise.
* graphite-clast-to-gimple.c: Removed.
* graphite-clast-to-gimple.h: Likewise.
* graphite-htab.h: Likewise.

[gcc/testsuite]

* gcc.dg/graphite/isl-ast-gen-blocks-1.c: Remove using of
fgraphite-code-generator flag.
* gcc.dg/graphite/isl-ast-gen-blocks-2.c:
* gcc.dg/graphite/isl-ast-gen-blocks-3.c:
* gcc.dg/graphite/isl-ast-gen-user-1.c:
* gcc.dg/graphite/isl-codegen-loop-dumping.c:
* gcc.dg/graphite/pr35356-2.c:
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 217264)
+++ gcc/Makefile.in (working copy)
@@ -1244,7 +1244,6 @@
graphds.o \
graphite.o \
graphite-blocking.o \
-   graphite-clast-to-gimple.o \
graphite-isl-ast-to-gimple.o \
graphite-dependences.o \
graphite-interchange.o \
Index: gcc/common.opt
===
--- gcc/common.opt  (revision 217264)
+++ gcc/common.opt  (working copy)
@@ -1293,20 +1293,7 @@
 fgraphite-identity
 Common Report Var(flag_graphite_identity) Optimization
 Enable Graphite Identity transformation
- 
-fgraphite-code-generator=
-Common Report RejectNegative Joined Optimization Enum(fgraphite_generator) 
Var(flag_graphite_code_gen) Init(FGRAPHITE_CODE_GEN_ISL)
-Choose code generator of Graphite
 
-Enum
-Name(fgraphite_generator) Type(enum fgraphite_generator) UnknownError(unknown 
code generator of graphite %qs)
-
-EnumValue
-Enum(fgraphite_generator) String(isl) Value(FGRAPHITE_CODE_GEN_ISL)
-
-EnumValue
-Enum(fgraphite_generator) String(cloog) Value(FGRAPHITE_CODE_GEN_CLOOG)
-
 fhoist-adjacent-loads
 Common Report Var(flag_hoist_adjacent_loads) Optimization
 Enable hoisting adjacent loads to encourage generating conditional move
Index: gcc/flag-types.h
===
--- gcc/flag-types.h(revision 217264)
+++ gcc/flag-types.h(working copy)
@@ -263,10 +263,4 @@
   LTO_PARTITION_MAX = 4
 };
 
-/* The code generator used by graphite */
-enum fgraphite_generator {
-  FGRAPHITE_CODE_GEN_ISL = 0,
-  FGRAPHITE_CODE_GEN_CLOOG = 1
-};
-
 #endif /* ! GCC_FLAG_TYPES_H */
Index: gcc/graphite-blocking.c
===
--- gcc/graphite-blocking.c (revision 217264)
+++ gcc/graphite-blocking.c (working copy)
@@ -28,11 +28,7 @@
 #include 
 #include 
 #include 
-#ifdef HAVE_cloog
-#include 
-#include 
 #endif
-#endif
 
 #include "system.h"
 #include "coretypes.h"
Index: gcc/graphite-clast-to-gimple.c
===
--- gcc/graphite-clast-to-gimple.c  (revision 217264)
+++ gcc/graphite-clast-to-gimple.c  (working copy)
@@ -1,1736 +0,0 @@
-/* Translation of CLAST (CLooG AST) to Gimple.
-   Copyright (C) 2009-2014 Free Software Foundation, Inc.
-   Contributed by Sebastian Pop .
-
-This file is part of GCC.
-
-GCC is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 3, or (at your option)
-any later version.
-
-GCC is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with GCC; see the file COPYING3.  If not see
-.  */
-
-#include "config.h"
-
-#ifdef HAVE_cloog
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#if defined(__cplusplus)
-extern "C" {
-#endif
-#include 
-#if defined(__cplusplus)
-}
-#endif
-#include 
-#include 
-#endif
-
-#include "system.h"
-#include "coretypes.h"
-#include "diagnostic-core.h"
-#include "tree.h"
-#include "predict.h"
-#include "vec.h"
-#include "hashtab.h"
-#include "hash-set.h"
-

Re: [PATCH 5/5] Add illegal cilk checks to C++ front.

2014-11-10 Thread Andi Kleen
On Sun, Nov 09, 2014 at 11:03:50PM -0600, Jason Merrill wrote:
> On 10/01/2014 11:26 PM, Andi Kleen wrote:
> >+  if (check_no_cilk (cond, "in a condition for a for-loop"))
> 
> Why is this one "in" while the others are "as"?

I think "in" was somewhere hard coded in the test suite
and I wanted to minimize test suite changes. So I tried
to keep the existing messages the same as before.

> The patch is OK in any case.
> 
> Please ping me directly on C++ patches.

Ok.  Thanks.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.


Re: RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?

2014-11-10 Thread Tobias Grosser

On 10.11.2014 20:14, Roman Gareev wrote:

Sure. We should drop the flag in these test cases.

This seems to make sense, as they now test something different and the flag
removal would reflect this.

I personally would include this in the same patch. Would this be difficult?


I don’t think that it could be difficult. I just wanted to reduce the
size of a patch which can be found below.


Thanks!

This LGTM if it passes tests.

Tobias


Re: RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?

2014-11-10 Thread Jack Howarth
 Is the current isl 0.12.2 in infrastructure entirely sufficient
to replace cloog-isl. or should the ABI compatibility changes be made
to graphite to allow gcc 5.0 to be transitioned to the isl 0.14
release? Especially if any graphite changes might be made before the
gcc 5.0 release that could leverage new functionalities in isl 0.14.
Jack


On Sun, Nov 9, 2014 at 12:16 PM, Roman Gareev  wrote:
> Hi Tobias,
>
> I've attached a patch which removes using of CLooG library from
> Graphite. Is it fine for trunk?
>
>
> --
> Cheers, Roman Gareev.


Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto

2014-11-10 Thread H.J. Lu
On Mon, Nov 10, 2014 at 5:44 AM, Richard Biener
 wrote:
> On Mon, Nov 10, 2014 at 2:43 PM, Jakub Jelinek  wrote:
>> On Mon, Nov 10, 2014 at 05:32:32AM -0800, H.J. Lu wrote:
>>> On Mon, Nov 10, 2014 at 4:05 AM, Jakub Jelinek  wrote:
>>> > On Mon, Nov 10, 2014 at 12:50:44PM +0100, Richard Biener wrote:
>>> >> On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu  wrote:
>>> >> > Hi,
>>> >> >
>>> >> > r216964 disables bootstrap for libcc1 which exposed 2 things:
>>> >> >
>>> >> > 1. libcc1 isn't compiled with LTO even when GCC is configured with
>>> >> > "--with-build-config=bootstrap-lto".  It may be intentional since
>>> >> > libcc1 is disabled for bootstrap.
>>> >> > 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is
>>> >> > compiled with LTO which remembers PIC option.
>>> >>
>>> >> Why is this any special to LTO?  If it is then it looks like a LTO
>>> >> (driver) issue to me?  Why are we linking the pic libibterty into
>>> >> a non-pic libcc1?
>>> >
>>> > I admit I haven't tried LTO bootstrap, but from normal bootstrap logs,
>>> > libcc1 is built normally using libtool using -fPIC only, and linked into
>>> > libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the
>>> > pic/libiberty.a, because we need PIC code in the shared libraries.
>>> > So, I don't understand the change at all.
>>> >
>>> > Jakub
>>>
>>> This is the command line to build libcc1.la:
>>
>> Sure, but there was -fPIC used to compile all the *.o files that are being
>> linked into libcc1.so, so LTO should know that.
>
> And it does.  If not please file a bug with a smaller testcase than libcc1
> and libiberty.
>

There is nothing wrong with linker.  It is a slm-lto bug in libtool.  I uploaded
a testcase at

https://gcc.gnu.org/bugzilla/attachment.cgi?id=33931

-- 
H.J.


Re: [PATCH] c++98/mt_allcoator.cc: Fix assumption sizeof(void *) == sizeof(size_t)

2014-11-10 Thread Joel Sherrill

On 11/10/2014 1:03 PM, Paolo Carlini wrote:
> Hi,
>
> On 11/10/2014 07:34 PM, Jonathan Wakely wrote:
>> On 10/11/14 12:01 -0600, Joel Sherrill wrote:
>>> cc'ing since both lists should be included.
>>>
>>> The m32c has 24-bit pointers and 16-bit size_t. This changes
>>> pushing a pointer through a size_t to pushing it through a
>>> uintptr_t.
>> I'm OK with this change if Paolo is.
> No problem with the experiment (frankly, I'm not at all sure that the 
> targets not providing  are *that* much uncommon than the 
> target which we are fixing with the patch), but please add a comment 
> about  in the code, then if bootstrap actually breaks the 
> issue is clear...
Just to be clear add a comment above the include of stdint.h that it is
assumed
that a target provides this header file and defines uintptr_t.
> Paolo.

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985




Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto

2014-11-10 Thread H.J. Lu
On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek  wrote:
> On Mon, Nov 10, 2014 at 02:44:55PM +0100, Richard Biener wrote:
>> >> > I admit I haven't tried LTO bootstrap, but from normal bootstrap logs,
>> >> > libcc1 is built normally using libtool using -fPIC only, and linked into
>> >> > libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the
>> >> > pic/libiberty.a, because we need PIC code in the shared libraries.
>> >> > So, I don't understand the change at all.
>> >> >
>> >> > Jakub
>> >>
>> >> This is the command line to build libcc1.la:
>> >
>> > Sure, but there was -fPIC used to compile all the *.o files that are being
>> > linked into libcc1.so, so LTO should know that.
>>
>> And it does.  If not please file a bug with a smaller testcase than libcc1
>> and libiberty.
>
> Ah, supposedly we should add $(POSTSTAGE1_HOST_EXPORTS) after $(HOST_EXPORTS)
> to the libcc1 rules iff the libcc1 module is built by the newly built
> bootstrapped compiler (but not when the compiler is not bootstrapped and
> thus it is built by the host compiler), because if we first bootstrap the
> compiler and build libcc1 by stage3, it is really post-stage1 building.

It doesn't help. The problem is the missing -fPIC when libtool calls
g+++ to create the shared object.  My patch fixes it.

-- 
H.J.


Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto

2014-11-10 Thread Markus Trippelsdorf
On 2014.11.10 at 11:43 -0800, H.J. Lu wrote:
> On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek  wrote:
> > On Mon, Nov 10, 2014 at 02:44:55PM +0100, Richard Biener wrote:
> >> >> > I admit I haven't tried LTO bootstrap, but from normal bootstrap logs,
> >> >> > libcc1 is built normally using libtool using -fPIC only, and linked 
> >> >> > into
> >> >> > libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the
> >> >> > pic/libiberty.a, because we need PIC code in the shared libraries.
> >> >> > So, I don't understand the change at all.
> >> >> >
> >> >> > Jakub
> >> >>
> >> >> This is the command line to build libcc1.la:
> >> >
> >> > Sure, but there was -fPIC used to compile all the *.o files that are 
> >> > being
> >> > linked into libcc1.so, so LTO should know that.
> >>
> >> And it does.  If not please file a bug with a smaller testcase than libcc1
> >> and libiberty.
> >
> > Ah, supposedly we should add $(POSTSTAGE1_HOST_EXPORTS) after 
> > $(HOST_EXPORTS)
> > to the libcc1 rules iff the libcc1 module is built by the newly built
> > bootstrapped compiler (but not when the compiler is not bootstrapped and
> > thus it is built by the host compiler), because if we first bootstrap the
> > compiler and build libcc1 by stage3, it is really post-stage1 building.
> 
> It doesn't help. The problem is the missing -fPIC when libtool calls
> g+++ to create the shared object.  My patch fixes it.

But wouldn't it be better to update to a more recent libtool version
instead of adding hack upon hack? 
This would also allow bootstrap-lto without the need of the gcc-ar
(, etc.) wrappers.

And you are one of the very few persons who could handle such an update.

-- 
Markus


Re: The nvptx port [10/11+] Target files

2014-11-10 Thread Jakub Jelinek
On Mon, Nov 10, 2014 at 05:19:57PM +0100, Bernd Schmidt wrote:
> commit 659744a99d815b168716b4460e32f6a21593e494
> Author: Bernd Schmidt 
> Date:   Thu Nov 6 19:03:57 2014 +0100

Note, in r217301 you've committed a change to pr35468.c, not mentioned in
the ChangeLog, that uses no_const_addr_space effective target that is never
defined.  Can you please revert or commit a patch that adds support for that
to gcc/testsuite/lib/ ?

+ERROR: gcc.c-torture/compile/pr35468.c   -O0 : unknown effective target 
keyword \`no_const_addr_space' for " dg-require-effective-target 2 
no_const_addr_space "
+UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O0 : unknown effective target 
keyword \`no_const_addr_space' for " dg-require-effective-target 2 
no_const_addr_space "
+ERROR: gcc.c-torture/compile/pr35468.c   -O1 : unknown effective target 
keyword \`no_const_addr_space' for " dg-require-effective-target 2 
no_const_addr_space "
+UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O1 : unknown effective target 
keyword \`no_const_addr_space' for " dg-require-effective-target 2 
no_const_addr_space "
+ERROR: gcc.c-torture/compile/pr35468.c   -O2 -flto -flto-partition=none : 
unknown effective target keyword \`no_const_addr_space' for " 
dg-require-effective-target 2 no_const_addr_space "
+UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O2 -flto -flto-partition=none : 
unknown effective target keyword \`no_const_addr_space' for " 
dg-require-effective-target 2 no_const_addr_space "
+ERROR: gcc.c-torture/compile/pr35468.c   -O2 -flto : unknown effective target 
keyword \`no_const_addr_space' for " dg-require-effective-target 2 
no_const_addr_space "
+UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O2 -flto : unknown effective 
target keyword \`no_const_addr_space' for " dg-require-effective-target 2 
no_const_addr_space "
+ERROR: gcc.c-torture/compile/pr35468.c   -O2 : unknown effective target 
keyword \`no_const_addr_space' for " dg-require-effective-target 2 
no_const_addr_space "
+UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O2 : unknown effective target 
keyword \`no_const_addr_space' for " dg-require-effective-target 2 
no_const_addr_space "
+ERROR: gcc.c-torture/compile/pr35468.c   -O3 -fomit-frame-pointer : unknown 
effective target keyword \`no_const_addr_space' for " 
dg-require-effective-target 2 no_const_addr_space "
+UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O3 -fomit-frame-pointer : 
unknown effective target keyword \`no_const_addr_space' for " 
dg-require-effective-target 2 no_const_addr_space "
+ERROR: gcc.c-torture/compile/pr35468.c   -O3 -g : unknown effective target 
keyword \`no_const_addr_space' for " dg-require-effective-target 2 
no_const_addr_space "
+UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O3 -g : unknown effective 
target keyword \`no_const_addr_space' for " dg-require-effective-target 2 
no_const_addr_space "
+ERROR: gcc.c-torture/compile/pr35468.c   -Os : unknown effective target 
keyword \`no_const_addr_space' for " dg-require-effective-target 2 
no_const_addr_space "
+UNRESOLVED: gcc.c-torture/compile/pr35468.c   -Os : unknown effective target 
keyword \`no_const_addr_space' for " dg-require-effective-target 2 
no_const_addr_space "
+ERROR: gcc.dg/pr44194-1.c: syntax error in target selector "target  { { { { { 
i?86-*-* x86_64-*-* } && x32 } || lp64 } && { ! s390*-*-* } } && { ! 
hppa*64*-*-* } } && { ! alpha*-*-* }  &&  { ! powerpc*-*-linux* } || 
powerpc_elfv2  &&  ! nvptx-*-*" for " dg-do 1 compile { target { { { { { { { 
i?86-*-* x86_64-*-* } && x32 } || lp64 } && { ! s390*-*-* } } && { ! 
hppa*64*-*-* } } && { ! alpha*-*-* } } && { { ! powerpc*-*-linux* } || 
powerpc_elfv2 } && { ! nvptx-*-* } } } "
+UNRESOLVED: gcc.dg/pr44194-1.c: syntax error in target selector "target  { { { 
{ { i?86-*-* x86_64-*-* } && x32 } || lp64 } && { ! s390*-*-* } } && { ! 
hppa*64*-*-* } } && { ! alpha*-*-* }  &&  { ! powerpc*-*-linux* } || 
powerpc_elfv2  &&  ! nvptx-*-*" for " dg-do 1 compile { target { { { { { { { 
i?86-*-* x86_64-*-* } && x32 } || lp64 } && { ! s390*-*-* } } && { ! 
hppa*64*-*-* } } && { ! alpha*-*-* } } && { { ! powerpc*-*-linux* } || 
powerpc_elfv2 } && { ! nvptx-*-* } } } "
+FAIL: gcc.dg/pr45352-1.c (test for excess errors)

Jakub


Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto

2014-11-10 Thread H.J. Lu
On Mon, Nov 10, 2014 at 11:57 AM, Markus Trippelsdorf
 wrote:
> On 2014.11.10 at 11:43 -0800, H.J. Lu wrote:
>> On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek  wrote:
>> > On Mon, Nov 10, 2014 at 02:44:55PM +0100, Richard Biener wrote:
>> >> >> > I admit I haven't tried LTO bootstrap, but from normal bootstrap 
>> >> >> > logs,
>> >> >> > libcc1 is built normally using libtool using -fPIC only, and linked 
>> >> >> > into
>> >> >> > libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the
>> >> >> > pic/libiberty.a, because we need PIC code in the shared libraries.
>> >> >> > So, I don't understand the change at all.
>> >> >> >
>> >> >> > Jakub
>> >> >>
>> >> >> This is the command line to build libcc1.la:
>> >> >
>> >> > Sure, but there was -fPIC used to compile all the *.o files that are 
>> >> > being
>> >> > linked into libcc1.so, so LTO should know that.
>> >>
>> >> And it does.  If not please file a bug with a smaller testcase than libcc1
>> >> and libiberty.
>> >
>> > Ah, supposedly we should add $(POSTSTAGE1_HOST_EXPORTS) after 
>> > $(HOST_EXPORTS)
>> > to the libcc1 rules iff the libcc1 module is built by the newly built
>> > bootstrapped compiler (but not when the compiler is not bootstrapped and
>> > thus it is built by the host compiler), because if we first bootstrap the
>> > compiler and build libcc1 by stage3, it is really post-stage1 building.
>>
>> It doesn't help. The problem is the missing -fPIC when libtool calls
>> g+++ to create the shared object.  My patch fixes it.
>
> But wouldn't it be better to update to a more recent libtool version
> instead of adding hack upon hack?

Hack is safer than the newer libtool :-(.  A new libtool needs to be
verified on all hosts for all targets.

> This would also allow bootstrap-lto without the need of the gcc-ar
> (, etc.) wrappers.
>
> And you are one of the very few persons who could handle such an update.
>

What did you mean by "you"?


-- 
H.J.


[PATCH, i386]: Use std::swap

2014-11-10 Thread Uros Bizjak
Hello!

std::swap was recently mentioned in gcc-patches@ mailing list, so I
gave it a try. As can be seen below, a lot of code in config/i386
benefits from this conversion.

Surprisingly, I didn't have to include any header on F20 linux build.
So, is this patch OK as far as c++ is concerned?

2014-11-10  Uros Bizjak  

* config/i386/i386.c (ix86_decompose_address): Replace open-coded
swap with std::swap to swap values.
(ix86_fixup_binary_operands): Ditto.
(ix86_binary_operator_ok): Ditto.
(ix86_prepare_fp_compare_args): Ditto.
(ix86_expand_branch): Ditto.
(ix86_expand_carry_flag_compare): Ditto.
(ix86_expand_int_movcc): Ditto.
(ix86_prepare_sse_fp_compare_args): Ditto.
(ix86_expand_sse_fp_minmax): Ditto.
(ix86_expand_int_vcond): Ditto.
(ix86_split_long_move): Ditto.
(ix86_expand_sse_comi): Ditto.
(ix86_expand_sse_compare_and_jump): Ditto.
(ix86_expand_sse_compare_mask): Ditto.
* config/i386/i386.md (*add_1): Ditto.
(addsi_1_zext): Ditto.
(*addhi_1): Ditto.
(*addqi_1): Ditto.
(*add_2): Ditto.
(*addsi_2_zext): Ditto.
(*add_3): Ditto.
(*addsi_3_zext): Ditto.
(*add_5): Ditto.
(absneg splitter): Ditto.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

I will wait for a day or two for possible comments from c++ side...

Uros.
Index: i386.c
===
--- i386.c  (revision 217303)
+++ i386.c  (working copy)
@@ -12698,9 +12698,8 @@ ix86_decompose_address (rtx addr, struct ix86_addr
  || index_reg == frame_pointer_rtx
  || (REG_P (index_reg) && REGNO (index_reg) == STACK_POINTER_REGNUM)))
 {
-  rtx tmp;
-  tmp = base, base = index, index = tmp;
-  tmp = base_reg, base_reg = index_reg, index_reg = tmp;
+  std::swap (base, index);
+  std::swap (base_reg, index_reg);
 }
 
   /* Special case: %ebp cannot be encoded as a base without a displacement.
@@ -17753,14 +17752,10 @@ ix86_fixup_binary_operands (enum rtx_code code, ma
   /* Canonicalize operand order.  */
   if (ix86_swap_binary_operands_p (code, mode, operands))
 {
-  rtx temp;
-
   /* It is invalid to swap operands of different modes.  */
   gcc_assert (GET_MODE (src1) == GET_MODE (src2));
 
-  temp = src1;
-  src1 = src2;
-  src2 = temp;
+  std::swap (src1, src2);
 }
 
   /* Both source operands cannot be in memory.  */
@@ -17950,11 +17945,7 @@ ix86_binary_operator_ok (enum rtx_code code, machi
 
   /* Canonicalize operand order for commutative operators.  */
   if (ix86_swap_binary_operands_p (code, mode, operands))
-{
-  rtx temp = src1;
-  src1 = src2;
-  src2 = temp;
-}
+std::swap (src1, src2);
 
   /* If the destination is memory, we must have a matching source operand.  */
   if (MEM_P (dst) && !rtx_equal_p (dst, src1))
@@ -19994,8 +19985,7 @@ ix86_prepare_fp_compare_args (enum rtx_code code,
  enum rtx_code new_code = ix86_fp_swap_condition (code);
  if (new_code != UNKNOWN)
{
- rtx tmp;
- tmp = op0, op0 = op1, op1 = tmp;
+ std::swap (op0, op1);
  code = new_code;
}
}
@@ -20023,8 +20013,7 @@ ix86_prepare_fp_compare_args (enum rtx_code code,
   > ix86_fp_comparison_cost (swap_condition (code))
   && (REG_P (op1) || can_create_pseudo_p ()))
 {
-  rtx tmp;
-  tmp = op0, op0 = op1, op1 = tmp;
+  std::swap (op0, op1);
   code = swap_condition (code);
   if (!REG_P (op0))
op0 = force_reg (op_mode, op0);
@@ -20290,7 +20279,7 @@ ix86_expand_branch (enum rtx_code code, rtx op0, r
 
if (CONSTANT_P (op0) && !CONSTANT_P (op1))
  {
-   tmp = op0, op0 = op1, op1 = tmp;
+   std::swap (op0, op1);
code = swap_condition (code);
  }
 
@@ -20471,9 +20460,7 @@ ix86_expand_carry_flag_compare (enum rtx_code code
   if ((code == GT || code == UNLE || code == LE || code == UNGT)
  && !TARGET_IEEE_FP)
{
- rtx tmp = op0;
- op0 = op1;
- op1 = tmp;
+ std::swap (op0, op1);
  code = swap_condition (code);
}
 
@@ -20533,9 +20520,7 @@ ix86_expand_carry_flag_compare (enum rtx_code code
}
   else
{
- rtx tmp = op1;
- op1 = op0;
- op0 = tmp;
+ std::swap (op1, op0);
  code = (code == GTU ? LTU : GEU);
}
   break;
@@ -20764,8 +20749,7 @@ ix86_expand_int_movcc (rtx operands[])
{
  machine_mode cmp_mode = GET_MODE (op0);
 
- HOST_WIDE_INT tmp;
- tmp = ct, ct = cf, cf = tmp;
+ std::swap (ct, cf);
  diff = -diff;
 
  if (SCALAR_FLOAT_MODE_P (cmp_mode))
@@ -20962,11 +20946,7 @@ ix86_expand_int_movcc (rtx operands[])
  compare_code = LT;
}
  else
-   {
- HOST_WIDE_INT t

Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto

2014-11-10 Thread Markus Trippelsdorf
On 2014.11.10 at 12:05 -0800, H.J. Lu wrote:
> On Mon, Nov 10, 2014 at 11:57 AM, Markus Trippelsdorf
>  wrote:
> > On 2014.11.10 at 11:43 -0800, H.J. Lu wrote:
> >> On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek  wrote:
> >> > On Mon, Nov 10, 2014 at 02:44:55PM +0100, Richard Biener wrote:
> >> >> >> > I admit I haven't tried LTO bootstrap, but from normal bootstrap 
> >> >> >> > logs,
> >> >> >> > libcc1 is built normally using libtool using -fPIC only, and 
> >> >> >> > linked into
> >> >> >> > libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against 
> >> >> >> > the
> >> >> >> > pic/libiberty.a, because we need PIC code in the shared libraries.
> >> >> >> > So, I don't understand the change at all.
> >> >> >> >
> >> >> >> > Jakub
> >> >> >>
> >> >> >> This is the command line to build libcc1.la:
> >> >> >
> >> >> > Sure, but there was -fPIC used to compile all the *.o files that are 
> >> >> > being
> >> >> > linked into libcc1.so, so LTO should know that.
> >> >>
> >> >> And it does.  If not please file a bug with a smaller testcase than 
> >> >> libcc1
> >> >> and libiberty.
> >> >
> >> > Ah, supposedly we should add $(POSTSTAGE1_HOST_EXPORTS) after 
> >> > $(HOST_EXPORTS)
> >> > to the libcc1 rules iff the libcc1 module is built by the newly built
> >> > bootstrapped compiler (but not when the compiler is not bootstrapped and
> >> > thus it is built by the host compiler), because if we first bootstrap the
> >> > compiler and build libcc1 by stage3, it is really post-stage1 building.
> >>
> >> It doesn't help. The problem is the missing -fPIC when libtool calls
> >> g+++ to create the shared object.  My patch fixes it.
> >
> > But wouldn't it be better to update to a more recent libtool version
> > instead of adding hack upon hack?
> 
> Hack is safer than the newer libtool :-(.  A new libtool needs to be
> verified on all hosts for all targets.

Well, perhaps now is the right time to do it, because there would be
enough time to fix any fallout.

> > This would also allow bootstrap-lto without the need of the gcc-ar
> > (, etc.) wrappers.
> >
> > And you are one of the very few persons who could handle such an update.
> >
> 
> What did you mean by "you"?

I mean that since Ralf Wildenhues dropped from the scene, you (H.J.) are
one of the few people who could handle a libtool update across the
different trees (gcc, binutils, etc.).

-- 
Markus


Re: [7/7] nvptx testsuite patches: Return addresses

2014-11-10 Thread H.J. Lu
On Tue, Oct 21, 2014 at 8:33 AM, Jeff Law  wrote:
> On 10/21/14 14:29, Bernd Schmidt wrote:
>>
>> This tests for availability of return addresses in a number of tests.
>>
>>
>> Bernd
>>
>>
>> r422426.diff
>>
>>
>> gcc/testsuite/
>> * lib/target-supports.exp (check_effective_target_return_address):
>> New function.
>> * gcc.c-torture/execute/20010122-1.c: Require return_address.
>> * gcc.c-torture/execute/20030323-1.c: Likewise.
>> * gcc.c-torture/execute/20030811-1.c: Likewise.
>> * gcc.c-torture/execute/eeprof-1.c: Likewise.
>> * gcc.c-torture/execute/frame-address.c: Likewise.
>> * gcc.c-torture/execute/pr17377.c: Likewise.
>
> OK.
> jeff
>

I checked in this patch to revert the accidental checkin.

-- 
H.J.

Index: ChangeLog
===
--- ChangeLog (revision 217312)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2014-11-10  H.J. Lu  
+
+ * gcc.c-torture/compile/pr35468.c: Revert the last change.
+
 2014-11-10  Andreas Tobler  

  * gcc.dg/fshort-wchar.c: Use arm_eabi instead of arm*-*-*eabi*.
Index: gcc.c-torture/compile/pr35468.c
===
--- gcc.c-torture/compile/pr35468.c (revision 217312)
+++ gcc.c-torture/compile/pr35468.c (working copy)
@@ -1,5 +1,4 @@
 /* PR tree-optimization/35468 */
-/* { dg-require-effective-target no_const_addr_space } */

 void
 foo (void)


Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto

2014-11-10 Thread H.J. Lu
On Mon, Nov 10, 2014 at 12:16 PM, Markus Trippelsdorf
 wrote:
> On 2014.11.10 at 12:05 -0800, H.J. Lu wrote:
>> On Mon, Nov 10, 2014 at 11:57 AM, Markus Trippelsdorf
>>  wrote:
>> > On 2014.11.10 at 11:43 -0800, H.J. Lu wrote:
>> >> On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek  wrote:
>> >> > On Mon, Nov 10, 2014 at 02:44:55PM +0100, Richard Biener wrote:
>> >> >> >> > I admit I haven't tried LTO bootstrap, but from normal bootstrap 
>> >> >> >> > logs,
>> >> >> >> > libcc1 is built normally using libtool using -fPIC only, and 
>> >> >> >> > linked into
>> >> >> >> > libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against 
>> >> >> >> > the
>> >> >> >> > pic/libiberty.a, because we need PIC code in the shared libraries.
>> >> >> >> > So, I don't understand the change at all.
>> >> >> >> >
>> >> >> >> > Jakub
>> >> >> >>
>> >> >> >> This is the command line to build libcc1.la:
>> >> >> >
>> >> >> > Sure, but there was -fPIC used to compile all the *.o files that are 
>> >> >> > being
>> >> >> > linked into libcc1.so, so LTO should know that.
>> >> >>
>> >> >> And it does.  If not please file a bug with a smaller testcase than 
>> >> >> libcc1
>> >> >> and libiberty.
>> >> >
>> >> > Ah, supposedly we should add $(POSTSTAGE1_HOST_EXPORTS) after 
>> >> > $(HOST_EXPORTS)
>> >> > to the libcc1 rules iff the libcc1 module is built by the newly built
>> >> > bootstrapped compiler (but not when the compiler is not bootstrapped and
>> >> > thus it is built by the host compiler), because if we first bootstrap 
>> >> > the
>> >> > compiler and build libcc1 by stage3, it is really post-stage1 building.
>> >>
>> >> It doesn't help. The problem is the missing -fPIC when libtool calls
>> >> g+++ to create the shared object.  My patch fixes it.
>> >
>> > But wouldn't it be better to update to a more recent libtool version
>> > instead of adding hack upon hack?
>>
>> Hack is safer than the newer libtool :-(.  A new libtool needs to be
>> verified on all hosts for all targets.
>
> Well, perhaps now is the right time to do it, because there would be
> enough time to fix any fallout.
>
>> > This would also allow bootstrap-lto without the need of the gcc-ar
>> > (, etc.) wrappers.
>> >
>> > And you are one of the very few persons who could handle such an update.
>> >
>>
>> What did you mean by "you"?
>
> I mean that since Ralf Wildenhues dropped from the scene, you (H.J.) are
> one of the few people who could handle a libtool update across the
> different trees (gcc, binutils, etc.).
>

I can handle binutils.  But it takes a LONG time for GCC build changes
to be reviewed.  I try to avoid it as much as I can :-).

-- 
H.J.


Re: [PATCH][1-3] New configure options that make the compiler use -fPIE and -pie as default option

2014-11-10 Thread Magnus Granberg
fredag 01 augusti 2014 10.52.27 skrev  Rainer Orth:
> Hi Magnus,
> 
> a couple of comments, mostly nits.
> 
> > 2014-07-31  Magnus Granberg  
> > 
> > /gcc
> > * config/gnu-user.h: Define PIE_DRIVER_SELF_SPECS for PIE
> > as default and GNU_DRIVER_SELF_SPECS.
> > * config/i386/gnu-user-common.h: Define DRIVER_SELF_SPECS
> > * configure.ac: Add new option that enable PIE as default.
> > * configure, config.in: Rebuild.
> > * Makefile.in: Disable PIE when building the compiler.
> > * doc/install.texi: Add the new configure option default PIE.
> > * doc/invoke.texi: Add note for the new configure option default PIE.
> 
> Many of those entries are mis-formatted.  See other examples and the GNU
> Coding Standards for details.  E.g. the first would be
> 
>   * config/gnu-user.h (PIE_DRIVER_SELF_SPECS): Define.
> 
> In general, you need to mention which macro, variable, manual section
> you change.  Emacs' add-change-log-entry does the basics for you.
> Besides, you only state what changed, not why.
> 
> Apart from that, I don't think defining PIE_DRIVER_SELF_SPECS in
> gnu-user.h is a good idea.  This way, every other target supporting the
> option would have to duplicate that stuff.
> 
>   * testsuite/gcc/default-pie.c: New test for new configure option
>   --enale-default-pie
> 
> gcc/testsuite has its own ChangeLog file.  Typo for --enale-...
> 
>   * testsuite/gcc.dg/other/anon5.C: Add skip test as it fail to link
>   on effective_target default_pie.
> 
> should be
> 
>   * g++.dg/other/anon5.C: Skip if default_pie.
> 
> No explanations in ChangeLog entries; they belong into the code.
> Besides, you had the first dir component wrong.  Again, Emacs does this
> for you.
> 
>   * testsuite/lib/target-supports.exp (check_profiling_available):
>   We can't use profiling on effective target default_pie.
>   (check_effective_target_pie): Add check_effective_target_default_pie.
> 
> Wrong: should be
> 
>   * lib/target-supports.exp (check_effective_target_default_pie):
> New proc.
> 
> The new default_pic effective-target keyword needs to be documented in
> doc/sourcebuild.texi.
> 
> --- a/gcc/testsuite/gcc.dg/default-pie.c  2013-11-09 21:07:16.741479728 
+0100
> +++ b/gcc/testsuite/gcc.dg/default-pie.c  2013-11-09 21:05:07.801479218
> +0100 @@ -0,0 +1,12 @@
> +/* { dg-do compile { target *-*-linux* *-*-gnu* } } */
> +/* { dg-require-effective-target default_pie } */
> 
> Why restrict to Linux, GNU?  default_pie should be enough once other
> targets add this.
> 
> --- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-store-ccp-3.c 2012-03-14
> 17:33:37.0 +0100 +++
> b/gcc/testsuite/gcc.dg/tree-ssa/ssa-store-ccp-3.c 2014-07-29
> 00:55:17.421086416 +0200 @@ -2,6 +2,9 @@
>  /* Skipped on MIPS GNU/Linux target because __PIC__ can be
> defined for executables as well as shared libraries.  */
>  /* { dg-skip-if "" { *-*-darwin* hppa*64*-*-* mips*-*-linux* *-*-mingw* } {
> "*" } { "" } } */ +/* Skipped on default_pie targets because __PIC__ is
> +   defined for executables.  */
> +/* { dg-skip-if "" { default_pie } { "*" } { "" } }  */
> 
> Emit those default args, they're unnecessary.  Also in g++.dg/other/anon5.C.
> 
> --- a/gcc/testsuite/g++.dg/other/anon5.C  2012-11-10 15:34:42.0 
> +0100
> +++ b/gcc/testsuite/g++.dg/other/anon5.C  2013-11-09 14:49:52.281390127
> +0100 @@ -1,5 +1,6 @@
>  // PR c++/34094
>  // { dg-do link { target { ! { *-*-darwin* *-*-hpux* *-*-solaris2.* } } } }
> +// { dg-skip-if "" { default_pie } { "*" } { "" } }
> 
> The first arg to dg-skip-if should explain why you're skipping the test.
> 
> --- a/gcc/testsuite/lib/target-supports.exp   2013-10-01 11:18:30.0
> +0200 +++ b/gcc/testsuite/lib/target-supports.exp 2013-10-25
> 22:01:46.743388469 +0200 @@ -474,6 +474,11 @@ proc
> check_profiling_available { test_wh
>   }
>  }
> 
> +# Profiling don't work with default -fPIE -pie.
> 
> Grammar: "doesn't work".
> 
> +# Return 1 if -pie, -fPIE are default enable, 0 otherwise.
> +
> +proc check_effective_target_default_pie { } {
> 
> Hard to understand, perhaps
> 
> # Return 1 if -pie -fPIE are enabled by default, 0 otherwise.
> 
> --- a/gcc/doc/invoke.texi 2013-10-03 19:13:50.0 +0200
> +++ b/gcc/doc/invoke.texi 2013-11-17 21:30:02.784220111 +0100
> @@ -10535,6 +10535,12 @@ For predictable results, you must also s
>  used for compilation (@option{-fpie}, @option{-fPIE},
>  or model suboptions) when you specify this linker option.
> 
> +NOTE: With configure --enable-default-pie this option is enabled by default
> 
> With the @option{--enable-default-pie} configure option, ...
> 
> +for C, C++, ObjC, ObjC++, if none of @option{-fno-PIE}, @option{-fno-pie},
> +@option{-fPIC}, @option{-fpic}, @option{-fno-PIC}, @option{-fno-pic},
> +@option{-nostdlib}, @option{-nostartfiles}, @option{-shared},
> +@option{-nodefaultlibs}, nor @option{static} are found.
> 
> @opti

Re: [7/7] nvptx testsuite patches: Return addresses

2014-11-10 Thread Mike Stump
On Nov 10, 2014, at 12:19 PM, H.J. Lu  wrote:
> I checked in this patch to revert the accidental checkin.

Thanks.


Re: [x86, 6/n] Replace builtins with vector extensions

2014-11-10 Thread Uros Bizjak
On Sun, Nov 9, 2014 at 5:26 PM, Marc Glisse  wrote:
> Hello,
>
> < > and == for integer vectors of size 128. I was surprised not to find
> _mm_cmplt_epi64 anywhere. Note that I can do the same for size 256, but not
> 512, there is no corresponding intrinsic, there are only _mask versions that
> return a mask.

Let's ask Kirill (CC'd) about missing intrinsics.

> For gcc-5, we should stop either after 5/n or after 7/n (avx2 version of
> 6/n).
>
> Regtested with 5/n.
>
> 2014-11-10  Marc Glisse  
>
> * config/i386/emmintrin.h (_mm_cmpeq_epi8, _mm_cmpeq_epi16,
> _mm_cmpeq_epi32, _mm_cmplt_epi8, _mm_cmplt_epi16, _mm_cmplt_epi32,
> _mm_cmpgt_epi8, _mm_cmpgt_epi16, _mm_cmpgt_epi32): Use vector
> extensions instead of builtins.
> * config/i386/smmintrin.h (_mm_cmpeq_epi64, _mm_cmpgt_epi64):
> Likewise.

OK.

Thanks,
Uros.


Re: The nvptx port [10/11+] Target files

2014-11-10 Thread H.J. Lu
On Mon, Nov 10, 2014 at 12:04 PM, Jakub Jelinek  wrote:
> On Mon, Nov 10, 2014 at 05:19:57PM +0100, Bernd Schmidt wrote:
>> commit 659744a99d815b168716b4460e32f6a21593e494
>> Author: Bernd Schmidt 
>> Date:   Thu Nov 6 19:03:57 2014 +0100
>
> Note, in r217301 you've committed a change to pr35468.c, not mentioned in
> the ChangeLog, that uses no_const_addr_space effective target that is never
> defined.  Can you please revert or commit a patch that adds support for that
> to gcc/testsuite/lib/ ?
>
> +ERROR: gcc.c-torture/compile/pr35468.c   -O0 : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O0 : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +ERROR: gcc.c-torture/compile/pr35468.c   -O1 : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O1 : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +ERROR: gcc.c-torture/compile/pr35468.c   -O2 -flto -flto-partition=none : 
> unknown effective target keyword \`no_const_addr_space' for " 
> dg-require-effective-target 2 no_const_addr_space "
> +UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O2 -flto -flto-partition=none 
> : unknown effective target keyword \`no_const_addr_space' for " 
> dg-require-effective-target 2 no_const_addr_space "
> +ERROR: gcc.c-torture/compile/pr35468.c   -O2 -flto : unknown effective 
> target keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O2 -flto : unknown effective 
> target keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +ERROR: gcc.c-torture/compile/pr35468.c   -O2 : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O2 : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +ERROR: gcc.c-torture/compile/pr35468.c   -O3 -fomit-frame-pointer : unknown 
> effective target keyword \`no_const_addr_space' for " 
> dg-require-effective-target 2 no_const_addr_space "
> +UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O3 -fomit-frame-pointer : 
> unknown effective target keyword \`no_const_addr_space' for " 
> dg-require-effective-target 2 no_const_addr_space "
> +ERROR: gcc.c-torture/compile/pr35468.c   -O3 -g : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O3 -g : unknown effective 
> target keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +ERROR: gcc.c-torture/compile/pr35468.c   -Os : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +UNRESOLVED: gcc.c-torture/compile/pr35468.c   -Os : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +ERROR: gcc.dg/pr44194-1.c: syntax error in target selector "target  { { { { 
> { i?86-*-* x86_64-*-* } && x32 } || lp64 } && { ! s390*-*-* } } && { ! 
> hppa*64*-*-* } } && { ! alpha*-*-* }  &&  { ! powerpc*-*-linux* } || 
> powerpc_elfv2  &&  ! nvptx-*-*" for " dg-do 1 compile { target { { { { { { { 
> i?86-*-* x86_64-*-* } && x32 } || lp64 } && { ! s390*-*-* } } && { ! 
> hppa*64*-*-* } } && { ! alpha*-*-* } } && { { ! powerpc*-*-linux* } || 
> powerpc_elfv2 } && { ! nvptx-*-* } } } "
> +UNRESOLVED: gcc.dg/pr44194-1.c: syntax error in target selector "target  { { 
> { { { i?86-*-* x86_64-*-* } && x32 } || lp64 } && { ! s390*-*-* } } && { ! 
> hppa*64*-*-* } } && { ! alpha*-*-* }  &&  { ! powerpc*-*-linux* } || 
> powerpc_elfv2  &&  ! nvptx-*-*" for " dg-do 1 compile { target { { { { { { { 
> i?86-*-* x86_64-*-* } && x32 } || lp64 } && { ! s390*-*-* } } && { ! 
> hppa*64*-*-* } } && { ! alpha*-*-* } } && { { ! powerpc*-*-linux* } || 
> powerpc_elfv2 } && { ! nvptx-*-* } } } "
> +FAIL: gcc.dg/pr45352-1.c (test for excess errors)
>
> Jakub



-- 
H.J.


Re: The nvptx port [10/11+] Target files

2014-11-10 Thread H.J. Lu
On Mon, Nov 10, 2014 at 12:04 PM, Jakub Jelinek  wrote:
> On Mon, Nov 10, 2014 at 05:19:57PM +0100, Bernd Schmidt wrote:
>> commit 659744a99d815b168716b4460e32f6a21593e494
>> Author: Bernd Schmidt 
>> Date:   Thu Nov 6 19:03:57 2014 +0100
>
> Note, in r217301 you've committed a change to pr35468.c, not mentioned in
> the ChangeLog, that uses no_const_addr_space effective target that is never
> defined.  Can you please revert or commit a patch that adds support for that
> to gcc/testsuite/lib/ ?
>
> +ERROR: gcc.c-torture/compile/pr35468.c   -O0 : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O0 : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +ERROR: gcc.c-torture/compile/pr35468.c   -O1 : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O1 : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +ERROR: gcc.c-torture/compile/pr35468.c   -O2 -flto -flto-partition=none : 
> unknown effective target keyword \`no_const_addr_space' for " 
> dg-require-effective-target 2 no_const_addr_space "
> +UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O2 -flto -flto-partition=none 
> : unknown effective target keyword \`no_const_addr_space' for " 
> dg-require-effective-target 2 no_const_addr_space "
> +ERROR: gcc.c-torture/compile/pr35468.c   -O2 -flto : unknown effective 
> target keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O2 -flto : unknown effective 
> target keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +ERROR: gcc.c-torture/compile/pr35468.c   -O2 : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O2 : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +ERROR: gcc.c-torture/compile/pr35468.c   -O3 -fomit-frame-pointer : unknown 
> effective target keyword \`no_const_addr_space' for " 
> dg-require-effective-target 2 no_const_addr_space "
> +UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O3 -fomit-frame-pointer : 
> unknown effective target keyword \`no_const_addr_space' for " 
> dg-require-effective-target 2 no_const_addr_space "
> +ERROR: gcc.c-torture/compile/pr35468.c   -O3 -g : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +UNRESOLVED: gcc.c-torture/compile/pr35468.c   -O3 -g : unknown effective 
> target keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +ERROR: gcc.c-torture/compile/pr35468.c   -Os : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +UNRESOLVED: gcc.c-torture/compile/pr35468.c   -Os : unknown effective target 
> keyword \`no_const_addr_space' for " dg-require-effective-target 2 
> no_const_addr_space "
> +ERROR: gcc.dg/pr44194-1.c: syntax error in target selector "target  { { { { 
> { i?86-*-* x86_64-*-* } && x32 } || lp64 } && { ! s390*-*-* } } && { ! 
> hppa*64*-*-* } } && { ! alpha*-*-* }  &&  { ! powerpc*-*-linux* } || 
> powerpc_elfv2  &&  ! nvptx-*-*" for " dg-do 1 compile { target { { { { { { { 
> i?86-*-* x86_64-*-* } && x32 } || lp64 } && { ! s390*-*-* } } && { ! 
> hppa*64*-*-* } } && { ! alpha*-*-* } } && { { ! powerpc*-*-linux* } || 
> powerpc_elfv2 } && { ! nvptx-*-* } } } "
> +UNRESOLVED: gcc.dg/pr44194-1.c: syntax error in target selector "target  { { 
> { { { i?86-*-* x86_64-*-* } && x32 } || lp64 } && { ! s390*-*-* } } && { ! 
> hppa*64*-*-* } } && { ! alpha*-*-* }  &&  { ! powerpc*-*-linux* } || 
> powerpc_elfv2  &&  ! nvptx-*-*" for " dg-do 1 compile { target { { { { { { { 
> i?86-*-* x86_64-*-* } && x32 } || lp64 } && { ! s390*-*-* } } && { ! 
> hppa*64*-*-* } } && { ! alpha*-*-* } } && { { ! powerpc*-*-linux* } || 
> powerpc_elfv2 } && { ! nvptx-*-* } } } "
> +FAIL: gcc.dg/pr45352-1.c (test for excess errors)
>
> Jakub

I reverted the change in gcc.c-torture/compile/pr35468.c.
I also checked in this patch to add missing braces in
gcc.dg/pr44194-1.c.



-- 
H.J.
-
Index: ChangeLog
===
--- ChangeLog (revision 217315)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2014-11-10  H.J. Lu  
+
+ * gcc.dg/pr44194-1.c (dg-do): Add missing braces.
+
 2014-11-10 Roman Gareev  

  * gcc.dg/graphite/isl-ast-gen-blocks-1.c: Remove using of
Index: gcc.dg/pr44194-1.c
===

Re: The nvptx port [10/11+] Target files

2014-11-10 Thread Mike Stump
On Nov 10, 2014, at 12:37 PM, H.J. Lu  wrote:
> I also checked in this patch to add missing braces in
> gcc.dg/pr44194-1.c.

Thanks.


Re: [x86, 5/n] Replace builtins with vector extensions

2014-11-10 Thread Uros Bizjak
On Sun, Nov 9, 2014 at 4:57 PM, Marc Glisse  wrote:
> Hello,
>
> &|^ of size 256 and 512. Regtested with 6/n.
>
> 2014-11-10  Marc Glisse  
>
> * config/i386/avx2intrin.h (_mm256_and_si256, _mm256_or_si256,
> _mm256_xor_si256): Use vector extensions instead of builtins.
> * config/i386/avx512fintrin.h (_mm512_or_si512, _mm512_or_epi32,
> _mm512_or_epi64, _mm512_xor_si512, _mm512_xor_epi32,
> _mm512_xor_epi64,
> _mm512_and_si512, _mm512_and_epi32, _mm512_and_epi64): Likewise.

OK.

Thanks,
Uros.


[PATCH] Fix some ICF gimple_call handling issues

2014-11-10 Thread Jakub Jelinek
Hi!

As the following two testcases shows, there are lots of issues in
ICF compare_gimple_call, in particular, it doesn't handle indirect calls
properly (see the ipa-icf-31.c testcase), doesn't handle internal calls
properly (see ubsan/ipa-icf-1.c), didn't check gimple_call flags at all.

As discussed with Honza, the call chain test (from Martin) is probably
insufficient, I'm open with leaving it out from the patch, but perhaps
what the patch has is better than nothing at all for now.

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

2014-11-10  Jakub Jelinek  
Martin Liska  

* ipa-icf-gimple.c (func_checker::compare_bb): Fix comment typo.
(func_checker::compare_gimple_call): Compare gimple_call_fn,
gimple_call_chain, gimple_call_fntype and call flags.
testsuite/
* gcc.dg/ubsan/ipa-icf-1.c: New test.
* gcc.dg/ipa/ipa-icf-31.c: New test.

--- gcc/ipa-icf-gimple.c.jj 2014-10-30 14:42:20.0 +0100
+++ gcc/ipa-icf-gimple.c2014-11-10 19:08:38.339986360 +0100
@@ -554,7 +554,7 @@ func_checker::parse_labels (sem_bb *bb)
 
In general, a collection of equivalence dictionaries is built for types
like SSA names, declarations (VAR_DECL, PARM_DECL, ..). This infrastructure
-   is utilized by every statement-by-stament comparison function.  */
+   is utilized by every statement-by-statement comparison function.  */
 
 bool
 func_checker::compare_bb (sem_bb *bb1, sem_bb *bb2)
@@ -662,9 +662,49 @@ func_checker::compare_gimple_call (gimpl
   t1 = gimple_call_fndecl (s1);
   t2 = gimple_call_fndecl (s2);
 
-  /* Function pointer variables are not supported yet.  */
   if (!compare_operand (t1, t2))
-return return_false();
+return return_false ();
+
+  if (t1 == NULL_TREE)
+{
+  t1 = gimple_call_fn (s1);
+  t2 = gimple_call_fn (s2);
+  if (!compare_operand (t1, t2))
+   return return_false ();
+}
+
+  /* Compare flags.  */
+  if (gimple_call_internal_p (s1) != gimple_call_internal_p (s2)
+  || gimple_call_ctrl_altering_p (s1) != gimple_call_ctrl_altering_p (s2)
+  || gimple_call_tail_p (s1) != gimple_call_tail_p (s2)
+  || gimple_call_return_slot_opt_p (s1) != gimple_call_return_slot_opt_p 
(s2)
+  || gimple_call_from_thunk_p (s1) != gimple_call_from_thunk_p (s2)
+  || gimple_call_va_arg_pack_p (s1) != gimple_call_va_arg_pack_p (s2)
+  || gimple_call_alloca_for_var_p (s1) != gimple_call_alloca_for_var_p (s2)
+  || gimple_call_with_bounds_p (s1) != gimple_call_with_bounds_p (s2))
+return false;
+
+  if (gimple_call_internal_p (s1)
+  && gimple_call_internal_fn (s1) != gimple_call_internal_fn (s2))
+return false;
+
+  tree fntype1 = gimple_call_fntype (s1);
+  tree fntype2 = gimple_call_fntype (s2);
+  if (fntype1 == NULL_TREE)
+{
+  if (fntype2)
+   return false;
+}
+  else if (fntype2 == NULL_TREE)
+return false;
+  else if (!types_compatible_p (fntype1, fntype2))
+return return_false_with_msg ("call function types are not compatible");
+
+  tree chain1 = gimple_call_chain (s1);
+  tree chain2 = gimple_call_chain (s2);
+
+  if ((chain1 && !chain2) || (!chain1 && chain2))
+return return_false_with_msg ("Tree call chains are different");
 
   /* Checking of argument.  */
   for (i = 0; i < gimple_call_num_args (s1); ++i)
--- gcc/testsuite/gcc.dg/ubsan/ipa-icf-1.c.jj   2014-11-10 19:00:53.509525071 
+0100
+++ gcc/testsuite/gcc.dg/ubsan/ipa-icf-1.c  2014-11-10 19:02:21.836925806 
+0100
@@ -0,0 +1,23 @@
+/* { dg-do run } */
+/* { dg-skip-if "" { *-*-* } { "*" } { "-O2" } } */
+/* { dg-options "-fsanitize=undefined -fipa-icf" } */
+
+__attribute__ ((noinline, noclone))
+int f1 (int x, int y)
+{
+  return x + y;
+}
+
+__attribute__ ((noinline, noclone))
+int f2 (int x, int y)
+{
+  return x - y;
+}
+
+int
+main ()
+{
+  if (f1 (5, 6) != 11 || f2 (5, 6) != -1)
+__builtin_abort ();
+  return 0;
+}
--- gcc/testsuite/gcc.dg/ipa/ipa-icf-31.c.jj2014-11-10 18:59:16.604294652 
+0100
+++ gcc/testsuite/gcc.dg/ipa/ipa-icf-31.c   2014-11-10 18:59:59.690519616 
+0100
@@ -0,0 +1,41 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -fipa-icf" } */
+
+__attribute__ ((noinline, noclone))
+int f1 (int x, int (*p1) (void), int (*p2) (void))
+{
+  if (x)
+return p1 ();
+  else
+return p2 ();
+}
+
+__attribute__ ((noinline, noclone))
+int f2 (int x, int (*p1) (void), int (*p2) (void))
+{
+  if (x)
+return p2 ();
+  else
+return p1 ();
+}
+
+__attribute__ ((noinline, noclone))
+int f3 (void)
+{
+  return 1;
+}
+
+__attribute__ ((noinline, noclone))
+int f4 (void)
+{
+  return 2;
+}
+
+int
+main ()
+{
+  if (f1 (0, f3, f4) != 2 || f1 (1, f3, f4) != 1 || f2 (0, f3, f4) != 1
+  || f2 (1, f3, f4) != 2)
+__builtin_abort ();
+  return 0;
+}

Jakub


  1   2   >