[PATCH][PR rtl-optimization/70024] Fix argument to CROSSING_JUMP_P

[Jeff Law]

As noted in the BZ, we were passing a SEQUENCE to CROSSING_JUMP_P, which 
triggers an RTL checking failure.  It's pretty obvious that we should 
have been passing in "delay_jump_insn" and doing so, of course, fixes 
the failure.


I haven't been able to put together a sparc64 system for testing under 
qemu, but I'm highly confident we've got the right fix.


I've committed this to the trunk.  I'm removing the gcc-6 regression 
marker, but adding one for gcc-5 as I believe gcc-5 suffers from the 
same problem -- even if this testcase doesn't trigger.


Jeff
commit 295d529101bb79b4f876e119d8e3e8dbd43963d2
Author: law 
Date:   Wed Mar 16 16:58:12 2016 +

PR rtl-optimization/70024
* reorg.c (relax_delay_slots): Pass right argument to CROSSING_JUMP_P.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@234262 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index b673443..ef16b27 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2016-03-11  Jeff Law  
+
+   PR rtl-optimization/70024
+   * reorg.c (relax_delay_slots): Pass right argument to CROSSING_JUMP_P.
+
 2016-03-16  Richard Henderson  
 
PR middle-end/70199
diff --git a/gcc/reorg.c b/gcc/reorg.c
index a02141f..7b28821 100644
--- a/gcc/reorg.c
+++ b/gcc/reorg.c
@@ -3307,7 +3307,7 @@ relax_delay_slots (rtx_insn *first)
  reorg_redirect_jump (delay_jump_insn, trial);
  target_label = trial;
  if (crossing)
-   CROSSING_JUMP_P (insn) = 1;
+   CROSSING_JUMP_P (delay_jump_insn) = 1;
}
 
   /* If the first insn at TARGET_LABEL is redundant with a previous

[Bug tree-optimization/70256] Add debug_varinfo and debug_varmap

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
Approved for stage1: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00912.html

[Bug rtl-optimization/70030] [LRA]ICE when reload insn with output scratch operand

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-03-16
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
Waiting.

[Bug c++/61198] Crash when selecting specializations through aliases.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||5.1.0
   Target Milestone|--- |4.9.4

--- Comment #11 from Jonathan Wakely  ---
Also backported to gcc-4_9-branch, as approved by Jason at
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00810.html

[PATCH] Use simplify_replace_rtx instead of replace_rtx for DEBUG_INSNs in reload

[Jakub Jelinek]

Hi!

This patch fixes one of the spots that use replace_rtx, as this changes
debug insns, it clearly wants to replace just based on regno, not on pointer
equality, and for debug insns simplification is always desirable too.
The other place in reload1 that modifies DEBUG_INSNs also uses
simplify_replace_rtx.

Bootstrapped/regtested on {x86_64,i686,powerpc64{,le}}-linux, ok for trunk?

2016-03-18  Jakub Jelinek  

* reload1.c (emit_input_reload_insns): Use simplify_replace_rtx
instead of replace_rtx for DEBUG_INSNs.

--- gcc/reload1.c.jj2016-03-02 07:39:13.0 +0100
+++ gcc/reload1.c   2016-03-16 10:41:34.622921016 +0100
@@ -7395,7 +7395,9 @@ emit_input_reload_insns (struct insn_cha
  /* Adjust any debug insns between temp and insn.  */
  while ((temp = NEXT_INSN (temp)) != insn)
if (DEBUG_INSN_P (temp))
- replace_rtx (PATTERN (temp), old, reloadreg);
+ INSN_VAR_LOCATION_LOC (temp)
+   = simplify_replace_rtx (INSN_VAR_LOCATION_LOC (temp),
+   old, reloadreg);
else
  gcc_assert (NOTE_P (temp));
}

Jakub

Re: [PATCH] PR testsuite/70150: Check non-pic/ia32 in stackprotectexplicit2.C

[Rainer Orth]

"H.J. Lu"  writes:

> For ia32, __stack_chk_fail isn't called in PIC.  We need to check
> non-pic or non-ia32 before scanning for __stack_chk_fail.
>
> OK for trunk?
>
> H.J.
> ---
>   PR testsuite/70150

There's already PR c++/66400 (and a bunch of others for several related
issues) which I'd filed on your request when working on Solaris PIE
support.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [C++ PATCH] Fix -flifetime-dse bug in dtors too (PR c++/70272)

[Jason Merrill]

OK.

Jason

New French PO file for 'cpplib' (version 6.1-b20160131)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the French team of translators.  The file is available at:

http://translationproject.org/latest/cpplib/fr.po

