Re: libgo patch committed: Fixes for sparc64

[Andrew Pinski]

On Wed, Oct 12, 2016 at 9:20 PM, Ian Lance Taylor  wrote:
> On Wed, Oct 12, 2016 at 8:03 PM, Andrew Pinski  wrote:
>> On Wed, Oct 12, 2016 at 10:43 AM, Ian Lance Taylor  wrote:
>>> On Wed, Oct 12, 2016 at 7:28 AM, Ian Lance Taylor  wrote:
 This patch to libgo by James Clarke fixes libgo for sparc64.  The
 getrandom syscall was being ignored because the file was named
 "sparc".  The clone syscall apparently needs special attention on
 SPARC.  Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
 Committed to mainline.
>>>
>>> And a followup: mark the new rawClone function as no_split_stack.
>>> Bootstrapped and tested on x86_64-pc-linux-gnu, committed to mainline.
>>
>> This breaks the build on Ubuntu 1604 on aarch64-linux-gnu:
>>
>> ../../../gcc/libgo/go/syscall/clone_linux.c:14:28: warning: ‘struct
>> pt_regs’ declared inside parameter list will not be visible outside of
>> this definition or declaration
>>
>>  void *ctid, struct pt_regs *regs)
>>
>> ^~~
>>
>> ../../../gcc/libgo/go/syscall/clone_linux.c:19:82: warning: ‘struct
>> pt_regs’ declared inside parameter list will not be visible outside of
>> this definition or declaration  rawClone (unsigned long flags, void
>> *child_stack, void *ptid, void *ctid, struct pt_regs *regs)
>>
>>
>>^~~
>>
>> ../../../gcc/libgo/go/syscall/clone_linux.c:19:1: error: conflicting
>> types for ‘rawClone’
>>
>>  rawClone (unsigned long flags, void *child_stack, void *ptid, void
>> *ctid, struct pt_regs *regs)  ^~~~
>>
>> ../../../gcc/libgo/go/syscall/clone_linux.c:13:6: note: previous
>> declaration of ‘rawClone’ was here  long rawClone (unsigned long
>> flags, void *child_stack, void *ptid,
>>
>>   ^~~~
>
> Bother.  Fixed like so.  Committed to mainline.

Thanks that solved it.

>
> Ian

Re: [PATCH] Fix PR77937

[Markus Trippelsdorf]

On 2016.10.12 at 20:14 -0500, Bill Schmidt wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937 reports an ICE in SLSR
> where a POINTER_PLUS_EXPR occurs with a candidate increment of -1.  This
> is supposed to be prevented by code in analyze_increments, since replacement
> of such a candidate is not guaranteed to be profitable.  The test for this
> was inadequate.  This patch replaces it with the correct check, determining
> whether the type of the candidate is a pointer type.
> 
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu, committed.

Please commit the small testcase from the bug, too.

Thanks.

-- 
Markus

Re: Set nonnull attribute to ptr_info_def based on VRP

[kugan]

Hi Richard,



what does this try to do?  Preserve info VRP computed across PTA?

I think we didn't yet sort out the nonlocal/escaped vs. null handling properly
(or how PTA should handle get_ptr_nonnull).  The way you are using it
asks for pt.null to be orthogonal to nonlocal/escaped and thus having
nonlocal or escaped would also require setting ptr.null in PTA.  It then
would be also more canonical to set it for pt.anything as well.  Which
means conservatively handling it would be equivalent to flipping its
semantic and changing its name to pt.nonnull.

That said, you seem to be simply "reserving" the bit for VRP, keeping it
conservatively true when "not computed".  I guess I'm fine with this for now
but it should be documented in the header file that way.



Thanks for the comments.

To summarize, currently I am not relying on PTA analysis at all. Just 
saving null from VRP (or rather nonnull) and preserving it across PTA. 
Primary intention is to pass it for PARM_DECL SSA names (from ipa-vrp).


In this case, using  pt.anything/nonlocal/escaped will only make the 
result more pessimistic.


Ideally, we should improve pt.null within PTA but for now as you said, I 
will document it.


When we start using pt.null from PTA analysis, we would also have to 
take into account pt.anything/nonlocal/escaped.


Does that make sense?

Thanks,
Kugan

Re: [vrp] use get_ptr_nonnull in tree-vrp

[kugan]

Hi Richard,


On 13/10/16 05:53, kugan wrote:

Hi Richard,

On 12/10/16 23:24, Richard Biener wrote:

On Wed, Oct 12, 2016 at 8:56 AM, kugan
 wrote:

Hi,

This patch uses get_ptr_nonnull in tree-vrp.

Bootstrapped and regression tested this with other patched without any
new regressions on x86_64-linux-gnu.

Is this OK for trunk?


Um.  Doesn't make much sense given nothing provides this info before EVRP?
And if it makes sense then it makes sense not only for PARM_DECL SSA names.

Not before EVRP. But when in TREE-VRP, EVRP + IPA-VRP should provide this.


My primary intention was to pass it for PARM_DECL SSA names which comes 
from ipa-vrp. I have changed this now.


Thanks,
Kugan


I am not sure if this is the question?

Thanks,
Kugan


Richard.


Thanks,
Kugan

gcc/testsuite/ChangeLog:

2016-10-12  Kugan Vivekanandarajah  

* gcc.dg/ipa/vrp4.c: Adjust testcase.

gcc/ChangeLog:

2016-10-12  Kugan Vivekanandarajah  

* tree-vrp.c (get_value_range): Check get_ptr_nonnull.
>From c033af7161bcf54f50262688854cb32e3e8eeb54 Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Wed, 12 Oct 2016 13:54:58 +1100
Subject: [PATCH 3/3] Teach-vrp-to-use-ptr-nonnull

---
 gcc/testsuite/gcc.dg/ipa/vrp4.c | 3 ++-
 gcc/tree-vrp.c  | 5 -
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/ipa/vrp4.c b/gcc/testsuite/gcc.dg/ipa/vrp4.c
index d7e1f26..941f80e 100644
--- a/gcc/testsuite/gcc.dg/ipa/vrp4.c
+++ b/gcc/testsuite/gcc.dg/ipa/vrp4.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-ipa-cp-details" } */
+/* { dg-options "-O2 -fdump-ipa-cp-details -fdump-tree-vrp1" } */
 
 static __attribute__((noinline, noclone))
 int foo (int *p)
@@ -25,3 +25,4 @@ int bar (struct st *s)
 }
 
 /* { dg-final { scan-ipa-dump "Setting nonnull for 0" "cp" } } */
