[PATCH] Fix cp_binding_level reuse logic

[Patrick Palka]

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?

gcc/cp/ChangeLog:

* name-lookup.c (begin_scope): After reusing a cp_binding_level
structure, update free_binding_level before the structure's
level_chain field gets cleared.
---
 gcc/cp/name-lookup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index c52d236..92d99aa 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -1557,8 +1557,8 @@ begin_scope (scope_kind kind, tree entity)
   if (!ENABLE_SCOPE_CHECKING && free_binding_level)
 {
   scope = free_binding_level;
-  memset (scope, 0, sizeof (cp_binding_level));
   free_binding_level = scope->level_chain;
+  memset (scope, 0, sizeof (cp_binding_level));
 }
   else
 scope = ggc_cleared_alloc ();
-- 
2.7.0.196.gaa98302.dirty

[Bug rtl-optimization/19705] -fno-branch-count-reg doesn't prevent decrement and branch instructions on a count register

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2006-03-05 03:12:14 |2016-1-27
 CC||msebor at gcc dot gnu.org
Summary|Cannot turn off doloop  |-fno-branch-count-reg
   |optimization via|doesn't prevent decrement
   |-fno-branch-count-reg if|and branch instructions on
   |-fno-ivopts is also |a count register
   |supplied|
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #5 from Martin Sebor  ---
I spent a bit of time looking at this today (more than I should have).

Based on the comments and based on my own testing and debugging, the Summary of
this bug isn't correct: the -fno-branch-count-reg option does disable the
doloop optimization (even when -fno-ivopts).  What's not correct is the
description of the effects of the option in the manual:

Do not use "decrement and branch" instructions on a count register, but instead
generate a sequence of instructions that decrement a register, compare it
against zero, then branch based upon the result.

I've adjusted the Summary to reflect that.

That said, I'm not sure what would be a meaningful update to the documentation.
 Saying that the -fno-branch-count-reg option may not actually do what its name
implies it's meant to do because there's some other pass that might do the
opposite doesn't seem very helpful.

FWIW, I was curious to know what pass is responsible for inserting the bdnz
instruction.  It seems that it's the combine pass and only in 32-bits.  That's
the first pass where I see the ctrsi_internal1 pattern introduced for the test
case.  (powerpc64 doesn't emit bdnz when -fno-branch-count-reg is used, at
least not for the test case.)

Anyway, with this background my opinion, for whatever it's worth, is that if
the purpose of the -fno-branch-count-reg option is to let users (as opposed to
GCC developers) control the kind of code that GCC emits then this seems like a
bug in the compiler that should be fixed by changing it to avoid emitting the
ctr_internal* patterns.  Otherwise, if its purpose is to let GCC
developers control whether or not the doloop pass runs, then that's how the
option should be documented.  (I do realize that despite what the manual
suggests these options are primarily used for debugging GCC so perhaps the
second alternative is the way to go.)

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

[anlauf at gmx dot de]

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

--- Comment #1 from Harald Anlauf  ---
The patch in comment #0 regtests ok on i686-pc-linux-gnu.

Possible ChangeLog entry:

2016-01-27  ...

PR fortran/69520
* options.c: Enhance -fcheck by reversal of specifications.
* invoke.texi: Document enhancement of -fcheck.

[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #12)
> At revision 232901, this testcase still ICEs on i686 (or x86_64 with -m32)
> on Fedora 23:
> 
> Running target unix/-m32
> FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)
> FAIL: gcc.dg/graphite/id-pr45230-1.c (test for excess errors)

Also seen in [1].

[1] https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg02668.html

[Bug rtl-optimization/69447] [5/6 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 #15 from Richard Henderson  ---
Author: rth
Date: Wed Jan 27 22:08:02 2016
New Revision: 232905

URL: https://gcc.gnu.org/viewcvs?rev=232905=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:
trunk/gcc/testsuite/gcc.c-torture/execute/pr69447.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-remat.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/69447] [5/6 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|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

[lra, committed] Fix PR 69447

[Richard Henderson]

This PR appears to be related to PR 66424, which Vlad fixed back in September,
but different in that the insn being rematerialized used the entire DImode
pseudo instead of an SImode subreg of a DImode pseudo.

The effect was the same, however, in that it lengthened the lifetime of one
half of the double-word pseudo, causing it to conflict with the coloring set up
by IRA.

While this solves the problem by refusing to remat any double-word pseudo that
has ever had one of its subreg taken, a more complete solution is to also sync
IRA and LRA so that both of them track lifetimes of subregs.  Not for now,
obviously.

Tested on x86_64, i686, and armv7hf-linux.
Approved by Vlad in the PR.


r~
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.

testsuite/
* gcc.c-torture/execute/pr69447.c: New test.


diff --git a/gcc/lra-remat.c b/gcc/lra-remat.c
index 6f490b9..4d8099f 100644
--- a/gcc/lra-remat.c
+++ b/gcc/lra-remat.c
@@ -77,6 +77,9 @@ static int call_used_regs_arr[FIRST_PSEUDO_REGISTER];
 /* Bitmap used for different calculations.  */
 static bitmap_head temp_bitmap;
 
+/* Registers accessed via subreg_p.  */
+static bitmap_head subreg_regs;
+
 typedef struct cand *cand_t;
 typedef const struct cand *const_cand_t;
 
@@ -383,30 +386,30 @@ operand_to_remat (rtx_insn *insn)
 return -1;
   /* First find a pseudo which can be rematerialized.  */
   for (reg = id->regs; reg != NULL; reg = reg->next)
-/* True FRAME_POINTER_NEEDED might be because we can not follow
-   changing sp offsets, e.g. alloca is used.  If the insn contains
-   stack pointer in such case, we can not rematerialize it as we
-   can not know sp offset at a rematerialization place.  */
-if (reg->regno == STACK_POINTER_REGNUM && frame_pointer_needed)
-  return -1;
-else if (reg->type == OP_OUT && ! reg->subreg_p
-&& find_regno_note (insn, REG_UNUSED, reg->regno) == NULL)
-  {
-   /* We permits only one spilled reg.  */
-   if (found_reg != NULL)
- return -1;
-   found_reg = reg;
-  }
-/* IRA calculates conflicts separately for subregs of two words
-   pseudo.  Even if the pseudo lives, e.g. one its subreg can be
-   used lately, another subreg hard register can be already used
-   for something else.  In such case, it is not safe to
-   rematerialize the insn.  */
-else if (reg->type == OP_IN && reg->subreg_p
-&& reg->regno >= FIRST_PSEUDO_REGISTER
-&& (GET_MODE_SIZE (PSEUDO_REGNO_MODE (reg->regno))
-== 2 * UNITS_PER_WORD))
-  return -1;
+{
+  /* True FRAME_POINTER_NEEDED might be because we can not follow
+changing sp offsets, e.g. alloca is used.  If the insn contains
+stack pointer in such case, we can not rematerialize it as we
+can not know sp offset at a rematerialization place.  */
+  if (reg->regno == STACK_POINTER_REGNUM && frame_pointer_needed)
+   return -1;
+  else if (reg->type == OP_OUT && ! reg->subreg_p
+  && find_regno_note (insn, REG_UNUSED, reg->regno) == NULL)
+   {
+ /* We permits only one spilled reg.  */
+ if (found_reg != NULL)
+   return -1;
+ found_reg = reg;
+}
+  /* IRA calculates conflicts separately for subregs of two words
+pseudo.  Even if the pseudo lives, e.g. one its subreg can be
+used lately, another subreg hard register can be already used
+for something else.  In such case, it is not safe to
+rematerialize the insn.  */
+  if (reg->regno >= FIRST_PSEUDO_REGISTER
+ && bitmap_bit_p (_regs, reg->regno))
+   return -1;
+}
   if (found_reg == NULL)
 return -1;
   if (found_reg->regno < FIRST_PSEUDO_REGISTER)
@@ -631,6 +634,9 @@ dump_candidates_and_remat_bb_data (void)
   lra_dump_bitmap_with_title ("avout cands in BB",
  _remat_bb_data (bb)->avout_cands, 
bb->index);
 }
+  fprintf (lra_dump_file, "subreg regs:");
+  dump_regset (_regs, lra_dump_file);
+  putc ('\n', lra_dump_file);
 }
 
 /* Free all BB data.  */
@@ -655,21 +661,24 @@ finish_remat_bb_data (void)
 
 
 
