Re: [PATCH] PR target/68991: Add vector_memory_operand and "Bm" constraint

[Jakub Jelinek]

On Mon, Jan 04, 2016 at 03:25:48PM -0800, H.J. Lu wrote:
> LRA is fine.  I should use
> 
> (define_memory_constraint "Bm"
>   "@internal Vector memory operand."
>   (match_operand 0 "vector_memory_operand"))
> 
> instead of
> 
> (define_constraint "Bm"
>   "@internal Vector memory operand."
>   (match_operand 0 "vector_memory_operand"))

I don't think so.  At least the documentation says that
define_memory_constraint is for MEM constraints where if they are not
satisfied they can be made to satisfy by forcing the address into a
register.  But that is not the case here, if a MEM is misaligned, no
equivalent changes to the XEXP (mem, 0) will make it aligned.

Jakub

[PATCH] Fix PR c/69122 (-Wmisleading-indentation false positive with empty macros)

[David Malcolm]

Successfully bootstrapped on x86_64-pc-linux-gnu.
OK for trunk?

gcc/c-family/ChangeLog:
PR c/69122
* c-indentation.c (get_visual_column): Remove default argument.
(should_warn_for_misleading_indentation): For the multiline case,
update call to get_visual_column for next_stmt_exploc so that it
captures the location of the first non-whitespace character in the
relevant line.  Don't issue warnings if there is non-whitespace
before the next statement.

gcc/testsuite/ChangeLog:
PR c/69122
* c-c++-common/Wmisleading-indentation.c (pr69122): New function.
---
 gcc/c-family/c-indentation.c   | 24 --
 .../c-c++-common/Wmisleading-indentation.c | 10 +
 2 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/gcc/c-family/c-indentation.c b/gcc/c-family/c-indentation.c
