[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
It still happens, but on another unit this time:

markus@x4 ffmpeg % cat h264dsp.i
extern int fn2(int);
extern int fn3(int);
int a, b, c;
void fn1(long p1) {
  char *d;
  for (;; d += p1) {
d[0] = fn2(1 >> a);
fn3(0);
fn3(c >> a);
d[1] = fn3(d[1] * b + c >> a);
d[4] = fn3(d[4] * b + c >> a);
d[5] = fn3(d[5] * b + c >> a);
  }
}

markus@x4 ffmpeg % gcc -march=amdfam10 -O3 -c -S h264dsp.i
h264dsp.i: In function ‘fn1’:
h264dsp.i:4:6: internal compiler error: in replace_one_candidate, at
gimple-ssa-strength-reduction.c:3369
 void fn1(long p1) {
  ^~~

Simply building ffmpeg with -march=amdfam10 finds these bugs.

Please consider reverting your original patch until you come up with solution.

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

[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
Keeping this open until the fix has some burn-in time, planning to backport to
GCC 6 and 5.

[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

[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Uroš Bizjak from comment #4)
> Looks like middle-end problem to me:

Maybe turning on RTL checking will find the problem is located.

[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Oct 13 01:08:20 2016
New Revision: 241082

URL: https://gcc.gnu.org/viewcvs?rev=241082=gcc=rev
Log:
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.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c

[Bug c++/77731] Parameter pack expansion doesn't work when used to define argument list

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 CC||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1

--- Comment #1 from Ville Voutilainen  ---
Clang accepts the code.

[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 

[Bug c++/77945] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding.

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||jason at redhat dot com,
   ||ville.voutilainen at gmail dot 
com

--- Comment #4 from Ville Voutilainen  ---
Another test:

struct T 
{ 
int x = 0; 
bool y = 0; 
constexpr T() {}
};

int main()
{
constexpr T t = (T{} = T{});
}

prog.cc: In function 'int main()':
prog.cc:10:31: error: accessing value of '' through a 'char [5]'
glvalue in a constant expression
 constexpr T t = (T{} = T{});
   ^

That looks rather bad.

[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

[Bug c++/77927] unary right fold fails to compile

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 CC||jason at redhat dot com,
   ||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1

--- Comment #4 from Ville Voutilainen  ---
Clang accepts the code.

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
>>
>

[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to Marc Mutz from comment #12)
> Is replacing a matching comment with __attribute__(fallthrough)) so
> complicated as to make this a wontfix?

It is not really possible.
__attribute__((fallthrough)) has precise rules on where it can appear, while /*
FALLTHRU */ comments, being comments, can appear anywhere.  Especially with
-Wimplicit-fallthrough=1 when all comments are considered fallthru comments...

[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective

[marc.mutz at kdab dot com]

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

--- Comment #12 from Marc Mutz  ---
Is replacing a matching comment with __attribute__(fallthrough)) so complicated
as to make this a wontfix?

[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.

[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target|x86_64-*-*  |x86_64-*-*, alphaev68-*-*

--- Comment #5 from Uroš Bizjak  ---
Also fails for alphaev68-linux-gnu:

internal compiler error: Segmentation fault
0x120948993 crash_signal
/space/homedirs/uros/gcc-svn/trunk/gcc/toplev.c:337
0x120d359b0 alpha_legitimate_address_p
/space/homedirs/uros/gcc-svn/trunk/gcc/config/alpha/alpha.c:857
0x1209439eb default_addr_space_legitimate_address_p(machine_mode, rtx_def*,
bool, unsigned char)
/space/homedirs/uros/gcc-svn/trunk/gcc/targhooks.c:1344
0x12087f613 memory_address_addr_space_p(machine_mode, rtx_def*, unsigned char)
/space/homedirs/uros/gcc-svn/trunk/gcc/recog.c:1336
0x120500963 adjust_address_1(rtx_def*, machine_mode, long, int, int, int, long)
/space/homedirs/uros/gcc-svn/trunk/gcc/emit-rtl.c:2221
0x120552b07 store_field
/space/homedirs/uros/gcc-svn/trunk/gcc/expr.c:6938
0x12054de3b expand_assignment(tree_node*, tree_node*, bool)
/space/homedirs/uros/gcc-svn/trunk/gcc/expr.c:5167
0x1203f251b expand_gimple_stmt_1
/space/homedirs/uros/gcc-svn/trunk/gcc/cfgexpand.c:3649
0x1203f251b expand_gimple_stmt
/space/homedirs/uros/gcc-svn/trunk/gcc/cfgexpand.c:3745
0x1203f908b expand_gimple_basic_block
/space/homedirs/uros/gcc-svn/trunk/gcc/cfgexpand.c:5752
0x1203fc2db execute
/space/homedirs/uros/gcc-svn/trunk/gcc/cfgexpand.c:6363

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

[Bug c++/55004] [meta-bug] constexpr issues

[myriachan at gmail dot com]

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

Bug 67333 Summary: [C++11][constexpr] constexpr functions incorrectly prohibit 
taking references to volatile types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67333

   What|Removed |Added

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

[Bug c++/67333] [C++11][constexpr] constexpr functions incorrectly prohibit taking references to volatile types

[myriachan at gmail dot com]

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

Melissa  changed:

   What|Removed |Added

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

--- Comment #3 from Melissa  ---
Seems to have been fixed sometime between 6.0 and 6.1.

[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.

[Bug middle-end/77959] ICE in ix86_decompose_address, at i386/i386.c:14954

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Component|target  |middle-end

--- Comment #4 from Uroš Bizjak  ---
Looks like middle-end problem to me:

Program received signal SIGSEGV, Segmentation fault.
0x00ef2ddb in ix86_decompose_address (addr=0x41,
out=out@entry=0x7fffd490) at
/home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:14954
14954 if (TARGET_64BIT && GET_MODE (addr) == DImode)
(gdb) p addr
$10 = (rtx) 0x41

(gdb) bt
#0  0x00ef2ddb in ix86_decompose_address (addr=0x41,
out=out@entry=0x7fffd490) at
/home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:14954
#1  0x00ef4ddc in ix86_legitimate_address_p (addr=,
strict=) at
/home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:15668
#2  0x00b1f4af in memory_address_addr_space_p (mode=mode@entry=SFmode,
addr=addr@entry=0x41, as=)
at /home/uros/gcc-svn/trunk/gcc/recog.c:1336
#3  0x00874930 in adjust_address_1 (memref=memref@entry=0x7fffefdec168,
mode=mode@entry=SFmode, offset=offset@entry=0, validate=validate@entry=1, 
adjust_address=adjust_address@entry=1, adjust_object=adjust_object@entry=0,
size=4) at /home/uros/gcc-svn/trunk/gcc/emit-rtl.c:2221
#4  0x008b3d1c in store_field (target=0x7fffefdec168, bitsize=32,
bitpos=0, bitregion_start=, bitregion_end=,
mode=SFmode, 
exp=0x7fffeffd8c48, alias_set=2, nontemporal=false, reverse=false) at
/home/uros/gcc-svn/trunk/gcc/expr.c:6938
#5  0x008afd2f in expand_assignment (to=to@entry=0x7fffeffc4a60,
from=from@entry=0x7fffeffd8c48, nontemporal=)
at /home/uros/gcc-svn/trunk/gcc/expr.c:5167
#6  0x0079c6ee in expand_gimple_stmt_1 (stmt=0x7fffeffc88c0) at
/home/uros/gcc-svn/trunk/gcc/cfgexpand.c:3649

(gdb) f 3
#3  0x00874930 in adjust_address_1 (memref=memref@entry=0x7fffefdec168,
mode=mode@entry=SFmode, offset=offset@entry=0, validate=validate@entry=1, 
adjust_address=adjust_address@entry=1, adjust_object=adjust_object@entry=0,
size=4) at /home/uros/gcc-svn/trunk/gcc/emit-rtl.c:2221
2221  && (!validate || memory_address_addr_space_p (mode, addr,
(gdb) list
2216size = defattrs->size;
2217
2218  /* If there are no changes, just return the original memory
reference.  */
2219  if (mode == GET_MODE (memref) && !offset
2220  && (size == 0 || (attrs.size_known_p && attrs.size == size))
2221  && (!validate || memory_address_addr_space_p (mode, addr,
attrs.addrspace)))
2223return memref;
2224
2225  /* ??? Prefer to create garbage instead of creating shared rtl.
(gdb) p addr
$8 = (rtx) 0x41

Corrupted RTX is passed from adjust_address_1.

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

[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from Bill Schmidt  ---
OK, I can reproduce now, and understand the problem better.  This patch fixes
the problem.  I'll regstrap it and get it committed shortly.

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

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.

[Bug target/77959] ICE in ix86_decompose_address, at i386/i386.c:14954

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
The ICE has been fixed between revisions r213007 (2014-07-24, ICE) and r213805
(2014-08-11, compiles).

[Bug c/38295] Support pointer difference as constant in static initializer

[fw at gcc dot gnu.org]

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

--- Comment #11 from Florian Weimer  ---
Created attachment 39799
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39799=edit
label.c

(In reply to Andrew Pinski from comment #6)
> Not always since they could be in different sections via -ffunction-sections
> or the user put them into different sections.  The layout of the sections is
> not known until link time.

For label differences, the difference is only known at assembly time, not
compile time.  So you can really evaluate the constant in GCC, either.  You can
even get assembler warnings and incorrect data, as the attached code shows.  It
produces an assembler warning for me:

/tmp/ccAMdJhn.s: Assembler messages:
/tmp/ccAMdJhn.s:1237: Warning: value 0x1680 truncated to 0x80

(The reproducer is slightly convoluted to work around bug 77951.)

There might also be targets where label differences are only known at link
time, too.

[Bug target/77959] ICE in ix86_decompose_address, at i386/i386.c:14954

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
No ICE with version 5.4.0 too.

[Bug libstdc++/65122] std::vector doesn't honor element alignment

[jason at gcc dot gnu.org]

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

Bug 77742 Summary: Warning about placement new for over-aligned type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77742

   What|Removed |Added

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

[Bug c++/77742] Warning about placement new for over-aligned type

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug fortran/77961] [7 Regression] ICE: verify_type failed, at tree.c:14085 ; gen_type_die_with_usage, at dwarf2out.c:22942

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4

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.

[Bug c++/77958] printf format checking -vs- variadic template functions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 Ever confirmed|0   |1

[Bug target/77959] ICE in ix86_decompose_address, at i386/i386.c:14954

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 CC||jakub at redhat dot com,
   ||marxin at gcc dot gnu.org
  Known to work||4.5.4, 4.6.4, 4.7.4, 5.4.0
   Target Milestone|--- |6.3
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.4, 6.2.0, 7.0

--- Comment #1 from Martin Liška  ---
Confirmed, on trunk started to appear again with r231499.
Current back-trace is the same as the one in 4.9.x.

[Bug fortran/77960] ICE in gfc_conv_ss_startstride, at fortran/trans-array.c:3966

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with 4.8.0.

[Bug fortran/77961] [7 Regression] ICE: verify_type failed, at tree.c:14085 ; gen_type_die_with_usage, at dwarf2out.c:22942

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 CC||marxin at gcc dot gnu.org,
   ||vehre at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ICE: verify_type failed, at |[7 Regression] ICE:
   |tree.c:14085 ;  |verify_type failed, at
   |gen_type_die_with_usage, at |tree.c:14085 ;
   |dwarf2out.c:22942   |gen_type_die_with_usage, at
   ||dwarf2out.c:22942
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r240231.

[Bug c++/77958] printf format checking -vs- variadic template functions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
It would certainly be nice if it did work, though I think it doesn't simply
because attribute format isn't designed to be used with variadic funtion
templates.  I don't have a sense how involved extending it to those would be
but let me confirm this as an enhancement request.

Btw., it's nice to see that because the -Wfornat-length warning runs later than
-Wformat it handles this case even without the attribute.  Moving -Wformat to a
later stage would have the same effect, in addition to letting it detect more
problems (e.g., when the format string isn't a literal).

$ cat z.C && gcc -S -O2  -Wall -Wextra -Wpedantic z.C
char d [4];

template
static inline void
whatever (char *d, const char *fmt, Args&&... args)
{
  __builtin_sprintf(d, fmt, args...);
}

void qq()
{
  whatever(d, "hi %s", "bob");
}

z.C: In function ‘void qq()’:
z.C:10:6: warning: ‘%s’ directive writing 3 bytes into a region of size 1
[-Wformat-length=]
 void qq()
  ^~
z.C:7:3: note: format output 7 bytes into a destination of size 4
   __builtin_sprintf(d, fmt, args...);
   ^

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

[Bug c++/77742] Warning about placement new for over-aligned type

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Oct 12 18:04:51 2016
New Revision: 241073

URL: https://gcc.gnu.org/viewcvs?rev=241073=gcc=rev
Log:
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.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/aligned-new7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/init.c

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: Potential bug with wide_int_storage::set_len

[Eric Botcazou]

> During the development of a patch I encountered some strange behavior
> and decided to investigate. The result of which is I think I found a bug
> with 'wide_int_storage::set_len' in gcc/wide-int.h.
> 
> The function reads:
> inline void
> wide_int_storage::set_len (unsigned int l, bool is_sign_extended)
> {
>   len = l;
>   if (!is_sign_extended && len * HOST_BITS_PER_WIDE_INT > precision)
> val[len - 1] = sext_hwi (val[len - 1],
>  precision % HOST_BITS_PER_WIDE_INT);
> }

The code certainly lacks a comment explaining the apparent discrepancy.

> Due to this, 'expand_expr' will expand a constant tree with unsigned
> integer type and value MAX_UINT to a rtx node (const_int -1).

As Jakub explained, that is as expected, even if a little surprising.

-- 
Eric Botcazou

[Bug fortran/77961] New: ICE: verify_type failed, at tree.c:14085 ; gen_type_die_with_usage, at dwarf2out.c:22942

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77961
   Summary: ICE: verify_type failed, at tree.c:14085 ;
gen_type_die_with_usage, at dwarf2out.c:22942
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

ICE observed with test version gfortran-7-20160925 and newer.
No ICE with gfortran-7-20160918 and older.
Needs option -g :


$ cat z1.f90
program p
   type t
   end type
   type t2
  type(t), allocatable :: c(:)
   end type
   type(t2) :: x[*]
   allocate (x%c(2), source=t())
contains
   subroutine s(x)
  class(*) :: x[*]
   end
end


$ gfortran-7-20161009 -g -fcoarray=single -c z1.f90
$ gfortran-7-20161009 -g -fcoarray=lib -c z1.f90
z1.f90:12:0:

end

Error: TYPE_CANONICAL is not compatible
  constant 384>
unit size  constant 48>
align 64 symtab 1200810336 alias set -1 canonical type 0x2b1647957540
fields 
asm_written public unsigned DI
size 
unit size 
align 64 symtab 1200808976 alias set -1 canonical type
0x2b16477852a0
pointer_to_this >
unsigned DI file z1.f90 line 10 col 0 size  unit size 
align 64 offset_align 128
offset 
bit offset  context 
chain 
DI file z1.f90 line 10 col 0 size 
unit size 
align 64 offset_align 128 offset  bit
offset  context  chain >>
pointer_to_this  chain >
  constant 448>
unit size  constant 56>
align 64 symtab 0 alias set -1 canonical type 0x2b1647957540
fields 
unsigned restrict DI
size 
unit size 
align 64 symtab 1200988480 alias set -1 canonical type
0x2b164778b930>
unsigned DI file z1.f90 line 12 col 0 size  unit size 
align 64 offset_align 128
offset 
bit offset  context 
chain 
DI file z1.f90 line 12 col 0 size 
unit size 
align 64 offset_align 128 offset  bit
offset  context  chain >>
pointer_to_this  chain >
z1.f90:12:0: internal compiler error: verify_type failed
0xee98e2 verify_type(tree_node const*)
../../gcc/tree.c:14085
0x8c25ec gen_type_die_with_usage
../../gcc/dwarf2out.c:22942
0x8c3c36 gen_type_die
../../gcc/dwarf2out.c:23140
0x8b7ed0 gen_decl_die
../../gcc/dwarf2out.c:23794
0x8cb015 gen_member_die
../../gcc/dwarf2out.c:22611
0x8cb015 gen_struct_or_union_type_die
../../gcc/dwarf2out.c:22717
0x8cb015 gen_tagged_type_die
../../gcc/dwarf2out.c:22920
0x8c2c5c gen_type_die_with_usage
../../gcc/dwarf2out.c:23085
0x8c3c36 gen_type_die
../../gcc/dwarf2out.c:23140
0x8b83a9 gen_decl_die
../../gcc/dwarf2out.c:23739
0x8b8d86 dwarf2out_decl
../../gcc/dwarf2out.c:24213
0x8d3b84 dwarf2out_type_decl
../../gcc/dwarf2out.c:23921
0xb5a0bf rest_of_type_compilation(tree_node*, int)
../../gcc/passes.c:333
0x7b3b03 gfc_finish_type(tree_node*)
../../gcc/fortran/trans-types.c:2247
0x7b74d4 gfc_get_derived_type(gfc_symbol*, bool)
../../gcc/fortran/trans-types.c:2711
0x7b7c9c gfc_typenode_for_spec(gfc_typespec*, bool)
../../gcc/fortran/trans-types.c:1110
0x7b5cc3 gfc_sym_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2167
0x74eb24 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1640
0x752767 generate_local_decl
../../gcc/fortran/trans-decl.c:5313
0x70dfcb do_traverse_symtree
../../gcc/fortran/symbol.c:3962

[Bug fortran/77960] New: ICE in gfc_conv_ss_startstride, at fortran/trans-array.c:3966

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77960
   Summary: ICE in gfc_conv_ss_startstride, at
fortran/trans-array.c:3966
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With invalid code, down to at least 4.8 :


$ cat z1.f90
program p
   procedure(g), pointer :: f
   f => g
   read(99) f
contains
   function g() result(z)
  integer :: z(2)
  z = 1
   end
end


$ gfortran-7-20161009 z1.f90
z1.f90:4:0:

read(99) f

internal compiler error: in gfc_conv_ss_startstride, at
fortran/trans-array.c:3966
0x730c76 gfc_conv_ss_startstride(gfc_loopinfo*)
../../gcc/fortran/trans-array.c:3966
0x790184 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2520
0x723ff7 trans_code
../../gcc/fortran/trans.c:1918
0x78ce50 build_dt
../../gcc/fortran/trans-io.c:1962
0x724027 trans_code
../../gcc/fortran/trans.c:1886
0x7538b8 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6257
0x6de1a0 translate_all_program_units
../../gcc/fortran/parse.c:5940
0x6de1a0 gfc_parse_file()
../../gcc/fortran/parse.c:6146
0x720e22 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/77959] New: ICE in ix86_decompose_address, at i386/i386.c:14954

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77959
   Summary: ICE in ix86_decompose_address, at i386/i386.c:14954
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Invalid code with ICE down to at least 4.8, at -Os, -O1 or higher.
No ICE with version 5.4.1.


$ cat z1.f90
program p
   interface
  subroutine s(x)
 real :: x
  end
   end interface
   call s(1.0)
end
subroutine s(x)
   complex :: x
   x = x + 1
end


$ gfortran-7-20161009 -O2 z1.f90
z1.f90:3:18:

   subroutine s(x)
  1
Warning: Interface mismatch in global procedure 's' at (1): Type mismatch in
argument 'x' (REAL(4)/COMPLEX(4))
z1.f90:11:0:

x = x + 1

internal compiler error: Segmentation fault
0xc2a7cf crash_signal
../../gcc/toplev.c:337
0xf69ea4 ix86_decompose_address(rtx_def*, ix86_address*)
../../gcc/config/i386/i386.c:14954
0xf6bd9b ix86_legitimate_address_p
../../gcc/config/i386/i386.c:15668
0xb8b07e memory_address_addr_space_p(machine_mode, rtx_def*, unsigned char)
../../gcc/recog.c:1336
0x8df897 adjust_address_1(rtx_def*, machine_mode, long, int, int, int, long)
../../gcc/emit-rtl.c:2221
0x91e9b1 store_field
../../gcc/expr.c:6938
0x91a7b7 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5167
0x8083e6 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3649
0x8083e6 expand_gimple_stmt
../../gcc/cfgexpand.c:3745
0x80a80e expand_gimple_basic_block
../../gcc/cfgexpand.c:5752
0x810996 execute
../../gcc/cfgexpand.c:6363

[Bug c++/77958] New: printf format checking -vs- variadic template functions

[tromey at gcc dot gnu.org]

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

Bug ID: 77958
   Summary: printf format checking -vs- variadic template
functions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

Consider this test case, derived from code I found in firefox:

#include 
#include 

template
static void
// __attribute__ ((format (printf, 1, 2)))
whatever(const char *fmt, Args&&... args)
{
  printf(fmt, args...);
}

void qq()
{
  whatever("hi %d", "bob");
}


If I compile this with -Wformat, I don't get any warnings.

However, if I uncomment the __attribute__, I get:

pokyo. g++ -Wall -c -Wformat q.cc
q.cc: In substitution of ‘template void whatever(const char*,
Args&& ...) [with Args = {const char (&)[4]}]’:
q.cc:14:26:   required from here
q.cc:7:1: error: args to be formatted is not ‘...’
 whatever(const char *fmt, Args&&... args)
 ^~~~


I think the attribute approach ought to work.

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)

[Bug c++/77911] Comparing function pointers in a constexpr function can produce an error.

[yhueotnk at pokemail dot net]

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

--- Comment #3 from Dr Hilbert Swan  ---
A generous fellow offered me this workaround for the time being:

   void test1(){}
   void test2(){}
   void test3(){}
   void test4(){}
   #define FUNCTION_LIST test1, test2, test3, test4

   template 
   struct SearchFun
   {
   static constexpr int Idx = SearchFun::Idx;
   };

   template 
   struct SearchFun
   {
   static constexpr int Idx = N;
   };

   template 
   using FindMatchingIdx = SearchFun<0, Fun, FUNCTION_LIST>;

   // Tests
   constexpr unsigned int loc1 = FindMatchingIdx::Idx;
   static_assert(loc1 == 0, "");
   constexpr unsigned int loc2 = FindMatchingIdx::Idx;
   static_assert(loc2 == 1, "");
   constexpr unsigned int loc3 = FindMatchingIdx::Idx;
   static_assert(loc3 == 2, "");

   // If the array is needed
   typedef void (*func)();
   func funcs[] = { FUNCTION_LIST };

   // If desired the template alias can be wrapped in a macro

   #define FindMatching(Fun) FindMatchingIdx::Idx
   constexpr unsigned int loc4 = FindMatching(test2);
   static_assert(loc4 == 1, "");

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

[Bug c/77909] -Wimplicit-fallthrough: accept more comment variants

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Markus Trippelsdorf  ---
This was fixed by Jakub's patch:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=126636026724ab5faecb017cfaf9dabbd3754ef3

-Wimplicit-fallthrough=1 should fix all of your issues.

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

[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Version|4.6.1   |6.0
 Resolution|--- |FIXED

--- Comment #20 from Jason Merrill  ---
Fixed in GCC 6.

[Bug bootstrap/77917] ARM/AARCH64 bootstrap-lto fails

[tulipawn at gmail dot com]

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

--- Comment #6 from PeteVine  ---
Indeed, gold is definitely a factor, but look what happens after switching back
to ld.bfd on ARM:

make[6]: Entering directory
`/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/src'
/bin/bash ../libtool --tag CXX   --mode=link
/home/guest/gcc-svn-master/build/./gcc/xgcc -shared-libgcc
-B/home/guest/gcc-svn-master/build/./gcc -nostdinc++
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/src
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/src/.libs
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/libsupc++/.libs
-B/usr/gcc7/arm-linux-gnueabihf/bin/ -B/usr/gcc7/arm-linux-gnueabihf/lib/
-isystem /usr/gcc7/arm-linux-gnueabihf/include -isystem
/usr/gcc7/arm-linux-gnueabihf/sys-include -Wl,-O1 -Wl,-z,relro
-Wl,--gc-sections  -std=gnu++98 -fPIC -DPIC -fno-implicit-templates  -Wall
-Wextra -Wwrite-strings -Wcast-qual -Wabi  -fdiagnostics-show-location=once  
-ffunction-sections -fdata-sections  -frandom-seed=libstdc++.la  -o
libstdc++.la -version-info 6:23:0 -Wl,--version-script=libstdc++-symbols.ver
-lm -rpath /usr/gcc7/lib compatibility.lo compatibility-debug_list.lo
compatibility-debug_list-2.lo  compatibility-c++0x.lo
compatibility-atomic-c++0x.lo compatibility-thread-c++0x.lo
compatibility-chrono.lo compatibility-condvar.lo 
../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la
../src/c++11/libc++11convenience.la 
libtool: link:  /home/guest/gcc-svn-master/build/./gcc/xgcc -shared-libgcc
-B/home/guest/gcc-svn-master/build/./gcc -nostdinc++
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/src
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/src/.libs
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/libsupc++/.libs
-B/usr/gcc7/arm-linux-gnueabihf/bin/ -B/usr/gcc7/arm-linux-gnueabihf/lib/
-isystem /usr/gcc7/arm-linux-gnueabihf/include -isystem
/usr/gcc7/arm-linux-gnueabihf/sys-include -fPIC -DPIC -D_GLIBCXX_SHARED
-shared -nostdlib /usr/lib/arm-linux-gnueabihf/crti.o
/home/guest/gcc-svn-master/build/./gcc/crtbeginS.o  .libs/compatibility.o
.libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o
.libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o
.libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o
.libs/compatibility-condvar.o  -Wl,--whole-archive
../libsupc++/.libs/libsupc++convenience.a
../src/c++98/.libs/libc++98convenience.a
../src/c++11/.libs/libc++11convenience.a -Wl,--no-whole-archive 
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/libsupc++/.libs
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/src
-L/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/src/.libs
-lm -L/home/guest/gcc-svn-master/build/./gcc -L/lib/arm-linux-gnueabihf
-L/usr/lib/arm-linux-gnueabihf -lc -lgcc_s
/home/guest/gcc-svn-master/build/./gcc/crtendS.o
/usr/lib/arm-linux-gnueabihf/crtn.o  -Wl,-O1 -Wl,-z -Wl,relro -Wl,--gc-sections
-Wl,--version-script=libstdc++-symbols.ver   -Wl,-soname -Wl,libstdc++.so.6 -o
.libs/libstdc++.so.6.0.23
/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/include/stdexcept:69:30:
note: type 'struct __cow_string' should match type 'struct __cow_string'
   typedef basic_string __cow_string;
  ^
/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/include/stdexcept:48:10:
note: the incompatible type is defined here
   struct __cow_string
  ^
/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/include/stdexcept:69:30:
note: type 'struct __cow_string' should match type 'struct __cow_string'
   typedef basic_string __cow_string;
  ^
/home/guest/gcc-svn-master/build/arm-linux-gnueabihf/libstdc++-v3/include/stdexcept:48:10:
note: the incompatible type is defined here
   struct __cow_string
  ^
`__gnu_end_cleanup' referenced in section `.text.__cxa_end_cleanup' of
/tmp/ccKTGZUi.ltrans0.ltrans.o: defined in discarded section `.text' of
eh_arm.o (symbol from plugin)
collect2: error: ld returned 1 exit status

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

Re: Potential bug with wide_int_storage::set_len

[Jakub Jelinek]

On Wed, Oct 12, 2016 at 06:45:39PM +0200, Jakub Jelinek wrote:
> On Wed, Oct 12, 2016 at 05:02:46PM +0100, Andre Vieira (lists) wrote:
> > Say you are running it on a 64-bit host:
> > #define HOST_BITS_PER_WIDE_INT 64
> > 
> > and you call 'result.set_len (1, false);'
> > 
> > Then this will sign extend the first element of val, to
> > 0x, and I don't think this is what you want.
> > 
> > Due to this, 'expand_expr' will expand a constant tree with unsigned
> > integer type and value MAX_UINT to a rtx node (const_int -1).
> 
> That is correct.  In RTL constants are always sign-extended from their
> precision to HOST_BITS_PER_WIDE_INT, regardless if it is "signed" or
> "unsigned" constant.  Whether you treat the low precision bits of the
> constant as signed or unsigned is something encoded in the operation on it.

Here is what rtl.texi says on it:
@item (const_int @var{i})
This type of expression represents the integer value @var{i}.  @var{i}
is customarily accessed with the macro @code{INTVAL} as in
@code{INTVAL (@var{exp})}, which is equivalent to @code{XWINT (@var{exp}, 0)}.

Constants generated for modes with fewer bits than in
@code{HOST_WIDE_INT} must be sign extended to full width (e.g., with
@code{gen_int_mode}).  For constants for modes with more bits than in
@code{HOST_WIDE_INT} the implied high order bits of that constant are
copies of the top bit.  Note however that values are neither
inherently signed nor inherently unsigned; where necessary, signedness
is determined by the rtl operation instead.

Jakub

Re: Potential bug with wide_int_storage::set_len

[Jakub Jelinek]

On Wed, Oct 12, 2016 at 05:02:46PM +0100, Andre Vieira (lists) wrote:
> Say you are running it on a 64-bit host:
> #define HOST_BITS_PER_WIDE_INT 64
> 
> and you call 'result.set_len (1, false);'
> 
> Then this will sign extend the first element of val, to
> 0x, and I don't think this is what you want.
> 
> Due to this, 'expand_expr' will expand a constant tree with unsigned
> integer type and value MAX_UINT to a rtx node (const_int -1).

That is correct.  In RTL constants are always sign-extended from their
precision to HOST_BITS_PER_WIDE_INT, regardless if it is "signed" or
"unsigned" constant.  Whether you treat the low precision bits of the
constant as signed or unsigned is something encoded in the operation on it.

Jakub

[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

[Bug target/77957] [6/7 Regression] Undefined .LCTOC0 with -fstack-protector-strong -mminimal-toc -O0 on ppc64le

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 39798
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39798=edit
gcc7-pr77957.patch

One of the problems is that for TARGET_THREAD_SSP_OFFSET targets we completely
wastefully create a MEM we don't really need and then ignore it.  This untested
patch attempts to avoid that.

The more important bug is somewhere in the rs6000 backend, that the useless
MEMs at -O0 confuse the backend enough that it contains (useless) .LCTOC0
reference/load without corresponding definition of .LCTOC0.  I'll leave this
part to the rs6000 maintainers.

[Bug libgomp/66553] openmp tasks produce libgomp warnings with fsanitize=thread

[jtaylor.debian at googlemail dot com]

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

--- Comment #3 from Julian Taylor  ---
Would adding a libgomp threadsanitizer configure switch be an option?
It could enable --disable-linux-futex which you need for omp critical sections,
set the right compile and link flags and add some extra locks in the task
structure to remove the false positives.


note gcc 6.2 still produces thread sanitizer errors with the above example when
using tasks:

==
WARNING: ThreadSanitizer: data race (pid=12405)
  Write of size 4 at 0x7d880001c900 by thread T1 (mutexes: write M12):
#0 gomp_team_barrier_set_task_pending ../libgomp/config/posix/bar.h:125
(libgomp.so.1+0x0001bd5b)
#1 GOMP_task ../libgomp/task.c:455 (libgomp.so.1+0x0001bd5b)
#2 main._omp_fn.0 /tmp/jtaylor/test2.c:17 (a.out+0x00400aff)
#3 gomp_thread_start ../libgomp/team.c:119 (libgomp.so.1+0x00022860)

  Previous read of size 4 at 0x7d880001c900 by thread T4 (mutexes: write M11):
#0 gomp_barrier_wait_start ../libgomp/config/posix/bar.h:82
(libgomp.so.1+0x0002619b)
#1 gomp_team_barrier_wait ../libgomp/config/posix/bar.c:252
(libgomp.so.1+0x0002619b)
#2 gomp_team_barrier_wait_final ../libgomp/config/posix/bar.h:104
(libgomp.so.1+0x0002286c)
#3 gomp_thread_start ../libgomp/team.c:120 (libgomp.so.1+0x0002286c)

  Location is heap block of size 5440 at 0x7d880001c800 allocated by main
thread:
#0 malloc ../../../../libsanitizer/tsan/tsan_interceptors.cc:538
(libtsan.so.0+0x000298bc)
#1 gomp_malloc ../libgomp/alloc.c:37 (libgomp.so.1+0xb06a)
#2 gomp_new_team ../libgomp/team.c:168 (libgomp.so.1+0x000228fa)
#3 GOMP_parallel ../libgomp/parallel.c:167 (libgomp.so.1+0x000129e3)
#4 main /tmp/jtaylor/test2.c:11 (a.out+0x00400a70)

  Mutex M12 (0x7d880001cf40) created at:
#0 pthread_mutex_init
../../../../libsanitizer/tsan/tsan_interceptors.cc:1091
(libtsan.so.0+0x0002b4be)
#1 gomp_mutex_init ../libgomp/config/posix/mutex.h:40
(libgomp.so.1+0x0002291a)
#2 gomp_new_team ../libgomp/team.c:174 (libgomp.so.1+0x0002291a)
#3 GOMP_parallel ../libgomp/parallel.c:167 (libgomp.so.1+0x000129e3)
#4 main /tmp/jtaylor/test2.c:11 (a.out+0x00400a70)

  Mutex M11 (0x7d880001c890) created at:
#0 pthread_mutex_init
../../../../libsanitizer/tsan/tsan_interceptors.cc:1091
(libtsan.so.0+0x0002b4be)
#1 gomp_mutex_init ../libgomp/config/posix/mutex.h:40
(libgomp.so.1+0x00025bde)
#2 gomp_barrier_init ../libgomp/config/posix/bar.c:37
(libgomp.so.1+0x00025bde)
#3 gomp_new_team ../libgomp/team.c:173 (libgomp.so.1+0x0002290b)
#4 GOMP_parallel ../libgomp/parallel.c:167 (libgomp.so.1+0x000129e3)
#5 main /tmp/jtaylor/test2.c:11 (a.out+0x00400a70)

  Thread T1 (tid=12407, running) created by main thread at:
#0 pthread_create ../../../../libsanitizer/tsan/tsan_interceptors.cc:876
(libtsan.so.0+0x0002ad6d)
#1 gomp_team_start ../libgomp/team.c:806 (libgomp.so.1+0x000231cd)
#2 GOMP_parallel ../libgomp/parallel.c:167 (libgomp.so.1+0x000129f7)
#3 main /tmp/jtaylor/test2.c:11 (a.out+0x00400a70)

  Thread T4 (tid=12410, running) created by main thread at:
#0 pthread_create ../../../../libsanitizer/tsan/tsan_interceptors.cc:876
(libtsan.so.0+0x0002ad6d)
#1 gomp_team_start ../libgomp/team.c:806 (libgomp.so.1+0x000231cd)
#2 GOMP_parallel ../libgomp/parallel.c:167 (libgomp.so.1+0x000129f7)
#3 main /tmp/jtaylor/test2.c:11 (a.out+0x00400a70)

SUMMARY: ThreadSanitizer: data race ../libgomp/config/posix/bar.h:125 in
gomp_team_barrier_set_task_pending
==
2 0
==
WARNING: ThreadSanitizer: data race (pid=12405)
  Read of size 4 at 0x7d880001cf88 by thread T1:
#0 GOMP_task ../libgomp/task.c:318 (libgomp.so.1+0x0001b69a)
#1 main._omp_fn.0 /tmp/jtaylor/test2.c:17 (a.out+0x00400aff)
#2 gomp_thread_start ../libgomp/team.c:119 (libgomp.so.1+0x00022860)

  Previous write of size 4 at 0x7d880001cf88 by thread T2 (mutexes: write M12):
#0 gomp_barrier_handle_tasks ../libgomp/task.c:1295
(libgomp.so.1+0x000178be)
#1 gomp_team_barrier_wait_end ../libgomp/config/posix/bar.c:155
(libgomp.so.1+0x00025f15)
#2 gomp_team_barrier_wait ../libgomp/config/posix/bar.c:252
(libgomp.so.1+0x000261db)
#3 gomp_team_barrier_wait_final ../libgomp/config/posix/bar.h:104
(libgomp.so.1+0x0002286c)
#4 gomp_thread_start ../libgomp/team.c:120 (libgomp.so.1+0x0002286c)

  Location is heap block of size 5440 at 0x7d880001c800 allocated by main
thread:
#0 malloc ../../../../libsanitizer/tsan/tsan_interceptors.cc:538
(libtsan.so.0+0x000298bc)
#1 gomp_malloc ../libgomp/alloc.c:37 (libgomp.so.1+0xb06a)
#2 gomp_new_team ../libgomp/team.c:168 (libgomp.so.1+0x000228fa)
#3 GOMP_parallel ../libgomp/parallel.c:167 (libgomp.so.1+0x000129e3)
#4 main 

[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Markus Trippelsdorf from comment #10)
> The testcase from PR77955:
> 
> markus@x4 /tmp % cat fall.c
> void bar(int);
> 
> void foo(int i) {
>   switch (i) {
>   case 1: {
> bar(1);
> // fall-through
>   }
>   case 2:

Well, this one is even much harder than the preprocessor issue, it isn't
solvable by preserving CPP_COMMENT tokens and ignoring them, there are tokens
in between the fallthru comment and case keyword even after preprocessing here.
I'm afraid this is a clear WONTFIX, move the comment or better use
__attribute__((fallthrough))/[[fallthrough]] instead.

> bar(2);
>   default:
> break;

Not warning here is completely intentional, it is a fallthru into break;

[Bug fortran/77903] gfortran 6.1.0/7.0.0 accept invalid code with conflicting module/submodule interfaces

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> That link worked for me. Thanks

For me too.

I think the reference C1556 (R1527) is rather

C1255 (R1227) If MODULE appears in the prefix of a module subprogram, 
the subprogram shall specify the same characteristics and dummy argument 
names as its corresponding module procedure interface body.

I overlooked it my F2015 draft.

[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
The testcase from PR77955:

markus@x4 /tmp % cat fall.c
void bar(int);

void foo(int i) {
  switch (i) {
  case 1: {
bar(1);
// fall-through
  }
  case 2:
bar(2);
  default:
break;
  }
}
markus@x4 /tmp % gcc -Wimplicit-fallthrough=1 -c fall.c
fall.c: In function ‘foo’:
fall.c:6:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
 bar(1);
 ^~
fall.c:9:3: note: here
   case 2:
   ^~~~

Two issues; the first is the bogus warning, the second that we don't
warn for the case 2 fall-through.

[Bug target/77957] [6/7 Regression] Undefined .LCTOC0 with -fstack-protector-strong -mminimal-toc -O0 on ppc64le

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Target||powerpc64le-linux
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-12
 CC||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
   Target Milestone|--- |6.3
 Ever confirmed|0   |1

[Bug target/77957] New: [6/7 Regression] Undefined .LCTOC0 with -fstack-protector-strong -mminimal-toc -O0 on ppc64le

[jakub at gcc dot gnu.org]

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

Bug ID: 77957
   Summary: [6/7 Regression] Undefined .LCTOC0 with
-fstack-protector-strong -mminimal-toc -O0 on ppc64le
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

void
foo (void)
{
  unsigned long x = 0;
  asm volatile ("" : : "r" () : "memory");
}

int
main ()
{
  foo ();
  return 0;
}

fails to link on powerpc64le-linux with -fstack-protector-strong -mminimal-toc
-O0:
gcc -fstack-protector-strong -mminimal-toc -O0 -o /tmp/test{,.c}
/tmp/ccldrAkU.o: In function `foo':
test.c:(.text+0x20): undefined reference to `.LCTOC0'
collect2: error: ld returned 1 exit status

I can reproduce also with a cross-compiler, the important trigger is that
TARGET_LIBC_PROVIDES_SSP must be defined to 1.  This compiled fine with 4.8,
fails with 6.2 and current trunk.

[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #9 from Marek Polacek  ---
*** Bug 77955 has been marked as a duplicate of this bug. ***

[Bug c/77955] -Wimplicit-fallthrough=1 issue

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Marek Polacek  ---
Ah, right.  Ok.

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

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

Potential bug with wide_int_storage::set_len

[Andre Vieira (lists)]

Hello,

During the development of a patch I encountered some strange behavior
and decided to investigate. The result of which is I think I found a bug
with 'wide_int_storage::set_len' in gcc/wide-int.h.

The function reads:
inline void
wide_int_storage::set_len (unsigned int l, bool is_sign_extended)
{
  len = l;
  if (!is_sign_extended && len * HOST_BITS_PER_WIDE_INT > precision)
val[len - 1] = sext_hwi (val[len - 1],
 precision % HOST_BITS_PER_WIDE_INT);
}

Now assume you have a wide_int_storage, lets call it 'result' with the
following values:
val = [ 0x, ...];
len = 1;
precision = 32;

Say you are running it on a 64-bit host:
#define HOST_BITS_PER_WIDE_INT 64

and you call 'result.set_len (1, false);'

Then this will sign extend the first element of val, to
0x, and I don't think this is what you want.

Due to this, 'expand_expr' will expand a constant tree with unsigned
integer type and value MAX_UINT to a rtx node (const_int -1).

Am I missing something here?

Cheers,
Andre

PS: I will be running tests with a patch to remove the negation in front
of 'is_sign_extended' and post the patch in gcc-patches. If anyone
thinks this is wrong and wants to spare me the effort please reply!

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
>

Potential bug with wide_int_storage::set_len

[Andre Vieira (lists)]

Hello,

During the development of a patch I encountered some strange behavior
and decided to investigate. The result of which is I think I found a bug
with 'wide_int_storage::set_len' in gcc/wide-int.h.

The function reads:
inline void
wide_int_storage::set_len (unsigned int l, bool is_sign_extended)
{
  len = l;
  if (!is_sign_extended && len * HOST_BITS_PER_WIDE_INT > precision)
val[len - 1] = sext_hwi (val[len - 1],
 precision % HOST_BITS_PER_WIDE_INT);
}

Now assume you have a wide_int_storage, lets call it 'result' with the
following values:
val = [ 0x, ...];
len = 1;
precision = 32;

Say you are running it on a 64-bit host:
#define HOST_BITS_PER_WIDE_INT 64

and you call 'result.set_len (1, false);'

Then this will sign extend the first element of val, to
0x, and I don't think this is what you want.

Due to this, 'expand_expr' will expand a constant tree with unsigned
integer type and value MAX_UINT to a rtx node (const_int -1).

Am I missing something here?

Cheers,
Andre

PS: I will be running tests with a patch to remove the negation in front
of 'is_sign_extended' and post the patch in gcc-patches. If anyone
thinks this is wrong and wants to spare me the effort please reply!

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

[Bug c/77955] -Wimplicit-fallthrough=1 issue

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
(In reply to Marek Polacek from comment #4)
> It'll be hard to "fix" the first testcase:
> .

Thanks.

The testcase from comment 3 is a dup of pr77886 and fixed by 
the patch that Jakub posted there.

So if there is already an existing bug for the first testcase,
feel free to close this bug.

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 

[Bug fortran/77903] gfortran 6.1.0/7.0.0 accept invalid code with conflicting module/submodule interfaces

[jvdelisle at charter dot net]

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

--- Comment #5 from jvdelisle at charter dot net ---
On 10/11/2016 10:21 PM, damian at sourceryinstitute dot org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77903
>
> --- Comment #4 from Damian Rouson  ---
> Check the date on your draft.   The latest draft is dated 31 August 2016.
> C1556 appears on page 330. Does the following link work for you?
>
> http://j3-fortran.org/doc/year/16/16-007.pdf
>
> I'm working on obtaining a publicly accessible link in case the above one
> doesn't work.
>
> Damian
>

That link worked for me. Thanks

Jerry