ARM gold unknown option.

[Umesh Kalappa]

Hi All ,

We are migrating to the gold linker and see the below issue


bash-4.1$ /auto/compiler-migration/bin/armeb-linux-gnueabi-ld.gold --be8

/auto/compiler-migration/bin/armeb-linux-gnueabi-ld.gold: --be8: unknown option


Any help ,will be appreciated .

Thank you
~Umesh

[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs

[yselkowi at redhat dot com]

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

--- Comment #5 from Yaakov Selkowitz  ---
Possible patch included in attachment 38505 for bug 71133.

[Bug libstdc++/71133] msp430-elf -mlarge FTBFS in libstdc++-v3

[yselkowi at redhat dot com]

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

--- Comment #1 from Yaakov Selkowitz  ---
Created attachment 38505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38505=edit
Draft patch for 6.1

The results of this test are (so far) used only in the code that will later
fail to compile on <32-bit-pointer targets anyway (bug 71135).  There's
probably a much better way of doing this, but the attached patch seems to be a
workaround.

[Bug c/71157] New: -Wnull-dereference false alarm in wrong function

[eggert at gnu dot org]

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

Bug ID: 71157
   Summary: -Wnull-dereference false alarm in wrong function
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at gnu dot org
  Target Milestone: ---

Created attachment 38504
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38504=edit
preprocessed source code for emacs/lib-src/etags.c

I discovered this when compiling bleeding-edge GNU Emacs with GCC 6.1.0 on
x86-64. For the attached file e.i, the shell command:

gcc -O2 -S -Wnull-dereference e.i

issues the diagnostics:

e.i: In function 'Forth_words':
e.i:9690:10: warning: potential null pointer dereference [-Wnull-dereference]
   while (*cp != '\0' && !c_isspace (*cp))
  ^~~
e.i:9690:10: warning: potential null pointer dereference [-Wnull-dereference]
e.i:9690:10: warning: potential null pointer dereference [-Wnull-dereference]

I see three things wrong with these diagnostics. First, line 9690 is nowhere
near the function Forth_words. Second, I see no path to line 9690 in which its
pointer CP can possibly be null. Furthermore, CP is dereferenced only twice in
line 9690, so why are there three warnings?

[Bug fortran/70959] [6/7 Regression] Invalid type determination due to expression in a type declaration statement

[w.clodius at icloud dot com]

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

--- Comment #5 from William Clodius  ---
1. Maybe the placement of the warning is spurious, but is there any chance it
is actually assigning the type REAL(4) to e18?

2. It sounds as if the logic of arith.c is in an incorrect order. What should
be done is roughly?
Is this a parenthesized expression?
  If yes is the expression comma deliminated?
If yes is it a single comma delimination?
  If yes is the first part REAL(4)?
If yes is the second part REAL(4)?
  If yes then it is a COMPLEX(8) expression
Else the parts are inconsistent in type and might be recognized as an
extension
  Else if no is the first part REAL(8)?
If yes then is the second part REAL(8) expression
  If yes then it is a COMPLEX(16) expression
Else the parts are inconsistent in type and might be recognized as an
extension
  Else is the first part another type you want to allow as an extension
...
   Else is it a multi comma deliminated expression?
 if yes then a syntax error, unrecognized expression
   Else it is a scalar expression of the type of the "first" expression

3. By the above if it mistakenly recognizing a complex constant  I would expect
it
   to be to a OMPLEX(16) constant. The message reads as if it might be
converting
   the INTEGER(8) to REAL(8) then deciding that it is part of a COMPLEX(8)
constant.

[Bug preprocessor/69665] Internal error on #pragma push_macro("__FILE__")

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
  Known to fail||4.9.3, 5.3.0, 6.1.0

--- Comment #2 from Martin Sebor  ---
I hit Save Changes prematurely.  Confirmed with all recent versions of GCC
including today's top of trunk (7.0).  The test case looks invalid though
(programs likely shouldn't be allowed to redefine __FILE__ or other standard
predefined macros).

[Bug preprocessor/69665] Internal error on #pragma push_macro("__FILE__")

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-17
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.0

--- Comment #1 from Martin Sebor  ---

$ cat uu.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -c
-Wall -Wextra -Wpedantic uu.c
#pragma push_macro  ("__FILE__")
#define __FILE__ "foobar.c"
#pragma pop_macro ("__FILE__")
uu.c:1:33: internal compiler error: invalid hash type 1 in cpp_macro_definition
 #pragma push_macro  ("__FILE__")
 ^
0x856ad9 c_cpp_error(cpp_reader*, int, int, rich_location*, char const*,
__va_list_tag (*) [1])
/src/gcc-svn/gcc/c-family/c-common.c:10232
0x18ccc54 cpp_diagnostic
/src/gcc-svn/libcpp/errors.c:61
0x18ccd26 cpp_error(cpp_reader*, int, char const*, ...)
/src/gcc-svn/libcpp/errors.c:76
0x18e716e cpp_macro_definition(cpp_reader*, cpp_hashnode*)
/src/gcc-svn/libcpp/macro.c:3352
0x18c9b4e do_pragma_push_macro
/src/gcc-svn/libcpp/directives.c:1542
0x18c9760 do_pragma
/src/gcc-svn/libcpp/directives.c:1457
0x18c79e4 _cpp_handle_directive
/src/gcc-svn/libcpp/directives.c:510
0x18dab37 _cpp_lex_token
/src/gcc-svn/libcpp/lex.c:2214
0x18e52cf cpp_get_token_1
/src/gcc-svn/libcpp/macro.c:2458
0x18e5719 cpp_get_token_with_location(cpp_reader*, unsigned int*)
/src/gcc-svn/libcpp/macro.c:2644
0x87281a c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
/src/gcc-svn/gcc/c-family/c-lex.c:398
0x7d86ce c_lex_one_token
/src/gcc-svn/gcc/c/c-parser.c:274
0x7d8add c_parser_peek_token
/src/gcc-svn/gcc/c/c-parser.c:455
0x80c026 c_parse_file()
/src/gcc-svn/gcc/c/c-parser.c:17903
0x87e56c c_common_parse_file()
/src/gcc-svn/gcc/c-family/c-opts.c:1064
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs

[yselkowi at redhat dot com]

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

--- Comment #4 from Yaakov Selkowitz  ---
(In reply to Yaakov Selkowitz from comment #3)
> It seems that #define _GLIBCXX_USE_WEAK_REF 1 would fix this; the question
> is where exactly it should go (config/os/generic/os_defines.h ?) and under
> what conditions.

Sorry, that should be #define _GLIBCXX_USE_WEAK_REF 0 and (due to
--with-newlib) in config/os/newlib/os_defines.h (which is already defined
inside an ifdef __CYGWIN__ block).

[AARCH64] Remove static variable all_extensions from aarch64.c

[Kugan Vivekanandarajah]

Hi,

static variable all_extensions in aarch64.c is not used and therefore
dead. I don’t see any reason why it should be there. Attached patch
removes this.


Bootstrapped on aarch64-linux-gnu. Regression testing is ongoing.

Is this OK for trunk?

Thanks,
Kugan

gcc/ChangeLog:

2016-05-17  Kugan Vivekanandarajah  

* config/aarch64/aarch64.c (all_extensions): Removed unused static variable.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index e081b16..00ab85b 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -663,16 +663,6 @@ struct aarch64_option_extension
   const unsigned long flags_off;
 };
 
-/* ISA extensions in AArch64.  */
-static const struct aarch64_option_extension all_extensions[] =
-{
-#define AARCH64_OPT_EXTENSION(NAME, X, FLAGS_ON, FLAGS_OFF, FEATURE_STRING) \
-  {NAME, FLAGS_ON, FLAGS_OFF},
-#include "aarch64-option-extensions.def"
-#undef AARCH64_OPT_EXTENSION
-  {NULL, 0, 0}
-};
-
 typedef enum aarch64_cond_code
 {
   AARCH64_EQ = 0, AARCH64_NE, AARCH64_CS, AARCH64_CC, AARCH64_MI, AARCH64_PL,

[PATCH 3/3] function: Restructure *logue insertion

[Segher Boessenkool]

This patch restructures how the prologues/epilogues are inserted.  Sibcalls
that run without prologue are now handled in shrink-wrap.c; it communicates
what is already handled by setting the EDGE_IGNORE flag.  The
try_shrink_wrapping function then doesn't need to be passed the bb_flags
anymore.

Tested like the previous two patches; is this okay for trunk?


Segher


2016-05-16  Segher Boessenkool  

* function.c (make_epilogue_seq): Remove epilogue_end parameter.
(thread_prologue_and_epilogue_insns): Remove bb_flags.  Restructure
code.  Ignore sibcalls on EDGE_IGNORE edges.
* shrink-wrap.c (handle_simple_exit): New function.  Set EDGE_IGNORE
on edges for sibcalls that run without prologue.  The rest of the
function is combined from...
(fix_fake_fallthrough_edge): ... this, and ...
(try_shrink_wrapping): ... a part of this.  Remove the bb_with
function argument, make it a local variable.

---
 gcc/function.c| 168 ++
 gcc/shrink-wrap.c |  88 ++--
 gcc/shrink-wrap.h |   3 +-
 3 files changed, 113 insertions(+), 146 deletions(-)

diff --git a/gcc/function.c b/gcc/function.c
index 75d2ad4..278aaf6 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -5819,13 +5819,13 @@ make_prologue_seq (void)
 }
 
 static rtx_insn *