index 2f857f7..3c09336 100644
--- a/gcc/c-family/c-indentation.c
+++ b/gcc/c-family/c-indentation.c
@@ -38,7 +38,7 @@ extern cpp_options *cpp_opts;
 static bool
 get_visual_column (expanded_location exploc,
   unsigned int *out,
-  unsigned int *first_nws = NULL)
+  unsigned int *first_nws)
 {
   int line_len;
   const char *line = location_get_source_line (exploc.file, exploc.line,
@@ -329,12 +329,20 @@ should_warn_for_misleading_indentation (const 
token_indent_info _tinfo,
  ;
  foo ();
  ^ DON'T WARN HERE
+
+   #define emit
+   if (flag)
+foo ();
+   emit bar ();
+^ DON'T WARN HERE
+
   */
   if (next_stmt_exploc.line > body_exploc.line)
 {
   /* Determine if GUARD_LOC and NEXT_STMT_LOC are aligned on the same
 "visual column"...  */
   unsigned int next_stmt_vis_column;
+  unsigned int next_stmt_line_first_nws;
   unsigned int body_vis_column;
   unsigned int body_line_first_nws;
   unsigned int guard_vis_column;
@@ -343,7 +351,8 @@ should_warn_for_misleading_indentation (const 
token_indent_info _tinfo,
 the case for input files containing #line directives, and these
 are often for autogenerated sources (e.g. from .md files), where
 it's not clear that it's meaningful to look at indentation.  */
-  if (!get_visual_column (next_stmt_exploc, _stmt_vis_column))
+  if (!get_visual_column (next_stmt_exploc, _stmt_vis_column,
+ _stmt_line_first_nws))
return false;
   if (!get_visual_column (body_exploc,
  _vis_column,
@@ -354,6 +363,17 @@ should_warn_for_misleading_indentation (const 
token_indent_info _tinfo,
  _line_first_nws))
return false;
 
+  /* If the line where the next stmt starts has non-whitespace
+on it before the stmt, then don't warn:
+ #define emit
+ if (flag)
+  foo ();
+ emit bar ();
+  ^ DON'T WARN HERE
+(PR c/69122).  */
+  if (next_stmt_line_first_nws < next_stmt_vis_column)
+   return false;
+
   if ((body_type != CPP_SEMICOLON
   && next_stmt_vis_column == body_vis_column)
  /* As a special case handle the case where the body is a semicolon
diff --git a/gcc/testsuite/c-c++-common/Wmisleading-indentation.c 
b/gcc/testsuite/c-c++-common/Wmisleading-indentation.c
index a3f5acd..491291c 100644
--- a/gcc/testsuite/c-c++-common/Wmisleading-indentation.c
+++ b/gcc/testsuite/c-c++-common/Wmisleading-indentation.c
@@ -891,3 +891,13 @@ fn_39 (void)
i++);
   foo (i);
 }
+
+/* We shouldn't complain about the following function.  */
+#define emit
+void pr69122 (void)
+{
+  if (flagA)
+   foo (0);
+  emit foo (1);
+}
+#undef emit
-- 
1.8.5.3

Re: [PATCH][combine][v2] Canonicalise (r + r) to (r << 1) to aid recognition

[Kyrill Tkachov]

Hi all,

On 18/12/15 14:39, Bernd Schmidt wrote:

On 12/18/2015 03:29 PM, Kyrill Tkachov wrote:

Bootstrapped and tested on arm, aarch64, x86_64.
As before, there were no codegen differences for SPEC2006 on x86_64.
aarch64 SPEC2006 sees the effects described above.


I think this is OK. There may be some question as to whether this is a bug fix, 
so please wait a few days for objections before committing. I'm assuming 
there's no place which tries to do the opposite transformation...



As I didn't hear see objections I'll be committing this later today.

Thanks for the reviews.

Kyrill



Bernd

Re: [PATHCH] Disable inline asm for in-tree mpfr (PR69134)

[Marc Glisse]

On Tue, 5 Jan 2016, Marc Glisse wrote:


On Tue, 5 Jan 2016, Bernd Edlinger wrote:

an in-tree mpfr build enables inline asm code, which makes the 
mips-bootstrap fail,
because at least mpfr 2.4.2 uses the "=h" constraint but in 
config/mips/constraints.md
we find: "Formerly the @code{hi} register.  This constraint is no longer 
supported.".


Using asm code is generally not desirable for in-tree mpfr builds.  So I 
looked for a way
to disable the asm code, and found it can be done, but differently than for 
in-tree gmp.

See the attached patch.


Note that, at least with recent versions, if you configure gmp with 
--disable-assembly, the flag -DNO_ASM ends up in __GMP_CFLAGS (in gmp.h) and 
mpfr thus uses it automatically.


Hmm, that probably doesn't apply here since gcc passes its own CC and 
CFLAGS to mpfr, please ignore my message.


--
Marc Glisse

[PATHCH] Disable inline asm for in-tree mpfr (PR69134)

[Bernd Edlinger]

Hi,


an in-tree mpfr build enables inline asm code, which makes the mips-bootstrap 
fail,
because at least mpfr 2.4.2 uses the "=h" constraint but in 
config/mips/constraints.md
we find: "Formerly the @code{hi} register.  This constraint is no longer 
supported.".

Using asm code is generally not desirable for in-tree mpfr builds.  So I looked 
for a way
to disable the asm code, and found it can be done, but differently than for 
in-tree gmp.
See the attached patch.


Boot-strapped and Reg-tested on x86_64-pc-linux-gnu.
OK for trunk?


Thanks
Bernd.2016-01-05  Bernd Edlinger  

	PR bootstrap/69134
	* Makefile.def (mpfr): Disable assembler.
	* Makefile.in: Regenerate.

Index: Makefile.def
===
--- Makefile.def	(revision 232034)
+++ Makefile.def	(working copy)
@@ -59,6 +59,7 @@ host_modules= { module= gmp; lib_path=.libs; boots
 	target="none-${host_vendor}-${host_os}"; };
 host_modules= { module= mpfr; lib_path=.libs; bootstrap=true;
 		extra_configure_flags='--disable-shared @extra_mpfr_configure_flags@';
+		extra_make_flags='AM_CFLAGS="-DNO_ASM"';
 		no_install= true; };
 host_modules= { module= mpc; lib_path=.libs; bootstrap=true;
 		extra_configure_flags='--disable-shared @extra_mpc_gmp_configure_flags@ @extra_mpc_mpfr_configure_flags@';
Index: Makefile.in
===
--- Makefile.in	(revision 232034)
+++ Makefile.in	(working copy)
@@ -12164,7 +12164,7 @@ all-mpfr: configure-mpfr
 	s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
 	$(HOST_EXPORTS)  \
 	(cd $(HOST_SUBDIR)/mpfr && \
-	  $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS) $(STAGE1_FLAGS_TO_PASS)  \
+	  $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS) $(STAGE1_FLAGS_TO_PASS) AM_CFLAGS="-DNO_ASM" \
 		$(TARGET-mpfr))
 @endif mpfr
 
@@ -12193,7 +12193,7 @@ all-stage1-mpfr: configure-stage1-mpfr
 		CXXFLAGS_FOR_TARGET="$(CXXFLAGS_FOR_TARGET)" \
 		LIBCFLAGS_FOR_TARGET="$(LIBCFLAGS_FOR_TARGET)" \
 		$(EXTRA_HOST_FLAGS)  \
-		$(STAGE1_FLAGS_TO_PASS)  \
+		$(STAGE1_FLAGS_TO_PASS) AM_CFLAGS="-DNO_ASM" \
 		TFLAGS="$(STAGE1_TFLAGS)" \
 		$(TARGET-stage1-mpfr)
 
@@ -12208,7 +12208,7 @@ clean-stage1-mpfr:
 	fi; \
 	cd $(HOST_SUBDIR)/mpfr && \
 	$(MAKE) $(EXTRA_HOST_FLAGS)  \
-	$(STAGE1_FLAGS_TO_PASS)  clean
+	$(STAGE1_FLAGS_TO_PASS) AM_CFLAGS="-DNO_ASM" clean
 @endif mpfr-bootstrap
 
 
@@ -12235,7 +12235,7 @@ all-stage2-mpfr: configure-stage2-mpfr
 		CFLAGS_FOR_TARGET="$(CFLAGS_FOR_TARGET)" \
 		CXXFLAGS_FOR_TARGET="$(CXXFLAGS_FOR_TARGET)" \
 		LIBCFLAGS_FOR_TARGET="$(LIBCFLAGS_FOR_TARGET)" \
-		$(EXTRA_HOST_FLAGS) $(POSTSTAGE1_FLAGS_TO_PASS)  \
+		$(EXTRA_HOST_FLAGS) $(POSTSTAGE1_FLAGS_TO_PASS) AM_CFLAGS="-DNO_ASM" \
 		TFLAGS="$(STAGE2_TFLAGS)" \
 		$(TARGET-stage2-mpfr)
 
@@ -12249,7 +12249,7 @@ clean-stage2-mpfr:
 	  $(MAKE) stage2-start; \
 	fi; \
 	cd $(HOST_SUBDIR)/mpfr && \
-	$(MAKE) $(EXTRA_HOST_FLAGS) $(POSTSTAGE1_FLAGS_TO_PASS)  clean
+	$(MAKE) $(EXTRA_HOST_FLAGS) $(POSTSTAGE1_FLAGS_TO_PASS) AM_CFLAGS="-DNO_ASM" clean
 @endif mpfr-bootstrap
 
 
@@ -12276,7 +12276,7 @@ all-stage3-mpfr: configure-stage3-mpfr
 		CFLAGS_FOR_TARGET="$(CFLAGS_FOR_TARGET)" \
 		CXXFLAGS_FOR_TARGET="$(CXXFLAGS_FOR_TARGET)" \
 		LIBCFLAGS_FOR_TARGET="$(LIBCFLAGS_FOR_TARGET)" \
-		$(EXTRA_HOST_FLAGS) $(POSTSTAGE1_FLAGS_TO_PASS)  \
+		$(EXTRA_HOST_FLAGS) $(POSTSTAGE1_FLAGS_TO_PASS) AM_CFLAGS="-DNO_ASM" \
 		TFLAGS="$(STAGE3_TFLAGS)" \
 		$(TARGET-stage3-mpfr)
 
@@ -12290,7 +12290,7 @@ clean-stage3-mpfr:
 	  $(MAKE) stage3-start; \
 	fi; \
 	cd $(HOST_SUBDIR)/mpfr && \
-	$(MAKE) $(EXTRA_HOST_FLAGS) $(POSTSTAGE1_FLAGS_TO_PASS)  clean
+	$(MAKE) $(EXTRA_HOST_FLAGS) $(POSTSTAGE1_FLAGS_TO_PASS) AM_CFLAGS="-DNO_ASM" clean
 @endif mpfr-bootstrap
 
 
@@ -12317,7 +12317,7 @@ all-stage4-mpfr: configure-stage4-mpfr
 		CFLAGS_FOR_TARGET="$(CFLAGS_FOR_TARGET)" \
 		CXXFLAGS_FOR_TARGET="$(CXXFLAGS_FOR_TARGET)" \
 		LIBCFLAGS_FOR_TARGET="$(LIBCFLAGS_FOR_TARGET)" \
-		$(EXTRA_HOST_FLAGS) $(POSTSTAGE1_FLAGS_TO_PASS)  \
+		$(EXTRA_HOST_FLAGS) $(POSTSTAGE1_FLAGS_TO_PASS) AM_CFLAGS="-DNO_ASM" \
 		TFLAGS="$(STAGE4_TFLAGS)" \
 		$(TARGET-stage4-mpfr)
 
@@ -12331,7 +12331,7 @@ clean-stage4-mpfr:
 	  $(MAKE) stage4-start; \
 	fi; \
 	cd $(HOST_SUBDIR)/mpfr && \
-	$(MAKE) $(EXTRA_HOST_FLAGS) $(POSTSTAGE1_FLAGS_TO_PASS)  clean
+	$(MAKE) $(EXTRA_HOST_FLAGS) $(POSTSTAGE1_FLAGS_TO_PASS) AM_CFLAGS="-DNO_ASM" clean
 @endif mpfr-bootstrap
 
 
@@ -12358,7 +12358,7 @@ all-stageprofile-mpfr: configure-stageprofile-mpfr
 		CFLAGS_FOR_TARGET="$(CFLAGS_FOR_TARGET)" \
 		CXXFLAGS_FOR_TARGET="$(CXXFLAGS_FOR_TARGET)" \
 		LIBCFLAGS_FOR_TARGET="$(LIBCFLAGS_FOR_TARGET)" \
-		$(EXTRA_HOST_FLAGS) $(POSTSTAGE1_FLAGS_TO_PASS)  \
+		$(EXTRA_HOST_FLAGS) $(POSTSTAGE1_FLAGS_TO_PASS) AM_CFLAGS="-DNO_ASM" \
 		TFLAGS="$(STAGEprofile_TFLAGS)" \
 		$(TARGET-stageprofile-mpfr)
 
@@ -12372,7 +12372,7 @@ clean-stageprofile-mpfr:
 	  $(MAKE) stageprofile-start; \
 	fi; \
 	cd 

Re: [PATCHES, PING*5] Enhance standard DWARF for Ada

[Pierre-Marie de Rodat]

On 01/03/2016 12:45 AM, Eric Botcazou wrote:

On powerpc64:

FAIL: gnat.dg/specs/debug1.ads scan-assembler-times DW_AT_artificial 18

$ grep -c DW_AT_artificial debug1.s
17


Test removed.


Thank you both!

--
Pierre-Marie de Rodat

Re: [ping] pending patches

[Eric Botcazou]

> It doesn't look to me like DW_AT_endianity is applicable to array types
> or members in DWARF 3/4; instead, it should be applied to the underlying
> base type.

OK, the attached patch does that so is more invasive as expected.

Tested on x86_64-suse-linux, OK for the mainline?


2016-01-05  Eric Botcazou  

* dwarf2out.c (need_endianity_attribute_p): New inline predicate.
(base_type_die): Add REVERSE parameter and attach DW_AT_endianity to
the DIE accordingly.
(modified_type_die): Add REVERSE parameter and pass it recursively,
as well as to base_type_die.  Adjust presence check accordingly.
(base_type_for_mode): Adjust call to modified_type_die.
(add_type_attribute): Add REVERSE parameter and pass it to
modified_type_die.
(generic_parameter_die): Adjust call to add_type_attribute.
(add_scalar_info): Likewise.
(add_subscript_info): Likewise.
(gen_array_type_die): Likewise.
(gen_descr_array_type_die): Likewise.
(gen_entry_point_die): Likewise.
(gen_enumeration_type_die): Likewise.
(gen_formal_parameter_die): Likewise.
(gen_subprogram_die): Likewise.
(gen_variable_die ): Likewise.
(gen_const_die): Likewise.
(gen_field_die): Likewise.
(gen_pointer_type_die): Likewise.
(gen_reference_type_die): Likewise.
(gen_ptr_to_mbr_type_die): Likewise.
(gen_inheritance_die): Likewise.
(gen_subroutine_type_die): Likewise.
(gen_typedef_die): Likewise.
(force_type_die): Adjust call to modified_type_die.

2016-01-05  Eric Botcazou  

* gcc.dg/debug/dwarf2/sso.c: New test.

-- 
Eric BotcazouIndex: dwarf2out.c
===
--- dwarf2out.c	(revision 232035)
+++ dwarf2out.c	(working copy)
@@ -3286,11 +3286,11 @@ static void output_ranges (void);
 static dw_line_info_table *new_line_info_table (void);
 static void output_line_info (bool);
 static void output_file_names (void);
-static dw_die_ref base_type_die (tree);
+static dw_die_ref base_type_die (tree, bool);
 static int is_base_type (tree);
 static dw_die_ref subrange_type_die (tree, tree, tree, tree, dw_die_ref);
 static int decl_quals (const_tree);
-static dw_die_ref modified_type_die (tree, int, dw_die_ref);
+static dw_die_ref modified_type_die (tree, int, bool, dw_die_ref);
 static dw_die_ref generic_parameter_die (tree, tree, bool, dw_die_ref);
 static dw_die_ref template_parameter_pack_die (tree, tree, dw_die_ref);
 static int type_is_enum (const_tree);
@@ -3362,7 +3362,7 @@ static dw_die_ref scope_die_for (tree, d
 static inline int local_scope_p (dw_die_ref);
 static inline int class_scope_p (dw_die_ref);
 static inline int class_or_namespace_scope_p (dw_die_ref);
-static void add_type_attribute (dw_die_ref, tree, int, dw_die_ref);
+static void add_type_attribute (dw_die_ref, tree, int, bool, dw_die_ref);
 static void add_calling_convention_attribute (dw_die_ref, tree);
 static const char *type_tag (const_tree);
 static tree member_declared_type (const_tree);
@@ -10796,14 +10796,23 @@ output_line_info (bool prologue_only)
   ASM_OUTPUT_LABEL (asm_out_file, l2);
 }
 
+/* Return true if DW_AT_endianity should be emitted according to REVERSE.  */
+
+static inline bool
+need_endianity_attribute_p (bool reverse)
+{
+  return reverse && (dwarf_version >= 3 || !dwarf_strict);
+}
+
 /* Given a pointer to a tree node for some base type, return a pointer to
-   a DIE that describes the given type.
+   a DIE that describes the given type.  REVERSE is true if this type is
+   to be interpreted in reverse storage order wrt to the target order.
 
This routine must only be called for GCC type nodes that correspond to
Dwarf base (fundamental) types.  */
 
 static dw_die_ref
-base_type_die (tree type)
+base_type_die (tree type, bool reverse)
 {
   dw_die_ref base_type_result;
   enum dwarf_type encoding;
@@ -10912,6 +10921,10 @@ base_type_die (tree type)
 		   int_size_in_bytes (type));
   add_AT_unsigned (base_type_result, DW_AT_encoding, encoding);
 
+  if (need_endianity_attribute_p (reverse))
+add_AT_unsigned (base_type_result, DW_AT_endianity,
+		 BYTES_BIG_ENDIAN ? DW_END_little : DW_END_big);
+
   if (fpt_used)
 {
   switch (fpt_info.scale_factor_kind)
@@ -10948,12 +10961,14 @@ base_type_die (tree type)
 	  gcc_unreachable ();
 	}
 }
-  if (type_bias != NULL)
+
+  if (type_bias)
 add_scalar_info (base_type_result, DW_AT_GNU_bias, type_bias,
 		 dw_scalar_form_constant
 		 | dw_scalar_form_exprloc
 		 | dw_scalar_form_reference,
 		 NULL);
+
   add_pubtype (type, base_type_result);
 
   return base_type_result;
@@ -11138,7 +11153,8 @@ get_nearest_type_subqualifiers (tree typ
entry that chains various modifiers in front of the given type.  */
 
 static dw_die_ref
-modified_type_die (tree type, int cv_quals, 

Re: [PATCH v2] ia64: don't use dynamic relocations for local symbols

[Sergei Trofimovich]

On Sat, 2 Jan 2016 11:50:56 +
Sergei Trofimovich  wrote:

> Attached updated patch and test runs on a crosscompiler before
> and after the change.
> 
> Now I'm building on real ia64 hardware as
> make bootstrap
> make -k check
> 
> for both clean and patched trees.

'make bootstrap' works fine on ia64 but I've failed to run 'make check'.
Testsuite's LD_LIBRARY_PATHs are not correct and can run tests.

Executing on host: /root/gcc-build/gcc/xgcc -B/root/gcc-build/gcc/  
-fno-diagnostics-show-caret -fdiagnostics-color=never-O0  -w -c   -o 
2105-1.o /root/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c
(timeout = 300)
spawn /root/gcc-build/gcc/xgcc -B/root/gcc-build/gcc/ 
-fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -w -c -o 21
05-1.o /root/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c
compiler exited with status -1
output is:
spawn failed

But running builds manually works:

gcc-build # /root/gcc-build/gcc/xgcc -B/root/gcc-build/gcc/  
-fno-diagnostics-show-caret -fdiagnostics-color=never-O0  -w -c   -o 
2105-1.o /root/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c  && 
echo ok
ok

-- 

  Sergei


signature.asc
Description: PGP signature

RE: [PATHCH] Disable inline asm for in-tree mpfr (PR69134)

[Matthew Fortune]

Bernd Edlinger  writes:
> an in-tree mpfr build enables inline asm code, which makes the mips-bootstrap 
> fail,
> because at least mpfr 2.4.2 uses the "=h" constraint but in 
> config/mips/constraints.md
> we find: "Formerly the @code{hi} register.  This constraint is no longer 
> supported.".
> 
> Using asm code is generally not desirable for in-tree mpfr builds.  So I 
> looked for a way
> to disable the asm code, and found it can be done, but differently than for 
> in-tree gmp.
> See the attached patch.
> 
> 
> Boot-strapped and Reg-tested on x86_64-pc-linux-gnu.
> OK for trunk?

FWIW, this sounds like a good plan to me. I'll try and remember to ask someone 
to work
through MPFR to fix the inline asm for MIPS.

Matthew

RE: [PATCH] Fix pr69012 ICE on building libgfortran for mips

[Matthew Fortune]

Bernd Edlinger  writes:
> Hi,
> 
> On 30.12.2015 15:31, Richard Sandiford wrote:
> > I think the problem is deeper than that though. The instructions that
> > are triggering the ICE are only generated by the prologue, so this
> > means that we're trying to lay out the frame again after the prologue
> > has been generated, whereas it really needs to be fixed by then. (And
> > even if recalculating it is a no-op, the operation is still too
> > expensive to be repeated lightly.) Query functions like
> > rtx_addr_can_trap_p(_1) shouldn't really be changing or recalculating
> > the frame layout or other global state. I think we need to find a
> > different way of getting the information. Maybe reload/LRA should use
> > its own structures to calculate the range of "safe" stack and hfp
> > offsets, then store them in crtl for rtx_addr_can_trap_p to use. AIUI,
> > before reload, the only non-trapping uses of sp should be for outgoing
> > arguments, so we can use a test based on the cumulative outgoing
> > arguments size. I don't think the hfp should be used at all before
> > reload, so we could conservatively return -1 for that case. Thanks,
> > Richard
> 
> 
> Yes, I agree, it _should_ be a no-op, but given the complexity of
> mips_compute_frame_info it is probably better to use cached values after
> reload completed.
> 
> Before reload_completed, rtx_addr_can_trap_p is just trying to do an
> initial guess on the stack layout, it may well be possible that some
> important information is still missing here.  We will never call the
> target callback from here, before reload_completed.  It is however not
> completely impossible that rtx_addr_can_trap_p is called while
> lra/reload is already renaming the registers, see PR66614.
> 
> Of course the required information is already cached in
> cfun->machine->frame, but rtx_addr_can_trap_p can't use the information
> without a target callback.  And I just want to avoid to invent a new
> callback for that.
> 
> I looked at how other targets handle this situation and found that most
> of them either have a more simple frame layout function or they keep the
> previously cached values if they are ever called after reload_completed.
> 
> I found, previously mips_compute_frame_info was always called with
> reload_completed=false, either from mips_frame_pointer_required or from
> mips_initial_elimination_offset.  Reload seems to call the
> initial_elimination_offset repeatedly and seems to _expect_ the values
> to change from time to time.  However it does not seem to expect the
> result from mips_frame_pointer_required to change after reload/LRA has
> started.  But as it seems, that may be possible for TARGET_MIPS16 if the
> frame size happens to be very close to 0x7FFF. Well that could be
> another story.
> 
> Anyways when mips_compute_frame_info is called with
> reload_completed=true, we can as well use the cached values, as they
> were immediately before reload_completed.
> 
> So what do you think of my new version of the patch?

Hi Bernd,

I don't see any problem with this change from a MIPS backend perspective.
As to whether rtx_addr_can_trap_p should be using initial_elimination_offset
then I don't have any particular opinion.

Richard: Any objections to using this fix so we can solve the PR leaving
debate on the original rtx_addr_can_trap_p as a separate issue?

Thanks,
Matthew

Re: [PATCH v2] ia64: don't use dynamic relocations for local symbols

[Eric Botcazou]

> 'make bootstrap' works fine on ia64 but I've failed to run 'make check'.
> Testsuite's LD_LIBRARY_PATHs are not correct and can run tests.

You need to run 'make -k check' from the top level build directory.

-- 
Eric Botcazou

Re: [PATHCH] Disable inline asm for in-tree mpfr (PR69134)

[Marc Glisse]

On Tue, 5 Jan 2016, Bernd Edlinger wrote:


an in-tree mpfr build enables inline asm code, which makes the mips-bootstrap 
fail,
because at least mpfr 2.4.2 uses the "=h" constraint but in 
config/mips/constraints.md
we find: "Formerly the @code{hi} register.  This constraint is no longer 
supported.".

Using asm code is generally not desirable for in-tree mpfr builds.  So I looked 
for a way
to disable the asm code, and found it can be done, but differently than for 
in-tree gmp.
See the attached patch.


Note that, at least with recent versions, if you configure gmp with 
--disable-assembly, the flag -DNO_ASM ends up in __GMP_CFLAGS (in gmp.h) 
and mpfr thus uses it automatically.


--
Marc Glisse

Re: [patch] ARM FreeBSD fix bootstrap

[Richard Earnshaw (lists)]

On 23/12/15 19:28, Andreas Tobler wrote:
> On 23.12.15 11:22, Richard Earnshaw (lists) wrote:
>> On 22/12/15 19:53, Andreas Tobler wrote:
>>> Hi all,
>>>
>>> the commit for PR68617 broke boostrap on armv6*-*-freebsd*.
>>>
>>> We still have unaligned_access = 0 on armv6 here on FreeBSD.
>>>
>>> The commit from the above PR overrides my SUBTARGET_OVERRIDE_OPTIONS I
>>> called in arm_option_override. And it sets the unaligned_access to 1.
>>>
>>> The attached patch fixes this, bootstrap ongoing but passed the breaking
>>> stage where genmddeps bus errored.
>>>
>>> Is this patch ok for trunk once bootstrap completes?
>>>
>>> TIA,
>>> Andreas
>>>
>>> 2015-12-22  Andreas Tobler  
>>>
>>>  * config/arm/freebsd.h (SUBTARGET_OVERRIDE_OPTIONS): Adjust to
>>>  check unaligned_access on the gcc_options set.
>>>  * config/arm/arm.c (arm_option_override): Move
>>>  SUBTARGET_OVERRIDE_OPTIONS from here to
>>>  (arm_option_override_internal).
>>>
>>
>> Moving this hunk to a different place potentially affects VXWORKS (the
>> only other target that uses this hook).  I'd like to see confirmation
>> from the VxWorks maintainers (Nathan?) that this doesn't cause any
>> problems for them.  If it does, then I think you need to create a new
>> subtarget hook (SUBTARGET_OVERRIDE_INTERNAL_OPTIONS?) and change FreeBSD
>> to use that rather than the existing hook.
> 
> I noticed this morning that VxWorks might be affected. To be on the safe
> side I'd like to propose the attached version since it makes clear where
> the override belongs to and I don't think hijacking
> SUBTARGET_OVERRIDE_OPTIONS is a good idea here.
> I need the override in the arm_option_override_internal function after
> the default has been set.
> 
> What do you think?
> 
> Thanks,
> 
> Andreas
> 
> 2015-12-23  Andreas Tobler  
> 
> * config/arm/freebsd.h: Rename SUBTARGET_OVERRIDE_OPTIONS to
> SUBTARGET_OVERRIDE_INTERNAL_OPTIONS. Adjust to check
> unaligned_access on the gcc_options set.
> * config/arm/arm.c (arm_option_override_internal): Use
> SUBTARGET_OVERRIDE_INTERNAL_OPTIONS.
> 
> 

This is OK.

One question, though, is whether you should explicitly override a user
request for unaligned accesses without at least warning that this is
being done.

R.

> 
> 
> 
> 
> 
> x_opts_unaligned2.diff
> 
> 
> Index: freebsd.h
> ===
> --- freebsd.h (revision 231903)
> +++ freebsd.h (working copy)
> @@ -120,10 +120,10 @@
>  #define SUBTARGET_CPU_DEFAULT   TARGET_CPU_arm9
>  #endif
>  
> -#define SUBTARGET_OVERRIDE_OPTIONS   \
> +#define SUBTARGET_OVERRIDE_INTERNAL_OPTIONS  \
>  do { \
> -if (unaligned_access)\
> - unaligned_access = 0;   \
> +if (opts->x_unaligned_access)\
> + opts->x_unaligned_access = 0;   \
>  } while (0)
>  
>  #undef MAX_SYNC_LIBFUNC_SIZE
> Index: arm.c
> ===
> --- arm.c (revision 231903)
> +++ arm.c (working copy)
> @@ -2954,6 +2954,10 @@
>/* Thumb2 inline assembly code should always use unified syntax.
>   This will apply to ARM and Thumb1 eventually.  */
>opts->x_inline_asm_unified = TARGET_THUMB2_P (opts->x_target_flags);
> +
> +#ifdef SUBTARGET_OVERRIDE_INTERNAL_OPTIONS
> +  SUBTARGET_OVERRIDE_INTERNAL_OPTIONS;
> +#endif
>  }
>  
>  /* Fix up any incompatible options that the user has specified.  */
> 

Re: [PATCH] libiberty: dupargv: rewrite to use xstrdup

[Ian Lance Taylor]

On Sat, Jan 2, 2016 at 10:36 PM, Mike Frysinger  wrote:
> This func is basically open coding the xstrdup function, so gut it
> and use it directly.
>
> 2016-01-03  Mike Frysinger  
>
> * argv.c (dupargv): Replace strlen/xmalloc/strcpy with xstrdup.

This is OK.  Thanks.

Ian

RE: [PATCH 1/4] [MIPS] Add support for MIPS SIMD Architecture (MSA)

[Robert Suchanek]

Hi,

Here is the updated patch for MSA.  The patch requires updated MSA tests
and preparatory patch that reorders function types.

Tested on mips-img-linux-gnu and mips-mti-linux-gnu.

Regards,
Robert

gcc/ChangeLog:

* config.gcc: Add MSA header file for mips*-*-* target.
* config/mips/constraints.md (YI, YC, YZ, Unv5, Uuv5, Usv5, Uuv6)
(Ubv8i, Urv8):  New constraints.
* config/mips/mips-ftypes.def: Add function types for MSA builtins.
* config/mips/mips-modes.def (V16QI, V8HI, V4SI, V2DI, V4SF, V2DF)
(V32QI, V16HI, V8SI, V4DI, V8SF, V4DF): New modes.
* config/mips/mips-msa.md: New file.
* config/mips/mips-protos.h
(mips_split_128bit_const_insns): New prototype.
(mips_msa_idiv_insns): Likewise.
(mips_split_128bit_move): Likewise.
(mips_split_128bit_move_p): Likewise.
(mips_split_msa_copy_d): Likewise.
(mips_split_msa_insert_d): Likewise.
(mips_split_msa_fill_d): Likewise.
(mips_expand_msa_branch): Likewise.
(mips_const_vector_same_val_p): Likewise.
(mips_const_vector_same_bytes_p): Likewise.
(mips_const_vector_same_int_p): Likewise.
(mips_const_vector_shuffle_set_p): Likewise.
(mips_const_vector_bitimm_set_p): Likewise.
(mips_const_vector_bitimm_clr_p): Likewise.
(mips_msa_vec_parallel_const_half): Likewise.
(mips_msa_output_division): Likewise.
(mips_ldst_scaled_shift): Likewise.
(mips_expand_vec_cond_expr): Likewise.
* config/mips/mips.c (enum mips_builtin_type): Add
MIPS_BUILTIN_MSA_TEST_BRANCH.
(mips_gen_const_int_vector_shuffle): New prototype.
(mips_const_vector_bitimm_set_p): New function.
(mips_const_vector_bitimm_clr_p): Likewise.
(mips_const_vector_same_val_p): Likewise.
(mips_const_vector_same_bytes_p): Likewise.
(mips_const_vector_same_int_p): Likewise.
(mips_const_vector_shuffle_set_p): Likewise.
(mips_symbol_insns): Forbid loading symbols via immediate for MSA.
(mips_valid_offset_p): Limit offset to 10-bit for MSA loads and stores.
(mips_valid_lo_sum_p): Forbid loadings symbols via %lo(base) for MSA.
(mips_lx_address_p): Add support load indexed address for MSA.
(mips_address_insns): Add calculation of instructions needed for
stores and loads for MSA.
(mips_const_insns): Move CONST_DOUBLE below CONST_VECTOR.  Handle
CONST_VECTOR for MSA and let it fall through.
(mips_ldst_scaled_shift): New function.
(mips_subword_at_byte): Likewise.
(mips_msa_idiv_insns): Likewise.
(mips_legitimize_move): Validate MSA moves.
(mips_rtx_costs): Add UNGE, UNGT, UNLE, UNLT cases.  Add calculation of
costs for MSA division.
(mips_split_move_p): Check if MSA moves need splitting.
(mips_split_move): Split MSA moves if necessary.
(mips_split_128bit_move_p): New function.
(mips_split_128bit_move): Likewise.
(mips_split_msa_copy_d): Likewise.
(mips_split_msa_insert_d): Likewise.
(mips_split_msa_fill_d): Likewise.
(mips_output_move): Handle MSA moves.
(mips_expand_msa_branch): New function.
(mips_print_operand): Add 'E', 'B', 'w', 'v' and 'V' modifiers.
Reinstate 'y' modifier.
(mips_file_start): Add MSA .gnu_attribute.
(mips_hard_regno_mode_ok_p): Allow TImode and 128-bit vectors in FPRs.
(mips_hard_regno_nregs): Always return 1 for MSA supported mode.
(mips_class_max_nregs): Add register size for MSA supported mode.
(mips_cannot_change_mode_class): Allow conversion between MSA vector
modes and TImode.
(mips_mode_ok_for_mov_fmt_p): Allow MSA to use move.v instruction.
(mips_secondary_reload_class): Force MSA loads/stores via memory.
(mips_preferred_simd_mode): Add preffered modes for MSA.
(mips_vector_mode_supported_p): Add MSA supported modes.
(mips_autovectorize_vector_sizes): New function.
(mips_msa_output_division): Likewise.
(MSA_BUILTIN, MIPS_BUILTIN_DIRECT_NO_TARGET, MSA_NO_TARGET_BUILTIN)
(MSA_BUILTIN_TEST_BRANCH): New macros.
(CODE_FOR_msa_adds_s_b, CODE_FOR_msa_adds_s_h, CODE_FOR_msa_adds_s_w)
(CODE_FOR_msa_adds_s_d, CODE_FOR_msa_adds_u_b, CODE_FOR_msa_adds_u_h)
(CODE_FOR_msa_adds_u_w, CODE_FOR_msa_adds_u_d, CODE_FOR_msa_addv_b)
(CODE_FOR_msa_addv_h, CODE_FOR_msa_addv_w, CODE_FOR_msa_addv_d)
(CODE_FOR_msa_and_v, CODE_FOR_msa_bmnz_v, CODE_FOR_msa_bmnzi_b)
(CODE_FOR_msa_bmz_v, CODE_FOR_msa_bmzi_b, CODE_FOR_msa_bnz_v)
(CODE_FOR_msa_bz_v, CODE_FOR_msa_bsel_v, CODE_FOR_msa_bseli_b)
(CODE_FOR_msa_ceqi_h, CODE_FOR_msa_ceqi_w, CODE_FOR_msa_ceqi_d)
(CODE_FOR_msa_clti_s_b, CODE_FOR_msa_clti_s_h, CODE_FOR_msa_clti_s_w)
(CODE_FOR_msa_clti_s_d, 

RE: [PATCH 3/4] Add support to run auto-vectorization tests for multiple effective targets

[Robert Suchanek]

Ping.

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
> Behalf Of Robert Suchanek
> Sent: 10 August 2015 13:15
> To: catherine_mo...@mentor.com; Matthew Fortune
> Cc: gcc-patches@gcc.gnu.org
> Subject: [PATCH 3/4] Add support to run auto-vectorization tests for multiple
> effective targets
> 
> Hi,
> 
> This patch allows to run auto-vectorization tests for more than one effective
> target.  The initial proposal
> 
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02289.html
> 
> had some issues that have been addressed and should work as expected now.
> 
> The idea was to add a wrapper procedure that would:
> 1. Iterative over a list of EFFECTIVE_TARGETS e.g. mips_msa, mpaired_single.
> 2. Add necessary compile time options for each effective target.
> 3. Check if it's possible to compile and/or run on a target, and set
>dg-do-what-default accordingly.
> 4. Set the target index to tell check_effective_target_vect_* which target is
>currently being processed.
> 5. Invoke {gfortran-,g++-,}dg-runtest with the list of vector tests as normal.
> 
> The above required that every vector feature e.g. vect_int that caches the
> result is
> capable of tracking what target supports a feature.  The result is saved to a
> list
> at an index controlled by the wrapper (et-dg-runtest).  Ports not using this
> feature,
> set DEFAULT_VECTFLAGS and the tests should run as they used to.
> 
> The patch was additionally tested on x86_64-unknown-linux-gnu and aarch64-
> linux-gnu.
> 
> Regards,
> Robert
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/vect/vect.exp: Add and set new global EFFECTIVE_TARGETS. Call
>   g++-dg-runtest via et-dg-runtest.
>   * gcc.dg/graphite/graphite.exp: Likewise, but for dg-runtest.
>   * gcc.dg/vect/vect.exp: Likewise.
>   * gfortran.dg/graphite/graphite.exp: Likewise, but for
>   gfortran-dg-runtest.
>   * gfortran.dg/vect/vect.exp: Likewise.
>   * lib/target-supports.exp (check_mpaired_single_hw_available): New.
>   (check_mips_loongson_hw_available): Likewise.
>   (check_effective_target_mpaired_single_runtime): Likewise.
>   (check_effective_target_mips_loongson_runtime): Likewise.
>   (add_options_for_mpaired_single): Likewise.
>   (check_effective_target_vect_int): Add global et_index.
>   Check and save the supported feature for a target selected by
>   the et_index target.  Break long lines where appropriate.  Call
>   et-is-effective-target for MIPS with an argument instead of
>   check_effective_target_* where appropriate.
>   (check_effective_target_vect_intfloat_cvt): Likewise.
>   (check_effective_target_vect_uintfloat_cvt): Likewise.
>   (check_effective_target_vect_floatint_cvt): Likewise.
>   (check_effective_target_vect_floatuint_cvt): Likewise.
>   (check_effective_target_vect_simd_clones): Likewise.
>   (check_effective_target_vect_shift): ewise.
>   (check_effective_target_whole_vector_shift): Likewise.
>   (check_effective_target_vect_bswap): Likewise.
>   (check_effective_target_vect_shift_char): Likewise.
>   (check_effective_target_vect_long): Likewise.
>   (check_effective_target_vect_float): Likewise.
>   (check_effective_target_vect_double): Likewise.
>   (check_effective_target_vect_long_long): Likewise.
>   (check_effective_target_vect_no_int_max): Likewise.
>   (check_effective_target_vect_no_int_add): Likewise.
>   (check_effective_target_vect_no_bitwise): Likewise.
>   (check_effective_target_vect_widen_shift): Likewise.
>   (check_effective_target_vect_no_align): Likewise.
>   (check_effective_target_vect_hw_misalign): Likewise.
>   (check_effective_target_vect_element_align): Likewise.
>   (check_effective_target_vect_condition): Likewise.
>   (check_effective_target_vect_cond_mixed): Likewise.
>   (check_effective_target_vect_char_mult): Likewise.
>   (check_effective_target_vect_short_mult): Likewise.
>   (check_effective_target_vect_int_mult): Likewise.
>   (check_effective_target_vect_extract_even_odd): Likewise.
>   (check_effective_target_vect_interleave): Likewise.
>   (check_effective_target_vect_stridedN): Likewise.
>   (check_effective_target_vect_multiple_sizes): Likewise.
>   (check_effective_target_vect64): Likewise.
>   (check_effective_target_vect_call_copysignf): Likewise.
>   (check_effective_target_vect_call_sqrtf): Likewise.
>   (check_effective_target_vect_call_lrint): Likewise.
>   (check_effective_target_vect_call_btrunc): Likewise.
>   (check_effective_target_vect_call_btruncf): Likewise.
>   (check_effective_target_vect_call_ceil): Likewise.
>   (check_effective_target_vect_call_ceilf): Likewise.
>   (check_effective_target_vect_call_floor): Likewise.
>   (check_effective_target_vect_call_floorf): Likewise.
>   (check_effective_target_vect_call_lceil): 

Re: [PATCH 2/4] Equate MEM_REFs and ARRAY_REFs in tree-ssa-scopedtables.c

[Alan Lawrence]

On 05/01/16 07:29, Richard Biener wrote:

On January 4, 2016 8:08:17 PM GMT+01:00, Jeff Law  wrote:

On 12/21/2015 06:13 AM, Alan Lawrence wrote:

This is a respin of patches
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03266.html and
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03267.html, which were
"too quickly" approved before concerns with efficiency were pointed

out.


I tried to change the hashing just in tree-ssa-dom.c using C++

subclassing, but

couldn't cleanly separate this out from tree-ssa-scopedtables and
tree-ssa-threadedge.c due to use of avail_exprs_stack. So I figured

it was

probably appropriate to use the equivalences in jump threading too.

Also,

using get_ref_base_and_extent unifies handling of MEM_REFs and

ARRAY_REFs


Without looking at the patch, ARRAY_REFs can have non-constant indices which 
get_ref_base_and_extend handles conservative.  You should make sure to not 
regress here.


Thanks for the warning - my understanding is that in such a case, 
get_ref_base_and_extent returns max_size=(size of the whole array), size=(size 
of one element); and I only handle cases where size==max_size. Arrays of unknown 
length have size -1, so will never be equal.


Thanks, Alan

Re: adjust fallback_frame_state for 32bits AIX 7.1

[David Edelsohn]

On Tue, Jan 5, 2016 at 6:15 AM, Olivier Hainque  wrote:
> Hello,
>
> This is a tiny change we have been using successfully for at least a couple
> of years now, improving exception propagation through signal handlers on 
> 32bits
> AIX 7.1.
>
> While this isn't a complete generalization to all possible configurations
> (haven't had the time to converge on 64bits kernels at this stage, 
> unfortunately),
> this is nevertheless an improvement on 32bits.

There are no 32 bit kernels for AIX 7.1.  This is the signal handler
path for 32 bit environment, but there are no 32 bit kernels.

>
> The patch is very short and in line with what is already there, and we thought
> it might be useful to others as well.
>
> OK to commit ?
>
> 2015-01-05  Olivier Hainque  
>
> libgcc/
> * config/rs6000/aix-unwind.h (ucontext_for): Handle AIX 7.1
> specificities.

Okay.

Thanks, David

Re: adjust fallback_frame_state for 32bits AIX 7.1

[Olivier Hainque]

> On Jan 5, 2016, at 17:33 , David Edelsohn  wrote:

> There are no 32 bit kernels for AIX 7.1.  This is the signal handler
> path for 32 bit environment, but there are no 32 bit kernels.

OK, thanks for correcting.

>> The patch is very short and in line with what is already there, and we 
>> thought
>> it might be useful to others as well.
>> 
>> OK to commit ?
>> 
>> 2015-01-05  Olivier Hainque  
>> 
>> libgcc/
>>* config/rs6000/aix-unwind.h (ucontext_for): Handle AIX 7.1
>>specificities.
> 
> Okay.

Thanks!

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68841: Make sure one basic block doesn't clobber CC reg usage of the other

[Kyrill Tkachov]

On 05/01/16 16:34, Bernd Schmidt wrote:

On 01/05/2016 03:22 PM, Kyrill Tkachov wrote:


This works around the issue but we don't want to do perform the check
for pairs of
simple basic blocks because then we'll end up rejecting code that does
things like:
x = cond ? x + 1 : x - 1
i.e. source of the set in both blocks reads and writes the same register.
We can deal with this safely later on in the function since we rename
the destinations
of the two sets, so we don't want to reject this case here.


So we need to teach bbs_ok_for_cmove_arith that this is going to happen. How 
about the approach below? Still seems to fix the issue, and it looks like the 
CC set is present in the df info so everything should work as intended. Right?



Yeah, this looks like it works.
However, now we reject if-conversion whereas with my patch we still tried 
switching the order in which
the blocks were emitted, which allowed for a bit more aggressive if-conversion.
I don't know if this approach is overly restrictive yet.
I'll try its effects on codegen quality on SPEC as soon as I get some cycles.
But this approach does look appealing to me.

Thanks for the help,
Kyrill



Bernd

Re: [PATCH v2] ia64: don't use dynamic relocations for local symbols

[Jeff Law]

On 01/05/2016 02:39 AM, Eric Botcazou wrote:

'make bootstrap' works fine on ia64 but I've failed to run 'make check'.
Testsuite's LD_LIBRARY_PATHs are not correct and can run tests.


You need to run 'make -k check' from the top level build directory.
No worries.  I had an ia64 box provisioned when I looked at this and I 
just let it run the regression tests overnight.  Everything looks good.


jeff

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

[H.J. Lu]

On Mon, Dec 14, 2015 at 2:08 PM, H.J. Lu  wrote:
> On Mon, Dec 14, 2015 at 12:43 PM, Jason Merrill  wrote:
>> On 12/14/2015 03:39 PM, H.J. Lu wrote:
>>>
>>> On Mon, Dec 14, 2015 at 12:16 PM, Jason Merrill  wrote:

 On 12/12/2015 01:42 PM, Marc Glisse wrote:
>
>
> On Sat, 12 Dec 2015, Jakub Jelinek wrote:
>
>> On Sat, Dec 12, 2015 at 09:51:23AM -0500, Jason Merrill wrote:
>>>
>>>
>>> On 12/11/2015 06:52 PM, H.J. Lu wrote:


 On Thu, Dec 10, 2015 at 3:24 AM, Richard Biener
  wrote:
>
>
> On Wed, Dec 9, 2015 at 10:31 PM, Markus Trippelsdorf
>  wrote:
>>
>>
>> On 2015.12.09 at 10:53 -0800, H.J. Lu wrote:
>>>
>>>
>>>
>>> Empty C++ class is a corner case which isn't covered in psABI nor
>>> C++ ABI.
>>> There is no mention of "empty record" in GCC documentation.  But
>>> there are
>>> plenty of "empty class" in gcc/cp.  This change affects all
>>> targets.  C++ ABI
>>> should specify how it should be passed.
>
>
>
>
> About this patch, aren't we supposed to enable new C++ ABIs with
> -fabi-version=42 (or whatever the next number is)?



 Yes, the patch should definitely make this conditional on
 abi_version_at_least.

>> There is a C++ ABI mailinglist, where you could discuss this issue:
>> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
>
>
>
> Yep.  As long as the ABI doesn't state how to pass those I'd rather
> _not_ change GCCs way.



 It is agreed that GCC is wrong on this:



 http://sourcerytools.com/pipermail/cxx-abi-dev/2015-December/002876.html

>>>
>>> Yes, I think this is just a (nasty) bug on some GCC targets.
>>
>>
>>
>> Well, the argument in that thread is weird, because C and C++ empty
>> structs
>> are different, so it isn't surprising they are passed differently.
>> C++ makes those sizeof == 1, while C has them sizeof == 0.
>
>
>
> Maybe it isn't surprising, but it isn't particularly helpful either. It
> increases the number of places where the 2 are incompatible.
> (I personally don't care about empty C structs)



 Yep.  The C standard doesn't have empty structs; it's a GNU extension.
 But
 in any case argument passing can be compatible between C and C++, so it
 really should be.


>>>
>>> Before I make any changes, I'd like to ask if we should make
>>> argument passing can be compatible between C and C++ for
>>> all targets GCC support or just x86.
>>
>>
>> All.
>
> Here is the patch to guard this ABI change with the ABI level 10,
> which is updated in GCC 6.  OK for master if there is no regression
> on x86?
>
> The patch for non-x86 targets is at
>
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01063.html
>

PING:

https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01444.html

-- 
H.J.

Re: [PATCH, rs6000] Fix PR target/68872, make -mcpu=powerpc64le pass correct assembler option

[Peter Bergner]

On Thu, 2015-12-24 at 10:15 -0800, Mike Stump wrote:
> On Dec 22, 2015, at 9:13 AM, Peter Bergner 
> > gcc/testsuite/
> >PR target/68772
> 
> Likewise.  Please retroactively update the number in the changelog.

Wow, thanks for catching this!  Fixed everywhere.

Peter

[PATCH][MIPS] Reorder function types

[Robert Suchanek]

Hi,

The following patch reorders some of the function types to follow 
lexicographical order.

This patch should go in before the MSA patch.

Regards,
Robert


gcc/
* config/mips/mips-ftypes.def: Sort to lexicographical order.
---
 gcc/config/mips/mips-ftypes.def | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/config/mips/mips-ftypes.def b/gcc/config/mips/mips-ftypes.def
index d56accc..e1656ee 100644
--- a/gcc/config/mips/mips-ftypes.def
+++ b/gcc/config/mips/mips-ftypes.def
@@ -42,6 +42,7 @@ DEF_MIPS_FTYPE (3, (DI, DI, SI, SI))
 DEF_MIPS_FTYPE (3, (DI, DI, USI, USI))
 DEF_MIPS_FTYPE (3, (DI, DI, V2HI, V2HI))
 DEF_MIPS_FTYPE (3, (DI, DI, V4QI, V4QI))
+DEF_MIPS_FTYPE (2, (DI, POINTER, SI))
 DEF_MIPS_FTYPE (2, (DI, SI, SI))
 DEF_MIPS_FTYPE (2, (DI, USI, USI))
 
@@ -50,9 +51,12 @@ DEF_MIPS_FTYPE (2, (INT, SF, SF))
 DEF_MIPS_FTYPE (2, (INT, V2SF, V2SF))
 DEF_MIPS_FTYPE (4, (INT, V2SF, V2SF, V2SF, V2SF))
 
+DEF_MIPS_FTYPE (1, (SF, SF))
+DEF_MIPS_FTYPE (2, (SF, SF, SF))
+DEF_MIPS_FTYPE (1, (SF, V2SF))
+
 DEF_MIPS_FTYPE (2, (SI, DI, SI))
 DEF_MIPS_FTYPE (2, (SI, POINTER, SI))
-DEF_MIPS_FTYPE (2, (DI, POINTER, SI))
 DEF_MIPS_FTYPE (1, (SI, SI))
 DEF_MIPS_FTYPE (2, (SI, SI, SI))
 DEF_MIPS_FTYPE (3, (SI, SI, SI, SI))
@@ -62,10 +66,6 @@ DEF_MIPS_FTYPE (1, (SI, V4QI))
 DEF_MIPS_FTYPE (2, (SI, V4QI, V4QI))
 DEF_MIPS_FTYPE (1, (SI, VOID))
 
-DEF_MIPS_FTYPE (1, (SF, SF))
-DEF_MIPS_FTYPE (2, (SF, SF, SF))
-DEF_MIPS_FTYPE (1, (SF, V2SF))
-
 DEF_MIPS_FTYPE (2, (UDI, UDI, UDI))
 DEF_MIPS_FTYPE (2, (UDI, UV2SI, UV2SI))
 
@@ -76,9 +76,9 @@ DEF_MIPS_FTYPE (2, (UV2SI, UV2SI, UV2SI))
 
 DEF_MIPS_FTYPE (2, (UV4HI, UV4HI, UQI))
 DEF_MIPS_FTYPE (2, (UV4HI, UV4HI, USI))
+DEF_MIPS_FTYPE (2, (UV4HI, UV4HI, UV4HI))
 DEF_MIPS_FTYPE (3, (UV4HI, UV4HI, UV4HI, UQI))
 DEF_MIPS_FTYPE (3, (UV4HI, UV4HI, UV4HI, USI))
-DEF_MIPS_FTYPE (2, (UV4HI, UV4HI, UV4HI))
 DEF_MIPS_FTYPE (1, (UV4HI, UV8QI))
 DEF_MIPS_FTYPE (2, (UV4HI, UV8QI, UV8QI))
 
-- 
2.4.5

RE: [PATCH 1/4] [MIPS] Add support for MIPS SIMD Architecture (MSA)

[Robert Suchanek]

Hi,

Comments inlined.

> >diff --git a/gcc/config/mips/constraints.md b/gcc/config/mips/constraints.md
> >index 7d1a8ba..cde0196 100644
> >--- a/gcc/config/mips/constraints.md
> >+++ b/gcc/config/mips/constraints.md
> >@@ -308,6 +308,53 @@ (define_constraint "Yx"
> >"@internal"
> >(match_operand 0 "low_bitmask_operand"))
> >
> >+(define_constraint "YI"
> >+  "@internal
> >+   A replicated vector const in which the replicated is a 10-bit signed
> value."
> 
> replicated value is in the range [-512,511].

Done.
> 
> >+(define_constraint "Unv5"
> >+  "@internal
> >+   A replicated vector const in which the replicated value is a negative
> >+   integer number in range [-31,0]."
> 
> Stick with similar phrasing throughout: replicated value is in the range...
> 
> >+  (and (match_code "const_vector")
> >+   (match_test "mips_const_vector_same_int_p (op, mode, -31, 0)")))
> >+
> >+(define_constraint "Uuv5"
> >+  "@internal
> >+   A replicated vector const in which the replicated value is a positive
> >+   integer number in range [0,31]."
> >+  (and (match_code "const_vector")
> >+   (match_test "mips_const_vector_same_int_p (op, mode, 0, 31)")))
> 
> likewise.
> 
> >+(define_constraint "Uuv6"
> >+  "@internal
> >+   A replicated vector const in which the replicated value is an unsigned
> >+   6-bit integer number."
> >+  (and (match_code "const_vector")
> >+   (match_test "mips_const_vector_same_int_p (op, mode, 0, 63)")))
> 
> likewise.

Done.
> 
> >+(define_constraint "Ubv8"
> >+  "@internal
> >+   A replicated vector const in which the replicated value is an 8-bit 
> >byte."
> 
> A replicated vector const.
> 
> (see below)...
> 
> >+  (and (match_code "const_vector")
> >+   (match_test "mips_const_vector_same_byte_p (op, mode)")))
> 
> This is no different from mips_const_vector_same_val_p excep for a mode
> assertion. This constraint may as well just verify that all elements are the
> same value and I think we can reasonably expect that you can't construct
> a V16QI vec_const with values outside of an 8-bit range. Perhaps call it
> Uxvx to indicate it is just checking mode width. Obviously this cannot be
> used in a context where an immediate is implicitly sign extended but that
> is what the other constraints are for.
> You can then delete mips_const_vector_same_byte_p.

I was going to follow this change as suggested but changed the constraint
name to "Urv8" and used mips_const_vector_same_bytes_p.  The constraint
represents a replicated byte values regardless of the mode.  This change
followed comments for mips-msa.md.

> 
> >diff --git a/gcc/config/mips/mips-ftypes.def 
> >b/gcc/config/mips/mips-ftypes.def
> >index d56accc..29ef33c 100644
> >--- a/gcc/config/mips/mips-ftypes.def
> >+++ b/gcc/config/mips/mips-ftypes.def
> >@@ -36,6 +36,226 @@ along with GCC; see the file COPYING3.  If not see
> > DEF_MIPS_FTYPE (1, (DF, DF))
> > DEF_MIPS_FTYPE (2, (DF, DF, DF))
> >
> >+DEF_MIPS_FTYPE (2, (V16QI, V16QI, V16QI))
> 
> ...
> 
> Please sort these as the file requests towards the top. I have not checked
> these are all needed but am assuming they are.

Done. I found some unused types. I will send another patch as some of the 
entries
were not sorted before MSA.

> 
> Thanks,
> Matthew

Regards,
Robert

Re: [PATCH 2/4] Equate MEM_REFs and ARRAY_REFs in tree-ssa-scopedtables.c

[Jeff Law]

On 01/05/2016 09:29 AM, Alan Lawrence wrote:

Without looking at the patch, ARRAY_REFs can have non-constant indices
which get_ref_base_and_extend handles conservative.  You should make
sure to not regress here.


Thanks for the warning - my understanding is that in such a case,
get_ref_base_and_extent returns max_size=(size of the whole array),
size=(size of one element); and I only handle cases where
size==max_size. Arrays of unknown length have size -1, so will never be
equal.
That was my understanding as well -- I'd been looking at that mostly in 
terms of making sure we were hashing the right stuff and that we were 
checking the right stuff in the equality function.


jeff

RE: [PATCH][MIPS] Reorder function types

[Moore, Catherine]

> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Tuesday, January 05, 2016 11:45 AM
> To: Robert Suchanek; Moore, Catherine
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH][MIPS] Reorder function types
> 
> Robert Suchanek  writes:
> > gcc/
> > * config/mips/mips-ftypes.def: Sort to lexicographical order.
> 
> The patch is fine. I don't know what we can/should commit at this stage.
> Catherine: Any idea what is acceptable? I'd think this kind of small change to
> be OK and make it easier to maintain MSA out of tree given I doubt it can be
> committed now.
> 
This is fine to commit now.

RE: [PATCH 1/4] [MIPS] Add support for MIPS SIMD Architecture (MSA)

[Robert Suchanek]

Hi,

Comments inlined. The updated patch will be sent in another email
as this message is already long.

> Hi Robert,
> 
> Next batch of comments. This set covers the rest of mips-msa.md.
> 
> >+++ b/gcc/config/mips/mips-msa.md
> >+(define_expand "vec_perm"
> >+  [(match_operand:MSA 0 "register_operand")
> >+   (match_operand:MSA 1 "register_operand")
> >+   (match_operand:MSA 2 "register_operand")
> >+   (match_operand: 3 "register_operand")]
> >+  "ISA_HAS_MSA"
> >+{
> >+  /* The optab semantics are that index 0 selects the first element
> >+ of operands[1] and the highest index selects the last element
> >+ of operands[2].  This is the oppossite order from "vshf.df wd,rs,wt"
> >+ where index 0 selects the first element of wt and the highest index
> >+ selects the last element of ws.  We therefore swap the operands here.
> */
> >+  emit_insn (gen_msa_vshf (operands[0], operands[3], operands[2],
> >+ operands[1]));
> >+  DONE;
> >+})
> 
> Can you make this the real instruction instead of msa_vshf and give it a
> proper pattern (vec_select, vec_concat) etc. Swap the builtin to target
> this pattern and swap the operands for the builtin expansion in C code
> like you have done for some other patterns.

Done.

> 
> >+(define_expand "neg2"
> >+  [(match_operand:IMSA 0 "register_operand")
> >+   (match_operand:IMSA 1 "register_operand")]
> >+  "ISA_HAS_MSA"
> >+{
> >+  rtx reg = gen_reg_rtx (mode);
> >+  emit_insn (gen_msa_ldi (reg, const0_rtx));
> >+  emit_insn (gen_sub3 (operands[0], reg, operands[1]));
> >+  DONE;
> >+})
> >+
> >+(define_expand "neg2"
> >+  [(match_operand:FMSA 0 "register_operand")
> >+   (match_operand:FMSA 1 "register_operand")]
> >+  "ISA_HAS_MSA"
> >+{
> >+  rtx reg = gen_reg_rtx (mode);
> >+  emit_move_insn (reg, CONST0_RTX (mode));
> >+  emit_insn (gen_sub3 (operands[0], reg, operands[1]));
> >+  DONE;
> >+})
> 
> Can't these two collapse into one like this?
> 
> (define_expand "neg2"
>   [(set (match_operand:MSA 0 "register_operand")
> (minus:MSA (match_dup 2)
>(match_operand:MSA 1 "register_operand")))]
>   "ISA_HAS_MSA"
> {
>   operands[2] = CONST0_RTX (mode);
> })
> 
> I'd hope the const_vector then gets emitted as an LDI? I haven't
> checked that there is a pattern for using LDI for FP const_vector
> moves.

Done with minor changes. The above is close but we still need
the CONST0_RTX to be placed in a register as we won't match the sub
pattern.

> 
> >+(define_expand "msa_ldi"
> >+  [(match_operand:IMSA 0 "register_operand")
> >+   (match_operand 1 "const_imm10_operand")]
> >+  "ISA_HAS_MSA"
> >+{
> >+  unsigned n_elts = GET_MODE_NUNITS (mode);
> >+  rtvec v = rtvec_alloc (n_elts);
> >+  HOST_WIDE_INT val = INTVAL (operands[1]);
> >+  unsigned int i;
> >+
> >+  if (mode != V16QImode)
> >+{
> >+  unsigned shift = HOST_BITS_PER_WIDE_INT - 10;
> >+  val = trunc_int_for_mode ((val << shift) >> shift, mode);
> >+}
> >+  else
> >+val = trunc_int_for_mode (val, mode);
> >+
> >+  for (i = 0; i < n_elts; i++)
> >+RTVEC_ELT (v, i) = GEN_INT (val);
> >+  emit_move_insn (operands[0],
> >+  gen_rtx_CONST_VECTOR (mode, v));
> >+  DONE;
> >+})
> 
> This is really weird. We shouldn't be simply discarding bits that don't fit.
> This needs to accept all immediates and generate the correct code to
> get a replicated constant of that value into a register. I think it is
> probably OK to trunc_int_for_mode on the original 'val' for the
> mode but anything out of range for V*HI/SI/DI needs to be expanded
> properly.
> 
> Please do not gen_msa_ldi anywhere other than from MSA builtins. There is
> no need just emit a move directly.

AFAICS, the truncation for everything except V16QImode is not needed
since we have the predicate here. Truncating the immediate for bytes may make
life easier for users when debugging. Although the extra bits are ignored by
the hardware, it doesn't stop us from encoding numbers out of range.
The RTL doesn't seem to have validation of ranges of constants and modes.
I did a small test and could output any number within the allowable range
in the predicate.

> 
> >+(define_insn "msa_vshf"
> >+  [(set (match_operand:MSA 0 "register_operand" "=f")
> >+(unspec:MSA [(match_operand: 1 "register_operand" "0")
> >+ (match_operand:MSA 2 "register_operand" "f")
> >+ (match_operand:MSA 3 "register_operand" "f")]
> >+UNSPEC_MSA_VSHF))]
> >+  "ISA_HAS_MSA"
> >+  "vshf.\t%w0,%w2,%w3"
> >+  [(set_attr "type" "simd_sld")
> >+   (set_attr "mode" "")])
> 
> Delete this and switch to using vec_perm directly instead for the builtin.

Done.

> 
> >+;; 128bit MSA modes only in msa registers or memory.  An exception is
> allowing
> 
> 128-bit MSA modes can only exist in MSA registers or memory. ...

Done.

> 
> >+;; Offset load
> >+(define_expand "msa_ld_"
> >+  [(match_operand:MSA 0 "register_operand")
> >+   (match_operand 1 

RE: [PATCH 1/4] [MIPS] Add support for MIPS SIMD Architecture (MSA)

[Robert Suchanek]

Hi,

Comments inlined.

> >+;; The attribute gives half modes for vector modes.
> >+(define_mode_attr VHMODE
> >+  [(V8HI "V16QI")
> >+   (V4SI "V8HI")
> >+   (V2DI "V4SI")
> >+   (V2DF "V4SF")])
> >+
> >+;; The attribute gives double modes for vector modes.
> >+(define_mode_attr VDMODE
> >+  [(V4SI "V2DI")
> >+   (V8HI "V4SI")
> >+   (V16QI "V8HI")])
> 
> Presumably there is a reason why this is not a mirror of VHMODE. I.e. it does
> not have floating point modes?

This is a mistake. The floating point mode in VHMODE is never used. Removed.

> >+;; The attribute gives half modes with same number of elements for vector
> modes.
> >+(define_mode_attr TRUNCMODE
> >+  [(V8HI "V8QI")
> >+   (V4SI "V4HI")
> >+   (V2DI "V2SI")])
> >+
> >+;; This attribute gives the mode of the result for "copy_s_b, copy_u_b" etc.
> >+(define_mode_attr RES
> >+  [(V2DF "DF")
> >+   (V4SF "SF")
> >+   (V2DI "DI")
> >+   (V4SI "SI")
> >+   (V8HI "SI")
> >+   (V16QI "SI")])
> 
> Verhaps prefix these with a 'V' to clarify they are vector mode attributes.

Done.


> >+;; This attribute gives define_insn suffix for MSA instructions with need
> 
> with => that need

Fixed.

> >+;; distinction between integer and floating point.
> >+(define_mode_attr msafmt_f
> >+  [(V2DF "d_f")
> >+   (V4SF "w_f")
> >+   (V2DI "d")
> >+   (V4SI "w")
> >+   (V8HI "h")
> >+   (V16QI "b")])
> >+
> >+;; To represent bitmask needed for vec_merge using 
> >"const__operand".
> 
> Commenting style is different here. Everything else starts with: This 
> attribute
> ...

Changed.
> 
> >+(define_mode_attr bitmask
> >+  [(V2DF "exp_2")
> >+   (V4SF "exp_4")
> >+   (V2DI "exp_2")
> >+   (V4SI "exp_4")
> >+   (V8HI "exp_8")
> >+   (V16QI "exp_16")])
> >+
> >+;; This attribute used to form an immediate operand constraint using
> 
> used to => is used to

Fixed.

> 
> >+;; "const__operand".
> >+(define_mode_attr bitimm
> >+  [(V16QI "uimm3")
> >+   (V8HI  "uimm4")
> >+   (V4SI  "uimm5")
> >+   (V2DI  "uimm6")
> >+  ])
> >+
> 
> >+(define_expand "fixuns_trunc2"
> >+  [(set (match_operand: 0 "register_operand" "=f")
> >+(unsigned_fix: (match_operand:FMSA 1 "register_operand" "f")))]
> >+  "ISA_HAS_MSA"
> >+{
> >+  emit_insn (gen_msa_ftrunc_u_ (operands[0], operands[1]));
> >+  DONE;
> >+})
> 
> The msa_ftrunc_u_* define_insns should just be renamed to use the standard
> pattern names and, more importantly, standard RTL not UNSPEC.

Renamed, define_expands removed. I also replaced FINT with VIMODE and removed
FINT mode attribute to avoid duplication.  
> 
> >+
> >+(define_expand "fix_trunc2"
> >+  [(set (match_operand: 0 "register_operand" "=f")
> >+(fix: (match_operand:FMSA 1 "register_operand" "f")))]
> >+  "ISA_HAS_MSA"
> >+{
> >+  emit_insn (gen_msa_ftrunc_s_ (operands[0], operands[1]));
> >+  DONE;
> >+})
> 
> Likewise.
> 
> >+
> >+(define_expand "vec_pack_trunc_v2df"
> >+  [(set (match_operand:V4SF 0 "register_operand")
> >+(vec_concat:V4SF
> >+  (float_truncate:V2SF (match_operand:V2DF 1 "register_operand"))
> >+  (float_truncate:V2SF (match_operand:V2DF 2 "register_operand"]
> >+  "ISA_HAS_MSA"
> >+  "")
> 
> Rename msa_fexdo_w to vec_pack_trunc_v2df.
> 
> I see that fexdo has a 'halfword' variant which creates a half-float. What
> else can operate on half-float and should this really be recorded as an
> HFmode?
> 
> >+(define_expand "vec_unpacks_hi_v4sf"
> >+  [(set (match_operand:V2DF 0 "register_operand" "=f")
> >+(float_extend:V2DF
> >+  (vec_select:V2SF
> >+(match_operand:V4SF 1 "register_operand" "f")
> >+(parallel [(const_int 0) (const_int 1)])
> 
> If we swap the (parallel) for a match_operand 2...
> 
> >+  )))]
> >+  "ISA_HAS_MSA"
> >+{
> >+  if (BYTES_BIG_ENDIAN)
> >+emit_insn (gen_msa_fexupr_d (operands[0], operands[1]));
> >+  else
> >+emit_insn (gen_msa_fexupl_d (operands[0], operands[1]));
> 
> Then these two could change to set up operands[2] with either
> a parallel of 0/1 or 2/3 and then...
> 
> You could change the fexupr_d and fexupl_d insn patterns to use normal RTL
> that select the appropriate elements (either 0/1 and 2/3).
> 
> >+  DONE;
> 
> Which means the RTL in the pattern would be used to expand this and
> you would remove the DONE. As it stands the pattern on this expand
> is simply never used.

Reworked. The parallel expression for operands[2] is now generated.

> 
> >+})
> >+
> >+(define_expand "vec_unpacks_lo_v4sf"
> >+  [(set (match_operand:V2DF 0 "register_operand" "=f")
> >+(float_extend:V2DF
> >+  (vec_select:V2SF
> >+(match_operand:V4SF 1 "register_operand" "f")
> >+(parallel [(const_int 0) (const_int 1)])
> >+  )))]
> >+  "ISA_HAS_MSA"
> >+{
> >+  if (BYTES_BIG_ENDIAN)
> >+emit_insn (gen_msa_fexupl_d (operands[0], operands[1]));
> >+  else
> >+emit_insn (gen_msa_fexupr_d (operands[0], operands[1]));
> >+  DONE;
> >+})
> 
> Likewise but inverted.

As above.

> 
> >+
> >+(define_expand "vec_unpacks_hi_"
> >+  [(set (match_operand: 0 

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68841: Make sure one basic block doesn't clobber CC reg usage of the other

[Bernd Schmidt]

On 01/05/2016 03:22 PM, Kyrill Tkachov wrote:


This works around the issue but we don't want to do perform the check
for pairs of
simple basic blocks because then we'll end up rejecting code that does
things like:
x = cond ? x + 1 : x - 1
i.e. source of the set in both blocks reads and writes the same register.
We can deal with this safely later on in the function since we rename
the destinations
of the two sets, so we don't want to reject this case here.


So we need to teach bbs_ok_for_cmove_arith that this is going to happen. 
How about the approach below? Still seems to fix the issue, and it looks 
like the CC set is present in the df info so everything should work as 
intended. Right?



Bernd
Index: gcc/ifcvt.c
===
--- gcc/ifcvt.c	(revision 232056)
+++ gcc/ifcvt.c	(working copy)
@@ -1866,11 +1866,13 @@ insn_valid_noce_process_p (rtx_insn *ins
 }
 
 
-/* Return true iff the registers that the insns in BB_A set do not
-   get used in BB_B.  */
+/* Return true iff the registers that the insns in BB_A set do not get
+   used in BB_B.  WILL_RENAME is true if we expect that BB_A consists
+   of a single single_set insn with a destination that the caller will
+   rename to a new pseudo.  */
 
 static bool
-bbs_ok_for_cmove_arith (basic_block bb_a, basic_block bb_b)
+bbs_ok_for_cmove_arith (basic_block bb_a, basic_block bb_b, bool will_rename)
 {
   rtx_insn *a_insn;
   bitmap bba_sets = BITMAP_ALLOC (_obstack);
@@ -1887,13 +1889,15 @@ bbs_ok_for_cmove_arith (basic_block bb_a
 
   if (!sset_a)
 	{
+	  gcc_assert (!will_rename);
 	  BITMAP_FREE (bba_sets);
 	  return false;
 	}
 
   /* Record all registers that BB_A sets.  */
   FOR_EACH_INSN_DEF (def, a_insn)
-	bitmap_set_bit (bba_sets, DF_REF_REGNO (def));
+	if (!will_rename || DF_REF_REG (def) != SET_DEST (sset_a))
+	  bitmap_set_bit (bba_sets, DF_REF_REGNO (def));
 }
 
   rtx_insn *b_insn;
@@ -2082,9 +2086,9 @@ noce_try_cmove_arith (struct noce_if_inf
 	}
 }
 
-  if (then_bb && else_bb && !a_simple && !b_simple
-  && (!bbs_ok_for_cmove_arith (then_bb, else_bb)
-	  || !bbs_ok_for_cmove_arith (else_bb, then_bb)))
+  if (then_bb && else_bb
+  && (!bbs_ok_for_cmove_arith (then_bb, else_bb, a_simple)
+	  || !bbs_ok_for_cmove_arith (else_bb, then_bb, b_simple)))
 return FALSE;
 
   start_sequence ();

RE: [PATCH][MIPS] Reorder function types

[Matthew Fortune]

Robert Suchanek  writes:
> gcc/
>   * config/mips/mips-ftypes.def: Sort to lexicographical order.

The patch is fine. I don't know what we can/should commit at this stage.
Catherine: Any idea what is acceptable? I'd think this kind of small change
to be OK and make it easier to maintain MSA out of tree given I doubt it
can be committed now.

Thanks,
Matthew

Re: [Ping^2][PATCH][GCC][ARM] testcase memset-inline-10.c uses -mfloat-abi=hard but does not check whether target supports it

[Andre Vieira]

On 27/11/15 14:28, Andre Vieira wrote:

On 12/11/15 15:16, Andre Vieira wrote:

On 12/11/15 15:08, Andre Vieira wrote:

Hi,

   This patch changes the memset-inline-10.c testcase to make sure that
it is only compiled for ARM targets that support -mfloat-abi=hard using
the fact that all non-thumb1 targets do.

   This is correct because all targets for which -mthumb causes the
compiler to use thumb2 will support the generation of FP instructions.

   Tested by running regressions for this testcase for various ARM
targets.

   Is this OK to commit?

   Thanks,
   Andre Vieira

gcc/testsuite/ChangeLog:
2015-11-06  Andre Vieira  

 * gcc.target/arm/memset-inline-10.c: Added
 dg-require-effective-target arm_thumb2_ok.


Now with attachment, sorry about that.

Cheers,
Andre


Ping.



Ping.

Re: [Bug c++/58583] NSDMI parsing

[Nathan Sidwell]

On 12/31/15 16:49, Jason Merrill wrote:


Maybe disable the fold if parsing_nsdmi()?


thanks.  I've applied the attached.

Richard, I've augmented the comment about the folding to emphasize the 
checkingness.

nathan
2016-01-05  Nathan Sidwell  

	gcc/cp/
	PR c++/58583
	* pt.c (build_non_dependent_expr): Don't try a checking fold when
	parsing an nsdmi.

	gcc/testsuite/
	PR c++/58583
	* g++.dg/cpp0x/nsdmi-template14.C: Adjust test & errors.

Index: cp/pt.c
===
--- cp/pt.c	(revision 232074)
+++ cp/pt.c	(working copy)
@@ -23416,9 +23416,13 @@ build_non_dependent_expr (tree expr)
 {
   tree inner_expr;
 
-  /* Try to get a constant value for all non-dependent expressions in
-  order to expose bugs in *_dependent_expression_p and constexpr.  */
-  if (flag_checking && cxx_dialect >= cxx11)
+  /* When checking, try to get a constant value for all non-dependent
+ expressions in order to expose bugs in *_dependent_expression_p
+ and constexpr.  */
+  if (flag_checking && cxx_dialect >= cxx11
+  /* Don't do this during nsdmi parsing as it can lead to
+	 unexpected recursive instantiations.  */
+  && !parsing_nsdmi ())
 fold_non_dependent_expr (expr);
 
   /* Preserve OVERLOADs; the functions must be available to resolve
Index: testsuite/g++.dg/cpp0x/nsdmi-template14.C
===
--- testsuite/g++.dg/cpp0x/nsdmi-template14.C	(revision 232074)
+++ testsuite/g++.dg/cpp0x/nsdmi-template14.C	(working copy)
@@ -1,11 +1,13 @@
 // PR c++/58583
 // { dg-do compile { target c++11 } }
 
-template struct A // { dg-error "has been parsed" }
+template struct A
 {
-  int i = (A<0>(), 0); // { dg-error "has been parsed" }
+  int i = (A<0>(), 0); // { dg-error "recursive instantiation of non-static data" }
 };
 
+A<0> a;
+
 template struct B
 {
   B* p = new B; // { dg-error "recursive instantiation of non-static data" }

Re: [PATCH] libiberty: {count,dup,write}argv: constify argv input slightly

[Ian Lance Taylor]

On Sat, Jan 2, 2016 at 10:39 PM, Mike Frysinger  wrote:
> Would be more useful if we could use "const char * const *", but there's
> a long standing bug where gcc warns about incompatible pointers when you
> try to pass in "char **".

That's not a bug.  It's how C works.  http://c-faq.com/ansi/constmismatch.html

> We can at least constify the array itself as
> gcc will not warn in that case.
>
> include/:
> 2016-01-03  Mike Frysinger  
>
> * libiberty.h (dupargv): Change arg to char * const *.
> (writeargv, countargv): Likewise.
>
> libiberty/:
> 2016-01-03  Mike Frysinger  
>
> * argv.c (dupargv): Change arg to char * const *.  Update comment.
> (writeargv, countargv): Likewise.
> * functions.texi (dupargv, writeargv, countargv): Likewise.

This is OK if it bootstraps.  Thanks.

Ian

Re: [PATCH] libiberty: support demangling of rvalue reference typenames

[Artemiy Volkov]

On Tue, Jan 05, 2016 at 05:26:28AM -0800, Ian Lance Taylor wrote:
> Artemiy Volkov  writes:
> 
> > On Mon, Jan 04, 2016 at 10:06:44PM -0800, Ian Lance Taylor wrote:
> >> Artemiy Volkov  writes:
> >> 
> >> > This patch adds handling of 'O' (rvalue ref) type codes in the C++
> >> > demangling
> >> > code which is done similarly to the 'R' (regular references)
> >> > case. It also adds
> >> > a few testcases for various demangling styles which are just
> >> > mirrored versions
> >> > of the corresponding regular references demangling tests.
> >> >
> >> > libiberty/ChangeLog:
> >> >
> >> > 2016-01-04  Artemiy Volkov  
> >> >
> >> > * cplus-dem.c (enum type_kind_t): Add tk_rvalue_reference
> >> > constant.
> >> > (demangle_template_value_parm): Handle tk_rvalue_reference
> >> > type kind.
> >> > (do_type): Support 'O' type id (rvalue references).
> >> 
> >> Is there a compiler that actually generate these symbols?
> >
> > Sure, at least gcc and clang generate this. E.g. when compiling:
> >
> > void f(int&& b) { }
> >
> > you then have:
> >
> > ➜ nm 1.o 
> >  T _Z1fOi
> 
> That symbol name is handled by code in cp-demangle.c, not cplus-dem.c.
> It already works today.  Try it.  cplus-dem is the old (very old)
> demangler.  cp-demangle is the current demangler.

Sorry, I believe I should have mentioned that this patch is for the
needs of gdb, whose demangle command still pretty much uses the old
demangler in cplus-dem.c. I was working on rvalue references support in
gdb (https://sourceware.org/ml/gdb-patches/2015-12/msg00407.html) and
AIUI all the patches for libiberty should go through this mailing list,
that's why I sent the libiberty part here to later merge it to gdb.

> 
> Ian

Re: [RFC][PATCH, ARM 1/8] Add support for ARMv8-M's Security Extensions flag and intrinsics

[Andre Vieira]

On 31/12/15 20:54, Joseph Myers wrote:

On Sat, 26 Dec 2015, Thomas Preud'homme wrote:


+#define CMSE_TT_ASM(flags) \
+{ \
+  cmse_address_info_t result; \
+   __asm__ ("tt" # flags " %0,%1" \
+  : "=r"(result) \
+  : "r"(p) \
+  : "memory"); \
+  return result; \


Are the identifiers "result" and "p" really meant to be reserved by this
header (so that users can't have macros with those names before including
it), or should they actually be __result and __p (and likewise for any
other identifiers in this file not specified as reserved)?


+__extension__ void *
+cmse_check_address_range (void *p, size_t size, int flags);


Are "size" and "flags" really meant to be reserved?


+@item -mcmse
+@opindex mcmse
+Generate secure code as per ARMv8-M Security Extensions.


I think you also need a section in extend.texi much like the existing ACLE
section, to describe support for this as a language extension.



I'll change all non-reserved and 'not-ment-for-export' identifiers to be 
preceded by '__' and Ill also look into adding a section for ARMv8-M 
Security Extensions (CMSE) to extend.texi.


Thank you for your feedback.

BR,
Andre

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68841: Make sure one basic block doesn't clobber CC reg usage of the other

[Bernd Schmidt]

On 12/21/2015 10:23 AM, Kyrill Tkachov wrote:


Here is a version integrating the new checks into bbs_ok_for_cmove_arith.
We might as well do it there since it already iterates over all the
instructions in the basic blocks.


The patch looks somewhat complicated and asymmetrical to me. I tried to 
debug the issue, and found that bbs_ok_for_cmove_arith wasn't called at 
all. After changing that, like this:


@@ -2082,7 +2082,7 @@ noce_try_cmove_arith (struct noce_if_inf
}
 }

-  if (then_bb && else_bb && !a_simple && !b_simple
+  if (then_bb && else_bb
   && (!bbs_ok_for_cmove_arith (then_bb, else_bb)
  || !bbs_ok_for_cmove_arith (else_bb, then_bb)))
 return FALSE;

the testcase passes. Could you investigate whether this is sufficient?


 * ifcvt.c (cond_exec_get_condition): Rename to...
 (get_condition_from_jump): ... This.


Please don't.


+/* { dg-options "-Og -fif-conversion -flive-range-shrinkage -fpeel-loops 
-frerun-cse-after-loop" } */


That's a very specific set of options there, I wonder how Zdenek even 
found that. Maybe we also want a copy in torture/ to test it more broadly?



Bernd

FW: [RFA] Compact EH Patch [Ping * 2]

[Moore, Catherine]

Ping, Ping.

-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On 
Behalf Of Moore, Catherine
Sent: Monday, December 21, 2015 9:22 AM
To: Richard Henderson; gcc-patches@gcc.gnu.org
Cc: ja...@redhat.com; Matthew Fortune
Subject: RE: [RFA] Compact EH Patch [Ping]



> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- 
> ow...@gcc.gnu.org] On Behalf Of Moore, Catherine
> Sent: Sunday, December 13, 2015 5:12 PM
> To: Richard Henderson; gcc-patches@gcc.gnu.org
> Cc: ja...@redhat.com; Matthew Fortune
> Subject: RE: [RFA] Compact EH Patch
> 
> I've now updated the patch.  I'd like to get this in GCC 6.0; please 
> let me know if that is possible.
> I've also updated the spec (https://github.com/MentorEmbedded/cxx-
> abi/MIPSCompactEH.pdf).
>  rth commented that there was no versioning info provision for the 
> personality routines.  The now spec identifies a couple of bits in the 
> header that can be used for that.  A couple of new unwind opcodes were 
> also added.
> 
> With the exception of Matthew's comment about disabling Compact EH for 
> those ABIs that don't support it, I have not addressed the 
> MIPS-specific comments.  I will post a follow-on patch next week to take care 
> of that.
> There is also a problem with N64 ABI support that requires a follow-on 
> binutils patch.  I have disabled Compact EH for N64 on Linux in this 
> version of the patch.  I plan to re-enable it after binutils is updated.
> 
> Okay to commit?
> 
> Thanks,
> Catherine
> 
> 
> > -Original Message-
> > From: Richard Henderson [mailto:r...@redhat.com]
> > Sent: Friday, September 18, 2015 3:25 PM
> > To: Moore, Catherine; gcc-patches@gcc.gnu.org
> > Cc: ja...@redhat.com; Matthew Fortune
> > Subject: Re: [RFA] Compact EH Patch
> >
> > > Index: libgcc/libgcc-std.ver.in
> > >
> >
> ==
> > =
> > > --- libgcc/libgcc-std.ver.in  (revision 226409)
> > > +++ libgcc/libgcc-std.ver.in  (working copy)
> > > @@ -1918,6 +1918,7 @@ GCC_4.6.0 {
> > >__morestack_current_segment
> > >__morestack_initial_sp
> > >__splitstack_find
> > > +  _Unwind_GetEhEncoding
> > >  }
> > >
> > >  %inherit GCC_4.7.0 GCC_4.6.0
> > > @@ -1938,3 +1939,8 @@ GCC_4.7.0 {
> > >  %inherit GCC_4.8.0 GCC_4.7.0
> > >  GCC_4.8.0 {
> > >  }
> > > +
> > > +%inherit GCC_4.8.0 GCC_4.7.0
> > > +GCC_4.8.0 {
> > > +  __register_frame_info_header_bases
> > > +}
> >
> > You can't push new symbols into old versions.  These have to go into 
> > the version for the current gcc.
> 
> Done.
> >
> > > Index: libstdc++-v3/config/abi/pre/gnu.ver
> > >
> >
> ==
> > =
> > > --- libstdc++-v3/config/abi/pre/gnu.ver   (revision 226409)
> > > +++ libstdc++-v3/config/abi/pre/gnu.ver   (working copy)
> > > @@ -1909,6 +1909,7 @@ CXXABI_1.3 {
> > >  __gxx_personality_v0;
> > >  __gxx_personality_sj0;
> > >  __gxx_personality_seh0;
> > > +__gnu_compact_pr2;
> > >  __dynamic_cast;
> > >
> > >  # *_type_info classes, ctor and dtor
> 
> Done.
> 
> > > Index: libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> > >
> >
> ==
> > =
> > > --- libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> > (revision 226409)
> > > +++ libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
> > (working copy)
> > > @@ -200,6 +200,7 @@ CXXABI_2.0 {
> > >  __cxa_vec_new;
> > >  __gxx_personality_v0;
> > >  __gxx_personality_sj0;
> > > +__gnu_compact_pr2;
> > >  __dynamic_cast;
> > >
> > >  # std::exception_ptr
> >
> Jonathan says that CXXABI_2.0 is correct here.
> >
> > > +  if (data.type != CET_not_found)
> > > +return data.type;
> > > +
> > > +  return CET_not_found;
> >
> > Return data.type unconditionally.
> 
> Done.
> >
> > > +++ libgcc/unwind-pe.h(working copy)
> > > @@ -44,6 +44,7 @@
> > >  #define DW_EH_PE_udata2 0x02
> > >  #define DW_EH_PE_udata4 0x03
> > >  #define DW_EH_PE_udata8 0x04
> > > +#define DW_EH_PE_udata1 0x05
> > >  #define DW_EH_PE_sleb1280x09
> > >  #define DW_EH_PE_sdata2 0x0A
> > >  #define DW_EH_PE_sdata4 0x0B
> >
> > If we're going to add udata1, we might as well add sdata1 for consistency.
> 
> Done.
> >
> > > @@ -184,6 +187,7 @@ read_encoded_value_with_base (unsigned char
> > encodi
> > >union unaligned
> > >  {
> > >void *ptr;
> > > +  unsigned u1 __attribute__ ((mode (QI)));
> > >unsigned u2 __attribute__ ((mode (HI)));
> > >unsigned u4 __attribute__ ((mode (SI)));
> > >unsigned u8 __attribute__ ((mode (DI)));
> >
> > This is silly.  Access to a single byte never requires alignment 
> > help from the compiler...
> >
> > > + case DW_EH_PE_udata1:
> > > +   result = u->u1;
> > > +   p += 1;
> > > +   break;
> >
> > 

Re: [patch] ARM FreeBSD fix bootstrap

[Nathan Sidwell]

On 01/04/16 16:45, Andreas Tobler wrote:

Ping :)



I noticed this morning that VxWorks might be affected. To be on the safe
side I'd like to propose the attached version since it makes clear where
the override belongs to and I don't think hijacking
SUBTARGET_OVERRIDE_OPTIONS is a good idea here.
I need the override in the arm_option_override_internal function after
the default has been set.




I  have no further comment, thanks for investigating the vxworks usage.

nathan

[PATCH] -Winvalid-memory-model warning not given for stdatomic.h macros (PR c/69104)

[Marek Polacek]

At present, we fail to warn about wrong memory orders for certain atomic
functions.  This happens for macros in stdatomic.h.  The fix is to use the
expansion point location rather than the input location.

While at it, I made a trivial fix to the wording of one of the warnings: don't
start with a capital and don't end the warning with a fullstop.

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

2016-01-05  Marek Polacek  

PR c/69104
* builtins.c (get_memmodel): Use expansion point location rather than
the input location.  Call warning_at rather than warning.
(expand_builtin_atomic_compare_exchange): Likewise.
(expand_builtin_atomic_load): Likewise.
(expand_builtin_atomic_store): Likewise.
(expand_builtin_atomic_clear): Likewise.

* gcc.dg/atomic-invalid-2.c: New.

diff --git gcc/builtins.c gcc/builtins.c
index 63d3190..eec4a58 100644
--- gcc/builtins.c
+++ gcc/builtins.c
@@ -5037,6 +5037,8 @@ get_memmodel (tree exp)
 {
   rtx op;
   unsigned HOST_WIDE_INT val;
+  source_location loc
+= expansion_point_location_if_in_system_header (input_location);
 
   /* If the parameter is not a constant, it's a run time value so we'll just
  convert it to MEMMODEL_SEQ_CST to avoid annoying runtime checking.  */
@@ -5050,16 +5052,16 @@ get_memmodel (tree exp)
 val = targetm.memmodel_check (val);
   else if (val & ~MEMMODEL_MASK)
 {
-  warning (OPT_Winvalid_memory_model,
-  "Unknown architecture specifier in memory model to builtin.");
+  warning_at (loc, OPT_Winvalid_memory_model,
+ "unknown architecture specifier in memory model to builtin");
   return MEMMODEL_SEQ_CST;
 }
 
   /* Should never see a user explicit SYNC memodel model, so >= LAST works. */
   if (memmodel_base (val) >= MEMMODEL_LAST)
 {
-  warning (OPT_Winvalid_memory_model,
-  "invalid memory model argument to builtin");
+  warning_at (loc, OPT_Winvalid_memory_model,
+ "invalid memory model argument to builtin");
   return MEMMODEL_SEQ_CST;
 }
 
@@ -5111,23 +5113,25 @@ expand_builtin_atomic_compare_exchange (machine_mode 
mode, tree exp,
   enum memmodel success, failure;
   tree weak;
   bool is_weak;
+  source_location loc
+= expansion_point_location_if_in_system_header (input_location);
 
   success = get_memmodel (CALL_EXPR_ARG (exp, 4));
   failure = get_memmodel (CALL_EXPR_ARG (exp, 5));
 
   if (failure > success)
 {
-  warning (OPT_Winvalid_memory_model,
-  "failure memory model cannot be stronger than success memory "
-  "model for %<__atomic_compare_exchange%>");
+  warning_at (loc, OPT_Winvalid_memory_model,
+ "failure memory model cannot be stronger than success "
+ "memory model for %<__atomic_compare_exchange%>");
   success = MEMMODEL_SEQ_CST;
 }
  
   if (is_mm_release (failure) || is_mm_acq_rel (failure))
 {
-  warning (OPT_Winvalid_memory_model,
-  "invalid failure memory model for "
-  "%<__atomic_compare_exchange%>");
+  warning_at (loc, OPT_Winvalid_memory_model,
+ "invalid failure memory model for "
+ "%<__atomic_compare_exchange%>");
   failure = MEMMODEL_SEQ_CST;
   success = MEMMODEL_SEQ_CST;
 }
@@ -5188,8 +5192,10 @@ expand_builtin_atomic_load (machine_mode mode, tree exp, 
rtx target)
   model = get_memmodel (CALL_EXPR_ARG (exp, 1));
   if (is_mm_release (model) || is_mm_acq_rel (model))
 {
-  warning (OPT_Winvalid_memory_model,
-  "invalid memory model for %<__atomic_load%>");
+  source_location loc
+   = expansion_point_location_if_in_system_header (input_location);
+  warning_at (loc, OPT_Winvalid_memory_model,
+ "invalid memory model for %<__atomic_load%>");
   model = MEMMODEL_SEQ_CST;
 }
 
@@ -5218,8 +5224,10 @@ expand_builtin_atomic_store (machine_mode mode, tree exp)
   if (!(is_mm_relaxed (model) || is_mm_seq_cst (model)
|| is_mm_release (model)))
 {
-  warning (OPT_Winvalid_memory_model,
-  "invalid memory model for %<__atomic_store%>");
+  source_location loc
+   = expansion_point_location_if_in_system_header (input_location);
+  warning_at (loc, OPT_Winvalid_memory_model,
+ "invalid memory model for %<__atomic_store%>");
   model = MEMMODEL_SEQ_CST;
 }
 
@@ -5319,8 +5327,10 @@ expand_builtin_atomic_clear (tree exp)
 
   if (is_mm_consume (model) || is_mm_acquire (model) || is_mm_acq_rel (model))
 {
-  warning (OPT_Winvalid_memory_model,
-  "invalid memory model for %<__atomic_store%>");
+  source_location loc
+   = expansion_point_location_if_in_system_header (input_location);
+  warning_at (loc, OPT_Winvalid_memory_model,
+ "invalid memory model for %<__atomic_store%>");
   model = 

[PATCH 1/2] DWARF: process all TYPE_DECL nodes when iterating on scopes

[Pierre-Marie de Rodat]

Hello,

In Ada, it is possible to have nested subprograms in the following
configuration:

procedure Parent is
   type T;
   [...]
   procedure Child (Value : T) is
   begin
  [...]
   end Child;
begin
   [...]
end Parent;

If we generate debugging information for Child first before Parent, the
debug info for T will be generated at global scope since the DIE for
Parent does not exist yet. It is when generating debug info for Parent
that we are supposed to relocate it thanks to decls_for_scope and
process_scope_var.

However, process_scope_var currently works only on TYPE_DECL nodes that
are stubs, for unknown reasons. This change adapts it to work on all
TYPE_DECL nodes.

It bootstrapped and regtested fine on x86_64-linux and triggered to
regression in the GDB testsuite for Ada, C, C++ and Fortran. Ok to
commit? Thank you in advance!

gcc/ChangeLog:

* dwarf2out.c (process_scope_var): Relocate TYPE_DECL nodes that
are not stubs just like stub ones.
---
 gcc/dwarf2out.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 2c0bd63..da5524e 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -22829,8 +22829,7 @@ process_scope_var (tree stmt, tree decl, tree 
origin, dw_die_ref context_die)

if (TREE_CODE (decl_or_origin) == FUNCTION_DECL)
 die = lookup_decl_die (decl_or_origin);
-  else if (TREE_CODE (decl_or_origin) == TYPE_DECL
-   && TYPE_DECL_IS_STUB (decl_or_origin))
+  else if (TREE_CODE (decl_or_origin) == TYPE_DECL)
 die = lookup_type_die (TREE_TYPE (decl_or_origin));
   else
 die = NULL;
--
2.6.4

Re: [PATCH] Remove use of 'struct map' from plugin (nvptx)

[James Norris]

Ping!

Thanks,
Jim

On 12/16/2015 02:35 PM, James Norris wrote:

Hi,

The attached patch removes the use of the map structure
(struct map) from the NVPTX plugin.

Regtested on x86_64-pc-linux-gnu

Ok for trunk?

Thanks!
Jim

ChangeLog
=

2015-12-XX  James Norris  

 libgomp/
 * plugin/plugin-nvptx.c (struct map): Removed.
 (map_init, map_pop): Remove use of struct map. (map_push):
 Likewise and change argument list.
 * testsuite/libgomp.oacc-c-c++-common/mapping-1.c: New

Re: [PATCH] Fix Fortran deviceptr clause.

[James Norris]

Ping!

Thanks,
Jim


On 12/06/2015 02:10 PM, James Norris wrote:

Hi,

Attached is a patch that fixes some runtime issues dealing
with the deviceptr clause in Fortran. There were some
corner cases that were not being dealt with correctly,
e.g., specifying the deviceptr clause and not using
the variable specified by the deviceptr clause within
the associated region. Also a new set of test cases
has been added.

Regtested on x86_64-pc-linux-gnu

Ok for trunk?

Thanks!
Jim

Re: [PATCH 1/3, libgomp] Resolve libgomp plugin deadlock on exit, libgomp proper parts

[Chung-Lin Tang]

Patch has been updated to accommodate the gomp_fini_device() removal changes.
And ping.

On 2015/12/14 11:47 PM, Chung-Lin Tang wrote:
> [sorry, forgot to C gcc-patches in last send]
> 
> Hi Jakub,
> these patches are a revision of 
> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01701.html
> since that patch set have bitrotten by now.
> 
> To recap the original situation, due to the way that device locks are held
> when entering plugin code, a GOMP_PLUGIN_fatal() call will deadlock when the
> GOMP_unregister_var() exit destructor tries to obtain the same device lock.
> 
> This patch set revises many functions on libgomp plugin interface to return 
> false on error,
> and back to libgomp to release the lock and call gomp_fatal() there.
> 
> This first patch is the changes for the machine independent libgomp proper. 
> The entire patch
> set was tested without regressions. Is this okay for trunk?
> 
> Thanks,
> Chung-Lin
> 
> 2015-12-14  Chung-Lin Tang  
> 
> * target.c (gomp_device_copy): New function.
> (gomp_copy_host2dev): Likewise.
> (gomp_copy_dev2host): Likewise.
> (gomp_free_device_memory): Likewise.
> (gomp_map_vars_existing): Adjust to call gomp_copy_host2dev().
> (gomp_map_pointer): Likewise.
> (gomp_map_vars): Adjust to call gomp_copy_host2dev(), handle
> NULL value from alloc_func plugin hook.
> (gomp_unmap_tgt): Adjust to call gomp_free_device_memory().
> (gomp_copy_from_async): Adjust to call gomp_copy_dev2host().
> (gomp_unmap_vars): Likewise.
> (gomp_update): Adjust to call gomp_copy_dev2host() and
> gomp_copy_host2dev() functions.
> (gomp_init_device): Handle false value from init_device_func
> plugin hook.
> (gomp_fini_device): Handle false value from fini_device_func
> plugin hook.
> (gomp_exit_data): Adjust to call gomp_copy_dev2host().
> (omp_target_free): Adjust to call gomp_free_device_memory().
> (omp_target_memcpy): Handle return values from host2dev_func,
> dev2host_func, and dev2dev_func plugin hooks.
> (omp_target_memcpy_rect_worker): Likewise.
> * libgomp.h (struct gomp_device_descr): Adjust return type of
> init_device_func, fini_device_func, free_func, dev2host_func,
> host2dev_func, and dev2dev_func plugin hooks from 'void *' to
> bool.
> * oacc-host.c (host_init_device): Change return type to bool.
> (host_fini_device): Likewise.
> (host_free): Likewise.
> (host_dev2host): Likewise.
> (host_host2dev): Likewise.
> * oacc-mem.c (acc_free): Handle plugin hook fatal error case.
> (acc_memcpy_to_device): Likewise.
> (acc_memcpy_from_device): Likewise.
> (delete_copyout): Add libfnname parameter, handle free_func
> hook fatal error case.
> (acc_delete): Adjust delete_copyout call.
> (acc_copyout): Likewise.
> 
> 
> 

Index: libgomp.h
===
--- libgomp.h   (revision 232047)
+++ libgomp.h   (working copy)
@@ -927,16 +927,17 @@ struct gomp_device_descr
   unsigned int (*get_caps_func) (void);
   int (*get_type_func) (void);
   int (*get_num_devices_func) (void);
-  void (*init_device_func) (int);
-  void (*fini_device_func) (int);
+  bool (*init_device_func) (int);
+  bool (*fini_device_func) (int);
   unsigned (*version_func) (void);
   int (*load_image_func) (int, unsigned, const void *, struct addr_pair **);
   void (*unload_image_func) (int, unsigned, const void *);
   void *(*alloc_func) (int, size_t);
-  void (*free_func) (int, void *);
-  void *(*dev2host_func) (int, void *, const void *, size_t);
-  void *(*host2dev_func) (int, void *, const void *, size_t);
-  void *(*dev2dev_func) (int, void *, const void *, size_t);
+  bool (*free_func) (int, void *);
+  bool (*dev2host_func) (int, void *, const void *, size_t);
+  bool (*host2dev_func) (int, void *, const void *, size_t);
+  /*xxx*/
+  bool (*dev2dev_func) (int, void *, const void *, size_t);
   void (*run_func) (int, void *, void *);
   void (*async_run_func) (int, void *, void *, void *);
 
Index: oacc-host.c
===
--- oacc-host.c (revision 232047)
+++ oacc-host.c (working copy)
@@ -60,14 +60,16 @@ host_get_num_devices (void)
   return 1;
 }
 
-static void
+static bool
 host_init_device (int n __attribute__ ((unused)))
 {
+  return true;
 }
 
-static void
+static bool
 host_fini_device (int n __attribute__ ((unused)))
 {
+  return true;
 }
 
 static unsigned
@@ -98,28 +100,29 @@ host_alloc (int n __attribute__ ((unused)), size_t
   return gomp_malloc (s);
 }
 
-static void
+static bool
 host_free (int n __attribute__ ((unused)), void *p)
 {
   free (p);
+  return true;
 }
 
-static void *
+static bool
 host_dev2host (int n __attribute__ ((unused)),
   void *h 

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68841: Make sure one basic block doesn't clobber CC reg usage of the other

[Kyrill Tkachov]

On 05/01/16 13:42, Bernd Schmidt wrote:

On 12/21/2015 10:23 AM, Kyrill Tkachov wrote:


Here is a version integrating the new checks into bbs_ok_for_cmove_arith.
We might as well do it there since it already iterates over all the
instructions in the basic blocks.


The patch looks somewhat complicated and asymmetrical to me. I tried to debug 
the issue, and found that bbs_ok_for_cmove_arith wasn't called at all. After 
changing that, like this:

@@ -2082,7 +2082,7 @@ noce_try_cmove_arith (struct noce_if_inf
 }
 }

-  if (then_bb && else_bb && !a_simple && !b_simple
+  if (then_bb && else_bb
   && (!bbs_ok_for_cmove_arith (then_bb, else_bb)
   || !bbs_ok_for_cmove_arith (else_bb, then_bb)))
 return FALSE;

the testcase passes. Could you investigate whether this is sufficient?



This works around the issue but we don't want to do perform the check for pairs 
of
simple basic blocks because then we'll end up rejecting code that does things 
like:
x = cond ? x + 1 : x - 1
i.e. source of the set in both blocks reads and writes the same register.
We can deal with this safely later on in the function since we rename the 
destinations
of the two sets, so we don't want to reject this case here.
So your proposal rejects this case on that basis, which is overly restrictive 
and doesn't
deal with the underlying issue of the condition code being clobbered.
I had tried this approach initially but it caused code quality regressions on 
SPEC.


 * ifcvt.c (cond_exec_get_condition): Rename to...
 (get_condition_from_jump): ... This.


Please don't.



Ok, I'll leave it as cond_exec_get_condition


+/* { dg-options "-Og -fif-conversion -flive-range-shrinkage -fpeel-loops 
-frerun-cse-after-loop" } */


That's a very specific set of options there, I wonder how Zdenek even found 
that. Maybe we also want a copy in torture/ to test it more broadly?



Judging from some other reports from Zdenek that I've seen I think he tries a 
matrix of options, getting some
of the exotic combinations.
So should we have a copy in gcc.dg/ with the explicit options and a clean copy 
in torture?

Thanks,
Kyrill



Bernd

[PATCH 2/2] Ada: add XVE/XVU parallel types to lexical scopes

[Pierre-Marie de Rodat]

Hello,

This change adds TYPE_DECL nodes for XVE/XVU parallel types to lexical
scopes so that these types are properly scoped in the debug information.
Ok to commit? Thank you in advance!

gcc/ada/ChangeLog:

* gcc-interface/utils.c (rest_of_record_type_compilation): Add
XVE/XVU parallel types to the current lexical scope.
---
 gcc/ada/gcc-interface/utils.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/ada/gcc-interface/utils.c b/gcc/ada/gcc-interface/utils.c
index 779c376..0226c28 100644
--- a/gcc/ada/gcc-interface/utils.c
+++ b/gcc/ada/gcc-interface/utils.c
@@ -1937,6 +1937,7 @@ rest_of_record_type_compilation (tree record_type)
= create_type_stub_decl (new_name, new_record_type);
   DECL_IGNORED_P (TYPE_STUB_DECL (new_record_type))
= DECL_IGNORED_P (TYPE_STUB_DECL (record_type));
+  gnat_pushdecl (TYPE_STUB_DECL (new_record_type), Empty);
   TYPE_SIZE (new_record_type) = size_int (TYPE_ALIGN (record_type));
   TYPE_SIZE_UNIT (new_record_type)
= size_int (TYPE_ALIGN (record_type) / BITS_PER_UNIT);
--
2.6.4

[PING][PATCH] Mark symbols in offload tables with force_output in read_offload_tables

[Tom de Vries]

[ was: Re: [PATCH] Handle BUILT_IN_GOACC_PARALLEL in ipa-pta ]

On 16/12/15 17:02, Tom de Vries wrote:

On 10/12/15 14:14, Tom de Vries wrote:

[ copy-pasting-with-quote from
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00420.html , for some
reason I didn't get this email ]


On Thu, 3 Dec 2015, Tom de Vries wrote:

The flag is set here in expand_omp_target:
...
12682 /* Prevent IPA from removing child_fn as unreachable,
 since there are no
12683refs from the parent function to child_fn in offload
 LTO mode.  */
12684 if (ENABLE_OFFLOADING)
12685   cgraph_node::get (child_fn)->mark_force_output ();
...



How are there no refs from the "parent"?  Are there not refs from
some kind of descriptor that maps fallback CPU and offloaded variants?


That descriptor is the offload table, which is emitted in
omp_finish_file. The function iterates over vectors offload_vars and
offload_funcs.

[ I would guess there's a one-on-one correspondance between
symtab_node::offloadable and membership of either offload_vars or
offload_funcs. ]


I think the above needs sorting out in somw way, making the refs
explicit rather than implicit via force_output.


I've tried an approach where I add a test for node->offloadable next to
each test for node->force_output, except for the test in the nonlocal_p
def in ipa_pta_execute. But I didn't (yet) manage to make that work.


I guess setting forced_by_abi instead would also mean child_fn is not
removed
as unreachable, while still allowing optimizations:
...
  /* Like FORCE_OUTPUT, but in the case it is ABI requiring the symbol
 to be exported.  Unlike FORCE_OUTPUT this flag gets cleared to
 symbols promoted to static and it does not inhibit
 optimization.  */
  unsigned forced_by_abi : 1;
...

But I suspect that other optimizations (than ipa-pta) might break
things.


How so?


Probably it's more accurate to say that I do not understand the
difference very well between force_output and force_by_abi, and what is
the class of optimizations enabled by using forced_by_abi instead of
force_output.'


Essentially we have two situations:
- in the host compiler, there is no need for the forced_output flag,
  and it inhibits optimization
- in the accelerator compiler, it (or some equivalent) is needed


Actually, things are slightly more complicated, I realize now. There's
also the distinction between:
- symbols declared as offloadable in the source code, and
- symbols create by the compiler and marked offloadable


I wonder if setting the force_output flag only when streaming the
bytecode for
offloading would work. That way, it wouldn't be set in the host
compiler,
while being set in the accelerator compiler.


Yeah, that was my original thinking btw.


FTR, I've tried that approach, as attached. It fixed the
goacc/kernels-alias-ipa-pta*.c failures. And I ran target-libgomp (also
using an accelerator configuration) without any regressions.


How about this patch?



Ping.

Thanks,
- Tom


We remove the setting of force_output when:
- encountering offloadable symbols in the frontend, or
- creating offloadable symbols in expand-omp.

Instead, we set force_output in input_offload_tables.

This is an improvement because:
- it moves the force_output setting to a single location
- it does the force_output setting ALAP

Thanks,
- Tom

0008-Mark-symbols-in-offload-tables-with-force_output-in-read_offload_tables.patch


Mark symbols in offload tables with force_output in read_offload_tables

2015-12-15  Tom de Vries

* c-parser.c (c_parser_oacc_declare, c_parser_omp_declare_target): Don't
set force_output.

* parser.c (cp_parser_oacc_declare, cp_parser_omp_declare_target): Don't
set force_output.

* omp-low.c (expand_omp_target): Don't set force_output.
* varpool.c (varpool_node::get_create): Same.
* lto-cgraph.c (input_offload_tables): Mark entries in offload_vars and
offload_funcs with force_output.

---
  gcc/c/c-parser.c | 10 ++
  gcc/cp/parser.c  | 10 ++
  gcc/lto-cgraph.c |  9 +
  gcc/omp-low.c|  5 -
  gcc/varpool.c|  1 -
  5 files changed, 13 insertions(+), 22 deletions(-)

diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 124c30b..6e6f4b8 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -13527,10 +13527,7 @@ c_parser_oacc_declare (c_parser *parser)
{
  g->have_offload = true;
  if (is_a  (node))
-   {
- vec_safe_push (offload_vars, decl);
- node->force_output = 1;
-   }
+   vec_safe_push (offload_vars, decl);
}
}
}
@@ -16412,10 +16409,7 @@ c_parser_omp_declare_target (c_parser *parser)
{
  g->have_offload = true;
  if 

[gomp4] merge ptx changes

[Nathan Sidwell]

This patch merges my most recent sequence of ptx  backend changes to the gomp4 
branch.


nathan
2016-01-05  Nathan Sidwell  

	Merge from mainline:
	2015-12-30  Nathan Sidwell  
	* config/nvptx/nvptx.c (nvptx_assemble_undefined_decl): Check
	it's not a constant pool object.

	2015-12-28  Nathan Sidwell  
	* config/nvptx/nvptx.c (nvptx_output_call_insn): Expect hard regs.
	* config/nvptx/nvptx.md (nvptx_reg_or_mem_operand): Rename to ...
	(nvptx_nonimmediate_operand): ... here.  Update all uses.
	(call_insn_operand): Use REG_P.
	(call_operation): Allow hard regs.

	2015-12-23  Nathan Sidwell  
	* config/nvptx/nvptx-protos.h
	(nvptx_maybe_convert_symbolic_operand): Delete prototype.
	* config/nvptx/nvptx.c (nvptx_maybe_convert_symbolic_operand): Delete.
	(nvptx_output_mov_insn): Record fnsym here.
	(nvptx_wpropagate): Don't create UNSPEC_TO_GENERIC unspec.
	* config/nvptx/nvptx.md (UNSPEC_TO_GENERIC): Delete.
	(symbolic_operand): Delete predicate.
	(nvptx_nonimmediate_operand): Delete predicate.
	(mov): Hard regs are perfectly ok here.
	(convaddr_): Delete.

	2015-12-18  Nathan Sidwell  
	* config/nvptx/nvptx.c (nvptx_maybe_convert_symbolic_operand):
	Remove UNSPEC_TO_GENERIC generation.
	(nvptx_output_mov_insn): Generate cvta for symbolic src.
	* config/nvptx/nvptx.md (nvptx_register_operand): Allow hard reg.
	(nvptx_reg_or_mem_operand): Likewise.
	(nvptx_nonmemory_operand): Likewise.
	(nvptx_general_operand): Delete.
	(*mov_insn): Use nonimmediate_operand, permit hardregs.
	(oacc_fork, oacc_join): Use general_operand.

	2015-12-18  Nathan Sidwell  
	* config/nvptx/nvptx.c (nvptx_option_override): Emit sorry for
	stabs debug.
	(nvptx_assemble_undefined_decl): Use nvptx_assemble_decl_end.

	2015-12-18  Nathan Sidwell  
	* config/nvptx/nvptx.c (worker_bcast_name, worker_red_name): Delete.
	(nvptx_option_override): Adjust worker symbol creation.
	(nvptx_gen_wcast): Wrap worker address in UNSPEC_TO_GENERIC.
	(write_worker_buffer): New.
	(nvptx_file_end): Call write_worker_buffer.
	* config/nvptx/nvptx.md (UNSPEC_SHARED_DATA): Delete.
	(worker_load, worker_store): Delete.

	2015-12-17  Nathan Sidwell  
	* config/nvptx/nvptx.h (NVPTX_RETURN_REGNUM, FRAME_POINTER_REGNUM,
	ARG_POINTER_REGNUM, STATIC_CHAIN_REGNUM): Renumber.
	(REGISTER_NAMES): Update and rename.
	(FIXED_REGISTERS, CALL_USED_REGISTERS): Update.
	(enum_reg_class, REG_CLASS_NAMES, REG_CLASS_CONTENTS): Reformat.

	2015-12-16  Nathan Sidwell  
	* config/nvptx/nvptx.h (OUTGOING_STATIC_CHAIN_REGNUM): Remove.
	(REGISTER_NAMES): Adjust.
	* config/nvptx/nvptx.c (nvptx_pass_by_reference): Avoid long line.
	(nvptx_static_hain): Delete.
	(write_arg_mode): Don't emit initializer if argno < 0.
	(write_arg_type): Fix whitespace.
	(init_frame): Initialize reg to zero if frame is zero-sized.
	(nvptx_declare_function_name):  Use write_arg_type to emit chain
	decl.
	(nvptx_output_call_insn): Adjust static chain emission.
	(nvptx_goacc_reduction): Make static.
	(TARGET_STATIC_CHAIN): Don't override.

	2015-12-16  Nathan Sidwell  
	* config/nvptx/nvptx-protos.h (nvptx_hard_regno_mode_ok): Delete.
	* config/nvptx/nvptx.h (struct machine_function):
	Reimplement. Adjust all users.
	* config/nvptx/nvptx.c (nvptx_declare_function_name): Move stack
	and frame array generation earlier.
	(nvptx_call_args): Reimplement.
	(nvptx_expand_call): Adjust.
	(nvptx_hard_reno_mode_ok): Delete.
	(nvptx_reorg): Revert scan of hard regs.

Index: config/nvptx/nvptx.h
===
--- config/nvptx/nvptx.h	(revision 232059)
+++ config/nvptx/nvptx.h	(working copy)
@@ -1,5 +1,5 @@
 /* Target Definitions for NVPTX.
-   Copyright (C) 2014-2015 Free Software Foundation, Inc.
+   Copyright (C) 2014-2016 Free Software Foundation, Inc.
Contributed by Bernd Schmidt 
 
This file is part of GCC.
@@ -29,8 +29,6 @@
 
 #define STARTFILE_SPEC "%{mmainkernel:crt0.o}"
 
-#define ASM_SPEC "%{misa=*:-m %*}"
-
 #define TARGET_CPU_CPP_BUILTINS()		\
   do		\
 {		\
@@ -84,21 +82,17 @@
 #define PTRDIFF_TYPE (TARGET_ABI64 ? "long int" : "int")
 
 #define POINTER_SIZE (TARGET_ABI64 ? 64 : 32)
-
 #define Pmode (TARGET_ABI64 ? DImode : SImode)
 
 #define TARGET_SM35 (ptx_isa_option >= PTX_ISA_SM35)
 
 /* Registers.  Since ptx is a virtual target, we just define a few
-   hard registers for special purposes and leave pseudos unallocated.  */
-
-#define FIRST_PSEUDO_REGISTER 16
-/* We have to have some available hard registers, to keep gcc setup
+   hard registers for special purposes and leave pseudos unallocated.
+   We have to have some available hard registers, to keep gcc setup
happy.  */
-#define FIXED_REGISTERS	\
-  { 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1 }
-#define CALL_USED_REGISTERS\
-  { 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 }

Re: [PATCH] libiberty: support demangling of rvalue reference typenames

[Ian Lance Taylor]

On Tue, Jan 5, 2016 at 5:59 AM, Artemiy Volkov  wrote:
> On Tue, Jan 05, 2016 at 05:26:28AM -0800, Ian Lance Taylor wrote:
>> Artemiy Volkov  writes:
>>
>> > On Mon, Jan 04, 2016 at 10:06:44PM -0800, Ian Lance Taylor wrote:
>> >> Artemiy Volkov  writes:
>> >>
>> >> > This patch adds handling of 'O' (rvalue ref) type codes in the C++
>> >> > demangling
>> >> > code which is done similarly to the 'R' (regular references)
>> >> > case. It also adds
>> >> > a few testcases for various demangling styles which are just
>> >> > mirrored versions
>> >> > of the corresponding regular references demangling tests.
>> >> >
>> >> > libiberty/ChangeLog:
>> >> >
>> >> > 2016-01-04  Artemiy Volkov  
>> >> >
>> >> > * cplus-dem.c (enum type_kind_t): Add tk_rvalue_reference
>> >> > constant.
>> >> > (demangle_template_value_parm): Handle tk_rvalue_reference
>> >> > type kind.
>> >> > (do_type): Support 'O' type id (rvalue references).
>> >>
>> >> Is there a compiler that actually generate these symbols?
>> >
>> > Sure, at least gcc and clang generate this. E.g. when compiling:
>> >
>> > void f(int&& b) { }
>> >
>> > you then have:
>> >
>> > ➜ nm 1.o
>> >  T _Z1fOi
>>
>> That symbol name is handled by code in cp-demangle.c, not cplus-dem.c.
>> It already works today.  Try it.  cplus-dem is the old (very old)
>> demangler.  cp-demangle is the current demangler.
>
> Sorry, I believe I should have mentioned that this patch is for the
> needs of gdb, whose demangle command still pretty much uses the old
> demangler in cplus-dem.c. I was working on rvalue references support in
> gdb (https://sourceware.org/ml/gdb-patches/2015-12/msg00407.html) and
> AIUI all the patches for libiberty should go through this mailing list,
> that's why I sent the libiberty part here to later merge it to gdb.

If gdb is using the code in cplus-dem.c in any way for a program
compiled in the last 15 years, then gdb is doing something horribly
wrong.  What function is gdb calling that makes your patch make a
difference?

Ian

Re: [PATCH] OpenACC documentation for libgomp

[James Norris]

Hi!

I've updated the original patch after some very helpful
comments from Sandra (thank you, thank you).

OK to commit to trunk?

Thanks!
Jim

diff --git a/libgomp/ChangeLog b/libgomp/ChangeLog
index 87ec337..fc7b9fe 100644
--- a/libgomp/ChangeLog
+++ b/libgomp/ChangeLog
@@ -1,3 +1,8 @@
+2016-01-XX  James Norris  
+	Thomas Schwinge  
+
+	* libgomp.texi (CUDA Streams Usage): New chapter.
+
 2016-01-04  Jakub Jelinek  
 
 	* libgomp.texi: Bump @copying's copyright year.
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 480353a..6c421c3 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -94,6 +94,16 @@ changed to GNU Offloading and Multi Processing Runtime Library.
 @comment  better formatting.
 @comment
 @menu
+* Enabling OpenACC::   How to enable OpenACC for your
+   applications.
+* OpenACC Runtime Library Routines:: The OpenACC runtime application
+   programming interface.
+* OpenACC Environment Variables::Influencing OpenACC runtime behavior with
+   environment variables.
+* CUDA Streams Usage:: Notes on the implementation of
+   asynchronous operations.
+* OpenACC Library Interoperability:: OpenACC library interoperability with the
+   NVIDIA CUBLAS library.
 * Enabling OpenMP::How to enable OpenMP for your applications.
 * Runtime Library Routines::   The OpenMP runtime application programming 
interface.
@@ -113,6 +123,1255 @@ changed to GNU Offloading and Multi Processing Runtime Library.
 
 
 @c -
+@c Enabling OpenACC
+@c -
+
+@node Enabling OpenACC
+@chapter Enabling OpenACC
+
+To activate the OpenACC extensions for C/C++ and Fortran, the compile-time 
+flag @option{-fopenacc} must be specified.  This enables the OpenACC directive
+@code{#pragma acc} in C/C++ and @code{!$accp} directives in free form,
+@code{c$acc}, @code{*$acc} and @code{!$acc} directives in fixed form,
+@code{!$} conditional compilation sentinels in free form and @code{c$},
+@code{*$} and @code{!$} sentinels in fixed form, for Fortran.  The flag also
+arranges for automatic linking of the OpenACC runtime library 
+(@ref{OpenACC Runtime Library Routines}).
+
+A complete description of all OpenACC directives accepted may be found in 
+the @uref{http://www.openacc.org/, OpenMP Application Programming
+Interface} manual, version 2.0.
+
+Note that this is an experimental feature, incomplete, and subject to
+change in future versions of GCC.  See
+@uref{https://gcc.gnu.org/wiki/OpenACC} for more information.
+
+
+
+@c -
+@c OpenACC Runtime Library Routines
+@c -
+
+@node OpenACC Runtime Library Routines
+@chapter OpenACC Runtime Library Routines
+
+The runtime routines described here are defined by section 3 of the OpenACC
+specifications in version 2.0.
+They have C linkage, and do not throw exceptions.
+Generally, they are available only for the host, with the exception of
+@code{acc_on_device}, which is available for both the host and the
+acceleration device.
+
+@menu
+* acc_get_num_devices:: Get number of devices for the given device type.
+* acc_set_device_type:: Set type of device accelerator to use.
+* acc_get_device_type:: Get type of device accelerator to be used.
+* acc_set_device_num::  Set device number to use.
+* acc_get_device_num::  Get device number to be used.
+* acc_async_test::  Tests for completion of a specific asynchronous operation.
+* acc_async_test_all::  Tests for completion of all asychronous operations.
+* acc_wait::Wait for completion of a specific asynchronous operation.
+* acc_wait_all::Waits for completion of all asyncrhonous operations.
+* acc_wait_all_async::  Wait for completion of all asynchronous operations.
+* acc_wait_async::  Wait for completion of asynchronous operations.
+* acc_init::Initialize runtime for a specific device type.
+* acc_shutdown::Shuts down the runtime for a specific device type.
+* acc_on_device::   Whether executing on a particular device
+* acc_malloc::  Allocate device memory.
+* acc_free::Free device memory.
+* acc_copyin::  Allocate device memory and copy host memory to it.
+* acc_present_or_copyin::   If the data is not present on the device, allocate device memory and copy from host memory.
+* acc_create::  Allocate device memory and map it to host memory.
+* 

[doc, committed] document MicroBlaze interrupt_handler and fast_interrupt attributes

[Sandra Loosemore]

I've checked in this patch to add some minimal documentation for the 
MicroBlaze interrupt handler attributes.  I was able to figure this out 
by inspection of the code and reading the processor documentation, which 
has a more extensive discussion of how to use these features.


-Sandra

2016-01-05  Sandra Loosemore 

	PR 1078
	gcc/
	* doc/extend.texi (MicroBlaze Function Attributes): Document
	interrupt_handler and fast_interrupt attributes.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 232077)
+++ gcc/doc/extend.texi	(working copy)
@@ -4205,6 +4205,17 @@ the @code{rtbd} instead of @code{rtsd}.
 @smallexample
 void f () __attribute__ ((break_handler));
 @end smallexample
+
+@item interrupt_handler
+@itemx fast_interrupt 
+@cindex @code{interrupt_handler} function attribute, MicroBlaze
+@cindex @code{fast_interrupt} function attribute, MicroBlaze
+These attributes indicate that the specified function is an interrupt
+handler.  Use the @code{fast_interrupt} attribute to indicate handlers
+used in low-latency interrupt mode, and @code{interrupt_handler} for
+interrupts that do not use low-latency handlers.  In both cases, GCC
+emits appropriate prologue code and generates a return from the handler
+using @code{rtid} instead of @code{rtsd}.
 @end table
 
 @node Microsoft Windows Function Attributes

Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68841: Make sure one basic block doesn't clobber CC reg usage of the other

[Kyrill Tkachov]

On 05/01/16 17:06, Kyrill Tkachov wrote:


On 05/01/16 16:34, Bernd Schmidt wrote:

On 01/05/2016 03:22 PM, Kyrill Tkachov wrote:


This works around the issue but we don't want to do perform the check
for pairs of
simple basic blocks because then we'll end up rejecting code that does
things like:
x = cond ? x + 1 : x - 1
i.e. source of the set in both blocks reads and writes the same register.
We can deal with this safely later on in the function since we rename
the destinations
of the two sets, so we don't want to reject this case here.


So we need to teach bbs_ok_for_cmove_arith that this is going to happen. How 
about the approach below? Still seems to fix the issue, and it looks like the 
CC set is present in the df info so everything should work as intended. Right?



Yeah, this looks like it works.
However, now we reject if-conversion whereas with my patch we still tried 
switching the order in which
the blocks were emitted, which allowed for a bit more aggressive if-conversion.
I don't know if this approach is overly restrictive yet.
I'll try its effects on codegen quality on SPEC as soon as I get some cycles.
But this approach does look appealing to me.



Hmm, from a first look at SPEC, it seems to still overly restrict ifconversion 
in the
x = cond ? x + 1 : x - 1 case.
I'll look deeper tomorrow as to what's going on there.

Kyrill


Thanks for the help,
Kyrill



Bernd

Re: [PATCH] Preserve user alignment on decls (PR middle-end/68960)

[Jeff Law]

On 01/05/2016 11:25 AM, Jakub Jelinek wrote:

Hi!

When a VAR_DECL is copied (e.g. for OpenMP/OpenACC privatization, or
when moving SESE region to another function), copy_var_decl only preserves
user alignment on types, but not on decls.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2016-01-05  Jakub Jelinek  

PR middle-end/68960
* gimple-expr.c (copy_var_decl): If var has DECL_USER_ALIGN set, copy
it and DECL_ALIGN too.

* testsuite/libgomp.c/pr68960.c: New test.

OK for the trunk.

Jeff

[gomp4] Non-unity default partition size

[Nathan Sidwell]

This patch implements support for providing non-unity default values for 
unspecified compute dimensions.  For instance, given:


#pragma acc parallel
#pragma acc loop gang
  ...

The user has not specified num_gangs, it would be good to choose a value greater 
than 1.  This patch achieves this via a new option '-fopenacc-dim=' and and an 
environment variable GOMP_OPENACC_DIM.  We also allow the target backend to 
provide a default value, if the -fopenacc-dim option is omitted.  For the PTX 
backend, this specifies 32 for each of the 3 dimensions.


Firstly the option takes a colon-separate triple of integers: 
-fopenacc-dim=G:W:V, these values are used as the default gang, worker and 
vector sizes, where a parallel region  has (a) not specified a dimension size 
and (b) contains a loop partitioned along that dimension.  Not all 3 values of 
the triple need specifying (omitted ones are defaulted by the backend, just as 
if no -fopenacc-dim option was given.


It is possible to defer dimension  size to runtime by specifying '-' as the 
value in the fopenacc-dim option triple. In this case, the GOMP_OPENACC_DIM 
environment variable will be examined at runtime to provide a value for any 
unspecified dimension.   Its format is the same as the fopenacc-dim option, 
except that '-' values are not permitted.  If the variable is omitted, or omits 
a value, a device-specific default is used (again, 32 for the PTX plugin).


The option and variable syntax are extendible for device_type support, by 
becoming a comma-separated set of tuples, each prefixed with a  colon-terminated 
device name. (Not implemented and subject to change).


Although the OpenACC specification indicates that an implementation can pick an 
arbitrary non-unity default, this can cause great surprise by introducing 
unexpected gang partitioned execution.  For instance:


#pragma acc parallel num_workers(32)
#pragma acc loop worker
  ...

if the gang-partitioning is not 1, the body of the loop probably becomes 
undefined code, as it executes multiple times on each gang.  Indeed, this 
simple-minded approach caused a great deal of testsuite fallout, with tests 
assuming non-gang-partitioned parallels defaulted  to 1 gang.


Further, requiring the user to explicitly specify num_gangs(1) on every 
non-gang-partitioned parallel will cause problems with auto loops,  where the 
compiler is permitted to choose a partitioning axis.  If the user doesn't 
specify num_gangs(1) and the compiler chooses not to partition on the gang axis, 
again we have undefined code should the compiler default to non-unity. 
Alternatively, should the user specify num_gangs(1) to maintain portability, and 
the compiler chose to partition on the gang axis, not much acceleration is going 
to be seen.


So, part of this patch augments the loop partitioning code to  return a mask of 
the axes that an offloaded function partitions loops.  For those that are 
partitioned we choose a non-unity default, but for those that are unpartitioned 
we choses 1.  (In both cases these choices go via the backend dimension 
validation, so the minumum might not be 1 -- eg the vector axis on PTX).


We also emit 2 new warnings

a) a loop is being partitioned on a dimension that is explicitly sized to 1

b) an offload region is partitioned to non-unity, but does not contain a loop on 
that axis.


The bulk of the testsuite changes are to inhibit those warnings, as oftenn they 
intentionally do one of those 2 things.


nathan
2016-01-05  Nathan Sidwell  

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

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

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

	gcc/testsuite/
	* c-c++-common/goacc/parallel-reduction.c: Add -w.
	* c-c++-common/goacc/routine-1.c: Add -w.
	* c-c++-common/goacc/routine-3.c: Add -w.
	* c-c++-common/goacc/routine-6.c: Add -w.
	* g++.dg/goacc/template.C: Add -w.
	* gfortran.dg/goacc/parallel-tree.f95: Add -w.
	* gfortran.dg/goacc/routine-4.f90: Add -w.

	libgomp/
	* plugin/plugin-nvptx.c (nvptx_exec): Read GOMP_OPENACC_DIM.
	* testsuite/libgomp.oacc-c-c++-common/loop-default-compile.c: New.
	* testsuite/libgomp.oacc-c-c++-common/loop-default-runtime.c: New.
	* 

Re: [PATHCH] Disable inline asm for in-tree mpfr (PR69134)

[Jeff Law]

On 01/05/2016 06:20 AM, Bernd Edlinger wrote:

Hi,

On 05.01.2016 13:58, Bernd Schmidt wrote:

On 01/05/2016 09:44 AM, Bernd Edlinger wrote:

an in-tree mpfr build enables inline asm code, which makes the
mips-bootstrap fail,
because at least mpfr 2.4.2 uses the "=h" constraint but in
config/mips/constraints.md
we find: "Formerly the @code{hi} register.  This constraint is no
longer supported.".

Using asm code is generally not desirable for in-tree mpfr builds.


Why not?


for the same reason why we disable the asm code for in-tree gmp.

If we think mpfr is fine to use assembler, why don't we let gmp use the
assember code too?

When we boot-strap to a different architecture we certainly do not want
to fiddle with inline-assember bugs, unless absolutely necessary.
Given that we're already building against the mpfr-3.x.y API/ABI for 
out-of-tree builds, what about just updating mpfr in the infrastructure 
directory?  It's only the in-tree builds of mpfr that are suffering and 
they're using an ancient mpfr.


I guess you'd have to verify that it works and that doing so doesn't 
require updating gmp and mpc.  But stepping forward seems like the best 
solution to me.


jeff

Re: [PATHCH] Disable inline asm for in-tree mpfr (PR69134)

[Richard Biener]

On January 5, 2016 2:20:42 PM GMT+01:00, Bernd Edlinger 
 wrote:
>Hi,
>
>On 05.01.2016 13:58, Bernd Schmidt wrote:
>> On 01/05/2016 09:44 AM, Bernd Edlinger wrote:
>>> an in-tree mpfr build enables inline asm code, which makes the 
>>> mips-bootstrap fail,
>>> because at least mpfr 2.4.2 uses the "=h" constraint but in 
>>> config/mips/constraints.md
>>> we find: "Formerly the @code{hi} register.  This constraint is no 
>>> longer supported.".
>>>
>>> Using asm code is generally not desirable for in-tree mpfr builds.
>>
>> Why not?
>
>for the same reason why we disable the asm code for in-tree gmp.
>
>If we think mpfr is fine to use assembler, why don't we let gmp use the
>
>assember code too?

IIRC the logic at some point at least used host CPU detection to select asm.  
That's undesirable if you want to run binaries on different hosts.  Not sure if 
this is still the case with newer gmp/mpfr, but as long as we allow the ancient 
ones we should continue w/o asm.

Richard.

>When we boot-strap to a different architecture we certainly do not want
>
>to fiddle with inline-assember bugs, unless absolutely necessary.
>
>
>>
>>> So I looked for a way
>>> to disable the asm code, and found it can be done, but differently 
>>> than for in-tree gmp.
>>> See the attached patch.
>>
>> Fix mpfr instead not to use that constraint?
>>
>
>I don't think we should start to patch mpfr release-tarballs.
>
>The only alternative I see, how a mips-compiler could be boot-strapped 
>today would be to set CFLAGS="-g -O2 -DNO_ASM" on the gcc configure 
>line, but this will then be used everywhere, and I have no idea if that
>
>define has some side effects on libgcc for instance (my boot-strap did 
>not reach that point).
>
>
>Bernd.

Re: [PATCH] PR target/68991: Add vector_memory_operand and "Bm" constraint

[H.J. Lu]

On Tue, Jan 5, 2016 at 4:32 AM, H.J. Lu  wrote:
> On Tue, Jan 5, 2016 at 12:11 AM, Jakub Jelinek  wrote:
>> On Mon, Jan 04, 2016 at 03:25:48PM -0800, H.J. Lu wrote:
>>> LRA is fine.  I should use
>>>
>>> (define_memory_constraint "Bm"
>>>   "@internal Vector memory operand."
>>>   (match_operand 0 "vector_memory_operand"))
>>>
>>> instead of
>>>
>>> (define_constraint "Bm"
>>>   "@internal Vector memory operand."
>>>   (match_operand 0 "vector_memory_operand"))
>>
>> I don't think so.  At least the documentation says that
>> define_memory_constraint is for MEM constraints where if they are not
>> satisfied they can be made to satisfy by forcing the address into a
>> register.  But that is not the case here, if a MEM is misaligned, no
>> equivalent changes to the XEXP (mem, 0) will make it aligned.
>>
>
> You are right and *mov_internal must use the 'm' constraint
> so that LRA won't keep generating the same reload for
>
> (insn 353 322 323 8 (set (reg:V4SF 192)
> (reg:V4SF 201 [192])) 1226 {*movv4sf_internal}
>  (nil))
>
> until
>
> x.i: In function \u2018foo\u2019:
> x.i:29:1: internal compiler error: Max. number of generated reload
> insns per insn is achieved (90)
>
>  }
>  ^
>
> 0xc0d635 lra_constraints(bool)
> /export/gnu/import/git/sources/gcc/gcc/lra-constraints.c:4336
> 0xbf9854 lra(_IO_FILE*)
> /export/gnu/import/git/sources/gcc/gcc/lra.c:2277
> 0xba6489 do_reload
> /export/gnu/import/git/sources/gcc/gcc/ira.c:5385
> 0xba683c execute
> /export/gnu/import/git/sources/gcc/gcc/ira.c:5556
>
>

Here are the updated patches.  I didn't change SSE
*mov_internal.  Tested on x86-64.  OK for
trunk?


-- 
H.J.
From 74f90ab1f38a7baf7503974130a699a1bd622b87 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Sat, 19 Dec 2015 06:51:44 -0800
Subject: [PATCH 1/2] Add vector_memory_operand and "Bm" constraint

SSE vector arithmetic and logic instructions only accept aligned memory
operand.  This patch adds vector_memory_operand and "Bm" constraint for
aligned SSE memory operand.  They are applied to SSE plusminus and
any_logic patterns.

gcc/

	PR target/68991
	* config/i386/constraints.md (Bm): New constraint.
	* config/i386/predicates.md (vector_memory_operand): New
	predicate.
	* config/i386/sse.md: Replace xm with xBm in plusminus and
	any_logic patterns.

gcc/testsuite/

	PR target/68991
	* g++.dg/pr68991-1.C: New test.
	* g++.dg/pr68991-2.C: Likewise.
---
 gcc/config/i386/constraints.md   |   5 +
 gcc/config/i386/predicates.md|   7 ++
 gcc/config/i386/sse.md   |  18 ++--
 gcc/testsuite/g++.dg/pr68991-1.C | 191 +++
 gcc/testsuite/g++.dg/pr68991-2.C | 191 +++
 5 files changed, 403 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr68991-1.C
 create mode 100644 gcc/testsuite/g++.dg/pr68991-2.C

diff --git a/gcc/config/i386/constraints.md b/gcc/config/i386/constraints.md
index b3db133..bac9d66 100644
--- a/gcc/config/i386/constraints.md
+++ b/gcc/config/i386/constraints.md
@@ -148,6 +148,7 @@
 ;; We use the B prefix to denote any number of internal operands:
 ;;  f  FLAGS_REG
 ;;  g  GOT memory operand.
+;;  m  Vector memory operand
 ;;  s  Sibcall memory operand, not valid for TARGET_X32
 ;;  w  Call memory operand, not valid for TARGET_X32
 ;;  z  Constant call address operand.
@@ -160,6 +161,10 @@
   "@internal GOT memory operand."
   (match_operand 0 "GOT_memory_operand"))
 
+(define_constraint "Bm"
+  "@internal Vector memory operand."
+  (match_operand 0 "vector_memory_operand"))
+
 (define_constraint "Bs"
   "@internal Sibcall memory operand."
   (ior (and (not (match_test "TARGET_X32"))
diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index 6f0159b..33b3594 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -951,6 +951,13 @@
(match_test "INTEGRAL_MODE_P (GET_MODE (op))")
(match_test "op == CONSTM1_RTX (GET_MODE (op))")))
 
+; Return true when OP is operand acceptable for vector memory operand.
+; Only AVX can have misaligned memory operand.
+(define_predicate "vector_memory_operand"
+  (and (match_operand 0 "memory_operand")
+   (ior (match_test "TARGET_AVX")
+	(match_test "MEM_ALIGN (op) >= GET_MODE_ALIGNMENT (mode)"
+
 ; Return true when OP is operand acceptable for standard SSE move.
 (define_predicate "vector_move_operand"
   (ior (match_operand 0 "nonimmediate_operand")
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index c3cd199..ca3a831 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -1676,7 +1676,7 @@
   [(set (match_operand:VF 0 "register_operand" "=x,v")
 	(plusminus:VF
 	  (match_operand:VF 1 "" "0,v")
-	  (match_operand:VF 2 "" "xm,")))]
+	  (match_operand:VF 2 "" "xBm,")))]
   "TARGET_SSE && ix86_binary_operator_ok (, mode, operands) &&  && "
   "@
\t{%2, %0|%0, %2}
@@ -1691,7 +1691,7 @@
 	

Re: [PATHCH] Disable inline asm for in-tree mpfr (PR69134)

[Jeff Law]

On 01/05/2016 11:52 AM, Bernd Edlinger wrote:


Maybe, that can of course improve things but...

I tried to update to gmp 6.0.0 a while ago, and I noticed that it won't
build unless we also update to latest mpfr and mpc at the same time.
I just checked --  mpfr-3.1.3 only requires gmp-4.1 or newer.  So we 
don't have to step gmp forward.  Just mpfr.


Jeff

Re: RFA: PR 66655: Use COFF/PE weak symbols

[Jeff Law]

On 01/05/2016 04:03 AM, Nick Clifton wrote:

Hi Jeff,


You probably know the capabilities of COFF/PE better than I, so the
patch itself is fine.


Thanks - committed.


Is there any way that test can be shoved into our dejagnu testing
harness?  I think we've got support somewhere for tests which require
multiple input files.


dg-additional-sources is the command that you are thinking about.

That's it!




The attached patch adds the test derived from the BZ.  There is one
small problem - I could not find a way to stop the additional source
file from being compiled as a test on its own.  When I investigated
however it seems that is a common problem for all tests that use
additional source files, so I do not think that it is a big issue.
I think for C++ code it's usually worked around by naming the 
additional-source file with ".cc" rather than .C.  Can you give that a 
quick whirl and see if that avoids having the additional file used as a 
a test on its own?


Thanks,
jeff

Re: [PATCH] PR target/68991: Add vector_memory_operand and "Bm" constraint

[Uros Bizjak]

On Tue, Jan 5, 2016 at 7:58 PM, H.J. Lu  wrote:
> On Tue, Jan 5, 2016 at 4:32 AM, H.J. Lu  wrote:
>> On Tue, Jan 5, 2016 at 12:11 AM, Jakub Jelinek  wrote:
>>> On Mon, Jan 04, 2016 at 03:25:48PM -0800, H.J. Lu wrote:
 LRA is fine.  I should use

 (define_memory_constraint "Bm"
   "@internal Vector memory operand."
   (match_operand 0 "vector_memory_operand"))

 instead of

 (define_constraint "Bm"
   "@internal Vector memory operand."
   (match_operand 0 "vector_memory_operand"))
>>>
>>> I don't think so.  At least the documentation says that
>>> define_memory_constraint is for MEM constraints where if they are not
>>> satisfied they can be made to satisfy by forcing the address into a
>>> register.  But that is not the case here, if a MEM is misaligned, no
>>> equivalent changes to the XEXP (mem, 0) will make it aligned.
>>>
>>
>> You are right and *mov_internal must use the 'm' constraint
>> so that LRA won't keep generating the same reload for
>>
>> (insn 353 322 323 8 (set (reg:V4SF 192)
>> (reg:V4SF 201 [192])) 1226 {*movv4sf_internal}
>>  (nil))
>>
>> until
>>
>> x.i: In function \u2018foo\u2019:
>> x.i:29:1: internal compiler error: Max. number of generated reload
>> insns per insn is achieved (90)
>>
>>  }
>>  ^
>>
>> 0xc0d635 lra_constraints(bool)
>> /export/gnu/import/git/sources/gcc/gcc/lra-constraints.c:4336
>> 0xbf9854 lra(_IO_FILE*)
>> /export/gnu/import/git/sources/gcc/gcc/lra.c:2277
>> 0xba6489 do_reload
>> /export/gnu/import/git/sources/gcc/gcc/ira.c:5385
>> 0xba683c execute
>> /export/gnu/import/git/sources/gcc/gcc/ira.c:5556
>>
>>
>
> Here are the updated patches.  I didn't change SSE
> *mov_internal.  Tested on x86-64.  OK for
> trunk?

It is hard to determine the changed patterns - can you confirm that
only patterns where ssememalign=0 are changed?

Uros.

Re: [PATCH] PR target/68991: Add vector_memory_operand and "Bm" constraint

[H.J. Lu]

On Tue, Jan 5, 2016 at 11:14 AM, Uros Bizjak  wrote:
> On Tue, Jan 5, 2016 at 7:58 PM, H.J. Lu  wrote:
>> On Tue, Jan 5, 2016 at 4:32 AM, H.J. Lu  wrote:
>>> On Tue, Jan 5, 2016 at 12:11 AM, Jakub Jelinek  wrote:
 On Mon, Jan 04, 2016 at 03:25:48PM -0800, H.J. Lu wrote:
> LRA is fine.  I should use
>
> (define_memory_constraint "Bm"
>   "@internal Vector memory operand."
>   (match_operand 0 "vector_memory_operand"))
>
> instead of
>
> (define_constraint "Bm"
>   "@internal Vector memory operand."
>   (match_operand 0 "vector_memory_operand"))

 I don't think so.  At least the documentation says that
 define_memory_constraint is for MEM constraints where if they are not
 satisfied they can be made to satisfy by forcing the address into a
 register.  But that is not the case here, if a MEM is misaligned, no
 equivalent changes to the XEXP (mem, 0) will make it aligned.

>>>
>>> You are right and *mov_internal must use the 'm' constraint
>>> so that LRA won't keep generating the same reload for
>>>
>>> (insn 353 322 323 8 (set (reg:V4SF 192)
>>> (reg:V4SF 201 [192])) 1226 {*movv4sf_internal}
>>>  (nil))
>>>
>>> until
>>>
>>> x.i: In function \u2018foo\u2019:
>>> x.i:29:1: internal compiler error: Max. number of generated reload
>>> insns per insn is achieved (90)
>>>
>>>  }
>>>  ^
>>>
>>> 0xc0d635 lra_constraints(bool)
>>> /export/gnu/import/git/sources/gcc/gcc/lra-constraints.c:4336
>>> 0xbf9854 lra(_IO_FILE*)
>>> /export/gnu/import/git/sources/gcc/gcc/lra.c:2277
>>> 0xba6489 do_reload
>>> /export/gnu/import/git/sources/gcc/gcc/ira.c:5385
>>> 0xba683c execute
>>> /export/gnu/import/git/sources/gcc/gcc/ira.c:5556
>>>
>>>
>>
>> Here are the updated patches.  I didn't change SSE
>> *mov_internal.  Tested on x86-64.  OK for
>> trunk?
>
> It is hard to determine the changed patterns - can you confirm that
> only patterns where ssememalign=0 are changed?
>
> Uros.

My patches only change SSE patterns without ssememalign
attribute, which defaults to

(define_attr "ssememalign" "" (const_int 0))



-- 
H.J.

Re: RFA: PR 68913: Provide weak version of __fread_chk for PR61886 test

[Jeff Law]

On 12/22/2015 02:54 AM, Nick Clifton wrote:

Hi Jeff,


   PR 68913 notes that the test gcc.dg/lto/pr61886_0.c test fails on
   targets whose C library does not provide a __fread_chk function.

   Since the purpose of the test is to show that GCC will correctly
   discard the invocation of __fread_chk_warn, we do not need to
actually
   link against a real __fread_chk function.  A dummy will do.



?  Isn'the purpose of this test to verify the function alias resolution
code?


I think that it is, but that the test does this by requiring that gcc
only generates code that calls __fread_chk.  Ie it does not generate any
code that calls __fread_chk_warn.  If gcc did generate code that calls
__fread_chk_warn then that function's warning attribute would be
triggered and we would get the warning message associated with it - and
the test would fail.
But does the existence of the weak fread_chk change the interactions 
inside IPA & LTO in such a way as to compromise the test?


One way to find out would be to check out a compiler before Honza's 
change which fixed 61886, verify the test as written fails, verify the 
test with your new weak symbol also fails.  Honza didn't fix this until 
early December, so you don't have to go terribly far back.






Since the test only links, it does not execute, there is no need to have
working versions of __fread_chk and __fread_chk_warn available.  All
that is necessary is that a symbol called __fread_chk is available at
link time.  (A symbol called __fread_chk_warn is not needed as
referencing this symbol triggers a warning, which causes the test to
fail).  So providing a weak definition of __fread_chk should be
sufficient for those runtimes which do not provide their own definition.
Right.  I'm not worried about any of this stuff.  I'm worried about the 
hideous problems with had in the IPA/LTO bits.  Just look at the long 
discussion in 61886.


jeff

Re: [CilkPlus] fix issues when cilk_spawn is used with nontrivial expressions

[Jeff Law]

On 12/25/2015 09:08 AM, Ryan Burn wrote:

This patch fixes issues with cilk_spawn where bad diagnostics are
emitted for expressions invoking conversion operators or constructor
calls (PR69024, PR68997).

It also fixes an issue with a missing CLEANUP_POINT_EXPR that causes
an ICE when gimplifying code containing a temporary with a destructor
(PR69048)

Bootstrapped and regression tested on x86_64-linux

2015-12-25  Ryan Burn

PR cilkplus/69024, PR cilkplus/68997, PR cilkplus/PR69048
* cilk.c (cilk_detect_spawn_and_unwrap): Use recursive function
find_spawn to search for the CILK_SPAWN_STMT.
  (cilk_ignorable_spawn_rhs_op): Also ignore COMPOUND_EXPR.
  (find_spawn): New.
  (is_conversion_operator_function_decl_p): New.
  (is_conversion_operator_call_p): New.
  (is_unary_constructor_aggr_init_p): New.
  (is_conversion_operator_aggr_init_p): New.
  (extract_free_variables): Don't extract the slot variable of
an AGGR_INIT_EXPR.
  (create_cilk_wrapper_body): Add CLEANUP_POINT_EXPR to the
spawn expression.

* gcc/testsuite/g++.dg/cilk-plus/CK/pr68997.cc : New test.

* gcc/testsuite/g++.dg/cilk-plus/CK/pr69024.cc : New test.

* gcc/testsuite/g++.dg/cilk-plus/CK/pr69048.cc : New test.

* gcc/testsuite/g++.dg/cilk-plus/CK/pr68001.cc : Removed check
depending on bad diagnostics.
Do you have a copyright assignment on file with the FSF?  This seems 
large enough to require one.



+static bool
+is_conversion_operator_function_decl_p (tree t) {
+  if (TREE_CODE (t) != FUNCTION_DECL)
+return false;
+
+  return DECL_NAME (t) && TREE_LANG_FLAG_4 (DECL_NAME (t));
At the least the use of TREE_LANG_FLAG here ought to document what 
you're checking for.  However, more likely the use is an indicator that 
you're doing something wrong.


Similarly for the use of TREE_LANG_FLAG_0.

Essentially those flags are allowed to have different meanings for each 
language.  AFAICT that their meaning varies for C/C++, so using them in 
a shared file like this is definitely suspect.



Each new function should have a block comment before it which briefly 
describes the function and return values.  See other existing functions 
for examples.



+  return VL_EXP_OPERAND_LENGTH (t) == 4
+&& TREE_CODE (fn) == ADDR_EXPR
+&& is_conversion_operator_function_decl_p (TREE_OPERAND (fn, 0));
For multi-line expressions, please wrap them in a outer set of 
parenthesis.  I think there was another instance earlier.




Jeff

Re: [PATCH 2/2] Ada: add XVE/XVU parallel types to lexical scopes

[Eric Botcazou]

> This change adds TYPE_DECL nodes for XVE/XVU parallel types to lexical
> scopes so that these types are properly scoped in the debug information.

OK, thanks.

-- 
Eric Botcazou

Re: [PATCH v2] ia64: don't use dynamic relocations for local symbols

[Jeff Law]

On 01/02/2016 04:50 AM, Sergei Trofimovich wrote:



I did ran tests only on amd64 host thus the execution failure tests.

Attached updated patch and test runs on a crosscompiler before
and after the change.

Now I'm building on real ia64 hardware as
 make bootstrap
 make -k check

for both clean and patched trees.
Thanks.  I also did a bootstrap & regression test since I had an ia64 
box provisioned when I was poking at your patch.


I've installed your patch on the trunk.
jeff

Re: [PATCH, PR67627][RFC] broken libatomic multilib parallel build

[Jeff Law]

On 12/17/2015 02:51 AM, Szabolcs Nagy wrote:

On 16/12/15 17:06, Jeff Law wrote:

On 12/04/2015 05:39 AM, Szabolcs Nagy wrote:

As described in pr other/67627, the all-multi target can be
built in parallel with the %_.lo targets which generate make
dependencies that are parsed during the build of all-multi.

gcc -MD does not generate the makefile dependencies in an
atomic way so make can fail if it concurrently parses those
half-written files.
(not observed on x86, but happens on arm native builds.)

this workaround forces all-multi to only run after the *_.lo
targets are done, but there might be a better solution using
automake properly. (automake should know about the generated
make dependency files that are included into the makefile so
no manual tinkering is needed to get the right build order,
but i don't know how to do that.)

2015-12-04  Szabolcs Nagy  

 PR other/67627
 * Makefile.am (all-multi): Add dependency.
 * Makefile.in: Regenerate.

So looking at the patch, it looks like you're adding
a dependency in Makefile.am to pass it through to
Makefile.in, which is fine.

So I think you just need to replicate that fix across
the other libraries which have this problem.



i don't see other libraries that use all-multi and
include auto-dependency generated makefiles as well.

only libatomic has both.

is it ok to commit and backport?
(gcc-5 and 4.9 have the same issue)

Sorry for the delay.

Yes, you're correct, it appears that only libatomic has this issue.

The patch is fine for the trunk and any release branches you want to 
backport to.


Thanks,
jeff

[PATCH] Fix -fdump-tree-fre ICE (PR tree-optimization/69141)

[Jakub Jelinek]

Hi!

On the following testcase we ICE, because fn is __builtin_unreachable
that doesn't have to have a cgraph node created.
The name method on cgraph nodes calls decl_printable_name, so the following
patch does that even if the cgraph node is NULL.

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

2016-01-05  Jakub Jelinek  

PR tree-optimization/69141
* tree-ssa-pre.c: Include langhooks.h.
(eliminate_dom_walker::before_dom_children): Use
lang_hooks.decl_printable_name instead of
cgraph_node::get ()->name ().

* g++.dg/opt/pr69141.C: New test.

--- gcc/tree-ssa-pre.c.jj   2016-01-04 14:55:53.0 +0100
+++ gcc/tree-ssa-pre.c  2016-01-05 10:15:40.209497116 +0100
@@ -52,6 +52,7 @@ along with GCC; see the file COPYING3.
 #include "tree-ssa-propagate.h"
 #include "ipa-utils.h"
 #include "tree-cfgcleanup.h"
+#include "langhooks.h"
 
 /* TODO:
 
@@ -4328,7 +4329,7 @@ eliminate_dom_walker::before_dom_childre
  dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, loc,
   "converting indirect call to "
   "function %s\n",
-  cgraph_node::get (fn)->name ());
+  lang_hooks.decl_printable_name (fn, 2));
}
  gimple_call_set_fndecl (call_stmt, fn);
  maybe_remove_unused_call_args (cfun, call_stmt);
--- gcc/testsuite/g++.dg/opt/pr69141.C.jj   2016-01-05 10:14:45.818265080 
+0100
+++ gcc/testsuite/g++.dg/opt/pr69141.C  2016-01-05 10:14:24.0 +0100
@@ -0,0 +1,15 @@
+// PR tree-optimization/69141
+// { dg-do compile }
+// { dg-options "-O2 -fdump-tree-fre" }
+
+struct B
+{
+  B *b;
+  B ();
+  virtual void f () = 0;
+};
+
+B::B () : b (this)
+{
+  b->f ();
+}

Jakub

Re: [PATCH] PR target/68991: Add vector_memory_operand and "Bm" constraint

[Uros Bizjak]

On Tue, Jan 5, 2016 at 8:20 PM, H.J. Lu  wrote:
> On Tue, Jan 5, 2016 at 11:14 AM, Uros Bizjak  wrote:
>> On Tue, Jan 5, 2016 at 7:58 PM, H.J. Lu  wrote:
>>> On Tue, Jan 5, 2016 at 4:32 AM, H.J. Lu  wrote:
 On Tue, Jan 5, 2016 at 12:11 AM, Jakub Jelinek  wrote:
> On Mon, Jan 04, 2016 at 03:25:48PM -0800, H.J. Lu wrote:
>> LRA is fine.  I should use
>>
>> (define_memory_constraint "Bm"
>>   "@internal Vector memory operand."
>>   (match_operand 0 "vector_memory_operand"))
>>
>> instead of
>>
>> (define_constraint "Bm"
>>   "@internal Vector memory operand."
>>   (match_operand 0 "vector_memory_operand"))
>
> I don't think so.  At least the documentation says that
> define_memory_constraint is for MEM constraints where if they are not
> satisfied they can be made to satisfy by forcing the address into a
> register.  But that is not the case here, if a MEM is misaligned, no
> equivalent changes to the XEXP (mem, 0) will make it aligned.
>

 You are right and *mov_internal must use the 'm' constraint
 so that LRA won't keep generating the same reload for

 (insn 353 322 323 8 (set (reg:V4SF 192)
 (reg:V4SF 201 [192])) 1226 {*movv4sf_internal}
  (nil))

 until

 x.i: In function \u2018foo\u2019:
 x.i:29:1: internal compiler error: Max. number of generated reload
 insns per insn is achieved (90)

  }
  ^

 0xc0d635 lra_constraints(bool)
 /export/gnu/import/git/sources/gcc/gcc/lra-constraints.c:4336
 0xbf9854 lra(_IO_FILE*)
 /export/gnu/import/git/sources/gcc/gcc/lra.c:2277
 0xba6489 do_reload
 /export/gnu/import/git/sources/gcc/gcc/ira.c:5385
 0xba683c execute
 /export/gnu/import/git/sources/gcc/gcc/ira.c:5556


>>>
>>> Here are the updated patches.  I didn't change SSE
>>> *mov_internal.  Tested on x86-64.  OK for
>>> trunk?
>>
>> It is hard to determine the changed patterns - can you confirm that
>> only patterns where ssememalign=0 are changed?
>>
>> Uros.
>
> My patches only change SSE patterns without ssememalign
> attribute, which defaults to
>
> (define_attr "ssememalign" "" (const_int 0))

The patch is OK for mainline.

(subst.md changes can IMO be considered obvious.)

Thanks,
Uros.

Re: [PATCH] -Winvalid-memory-model warning not given for stdatomic.h macros (PR c/69104)

[Jeff Law]

On 01/05/2016 08:00 AM, Marek Polacek wrote:

At present, we fail to warn about wrong memory orders for certain atomic
functions.  This happens for macros in stdatomic.h.  The fix is to use the
expansion point location rather than the input location.

While at it, I made a trivial fix to the wording of one of the warnings: don't
start with a capital and don't end the warning with a fullstop.

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

2016-01-05  Marek Polacek  

PR c/69104
* builtins.c (get_memmodel): Use expansion point location rather than
the input location.  Call warning_at rather than warning.
(expand_builtin_atomic_compare_exchange): Likewise.
(expand_builtin_atomic_load): Likewise.
(expand_builtin_atomic_store): Likewise.
(expand_builtin_atomic_clear): Likewise.

* gcc.dg/atomic-invalid-2.c: New.

OK.
jeff

Re: [PATCH] c/68966 - atomic_fetch_* on atomic_bool not diagnosed

[Martin Sebor]

I agree that the rules are sometimes tedious to follow (and rebasing
patches just to fix some formatting issues isn't exactly fun).  I don't
use git to commit either.  My "secret" is to enable highlighting of trailing
whitespaces in vim ("let c_space_errors=1"), but that's of no use to you
I guess.


Thanks.

I just downloaded and installed an Emacs equivalent called redspace.
It does the same thing.  Unfortunately, it also has the effect of
highlighting in red the one blank inserted by diff at the beginning
of empty lines. I guess the way to deal with that is to avoid
inserting blank spaces into changes to begin with rather than trying
to remove them from the final patch.


But there's this contrib/check_GNU_style.sh script that you can use,
which points out e.g. 8 spaces -> tabs.  Before posting a patch, I always do
'check_GNU_style z.patch'.
That might help.


I use the script on bigger patches.  I just haven't trained myself
to use it consistently, for all of them, and each time I post a new
revision of a patch for review.  (The script also complains about
tests where following the convention isn't always possible -- e.g.,
lines over 80 characters are unavoidable due to dg-error directives,
and periods can't be preceded by a space when they are part of
regular expressions in dg- directives..)

But what I'm hoping to find is a fully automated way of dealing
with this so I don't have to think about and waste other people's
time pointing it out.  (Ideally, it would be automated for everyone
so that none of us have to worry about it.  Perhaps a post-commit
hook could be put in place for this.)




Index: gcc/c-family/c-common.c

...


This change is unrelated.


Yes, sorry about that. It's yet another weakness in my workflow
(using the same local copy to test multiple unrelated changes).

A new patch is attached.

Martin
gcc/ChangeLog:
2016-01-04  Martin Sebor  

	PR c/68966
	* doc/extend.texi (__atomic Builtins, __sync Builtins): Document
	constraint on the type of arguments.

gcc/c-family/ChangeLog:
2016-01-04  Martin Sebor  

	PR c/68966
	* c-common.c (sync_resolve_size): Reject first argument when it's
	a pointer to _Bool.

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

	PR c/68966
	* gcc.dg/atomic-fetch-bool.c: New test.
	* gcc.dg/sync-fetch-bool.c: Same.

Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 232069)
+++ gcc/doc/extend.texi	(working copy)
@@ -9238,6 +9238,9 @@
 @{ tmp = *ptr; *ptr = ~(tmp & value); return tmp; @}   // nand
 @end smallexample
 
+The object pointed to by the first argument must be of integer or pointer
+type.  It must not be a Boolean type.
+
 @emph{Note:} GCC 4.4 and later implement @code{__sync_fetch_and_nand}
 as @code{*ptr = ~(tmp & value)} instead of @code{*ptr = ~tmp & value}.
 
@@ -9261,6 +9264,9 @@
 @{ *ptr = ~(*ptr & value); return *ptr; @}   // nand
 @end smallexample
 
+The same constraints on arguments apply as for the corresponding
+@code{__sync_op_and_fetch} built-in functions.
+
 @emph{Note:} GCC 4.4 and later implement @code{__sync_nand_and_fetch}
 as @code{*ptr = ~(*ptr & value)} instead of
 @code{*ptr = ~*ptr & value}.
@@ -9507,13 +9513,14 @@
 @deftypefnx {Built-in Function} @var{type} __atomic_or_fetch (@var{type} *ptr, @var{type} val, int memorder)
 @deftypefnx {Built-in Function} @var{type} __atomic_nand_fetch (@var{type} *ptr, @var{type} val, int memorder)
 These built-in functions perform the operation suggested by the name, and
-return the result of the operation. That is,
+return the result of the operation.  That is,
 
 @smallexample
 @{ *ptr @var{op}= val; return *ptr; @}
 @end smallexample
 
-All memory orders are valid.
+The object pointed to by the first argument must be of integer or pointer
+type.  It must not be a Boolean type.  All memory orders are valid.
 
 @end deftypefn
 
@@ -9530,7 +9537,8 @@
 @{ tmp = *ptr; *ptr @var{op}= val; return tmp; @}
 @end smallexample
 
-All memory orders are valid.
+The same constraints on arguments apply as for the corresponding
+@code{__atomic_op_fetch} built-in functions.  All memory orders are valid.
 
 @end deftypefn
 
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c	(revision 232069)
+++ gcc/c-family/c-common.c	(working copy)
@@ -10657,11 +10657,16 @@
 /* A helper function for resolve_overloaded_builtin in resolving the
overloaded __sync_ builtins.  Returns a positive power of 2 if the
first operand of PARAMS is a pointer to a supported data type.
-   Returns 0 if an error is encountered.  */
+   Returns 0 if an error is encountered.
+   FETCH is true when FUNCTION is one of the _FETCH_OP_ or _OP_FETCH_
+   built-ins.  */
 
 static int
-sync_resolve_size (tree function, vec *params)
+sync_resolve_size (tree function, vec *params, bool fetch)
 {
+  /* 

Re: [PATHCH] Disable inline asm for in-tree mpfr (PR69134)

[Bernd Edlinger]

Hi Jeff,

On 05.01.2016 19:21, Jeff Law wrote:
> On 01/05/2016 06:20 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> On 05.01.2016 13:58, Bernd Schmidt wrote:
>>> On 01/05/2016 09:44 AM, Bernd Edlinger wrote:
 an in-tree mpfr build enables inline asm code, which makes the
 mips-bootstrap fail,
 because at least mpfr 2.4.2 uses the "=h" constraint but in
 config/mips/constraints.md
 we find: "Formerly the @code{hi} register.  This constraint is no
 longer supported.".

 Using asm code is generally not desirable for in-tree mpfr builds.
>>>
>>> Why not?
>>
>> for the same reason why we disable the asm code for in-tree gmp.
>>
>> If we think mpfr is fine to use assembler, why don't we let gmp use the
>> assember code too?
>>
>> When we boot-strap to a different architecture we certainly do not want
>> to fiddle with inline-assember bugs, unless absolutely necessary.
> Given that we're already building against the mpfr-3.x.y API/ABI for 
> out-of-tree builds, what about just updating mpfr in the 
> infrastructure directory?  It's only the in-tree builds of mpfr that 
> are suffering and they're using an ancient mpfr.
>
> I guess you'd have to verify that it works and that doing so doesn't 
> require updating gmp and mpc.  But stepping forward seems like the 
> best solution to me.
>
> jeff

Maybe, that can of course improve things but...

I tried to update to gmp 6.0.0 a while ago, and I noticed that it won't 
build unless we also update to latest mpfr and mpc at the same time.

But from Marc Glisse's comment:

"Note that, at least with recent versions, if you configure gmp with 
--disable-assembly, the flag -DNO_ASM ends up in __GMP_CFLAGS (in gmp.h) 
and mpfr thus uses it automatically.

Hmm, that probably doesn't apply here since gcc passes its own CC and 
CFLAGS to mpfr, please ignore my message. "


I've learned, that it is the intention to mimic the --disable-assembly 
setting from gmp in mpfr, but we break that mechanism, by overwriting 
the CFLAGS
after configure modifies them.  For me the in-tree configuration was 
always like a convenience, that prefers safety over speed.


Bernd.

Re: [PATCH] Fix -fdump-tree-fre ICE (PR tree-optimization/69141)

[Jeff Law]

On 01/05/2016 11:20 AM, Jakub Jelinek wrote:

Hi!

On the following testcase we ICE, because fn is __builtin_unreachable
that doesn't have to have a cgraph node created.
The name method on cgraph nodes calls decl_printable_name, so the following
patch does that even if the cgraph node is NULL.

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

2016-01-05  Jakub Jelinek  

PR tree-optimization/69141
* tree-ssa-pre.c: Include langhooks.h.
(eliminate_dom_walker::before_dom_children): Use
lang_hooks.decl_printable_name instead of
cgraph_node::get ()->name ().

* g++.dg/opt/pr69141.C: New test.

OK.

jeff

[C++ PATCH] Fix #pragma implementation diagnostics (PR c++/69145)

[Jakub Jelinek]

Hi!

Now that input_location can be adhoc location (if it represents a location
range rather than a single loc and it is long enough), we need to avoid
passing it to cpp_included_before which compares locations as numbers.
This can't be done on the libcpp side, because cpp_included_before
isn't called with the line_table parameter.

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

2016-01-05  Jakub Jelinek  

PR c++/69145
* lex.c (handle_pragma_implementation): Pass LOCATION_LOCUS
of input_location instead of input_location itself to
cpp_included_before.

* g++.dg/ext/pr69145-1.C: New test.
* g++.dg/ext/pr69145-2-very-long-filename.cc: New file.
* g++.dg/ext/pr69145-2.h: New file.

--- gcc/cp/lex.c.jj 2016-01-04 14:55:57.0 +0100
+++ gcc/cp/lex.c2016-01-05 12:27:36.056749882 +0100
@@ -408,7 +408,8 @@ handle_pragma_implementation (cpp_reader
   else
 {
   filename = TREE_STRING_POINTER (fname);
-  if (cpp_included_before (parse_in, filename, input_location))
+  if (cpp_included_before (parse_in, filename,
+  LOCATION_LOCUS (input_location)))
warning (0, "#pragma implementation for %qs appears after "
 "file is included", filename);
 }
--- gcc/testsuite/g++.dg/ext/pr69145-1.C.jj 2016-01-05 12:22:58.206729760 
+0100
+++ gcc/testsuite/g++.dg/ext/pr69145-1.C2016-01-05 12:22:52.017818392 
+0100
@@ -0,0 +1,4 @@
+// PR c++/69145
+// { dg-do compile }
+#pragma implementation "pr69145-2-very-long-filename.cc" // { dg-bogus 
"appears after file is included" }
+#include "pr69145-2-very-long-filename.cc"
--- gcc/testsuite/g++.dg/ext/pr69145-2-very-long-filename.cc.jj 2016-01-05 
12:23:47.151028824 +0100
+++ gcc/testsuite/g++.dg/ext/pr69145-2-very-long-filename.cc2016-01-05 
12:23:42.629093583 +0100
@@ -0,0 +1,3 @@
+// PR c++/69145
+// { dg-do compile } */
+#include "pr69145-2.h"
--- gcc/testsuite/g++.dg/ext/pr69145-2.h.jj 2016-01-05 12:23:49.963988539 
+0100
+++ gcc/testsuite/g++.dg/ext/pr69145-2.h2016-01-05 12:06:42.0 
+0100
@@ -0,0 +1,3 @@
+#ifndef PR69145_2_H
+# define PR69145_2_H
+#endif

Jakub

[PATCH] Preserve user alignment on decls (PR middle-end/68960)

[Jakub Jelinek]

Hi!

When a VAR_DECL is copied (e.g. for OpenMP/OpenACC privatization, or
when moving SESE region to another function), copy_var_decl only preserves
user alignment on types, but not on decls.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2016-01-05  Jakub Jelinek  

PR middle-end/68960
* gimple-expr.c (copy_var_decl): If var has DECL_USER_ALIGN set, copy
it and DECL_ALIGN too.

* testsuite/libgomp.c/pr68960.c: New test.

--- gcc/gimple-expr.c.jj2016-01-04 14:55:52.0 +0100
+++ gcc/gimple-expr.c   2016-01-05 16:21:53.831077722 +0100
@@ -375,6 +375,11 @@ copy_var_decl (tree var, tree name, tree
   TREE_USED (copy) = 1;
   DECL_SEEN_IN_BIND_EXPR_P (copy) = 1;
   DECL_ATTRIBUTES (copy) = DECL_ATTRIBUTES (var);
+  if (DECL_USER_ALIGN (var))
+{
+  DECL_ALIGN (copy) = DECL_ALIGN (var);
+  DECL_USER_ALIGN (copy) = 1;
+}
 
   return copy;
 }
--- libgomp/testsuite/libgomp.c/pr68960.c.jj2016-01-05 16:26:34.957162544 
+0100
+++ libgomp/testsuite/libgomp.c/pr68960.c   2016-01-05 16:30:11.0 
+0100
@@ -0,0 +1,25 @@
+/* PR middle-end/68960 */
+/* { dg-do run } */
+
+int
+main ()
+{
+  int temp[257] __attribute__ ((aligned (256))) = { 0 };
+  #pragma omp parallel private (temp) num_threads (2)
+  {
+int *p = [0];
+asm volatile ("" : "+g" (p));
+if (((__UINTPTR_TYPE__) p) & 255)
+  __builtin_abort ();
+  }
+  #pragma omp parallel num_threads (2)
+  #pragma omp single
+  #pragma omp task firstprivate (temp)
+  {
+int *p = [0];
+asm volatile ("" : "+g" (p));
+if (((__UINTPTR_TYPE__) p) & 255)
+  __builtin_abort ();
+  }
+  return 0;
+}

Jakub

Re: [PATCH] Don't leak C_MAYBE_CONST_EXPRs into gimplifier from float-cast instrumentation (PR sanitizer/69099)

[Jeff Law]

On 01/05/2016 06:03 AM, Marek Polacek wrote:

The problem in this PR is that we were leaking C_MAYBE_CONST_EXPRs into the
gimplifier.  It was created in the float-cast instrumentation in convert().

Fixed by using the fully-folded EXPR only, thus without C_MAYBE_CONST_EXPR.
Which means that we can drop a parameter of ubsan_instrument_float_cast.
Seems that this doesn't hurt the diagnostics.

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

2016-01-05  Marek Polacek  

PR sanitizer/69099
* c-convert.c (convert) [INTEGER_TYPE]: Drop ARG.  Don't pass ARG to
ubsan_instrument_float_cast.  Fold EXPR.

* convert.c (convert_to_integer_1): Adjust call to
ubsan_instrument_float_cast.
* ubsan.c (ubsan_instrument_float_cast): Drop the ARG parameter.  Use
EXPR instead of ARG.
* ubsan.h (ubsan_instrument_float_cast): Adjust declaration.

* gcc.dg/ubsan/float-cast-overflow-atomic.c: New test.
OK.  You might want to mention the change from NULL to NULL_TREE in the 
ChangeLog as well.


jeff

Re: [PATCH] Fix pr69012 ICE on building libgfortran for mips

[Richard Sandiford]

Matthew Fortune  writes:
> Bernd Edlinger  writes:
>> On 30.12.2015 15:31, Richard Sandiford wrote:
>> > I think the problem is deeper than that though. The instructions that
>> > are triggering the ICE are only generated by the prologue, so this
>> > means that we're trying to lay out the frame again after the prologue
>> > has been generated, whereas it really needs to be fixed by then. (And
>> > even if recalculating it is a no-op, the operation is still too
>> > expensive to be repeated lightly.) Query functions like
>> > rtx_addr_can_trap_p(_1) shouldn't really be changing or recalculating
>> > the frame layout or other global state. I think we need to find a
>> > different way of getting the information. Maybe reload/LRA should use
>> > its own structures to calculate the range of "safe" stack and hfp
>> > offsets, then store them in crtl for rtx_addr_can_trap_p to use. AIUI,
>> > before reload, the only non-trapping uses of sp should be for outgoing
>> > arguments, so we can use a test based on the cumulative outgoing
>> > arguments size. I don't think the hfp should be used at all before
>> > reload, so we could conservatively return -1 for that case. Thanks,
>> > Richard
>> 
>> 
>> Yes, I agree, it _should_ be a no-op, but given the complexity of
>> mips_compute_frame_info it is probably better to use cached values after
>> reload completed.
>> 
>> Before reload_completed, rtx_addr_can_trap_p is just trying to do an
>> initial guess on the stack layout, it may well be possible that some
>> important information is still missing here.  We will never call the
>> target callback from here, before reload_completed.  It is however not
>> completely impossible that rtx_addr_can_trap_p is called while
>> lra/reload is already renaming the registers, see PR66614.

It sounds like we could then have the same kind of problem when
reload_in_progress though.  I.e. we'd have a predicate function like
rtx_addr_can_trap_p changing global state.  I realise the symptoms
wouldn't be the same as in this PR because the instructions that trigger
the ICE are part of the prologue, but it might show up in other ways.

E.g. LRA (like reload) loops until it reaches a stable stack layout.
If one iteration of the loop does something that changes the stack
layout (and so requires another go-round), calling rtx_addr_can_trap_p
before the loop restarts would alter the global state unexpectedly.
That might trigger an ICE.

If we need rtx_addr_can_trap_p to be as accurate as possible (rather
than conservative) during LRA/reload, I suppose we should calculate
the crtl fields I mentioned during each LRA/reload phase, rather than
at the end.

>> Of course the required information is already cached in
>> cfun->machine->frame, but rtx_addr_can_trap_p can't use the information
>> without a target callback.  And I just want to avoid to invent a new
>> callback for that.

Right.  I don't think we need or want a new callback.  My point was
that reload and LRA already compute the offsets you need, so it seems
better to cache them there than to try to recalculate them in rtlanal.c.

>> I looked at how other targets handle this situation and found that most
>> of them either have a more simple frame layout function or they keep the
>> previously cached values if they are ever called after reload_completed.
>> 
>> I found, previously mips_compute_frame_info was always called with
>> reload_completed=false, either from mips_frame_pointer_required or from
>> mips_initial_elimination_offset.  Reload seems to call the
>> initial_elimination_offset repeatedly and seems to _expect_ the values
>> to change from time to time.

Yeah.  This happens if the first reload attempt fails because there aren't
enough free registers or enough spill slots.  We then update the frame
layout to account for the new spill slots and call-saved register save
slots, then try again.

>> However it does not seem to expect the
>> result from mips_frame_pointer_required to change after reload/LRA has
>> started.  But as it seems, that may be possible for TARGET_MIPS16 if the
>> frame size happens to be very close to 0x7FFF. Well that could be
>> another story.

What kind of case were you thinking of?

>> Anyways when mips_compute_frame_info is called with
>> reload_completed=true, we can as well use the cached values, as they
>> were immediately before reload_completed.
>> 
>> So what do you think of my new version of the patch?
>
> Hi Bernd,
>
> I don't see any problem with this change from a MIPS backend perspective.
> As to whether rtx_addr_can_trap_p should be using initial_elimination_offset
> then I don't have any particular opinion.
>
> Richard: Any objections to using this fix so we can solve the PR leaving
> debate on the original rtx_addr_can_trap_p as a separate issue?

Well, it still feels to me like the patch is papering over the problem.
Like Bernd says, we didn't previously call mips_compute_frame_info 

[doc, committed] document RL78 saddr attribute

[Sandra Loosemore]

I've checked in this patch to add some minimal documentation for the 
RL78 "saddr" variable attribute.


-Sandra

2016-01-05  Sandra Loosemore 

	PR 1078
	gcc/
	* doc/extend.texi (RL78 Variable Attributes): New section.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 232085)
+++ gcc/doc/extend.texi	(working copy)
@@ -5453,6 +5453,7 @@ attributes.
 * Microsoft Windows Variable Attributes::
 * MSP430 Variable Attributes::
 * PowerPC Variable Attributes::
+* RL78 Variable Attributes::
 * SPU Variable Attributes::
 * V850 Variable Attributes::
 * x86 Variable Attributes::
@@ -6096,6 +6097,14 @@ documentation in @ref{x86 Variable Attri
 For documentation of @code{altivec} attribute please see the
 documentation in @ref{PowerPC Type Attributes}.
 
+@node RL78 Variable Attributes
+@subsection RL78 Variable Attributes
+
+@cindex @code{saddr} variable attribute, RL78
+The RL78 back end supports the @code{saddr} variable attribute.  This
+specifies placement of the corresponding variable in the SADDR area,
+which can be accessed more efficiently than the default memory region.
+
 @node SPU Variable Attributes
 @subsection SPU Variable Attributes
 

Re: [doc, committed] document MicroBlaze interrupt_handler and fast_interrupt attributes

[Michael Eager]

On 01/05/2016 10:08 AM, Sandra Loosemore wrote:

I've checked in this patch to add some minimal documentation for the MicroBlaze 
interrupt handler
attributes.  I was able to figure this out by inspection of the code and 
reading the processor
documentation, which has a more extensive discussion of how to use these 
features.

-Sandra


OK.

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

Re: [C++ PATCH] Fix #pragma implementation diagnostics (PR c++/69145)

[David Malcolm]

On Tue, 2016-01-05 at 19:23 +0100, Jakub Jelinek wrote:
> Hi!
> 
> Now that input_location can be adhoc location (if it represents a location
> range rather than a single loc and it is long enough), we need to avoid
> passing it to cpp_included_before which compares locations as numbers.
> This can't be done on the libcpp side, because cpp_included_before
> isn't called with the line_table parameter.
Isn't the line_table available from the cpp_reader as a field, though?
cpp_included_before could in theory access pfile->line_table.

That said, cp/lex.c seems to have the only usage of cpp_included_before.

> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2016-01-05  Jakub Jelinek  
> 
>   PR c++/69145
>   * lex.c (handle_pragma_implementation): Pass LOCATION_LOCUS
>   of input_location instead of input_location itself to
>   cpp_included_before.
> 
>   * g++.dg/ext/pr69145-1.C: New test.
>   * g++.dg/ext/pr69145-2-very-long-filename.cc: New file.
>   * g++.dg/ext/pr69145-2.h: New file.
> 
> --- gcc/cp/lex.c.jj   2016-01-04 14:55:57.0 +0100
> +++ gcc/cp/lex.c  2016-01-05 12:27:36.056749882 +0100
> @@ -408,7 +408,8 @@ handle_pragma_implementation (cpp_reader
>else
>  {
>filename = TREE_STRING_POINTER (fname);
> -  if (cpp_included_before (parse_in, filename, input_location))
> +  if (cpp_included_before (parse_in, filename,
> +LOCATION_LOCUS (input_location)))
>   warning (0, "#pragma implementation for %qs appears after "
>"file is included", filename);
>  }
> --- gcc/testsuite/g++.dg/ext/pr69145-1.C.jj   2016-01-05 12:22:58.206729760 
> +0100
> +++ gcc/testsuite/g++.dg/ext/pr69145-1.C  2016-01-05 12:22:52.017818392 
> +0100
> @@ -0,0 +1,4 @@
> +// PR c++/69145
> +// { dg-do compile }
> +#pragma implementation "pr69145-2-very-long-filename.cc" // { dg-bogus 
> "appears after file is included" }
> +#include "pr69145-2-very-long-filename.cc"
> --- gcc/testsuite/g++.dg/ext/pr69145-2-very-long-filename.cc.jj   
> 2016-01-05 12:23:47.151028824 +0100
> +++ gcc/testsuite/g++.dg/ext/pr69145-2-very-long-filename.cc  2016-01-05 
> 12:23:42.629093583 +0100
> @@ -0,0 +1,3 @@
> +// PR c++/69145
> +// { dg-do compile } */
> +#include "pr69145-2.h"
> --- gcc/testsuite/g++.dg/ext/pr69145-2.h.jj   2016-01-05 12:23:49.963988539 
> +0100
> +++ gcc/testsuite/g++.dg/ext/pr69145-2.h  2016-01-05 12:06:42.0 
> +0100
> @@ -0,0 +1,3 @@
> +#ifndef PR69145_2_H
> +# define PR69145_2_H
> +#endif
> 
>   Jakub

Re: [PATCH] libiberty: support demangling of rvalue reference typenames

[Ian Lance Taylor]

On Tue, Jan 5, 2016 at 12:38 PM, Artemiy Volkov  wrote:
> On Tue, Jan 05, 2016 at 07:26:36AM -0800, Ian Lance Taylor wrote:
>
>> If gdb is using the code in cplus-dem.c in any way for a program
>> compiled in the last 15 years, then gdb is doing something horribly
>> wrong.  What function is gdb calling that makes your patch make a
>> difference?
>
> This is what I'm doing, just the ordinary use of the demangle command...
>
> ➜ gdb gdb/gdb
> GNU gdb (GDB) 7.10.1
> Copyright (C) 2015 Free Software Foundation, Inc.
> [snip]
> (top-gdb) b cplus-dem.c:3636
> Breakpoint 3 at 0x8cf598: file ../../binutils-gdb/libiberty/cplus-dem.c,
> line 3636.
> (top-gdb) r
> Starting program: /home/w41/gdb-build/gdb/gdb
> [snip]
> (gdb) demangle -l c++ -- __20DisplayList_IteratorO11DisplayList
>
> Breakpoint 3, do_type (work=0x7fffdf40, mangled=0x7fffded0,
> result=0x11622b0) at ../../binutils-gdb/libiberty/cplus-dem.c:3636
> 3636type_quals = TYPE_UNQUALIFIED;
> (top-gdb) bt
> #0  do_type (work=0x7fffdf40, mangled=0x7fffded0,
> result=0x11622b0) at ../../binutils-gdb/libiberty/cplus-dem.c:3636
> #1  0x008d0b5c in do_arg (work=0x7fffdf40,
> mangled=0x7fffded0, result=0x7fffdde0)
> at ../../binutils-gdb/libiberty/cplus-dem.c:4231
> #2  0x008d1350 in demangle_args (work=0x7fffdf40,
> mangled=0x7fffded0, declp=0x7fffdee0)
> at ../../binutils-gdb/libiberty/cplus-dem.c:4514
> #3  0x008cb79a in demangle_signature (work=0x7fffdf40,
> mangled=0x7fffded0, declp=0x7fffdee0)
> at ../../binutils-gdb/libiberty/cplus-dem.c:1665
> #4  0x008ca778 in internal_cplus_demangle (work=0x7fffdf40,
> mangled=0xdf5132 "O11DisplayList")
> at ../../binutils-gdb/libiberty/cplus-dem.c:1203
> #5  0x008c9e0c in cplus_demangle (mangled=0xdf511a
> "__20DisplayList_IteratorO11DisplayList", options=3)
> at ../../binutils-gdb/libiberty/cplus-dem.c:886
> #6  0x007f2af0 in bfd_demangle (abfd=0x0, name=0xdf511a
> "__20DisplayList_IteratorO11DisplayList", options=3)
> at ../../binutils-gdb/bfd/bfd.c:1917
> #7  0x00781795 in gdb_demangle (name=0xdf511a
> "__20DisplayList_IteratorO11DisplayList", options=3)
> at ../../binutils-gdb/gdb/cp-support.c:1571
> #8  0x00695474 in language_demangle (current_language=0x9c0180
> ,
> mangled=0xdf511a "__20DisplayList_IteratorO11DisplayList",
> options=3) at ../../binutils-gdb/gdb/language.c:651
> #9  0x006a9189 in demangle_command (args=0xdf61a9 "-l c++ --
> __20DisplayList_IteratorO11DisplayList", from_tty=1)
> at ../../binutils-gdb/gdb/demangle.c:218
> #10 0x00507d64 in do_cfunc (c=0xeb1710, args=0xdf61a9 "-l c++ --
> __20DisplayList_IteratorO11DisplayList", from_tty=1)
> at ../../binutils-gdb/gdb/cli/cli-decode.c:105
> #11 0x0050ad01 in cmd_func (cmd=0xeb1710, args=0xdf61a9 "-l c++
> -- __20DisplayList_IteratorO11DisplayList", from_tty=1)
> at ../../binutils-gdb/gdb/cli/cli-decode.c:1885
> #12 0x00769272 in execute_command (p=0xdf61d8 "t", from_tty=1)
> at ../../binutils-gdb/gdb/top.c:475
> #13 0x006558c7 in command_handler (command=0xdf61a0 "demangle -l
> c++ -- __20DisplayList_IteratorO11DisplayList")
> at ../../binutils-gdb/gdb/event-top.c:491
> #14 0x00655e80 in command_line_handler (rl=0x1161910 "demangle
> -l c++ -- __20DisplayList_IteratorO11DisplayList")

Where is the symbol "__20DisplayList_IteratorO11DisplayList" coming from?

As far as I know no current C++ compiler will generate such a symbol.

Ian

Re: [PATCH] libiberty: {count,dup,write}argv: constify argv input slightly

[Mike Frysinger]

On 05 Jan 2016 07:32, Ian Lance Taylor wrote:
> On Sat, Jan 2, 2016 at 10:39 PM, Mike Frysinger  wrote:
> > Would be more useful if we could use "const char * const *", but there's
> > a long standing bug where gcc warns about incompatible pointers when you
> > try to pass in "char **".
> 
> That's not a bug.  It's how C works.  http://c-faq.com/ansi/constmismatch.html

i'm referring to the bugs filed/discussing the issue in the gcc tracker.
i'm aware of the (crap) standards.

> > We can at least constify the array itself as
> > gcc will not warn in that case.
> >
> > include/:
> > 2016-01-03  Mike Frysinger  
> >
> > * libiberty.h (dupargv): Change arg to char * const *.
> > (writeargv, countargv): Likewise.
> >
> > libiberty/:
> > 2016-01-03  Mike Frysinger  
> >
> > * argv.c (dupargv): Change arg to char * const *.  Update comment.
> > (writeargv, countargv): Likewise.
> > * functions.texi (dupargv, writeargv, countargv): Likewise.
> 
> This is OK if it bootstraps.  Thanks.

i've been testing this in gdb because gcc doesn't actually use dupargv or
countargv.  it does use writeargv in all of three places.

that said, it does bootstrap
-mike


signature.asc
Description: Digital signature

Re: [PATCH v2] ia64: don't use dynamic relocations for local symbols

[Sergei Trofimovich]

On Tue, 5 Jan 2016 10:41:14 -0700
Jeff Law  wrote:

> On 01/05/2016 02:39 AM, Eric Botcazou wrote:
> >> 'make bootstrap' works fine on ia64 but I've failed to run 'make check'.
> >> Testsuite's LD_LIBRARY_PATHs are not correct and can run tests.
> >
> > You need to run 'make -k check' from the top level build directory.
> No worries.  I had an ia64 box provisioned when I looked at this and I 
> just let it run the regression tests overnight.  Everything looks good.
> 
> jeff

Thank you!

[ Also found real cause of broken 'make -k check':
  I did not have devpts subsystem set correctly.
  Expect requires pseudoterminals to really work.
  Fixed that and tests run fine now. ]

-- 

  Sergei


signature.asc
Description: PGP signature

Re: [PATCH] Fix -Wmisleading indentation false-positive for do-while statement

[Bernd Schmidt]

On 01/05/2016 10:58 PM, David Malcolm wrote:


In general I don't think we can get any useful indentation warning out
of a do-while statement, so this patch makes it so that we just skip
them.

Is this OK to commit after testing?


It looks like this is PR c++/69029.  FWIW, I agree with your rationale -
though perhaps we should instead update the frontends to not even call
into c-indentation.c for do-while statements?


Ok with the PR mentioned in the ChangeLog as usual. I thought about 
David's idea, but I think it's reasonable to keep all knowledge inside 
c-indentation.c as in Patrick's patch.



Bernd

[Patch] Fix libstdc++ build when using uclibc instead of glibc

[Steve Ellcey]

While trying to build GCC with uclibc instead of glibc I ran into a build
failure in libstdc++.  uclibc doesn't seem to provide the isfinite function
like glibc does so that means that libstdc++ doesn't have std::isfinite.

This in turn caused include/ext/random.tcc to not compile because it uses
std::isfinite.  I can easily see how this might be considered a uclibc
bug but given that it is the only build problem I ran into I was hoping
we could fix it in libstdc++ by using __builtin_finite instead of
std::isfinite.  This fixes my uclibc build and also worked for glibc
with no regressions.

OK to checkin?

Steve Ellcey
sell...@imgtec.com


2016-01-05  Steve Ellcey  

* include/ext/random.tcc: Use __builtin_finite instead of
std::isfinite.


diff --git a/libstdc++-v3/include/ext/random.tcc 
b/libstdc++-v3/include/ext/random.tcc
index a9c5a2b..3467823 100644
--- a/libstdc++-v3/include/ext/random.tcc
+++ b/libstdc++-v3/include/ext/random.tcc
@@ -1570,7 +1570,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  return __t; });
  __norm = std::sqrt(__sum);
}
- while (__norm == _RealType(0) || ! std::isfinite(__norm));
+ while (__norm == _RealType(0) || ! __builtin_finite(__norm));
 
  std::transform(__ret.begin(), __ret.end(), __ret.begin(),
 [__norm](_RealType __val){ return __val / __norm; });

Re: [PATCH] Fix SLP ICE (PR tree-optimization/69083)

[Jeff Law]

On 01/04/2016 01:17 PM, Jakub Jelinek wrote:

Hi!

The vec-cmp SLP patch added
+ if (VECTOR_BOOLEAN_TYPE_P (vector_type))
+   {
+ /* Can't use VIEW_CONVERT_EXPR for booleans because
+of possibly different sizes of scalar value and
+vector element.  */
...
+   }
hunk a few lines above this spot, but that only handles constants.
For non-constants, the problem is similar, boolean vector element type might
have different size from the op's type, but it really should be fold
convertible to that, so while we can't use VCE, we can use a NOP_EXPR
instead.

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

2016-01-04  Jakub Jelinek  

PR tree-optimization/69083
* tree-vect-slp.c (vect_get_constant_vectors): For
VECTOR_BOOLEAN_TYPE_P assert op is fold_convertible_p to vector_type's
element type.  If op is fold_convertible_p to vector_type's element
type, use NOP_EXPR instead of VCE.

* gcc.dg/vect/pr69083.c: New test.

OK.
jeff

[doc, committed] document V850 function and variable attributes

[Sandra Loosemore]

In reviewing the state of target-specific attribute documentation for 
PR1078, I saw that there was no documentation for any of the V850 
attributes.  I was able to fill in the information from reading the code 
and referring to the existing docs for the -msda/-mtda/-mzda options.


-Sandra

2016-01-05  Sandra Loosemore 

	PR 1078
	gcc/
	* doc/extend.texi (V850 Function Attributes): New section.
	(V850 Variable Attributes): New section.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 232081)
+++ gcc/doc/extend.texi	(working copy)
@@ -2278,6 +2278,7 @@ GCC plugins may provide their own attrib
 * SH Function Attributes::
 * SPU Function Attributes::
 * Symbian OS Function Attributes::
+* V850 Function Attributes::
 * Visium Function Attributes::
 * x86 Function Attributes::
 * Xstormy16 Function Attributes::
@@ -5099,6 +5100,22 @@ depended upon to work reliably and are n
 @xref{Microsoft Windows Function Attributes}, for discussion of the
 @code{dllexport} and @code{dllimport} attributes.
 
+@node V850 Function Attributes
+@subsection V850 Function Attributes
+
+The V850 back end supports these function attributes:
+
+@table @code
+@item interrupt
+@itemx interrupt_handler
+@cindex @code{interrupt} function attribute, V850
+@cindex @code{interrupt_handler} function attribute, V850
+Use these attributes to indicate
+that the specified function is an interrupt handler.  The compiler generates
+function entry and exit sequences suitable for use in an interrupt handler
+when either attribute is present.
+@end table
+
 @node Visium Function Attributes
 @subsection Visium Function Attributes
 
@@ -5437,6 +5454,7 @@ attributes.
 * MSP430 Variable Attributes::
 * PowerPC Variable Attributes::
 * SPU Variable Attributes::
+* V850 Variable Attributes::
 * x86 Variable Attributes::
 * Xstormy16 Variable Attributes::
 @end menu
@@ -6086,6 +6104,29 @@ The SPU supports the @code{spu_vector} a
 documentation of this attribute please see the documentation in
 @ref{SPU Type Attributes}.
 
+@node V850 Variable Attributes
+@subsection V850 Variable Attributes
+
+These variable attributes are supported by the V850 back end:
+
+@table @code
+
+@item sda
+@cindex @code{sda} variable attribute, V850
+Use this attribute to explicitly place a variable in the small data area,
+which can hold up to 64 kilobytes.
+
+@item tda
+@cindex @code{tda} variable attribute, V850
+Use this attribute to explicitly place a variable in the tiny data area,
+which can hold up to 256 bytes in total.
+
+@item zda
+@cindex @code{zda} variable attribute, V850
+Use this attribute to explicitly place a variable in the first 32 kilobytes
+of memory.
+@end table
+
 @node x86 Variable Attributes
 @subsection x86 Variable Attributes
 

Re: [PATCH, testsuite] Fix g++.dg/pr67989.C test failure when running with -march or -mcpu

[Richard Earnshaw (lists)]

On 05/01/16 10:47, Kyrill Tkachov wrote:
> Hi Thomas,
> 
> On 05/01/16 07:37, Thomas Preud'homme wrote:
>> Hi,
>>
>> g++.dg/pr67989.C passes -march=armv4t to gcc when compiling which
>> fails if
>> RUNTESTFLAGS passes -mcpu or -march with a different value. This patch
>> adds a
>> dg-skip-if directive to skip the test when such a thing happens.
>>
>> ChangeLog entry is as follows:
>>
>>
>> *** gcc/testsuite/ChangeLog ***
>>
>> 2015-12-31  Thomas Preud'homme  
>>
>>  * g++.dg/pr67989.C: Skip test if already running it with
>> -mcpu or
>>  -march with different value.
>>
>>
>> diff --git a/gcc/testsuite/g++.dg/pr67989.C
>> b/gcc/testsuite/g++.dg/pr67989.C
>> index
>> 90261c450b4b9429fb989f7df62f3743017c7363..61be8e172a96df5bb76f7ecd8543dadf825e7dc7
>>
>> 100644
>> --- a/gcc/testsuite/g++.dg/pr67989.C
>> +++ b/gcc/testsuite/g++.dg/pr67989.C
>> @@ -1,5 +1,6 @@
>>   /* { dg-do compile } */
>>   /* { dg-options "-std=c++11 -O2" } */
>> +/* { dg-skip-if "do not override -mcpu" { arm*-*-* } { "-march=*"
>> "-mcpu=*" }
>> { "-march=armv4t" } } */
>>   /* { dg-additional-options "-marm -march=armv4t" { target arm*-*-* }
>> } */
>>   
> 
> How about we try to do it using the add_options_for_arm_arch_v4t machinery
> and the arm_arch_v4t_ok check?
> 
> I think the -marm part can go and can be added implicitly as part of
> multilib testing
> 

Or we could drop all the target-specific options as this is supposed to
be a generic test.  Yes, I realise this was the particular flag
combination required to trigger the original ICE, but no other target
running this test has target-specific options, so it seams a little
strange that ARM does.

R.


> Thanks,
> Kyrill
> 
> 
>>   __extension__ typedef unsigned long long int uint64_t;
>>
>>
>> Is this ok for stage3?
>>
>> Best regards,
>>
>> Thomas
>>
> 

adjust fallback_frame_state for 32bits AIX 7.1

[Olivier Hainque]

Hello,

This is a tiny change we have been using successfully for at least a couple
of years now, improving exception propagation through signal handlers on 32bits
AIX 7.1.

While this isn't a complete generalization to all possible configurations
(haven't had the time to converge on 64bits kernels at this stage, 
unfortunately),
this is nevertheless an improvement on 32bits.

The patch is very short and in line with what is already there, and we thought
it might be useful to others as well.

OK to commit ?

2015-01-05  Olivier Hainque  

libgcc/
* config/rs6000/aix-unwind.h (ucontext_for): Handle AIX 7.1
specificities. 



fallback-aix-7.1.diff
Description: Binary data

Re: [PATCH, testsuite] Fix g++.dg/pr67989.C test failure when running with -march or -mcpu

[Kyrill Tkachov]

Hi Thomas,

On 05/01/16 07:37, Thomas Preud'homme wrote:

Hi,

g++.dg/pr67989.C passes -march=armv4t to gcc when compiling which fails if
RUNTESTFLAGS passes -mcpu or -march with a different value. This patch adds a
dg-skip-if directive to skip the test when such a thing happens.

ChangeLog entry is as follows:


*** gcc/testsuite/ChangeLog ***

2015-12-31  Thomas Preud'homme  

 * g++.dg/pr67989.C: Skip test if already running it with -mcpu or
 -march with different value.


diff --git a/gcc/testsuite/g++.dg/pr67989.C b/gcc/testsuite/g++.dg/pr67989.C
index
90261c450b4b9429fb989f7df62f3743017c7363..61be8e172a96df5bb76f7ecd8543dadf825e7dc7
100644
--- a/gcc/testsuite/g++.dg/pr67989.C
+++ b/gcc/testsuite/g++.dg/pr67989.C
@@ -1,5 +1,6 @@
  /* { dg-do compile } */
  /* { dg-options "-std=c++11 -O2" } */
+/* { dg-skip-if "do not override -mcpu" { arm*-*-* } { "-march=*" "-mcpu=*" }
{ "-march=armv4t" } } */
  /* { dg-additional-options "-marm -march=armv4t" { target arm*-*-* } } */
  


How about we try to do it using the add_options_for_arm_arch_v4t machinery
and the arm_arch_v4t_ok check?

I think the -marm part can go and can be added implicitly as part of multilib 
testing

Thanks,
Kyrill



  __extension__ typedef unsigned long long int uint64_t;


Is this ok for stage3?

Best regards,

Thomas

Re: [PATCH] c/68966 - atomic_fetch_* on atomic_bool not diagnosed

[Marek Polacek]

On Mon, Jan 04, 2016 at 06:18:32PM -0700, Martin Sebor wrote:
> I've fixed the problems you pointed out in the attached patch.
> The typos are my bad.  As for the whitespace, I have to confess
> I'm finding all the rules tedious to follow without some sort
> of automation.  Jason suggested some option to git but I don't
> use git to commit (too many other problems).  I'm also not sure
> the option makes Git replace 8 spaces with TABs.  I tried to
> have my Emacs automatically strip trailing whitespace for me
> but that was causing spurious changes on otherwise untouched
> lines that already contain it (clearly, I'm not the only who
> struggles with whitespace).  I don't suppose everyone is
> voluntarily subjecting themselves to this torture so there
> must be a way to make it less onerous and painful.  What's
> your secret?

I agree that the rules are sometimes tedious to follow (and rebasing
patches just to fix some formatting issues isn't exactly fun).  I don't
use git to commit either.  My "secret" is to enable highlighting of trailing
whitespaces in vim ("let c_space_errors=1"), but that's of no use to you
I guess.  But there's this contrib/check_GNU_style.sh script that you can use,
which points out e.g. 8 spaces -> tabs.  Before posting a patch, I always do
'check_GNU_style z.patch'.
That might help.

> Index: gcc/c-family/c-common.c
> ===
> --- gcc/c-family/c-common.c   (revision 232047)
> +++ gcc/c-family/c-common.c   (working copy)
> @@ -7804,7 +7804,7 @@
>else if (TYPE_P (*node))
>  type = node, is_type = 1;
>  
> -  if ((i = check_user_alignment (align_expr, false)) == -1
> +  if ((i = check_user_alignment (align_expr, true)) == -1
>|| !check_cxx_fundamental_alignment_constraints (*node, i, flags))
>  *no_add_attrs = true;
>else if (is_type)

This change is unrelated.

Marek

Re: [PATCH, testsuite] Fix g++.dg/pr67989.C test failure when running with -march or -mcpu

[Kyrill Tkachov]

On 05/01/16 10:52, Richard Earnshaw (lists) wrote:

On 05/01/16 10:47, Kyrill Tkachov wrote:

Hi Thomas,

On 05/01/16 07:37, Thomas Preud'homme wrote:

Hi,

g++.dg/pr67989.C passes -march=armv4t to gcc when compiling which
fails if
RUNTESTFLAGS passes -mcpu or -march with a different value. This patch
adds a
dg-skip-if directive to skip the test when such a thing happens.

ChangeLog entry is as follows:


*** gcc/testsuite/ChangeLog ***

2015-12-31  Thomas Preud'homme  

  * g++.dg/pr67989.C: Skip test if already running it with
-mcpu or
  -march with different value.


diff --git a/gcc/testsuite/g++.dg/pr67989.C
b/gcc/testsuite/g++.dg/pr67989.C
index
90261c450b4b9429fb989f7df62f3743017c7363..61be8e172a96df5bb76f7ecd8543dadf825e7dc7

100644
--- a/gcc/testsuite/g++.dg/pr67989.C
+++ b/gcc/testsuite/g++.dg/pr67989.C
@@ -1,5 +1,6 @@
   /* { dg-do compile } */
   /* { dg-options "-std=c++11 -O2" } */
+/* { dg-skip-if "do not override -mcpu" { arm*-*-* } { "-march=*"
"-mcpu=*" }
{ "-march=armv4t" } } */
   /* { dg-additional-options "-marm -march=armv4t" { target arm*-*-* }
} */
   

How about we try to do it using the add_options_for_arm_arch_v4t machinery
and the arm_arch_v4t_ok check?

I think the -marm part can go and can be added implicitly as part of
multilib testing


Or we could drop all the target-specific options as this is supposed to
be a generic test.  Yes, I realise this was the particular flag
combination required to trigger the original ICE, but no other target
running this test has target-specific options, so it seams a little
strange that ARM does.


IIRC the problem in this PR was a fallback path in one of the
atomic operation expand routines, so it needs an architecture version
that is sufficiently low to not use the target-specific expanders.
That's why the armv4t was there.

Kyrill


R.



Thanks,
Kyrill



   __extension__ typedef unsigned long long int uint64_t;


Is this ok for stage3?

Best regards,

Thomas

Re: RFA: PR 66655: Use COFF/PE weak symbols

[Nick Clifton]

Hi Jeff,


You probably know the capabilities of COFF/PE better than I, so the
patch itself is fine.


Thanks - committed.


Is there any way that test can be shoved into our dejagnu testing
harness?  I think we've got support somewhere for tests which require
multiple input files.


dg-additional-sources is the command that you are thinking about.


The attached patch adds the test derived from the BZ.  There is one 
small problem - I could not find a way to stop the additional source 
file from being compiled as a test on its own.  When I investigated 
however it seems that is a common problem for all tests that use 
additional source files, so I do not think that it is a big issue.


Tested with no regressions on an x86_64-pc-linux-gnu toolchain.

OK to apply ?

Cheers
  Nick

gcc/testsuite/ChangeLog
2016-01-05  Nick Clifton  

PR target/66655
* g++.dg/pr66655.C: New test.
* g++.dg/pr66655_1.C: Additional source file for the test.
* g++.dg/pr66655.h: Header file for the test.
--- /dev/null	2016-01-05 08:31:00.212966083 +
+++ gcc/testsuite/g++.dg/pr66655.C	2016-01-05 10:42:01.769654305 +
@@ -0,0 +1,25 @@
+/* { dg-do run } */
+/* { dg-additional-sources "pr66655_1.C" } */
+
+#include "pr66655.h"
+
+extern "C" void abort (void);
+
+#define COOKIE 0xabcd0123
+
+int
+g (void)
+{
+  return COOKIE;
+}
+
+extern int f (void);
+
+int
+main (void)
+{
+  S::set(0);
+  if (f () != COOKIE)
+abort ();
+  return 0;
+}
--- /dev/null	2016-01-05 08:31:00.212966083 +
+++ gcc/testsuite/g++.dg/pr66655_1.C	2016-01-05 10:41:23.266433205 +
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+#include "pr66655.h"
+
+extern int g (void);
+
+int S::i;
+
+int
+f (void)
+{
+  int ret = g ();
+
+  S::set (ret);
+  return ret;
+}
--- /dev/null	2016-01-05 08:31:00.212966083 +
+++ gcc/testsuite/g++.dg/pr66655.h	2016-01-05 10:41:45.629561622 +
@@ -0,0 +1,5 @@
+struct S
+{
+  static int i;
+  static void set (int ii) { i = -ii; }
+};

Re: [PATCH] PR target/68991: Add vector_memory_operand and "Bm" constraint

[Richard Sandiford]

Jakub Jelinek  writes:
> On Mon, Jan 04, 2016 at 03:25:48PM -0800, H.J. Lu wrote:
>> LRA is fine.  I should use
>> 
>> (define_memory_constraint "Bm"
>>   "@internal Vector memory operand."
>>   (match_operand 0 "vector_memory_operand"))
>> 
>> instead of
>> 
>> (define_constraint "Bm"
>>   "@internal Vector memory operand."
>>   (match_operand 0 "vector_memory_operand"))
>
> I don't think so.  At least the documentation says that
> define_memory_constraint is for MEM constraints where if they are not
> satisfied they can be made to satisfy by forcing the address into a
> register.  But that is not the case here, if a MEM is misaligned, no
> equivalent changes to the XEXP (mem, 0) will make it aligned.

Yeah.  It seems like a missing feature though.  Maybe
define_memory_constraint should have two conditions, one for
when the MEM is valid and one for when the address is?
Guess that isn't stage 3 material though.  And maybe longer-term
we should avoid define_memory_constraint altogether and have an
automatic way of testing whether replacing the address with a
register is OK.

Thanks,
Richard

Re: [PATCH 2/4 v2][AArch64] Add support for FCCMP

[Evandro Menezes]

Hi, Wilco.

On 12/15/2015 04:32 AM, Wilco Dijkstra wrote:

-Original Message-
From: Wilco Dijkstra [mailto:wilco.dijks...@arm.com]
Sent: 17 November 2015 18:36
To: gcc-patches@gcc.gnu.org
Subject: [PATCH 2/4 v2][AArch64] Add support for FCCMP

(v2 version removes 4 enums)

This patch adds support for FCCMP. This is trivial with the new CCMP 
representation - remove the restriction of FP in ccmp.c and add
FCCMP patterns. Add a test to ensure FCCMP/FCCMPE are emitted as expected.

OK for commit?

ChangeLog:
2015-11-18  Wilco Dijkstra  

* gcc/ccmp.c (ccmp_candidate_p): Remove integer-only restriction.
* gcc/config/aarch64/aarch64.md (fccmp): New pattern.
(fccmpe): Likewise.
(fcmp): Rename to fcmp and globalize pattern.
(fcmpe): Likewise.
* gcc/config/aarch64/aarch64.c (aarch64_gen_ccmp_first): Add FP support.
(aarch64_gen_ccmp_next): Add FP support.

gcc/testsuite/
* gcc.target/aarch64/ccmp_1.c: New testcase.


Add support for the FCCMP insn types

2016-01-04  Evandro Menezes  

gcc/
* config/aarch64/aarch64.md (fccmp): Change insn type.
(fccmpe): Likewise.
* config/aarch64/thunderx.md (thunderx_fcmp): Add
   "fccmp{s,d}" types.
* config/arm/types.md (fccmps): Add new insn type.
(fccmpd): Likewise.
* config/arm/arm1020e.md (v10_ffarith): Add "fccmp{s,d}" types.
* config/arm/cortex-a17-neon.md (cortex_a17_vfp_cmp): Likewise.
* config/arm/cortex-a5.md (cortex_a5_fpalu): Likewise.
* config/arm/cortex-a53.md (cortex_a53_fpalu): Likewise.
* config/arm/cortex-a57.md (cortex_a57_fp_cmp): Likewise.
* config/arm/cortex-a7.md (cortex_a7_fpalu): Likewise.
* config/arm/cortex-a8-neon.md (cortex_a8_vfp_farith):
   Likewise.
* config/arm/cortex-a9.md (cortex_a9_fcmp): Likewise.
* config/arm/cortex-m7.md (cortex_m7_fpalu): Likewise.
* config/arm/marvell-pj4.md (pj4_vfp_cpy): Likewise.
* config/arm/vfp11.md (vfp_ffarith): Likewise.
* config/arm/xgene1.md (xgene1_fcmp): Likewise.
* config/arm/cortex-a15-neon.md (cortex_a15_vfp_cmps): Add
   "fccmps"
type.
(cortex_a15_vfp_cmpd): Add "fccmpd" type.
* config/arm/cortex-m4-fpu.md (cortex_m4_fcmps): Add
   "fccmps" type.
* config/arm/cortex-r4f.md (cortex_r4_ffariths): Likewise.
(cortex_r4_fcmpd): Add "fccmpd" type.
* config/arm/exynos-m1.md (exynos_m1_fp_ccmp): New insn
   reservation.

Here's what I had in mind when I inquired about distinguishing FCMP from 
FCCMP.  As you can see in the patch, Exynos is the only target that 
cares about it, but I wonder if ThunderX or Xgene would too.


What do you think?

Thank you,

--
Evandro Menezes

>From d96ede48a0adb46cec1f98acfe967fce22dcc406 Mon Sep 17 00:00:00 2001
From: Evandro Menezes 
Date: Mon, 4 Jan 2016 18:44:30 -0600
Subject: [PATCH] Add support for the FCCMP insn types

2016-01-04  Evandro Menezes  

gcc/
	* config/aarch64/aarch64.md (fccmp): Change insn type.
	(fccmpe): Likewise.
	* config/aarch64/thunderx.md (thunderx_fcmp): Add "fccmp{s,d}" types.
	* config/arm/types.md (fccmps): Add new insn type.
	(fccmpd): Likewise.
	* config/arm/arm1020e.md (v10_ffarith): Add "fccmp{s,d}" types.
	* config/arm/cortex-a17-neon.md (cortex_a17_vfp_cmp): Likewise.
	* config/arm/cortex-a5.md (cortex_a5_fpalu): Likewise.
	* config/arm/cortex-a53.md (cortex_a53_fpalu): Likewise.
	* config/arm/cortex-a57.md (cortex_a57_fp_cmp): Likewise.
	* config/arm/cortex-a7.md (cortex_a7_fpalu): Likewise.
	* config/arm/cortex-a8-neon.md (cortex_a8_vfp_farith): Likewise.
	* config/arm/cortex-a9.md (cortex_a9_fcmp): Likewise.
	* config/arm/cortex-m7.md (cortex_m7_fpalu): Likewise.
	* config/arm/marvell-pj4.md (pj4_vfp_cpy): Likewise.
	* config/arm/vfp11.md (vfp_ffarith): Likewise.
	* config/arm/xgene1.md (xgene1_fcmp): Likewise.
	* config/arm/cortex-a15-neon.md (cortex_a15_vfp_cmps): Add "fccmps"
	type.
	(cortex_a15_vfp_cmpd): Add "fccmpd" type.
	* config/arm/cortex-m4-fpu.md (cortex_m4_fcmps): Add "fccmps" type.
	* config/arm/cortex-r4f.md (cortex_r4_ffariths): Likewise.
	(cortex_r4_fcmpd): Add "fccmpd" type.
	* config/arm/exynos-m1.md (exynos_m1_fp_ccmp): New insn reservation.
---
 gcc/config/aarch64/aarch64.md | 4 ++--
 gcc/config/aarch64/thunderx.md| 2 +-
 gcc/config/arm/arm1020e.md| 2 +-
 gcc/config/arm/cortex-a15-neon.md | 4 ++--
 gcc/config/arm/cortex-a17-neon.md | 2 +-
 gcc/config/arm/cortex-a5.md   | 2 +-
 gcc/config/arm/cortex-a53.md  | 3 ++-
 gcc/config/arm/cortex-a57.md  | 2 +-
 gcc/config/arm/cortex-a7.md   | 3 ++-
 gcc/config/arm/cortex-a8-neon.md  | 3 ++-
 gcc/config/arm/cortex-a9.md   | 2 +-
 gcc/config/arm/cortex-m4-fpu.md   | 2 +-
 

Re: [doc, committed] document RL78 saddr attribute

[DJ Delorie]

> I've checked in this patch to add some minimal documentation for the 
> RL78 "saddr" variable attribute.

That's pretty much all there is to say about the saddr attribute, too.

Re: [PATCH] Fix -Wmisleading indentation false-positive for do-while statement

[David Malcolm]

On Tue, 2015-12-22 at 12:33 -0500, Patrick Palka wrote:
> We are emitting a bogus warning for the code
> 
>   do foo (0); while (flagA);
>   ^--- NEXT
>  ^ BODY
>   ^--- GUARD
> 
> In general I don't think we can get any useful indentation warning out
> of a do-while statement, so this patch makes it so that we just skip
> them.
> 
> Is this OK to commit after testing?

It looks like this is PR c++/69029.  FWIW, I agree with your rationale -
though perhaps we should instead update the frontends to not even call
into c-indentation.c for do-while statements?

> gcc/c-family/ChangeLog:
> 
>   * c-indentation.c (should_warn_for_misleading_indentation):
>   Don't warn about do-while statements.
> 
> gcc/testsuite/ChangeLog:
> 
>   * c-c++-common/Wisleading-indentation.c: Augment test.
> ---
>  gcc/c-family/c-indentation.c | 6 ++
>  gcc/testsuite/c-c++-common/Wmisleading-indentation.c | 2 ++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/gcc/c-family/c-indentation.c b/gcc/c-family/c-indentation.c
> index 638a9cf..1cbaab7 100644
> --- a/gcc/c-family/c-indentation.c
> +++ b/gcc/c-family/c-indentation.c
> @@ -202,6 +202,12 @@ should_warn_for_misleading_indentation (const 
> token_indent_info _tinfo,
>if (line_table->seen_line_directive)
>  return false;
>  
> +  /* We can't usefully warn about do-while statements since the bodies of 
> these
> + statements are always explicitly delimited at both ends, so control 
> flow is
> + quite obvious.  */
> +  if (guard_tinfo.keyword == RID_DO)
> +return false;
> +
>/* If the token following the body is a close brace or an "else"
>   then while indentation may be sloppy, there is not much ambiguity
>   about control flow, e.g.
> diff --git a/gcc/testsuite/c-c++-common/Wmisleading-indentation.c 
> b/gcc/testsuite/c-c++-common/Wmisleading-indentation.c
> index a3f5acd..72c21a0 100644
> --- a/gcc/testsuite/c-c++-common/Wmisleading-indentation.c
> +++ b/gcc/testsuite/c-c++-common/Wmisleading-indentation.c
> @@ -890,4 +890,6 @@ fn_39 (void)
> i < 10;
> i++);
>foo (i);
> +
> +  do foo (0); while (flagA);
>  }

Re: [patch] ARM FreeBSD fix bootstrap

[Andreas Tobler]

On 05.01.16 11:32, Richard Earnshaw (lists) wrote:

On 23/12/15 19:28, Andreas Tobler wrote:



2015-12-23  Andreas Tobler  

 * config/arm/freebsd.h: Rename SUBTARGET_OVERRIDE_OPTIONS to
 SUBTARGET_OVERRIDE_INTERNAL_OPTIONS. Adjust to check
 unaligned_access on the gcc_options set.
 * config/arm/arm.c (arm_option_override_internal): Use
 SUBTARGET_OVERRIDE_INTERNAL_OPTIONS.




This is OK.

One question, though, is whether you should explicitly override a user
request for unaligned accesses without at least warning that this is
being done.



Like this?

config/arm/freebsd.h:

#define SUBTARGET_OVERRIDE_INTERNAL_OPTIONS \
do {\
if (opts_set->x_unaligned_access == 1)   \
warning (0, "target CPU does not support unaligned accesses");\
if (opts->x_unaligned_access)\
opts->x_unaligned_access = 0;

Thank you for the feedback.

Andreas 

Re: [PATCH 2/4 v2][AArch64] Add support for FCCMP

[Andrew Pinski]

On Tue, Jan 5, 2016 at 2:00 PM, Evandro Menezes  wrote:
> Hi, Wilco.
>
> On 12/15/2015 04:32 AM, Wilco Dijkstra wrote:
>>>
>>> -Original Message-
>>> From: Wilco Dijkstra [mailto:wilco.dijks...@arm.com]
>>> Sent: 17 November 2015 18:36
>>> To: gcc-patches@gcc.gnu.org
>>> Subject: [PATCH 2/4 v2][AArch64] Add support for FCCMP
>>>
>>> (v2 version removes 4 enums)
>>>
>>> This patch adds support for FCCMP. This is trivial with the new CCMP
>>> representation - remove the restriction of FP in ccmp.c and add
>>> FCCMP patterns. Add a test to ensure FCCMP/FCCMPE are emitted as
>>> expected.
>>>
>>> OK for commit?
>>>
>>> ChangeLog:
>>> 2015-11-18  Wilco Dijkstra  
>>>
>>> * gcc/ccmp.c (ccmp_candidate_p): Remove integer-only restriction.
>>> * gcc/config/aarch64/aarch64.md (fccmp): New pattern.
>>> (fccmpe): Likewise.
>>> (fcmp): Rename to fcmp and globalize pattern.
>>> (fcmpe): Likewise.
>>> * gcc/config/aarch64/aarch64.c (aarch64_gen_ccmp_first): Add FP
>>> support.
>>> (aarch64_gen_ccmp_next): Add FP support.
>>>
>>> gcc/testsuite/
>>> * gcc.target/aarch64/ccmp_1.c: New testcase.
>
>
> Add support for the FCCMP insn types
>
> 2016-01-04  Evandro Menezes  
>
> gcc/
> * config/aarch64/aarch64.md (fccmp): Change insn type.
> (fccmpe): Likewise.
> * config/aarch64/thunderx.md (thunderx_fcmp): Add
>"fccmp{s,d}" types.
> * config/arm/types.md (fccmps): Add new insn type.
> (fccmpd): Likewise.
> * config/arm/arm1020e.md (v10_ffarith): Add "fccmp{s,d}" types.
> * config/arm/cortex-a17-neon.md (cortex_a17_vfp_cmp): Likewise.
> * config/arm/cortex-a5.md (cortex_a5_fpalu): Likewise.
> * config/arm/cortex-a53.md (cortex_a53_fpalu): Likewise.
> * config/arm/cortex-a57.md (cortex_a57_fp_cmp): Likewise.
> * config/arm/cortex-a7.md (cortex_a7_fpalu): Likewise.
> * config/arm/cortex-a8-neon.md (cortex_a8_vfp_farith):
>Likewise.
> * config/arm/cortex-a9.md (cortex_a9_fcmp): Likewise.
> * config/arm/cortex-m7.md (cortex_m7_fpalu): Likewise.
> * config/arm/marvell-pj4.md (pj4_vfp_cpy): Likewise.
> * config/arm/vfp11.md (vfp_ffarith): Likewise.
> * config/arm/xgene1.md (xgene1_fcmp): Likewise.
> * config/arm/cortex-a15-neon.md (cortex_a15_vfp_cmps): Add
>"fccmps"
> type.
> (cortex_a15_vfp_cmpd): Add "fccmpd" type.
> * config/arm/cortex-m4-fpu.md (cortex_m4_fcmps): Add
>"fccmps" type.
> * config/arm/cortex-r4f.md (cortex_r4_ffariths): Likewise.
> (cortex_r4_fcmpd): Add "fccmpd" type.
> * config/arm/exynos-m1.md (exynos_m1_fp_ccmp): New insn
>reservation.
>
> Here's what I had in mind when I inquired about distinguishing FCMP from
> FCCMP.  As you can see in the patch, Exynos is the only target that cares
> about it, but I wonder if ThunderX or Xgene would too.

For ThunderX, FCCMP and FCMP have both the same latency and executed
on the same pipeline so ThunderX does not care about the difference
between those two.

Thanks,
Andrew

>
> What do you think?
>
> Thank you,
>
> --
> Evandro Menezes
>

Re: [PATHCH] Disable inline asm for in-tree mpfr (PR69134)

[Bernd Schmidt]

On 01/05/2016 09:44 AM, Bernd Edlinger wrote:

an in-tree mpfr build enables inline asm code, which makes the mips-bootstrap 
fail,
because at least mpfr 2.4.2 uses the "=h" constraint but in 
config/mips/constraints.md
we find: "Formerly the @code{hi} register.  This constraint is no longer 
supported.".

Using asm code is generally not desirable for in-tree mpfr builds.


Why not?


So I looked for a way
to disable the asm code, and found it can be done, but differently than for 
in-tree gmp.
See the attached patch.


Fix mpfr instead not to use that constraint?


Bernd

[PATCH] Don't leak C_MAYBE_CONST_EXPRs into gimplifier from float-cast instrumentation (PR sanitizer/69099)

[Marek Polacek]

The problem in this PR is that we were leaking C_MAYBE_CONST_EXPRs into the
gimplifier.  It was created in the float-cast instrumentation in convert().

Fixed by using the fully-folded EXPR only, thus without C_MAYBE_CONST_EXPR.
Which means that we can drop a parameter of ubsan_instrument_float_cast.
Seems that this doesn't hurt the diagnostics.

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

2016-01-05  Marek Polacek  

PR sanitizer/69099
* c-convert.c (convert) [INTEGER_TYPE]: Drop ARG.  Don't pass ARG to
ubsan_instrument_float_cast.  Fold EXPR.

* convert.c (convert_to_integer_1): Adjust call to
ubsan_instrument_float_cast.
* ubsan.c (ubsan_instrument_float_cast): Drop the ARG parameter.  Use
EXPR instead of ARG.
* ubsan.h (ubsan_instrument_float_cast): Adjust declaration.

* gcc.dg/ubsan/float-cast-overflow-atomic.c: New test.

diff --git gcc/c/c-convert.c gcc/c/c-convert.c
index 5ee52eb..4167c34 100644
--- gcc/c/c-convert.c
+++ gcc/c/c-convert.c
@@ -111,20 +111,16 @@ convert (tree type, tree expr)
  && COMPLETE_TYPE_P (type)
  && do_ubsan_in_current_function ())
{
- tree arg;
  if (in_late_binary_op)
-   {
- expr = save_expr (expr);
- arg = expr;
-   }
+   expr = save_expr (expr);
  else
{
  expr = c_save_expr (expr);
- arg = c_fully_fold (expr, false, NULL);
+ expr = c_fully_fold (expr, false, NULL);
}
- tree check = ubsan_instrument_float_cast (loc, type, expr, arg);
+ tree check = ubsan_instrument_float_cast (loc, type, expr);
  expr = fold_build1 (FIX_TRUNC_EXPR, type, expr);
- if (check == NULL)
+ if (check == NULL_TREE)
return expr;
  return fold_build2 (COMPOUND_EXPR, TREE_TYPE (expr), check, expr);
}
diff --git gcc/convert.c gcc/convert.c
index 4b1e1f1..dd7d818 100644
--- gcc/convert.c
+++ gcc/convert.c
@@ -920,9 +920,9 @@ convert_to_integer_1 (tree type, tree expr, bool dofold)
  && do_ubsan_in_current_function ())
{
  expr = save_expr (expr);
- tree check = ubsan_instrument_float_cast (loc, type, expr, expr);
+ tree check = ubsan_instrument_float_cast (loc, type, expr);
  expr = build1 (FIX_TRUNC_EXPR, type, expr);
- if (check == NULL)
+ if (check == NULL_TREE)
return expr;
  return maybe_fold_build2_loc (dofold, loc, COMPOUND_EXPR,
TREE_TYPE (expr), check, expr);
diff --git gcc/testsuite/gcc.dg/ubsan/float-cast-overflow-atomic.c 
gcc/testsuite/gcc.dg/ubsan/float-cast-overflow-atomic.c
index e69de29..0a4fa01 100644
--- gcc/testsuite/gcc.dg/ubsan/float-cast-overflow-atomic.c
+++ gcc/testsuite/gcc.dg/ubsan/float-cast-overflow-atomic.c
@@ -0,0 +1,171 @@
+/* PR sanitizer/69099 */
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -pedantic-errors -fsanitize=float-cast-overflow" } */
+/* This is gcc.dg/atomic/c11-atomic-exec-2.c.  */
+
+extern void abort (void);
+extern void exit (int);
+
+#define CMPLX(X, Y) __builtin_complex ((X), (Y))
+
+#define TEST_COMPOUND(TYPE, LHSVAL, RHSVAL, OP)
\
+  do   \
+{  \
+  static volatile _Atomic (TYPE) a = (TYPE) (LHSVAL);  \
+  if ((a OP##= (RHSVAL)) != (TYPE) ((TYPE) (LHSVAL) OP (RHSVAL)))  \
+   abort ();   \
+  if (a != (TYPE) ((TYPE) (LHSVAL) OP (RHSVAL)))   \
+   abort ();   \
+}  \
+  while (0)
+
+#define TEST_COMPOUND_ARITH(LHSVAL, RHSVAL, OP)
\
+  do   \
+{  \
+  TEST_COMPOUND (_Bool, (LHSVAL), (RHSVAL), OP);   \
+  TEST_COMPOUND (char, (LHSVAL), (RHSVAL), OP);\
+  TEST_COMPOUND (signed char, (LHSVAL), (RHSVAL), OP); \
+  TEST_COMPOUND (unsigned char, (LHSVAL), (RHSVAL), OP);   \
+  TEST_COMPOUND (signed short, (LHSVAL), (RHSVAL), OP);\
+  TEST_COMPOUND (unsigned short, (LHSVAL), (RHSVAL), OP);  \
+  TEST_COMPOUND (signed int, (LHSVAL), (RHSVAL), OP);  \
+  TEST_COMPOUND (unsigned int, (LHSVAL), (RHSVAL), OP);\
+  TEST_COMPOUND (signed long, (LHSVAL), (RHSVAL), OP); \
+  TEST_COMPOUND (unsigned long, (LHSVAL), (RHSVAL), OP);   \
+  TEST_COMPOUND (signed long long, (LHSVAL), (RHSVAL), OP);
\
+