+/* { dg-final { scan-tree-dump-times "if" 1 "vrp1" } } */
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 7e4f947..bc53d07 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -679,7 +679,10 @@ get_value_range (const_tree var)
   if (SSA_NAME_IS_DEFAULT_DEF (var))
 {
   sym = SSA_NAME_VAR (var);
-  if (TREE_CODE (sym) == PARM_DECL)
+  if (POINTER_TYPE_P (TREE_TYPE (sym))
+	  && get_ptr_nonnull (var))
+	set_value_range_to_nonnull (vr, TREE_TYPE (sym));
+  else if (TREE_CODE (sym) == PARM_DECL)
 	{
 	  /* Try to use the "nonnull" attribute to create ~[0, 0]
 	 anti-ranges for pointers.  Note that this is only valid with
-- 
2.7.4

Re: libgo patch committed: Fixes for sparc64

[Ian Lance Taylor]

On Wed, Oct 12, 2016 at 8:03 PM, Andrew Pinski  wrote:
> On Wed, Oct 12, 2016 at 10:43 AM, Ian Lance Taylor  wrote:
>> On Wed, Oct 12, 2016 at 7:28 AM, Ian Lance Taylor  wrote:
>>> This patch to libgo by James Clarke fixes libgo for sparc64.  The
>>> getrandom syscall was being ignored because the file was named
>>> "sparc".  The clone syscall apparently needs special attention on
>>> SPARC.  Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
>>> Committed to mainline.
>>
>> And a followup: mark the new rawClone function as no_split_stack.
>> Bootstrapped and tested on x86_64-pc-linux-gnu, committed to mainline.
>
> This breaks the build on Ubuntu 1604 on aarch64-linux-gnu:
>
> ../../../gcc/libgo/go/syscall/clone_linux.c:14:28: warning: ‘struct
> pt_regs’ declared inside parameter list will not be visible outside of
> this definition or declaration
>
>  void *ctid, struct pt_regs *regs)
>
> ^~~
>
> ../../../gcc/libgo/go/syscall/clone_linux.c:19:82: warning: ‘struct
> pt_regs’ declared inside parameter list will not be visible outside of
> this definition or declaration  rawClone (unsigned long flags, void
> *child_stack, void *ptid, void *ctid, struct pt_regs *regs)
>
>
>^~~
>
> ../../../gcc/libgo/go/syscall/clone_linux.c:19:1: error: conflicting
> types for ‘rawClone’
>
>  rawClone (unsigned long flags, void *child_stack, void *ptid, void
> *ctid, struct pt_regs *regs)  ^~~~
>
> ../../../gcc/libgo/go/syscall/clone_linux.c:13:6: note: previous
> declaration of ‘rawClone’ was here  long rawClone (unsigned long
> flags, void *child_stack, void *ptid,
>
>   ^~~~

Bother.  Fixed like so.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 241074)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-f38ba8837a0c961e18d982930e192132870f3836
+6c9070324d5b7c8483bc7c17b0a8faaa1fb1ae30
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/syscall/clone_linux.c
===
--- libgo/go/syscall/clone_linux.c  (revision 241072)
+++ libgo/go/syscall/clone_linux.c  (working copy)
@@ -5,18 +5,17 @@
license that can be found in the LICENSE file.  */
 
 #include 
-#include 
 #include 
 
 #include "runtime.h"
 
 long rawClone (unsigned long flags, void *child_stack, void *ptid,
-  void *ctid, struct pt_regs *regs)
+  void *ctid, void *regs)
   __asm__ (GOSYM_PREFIX "syscall.rawClone")
   __attribute__ ((no_split_stack));
 
 long
-rawClone (unsigned long flags, void *child_stack, void *ptid, void *ctid, 
struct pt_regs *regs)
+rawClone (unsigned long flags, void *child_stack, void *ptid, void *ctid, void 
*regs)
 {
 #if defined(__arc__) || defined(__aarch64__) || defined(__arm__) || 
defined(__mips__) || defined(__hppa__) || defined(__powerpc__) || 
defined(__score__) || defined(__i386__) || defined(__xtensa__)
   // CLONE_BACKWARDS

Re: libgo patch committed: Fixes for sparc64

[Andrew Pinski]

On Wed, Oct 12, 2016 at 10:43 AM, Ian Lance Taylor  wrote:
> On Wed, Oct 12, 2016 at 7:28 AM, Ian Lance Taylor  wrote:
>> This patch to libgo by James Clarke fixes libgo for sparc64.  The
>> getrandom syscall was being ignored because the file was named
>> "sparc".  The clone syscall apparently needs special attention on
>> SPARC.  Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
>> Committed to mainline.
>
> And a followup: mark the new rawClone function as no_split_stack.
> Bootstrapped and tested on x86_64-pc-linux-gnu, committed to mainline.

This breaks the build on Ubuntu 1604 on aarch64-linux-gnu:

../../../gcc/libgo/go/syscall/clone_linux.c:14:28: warning: ‘struct
pt_regs’ declared inside parameter list will not be visible outside of
this definition or declaration

 void *ctid, struct pt_regs *regs)

^~~

../../../gcc/libgo/go/syscall/clone_linux.c:19:82: warning: ‘struct
pt_regs’ declared inside parameter list will not be visible outside of
this definition or declaration  rawClone (unsigned long flags, void
*child_stack, void *ptid, void *ctid, struct pt_regs *regs)


   ^~~

../../../gcc/libgo/go/syscall/clone_linux.c:19:1: error: conflicting
types for ‘rawClone’

 rawClone (unsigned long flags, void *child_stack, void *ptid, void
*ctid, struct pt_regs *regs)  ^~~~

../../../gcc/libgo/go/syscall/clone_linux.c:13:6: note: previous
declaration of ‘rawClone’ was here  long rawClone (unsigned long
flags, void *child_stack, void *ptid,

  ^~~~

Thanks,
Andrew



>
> Ian

[PATCH] Fix PR77937

[Bill Schmidt]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937 reports an ICE in SLSR
where a POINTER_PLUS_EXPR occurs with a candidate increment of -1.  This
is supposed to be prevented by code in analyze_increments, since replacement
of such a candidate is not guaranteed to be profitable.  The test for this
was inadequate.  This patch replaces it with the correct check, determining
whether the type of the candidate is a pointer type.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu, committed.

Thanks,
Bill


2016-10-12  Bill Schmidt  

PR tree-optimization/77937
* gimple-ssa-strength-reduction.c (analyze_increments): Use
POINTER_TYPE_P on the candidate type to determine whether
candidates in this chain require pointer arithmetic.


Index: gcc/gimple-ssa-strength-reduction.c
===
--- gcc/gimple-ssa-strength-reduction.c (revision 240946)
+++ gcc/gimple-ssa-strength-reduction.c (working copy)
@@ -2816,8 +2816,7 @@ analyze_increments (slsr_cand_t first_dep, machine
   else if (incr == 0
   || incr == 1
   || (incr == -1
-  && (gimple_assign_rhs_code (first_dep->cand_stmt)
-  != POINTER_PLUS_EXPR)))
+  && !POINTER_TYPE_P (first_dep->cand_type)))
incr_vec[i].cost = COST_NEUTRAL;
   
   /* FORNOW: If we need to add an initializer, give up if a cast from

[PATCH] Don't unnecessarily create stack protector guard decls and MEMs (PR target/77957)

[Jakub Jelinek]

Hi!

PR77957 is likely a rs6000 backend bug where a useless memory load causes
.LCTOC0 undefined reference in the end at -O0 and as such should be fixed,
but I think it is completely unnecessary to create those loads at all
if we know we are going to ignore it in the stack_protect_{set,test}
patterns because TARGET_THREAD_SSP_OFFSET is defined and we are going to
load from ABI selected TLS word.

So, this patch tweaks the -fstack-protector* expansion (both prologue and
epilogue) so that if targetm.stack_protector_guard hook returns NULL it just
passes a dummy const0_rtx down to the expander that is going to ignore it
anyway, and adjusts the affected targets to return NULL in those cases.

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

2016-10-12  Jakub Jelinek  

PR target/77957
* hooks.h (hook_tree_void_null): Declare.
* hooks.c (hook_tree_void_null): New function.
* langhooks.c (lhd_return_null_tree_v): Remove.
* langhooks-def.h (lhd_return_null_tree_v): Remove.
* cfgexpand.c (stack_protect_prologue): If guard_decl is NULL,
set y to const0_rtx.
* function.c (stack_protect_epilogue): Likewise.
* config/tilepro/tilepro.c (TARGET_STACK_PROTECT_GUARD): Redefine
if TARGET_THREAD_SSP_OFFSET is defined.
* config/s390/s390.c (TARGET_STACK_PROTECT_GUARD): Likewise.
* config/sparc/sparc.c (TARGET_STACK_PROTECT_GUARD): Likewise.
* config/tilegx/tilegx.c (TARGET_STACK_PROTECT_GUARD): Likewise.
* config/rs6000/rs6000.c (TARGET_STACK_PROTECT_GUARD): Likewise.
* config/i386/i386.c (TARGET_STACK_PROTECT_GUARD): Likewise.
(ix86_stack_protect_guard): New function.
c/
* c-objc-common.h (LANG_HOOKS_GETDECLS): Use hook_tree_void_null
instead of lhd_return_null_tree_v.
ada/
* gcc-interface/misc.c (LANG_HOOKS_GETDECLS): Use hook_tree_void_null
instead of lhd_return_null_tree_v.

--- gcc/config/tilepro/tilepro.c.jj 2016-09-27 20:12:45.0 +0200
+++ gcc/config/tilepro/tilepro.c2016-10-12 18:18:41.001998284 +0200
@@ -4948,6 +4948,11 @@ tilepro_file_end (void)
 #undef  TARGET_OPTION_OVERRIDE
 #define TARGET_OPTION_OVERRIDE tilepro_option_override
 
+#ifdef TARGET_THREAD_SSP_OFFSET
+#undef TARGET_STACK_PROTECT_GUARD
+#define TARGET_STACK_PROTECT_GUARD hook_tree_void_null
+#endif
+
 #undef  TARGET_SCALAR_MODE_SUPPORTED_P
 #define TARGET_SCALAR_MODE_SUPPORTED_P tilepro_scalar_mode_supported_p
 
--- gcc/config/s390/s390.c.jj   2016-09-27 09:46:13.0 +0200
+++ gcc/config/s390/s390.c  2016-10-12 18:17:24.873959377 +0200
@@ -15124,6 +15124,11 @@ s390_invalid_binary_op (int op ATTRIBUTE
 #undef TARGET_OPTION_OVERRIDE
 #define TARGET_OPTION_OVERRIDE s390_option_override
 
+#ifdef TARGET_THREAD_SSP_OFFSET
+#undef TARGET_STACK_PROTECT_GUARD
+#define TARGET_STACK_PROTECT_GUARD hook_tree_void_null
+#endif
+
 #undef TARGET_ENCODE_SECTION_INFO
 #define TARGET_ENCODE_SECTION_INFO s390_encode_section_info
 
--- gcc/config/i386/i386.c.jj   2016-10-08 14:04:16.859911786 +0200
+++ gcc/config/i386/i386.c  2016-10-12 18:10:00.344570177 +0200
@@ -44023,6 +44023,18 @@ ix86_mangle_type (const_tree type)
 }
 }
 
+#ifdef TARGET_THREAD_SSP_OFFSET
+/* If using TLS guards, don't waste time creating and expanding
+   __stack_chk_guard decl and MEM as we are going to ignore it.  */
+static tree
+ix86_stack_protect_guard (void)
+{
+  if (TARGET_SSP_TLS_GUARD)
+return NULL_TREE;
+  return default_stack_protect_guard ();
+}
+#endif
+
 /* For 32-bit code we can save PIC register setup by using
__stack_chk_fail_local hidden function instead of calling
__stack_chk_fail directly.  64-bit code doesn't need to setup any PIC
@@ -50614,6 +50626,11 @@ ix86_addr_space_zero_address_valid (addr
 #undef TARGET_MANGLE_TYPE
 #define TARGET_MANGLE_TYPE ix86_mangle_type
 
+#ifdef TARGET_THREAD_SSP_OFFSET
+#undef TARGET_STACK_PROTECT_GUARD
+#define TARGET_STACK_PROTECT_GUARD ix86_stack_protect_guard
+#endif
+
 #if !TARGET_MACHO
 #undef TARGET_STACK_PROTECT_FAIL
 #define TARGET_STACK_PROTECT_FAIL ix86_stack_protect_fail
--- gcc/config/sparc/sparc.c.jj 2016-10-12 01:16:42.0 +0200
+++ gcc/config/sparc/sparc.c2016-10-12 18:17:44.595710443 +0200
@@ -798,6 +798,11 @@ char sparc_hard_reg_printed[8];
 #undef TARGET_OPTION_OVERRIDE
 #define TARGET_OPTION_OVERRIDE sparc_option_override
 
+#ifdef TARGET_THREAD_SSP_OFFSET
+#undef TARGET_STACK_PROTECT_GUARD
+#define TARGET_STACK_PROTECT_GUARD hook_tree_void_null
+#endif
+
 #if TARGET_GNU_TLS && defined(HAVE_AS_SPARC_UA_PCREL)
 #undef TARGET_ASM_OUTPUT_DWARF_DTPREL
 #define TARGET_ASM_OUTPUT_DWARF_DTPREL sparc_output_dwarf_dtprel
--- gcc/config/tilegx/tilegx.c.jj   2016-09-14 16:01:07.0 +0200
+++ gcc/config/tilegx/tilegx.c  2016-10-12 18:18:20.952251422 +0200
@@ -5544,6 +5544,11 @@ tilegx_file_end (void)
 #undef  TARGET_OPTION_OVERRIDE
 #define TARGET_OPTION_OVERRIDE 

[PATCH] Fix -Wimplicit-fallthrough ICE (PR c/77946)

[Jakub Jelinek]

Hi!

Seems 2 functions in varasm.c just use TREE_PUBLIC on LABEL_DECLs together
with other kinds of decls, but as TREE_PUBLIC on LABEL_DECLs means now
something different, it breaks badly.
While I could change those 2 functions in varasm.c, I'm afraid other
functions might be doing something similar, so I think TREE_PRIVATE which is
used far less often is a better choice for the flag bit here.

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

2016-10-12  Jakub Jelinek  

PR c/77946
* tree.h (FALLTHROUGH_LABEL_P): Use private_flag instead of
public_flag.
* varasm.c (default_binds_local_p_3): Formatting fix.

* c-c++-common/Wimplicit-fallthrough-34.c: New test.

--- gcc/tree.h.jj   2016-10-11 20:50:53.0 +0200
+++ gcc/tree.h  2016-10-12 10:14:39.475938668 +0200
@@ -777,7 +777,7 @@ extern void omp_clause_range_check_faile
 /* Whether a case or a user-defined label is allowed to fall through to.
This is used to implement -Wimplicit-fallthrough.  */
 #define FALLTHROUGH_LABEL_P(NODE) \
-  (LABEL_DECL_CHECK (NODE)->base.public_flag)
+  (LABEL_DECL_CHECK (NODE)->base.private_flag)
 
 /* Nonzero means this expression is volatile in the C sense:
its address should be of type `volatile WHATEVER *'.
--- gcc/varasm.c.jj 2016-10-09 13:19:09.0 +0200
+++ gcc/varasm.c2016-10-12 10:12:41.617430327 +0200
@@ -6856,8 +6856,8 @@ default_binds_local_p_3 (const_tree exp,
  FIXME: We can resolve the weakref case more curefuly by looking at the
  weakref alias.  */
   if (lookup_attribute ("weakref", DECL_ATTRIBUTES (exp))
-  || (TREE_CODE (exp) == FUNCTION_DECL
-  && lookup_attribute ("ifunc", DECL_ATTRIBUTES (exp
+  || (TREE_CODE (exp) == FUNCTION_DECL
+ && lookup_attribute ("ifunc", DECL_ATTRIBUTES (exp
 return false;
 
   /* Static variables are always local.  */
--- gcc/testsuite/c-c++-common/Wimplicit-fallthrough-34.c.jj2016-10-12 
10:19:30.726252500 +0200
+++ gcc/testsuite/c-c++-common/Wimplicit-fallthrough-34.c   2016-10-12 
10:19:06.0 +0200
@@ -0,0 +1,12 @@
+/* PR c/77946 */
+/* { dg-do compile } */
+/* { dg-options "-Wimplicit-fallthrough" } */
+
+void
+foo (void)
+{
+  static void *p = &
+  goto *p;
+  /*FALLTHRU*/
+  lab:;
+}

Jakub

Re: [PATCH 01/16] read-md.c: Add various cleanups to ~rtx_reader

[Richard Sandiford]

Sorry, haven't had time to read the full series yet, but:

David Malcolm  writes:
> On Wed, 2016-10-05 at 17:51 +0200, Bernd Schmidt wrote:
>> On 10/05/2016 06:14 PM, David Malcolm wrote:
>> > The selftests for the RTL frontend require supporting multiple
>> > reader instances being alive one after another in-process, so
>> > this lack of cleanup would become a leak.
>> 
>> > +  /* Initialize global data.  */
>> > +  obstack_init (_obstack);
>> > +  ptr_locs = htab_create (161, leading_ptr_hash, leading_ptr_eq_p,
>> > 0);
>> > +  obstack_init (_loc_obstack);
>> > +  joined_conditions = htab_create (161, leading_ptr_hash,
>> > leading_ptr_eq_p, 0);
>> > +  obstack_init (_conditions_obstack);
>> > +  md_constants = htab_create (31, leading_string_hash,
>> > +leading_string_eq_p, (htab_del) 0);
>> > +  enum_types = htab_create (31, leading_string_hash,
>> > +  leading_string_eq_p, (htab_del) 0);
>> > +
>> > +  /* Unlock the stdio streams.  */
>> > +  unlock_std_streams ();
>> 
>> Hmm, but these are global statics. Shouldn't they first be moved to 
>> become class members?
>
> [CCing Richard Sandiford]
>
> I tried to move these into class rtx_reader, but doing so rapidly
> became quite invasive, with many of functions in the gen* tools
> becoming methods.

Is that just to avoid introducing explicit references to the global
rtx_reader object in the gen* tools?  If so, then TBH adding those
references sound better to me than tying generator-specific functions
to the rtx reader (not least because most of them do more than just
read rtl).

> Arguably that would be a good thing, but there are a couple of issues:
>
> (a) some of these functions take "vec" arguments; moving them from
> static functions to being class methods requires that vec.h has been
> included when the relevant class decl is parsed.

I don't think including vec.h more often should be a blocker though. :-)

> (b) rtx_reader turns into a bug dumping ground of methods, for the
> union of all of the various gen* tools.
>
> One way to alleviate these issues would be to do the split of
> rtx_reader into base_rtx_reader vs rtx_reader from patch 9 of the kit:
>   https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00273.html
> and perhaps to split out part of read-md.h into a new read-rtl.h.
>
> Before I reorganize the patches, does this approach sound reasonable?
>
> Alternatively, a less invasive approach is to have an accessor for
> these fields, so that things using them can get at them via the
> rtx_reader_ptr singleton e.g.:
>
> void
> grow_string_obstack (char ch)
> {
>obstack_1grow (rtx_reader_ptr->get_string_obstack (), ch);
> }
>
> and similar.

I think it's OK for the generators to refer rtx_reader_ptr directly.
Obviously that makes the patches more invasive, but hopefully the
extra changes are mechanical.

Thanks,
Richard

Re: [PATCH] 77864 Fix noexcept conditions for map/set default constructors

[Tim Song]

On Wed, Oct 12, 2016 at 4:36 PM, François Dumont  wrote:
> On 10/10/2016 23:01, Tim Song wrote:
>>
>> Trying again...with a few edits.
>>
>>> On Mon, Oct 10, 2016 at 3:24 PM, François Dumont 
>>> wrote:
>>>
>>> @@ -602,24 +612,32 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>>   struct _Rb_tree_impl : public _Node_allocator
>>>   {
>>> _Key_compare _M_key_compare;
>>> -  _Rb_tree_node_base _M_header;
>>> +  _Rb_header_node _M_header;
>>> +#if __cplusplus < 201103L
>>> size_type _M_node_count; // Keeps track of size of tree.
>>> +#else
>>> +  size_type _M_node_count = 0; // Keeps track of size of tree.
>>> +#endif
>>>
>>> +#if __cplusplus < 201103L
>>> _Rb_tree_impl()
>>> -  : _Node_allocator(), _M_key_compare(), _M_header(),
>>> -_M_node_count(0)
>>> -  { _M_initialize(); }
>>> +  : _M_node_count(0)
>>> +  { }
>>> +#else
>>> +  _Rb_tree_impl() = default;
>>> +#endif
>>
>>
>> The default constructor of the associative containers is required to
>> value-initialize the comparator (see their synopses in
>> [map/set/multimap/multiset.overview]).
>
> I don't have latest Standard version so can't see the exact word but I find
> quite annoying that the Standard doesn't allow this simple implementation.

The "exact word" is:

map() : map(Compare()) { }

which mandates the comparator be copied from a value-initialized Compare.
The use of () means value-initialization.

>
> I don't know if unodered containers have same kind of requirements for equal
> or hash functors but if so current implementation doesn't do this value
> initialization.


Yes, unordered_meows are required to do that as well. See, e.g.,
https://timsong-cpp.github.io/cppwp/unord.map.cnstr:

unordered_map() : unordered_map(size_type(see below)) { }
explicit unordered_map(size_type n,
  const hasher& hf = hasher(),
  const key_equal& eql = key_equal(),
  const allocator_type& a =
allocator_type());

The default constructor is specified to call the second constructor,
which copies the hasher etc. from a value-initialized object.

Tim

>
> So here is another attempt. This time it simply allows to have noexcept
> condition in one place and closer to where operations are being invoked.
>
> Ok to commit after tests ?
>
> François
>
>>
>>   _Rb_tree_impl() = default; doesn't do that; it default-initializes the
>>   comparator instead.
>>
>> Tim
>>
>

[Visium] Fix gcc.dg/compat/scalar-by-value-4/scalar-return-4

[Eric Botcazou]

There is a missing big-endian correction when types smaller than a word are 
passed through va_arg without promotion like _Complex char.

Tested on visium-elf, applied on the mainline.


2016-10-12  Eric Botcazou  

* config/visium/visium.c (visium_gimplify_va_arg): Emit a big-endian
correction if the type is smaller than a word.
(visium_select_cc_mode): Add ... fall through ... comment.

-- 
Eric BotcazouIndex: config/visium/visium.c
===
--- config/visium/visium.c	(revision 240969)
+++ config/visium/visium.c	(working copy)
@@ -1626,8 +1626,8 @@ visium_gimplify_va_arg (tree valist, tre
  7:   {
  8: bytes = 0;
  9: addr_rtx = ovfl;
- 10: ovfl += rsize;
- 11:   }
+ 10:ovfl += rsize;
+ 11:  }
 
*/
 
@@ -1691,6 +1691,16 @@ visium_gimplify_va_arg (tree valist, tre
   gimplify_and_add (t, pre_p);
   t = build1 (LABEL_EXPR, void_type_node, lab_over);
   gimplify_and_add (t, pre_p);
+
+  /* Emit a big-endian correction if size < UNITS_PER_WORD.  */
+  if (size < UNITS_PER_WORD)
+{
+  t = build2 (POINTER_PLUS_EXPR, TREE_TYPE (addr), addr,
+		  size_int (UNITS_PER_WORD - size));
+  t = build2 (MODIFY_EXPR, void_type_node, addr, t);
+  gimplify_and_add (t, pre_p);
+}
+
   addr = fold_convert (ptrtype, addr);
 
   return build_va_arg_indirect_ref (addr);
@@ -2848,6 +2858,9 @@ visium_select_cc_mode (enum rtx_code cod
 case CONST_INT:
   /* This is a degenerate case, typically an uninitialized variable.  */
   gcc_assert (op0 == constm1_rtx);
+
+  /* ... fall through ... */
+
 case REG:
 case AND:
 case IOR:

[PATCH 3/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

[Denys Vlasenko]

falign-functions=N is too simplistic.

Ingo Molnar ran some tests and it seems that on latest x86 CPUs, 64-byte 
alignment
of functions runs fastest (he tried many other possibilites):
this way, after a call CPU can fetch a lot of insns in the first cacheline fill.

However, developers are less than thrilled by the idea of a slam-dunk 64-byte
aligning everything. Too much waste:
On 05/20/2015 02:47 AM, Linus Torvalds wrote:
> At the same time, I have to admit that I abhor a 64-byte function
> alignment, when we have a fair number of functions that are (much)
> smaller than that.
>
> Is there some way to get gcc to take the size of the function into
> account? Because aligning a 16-byte or 32-byte function on a 64-byte
> alignment is just criminally nasty and wasteful.

This change makes it possible to align functions to 64-byte boundaries *if*
this does not introduce huge amount of padding.

Example syntax is -falign-functions=64,9: "align to 64 by skipping up to
9 bytes (not inclusive)". IOW: "after a call insn, CPU will always be able
to fetch at least 9 bytes of insns".

x86 had a tweak: -falign-functions=N with N > 8 was adding secondary alignment.
For example, falign-functions=10 was emitting this before every function:
.p2align 4,,9
.p2align 3
This tweak was removed by the previous patch. Now it is reinstated
by the logic that if falign-functions=N[,M] is specified and N > 8,
then default value of N2 is 8, not 1. Now this can be suppressed by
falign-functions=N,M,1 - which wasn't possible before.
In general, optional N2,M2 pair can be used to generate any secondary
alignment user wants.

Subalignment for loops/jumps/labels are trickier to fully implement.
The implementation in this patch uses falign-labels subalignment values
for any of these three types of labels - but only if "main" alignment
triggers. With -O2 defaults, this provides a matching behavior on x86:
loops and jumps are aligned (to 16-32 bytes depending on selected CPU)
and subaligned to 8 bytes. Labels are not aligned.

Testing:

Tested that with -falign-functions=N (tried 8, 15, 16, 17...) the alignment
directives are the same before and after the patch.
Tested that -falign-functions=N,N (two equal parameters) works exactly
like -falign-functions=N.

No change from past behavior:
Tested that "-falign-functions" uses an arch-dependent alignment.
Tested that "-O2" uses an arch-dependent alignment.
Tested that "-O2 -falign-functions=N" uses explicitly given alignment.

2016-09-27  Denys Vlasenko  

* doc/invoke.texi: Update option documentation.
* common.opt (-falign-functions=): Accept a string instead of integer.
(-falign-jumps=): Likewise.
(-falign-labels=): Likewise.
(-falign-loops=): Likewise.
* flags.h (struct target_flag_state): Revamp how alignment data is stored:
for each of four alignment types, store two pairs of log/maxskip values.
* toplev.c (read_uint): New function.
(read_log_maxskip): New function.
(parse_N_M): New function.
(init_alignments): Rename to parse_alignment_opts, make globally visible.
Set align_foo[0/1].log/maxskip from
specified falign-FOO=N[,M[,N[,M]]] options.
* toplev.h (parse_alignment_opts): Now globally visible.
(min_align_loops_log): Variable which holds arch override for minimal
alignment of loops.
(min_align_jumps_log): Likewise for jumps.
(min_align_labels_log): Likewise for labels.
(min_align_functions_log): Likewise for functions.
* varasm.c (assemble_start_function): Call two ASM_OUTPUT_MAX_SKIP_ALIGN
macros, first for N,M and second time for N2,M2 from
falign-functions=N,M,N2,M2. This generates 0, 1, or 2 align directives.
* final.c (final_scan_insn): If a label, jump or loop target
is being aligned, emit a secondary alignment directive.
* config/i386/i386.c (struct ptt): Change foo_align members from
integers to strings. Add align_label member. Set it to "0,0,8"
on the processors which have maxskips > 7 for loops and jumps -
this preserves existing behaviout of adding 8-byte subalign.
* config/i386/i386.c (processor_target_table): Likewise.
* config/aarch64/aarch64-protos.h (struct tune_params):
Change foo_align members from integers to strings.
* config/aarch64/aarch64.c (_tunings):
Change foo_align field values from integers to strings.
* config/arm/arm.c (arm_override_options_after_change_1):
Fix if() condition to detect that -falign-functions is specified,
change code which sets arch-default alignment.
* config/i386/i386.c (ix86_default_align): Likewise.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Likewise.
* config/mips/mips.c (mips_set_compression_mode): Likewise.
* config/alpha/alpha.c (alpha_override_options_after_change): Likewise.
* config/visium/visium.c (visium_option_override): Likewise.
* 

[PATCH 0/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]] version 4

[Denys Vlasenko]

These patches are for this bug:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
"RFE: extend -falign-xyz syntax"

The test program:

int g();
int f(int i) {
i *= 3;
while (--i > 100) {
 L1:if (g()) goto L1;
if (g()) goto L2;
}
return i;
 L2:return 123;
}

"-O2" assembly before the patch:After the patch:
.text   .text
.p2align 4,,15  .p2align 4
.globl  f   .globl  f
.type   f, @function.type   f, @function
f:  f:
.LFB0:  .LFB0:
pushq   %rbxpushq   %rbx
leal(%rdi,%rdi,2), %ebx leal(%rdi,%rdi,2), %ebx
.p2align 4,,10  .p2align 4,,10
.p2align 3  .p2align 3
.L2:.L2:
subl$1, %ebxsubl$1, %ebx
cmpl$100, %ebx  cmpl$100, %ebx
jle .L1 jle .L1
.p2align 4,,10  .p2align 4,,10
.p2align 3  .p2align 3
.L3:.L3:
xorl%eax, %eax  xorl%eax, %eax
callg   callg
testl   %eax, %eax  testl   %eax, %eax
jne .L3 jne .L3
callg   callg
testl   %eax, %eax  testl   %eax, %eax
je  .L2 je  .L2
movl$123, %ebx  movl$123, %ebx
.L4:.L4:
.L1:.L1:
movl%ebx, %eax  movl%ebx, %eax
popq%rbxpopq%rbx
ret ret

This is version 6 of the patch set.

Bernd asked to replace use of a new SUBALIGN_LOG define with a hook.
Don't see an easy way to do that (short of adding a dedicated hook),
for now retained SUBALIGN_LOG method. Suggestions welcome.

Changes since version 5:

* Changes in rs6000, mips, alpha, visium, sh, rx, spu to accomodate
  new alignment options.
* Explicitly list secondary alignment of 8 ("n,m,8") in x86 tables
  for all types of jump targets.

Changes since version 4:

* Deleted rather than NOPed -malign-foo=N support.
* Improved behavior match with x86 8-byte subalignment for labels.

Changes since version 3:

* Improved documentation in invoke.texi
* Fixed x86-specific calculation of default N2 value:
  previous version was doing it incorrectly for cross-compile

[PATCH 2/3] Temporary remove "at least 8 byte alignment" code from x86

[Denys Vlasenko]

This change drops forced alignment to 8 if requested alignment is higher
than 8: before the patch, -falign-functions=9 was generating

.p2align 4,,8
.p2align 3

which means: "align to 16 if the skip is 8 bytes or less; else align to 8".
After this change, ".p2align 3" is not emitted.

This behavior will be implemented differently by the next patch.

The new SUBALIGN_LOG define will be used by the next patch.

While we are here, avoid generating ".p2align N,,2^N-1" -
it is functionally equivalent to ".p2align N". In this case, use the latter.

2016-09-27  Denys Vlasenko  

* config/i386/dragonfly.h: (ASM_OUTPUT_MAX_SKIP_ALIGN):
Use a simpler align directive also if MAXSKIP = ALIGN-1.
* config/i386/gas.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.
* config/i386/lynx.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.
* config/i386/netbsd-elf.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.
* config/i386/i386.h (ASM_OUTPUT_MAX_SKIP_PAD): Likewise.
* config/i386/freebsd.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Remove "If N
is large, do at least 8 byte alignment" code. Add SUBALIGN_LOG
define. Use a simpler align directive also if MAXSKIP = ALIGN-1.
* config/i386/gnu-user.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.
* config/i386/iamcu.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.
* config/i386/openbsdelf.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.
* config/i386/x86-64.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.

Index: gcc/config/i386/dragonfly.h
===
--- gcc/config/i386/dragonfly.h (revision 239860)
+++ gcc/config/i386/dragonfly.h (working copy)
@@ -69,10 +69,12 @@ see the files COPYING3 and COPYING.RUNTIME respect
 
 #ifdef HAVE_GAS_MAX_SKIP_P2ALIGN
 #undef  ASM_OUTPUT_MAX_SKIP_ALIGN
-#define ASM_OUTPUT_MAX_SKIP_ALIGN(FILE, LOG, MAX_SKIP) 
\
-  if ((LOG) != 0) {
\
-if ((MAX_SKIP) == 0) fprintf ((FILE), "\t.p2align %d\n", (LOG));   \
-else fprintf ((FILE), "\t.p2align %d,,%d\n", (LOG), (MAX_SKIP));   \
+#define ASM_OUTPUT_MAX_SKIP_ALIGN(FILE, LOG, MAX_SKIP) \
+  if ((LOG) != 0) {\
+if ((MAX_SKIP) == 0 || (MAX_SKIP) >= (1<<(LOG))-1) \
+  fprintf ((FILE), "\t.p2align %d\n", (LOG));  \
+else   \
+  fprintf ((FILE), "\t.p2align %d,,%d\n", (LOG), (MAX_SKIP));  \
   }
 #endif
 
Index: gcc/config/i386/freebsd.h
===
--- gcc/config/i386/freebsd.h   (revision 239860)
+++ gcc/config/i386/freebsd.h   (working copy)
@@ -92,9 +92,9 @@ along with GCC; see the file COPYING3.  If not see
 
 /* A C statement to output to the stdio stream FILE an assembler
command to advance the location counter to a multiple of 1<= (1<<(LOG))-1)   \
+   fprintf ((FILE), "\t.p2align %d\n", (LOG)); \
+  else \
fprintf ((FILE), "\t.p2align %d,,%d\n", (LOG), (MAX_SKIP)); \
-   /* Make sure that we have at least 8 byte alignment if > 8 byte \
-  alignment is preferred.  */  \
-   if ((LOG) > 3   \
-   && (1 << (LOG)) > ((MAX_SKIP) + 1)  \
-   && (MAX_SKIP) >= 7) \
- fputs ("\t.p2align 3\n", (FILE)); \
-  }
\
 }  \
   } while (0)
 #endif
Index: gcc/config/i386/gas.h
===
--- gcc/config/i386/gas.h   (revision 239860)
+++ gcc/config/i386/gas.h   (working copy)
@@ -72,10 +72,12 @@ along with GCC; see the file COPYING3.  If not see
 
 #ifdef HAVE_GAS_MAX_SKIP_P2ALIGN
 #  define ASM_OUTPUT_MAX_SKIP_ALIGN(FILE,LOG,MAX_SKIP) \
- if ((LOG) != 0) {\
-   if ((MAX_SKIP) == 0) fprintf ((FILE), "\t.p2align %d\n", (LOG)); \
-   else fprintf ((FILE), "\t.p2align %d,,%d\n", (LOG), (MAX_SKIP)); \
- }
+if ((LOG) != 0) { \
+  if ((MAX_SKIP) == 0 || (MAX_SKIP) >= (1<<(LOG))-1)   \
+   fprintf ((FILE), "\t.p2align %d\n", (LOG)); \
+  else \
+   fprintf ((FILE), "\t.p2align %d,,%d\n", (LOG), (MAX_SKIP)); \
+}
 #endif
 
 /* A C statement or statements which output an assembler instruction
Index: gcc/config/i386/gnu-user.h
===
--- 

[PATCH 1/3] Remove support for obsolete x86 -malign-foo options

[Denys Vlasenko]

2016-09-27  Denys Vlasenko  

* config/i386/i386-common.c (ix86_handle_option): Remove support
for obsolete -malign-loops, -malign-jumps and -malign-functions
options.
* config/i386/i386.opt: Likewise.

Index: gcc/common/config/i386/i386-common.c
===
--- gcc/common/config/i386/i386-common.c(revision 240663)
+++ gcc/common/config/i386/i386-common.c(working copy)
@@ -998,38 +998,6 @@ ix86_handle_option (struct gcc_options *opts,
}
   return true;
 
-
-  /* Comes from final.c -- no real reason to change it.  */
-#define MAX_CODE_ALIGN 16
-
-case OPT_malign_loops_:
-  warning_at (loc, 0, "-malign-loops is obsolete, use -falign-loops");
-  if (value > MAX_CODE_ALIGN)
-   error_at (loc, "-malign-loops=%d is not between 0 and %d",
- value, MAX_CODE_ALIGN);
-  else
-   opts->x_align_loops = 1 << value;
-  return true;
-
-case OPT_malign_jumps_:
-  warning_at (loc, 0, "-malign-jumps is obsolete, use -falign-jumps");
-  if (value > MAX_CODE_ALIGN)
-   error_at (loc, "-malign-jumps=%d is not between 0 and %d",
- value, MAX_CODE_ALIGN);
-  else
-   opts->x_align_jumps = 1 << value;
-  return true;
-
-case OPT_malign_functions_:
-  warning_at (loc, 0,
- "-malign-functions is obsolete, use -falign-functions");
-  if (value > MAX_CODE_ALIGN)
-   error_at (loc, "-malign-functions=%d is not between 0 and %d",
- value, MAX_CODE_ALIGN);
-  else
-   opts->x_align_functions = 1 << value;
-  return true;
-
 case OPT_mbranch_cost_:
   if (value > 5)
{
Index: gcc/config/i386/i386.opt
===
--- gcc/config/i386/i386.opt(revision 240663)
+++ gcc/config/i386/i386.opt(working copy)
@@ -205,18 +205,6 @@ malign-double
 Target Report Mask(ALIGN_DOUBLE) Save
 Align some doubles on dword boundary.
 
-malign-functions=
-Target RejectNegative Joined UInteger
-Function starts are aligned to this power of 2.
-
-malign-jumps=
-Target RejectNegative Joined UInteger
-Jump targets are aligned to this power of 2.
-
-malign-loops=
-Target RejectNegative Joined UInteger
-Loop code aligned to this power of 2.
-
 malign-stringops
 Target RejectNegative Report InverseMask(NO_ALIGN_STRINGOPS, ALIGN_STRINGOPS) 
Save
 Align destination of the string operations.

Re: [PATCH] 77864 Fix noexcept conditions for map/set default constructors

[François Dumont]

On 10/10/2016 23:01, Tim Song wrote:

Trying again...with a few edits.


On Mon, Oct 10, 2016 at 3:24 PM, François Dumont 
wrote:

@@ -602,24 +612,32 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  struct _Rb_tree_impl : public _Node_allocator
  {
_Key_compare _M_key_compare;
-  _Rb_tree_node_base _M_header;
+  _Rb_header_node _M_header;
+#if __cplusplus < 201103L
size_type _M_node_count; // Keeps track of size of tree.
+#else
+  size_type _M_node_count = 0; // Keeps track of size of tree.
+#endif

+#if __cplusplus < 201103L
_Rb_tree_impl()
-  : _Node_allocator(), _M_key_compare(), _M_header(),
-_M_node_count(0)
-  { _M_initialize(); }
+  : _M_node_count(0)
+  { }
+#else
+  _Rb_tree_impl() = default;
+#endif


The default constructor of the associative containers is required to
value-initialize the comparator (see their synopses in
[map/set/multimap/multiset.overview]).
I don't have latest Standard version so can't see the exact word but I 
find quite annoying that the Standard doesn't allow this simple 
implementation.


I don't know if unodered containers have same kind of requirements for 
equal or hash functors but if so current implementation doesn't do this 
value initialization.


So here is another attempt. This time it simply allows to have noexcept 
condition in one place and closer to where operations are being invoked.


Ok to commit after tests ?

François


  _Rb_tree_impl() = default; doesn't do that; it default-initializes the
  comparator instead.

Tim



diff --git a/libstdc++-v3/include/bits/stl_map.h b/libstdc++-v3/include/bits/stl_map.h
index e5b2a1b..dea7d5b 100644
--- a/libstdc++-v3/include/bits/stl_map.h
+++ b/libstdc++-v3/include/bits/stl_map.h
@@ -167,11 +167,11 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   /**
*  @brief  Default constructor creates no elements.
*/
-  map()
-  _GLIBCXX_NOEXCEPT_IF(
-	  is_nothrow_default_constructible::value
-	  && is_nothrow_default_constructible::value)
-  : _M_t() { }
+#if __cplusplus < 201103L
+  map() : _M_t() { }
+#else
+  map() = default;
+#endif
 
   /**
*  @brief  Creates a %map with no elements.
diff --git a/libstdc++-v3/include/bits/stl_multimap.h b/libstdc++-v3/include/bits/stl_multimap.h
index d240427..7e86b76 100644
--- a/libstdc++-v3/include/bits/stl_multimap.h
+++ b/libstdc++-v3/include/bits/stl_multimap.h
@@ -164,11 +164,11 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   /**
*  @brief  Default constructor creates no elements.
*/
-  multimap()
-  _GLIBCXX_NOEXCEPT_IF(
-	  is_nothrow_default_constructible::value
-	  && is_nothrow_default_constructible::value)
-  : _M_t() { }
+#if __cplusplus < 201103L
+  multimap() : _M_t() { }
+#else
+  multimap() = default;
+#endif
 
   /**
*  @brief  Creates a %multimap with no elements.
diff --git a/libstdc++-v3/include/bits/stl_multiset.h b/libstdc++-v3/include/bits/stl_multiset.h
index cc068a9..7fe2fbd 100644
--- a/libstdc++-v3/include/bits/stl_multiset.h
+++ b/libstdc++-v3/include/bits/stl_multiset.h
@@ -144,11 +144,11 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   /**
*  @brief  Default constructor creates no elements.
*/
-  multiset()
-  _GLIBCXX_NOEXCEPT_IF(
-	  is_nothrow_default_constructible::value
-	  && is_nothrow_default_constructible::value)
-  : _M_t() { }
+#if __cplusplus < 201103L
+  multiset() : _M_t() { }
+#else
+  multiset() = default;
+#endif
 
   /**
*  @brief  Creates a %multiset with no elements.
diff --git a/libstdc++-v3/include/bits/stl_set.h b/libstdc++-v3/include/bits/stl_set.h
index 3938351..5ed9672 100644
--- a/libstdc++-v3/include/bits/stl_set.h
+++ b/libstdc++-v3/include/bits/stl_set.h
@@ -147,11 +147,11 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   /**
*  @brief  Default constructor creates no elements.
*/
-  set()
-  _GLIBCXX_NOEXCEPT_IF(
-	  is_nothrow_default_constructible::value
-	  && is_nothrow_default_constructible::value)
-  : _M_t() { }
+#if __cplusplus < 201103L
+  set() : _M_t() { }
+#else
+  set() = default;
+#endif
 
   /**
*  @brief  Creates a %set with no elements.
diff --git a/libstdc++-v3/include/bits/stl_tree.h b/libstdc++-v3/include/bits/stl_tree.h
index ee2dc70..b6a3c1e 100644
--- a/libstdc++-v3/include/bits/stl_tree.h
+++ b/libstdc++-v3/include/bits/stl_tree.h
@@ -137,6 +137,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 }
   };
 
+  struct _Rb_header_node : public _Rb_tree_node_base
+  {
+_Rb_header_node() _GLIBCXX_NOEXCEPT
+{
+  _M_color = _S_red;
+  _M_parent = _Base_ptr();
+  _M_left = _M_right = this;
+}
+  };
+
   template
 struct _Rb_tree_node : public _Rb_tree_node_base
 {
@@ -602,24 +612,34 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 struct _Rb_tree_impl : public _Node_allocator
 {
 	  _Key_compare		_M_key_compare;
-	  _Rb_tree_node_base 	_M_header;
+	  _Rb_header_node 	

[PATCH] Tweaks to print_rtx_function

[David Malcolm]

On Wed, 2016-10-12 at 19:31 +0200, Bernd Schmidt wrote:
> On 10/12/2016 07:48 PM, David Malcolm wrote:

[...snip...]

> > I think the only remaining item from our discussion above is what
> > to do
> > about the numbering of pseudos in the dumps (currently it just
> > prints the regno
> > unmodified).
> >
> > Other than that, is the resultant dump format good enough that I
> > can start
> > rewriting the RTL frontend parser, or are there other changes you'd
> > want?
>
> Give me a day or two to think it over, and for others to chime in.
> But I
> think this is reasonably close to what it should look like. Maybe
> empty
> edge flags don't need to be printed, and possibly there could be a
> more
> compact format for a large number edges like what you have for the
> switch?

[...snip...]

This patch implements:
* the renumbering of non-virtual pseudos, using
  LAST_VIRTUAL_REGISTER + 1 as a base.
* omitting the edge "(flags)" directive if there aren't any

Bootstrap & regrtest in progress.

OK for trunk if they pass?

gcc/ChangeLog:
* print-rtl-function.c (print_edge): Omit "(flags)" when none are
set.
* print-rtl.c (print_rtx_operand_code_r): In compact mode, print
pseudos offset by (LAST_VIRTUAL_REGISTER + 1), so that the first
non-virtual pseudo is 0.
---
 gcc/print-rtl-function.c | 13 +
 gcc/print-rtl.c  |  8 
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/gcc/print-rtl-function.c b/gcc/print-rtl-function.c
index 90a0ff7..770cee3 100644
--- a/gcc/print-rtl-function.c
+++ b/gcc/print-rtl-function.c
@@ -59,9 +59,11 @@ print_edge (FILE *outfile, edge e, bool from)
 
   /* Express edge flags as a string with " | " separator.
  e.g. (flags "FALLTHRU | DFS_BACK").  */
-  fprintf (outfile, " (flags \"");
-  bool seen_flag = false;
-#define DEF_EDGE_FLAG(NAME,IDX) \
+  if (e->flags)
+{
+  fprintf (outfile, " (flags \"");
+  bool seen_flag = false;
+#define DEF_EDGE_FLAG(NAME,IDX)\
   do { \
 if (e->flags & EDGE_##NAME)\
   {\
@@ -74,7 +76,10 @@ print_edge (FILE *outfile, edge e, bool from)
 #include "cfg-flags.def"
 #undef DEF_EDGE_FLAG
 
-  fprintf (outfile, "\"))\n");
+  fprintf (outfile, "\")");
+}
+
+  fprintf (outfile, ")\n");
 }
 
 /* If BB is non-NULL, print the start of a "(block)" directive for it
diff --git a/gcc/print-rtl.c b/gcc/print-rtl.c
index f114cb4..86816b5 100644
--- a/gcc/print-rtl.c
+++ b/gcc/print-rtl.c
@@ -400,6 +400,14 @@ print_rtx_operand_code_r (const_rtx in_rtx)
 #endif
 if (flag_dump_unnumbered && is_insn)
   fputc ('#', outfile);
+else if (flag_compact)
+  {
+   /* In compact mode, print pseudos offset by
+  (LAST_VIRTUAL_REGISTER + 1), so that the first non-virtual pseudo
+  is dumped as 0.  */
+   gcc_assert (regno > LAST_VIRTUAL_REGISTER);
+   fprintf (outfile, " %d", regno - (LAST_VIRTUAL_REGISTER + 1));
+  }
 else
   fprintf (outfile, " %d", regno);
 
-- 
1.8.5.3

[PATCH] (v2) Add a "compact" mode to print_rtx_function

[David Malcolm]

On Wed, 2016-10-12 at 19:31 +0200, Bernd Schmidt wrote:
> On 10/12/2016 07:48 PM, David Malcolm wrote:
> > This patch implements a "compact" mode for print_rtx_function,
> > implementing most of the ideas above.
> > 
> > Example of output can be seen here:
> >   https://dmalcolm.fedorapeople.org/gcc/2016-10-12/test-switch-comp
> > act.rtl
> > which can be contrasted with the non-compact output here:
> >   https://dmalcolm.fedorapeople.org/gcc/2016-10-12/test-switch-nonc
> > ompact.rtl
> > 
> > It adds the "c" prefix to the insn names, so we get "cinsn", etc. 
> >  However,
> > it does lead to things like this:
> > 
> >(ccode_label 56 8 "")
> > 
> > which gives me pause: would the "ccode" in "ccode_label" be
> > confusing? (compared
> > to "ccmode").  An alternative might be to have a "compact-insn
> > -chain" vs
> > "insn-chain" wrapper element, expressing that this is a compact
> > dump.
> 
> Maybe "clabel" or something.

I've special-cased it to be "clabel" rather than "ccode_label".

> > OK for trunk if it passes?
> 
> I'd say yes - we're iterating and this seems to be an improvement.

It didn't pass, due to this change:

 (print_rtx_operand_code_i): When printing source locations, wrap
 xloc.file in quotes. [...snip...]

Note that this change isn't guarded by flag_compact; it affects all
dumps, which meant that this testcase stopped working:
  gcc.target/i386/vararg-loc.c
which used scan-rtl-dump to look for the insn location.

I had a look over the testsuite looking for other scan-rtl-dump
directives that could be affected by the change, and I didn't see any
though obviously I could have missed some.

The following is a revised version of the patch which updates this test case.

> > I think the only remaining item from our discussion above is what
> > to do
> > about the numbering of pseudos in the dumps (currently it just
> > prints the regno
> > unmodified).
> > 
> > Other than that, is the resultant dump format good enough that I
> > can start
> > rewriting the RTL frontend parser, or are there other changes you'd
> > want?
> 
> Give me a day or two to think it over, and for others to chime in.
> But I
> think this is reasonably close to what it should look like. Maybe
> empty
> edge flags don't need to be printed, and possibly there could be a
> more
> compact format for a large number edges like what you have for the
> switch?
> 
> > +  /* For insns, print the INSN_UID.
> > + In compact mode, we only print the INSN_UID of CODE_LABELs. 
> >  */
> > +  if (!flag_compact || GET_CODE (in_rtx) == CODE_LABEL)
> > +if (INSN_CHAIN_CODE_P (GET_CODE (in_rtx)))
> 
> The two ifs should be merged I think.
 
Changed in v2:
- fixes to gcc.target/i386/vararg-loc.c
- "clabel" rather than "ccode_label"
- merged the two "if"s

Successfully bootstrapped on x86_64-pc-linux-gnu.

OK for trunk?

gcc/ChangeLog:
* function-tests.c (selftest::test_expansion_to_rtl): Add "true"
for new "compact" param of print_rtx_function.  Check for "cinsn"
rather than "insn".
* print-rtl-function.c (flag_compact): New decl.
(print_rtx_function): Add param "compact" and use it to set
flag_compact, adding a description of the effect to the leading
comment, and updating the example output.
* print-rtl.c (flag_compact): New variable.
(print_rtx_operand_code_0): Omit the JUMP_LABEL reference in compact
mode.
(print_rtx_operand_code_i): When printing source locations, wrap
xloc.file in quotes.  Don't print INSN_CODEs in compact mode.
(print_rtx_operand_code_r): Don't print regnos for hard regs and
virtuals in compact mode.
(print_rtx_operand_code_u): Don't print insn UIDs in compact mode,
apart from in LABEL_REFs.
(print_rtx_operand): In case 'w', don't print in hex in compact mode.
Don't print basic block ids in compact mode.
(print_rtx):  In compact mode, prefix the code of insns with "c",
only print the INSN_UID of CODE_LABELs, and omit their LABEL_NUSES.
* print-rtl.h (print_rtx_function): Add "compact" param.

gcc/testsuite/ChangeLog:
* gcc.target/i386/vararg-loc.c: Update for quoting of xloc.file
in INSN_LOCATION.
---
 gcc/function-tests.c   |  4 +-
 gcc/print-rtl-function.c   | 76 +-
 gcc/print-rtl.c| 73 +---
 gcc/print-rtl.h|  2 +-
 gcc/testsuite/gcc.target/i386/vararg-loc.c |  6 +--
 5 files changed, 107 insertions(+), 54 deletions(-)

diff --git a/gcc/function-tests.c b/gcc/function-tests.c
index 049a07f9..b0c44cf 100644
--- a/gcc/function-tests.c
+++ b/gcc/function-tests.c
@@ -648,7 +648,7 @@ test_expansion_to_rtl ()
   /* Verify that print_rtl_function is sane.  */
   named_temp_file tmp_out (".rtl");
   FILE *outfile = fopen (tmp_out.get_filename (), "w");
-  print_rtx_function (outfile, 

Re: [PATCH] [ARC] New option handling, refurbish multilib support.

[Andrew Burgess]

* Claudiu Zissulescu  [2016-10-10 15:26:47 
+0200]:

> Hi Andrew,
> 
> This is updated patch of the original sent to mailing list some while ago.
> 
> What is new:
>  - Do not use MULTILIB_REUSE as its semantic changed, and the old one was 
> causing issues while building.
>  - Update invoke.texi documentation adding nps400 option to mcpu.
> 
> This patch is important as it changes the way how we handle CPU
> variations and multilib support. It will be great if you can include
> this patch on your review list before any other one.

Sorry it's taken s long to review this patch.

In general I like this, and think it's a step in the right direction.
I have a few pretty minor concerns, but hopefully nothing too
contentious.

In general I like the use of the *.def files, but my only concern is
the lack of explanation in any of them about what they're for.  It
would be nice if each had a summary of what each field represents to
make it easier to add new entries.

The use of arc_seen_options can, I think be replaced by using
global_opts_seen.x_target_flags, or maybe there's a detail I'm not
understanding, in which case maybe a comment somewhere to explain why
those two things are different.

The only thing I dislike in this patch is the switch from 'arc_cpu' to
a set of global boolean flags.  I can't see why we'd ever want more
than one of those architecture flags to be true, so I'd rather we
switched back to an enum if that's possible.

[ I've left my review comments in line below too, but the above is a
summary of everything, there's nothing additional below. ]

Thanks,
Andrew

> 
> Thanks,
> Claudiu
> 
> gcc/
> 2016-05-09  Claudiu Zissulescu  
> 
>   * config/arc/arc-arch.h: New file.
>   * config/arc/arc-arches.def: Likewise.
>   * config/arc/arc-cpus.def: Likewise.
>   * config/arc/arc-options.def: Likewise.
>   * config/arc/t-multilib: Likewise.
>   * config/arc/genmultilib.awk: Likewise.
>   * config/arc/genoptions.awk: Likewise.
>   * config/arc/arc-tables.opt: Likewise.
>   * config/arc/driver-arc.c: Likewise.
>   * common/config/arc/arc-common.c (arc_handle_option): Trace
>   toggled options.
>   * config.gcc (arc*-*-*): Add arc-tables.opt to arc's extra
>   options; check for supported cpu against arc-cpus.def file.
>   (arc*-*-elf*, arc*-*-linux-uclibc*): Use new make fragment; define
>   TARGET_CPU_BUILD macro; add driver-arc.o as an extra object.
>   * config/arc/arc-c.def: Add emacs local variables.
>   * config/arc/arc-opts.h (processor_type): Use arc-cpus.def file.
>   (FPU_FPUS, FPU_FPUD, FPU_FPUDA, FPU_FPUDA_DIV, FPU_FPUDA_FMA)
>   (FPU_FPUDA_ALL, FPU_FPUS_DIV, FPU_FPUS_FMA, FPU_FPUS_ALL)
>   (FPU_FPUD_DIV, FPU_FPUD_FMA, FPU_FPUD_ALL): New defines.
>   (DEFAULT_arc_fpu_build): Define.
>   (DEFAULT_arc_mpy_option): Define.
>   * config/arc/arc-protos.h (arc_init): Delete.
>   * config/arc/arc.c (arc_cpu_name): New variable.
>   (arc_selected_cpu, arc_selected_arch, arc_arcem, arc_archs)
>   (arc_arc700, arc_arc600, arc_arc601): New variable.
>   (arc_init): Add static; remove selection of default tune value,
>   cleanup obsolete error messages.
>   (arc_override_options): Make use of .def files for selecting the
>   right cpu and option configurations.
>   * config/arc/arc.h (stdbool.h): Include.
>   (TARGET_CPU_DEFAULT): Define.
>   (CPP_SPEC): Remove mcpu=NPS400 handling.
>   (arc_cpu_to_as): Declare.
>   (EXTRA_SPEC_FUNCTIONS): Define.
>   (OPTION_DEFAULT_SPECS): Likewise.
>   (ASM_DEFAULT): Remove.
>   (ASM_SPEC): Use arc_cpu_to_as.
>   (DRIVER_SELF_SPECS): Remove deprecated options.
>   (arc_arc700, arc_arc600, arc_arc601, arc_arcem, arc_archs):
>   Declare.
>   (TARGET_ARC600, TARGET_ARC601, TARGET_ARC700, TARGET_EM)
>   (TARGET_HS, TARGET_V2, TARGET_ARC600): Make them use arc_arc*
>   variables.
>   (MULTILIB_DEFAULTS): Use ARC_MULTILIB_CPU_DEFAULT.
>   * config/arc/arc.md (attr_cpu): Remove.
>   * config/arc/arc.opt (arc_mpy_option): Make it target variable.
>   (mno-mpy): Deprecate.
>   (mcpu=ARC600, mcpu=ARC601, mcpu=ARC700, mcpu=NPS400, mcpu=ARCEM)
>   (mcpu=ARCHS): Remove.
>   (mcrc, mdsp-packa, mdvbf, mmac-d16, mmac-24, mtelephony, mrtsc):
>   Deprecate.
>   (mbarrel_shifte, mspfp_, mdpfp_, mdsp_pack, mmac_): Remove.
>   (arc_fpu): Use new defines.
>   (arc_seen_options): New target variable.
>   * config/arc/t-arc (driver-arc.o): New target.
>   (arc-cpus, t-multilib, arc-tables.opt): Likewise.
>   * config/arc/t-arc-newlib: Delete.
>   * config/arc/t-arc-uClibc: Renamed to t-uClibc.
>   * doc/invoke.texi (ARC): Update arc options.
> ---
>  gcc/common/config/arc/arc-common.c | 162 -
>  gcc/config.gcc |  47 +
>  

Re: [PATCH, GCC] Move MEMMODEL_* and enum memmodel from coretypes.h to memmodel.h

[Joseph Myers]

On Wed, 12 Oct 2016, Thomas Preudhomme wrote:

> This patch is a follow up of [1] which aims to have all memory model related
> declarations in memmodel.h. To achieve that, this patch moves memory model
> related declaration from coretypes.h into memmodel.h. Note that since
> memmodel.h is now included from libgcc it needs to have a runtime library
> exception.

I think libgcc should be using the __ATOMIC_* predefines instead of the 
MEMMODEL_* host-side constants.  (In general, we should be moving away 
from including host-side headers in target-side code.)

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

Re: [PATCH] Implement new hook for max_align_t_align

[Carlos O'Donell]

On 10/12/2016 10:17 AM, John David Anglin wrote:
> On 2016-10-12 9:48 AM, Jason Merrill wrote:
>> On Wed, Oct 12, 2016 at 4:02 AM, Jakub Jelinek  wrote:
>>> On Wed, Oct 12, 2016 at 09:52:04AM +0200, Florian Weimer wrote:
 dropping the alignment means that the padding before the lock member
 vanishes.  Consequently, we have just created a silent ABI change in
 application code, which is a big no-no.
>>> Sure, it would be an ABI change, but how many users would it affect?
>>>
 Since this is PA-RISC, which is essentially dead (neither HPE nor Debian
 ship it anymore), I stand by my suggestion to bump the fundamental 
 alignment
>>> Or just drop support for a dead arch?
>>>
 instead.  Sure, it is a bit inefficient, but this will only affect PA-RISC
 users.  It does not even cause work for PA-RISC porters. Conversely, if we
 work on this to come up with a different fix, many more people will be
 affected (because they don't get all the nice things we could work on
 instead), and we may need to maintain a special GCC kludge for the
 alternative solution, impacting GCC developers in particular.
>>> But sure, bumping malloc alignment is probably easiest.  And people who want
>>> performance have better options than to stay on 32-bit PA-RISC anyway.
>> Or we could do nothing and tell people to ignore the harmless warning.
> The warning is an issue because of -Werror.  However, it appears easy to 
> suppress it in the PA
> backend.  I have a patch that I'm testing.
> 
> We are discussing offline regarding the glibc issue.  It easy to bump the 
> alignment of malloc
> but I take Jakub's point and maybe we should break the ABI.  Debian unstable 
> churns
> quickly, and I think we would be better off being consistent with the current 
> max_align_t
> and 8-byte aligned malloc.

I am against breaking the ABI.

I would rather see us bump malloc alignment up to 16-bytes.

The last time I changed this alignment it _immediately_ broken libstdc++ 
boostrap
because it's using exactly the kind of embedded pthread_mutext_t we're talking 
about
breaking.

So in that case the debian builds in unstable broke right away, and I had to 
revert
the change. We'd have to BinNMU a bunch of things to get this working again.

Again I think our two options are, in my order of preference:

- Disable the warning via a PA backend change.
- Bump malloc alignment.

I am sensitive to the first change being something that carries with it extra
maintenance burden, so I'm happy to see the second solution chosen if that's 
what
everyone wants (Florian's suggestion).

-- 
Cheers,
Carlos.

Re: [RFC] Possible folding opportunities for string built-ins

[Jim Wilson]

On 10/12/2016 08:55 AM, Joseph Myers wrote:

On Wed, 12 Oct 2016, Martin Liška wrote:


Last question is whether one can aggressively fold strcasecmp in a host
compiler? Or are there any situations where results depends on locale?


There are the usual issues with Turkish locales having the uppercase
version of 'i' being 'İ' and the lowercase version of 'I' being 'ı'.


See for instance
  https://en.wikipedia.org/wiki/Dotted_and_dotless_I

Jim

Re: [patch] aarch64-*-freebsd* support for gcc.

[Andreas Tobler]

Hi Jeff,

On 10.10.16 23:10, Jeff Law wrote:

On 10/10/2016 03:07 PM, Andreas Tobler wrote:

Hi all,

the attached patch brings support for the aarch64-*-freebsd* target.

Bootstraped and tested, results on the list. Not that many results due
to board instabilities I lack a cavium ;)

Ok for main? And if yes, how far can I backport? Down to 5.4?

TIA,
Andreas

libgcc:

2016-10-10  Andreas Tobler  

* config.host: Add support for aarch64-*-freebsd*.

gcc:

2016-10-10  Andreas Tobler  

* config.gcc: Add aarch64-*-freebsd* support.
* config.host: Likewise.
* config/aarch64/aarch64-freebsd.h: New file.
* config/aarch64/t-aarch64-freebsd: Ditto.

toplevel:

2016-10-10  Andreas Tobler 

* configure.ac: Add aarch64-*-freebsd*.
* configure: Regenerate.

Certainly OK for the trunk.  Jakub, Richi & Joseph make the rules for
the release branches.


I had a chat with Jakub and I learned as long as there is no branch 
freeze or such, every global reviewer can approve such a patch backport. 
So may I ask you, would you mind approving this patch for 6.x and 5.x?


TIA,
Andreas

Re: New option -flimit-function-alignment

[Denys Vlasenko]

On 10/11/2016 10:14 PM, Bernd Schmidt wrote:

On 10/11/2016 04:23 PM, Denys Vlasenko wrote:


This is better than current behavior, but this is not what I want.

15-byte function does not need to be aligned to 16 bytes on a
machine with 128-byte L1I cachelines. It needs to be aligned to 128
bytes if there are less than 15 bytes remaining; if there are MORE
than 15 bytes remaining, why align at all? It's a waste of space.


So that sounds like you'd want to modify the max_skip value based on
the size of the function - which would be a fairly minor change.


Yes, something like "if max_skip >= func_size, temporarily lower
max_skip to func_size-1" (because otherwise we can create padding
bigger-or-equal to the entire function in size, which is stupid
- it's better to just put the function in that space).

This would be a nice.

Re: [vrp] use get_ptr_nonnull in tree-vrp

[kugan]

Hi Richard,

On 12/10/16 23:24, Richard Biener wrote:

On Wed, Oct 12, 2016 at 8:56 AM, kugan
 wrote:

Hi,

This patch uses get_ptr_nonnull in tree-vrp.

Bootstrapped and regression tested this with other patched without any
new regressions on x86_64-linux-gnu.

Is this OK for trunk?


Um.  Doesn't make much sense given nothing provides this info before EVRP?
And if it makes sense then it makes sense not only for PARM_DECL SSA names.


Not before EVRP. But when in TREE-VRP, EVRP + IPA-VRP should provide this.

I am not sure if this is the question?

Thanks,
Kugan


Richard.


Thanks,
Kugan

gcc/testsuite/ChangeLog:

2016-10-12  Kugan Vivekanandarajah  

* gcc.dg/ipa/vrp4.c: Adjust testcase.

gcc/ChangeLog:

2016-10-12  Kugan Vivekanandarajah  

* tree-vrp.c (get_value_range): Check get_ptr_nonnull.

Re: Questionable code in gcov-io.c

[Nathan Sidwell]

On 10/12/16 11:04, Andreas Schwab wrote:


Do we still need to call fstat?  I don't think it can ever fail here.


Update removing the fstat.  Survived a profiled bootstrap, so I'll commit 
tomorrow, unless there are further comments.  Thanks for spotting this!


nathan


2016-10-12  Nathan Sidwell  

	* gcov-io.c (gcov_open): Fix documentation.  Simplify setting
	gcov_var.mode.  Remove unnecessary fstat.

Index: gcov-io.c
===
--- gcov-io.c	(revision 241027)
+++ gcov-io.c	(working copy)
@@ -115,10 +115,9 @@ static inline gcov_unsigned_t from_file
opened. If MODE is >= 0 an existing file will be opened, if
possible, and if MODE is <= 0, a new file will be created. Use
MODE=0 to attempt to reopen an existing file and then fall back on
-   creating a new one.  If MODE < 0, the file will be opened in
+   creating a new one.  If MODE > 0, the file will be opened in
read-only mode.  Otherwise it will be opened for modification.
-   Return zero on failure, >0 on opening an existing file and <0 on
-   creating a new one.  */
+   Return zero on failure, non-zero on success.  */
 
 GCOV_LINKAGE int
 #if IN_LIBGCOV
@@ -156,17 +155,12 @@ gcov_open (const char *name, int mode)
   /* pass mode (ignored) for compatibility */
   fd = open (name, O_RDONLY, S_IRUSR | S_IWUSR);
 }
-  else if (mode < 0)
+  else
  {
/* Write mode - acquire a write-lock.  */
s_flock.l_type = F_WRLCK;
-  fd = open (name, O_RDWR | O_CREAT | O_TRUNC, 0666);
-}
-  else /* mode == 0 */
-{
-  /* Read-Write mode - acquire a write-lock.  */
-  s_flock.l_type = F_WRLCK;
-  fd = open (name, O_RDWR | O_CREAT, 0666);
+   /* Truncate if force new mode.  */
+   fd = open (name, O_RDWR | O_CREAT | (mode < 0 ? O_TRUNC : 0), 0666);
 }
   if (fd < 0)
 return 0;
@@ -181,42 +175,23 @@ gcov_open (const char *name, int mode)
   close (fd);
   return 0;
 }
-
-  if (mode > 0)
-gcov_var.mode = 1;
-  else if (mode == 0)
-{
-  struct stat st;
-
-  if (fstat (fd, ) < 0)
-	{
-	  fclose (gcov_var.file);
-	  gcov_var.file = 0;
-	  return 0;
-	}
-  if (st.st_size != 0)
-	gcov_var.mode = 1;
-  else
-	gcov_var.mode = mode * 2 + 1;
-}
-  else
-gcov_var.mode = mode * 2 + 1;
 #else
   if (mode >= 0)
+/* Open an existing file.  */
 gcov_var.file = fopen (name, (mode > 0) ? "rb" : "r+b");
 
   if (gcov_var.file)
-gcov_var.mode = 1;
+mode = 1;
   else if (mode <= 0)
-{
-  gcov_var.file = fopen (name, "w+b");
-  if (gcov_var.file)
-	gcov_var.mode = mode * 2 + 1;
-}
+/* Create a new file.  */
+gcov_var.file = fopen (name, "w+b");
+
   if (!gcov_var.file)
 return 0;
 #endif
 
+  gcov_var.mode = mode ? mode : 1;
+
   setbuf (gcov_var.file, (char *)0);
 
   return 1;

Go patch committed: copy string code from Go 1.7 runtime

[Ian Lance Taylor]

This patch to the Go frontend and libgo copies the string code from
the Go 1.7 runtime.  This mainly replaces some C code with Go code.

This adds compiler support for turning concatenating strings into a
call to a runtime function that takes the appropriate number of
arguments.

This renames some local variables in mgc0.c to avoid macros that the
new rune.go causes to appear in runtime.inc.

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 241072)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-c18d9f0e7270144ebd1f67d85995f434bbdab0b0
+f38ba8837a0c961e18d982930e192132870f3836
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/escape.cc
===
--- gcc/go/gofrontend/escape.cc (revision 240942)
+++ gcc/go/gofrontend/escape.cc (working copy)
@@ -1233,13 +1233,17 @@ Escape_analysis_assign::expression(Expre
  case Runtime::MAKESLICE2:
  case Runtime::MAKESLICE1BIG:
  case Runtime::MAKESLICE2BIG:
- case Runtime::BYTE_ARRAY_TO_STRING:
- case Runtime::INT_ARRAY_TO_STRING:
- case Runtime::STRING_TO_BYTE_ARRAY:
- case Runtime::STRING_TO_INT_ARRAY:
- case Runtime::STRING_PLUS:
+ case Runtime::SLICEBYTETOSTRING:
+ case Runtime::SLICERUNETOSTRING:
+ case Runtime::STRINGTOSLICEBYTE:
+ case Runtime::STRINGTOSLICERUNE:
+ case Runtime::CONCATSTRINGS:
+ case Runtime::CONCATSTRING2:
+ case Runtime::CONCATSTRING3:
+ case Runtime::CONCATSTRING4:
+ case Runtime::CONCATSTRING5:
  case Runtime::CONSTRUCT_MAP:
- case Runtime::INT_TO_STRING:
+ case Runtime::INTSTRING:
{
  Node* runtime_node = Node::make_node(fe);
  this->context_->track(runtime_node);
@@ -1842,21 +1846,25 @@ Escape_analysis_assign::assign(Node* dst
  case Runtime::MAKESLICE1BIG:
  case Runtime::MAKESLICE2BIG:
// DST = make(...).
- case Runtime::BYTE_ARRAY_TO_STRING:
+ case Runtime::SLICEBYTETOSTRING:
// DST = string([]byte{...}).
- case Runtime::INT_ARRAY_TO_STRING:
+ case Runtime::SLICERUNETOSTRING:
// DST = string([]int{...}).
- case Runtime::STRING_TO_BYTE_ARRAY:
+ case Runtime::STRINGTOSLICEBYTE:
// DST = []byte(str).
- case Runtime::STRING_TO_INT_ARRAY:
-   // DST = []int(str).
- case Runtime::STRING_PLUS:
+ case Runtime::STRINGTOSLICERUNE:
+   // DST = []rune(str).
+ case Runtime::CONCATSTRINGS:
+ case Runtime::CONCATSTRING2:
+ case Runtime::CONCATSTRING3:
+ case Runtime::CONCATSTRING4:
+ case Runtime::CONCATSTRING5:
// DST = str1 + str2
  case Runtime::CONSTRUCT_MAP:
// When building a map literal's backend representation.
// Likely never seen here and covered in
// Expression::EXPRESSION_MAP_CONSTRUCTION.
- case Runtime::INT_TO_STRING:
+ case Runtime::INTSTRING:
// DST = string(i).
  case Runtime::IFACEE2E2:
  case Runtime::IFACEI2E2:
@@ -2614,13 +2622,17 @@ Escape_analysis_flood::flood(Level level
case Runtime::MAKESLICE2:
case Runtime::MAKESLICE1BIG:
case Runtime::MAKESLICE2BIG:
-   case Runtime::BYTE_ARRAY_TO_STRING:
-   case Runtime::INT_ARRAY_TO_STRING:
-   case Runtime::STRING_TO_BYTE_ARRAY:
-   case Runtime::STRING_TO_INT_ARRAY:
-   case Runtime::STRING_PLUS:
+   case Runtime::SLICEBYTETOSTRING:
+   case Runtime::SLICERUNETOSTRING:
+   case Runtime::STRINGTOSLICEBYTE:
+   case Runtime::STRINGTOSLICERUNE:
+   case Runtime::CONCATSTRINGS:
+   case Runtime::CONCATSTRING2:
+   case Runtime::CONCATSTRING3:
+   case Runtime::CONCATSTRING4:
+   case Runtime::CONCATSTRING5:
case Runtime::CONSTRUCT_MAP:
-   case Runtime::INT_TO_STRING:
+   case Runtime::INTSTRING:
case Runtime::CONVERT_INTERFACE:
  // All runtime calls that 

Re: [PATCH] Implement new hook for max_align_t_align

[John David Anglin]

On 2016-10-12 2:01 PM, Florian Weimer wrote:

On 10/12/2016 06:14 PM, Jeff Law wrote:


If the issue is strictly limited to 32 bit hpux, then do we really care?
 Can we just deprecate that platform and thus make the issue go away?


Are we talking about HP-XX or Linux on PA-RISC?
The patch was intended to address a Linux issue on PA-RISC.  On HP-UX, 
the current

version of max_align_t is fine.

Dave

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

C++ PATCH for c++/77742 (-Waligned-new and placement new)

[Jason Merrill]

It doesn't make sense to warn about placement new of over-aligned
types; most occurrences are likely to be doing this in order to
provide properly aligned memory by allocating it first and then using
the standard non-allocating placement new.

Also, the discussion of -Waligned-new on HPPA led me to think that
even though MALLOC_ABI_ALIGNMENT is oddly low on most targets, some
might define it to be larger than max_align_t_align, and we should
take advantage of that when it occurs.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit fb86b2acf865a283c94fea604843308b3b5ba331
Author: Jason Merrill 
Date:   Tue Oct 11 17:24:05 2016 -0400

PR c++/77742 - -Waligned-new and placement new.
* init.c (build_new_1): Don't -Waligned-new about placement new.
(malloc_alignment): New.  Consider MALLOC_ABI_ALIGNMENT.
* decl.c (cxx_init_decl_processing): New.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 8b0442f..88cae04 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5953,6 +5953,7 @@ extern tree build_offset_ref  (tree, 
tree, bool,
 tsubst_flags_t);
 extern tree throw_bad_array_new_length (void);
 extern bool type_has_new_extended_alignment(tree);
+extern unsigned malloc_alignment   (void);
 extern tree build_new  (vec **, tree, 
tree,
 vec **, int,
  tsubst_flags_t);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 2d11aef..6240893 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -4082,7 +4082,7 @@ cxx_init_decl_processing (void)
   if (aligned_new_threshold == -1)
 aligned_new_threshold = (cxx_dialect >= cxx1z) ? 1 : 0;
   if (aligned_new_threshold == 1)
-aligned_new_threshold = max_align_t_align () / BITS_PER_UNIT;
+aligned_new_threshold = malloc_alignment () / BITS_PER_UNIT;
 
   {
 tree newattrs, extvisattr;
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index b4b5e0a..455995a 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -2589,6 +2589,16 @@ type_has_new_extended_alignment (tree t)
  && TYPE_ALIGN_UNIT (t) > (unsigned)aligned_new_threshold);
 }
 
+/* Return the alignment we expect malloc to guarantee.  This should just be
+   MALLOC_ABI_ALIGNMENT, but that macro defaults to only BITS_PER_WORD for some
+   reason, so don't let the threshold be smaller than max_align_t_align.  */
+
+unsigned
+malloc_alignment ()
+{
+  return MAX (max_align_t_align(), MALLOC_ABI_ALIGNMENT);
+}
+
 /* Generate code for a new-expression, including calling the "operator
new" function, initializing the object, and, if an exception occurs
during construction, cleaning up.  The arguments are as for
@@ -2974,8 +2984,23 @@ build_new_1 (vec **placement, tree type, 
tree nelts,
 
   gcc_assert (alloc_fn != NULL_TREE);
 
+  /* Now, check to see if this function is actually a placement
+ allocation function.  This can happen even when PLACEMENT is NULL
+ because we might have something like:
+
+   struct S { void* operator new (size_t, int i = 0); };
+
+ A call to `new S' will get this allocation function, even though
+ there is no explicit placement argument.  If there is more than
+ one argument, or there are variable arguments, then this is a
+ placement allocation function.  */
+  placement_allocation_fn_p
+= (type_num_arguments (TREE_TYPE (alloc_fn)) > 1
+   || varargs_function_p (alloc_fn));
+
   if (warn_aligned_new
-  && TYPE_ALIGN (elt_type) > max_align_t_align ()
+  && !placement_allocation_fn_p
+  && TYPE_ALIGN (elt_type) > malloc_alignment ()
   && (warn_aligned_new > 1
  || CP_DECL_CONTEXT (alloc_fn) == global_namespace)
   && !aligned_allocation_fn_p (alloc_fn))
@@ -3033,20 +3058,6 @@ build_new_1 (vec **placement, tree type, 
tree nelts,
   while (TREE_CODE (alloc_call) == COMPOUND_EXPR)
 alloc_call = TREE_OPERAND (alloc_call, 1);
 
-  /* Now, check to see if this function is actually a placement
- allocation function.  This can happen even when PLACEMENT is NULL
- because we might have something like:
-
-   struct S { void* operator new (size_t, int i = 0); };
-
- A call to `new S' will get this allocation function, even though
- there is no explicit placement argument.  If there is more than
- one argument, or there are variable arguments, then this is a
- placement allocation function.  */
-  placement_allocation_fn_p
-= (type_num_arguments (TREE_TYPE (alloc_fn)) > 1
-   || varargs_function_p (alloc_fn));
-
   /* Preevaluate the placement args so that we don't reevaluate them for a
  placement delete.  */
   if (placement_allocation_fn_p)
diff --git a/gcc/testsuite/g++.dg/cpp1z/aligned-new7.C 
b/gcc/testsuite/g++.dg/cpp1z/aligned-new7.C
new file 

Re: [PATCH] Implement new hook for max_align_t_align

[Florian Weimer]

On 10/12/2016 06:14 PM, Jeff Law wrote:


If the issue is strictly limited to 32 bit hpux, then do we really care?
 Can we just deprecate that platform and thus make the issue go away?


Are we talking about HP-XX or Linux on PA-RISC?

Thanks,
Florian

Re: libgo patch committed: Fixes for sparc64

[Ian Lance Taylor]

On Wed, Oct 12, 2016 at 7:28 AM, Ian Lance Taylor  wrote:
> This patch to libgo by James Clarke fixes libgo for sparc64.  The
> getrandom syscall was being ignored because the file was named
> "sparc".  The clone syscall apparently needs special attention on
> SPARC.  Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
> Committed to mainline.

And a followup: mark the new rawClone function as no_split_stack.
Bootstrapped and tested on x86_64-pc-linux-gnu, committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 241067)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-7e4543d050339e113e6278fd442d940c0f1a5670
+c18d9f0e7270144ebd1f67d85995f434bbdab0b0
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/syscall/clone_linux.c
===
--- libgo/go/syscall/clone_linux.c  (revision 241051)
+++ libgo/go/syscall/clone_linux.c  (working copy)
@@ -10,7 +10,10 @@
 
 #include "runtime.h"
 
-long rawClone (unsigned long flags, void *child_stack, void *ptid, void *ctid, 
struct pt_regs *regs) __asm__ (GOSYM_PREFIX "syscall.rawClone");
+long rawClone (unsigned long flags, void *child_stack, void *ptid,
+  void *ctid, struct pt_regs *regs)
+  __asm__ (GOSYM_PREFIX "syscall.rawClone")
+  __attribute__ ((no_split_stack));
 
 long
 rawClone (unsigned long flags, void *child_stack, void *ptid, void *ctid, 
struct pt_regs *regs)

Re: [PATCH] Add a "compact" mode to print_rtx_function

[Bernd Schmidt]

On 10/12/2016 07:48 PM, David Malcolm wrote:

This patch implements a "compact" mode for print_rtx_function,
implementing most of the ideas above.

Example of output can be seen here:
  https://dmalcolm.fedorapeople.org/gcc/2016-10-12/test-switch-compact.rtl
which can be contrasted with the non-compact output here:
  https://dmalcolm.fedorapeople.org/gcc/2016-10-12/test-switch-noncompact.rtl

It adds the "c" prefix to the insn names, so we get "cinsn", etc.  However,
it does lead to things like this:

   (ccode_label 56 8 "")

which gives me pause: would the "ccode" in "ccode_label" be confusing? (compared
to "ccmode").  An alternative might be to have a "compact-insn-chain" vs
"insn-chain" wrapper element, expressing that this is a compact dump.


Maybe "clabel" or something.


OK for trunk if it passes?


I'd say yes - we're iterating and this seems to be an improvement.


I think the only remaining item from our discussion above is what to do
about the numbering of pseudos in the dumps (currently it just prints the regno
unmodified).

Other than that, is the resultant dump format good enough that I can start
rewriting the RTL frontend parser, or are there other changes you'd want?


Give me a day or two to think it over, and for others to chime in. But I 
think this is reasonably close to what it should look like. Maybe empty 
edge flags don't need to be printed, and possibly there could be a more 
compact format for a large number edges like what you have for the switch?



+  /* For insns, print the INSN_UID.
+ In compact mode, we only print the INSN_UID of CODE_LABELs.  */
+  if (!flag_compact || GET_CODE (in_rtx) == CODE_LABEL)
+if (INSN_CHAIN_CODE_P (GET_CODE (in_rtx)))


The two ifs should be merged I think.


Bernd

Re: [PATCH] Implement new hook for max_align_t_align

[John David Anglin]

On 2016-10-12 12:14 PM, Jeff Law wrote:

On 10/12/2016 02:02 AM, Jakub Jelinek wrote:

On Wed, Oct 12, 2016 at 09:52:04AM +0200, Florian Weimer wrote:

dropping the alignment means that the padding before the lock member
vanishes.  Consequently, we have just created a silent ABI change in
application code, which is a big no-no.


Sure, it would be an ABI change, but how many users would it affect?




Since this is PA-RISC, which is essentially dead (neither HPE nor 
Debian
ship it anymore), I stand by my suggestion to bump the fundamental 
alignment


Or just drop support for a dead arch?

instead.  Sure, it is a bit inefficient, but this will only affect 
PA-RISC
users.  It does not even cause work for PA-RISC porters. Conversely, 
if we

work on this to come up with a different fix, many more people will be
affected (because they don't get all the nice things we could work on
instead), and we may need to maintain a special GCC kludge for the
alternative solution, impacting GCC developers in particular.


But sure, bumping malloc alignment is probably easiest.  And people 
who want

performance have better options than to stay on 32-bit PA-RISC anyway.
If the issue is strictly limited to 32 bit hpux, then do we really 
care?  Can we just deprecate that platform and thus make the issue go 
away?


It's really hard to make an argument to do anything other than 
deprecate that platform.  Given John's ongoing involvement it's much 
harder to deprecate 64bit linux (and consequently 64bit hpux).


I believe that deprecating the 32-bit HP-UX platform makes sense. There 
is no HP involvement in hppa,
 ia64 or alpha open source that I am aware of, so deprecating gcc 
platforms with HP systems is reasonable.


My primary focus is open source and one less platform will free some 
time. We still need 64bit hpux for

64bit linux development.

Dave

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

[PATCH] Add a "compact" mode to print_rtx_function

[David Malcolm]

On Fri, 2016-10-07 at 15:58 +0200, Bernd Schmidt wrote:
> On 10/07/2016 03:26 PM, David Malcolm wrote:
> > 
> > We could simply print the INSN_UID for CODE_LABELs; something like
> > this
> > (see the "(code_label 16" below):
> 
> I think that should work.
> 
> > You appear to have trimmed the idea of enclosing the insns with
> > (basic-block) directives without commenting on it.  Did you like
> > this
> > idea?
> 
> Sorry - I appear to have completely missed it.
> 
> > It would make the above look like:
> > 
> >   (basic-block 2
> > ;; insns snipped
> > (jump_insn (set (pc)
> > (if_then_else (ge (reg:CCGC 17 flags)
> > (const_int 0 [0]))
> > (label_ref 16)
> > (pc))) "test.c":3
> >-> 16)
> >   ) ;; basic-block 2
> >   (basic-block 4
> > (note [bb 4] NOTE_INSN_BASIC_BLOCK)
> > ;; insns snipped
> > (jump_insn (set (pc) (label_ref 20)) "test.c":4
> >  -> 20)
> >   ) ;; basic-block 4
> >   (barrier)
> >   (basic-block 5
> > (code_label 16 [1 uses])
> > (note [bb 5] NOTE_INSN_BASIC_BLOCK)
> > ;; etc
> >   ) ;; basic-block 5
> > 
> > Note how the above format expresses clearly that:
> > * the (barrier) is part of the insn chain, but not in a basic
> > block, and
> > * some insns can happen in a basic block
> 
> That looks really nice IMO. Except maybe drop the "-> 16" bit for the
> jump_insn (that's the JUMP_LABEL, isn't it?)
> 
> > Taking this idea further: if we have (basic-block) directives
> > integrated into the insn-chain like this, we could express the CFG
> > by
> > adding (edge) directives. Here's a suggestion for doing it with
> > (edge-from) and (edge-to) directives, expressing the predecessor
> > and
> > successor edges in the CFG, along with :
> 
> That also looks reasonable. Probably a small but maybe not a huge
> improvement over the other syntax. Having both from and to edges
> seems
> redundant but might help readability. The reader should check
> consistency in that case.
> 
> > Should we spell "0" and "1" as "entry" and "exit" when
> > parsing/dumping
> > basic block indices? e.g.:
> > 
> >   (basic-block 2
> > (edge-from entry)
> 
> If that can be done it would be an improvement.
> 
> > > I think maybe you want a separate compact form of insns and notes
> > > (cinsn/cnote maybe), with a flag selecting which gets written out
> > > in
> > > the
> > > dumper. The reader could then read them in like any other rtx
> > > code,
> > > and
> > > there'd be a postprocessing stage to reconstruct the insn chain.
> > 
> > By this separate compact form, do you mean the form we've been
> > discussing above, with no INSN_UID/PREV/NEXT, etc?  Or something
> > else?
> 
> Yes, the form we're discussing, except instead of (insn ...) you'd
> have
> (cinsn ...), which I assume would make it easier for the reader and
> less
> ambiguous overall.
> 
> > As for "cinsn", "cnote", how about just "insn" and "note", and
> > having
> > the compactness be expressed at the top of the dump e.g. implicitly
> > by
> > the presence of a "(function" directive.  Could even have a format
> > version specifier in the function directive, to give us some future
> > -proofing e.g.
> >   (function (format 20161007)
> > or somesuch.
> 
> Having it implicit should also be ok - I have no strong preference
> really. I'm not sure we want versioning - better to have an automatic
> conversion if we ever feel we need to change the format.
> 
> > Do you want to want to try hand-edited a test case, using some of
> > the
> > format ideas we've been discussing?  That might suggest further
> > improvements to the format.
> 
> We'll definitely want to have a look at one or two. Also, we ought to
> try to set up situations we haven't discussed: ADDR_VECs (in light of
> the basic block dumping) and ASMs maybe. I'm probably forgetting
> some.
> 
> One other thing in terms of format is the printout of CONST_INT - I
> think it should suffice to have either decimal, or hex, but not
> really
> both. The reader should maybe accept either.
> 
> I think all hosts have 64-bit HWI these days, so CONST_INT ought to
> always stay valid through a roundtrip.
> 
> I may have missed it, but is there any kind of provision yet for
> providing an "after" dump for what is expected after a pass is run?
> Might be worth thinking about whether the reader could have a mode
> where
> it matches internal RTL against an input.
> 
> > OK.  If so, do we need to print the regno for hard registers?  Or
> > should we just print the name for those, for consistency with
> > virtual
> > regs?  (i.e. have it be controlled by the same flag?)
> 
> Just the name should work, leaving only pseudos with numbers - that
> ought to be reasonable. In the reader, when encountering a reg with a
> number, just add FIRST_PSEUDO_REGISTER, and you should end up with
> something that's consistent. Or maybe even dump the expected
> FIRST_PSEUDO_REGISTER, and adjust for it in case the one we have 

Re: PING! [Fortran, Patch, PR72832, v1] [6/7 Regression] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions

[Steve Kargl]

On Wed, Oct 12, 2016 at 11:50:10AM +0200, Andre Vehreschild wrote:
> Ping!
> 
> Updated patch with the comments gotten so far.
> 
> Ok for trunk?
> 

Looks good to me.

-- 
Steve

Re: [PATCH][check_GNU_style.sh] More aggressively ignore dg-xxx directives

[Martin Sebor]

On 10/12/2016 06:43 AM, Kyrill Tkachov wrote:


On 12/10/16 11:18, Kyrill Tkachov wrote:


On 12/10/16 10:57, Kyrill Tkachov wrote:


On 11/10/16 20:19, Jakub Jelinek wrote:

On Tue, Oct 11, 2016 at 01:11:04PM -0600, Martin Sebor wrote:

Also, the pattern that starts with "/\+\+\+" looks like it's missing
the ^ anchor.  Presumably it should be "/^\+\+\+ \/testsuite\//".

No, it will be almost never +++ /testsuite/
There needs to be .* in between "+++ " and "/testsuite/", and perhaps
it should also ignore "+++ testsuite/".
So /^\+\+\+ (.*\/)?testsuite\// ?
Also, normally (when matching $0) there won't be newlines in the text.

Jakub


Thanks.
Here is the updated patch with your suggestions.



Actually, I've encountered a problem:

 85 # Remove the testsuite part of the diff.  We don't care about GNU
style
 86 # in testcases and the dg-* directives give too many false positives.
 87 remove_testsuite ()
 88 {
 89   awk 'BEGIN{testsuite=0} /\+\+\+ / && ! /testsuite\//{testsuite=0} \
 90{if (!testsuite) print} /^\+\+\+
(.*\/)?testsuite\//{testsuite=1}'
 91 }
 92
 93 grep $format '^+' $files \
 94 | remove_testsuite \
 95 | grep -v ':+++' \
 96 > $inp


The /^\+\+\+ (.*\/)?testsuite\// doesn't ever match when the ^ anchor
is used.
The awk command matches fine by itself but not when fed from the "grep
$format '^+' $files"
command because grep adds the line numbers and file names.
So is it okay to omit the ^ here?


I think the AWK regex will not work correctly when the patch has
the line number prefix like "1234: " (AFAICT, this can only happen
in the second invocation of the remove_testsuite function which
also has the problem below making me wonder if your testing
exercised that mode).

I think the AWK regex needs to be changed to handle that.  It should
start with something like "^([1-9][0-9]*:)?\+\+\+"

I tried to test the patch but it doesn't seem to work.  When passed
a patch as an argument it hangs.  The hunk below isn't quite right:

# Don't reuse $inp, which may be generated using -H and thus contain a
-   # file prefix.
-   grep -n '^+' $f \
+   # file prefix.  Re-remove the testsuite since we're not using $inp.
+   remove_testsuite $f \
+   | grep -n '^+' \
| grep -v ':+++' \
> $tmp

The remove_testsuite function ignores arguments so passing $f to it
won't do anything except hang waiting for input.  This should look
closer to this (it worked in my very limited testing):

cat $f | remove_testsuite \

Martin

[Fortran, Patch, cosmetics] Fix some indentation and typos in comments.

[Andre Vehreschild]

Hi all,

I have committed attached patch as obvious as r241071, because it just corrects
some indentation issues and a typo in a comment.

Bootstrapped and regtested ok on x86_64-linux/f23.

Regards,
Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 241033)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,11 @@
+2016-10-12  Andre Vehreschild  
+
+	* trans-expr.c (gfc_find_and_cut_at_last_class_ref): Fixed style.
+	(gfc_trans_class_init_assign): Same.
+	(gfc_conv_procedure_call): Same.
+	(gfc_trans_assignment_1): Same.
+	* trans-stmt.c (gfc_trans_allocate): Same.
+
 2016-10-11  Jakub Jelinek  
 
 	* iresolve.c (is_trig_resolved, resolve_trig_call): Formatting fixes.
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c	(Revision 241033)
+++ gcc/fortran/trans-expr.c	(Arbeitskopie)
@@ -357,8 +357,7 @@
   array_ref = NULL;
   for (ref = e->ref; ref; ref = ref->next)
 {
-  if (ref->type == REF_ARRAY
-	  && ref->u.ar.type != AR_ELEMENT)
+  if (ref->type == REF_ARRAY && ref->u.ar.type != AR_ELEMENT)
 	array_ref = ref;
 
   if (ref->type == REF_COMPONENT
@@ -367,11 +366,10 @@
 	  /* Component to the right of a part reference with nonzero rank
 	 must not have the ALLOCATABLE attribute.  If attempts are
 	 made to reference such a component reference, an error results
-	 followed by anICE.  */
-	  if (array_ref
-	  && CLASS_DATA (ref->u.c.component)->attr.allocatable)
+	 followed by an ICE.  */
+	  if (array_ref && CLASS_DATA (ref->u.c.component)->attr.allocatable)
 	return NULL;
-	class_ref = ref;
+	  class_ref = ref;
 	}
 
   if (ref->next == NULL)
@@ -1428,7 +1426,7 @@
   rhs->rank = 0;
 
   if (code->expr1->ts.type == BT_CLASS
-	&& CLASS_DATA (code->expr1)->attr.dimension)
+  && CLASS_DATA (code->expr1)->attr.dimension)
 tmp = gfc_trans_class_array_init_assign (rhs, lhs, code->expr1);
   else
 {
@@ -5880,7 +5878,7 @@
   if (comp)
 ts = comp->ts;
   else
-   ts = sym->ts;
+ts = sym->ts;
 
   if (ts.type == BT_CHARACTER && sym->attr.is_bind_c)
 se->string_length = build_int_cst (gfc_charlen_type_node, 1);
@@ -9549,9 +9547,9 @@
  nullification occurs before the call to the finalizer. In the case of
  a scalar to array assignment, this is done in gfc_trans_scalar_assign
  as part of the deep copy.  */
-  if (!scalar_to_array && (expr1->ts.type == BT_DERIVED)
-	  && (gfc_is_alloc_class_array_function (expr2)
-		  || gfc_is_alloc_class_scalar_function (expr2)))
+  if (!scalar_to_array && expr1->ts.type == BT_DERIVED
+		   && (gfc_is_alloc_class_array_function (expr2)
+			   || gfc_is_alloc_class_scalar_function (expr2)))
 {
   tmp = rse.expr;
   tmp = gfc_nullify_alloc_comp (expr1->ts.u.derived, rse.expr, 0);
Index: gcc/fortran/trans-stmt.c
===
--- gcc/fortran/trans-stmt.c	(Revision 241033)
+++ gcc/fortran/trans-stmt.c	(Arbeitskopie)
@@ -5928,7 +5928,7 @@
 	  al_len_needs_set = false;
 	}
 	  else if (expr->ts.type == BT_CHARACTER && al_len != NULL_TREE
-		   && code->ext.alloc.ts.u.cl->length)
+	  && code->ext.alloc.ts.u.cl->length)
 	{
 	  /* Cover the cases where a string length is explicitly
 		 specified by a type spec for deferred length character
@@ -6015,7 +6015,7 @@
 		expr3_len = NULL_TREE;
 	}
 	  else if (code->ext.alloc.ts.type == BT_CHARACTER
-		   && code->ext.alloc.ts.u.cl->length)
+	  && code->ext.alloc.ts.u.cl->length)
 	{
 	  /* Cover the cases where a string length is explicitly
 		 specified by a type spec for deferred length character

Re: [PATCH] Implement new hook for max_align_t_align

[Jeff Law]

On 10/12/2016 02:02 AM, Jakub Jelinek wrote:

On Wed, Oct 12, 2016 at 09:52:04AM +0200, Florian Weimer wrote:

dropping the alignment means that the padding before the lock member
vanishes.  Consequently, we have just created a silent ABI change in
application code, which is a big no-no.


Sure, it would be an ABI change, but how many users would it affect?





Since this is PA-RISC, which is essentially dead (neither HPE nor Debian
ship it anymore), I stand by my suggestion to bump the fundamental alignment


Or just drop support for a dead arch?


instead.  Sure, it is a bit inefficient, but this will only affect PA-RISC
users.  It does not even cause work for PA-RISC porters. Conversely, if we
work on this to come up with a different fix, many more people will be
affected (because they don't get all the nice things we could work on
instead), and we may need to maintain a special GCC kludge for the
alternative solution, impacting GCC developers in particular.


But sure, bumping malloc alignment is probably easiest.  And people who want
performance have better options than to stay on 32-bit PA-RISC anyway.
If the issue is strictly limited to 32 bit hpux, then do we really care? 
 Can we just deprecate that platform and thus make the issue go away?


It's really hard to make an argument to do anything other than deprecate 
that platform.  Given John's ongoing involvement it's much harder to 
deprecate 64bit linux (and consequently 64bit hpux).


Jeff

[PATCH, GCC] Move MEMMODEL_* and enum memmodel from coretypes.h to memmodel.h

[Thomas Preudhomme]

Hi,

This patch is a follow up of [1] which aims to have all memory model related 
declarations in memmodel.h. To achieve that, this patch moves memory model 
related declaration from coretypes.h into memmodel.h. Note that since memmodel.h 
is now included from libgcc it needs to have a runtime library exception.


[1] https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01550.html

=== Methodology ===

To achieve this, an include "memmodel.h" was added to all files except header 
files using MEMMODEL_* or enum memmodel. For header files, the header files 
including them were searched in turn and the process repeated until no new file 
gets modified (a file can have already be mentionned but a change still 
necessary due to needing the include earlier).



ChangeLog entries are as follow:

*** gcc/ChangeLog ***

2016-10-10  Thomas Preud'homme  

* coretypes.h: Move MEMMODEL_* macros and enum memmodel definition
into ...
* memmodel.h: This file.  Add runtime library exception.
* alias.c, asan.c, auto-inc-dec.c, bb-reorder.c, bt-load.c,
  caller-save.c, calls.c, ccmp.c, cfgbuild.c, cfgcleanup.c,
  cfgexpand.c, cfgloopanal.c, cfgrtl.c, cilk-common.c, combine.c,
  combine-stack-adj.c, common/config/aarch64/aarch64-common.c,
  common/config/arm/arm-common.c, common/config/bfin/bfin-common.c,
  common/config/c6x/c6x-common.c, common/config/i386/i386-common.c,
  common/config/ia64/ia64-common.c, common/config/nvptx/nvptx-common.c,
  compare-elim.c, config/aarch64/aarch64-builtins.c,
  config/aarch64/aarch64-c.c, config/aarch64/cortex-a57-fma-steering.c,
  config/arc/arc.c, config/arc/arc-c.c, config/arm/arm-builtins.c,
  config/arm/arm-c.c, config/avr/avr.c, config/avr/avr-c.c,
  config/avr/avr-log.c, config/bfin/bfin.c, config/c6x/c6x.c,
  config/cr16/cr16.c, config/cris/cris.c, config/darwin-c.c,
  config/darwin.c, config/epiphany/epiphany.c,
  config/epiphany/mode-switch-use.c,
  config/epiphany/resolve-sw-modes.c, config/fr30/fr30.c,
  config/frv/frv.c, config/ft32/ft32.c, config/h8300/h8300.c,
  config/i386/i386-c.c, config/i386/winnt.c, config/iq2000/iq2000.c,
  config/lm32/lm32.c, config/m32c/m32c.c, config/m32r/m32r.c,
  config/m68k/m68k.c, config/mcore/mcore.c,
  config/microblaze/microblaze.c, config/mmix/mmix.c,
  config/mn10300/mn10300.c, config/moxie/moxie.c,
  config/msp430/msp430.c, config/nds32/nds32-cost.c,
  config/nds32/nds32-intrinsic.c, config/nds32/nds32-md-auxiliary.c,
  config/nds32/nds32-memory-manipulation.c,
  config/nds32/nds32-predicates.c, config/nds32/nds32.c,
  config/nios2/nios2.c, config/nvptx/nvptx.c, config/pa/pa.c,
  config/pdp11/pdp11.c, config/rl78/rl78.c, config/rs6000/rs6000-c.c,
  config/rx/rx.c, config/s390/s390-c.c, config/s390/s390.c,
  config/sh/sh.c, config/sh/sh-c.c, config/sh/sh-mem.cc,
  config/sh/sh_treg_combine.cc, config/sol2.c, config/spu/spu.c,
  config/stormy16/stormy16.c, config/tilegx/tilegx.c,
  config/tilepro/tilepro.c, config/v850/v850.c, config/vax/vax.c,
  config/visium/visium.c, config/vms/vms-c.c, config/xtensa/xtensa.c,
  coverage.c, cppbuiltin.c, cprop.c, cse.c, cselib.c, dbxout.c, dce.c,
  df-core.c, df-problems.c, df-scan.c, dojump.c, dse.c, dwarf2asm.c,
  dwarf2cfi.c, dwarf2out.c, emit-rtl.c, except.c, explow.c, expmed.c,
  expr.c, final.c, fold-const.c, function.c, fwprop.c, gcse.c,
  ggc-page.c, haifa-sched.c, hsa-brig.c, hsa-gen.c, hw-doloop.c,
  ifcvt.c, init-regs.c, internal-fn.c, ira-build.c, ira-color.c,
  ira-conflicts.c, ira-costs.c, ira-emit.c, ira-lives.c, ira.c, jump.c,
  loop-doloop.c, loop-invariant.c, loop-iv.c, loop-unroll.c,
  lower-subreg.c, lra.c, lra-assigns.c, lra-coalesce.c,
  lra-constraints.c, lra-eliminations.c, lra-lives.c, lra-remat.c,
  lra-spills.c, mode-switching.c, modulo-sched.c, omp-low.c, passes.c,
  postreload-gcse.c, postreload.c, predict.c, print-rtl-function.c,
  recog.c, ree.c, reg-stack.c, regcprop.c, reginfo.c, regrename.c,
  reload.c, reload1.c, reorg.c, resource.c, rtl-chkp.c, rtl-tests.c,
  rtlanal.c, rtlhooks.c, sched-deps.c, sched-rgn.c, sdbout.c,
  sel-sched-ir.c, sel-sched.c, shrink-wrap.c, simplify-rtx.c,
  stack-ptr-mod.c, stmt.c, stor-layout.c, target-globals.c,
  targhooks.c, toplev.c, tree-nested.c, tree-outof-ssa.c,
  tree-profile.c, tree-ssa-coalesce.c, tree-ssa-ifcombine.c,
  tree-ssa-loop-ivopts.c, tree-ssa-loop.c, tree-ssa-reassoc.c,
  tree-ssa-sccvn.c, tree-vect-data-refs.c, ubsan.c, valtrack.c,
  var-tracking.c, varasm.c: Include memmodel.h.
* genattrtab.c (write_header): Include memmodel.h in 

Re: [PATCH, GCC/testsuite/ARM] Enable mov?i_movw tests on ARM and big endian

[Thomas Preudhomme]

On 12/10/16 17:01, Christophe Lyon wrote:

On 12 October 2016 at 17:50, Kyrill Tkachov  wrote:


On 12/10/16 16:29, Thomas Preudhomme wrote:


Sorry :-(

Here you are.

Cheers,

Thomas

On 12/10/16 16:25, Kyrill Tkachov wrote:



On 12/10/16 16:21, Thomas Preudhomme wrote:


Hi,

As reported by Christophe Lyon, gcc.target/arm/movdi_movw test fails on
big
endian targets. This is because on big endian targets the low bits of a
64bit
value would be in the highest numbered register of a pair rather than
the
lowest numbered register as on little endian targets. This patch fixes
that by
allowing both r0 and r1. It also changes effective target to use
arm_thumb2_ok
instead of arm_thumb2 to allow the test on ARM mode targets.

ChangeLog entry is as follows:


*** gcc/testsuite/ChangeLog ***

2016-10-11  Thomas Preud'homme 

* gcc.target/arm/movhi_movw.c: Enable test for ARM mode.
* gcc.target/arm/movsi_movw.c: Likewise.
* gcc.target/arm/movdi_movw.c: Likewise and adapt scan-assembler
directive to work on big endian targets.


Tested testcases with armeb-none-eabi for -march=armv8-a.

Is this ok for trunk?

Best regards,

Thomas



-ERRNOPATCH.
Thanks,
Kyrill



--- a/gcc/testsuite/gcc.target/arm/movdi_movw.c
+++ b/gcc/testsuite/gcc.target/arm/movdi_movw.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { arm_thumb2 || arm_thumb1_movt_ok } } } */
+/* { dg-do compile { target { arm_thumb2_ok || arm_thumb1_movt_ok } } } */


what is the purpose of arm_thumb2_ok || arm_thumb1_movt_ok
if you do not use -mthumb in dg-options?


Checking whether movw is available, otherwise the test would fail. This 
condition ensures that the -march or -mcpu passed indicates either a Thumb-2 
capable target or a target with Thumb-1 and movw such as ARMv8-M.


Best regards,

Thomas

Re: [PATCH, GCC/testsuite/ARM] Enable mov?i_movw tests on ARM and big endian

[Christophe Lyon]

On 12 October 2016 at 17:50, Kyrill Tkachov  wrote:
>
> On 12/10/16 16:29, Thomas Preudhomme wrote:
>>
>> Sorry :-(
>>
>> Here you are.
>>
>> Cheers,
>>
>> Thomas
>>
>> On 12/10/16 16:25, Kyrill Tkachov wrote:
>>>
>>>
>>> On 12/10/16 16:21, Thomas Preudhomme wrote:

 Hi,

 As reported by Christophe Lyon, gcc.target/arm/movdi_movw test fails on
 big
 endian targets. This is because on big endian targets the low bits of a
 64bit
 value would be in the highest numbered register of a pair rather than
 the
 lowest numbered register as on little endian targets. This patch fixes
 that by
 allowing both r0 and r1. It also changes effective target to use
 arm_thumb2_ok
 instead of arm_thumb2 to allow the test on ARM mode targets.

 ChangeLog entry is as follows:


 *** gcc/testsuite/ChangeLog ***

 2016-10-11  Thomas Preud'homme 

 * gcc.target/arm/movhi_movw.c: Enable test for ARM mode.
 * gcc.target/arm/movsi_movw.c: Likewise.
 * gcc.target/arm/movdi_movw.c: Likewise and adapt scan-assembler
 directive to work on big endian targets.


 Tested testcases with armeb-none-eabi for -march=armv8-a.

 Is this ok for trunk?

 Best regards,

 Thomas

>>>
>>> -ERRNOPATCH.
>>> Thanks,
>>> Kyrill
>
>
> --- a/gcc/testsuite/gcc.target/arm/movdi_movw.c
> +++ b/gcc/testsuite/gcc.target/arm/movdi_movw.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile { target { arm_thumb2 || arm_thumb1_movt_ok } } } */
> +/* { dg-do compile { target { arm_thumb2_ok || arm_thumb1_movt_ok } } } */

what is the purpose of arm_thumb2_ok || arm_thumb1_movt_ok
if you do not use -mthumb in dg-options?

>  /* { dg-options "-O2" } */
>   long long
> @@ -7,4 +7,4 @@ movdi (int a)
>return 0xF0F0;
>  }
>  -/* { dg-final { scan-assembler-times "movw\tr0, #61680" 1 } } */
> +/* { dg-final { scan-assembler-times "movw\tr\[01\], #61680" 1 } } */
>
> Can you please add a comment above the scan-assembler to mention the
> big-endian case.
> You can do that as a pre-approved followup or as a respin of this patch.
> Ok for trunk if you want to do it as a followup.
>
> Thanks,
> Kyrill
>

Ping^4 Re: [Patch AArch64] Add floatdihf2 and floatunsdihf2 patterns

[James Greenhalgh]

On Wed, Sep 28, 2016 at 05:17:14PM +0100, James Greenhalgh wrote:
> On Wed, Sep 21, 2016 at 10:42:03AM +0100, James Greenhalgh wrote:
> > On Tue, Sep 13, 2016 at 10:31:28AM +0100, James Greenhalgh wrote:
> > > On Tue, Sep 06, 2016 at 10:19:50AM +0100, James Greenhalgh wrote:
> > > > This patch adds patterns for conversion from 64-bit integer to 16-bit
> > > > floating-point values under AArch64 targets which don't have support for
> > > > the ARMv8.2-A 16-bit floating point extensions.
> > > > 
> > > > We implement these by first saturating to a SImode (we know that any
> > > > values >= 65504 will round to infinity after conversion to HFmode), then
> > > > converting to a DFmode (unsigned conversions could go to SFmode, but 
> > > > there
> > > > is no performance benefit to this). Then converting to HFmode.
> > > > 
> > > > Having added these patterns, the expansion path in "expand_float" will
> > > > now try to use them for conversions from SImode to HFmode as there is no
> > > > floatsihf2 pattern. expand_float first tries widening the integer size 
> > > > and
> > > > looking for a match, so it will try SImode -> DImode. But our DI mode
> > > > pattern is going to then saturate us back to SImode which is wasteful.
> > > > 
> > > > Better, would be for us to provide float(uns)sihf2 patterns directly.
> > > > So that's what this patch does.
> > > > 
> > > > The testcase add in this patch would fail on trunk for AArch64. There is
> > > > no libgcc routine to make the conversion, and we don't provide 
> > > > appropriate
> > > > patterns in the backend, so we get a link-time error.
> > > > 
> > > > Bootstrapped and tested on aarch64-none-linux-gnu
> > > > 
> > > > OK for trunk?
> > > 
> > > Ping.
> > 
> > Ping^2
> 
> Ping^3

Ping^4

Thanks,
James

> 
> There was an off-list question as to whether the mid-end could catch this,
> rather than requiring the target to do so. My objection to that is that it
> would involve teaching the midend about saturating narrowing operations,
> which if the target doesn't provide them natively require branching.
> 
> I'd rather push targets that want DImode to HFmode (and don't provide a
> DImode to TFmode to go through first) to use libgcc/soft-fp than try to add
> a special generic expander for DImode to HFmode conversions.
> 
> Note that even if we did have a generic expander for these types, we would
> still need some version of this patch, as we want to override the behaviour
> where the ARMv8.2-A 16-bit floating-point types are available.
> > > > 2016-09-06  James Greenhalgh  
> > > > 
> > > > * config/aarch64/aarch64.md (sihf2): Convert to expand.
> > > > (dihf2): Likewise.
> > > > (aarch64_fp16_hf2): New.
> > > > 
> > > > 2016-09-06  James Greenhalgh  
> > > > 
> > > > * gcc.target/aarch64/floatdihf2_1.c: New.
> > > > 
> > > 
> > > > diff --git a/gcc/config/aarch64/aarch64.md 
> > > > b/gcc/config/aarch64/aarch64.md
> > > > index 6afaf90..1882a72 100644
> > > > --- a/gcc/config/aarch64/aarch64.md
> > > > +++ b/gcc/config/aarch64/aarch64.md
> > > > @@ -4630,7 +4630,14 @@
> > > >[(set_attr "type" "f_cvti2f")]
> > > >  )
> > > >  
> > > > -(define_insn "hf2"
> > > > +;; If we do not have ARMv8.2-A 16-bit floating point extensions, the
> > > > +;; midend will arrange for an SImode conversion to HFmode to first go
> > > > +;; through DFmode, then to HFmode.  But first it will try converting
> > > > +;; to DImode then down, which would match our DImode pattern below and
> > > > +;; give very poor code-generation.  So, we must provide our own 
> > > > emulation
> > > > +;; of the mid-end logic.
> > > > +
> > > > +(define_insn "aarch64_fp16_hf2"
> > > >[(set (match_operand:HF 0 "register_operand" "=w")
> > > > (FLOATUORS:HF (match_operand:GPI 1 "register_operand" "r")))]
> > > >"TARGET_FP_F16INST"
> > > > @@ -4638,6 +4645,53 @@
> > > >[(set_attr "type" "f_cvti2f")]
> > > >  )
> > > >  
> > > > +(define_expand "sihf2"
> > > > +  [(set (match_operand:HF 0 "register_operand")
> > > > +   (FLOATUORS:HF (match_operand:SI 1 "register_operand")))]
> > > > +  "TARGET_FLOAT"
> > > > +{
> > > > +  if (TARGET_FP_F16INST)
> > > > +emit_insn (gen_aarch64_fp16_sihf2 (operands[0], 
> > > > operands[1]));
> > > > +  else
> > > > +{
> > > > +  rtx convert_target = gen_reg_rtx (DFmode);
> > > > +  emit_insn (gen_sidf2 (convert_target, operands[1]));
> > > > +  emit_insn (gen_truncdfhf2 (operands[0], convert_target));
> > > > +}
> > > > +  DONE;
> > > > +}
> > > > +)
> > > > +
> > > > +;; For DImode there is no wide enough floating-point mode that we
> > > > +;; can convert through natively (TFmode would work, but requires a 
> > > > library
> > > > +;; call).  However, we know that any value >= 65504 will be rounded
> > > > +;; to infinity on conversion.  This is well within the range of 
> > > > SImode, so
> > > > +;; we can:
> > > > +;;   Saturate to 

Re: [RFC] Possible folding opportunities for string built-ins

[Joseph Myers]

On Wed, 12 Oct 2016, Martin Liška wrote:

> Last question is whether one can aggressively fold strcasecmp in a host 
> compiler? Or are there any situations where results depends on locale?

There are the usual issues with Turkish locales having the uppercase 
version of 'i' being 'İ' and the lowercase version of 'I' being 'ı'.

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

Re: [PATCH] Implement new hook for max_align_t_align

[Joseph Myers]

On Wed, 12 Oct 2016, Richard Biener wrote:

> I'd say what applies to PA should apply equally well to the pdp11 and
> the alpha port ...
> 
> But usually the question is just whether the port has a maintainer
> and/or whether it is
> a maintainance burden to keep it (say, last user of obsolete feature X).

Last users of obsolete feature "defines TARGET_HAVE_NAMED_SECTIONS to 
false": 32-bit PA HP-UX (64-bit HP-UX is ELF like GNU/Linux, so OK), 
pdp11, pre-ELF OpenBSD ports.  (I'm not aware of that obsolete feature 
particularly causing problems, however.  But the implication for pdp11 
would be that if the port were to stay with that feature being removed, it 
should move to ELF - the e_machine value EM_PDP11 having been allocated by 
Lars Brinkhoff on 30 May 2002, but I don't know if there's an ABI.)

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

Re: [PATCH, GCC/testsuite/ARM] Enable mov?i_movw tests on ARM and big endian

[Kyrill Tkachov]

On 12/10/16 16:29, Thomas Preudhomme wrote:

Sorry :-(

Here you are.

Cheers,

Thomas

On 12/10/16 16:25, Kyrill Tkachov wrote:


On 12/10/16 16:21, Thomas Preudhomme wrote:

Hi,

As reported by Christophe Lyon, gcc.target/arm/movdi_movw test fails on big
endian targets. This is because on big endian targets the low bits of a 64bit
value would be in the highest numbered register of a pair rather than the
lowest numbered register as on little endian targets. This patch fixes that by
allowing both r0 and r1. It also changes effective target to use arm_thumb2_ok
instead of arm_thumb2 to allow the test on ARM mode targets.

ChangeLog entry is as follows:


*** gcc/testsuite/ChangeLog ***

2016-10-11  Thomas Preud'homme 

* gcc.target/arm/movhi_movw.c: Enable test for ARM mode.
* gcc.target/arm/movsi_movw.c: Likewise.
* gcc.target/arm/movdi_movw.c: Likewise and adapt scan-assembler
directive to work on big endian targets.


Tested testcases with armeb-none-eabi for -march=armv8-a.

Is this ok for trunk?

Best regards,

Thomas



-ERRNOPATCH.
Thanks,
Kyrill


--- a/gcc/testsuite/gcc.target/arm/movdi_movw.c
+++ b/gcc/testsuite/gcc.target/arm/movdi_movw.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { arm_thumb2 || arm_thumb1_movt_ok } } } */
+/* { dg-do compile { target { arm_thumb2_ok || arm_thumb1_movt_ok } } } */
 /* { dg-options "-O2" } */
 
 long long

@@ -7,4 +7,4 @@ movdi (int a)
   return 0xF0F0;
 }
 
-/* { dg-final { scan-assembler-times "movw\tr0, #61680" 1 } } */

+/* { dg-final { scan-assembler-times "movw\tr\[01\], #61680" 1 } } */

Can you please add a comment above the scan-assembler to mention the big-endian 
case.
You can do that as a pre-approved followup or as a respin of this patch.
Ok for trunk if you want to do it as a followup.

Thanks,
Kyrill

Re: [PATCH][store merging][RFA] Re-implement merging code

[Kyrill Tkachov]

On 10/10/16 12:15, Richard Biener wrote:

On Mon, 10 Oct 2016, Richard Biener wrote:


On Mon, 10 Oct 2016, Kyrill Tkachov wrote:


On 10/10/16 11:22, Richard Biener wrote:

On Mon, 10 Oct 2016, Kyrill Tkachov wrote:


Hi Richard,

As I mentioned, here is the patch applying to the main store merging patch
to
re-implement encode_tree_to_bitpos
to operate on the bytes directly.

This works fine on little-endian but breaks on big-endian, even for
merging
bitfields within a single byte.
Consider the code snippet from gcc.dg/store_merging_6.c:

struct bar {
int a : 3;
unsigned char b : 4;
unsigned char c : 1;
char d;
char e;
char f;
char g;
};

void
foo1 (struct bar *p)
{
p->b = 3;
p->a = 2;
p->c = 1;
p->d = 4;
p->e = 5;
}

The correct GIMPLE for these merged stores on big-endian is:
MEM[(voidD.49 *)p_2(D)] = 18180;
MEM[(charD.8 *)p_2(D) + 2B] = 5;

whereas with this patch we emit:
MEM[(voidD.49 *)p_2(D)] = 39428;
MEM[(charD.8 *)p_2(D) + 2B] = 5;

The dump for merging the individual stores without this patch (using the
correct but costly wide_int approach in the base patch) is:
After writing 3 of size 4 at position 3 the merged region contains:
6 0 0 0 0 0
After writing 2 of size 3 at position 0 the merged region contains:
46 0 0 0 0 0
After writing 1 of size 1 at position 7 the merged region contains:
47 0 0 0 0 0
After writing 4 of size 8 at position 8 the merged region contains:
47 4 0 0 0 0
After writing 5 of size 8 at position 16 the merged region contains:
47 4 5 0 0 0


And with this patch it is:
After writing 3 of size 4 at position 3 the merged region contains:
18 0 0 0 0 0
After writing 2 of size 3 at position 0 the merged region contains:
1a 0 0 0 0 0
After writing 1 of size 1 at position 7 the merged region contains:
9a 0 0 0 0 0
After writing 4 of size 8 at position 8 the merged region contains:
9a 4 0 0 0 0
After writing 5 of size 8 at position 16 the merged region contains:
9a 4 5 0 0 0

(Note the dump just dumps the byte array from index 0 to  so the
first
thing printed is the lowest numbered byte.
Also, each byte is dumped in hex.)

The code as included here doesn't do any byte swapping for big-endian but
as
seen from the dump even writing a sub-byte
bitfield goes wrong so it would be nice to resolve that before going
forward.
Any help with debugging this is hugely appreciated. I've included an ASCII
diagram of the steps in the algorithm
in the patch itself.

Ah, I think you need to account for BITS_BIG_ENDIAN in
shift_bytes_in_array.  You have to shift towards MSB which means changing
left to right shifts for BITS_BIG_ENDIAN.

Thanks, I'll try it out. But this is on aarch64 where
BITS_BIG_ENDIAN is 0 even when BYTES_BIG_ENDIAN is 1
so there's something else bad here.

Maybe I'm confusing all the macros, so maybe it's BYTES_BIG_ENDIAN
(vs. WORDS_BIG_ENDIAN -- in theory this approach should work for
pdp11 as well).

Or maybe I'm confusing how get_inner_reference numbers "bits" when
it returns bitpos... (and how a multi-byte value in target memory
representation has to be "shifted" by bitpos).

I really thought BITS_BIG_ENDIAN is the only thing that matters...

Btw, I reproduced on ppc64-linux (which has BITS_BIG_ENDIAN).


having looked around the documentation and codebase it looks like 
BITS_BIG_ENDIAN
is just used to define how bitfield instructions on a target operate and so only
apply to the RTL level, so I think we don't have to worry about that at GIMPLE.
As a hack, adjusting bitpos for BYTES_BIG_ENDIAN to:
bitpos = byte_size * BITS_PER_UNIT - bitlen - (bitpos % BITS_PER_UNIT)
"fixes" the dg.exp=store_merging* testcases but is still wrong for multi-byte
testcases (gcc.c-torture/execute/20040629-1.c is a good one that exercises all 
that).

I'm trying to wrap my head around the byte layout and what should be shifted 
where...

Thanks,
Kyrill


Richard.


Richard.


You also seem to miss to account for amnt / BITS_PER_UNIT != 0.
Independently of BYTES_BIG_ENDIAN it would be

ptr[i + (amnt / BITS_PER_UNIT)] = ptr[i] << amnt;
...

doh, yes. I'll fix that.


(so best use a single load / store and operate on a temporary).

Thanks,
Kyrill


Richard.


Thanks,
Kyrill

Re: [PATCH 4/6] shrink-wrap: Shrink-wrapping for separate components

[Segher Boessenkool]

On Mon, Oct 03, 2016 at 01:48:21PM +, Segher Boessenkool wrote:
> This is the main substance of this patch series.

I forgot to update the changelog before, what I committed is:


* function.c (thread_prologue_and_epilogue_insns): Call
try_shrink_wrapping_separate.  Compute the prologue_seq afterwards,
if it has possibly changed.  Compute the split_prologue_seq and
epilogue_seq later, too.
* shrink-wrap.c: #include cfgbuild.h and insn-config.h.
(dump_components): New function.
(struct sw): New struct.
(SW): New function.
(init_separate_shrink_wrap): New function.
(fini_separate_shrink_wrap): New function.
(place_prologue_for_one_component): New function.
(spread_components): New function.
(disqualify_problematic_components): New function.
(emit_common_heads_for_components): New function.
(emit_common_tails_for_components): New function.
(insert_prologue_epilogue_for_components): New function.
(try_shrink_wrapping_separate): New function.
* shrink-wrap.h: Declare try_shrink_wrapping_separate.

libgo patch committed: copy Go 1.7 runtime semaphore code

[Ian Lance Taylor]

This patch to libgo copies the Go 1.7 runtime semaphore code into
libgo, basically replacing sema.goc (written in C) with sema.go
(writteh in Go).

This triggered a check in releaseSudog that g.param not nil, because
libgo uses the param field when starting a goroutine.  Fixed by clearing
g->param in kickoff in proc.c.

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 241051)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-d56717f8c434b3d6b753c027487681769e201e14
+7e4543d050339e113e6278fd442d940c0f1a5670
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 241051)
+++ libgo/Makefile.am   (working copy)
@@ -528,7 +528,6 @@ runtime_files = \
rdebug.c \
reflect.c \
runtime1.c \
-   sema.c \
sigqueue.c \
string.c \
time.c \
Index: libgo/go/runtime/sema.go
===
--- libgo/go/runtime/sema.go(revision 0)
+++ libgo/go/runtime/sema.go(working copy)
@@ -0,0 +1,358 @@
+// Copyright 2009 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// Semaphore implementation exposed to Go.
+// Intended use is provide a sleep and wakeup
+// primitive that can be used in the contended case
+// of other synchronization primitives.
+// Thus it targets the same goal as Linux's futex,
+// but it has much simpler semantics.
+//
+// That is, don't think of these as semaphores.
+// Think of them as a way to implement sleep and wakeup
+// such that every sleep is paired with a single wakeup,
+// even if, due to races, the wakeup happens before the sleep.
+//
+// See Mullender and Cox, ``Semaphores in Plan 9,''
+// http://swtch.com/semaphore.pdf
+
+package runtime
+
+// Export temporarily for gccgo's C code to call:
+//go:linkname semacquire runtime.semacquire
+//go:linkname semrelease runtime.semrelease
+
+import (
+   "runtime/internal/atomic"
+   "runtime/internal/sys"
+   "unsafe"
+)
+
+// Asynchronous semaphore for sync.Mutex.
+
+type semaRoot struct {
+   lock  mutex
+   head  *sudog
+   tail  *sudog
+   nwait uint32 // Number of waiters. Read w/o the lock.
+}
+
+// Prime to not correlate with any user patterns.
+const semTabSize = 251
+
+var semtable [semTabSize]struct {
+   root semaRoot
+   pad  [sys.CacheLineSize - unsafe.Sizeof(semaRoot{})]byte
+}
+
+//go:linkname sync_runtime_Semacquire sync.runtime_Semacquire
+func sync_runtime_Semacquire(addr *uint32) {
+   semacquire(addr, true)
+}
+
+//go:linkname net_runtime_Semacquire net.runtime_Semacquire
+func net_runtime_Semacquire(addr *uint32) {
+   semacquire(addr, true)
+}
+
+//go:linkname sync_runtime_Semrelease sync.runtime_Semrelease
+func sync_runtime_Semrelease(addr *uint32) {
+   semrelease(addr)
+}
+
+//go:linkname net_runtime_Semrelease net.runtime_Semrelease
+func net_runtime_Semrelease(addr *uint32) {
+   semrelease(addr)
+}
+
+func readyWithTime(s *sudog, traceskip int) {
+   if s.releasetime != 0 {
+   s.releasetime = cputicks()
+   }
+   goready(s.g, traceskip)
+}
+
+// Called from runtime.
+func semacquire(addr *uint32, profile bool) {
+   gp := getg()
+   if gp != gp.m.curg {
+   throw("semacquire not on the G stack")
+   }
+
+   // Easy case.
+   if cansemacquire(addr) {
+   return
+   }
+
+   // Harder case:
+   //  increment waiter count
+   //  try cansemacquire one more time, return if succeeded
+   //  enqueue itself as a waiter
+   //  sleep
+   //  (waiter descriptor is dequeued by signaler)
+   s := acquireSudog()
+   root := semroot(addr)
+   t0 := int64(0)
+   s.releasetime = 0
+   if profile && blockprofilerate > 0 {
+   t0 = cputicks()
+   s.releasetime = -1
+   }
+   for {
+   lock()
+   // Add ourselves to nwait to disable "easy case" in semrelease.
+   atomic.Xadd(, 1)
+   // Check cansemacquire to avoid missed wakeup.
+   if cansemacquire(addr) {
+   atomic.Xadd(, -1)
+   unlock()
+   break
+   }
+   // Any semrelease after the cansemacquire knows we're waiting
+   // (we set nwait above), so go to sleep.
+   root.queue(addr, s)
+   goparkunlock(, "semacquire", traceEvGoBlockSync, 4)
+   if cansemacquire(addr) {
+   break
+  

[PATCH] Define std::sample for C++17

[Jonathan Wakely]

I forgot that std::sample() was added to C++17, so it wasn't in our
status table. It is now.

I changed the testcase to use our iterator wrappers instead of
containers, which found some bugs. I intend to go through other tests
where I've used std::forward_list to get forward iterators, or stream
iterators for input/output iterators, and make them use the wrappers
too.

* doc/xml/manual/status_cxx2017.xml: Add std::sample status.
* doc/html/*: Regenerate.
* include/experimental/algorithm (__sample): Move to bits/stl_algo.h
and into namespace std.
* include/bits/stl_algo.h (__sample): Define here. Fix invalid use
of input iterator. Defend against overloaded comma operator.
(sample): Define for C++17.
* testsuite/25_algorithms/sample/1.cc: New test.

Tested powerpc64le-linux, committed to trunk.

commit d727fe4bd81e5c79d4f37df66fad53503e01ccec
Author: Jonathan Wakely 
Date:   Wed Oct 12 15:02:59 2016 +0100

Define std::sample for C++17

* doc/xml/manual/status_cxx2017.xml: Add std::sample status.
* doc/html/*: Regenerate.
* include/experimental/algorithm (__sample): Move to bits/stl_algo.h
and into namespace std.
* include/bits/stl_algo.h (__sample): Define here. Fix invalid use
of input iterator. Defend against overloaded comma operator.
(sample): Define for C++17.
* testsuite/25_algorithms/sample/1.cc: New test.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
index c6b8440..ae8dfa9 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
@@ -182,6 +182,17 @@ Feature-testing recommendations for C++.
 
 
 
+   Library Fundamentals V1 TS Components: Sampling 
+  
+   http://www.w3.org/1999/xlink; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0220r1.html;>
+   P0220R1
+   
+  
+   7 
+   __cpp_lib_sample >= 201603 
+
+
+
Constant View: A proposal for a std::as_const 
helper function template  
   
http://www.w3.org/1999/xlink; xlink:href="">
diff --git a/libstdc++-v3/include/bits/stl_algo.h 
b/libstdc++-v3/include/bits/stl_algo.h
index ea0b56c..0538a79 100644
--- a/libstdc++-v3/include/bits/stl_algo.h
+++ b/libstdc++-v3/include/bits/stl_algo.h
@@ -5615,6 +5615,86 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
__gnu_cxx::__ops::__iter_comp_iter(__comp));
 }
 
+#if __cplusplus >= 201402L
+  /// Reservoir sampling algorithm.
+  template
+_RandomAccessIterator
+__sample(_InputIterator __first, _InputIterator __last, input_iterator_tag,
+_RandomAccessIterator __out, random_access_iterator_tag,
+_Size __n, _UniformRandomBitGenerator&& __g)
+{
+  using __distrib_type = uniform_int_distribution<_Size>;
+  using __param_type = typename __distrib_type::param_type;
+  __distrib_type __d{};
+  _Size __sample_sz = 0;
+  while (__first != __last && __sample_sz != __n)
+   {
+ __out[__sample_sz++] = *__first;
+ ++__first;
+   }
+  for (auto __pop_sz = __sample_sz; __first != __last;
+ ++__first, (void) ++__pop_sz)
+   {
+ const auto __k = __d(__g, __param_type{0, __pop_sz});
+ if (__k < __n)
+   __out[__k] = *__first;
+   }
+  return __out + __sample_sz;
+}
+
+  /// Selection sampling algorithm.
+  template
+_OutputIterator
+__sample(_ForwardIterator __first, _ForwardIterator __last,
+forward_iterator_tag,
+_OutputIterator __out, _Cat,
+_Size __n, _UniformRandomBitGenerator&& __g)
+{
+  using __distrib_type = uniform_int_distribution<_Size>;
+  using __param_type = typename __distrib_type::param_type;
+  __distrib_type __d{};
+  _Size __unsampled_sz = std::distance(__first, __last);
+  for (__n = std::min(__n, __unsampled_sz); __n != 0; ++__first)
+   if (__d(__g, __param_type{0, --__unsampled_sz}) < __n)
+ {
+   *__out++ = *__first;
+   --__n;
+ }
+  return __out;
+}
+
+#if __cplusplus > 201402L
+#define __cpp_lib_sample 201603
+  /// Take a random sample from a population.
+  template
+_SampleIterator
+sample(_PopulationIterator __first, _PopulationIterator __last,
+  _SampleIterator __out, _Distance __n,
+  _UniformRandomBitGenerator&& __g)
+{
+  using __pop_cat = typename
+   std::iterator_traits<_PopulationIterator>::iterator_category;
+  using __samp_cat = typename
+   std::iterator_traits<_SampleIterator>::iterator_category;
+
+  static_assert(
+ __or_,
+   is_convertible<__samp_cat, random_access_iterator_tag>>::value,
+ "output range must use a RandomAccessIterator 

Re: [PATCH, GCC/testsuite/ARM] Enable mov?i_movw tests on ARM and big endian

[Thomas Preudhomme]

Sorry :-(

Here you are.

Cheers,

Thomas

On 12/10/16 16:25, Kyrill Tkachov wrote:


On 12/10/16 16:21, Thomas Preudhomme wrote:

Hi,

As reported by Christophe Lyon, gcc.target/arm/movdi_movw test fails on big
endian targets. This is because on big endian targets the low bits of a 64bit
value would be in the highest numbered register of a pair rather than the
lowest numbered register as on little endian targets. This patch fixes that by
allowing both r0 and r1. It also changes effective target to use arm_thumb2_ok
instead of arm_thumb2 to allow the test on ARM mode targets.

ChangeLog entry is as follows:


*** gcc/testsuite/ChangeLog ***

2016-10-11  Thomas Preud'homme  

* gcc.target/arm/movhi_movw.c: Enable test for ARM mode.
* gcc.target/arm/movsi_movw.c: Likewise.
* gcc.target/arm/movdi_movw.c: Likewise and adapt scan-assembler
directive to work on big endian targets.


Tested testcases with armeb-none-eabi for -march=armv8-a.

Is this ok for trunk?

Best regards,

Thomas



-ERRNOPATCH.
Thanks,
Kyrill
diff --git a/gcc/testsuite/gcc.target/arm/movdi_movw.c b/gcc/testsuite/gcc.target/arm/movdi_movw.c
index 0f6b839da614c56766e92e3da125551df47890fc..253d0b26d2ebbd0e2c006b79e7cd2fc8312ff828 100644
--- a/gcc/testsuite/gcc.target/arm/movdi_movw.c
+++ b/gcc/testsuite/gcc.target/arm/movdi_movw.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { arm_thumb2 || arm_thumb1_movt_ok } } } */
+/* { dg-do compile { target { arm_thumb2_ok || arm_thumb1_movt_ok } } } */
 /* { dg-options "-O2" } */
 
 long long
@@ -7,4 +7,4 @@ movdi (int a)
   return 0xF0F0;
 }
 
-/* { dg-final { scan-assembler-times "movw\tr0, #61680" 1 } } */
+/* { dg-final { scan-assembler-times "movw\tr\[01\], #61680" 1 } } */
diff --git a/gcc/testsuite/gcc.target/arm/movhi_movw.c b/gcc/testsuite/gcc.target/arm/movhi_movw.c
index b097a8a019c74507f0c182af6ba5cf526369564b..d0d2bbb418e0d76b5438c5fcd84b4ee069b01ac7 100644
--- a/gcc/testsuite/gcc.target/arm/movhi_movw.c
+++ b/gcc/testsuite/gcc.target/arm/movhi_movw.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { arm_thumb2 || arm_thumb1_movt_ok } } } */
+/* { dg-do compile { target { arm_thumb2_ok || arm_thumb1_movt_ok } } } */
 /* { dg-options "-O2" } */
 
 short
diff --git a/gcc/testsuite/gcc.target/arm/movsi_movw.c b/gcc/testsuite/gcc.target/arm/movsi_movw.c
index d50906e76ab412ead71ff576d2f28d520234f58d..349705813971d035235898bf40771b1b17b64cca 100644
--- a/gcc/testsuite/gcc.target/arm/movsi_movw.c
+++ b/gcc/testsuite/gcc.target/arm/movsi_movw.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { arm_thumb2 || arm_thumb1_movt_ok } } } */
+/* { dg-do compile { target { arm_thumb2_ok || arm_thumb1_movt_ok } } } */
 /* { dg-options "-O2" } */
 
 int

Re: [PATCH, GCC/testsuite/ARM] Enable mov?i_movw tests on ARM and big endian

[Kyrill Tkachov]

On 12/10/16 16:21, Thomas Preudhomme wrote:

Hi,

As reported by Christophe Lyon, gcc.target/arm/movdi_movw test fails on big endian targets. This is because on big endian targets the low bits of a 64bit value would be in the highest numbered register of a pair rather than the lowest 
numbered register as on little endian targets. This patch fixes that by allowing both r0 and r1. It also changes effective target to use arm_thumb2_ok instead of arm_thumb2 to allow the test on ARM mode targets.


ChangeLog entry is as follows:


*** gcc/testsuite/ChangeLog ***

2016-10-11  Thomas Preud'homme  

* gcc.target/arm/movhi_movw.c: Enable test for ARM mode.
* gcc.target/arm/movsi_movw.c: Likewise.
* gcc.target/arm/movdi_movw.c: Likewise and adapt scan-assembler
directive to work on big endian targets.


Tested testcases with armeb-none-eabi for -march=armv8-a.

Is this ok for trunk?

Best regards,

Thomas



-ERRNOPATCH.
Thanks,
Kyrill

[PATCH, GCC/testsuite/ARM] Enable mov?i_movw tests on ARM and big endian

[Thomas Preudhomme]

Hi,

As reported by Christophe Lyon, gcc.target/arm/movdi_movw test fails on big 
endian targets. This is because on big endian targets the low bits of a 64bit 
value would be in the highest numbered register of a pair rather than the lowest 
numbered register as on little endian targets. This patch fixes that by allowing 
both r0 and r1. It also changes effective target to use arm_thumb2_ok instead of 
arm_thumb2 to allow the test on ARM mode targets.


ChangeLog entry is as follows:


*** gcc/testsuite/ChangeLog ***

2016-10-11  Thomas Preud'homme  

* gcc.target/arm/movhi_movw.c: Enable test for ARM mode.
* gcc.target/arm/movsi_movw.c: Likewise.
* gcc.target/arm/movdi_movw.c: Likewise and adapt scan-assembler
directive to work on big endian targets.


Tested testcases with armeb-none-eabi for -march=armv8-a.

Is this ok for trunk?

Best regards,

Thomas

Re: Questionable code in gcov-io.c

[Nathan Sidwell]

On 10/12/16 11:04, Andreas Schwab wrote:


Do we still need to call fstat?  I don't think it can ever fail here.


You appear to be correct.

nathan

Re: Questionable code in gcov-io.c

[Marek Polacek]

On Wed, Oct 12, 2016 at 10:47:07AM -0400, Nathan Sidwell wrote:
> On 10/12/16 09:43, Marek Polacek wrote:
> 
> > > ITYM lines 197 -> 203.  I.e. remove the entire if that;s inside the 'mode 
> > > ==
> > > 0' branch and make line 203 unconditional.
> > 
> > Yes, sorry for sloppy wording.  I'm testing a patch.
> 
> Here's the patch I've tested (but not bootstrapped).  As the incoming mode
> is -1, 0 or +1 we can make things considerably simpler.

Great, thanks.

Marek

Re: Questionable code in gcov-io.c

[Andreas Schwab]

On Okt 12 2016, Nathan Sidwell  wrote:

> @@ -182,9 +176,7 @@ gcov_open (const char *name, int mode)
>return 0;
>  }
>  
> -  if (mode > 0)
> -gcov_var.mode = 1;
> -  else if (mode == 0)
> +  if (mode == 0)
>  {
>struct stat st;
>  
> @@ -194,21 +186,20 @@ gcov_open (const char *name, int mode)
> gcov_var.file = 0;
> return 0;
>   }
> -  if (st.st_size != 0)
> - gcov_var.mode = 1;
> -  else
> - gcov_var.mode = mode * 2 + 1;
> +  gcov_var.mode = 1;

Do we still need to call fstat?  I don't think it can ever fail here.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [tree-optimization/71947] Avoid unwanted propagations

[Georg-Johann Lay]

On 10.10.2016 23:06, Jeff Law wrote:



So if we have an equality conditional between A & B, we record into our
const/copy tables A = B and B = A.

This helps us discover some of the more obscure equivalences. But it also
creates problems with an expression like

A ^ B

Where we might cprop the first operand generating

B ^ B

Then the second generating

B ^ A

ANd we've lost the folding opportunity.  At first I'd tried folding after each
propagation step, but that turns into a bit of a nightmare because of changes
in the underlying structure of the gimple statement and cycles that may develop
if we re-build the operand cache after folding.

This approach is simpler and should catch all these cases for binary
operators.  We just track the last copy propagated argument and refuse to
ping-pong propagations.

It fixes the tests from 71947 and 77647 without regressing (obviously). I've
included an xfailed test for a more complex situation that we don't currently
handle (would require backtracking from the equality comparison through the
logicals that feed the equality comparison).

Bootstrapped and regression tested on x86_64.  Applied to the trunk.

commit 6223e6e425b6de916f0330b9dbe5698765d4a73c
Author: law 
Date:   Mon Oct 10 20:40:59 2016 +

PR tree-optimization/71947
* tree-ssa-dom.c (cprop_into_stmt): Avoid replacing A with B, then
B with A within a single statement.

PR tree-optimization/71947
* gcc.dg/tree-ssa/pr71947-1.c: New test.
* gcc.dg/tree-ssa/pr71947-2.c: New test.
* gcc.dg/tree-ssa/pr71947-3.c: New test.
* gcc.dg/tree-ssa/pr71947-4.c: New test.
* gcc.dg/tree-ssa/pr71947-5.c: New test.
* gcc.dg/tree-ssa/pr71947-6.c: New test.

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

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 1738bc7..16e25bf 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2016-10-10  Jeff Law  
+
+PR tree-optimization/71947
+   * tree-ssa-dom.c (cprop_into_stmt): Avoid replacing A with B, then
+   B with A within a single statement.
+
 2016-10-10  Bill Schmidt  

PR tree-optimization/77824
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 04966cf..e31bcc6 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,13 @@
+2016-10-10  Jeff Law  
+
+   PR tree-optimization/71947
+   * gcc.dg/tree-ssa/pr71947-1.c: New test.
+   * gcc.dg/tree-ssa/pr71947-2.c: New test.
+   * gcc.dg/tree-ssa/pr71947-3.c: New test.
+   * gcc.dg/tree-ssa/pr71947-4.c: New test.
+   * gcc.dg/tree-ssa/pr71947-5.c: New test.
+   * gcc.dg/tree-ssa/pr71947-6.c: New test.
+
 2016-10-10  Thomas Koenig  

PR fortran/77915
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71947-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-1.c
new file mode 100644
index 000..b033495
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-1.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-tree-vrp -fdump-tree-dom-details" } */
+
+
+int f(int x, int y)
+{
+   int ret;
+
+   if (x == y)
+ ret = x ^ y;
+   else
+ ret = 1;
+
+   return ret;
+}
+
+/* { dg-final { scan-tree-dump "Folded to: ret_\[0-9\]+ = 0;"  "dom2" } } */
+
+
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
new file mode 100644
index 000..de8f88b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-tree-vrp -fdump-tree-dom-details" } */
+
+
+int f(int x, int y)
+{
+  int ret;
+  if (x == y)
+ret = x - y;
+  else
+ret = 1;
+
+  return ret;
+}
+
+/* { dg-final { scan-tree-dump "Folded to: ret_\[0-9\]+ = 0;"  "dom2" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71947-3.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-3.c
new file mode 100644
index 000..e79847f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-3.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-tree-vrp -fdump-tree-dom-details" } */
+
+int f(int x, int y)
+{
+  int ret = 10;
+  if (x == y)
+ret = x  -  y;
+  return ret;
+}
+
+/* { dg-final { scan-tree-dump "Folded to: ret_\[0-9\]+ = 0;"  "dom2" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71947-4.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-4.c
new file mode 100644
index 000..a881f0d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-4.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-tree-vrp -fdump-tree-dom-details" } */
+
+
+
+static inline long load(long *p)
+{
+long ret;
+asm ("movq  %1,%0\n\t" : "=r" (ret) : "m" (*p));



Hi, shouldn't this test be restricted to target machines that understand MOVQ?

Same issue for 

RE: [PATCH 4/4] [MIPS] Add tests for MSA

[Robert Suchanek]

Hi,

> -Original Message-
> From: Matthew Fortune
> Sent: 19 September 2016 15:46
> To: Robert Suchanek; catherine_mo...@mentor.com
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH 4/4] [MIPS] Add tests for MSA
> 
> Hi Robert,
> 
> Sorry for the long delay. Just a couple of cleanup bits in here but
> otherwise OK. Unless you want me to read through again please go
> ahead and commit once you've addressed the comments.
> 
> We could do more in mips.exp for inferring -mfp64 and -mhard-float
> but I'm not sure it is worth it currently. Let's leave it for a
> round of testsuite changes at a later date.

Will do.

> 
> Thanks,
> Matthew
> 
> >---
> > gcc/testsuite/gcc.dg/vect/slp-26.c   |7 +-
> > gcc/testsuite/gcc.dg/vect/tree-vect.h|2 +
> > gcc/testsuite/gcc.target/mips/mips.exp   |8 +
> > gcc/testsuite/gcc.target/mips/msa-builtins.c | 1086
> ++
> > gcc/testsuite/gcc.target/mips/msa.c  |  631 +++
> > gcc/testsuite/lib/target-supports.exp|  191 -
> > 6 files changed, 1895 insertions(+), 30 deletions(-)
> > create mode 100644 gcc/testsuite/gcc.target/mips/msa-builtins.c
> > create mode 100644 gcc/testsuite/gcc.target/mips/msa.c
> >
> >diff --git a/gcc/testsuite/gcc.dg/vect/slp-26.c
> b/gcc/testsuite/gcc.dg/vect/slp-26.c
> >index 8b224ff..01f4e4e 100644
> >--- a/gcc/testsuite/gcc.dg/vect/slp-26.c
> >+++ b/gcc/testsuite/gcc.dg/vect/slp-26.c
> >@@ -46,6 +46,7 @@ int main (void)
> >   return 0;
> > }
> >
> >-/* { dg-final { scan-tree-dump-times "vectorized 0 loops" 1 "vect"  } } */
> >-/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 0 "vect"
> } } */
> >-
> >+/* { dg-final { scan-tree-dump-times "vectorized 0 loops" 1 "vect" { target 
> >{
> ! mips_msa } } } } */
> >+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target 
> >{
> mips_msa } } } } */
> >+/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 0 "vect" 
> >{
> target { ! mips_msa } } } } */
> >+/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" 
> >{
> target { mips_msa } } } } */
> 
> Why can we vectorise this with MSA but presumably no other arch can?