(This file, 'cpplib-6.1-b20160131.fr.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[Bug c/70281] valgrind error in can_be_stored_compactly_p (line-map.c:148)

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-03-17
 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Thanks.  Confirmed on my box; am investigating.

Re: [RFA][PR rtl-optimization/70263] Fix creation of new REG_EQUIV notes

[David Malcolm]

On Fri, 2016-03-18 at 13:20 -0600, Jeff Law wrote:
> On 03/18/2016 01:16 PM, Bernd Schmidt wrote:
> > On 03/18/2016 08:14 PM, Jeff Law wrote:
> > > I also added a blurb to the dump file when we create these
> > > equivalences
> > > and included a test to verify the code fires.  I verified it
> > > fired on
> > > x86 and x86-64.  It may or may not fire on other targets, so I
> > > left the
> > > test in the i386 specific subdirectory.
> > 
> > This is the sort of thing I'd want to do with rtl unit tests.

Would you like an RTL frontend?  (and something like a 
 gcc/testsuite/rtl.dg/ )

> Yea.  Along the same lines, my patch for the coalescing problem 
> introduces a new bitmap function that I'd like to cover with some
> unit 
> tests.  

Presumably the -fself-test idea could help here?

> I'm sure we're going to find oodles of these things as we 
> continue development and ponder how to better test things than
> scanning 
> dump files.

 

Re: [PATCH] Fix PR c++/70218 (illegal access to private field succeeds)

[Matthias Klose]

On 13.03.2016 21:03, Patrick Palka wrote:

Here we are mishandling the deferred_access_stack by not coherently
pushing/popping from it.  In cp_parser_lambda_expression we are calling
(in order):

   push_deferring_access_checks (dk_no_deferred);
   cp_parser_start_tentative_firewall (parser);
   ...
   pop_deferring_access_checks ();
   cp_parser_end_tentative_firewall (parser, start, lambda_expr);

But the order of the last two popping calls does not correspond with the order
of the first two pushing calls.  pop_deferring_access_checks should be
called last.  This error may cause us to drop deferred access checks
instead of performing them.

Bootstrap + regtest in progress, does this look OK to commit if testing
succeeds?


when applying this patch to the gcc-5-branch I see regressions like

/scratch/packages/gcc/5/gcc-5-5.3.1/src/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-70218.C: 
In function 'void foo()':
/scratch/packages/gcc/5/gcc-5-5.3.1/src/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-70218.C:6:8: 
error: 'int X::i' is private
/scratch/packages/gcc/5/gcc-5-5.3.1/src/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-70218.C:16:18: 
error: within this context


Excess errors:
/scratch/packages/gcc/5/gcc-5-5.3.1/src/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-70218.C:6:8: 
error: 'int X::i' is private
/scratch/packages/gcc/5/gcc-5-5.3.1/src/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-70218.C:16:18: 
error: within this context



haven't yet checked the trunk. I don't see any other regressions besides the 
usual noise in the ubsan tests.


Matthias

[Bug fortran/70244] ICE spec_dimen_size() Bad dimension

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-16
 CC||burnus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Tobias Burnus  ---
Confirmed with GCC 6.


The ICE is triggered for:

0x61723e spec_dimen_size(gfc_array_spec*, int, __mpz_struct (*) [1])
2118  if (dimen < 0 || dimen > as->rank - 1)

as dimen == 1 and as->rank == 1. That's called via "gfc_array_dimen_size",
which first has:

case EXPR_FUNCTION:
  for (ref = array->ref; ref; ref = ref->next)

but that never gets executed as one has one REF_ARRAY of type AR_ELEMENT and
then 4 REF_COMPONENT. Thus, the following code is used:
  else if (!spec_dimen_size (array->symtree->n.sym->as, dimen, result))
which resolves to "e" which is a rank-1 array.

That fails as the proper "as" is the one at
   array->ref->next->next->next->u.c.component->as



Replacing the check in "gfc_array_dimen_size" by the following should works:

  gfc_array_spec *as = gfc_get_full_arrayspec_from_expr (array);
  if (!spec_dimen_size (as, dimen, result))
return false;

One just has to check which parts in gfc_array_dimen_size can be replaced by
this and whether all special cases are taken care of in
gfc_get_full_arrayspec_from_expr.

Re: [PATCH] Fix PR64764

[Tom de Vries]

On 16/03/16 17:15, H.J. Lu wrote:

On Wed, Mar 16, 2016 at 9:12 AM, H.J. Lu  wrote:



Any particular reason why this test was changed to DOS format?


FWIW, the test was in DOS format from the start.

Thanks
- Tom

Re: [PATCH, PR70269] Set dump_file to NULL in cgraph_node::get_body

[Richard Biener]

On Thu, 17 Mar 2016, Tom de Vries wrote:

> Hi,
> 
> this patch fixes PR70269, an 5/6 regression.
> 
> When compiling with "-O2 -fipa-pta -fdump-ipa-pta-graph" we try to initialize
> a graph dump file for ipa-cp, while the dump file is not enabled, which causes
> an ICE because dump_file_name is NULL.
> 
> This condition in pass_init_dump_file enables the unnecessary initialization,
> because dump_file is non-NULL:
> ...
>   if (initializing_dump
>   && dump_file && (dump_flags & TDF_GRAPH)
>   && cfun && (cfun->curr_properties & PROP_cfg))
> ...
> 
> The dump_file is non-NULL, but it's the dump file for ipa-pta, the pass that
> calls cgraph_node:get_body which triggers the ipa transform of ipa-cp.
> 
> The patch fixes this by resetting dump_file to NULL in cgraph_node::get_body.
> 
> OK for stage 4 trunk/5 branch if bootstrap and reg-test succeeds?

Ok.

Richard.

[Bug target/70232] [6 regression] excessive stack usage with -O2

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Btw, the bswap pass for arm doesn't detect any bswap32 or bswap64 instruction.

There is

(define_expand "bswapsi2"
  [(set (match_operand:SI 0 "s_register_operand" "=r")
(bswap:SI (match_operand:SI 1 "s_register_operand" "r")))]
"TARGET_EITHER && (arm_arch6 || !optimize_size)"

but no bswapdi2.

Rename GOMP_MAP_FORCE_DEALLOC to GOMP_MAP_DELETE (was: [gomp4.1] map clause parsing improvements)

[Thomas Schwinge]

Hi!

On Thu, 17 Mar 2016 15:37:04 +0100, Jakub Jelinek  wrote:
> On Thu, Mar 17, 2016 at 03:34:09PM +0100, Thomas Schwinge wrote:
> > That's simple enouch; OK to commit?  (I'm also including the related
> > change, to rename the Fortran OMP_MAP_FORCE_DEALLOC to OMP_MAP_DELETE,
> > because I think that's what you'd do, once starting the OpenMP 4.5
> > Fortran front end work.)
> 
> Ok, thanks.

Committed unchanged to trunk in r234294:

commit 5cb6b0b9685d5c63e87abb10abac60312dab1378
Author: tschwinge 
Date:   Thu Mar 17 15:07:54 2016 +

Rename GOMP_MAP_FORCE_DEALLOC to GOMP_MAP_DELETE

Also rename the Fortran OMP_MAP_FORCE_DEALLOC to OMP_MAP_DELETE.

include/
* gomp-constants.h (enum gomp_map_kind): Rename
GOMP_MAP_FORCE_DEALLOC to GOMP_MAP_DELETE.  Adjust all users.

gcc/fortran/
* gfortran.h (enum gfc_omp_map_op): Rename OMP_MAP_FORCE_DEALLOC
to OMP_MAP_DELETE.  Adjust all users.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@234294 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/c/c-parser.c   | 2 +-
 gcc/cp/parser.c| 2 +-
 gcc/fortran/ChangeLog  | 5 +
 gcc/fortran/gfortran.h | 2 +-
 gcc/fortran/openmp.c   | 2 +-
 gcc/fortran/trans-openmp.c | 6 +++---
 gcc/gimplify.c | 2 +-
 gcc/omp-low.c  | 2 +-
 gcc/tree-pretty-print.c| 2 +-
 include/ChangeLog  | 5 +
 include/gomp-constants.h   | 6 ++
 libgomp/oacc-parallel.c| 6 +++---
 12 files changed, 25 insertions(+), 17 deletions(-)

diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index 60ec996..82d6eca 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -10715,7 +10715,7 @@ c_parser_oacc_data_clause (c_parser *parser, 
pragma_omp_clause c_kind,
   kind = GOMP_MAP_FORCE_ALLOC;
   break;
 case PRAGMA_OACC_CLAUSE_DELETE:
-  kind = GOMP_MAP_FORCE_DEALLOC;
+  kind = GOMP_MAP_DELETE;
   break;
 case PRAGMA_OACC_CLAUSE_DEVICE:
   kind = GOMP_MAP_FORCE_TO;
diff --git gcc/cp/parser.c gcc/cp/parser.c
index 62570d4..8ba4ffe 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -30086,7 +30086,7 @@ cp_parser_oacc_data_clause (cp_parser *parser, 
pragma_omp_clause c_kind,
   kind = GOMP_MAP_FORCE_ALLOC;
   break;
 case PRAGMA_OACC_CLAUSE_DELETE:
-  kind = GOMP_MAP_FORCE_DEALLOC;
+  kind = GOMP_MAP_DELETE;
   break;
 case PRAGMA_OACC_CLAUSE_DEVICE:
   kind = GOMP_MAP_FORCE_TO;
diff --git gcc/fortran/ChangeLog gcc/fortran/ChangeLog
index 9ed112e..105e7b4 100644
--- gcc/fortran/ChangeLog
+++ gcc/fortran/ChangeLog
@@ -1,3 +1,8 @@
+2016-03-17  Thomas Schwinge  
+
+   * gfortran.h (enum gfc_omp_map_op): Rename OMP_MAP_FORCE_DEALLOC
+   to OMP_MAP_DELETE.  Adjust all users.
+
 2016-03-13  Jerry DeLisle  
Jim MacArthur  
 
diff --git gcc/fortran/gfortran.h gcc/fortran/gfortran.h
index 33fffd8..a0fb5fd 100644
--- gcc/fortran/gfortran.h
+++ gcc/fortran/gfortran.h
@@ -1112,8 +1112,8 @@ enum gfc_omp_map_op
   OMP_MAP_TO,
   OMP_MAP_FROM,
   OMP_MAP_TOFROM,
+  OMP_MAP_DELETE,
   OMP_MAP_FORCE_ALLOC,
-  OMP_MAP_FORCE_DEALLOC,
   OMP_MAP_FORCE_TO,
   OMP_MAP_FORCE_FROM,
   OMP_MAP_FORCE_TOFROM,
diff --git gcc/fortran/openmp.c gcc/fortran/openmp.c
index 51ab96e..a6c39cd 100644
--- gcc/fortran/openmp.c
+++ gcc/fortran/openmp.c
@@ -764,7 +764,7 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, uint64_t mask,
   if ((mask & OMP_CLAUSE_DELETE)
  && gfc_match ("delete ( ") == MATCH_YES
  && gfc_match_omp_map_clause (>lists[OMP_LIST_MAP],
-  OMP_MAP_FORCE_DEALLOC))
+  OMP_MAP_DELETE))
continue;
   if ((mask & OMP_CLAUSE_PRESENT)
  && gfc_match ("present ( ") == MATCH_YES
diff --git gcc/fortran/trans-openmp.c gcc/fortran/trans-openmp.c
index 5990202..a905ca6 100644
--- gcc/fortran/trans-openmp.c
+++ gcc/fortran/trans-openmp.c
@@ -2119,12 +2119,12 @@ gfc_trans_omp_clauses (stmtblock_t *block, 
gfc_omp_clauses *clauses,
case OMP_MAP_TOFROM:
  OMP_CLAUSE_SET_MAP_KIND (node, GOMP_MAP_TOFROM);
  break;
+   case OMP_MAP_DELETE:
+ OMP_CLAUSE_SET_MAP_KIND (node, GOMP_MAP_DELETE);
+ break;
case OMP_MAP_FORCE_ALLOC:
  OMP_CLAUSE_SET_MAP_KIND (node, GOMP_MAP_FORCE_ALLOC);
  break;
-   case OMP_MAP_FORCE_DEALLOC:
- OMP_CLAUSE_SET_MAP_KIND (node, GOMP_MAP_FORCE_DEALLOC);
- break;
case OMP_MAP_FORCE_TO:
  OMP_CLAUSE_SET_MAP_KIND (node, GOMP_MAP_FORCE_TO);
  break;
diff --git gcc/gimplify.c gcc/gimplify.c
index f3e5c39..3687e7a 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@ -8194,7 +8194,7 @@ 

[Bug c++/70205] [4.9/5 Regression] ICE on valid code on x86_64-linux-gnu: tree check: expected tree_binfo, have error_mark in add_candidates, at cp/call.c:5283

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression] ICE on |[4.9/5 Regression] ICE on
   |valid code on   |valid code on
   |x86_64-linux-gnu: tree  |x86_64-linux-gnu: tree
   |check: expected tree_binfo, |check: expected tree_binfo,
   |have error_mark in  |have error_mark in
   |add_candidates, at  |add_candidates, at
   |cp/call.c:5283  |cp/call.c:5283

--- Comment #11 from Patrick Palka  ---
Fixed on GCC 6 so far.

[Bug c++/70265] New: ICE on code with constexpr on x86_64-linux-gnu in tree check: expected statement_list, have nop_expr in tsi_start, at tree-iterator.h:42

[su at cs dot ucdavis.edu]

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

Bug ID: 70265
   Summary: ICE on code with constexpr on x86_64-linux-gnu in tree
check: expected statement_list, have nop_expr in
tsi_start, at tree-iterator.h:42
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following valid code causes an ICE when compiled with the current GCC trunk
on x86_64-linux-gnu in both 32-bit and 64-bit modes. 

It also seems to affect all 5.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160317 (experimental) [trunk revision 234278] (GCC) 
$ 
$ g++-trunk -c small.cpp
small2.cpp:10:20:   in constexpr expansion of ‘foo(1)’
small2.cpp:10:33: internal compiler error: tree check: expected statement_list,
have nop_expr in tsi_start, at tree-iterator.h:42
 static_assert (foo (1) == 0, "");
 ^
0xfe2bdc tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-source-trunk/gcc/tree.c:9643
0x5d17ff tree_check
../../gcc-source-trunk/gcc/tree.h:3006
0x5d17ff tsi_start
../../gcc-source-trunk/gcc/tree-iterator.h:42
0x85382f tsi_start
../../gcc-source-trunk/gcc/cp/constexpr.c:3105
0x85382f cxx_eval_statement_list
../../gcc-source-trunk/gcc/cp/constexpr.c:3136
0x84d024 cxx_eval_loop_expr
../../gcc-source-trunk/gcc/cp/constexpr.c:3184
0x84d024 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3842
0x8536b5 cxx_eval_statement_list
../../gcc-source-trunk/gcc/cp/constexpr.c:3152
0x84cf3a cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3776
0x84d18a cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3782
0x84c536 cxx_eval_call_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:1393
0x84d46b cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3374
0x850fdd cxx_eval_binary_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:1617
0x84d395 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3624
0x853999 cxx_eval_outermost_constant_expr
../../gcc-source-trunk/gcc/cp/constexpr.c:3939
0x85669c maybe_constant_value_1
../../gcc-source-trunk/gcc/cp/constexpr.c:4127
0x85669c maybe_constant_value(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/cp/constexpr.c:4148
0x7c2465 finish_static_assert(tree_node*, tree_node*, unsigned int, bool)
../../gcc-source-trunk/gcc/cp/semantics.c:8681
0x741520 cp_parser_static_assert
../../gcc-source-trunk/gcc/cp/parser.c:13050
0x753339 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12244
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 





constexpr int
foo (int p)
{
  int t = 0; 
  while (1) 
;
  return t;
}

static_assert (foo (1) == 0, "");

[Bug middle-end/70199] [5/6 Regression] Crash at -O2 when using labels.

[rth at gcc dot gnu.org]

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

--- Comment #6 from Richard Henderson  ---
Author: rth
Date: Wed Mar 16 16:50:18 2016
New Revision: 234261

URL: https://gcc.gnu.org/viewcvs?rev=234261=gcc=rev
Log:
PR middle-end/70199

 * function.h (struct function): Add has_forced_label_in_static.
 * gimplify.c (force_labels_r): Set it.
 * lto-streamer-in.c (input_struct_function_base): Read it.
 * lto-streamer-out.c (output_struct_function_base): Write it.
 * tree-inline.c (has_label_address_in_static_1): Remove.
 (copy_forbidden): Remove fndecl parameter; test
 has_forced_label_in_static.
 (inline_forbidden_p): Update call to copy_forbidden.
 (tree_versionable_function_p): Likewise.
 * ipa-chkp.c (chkp_instrumentable_p): Likewise.
 (chkp_versioning): Likewise.
 * tree-inline.h (copy_forbidden): Update decl.

testsuite/
 * gcc.c-torture/compile/pr70199.c: New.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr70199.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.h
trunk/gcc/gimplify.c
trunk/gcc/ipa-chkp.c
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer-out.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c
trunk/gcc/tree-inline.h

Re: [PATCH][ARM] Split out armv7ve effective target check

[Ramana Radhakrishnan]

On Wed, Mar 2, 2016 at 1:32 PM, Kyrill Tkachov
 wrote:
> Hi all,
>
> I'm seeing the fails:
> FAIL: gcc.target/arm/atomic_loaddi_2.c scan-assembler-times ldrd\tr[0-9]+,
> r[0-9]+, \\[r[0-9]+\\] 1
> FAIL: gcc.target/arm/atomic_loaddi_5.c scan-assembler-times ldrd\tr[0-9]+,
> r[0-9]+, \\[r[0-9]+\\] 1
> FAIL: gcc.target/arm/atomic_loaddi_8.c scan-assembler-times ldrd\tr[0-9]+,
> r[0-9]+, \\[r[0-9]+\\] 1
>
> when testing an arm multilib with /-march=armv7-a.
>
> The tests have an effective target check for armv7ve but it doesn't work
> because
> under the hood the check is the same as for armv7-a, that is it checks for
> the __ARM_ARCH_7A__
> predefine which is set for both march values.
>
> To check for armv7ve using predefines we need to check for both
> __ARM_ARCH_7A__ and for the hardware
> integer division predefine, making armv7ve special.
>
> So this patch separates the effective target check definition from the rest
> of the architectures
> and defines it appropriately.
>
> With this patch the aforementioned tests appear UNSUPPORTED when testing the
> /-march=armv7-a multilib.
>
> Ok for trunk?

Ok, but please follow up with updating sourcebuild.texi.

Ramana

>
> Thanks,
> Kyrill
>
> 2016-03-02  Kyrylo Tkachov  
>
> * lib/target-supports.exp: Remove v7ve entry from loop
> creating effective target checks.
> (check_effective_target_arm_arch_v7ve_ok): New procedure.
> (add_options_for_arm_arch_v7ve): Likewise.

[Bug middle-end/70273] [6 regression] FAIL: g++.dg/ext/label13a.C -std=gnu++98 execution test / scan-assembler _ZN1CC4Ev

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

  Attachment #38003|0   |1
is obsolete||

--- Comment #10 from Richard Henderson  ---
Created attachment 38034
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38034=edit
second patch

The first patch fails full testing.  We fail to remap
the label for some reason without leaving it on the 
local decl list.

Scan for parallelization of the oacc kernels test-cases in gfortran.dg/goacc (was: [PATCH, 15/16] Add libgomp.oacc-c-c++-common/kernels-*.c)

[Thomas Schwinge]

Hi!

On Wed, 9 Mar 2016 10:17:28 +0100, Tom de Vries  wrote:
> [Should have cited
> 
> instead of the C/C++ tests]

> Retested on current trunk.
> 
> Committed, minus the kernels-parallel-loop-data-enter-exit.f95 test.

Is there a reason why you omitted the following tree scanning tests (as
done for C/C++, and also present for Fortran on gomp-4_0-branch)?  (Note
that I had to XFAIL gfortran.dg/goacc/kernels-loop-n.f95.)  OK to commit?

commit f0294eeb30ef285c3930b975ccbc1b6d7052cc03
Author: Thomas Schwinge 
Date:   Fri Mar 18 12:52:37 2016 +0100

Scan for parallelization of the oacc kernels test-cases in gfortran.dg/goacc

gcc/testsuite/
* gfortran.dg/goacc/kernels-loop-2.f95: Scan for parallelization.
* gfortran.dg/goacc/kernels-loop-data-2.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-data-enter-exit-2.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-data-enter-exit.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-data-update.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-data.f95: Likewise.
* gfortran.dg/goacc/kernels-loop.f95: Likewise.
* gfortran.dg/goacc/kernels-loop-n.f95: Likewise, XFAILed.
---
 gcc/testsuite/gfortran.dg/goacc/kernels-loop-2.f95 | 2 ++
 gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-2.f95| 1 +
 gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-enter-exit-2.f95 | 2 ++
 gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-enter-exit.f95   | 2 ++
 gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-update.f95   | 2 ++
 gcc/testsuite/gfortran.dg/goacc/kernels-loop-data.f95  | 2 ++
 gcc/testsuite/gfortran.dg/goacc/kernels-loop-n.f95 | 7 +++
 gcc/testsuite/gfortran.dg/goacc/kernels-loop.f95   | 2 ++
 8 files changed, 20 insertions(+)

diff --git gcc/testsuite/gfortran.dg/goacc/kernels-loop-2.f95 
gcc/testsuite/gfortran.dg/goacc/kernels-loop-2.f95
index 5cc2e8b..865f7a6 100644
--- gcc/testsuite/gfortran.dg/goacc/kernels-loop-2.f95
+++ gcc/testsuite/gfortran.dg/goacc/kernels-loop-2.f95
@@ -40,3 +40,5 @@ end program main
 ! { dg-final { scan-tree-dump-times "(?n);; Function MAIN__._omp_fn.0 " 1 
"optimized" } }
 ! { dg-final { scan-tree-dump-times "(?n);; Function MAIN__._omp_fn.1 " 1 
"optimized" } }
 ! { dg-final { scan-tree-dump-times "(?n);; Function MAIN__._omp_fn.2 " 1 
"optimized" } }
+
+! { dg-final { scan-tree-dump-times "(?n)oacc function \\(0," 3 "parloops1" } }
diff --git gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-2.f95 
gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-2.f95
index d1bfc70..c9f3a62 100644
--- gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-2.f95
+++ gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-2.f95
@@ -47,3 +47,4 @@ end program main
 ! { dg-final { scan-tree-dump-times "(?n);; Function MAIN__._omp_fn.1 " 1 
"optimized" } }
 ! { dg-final { scan-tree-dump-times "(?n);; Function MAIN__._omp_fn.2 " 1 
"optimized" } }
 
+! { dg-final { scan-tree-dump-times "(?n)oacc function \\(0," 3 "parloops1" } }
diff --git gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-enter-exit-2.f95 
gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-enter-exit-2.f95
index feac7b2..3361607 100644
--- gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-enter-exit-2.f95
+++ gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-enter-exit-2.f95
@@ -46,3 +46,5 @@ end program main
 ! { dg-final { scan-tree-dump-times "(?n);; Function MAIN__._omp_fn.0 " 1 
"optimized" } }
 ! { dg-final { scan-tree-dump-times "(?n);; Function MAIN__._omp_fn.1 " 1 
"optimized" } }
 ! { dg-final { scan-tree-dump-times "(?n);; Function MAIN__._omp_fn.2 " 1 
"optimized" } }
+
+! { dg-final { scan-tree-dump-times "(?n)oacc function \\(0," 3 "parloops1" } }
diff --git gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-enter-exit.f95 
gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-enter-exit.f95
index 632983f..5ba56fb 100644
--- gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-enter-exit.f95
+++ gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-enter-exit.f95
@@ -44,3 +44,5 @@ end program main
 ! { dg-final { scan-tree-dump-times "(?n);; Function MAIN__._omp_fn.0 " 1 
"optimized" } }
 ! { dg-final { scan-tree-dump-times "(?n);; Function MAIN__._omp_fn.1 " 1 
"optimized" } }
 ! { dg-final { scan-tree-dump-times "(?n);; Function MAIN__._omp_fn.2 " 1 
"optimized" } }
+
+! { dg-final { scan-tree-dump-times "(?n)oacc function \\(0," 3 "parloops1" } }
diff --git gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-update.f95 
gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-update.f95
index 41b0d96..a622a96 100644
--- gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-update.f95
+++ gcc/testsuite/gfortran.dg/goacc/kernels-loop-data-update.f95
@@ -43,3 +43,5 @@ end program main
 ! Check that the loop has been split off into a 

[Bug target/70232] [6 regression] excessive stack usage with -O2

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Thomas Preud'homme from comment #9)
> (In reply to Richard Biener from comment #7)
> > The bswap pass could learn to split this up into two loads and bswaps and
> > combine the results with a single shift and or.
> 
> I'll add it to the bswap TODO list. Thanks.

Actually handles it via builtin_bswap64 already and generic code in optabs.c

But somehow bswap64 is still not detected for me on arm (works on x86-64 with
-m32).

[Bug c/70257] New: #line incorrectly handled in error messages

[rowe-gcc at excc dot ex.ac.uk]

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

Bug ID: 70257
   Summary: #line incorrectly handled in error messages
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rowe-gcc at excc dot ex.ac.uk
  Target Milestone: ---

When the following code is compiled with gcc -Wall :

// This line intentionally left blank
#line 1
#include 
int main() {
int k;

  return 0;
}

it produces the following:

text.c: In function ‘main’:
text.c:3:9: warning: unused variable ‘k’ [-Wunused-variable]
 #include 
 ^

Clearly although the #line directive is being recognised by the traditional
error code, the wrong line is then highlighted.
The version is: gcc (GCC) 5.3.0

Thanks for all your work on GCC.

John

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
--- gcc-5.3.0.old/libstdc++-v3/include/std/thread   2015-03-26
20:59:08.0 +0100
+++ gcc-5.3.0.old/libstdc++-v3/include/std/thread   2016-03-17
06:32:41.124378000 +0100
@@ -83,10 +83,19 @@ 
   operator==(thread::id __x, thread::id __y) noexcept
   { return __gthread_equal(__x._M_thread, __y._M_thread); }

+  // implement operator< explicitly in terms of the internals of
+  // pthreads-win32's ptw32_handle_t so that std::thread can use pthreads
+#ifdef PTW32_VERSION
+  friend bool
+  operator<(thread::id __x, thread::id __y)
+  { return ( (__x._M_thread.p < __y._M_thread.p) || 
+ ((__x._M_thread.p == __y._M_thread.p) && (__x._M_thread.x <
__y._M_thread.x) ) ); }

I suggest:

 return std::tie(__x._M_thread.p, __x._M_thread.x)
  < std::tie(__y._M_thread.p, __y._M_thread.x);

+#else
   friend bool
   operator<(thread::id __x, thread::id __y) noexcept
-  { return __x._M_thread < __y._M_thread; }
-
+  {return __less::_S_less(__x._M_thread,
__y._M_thread); }
+#endif
+  

What's this?

[Bug target/70232] [6 regression] excessive stack usage with -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||thopre01 at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
(In reply to Arnd Bergmann from comment #4)
> I've tried out a few more things as well, to see if the alignment of the
> struct lpfc_name type or the builtin memcpy makes a different. Replacing the
> array of eight bytes with a single uint64_t and scalar operations instead of
> string functions makes very little difference, so it seems to be neither of
> them.
> 
> However, I think the wwn_to_uint64_t() function is what causes the problem.
> This is supposed to be turned into a direct load or a byte reversing load
> depending on endianess, but this apparently does not happen.

I'm not aware of such transform - we have the 'bswap' pass on GIMPLE
but that only looks for the direct load case (-mbig-endian):

64 bit load in target endianness found at: _95 = MEM[(uint8_t
*)vport_wwpn_14(D)];
64 bit load in target endianness found at: _125 = MEM[(uint8_t
*)target_wwpn_16(D)];
64 bit load in target endianness found at: _167 = MEM[(uint8_t
*)vport_wwpn_14(D)];
64 bit load in target endianness found at: _197 = MEM[(uint8_t
*)target_wwpn_16(D)];
64 bit load in target endianness found at: _236 = MEM[(uint8_t
*)vport_wwpn_14(D)];
64 bit load in target endianness found at: _266 = MEM[(uint8_t
*)target_wwpn_16(D)];

as there is no "standard" target independent way to express a byte
reversed load (optab or so).  The closest we'd have is to "vectorize"
this as

  tem = load v8qi;
  tem = vec_perm ;
  ... = VIEW_CONVERT ;

if both the vector mode exists and the constant permute is handled
by the target.  The target would then need to combine the load
and the permute into a reversing load (if the target indeed has such
instruction).

> Adding -mbig-endian to the compiler flags brings the stack usage down, so
> presumably the optimization step that identifies byteswap patters is what
> causes the stack growth.

[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
> We'd likely want to warn in merge_decls for this case.

"this case" == all optimization attributes applied via newdecl to
olddecl with DECL_SAVED_TREE (or DECL_INITIAL?) set.

Re: [PATCH][ARM][testsuite][committed] Do not override -mcpu in no-volatile-in-it.c

[Ramana Radhakrishnan]

On Fri, Mar 18, 2016 at 10:31 AM, Andre Vieira (lists)
 wrote:
> On 16/07/15 16:31, Kyrill Tkachov wrote:
>> Hi all,
>>
>> This scan-assembler test was failing for me when testing with an
>> explicit /-march=armv7-a variant because
>> it clashed with the -mcpu=cortex-m7 and overrode it.
>>
>> This patch skips the test if the user forces an incompatible -march or
>> -mcpu option.
>> The test now appears as UNSUPPORTED in these conditions and PASSes
>> normally.
>>
>> Applied as obvious with r225892.
>>
>> Thanks,
>> Kyrill
>>
>> 2015-07-16  Kyrylo Tkachov  
>>
>> * gcc.target/arm/no-volatile-in-it.c: Skip if -mcpu is overriden.
>
> OK to backport this to gcc-5-branch?

Ok ... it was *obvious* , if you're hitting it on the gcc-5 branch
then apply it.

Ramana
>
> Cheers,
> Andre

[PATCH, PR tree-optimization/70251] Disable VEC_COND_EXPR transformation into VIEW_CONVERT_EXPR for scalar mask case

[Ilya Enkovich]

Hi,

This patch disables two match.pd patterns which transform
VEC_COND_EXPR into simple conversion in case it uses a scalar mask.
The patch was bootstrapped and regtested on x86_64-pc-linux-gnu +
separate check for new test on SDE.  OK for trunk?

Thanks,
Ilya
--
gcc/

2016-03-17  Ilya Enkovich  

* match.pd (A + (B vcmp C ? 1 : 0) -> A - (B vcmp C)): Apply
for boolean vector with vector mode only.
(A - (B vcmp C ? 1 : 0) -> A + (B vcmp C)): Likewise.

gcc/testsuite/

2016-03-17  Ilya Enkovich  

* gcc.target/i386/pr70251.c: New test.


diff --git a/gcc/match.pd b/gcc/match.pd
index 112deb3..7245ff4 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1759,6 +1759,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (simplify
  (plus:c @3 (view_convert? (vec_cond @0 integer_each_onep@1 integer_zerop@2)))
  (if (VECTOR_TYPE_P (type)
+  && VECTOR_MODE_P (TYPE_MODE (TREE_TYPE (@0)))
   && TYPE_VECTOR_SUBPARTS (type) == TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0))
   && (TYPE_MODE (TREE_TYPE (type))
   == TYPE_MODE (TREE_TYPE (TREE_TYPE (@0)
@@ -1768,6 +1769,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (simplify
  (minus @3 (view_convert? (vec_cond @0 integer_each_onep@1 integer_zerop@2)))
  (if (VECTOR_TYPE_P (type)
+  && VECTOR_MODE_P (TYPE_MODE (TREE_TYPE (@0)))
   && TYPE_VECTOR_SUBPARTS (type) == TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0))
   && (TYPE_MODE (TREE_TYPE (type))
   == TYPE_MODE (TREE_TYPE (TREE_TYPE (@0)
diff --git a/gcc/testsuite/gcc.target/i386/pr70251.c 
b/gcc/testsuite/gcc.target/i386/pr70251.c
new file mode 100644
index 000..97078cd
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr70251.c
@@ -0,0 +1,52 @@
+/* { dg-do run } */
+/* { dg-options "-O3 -mavx512bw" } */
+/* { dg-require-effective-target avx512bw } */
+
+#define AVX512BW
+#include "avx512f-helper.h"
+
+unsigned long long int
+hash(unsigned long long int seed, unsigned long long int v)
+{
+  return seed ^ (v + 0x9e3779b9 + (seed<<6) + (seed>>2));
+}
+
+unsigned int a [100];
+signed char b [100];
+signed char c [100];
+
+void
+init ()
+{
+  for (int i = 0; i < 100; ++i)
+{
+  a [i] = 1000L;
+  b [i] = 10;
+  c [i] = 5;
+}
+}
+
+void
+foo ()
+{
+  for (int i = 0; i < 100; ++i)
+b [i] = (!b [i] ^ (a [i] >= b [i])) + c [i];
+}
+
+unsigned long long int
+checksum ()
+{
+  unsigned long long int seed = 0ULL;
+  for (int i = 0; i < 100; ++i)
+seed = hash (seed, b[i]);
+  return seed;
+}
+
+void
+TEST ()
+{
+  init ();
+  foo ();
+  if (checksum () != 5785906989299578598ULL)
+__builtin_abort ();
+}

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[ralphengels at gmail dot com]

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

--- Comment #13 from ralphengels at gmail dot com  ---
Also needs a small change in pthread.h to guard against including windows.h

#if defined(PTW32_CONFIG_MINGW) && defined(__cplusplus)

change to

#if defined(PTW32_CONFIG_MINGW) && defined(PTW32_BUILD) && defined(__cplusplus)

[Bug rtl-optimization/70030] [LRA]ICE when reload insn with output scratch operand

[vmakarov at gcc dot gnu.org]

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

--- Comment #6 from Vladimir Makarov  ---
Created attachment 38033
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38033=edit
A patch

Here is the patch which might solve the problem.

C++ PATCH for c++/70147 (-fsanitize=vptr, -flifetime-dse, and virtual bases)

[Jason Merrill]

The first patch factors out testing of current_in_charge_parm from 
various places in the compiler into a new build_if_in_charge function.


The second patch implements Bernd's suggestion for modifying 
-flifetime-dse so that when we have virtual bases, we clobber the entire 
object, but only when we are in charge (and therefore know we are in the 
constructor for a complete object, and don't need to worry about tail 
padding).


The third patch adjusts the -fsanitize=vptr vptr clearing so that we 
don't clear the vptr for a virtual base when we aren't in charge of 
virtual bases, even if the current class shares the vptr from a primary 
virtual base.


The testcase tests all of these changes.

Tested x86_64-pc-linux-gnu, applying to trunk.

commit 4cffe7ea961ed6b602a954c616f5186f27c85db5
Author: Jason Merrill 
Date:   Thu Mar 17 17:22:43 2016 -0400

	* class.c (build_if_in_charge): Split out from build_base_path.

	* init.c (expand_virtual_init, expand_default_init): Use it.
	* call.c (build_special_member_call): Use it.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 34c1d9b..d445163 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8082,11 +8082,7 @@ build_special_member_call (tree instance, tree name, vec **args,
   vtt = decay_conversion (vtt, complain);
   if (vtt == error_mark_node)
 	return error_mark_node;
-  vtt = build3 (COND_EXPR, TREE_TYPE (vtt),
-		build2 (EQ_EXPR, boolean_type_node,
-			current_in_charge_parm, integer_zero_node),
-		current_vtt_parm,
-		vtt);
+  vtt = build_if_in_charge (vtt, current_vtt_parm);
   if (BINFO_SUBVTT_INDEX (binfo))
 	sub_vtt = fold_build_pointer_plus (vtt, BINFO_SUBVTT_INDEX (binfo));
   else
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index f8ecfa1..866a0a4 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -225,6 +225,24 @@ int n_convert_harshness = 0;
 int n_compute_conversion_costs = 0;
 int n_inner_fields_searched = 0;
 
+/* Return a COND_EXPR that executes TRUE_STMT if this execution of the
+   'structor is in charge of 'structing virtual bases, or FALSE_STMT
+   otherwise.  */
+
+tree
+build_if_in_charge (tree true_stmt, tree false_stmt)
+{
+  gcc_assert (DECL_HAS_IN_CHARGE_PARM_P (current_function_decl));
+  tree cmp = build2 (NE_EXPR, boolean_type_node,
+		 current_in_charge_parm, integer_zero_node);
+  tree type = unlowered_expr_type (true_stmt);
+  if (VOID_TYPE_P (type))
+type = unlowered_expr_type (false_stmt);
+  tree cond = build3 (COND_EXPR, type,
+		  cmp, true_stmt, false_stmt);
+  return cond;
+}
+
 /* Convert to or from a base subobject.  EXPR is an expression of type
`A' or `A*', an expression of type `B' or `B*' is returned.  To
convert A to a base B, CODE is PLUS_EXPR and BINFO is the binfo for
@@ -470,12 +488,9 @@ build_base_path (enum tree_code code,
 	/* Negative fixed_type_p means this is a constructor or destructor;
 	   virtual base layout is fixed in in-charge [cd]tors, but not in
 	   base [cd]tors.  */
-	offset = build3 (COND_EXPR, ptrdiff_type_node,
-			 build2 (EQ_EXPR, boolean_type_node,
- current_in_charge_parm, integer_zero_node),
-			 v_offset,
-			 convert_to_integer (ptrdiff_type_node,
-	 BINFO_OFFSET (binfo)));
+	offset = build_if_in_charge
+	  (convert_to_integer (ptrdiff_type_node, BINFO_OFFSET (binfo)),
+	   v_offset);
   else
 	offset = v_offset;
 }
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index a50d92c..497430a 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5642,6 +5642,7 @@ extern tree get_function_version_dispatcher	(tree);
 
 /* in class.c */
 extern tree build_vfield_ref			(tree, tree);
+extern tree build_if_in_charge			(tree true_stmt, tree false_stmt = void_node);
 extern tree build_base_path			(enum tree_code, tree,
 		 tree, int, tsubst_flags_t);
 extern tree convert_to_base			(tree, tree, bool, bool,
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 22c039b..aee3b84 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -1243,12 +1243,7 @@ expand_virtual_init (tree binfo, tree decl)
   /* The actual initializer is the VTT value only in the subobject
 	 constructor.  In maybe_clone_body we'll substitute NULL for
 	 the vtt_parm in the case of the non-subobject constructor.  */
-  vtbl = build3 (COND_EXPR,
-		 TREE_TYPE (vtbl),
-		 build2 (EQ_EXPR, boolean_type_node,
-			 current_in_charge_parm, integer_zero_node),
-		 vtbl2,
-		 vtbl);
+  vtbl = build_if_in_charge (vtbl, vtbl2);
 }
 
   /* Compute the location of the vtpr.  */
@@ -1741,11 +1736,7 @@ expand_default_init (tree binfo, tree true_exp, tree exp, tree init, int flags,
 	, binfo, flags,
 	complain);
   base = fold_build_cleanup_point_expr (void_type_node, base);
-  rval = build3 (COND_EXPR, void_type_node,
-		 build2 (EQ_EXPR, boolean_type_node,
-			 current_in_charge_parm, integer_zero_node),
-		 base,
-		 complete);
+  rval = 

[Bug fortran/69739] [4.9/5/6 Regression] ICE during array result, allocatable assignment

[anlauf at gmx dot de]

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

--- Comment #4 from Harald Anlauf  ---
(In reply to Harald Anlauf from comment #3)
> (In reply to John from comment #2)
> > So maybe the automatic-size result is the actual root of the ICE?
> 
> If I use
> 
> real  :: operate(1:size(A))
> 
> instead of
> 
> real  :: operate(1:PRODUCT(UBOUND(A)))
> 
> I do not get an ICE.  So it's not automatic-size per se.

More testing: both

real  :: operate(1:UBOUND(A,1)*UBOUND(A,2)*UBOUND(A,3))

and

real  :: operate(1:PRODUCT(shape (A)))

appear ok.

[Bug tree-optimization/70267] ICE on valid code at -O1 and above on x86_64-linux-gnu in propagate_necessity, at tree-ssa-dce.c:924

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
We ICE in propagate_necessity because it can't digest
# VUSE <.MEM_3>
f.0_4 = (struct Foo *) D.2296;
which is 
(gdb) p gimple_code(stmt)
$2 = GIMPLE_ASSIGN
but
(gdb) p gimple_assign_single_p (stmt)
$3 = false
thus we end up in the gcc_unreachable (); branch there.

[Bug target/70292] New: ICE in verify_target_availability, at sel-sched.c:1584 with -fno-inline -fno-dce -fschedule-insns -fselective-scheduling -fno-tree-dce -O1

[tarasevich at cs dot uni-saarland.de]

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

Bug ID: 70292
   Summary: ICE in verify_target_availability, at sel-sched.c:1584
with -fno-inline -fno-dce -fschedule-insns
-fselective-scheduling -fno-tree-dce -O1
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tarasevich at cs dot uni-saarland.de
  Target Milestone: ---

Created attachment 38016
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38016=edit
test case with ICE

This might be a duplicate of bug 64411

../build/gcc_530_clean_bin/bin/gcc test_case_52485.c -fno-inline -fno-dce
-fschedule-insns -fselective-scheduling -fno-tree-dce -O1 -save-temps -v
Using built-in specs.
COLLECT_GCC=../build/gcc_530_clean_bin/bin/gcc
COLLECT_LTO_WRAPPER=/home/tarasevich/build/gcc_530_clean_bin/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../../source/gcc_530/configure
--prefix=/home/tarasevich/build/gcc_530_clean_bin/ --enable-languages=c
--disable-multilib --disable-bootstrap
CC=/home/tarasevich/build/llvm_371_bin/bin/clang
CXX=/home/tarasevich/build/llvm_371_bin/bin/clang++
Thread model: posix
gcc version 5.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-fno-inline' '-fno-dce' '-fschedule-insns'
'-fselective-scheduling' '-fno-tree-dce' '-O1' '-save-temps' '-v'
'-mtune=generic' '-march=x86-64'

/home/tarasevich/build/gcc_530_clean_bin/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/cc1
-E -quiet -v -imultiarch x86_64-linux-gnu test_case_52485.c -mtune=generic
-march=x86-64 -fno-inline -fno-dce -fschedule-insns -fselective-scheduling
-fno-tree-dce -O1 -fpch-preprocess -o test_case_52485.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/home/tarasevich/build/gcc_530_clean_bin/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/home/tarasevich/build/gcc_530_clean_bin/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include
 /usr/local/include
 /home/tarasevich/build/gcc_530_clean_bin/include

/home/tarasevich/build/gcc_530_clean_bin/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-fno-inline' '-fno-dce' '-fschedule-insns'
'-fselective-scheduling' '-fno-tree-dce' '-O1' '-save-temps' '-v'
'-mtune=generic' '-march=x86-64'

/home/tarasevich/build/gcc_530_clean_bin/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/cc1
-fpreprocessed test_case_52485.i -quiet -dumpbase test_case_52485.c
-mtune=generic -march=x86-64 -auxbase test_case_52485 -O1 -version -fno-inline
-fno-dce -fschedule-insns -fselective-scheduling -fno-tree-dce -o
test_case_52485.s
GNU C11 (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.1 Compatible Clang 3.7.1
(tags/RELEASE_371/final 263010), GMP version 5.1.3, MPFR version 3.1.2-p3, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.1 Compatible Clang 3.7.1
(tags/RELEASE_371/final 263010), GMP version 5.1.3, MPFR version 3.1.2-p3, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c53bb545b4c066cdbf5e42f0b9d9ad8b
test_case_52485.c: In function 't106_1mul':
test_case_52485.c:9:1: internal compiler error: in verify_target_availability,
at sel-sched.c:1584
 }
 ^
0x906ac3 verify_target_availability(_expr*, bitmap_head*, reg_rename*)
../../../source/gcc_530/gcc/sel-sched.c:1581
0x906ac3 find_best_reg_for_expr(_expr*, _list_node*, bool*)
../../../source/gcc_530/gcc/sel-sched.c:1696
0x906ac3 fill_vec_av_set(_list_node*, _list_node*, _fence*, int*)
../../../source/gcc_530/gcc/sel-sched.c:3810
0x906ac3 fill_ready_list(_list_node**, _list_node*, _fence*, int*)
../../../source/gcc_530/gcc/sel-sched.c:4040
0x906ac3 find_best_expr(_list_node**, _list_node*, _fence*, int*)
../../../source/gcc_530/gcc/sel-sched.c:4403
0x906ac3 fill_insns(_fence*, int, _list_node***)
../../../source/gcc_530/gcc/sel-sched.c:5570
0x901fae schedule_on_fences(_list_node*, int, _list_node***)
../../../source/gcc_530/gcc/sel-sched.c:7395
0x901fae sel_sched_region_2(int)
../../../source/gcc_530/gcc/sel-sched.c:7533
0x8fe717 sel_sched_region_1()
../../../source/gcc_530/gcc/sel-sched.c:7575
0x8fe717 sel_sched_region(int)
../../../source/gcc_530/gcc/sel-sched.c:7676
0x8ff976 run_selective_scheduling()
../../../source/gcc_530/gcc/sel-sched.c:7752
0x8ed24e rest_of_handle_sched()
../../../source/gcc_530/gcc/sched-rgn.c:3633
0x8ed24e (anonymous 

[Bug fortran/70233] Missing diagnostic in array constructor, different size strings

[anlauf at gmx dot de]

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

--- Comment #4 from Harald Anlauf  ---
(In reply to Harald Anlauf from comment #2)
> Created attachment 37982 [details]
> Patch to generate error message

This patch leads to serious regressions.  Do not
yet understand why.  Withdrawing...

[Bug c++/70285] [6 Regression] ICE on valid code on x86_64-linux-gnu: verify_gimple failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
In particular, we hit the
  /* [expr.cond]

 If the second and third operands are glvalues of the same value
 category and have the same type, the result is of that type and
 value category.  */
  if (((real_lvalue_p (arg2) && real_lvalue_p (arg3))
   || (xvalue_p (arg2) && xvalue_p (arg3)))
  && same_type_p (arg2_type, arg3_type))
{
  result_type = arg2_type;
  arg2 = mark_lvalue_use (arg2);
  arg3 = mark_lvalue_use (arg3);
  goto valid_operands;
}
case, and therefore bypass any promotion.
As I said, arg2 has type signed char, arg2_type is int, arg3 has type int and
arg3_type is int.
So, the question is what C++ says here we should do with the bitfields.
Shall it call same_type_p (TREE_TYPE (arg2), TREE_TYPE (arg3)) instead?  Saying
that int :8 bitfield has the same type as int is just weird.
But, what would happen if both arms are say the int :8 bitfields?  The result
type will be still int, different from the arm types.
Let's CC Jason on this.

[Bug tree-optimization/70291] muldc3 code generation could be smarter

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-18
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug c++/70265] ICE on code with constexpr on x86_64-linux-gnu in tree check: expected statement_list, have nop_expr in tsi_start, at tree-iterator.h:42

[su at cs dot ucdavis.edu]

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

--- Comment #1 from Zhendong Su  ---
A slight variation of the test causes GCC to hang (apparently in evaluating the
infinite loop). 


$ timeout -s 9 10 g++-trunk -c small.cpp
Killed
$ 
$ clang++-trunk -std=c++14 -c small.cpp
small.cpp:2:1: error: constexpr function never produces a constant expression
[-Winvalid-constexpr]
foo (int p)
^
small.cpp:6:5: note: constexpr evaluation hit maximum step limit; possible
infinite loop?
t = 0; 
^
small.cpp:10:16: error: static_assert expression is not an integral constant
expression
static_assert (foo (1) == 0, "");
   ^~~~
small.cpp:6:5: note: constexpr evaluation hit maximum step limit; possible
infinite loop?
t = 0; 
^
small.cpp:10:16: note: in call to 'foo(1)'
static_assert (foo (1) == 0, "");
   ^
2 errors generated.
$ 





constexpr int
foo (int p)
{
  int t = 0; 
  while (1) 
t = 0; // was ';' 
  return t;
}

static_assert (foo (1) == 0, "");

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

[H.J. Lu]

On Tue, Mar 15, 2016 at 7:51 PM, Jason Merrill  wrote:
> On 03/15/2016 08:25 PM, Joseph Myers wrote:
>>
>> On Tue, 15 Mar 2016, H.J. Lu wrote:
>>
>>> On Tue, Mar 15, 2016 at 3:34 PM, Joseph Myers 
>>> wrote:

 On Tue, 15 Mar 2016, H.J. Lu wrote:

> On Tue, Mar 15, 2016 at 2:39 PM, Joseph Myers 
> wrote:
>>
>> I'm not sure if the zero-size arrays (a GNU extension) are considered
>> to
>> make a struct non-empty, but in any case I think the tests should
>> cover
>> such arrays as elements of structs.
>
>
> There are couple tests for structs with members of array
> of empty types.  testsuite/g++.dg/abi/empty14.h has


 My concern is the other way round - structs with elements such as
 "int a[0];", an array [0] of a nonempty type.  My reading of the
 subobject
 definition is that such an array should not cause the struct to be
 considered nonempty (it doesn't result in any int subobjects).
>>>
>>>
>>> This is a test for struct with zero-size array, which isn't treated
>>> as empty type.  C++ and C are compatible in its passing.
>>
>>
>> Where is the current definition of empty types you're proposing for use in
>> GCC?  Is the behavior of this case clear from that definition?
>
>
> "An empty type is a type where it and all of its subobjects (recursively)
> are of structure, union, or array type.  No memory slot nor register should
> be used to pass or return an object of empty type."
>
> It seems to me that such a struct should be considered an empty type under
> this definition, since a zero-length array has no subobjects.
>

Since zero-size array is GCC extension, we can change it.   Do we
want to change its passing for C?

-- 
H.J.

[Bug c/70150] Additonal test failures with --enable-default-pie

[hjl.tools at gmail dot com]

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

Bug 70192 Summary: -fno-pic doesn't work with --enable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70192

   What|Removed |Added

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

[Bug fortran/70260] ICE: gimplification failed

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #4 from Harald Anlauf  ---
(In reply to Gerhard Steinmetz from comment #1)
> Another situation :
> 
> 
> $ cat z3.f90
> subroutine s (f)
>integer, external :: f, g
>integer :: h
>g = f(2)
>h = g(2)
> end

Commenting out the assignment to h, I get:

% gfc-trunk pr70260-z3.f90
pr70260-z3.f90:4:3:

g = f(2)
   1
Error: 'g' in variable definition context (assignment) at (1) is not a variable

Re: Is test case with 700k lines of code a valid test case?

[Jakub Jelinek]

On Fri, Mar 18, 2016 at 02:02:48PM +, Jonathan Wakely wrote:
> On 18 March 2016 at 12:45, Paulo Matos wrote:
> >> I have a source file with 700k lines of code 99% of which are printf() 
> >> statements. Compiling this test case crashes GCC 5.3.0 with segmentation 
> >> fault.
> >> Can such test case be considered valid or source files of size 35 MB are 
> >> too much for a C compiler and it should crash? It crashes on Ubuntu 14.04 
> >> 64bit with 16GB of RAM.
> >>
> >> Cheers,
> >> Andrey
> >>
> >
> > I would think it's useful but a reduced version would be great.
> > Can you reduce the test? If you need a hand, I can help. Contact me
> > directly and I will give it a try.
> 
> It's probably crashing because it's too large, so if you reduce it
> then it won't crash.

But if most of the lines are pretty much the same or similar, it might be
worth trying to recreate it with preprocessor macros.  Just pick up a couple
of most common lines and duplicate them as many times as needed to try to
get the testcase into similar size.

Jakub

[Bug c++/70205] [4.9/5/6 Regression] ICE on valid code on x86_64-linux-gnu: tree check: expected tree_binfo, have error_mark in add_candidates, at cp/call.c:5283

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  ---
Thanks a lot Marek. The patch makes sense to me, I would recommend fully
regression testing it and sending it to the mailing list.

Re: [PATCH] Fix PR c++/70121 (premature folding of const var that was implicitly captured)

[Patrick Palka]

On Thu, Mar 10, 2016 at 6:06 PM, Patrick Palka  wrote:
> On Thu, Mar 10, 2016 at 5:58 PM, Patrick Palka  wrote:
>> Within a lambda we should implicitly capture an outer const variable
>> only if it's odr-used in the body of the lambda.  But we are currently
>> making the decision of whether to capture such a variable, or else to
>> fold it to a constant, too early -- before we can know whether it's
>> being odr-used or not.  So we currently always fold a const variable to
>> a constant if possible instead of otherwise capturing it, but of course
>> doing this is wrong if e.g. the address of this variable is taken inside
>> the lambda's body.
>>
>> This patch reverses the behavior of process_outer_var_ref, so that we
>> always implicitly capture a const variable if it's capturable, instead
>> of always trying to first fold it to a constant.  This behavior however
>> is wrong too, and introduces a different but perhaps less important
>> regression: if we implicitly capture by value a const object that is not
>> actually odr-used within the body of the lambda, we may introduce a
>> redundant call to its copy/move constructor, see pr70121-2.C.
>>
>> Ideally we should be capturing a variable only if it's not odr-used
>
> Er, this sentence should read
>
>   Ideally we should be _implicitly_ capturing a variable only if it
> _is_ odr-used ...

Ping.

[Bug rtl-optimization/63384] scheduler loops on endless fence list with -fselective-scheduling2 on x86

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #7 from Jeffrey A. Law  ---
Fixed on the trunk.

Re: [PATCH] c++/67376 Comparison with pointer to past-the-end, of array fails inside constant expression

[Jeff Law]

On 03/14/2016 04:13 PM, Jakub Jelinek wrote:

On Mon, Mar 14, 2016 at 03:25:07PM -0600, Martin Sebor wrote:

PR c++/67376 - [5/6 regression] Comparison with pointer to past-the-end
of array fails inside constant expression
PR c++/70170 - [6 regression] bogus not a constant expression error comparing
pointer to array to null
PR c++/70172 - incorrect reinterpret_cast from integer to pointer error
on invalid constexpr initialization
PR c++/60760 - arithmetic on null pointers should not be allowed in constant
expressions
PR c++/70228 - insufficient detail in diagnostics for a constexpr out of bounds
array subscript


Can you please check up the formatting in the patch?
Seems e.g. you've replaced tons of tabs with 8 spaces etc. (check your
editor setting, and check the patch with contrib/check-GNU-style.sh).
There is some trailing whitespace too, spaces before [, etc.
Jakub, do you have any comments on the substance of the patch?  If so, 
it would help immensely if you could provide them so that Martin could 
address technical issues at the same time as he fixes up whitespace nits.


jeff

[Bug c/70255] change of the order of summation of floating point numbers despite no-associative-math

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
We'd likely want to warn in merge_decls for this case.

[Bug sanitizer/70147] [6 Regression] testcase from hana testsuite gets miscompiled with -fsanitize=undefined

[jason at gcc dot gnu.org]

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

--- Comment #27 from Jason Merrill  ---
(In reply to Bernd Edlinger from comment #26)
> I just fail to understand why we cannot just clobber the whole
> object once in the in-charge constructor,
> then if sanitizing vptrs initialize every vptr once to zero.
> and skip all the clobber and vptr initializing on the
> not in-charge constructors.

That sounds fine, for classes with virtual bases.

Re: [RFA][PR rtl-optimization/70263] Fix creation of new REG_EQUIV notes

[Jakub Jelinek]

On Fri, Mar 18, 2016 at 04:05:08PM -0400, David Malcolm wrote:
> On Fri, 2016-03-18 at 13:20 -0600, Jeff Law wrote:
> > On 03/18/2016 01:16 PM, Bernd Schmidt wrote:
> > > On 03/18/2016 08:14 PM, Jeff Law wrote:
> > > > I also added a blurb to the dump file when we create these
> > > > equivalences
> > > > and included a test to verify the code fires.  I verified it
> > > > fired on
> > > > x86 and x86-64.  It may or may not fire on other targets, so I
> > > > left the
> > > > test in the i386 specific subdirectory.
> > > 
> > > This is the sort of thing I'd want to do with rtl unit tests.
> 
> Would you like an RTL frontend?  (and something like a 
>  gcc/testsuite/rtl.dg/ )

That really shouldn't be hard, we already have RTL readers and RTL writers,
of course e.g. stuff where RTL refers to trees will be harder (or we could
just not fill it in).

Jakub

[Bug libstdc++/70294] New: operator< and operator== for std::thread::id only findable by ADL

[redi at gcc dot gnu.org]

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

Bug ID: 70294
   Summary: operator< and operator== for std::thread::id only
findable by ADL
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 
bool (*lt)(std::thread::id, std::thread::id) = ::operator<;
bool (*eq)(std::thread::id, std::thread::id) = ::operator==;

This fails because the friend functions in std::thread::id can't be found by
normal name lookup. There should be non-friend declarations at namespace scope.

I'll fix this post-gcc6.

[Bug target/70133] AArch64 -mtune=native generates improperly formatted -march parameters

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

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

--- Comment #8 from James Greenhalgh  ---
(In reply to Christophe Lyon from comment #6)
> > 3) We should think about whether we need to put out these +no extension
> > strings at all. I don't like that for my older systems I'll need to keep
> > updating my binutils to cover any new extension strings (e.g. +nolse) that
> > are added by GCC if I want to use -march=native . We shouldn't force that if
> > we don't have to.
> > 
> 
> Do you know why these +no where introduced in the first place?
> 
> Why would there be a difference between "+nolse" and "" for instance?

We don't keep track (in aarch64-driver.c) of which flags are implicitly
included (e.g. +fp+simd) and would need an explicit +nofp to disable, and which
flags need explicitly enabled (e.g. +crc) and so don't need to be explicitly
disabled.

I'm working on a clean-up.

[Bug libstdc++/70238] [5/6 Regression] std::future_category ABI change

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #7 from Marek Polacek  ---
So RESOLVED|WONTFIX?

Fix 70278 (LRA split_regs followup patch)

[Bernd Schmidt]

This fixes an oversight in my previous patch here. I used biggest_mode 
in the assumption that if the reg was used in the function, it would be 
set to something other than VOIDmode, but that fails if we have a 
multiword access - only the first hard reg gets its biggest_mode 
assigned in that case.


Bootstrapped and tested on x86_64-linux, ran (just) the new arm testcase 
manually with arm-eabi. Ok?


(The testcase seems to be from glibc. Do we keep the copyright notices 
on the reduced form)?



Bernd
	PR rtl-optimization/70278
	* lra-constraints.c (split_reg): Handle the case where biggest_mode is
	VOIDmode.

testsuite/
	* gcc.dg/torture/pr70278.c: New test.
	* gcc.target/arm/pr70278.c: New test.

Index: gcc/lra-constraints.c
===
--- gcc/lra-constraints.c	(revision 234184)
+++ gcc/lra-constraints.c	(working copy)
@@ -4982,7 +4982,12 @@ split_reg (bool before_p, int original_r
   nregs = 1;
   mode = lra_reg_info[hard_regno].biggest_mode;
   machine_mode reg_rtx_mode = GET_MODE (regno_reg_rtx[hard_regno]);
-  if (GET_MODE_SIZE (mode) > GET_MODE_SIZE (reg_rtx_mode))
+  /* A reg can have a biggest_mode of VOIDmode if it was only ever seen
+	 as part of a multi-word register.  In that case, or if the biggest
+	 mode was larger than a register, just use the reg_rtx.  Otherwise,
+	 limit the size to that of the biggest access in the function.  */
+  if (mode == VOIDmode
+	  || GET_MODE_SIZE (mode) > GET_MODE_SIZE (reg_rtx_mode))
 	{
 	  original_reg = regno_reg_rtx[hard_regno];
 	  mode = reg_rtx_mode;
Index: gcc/testsuite/gcc.dg/torture/pr70278.c
===
--- gcc/testsuite/gcc.dg/torture/pr70278.c	(revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr70278.c	(working copy)
@@ -0,0 +1,37 @@
+/* { dg-do compile } */
+/*
+ * 
+ * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
+ *
+ * Developed at SunPro, a Sun Microsystems, Inc. business.
+ * Permission to use, copy, modify, and distribute this
+ * software is freely granted, provided that this notice 
+ * is preserved.
+ * 
+ */
+typedef union
+{
+  double value;
+  struct
+  {
+unsigned int msw;
+  } parts;
+} ieee_double_shape_type;
+double __ieee754_hypot(double x, double y)
+{
+ double a=x,b=y,t1,t2,y1,y2,w;
+ int j,k,ha,hb;
+ do { ieee_double_shape_type gh_u; gh_u.value = (x); (ha) = gh_u.parts.msw; } while (0);;
+ if(hb > ha) {a=y;b=x;j=ha; ha=hb;hb=j;} else {a=x;b=y;}
+ if(ha > 0x5f30) {
+do { ieee_double_shape_type sh_u; sh_u.value = (a); sh_u.parts.msw = (ha); (a) = sh_u.value; } while (0);;
+ }
+ w = a-b;
+ if (w <= b)
+ {
+ t2 = a - t1;
+ w = t1*y1-(w*(-w)-(t1*y2+t2*b));
+ }
+ if(k!=0) {
+ } else return w;
+}
Index: gcc/testsuite/gcc.target/arm/pr70278.c
===
--- gcc/testsuite/gcc.target/arm/pr70278.c	(revision 0)
+++ gcc/testsuite/gcc.target/arm/pr70278.c	(working copy)
@@ -0,0 +1,41 @@
+/* { dg-do compile } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-march=*" } { "-march=armv4t" } } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" } { "" } } */
+/* { dg-options "-mthumb" } */
+/* { dg-add-options arm_arch_v4t } */
+/*
+ * 
+ * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
+ *
+ * Developed at SunPro, a Sun Microsystems, Inc. business.
+ * Permission to use, copy, modify, and distribute this
+ * software is freely granted, provided that this notice 
+ * is preserved.
+ * 
+ */
+typedef union
+{
+  double value;
+  struct
+  {
+unsigned int msw;
+  } parts;
+} ieee_double_shape_type;
+double __ieee754_hypot(double x, double y)
+{
+ double a=x,b=y,t1,t2,y1,y2,w;
+ int j,k,ha,hb;
+ do { ieee_double_shape_type gh_u; gh_u.value = (x); (ha) = gh_u.parts.msw; } while (0);;
+ if(hb > ha) {a=y;b=x;j=ha; ha=hb;hb=j;} else {a=x;b=y;}
+ if(ha > 0x5f30) {
+do { ieee_double_shape_type sh_u; sh_u.value = (a); sh_u.parts.msw = (ha); (a) = sh_u.value; } while (0);;
+ }
+ w = a-b;
+ if (w <= b)
+ {
+ t2 = a - t1;
+ w = t1*y1-(w*(-w)-(t1*y2+t2*b));
+ }
+ if(k!=0) {
+ } else return w;
+}

[Bug middle-end/70273] [6 regression] FAIL: g++.dg/ext/label13a.C -std=gnu++98 execution test / scan-assembler _ZN1CC4Ev

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Richard Biener from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > Or better yet decide whether to walk the initializers or not based on
> > !gimple_body (fndecl) && !fun->cfg ?
> 
> or make the flag a tri-state and if we compute it before (during the 
> tree-inline.c walk) then set it from there to avoid redundant work.

Is cgraph_finalize_function () time early enough for C++ cloning?

Re: C++ PATCH to fix missing warning (PR c++/70194)

[Martin Sebor]

On 03/17/2016 10:48 AM, Patrick Palka wrote:

On Thu, Mar 17, 2016 at 12:27 PM, Jeff Law  wrote:

On 03/16/2016 06:43 PM, Martin Sebor wrote:


@@ -3974,6 +3974,38 @@ build_vec_cmp (tree_code code, tree type,
 return build3 (VEC_COND_EXPR, type, cmp, minus_one_vec, zero_vec);
   }

+/* Possibly warn about an address never being NULL.  */
+
+static void
+warn_for_null_address (location_t location, tree op, tsubst_flags_t
complain)
+{


...


+  if (TREE_CODE (cop) == ADDR_EXPR
+  && decl_with_nonnull_addr_p (TREE_OPERAND (cop, 0))
+  && !TREE_NO_WARNING (cop))
+warning_at (location, OPT_Waddress, "the address of %qD will never "
+"be NULL", TREE_OPERAND (cop, 0));
+
+  if (CONVERT_EXPR_P (op)
+  && TREE_CODE (TREE_TYPE (TREE_OPERAND (op, 0))) == REFERENCE_TYPE)
+{
+  tree inner_op = op;
+  STRIP_NOPS (inner_op);
+
+  if (DECL_P (inner_op))
+warning_at (location, OPT_Waddress,
+"the compiler can assume that the address of "
+"%qD will never be NULL", inner_op);



Since I noted the subtle differences between the phrasing of
the various -Waddress warnings in the bug, I have to ask: what is
the significance of the difference between the two warnings here?

Would it not be appropriate to issue the first warning in the latter
case?  Or perhaps even use the same text as is already used elsewhere:
"the address of %qD will always evaluate as ‘true’" (since it may not
be the macro NULL that's mentioned in the expression).


They were added at different times AFAICT.  The former is fairly old
(Douglas Gregor, 2008) at this point.  The latter was added by Patrick Palka
for 65168 about a year ago.

You could directly ask Patrick about motivations for a different message.


There is no plausible way for the address of a non-reference variable
to be NULL even in code with UB (aside from __attribute__ ((weak)) in
which case the warning is suppressed).  But the address of a reference
can easily seem to be NULL if one performs UB and assigns to it *(int
*)NULL or something like that.  I think that was my motivation, anyway
:)


Thanks (everyone) for the explanation.

I actually think the warning Patrick added is the most accurate
and would be appropriate in all cases.

I suppose what bothers me besides the mention of NULL even when
there is no NULL in the code, is that a) the text of the warnings
is misleading (contradictory) in some interesting cases, and b)
I can't think of a way in which the difference between the three
phrasings of the diagnostic could be useful to a user.  All three
imply the same thing: compilers can and GCC is some cases does
assume that the address of an ordinary (non weak) function, object,
or reference is not null.

To see (a), consider the invalid test program below, in which
GCC makes this assumption about the address of i even though
the warning doesn't mention it (but it makes a claim that's
contrary to the actual address), yet doesn't make the same
assumption about the address of the reference even though
the diagnostic says it can.

While I would find the warning less misleading if it simply said
in all three cases: "the address of 'x' will always evaluate as
‘true’" I think it would be even more accurate if it said
"the address of 'x' may be assumed to evaluate to ‘true’"  That
avoids making claims about whether or not it actually is null,
doesn't talk about the NULL macro when one isn't used in the
code, and by saying "may assume" it allows for both making
the assumption as well as not making one.

I'm happy to submit a patch to make this change in stage 1 if
no one objects to it.

Martin

$ cat x.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc 
-B/home/msebor/build/gcc-trunk-svn/gcc -c -xc++ x.c && 
/home/msebor/build/gcc-trunk-svn/gcc/xgcc 
-B/home/msebor/build/gcc-trunk-svn/gcc -DMAIN -Wall -Wextra -Wpedantic 
x.o -xc++ x.c && ./a.out

#if MAIN

extern int i;
extern int 

extern void f ();

int main ()
{
f ();

#define TEST(x) __builtin_printf ("%s is %s\n", #x, (x) ? "true" : "false")

TEST ( != 0);
TEST ( != 0);
TEST ();
}

#else
extern __attribute__ ((weak)) int i;
int  = i;

void f ()
{
__builtin_printf (" = %p\n = %p\n", , );
}

#endif
x.c: In function ‘int main()’:
x.c:14:17: warning: the address of ‘i’ will never be NULL [-Waddress]
 TEST ( != 0);
 ^
x.c:12:54: note: in definition of macro ‘TEST’
 #define TEST(x) __builtin_printf ("%s is %s\n", #x, (x) ? "true" : 
"false")

  ^
x.c:15:14: warning: the compiler can assume that the address of ‘r’ will 
never be NULL [-Waddress]

 TEST ( != 0);
   ~~~^~~~
x.c:12:54: note: in definition of macro ‘TEST’
 #define TEST(x) __builtin_printf ("%s is %s\n", #x, (x) ? "true" : 
"false")

  ^
x.c:12:68: warning: the address of ‘i’ will always evaluate as ‘true’ 
[-Waddres]
 #define TEST(x) 

[Bug libstdc++/70238] [5/6 Regression] std::future_category ABI change

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #9 from Jakub Jelinek  ---
.

[Bug tree-optimization/68714] [6 Regression] less folding of vector comparison

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 16 13:34:36 2016
New Revision: 234258

URL: https://gcc.gnu.org/viewcvs?rev=234258=gcc=rev
Log:
PR tree-optimization/68714
* gcc.dg/tree-ssa/pr68714.c: Add -w -Wno-psabi to dg-options.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr68714.c

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

[H.J. Lu]

On Wed, Mar 16, 2016 at 2:45 AM, Bernhard Reutner-Fischer
 wrote:
> On March 16, 2016 3:17:20 AM GMT+01:00, "H.J. Lu"  wrote:
>
>>> Where is the current definition of empty types you're proposing for
>>use in
>>> GCC?  Is the behavior of this case clear from that definition?
>>
>>https://gcc.gnu.org/ml/gcc/2016-03/msg00071.html
>>
>>Jason's patch follows it.  Here is a test for struct with zero-size
>>array of empty type, which is treated as empty type.
>
> index 000..489eb3a
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/abi/empty19.C
> @@ -0,0 +1,17 @@
> +// PR c++/60336
> +// { dg-do run }
> +// { dg-options "-Wabi=9 -x c" }
> +// { dg-additional-sources "empty14a.c" }
>
> 14a ? Not 19a ?
> Thanks
>
>

Here is the updated patch.

-- 
H.J.
From d7da4b56dddbd75da163b9fd3cc9ff4241be6ca9 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Tue, 15 Mar 2016 19:14:30 -0700
Subject: [PATCH] Add a test for struct with zero-size array of empty type

---
 gcc/testsuite/g++.dg/abi/empty19.C  | 17 +
 gcc/testsuite/g++.dg/abi/empty19.h  | 10 ++
 gcc/testsuite/g++.dg/abi/empty19a.c |  6 ++
 3 files changed, 33 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/abi/empty19.C
 create mode 100644 gcc/testsuite/g++.dg/abi/empty19.h
 create mode 100644 gcc/testsuite/g++.dg/abi/empty19a.c

diff --git a/gcc/testsuite/g++.dg/abi/empty19.C b/gcc/testsuite/g++.dg/abi/empty19.C
new file mode 100644
index 000..e3e855a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/abi/empty19.C
@@ -0,0 +1,17 @@
+// PR c++/60336
+// { dg-do run }
+// { dg-options "-Wabi=9 -x c" }
+// { dg-additional-sources "empty19a.c" }
+// { dg-prune-output "command line option" }
+
+#include "empty19.h"
+extern "C" void fun(struct dummy, struct foo);
+
+int main()
+{
+  struct dummy d;
+  struct foo f = { -1, -2, -3, -4, -5 };
+
+  fun(d, f); // { dg-warning "empty" }
+  return 0;
+}
diff --git a/gcc/testsuite/g++.dg/abi/empty19.h b/gcc/testsuite/g++.dg/abi/empty19.h
new file mode 100644
index 000..616b87b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/abi/empty19.h
@@ -0,0 +1,10 @@
+struct dummy0 { };
+struct dummy { struct dummy0 d[0]; };
+struct foo
+{
+  int i1;
+  int i2;
+  int i3;
+  int i4;
+  int i5;
+};
diff --git a/gcc/testsuite/g++.dg/abi/empty19a.c b/gcc/testsuite/g++.dg/abi/empty19a.c
new file mode 100644
index 000..767b1eb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/abi/empty19a.c
@@ -0,0 +1,6 @@
+#include "empty19.h"
+void fun(struct dummy d, struct foo f)
+{
+  if (f.i1 != -1)
+__builtin_abort();
+}
-- 
2.5.0

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[ralphengels at gmail dot com]

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

--- Comment #19 from ralphengels at gmail dot com  ---
Had problems with the define not being pulled in from os_defines.h (i think a
better place would have been gthr_posix.h since that gets pulled in at build
time) hence the change, also if using another posix thread implementation it
would break using that instead since your define would then be undefined
leading to a build error. Besides that better implementations are welcome :)
this was just an example of a possible fix.

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
(In reply to Tobias Burnus from comment #7)
... snip ...
> 
> My gut feeling is that it has something to do with having "precision" == 17
> in that function. In any case, the nafter is too large when nblanks is
> calculated.

Yes, and I find one place where after a memmove to align digits, the
significant digit gets wiped to a zero, really odd. I am on the hunt

[Bug fortran/69604] ICE in gfc_add_modify_loc, at fortran/trans.c:159

[anlauf at gmx dot de]

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

--- Comment #7 from Harald Anlauf  ---
(In reply to Harald Anlauf from comment #6)

All crashes for case 4 go away after the following change:

Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 234170)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -8275,7 +8275,7 @@
  gfc_add_expr_to_block (, tmp);
}
 }
-  else if (ts.type == BT_DERIVED || ts.type == BT_CLASS)
+  else if (ts.type == BT_DERIVED || ts.type == BT_CLASS || ts.type ==
BT_COMPLEX)
 {
   gfc_add_block_to_block (, >pre);
   gfc_add_block_to_block (, >pre);


Could somebody please check whether this makes sense?

[Bug c/70281] valgrind error in can_be_stored_compactly_p (line-map.c:148)

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Minimized reproducer:

$ cat bug.c
const char *bch_stats_show (unsigned long cache_hits)
{
  return (__builtin_types_compatible_p (typeof (cache_hits >> 16), int)
  ? "%i\n" : "%i\n");
}

Am working on a fix.

Re: [PATCH] Fix rs6000 vector builtin macro handling if it is followed by a fn-like macro without arguments (PR target/70296)

[David Edelsohn]

On Fri, Mar 18, 2016 at 5:34 PM, Jakub Jelinek  wrote:
> Hi!
>
> The following testcase is diagnosed as errorneous, because the preprocessor
> mishandles
>
> #define c(x) x
> vector c;
>
> and
>
> #define int(x) x
> vector int n;
>
> The thing is if a function-like macro is not followed by (, then it is kept
> as is, but the builtin conditional macro handling expects it always expands
> as something and calls cpp_get_token on it.  For non-function-like macros
> or function-like macros followed by ( that is not a problem, that
> cpp_get_token call just eats the macro token and pushes instead the
> replacement tokens, but for function-like macro not followed by ( it results
> in the token being dropped on the floor.
> So, in the above mentioned cases we preprocess it as
> vector ;
> and
> vector n;
> and when compiling, error on the first one, and (due to previous
> typedef int vector;) handle it at int n; rather than
> __attribute__((__vector)) int n;
>
> Fixed by peeking at the next token after the macro token (or more, if there
> are CPP_PADDING tokens) and if it is not followed by CPP_OPEN_PAREN, not
> calling cpp_get_token.  Unfortunately, cpp_macro structure is opaque outside
> of libcpp, so I had to add a helper function into libcpp.
>
> Bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?
>
> 2016-03-18  Jakub Jelinek  
>
> PR target/70296
> * include/cpplib.h (cpp_fun_like_macro_p): New prototype.
> * macro.c (cpp_fun_like_macro_p): New function.
>
> * config/rs6000/rs6000-c.c (rs6000_macro_to_expand): If IDENT is
> function-like macro, peek following token(s) if it is followed
> by CPP_OPEN_PAREN token with optional padding in between, and
> if not, don't treat it like a macro.
>
> * gcc.target/powerpc/altivec-36.c: New test.

I'm not an expert in this part of the compiler, but the rs6000 bits
are fine with me.

Thanks, David

Re: [C PATCH] Prevent -Wunused-value warning with __atomic_fetch_* (PR c/69407)

[Jeff Law]

On 03/14/2016 05:48 AM, Marek Polacek wrote:

Ping.

On Fri, Mar 04, 2016 at 07:03:09PM +0100, Marek Polacek wrote:

On Fri, Mar 04, 2016 at 06:41:26PM +0100, Jakub Jelinek wrote:

I'm ok with it for gcc6.


Cool.


But IMHO you should add dg-bogus directives here.


Ok, version with dg-bogus:

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

2016-03-04  Marek Polacek  

PR c/69407
* c-common.c (resolve_overloaded_builtin): Set TREE_USED for the fetch
operations.

* gcc.dg/atomic-op-6.c: New test.

OK.
jeff

[Bug target/70133] AArch64 -mtune=native generates improperly formatted -march parameters

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Christophe Lyon from comment #6)
> > 3) We should think about whether we need to put out these +no extension
> > strings at all. I don't like that for my older systems I'll need to keep
> > updating my binutils to cover any new extension strings (e.g. +nolse) that
> > are added by GCC if I want to use -march=native . We shouldn't force that if
> > we don't have to.
> > 
> 
> Do you know why these +no where introduced in the first place?
> 
> Why would there be a difference between "+nolse" and "" for instance?

X86, adds the -mno-* option too with respect of -march=native.

[Bug c++/70194] [6 regression] missing -Waddress on constexpr pointer

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Thu Mar 17 10:29:36 2016
New Revision: 234281

URL: https://gcc.gnu.org/viewcvs?rev=234281=gcc=rev
Log:
PR c++/70194
* typeck.c (warn_for_null_address): New function.
(cp_build_binary_op): Call it.

* g++.dg/warn/constexpr-70194.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/constexpr-70194.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

Re: C++ PATCH to fix missing warning (PR c++/70194)

[Jeff Law]

On 03/17/2016 10:45 AM, Jason Merrill wrote:

On 03/16/2016 08:43 PM, Martin Sebor wrote:

@@ -3974,6 +3974,38 @@ build_vec_cmp (tree_code code, tree type,
return build3 (VEC_COND_EXPR, type, cmp, minus_one_vec, zero_vec);
  }

+/* Possibly warn about an address never being NULL.  */
+
+static void
+warn_for_null_address (location_t location, tree op, tsubst_flags_t
complain)
+{

...

+  if (TREE_CODE (cop) == ADDR_EXPR
+  && decl_with_nonnull_addr_p (TREE_OPERAND (cop, 0))
+  && !TREE_NO_WARNING (cop))
+warning_at (location, OPT_Waddress, "the address of %qD will
never "
+"be NULL", TREE_OPERAND (cop, 0));
+
+  if (CONVERT_EXPR_P (op)
+  && TREE_CODE (TREE_TYPE (TREE_OPERAND (op, 0))) ==
REFERENCE_TYPE)
+{
+  tree inner_op = op;
+  STRIP_NOPS (inner_op);
+
+  if (DECL_P (inner_op))
+warning_at (location, OPT_Waddress,
+"the compiler can assume that the address of "
+"%qD will never be NULL", inner_op);


Since I noted the subtle differences between the phrasing of
the various -Waddress warnings in the bug, I have to ask: what is
the significance of the difference between the two warnings here?


The difference is that in the second case, a reference could be bound to
a null address, but that has undefined behavior, so the compiler can
assume it won't happen.
So the first can't happen, the second could, but would be considered 
undefined behavior.


jeff

[Bug c/70150] Additonal test failures with --enable-default-pie

[hjl.tools at gmail dot com]

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

Bug 70258 Summary: [6 Regression] flag_pic is cleared for PIE in 
lto_post_options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70258

   What|Removed |Added

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

[Bug middle-end/70245] [6 Regression] Miscompilation of ICU on i386 with atom tuning starting with r227382

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar 17 11:53:53 2016
New Revision: 234285

URL: https://gcc.gnu.org/viewcvs?rev=234285=gcc=rev
Log:
PR target/70245
* rtl.h (replace_rtx): Add ALL_REGS argument.
* rtlanal.c (replace_rtx): Likewise.  If true, use REGNO
equality and assert mode is the same, instead of just rtx pointer
equality.
* config/i386/i386.md (mov + arithmetics with load peephole): Pass
true as ALL_REGS argument to replace_rtx.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/rtl.h
trunk/gcc/rtlanal.c

[Bug target/70048] [6 Regression][AArch64] Inefficient local array addressing

[wdijkstr at arm dot com]

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

--- Comment #20 from Wilco  ---
(In reply to Richard Henderson from comment #19)

> I wish that message had been a bit more complete with the description
> of the performance issue.  I must guess from this...
> 
> >   ldr dst1, [reg_base1, reg_index, #lsl 1]
> >   ldr dst2, [reg_base2, reg_index, #lsl 1]
> >   ldr dst3, [reg_base3, reg_index, #lsl 1]
> > 
> > into
> > 
> >   reg_index = reg_index << 1;
> >   ldr dst1, [reg_base1, reg_index]
> >   ldr dst2, [reg_base2, reg_index]
> >   ldr dst3, [reg_base3, reg_index]
> 
> that it must have something to do with the smaller cpus, e.g. exynosm1,
> based on the address cost tables.

Some CPUs emit seperate uops to do address shift by 1. So that would mean 6
uops in the first example vs 4 when doing the shift separately. According to
the cost tables this might actually be worse on exynosm1 as it has a cost for
any indexing.

> I'll note for the record that you cannot hope to solve this with
> the legitimize_address hook alone for the simple reason that it's not
> called for legitimate addresses, of which (base + index * 2) is
> a member.  The hook is only being called for illegitimate addresses.

Would it be possible to disallow expensive addresses initially, let CSE do its
thing and then merge addresses with 1 or 2 uses back into loads/stores?

> To include legitimate addresses, you'd have to force out the address
> components somewhere else.  Perhaps in the mov expanders, since that's
> one of the very few places mem's are allowed.  You'd want to do this
> only if !cse_not_expected.

And presumably only for addresses we would prefer to be CSEd, such as expensive
shifts or indexing.

> OTOH, it's also the sort of thing that one would hope that CSE itself
> would be able to handle.  Looking across various addresses, computing
> sums of costs, and breaking out subexpressions as necessary.

Yes that would be the ideal, but one can dream...

Did you post your patch btw? We should go ahead with that (with Jiong's minor
modification) as it looks significantly better overall.

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

[H.J. Lu]

On Tue, Mar 15, 2016 at 12:32 PM, Jason Merrill  wrote:
> On 03/15/2016 12:00 PM, H.J. Lu wrote:
>>
>> On Tue, Mar 15, 2016 at 8:35 AM, Jason Merrill  wrote:
>>>
>>> I'm concerned about how this patch changes both target-independent code
>>> and
>>> target-specific code, with a passing remark that other targets might need
>>> to
>>> make similar changes.  I'm also concerned about the effect of this on
>>> other
>>> languages that might not want the same change.  So, here's an alternative
>>> patch that implements the change in the front end (and includes your
>>> testcases, thanks!).
>>>
>>> Thoughts?
>>
>>
>> On x86-64, I got
>>
>>
>> /export/gnu/import/git/sources/gcc/libstdc++-v3/src/c++11/cxx11-shim_facets.cc:273:23:
>> error: empty class ‘std::__facet_shims::other_abi {aka
>> std::integral_constant}’ parameter passing ABI changes in
>> -fabi-version=10 (GCC 6) [-Werror=abi]
>>  __collate_transform(other_abi{}, _M_get(), st, lo, hi);
>
>
> Right, need to remove the -Werror=abi bit from the patch until Jonathan
> updates libstdc++.
>
> Jason
>

I got

FAIL: g++.dg/abi/pr60336-1.C   scan-assembler jmp[\t ]+[^$]*?_Z3xxx9true_type
FAIL: g++.dg/abi/pr60336-5.C   scan-assembler jmp[\t ]+[^$]*?_Z3xxx9true_type
FAIL: g++.dg/abi/pr60336-6.C   scan-assembler jmp[\t ]+[^$]*?_Z3xxx9true_type
FAIL: g++.dg/abi/pr60336-7.C   scan-assembler jmp[\t ]+[^$]*?_Z3xxx9true_type
FAIL: g++.dg/abi/pr60336-9.C   scan-assembler jmp[\t ]+[^$]*?_Z3xxx9true_type
FAIL: g++.dg/abi/pr68355.C   scan-assembler jmp[\t
]+[^$]*?_Z3xxx17integral_constantIbLb1EE

They are expected since get_ref_base_and_extent needs to be
changed to set bitsize to 0 for empty types so that when
ref_maybe_used_by_call_p_1 calls get_ref_base_and_extent to
get 0 as the maximum size on empty type.  Otherwise, find_tail_calls
won't perform tail call optimization for functions with empty type
parameters.

-- 
H.J.

Re: C PATCH for c/70093 (ICE with nested-function returning VM type)

[Jakub Jelinek]

On Wed, Mar 16, 2016 at 04:11:56PM +0100, Marek Polacek wrote:
> > 2016-03-09  Marek Polacek  
> > 
> > PR c/70093
> > * c-typeck.c (build_function_call_vec): Create a TARGET_EXPR for
> > nested functions returning VM types.
> > 
> > * cgraphunit.c (cgraph_node::expand_thunk): Also build call to the
> > function being thunked if the result type doesn't have fixed size.
> > * gimplify.c (gimplify_modify_expr): Also set LHS if the result type
> > doesn't have fixed size.
> > 
> > * gcc.dg/nested-func-10.c: New test.
> > * gcc.dg/nested-func-9.c: New test.

Ok, thanks.

Jakub

[Bug middle-end/70245] [6 Regression] Miscompilation of ICU on i386 with atom tuning starting with r227382

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
See PR70261.

[Bug target/54746] config/s390/s390.c:1583: possible missing break in switch ?

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Andreas Krebbel  ---
Fixed.

[Bug c++/70121] Spurious warning and crash when returning a reference from lambda

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|ppalka at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
Summary|[5/6 Regression] spurious   |Spurious warning and crash
   |warning and crash when  |when returning a reference
   |returning a reference from  |from lambda
   |lambda  |

--- Comment #5 from Patrick Palka  ---
Removing regression markers.

[Bug target/61821] gcc.target/i386/pr61599-1.c FAILs with Sun as

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|i386-pc-solaris2.1[01]  |i386-pc-solaris2.1[012]
 Status|UNCONFIRMED |ASSIGNED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2016-03/msg01059.ht
   ||ml
   Last reconfirmed||2016-03-18
   Host|i386-pc-solaris2.1[01]  |i386-pc-solaris2.1[012]
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org
 Ever confirmed|0   |1
  Build|i386-pc-solaris2.1[01]  |i386-pc-solaris2.1[012]

--- Comment #4 from Rainer Orth  ---
Mine, patch posted.

[Bug c++/70318] New: `std::sqrt(int)` Produces -Wfloat-conversion Warning, Erroneous After C++11.

[ian at geometrian dot com]

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

Bug ID: 70318
   Summary: `std::sqrt(int)` Produces -Wfloat-conversion
Warning, Erroneous After C++11.
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian at geometrian dot com
  Target Milestone: ---

Created attachment 38032
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38032=edit
Sample given in text, as a file.

As required by the C++ standard, after C++11, the `std::sqrt` function in
`` is required to have "A set of overloads or a function template
accepting an argument of any integral type."

Consider the following command-line tool for computing integer-square root:

//Compile like so: g++ isqrt.cpp -std=c++11 -Wfloat-conversion -o isqrt
#include 
#include 
int main(int argc, char* argv[]) {
if (argc!=2) {
std::cout << "Usage: \"./isqrt [integer]\"" << std::endl;
return -1;
} else {
int arg = atoi(argv[1]);
int isqrt = std::sqrt(arg);
std::cout << isqrt << std::endl;
return isqrt;
}
}

When compiling as the comment says, a warning is produced:

isqrt.cpp: In function ‘int main(int, char**)’:
isqrt.cpp:10:33: warning: conversion to ‘int’ from
‘__gnu_cxx::__enable_if::__type {aka double}’ may alter its value
[-Wfloat-conversion]
   int isqrt = std::sqrt(arg);
 ^

Internally, the argument is indeed converted to `double`, before doing the
square root with `double`s (at it should be).  However, since the overload is
required to exist separately and explicitly (and it evidently doesn't), I think
this warning is erroneous.

For your convenience, my sample is also attached as a file.

[Bug other/70268] New: add option -ffile-prefix-map to map one directory name (old) to another (new) in __FILE__, __BASE_FILE__and __builtin_FILE()

[hongxu.jia at windriver dot com]

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

Bug ID: 70268
   Summary: add option -ffile-prefix-map to map one directory name
(old) to another (new) in __FILE__, __BASE_FILE__and
__builtin_FILE()
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hongxu.jia at windriver dot com
  Target Milestone: ---

Hi all,

I come from OpenEmbedded community (https://www.yoctoproject.org/),
and we use the powerful gcc for cross compilation. Previously, with
the help of Richard Biener and Jakub Jelinek, PR69821 was fixed which
do not expose the build path to others while '-g' used.

But there is another similar issue, while '__FILE__' used, this macro
expands to the name of the current input file which has build path.

I know the tradition solution is using relative path to compile.
(Such as instead of 'gcc /full/path/to/test.c',
try 'cd /full/path/to; gcc test.c; cd -;')

But if '__FILE__' exists in included header file and the header
file in standard system directories, the above way doesn't work.
Here is my test case:
---
1. Prepare a C source file and a C include file
$ cat << ENDOF > test.c
#include 
#include 

int main(int argc, char *argv[])
{
  printf("__FILE__ %s\n", __FILE__);
  test();
  return 0;
}

ENDOF

$ cat << ENDOF > test.h
#include 

void test(void)
{
  printf("__FILE__ %s\n", __FILE__);
  return;
}

ENDOF

2. Move include file to standard system directory.
$ sudo mv test.h /usr/include/

3. Compile C source file
$ gcc ./test.c -o test

4. Execute and the output shows full path header file.
$ ./test 
__FILE__ ./test.c
__FILE__ /usr/include/test.h
---

Re: [PATCH] Retry to emit global variables in HSA (PR hsa/70234)

[Martin Jambor]

Hi,

On Tue, Mar 15, 2016 at 12:59:03PM +0100, Martin Liska wrote:
> Hi.
> 
> As emission of a HSAIL function can fail for various reason (-Whsa),
> we must guarantee that a global variable is declared and at maximum once.
> 
> Following patch does that, patch can survive make check-target-libgomp and
> HSAILAsm is happy with BRIG output of declare_target-5.c source file.
> 
> Currently, I'm running bootstrap on x86_64-linux-gnu.
> Ready to install after if finishes?
> 
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2016-03-15  Martin Liska  
> 
>   PR hsa/70234
>   * hsa-brig.c (emit_function_directives): Mark unemitted
>   global variables for emission.
>   * hsa-gen.c (hsa_symbol::hsa_symbol): Initialize a new flag.
>   (get_symbol_for_decl): Likewise.
>   * hsa.h (struct hsa_symbol): New flag.
> ---
>  gcc/hsa-brig.c |  2 ++
>  gcc/hsa-gen.c  | 22 +++---
>  gcc/hsa.h  |  3 +++
>  3 files changed, 24 insertions(+), 3 deletions(-)
> 
> diff --git a/gcc/hsa-brig.c b/gcc/hsa-brig.c
> index 2a301be..9b6c0b8 100644
> --- a/gcc/hsa-brig.c
> +++ b/gcc/hsa-brig.c
> @@ -643,6 +643,8 @@ emit_function_directives (hsa_function_representation *f, 
> bool is_declaration)
>if (!f->m_declaration_p)
>  for (int i = 0; f->m_global_symbols.iterate (i, ); i++)
>{
> + gcc_assert (!sym->m_emitted_to_brig);
> + sym->m_emitted_to_brig = true;
>   emit_directive_variable (sym);
>   brig_insn_count++;
>}
> diff --git a/gcc/hsa-gen.c b/gcc/hsa-gen.c
> index 5939a57..473d4bd 100644
> --- a/gcc/hsa-gen.c
> +++ b/gcc/hsa-gen.c
> @@ -162,7 +162,7 @@ hsa_symbol::hsa_symbol ()
>  m_directive_offset (0), m_type (BRIG_TYPE_NONE),
>  m_segment (BRIG_SEGMENT_NONE), m_linkage (BRIG_LINKAGE_NONE), m_dim (0),
>  m_cst_value (NULL), m_global_scope_p (false), m_seen_error (false),
> -m_allocation (BRIG_ALLOCATION_AUTOMATIC)
> +m_allocation (BRIG_ALLOCATION_AUTOMATIC), m_emitted_to_brig (false)
>  {
>  }
>  
> @@ -174,7 +174,7 @@ hsa_symbol::hsa_symbol (BrigType16_t type, BrigSegment8_t 
> segment,
>  m_directive_offset (0), m_type (type), m_segment (segment),
>  m_linkage (linkage), m_dim (0), m_cst_value (NULL),
>  m_global_scope_p (global_scope_p), m_seen_error (false),
> -m_allocation (allocation)
> +m_allocation (allocation), m_emitted_to_brig (false)
>  {
>  }
>  
> @@ -880,11 +880,27 @@ get_symbol_for_decl (tree decl)
>gcc_checking_assert (slot);
>if (*slot)
>  {
> +  hsa_symbol *sym = (*slot);
> +
>/* If the symbol is problematic, mark current function also as
>problematic.  */
> -  if ((*slot)->m_seen_error)
> +  if (sym->m_seen_error)
>   hsa_fail_cfun ();
>  
> +  /* PR hsa/70234: If a global variable was marked to be emitted,
> +  but HSAIL generation of a function using the variable fails,
> +  we should retry to emit the variable in context of a different
> +  function.
> +
> +  Iterate elements whether a symbol is already in m_global_symbols
> +  of not.  */
> +  for (unsigned i = 0; i < hsa_cfun->m_global_symbols.length (); i++)
> + if (hsa_cfun->m_global_symbols[i] == sym)
> +   return *slot;
> +
> +  if (is_in_global_vars && !sym->m_emitted_to_brig)
> + hsa_cfun->m_global_symbols.safe_push (sym);
> +

Hopefully the linear search in m_global_symbols never becomes
prohibitively expensive.  But it is only necessary when
is_in_global_vars is true, so at least we could do something like:

  if (is_in_global_vars && !sym->m_emitted_to_brig)
{
  for (unsigned i = 0; i < hsa_cfun->m_global_symbols.length (); i++)
if (hsa_cfun->m_global_symbols[i] == sym)
  return *slot;
hsa_cfun->m_global_symbols.safe_push (sym);
}

OK with that change.  And even though I have seen the bug only on the
hsa branch, commit the fix to trunk too, I think it can happen there
as well.

Thanks a lot,

Martin

[Bug target/70008] [ARM] Reverse subtract with carry can be generated in thumb2 mode

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from Ramana Radhakrishnan  ---
Invalid.

[Bug target/70162] [RX] const_int printing causes wrong code on 32 bit host

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

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

--- Comment #8 from Nick Clifton  ---
Patch applied.

[Bug target/70133] AArch64 -mtune=native generates improperly formatted -march parameters

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

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

--- Comment #5 from James Greenhalgh  ---
The crux of this issue is going to be that your Cortex-A53 has no support for
the cryptography extension, but does have support for the CRC extensions.

By inspection of host_detect_local_cpu, I see that we run through all the
extensions that we know about, checking to see whether that extension is a
substring of the Features we read from /proc/cpuinfo . If it is we add
+extension, if not we add +noextension.

So, it seems reasonable to me that if we run this algorithm on a core without
crypto, but with CRC, we'll get the string described
(-march=armv8-a+fp+simd+nocrypto+crc+nolse) forwarded to the assembler on
command line.

And sure enough, the assembler wants to read everything you've got before you
start telling it what you've not got.

I see a few issues.

1) There's not really a good reason for an assembler to have this syntax
restriction. The code does the right thing whatever order you put your features
in.
2) We'll have to support these older assemblers anyway, so at the least we'll
have to hold off writing the "+no" extension strings until we're done with the
"+" extension strings.
3) We should think about whether we need to put out these +no extension strings
at all. I don't like that for my older systems I'll need to keep updating my
binutils to cover any new extension strings (e.g. +nolse) that are added by GCC
if I want to use -march=native . We shouldn't force that if we don't have to.

So, Confirmed.

[Bug rtl-optimization/70224] [5 regression] ICE: RTL flag check: CROSSING_JUMP_P used with unexpected rtx code 'insn' in relax_delay_slots, at reorg.c:3310

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #9 from Jeffrey A. Law  ---
> So I realized that given the nature of this bug a simple bootstrap on sparc
> wasn't going to be particularly interesting -- bootstraps don't tickle this
> code (if they did, it'd fault in a manner similar to Rainer's test).  So my
> time trying to put together a usable sparc/sparc64 qemu testing environment 
> was
> largely wasted.
>
> I'm going to go forward with the obvious patch.
>
> Rainer, if you could do a bootstrap with -freorder-blocks-and-partition after 
> I
> commit the obvious fix, it'd be appreciated as an additional sanity check.

I just did, but it ICEed in stage2:

+===GNAT BUG DETECTED==+
| 6.0.0 20160317 (experimental) (sparc-sun-solaris2.12) GCC error: |
| in replace_rtx, at rtlanal.c:2969|
| Error detected around /vol/gcc/src/hg/trunk/dist/gcc/ada/types.adb:121:8 |

Rainer

Re: [PATCH, PR tree-optimization/70251] Disable VEC_COND_EXPR transformation into VIEW_CONVERT_EXPR for scalar mask case

[Richard Biener]

On Thu, Mar 17, 2016 at 11:23 AM, Ilya Enkovich  wrote:
> Hi,
>
> This patch disables two match.pd patterns which transform
> VEC_COND_EXPR into simple conversion in case it uses a scalar mask.
> The patch was bootstrapped and regtested on x86_64-pc-linux-gnu +
> separate check for new test on SDE.  OK for trunk?

Ok.

Richard.

> Thanks,
> Ilya
> --
> gcc/
>
> 2016-03-17  Ilya Enkovich  
>
> * match.pd (A + (B vcmp C ? 1 : 0) -> A - (B vcmp C)): Apply
> for boolean vector with vector mode only.
> (A - (B vcmp C ? 1 : 0) -> A + (B vcmp C)): Likewise.
>
> gcc/testsuite/
>
> 2016-03-17  Ilya Enkovich  
>
> * gcc.target/i386/pr70251.c: New test.
>
>
> diff --git a/gcc/match.pd b/gcc/match.pd
> index 112deb3..7245ff4 100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -1759,6 +1759,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>  (simplify
>   (plus:c @3 (view_convert? (vec_cond @0 integer_each_onep@1 
> integer_zerop@2)))
>   (if (VECTOR_TYPE_P (type)
> +  && VECTOR_MODE_P (TYPE_MODE (TREE_TYPE (@0)))
>&& TYPE_VECTOR_SUBPARTS (type) == TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0))
>&& (TYPE_MODE (TREE_TYPE (type))
>== TYPE_MODE (TREE_TYPE (TREE_TYPE (@0)
> @@ -1768,6 +1769,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>  (simplify
>   (minus @3 (view_convert? (vec_cond @0 integer_each_onep@1 integer_zerop@2)))
>   (if (VECTOR_TYPE_P (type)
> +  && VECTOR_MODE_P (TYPE_MODE (TREE_TYPE (@0)))
>&& TYPE_VECTOR_SUBPARTS (type) == TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0))
>&& (TYPE_MODE (TREE_TYPE (type))
>== TYPE_MODE (TREE_TYPE (TREE_TYPE (@0)
> diff --git a/gcc/testsuite/gcc.target/i386/pr70251.c 
> b/gcc/testsuite/gcc.target/i386/pr70251.c
> new file mode 100644
> index 000..97078cd
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr70251.c
> @@ -0,0 +1,52 @@
> +/* { dg-do run } */
> +/* { dg-options "-O3 -mavx512bw" } */
> +/* { dg-require-effective-target avx512bw } */
> +
> +#define AVX512BW
> +#include "avx512f-helper.h"
> +
> +unsigned long long int
> +hash(unsigned long long int seed, unsigned long long int v)
> +{
> +  return seed ^ (v + 0x9e3779b9 + (seed<<6) + (seed>>2));
> +}
> +
> +unsigned int a [100];
> +signed char b [100];
> +signed char c [100];
> +
> +void
> +init ()
> +{
> +  for (int i = 0; i < 100; ++i)
> +{
> +  a [i] = 1000L;
> +  b [i] = 10;
> +  c [i] = 5;
> +}
> +}
> +
> +void
> +foo ()
> +{
> +  for (int i = 0; i < 100; ++i)
> +b [i] = (!b [i] ^ (a [i] >= b [i])) + c [i];
> +}
> +
> +unsigned long long int
> +checksum ()
> +{
> +  unsigned long long int seed = 0ULL;
> +  for (int i = 0; i < 100; ++i)
> +seed = hash (seed, b[i]);
> +  return seed;
> +}
> +
> +void
> +TEST ()
> +{
> +  init ();
> +  foo ();
> +  if (checksum () != 5785906989299578598ULL)
> +__builtin_abort ();
> +}

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
Created attachment 37990
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37990=edit
A useful test program

I get correct results using the attached with gcc version 4.6.4 (GCC)

Broken in 4.9, 5, and 6.

[Bug target/70162] [RX] const_int printing causes wrong code on 32 bit host

[nickc at gcc dot gnu.org]

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

--- Comment #7 from Nick Clifton  ---
Author: nickc
Date: Thu Mar 17 10:16:38 2016
New Revision: 234280

URL: https://gcc.gnu.org/viewcvs?rev=234280=gcc=rev
Log:
PR target/70162
* config/rx/rx.c (rx_print_integer): Print negative constants in
decimal.

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

[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled

[ralphengels at gmail dot com]

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

ralphengels at gmail dot com  changed:

   What|Removed |Added

 CC||ralphengels at gmail dot com

--- Comment #12 from ralphengels at gmail dot com  ---
Created attachment 38009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38009=edit
pthreads-w32 compatibility patch

Patch to allow building gcc-5.3.0 with pthreads-w32, no bugs so far but im
still running the testsuite so something might turn up, feel free to test.

[Bug tree-optimization/70252] ICE in vect_get_vec_def_for_stmt_copy with -O3 -march=skylake-avx512.

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #5 from Ilya Enkovich  ---
Fixed

[Bug libstdc++/70303] New: Value-initialized debug iterators

[Casey at Carter dot net]

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

Bug ID: 70303
   Summary: Value-initialized debug iterators
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

Since C++14 requires value-initialized Forward iterators to compare equal, and
subtraction/ordering of RandomAccess iterators is based on equality, this
program should run to completion:

#define _GLIBCXX_DEBUG

#include 
#include 

int main() {
  using I = std::vector::iterator;
  assert(I{} == I{});
  assert(!(I{} != I{}));
  assert(I{} - I{} == 0);
  assert(!(I{} < I{}));
  assert(!(I{} > I{}));
  assert(I{} <= I{});
  assert(I{} >= I{});
}

instead of reporting "Error: attempt to compare a singular iterator to a
singular iterator." for any of the listed iterator operations.

[Bug lto/70289] [openacc] ICE in input_varpool_node

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||tschwinge at gcc dot gnu.org

--- Comment #1 from vries at gcc dot gnu.org ---
For now, marking as ICE-on-valid-code.

Re: [AArch64] Emit square root using the Newton series

[James Greenhalgh]

On Wed, Mar 16, 2016 at 02:45:37PM -0500, Evandro Menezes wrote:
> On 03/08/16 16:08, Evandro Menezes wrote:
> >On 02/16/16 14:56, Evandro Menezes wrote:
> >>On 12/08/15 15:35, Evandro Menezes wrote:
> >>>Emit square root using the Newton series
> >>>
> >>>   2015-12-03  Evandro Menezes  
> >>>
> >>>   gcc/
> >>>* config/aarch64/aarch64-protos.h (aarch64_emit_swsqrt):
> >>>   Declare new
> >>>function.
> >>>* config/aarch64/aarch64-simd.md (sqrt2): New
> >>>   expansion and
> >>>insn definitions.
> >>>* config/aarch64/aarch64-tuning-flags.def
> >>>(AARCH64_EXTRA_TUNE_FAST_SQRT): New tuning macro.
> >>>* config/aarch64/aarch64.c (aarch64_emit_swsqrt): Define
> >>>   new function.
> >>>* config/aarch64/aarch64.md (sqrt2): New expansion
> >>>   and insn
> >>>definitions.
> >>>* config/aarch64/aarch64.opt (mlow-precision-recip-sqrt):
> >>>   Expand option
> >>>description.
> >>>* doc/invoke.texi (mlow-precision-recip-sqrt): Likewise.
> >>>
> >>>This patch extends the patch that added support for
> >>>implementing x^-1/2 using the Newton series by adding support
> >>>for x^1/2 as well.
> >>>
> >>>Is it OK at this point of stage 3?
> >>>
> >>>Thank you,
> >>>
> >>
> >>James,
> >>
> >>As I was saying, this patch results in some validation errors in
> >>CPU2000 benchmarks using DF.  Although proving the algorithm to
> >>be pretty solid with a vast set of random values, I'm confused
> >>why some benchmarks fail to validate with this implementation of
> >>the Newton series for square root too, when they pass with the
> >>Newton series for reciprocal square root.
> >>
> >>Since I had no problems with the same algorithm on x86-64, I
> >>wonder if the initial estimate on AArch64, which offers just 8
> >>bits, whereas x86-64 offers 11 bits, has to do with it.  Then
> >>again, the algorithm iterated 1 less time on x86-64 than on
> >>AArch64.
> >>
> >>Since it seems that the initial estimate is sufficient for
> >>CPU2000 to validate when using SF, I'm leaning towards
> >>restricting the Newton series for square root only for SF.
> >>
> >>Your thoughts on the matter are appreciated,
> >
> >Add choices for the reciprocal square root approximation
> >
> >Allow a target to prefer such operation depending on the FP
> >   precision.
> >
> >gcc/
> >* config/aarch64/aarch64-protos.h
> >(AARCH64_EXTRA_TUNE_APPROX_RSQRT): New macro.
> >* config/aarch64/aarch64-tuning-flags.def
> >(AARCH64_EXTRA_TUNE_APPROX_RSQRT_DF): New mask.
> >(AARCH64_EXTRA_TUNE_APPROX_RSQRT_SF): Likewise.
> >* config/aarch64/aarch64.c
> >(use_rsqrt_p): New argument for the mode.
> >(aarch64_builtin_reciprocal): Devise mode from builtin.
> >(aarch64_optab_supported_p): New argument for the mode.
> >
> >
> >Now that the patch is attached, feedback is appreciated.
> 
> Ping.

Hi Evandro,

I thought this was on hold while you looked in to the underlying issue for
the failures in the other thread? With that said, I'm struggling to keep
up with where we are on this, so maybe it is time for a clean break - a new
thread for patch set v2, proposed as an explicit patch series (just to keep
the dependencies clear to me).

I'm not convinced of the value of this split, nor why we would stop here
if it was useful (vector modes vs. scalar modes would also seem an
important distinction).

If you no longer need the workaround this enables then I'm not sure I see a
good reason for it to go in, maybe I'm missing a target for which this
would be important?

Thanks,
James

[Bug rtl-optimization/70261] [6 Regression] r234265 causes fails on rs6000

[rth at gcc dot gnu.org]

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

--- Comment #3 from Richard Henderson  ---
Created attachment 37993
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37993=edit
aarch64 pbase_type_info.ii

This will ICE with just cc1plus -O.

Re: C++ PATCH to fix missing warning (PR c++/70194)

[Martin Sebor]

While I would find the warning less misleading if it simply said
in all three cases: "the address of 'x' will always evaluate as
‘true’" I think it would be even more accurate if it said
"the address of 'x' may be assumed to evaluate to ‘true’"  That
avoids making claims about whether or not it actually is null,
doesn't talk about the NULL macro when one isn't used in the
code, and by saying "may assume" it allows for both making
the assumption as well as not making one.


That sounds good except that talking about 'true' is wrong when there is
an explicit comparison to a null pointer constant.  I'd be fine with
changing "NULL" to "null" or similar.


Sounds good.  I will use bug 47931 - missing -Waddress warning
for comparison with NULL, to take care of the outstanding cases
where a warning still isn't issued (in either C++ or C) and also
adjust the text of the warning.

Martin

PS It seems that just adding STRIP_NOPS (op) to Marek's patch
significantly increases the number of successfully diagnosed
cases.  (The small patch I attached to 47931 covers nearly all
the remaining cases I could think of.)

[Bug tree-optimization/68714] [6 Regression] less folding of vector comparison

[rth at gcc dot gnu.org]

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

--- Comment #11 from Richard Henderson  ---
Author: rth
Date: Wed Mar 16 23:53:01 2016
New Revision: 234271

URL: https://gcc.gnu.org/viewcvs?rev=234271=gcc=rev
Log:
Gimplify vec_cond_expr with condition inside

  PR middle-end/70240
  PR middle-end/68215
  PR tree-opt/68714
  * gimplify.c (gimplify_expr) [VEC_COND_EXPR]: Gimplify the
  first operand as is_gimple_condexpr.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c

[Bug middle-end/70240] [6 Regression] ICE: in gimplify_modify_expr, at gimplify.c:4854 with -ftree-vectorize

[rth at gcc dot gnu.org]

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

--- Comment #11 from Richard Henderson  ---
Author: rth
Date: Wed Mar 16 23:53:18 2016
New Revision: 234273

URL: https://gcc.gnu.org/viewcvs?rev=234273=gcc=rev
Log:
PR middle-end/70240

  * gcc.c-torture/compile/pr70240.c: New.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr70240.c
Modified:
trunk/gcc/testsuite/ChangeLog

Re: [RFA][PR rtl-optimization/70263] Fix creation of new REG_EQUIV notes

[Bernd Schmidt]

On 03/18/2016 08:14 PM, Jeff Law wrote:

I also added a blurb to the dump file when we create these equivalences
and included a test to verify the code fires.  I verified it fired on
x86 and x86-64.  It may or may not fire on other targets, so I left the
test in the i386 specific subdirectory.


This is the sort of thing I'd want to do with rtl unit tests.


Bootstrapped and regression tested on x86_64-linux-gnu.  And unlike the
last version, it doesn't totally disable the note creation (as verified
by the new test ;-)

OK for the trunk?


Ok.


Bernd

[Bug libfortran/70279] New: Crash duing compilation with NINT and 128 bits integer

[francois.willot at ensmp dot fr]

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

Bug ID: 70279
   Summary: Crash duing compilation with NINT and 128 bits integer
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: francois.willot at ensmp dot fr
  Target Milestone: ---

Compiling the code below makes gfortran 4.8.4 crash:

gfortran -Wall -O3 -pedantic-errors -pedantic -Werror -std=f2003 -fopenmp -cpp
-DMULTITHREADS test.f90

test.f90: In function ‘MAIN__’:
test.f90:17:0: internal compiler error: in build_round_expr, at
fortran/trans-intrinsic.c:394
 PRINT *,NINT(a,i)
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The code is:

PROGRAM MAIN
IMPLICIT NONE
INTEGER, PARAMETER :: i=SELECTED_INT_KIND(30)
DOUBLE PRECISION :: a
a=0.0D0
PRINT *,NINT(a,i)
END


Instead, this code runs as expected

PROGRAM MAIN
IMPLICIT NONE
INTEGER, PARAMETER :: i=SELECTED_INT_KIND(30)
PRINT *,NINT(0.0D0,i),i
END

(It produces:
 0 16  
)

[Bug other/70268] add option -ffile-prefix-map to map one directory name (old) to another (new) in __FILE__, __BASE_FILE__and __builtin_FILE()

[hongxu.jia at windriver dot com]

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

--- Comment #1 from hongxu jia  ---
So I suggest gcc could provide a option '-ffile-prefix-map=='
to map  directory in __FILE__ and replace it with  directory.

It is similar to '-fdebug-prefix-map==', but the latter is used
for DWARF, and the newly added option only works on '__FILE__', '__BASE_FILE__'
and '__builtin_FILE()'

---
5. Compile C source file with '-ffile-prefix-map'
$ gcc ./test.c -ffile-prefix-map=/usr/include= -o test

4. Execute and the header file is not pull path.
$ ./test 
__FILE__ ./test.c
__FILE__ /test.h
---

[Bug middle-end/70240] [6 Regression] ICE: in gimplify_modify_expr, at gimplify.c:4854 with -ftree-vectorize

[rth at gcc dot gnu.org]

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

--- Comment #10 from Richard Henderson  ---
Author: rth
Date: Wed Mar 16 23:53:10 2016
New Revision: 234272

URL: https://gcc.gnu.org/viewcvs?rev=234272=gcc=rev
Log:
Revert r231575

  PR middle-end/70240
  PR middle-end/68215
  2015-12-11  Eric Botcazou  
  * tree-vect-generic.c (tree_vec_extract): Remove GSI parameter.
  Do not gimplify the result.
  (do_unop): Adjust call to tree_vec_extract.
  (do_binop): Likewise.
  (do_compare): Likewise.
  (do_plus_minus): Likewise.
  (do_negate): Likewise.
  (expand_vector_condition): Likewise.
  (do_cond): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-generic.c