Re: RFA: patch to fix PR69299

[Vladimir Makarov]

On 01/28/2016 08:05 AM, Jakub Jelinek wrote:

On Wed, Jan 27, 2016 at 04:01:23PM -0500, Vladimir Makarov wrote:

   The following patch fixes PR69299.

   The details of the problem is described on

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

   The patch was successfully bootstrapped and tested on x86/x86-64.

   The patch introduces a new type of constraints
define_special_memory_constraint for memory constraints whose address reload
can not make memory to satisfy the constraint.  It is useful when
specifically aligned memory is necessary or desirable. I don't know what is
the best name for this constraint.  I use special_memory_constraint but it
could be more specific, e.g. aligned_memory_constraint.  Please let me know
what is the best name for you.

   Is the patch ok to commit?

I support the general idea and for naming will defer to Jeff, just have some
nits below.  But it is your code and area of expertise, so I don't claim to
be an expert here...
Thanks for the comments, Jakub.  I am not sure about all these changes 
-- tt is hard to predict all possible consequences of the decisions 
because of the RA complexity.  But some comments made me rethink the patch.

--- ira-costs.c (revision 232571)
+++ ira-costs.c (working copy)
@@ -777,6 +777,7 @@ record_reg_classes (int n_alts, int n_op
  break;
  
  		case CT_MEMORY:

+   case CT_SPECIAL_MEMORY:
  /* Every MEM can be reloaded to fit.  */
  insn_allows_mem[i] = allows_mem[i] = 1;
  if (MEM_P (op))

The comment is true only for CT_MEMORY.  Wonder if it wouldn't be better to
handle CT_SPECIAL_MEMORY separately, perhaps as:

  case CT_SPECIAL_MEMORY:
if (MEM_P (op) && constraint_satisfied_p (op, cn))
  {
insn_allows_mem[i] = allows_mem[i] = 1;
win = 1;
  }
break;

?  I.e. if the constraint is already satisfied, treat it like memory
constraint, otherwise treat like (unsatisfied) fixed form constraint.
Or, if you want to account for the possibility that it doesn't satisfy the
constraint yet due to address that if reloaded would make it satisfy,
consider !memory_operand (op, ...) case as unknown, with no need to
check the constraint.  Because if op satisfies already memory_operand,
but doesn't constraint_satisfied_p, it means it will never satisfy.

The difference in code most probably does not affect generated code 
correctness but may change code quality.  After some thinking, I decided 
to change it to


  case CT_SPECIAL_MEMORY:
 if (MEM_P (op) && constraint_satisfied_p (op, cn))
win = 1;
 allows_mem[i] = insn_allows_mem[i] = 1;
 break;



--- ira.c   (revision 232571)
+++ ira.c   (working copy)
@@ -1868,6 +1868,7 @@ ira_setup_alts (rtx_insn *insn, HARD_REG
  
  			case CT_ADDRESS:

case CT_MEMORY:
+   case CT_SPECIAL_MEMORY:
  goto op_success;

Perhaps treat it like CT_FIXED_FORM here instead?  I.e. op_success only
if the constraint is satisfied?  Or perhaps treat it as possible op_success
if !memory_operand, as mentioned above.
This would exclude consideration of possible transformation: unaligned 
memory -> reg -> aligned memory.  LRA can figure out the profitability 
of this.  But taking complexity of RA we can do unaligned memory -> 
pseudo first assigning a hard reg to the pseudo and on later subpasses 
to spill the pseudo for some reasons.  Removing such RA freedom might 
result in having LRA stuck.

--- recog.c (revision 232571)
+++ recog.c (working copy)
@@ -1791,6 +1791,7 @@ asm_operand_ok (rtx op, const char *cons
  break;
  
  	case CT_MEMORY:

+   case CT_SPECIAL_MEMORY:
  /* Every memory operand can be reloaded to fit.  */
  result = result || memory_operand (op, VOIDmode);
  break;

Again, I'd treat it like CT_FIXED_FORM here, or at least if
memory_operand check also constraint_satisfied_p.


I would not change it.  The reasons are described in the previous comment.

I'll test the change for ira-costs.c.  If I find something wrong I'll 
wrote about it.

[Bug tree-optimization/69541] check ssa more often in parloops

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5

[Bug libstdc++/69450] [6 Regression] libstdc++-v3/include/math.h:66:1 2: error: 'constexpr bool std::isnan(double)' conflicts with a previous declaration

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
(In reply to amker from comment #13)
> I also saw this issue on aarch64, will test if the patch fixes it.

It's a C library conflict, not hardware-specific, so "aarch64" is not relevant.

The patch only affects HP-UX so unless you're running that on aarch64(!) it
won't make any difference.

[Bug target/65578] FAIL: gcc.target/arm/builtin-bswap-1.c (test for excess errors)

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Also note that this test currently fails its scan-assembler check for -marm due
to PR 67295

Re: [hsa merge 00/10] Merge of HSA branch

[Gerald Pfeifer]

Hi Martin,

On Wed, 27 Jan 2016, Martin Jambor wrote:
> So what would you think about the following?  Perhaps it is too
> verbose but I wanted to mention the few areas users should know 
> have changed, if they happen to try HSA out.  I can certainly 
> cut it down a bit.

I like this.  In fact, in one or two spots we even may want to
be a little bit longer on the changes.html page.  (Definitely a
good idea to split this into the shorter announcement and the
longer one for the release notes.)

> Index: changes.html
> ===
> + GCC can now generate HSAIL for simple OpenMP device constructs
> +   if configured with --enable-offload-targets=hsa.  A new
> +   libgomp plugin then run these HSAIL kernels implementing these
> +   constructs on HSA capable GPUs via standard HSA run-time.

"run" -> "runs"

"via a standard HSA"

"run-time" -> "run time" (since it's a noun)

Will everyone know what HSAIL is?  Should we expand the acronym
at first or note (in parenthesis what it is)?

> +   If the HSA compilation back-end determines it cannot output HSAIL
> +   for a particular input, it gives a warning by default.  These
> +   warnings can be suppressed with -Wno-hsa.  To give a
> +   few examples, the HSA back-end does not implement compilation of

"back end"

> +   code using function pointers and variable-sized variables and

"variable-sized variables" is a bit confusing. ;-)  Is there a
better term?  "variable-sized arrays" I know, for example.

> +   When compilation for HSA is enabled, the compiler attempts to
> +   compile composite OpenMP constructs
> +  
> +#pragma omp target teams distribute parallel for
> +  into parallel HSA GPU kernels.

Above we had "HSAIL kernels", here "HSA GPU kernels".  Should we
converge on one?

> Index: index.html
> ===
> + Heterogeneous Systems Architecture support in GCC

Here I would omit the "in GCC" since this is our main page.

> + [2016-01-27]
> + http://www.hsafoundation.com/;> Heterogeneous Systems
> + Architecture 1.0  href="https://gcc.gnu.org/gcc-6/changes.html#hsa;>
> + support was added to GCC.  Contributed by Martin Jambor, Martin 
> Liška
> + and Michael Matz from SUSE.

How about "to GCC, contributed by..."?

Not too long for the main page I'd say.


This is okay with the changes/considering the questions above.

Gerald

[Bug tree-optimization/69541] New: check ssa more often in parloops

[vries at gcc dot gnu.org]

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

Bug ID: 69541
   Summary: check ssa more often in parloops
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

It happens that we run into a parloops ssa update failure while processing loop
y, but the faulty ssa was introduced while processing loop x. This is somewhat
confusing, and it probably makes sense to verify ssa after processing each
loop:
 ...
@@ -2413,11 +2416,18 @@ gen_parallel_loop (struct loop *loop,
   if (reduction_list->elements () > 0)
 create_call_for_reduction (loop, reduction_list, _data);

+  update_ssa (TODO_update_ssa);
+  verify_ssa (true, true);
+
   scev_reset ();

   /* Free loop bound estimations that could contain references to
...
Perhaps only if flag_checking.

Furthermore, to pinpoint where the error is introduced, I tend to move the
update_ssa/verify_ssa calls backwards in gen_parallel_loop. But that doesn't
work at points were we always have invalid ssa, which is the case before
gen_parallel loop.  This patch fixes that:
...
diff --git a/gcc/tree-parloops.c b/gcc/tree-parloops.c
index 139e38c..2086a21 100644
--- a/gcc/tree-parloops.c
+++ b/gcc/tree-parloops.c
@@ -1411,6 +1411,8 @@ separate_decls_in_region (edge entry, edge exit,
   nvar = create_tmp_var (build_pointer_type (type), ".paral_data_load");
   *new_arg_struct = make_ssa_name (nvar);

+  SSA_NAME_IS_DEFAULT_DEF (*new_arg_struct) = 1;
+  SSA_NAME_DEF_STMT (*new_arg_struct) = gimple_build_nop ();
   ld_st_data->store = *arg_struct;
   ld_st_data->load = *new_arg_struct;
   ld_st_data->store_bb = bb0;
@@ -2070,6 +2072,7 @@ create_parallel_loop (struct loop *loop, tree loop_fn,
tree data,

  assign_stmt = gimple_build_assign (new_data,
 fold_convert (TREE_TYPE
(new_data), param));
+ SSA_NAME_IS_DEFAULT_DEF (new_data) = 0;
  gsi_insert_before (, assign_stmt, GSI_SAME_STMT);
}
...

[Bug c++/69517] [5/6 regression] SEGV on a VLA with excess initializer elements

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
(In reply to Martin Sebor from comment #3)
> Just to clarify: it's the program that crashes, not GCC (so removing the
> ice-on-invalid-code keyword).
> 
> But I also think that rejecting or at least loudly diagnosing the code would
> be preferable to letting it run off the rails.  We have tentatively agreed
> on this approach in a separate thread
> (https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02167.html) so someone just
> needs to put together a patch.  I'll see if I can find the time to do it if
> no one beats me to it.

Thanks.

> With that said, I wonder if restoring the exception that 4.9.3 would be
> feasible.  It seems like the ideal solution, in line with the array new
> expression.  Jason. were there problems with it that the exception throwing
> code had to be removed?

The only issue was that the exception class was removed from the working paper,
so it isn't part of C++14.  I'm open to restoring the throwing code, but we
should probably use a different exception type, either bad_array_new_length or
an extension.

[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||arm
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-28
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on trunk at least

[Bug c++/65608] [meta-bug] friend issues

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608
Bug 65608 depends on bug 67407, which changed state.

Bug 67407 Summary: [6 regression] ice in friend_accessible_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67407

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[PATCH 2/3] [graphite] use codegen_error_p

[Sebastian Pop]

* graphite-isl-ast-to-gimple.c (binary_op_to_tree): Call 
codegen_error_p.
(ternary_op_to_tree): Same.
(unary_op_to_tree): Same.
(nary_op_to_tree): Same.
(gcc_expression_from_isl_expr_op): Same.
(gcc_expression_from_isl_expression): Same.
(graphite_create_new_loop): Same.
(graphite_create_new_loop_guard): Same.
(build_iv_mapping): Same.
(graphite_create_new_guard): Same.
(translate_isl_ast_to_gimple::copy_loop_phi_nodes): Same.
(translate_isl_ast_to_gimple::translate_pending_phi_nodes): Same.
---
 gcc/graphite-isl-ast-to-gimple.c | 49 
 1 file changed, 25 insertions(+), 24 deletions(-)

diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-to-gimple.c
index 47225ef..ded1f74 100644
--- a/gcc/graphite-isl-ast-to-gimple.c
+++ b/gcc/graphite-isl-ast-to-gimple.c
@@ -438,16 +438,14 @@ class translate_isl_ast_to_gimple
vec iv_map);
 
   /* Duplicates the statements of basic block BB into basic block NEW_BB
- and compute the new induction variables according to the IV_MAP.
- CODEGEN_ERROR is set when the code generation cannot continue.  */
+ and compute the new induction variables according to the IV_MAP.  */
 
   bool graphite_copy_stmts_from_block (basic_block bb, basic_block new_bb,
   vec iv_map);
 
   /* Copies BB and includes in the copied BB all the statements that can
  be reached following the use-def chains from the memory accesses,
- and returns the next edge following this new block.  codegen_error is
- set when the code generation cannot continue.  */
+ and returns the next edge following this new block.  */
 
   edge copy_bb_and_scalar_dependences (basic_block bb, edge next_e,
   vec iv_map);
@@ -480,8 +478,7 @@ class translate_isl_ast_to_gimple
  RENAME_MAP, inserting the gimplification code at GSI_TGT, for the
  translation REGION, with the original copied statement in LOOP, and using
  the induction variable renaming map IV_MAP.  Returns true when something
- has been renamed.  codegen_error is set when the code generation cannot
- continue.  */
+ has been renamed.  */
 
   bool rename_uses (gimple *copy, gimple_stmt_iterator *gsi_tgt,
basic_block old_bb, loop_p loop, vec iv_map);
@@ -597,7 +594,7 @@ binary_op_to_tree (tree type, __isl_take isl_ast_expr 
*expr, ivs_params )
   enum isl_ast_op_type expr_type = isl_ast_expr_get_op_type (expr);
   isl_ast_expr_free (expr);
 
-  if (codegen_error)
+  if (codegen_error_p ())
 return NULL_TREE;
 
   switch (expr_type)
@@ -699,7 +696,7 @@ ternary_op_to_tree (tree type, __isl_take isl_ast_expr 
*expr, ivs_params )
   tree c = gcc_expression_from_isl_expression (type, arg_expr, ip);
   isl_ast_expr_free (expr);
 
-  if (codegen_error)
+  if (codegen_error_p ())
 return NULL_TREE;
 
   return fold_build3 (COND_EXPR, type, a, b, c);
@@ -716,7 +713,8 @@ unary_op_to_tree (tree type, __isl_take isl_ast_expr *expr, 
ivs_params )
   isl_ast_expr *arg_expr = isl_ast_expr_get_op_arg (expr, 0);
   tree tree_expr = gcc_expression_from_isl_expression (type, arg_expr, ip);
   isl_ast_expr_free (expr);
-  return codegen_error ? NULL_TREE : fold_build1 (NEGATE_EXPR, type, 
tree_expr);
+  return codegen_error_p () ? NULL_TREE
+: fold_build1 (NEGATE_EXPR, type, tree_expr);
 }
 
 /* Converts an isl_ast_expr_op expression E with unknown number of arguments
@@ -743,7 +741,7 @@ nary_op_to_tree (tree type, __isl_take isl_ast_expr *expr, 
ivs_params )
   isl_ast_expr *arg_expr = isl_ast_expr_get_op_arg (expr, 0);
   tree res = gcc_expression_from_isl_expression (type, arg_expr, ip);
 
-  if (codegen_error)
+  if (codegen_error_p ())
 {
   isl_ast_expr_free (expr);
   return NULL_TREE;
@@ -755,7 +753,7 @@ nary_op_to_tree (tree type, __isl_take isl_ast_expr *expr, 
ivs_params )
   arg_expr = isl_ast_expr_get_op_arg (expr, i);
   tree t = gcc_expression_from_isl_expression (type, arg_expr, ip);
 
-  if (codegen_error)
+  if (codegen_error_p ())
{
  isl_ast_expr_free (expr);
  return NULL_TREE;
@@ -775,7 +773,7 @@ translate_isl_ast_to_gimple::
 gcc_expression_from_isl_expr_op (tree type, __isl_take isl_ast_expr *expr,
 ivs_params )
 {
-  if (codegen_error)
+  if (codegen_error_p ())
 {
   isl_ast_expr_free (expr);
   return NULL_TREE;
@@ -837,7 +835,7 @@ translate_isl_ast_to_gimple::
 gcc_expression_from_isl_expression (tree type, __isl_take isl_ast_expr *expr,
ivs_params )
 {
-  if (codegen_error)
+  if (codegen_error_p ())
 {
   isl_ast_expr_free (expr);
   return NULL_TREE;
@@ -879,7 +877,7 @@ graphite_create_new_loop (edge entry_edge, __isl_keep 
isl_ast_node *node_for,
   tree stride = 

[Bug c++/69517] [5/6 regression] SEGV on a VLA with excess initializer elements

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |

--- Comment #3 from Martin Sebor  ---
Just to clarify: it's the program that crashes, not GCC (so removing the
ice-on-invalid-code keyword).

But I also think that rejecting or at least loudly diagnosing the code would be
preferable to letting it run off the rails.  We have tentatively agreed on this
approach in a separate thread
(https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02167.html) so someone just
needs to put together a patch.  I'll see if I can find the time to do it if no
one beats me to it.

With that said, I wonder if restoring the exception that 4.9.3 would be
feasible.  It seems like the ideal solution, in line with the array new
expression.  Jason. were there problems with it that the exception throwing
code had to be removed?

[Bug middle-end/69526] ivopts candidate strangeness

[amker at gcc dot gnu.org]

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

--- Comment #6 from amker at gcc dot gnu.org ---
(In reply to rdapp from comment #5)
> I still don't quite get why the "n - 1" is needed. Do we need it to possibly
> have an exit condition like
> 
>  if (i != n-1) or 
>  if (i <= n-1)?
> 
> Am I missing something really obvious here?

The dump before ivopt is as below:

  :
  if (n_5(D) != 0)
goto ;
  else
goto ;

  :
  return;

  :

  :
  # i_18 = PHI <0(4), i_14(7)>
  _6 = (long unsigned int) i_18;
  _7 = _6 * 8;
  _9 = out_8(D) + _7;
  _11 = in_10(D) + _7;
  _12 = *_11;
  *_9 = _12;
  i_14 = i_18 + 1;
  i.0_4 = (unsigned int) i_14;
  if (i.0_4 < n_5(D))
goto ;
  else
goto ;

  :
  goto ;

  :
  goto ;


It comes from loop niter analysis, as in may_eliminate_iv, we have:

(gdb) call debug_generic_expr(desc->niter)
n_5(D) + 4294967295

[Bug c++/67407] [6 regression] ice in friend_accessible_p

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jason Merrill  ---
Fixed.

RE: [Patch, MIPS] Patch for PR 68400, a mips16 bug

[Moore, Catherine]

> -Original Message-
> From: Steve Ellcey [mailto:sell...@imgtec.com]
> Sent: Tuesday, January 26, 2016 3:43 PM
> To: gcc-patches@gcc.gnu.org
> Cc: matthew.fort...@imgtec.com; Moore, Catherine
> Subject: [Patch, MIPS] Patch for PR 68400, a mips16 bug
> 
> Here is a patch for PR6400.  The problem is that and_operands_ok was
> checking one operand to see if it was a memory_operand but MIPS16
> addressing is more restrictive than what the general memory_operand
> allows.  The fix was to call mips_classify_address if TARGET_MIPS16 is set
> because it will do a more complete mips16 addressing check and reject
> operands that do not meet the more restrictive requirements.
> 
> I ran the GCC testsuite with no regressions and have included a test case as
> part of this patch.
> 
> OK to checkin?
> 
> Steve Ellcey
> sell...@imgtec.com
> 
> 
> 2016-01-26  Steve Ellcey  
> 
>   PR target/68400
>   * config/mips/mips.c (and_operands_ok): Add MIPS16 check.
> 
> 
> 
This is OK.
Thanks, Catherine

[Bug libstdc++/69450] [6 Regression] libstdc++-v3/include/math.h:66:1 2: error: 'constexpr bool std::isnan(double)' conflicts with a previous declaration

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #13 from amker at gcc dot gnu.org ---
(In reply to John David Anglin from comment #12)
> Fixed.

I also saw this issue on aarch64, will test if the patch fixes it.

Thanks,

[Bug middle-end/69542] [6 Regression] -fcompare-debug failure in simplify-rtx.c on i?86 since r232905

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-28
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

[Bug middle-end/69542] New: [6 Regression] -fcompare-debug failure in simplify-rtx.c on i?86 since r232905

[jakub at gcc dot gnu.org]

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

Bug ID: 69542
   Summary: [6 Regression] -fcompare-debug failure in
simplify-rtx.c on i?86 since r232905
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

r232905 breaks bootstrap on i686-linux, with miscompare of simplify-rtx.o.
I'm still reducing testcase for this, but have bisected it to this commit
already.
Guess either the
 if (regno >= FIRST_PSEUDO_REGISTER && reg->subreg_p)
680  bitmap_set_bit (_regs, regno);
or perhaps the whole set_bb_regs function should not be called for DEBUG_INSNs.
I think it shouldn't contain any type != OP_IN regs anyway, nor REG_DEAD notes.

[Bug libstdc++/69450] [6 Regression] libstdc++-v3/include/math.h:66:1 2: error: 'constexpr bool std::isnan(double)' conflicts with a previous declaration

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
Amker, if you're talking about aarch64-*-*gnu* then that's not this bug
(because this is about HP-UX). I assume you're using glibc from git, in which
case see 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69413#c2

Re: RFA (tree.h): C++ PATCH for c++/67407 (ICE with protected access)

[Jason Merrill]

On 01/28/2016 10:09 AM, Jakub Jelinek wrote:

On Thu, Jan 28, 2016 at 10:03:59AM -0500, Jason Merrill wrote:

In this testcase, the problem was that we were checking DERIVED_FROM_P,
which uses dfs_walk_once and thus BINFO_MARKED, in the middle of a
dfs_walk_once_accessible, which also uses BINFO_MARKED, and the marks from
one walk were confusing the other walk.  Fixed by moving these binfo walking
functions to use a hash_set instead of BINFO_MARKED.

After this change, there are no uses of BINFO_MARKED left in the source
tree, so I'm inclined to rename it to BINFO_LANG_FLAG_0.  OK?


LGTM.
Do you see any measurable compatile time differences with this patch
on some large C++ preprocessed source (say some boost one)?


Nope.

Jason

[Bug target/68662] [6 regression] FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects

[bergner at gcc dot gnu.org]

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

--- Comment #12 from Peter Bergner  ---
Should we add an assert somewhere to ensure that flag_pic and
TARGET_RELOCATABLE are consistent?

Default compute dimensions

[Nathan Sidwell]

This patch adds default compute dimension handling.  Users rarely specify 
compute dimensions, expecting the toolchain to DTRT.  More savvy users would 
like to specify global defaults.  This patch permits both.


While the vector and worker dimensions are constrained by the target CPU 
implementation, the number of gangs is arbitrary.  The number that can compute 
in parallel depends on the physical number on your accelerator board -- but 
that's hidden behind the runtime API, which will schedule logical instances onto 
 the physical devices an an arbitrary order.  Without this patch, one's reliant 
 on the user specifying 'num_gangs(G)' with a  suitable 'G' on each offload 
region.  General code tends not to do that.Further, if one's relying on 
automatic paritioning in a parallel region via

#pragma acc loop auto
(we default auto there, if nothing overrides it)

then the user has no way of knowing which set of partions were being used, so 
would be unwise to specify a particular axis with non-unity size.


Hence this patch.

We add a '-fopenacc-dim=G:W:V' option, where G, W, & V are integer constants.  A 
particular entry may be omitted to get the default value.  I envision extending 
this to device_type support with something like DEV_T:G:W:V as comma-separated 
tuples.


If the option is omitted -- or dimensions not completely specified -- the 
backend gets to pick defaults.  For PTX we already force V as 32, and bounded W 
at 32 (but permitted smaller values).  This patch sets W & G to 32.  Explicitly 
specified values go through backend range checking.


The backend validate_dims hook is extended to handle these cases (with a NULL 
fndecl arg), and it is also changed to not fill in defaults (except in the case 
of determining the global default).


The loop partitioning code in the oacc dev lower pass is rearranged to return 
the mask of partition axes used, and then that pass selects a suitable default 
value for axes that are unspecified -- either the default value, or the minimum 
permitted value.


The outcome is that the naive user will get multiple compute elements for 
'#pragma acc loop' use in a parallel region, whereas before they had to specify 
the number of elements to guarantee that (but as mentioned above would then want 
to specify which axis each loop should be partitioned over).


ok?

nathan
2016-01-28  Nathan Sidwell  

	gcc/
	* config/nvptx/nvptx.c (PTX_GANG_DEFAULT): New.
	(nvptx_goacc_validate_dims): Extend to handle global defaults.
	* target.def (OACC_VALIDATE_DIMS): Extend documentation.
	* doc/tm.texti: Rebuilt.
	* doc/invoke.texi (fopenacc-dim): Document.
	* lto-wrapper.c (merge_and_complain): Add OPT_fopenacc_dim_ case.
	(append_compiler_options): Likewise.
	* omp-low.c (oacc_default_dims, oacc_min_dims): New.
	(oacc_parse_default_dims): New.
	(oacc_validate_dims): Add USED arg.  Select non-unity default when
	possible.
	(oacc_loop_fixed_partitions): Return mask of used partitions.
	(oacc_loop_auto_partitions): Emit dump info.
	(oacc_loop_partition): Return mask of used partitions.
	(execute_oacc_device_lower): Parse default dimension arg.  Adjust
	loop partitioning and validation calls.

	gcc/c-family/
	* c.opt (fopenacc-dim=): New option.

	gcc/fortran/
	* lang.opt (fopenacc-dim=): New option.

	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/loop-dim-default.c: New.
	* testsuite/libgomp.oacc-fortran/routine-7.f90: Serialize loop.

Index: gcc/config/nvptx/nvptx.c
===
--- gcc/config/nvptx/nvptx.c	(revision 232881)
+++ gcc/config/nvptx/nvptx.c	(working copy)
@@ -4122,10 +4122,12 @@ nvptx_expand_builtin (tree exp, rtx targ
 /* Define dimension sizes for known hardware.  */
 #define PTX_VECTOR_LENGTH 32
 #define PTX_WORKER_LENGTH 32
+#define PTX_GANG_DEFAULT  32
 
 /* Validate compute dimensions of an OpenACC offload or routine, fill
in non-unity defaults.  FN_LEVEL indicates the level at which a
-   routine might spawn a loop.  It is negative for non-routines.  */
+   routine might spawn a loop.  It is negative for non-routines.  If
+   DECL is null, we are validating the default dimensions.  */
 
 static bool
 nvptx_goacc_validate_dims (tree decl, int dims[], int fn_level)
@@ -4133,11 +4135,12 @@ nvptx_goacc_validate_dims (tree decl, in
   bool changed = false;
 
   /* The vector size must be 32, unless this is a SEQ routine.  */
-  if (fn_level <= GOMP_DIM_VECTOR
+  if (fn_level <= GOMP_DIM_VECTOR && fn_level >= -1
+  && dims[GOMP_DIM_VECTOR] >= 0
   && dims[GOMP_DIM_VECTOR] != PTX_VECTOR_LENGTH)
 {
-  if (dims[GOMP_DIM_VECTOR] >= 0 && fn_level < 0)
-	warning_at (DECL_SOURCE_LOCATION (decl), 0,
+  if (fn_level < 0 && dims[GOMP_DIM_VECTOR] >= 0)
+	warning_at (decl ? DECL_SOURCE_LOCATION (decl) : UNKNOWN_LOCATION, 0,
 		dims[GOMP_DIM_VECTOR]
 		? "using vector_length (%d), ignoring %d"
 		: "using vector_length (%d), ignoring runtime setting",

[Bug c++/68949] [5/6 Regression] Implicit initialization of array member silently miscompiling.

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Jason Merrill  ---
Fixed.

[PATCH 3/3] [graphite] remove out of sync comments

[Sebastian Pop]

* graphite-isl-ast-to-gimple.c (class translate_isl_ast_to_gimple):
Remove comments from class declarations: they are already in the code
close by the defs.
---
 gcc/graphite-isl-ast-to-gimple.c | 437 ---
 1 file changed, 83 insertions(+), 354 deletions(-)

diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-to-gimple.c
index ded1f74..161b434 100644
--- a/gcc/graphite-isl-ast-to-gimple.c
+++ b/gcc/graphite-isl-ast-to-gimple.c
@@ -171,342 +171,117 @@ class translate_isl_ast_to_gimple
 {
  public:
   translate_isl_ast_to_gimple (sese_info_p r)
-: region (r), codegen_error (false)
-{ }
-
-  /* Translates an isl AST node NODE to GCC representation in the
- context of a SESE.  */
+: region (r), codegen_error (false) { }
   edge translate_isl_ast (loop_p context_loop, __isl_keep isl_ast_node *node,
  edge next_e, ivs_params );
-
-  /* Translates an isl_ast_node_for to Gimple.  */
   edge translate_isl_ast_node_for (loop_p context_loop,
   __isl_keep isl_ast_node *node,
   edge next_e, ivs_params );
-
-  /* Create the loop for a isl_ast_node_for.
-
- - NEXT_E is the edge where new generated code should be attached.  */
   edge translate_isl_ast_for_loop (loop_p context_loop,
   __isl_keep isl_ast_node *node_for,
   edge next_e,
   tree type, tree lb, tree ub,
   ivs_params );
-
-  /* Translates an isl_ast_node_if to Gimple.  */
   edge translate_isl_ast_node_if (loop_p context_loop,
  __isl_keep isl_ast_node *node,
  edge next_e, ivs_params );
-
-  /* Translates an isl_ast_node_user to Gimple.
-
- FIXME: We should remove iv_map.create (loop->num + 1), if it is
- possible.  */
   edge translate_isl_ast_node_user (__isl_keep isl_ast_node *node,
edge next_e, ivs_params );
-
-  /* Translates an isl_ast_node_block to Gimple.  */
   edge translate_isl_ast_node_block (loop_p context_loop,
 __isl_keep isl_ast_node *node,
 edge next_e, ivs_params );
-
-  /* Converts a unary isl_ast_expr_op expression E to a GCC expression tree of
- type TYPE.  */
   tree unary_op_to_tree (tree type, __isl_take isl_ast_expr *expr,
 ivs_params );
-
-  /* Converts a binary isl_ast_expr_op expression E to a GCC expression tree of
- type TYPE.  */
   tree binary_op_to_tree (tree type, __isl_take isl_ast_expr *expr,
  ivs_params );
-
-  /* Converts a ternary isl_ast_expr_op expression E to a GCC expression tree 
of
- type TYPE.  */
   tree ternary_op_to_tree (tree type, __isl_take isl_ast_expr *expr,
   ivs_params );
-
-  /* Converts an isl_ast_expr_op expression E with unknown number of arguments
- to a GCC expression tree of type TYPE.  */
   tree nary_op_to_tree (tree type, __isl_take isl_ast_expr *expr,
ivs_params );
-
-  /* Converts an isl AST expression E back to a GCC expression tree of
- type TYPE.  */
   tree gcc_expression_from_isl_expression (tree type,
   __isl_take isl_ast_expr *,
   ivs_params );
-
-  /* Return the tree variable that corresponds to the given isl ast identifier
- expression (an isl_ast_expr of type isl_ast_expr_id).
-
- FIXME: We should replace blind conversation of id's type with derivation
- of the optimal type when we get the corresponding isl support.  Blindly
- converting type sizes may be problematic when we switch to smaller
- types.  */
   tree gcc_expression_from_isl_ast_expr_id (tree type,
__isl_keep isl_ast_expr *expr_id,
ivs_params );
-
-  /* Converts an isl_ast_expr_int expression E to a GCC expression tree of
- type TYPE.  */
   tree gcc_expression_from_isl_expr_int (tree type,
 __isl_take isl_ast_expr *expr);
-
-  /* Converts an isl_ast_expr_op expression E to a GCC expression tree of
- type TYPE.  */
   tree gcc_expression_from_isl_expr_op (tree type,
__isl_take isl_ast_expr *expr,
ivs_params );
-
-  /* Creates a new LOOP corresponding to isl_ast_node_for.  Inserts an
- induction variable for the new LOOP.  New LOOP is attached to CFG
- starting at ENTRY_EDGE.  LOOP is inserted into the loop tree and
- becomes the child loop of the OUTER_LOOP.  NEWIVS_INDEX binds
- isl's scattering name to the induction variable created for the
- loop of STMT.  The new induction variable 

[PATCH 1/3] [graphite] assert instead of silently failing code gen

[Sebastian Pop]

* graphite-isl-ast-to-gimple.c (get_rename_from_scev): Assert instead of
setting codegen_error to fail codegen.
---
 gcc/graphite-isl-ast-to-gimple.c | 26 ++
 1 file changed, 6 insertions(+), 20 deletions(-)

diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-to-gimple.c
index 81ed304..47225ef 100644
--- a/gcc/graphite-isl-ast-to-gimple.c
+++ b/gcc/graphite-isl-ast-to-gimple.c
@@ -1833,31 +1833,18 @@ get_rename_from_scev (tree old_name, gimple_seq *stmts, 
loop_p loop,
   tree scev = scalar_evolution_in_region (region->region, loop, old_name);
 
   /* At this point we should know the exact scev for each
- scalar SSA_NAME used in the scop: all the other scalar
- SSA_NAMEs should have been translated out of SSA using
- arrays with one element.  */
-  tree new_expr;
-  if (chrec_contains_undetermined (scev))
-{
-  codegen_error = true;
-  return build_zero_cst (TREE_TYPE (old_name));
-}
+ scalar SSA_NAME used in the scop.  */
+  gcc_assert (!chrec_contains_undetermined (scev));
 
-  new_expr = chrec_apply_map (scev, iv_map);
+  tree new_expr = chrec_apply_map (scev, iv_map);
 
   /* The apply should produce an expression tree containing
  the uses of the new induction variables.  We should be
  able to use new_expr instead of the old_name in the newly
  generated loop nest.  */
-  if (chrec_contains_undetermined (new_expr)
-  || tree_contains_chrecs (new_expr, NULL))
-{
-  codegen_error = true;
-  return build_zero_cst (TREE_TYPE (old_name));
-}
+  gcc_assert (!chrec_contains_undetermined (new_expr)
+ && !tree_contains_chrecs (new_expr, NULL));
 
-  /* We should check all the operands and all of them should dominate the use 
at
- new_expr.  */
   if (TREE_CODE (new_expr) == SSA_NAME)
 {
   basic_block bb = gimple_bb (SSA_NAME_DEF_STMT (new_expr));
@@ -1898,8 +1885,7 @@ get_rename_from_scev (tree old_name, gimple_seq *stmts, 
loop_p loop,
substitution map RENAME_MAP, inserting the gimplification code at
GSI_TGT, for the translation REGION, with the original copied
statement in LOOP, and using the induction variable renaming map
-   IV_MAP.  Returns true when something has been renamed.  codegen_error
-   is set when the code generation cannot continue.  */
+   IV_MAP.  Returns true when something has been renamed.  */
 
 bool
 translate_isl_ast_to_gimple::rename_uses (gimple *copy,
-- 
2.5.0

Compiling with -m64 using attribute interrupt emits IRET not IRETQ

[Wink Saville]

I using hjl/interrupt/gcc-5-branch and my program is crashing when I
issue an INT xx. The problem appears to me to be that using
__attribute__ ((interrupt)) causes the a IRET to be emitted when an
IRETQ should be emitted. Below is my trivial do nothing main.c which I
compile with and then use objdump to view the assembler source.

I compiled x86_64-unknown-elf- using crosstool-ng, could that be a problem?

$ cat main.c
typedef unsigned long u64;

typedef struct intr_frame {
  u64 ip;
  u64 cs;
  u64 flags;
  u64 sp;
  u64 ss;
} intr_frame;

__attribute__ ((interrupt))
void ih(struct intr_frame* frame) {
}

void main(void) {
}

$ x86_64-unknown-elf-gcc -c main.c -o main.o -m64
$ x86_64-unknown-elf-objdump -d main.o

main.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0: 55   push   %rbp
   1: 48 89 e5 mov%rsp,%rbp
   4: 50   push   %rax
   5: 48 8d 45 08   lea0x8(%rbp),%rax
   9: 48 89 45 f0   mov%rax,-0x10(%rbp)
   d: 90   nop
   e: 58   pop%rax
   f: 5d   pop%rbp
  10: cf   iret

0011 :
  11: 55   push   %rbp
  12: 48 89 e5 mov%rsp,%rbp
  15: 90   nop
  16: 5d   pop%rbp
  17: c3   retq

Re: RFC: Support non-standard extension (call via casted function pointer)

[Michael Karcher]

On 28.01.2016 11:04, Andreas Schwab wrote:
> John Paul Adrian Glaubitz  writes:
>
>> [suggestion to use "void" as dummy return type]
>>
>> Wait. Do you think this would actually allow ghc to determine the
>> return type later? If I remember correctly, ghc currently initially
>> declares the function prototype with return type void*, doesn't it?
> Replace a lie with a different lie.  Spot the pattern?
>
> Andreas.
I am sorry, I fail to spot any pattern. As I understood you, you are
opposed to changing gcc because a program that lies to gcc fails to get
the result this program expects. But I don't see any pattern in
"replacing a lie with a different lie". Please be more specific in what
your message should tell the recipients.

In case you refer to the ppc64el issue of ghc, and try to imply that
changing lies at it fits has precedence in ghc history (and thus ghc
either needs to stop lying or find a new lie that just happens to work),
I strongly disagree. In that case, ghc developers not "replace a lie
with a different lie", but replaced a lie "(empty parameter list)" with
the truth "(unknown parameter list)".

Regards,
  Michael Karcher

[Bug c++/69549] New: Named Address Spaces does not compile in C++

[thiago at kde dot org]

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

Bug ID: 69549
   Summary: Named Address Spaces does not compile in C++
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org
  Target Milestone: ---

It works in C:

$ cat test.c
__seg_gs char * ptr;
$ gcc -c test.c && echo Success
Success

But not in C++:

$ gcc -xc++ -c test.c
test.c:1:1: error: ‘__seg_gs’ does not name a type

Even though it's advertised as supported:

$ gcc -xc++ -dM -E /dev/null | grep SEG_GS   
#define __SEG_GS 1

[gomp4] Merge trunk r232931 (2016-01-28) into gomp-4_0-branch

[Thomas Schwinge]

Hi!

Committed to gomp-4_0-branch in r232967:

commit 5999e6842d3f9cecc5cb500ebf692f54158e8017
Merge: 9cfa5d5 b547a9b
Author: tschwinge 
Date:   Fri Jan 29 06:46:35 2016 +

svn merge -r 232548:232931 svn+ssh://gcc.gnu.org/svn/gcc/trunk


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@232967 
138bc75d-0d04-0410-961f-82ee72b054a4


Grüße
 Thomas

Re: [gomp4, PR68977, Committed] Don't gimplify in ssa mode if seen_error in oacc_xform_loop

[Richard Biener]

On Thu, Jan 28, 2016 at 6:49 PM, Tom de Vries  wrote:
> On 28/01/16 14:32, Richard Biener wrote:
>>
>> On Mon, Jan 25, 2016 at 12:00 PM, Tom de Vries 
>> wrote:
>>>
>>> On 14/01/16 10:43, Richard Biener wrote:


 On Wed, Jan 13, 2016 at 9:04 PM, Tom de Vries 
 wrote:
>
>
> Hi,
>
> At r231739, there was an ICE when checking code generated by
> oacc_xform_loop, in case the source contained an error.
>
> Due to seen_error (), gimplification during oacc_xform_loop bailed out,
> and
> an uninitialized var was introduced.  Because of gimplifying in ssa
> mode,
> that caused an ICE.
>
> I can't reproduce this any longer, but I think the fix still makes
> sense.
> The patch makes sure oacc_xform_loop gimplifies in non-ssa mode if
> seen_error ().



 I don't think it makes "sense" in any way.  After seen_error () a
 following ICE
 will be "confused after earlier errors" in release mode and thus I think
 that's
 not an important problem to paper over with this kind of "hack".

 I'd rather avoid doing any of omp-low if seen_error ()?

>>>
>>> The error triggered in oacc_device_lower, so there's nothing we can do
>>> before (in omp-low).
>>>
>>> How about this fix, which replaces the oacc ifn calls with
>>> zero-assignments
>>> if seen_error ()?
>>
>>
>> Again it looks like too much complexity for an ICE-after-error which will
>> be reported as "confused after errors" only.
>
>
> IMO it's not much different from what is done in lower_omp_1:
> ...
>   /* If we have issued syntax errors, avoid doing any heavy lifting.
>  Just replace the OMP directives with a NOP to avoid
>  confusing RTL expansion.  */
>   if (seen_error () && is_gimple_omp (stmt))
> {
>   gsi_replace (gsi_p, gimple_build_nop (), true);
>   return;
> }
> ...
>
>> I'd accept a patch that simply
>> stops processing the function before lowering which is what we usually
>> do with this kind of cases [yes, it might make sense to start tracking
>> seen-error per function].
>>
>
> [ AFAIU, the patch below stops after lowering. ]
>
>
>> So in this case add a seen_errors () guard to cgraph_node::expand ()
>> like the following:
>>
>> Index: cgraphunit.c
>> ===
>> --- cgraphunit.c(revision 232666)
>> +++ cgraphunit.c(working copy)
>> @@ -1967,15 +1967,18 @@ cgraph_node::expand (void)
>>
>> execute_all_ipa_transforms ();
>>
>> -  /* Perform all tree transforms and optimizations.  */
>> -
>> -  /* Signal the start of passes.  */
>> -  invoke_plugin_callbacks (PLUGIN_ALL_PASSES_START, NULL);
>> -
>> -  execute_pass_list (cfun, g->get_passes ()->all_passes);
>> -
>> -  /* Signal the end of passes.  */
>> -  invoke_plugin_callbacks (PLUGIN_ALL_PASSES_END, NULL);
>> +  if (! seen_error ())
>> +{
>> +  /* Perform all tree transforms and optimizations.  */
>> +
>> +  /* Signal the start of passes.  */
>> +  invoke_plugin_callbacks (PLUGIN_ALL_PASSES_START, NULL);
>> +
>> +  execute_pass_list (cfun, g->get_passes ()->all_passes);
>> +
>> +  /* Signal the end of passes.  */
>> +  invoke_plugin_callbacks (PLUGIN_ALL_PASSES_END, NULL);
>> +}
>>
>> bitmap_obstack_release (_obstack);
>
>
> I suppose the patch makes sense in general.
>
> But it doesn't address the scenario I'm trying to fix:
> pass_oacc_device_lower signals an error, and then may run into an ICE during
> gimplification in that same pass.
>
> What would work (and is less fine-grained than the solutions I've proposed
> until now) is bailing out of pass_oacc_device_lower once seen_error, before
> doing any gimplification, and then not running any further passes, to
> prevent running into further ICEs.

I see.  Is it possible to simply scrub the whole OACC region in this
case instead?
Or even better, report those errors earlier?

Richard.

> Thanks,
> - Tom
>

Re: [PATCH] Use vm in sse2_cvtps2pd

[Uros Bizjak]

On Fri, Jan 29, 2016 at 5:01 AM, H.J. Lu  wrote:
> sse2_cvtps2pd has
>
> (define_insn "sse2_cvtps2pd"
>   [(set (match_operand:V2DF 0 "register_operand" "=v")
> (float_extend:V2DF
>   (vec_select:V2SF
> (match_operand:V4SF 1 "vector_operand" "vBm")
> (parallel [(const_int 0) (const_int 1)]]
>
> The memory operand size is 8 bytes (2 floats).  We should use vm instead
> of vBm.  Tested on Linux/x86-64.  OK for trunk?

OK with a ChangeLog.

Thanks,
Uros.

>
> H.J.
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 84d2b7a..ac96bbf 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -5464,7 +5464,7 @@
>[(set (match_operand:V2DF 0 "register_operand" "=v")
> (float_extend:V2DF
>   (vec_select:V2SF
> -   (match_operand:V4SF 1 "vector_operand" "vBm")
> +   (match_operand:V4SF 1 "vector_operand" "vm")
> (parallel [(const_int 0) (const_int 1)]]
>"TARGET_SSE2 && "
>"%vcvtps2pd\t{%1, %0|%0, %q1}"

[Bug middle-end/69526] ivopts candidate strangeness

[rdapp at linux dot vnet.ibm.com]

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

--- Comment #5 from rdapp at linux dot vnet.ibm.com ---
I still don't quite get why the "n - 1" is needed. Do we need it to possibly
have an exit condition like

 if (i != n-1) or 
 if (i <= n-1)?

Am I missing something really obvious here?

[Bug driver/40200] ''gcc file.cpp -o file.cpp'' overwrites input file

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dmalcolm at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from David Malcolm  ---
Yes, this has bitten me (esp. with Makefiles).

Looks like this was implemented in r217391; resolving as dup of PR 36312.

*** This bug has been marked as a duplicate of bug 36312 ***

[Bug driver/36312] should refuse to overwrite input file with output file

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||_paul at bk dot ru

--- Comment #20 from David Malcolm  ---
*** Bug 40200 has been marked as a duplicate of this bug. ***

Re: [PATCH] Fix cp_binding_level reuse logic

[Jason Merrill]

On 01/27/2016 07:44 PM, Patrick Palka wrote:

In begin_scope(), we are accidentally clearing the entire
free_binding_level store whenever we reuse a single GC-alloced
cp_binding_level structure from it.  This happens because we erroneously
update free_binding_level _after_ the pointer pointing to the next
available structure has been cleared, rather than doing it the other way
around.  This patch reorders the two operations.

This bug was introduced in commit 43959b95a / r118903 back in 2006,
during a refactoring of XNEW/memset -> XCNEW etc.

Using a dummy test file of mine (which simply #includes almost all of
the C++ stdlib headers), according to -ftime-report and
/usr/bin/time -v, this patch reduces the amount of GGC memory
allocated from 150MB to 148MB and reduces the maximum RSS from 130MB to
128MB, in each case a reduction of 1.5% or so.  Of course, this is because we 
now
reuse more and allocate fewer cp_binding_level structures.

Bootstrapped + regtested on x86_64-pc-linux-gnu, OK to commit at this
stage?  Or for stage 1?


I suppose this qualifies as a regression fix.  OK.

Jason

[Bug middle-end/69526] ivopts candidate strangeness

[amker at gcc dot gnu.org]

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

--- Comment #8 from amker at gcc dot gnu.org ---
(In reply to rdapp from comment #7)
> (In reply to amker from comment #6)
> 
> > It comes from loop niter analysis, as in may_eliminate_iv, we have:
> > 
> > (gdb) call debug_generic_expr(desc->niter)
> > n_5(D) + 4294967295
> 
> and this is correct? I.e. the number of iterations is n - 1? I'd naively
> expect 
>   desc->niter = n_5(D)
> 
> (Again, it might be necessary for some reason escapes me currently)

It confused me too, but niter in tree_niter_desc means the number of time latch
is executed, as commented in tree-ssa-loop.h:

  tree niter;   /* The expression giving the number of iterations of
   a loop (provided that assumptions == true and
   may_be_zero == false), more precisely the number
   of executions of the latch of the loop.  */

[Bug c/69540] New: add a short info on .so priority in -l

[arkadiusz at drabczyk dot org]

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

Bug ID: 69540
   Summary: add a short info on .so priority in -l
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arkadiusz at drabczyk dot org
  Target Milestone: ---

Not a big thing but just to limit a discrepancy between what gcc says
and what it actually does I think it's a good idea to add a few words
about .so to a description of -l in gcc/doc/invoke.texi.  Currently
only .a files are mentioned but in fact not only are .so also searched
but have priority over .a.  It could be something like:

"The only difference between using an @option{-l} option and
specifying a file name is that @option{-l} surrounds @var{library}
with @samp{lib} and @samp{.so} on systems with shared libraries
support or with @samp{.a} if @var{library} with @samp{.so} is not
found and on all other system and searches several directories."

Anybody who needs more details will look into ld manual anyway.

Re: new port: vn8

[Joseph Myers]

On Wed, 27 Jan 2016, Sandra Loosemore wrote:

> On 01/27/2016 08:47 PM, Nguyễn Sinh Ngọc wrote:
> > > Where is the patch under discussion here?  I can't find it in the
> > > archives.
> > 
> > This is the source code of VN8 target:
> > https://drive.google.com/file/d/0B169XTHeyQCfb2ZVak5VRm4tcHc/view?usp=sharing
> 
> Thanks.  I skimmed it over quickly to see if the documentation changes were in
> order, but I can't find any.  :-(  When you revise the port against current
> trunk and resubmit it for review, please remember to add documentation for all
> the target-specific command-line options and built-in functions in the
> appropriate sections of the GCC manual.

Specifically, follow the checklist in sourcebuild.texi for everything that 
needs to be documented for a new port.  And if it's too big for 
gcc-patches, split it into as many messages as necessary for it to be 
accepted by the list, don't provide it only as a link to an external site.

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

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
So, we have here:
(insn 42 41 43 2 (set (reg:V4SI 318)
(const_vector:V4SI [
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
])) pr69459.c:14 1220 {*movv4si_internal}
 (expr_list:REG_EQUIV (const_vector:V4SI [
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
])
(nil)))
...
(insn 245 242 246 4 (set (reg/v:V4SI 295 [ v16u32_1 ])
(vec_merge:V4SI (vec_duplicate:V4SI (const_int 4160055 [0x3f7a37]))
(reg:V4SI 318)
(const_int 1 [0x1]))) pr69459.c:23 2489 {vec_setv4si_0}
 (expr_list:REG_DEAD (reg:V4SI 318)
(expr_list:REG_EQUAL (const_vector:V4SI [
(const_int 4160055 [0x3f7a37])
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
])
(nil
and LRA changes this into:
...
(insn 245 481 246 4 (set (reg/v:V4SI 24 xmm3 [orig:295 v16u32_1 ] [295])
(vec_merge:V4SI (vec_duplicate:V4SI (mem/c:SI (plus:DI (reg/f:DI 7 sp)
(const_int -120 [0xff88])) [5 %sfp+-256 S4
A128]))
(const_vector:V4SI [
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
])
(const_int 1 [0x1]))) pr69459.c:23 2489 {vec_setv4si_0}
 (expr_list:REG_EQUAL (const_vector:V4SI [
(const_int 4160055 [0x3f7a37])
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
])
(nil)))
This is because the "C" constraint allows not just CONST0_RTX, but also
selected all ones vectors, including the V4SI all ones vector.
The vec_setv4si_0 insn uses the "C" constraints with "vector_move_operand"
predicate, the all ones vector fails the vector_move_operand predicate, but for
whatever reason LRA doesn't try to undo it and doesn't invalidate the cached
insn code, so we happily assembly it.  But instead of the desired { 0x3f7a37,
-1, -1, -1 } vector we get { 0x3f7a37, 0, 0, 0 }.

I'd say the i386 backend just should add a new constraint for CONST0_RTX only
and use it wherever the all ones is not allowed.  As "C" is documented,
probably the new "BC" constraint should be const0/CONST0_RTX only, and I think
at least the vector_move_operand, reg_or_0_operand and likely the
const_int_operand cases too should be changed to "BC".  At least that way the
RA and other spots will not try to satisfy it with something that can't match.

And then there is the question if and what should change on the LRA side.

i386.md:(match_operand:XI 1 "vector_move_operand"  "C ,vm,v"))]
i386.md:(match_operand:OI 1 "vector_move_operand"  "C ,vm,v"))]
i386.md:(match_operand:TI 1 "general_operand"  "riFo,re,C,vm,v"))]
i386.md:(match_operand:DI 1 "general_operand" "riFo,riF,Z,rem,i,re,C
,*y,m  ,*y,*Yn,r   ,C ,*v,m ,*v,v,*Yj,*v,r   ,*Yj ,*Yn ,*r ,*km,*k,*k"))]
i386.md:(match_operand:SI 1 "general_operand" "g ,re,C ,*y,*y ,rm ,C
,*v,m ,*v,*Yj,*v,r   ,*krm,*k"))]
i386.md:(match_operand:TF 1 "general_operand"  "C
,xm,x,*roF,*rC"))]
i386.md:(match_operand:XF 1 "general_operand" "fm,f,G,roF,r , *roF,*r,F
,C,roF,rF"))]
i386.md:(match_operand:DF 1 "general_operand" "Yf*fm,Yf*f,G   ,roF,r
,*roF,*r,F ,rm,rC,C ,F ,C,v,m,v,C ,*x,m ,*x,Yj,r ,roF,rF,rmF,rC"))]
i386.md:(match_operand:SF 1 "general_operand" "Yf*fm,Yf*f,G  
,rmF,rF,C,v,m,v,Yj,r  ,*y ,m  ,*y,*Yn,r   ,rmF,rF"))]
i386.md:  [(match_operand: 1 "vector_move_operand" "xmC")
mmx.md: (match_operand:MMXMODE 1 "vector_move_operand" "rCo,rC,C,rm,rC,C  ,!y,m
 ,?!y,?!Yn,r   ,C,v,m,v,C ,*x,m ,*x,Yj,r ,*Yj,!Yn"))]
mmx.md:   (match_operand:SF 2 "vector_move_operand"  "ym,C")))]
mmx.md:   (match_operand:SI 2 "vector_move_operand"  "ym,C")))]
sse.md: (match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand"  "C
,vm,v"))]
sse.md:   (match_operand:V48_AVX512VL 2 "vector_move_operand" "0C,0C")
sse.md:   (match_operand:VI12_AVX512VL 2 

[Bug target/65546] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
For GCC 6, this is just a testcase error.  The failing assertion requires this
clause now that we can vectorize the loop using misaligned loads/stores:

{ target { ! vect_hw_misalign } }

I'll get that fixed shortly, then see what's up on 4.9 and 5.

[Bug middle-end/69542] [6 Regression] -fcompare-debug failure in simplify-rtx.c on i?86 since r232905

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
2016-01-28  Jakub Jelinek  

PR middle-end/69542
* lra-remat.c (calculate_local_reg_remat_bb_data): Only consider
non-debug insns.

--- gcc/lra-remat.c.jj  2016-01-28 15:07:24.0 +0100
+++ gcc/lra-remat.c 2016-01-28 18:24:43.778297120 +0100
@@ -694,7 +694,7 @@ calculate_local_reg_remat_bb_data (void)

   FOR_EACH_BB_FN (bb, cfun)
 FOR_BB_INSNS (bb, insn)
-  if (INSN_P (insn))
+  if (NONDEBUG_INSN_P (insn))
set_bb_regs (bb, insn);
 }

fixes this, just waiting for testcase and will bootstrap/regtest it.

Re: [PATCH, gcc7, aarch64] Add arithmetic overflow patterns

[Richard Henderson]

On 01/28/2016 01:50 AM, Michael Collison wrote:
> Hi Richard,
> 
> Note that this patch appears to depend on your previous patch:
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-01/txtDPaXOBMuOB.txt
> 
> for the definition of define_mode_attr DWI. I was looking at this patch as I
> was working on Bugzilla 68543 which this will address.

Yes, it did.  I've now committed a slightly modified patch for pr69305, which
includes some name changes that were present in this patch.  There may be minor
patch conflicts but nothing major.



r~

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #4)

> I'd say the i386 backend just should add a new constraint for CONST0_RTX
> only and use it wherever the all ones is not allowed.  As "C" is documented,
> probably the new "BC" constraint should be const0/CONST0_RTX only, and I
> think at least the vector_move_operand, reg_or_0_operand and likely the
> const_int_operand cases too should be changed to "BC".  At least that way
> the RA and other spots will not try to satisfy it with something that can't
> match.

Yes, let's go this way.

> And then there is the question if and what should change on the LRA side.

IMO, to avoid issues like this, ICE with unrecognized insn should be triggered
when operand satisfies constraint, but not predicate.

[Bug target/69305] [5/6 Regression] wrong code with -O and int128 @ aarch64

[rth at gcc dot gnu.org]

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

--- Comment #13 from Richard Henderson  ---
Author: rth
Date: Thu Jan 28 17:48:22 2016
New Revision: 232936

URL: https://gcc.gnu.org/viewcvs?rev=232936=gcc=rev
Log:
PR target/69305

  * config/aarch64/aarch64-modes.def (CC_Cmode): New
  * config/aarch64/aarch64-protos.h: Update.
  * config/aarch64/aarch64.c (aarch64_zero_extend_const_eq): New.
  (aarch64_select_cc_mode): Add check for use of CC_Cmode.
  (aarch64_get_condition_code_1): Handle CC_Cmode.
  * config/aarch64/aarch64.md (addti3): Use adddi3_compareC.
  (*add3_compareC_cconly_imm): New.
  (*add3_compareC_cconly): New.
  (*add3_compareC_imm): New.
  (add3_compareC): New.
  (add3_carryin, *addsi3_carryin_uxtw): Sort compare operand
  to be first.  Use aarch64_carry_operation.
  (*add3_carryin_alt1, *addsi3_carryin_alt1_uxtw): Remove.
  (*add3_carryin_alt2, *addsi3_carryin_alt2_uxtw): Remove.
  (*add3_carryin_alt3, *addsi3_carryin_alt3_uxtw): Remove.
  (subti3): Use subdi3_compare1.
  (*sub3_compare0): Rename from sub3_compare0.
  (sub3_compare1): New.
  (*sub3_carryin0, *subsi3_carryin_uxtw): New.
  (*sub3_carryin): Use aarch64_borrow_operation.
  (*subsi3_carryin_uxtw): Likewise.
  (*ngc, *ngcsi_uxtw): Likewise.
  (*sub3_carryin_alt, *subsi3_carryin_alt_uxtw): New.
  * config/aarch64/iterators.md (DWI): New.
  * config/aarch64/predicates.md (aarch64_carry_operation): New.
  (aarch64_borrow_operation): New.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-modes.def
trunk/gcc/config/aarch64/aarch64-protos.h
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/config/aarch64/iterators.md
trunk/gcc/config/aarch64/predicates.md
trunk/gcc/testsuite/gcc.target/aarch64/ccmp_1.c
trunk/gcc/testsuite/gcc.target/aarch64/tst_3.c

Re: [PATCH, rs6000] Partial fix for PR65546 (GCC 6)

[Bill Schmidt]

Actually, please hold off on this.  The test in general is just faulty.
I'll get something more complete later on.

Sorry for the noise,
Bill

On Thu, 2016-01-28 at 11:45 -0600, Bill Schmidt wrote:
> Hi,
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65546 discusses the failure
> of gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c.  The test fails
> differently on GCC 4.9 and 5 than it does on GCC 6.  For GCC 6, the test
> case is faulty, as we only expect to see the "vectorization not
> profitable" statement when misaligned loads/stores are not efficient on
> the target hardware.  This patch fixes the test for GCC 6.
> 
> Something else is going on in the earlier releases, which I plan to look
> at separately.
> 
> Verified on powerpc64le-unknown-linux-gnu.  Is this okay for trunk?
> 
> Thanks,
> Bill
> 
> 
> 2016-01-28  Bill Schmidt  
> 
>   PR target/65546
>   * gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Disable check
>   for "vectorization not profitable" when the target supports
>   misaligned loads and stores.
> 
> 
> Index: gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
> ===
> --- gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c  
> (revision 232890)
> +++ gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c  
> (working copy)
> @@ -46,5 +46,5 @@ int main (void)
>return main1 ();
>  } 
> 
> -/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" 
> } } */
> +/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" 
> { target { ! vect_hw_misalign } } } } */
>  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" { target 
> { ! vect_hw_misalign } } } } */
> 
> 

[Bug rtl-optimization/69447] [5 Regression] wrong code with -O2 -fno-schedule-insns and mixed 8/16/32/64bit arithmetics @ armv7a

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #21 from Richard Henderson  ---
Fixed.

[Bug rtl-optimization/69447] [5 Regression] wrong code with -O2 -fno-schedule-insns and mixed 8/16/32/64bit arithmetics @ armv7a

[rth at gcc dot gnu.org]

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

--- Comment #20 from Richard Henderson  ---
Author: rth
Date: Thu Jan 28 18:11:27 2016
New Revision: 232938

URL: https://gcc.gnu.org/viewcvs?rev=232938=gcc=rev
Log:
PR rtl-opt/69447

  * lra-remat.c (subreg_regs): New.
  (dump_candidates_and_remat_bb_data): Dump it.
  (operand_to_remat): Reject if operand in subreg_regs.
  (set_bb_regs): Collect subreg_regs.
  (lra_remat): Init and free subreg_regs.  Compute
  calculate_local_reg_remat_bb_data before create_cands.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr69447.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/lra-remat.c

libstdc++ and c library compatible issue when bootstrap GCC

[Bin.Cheng]

Hi,
I ran into below error message at stage2 of bootstrap GCC:

/work/obj/gcc-bootstrap/./prev-gcc/xg++
-B/work/obj/gcc-bootstrap/./prev-gcc/ -B//aarch64-none-linux-gnu/bin/
-nostdinc++ 
-B/work/obj/gcc-bootstrap/prev-aarch64-none-linux-gnu/libstdc++-v3/src/.libs
-B/work/obj/gcc-bootstrap/prev-aarch64-none-linux-gnu/libstdc++-v3/libsupc++/.libs
 
-I/work/obj/gcc-bootstrap/prev-aarch64-none-linux-gnu/libstdc++-v3/include/aarch64-none-linux-gnu
 -I/work/obj/gcc-bootstrap/prev-aarch64-none-linux-gnu/libstdc++-v3/include
 -I/src/gcc/libstdc++-v3/libsupc++
-L/work/obj/gcc-bootstrap/prev-aarch64-none-linux-gnu/libstdc++-v3/src/.libs
-L/work/obj/gcc-bootstrap/prev-aarch64-none-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild
-I/src/gcc/gcc -I/src/gcc/gcc/build -I/src/gcc/gcc/../include
-I/src/gcc/gcc/../libcpp/include  \
-o build/genautomata.o /src/gcc/gcc/genautomata.c
In file included from /src/gcc/gcc/genautomata.c:116:0:
/work/obj/gcc-bootstrap/prev-aarch64-none-linux-gnu/libstdc++-v3/include/math.h:65:12:
error: ‘constexpr bool std::isinf(double)’ conflicts with a previous
declaration
 using std::isinf;
^

In file included from /usr/include/features.h:374:0,
 from /usr/include/stdio.h:27,
 from /src/gcc/gcc/system.h:46,
 from /src/gcc/gcc/genautomata.c:108:
/usr/include/aarch64-linux-gnu/bits/mathcalls.h:201:1: note: previous
declaration ‘int isinf(double)’
 __MATHDECL_1 (int,isinf,, (_Mdouble_ __value)) __attribute__ ((__const__));
 ^

I kind of understand what the problem is base on below facts:
1) I bootstrap gcc against new glibc;
2) I configure gcc with "--with-build-sysroot". According to GCC
document, this only affects how target libraries are built.
3) binary executables are built in GCC for internal use purpose. These
binaries are used to generate internal files during building gcc, and
I guess they are not considered as target library. So system C
libraries/headers are used.
4) at stage2 of gcc bootstrap, these binaries are compiled by stage1
xg++, which by default uses new libstdc+ just built in stage1.
5) Problem, the new libstdc++ is configured/built against new glibc
because of "--with-build-sysroot". It's incompatible with system C
headers.

It's a little tricky.  First question is:  is it reasonable to use
"--with-build-sysroot" alone when building/bootstrapping gcc?  If yes,
how should we build binaries in GCC?  Seems to me it's not reasonable
to use new libstdc++ along with system C library since it's built
against new glibc.

Any suggestion?  Thanks in advance.

Thanks,
bin

[Bug rtl-optimization/69530] [6 Regression] ICE: SIGSEGV in ix86_split_long_move (i386.c:24353) with -fno-split-wide-types -mavx

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #5)
> Created attachment 37509 [details]
> A patch
> 
> I am testing this.

Many post-reload splitters in i386.md check their operands with REG_P, based on
the premise that there are no subregs after registers are allocated.

I don't know what will break if this is not the case anymore.

Re: [PATCH] [graphite] make debug comment more explicit

[H.J. Lu]

On Thu, Jan 28, 2016 at 8:32 AM, Sebastian Pop  wrote:
> 2016-01-28  Abderrazek Zaafrani  
>
> * graphite-optimize-isl.c (optimize_isl): Print a different debug
> message when isl does not return a valid schedule.
> ---
>  gcc/graphite-optimize-isl.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/graphite-optimize-isl.c b/gcc/graphite-optimize-isl.c
> index d1620d5..6b3108d 100644
> --- a/gcc/graphite-optimize-isl.c
> +++ b/gcc/graphite-optimize-isl.c
> @@ -477,8 +477,15 @@ optimize_isl (scop_p scop)
>if (!schedule || isl_ctx_last_error (scop->isl_context) == isl_error_quota)
>  {
>if (dump_file && dump_flags)
> -   fprintf (dump_file, "isl timed out --param max-isl-operations=%d\n",
> -max_operations);
> +   {
> + if (!schedule)
> +   fprintf (dump_file, "isl did not return any schedule.\n",
> +max_operations);
> + else
> +   fprintf (dump_file, "isl timed out --param 
> max-isl-operations=%d\n",
> +max_operations);
> +   }
> +
>if (schedule)
> isl_schedule_free (schedule);
>return false;
> --
> 2.5.0
>

I checked in this to fix

/export/gnu/import/git/sources/gcc/gcc/graphite-optimize-isl.c:483:22:
error: too many arguments for format [-Werror=format-extra-args]
max_operations);
  ^
cc1plus: all warnings being treated as errors
Makefile:1085: recipe for target 'graphite-optimize-isl.o' failed
make[5]: *** [graphite-optimize-isl.o] Error 1
make[5]: *** Waiting for unfinished jobs


-- 
H.J.
--
Index: ChangeLog
===
--- ChangeLog (revision 232938)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2016-01-28  H.J. Lu  
+
+ * graphite-optimize-isl.c (optimize_isl): Fix dump.
+
 2016-01-28  Richard Henderson  

  PR target/69305
Index: graphite-optimize-isl.c
===
--- graphite-optimize-isl.c (revision 232938)
+++ graphite-optimize-isl.c (working copy)
@@ -479,8 +479,7 @@ optimize_isl (scop_p scop)
   if (dump_file && dump_flags)
  {
   if (!schedule)
-fprintf (dump_file, "isl did not return any schedule.\n",
- max_operations);
+fprintf (dump_file, "isl did not return any schedule.\n");
   else
 fprintf (dump_file, "isl timed out --param max-isl-operations=%d\n",
  max_operations);

Re: [PATCH] Fix use of declare'd vars by routine procedures.

[James Norris]

Jakub,

On 01/22/2016 04:39 AM, Jakub Jelinek wrote:


As for the extra error, I think it would be better to diagnose this during
gimplification, that way you do it for all FEs, plus you have the omp
context in there, etc.  The error wording is weird, the diagnostic
should make it clear use of what is invalid in what and why.

Jakub



I think the attached change is what you had in mind with
regard to doing the check at gimplification time.

OK?

Thanks for taking the time to review,
Jim


ChangeLog entries

gcc/
* gimplify.c (gimplify_var_or_parm_decl): Add variable usage check.
gcc/testsuite/
* c-c++-common/goacc/routine-5.c: Add tests.

Index: gcc/ChangeLog
===
diff --git a/trunk/gcc/ChangeLog b/trunk/gcc/ChangeLog
--- a/trunk/gcc/ChangeLog	(revision 232802)
+++ b/trunk/gcc/ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2016-01-XX  James Norris  
+
+	* gimplify.c (gimplify_var_or_parm_decl): Add usage check.
+
 2016-01-25  Jeff Law  
 
 	PR tree-optimization/69196
Index: gcc/gimplify.c
===
diff --git a/trunk/gcc/gimplify.c b/trunk/gcc/gimplify.c
--- a/trunk/gcc/gimplify.c	(revision 232802)
+++ b/trunk/gcc/gimplify.c	(working copy)
@@ -1841,6 +1841,33 @@
   return GS_ERROR;
 }
 
+  /* Validate variable for use within routine function.  */
+  if (gimplify_omp_ctxp && gimplify_omp_ctxp->region_type == ORT_TARGET
+  && get_oacc_fn_attrib (current_function_decl)
+  && TREE_CODE (decl) == VAR_DECL
+  && is_global_var (decl)
+  && ((TREE_STATIC (decl) && !DECL_EXTERNAL (decl))
+	  || (!TREE_STATIC (decl) && DECL_EXTERNAL (decl
+{
+  location_t loc = DECL_SOURCE_LOCATION (decl);
+
+  if (lookup_attribute ("omp declare target link", DECL_ATTRIBUTES (decl)))
+	{
+	  error_at (loc,
+		"%qE with % clause used in % function",
+		DECL_NAME (decl));
+	  return GS_ERROR;
+	}
+  else if (!lookup_attribute ("omp declare target", DECL_ATTRIBUTES (decl)))
+	{
+	  error_at (loc,
+		"storage class of %qE cannot be ", DECL_NAME (decl));
+	  error_at (gimplify_omp_ctxp->location,
+		"used in enclosing % function");
+	  return GS_ERROR;
+	}
+}
+
   /* When within an OMP context, notice uses of variables.  */
   if (gimplify_omp_ctxp && omp_notice_variable (gimplify_omp_ctxp, decl, true))
 return GS_ALL_DONE;
Index: gcc/testsuite/ChangeLog
===
diff --git a/trunk/gcc/testsuite/ChangeLog b/trunk/gcc/testsuite/ChangeLog
--- a/trunk/gcc/testsuite/ChangeLog	(revision 232802)
+++ b/trunk/gcc/testsuite/ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2016-01-XX  James Norris  
+
+	* c-c++-common/goacc/routine-5.c: Add tests.
+
 2016-01-25  Jeff Law  
 
 	PR tree-optimization/69196
Index: gcc/testsuite/c-c++-common/goacc/routine-5.c
===
diff --git a/trunk/gcc/testsuite/c-c++-common/goacc/routine-5.c b/trunk/gcc/testsuite/c-c++-common/goacc/routine-5.c
--- a/trunk/gcc/testsuite/c-c++-common/goacc/routine-5.c	(revision 232802)
+++ b/trunk/gcc/testsuite/c-c++-common/goacc/routine-5.c	(working copy)
@@ -45,3 +45,70 @@
 #pragma acc routine (a) /* { dg-error "does not refer to" } */
   
 #pragma acc routine (c) /* { dg-error "does not refer to" } */
+
+float vb1; /* { dg-error "storage class of" } */
+
+#pragma acc routine
+int
+func1 (int a)		/* { dg-error "used in enclosing" } */
+{
+  vb1 = a + 1;
+
+  return vb1;
+}
+
+#pragma acc routine
+int
+func2 (int a)		/* { dg-error "used in enclosing" } */
+{
+  static int vb2;	/* { dg-error "storage class of" } */
+
+  vb2 = a + 1;
+
+  return vb2;
+}
+
+float vb3;		/* { dg-error "'link' clause used" } */
+#pragma acc declare link (vb3)
+
+#pragma acc routine
+int
+func3 (int a)
+{
+  vb3 = a + 1;
+
+  return vb3;
+}
+
+float vb4;
+#pragma acc declare create (vb4)
+
+#pragma acc routine
+int
+func4 (int a)
+{
+  vb4 = a + 1;
+
+  return vb4;
+}
+
+extern float vb5;	/* { dg-error "storage class of" } */
+
+#pragma acc routine
+int
+func5 (int a)		/* { dg-error "used in enclosing" } */
+{
+  vb5 = a + 1;
+
+  return vb5;
+}
+
+#pragma acc routine
+int
+func6 (int a)		/* { dg-error "used in enclosing" } */
+{
+  extern float vb6;	/* { dg-error "storage class of" } */
+  vb6 = a + 1;
+
+  return vb6;
+}

[Bug target/69535] [6 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-reassoc due to use of uninitialised value

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-01-28
 CC||rth at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Henderson  ---
Confirmed.

Re: Compiling with -m64 using attribute interrupt emits IRET not IRETQ

[H.J. Lu]

On Thu, Jan 28, 2016 at 10:26 AM, H.J. Lu  wrote:
> On Thu, Jan 28, 2016 at 9:06 AM, Wink Saville  wrote:
>> I using hjl/interrupt/gcc-5-branch and my program is crashing when I
>> issue an INT xx. The problem appears to me to be that using
>> __attribute__ ((interrupt)) causes the a IRET to be emitted when an
>> IRETQ should be emitted. Below is my trivial do nothing main.c which I
>> compile with and then use objdump to view the assembler source.
>>
>> I compiled x86_64-unknown-elf- using crosstool-ng, could that be a 
>> problem?
>
> I fixed it on hjl/interrupt/gcc-5-branch branch.  I will fix it for
> hjl/interrupt/stage1 soon.
>
>

hjl/interrupt/stage1 branch is also fixed.

-- 
H.J.

[Bug tree-optimization/69355] [5 Regression] Wrong results with -O1 optimization

[jamborm at gcc dot gnu.org]

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

--- Comment #23 from Martin Jambor  ---
The testcase I posted to comment #19 fails also on the 4.9 branch so I
will test and commit the patch there too.

Jakub, can I close the bug afterwards or do you want to backport the
gcc/tree-dfa.c (the patch in comment#11) to gcc 5 as well?

[Bug target/68972] g++.dg/cpp1y/vla-initlist1.C test case fails on powerpc64le

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #4 from Martin Sebor  ---
Let me propose a fix for the test.

[Bug fortran/69524] [6 Regression] [F08] Compiler segfaults on "module procedure"

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
Summary|[6 Regression] Compiler |[6 Regression] [F08]
   |segfaults on invalid|Compiler segfaults on
   |testcase|"module procedure"

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #5)
> The only place where I find "module subroutine" is in codes related to
> submodules.

Ah, good point. Unfortunately I'm completely ignorant of all the submodule
stuff. So the test case may be valid after all (not sure about that) ...

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak  ---
Created attachment 37510
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37510=edit
Proposed patch

Patch in testing.

[Bug rtl-optimization/69535] [6 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-reassoc due to use of uninitialised value

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

  Component|target  |rtl-optimization

--- Comment #3 from Richard Henderson  ---
Combine turns

(insn 35 33 36 2 (parallel [
(set (reg:SI 123 [ u32_2 ])
(lshiftrt:SI (reg/v:SI 108 [ u32_2 ])
(reg/v:QI 94 [ u8_3 ])))
(clobber (reg:CC 17 flags))
]) z.c:21 562 {*lshrsi3_1}
 (expr_list:REG_DEAD (reg/v:SI 108 [ u32_2 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 36 35 59 2 (set (reg:DI 125 [ u32_2 ])
(zero_extend:DI (reg:SI 123 [ u32_2 ]))) z.c:22 131 {*zero_extendsidi2}
 (expr_list:REG_DEAD (reg:SI 123 [ u32_2 ])
(nil)))
...
(insn 37 59 38 2 (set (subreg:DI (reg:TI 124 [ u32_2 ]) 0)
(reg:DI 125 [ u32_2 ])) z.c:22 85 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 125 [ u32_2 ])
(nil)))

into

(note 35 33 36 2 NOTE_INSN_DELETED)
(note 36 35 59 2 NOTE_INSN_DELETED)
(insn 37 59 38 2 (set (subreg:DI (reg:TI 124 [ u32_2 ]) 0)
(subreg:DI (reg/v:SI 108 [ u32_2 ]) 0)) z.c:22 85 {*movdi_internal}
 (expr_list:REG_DEAD (reg/v:SI 108 [ u32_2 ])
(nil)))

I'm not sure how it decided to drop the lshiftrt, but the change
from (zero_extend:DI (reg:SI X)) to (subreg:DI (reg:SI X)) is
completely invalid.  The final rtl explicitly says that the high
32 bits of the DImode value are unused, which from the PR is
obviously wrong.

[Bug tree-optimization/69355] [5 Regression] Wrong results with -O1 optimization

[jakub at gcc dot gnu.org]

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

--- Comment #24 from Jakub Jelinek  ---
(In reply to Martin Jambor from comment #23)
> The testcase I posted to comment #19 fails also on the 4.9 branch so I
> will test and commit the patch there too.
> 
> Jakub, can I close the bug afterwards or do you want to backport the
> gcc/tree-dfa.c (the patch in comment#11) to gcc 5 as well?

If the bug is fixed in gcc 5 and/or 4.9 through your patch, the tree-dfa.c
change is not needed there, let's keep tree-dfa.c as is there.

[Bug fortran/69524] [6 Regression] Compiler segfaults on simple testcase

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-28
  Known to work||5.2.1
Summary|[ICE] [F95] Compiler|[6 Regression] Compiler
   |segfaults on simple |segfaults on simple
   |testcase @ -O0  |testcase
 Ever confirmed|0   |1
  Known to fail||6.0

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #1)
> With gfortran 5.2.1, I do not get an ICE

However, I can indeed reproduce the ICE with trunk. Thus, it's a regression.

Re: Compiling with -m64 using attribute interrupt emits IRET not IRETQ

[H.J. Lu]

On Thu, Jan 28, 2016 at 11:06 AM, Wink Saville  wrote:
> Thanks. How are you testing?
>
>

* { dg-do compile } */
/* { dg-options "-O2 -Wall -g" } */

void
__attribute__((interrupt))
fn (void *frame)
{
}

/* { dg-final { scan-assembler-not "add(l|q)\[\\t \]*\\$\[0-9\]*,\[\\t
\]*%\[re\]?sp" } } */
/* { dg-final { scan-assembler "iret" { target ia32 } } } */
/* { dg-final { scan-assembler "iretq" { target { ! ia32 } } } } */
^^^

The testcase scans for iretq if target isn't 32-bit.

-- 
H.J.

[Bug fortran/69524] [6 Regression] Compiler segfaults on invalid testcase

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[6 Regression] Compiler |[6 Regression] Compiler
   |segfaults on simple |segfaults on invalid
   |testcase|testcase

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #1)
> With gfortran 5.2.1, I do not get an ICE, but several errors, starting with:
> 
>   module subroutine A1(i)
>  1
> Error: Unclassifiable statement at (1)

I guess the main question is why this error is not being triggered on trunk.

[Bug pch/68176] [4.9/5/6 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)

[nix at esperi dot org.uk]

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

--- Comment #10 from Nix  ---
Argh, scratch that -- I need to test a tree that *doesn't* have the original
patch reverted! Doing that now, will report back once that's done.

[Bug fortran/69484] [5 Regression] documentation issue: -Wtabs and -Wall

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from janus at gcc dot gnu.org ---
Fixed on trunk and the gcc-5 branch. Closing.

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Uroš Bizjak from comment #5)
> > (In reply to Jakub Jelinek from comment #4)
> > 
> > > I'd say the i386 backend just should add a new constraint for CONST0_RTX
> > > only and use it wherever the all ones is not allowed.  As "C" is 
> > > documented,
> > > probably the new "BC" constraint should be const0/CONST0_RTX only, and I
> > > think at least the vector_move_operand, reg_or_0_operand and likely the
> > > const_int_operand cases too should be changed to "BC".  At least that way
> > > the RA and other spots will not try to satisfy it with something that 
> > > can't
> > > match.
> > 
> > Yes, let's go this way.
> 
> Ok, will work on it tomorrow.

Heh, it looks we can change "C" constraint to mean only zero. Please consider
following testcase:

--cut here--
typedef int __v4si __attribute__ ((__vector_size__ (16)));

void test (void)
{
  asm volatile ("%0" : : "C" ( (__v4si) { -1, -1, -1, -1 } ));
}
--cut here--

This is the only way "C" constraint can be satisfied by non-zero operand.
Trying to compile this, we get:

c.c: In function ‘test’:
c.c:6:1: internal compiler error: in ix86_print_operand, at
config/i386/i386.c:17289

17284 /* We have patterns that allow zero sets of memory, for instance.
17285In 64-bit mode, we should probably support all 8-byte vectors,
17286since we can in fact encode that into an immediate.  */
17287 if (GET_CODE (x) == CONST_VECTOR)
17288   {
17289 gcc_assert (x == CONST0_RTX (GET_MODE (x)));
17290 x = const0_rtx;
17291   }

Based on this evidence, there is no way "C" constraint ca be used with non-zero
immediate. So, let's change "C" constraint to:

;; This can theoretically be any mode's CONST0_RTX.
(define_constraint "C"
  "Constant zero."
  (match_test "op == const0_rtx || op == CONST0_RTX (GET_MODE (op))"))

and add new BC constraint

(define_constraint "BC"
  "@internal SSE constant operand."
  (match_test "standard_sse_constant_p (op)"))

that is used only in SSE move pattern:

(define_insn "*mov_internal"
  [(set (match_operand:VMOVE 0 "nonimmediate_operand"   "=v,v ,m")
(match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand" 
"BC,vm,v"))]
  "TARGET_SSE
   && (register_operand (operands[0], mode)
   || register_operand (operands[1], mode))"

Re: [PATCH] libcpp: use better locations for _Pragma tokens (preprocessor/69126)

[Steve Ellcey]

David,

This patch has broken the top-of-tree glibc build.  I get an error on an
undef that is supposed to be protected by Pragmas.  It happens when
compiling intl/plural.c in glibc.  I created a preprocessed source file
but when I compile it, the error doesn't happen.  I will try to create a
small unpreprocessed standalone test case but maybe this is enough for
you to know what is happening.

If I look at the preprocessed code, the statement in question is
under ingore warning pragmas.

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wuninitialized"
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
  *++yyvsp = __gettextlval;
#pragma GCC diagnostic pop


Steve Ellcey
sell...@imgtec.com

plural.c: In function '__gettextparse':
plural.c:1767:12: error: '__gettextlval.num' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
   *++yyvsp = yylval;
 
plural.c:66:25: note: '__gettextlval.num' was declared here
 #define yylval  __gettextlval
 ^
plural.c:1265:9: note: in expansion of macro 'yylval'
 YYSTYPE yylval YY_INITIAL_VALUE(yyval_default);
 ^~
cc1: all warnings being treated as errors

[Bug fortran/69524] [6 Regression] Compiler segfaults on simple testcase

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
Here is a slightly reduced test case:

module A
  interface
module subroutine A1
end
  end interface
contains
  subroutine A1
  end
end

It's still invalid, but gives less errors with gfortran-5.

[Bug fortran/69524] [6 Regression] Compiler segfaults on invalid testcase

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #5 from Dominique d'Humieres  ---
> > With gfortran 5.2.1, I do not get an ICE, but several errors, starting with:
> > 
> >   module subroutine A1(i)
> >  1
> > Error: Unclassifiable statement at (1)
>
> I guess the main question is why this error is not being triggered on trunk.

The only place where I find "module subroutine" is in codes related to
submodules.

Re: [C/C++ PATCH] Don't emit invalid VEC_COND_EXPR for vector comparisons (PR c/68062)

[Marek Polacek]

On Thu, Jan 28, 2016 at 04:47:04AM -0800, H.J. Lu wrote:
> I got
> 
> FAIL: c-c++-common/vector-compare-4.c  -Wc++-compat   (test for
> warnings, line 17)
> FAIL: c-c++-common/vector-compare-4.c  -Wc++-compat   (test for
> warnings, line 18)
> FAIL: c-c++-common/vector-compare-4.c  -Wc++-compat   (test for
> warnings, line 34)
> FAIL: c-c++-common/vector-compare-4.c  -Wc++-compat   (test for
> warnings, line 35)

Ah, patch(1) bogosity, fixed now.  Sorry about that.

Marek

Re: Is it OK for rtx_addr_can_trap_p_1 to attempt to compute the frame layout? (was Re: [PATCH] Skip re-computing the mips frame info after reload completed)

[Richard Sandiford]

Bernd Edlinger  writes:
> On 26.01.2016 22:18, Richard Sandiford wrote:
>> [cc-ing Eric as RTL maintainer]
>>
>> Matthew Fortune  writes:
>>> Bernd Edlinger  writes:
 Matthew Fortune  writes:
> Has the patch been tested beyond just building GCC? I can do a
> test run for you if you don't have things set up to do one yourself.

 I built a cross-gcc with all languages and a cross-glibc, but I have
 not set up an emulation environment, so if you could give it a test
 that would be highly welcome.
>>>
>>> mipsel-linux-gnu test results are the same before and after this patch.
>>>
>>> Please go ahead and commit.
>>
>> I still object to this.  And it feels like the patch was posted
>> as though it was a new one in order to avoid answering the objections
>> that were raised when it was last posted:
>>
>>https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02218.html
>>
>
> Richard, I am really sorry when you feel now like I did not take your
> objections seriously.  Let me first explain what happened from my point
> of view:
>
> When I posted this response to your objections here:
>
>   https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00235.html
>
> I was waiting for your response, but nothing happened, so I kind of
> forgot about the issue.  In the meantime Ubuntu and Debian began to
> roll out GCC-6 and they got stuck at the same issue, but instead of
> waiting for pr69012 to be eventually resolved they created a duplicate
> pr69129, and then last Thursday Nick applied my initial patch without
> my intervention, probably because of the pressure they put on us.

Ah, I'd missed that, sorry.  It's not obvious from the email thread
that the patch was actually approved.  I just see a message from Matthias
saying that it worked for him and then a message from Nick saying that
he'd applied it.

Ah well.  I guess at some point I have to get over the fact that I'm no
longer the MIPS maintainer :-)

> That changed significantly how I looked at the issue after that point,
> as there was no actual regression anymore, the revised patch still made
> sense, but for another reason.  When you look at the 20+ targets in the
> gcc tree you'll see that almost all of them have a frame-layout
> computation function and all except mips have a shortcut
> "if (reload_completed) return;" in that function.  And OTOH mips has
> one of the most complicated frame layout functions of all targets.
>
> For all of these reasons I posted a new patch which tries to resolve
> differences between mips and other targets inital_elimination_offset
> functions.

OK.  But the point still stands that the patch is only useful because
we're now calling mips_compute_frame_info in cases where we wouldn't
previously, because of the rtx_addr_can_trap_p changes.

> I still think that it is not OK for the mips target to do the frame
> layout already in mips_frame_pointer_required because the frame layout
> will change several times, until reload is completed, and that function
> is only called right in the beginning.

I don't think it's any better or worse than doing the frame layout in
INITIAL_ELIMINATION_OFFSET (which is common practice and pretty much
required).  They're both part of the initial setup phase --
targetm.frame_layout_required determines frame_pointer_needed, which is
a vital input to the code that decides which eliminations to make.

And this is an example of us doing the kind of caching that I was
suggesting.  Code that wants to know whether the frame pointer is needed
for the current function should use frame_pointer_needed.  Only the code
that sets up frame_pointer_needed should call frame_pointer_required
directly. 

> And I think that it is not really well-designed to have a frame layout
> function F(x,y)->z unless you assume F to be a trivial O(1) function
> that has no significant computation overhead.  When you assume F to be
> an expensive O(N) or higher complexity you would design the interface
> like compute_frame_layout_now() and
> get_cached_initial_elimination_offset(x,y)->z.
>
> Also note, that with the current design, of initial_elimination_offset
> the frame layout is already computed several times, because reload has
> to call the function with different parameters, and there is no way how
> to know when the cached value can be used and when not.

Agreed -- the current interface is pretty poor.  But that's even more
reason not to add uses of it after LRA/reload.  Caching would be both
simpler and more efficient.

> I do also think that having to cache the initial elimination offset
> values in the back-end that are already cached in the target does not
> improve anything.  Then I would prefer to have a set of new target
> callbacks that makes it easy to access the cached target values.

I don't agree.  Asking each backend to cache a particular value in
its frame_info structure and then providing a 

Re: [PATCH] Fix PCH on systems where stdc-predef.h includes other headers (PR pch/68176)

[Marek Polacek]

On Thu, Jan 28, 2016 at 03:32:39PM +0100, Jakub Jelinek wrote:
> Hi!
> 
> As mentioned in the PR, most of the pch tests fail if stdc-predef.h header
> includes other headers.  I don't have such a system, but changed my
> stdc-predef.h to include a dummy header bits/predef.h and this patch fixes
> all the tests that failed because of that.
> AFAIK file->implicit_preinclude flag is used solely for the PCH purposes,
> and this patch makes sure that headers included from implicit_preinclude
> headers are also implicit_preinclude.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2016-01-28  Jakub Jelinek  
> 
>   PR pch/68176
>   * files.c (_cpp_find_file): Set file->implicit_preinclude even if
>   included from file->implicit_preinclude header.

Ok.

Marek

[Bug rtl-optimization/69530] [6 Regression] ICE: SIGSEGV in ix86_split_long_move (i386.c:24353) with -fno-split-wide-types -mavx

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #8)
> Is the r229087 change still needed after r229458?

Backout r229087 doesn't cause gcc.target/i386/pr67609-2.c nor 
gcc.target/i386/pr67609.c to fail.

[Bug target/68400] ICE in change_address_1, at emit-rtl.c:2125

[sje at gcc dot gnu.org]

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

--- Comment #5 from Steve Ellcey  ---
Author: sje
Date: Thu Jan 28 22:25:55 2016
New Revision: 232952

URL: https://gcc.gnu.org/viewcvs?rev=232952=gcc=rev
Log:
2016-01-28  Steve Ellcey  

PR target/68400
* config/mips/mips.c (and_operands_ok): Add MIPS16 check.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/mips.c

[Bug preprocessor/69543] [6 Regression] _Pragma does not apply within macro

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Breakpoint 4, linemap_compare_locations (set=0x77ff6000, pre=2147483641,
post=post@entry=2147483656) at ../../src/libcpp/line-map.c:1326

(gdb) call inform (2147483641, "pre=2147483641")
../../src/gcc/testsuite/c-c++-common/pr69453.c: In function ‘test’:
../../src/gcc/testsuite/c-c++-common/pr69453.c:6:5: note: pre=2147483641
 _Pragma ("GCC diagnostic ignored \"-Wmaybe-uninitialized\"")
 ^
../../src/gcc/testsuite/c-c++-common/pr69453.c:13:3: note: in expansion of
macro ‘YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN’
   YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
   ^
(gdb) p /x 2147483641
$15 = 0x7ff9

(gdb) call inform (2147483656, "post=2147483656")
../../src/gcc/testsuite/c-c++-common/pr69453.c:14:12: note: post=2147483656
   *++yyvsp = yylval;
   ~^~~~
(gdb) p /x 2147483656
$8 = 0x8008

(gdb) p l0
$16 = 2147483641
(gdb) p l1
$17 = 312096
(gdb) p /x l0
$18 = 0x7ff9

Then, after the call to:
1338  if ((pre_virtual_p = linemap_location_from_macro_expansion_p (set,
l0)))
1339l0 = linemap_resolve_location (set, l0,
1340   LRK_MACRO_EXPANSION_POINT,
1341   NULL);
1342
we have:
(gdb) p /x l0
$21 = 0x8004

so we have a comparison of locations, one (l0) from a macro expansion, the
other not (l1).

linemap_compare_locations concludes by executing this:
1368  return l1 - l0;
giving this rather nonsensical result:
Value returned is $25 = -2147171556

If I'm reading this right, it thus regards the "ignored" as happening *after*
the source line of interest, hence the latter erroneously isn't affected by the
_Pragma.

[Bug fortran/69544] [5/6 Regression] Internal compiler error with -Wall and where

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-28
 CC||manu at gcc dot gnu.org
Summary|Internal compiler error |[5/6 Regression] Internal
   |with -Wall and where|compiler error with -Wall
   ||and where
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed as a regression between revisions r217961 (2014-11-22, warning) and
r218255 (2014-12-02, ICE). The warning was



Warning: CHARACTER expression will be truncated in assignment (8/12) at (1)

[Bug bootstrap/69506] [6 Regression] check-in 232454 seems to cause problems with cygwin builds

[rogero at howzatt dot demon.co.uk]

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

--- Comment #3 from Roger Orr  ---
Tested: bootstrap build on cygwin with your patch completed successfully.

I used:
../gcctrunk/configure --enable-languages=c,c++ --prefix=/usr/share/gcc-trunk
make -j5
make install

Thank you :-)

[Bug middle-end/69545] [6 Regression] FAIL: gfortran.dg/graphite/pr42285.f90 -O (internal compiler error)

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |spop at gcc dot gnu.org

--- Comment #1 from Sebastian Pop  ---
I guess this issue is due to isl-0.14.  With isl-0.15 it is passing.
I will have a look.

Re: [google gcc-4_9]: Backport trunk:r232727 fix for PR/69403.

[Carrot Wei]

LGTM

thanks
Carrot

On Thu, Jan 28, 2016 at 11:53 AM, Han Shen  wrote:
> Backport trunk:r232727 fix for PR/69403 - wrong
> thumb2_ior_scc_strict_it insn pattern.
>
> Note this only affect armv7-a tuned for armv8 arch, tested / booted
> affected ChromeOS book.
>
> Ok for google/gcc-4_9 branch?
>
> --
> Han Shen

[PATCH, rs6000] Partial fix for PR65546 (GCC 6)

[Bill Schmidt]

Hi,

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65546 discusses the failure
of gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c.  The test fails
differently on GCC 4.9 and 5 than it does on GCC 6.  For GCC 6, the test
case is faulty, as we only expect to see the "vectorization not
profitable" statement when misaligned loads/stores are not efficient on
the target hardware.  This patch fixes the test for GCC 6.

Something else is going on in the earlier releases, which I plan to look
at separately.

Verified on powerpc64le-unknown-linux-gnu.  Is this okay for trunk?

Thanks,
Bill


2016-01-28  Bill Schmidt  

PR target/65546
* gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Disable check
for "vectorization not profitable" when the target supports
misaligned loads and stores.


Index: gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
===
--- gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
(revision 232890)
+++ gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
(working copy)
@@ -46,5 +46,5 @@ int main (void)
   return main1 ();
 } 
 
-/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" } 
} */
+/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" { 
target { ! vect_hw_misalign } } } } */
 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" { target { 
! vect_hw_misalign } } } } */

Re: [PATCH, aarch64] Fix pr69305 -- addti miscompilation

[Richard Henderson]

Here's the patch as committed.

It includes a few name changes from the addv patch I posted,
which correspond nicely with a name clarification that James
requested during feedback.


r~
PR target/69305
* config/aarch64/aarch64-modes.def (CC_Cmode): New
* config/aarch64/aarch64-protos.h: Update.
* config/aarch64/aarch64.c (aarch64_zero_extend_const_eq): New.
(aarch64_select_cc_mode): Add check for use of CC_Cmode.
(aarch64_get_condition_code_1): Handle CC_Cmode.
* config/aarch64/aarch64.md (addti3): Use adddi3_compareC.
(*add3_compareC_cconly_imm): New.
(*add3_compareC_cconly): New.
(*add3_compareC_imm): New.
(add3_compareC): New.
(add3_carryin, *addsi3_carryin_uxtw): Sort compare operand
to be first.  Use aarch64_carry_operation.
(*add3_carryin_alt1, *addsi3_carryin_alt1_uxtw): Remove.
(*add3_carryin_alt2, *addsi3_carryin_alt2_uxtw): Remove.
(*add3_carryin_alt3, *addsi3_carryin_alt3_uxtw): Remove.
(subti3): Use subdi3_compare1.
(*sub3_compare0): Rename from sub3_compare0.
(sub3_compare1): New.
(*sub3_carryin0, *subsi3_carryin_uxtw): New.
(*sub3_carryin): Use aarch64_borrow_operation.
(*subsi3_carryin_uxtw): Likewise.
(*ngc, *ngcsi_uxtw): Likewise.
(*sub3_carryin_alt, *subsi3_carryin_alt_uxtw): New.
* config/aarch64/iterators.md (DWI): New.
* config/aarch64/predicates.md (aarch64_carry_operation): New.
(aarch64_borrow_operation): New.


diff --git a/gcc/config/aarch64/aarch64-modes.def 
b/gcc/config/aarch64/aarch64-modes.def
index 3fab205..7de0b3f 100644
--- a/gcc/config/aarch64/aarch64-modes.def
+++ b/gcc/config/aarch64/aarch64-modes.def
@@ -25,6 +25,7 @@ CC_MODE (CC_ZESWP); /* zero-extend LHS (but swap to make it 
RHS).  */
 CC_MODE (CC_SESWP); /* sign-extend LHS (but swap to make it RHS).  */
 CC_MODE (CC_NZ);/* Only N and Z bits of condition flags are valid.  */
 CC_MODE (CC_Z); /* Only Z bit of condition flags is valid.  */
+CC_MODE (CC_C); /* Only C bit of condition flags is valid.  */
 
 /* Half-precision floating point for __fp16.  */
 FLOAT_MODE (HF, 2, 0);
diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index bd900c6..78870e2 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -290,6 +290,7 @@ void aarch64_declare_function_name (FILE *, const char*, 
tree);
 bool aarch64_legitimate_pic_operand_p (rtx);
 bool aarch64_modes_tieable_p (machine_mode mode1,
  machine_mode mode2);
+bool aarch64_zero_extend_const_eq (machine_mode, rtx, machine_mode, rtx);
 bool aarch64_move_imm (HOST_WIDE_INT, machine_mode);
 bool aarch64_mov_operand_p (rtx, machine_mode);
 int aarch64_simd_attr_length_rglist (enum machine_mode);
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index bba7a9b..aee6685 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1493,6 +1493,16 @@ aarch64_split_simd_move (rtx dst, rtx src)
 }
 }
 
+bool
+aarch64_zero_extend_const_eq (machine_mode xmode, rtx x,
+ machine_mode ymode, rtx y)
+{
+  rtx r = simplify_const_unary_operation (ZERO_EXTEND, xmode, y, ymode);
+  gcc_assert (r != NULL);
+  return rtx_equal_p (x, r);
+}
+ 
+
 static rtx
 aarch64_force_temporary (machine_mode mode, rtx x, rtx value)
 {
@@ -4189,6 +4199,13 @@ aarch64_select_cc_mode (RTX_CODE code, rtx x, rtx y)
 return ((code == GT || code == GE || code == LE || code == LT)
? CC_SESWPmode : CC_ZESWPmode);
 
+  /* A test for unsigned overflow.  */
+  if ((GET_MODE (x) == DImode || GET_MODE (x) == TImode)
+  && code == NE
+  && GET_CODE (x) == PLUS
+  && GET_CODE (y) == ZERO_EXTEND)
+return CC_Cmode;
+
   /* For everything else, return CCmode.  */
   return CCmode;
 }
@@ -4288,6 +4305,15 @@ aarch64_get_condition_code_1 (enum machine_mode mode, 
enum rtx_code comp_code)
}
   break;
 
+case CC_Cmode:
+  switch (comp_code)
+   {
+   case NE: return AARCH64_CS;
+   case EQ: return AARCH64_CC;
+   default: return -1;
+   }
+  break;
+
 default:
   return -1;
   break;
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 5d35261..b42f550 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -1710,7 +1710,7 @@
   ""
 {
   rtx low = gen_reg_rtx (DImode);
-  emit_insn (gen_adddi3_compare0 (low, gen_lowpart (DImode, operands[1]),
+  emit_insn (gen_adddi3_compareC (low, gen_lowpart (DImode, operands[1]),
  gen_lowpart (DImode, operands[2])));
 
   rtx high = gen_reg_rtx (DImode);
@@ -1755,6 +1755,71 @@
   [(set_attr "type" "alus_sreg,alus_imm,alus_imm")]
 )
 
+(define_insn "*add3_compareC_cconly_imm"
+  [(set (reg:CC_C 

[Bug tree-optimization/69355] [5 Regression] Wrong results with -O1 optimization

[jamborm at gcc dot gnu.org]

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

--- Comment #22 from Martin Jambor  ---
Author: jamborm
Date: Thu Jan 28 18:04:00 2016
New Revision: 232937

URL: https://gcc.gnu.org/viewcvs?rev=232937=gcc=rev
Log:
[PR 69355] Correct hole detection when total_scalarization fails

2016-01-28  Martin Jambor  

PR tree-optimization/69355
* tree-sra.c (analyze_access_subtree): Correct hole detection when
total_scalarization fails.

testsuite/
* gcc.dg/tree-ssa/pr69355.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/tree-ssa/pr69355.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/tree-sra.c

Re: RFC: Support non-standard extension (call via casted function pointer)

[Andreas Schwab]

Why does the dummy declaration need to use a pointer type?

Andreas.

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

[Bug pch/68176] [4.9/5/6 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)

[nix at esperi dot org.uk]

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

--- Comment #11 from Nix  ---
Confirmed fixed (properly this time).

[Bug target/68400] ICE in change_address_1, at emit-rtl.c:2125

[sje at gcc dot gnu.org]

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

--- Comment #6 from Steve Ellcey  ---
Author: sje
Date: Thu Jan 28 22:28:04 2016
New Revision: 232954

URL: https://gcc.gnu.org/viewcvs?rev=232954=gcc=rev
Log:
PR target/68400
* gcc.target/mips/mips.exp (mips_option_groups): Add stack-protector.
* gcc.target/mips/pr68400.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/mips/pr68400.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/mips/mips.exp

Re: C++ PATCH for c++/69496 (ICE on VLA in constexpr function)

[Marek Polacek]

On Wed, Jan 27, 2016 at 09:52:13AM -0700, Martin Sebor wrote:
> This happens to work but I suspect it's only by accident.  When
> the number of elements in the initializer is increased to exceed
> the number of elements in the VLA GCC gets into infinite recursion.
> (I opened bug 69516 with a test case).  The same error in a non-
> constexpr function causes a SEGV at runtime (this is also
> a regression WRT 4.9.3 -- I opened bug 69517 for it).

FWIW, the patch I posted today should cure all those infinite recursions.

Marek

[Bug pch/68176] [4.9/5/6 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jan 28 22:35:20 2016
New Revision: 232956

URL: https://gcc.gnu.org/viewcvs?rev=232956=gcc=rev
Log:
PR pch/68176
* files.c (_cpp_find_file): Set file->implicit_preinclude even if
included from file->implicit_preinclude header.

Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/files.c

[Bug pch/68176] [4.9/5 Regression] all pch tests fail on eglibc systems (with bits/predefs.h)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression] all|[4.9/5 Regression] all pch
   |pch tests fail on eglibc|tests fail on eglibc
   |systems (with   |systems (with
   |bits/predefs.h) |bits/predefs.h)

--- Comment #13 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[gang.chen.5i5j at gmail dot com]

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

--- Comment #22 from Chen Gang  ---
(In reply to Mark Wielaard from comment #21)

[...]

> Although in C a static const is not really like a #define I suspect that
> there are cases where they are used as such in header files. If that is the
> major reason for why there are people opposed to the warning then what we
> could do is hide such (non-)usage of static const variables from header
> files behind -Wextra and only explicitly warn for static const variable
> defined (and then not used) in the main file.
> 

For me, what you said above sounds reasonable. :-)

[PATCH, rs6000] Fix PR65546

[Bill Schmidt]

Hi,

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65546 identifies a failure
in gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c.  The test case hasn't
kept up with changes in the vectorizer, so it's looking for the wrong
error message.  Also, the error message should be conditioned by a check
for support of unaligned memory accesses.  This patch corrects these
problems.

For 4.9 and 5, the error message needs to be similarly changed.
However, for these earlier releases, the check for misalignment support
doesn't apply.

Verified on powerpc64le-unknown-linux-gnu for both -mcpu=power7 and
-mcpu=power8, which differ in their support for misalignment.  Is this
ok for trunk?  Provided verification succeeds on 4.9 and 5, is the
revised test ok for those releases?

Thanks,
Bill


2016-01-28  Bill Schmidt  

PR target/65546
* gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Correct
condition being checked, and disable it when the target supports
misaligned loads and stores.


Index: gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
===
--- gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
(revision 232890)
+++ gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
(working copy)
@@ -46,5 +46,5 @@ int main (void)
   return main1 ();
 } 
 
-/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" } 
} */
+/* { dg-final { scan-tree-dump-times "not vectorized: unsupported unaligned 
store" 1 "vect" { target { ! vect_hw_misalign } } } } */
 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" { target { 
! vect_hw_misalign } } } } */

[PATCH, i386]: Fix PR69549, wrong code with -O2 and vector arithmetics @ x86_64

[Uros Bizjak]

Hello!

Attached patch corrects "C" constraint to accept only SSE constant
zero operand and introduces new "BC" constraint to accept all SSE
constant operands (all bits 0 and all bits 1).

As discussed in the PR, the compiler ICEs when "C" constraint is used
non-zero vector operands, so it is still possible to change the
constraint a bit. With fixed constraint, we get "impossible
constraint" error instead of ICEing when following testcase:

--cut here--
typedef int __v4si __attribute__ ((__vector_size__ (16)));

void test (void)
{
  asm volatile ("%0" : : "C" ( (__v4si) { -1, -1, -1, -1 } ));
}
--cut here--

is compiled with -O2 -msse2.

2016-01-28  Uros Bizjak  

PR target/69459
* config/i386/constraints.md (C): Only accept constant zero operand.
(BC): New constraint.
* config/i386/sse.md (*mov_internal): Use BC constraint
instead of C constraint.
* doc/md.texi (Machine Constraints): Update description
of C constraint.

testsuite/ChangeLog:

2016-01-28  Uros Bizjak  

PR target/69459
* gcc.target/i386/pr69459.c: New test.

Patch was bootstrapped and regression tested on x86_64-linux-gnu
{,-m32}. Patch was committed to mainline SVN and will be backported to
release branches.

Uros.
Index: config/i386/constraints.md
===
--- config/i386/constraints.md  (revision 232929)
+++ config/i386/constraints.md  (working copy)
@@ -152,6 +152,7 @@
 ;;  s  Sibcall memory operand, not valid for TARGET_X32
 ;;  w  Call memory operand, not valid for TARGET_X32
 ;;  z  Constant call address operand.
+;;  C  SSE constant operand.
 
 (define_constraint "Bf"
   "@internal Flags register operand."
@@ -183,6 +184,10 @@
   "@internal Constant call address operand."
   (match_operand 0 "constant_call_address_operand"))
 
+(define_constraint "BC"
+  "@internal SSE constant operand."
+  (match_test "standard_sse_constant_p (op)"))
+
 ;; Integer constant constraints.
 (define_constraint "I"
   "Integer constant in the range 0 @dots{} 31, for 32-bit shifts."
@@ -233,8 +238,8 @@
 
 ;; This can theoretically be any mode's CONST0_RTX.
 (define_constraint "C"
-  "Standard SSE floating point constant."
-  (match_test "standard_sse_constant_p (op)"))
+  "SSE constant zero operand."
+  (match_test "standard_sse_constant_p (op) == 1"))
 
 ;; Constant-or-symbol-reference constraints.
 
Index: config/i386/sse.md
===
--- config/i386/sse.md  (revision 232929)
+++ config/i386/sse.md  (working copy)
@@ -833,7 +833,7 @@
 
 (define_insn "*mov_internal"
   [(set (match_operand:VMOVE 0 "nonimmediate_operand"   "=v,v ,m")
-   (match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand"  "C ,vm,v"))]
+   (match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand"  "BC,vm,v"))]
   "TARGET_SSE
&& (register_operand (operands[0], mode)
|| register_operand (operands[1], mode))"
Index: doc/md.texi
===
--- doc/md.texi (revision 232929)
+++ doc/md.texi (working copy)
@@ -4100,7 +4100,7 @@ Integer constant in the range 0 @dots{} 127, for 1
 Standard 80387 floating point constant.
 
 @item C
-Standard SSE floating point constant.
+SSE constant zero operand.
 
 @item e
 32-bit signed integer constant, or a symbolic reference known
Index: testsuite/gcc.target/i386/pr69459.c
===
--- testsuite/gcc.target/i386/pr69459.c (nonexistent)
+++ testsuite/gcc.target/i386/pr69459.c (working copy)
@@ -0,0 +1,42 @@
+/* PR target/69549 */
+/* { dg-do run { target sse2_runtime } } */
+/* { dg-options "-O2 -msse2" } */
+
+typedef unsigned char u8;
+typedef unsigned short u16;
+typedef unsigned int u32;
+typedef unsigned long long u64;
+typedef unsigned char v16u8 __attribute__ ((vector_size (16)));
+typedef unsigned short v16u16 __attribute__ ((vector_size (16)));
+typedef unsigned int v16u32 __attribute__ ((vector_size (16)));
+typedef unsigned long long v16u64 __attribute__ ((vector_size (16)));
+
+u64 __attribute__((noinline, noclone))
+foo (u8 u8_0, u16 u16_3, v16u8 v16u8_0, v16u16 v16u16_0, v16u32 v16u32_0, 
v16u64 v16u64_0, v16u8 v16u8_1, v16u16 v16u16_1, v16u32 v16u32_1, v16u64 
v16u64_1, v16u8 v16u8_2, v16u16 v16u16_2, v16u32 v16u32_2, v16u64 v16u64_2, 
v16u8 v16u8_3, v16u16 v16u16_3, v16u32 v16u32_3, v16u64 v16u64_3)
+{
+  v16u64_0 /= (v16u64){u16_3, ((0))} | 1;
+  v16u64_1 += (v16u64)~v16u32_0;
+  v16u16_1 /= (v16u16){-v16u64_3[1]} | 1;
+  v16u64_3[1] -= 0x1fff;
+  v16u32_2 /= (v16u32)-v16u64_0 | 1;
+  v16u32_1 += ~v16u32_1;
+  v16u16_3 %= (v16u16){0xfff, v16u32_2[3], v16u8_0[14]} | 1;
+  v16u64_3 -= (v16u64)v16u32_2;
+  if (v16u64_1[1] >= 1) {
+v16u64_0 %= (v16u64){v16u32_0[1]} | 1;
+v16u32_1[1] %= 0x5fb856;
+v16u64_1 |= -v16u64_0;
+  }
+  v16u8_0 *= (v16u8)v16u32_1;
+  return u8_0 + v16u8_0 [12] + 

Re: C++ PATCH for c++/69509 and c++/69516 (infinite recursion with invalid VLAs in constexpr functions)

[Jason Merrill]

OK.  I suppose we should also catch the out-of-bounds store in 
cxx_eval_store_expression...


Jason

Re: C++ PATCH for c++/69509 and c++/69516 (infinite recursion with invalid VLAs in constexpr functions)

[Marek Polacek]

On Thu, Jan 28, 2016 at 05:51:30PM -0500, Jason Merrill wrote:
> OK.  I suppose we should also catch the out-of-bounds store in
> cxx_eval_store_expression...

Thanks, I'll look into that as a follow-up.

Marek

[Bug target/69459] [5/6 Regression] wrong code with -O2 and vector arithmetics @ x86_64

[uros at gcc dot gnu.org]

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

--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jan 28 22:32:47 2016
New Revision: 232955

URL: https://gcc.gnu.org/viewcvs?rev=232955=gcc=rev
Log:
PR target/69459
* config/i386/constraints.md (C): Only accept constant zero operand.
(BC): New constraint.
* config/i386/sse.md (*mov_internal): Use BC constraint
instead of C constraint.
* doc/md.texi (Machine Constraints): Update description
of C constraint.

testsuite/ChangeLog:

PR target/69459
* gcc.target/i386/pr69459.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr69459.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/constraints.md
trunk/gcc/config/i386/sse.md
trunk/gcc/doc/md.texi
trunk/gcc/testsuite/ChangeLog

Re: Strange diagnostics behavior with patch

[David Malcolm]

On Thu, 2016-01-28 at 21:07 +0100, Thomas Koenig wrote:
> Hello world,
> 
> the attached patch fixes the regression of PR 60526 by checking for
> the presence of a type with the same name as the variable.  Types
> effectively have their separate namespace because the names of their
> symtrees start with an uppercase letter.  So far, so good.
> 
> However, the error message generated is far to big, and contains
> statements which are not relevant and also empty lines.
> 
> For the test case
> 
> type xx
> end type
> 
> integer :: q
> real :: a
> integer, parameter :: h=3
> 
> type(xX) :: Xx
> 
> end
> 
> 
> the error message becomes
> 
> type3.f90:8:14:
> 
>   type xx
> 2
>   end type
> 
> 
> 
>   integer :: q
> 
>   real :: a
> 
>   integer, parameter :: h=3
> 
> 
> 
>   type(xX) :: Xx
>1
> Error: Symbol »xx« at (1) also declared as a type at (2)
> 
> The error message is emitted via
> 
>gfc_error ("Symbol %qs at %C also declared as a type at %L",
> name,
>  >n.sym->declared_at);
> 
> which I think is the right thing to do.  Am I using this wrong, or is
> it
> a quirk in gfc_error or in the general error handling routines?


This looks like a bug in the general error-handling routines: for
diagnostics containing more than one location, the new implementation
of diagnostic_show_locus attempts to show all of the relevant locations
in one loop.  It prints a range of lines covering all of the locations
within the same source file as the primary location of the diagnostic. 

It looks like we need some logic to split things up if there's a big
gap between locations within one diagnostic (and probably to only print
annotation lines under the source if there are some annotations to go
in those lines).

Please can you file this example in bugzilla and CC me?

Thanks
Dave

[Bug middle-end/69542] [6 Regression] -fcompare-debug failure in simplify-rtx.c on i?86 since r232905

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug rtl-optimization/69530] [6 Regression] ICE: SIGSEGV in ix86_split_long_move (i386.c:24353) with -fno-split-wide-types -mavx

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #37509|0   |1
is obsolete||

--- Comment #10 from H.J. Lu  ---
Created attachment 37512
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37512=edit
A new patch

I am testing this now.

[Bug fortran/69520] Implement reversal of -fcheck options

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-28
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
> I don't have a strong opinion on whether the prefix for disabling
> should be "no" or "no-", or whether both should be accepted.
> The present patch implements the first variant.  If there is some
> guideline to use the latter, the changes are obviously trivial.

I'ld prefer "no-".

Re: [PATCH] target/68972 - g++.dg/cpp1y/vla-initlist1.C test case fails on powerpc64le

[Jason Merrill]

On 01/28/2016 02:48 PM, Martin Sebor wrote:

The g++.dg/cpp1y/vla-initlist1.C test relies on undefined behavior
(reading an uninitialized array element) to verify that two VLAs
are allocated in memory starting at the same address.  The test
has been seen to fail on powerpc64-*-linux-gnu and spu-*-elf.
The attached patch removes the undefined behavior while still
verifying the same thing.  It passes on powerpc64le.

Jason, based on your comment in the bug I've removed the part
of the test that verifies that the no-op initializer-list ctor
for the user-defined VLA leaves the array elements uninitialized.
If that's something that should be tested let me know and I'll
add another test or test case for that.


Actually, yes, the testcase is testing for that as well.  Is that the 
part that breaks on PPC64LE?


Jason

[Bug bootstrap/69506] [6 Regression] check-in 232454 seems to cause problems with cygwin builds

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
OK thanks, I'll commit it tomorrow.

[Bug middle-end/69546] New: [5/6 Regression] wrong code with -O and simple int128 arithmetics

[zsojka at seznam dot cz]

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

Bug ID: 69546
   Summary: [5/6 Regression] wrong code with -O and simple int128
arithmetics
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-*, aarch64-*, powerpc64-*, sparc64-*

Created attachment 37513
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37513=edit
reduced testcase

Output:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-232939-checking-yes-rtl-df-nobootstrap-nographite/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --disable-bootstrap --without-cloog --without-ppl
--without-isl --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-232939-checking-yes-rtl-df-nobootstrap-nographite
Thread model: posix
gcc version 6.0.0 20160128 (experimental) (GCC) 

$ gcc -O testcase.c
$ ./a.out 

Aborted

All tested __int128-capable targets are affected. (x86_64, powerpc64, aarch64,
sparc64)

Tested revisions:
r232939 - FAIL (after PR69399 fix)
5-branch r232545 - FAIL
4_9-branch r232544 - OK
4_[678]-branch - OK

[C++ patch] report better diagnostic for static following '[' in parameter declaration

[Prathamesh Kulkarni]

Hi,
For the test-case,
void f(int a[static 10]);

g++ gives following errors:
test-foo.cpp:1:14: error: expected primary-expression before ‘static’
 void f(int a[static 10]);
  ^
test-foo.cpp:1:14: error: expected ‘]’ before ‘static’
test-foo.cpp:1:14: error: expected ‘)’ before ‘static’
test-foo.cpp:1:14: error: expected initializer before ‘static’

and clang++ gives:
test-foo.cpp:1:13: error: static array size is a C99 feature, not
permitted in C++
void f(int a[static 10]);
^
I have attached patch that attempts to report the same diagnostic.
With patch, g++ reports:

test-foo.cpp:1:14: error: static array size is a C99 feature,not
permitted in C++
 void f(int a[static 10])
  ^~
test-foo.cpp:1:14: error: expected ‘]’ before ‘static’
test-foo.cpp:1:14: error: expected ‘)’ before ‘static’
test-foo.cpp:1:14: error: expected initializer before ‘static’

I tried to remove the 3 errors that follow it (expected X before static)
but without luck :/

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

Thanks,
Prathamesh
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d03b0c9..4d3e38a 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -19016,10 +19017,22 @@ cp_parser_direct_declarator (cp_parser* parser,
  cp_lexer_consume_token (parser->lexer);
  /* Peek at the next token.  */
  token = cp_lexer_peek_token (parser->lexer);
+
+ /* If static keyword immediately follows [, report error.  */
+ if (cp_lexer_next_token_is_keyword (parser->lexer, RID_STATIC)
+ && current_binding_level->kind == sk_function_parms)
+   {
+ error_at (token->location,
+   "static array size is a C99 feature,"
+   "not permitted in C++");
+ bounds = error_mark_node;
+   }
+
  /* If the next token is `]', then there is no
 constant-expression.  */
- if (token->type != CPP_CLOSE_SQUARE)
+ else if (token->type != CPP_CLOSE_SQUARE)
{
+
  bool non_constant_p;
  bounds
= cp_parser_constant_expression (parser,
diff --git a/gcc/testsuite/g++.dg/parse/static-array-error.C 
b/gcc/testsuite/g++.dg/parse/static-array-error.C
new file mode 100644
index 000..8b58588
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/static-array-error.C
@@ -0,0 +1,6 @@
+// { dg-do compile }
+
+void f(int a[static 10]);  /* { dg-error "static array size is a C99 feature" 
} */
+/* { dg-error "expected ']' before 'static'" "" { target *-*-* } 3 } */
+/* { dg-error "expected ')' before 'static'" "" { target *-*-* } 3 } */
+/* { dg-error "expected initializer before 'static'" "" { target *-*-* } 3 } */


ChangeLog
Description: Binary data