AFAICT, the reason being is that MSA supports integer division in hardware, 
thus,
we can vectorize the loop.

> 
> >diff --git a/gcc/testsuite/gcc.target/mips/mips.exp
> b/gcc/testsuite/gcc.target/mips/mips.exp
> >index 3258105..7c24140 100644
> >--- a/gcc/testsuite/gcc.target/mips/mips.exp
> >+++ b/gcc/testsuite/gcc.target/mips/mips.exp
> >@@ -290,6 +290,7 @@ foreach option {
> > relax-pic-calls
> > mcount-ra-address
> > odd-spreg
> >+msa
> > } {
> > lappend mips_option_groups $option "-m(no-|)$option"
> > }
> >@@ -820,6 +821,12 @@ proc mips-dg-init {} {
> > "-mno-synci",
> > #endif
> >
> >+#ifdef __mips_msa
> >+"-mmsa"
> >+#else
> >+"-mno-msa"
> >+#endif
> >+
> > 0
> > };
> > }]
> >@@ -1368,6 +1375,7 @@ proc mips-dg-options { args } {
> > mips_option_dependency options "-mfpxx" "-mno-paired-single"
> > mips_option_dependency options "-msoft-float" "-mno-paired-single"
> > mips_option_dependency options "-mno-paired-single" "-mno-mips3d"
> >+mips_option_dependency options "-mmsa" "-mno-mips16"
> >
> > # If the test requires an unsupported option, change run tests
> > # to link tests.
> >diff --git a/gcc/testsuite/gcc.target/mips/msa-builtins.c
> b/gcc/testsuite/gcc.target/mips/msa-builtins.c
> >new file mode 100644
> >index 000..f5e1efa
> >--- /dev/null
> >+++ b/gcc/testsuite/gcc.target/mips/msa-builtins.c
> >@@ -0,0 +1,1086 @@
> >+/* Test builtins for MIPS MSA ASE instructions */
> >+/* { dg-do compile } */
> >+/* { dg-options "-mfp64 -mhard-float -mmsa" } */
> >+/* { dg-skip-if "needs asm output" { *-*-* } { "-flto" } { "-ffat-lto-
> objects" } } */
> 
> This should not be necessary. The scan-assembler directive forces fat-lto-
> objects
> via some higher level code. I have seen this fail at times but never tracked 
> it
> down
> please remove dg-skip-if and see if you still get any -fno-fat-lto-objects
> builds
> of this file.

I placed it temporarily to work around occasional failures with the bare-metal
toolchain.  As discussed, this is going to be fixed so I removed these from the 
tests.

> 
> >+
> >+/* { dg-final { scan-assembler "msa_addv_b.*:.*addv\\.b.*msa_addv_b" } } */
> 
> Should these be seen only once: I.e. scan-assembler-times?

I changed the test to scan-assembler-times with some additional changes to
fit the correct matching and counting.

I applied changes as suggested in all the remaining comments.

Committed as r241054.

Regards,
Robert

Re: Questionable code in gcov-io.c

[Nathan Sidwell]

On 10/12/16 09:43, Marek Polacek wrote:


ITYM lines 197 -> 203.  I.e. remove the entire if that;s inside the 'mode ==
0' branch and make line 203 unconditional.


Yes, sorry for sloppy wording.  I'm testing a patch.


Here's the patch I've tested (but not bootstrapped).  As the incoming mode is 
-1, 0 or +1 we can make things considerably simpler.


nathan

2016-10-12  Nathan Sidwell  

	* gcov-io.c (gcov_open): Fix documentation.  Simplify setting
	gcov_var.mode.

Index: gcov-io.c
===
--- gcov-io.c	(revision 241027)
+++ gcov-io.c	(working copy)
@@ -115,10 +115,9 @@ static inline gcov_unsigned_t from_file
opened. If MODE is >= 0 an existing file will be opened, if
possible, and if MODE is <= 0, a new file will be created. Use
MODE=0 to attempt to reopen an existing file and then fall back on
-   creating a new one.  If MODE < 0, the file will be opened in
+   creating a new one.  If MODE > 0, the file will be opened in
read-only mode.  Otherwise it will be opened for modification.
-   Return zero on failure, >0 on opening an existing file and <0 on
-   creating a new one.  */
+   Return zero on failure, non-zero on success.  */
 
 GCOV_LINKAGE int
 #if IN_LIBGCOV
@@ -156,17 +155,12 @@ gcov_open (const char *name, int mode)
   /* pass mode (ignored) for compatibility */
   fd = open (name, O_RDONLY, S_IRUSR | S_IWUSR);
 }