-/* Update changed_regs and dead_regs of BB from INSN.  */
+/* Update changed_regs, dead_regs, subreg_regs of BB from INSN.  */
 static void
 set_bb_regs (basic_block bb, rtx_insn *insn)
 {
   lra_insn_recog_data_t id = lra_get_insn_recog_data (insn);
+  remat_bb_data_t bb_info = get_remat_bb_data (bb);
   struct lra_insn_reg *reg;
 
   for (reg = id->regs; reg != NULL; reg = reg->next)
-if (reg->type != OP_IN)
-  bitmap_set_bit (_remat_bb_data (bb)->changed_regs, reg->regno);
-else
-  {
-   if 

Another suspicious code hunk in c-family/c-common.c

[Andrew MacLeod]

another chock with the static type code in 
c-family/c-common:handle_deprecated_attribute()

 around line 8919-8923


handle_deprecated_attribute (tree *node, tree name,
 tree args, int flags,
 bool *no_add_attrs)
{
<...>
if (DECL_P (*node))
{
  tree decl = *node;
  type = TREE_TYPE (decl);
<...>
}
else if (TYPE_P (*node))
{
  if (!(flags & (int) ATTR_FLAG_TYPE_IN_PLACE))
*node = build_variant_type_copy (*node);
  TREE_DEPRECATED (*node) = 1;
  type = *node;
}
<...>

if (type && TYPE_NAME (type))
{
  if (TREE_CODE (TYPE_NAME (type)) == IDENTIFIER_NODE)
(*) what = TYPE_NAME (*node);
  else if (TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
   && DECL_NAME (TYPE_NAME (type)))
what = DECL_NAME (TYPE_NAME (type));
}
  if (what)
warning (OPT_Wattributes, "%qE attribute ignored for %qE", 
name, what);



I think the (*) line is suppose to be
  what = TYPE_NAME (type);

It will work fine for the case where a type is passed in since type is 
equivilent to *name,  but in some cases of DECL I'd say it's not looking 
at the correct field..


Andrew

[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|RESOLVED|REOPENED
 Resolution|FIXED   |---
Summary|[5/6 Regression] wrong code |[5 Regression] wrong code
   |with -O2|with -O2
   |-fno-schedule-insns and |-fno-schedule-insns and
   |mixed 8/16/32/64bit |mixed 8/16/32/64bit
   |arithmetics @ armv7a|arithmetics @ armv7a

--- Comment #18 from Richard Henderson  ---
Of course it should.  Overeager close.

[Bug target/5372] [powerpc-*-eabi] -mno-eabi not working

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
The PowerPC EABI document itself does not say anything about __eabi
or process startup (it even says there are no requirements).

[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target|powerpc-*-*, arm*-*-*   |powerpc-*-*, arm*-*-*,
   ||i?86-*-*
 CC||ubizjak at gmail dot com

--- Comment #12 from Uroš Bizjak  ---
At revision 232901, this testcase still ICEs on i686 (or x86_64 with -m32) on
Fedora 23:

Running target unix/-m32
FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)
FAIL: gcc.dg/graphite/id-pr45230-1.c (test for excess errors)

Executing on host: /ssd/uros/gcc-build/gcc/xgcc -B/ssd/uros/gcc-build/gcc/
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c  -m32   
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/ 
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/mpxrt 
-L/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs 
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/ 
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/mpxwrap 
-L/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs 
-fno-diagnostics-show-caret -fdiagnostics-color=never   -O2 -fgraphite-identity
-ffast-math -S -o id-pr45230-1.s(timeout = 300)
spawn -ignore SIGHUP /ssd/uros/gcc-build/gcc/xgcc -B/ssd/uros/gcc-build/gcc/
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c -m32
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/mpxrt
-L/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/
-B/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/mpxwrap
-L/ssd/uros/gcc-build/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fgraphite-identity
-ffast-math -S -o id-pr45230-1.s
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c: In
function 'main':
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/graphite/id-pr45230-1.c:45:1:
internal compiler error: Segmentation fault
0xb2a58f crash_signal
/home/uros/gcc-svn/trunk/gcc/toplev.c:335
0x11cd064 translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*,
vec*)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1652
0x11cd0cf translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*,
vec*)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1662
0x11cd0cf translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*,
vec*)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1662
0x11cd0cf translate_isl_ast_to_gimple::collect_all_ssa_names(tree_node*,
vec*)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1662
0x11ce727 translate_isl_ast_to_gimple::rename_all_uses(tree_node*,
basic_block_def*, basic_block_def*)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1814
0x11ce900 translate_isl_ast_to_gimple::get_rename_from_scev(tree_node*,
gimple**, loop*, basic_block_def*, basic_block_def*, vec)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1871
0x11d0f5f translate_isl_ast_to_gimple::rename_uses(gimple*,
gimple_stmt_iterator*, basic_block_def*, loop*, vec)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1981
0x11d27f7
translate_isl_ast_to_gimple::graphite_copy_stmts_from_block(basic_block_def*,
basic_block_def*, vec)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:2861
0x11d2c66
translate_isl_ast_to_gimple::copy_bb_and_scalar_dependences(basic_block_def*,
edge_def*, vec)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:3077
0x11d3367
translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1172
0x11d36d9 translate_isl_ast_to_gimple::translate_isl_ast_for_loop(loop*,
isl_ast_node*, edge_def*, tree_node*, tree_node*, tree_node*, std::map, std::allocator > >&)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:922
0x11d391c translate_isl_ast_to_gimple::translate_isl_ast_node_for(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
/home/uros/gcc-svn/trunk/gcc/graphite-isl-ast-to-gimple.c:1090
0x11d3ae5 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,

Re: [PATCH] add test for target/17381 - Unnecessary register move for float extend

[Jeff Law]

On 01/27/2016 03:38 PM, Martin Sebor wrote:

The attached patch adds a test for the apparently long fixed
bug.

FWIW, I've been trying to close out some of these old bugs and
while it doesn't seem to be done consistently, it occurs to me
that it might be nice to add tests for them.  Please let me
know if you don't think it's worth the trouble (not just mine
but also reviewing the tests and maintaining them).
I suspect it's more oversight than anything.  And if an old bug isn't on 
the regression lists, it doesn't tend to get much attention.


I'm all for adding the regression tests and getting this stuff closed out.

I'll let the PPC maintainers weigh in on the actual test, but my 
inclination would be to include it if it works across the various PPC 
targets.



jeff

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

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #2 from Jerry DeLisle  ---
Harald, if you have commits rights or are interested in getting such, let me
know and we can let you take this one. (Otherwise I will do so)

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

[zsojka at seznam dot cz]

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

--- Comment #17 from Zdenek Sojka  ---
(In reply to Richard Henderson from comment #16)
> Fixed.

This patch is not going to the 5-branch?

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

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
Author: janus
Date: Wed Jan 27 22:32:52 2016
New Revision: 232906

URL: https://gcc.gnu.org/viewcvs?rev=232906=gcc=rev
Log:
2016-01-27  Janus Weil  

PR fortran/69484
* invoke.texi: Fix documentation of -Wall with respect to -Wtabs.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/invoke.texi

[PATCH] add test for target/17381 - Unnecessary register move for float extend

[Martin Sebor]

The attached patch adds a test for the apparently long fixed
bug.

FWIW, I've been trying to close out some of these old bugs and
while it doesn't seem to be done consistently, it occurs to me
that it might be nice to add tests for them.  Please let me
know if you don't think it's worth the trouble (not just mine
but also reviewing the tests and maintaining them).

Martin
PR target/17381 - Unnecessary register move for float extend

gcc/testsuite/ChangeLog:
2016-01-27  Martin Sebor  

	PR target/17381
	* gcc.target/powerpc/pr17381.c: New test.
Index: gcc/testsuite/gcc.target/powerpc/pr17381.c
===
--- gcc/testsuite/gcc.target/powerpc/pr17381.c	(revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr17381.c	(working copy)
@@ -0,0 +1,11 @@
+/* PR target/17381 - Unnecessary register move for float extend */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+double d;
+float test1(float fParm)
+{
+  d = fParm + 1.0;
+  return fParm + 1.0f;
+}
+/* { dg-final { scan-assembler-times "fmr" 1 } } */

[Bug target/18900] Don't use fp regs for mem moves without explicit use of fp

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #8 from Segher Boessenkool  ---
I think a long time ago (early 4.x era?) something went in to always
prefer integer registers for copying.  With the following testcase,
the only floating point use is for the structs with doubles.  (-m32
-mcpu=603 or similar).  Closing as fixed.

===
long long a, b;
struct { int x[2]; } sa, sb;
struct { char x[8]; } ta, tb;
struct { int x; int y; } ua, ub;
struct { float x; float y; } va, vb;
struct { double x; } wa, wb;
struct { double x[1]; } xa, xb;

void f(void)
{
a = b;
sa = sb;
ta = tb;
ua = ub;
va = vb;
wa = wb;
xa = xb;
}
===

RE: [PATCH] MIPS: Prevent the p5600-bonding.c test from being run for the n32 and 64 ABIs

[Moore, Catherine]

> -Original Message-
> From: Andrew Bennett [mailto:andrew.benn...@imgtec.com]
> Sent: Wednesday, January 20, 2016 9:42 AM
> To: Matthew Fortune; gcc-patches@gcc.gnu.org
> Cc: Moore, Catherine
> Subject: RE: [PATCH] MIPS: Prevent the p5600-bonding.c test from being run
> for the n32 and 64 ABIs
> 
> Ping.
> 

This is OK now.

> 
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org
> > [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Andrew Bennett
> > Sent: 02 September 2015 14:55
> > To: Matthew Fortune; gcc-patches@gcc.gnu.org
> > Cc: Moore, Catherine (catherine_mo...@mentor.com)
> > Subject: RE: [PATCH] MIPS: Prevent the p5600-bonding.c test from being
> > run for the n32 and 64 ABIs
> >
> > > > diff --git a/gcc/testsuite/gcc.target/mips/p5600-bonding.c
> > > > b/gcc/testsuite/gcc.target/mips/p5600-bonding.c
> > > > index 0890ffa..20c26ca 100644
> > > > --- a/gcc/testsuite/gcc.target/mips/p5600-bonding.c
> > > > +++ b/gcc/testsuite/gcc.target/mips/p5600-bonding.c
> > > > @@ -1,6 +1,7 @@
> > > >  /* { dg-do compile } */
> > > >  /* { dg-options "-dp -mtune=p5600  -mno-micromips -mno-mips16" }
> > > > */
> > > >  /* { dg-skip-if "Bonding needs peephole optimization." { *-*-* } { 
> > > > "-O0"
> > "-
> > > O1" } { "" } }
> > > > */
> > > > +/* { dg-skip-if "There is no DI mode support for load/store
> > > > +bonding" { *-
> > *-
> > > * } { "-
> > > > mabi=n32" "-mabi=64" } { "" } } */  typedef int VINT32
> > > > __attribute__ ((vector_size((16;
> > >
> > > If the best fix we can do for this test is to limit what it tests
> > > then we should still not just skip it. There is some precedence for
> > > tests that require a specific arch with the isa=loongson special
> > > case. I'd rather just lock the test down to p5600 as per the filename.
> >
> > I have changed the testcase's dg-options so that it is only built for p5600.
> > The updated patch and ChangeLog are below.
> >
> > Ok to commit?
> >
> > Many thanks,
> >
> >
> >
> > Andrew
> >
> >
> > testsuite/
> > * gcc.target/mips/p5600-bonding.c (dg-options): Force the test to be
> > always
> > built for p5600.
> > * gcc.target/mips/mips.exp (mips-dg-options): Add support for the
> > isa=p5600
> > dg-option.
> >
> >
> > diff --git a/gcc/testsuite/gcc.target/mips/mips.exp
> > b/gcc/testsuite/gcc.target/mips/mips.exp
> > index 42e7fff..e8d1895 100644
> > --- a/gcc/testsuite/gcc.target/mips/mips.exp
> > +++ b/gcc/testsuite/gcc.target/mips/mips.exp
> > @@ -142,6 +142,9 @@
> >  #   isa=loongson
> >  #  select a Loongson processor
> >  #
> > +#   isa=p5600
> > +#  select a P5600 processor
> > +#
> >  #   addressing=absolute
> >  #  force absolute addresses to be used
> >  #
> > @@ -1009,6 +1012,10 @@ proc mips-dg-options { args } {
> > if { ![regexp {^-march=loongson} $arch] } {
> > set arch "-march=loongson2f"
> > }
> > +   } elseif { [string equal $spec "isa=p5600"] } {
> > +   if { ![regexp {^-march=p5600} $arch] } {
> > +   set arch "-march=p5600"
> > +   }
> > } else {
> > if { ![regexp {^(isa(?:|_rev))(=|<=|>=)([0-9]*)$} \
> >$spec dummy prop relation value nocpus] } {
> > diff --git a/gcc/testsuite/gcc.target/mips/p5600-bonding.c
> > b/gcc/testsuite/gcc.target/mips/p5600-bonding.c
> > index 0890ffa..0bc6d91 100644
> > --- a/gcc/testsuite/gcc.target/mips/p5600-bonding.c
> > +++ b/gcc/testsuite/gcc.target/mips/p5600-bonding.c
> > @@ -1,5 +1,5 @@
> >  /* { dg-do compile } */
> > -/* { dg-options "-dp -mtune=p5600  -mno-micromips -mno-mips16" } */
> > +/* { dg-options "-dp isa=p5600 -mtune=p5600 -mno-micromips
> > +-mno-mips16" } */
> >  /* { dg-skip-if "Bonding needs peephole optimization." { *-*-* } {
> > "-O0" "- O1" } { "" } } */  typedef int VINT32 __attribute__
> > ((vector_size((16;

[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

[amodra at gmail dot com]

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

--- Comment #10 from Alan Modra  ---
I guess rs6000 needs to implement targetm.override_options_after_change() if
we're to keep flag_pic and TARGET_RELOCATABLE consistent.

[PATCH, rs6000] Disable static branch prediction in absence of real profile data

[Pat Haugen]

The following patch prevents static prediction if we don't have real 
profile data. Testing on SPEC CPU2006 showed a couple improvements in 
specint and specfp neutral. Bootstrap/regtest on powerpc64 with no new 
regressions. Ok for trunk?


-Pat


2016-01-27  Pat Haugen  

* config/rs6000/rs6000.c (output_cbranch): Don't statically predict
branches if using guessed profile.


Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c	(revision 232881)
+++ gcc/config/rs6000/rs6000.c	(working copy)
@@ -21424,14 +21424,15 @@ output_cbranch (rtx op, const char *labe
   /* PROB is the difference from 50%.  */
   int prob = XINT (note, 0) - REG_BR_PROB_BASE / 2;
 
-  /* Only hint for highly probable/improbable branches on newer
-	 cpus as static prediction overrides processor dynamic
-	 prediction.  For older cpus we may as well always hint, but
+  /* Only hint for highly probable/improbable branches on newer cpus when
+	 we have real profile data, as static prediction overrides processor
+	 dynamic prediction.  For older cpus we may as well always hint, but
 	 assume not taken for branches that are very close to 50% as a
 	 mispredicted taken branch is more expensive than a
 	 mispredicted not-taken branch.  */
   if (rs6000_always_hint
 	  || (abs (prob) > REG_BR_PROB_BASE / 100 * 48
+	  && (profile_status_for_fn (cfun) != PROFILE_GUESSED)
 	  && br_prob_note_reliable_p (note)))
 	{
 	  if (abs (prob) > REG_BR_PROB_BASE / 20

Re: [PATCH][AArch64] Replace insn to zero up DF register

[Evandro Menezes]

On 01/22/16 07:52, Wilco Dijkstra wrote:

On 12/16/2015 03:30 PM, Evandro Menezes wrote:

 On 10/30/2015 05:24 AM, Marcus Shawcroft wrote:

 On 20 October 2015 at 00:40, Evandro Menezes  
wrote:

 In the existing targets, it seems that it's always faster to zero 
up a DF

 register with "movi %d0, #0" instead of "fmov %d0, xzr".

 This patch modifies the respective pattern.


 Hi Evandro,

 This patch changes the generic, u architecture independent instruction
 selection. The ARM ARM (C3.5.3) makes a specific recommendation about
 the choice of instruction in this situation and the current
 implementation in GCC follows that recommendation.  Wilco has also
 picked up on this issue he has the same patch internal to ARM along
 with an ongoing discussion with ARM architecture folk regarding this
 recommendation.  I'm reluctant to take this patch right now on the
 basis that it runs contrary to ARM ARM recommendation pending the
 conclusion of Wilco's discussion with ARM architecture folk.


 Have you had a chance to discuss this internally further?

Yes, it was decided to remove the recommendation from future ARM ARM's.

Several review comments on your patch 
(https://patchwork.ozlabs.org/patch/532736):

* This should be added to movhf, movsf and movdf - movtf already does this.
* It is important to set the "fp" and "simd" attributes so that the movi 
variant can
only be selected if it is available.



Hi, Wilco.

   2016-01-27 Evandro Menezes 

Replace insn to zero up SIMD registers

gcc/
* config/aarch64/aarch64.md
(*movhf_aarch64): Add "movi %0, #0" to zero up register.
(*movsf_aarch64): Likewise.
(*movdf_aarch64): Likewise.

When this decision is final, methinks that this patch would be close to 
addressing this change.


I have a question though: is it necessary to add the "fp" and "simd" 
attributes to both movsf_aarch64 and movdf_aarch64 as well?


Thank you,

--
Evandro Menezes

>From b390d411b56cfcdedf4601d0487baf1ef84e79ab Mon Sep 17 00:00:00 2001
From: Evandro Menezes 
Date: Mon, 19 Oct 2015 18:31:48 -0500
Subject: [PATCH] Replace insn to zero up SIMD registers

gcc/
	* config/aarch64/aarch64.md
	(*movhf_aarch64): Add "movi %0, #0" to zero up register.
	(*movsf_aarch64): Likewise.
	(*movdf_aarch64): Likewise.
---
 gcc/config/aarch64/aarch64.md | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index f6c8eb1..43a3854 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -1164,64 +1164,67 @@
   operands[1] = force_reg (mode, operands[1]);
   }
 )
 
 (define_insn "*movhf_aarch64"
-  [(set (match_operand:HF 0 "nonimmediate_operand" "=w, ?r,w,w,m,r,m ,r")
-	(match_operand:HF 1 "general_operand"  "?rY, w,w,m,w,m,rY,r"))]
+  [(set (match_operand:HF 0 "nonimmediate_operand" "=w,w,?r,w,w,m,r,m ,r")
+	(match_operand:HF 1 "general_operand"  "?r,Y, w,w,m,w,m,rY,r"))]
   "TARGET_FLOAT && (register_operand (operands[0], HFmode)
 || aarch64_reg_or_fp_zero (operands[1], HFmode))"
   "@
mov\\t%0.h[0], %w1
+   movi\\t%0.8h, #0
umov\\t%w0, %1.h[0]
mov\\t%0.h[0], %1.h[0]
ldr\\t%h0, %1
str\\t%h1, %0
ldrh\\t%w0, %1
strh\\t%w1, %0
mov\\t%w0, %w1"
-  [(set_attr "type" "neon_from_gp,neon_to_gp,neon_move,\
+  [(set_attr "type" "neon_from_gp,neon_move,neon_to_gp,neon_move,\
  f_loads,f_stores,load1,store1,mov_reg")
-   (set_attr "simd" "yes,yes,yes,*,*,*,*,*")
-   (set_attr "fp"   "*,*,*,yes,yes,*,*,*")]
+   (set_attr "simd" "yes,yes,yes,yes,*,*,*,*,*")
+   (set_attr "fp"   "*,*,*,*,yes,yes,*,*,*")]
 )
 
 (define_insn "*movsf_aarch64"
-  [(set (match_operand:SF 0 "nonimmediate_operand" "=w, ?r,w,w  ,w,m,r,m ,r")
-	(match_operand:SF 1 "general_operand"  "?rY, w,w,Ufc,m,w,m,rY,r"))]
+  [(set (match_operand:SF 0 "nonimmediate_operand" "=w,w,?r,w,w  ,w,m,r,m ,r")
+	(match_operand:SF 1 "general_operand"  "?r,Y, w,w,Ufc,m,w,m,rY,r"))]
   "TARGET_FLOAT && (register_operand (operands[0], SFmode)
 || aarch64_reg_or_fp_zero (operands[1], SFmode))"
   "@
fmov\\t%s0, %w1
+   movi\\t%0.4s, #0
fmov\\t%w0, %s1
fmov\\t%s0, %s1
fmov\\t%s0, %1
ldr\\t%s0, %1
str\\t%s1, %0
ldr\\t%w0, %1
str\\t%w1, %0
mov\\t%w0, %w1"
-  [(set_attr "type" "f_mcr,f_mrc,fmov,fconsts,\
+  [(set_attr "type" "f_mcr,neon_move,f_mrc,fmov,fconsts,\
  f_loads,f_stores,load1,store1,mov_reg")]
 )
 
 (define_insn "*movdf_aarch64"
-  [(set (match_operand:DF 0 "nonimmediate_operand" "=w, ?r,w,w  ,w,m,r,m ,r")
-	(match_operand:DF 1 "general_operand"  "?rY, w,w,Ufc,m,w,m,rY,r"))]
+  [(set (match_operand:DF 0 "nonimmediate_operand" "=w,w,?r,w,w 

gcc-4.9-20160127 is now available

[gccadmin]

Snapshot gcc-4.9-20160127 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160127/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch 
revision 232905

You'll find:

 gcc-4.9-20160127.tar.bz2 Complete GCC

  MD5=be23c0ea7d1598eedabb30f96e2b4be3
  SHA1=0d7f06ea50a4f19c5e01d926fcadc0766041fe8d

Diffs from 4.9-20160120 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug target/18154] Inefficient max/min code for PowerPC

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Target|powerpc-*-* |powerpc*-*-*
 Status|NEW |WAITING
   Last reconfirmed|2006-10-22 23:16:26 |2016-1-27
 CC||msebor at gcc dot gnu.org
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #7 from Martin Sebor  ---
Current trunk as well as all supported GCC versions before it still emits the
same code (see below).  XLC 12 on gcc111.fsffrance.org also emits a branch (see
below).  Ditto for Clang.

David, in light of this and in light of comments #4 and #5, do you still
believe that GCC should change as you suggested in the Description?

.min:   # 0x (H.10.NO_SYMBOL)
cmp0,r3,r4
bc BO_IF,CR0_LT,__L10
oril   r3,r4,0x
bcrBO_ALWAYS,CR0_LT
__L10:  # 0x0010 (H.10.NO_SYMBOL+0x10)
bcrBO_ALWAYS,CR0_LT


$ cat ~/tmp/t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -O2 -S
-Wall -Wextra -Wpedantic -o/dev/stdout ~/tmp/t.c
int min(int a, int b) {
  if (a < b)
return a;
  else
return b;
}
.file   "t.c"
.machine power8
.abiversion 2
.section".toc","aw"
.section".text"
.align 2
.p2align 4,,15
.globl min
.type   min, @function
min:
cmpw 7,3,4
ble 7,.L2
mr 3,4
.L2:
extsw 3,3
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size   min,.-min
.ident  "GCC: (GNU) 6.0.0 20160125 (experimental)"
.section.note.GNU-stack,"",@progbits

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

[John David Anglin]

The attached patch fixes a stage1 build error compiling genautomata.c on hpux.  
We need to test for obsolete
XOPEN declarations of isinf and isnan on hpux.  Further, we need to check 
individually for isinf and isnan on hpux11
since only isnan has an obsolete XOPEN declaration.

Tested on hppa2.0w-hp-hpux11.11.

Okay for trunk?

Dave
--
John David Anglin   dave.ang...@bell.net


2016-01-27  John David Anglin  

PR libstdc++/69450
* acinclude.m4 (GLIBCXX_CHECK_MATH11_PROTO): Split check for obsolete
isinf and isnan functions into two independent checks.  Check on hpux.
* config.h.in: Regenerate.
* configure: Regenerate.
* include/c_global/cmath (isinf(double), isnan(double)): Use
_GLIBCXX_HAVE_OBSOLETE_ISINF and _GLIBCXX_HAVE_OBSOLETE_ISNAN,
respectively.

Index: acinclude.m4
===
--- acinclude.m4(revision 232776)
+++ acinclude.m4(working copy)
@@ -2186,39 +2186,54 @@
   fi
   AC_MSG_RESULT([$glibcxx_cv_math11_overload])
   ;;
-*-*-*gnu* | *-*-aix*)
+*-*-*gnu* | *-*-aix* | *-*-hpux*)
   # If  defines the obsolete isinf(double) and isnan(double)
   # functions (instead of or as well as the C99 generic macros) then we
   # can't define std::isinf(double) and std::isnan(double) in 
   # and must use the ones from  instead.
-  AC_MSG_CHECKING([for obsolete isinf and isnan functions in ])
-AC_CACHE_VAL(glibcxx_cv_obsolete_isinf_isnan, [
+  AC_MSG_CHECKING([for obsolete isinf function in ])
+AC_CACHE_VAL(glibcxx_cv_obsolete_isinf, [
   AC_COMPILE_IFELSE([AC_LANG_SOURCE(
 [#include 
  #undef isinf
- #undef isnan
  namespace std {
using ::isinf;
bool isinf(float);
bool isinf(long double);
+ }
+ using std::isinf;
+ bool b = isinf(0.0);
+  ])],
+  [glibcxx_cv_obsolete_isinf=yes],
+  [glibcxx_cv_obsolete_isinf=no]
+)])
+  AC_MSG_RESULT([$glibcxx_cv_obsolete_isinf])
+  if test $glibcxx_cv_obsolete_isinf = yes; then
+AC_DEFINE(HAVE_OBSOLETE_ISINF, 1,
+  [Define if  defines obsolete isinf function.])
+  fi
+
+  AC_MSG_CHECKING([for obsolete isnan function in ])
+AC_CACHE_VAL(glibcxx_cv_obsolete_isnan, [
+  AC_COMPILE_IFELSE([AC_LANG_SOURCE(
+[#include 
+ #undef isnan
+ namespace std {
using ::isnan;
bool isnan(float);
bool isnan(long double);
  }
- using std::isinf;
  using std::isnan;
- bool b = isinf(0.0) || isnan(0.0);
+ bool b = isnan(0.0);
   ])],
-  [glibcxx_cv_obsolete_isinf_isnan=yes],
-  [glibcxx_cv_obsolete_isinf_isnan=no]
+  [glibcxx_cv_obsolete_isnan=yes],
+  [glibcxx_cv_obsolete_isnan=no]
 )])
-
-
-  if test $glibcxx_cv_obsolete_isinf_isnan = yes; then
-AC_DEFINE(HAVE_OBSOLETE_ISINF_ISNAN, 1,
-  [Define if  defines obsolete isinf and isnan 
functions.])
+  AC_MSG_RESULT([$glibcxx_cv_obsolete_isnan])
+  if test $glibcxx_cv_obsolete_isnan = yes; then
+AC_DEFINE(HAVE_OBSOLETE_ISNAN, 1,
+  [Define if  defines obsolete isnan function.])
   fi
-  AC_MSG_RESULT([$glibcxx_cv_obsolete_isinf_isnan])
   ;;
   esac
 
Index: include/c_global/cmath
===
--- include/c_global/cmath  (revision 232776)
+++ include/c_global/cmath  (working copy)
@@ -610,7 +610,7 @@
   isinf(float __x)
   { return __builtin_isinf(__x); }
 
-#if _GLIBCXX_HAVE_OBSOLETE_ISINF_ISNAN \
+#if _GLIBCXX_HAVE_OBSOLETE_ISINF \
   && !_GLIBCXX_NO_OBSOLETE_ISINF_ISNAN_DYNAMIC
   using ::isinf;
 #else
@@ -635,7 +635,7 @@
   isnan(float __x)
   { return __builtin_isnan(__x); }
 
-#if _GLIBCXX_HAVE_OBSOLETE_ISINF_ISNAN \
+#if _GLIBCXX_HAVE_OBSOLETE_ISNAN \
   && !_GLIBCXX_NO_OBSOLETE_ISINF_ISNAN_DYNAMIC
   using ::isnan;
 #else

[Bug c++/24208] C++ front-end can still be sped up

[ppalka at gcc dot gnu.org]

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

--- Comment #9 from Patrick Palka  ---
Author: ppalka
Date: Thu Jan 28 01:06:29 2016
New Revision: 232912

URL: https://gcc.gnu.org/viewcvs?rev=232912=gcc=rev
Log:
Low-hanging C++-lexer speedup (PR c++/24208)

gcc/cp/ChangeLog:

PR c++/24208
* parser.c (LEXER_DEBUGGING_ENABLED_P): New macro.
(cp_lexer_debugging_p): Use it.
(cp_lexer_start_debugging): Likewise.
(cp_lexer_stop_debugging): Likewise.


Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c

[Bug c++/22238] Awful error messages with virtual functions

[dmalcolm at gcc dot gnu.org]

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

--- Comment #22 from David Malcolm  ---
(In reply to Manuel López-Ibáñez from comment #20)
[...]
> I maintain my opinion that any user-facing diagnostic using %qE is
> potentially broken.

Thanks; I'm inclined to agree.

Notes to self: implementation of %qE is in cp/error.c:cp_printer, which calls
expr_to_string.

$ grep "%qE" gcc/cp/*.c | wc -l
195

[Bug c++/53341] overloaded operator delete(void *) appear in object file even when not directly used

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
With -std=c++0x  included  (until a few days ago on trunk),
which is what caused the difference.

I don't see _ZdlPv since 4.8.0 though.

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

[Michael Karcher]

On 27.01.2016 22:49, Andrew Pinski wrote:
> On Wed, Jan 27, 2016 at 7:17 AM, Richard Biener
>  wrote:
>>
>> We are trying to support
>>
>> t.c
>> ---
>> void *foo();
>>
>> int bar()
>> {
>>   return ((int (*)())foo) ();
>> }
> Why can't ghc produce code like:
> int bar ()
> {
>   int (*foo1)() = foo;
>   asm("":"+r"(foo1));
>   return foo1();
> }
Thank you for the first suggestion about what ghc can do to avoid the
problem without the need to change the internally used Cmm language (as
would be needed to avoid lying about the type of foo).
 
> Yes it no longer produces an direct function call but it might be
> better in the long run anyways.
I don't really care about the direct function call. Using ghc on a
target where it can't generate native machine code is doomed to be slow
anyway.
But I don't see how it "might be better in the long rung anyway". The
first thing I note is that this workaround is specific to gcc. I didn't
check the gcc internals manual, but I am unsure whether the constraint
"r" is portable to be used on function pointers on all architectures gcc
supports. Furthermore, this hides the fact that the use case is not
supported by playing games with the optimizer, whereas Jeff and Richard
try to get this use case supported.

If gcc decides that the m68k backend should not be adjusted to use the
parameter "valtype" to determine the register used by the currently
selected ABI for the return value on caller side, but keep using the
function declaration for that, I will nevertheless propose this change
to ghc.

> Thanks,
> Andrew
Regards,
  Michael Karcher

[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

[amodra at gmail dot com]

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

--- Comment #9 from Alan Modra  ---
For the testcase in comment #7, global_options are inconsistent (*) and wrong
when compiling foo.  I see flag_pic == 2 there??

(*) In particular, TARGET_RELOCATABLE and flag_pic don't agree.  See
config/rs6000/sysv4.h SUBTARGET_OVERRIDE_OPTIONS.  flag_pic == 2 ought to mean
TARGET_RELOCATABLE is true, but TARGET_RELOCATABLE is false.  This combination
is not recognized in rs6000_emit_move.

[Patch, Fortran, committed] PR 69484: [5/6 Regression] documentation issue: -Wtabs and -Wall

[Janus Weil]

Hi all,

I have just committed a rather obvious documentation fix to trunk:

https://gcc.gnu.org/viewcvs/gcc?view=revision=232906

I'll also backport this to the gcc-5 branch soonish ...

Cheers,
Janus

[Bug middle-end/17958] expand_divmod fails to optimize division of 64-bit quantity by small constant when BITS_PER_WORD is 32

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2007-07-02 21:30:35 |2016-1-27
 CC||msebor at gcc dot gnu.org
  Known to fail||4.8.3, 4.9.3, 5.3.0, 6.0

--- Comment #3 from Martin Sebor  ---
It doesn't look like the patch referenced in comment #2 was ever committed and
the 32-bit code still emits a call to __divdi3, not just on powerpc but also on
x86_64.  This affects all still supported GCC versions.

$ cat ~/tmp/t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -O2 -S
-Wall -Wextra -Wpedantic -m32 -o/dev/stdout ~/tmp/t.c
long long div10(long long n) { return n / 10; }
.file   "t.c"
.machine power4
.globl __divdi3
.section".text"
.align 2
.p2align 4,,15
.globl div10
.type   div10, @function
div10:
stwu 1,-16(1)
li 5,0
mflr 0
li 6,10
stw 0,20(1)
bl __divdi3
lwz 0,20(1)
addi 1,1,16
mtlr 0
blr
.size   div10,.-div10
.ident  "GCC: (GNU) 6.0.0 20160125 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug fortran/69497] ICE in gfc_free_namespace, at fortran/symbol.c:3701

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #4 from Jerry DeLisle  ---
Dominique, I will take this one unless you want to.

Re: Another suspicious code hunk in c-family/c-common.c

[Jeff Law]

On 01/27/2016 03:41 PM, Andrew MacLeod wrote:

another chock with the static type code in
c-family/c-common:handle_deprecated_attribute()
  around line 8919-8923


handle_deprecated_attribute (tree *node, tree name,
  tree args, int flags,
  bool *no_add_attrs)
{
<...>
if (DECL_P (*node))
 {
   tree decl = *node;
   type = TREE_TYPE (decl);
<...>
 }
else if (TYPE_P (*node))
 {
   if (!(flags & (int) ATTR_FLAG_TYPE_IN_PLACE))
 *node = build_variant_type_copy (*node);
   TREE_DEPRECATED (*node) = 1;
   type = *node;
 }
<...>

if (type && TYPE_NAME (type))
 {
   if (TREE_CODE (TYPE_NAME (type)) == IDENTIFIER_NODE)
(*) what = TYPE_NAME (*node);
   else if (TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
&& DECL_NAME (TYPE_NAME (type)))
 what = DECL_NAME (TYPE_NAME (type));
 }
   if (what)
 warning (OPT_Wattributes, "%qE attribute ignored for %qE",
name, what);


I think the (*) line is suppose to be
   what = TYPE_NAME (type);

It will work fine for the case where a type is passed in since type is
equivilent to *name,  but in some cases of DECL I'd say it's not looking
at the correct field..

That would be my suspicion as well.

Good to see this work exposing this kind of issue at compile time -- 
that was definitely one of the things I want to get out of this class of 
infrastructure changes.


jeff

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)

[Eric Botcazou]

> [cc-ing Eric as RTL maintainer]

Sorry for the delay, the message apparently bounced]

> IMO the problem is that rtx_addr_can_trap_p_1 duplicates a large
> bit of LRA/reload logic:
> 
> [...]
> 
> Under the current interface macros like INITIAL_ELIMINATION_OFFSET
> are expected to trigger the calculation of the target's frame layout
> (since you need that information to answer the question).
> To me it seems wrong that we're attempting to call that sort of
> macro in a query routine like rtx_addr_can_trap_p_1.

I'm a little uncomfortable stepping in here because, while I essentially share 
your objections and was opposed to the patch (I was almost sure that it would 
introduce maintainance issues for no practical benefit), I didn't imagine that 
such a failure mode would have been possible (computing an approximation of 
the frame layout after reload being problematic) so I didn't really object to 
being overruled after seeing Bernd's patch...

> IMO we should cache the information we need@the start of each
> LRA/reload cycle.  This will be more robust, because there will
> be no accidental changes to global state either during or after
> LRA/reload.  It will also be more efficient because
> rtx_addr_can_trap_p_1 can read the cached variables rather
> than calling back into the target.

That would be a better design for sure and would eliminate the maintainance 
issues I was originally afraid of.

My recommendation would be to back out Bernd's patch for GCC 6.0 (again, it 
doesn't fix any regression and, more importantly, any bug in real software, 
but only corner case bugs in dumb computer-generated testcases) but with the 
commitment to address the underlying issue for GCC 7.0 and backport the fix to 
GCC 6.x unless really impracticable.  That being said, it's ultimately Jakub 
and Richard's call.

-- 
Eric Botcazou

[Bug c++/69521] -Wdeprecated-declarations errors in unused inline methods

[loic.yhuel at gmail dot com]

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

Loïc Yhuel  changed:

   What|Removed |Added

 CC||loic.yhuel at gmail dot com

--- Comment #1 from Loïc Yhuel  ---
> If it's easier to do, perhaps using a deprecated function in a deprecated
> function shouldn't produce a warning (deprecated code would be able to use
> other deprecated code).
Clang seems to do this.
Testing with clang 3.7, the 3 cases (first code, second code in C++ mode,
second code in C mode) don't produce any warning, unless I remove the
deprecated attribute from qLowerBound.

Re: [PATCH 1/4] Make SRA scalarize constant-pool loads

[Jeff Law]

On 01/27/2016 12:39 PM, David Edelsohn wrote:

The new sra-17.c and sra-18.c tests fail on AIX because the regex is
too restrictive -- AIX labels don't have exactly the same format.  On
AIX, the labels in the dumps look like "LC..0" instead of ".LC0".

This patch adds "*" and ".*" so that the "." prepended to LC is
optional and to allow characters between the "LC" and the "0".

I needed extra escapes for the sra-17.c line that matches multiple
times - for no apparent reason.
The joys of expect/tcl.  I just keep escaping until the regex that I 
developed outside the suite works.  I have been trying to get away from 
using .* though.  The longest match nature sometimes gives surprising 
results.  In theory .*? ought to work better, but I haven't tried using 
it much.


Anyway, the change looks fine to me.

jeff

[Bug c++/69523] New: -Wliteral-suffix should not warn within namespace std

[eric at efcs dot ca]

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

Bug ID: 69523
   Summary: -Wliteral-suffix should not warn within namespace std
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Created attachment 37497
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37497=edit
reproducer.cpp

While developing for libc++ I enable warnings in the headers. Unfortunately
 always emits the warning:

> libcxx/include/string:4267:36: error: literal operator suffixes not preceded 
> by ‘_’ are reserved for future standardization [-Werror]

Obviously this is a false positive. Since the warning is on by default and
-Wno-literal-suffix doesn't disable it, then it needs to ignore user defined
literals within namespace std.

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
How about declaring those headers as system headers by using -isystem instead
of using -I :)?

[Bug tree-optimization/22226] vectorization library

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
There's been no activity on this bug in almost eight years.  Is this still a
desirable enhancement today (or are there better alternatives), and is there
any likelihood that it will be implemented?  (I don't have an opinion, just
trying to clear out some old inactive bugs.)

Re: new port: vn8

[Mike Stump]

On Jan 27, 2016, at 7:12 PM, Bernhard Reutner-Fischer  
wrote:
> On January 27, 2016 8:47:15 PM GMT+01:00, Mike Stump  
> wrote:
>> On Jan 26, 2016, at 10:33 PM, Nguyễn Sinh Ngọc
>>  wrote:
>>> I wonder that what paper is?
>>> Is it an introduction about new feature in our target?
>> 
>> I was not able to make any sense of these two question.  Likely a
>> language barrier.  If you can find a way to rephrase them…  I can try
>> and answer.
> 
> I guess gcc.gnu.org/contribute.html#legal
> 
> I.e. copyright assignment.

Yes.  In theory someone on this list will help you with it.  I just don’t know 
who usually does this; they should step forward and help get you the right 
assignments.  If you don’t hear some someone soon, just ping the list for help 
on the copyright assignment forms.

[Bug target/65010] ppc backend generates unnecessary signed extension

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|DUPLICATE   |---

--- Comment #6 from David Edelsohn  ---
This is not the same.  There is a difference between sign extension of
arguments and sign extensions within a function.

Re: [PATCH, rs6000] Disable static branch prediction in absence of real profile data

[David Edelsohn]

On Wed, Jan 27, 2016 at 6:10 PM, Pat Haugen  wrote:
> The following patch prevents static prediction if we don't have real profile
> data. Testing on SPEC CPU2006 showed a couple improvements in specint and
> specfp neutral. Bootstrap/regtest on powerpc64 with no new regressions. Ok
> for trunk?
>
> -Pat
>
>
> 2016-01-27  Pat Haugen  
>
> * config/rs6000/rs6000.c (output_cbranch): Don't statically predict
> branches if using guessed profile.

Okay.

Thanks, David

[Bug target/19746] printf() optimisation ignores longcall attribute

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2005-05-09 01:18:53 |2016-1-27
 CC||msebor at gcc dot gnu.org
  Known to fail||5.3.0, 6.0

--- Comment #3 from Martin Sebor  ---
The behavior is still present on trunk and currently supported versions.  The
test case below shows the difference between the expected call sequence (in
bar_long) and the actual call sequence (in foo, which matches that in
bar_short).

That said, I don't think this is a target-specific problem.  The same issue
exists in other back ends, and is likely caused by some early folding not
taking into account differences in attributes or the presence of user-defined
declarations (as suggested by the patch in comment #2).

It seems that this bug should be reclassified as middle-end?

$ cat t.c && /build/sysroot/powerpc-eabispe/bin/powerpc-eabispe-gcc -O2 -S -o
/dev/stdout t.c
int printf (const char*, ...) __attribute__ ((__longcall__)); 
int puts (const char*) __attribute__ ((__longcall__));

void foo (void) { printf (" \n"); }

int puts_long (const char*) __attribute__ ((__longcall__));
int puts_short (const char*) __attribute__ ((__shortcall__));

void bar_long (void) { puts_long (" "); }
void bar_short (void) { puts_short (" "); }


.file   "t.c"
.section".text"
.align 2
.globl foo
.type   foo, @function
foo:
lis 3,.LC0@ha
la 3,.LC0@l(3)
b puts
.size   foo, .-foo
.align 2
.globl bar_long
.type   bar_long, @function
bar_long:
stwu 1,-8(1)
lis 9,puts_long@ha
mflr 0
la 9,puts_long@l(9)
lis 3,.LC0@ha
stw 0,12(1)
la 3,.LC0@l(3)
mtctr 9
bctrl
lwz 0,12(1)
addi 1,1,8
mtlr 0
blr
.size   bar_long, .-bar_long
.align 2
.globl bar_short
.type   bar_short, @function
bar_short:
lis 3,.LC0@ha
la 3,.LC0@l(3)
b puts_short
.size   bar_short, .-bar_short
.section.rodata.str1.4,"aMS",@progbits,1
.align 2
.LC0:
.string " "
.ident  "GCC: (GNU) 6.0.0 20160121 (experimental)"

Re: new port: vn8

[Sandra Loosemore]

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.


-Sandra

[Bug tree-optimization/69522] New: gcc hangs on valid code on x86_64-linux-gnu

[helloqirun at gmail dot com]

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

Bug ID: 69522
   Summary: gcc hangs on valid code on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The current gcc trunk hangs on the following valid code snippets on
x86_64-linux-gnu in both 32-bit and 64-bit modes.

I assume the code snippets are valid since both gcc-4.4 and clang-trunk compile
them. gcc-4.4 and clang-trunk generate no warning for the first code snippet.
The second one is essentially the same as the first one having the line control
removed.

I tested them for gcc-4.6, gcc-4.8, gcc-4.9, gcc-5.1, gcc-5.2 and gcc-5.3. Only
gcc-4.8 got an ICE for "abc2.c", the others were just hanging.


$ gcc-4.4 -Wall -Wextra abc1.c -c
$ clang-trunk -Wall -Wextra -Wpedantic abc1.c -c
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160127 (experimental) [trunk revision 232874] (GCC) 


$ time gcc-trunk abc1.c
^C

real21m50.378s
user0m0.000s
sys 0m0.002s



$ cat abc1.c
# 1 "" 3
struct str {};
struct {
  struct str b;
  float c[4];
  int d;
  float e[2];
  int f;
} a = {{}, 0, 0, 0, 0, {0.5}, 0, 0, {0}};





$ time gcc-trunk abc2.c
abc.c:8:1: warning: braces around scalar initializer
 } a = {{}, 0, 0, 0, 0, {0.5}, 0, 0, {0}};
 ^
abc.c:8:1: note: (near initialization for ‘a.d’)
abc.c:8:1: warning: braces around scalar initializer
abc.c:8:1: note: (near initialization for ‘a.f’)
^C

real14m22.631s
user0m0.000s
sys 0m0.002s


$ gcc-4.8 abc2.c
abc.c:8:1: warning: braces around scalar initializer [enabled by default]
 } a = {{}, 0, 0, 0, 0, {0.5}, 0, 0, {0}};
 ^
abc.c:8:1: warning: (near initialization for ‘a.d’) [enabled by default]
abc.c:8:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccVkQrfE.out file, please attach this to
your bugreport.


$cat abc2.c
struct str {};
struct {
  struct str b;
  float c[4];
  int d;
  float e[2];
  int f;
} a = {{}, 0, 0, 0, 0, {0.5}, 0, 0, {0}};

Re: new port: vn8

[Bernhard Reutner-Fischer]

On January 27, 2016 8:47:15 PM GMT+01:00, Mike Stump  
wrote:
>On Jan 26, 2016, at 10:33 PM, Nguyễn Sinh Ngọc
> wrote:
>> I wonder that what paper is?
>> Is it an introduction about new feature in our target?
>
>I was not able to make any sense of these two question.  Likely a
>language barrier.  If you can find a way to rephrase them…  I can try
>and answer.

I guess gcc.gnu.org/contribute.html#legal

I.e. copyright assignment.

HTH,

[Bug target/23450] local functions should not sign extend results (and arguments) for speed reasons

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||carrot at google dot com

--- Comment #4 from Martin Sebor  ---
*** Bug 65010 has been marked as a duplicate of this bug. ***

[Bug target/65010] ppc backend generates unnecessary signed extension

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Last reconfirmed|2015-03-21 00:00:00 |2016-1-27
 Resolution|--- |DUPLICATE
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #5 from Martin Sebor  ---
This is a duplicate of 23450.

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

Re: new port: vn8

[Nguyễn Sinh Ngọc]

> 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 & Best regards
Nguyễn Sinh Ngọc
Software Department
IC Design & Research Education Center
Email: ngoc.nguyens...@icdrec.edu.vn
Cell Phone: +84 (0)974117946

[Bug c++/69523] -Wliteral-suffix should not warn within namespace std

[eric at efcs dot ca]

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

--- Comment #2 from Eric Fiselier  ---
@Andrew I'm a libc++ developer and I really like using compiler warnings when
developing and testing libc++. Using -isystem prevents this entirely. Normally
they are system headers but this is explicitly turned off during development.

[Bug target/23450] local functions should not sign extend results (and arguments) for speed reasons

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2007-07-01 00:47:09 |2016-1-27
 CC||msebor at gcc dot gnu.org
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #3 from Martin Sebor  ---
Even though the generated code has changed, this is still a problem with 6.0
and in all supported versions prior to it as noted in bug 65010, for both
powerpc64 and powerpc64le, where GCC emits:

f:
addi 3,3,1
extsw 3,3
blr

g:
addi 3,3,1
extsw 3,3
b f

[Bug target/69461] [6 Regression] ICE in lra_set_insn_recog_data, at lra.c:964

[aoliva at gcc dot gnu.org]

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

--- Comment #6 from Alexandre Oliva  ---
Created attachment 37498
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37498=edit
Patch I'm testing to fix the bug

LRA wants harder than reload to avoid creating a stack slot to satisfy insn
constraints.  As a result, it creates an additional REG:TI pseudo to reload a
SUBREG:V2DF of a REG:TI, and then it tries to assign that pseudo to VSX_REGS,
which in turn causes another reload because there's no way to load a TImode
value into a VSX_REG in *mov_ppc64, and that requires another, and so on,
until the limit on reload insns is exceeded.

The first problem is that we shouldn't be creating a TImode reload for
VSX_REGS, since we can't possibly satisfy that: TImode values are not ok for
VSX_REGS.  I've adjusted in_class_p to check HARD_REGNO_MODE_OK, and that put
an end to infinite stream of reloads.

It was still a very long stream, though.  simplify_operand_subreg attempts to
turn SUBREGs of MEMs into MEMs, but it will only proceed with the
simplification if the resulting address is at least as valid as the original.  

Alas, instead of the simplification, we end up repeatedly generating reloads
copying the initial value to stack slots with growing offsets, until the offset
grows enough that the address becomes invalid, at which point the subreg
simplification is performed.  That's 2047 excess stores and loads, plus insns
that compute the stack address for each of them.

In order to fix that, I amended the test on whether to proceed with the subreg
simplification to take into account the availability of regs that can hold a
value of the intended mode in the goal class for that operand.

With that, we go from 2047 excess stores and loads to only 1.  I couldn't
figure out yet how to get rid of this one extra store and load, and the excess
stack slot, but I figured I'd share what I have, that I believe to be a solid
fix, and save the investigation on an additional LRA improvement for later.

Re: new port: vn8

[Nguyễn Sinh Ngọc]

> If you don’t have your paper work done, you will want to start up that 
> process now.  The port can’t go into the compiler without it.

What is the paper?
Can you explain more about it?

On Thu, Jan 28, 2016 at 2:47 AM, Mike Stump  wrote:
> On Jan 26, 2016, at 10:33 PM, Nguyễn Sinh Ngọc 
>  wrote:
>> I wonder that what paper is?
>> Is it an introduction about new feature in our target?
>
> I was not able to make any sense of these two question.  Likely a language 
> barrier.  If you can find a way to rephrase them…  I can try and answer.



-- 
Thanks & Best regards
Nguyễn Sinh Ngọc
Software Department
IC Design & Research Education Center
Email: ngoc.nguyens...@icdrec.edu.vn
Cell Phone: +84 (0)974117946

[Bug target/22271] No builtin preprocessing defines to tell SDATA mode.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
This enhancement request has a patch but it's over 10 years old.  Is it still
applicable/worthwhile applying?  If so, Sergei, can you post it to gcc-patches?
 If not, should it be closed as WONTFIX?

[Bug tree-optimization/22226] vectorization library

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #5 from David Edelsohn  ---
This is still of interest.

Re: new port: vn8

[Sandra Loosemore]

Where is the patch under discussion here?  I can't find it in the archives.

-Sandra

[Bug target/18154] Inefficient max/min code for PowerPC

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||wschmidt at gcc dot gnu.org

--- Comment #8 from David Edelsohn  ---
Branchless code generally is better.

[Bug debug/21913] REG_EXPR wrong for parameters passed by invisible reference

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
It looks to me like this isn't a problem anymore but my DAWRF-fu is weak to
tell for sure.  Jakub, can you please confirm whether or not this has been
fixed?

Re: [PATCH] add test for target/17381 - Unnecessary register move for float extend

[David Edelsohn]

On Wed, Jan 27, 2016 at 5:38 PM, Martin Sebor  wrote:
> The attached patch adds a test for the apparently long fixed
> bug.
>
> FWIW, I've been trying to close out some of these old bugs and
> while it doesn't seem to be done consistently, it occurs to me
> that it might be nice to add tests for them.  Please let me
> know if you don't think it's worth the trouble (not just mine
> but also reviewing the tests and maintaining them).

Assuming this passes, the additional test is okay.

Thanks, David

Re: [PATCH, PR target/69454] Disable TARGET_STV when stack is not properly aligned

[H.J. Lu]

On Wed, Jan 27, 2016 at 8:36 AM, H.J. Lu  wrote:
> On Wed, Jan 27, 2016 at 8:29 AM, Ilya Enkovich  wrote:
>> 2016-01-27 19:18 GMT+03:00 H.J. Lu :
>>> On Wed, Jan 27, 2016 at 8:11 AM, Ilya Enkovich  
>>> wrote:
 On 27 Jan 16:44, Jakub Jelinek wrote:
> On Wed, Jan 27, 2016 at 06:34:41PM +0300, Ilya Enkovich wrote:
> > @@ -5453,6 +5443,11 @@ ix86_option_override_internal (bool main_args_p,
> >  opts->x_target_flags |= MASK_VZEROUPPER;
> >if (!(opts_set->x_target_flags & MASK_STV))
> >  opts->x_target_flags |= MASK_STV;
> > +  /* Disable STV if -mpreferred-stack-boundary={2,3} - the needed
>
> The comment doesn't match the code, you disable STV only for
> -mpreferred-stack-boundary=2.

 Thanks, here is an updated version.

 Ilya
 --
 gcc/

 2016-01-27  Jakub Jelinek  
 Ilya Enkovich  

 PR target/69454
 * config/i386/i386.c (convert_scalars_to_vector): Remove
 stack alignment fixes.
 (ix86_option_override_internal): Disable TARGET_STV if stack
 is not properly aligned.

 gcc/testsuite/

 2016-01-27  Ilya Enkovich  

 PR target/69454
 * gcc.target/i386/pr69454-1.c: New test.
 * gcc.target/i386/pr69454-2.c: New test.


 diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
 index 34b57a4..9fb8db8 100644
 --- a/gcc/config/i386/i386.c
 +++ b/gcc/config/i386/i386.c
 @@ -3588,16 +3588,6 @@ convert_scalars_to_vector ()
bitmap_obstack_release (NULL);
df_process_deferred_rescans ();

 -  /* Conversion means we may have 128bit register spills/fills
 - which require aligned stack.  */
 -  if (converted_insns)
 -{
 -  if (crtl->stack_alignment_needed < 128)
 -   crtl->stack_alignment_needed = 128;
 -  if (crtl->stack_alignment_estimated < 128)
 -   crtl->stack_alignment_estimated = 128;
 -}
 -
return 0;
  }

 @@ -5453,6 +5443,11 @@ ix86_option_override_internal (bool main_args_p,
  opts->x_target_flags |= MASK_VZEROUPPER;
if (!(opts_set->x_target_flags & MASK_STV))
  opts->x_target_flags |= MASK_STV;
 +  /* Disable STV if -mpreferred-stack-boundary=2 - the needed
 + stack realignment will be extra cost the pass doesn't take into
 + account and the pass can't realign the stack.  */
 +  if (ix86_preferred_stack_boundary < 64)
 +opts->x_target_flags &= ~MASK_STV;

This won't work for 32-bit incoming stack boundary and 64-bit preferred
stack boundary.  In this case, STV won't be off.  When LRA needs 64-bit
aligned stack slot, stack must be realigned.  But for leaf function, we may
not realign stack if ix86_minimum_alignment returns 32 for DImode.   You
must either add assert (!TARGET_STV) before returning 32 for DImode or
return 64 for DImode if STV is on in ix86_minimum_alignment.

if (!ix86_tune_features[X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL]
&& !(opts_set->x_target_flags & MASK_AVX256_SPLIT_UNALIGNED_LOAD))
  opts->x_target_flags |= MASK_AVX256_SPLIT_UNALIGNED_LOAD;
>>>
>>> MINIMUM_ALIGNMENT keeps track stack alignment.  It is OK
>>> to disable STV for -mpreferred-stack-boundary=2.  But you should
>>> also update ix86_minimum_alignment to make sure that STV is
>>> disabled before returning 32 for DImode.
>>
>> If -mpreferred-stack-boundary=2 then STV is disabled, if STV is enabled then
>> -mpreferred-stack-boundary>=3 and this condition in
>> ix86_minimum_alignment works:
>>
>>   if (TARGET_64BIT || align != 64 || ix86_preferred_stack_boundary >= 64)
>> return align;
>>
>
> No, you shouldn't make assumptions in ix86_minimum_alignment. You
> should check explicitly that STV is disabled in ix86_minimum_alignment.
>
>
> --
> H.J.



-- 
H.J.

Re: [PATCH] Low-hanging C++-lexer speedup (PR c++/24208)

[Patrick Palka]

On Wed, Jan 27, 2016 at 4:33 PM, Jason Merrill  wrote:
> On 01/25/2016 11:45 PM, Patrick Palka wrote:
>>
>> +/* This needs to be set to TRUE before the lexer-debugging infrastructure
>> can
>> +   be used.  The point of this flag is to help the compiler to fold away
>> calls
>> +   to cp_lexer_debugging_p within this source file at compile time, when
>> the
>> +   lexer is not being debugged.  */
>> +
>> +#define LEXER_DEBUGGING_ENABLED_P false
>
>
> I wonder about using an existing flag, such as CHECKING_P, but I guess this
> is OK too.

The way I look at it is that you need to deliberately add calls to
cp_lexer_[start|stop]_debugging in parser.c in order to make use of
the lexer debugging stuff anyway, so it's not too invasive to guard
this functionality behind a distinct flag that needs to be manually
toggled within parser.c.  And it is nice to avoid this overhead even
when CHECKING_P, to provide a minor speed-up in bootstrap times and
stuff.

[Bug target/18900] Don't use fp regs for mem moves without explicit use of fp

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||msebor at gcc dot gnu.org

--- Comment #7 from Martin Sebor  ---
I haven't been able to reproduce the use of floating point registers in struct
copying with any of my compilers or cross-compilers.  Is there test case that
shows that the problem still exists?

Re: [Patch, fortran, GCC-5/6, PR62536, v1] ICE (segfault) for invalid END BLOCK statement

[Jerry DeLisle]

On 01/27/2016 08:25 AM, Andre Vehreschild wrote:
> Hi all,
> 
> attached are two patches one for trunk and one for the gcc-5-branch,
> which fix an ICE when BLOCK statements are not closed correctly (too
> many END BLOCKs). Unfortunately did the patch I tailored for gcc-5 not
> work on trunk.
> 
> GCC 5: The ICE is prevented by making sure that gfc_current_ns is not
> set to NULL, when too many closing END BLOCK statements are found. This
> may lead to gfortran be in the wrong namespace, but gfortran is already
> in error. Therefore this does not matter any more. We just need to exit
> cleanly.
> 
> GCC 6/trunk: Here the ICE is prevented by making sure, that unnesting
> of BLOCK namespaces is only done, when the END encountered is not the
> one of a BLOCK. This prevents gfortran from removing a correctly
> initialized and for further analysis required namespace.
> 
> Bootstrapped and regtested ok on x86_64-linux-gnu/F23. 
> 
> Ok for trunk and gcc-5-branch, respectively?
> 

OK and thanks for fixes. Much appreciated?

Jerry

Re: [PATCH 1/4] Make SRA scalarize constant-pool loads

[David Edelsohn]

On Wed, Jan 27, 2016 at 6:36 PM, Jeff Law  wrote:
> On 01/27/2016 12:39 PM, David Edelsohn wrote:
>>
>> The new sra-17.c and sra-18.c tests fail on AIX because the regex is
>> too restrictive -- AIX labels don't have exactly the same format.  On
>> AIX, the labels in the dumps look like "LC..0" instead of ".LC0".
>>
>> This patch adds "*" and ".*" so that the "." prepended to LC is
>> optional and to allow characters between the "LC" and the "0".
>>
>> I needed extra escapes for the sra-17.c line that matches multiple
>> times - for no apparent reason.
>
> The joys of expect/tcl.  I just keep escaping until the regex that I
> developed outside the suite works.  I have been trying to get away from
> using .* though.  The longest match nature sometimes gives surprising
> results.  In theory .*? ought to work better, but I haven't tried using it
> much.
>
> Anyway, the change looks fine to me.

Segher pointed out to me that my revised regex was matching multiple
lines, so it was not triggering multiple times without the restriction
on the pattern.

A revised, tighter patch uses "?"

Index: sra-17.c
===
--- sra-17.c(revision 232904)
+++ sra-17.c(working copy)
@@ -15,5 +15,5 @@
   abort ();
 }

-/* { dg-final { scan-tree-dump-times "Removing load: a = \\\*.LC0;" 1
"esra" } } */
-/* { dg-final { scan-tree-dump-times "SR.\[0-9_\]+ = \\\*.LC0\\\[" 4
"esra" } } */
+/* { dg-final { scan-tree-dump-times "Removing load: a =
\\\*\\.?LC\\.?\\.?0;" 1 "esra" } } */
+/* { dg-final { scan-tree-dump-times "SR\\.\[0-9_\]+ =
\\\*\\.?LC\\.?\\.?0\\\[" 4 "esra" } } */
Index: sra-18.c
===
--- sra-18.c(revision 232904)
+++ sra-18.c(working copy)
@@ -21,8 +21,8 @@
   abort ();
 }

-/* { dg-final { scan-tree-dump-times "Removing load: a = \\\*.LC0;" 1
"esra" } } */
-/* { dg-final { scan-tree-dump-times "SR.\[0-9_\]+ =
\\\*.LC0\\.b\\\[0\\\]\\.f\\\[0\\\]\\.x" 1 "esra" } } */
-/* { dg-final { scan-tree-dump-times "SR.\[0-9_\]+ =
\\\*.LC0\\.b\\\[0\\\]\\.f\\\[1\\\]\\.x" 1 "esra" } } */
-/* { dg-final { scan-tree-dump-times "SR.\[0-9_\]+ =
\\\*.LC0\\.b\\\[1\\\]\\.f\\\[0\\\]\\.x" 1 "esra" } } */
-/* { dg-final { scan-tree-dump-times "SR.\[0-9_\]+ =
\\\*.LC0\\.b\\\[1\\\]\\.f\\\[1\\\]\\.x" 1 "esra" } } */
+/* { dg-final { scan-tree-dump-times "Removing load: a =
\\\*\\.?LC\\.?\\.?0;" 1 "esra" } } */
+/* { dg-final { scan-tree-dump-times "SR\\.\[0-9_\]+ =
\\\*\\.?LC\\.?\\.?0\\.b\\\[0\\\]\\.f\\\[0\\\]\\.x" 1 "esra" } } */
+/* { dg-final { scan-tree-dump-times "SR\\.\[0-9_\]+ =
\\\*\\.?LC\\.?\\.?0\\.b\\\[0\\\]\\.f\\\[1\\\]\\.x" 1 "esra" } } */
+/* { dg-final { scan-tree-dump-times "SR\\.\[0-9_\]+ =
\\\*\\.?LC\\.?\\.?0\\.b\\\[1\\\]\\.f\\\[0\\\]\\.x" 1 "esra" } } */
+/* { dg-final { scan-tree-dump-times "SR\\.\[0-9_\]+ =
\\\*\\.?LC\\.?\\.?0\\.b\\\[1\\\]\\.f\\\[1\\\]\\.x" 1 "esra" } } */

[testsuite] XFAIL gcc.dg/tree-ssa/ssa-dom-cse-2.c on SPARC 64-bit

[Eric Botcazou]

For the same reason as on Alpha and PowerPC 64-bit.

Tested on x86-64/Linux and SPARC64/Solaris, applied on the mainline.


2016-01-27  Eric Botcazou  

* gcc.dg/tree-ssa/ssa-dom-cse-2.c: XFAIL on SPARC 64-bit.

-- 
Eric BotcazouIndex: gcc.dg/tree-ssa/ssa-dom-cse-2.c
===
--- gcc.dg/tree-ssa/ssa-dom-cse-2.c	(revision 232773)
+++ gcc.dg/tree-ssa/ssa-dom-cse-2.c	(working copy)
@@ -21,4 +21,4 @@ foo ()
but the loop reads only one element at a time, and DOM cannot resolve these.
The same happens on powerpc depending on the SIMD support available.  */
 
-/* { dg-final { scan-tree-dump "return 28;" "optimized" { xfail alpha*-*-* powerpc64*-*-* } } } */
+/* { dg-final { scan-tree-dump "return 28;" "optimized" { xfail { { alpha*-*-* powerpc64*-*-* } || { sparc*-*-* && lp64 } } } } } */

[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation

[rguenther at suse dot de]

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

--- Comment #22 from rguenther at suse dot de  ---
On Tue, 26 Jan 2016, afomin.mailbox at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
> 
> --- Comment #21 from Alexander Fomin  ---
> (In reply to Richard Biener from comment #18)
> > Heh.  What about testcases?
> We don't have a reproducer yet, but I can provide any RTL dumps immediately 
> (of
> course).

Can you simply attach preprocessed source of the relevant file?

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

[Marc Glisse]

On Tue, 26 Jan 2016, H.J. Lu wrote:


On Tue, Jan 26, 2016 at 1:40 PM, Jakub Jelinek  wrote:

On Tue, Jan 26, 2016 at 01:21:52PM -0800, H.J. Lu wrote:

Like this:

/* Returns true if TYPE is POD for the purpose of layout and an empty
   class or an class with empty classes.  */

static bool
is_empty_record (tree type)
{
  if (type == error_mark_node)
return false;

  if (!CLASS_TYPE_P (type))
return false;

  if (CLASSTYPE_NON_LAYOUT_POD_P (type))
return false;

  gcc_assert (COMPLETE_TYPE_P (type));

  if (CLASSTYPE_EMPTY_P (type))
return true;

  tree field;

  for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
if (TREE_CODE (field) == FIELD_DECL
&& !DECL_ARTIFICIAL (field)
&& !is_empty_record (TREE_TYPE (field)))
  return false;

  return true;
}


So you say that K1 in e.g.:

struct A1 {}; struct A2 {};
struct B1 { A1 a; A2 b; }; struct B2 { A1 a; A2 b; };
struct C1 { B1 a; B2 b; }; struct C2 { B1 a; B2 b; };
struct D1 { C1 a; C2 b; }; struct D2 { C1 a; C2 b; };
struct E1 { D1 a; D2 b; }; struct E2 { D1 a; D2 b; };
struct F1 { E1 a; E2 b; }; struct F2 { E1 a; E2 b; };
struct G1 { F1 a; F2 b; }; struct G2 { F1 a; F2 b; };
struct H1 { G1 a; G2 b; }; struct H2 { G1 a; G2 b; };
struct I1 { H1 a; H2 b; }; struct I2 { H1 a; H2 b; };
struct J1 { I1 a; I2 b; }; struct J2 { I1 a; I2 b; };
struct K1 { J1 a; J2 b; };
int v;
__attribute__((noinline, noclone))
K1 foo (int a, K1 x, int b)
{
  v = a + b;
  return x;
}
K1 k, m;
void
bar (void)
{
  m = foo (1, k, 2);
}

is empty class?  What does clang do with this?

Jakub


Revised:

/* Returns true if TYPE is POD of one-byte or less in size for the purpose
  of layout and an empty class or an class with empty classes.  */

static bool
is_empty_record (tree type)
{
 if (type == error_mark_node)
   return false;

 if (!CLASS_TYPE_P (type))
   return false;

 if (CLASSTYPE_NON_LAYOUT_POD_P (type))
   return false;

 gcc_assert (COMPLETE_TYPE_P (type));

 if (CLASSTYPE_EMPTY_P (type))
   return true;

 if (int_size_in_bytes (type) > 1)
   return false;


That's completely arbitrary :-(

If we are defining a new ABI, I preferred your previous version (at least 
the idea, I didn't check the code). If we are trying to follow clang, then 
we need either a clear English definition from a clang developer or at 
least someone should check what conditions they use in the code. Trying to 
infer it from a couple examples sounds too fragile for an ABI decision.



 tree field;

 for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
   if (TREE_CODE (field) == FIELD_DECL
   && !DECL_ARTIFICIAL (field)
   && !is_empty_record (TREE_TYPE (field)))
 return false;

 return true;
}


--
Marc Glisse

Re: [PATCH] Fix PR69336

[Eric Botcazou]

> The new test case fails on s390x:

Likewise on SPARC 32-bit and 64-bit.

-- 
Eric Botcazou

[Bug jit/69490] jit testsuite failures (segmentation fault) on x86_64-unknown-linux-gnu

[rai...@emrich-ebersheim.de]

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

--- Comment #3 from Rainer Emrich  ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am 26.01.2016 um 16:08 schrieb Rainer Emrich:
> Am 26.01.2016 um 15:50 schrieb dmalcolm at gcc dot gnu.org:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69490
> 
>> --- Comment #1 from David Malcolm  
>> --- Thanks for reporting this.
> 
>> Which exact version are you testing with?  This looks a lot like
>> PR 68446, which was fixed in r232567.
> 
> Ok, I'm a little bit behind, that's rev. 232504. I will retest
> with current trunk!

I confirm, revision 232832 doesn't have the issue.
I mark this as duplicate of pr68446.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWqHx/AAoJEB3HOsWs+KJbmqYH/3fNkJQuBeALQtmMNXKkM8EM
5FAOgykAFDQQhmodoXt2kE+MdzlOdWefoKTySEsxy+qfHK3kXpxgmw8RN3Ir19++
KMXGZAla6836UU7UEZYxwd0Xt7pxukQ7HqGxOBzxrivh6ntT6BwLV2qZRR3emkmm
PM+l17UlgJfB9x2LfTxq8C7nzAnoBm8vV3KHdpNeiWS7kwm6xB63M2MOlfK/PW/q
4SlzzPjrUNKwNGbp4bkVkVhz13XD13lSQvYNnvb20vadWCu89Q5Zko5cwmhdwhFB
ZYYs/uyL58cW7omrRCo6eEH5/leX9xvwcUJ6ar2f19UgTcd5AgLH0gvq5U9ZWOw=
=qbY3
-END PGP SIGNATURE-

[Bug tree-optimization/69336] Constant value not detected

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Should be fixed with

2016-01-25  Richard Biener  

PR testsuite/69380
* g++.dg/tree-ssa/pr69336.C: Restrict to x86_64 and i?86.

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

[Jakub Jelinek]

On Wed, Jan 27, 2016 at 09:10:14AM +0100, Marc Glisse wrote:
> >Revised:
> >
> >/* Returns true if TYPE is POD of one-byte or less in size for the purpose
> >  of layout and an empty class or an class with empty classes.  */
> >
> >static bool
> >is_empty_record (tree type)
> >{
> > if (type == error_mark_node)
> >   return false;
> >
> > if (!CLASS_TYPE_P (type))
> >   return false;
> >
> > if (CLASSTYPE_NON_LAYOUT_POD_P (type))
> >   return false;
> >
> > gcc_assert (COMPLETE_TYPE_P (type));
> >
> > if (CLASSTYPE_EMPTY_P (type))
> >   return true;
> >
> > if (int_size_in_bytes (type) > 1)
> >   return false;
> 
> That's completely arbitrary :-(

Yeah.  Because (adapted to be compilable with C):
struct A1 {}; struct A2 {};
struct B1 { struct A1 a; struct A2 b; }; struct B2 { struct A1 a; struct A2 b; 
};
struct C1 { struct B1 a; struct B2 b; }; struct C2 { struct B1 a; struct B2 b; 
};
struct D1 { struct C1 a; struct C2 b; }; struct D2 { struct C1 a; struct C2 b; 
};
struct E1 { struct D1 a; struct D2 b; }; struct E2 { struct D1 a; struct D2 b; 
};
struct F1 { struct E1 a; struct E2 b; }; struct F2 { struct E1 a; struct E2 b; 
};
struct G1 { struct F1 a; struct F2 b; }; struct G2 { struct F1 a; struct F2 b; 
};
struct H1 { struct G1 a; struct G2 b; }; struct H2 { struct G1 a; struct G2 b; 
};
struct I1 { struct H1 a; struct H2 b; }; struct I2 { struct H1 a; struct H2 b; 
};
struct J1 { struct I1 a; struct I2 b; }; struct J2 { struct I1 a; struct I2 b; 
};
struct K1 { struct J1 a; struct J2 b; };
int v;
__attribute__((noinline, noclone))
struct K1 foo (int a, struct K1 x, int b)
{
  v = a + b;
  return x;
}
struct K1 k, m;
void
bar (void)
{
  m = foo (1, k, 2);
}
then would have a different calling convention between C and C++,
so where is the argument that we change anything just to make the two
compatible?  Though, of course, those two will never be compatible,
it is enough to add struct L1 { int a; struct K1 b; int c; }; and
that structure has 1024+8 bytes in C++ and 8 bytes in C.
As clang generates different code for the above between C and C++, it
clearly special cases for some reason just the most common case.
IMHO it is not worth to change GCC ABI...

Jakub

[Bug tree-optimization/69466] [6 Regression] ICE: Invalid PHI argument after vectorization (on -O2)

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
Created attachment 37486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37486=edit
Patch I'm testing to fix the problem

The problem occurs because we call set_current_def for phi nodes after
duplicating some blocks, but it isn't always the case that the blocks passed to
slpeel_duplicate_current_defs_from_edges were copied from one another.  In the
given testcase, the exit blocks passed to this function don't seem to be
related at all, so taking information from corresponding phi nodes to call
set_current_def is most certainly incorrect.  Indeed, it's calling
set_current_def for a virtual operand from a "corresponding" non-virtual
operand that causes slpeel_duplicate_current_defs_from_edges's use of
get_current_def to set up an incorrect, non-virtual value for the
virtual-operand phi node.  With this patch, we refrain from setting current
defs when blocks don't have analogous phi nodes, and this is enough to address
the problem.

It would be nice, however, if someone more familiar with the loop vectorizer
would check whether our calling this function with mismatched blocks indicates
another latent problem, or whether we could check for the mismatch and bypass
the call more efficiently at the caller.  For this testcase, the mismatching
call is the single_exit (scalar_loop) one in
slpeel_tree_duplicate_loop_to_edge_cfg.

[Bug jit/69490] jit testsuite failures (segmentation fault) on x86_64-unknown-linux-gnu

[rai...@emrich-ebersheim.de]

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

Rainer Emrich  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Rainer Emrich  ---
Marked as duplicate of PR68446, which is solved in r232567.

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

[Bug jit/68446] [6 Regression] jit testsuite failures seen inside dwarf2out.c:gen_producer_string

[rai...@emrich-ebersheim.de]

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

Rainer Emrich  changed:

   What|Removed |Added

 CC||rai...@emrich-ebersheim.de

--- Comment #9 from Rainer Emrich  ---
*** Bug 69490 has been marked as a duplicate of this bug. ***

[PATCH, PR target/69454] Disable TARGET_STV when stack is not properly aligned

[Ilya Enkovich]

Hi,

Currently STV pass may require a stack realignment if any
transformation occurs to enable SSE registers spill/fill.
It appears it's invalid to increase stack alignment requirements
at this point.  Thus we have to either assume we need stack to be
aligned if are going to run STV pass or disable STV if stack is
not properly aligned.  I suppose we shouldn't ignore explicitly
requested stack alignment not beeing sure we really optimize
anything (and STV is not an optimization frequiently applied).
So I think we may disable TARGET_STV for such cases as Jakub
suggested.  This patch was bootstrapped and regtested on
x86_64-pc-linux-gnu.  OK for trunk?

Thanks,
Ilya
--
gcc/

2016-01-27  Jakub Jelinek  
Ilya Enkovich  

PR target/69454
* config/i386/i386.c (convert_scalars_to_vector): Remove
stack alignment fixes.
(ix86_option_override_internal): Disable TARGET_STV if stack
is not properly aligned.

gcc/testsuite/

2016-01-27  Ilya Enkovich  

PR target/69454
* gcc.target/i386/pr69454-1.c: New test.
* gcc.target/i386/pr69454-2.c: New test.


diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 34b57a4..9fb8db8 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3588,16 +3588,6 @@ convert_scalars_to_vector ()
   bitmap_obstack_release (NULL);
   df_process_deferred_rescans ();
 
-  /* Conversion means we may have 128bit register spills/fills
- which require aligned stack.  */
-  if (converted_insns)
-{
-  if (crtl->stack_alignment_needed < 128)
-   crtl->stack_alignment_needed = 128;
-  if (crtl->stack_alignment_estimated < 128)
-   crtl->stack_alignment_estimated = 128;
-}
-
   return 0;
 }
 
@@ -5453,6 +5443,11 @@ ix86_option_override_internal (bool main_args_p,
 opts->x_target_flags |= MASK_VZEROUPPER;
   if (!(opts_set->x_target_flags & MASK_STV))
 opts->x_target_flags |= MASK_STV;
+  /* Disable STV if -mpreferred-stack-boundary={2,3} - the needed
+ stack realignment will be extra cost the pass doesn't take into
+ account and the pass can't realign the stack.  */
+  if (ix86_preferred_stack_boundary < 64)
+opts->x_target_flags &= ~MASK_STV;
   if (!ix86_tune_features[X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL]
   && !(opts_set->x_target_flags & MASK_AVX256_SPLIT_UNALIGNED_LOAD))
 opts->x_target_flags |= MASK_AVX256_SPLIT_UNALIGNED_LOAD;
diff --git a/gcc/testsuite/gcc.target/i386/pr69454-1.c 
b/gcc/testsuite/gcc.target/i386/pr69454-1.c
new file mode 100644
index 000..12ecfd3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr69454-1.c
@@ -0,0 +1,11 @@
+/* { dg-do compile { target { ia32 } } } */
+/* { dg-options "-O2 -msse2 -mno-accumulate-outgoing-args 
-mpreferred-stack-boundary=2" } */
+
+typedef struct { long long w64[2]; } V128;
+extern V128* fn2(void);
+long long a;
+V128 b;
+void fn1() {
+  V128 *c = fn2();
+  c->w64[0] = a ^ b.w64[0];
+}
diff --git a/gcc/testsuite/gcc.target/i386/pr69454-2.c 
b/gcc/testsuite/gcc.target/i386/pr69454-2.c
new file mode 100644
index 000..28bab93
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr69454-2.c
@@ -0,0 +1,13 @@
+/* { dg-do compile { target { ia32 } } } */
+/* { dg-options "-O2 -mpreferred-stack-boundary=2" } */
+
+extern void fn2 ();
+long long a, b;
+
+void fn1 ()
+{
+  long long c = a;
+  a = b ^ a;
+  fn2 ();
+  a = c;
+}

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

[H.J. Lu]

On Wed, Jan 27, 2016 at 5:46 AM, H.J. Lu  wrote:
> On Wed, Jan 27, 2016 at 1:03 AM, Marc Glisse  wrote:
>> On Wed, 27 Jan 2016, Jakub Jelinek wrote:
>>
>>> On Wed, Jan 27, 2016 at 09:10:14AM +0100, Marc Glisse wrote:
>
> Revised:
>
> /* Returns true if TYPE is POD of one-byte or less in size for the
> purpose
>  of layout and an empty class or an class with empty classes.  */
>
> static bool
> is_empty_record (tree type)
> {
> if (type == error_mark_node)
>   return false;
>
> if (!CLASS_TYPE_P (type))
>   return false;
>
> if (CLASSTYPE_NON_LAYOUT_POD_P (type))
>   return false;
>
> gcc_assert (COMPLETE_TYPE_P (type));
>
> if (CLASSTYPE_EMPTY_P (type))
>   return true;
>
> if (int_size_in_bytes (type) > 1)
>   return false;


 That's completely arbitrary :-(
>>>
>>>
>>> Yeah.  Because (adapted to be compilable with C):
>>> struct A1 {}; struct A2 {};
>>> struct B1 { struct A1 a; struct A2 b; }; struct B2 { struct A1 a; struct
>>> A2 b; };
>>> struct C1 { struct B1 a; struct B2 b; }; struct C2 { struct B1 a; struct
>>> B2 b; };
>>> struct D1 { struct C1 a; struct C2 b; }; struct D2 { struct C1 a; struct
>>> C2 b; };
>>> struct E1 { struct D1 a; struct D2 b; }; struct E2 { struct D1 a; struct
>>> D2 b; };
>>> struct F1 { struct E1 a; struct E2 b; }; struct F2 { struct E1 a; struct
>>> E2 b; };
>>> struct G1 { struct F1 a; struct F2 b; }; struct G2 { struct F1 a; struct
>>> F2 b; };
>>> struct H1 { struct G1 a; struct G2 b; }; struct H2 { struct G1 a; struct
>>> G2 b; };
>>> struct I1 { struct H1 a; struct H2 b; }; struct I2 { struct H1 a; struct
>>> H2 b; };
>>> struct J1 { struct I1 a; struct I2 b; }; struct J2 { struct I1 a; struct
>>> I2 b; };
>>> struct K1 { struct J1 a; struct J2 b; };
>>> int v;
>>> __attribute__((noinline, noclone))
>>> struct K1 foo (int a, struct K1 x, int b)
>>> {
>>>  v = a + b;
>>>  return x;
>>> }
>>> struct K1 k, m;
>>> void
>>> bar (void)
>>> {
>>>  m = foo (1, k, 2);
>>> }
>>> then would have a different calling convention between C and C++,
>>> so where is the argument that we change anything just to make the two
>>> compatible?  Though, of course, those two will never be compatible,
>>> it is enough to add struct L1 { int a; struct K1 b; int c; }; and
>>> that structure has 1024+8 bytes in C++ and 8 bytes in C.
>>
>>
>> I don't know how empty classes are used in C in practice, but it could make
>> sense to have ABI compatibility as long as no empty struct is used as a
>> member of another struct (I also suggested an attribute to let C++ use the
>> same layout as C here: PR63579). But then the usual definition of empty
>> would be sufficient.
>>
>>> As clang generates different code for the above between C and C++, it
>>> clearly special cases for some reason just the most common case.
>>> IMHO it is not worth to change GCC ABI...
>>
>>
>> I was interested in this change because it improves C++, C compatibility was
>> a convenient excuse ;-)
>>
>
> I opened  a clang bug:
>
> https://llvm.org/bugs/show_bug.cgi?id=26337
>
> I propose the following definitions:
>
> i. An empty record is:
>1. A class without member.  Or
>2. An array of empty records.  Or
>3. A class with empty records.
> ii. An empty record type for parameter passing is POD for the purpose of 
> layout
> and
>1. A class without member.  Or
>2. A class with empty records.
>
> /* An empty record is:
>1. A class without member.  Or
>2. An array of empty records.  Or
>3. A class with empty records.  */
>
> /* Returns true if TYPE is an empty record or an array of empty records.  */
>
> static bool
> is_empty_record_or_array_of_empty_record (tree type)
> {
>   if (CLASS_TYPE_P (type))
> {
>   if (CLASSTYPE_EMPTY_P (type))
> return true;
>
>   tree field;
>
>   for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
> if (TREE_CODE (field) == FIELD_DECL
> && !DECL_ARTIFICIAL (field)
> && !is_empty_record_or_array_of_empty_record (TREE_TYPE (field)))
>   return false;
>   return true;
> }
>   else if (TREE_CODE (type) == ARRAY_TYPE)
> return is_empty_record_or_array_of_empty_record (TREE_TYPE (type));
>   return false;
> }
>
> /* Returns true if TYPE is POD for the purpose of layout and
>1. A class without member.  Or
>2. A class with empty records.  */
>
> static bool
> is_empty_record_for_parm (tree type)
> {
>   if (type == error_mark_node)
> return false;
>
>   if (!CLASS_TYPE_P (type))
> return false;
>
>   if (CLASSTYPE_NON_LAYOUT_POD_P (type))
> return false;
>
>   gcc_assert (COMPLETE_TYPE_P (type));
>
>   if (CLASSTYPE_EMPTY_P (type))
> return true;
>
>   tree field;
>
>   for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
> if (TREE_CODE (field) == FIELD_DECL
> && !DECL_ARTIFICIAL 

[Bug c++/69317] [6 regression] wrong ABI version in -Wabi warnings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed in r232881.

[Bug middle-end/65686] [5/6 regression] inconsistent warning maybe-uninitialized: warn about 'unsigned', not warn about 'int'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
So, does the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13962#c9 patch help
here?

Re: [PATCH, PR target/69454] Disable TARGET_STV when stack is not properly aligned

[H.J. Lu]

On Wed, Jan 27, 2016 at 8:11 AM, Ilya Enkovich  wrote:
> On 27 Jan 16:44, Jakub Jelinek wrote:
>> On Wed, Jan 27, 2016 at 06:34:41PM +0300, Ilya Enkovich wrote:
>> > @@ -5453,6 +5443,11 @@ ix86_option_override_internal (bool main_args_p,
>> >  opts->x_target_flags |= MASK_VZEROUPPER;
>> >if (!(opts_set->x_target_flags & MASK_STV))
>> >  opts->x_target_flags |= MASK_STV;
>> > +  /* Disable STV if -mpreferred-stack-boundary={2,3} - the needed
>>
>> The comment doesn't match the code, you disable STV only for
>> -mpreferred-stack-boundary=2.
>
> Thanks, here is an updated version.
>
> Ilya
> --
> gcc/
>
> 2016-01-27  Jakub Jelinek  
> Ilya Enkovich  
>
> PR target/69454
> * config/i386/i386.c (convert_scalars_to_vector): Remove
> stack alignment fixes.
> (ix86_option_override_internal): Disable TARGET_STV if stack
> is not properly aligned.
>
> gcc/testsuite/
>
> 2016-01-27  Ilya Enkovich  
>
> PR target/69454
> * gcc.target/i386/pr69454-1.c: New test.
> * gcc.target/i386/pr69454-2.c: New test.
>
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 34b57a4..9fb8db8 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -3588,16 +3588,6 @@ convert_scalars_to_vector ()
>bitmap_obstack_release (NULL);
>df_process_deferred_rescans ();
>
> -  /* Conversion means we may have 128bit register spills/fills
> - which require aligned stack.  */
> -  if (converted_insns)
> -{
> -  if (crtl->stack_alignment_needed < 128)
> -   crtl->stack_alignment_needed = 128;
> -  if (crtl->stack_alignment_estimated < 128)
> -   crtl->stack_alignment_estimated = 128;
> -}
> -
>return 0;
>  }
>
> @@ -5453,6 +5443,11 @@ ix86_option_override_internal (bool main_args_p,
>  opts->x_target_flags |= MASK_VZEROUPPER;
>if (!(opts_set->x_target_flags & MASK_STV))
>  opts->x_target_flags |= MASK_STV;
> +  /* Disable STV if -mpreferred-stack-boundary=2 - the needed
> + stack realignment will be extra cost the pass doesn't take into
> + account and the pass can't realign the stack.  */
> +  if (ix86_preferred_stack_boundary < 64)
> +opts->x_target_flags &= ~MASK_STV;
>if (!ix86_tune_features[X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL]
>&& !(opts_set->x_target_flags & MASK_AVX256_SPLIT_UNALIGNED_LOAD))
>  opts->x_target_flags |= MASK_AVX256_SPLIT_UNALIGNED_LOAD;

MINIMUM_ALIGNMENT keeps track stack alignment.  It is OK
to disable STV for -mpreferred-stack-boundary=2.  But you should
also update ix86_minimum_alignment to make sure that STV is
disabled before returning 32 for DImode.


-- 
H.J.

[Bug middle-end/68542] [6 Regression] 10% 481.wrf performance regression

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On January 27, 2016 5:03:18 PM GMT+01:00, "mpolacek at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68542
>
>Marek Polacek  changed:
>
>   What|Removed |Added
>
>CC||mpolacek at gcc dot gnu.org
>
>--- Comment #6 from Marek Polacek  ---
>Fixed?

Not yet

[Bug c++/69509] infinite loop compiling a VLA in a recursive constexpr function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-27
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/69516] [5/6 regression] infinite recursion on a VLA with excess initializer elements in constexpr function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-27
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/69516] New: [5/6 regression] infinite recursion on a VLA with excess initializer elements in constexpr function

[msebor at gcc dot gnu.org]

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

Bug ID: 69516
   Summary: [5/6 regression] infinite recursion on a VLA with
excess initializer elements in constexpr function
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC gets itself into infinite recursion compiling the following test case
derived derived from the one shown in the discussion of a patch for bug 69496
(https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02098.html).  See also bug 69509
(which might be the same problem.)

The same problem exists in 5.x.  4.9.3 doesn't suffer from it because it
doesn't implement the more relaxed C++ 14 constexpr rules and rejects constexpr
functions that consist of more than just a return statement.

$ (cat t.c && ulimit -t 10 && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc  -Wall -Wextra -Wpedantic -std=c++14
-xc++ t.c)
constexpr int foo (int n)
{
 int a[n] = { 1, 2, 3, 4, 5, 6 };
 int z = 0;
 for (unsigned i = 0; i < 3; ++i)
   z += a[i];
 return z;
}

int main ()
{
   constexpr int n = foo (3);
   __builtin_printf ("%d\n", n);
}
t.c: In function ‘constexpr int foo(int)’:
t.c:3:13: warning: ISO C++ forbids variable length array ‘a’ [-Wvla]
  int a[n] = { 1, 2, 3, 4, 5, 6 };
 ^
xgcc: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/65931] [5/6 regression] dsymutil assertion failure building libgnat-5.dylib

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #11 from Jakub Jelinek  ---
.

Re: [PATCH, PR target/69454] Disable TARGET_STV when stack is not properly aligned

[Jakub Jelinek]

On Wed, Jan 27, 2016 at 06:34:41PM +0300, Ilya Enkovich wrote:
> @@ -5453,6 +5443,11 @@ ix86_option_override_internal (bool main_args_p,
>  opts->x_target_flags |= MASK_VZEROUPPER;
>if (!(opts_set->x_target_flags & MASK_STV))
>  opts->x_target_flags |= MASK_STV;
> +  /* Disable STV if -mpreferred-stack-boundary={2,3} - the needed

The comment doesn't match the code, you disable STV only for
-mpreferred-stack-boundary=2.

> + stack realignment will be extra cost the pass doesn't take into
> + account and the pass can't realign the stack.  */
> +  if (ix86_preferred_stack_boundary < 64)
> +opts->x_target_flags &= ~MASK_STV;
>if (!ix86_tune_features[X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL]
>&& !(opts_set->x_target_flags & MASK_AVX256_SPLIT_UNALIGNED_LOAD))
>  opts->x_target_flags |= MASK_AVX256_SPLIT_UNALIGNED_LOAD;

Jakub

[Bug c++/69317] [6 regression] wrong ABI version in -Wabi warnings

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Wed Jan 27 15:44:07 2016
New Revision: 232881

URL: https://gcc.gnu.org/viewcvs?rev=232881=gcc=rev
Log:
PR c++/69317 - [6 regression] wrong ABI version in -Wabi warnings

gcc/cp/ChangeLog:
2016-01-27  Martin Sebor  

PR c++/69317
* mangle.c (mangle_decl): Reference the correct (saved) version
of the ABI in -Wabi diagnostics.

gcc/testsuite/ChangeLog:
2016-01-27  Martin Sebor  

PR c++/69317
* g++.dg/abi/Wabi-2-2.C: New test.
* g++.dg/abi/Wabi-2-3.C: New test.
* g++.dg/abi/Wabi-3-2.C: New test.
* g++.dg/abi/Wabi-3-3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/abi/Wabi-2-2.C
trunk/gcc/testsuite/g++.dg/abi/Wabi-2-3.C
trunk/gcc/testsuite/g++.dg/abi/Wabi-3-2.C
trunk/gcc/testsuite/g++.dg/abi/Wabi-3-3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/mangle.c
trunk/gcc/testsuite/ChangeLog

Re: [PATCH, PR target/69454] Disable TARGET_STV when stack is not properly aligned

[H.J. Lu]

On Wed, Jan 27, 2016 at 7:34 AM, Ilya Enkovich  wrote:
> Hi,
>
> Currently STV pass may require a stack realignment if any
> transformation occurs to enable SSE registers spill/fill.
> It appears it's invalid to increase stack alignment requirements
> at this point.  Thus we have to either assume we need stack to be
> aligned if are going to run STV pass or disable STV if stack is
> not properly aligned.  I suppose we shouldn't ignore explicitly
> requested stack alignment not beeing sure we really optimize
> anything (and STV is not an optimization frequiently applied).
> So I think we may disable TARGET_STV for such cases as Jakub
> suggested.  This patch was bootstrapped and regtested on
> x86_64-pc-linux-gnu.  OK for trunk?
>

> diff --git a/gcc/testsuite/gcc.target/i386/pr69454-1.c 
> b/gcc/testsuite/gcc.target/i386/pr69454-1.c
> new file mode 100644
> index 000..12ecfd3
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr69454-1.c
> @@ -0,0 +1,11 @@
> +/* { dg-do compile { target { ia32 } } } */
> +/* { dg-options "-O2 -msse2 -mno-accumulate-outgoing-args 
> -mpreferred-stack-boundary=2" } */
> +
> +typedef struct { long long w64[2]; } V128;
> +extern V128* fn2(void);
> +long long a;
> +V128 b;
> +void fn1() {
> +  V128 *c = fn2();
> +  c->w64[0] = a ^ b.w64[0];
> +}
> diff --git a/gcc/testsuite/gcc.target/i386/pr69454-2.c 
> b/gcc/testsuite/gcc.target/i386/pr69454-2.c
> new file mode 100644
> index 000..28bab93
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr69454-2.c
> @@ -0,0 +1,13 @@
> +/* { dg-do compile { target { ia32 } } } */
> +/* { dg-options "-O2 -mpreferred-stack-boundary=2" } */

This needs:

+/* { dg-options "-O2 -msse2 -mno-accumulate-outgoing-args
-mpreferred-stack-boundary=2" } */

to trigger.

> +extern void fn2 ();
> +long long a, b;
> +
> +void fn1 ()
> +{
> +  long long c = a;
> +  a = b ^ a;
> +  fn2 ();
> +  a = c;
> +}

Here is a different patch, which I believe is the right fix.

-- 
H.J.
From 86e040399dd5ca6b23597be4aff5edb9ac2ab5d7 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Mon, 25 Jan 2016 12:31:45 -0800
Subject: [PATCH] Don't align DImode to 32 bits if the STV pass is enabled

Since the STV pass uses SSE2 instructions on DImode which needs 64-bit
alignment for DImode, don't align DImode to 32 bits if the STV pass is
enabled.

gcc/

	PR target/69454
	* config/i386/i386.c (convert_scalars_to_vector): Don't change
	stack alignment here.
	(ix86_minimum_alignment): Don't align DImode to 32 bits if the
	STV pass is enabled.

gcc/testsuite/

	PR target/69454
	* gcc.target/i386/pr69454-1.c: New test.
	* gcc.target/i386/pr69454-2.c: Likewise.
---
 gcc/config/i386/i386.c| 16 
 gcc/testsuite/gcc.target/i386/pr69454-1.c | 11 +++
 gcc/testsuite/gcc.target/i386/pr69454-2.c | 13 +
 3 files changed, 28 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr69454-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr69454-2.c

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index cfbdf0f..8babdaf 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3588,16 +3588,6 @@ convert_scalars_to_vector ()
   bitmap_obstack_release (NULL);
   df_process_deferred_rescans ();
 
-  /* Conversion means we may have 128bit register spills/fills
- which require aligned stack.  */
-  if (converted_insns)
-{
-  if (crtl->stack_alignment_needed < 128)
-	crtl->stack_alignment_needed = 128;
-  if (crtl->stack_alignment_estimated < 128)
-	crtl->stack_alignment_estimated = 128;
-}
-
   return 0;
 }
 
@@ -29299,8 +29289,10 @@ ix86_minimum_alignment (tree exp, machine_mode mode,
 return align;
 
   /* Don't do dynamic stack realignment for long long objects with
- -mpreferred-stack-boundary=2.  */
-  if ((mode == DImode || (type && TYPE_MODE (type) == DImode))
+ -mpreferred-stack-boundary=2.  The STV pass uses SSE2 instructions
+ on DImode which needs 64-bit alignment for DImode.  */
+  if (!(TARGET_STV && TARGET_SSE2 && optimize > 1)
+  && (mode == DImode || (type && TYPE_MODE (type) == DImode))
   && (!type || !TYPE_USER_ALIGN (type))
   && (!decl || !DECL_USER_ALIGN (decl)))
 return 32;
diff --git a/gcc/testsuite/gcc.target/i386/pr69454-1.c b/gcc/testsuite/gcc.target/i386/pr69454-1.c
new file mode 100644
index 000..12ecfd3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr69454-1.c
@@ -0,0 +1,11 @@
+/* { dg-do compile { target { ia32 } } } */
+/* { dg-options "-O2 -msse2 -mno-accumulate-outgoing-args -mpreferred-stack-boundary=2" } */
+
+typedef struct { long long w64[2]; } V128;
+extern V128* fn2(void);
+long long a;
+V128 b;
+void fn1() {
+  V128 *c = fn2();
+  c->w64[0] = a ^ b.w64[0];
+}
diff --git a/gcc/testsuite/gcc.target/i386/pr69454-2.c b/gcc/testsuite/gcc.target/i386/pr69454-2.c
new file mode 100644
index 000..4820b76
--- /dev/null
+++ 

Re: [PATCH, PR target/69454] Disable TARGET_STV when stack is not properly aligned

[Ilya Enkovich]

On 27 Jan 16:44, Jakub Jelinek wrote:
> On Wed, Jan 27, 2016 at 06:34:41PM +0300, Ilya Enkovich wrote:
> > @@ -5453,6 +5443,11 @@ ix86_option_override_internal (bool main_args_p,
> >  opts->x_target_flags |= MASK_VZEROUPPER;
> >if (!(opts_set->x_target_flags & MASK_STV))
> >  opts->x_target_flags |= MASK_STV;
> > +  /* Disable STV if -mpreferred-stack-boundary={2,3} - the needed
> 
> The comment doesn't match the code, you disable STV only for
> -mpreferred-stack-boundary=2.

Thanks, here is an updated version.

Ilya
--
gcc/

2016-01-27  Jakub Jelinek  
Ilya Enkovich  

PR target/69454
* config/i386/i386.c (convert_scalars_to_vector): Remove
stack alignment fixes.
(ix86_option_override_internal): Disable TARGET_STV if stack
is not properly aligned.

gcc/testsuite/

2016-01-27  Ilya Enkovich  

PR target/69454
* gcc.target/i386/pr69454-1.c: New test.
* gcc.target/i386/pr69454-2.c: New test.


diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 34b57a4..9fb8db8 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3588,16 +3588,6 @@ convert_scalars_to_vector ()
   bitmap_obstack_release (NULL);
   df_process_deferred_rescans ();
 
-  /* Conversion means we may have 128bit register spills/fills
- which require aligned stack.  */
-  if (converted_insns)
-{
-  if (crtl->stack_alignment_needed < 128)
-   crtl->stack_alignment_needed = 128;
-  if (crtl->stack_alignment_estimated < 128)
-   crtl->stack_alignment_estimated = 128;
-}
-
   return 0;
 }
 
@@ -5453,6 +5443,11 @@ ix86_option_override_internal (bool main_args_p,
 opts->x_target_flags |= MASK_VZEROUPPER;
   if (!(opts_set->x_target_flags & MASK_STV))
 opts->x_target_flags |= MASK_STV;
+  /* Disable STV if -mpreferred-stack-boundary=2 - the needed
+ stack realignment will be extra cost the pass doesn't take into
+ account and the pass can't realign the stack.  */
+  if (ix86_preferred_stack_boundary < 64)
+opts->x_target_flags &= ~MASK_STV;
   if (!ix86_tune_features[X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL]
   && !(opts_set->x_target_flags & MASK_AVX256_SPLIT_UNALIGNED_LOAD))
 opts->x_target_flags |= MASK_AVX256_SPLIT_UNALIGNED_LOAD;
diff --git a/gcc/testsuite/gcc.target/i386/pr69454-1.c 
b/gcc/testsuite/gcc.target/i386/pr69454-1.c
new file mode 100644
index 000..12ecfd3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr69454-1.c
@@ -0,0 +1,11 @@
+/* { dg-do compile { target { ia32 } } } */
+/* { dg-options "-O2 -msse2 -mno-accumulate-outgoing-args 
-mpreferred-stack-boundary=2" } */
+
+typedef struct { long long w64[2]; } V128;
+extern V128* fn2(void);
+long long a;
+V128 b;
+void fn1() {
+  V128 *c = fn2();
+  c->w64[0] = a ^ b.w64[0];
+}
diff --git a/gcc/testsuite/gcc.target/i386/pr69454-2.c 
b/gcc/testsuite/gcc.target/i386/pr69454-2.c
new file mode 100644
index 000..28bab93
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr69454-2.c
@@ -0,0 +1,13 @@
+/* { dg-do compile { target { ia32 } } } */
+/* { dg-options "-O2 -mpreferred-stack-boundary=2" } */
+
+extern void fn2 ();
+long long a, b;
+
+void fn1 ()
+{
+  long long c = a;
+  a = b ^ a;
+  fn2 ();
+  a = c;
+}

[Bug rtl-optimization/69447] [5/6 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 #12 from Richard Henderson  ---
(In reply to ktkachov from comment #10)
> This patch also seems to fix the wrong code in PR 69124

Good to know -- I wasn't able to reproduce that failure myself.

[Bug testsuite/69488] tests in gnat/sso give a lot of spurious failures

[rai...@emrich-ebersheim.de]

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

--- Comment #6 from Rainer Emrich  ---
I tested the new version of the proposed patch. Now the tests all pass on
x86_64-unknown-linux-gnu and x86_64-w64-mingw32.

Eric, please submit to mainline.

Re: [PATCH, PR target/69454] Disable TARGET_STV when stack is not properly aligned

[Ilya Enkovich]

2016-01-27 19:18 GMT+03:00 H.J. Lu :
> On Wed, Jan 27, 2016 at 8:11 AM, Ilya Enkovich  wrote:
>> On 27 Jan 16:44, Jakub Jelinek wrote:
>>> On Wed, Jan 27, 2016 at 06:34:41PM +0300, Ilya Enkovich wrote:
>>> > @@ -5453,6 +5443,11 @@ ix86_option_override_internal (bool main_args_p,
>>> >  opts->x_target_flags |= MASK_VZEROUPPER;
>>> >if (!(opts_set->x_target_flags & MASK_STV))
>>> >  opts->x_target_flags |= MASK_STV;
>>> > +  /* Disable STV if -mpreferred-stack-boundary={2,3} - the needed
>>>
>>> The comment doesn't match the code, you disable STV only for
>>> -mpreferred-stack-boundary=2.
>>
>> Thanks, here is an updated version.
>>
>> Ilya
>> --
>> gcc/
>>
>> 2016-01-27  Jakub Jelinek  
>> Ilya Enkovich  
>>
>> PR target/69454
>> * config/i386/i386.c (convert_scalars_to_vector): Remove
>> stack alignment fixes.
>> (ix86_option_override_internal): Disable TARGET_STV if stack
>> is not properly aligned.
>>
>> gcc/testsuite/
>>
>> 2016-01-27  Ilya Enkovich  
>>
>> PR target/69454
>> * gcc.target/i386/pr69454-1.c: New test.
>> * gcc.target/i386/pr69454-2.c: New test.
>>
>>
>> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>> index 34b57a4..9fb8db8 100644
>> --- a/gcc/config/i386/i386.c
>> +++ b/gcc/config/i386/i386.c
>> @@ -3588,16 +3588,6 @@ convert_scalars_to_vector ()
>>bitmap_obstack_release (NULL);
>>df_process_deferred_rescans ();
>>
>> -  /* Conversion means we may have 128bit register spills/fills
>> - which require aligned stack.  */
>> -  if (converted_insns)
>> -{
>> -  if (crtl->stack_alignment_needed < 128)
>> -   crtl->stack_alignment_needed = 128;
>> -  if (crtl->stack_alignment_estimated < 128)
>> -   crtl->stack_alignment_estimated = 128;
>> -}
>> -
>>return 0;
>>  }
>>
>> @@ -5453,6 +5443,11 @@ ix86_option_override_internal (bool main_args_p,
>>  opts->x_target_flags |= MASK_VZEROUPPER;
>>if (!(opts_set->x_target_flags & MASK_STV))
>>  opts->x_target_flags |= MASK_STV;
>> +  /* Disable STV if -mpreferred-stack-boundary=2 - the needed
>> + stack realignment will be extra cost the pass doesn't take into
>> + account and the pass can't realign the stack.  */
>> +  if (ix86_preferred_stack_boundary < 64)
>> +opts->x_target_flags &= ~MASK_STV;
>>if (!ix86_tune_features[X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL]
>>&& !(opts_set->x_target_flags & MASK_AVX256_SPLIT_UNALIGNED_LOAD))
>>  opts->x_target_flags |= MASK_AVX256_SPLIT_UNALIGNED_LOAD;
>
> MINIMUM_ALIGNMENT keeps track stack alignment.  It is OK
> to disable STV for -mpreferred-stack-boundary=2.  But you should
> also update ix86_minimum_alignment to make sure that STV is
> disabled before returning 32 for DImode.

If -mpreferred-stack-boundary=2 then STV is disabled, if STV is enabled then
-mpreferred-stack-boundary>=3 and this condition in
ix86_minimum_alignment works:

  if (TARGET_64BIT || align != 64 || ix86_preferred_stack_boundary >= 64)
return align;

Thanks,
Ilya

>
>
> --
> H.J.

[Bug target/68380] NetBSD has SSP in libc

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #3 from Jeffrey A. Law  ---
Patch committed to the trunk.

[Bug target/68380] NetBSD has SSP in libc

[law at gcc dot gnu.org]

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

--- Comment #2 from Jeffrey A. Law  ---
Author: law
Date: Wed Jan 27 16:54:48 2016
New Revision: 232884

URL: https://gcc.gnu.org/viewcvs?rev=232884=gcc=rev
Log:
2016-01-27  Thomas Klausner  

PR target/68380
* configure.ac: NetBSD provides SSP in its C library.
* configure: Updated.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/gcc/configure.ac

[Bug ada/69488] tests in gnat/sso give a lot of spurious failures

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #9 from Eric Botcazou  ---
.

[Bug tree-optimization/69466] [6 Regression] ICE: Invalid PHI argument after vectorization (on -O2)

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
I am testing that patch now.

[Bug fortran/69495] unused-label warning does not tell which flag triggered it

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #5)
> (In reply to janus from comment #4)
> > Is there a reason for this behavior?
> 
> https://gcc.gnu.org/wiki/FAQ#wnowarning

I see. So this is intended and not a bug. Thanks for the pointer.


> But the third call should have given some other warning; otherwise there is
> a bug.

Right, there was a warning. I just omitted it because I did not expect that it
makes a difference.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Patch, fortran, GCC-5/6, PR62536, v1] ICE (segfault) for invalid END BLOCK statement

[Andre Vehreschild]

Hi all,

attached are two patches one for trunk and one for the gcc-5-branch,
which fix an ICE when BLOCK statements are not closed correctly (too
many END BLOCKs). Unfortunately did the patch I tailored for gcc-5 not
work on trunk.

GCC 5: The ICE is prevented by making sure that gfc_current_ns is not
set to NULL, when too many closing END BLOCK statements are found. This
may lead to gfortran be in the wrong namespace, but gfortran is already
in error. Therefore this does not matter any more. We just need to exit
cleanly.

GCC 6/trunk: Here the ICE is prevented by making sure, that unnesting
of BLOCK namespaces is only done, when the END encountered is not the
one of a BLOCK. This prevents gfortran from removing a correctly
initialized and for further analysis required namespace.

Bootstrapped and regtested ok on x86_64-linux-gnu/F23. 

Ok for trunk and gcc-5-branch, respectively?

Regards,
Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 2708413..adea3f3 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -6454,9 +6454,16 @@ cleanup:
 	  prev_ns = ns;
 	  ns = ns->sibling;
 	}
-  
-  gfc_free_namespace (gfc_current_ns);
-  gfc_current_ns = parent_ns;
+
+  if (parent_ns)
+	{
+	  /* Free the current namespace only when the parent one exists.  This
+	 prevents an ICE when more END BLOCK then BLOCK statements are
+	 present.  It does not mean any further harm, because we already
+	 have errored.  */
+	  gfc_free_namespace (gfc_current_ns);
+	  gfc_current_ns = parent_ns;
+	}
 }
 
   return MATCH_ERROR;
diff --git a/gcc/testsuite/gfortran.dg/block_14.f08 b/gcc/testsuite/gfortran.dg/block_14.f08
new file mode 100644
index 000..4e5903b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/block_14.f08
@@ -0,0 +1,21 @@
+! { dg-do compile }
+!
+! Contributed by Tobias Burnus  
+! Check fix for PR62536 works as expected.
+
+function f2 (x)
+implicit none
+  integer f2, x
+  block
+   block named ! { dg-error "Unclassifiable statement" }
+integer a ! should be SAVEd
+a = a + x ! should increment by y every time
+f2 = a
+   end block named ! { dg-error "Syntax error in END BLOCK statement" }
+  end block ! { dg-error "Expected block name of " }
+  return
+endfunction ! { dg-error "Expecting END BLOCK statement" }
+
+end ! { dg-error "END BLOCK statement expected" }
+! { dg-excess-errors "Previous error cause unexpected end of file." }
+
gcc/testsuite/ChangeLog:

2016-01-27  Andre Vehreschild  

PR fortran/62536
* gfortran.dg/block_14.f08: New test.


gcc/fortran/ChangeLog:

2016-01-27  Andre Vehreschild  

PR fortran/62536
* decl.c: Prevent setting gfc_current_ns to NULL when block statement's
nesting is incomplete.  There is already an error conditon, so having
gfc_current_ns pointing to an eventually wrong namespace does not matter
that much.

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 7c0e011..df81369 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -6327,6 +6327,7 @@ gfc_match_end (gfc_statement *st)
   gfc_namespace *parent_ns, *ns, *prev_ns;
   gfc_namespace **nsp;
   bool abreviated_modproc_decl;
+  bool got_matching_end = false;
 
   old_loc = gfc_current_locus;
   if (gfc_match ("end") != MATCH_YES)
@@ -6510,6 +6511,8 @@ gfc_match_end (gfc_statement *st)
 		 ? "END PROCEDURE" : gfc_ascii_statement(*st), _loc);
   goto cleanup;
 }
+  else
+got_matching_end = true;
 
   old_loc = gfc_current_locus;
   /* If we're at the end, make sure a block name wasn't required.  */
@@ -6581,7 +6584,7 @@ cleanup:
   /* If we are missing an END BLOCK, we created a half-ready namespace.
  Remove it from the parent namespace's sibling list.  */
 
-  while (state == COMP_BLOCK)
+  while (state == COMP_BLOCK && !got_matching_end)
 {
   parent_ns = gfc_current_ns->parent;
 
@@ -6601,7 +6604,7 @@ cleanup:
 	  prev_ns = ns;
 	  ns = ns->sibling;
 	}
-  
+
   gfc_free_namespace (gfc_current_ns);
   gfc_current_ns = parent_ns;
   gfc_state_stack = gfc_state_stack->previous;
diff --git a/gcc/testsuite/gfortran.dg/block_15.f08 b/gcc/testsuite/gfortran.dg/block_15.f08
new file mode 100644
index 000..fd1ca55
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/block_15.f08
@@ -0,0 +1,20 @@
+! { dg-do compile }
+!
+! Contributed by Tobias Burnus  
+! Check fix for PR62536 works as expected.
+
+function f2 (x)
+implicit none
+  integer f2, x
+  block
+   block named ! { dg-error "Unclassifiable statement" }
+integer a ! should be SAVEd
+a = a + x ! should increment by y every time
+f2 = a
+   end block named ! { dg-error "Syntax error in END BLOCK statement" }
+  end block
+  return
+endfunction
+
+end
+
diff --git a/gcc/testsuite/gfortran.dg/block_end_error_1.f90 b/gcc/testsuite/gfortran.dg/block_end_error_1.f90
index 

[Bug c++/69379] [6 Regression] ICE in fold_convert_loc, at fold-const.c:2366

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #13 from Marek Polacek  ---
Hopefully fixed.

Re: C++ PATCH for c++/69379 (ICE with PTRMEM_CST wrapped in NOP_EXPR)

[Jason Merrill]

On 01/25/2016 03:00 PM, Marek Polacek wrote:

It appears that handling the case when the types don't match is sufficient, at
least all the tests pass, thus the following should be enough.


OK.


+   "reinterpret_cast has different types");


Let's say "a reinterpret_cast is not a constant-expression" here.

OK with that change.

Jason