-make_epilogue_seq (rtx_insn **epilogue_end)
+make_epilogue_seq (void)
 {
   if (!targetm.have_epilogue ())
 return NULL;
 
   start_sequence ();
-  *epilogue_end = emit_note (NOTE_INSN_EPILOGUE_BEG);
+  emit_note (NOTE_INSN_EPILOGUE_BEG);
   rtx_insn *seq = targetm.gen_epilogue ();
   if (seq)
 emit_jump_insn (seq);
@@ -5897,66 +5897,29 @@ make_epilogue_seq (rtx_insn **epilogue_end)
 void
 thread_prologue_and_epilogue_insns (void)
 {
-  bool inserted;
-  bitmap_head bb_flags;
-  rtx_insn *epilogue_end ATTRIBUTE_UNUSED;
-  edge e, entry_edge, orig_entry_edge, exit_fallthru_edge;
-  edge_iterator ei;
-
   df_analyze ();
 
-  rtl_profile_for_bb (ENTRY_BLOCK_PTR_FOR_FN (cfun));
-
-  inserted = false;
-  epilogue_end = NULL;
-
   /* Can't deal with multiple successors of the entry block at the
  moment.  Function should always have at least one entry
  point.  */
   gcc_assert (single_succ_p (ENTRY_BLOCK_PTR_FOR_FN (cfun)));
-  entry_edge = single_succ_edge (ENTRY_BLOCK_PTR_FOR_FN (cfun));
-  orig_entry_edge = entry_edge;
+
+  edge entry_edge = single_succ_edge (ENTRY_BLOCK_PTR_FOR_FN (cfun));
+  edge orig_entry_edge = entry_edge;
 
   rtx_insn *split_prologue_seq = make_split_prologue_seq ();
   rtx_insn *prologue_seq = make_prologue_seq ();
-  rtx_insn *epilogue_seq = make_epilogue_seq (_end);
-
-  bitmap_initialize (_flags, _default_obstack);
+  rtx_insn *epilogue_seq = make_epilogue_seq ();
 
   /* Try to perform a kind of shrink-wrapping, making sure the
  prologue/epilogue is emitted only around those parts of the
  function that require it.  */
 
-  try_shrink_wrapping (_edge, _flags, prologue_seq);
+  try_shrink_wrapping (_edge, prologue_seq);
 
-  if (split_prologue_seq != NULL_RTX)
-{
-  insert_insn_on_edge (split_prologue_seq, orig_entry_edge);
-  inserted = true;
-}
-  if (prologue_seq != NULL_RTX)
-{
-  insert_insn_on_edge (prologue_seq, entry_edge);
-  inserted = true;
-}
-
-  /* If the exit block has no non-fake predecessors, we don't need
- an epilogue.  */
-  FOR_EACH_EDGE (e, ei, EXIT_BLOCK_PTR_FOR_FN (cfun)->preds)
-if ((e->flags & EDGE_FAKE) == 0)
-  break;
-  if (e == NULL)
-goto epilogue_done;
 
   rtl_profile_for_bb (EXIT_BLOCK_PTR_FOR_FN (cfun));
 
-  exit_fallthru_edge = find_fallthru_edge (EXIT_BLOCK_PTR_FOR_FN 
(cfun)->preds);
-
-  /* If nothing falls through into the exit block, we don't need an
- epilogue.  */
-  if (exit_fallthru_edge == NULL)
-goto epilogue_done;
-
   /* A small fib -- epilogue is not yet completed, but we wish to re-use
  this marker for the splits of EH_RETURN patterns, and nothing else
  uses the flag in the meantime.  */
@@ -5967,6 +5930,8 @@ thread_prologue_and_epilogue_insns (void)
  code.  In order to be able to properly annotate these with unwind
  info, try to split them now.  If we get a valid split, drop an
  EPILOGUE_BEG note and mark the insns as epilogue insns.  */
+  edge e;
+  edge_iterator ei;
   FOR_EACH_EDGE (e, ei, EXIT_BLOCK_PTR_FOR_FN (cfun)->preds)
 {
   rtx_insn *prev, *last, *trial;
@@ -5986,78 +5951,84 @@ thread_prologue_and_epilogue_insns (void)
   emit_note_after (NOTE_INSN_EPILOGUE_BEG, prev);
 }
 
-  if (epilogue_seq)
-{
-  insert_insn_on_edge (epilogue_seq, exit_fallthru_edge);
-  inserted = true;
-}
-  else
-{
-  basic_block cur_bb;
+  edge exit_fallthru_edge = find_fallthru_edge (EXIT_BLOCK_PTR_FOR_FN 
(cfun)->preds);
 
-  if (! next_active_insn (BB_END (exit_fallthru_edge->src)))
-   goto 

[PATCH 2/3] function: Factor out make_*logue_seq

[Segher Boessenkool]

Make new functions make_split_prologue_seq, make_prologue_seq, and
make_epilogue_seq.

Tested as in the previous patch; is this okay for trunk?


Segher


2016-05-16  Segher Boessenkool  

* function.c (make_split_prologue_seq, make_prologue_seq,
make_epilogue_seq): New functions, factored out from...
(thread_prologue_and_epilogue_insns): Here.

---
 gcc/function.c | 154 +++--
 1 file changed, 85 insertions(+), 69 deletions(-)

diff --git a/gcc/function.c b/gcc/function.c
index b9a6338..75d2ad4 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -5768,6 +5768,83 @@ set_return_jump_label (rtx_insn *returnjump)
 JUMP_LABEL (returnjump) = ret_rtx;
 }
 
+static rtx_insn *
+make_split_prologue_seq (void)
+{
+  if (!flag_split_stack
+  || lookup_attribute ("no_split_stack", DECL_ATTRIBUTES (cfun->decl)))
+return NULL;
+
+  start_sequence ();
+  emit_insn (targetm.gen_split_stack_prologue ());
+  rtx_insn *seq = get_insns ();
+  end_sequence ();
+
+  record_insns (seq, NULL, _insn_hash);
+  set_insn_locations (seq, prologue_location);
+
+  return seq;
+}
+
+static rtx_insn *
+make_prologue_seq (void)
+{
+  if (!targetm.have_prologue ())
+return NULL;
+
+  start_sequence ();
+  rtx_insn *seq = targetm.gen_prologue ();
+  emit_insn (seq);
+
+  /* Insert an explicit USE for the frame pointer
+ if the profiling is on and the frame pointer is required.  */
+  if (crtl->profile && frame_pointer_needed)
+emit_use (hard_frame_pointer_rtx);
+
+  /* Retain a map of the prologue insns.  */
+  record_insns (seq, NULL, _insn_hash);
+  emit_note (NOTE_INSN_PROLOGUE_END);
+
+  /* Ensure that instructions are not moved into the prologue when
+ profiling is on.  The call to the profiling routine can be
+ emitted within the live range of a call-clobbered register.  */
+  if (!targetm.profile_before_prologue () && crtl->profile)
+emit_insn (gen_blockage ());
+
+  seq = get_insns ();
+  end_sequence ();
+  set_insn_locations (seq, prologue_location);
+
+  return seq;
+}
+
+static rtx_insn *
+make_epilogue_seq (rtx_insn **epilogue_end)
+{
+  if (!targetm.have_epilogue ())
+return NULL;
+
+  start_sequence ();
+  *epilogue_end = emit_note (NOTE_INSN_EPILOGUE_BEG);
+  rtx_insn *seq = targetm.gen_epilogue ();
+  if (seq)
+emit_jump_insn (seq);
+
+  /* Retain a map of the epilogue insns.  */
+  record_insns (seq, NULL, _insn_hash);
+  set_insn_locations (seq, epilogue_location);
+
+  seq = get_insns ();
+  rtx_insn *returnjump = get_last_insn ();
+  end_sequence ();
+
+  if (JUMP_P (returnjump))
+set_return_jump_label (returnjump);
+
+  return seq;
+}
+
+
 
 /* Generate the prologue and epilogue RTL if the machine supports it.  Thread
this into place with notes indicating where the prologue ends and where
@@ -5822,9 +5899,7 @@ thread_prologue_and_epilogue_insns (void)
 {
   bool inserted;
   bitmap_head bb_flags;
-  rtx_insn *returnjump;
   rtx_insn *epilogue_end ATTRIBUTE_UNUSED;
-  rtx_insn *prologue_seq ATTRIBUTE_UNUSED, *split_prologue_seq 
ATTRIBUTE_UNUSED;
   edge e, entry_edge, orig_entry_edge, exit_fallthru_edge;
   edge_iterator ei;
 
@@ -5834,7 +5909,6 @@ thread_prologue_and_epilogue_insns (void)
 
   inserted = false;
   epilogue_end = NULL;
-  returnjump = NULL;
 
   /* Can't deal with multiple successors of the entry block at the
  moment.  Function should always have at least one entry
@@ -5843,46 +5917,9 @@ thread_prologue_and_epilogue_insns (void)
   entry_edge = single_succ_edge (ENTRY_BLOCK_PTR_FOR_FN (cfun));
   orig_entry_edge = entry_edge;
 
-  split_prologue_seq = NULL;
-  if (flag_split_stack
-  && (lookup_attribute ("no_split_stack", DECL_ATTRIBUTES (cfun->decl))
- == NULL))
-{
-  start_sequence ();
-  emit_insn (targetm.gen_split_stack_prologue ());
-  split_prologue_seq = get_insns ();
-  end_sequence ();
-
-  record_insns (split_prologue_seq, NULL, _insn_hash);
-  set_insn_locations (split_prologue_seq, prologue_location);
-}
-
-  prologue_seq = NULL;
-  if (targetm.have_prologue ())
-{
-  start_sequence ();
-  rtx_insn *seq = targetm.gen_prologue ();
-  emit_insn (seq);
-
-  /* Insert an explicit USE for the frame pointer
- if the profiling is on and the frame pointer is required.  */
-  if (crtl->profile && frame_pointer_needed)
-   emit_use (hard_frame_pointer_rtx);
-
-  /* Retain a map of the prologue insns.  */
-  record_insns (seq, NULL, _insn_hash);
-  emit_note (NOTE_INSN_PROLOGUE_END);
-
-  /* Ensure that instructions are not moved into the prologue when
-profiling is on.  The call to the profiling routine can be
-emitted within the live range of a call-clobbered register.  */
-  if (!targetm.profile_before_prologue () && crtl->profile)
-emit_insn (gen_blockage ());
-
-  prologue_seq = get_insns ();
-  end_sequence 

[PATCH 1/3] function: Do the CLEANUP_EXPENSIVE after shrink-wrapping, not before

[Segher Boessenkool]

We should do CLEANUP_EXPENSIVE after shrink-wrapping, because shrink-
wrapping creates constructs that CLEANUP_EXPENSIVE can optimise, and
nothing runs CLEANUP_EXPENSIVE later.  We don't need cleanup_cfg before
shrink-wrapping, nothing in shrink-wrapping (or the other *logue insertion
code) cares at all.

Tested this (and the other two patches in this series) on powerpc64-linux
(-m32/-m64, -mlra/-mno-lra); on powerpc64le-linux; and on x86_64-linux.
No regressions.

Is this okay for trunk?


Segher


2016-05-16  Segher Boessenkool  

* function.c (rest_of_handle_thread_prologue_and_epilogue): Call
cleanup_cfg with CLEANUP_EXPENSIVE after shrink-wrapping.  Don't
call cleanup_cfg before shrink-wrapping.

---
 gcc/function.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/gcc/function.c b/gcc/function.c
index 70584b9..b9a6338 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -6369,9 +6369,6 @@ make_pass_leaf_regs (gcc::context *ctxt)
 static unsigned int
 rest_of_handle_thread_prologue_and_epilogue (void)
 {
-  if (optimize)
-cleanup_cfg (CLEANUP_EXPENSIVE);
-
   /* On some machines, the prologue and epilogue code, or parts thereof,
  can be represented as RTL.  Doing so lets us schedule insns between
  it and the rest of the code and also allows delayed branch
@@ -6384,7 +6381,7 @@ rest_of_handle_thread_prologue_and_epilogue (void)
 
   /* Shrink-wrapping can result in unreachable edges in the epilogue,
  see PR57320.  */
-  cleanup_cfg (0);
+  cleanup_cfg (optimize ? CLEANUP_EXPENSIVE : 0);
 
   /* The stack usage info is finalized during prologue expansion.  */
   if (flag_stack_usage_info)
-- 
1.9.3

[Bug fortran/71156] New: PURE interface/definition inconsistency: accepts invalid, rejects valid

[damian at sourceryinstitute dot org]

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

Bug ID: 71156
   Summary: PURE interface/definition inconsistency: accepts
invalid, rejects valid
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

As shown below, gfortran 6.1.0 rejects the application of the PURE attribute
consistently in a procedure interface body and the corresponding procedure
definition. 
Conversely, gfortran accepts the inconsistent approach (not shown) of using
PURE in the interface body but omitting PURE from the procedure definition.  By
contrast, the Cray and Intel compilers behave opposite to gfortran: Intel and
Cray accept the consistent syntax below and reject the inconsistent syntax in
which PURE appears only in the interface body or only in the definition.  If
Intel and Cray are correct, then gfortran is accepting invalid code and
rejecting the complementary valid code and it would be great if a fix could be
applied to the 6 and 7 branches.

$ cat consistency.f90 
module my_interface
  implicit none
  interface
pure module subroutine f
end subroutine
  end interface
end module 

submodule(my_interface) my_implementation
  implicit none
contains
pure module subroutine f
end subroutine
end submodule

$ gfortran -c consistency.f90 
consistency.f90:12:28:

 pure module subroutine f
1
Error: Duplicate PURE attribute specified at (1)

$ gfortran --version
GNU Fortran (MacPorts gcc6 6.1.0_0) 6.1.0

Re: [PATCH] misc minor doc fixes

[Sandra Loosemore]

On 05/16/2016 05:05 PM, Jim Wilson wrote:

Deletes text claiming that major version changes are rare, and fixes
two misspellings of signaling.

Tested with make info and make dvi.


This looks fine to me.

-Sandra

Re: PING^5 [PATCH, GCC 5] PR 70613, -fabi-version docs don't match implementation

[Sandra Loosemore]

On 05/16/2016 04:35 PM, Jim Wilson wrote:

This is my fifth ping.  I just need someone to rubber stamp it so I
can check it in.


The documentation change looks fine, but as a documentation maintainer 
only I don't think I can approve changes to a release branch.


-Sandra

[Bug c++/70979] [C++14] g++ falsely accepts constexpr function returning a lambda

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Including the following test case from the duplicate bug 71116 (which is
expected to pass in C+++ 14 and prior):

$ cat uu.cpp && /home/msebor/build/gcc-fortify-source/gcc/xgcc
-B/home/msebor/build/gcc-fortify-source/gcc -S uu.cpp
void oops () {
  auto fn = []{ };
  static_assert (!__is_literal_type (decltype (fn)), "oops");
}


uu.cpp: In function ‘void oops()’:
uu.cpp:3:3: error: static assertion failed: oops
   static_assert (!__is_literal_type (decltype (fn)), "oops");
   ^

[Bug libstdc++/71108] to_string is relatively slow

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
(In reply to Adrian Wielgosik from comment #0)
> For example, this function is 3-7x faster than 6.1 std::to_string(unsigned
> int) in a microbenchmark.

https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html

[Bug c++/70979] [C++14] g++ falsely accepts constexpr function returning a lambda

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||eric.niebler at gmail dot com

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

[Bug c++/71116] Lambdas should not be literal types

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Last reconfirmed||2016-5-16
 CC||msebor at gcc dot gnu.org
 Resolution|--- |DUPLICATE
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed with all supported versions of GCC as well as today's trunk of 7.0. 
A slightly simplified test case independent of libstdc++:

$ cat uu.cpp && /home/msebor/build/gcc-fortify-source/gcc/xgcc
-B/home/msebor/build/gcc-fortify-source/gcc -S uu.cpp
void oops () {
  auto fn = []{ };
  static_assert (!__is_literal_type (decltype (fn)), "oops");
}


uu.cpp: In function ‘void oops()’:
uu.cpp:3:3: error: static assertion failed: oops
   static_assert (!__is_literal_type (decltype (fn)), "oops");
   ^

I think this needs to be fixed in tandem with bug 70979 and so is probably
simplest to treat it as a duplicate.

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

[PATCH] misc minor doc fixes

[Jim Wilson]

Deletes text claiming that major version changes are rare, and fixes
two misspellings of signaling.

Tested with make info and make dvi.

Jim
2016-05-16  Jim Wilson  

	* doc/cpp.texi (__GNUC__): Major version changes are no longer rare.
	* doc/invoke.texi (-mnan=2008): Change signalling to signaling.
	* doc/md.texi (fmin@var{m}3): Likewise.

Index: cpp.texi
===
--- cpp.texi	(revision 236231)
+++ cpp.texi	(working copy)
@@ -1984,7 +1984,7 @@ by GCC, or a non-GCC compiler that claims to accep
 you can simply test @code{__GNUC__}.  If you need to write code
 which depends on a specific version, you must be more careful.  Each
 time the minor version is increased, the patch level is reset to zero;
-each time the major version is increased (which happens rarely), the
+each time the major version is increased, the
 minor version and patch level are reset.  If you wish to use the
 predefined macros directly in the conditional, you will need to write it
 like this:
Index: invoke.texi
===
--- invoke.texi	(revision 236231)
+++ invoke.texi	(working copy)
@@ -18130,7 +18130,7 @@ IEEE 754 floating-point data.
 
 The @option{-mnan=legacy} option selects the legacy encoding.  In this
 case quiet NaNs (qNaNs) are denoted by the first bit of their trailing
-significand field being 0, whereas signalling NaNs (sNaNs) are denoted
+significand field being 0, whereas signaling NaNs (sNaNs) are denoted
 by the first bit of their trailing significand field being 1.
 
 The @option{-mnan=2008} option selects the IEEE 754-2008 encoding.  In
Index: md.texi
===
--- md.texi	(revision 236231)
+++ md.texi	(working copy)
@@ -5018,7 +5018,7 @@ it is unspecified which of the two operands is ret
 IEEE-conformant minimum and maximum operations.  If one operand is a quiet
 @code{NaN}, then the other operand is returned.  If both operands are quiet
 @code{NaN}, then a quiet @code{NaN} is returned.  In the case when gcc supports
-signalling @code{NaN} (-fsignaling-nans) an invalid floating point exception is
+signaling @code{NaN} (-fsignaling-nans) an invalid floating point exception is
 raised and a quiet @code{NaN} is returned.
 
 All operands have mode @var{m}, which is a scalar or vector

[Bug c/71152] NULL is not cast to (void *) as it ought to be if compiling code with -c

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Sorry, I didn't finish the sentence: ...please attach the complete preprocessor
output on the off change that the NULL macro isn't expanded to (void*)0 for
some reason.

[Bug c/71152] NULL is not cast to (void *) as it ought to be if compiling code with -c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #3 from Martin Sebor  ---
I'm not able to reproduce this with either 6.1 or the current trunk, or find an
older revision that fails to give the warning.  I would suggest opening a bug
against the Fedora GCC (please att

[Bug middle-end/71155] New: symbol in wrong section .data.rel.local on mips64el

[aurelien at aurel32 dot net]

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

Bug ID: 71155
   Summary: symbol in wrong section .data.rel.local on mips64el
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---
  Host: mips64el-linux-gnuabi64
Target: mips64el-linux-gnuabi64
 Build: mips64el-linux-gnuabi64

Created attachment 38503
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38503=edit
preprocessed source file

When compiling the GNU libc on mips64el-linux-gnuabi64 with GCC >= 4.9, the
resulting libc causes lua 5.2 to not work correcty. It happens this is due to
wrong the compilation of libio/oldstdfiles.c. When using GCC <= 4.8, the
_IO_stdin_ symbol ends up in the data.rel section just like _IO_stdout_ and
_IO_stderr_. When using GCC >= 4.9, the _IO_stdin_ symbol is moved to the
.data.rel.local section, while the two others are unchanged.

This is also reproducible with GCC 5 and GCC 6.

The issue seems to have been introduced by the following patch:
https://gcc.gnu.org/ml/gcc-patches/2014-01/msg01169.html

I have attached the preprocessed source file, the original source file can be
found there:
https://sourceware.org/git/?p=glibc.git;a=blob;f=libio/oldstdfiles.c;h=609b7d9ef2d78f851a29b3d25efbb03f9c76ca91;hb=HEAD

Re: [PATCH 0/4] RFC: RTL frontend

[Jeff Law]

On 05/04/2016 02:49 PM, David Malcolm wrote:


* The existing RTL code is structured around a single function being
  optimized, so, as a simplification, the RTL frontend can only handle
  one function per input file.  Also, the dump format currently uses
  comments to separate functions::

;; Function test_1 (test_1, funcdef_no=0, decl_uid=1758, cgraph_uid=0, 
symbol_order=0)
ISTM we can fix this by adding more true structure to the RTL dump. 
IMHO we have the freedom to extend the RTL dumper to make it easier to 
read the RTL dumps in for this kind of work.





... various pass-specific things, sometimes expressed as comments,
sometimes not

Which seems like a bug to me.



;;
;; Full RTL generated for this function:
;;
(note 1 0 6 NOTE_INSN_DELETED)
;; etc, insns for function "test_1" go here
(insn 27 26 0 6 (use (reg/i:SI 0 ax)) 
../../src/gcc/testsuite/rtl.dg/test.c:7 -1
 (nil))

;; Function test_2 (test_2, funcdef_no=1, decl_uid=1765, cgraph_uid=1, 
symbol_order=1)
... various pass-specific things, sometimes expressed as comments,
sometimes not
;;
;; Full RTL generated for this function:
;;
(note 1 0 5 NOTE_INSN_DELETED)
;; etc, insns for function "test_2" go here
(insn 59 58 0 8 (use (reg/i:SF 21 xmm0)) 
../../src/gcc/testsuite/rtl.dg/test.c:31 -1
 (nil))

  so that there's no clear separation of the instructions between the
  two functions (and no metadata e.g. function names).

  This could be fixed by adding a new clause to the dump e.g.::

Which would seem like a good idea to me.



* Similarly, there are no types beyond the built-in ones; all expressions
  are treated as being of type int.  I suspect that this approach
  will be too simplistic when it comes to e.g. aliasing.
Well, we have pointers back to the tree IL for this kind of thing, but 
it's far from ideal because of the lack of separation that implies.


I wouldn't lose a ton of sleep if we punted this for a while, perhaps 
just dumping the alias set splay tree so we can at least carry that 
information around.




* There's no support for running more than one pass; fixing this would
  require being able to run passes from a certain point onwards.

I think that's OK at this stage.



* Roundtripping of recognized instructions may be an issue (i.e. those
  with INSN_CODE != -1), such as the "667 {jump}" in the following::

(jump_insn 50 49 51 10
  (set (pc)
   (label_ref:DI 59)) ../../src/test-switch.c:18 667 {jump}
   (nil) -> 59)

  since the integer ID can change when the .md files are changed
  (and the associated pattern name is very much target-specific).
  It may be best to reset them to -1 in the input files (and delete the
  operation name), giving::
Just ignore the index and the pretty name.  When you're done reading the 
file, call recog on each insn to get that information filled in.





(jump_insn 50 49 51 10
  (set (pc)
   (label_ref:DI 59)) ../../src/test-switch.c:18 -1
   (nil) -> 59)

* Currently there's no explicit CFG edge information in the dumps.
  The rtl1 frontend reconstructs the edges based on jump instructions.
  As I understand the distinction between cfgrtl and cfglayout modes
  https://gcc.gnu.org/wiki/cfglayout_mode , this is OK for "cfgrtl" mode,
  but isn't going to work for "cfglayout" mode - in the latter,
  unconditional jumps are represented purely by edges in the CFG, and this
  information isn't currently present in the dumps  (perhaps we could add it
  if it's an issue).
We could either add the CFG information or you could extract it from the 
guts of the RTL you read.  The former leads to the possibility of an 
inconsistent view of the CFG.  The latter is more up-front work and has 
to deal with the differences between cfgrtl and cfglayout modes.




Open Questions
**

* Register numbering: consider this fragment of RTL emitted during
  expansion::

(reg/f:DI 82 virtual-stack-vars)

  At the time of emission, register 82 is the VIRTUAL_STACK_VARS_REGNUM,
  and this value is effectively hardcoded into the dump.  Presumably this
  is baking in assumptions about the target into the test.  Also, how likely is
  this value to change?  When we reload the dump, should we notice that this
  is tagged with virtual-stack-vars and override the specific register
  number to use the current value of VIRTUAL_STACK_VARS_REGNUM on the
  target rtl1 was built for?
Those change semi-regularly.  Essentially anytime a new version of the 
ISA shows up with new register #s.


My instinct is to drop raw numbers and just output them symbolicly.  We 
can map them back into the hard register numbers easy enough.  We would 
want to use some magic to identify pseudo regs.  P1...PN in the dumps 
which we'd map to FIRST_PSEUDO_REGISTER+N when we read the file in.



Jeff

Re: match.pd: ~X & Y to X ^ Y in some cases

[Jeff Law]

On 05/16/2016 04:31 PM, Marc Glisse wrote:

On Mon, 16 May 2016, Jeff Law wrote:


Please use if (GIMPLE
   && ((get_nonzero_bits ...)

Rather than #if GIMPLE


Richard asked for the reverse in some previous patch:
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01617.html

I don't really care which one we settle on...

If Richi wanted the reverse, then go with it.  I'm not going to object 
over something like that.


jeff

Re: PING^5 [PATCH, GCC 5] PR 70613, -fabi-version docs don't match implementation

[Jim Wilson]

This is my fifth ping.  I just need someone to rubber stamp it so I
can check it in.

Maybe it would be easier if I volunteered to be a doc maintainer so I
can self approve it?

Jim

On Mon, May 9, 2016 at 4:21 PM, Jim Wilson  wrote:
> On Mon, May 2, 2016 at 12:13 PM, Jim Wilson  wrote:
>> Here is a patch to correct the -fabi-version docs on the GCC 5 branch.
>> https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00480.html
>
> You can see the default -fabi-version in gcc/c-family/c-opts.c on the
> gcc-5 branch which has
>
>   /* Change flag_abi_version to be the actual current ABI level for the
>  benefit of c_cpp_builtins.  */
>   if (flag_abi_version == 0)
> flag_abi_version = 9;
>
> You can see in the docs that -fabi-version only goes up to 8.
> 
> https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/C_002b_002b-Dialect-Options.html#C_002b_002b-Dialect-Options
>
> As for how we got here...
> I see that the patch for bug 65945 was back ported to the gcc-5
> branch, which required a partial backport of the patch for bug 44282,
> which added abi version 9.  The original patch for 44282 is missing
> the doc change.
>
> The missing doc change was then added here
> https://gcc.gnu.org/viewcvs/gcc?view=revision=228017
> which has the invoke.texi hunk we need, but is missing a ChangeLog
> entry for it.  So it appears all we need is a partial backport of this
> invoke.texi hunk.  This is mostly documenting a change to -Wabi, so we
> only need parts of two hunks that document -fabi-version=9 and mention
> gcc-5.2.
>
> The patch is attached again.
>
> Jim
Index: ChangeLog
===
--- ChangeLog	(revision 234867)
+++ ChangeLog	(working copy)
@@ -1,3 +1,12 @@
+2016-04-11  Jim Wilson  
+
+	Partial backport from trunk r228017.
+	2015-09-22  Jason Merrill  
+
+	PR c++/70613
+	* doc/invoke.texi (-fabi-version): Document version 9.
+	(-Wabi): Document version 9.  Mention version 8 is default for GCC 5.1.
+
 2016-04-09  Oleg Endo  
 
 	Backport from mainline
Index: doc/invoke.texi
===
--- doc/invoke.texi	(revision 234867)
+++ doc/invoke.texi	(working copy)
@@ -2118,6 +2118,9 @@ scope.
 Version 8, which first appeared in G++ 4.9, corrects the substitution
 behavior of function types with function-cv-qualifiers.
 
+Version 9, which first appeared in G++ 5.2, corrects the alignment of
+@code{nullptr_t}.
+
 See also @option{-Wabi}.
 
 @item -fabi-compat-version=@var{n}
@@ -2619,7 +2622,15 @@ When mangling a function type with function-cv-qua
 un-qualified function type was incorrectly treated as a substitution
 candidate.
 
-This was fixed in @option{-fabi-version=8}.
+This was fixed in @option{-fabi-version=8}, the default for GCC 5.1.
+
+@item
+@code{decltype(nullptr)} incorrectly had an alignment of 1, leading to
+unaligned accesses.  Note that this did not affect the ABI of a
+function with a @code{nullptr_t} parameter, as parameters have a
+minimum alignment.
+
+This was fixed in @option{-fabi-version=9}, the default for GCC 5.2.
 @end itemize
 
 It also warns about psABI-related changes.  The known psABI changes at this

Re: match.pd: ~X & Y to X ^ Y in some cases

[Marc Glisse]

On Mon, 16 May 2016, Jeff Law wrote:


Please use if (GIMPLE
   && ((get_nonzero_bits ...)

Rather than #if GIMPLE


Richard asked for the reverse in some previous patch:
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01617.html

I don't really care which one we settle on...

--
Marc Glisse

Re: [PATCH 4/4] Initial version of RTL frontend

[Jeff Law]

On 05/10/2016 08:13 AM, David Malcolm wrote:

On Wed, 2016-05-04 at 16:49 -0400, David Malcolm wrote:
[...snip...]


I wrote this by compiling a test.c with -fdump-rtl-all on
x86_64-pc-linux-gnu, and then attempting to load the state at each
pass, and then trying to run just one pass, and fixing bugs until the
dump output from each pass was the same as when running the pass from
cc1.  I've only done this with a small subset of passes, and with a
very
simple test case, so I'm sure there are plenty of bugs and "x86_64
-isms"
remaining.


[...snip...]

On the subject of "x86_64-isms", a couple of issues I ran into when
testing with --target=aarch64-linux-gnu:

* roundtrip.exp fails due to different register names so e.g. this from
x86_64:

 (reg:SI 5 di [ i ]))

  becomes this after roundtripping on aarch64:

 (reg:SI 5 x5 [ i ]))

  (i.e. "di" vs "x5" for register 5).

* unknown modes e.g. this from x86_64:

(reg:CCGC 17 flags)

  fails on aarch64 due to the lack of a "CCGC" mode.
Fundamentally all this stuff is target dependent.  Trying to read in an 
x86-64 generated dump into an aarch64 targeted compiler is a waste of 
time/effort.  THe number of things you're going to stumble over are 
innumerable.


I think we lay down the law that RTL dumps are target specific.There 
probably should be some kind of metadata emitted in the dump file which 
identifies the target and if we try to read in the wrong stuff, we get a 
nice error.


jeff

Re: [PATCH 2/3] Add profiling support for IVOPTS

[Bin.Cheng]

> As profile-guided optimization can provide very useful information
> about basic block frequencies within a loop, following patch set leverages
> that information. It speeds up a single benchmark from upcoming SPECv6
> suite by 20% (-O2 -profile-generate/-fprofile use) and I think it can
> also improve others (currently measuring numbers for PGO).
Hi,
Is this 20% improvement from this patch, or does it include the
existing PGO's improvement?

For the patch:
> +
> +  /* Return true if the frequency has a valid value.  */
> +  bool has_frequency ();
> +
>/* Return infinite comp_cost.  */
>static comp_cost get_infinite ();
>
> @@ -249,6 +272,9 @@ private:
>   complexity field should be larger for more
>   complex expressions and addressing modes).  */
>int m_scratch;  /* Scratch used during cost computation.  */
> +  sreal m_frequency;  /* Frequency of the basic block this comp_cost
> + belongs to.  */
> +  sreal m_cost_scaled;  /* Scalled runtime cost.  */
IMHO we shouldn't embed frequency in comp_cost, neither record scaled
cost in it.  I would suggest we compute cost and amortize the cost
over frequency in get_computation_cost_at before storing it into
comp_cost.  That is, once cost is computed/stored in comp_cost, it is
already scaled with frequency.  One argument is frequency info is only
valid for use's statement/basic_block, it really doesn't have clear
meaning in comp_cost structure.  Outside of function
get_computation_cost_at, I found it's hard to understand/remember
what's the meaning of comp_cost.m_frequency and where it came from.
There are other reasons embedded in below comments.
>
>
>  comp_cost&
> @@ -257,6 +283,8 @@ comp_cost::operator= (const comp_cost& other)
>m_cost = other.m_cost;
>m_complexity = other.m_complexity;
>m_scratch = other.m_scratch;
> +  m_frequency = other.m_frequency;
> +  m_cost_scaled = other.m_cost_scaled;
>
>return *this;
>  }
> @@ -275,6 +303,7 @@ operator+ (comp_cost cost1, comp_cost cost2)
>
>cost1.m_cost += cost2.m_cost;
>cost1.m_complexity += cost2.m_complexity;
> +  cost1.m_cost_scaled += cost2.m_cost_scaled;
>
>return cost1;
>  }
> @@ -290,6 +319,8 @@ comp_cost
>  comp_cost::operator+= (HOST_WIDE_INT c)
This and below operators need check for infinite cost first and return
immediately.
>  {
>this->m_cost += c;
> +  if (has_frequency ())
> +this->m_cost_scaled += scale_cost (c);
>
>return *this;
>  }
> @@ -5047,18 +5128,21 @@ get_computation_cost_at (struct ivopts_data *data,
>   (symbol/var1/const parts may be omitted).  If we are looking for an
>   address, find the cost of addressing this.  */
>if (address_p)
> -return cost + get_address_cost (symbol_present, var_present,
> -offset, ratio, cstepi,
> -mem_mode,
> -TYPE_ADDR_SPACE (TREE_TYPE (utype)),
> -speed, stmt_is_after_inc, can_autoinc);
> +{
> +  cost += get_address_cost (symbol_present, var_present,
> + offset, ratio, cstepi,
> + mem_mode,
> + TYPE_ADDR_SPACE (TREE_TYPE (utype)),
> + speed, stmt_is_after_inc, can_autoinc);
> +  goto ret;
> +}
>
>/* Otherwise estimate the costs for computing the expression.  */
>if (!symbol_present && !var_present && !offset)
>  {
>if (ratio != 1)
>   cost += mult_by_coeff_cost (ratio, TYPE_MODE (ctype), speed);
> -  return cost;
> +  goto ret;
>  }
>
>/* Symbol + offset should be compile-time computable so consider that they
> @@ -5077,7 +5161,8 @@ get_computation_cost_at (struct ivopts_data *data,
>aratio = ratio > 0 ? ratio : -ratio;
>if (aratio != 1)
>  cost += mult_by_coeff_cost (aratio, TYPE_MODE (ctype), speed);
> -  return cost;
> +
> +  goto ret;
>
>  fallback:
>if (can_autoinc)
> @@ -5093,8 +5178,13 @@ fallback:
>  if (address_p)
>comp = build_simple_mem_ref (comp);
>
> -return comp_cost (computation_cost (comp, speed), 0);
> +cost = comp_cost (computation_cost (comp, speed), 0);
>}
> +
> +ret:
> +  cost.calculate_scaled_cost (at->bb->frequency,
> +  data->current_loop->header->frequency);
Here cost consists of two parts.  One is for loop invariant
computation, we amortize is against avg_loop_niter and record register
pressure (either via invriant variables or invariant expressions) for
it;  the other is loop variant part.  For the first part, we should
not scaled it using frequency, since we have already assumed it would
be hoisted out of loop.  No matter where the use is, hoisted loop
invariant has the same frequency as loop header.  This is the second
reason I want to factor frequency out of comp_cost.  It's easier to
scale with frequency only it's necessary.

> +  return cost;
>  }
>
>  /* Determines the cost of the computation by that USE is expressed
> @@ -5922,16 +6012,19 @@ determine_group_iv_costs (struct ivopts_data *data)
>group = data->vgroups[i];
>
>fprintf (dump_file, "Group %d:\n", i);
> -  fprintf (dump_file, "  

Re: [PATCH] Import config.sub and config.guess from upstream.

[Jeff Law]

On 05/13/2016 01:55 AM, Jakub Sejdak wrote:

+2016-05-13  Jakub Sejdak  

+* config.guess: Import version 2016-04-02 (newest).
+* config.sub: Import version 2016-05-10 (newest).


Installed on the trunk.  I think this was NAK's for the release branches.

jeff

Re: [PATCH 3/3] Allow constant global VAR_DECLs in constant jump functions

[Jeff Law]

On 05/12/2016 10:09 AM, Martin Jambor wrote:

Hi,

the following patch adds the final step necessary to perform
optimization requested in PR 69708, i.e do indirect inlining of a
function passed by value in a structure.  It allows jump functions to
be aggregate global constant VAR_DECLs, which enables the
constructor-walking code introduced in the first patch of the series
to deduce aggregate contents from it.  IPA-CP expects jump-functions
to be scalars, and they indeed need be for processing arithmetic
jump-functions, but this patch allows any tree for the simple ones.

Bootstrapped, lto-bootstrapped tested on x86_64.  OK for trunk?

Thanks,

Martin


2016-05-11  Martin Jambor  

PR ipa/69708
* ipa-cp.c (ipa_get_jf_pass_through_result): Allow non-ip constant
input for NOP_EXPR pass-through functions.
* ipa-prop.c (ipa_compute_jump_functions_for_edge): Allow
aggregate global constant VAR_DECLs in constant jump functions.

testsuite/
* gcc.dg/ipa/iinline-cstagg-2.c: New test.
* gcc.dg/ipa/ipcp-cstagg-5.c: Likewise.
* gcc.dg/ipa/ipcp-cstagg-6.c: Likewise.
* gcc.dg/ipa/ipcp-cstagg-7.c: Likewise.

LGTM.
jeff

[Bug target/71153] aarch64 LSE __atomic_fetch_and() generates inversion for constants

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
The other way of fixing this is to expose the NOT in RTL before register
allocator.  That is harder but still doable.

[Bug target/71153] aarch64 __atomic_fetch_and() generates probably incorrect double inversion

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-16
 CC||pinskia at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
LDCLRL does MEM &= ~op.

LDCLR – atomic AND NOT (bitclear) of a location with value in a register, with
original data loaded into a register.
Applies to 8, 16, 32, 64 bits. Each instruction can have one of four possible
orderings - acquire, release,
acquire, no order, as it performs both a load and a store.

So the code is correct just not optimal.


Something like this should get the code back to optimal:
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 236c819..ad92f6a 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -11607,6 +11607,7 @@ aarch64_gen_atomic_ldop (enum rtx_code code, rtx
out_data, rtx out_result,
   aarch64_atomic_load_op_code ldop_code;
   rtx src;
   rtx x;
+  bool already_swapped = false;

   if (out_data)
 out_data = gen_lowpart (mode, out_data);
@@ -11614,6 +11615,12 @@ aarch64_gen_atomic_ldop (enum rtx_code code, rtx
out_data, rtx out_result,
   if (out_result)
 out_result = gen_lowpart (mode, out_result);

+  if (code == AND && CONST_INT_P (value))
+{
+  value = simplify_gen_unary (NOT, mode, value, mode);
+  already_swapped = true;
+}
+
   /* Make sure the value is in a register, putting it into a destination
  register if it needs to be manipulated.  */
   if (!register_operand (value, mode)
@@ -11670,8 +11677,11 @@ aarch64_gen_atomic_ldop (enum rtx_code code, rtx
out_data, rtx out_result,
if (short_mode)
  src = gen_lowpart (wmode, src);

-   not_src = gen_rtx_NOT (wmode, src);
-   emit_insn (gen_rtx_SET (src, not_src));
+   if (!already_swapped)
+ {
+   not_src = gen_rtx_NOT (wmode, src);
+   emit_insn (gen_rtx_SET (src, not_src));
+ }

if (short_mode)
  src = gen_lowpart (mode, src);

Re: [PATCH 1/3] Indirect inlining of targets from references of global constants

[Jeff Law]

On 05/12/2016 10:08 AM, Martin Jambor wrote:

Hi,

the patch below implements deducing aggregate contents from pointers
to constant variables for inlining and IPA-CP, which finally makes us
perform the optimization requested in
https://gcc.gnu.org/ml/gcc/2014-07/msg00240.html. It also lays down
the basis for doing optimization requested in PR 69708 but two
additional small patches are required for that.

This means we do not give up if we can't use AA to prove that
the memory in question has not been clobbered since invocation of the
function but only mark this fact in the indirect_call_info.  Later on
we still use this information if we know that the parameter in
question points to a constant variable.

If this is deemed a god approach, we will probably want to add a
similar bit to inlining conditions.

Bootstrapped, lto-bootstrapped and tested on x86_64-linux. OK for
trunk?

Thanks,

Martin


2016-05-11  Martin Jambor  

PR ipa/69708
* cgraph.h (cgraph_indirect_call_info): New field
guaranteed_unmodified.
* ipa-cp.c (ipa_get_indirect_edge_target_1): Also pass parameter value
to ipa_find_agg_cst_for_param, check guaranteed_unmodified when
appropriate.
* ipa-inline-analysis.c (evaluate_conditions_for_known_args): Also
pass the parameter value to ipa_find_agg_cst_for_param.
* ipa-prop.c (ipa_load_from_parm_agg): New parameter
guaranteed_unmodified, store AA results there instead of bailing out
if present.
(ipa_note_param_call): Also initialize guaranteed_unmodified flag.
(ipa_analyze_indirect_call_uses): Also set guaranteed_unmodified flag.
(find_constructor_constant_at_offset): New function.
(ipa_find_agg_cst_from_init): Likewise.
(ipa_find_agg_cst_for_param): Also seearch for aggregate values in
static initializers of contants, report back through a new paameter
from_global_constant if that was the case.
(try_make_edge_direct_simple_call): Also pass parameter value to
ipa_find_agg_cst_for_param, check guaranteed_unmodified when
appropriate.
(ipa_write_indirect_edge_info): Stream new flag guaranteed_unmodified.
(ipa_read_indirect_edge_info): Likewise.
* ipa-prop.h (ipa_find_agg_cst_for_param): Update declaration.
(ipa_load_from_parm_agg): Likewise.

testsuite/
* gcc.dg/ipa/iinline-cstagg-1.c: New test.
* gcc.dg/ipa/ipcp-cstagg-1.c: Likewise.
* gcc.dg/ipa/ipcp-cstagg-2.c: Likewise.
* gcc.dg/ipa/ipcp-cstagg-3.c: Likewise.
* gcc.dg/ipa/ipcp-cstagg-4.c: Likewise.
---

LGTM.
jeff

[C++ Patch] PR 70466 ("ICE on invalid code in tree check: expected constructor, have parm_decl in convert_like_real...")

[Paolo Carlini]

Hi,

in this ICE during error recovery, the check in convert_like_real:

if (CONSTRUCTOR_NELTS (expr) == 0
&& FUNCTION_FIRST_USER_PARMTYPE (convfn) != void_list_node)

is reached for a PARM_DECL as expr. I think that the correct way to 
avoid in general such problem is adding (here too, as elsewhere) a check 
that BRACE_ENCLOSED_INITIALIZER_P (expr) is true to the outer 
conditional, for sure because talking about "converting to %qT from 
initializer list would use explicit constructor %qD", which happens 
anyway in the above conditional, otherwise doesn't make sense. Tested 
x86_64-linux.


Thanks,
Paolo.

/
/cp
2016-05-16  Paolo Carlini  

PR c++/70466
* call.c (convert_like_real): Check that we are actually converting
from an init list.

/testsuite
2016-05-16  Paolo Carlini  

PR c++/70466
* g++.dg/template/crash122.C: New.
Index: cp/call.c
===
--- cp/call.c   (revision 236300)
+++ cp/call.c   (working copy)
@@ -6377,6 +6377,7 @@ convert_like_real (conversion *convs, tree expr, t
/* When converting from an init list we consider explicit
   constructors, but actually trying to call one is an error.  */
if (DECL_NONCONVERTING_P (convfn) && DECL_CONSTRUCTOR_P (convfn)
+   && BRACE_ENCLOSED_INITIALIZER_P (expr)
/* Unless this is for direct-list-initialization.  */
&& !DIRECT_LIST_INIT_P (expr)
/* And in C++98 a default constructor can't be explicit.  */
Index: testsuite/g++.dg/template/crash122.C
===
--- testsuite/g++.dg/template/crash122.C(revision 0)
+++ testsuite/g++.dg/template/crash122.C(working copy)
@@ -0,0 +1,27 @@
+// PR c++/70466
+
+template < class T, class T >  // { dg-error "conflicting" }
+class A
+{
+public:
+  explicit A (T (S::*f) ()) {}  // { dg-error "expected" }
+};
+
+template < class T, class S > 
+A < T, S > foo (T (S::*f) ())
+{
+  return A < T, S > (f);
+}
+
+class B
+{
+public:
+  void bar () {}
+};
+
+int
+main ()
+{
+  foo (::bar);
+  return 0;
+}

[Bug c++/71154] Attributes for an explicit template instantiation are ignored

[abbeyj+gcc at gmail dot com]

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

--- Comment #1 from James Abbatiello  ---
Created attachment 38502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38502=edit
Too simple patch

[Bug c++/71154] New: Attributes for an explicit template instantiation are ignored

[abbeyj+gcc at gmail dot com]

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

Bug ID: 71154
   Summary: Attributes for an explicit template instantiation are
ignored
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abbeyj+gcc at gmail dot com
  Target Milestone: ---

Created attachment 38501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38501=edit
Reproducer

Trying to apply attributes (like visibility("default")) to an explicit template
instantiation does not work if the type has been previously mentioned in the
translation unit.

This was previously reported as part of bug #50044.  But that bug was
eventually marked as a duplicate of bug #40068 which only seems to cover the
problem with typeinfo.  The part about the problem with attributes seems to
have been lost so I'm opening this bug to cover it.

STR:
==
$ cat main.cpp
template 
class C
{
void foo();
};

C g_c_int;
C g_c_double;

template 
void C::foo() {}

template class __attribute__((visibility("default"))) C;
template class C;


$ g++ -fvisibility=hidden -fPIC -shared main.cpp -o main.so
main.cpp:13:55: warning: type attributes ignored after type is already defined
[-Wattributes]
 template class __attribute__((visibility("default"))) C;
   ^~


$ nm -C main.so | grep foo
061c t C::foo()
0610 t C::foo()

==

Note that C::foo() is marked as local (lowercase t) when the intent was to
make it global (uppercase).  When compiled with clang++ instead there are no
warnings and nm reports:
0510 t C::foo()
0500 W C::foo()

where C::foo() is global as desired.

Similar code, with the __attribute__ replaced with __declspec(dllexport), works
as expected with MSVC 2012.  That is, C::foo() is exported from the DLL
and C::foo() is not.


I have a patch for this which I will attach.  It just removes the relevant
checks entirely.  This seems likely to cause problems elsewhere but perhaps it
gives somebody an idea on where to start.

[Bug target/71153] aarch64 __atomic_fetch_and() generates probably incorrect double inversion

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
(In reply to dhowe...@redhat.com from comment #0)
> ... If nothing else, the MOVN and MOV could be condensed into just a MOV. ...

The MOVN and the MVN could be condensed, that is.

[Bug target/71153] New: aarch64 __atomic_fetch_and() generates probably incorrect double inversion

[dhowells at redhat dot com]

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

Bug ID: 71153
   Summary: aarch64 __atomic_fetch_and() generates probably
incorrect double inversion
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Compiling this code:

static __always_inline
void clear_bit_unlock(long bit, volatile unsigned long *addr)
{
unsigned long mask = 1UL << (bit & (64 - 1));
addr += bit >> 6;
__atomic_fetch_and(addr, ~mask, __ATOMIC_RELEASE);
}

void bar_clear_bit_unlock(unsigned long *p)
{
clear_bit_unlock(22, p);
}

for aarch64-linux-gnu with "-march=armv8-a+lse -Os" generates a double negation
of the mask value in the assembly:

007c :
  7c:   92a00801mov x1, #0xffbf // #-4194305
  80:   aa2103e1mvn x1, x1
  84:   f8611001ldclrl  x1, x1, [x0]
  88:   d65f03c0ret

The instruction at 7c is loading an inverted value into x1 (it's actually a
MOVN instruction according to the opcode table that I can find); the value in
x1 is then inverted *again* by the MVN instruction.

Now, I can't find a description of how the LDCLRL instruction works, so I can't
say that it doesn't invert the parameter a third time (ie. apply an A AND-NOT B
operation), but it looks suspicious.  If nothing else, the MOVN and MOV could
be condensed into just a MOV.

If a parameter is used instead of a constant:

void foo_clear_bit_unlock(long bit, unsigned long *p)
{
clear_bit_unlock(bit, p);
}

then two MVN instructions are generated:

0048 :
  48:   12001403and w3, w0, #0x3f
  4c:   9346fc02asr x2, x0, #6
  50:   d2800020mov x0, #0x1// #1
  54:   8b020c21add x1, x1, x2, lsl #3
  58:   9ac32000lsl x0, x0, x3
  5c:   aa2003e0mvn x0, x0
  60:   aa2003e2mvn x2, x0
  64:   f8621022ldclrl  x2, x2, [x1]
  68:   d65f03c0ret

The C code appears to be correct, because on x86_64 it generates:

004c :
  4c:   f0 48 81 27 ff ff bflock andq $0xffbf,(%rdi)
  53:   ff 
  54:   c3  retq

[Bug libstdc++/11196] _GNU_SOURCE vs. M_PI

[j.v.dijk at tue dot nl]

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

Jan van Dijk  changed:

   What|Removed |Added

 CC||j.v.dijk at tue dot nl

--- Comment #10 from Jan van Dijk  ---
Has this been (partly) fixed in the meantime? The OP's test program compiles
just fine with:

  g++ (SUSE Linux) 4.8.3 20140627 [gcc-4_8-branch revision 212064]
  g++ (SUSE Linux) 5.3.1 20160412 [gcc-5-branch revision 234894]
  g++ (GCC) 7.0.0 20160516 (experimental)
  x86_64-w64-mingw32.shared-g++ (GCC) 4.9.3

I also see that GNU_SOURCE is no longer implicitly defined. At least, I do not
see that in the output of "g++ -dM -E - < /dev/null" anymore.

Are there any remaining issues, or should this report be closed?

Re: (R5900) Implementing Vector Support

[Richard Henderson]

On 05/14/2016 03:21 AM, Woon yung Liu wrote:

The current constraints allow GCC to access the 64-bit LO+HI register pair
as a single 128-bit register, so I am cheating by using both the x and wr
(new constraint for LO1+HI1) constraints.


That doesn't seem right.

The x constrant is for the hi/lo pair, whatever size it is.  You should be able 
to use that just fine with a 256 bit mode.



r~

Re: [PATCH] Enable libgloss support for ARC in top-level configure.ac

[Jeff Law]

On 05/13/2016 06:35 AM, Anton Kolesov wrote:

2016-05-13  Anton Kolesov  

* configure.ac: Add ARC support to libgloss.
* configure: Regenerate
Thanks.  Installed on the trunk after moving a mis-placed ChangeLog 
entry from Wilco.


Jeff

[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090

[dominiq at lps dot ens.fr]

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

--- Comment #18 from Dominique d'Humieres  ---
> smoke test passes, I'll leave it to Dominique's full-run to confirm.

With the patch in comment 15 applied on top of revision r236286 the reported
failures are gone.

From the fix, would it be possible to derive a test failing on linux?

Also the test gcc.target/i386/pr70799-1.c fails

FAIL: gcc.target/i386/pr70799-1.c scan-assembler movdqa[ t]+.LC0

In the assembly I see

movdqa  LC0-L3$pb(%eax), %xmm0

with nothing between \t and L.

Re: match.pd: ~X & Y to X ^ Y in some cases

[Jeff Law]

On 05/13/2016 01:07 PM, Marc Glisse wrote:

Hello,

maybe this would fit better in VRP, but it is easier (and not completely
useless) to put it in match.pd.

Since the transformation is restricted to GIMPLE, I think I don't need
to check that @0 is SSA_NAME. I didn't test if @0 has pointer type
before calling get_range_info because we are doing bit_not on it, but it
looks like I should because we can do bitops on pointers?

Adjustment for pr69270.c is exactly the same as in the previous patch
from today :-)

Bootstrap+regtest on powerpc64le-unknown-linux-gnu.


2016-05-16  Marc Glisse  

gcc/
* match.pd (~X & Y): New transformation.

gcc/testsuite/
* gcc.dg/tree-ssa/pr69270.c: Adjust.
* gcc.dg/tree-ssa/andnot-1.c: New testcase.



Please use if (GIMPLE
&& ((get_nonzero_bits ...)

Rather than #if GIMPLE

With that, OK.

jeff

[Bug rtl-optimization/71150] [7 Regression] ICE on valid code at -O1 and above in 64-bit mode on x86_64-linux-gnu in lra_eliminate_reg_if_possible, at lra-eliminations.c:1402

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

 Target||i386*
 Status|NEW |ASSIGNED

--- Comment #2 from Jiong Wang  ---
r236181 was assuming SUBREG_REG (x) is a REG, but actually it might be not, at
least for i386. A simple new guard of REG_P check can fix this regression.

Will explore more to see what's the best fix and propose a patch shortly.

Re: (R5900) Implementing Vector Support

[Richard Henderson]

On 05/15/2016 03:43 AM, Woon yung Liu wrote:

  testv.c:70:2: note: ==> examining statement: _5 = (int) _4;


You need to implement the vec_unpack* patterns.


But how can I tell what operations are required by autovectorization, that are 
currently not supported?


Well, the dumps you're looking at are the start.  But it also requires that you 
look through tree-vect-stmts.c.




My port is still missing the instructions for initializing vectors, and
inserting/setting and extracting values from vectors. They aren't
implemented yet because I haven't figured out how to implement them; the
documentation describes them as simple operations, but yet the
implementations within mips.c do a lot more things!


Efficient vector initialization requires that we detect some common cases.  We 
do that before the fully general mips_expand_vi_general.



r~

Re: RFA: Generate normal DWARF DW_LOC descriptors for non integer mode pointers

[Jeff Law]

On 05/16/2016 08:12 AM, Nick Clifton wrote:

Hi Guys,

  Currently dwarf2out.c:mem_loc_descriptor() has some special case
  code to handle the situation where an address is held in a register
  whose mode is not of type MODE_INT.  It generates a
  DW_OP_GNU_regval_type expression which may later on be converted into
  a frame pointer based expression.  This is a problem for targets which
  use a partial integer mode for their pointers (eg the msp430).  In
  such cases the conversion to a frame pointer based expression could
  be wrong if the frame pointer is not being used.

  For example the GDB testfile gdb/testsuite/gdb.base/advance.c contains
  this code fragment:

int
main ()
{
  int result;
  int b, c;
  c = 5;
  b = 3;/* advance this location */

  func (c); /* stop here after leaving current frame */

  which compiles to these instructions:

suba#6, r1
mov #5, 4(r1)   
mov #3, 2(r1)   
mov 4(r1),  r12 
calla   #0  ;

  (Note that only r1 - the stack pointer - is used.  r4 - the frame
  pointer - is not).

  The debug information produced for the "c" local variable looks like
  this:

Abbrev Number: 3 (DW_TAG_variable)
 DW_AT_name: c
 DW_AT_decl_file   : 1
 DW_AT_decl_line   : 40
 DW_AT_type: <0x37>
 DW_AT_location: 5 byte block: f5 4 21 32 1c(DW_OP_GNU_regval_type: 4 
(r4) <0x21>; DW_OP_lit2; DW_OP_minus)

  ie it says that "c" is stored in memory location "r4 - 2", which is
  wrong since register r4 is not even used in this function.

  The patch below addresses this problem by allowing the normal,
  register based descriptor to be produced when the mode is Pmode.

  With this patch applied the unexpected failure count in the GDB
  testsuite for the MSP430's -mlarge multilib changes from 2253 to 367.
  There are no regressions, for MSP430 or x86_64, and no changes to
  the GCC testsuite results for either target.

  OK to apply ?

Cheers
  Nick

gcc/ChangeLog
2016-05-16  Nick Clifton  

* dwarf2out.c (mem_loc_descriptor): Convert REG based addresses
whose mode is Pmode into basereg descriptors even if Pmode is
not an integer mode.
I'm not real familiar with dwarf, so if one of other maintainers steps 
in and says this is OK, then ignore my comments/questions.


I may be missing something, but isn't it the transition to an FP 
relative address rather than a SP relative address that's the problem 
here?  Where does that happen?  Is it possible we've got the wrong 
DECL_RTL or somesuch?


Jeff

[Bug c/71152] NULL is not cast to (void *) as it ought to be if compiling code with -c

[rstrode at redhat dot com]

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

--- Comment #2 from Ray Strode  ---
this test case works as expected with gcc-5.3.1-6.fc23.x86_64

Avoid inlining into instrumetnation thunks

[Jan Hubicka]

Hi,
this patch fixes chkp ICE when we try to inline into an instrumentation thunk.
This is not really a thunk and ths can't be hanled as such.

Bootstrapped/regtested x86_64-linux

Honza

2016-05-16  Jan Hubicka  

* ipa-inline-analysis.c (compute_inline_parameters): Disable inlinig
into instrumentation thunks.
* cif-code.def (CIF_CHKP): New.

Index: ipa-inline-analysis.c
===
--- ipa-inline-analysis.c   (revision 236275)
+++ ipa-inline-analysis.c   (working copy)
@@ -2943,7 +2943,13 @@ compute_inline_parameters (struct cgraph
   info->self_size = info->size;
   info->self_time = info->time;
   /* We can not inline instrumetnation clones.  */
-  info->inlinable = !node->thunk.add_pointer_bounds_args;
+  if (node->thunk.add_pointer_bounds_args)
+   {
+  info->inlinable = false;
+  node->callees->inline_failed = CIF_CHKP;
+   }
+  else
+info->inlinable = true;
 }
   else
 {
Index: cif-code.def
===
--- cif-code.def(revision 236275)
+++ cif-code.def(working copy)
@@ -135,3 +135,7 @@ DEFCIFCODE(CILK_SPAWN, CIF_FINAL_ERROR,
 /* We proved that the call is unreachable.  */
 DEFCIFCODE(UNREACHABLE, CIF_FINAL_ERROR,
   N_("unreachable"))
+
+/* We can't inline because of instrumentation thunk.  */
+DEFCIFCODE(CHKP, CIF_FINAL_ERROR,
+  N_("caller is instrumetnation thunk"))

[Bug c++/71145] Alpha: Error: No lda !gpdisp!278 was found

[mcree at orcon dot net.nz]

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

--- Comment #3 from Michael Cree  ---
Created attachment 38500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38500=edit
compressed preprocessed source

Failing preprocessed source compressed with gzip; hopefully this goes through
okay.

[Bug c/71152] NULL is not cast to (void *) as it ought to be if compiling code with -c

[rstrode at redhat dot com]

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

--- Comment #1 from Ray Strode  ---
$ rpm -q gcc
gcc-6.0.0-0.20.fc25.x86_64

PING 2 [PATCH] integer overflow checking builtins in constant expressions

[Martin Sebor]

Ping 2 of the following patch:
  https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00013.html

On 05/09/2016 10:38 AM, Martin Sebor wrote:

Pinging the following patch:
   https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00013.html

On 05/01/2016 10:39 AM, Martin Sebor wrote:

c/68120 - can't easily deal with integer overflow at compile time,
is an enhancement request to make the integer overflow intrinsics
usable in constant expressions in C (in addition to letting them
be invoked with just two arguments).

The inability to use the built-ins in constant expressions also
limited to non-constexpr the contexts in which the patch for c++/
69517 - SEGV on a VLA with excess initializer elements, was able
to prevent the SEGV.  This limitation is noted in c++/70507 -
integer overflow builtins not constant expressions.

The attached patch implements the request in c/68120 for both
the C and C++ front-ends.  It stops short of providing the new
__builtin_add_wrapv function requested in c/68120.  It doesn't
seem necessary since the same functionality is available with
the patch via the existing built-ins.

With this enhancement in place it will be possible to add the
C++ VLA checking to constexpr functions and fully resolve c++/
69517 (which I plan to do next).

While testing the patch, I also noticed an minor inconsistency
in the text of the diagnostic GCC issues for invalid calls to
the built-ins with insufficient numbers of arguments:  for one
set of built-ins the error says: "not enough arguments," while
for another it says: "too few arguments."  I raised PR c/70883
- inconsistent error message for calls to __builtin_add_overflow
with too few arguments, for this and include a fix in this patch
as well.

Martin

PS The enhancement to call the type-generic built-ins with a null
pointer is not available in C++ 98 mode because GCC doesn't allow
null pointers in constant expressions.  Since C and later versions
of C++ do, it seems that it might be worthwhile to relax the rules
and accept them in C++ 98 as well so that the built-ins can be used
portably across all versions of C++.

[Bug c/71152] New: NULL is not cast to (void *) as it ought to be if compiling code with -c

[rstrode at redhat dot com]

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

Bug ID: 71152
   Summary: NULL is not cast to (void *) as it ought to be if
compiling code with -c
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rstrode at redhat dot com
  Target Milestone: ---

Created attachment 38499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38499=edit
small test case try compiling with -c and without

I was refactoring code in a project and moved some code off to a helper
function.
The helper function returns an integer error code and the main function returns
a pointer.

When I moved the error handling code over from the main function to the helper
function, I neglected to change the return code from NULL to -1.

gcc didn't warn about this.

So I wrote a quick test case (attached) and discovered something very strange.

gcc does warn if you compile and link the code in one step, i.e.:

$ gcc nulltest.c
nulltest.c: In function ‘NULL_as_int’:
nulltest.c:6:12: warning: return makes integer from pointer without a cast
[-Wint-conversion]
 return NULL;
^~~~
$ 


But if you pass -c to defer linking, the bug manifests:

$ gcc nulltest.c -c
$

Successful bootstrap and install of gcc (GCC) 6.1.0 on armv5tel-unknown-linux-gnueabi

[Aaro Koskinen]

Hi,

Here's a report of a successful build and install of GCC:

$ gcc-6.1.0/config.guess
armv5tel-unknown-linux-gnueabi

$ newcompiler/bin/gcc -v
Using built-in specs.
COLLECT_GCC=newcompiler/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/gcctest/newcompiler/libexec/gcc/arm-unknown-linux-gnueabi/6.1.0/lto-wrapper
Target: arm-unknown-linux-gnueabi
Configured with: ../gcc-6.1.0/configure --with-arch=armv4t --with-float=soft 
--disable-nls --prefix=/mnt/gcctest/newcompiler --enable-languages=c,c++ 
--host=arm-unknown-linux-gnueabi --build=arm-unknown-linux-gnueabi 
--target=arm-unknown-linux-gnueabi --with-system-zlib --with-sysroot=/
Thread model: posix
gcc version 6.1.0 (GCC) 

-- Build environment --

host: openrd-client
distro:   los.git rootfs=71e48 native=71e48
kernel:   Linux 4.6.0-rc5-mvebu-los_71e48
binutils: GNU binutils 2.26.20160125
make: GNU Make 4.1
libc: GNU C Library (GNU libc) stable release version 2.23
zlib: 1.2.8
mpfr: 3.1.3
gmp:  6

-- Time consumed --

configure:  real0m 29.17s
user0m 19.98s
sys 0m 1.70s

bootstrap:  real33h 31m 03s
user32h 13m 26s
sys 32m 6.62s

install:real3m 47.36s
user2m 30.66s
sys 0m 20.19s

-- Hardware details ---

MemTotal: 513148 kB

processor   : 0
model name  : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS: 1196.85
Features: swp half thumb fastmult edsp 
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part: 0x131
CPU revision: 1

Hardware: Marvell Kirkwood (Flattened Device Tree)
Revision: 
Serial  : 

A.

Re: [PATCH 2/3] Const parameters are always unmodified

[Jeff Law]

On 05/12/2016 10:08 AM, Martin Jambor wrote:

Hi,

this patch simply makes parm_preserved_before_stmt_p consider all
const PARM_DECLs constant and does not invoke AA walking on them
(really the DECLs themselves, not the memory they might point to).

Bootstrapped and lto-bootstrapped and tested on x86_64-linux.  OK for
trunk?

Thanks,

Martin


2016-05-10  Martin Jambor  

* ipa-prop.c (parm_preserved_before_stmt_p): Return true for loads
from TREE_READONLY parameters.

Seems like a good idea irrespective of the other patches in this series.

OK for the trunk.  Is this related to 69708, if so you might want to add 
that marker to the ChangeLog entry.



jeff

Re: [PATCH vs] Take known zero bits into account when checking extraction.

[Jeff Law]

On 05/11/2016 02:52 AM, Dominik Vogt wrote:

On Wed, May 11, 2016 at 10:40:11AM +0200, Bernd Schmidt wrote:

On 05/11/2016 09:42 AM, Dominik Vogt wrote:

On Tue, May 10, 2016 at 05:05:06PM +0200, Bernd Schmidt wrote:

Earlier in the discussion you mentioned the intention to remove
these costs. Nothing else in the function does cost calculations -
maybe you can try placing a gcc_unreachable into the case where the
costs would prevent the transformation to see if it ever triggers.


You mean to try it out locally or as part of the patch?


I meant try it out locally. I'm almost certain the patch shouldn't
be trying to use costs here.


That's what I mentioned somewhere during the discussion.  The s390
backend just uses COSTS_N_INSNS(1) for AND as well as ZERO_EXTEND,
so this won't ever trigger.  I just left the rtx_cost call in the
patch for further discussion as Jeff said he liked the approach.
We don't need it to achieve the behaviour we want for s390.
I liked it, just based on the general theory that we should be comparing 
costs of a transform to the original much more often than we currently do.


If Bernd prefers it gone and you don't need it to achieve your goals, 
then I won't object to the costing stuff going away.


jeff

Re: [PATCH] Take known zero bits into account when checking extraction.

[Jeff Law]

On 04/29/2016 03:35 AM, Dominik Vogt wrote:

On Wed, Apr 27, 2016 at 10:24:21PM -0600, Jeff Law wrote:

Instead you want insn 12 to use a zero-extend to extend (reg:SI 64)
into (reg:DI 2)?


Yes, because we get the zero extend for free in this case (through
the constant in the AND or because the input value is a function
argument that is already zero extended).


Can't you achieve this in this clause:

 /* If the constant is one less than a power of two, this might be
 representable by an extraction even if no shift is present.
 If it doesn't end up being a ZERO_EXTEND, we will ignore it unless
 we are in a COMPARE.  */

You extract the constant via UINTVAL (XEXP (x, 1)), then munge it
based on nonzero_bits and pass the result to exact_log2?


That's what we tried first, but it resulted in worse code in many
places (saved about 250 instructions in the SPEC2006 testsuite but
added about 42000 elsewhere).  It was so bad that I didn't even
bother to check what's going on.  Probably this was triggered all
over the place by small constants like 1, 3, 7 and the like where
s390 has no cheap way for zero extension.  So I limited this to
constants that are actually mode masks, implicitly assuming that
there are zero extend instructions only for known modes (which is
true for s390 but may not for some other targets).  Being
conservative here shouldn't hurt; but I wonder whether there are
targets where this condition still allows too much.
You're probably right.  FWIW, I do believe a variety of targets can do 
these kind of zero extensions.  The PA for example has extru which can 
extract a field from a general register zero extend it, then place the 
result, right justified into another register.



We don't get them "for free", except as a component of a larger sequence 
of statements for bitfield extraction/manipulation.


I believe PPC has similar capabilities.
jeff

[PATCH, i386]: No singing in the compiler!

[Uros Bizjak]

2016-05-16  Uros Bizjak  

* config/i386/xopintrin.h: Correct "unsinged" typo in the comments.

Committed as obvious.

Uros.
Index: config/i386/xopintrin.h
===
--- config/i386/xopintrin.h (revision 236296)
+++ config/i386/xopintrin.h (working copy)
@@ -330,7 +330,7 @@
 }
 
 /* Compare and Predicate Generation
-   pcom (integer, unsinged bytes) */
+   pcom (integer, unsigned bytes) */
 
 extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
 _mm_comlt_epu8(__m128i __A, __m128i __B)
@@ -380,7 +380,7 @@
   return (__m128i) __builtin_ia32_vpcomtrueub ((__v16qi)__A, (__v16qi)__B);
 }
 
-/*pcom (integer, unsinged words) */
+/*pcom (integer, unsigned words) */
 
 extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
 _mm_comlt_epu16(__m128i __A, __m128i __B)
@@ -430,7 +430,7 @@
   return (__m128i) __builtin_ia32_vpcomtrueuw ((__v8hi)__A, (__v8hi)__B);
 }
 
-/*pcom (integer, unsinged double words) */
+/*pcom (integer, unsigned double words) */
 
 extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
 _mm_comlt_epu32(__m128i __A, __m128i __B)
@@ -480,7 +480,7 @@
   return (__m128i) __builtin_ia32_vpcomtrueud ((__v4si)__A, (__v4si)__B);
 }
 
-/*pcom (integer, unsinged quad words) */
+/*pcom (integer, unsigned quad words) */
 
 extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
 _mm_comlt_epu64(__m128i __A, __m128i __B)

Re: [PATCH] Respect --param ipa-max-agg-items=0

[Jeff Law]

On 05/11/2016 09:46 AM, Martin Jambor wrote:

Hi,

when analyzing PR 70646, I found out that --param ipa-max-agg-items=0
does not prevent creation of aggregate jump functions because it is
checked only after the first such jump function is created.  The
following patch fixes that by checking the parameter before starting
the whole analysis.

Bootstrapped and lto-bootstrapped on x86_64-linux.  OK for trunk?  OK
for all active release branches?

Yes and yes.



jeff

Re: [PATCH] [rtlfe] Barebones implementation of "__RTL"; next steps?

[Jeff Law]

On 05/12/2016 08:29 AM, David Malcolm wrote:


One wart I ran into is that system.h has this:

/* Front ends should never have to include middle-end headers.  Enforce
   this by poisoning the header double-include protection defines.  */
#ifdef IN_GCC_FRONTEND
#pragma GCC poison GCC_RTL_H GCC_EXCEPT_H GCC_EXPR_H
#endif

i.e. the idea of running RTL code from inside the C frontend seems to
be banned.
Yea, we really don't want the front-ends to know about the guts of RTL. 
This work would seem to violate that guiding principle.


I'd be more in favor of a true RTL front-end rather than bolting it onto 
the side of the C front-end.


jeff

Re: VRP: range info of new variables

[Jeff Law]

On 05/13/2016 12:50 PM, Marc Glisse wrote:

Hello,

when VRP does some transforms, it may create new SSA_NAMEs, but doesn't
give them range information. This can prevent cascading transformations
in a single VRP pass. With this patch, I assign range information to the
variable introduced by one transformation, and in another
transformation, I get range information through get_range_info instead
of get_value_range in order to have access to the new information.

Some notes:
- get_range_info only applies to integers, not pointers. I hope we are
not losing much by restricting this transformation. I could also call
get_value_range and only fall back to get_range_info if that failed (and
we don't have a pointer), but it doesn't seem worth it.

It probably isn't worth it.


- Now that I think of it, maybe I should check that the variable is not
a pointer before calling set_range_info? Having range [0, 1] makes it
unlikely, but who knows...

Maybe using an assert would be better.



Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c  (revision 236194)
+++ gcc/tree-vrp.c  (working copy)
@@ -8933,20 +8933,24 @@ simplify_truth_ops_using_ranges (gimple_
 gimple_assign_set_rhs_with_ops (gsi,
need_conversion
? NOP_EXPR : TREE_CODE (op0), op0);
   /* For A != B we substitute A ^ B.  Either with conversion.  */
   else if (need_conversion)
 {
   tree tem = make_ssa_name (TREE_TYPE (op0));
   gassign *newop
= gimple_build_assign (tem, BIT_XOR_EXPR, op0, op1);
   gsi_insert_before (gsi, newop, GSI_SAME_STMT);
+  if (TYPE_PRECISION (TREE_TYPE (tem)) > 1)
+   set_range_info (tem, VR_RANGE,
+   wi::zero (TYPE_PRECISION (TREE_TYPE (tem))),
+   wi::one (TYPE_PRECISION (TREE_TYPE (tem;
Is there actually a case where TYPE_PRECISION (TREE_TYPE (tem)) > 1 is 
ever false?  Would an assert make more sense here?





 /* Simplify an integral conversion from an SSA name in STMT.  */

 static bool
 simplify_conversion_using_ranges (gimple *stmt)
Your ChangeLog mentions simplify_switch_using_ranges, not 
simplify_conversion_using_ranges.


This is OK for the trunk -- your call on asserting the variable is not a 
pointer before calling set_range_info.  Similarly on the check that the 
TYPE_PRECISION (TREE_TYPE (tem)) > 1.


Jeff

[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs

[yselkowi at redhat dot com]

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

--- Comment #3 from Yaakov Selkowitz  ---
It seems that #define _GLIBCXX_USE_WEAK_REF 1 would fix this; the question is
where exactly it should go (config/os/generic/os_defines.h ?) and under what
conditions.

Re: Fix for PR68159 in Libiberty Demangler (6)

[Jeff Law]

On 05/16/2016 12:19 PM, Jakub Jelinek wrote:

On Mon, May 16, 2016 at 12:12:38PM -0600, Jeff Law wrote:

On 05/06/2016 09:19 AM, Jakub Jelinek wrote:

On Fri, May 06, 2016 at 11:11:29PM +0800, Marcel Böhme wrote:

+  dpi.copy_templates
+= (struct d_print_template *) malloc (((size_t) dpi.num_copy_templates)
+ * sizeof (*dpi.copy_templates));
+  if (! dpi.copy_templates)
+{
+  d_print_error ();
+  return 0;
+}


Another thing to consider is if the common values of dpi.num_*
and similarly in the other block are small enough, it might be desirable
to just use an automatic fixed size array (or even alloca) and only
fall back to malloc if it is too large.

Please, no, don't fall back to alloca like this.  That coding idiom has been
the source of numerous security exploits in glibc.  Experience shows us that
we are not capable of doing that correctly on a consistent basis.


Falling back to fixed size buffer is something we use heavily in gcc, and
are able to get it right, there is nothing hard in it.
Conceptually I agree, it ought not be that hard, in practice, it's been 
an absolute disaster in glibc.


I've often wondered if the right model is to to use escape analysis 
along with the size of the object, loop analysis, etc and let the 
compiler figure this stuff out rather than leaving it to humans.





For the cases where we can't use malloc at all and we'd need too much memory
that it won't fit into the static buffer, I think all we can do is fall back
into increasing the time complexity in the demangler by processing the
string multiple times.

Probably true.

jeff

[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs

[yselkowi at redhat dot com]

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

--- Comment #2 from Yaakov Selkowitz  ---
(In reply to Jonathan Wakely from comment #1)
> I think we just want to disable TM library support for such targets.

Okay, h8300-elf and xstormy16-elf are both similarly affected.  msp430-elf
probably will be as well once configure works again (bug 71133).

Re: Fix for PR68159 in Libiberty Demangler (6)

[Jakub Jelinek]

On Mon, May 16, 2016 at 12:12:38PM -0600, Jeff Law wrote:
> On 05/06/2016 09:19 AM, Jakub Jelinek wrote:
> >On Fri, May 06, 2016 at 11:11:29PM +0800, Marcel Böhme wrote:
> >>+  dpi.copy_templates
> >>+= (struct d_print_template *) malloc (((size_t) dpi.num_copy_templates)
> >>+ * sizeof (*dpi.copy_templates));
> >>+  if (! dpi.copy_templates)
> >>+{
> >>+  d_print_error ();
> >>+  return 0;
> >>+}
> >
> >Another thing to consider is if the common values of dpi.num_*
> >and similarly in the other block are small enough, it might be desirable
> >to just use an automatic fixed size array (or even alloca) and only
> >fall back to malloc if it is too large.
> Please, no, don't fall back to alloca like this.  That coding idiom has been
> the source of numerous security exploits in glibc.  Experience shows us that
> we are not capable of doing that correctly on a consistent basis.

Falling back to fixed size buffer is something we use heavily in gcc, and
are able to get it right, there is nothing hard in it.

For the cases where we can't use malloc at all and we'd need too much memory
that it won't fit into the static buffer, I think all we can do is fall back
into increasing the time complexity in the demangler by processing the
string multiple times.

Jakub

Re: Fix for PR68159 in Libiberty Demangler (6)

[Jeff Law]

On 05/06/2016 09:19 AM, Jakub Jelinek wrote:

On Fri, May 06, 2016 at 11:11:29PM +0800, Marcel Böhme wrote:

+  dpi.copy_templates
+= (struct d_print_template *) malloc (((size_t) dpi.num_copy_templates)
+ * sizeof (*dpi.copy_templates));
+  if (! dpi.copy_templates)
+{
+  d_print_error ();
+  return 0;
+}


Another thing to consider is if the common values of dpi.num_*
and similarly in the other block are small enough, it might be desirable
to just use an automatic fixed size array (or even alloca) and only
fall back to malloc if it is too large.
Please, no, don't fall back to alloca like this.  That coding idiom has 
been the source of numerous security exploits in glibc.  Experience 
shows us that we are not capable of doing that correctly on a consistent 
basis.


Jeff

Re: [PATCH] Add PowerPC ISA 3.0 word splat and byte immediate splat support

[Michael Meissner]

On Fri, May 13, 2016 at 08:23:16PM -0500, Segher Boessenkool wrote:
> On Fri, May 13, 2016 at 07:25:43PM -0400, Michael Meissner wrote:
> > This patch adds support for the 32-bit word splat instructions, the byte
> > immediate splat instructions, and the vector sign extend instructions to GCC
> > 7.0.
> > 
> > In addition to the various splat instructions, since I was modifying the 
> > vector
> > moves, I took the opportunity to reorganize the vector move instructions 
> > with
> > several changes I've wanted to do:
> 
> It is much easier to review, and for regression searches later, if one
> patch does one thing.  No need to change this patch, but please keep
> it in mind for later patches.

Yes and no.  Sometimes, you need to make larger changes.

> > Are these patches ok to apply to the GCC 7.0 trunk?
> 
> Changelog is missing.

Sorry about that.  I was focused on including the patches this time, that I
forgot to include the ChangeLog entries.

Unfortunately, I'm finding some regressions that seem to show up with more
recent trunk changes, particularly with reload than LRA.  I'm going to have to
spend some time debugging why reload is failing on big endian systems, and
resubmit the patches when it is debugged.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

[hsa] Increase hsa symbol alignment to a natural one

[Martin Jambor]

Hi,

in the last round fo alignment fixes, we have forgot to make sure that
all symbols are at least naturally aligned, which is a hard HSAIL
requirement.  This caused problems when emitting a symbol for a
private complex number, as the natural alignment as defined by HSAIL
is twice the one of the component, which was selected by gcc.

The following patch addresses this in two ways.  First, it simply
increases the alignment of symbols that are only accessible from
within HSAIL.  If however a symbol that is shared in between host and
an HSA accelerator is under-aligned (in my experience it only happens
if the user uses the aligned attribute), we have no option but to
abort HSAIL generation because even if we did generate it, it would
not finalize.

Bootstrapped and tested on x86_64-linux with hsa enabled.  I will
commit it to trunk and the gcc-6 branch shortly.

Martin


2016-05-16  Martin Jambor  

* hsa-gen.c (fillup_for_decl): Increase alignment to natural one.
(get_symbol_for_decl): Sorry if a global symbol in under-aligned.

libgomp/
* testsuite/libgomp.hsa.c/complex-align-2.c: New test.
---
 gcc/hsa-gen.c | 19 
 libgomp/testsuite/libgomp.hsa.c/complex-align-2.c | 27 +++
 2 files changed, 42 insertions(+), 4 deletions(-)
 create mode 100644 libgomp/testsuite/libgomp.hsa.c/complex-align-2.c

diff --git a/gcc/hsa-gen.c b/gcc/hsa-gen.c
index 5baf607..697d599 100644
--- a/gcc/hsa-gen.c
+++ b/gcc/hsa-gen.c
@@ -203,9 +203,13 @@ hsa_symbol::fillup_for_decl (tree decl)
 {
   m_decl = decl;
   m_type = hsa_type_for_tree_type (TREE_TYPE (decl), _dim, false);
-
   if (hsa_seen_error ())
-m_seen_error = true;
+{
+  m_seen_error = true;
+  return;
+}
+
+  m_align = MAX (m_align, hsa_natural_alignment (m_type));
 }
 
 /* Constructor of class representing global HSA function/kernel information and
@@ -929,6 +933,14 @@ get_symbol_for_decl (tree decl)
BRIG_LINKAGE_PROGRAM, true,
BRIG_ALLOCATION_PROGRAM, align);
  hsa_cfun->m_global_symbols.safe_push (sym);
+ sym->fillup_for_decl (decl);
+ if (sym->m_align > align)
+   {
+ sym->m_seen_error = true;
+ HSA_SORRY_ATV (EXPR_LOCATION (decl),
+"HSA specification requires that %E is at least "
+"naturally aligned", decl);
+   }
}
   else
{
@@ -944,12 +956,11 @@ get_symbol_for_decl (tree decl)
  sym = new hsa_symbol (BRIG_TYPE_NONE, BRIG_SEGMENT_PRIVATE,
BRIG_LINKAGE_FUNCTION);
  sym->m_align = align;
+ sym->fillup_for_decl (decl);
  hsa_cfun->m_private_variables.safe_push (sym);
}
 
-  sym->fillup_for_decl (decl);
   sym->m_name = hsa_get_declaration_name (decl);
-
   *slot = sym;
   return sym;
 }
diff --git a/libgomp/testsuite/libgomp.hsa.c/complex-align-2.c 
b/libgomp/testsuite/libgomp.hsa.c/complex-align-2.c
new file mode 100644
index 000..b2d7acf
--- /dev/null
+++ b/libgomp/testsuite/libgomp.hsa.c/complex-align-2.c
@@ -0,0 +1,27 @@
+#pragma omp declare target
+_Complex int *g;
+#pragma omp end declare target
+
+
+
+_Complex float f(void);
+
+int
+main ()
+{
+  _Complex int y;
+#pragma omp target map(from:y)
+  {
+_Complex int x;
+g = 
+__imag__ x = 1;
+__real__ x = 2;
+y = x;
+  }
+
+  if ((__imag__ y != 1)
+  || (__real__ y != 2))
+__builtin_abort ();
+  return 0;
+}
+
-- 
2.8.2

[Bug bootstrap/70835] New: internal compiler error on libiberty/floatformat.c when bootstrapping 5.3.0 with 5.3.0

[LpSolit at netscape dot net]

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

Bug ID: 70835
   Summary: internal compiler error on libiberty/floatformat.c
when bootstrapping 5.3.0 with 5.3.0
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nunya223bidness at streetwisemail dot com
  Target Milestone: ---

../gcc-5.3.0/configure --prefix=/usr/local
--with-native-system-header-files=/opt/include:/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/include
--enable-bootstrap --enable-lto --with-{gmp,mpc,mpfr,isl}=/usr/local
--with-gnu-ld --enable-twoprocess --enable-gather-detailed-mem-stats
--enable-multilib --enable-multiarch --enable-decimal-float=yes
--enable-fixed-point --enable-plugin --disable-dependency-tracking
--disable-nls --disable-canonical-system-headers --with-glibc-version=2.20
--without-cuda-driver --enable-languages=c,c++
--with-build-time-tools=/usr/local --with-build-libsubdir=lib CFLAGS="-v
-save-temps" ; make

[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[3]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
rm -f stage_current
make[3]: Leaving directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Leaving directory '/volume1/local/src/gcc-5.3.0-build'
make[2]: Entering directory '/volume1/local/src/gcc-5.3.0-build'
make[3]: Entering directory '/volume1/local/src/gcc-5.3.0-build/libiberty'
if [ x"-fpic" != x ]; then \
  gcc -c -DHAVE_CONFIG_H -g  -I. -I../../gcc-5.3.0/libiberty/../include  -W
-Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fpic
../../gcc-5.3.0/libiberty/floatformat.c -o pic/floatformat.o; \
else true; fi
GNU MP: Cannot allocate memory (size=4611686018427387859)
../../gcc-5.3.0/libiberty/floatformat.c: In function 'floatformat_to_double':
../../gcc-5.3.0/libiberty/floatformat.c:529:2: internal compiler error: Aborted
  dto = ldexp (1.0, exponent);
  ^
0x9bed4f crash_signal
../../gcc-5.3.0/gcc/toplev.c:383
0x93c390 real_from_mpfr(real_value*, __mpfr_struct const*, tree_node*,
mpfr_rnd_t)
../../gcc-5.3.0/gcc/realmpfr.c:92
0x939b49 real_from_string(real_value*, char const*)
../../gcc-5.3.0/gcc/real.c:2073
0x93a3bc real_from_string3(real_value*, char const*, machine_mode)
../../gcc-5.3.0/gcc/real.c:2123
0x6576a3 interpret_float
../../gcc-5.3.0/gcc/c-family/c-lex.c:897
0x65834c c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../gcc-5.3.0/gcc/c-family/c-lex.c:442
0x602fef c_lex_one_token
../../gcc-5.3.0/gcc/c/c-parser.c:258
0x613d1a c_parser_peek_token
../../gcc-5.3.0/gcc/c/c-parser.c:440
0x613d1a c_parser_next_token_is
../../gcc-5.3.0/gcc/c/c-parser.c:452
0x613d1a c_parser_postfix_expression_after_primary
../../gcc-5.3.0/gcc/c/c-parser.c:7865
0x60e067 c_parser_postfix_expression
../../gcc-5.3.0/gcc/c/c-parser.c:7715
0x61031a c_parser_unary_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6602
0x610e8f c_parser_cast_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6440
0x611072 c_parser_binary_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6255
0x611ba5 c_parser_conditional_expression
../../gcc-5.3.0/gcc/c/c-parser.c:6031
0x611ff0 c_parser_expr_no_commas
../../gcc-5.3.0/gcc/c/c-parser.c:5949
0x61206a c_parser_expr_no_commas
../../gcc-5.3.0/gcc/c/c-parser.c:5991
0x6124e2 c_parser_expression
../../gcc-5.3.0/gcc/c/c-parser.c:8022
0x612c99 c_parser_expression_conv
../../gcc-5.3.0/gcc/c/c-parser.c:8055
0x60c096 c_parser_statement_after_labels
../../gcc-5.3.0/gcc/c/c-parser.c:5115

sh-4.3# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/volume1/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.3.0/configure
--with-buildtime-tools=/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/bin
--with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local
--with-isl=/usr/local --disable-multilib
--with-sysroot=/volume1/mmt/x-tools/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/sysroot
--enable-bootstrap --disable-lto
Thread model: posix
gcc version 5.3.0 (GCC) 

sh-4.3# uname -s -r -v -m -p -i -o
Linux 3.10.77 #7321 SMP Thu Apr 21 14:35:22 CST 2016 x86_64 unknown unknown
GNU/Linux

[Bug ipa/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka  ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71146
> 
> --- Comment #5 from Marek Polacek  ---
> And of course I found it (I think) just after posting the previous commit:

Ah, thanks. It looks OK to me.  I was wondering if it is cleaner to split the
BB just to make the outer loop continue where it started or do something
smarter.
I wonder how we managed to redirect call within thunk to unreachable?

Honza

[committed] Fix some typos in gimple.c

[Marek Polacek]

While debugging PR71146 I notices these.  These typos are perfidious because
they make grepping for '__builtin_unreachable' harder.

Applying to trunk as obvious.

2016-05-16  Marek Polacek  

* gimple.c (maybe_remove_unused_call_args): Fix typos in the
commentary.

diff --git gcc/gimple.c gcc/gimple.c
index 1a22e82..d822fab 100644
--- gcc/gimple.c
+++ gcc/gimple.c
@@ -3002,7 +3002,7 @@ gimple_seq_discard (gimple_seq seq)
 
 /* See if STMT now calls function that takes no parameters and if so, drop
call arguments.  This is used when devirtualization machinery redirects
-   to __builtiln_unreacahble or __cxa_pure_virutal.  */
+   to __builtin_unreachable or __cxa_pure_virtual.  */
 
 void
 maybe_remove_unused_call_args (struct function *fn, gimple *stmt)

Marek

[PATCH 4/4] BRIG (HSAIL) frontend: smoke test suite

[Pekka Jääskeläinen]

A smoke test suite. The patch has been tested more thoroughly with the
proprietary HSA PRM conformance suite.

Requires the HSAILasm tool to first compile the .hsail to .brig.

--
Pekka Jääskeläinen
Parmance
A smoke test suite. The patch has been tested more thoroughly with the
proprietary HSA PRM conformance suite.

Requires the HSAILasm tool to first compile the .hsail to .brig.
diff --git a/gcc/testsuite/brig.dg/README b/gcc/testsuite/brig.dg/README
new file mode 100644
index 000..cc313c4
--- /dev/null
+++ b/gcc/testsuite/brig.dg/README
@@ -0,0 +1,10 @@
+BRIG (HSAIL) frontend test cases
+
+
+The suite consists of "smoke tests" that test several features of
+the compilation and regression tests, but is not an exhaustive test
+suite for all HSAIL instructions. The HSA PRM conformance suite
+is supposed to be used for that.
+
+HSAILasm is required for converting the text HSAIL files to BRIGs
+which the compiler consumes.
diff --git a/gcc/testsuite/brig.dg/dg.exp b/gcc/testsuite/brig.dg/dg.exp
new file mode 100644
index 000..fd75cae
--- /dev/null
+++ b/gcc/testsuite/brig.dg/dg.exp
@@ -0,0 +1,27 @@
+#   Copyright (C) 2009-2014 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+# GCC testsuite that uses the `dg.exp' driver.
+
+load_lib brig-dg.exp
+
+# Initialize `dg'.
+dg-init
+
+dg-runtest [find $srcdir/$subdir *.hsail] "" ""
+
+# All done.
+dg-finish
diff --git a/gcc/testsuite/brig.dg/test/gimple/alloca.hsail b/gcc/testsuite/brig.dg/test/gimple/alloca.hsail
new file mode 100644
index 000..73c2f93
--- /dev/null
+++ b/gcc/testsuite/brig.dg/test/gimple/alloca.hsail
@@ -0,0 +1,37 @@
+module :1:0:$full:$large:$default;
+
+/* Tests for alloca. */
+
+/* { dg-do compile } */
+/* { dg-options "-fdump-tree-gimple" } */
+
+prog function (arg_u32 %return_value)() {
+ alloca_align(1)_u32 $s2, 256;
+ st_arg_u32 $s2, [%return_value];
+ ret;
+};
+
+prog kernel (kernarg_u64 %input_ptr, kernarg_u64 %output_ptr)
+{
+ld_kernarg_u64 $d0, [%input_ptr];
+ld_global_u32 $s0, [$d0];
+
+	alloca_align(256)_u32 $s1, 16;
+	{
+		arg_u32 %return_value;
+		call (%return_value)();
+		ld_arg_u32 $s1, [%return_value];
+	}
+ld_kernarg_u64 $d1, [%output_ptr];
+st_global_u32 $s1, [$d0];
+};
+
+/* { dg-final { scan-tree-dump "s2 = __phsa_builtin_alloca \\\(256, 1, __context\\\);" "gimple" } } */
+
+/* { dg-final { scan-tree-dump "s1 = __phsa_builtin_alloca \\\(16, 256, __context\\\);" "gimple" } } */
+
+
+/* Both functions should have an alloca frame push and pop. */
+/* { dg-final { scan-tree-dump-times "__phsa_builtin_alloca_push_frame \\\(__context\\\);" 2 "gimple" } } */
+
+/* { dg-final { scan-tree-dump-times "__phsa_builtin_alloca_pop_frame \\\(__context\\\);" 2 "gimple" } } */
diff --git a/gcc/testsuite/brig.dg/test/gimple/atomics.hsail b/gcc/testsuite/brig.dg/test/gimple/atomics.hsail
new file mode 100644
index 000..a0b2f85
--- /dev/null
+++ b/gcc/testsuite/brig.dg/test/gimple/atomics.hsail
@@ -0,0 +1,33 @@
+module :1:0:$full:$large:$default;
+
+/* Test for atomic instructions. */
+
+/* { dg-do compile } */
+/* { dg-options "-fdump-tree-original" } */
+
+prog kernel (kernarg_u64 %input_ptr, kernarg_u64 %output_ptr)
+{
+ld_kernarg_u64 $d0, [%input_ptr];
+
+	atomic_ld_global_rlx_system_b32 $s0, [$d0];
+	atomic_add_global_rlx_system_u32 $s1, [$d0 + 4], $s0;
+
+ld_kernarg_u64 $d0, [%output_ptr];
+atomicnoret_st_global_rlx_system_b32 [$d0], $s2;
+
+	atomicnoret_min_global_rlx_system_u32 [$d0 + 4], $s1;
+
+ret;
+};
+
+/* The atomic loads are implemented by casting to an atomic pointer. */
+/* { dg-final { scan-tree-dump "s0 = VIEW_CONVERT_EXPR\\\(\\\*\\\(atomic unsigned int \\\*\\\)" "original"} } */
+
+/* The atomic add should call a gcc builtin. */
+/* { dg-final { scan-tree-dump "= __sync_fetch_and_add_4 \\\(" "original"} } */
+
+/* The atomic stores are implemented by casting to an atomic pointer. */
+/* { dg-final { scan-tree-dump "\\\*\\\(atomic unsigned int \\\*\\\) VIEW_CONVERT_EXPR\\\(VIEW_CONVERT_EXPR\\\(d0\\\)\\\) = s2;" "original"} } */
+
+/* The atomic min is implemented by a custom builtin. */
+/* { dg-final { scan-tree-dump "builtin_out.\[0-9\]+ = __phsa_builtin_atomic_min_u32 \\\(" "original"} } */
diff --git a/gcc/testsuite/brig.dg/test/gimple/branches.hsail 

[PATCH 2/4] BRIG (HSAIL) frontend: The FE itself.

[Pekka Jääskeläinen]

The BRIG frontend itself.

--
Pekka Jääskeläinen
Parmance


002-brig-fe-new-files.patch.gz
Description: application/gzip

[PATCH 1/4] BRIG (HSAIL) frontend: configuration file changes and misc

[Pekka Jääskeläinen]

The configuration file changes and misc. updates required
by the BRIG frontend.

Also, added include/hsa-interface.h which is hsa.h taken from libgomp
and will be shared by it (agreed with Martin Liška / SUSE).

--
Pekka Jääskeläinen
Parmance
The configuration file changes and misc. updates required
by the BRIG frontend.

Also, added include/hsa-interface.h which is hsa.h taken from libgomp
and will be shared by it (agreed with Martin Liška / SUSE).

diff --git a/Makefile.def b/Makefile.def
index ec5f31e..2c1668b 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -157,6 +157,7 @@ target_modules = { module= libquadmath; };
 target_modules = { module= libgfortran; };
 target_modules = { module= libobjc; };
 target_modules = { module= libgo; };
+target_modules = { module= libhsail-rt; };
 target_modules = { module= libtermcap; no_check=true;
missing=mostlyclean;
missing=clean;
@@ -619,6 +620,8 @@ languages = { language=objc;	gcc-check-target=check-objc;
 languages = { language=obj-c++;	gcc-check-target=check-obj-c++; };
 languages = { language=go;	gcc-check-target=check-go;
 lib-check-target=check-target-libgo; };
+languages = { language=brig;	gcc-check-target=check-brig;
+lib-check-target=check-target-libhsail-rt; };
 
 // Toplevel bootstrap
 bootstrap_stage = { id=1 ; };
diff --git a/Makefile.in b/Makefile.in
index f778d03..fcac74c 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -966,6 +966,7 @@ configure-target:  \
 maybe-configure-target-libgfortran \
 maybe-configure-target-libobjc \
 maybe-configure-target-libgo \
+maybe-configure-target-libhsail-rt \
 maybe-configure-target-libtermcap \
 maybe-configure-target-winsup \
 maybe-configure-target-libgloss \
@@ -1133,6 +1134,7 @@ all-target: maybe-all-target-libquadmath
 all-target: maybe-all-target-libgfortran
 all-target: maybe-all-target-libobjc
 all-target: maybe-all-target-libgo
+all-target: maybe-all-target-libhsail-rt
 all-target: maybe-all-target-libtermcap
 all-target: maybe-all-target-winsup
 all-target: maybe-all-target-libgloss
@@ -1227,6 +1229,7 @@ info-target: maybe-info-target-libquadmath
 info-target: maybe-info-target-libgfortran
 info-target: maybe-info-target-libobjc
 info-target: maybe-info-target-libgo
+info-target: maybe-info-target-libhsail-rt
 info-target: maybe-info-target-libtermcap
 info-target: maybe-info-target-winsup
 info-target: maybe-info-target-libgloss
@@ -1314,6 +1317,7 @@ dvi-target: maybe-dvi-target-libquadmath
 dvi-target: maybe-dvi-target-libgfortran
 dvi-target: maybe-dvi-target-libobjc
 dvi-target: maybe-dvi-target-libgo
+dvi-target: maybe-dvi-target-libhsail-rt
 dvi-target: maybe-dvi-target-libtermcap
 dvi-target: maybe-dvi-target-winsup
 dvi-target: maybe-dvi-target-libgloss
@@ -1401,6 +1405,7 @@ pdf-target: maybe-pdf-target-libquadmath
 pdf-target: maybe-pdf-target-libgfortran
 pdf-target: maybe-pdf-target-libobjc
 pdf-target: maybe-pdf-target-libgo
+pdf-target: maybe-pdf-target-libhsail-rt
 pdf-target: maybe-pdf-target-libtermcap
 pdf-target: maybe-pdf-target-winsup
 pdf-target: maybe-pdf-target-libgloss
@@ -1488,6 +1493,7 @@ html-target: maybe-html-target-libquadmath
 html-target: maybe-html-target-libgfortran
 html-target: maybe-html-target-libobjc
 html-target: maybe-html-target-libgo
+html-target: maybe-html-target-libhsail-rt
 html-target: maybe-html-target-libtermcap
 html-target: maybe-html-target-winsup
 html-target: maybe-html-target-libgloss
@@ -1575,6 +1581,7 @@ TAGS-target: maybe-TAGS-target-libquadmath
 TAGS-target: maybe-TAGS-target-libgfortran
 TAGS-target: maybe-TAGS-target-libobjc
 TAGS-target: maybe-TAGS-target-libgo
+TAGS-target: maybe-TAGS-target-libhsail-rt
 TAGS-target: maybe-TAGS-target-libtermcap
 TAGS-target: maybe-TAGS-target-winsup
 TAGS-target: maybe-TAGS-target-libgloss
@@ -1662,6 +1669,7 @@ install-info-target: maybe-install-info-target-libquadmath
 install-info-target: maybe-install-info-target-libgfortran
 install-info-target: maybe-install-info-target-libobjc
 install-info-target: maybe-install-info-target-libgo
+install-info-target: maybe-install-info-target-libhsail-rt
 install-info-target: maybe-install-info-target-libtermcap
 install-info-target: maybe-install-info-target-winsup
 install-info-target: maybe-install-info-target-libgloss
@@ -1749,6 +1757,7 @@ install-pdf-target: maybe-install-pdf-target-libquadmath
 install-pdf-target: maybe-install-pdf-target-libgfortran
 install-pdf-target: maybe-install-pdf-target-libobjc
 install-pdf-target: maybe-install-pdf-target-libgo
+install-pdf-target: maybe-install-pdf-target-libhsail-rt
 install-pdf-target: maybe-install-pdf-target-libtermcap
 install-pdf-target: maybe-install-pdf-target-winsup
 install-pdf-target: maybe-install-pdf-target-libgloss
@@ -1836,6 +1845,7 @@ install-html-target: maybe-install-html-target-libquadmath
 install-html-target: maybe-install-html-target-libgfortran
 install-html-target: maybe-install-html-target-libobjc
 

[PATCH 0/4] BRIG (HSAIL) frontend

[Pekka Jääskeläinen]

This patch set adds a BRIG (HSAIL) frontend. It can be used as a core
for an HSAIL finalizer implementation for processors with gcc backends.

It is a bit unusual frontend as the consumed format is a binary
representation.  The textual HSAIL can be compiled to it with a 
separate assembler.

The frontend has been mostly tested with the HSA PRM conformance suite which
it now passes. The accompanied GENERIC-scanning test suite is supposed to be
only a smoke test. 

libhsail-rt implements HSAIL specific builtins and includes a simple runtime
that implements SPMD execution via either Pth-based fibers or loops to 
execute multiple work-item work groups without SPMD/SIMD-default hardware.

I've split it to 4 patches:

001 - the configuration file changes and misc.
002 - the frontend itself
003 - libhsail-rt
004 - the smoke test suite

The diffstat is as follows:

 Makefile.def  | 3 +
 Makefile.in   |   489 +
 configure | 1 +
 configure.ac  | 1 +
 gcc/brig/Make-lang.in |   246 +
 gcc/brig/brig-c.h |68 +
 gcc/brig/brig-lang.c  |   461 +
 gcc/brig/brigfrontend/brig-arg-block-handler.cc   |67 +
 gcc/brig/brigfrontend/brig-atomic-inst-handler.cc |   377 +
 gcc/brig/brigfrontend/brig-basic-inst-handler.cc  |   732 +
 gcc/brig/brigfrontend/brig-branch-inst-handler.cc |   217 +
 gcc/brig/brigfrontend/brig-cmp-inst-handler.cc|   212 +
 gcc/brig/brigfrontend/brig-code-entry-handler.cc  |  2319 +++
 gcc/brig/brigfrontend/brig-code-entry-handler.h   |   449 +
 gcc/brig/brigfrontend/brig-comment-handler.cc |39 +
 gcc/brig/brigfrontend/brig-control-handler.cc |29 +
 .../brigfrontend/brig-copy-move-inst-handler.cc   |56 +
 gcc/brig/brigfrontend/brig-cvt-inst-handler.cc|   249 +
 gcc/brig/brigfrontend/brig-fbarrier-handler.cc|44 +
 gcc/brig/brigfrontend/brig-function-handler.cc|   373 +
 gcc/brig/brigfrontend/brig-function.cc|   698 +
 gcc/brig/brigfrontend/brig-function.h |   216 +
 gcc/brig/brigfrontend/brig-inst-mod-handler.cc|   168 +
 gcc/brig/brigfrontend/brig-label-handler.cc   |37 +
 gcc/brig/brigfrontend/brig-lane-inst-handler.cc   |82 +
 gcc/brig/brigfrontend/brig-machine.c  |37 +
 gcc/brig/brigfrontend/brig-machine.h  |35 +
 gcc/brig/brigfrontend/brig-mem-inst-handler.cc|   180 +
 gcc/brig/brigfrontend/brig-module-handler.cc  |30 +
 gcc/brig/brigfrontend/brig-queue-inst-handler.cc  |92 +
 gcc/brig/brigfrontend/brig-seg-inst-handler.cc|   133 +
 gcc/brig/brigfrontend/brig-signal-inst-handler.cc |42 +
 gcc/brig/brigfrontend/brig-util.cc|   347 +
 gcc/brig/brigfrontend/brig-util.h |49 +
 gcc/brig/brigfrontend/brig-variable-handler.cc|   255 +
 gcc/brig/brigfrontend/brig_to_generic.cc  |   773 +
 gcc/brig/brigfrontend/brig_to_generic.h   |   245 +
 gcc/brig/brigfrontend/phsa.h  |40 +
 gcc/brig/brigspec.c   |   193 +
 gcc/brig/config-lang.in   |41 +
 gcc/brig/lang-specs.h |28 +
 gcc/brig/lang.opt |41 +
 gcc/testsuite/brig.dg/README  |10 +
 gcc/testsuite/brig.dg/dg.exp  |27 +
 gcc/testsuite/brig.dg/test/gimple/alloca.hsail|37 +
 gcc/testsuite/brig.dg/test/gimple/atomics.hsail   |33 +
 gcc/testsuite/brig.dg/test/gimple/branches.hsail  |58 +
 gcc/testsuite/brig.dg/test/gimple/fbarrier.hsail  |74 +
 .../brig.dg/test/gimple/function_calls.hsail  |59 +
 gcc/testsuite/brig.dg/test/gimple/mem.hsail   |39 +
 gcc/testsuite/brig.dg/test/gimple/mulhi.hsail |33 +
 gcc/testsuite/brig.dg/test/gimple/packed.hsail|78 +
 .../brig.dg/test/gimple/smoke_test.hsail  |91 +
 gcc/testsuite/brig.dg/test/gimple/variables.hsail |   124 +
 gcc/testsuite/brig.dg/test/gimple/vector.hsail|57 +
 gcc/testsuite/lib/brig-dg.exp |29 +
 gcc/testsuite/lib/brig.exp|40 +
 include/hsa-interface.h   |   630 +
 libhsail-rt/Makefile.am   |   123 +
 libhsail-rt/Makefile.in   |   721 +
 libhsail-rt/README| 4 +
 libhsail-rt/aclocal.m4|   979 +
 libhsail-rt/config.h.in   |   217 +
 libhsail-rt/configure | 17162 ++
 libhsail-rt/configure.ac  |   150 +
 libhsail-rt/include/internal/phsa-rt.h|97 +
 .../include/internal/phsa_queue_interface.h   |60 +
 

[Bug ipa/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
And of course I found it (I think) just after posting the previous commit:

--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -4486,6 +4486,7 @@ expand_call_inline (basic_block bb, gimple *stmt,
copy_body_data *id)
   update_stmt (stmt);
   id->src_node->remove ();
   expand_call_inline (bb, stmt, id);
+  maybe_remove_unused_call_args (cfun, stmt);
   return true;
 }
   fn = cg_edge->callee->decl;

[Bug target/71151] New: -fmerge-constants and -fdata-sections results in string constants in .progmem.gcc_sw section

[senthil.thecoder at gmail dot com]

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

Bug ID: 71151
   Summary: -fmerge-constants and -fdata-sections results in
string constants in .progmem.gcc_sw section
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: senthil.thecoder at gmail dot com
  Target Milestone: ---

Using -fdata-sections causes string literals in functions to go into
.progmem.sw_gcc, instead of .rodata.str. This is incorrect, since code using
them expects data memory addresses, not flash.

$ cat printf.c
extern void bar(const char*);
void foo(void)
{
  bar("BB");
}

$ avr-gcc -mmcu=atmega32u2 printf.c -S -Os -fdata-sections -ffunction-sections
$ cat printf.s
jaguar:~/scratch$ cat printf.s
.file   "printf.c"
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__tmp_reg__ = 0
__zero_reg__ = 1
.section.progmem.gcc_sw_table.foo.str1.1,"aMS",@progbits,1
.LC0:
.string "BB"
.section.text.foo,"ax",@progbits
.global foo
.type   foo, @function
foo:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
ldi r24,lo8(.LC0)
ldi r25,hi8(.LC0)
jmp bar
.size   foo, .-foo
.ident  "GCC: (GNU) 6.1.0"


As the testcase shows, the string goes into progmem.gcc_sw_table..*,
and this gets placed in flash by the linker script. Reading from the address in
r25:24 will obviously not give the correct results - it will read from whatever
happens to be mapped at the same address in the data address space.

[Bug ipa/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
It would appear that we need to call maybe_remove_unused_call_args somewhere,
but so far haven't found the right spot...

my student enjoyed your page

[Jessica Lowe]

Hello,

My name is Jessica Lowe, I am a middle school teacher in Colorado. I have been 
working with a student of mine who is interested in learning more about 
computer coding and programming. I was doing some research and finding some 
sources for him, and I found your page https://gcc.gnu.org/readings.html to be 
very helpful and informative, and wanted to thank you. 

I also came across this article 
http://ithare.com/a-beginners-guide-to-programming-languages/ about programming 
for beginners, and I thought it was a great starting point for Jason, my 
student, or anyone who is interested in learning more about computer 
programming and coding. I thought it would be great to add to your resources so 
others could have access to it.

Thanks again for all of the great information, Myself and Jason both really 
appreciate it. It definitely has put him in the right direction in advancing 
towards a potential career in this field. Have a great day and please let me 
know if you are able to add the article, I would love to show Jason and know we 
were able to contribute something!

Best Wishes

Jessica Lowe
jess...@mrslowe.com

[Bug tree-optimization/71149] missing modulo 2 optimization converting result to bool

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-16
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Most likely the opt needs to be moved from fold-const to match.pd .  Should
> be a simple patch.

Yes:
  /* If this is an NE or EQ comparison of zero against the result of a
 signed MOD operation whose second operand is a power of 2, make
 the MOD operation unsigned since it is simpler and equivalent.  */
  if (integer_zerop (arg1)
  && !TYPE_UNSIGNED (TREE_TYPE (arg0))
  && (TREE_CODE (arg0) == TRUNC_MOD_EXPR
  || TREE_CODE (arg0) == CEIL_MOD_EXPR
  || TREE_CODE (arg0) == FLOOR_MOD_EXPR
  || TREE_CODE (arg0) == ROUND_MOD_EXPR)
  && integer_pow2p (TREE_OPERAND (arg0, 1)))
{
  tree newtype = unsigned_type_for (TREE_TYPE (arg0));
  tree newmod = fold_build2_loc (loc, TREE_CODE (arg0), newtype,
 fold_convert_loc (loc, newtype,
   TREE_OPERAND (arg0, 0)),
 fold_convert_loc (loc, newtype,
   TREE_OPERAND (arg0,
1)));

  return fold_build2_loc (loc, code, type, newmod,
  fold_convert_loc (loc, newtype, arg1));
}


Something like:
(for mod (ceil_mod floor_mod round_mod trunc_mod)
 (for eqne (ne eq)
  (simplify (eqne (mod @1 integer_pow2p@2) integer_zerop)
   (if (!TYPE_UNSIGNED (TREE_TYPE (@1)))
(  

I am lazy to fill in the ... part right now but you get the idea.

[Bug rtl-optimization/71150] [7 Regression] ICE on valid code at -O1 and above in 64-bit mode on x86_64-linux-gnu in lra_eliminate_reg_if_possible, at lra-eliminations.c:1402

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-16
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ICE on valid code at -O1|[7 Regression] ICE on valid
   |and above in 64-bit mode on |code at -O1 and above in
   |x86_64-linux-gnu in |64-bit mode on
   |lra_eliminate_reg_if_possib |x86_64-linux-gnu in
   |le, at  |lra_eliminate_reg_if_possib
   |lra-eliminations.c:1402 |le, at
   ||lra-eliminations.c:1402
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with:

commit 4fe01ba94e99e792ebe9da2ccb3b071aa1bac388
Author: jiwang 
Date:   Thu May 12 17:00:52 2016 +

[LRA] PR70904, relax the restriction on subreg reload for wide mode

2016-05-12  Jiong Wang  

gcc/
  PR rtl-optimization/70904
  * lra-constraint.c (process_addr_reg): Relax the restriction on
  subreg reload for wide mode.



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

[Bug rtl-optimization/71150] New: ICE on valid code at -O1 and above in 64-bit mode on x86_64-linux-gnu in lra_eliminate_reg_if_possible, at lra-eliminations.c:1402

[su at cs dot ucdavis.edu]

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

Bug ID: 71150
   Summary: ICE on valid code at -O1 and above in 64-bit mode on
x86_64-linux-gnu in lra_eliminate_reg_if_possible, at
lra-eliminations.c:1402
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O1 and above on x86_64-linux-gnu in the 64-bit mode.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.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 7.0.0 20160516 (experimental) [trunk revision 236272] (GCC)
$
$ gcc-trunk -O0 -c small.c
$
$ gcc-trunk -O1 -c small.c
small.c: In function ‘fn2’:
small.c:11:1: internal compiler error: in lra_eliminate_reg_if_possible, at
lra-eliminations.c:1402
 }
 ^
0xa5d0fe lra_eliminate_reg_if_possible(rtx_def**)
../../gcc-source-trunk/gcc/lra-eliminations.c:1402
0xa4d9ee in_class_p
../../gcc-source-trunk/gcc/lra-constraints.c:266
0xa51031 process_addr_reg
../../gcc-source-trunk/gcc/lra-constraints.c:1320
0xa54b11 process_address_1
../../gcc-source-trunk/gcc/lra-constraints.c:2983
0xa55ce9 process_address
../../gcc-source-trunk/gcc/lra-constraints.c:3233
0xa55ce9 curr_insn_transform
../../gcc-source-trunk/gcc/lra-constraints.c:3534
0xa5a736 lra_constraints(bool)
../../gcc-source-trunk/gcc/lra-constraints.c:4530
0xa46484 lra(_IO_FILE*)
../../gcc-source-trunk/gcc/lra.c:2290
0x9fd839 do_reload
../../gcc-source-trunk/gcc/ira.c:5381
0x9fd839 execute
../../gcc-source-trunk/gcc/ira.c:5565
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$


--


long a;

void fn1 () {}

void
fn2 ()
{ 
  unsigned b = (unsigned long) fn1;
  if (a ^ b)
a--;
}

[Bug tree-optimization/71149] missing modulo 2 optimization converting result to bool

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Most likely the opt needs to be moved from fold-const to match.pd .  Should be
a simple patch.

[Bug tree-optimization/71149] New: missing modulo 2 optimization converting result to bool

[msebor at gcc dot gnu.org]

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

Bug ID: 71149
   Summary: missing modulo 2 optimization converting result to
bool
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

One would expect GCC to emit comparably efficient code for all three functions
below, but it only does so for odd_mod and odd_and but not for the equivalent
odd_mod_cvt function.  Clang emits the same optimal code for all three
functions.

$ cat xxx.cpp && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc
-Dbool=_Bool -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout -o/dev/null
-xc xxx.cpp
int odd_mod (int a) {
return (a % 2) != 0;
}

_Bool odd_mod_cvt (int a) {
return a % 2;
}

int odd_and (int a) {
return (a & 1) != 0;
}


;; Function odd_mod (odd_mod, funcdef_no=0, decl_uid=1745, cgraph_uid=0,
symbol_order=0)

odd_mod (int a)
{
  int _1;

  :
  _1 = a_4(D) & 1;
  return _1;

}



;; Function odd_mod_cvt (odd_mod_cvt, funcdef_no=1, decl_uid=1748,
cgraph_uid=1, symbol_order=1)

odd_mod_cvt (int a)
{
  int _1;
  _Bool _3;

  :
  _1 = a_2(D) % 2;
  _3 = _1 != 0;
  return _3;

}



;; Function odd_and (odd_and, funcdef_no=2, decl_uid=1751, cgraph_uid=2,
symbol_order=2)

odd_and (int a)
{
  int _1;

  :
  _1 = a_3(D) & 1;
  return _1;

}

[gomp4.5] Some OpenMP 4.5 resolving and translation changes

[Jakub Jelinek]

Hi!

This patch tweaks various spots, including being able to compile taskloop
construct.  I'll be adding more testcases and tweaking the code further
later on.

2016-05-16  Jakub Jelinek  

* trans.c (trans_code): Handle new OpenMP 4.5 constructs.
* resolve.c (gfc_resolve_blocks): Likewise.
(gfc_resolve_code): Likewise.
* trans-openmp.c (gfc_trans_omp_clauses): Handle new OpenMP 4.5
clauses and new clause modifiers.
(gfc_trans_omp_do): Handle EXEC_OMP_TASKLOOP.
(GFC_OMP_SPLIT_TASKLOOP, GFC_OMP_MASK_TASKLOOP): New enum constants.
(gfc_split_omp_clauses): Handle EXEC_OMP_TARGET_PARALLEL{,_DO,_DO_SIMD}
and EXEC_OMP_TASKLOOP{,_SIMD}.  Add handling for new OpenMP 4.5
clauses and clause modifiers and handle if clause without/with
modifiers.
(gfc_trans_omp_target): Handle EXEC_OMP_TARGET_PARALLEL{,_DO,_DO_SIMD}
and EXEC_OMP_TARGET_SIMD.
(gfc_trans_omp_taskloop): New function.
(gfc_trans_omp_directive): Handle EXEC_OMP_TASKLOOP{,_SIMD},
EXEC_OMP_TARGET_PARALLEL{,_DO,_DO_SIMD} and EXEC_OMP_TARGET_SIMD.
* openmp.c (resolve_oacc_scalar_int_expr): Renamed to ...
(resolve_scalar_int_expr): ... this.  Fix up formatting.
(resolve_oacc_positive_int_expr): Renamed to ...
(resolve_positive_int_expr): ... this.  Fix up formatting.
(resolve_nonnegative_int_expr): New function.
(resolve_omp_clauses): Adjust callers, use the above functions
even for OpenMP clauses, add handling of new OpenMP 4.5 clauses.
(gfc_resolve_omp_parallel_blocks): Handle new OpenMP 4.5 constructs,
replace underscores with spaces in a few construct names.
(resolve_omp_do): Handle new OpenMP 4.5 constructs.
(resolve_oacc_loop_blocks): Call resolve_positive_int_expr instead
of resolve_oacc_positive_int_expr.
(gfc_resolve_omp_directive): Handle new OpenMP 4.5 constructs.

* testsuite/libgomp.fortran/taskloop-1.f90: New test.

--- gcc/fortran/trans.c.jj  2016-05-04 18:37:30.0 +0200
+++ gcc/fortran/trans.c 2016-05-16 15:48:07.489838631 +0200
@@ -1916,6 +1916,12 @@ trans_code (gfc_code * code, tree cond)
case EXEC_OMP_SINGLE:
case EXEC_OMP_TARGET:
case EXEC_OMP_TARGET_DATA:
+   case EXEC_OMP_TARGET_ENTER_DATA:
+   case EXEC_OMP_TARGET_EXIT_DATA:
+   case EXEC_OMP_TARGET_PARALLEL:
+   case EXEC_OMP_TARGET_PARALLEL_DO:
+   case EXEC_OMP_TARGET_PARALLEL_DO_SIMD:
+   case EXEC_OMP_TARGET_SIMD:
case EXEC_OMP_TARGET_TEAMS:
case EXEC_OMP_TARGET_TEAMS_DISTRIBUTE:
case EXEC_OMP_TARGET_TEAMS_DISTRIBUTE_PARALLEL_DO:
@@ -1924,6 +1930,8 @@ trans_code (gfc_code * code, tree cond)
case EXEC_OMP_TARGET_UPDATE:
case EXEC_OMP_TASK:
case EXEC_OMP_TASKGROUP:
+   case EXEC_OMP_TASKLOOP:
+   case EXEC_OMP_TASKLOOP_SIMD:
case EXEC_OMP_TASKWAIT:
case EXEC_OMP_TASKYIELD:
case EXEC_OMP_TEAMS:
--- gcc/fortran/resolve.c.jj2016-05-04 18:37:32.0 +0200
+++ gcc/fortran/resolve.c   2016-05-16 15:35:33.220026681 +0200
@@ -9459,6 +9459,12 @@ gfc_resolve_blocks (gfc_code *b, gfc_nam
case EXEC_OMP_SINGLE:
case EXEC_OMP_TARGET:
case EXEC_OMP_TARGET_DATA:
+   case EXEC_OMP_TARGET_ENTER_DATA:
+   case EXEC_OMP_TARGET_EXIT_DATA:
+   case EXEC_OMP_TARGET_PARALLEL:
+   case EXEC_OMP_TARGET_PARALLEL_DO:
+   case EXEC_OMP_TARGET_PARALLEL_DO_SIMD:
+   case EXEC_OMP_TARGET_SIMD:
case EXEC_OMP_TARGET_TEAMS:
case EXEC_OMP_TARGET_TEAMS_DISTRIBUTE:
case EXEC_OMP_TARGET_TEAMS_DISTRIBUTE_PARALLEL_DO:
@@ -9467,6 +9473,8 @@ gfc_resolve_blocks (gfc_code *b, gfc_nam
case EXEC_OMP_TARGET_UPDATE:
case EXEC_OMP_TASK:
case EXEC_OMP_TASKGROUP:
+   case EXEC_OMP_TASKLOOP:
+   case EXEC_OMP_TASKLOOP_SIMD:
case EXEC_OMP_TASKWAIT:
case EXEC_OMP_TASKYIELD:
case EXEC_OMP_TEAMS:
@@ -10384,6 +10392,9 @@ gfc_resolve_code (gfc_code *code, gfc_na
case EXEC_OMP_PARALLEL_DO:
case EXEC_OMP_PARALLEL_DO_SIMD:
case EXEC_OMP_PARALLEL_SECTIONS:
+   case EXEC_OMP_TARGET_PARALLEL:
+   case EXEC_OMP_TARGET_PARALLEL_DO:
+   case EXEC_OMP_TARGET_PARALLEL_DO_SIMD:
case EXEC_OMP_TARGET_TEAMS:
case EXEC_OMP_TARGET_TEAMS_DISTRIBUTE:
case EXEC_OMP_TARGET_TEAMS_DISTRIBUTE_PARALLEL_DO:
@@ -10404,6 +10415,9 @@ gfc_resolve_code (gfc_code *code, gfc_na
case EXEC_OMP_DO:
case EXEC_OMP_DO_SIMD:
case EXEC_OMP_SIMD:
+   case EXEC_OMP_TARGET_SIMD:
+   case EXEC_OMP_TASKLOOP:
+   case EXEC_OMP_TASKLOOP_SIMD:
  gfc_resolve_omp_do_blocks (code, ns);
  break;
case EXEC_SELECT_TYPE:
@@ -10786,6 +10800,12 @@ start:
case 

Re: Machine constraints list

[Michael Eager]

On 05/08/2016 03:27 PM, David Wohlferd wrote:

Looking at the v6 release criteria (https://gcc.gnu.org/gcc-6/criteria.html) 
there are about a dozen
supported platforms.

Looking at the Machine Constraints docs
(https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html), there are 34 
architectures listed.
That's a lot of entries to scroll thru.  If these architectures aren't 
supported anymore, is it time
to drop some of these from this page?


I don't believe that the listing of Primary or Secondary Platforms
should be considered an exhaustive list of the supported architectures.



As a first pass, maybe something like this:

...
> Drop
...

MicroBlaze—config/microblaze/constraints.md


MicroBlaze should continue to be supported.


--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

[PATCH][AArch64][tests] Skip cpu-diagnostics tests when overriding -mcpu

[Kyrill Tkachov]

Hi all,

The gcc.target/aarch64/cpu-diagnostics* tests specify invalid -mcpu options and 
look for the expected error.
However, if the user overrides the -mcpu option when testing the tests start 
FAILing because they don't get
the expected bad -mcpu option.

This patch skips those tests when that happens.
That way when testing with /-mcpu= the tests appear UNSUPPORTED 
rather than FAIL.

Ok for trunk?

Thanks,
Kyrill

2016-05-16  Kyrylo Tkachov  

* gcc.target/aarch64/cpu-diagnostics-1.c: Skip if -mcpu is overriden.
* gcc.target/aarch64/cpu-diagnostics-2.c: Likewise.
* gcc.target/aarch64/cpu-diagnostics-3.c: Likewise.
* gcc.target/aarch64/cpu-diagnostics-4.c: Likewise.
diff --git a/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-1.c b/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-1.c
index de6b8a7da4d4d2500e5191dbbd925fab2d0afdb8..ddba65544710d35510cd73bcab083fc088148526 100644
--- a/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-1.c
+++ b/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-1.c
@@ -1,4 +1,5 @@
 /* { dg-error "unknown" "" {target "aarch64*-*-*" } } */
+/* { dg-skip-if "do not override -mcpu" { *-*-* } { "-mcpu=*" } { "" } } */
 /* { dg-options "-O2 -mcpu=dummy" } */
 
 void f ()
diff --git a/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-2.c b/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-2.c
index 2ca006598ff84cf0b92f229e72f83750d4c5e91f..ae42436031b07af709f754f24ef63fff1ce9b34c 100644
--- a/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-2.c
+++ b/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-2.c
@@ -1,4 +1,5 @@
 /* { dg-error "missing" "" {target "aarch64*-*-*" } } */
+/* { dg-skip-if "do not override -mcpu" { *-*-* } { "-mcpu=*" } { "" } } */
 /* { dg-options "-O2 -mcpu=cortex-a53+no" } */
 
 void f ()
diff --git a/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-3.c b/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-3.c
index 807e3253e30637f73613cdd184dc79bb6f24e7dc..8bc6e2fe0492e4518cdbea47fa63315a2fd83bac 100644
--- a/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-3.c
+++ b/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-3.c
@@ -1,4 +1,5 @@
 /* { dg-error "invalid feature" "" {target "aarch64*-*-*" } } */
+/* { dg-skip-if "do not override -mcpu" { *-*-* } { "-mcpu=*" } { "" } } */
 /* { dg-options "-O2 -mcpu=cortex-a53+dummy" } */
 
 void f ()
diff --git a/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-4.c b/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-4.c
index 4c246eb0172b16f9bad8b914b0bd0addd44edfe4..58355b42f84040386eef97dbe09ed99a0091923c 100644
--- a/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-4.c
+++ b/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-4.c
@@ -1,4 +1,5 @@
 /* { dg-error "missing" "" {target "aarch64*-*-*" } } */
+/* { dg-skip-if "do not override -mcpu" { *-*-* } { "-mcpu=*" } { "" } } */
 /* { dg-options "-O2 -mcpu=+dummy" } */
 
 void f ()

[Bug hsa/70857] [6/7 Regression] ICE with -fopenmp -fopenacc in insert_vi_for_tree, at tree-ssa-structalias.c:2813

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Jambor  ---
Fixed.

[Bug hsa/70857] [6/7 Regression] ICE with -fopenmp -fopenacc in insert_vi_for_tree, at tree-ssa-structalias.c:2813

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  ---
Author: jamborm
Date: Mon May 16 15:57:06 2016
New Revision: 236292

URL: https://gcc.gnu.org/viewcvs?rev=236292=gcc=rev
Log:
[PR 70857] Copy RESULT_DECL of HSA outlined kernel function

2016-05-16  Martin Jambor  

PR hsa/70857
* omp-low.c (grid_expand_target_grid_body): Copy RESULT_DECL of
the outlined kernel function.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/omp-low.c

[Bug c++/71121] Spurious warning: "the address of [...] will never be NULL [-Waddress]"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-16
 CC||jason at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
  Known to work||5.3.0
 Blocks||55004
 Ever confirmed|0   |1
  Known to fail||6.1.0

--- Comment #1 from Martin Sebor  ---
Confirmed with 6.1.0 and today's top of trunk (7.0).  Both the auto and the
constexpr appear to be necessary to trigger the warning.  The regression
appears to have been introduced in r234940.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug hsa/70857] [6/7 Regression] ICE with -fopenmp -fopenacc in insert_vi_for_tree, at tree-ssa-structalias.c:2813

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
Author: jamborm
Date: Mon May 16 15:40:30 2016
New Revision: 236291

URL: https://gcc.gnu.org/viewcvs?rev=236291=gcc=rev
Log:
[PR 70857] Copy RESULT_DECL of HSA outlined kernel function

2016-05-16  Martin Jambor  

PR hsa/70857
* omp-low.c (grid_expand_target_grid_body): Copy RESULT_DECL of
the outlined kernel function.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c

[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-16
 Ever confirmed|0   |1

[Bug libstdc++/71133] msp430-elf -mlarge FTBFS in libstdc++-v3

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-16
 CC||torvald at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libstdc++/71135] rl78-elf libstdc++ FTBFS with some multilibs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||torvald at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
I think we just want to disable TM library support for such targets.

Re: [PATCH GCC]Document vect_cond_mixed in sourcebuild.texi

[Sandra Loosemore]

On 05/16/2016 05:01 AM, Bin Cheng wrote:

Hi,
This is an obvious patch documenting vect_cond_mixed in sourcebuild.texi.  OK?

Thanks,
bin

2016-05-13  bin cheng  

* doc/sourcebuild.texi (@item vect_cond_mixed): New item.


Assuming the information is technically correct, the patch looks OK from 
a documentation perspective.


-Sandra

RE: [PATCH][MIPS] Enable LSA/DLSA for MSA

[Robert Suchanek]

Hi Matthew,
> > Ok to commit?
> 
> OK.

Done as r236289.
 
> There is a corresponding testsuite change needed for this
> as some code quality tests change if LSA is available.  This
> is the HAS_LSA 'ghost' option in mips.exp.  I'm happy to leave
> this to be dealt with as part of the overall MSA testsuite
> patch though.

It's on my TODO list and will update the patch with MSA tests
to put all tests in one go.

Regards,
Robert

Re: [PR 70857] Copy RESULT_DECL of HSA outlined kernel function

[Jakub Jelinek]

On Mon, May 16, 2016 at 04:25:10PM +0200, Martin Jambor wrote:
> the patch below fixes PR 70857.  When the HSA gridification code
> copies the declaration of the function for outlining the target
> construct, it left the old RESULT_DECL dangling to it.  I did not
> notice because it has VOID_TYPE but it needs to be done nevertheless,
> not least because ipa-pta chokes on it.
> 
> Bootstrapped and tested on x86_64 with hsa enabled.  OK for trunk and
> the gcc-6 branch?
> 
> Thanks,
> 
> Martin
> 
> 2016-05-12  Martin Jambor  
> 
>   PR hsa/70857
>   * omp-low.c (grid_expand_target_grid_body): Copy RESULT_DECL of
>   the outlined kernel function.

Ok.

> diff --git a/gcc/omp-low.c b/gcc/omp-low.c
> index c9600fb..a11f44b 100644
> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -13681,6 +13681,9 @@ grid_expand_target_grid_body (struct omp_region 
> *target)
>tree new_parm_decl = copy_node (DECL_ARGUMENTS (kern_fndecl));
>DECL_CONTEXT (new_parm_decl) = kern_fndecl;
>DECL_ARGUMENTS (kern_fndecl) = new_parm_decl;
> +  gcc_assert (VOID_TYPE_P (TREE_TYPE (DECL_RESULT (kern_fndecl;
> +  DECL_RESULT (kern_fndecl) = copy_node (DECL_RESULT (kern_fndecl));
> +  DECL_CONTEXT (DECL_RESULT (kern_fndecl)) = kern_fndecl;
>struct function *kern_cfun = DECL_STRUCT_FUNCTION (kern_fndecl);
>kern_cfun->curr_properties = cfun->curr_properties;
>  
> -- 
> 2.8.2

Jakub

RE: [PATCH][MIPS] Correct latency of loads in M5100

[Robert Suchanek]

> > Ok to commit?
> 
> > * config/mips/m5100.md (m51_int_load): Update the latency to 2.
> 
> OK.

Committed - r236288

Robert

[PR 70857] Copy RESULT_DECL of HSA outlined kernel function

[Martin Jambor]

Hi,

the patch below fixes PR 70857.  When the HSA gridification code
copies the declaration of the function for outlining the target
construct, it left the old RESULT_DECL dangling to it.  I did not
notice because it has VOID_TYPE but it needs to be done nevertheless,
not least because ipa-pta chokes on it.

Bootstrapped and tested on x86_64 with hsa enabled.  OK for trunk and
the gcc-6 branch?

Thanks,

Martin

2016-05-12  Martin Jambor  

PR hsa/70857
* omp-low.c (grid_expand_target_grid_body): Copy RESULT_DECL of
the outlined kernel function.
---
 gcc/omp-low.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index c9600fb..a11f44b 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -13681,6 +13681,9 @@ grid_expand_target_grid_body (struct omp_region *target)
   tree new_parm_decl = copy_node (DECL_ARGUMENTS (kern_fndecl));
   DECL_CONTEXT (new_parm_decl) = kern_fndecl;
   DECL_ARGUMENTS (kern_fndecl) = new_parm_decl;
+  gcc_assert (VOID_TYPE_P (TREE_TYPE (DECL_RESULT (kern_fndecl;
+  DECL_RESULT (kern_fndecl) = copy_node (DECL_RESULT (kern_fndecl));
+  DECL_CONTEXT (DECL_RESULT (kern_fndecl)) = kern_fndecl;
   struct function *kern_cfun = DECL_STRUCT_FUNCTION (kern_fndecl);
   kern_cfun->curr_properties = cfun->curr_properties;
 
-- 
2.8.2

RE: [RFC v2] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking

[Matthew Fortune]

Hi Maciej,

Thanks for the update.  I've read through the whole proposal again and
it looks good.  I'd like to discuss legacy objects a bit more though...

Maciej Rozycki  writes:
> 3.4 Relocatable Object Generation
> 
>  Tools that produce relocatable objects such as the assembler shall
> always produce a SHT_MIPS_ABIFLAGS section according to the IEEE Std 754
> compliance mode selected.  In the absence of any explicit user
> instructions the `strict' mode shall be assumed.  No new `legacy'
> objects shall be produced.

Is it necessary to say that no new legacy objects can be created?

I think there is value in still being able to generate legacy objects because
of the fact that strict executables leave no room for override at runtime.
Apart from the fact that strict cannot be disabled there is otherwise no
difference between legacy and strict compliance modes.

I believe the strict option is really intended for conscious use so that
programmers who know they need it, can use it. Ordinary users still get the
casual safety they need as legacy objects are just as good as strict until
overridden. If we lose the ability to override then in some environments we
will accumulate lots of needlessly strict executables just because of a tools
upgrade whereas the old tools would have generated executables that were as
safe but also could be overridden by kernel options. 

Allowing legacy objects to be generated may also allow the linkage rules to
be tightened.  I.e. Forcing a relaxed mode at link time could simply fail
if confronted by a strict object instead only allowing legacy objects to
be relaxed.

A default build of GCC and binutils would therefore still generate legacy
objects until someone consciously updated the configure options or used
command line options.

Thanks,
Matthew