-  else if (mode < 0)
+  else
  {
/* Write mode - acquire a write-lock.  */
s_flock.l_type = F_WRLCK;
-  fd = open (name, O_RDWR | O_CREAT | O_TRUNC, 0666);
-}
-  else /* mode == 0 */
-{
-  /* Read-Write mode - acquire a write-lock.  */
-  s_flock.l_type = F_WRLCK;
-  fd = open (name, O_RDWR | O_CREAT, 0666);
+   /* Truncate if force new mode.  */
+   fd = open (name, O_RDWR | O_CREAT | (mode < 0 ? O_TRUNC : 0), 0666);
 }
   if (fd < 0)
 return 0;
@@ -182,9 +176,7 @@ gcov_open (const char *name, int mode)
   return 0;
 }
 
-  if (mode > 0)
-gcov_var.mode = 1;
-  else if (mode == 0)
+  if (mode == 0)
 {
   struct stat st;
 
@@ -194,21 +186,20 @@ gcov_open (const char *name, int mode)
 	  gcov_var.file = 0;
 	  return 0;
 	}
-  if (st.st_size != 0)
-	gcov_var.mode = 1;
-  else
-	gcov_var.mode = mode * 2 + 1;
+  gcov_var.mode = 1;
 }
   else
-gcov_var.mode = mode * 2 + 1;
+gcov_var.mode = mode;
 #else
   if (mode >= 0)
