[PATCH] fixincludes: fix fixincludes for MinGW

[Tadek Kijkowski]

The fixincl executable uses system function to call applyfix or to
direcly patch a header file, with parameters enclosed in single
quotes. This problem is that MinGW system function just calls cmd.exe,
which doesn't strip quotes from parameters and completely ignores
quotes for embedding spaces in parameters. The MinGW system function
also doesn't allow for newlines in executed command parameters. As a
result fixincludes doesn't wotk at on when trying to build a cross
compiler with mingw as host.

On MinGW host, this patch adds system_with_shell function, which
transforms command passed to system function is following way:
- Enclose entire command in double quotes
- Prepend shell executable name, taken from environment variable SHELL
- Replace each occurence of newline with '$'\n'' sequence which is
understood by bash and ksh (it is assumed that all newlines are
embedded in command parameters enclosed in single quotes)

2016-09-23 Tadek Kijkowski (tkijkow...@gmail.com)

* fixincl.c: Added system_with_shell for MinGW host.


Index: fixincludes/fixincl.c
===
--- fixincludes/fixincl.c   (revision 240386)
+++ fixincludes/fixincl.c   (working copy)
@@ -170,7 +170,111 @@
   exit (EXIT_SUCCESS);
 }

+#ifdef __MINGW32__

+/* Count number of \c needle character instances in string */
+static int
+count_chars ( char* str, char needle )
+{
+  int instances = 0;
+
+  while (str)
+{
+   str = strchr (str, needle);
+   if (str)
+ {
+   ++str;
+   ++instances;
+ }
+}
+
+  return instances;
+}
+
+/* On Mingw32 system(3) will just start cmd by default.
+   Try using unix style shell passed via SHELL env. variable.
+ */
+
+/* Call system(3) function, but prepend ${SHELL} -c to the command,
+   replace newlines with '$'\n'' and enclose command with double quotes.
+ */
+static int
+system_with_shell ( char* s )
+{
+  static const char z_shell_start_args[] = " -c \"";
+  static const char z_shell_end_args[] = "\"";
+  static const char z_shell_newline[] = "'$'\\n''";
+
+  char* env_shell;
+  char* long_cmd;
+  char* cmd_endp;
+  size_t cmd_size;
+  int sys_result;
+  int newline_cnt;
+  char* nl_scan;
+
+  /* If SHELL variable is not defined just call standard shell function */
+  env_shell = getenv ("SHELL");
+  if (env_shell == NULL)
+return system (s);
+
+  /* Count number of newlines in command */
+  newline_cnt = count_chars(s, '\n');
+
+  /* Allocate enough memory to fit newly created command string */
+  cmd_size = strlen (env_shell) + (sizeof (z_shell_start_args) - 1)
+   + strlen (s) + newline_cnt * (sizeof(z_shell_newline) - 1 - 1)
+   + (sizeof (z_shell_end_args) - 1) + 1;
+
+  long_cmd = XNEWVEC (char, cmd_size);
+
+  /* Start with ${SHELL} -c " */
+  strcpy (long_cmd, env_shell);
+  strcat (long_cmd, z_shell_start_args);
+
+  /* End pointer for appending pieces of command while replacing newlines */
+  cmd_endp = long_cmd + strlen(long_cmd);
+  nl_scan = s;
+  while (nl_scan != NULL)
+{
+  char* next_nl = strchr (nl_scan, '\n');
+  if (next_nl)
+{
+  /* Append part of command between newlines */
+  size_t part_len = next_nl - nl_scan;
+  memcpy(cmd_endp, nl_scan, part_len);
+  cmd_endp += part_len;
+
+  /* Append newline replacement */
+  memcpy(cmd_endp, z_shell_newline, sizeof(z_shell_newline));
+  cmd_endp += sizeof(z_shell_newline) - 1;
+
+  /* Skip newline in src */
+  ++next_nl;
+}
+  else
+{
+  /* Last portion */
+  strcpy (cmd_endp, nl_scan);
+}
+  nl_scan = next_nl;
+}
+
+  /* Closing quote */
+  strcat (long_cmd, z_shell_end_args);
+
+  sys_result = system (long_cmd);
+
+  free ( (void*) long_cmd);
+
+  return sys_result;
+}
+
+#define system system_with_shell
+
+#endif /* defined(__MINGW32__) */
+
+
 static void
 do_version (void)
 {

Re: [PATCHv2][ARM] -mpure-code option for ARM

[Sandra Loosemore]

On 09/22/2016 07:52 AM, Richard Earnshaw (lists) wrote:

On 11/07/16 17:56, Andre Vieira (lists) wrote:

+
diff --git a/gcc/target.def b/gcc/target.def
index 
a4df363698ce776b51d11c187baed2069ba88a52..a3d46fa48d919a16699c33b2b78236e62a33e025
 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -432,6 +432,19 @@ this section is associated.",
   void, (const char *name, unsigned int flags, tree decl),
   default_no_named_section)

+/* Tell assembler what section attributes to assign this elf section
+   declaration, using their numerical value.  */
+DEFHOOK
+(elf_flags_numeric,
+ "If the target needs to represent ELF section attributes using their\n\
+numerical value, then this hook should be implemented to return true and\n\
+write the numerical value of @var{flags} in @var{num}.  This function is\n\
+called by @code{default_elf_asm_named_section}, which prints @var{num}\n\
+as the value representing the ELF section attributes if this function\n\
+returns true.",



I think this should read something like.

This hook can be used to encode ELF section flags for which no letter
code has been defined in the assembler.  It is called by
@code{default_asm_named_section} whenever the section flags need to be
emitted in the assembler output.  If the hook returns true, then the
numerical value for ELF section flags should be calculated from
@var{flags} and saved in @var{*num}; the value will be printed out
instead of the normal sequence of letter codes.  If the hook is not
defined, or if it returns false, then @var{num} will be ignored and the
traditional letter sequence will be emitted.


Can we please write this in the present tense instead of the future, 
assuming it describes current behavior (as modified by the patch)?


s/will be/is/g

-Sandra

Re: gcc build problem (i386.c) -- missing declaration

[Anton Blanchard]

Hi,

>  extern unsigned hook_uint_void_0 (void);  
>  extern unsigned int hook_uint_mode_0 (machine_mode);  
> +extern bool hook_uint_uintp_false (unsigned int, unsigned int *);  

I'm seeing the same build issue on ppc64le, and your patch fixes it.
Thanks.

Anton

Re: [PATCH] Extend dg-{error,warning,message,bogus} line specification to allow relative line numbers

[Mike Stump]

On Sep 22, 2016, at 1:05 PM, Jakub Jelinek  wrote:
> This is something I've been unhappy for a long time with

:-)  Me too.

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

Ok.  Thanks.

Re: [PATCH] accept flexible arrays in struct in unions (c++/71912 - [6/7 regression])

[Martin Sebor]

On 09/21/2016 02:43 PM, Jason Merrill wrote:

On Tue, Sep 20, 2016 at 1:01 PM, Martin Sebor  wrote:

On 09/16/2016 12:19 PM, Jason Merrill wrote:

On 09/14/2016 01:03 PM, Martin Sebor wrote:


+  /* Type of the member.  */
+  tree fldtype = TREE_CODE (fld) == FIELD_DECL ? TREE_TYPE (fld)
: fld;


Why set "fldtype" to be a TYPE_DECL rather than its type?


I'm not sure I understand the question but (IIRC) the purpose of
this code is to detect invalid uses of flexible array members in
typedefs such as this:

   struct S { typedef struct { int i, a[]; } X2 [2]; };

Sadly, it doesn't do anything for

   struct X { int i, a[]; };
   struct S { typedef struct X X2 [2]; };


The issue is I don't see anything that uses fldtype as a decl, and
it's strange to have a variable called "*type" that can either be a
type or a decl, which later code still assumes will be a type.


I suspect I'm simply looking at it from a different point of view.
The definition

  tree fldtype = TREE_CODE (fld) == FIELD_DECL ? TREE_TYPE (fld) : fld

denotes the type of the field if fld is a data member.  Otherwise,
it denotes a type (like a typedef).  Fldtype seems as a good a name
as any but I'll gladly rename it to something else if that lets us
move forward.  What would you prefer?


+  /* The context of the flexible array member.  Either the struct
+ in which it's declared or, for anonymous structs and unions,
+ the struct/union of which the array is effectively a member.  */
+  tree fmemctx = anon_context (fmem->array);
+  bool anon_p = fmemctx != DECL_CONTEXT (fmem->array);
+  if (!anon_p)
+fmemctx = t;


Why do you need to do something different here based on anon_p?  I don't
see why that would affect whether we want to look through intermediate
non-anonymous classes.


In code like this:

   struct X { int n, a[]; };
   struct Y { int n, b[]; };

   struct D: X, Y { };

The test above make the diagnostic point to the context of the invalid
flexible array member, or Y::b, rather than that of X. Without it, we
end up with:

   error: flexible array member ‘X::a’ not at end of ‘struct X’

rather than with

   error: flexible array member ‘X::a’ not at end of ‘struct D’


Yes, but why does whether we want to talk about X or D change if a is
wrapped in struct { }?


Sorry, I don't understand the question.  A flexible array is always
"wrapped in struct { }" so I'm not sure what you mean by that.  And
"we want to talk about D" because that's where the next member after
a is defined (we could also say it's defined in struct Y and I think
I may have been down that path at one point and decided this was fine
or perhaps even better or simpler but I don't recall which for sure.)

Btw., I used quotes above only to explain how I read your question,
not to mock what you said in any way.

Going back and looking at some of the older patches, this hunk above
was changed from the original patch like so:

@@ -6923,7 +6930,10 @@ diagnose_flexarrays (tree t, const flexmems_t *fmem)
 /* The context of the flexible array member.  Either the struct
in which it's declared or, for anonymous structs and unions,
the struct/union of which the array is effectively a member.  */
-tree fmemctx = fmem->anonctx ? fmem->anonctx : t;
+tree fmemctx = anon_context (fmem->array);
+bool anon_p = fmemctx != DECL_CONTEXT (fmem->array);
+if (!anon_p)
+  fmemctx = t;

I made this change because you preferred deriving the fmemctx value
in a new function rather than storing it the fmem->anonctx member.
I don't know if this helps clarify it.

  https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00153.html

(FWIW, it's been a stressful couple of days with the regressions
that my recent commit caused, so I hope you can bear with me if
I seem slow or dense on these two points.)




+  check_flexarrays (basetype, fmem, true);


Please decorate boolean literal arguments like this with the name of the
parameter, e.g. /*base_p*/true.


Sure.  I should mention that Jeff recently advised against it in
another review, so it would be nice to adopt the same convention
throughout and document it (I'm happy to add it to the Wiki once
it has been agreed on):

   https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00354.html


Interesting.  It's pretty common in the C++ front end.


FWIW, I haven't found mentioning the formal argument in a comment
a useful or consistent convention.  Other arguments' names aren't
mentioned, and the bool argument's name cannot be mentioned when
it has a default value.


True, but other arguments usually have more implied meaning and so I
think they are less of a barrier to reading.


On the other hand, a convention I do find useful (though not one
that seems to be used in GCC) is indicating in a comment in the
definition of a function the value of the default argument in
functions declared to take one.


I agree that would be a good convention.


I'm happy to start a separate discussion on 

gcc build problem (i386.c) -- missing declaration

[Louis Krupp]

As of revision 240383 , i386.c isn't compiling.  The errors are:  
  
In file included from ../../gcc_trunk/gcc/target-def.h:106:0,  
 from ../../gcc_trunk/gcc/config/i386/i386.c:81:  
./target-hooks-def.h:92:38: error: ‘hook_uint_uintp_false’ was not declared in 
this scope  
 #define TARGET_ASM_ELF_FLAGS_NUMERIC hook_uint_uintp_false  
  ^  
./target-hooks-def.h:2205:5: note: in expansion of macro 
‘TARGET_ASM_ELF_FLAGS_NUMERIC’  
 TARGET_ASM_ELF_FLAGS_NUMERIC, \  
 ^~~~  
./target-hooks-def.h:1792:5: note: in expansion of macro ‘TARGET_ASM_OUT’  
 TARGET_ASM_OUT, \  
 ^~  
../../gcc_trunk/gcc/config/i386/i386.c:50811:29: note: in expansion of macro 
‘TARGET_INITIALIZER’  
 struct gcc_target targetm = TARGET_INITIALIZER;  
  
The problem seems to be that hook_uint_uintp_false() was added to hooks.c but 
not to hooks.h.  I have things working on my copy with this change:  
  
--- hooks.h (revision 240383)  
+++ hooks.h (working copy)  
@@ -95,6 +95,7 @@ extern tree hook_tree_tree_int_treep_bool_null (tr  
  
 extern unsigned hook_uint_void_0 (void);  
 extern unsigned int hook_uint_mode_0 (machine_mode);  
+extern bool hook_uint_uintp_false (unsigned int, unsigned int *);  
  
 extern bool default_can_output_mi_thunk_no_vcall (const_tree, HOST_WIDE_INT,  
  HOST_WIDE_INT, const_tree);  
  
If I'm not missing something, and if this is a genuine build problem, and if 
this change looks good, I can commit it unless someone else is in the process 
of doing that.  I just need someone's approval.  (I should add that I'm on the 
Fortran commit-after-approval list, but I'm not on a general gcc list as far as 
I know.) 
 
Louis Krupp  

[openacc] fix an ICE with acc declared VLAs

[Cesar Philippidis]

There's a bug with ACC DECLARE clauses involving VLA variables that
causes lower_omp_target to thow an ICE on VLA decls. The problem
occurred because those clauses are never gimplified. This patch resolves
that ICE by teaching gimplify_oacc_declare how to gimplify them.

It turns out that gimplify_adjust_omp_clauses removes the
gimplify_omp_ctx created by gimplify_scan_omp_clauses. To workaround
that problem, I just taught gimplify_oacc_declare to ensure that each
gimplified decl has an "oacc declare target" attribute. This seems like
a reasonable solution because acc declare is an executable directive,
and hence really doesn't have a normal scope like ACC DATA. The declare
code does install destructors to unmap those clauses (except for those
vars which were ACC DECLARE CREATE'd -- but that's a problem for patch),
but that doesn't depend on the gimplify omp ctx. The only other major
thing that had to be updated was oacc_default_clause, because
omp_notice_variable no longer has a gimple omp ctx to inspect for
existing variables. But that's where the "oacc declare target" attribute
comes into play.

Is this patch OK for trunk?

Cesar
2016-09-22  Cesar Philippidis  

	gcc/
	* gimplify.c (is_oacc_declared): New function.
	(oacc_default_clause): Use it to set default flags for acc declared
	variables inside parallel regions.
	(gimplify_scan_omp_clauses): Strip firstprivate pointers for acc
	declared variables.
	(gimplify_oacc_declare): Gimplify the declare clauses.  Add the
	declare attribute to any decl as necessary.

	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/declare-vla.c: New test.


diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index e378ed0..19095ff 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -6114,6 +6114,16 @@ device_resident_p (tree decl)
   return false;
 }
 
+/* Return true if DECL has an ACC DECLARE attribute.  */
+
+static bool
+is_oacc_declared (tree decl)
+{
+  tree t = TREE_CODE (decl) == MEM_REF ? TREE_OPERAND (decl, 0) : decl;
+  tree declared = lookup_attribute ("oacc declare target", DECL_ATTRIBUTES (t));
+  return declared != NULL_TREE;
+}
+
 /* Determine outer default flags for DECL mentioned in an OMP region
but not declared in an enclosing clause.
 
@@ -6214,6 +6224,7 @@ oacc_default_clause (struct gimplify_omp_ctx *ctx, tree decl, unsigned flags)
 {
   const char *rkind;
   bool on_device = false;
+  bool declared = is_oacc_declared (decl);
   tree type = TREE_TYPE (decl);
 
   if (lang_hooks.decls.omp_privatize_by_reference (decl))
@@ -6244,7 +6255,7 @@ oacc_default_clause (struct gimplify_omp_ctx *ctx, tree decl, unsigned flags)
 
 case ORT_ACC_PARALLEL:
   {
-	if (on_device || AGGREGATE_TYPE_P (type))
+	if (on_device || AGGREGATE_TYPE_P (type) || declared)
 	  /* Aggregates default to 'present_or_copy'.  */
 	  flags |= GOVD_MAP;
 	else
@@ -6714,6 +6725,7 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq *pre_p,
   case OMP_TARGET_DATA:
   case OMP_TARGET_ENTER_DATA:
   case OMP_TARGET_EXIT_DATA:
+  case OACC_DECLARE:
   case OACC_HOST_DATA:
 	ctx->target_firstprivatize_array_bases = true;
   default:
@@ -8589,20 +8601,28 @@ gimplify_oacc_declare (tree *expr_p, gimple_seq *pre_p)
 {
   tree expr = *expr_p;
   gomp_target *stmt;
-  tree clauses, t;
+  tree clauses, t, decl;
 
   clauses = OACC_DECLARE_CLAUSES (expr);
 
   gimplify_scan_omp_clauses (, pre_p, ORT_TARGET_DATA, OACC_DECLARE);
+  gimplify_adjust_omp_clauses (pre_p, NULL, , OACC_DECLARE);
 
   for (t = clauses; t; t = OMP_CLAUSE_CHAIN (t))
 {
-  tree decl = OMP_CLAUSE_DECL (t);
+  decl = OMP_CLAUSE_DECL (t);
 
   if (TREE_CODE (decl) == MEM_REF)
-	continue;
+	decl = TREE_OPERAND (decl, 0);
 
-  if (TREE_CODE (decl) == VAR_DECL
+  if (VAR_P (decl) && !is_oacc_declared (decl))
+	{
+	  tree attr = get_identifier ("oacc declare target");
+	  DECL_ATTRIBUTES (decl) = tree_cons (attr, NULL_TREE,
+	  DECL_ATTRIBUTES (decl));
+	}
+
+  if (VAR_P (decl)
 	  && !is_global_var (decl)
 	  && DECL_CONTEXT (decl) == current_function_decl)
 	{
@@ -8616,7 +8636,8 @@ gimplify_oacc_declare (tree *expr_p, gimple_seq *pre_p)
 	}
 	}
 
-  omp_add_variable (gimplify_omp_ctxp, decl, GOVD_SEEN);
+  if (gimplify_omp_ctxp)
+	omp_add_variable (gimplify_omp_ctxp, decl, GOVD_SEEN);
 }
 
   stmt = gimple_build_omp_target (NULL, GF_OMP_TARGET_KIND_OACC_DECLARE,
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla.c
new file mode 100644
index 000..3ea148e
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla.c
@@ -0,0 +1,25 @@
+/* Verify that acc declare accept VLA variables.  */
+
+#include 
+
+int
+main ()
+{
+  int N = 1000;
+  int i, A[N];
+#pragma acc declare copy(A)
+
+  for (i = 0; i < N; i++)
+A[i] = -i;
+
+#pragma acc kernels
+  for (i = 0; i < N; i++)
+A[i] = i;
+
+#pragma acc update host(A)
+
+  for (i = 0; 

ICE at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu

[kugan]

Hi,
As Richard pointed out in PR77677, TREE_OVERFLOW is not cleared in 
IPA-VRP. There are three places in which we set value_range:



1. When value ranges are obtained from SSA_NAME with get_range_info with 
wide_int_to_tree. In this case we will not have TREE_OVERFLOW set.


2. When we vrp_meet/vrp_intersect_ranges two ranges. It does 
int_const_binop but AFAIK this does not set TREE_OVERFLOW.


3. When we create range from constant. This is the problem bit and we 
need to clear TREE_OVERFLOW here.


Attached patch clears the TREE_OVERFLOW in 3rd case. Bootstrap and 
regression testing are ongoing. Is this OK if there is no regression.


Thanks,
Kugan


gcc/ChangeLog:

2016-09-23  Kugan Vivekanandarajah  

PR ipa/77677
* ipa-cp.c (propagate_vr_accross_jump_function):Drop TREE_OVERFLOW
from constant while creating value range.

gcc/testsuite/ChangeLog:

2016-09-23  Kugan Vivekanandarajah  

PR ipa/77677
* gcc.dg/torture/pr77677.c: New test.
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index cb60f1e..f735ef7 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -2065,6 +2065,8 @@ propagate_vr_accross_jump_function (cgraph_edge *cs,
   tree val = ipa_get_jf_constant (jfunc);
   if (TREE_CODE (val) == INTEGER_CST)
{
+ if (TREE_OVERFLOW_P (val))
+   val = drop_tree_overflow (val);
  jfunc->vr_known = true;
  jfunc->m_vr.type = VR_RANGE;
  jfunc->m_vr.min = val;
diff --git a/gcc/testsuite/gcc.dg/torture/pr77677.c 
b/gcc/testsuite/gcc.dg/torture/pr77677.c
index e69de29..af3f0b0 100644
--- a/gcc/testsuite/gcc.dg/torture/pr77677.c
+++ b/gcc/testsuite/gcc.dg/torture/pr77677.c
@@ -0,0 +1,18 @@
+/* PR ipa/77677 */
+/* { dg-do compile } */
+
+int a, b;
+
+static void fn1 (short p1)
+{
+  a = -p1;
+  if (a || b)
+__builtin_printf ("%d\n", b);
+}
+
+int main ()
+{
+  int c[] = { 4 };
+  fn1 (c[0]);
+  return 0;
+}

RE: [PATCH] Fix PR tree-optimization/77654

[Doug Gilmore]

> From: Richard Biener [rguent...@suse.de]
> Sent: Thursday, September 22, 2016 12:43 AM
> To: Doug Gilmore
> Cc: gcc-patches@gcc.gnu.org; rgue...@gcc.gnu.org
> Subject: RE: [PATCH] Fix PR tree-optimization/77654
> 
> On Wed, 21 Sep 2016, Doug Gilmore wrote:
> 
> ...
> > Sorry I that missed point.  I glossed your comment "addr_base should
> > always be a pointer", causing me to go off into the weeds.
> >
> > New patch attached.
> 
> Ok if successfully bootstrapped / tested.
> 
> Thanks,
> Richard.
The change bootstrapped on X86_64 and the several "make check" errors
also appeared in latest archived mail message to gcc-testresults.

Thanks,
Doug
> 
> > ...

Re: [PATCH] builtin expansion of memcmp for powerpc

[Segher Boessenkool]

Hi Aaron,

On Thu, Sep 22, 2016 at 03:10:24PM -0500, Aaron Sawdey wrote:
> The powerpc target had a movmemsi pattern which supports memcpy() but
> did not have anything for memcmp(). This adds support for builtin
> expansion of memcmp() into inline code for modest constant lengths.
> Performance on power8 is in the range of 3-7x faster than calling
> memcmp() for lengths under 40 bytes.
> 
> Bootstrap on powerpc64le, regtest in progress, OK for trunk if no new
> regressions?

[ You are testing on BE and 32-bit as well, thanks. ]

Just a bit more formatting, and one nit:

> 2016-09-22  Aaron Sawdey  
> 
PR target/77685   <<<--- please add this here
>   * config/rs6000/rs6000.md (cmpmemsi): New define_expand.
>   * config/rs6000/rs6000.c (expand_block_compare): New function used by
>   cmpmemsi pattern to do builtin expansion of memcmp().

Space before (, here and below.

>   (compute_current_alignment): Add helper function for
>   expand_block_compare used to compute alignment as the compare proceeds.
>   (select_block_compare_mode): Used by expand_block_compare to select
>   the mode used for reading the next chunk of bytes in the compare.
>   (do_load_for_compare): Used by expand_block_compare to emit the load
>   insns for the compare.
>   (rs6000_emit_dot_insn): Moved this function to avoid a forward
>   reference from expand_block_compare().
>   * config/rs6000/rs6000-protos.h (expand_block_compare): Add a
>   prototype for this function.
>   * config/rs6000/rs6000.opt (mblock-compare-inline-limit): Add a new
>   target option for controlling how much code inline expansion of
>   memcmp() will be allowed to generate.

You can just say "New function." and the like for most things here, fwiw.

> +/* Figure out the correct instructions to generate to load data for
> +   block compare.  MODE is used for the read from memory, and
> +   data is zero extended if REG is wider than MODE.  If LE code
> +   is being generated, bswap loads are used.

"Emit a load for a block compare", maybe?  I.e. say it emits code, and
it does only one load.

> +  /* final fallback is do one byte */

Capital, dot space space.

> +  /* If this is not a fixed size compare, just call memcmp */

Dot space space.

> +  /* This must be a fixed size alignment */

Dot space space.

> +  /* SLOW_UNALIGNED_ACCESS -- don't do unaligned stuff */

Full sentence.

> +  /* Anything to move? */

Question mark space space.

> +  int offset = 0;
> +  machine_mode load_mode =
> +select_block_compare_mode (offset, bytes, base_align, word_mode_ok);
> +  int load_mode_size = GET_MODE_SIZE (load_mode);

HOST_WIDE_INT instead of the ints?  It isn't slower and I find it hard to
convince myself int always works.

> +   int extra_bytes = load_mode_size - bytes;

Here too.

> +  int remain = bytes - cmp_bytes;

One more.

Very nice improvement, thank you!  This is okay for trunk.


Segher

Re: [PATCHv3][ARM] -mpure-code option for ARM

[Uros Bizjak]

diff --git a/gcc/hooks.c b/gcc/hooks.c
index 
99ec4014adb6fcbb073bf538dd00fe8695ee6cb2..1e925645c3173f8d97e104b9b2f480fca2ede438
100644
--- a/gcc/hooks.c
+++ b/gcc/hooks.c
@@ -481,3 +481,13 @@ void
  hook_void_gcc_optionsp (struct gcc_options *opts ATTRIBUTE_UNUSED)
  {
  }
+
+/* Generic hook that takes an unsigned int, an unsigned int pointer and
+   returns false.  */
+
+bool
+hook_uint_uintp_false (unsigned int, unsigned int *)
+{
+  return false;
+}


The name of this hook doesn't adhere to the convention. It should be named:

hook_bool_uint_uintp_false

Uros.

Go patch committed: compile runtime.getcaller{pc,sp} into builtin functions

[Ian Lance Taylor]

This patch to the Go frontend compilers the runtime functions
getcallerpc and getcallersp into calls to __builtin_return_address and
__builtin_frame_address.  This is how we currently handle those
functions in the C code, using #define's in runtime.h.  This handles
the functions the same way in the Go code.  This is done by specially
recognizing the functions in the compiler, so that they will work
efficiently without doing a real stack unwind.

This fixes a breakage in libgo when libgo is compiled without
optimization, as currently all calls to these functions are compiled
out when optimizing but not when not optimizing.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian

2016-09-22  Ian Lance Taylor  

* go-gcc.cc (Gcc_backend::Gcc_backend): Declare
__builtin_frame_address.
Index: gcc/go/go-gcc.cc
===
--- gcc/go/go-gcc.cc(revision 240083)
+++ gcc/go/go-gcc.cc(working copy)
@@ -818,13 +818,14 @@ Gcc_backend::Gcc_backend()
   math_function_type_long, true, false);
 
   // We use __builtin_return_address in the thunk we build for
-  // functions which call recover.
+  // functions which call recover, and for runtime.getcallerpc.
+  t = build_function_type_list(ptr_type_node, unsigned_type_node, NULL_TREE);
   this->define_builtin(BUILT_IN_RETURN_ADDRESS, "__builtin_return_address",
-  NULL,
-  build_function_type_list(ptr_type_node,
-   unsigned_type_node,
-   NULL_TREE),
-  false, false);
+  NULL, t, false, false);
+
+  // The runtime calls __builtin_frame_address for runtime.getcallersp.
+  this->define_builtin(BUILT_IN_FRAME_ADDRESS, "__builtin_frame_address",
+  NULL, t, false, false);
 
   // The compiler uses __builtin_trap for some exception handling
   // cases.
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 240378)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-34c4837efc21c35eb21f40efc9bb6b1d71dbda47
+4f84c5e0210e674163f3f6462da6f5be9e5b0a36
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc(revision 240378)
+++ gcc/go/gofrontend/expressions.cc(working copy)
@@ -8897,6 +8897,45 @@ Call_expression::do_lower(Gogo* gogo, Na
  bme->location());
 }
 
+  // Handle a couple of special runtime functions.  In the runtime
+  // package, getcallerpc returns the PC of the caller, and
+  // getcallersp returns the frame pointer of the caller.  Implement
+  // these by turning them into calls to GCC builtin functions.  We
+  // could implement them in normal code, but then we would have to
+  // explicitly unwind the stack.  These functions are intended to be
+  // efficient.  Note that this technique obviously only works for
+  // direct calls, but that is the only way they are used.  The actual
+  // argument to these functions is always the address of a parameter;
+  // we don't need that for the GCC builtin functions, so we just
+  // ignore it.
+  if (gogo->compiling_runtime()
+  && this->args_ != NULL
+  && this->args_->size() == 1
+  && gogo->package_name() == "runtime")
+{
+  Func_expression* fe = this->fn_->func_expression();
+  if (fe != NULL
+ && fe->named_object()->is_function_declaration()
+ && fe->named_object()->package() == NULL)
+   {
+ std::string n = Gogo::unpack_hidden_name(fe->named_object()->name());
+ if (n == "getcallerpc")
+   {
+ static Named_object* builtin_return_address;
+ return this->lower_to_builtin(_return_address,
+   "__builtin_return_address",
+   0);
+   }
+ else if (n == "getcallersp")
+   {
+ static Named_object* builtin_frame_address;
+ return this->lower_to_builtin(_frame_address,
+   "__builtin_frame_address",
+   1);
+   }
+   }
+}
+
   return this;
 }
 
@@ -8997,6 +9036,28 @@ Call_expression::lower_varargs(Gogo* gog
   this->varargs_are_lowered_ = true;
 }
 
+// Return a call to __builtin_return_address or __builtin_frame_address.
+
+Expression*
+Call_expression::lower_to_builtin(Named_object** pno, const char* name,
+ int arg)
+{
+  if (*pno == NULL)
+*pno = Gogo::declare_builtin_rf_address(name);
+
+  Location loc = 

Re: [PATCH] Fix PR tree-optimization/77550

[Bernd Edlinger]

On 09/22/16 21:30, Christophe Lyon wrote:
> On 21 September 2016 at 22:20, Bernd Edlinger  
> wrote:
>> On 09/21/16 21:57, Christophe Lyon wrote:
>>> Hi,
>>>
>>> The new testcase pr77550.C fails on arm:
>>> /testsuite/g++.dg/pr77550.C:39:43: error: 'operator new' takes type
>>> 'size_t' ('unsigned int') as first parameter [-fpermissive]
>>> compiler exited with status 1
>>>
>>> Christophe
>>>
>>
>> Yes, I see, thanks.  This should fix it.
>>
>> OK for trunk, gcc-6 after a while ?
>>
>>
>> Bernd.
>
> Hi,
>
> The test now compiles and runs OK on most arm configurations, but
> on arm-none-eabi --with-cpu=cortex-a9, execution fails:
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> FAIL: g++.dg/pr77550.C   execution test
>
> And on arm-none-eabi with default cpu, the test still does not compile.
>
> Christophe
>

Hmm.  This test case is hardly worth it, because on my armv7hf target
it doesn't even reproduce the original problem :(

Could you send me the exact compile-flags and the error message
please?


Bernd.

Re: [v3 PATCH] PR libstdc++/77288 and the newest proposed resolution for LWG 2756

[Christophe Lyon]

On 22 September 2016 at 13:15, Jonathan Wakely  wrote:
> On 22/09/16 11:16 +0100, Jonathan Wakely wrote:
>>
>> (Somebody should fix PR58938 so exception_ptr is portable).
>
>
> Christophe, would you be able to test this patch?
>
> It uses a single global mutex for exception_ptr objects, which doesn't
> scale well but that probably isn't a problem for processors without
> lock-free atomics for single words.
>
> This also solves the problem of mismatched -march options, where the
> header is compiled for a CPU that supports the atomics but
> libstdc++.so was built for an older CPU that doesn't support them, and
> linking fails (as in https://gcc.gnu.org/PR58938#c13).
>
>
Hi Jonathan,

This is not quite right.
In most cases, it moves
18_support/exception_ptr/requirements_neg.cc  (test for errors, line 30)
to line 27 (not sure why, since you removed 1 line only)

but on older arm architectures, the tests you updated fail to compile:
  18_support/exception_ptr/40296.cc (test for excess errors)
  18_support/exception_ptr/60612-terminate.cc (test for excess errors)
  18_support/exception_ptr/60612-unexpected.cc (test for excess errors)
  18_support/exception_ptr/62258.cc (test for excess errors)
  18_support/exception_ptr/64241.cc (test for excess errors)
  18_support/exception_ptr/current_exception.cc (test for excess errors)
  18_support/exception_ptr/lifespan.cc (test for excess errors)
  18_support/exception_ptr/make_exception_ptr.cc (test for excess errors)
  18_support/exception_ptr/move.cc (test for excess errors)
  18_support/exception_ptr/requirements.cc (test for excess errors)
  18_support/exception_ptr/requirements_neg.cc  (test for errors, line 27)
  18_support/exception_ptr/requirements_neg.cc  (test for errors, line 28)
  18_support/exception_ptr/requirements_neg.cc  (test for errors, line 29)
  18_support/exception_ptr/requirements_neg.cc (test for excess errors)
  18_support/exception_ptr/rethrow_exception.cc (test for excess errors)

For instance:
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/18_support/exception_ptr/40296.cc:
In function 'bool test01()':
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/18_support/exception_ptr/40296.cc:25:
error: 'exception_ptr' is not a member of 'std'
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/18_support/exception_ptr/40296.cc:25:
note: suggested alternative: 'fexcept_t'
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/18_support/exception_ptr/40296.cc:27:
error: 'p' was not declared in this scope

/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/18_support/exception_ptr/60612-terminate.cc:
In function 'void f()':
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/18_support/exception_ptr/60612-terminate.cc:34:
error: 'rethrow_exception' is not a member of 'std'
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/18_support/exception_ptr/60612-terminate.cc:34:
note: suggested alternative: '__exception'
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/18_support/exception_ptr/60612-terminate.cc:34:
error: 'current_exception' is not a member of 'std'
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/18_support/exception_ptr/60612-terminate.cc:34:
note: suggested alternative: '_ZTISt9exception'

For more details:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/240339-pr58938-v2/report-build-info.html

Thanks,

Christophe

Re: [PATCHv3][ARM] -mpure-code option for ARM

[Martin Sebor]

FYI (to help avoid raising duplicate bugs), I opened bug 77695
for the bootstrap failure.

Martin

On 09/22/2016 01:33 PM, Bill Seurer wrote:

This patch breaks compilation on power:

g++ -fno-PIE -c   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common
-DHAVE_CONFIG_H -I. -I. -I/home/seurer/gcc/gcc-test2/gcc
-I/home/seurer/gcc/gcc-test2/gcc/.
-I/home/seurer/gcc/gcc-test2/gcc/../include
-I/home/seurer/gcc/gcc-test2/gcc/../libcpp/include
-I/home/seurer/gcc/gcc-test2/gcc/../libdecnumber
-I/home/seurer/gcc/gcc-test2/gcc/../libdecnumber/dpd -I../libdecnumber
-I/home/seurer/gcc/gcc-test2/gcc/../libbacktrace   -o rs6000.o -MT
rs6000.o -MMD -MP -MF ./.deps/rs6000.TPo
/home/seurer/gcc/gcc-test2/gcc/config/rs6000/rs6000.c
In file included from /home/seurer/gcc/gcc-test2/gcc/target-def.h:106:0,
 from
/home/seurer/gcc/gcc-test2/gcc/config/rs6000/rs6000.c:77:
./target-hooks-def.h:92:38: error: 'hook_uint_uintp_false' was not
declared in this scope
 #define TARGET_ASM_ELF_FLAGS_NUMERIC hook_uint_uintp_false
  ^
./target-hooks-def.h:2205:5: note: in expansion of macro
'TARGET_ASM_ELF_FLAGS_NUMERIC'
 TARGET_ASM_ELF_FLAGS_NUMERIC, \
 ^~~~
./target-hooks-def.h:1792:5: note: in expansion of macro 'TARGET_ASM_OUT'
 TARGET_ASM_OUT, \
 ^~
/home/seurer/gcc/gcc-test2/gcc/config/rs6000/rs6000.c:40709:29: note: in
expansion of macro 'TARGET_INITIALIZER'
 struct gcc_target targetm = TARGET_INITIALIZER;
 ^~
make[2]: *** [rs6000.o] Error 1


On 09/22/16 12:04, Andre Vieira (lists) wrote:

On 22/09/16 16:28, Richard Earnshaw (lists) wrote:

On 22/09/16 16:04, Andre Vieira (lists) wrote:


I reworked the patch according to the comments above.

Is this OK?

gcc/ChangeLog:
2016-09-22  Andre Vieira  
Terry Guo  

* target.def (elf_flags_numeric): New target hook.
* targhooks.h (default_asm_elf_flags_numeric): New.
* varasm.c (default_asm_elf_flags_numeric): New.
  (default_elf_asm_named_section): Use new target hook.
* config/arm/arm.opt (mpure-code): New.
* config/arm/arm.h (SECTION_ARM_PURECODE): New.
* config/arm/arm.c (arm_asm_init_sections): Add section
  attribute to default text section if -mpure-code.
  (arm_option_check_internal): Diagnose use of option with
  non supported targets and/or options.
  (arm_asm_elf_flags_numeric): New.
  (arm_function_section): New.
  (arm_elf_section_type_flags): New.
* config/arm/elf.h (JUMP_TABLES_IN_TEXT_SECTION): Disable
  for -mpure-code.
* gcc/doc/texi (TARGET_ASM_ELF_FLAGS_NUMERIC): New.
* gcc/doc/texi.in (TARGET_ASM_ELF_FLAGS_NUMERIC): Likewise.



gcc/testsuite/ChangeLog:
2016-09-22  Andre Vieira  
Terry Guo  

* gcc.target/arm/pure-code/ffunction-sections.c: New.
* gcc.target/arm/pure-code/no-literal-pool.c: New.
* gcc.target/arm/pure-code/pure-code.exp: New.




I missed this last time around, but please can you wrap references to
SHF_ARM_PURECODE in the documentation with @code{...}.

OK with that change.

R.


Done. Committed as revision r240379.

Re: [PATCH PR other/77609] Let the assembler choose ELF section types for miscellaneous named sections

[Roland McGrath]

ping?

On Thu, Sep 15, 2016 at 4:09 PM, Roland McGrath  wrote:
> This fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77609 (which I've
> just filed).
>
> OK for trunk?
>
> I'm not sure if this kind of fix is appropriate for gcc-6-branch or not,
> but I'd like to backport it there too if it is acceptable.
>
>
> Thanks,
> Roland
>
>
> gcc/
> 2016-09-15  Roland McGrath  <
>
> PR other/77609
> * varasm.c (default_section_type_flags): Set SECTION_NOTYPE for
> any section for which we don't know a specific type it should have,
> regardless of name.  Previously this was done only for the exact
> names ".init_array", ".fini_array", and ".preinit_array".
>
> diff --git a/gcc/varasm.c b/gcc/varasm.c
> index 00a9b30..0d7ea38 100644
> --- a/gcc/varasm.c
> +++ b/gcc/varasm.c
> @@ -6210,15 +6210,20 @@ default_section_type_flags (tree decl, const
> char *name, int reloc)
>|| strncmp (name, ".gnu.linkonce.tb.", 17) == 0)
>  flags |= SECTION_TLS | SECTION_BSS;
>
> -  /* These three sections have special ELF types.  They are neither
> - SHT_PROGBITS nor SHT_NOBITS, so when changing sections we don't
> - want to print a section type (@progbits or @nobits).  If someone
> - is silly enough to emit code or TLS variables to one of these
> - sections, then don't handle them specially.  */
> -  if (!(flags & (SECTION_CODE | SECTION_BSS | SECTION_TLS))
> -  && (strcmp (name, ".init_array") == 0
> - || strcmp (name, ".fini_array") == 0
> - || strcmp (name, ".preinit_array") == 0))
> +  /* Various sections have special ELF types that the assembler will
> + assign by default based on the name.  They are neither SHT_PROGBITS
> + nor SHT_NOBITS, so when changing sections we don't want to print a
> + section type (@progbits or @nobits).  Rather than duplicating the
> + assembler's knowledge of what those special name patterns are, just
> + let the assembler choose the type if we don't know a specific
> + reason to set it to something other than the default.  SHT_PROGBITS
> + is the default for sections whose name is not specially known to
> + the assembler, so it does no harm to leave the choice to the
> + assembler when @progbits is the best thing we know to use.  If
> + someone is silly enough to emit code or TLS variables to one of
> + these sections, then don't handle them specially.  */
> +  if (!(flags & (SECTION_CODE | SECTION_BSS | SECTION_TLS | SECTION_ENTSIZE))
> +  && !(HAVE_COMDAT_GROUP && (flags & SECTION_LINKONCE)))
>  flags |= SECTION_NOTYPE;
>
>return flags;

Re: [PATCHv3][ARM] -mpure-code option for ARM

[Paolo Carlini]

Hi,

On 22/09/2016 19:04, Andre Vieira (lists) wrote:

diff --git a/gcc/hooks.c b/gcc/hooks.c
index 
99ec4014adb6fcbb073bf538dd00fe8695ee6cb2..1e925645c3173f8d97e104b9b2f480fca2ede438
 100644
--- a/gcc/hooks.c
+++ b/gcc/hooks.c
@@ -481,3 +481,13 @@ void
  hook_void_gcc_optionsp (struct gcc_options *opts ATTRIBUTE_UNUSED)
  {
  }
+
+/* Generic hook that takes an unsigned int, an unsigned int pointer and
+   returns false.  */
+
+bool
+hook_uint_uintp_false (unsigned int, unsigned int *)
+{
+  return false;
+}
+


I don't see this change in the committed ChangeLog and, as is, it 
doesn't have a counterpart in hooks.h. Something as trivial as the below 
fixes the bootstrap error for me on x86_64-linux.


Thanks,
Paolo.


Index: hooks.h
===
--- hooks.h (revision 240379)
+++ hooks.h (working copy)
@@ -76,6 +76,7 @@ extern void hook_void_tree (tree);
 extern void hook_void_tree_treeptr (tree, tree *);
 extern void hook_void_int_int (int, int);
 extern void hook_void_gcc_optionsp (struct gcc_options *);
+extern bool hook_uint_uintp_false (unsigned int, unsigned int *);
 
 extern int hook_int_uint_mode_1 (unsigned int, machine_mode);
 extern int hook_int_const_tree_0 (const_tree);

[PATCH] builtin expansion of memcmp for powerpc

[Aaron Sawdey]

The powerpc target had a movmemsi pattern which supports memcpy() but
did not have anything for memcmp(). This adds support for builtin
expansion of memcmp() into inline code for modest constant lengths.
Performance on power8 is in the range of 3-7x faster than calling
memcmp() for lengths under 40 bytes.

Bootstrap on powerpc64le, regtest in progress, OK for trunk if no new
regressions?

2016-09-22  Aaron Sawdey  

* config/rs6000/rs6000.md (cmpmemsi): New define_expand.
* config/rs6000/rs6000.c (expand_block_compare): New function used by
cmpmemsi pattern to do builtin expansion of memcmp().
(compute_current_alignment): Add helper function for
expand_block_compare used to compute alignment as the compare proceeds.
(select_block_compare_mode): Used by expand_block_compare to select
the mode used for reading the next chunk of bytes in the compare.
(do_load_for_compare): Used by expand_block_compare to emit the load
insns for the compare.
(rs6000_emit_dot_insn): Moved this function to avoid a forward
reference from expand_block_compare().
* config/rs6000/rs6000-protos.h (expand_block_compare): Add a
prototype for this function.
* config/rs6000/rs6000.opt (mblock-compare-inline-limit): Add a new
target option for controlling how much code inline expansion of
memcmp() will be allowed to generate.

-- 
Aaron Sawdey, Ph.D.  acsaw...@linux.vnet.ibm.com
050-2/C113  (507) 253-7520 home: 507/263-0782
IBM Linux Technology Center - PPC ToolchainIndex: gcc/config/rs6000/rs6000-protos.h
===
--- gcc/config/rs6000/rs6000-protos.h	(revision 240286)
+++ gcc/config/rs6000/rs6000-protos.h	(working copy)
@@ -77,6 +77,7 @@
 extern void rs6000_scale_v2df (rtx, rtx, int);
 extern int expand_block_clear (rtx[]);
 extern int expand_block_move (rtx[]);
+extern bool expand_block_compare (rtx[]);
 extern const char * rs6000_output_load_multiple (rtx[]);
 extern bool rs6000_is_valid_mask (rtx, int *, int *, machine_mode);
 extern bool rs6000_is_valid_and_mask (rtx, machine_mode);
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c	(revision 240286)
+++ gcc/config/rs6000/rs6000.c	(working copy)
@@ -18423,7 +18423,462 @@
   return 1;
 }
 
+/* Emit a potentially record-form instruction, setting DST from SRC.
+   If DOT is 0, that is all; otherwise, set CCREG to the result of the
+   signed comparison of DST with zero.  If DOT is 1, the generated RTL
+   doesn't care about the DST result; if DOT is 2, it does.  If CCREG
+   is CR0 do a single dot insn (as a PARALLEL); otherwise, do a SET and
+   a separate COMPARE.  */
+
+static void
+rs6000_emit_dot_insn (rtx dst, rtx src, int dot, rtx ccreg)
+{
+  if (dot == 0)
+{
+  emit_move_insn (dst, src);
+  return;
+}
+
+  if (cc_reg_not_cr0_operand (ccreg, CCmode))
+{
+  emit_move_insn (dst, src);
+  emit_move_insn (ccreg, gen_rtx_COMPARE (CCmode, dst, const0_rtx));
+  return;
+}
+
+  rtx ccset = gen_rtx_SET (ccreg, gen_rtx_COMPARE (CCmode, src, const0_rtx));
+  if (dot == 1)
+{
+  rtx clobber = gen_rtx_CLOBBER (VOIDmode, dst);
+  emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, ccset, clobber)));
+}
+  else
+{
+  rtx set = gen_rtx_SET (dst, src);
+  emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, ccset, set)));
+}
+}
+
 