+/* Open an existing file.  */
 gcov_var.file = fopen (name, (mode > 0) ? "rb" : "r+b");
 
   if (gcov_var.file)
 gcov_var.mode = 1;
   else if (mode <= 0)
 {
+  /* Create a new file.  */
   gcov_var.file = fopen (name, "w+b");
   if (gcov_var.file)
 	gcov_var.mode = mode * 2 + 1;

Re: [tree-optimization/71947] Avoid unwanted propagations

[Christophe Lyon]

Hi Jeff,


On 10 October 2016 at 23:06, Jeff Law  wrote:
>
>
> So if we have an equality conditional between A & B, we record into our
> const/copy tables A = B and B = A.
>
> This helps us discover some of the more obscure equivalences. But it also
> creates problems with an expression like
>
> A ^ B
>
> Where we might cprop the first operand generating
>
> B ^ B
>
> Then the second generating
>
> B ^ A
>
> ANd we've lost the folding opportunity.  At first I'd tried folding after
> each propagation step, but that turns into a bit of a nightmare because of
> changes in the underlying structure of the gimple statement and cycles that
> may develop if we re-build the operand cache after folding.
>
> This approach is simpler and should catch all these cases for binary
> operators.  We just track the last copy propagated argument and refuse to
> ping-pong propagations.
>
> It fixes the tests from 71947 and 77647 without regressing (obviously). I've
> included an xfailed test for a more complex situation that we don't
> currently handle (would require backtracking from the equality comparison
> through the logicals that feed the equality comparison).
>
FWIW, this test is XPASS on arm-none-linux-gnueabihf
--with-cpu=cortex-a5 --with-fpu=vfpv3-d16-fp16:

Christophe


> Bootstrapped and regression tested on x86_64.  Applied to the trunk.
>
>
> commit 6223e6e425b6de916f0330b9dbe5698765d4a73c
> Author: law 
> Date:   Mon Oct 10 20:40:59 2016 +
>
> PR tree-optimization/71947
> * tree-ssa-dom.c (cprop_into_stmt): Avoid replacing A with B, then
> B with A within a single statement.
>
> PR tree-optimization/71947
> * gcc.dg/tree-ssa/pr71947-1.c: New test.
> * gcc.dg/tree-ssa/pr71947-2.c: New test.
> * gcc.dg/tree-ssa/pr71947-3.c: New test.
> * gcc.dg/tree-ssa/pr71947-4.c: New test.
> * gcc.dg/tree-ssa/pr71947-5.c: New test.
> * gcc.dg/tree-ssa/pr71947-6.c: New test.
>
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@240947
> 138bc75d-0d04-0410-961f-82ee72b054a4
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 1738bc7..16e25bf 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,9 @@
> +2016-10-10  Jeff Law  
> +
> +PR tree-optimization/71947
> +   * tree-ssa-dom.c (cprop_into_stmt): Avoid replacing A with B, then
> +   B with A within a single statement.
> +
>  2016-10-10  Bill Schmidt  
>
> PR tree-optimization/77824
> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> index 04966cf..e31bcc6 100644
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,3 +1,13 @@
> +2016-10-10  Jeff Law  
> +
> +   PR tree-optimization/71947
> +   * gcc.dg/tree-ssa/pr71947-1.c: New test.
> +   * gcc.dg/tree-ssa/pr71947-2.c: New test.
> +   * gcc.dg/tree-ssa/pr71947-3.c: New test.
> +   * gcc.dg/tree-ssa/pr71947-4.c: New test.
> +   * gcc.dg/tree-ssa/pr71947-5.c: New test.
> +   * gcc.dg/tree-ssa/pr71947-6.c: New test.
> +
>  2016-10-10  Thomas Koenig  
>
> PR fortran/77915
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71947-1.c
> b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-1.c
> new file mode 100644
> index 000..b033495
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-1.c
> @@ -0,0 +1,19 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fno-tree-vrp -fdump-tree-dom-details" } */
> +
> +
> +int f(int x, int y)
> +{
> +   int ret;
> +
> +   if (x == y)
> + ret = x ^ y;
> +   else
> + ret = 1;
> +
> +   return ret;
> +}
> +
> +/* { dg-final { scan-tree-dump "Folded to: ret_\[0-9\]+ = 0;"  "dom2" } }
> */
> +
> +
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
> b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
> new file mode 100644
> index 000..de8f88b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
> @@ -0,0 +1,16 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fno-tree-vrp -fdump-tree-dom-details" } */
> +
> +
> +int f(int x, int y)
> +{
> +  int ret;
> +  if (x == y)
> +ret = x - y;
> +  else
> +ret = 1;
> +
> +  return ret;
> +}
> +
> +/* { dg-final { scan-tree-dump "Folded to: ret_\[0-9\]+ = 0;"  "dom2" } }
> */
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71947-3.c
> b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-3.c
> new file mode 100644
> index 000..e79847f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-3.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fno-tree-vrp -fdump-tree-dom-details" } */
> +
> +int f(int x, int y)
> +{
> +  int ret = 10;
> +  if (x == y)
> +ret = x  -  y;
> +  return ret;
> +}
> +
> +/* { dg-final { scan-tree-dump "Folded to: ret_\[0-9\]+ = 0;"  "dom2" } }
> */
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71947-4.c
> 

[PATCH] Fix PR77947

[Richard Biener]

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

Richard.

2016-10-12  Richard Biener  

PR debug/77947
* cgraphunit.c (analyze_functions): Preserve cgraph nodes
function context.

* g++.dg/torture/pr77947.C: New testcase.

Index: gcc/cgraphunit.c
===
--- gcc/cgraphunit.c(revision 241033)
+++ gcc/cgraphunit.c(working copy)
@@ -1117,15 +1117,22 @@ analyze_functions (bool first_time)
}
 
  /* If decl is a clone of an abstract function,
- mark that abstract function so that we don't release its body.
- The DECL_INITIAL() of that abstract function declaration
- will be later needed to output debug info.  */
+mark that abstract function so that we don't release its body.
+The DECL_INITIAL() of that abstract function declaration
+will be later needed to output debug info.  */
  if (DECL_ABSTRACT_ORIGIN (decl))
{
  cgraph_node *origin_node
= cgraph_node::get_create (DECL_ABSTRACT_ORIGIN (decl));
  origin_node->used_as_abstract_origin = true;
}
+ /* Preserve a functions function context node.  It will
+later be needed to output debug info.  */
+ if (tree fn = decl_function_context (decl))
+   {
+ cgraph_node *origin_node = cgraph_node::get_create (fn);
+ enqueue_node (origin_node);
+   }
}
  else
{
Index: gcc/testsuite/g++.dg/torture/pr77947.C
===
--- gcc/testsuite/g++.dg/torture/pr77947.C  (revision 0)
+++ gcc/testsuite/g++.dg/torture/pr77947.C  (revision 0)
@@ -0,0 +1,29 @@
+// { dg-do compile }
+// { dg-additional-options "-g" }
+
+class A
+{
+public:
+  virtual bool m_fn1 () const = 0;
+};
+class B
+{
+  const A *m_fn2 () const;
+};
+inline const A *
+B::m_fn2 () const
+{
+  class C : A
+  {
+bool
+m_fn1 () const
+{
+}
+C () {}
+  };
+}
+void
+fn1 (A )
+{
+  p1.m_fn1 ();
+}

libgo patch committed: Fixes for sparc64

[Ian Lance Taylor]

This patch to libgo by James Clarke fixes libgo for sparc64.  The
getrandom syscall was being ignored because the file was named
"sparc".  The clone syscall apparently needs special attention on
SPARC.  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 240993)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-03e53c928ebaa15a915eb1e1b07f193d83fc2852
+d56717f8c434b3d6b753c027487681769e201e14
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 240956)
+++ libgo/Makefile.am   (working copy)
@@ -736,6 +736,12 @@ s-epoll: Makefile
$(SHELL) $(srcdir)/mvifdiff.sh epoll.go.tmp epoll.go
$(STAMP) $@
 
+if LIBGO_IS_LINUX
+syscall_lib_clone_lo = syscall/clone_linux.lo
+else
+syscall_lib_clone_lo =
+endif
+
 libgo_go_objs = \
bufio.lo \
bytes.lo \
@@ -767,6 +773,7 @@ libgo_go_objs = \
strings/index.lo \
sync.lo \
syscall.lo \
+   $(syscall_lib_clone_lo) \
syscall/errno.lo \
syscall/signame.lo \
syscall/wait.lo \
@@ -2534,6 +2541,9 @@ syscall.lo.dep: $(srcdir)/go/syscall/*.g
$(BUILDDEPS)
 syscall.lo:
$(BUILDPACKAGE)
+syscall/clone_linux.lo: go/syscall/clone_linux.c runtime.inc
+   @$(MKDIR_P) syscall
+   $(LTCOMPILE) -c -o $@ $<
 syscall/errno.lo: go/syscall/errno.c runtime.inc
@$(MKDIR_P) syscall
$(LTCOMPILE) -c -o $@ $<
Index: libgo/go/internal/syscall/unix/getrandom_linux_sparc.go
===
--- libgo/go/internal/syscall/unix/getrandom_linux_sparc.go (revision 
240942)
+++ libgo/go/internal/syscall/unix/getrandom_linux_sparc.go (working copy)
@@ -1,11 +0,0 @@
-// Copyright 2016 The Go Authors. All rights reserved.
-// Use of this source code is governed by a BSD-style
-// license that can be found in the LICENSE file.
-
-// +build sparc sparc64
-
-package unix
-
-// Linux getrandom system call number.
-// See GetRandom in getrandom_linux.go.
-const randomTrap uintptr = 347
Index: libgo/go/internal/syscall/unix/getrandom_linux_sparcx.go
===
--- libgo/go/internal/syscall/unix/getrandom_linux_sparcx.go(revision 0)
+++ libgo/go/internal/syscall/unix/getrandom_linux_sparcx.go(working copy)
@@ -0,0 +1,11 @@
+// Copyright 2016 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// +build sparc sparc64
+
+package unix
+
+// Linux getrandom system call number.
+// See GetRandom in getrandom_linux.go.
+const randomTrap uintptr = 347
Index: libgo/go/syscall/clone_linux.c
===
--- libgo/go/syscall/clone_linux.c  (revision 0)
+++ libgo/go/syscall/clone_linux.c  (working copy)
@@ -0,0 +1,100 @@
+/* clone_linux.c -- consistent wrapper around Linux clone syscall
+
+   Copyright 2016 The Go Authors. All rights reserved.
+   Use of this source code is governed by a BSD-style
+   license that can be found in the LICENSE file.  */
+
+#include 
+#include 
+#include 
+
+#include "runtime.h"
+
+long rawClone (unsigned long flags, void *child_stack, void *ptid, void *ctid, 
struct pt_regs *regs) __asm__ (GOSYM_PREFIX "syscall.rawClone");
+
+long
+rawClone (unsigned long flags, void *child_stack, void *ptid, void *ctid, 
struct pt_regs *regs)
+{
+#if defined(__arc__) || defined(__aarch64__) || defined(__arm__) || 
defined(__mips__) || defined(__hppa__) || defined(__powerpc__) || 
defined(__score__) || defined(__i386__) || defined(__xtensa__)
+  // CLONE_BACKWARDS
+  return syscall(__NR_clone, flags, child_stack, ptid, regs, ctid);
+#elif defined(__s390__) || defined(__cris__)
+  // CLONE_BACKWARDS2
+  return syscall(__NR_clone, child_stack, flags, ptid, ctid, regs);
+#elif defined(__microblaze__)
+  // CLONE_BACKWARDS3
+  return syscall(__NR_clone, flags, child_stack, 0, ptid, ctid, regs);
+#elif defined(__sparc__)
+
+  /* SPARC has a unique return value convention:
+
+ Parent -->  %o0 == child's  pid, %o1 == 0
+ Child  -->  %o0 == parent's pid, %o1 == 1
+
+ Translate this to look like a normal clone.  */
+
+# if defined(__arch64__)
+
+#  define SYSCALL_STRING   \
+   "ta 0x6d;"  \
+   "bcc,pt %%xcc, 1f;" \
+   " mov   0, %%g1;"   \
+   "sub%%g0, %%o0, %%o0;"  \
+   "mov1, %%g1;"  

Re: PR35503 - warn for restrict pointer

[Jason Merrill]

On Sat, Oct 8, 2016 at 1:07 PM, Prathamesh Kulkarni
 wrote:
> On 7 October 2016 at 17:49, David Malcolm  wrote:
>> On Fri, 2016-10-07 at 10:33 +0530, Prathamesh Kulkarni wrote:
>>> On 22 September 2016 at 23:15, Joseph Myers 
>>> wrote:
>>> > 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__.
>>> Thanks for the suggestions. To keep it simple, instead of vec,
>>> I made %Z take two args: int *v, unsigned len, and prints elements in
>>> v having length == len.
>>> Is that OK ?
>>>
>>> Bootstrapped+tested on x86_64-unknown-linux-gnu.
>>> As pointed out earlier in the thread, the patch can give false
>>> positives because
>>> it only checks whether parameters are qualified with restrict, not
>>> how
>>> parameters
>>> are used inside the function. For instance it warned for example 10
>>> mentioned in n1570
>>> under section 6.7.3.1 - "Formal definition of restrict".
>>> Should we keep the warning in Wall or keep it in Wextra ?
>>> The attached patch enables it with Wall.
>>>
>>
>> This needs a ChangeLog.
>>
>> The changes to diagnostic-core.h and diagnostic.c are OK for trunk,
>> given a suitable ChangeLog (and could be split into a separate patch if
>> you like).
> Thanks, I committed diagnostic.c and diagnostic-core.h changes (with 
> ChangeLog)
> in r240891.

The C++ changes are also OK.

Jason

Re: [PATCH] Implement new hook for max_align_t_align

[John David Anglin]

On 2016-10-12 9:48 AM, Jason Merrill wrote:

On Wed, Oct 12, 2016 at 4:02 AM, Jakub Jelinek  wrote:

On Wed, Oct 12, 2016 at 09:52:04AM +0200, Florian Weimer wrote:

dropping the alignment means that the padding before the lock member
vanishes.  Consequently, we have just created a silent ABI change in
application code, which is a big no-no.

Sure, it would be an ABI change, but how many users would it affect?


Since this is PA-RISC, which is essentially dead (neither HPE nor Debian
ship it anymore), I stand by my suggestion to bump the fundamental alignment

Or just drop support for a dead arch?


instead.  Sure, it is a bit inefficient, but this will only affect PA-RISC
users.  It does not even cause work for PA-RISC porters. Conversely, if we
work on this to come up with a different fix, many more people will be
affected (because they don't get all the nice things we could work on
instead), and we may need to maintain a special GCC kludge for the
alternative solution, impacting GCC developers in particular.

But sure, bumping malloc alignment is probably easiest.  And people who want
performance have better options than to stay on 32-bit PA-RISC anyway.

Or we could do nothing and tell people to ignore the harmless warning.
The warning is an issue because of -Werror.  However, it appears easy to 
suppress it in the PA

backend.  I have a patch that I'm testing.

We are discussing offline regarding the glibc issue.  It easy to bump 
the alignment of malloc
but I take Jakub's point and maybe we should break the ABI.  Debian 
unstable churns
quickly, and I think we would be better off being consistent with the 
current max_align_t

and 8-byte aligned malloc.

Dave

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

Re: [PATCH] Introduce -Wimplicit-fallthrough={0,1,2,3,4,5}

[Jakub Jelinek]

On Wed, Oct 12, 2016 at 04:04:25PM +0200, Bernd Schmidt wrote:
> On 10/12/2016 01:04 PM, Markus Trippelsdorf wrote:
> >I'm more concerned about the first impression that people will get from
> >this warning. If the fist couple of samples they will look at are
> >clearly bogus (as with the example comments above) they will very
> >quickly disable the warning.
> >
> >And if a small one digit percentage of all potential issues falls
> >through the cracks with -Wimplicit-fallthrough=1 , so be it.
> 
> Yes. Better to give mostly sensible warnings, making people aware of the
> option and maybe encouraging to try higher levels, rather than generating a
> huge amount of noise which will result in some people turning the warning
> off, some making pointles or even incorrect changes to their code (as we saw
> in gcc itself), and generating bad publicity.

But whatever non-zero level it is, the most common case in most projects
will be not the intentional fallthrus marked with custom style comments, but
those not marked at all.  E.g. in the linux kernel case, that is 90% of the
warnings with -Wimplicit-fallthrough=2.  Whether you tweak another 10% isn't
something that makes significant difference.
What incorrect changes to code in gcc do you have in mind?  I just remember
one spot where a /* FALLTHRU */ comment has been added even when it should
be break;, that is no code change.  Most of the cases in gcc that had to
change were where there were no fallthru comments at all, not where a custom
style comment has been changed to some more standardized one.

Jakub

Re: Move OVERRIDE/FINAL from gcc/coretypes.h to include/ansidecl.h

[Bernd Schmidt]

On 10/12/2016 04:09 PM, Pedro Alves wrote:


Thanks.  Here's a follow up patch that I was just testing.

Need this if building with "g++ -std=gnu++11", with gcc < 4.7.


Lovely. That's ok too if the other one goes in.


Bernd

Re: Move OVERRIDE/FINAL from gcc/coretypes.h to include/ansidecl.h

[Pedro Alves]

On 10/12/2016 03:01 PM, Bernd Schmidt wrote:
> On 10/10/2016 09:32 PM, Pedro Alves wrote:
>> From: Pedro Alves 
>> Date: 2016-10-10 19:25:47 +0100
>>
>> Move OVERRIDE/FINAL from gcc/coretypes.h to include/ansidecl.h
>>
>> So that GDB and other projects that share the top level can use them.
> 
> Seems reasonable. OK unless someone objects by the end of the week.

Thanks.  Here's a follow up patch that I was just testing.

Need this if building with "g++ -std=gnu++11", with gcc < 4.7.

From: Pedro Alves 
Date: 2016-10-12 01:49:53 +0100

FINAL/OVERRIDE: Define to empty on g++ < 4.7

final/override were only implemented in 4.7.

include/ChangeLog
2016-10-12  Pedro Alves  

* ansidecl.h [__cplusplus >= 201103 && GCC_VERSION > 4007] (FINAL,
OVERRIDE): Define as empty.
[__cplusplus < 201103 && GCC_VERSION > 4007] (FINAL): Define as
__final.
[__cplusplus < 201103 && GCC_VERSION > 4007] (OVERRIDE): Define as
empty.
---

 include/ansidecl.h |   20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/include/ansidecl.h b/include/ansidecl.h
index ee93421..08aeb1e 100644
--- a/include/ansidecl.h
+++ b/include/ansidecl.h
@@ -329,13 +329,23 @@ So instead we use the macro below and test it against 
specific values.  */
this by default (actually GNU++14).  */
 
 #if __cplusplus >= 201103
-/* C++11 claims to be available: use it: */
-#define OVERRIDE override
-#define FINAL final
+/* C++11 claims to be available: use it.  final/override were only
+   implemented in 4.7, though.  */
+# if GCC_VERSION < 4007
+#  define OVERRIDE
+#  define FINAL
+# else
+#  define OVERRIDE override
+#  define FINAL final
+# endif
+#elif GCC_VERSION >= 4007
+/* G++ 4.7 supports __final in C++98.  */
+# define OVERRIDE
+# define FINAL __final
 #else
 /* No C++11 support; leave the macros empty: */
-#define OVERRIDE
-#define FINAL
+# define OVERRIDE
+# define FINAL
 #endif
 
 #ifdef __cplusplus

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

[Martin Liška]

On 10/07/2016 01:13 PM, Jakub Jelinek wrote:
> Hi!
> 

Hi Jakub.

Again thanks for detailed review, you found many improvements.

> Ok, first let me list some needed follow-ups that don't need to be handled
> right away:
> - r237814-like changes for ASAN_MARK

Yes, that's missing. I'm wondering whether the same approach would be viable as
the {un}poisoning happens during gimplification. Thus it generates  
expressions
which verifier won't be happy about?

> - optimization to remove ASAN_MARK unpoisoning at the start of the function

As current implementation does not poison variables at the very beginning of
a functions (RTL stack frame emission), it won't be needed.

> - optimization to remove ASAN_MARK poisoning at the end of function (and
>   remove epilogue unpoisoning)
> - optimization to remove ASAN_MARK unpoisoning followed by ASAN_MARK poisoning
>   or vice versa if there are no memory accesses in between

Yep, both are not handled and are very similar from my perspective: pairing
poisoning and unpoisoning pair which are not interfered by a memory operation
in between (in dominator meaning of word).
I'm wondering whether can be done effectively as we would need to visit all BBs
in a dominance domain (get_all_dominated_blocks) and check for the memory 
operations.
One improvement can be set of BBs that do not have any memory operations 
(excluding
ASAN_CHECK, ASAN_MARK builtins), but it can be still expensive to simplify 
poisoning
for all local variables. Or am I wrong?

> - try to improve the goto handling

Works for me to be target for stage3.

I'm sending a new version where all mentioned notes should be fixed.

Thanks,
Martin


> 
> On Mon, Oct 03, 2016 at 11:27:38AM +0200, Martin Liška wrote:
>> +  if (dump_file && (dump_flags & TDF_DETAILS))
>> +fprintf (dump_file, "Skipping stack emission for variable: %s "
>> + "(%ldB)\n",
> 
> This message is weird.  I would have thought you are informing the user
> that you are unpoisoning the stack for the specified variable.
> 
>> + IDENTIFIER_POINTER (DECL_NAME (decl)),
> 
> Can't DECL_NAME be NULL?
> 
>> + var_end_offset - var_offset);
>> +  for (unsigned i = 0; i < size; ++i)
>> +{
>> +  unsigned char shadow_c = c;
>> +  if (i == size- 1 && last_chunk_size && !is_clobber)
> 
> Wrong formatting, space before - missing.
> 
>> +  g = gimple_build_assign (make_ssa_name (pointer_sized_int_node),
>> +  NOP_EXPR, base);
> 
> Incorrect indentation.
> 
>> +
>> +/* Return TRUE if we should instrument for use-after-scope sanity checking. 
>>  */
>> +
>> +static inline bool
>> +asan_sanitize_use_after_scope (void)
>> +{
>> +  return ((flag_sanitize & SANITIZE_ADDRESS_USE_AFTER_SCOPE)
>> +  == SANITIZE_ADDRESS_USE_AFTER_SCOPE
>> +  && ASAN_STACK);
>> +}
> 
> This looks wrong.  IMHO you really don't want to use ASAN_STACK in asan.h, 
> because it
> requires params.h.  I think what would be best is to prototype
> asan_sanitize_stack_p in asan.h, remove static inline from its definition,
> and have asan.h
> static inline bool
> asan_sanitize_use_after_scope (void)
> {
>   return (flag_sanitize_use_after_scope && asan_sanitize_stack_p ();
> }
> That way, for the common case of no sanitization it would be inline and
> fast.
> 
>> +static inline bool
>> +asan_no_sanitize_address_p (void)
>> +{
>> +  return lookup_attribute ("no_sanitize_address",
>> +   DECL_ATTRIBUTES (current_function_decl));
>> +}
> 
> And you could avoid doing this.
> 
>> +  if ((asan_sanitize_stack_p () || asan_sanitize_use_after_scope ())
> 
> And then just drop asan_sanitize_use_after_scope () from cases like this,
> because really asan_sanitize_use_after_scope () must imply
> asan_sanitize_stack_p ().
> 
>> @@ -1127,7 +1127,8 @@ expand_stack_vars (bool (*pred) (size_t), struct 
>> stack_vars_data *data)
>>if (alignb * BITS_PER_UNIT <= MAX_SUPPORTED_STACK_ALIGNMENT)
>>  {
>>base = virtual_stack_vars_rtx;
>> -  if (asan_sanitize_stack_p () && pred)
>> +  if ((asan_sanitize_stack_p () || asan_sanitize_use_after_scope ())
> 
> Likewise.
>> +  && pred)
> 
>> @@ -1514,7 +1515,9 @@ defer_stack_allocation (tree var, bool toplevel)
>>/* If stack protection is enabled, *all* stack variables must be deferred,
>>   so that we can re-order the strings to the top of the frame.
>>   Similarly for Address Sanitizer.  */
>> -  if (flag_stack_protect || asan_sanitize_stack_p ())
>> +  if (flag_stack_protect
>> +  || asan_sanitize_stack_p ()
>> +  || asan_sanitize_use_after_scope ())
> 
> And again.
> 
>>  return true;
>>  
>>unsigned int align = TREE_CODE (var) == SSA_NAME
>> @@ -2212,7 +2215,7 @@ expand_used_vars (void)
>>  expand_stack_vars (stack_protect_decl_phase_2, );
>>  }
>>  
>> -  if (asan_sanitize_stack_p ())
>> +  if (asan_sanitize_stack_p () || 

Re: [PATCH,rs6000] Add built-in function support for Power9 string operations

[Segher Boessenkool]

On Tue, Oct 11, 2016 at 03:29:54PM -0600, Martin Sebor wrote:
> >+signed int vec_cntlz_lsbb (vector signed char);
> >+signed int vec_cntlz_lsbb (vector unsigned char)
> >+
> >+signed int vec_cnttz_lsbb (vector signed char);
> >+signed int vec_cnttz_lsbb (vector unsigned char);
> ...
> >+The @code{vec_cntlz_lsbb} function returns the count of the number of
> >+consecutive leading byte elements (starting from position 0 within the
> >+supplied vector argument) for which the least-significant bit
> >+equals zero.  The @code{vec_cnttz_lsbb} function returns the count of
> >+the number of consecutive trailing byte elements (starting from
> >+position 15 and counting backwards within the supplied vector
> >+argument) for which the least-significant bit equals zero.
> 
> Since these return a non-negative result I'm wondering if it would
> make more sense to declare them to return unsigned rather a "signed
> int."

We have to do what the ABI says, I'm afraid ;-)

> Alternatively (and I admit I have no idea if this is even
> doable in the back end), since the return value is within a narrow
> range of unsigned integers (between zero and 16, IIUC) would it be
> possible to constrain the range of its return values, like for
> the scalar __builtin_popcount?

The intrinsics expand to RTL code.  GCC can usually figure out what
range of values can be produced, except that the UNSPECs don't help
here.


Segher

Re: [PATCH 2/2] [ARC] Fix mul32x16 patterns.

[Andrew Burgess]

* Claudiu Zissulescu  [2016-06-30 12:24:12 
+0200]:

> The mululw instructions are wrongly used in the patterns, fix them.
> 
> Okt to apply?
> Claudiu
> 
> gcc/
> 2016-06-28  Claudiu Zissulescu  
> 
>   * config/arc/arc.md (umul_600): Change.
>   (umul64_600): Likewise.

Looks fine, though maybe you could be a little more descriptive with
the ChangeLog entry.

Thanks,
Andrew




> ---
>  gcc/config/arc/arc.md | 18 +++---
>  1 file changed, 7 insertions(+), 11 deletions(-)
> 
> diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
> index 2464a19..41b8eed 100644
> --- a/gcc/config/arc/arc.md
> +++ b/gcc/config/arc/arc.md
> @@ -1937,13 +1937,11 @@
> (const_int 0
> (clobber (match_operand:SI 3 "acc1_operand" ""))]
>"TARGET_MULMAC_32BY16_SET"
> -  "@mululw 0, %0, %1
> -mululw 0, %0, %1
> -mululw%? 0, %1, %0"
> +  "mululw 0, %0, %1"
>[(set_attr "length" "4,4,8")
> -   (set_attr "type" "mulmac_600, mulmac_600, mulmac_600")
> -   (set_attr "predicable" "no, no, yes")
> -   (set_attr "cond" "nocond, canuse_limm, canuse")])
> +   (set_attr "type" "mulmac_600")
> +   (set_attr "predicable" "no")
> +   (set_attr "cond" "nocond")])
>  
>  (define_insn "mac_600"
>[(set (match_operand:SI 2 "acc2_operand" "")
> @@ -2372,13 +2370,11 @@
> (const_int 0
>]
>"TARGET_MULMAC_32BY16_SET"
> -  "@mululw 0, %0, %1
> -mululw 0, %0, %1
> -mululw%? 0, %1, %0"
> +  "mululw 0, %0, %1"
>[(set_attr "length" "4,4,8")
> (set_attr "type" "mulmac_600")
> -   (set_attr "predicable" "no,no,yes")
> -   (set_attr "cond" "nocond, canuse_limm, canuse")])
> +   (set_attr "predicable" "no")
> +   (set_attr "cond" "nocond")])
>  
>  
>  (define_insn "umac64_600"
> -- 
> 1.9.1
> 

Re: [PATCH] Introduce -Wimplicit-fallthrough={0,1,2,3,4,5}

[Bernd Schmidt]

On 10/12/2016 01:04 PM, Markus Trippelsdorf wrote:

I'm more concerned about the first impression that people will get from
this warning. If the fist couple of samples they will look at are
clearly bogus (as with the example comments above) they will very
quickly disable the warning.

And if a small one digit percentage of all potential issues falls
through the cracks with -Wimplicit-fallthrough=1 , so be it.


Yes. Better to give mostly sensible warnings, making people aware of the 
option and maybe encouraging to try higher levels, rather than 
generating a huge amount of noise which will result in some people 
turning the warning off, some making pointles or even incorrect changes 
to their code (as we saw in gcc itself), and generating bad publicity.



Bernd

Re: [PATCH 1/2] [ARC] Update INSN_LENGTH_ALIGNMENT.

[Andrew Burgess]

* Claudiu Zissulescu  [2016-06-30 12:24:11 
+0200]:

> Update the INSN_LENGTH_ALIGNMENT macro to handle jump tables placed in
> program memory.
> 
> Ok to apply?
> Claudiu

This looks good to me.


Thanks,
Andrew


> 
> 
> gcc/
> 2016-06-20  Claudiu Zissulescu  
> 
>   * config/arc/arc.h (INSN_LENGTH_ALIGNMENT): Change.
> ---
>  gcc/config/arc/arc.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/gcc/config/arc/arc.h b/gcc/config/arc/arc.h
> index 3376ad8..d2adf4d 100644
> --- a/gcc/config/arc/arc.h
> +++ b/gcc/config/arc/arc.h
> @@ -1519,10 +1519,10 @@ extern int arc_return_address_regs[4];
>  #define ASM_OUTPUT_BEFORE_CASE_LABEL(FILE, PREFIX, NUM, TABLE) \
>ASM_OUTPUT_ALIGN ((FILE), ADDR_VEC_ALIGN (TABLE));
>  
> -#define INSN_LENGTH_ALIGNMENT(INSN) \
> -  ((JUMP_P (INSN) \
> +#define INSN_LENGTH_ALIGNMENT(INSN)\
> +  ((JUMP_TABLE_DATA_P (INSN)   \
>  && GET_CODE (PATTERN (INSN)) == ADDR_DIFF_VEC \
> -&& GET_MODE (PATTERN (INSN)) == QImode) \
> +&& GET_MODE (PATTERN (INSN)) == QImode)\
> ? 0 : length_unit_log)
>  
>  /* Define if operations between registers always perform the operation
> -- 
> 1.9.1
> 

Re: Move OVERRIDE/FINAL from gcc/coretypes.h to include/ansidecl.h

[Bernd Schmidt]

On 10/10/2016 09:32 PM, Pedro Alves wrote:

From: Pedro Alves 
Date: 2016-10-10 19:25:47 +0100

Move OVERRIDE/FINAL from gcc/coretypes.h to include/ansidecl.h

So that GDB and other projects that share the top level can use them.


Seems reasonable. OK unless someone objects by the end of the week.


Bernd

Re: [RFC] Speed-up -fprofile-update=atomic

[Martin Liška]

On 10/04/2016 11:45 AM, Richard Biener wrote:
> On Thu, Sep 15, 2016 at 12:00 PM, Martin Liška  wrote:
>> On 09/07/2016 02:09 PM, Richard Biener wrote:
>>> On Wed, Sep 7, 2016 at 1:37 PM, Martin Liška  wrote:
 On 08/18/2016 06:06 PM, Richard Biener wrote:
> On August 18, 2016 5:54:49 PM GMT+02:00, Jakub Jelinek  
> wrote:
>> On Thu, Aug 18, 2016 at 08:51:31AM -0700, Andi Kleen wrote:
 I'd prefer to make updates atomic in multi-threaded applications.
 The best proxy we have for that is -pthread.

 Is it slower, most definitely, but odds are we're giving folks
 garbage data otherwise, which in many ways is even worse.
>>>
>>> It will likely be catastrophically slower in some cases.
>>>
>>> Catastrophically as in too slow to be usable.
>>>
>>> An atomic instruction is a lot more expensive than a single
>> increment. Also
>>> they sometimes are really slow depending on the state of the machine.
>>
>> Can't we just have thread-local copies of all the counters (perhaps
>> using
>> __thread pointer as base) and just atomically merge at thread
>> termination?
>
> I suggested that as well but of course it'll have its own class of issues 
> (short lived threads, so we need to somehow re-use counters from 
> terminated threads, large number of threads and thus using too much 
> memory for the counters)
>
> Richard.

 Hello.

 I've got written the approach on my TODO list, let's see whether it would 
 be doable in a reasonable amount of time.

 I've just finished some measurements to illustrate slow-down of 
 -fprofile-update=atomic approach.
 All numbers are: no profile, -fprofile-generate, -fprofile-generate 
 -fprofile-update=atomic
 c-ray benchmark (utilizing 8 threads, -O3): 1.7, 15.5., 38.1s
 unrar (utilizing 8 threads, -O3): 3.6, 11.6, 38s
 tramp3d (1 thread, -O3): 18.0, 46.6, 168s

 So the slow-down is roughly 300% compared to -fprofile-generate. I'm not 
 having much experience with default option
 selection, but these numbers can probably help.

 Thoughts?
>>>
>>> Look at the generated code for an instrumented simple loop and see that for
>>> the non-atomic updates we happily apply store-motion to the counter update
>>> and thus we only get one counter update per loop exit rather than one per
>>> loop iteration.  Now see what happens for the atomic case (I suspect you
>>> get one per iteration).
>>>
>>> I'll bet this accounts for most of the slowdown.
>>>
>>> Back in time ICC which had atomic counter updates (but using function
>>> calls - ugh!) had a > 1000% overhead with FDO for tramp3d (they also
>>> didn't have early inlining -- removing abstraction helps reducing the number
>>> of counters significantly).
>>>
>>> Richard.
>>
>> Hi.
>>
>> During Cauldron I discussed with Richi approaches how to speed-up ARCS
>> profile counter updates. My first attempt is to utilize TLS storage, where
>> every function is accumulating arcs counters. These are eventually added
>> (using atomic operations) to the global one at the very end of a function.
>> Currently I rely on target support of TLS, which is questionable whether
>> to have such a requirement for -fprofile-update=atomic, or to add a new 
>> option value
>> like -fprofile-update=atomic-tls?
>>
>> Running the patch on tramp3d, compared to previous numbers, it takes 88s to 
>> finish.
>> Time shrinks to 50%, compared to the current implementation.
>>
>> Thoughts?
> 
> Hmm, I thought I suggested that you can simply use automatic storage
> (which effectively
> is TLS...) for regions that are not forked or abnormally left (which
> means SESE regions
> that have no calls that eventually terminate or throw externally).
> 
> So why did you end up with TLS?

Hi.

Usage for TLS does not makes sense, stupid mistake ;)

By using SESE regions, do you mean the infrastructure that is utilized
by Graphite machinery?

Thanks,
Martin

> 
> Richard.
> 
>> Martin
>>
>>>
 Martin

>
>>  Jakub
>
>

>>

[Ada] Missing predicate check with explicit policy pragma

[Arnaud Charlet]

This patch fixes an omission in the generation of predicate checks, when there
is a configuration pragma that sets Assertion_Policy to Ignore and a subsequent
configuration pragma that enables predicate checking.

Executing:

   gnatmake -q main
   main

must yield

raised SYSTEM.ASSERTIONS.ASSERT_FAILURE :
Dynamic_Predicate failed at main.adb:5

---
pragma Assertion_Policy (Ignore);
 pragma Assertion_Policy
   (Static_Predicate => Check,
   Dynamic_Predicate => Check,
   Pre => Check, Pre'Class => Check);
---
with Pred;
procedure Main is
begin
  Pred.Foo ("");
end;
---
package Pred is
  subtype Not_Empty_String is String
with Dynamic_Predicate => Not_Empty_String /= "";
  procedure Foo (S : Not_Empty_String);
end;
---
package body Pred is
  procedure Foo (S : Not_Empty_String) is begin null; end;
end;

Tested on x86_64-pc-linux-gnu, committed on trunk

2016-10-12  Ed Schonberg  

* sem_prag.adb (Analyze_Pragma, case Dynamic_Predicate):
Check properly whether there is an explicit assertion policy
for predicate checking, even in the presence of a general Ignore
assertion policy.

Index: sem_prag.adb
===
--- sem_prag.adb(revision 241048)
+++ sem_prag.adb(working copy)
@@ -19136,15 +19136,17 @@
 --  the rep item chain, for processing when the type is frozen.
 --  This is accomplished by a call to Rep_Item_Too_Late. We also
 --  mark the type as having predicates.
---  If the current policy is Ignore mark the subtype accordingly.
---  In the case of predicates we consider them enabled unless an
---  Ignore is specified, to preserve existing warnings.
 
+--  If the current policy for predicate checking is Ignore mark the
+--  subtype accordingly. In the case of predicates we consider them
+--  enabled unless Ignore is specified (either directly or with a
+--  general Assertion_Policy pragma) to preserve existing warnings.
+
 Set_Has_Predicates (Typ);
 Set_Predicates_Ignored (Typ,
   Present (Check_Policy_List)
 and then
-  Policy_In_Effect (Name_Assertion_Policy) = Name_Ignore);
+  Policy_In_Effect (Name_Dynamic_Predicate) = Name_Ignore);
 Discard := Rep_Item_Too_Late (Typ, N, FOnly => True);
  end Predicate;
 

[Ada] Premature finalization of controlled array component

[Arnaud Charlet]

This patch modifies the processing of transient array components to properly
handle the finalization of the temporary controlled function result when the
call initializes a component choice list or an "others" choice.


-- Source --


--  aggregates.adb

with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
with Ada.Text_IO;   use Ada.Text_IO;

procedure Aggregates is
begin
   declare
  Arr : array (1 .. 3) of Unbounded_String :=
  (2  => To_Unbounded_String ("two"),
   others => To_Unbounded_String ("others"));
   begin
  Put ("others "); Put_Line (To_String (Arr (1)));
  Put ("two"); Put_Line (To_String (Arr (2)));
  Put ("others "); Put_Line (To_String (Arr (3)));
   end;

   declare
  Arr : array (1 .. 4) of Unbounded_String :=
  (1 | 3 | 4 => To_Unbounded_String ("one_three_four"),
   2 => To_Unbounded_String ("two"));
   begin
  Put ("one_three_four "); Put_Line (To_String (Arr (1)));
  Put ("two"); Put_Line (To_String (Arr (2)));
  Put ("one_three_four "); Put_Line (To_String (Arr (3)));
  Put ("one_three_four "); Put_Line (To_String (Arr (4)));
   end;

   declare
  Arr : array (1 .. 3) of Unbounded_String :=
  (1 .. 2 => To_Unbounded_String ("one_two"),
   others => To_Unbounded_String ("others"));
   begin
  Put ("one_two"); Put_Line (To_String (Arr (1)));
  Put ("one_two"); Put_Line (To_String (Arr (2)));
  Put ("others "); Put_Line (To_String (Arr (3)));
   end;

   declare
  Arr : array (1 .. 4) of Unbounded_String :=
  (1  => To_Unbounded_String ("one"),
   2 .. 4 => To_Unbounded_String ("two_four"));
   begin
  Put ("one"); Put_Line (To_String (Arr (1)));
  Put ("two_four   "); Put_Line (To_String (Arr (2)));
  Put ("two_four   "); Put_Line (To_String (Arr (3)));
  Put ("two_four   "); Put_Line (To_String (Arr (4)));
   end;

   declare
  Arr : array (1 .. 5) of Unbounded_String :=
  (1 .. 2 => To_Unbounded_String ("one_two"),
   4 | 5  => To_Unbounded_String ("four_five"),
   others => To_Unbounded_String ("others"));
   begin
  Put ("one_two"); Put_Line (To_String (Arr (1)));
  Put ("one_two"); Put_Line (To_String (Arr (2)));
  Put ("others "); Put_Line (To_String (Arr (3)));
  Put ("four_five  "); Put_Line (To_String (Arr (4)));
  Put ("four_five  "); Put_Line (To_String (Arr (5)));
   end;
end Aggregates;


-- Compilation and output --


$ gnatmake -q aggregates.adb
$ ./aggregates
others others
twotwo
others others
one_three_four one_three_four
twotwo
one_three_four one_three_four
one_three_four one_three_four
one_twoone_two
one_twoone_two
others others
oneone
two_four   two_four
two_four   two_four
two_four   two_four
one_twoone_two
one_twoone_two
others others
four_five  four_five
four_five  four_five

Tested on x86_64-pc-linux-gnu, committed on trunk

2016-10-12  Hristian Kirtchev  

* exp_aggr.adb (Initialize_Ctrl_Array_Component):
Create a copy of the initialization expression to avoid sharing
it between multiple components.

Index: exp_aggr.adb
===
--- exp_aggr.adb(revision 241024)
+++ exp_aggr.adb(working copy)
@@ -1277,6 +1277,7 @@
  is
 Act_Aggr   : Node_Id;
 Act_Stmts  : List_Id;
+Expr   : Node_Id;
 Fin_Call   : Node_Id;
 Hook_Clear : Node_Id;
 
@@ -1285,20 +1286,29 @@
 --  in-place expansion.
 
  begin
+--  Duplicate the initialization expression in case the context is
+--  a multi choice list or an "others" choice which plugs various
+--  holes in the aggregate. As a result the expression is no longer
+--  shared between the various components and is reevaluated for
+--  each such component.
+
+Expr := New_Copy_Tree (Init_Expr);
+Set_Parent (Expr, Parent (Init_Expr));
+
 --  Perform a preliminary analysis and resolution to determine what
 --  the initialization expression denotes. An unanalyzed function
 --  call may appear as an identifier or an indexed component.
 
-if Nkind_In (Init_Expr, N_Function_Call,
-N_Identifier,
-N_Indexed_Component)
-  and then not Analyzed (Init_Expr)
+if Nkind_In (Expr, N_Function_Call,
+   N_Identifier,
+ 

[Ada] Spurious error on renaming of type conversion with invariant.

[Arnaud Charlet]

This patch fixes a spurious error on a renaming of a conversion of the
designated object of a pointer to class-wide type when the target type has
an invariant aspect.

The following must execute quietly:

   gnatmake -gnata -q main
   main

---
with System.Assertions; use System.Assertions;
with Gd; use Gd;
procedure main is
begin
   Foo;
   raise Program_Error;
exception
   when Assert_Failure => null;
end;
--
package CN is
   type CN_Type is private;
private
   type CN_Type is record
  V : Integer := 27;   -- wrong initialization
   end record  with Type_Invariant => V mod 7 = 0;
end;
---
package HD is
   type HD_Type is tagged null record;
   type HD_Class_Pointer is access HD_Type'Class;
end;
---
with CN;
with HD;
package GD is
   type XT is new HD.HD_Type with record
  X : aliased CN.CN_Type;
   end record;
   procedure Foo;
end;
--
package body GD is
   procedure Foo is
  DHP : constant HD.HD_Class_Pointer := new XT;
  DH  : XT renames XT (DHP.all);
   begin
  null;
   end;
end;

Tested on x86_64-pc-linux-gnu, committed on trunk

2016-10-12  Ed Schonberg  

* exp_ch4.adb (Expand_N_Type_Conversion): If the target type
has an invariant aspect, insert invariant call at the proper
place in the code rather than rewriting the expression as an
expression with actions, to prevent spurious semantic errors on
the rewritten conversion when it is the object in a renaming.

Index: exp_ch4.adb
===
--- exp_ch4.adb (revision 241041)
+++ exp_ch4.adb (working copy)
@@ -10577,16 +10577,17 @@
   end if;
 
   --  Check for case of converting to a type that has an invariant
-  --  associated with it. This required an invariant check. We convert
+  --  associated with it. This requires an invariant check. We insert
+  --  a call:
 
-  --typ (expr)
+  --invariant_check (typ (expr))
 
-  --  into
+  --  in the code, after removing side effects from the expression.
+  --  This is clearer than replacing the conversion into an expression
+  --  with actions, because the context may impose additional actions
+  --  (tag checks, membership tests, etc.) that conflict with this
+  --  rewriting (used previously).
 
-  --do invariant_check (typ (expr)) in typ (expr);
-
-  --  using Duplicate_Subexpr to avoid multiple side effects
-
   --  Note: the Comes_From_Source check, and then the resetting of this
   --  flag prevents what would otherwise be an infinite recursion.
 
@@ -10595,12 +10596,8 @@
 and then Comes_From_Source (N)
   then
  Set_Comes_From_Source (N, False);
- Rewrite (N,
-   Make_Expression_With_Actions (Loc,
- Actions=> New_List (
-   Make_Invariant_Call (Duplicate_Subexpr (N))),
- Expression => Duplicate_Subexpr_No_Checks (N)));
- Analyze_And_Resolve (N, Target_Type);
+ Remove_Side_Effects (N);
+ Insert_Action (N, Make_Invariant_Call (Duplicate_Subexpr (N)));
  goto Done;
   end if;
 

[Ada] Allow Refined_Global/Depends contracts with partial refinement

[Arnaud Charlet]

Pragmas/aspects Refined_Global and Refined_Depends may be applied in
a scope where only partial refinement of abstract states is visible,
as defined in SPARK RM 7.2.4. In such a case, the partial refinement
should be used instead of the full refinement for checking the refined
contracts.

Tested on x86_64-pc-linux-gnu, committed on trunk

2016-10-12  Yannick Moy  

* einfo.adb, einfo.ads (Has_Partial_Visible_Refinement): New flag
in abtract states.
(Has_Non_Null_Visible_Refinement): Return true for patial refinement.
(Partial_Refinement_Constituents): New function returns the full or
partial refinement constituents depending on scope.
* sem_ch3.adb (Analyze_Declarations): Remove partial visible
refinements when exiting the scope of a package spec or body
and those partial refinements are not in scope afterwards.
* sem_ch7.adb, sem_ch7.ads (Install_Partial_Declarations): Mark
abstract states of parent units with partial refinement so that
it is visible.
* sem_prag.adb (Analyze_Part_Of_In_Decl_Part): Mark enclosing
abstract state if any as having partial refinement in that scope.
(Analyze_Refined_Global_In_Decl_Part): Check constituent usage
based on full or partial refinement depending on scope.

Index: sem_ch3.adb
===
--- sem_ch3.adb (revision 241041)
+++ sem_ch3.adb (working copy)
@@ -2178,10 +2178,17 @@
   --  case, add a proper spec if the body lacks one. The spec is inserted
   --  before Body_Decl and immediately analyzed.
 
+  procedure Remove_Partial_Visible_Refinements (Spec_Id : Entity_Id);
+  --  Spec_Id is the entity of a package that may define abstract states,
+  --  and in the case of a child unit, whose ancestors may define abstract
+  --  states. If the states have partial visible refinement, remove the
+  --  partial visibility of each constituent at the end of the package
+  --  spec and body declarations.
+
   procedure Remove_Visible_Refinements (Spec_Id : Entity_Id);
   --  Spec_Id is the entity of a package that may define abstract states.
   --  If the states have visible refinement, remove the visibility of each
-  --  constituent at the end of the package body declarations.
+  --  constituent at the end of the package body declaration.
 
   -
   -- Adjust_Decl --
@@ -2335,6 +2342,29 @@
  Insert_Before_And_Analyze (Body_Decl, Decl);
   end Handle_Late_Controlled_Primitive;
 
+  
+  -- Remove_Partial_Visible_Refinements --
+  
+
+  procedure Remove_Partial_Visible_Refinements (Spec_Id : Entity_Id) is
+ State_Elmt : Elmt_Id;
+  begin
+ if Present (Abstract_States (Spec_Id)) then
+State_Elmt := First_Elmt (Abstract_States (Spec_Id));
+while Present (State_Elmt) loop
+   Set_Has_Partial_Visible_Refinement (Node (State_Elmt), False);
+   Next_Elmt (State_Elmt);
+end loop;
+ end if;
+
+ --  For a child unit, also hide the partial state refinement from
+ --  ancestor packages.
+
+ if Is_Child_Unit (Spec_Id) then
+Remove_Partial_Visible_Refinements (Scope (Spec_Id));
+ end if;
+  end Remove_Partial_Visible_Refinements;
+
   
   -- Remove_Visible_Refinements --
   
@@ -2576,6 +2606,15 @@
 --  restore the original state conditions.
 
 Remove_Visible_Refinements (Corresponding_Spec (Context));
+Remove_Partial_Visible_Refinements (Corresponding_Spec (Context));
+
+ elsif Nkind (Context) = N_Package_Declaration then
+
+--  Partial state refinements are visible up to the end of the
+--  package spec declarations. Hide the partial state refinements
+--  from visibility to restore the original state conditions.
+
+Remove_Partial_Visible_Refinements (Corresponding_Spec (Context));
  end if;
 
  --  Verify that all abstract states found in any package declared in
Index: sem_ch7.adb
===
--- sem_ch7.adb (revision 241024)
+++ sem_ch7.adb (working copy)
@@ -2275,6 +2275,34 @@
  Next_Entity (Id);
   end loop;
 
+  --  An abstract state is partially refined when it has at least one
+  --  Part_Of constituent. Since these constituents are being installed
+  --  into visibility, update the partial refinement status of any state
+  --  defined in the associated package, subject to at least one Part_Of
+  --  constituent.
+
+  if Ekind_In (P, E_Generic_Package, E_Package) then
+ declare
+States 

Re: [PATCH] Implement new hook for max_align_t_align

[Jason Merrill]

On Wed, Oct 12, 2016 at 4:02 AM, Jakub Jelinek  wrote:
> On Wed, Oct 12, 2016 at 09:52:04AM +0200, Florian Weimer wrote:
>> dropping the alignment means that the padding before the lock member
>> vanishes.  Consequently, we have just created a silent ABI change in
>> application code, which is a big no-no.
>
> Sure, it would be an ABI change, but how many users would it affect?
>
>> Since this is PA-RISC, which is essentially dead (neither HPE nor Debian
>> ship it anymore), I stand by my suggestion to bump the fundamental alignment
>
> Or just drop support for a dead arch?
>
>> instead.  Sure, it is a bit inefficient, but this will only affect PA-RISC
>> users.  It does not even cause work for PA-RISC porters. Conversely, if we
>> work on this to come up with a different fix, many more people will be
>> affected (because they don't get all the nice things we could work on
>> instead), and we may need to maintain a special GCC kludge for the
>> alternative solution, impacting GCC developers in particular.
>
> But sure, bumping malloc alignment is probably easiest.  And people who want
> performance have better options than to stay on 32-bit PA-RISC anyway.

Or we could do nothing and tell people to ignore the harmless warning.

Jason

[RFC] Possible folding opportunities for string built-ins

[Martin Liška]

Hi.

As you probably mentioned, simple folding improvement has grown to multiple 
patches
and multiple iterations. Apart from that, I also noticed that we do not do the 
best
for couple of cases and I would like to have a feedback if it worth to improve 
or not?

$ cat /tmp/string-folding-missing.c 
const char global_1[4] = {'a', 'b', 'c', 'd' };
const char global_2[6] = "abcdefghijk";

int main()
{
  const char local1[] = "asdfasdfasdf";

  /* Case 1 */
  __builtin_memchr (global_1, 'c', 5);

  /* Case 2 */
  __builtin_memchr (global_2, 'c', 5);

  /* Case 3 */
  __builtin_memchr (local1, 'a', 5);

  return 0;
}

Cases:
1) Currently, calling c_getstr (which calls string_constant) can't handle 
CONSTRUCTOR. Potential
solution can be to create on demand STRING_CST, however as string_constant is 
called multiple times,
it can be overkill.
2) /tmp/x.c:2:26: warning: initializer-string for array of chars is too long
 const char global_2[6] = "abcdefghijk";
Here I'm not sure whether one can consider global_2 == "abcdef" (w/o trailing 
zero char) or not?
If so, adding new output argument (string_length) to string_constant can be 
solution.
3) Currently, ctor_for_folding return error_mark_node for local variables. I'm 
wondering whether returning
DECL_INITIAL for these would be doable? Will it make any issue for LTO?