+/* Figure out the correct instructions to generate to load data for
+   block compare.  MODE is used for the read from memory, and
+   data is zero extended if REG is wider than MODE.  If LE code
+   is being generated, bswap loads are used.
+
+   REG is the destination register to move the data into.
+   MEM is the memory block being read.
+   MODE is the mode of memory to use for the read.  */
+static void
+do_load_for_compare (rtx reg, rtx mem, machine_mode mode)
+{
+  switch (GET_MODE (reg))
+{
+case DImode:
+  switch (mode)
+	{
+	case QImode:
+	  emit_insn (gen_zero_extendqidi2 (reg, mem));
+	  break;
+	case HImode:
+	  {
+	rtx src = mem;
+	if (TARGET_LITTLE_ENDIAN)
+	  {
+		src = gen_reg_rtx (HImode);
+		emit_insn (gen_bswaphi2 (src, mem));
+	  }
+	emit_insn (gen_zero_extendhidi2 (reg, src));
+	break;
+	  }
+	case SImode:
+	  {
+	rtx src = mem;
+	if (TARGET_LITTLE_ENDIAN)
+	  {
+		src = gen_reg_rtx (SImode);
+		emit_insn (gen_bswapsi2 (src, mem));
+	  }
+	emit_insn (gen_zero_extendsidi2 (reg, src));
+	  }
+	  break;
+	case DImode:
+	  if (TARGET_LITTLE_ENDIAN)
+	emit_insn (gen_bswapdi2 (reg, mem));
+	  else
+	emit_insn (gen_movdi (reg, mem));
+	  break;
+	default:
+	  gcc_unreachable ();
+	}
+  break;
+
+case SImode:
+  switch (mode)
+	{
+	case QImode:
+	  emit_insn (gen_zero_extendqisi2 (reg, mem));
+	  break;
+	case 

[PATCH] Use CONSTRUCTOR_NELTS macro some more

[Jakub Jelinek]

Hi!

I've noticed lots of vec_safe_length (CONSTRUCTOR_ELTS (...)) uses
in the sources, which IMHO are less readable than the much more often
used CONSTRUCTOR_NELTS (...) macro that does the same thing.

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

2016-09-22  Jakub Jelinek  

* hsa-gen.c (hsa_op_immed::hsa_op_immed Use CONSTRUCTOR_NELTS (...)
instead of vec_safe_length (CONSTRUCTOR_ELTS (...)).
(gen_hsa_ctor_assignment): Likewise.
* print-tree.c (print_node): Likewise.
* tree-dump.c (dequeue_and_dump): Likewise.
* tree-sra.c (sra_modify_constructor_assign): Likewise.
* expr.c (store_constructor): Likewise.
* fold-const.c (operand_equal_p): Likewise.
* tree-pretty-print.c (dump_generic_node): Likewise.
* hsa-brig.c (hsa_op_immed::emit_to_buffer): Likewise.
* ipa-icf-gimple.c (func_checker::compare_operand): Likewise.
cp/
* typeck2.c (process_init_constructor_record): Use
CONSTRUCTOR_NELTS (...) instead of
vec_safe_length (CONSTRUCTOR_ELTS (...)).
* decl.c (reshape_init_r): Likewise.
(check_initializer): Likewise.
ada/
* gcc-interface/decl.c (gnat_to_gnu_entity): Use
CONSTRUCTOR_NELTS (...) instead of
vec_safe_length (CONSTRUCTOR_ELTS (...)).

--- gcc/hsa-gen.c.jj2016-09-16 22:19:42.0 +0200
+++ gcc/hsa-gen.c   2016-09-22 17:51:23.078131950 +0200
@@ -1100,8 +1100,7 @@ hsa_op_immed::hsa_op_immed (tree tree_va
 
   /* Verify that all elements of a constructor are constants.  */
   if (TREE_CODE (m_tree_value) == CONSTRUCTOR)
-for (unsigned i = 0;
-i < vec_safe_length (CONSTRUCTOR_ELTS (m_tree_value)); i++)
+for (unsigned i = 0; i < CONSTRUCTOR_NELTS (m_tree_value); i++)
   {
tree v = CONSTRUCTOR_ELT (m_tree_value, i)->value;
if (!CONSTANT_CLASS_P (v))
@@ -2845,7 +2844,7 @@ void
 gen_hsa_ctor_assignment (hsa_op_address *addr_lhs, tree rhs, hsa_bb *hbb,
 BrigAlignment8_t align)
 {
-  if (vec_safe_length (CONSTRUCTOR_ELTS (rhs)))
+  if (CONSTRUCTOR_NELTS (rhs))
 {
   HSA_SORRY_AT (EXPR_LOCATION (rhs),
"support for HSA does not implement load from constructor");
--- gcc/print-tree.c.jj 2016-09-21 08:54:18.0 +0200
+++ gcc/print-tree.c2016-09-22 17:52:19.644409569 +0200
@@ -841,7 +841,7 @@ print_node (FILE *file, const char *pref
  {
unsigned HOST_WIDE_INT cnt;
tree index, value;
-   len = vec_safe_length (CONSTRUCTOR_ELTS (node));
+   len = CONSTRUCTOR_NELTS (node);
fprintf (file, " lngt %d", len);
FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (node),
  cnt, index, value)
--- gcc/tree-dump.c.jj  2016-01-04 14:55:53.0 +0100
+++ gcc/tree-dump.c 2016-09-22 17:52:39.430156894 +0200
@@ -646,7 +646,7 @@ dequeue_and_dump (dump_info_p di)
   {
unsigned HOST_WIDE_INT cnt;
tree index, value;
-   dump_int (di, "lngt", vec_safe_length (CONSTRUCTOR_ELTS (t)));
+   dump_int (di, "lngt", CONSTRUCTOR_NELTS (t));
FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (t), cnt, index, value)
  {
dump_child ("idx", index);
--- gcc/tree-sra.c.jj   2016-09-16 22:19:42.0 +0200
+++ gcc/tree-sra.c  2016-09-22 17:53:37.367417004 +0200
@@ -3224,7 +3224,7 @@ sra_modify_constructor_assign (gimple *s
return SRA_AM_MODIFIED;
 }
 
-  if (vec_safe_length (CONSTRUCTOR_ELTS (gimple_assign_rhs1 (stmt))) > 0)
+  if (CONSTRUCTOR_NELTS (gimple_assign_rhs1 (stmt)) > 0)
 {
   /* I have never seen this code path trigger but if it can happen the
 following should handle it gracefully.  */
--- gcc/expr.c.jj   2016-09-16 22:19:40.0 +0200
+++ gcc/expr.c  2016-09-22 17:49:51.441302202 +0200
@@ -6187,8 +6187,7 @@ store_constructor (tree exp, rtx target,
   register whose mode size isn't equal to SIZE since
   clear_storage can't handle this case.  */
else if (size > 0
-&& (((int)vec_safe_length (CONSTRUCTOR_ELTS (exp))
- != fields_length (type))
+&& (((int) CONSTRUCTOR_NELTS (exp) != fields_length (type))
 || mostly_zeros_p (exp))
 && (!REG_P (target)
 || ((HOST_WIDE_INT) GET_MODE_SIZE (GET_MODE (target))
--- gcc/fold-const.c.jj 2016-09-16 22:19:38.0 +0200
+++ gcc/fold-const.c2016-09-22 17:50:34.154756728 +0200
@@ -2954,8 +2954,7 @@ operand_equal_p (const_tree arg0, const_
   case CONSTRUCTOR:
/* In GIMPLE empty constructors are allowed in initializers of
   aggregates.  */
-   return (!vec_safe_length (CONSTRUCTOR_ELTS (arg0))
-   && !vec_safe_length (CONSTRUCTOR_ELTS (arg1)));
+   return !CONSTRUCTOR_NELTS (arg0) && !CONSTRUCTOR_NELTS (arg1);
   default:
  

[PATCH] Extend dg-{error,warning,message,bogus} line specification to allow relative line numbers

[Jakub Jelinek]

Hi!

This is something I've been unhappy for a long time with, and finally got to
write something for it.
When some test expects more than one error or warning or message on the same
source line, people have to use absolute line number on the dg-* directives
that is not on the right line, as DejaGNU handles just . (current line, the
default if the directive doesn't have all the arguments), 0 (no expected
line) and  for absolute line number.

This patch extends it, so one can write relative line numbers, . +/- 
as a single argument, say .-1 for the previous line number, .+1 for the next 
line
number, etc.  While one still has to supply the comment and target/xfail
arguments, the advantage of doing this is that if you adjust the testcase,
say add a line somewhere early, etc., you don't have to renumber all the
line numbers, and from what I saw in some clang testcases, it can be also
useful if multiple errors are issued for consecutive lines with different
wordings depending on some target supports etc. macros, one can e.g. use
  stmt1;/* { dg-error "..." "" { target c } } */
  stmt2;/* { dg-error "..." "" { target c } } */
  stmt3;/* { dg-error "..." "" { target c } } */
/* { dg-error "..." "" { target c++ } .-3 } */
/* { dg-error "..." "" { target c++ } .-3 } */
/* { dg-error "..." "" { target c++ } .-3 } */
which would be more readable than intermix the two sets of diagnostics.

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

2016-09-22  Jakub Jelinek  

* lib/gcc-dg.exp (process-message): Support relative line number
notation - .+4 or .-1 etc.
* gcc.dg/dg-test-1.c: New test.

--- gcc/testsuite/lib/gcc-dg.exp.jj 2016-06-24 12:59:19.0 +0200
+++ gcc/testsuite/lib/gcc-dg.exp2016-09-22 17:29:21.912995332 +0200
@@ -986,6 +986,13 @@ if { [info procs saved-dg-error] == [lis
 proc process-message { msgproc msgprefix dgargs } {
 upvar dg-messages dg-messages
 
+# Handle relative line specification, .+1 or .-1 etc.
+if { [llength $dgargs] == 5
+&& [regsub "^\.\[+-\](\[0-9\])$" [lindex $dgargs 4] "\\1" num] } {
+   set num [expr [lindex $dgargs 0] [string index [lindex $dgargs 4] 1] 
$num]
+   set dgargs [lreplace $dgargs 4 4 $num]
+}
+
 # Process the dg- directive, including adding the regular expression
 # to the new message entry in dg-messages.
 set msgcnt [llength ${dg-messages}]
--- gcc/testsuite/gcc.dg/dg-test-1.c.jj 2016-09-22 17:19:39.984407351 +0200
+++ gcc/testsuite/gcc.dg/dg-test-1.c2016-09-22 17:22:14.0 +0200
@@ -0,0 +1,18 @@
+/* Test relative line number specification extensions over what DejaGNU 
supports.  */
+/* { dg-do compile } */
+/* { dg-options "-Wunused-parameter" } */
+
+void
+foo (void)
+{  /* { dg-error "'a' undeclared" "err1" { target *-*-* } 
.+1 } */
+  int z = a + b + c + d;/* { dg-error "'b' undeclared" "err2" { target *-*-* } 
. } */
+}  /* { dg-error "'c' undeclared" "err3" { target *-*-* } 
.-1 } */
+
+
+/* { dg-error "'d' undeclared" "err4" { target *-*-* } .-4 } */
+/* { dg-warning "unused parameter 'e'" "warn1" { target *-*-* } .+3 } */
+
+void   /* { dg-warning "unused parameter 'f'" "warn2" 
{ target *-*-* } .+1 } */
+bar (int e, int f, int g, int h)/* { dg-warning "unused parameter 'g'" "warn3" 
{ target *-*-* } . } */
+{  /* { dg-warning "unused parameter 'h'" "warn4" 
{ target *-*-* } .-1 } */
+}

Jakub

[PATCH] Avoid some C++ local statics with constructors

[Jakub Jelinek]

Hi!

The discovered 5 unnecessary C++ static locals with ctors prompted me to
look at other cases, which from looking at the optimized or non-optimized
code are just terrible.
We don't need to initialize static vectors with vNULL, because that implies
runtime initialization, static vars are zero initialized, which is what we
want for the vectors.
In ipa-cp, I understand the vr.min and vr.max is set just so that
uninitialized vars aren't copied around, but initializing static local
wide_int from tree and then copying over is significantly more expensive
than just using wi::zero.
The only questionable change is the sreal.h one, what it did is certainly
very inefficient and ugly, but what the patch does is a kind of hack to keep
it as efficient as possible even for -O0, at -O2 I'd say the compiler should
just inline sreal::normalize and fold it into nothing.
So, if preferred, we could go with just
   inline static sreal min ()
   {
 return sreal (-SREAL_MAX_SIG, SREAL_MAX_EXP);
   }
which will be at -O2 as efficient as what the patch does - storing 2
integers.

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

2016-09-22  Jakub Jelinek  

* ipa-cp.c (ipcp_store_vr_results): Avoid static local
var zero.
* sreal.h (sreal::min, sreal::max): Avoid static local vars,
construct values without normalization.
* tree-ssa-sccvn.c (vn_reference_lookup_3): Don't initialize
static local lhs_ops to vNULL.
cp/
* name-lookup.c (store_bindings, store_class_bindings): Don't
initialize static local bindings_need_stored to vNULL.

--- gcc/ipa-cp.c.jj 2016-09-21 08:54:15.0 +0200
+++ gcc/ipa-cp.c2016-09-22 13:49:57.638198975 +0200
@@ -5204,11 +5204,9 @@ ipcp_store_vr_results (void)
 }
else
 {
-  static wide_int zero = integer_zero_node;
   vr.known = false;
   vr.type = VR_VARYING;
-  vr.min = zero;
-  vr.max = zero;
+  vr.min = vr.max = wi::zero (INT_TYPE_SIZE);
 }
ts->m_vr->quick_push (vr);
  }
--- gcc/sreal.h.jj  2016-01-04 14:55:52.0 +0100
+++ gcc/sreal.h 2016-09-22 14:09:38.882930801 +0200
@@ -104,14 +104,20 @@ public:
   /* Global minimum sreal can hold.  */
   inline static sreal min ()
   {
-static sreal min = sreal (-SREAL_MAX_SIG, SREAL_MAX_EXP);
+sreal min;
+/* This never needs normalization.  */
+min.m_sig = -SREAL_MAX_SIG;
+min.m_exp = SREAL_MAX_EXP;
 return min;
   }
 
   /* Global minimum sreal can hold.  */
   inline static sreal max ()
   {
-static sreal max = sreal (SREAL_MAX_SIG, SREAL_MAX_EXP);
+sreal max;
+/* This never needs normalization.  */
+max.m_sig = SREAL_MAX_SIG;
+max.m_exp = SREAL_MAX_EXP;
 return max;
   }
 
--- gcc/tree-ssa-sccvn.c.jj 2016-09-20 15:43:09.0 +0200
+++ gcc/tree-ssa-sccvn.c2016-09-22 13:40:03.667886908 +0200
@@ -1786,8 +1786,7 @@ vn_reference_lookup_3 (ao_ref *ref, tree
   gimple *def_stmt = SSA_NAME_DEF_STMT (vuse);
   tree base = ao_ref_base (ref);
   HOST_WIDE_INT offset, maxsize;
-  static vec
-lhs_ops = vNULL;
+  static vec lhs_ops;
   ao_ref lhs_ref;
   bool lhs_ref_ok = false;
 
--- gcc/cp/name-lookup.c.jj 2016-09-14 23:54:25.0 +0200
+++ gcc/cp/name-lookup.c2016-09-22 13:51:22.459102089 +0200
@@ -6197,7 +6197,7 @@ store_binding (tree id, vec **old_bindings)
 {
-  static vec bindings_need_stored = vNULL;
+  static vec bindings_need_stored;
   tree t, id;
   size_t i;
 
@@ -6233,7 +6233,7 @@ static void
 store_class_bindings (vec *names,
  vec **old_bindings)
 {
-  static vec bindings_need_stored = vNULL;
+  static vec bindings_need_stored;
   size_t i;
   cp_class_binding *cb;
 

Jakub

Re: [PATCHv3][ARM] -mpure-code option for ARM

[Bill Seurer]

This patch breaks compilation on power:

g++ -fno-PIE -c   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -I. -I. -I/home/seurer/gcc/gcc-test2/gcc 
-I/home/seurer/gcc/gcc-test2/gcc/. 
-I/home/seurer/gcc/gcc-test2/gcc/../include 
-I/home/seurer/gcc/gcc-test2/gcc/../libcpp/include 
-I/home/seurer/gcc/gcc-test2/gcc/../libdecnumber 
-I/home/seurer/gcc/gcc-test2/gcc/../libdecnumber/dpd -I../libdecnumber 
-I/home/seurer/gcc/gcc-test2/gcc/../libbacktrace   -o rs6000.o -MT 
rs6000.o -MMD -MP -MF ./.deps/rs6000.TPo 
/home/seurer/gcc/gcc-test2/gcc/config/rs6000/rs6000.c

In file included from /home/seurer/gcc/gcc-test2/gcc/target-def.h:106:0,
 from 
/home/seurer/gcc/gcc-test2/gcc/config/rs6000/rs6000.c:77:
./target-hooks-def.h:92:38: error: 'hook_uint_uintp_false' was not 
declared in this scope

 #define TARGET_ASM_ELF_FLAGS_NUMERIC hook_uint_uintp_false
  ^
./target-hooks-def.h:2205:5: note: in expansion of macro 
'TARGET_ASM_ELF_FLAGS_NUMERIC'

 TARGET_ASM_ELF_FLAGS_NUMERIC, \
 ^~~~
./target-hooks-def.h:1792:5: note: in expansion of macro 'TARGET_ASM_OUT'
 TARGET_ASM_OUT, \
 ^~
/home/seurer/gcc/gcc-test2/gcc/config/rs6000/rs6000.c:40709:29: note: in 
expansion of macro 'TARGET_INITIALIZER'

 struct gcc_target targetm = TARGET_INITIALIZER;
 ^~
make[2]: *** [rs6000.o] Error 1


On 09/22/16 12:04, Andre Vieira (lists) wrote:

On 22/09/16 16:28, Richard Earnshaw (lists) wrote:

On 22/09/16 16:04, Andre Vieira (lists) wrote:


I reworked the patch according to the comments above.

Is this OK?

gcc/ChangeLog:
2016-09-22  Andre Vieira  
Terry Guo  

* target.def (elf_flags_numeric): New target hook.
* targhooks.h (default_asm_elf_flags_numeric): New.
* varasm.c (default_asm_elf_flags_numeric): New.
  (default_elf_asm_named_section): Use new target hook.
* config/arm/arm.opt (mpure-code): New.
* config/arm/arm.h (SECTION_ARM_PURECODE): New.
* config/arm/arm.c (arm_asm_init_sections): Add section
  attribute to default text section if -mpure-code.
  (arm_option_check_internal): Diagnose use of option with
  non supported targets and/or options.
  (arm_asm_elf_flags_numeric): New.
  (arm_function_section): New.
  (arm_elf_section_type_flags): New.
* config/arm/elf.h (JUMP_TABLES_IN_TEXT_SECTION): Disable
  for -mpure-code.
* gcc/doc/texi (TARGET_ASM_ELF_FLAGS_NUMERIC): New.
* gcc/doc/texi.in (TARGET_ASM_ELF_FLAGS_NUMERIC): Likewise.



gcc/testsuite/ChangeLog:
2016-09-22  Andre Vieira  
Terry Guo  

* gcc.target/arm/pure-code/ffunction-sections.c: New.
* gcc.target/arm/pure-code/no-literal-pool.c: New.
* gcc.target/arm/pure-code/pure-code.exp: New.




I missed this last time around, but please can you wrap references to
SHF_ARM_PURECODE in the documentation with @code{...}.

OK with that change.

R.


Done. Committed as revision r240379.




--

-Bill Seurer

Re: [PATCH] Fix PR tree-optimization/77550

[Christophe Lyon]

On 21 September 2016 at 22:20, Bernd Edlinger  wrote:
> On 09/21/16 21:57, Christophe Lyon wrote:
>> Hi,
>>
>> The new testcase pr77550.C fails on arm:
>> /testsuite/g++.dg/pr77550.C:39:43: error: 'operator new' takes type
>> 'size_t' ('unsigned int') as first parameter [-fpermissive]
>> compiler exited with status 1
>>
>> Christophe
>>
>
> Yes, I see, thanks.  This should fix it.
>
> OK for trunk, gcc-6 after a while ?
>
>
> Bernd.

Hi,

The test now compiles and runs OK on most arm configurations, but
on arm-none-eabi --with-cpu=cortex-a9, execution fails:
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
FAIL: g++.dg/pr77550.C   execution test

And on arm-none-eabi with default cpu, the test still does not compile.

Christophe

Re: [PATCHv3][ARM] -mpure-code option for ARM

[Christophe Lyon]

Hi Andre,


On 22 September 2016 at 19:04, Andre Vieira (lists)
 wrote:
> On 22/09/16 16:28, Richard Earnshaw (lists) wrote:
>> On 22/09/16 16:04, Andre Vieira (lists) wrote:
>>>
>>> I reworked the patch according to the comments above.
>>>
>>> Is this OK?
>>>
>>> gcc/ChangeLog:
>>> 2016-09-22  Andre Vieira  
>>> Terry Guo  
>>>
>>> * target.def (elf_flags_numeric): New target hook.
>>> * targhooks.h (default_asm_elf_flags_numeric): New.
>>> * varasm.c (default_asm_elf_flags_numeric): New.
>>>   (default_elf_asm_named_section): Use new target hook.
>>> * config/arm/arm.opt (mpure-code): New.
>>> * config/arm/arm.h (SECTION_ARM_PURECODE): New.
>>> * config/arm/arm.c (arm_asm_init_sections): Add section
>>>   attribute to default text section if -mpure-code.
>>>   (arm_option_check_internal): Diagnose use of option with
>>>   non supported targets and/or options.
>>>   (arm_asm_elf_flags_numeric): New.
>>>   (arm_function_section): New.
>>>   (arm_elf_section_type_flags): New.
>>> * config/arm/elf.h (JUMP_TABLES_IN_TEXT_SECTION): Disable
>>>   for -mpure-code.
>>> * gcc/doc/texi (TARGET_ASM_ELF_FLAGS_NUMERIC): New.
>>> * gcc/doc/texi.in (TARGET_ASM_ELF_FLAGS_NUMERIC): Likewise.
>>>
>>>
>>>
>>> gcc/testsuite/ChangeLog:
>>> 2016-09-22  Andre Vieira  
>>> Terry Guo  
>>>
>>> * gcc.target/arm/pure-code/ffunction-sections.c: New.
>>> * gcc.target/arm/pure-code/no-literal-pool.c: New.
>>> * gcc.target/arm/pure-code/pure-code.exp: New.
>>>
>>>
>>
>> I missed this last time around, but please can you wrap references to
>> SHF_ARM_PURECODE in the documentation with @code{...}.
>>
>> OK with that change.
>>
>> R.
>
> Done. Committed as revision r240379.
>
This patch broke the aarch64 builds:
/tmp/9380062_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/aarch64/aarch64.c:14391:
error: ‘hook_uint_uintp_false’ was not declared in this s
cope
/tmp/9380062_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/aarch64/aarch64.c:14391:
error: too many initializers for ‘gcc_target::asm_out’
make[2]: *** [aarch64.o] Error 1
make[2]: Leaving directory
`/tmp/9380062_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc1/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory
`/tmp/9380062_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc1'
make: *** [all] Error 2

[PATCH] Don't peel extra copy of loop in unroller for loops with exit at end

[Pat Haugen]

I noticed the loop unroller peels an extra copy of the loop before it enters 
the switch block code to round the iteration count to a multiple of the unroll 
factor. This peeled copy is only needed for the case where the exit test is at 
the beginning of the loop since in that case it inserts the test for zero peel 
iterations before that peeled copy.

This patch bumps the iteration count by 1 for loops with the exit at the end so 
that it represents the number of times the loop body is executed, and therefore 
removes the need to always execute that first peeled copy. With this change, 
when the number of executions of the loop is an even multiple of the unroll 
factor then the code will jump to the unrolled loop immediately instead of 
executing all the switch code and peeled copies of the loop and then falling 
into the unrolled loop. This change also reduces code size by removing a peeled 
copy of the loop. 

Bootstrap/regtest on powerpc64le with no new regressions. Ok for trunk?



2016-09-22  Pat Haugen  

* loop-unroll.c (unroll_loop_runtime_iterations): Condition initial
loop peel to loops with exit test at the beginning.


Index: gcc/loop-unroll.c
===
--- gcc/loop-unroll.c	(revision 240167)
+++ gcc/loop-unroll.c	(working copy)
@@ -857,7 +857,7 @@ unroll_loop_runtime_iterations (struct l
   rtx old_niter, niter, tmp;
   rtx_insn *init_code, *branch_code;
   unsigned i, j, p;
-  basic_block preheader, *body, swtch, ezc_swtch;
+  basic_block preheader, *body, swtch, ezc_swtch = NULL;
   int may_exit_copy;
   unsigned n_peel;
   edge e;
@@ -916,6 +916,16 @@ unroll_loop_runtime_iterations (struct l
   if (tmp != niter)
 emit_move_insn (niter, tmp);
 
+  /* For loops that exit at end, add one to niter to account for first pass
+ through loop body before reaching exit test. */
+  if (exit_at_end)
+{
+  niter = expand_simple_binop (desc->mode, PLUS,
+   niter, const1_rtx,
+   NULL_RTX, 0, OPTAB_LIB_WIDEN);
+  old_niter = niter;
+}
+
   /* Count modulo by ANDing it with max_unroll; we use the fact that
  the number of unrollings is a power of two, and thus this is correct
  even if there is overflow in the computation.  */
@@ -934,20 +944,21 @@ unroll_loop_runtime_iterations (struct l
 
   auto_sbitmap wont_exit (max_unroll + 2);
 
-  /* Peel the first copy of loop body (almost always we must leave exit test
- here; the only exception is when we have extra zero check and the number
- of iterations is reliable.  Also record the place of (possible) extra
- zero check.  */
-  bitmap_clear (wont_exit);
-  if (extra_zero_check
-  && !desc->noloop_assumptions)
-bitmap_set_bit (wont_exit, 1);
-  ezc_swtch = loop_preheader_edge (loop)->src;
-  ok = duplicate_loop_to_header_edge (loop, loop_preheader_edge (loop),
-  1, wont_exit, desc->out_edge,
-  _edges,
-  DLTHE_FLAG_UPDATE_FREQ);
-  gcc_assert (ok);
+  if (extra_zero_check)
+{
+  /* Peel the first copy of loop body.  Leave the exit test if the number
+	 of iterations is not reliable.  Also record the place of the extra zero
+	 check.  */
+  bitmap_clear (wont_exit);
+  if (!desc->noloop_assumptions)
+	bitmap_set_bit (wont_exit, 1);
+  ezc_swtch = loop_preheader_edge (loop)->src;
+  ok = duplicate_loop_to_header_edge (loop, loop_preheader_edge (loop),
+	  1, wont_exit, desc->out_edge,
+	  _edges,
+	  DLTHE_FLAG_UPDATE_FREQ);
+  gcc_assert (ok);
+}
 
   /* Record the place where switch will be built for preconditioning.  */
   swtch = split_edge (loop_preheader_edge (loop));

Re: [PATCH v2] [RTEMS] Always use atomic builtins for libstdc++

[Bernhard Reutner-Fischer]

On 22 September 2016 11:11:42 CEST, Andreas Schwab  wrote:
>On Sep 22 2016, Sebastian Huber 
>wrote:
>
>> diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
>> index 6d897be..d7db435 100644
>> --- a/libstdc++-v3/acinclude.m4
>> +++ b/libstdc++-v3/acinclude.m4
>> @@ -3490,9 +3490,10 @@ EOF
>>AC_LANG_RESTORE
>>  
>># Set atomicity_dir to builtins if all but the long long test
>above passes.
>> -  if test "$glibcxx_cv_atomic_bool" = yes \
>> +  if { test "$glibcxx_cv_atomic_bool" = yes \
>>   && test "$glibcxx_cv_atomic_short" = yes \
>> - && test "$glibcxx_cv_atomic_int" = yes; then
>> + && test "$glibcxx_cv_atomic_int" = yes } \
>
>You need a semicolon (or newline) before }.

Please remind me why you need curly braces at all?

thanks

Re: [v3 PATCH] PR libstdc++/77288 and the newest proposed resolution for LWG 2756

[Christophe Lyon]

On 22 September 2016 at 15:25, Jonathan Wakely  wrote:
> On 22/09/16 12:15 +0100, Jonathan Wakely wrote:
>>
>> On 22/09/16 11:16 +0100, Jonathan Wakely wrote:
>>>
>>> (Somebody should fix PR58938 so exception_ptr is portable).
>>
>>
>> Christophe, would you be able to test this patch?
>>
>> It uses a single global mutex for exception_ptr objects, which doesn't
>> scale well but that probably isn't a problem for processors without
>> lock-free atomics for single words.
>>
>> This also solves the problem of mismatched -march options, where the
>> header is compiled for a CPU that supports the atomics but
>> libstdc++.so was built for an older CPU that doesn't support them, and
>> linking fails (as in https://gcc.gnu.org/PR58938#c13).
>
>
> We'd also need something like this extra piece, to ensure we don't
> leak exceptions. Currently __gxx_exception_cleanup assumes that if
> ATOMIC_INT_LOCK_FREE < 2 the referenceCount can never be greater than
> 1, because there are not exception_ptr objects that could increase it.
>
> If we enable exception_ptr unconditionally then that assumption
> doesn't hold. This patch uses the exception_ptr code to do the
> cleanup, under the same mutex as any other increments and decrements
> of the reference count.
>
> It's a bit of a hack though.
>
Should I have applied this one on top of the other?

I ran a validation with it alone, and
arm-none-eabi with default mode, cpu, and fpu does not build:
In file included from
/tmp/9260164_29.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/eh_throw.cc:27:0:
/tmp/9260164_29.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/exception_ptr.h:43:4:
error: #error This platform does
not support exception propagation.
 #  error This platform does not support exception propagation.
^
make[4]: *** [eh_throw.lo] Error 1


In addition, on arm-none-eabi --with-mode=thumb --with-cpu=cortex-a9,
I've noticed a regression in c++
  - PASS now FAIL [PASS => FAIL]:

  g++.dg/opt/pr36449.C  -std=gnu++11 execution test
  g++.dg/opt/pr36449.C  -std=gnu++14 execution test
  g++.dg/opt/pr36449.C  -std=gnu++98 execution test

My logs show:
qemu: uncaught target signal 11 (Segmentation fault) - core dumped

The validation of the other patch is still running: I had to re-run it
because the
patch didn't apply because of the ChangeLog entry.

Re: [RFC] Update gmp/mpfr/mpc minimum versions

[Bernd Edlinger]

On 09/22/16 20:07, Moritz Klammler wrote:
> Martin Sebor  writes:
>
>> [...]
>>
>>> In-tree only the versions that download_prerequisite picks are
>>> tested and guaranteed to work.
>>
>> I was made aware today that my recent patch for pr49905 broke
>> bootstrap with MPFR 2.4:
>>
>>https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01507.html
>>
>> In light of this risk and given that the recommended MPFR version
>> is still 2.4 I wonder if the download_prerequisites script shouldn't
>> instead download the minimum supported version.  That way those of
>> us working with MPFR but not intimately familiar with its version
>> specific details would have an easier way of avoiding such breakage.
>>
>> Alternatively, perhaps the script could be extended to make it
>> possible to choose between the most recent and the recommended
>> versions of the prerequisites that GCC is intended to work with,
>> and people who make use of either in their code encouraged to
>> test with both.
>
> As some of you might already be aware of, I'm currently trying to get a
> new version of the `contrib/download_prerequisites` script approved that
> will verify the checksums of the tarballs it downloads and also provides
> additional options.  If it is considered useful, I could add an option
> to it that would do what you suggest.  Am I understanding correctly that
> we have a "minimum", "recommended" and "most recent" version for each
> dependency and that the script currently uses the "most recent" one?  If
> the feature is wanted, all I'd need is somebody to tell me the version
> numbers.
>

No, the problem is, that these packages are not designed for in-tree
builds but for stand-alone.  Likewise they are not designed for
cross-target builds.  So for each version there are different
work-arounds necessary from the toplevel configure scripts.

And until I updated that top-level script, only the very old versions
did *actually* work on all targets.


Bernd.

Re: [PATCHv3][ARM] -mpure-code option for ARM

[David Edelsohn]

This patch broke bootstrap.

In file included from
/nasfarm/edelsohn/src/src/gcc/target-def.h:106:0, from
/nasfarm/edelsohn/src/src/gcc/config/rs6000/rs6000.c:77:./target-hooks-def.h:92:38:
error: 'hook_uint_uintp_false' was not declared in this scope

 #define TARGET_ASM_ELF_FLAGS_NUMERIC hook_uint_uintp_false
  ^./target-hooks-def.h:2205:5: note: in
expansion of macro 'TARGET_ASM_ELF_FLAGS_NUMERIC'
TARGET_ASM_ELF_FLAGS_NUMERIC, \

 ^

./target-hooks-def.h:1792:5: note: in expansion of macro 'TARGET_ASM_OUT'

 TARGET_ASM_OUT, \

 ^

/nasfarm/edelsohn/src/src/gcc/config/rs6000/rs6000.c:40709:29: note:
in expansion of macro 'TARGET_INITIALIZER'

 struct gcc_target targetm = TARGET_INITIALIZER;

Re: [RFC] Update gmp/mpfr/mpc minimum versions

[Joseph Myers]

On Thu, 22 Sep 2016, Moritz Klammler wrote:

> As some of you might already be aware of, I'm currently trying to get a
> new version of the `contrib/download_prerequisites` script approved that
> will verify the checksums of the tarballs it downloads and also provides
> additional options.  If it is considered useful, I could add an option
> to it that would do what you suggest.  Am I understanding correctly that
> we have a "minimum", "recommended" and "most recent" version for each
> dependency and that the script currently uses the "most recent" one?  If
> the feature is wanted, all I'd need is somebody to tell me the version
> numbers.

The script should not handle multiple versions; only recommended versions, 
which should be the most recent known to work with it.

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

[PATCH, i386]: Improve x86 target selectors and cleanup a couple of gcc.dg tests

[Uros Bizjak]

2016-09-22  Uros Bizjak  

* gcc.dg/ifcvt-1.c: Compile also for 64-bit i?86-*-* target.
* gcc.dg/ifcvt-2.c: Ditto.
* gcc.dg/zero_bits_compound-1.c: Ditto.
* gcc.dg/zero_bits_compound-1.c: Ditto.
* gcc.dg/pr40550.c: Simplify target selectors.
Use dg-additional-options.
* gcc.dg/pr47893.c: Ditto.
* gcc.dg/pr68435.c: Compile also for i?86-*-* target.  Add -march=i686
additional options for 32-bit x86 targets.
* gcc.dg/pr70955.c: Move to ...
* gcc.target/i386/pr70955.c: ... here.  Simplify target selector.

Tested on x86_64-linux-gnu {,-m32} and committed to mainline SVN.

Uros.
Index: gcc.dg/ifcvt-1.c
===
--- gcc.dg/ifcvt-1.c(revision 240365)
+++ gcc.dg/ifcvt-1.c(working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile { target aarch64*-*-* x86_64-*-* } } */
+/* { dg-do compile { target { { { i?86-*-* x86_64-*-* } && { ! ia32 } } || 
aarch64*-*-* } } } */
 /* { dg-options "-fdump-rtl-ce1 -O2" } */
 
 int
Index: gcc.dg/ifcvt-2.c
===
--- gcc.dg/ifcvt-2.c(revision 240365)
+++ gcc.dg/ifcvt-2.c(working copy)
@@ -1,7 +1,6 @@
-/* { dg-do compile { target aarch64*-*-* x86_64-*-* } } */
+/* { dg-do compile { target { { { i?86-*-* x86_64-*-* } && { ! ia32 } } || 
aarch64*-*-* } } } */
 /* { dg-options "-fdump-rtl-ce1 -O2 --param 
max-rtl-if-conversion-unpredictable-cost=100" } */
 
-
 typedef unsigned char uint8_t;
 typedef unsigned int uint16_t;
 
Index: gcc.dg/pr40550.c
===
--- gcc.dg/pr40550.c(revision 240365)
+++ gcc.dg/pr40550.c(working copy)
@@ -1,6 +1,7 @@
 /* { dg-do run } */
-/* { dg-options "-msse" { target { { i?86-*-* x86_64-*-* } && ilp32 } } } */
-/* { dg-require-effective-target sse_runtime { target { { i?86-*-* x86_64-*-* 
} && ilp32 } } } */
+/* { dg-options "" } */
+/* { dg-additional-options "-msse" { target i?86-*-* x86_64-*-* } } */
+/* { dg-require-effective-target sse_runtime { target { i?86-*-* x86_64-*-* } 
} } */
 
 typedef float v2sf __attribute__ ((vector_size (2 * sizeof(float;
 
Index: gcc.dg/pr47893.c
===
--- gcc.dg/pr47893.c(revision 240365)
+++ gcc.dg/pr47893.c(working copy)
@@ -1,7 +1,7 @@
 /* PR middle-end/47893 */
 /* { dg-do run } */
 /* { dg-options "-O2" } */
-/* { dg-options "-O2 -mtune=atom -fno-omit-frame-pointer -fno-strict-aliasing" 
{ target { { i?86-*-* x86_64-*-* } && ilp32 } } } */
+/* { dg-additional-options "-mtune=atom -fno-omit-frame-pointer 
-fno-strict-aliasing" { target { { i?86-*-* x86_64-*-* } && ia32 } } } */
 /* { dg-skip-if "Too much RAM needed" { "avr-*-*" } { "*" } { "" } } */
 
 extern void abort (void);
Index: gcc.dg/pr68435.c
===
--- gcc.dg/pr68435.c(revision 240365)
+++ gcc.dg/pr68435.c(working copy)
@@ -1,5 +1,6 @@
-/* { dg-do compile { target aarch64*-*-* x86_64-*-* } } */
+/* { dg-do compile { target aarch64*-*-* i?86-*-* x86_64-*-* } } */
 /* { dg-options "-fdump-rtl-ce1 -O2 -w --param 
max-rtl-if-conversion-unpredictable-cost=100" } */
+/* { dg-additional-options "-march=i686" { target { { i?86-*-* x86_64-*-* } && 
ia32 } } } */
 
 typedef struct cpp_reader cpp_reader;
 enum cpp_ttype
Index: gcc.dg/pr70955.c
===
--- gcc.dg/pr70955.c(revision 240365)
+++ gcc.dg/pr70955.c(nonexistent)
@@ -1,36 +0,0 @@
-/* __builtin_ms_va_list is only supported for x86_64 -m64.  */
-/* { dg-do run { target { x86_64-*-* && { ! ilp32 } } } } */
-/* { dg-require-effective-target lto } */
-/* { dg-options "-flto" } */
-
-#include 
-
-int __attribute__((ms_abi))
-foo (int n, ...)
-{
-  __builtin_ms_va_list ap;
-  int sum = 0;
-
-  __builtin_ms_va_start (ap, n);
-
-  while (n--)
-{
-  sum += __builtin_va_arg (ap, int);
-  printf ("sum = %d\n", sum);
-}
-
-  __builtin_ms_va_end (ap);
-
-  return sum;
-}
-
-int
-main (void)
-{
-  int res = foo (10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
-
-  if (res != 55)
-__builtin_abort ();
-
-  return 0;
-}
Index: gcc.dg/zero_bits_compound-1.c
===
--- gcc.dg/zero_bits_compound-1.c   (revision 240365)
+++ gcc.dg/zero_bits_compound-1.c   (working copy)
@@ -4,7 +4,7 @@
 /* Note: This test requires that char, int and long have different sizes and 
the
target has a way to do 32 -> 64 bit zero extension other than AND.  */
 
-/* { dg-do compile { target x86_64-*-* s390*-*-* aarch64*-*-* } } */
+/* { dg-do compile { target i?86-*-* x86_64-*-* s390*-*-* aarch64*-*-* } } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-options "-O3 -dP" } */
 
Index: gcc.dg/zero_bits_compound-2.c
===
--- 

Re: [RFC] Update gmp/mpfr/mpc minimum versions

[Bernd Edlinger]

On 09/22/16 20:00, Joseph Myers wrote:
> On Thu, 22 Sep 2016, Bernd Edlinger wrote:
>
>> There is no feasible way how to make all gmp/mpfr/mpc versions from
>> minimal to latest build for all targets and all possible
>> cross-configurations.
>>
>> I hope that we do not "recommend" these versions.
>>
>> They are only the minimum versions for pre-installed packages.
>
> And personally I think it would by now be reasonable to require MPFR 3.0
> or 3.1 as a minimum version should someone wish to make the various
> cleanups mentioned in the April discussion, so avoiding claiming to
> support configurations few developers will be testing.  (MPFR 3.1 came out
> nearly five years ago - 3 Oct 2011.)
>

Yes, and we have workarounds for more than just convenience features
that are missing in MPFR 2.4.

I proposed to remove them in April but Richard was against it.


Bernd.

Re: [RFC] Update gmp/mpfr/mpc minimum versions

[Moritz Klammler]

Martin Sebor  writes:

> [...]
>
>> In-tree only the versions that download_prerequisite picks are
>> tested and guaranteed to work.
>
> I was made aware today that my recent patch for pr49905 broke
> bootstrap with MPFR 2.4:
>
>   https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01507.html
>
> In light of this risk and given that the recommended MPFR version
> is still 2.4 I wonder if the download_prerequisites script shouldn't
> instead download the minimum supported version.  That way those of
> us working with MPFR but not intimately familiar with its version
> specific details would have an easier way of avoiding such breakage.
>
> Alternatively, perhaps the script could be extended to make it
> possible to choose between the most recent and the recommended
> versions of the prerequisites that GCC is intended to work with,
> and people who make use of either in their code encouraged to
> test with both.

As some of you might already be aware of, I'm currently trying to get a
new version of the `contrib/download_prerequisites` script approved that
will verify the checksums of the tarballs it downloads and also provides
additional options.  If it is considered useful, I could add an option
to it that would do what you suggest.  Am I understanding correctly that
we have a "minimum", "recommended" and "most recent" version for each
dependency and that the script currently uses the "most recent" one?  If
the feature is wanted, all I'd need is somebody to tell me the version
numbers.

Re: [RFC] Update gmp/mpfr/mpc minimum versions

[Joseph Myers]

On Thu, 22 Sep 2016, Bernd Edlinger wrote:

> There is no feasible way how to make all gmp/mpfr/mpc versions from
> minimal to latest build for all targets and all possible
> cross-configurations.
> 
> I hope that we do not "recommend" these versions.
> 
> They are only the minimum versions for pre-installed packages.

And personally I think it would by now be reasonable to require MPFR 3.0 
or 3.1 as a minimum version should someone wish to make the various 
cleanups mentioned in the April discussion, so avoiding claiming to 
support configurations few developers will be testing.  (MPFR 3.1 came out 
nearly five years ago - 3 Oct 2011.)

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

Re: [RFC] Update gmp/mpfr/mpc minimum versions

[Richard Biener]

On September 22, 2016 8:00:40 PM GMT+02:00, Joseph Myers 
 wrote:
>On Thu, 22 Sep 2016, Bernd Edlinger wrote:
>
>> There is no feasible way how to make all gmp/mpfr/mpc versions from
>> minimal to latest build for all targets and all possible
>> cross-configurations.
>> 
>> I hope that we do not "recommend" these versions.
>> 
>> They are only the minimum versions for pre-installed packages.
>
>And personally I think it would by now be reasonable to require MPFR
>3.0 
>or 3.1 as a minimum version should someone wish to make the various 
>cleanups mentioned in the April discussion, so avoiding claiming to 
>support configurations few developers will be testing.  (MPFR 3.1 came
>out 
>nearly five years ago - 3 Oct 2011.)

Hmpf, it will be a hassle to update all our auto-testers again...  So, yes, we 
are 'testing' with those versions.

Richard.

Re: [Patch] Remove all uses of TARGET_FLT_EVAL_METHOD_NON_DEFAULT and poison it

[Joseph Myers]

On Thu, 22 Sep 2016, James Greenhalgh wrote:

> The relaxation isn't portable, and keeping it in place is tricky, so this
> patch removes it, and poisons TARGET_FLT_EVAL_METHOD_NON_DEFAULT in
> system.h to prevent future use.
> 
> Bootstrapped and tested on x86_64 with --enable-languages=all,ada,go,obj-c++
> with no issues.
> 
> OK?

OK.

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

Re: PR35503 - warn for restrict pointer

[Joseph Myers]

On Thu, 22 Sep 2016, Prathamesh Kulkarni wrote:

> Would that be acceptable ? I am not sure how to make %Z check if the
> argument has type vec *
> since vec is not really a builtin C type.
> Could you suggest me a better solution so that the format checker will check
> if arg has type vec * instead of checking if it's just a pointer ?
> Also for testing, should I create a testcase in g++.dg since
> gcc.dg/format/ tests are C-only ?

If it's C++-only then it would need to be in g++.dg.

The way we handle GCC-specific types in checking these formats is that the 
code using these formats has to define typedefs which the format-checking 
code then looks up.  In most cases it can just look up names like 
location_t or tree, but for HOST_WIDE_INT it looks up 
__gcc_host_wide_int__ which the user must have defined as a typedef.  
Probably that's the way to go in this case: the user must do "typedef 
vec __gcc_vec_int__;" or similar, and the code looks up 
__gcc_vec_int__.

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

Re: [RFC] Update gmp/mpfr/mpc minimum versions

[Bernd Edlinger]

On 09/22/16 19:26, Martin Sebor wrote:
> On 04/27/2016 09:47 AM, Bernd Edlinger wrote:
>>
>>
>> Yes, when they are pre-installed there should be no problem.
>> Also newer versions than these seem to work.
>>
>> In-tree only the versions that download_prerequisite picks are
>> tested and guaranteed to work.
>
> I was made aware today that my recent patch for pr49905 broke
> bootstrap with MPFR 2.4:
>
>https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01507.html
>
> In light of this risk and given that the recommended MPFR version
> is still 2.4 I wonder if the download_prerequisites script shouldn't
> instead download the minimum supported version.  That way those of
> us working with MPFR but not intimately familiar with its version
> specific details would have an easier way of avoiding such breakage.
>
> Alternatively, perhaps the script could be extended to make it
> possible to choose between the most recent and the recommended
> versions of the prerequisites that GCC is intended to work with,
> and people who make use of either in their code encouraged to
> test with both.
>
> Martin
>


There is no feasible way how to make all gmp/mpfr/mpc versions from
minimal to latest build for all targets and all possible
cross-configurations.

I hope that we do not "recommend" these versions.

They are only the minimum versions for pre-installed packages.



Bernd.

Re: [RFC] Update gmp/mpfr/mpc minimum versions

[Joseph Myers]

On Thu, 22 Sep 2016, Martin Sebor wrote:

> In light of this risk and given that the recommended MPFR version
> is still 2.4 I wonder if the download_prerequisites script shouldn't
> instead download the minimum supported version.  That way those of

No, it should download the latest version known to work with the script 
and we should routinely review and update those versions (preferably they 
should be the latest releases of the libraries, subject to avoiding major 
updates while in bug-fixing mode).  We should not encourage use of ancient 
versions, although we should only update the minimum when there's actually 
a new feature we want to use (that feature may just be a convenience 
rather than something hard to avoid, if the minimum version with it is old 
enough).

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

Re: [Fortran, accaf, patch, v1] Fixing compatibility with opencoarrays (mostly)

[Paul Richard Thomas]

Dear Andre,

Yes, this is fine for trunk. Thanks for fixing it so quickly.

Best regards

Paul

On 22 September 2016 at 17:09, Andre Vehreschild  wrote:
> Hi all,
>
> attached patch fixes compatibility with opencoarrays by using the old coarray
> interface of caf_get() as long as possible.
>
> Bootstrapped and regtested ok on x86_64-linux/F23. Ok for trunk?
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein

Re: [RFC] Update gmp/mpfr/mpc minimum versions

[Martin Sebor]

On 04/27/2016 09:47 AM, Bernd Edlinger wrote:



Am 27.04.2016 um 17:37 schrieb Rainer Orth:

Bernd Edlinger  writes:


On 26.04.2016 22:14, Joseph Myers wrote:

On Tue, 26 Apr 2016, Bernd Edlinger wrote:


Hi,

as we all know, it's high time now to adjust the minimum supported
gmp/mpfr/mpc versions for gcc-7.


I think updating the minimum versions (when using previously built
libraries, not in-tree) is only appropriate when it allows some cleanup in
GCC, such as removing conditionals on whether a more recently added
function is available, adding functionality that depends on a newer
interface, or using newer interfaces instead of older ones that are now
deprecated.

For example, you could justify a move to requiring MPFR 3.0.0 or later
with cleanups to use MPFR_RND* instead of the older GMP_RND*, and
similarly mpfr_rnd_t instead of the older mp_rnd_t and likewise mpfr_exp_t
and mpfr_prec_t in fortran/.  You could justify a move to requiring MPC
1.0.0 (or 1.0.2) by optimizing clog10 using mpc_log10.  I don't know what
if any newer GMP interfaces would be beneficial in GCC.  And as always in
such cases, it's a good idea to look at e.g. how widespread the newer
versions are in GNU/Linux distributions, which indicates how many people
might be affected by an increase in the version requirement.



Yes I see.

I would justify it this way: gmp-6.0.0 is the first version that does
not invoke undefined behavior in gmp.h, once we update to gmp-6.0.0
we could emit at least a warning in cstddef for this invalid code.

Once we have gmp-6.0.0, the earliest mpfr version that compiles at all
is mpfr-3.1.1 and the earliest mpc version that compiles at all is
mpc-0.9.  This would be the supported installed versions.

In-tree gmp-6.0.0 does _not_ work for ARM.  But gmp-6.1.0 does (with a
little quirk).  All supported mpfr and mpc versions are working in-tree
too, even for the ARM target.

When we have at least mpfr-3.1.1, it is straight forward to remove the
pre-3.1.0 compatibility code from gcc/fortran/simplify.c for instance.

So I would propose this updated patch for gcc-7.


would this version combo (gmp 6.0.0, mpfr 3.1.1, mpc 0.9) also work on
the active release branches (gcc-5 and gcc-6, gcc-4.9 is on it's way
out)?  Having to install two different sets of the libraries for trunk
and branch work would be extremely tedious.

Rainer



Yes, when they are pre-installed there should be no problem.
Also newer versions than these seem to work.

In-tree only the versions that download_prerequisite picks are
tested and guaranteed to work.


I was made aware today that my recent patch for pr49905 broke
bootstrap with MPFR 2.4:

  https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01507.html

In light of this risk and given that the recommended MPFR version
is still 2.4 I wonder if the download_prerequisites script shouldn't
instead download the minimum supported version.  That way those of
us working with MPFR but not intimately familiar with its version
specific details would have an easier way of avoiding such breakage.

Alternatively, perhaps the script could be extended to make it
possible to choose between the most recent and the recommended
versions of the prerequisites that GCC is intended to work with,
and people who make use of either in their code encouraged to
test with both.

Martin

Re: [PATCH] fix ILP32 bootstrap failures due to -Wformat-length

[Jeff Law]

On 09/21/2016 06:28 PM, Martin Sebor wrote:


PR target/77676 - powerpc64 and powerpc64le stage2 bootstrap fail

gcc/testsuite/ChangeLog:
2016-09-21  Martin Sebor  

PR target/77676
* gcc.dg/tree-ssa/builtin-sprintf-2.c: Fix typo.
* gcc.dg/tree-ssa/builtin-sprintf-3.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-5.c: New test.

gcc/ChangeLog:
2016-09-21  Martin Sebor  

PR target/77676
* gimple-ssa-sprintf.c (target_int_min, target_int_max): Use
HOST_BITS_PER_WIDE_INT, make a static local variable auto.
(target_int_min): Correct computation.
(format_integer): Use long long as the argument for the ll length
modifier.
(format_floating): Use target_int_max().
(get_string_length): Same.
(format_string): Avoid setting the bounded flag for strings
of unknown length.
(try_substitute_return_value): Avoid setting range info when
the result isn't bounded.
* varasm.c (assemble_name): Increase buffer size.

@@ -1471,6 +1473,10 @@ format_string (const conversion_spec , tree arg)
: 2 == warn_format_length ? 0 <= prec ? prec : 1
: HOST_WIDE_INT_MAX);

+  /* The result is bounded unless overriddden for a non-constant string

s/overriddden/overridden/

OK with that change.

jeff

Re: C/C++ PATCH to implement -Wbool-operation (PR c/77490)

[Joseph Myers]

On Wed, 21 Sep 2016, Marek Polacek wrote:

> > > > And let's refer to "expression of type bool" rather than "boolean
> > > > expression".
> > > 
> > > Adjusted (and in the C FE too).
> > 
> > Hmm, I'm not sure that change is right for C.  But the C++ hunk is OK.
> 
> Thanks.  Joseph, how about the C part?

You shouldn't refer to "type bool" for C.  If it's the result of a boolean 
operation, the type is int; an expression has type _Bool only if cast to 
that type or if it's a variable of that type.

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

Re: [gofrontend-dev] Go patch committed: Avoid warning by using a local var for std::ofstream

[Joseph Myers]

On Wed, 21 Sep 2016, John David Anglin wrote:

> The alignment of 16 arises in code that used the ldcw instruction.
> Although this could be avoided in glibc there are numerous other
> packages with objects requiring 16-byte alignment.  So, I'm tending
> to think the typedef for max_align_t should be adjusted on hppa-linux
> so that it has 16-byte alignment.  Is that the correct approach?

The ISO C rule (given the fix to DR#445) is that max_align_t must be at 
least as aligned as, inter alia, "all types specified in clause 7 as 
complete object types".  The idea is that it must be at least as aligned 
as any type the user can define using only standard features other than 
_Alignas.

It would seem reasonable for it to be at least as aligned as POSIX types 
as well, in cases where POSIX types have greater alignment requirements 
than ISO C types; clearly malloc needs to return memory sufficiently 
aligned for POSIX types (because POSIX inherits from C99, where malloc has 
the "any type of object" wording).  It's vector types we want to avoid 
contributing to max_align_t alignment.

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

Re: [PATCHv3][ARM] -mpure-code option for ARM

[Andre Vieira (lists)]

On 22/09/16 16:28, Richard Earnshaw (lists) wrote:
> On 22/09/16 16:04, Andre Vieira (lists) wrote:
>>
>> I reworked the patch according to the comments above.
>>
>> Is this OK?
>>
>> gcc/ChangeLog:
>> 2016-09-22  Andre Vieira  
>> Terry Guo  
>>
>> * target.def (elf_flags_numeric): New target hook.
>> * targhooks.h (default_asm_elf_flags_numeric): New.
>> * varasm.c (default_asm_elf_flags_numeric): New.
>>   (default_elf_asm_named_section): Use new target hook.
>> * config/arm/arm.opt (mpure-code): New.
>> * config/arm/arm.h (SECTION_ARM_PURECODE): New.
>> * config/arm/arm.c (arm_asm_init_sections): Add section
>>   attribute to default text section if -mpure-code.
>>   (arm_option_check_internal): Diagnose use of option with
>>   non supported targets and/or options.
>>   (arm_asm_elf_flags_numeric): New.
>>   (arm_function_section): New.
>>   (arm_elf_section_type_flags): New.
>> * config/arm/elf.h (JUMP_TABLES_IN_TEXT_SECTION): Disable
>>   for -mpure-code.
>> * gcc/doc/texi (TARGET_ASM_ELF_FLAGS_NUMERIC): New.
>> * gcc/doc/texi.in (TARGET_ASM_ELF_FLAGS_NUMERIC): Likewise.
>>
>>
>>
>> gcc/testsuite/ChangeLog:
>> 2016-09-22  Andre Vieira  
>> Terry Guo  
>>
>> * gcc.target/arm/pure-code/ffunction-sections.c: New.
>> * gcc.target/arm/pure-code/no-literal-pool.c: New.
>> * gcc.target/arm/pure-code/pure-code.exp: New.
>>
>>
> 
> I missed this last time around, but please can you wrap references to
> SHF_ARM_PURECODE in the documentation with @code{...}.
> 
> OK with that change.
> 
> R.

Done. Committed as revision r240379.

diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index f0cdd669191689bc5dcf3a7c2b60da5a2d201e3f..d10605cee0e6e0e07bbb4e1910d30c91443f8d17 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -2263,4 +2263,8 @@ extern const char *host_detect_local_cpu (int argc, const char **argv);
 /* For switching between functions with different target attributes.  */
 #define SWITCHABLE_TARGET 1
 
+/* Define SECTION_ARM_PURECODE as the ARM specific section attribute
+   representation for SHF_ARM_PURECODE in GCC.  */
+#define SECTION_ARM_PURECODE SECTION_MACH_DEP
+
 #endif /* ! GCC_ARM_H */
>From f1d08002e245776ff131fcdf498cc3a9acc87ca3 Mon Sep 17 00:00:00 2001
From: Andre Simoes Dias Vieira 
Date: Tue, 14 Jun 2016 11:17:12 +0100
Subject: [PATCH] mpure-code for ARM

---
 gcc/config/arm/arm.c   | 145 -
 gcc/config/arm/arm.h   |   4 +
 gcc/config/arm/arm.md  |   2 +-
 gcc/config/arm/arm.opt |   4 +
 gcc/config/arm/elf.h   |   3 +-
 gcc/doc/invoke.texi|  11 +-
 gcc/doc/tm.texi|  12 ++
 gcc/doc/tm.texi.in |   2 +
 gcc/hooks.c|  10 ++
 gcc/target.def |  16 +++
 .../gcc.target/arm/pure-code/ffunction-sections.c  |  17 +++
 gcc/testsuite/gcc.target/arm/pure-code/no-casesi.c |  29 +
 .../gcc.target/arm/pure-code/no-literal-pool.c |  68 ++
 .../gcc.target/arm/pure-code/pure-code.exp |  54 
 gcc/varasm.c   |  50 ---
 15 files changed, 397 insertions(+), 30 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arm/pure-code/ffunction-sections.c
 create mode 100644 gcc/testsuite/gcc.target/arm/pure-code/no-casesi.c
 create mode 100644 gcc/testsuite/gcc.target/arm/pure-code/no-literal-pool.c
 create mode 100644 gcc/testsuite/gcc.target/arm/pure-code/pure-code.exp

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index f60955438d6f1cc5d996e7eacd4b453213044181..4d3f3d5b169dba636276093f1567b248e3035812 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -214,8 +214,8 @@ static bool arm_return_in_memory (const_tree, const_tree);
 static void arm_unwind_emit (FILE *, rtx_insn *);
 static bool arm_output_ttype (rtx);
 static void arm_asm_emit_except_personality (rtx);
-static void arm_asm_init_sections (void);
 #endif
+static void arm_asm_init_sections (void);
 static rtx arm_dwarf_register_span (rtx);
 
 static tree arm_cxx_guard_type (void);
@@ -299,7 +299,10 @@ static unsigned HOST_WIDE_INT arm_asan_shadow_offset (void);
 static void arm_sched_fusion_priority (rtx_insn *, int, int *, int*);
 static bool arm_can_output_mi_thunk (const_tree, HOST_WIDE_INT, HOST_WIDE_INT,
  const_tree);
-
+static section *arm_function_section (tree, enum node_frequency, bool, bool);
+static bool arm_asm_elf_flags_numeric (unsigned int flags, unsigned int *num);
+static unsigned int 

Go patch committed: add missing break statement

[Ian Lance Taylor]

This patch from Marek Polacek adds a missing break statement in the Go
frontend code.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 240334)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-69668416034247ac6c7228c9dcbf6719af05b6ca
+34c4837efc21c35eb21f40efc9bb6b1d71dbda47
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc(revision 240334)
+++ gcc/go/gofrontend/expressions.cc(working copy)
@@ -7066,6 +7066,7 @@ Builtin_call_expression::do_flatten(Gogo
  *pa = Expression::make_temporary_reference(temp, loc);
}
}
+  break;
 
 case BUILTIN_LEN:
   Expression_list::iterator pa = this->args()->begin();

[Patch] Remove all uses of TARGET_FLT_EVAL_METHOD_NON_DEFAULT and poison it

[James Greenhalgh]

Hi,

I'm going to hookize TARGET_FLT_EVAL_METHOD, so the current definition
of TARGET_FLT_EVAL_METHOD_NON_DEFAULT will stop working.

I looked in to ways of redefining this macro, but each that I explored would
require pulling in target.h in front-ends that don't otherwise need it.

Rather than do that, I thought about the purpose of this macro, which is
to permit a relaxation of the rule that -fexcess-precision=standard
requires front-end specific code to work if the target had no definition of
TARGET_FLT_EVAL_METHOD. That makes -fexcess-precision=standard with a
language other than C not-portable, and in particular it won't work with
any of the i386 backend targets.

The relaxation isn't portable, and keeping it in place is tricky, so this
patch removes it, and poisons TARGET_FLT_EVAL_METHOD_NON_DEFAULT in
system.h to prevent future use.

Bootstrapped and tested on x86_64 with --enable-languages=all,ada,go,obj-c++
with no issues.

OK?

Thanks,
James

---

gcc/

2016-09-22  James Greenhalgh  

* defaults.h (TARGET_FLT_EVAL_METHOD_NON_DEFAULT): Remove.
* system.h (TARGET_FLT_EVAL_METHOD_NON_DEFAULT): Poison.

gcc/c-family/

2016-09-22  James Greenhalgh  

* c-opts.c (c_common_post_options): Remove special case for
TARGET_FLT_EVAL_METHOD_NON_DEFAULT with -fexcess-precision=standard
in C++.

gcc/java/

2016-09-22  James Greenhalgh  

* lang.c (java_post_options): Remove special case for
TARGET_FLT_EVAL_METHOD_NON_DEFAULT with -fexcess-precision=standard.

gcc/fortran/

2016-09-22  James Greenhalgh  

* options.c (gfc_post_options): Remove special case for
TARGET_FLT_EVAL_METHOD_NON_DEFAULT with -fexcess-precision=standard.

gcc/ada/

2016-09-22  James Greenhalgh  

* gcc-interface/misc.c (gnat_post_options): Remove special case for
TARGET_FLT_EVAL_METHOD_NON_DEFAULT with -fexcess-precision=standard.

diff --git a/gcc/ada/gcc-interface/misc.c b/gcc/ada/gcc-interface/misc.c
index b240bc5..236a083 100644
--- a/gcc/ada/gcc-interface/misc.c
+++ b/gcc/ada/gcc-interface/misc.c
@@ -255,8 +255,7 @@ static bool
 gnat_post_options (const char **pfilename ATTRIBUTE_UNUSED)
 {
   /* Excess precision other than "fast" requires front-end support.  */
-  if (flag_excess_precision_cmdline == EXCESS_PRECISION_STANDARD
-  && TARGET_FLT_EVAL_METHOD_NON_DEFAULT)
+  if (flag_excess_precision_cmdline == EXCESS_PRECISION_STANDARD)
 sorry ("-fexcess-precision=standard for Ada");
   flag_excess_precision_cmdline = EXCESS_PRECISION_FAST;
 
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index e83944c..5fe3132 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -770,8 +770,7 @@ c_common_post_options (const char **pfilename)
  support.  */
   if (c_dialect_cxx ())
 {
-  if (flag_excess_precision_cmdline == EXCESS_PRECISION_STANDARD
-	  && TARGET_FLT_EVAL_METHOD_NON_DEFAULT)
+  if (flag_excess_precision_cmdline == EXCESS_PRECISION_STANDARD)
 	sorry ("-fexcess-precision=standard for C++");
   flag_excess_precision_cmdline = EXCESS_PRECISION_FAST;
 }
diff --git a/gcc/defaults.h b/gcc/defaults.h
index af8fe91..c62c844 100644
--- a/gcc/defaults.h
+++ b/gcc/defaults.h
@@ -963,11 +963,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #define REG_WORDS_BIG_ENDIAN WORDS_BIG_ENDIAN
 #endif
 
-#ifdef TARGET_FLT_EVAL_METHOD
-#define TARGET_FLT_EVAL_METHOD_NON_DEFAULT 1
-#else
+#ifndef TARGET_FLT_EVAL_METHOD
 #define TARGET_FLT_EVAL_METHOD 0
-#define TARGET_FLT_EVAL_METHOD_NON_DEFAULT 0
 #endif
 
 #ifndef TARGET_DEC_EVAL_METHOD
diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c
index 4aa8303..1b6984f 100644
--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -209,8 +209,7 @@ gfc_post_options (const char **pfilename)
 
   /* Excess precision other than "fast" requires front-end
  support.  */
-  if (flag_excess_precision_cmdline == EXCESS_PRECISION_STANDARD
-  && TARGET_FLT_EVAL_METHOD_NON_DEFAULT)
+  if (flag_excess_precision_cmdline == EXCESS_PRECISION_STANDARD)
 sorry ("-fexcess-precision=standard for Fortran");
   flag_excess_precision_cmdline = EXCESS_PRECISION_FAST;
 
diff --git a/gcc/java/lang.c b/gcc/java/lang.c
index 1c6dde4..65025ee 100644
--- a/gcc/java/lang.c
+++ b/gcc/java/lang.c
@@ -569,8 +569,7 @@ java_post_options (const char **pfilename)
 
   /* Excess precision other than "fast" requires front-end
  support.  */
-  if (flag_excess_precision_cmdline == EXCESS_PRECISION_STANDARD
-  && TARGET_FLT_EVAL_METHOD_NON_DEFAULT)
+  if (flag_excess_precision_cmdline == EXCESS_PRECISION_STANDARD)
 sorry ("-fexcess-precision=standard for Java");
   flag_excess_precision_cmdline = EXCESS_PRECISION_FAST;
 
diff --git a/gcc/system.h b/gcc/system.h
index 8a17197..e8f4dd9 100644
--- a/gcc/system.h
+++ b/gcc/system.h

[arm-embedded] [PATCH, ARM 7/7] Enable ARMv8-M atomic and synchronization support for ARMv8-M Baseline

[Thomas Preudhomme]

Hi,

We've decided to apply the following patch to ARM/embedded-6-branch.

Best regards,

Thomas
--- Begin Message ---

Hi,

This patch is part of a patch series to add support for atomic operations on 
ARMv8-M Baseline targets in GCC. This specific patch enables atomic and 
synchronization support added in previous patches of the series and adds tests. 
Enabling is done at the end of the patch series to ensure that no ICE is seen 
when in the middle of the patch series (eg. while doing a bisect). Enabling is 
done by enabling the exclusive and atomic loads and stores needed to implement 
all synchronization and atomic operations.


ChangeLog entries are as follow:

*** gcc/ChangeLog ***

2016-07-05  Thomas Preud'homme  

* config/arm/arm.h (TARGET_HAVE_LDREX): Define for ARMv8-M Baseline.
(TARGET_HAVE_LDREXBH): Likewise.
(TARGET_HAVE_LDACQ): Likewise.


*** gcc/testsuite/ChangeLog ***

2016-07-05  Thomas Preud'homme  

* gcc.target/arm/atomic-comp-swap-release-acquire-3.c: New test.
* gcc.target/arm/atomic-op-acq_rel-3.c: Likewise.
* gcc.target/arm/atomic-op-acquire-3.c: Likewise.
* gcc.target/arm/atomic-op-char-3.c: Likewise.
* gcc.target/arm/atomic-op-consume-3.c: Likewise.
* gcc.target/arm/atomic-op-int-3.c: Likewise.
* gcc.target/arm/atomic-op-relaxed-3.c: Likewise.
* gcc.target/arm/atomic-op-release-3.c: Likewise.
* gcc.target/arm/atomic-op-seq_cst-3.c: Likewise.
* gcc.target/arm/atomic-op-short-3.c: Likewise.


Testing: No code generation difference for ARMv7-A, ARMv7VE and ARMv8-A on all 
atomic and synchronization testcases in the testsuite [2]. Patchset was also 
bootstrapped with --enable-itm --enable-gomp on ARMv8-A in ARM and Thumb mode at 
optimization level -O1 and above [1] without any regression in the testsuite and 
no code generation difference in libitm and libgomp.


Code generation for ARMv8-M Baseline has been manually examined and compared 
against ARMv8-A Thumb-2 for the following configuration without finding any issue:


gcc.dg/atomic-op-2.c at -Os
gcc.dg/atomic-compare-exchange-2.c at -Os
gcc.dg/atomic-compare-exchange-3.c at -O3


Is this ok for trunk?

Best regards,

Thomas

[1] CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET were set to "-O1 -g", "-O3 -g" and 
undefined ("-O2 -g")

[2] The exact list is:

gcc/testsuite/gcc.dg/atomic-compare-exchange-1.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-2.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-3.c
gcc/testsuite/gcc.dg/atomic-exchange-1.c
gcc/testsuite/gcc.dg/atomic-exchange-2.c
gcc/testsuite/gcc.dg/atomic-exchange-3.c
gcc/testsuite/gcc.dg/atomic-fence.c
gcc/testsuite/gcc.dg/atomic-flag.c
gcc/testsuite/gcc.dg/atomic-generic.c
gcc/testsuite/gcc.dg/atomic-generic-aux.c
gcc/testsuite/gcc.dg/atomic-invalid-2.c
gcc/testsuite/gcc.dg/atomic-load-1.c
gcc/testsuite/gcc.dg/atomic-load-2.c
gcc/testsuite/gcc.dg/atomic-load-3.c
gcc/testsuite/gcc.dg/atomic-lockfree.c
gcc/testsuite/gcc.dg/atomic-lockfree-aux.c
gcc/testsuite/gcc.dg/atomic-noinline.c
gcc/testsuite/gcc.dg/atomic-noinline-aux.c
gcc/testsuite/gcc.dg/atomic-op-1.c
gcc/testsuite/gcc.dg/atomic-op-2.c
gcc/testsuite/gcc.dg/atomic-op-3.c
gcc/testsuite/gcc.dg/atomic-op-6.c
gcc/testsuite/gcc.dg/atomic-store-1.c
gcc/testsuite/gcc.dg/atomic-store-2.c
gcc/testsuite/gcc.dg/atomic-store-3.c
gcc/testsuite/g++.dg/ext/atomic-1.C
gcc/testsuite/g++.dg/ext/atomic-2.C
gcc/testsuite/gcc.target/arm/atomic-comp-swap-release-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-acq_rel.c
gcc/testsuite/gcc.target/arm/atomic-op-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-char.c
gcc/testsuite/gcc.target/arm/atomic-op-consume.c
gcc/testsuite/gcc.target/arm/atomic-op-int.c
gcc/testsuite/gcc.target/arm/atomic-op-relaxed.c
gcc/testsuite/gcc.target/arm/atomic-op-release.c
gcc/testsuite/gcc.target/arm/atomic-op-seq_cst.c
gcc/testsuite/gcc.target/arm/atomic-op-short.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_1.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_2.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_3.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_4.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_5.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_6.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_7.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_8.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_9.c
gcc/testsuite/gcc.target/arm/sync-1.c
gcc/testsuite/gcc.target/arm/synchronize.c
gcc/testsuite/gcc.target/arm/armv8-sync-comp-swap.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-acquire.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-full.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-release.c
libstdc++-v3/testsuite/29_atomics/atomic/60658.cc
libstdc++-v3/testsuite/29_atomics/atomic/62259.cc
libstdc++-v3/testsuite/29_atomics/atomic/64658.cc
libstdc++-v3/testsuite/29_atomics/atomic/65147.cc
libstdc++-v3/testsuite/29_atomics/atomic/65913.cc
libstdc++-v3/testsuite/29_atomics/atomic/70766.cc

[arm-embedded] [PATCH, ARM/testsuite 6/7] Force soft float in ARMv6-M and ARMv8-M Baseline options

[Thomas Preudhomme]

Hi,

We've decided to apply the following patch to ARM/embedded-6-branch.

Best regards,

Thomas
--- Begin Message ---
Sorry, noticed an error in the patch. It was not caught during testing because 
GCC was built with --with-mode=thumb. Correct patch attached.


Best regards,

Thomas

On 22/09/16 14:49, Thomas Preudhomme wrote:

Hi,

ARMv6-M and ARMv8-M Baseline only support soft float ABI. Therefore, the
arm_arch_v8m_base add option should pass -mfloat-abi=soft, much like -mthumb is
passed for architectures that only support Thumb instruction set. This patch
adds -mfloat-abi=soft to both arm_arch_v6m and arm_arch_v8m_base add options.
Patch is in attachment.

ChangeLog entry is as follows:

*** gcc/testsuite/ChangeLog ***

2016-07-15  Thomas Preud'homme  

* lib/target-supports.exp (add_options_for_arm_arch_v6m): Add
-mfloat-abi=soft option.
(add_options_for_arm_arch_v8m_base): Likewise.


Is this ok for trunk?

Best regards,

Thomas
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 0dabea0850124947a7fe333e0b94c4077434f278..b5d72f1283be6a6e4736a1d20936e169c1384398 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3540,24 +3540,25 @@ proc check_effective_target_arm_fp16_hw { } {
 # Usage: /* { dg-require-effective-target arm_arch_v5_ok } */
 #/* { dg-add-options arm_arch_v5 } */
 #	 /* { dg-require-effective-target arm_arch_v5_multilib } */
-foreach { armfunc armflag armdef } { v4 "-march=armv4 -marm" __ARM_ARCH_4__
- v4t "-march=armv4t" __ARM_ARCH_4T__
- v5 "-march=armv5 -marm" __ARM_ARCH_5__
- v5t "-march=armv5t" __ARM_ARCH_5T__
- v5te "-march=armv5te" __ARM_ARCH_5TE__
- v6 "-march=armv6" __ARM_ARCH_6__
- v6k "-march=armv6k" __ARM_ARCH_6K__
- v6t2 "-march=armv6t2" __ARM_ARCH_6T2__
- v6z "-march=armv6z" __ARM_ARCH_6Z__
- v6m "-march=armv6-m -mthumb" __ARM_ARCH_6M__
- v7a "-march=armv7-a" __ARM_ARCH_7A__
- v7r "-march=armv7-r" __ARM_ARCH_7R__
- v7m "-march=armv7-m -mthumb" __ARM_ARCH_7M__
- v7em "-march=armv7e-m -mthumb" __ARM_ARCH_7EM__
- v8a "-march=armv8-a" __ARM_ARCH_8A__
- v8_1a "-march=armv8.1a" __ARM_ARCH_8A__
- v8m_base "-march=armv8-m.base -mthumb" __ARM_ARCH_8M_BASE__
- v8m_main "-march=armv8-m.main -mthumb" __ARM_ARCH_8M_MAIN__ } {
+foreach { armfunc armflag armdef } {
+	v4 "-march=armv4 -marm" __ARM_ARCH_4__
+	v4t "-march=armv4t" __ARM_ARCH_4T__
+	v5 "-march=armv5 -marm" __ARM_ARCH_5__
+	v5t "-march=armv5t" __ARM_ARCH_5T__
+	v5te "-march=armv5te" __ARM_ARCH_5TE__
+	v6 "-march=armv6" __ARM_ARCH_6__
+	v6k "-march=armv6k" __ARM_ARCH_6K__
+	v6t2 "-march=armv6t2" __ARM_ARCH_6T2__
+	v6z "-march=armv6z" __ARM_ARCH_6Z__
+	v6m "-march=armv6-m -mthumb -mfloat-abi=soft" __ARM_ARCH_6M__
+	v7a "-march=armv7-a" __ARM_ARCH_7A__
+	v7r "-march=armv7-r" __ARM_ARCH_7R__
+	v7m "-march=armv7-m -mthumb" __ARM_ARCH_7M__
+	v7em "-march=armv7e-m -mthumb" __ARM_ARCH_7EM__
+	v8a "-march=armv8-a" __ARM_ARCH_8A__
+	v8_1a "-march=armv8.1a" __ARM_ARCH_8A__
+	v8m_base "-march=armv8-m.base -mthumb -mfloat-abi=soft" __ARM_ARCH_8M_BASE__
+	v8m_main "-march=armv8-m.main -mthumb" __ARM_ARCH_8M_MAIN__ } {
 eval [string map [list FUNC $armfunc FLAG $armflag DEF $armdef ] {
 	proc check_effective_target_arm_arch_FUNC_ok { } {
 	if { [ string match "*-marm*" "FLAG" ] &&
--- End Message ---

[arm-embedded] [PATCH, ARM 5/7] Adapt other atomic operations to ARMv8-M Baseline

[Thomas Preudhomme]

Hi,

We've decided to apply the following patch to ARM/embedded-6-branch.

Best regards,

Thomas
--- Begin Message ---

Hi,

This patch is part of a patch series to add support for atomic operations on 
ARMv8-M Baseline targets in GCC. This specific patch adds support for remaining 
atomic operations (exchange, addition, substraction, bitwise AND, OR, XOR and 
NAND to ARMv8-M Baseline, doubleword integers excepted. As with the previous 
patch in the patch series, this mostly consists adding Thumb-1 specific 
constraints to atomic_* patterns to match those in thumb1.md for the non atomic 
operation.


ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2016-09-02  Thomas Preud'homme  

* config/arm/arm.c (arm_split_atomic_op): Add function comment.  Add
logic to to decide whether to copy over old value to register for new
value.
* config/arm/sync.md: Add comments explaning why mode and code
attribute are not defined in iterators.md
(thumb1_atomic_op_str): New code attribute.
(thumb1_atomic_newop_str): Likewise.
(thumb1_atomic_fetch_op_str): Likewise.
(thumb1_atomic_fetch_newop_str): Likewise.
(thumb1_atomic_fetch_oldop_str): Likewise.
(atomic_exchange): Add new ARMv8-M Baseline only alternatives to
mirror the more restrictive constraints of the Thumb-1 insns after
split compared to Thumb-2 counterpart insns.
(atomic_): Likewise.  Add comment to keep constraints
in sync with non atomic version.
(atomic_nand): Likewise.
(atomic_fetch_): Likewise.
(atomic_fetch_nand): Likewise.
(atomic__fetch): Likewise.
(atomic_nand_fetch): Likewise.
* config/arm/thumb1.md (thumb1_addsi3): Add comment to keep contraint
in sync with atomic version.
(thumb1_subsi3_insn): Likewise.
(thumb1_andsi3_insn): Likewise.
(thumb1_iorsi3_insn): Likewise.
(thumb1_xorsi3_insn): Likewise.


Testing: No code generation difference for ARMv7-A, ARMv7VE and ARMv8-A on all 
atomic and synchronization testcases in the testsuite [2]. Patchset was also 
bootstrapped with --enable-itm --enable-gomp on ARMv8-A in ARM and Thumb mode at 
optimization level -O1 and above [1] without any regression in the testsuite and 
no code generation difference in libitm and libgomp.


Code generation for ARMv8-M Baseline has been manually examined and compared 
against ARMv8-A Thumb-2 for the following configuration without finding any issue:


gcc.dg/atomic-op-2.c at -Os
gcc.dg/atomic-compare-exchange-2.c at -Os
gcc.dg/atomic-compare-exchange-3.c at -O3


Is this ok for trunk?

Best regards,

Thomas

[1] CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET were set to "-O1 -g", "-O3 -g" and 
undefined ("-O2 -g")

[2] The exact list is:

gcc/testsuite/gcc.dg/atomic-compare-exchange-1.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-2.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-3.c
gcc/testsuite/gcc.dg/atomic-exchange-1.c
gcc/testsuite/gcc.dg/atomic-exchange-2.c
gcc/testsuite/gcc.dg/atomic-exchange-3.c
gcc/testsuite/gcc.dg/atomic-fence.c
gcc/testsuite/gcc.dg/atomic-flag.c
gcc/testsuite/gcc.dg/atomic-generic.c
gcc/testsuite/gcc.dg/atomic-generic-aux.c
gcc/testsuite/gcc.dg/atomic-invalid-2.c
gcc/testsuite/gcc.dg/atomic-load-1.c
gcc/testsuite/gcc.dg/atomic-load-2.c
gcc/testsuite/gcc.dg/atomic-load-3.c
gcc/testsuite/gcc.dg/atomic-lockfree.c
gcc/testsuite/gcc.dg/atomic-lockfree-aux.c
gcc/testsuite/gcc.dg/atomic-noinline.c
gcc/testsuite/gcc.dg/atomic-noinline-aux.c
gcc/testsuite/gcc.dg/atomic-op-1.c
gcc/testsuite/gcc.dg/atomic-op-2.c
gcc/testsuite/gcc.dg/atomic-op-3.c
gcc/testsuite/gcc.dg/atomic-op-6.c
gcc/testsuite/gcc.dg/atomic-store-1.c
gcc/testsuite/gcc.dg/atomic-store-2.c
gcc/testsuite/gcc.dg/atomic-store-3.c
gcc/testsuite/g++.dg/ext/atomic-1.C
gcc/testsuite/g++.dg/ext/atomic-2.C
gcc/testsuite/gcc.target/arm/atomic-comp-swap-release-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-acq_rel.c
gcc/testsuite/gcc.target/arm/atomic-op-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-char.c
gcc/testsuite/gcc.target/arm/atomic-op-consume.c
gcc/testsuite/gcc.target/arm/atomic-op-int.c
gcc/testsuite/gcc.target/arm/atomic-op-relaxed.c
gcc/testsuite/gcc.target/arm/atomic-op-release.c
gcc/testsuite/gcc.target/arm/atomic-op-seq_cst.c
gcc/testsuite/gcc.target/arm/atomic-op-short.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_1.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_2.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_3.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_4.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_5.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_6.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_7.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_8.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_9.c
gcc/testsuite/gcc.target/arm/sync-1.c
gcc/testsuite/gcc.target/arm/synchronize.c
gcc/testsuite/gcc.target/arm/armv8-sync-comp-swap.c

[arm-embedded] [PATCH, ARM 4/7] Adapt atomic compare and swap to ARMv8-M Baseline

[Thomas Preudhomme]

Hi,

We've decided to apply the following patch to ARM/embedded-6-branch.

Best regards,

Thomas
--- Begin Message ---

Hi,

This patch is part of a patch series to add support for atomic operations on 
ARMv8-M Baseline targets in GCC. This specific patch makes the necessary change 
for compare and swap to work for ARMv8-M Baseline, doubleword integers excepted. 
Namely, it adds Thumb-1 specific constraints to compare_and_swap. The 
constraints are chosen so that once the pattern is splitted, the individual 
instructions have their constraints respected. In particular, the constraints 
for the cbranchsi4_* pattern must be duplicated here, which explains the use of 
several alternatives.


Note: changes to enable other atomic operation are in the next patch of the 
series.

ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2016-07-05  Thomas Preud'homme  

* config/arm/sync.md (atomic_compare_and_swap_1): Add new ARMv8-M
Baseline only alternatives to (i) hold store atomic success value in a
return register rather than a scratch register, (ii) use a low register
for it and to (iii) ensure the cbranchsi insn generated by the split
respect the constraints of Thumb-1 cbranchsi4_insn and
cbranchsi4_scratch.
* config/arm/thumb1.md (cbranchsi4_insn): Add comment to indicate
constraints must match those in atomic_compare_and_swap.
(cbranchsi4_scratch): Likewise.


Testing: No code generation difference for ARMv7-A, ARMv7VE and ARMv8-A on all 
atomic and synchronization testcases in the testsuite [2]. Patchset was also 
bootstrapped with --enable-itm --enable-gomp on ARMv8-A in ARM and Thumb mode at 
optimization level -O1 and above [1] without any regression in the testsuite and 
no code generation difference in libitm and libgomp.


Code generation for ARMv8-M Baseline has been manually examined and compared 
against ARMv8-A Thumb-2 for the following configuration without finding any issue:


gcc.dg/atomic-op-2.c at -Os
gcc.dg/atomic-compare-exchange-2.c at -Os
gcc.dg/atomic-compare-exchange-3.c at -O3


Is this ok for trunk?

Best regards,

Thomas

[1] CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET were set to "-O1 -g", "-O3 -g" and 
undefined ("-O2 -g")

[2] The exact list is:

gcc/testsuite/gcc.dg/atomic-compare-exchange-1.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-2.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-3.c
gcc/testsuite/gcc.dg/atomic-exchange-1.c
gcc/testsuite/gcc.dg/atomic-exchange-2.c
gcc/testsuite/gcc.dg/atomic-exchange-3.c
gcc/testsuite/gcc.dg/atomic-fence.c
gcc/testsuite/gcc.dg/atomic-flag.c
gcc/testsuite/gcc.dg/atomic-generic.c
gcc/testsuite/gcc.dg/atomic-generic-aux.c
gcc/testsuite/gcc.dg/atomic-invalid-2.c
gcc/testsuite/gcc.dg/atomic-load-1.c
gcc/testsuite/gcc.dg/atomic-load-2.c
gcc/testsuite/gcc.dg/atomic-load-3.c
gcc/testsuite/gcc.dg/atomic-lockfree.c
gcc/testsuite/gcc.dg/atomic-lockfree-aux.c
gcc/testsuite/gcc.dg/atomic-noinline.c
gcc/testsuite/gcc.dg/atomic-noinline-aux.c
gcc/testsuite/gcc.dg/atomic-op-1.c
gcc/testsuite/gcc.dg/atomic-op-2.c
gcc/testsuite/gcc.dg/atomic-op-3.c
gcc/testsuite/gcc.dg/atomic-op-6.c
gcc/testsuite/gcc.dg/atomic-store-1.c
gcc/testsuite/gcc.dg/atomic-store-2.c
gcc/testsuite/gcc.dg/atomic-store-3.c
gcc/testsuite/g++.dg/ext/atomic-1.C
gcc/testsuite/g++.dg/ext/atomic-2.C
gcc/testsuite/gcc.target/arm/atomic-comp-swap-release-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-acq_rel.c
gcc/testsuite/gcc.target/arm/atomic-op-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-char.c
gcc/testsuite/gcc.target/arm/atomic-op-consume.c
gcc/testsuite/gcc.target/arm/atomic-op-int.c
gcc/testsuite/gcc.target/arm/atomic-op-relaxed.c
gcc/testsuite/gcc.target/arm/atomic-op-release.c
gcc/testsuite/gcc.target/arm/atomic-op-seq_cst.c
gcc/testsuite/gcc.target/arm/atomic-op-short.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_1.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_2.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_3.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_4.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_5.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_6.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_7.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_8.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_9.c
gcc/testsuite/gcc.target/arm/sync-1.c
gcc/testsuite/gcc.target/arm/synchronize.c
gcc/testsuite/gcc.target/arm/armv8-sync-comp-swap.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-acquire.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-full.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-release.c
libstdc++-v3/testsuite/29_atomics/atomic/60658.cc
libstdc++-v3/testsuite/29_atomics/atomic/62259.cc
libstdc++-v3/testsuite/29_atomics/atomic/64658.cc
libstdc++-v3/testsuite/29_atomics/atomic/65147.cc
libstdc++-v3/testsuite/29_atomics/atomic/65913.cc
libstdc++-v3/testsuite/29_atomics/atomic/70766.cc
libstdc++-v3/testsuite/29_atomics/atomic/cons/49445.cc
libstdc++-v3/testsuite/29_atomics/atomic/cons/constexpr.cc

[arm-embedded] [PATCH, ARM 3/7] Refactor atomic compare_and_swap to make it fit for ARMv8-M Baseline

[Thomas Preudhomme]

Hi,

We've decided to apply the following patch to ARM/embedded-6-branch.

Best regards,

Thomas
--- Begin Message ---

Hi,

This patch is part of a patch series to add support for atomic operations on 
ARMv8-M Baseline targets in GCC. This specific patch refactors the expander and 
splitter for atomics to make the logic work with ARMv8-M Baseline which has 
limitation of Thumb-1 in terms of CC flag setting and different conditional 
compare insn patterns.


ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2016-09-02  Thomas Preud'homme  

* config/arm/arm.c (arm_expand_compare_and_swap): Add new bdst local
variable.  Add the new parameter to the insn generator.  Set that
parameter to be CC flag for 32-bit targets, bval otherwise.  Set the
return value from the negation of that parameter for Thumb-1, keeping
the logic unchanged otherwise except for using bdst as the destination
register of the compare_and_swap insn.
(arm_split_compare_and_swap): Add explanation about how is the value
returned to the function comment.  Rename scratch variable to
neg_bval.  Adapt initialization of variables holding operands to the
new operand numbers.  Use return register to hold result of store
exclusive for Thumb-1, scratch register otherwise.  Construct the
appropriate cbranch for Thumb-1 targets, keeping the logic unchanged
for 32-bit targets.  Guard Z flag setting to restrict to 32bit targets.
Use gen_cbranchsi4 rather than hand-written conditional branch to loop
for strongly ordered compare_and_swap.
* config/arm/predicates.md (cc_register_operand): New predicate.
* config/arm/sync.md (atomic_compare_and_swap_1): Use a
match_operand with the new predicate to accept either the CC flag or a
destination register for the boolean return value, restricting it to
CC flag only via constraint.  Adapt operand numbers accordingly.


Testing: No code generation difference for ARMv7-A, ARMv7VE and ARMv8-A on all 
atomic and synchronization testcases in the testsuite [2]. Patchset was also 
bootstrapped with --enable-itm --enable-gomp on ARMv8-A in ARM and Thumb mode at 
optimization level -O1 and above [1] without any regression in the testsuite and 
no code generation difference in libitm and libgomp.


Code generation for ARMv8-M Baseline has been manually examined and compared 
against ARMv8-A Thumb-2 for the following configuration without finding any issue:


gcc.dg/atomic-op-2.c at -Os
gcc.dg/atomic-compare-exchange-2.c at -Os
gcc.dg/atomic-compare-exchange-3.c at -O3


Is this ok for trunk?

Best regards,

Thomas

[1] CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET were set to "-O1 -g", "-O3 -g" and 
undefined ("-O2 -g")

[2] The exact list is:

gcc/testsuite/gcc.dg/atomic-compare-exchange-1.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-2.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-3.c
gcc/testsuite/gcc.dg/atomic-exchange-1.c
gcc/testsuite/gcc.dg/atomic-exchange-2.c
gcc/testsuite/gcc.dg/atomic-exchange-3.c
gcc/testsuite/gcc.dg/atomic-fence.c
gcc/testsuite/gcc.dg/atomic-flag.c
gcc/testsuite/gcc.dg/atomic-generic.c
gcc/testsuite/gcc.dg/atomic-generic-aux.c
gcc/testsuite/gcc.dg/atomic-invalid-2.c
gcc/testsuite/gcc.dg/atomic-load-1.c
gcc/testsuite/gcc.dg/atomic-load-2.c
gcc/testsuite/gcc.dg/atomic-load-3.c
gcc/testsuite/gcc.dg/atomic-lockfree.c
gcc/testsuite/gcc.dg/atomic-lockfree-aux.c
gcc/testsuite/gcc.dg/atomic-noinline.c
gcc/testsuite/gcc.dg/atomic-noinline-aux.c
gcc/testsuite/gcc.dg/atomic-op-1.c
gcc/testsuite/gcc.dg/atomic-op-2.c
gcc/testsuite/gcc.dg/atomic-op-3.c
gcc/testsuite/gcc.dg/atomic-op-6.c
gcc/testsuite/gcc.dg/atomic-store-1.c
gcc/testsuite/gcc.dg/atomic-store-2.c
gcc/testsuite/gcc.dg/atomic-store-3.c
gcc/testsuite/g++.dg/ext/atomic-1.C
gcc/testsuite/g++.dg/ext/atomic-2.C
gcc/testsuite/gcc.target/arm/atomic-comp-swap-release-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-acq_rel.c
gcc/testsuite/gcc.target/arm/atomic-op-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-char.c
gcc/testsuite/gcc.target/arm/atomic-op-consume.c
gcc/testsuite/gcc.target/arm/atomic-op-int.c
gcc/testsuite/gcc.target/arm/atomic-op-relaxed.c
gcc/testsuite/gcc.target/arm/atomic-op-release.c
gcc/testsuite/gcc.target/arm/atomic-op-seq_cst.c
gcc/testsuite/gcc.target/arm/atomic-op-short.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_1.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_2.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_3.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_4.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_5.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_6.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_7.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_8.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_9.c
gcc/testsuite/gcc.target/arm/sync-1.c
gcc/testsuite/gcc.target/arm/synchronize.c
gcc/testsuite/gcc.target/arm/armv8-sync-comp-swap.c

[arm-embedded] [PATCH, ARM 2/7] Adapt atomic and exclusive load and store to ARMv8-M Baseline

[Thomas Preudhomme]

Hi,

We've decided to apply the following patch to ARM/embedded-6-branch.

Best regards,

Thomas
--- Begin Message ---

Hi,

This patch is part of a patch series to add support for atomic operations on 
ARMv8-M Baseline targets in GCC. This specific patch adapts atomic and exclusive 
load and store patterns to the constraints of ARMv8-M Baseline. It consists of 
two sets of changes:


- adding non predicated output templates because ARMv8-M Baseline does not have 
IT instruction

- use low registers for ldr/str

Together these changes require to create 2 new alternatives for atomic_load and 
atomic_store: (i) one for relaxed, consume and release memory model (the new Pf 
constraint) where ldr/str are used and thus low registers must be used and (ii) 
another one for the other memory model where lda/stl are used. These are 
separate from the constraint for 32bit targets whose output templates expect 
predication.


ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2016-07-05  Thomas Preud'homme  

* config/arm/constraints.md (Q constraint): Document its use for
Thumb-1.
(Pf constraint): New constraint for relaxed, consume or relaxed memory
models.
* config/arm/sync.md (atomic_load): Add new ARMv8-M Baseline only
alternatives to allow any register when memory model matches Pf and
thus lda is used, but only low registers otherwise.  Use unpredicated
output template for Thumb-1 targets.
(atomic_store): Likewise for stl.
(arm_load_exclusive): Add new ARMv8-M Baseline only alternative
whose output template does not have predication.
(arm_load_acquire_exclusive): Likewise.
(arm_load_exclusivesi): Likewise.
(arm_load_acquire_exclusivesi): Likewise.
(arm_store_release_exclusive): Likewise.
(arm_store_exclusive): Use unpredicated output template for
Thumb-1 targets.


Testing: No code generation difference for ARMv7-A, ARMv7VE and ARMv8-A on all 
atomic and synchronization testcases in the testsuite [2]. Patchset was also 
bootstrapped with --enable-itm --enable-gomp on ARMv8-A in ARM and Thumb mode at 
optimization level -O1 and above [1] without any regression in the testsuite and 
no code generation difference in libitm and libgomp.


Code generation for ARMv8-M Baseline has been manually examined and compared 
against ARMv8-A Thumb-2 for the following configuration without finding any issue:


gcc.dg/atomic-op-2.c at -Os
gcc.dg/atomic-compare-exchange-2.c at -Os
gcc.dg/atomic-compare-exchange-3.c at -O3


Is this ok for trunk?

Best regards,

Thomas

[1] CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET were set to "-O1 -g", "-O3 -g" and 
undefined ("-O2 -g")

[2] The exact list is:

gcc/testsuite/gcc.dg/atomic-compare-exchange-1.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-2.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-3.c
gcc/testsuite/gcc.dg/atomic-exchange-1.c
gcc/testsuite/gcc.dg/atomic-exchange-2.c
gcc/testsuite/gcc.dg/atomic-exchange-3.c
gcc/testsuite/gcc.dg/atomic-fence.c
gcc/testsuite/gcc.dg/atomic-flag.c
gcc/testsuite/gcc.dg/atomic-generic.c
gcc/testsuite/gcc.dg/atomic-generic-aux.c
gcc/testsuite/gcc.dg/atomic-invalid-2.c
gcc/testsuite/gcc.dg/atomic-load-1.c
gcc/testsuite/gcc.dg/atomic-load-2.c
gcc/testsuite/gcc.dg/atomic-load-3.c
gcc/testsuite/gcc.dg/atomic-lockfree.c
gcc/testsuite/gcc.dg/atomic-lockfree-aux.c
gcc/testsuite/gcc.dg/atomic-noinline.c
gcc/testsuite/gcc.dg/atomic-noinline-aux.c
gcc/testsuite/gcc.dg/atomic-op-1.c
gcc/testsuite/gcc.dg/atomic-op-2.c
gcc/testsuite/gcc.dg/atomic-op-3.c
gcc/testsuite/gcc.dg/atomic-op-6.c
gcc/testsuite/gcc.dg/atomic-store-1.c
gcc/testsuite/gcc.dg/atomic-store-2.c
gcc/testsuite/gcc.dg/atomic-store-3.c
gcc/testsuite/g++.dg/ext/atomic-1.C
gcc/testsuite/g++.dg/ext/atomic-2.C
gcc/testsuite/gcc.target/arm/atomic-comp-swap-release-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-acq_rel.c
gcc/testsuite/gcc.target/arm/atomic-op-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-char.c
gcc/testsuite/gcc.target/arm/atomic-op-consume.c
gcc/testsuite/gcc.target/arm/atomic-op-int.c
gcc/testsuite/gcc.target/arm/atomic-op-relaxed.c
gcc/testsuite/gcc.target/arm/atomic-op-release.c
gcc/testsuite/gcc.target/arm/atomic-op-seq_cst.c
gcc/testsuite/gcc.target/arm/atomic-op-short.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_1.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_2.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_3.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_4.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_5.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_6.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_7.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_8.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_9.c
gcc/testsuite/gcc.target/arm/sync-1.c
gcc/testsuite/gcc.target/arm/synchronize.c
gcc/testsuite/gcc.target/arm/armv8-sync-comp-swap.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-acquire.c

[arm-embedded] [PATCH, 1/7] Move memory model declarations in memmodel.h

[Thomas Preudhomme]

Hi,

We've decided to apply the following patch to ARM/embedded-6-branch.

Best regards,

Thomas
--- Begin Message ---

Hi,

This patch is part of a patch series to add support for ARMv8-M[1] to GCC. This 
specific patch moves memory model declarations in memmodel.h.


Currently, is_mm_* memory model related functions are declared in tree.h which 
prevents using them in constraints machine description files. This patch move 
this functions into a new memmodel.h header to allow such a thing and update all 
users of this function to include the new header.


ChangeLog entries are as follows:

*** gcc/ChangeLog ***

2016-04-20  Thomas Preud'homme  

* tree.h (memmodel_from_int, memmodel_base, is_mm_relaxed,
is_mm_consume, is_mm_acquire, is_mm_release, is_mm_acq_rel,
is_mm_seq_cst, is_mm_sync): Move to ...
* memmodel.h: This.  New file.
* builtins.c: Include memmodel.h.
* optabs.c: Likewise.
* tsan.c: Likewise.
* config/aarch64/aarch64.c: Likewise.
* config/alpha/alpha.c: Likewise.
* config/arm/arm.c: Likewise.
* config/i386/i386.c: Likewise.
* config/ia64/ia64.c: Likewise.
* config/mips/mips.c: Likewise.
* config/rs6000/rs6000.c: Likewise.
* config/sparc/sparc.c: Likewise.
* genconditions.c: Include memmodel.h in generated file.
* genemit.c: Likewise.
* genoutput.c: Likewise.
* genpeep.c: Likewise.
* genpreds.c: Likewise.
* genrecog.c: Likewise.


*** gcc/c-family/ChangeLog ***

2016-04-20  Thomas Preud'homme  

* c-common.c: Include memmodel.h.


Is this ok for trunk?

Best regards,

Thomas
diff --git a/gcc/builtins.c b/gcc/builtins.c
index b981bcd281af29cdbb1d6bcc1e9f93b769708897..3d9c8aa38b6aea03b2f4ddc59222f19ba078 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -28,6 +28,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "target.h"
 #include "rtl.h"
 #include "tree.h"
+#include "memmodel.h"
 #include "gimple.h"
 #include "predict.h"
 #include "tm_p.h"
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 399ba975184e934bc061113286787840a7531291..a74301fa6de1897007635574ab36058572d953b3 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -25,6 +25,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "target.h"
 #include "function.h"
 #include "tree.h"
+#include "memmodel.h"
 #include "c-common.h"
 #include "gimple-expr.h"
 #include "tm_p.h"
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 5efad462f11f2954a65386b3b6b8d51bd61c51c1..913e026f54cc8464ba9cee0dbecd2a711458dc41 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -26,6 +26,7 @@
 #include "target.h"
 #include "rtl.h"
 #include "tree.h"
+#include "memmodel.h"
 #include "gimple.h"
 #include "cfghooks.h"
 #include "cfgloop.h"
diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
index 702cd277ede8860c53d3ce4c03a8c6d81f7b5c5b..488902741504bc2f93424da6e80e83270d24edd2 100644
--- a/gcc/config/alpha/alpha.c
+++ b/gcc/config/alpha/alpha.c
@@ -26,6 +26,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "target.h"
 #include "rtl.h"
 #include "tree.h"
+#include "memmodel.h"
 #include "gimple.h"
 #include "df.h"
 #include "tm_p.h"
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 946f308ca84e232af8af6eca4813464914cbd59c..97b3ef1673a98f406aed023f5715c35ebf69b07e 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -27,6 +27,7 @@
 #include "target.h"
 #include "rtl.h"
 #include "tree.h"
+#include "memmodel.h"
 #include "cfghooks.h"
 #include "df.h"
 #include "tm_p.h"
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 3ac115c64f717f928eeb8085fea941383121df85..00c5a3db569e0d1758a8e96b3ff1b9f4446b6ad7 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -23,6 +23,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "backend.h"
 #include "rtl.h"
 #include "tree.h"
+#include "memmodel.h"
 #include "gimple.h"
 #include "cfghooks.h"
 #include "cfgloop.h"
diff --git a/gcc/config/ia64/ia64.c b/gcc/config/ia64/ia64.c
index ebd2c86b8d8f917248453070105b1fb5178bc7a3..1f3628b254cac4ef9ea0e72024fe309c4d0eb0da 100644
--- a/gcc/config/ia64/ia64.c
+++ b/gcc/config/ia64/ia64.c
@@ -26,6 +26,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "target.h"
 #include "rtl.h"
 #include "tree.h"
+#include "memmodel.h"
 #include "cfghooks.h"
 #include "df.h"
 #include "tm_p.h"
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 88f4038224a9cdc904cbf15b2a5833b6525702ab..3586a1001e7a920571b1be6d41f9a8e1345f33cc 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -28,6 +28,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "target.h"
 #include "rtl.h"
 #include "tree.h"
+#include 

[PATCH, testsuite]: Add x86_64 to gcc.dg/debug/dwarf2/const-2b.c target selector

[Uros Bizjak]

2016-09-22  Uros Bizjak  

* gcc.dg/debug/dwarf2/const-2b.c: Also compile for x86_64-*-*.
Remove SSE effective target requirement.

Tested on x86_64-linux-gnu {,-m32} where the testcase currently fails
for unrelated reasons.

Committed to mainline SVN.

Uros.
Index: gcc.dg/debug/dwarf2/const-2b.c
===
--- gcc.dg/debug/dwarf2/const-2b.c  (revision 240365)
+++ gcc.dg/debug/dwarf2/const-2b.c  (working copy)
@@ -1,6 +1,5 @@
-/* { dg-do compile { target i386*-*-* } } */
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
 /* { dg-options "-O -gdwarf -dA -msse" } */
-/* { dg-require-effective-target sse } */
 /* { dg-final { scan-assembler "DW_AT_const_value" } } */
 
 typedef float FloatVect __attribute__((__vector_size__(16)));

Re: [PATCH, ARM/testsuite 6/7] Force soft float in ARMv6-M and ARMv8-M Baseline options

[Thomas Preudhomme]

On 22/09/16 16:47, Richard Earnshaw (lists) wrote:

On 22/09/16 15:51, Thomas Preudhomme wrote:

Sorry, noticed an error in the patch. It was not caught during testing
because GCC was built with --with-mode=thumb. Correct patch attached.

Best regards,

Thomas

On 22/09/16 14:49, Thomas Preudhomme wrote:

Hi,

ARMv6-M and ARMv8-M Baseline only support soft float ABI. Therefore, the
arm_arch_v8m_base add option should pass -mfloat-abi=soft, much like
-mthumb is
passed for architectures that only support Thumb instruction set. This
patch
adds -mfloat-abi=soft to both arm_arch_v6m and arm_arch_v8m_base add
options.
Patch is in attachment.

ChangeLog entry is as follows:

*** gcc/testsuite/ChangeLog ***

2016-07-15  Thomas Preud'homme  

* lib/target-supports.exp (add_options_for_arm_arch_v6m): Add
-mfloat-abi=soft option.
(add_options_for_arm_arch_v8m_base): Likewise.


Is this ok for trunk?

Best regards,

Thomas


6_softfloat_testing_v6m_v8m_baseline.patch


diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 
0dabea0850124947a7fe333e0b94c4077434f278..b5d72f1283be6a6e4736a1d20936e169c1384398
 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3540,24 +3540,25 @@ proc check_effective_target_arm_fp16_hw { } {
 # Usage: /* { dg-require-effective-target arm_arch_v5_ok } */
 #/* { dg-add-options arm_arch_v5 } */
 #   /* { dg-require-effective-target arm_arch_v5_multilib } */
-foreach { armfunc armflag armdef } { v4 "-march=armv4 -marm" __ARM_ARCH_4__
-v4t "-march=armv4t" __ARM_ARCH_4T__
-v5 "-march=armv5 -marm" __ARM_ARCH_5__
-v5t "-march=armv5t" __ARM_ARCH_5T__
-v5te "-march=armv5te" __ARM_ARCH_5TE__
-v6 "-march=armv6" __ARM_ARCH_6__
-v6k "-march=armv6k" __ARM_ARCH_6K__
-v6t2 "-march=armv6t2" __ARM_ARCH_6T2__
-v6z "-march=armv6z" __ARM_ARCH_6Z__
-v6m "-march=armv6-m -mthumb" 
__ARM_ARCH_6M__
-v7a "-march=armv7-a" __ARM_ARCH_7A__
-v7r "-march=armv7-r" __ARM_ARCH_7R__
-v7m "-march=armv7-m -mthumb" 
__ARM_ARCH_7M__
-v7em "-march=armv7e-m -mthumb" 
__ARM_ARCH_7EM__
-v8a "-march=armv8-a" __ARM_ARCH_8A__
-v8_1a "-march=armv8.1a" __ARM_ARCH_8A__
-v8m_base "-march=armv8-m.base -mthumb" 
__ARM_ARCH_8M_BASE__
-v8m_main "-march=armv8-m.main -mthumb" 
__ARM_ARCH_8M_MAIN__ } {
+foreach { armfunc armflag armdef } {
+   v4 "-march=armv4 -marm" __ARM_ARCH_4__
+   v4t "-march=armv4t" __ARM_ARCH_4T__
+   v5 "-march=armv5 -marm" __ARM_ARCH_5__
+   v5t "-march=armv5t" __ARM_ARCH_5T__
+   v5te "-march=armv5te" __ARM_ARCH_5TE__
+   v6 "-march=armv6" __ARM_ARCH_6__
+   v6k "-march=armv6k" __ARM_ARCH_6K__
+   v6t2 "-march=armv6t2" __ARM_ARCH_6T2__
+   v6z "-march=armv6z" __ARM_ARCH_6Z__
+   v6m "-march=armv6-m -mthumb -mfloat-abi=soft" __ARM_ARCH_6M__
+   v7a "-march=armv7-a" __ARM_ARCH_7A__
+   v7r "-march=armv7-r" __ARM_ARCH_7R__
+   v7m "-march=armv7-m -mthumb" __ARM_ARCH_7M__
+   v7em "-march=armv7e-m -mthumb" __ARM_ARCH_7EM__
+   v8a "-march=armv8-a" __ARM_ARCH_8A__
+   v8_1a "-march=armv8.1a" __ARM_ARCH_8A__
+   v8m_base "-march=armv8-m.base -mthumb -mfloat-abi=soft" 
__ARM_ARCH_8M_BASE__
+   v8m_main "-march=armv8-m.main -mthumb" __ARM_ARCH_8M_MAIN__ } {
 eval [string map [list FUNC $armfunc FLAG $armflag DEF $armdef ] {
proc check_effective_target_arm_arch_FUNC_ok { } {
if { [ string match "*-marm*" "FLAG" ] &&



I think if you're going to do this you need to also check that changing
the ABI in this way isn't incompatible with other aspects of how the
user has invoked dejagnu.


So should this check also be done for all the target for which -mthumb is passed 
or is there a difference between the two situations?


Best regards,

Thomas

Re: Make regcprop to eliminate noop moves better

[Bernd Schmidt]

On 09/22/2016 01:48 PM, Jan Hubicka wrote:


* postreload.c (reload_cse_simplify): Also accept USE in noop move
patterns.

diff --git a/gcc/postreload.c b/gcc/postreload.c
index 61c1ce8..4f3a526 100644
--- a/gcc/postreload.c
+++ b/gcc/postreload.c
@@ -153,7 +153,8 @@ reload_cse_simplify (rtx_insn *insn, rtx testreg)
  value = SET_DEST (part);
}
}
- else if (GET_CODE (part) != CLOBBER)
+ else if (GET_CODE (part) != CLOBBER
+  && GET_CODE (part) != USE)
break;
}


Hmm. This is probably ok, but what's the USE for in your pattern?


Bernd

Re: [PATCH, ARM/testsuite 6/7] Force soft float in ARMv6-M and ARMv8-M Baseline options

[Richard Earnshaw (lists)]

On 22/09/16 15:51, Thomas Preudhomme wrote:
> Sorry, noticed an error in the patch. It was not caught during testing
> because GCC was built with --with-mode=thumb. Correct patch attached.
> 
> Best regards,
> 
> Thomas
> 
> On 22/09/16 14:49, Thomas Preudhomme wrote:
>> Hi,
>>
>> ARMv6-M and ARMv8-M Baseline only support soft float ABI. Therefore, the
>> arm_arch_v8m_base add option should pass -mfloat-abi=soft, much like
>> -mthumb is
>> passed for architectures that only support Thumb instruction set. This
>> patch
>> adds -mfloat-abi=soft to both arm_arch_v6m and arm_arch_v8m_base add
>> options.
>> Patch is in attachment.
>>
>> ChangeLog entry is as follows:
>>
>> *** gcc/testsuite/ChangeLog ***
>>
>> 2016-07-15  Thomas Preud'homme  
>>
>> * lib/target-supports.exp (add_options_for_arm_arch_v6m): Add
>> -mfloat-abi=soft option.
>> (add_options_for_arm_arch_v8m_base): Likewise.
>>
>>
>> Is this ok for trunk?
>>
>> Best regards,
>>
>> Thomas
> 
> 6_softfloat_testing_v6m_v8m_baseline.patch
> 
> 
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index 
> 0dabea0850124947a7fe333e0b94c4077434f278..b5d72f1283be6a6e4736a1d20936e169c1384398
>  100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -3540,24 +3540,25 @@ proc check_effective_target_arm_fp16_hw { } {
>  # Usage: /* { dg-require-effective-target arm_arch_v5_ok } */
>  #/* { dg-add-options arm_arch_v5 } */
>  # /* { dg-require-effective-target arm_arch_v5_multilib } */
> -foreach { armfunc armflag armdef } { v4 "-march=armv4 -marm" __ARM_ARCH_4__
> -  v4t "-march=armv4t" __ARM_ARCH_4T__
> -  v5 "-march=armv5 -marm" __ARM_ARCH_5__
> -  v5t "-march=armv5t" __ARM_ARCH_5T__
> -  v5te "-march=armv5te" __ARM_ARCH_5TE__
> -  v6 "-march=armv6" __ARM_ARCH_6__
> -  v6k "-march=armv6k" __ARM_ARCH_6K__
> -  v6t2 "-march=armv6t2" __ARM_ARCH_6T2__
> -  v6z "-march=armv6z" __ARM_ARCH_6Z__
> -  v6m "-march=armv6-m -mthumb" 
> __ARM_ARCH_6M__
> -  v7a "-march=armv7-a" __ARM_ARCH_7A__
> -  v7r "-march=armv7-r" __ARM_ARCH_7R__
> -  v7m "-march=armv7-m -mthumb" 
> __ARM_ARCH_7M__
> -  v7em "-march=armv7e-m -mthumb" 
> __ARM_ARCH_7EM__
> -  v8a "-march=armv8-a" __ARM_ARCH_8A__
> -  v8_1a "-march=armv8.1a" __ARM_ARCH_8A__
> -  v8m_base "-march=armv8-m.base -mthumb" 
> __ARM_ARCH_8M_BASE__
> -  v8m_main "-march=armv8-m.main -mthumb" 
> __ARM_ARCH_8M_MAIN__ } {
> +foreach { armfunc armflag armdef } {
> + v4 "-march=armv4 -marm" __ARM_ARCH_4__
> + v4t "-march=armv4t" __ARM_ARCH_4T__
> + v5 "-march=armv5 -marm" __ARM_ARCH_5__
> + v5t "-march=armv5t" __ARM_ARCH_5T__
> + v5te "-march=armv5te" __ARM_ARCH_5TE__
> + v6 "-march=armv6" __ARM_ARCH_6__
> + v6k "-march=armv6k" __ARM_ARCH_6K__
> + v6t2 "-march=armv6t2" __ARM_ARCH_6T2__
> + v6z "-march=armv6z" __ARM_ARCH_6Z__
> + v6m "-march=armv6-m -mthumb -mfloat-abi=soft" __ARM_ARCH_6M__
> + v7a "-march=armv7-a" __ARM_ARCH_7A__
> + v7r "-march=armv7-r" __ARM_ARCH_7R__
> + v7m "-march=armv7-m -mthumb" __ARM_ARCH_7M__
> + v7em "-march=armv7e-m -mthumb" __ARM_ARCH_7EM__
> + v8a "-march=armv8-a" __ARM_ARCH_8A__
> + v8_1a "-march=armv8.1a" __ARM_ARCH_8A__
> + v8m_base "-march=armv8-m.base -mthumb -mfloat-abi=soft" 
> __ARM_ARCH_8M_BASE__
> + v8m_main "-march=armv8-m.main -mthumb" __ARM_ARCH_8M_MAIN__ } {
>  eval [string map [list FUNC $armfunc FLAG $armflag DEF $armdef ] {
>   proc check_effective_target_arm_arch_FUNC_ok { } {
>   if { [ string match "*-marm*" "FLAG" ] &&
> 

I think if you're going to do this you need to also check that changing
the ABI in this way isn't incompatible with other aspects of how the
user has invoked dejagnu.

R.

Re: [PATCH][RFC][regrename][sel-sched] Fix arm bootstrap

[Kyrill Tkachov]

On 22/09/16 16:24, Alexander Monakov wrote:

On Thu, 22 Sep 2016, Kyrill Tkachov wrote:

I don't follow.  The macro used as a boolean in places changed by your patch
is H_F_P_IS_FRAME_POINTER, not H_F_P_REGNUM.

Am I missing something?

I'm following Bernd's proposed change from:
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01330.html

I see - I was misled by the error in the ChangeLog and the fact that the first
hunk is not relevant to the issue:


diff --git a/gcc/regrename.c b/gcc/regrename.c
index 
54c7768efa226139c340868e42b784fb011a19b9..a7339db441012e338de5697015f04c1fdb970164
 100644
--- a/gcc/regrename.c
+++ b/gcc/regrename.c
@@ -464,8 +464,7 @@ rename_chains (void)
if (frame_pointer_needed)
  {
add_to_hard_reg_set (, Pmode, FRAME_POINTER_REGNUM);
-  if (!HARD_FRAME_POINTER_IS_FRAME_POINTER)
-   add_to_hard_reg_set (, Pmode, HARD_FRAME_POINTER_REGNUM);
+  add_to_hard_reg_set (, Pmode, HARD_FRAME_POINTER_REGNUM);
  }

There's no issue here: H_F_P_REGNUM is not used in the boolean context, only
H_F_P_IS_FRAME_POINTER is. There's no warning here, right?


FOR_EACH_VEC_ELT (id_to_chain, i, this_head)
@@ -479,10 +478,9 @@ rename_chains (void)
continue;
  
if (fixed_regs[reg] || global_regs[reg]

- || (!HARD_FRAME_POINTER_IS_FRAME_POINTER && frame_pointer_needed
- && reg == HARD_FRAME_POINTER_REGNUM)
- || (HARD_FRAME_POINTER_REGNUM && frame_pointer_needed
- && reg == FRAME_POINTER_REGNUM))
+ || (frame_pointer_needed
+ && (reg == HARD_FRAME_POINTER_REGNUM
+ || reg == FRAME_POINTER_REGNUM)))
continue;

OK, so here's the real issue: due to a typo 'H_F_P_REGNUM &&
frame_pointer_needed' is used where H_F_P_IS_FRAME_POINTER was used in a
preprocessor #if previously.

A minimal fix would just change H_F_P_REGNUM back to H_F_P_IS_FRAME_POINTER.
I think that's what should be done in order to restore bootstrap: that's clearly
doing no more than restoring previous semantics. The change you've shown also
alters the meaning of the code: I think if that's desired, that should be a
separate patch.


diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 
25a100ee34f6ceaceda2814ae281cadf8b29e688..4a2679c6701c256c5559fa1e9c156bdaad1c2891
 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -1183,10 +1183,8 @@ mark_unavailable_hard_regs (def_t def, struct reg_rename 
*reg_rename_p,
   frame pointer, or we could not discover its class.  */
if (fixed_regs[regno]
|| global_regs[regno]
-  || (!HARD_FRAME_POINTER_IS_FRAME_POINTER && frame_pointer_needed
+  || (frame_pointer_needed
  && regno == HARD_FRAME_POINTER_REGNUM)
-  || (HARD_FRAME_POINTER_REGNUM && frame_pointer_needed
- && regno == FRAME_POINTER_REGNUM)
|| (reload_completed && cl == NO_REGS))

Originally this condition in sel-sched.c looked exactly like the above in
regrename.c (except the last line).  Please keep them in sync: I think if both
H_F_P_REGNUM and F_P_REGNUM ought to be accepted in rename_chains (like your
patch does), so they should be here in mark_u_h_r.


Thanks for the suggestions.
From what I understand 
(https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01569.html)
the warning won't trigger anymore for macros, so there shouldn't be a bootstrap
failure any more. I'm re-running an arm bootstrap with latest trunk now to 
confirm.
If that is the case, then this is not as urgent to fix.

However it's still a problem we should fix now that it has been exposed.
I'll implement your suggestions and do the usual testing.

Thanks,
Kyrill


Thanks.
Alexander

Re: [PATCHv3][ARM] -mpure-code option for ARM

[Richard Earnshaw (lists)]

On 22/09/16 16:04, Andre Vieira (lists) wrote:
> 
> I reworked the patch according to the comments above.
> 
> Is this OK?
> 
> gcc/ChangeLog:
> 2016-09-22  Andre Vieira  
> Terry Guo  
> 
> * target.def (elf_flags_numeric): New target hook.
> * targhooks.h (default_asm_elf_flags_numeric): New.
> * varasm.c (default_asm_elf_flags_numeric): New.
>   (default_elf_asm_named_section): Use new target hook.
> * config/arm/arm.opt (mpure-code): New.
> * config/arm/arm.h (SECTION_ARM_PURECODE): New.
> * config/arm/arm.c (arm_asm_init_sections): Add section
>   attribute to default text section if -mpure-code.
>   (arm_option_check_internal): Diagnose use of option with
>   non supported targets and/or options.
>   (arm_asm_elf_flags_numeric): New.
>   (arm_function_section): New.
>   (arm_elf_section_type_flags): New.
> * config/arm/elf.h (JUMP_TABLES_IN_TEXT_SECTION): Disable
>   for -mpure-code.
> * gcc/doc/texi (TARGET_ASM_ELF_FLAGS_NUMERIC): New.
> * gcc/doc/texi.in (TARGET_ASM_ELF_FLAGS_NUMERIC): Likewise.
> 
> 
> 
> gcc/testsuite/ChangeLog:
> 2016-09-22  Andre Vieira  
> Terry Guo  
> 
> * gcc.target/arm/pure-code/ffunction-sections.c: New.
> * gcc.target/arm/pure-code/no-literal-pool.c: New.
> * gcc.target/arm/pure-code/pure-code.exp: New.
> 
> 

I missed this last time around, but please can you wrap references to
SHF_ARM_PURECODE in the documentation with @code{...}.

OK with that change.

R.

> 0001-mpure-code-for-ARM.patch
> 
> 
> diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
> index 
> f0cdd669191689bc5dcf3a7c2b60da5a2d201e3f..d10605cee0e6e0e07bbb4e1910d30c91443f8d17
>  100644
> --- a/gcc/config/arm/arm.h
> +++ b/gcc/config/arm/arm.h
> @@ -2263,4 +2263,8 @@ extern const char *host_detect_local_cpu (int argc, 
> const char **argv);
>  /* For switching between functions with different target attributes.  */
>  #define SWITCHABLE_TARGET 1
>  
> +/* Define SECTION_ARM_PURECODE as the ARM specific section attribute
> +   representation for SHF_ARM_PURECODE in GCC.  */
> +#define SECTION_ARM_PURECODE SECTION_MACH_DEP
> +
>  #endif /* ! GCC_ARM_H */
> From d0e5894dbe59ea87a3dfc9f681d5616f178ce3a7 Mon Sep 17 00:00:00 2001
> From: Andre Simoes Dias Vieira 
> Date: Tue, 14 Jun 2016 11:17:12 +0100
> Subject: [PATCH] mpure-code for ARM
> 
> ---
>  gcc/config/arm/arm.c   | 145 
> -
>  gcc/config/arm/arm.h   |   4 +
>  gcc/config/arm/arm.md  |   2 +-
>  gcc/config/arm/arm.opt |   4 +
>  gcc/config/arm/elf.h   |   3 +-
>  gcc/doc/invoke.texi|  11 +-
>  gcc/doc/tm.texi|  12 ++
>  gcc/doc/tm.texi.in |   2 +
>  gcc/hooks.c|  10 ++
>  gcc/target.def |  16 +++
>  gcc/targhooks.h|   1 -
>  .../gcc.target/arm/pure-code/ffunction-sections.c  |  17 +++
>  gcc/testsuite/gcc.target/arm/pure-code/no-casesi.c |  29 +
>  .../gcc.target/arm/pure-code/no-literal-pool.c |  68 ++
>  .../gcc.target/arm/pure-code/pure-code.exp |  54 
>  gcc/varasm.c   |  50 ---
>  16 files changed, 397 insertions(+), 31 deletions(-)
>  create mode 100644 
> gcc/testsuite/gcc.target/arm/pure-code/ffunction-sections.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/pure-code/no-casesi.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/pure-code/no-literal-pool.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/pure-code/pure-code.exp
> 
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 
> f60955438d6f1cc5d996e7eacd4b453213044181..59dc2d3392bf375e26507041309e219215198d62
>  100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -214,8 +214,8 @@ static bool arm_return_in_memory (const_tree, const_tree);
>  static void arm_unwind_emit (FILE *, rtx_insn *);
>  static bool arm_output_ttype (rtx);
>  static void arm_asm_emit_except_personality (rtx);
> -static void arm_asm_init_sections (void);
>  #endif
> +static void arm_asm_init_sections (void);
>  static rtx arm_dwarf_register_span (rtx);
>  
>  static tree arm_cxx_guard_type (void);
> @@ -299,7 +299,10 @@ static unsigned HOST_WIDE_INT arm_asan_shadow_offset 
> (void);
>  static void arm_sched_fusion_priority (rtx_insn *, int, int *, int*);
>  static bool arm_can_output_mi_thunk (const_tree, HOST_WIDE_INT, 
> HOST_WIDE_INT,
>const_tree);
> -
> +static section *arm_function_section (tree, 

Re: [PATCH][RFC][regrename][sel-sched] Fix arm bootstrap

[Alexander Monakov]

On Thu, 22 Sep 2016, Kyrill Tkachov wrote:
> > I don't follow.  The macro used as a boolean in places changed by your patch
> > is H_F_P_IS_FRAME_POINTER, not H_F_P_REGNUM.
> > 
> > Am I missing something?
> 
> I'm following Bernd's proposed change from:
> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01330.html

I see - I was misled by the error in the ChangeLog and the fact that the first
hunk is not relevant to the issue:

> diff --git a/gcc/regrename.c b/gcc/regrename.c
> index 
> 54c7768efa226139c340868e42b784fb011a19b9..a7339db441012e338de5697015f04c1fdb970164
>  100644
> --- a/gcc/regrename.c
> +++ b/gcc/regrename.c
> @@ -464,8 +464,7 @@ rename_chains (void)
>if (frame_pointer_needed)
>  {
>add_to_hard_reg_set (, Pmode, FRAME_POINTER_REGNUM);
> -  if (!HARD_FRAME_POINTER_IS_FRAME_POINTER)
> - add_to_hard_reg_set (, Pmode, HARD_FRAME_POINTER_REGNUM);
> +  add_to_hard_reg_set (, Pmode, HARD_FRAME_POINTER_REGNUM);
>  }

There's no issue here: H_F_P_REGNUM is not used in the boolean context, only
H_F_P_IS_FRAME_POINTER is. There's no warning here, right?

>FOR_EACH_VEC_ELT (id_to_chain, i, this_head)
> @@ -479,10 +478,9 @@ rename_chains (void)
>   continue;
>  
>if (fixed_regs[reg] || global_regs[reg]
> -   || (!HARD_FRAME_POINTER_IS_FRAME_POINTER && frame_pointer_needed
> -   && reg == HARD_FRAME_POINTER_REGNUM)
> -   || (HARD_FRAME_POINTER_REGNUM && frame_pointer_needed
> -   && reg == FRAME_POINTER_REGNUM))
> +   || (frame_pointer_needed
> +   && (reg == HARD_FRAME_POINTER_REGNUM
> +   || reg == FRAME_POINTER_REGNUM)))
>   continue;

OK, so here's the real issue: due to a typo 'H_F_P_REGNUM &&
frame_pointer_needed' is used where H_F_P_IS_FRAME_POINTER was used in a
preprocessor #if previously.

A minimal fix would just change H_F_P_REGNUM back to H_F_P_IS_FRAME_POINTER.
I think that's what should be done in order to restore bootstrap: that's clearly
doing no more than restoring previous semantics. The change you've shown also
alters the meaning of the code: I think if that's desired, that should be a
separate patch.

> diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
> index 
> 25a100ee34f6ceaceda2814ae281cadf8b29e688..4a2679c6701c256c5559fa1e9c156bdaad1c2891
>  100644
> --- a/gcc/sel-sched.c
> +++ b/gcc/sel-sched.c
> @@ -1183,10 +1183,8 @@ mark_unavailable_hard_regs (def_t def, struct 
> reg_rename *reg_rename_p,
>   frame pointer, or we could not discover its class.  */
>if (fixed_regs[regno]
>|| global_regs[regno]
> -  || (!HARD_FRAME_POINTER_IS_FRAME_POINTER && frame_pointer_needed
> +  || (frame_pointer_needed
> && regno == HARD_FRAME_POINTER_REGNUM)
> -  || (HARD_FRAME_POINTER_REGNUM && frame_pointer_needed
> -   && regno == FRAME_POINTER_REGNUM)
>|| (reload_completed && cl == NO_REGS))

Originally this condition in sel-sched.c looked exactly like the above in
regrename.c (except the last line).  Please keep them in sync: I think if both
H_F_P_REGNUM and F_P_REGNUM ought to be accepted in rename_chains (like your
patch does), so they should be here in mark_u_h_r.

Thanks.
Alexander

Re: [PATCH] Fix various minor gimple-ssa-sprintf.c issues

[Martin Sebor]

What I would be even more grateful for is a review of the error
prone parts like those that caused the bootstrap failure.  I.e.,
any lingering assumptions about integer sizes between the host


I must say I'm surprised you do all your computations in HOST_WIDE_INT,
rather than say in wide_int, then you could just compare against
TYPE_{MIN,MAX}_VALUE (TYPE_DOMAIN (integer_type_node)) instead of inventing
a function for that.  As for the warn_* vs. flag_* stuff, it just looked
that the warn_* is tested in lots of functions invoked even for the return
length folding, so it is much harder to prove whether it works properly or
not.


Well, chalk that up to my ignorance of a better/more appropriate
API.  I'll be happy to switch to using it if it simplifies things.
Thanks for the tip!

Martin

Re: [PATCH] fix ILP32 bootstrap failures due to -Wformat-length

[Martin Sebor]

Jeff or Richard,

As the two middle end maintainers familiar with my work, can one
of you approve the updated patch?  It's necessary to restore ILP32
bootstrap on a number of targets (pr77676).

  https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01477.html

Thanks
Martin

On 09/21/2016 06:28 PM, Martin Sebor wrote:

On 09/21/2016 05:09 PM, Jakub Jelinek wrote:

On Wed, Sep 21, 2016 at 04:39:42PM -0600, Martin Sebor wrote:

diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index dddb026..652d3fb 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -210,8 +210,8 @@ struct format_result
 static HOST_WIDE_INT
 target_int_min ()
 {
-  static const unsigned HOST_WIDE_INT int_min
-= 1LLU << (sizeof int_min * CHAR_BIT
+  const unsigned HOST_WIDE_INT int_min
+= 1LLU << (HOST_BITS_PER_WIDE_INT


1LLU should be really HOST_WIDE_INT_1U


- TYPE_PRECISION (integer_type_node) + 1);


Is the shift amount really what you mean?
HOST_BITS_PER_WIDE_INT - TYPE_PRECISION (integer_type_node) + 1
is usually 33 (or 17 or 9 in much rarer cases), so that is
0x2ULL.  Don't you want instead
  = HOST_WIDE_INT_1U << (TYPE_PRECISION (ingeger_type_node) - 1);
so that it will be
0x8000ULL?


Great catch, thank you!  That must have been a copy and paste mistake.




@@ -221,8 +221,8 @@ target_int_min ()
 static unsigned HOST_WIDE_INT
 target_int_max ()
 {
-  static const unsigned HOST_WIDE_INT int_max
-= HOST_WIDE_INT_M1U >> (sizeof int_max * CHAR_BIT
+  const unsigned HOST_WIDE_INT int_max
+= HOST_WIDE_INT_M1U >> (HOST_BITS_PER_WIDE_INT
 - TYPE_PRECISION (integer_type_node) + 1);
   return int_max;
 }


This is expectedly -1ULL >> 33, i.e. 0x7fffULL, which looks ok.


Thanks for double checking that.  There is a test case for this
in the test suite for the optimization but there wasn't one for
the INT_MIN case.  I've added it in the attached patch.  I'll
beef up the return range testing some more before re-enabling
the optimization.

Martin

[Fortran, accaf, patch, v1] Fixing compatibility with opencoarrays (mostly)

[Andre Vehreschild]

Hi all,

attached patch fixes compatibility with opencoarrays by using the old coarray
interface of caf_get() as long as possible.

Bootstrapped and regtested ok on x86_64-linux/F23. Ok for trunk?

Regards,
Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
gcc/fortran/ChangeLog:

2016-09-22  Andre Vehreschild  

* trans-intrinsic.c (gfc_conv_intrinsic_caf_get): Use the old caf-
interface where possible.

gcc/testsuite/ChangeLog:

2016-09-22  Andre Vehreschild  

* gfortran.dg/coarray_lib_comm_1.f90: Using the old caf-interface
here now.

diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index c6883dc..d3f6842 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -1607,10 +1607,9 @@ gfc_conv_intrinsic_caf_get (gfc_se *se, gfc_expr *expr, tree lhs, tree lhs_kind,
   else
 stat = null_pointer_node;
 
-  /* Always use the new get_by_ref ().  When no allocatable components are
- present and the lhs does not reallocation then the "old" get () might
- suffice.  */
-  if (true) //caf_attr->alloc_comp && !may_realloc)
+  /* Only use the new get_by_ref () where it is necessary.  I.e., when the lhs
+ is reallocatable or the right-hand side has allocatable components.  */
+  if (caf_attr->alloc_comp || may_realloc)
 {
   /* Get using caf_get_by_ref.  */
   caf_reference = conv_expr_ref_to_caf_ref (>pre, array_expr);
diff --git a/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90 b/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90
index 7ab5ab4..cfd1e64 100644
--- a/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90
+++ b/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90
@@ -40,7 +40,7 @@ end
 
 ! { dg-final { scan-tree-dump-times "_gfortran_caf_sendget \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, _gfortran_caf_this_image \\\(0\\\), \[0-9\]+, 0B, caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, 4, 4, 0, 0B\\\);" 1 "original" } }
 ! { dg-final { scan-tree-dump-times "_gfortran_caf_sendget \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, _gfortran_caf_this_image \\\(0\\\), \[0-9\]+, 0B, caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, 4, 4, 1, 0B\\\);" 1 "original" } }
-! { dg-final { scan-tree-dump-times "_gfortran_caf_get_by_ref \\\(caf_token.0, 1, , _ref.\[0-9\]+, 4, 4, 1, 0, 0B\\\);" 1 "original" } }
-! { dg-final { scan-tree-dump-times "_gfortran_caf_get_by_ref \\\(caf_token.1, 1, , _ref.\[0-9\]+, 4, 4, 0, 0, 0B\\\);" 1 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.0, \\\(integer\\\(kind=8\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=8\\\)\\\) a, 1, \[0-9\]+, 0B, , 4, 4, 1, 0B\\\);" 1 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_caf_get \\\(caf_token.1, \\\(integer\\\(kind=8\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=8\\\)\\\) b, 1, \[0-9\]+, 0B, , 4, 4, 0, 0B\\\);" 1 "original" } }
 ! { dg-final { scan-tree-dump-times "_gfortran_caf_sendget \\\(caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, caf_token.0, \\\(integer\\\(kind=\[48\]\\\)\\\) parm.\[0-9\]+.data - \\\(integer\\\(kind=\[48\]\\\)\\\) a, 1, \[0-9\]+, 0B, 4, 4, 0, 0B\\\);" 1 "original" } }
 

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Martin Sebor]

On 09/22/2016 06:14 AM, Rainer Orth wrote:

Hi Martin,


your patch broke bootstrap with MPFR 2.4.2, which is still the
recommended (or perhaps minimal) version according to install.texi:

[...]

The following patch (together with your other one to fix ILP32 targets)
allows a sparc-sun-solaris2.12 bootstrap to continue.  I'm going to
commit it as obvious.


done now.  Once the bootstrap had finished, I see quite a number of
testsuite failures (i386-pc-solaris2.12 still running), both 32 and
64-bit:

+FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c  (test for warnings, line 1220)
+FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c  (test for warnings, line 1270)
+FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c  (test for warnings, line 1381)
+FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c  (test for warnings, line 356)
+FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c  (test for warnings, line 99)
+FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)


I have a patch for (hopefully) most of these failures that I will
commit along with the one for pr77676 as soon as it's approved.


Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:209:3:
 warning: format '%lc' expects argument of type 'wint_t', but argument 5 has 
type 'int' [-Wformat=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:210:3:
 warning: format '%lc' expects argument of type 'wint_t', but argument 5 has 
type 'int' [-Wformat=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:211:3:
 warning: format '%lc' expects argument of type 'wint_t', but argument 5 has 
type 'int' [-Wformat=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:211:3:
 warning: format '%lc' expects argument of type 'wint_t', but argument 6 has 
type 'int' [-Wformat=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:212:3:
 warning: format '%lc' expects argument of type 'wint_t', but argument 5 has 
type 'int' [-Wformat=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:213:3:
 warning: format '%lc' expects argument of type 'wint_t', but argument 5 has 
type 'int' [-Wformat=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:213:3:
 warning: format '%lc' expects argument of type 'wint_t', but argument 6 has 
type 'int' [-Wformat=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:1238:3:
 warning: format '%lc' expects argument of type 'wint_t', but argument 4 has 
type 'int' [-Wformat=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:1239:3:
 warning: format '%lc' expects argument of type 'wint_t', but argument 4 has 
type 'int' [-Wformat=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:1240:3:
 warning: format '%lc' expects argument of type 'wint_t', but argument 4 has 
type 'int' [-Wformat=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:1287:3:
 warning: format '%lc' expects argument of type 'wint_t', but argument 6 has 
type 'int' [-Wformat=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:1288:3:
 warning: format '%lc' expects argument of type 'wint_t', but argument 6 has 
type 'int' [-Wformat=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:1289:3:
 warning: format '%lc' expects argument of type 'wint_t', but argument 6 has 
type 'int' [-Wformat=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:99:3:
 warning: '%p' directive writing 1 byte into a region of size 0 
[-Wformat-length=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:1406:3:
 warning: specified size 4294967295 exceeds the size 2 of the destination 
object [-Wformat-length=]

+FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-2.c  (test for warnings, line 50)
+FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-2.c sprintf transformed into strcpy
(test for warnings, line 83)
+FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-2.c sprintf transformed into strcpy
(test for warnings, line 84)

+FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c (test for excess errors)

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:10:21:
 warning: writing a terminating nul past the end of the destination 
[-Wformat-length=]/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:22:22:
 warning: '%-s' directive writing 4 bytes into a region of size 1 
[-Wformat-length=]

+FAIL: gcc.dg/tree-ssa/builtin-sprintf.c execution test

FAIL: test_a_double:364: "%a" expected result for "0x0.0p+0" 
doesn't match function call return value: 20 != 6
FAIL: test_a_double:365: "%a" expected result for "0x1.0p+0" 
doesn't match function 

Re: [PATCHv3][ARM] -mpure-code option for ARM

[Andre Vieira (lists)]

On 22/09/16 14:52, Richard Earnshaw (lists) wrote:
> On 11/07/16 17:56, Andre Vieira (lists) wrote:
>> On 07/07/16 13:30, mickael guene wrote:
>>> Hi Andre,
>>>
>>>  Another feedback on your purecode patch.
>>>  You have to disable casesi pattern since then it will
>>> generate wrong code with -mpure-code option.
>>>  Indeed it will generate an 'adr rx, .Lx' (aka
>>> 'subs rx, PC, #offset') which will not work in our
>>> case since 'Lx' label is put in an .rodata section.
>>> So offset value is unknown and can be impossible
>>> to encode correctly.
>>>
>>> Regards
>>> Mickael
>>>
>>> On 06/30/2016 04:32 PM, Andre Vieira (lists) wrote:
 Hello,

 This patch adds the -mpure-code option for ARM. This option ensures
 functions are put into sections that contain only code and no data. To
 ensure this throughout compilation we give these sections the ARM
 processor-specific ELF section attribute "SHF_ARM_PURECODE". This option
 is only supported for non-pic code for armv7-m targets.

 This patch introduces a new target hook 'TARGET_ASM_ELF_FLAGS_NUMERIC'.
 This target hook enables a target to use the numeric value for elf
 section attributes rather than their alphabetical representation. If
 TARGET_ASM_ELF_FLAGS_NUMERIC returns TRUE, the existing
 'default_elf_asm_named_section', will print the numeric value of the
 section attributes for the current section. This target hook has two
 parameters:
 unsigned int FLAGS, the input parameter that tells the function the
 current section's attributes;
 unsigned int *NUM, used to pass down the numerical representation of the
 section's attributes.

 The default implementation for TARGET_ASM_ELF_FLAGS_NUMERIC will return
 false, so existing behavior is not changed.

 Bootstrapped and tested for arm-none-linux-gnueabihf. Further tested for
 arm-none-eabi with a Cortex-M3 target.


 gcc/ChangeLog:
 2016-06-30  Andre Vieira  
 Terry Guo  

 * target.def (elf_flags_numeric): New target hook.
 * targhooks.h (default_asm_elf_flags_numeric): New.
 * varasm.c (default_asm_elf_flags_numeric): New.
   (default_elf_asm_named_section): Use new target hook.
 * config/arm/arm.opt (mpure-code): New.
 * config/arm/arm.h (SECTION_ARM_PURECODE): New.
 * config/arm/arm.c (arm_asm_init_sections): Add section
   attribute to default text section if -mpure-code.
   (arm_option_check_internal): Diagnose use of option with
   non supported targets and/or options.
   (arm_asm_elf_flags_numeric): New.
   (arm_function_section): New.
   (arm_elf_section_type_flags): New.
 * config/arm/elf.h (JUMP_TABLES_IN_TEXT_SECTION): Disable
   for -mpure-code.
 * gcc/doc/texi (TARGET_ASM_ELF_FLAGS_NUMERIC): New.
 * gcc/doc/texi.in (TARGET_ASM_ELF_FLAGS_NUMERIC): Likewise.



 gcc/testsuite/ChangeLog:
 2016-06-30  Andre Vieira  
 Terry Guo  

 * gcc.target/arm/pure-code/ffunction-sections.c: New.
 * gcc.target/arm/pure-code/no-literal-pool.c: New.
 * gcc.target/arm/pure-code/pure-code.exp: New.

>>>
>> Hi Sandra, Mickael,
>>
>> Thank you for your comments. I changed the description of -mpure-code in
>> invoke.texi to better reflect the error message you get wrt supported
>> targets.
>>
>> As for the target hook description, I hope the text is clearer now. Let
>> me know if you think it needs further explanation.
>>
>> I also fixed the double '%' in the text string for unnamed text sections
>> and disabled the casesi pattern.
>>
>> I duplicated the original casesi test
>> 'gcc/testsuite/gcc.c-torture/compile/pr46934.c' for pure-code to make
>> sure the casesi was disabled and other patterns were selected instead.
>>
>> Reran regressions for pure-code.exp for Cortex-M3.
>>
>> Cheers,
>> Andre
>>
>>
>> gcc/ChangeLog:
>> 2016-07-11  Andre Vieira  
>> Terry Guo  
>>
>> * target.def (elf_flags_numeric): New target hook.
>> * hooks.c (hook_uint_uintp_false): New generic hook.
>> * varasm.c (default_elf_asm_named_section): Use new target hook.
>> * config/arm/arm.opt (mpure-code): New.
>> * config/arm/arm.h (SECTION_ARM_PURECODE): New.
>> * config/arm/arm.c (arm_asm_init_sections): Add section
>> attribute to default text section if -mpure-code.
>> (arm_option_check_internal): Diagnose use of option with
>> non supported targets and/or options.
>> (arm_asm_elf_flags_numeric): New.
>> (arm_function_section): New.
>> (arm_elf_section_type_flags): New.

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Martin Sebor]

your patch broke bootstrap with MPFR 2.4.2, which is still the
recommended (or perhaps minimal) version according to install.texi:

/vol/gcc/src/hg/trunk/local/gcc/gimple-ssa-sprintf.c: In function 'int 
{anonymous}::format_floating_max(tree, char)':
/vol/gcc/src/hg/trunk/local/gcc/gimple-ssa-sprintf.c:1128:27: error: 
'MPFR_RNDN' was not declared in this scope
   mpfr_from_real (x, , MPFR_RNDN);
   ^
/vol/gcc/src/hg/trunk/local/gcc/gimple-ssa-sprintf.c: In function 
'{anonymous}::fmtresult {anonymous}::format_floating(const 
{anonymous}::conversion_spec&, tree)':
/vol/gcc/src/hg/trunk/local/gcc/gimple-ssa-sprintf.c:1328:37: error: 
'MPFR_RNDN' was not declared in this scope
   mpfr_from_real (mpfrval, rvp, MPFR_RNDN);
 ^

MPFR_RNDN was only introduced in mpfr 3.0.0, and everywhere else in gcc
GMP_RNDN is used instead.  mpfr 3.0.0  has

/* kept for compatibility with MPFR 2.4.x and before */
#define GMP_RNDN MPFR_RNDN

The following patch (together with your other one to fix ILP32 targets)
allows a sparc-sun-solaris2.12 bootstrap to continue.  I'm going to
commit it as obvious.


Thanks.  I didn't realize the older MPFR was still recommended.
FWIW, I was using MPFR 2.4 until recently but after running into
some (unexplained) runtime issues I reran the download_prerequisites
script to update them and it installed 3.1.4.

It seems that either the recommended MPFR version should be bumped
up (or the script downgraded to 2.4 to avoid this risk, though I
suspect there are reasons why it was updated to the latest).

Based on the log the script was updated from MPFR 2.4 to 3.0 in
r235763.  The change also updated install.texi but not the MPFR
version mentioned there.  It might be worth checking with the
author, Bernd Edlinger, to see how to resolve this.  Let me ping
him in a separate thread.

Martin

Re: [PATCH][RFC][regrename][sel-sched] Fix arm bootstrap

[Bernd Edlinger]

On 09/22/16 16:34, Kyrill Tkachov wrote:
>
> On 22/09/16 15:27, Alexander Monakov wrote:
>> H_F_P_IS_FRAME_POINTER (the ChangeLog is wrong).  As I understand, the
>> issue is
>> that config/arm/arm.h defines that to plain 0, which causes the
>> warning (ugh?).
>>
>> Does the following restore bootstrap?
>>
>> Thanks.
>> Alexander
>>
>> diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
>> index 373dc85..1ae82c1 100644
>> --- a/gcc/config/arm/arm.h
>> +++ b/gcc/config/arm/arm.h
>> @@ -887,8 +887,8 @@ extern int arm_arch_crc;
>>  ? ARM_HARD_FRAME_POINTER_REGNUM \
>>  : THUMB_HARD_FRAME_POINTER_REGNUM)
>>
>> -#define HARD_FRAME_POINTER_IS_FRAME_POINTER 0
>> -#define HARD_FRAME_POINTER_IS_ARG_POINTER 0
>> +#define HARD_FRAME_POINTER_IS_FRAME_POINTER false
>> +#define HARD_FRAME_POINTER_IS_ARG_POINTER false
>
> Sorry no, the problem is HARD_FRAME_POINTER_REGNUM that is defined as:
> #define HARD_FRAME_POINTER_REGNUM\
>(TARGET_ARM\
> ? ARM_HARD_FRAME_POINTER_REGNUM\
> : THUMB_HARD_FRAME_POINTER_REGNUM)
>
> where ARM_HARD_FRAME_POINTER_REGNUM is 11 and
> THUMB_HARD_FRAME_POINTER_REGNUM is 7
> so Bernd's new warning triggers whenever HARD_FRAME_POINTER_REGNUM is
> used as a
> boolean like it is in sel-sched.c and regrename.c
>

Yes and that was obviously a typo.

As of today the warning will no longer trigger if the ?: is in a
macro definition, but most ot the time when the warning triggered
so far, it has pointed to something that needed really our attention
like this one here.

I thinking that there will soon be more different levels of that
warning that may probably not be in -Wall, so we can at least
enable finding code like this.


Bernd.

Re: [PATCH, ARM/testsuite 6/7] Force soft float in ARMv6-M and ARMv8-M Baseline options

[Thomas Preudhomme]

Sorry, noticed an error in the patch. It was not caught during testing because 
GCC was built with --with-mode=thumb. Correct patch attached.


Best regards,

Thomas

On 22/09/16 14:49, Thomas Preudhomme wrote:

Hi,

ARMv6-M and ARMv8-M Baseline only support soft float ABI. Therefore, the
arm_arch_v8m_base add option should pass -mfloat-abi=soft, much like -mthumb is
passed for architectures that only support Thumb instruction set. This patch
adds -mfloat-abi=soft to both arm_arch_v6m and arm_arch_v8m_base add options.
Patch is in attachment.

ChangeLog entry is as follows:

*** gcc/testsuite/ChangeLog ***

2016-07-15  Thomas Preud'homme  

* lib/target-supports.exp (add_options_for_arm_arch_v6m): Add
-mfloat-abi=soft option.
(add_options_for_arm_arch_v8m_base): Likewise.


Is this ok for trunk?

Best regards,

Thomas
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 0dabea0850124947a7fe333e0b94c4077434f278..b5d72f1283be6a6e4736a1d20936e169c1384398 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3540,24 +3540,25 @@ proc check_effective_target_arm_fp16_hw { } {
 # Usage: /* { dg-require-effective-target arm_arch_v5_ok } */
 #/* { dg-add-options arm_arch_v5 } */
 #	 /* { dg-require-effective-target arm_arch_v5_multilib } */
-foreach { armfunc armflag armdef } { v4 "-march=armv4 -marm" __ARM_ARCH_4__
- v4t "-march=armv4t" __ARM_ARCH_4T__
- v5 "-march=armv5 -marm" __ARM_ARCH_5__
- v5t "-march=armv5t" __ARM_ARCH_5T__
- v5te "-march=armv5te" __ARM_ARCH_5TE__
- v6 "-march=armv6" __ARM_ARCH_6__
- v6k "-march=armv6k" __ARM_ARCH_6K__
- v6t2 "-march=armv6t2" __ARM_ARCH_6T2__
- v6z "-march=armv6z" __ARM_ARCH_6Z__
- v6m "-march=armv6-m -mthumb" __ARM_ARCH_6M__
- v7a "-march=armv7-a" __ARM_ARCH_7A__
- v7r "-march=armv7-r" __ARM_ARCH_7R__
- v7m "-march=armv7-m -mthumb" __ARM_ARCH_7M__
- v7em "-march=armv7e-m -mthumb" __ARM_ARCH_7EM__
- v8a "-march=armv8-a" __ARM_ARCH_8A__
- v8_1a "-march=armv8.1a" __ARM_ARCH_8A__
- v8m_base "-march=armv8-m.base -mthumb" __ARM_ARCH_8M_BASE__
- v8m_main "-march=armv8-m.main -mthumb" __ARM_ARCH_8M_MAIN__ } {
+foreach { armfunc armflag armdef } {
+	v4 "-march=armv4 -marm" __ARM_ARCH_4__
+	v4t "-march=armv4t" __ARM_ARCH_4T__
+	v5 "-march=armv5 -marm" __ARM_ARCH_5__
+	v5t "-march=armv5t" __ARM_ARCH_5T__
+	v5te "-march=armv5te" __ARM_ARCH_5TE__
+	v6 "-march=armv6" __ARM_ARCH_6__
+	v6k "-march=armv6k" __ARM_ARCH_6K__
+	v6t2 "-march=armv6t2" __ARM_ARCH_6T2__
+	v6z "-march=armv6z" __ARM_ARCH_6Z__
+	v6m "-march=armv6-m -mthumb -mfloat-abi=soft" __ARM_ARCH_6M__
+	v7a "-march=armv7-a" __ARM_ARCH_7A__
+	v7r "-march=armv7-r" __ARM_ARCH_7R__
+	v7m "-march=armv7-m -mthumb" __ARM_ARCH_7M__
+	v7em "-march=armv7e-m -mthumb" __ARM_ARCH_7EM__
+	v8a "-march=armv8-a" __ARM_ARCH_8A__
+	v8_1a "-march=armv8.1a" __ARM_ARCH_8A__
+	v8m_base "-march=armv8-m.base -mthumb -mfloat-abi=soft" __ARM_ARCH_8M_BASE__
+	v8m_main "-march=armv8-m.main -mthumb" __ARM_ARCH_8M_MAIN__ } {
 eval [string map [list FUNC $armfunc FLAG $armflag DEF $armdef ] {
 	proc check_effective_target_arm_arch_FUNC_ok { } {
 	if { [ string match "*-marm*" "FLAG" ] &&

Re: [PATCH][RFC][regrename][sel-sched] Fix arm bootstrap

[Kyrill Tkachov]

On 22/09/16 15:39, Alexander Monakov wrote:

On Thu, 22 Sep 2016, Kyrill Tkachov wrote:

Sorry no, the problem is HARD_FRAME_POINTER_REGNUM that is defined as:
#define HARD_FRAME_POINTER_REGNUM\
   (TARGET_ARM\
? ARM_HARD_FRAME_POINTER_REGNUM\
: THUMB_HARD_FRAME_POINTER_REGNUM)

where ARM_HARD_FRAME_POINTER_REGNUM is 11 and THUMB_HARD_FRAME_POINTER_REGNUM
is 7 so Bernd's new warning triggers whenever HARD_FRAME_POINTER_REGNUM is
used as a boolean like it is in sel-sched.c and regrename.c

I don't follow.  The macro used as a boolean in places changed by your patch is
H_F_P_IS_FRAME_POINTER, not H_F_P_REGNUM.

Am I missing something?


I'm following Bernd's proposed change from:
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01330.html

that includes removing an extra conditional involving: 
HARD_FRAME_POINTER_IS_FRAME_POINTER .

I agree the ChangeLog entry should be better. I'm not very familiar with that 
code, so I
left it generic would something like this be more appropriate?

* regrename.c (rename_chains): Always add hard frame pointer to unavailable
set when frame pointer is needed.

Kyrill



Thanks.
Alexander

Re: [PATCH][RFC][regrename][sel-sched] Fix arm bootstrap

[Alexander Monakov]

On Thu, 22 Sep 2016, Kyrill Tkachov wrote:
> Sorry no, the problem is HARD_FRAME_POINTER_REGNUM that is defined as:
> #define HARD_FRAME_POINTER_REGNUM\
>   (TARGET_ARM\
>? ARM_HARD_FRAME_POINTER_REGNUM\
>: THUMB_HARD_FRAME_POINTER_REGNUM)
> 
> where ARM_HARD_FRAME_POINTER_REGNUM is 11 and THUMB_HARD_FRAME_POINTER_REGNUM
> is 7 so Bernd's new warning triggers whenever HARD_FRAME_POINTER_REGNUM is
> used as a boolean like it is in sel-sched.c and regrename.c

I don't follow.  The macro used as a boolean in places changed by your patch is
H_F_P_IS_FRAME_POINTER, not H_F_P_REGNUM.

Am I missing something?

Thanks.
Alexander

[PATCH] Bits from Early LTO debug merge -- move stuff from late to early finish

[Richard Biener]

This merges moving of unused type pruning from late to early finish as 
well as handling of debug types and dwarf2 dups elimination.  It adds
a flag to DIEs so we can mark them as removed in case sth after
early finish tries to lookup a DIE for a removed DIE again - we shouldn't
re-use the removed DIE (w/o parent) there.

I suppose at some point we should re-think how pruning of "unused"
stuff is supposed to work.  Given my grand plan is to get rid of
debug hooks and allow FEs direct control over the DWARF it should
be ultimatively their decision what to remove (err, not create, in
the first place).

Bootstrap and regtest running on x86_64-unknown-linux-gnu, ok for trunk?

I believe this is the last part I can reasonably split out (but I'll
have a second look after merging back from trunk once this and the other
pending patch is approved).

Thanks,
Richard.

2016-09-22  Richard Biener  

* dwarf2out.c (struct die_struct): Add removed flag.
(lookup_type_die): If the DIE is marked as removed, clear
TYPE_SYMTAB_DIE and return NULL.
(lookup_decl_die): If the DIE is marked as removed, remove it
from the hash and return NULL.
(mark_removed): New helper.
(prune_unused_types_prune): Call it for removed DIEs.
(dwarf2out_finish): Move unused type pruning debug_types handling
and breaking out includes ...
(dwarf2out_early_finish): ... here.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 240353)
+++ gcc/dwarf2out.c (working copy)
@@ -2705,6 +2705,10 @@ typedef struct GTY((chain_circular ("%h.
   /* Die is used and must not be pruned as unused.  */
   BOOL_BITFIELD die_perennial_p : 1;
   BOOL_BITFIELD comdat_type_p : 1; /* DIE has a type signature */
+  /* Whether this DIE was removed from the DIE tree, for example via
+ prune_unused_types.  We don't consider those present from the
+ DIE lookup routines.  */
+  BOOL_BITFIELD removed : 1;
   /* Lots of spare bits.  */
 }
 die_node;
@@ -5098,7 +5102,13 @@ new_die (enum dwarf_tag tag_value, dw_di
 static inline dw_die_ref
 lookup_type_die (tree type)
 {
-  return TYPE_SYMTAB_DIE (type);
+  dw_die_ref die = TYPE_SYMTAB_DIE (type);
+  if (die && die->removed)
+{
+  TYPE_SYMTAB_DIE (type) = NULL;
+  return NULL;
+}
+  return die;
 }
 
 /* Given a TYPE_DIE representing the type TYPE, if TYPE is an
@@ -5163,7 +5173,16 @@ decl_die_hasher::equal (die_node *x, tre
 static inline dw_die_ref
 lookup_decl_die (tree decl)
 {
-  return decl_die_table->find_with_hash (decl, DECL_UID (decl));
+  dw_die_ref *die = decl_die_table->find_slot_with_hash (decl, DECL_UID (decl),
+NO_INSERT);
+  if (!die)
+return NULL;
+  if ((*die)->removed)
+{
+  decl_die_table->clear_slot (die);
+  return NULL;
+}
+  return *die;
 }
 
 /* Returns a hash value for X (which really is a var_loc_list).  */
@@ -26195,6 +26214,16 @@ prune_unused_types_update_strings (dw_di
   }
 }
 
+/* Mark DIE and its children as removed.  */
+
+static void
+mark_removed (dw_die_ref die)
+{
+  dw_die_ref c;
+  die->removed = true;
+  FOR_EACH_CHILD (die, c, mark_removed (c));
+}
+
 /* Remove from the tree DIE any dies that aren't marked.  */
 
 static void
@@ -26224,12 +26253,14 @@ prune_unused_types_prune (dw_die_ref die
  die->die_child = prev;
}
  c->die_sib = NULL;
+ mark_removed (c);
  return;
}
   else
{
  next = c->die_sib;
  c->die_sib = NULL;
+ mark_removed (c);
}
 
 if (c != prev->die_sib)
@@ -27835,37 +27866,6 @@ dwarf2out_finish (const char *)
   resolve_addr (comp_unit_die ());
   move_marked_base_types ();
 
-  if (flag_eliminate_unused_debug_types)
-prune_unused_types ();
-
-  /* Generate separate COMDAT sections for type DIEs. */
-  if (use_debug_types)
-{
-  break_out_comdat_types (comp_unit_die ());
-
-  /* Each new type_unit DIE was added to the limbo die list when created.
- Since these have all been added to comdat_type_list, clear the
- limbo die list.  */
-  limbo_die_list = NULL;
-
-  /* For each new comdat type unit, copy declarations for incomplete
- types to make the new unit self-contained (i.e., no direct
- references to the main compile unit).  */
-  for (ctnode = comdat_type_list; ctnode != NULL; ctnode = ctnode->next)
-copy_decls_for_unworthy_types (ctnode->root_die);
-  copy_decls_for_unworthy_types (comp_unit_die ());
-
-  /* In the process of copying declarations from one unit to another,
- we may have left some declarations behind that are no longer
- referenced.  Prune them.  */
-  prune_unused_types ();
-}
-
-  /* Generate separate CUs for each of the include files we've seen.
- They will go into 

Re: [PATCH][RFC][regrename][sel-sched] Fix arm bootstrap

[Kyrill Tkachov]

On 22/09/16 15:27, Alexander Monakov wrote:

On Thu, 22 Sep 2016, Kyrill Tkachov wrote:

In the the interest of fixing arm bootstrap here are the two blocking issues
and the changes proposed for them.
I'm not familiar enough with regrename or sel-sched to make a call on whether
these are right or not, I just want to keep the ball rolling so we can fix
arm bootstrap.

These changes allowed arm bootstrap to complete.
Are they the right way to go?
If so, I'll do a full bootstrap and test run on aarch64 and x86_64.

Thanks,
Kyrill

2016-09-22  Kyrylo Tkachov  
 Bernd Edlinger  
 Bernd Schmidt  

 * regrename.c (rename_chains): Avoid using HARD_FRAME_POINTER_REGNUM
 in a boolean context.
 * sel-sched.c (mark_unavailable_hard_regs): Likewise.

This doesn't look right to me. Note that you're patching uses of
H_F_P_IS_FRAME_POINTER (the ChangeLog is wrong).  As I understand, the issue is
that config/arm/arm.h defines that to plain 0, which causes the warning (ugh?).

Does the following restore bootstrap?

Thanks.
Alexander

diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 373dc85..1ae82c1 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -887,8 +887,8 @@ extern int arm_arch_crc;
 ? ARM_HARD_FRAME_POINTER_REGNUM \
 : THUMB_HARD_FRAME_POINTER_REGNUM)

-#define HARD_FRAME_POINTER_IS_FRAME_POINTER 0
-#define HARD_FRAME_POINTER_IS_ARG_POINTER 0
+#define HARD_FRAME_POINTER_IS_FRAME_POINTER false
+#define HARD_FRAME_POINTER_IS_ARG_POINTER false


Sorry no, the problem is HARD_FRAME_POINTER_REGNUM that is defined as:
#define HARD_FRAME_POINTER_REGNUM\
  (TARGET_ARM\
   ? ARM_HARD_FRAME_POINTER_REGNUM\
   : THUMB_HARD_FRAME_POINTER_REGNUM)

where ARM_HARD_FRAME_POINTER_REGNUM is 11 and THUMB_HARD_FRAME_POINTER_REGNUM 
is 7
so Bernd's new warning triggers whenever HARD_FRAME_POINTER_REGNUM is used as a
boolean like it is in sel-sched.c and regrename.c



  #define FP_REGNUM  HARD_FRAME_POINTER_REGNUM

Re: [PATCH][RFC][regrename][sel-sched] Fix arm bootstrap

[Alexander Monakov]

On Thu, 22 Sep 2016, Kyrill Tkachov wrote:
> In the the interest of fixing arm bootstrap here are the two blocking issues
> and the changes proposed for them.
> I'm not familiar enough with regrename or sel-sched to make a call on whether
> these are right or not, I just want to keep the ball rolling so we can fix
> arm bootstrap.
> 
> These changes allowed arm bootstrap to complete.
> Are they the right way to go?
> If so, I'll do a full bootstrap and test run on aarch64 and x86_64.
> 
> Thanks,
> Kyrill
> 
> 2016-09-22  Kyrylo Tkachov  
> Bernd Edlinger  
> Bernd Schmidt  
> 
> * regrename.c (rename_chains): Avoid using HARD_FRAME_POINTER_REGNUM
> in a boolean context.
> * sel-sched.c (mark_unavailable_hard_regs): Likewise.

This doesn't look right to me. Note that you're patching uses of
H_F_P_IS_FRAME_POINTER (the ChangeLog is wrong).  As I understand, the issue is
that config/arm/arm.h defines that to plain 0, which causes the warning (ugh?).

Does the following restore bootstrap?

Thanks.
Alexander

diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 373dc85..1ae82c1 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -887,8 +887,8 @@ extern int arm_arch_crc;
? ARM_HARD_FRAME_POINTER_REGNUM \
: THUMB_HARD_FRAME_POINTER_REGNUM)

-#define HARD_FRAME_POINTER_IS_FRAME_POINTER 0
-#define HARD_FRAME_POINTER_IS_ARG_POINTER 0
+#define HARD_FRAME_POINTER_IS_FRAME_POINTER false
+#define HARD_FRAME_POINTER_IS_ARG_POINTER false

 #define FP_REGNUM  HARD_FRAME_POINTER_REGNUM

Re: [PATCH][RFC][regrename][sel-sched] Fix arm bootstrap

[Bernd Edlinger]

On 09/22/16 15:26, Kyrill Tkachov wrote:
> Hi all,
>
> In the the interest of fixing arm bootstrap here are the two blocking
> issues
> and the changes proposed for them.
> I'm not familiar enough with regrename or sel-sched to make a call on
> whether
> these are right or not, I just want to keep the ball rolling so we can fix
> arm bootstrap.
>
> These changes allowed arm bootstrap to complete.
> Are they the right way to go?
> If so, I'll do a full bootstrap and test run on aarch64 and x86_64.
>
> Thanks,
> Kyrill
>
> 2016-09-22  Kyrylo Tkachov  
>  Bernd Edlinger  
>  Bernd Schmidt  
>
>  * regrename.c (rename_chains): Avoid using HARD_FRAME_POINTER_REGNUM
>  in a boolean context.
>  * sel-sched.c (mark_unavailable_hard_regs): Likewise.

Thanks Kyill,


--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -1183,10 +1183,8 @@ mark_unavailable_hard_regs (def_t def, struct 
reg_rename *reg_rename_p,
   frame pointer, or we could not discover its class.  */
if (fixed_regs[regno]
|| global_regs[regno]
-  || (!HARD_FRAME_POINTER_IS_FRAME_POINTER && frame_pointer_needed
+  || (frame_pointer_needed
  && regno == HARD_FRAME_POINTER_REGNUM)
-  || (HARD_FRAME_POINTER_REGNUM && frame_pointer_needed
- && regno == FRAME_POINTER_REGNUM)
|| (reload_completed && cl == NO_REGS))
  {
SET_HARD_REG_SET (reg_rename_p->unavailable_hard_regs);

I think, that sel-sched.c would be on the safe side, if it is
staying away from both HARD_FRAME_POINTER and FRAME_POINTER, because
it may apparently also used before reload, where most of the
accesses use FRAME_POINTER.

   if (frame_pointer_needed)
 {
   add_to_hard_reg_set (_rename_p->unavailable_hard_regs,
Pmode, FRAME_POINTER_REGNUM);

   if (!HARD_FRAME_POINTER_IS_FRAME_POINTER)
 add_to_hard_reg_set (_rename_p->unavailable_hard_regs,
  Pmode, HARD_FRAME_POINTER_REGNUM);
 }

also here maybe remove the if (!...) ?



Bernd.

Re: [C++ PATCH] Aligned new option handling fixes (PR c++/77651)

[Christophe Lyon]

On 22 September 2016 at 15:01, Jason Merrill  wrote:
> On Thu, Sep 22, 2016 at 4:58 AM, Christophe Lyon
>  wrote:
>> This new test (aligned-new6.C) fails on arm/aarch64 bare-metal targets
>> (using newlib):
>> arm-none-eabi/./libstdc++-v3/src/.libs/libstdc++.a(new_opa.o): In
>> function `operator new(unsigned int, std::align_val_t)':
>> /gccsrc/libstdc++-v3/libsupc++/new_opa.cc:76: undefined reference to
>> `aligned_alloc'
>
> Hmm, does this fix that?

Yes. (I tested on arm only)

Thanks,

Christophe

PATCH to fix fallout from recent C++ bool changes

[Marek Polacek]

Jason reported that make check-c++1z reveals some fallout
because we now reject bool++ in C++1z:
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01460.html

I hope this patch fixes all of it.

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

2016-09-22  Marek Polacek  

* c-c++-common/gomp/atomic-12.c: Skip for C++1z.
* c-c++-common/gomp/atomic-13.c: Likewise.
* c-c++-common/gomp/atomic-14.c: Likewise.
* c-c++-common/pr60439.c: Remove invalid code.
* g++.dg/expr/bitfield4.C: Robustify for C++1z.
* g++.dg/expr/bitfield5.C: Likewise.
* g++.dg/expr/bitfield6.C: Likewise.
* g++.dg/expr/bool1.C: Likewise.
* g++.dg/expr/bool3.C: Likewise.
* g++.dg/expr/lval3.C: Likewise.
* g++.dg/expr/lval4.C: Likewise.
* g++.old-deja/g++.jason/bool5.C: Likewise.

diff --git gcc/testsuite/c-c++-common/gomp/atomic-12.c 
gcc/testsuite/c-c++-common/gomp/atomic-12.c
index e9ca650..07790d9 100644
--- gcc/testsuite/c-c++-common/gomp/atomic-12.c
+++ gcc/testsuite/c-c++-common/gomp/atomic-12.c
@@ -4,6 +4,7 @@
 /* atomicvar should never be referenced in between the barrier and
following #pragma omp atomic_load.  */
 /* { dg-final { scan-tree-dump-not "barrier\[^#\]*atomicvar" "gimple" } } */
+/* { dg-skip-if "invalid in C++1z" { c++1z } } */
 
 #ifdef __cplusplus
 bool atomicvar, c;
diff --git gcc/testsuite/c-c++-common/gomp/atomic-13.c 
gcc/testsuite/c-c++-common/gomp/atomic-13.c
index 7f4afcf..83c6560 100644
--- gcc/testsuite/c-c++-common/gomp/atomic-13.c
+++ gcc/testsuite/c-c++-common/gomp/atomic-13.c
@@ -4,5 +4,6 @@
 /* atomicvar should never be referenced in between the barrier and
following #pragma omp atomic_load.  */
 /* { dg-final { scan-tree-dump-not "barrier\[^#\]*atomicvar" "gimple" } } */
+/* { dg-skip-if "invalid in C++1z" { c++1z } } */
 
 #include "atomic-12.c"
diff --git gcc/testsuite/c-c++-common/gomp/atomic-14.c 
gcc/testsuite/c-c++-common/gomp/atomic-14.c
index 7e23453..f2dd9fc 100644
--- gcc/testsuite/c-c++-common/gomp/atomic-14.c
+++ gcc/testsuite/c-c++-common/gomp/atomic-14.c
@@ -1,6 +1,7 @@
 /* PR middle-end/45423 */
 /* { dg-do compile } */
 /* { dg-options "-fopenmp -Wno-deprecated" } */
+/* { dg-skip-if "invalid in C++1z" { c++1z } } */
 
 #ifdef __cplusplus
 bool *baz ();
diff --git gcc/testsuite/c-c++-common/pr60439.c 
gcc/testsuite/c-c++-common/pr60439.c
index 71b397a..dc12d1f 100644
--- gcc/testsuite/c-c++-common/pr60439.c
+++ gcc/testsuite/c-c++-common/pr60439.c
@@ -131,12 +131,6 @@ f6 (bool b)
 case 3:
   break;
 }
-  switch (b++) /* { dg-warning "switch condition has" } */
-  /* { dg-warning "is deprecated" "" { target c++ } 134 } */
-{
-case 3:
-  break;
-}
 }
 
 void
diff --git gcc/testsuite/g++.dg/expr/bitfield4.C 
gcc/testsuite/g++.dg/expr/bitfield4.C
index 7fae086..97a1fe9 100644
--- gcc/testsuite/g++.dg/expr/bitfield4.C
+++ gcc/testsuite/g++.dg/expr/bitfield4.C
@@ -14,6 +14,8 @@ template <>
 void f(bool) {} 
 
 int main() {
-  f(s.x++); // { dg-warning "deprecated" }
-  f(++s.x); // { dg-warning "deprecated" }
+  f(s.x++); // { dg-warning "deprecated" "" { target { ! c++1z } } }
+  // { dg-error "forbidden" "" { target c++1z } 17 }
+  f(++s.x); // { dg-warning "deprecated" "" { target { ! c++1z } } }
+  // { dg-error "forbidden" "" { target c++1z } 19 }
 }
diff --git gcc/testsuite/g++.dg/expr/bitfield5.C 
gcc/testsuite/g++.dg/expr/bitfield5.C
index 0a37f9f..bba35cb 100644
--- gcc/testsuite/g++.dg/expr/bitfield5.C
+++ gcc/testsuite/g++.dg/expr/bitfield5.C
@@ -8,10 +8,12 @@ struct S {
 S s;
 
 int main() {
-  s.x++; // { dg-warning "deprecated" }
+  s.x++; // { dg-warning "deprecated" "" { target { ! c++1z } } }
+  // { dg-error "forbidden" "" { target c++1z } 11 }
   if (s.x != 1)
 return 1;
-  ++s.x; // { dg-warning "deprecated" }
+  ++s.x; // { dg-warning "deprecated" "" { target { ! c++1z } } }
+  // { dg-error "forbidden" "" { target c++1z } 15 }
   if (s.x != 1)
 return 2;
 }
diff --git gcc/testsuite/g++.dg/expr/bitfield6.C 
gcc/testsuite/g++.dg/expr/bitfield6.C
index 8523866..202c246 100644
--- gcc/testsuite/g++.dg/expr/bitfield6.C
+++ gcc/testsuite/g++.dg/expr/bitfield6.C
@@ -7,5 +7,6 @@ struct S {
 S s;
 
 void f() {
-  ++s.x = false; // { dg-warning "deprecated" }
+  ++s.x = false; // { dg-warning "deprecated" "" { target { ! c++1z } } }
+  // { dg-error "forbidden" "" { target c++1z } 10 }
 }
diff --git gcc/testsuite/g++.dg/expr/bool1.C gcc/testsuite/g++.dg/expr/bool1.C
index 503e8b4..4ecc6ac 100644
--- gcc/testsuite/g++.dg/expr/bool1.C
+++ gcc/testsuite/g++.dg/expr/bool1.C
@@ -10,8 +10,10 @@ int main()
   my_bool b = false;
   int i;
 
-  b++; // { dg-warning "deprecated" }
-  b++; // { dg-warning "deprecated" }
+  b++; // { dg-warning "deprecated" "" { target { ! c++1z } } }
+  // { dg-error "forbidden" "" { target c++1z } 13 }
+  b++; // { dg-warning "deprecated" "" { target { ! c++1z } } }
+  // { dg-error "forbidden" "" { 

Re: Implement -Wimplicit-fallthrough (version 9)

[Marek Polacek]

On Wed, Sep 21, 2016 at 03:14:07PM -0400, Jason Merrill wrote:
> On 09/21/2016 02:59 PM, Marek Polacek wrote:
> > +  if (statement == NULL_TREE
> > +  && attr != NULL_TREE
> > +  && maybe_attribute_fallthrough_p (attr))
> > +{
> > +  /* Turn [[fallthrough]]; into FALLTHROUGH ();.  */
> > +  statement = build_call_expr_internal_loc (loc, IFN_FALLTHROUGH,
> > +   void_type_node, 0);
> > +  attr = NULL_TREE;
> > +}
> > +
> > +  /* Allow "[[fallthrough]];", but warn otherwise.  */
> > +  if (attr != NULL_TREE)
> > +warning_at (loc, OPT_Wattributes,
> > +   "attributes at the beginning of statement are ignored");
> 
> This is very close, thanks.  Let's give a more helpful warning about
> 
> [[fallthrough]] 0;
> __attribute__ ((fallthrough)) 0;
> 
> both here and in cp_parser_statement, something like "fallthrough attribute
> not followed by ';'"

Done.  And I made similar tweaks in the C FE.

Bootstrapped/regtested on x86_64-linux and ppc64-linux.

2016-09-22  Marek Polacek  
Jakub Jelinek  

PR c/7652
gcc/
* common.opt (Wimplicit-fallthrough): New option.
* doc/extend.texi: Document statement attributes and the fallthrough
attribute.
* doc/invoke.texi: Document -Wimplicit-fallthrough.
* gimple.h (gimple_call_internal_p): New function.
* gimplify.c (struct gimplify_ctx): Add in_switch_expr.
(struct label_entry): New struct.
(find_label_entry): New function.
(case_label_p): New function.
(collect_fallthrough_labels): New function.
(last_stmt_in_scope): New function.
(should_warn_for_implicit_fallthrough): New function.
(warn_implicit_fallthrough_r): New function.
(maybe_warn_implicit_fallthrough): New function.
(expand_FALLTHROUGH_r): New function.
(expand_FALLTHROUGH): New function.
(gimplify_switch_expr): Call maybe_warn_implicit_fallthrough and
expand_FALLTHROUGH for the innermost GIMPLE_SWITCH.
(gimplify_label_expr): New function.
(gimplify_case_label_expr): Set location.
(gimplify_expr): Call gimplify_label_expr.
* internal-fn.c (expand_FALLTHROUGH): New function.
* internal-fn.def (FALLTHROUGH): New internal function.
* langhooks.c (lang_GNU_OBJC): New function.
* langhooks.h (lang_GNU_OBJC): Declare.
* system.h (gcc_fallthrough): Define.
* tree-core.h: Add FALLTHROUGH_LABEL_P comment.
* tree.h (FALLTHROUGH_LABEL_P): Define.
gcc/c-family/
* c-common.c (c_common_attribute_table): Add fallthrough attribute.
(handle_fallthrough_attribute): New function.
(attribute_fallthrough_p): New function.
* c-common.h (attribute_fallthrough_p): Declare.
gcc/c/
* c-parser.c (struct c_token): Add flags field.
(c_lex_one_token): Pass it to c_lex_with_flags.
(c_parser_declaration_or_fndef): Turn __attribute__((fallthrough));
into IFN_FALLTHROUGH.
(c_parser_label): Set FALLTHROUGH_LABEL_P on labels.  Handle
attribute fallthrough after a case label or default label.
(c_parser_statement_after_labels): Handle RID_ATTRIBUTE.
gcc/cp/
* constexpr.c (cxx_eval_internal_function): Handle IFN_FALLTHROUGH.
(potential_constant_expression_1): Likewise.
* constraint.cc (function_concept_check_p): Check fn for null.
* parser.c (cp_parser_expression_statement): Handle attribute
fallthrough.
(cp_parser_statement): Likewise.
(cp_parser_label_for_labeled_statement): Set FALLTHROUGH_LABEL_P on
labels.
(cp_parser_std_attribute): Handle fallthrough attribute.
(cp_parser_check_std_attribute): Add %< %> quotes.
* pt.c (tsubst_copy_and_build): Handle internal functions.
(instantiation_dependent_scope_ref_p): Return if the expression is
null.
gcc/testsuite/
* c-c++-common/Wimplicit-fallthrough-1.c: New test.
* c-c++-common/Wimplicit-fallthrough-10.c: New test.
* c-c++-common/Wimplicit-fallthrough-11.c: New test.
* c-c++-common/Wimplicit-fallthrough-12.c: New test.
* c-c++-common/Wimplicit-fallthrough-13.c: New test.
* c-c++-common/Wimplicit-fallthrough-14.c: New test.
* c-c++-common/Wimplicit-fallthrough-15.c: New test.
* c-c++-common/Wimplicit-fallthrough-16.c: New test.
* c-c++-common/Wimplicit-fallthrough-17.c: New test.
* c-c++-common/Wimplicit-fallthrough-18.c: New test.
* c-c++-common/Wimplicit-fallthrough-19.c: New test.
* c-c++-common/Wimplicit-fallthrough-20.c: New test.
* c-c++-common/Wimplicit-fallthrough-21.c: New test.
* c-c++-common/Wimplicit-fallthrough-2.c: New test.
* c-c++-common/Wimplicit-fallthrough-3.c: New test.
* c-c++-common/Wimplicit-fallthrough-4.c: New 

Re: [PATCHv2][ARM] -mpure-code option for ARM

[Richard Earnshaw (lists)]

On 11/07/16 17:56, Andre Vieira (lists) wrote:
> On 07/07/16 13:30, mickael guene wrote:
>> Hi Andre,
>>
>>  Another feedback on your purecode patch.
>>  You have to disable casesi pattern since then it will
>> generate wrong code with -mpure-code option.
>>  Indeed it will generate an 'adr rx, .Lx' (aka
>> 'subs rx, PC, #offset') which will not work in our
>> case since 'Lx' label is put in an .rodata section.
>> So offset value is unknown and can be impossible
>> to encode correctly.
>>
>> Regards
>> Mickael
>>
>> On 06/30/2016 04:32 PM, Andre Vieira (lists) wrote:
>>> Hello,
>>>
>>> This patch adds the -mpure-code option for ARM. This option ensures
>>> functions are put into sections that contain only code and no data. To
>>> ensure this throughout compilation we give these sections the ARM
>>> processor-specific ELF section attribute "SHF_ARM_PURECODE". This option
>>> is only supported for non-pic code for armv7-m targets.
>>>
>>> This patch introduces a new target hook 'TARGET_ASM_ELF_FLAGS_NUMERIC'.
>>> This target hook enables a target to use the numeric value for elf
>>> section attributes rather than their alphabetical representation. If
>>> TARGET_ASM_ELF_FLAGS_NUMERIC returns TRUE, the existing
>>> 'default_elf_asm_named_section', will print the numeric value of the
>>> section attributes for the current section. This target hook has two
>>> parameters:
>>> unsigned int FLAGS, the input parameter that tells the function the
>>> current section's attributes;
>>> unsigned int *NUM, used to pass down the numerical representation of the
>>> section's attributes.
>>>
>>> The default implementation for TARGET_ASM_ELF_FLAGS_NUMERIC will return
>>> false, so existing behavior is not changed.
>>>
>>> Bootstrapped and tested for arm-none-linux-gnueabihf. Further tested for
>>> arm-none-eabi with a Cortex-M3 target.
>>>
>>>
>>> gcc/ChangeLog:
>>> 2016-06-30  Andre Vieira  
>>> Terry Guo  
>>>
>>> * target.def (elf_flags_numeric): New target hook.
>>> * targhooks.h (default_asm_elf_flags_numeric): New.
>>> * varasm.c (default_asm_elf_flags_numeric): New.
>>>   (default_elf_asm_named_section): Use new target hook.
>>> * config/arm/arm.opt (mpure-code): New.
>>> * config/arm/arm.h (SECTION_ARM_PURECODE): New.
>>> * config/arm/arm.c (arm_asm_init_sections): Add section
>>>   attribute to default text section if -mpure-code.
>>>   (arm_option_check_internal): Diagnose use of option with
>>>   non supported targets and/or options.
>>>   (arm_asm_elf_flags_numeric): New.
>>>   (arm_function_section): New.
>>>   (arm_elf_section_type_flags): New.
>>> * config/arm/elf.h (JUMP_TABLES_IN_TEXT_SECTION): Disable
>>>   for -mpure-code.
>>> * gcc/doc/texi (TARGET_ASM_ELF_FLAGS_NUMERIC): New.
>>> * gcc/doc/texi.in (TARGET_ASM_ELF_FLAGS_NUMERIC): Likewise.
>>>
>>>
>>>
>>> gcc/testsuite/ChangeLog:
>>> 2016-06-30  Andre Vieira  
>>> Terry Guo  
>>>
>>> * gcc.target/arm/pure-code/ffunction-sections.c: New.
>>> * gcc.target/arm/pure-code/no-literal-pool.c: New.
>>> * gcc.target/arm/pure-code/pure-code.exp: New.
>>>
>>
> Hi Sandra, Mickael,
> 
> Thank you for your comments. I changed the description of -mpure-code in
> invoke.texi to better reflect the error message you get wrt supported
> targets.
> 
> As for the target hook description, I hope the text is clearer now. Let
> me know if you think it needs further explanation.
> 
> I also fixed the double '%' in the text string for unnamed text sections
> and disabled the casesi pattern.
> 
> I duplicated the original casesi test
> 'gcc/testsuite/gcc.c-torture/compile/pr46934.c' for pure-code to make
> sure the casesi was disabled and other patterns were selected instead.
> 
> Reran regressions for pure-code.exp for Cortex-M3.
> 
> Cheers,
> Andre
> 
> 
> gcc/ChangeLog:
> 2016-07-11  Andre Vieira  
> Terry Guo  
> 
> * target.def (elf_flags_numeric): New target hook.
> * hooks.c (hook_uint_uintp_false): New generic hook.
> * varasm.c (default_elf_asm_named_section): Use new target hook.
> * config/arm/arm.opt (mpure-code): New.
> * config/arm/arm.h (SECTION_ARM_PURECODE): New.
> * config/arm/arm.c (arm_asm_init_sections): Add section
> attribute to default text section if -mpure-code.
> (arm_option_check_internal): Diagnose use of option with
> non supported targets and/or options.
> (arm_asm_elf_flags_numeric): New.
> (arm_function_section): New.
> (arm_elf_section_type_flags): New.
> * config/arm/elf.h (JUMP_TABLES_IN_TEXT_SECTION): Disable
> for -mpure-code.
> * config/arm/arm.md (casesi): Disable pattern for
>   

[PATCH, ARM 7/7] Enable ARMv8-M atomic and synchronization support for ARMv8-M Baseline

[Thomas Preudhomme]

Hi,

This patch is part of a patch series to add support for atomic operations on 
ARMv8-M Baseline targets in GCC. This specific patch enables atomic and 
synchronization support added in previous patches of the series and adds tests. 
Enabling is done at the end of the patch series to ensure that no ICE is seen 
when in the middle of the patch series (eg. while doing a bisect). Enabling is 
done by enabling the exclusive and atomic loads and stores needed to implement 
all synchronization and atomic operations.


ChangeLog entries are as follow:

*** gcc/ChangeLog ***

2016-07-05  Thomas Preud'homme  

* config/arm/arm.h (TARGET_HAVE_LDREX): Define for ARMv8-M Baseline.
(TARGET_HAVE_LDREXBH): Likewise.
(TARGET_HAVE_LDACQ): Likewise.


*** gcc/testsuite/ChangeLog ***

2016-07-05  Thomas Preud'homme  

* gcc.target/arm/atomic-comp-swap-release-acquire-3.c: New test.
* gcc.target/arm/atomic-op-acq_rel-3.c: Likewise.
* gcc.target/arm/atomic-op-acquire-3.c: Likewise.
* gcc.target/arm/atomic-op-char-3.c: Likewise.
* gcc.target/arm/atomic-op-consume-3.c: Likewise.
* gcc.target/arm/atomic-op-int-3.c: Likewise.
* gcc.target/arm/atomic-op-relaxed-3.c: Likewise.
* gcc.target/arm/atomic-op-release-3.c: Likewise.
* gcc.target/arm/atomic-op-seq_cst-3.c: Likewise.
* gcc.target/arm/atomic-op-short-3.c: Likewise.


Testing: No code generation difference for ARMv7-A, ARMv7VE and ARMv8-A on all 
atomic and synchronization testcases in the testsuite [2]. Patchset was also 
bootstrapped with --enable-itm --enable-gomp on ARMv8-A in ARM and Thumb mode at 
optimization level -O1 and above [1] without any regression in the testsuite and 
no code generation difference in libitm and libgomp.


Code generation for ARMv8-M Baseline has been manually examined and compared 
against ARMv8-A Thumb-2 for the following configuration without finding any issue:


gcc.dg/atomic-op-2.c at -Os
gcc.dg/atomic-compare-exchange-2.c at -Os
gcc.dg/atomic-compare-exchange-3.c at -O3


Is this ok for trunk?

Best regards,

Thomas

[1] CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET were set to "-O1 -g", "-O3 -g" and 
undefined ("-O2 -g")

[2] The exact list is:

gcc/testsuite/gcc.dg/atomic-compare-exchange-1.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-2.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-3.c
gcc/testsuite/gcc.dg/atomic-exchange-1.c
gcc/testsuite/gcc.dg/atomic-exchange-2.c
gcc/testsuite/gcc.dg/atomic-exchange-3.c
gcc/testsuite/gcc.dg/atomic-fence.c
gcc/testsuite/gcc.dg/atomic-flag.c
gcc/testsuite/gcc.dg/atomic-generic.c
gcc/testsuite/gcc.dg/atomic-generic-aux.c
gcc/testsuite/gcc.dg/atomic-invalid-2.c
gcc/testsuite/gcc.dg/atomic-load-1.c
gcc/testsuite/gcc.dg/atomic-load-2.c
gcc/testsuite/gcc.dg/atomic-load-3.c
gcc/testsuite/gcc.dg/atomic-lockfree.c
gcc/testsuite/gcc.dg/atomic-lockfree-aux.c
gcc/testsuite/gcc.dg/atomic-noinline.c
gcc/testsuite/gcc.dg/atomic-noinline-aux.c
gcc/testsuite/gcc.dg/atomic-op-1.c
gcc/testsuite/gcc.dg/atomic-op-2.c
gcc/testsuite/gcc.dg/atomic-op-3.c
gcc/testsuite/gcc.dg/atomic-op-6.c
gcc/testsuite/gcc.dg/atomic-store-1.c
gcc/testsuite/gcc.dg/atomic-store-2.c
gcc/testsuite/gcc.dg/atomic-store-3.c
gcc/testsuite/g++.dg/ext/atomic-1.C
gcc/testsuite/g++.dg/ext/atomic-2.C
gcc/testsuite/gcc.target/arm/atomic-comp-swap-release-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-acq_rel.c
gcc/testsuite/gcc.target/arm/atomic-op-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-char.c
gcc/testsuite/gcc.target/arm/atomic-op-consume.c
gcc/testsuite/gcc.target/arm/atomic-op-int.c
gcc/testsuite/gcc.target/arm/atomic-op-relaxed.c
gcc/testsuite/gcc.target/arm/atomic-op-release.c
gcc/testsuite/gcc.target/arm/atomic-op-seq_cst.c
gcc/testsuite/gcc.target/arm/atomic-op-short.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_1.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_2.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_3.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_4.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_5.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_6.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_7.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_8.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_9.c
gcc/testsuite/gcc.target/arm/sync-1.c
gcc/testsuite/gcc.target/arm/synchronize.c
gcc/testsuite/gcc.target/arm/armv8-sync-comp-swap.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-acquire.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-full.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-release.c
libstdc++-v3/testsuite/29_atomics/atomic/60658.cc
libstdc++-v3/testsuite/29_atomics/atomic/62259.cc
libstdc++-v3/testsuite/29_atomics/atomic/64658.cc
libstdc++-v3/testsuite/29_atomics/atomic/65147.cc
libstdc++-v3/testsuite/29_atomics/atomic/65913.cc
libstdc++-v3/testsuite/29_atomics/atomic/70766.cc
libstdc++-v3/testsuite/29_atomics/atomic/cons/49445.cc
libstdc++-v3/testsuite/29_atomics/atomic/cons/constexpr.cc

[PATCH, ARM/testsuite 6/7] Force soft float in ARMv6-M and ARMv8-M Baseline options

[Thomas Preudhomme]

Hi,

ARMv6-M and ARMv8-M Baseline only support soft float ABI. Therefore, the 
arm_arch_v8m_base add option should pass -mfloat-abi=soft, much like -mthumb is 
passed for architectures that only support Thumb instruction set. This patch 
adds -mfloat-abi=soft to both arm_arch_v6m and arm_arch_v8m_base add options. 
Patch is in attachment.


ChangeLog entry is as follows:

*** gcc/testsuite/ChangeLog ***

2016-07-15  Thomas Preud'homme  

* lib/target-supports.exp (add_options_for_arm_arch_v6m): Add
-mfloat-abi=soft option.
(add_options_for_arm_arch_v8m_base): Likewise.


Is this ok for trunk?

Best regards,

Thomas
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 0dabea0850124947a7fe333e0b94c4077434f278..a9629210fbf33262d9db26ec30bf1d44a95a15ba 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3540,24 +3540,25 @@ proc check_effective_target_arm_fp16_hw { } {
 # Usage: /* { dg-require-effective-target arm_arch_v5_ok } */
 #/* { dg-add-options arm_arch_v5 } */
 #	 /* { dg-require-effective-target arm_arch_v5_multilib } */
-foreach { armfunc armflag armdef } { v4 "-march=armv4 -marm" __ARM_ARCH_4__
- v4t "-march=armv4t" __ARM_ARCH_4T__
- v5 "-march=armv5 -marm" __ARM_ARCH_5__
- v5t "-march=armv5t" __ARM_ARCH_5T__
- v5te "-march=armv5te" __ARM_ARCH_5TE__
- v6 "-march=armv6" __ARM_ARCH_6__
- v6k "-march=armv6k" __ARM_ARCH_6K__
- v6t2 "-march=armv6t2" __ARM_ARCH_6T2__
- v6z "-march=armv6z" __ARM_ARCH_6Z__
- v6m "-march=armv6-m -mthumb" __ARM_ARCH_6M__
- v7a "-march=armv7-a" __ARM_ARCH_7A__
- v7r "-march=armv7-r" __ARM_ARCH_7R__
- v7m "-march=armv7-m -mthumb" __ARM_ARCH_7M__
- v7em "-march=armv7e-m -mthumb" __ARM_ARCH_7EM__
- v8a "-march=armv8-a" __ARM_ARCH_8A__
- v8_1a "-march=armv8.1a" __ARM_ARCH_8A__
- v8m_base "-march=armv8-m.base -mthumb" __ARM_ARCH_8M_BASE__
- v8m_main "-march=armv8-m.main -mthumb" __ARM_ARCH_8M_MAIN__ } {
+foreach { armfunc armflag armdef } {
+	v4 "-march=armv4 -marm" __ARM_ARCH_4__
+	v4t "-march=armv4t" __ARM_ARCH_4T__
+	v5 "-march=armv5 -marm" __ARM_ARCH_5__
+	v5t "-march=armv5t" __ARM_ARCH_5T__
+	v5te "-march=armv5te" __ARM_ARCH_5TE__
+	v6 "-march=armv6" __ARM_ARCH_6__
+	v6k "-march=armv6k" __ARM_ARCH_6K__
+	v6t2 "-march=armv6t2" __ARM_ARCH_6T2__
+	v6z "-march=armv6z" __ARM_ARCH_6Z__
+	v6m "-march=armv6-m -mthumb -mfloat-abi=soft" __ARM_ARCH_6M__
+	v7a "-march=armv7-a" __ARM_ARCH_7A__
+	v7r "-march=armv7-r" __ARM_ARCH_7R__
+	v7m "-march=armv7-m -mthumb" __ARM_ARCH_7M__
+	v7em "-march=armv7e-m -mthumb" __ARM_ARCH_7EM__
+	v8a "-march=armv8-a" __ARM_ARCH_8A__
+	v8_1a "-march=armv8.1a" __ARM_ARCH_8A__
+	v8m_base "-march=armv8-m.base -mthumb" __ARM_ARCH_8M_BASE__
+	v8m_main "-march=armv8-m.main -mthumb -mfloat-abi=soft" __ARM_ARCH_8M_MAIN__ } {
 eval [string map [list FUNC $armfunc FLAG $armflag DEF $armdef ] {
 	proc check_effective_target_arm_arch_FUNC_ok { } {
 	if { [ string match "*-marm*" "FLAG" ] &&

[PATCH, ARM 5/7] Adapt other atomic operations to ARMv8-M Baseline

[Thomas Preudhomme]

Hi,

This patch is part of a patch series to add support for atomic operations on 
ARMv8-M Baseline targets in GCC. This specific patch adds support for remaining 
atomic operations (exchange, addition, substraction, bitwise AND, OR, XOR and 
NAND to ARMv8-M Baseline, doubleword integers excepted. As with the previous 
patch in the patch series, this mostly consists adding Thumb-1 specific 
constraints to atomic_* patterns to match those in thumb1.md for the non atomic 
operation.


ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2016-09-02  Thomas Preud'homme  

* config/arm/arm.c (arm_split_atomic_op): Add function comment.  Add
logic to to decide whether to copy over old value to register for new
value.
* config/arm/sync.md: Add comments explaning why mode and code
attribute are not defined in iterators.md
(thumb1_atomic_op_str): New code attribute.
(thumb1_atomic_newop_str): Likewise.
(thumb1_atomic_fetch_op_str): Likewise.
(thumb1_atomic_fetch_newop_str): Likewise.
(thumb1_atomic_fetch_oldop_str): Likewise.
(atomic_exchange): Add new ARMv8-M Baseline only alternatives to
mirror the more restrictive constraints of the Thumb-1 insns after
split compared to Thumb-2 counterpart insns.
(atomic_): Likewise.  Add comment to keep constraints
in sync with non atomic version.
(atomic_nand): Likewise.
(atomic_fetch_): Likewise.
(atomic_fetch_nand): Likewise.
(atomic__fetch): Likewise.
(atomic_nand_fetch): Likewise.
* config/arm/thumb1.md (thumb1_addsi3): Add comment to keep contraint
in sync with atomic version.
(thumb1_subsi3_insn): Likewise.
(thumb1_andsi3_insn): Likewise.
(thumb1_iorsi3_insn): Likewise.
(thumb1_xorsi3_insn): Likewise.


Testing: No code generation difference for ARMv7-A, ARMv7VE and ARMv8-A on all 
atomic and synchronization testcases in the testsuite [2]. Patchset was also 
bootstrapped with --enable-itm --enable-gomp on ARMv8-A in ARM and Thumb mode at 
optimization level -O1 and above [1] without any regression in the testsuite and 
no code generation difference in libitm and libgomp.


Code generation for ARMv8-M Baseline has been manually examined and compared 
against ARMv8-A Thumb-2 for the following configuration without finding any issue:


gcc.dg/atomic-op-2.c at -Os
gcc.dg/atomic-compare-exchange-2.c at -Os
gcc.dg/atomic-compare-exchange-3.c at -O3


Is this ok for trunk?

Best regards,

Thomas

[1] CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET were set to "-O1 -g", "-O3 -g" and 
undefined ("-O2 -g")

[2] The exact list is:

gcc/testsuite/gcc.dg/atomic-compare-exchange-1.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-2.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-3.c
gcc/testsuite/gcc.dg/atomic-exchange-1.c
gcc/testsuite/gcc.dg/atomic-exchange-2.c
gcc/testsuite/gcc.dg/atomic-exchange-3.c
gcc/testsuite/gcc.dg/atomic-fence.c
gcc/testsuite/gcc.dg/atomic-flag.c
gcc/testsuite/gcc.dg/atomic-generic.c
gcc/testsuite/gcc.dg/atomic-generic-aux.c
gcc/testsuite/gcc.dg/atomic-invalid-2.c
gcc/testsuite/gcc.dg/atomic-load-1.c
gcc/testsuite/gcc.dg/atomic-load-2.c
gcc/testsuite/gcc.dg/atomic-load-3.c
gcc/testsuite/gcc.dg/atomic-lockfree.c
gcc/testsuite/gcc.dg/atomic-lockfree-aux.c
gcc/testsuite/gcc.dg/atomic-noinline.c
gcc/testsuite/gcc.dg/atomic-noinline-aux.c
gcc/testsuite/gcc.dg/atomic-op-1.c
gcc/testsuite/gcc.dg/atomic-op-2.c
gcc/testsuite/gcc.dg/atomic-op-3.c
gcc/testsuite/gcc.dg/atomic-op-6.c
gcc/testsuite/gcc.dg/atomic-store-1.c
gcc/testsuite/gcc.dg/atomic-store-2.c
gcc/testsuite/gcc.dg/atomic-store-3.c
gcc/testsuite/g++.dg/ext/atomic-1.C
gcc/testsuite/g++.dg/ext/atomic-2.C
gcc/testsuite/gcc.target/arm/atomic-comp-swap-release-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-acq_rel.c
gcc/testsuite/gcc.target/arm/atomic-op-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-char.c
gcc/testsuite/gcc.target/arm/atomic-op-consume.c
gcc/testsuite/gcc.target/arm/atomic-op-int.c
gcc/testsuite/gcc.target/arm/atomic-op-relaxed.c
gcc/testsuite/gcc.target/arm/atomic-op-release.c
gcc/testsuite/gcc.target/arm/atomic-op-seq_cst.c
gcc/testsuite/gcc.target/arm/atomic-op-short.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_1.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_2.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_3.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_4.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_5.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_6.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_7.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_8.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_9.c
gcc/testsuite/gcc.target/arm/sync-1.c
gcc/testsuite/gcc.target/arm/synchronize.c
gcc/testsuite/gcc.target/arm/armv8-sync-comp-swap.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-acquire.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-full.c

[PATCH, ARM 4/7] Adapt atomic compare and swap to ARMv8-M Baseline

[Thomas Preudhomme]

Hi,

This patch is part of a patch series to add support for atomic operations on 
ARMv8-M Baseline targets in GCC. This specific patch makes the necessary change 
for compare and swap to work for ARMv8-M Baseline, doubleword integers excepted. 
Namely, it adds Thumb-1 specific constraints to compare_and_swap. The 
constraints are chosen so that once the pattern is splitted, the individual 
instructions have their constraints respected. In particular, the constraints 
for the cbranchsi4_* pattern must be duplicated here, which explains the use of 
several alternatives.


Note: changes to enable other atomic operation are in the next patch of the 
series.

ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2016-07-05  Thomas Preud'homme  

* config/arm/sync.md (atomic_compare_and_swap_1): Add new ARMv8-M
Baseline only alternatives to (i) hold store atomic success value in a
return register rather than a scratch register, (ii) use a low register
for it and to (iii) ensure the cbranchsi insn generated by the split
respect the constraints of Thumb-1 cbranchsi4_insn and
cbranchsi4_scratch.
* config/arm/thumb1.md (cbranchsi4_insn): Add comment to indicate
constraints must match those in atomic_compare_and_swap.
(cbranchsi4_scratch): Likewise.


Testing: No code generation difference for ARMv7-A, ARMv7VE and ARMv8-A on all 
atomic and synchronization testcases in the testsuite [2]. Patchset was also 
bootstrapped with --enable-itm --enable-gomp on ARMv8-A in ARM and Thumb mode at 
optimization level -O1 and above [1] without any regression in the testsuite and 
no code generation difference in libitm and libgomp.


Code generation for ARMv8-M Baseline has been manually examined and compared 
against ARMv8-A Thumb-2 for the following configuration without finding any issue:


gcc.dg/atomic-op-2.c at -Os
gcc.dg/atomic-compare-exchange-2.c at -Os
gcc.dg/atomic-compare-exchange-3.c at -O3


Is this ok for trunk?

Best regards,

Thomas

[1] CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET were set to "-O1 -g", "-O3 -g" and 
undefined ("-O2 -g")

[2] The exact list is:

gcc/testsuite/gcc.dg/atomic-compare-exchange-1.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-2.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-3.c
gcc/testsuite/gcc.dg/atomic-exchange-1.c
gcc/testsuite/gcc.dg/atomic-exchange-2.c
gcc/testsuite/gcc.dg/atomic-exchange-3.c
gcc/testsuite/gcc.dg/atomic-fence.c
gcc/testsuite/gcc.dg/atomic-flag.c
gcc/testsuite/gcc.dg/atomic-generic.c
gcc/testsuite/gcc.dg/atomic-generic-aux.c
gcc/testsuite/gcc.dg/atomic-invalid-2.c
gcc/testsuite/gcc.dg/atomic-load-1.c
gcc/testsuite/gcc.dg/atomic-load-2.c
gcc/testsuite/gcc.dg/atomic-load-3.c
gcc/testsuite/gcc.dg/atomic-lockfree.c
gcc/testsuite/gcc.dg/atomic-lockfree-aux.c
gcc/testsuite/gcc.dg/atomic-noinline.c
gcc/testsuite/gcc.dg/atomic-noinline-aux.c
gcc/testsuite/gcc.dg/atomic-op-1.c
gcc/testsuite/gcc.dg/atomic-op-2.c
gcc/testsuite/gcc.dg/atomic-op-3.c
gcc/testsuite/gcc.dg/atomic-op-6.c
gcc/testsuite/gcc.dg/atomic-store-1.c
gcc/testsuite/gcc.dg/atomic-store-2.c
gcc/testsuite/gcc.dg/atomic-store-3.c
gcc/testsuite/g++.dg/ext/atomic-1.C
gcc/testsuite/g++.dg/ext/atomic-2.C
gcc/testsuite/gcc.target/arm/atomic-comp-swap-release-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-acq_rel.c
gcc/testsuite/gcc.target/arm/atomic-op-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-char.c
gcc/testsuite/gcc.target/arm/atomic-op-consume.c
gcc/testsuite/gcc.target/arm/atomic-op-int.c
gcc/testsuite/gcc.target/arm/atomic-op-relaxed.c
gcc/testsuite/gcc.target/arm/atomic-op-release.c
gcc/testsuite/gcc.target/arm/atomic-op-seq_cst.c
gcc/testsuite/gcc.target/arm/atomic-op-short.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_1.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_2.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_3.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_4.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_5.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_6.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_7.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_8.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_9.c
gcc/testsuite/gcc.target/arm/sync-1.c
gcc/testsuite/gcc.target/arm/synchronize.c
gcc/testsuite/gcc.target/arm/armv8-sync-comp-swap.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-acquire.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-full.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-release.c
libstdc++-v3/testsuite/29_atomics/atomic/60658.cc
libstdc++-v3/testsuite/29_atomics/atomic/62259.cc
libstdc++-v3/testsuite/29_atomics/atomic/64658.cc
libstdc++-v3/testsuite/29_atomics/atomic/65147.cc
libstdc++-v3/testsuite/29_atomics/atomic/65913.cc
libstdc++-v3/testsuite/29_atomics/atomic/70766.cc
libstdc++-v3/testsuite/29_atomics/atomic/cons/49445.cc
libstdc++-v3/testsuite/29_atomics/atomic/cons/constexpr.cc
libstdc++-v3/testsuite/29_atomics/atomic/cons/copy_list.cc
libstdc++-v3/testsuite/29_atomics/atomic/cons/default.cc

[PATCH, ARM 3/7] Refactor atomic compare_and_swap to make it fit for ARMv8-M Baseline

[Thomas Preudhomme]

Hi,

This patch is part of a patch series to add support for atomic operations on 
ARMv8-M Baseline targets in GCC. This specific patch refactors the expander and 
splitter for atomics to make the logic work with ARMv8-M Baseline which has 
limitation of Thumb-1 in terms of CC flag setting and different conditional 
compare insn patterns.


ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2016-09-02  Thomas Preud'homme  

* config/arm/arm.c (arm_expand_compare_and_swap): Add new bdst local
variable.  Add the new parameter to the insn generator.  Set that
parameter to be CC flag for 32-bit targets, bval otherwise.  Set the
return value from the negation of that parameter for Thumb-1, keeping
the logic unchanged otherwise except for using bdst as the destination
register of the compare_and_swap insn.
(arm_split_compare_and_swap): Add explanation about how is the value
returned to the function comment.  Rename scratch variable to
neg_bval.  Adapt initialization of variables holding operands to the
new operand numbers.  Use return register to hold result of store
exclusive for Thumb-1, scratch register otherwise.  Construct the
appropriate cbranch for Thumb-1 targets, keeping the logic unchanged
for 32-bit targets.  Guard Z flag setting to restrict to 32bit targets.
Use gen_cbranchsi4 rather than hand-written conditional branch to loop
for strongly ordered compare_and_swap.
* config/arm/predicates.md (cc_register_operand): New predicate.
* config/arm/sync.md (atomic_compare_and_swap_1): Use a
match_operand with the new predicate to accept either the CC flag or a
destination register for the boolean return value, restricting it to
CC flag only via constraint.  Adapt operand numbers accordingly.


Testing: No code generation difference for ARMv7-A, ARMv7VE and ARMv8-A on all 
atomic and synchronization testcases in the testsuite [2]. Patchset was also 
bootstrapped with --enable-itm --enable-gomp on ARMv8-A in ARM and Thumb mode at 
optimization level -O1 and above [1] without any regression in the testsuite and 
no code generation difference in libitm and libgomp.


Code generation for ARMv8-M Baseline has been manually examined and compared 
against ARMv8-A Thumb-2 for the following configuration without finding any issue:


gcc.dg/atomic-op-2.c at -Os
gcc.dg/atomic-compare-exchange-2.c at -Os
gcc.dg/atomic-compare-exchange-3.c at -O3


Is this ok for trunk?

Best regards,

Thomas

[1] CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET were set to "-O1 -g", "-O3 -g" and 
undefined ("-O2 -g")

[2] The exact list is:

gcc/testsuite/gcc.dg/atomic-compare-exchange-1.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-2.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-3.c
gcc/testsuite/gcc.dg/atomic-exchange-1.c
gcc/testsuite/gcc.dg/atomic-exchange-2.c
gcc/testsuite/gcc.dg/atomic-exchange-3.c
gcc/testsuite/gcc.dg/atomic-fence.c
gcc/testsuite/gcc.dg/atomic-flag.c
gcc/testsuite/gcc.dg/atomic-generic.c
gcc/testsuite/gcc.dg/atomic-generic-aux.c
gcc/testsuite/gcc.dg/atomic-invalid-2.c
gcc/testsuite/gcc.dg/atomic-load-1.c
gcc/testsuite/gcc.dg/atomic-load-2.c
gcc/testsuite/gcc.dg/atomic-load-3.c
gcc/testsuite/gcc.dg/atomic-lockfree.c
gcc/testsuite/gcc.dg/atomic-lockfree-aux.c
gcc/testsuite/gcc.dg/atomic-noinline.c
gcc/testsuite/gcc.dg/atomic-noinline-aux.c
gcc/testsuite/gcc.dg/atomic-op-1.c
gcc/testsuite/gcc.dg/atomic-op-2.c
gcc/testsuite/gcc.dg/atomic-op-3.c
gcc/testsuite/gcc.dg/atomic-op-6.c
gcc/testsuite/gcc.dg/atomic-store-1.c
gcc/testsuite/gcc.dg/atomic-store-2.c
gcc/testsuite/gcc.dg/atomic-store-3.c
gcc/testsuite/g++.dg/ext/atomic-1.C
gcc/testsuite/g++.dg/ext/atomic-2.C
gcc/testsuite/gcc.target/arm/atomic-comp-swap-release-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-acq_rel.c
gcc/testsuite/gcc.target/arm/atomic-op-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-char.c
gcc/testsuite/gcc.target/arm/atomic-op-consume.c
gcc/testsuite/gcc.target/arm/atomic-op-int.c
gcc/testsuite/gcc.target/arm/atomic-op-relaxed.c
gcc/testsuite/gcc.target/arm/atomic-op-release.c
gcc/testsuite/gcc.target/arm/atomic-op-seq_cst.c
gcc/testsuite/gcc.target/arm/atomic-op-short.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_1.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_2.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_3.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_4.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_5.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_6.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_7.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_8.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_9.c
gcc/testsuite/gcc.target/arm/sync-1.c
gcc/testsuite/gcc.target/arm/synchronize.c
gcc/testsuite/gcc.target/arm/armv8-sync-comp-swap.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-acquire.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-full.c

Re: [PATCH] Increase lto-min-partition

[Markus Trippelsdorf]

On 2016.09.22 at 15:36 +0200, Richard Biener wrote:
> On Thu, Sep 22, 2016 at 3:13 PM, Wilco Dijkstra  
> wrote:
> > Increase the lto-min-partition size to 5 to reduce the number of 
> > partitions.
> > See eg. https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00235.html for a 
> > concise
> > explanation why 1 is too small for modern CPU/memory size.  
> > Additionally,
> > larger values increase optimization opportunities and reduce bad decisions 
> > in the
> > layout of global variables across partitions (anchors do not work well with 
> > LTO).
> > Looking at SPEC2000, 8 more benchmarks now use a single LTO partition which
> > is the most optimal.  Build time with LTO increases only slightly, eg. 
> > SPEC2006
> > now takes 2% more time on an 8-core ARM server.
> 
> Ok.  Marcus, how many partitions do we get with libreoffice/firefox currently
> (I suppose they all hit lto-max-partition now?)

Yes. Even tramp3d currently gets 30 partitions. With this patch it gets
reduced to 20.
And I guess bigger projects like Firefox are unchanged at 32.

-- 
Markus

[PATCH, ARM 2/7] Adapt atomic and exclusive load and store to ARMv8-M Baseline

[Thomas Preudhomme]

Hi,

This patch is part of a patch series to add support for atomic operations on 
ARMv8-M Baseline targets in GCC. This specific patch adapts atomic and exclusive 
load and store patterns to the constraints of ARMv8-M Baseline. It consists of 
two sets of changes:


- adding non predicated output templates because ARMv8-M Baseline does not have 
IT instruction

- use low registers for ldr/str

Together these changes require to create 2 new alternatives for atomic_load and 
atomic_store: (i) one for relaxed, consume and release memory model (the new Pf 
constraint) where ldr/str are used and thus low registers must be used and (ii) 
another one for the other memory model where lda/stl are used. These are 
separate from the constraint for 32bit targets whose output templates expect 
predication.


ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2016-07-05  Thomas Preud'homme  

* config/arm/constraints.md (Q constraint): Document its use for
Thumb-1.
(Pf constraint): New constraint for relaxed, consume or relaxed memory
models.
* config/arm/sync.md (atomic_load): Add new ARMv8-M Baseline only
alternatives to allow any register when memory model matches Pf and
thus lda is used, but only low registers otherwise.  Use unpredicated
output template for Thumb-1 targets.
(atomic_store): Likewise for stl.
(arm_load_exclusive): Add new ARMv8-M Baseline only alternative
whose output template does not have predication.
(arm_load_acquire_exclusive): Likewise.
(arm_load_exclusivesi): Likewise.
(arm_load_acquire_exclusivesi): Likewise.
(arm_store_release_exclusive): Likewise.
(arm_store_exclusive): Use unpredicated output template for
Thumb-1 targets.


Testing: No code generation difference for ARMv7-A, ARMv7VE and ARMv8-A on all 
atomic and synchronization testcases in the testsuite [2]. Patchset was also 
bootstrapped with --enable-itm --enable-gomp on ARMv8-A in ARM and Thumb mode at 
optimization level -O1 and above [1] without any regression in the testsuite and 
no code generation difference in libitm and libgomp.


Code generation for ARMv8-M Baseline has been manually examined and compared 
against ARMv8-A Thumb-2 for the following configuration without finding any issue:


gcc.dg/atomic-op-2.c at -Os
gcc.dg/atomic-compare-exchange-2.c at -Os
gcc.dg/atomic-compare-exchange-3.c at -O3


Is this ok for trunk?

Best regards,

Thomas

[1] CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET were set to "-O1 -g", "-O3 -g" and 
undefined ("-O2 -g")

[2] The exact list is:

gcc/testsuite/gcc.dg/atomic-compare-exchange-1.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-2.c
gcc/testsuite/gcc.dg/atomic-compare-exchange-3.c
gcc/testsuite/gcc.dg/atomic-exchange-1.c
gcc/testsuite/gcc.dg/atomic-exchange-2.c
gcc/testsuite/gcc.dg/atomic-exchange-3.c
gcc/testsuite/gcc.dg/atomic-fence.c
gcc/testsuite/gcc.dg/atomic-flag.c
gcc/testsuite/gcc.dg/atomic-generic.c
gcc/testsuite/gcc.dg/atomic-generic-aux.c
gcc/testsuite/gcc.dg/atomic-invalid-2.c
gcc/testsuite/gcc.dg/atomic-load-1.c
gcc/testsuite/gcc.dg/atomic-load-2.c
gcc/testsuite/gcc.dg/atomic-load-3.c
gcc/testsuite/gcc.dg/atomic-lockfree.c
gcc/testsuite/gcc.dg/atomic-lockfree-aux.c
gcc/testsuite/gcc.dg/atomic-noinline.c
gcc/testsuite/gcc.dg/atomic-noinline-aux.c
gcc/testsuite/gcc.dg/atomic-op-1.c
gcc/testsuite/gcc.dg/atomic-op-2.c
gcc/testsuite/gcc.dg/atomic-op-3.c
gcc/testsuite/gcc.dg/atomic-op-6.c
gcc/testsuite/gcc.dg/atomic-store-1.c
gcc/testsuite/gcc.dg/atomic-store-2.c
gcc/testsuite/gcc.dg/atomic-store-3.c
gcc/testsuite/g++.dg/ext/atomic-1.C
gcc/testsuite/g++.dg/ext/atomic-2.C
gcc/testsuite/gcc.target/arm/atomic-comp-swap-release-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-acq_rel.c
gcc/testsuite/gcc.target/arm/atomic-op-acquire.c
gcc/testsuite/gcc.target/arm/atomic-op-char.c
gcc/testsuite/gcc.target/arm/atomic-op-consume.c
gcc/testsuite/gcc.target/arm/atomic-op-int.c
gcc/testsuite/gcc.target/arm/atomic-op-relaxed.c
gcc/testsuite/gcc.target/arm/atomic-op-release.c
gcc/testsuite/gcc.target/arm/atomic-op-seq_cst.c
gcc/testsuite/gcc.target/arm/atomic-op-short.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_1.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_2.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_3.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_4.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_5.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_6.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_7.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_8.c
gcc/testsuite/gcc.target/arm/atomic_loaddi_9.c
gcc/testsuite/gcc.target/arm/sync-1.c
gcc/testsuite/gcc.target/arm/synchronize.c
gcc/testsuite/gcc.target/arm/armv8-sync-comp-swap.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-acquire.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-full.c
gcc/testsuite/gcc.target/arm/armv8-sync-op-release.c
libstdc++-v3/testsuite/29_atomics/atomic/60658.cc

[PATCH, 1/7] Move memory model declarations in memmodel.h

[Thomas Preudhomme]

Hi,

This patch is part of a patch series to add support for ARMv8-M[1] to GCC. This 
specific patch moves memory model declarations in memmodel.h.


Currently, is_mm_* memory model related functions are declared in tree.h which 
prevents using them in constraints machine description files. This patch move 
this functions into a new memmodel.h header to allow such a thing and update all 
users of this function to include the new header.


ChangeLog entries are as follows:

*** gcc/ChangeLog ***

2016-04-20  Thomas Preud'homme  

* tree.h (memmodel_from_int, memmodel_base, is_mm_relaxed,
is_mm_consume, is_mm_acquire, is_mm_release, is_mm_acq_rel,
is_mm_seq_cst, is_mm_sync): Move to ...
* memmodel.h: This.  New file.
* builtins.c: Include memmodel.h.
* optabs.c: Likewise.
* tsan.c: Likewise.
* config/aarch64/aarch64.c: Likewise.
* config/alpha/alpha.c: Likewise.
* config/arm/arm.c: Likewise.
* config/i386/i386.c: Likewise.
* config/ia64/ia64.c: Likewise.
* config/mips/mips.c: Likewise.
* config/rs6000/rs6000.c: Likewise.
* config/sparc/sparc.c: Likewise.
* genconditions.c: Include memmodel.h in generated file.
* genemit.c: Likewise.
* genoutput.c: Likewise.
* genpeep.c: Likewise.
* genpreds.c: Likewise.
* genrecog.c: Likewise.


*** gcc/c-family/ChangeLog ***

2016-04-20  Thomas Preud'homme  

* c-common.c: Include memmodel.h.


Is this ok for trunk?

Best regards,

Thomas
diff --git a/gcc/builtins.c b/gcc/builtins.c
index b981bcd281af29cdbb1d6bcc1e9f93b769708897..3d9c8aa38b6aea03b2f4ddc59222f19ba078 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -28,6 +28,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "target.h"
 #include "rtl.h"
 #include "tree.h"
+#include "memmodel.h"
 #include "gimple.h"
 #include "predict.h"
 #include "tm_p.h"
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 399ba975184e934bc061113286787840a7531291..a74301fa6de1897007635574ab36058572d953b3 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -25,6 +25,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "target.h"
 #include "function.h"
 #include "tree.h"
+#include "memmodel.h"
 #include "c-common.h"
 #include "gimple-expr.h"
 #include "tm_p.h"
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 5efad462f11f2954a65386b3b6b8d51bd61c51c1..913e026f54cc8464ba9cee0dbecd2a711458dc41 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -26,6 +26,7 @@
 #include "target.h"
 #include "rtl.h"
 #include "tree.h"
+#include "memmodel.h"
 #include "gimple.h"
 #include "cfghooks.h"
 #include "cfgloop.h"
diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
index 702cd277ede8860c53d3ce4c03a8c6d81f7b5c5b..488902741504bc2f93424da6e80e83270d24edd2 100644
--- a/gcc/config/alpha/alpha.c
+++ b/gcc/config/alpha/alpha.c
@@ -26,6 +26,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "target.h"
 #include "rtl.h"
 #include "tree.h"
+#include "memmodel.h"
 #include "gimple.h"
 #include "df.h"
 #include "tm_p.h"
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 946f308ca84e232af8af6eca4813464914cbd59c..97b3ef1673a98f406aed023f5715c35ebf69b07e 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -27,6 +27,7 @@
 #include "target.h"
 #include "rtl.h"
 #include "tree.h"
+#include "memmodel.h"
 #include "cfghooks.h"
 #include "df.h"
 #include "tm_p.h"
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 3ac115c64f717f928eeb8085fea941383121df85..00c5a3db569e0d1758a8e96b3ff1b9f4446b6ad7 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -23,6 +23,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "backend.h"
 #include "rtl.h"
 #include "tree.h"
+#include "memmodel.h"
 #include "gimple.h"
 #include "cfghooks.h"
 #include "cfgloop.h"
diff --git a/gcc/config/ia64/ia64.c b/gcc/config/ia64/ia64.c
index ebd2c86b8d8f917248453070105b1fb5178bc7a3..1f3628b254cac4ef9ea0e72024fe309c4d0eb0da 100644
--- a/gcc/config/ia64/ia64.c
+++ b/gcc/config/ia64/ia64.c
@@ -26,6 +26,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "target.h"
 #include "rtl.h"
 #include "tree.h"
+#include "memmodel.h"
 #include "cfghooks.h"
 #include "df.h"
 #include "tm_p.h"
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 88f4038224a9cdc904cbf15b2a5833b6525702ab..3586a1001e7a920571b1be6d41f9a8e1345f33cc 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -28,6 +28,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "target.h"
 #include "rtl.h"
 #include "tree.h"
+#include "memmodel.h"
 #include "gimple.h"
 #include "cfghooks.h"
 #include "df.h"
diff --git a/gcc/config/rs6000/rs6000.c 

Re: [PATCH] Increase lto-min-partition

[Richard Biener]

On Thu, Sep 22, 2016 at 3:13 PM, Wilco Dijkstra  wrote:
> Increase the lto-min-partition size to 5 to reduce the number of 
> partitions.
> See eg. https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00235.html for a concise
> explanation why 1 is too small for modern CPU/memory size.  Additionally,
> larger values increase optimization opportunities and reduce bad decisions in 
> the
> layout of global variables across partitions (anchors do not work well with 
> LTO).
> Looking at SPEC2000, 8 more benchmarks now use a single LTO partition which
> is the most optimal.  Build time with LTO increases only slightly, eg. 
> SPEC2006
> now takes 2% more time on an 8-core ARM server.

Ok.  Marcus, how many partitions do we get with libreoffice/firefox currently
(I suppose they all hit lto-max-partition now?)

Thanks,
Richard.

> ChangeLog:
> 2016-09-22  Wilco Dijkstra  
>
> gcc/
> * params.def (MIN_PARTITION_SIZE): Increase to 5.
>
> --
> diff --git a/gcc/params.def b/gcc/params.def
> index 
> 79b7dd4cca9ec1bb67a64725fb1a596b6e937419..da8fd1825e15f2aa800b1c8b680985776c1080ed
>  100644
> --- a/gcc/params.def
> +++ b/gcc/params.def
> @@ -1045,7 +1045,7 @@ DEFPARAM (PARAM_LTO_PARTITIONS,
>  DEFPARAM (MIN_PARTITION_SIZE,
>   "lto-min-partition",
>   "Minimal size of a partition for LTO (in estimated instructions).",
> - 1, 0, 0)
> + 5, 0, 0)
>
>  DEFPARAM (MAX_PARTITION_SIZE,
>   "lto-max-partition",
>

Re: [PATCH v2] [RTEMS] Always use atomic builtins for libstdc++

[Sebastian Huber]

On 22/09/16 15:25, Joel Sherrill wrote:

/The target pattern in the commit message doesn't look right.
It should be *-*-rtems* I think.


It should be ok since host_os is used:

# It uses the following shell variables as set by config.guess:
#   hostThe configuration host (full CPU-vendor-OS triplet)
#   host_cpuThe configuration host CPU
#   host_os The configuration host OS



Do all BSPs for m68k build with C++ enabled?


Yes, but I face currently some other problems with GCC 7:

https://gcc.gnu.org/ml/gcc/2016-09/msg00114.html

There is also a NULL pointer access in wctob() with the latest Newlib.



What code is used for atomic operations on say a 68000 or
68020?


They use the libatomic if the atomic operations are not supported by 
hardware. libatomic uses _Libatomic_Protect_start() and 
_Libatomic_Protect_end() on RTEMS.




Thanks.

--joel

On Thu, Sep 22, 2016 at 3:47 AM, Sebastian Huber 
> wrote:


v2: Fix shell script part since shell grouping is expressed by { }.

libstdc++-v3/
* config/cpu/m68k/atomicity.h: Adjust comment.
* acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Honor
explicit atomicity_dir setup via configure.host.
* configure.host (rtems-*): Set atomicity_dir.
* configure: Regenerate.
---
 libstdc++-v3/acinclude.m4|  5 +++--
 libstdc++-v3/config/cpu/m68k/atomicity.h |  3 +++
 libstdc++-v3/configure   | 11 ++-
 libstdc++-v3/configure.host  |  4 
 4 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 6d897be..d7db435 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -3490,9 +3490,10 @@ EOF
   AC_LANG_RESTORE

   # Set atomicity_dir to builtins if all but the long long test
above passes.
-  if test "$glibcxx_cv_atomic_bool" = yes \
+  if { test "$glibcxx_cv_atomic_bool" = yes \
  && test "$glibcxx_cv_atomic_short" = yes \
- && test "$glibcxx_cv_atomic_int" = yes; then
+ && test "$glibcxx_cv_atomic_int" = yes } \
+ || test "$atomicity_dir" = "cpu/generic/atomicity_builtins";
then
 AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS, 1,
 [Define if the compiler supports C++11 atomics.])
 atomicity_dir=cpu/generic/atomicity_builtins
diff --git a/libstdc++-v3/config/cpu/m68k/atomicity.h
b/libstdc++-v3/config/cpu/m68k/atomicity.h
index f421330..a9ddc6b 100644
--- a/libstdc++-v3/config/cpu/m68k/atomicity.h
+++ b/libstdc++-v3/config/cpu/m68k/atomicity.h
@@ -48,6 +48,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }

 #elif defined(__rtems__)
+  // This code is only provided for reference.  RTEMS uses now
the atomic
+  // builtins and libatomic.  See configure.host.
+  //
   // TAS/JBNE is unsafe on systems with strict priority-based
scheduling.
   // Disable interrupts, which we can do only from supervisor mode.
   _Atomic_word
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 6332c4d..d09a7e0 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -15539,9 +15539,10 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu


   # Set atomicity_dir to builtins if all but the long long test
above passes.
-  if test "$glibcxx_cv_atomic_bool" = yes \
+  if { test "$glibcxx_cv_atomic_bool" = yes \
  && test "$glibcxx_cv_atomic_short" = yes \
- && test "$glibcxx_cv_atomic_int" = yes; then
+ && test "$glibcxx_cv_atomic_int" = yes } \
+ || test "$atomicity_dir" = "cpu/generic/atomicity_builtins";
then

 $as_echo "#define _GLIBCXX_ATOMIC_BUILTINS 1" >>confdefs.h

@@ -15573,7 +15574,7 @@ $as_echo "$as_me: WARNING: Performance of
certain classes will degrade as a resu
   # unnecessary for this test.

 cat > conftest.$ac_ext << EOF
-#line 15576 "configure"
+#line 15577 "configure"
 int main()
 {
   _Decimal32 d1;
@@ -15615,7 +15616,7 @@ ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
   # unnecessary for this test.

 cat > conftest.$ac_ext << EOF
-#line 15618 "configure"
+#line 15619 "configure"
 template
   struct same
   { typedef T2 type; };
@@ -15649,7 +15650,7 @@ $as_echo "$enable_int128" >&6; }
 rm -f conftest*

 cat > conftest.$ac_ext << EOF
-#line 15652 "configure"
+#line 15653 "configure"
 template
   struct same
   { typedef T2 type; };
diff --git a/libstdc++-v3/configure.host b/libstdc++-v3/configure.host
index c0cc3ee..eb56ab1 100644
--- a/libstdc++-v3/configure.host
+++ b/libstdc++-v3/configure.host
@@ -296,6 +296,10 @@ case "${host_os}" in
 os_include_dir="os/qnx/qnx6.1"

[PATCH][RFC][regrename][sel-sched] Fix arm bootstrap

[Kyrill Tkachov]

Hi all,

In the the interest of fixing arm bootstrap here are the two blocking issues
and the changes proposed for them.
I'm not familiar enough with regrename or sel-sched to make a call on whether
these are right or not, I just want to keep the ball rolling so we can fix
arm bootstrap.

These changes allowed arm bootstrap to complete.
Are they the right way to go?
If so, I'll do a full bootstrap and test run on aarch64 and x86_64.

Thanks,
Kyrill

2016-09-22  Kyrylo Tkachov  
Bernd Edlinger  
Bernd Schmidt  

* regrename.c (rename_chains): Avoid using HARD_FRAME_POINTER_REGNUM
in a boolean context.
* sel-sched.c (mark_unavailable_hard_regs): Likewise.
diff --git a/gcc/regrename.c b/gcc/regrename.c
index 54c7768efa226139c340868e42b784fb011a19b9..a7339db441012e338de5697015f04c1fdb970164 100644
--- a/gcc/regrename.c
+++ b/gcc/regrename.c
@@ -464,8 +464,7 @@ rename_chains (void)
   if (frame_pointer_needed)
 {
   add_to_hard_reg_set (, Pmode, FRAME_POINTER_REGNUM);
-  if (!HARD_FRAME_POINTER_IS_FRAME_POINTER)
-	add_to_hard_reg_set (, Pmode, HARD_FRAME_POINTER_REGNUM);
+  add_to_hard_reg_set (, Pmode, HARD_FRAME_POINTER_REGNUM);
 }
 
   FOR_EACH_VEC_ELT (id_to_chain, i, this_head)
@@ -479,10 +478,9 @@ rename_chains (void)
 	continue;
 
   if (fixed_regs[reg] || global_regs[reg]
-	  || (!HARD_FRAME_POINTER_IS_FRAME_POINTER && frame_pointer_needed
-	  && reg == HARD_FRAME_POINTER_REGNUM)
-	  || (HARD_FRAME_POINTER_REGNUM && frame_pointer_needed
-	  && reg == FRAME_POINTER_REGNUM))
+	  || (frame_pointer_needed
+	  && (reg == HARD_FRAME_POINTER_REGNUM
+		  || reg == FRAME_POINTER_REGNUM)))
 	continue;
 
   COPY_HARD_REG_SET (this_unavailable, unavailable);
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 25a100ee34f6ceaceda2814ae281cadf8b29e688..4a2679c6701c256c5559fa1e9c156bdaad1c2891 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -1183,10 +1183,8 @@ mark_unavailable_hard_regs (def_t def, struct reg_rename *reg_rename_p,
  frame pointer, or we could not discover its class.  */
   if (fixed_regs[regno]
   || global_regs[regno]
-  || (!HARD_FRAME_POINTER_IS_FRAME_POINTER && frame_pointer_needed
+  || (frame_pointer_needed
 	  && regno == HARD_FRAME_POINTER_REGNUM)
-  || (HARD_FRAME_POINTER_REGNUM && frame_pointer_needed
-	  && regno == FRAME_POINTER_REGNUM)
   || (reload_completed && cl == NO_REGS))
 {
   SET_HARD_REG_SET (reg_rename_p->unavailable_hard_regs);

Re: [v3 PATCH] PR libstdc++/77288 and the newest proposed resolution for LWG 2756

[Jonathan Wakely]

On 22/09/16 12:15 +0100, Jonathan Wakely wrote:

On 22/09/16 11:16 +0100, Jonathan Wakely wrote:

(Somebody should fix PR58938 so exception_ptr is portable).


Christophe, would you be able to test this patch?

It uses a single global mutex for exception_ptr objects, which doesn't
scale well but that probably isn't a problem for processors without
lock-free atomics for single words.

This also solves the problem of mismatched -march options, where the
header is compiled for a CPU that supports the atomics but
libstdc++.so was built for an older CPU that doesn't support them, and
linking fails (as in https://gcc.gnu.org/PR58938#c13).


We'd also need something like this extra piece, to ensure we don't
leak exceptions. Currently __gxx_exception_cleanup assumes that if
ATOMIC_INT_LOCK_FREE < 2 the referenceCount can never be greater than
1, because there are not exception_ptr objects that could increase it.

If we enable exception_ptr unconditionally then that assumption
doesn't hold. This patch uses the exception_ptr code to do the
cleanup, under the same mutex as any other increments and decrements
of the reference count.

It's a bit of a hack though.

diff --git a/libstdc++-v3/libsupc++/Makefile.am b/libstdc++-v3/libsupc++/Makefile.am
index 2df31ff..dbfd00f 100644
--- a/libstdc++-v3/libsupc++/Makefile.am
+++ b/libstdc++-v3/libsupc++/Makefile.am
@@ -155,9 +155,9 @@ eh_terminate.o: eh_terminate.cc
 	$(CXXCOMPILE) -std=gnu++11 -c $<
 
 eh_throw.lo: eh_throw.cc
-	$(LTCXXCOMPILE) -std=gnu++11 -c $<
+	$(LTCXXCOMPILE) -std=gnu++11 -fno-access-control -c $<
 eh_throw.o: eh_throw.cc
-	$(CXXCOMPILE) -std=gnu++11 -c $<
+	$(CXXCOMPILE) -std=gnu++11 -fno-access-control -c $<
 
 guard.lo: guard.cc
 	$(LTCXXCOMPILE) -std=gnu++11 -c $<
diff --git a/libstdc++-v3/libsupc++/Makefile.in b/libstdc++-v3/libsupc++/Makefile.in
index e828ed9..f3e2193 100644
--- a/libstdc++-v3/libsupc++/Makefile.in
+++ b/libstdc++-v3/libsupc++/Makefile.in
@@ -884,9 +884,9 @@ eh_terminate.o: eh_terminate.cc
 	$(CXXCOMPILE) -std=gnu++11 -c $<
 
 eh_throw.lo: eh_throw.cc
-	$(LTCXXCOMPILE) -std=gnu++11 -c $<
+	$(LTCXXCOMPILE) -std=gnu++11 -fno-access-control -c $<
 eh_throw.o: eh_throw.cc
-	$(CXXCOMPILE) -std=gnu++11 -c $<
+	$(CXXCOMPILE) -std=gnu++11 -fno-access-control -c $<
 
 guard.lo: guard.cc
 	$(LTCXXCOMPILE) -std=gnu++11 -c $<
diff --git a/libstdc++-v3/libsupc++/eh_throw.cc b/libstdc++-v3/libsupc++/eh_throw.cc
index a05f4eb..0f61fbf 100644
--- a/libstdc++-v3/libsupc++/eh_throw.cc
+++ b/libstdc++-v3/libsupc++/eh_throw.cc
@@ -24,6 +24,7 @@
 
 #include 
 #include "unwind-cxx.h"
+#include "exception_ptr.h"
 
 using namespace __cxxabiv1;
 
@@ -42,17 +43,8 @@ __gxx_exception_cleanup (_Unwind_Reason_Code code, _Unwind_Exception *exc)
   if (code != _URC_FOREIGN_EXCEPTION_CAUGHT && code != _URC_NO_REASON)
 __terminate (header->exc.terminateHandler);
 
-#if ATOMIC_INT_LOCK_FREE > 1
-  if (__atomic_sub_fetch (>referenceCount, 1, __ATOMIC_ACQ_REL) == 0)
-{
-#endif
-  if (header->exc.exceptionDestructor)
-	header->exc.exceptionDestructor (header + 1);
-
-  __cxa_free_exception (header + 1);
-#if ATOMIC_INT_LOCK_FREE > 1
-}
-#endif
+  std::__exception_ptr::exception_ptr ptr;
+  ptr._M_exception_object = header + 1;
 }
 
 extern "C" __cxa_refcounted_exception*

Re: [PATCH] Fix PR64078

[Bernd Edlinger]

On 09/19/16 23:27, Jeff Law wrote:
> On 09/19/2016 03:08 PM, Bernd Edlinger wrote:
>>>
>>> Would it work to break this up into distinct tests, exit()-ing from each
>>> function rather than returning back to main?
>>>
>>
>> Yes.  I think how this test is designed, each function must be inlined,
>> or it will fail anyway.  It was for instance impossible to pass the
>> ubsan test, if -fno-inline was used as RUNTESTFLAGS.
> Presumably the dg-skip-if is ensuring that we're only testing with -O2
> turned on.
>>
>> Therefore it works as well, if main avoids to return and calls
>> exit(0) instead, with a specific comment of course.
>>
>> See https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01985.html
> That works for me.
>
> jeff

OK, thanks.
Then I will commit this on trunk and active branches.


Bernd.
2016-09-22  Bernd Edlinger  
	Tom de Vries  

	PR testsuite/77411
	* c-c++-common/ubsan/object-size-9.c: Call __builtin_exit in C++.

Index: c-c++-common/ubsan/object-size-9.c
===
--- c-c++-common/ubsan/object-size-9.c	(Revision 240355)
+++ c-c++-common/ubsan/object-size-9.c	(Arbeitskopie)
@@ -93,5 +93,9 @@ main (void)
 #endif
   f4 (12);
   f5 (12);
+#ifdef __cplusplus
+  /* Stack may be smashed by f2/f3 above.  */
+  __builtin_exit (0);
+#endif
   return 0;
 }

Re: [PATCH 0/4] Properly handle GCC target("march=") (PR71652)

[jh]

OK for patches 1-4.

Honza

Dne 2016-08-12 14:15, Martin Liška napsal:

PING^1


Hello.

Following small patch set targets $subject, where we ICE if someone
uses #pragma GCC target ("arch=generic"). My attempt is to not to
create a new target optimization node in case of a wrong value
of march string. Such approach does not generate multiple errors.

Apart from that, I also improved i386 option handling as mentioned
in: [1]

Patch bootstraps and survives regression tests on 
powerpc64le-unknown-linux-gnu.


Ready for trunk?
Thanks,
Martin

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71652#c4

marxin (4):
  Fix PR target/71652
  Support crc32 as a i386 target optimization node
  Support movbe as a i386 target optimization node
  Remove fused-madd from documentation

 gcc/config/i386/i386.c| 64 
++-

 gcc/doc/extend.texi   |  5 ---
 gcc/testsuite/gcc.target/i386/crc32-5.c   | 25 
 gcc/testsuite/gcc.target/i386/movbe-4.c   | 20 ++
 gcc/testsuite/gcc.target/i386/pr71652-2.c | 13 +++
 gcc/testsuite/gcc.target/i386/pr71652-3.c | 14 +++
 gcc/testsuite/gcc.target/i386/pr71652.c   | 13 +++
 7 files changed, 130 insertions(+), 24 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/crc32-5.c
 create mode 100644 gcc/testsuite/gcc.target/i386/movbe-4.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr71652-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr71652-3.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr71652.c

[PATCH] Increase lto-min-partition

[Wilco Dijkstra]

Increase the lto-min-partition size to 5 to reduce the number of partitions.
See eg. https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00235.html for a concise 
explanation why 1 is too small for modern CPU/memory size.  Additionally,
larger values increase optimization opportunities and reduce bad decisions in 
the
layout of global variables across partitions (anchors do not work well with 
LTO).
Looking at SPEC2000, 8 more benchmarks now use a single LTO partition which
is the most optimal.  Build time with LTO increases only slightly, eg. SPEC2006
now takes 2% more time on an 8-core ARM server.

ChangeLog:
2016-09-22  Wilco Dijkstra  

gcc/
* params.def (MIN_PARTITION_SIZE): Increase to 5.

--
diff --git a/gcc/params.def b/gcc/params.def
index 
79b7dd4cca9ec1bb67a64725fb1a596b6e937419..da8fd1825e15f2aa800b1c8b680985776c1080ed
 100644
--- a/gcc/params.def
+++ b/gcc/params.def
@@ -1045,7 +1045,7 @@ DEFPARAM (PARAM_LTO_PARTITIONS,
 DEFPARAM (MIN_PARTITION_SIZE,
  "lto-min-partition",
  "Minimal size of a partition for LTO (in estimated instructions).",
- 1, 0, 0)
+ 5, 0, 0)
 
 DEFPARAM (MAX_PARTITION_SIZE,
  "lto-max-partition",

Re: [PATCH] Fix PR ipa/77653

[David Edelsohn]

@@ -,13 +2221,11 @@ sem_variable::merge (sem_item *alias_item)
 }

   /* We can not merge if address comparsion metters.  */
-  if (original_address_matters && alias_address_matters
-  && flag_merge_constants < 2)
+  if (alias_address_matters && flag_merge_constants < 2)
 {
   if (dump_file)
  fprintf (dump_file,
- "Not unifying; "
- "adress of original and alias may be compared.\n\n");
+ "Not unifying; adress of original may be compared.\n\n");
 ^^^ address not adress
   return false;
 }

The dump file message contains a typo: address not adress.

+/* { dg-final { scan-ipa-dump "Not unifying; adress of original may
be compared." "icf"  } } */

Similarly, the testcase needs to be updated to match.

Thanks, David

Re: [C++ Patch] PR 71979

[Jason Merrill]

OK.

On Thu, Sep 22, 2016 at 8:53 AM, Paolo Carlini  wrote:
> Hi,
>
> in this ICE on invalid [5/6/7] regression the gcc_assert in build_base_path
> is triggered during error recovery when lookup_base returns NULL_TREE (makes
> sense because B is looked up as base of A!). It seems to me that we can
> simply allow for this case in the assertion and be done with the issue
> (should be safe for the release branch too). Tested x86_64-linux.
>
> Thanks,
>
> Paolo.
>
> /
>

Re: [C++ PATCH] Aligned new option handling fixes (PR c++/77651)

[Jason Merrill]

On Thu, Sep 22, 2016 at 4:58 AM, Christophe Lyon
 wrote:
> This new test (aligned-new6.C) fails on arm/aarch64 bare-metal targets
> (using newlib):
> arm-none-eabi/./libstdc++-v3/src/.libs/libstdc++.a(new_opa.o): In
> function `operator new(unsigned int, std::align_val_t)':
> /gccsrc/libstdc++-v3/libsupc++/new_opa.cc:76: undefined reference to
> `aligned_alloc'

Hmm, does this fix that?
commit d94c614feec525860ae3640727a740fb5a0fe9b0
Author: Jason Merrill 
Date:   Thu Sep 22 09:01:16 2016 -0400

* configure.ac: Define HAVE_MEMALIGN for newlib.

diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 6332c4d..973d6d1 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -28822,6 +28822,8 @@ else
 
 $as_echo "#define HAVE_ICONV 1" >>confdefs.h
 
+$as_echo "#define HAVE_MEMALIGN 1" >>confdefs.h
+
   else
 
 # Base decisions on target environment.
diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index 5657ecb..baf605c 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/configure.ac
@@ -324,6 +324,7 @@ else
 AC_DEFINE(HAVE_TANHF)
 
 AC_DEFINE(HAVE_ICONV)
+AC_DEFINE(HAVE_MEMALIGN)
   else
 GLIBCXX_CROSSCONFIG
   fi

[PATCH] Improve SCCVN with devirtualization to pure/const calls

[Richard Biener]

Not because it might be terribly important but the recent change
triggered a latent(?) issue on AIX which broke bootstrap.  Let's
try if another change mitigates that.

The change basically allows devirt-to-const/pure to be taken
into account during the value-numbering rather than only in
followup passes (after we committed the devirtualization).

Bootstrap / regtest running on x86_64-unknown-linux-gnu.

Richard.

2016-09-22  Richard Biener  

* tree-ssa-sccvn.c (visit_reference_op_call): Value number
virtual definition to virtual use if the call devirtualizes
to a const or pure function.
(visit_use): Also visit calls we can devirtualize to a
const or pure function.

Index: gcc/tree-ssa-sccvn.c
===
*** gcc/tree-ssa-sccvn.c(revision 240353)
--- gcc/tree-ssa-sccvn.c(working copy)
*** visit_reference_op_call (tree lhs, gcall
*** 3486,3492 
vn_reference_t vr2;
vn_reference_s **slot;
if (vdef)
!   changed |= set_ssa_val_to (vdef, vdef);
if (lhs)
changed |= set_ssa_val_to (lhs, lhs);
vr2 = current_info->references_pool->allocate ();
--- 3593,3615 
vn_reference_t vr2;
vn_reference_s **slot;
if (vdef)
!   {
! /* If we value numbered an indirect functions function to
!one not clobbering memory value number its VDEF to its
!VUSE.  */
! tree fn = gimple_call_fn (stmt);
! tree vdef_val = vdef;
! if (fn && TREE_CODE (fn) == SSA_NAME)
!   {
! fn = SSA_VAL (fn);
! if (TREE_CODE (fn) == ADDR_EXPR
! && TREE_CODE (TREE_OPERAND (fn, 0)) == FUNCTION_DECL
! && (flags_from_decl_or_type (TREE_OPERAND (fn, 0))
! & (ECF_CONST | ECF_PURE)))
!   vdef_val = vuse_ssa_val (gimple_vuse (stmt));
!   }
! changed |= set_ssa_val_to (vdef, vdef_val);
!   }
if (lhs)
changed |= set_ssa_val_to (lhs, lhs);
vr2 = current_info->references_pool->allocate ();
*** visit_use (tree use)
*** 3913,3923 
}
}
  
if (!gimple_call_internal_p (call_stmt)
  && (/* Calls to the same function with the same vuse
 and the same operands do not necessarily return the same
 value, unless they're pure or const.  */
! gimple_call_flags (call_stmt) & (ECF_PURE | ECF_CONST)
  /* If calls have a vdef, subsequent calls won't have
 the same incoming vuse.  So, if 2 calls with vdef have the
 same vuse, we know they're not subsequent.
--- 4035,4056 
}
}
  
+   /* Pick up flags from a devirtualization target.  */
+   tree fn = gimple_call_fn (stmt);
+   int extra_fnflags = 0;
+   if (fn && TREE_CODE (fn) == SSA_NAME)
+   {
+ fn = SSA_VAL (fn);
+ if (TREE_CODE (fn) == ADDR_EXPR
+ && TREE_CODE (TREE_OPERAND (fn, 0)) == FUNCTION_DECL)
+   extra_fnflags = flags_from_decl_or_type (TREE_OPERAND (fn, 0));
+   }
if (!gimple_call_internal_p (call_stmt)
  && (/* Calls to the same function with the same vuse
 and the same operands do not necessarily return the same
 value, unless they're pure or const.  */
! ((gimple_call_flags (call_stmt) | extra_fnflags)
!  & (ECF_PURE | ECF_CONST))
  /* If calls have a vdef, subsequent calls won't have
 the same incoming vuse.  So, if 2 calls with vdef have the
 same vuse, we know they're not subsequent.
Index: gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-56.c
===
*** gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-56.c  (revision 0)
--- gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-56.c  (working copy)
***
*** 0 
--- 1,26 
+ /* { dg-do compile } */
+ /* { dg-options "-O -fdump-tree-fre1" } */
+ 
+ int x = 1;
+ int __attribute__((noinline,noclone)) fn ()
+ {
+   return x;
+ }
+ int (*f)();
+ int main ()
+ {
+   int res;
+   f = fn;
+   x = 0;
+   res = f ();
+   res += x;
+   if (res != 0)
+ __builtin_abort ();
+   return 0;
+ }
+ 
+ /* We should be able to optimize the load from x in main and thus the
+addition.  */
+ 
+ /* { dg-final { scan-tree-dump-times "= x;" 1 "fre1" } } */
+ /* { dg-final { scan-tree-dump-times " \\\+ " 0 "fre1" } } */

[C++ Patch] PR 71979

[Paolo Carlini]

Hi,

in this ICE on invalid [5/6/7] regression the gcc_assert in 
build_base_path is triggered during error recovery when lookup_base 
returns NULL_TREE (makes sense because B is looked up as base of A!). It 
seems to me that we can simply allow for this case in the assertion and 
be done with the issue (should be safe for the release branch too). 
Tested x86_64-linux.


Thanks,

Paolo.

/

/cp
2016-09-22  Paolo Carlini  

PR c++/71979
* class.c (build_base_path): Allow for lookup_base returning
NULL_TREE.

/testsuite
2016-09-22  Paolo Carlini  

PR c++/71979
* g++.dg/cpp0x/pr71979.C: New.
Index: cp/class.c
===
--- cp/class.c  (revision 240345)
+++ cp/class.c  (working copy)
@@ -296,12 +296,13 @@ build_base_path (enum tree_code code,
   /* This can happen when adjust_result_of_qualified_name_lookup can't
 find a unique base binfo in a call to a member function.  We
 couldn't give the diagnostic then since we might have been calling
-a static member function, so we do it now.  */
+a static member function, so we do it now.  In other cases, eg.
+during error recovery (c++/71979), we may not have a base at all.  */
   if (complain & tf_error)
{
  tree base = lookup_base (probe, BINFO_TYPE (d_binfo),
   ba_unique, NULL, complain);
- gcc_assert (base == error_mark_node);
+ gcc_assert (base == error_mark_node || !base);
}
   return error_mark_node;
 }
Index: testsuite/g++.dg/cpp0x/pr71979.C
===
--- testsuite/g++.dg/cpp0x/pr71979.C(revision 0)
+++ testsuite/g++.dg/cpp0x/pr71979.C(working copy)
@@ -0,0 +1,15 @@
+// PR c++/71979
+// { dg-do compile { target c++11 } }
+
+struct A
+{ 
+  A & operator= (A &);
+};
+
+struct B : A {};   // { dg-error "cannot bind" }
+
+void foo ()
+{ 
+  B b;
+  b = B ();  // { dg-error "use of deleted" }
+}

Backport fix for PR 65210 to gcc-5-branch

[Senthil Kumar Selvaraj]

Hi,

  Is it ok to backport PR 65210 to gcc-5-branch? The patch is already in
  6.x and trunk.

Regards
Senthil

gcc/ChangeLog

2016-09-22  Senthil Kumar Selvaraj  

Backport from trunk r227496

PR target/65210
* config/avr/avr.c (avr_eval_addr_attrib): Look for io_low
attribute as well.

gcc/testsuite/ChangeLog

2016-09-22  Senthil Kumar Selvaraj  

Backport from trunk r227496

PR target/65210
* gcc.target/avr/pr65210.c: New test.

Index: gcc/config/avr/avr.c
===
--- gcc/config/avr/avr.c(revision 240340)
+++ gcc/config/avr/avr.c(working copy)
@@ -9122,6 +9122,8 @@
   if (SYMBOL_REF_FLAGS (x) & SYMBOL_FLAG_IO)
{
  attr = lookup_attribute ("io", DECL_ATTRIBUTES (decl));
+ if (!attr || !TREE_VALUE (attr))
+   attr = lookup_attribute ("io_low", DECL_ATTRIBUTES (decl));
  gcc_assert (attr);
}
   if (!attr || !TREE_VALUE (attr))
   Index: gcc/testsuite/gcc.target/avr/pr65210.c
===
--- gcc/testsuite/gcc.target/avr/pr65210.c  (nonexistent)
+++ gcc/testsuite/gcc.target/avr/pr65210.c  (working copy)
@@ -0,0 +1,7 @@
+/* { dg-do compile } */
+
+/* This testcase exposes PR65210. Usage of the io_low attribute
+   causes assertion failure because code only looks for the io
+   attribute if SYMBOL_FLAG_IO is set. */
+
+volatile char q __attribute__((io_low,address(0x81)));