Last question is whether one can aggressively fold strcasecmp in a host 
compiler? Or are there any situations
where results depends on locale?

Thanks for thoughts.
Martin

Re: Questionable code in gcov-io.c

[Nathan Sidwell]

On 10/12/16 09:43, Marek Polacek wrote:


ITYM lines 197 -> 203.  I.e. remove the entire if that;s inside the 'mode ==
0' branch and make line 203 unconditional.


Yes, sorry for sloppy wording.  I'm testing a patch.


heh, so am I :)

nathan

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

[Jason Merrill]

On Tue, Oct 11, 2016 at 9:45 PM, Martin Sebor  wrote:
> Are there any other changes you want me to make to the patch?
> I leave this weekend for the WG14 meeting and would like to
> get this change finalized and hopefully committed before then.
>
>   https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00410.html

OK, thanks.  Sorry I overlooked your earlier mail.

Jason

Re: Questionable code in gcov-io.c

[Marek Polacek]

On Wed, Oct 12, 2016 at 08:14:58AM -0400, Nathan Sidwell wrote:
> On 10/12/16 08:10, Marek Polacek wrote:
> > While implementing a warning I noticed this in gcov-io.c:
> > 
> >  187   else if (mode == 0)
> >  188 {
> >  189   struct stat st;
> >  190
> >  191   if (fstat (fd, ) < 0)
> >  192 {
> >  193   fclose (gcov_var.file);
> >  194   gcov_var.file = 0;
> >  195   return 0;
> >  196 }
> >  197   if (st.st_size != 0)
> >  198 gcov_var.mode = 1;
> >  199   else
> >  200 gcov_var.mode = mode * 2 + 1;
> >  201 }
> >  202   else
> >  203 gcov_var.mode = mode * 2 + 1;
> > 
> > It seems that lines 198 and 200 do the same thing, at line 200 we know that
> > mode == 0, so we just assign 1.  Should we just remove the condition on 
> > line 197?
> 
> ITYM lines 197 -> 203.  I.e. remove the entire if that;s inside the 'mode ==
> 0' branch and make line 203 unconditional.

Yes, sorry for sloppy wording.  I'm testing a patch.

Thanks,

Marek

Re: Fix LTO_STREAMER_DEBUG build

[Thomas Schwinge]

Hi!

On Thu, 29 Sep 2016 17:29:29 +0200, Richard Biener  
wrote:
> On September 29, 2016 4:54:36 PM GMT+02:00, Thomas Schwinge 
>  wrote:
> >While working on something else, I found LTO_STREAMER_DEBUG broken.
> >Enabling (#define) gcc/lto-stream.h:LTO_STREAMER_DEBUG, some further
> >checking is done on the LTO streamer (writer/reader), and some
> >additional
> >debugging hooks are provided.  In the end, I didn't use this facility
> >for
> >my debugging, but here is anyway the patch to un-break it.  Not yet
> >thoroughly tested, will do that later -- OK for trunk then?
> 
> Works for me though I'd expect the checking code to be broken (I foubd it 
> hardly useful)

;-) Well, I just filed  "LTO_STREAMER_DEBUG
ICE with OpenMP SIMD clones".

Without changes committed in r241046:

commit 2e5bb449b8f67130b235ea4e3643929041bb495e
Author: tschwinge 
Date:   Wed Oct 12 13:18:36 2016 +

Fix LTO_STREAMER_DEBUG build

gcc/
* lto-streamer.c: Fix LTO_STREAMER_DEBUG build.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241046 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog  |  2 ++
 gcc/lto-streamer.c | 12 ++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index c66b7a7..e709adb 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,5 +1,7 @@
 2016-10-12  Thomas Schwinge  
 
+   * lto-streamer.c: Fix LTO_STREAMER_DEBUG build.
+
* dwarf2out.c (dwarf2_lineno_debug_hooks): Use
dwarf2out_assembly_start.
 
diff --git gcc/lto-streamer.c gcc/lto-streamer.c
index bfde1fe..a44a916 100644
--- gcc/lto-streamer.c
+++ gcc/lto-streamer.c
@@ -267,23 +267,23 @@ struct tree_hash_entry
 
 struct tree_entry_hasher : nofree_ptr_hash 
 {
-  static inline hashval_t hash (const value_type *);
-  static inline bool equal (const value_type *, const compare_type *);
+  static inline hashval_t hash (const tree_hash_entry *);
+  static inline bool equal (const tree_hash_entry *, const tree_hash_entry *);
 };
 
 inline hashval_t
-tree_entry_hasher::hash (const value_type *e)
+tree_entry_hasher::hash (const tree_hash_entry *e)
 {
   return htab_hash_pointer (e->key);
 }
 
 inline bool
-tree_entry_hasher::equal (const value_type *e1, const compare_type *e2)
+tree_entry_hasher::equal (const tree_hash_entry *e1, const tree_hash_entry *e2)
 {
   return (e1->key == e2->key);
 }
 
-static hash_table *tree_htab;
+static hash_table *tree_htab;
 #endif
 
 /* Initialization common to the LTO reader and writer.  */
@@ -299,7 +299,7 @@ lto_streamer_init (void)
 streamer_check_handled_ts_structures ();
 
 #ifdef LTO_STREAMER_DEBUG
-  tree_htab = new hash_table (31);
+  tree_htab = new hash_table (31);
 #endif
 }
 


Grüße
 Thomas

Re: Compile-time improvement for if conversion.

[Yuri Rumyantsev]

Richard,

Here is updated patch . I avoided creation of new entry/exit blocks
but instead add check to border cases - do not consider also blocks
which are out of region.

Any comments will be appreciated.

2016-10-11 16:48 GMT+03:00 Richard Biener :
> On Tue, Oct 11, 2016 at 3:23 PM, Yuri Rumyantsev  wrote:
>> Richard,
>>
>> I implemented this by passing callback function in_region which
>> returns true if block belongs to region.
>> I am testing it now
>>
>> I attach modified patch for your quick review.
>
> +  FOR_EACH_VEC_ELT (region, i, bb)
> +{
> +  bb->dom[dir_index] = et_new_tree (bb);
> +}
> +  /* Check that region is SESE region.  */
> +  entry = region[0];
> +  if ( EDGE_COUNT (entry->succs) > 1)
> +{
> +  /* Create new entry block with the only successor.  */
> +  basic_block succ = NULL;
> +  bool found = false;
> +  FOR_EACH_EDGE (e, ei, entry->succs)
> +   if (in_region (region, e->dest))
> + {
> +   gcc_assert (!found);
>
> is that check equal to e->dest->dom[dir_index] != NULL?  I think we
> shouldn't need the callback.
>
> +new_entry = create_empty_bb (entry);
> +unchecked_make_edge (new_entry, succ, 0);
>
> I still think this is somewhat gross and we should try to avoid it
> somehow - at least it's well-hidden now ;)
>
> +/* Put it to region as entry node.  */
> +region[0] = new_entry;
>
> so region[0] is overwritten now?
>
> As far as I understand calc_dfs_tree it should be possible to compute
> the region on-the-fly
> from calling calc_dfs_tree_nonrec on the entry/exit (also maybe
> avoiding some of the still
> "large" complexity of zeroing arrays in the constructor).
>
> And if we use that DFS walk directly we should be able to avoid
> creating those fake entry/exit
> blocks by using entry/exit edges instead... (somehow).
>
> Richard.
>
>
>
>> Thanks.
>>
>> 2016-10-11 13:33 GMT+03:00 Richard Biener :
>>> On Mon, Oct 10, 2016 at 4:17 PM, Yuri Rumyantsev  wrote:
 Richard,

 If "fake" exit or entry block is created in dominance how we can
 determine what is its the only  predecessor or successor without using
 a notion of loop?
>>>
>>> The caller passes in an entry and exit edge instead of a block or loop.
>>>
>>> Richard.
>>>
 2016-10-10 15:00 GMT+03:00 Richard Biener :
> On Mon, Oct 10, 2016 at 1:42 PM, Yuri Rumyantsev  
> wrote:
>> Thanks Richard for your comments.
>> I'd like to answer on your last comment regarding use split_edge()
>> instead of creating fake post-header. I started with this splitting
>> but it requires to fix-up closed ssa form by creating additional phi
>> nodes, so I decided to use only cfg change without updating ssa form.
>> Other changes look reasonable and will fix them.
>
> Ah.  In this case can you investigate what it takes to make the entry/exit
> edges rather than BBs?  That is, introduce those "fakes" only internally
> in dominance.c?
>
>> 2016-10-10 12:52 GMT+03:00 Richard Biener :
>>> On Wed, Oct 5, 2016 at 3:22 PM, Yuri Rumyantsev  
>>> wrote:
 Hi All,

 Here is implementation of Richard proposal:

 < For general infrastructure it would be nice to expose a 
 (post-)dominator
 < compute for MESE (post-dominators) / SEME (dominators) regions.  I 
 believe
 < what makes if-conversion expensive is the post-dom compute which 
 happens
 < for each loop for the whole function.  It shouldn't be very difficult
 < to write this,
 < sharing as much as possible code with the current DOM code might need
 < quite some refactoring though.

 I implemented this proposal by adding calculation of dominance info
 for SESE regions and incorporate this change to if conversion pass.
 SESE region is built by adding loop pre-header and possibly fake
 post-header blocks to loop body. Fake post-header is deleted after
 predication completion.

 Bootstrapping and regression testing did not show any new failures.

 Is it OK for trunk?
>>>
>>> It's mostly reasonable but I have a few comments.  First, re-using
>>> bb->dom[] for the dominator info is somewhat fragile but indeed
>>> a requirement to make the patch reasonably small.  Please,
>>> in calculate_dominance_info_for_region, make sure that
>>> !dom_info_available_p (dir).
>>>
>>> You pass loop * everywhere but require ->aux to be set up as
>>> an array of BBs forming the region with special BBs at array ends.
>>>
>>> Please instead pass in a vec which avoids using ->aux
>>> and also allows other non-loop-based SESE regions to be used
>>> (I 

[PATCH] Make test helper work with non-copyable types

[Jonathan Wakely]

This test utility does: "T t = T();" to guarantee value-init, and then
some std::atomic tests have dg-error directives to handle the errors
that happen because atomics are non-copyable. In C++17 there is no
error, because of guaranteed elision, so the dg-errors FAIL.

For C++11 we can us "T t{};" instead, which means there are no errors
for non-copyable types, and we don't get different errors for C++11
and C++17.

* testsuite/util/testsuite_common_types.h
(bitwise_assignment_operators): Use direct-initialization for C++11
and later, to avoid CopyConstructible requirement.
* testsuite/29_atomics/atomic/cons/assign_neg.cc: Adjust dg-error
line numbers.
* testsuite/29_atomics/atomic/cons/copy_neg.cc: Likewise.
* testsuite/29_atomics/atomic_integral/cons/assign_neg.cc: Likewise.
* testsuite/29_atomics/atomic_integral/cons/copy_neg.cc: Likewise.
* testsuite/29_atomics/atomic_integral/operators/bitwise_neg.cc:
Adjust expected errors and line numbers.

Tested powerpc64le-linux, committed to trunk.

commit 588104840e79d4fdad1eba26ac83a511d9b6ab27
Author: Jonathan Wakely 
Date:   Wed Oct 12 13:17:05 2016 +0100

Make test helper work with non-copyable types

* testsuite/util/testsuite_common_types.h
(bitwise_assignment_operators): Use direct-initialization for C++11
and later, to avoid CopyConstructible requirement.
* testsuite/29_atomics/atomic/cons/assign_neg.cc: Adjust dg-error
line numbers.
* testsuite/29_atomics/atomic/cons/copy_neg.cc: Likewise.
* testsuite/29_atomics/atomic_integral/cons/assign_neg.cc: Likewise.
* testsuite/29_atomics/atomic_integral/cons/copy_neg.cc: Likewise.
* testsuite/29_atomics/atomic_integral/operators/bitwise_neg.cc:
Adjust expected errors and line numbers.

diff --git a/libstdc++-v3/testsuite/29_atomics/atomic/cons/assign_neg.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic/cons/assign_neg.cc
index eb0111d..4136944 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic/cons/assign_neg.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/cons/assign_neg.cc
@@ -27,5 +27,5 @@ int main()
   return 0;
 }
 
-// { dg-error "deleted" "" { target *-*-* } 615 }
+// { dg-error "deleted" "" { target *-*-* } 620 }
 // { dg-prune-output "include" }
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic/cons/copy_neg.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic/cons/copy_neg.cc
index 546ac50..ffc2dc2 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic/cons/copy_neg.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/cons/copy_neg.cc
@@ -27,5 +27,5 @@ int main()
   return 0;
 }
 
-// { dg-error "deleted" "" { target *-*-* } 654 }
+// { dg-error "deleted" "" { target *-*-* } 659 }
 // { dg-prune-output "include" }
diff --git 
a/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/assign_neg.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/assign_neg.cc
index c5b6103..20f263c 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/assign_neg.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/assign_neg.cc
@@ -28,5 +28,5 @@ int main()
   return 0;
 }
 
-// { dg-error "deleted" "" { target *-*-* } 615 }
+// { dg-error "deleted" "" { target *-*-* } 620 }
 // { dg-prune-output "include" }
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/copy_neg.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/copy_neg.cc
index 49e1eb1..bf7cda8 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/copy_neg.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/copy_neg.cc
@@ -28,5 +28,5 @@ int main()
   return 0;
 }
 
-// { dg-error "deleted" "" { target *-*-* } 654 }
+// { dg-error "deleted" "" { target *-*-* } 659 }
 // { dg-prune-output "include" }
diff --git 
a/libstdc++-v3/testsuite/29_atomics/atomic_integral/operators/bitwise_neg.cc 
b/libstdc++-v3/testsuite/29_atomics/atomic_integral/operators/bitwise_neg.cc
index db0c3c1..731513b 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_integral/operators/bitwise_neg.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_integral/operators/bitwise_neg.cc
@@ -26,10 +26,8 @@ int main()
   return 0;
 }
 
-// { dg-error "deleted" "" { target *-*-* } 469 }
-// { dg-error "deleted" "" { target *-*-* } 470 }
-// { dg-error "operator" "" { target *-*-* } 471 }
-// { dg-error "operator" "" { target *-*-* } 472 }
-// { dg-error "operator" "" { target *-*-* } 473 }
+// { dg-error "operator" "" { target *-*-* } 476 }
+// { dg-error "operator" "" { target *-*-* } 477 }
+// { dg-error "operator" "" { target *-*-* } 478 }
 
 // { dg-prune-output "declared here" }
diff --git a/libstdc++-v3/testsuite/util/testsuite_common_types.h 
b/libstdc++-v3/testsuite/util/testsuite_common_types.h
index 2f3732e..3233676 100644
--- a/libstdc++-v3/testsuite/util/testsuite_common_types.h
+++ 

Re: [PATCH] Fix PR77826

[Richard Biener]

On Wed, 12 Oct 2016, Marc Glisse wrote:

> On Wed, 12 Oct 2016, Richard Biener wrote:
> 
> > So with doing the same on GENERIC I hit
> > 
> > FAIL: g++.dg/cpp1y/constexpr-array4.C  -std=c++14 (test for excess errors)
> > 
> > with the pattern
> > 
> >  /* (T)(P + A) - (T)P -> (T) A */
> >  (for add (plus pointer_plus)
> >   (simplify
> >(minus (convert (add @0 @1))
> > (convert @0))
> 
> Ah, grep missed that one because it is on 2 lines :-(
> 
> >...
> > (convert @1
> > 
> > 
> > no longer applying to
> > 
> > (long int) ((int *)  + 12) - (long int) 
> > 
> > because while (int *)  is equal to (long int)  (operand_equal_p
> > does STRIP_NOPS) they obviously do not have the same type.
> 
> I believe we are comparing (int *)  to , not to (long int)  But yes,
> indeed.
> 
> > So on GENERIC we have to consider that we feed operand_equal_p with
> > non-ATOMs (arbitrary expressions).  The pattern above is "safe" as it
> > doesn't reference @0 in the result (not sure if we should take advantage of
> > that in genmatch).
> 
> Since we are in the process of defining an
> operand_equal_for_(generic|gimple)_match_p, we could tweak it to check the
> type only for INTEGER_CST, or to still STRIP_NOPS, or similar.
> 
> Or we could remain very strict and refine the pattern, allowing a convert on
> the pointer (we might want to split the plus and pointer_plus versions then,
> for clarity). There are not many optimizations that are mandated by front-ends
> and for which this is an issue.
> 
> > The other FAILs with doing the same on GENERIC are
> > 
> > FAIL: g++.dg/gomp/declare-simd-3.C  -std=gnu++11 (test for excess errors)
> > FAIL: g++.dg/torture/pr71448.C   -O0  (test for excess errors)
> > FAIL: g++.dg/vect/simd-clone-6.cc  -std=c++11 (test for excess errors)
> > 
> > the simd ones are 'warning: ignoring large linear step' and the pr71448.C
> > case is very similar to the above.
> 
> Yes, I expect they all come from the same 1 or 2 transformations.
> 
> > > > > If we stick to the old behavior, maybe we could have some genmatch
> > > > > magic to help with the constant capture weirdness. With matching
> > > > > captures, we could select which operand (among those supposed to be
> > > > > equivalent) is actually captured more cleverly, either with an
> > > > > explicit marker, or by giving priority to the one that is not
> > > > > immediatly below convert? in the pattern.
> > > > 
> > > > This route is a difficult one to take
> > > 
> > > The simplest version I was thinking about was @0 for a true capture, and
> > > @@0
> > > for something that just has to be checked for equality with @0.
> > 
> > Hmm, ok.  So you'd have @@0 having to match @0 and we'd get the @0 for
> > the result in a reliable way?  Sounds like a reasonable idea, I'll see
> > how that works out (we could auto-detect '@@' if the capture is not
> > used in the result, see above).
> 
> It probably doesn't bring much compared to the @0@4 syntax you were 
> suggesting below, so if that is easier...

Will figure that out ...

> > > > -- what would be possible is to
> > > > capture a specific operand.  Like allow one to write
> > > > 
> > > > (op (op @0@4 @1) (op @0@3 @2))
> > > > 
> > > > and thus actually have three "names" for @0.  We have this internally
> > > > already when you write
> > > > 
> > > > (convert?@0 @1)
> > > > 
> > > > for the case where there is no conversion.  @0 and @1 are the same
> > > > in this case.
> > > 
> > > Looks nice and convenient (assuming lax constant matching).
> > 
> > Yes, w/o lax matching it has of course little value.
> > 
> > > > Not sure if this helps enough cases.
> > > 
> > > IIRC, in all cases where we had trouble with operand_equal_p, chosing
> > > which
> > > operand to capture would have solved the issue.
> > 
> > Yes.  We'd still need to actually catch all those cases...
> 
> Being forced to chose which operand we capture (say with @ vs @@, making 2
> occurences of @0 a syntax error) might help, but it would also require
> updating many patterns for which this was never an issue (easy but boring).

We can even have today

 (plus (minus @0 @1) (plus @0 @2) @0)

thus three matching @0.  Now if we have @@ telling to use value equality
rather than "node equality" _and_ making the @@ select the canonical
operand to choose then we'd have at most one @@ per ID.  Somewhat tricky
but not impossible to implement I think.

> > > > I still think that having two things matched that are not really
> > > > the same is werid (and a possible source of errors as in, ICEs,
> > > > rather than missed optimizations).
> > > 
> > > Ok. Let's go with the strict matching, it is indeed less confusing.
> > 
> > I'll hold off with the GENERIC strict matching and will investigate
> > the @@ idea (plus auto-detecting it).
> > 
> > > > > And if we move to stricter matching, maybe genmatch could be updated
> > > > > so
> > > > > convert could also match integer constants in some cases.
> > > > 
> > > > You mean when 

Re: Un-break dwarf2out for DWARF2_LINENO_DEBUGGING_INFO configurations (was: [PATCH] Refactor section/label init for early LTO debug)

[Thomas Schwinge]

Hi!

On Wed, 28 Sep 2016 11:28:16 +0200 (CEST), Richard Biener  
wrote:
> On Wed, 28 Sep 2016, Thomas Schwinge wrote:
> > ([...] got committed in r240545.)  For DWARF2_LINENO_DEBUGGING_INFO
> > configurations (that is, nvptx; Bernd CCed, who originally authored the
> > DWARF2_LINENO_DEBUGGING_INFO support), this breaks things because of
> > uninitialized text_section_line_info/cur_line_info_table.  OK to fix as
> > follows?
> 
> Ok.

Without changes committed to trunk in r241045:

commit 84cb1b769377413a1b7cef73fc4f6022e046b0a9
Author: tschwinge 
Date:   Wed Oct 12 13:09:26 2016 +

Un-break dwarf2out for DWARF2_LINENO_DEBUGGING_INFO configurations

gcc/
* dwarf2out.c (dwarf2_lineno_debug_hooks): Use
dwarf2out_assembly_start.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241045 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog   | 3 +++
 gcc/dwarf2out.c | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index d6880d9..c66b7a7 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,5 +1,8 @@
 2016-10-12  Thomas Schwinge  
 
+   * dwarf2out.c (dwarf2_lineno_debug_hooks): Use
+   dwarf2out_assembly_start.
+
* Makefile.in (SELFTEST_FLAGS): Add -nostdinc.
 
* Makefile.in (SELFTEST_FLAGS): New variable.
diff --git gcc/dwarf2out.c gcc/dwarf2out.c
index b5787ef..98deeef 100644
--- gcc/dwarf2out.c
+++ gcc/dwarf2out.c
@@ -2540,7 +2540,7 @@ const struct gcc_debug_hooks dwarf2_lineno_debug_hooks =
   dwarf2out_init,
   debug_nothing_charstar,
   debug_nothing_charstar,
-  debug_nothing_void,
+  dwarf2out_assembly_start,
   debug_nothing_int_charstar,
   debug_nothing_int_charstar,
   debug_nothing_int_charstar,


Grüße
 Thomas

Re: [PATCH] Test folding of str{n}{case}cmp and memchr (version 3)

[Martin Liška]

On 10/12/2016 10:34 AM, Richard Biener wrote:
> On Tue, Oct 11, 2016 at 11:38 AM, Martin Liška  wrote:
>> Third iteration of tests, where I added both GENERIC and GIMPLE folding
>> tests.
> 
> They should work already with -O1?

Yes, they work. Sending new version where I also added few situations
that trigger an undefined behavior (and should not be folded).

Martin

> 
> Otherwise ok.
> 
> Richard.
> 
>> Martin

>From bae7f32a3f602d111ac67019c6cd6dd8efacae00 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 16 Aug 2016 15:56:01 +0200
Subject: [PATCH 5/5] Test folding of str{n}{case}cmp and memchr

gcc/testsuite/ChangeLog:

2016-08-16  Martin Liska  

	* gcc.dg/tree-ssa/builtins-folding-generic.c: New test.
	* gcc.dg/tree-ssa/builtins-folding-gimple.c: Likewise.
	* gcc.dg/tree-ssa/builtins-folding-gimple-ub.c: Likewise.
---
 .../gcc.dg/tree-ssa/builtins-folding-generic.c |  76 +++
 .../gcc.dg/tree-ssa/builtins-folding-gimple-ub.c   |  23 
 .../gcc.dg/tree-ssa/builtins-folding-gimple.c  | 140 +
 3 files changed, 239 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-generic.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-gimple-ub.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-gimple.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-generic.c b/gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-generic.c
new file mode 100644
index 000..175feff
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-generic.c
@@ -0,0 +1,76 @@
+/* { dg-do run } */
+/* { dg-options "-O1 -fdump-tree-original" } */
+
+char *buffer1;
+char *buffer2;
+
+#define SIZE 1000
+
+int
+main (void)
+{
+  const char* const foo1 = "hello world";
+
+  buffer1 = __builtin_malloc (SIZE);
+  __builtin_strcpy (buffer1, foo1);
+  buffer2 = __builtin_malloc (SIZE);
+  __builtin_strcpy (buffer2, foo1);
+
+  /* MEMCHR.  */
+  if (__builtin_memchr ("hello world", 'x', 11))
+__builtin_abort ();
+  if (__builtin_memchr ("hello world", 'x', 0) != 0)
+__builtin_abort ();
+  if (__builtin_memchr ("hello world", 'w', 2))
+__builtin_abort ();
+  if (__builtin_memchr ("hello world", 'd', 10))
+__builtin_abort ();
+  if (__builtin_memchr ("hello world", '\0', 11))
+__builtin_abort ();
+
+  /* STRCMP.  */
+  if (__builtin_strcmp ("hello", "a") <= 0)
+__builtin_abort ();
+  if (__builtin_strcmp ("a", "a") != 0)
+__builtin_abort ();
+  if (__builtin_strcmp ("a", "") <= 0)
+__builtin_abort ();
+  if (__builtin_strcmp ("", "a") >= 0)
+__builtin_abort ();
+  if (__builtin_strcmp ("ab", "ba") >= 0)
+__builtin_abort ();
+
+  /* STRNCMP.  */
+  if (__builtin_strncmp ("hello", "a", 0) != 0)
+__builtin_abort ();
+  if (__builtin_strncmp ("a", "a", 100) != 0)
+__builtin_abort ();
+  if (__builtin_strncmp ("a", "", 100) <= 0)
+__builtin_abort ();
+  if (__builtin_strncmp ("", "a", 100) >= 0)
+__builtin_abort ();
+  if (__builtin_strncmp ("ab", "ba", 1) >= 0)
+__builtin_abort ();
+  if (__builtin_strncmp ("aab", "aac", 2) != 0)
+__builtin_abort ();
+
+  /* STRCASECMP.  */
+  if (__builtin_strcasecmp ("a", "a") != 0)
+__builtin_abort ();
+
+  /* STRNCASECMP.  */
+  if (__builtin_strncasecmp ("hello", "a", 0) != 0)
+__builtin_abort ();
+  if (__builtin_strncasecmp ("a", "a", 100) != 0)
+__builtin_abort ();
+  if (__builtin_strncasecmp ("aab", "aac", 2) != 0)
+__builtin_abort ();
+
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-not "__builtin_strcmp" "original" } } */
+/* { dg-final { scan-tree-dump-not "__builtin_strcasecmp" "original" } } */
+/* { dg-final { scan-tree-dump-not "__builtin_strncmp" "original" } } */
+/* { dg-final { scan-tree-dump-not "__builtin_strncasecmp" "original" } } */
+/* { dg-final { scan-tree-dump-not "__builtin_memchr" "original" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-gimple-ub.c b/gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-gimple-ub.c
new file mode 100644
index 000..df0ede2
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-gimple-ub.c
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -fdump-tree-optimized" } */
+
+char *buffer1;
+char *buffer2;
+
+#define SIZE 1000
+
+int
+main (void)
+{
+  const char* const foo1 = "hello world";
+
+  /* MEMCHR.  */
+  if (__builtin_memchr ("", 'x', 1000)) /* Not folded away.  */
+__builtin_abort ();
+  if (__builtin_memchr (foo1, 'x', 1000)) /* Not folded away.  */
+__builtin_abort ();
+
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-times "__builtin_memchr" 2 "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-gimple.c b/gcc/testsuite/gcc.dg/tree-ssa/builtins-folding-gimple.c
new file mode 100644
index 000..4cac93a
--- /dev/null
+++ 

Re: [PATCH] Fold __builtin_memchr (version 3)

[Martin Liška]

On 10/12/2016 10:35 AM, Richard Biener wrote:
> On Tue, Oct 11, 2016 at 11:38 AM, Martin Liška  wrote:
>> One question that comes to my mind is whether there's a possibility
>> to fully test gimple folding of all cases if some of them are already
>> eaten by generic folding?
> 
> The only way is to make GENERIC folding not trigger by pushing
> constants to temporaries.
> 
> Richard.
> 

Good idea, I've done that in the patch with tests. I made a small revision to
patch, where I utilize the new c_getstr function arguments to handle more
cases.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests
as a whole series.

Martin
>From bc96a7b30764a098d47fa65bd1682005111febdf Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 6 Oct 2016 17:52:45 +0200
Subject: [PATCH 4/5] Fold __builtin_memchr function

gcc/ChangeLog:

2016-10-06  Martin Liska  

	* builtins.h(target_char_cst_p): Declare the function.
	* builtins.c (fold_builtin_memchr): Remove.
	(target_char_cst_p): Move the function from gimple-fold.c.
	(fold_builtin_3): Do not call the function.
	* gimple-fold.c (gimple_fold_builtin_memchr): New function.
	(gimple_fold_builtin): Call the function.
	* fold-const-call.c (fold_const_call_1): Handle CFN_BUILT_IN_MEMCHR.
---
 gcc/builtins.c| 59 +---
 gcc/builtins.h|  1 +
 gcc/fold-const-call.c | 41 +
 gcc/gimple-fold.c | 83 ++-
 4 files changed, 125 insertions(+), 59 deletions(-)

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 6696f28..385e78e0 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -148,7 +148,6 @@ static tree rewrite_call_expr (location_t, tree, int, tree, int, ...);
 static bool validate_arg (const_tree, enum tree_code code);
 static rtx expand_builtin_fabs (tree, rtx, rtx);
 static rtx expand_builtin_signbit (tree, rtx);
-static tree fold_builtin_memchr (location_t, tree, tree, tree, tree);
 static tree fold_builtin_memcmp (location_t, tree, tree, tree);
 static tree fold_builtin_isascii (location_t, tree);
 static tree fold_builtin_toascii (location_t, tree);
@@ -7244,47 +7243,6 @@ fold_builtin_sincos (location_t loc,
 			 fold_build1_loc (loc, REALPART_EXPR, type, call)));
 }
 
-/* Fold function call to builtin memchr.  ARG1, ARG2 and LEN are the
-   arguments to the call, and TYPE is its return type.
-   Return NULL_TREE if no simplification can be made.  */
-
-static tree
-fold_builtin_memchr (location_t loc, tree arg1, tree arg2, tree len, tree type)
-{
-  if (!validate_arg (arg1, POINTER_TYPE)
-  || !validate_arg (arg2, INTEGER_TYPE)
-  || !validate_arg (len, INTEGER_TYPE))
-return NULL_TREE;
-  else
-{
-  const char *p1;
-
-  if (TREE_CODE (arg2) != INTEGER_CST
-	  || !tree_fits_uhwi_p (len))
-	return NULL_TREE;
-
-  p1 = c_getstr (arg1);
-  if (p1 && compare_tree_int (len, strlen (p1) + 1) <= 0)
-	{
-	  char c;
-	  const char *r;
-	  tree tem;
-
-	  if (target_char_cast (arg2, ))
-	return NULL_TREE;
-
-	  r = (const char *) memchr (p1, c, tree_to_uhwi (len));
-
-	  if (r == NULL)
-	return build_int_cst (TREE_TYPE (arg1), 0);
-
-	  tem = fold_build_pointer_plus_hwi_loc (loc, arg1, r - p1);
-	  return fold_convert_loc (loc, type, tem);
-	}
-  return NULL_TREE;
-}
-}
-
 /* Fold function call to builtin memcmp with arguments ARG1 and ARG2.
Return NULL_TREE if no simplification can be made.  */
 
@@ -8340,9 +8298,6 @@ fold_builtin_3 (location_t loc, tree fndecl,
 	return do_mpfr_remquo (arg0, arg1, arg2);
 break;
 
-case BUILT_IN_MEMCHR:
-  return fold_builtin_memchr (loc, arg0, arg1, arg2, type);
-
 case BUILT_IN_BCMP:
 case BUILT_IN_MEMCMP:
   return fold_builtin_memcmp (loc, arg0, arg1, arg2);;
@@ -9908,3 +9863,17 @@ is_inexpensive_builtin (tree decl)
 
   return false;
 }
+
+/* Return true if T is a constant and the value cast to a target char
+   can be represented by a host char.
+   Store the casted char constant in *P if so.  */
+
+bool
+target_char_cst_p (tree t, char *p)
+{
+  if (!tree_fits_uhwi_p (t) || CHAR_TYPE_SIZE != HOST_BITS_PER_CHAR)
+return false;
+
+  *p = (char)tree_to_uhwi (t);
+  return true;
+}
diff --git a/gcc/builtins.h b/gcc/builtins.h
index 8d0acd0..5e83646 100644
--- a/gcc/builtins.h
+++ b/gcc/builtins.h
@@ -97,6 +97,7 @@ extern unsigned HOST_WIDE_INT target_percent;
 extern char target_percent_s[3];
 extern char target_percent_c[3];
 extern char target_percent_s_newline[4];
+extern bool target_char_cst_p (tree t, char *p);
 
 extern internal_fn associated_internal_fn (tree);
 extern internal_fn replacement_internal_fn (gcall *);
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 993769c..d84af48 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -28,6 +28,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "fold-const-call.h"
 #include 

Re: [PATCH] Fold __builtin_str{n}{case}cmp functions (version 3)

[Martin Liška]

On 10/12/2016 10:30 AM, Richard Biener wrote:
> On Tue, Oct 11, 2016 at 11:33 AM, Martin Liška  wrote:
>> Changes from the previous version:
>>
>> 1) Handle BUILT_IN_STRNCMP with length == -1.
>> 2) Direct gimple stmts creation and usage gsi_replace_with_seq_vops.
>> (hope using of replace_call_with_value is fine if replacing with a cst?)
> 
> yes
> 
>> 3) lhs == NULL cases are handled (Or is it fine to replace with a nop in 
>> general?
>> Can change a semantic as it may touch a memory.)
>> 4) CFN_BUILT_IN_STRNCMP can handle strncmp (x, y, 0).
>> 5) Handling of CFN_BUILT_IN_STRNCASECMP is added.
>>
>> Testing of the whole series has been running.
> 
> gimple_load_first_char needs a comment.
> 
> +  tree var = gimple_load_first_char (loc, str1, );
> +  if (lhs)
> +   stmt = gimple_build_assign (lhs, NOP_EXPR, var);
> +  else
> +   stmt = gimple_build_nop ();
> 
> I think you don't need the nop() as you have at least one stmt
> from the load.  Likewise for the other cases below.

Thanks, both nits are fixed in the new version.
Apart from that, I added usages of enhanced c_getstr API.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests
as a whole series.

Martin

> 
> Otherwise this patch looks ok now.
> 
> Richard.
> 
> 
> 
>> Martin

>From ec78ca3e97984acd8ef6330424798218568bd6c8 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Wed, 5 Oct 2016 13:18:35 +0200
Subject: [PATCH 3/5] Fold __builtin_str{n}{case}cmp functions

gcc/ChangeLog:

2016-10-06  Martin Liska  

	* builtins.c (fold_builtin_strcmp): Remove function.
	(fold_builtin_strncmp): Likewise.
	(fold_builtin_2): Do not call fold_builtin_strcmp.
	(fold_builtin_3): Do not call fold_builtin_strncmp.
	* fold-const-call.c: Make build_cmp_result global fn.
	* fold-const-call.h: Likewise.
	* gimple-fold.c (gimple_fold_builtin_string_compare): New
	function.
	(gimple_fold_builtin): Call the function.
	* fold-const-call.c (fold_const_call): Handle
	CFN_BUILT_IN_STRCASECMP, CFN_BUILT_IN_STRNCMP and
	CFN_BUILT_IN_STRNCASECMP.
---
 gcc/builtins.c| 138 
 gcc/fold-const-call.c |  43 +---
 gcc/fold-const-call.h |   1 +
 gcc/gimple-fold.c | 189 +-
 4 files changed, 224 insertions(+), 147 deletions(-)

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 6c68198..6696f28 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -150,8 +150,6 @@ static rtx expand_builtin_fabs (tree, rtx, rtx);
 static rtx expand_builtin_signbit (tree, rtx);
 static tree fold_builtin_memchr (location_t, tree, tree, tree, tree);
 static tree fold_builtin_memcmp (location_t, tree, tree, tree);
-static tree fold_builtin_strcmp (location_t, tree, tree);
-static tree fold_builtin_strncmp (location_t, tree, tree, tree);
 static tree fold_builtin_isascii (location_t, tree);
 static tree fold_builtin_toascii (location_t, tree);
 static tree fold_builtin_isdigit (location_t, tree);
@@ -7333,136 +7331,6 @@ fold_builtin_memcmp (location_t loc, tree arg1, tree arg2, tree len)
   return NULL_TREE;
 }
 
-/* Fold function call to builtin strcmp with arguments ARG1 and ARG2.
-   Return NULL_TREE if no simplification can be made.  */
-
-static tree
-fold_builtin_strcmp (location_t loc, tree arg1, tree arg2)
-{
-  if (!validate_arg (arg1, POINTER_TYPE)
-  || !validate_arg (arg2, POINTER_TYPE))
-return NULL_TREE;
-
-  /* If ARG1 and ARG2 are the same (and not volatile), return zero.  */
-  if (operand_equal_p (arg1, arg2, 0))
-return integer_zero_node;
-
-  /* If the second arg is "", return *(const unsigned char*)arg1.  */
-  const char *p2 = c_getstr (arg2);
-  if (p2 && *p2 == '\0')
-{
-  tree cst_uchar_node = build_type_variant (unsigned_char_type_node, 1, 0);
-  tree cst_uchar_ptr_node
-	= build_pointer_type_for_mode (cst_uchar_node, ptr_mode, true);
-
-  return fold_convert_loc (loc, integer_type_node,
-			   build1 (INDIRECT_REF, cst_uchar_node,
-   fold_convert_loc (loc,
-			 cst_uchar_ptr_node,
-			 arg1)));
-}
-
-  /* If the first arg is "", return -*(const unsigned char*)arg2.  */
-  const char *p1 = c_getstr (arg1);
-  if (p1 && *p1 == '\0')
-{
-  tree cst_uchar_node = build_type_variant (unsigned_char_type_node, 1, 0);
-  tree cst_uchar_ptr_node
-	= build_pointer_type_for_mode (cst_uchar_node, ptr_mode, true);
-
-  tree temp
-	= fold_convert_loc (loc, integer_type_node,
-			build1 (INDIRECT_REF, cst_uchar_node,
-fold_convert_loc (loc,
-		  cst_uchar_ptr_node,
-		  arg2)));
-  return fold_build1_loc (loc, NEGATE_EXPR, integer_type_node, temp);
-}
-
-  return NULL_TREE;
-}
-
-/* Fold function call to builtin strncmp with arguments ARG1, ARG2, and LEN.
-   Return NULL_TREE if no simplification can be made.  */
-
-static tree
-fold_builtin_strncmp (location_t loc, tree arg1, tree arg2, tree len)
-{
-  if 

Re: [PATCH] Check \0-termination of string in c_getstr

[Martin Liška]

On 10/11/2016 12:28 PM, Richard Biener wrote:
> On Tue, Oct 11, 2016 at 11:27 AM, Martin Liška  wrote:
>> As mentioned in the email that I reply to, c_getstr should check
>> null termination of string constants.
>>
>> Tests of the whole series have been running.
> 
> Looks ok to me (if testing passes).

Thanks for the review, however I decided to enhance the API to support
a requested length argument (if a string is not null terminated)
and to return length of the string(usable for strn* functions folding).

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests as
a whole series.

Martin

> 
> Thanks,
> Richard.
> 
>> Thanks,
>> Martin

>From e6c16ea038104ef15b087ff9fca23d9b2406e65e Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 10 Oct 2016 12:13:12 +0200
Subject: [PATCH] Enhance c_getstr API

gcc/ChangeLog:

2016-10-10  Martin Liska  

	* fold-const.c (c_getstr): Guard string termination, or validate
	that requested length is within a string constant.
	* fold-const.h (c_getstr): Set default value for the new arg.
---
 gcc/fold-const.c | 44 +++-
 gcc/fold-const.h |  3 ++-
 2 files changed, 37 insertions(+), 10 deletions(-)

diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 02aa484..eb53e84 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -14440,24 +14440,50 @@ fold_build_pointer_plus_hwi_loc (location_t loc, tree ptr, HOST_WIDE_INT off)
 }
 
 /* Return a char pointer for a C string if it is a string constant
-   or sum of string constant and integer constant.  */
+   or sum of string constant and integer constant.
+   If the string constant is properly zero-terminated, the constant is returned.
+   Otherwise, if REQ_LENGTH is a non-negative number, the constant
+   is returned if the string length is greater or equal to REQ_LENGTH.
+   If STRLEN is a valid pointer, length (including terminatinch character)
+   of returned string is stored to the argument.  */
 
 const char *
-c_getstr (tree src)
+c_getstr (tree src, HOST_WIDE_INT req_length, unsigned HOST_WIDE_INT *strlen)
 {
   tree offset_node;
 
+  if (strlen)
+*strlen = 0;
+
   src = string_constant (src, _node);
   if (src == 0)
-return 0;
+return NULL;
 
-  if (offset_node == 0)
-return TREE_STRING_POINTER (src);
-  else if (!tree_fits_uhwi_p (offset_node)
-	   || compare_tree_int (offset_node, TREE_STRING_LENGTH (src) - 1) > 0)
-return 0;
+  unsigned HOST_WIDE_INT offset = 0;
+  if (offset_node != NULL_TREE)
+{
+  if (!tree_fits_uhwi_p (offset_node))
+	return NULL;
+  else
+	offset = tree_to_uhwi (offset_node);
+}
 
-  return TREE_STRING_POINTER (src) + tree_to_uhwi (offset_node);
+  unsigned HOST_WIDE_INT string_length = TREE_STRING_LENGTH (src);
+  const char *string = TREE_STRING_POINTER (src);
+  if (offset > string_length)
+return NULL;
+
+  /* If the string is properly '\0' character terminated, return it.  */
+  if ((string_length > 0 && string[string_length - 1] == 0)
+  || (req_length != -1
+	  && (unsigned HOST_WIDE_INT)req_length <= string_length - offset))
+{
+  if (strlen)
+	*strlen = string_length - offset;
+  return string + offset;
+}
+  else
+return NULL;
 }
 
 #if CHECKING_P
diff --git a/gcc/fold-const.h b/gcc/fold-const.h
index 637e46b..bbf831a 100644
--- a/gcc/fold-const.h
+++ b/gcc/fold-const.h
@@ -182,7 +182,8 @@ extern bool expr_not_equal_to (tree t, const wide_int &);
 extern tree const_unop (enum tree_code, tree, tree);
 extern tree const_binop (enum tree_code, tree, tree, tree);
 extern bool negate_mathfn_p (combined_fn);
-extern const char *c_getstr (tree);
+extern const char *c_getstr (tree src, HOST_WIDE_INT req_length = -1,
+			 unsigned HOST_WIDE_INT *strlen = NULL);
 
 /* Return OFF converted to a pointer offset type suitable as offset for
POINTER_PLUS_EXPR.  Use location LOC for this conversion.  */
-- 
2.9.2

Re: [BUILDROBOT] Selftest failed for i686-wrs-vxworks

[Thomas Schwinge]

Hi!

On Wed, 5 Oct 2016 16:36:01 +0200, Bernd Schmidt  wrote:
> On 10/05/2016 04:14 PM, David Malcolm wrote:
> > Thanks.  I'm not able to formally approve these changes, but FWIW these
> > patches look good to me (assuming usual testing).
> 
> LGTM too, so OK.

Without changes, committed to trunk in r241043 and r241044:

commit 441751466e69eaf8d8da7c0d388055509b35bc63
Author: tschwinge 
Date:   Wed Oct 12 13:09:06 2016 +

In gcc/Makefile.in, factor out SELFTEST_FLAGS

gcc/
* Makefile.in (SELFTEST_FLAGS): New variable.
(s-selftest, selftest-gdb, selftest-valgrind): Use it.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241043 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog   |  3 +++
 gcc/Makefile.in | 11 ---
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index e57438e..003316f 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,5 +1,8 @@
 2016-10-12  Thomas Schwinge  
 
+   * Makefile.in (SELFTEST_FLAGS): New variable.
+   (s-selftest, selftest-gdb, selftest-valgrind): Use it.
+
* vmsdbgout.c (vmsdbg_debug_hooks): Add filename parameter to
early_finish hook.
 
diff --git gcc/Makefile.in gcc/Makefile.in
index 2914605..02d0c45 100644
--- gcc/Makefile.in
+++ gcc/Makefile.in
@@ -1877,6 +1877,10 @@ endif
 # This does the things that can't be done on the host machine.
 rest.cross: specs
 
+# GCC's selftests.
+# Specify a dummy input file to placate the driver.
+SELFTEST_FLAGS = -x c /dev/null -S -fself-test
+
 # Run the selftests during the build once we have a driver and a cc1,
 # so that self-test failures are caught as early as possible.
 # Use "s-selftest" to ensure that we only run the selftests if the
@@ -1884,18 +1888,19 @@ rest.cross: specs
 .PHONY: selftest
 selftest: s-selftest
 s-selftest: $(GCC_PASSES) cc1$(exeext) stmp-int-hdrs
-   $(GCC_FOR_TARGET) -xc -S -c /dev/null -fself-test
+   $(GCC_FOR_TARGET) $(SELFTEST_FLAGS)
$(STAMP) $@
 
 # Convenience method for running selftests under gdb:
 .PHONY: selftest-gdb
 selftest-gdb: $(GCC_PASSES) cc1$(exeext) stmp-int-hdrs
-   $(GCC_FOR_TARGET) -xc -S -c /dev/null -fself-test -wrapper gdb,--args
+   $(GCC_FOR_TARGET) $(SELFTEST_FLAGS) \
+ -wrapper gdb,--args
 
 # Convenience method for running selftests under valgrind:
 .PHONY: selftest-valgrind
 selftest-valgrind: $(GCC_PASSES) cc1$(exeext) stmp-int-hdrs
-   $(GCC_FOR_TARGET) -xc -S -c /dev/null -fself-test \
+   $(GCC_FOR_TARGET) $(SELFTEST_FLAGS) \
  -wrapper valgrind,--leak-check=full
 
 # Recompile all the language-independent object files.

commit c2d86129ef8141bb214958ca90be15fbeb42f4b1
Author: tschwinge 
Date:   Wed Oct 12 13:09:17 2016 +

Make GCC selftests work for *-wrs-vxworks-* targets

gcc/
* Makefile.in (SELFTEST_FLAGS): Add -nostdinc.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241044 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog   | 2 ++
 gcc/Makefile.in | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index 003316f..d6880d9 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,5 +1,7 @@
 2016-10-12  Thomas Schwinge  
 
+   * Makefile.in (SELFTEST_FLAGS): Add -nostdinc.
+
* Makefile.in (SELFTEST_FLAGS): New variable.
(s-selftest, selftest-gdb, selftest-valgrind): Use it.
 
diff --git gcc/Makefile.in gcc/Makefile.in
index 02d0c45..f1ff782 100644
--- gcc/Makefile.in
+++ gcc/Makefile.in
@@ -1879,7 +1879,9 @@ rest.cross: specs
 
 # GCC's selftests.
 # Specify a dummy input file to placate the driver.
-SELFTEST_FLAGS = -x c /dev/null -S -fself-test
+# Specify -nostdinc to work around missing WIND_BASE environment variable
+# required for *-wrs-vxworks-* targets.
+SELFTEST_FLAGS = -nostdinc -x c /dev/null -S -fself-test
 
 # Run the selftests during the build once we have a driver and a cc1,
 # so that self-test failures are caught as early as possible.


Grüße
 Thomas

Re: [PATCH] More trivial bits from early LTO debug merge

[Thomas Schwinge]

Hi!

On Mon, 19 Sep 2016 09:53:13 +0200 (CEST), Richard Biener  
wrote:
>   * debug.h (gcc_debug_hooks): Add filename parameter to early_finish
>   hook.
>   [...]

With contrib/config-list.mk testing, I noticed another one that needed to
be updated; log/alpha-dec-vms-make.out, log/alpha64-dec-vms-make.out,
log/ia64-hp-vms-make.out:

[...]/source-gcc/gcc/vmsdbgout.c:209:1: error: invalid conversion from 
'void (*)()' to 'void (*)(const char*)' [-fpermissive]
 };
 ^
make[2]: *** [vmsdbgout.o] Error 1

As obvious, committed to trunk in r241042:

commit 706cf22169f5881765aa12affda63d80b372e47d
Author: tschwinge 
Date:   Wed Oct 12 13:08:53 2016 +

Fix gcc/vmsdbgout.c:vmsdbg_debug_hooks for "More trivial bits from early 
LTO debug merge"

gcc/
* vmsdbgout.c (vmsdbg_debug_hooks): Add filename parameter to
early_finish hook.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241042 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog   | 5 +
 gcc/vmsdbgout.c | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index 8044af0..e57438e 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,8 @@
+2016-10-12  Thomas Schwinge  
+
+   * vmsdbgout.c (vmsdbg_debug_hooks): Add filename parameter to
+   early_finish hook.
+
 2016-10-12  Georg-Johann Lay  
 
* rtl.h (struct rtx_def): Comment how RTX_FLAGS will be
diff --git gcc/vmsdbgout.c gcc/vmsdbgout.c
index 7c6d64d..23f7631 100644
--- gcc/vmsdbgout.c
+++ gcc/vmsdbgout.c
@@ -174,7 +174,7 @@ static void vmsdbgout_abstract_function (tree);
 const struct gcc_debug_hooks vmsdbg_debug_hooks
 = {vmsdbgout_init,
vmsdbgout_finish,
-   debug_nothing_void,
+   debug_nothing_charstar,
vmsdbgout_assembly_start,
vmsdbgout_define,
vmsdbgout_undef,


Grüße
 Thomas

[Ada] Spurious use visibility with limited with and child packages

[Arnaud Charlet]

This patch corrects a minor issue whereby declarations that occur
immediately within package P are erroneously treated as potentially
use-visible when a parent package has a limited with clause on P, a
child package has a with clause on P, and the child package is a
client of another unit. 


-- Source --


--  buffer.ads

package Buffer is
   Junk : Integer;
end;

--  d.ads

limited with Buffer;
package D is
   Junk : Integer;
end;

--  d-te.ads

with Buffer;
package D.Te is
   Junk : Integer;
end;

-- f.ads

with D.Te;
package F is
   use Buffer; -- This should cause an error
end;


-- Compilation and output --


$ gcc -c f.ads
f.ads:3:08: "Buffer" is not visible
f.ads:3:08: non-visible declaration at buffer.ads:1

Tested on x86_64-pc-linux-gnu, committed on trunk

2016-10-12  Justin Squirek  

* sem_ch10.adb (Remove_Limited_With_Clause): Add a check to
detect accidental visibility.

Index: sem_ch10.adb
===
--- sem_ch10.adb(revision 241024)
+++ sem_ch10.adb(working copy)
@@ -6377,6 +6377,13 @@
   --  Limited_Withed_Unit.
 
   else
+ --  If the limited_with_clause is in some other unit in the context
+ --  then it is not visible in the main unit.
+
+ if not In_Extended_Main_Source_Unit (N) then
+Set_Is_Immediately_Visible (P, False);
+ end if;
+
  --  Real entities that are type or subtype declarations were hidden
  --  from visibility at the point of installation of the limited-view.
  --  Now we recover the previous value of the hidden attribute.

Re: Questionable code in gcov-io.c

[Jakub Jelinek]

On Wed, Oct 12, 2016 at 02:23:36PM +0200, Bernd Schmidt wrote:
> >It seems that lines 198 and 200 do the same thing, at line 200 we know that
> >mode == 0, so we just assign 1.  Should we just remove the condition on line 
> >197?
> 
> The intention seems to be that a negative gcov_var.mode means we're writing,
> so for a size zero file maybe that's the expected result. But of course none
> of the existing code is going to expect that.
> 
> There are more oddities here...

Unfortunately I really don't remember, and it seems we don't have the
posting in gcc-patches archive at all.
Found it in http://marc.info/?l=gcc-patches=107747608611324 though.

Jakub

Re: [PATCH] Fix PR77826

[Marc Glisse]

On Wed, 12 Oct 2016, Richard Biener wrote:


So with doing the same on GENERIC I hit

FAIL: g++.dg/cpp1y/constexpr-array4.C  -std=c++14 (test for excess errors)

with the pattern

 /* (T)(P + A) - (T)P -> (T) A */
 (for add (plus pointer_plus)
  (simplify
   (minus (convert (add @0 @1))
(convert @0))


Ah, grep missed that one because it is on 2 lines :-(


   ...
(convert @1


no longer applying to

(long int) ((int *)  + 12) - (long int) 

because while (int *)  is equal to (long int)  (operand_equal_p
does STRIP_NOPS) they obviously do not have the same type.


I believe we are comparing (int *)  to , not to (long int)  But 
yes, indeed.


So on GENERIC we have to consider that we feed operand_equal_p with 
non-ATOMs (arbitrary expressions).  The pattern above is "safe" as it 
doesn't reference @0 in the result (not sure if we should take advantage 
of that in genmatch).


Since we are in the process of defining an 
operand_equal_for_(generic|gimple)_match_p, we could tweak it to check the 
type only for INTEGER_CST, or to still STRIP_NOPS, or similar.


Or we could remain very strict and refine the pattern, allowing a convert 
on the pointer (we might want to split the plus and pointer_plus versions 
then, for clarity). There are not many optimizations that are mandated by 
front-ends and for which this is an issue.



The other FAILs with doing the same on GENERIC are

FAIL: g++.dg/gomp/declare-simd-3.C  -std=gnu++11 (test for excess errors)
FAIL: g++.dg/torture/pr71448.C   -O0  (test for excess errors)
FAIL: g++.dg/vect/simd-clone-6.cc  -std=c++11 (test for excess errors)

the simd ones are 'warning: ignoring large linear step' and the pr71448.C
case is very similar to the above.


Yes, I expect they all come from the same 1 or 2 transformations.

If we stick to the old behavior, maybe we could have some genmatch 
magic to help with the constant capture weirdness. With matching 
captures, we could select which operand (among those supposed to be 
equivalent) is actually captured more cleverly, either with an 
explicit marker, or by giving priority to the one that is not 
immediatly below convert? in the pattern.


This route is a difficult one to take


The simplest version I was thinking about was @0 for a true capture, and @@0
for something that just has to be checked for equality with @0.


Hmm, ok.  So you'd have @@0 having to match @0 and we'd get the @0 for
the result in a reliable way?  Sounds like a reasonable idea, I'll see
how that works out (we could auto-detect '@@' if the capture is not
used in the result, see above).


It probably doesn't bring much compared to the @0@4 syntax you were 
suggesting below, so if that is easier...



-- what would be possible is to
capture a specific operand.  Like allow one to write

(op (op @0@4 @1) (op @0@3 @2))

and thus actually have three "names" for @0.  We have this internally
already when you write

(convert?@0 @1)

for the case where there is no conversion.  @0 and @1 are the same
in this case.


Looks nice and convenient (assuming lax constant matching).


Yes, w/o lax matching it has of course little value.


Not sure if this helps enough cases.


IIRC, in all cases where we had trouble with operand_equal_p, chosing which
operand to capture would have solved the issue.


Yes.  We'd still need to actually catch all those cases...


Being forced to chose which operand we capture (say with @ vs @@, making 2 
occurences of @0 a syntax error) might help, but it would also require 
updating many patterns for which this was never an issue (easy but 
boring).



I still think that having two things matched that are not really
the same is werid (and a possible source of errors as in, ICEs,
rather than missed optimizations).


Ok. Let's go with the strict matching, it is indeed less confusing.


I'll hold off with the GENERIC strict matching and will investigate
the @@ idea (plus auto-detecting it).


And if we move to stricter matching, maybe genmatch could be updated so
convert could also match integer constants in some cases.


You mean when trying to match @0 ... (convert @0) and @0 is an INTEGER_CST
allow then (convert ...) case to match an INTEGER_CST of different type?
That's an interesting idea (not sure how to implement that though).


Yes, though I am not sure of the exact semantics that would work best.

On a related note, seeing duplicated patterns for constants, I tried several
variants of

(match (mynot @0)
 (bit_not @0))
(match (mynot @0)
 INTEGER_CST@0
 (if (@0 = wide_int_to_tree (TREE_TYPE (@0), wi::bit_not (@0)

(simplify
 (minus (bit_and:cs @0 (mynot @1)) (bit_and:cs @0 @1))
  (minus (bit_xor @0 @1) @1))

This kind of hack feels wrong, but I don't see a proper way to write it.


Yes.  The above is very much a hack.  Must have been me inventing it
just to avoid duplicating the pattern.


Uh, no, don't worry, we don't have that hack in match.pd, we have 2 
patterns. The hack is just me trying to remove the duplication. 

Re: [PATCH] Implement new hook for max_align_t_align

[Bernd Schmidt]

On 10/12/2016 02:43 PM, Richard Biener wrote:

I'd say what applies to PA should apply equally well to the pdp11 and
the alpha port ...

But usually the question is just whether the port has a maintainer
and/or whether it is
a maintainance burden to keep it (say, last user of obsolete feature X).


Well, we seem to be running into a problem with PA, and pdp11 is a cc0 port.


Bernd

Re: [PATCH] Implement new hook for max_align_t_align

[Richard Biener]

On Wed, Oct 12, 2016 at 2:33 PM, Bernd Schmidt  wrote:
> On 10/12/2016 02:12 PM, John David Anglin wrote:
>>
>> On 2016-10-12, at 4:02 AM, Jakub Jelinek wrote:
>>
 Since this is PA-RISC, which is essentially dead (neither HPE nor Debian
 ship it anymore), I stand by my suggestion to bump the fundamental
 alignment
>>>
>>>
>>> Or just drop support for a dead arch?
>>
>>
>> Hardware is still available on the second hand market.
>
>
> So is the Commodore 64, but is that enough though to keep supporting PA in
> gcc? Anyone who wants to do retrocomputing can still use gcc-6 or earlier
> versions.

I'd say what applies to PA should apply equally well to the pdp11 and
the alpha port ...

But usually the question is just whether the port has a maintainer
and/or whether it is
a maintainance burden to keep it (say, last user of obsolete feature X).

Richard.

>
> Bernd

Re: [PATCH][check_GNU_style.sh] More aggressively ignore dg-xxx directives

[Kyrill Tkachov]

On 12/10/16 11:18, Kyrill Tkachov wrote:


On 12/10/16 10:57, Kyrill Tkachov wrote:


On 11/10/16 20:19, Jakub Jelinek wrote:

On Tue, Oct 11, 2016 at 01:11:04PM -0600, Martin Sebor wrote:

Also, the pattern that starts with "/\+\+\+" looks like it's missing
the ^ anchor.  Presumably it should be "/^\+\+\+ \/testsuite\//".

No, it will be almost never +++ /testsuite/
There needs to be .* in between "+++ " and "/testsuite/", and perhaps
it should also ignore "+++ testsuite/".
So /^\+\+\+ (.*\/)?testsuite\// ?
Also, normally (when matching $0) there won't be newlines in the text.

Jakub


Thanks.
Here is the updated patch with your suggestions.



Actually, I've encountered a problem:

 85 # Remove the testsuite part of the diff.  We don't care about GNU style
 86 # in testcases and the dg-* directives give too many false positives.
 87 remove_testsuite ()
 88 {
 89   awk 'BEGIN{testsuite=0} /\+\+\+ / && ! /testsuite\//{testsuite=0} \
 90{if (!testsuite) print} /^\+\+\+ (.*\/)?testsuite\//{testsuite=1}'
 91 }
 92
 93 grep $format '^+' $files \
 94 | remove_testsuite \
 95 | grep -v ':+++' \
 96 > $inp


The /^\+\+\+ (.*\/)?testsuite\// doesn't ever match when the ^ anchor is used.
The awk command matches fine by itself but not when fed from the "grep $format '^+' 
$files"
command because grep adds the line numbers and file names.
So is it okay to omit the ^ here?



Here is the patch omitting the ^.
Thanks,
Kyrill

2016-10-12  Kyrylo Tkachov  

* check_GNU_style.sh (remove_testsuite): New function.
Use it to remove testsuite from the diff.


Thanks,
Kyrill



diff --git a/contrib/check_GNU_style.sh b/contrib/check_GNU_style.sh
index 87a276c9cf47b5e07c4407f740ce05dce1928c30..92ce2eee2067b067c002f60b4a81eb3a5fb98ec5 100755
--- a/contrib/check_GNU_style.sh
+++ b/contrib/check_GNU_style.sh
@@ -81,7 +81,17 @@ if [ $nfiles -eq 1 ]; then
 else
 format="-nH"
 fi
+
+# Remove the testsuite part of the diff.  We don't care about GNU style
+# in testcases and the dg-* directives give too many false positives.
+remove_testsuite ()
+{
+  awk 'BEGIN{testsuite=0} /\+\+\+ / && ! /testsuite\//{testsuite=0} \
+   {if (!testsuite) print} /\+\+\+ (.*\/)?testsuite\//{testsuite=1}'
+}
+
 grep $format '^+' $files \
+| remove_testsuite \
 | grep -v ':+++' \
 > $inp
 
@@ -160,8 +170,9 @@ col (){
 	fi
 
 	# Don't reuse $inp, which may be generated using -H and thus contain a
-	# file prefix.
-	grep -n '^+' $f \
+	# file prefix.  Re-remove the testsuite since we're not using $inp.
+	remove_testsuite $f \
+	| grep -n '^+' \
 	| grep -v ':+++' \
 	> $tmp
 
@@ -174,11 +185,10 @@ col (){
 	# Expand tabs to spaces according to tab positions.
 	# Keep long lines, make short lines empty.  Print the part past 80 chars
 	# in red.
-# Don't complain about dg-xxx directives in tests.
 	cat "$tmp" \
 	| sed 's/^[0-9]*:+//' \
 	| expand \
-	| awk '$0 !~ /{[[:space:]]*dg-(error|warning|message)[[:space:]]/ { \
+	| awk '{ \
 		 if (length($0) > 80) \
 		   printf "%s\033[1;31m%s\033[0m\n", \
 			  substr($0,1,80), \