Re: [PATCH] IRA: Don't create new regs for debug insns (PR80429)

[Segher Boessenkool]

On Tue, Apr 18, 2017 at 11:47:40AM +0200, Jakub Jelinek wrote:
> On Tue, Apr 18, 2017 at 09:30:19AM +, Segher Boessenkool wrote:
> > In split_live_ranges_for_shrink_wrap IRA also splits regs that are
> > only used in debug insns, leading to -fcompare-debug failures.
> > 
> > Bootstrapped and tested on powerpc64-linux {-m32,-m64}.  This happens
> > on at least GCC 5, so not a regression; but it is trivial and obvious,
> > is it okay for trunk anyway?
> 
> I think the first question here is if it is beneficial to replace the
> regs in DEBUG_INSNs or not.  If it is beneficial, then it of course
> has to be changed such that it never does
> newreg = ira_create_new_reg (dest);
> just because it sees DEBUG_INSN uses, but otherwise it should do what it
> does now.
> 
> So one option is e.g. to split that loop into two, one doing analysis,
> i.e. that newreg = ira_create_new_reg (dest);, but not
> validate_change (uin, DF_REF_REAL_LOC (use), newreg, true);
> and this loop would also ignore DEBUG_INSN_P.
> And the other loop, with the same content, just without that newreg = ...
> and with the validate_change, as whole guarded with if (newreg),
> replacing stuff on all insns.

Like this?  Tested as before, etc.  Thanks,


Segher


2017-04-18  Segher Boessenkool  

PR rtl-optimization/80429
* ira.c (split_live_ranges_for_shrink_wrap): Don't split regs that
are only used in debug insns.

---
 gcc/ira.c | 25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/gcc/ira.c b/gcc/ira.c
index 7079573..bfb0508 100644
--- a/gcc/ira.c
+++ b/gcc/ira.c
@@ -4992,25 +4992,40 @@ split_live_ranges_for_shrink_wrap (void)
   if (!dest || dest == pic_offset_table_rtx)
continue;
 
-  rtx newreg = NULL_RTX;
+  bool need_newreg = false;
   df_ref use, next;
   for (use = DF_REG_USE_CHAIN (REGNO (dest)); use; use = next)
{
  rtx_insn *uin = DF_REF_INSN (use);
  next = DF_REF_NEXT_REG (use);
 
+ if (DEBUG_INSN_P (uin))
+   continue;
+
  basic_block ubb = BLOCK_FOR_INSN (uin);
  if (ubb == call_dom
  || dominated_by_p (CDI_DOMINATORS, ubb, call_dom))
{
- if (!newreg)
-   newreg = ira_create_new_reg (dest);
- validate_change (uin, DF_REF_REAL_LOC (use), newreg, true);
+ need_newreg = true;
+ break;
}
}
 
-  if (newreg)
+  if (need_newreg)
{
+ rtx newreg = ira_create_new_reg (dest);
+
+ for (use = DF_REG_USE_CHAIN (REGNO (dest)); use; use = next)
+   {
+ rtx_insn *uin = DF_REF_INSN (use);
+ next = DF_REF_NEXT_REG (use);
+
+ basic_block ubb = BLOCK_FOR_INSN (uin);
+ if (ubb == call_dom
+ || dominated_by_p (CDI_DOMINATORS, ubb, call_dom))
+   validate_change (uin, DF_REF_REAL_LOC (use), newreg, true);
+   }
+
  rtx_insn *new_move = gen_move_insn (newreg, dest);
  emit_insn_after (new_move, bb_note (call_dom));
  if (dump_file)
-- 
1.9.3

Re: [PATCH] Fix TYPE_TYPELESS_STORAGE handling (PR middle-end/80423)

[Richard Biener]

On April 19, 2017 7:56:30 AM GMT+02:00, Jakub Jelinek  wrote:
>On Wed, Apr 19, 2017 at 07:45:36AM +0200, Richard Biener wrote:
>> >As mentioned in the PR, we now use TYPE_TYPELESS_STORAGE flag on
>> >ARRAY_TYPEs to denote types that need the special C++ alias
>handling.
>> >The problem is how is that created, we just use build_array_type and
>> >set TYPE_TYPELESS_STORAGE on the result, but build_array_type uses
>type
>> >caching, so we might modify that way some other array type.
>> >If all the array type creation goes through build_cplus_array_type,
>> >that
>> >wouldn't be a problem, as that flag is dependent just on the element
>> >type, but that is not the case, c-family as well as the middle-end
>has
>> >lots of spots that also create array types.  So in the end whether
>> >one gets TYPE_TYPELESS_STORAGE flag or not is quite random, depends
>on
>> >GC etc.
>> >
>> >The following patch attempts to resolve this, by making the type
>> >hashing
>> >take that flag into account.  Bootstrapped/regtested on x86_64-linux
>> >and
>> >i686-linux, ok for trunk?
>> 
>> When changing the C++ function I thought that calling
>build_array_type was
>> wrong and it should instead do the same it does in the other places,
>use
>> its raw creation routine and then the canonical type register stuff. 
>But
>> I was hesitant to change this at this point.
>
>The problem is that as the patch shows, we don't need it in a single
>place
>(the C++ FE), but at least in two places (C++ FE and c-family), and it
>wouldn't surprise me if we don't need it later on in further places
>(e.g. in middle-end, if we have a TYPE_TYPELESS_STORAGE array and say
>DSE
>wants to create a smaller one with the same property).

Hmm, but the C++ FE largely avoids the type cache of the Me and uses its own.  
Apart from a single place in this function.
But as I said I'm AFK and can't really check.

>Using a default argument to build_array_type is likely cleaner indeed,
>I'd just then also swap the arguments to build_array_type_1 (the shared
>vs. typeless_storage).

Sure.  With C++ there's no reason to export _1 variants.  Either overloading or 
default args work for me here.

Richard.

>   Jakub

[SPARC] Fix ICE on FP code in 64-bit mode

[Eric Botcazou]

This is a regression introduced in 64-bit mode on the mainline by the switch 
to LRA, spotted by Jeff and fixed by Vladimir (much thanks to both).

Tested on SPARC/Solaris, applied on the mainline.


2017-04-19  Eric Botcazou  
Vladimir Makarov  

* config/sparc/predicates.md (input_operand): Add comment.  Return
true for any memory operand when LRA is in progress.
* config/sparc/sparc.c (sparc_expand_move): Minor formatting fix.


2017-04-19  Eric Botcazou  
Jeff Law  

* gcc.c-torture/compile/20170419-1.c: New test.


-- 
Eric BotcazouIndex: config/sparc/predicates.md
===
--- config/sparc/predicates.md	(revision 246960)
+++ config/sparc/predicates.md	(working copy)
@@ -373,6 +373,7 @@ (define_predicate "input_operand"
   if (TARGET_ARCH32 && mode == DImode && GET_CODE (op) == CONST_INT)
 return true;
 
+  /* Allow FP constants to be built in integer registers.  */
   if (mclass == MODE_FLOAT && GET_CODE (op) == CONST_DOUBLE)
 return true;
 
@@ -388,7 +389,14 @@ (define_predicate "input_operand"
 
   /* Check for valid MEM forms.  */
   if (GET_CODE (op) == MEM)
-return memory_address_p (mode, XEXP (op, 0));
+{
+  /* Except when LRA is precisely working hard to make them valid
+	 and relying entirely on the constraints.  */
+  if (lra_in_progress)
+	return true;
+
+  return memory_address_p (mode, XEXP (op, 0));
+}
 
   return false;
 })
Index: config/sparc/sparc.c
===
--- config/sparc/sparc.c	(revision 246960)
+++ config/sparc/sparc.c	(working copy)
@@ -1911,9 +1911,8 @@ sparc_expand_move (machine_mode mode, rt
 	  /* We are able to build any SF constant in integer registers
 	 with at most 2 instructions.  */
 	  && (mode == SFmode
-	  /* And any DF constant in integer registers.  */
-	  || (mode == DFmode
-		  && ! can_create_pseudo_p (
+	  /* And any DF constant in integer registers if needed.  */
+	  || (mode == DFmode && !can_create_pseudo_p (
 	return false;
 
   operands[1] = force_const_mem (mode, operands[1]);
extern int __fpclassifyd (double x);

double fdim (double x, double y)
{
   int c = __fpclassifyd (x);
   if (c == 0)
 return (x);
   if (__fpclassifyd (y) == 0)
 return (y);
   if (c == 1)
 return (__builtin_huge_val ());
   return x > y ? x - y : 0.0;
}

[PATCH] Introduce gcov.h header file (PR gcov-profile/80435).

[Martin Liška]

Hi.

I discussed following patch with Jakub and Honza approved it in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80435#c3

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Martin
>From 1aebc17525a0e6b263212bca8f592cf2be5f923c Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 18 Apr 2017 10:20:52 +0200
Subject: [PATCH] Introduce gcov.h header file (PR gcov-profile/80435).

libgcc/ChangeLog:

2017-04-18  Martin Liska  

	PR gcov-profile/80435
	* Makefile.in: Install gcov.h.
	* gcov.h: New file.
	* libgcov.h: Use the header and make __gcov_flush publicly
	visible.
---
 libgcc/Makefile.in | 15 ++-
 libgcc/gcov.h  | 41 +
 libgcc/libgcov.h   |  6 +-
 3 files changed, 52 insertions(+), 10 deletions(-)
 create mode 100644 libgcc/gcov.h

diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index 6f58fd451a6..a1a392de88d 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -907,14 +907,14 @@ libgcov-driver-objects = $(patsubst %,%$(objext),$(LIBGCOV_DRIVER))
 libgcov-objects = $(libgcov-merge-objects) $(libgcov-profiler-objects) \
  $(libgcov-interface-objects) $(libgcov-driver-objects)
 
-$(libgcov-merge-objects): %$(objext): $(srcdir)/libgcov-merge.c $(srcdir)/libgcov.h
+$(libgcov-merge-objects): %$(objext): $(srcdir)/libgcov-merge.c $(srcdir)/gcov.h $(srcdir)/libgcov.h
 	$(gcc_compile) -DL$* -c $(srcdir)/libgcov-merge.c
-$(libgcov-profiler-objects): %$(objext): $(srcdir)/libgcov-profiler.c $(srcdir)/libgcov.h
+$(libgcov-profiler-objects): %$(objext): $(srcdir)/libgcov-profiler.c $(srcdir)/gcov.h $(srcdir)/libgcov.h
 	$(gcc_compile) -DL$* -c $(srcdir)/libgcov-profiler.c
-$(libgcov-interface-objects): %$(objext): $(srcdir)/libgcov-interface.c $(srcdir)/libgcov.h
+$(libgcov-interface-objects): %$(objext): $(srcdir)/libgcov-interface.c $(srcdir)/gcov.h $(srcdir)/libgcov.h
 	$(gcc_compile) -DL$* -c $(srcdir)/libgcov-interface.c
 $(libgcov-driver-objects): %$(objext): $(srcdir)/libgcov-driver.c \
-  $(srcdir)/libgcov-driver-system.c $(srcdir)/libgcov.h
+  $(srcdir)/libgcov-driver-system.c $(srcdir)/gcov.h $(srcdir)/libgcov.h
 	$(gcc_compile) -DL$* -c $(srcdir)/libgcov-driver.c
 
 
@@ -1114,6 +1114,10 @@ install-unwind_h:
 
 all: install-unwind_h-forbuild
 
+install-gcov_h:
+	$(mkinstalldirs) $(DESTDIR)$(libsubdir)/include
+	$(INSTALL_DATA) $(srcdir)/gcov.h $(DESTDIR)$(libsubdir)/include
+
 # Documentation targets (empty).
 .PHONY: info html dvi pdf install-info install-html install-pdf
 
@@ -1171,13 +1175,14 @@ install-leaf: $(install-shared) $(install-libunwind)
 	  esac;			\
 	done
 
-install: install-leaf install-unwind_h
+install: install-leaf install-unwind_h install-gcov_h
 	@: $(MAKE) ; $(MULTIDO) $(FLAGS_TO_PASS) multi-do DO=install
 
 install-strip: install
 
 .PHONY: install install-shared install-libunwind install-strip
 .PHONY: install-unwind_h install-unwind_h-forbuild
+.PHONY: install-gcov_h
 
 # Don't export variables to the environment, in order to not confuse
 # configure.
diff --git a/libgcc/gcov.h b/libgcc/gcov.h
new file mode 100644
index 000..0333ecca837
--- /dev/null
+++ b/libgcc/gcov.h
@@ -0,0 +1,41 @@
+/* GCOV interface routines.
+   Copyright (C) 2017 Free Software Foundation, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it under
+   the terms of the GNU General Public License as published by the Free
+   Software Foundation; either version 3, or (at your option) any later
+   version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+   WARRANTY; without even the implied warranty of MERCHANTABILITY or
+   FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+   for more details.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+
+   You should have received a copy of the GNU General Public License and
+   a copy of the GCC Runtime Library Exception along with this program;
+   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+   .  */
+
+#ifndef GCC_GCOV_H
+#define GCC_GCOV_H
+
+/* Set all counters to zero.  */
+
+extern void __gcov_reset (void);
+
+/* Write profile information to a file.  */
+
+extern void __gcov_dump (void);
+
+/* Write profile information to a file and reset counters to zero.
+   The function does operations under a mutex.  */
+
+extern void __gcov_flush (void);
+
+#endif /* GCC_GCOV_H */
diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
index 6118fe9621a..4c1204ca83c 100644
--- a/libgcc/libgcov.h
+++ b/libgcc/libgcov.h
@@ -42,6 +42,7 @@
 #include "coretypes.h"
 #include "tm.h"
 #include "libgcc_tm.h"
+#include "gcov.h"
 
 #if __CHAR_BIT__ == 8
 typedef unsigned gcov_unsigned_t __attribute__ ((mode (SI)));
@@ -237,16 +238,11 @@ extern void __gcov_init (struct

Re: [PATCH, GCC, stage4] Fix type for .init_array.* and .fini_array.* sections

[Thomas Preudhomme]

Stage 4 ping?

Best regards,

Thomas

On 11/04/17 18:35, Thomas Preudhomme wrote:

Hi,

Several tests started failing for ARM targets (eg. gcc.dg/initpri1.c)
after change 6f9dbcd42f2cf034a9a21f46842c08d2e88449db in binutils. This
is because the non-default priority init_array and fini_array sections
are not created with NOTYPE flag as is the case for default priority
init_array and fini_array sections (see default_section_type_flags in
varasm.c for instance). This patch fixes the issue.

ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2017-04-11  Thomas Preud'homme  

* config/arm/arm.c (arm_elf_asm_cdtor): Create non-default
priority .init_array and .fini_array section with SECTION_NOTYPE
flag.

Testing: with this patch test gcc.dg/initpri1.c succeeds but fails
without.

Is this ok for stage4?

Best regards,

Thomas
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index a2d80cfd645928fb8b3178a8e0c7173adce5d598..f3a6b64b16896e82d6e7a66726a929f0572542d9 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -22593,7 +22593,7 @@ arm_elf_asm_cdtor (rtx symbol, int priority, bool is_ctor)
   sprintf (buf, "%s.%.5u",
 	   is_ctor ? ".init_array" : ".fini_array",
 	   priority);
-  s = get_section (buf, SECTION_WRITE, NULL_TREE);
+  s = get_section (buf, SECTION_WRITE | SECTION_NOTYPE, NULL_TREE);
 }
   else if (is_ctor)
 s = ctors_section;

Re: [PATCH, GCC/ARM, stage4] Set mode for success result of atomic compare and swap

[Thomas Preudhomme]

Stage 4 ping?

Best regards,

Thomas

On 12/04/17 09:59, Thomas Preudhomme wrote:

Hi,

Currently atomic_compare_and_swap_1 define_insn do not have a mode
set for the destination of the set indicating the success result of the
instruction. This is because the operand can be either a CC_Z register
(for 32-bit targets) or a SI register (for 16-bit Thumb targets). This
result in lack of checking for the mode.

This commit use a new CCSI iterator to solve this issue while avoiding
duplication of the patterns. The insn name are kept unique by using
attributes tied to the iterator (SIDI:mode and CCSI:arch) instead of
usign the builtin mode attribute. Expander arm_expand_compare_and_swap
is also adapted accordingly.

ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2017-04-11  Thomas Preud'homme  

* config/arm/iterators.md (CCSI): New mode iterator.
(arch): New mode attribute.
* config/arm/sync.md (atomic_compare_and_swap_1): Rename into ...
(atomic_compare_and_swap_1): This and ...
(atomic_compare_and_swap_1): This.  Use CCSI
code iterator for success result mode.
* config/arm/arm.c (arm_expand_compare_and_swap): Adapt code to use
the corresponding new insn generators.

Testing: arm-none-eabi cross-compiler built successfully for ARMv8-M
Mainline and Baseline without the lack of destination mode warning in
sync.md. Testsuite show no regression.

Is this ok for stage4?

Best regards,

Thomas
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index b24143e32e2f10f3b150f7ed0df4fabb3cc8..cf628714507efd2b5a5ab5de97ef32fd45987d1f 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -28190,17 +28190,32 @@ arm_expand_compare_and_swap (rtx operands[])
   gcc_unreachable ();
 }
 
-  switch (mode)
+  if (TARGET_THUMB1)
 {
-case QImode: gen = gen_atomic_compare_and_swapqi_1; break;
-case HImode: gen = gen_atomic_compare_and_swaphi_1; break;
-case SImode: gen = gen_atomic_compare_and_swapsi_1; break;
-case DImode: gen = gen_atomic_compare_and_swapdi_1; break;
-default:
-  gcc_unreachable ();
+  switch (mode)
+	{
+	case QImode: gen = gen_atomic_compare_and_swapt1qi_1; break;
+	case HImode: gen = gen_atomic_compare_and_swapt1hi_1; break;
+	case SImode: gen = gen_atomic_compare_and_swapt1si_1; break;
+	case DImode: gen = gen_atomic_compare_and_swapt1di_1; break;
+	default:
+	  gcc_unreachable ();
+	}
+}
+  else
+{
+  switch (mode)
+	{
+	case QImode: gen = gen_atomic_compare_and_swap32qi_1; break;
+	case HImode: gen = gen_atomic_compare_and_swap32hi_1; break;
+	case SImode: gen = gen_atomic_compare_and_swap32si_1; break;
+	case DImode: gen = gen_atomic_compare_and_swap32di_1; break;
+	default:
+	  gcc_unreachable ();
+	}
 }
 
-  bdst = TARGET_THUMB1 ? bval : gen_rtx_REG (CCmode, CC_REGNUM);
+  bdst = TARGET_THUMB1 ? bval : gen_rtx_REG (CC_Zmode, CC_REGNUM);
   emit_insn (gen (bdst, rval, mem, oldval, newval, is_weak, mod_s, mod_f));
 
   if (mode == QImode || mode == HImode)
diff --git a/gcc/config/arm/iterators.md b/gcc/config/arm/iterators.md
index e2e588688eb04c158d1c146bca12d84cfb5ff130..48992879a8eecc66eba913c2b9a7c5989c5c7bc6 100644
--- a/gcc/config/arm/iterators.md
+++ b/gcc/config/arm/iterators.md
@@ -45,6 +45,9 @@
 ;; A list of the 32bit and 64bit integer modes
 (define_mode_iterator SIDI [SI DI])
 
+;; A list of atomic compare and swap success return modes
+(define_mode_iterator CCSI [(CC_Z "TARGET_32BIT") (SI "TARGET_THUMB1")])
+
 ;; A list of modes which the VFP unit can handle
 (define_mode_iterator SDF [(SF "") (DF "TARGET_VFP_DOUBLE")])
 
@@ -411,6 +414,10 @@
 ;; Mode attributes
 ;;
 
+;; Determine name of atomic compare and swap from success result mode.  This
+;; distinguishes between 16-bit Thumb and 32-bit Thumb/ARM.
+(define_mode_attr arch [(CC_Z "32") (SI "t1")])
+
 ;; Determine element size suffix from vector mode.
 (define_mode_attr MMX_char [(V8QI "b") (V4HI "h") (V2SI "w") (DI "d")])
 
diff --git a/gcc/config/arm/sync.md b/gcc/config/arm/sync.md
index 1f91b7364d5689145a10bbb193d54a0677b2fd36..b4b4f2e6815e7c31c9874c19af31e908107e6a62 100644
--- a/gcc/config/arm/sync.md
+++ b/gcc/config/arm/sync.md
@@ -191,9 +191,9 @@
 
 ;; Constraints of this pattern must be at least as strict as those of the
 ;; cbranchsi operations in thumb1.md and aim to be as permissive.
-(define_insn_and_split "atomic_compare_and_swap_1"
-  [(set (match_operand 0 "cc_register_operand" "=&c,&l,&l,&l")		;; bool out
-	(unspec_volatile:CC_Z [(const_int 0)] VUNSPEC_ATOMIC_CAS))
+(define_insn_and_split "atomic_compare_and_swap_1"
+  [(set (match_operand:CCSI 0 "cc_register_operand" "=&c,&l,&l,&l")	;; bool out
+	(unspec_volatile:CCSI [(const_int 0)] VUNSPEC_ATOMIC_CAS))
(set (match_operand:SI 1 "s_register_operand" "=&r,&l,&0,&l*h")	;; val out
 	(zero_extend:SI
 	  (match_operand:NARROW 2 "mem_noofs_operand" "+Ua,Ua,Ua,Ua")))	;; memory
@@ -223,9 +

Re: [patch] Fix PR tree-optimization/80426

[Jakub Jelinek]

On Wed, Apr 19, 2017 at 08:20:40AM +0200, Eric Botcazou wrote:
> --- tree-vrp.c(revision 246960)
> +++ tree-vrp.c(working copy)
> @@ -2461,7 +2461,19 @@ extract_range_from_binary_expr_1 (value_
> else if (min_op0)
>   wmin = min_op0;
> else if (min_op1)
> - wmin = minus_p ? wi::neg (min_op1) : min_op1;
> + {
> +   if (minus_p)
> + {
> +   wmin = wi::neg (min_op1);
> +
> +   /* Check for overflow.  */
> +   if (wi::cmp (0, min_op1, sgn)
> +   != wi::cmp (wmin, 0, sgn))

I know this attempts to be a copy of what is used elsewhere, but
at least there it is a result of wi::sub etc.
Wouldn't it be simpler to
  if (sgn == SIGNED && wi::neg_p (min_op1) && wi::neg_p (wmin))
min_ovf = 1;
  else if (sgn == UNSIGNED && wi::ne_p (min_op1, 0))
min_ovf = -1;

I mean, for SIGNED if min_op1 is 0, then wmin is 0 to and we want
min_ovf = 0;
If it is positive, wmin will be surely negative and again we want
min_ovf = 0.  Only if it is negative and its negation is negative
too we want min_ovf = 1 (i.e. wi::cmps (0, most_negative) result).
For UNSIGNED, if min_op1 is 0, again all 3 wi::cmp will yield
0 and min_ovf = 0.  If it is non-zero, it is > 0, therefore it
the first wi::cmp will return -1, the second wi::cmp returns
1 and the third one -1.

Is that what we want (e.g. the UNSIGNED case to overflow pretty much always
except for 0 which should be optimized away anyway)?

Or, shouldn't we just set if (!min_op0 && min_op1 && minus_p) min_op0 =
build_int_cst (expr_type, 0); before the if (min_op0 && min_op1) case
and don't duplicate that?

Jakub

Re: [PATCH] IRA: Don't create new regs for debug insns (PR80429)

[Jakub Jelinek]

On Wed, Apr 19, 2017 at 02:56:47AM -0500, Segher Boessenkool wrote:
> On Tue, Apr 18, 2017 at 11:47:40AM +0200, Jakub Jelinek wrote:
> > On Tue, Apr 18, 2017 at 09:30:19AM +, Segher Boessenkool wrote:
> > > In split_live_ranges_for_shrink_wrap IRA also splits regs that are
> > > only used in debug insns, leading to -fcompare-debug failures.
> > > 
> > > Bootstrapped and tested on powerpc64-linux {-m32,-m64}.  This happens
> > > on at least GCC 5, so not a regression; but it is trivial and obvious,
> > > is it okay for trunk anyway?
> > 
> > I think the first question here is if it is beneficial to replace the
> > regs in DEBUG_INSNs or not.  If it is beneficial, then it of course
> > has to be changed such that it never does
> > newreg = ira_create_new_reg (dest);
> > just because it sees DEBUG_INSN uses, but otherwise it should do what it
> > does now.
> > 
> > So one option is e.g. to split that loop into two, one doing analysis,
> > i.e. that newreg = ira_create_new_reg (dest);, but not
> > validate_change (uin, DF_REF_REAL_LOC (use), newreg, true);
> > and this loop would also ignore DEBUG_INSN_P.
> > And the other loop, with the same content, just without that newreg = ...
> > and with the validate_change, as whole guarded with if (newreg),
> > replacing stuff on all insns.
> 
> Like this?  Tested as before, etc.  Thanks,
> 
> 
> Segher
> 
> 
> 2017-04-18  Segher Boessenkool  
> 
>   PR rtl-optimization/80429
>   * ira.c (split_live_ranges_for_shrink_wrap): Don't split regs that
>   are only used in debug insns.

Ok, thanks.

Jakub

Re: [PATCH, GCC, stage4] Fix type for .init_array.* and .fini_array.* sections

[Kyrill Tkachov]

Hi Thomas,

On 11/04/17 18:35, Thomas Preudhomme wrote:

Hi,

Several tests started failing for ARM targets (eg. gcc.dg/initpri1.c)
after change 6f9dbcd42f2cf034a9a21f46842c08d2e88449db in binutils. This
is because the non-default priority init_array and fini_array sections
are not created with NOTYPE flag as is the case for default priority
init_array and fini_array sections (see default_section_type_flags in
varasm.c for instance). This patch fixes the issue.

ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2017-04-11  Thomas Preud'homme  

* config/arm/arm.c (arm_elf_asm_cdtor): Create non-default
priority .init_array and .fini_array section with SECTION_NOTYPE
flag.

Testing: with this patch test gcc.dg/initpri1.c succeeds but fails
without.

Is this ok for stage4?



This is ok if a bootstrap and test run on arm-none-linux-gnueabihf shows no 
problems.

Thanks,
Kyrill


Best regards,

Thomas

[patch,avr] Fix PR80462

[Georg-Johann Lay]

This PR is about an incorrect warning for variables in progmem
without initializer.  If the variable is just an alias like in
and with -fmerge-all-constants

const __flash char string1[] = "same string";
const __flash char string2[] = "same string";

this will result in an incorrect

warning: uninitialized variable 'string2' put into program memory area 
[-Wuninitialized]


Hence, this patch tests whether the decl is just an alias.

Ok to apply?

Johann

PR target/80462
* config/avr/avr.c (tree.h): Include it.
(cgraph.h): Include it.
(avr_encode_section_info): Don't warn for uninitialized progmem
variable if it's just an alias.

Index: config/avr/avr.c
===
--- config/avr/avr.c	(revision 246966)
+++ config/avr/avr.c	(working copy)
@@ -25,6 +25,8 @@
 #include "backend.h"
 #include "target.h"
 #include "rtl.h"
+#include "tree.h"
+#include "cgraph.h"
 #include "c-family/c-common.h"
 #include "cfghooks.h"
 #include "df.h"
@@ -10127,9 +10129,14 @@ avr_encode_section_info (tree decl, rtx
   && !DECL_EXTERNAL (decl)
   && avr_progmem_p (decl, DECL_ATTRIBUTES (decl)))
 {
-  warning (OPT_Wuninitialized,
-   "uninitialized variable %q+D put into "
-   "program memory area", decl);
+  // Don't warn for (implicit) aliases like in PR80462.
+  tree asmname = DECL_ASSEMBLER_NAME (decl);
+  varpool_node *node = varpool_node::get_for_asmname (asmname);
+  bool alias_p = node && node->alias;
+
+  if (!alias_p)
+warning (OPT_Wuninitialized, "uninitialized variable %q+D put into "
+ "program memory area", decl);
 }
 
   default_encode_section_info (decl, rtl, new_decl_p);

[PATCH] PR libstdc++/80446 cope with libc defining __has_builtin

[Jonathan Wakely]

Both newlib and FreeBSD have this in libc headers:

#ifndef __has_builtin
#define __has_builtin(x) 0
#endif

This means our attempts to use #ifdef __has_builtin aren't reliable,
so we need a different approach. With this patch we don't care whether
it's defined or not, only its value.

PR libstdc++/80446
* include/std/type_traits (is_aggregate): Change __has_builtin checks.
* libsupc++/new (launder): Likewise.

Tested ppc64le-linux and x86_64-freebsd11.0, committed to trunk.


commit 5c3b069722fb9182972fa551a83cc10f42c6fbce
Author: Jonathan Wakely 
Date:   Wed Apr 19 10:57:59 2017 +0100

PR libstdc++/80446 cope with libc defining __has_builtin

PR libstdc++/80446
* include/std/type_traits (is_aggregate): Change __has_builtin checks.
* libsupc++/new (launder): Likewise.

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index 8ea2801..aac7cff 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -3062,14 +3062,16 @@ template 
 #endif
 #undef _GLIBCXX_NO_BUILTIN_HAS_UNIQ_OBJ_REP
 
-#ifdef __has_builtin
-# if !__has_builtin(__is_aggregate)
-// Try not to break non-GNU compilers that don't support the built-in:
-#  define _GLIBCXX_NO_BUILTIN_IS_AGGREGATE 1
+#if __GNUC__ >= 7
+# define _GLIBCXX_HAVE_BUILTIN_IS_AGGREGATE 1
+#elif defined __has_builtin
+// For non-GNU compilers:
+# if __has_builtin(__is_aggregate)
+#  define _GLIBCXX_HAVE_BUILTIN_IS_AGGREGATE 1
 # endif
 #endif
 
-#ifndef _GLIBCXX_NO_BUILTIN_IS_AGGREGATE
+#ifdef _GLIBCXX_HAVE_BUILTIN_IS_AGGREGATE
 #define __cpp_lib_is_aggregate 201703
   /// is_aggregate
   template
@@ -3080,7 +3082,7 @@ template 
   template
 inline constexpr bool is_aggregate_v = is_aggregate<_Tp>::value;
 #endif
-#undef _GLIBCXX_NO_BUILTIN_IS_AGGREGATE
+#undef _GLIBCXX_HAVE_BUILTIN_IS_AGGREGATE
 
 #endif // C++17
 
diff --git a/libstdc++-v3/libsupc++/new b/libstdc++-v3/libsupc++/new
index 9a7859d..2de7752 100644
--- a/libstdc++-v3/libsupc++/new
+++ b/libstdc++-v3/libsupc++/new
@@ -177,14 +177,16 @@ inline void operator delete[](void*, void*) 
_GLIBCXX_USE_NOEXCEPT { }
 } // extern "C++"
 
 #if __cplusplus > 201402L
-#ifdef __has_builtin
-# if !__has_builtin(__builtin_launder)
-// Try not to break non-GNU compilers that don't support the built-in:
-#  define _GLIBCXX_NO_BUILTIN_LAUNDER 1
+#if __GNUC__ >= 7
+#  define _GLIBCXX_HAVE_BUILTIN_LAUNDER 1
+#elif defined __has_builtin
+// For non-GNU compilers:
+# if __has_builtin(__builtin_launder)
+#  define _GLIBCXX_HAVE_BUILTIN_LAUNDER 1
 # endif
 #endif
 
-#ifndef _GLIBCXX_NO_BUILTIN_LAUNDER
+#ifdef _GLIBCXX_HAVE_BUILTIN_LAUNDER
 namespace std
 {
 #define __cpp_lib_launder 201606
@@ -208,7 +210,7 @@ namespace std
   void launder(const volatile void*) = delete;
 }
 #endif // _GLIBCXX_NO_BUILTIN_LAUNDER
-#undef _GLIBCXX_NO_BUILTIN_LAUNDER
+#undef _GLIBCXX_HAVE_BUILTIN_LAUNDER
 #endif // C++17
 
 #pragma GCC visibility pop

Re: Fix ICE with -fauto-profile when walking vdefs

[Martin Liška]

On 04/18/2017 08:05 PM, Sebastian Pop wrote:

On Mon, Apr 3, 2017 at 5:34 AM, Richard Biener  wrote:

On Fri, 31 Mar 2017, Sebastian Pop wrote:


On Fri, Mar 31, 2017 at 12:06 PM, Richard Biener  wrote:

Does the following fix it?

Index: gcc/auto-profile.c
===
--- gcc/auto-profile.c  (revision 246642)
+++ gcc/auto-profile.c  (working copy)
@@ -1511,7 +1511,9 @@ afdo_vpt_for_early_inline (stmt_set *pro

   if (has_vpt)
 {
-  optimize_inline_calls (current_function_decl);
+  unsigned todo = optimize_inline_calls (current_function_decl);
+  if (todo & TODO_update_ssa_any)
+   update_ssa (TODO_update_ssa);
   return true;
 }


Yes, this patch solves the problem, and this is also what Dehao has
suggested in his last comment in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972

Thanks,
Sebastian


Hi.

I've just tested the patch and survives bootstrap.
May I install the patch?

Martin






afdo really _grossly_ over-does inlining.  And it looks like a total
hack to me.

It iterates PARAM_EARLY_INLINER_MAX_ITERATIONS but early_inliner does
that itself already..


>From b778a13b31b4237e147ab4d0dbc7651dda000def Mon Sep 17 00:00:00 2001
From: marxin 
Date: Wed, 19 Apr 2017 10:00:35 +0200
Subject: [PATCH] Update SSA after AutoPGO early inlining (PR ipa/65972).

gcc/ChangeLog:

2017-04-19  Richard Biener  

	PR ipa/65972
	* auto-profile.c (afdo_vpt_for_early_inline): Update SSA
	when needed by AutoPGO.
---
 gcc/auto-profile.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/auto-profile.c b/gcc/auto-profile.c
index 4b21340c6f0..4e498dc6b0e 100644
--- a/gcc/auto-profile.c
+++ b/gcc/auto-profile.c
@@ -1511,7 +1511,9 @@ afdo_vpt_for_early_inline (stmt_set *promoted_stmts)
 
   if (has_vpt)
 {
-  optimize_inline_calls (current_function_decl);
+  unsigned todo = optimize_inline_calls (current_function_decl);
+  if (todo & TODO_update_ssa_any)
+   update_ssa (TODO_update_ssa);
   return true;
 }
 
-- 
2.12.2

[PATCH] PR libstdc++/80448 remove noexcept from defaulted functions

[Jonathan Wakely]

Clang trunk won't compile  due to a conflict
between a default member initializer and "foo() noexcept = default;"
so this simply removes the noexept. The defaulted constructors should
still be noexcept anyway, so there's no need to explicitly require it.

PR libstdc++/80448
* include/experimental/bits/fs_dir.h (directory_iterator)
(recursive_directory_iterator): Remove noexcept from defaulted
constructors.

Tested ppc64le-linux, committed to trunk.


commit 2a66f241c739fc2c3c93e82a30bee97823a8df63
Author: Jonathan Wakely 
Date:   Wed Apr 19 11:52:27 2017 +0100

PR libstdc++/80448 remove noexcept from defaulted functions

PR libstdc++/80448
* include/experimental/bits/fs_dir.h (directory_iterator)
(recursive_directory_iterator): Remove noexcept from defaulted
constructors.

diff --git a/libstdc++-v3/include/experimental/bits/fs_dir.h 
b/libstdc++-v3/include/experimental/bits/fs_dir.h
index 3bdf911..0efaf94 100644
--- a/libstdc++-v3/include/experimental/bits/fs_dir.h
+++ b/libstdc++-v3/include/experimental/bits/fs_dir.h
@@ -181,7 +181,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 typedef const directory_entry& reference;
 typedef input_iterator_tag iterator_category;
 
-directory_iterator() noexcept = default;
+directory_iterator() = default;
 
 explicit
 directory_iterator(const path& __p)
@@ -262,7 +262,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 typedef const directory_entry& reference;
 typedef input_iterator_tag iterator_category;
 
-recursive_directory_iterator() noexcept = default;
+recursive_directory_iterator() = default;
 
 explicit
 recursive_directory_iterator(const path& __p)
@@ -282,8 +282,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 recursive_directory_iterator(
 const recursive_directory_iterator&) = default;
 
-recursive_directory_iterator(
-recursive_directory_iterator&&) noexcept = default;
+recursive_directory_iterator(recursive_directory_iterator&&) = default;
 
 ~recursive_directory_iterator();
 

[Patch, testsuite] Fix broken pr80341.c for avr

[Senthil Kumar Selvaraj]

Hi,

  This patch skips pr80341.c for targets with int size less than 32 bits.
  The assertion in the testcase holds only if sizeof(int) > sizeof(short), 
  which isn't true for smaller int size targets like the avr.

  Specifically, after integer promotion, the "usual arithmetic
  conversion" of the unsigned short to signed int doesn't occur, and
  this causes the test to fail.

  Committed as obvious.

Regards
Senthil

2017-04-19  Senthil Kumar Selvaraj  

* gcc.dg/torture/pr80341.c: Require int32plus.

Index: gcc.dg/torture/pr80341.c
===
--- gcc.dg/torture/pr80341.c(revision 246991)
+++ gcc.dg/torture/pr80341.c(working copy)
@@ -1,5 +1,6 @@
 /* { dg-do run } */
 /* { dg-additional-options "-Wno-overflow" } */
+/* { dg-require-effective-target int32plus } */
 
 const signed char c = -84;
 signed char s;

Re: [patch,avr] Fix PR80462

[Denis Chertykov]

2017-04-19 14:43 GMT+04:00 Georg-Johann Lay :
> This PR is about an incorrect warning for variables in progmem
> without initializer.  If the variable is just an alias like in
> and with -fmerge-all-constants
>
> const __flash char string1[] = "same string";
> const __flash char string2[] = "same string";
>
> this will result in an incorrect
>
> warning: uninitialized variable 'string2' put into program memory area
> [-Wuninitialized]
>
> Hence, this patch tests whether the decl is just an alias.
>
> Ok to apply?
>
> Johann
>
> PR target/80462
> * config/avr/avr.c (tree.h): Include it.
> (cgraph.h): Include it.
> (avr_encode_section_info): Don't warn for uninitialized progmem
> variable if it's just an alias.
>


Please apply.

[DOC][OBVIOUS] Fix typo in LTO documentation (PR lto/50345).

[Martin Liška]

Simple patch that's attached here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50345#c2

Installed as obvious.

Martin
>From 175a12777c8c17e9fbd0fb00c78ecb6c9c6b528e Mon Sep 17 00:00:00 2001
From: marxin 
Date: Wed, 19 Apr 2017 13:56:29 +0200
Subject: [PATCH] Fix typo in LTO documentation (PR lto/50345).

gcc/ChangeLog:

2017-04-19  Paulo J. Matos  

	PR lto/50345
	* doc/lto.texi: Remove an extra 'that'.
---
 gcc/doc/lto.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/lto.texi b/gcc/doc/lto.texi
index 1d36f744d55..990c06f9444 100644
--- a/gcc/doc/lto.texi
+++ b/gcc/doc/lto.texi
@@ -43,7 +43,7 @@ existing build systems, as one can, for instance, produce archives of
 the files.  Additionally, one might be able to ship one set of fat
 objects which could be used both for development and the production of
 optimized builds.  A, perhaps surprising, side effect of this feature
-is that any mistake in the toolchain that leads to LTO information not
+is that any mistake in the toolchain leads to LTO information not
 being used (e.g.@: an older @code{libtool} calling @code{ld} directly).
 This is both an advantage, as the system is more robust, and a
 disadvantage, as the user is not informed that the optimization has
-- 
2.12.2

Re: Fix ICE with -fauto-profile when walking vdefs

[Richard Biener]

On April 19, 2017 12:55:24 PM GMT+02:00, "Martin Liška"  wrote:
>On 04/18/2017 08:05 PM, Sebastian Pop wrote:
>> On Mon, Apr 3, 2017 at 5:34 AM, Richard Biener 
>wrote:
>>> On Fri, 31 Mar 2017, Sebastian Pop wrote:
>>>
 On Fri, Mar 31, 2017 at 12:06 PM, Richard Biener
> wrote:
>>> Does the following fix it?
>>>
>>> Index: gcc/auto-profile.c
>>> ===
>>> --- gcc/auto-profile.c  (revision 246642)
>>> +++ gcc/auto-profile.c  (working copy)
>>> @@ -1511,7 +1511,9 @@ afdo_vpt_for_early_inline (stmt_set *pro
>>>
>>>if (has_vpt)
>>>  {
>>> -  optimize_inline_calls (current_function_decl);
>>> +  unsigned todo = optimize_inline_calls
>(current_function_decl);
>>> +  if (todo & TODO_update_ssa_any)
>>> +   update_ssa (TODO_update_ssa);
>>>return true;
>>>  }
>>
>> Yes, this patch solves the problem, and this is also what Dehao has
>> suggested in his last comment in
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972
>>
>> Thanks,
>> Sebastian
>
>Hi.
>
>I've just tested the patch and survives bootstrap.
>May I install the patch?


Yes.

Richard.
>Martin
>
>>
>>>
>>>
>>> afdo really _grossly_ over-does inlining.  And it looks like a total
>>> hack to me.
>>>
>>> It iterates PARAM_EARLY_INLINER_MAX_ITERATIONS but early_inliner
>does
>>> that itself already..

Re: [PATCH GCC8][33/33]Fix PR69710/PR68030 by reassociate vect base address and a simple CSE pass

[Bin.Cheng]

On Tue, Apr 18, 2017 at 10:25 PM, Michael Meissner
 wrote:
> I did a bootstrap and make check-{gcc,c++,fortran,lto} comparing the results 
> to
> the baseline (subversion id 246975).
>
> There were 2 differences:
>
> The baseline failed on gcc.dg/sms-4.c but succeeded on gcc.dg/sms-1.c.
>
> Here are the sms-[14] lines from the baseline:
>
> Executing on host: /home/meissner/fsf-build-ppc64le/trunk-246975/gcc/xgcc 
> -B/home/meissner/fsf-build-ppc64le/trunk-246975/gcc/ 
> /home/meissner/fsf-src/trunk-246975/gcc/testsuite/gcc.dg/sms-4.c  
> -fno-diagnostics-show-caret
>  -fdiagnostics-color=never  -O2 -fmodulo-sched -fmodulo-sched-allow-regmoves 
> -fdump-rtl-sms --param sms-min-sc=1 -ffat-lto-objects  -lm-o ./sms-4.exe  
>   (timeout = 300)
> spawn /home/meissner/fsf-build-ppc64le/trunk-246975/gcc/xgcc 
> -B/home/meissner/fsf-build-ppc64le/trunk-246975/gcc/ 
> /home/meissner/fsf-src/trunk-246975/gcc/testsuite/gcc.dg/sms-4.c 
> -fno-diagnostics-show-caret -fdiagnostics
> -color=never -O2 -fmodulo-sched -fmodulo-sched-allow-regmoves -fdump-rtl-sms 
> --param sms-min-sc=1 -ffat-lto-objects -lm -o ./sms-4.exe
> PASS: gcc.dg/sms-4.c (test for excess errors)
> Setting LD_LIBRARY_PATH to 
> :/home/meissner/fsf-build-ppc64le/trunk-246975/gcc:/home/meissner/fsf-build-ppc64le/trunk-246975/powerpc64le-unknown-linux-gnu/./libatomic/.libs::/home/meissner/fsf-build-ppc64le/trunk-246975/g
> cc:/home/meissner/fsf-build-ppc64le/trunk-246975/powerpc64le-unknown-linux-gnu/./libatomic/.libs:
> spawn [open ...]
> PASS: gcc.dg/sms-4.c execution test
> FAIL: gcc.dg/sms-4.c scan-rtl-dump-times sms "SMS succeeded" 1
>
> Executing on host: /home/meissner/fsf-build-ppc64le/trunk-246975/gcc/xgcc 
> -B/home/meissner/fsf-build-ppc64le/trunk-246975/gcc/ 
> /home/meissner/fsf-src/trunk-246975/gcc/testsuite/gcc.dg/sms-1.c  
> -fno-diagnostics-show-caret -fdiagnostics-color=never  -O2 -fmodulo-sched 
> -fmodulo-sched-allow-regmoves -fdump-rtl-sms -ffat-lto-objects  -lm-o 
> ./sms-1.exe(timeout = 300)
> spawn /home/meissner/fsf-build-ppc64le/trunk-246975/gcc/xgcc 
> -B/home/meissner/fsf-build-ppc64le/trunk-246975/gcc/ 
> /home/meissner/fsf-src/trunk-246975/gcc/testsuite/gcc.dg/sms-1.c 
> -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fmodulo-sched 
> -fmodulo-sched-allow-regmoves -fdump-rtl-sms -ffat-lto-objects -lm -o 
> ./sms-1.exe
> PASS: gcc.dg/sms-1.c (test for excess errors)
> Setting LD_LIBRARY_PATH to 
> :/home/meissner/fsf-build-ppc64le/trunk-246975/gcc:/home/meissner/fsf-build-ppc64le/trunk-246975/powerpc64le-unknown-linux-gnu/./libatomic/.libs::/home/meissner/fsf-build-ppc64le/trunk-246975/gcc:/home/meissner/fsf-build-ppc64le/trunk-246975/powerpc64le-unknown-linux-gnu/./libatomic/.libs:
> spawn [open ...]
> PASS: gcc.dg/sms-1.c execution test
> PASS: gcc.dg/sms-1.c scan-rtl-dump-times sms "SMS succeeded" 1
>
> While here are the lines from the ivopts run:
>
> Executing on host: /home/meissner/fsf-build-ppc64le/ivopts/gcc/xgcc 
> -B/home/meissner/fsf-build-ppc64le/ivopts/gcc/ 
> /home/meissner/fsf-src/ivopts/gcc/testsuite/gcc.dg/sms-1.c  
> -fno-diagnostics-show-caret -fdiagnostics-color=never  -O2 -fmodulo-sched 
> -fmodulo-sched-allow-regmoves -fdump-rtl-sms -ffat-lto-objects  -lm-o 
> ./sms-1.exe(timeout = 300)
> spawn /home/meissner/fsf-build-ppc64le/ivopts/gcc/xgcc 
> -B/home/meissner/fsf-build-ppc64le/ivopts/gcc/ 
> /home/meissner/fsf-src/ivopts/gcc/testsuite/gcc.dg/sms-1.c 
> -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fmodulo-sched 
> -fmodulo-sched-allow-regmoves -fdump-rtl-sms -ffat-lto-objects -lm -o 
> ./sms-1.exe
> PASS: gcc.dg/sms-1.c (test for excess errors)
> Setting LD_LIBRARY_PATH to 
> :/home/meissner/fsf-build-ppc64le/ivopts/gcc:/home/meissner/fsf-build-ppc64le/ivopts/powerpc64le-unknown-linux-gnu/./libatomic/.libs::/home/meissner/fsf-build-ppc64le/ivopts/gcc:/home/meissner/fsf-build-ppc64le/ivopts/powerpc64le-unknown-linux-gnu/./libatomic/.libs:
> spawn [open ...]
> PASS: gcc.dg/sms-1.c execution test
> FAIL: gcc.dg/sms-1.c scan-rtl-dump-times sms "SMS succeeded" 1
>
> Executing on host: /home/meissner/fsf-build-ppc64le/ivopts/gcc/xgcc 
> -B/home/meissner/fsf-build-ppc64le/ivopts/gcc/ 
> /home/meissner/fsf-src/ivopts/gcc/testsuite/gcc.dg/sms-4.c  
> -fno-diagnostics-show-caret -fdiagnostics-color=never  -O2 -fmodulo-sched 
> -fmodulo-sched-allow-regmoves -fdump-rtl-sms --param sms-min-sc=1 
> -ffat-lto-objects  -lm-o ./sms-4.exe(timeout = 300)
> spawn /home/meissner/fsf-build-ppc64le/ivopts/gcc/xgcc 
> -B/home/meissner/fsf-build-ppc64le/ivopts/gcc/ 
> /home/meissner/fsf-src/ivopts/gcc/testsuite/gcc.dg/sms-4.c 
> -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fmodulo-sched 
> -fmodulo-sched-allow-regmoves -fdump-rtl-sms --param sms-min-sc=1 
> -ffat-lto-objects -lm -o ./sms-4.exe
> PASS: gcc.dg/sms-4.c (test for excess errors)
> Setting LD_LIBRARY_PATH to 
> :/home/meissner/fsf-build-ppc64le/ivopts/gcc:/home/meissner/fsf-build-ppc64le/ivopts/powe

[PATCH] doc: mention handling of {0} in -Wmissing-field-initializers (PR 71250)

[Alexander Monakov]

Hi,

PR 71250 asks to explicitly document that -Wmissing-field-initializers warning
was enhanced some time ago to suppress warnings on uses of the universal zero
initializer { 0 } in C language.  The documentation already calls out that the
warning is silenced in C++ for '{ }', the patch adds the corresponding C example
just before that.

Sanity-checked with 'make info html', ok to apply?

Alexander

PR other/71250
* doc/invoke.texi (-Wmissing-field-initializers): Mention that warning
is suppressed for '{ 0 }' in C.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8d3821e..726d4c1 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -6220,7 +6220,15 @@ struct s @{ int f, g, h; @};
 struct s x = @{ .f = 3, .g = 4 @};
 @end smallexample

-In C++ this option does not warn either about the empty @{ @}
+In C this option does not warn about the universal zero initializer
+@samp{@{ 0 @}}:
+
+@smallexample
+struct s @{ int f, g, h; @};
+struct s x = @{ 0 @};
+@end smallexample
+
+Likewise, in C++ this option does not warn about the empty @{ @}
 initializer, for example:

 @smallexample

[PATCH RFC] Check for __cxa_atexit when building native compiler

[Kang-Che Sung]

From: Explorer09 

(This is my first time submitting a patch for GCC)

I found the logic of use_cxa_atexit in configure script a little
bit weird.

It first looks up the default_use_cxa_atexit value for the target,
then, for building the native compiler, checks for __cxa_atexit
in libc. But, from what I read about __cxa_atexit, it should be the
recommended way for registering destructors, and in other words, GCC
shall --enable-__cxa_atexit whenever libc has it, or when _we_ have its
implementation for the target.

The logic should be:
When building native compiler, check for libc's function despite
default_use_cxa_atexit defined for the target, and
default_use_cxa_atexit be used only when building a cross.

Do I understand it wrong?

Below is the patch for the proposed logic change. Thank you.

2017-04-19  Kang-Che Sung  

* configure.ac (use_cxa_atexit): When building native compiler,
ignore $default_use_cxa_atexit and check for libc's __cxa_atexit.
* configure: Regenerate.

---
 gcc/ChangeLog|  6 ++
 gcc/configure.ac | 24 ++--
 gcc/configure| 27 ---
 3 files changed, 36 insertions(+), 21 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index d52db8a3609..e93789faf9c 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2017-04-19  Kang-Che Sung  
+
+   * configure.ac (use_cxa_atexit): When building native compiler,
+   ignore $default_use_cxa_atexit and check for libc's __cxa_atexit.
+   * configure: Regenerate.
+
 2017-04-19  Eric Botcazou  
 Vladimir Makarov  
 
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 9d4c792a33f..cf7ddce79c1 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -1632,9 +1632,8 @@ fi
 # 
 
 use_cxa_atexit=no
-if test x$enable___cxa_atexit = xyes || \
-   test x$enable___cxa_atexit = x -a x$default_use_cxa_atexit = xyes; then
-  if test x$host = x$target; then
+if test x$host = x$target; then
+  if test x$enable___cxa_atexit != xno; then
 case $host in
   # mingw32 doesn't have __cxa_atexit but uses atexit registration
   # keyed to flag_use_cxa_atexit
@@ -1645,22 +1644,27 @@ if test x$enable___cxa_atexit = xyes || \
use_cxa_atexit=yes
;;
   *)
-   AC_CHECK_FUNC(__cxa_atexit,[use_cxa_atexit=yes],
- [echo "__cxa_atexit can't be enabled on this target"])
+   AC_CHECK_FUNC(__cxa_atexit, [use_cxa_atexit=yes],[
+  if test x$enable___cxa_atexit = xyes; then
+AC_MSG_ERROR([__cxa_atexit can't be enabled on this target])
+  fi])
;;
 esac
-  else
-# We can't check for __cxa_atexit when building a cross, so assume
-# it is available 
+  fi
+else
+  # Can't check presence of libc functions during cross-compile, so respect
+  # user or use our default.
+  if test x$enable___cxa_atexit = xyes || \
+ test x$enable___cxa_atexit = x -a x$default_use_cxa_atexit = xyes; then
 use_cxa_atexit=yes
   fi
-  if test x$use_cxa_atexit = xyes; then
+fi
+if test x$use_cxa_atexit = xyes; then
 AC_DEFINE(DEFAULT_USE_CXA_ATEXIT, 2,
   [Define if you want to use __cxa_atexit, rather than atexit, to
   register C++ destructors for local statics and global objects.
   This is essential for fully standards-compliant handling of
   destructors, but requires __cxa_atexit in libc.])
-  fi
 fi
 
 # Look for a file containing extra machine modes.
-- 
2.11.0

Re: [PATCH, GCC/ARM, stage4] Set mode for success result of atomic compare and swap

[Kyrill Tkachov]

Hi Thomas,

On 12/04/17 09:59, Thomas Preudhomme wrote:

Hi,

Currently atomic_compare_and_swap_1 define_insn do not have a mode
set for the destination of the set indicating the success result of the
instruction. This is because the operand can be either a CC_Z register
(for 32-bit targets) or a SI register (for 16-bit Thumb targets). This
result in lack of checking for the mode.

This commit use a new CCSI iterator to solve this issue while avoiding
duplication of the patterns. The insn name are kept unique by using
attributes tied to the iterator (SIDI:mode and CCSI:arch) instead of
usign the builtin mode attribute. Expander arm_expand_compare_and_swap
is also adapted accordingly.

ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2017-04-11  Thomas Preud'homme  

* config/arm/iterators.md (CCSI): New mode iterator.
(arch): New mode attribute.
* config/arm/sync.md (atomic_compare_and_swap_1): Rename into ...
(atomic_compare_and_swap_1): This and ...
(atomic_compare_and_swap_1): This.  Use CCSI
code iterator for success result mode.
* config/arm/arm.c (arm_expand_compare_and_swap): Adapt code to use
the corresponding new insn generators.

Testing: arm-none-eabi cross-compiler built successfully for ARMv8-M
Mainline and Baseline without the lack of destination mode warning in
sync.md. Testsuite show no regression.



Thanks for fixing these warnings.
The code looks ok to me but
I'd like to make sure that the rest of the arm atomic targets are not adversely 
affected,
so please also do a test run for ARMv7-A and ARMv8-A targets.
Also, a bootstrap is required as always.

Ok with that testing.

Thanks,
Kyrill


Is this ok for stage4?

Best regards,

Thomas

[PATCH] Fix -fcompare-debug bugs during updating into loop closed ssa form (PR debug/80436)

[Jakub Jelinek]

Hi!

-fcompare-debug fails on the following testcase, because during loop
splitting we attempt to switch into loop closed SSA form and use
also debug stmt uses in those decisions, which is wrong.
Looking at the rest of tree-ssa-loop-manip.c, both find_uses_to_rename_stmt
and check_loop_closed_ssa_stmt ignore debug stmts, this patch just adds
that to another spot.  Without it a new SSA_NAME is created (only with -g)
and then soon (in the next pass) removed again because DCE sees it as
dead (it has no non-debug uses) and is replaced by the definition from the
loop again.

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

2017-04-19  Jakub Jelinek  

PR debug/80436
* tree-ssa-loop-manip.c (find_uses_to_rename_def): Ignore debug uses.

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

--- gcc/tree-ssa-loop-manip.c.jj2017-02-27 15:19:12.0 +0100
+++ gcc/tree-ssa-loop-manip.c   2017-04-19 09:47:30.768610273 +0200
@@ -494,6 +494,9 @@ find_uses_to_rename_def (tree def, bitma
 
   FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, def)
 {
+  if (is_gimple_debug (use_stmt))
+   continue;
+
   basic_block use_bb = gimple_bb (use_stmt);
 
   use_operand_p use_p;
--- gcc/testsuite/g++.dg/opt/pr80436.C.jj   2017-04-19 09:54:59.370714079 
+0200
+++ gcc/testsuite/g++.dg/opt/pr80436.C  2017-04-19 09:56:28.003549930 +0200
@@ -0,0 +1,42 @@
+// PR debug/80436
+// { dg-do compile { target c++11 } }
+// { dg-options "-O3 -fcompare-debug" }
+
+void fn (...);
+void foo (int, int, int);
+struct { int elt1; int bits; } *a;
+int b, d;
+
+int
+bar (unsigned *x)
+{
+  if (0)
+  next_bit:
+return 1;
+  while (1)
+{
+  if (b)
+   if (a->bits)
+ goto next_bit;
+  *x = b;
+  if (a->elt1)
+   return 0;
+  a = 0;
+}
+}
+
+enum { C0, C1 } *c;
+
+void
+baz ()
+{
+  int e, m = d;
+  for (; e < m; e++)
+{
+  if (e < 0)
+   foo (0, 0, c[e]);
+  unsigned f;
+  for (; bar (&f);)
+   fn (f);
+}
+}

Jakub

[PATCH] Adjust c-c++-common/opaque-vector.c testcase (PR c++/80459)

[Jakub Jelinek]

Hi!

The testcase attempts to use long double __attribute__((vector_size (16)))
vector and in addition to that uses __typeof((v

PR c++/80459
* c-c++-common/opaque-vector.c (SIZEOF_MAXINT): Define.
(f): Don't test long double vectors if __SIZEOF_LONG_DOUBLE__
is not power of 2, or is more than 16 or more than SIZEOF_MAXINT.

--- gcc/testsuite/c-c++-common/opaque-vector.c.jj   2013-10-21 
09:00:50.0 +0200
+++ gcc/testsuite/c-c++-common/opaque-vector.c  2017-04-19 10:24:19.154548627 
+0200
@@ -5,6 +5,11 @@
 #define T_TEST(TYPE)
 #endif
 #define T(TYPE) B_TEST(TYPE) T_TEST(TYPE)
+#ifdef __SIZEOF_INT128__
+#define SIZEOF_MAXINT __SIZEOF_INT128__
+#else
+#define SIZEOF_MAXINT __SIZEOF_LONG_LONG__
+#endif
 
 void f ()
 {
@@ -15,8 +20,13 @@ void f ()
 
   T_TEST(float)
   T_TEST(double)
-  /* Avoid trouble with non-power-of-two sizes.  */
-#if !defined(__i386__) && !defined(__x86_64__) && !defined(__m68k__) && 
!defined(__ia64__) && !defined(__hppa__)
+  /* Avoid trouble with non-power-of-two sizes.
+ Also avoid trouble with long double larger than integral types.  */
+#if !defined(__i386__) && !defined(__x86_64__) && !defined(__m68k__) \
+&& !defined(__ia64__) && !defined(__hppa__) \
+&& (__SIZEOF_LONG_DOUBLE__ & (__SIZEOF_LONG_DOUBLE__ - 1)) == 0 \
+&& __SIZEOF_LONG_DOUBLE__ <= 16 \
+&& __SIZEOF_LONG_DOUBLE__ <= SIZEOF_MAXINT
   T_TEST(long double)
 #endif
 }

Jakub

[PATCH] Fix ICE in modified_type_die (PR debug/80461)

[Jakub Jelinek]

Hi!

On the following testcase we ICE in modified_type_die, because the
search for a non-qualified variant type with the same rvalue quals
etc. finds pretty randomly qualified type, while modified_type_die
expects that it is either an unqualified type or (if there is no such a
type) type itself.  When we are looking for const qualified FUNCTION_TYPE
and find instead volatile qualified FUNCTION_TYPE, then we die on an
assertion that we can't subtract qualifiers from the chosen type to
get to the desired type (only can add them).

The following patch makes sure we pick only the unqualified types.
Bootstrapped/regtested on x86_64-linux and i686-linux with additional
statistics collection which found that both the loops found such an
unqualified type in all cases except for a single fntype in each of the
following testcases:
libstdc++-v3/testsuite/20_util/add_lvalue_reference/value.cc
libstdc++-v3/testsuite/20_util/add_rvalue_reference/value.cc
libstdc++-v3/testsuite/20_util/is_assignable/value.cc
where we didn't find any unqualified types among the variants;
previously we found type itself that way, which is what the patched
compiler does too in that case (see the return lookup_type_die (type)
after it or that type remains the old type).

Ok for trunk?

2017-04-19  Jakub Jelinek  

PR debug/80461
* dwarf2out.c (modified_type_die, gen_type_die_with_usage):
Check for t with zero TYPE_QUALS_NO_ADDR_SPACE.

* g++.dg/debug/pr80461.C: New test.

--- gcc/dwarf2out.c.jj  2017-04-18 18:58:13.0 +0200
+++ gcc/dwarf2out.c 2017-04-19 13:05:31.109271480 +0200
@@ -12690,7 +12690,9 @@ modified_type_die (tree type, int cv_qua
 but try to canonicalize.  */
  tree main = TYPE_MAIN_VARIANT (type);
  for (tree t = main; t; t = TYPE_NEXT_VARIANT (t))
-   if (check_base_type (t, main) && check_lang_type (t, type))
+   if (TYPE_QUALS_NO_ADDR_SPACE (t) == 0
+   && check_base_type (t, main)
+   && check_lang_type (t, type))
  return lookup_type_die (t);
  return lookup_type_die (type);
}
@@ -24580,13 +24582,13 @@ gen_type_die_with_usage (tree type, dw_d
 but try to canonicalize.  */
   tree main = TYPE_MAIN_VARIANT (type);
   for (tree t = main; t; t = TYPE_NEXT_VARIANT (t))
-   {
- if (check_base_type (t, main) && check_lang_type (t, type))
-   {
- type = t;
- break;
-   }
-   }
+   if (TYPE_QUALS_NO_ADDR_SPACE (t) == 0
+   && check_base_type (t, main)
+   && check_lang_type (t, type))
+ {
+   type = t;
+   break;
+ }
 }
   else if (TREE_CODE (type) != VECTOR_TYPE
   && TREE_CODE (type) != ARRAY_TYPE)
--- gcc/testsuite/g++.dg/debug/pr80461.C.jj 2017-04-19 13:27:36.101829399 
+0200
+++ gcc/testsuite/g++.dg/debug/pr80461.C2017-04-19 13:27:46.618690922 
+0200
@@ -0,0 +1,42 @@
+// PR debug/80461
+// { dg-do compile }
+// { dg-options "-g -O" }
+
+template  class A;
+struct B
+{
+  template 
+  static bool foo (U T::*) {}
+};
+template  class J;
+template 
+class J : public J {};
+template 
+class J : public B {};
+template  struct A
+{
+  template  using K = int;
+  template , typename = K> A 
(L);
+};
+template 
+template 
+A::A (L x) { J::foo (x); }
+struct N;
+volatile int v;
+
+template 
+void
+bar ()
+{
+  O q;
+  A f = q;
+  v++;
+}
+
+void
+baz ()
+{
+  bar ();
+  bar ();
+  bar ();
+}

Jakub

Re: [PATCH] Fix -fcompare-debug bugs during updating into loop closed ssa form (PR debug/80436)

[Jeff Law]

On 04/19/2017 07:55 AM, Jakub Jelinek wrote:

Hi!

-fcompare-debug fails on the following testcase, because during loop
splitting we attempt to switch into loop closed SSA form and use
also debug stmt uses in those decisions, which is wrong.
Looking at the rest of tree-ssa-loop-manip.c, both find_uses_to_rename_stmt
and check_loop_closed_ssa_stmt ignore debug stmts, this patch just adds
that to another spot.  Without it a new SSA_NAME is created (only with -g)
and then soon (in the next pass) removed again because DCE sees it as
dead (it has no non-debug uses) and is replaced by the definition from the
loop again.

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

2017-04-19  Jakub Jelinek  

PR debug/80436
* tree-ssa-loop-manip.c (find_uses_to_rename_def): Ignore debug uses.

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

OK.
jeff

Re: [PATCH] Adjust c-c++-common/opaque-vector.c testcase (PR c++/80459)

[Jeff Law]

On 04/19/2017 08:00 AM, Jakub Jelinek wrote:

Hi!

The testcase attempts to use long double __attribute__((vector_size (16)))
vector and in addition to that uses __typeof((v

PR c++/80459
* c-c++-common/opaque-vector.c (SIZEOF_MAXINT): Define.
(f): Don't test long double vectors if __SIZEOF_LONG_DOUBLE__
is not power of 2, or is more than 16 or more than SIZEOF_MAXINT.

OK.
jeff

Re: [PATCH] doc: mention handling of {0} in -Wmissing-field-initializers (PR 71250)

[Jeff Law]

On 04/19/2017 07:12 AM, Alexander Monakov wrote:

Hi,

PR 71250 asks to explicitly document that -Wmissing-field-initializers warning
was enhanced some time ago to suppress warnings on uses of the universal zero
initializer { 0 } in C language.  The documentation already calls out that the
warning is silenced in C++ for '{ }', the patch adds the corresponding C example
just before that.

Sanity-checked with 'make info html', ok to apply?

Alexander

PR other/71250
* doc/invoke.texi (-Wmissing-field-initializers): Mention that warning
is suppressed for '{ 0 }' in C.

OK.
jeff

Re: [PATCH] Fix ICE in modified_type_die (PR debug/80461)

[Jeff Law]

On 04/19/2017 08:28 AM, Jakub Jelinek wrote:

Hi!

On the following testcase we ICE in modified_type_die, because the
search for a non-qualified variant type with the same rvalue quals
etc. finds pretty randomly qualified type, while modified_type_die
expects that it is either an unqualified type or (if there is no such a
type) type itself.  When we are looking for const qualified FUNCTION_TYPE
and find instead volatile qualified FUNCTION_TYPE, then we die on an
assertion that we can't subtract qualifiers from the chosen type to
get to the desired type (only can add them).

The following patch makes sure we pick only the unqualified types.
Bootstrapped/regtested on x86_64-linux and i686-linux with additional
statistics collection which found that both the loops found such an
unqualified type in all cases except for a single fntype in each of the
following testcases:
libstdc++-v3/testsuite/20_util/add_lvalue_reference/value.cc
libstdc++-v3/testsuite/20_util/add_rvalue_reference/value.cc
libstdc++-v3/testsuite/20_util/is_assignable/value.cc
where we didn't find any unqualified types among the variants;
previously we found type itself that way, which is what the patched
compiler does too in that case (see the return lookup_type_die (type)
after it or that type remains the old type).

Ok for trunk?

2017-04-19  Jakub Jelinek  

PR debug/80461
* dwarf2out.c (modified_type_die, gen_type_die_with_usage):
Check for t with zero TYPE_QUALS_NO_ADDR_SPACE.

* g++.dg/debug/pr80461.C: New test.
I'm going to assume your use of TYPE_QUALS_NO_ADDR_SPACE vs TYPE_QUALS 
or TYPE_QUALS_NO_ADDR_SPACE_NO_ATOMIC is correct.


OK.
jeff

Re: [patch] Fix PR tree-optimization/80426

[Eric Botcazou]

> I know this attempts to be a copy of what is used elsewhere, but
> at least there it is a result of wi::sub etc.
> Wouldn't it be simpler to
>   if (sgn == SIGNED && wi::neg_p (min_op1) && wi::neg_p (wmin))
> min_ovf = 1;
>   else if (sgn == UNSIGNED && wi::ne_p (min_op1, 0))
> min_ovf = -1;
> 
> I mean, for SIGNED if min_op1 is 0, then wmin is 0 to and we want
> min_ovf = 0;
> If it is positive, wmin will be surely negative and again we want
> min_ovf = 0.  Only if it is negative and its negation is negative
> too we want min_ovf = 1 (i.e. wi::cmps (0, most_negative) result).
> For UNSIGNED, if min_op1 is 0, again all 3 wi::cmp will yield
> 0 and min_ovf = 0.  If it is non-zero, it is > 0, therefore it
> the first wi::cmp will return -1, the second wi::cmp returns
> 1 and the third one -1.

Fine with me.

> Is that what we want (e.g. the UNSIGNED case to overflow pretty much always
> except for 0 which should be optimized away anyway)?

I think so, you'd better be very cautious with overflow and symbolic ranges.

> Or, shouldn't we just set if (!min_op0 && min_op1 && minus_p) min_op0 =
> build_int_cst (expr_type, 0); before the if (min_op0 && min_op1) case
> and don't duplicate that?

This isn't better than my version IMO.

Tested on x86_64-suse-linux, OK for mainline and 6 branch?


2017-04-19  Eric Botcazou  
Jakub Jelinek  

PR tree-optimization/80426
* tree-vrp.c (extract_range_from_binary_expr_1): For an additive
operation on symbolic operands, also compute the overflow for the
invariant part when the operation degenerates into a negation.

-- 
Eric BotcazouIndex: tree-vrp.c
===
--- tree-vrp.c	(revision 246960)
+++ tree-vrp.c	(working copy)
@@ -2461,7 +2461,20 @@ extract_range_from_binary_expr_1 (value_
 	  else if (min_op0)
 	wmin = min_op0;
 	  else if (min_op1)
-	wmin = minus_p ? wi::neg (min_op1) : min_op1;
+	{
+	  if (minus_p)
+		{
+		  wmin = wi::neg (min_op1);
+
+		  /* Check for overflow.  */
+		  if (sgn == SIGNED && wi::neg_p (min_op1) && wi::neg_p (wmin))
+		min_ovf = 1;
+		  else if (sgn == UNSIGNED && wi::ne_p (min_op1, 0))
+		min_ovf = -1;
+		}
+	  else
+		wmin = min_op1;
+	}
 	  else
 	wmin = wi::shwi (0, prec);
 
@@ -2489,7 +2502,20 @@ extract_range_from_binary_expr_1 (value_
 	  else if (max_op0)
 	wmax = max_op0;
 	  else if (max_op1)
-	wmax = minus_p ? wi::neg (max_op1) : max_op1;
+	{
+	  if (minus_p)
+		{
+		  wmax = wi::neg (max_op1);
+
+		  /* Check for overflow.  */
+		  if (sgn == SIGNED && wi::neg_p (max_op1) && wi::neg_p (wmax))
+		max_ovf = 1;
+		  else if (sgn == UNSIGNED && wi::ne_p (max_op1, 0))
+		max_ovf = -1;
+		}
+	  else
+		wmax = max_op1;
+	}
 	  else
 	wmax = wi::shwi (0, prec);
 

Re: [patch] Fix PR tree-optimization/80426

[Jakub Jelinek]

On Wed, Apr 19, 2017 at 04:59:50PM +0200, Eric Botcazou wrote:
> > I know this attempts to be a copy of what is used elsewhere, but
> > at least there it is a result of wi::sub etc.
> > Wouldn't it be simpler to
> >   if (sgn == SIGNED && wi::neg_p (min_op1) && wi::neg_p (wmin))
> > min_ovf = 1;
> >   else if (sgn == UNSIGNED && wi::ne_p (min_op1, 0))
> > min_ovf = -1;
> > 
> > I mean, for SIGNED if min_op1 is 0, then wmin is 0 to and we want
> > min_ovf = 0;
> > If it is positive, wmin will be surely negative and again we want
> > min_ovf = 0.  Only if it is negative and its negation is negative
> > too we want min_ovf = 1 (i.e. wi::cmps (0, most_negative) result).
> > For UNSIGNED, if min_op1 is 0, again all 3 wi::cmp will yield
> > 0 and min_ovf = 0.  If it is non-zero, it is > 0, therefore it
> > the first wi::cmp will return -1, the second wi::cmp returns
> > 1 and the third one -1.
> 
> Fine with me.
> 
> > Is that what we want (e.g. the UNSIGNED case to overflow pretty much always
> > except for 0 which should be optimized away anyway)?
> 
> I think so, you'd better be very cautious with overflow and symbolic ranges.
> 
> > Or, shouldn't we just set if (!min_op0 && min_op1 && minus_p) min_op0 =
> > build_int_cst (expr_type, 0); before the if (min_op0 && min_op1) case
> > and don't duplicate that?
> 
> This isn't better than my version IMO.
> 
> Tested on x86_64-suse-linux, OK for mainline and 6 branch?

Ok, thanks.

Jakub

Re: [PATCH] Fix ICE in modified_type_die (PR debug/80461)

[Jakub Jelinek]

On Wed, Apr 19, 2017 at 08:57:52AM -0600, Jeff Law wrote:
> > 2017-04-19  Jakub Jelinek  
> > 
> > PR debug/80461
> > * dwarf2out.c (modified_type_die, gen_type_die_with_usage):
> > Check for t with zero TYPE_QUALS_NO_ADDR_SPACE.
> > 
> > * g++.dg/debug/pr80461.C: New test.
> I'm going to assume your use of TYPE_QUALS_NO_ADDR_SPACE vs TYPE_QUALS or
> TYPE_QUALS_NO_ADDR_SPACE_NO_ATOMIC is correct.

I don't really know.  For address space quals I think one would need to have
pointer-to-members in different code address spaces, not sure if we support
anything like that.  And atomic is C only which doesn't have
pointer-to-members.

Jakub

Re: [PATCH] PR libstdc++/80446 cope with libc defining __has_builtin

[Jonathan Wakely]

On 19/04/17 11:49 +0100, Jonathan Wakely wrote:

Both newlib and FreeBSD have this in libc headers:

#ifndef __has_builtin
#define __has_builtin(x) 0
#endif

This means our attempts to use #ifdef __has_builtin aren't reliable,
so we need a different approach. With this patch we don't care whether
it's defined or not, only its value.

PR libstdc++/80446
* include/std/type_traits (is_aggregate): Change __has_builtin checks.
* libsupc++/new (launder): Likewise.

Tested ppc64le-linux and x86_64-freebsd11.0, committed to trunk.


Jakub pointed out I forgot to update the macro name in a comment.

Smoke-tested and committed to trunk.

commit be2fd5feb898fefac9f97ffca6691b232d18fa5b
Author: Jonathan Wakely 
Date:   Wed Apr 19 16:11:34 2017 +0100

	* libsupc++/new: Update comment on #endif directive.

diff --git a/libstdc++-v3/libsupc++/new b/libstdc++-v3/libsupc++/new
index 2de7752..04f172c 100644
--- a/libstdc++-v3/libsupc++/new
+++ b/libstdc++-v3/libsupc++/new
@@ -209,7 +209,7 @@ namespace std
   void launder(volatile void*) = delete;
   void launder(const volatile void*) = delete;
 }
-#endif // _GLIBCXX_NO_BUILTIN_LAUNDER
+#endif // _GLIBCXX_HAVE_BUILTIN_LAUNDER
 #undef _GLIBCXX_HAVE_BUILTIN_LAUNDER
 #endif // C++17
 

Re: [PATCH] Fix ICE in modified_type_die (PR debug/80461)

[Jeff Law]

On 04/19/2017 09:10 AM, Jakub Jelinek wrote:

On Wed, Apr 19, 2017 at 08:57:52AM -0600, Jeff Law wrote:

2017-04-19  Jakub Jelinek  

PR debug/80461
* dwarf2out.c (modified_type_die, gen_type_die_with_usage):
Check for t with zero TYPE_QUALS_NO_ADDR_SPACE.

* g++.dg/debug/pr80461.C: New test.

I'm going to assume your use of TYPE_QUALS_NO_ADDR_SPACE vs TYPE_QUALS or
TYPE_QUALS_NO_ADDR_SPACE_NO_ATOMIC is correct.


I don't really know.  For address space quals I think one would need to have
pointer-to-members in different code address spaces, not sure if we support
anything like that.  And atomic is C only which doesn't have
pointer-to-members.
To put it another way, in your message you indicated that 
modified_type_die expects either an unqualified type or the type itself 
and that your patch makes sure we only pick unqualified types.


Using TYPE_QUALS_NO_ADDR_SPACE like you have seems to conflict with 
those statements.  So I'm curious why you allow address space qualifiers 
to pass through, but no others.   It just seems odd.


I'm guessing you're doing that because modified_type_die ignores address 
space qualifiers (and it only conditionally ignores atomics or restrict 
based on dwarf level).  But it'd be good to get a confirmation that's 
what you were thinking.


jeff

Re: [PATCH] Fix ICE in modified_type_die (PR debug/80461)

[Jakub Jelinek]

On Wed, Apr 19, 2017 at 09:55:19AM -0600, Jeff Law wrote:
> On 04/19/2017 09:10 AM, Jakub Jelinek wrote:
> > On Wed, Apr 19, 2017 at 08:57:52AM -0600, Jeff Law wrote:
> > > > 2017-04-19  Jakub Jelinek  
> > > > 
> > > > PR debug/80461
> > > > * dwarf2out.c (modified_type_die, gen_type_die_with_usage):
> > > > Check for t with zero TYPE_QUALS_NO_ADDR_SPACE.
> > > > 
> > > > * g++.dg/debug/pr80461.C: New test.
> > > I'm going to assume your use of TYPE_QUALS_NO_ADDR_SPACE vs TYPE_QUALS or
> > > TYPE_QUALS_NO_ADDR_SPACE_NO_ATOMIC is correct.
> > 
> > I don't really know.  For address space quals I think one would need to have
> > pointer-to-members in different code address spaces, not sure if we support
> > anything like that.  And atomic is C only which doesn't have
> > pointer-to-members.
> To put it another way, in your message you indicated that modified_type_die
> expects either an unqualified type or the type itself and that your patch
> makes sure we only pick unqualified types.
> 
> Using TYPE_QUALS_NO_ADDR_SPACE like you have seems to conflict with those
> statements.  So I'm curious why you allow address space qualifiers to pass
> through, but no others.   It just seems odd.

I used TYPE_QUALS_NO_ADDR_SPACE because that seems to be used in
modified_type_die elsewhere (dwarf2out.c has only one use of TYPE_QUALS and
even that one ignores addr space bits, as it is masked with qual_mask;
the rest just TYPE_QUALS_NO_ADDR_SPACE).  I think with FUNCTION/METHOD types
with addr space quals we end up in grossly untested territory that most
likely will just not work at all.  I think we don't do anything with the
address space quals right now, in the future DWARF has segment identifiers
and something like that could be emitted, but there needs to be ABI
agreement on what it means.

Jakub

Re: [PATCH] Fix ICE in modified_type_die (PR debug/80461)

[Jeff Law]

On 04/19/2017 10:13 AM, Jakub Jelinek wrote:

On Wed, Apr 19, 2017 at 09:55:19AM -0600, Jeff Law wrote:

On 04/19/2017 09:10 AM, Jakub Jelinek wrote:

On Wed, Apr 19, 2017 at 08:57:52AM -0600, Jeff Law wrote:

2017-04-19  Jakub Jelinek  

PR debug/80461
* dwarf2out.c (modified_type_die, gen_type_die_with_usage):
Check for t with zero TYPE_QUALS_NO_ADDR_SPACE.

* g++.dg/debug/pr80461.C: New test.

I'm going to assume your use of TYPE_QUALS_NO_ADDR_SPACE vs TYPE_QUALS or
TYPE_QUALS_NO_ADDR_SPACE_NO_ATOMIC is correct.


I don't really know.  For address space quals I think one would need to have
pointer-to-members in different code address spaces, not sure if we support
anything like that.  And atomic is C only which doesn't have
pointer-to-members.

To put it another way, in your message you indicated that modified_type_die
expects either an unqualified type or the type itself and that your patch
makes sure we only pick unqualified types.

Using TYPE_QUALS_NO_ADDR_SPACE like you have seems to conflict with those
statements.  So I'm curious why you allow address space qualifiers to pass
through, but no others.   It just seems odd.


I used TYPE_QUALS_NO_ADDR_SPACE because that seems to be used in
modified_type_die elsewhere (dwarf2out.c has only one use of TYPE_QUALS and
even that one ignores addr space bits, as it is masked with qual_mask;
the rest just TYPE_QUALS_NO_ADDR_SPACE).  I think with FUNCTION/METHOD types
with addr space quals we end up in grossly untested territory that most
likely will just not work at all.  I think we don't do anything with the
address space quals right now, in the future DWARF has segment identifiers
and something like that could be emitted, but there needs to be ABI
agreement on what it means.
OK.  So let's go with your patch -- my reading of modified_type_die was 
that it would ignore address-space qualifiers.  So I think your patch is 
safe, it was the inconsistency in the message and the patch itself I was 
most concerned about.


jeff

Re: [CHKP] Fix for PR79990

[Alexander Ivchenko]

Hi,

Thanks for the comments, that was a good idea to place all the logic inside
of chkp_build_addr_expr function. I followed it and here is what I got:

gcc/testsuite/ChangeLog:

2017-04-19  Alexander Ivchenko  

* gcc.target/i386/mpx/hard-reg-2-lbv.c: New test.
* gcc.target/i386/mpx/hard-reg-2-nov.c: New test.
* gcc.target/i386/mpx/hard-reg-2-ubv.c: New test.
* gcc.target/i386/mpx/hard-reg-3-1-lbv.c: New test.
* gcc.target/i386/mpx/hard-reg-3-1-nov.c: New test.
* gcc.target/i386/mpx/hard-reg-3-1-ubv.c: New test.
* gcc.target/i386/mpx/hard-reg-3-2-lbv.c: New test.
* gcc.target/i386/mpx/hard-reg-3-2-nov.c: New test.
* gcc.target/i386/mpx/hard-reg-3-2-ubv.c: New test.
* gcc.target/i386/mpx/hard-reg-3-lbv.c: New test.
* gcc.target/i386/mpx/hard-reg-3-nov.c: New test.
* gcc.target/i386/mpx/hard-reg-3-ubv.c: New test.
* gcc.target/i386/mpx/hard-reg-4-lbv.c: New test.
* gcc.target/i386/mpx/hard-reg-4-nov.c: New test.
* gcc.target/i386/mpx/hard-reg-4-ubv.c: New test.
* gcc.target/i386/mpx/hard-reg-5-1-lbv.c: New test.
* gcc.target/i386/mpx/hard-reg-5-1-nov.c: New test.
* gcc.target/i386/mpx/hard-reg-5-1-ubv.c: New test.
* gcc.target/i386/mpx/hard-reg-5-2-lbv.c: New test.
* gcc.target/i386/mpx/hard-reg-5-2-nov.c: New test.
* gcc.target/i386/mpx/hard-reg-5-2-ubv.c: New test.

gcc/ChangeLog:

2017-04-19  Alexander Ivchenko  

* tree-chkp.c (chkp_get_hard_register_var_fake_base_address):
New function to provide a base address for.
chkp_get_hard_register_fake_addr_expr
(chkp_get_hard_register_fake_addr_expr): New function to build
fake address expression for an expr that resides on a hard
register.
(chkp_build_addr_expr): Add checks for hard reg cases.
(chkp_parse_array_and_component_ref): Create/find bounds if the
var resides on a hard reg.
(chkp_find_bounds_1): Check for hard register cases.





And the patch itself:

diff --git a/gcc/testsuite/gcc.target/i386/mpx/hard-reg-2-lbv.c
b/gcc/testsuite/gcc.target/i386/mpx/hard-reg-2-lbv.c
new file mode 100644
index 000..319e1ec
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/mpx/hard-reg-2-lbv.c
@@ -0,0 +1,21 @@
+/* { dg-do run } */
+/* { dg-shouldfail "bounds violation" } */
+/* { dg-options "-fcheck-pointer-bounds -mmpx" } */
+
+
+#define SHOULDFAIL
+
+#include "mpx-check.h"
+
+typedef int v16 __attribute__((vector_size(16)));
+
+int foo(int i) {
+  register v16 u asm("xmm0");
+  return u[i];
+}
+
+int mpx_test (int argc, const char **argv)
+{
+  printf ("%d\n", foo (-1));
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.target/i386/mpx/hard-reg-2-nov.c
b/gcc/testsuite/gcc.target/i386/mpx/hard-reg-2-nov.c
new file mode 100644
index 000..3c6d39a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/mpx/hard-reg-2-nov.c
@@ -0,0 +1,18 @@
+/* { dg-do run } */
+/* { dg-options "-fcheck-pointer-bounds -mmpx" } */
+
+#include "mpx-check.h"
+
+typedef int v16 __attribute__((vector_size(16)));
+
+int foo (int i) {
+  register v16 u asm ("xmm0");
+  return u[i];
+}
+
+int mpx_test (int argc, const char **argv)
+{
+  printf ("%d\n", foo (3));
+  printf ("%d\n", foo (0));
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.target/i386/mpx/hard-reg-2-ubv.c
b/gcc/testsuite/gcc.target/i386/mpx/hard-reg-2-ubv.c
new file mode 100644
index 000..7fe76c4
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/mpx/hard-reg-2-ubv.c
@@ -0,0 +1,21 @@
+/* { dg-do run } */
+/* { dg-shouldfail "bounds violation" } */
+/* { dg-options "-fcheck-pointer-bounds -mmpx" } */
+
+
+#define SHOULDFAIL
+
+#include "mpx-check.h"
+
+typedef int v16 __attribute__((vector_size(16)));
+
+int foo (int i) {
+  register v16 u asm ("xmm0");
+  return u[i];
+}
+
+int mpx_test (int argc, const char **argv)
+{
+  printf ("%d\n", foo (5));
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.target/i386/mpx/hard-reg-3-1-lbv.c
b/gcc/testsuite/gcc.target/i386/mpx/hard-reg-3-1-lbv.c
new file mode 100644
index 000..7e4451f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/mpx/hard-reg-3-1-lbv.c
@@ -0,0 +1,33 @@
+/* { dg-do run } */
+/* { dg-shouldfail "bounds violation" } */
+/* { dg-options "-fcheck-pointer-bounds -mmpx" } */
+
+
+#define SHOULDFAIL
+
+#include "mpx-check.h"
+
+typedef int v8 __attribute__ ((vector_size (8)));
+
+struct S1
+{
+  v8 s1f;
+};
+
+struct S2
+{
+  struct S1 s2f1;
+  v8 s2f2;
+};
+
+int foo_s2f1 (int i)
+{
+  register struct S2 b asm ("xmm0");
+  return b.s2f1.s1f[i];
+}
+
+int mpx_test (int argc, const char **argv)
+{
+  printf ("%d\n", foo_s2f1 (-1));
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.target/i386/mpx/hard-reg-3-1-nov.c
b/gcc/testsuite/gcc.target/i386/mpx/hard-reg-3-1-nov.c
new file mode 100644
index 000..73bd7fb
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/mpx/hard-reg-3-1-nov.c
@@ -0,0 +1,30 @@
+/* { dg-do run } */
+/* { dg-options "-fcheck-pointer-bounds -mmpx" } */
+

Re: [libstdc++] Adjust to the new location of the C++ ABI

[Jonathan Wakely]

On 12/04/17 08:37 +1000, Gerald Pfeifer wrote:

On Thu, 30 Mar 2017, Gerald Pfeifer wrote:

(Jonathan, I'm going to take care of the libstdc++/doc links as
well in case you wonder.)


Done thusly.

Jonathan, do you think one of the three references in
doc/xml/manual/abi.xml could be avoided?  That'll make it easier
next time this document moves. :-}


Well, they go to three different places (or did, before your change).

One link was the the ABI spec, one is to a specific section of the
spec, and one is a bibliography entry linking to the homepage of the
project. I've changed the first one to link to the bibliography entry,
so there are only two now, but I don't think it's am improvement
really. When you click on the link it jumps to the bottom of the
page, but not necessarily to the actual anchor (because it's too near
the bottom of the page).

I certainly don't think we should remove the second one. I
don't want to have a hypertext document that says "see section N of
[biblio.cxxabi]" rather than just hyperlinking directly to it.


(Also, if you could regenerate and upload the docs?)


Sure.

Committed to trunk.


commit ed7eeb361974a8c64803b617bd760612060cc3ab
Author: Jonathan Wakely 
Date:   Wed Apr 19 17:45:42 2017 +0100

Rationalise ABI links in libstdc++ manual

	* doc/xml/manual/abi.xml: Rephrase one of the references to the
	Itanium C++ ABI.
	* doc/xml/manual/test.xml: Document DejaGnu 1.5.3 requirement.
	* doc/html/*: Regenerate.

diff --git a/libstdc++-v3/doc/xml/manual/abi.xml b/libstdc++-v3/doc/xml/manual/abi.xml
index 0e56068..1c816b1 100644
--- a/libstdc++-v3/doc/xml/manual/abi.xml
+++ b/libstdc++-v3/doc/xml/manual/abi.xml
@@ -40,10 +40,9 @@
   alignment and in a particular layout, mangling names according to a
   well-defined algorithm, has specific arrangements for the support of
   virtual functions, etc. These details are defined as the compiler
-  Application Binary Interface, or ABI. The GNU C++ compiler uses an
-  industry-standard C++ ABI starting with version 3. Details can be
-  found in the http://www.w3.org/1999/xlink"; xlink:href="https://itanium-cxx-abi.github.io/cxx-abi/";>ABI
-  specification.
+  Application Binary Interface, or ABI. From GCC version 3 onwards the
+  GNU C++ compiler uses an industry-standard C++ ABI, the
+  Itanium C++ ABI.
 
 
 
@@ -1116,7 +1115,7 @@ gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.
   
 	http://www.w3.org/1999/xlink";
 	  xlink:href="https://itanium-cxx-abi.github.io/cxx-abi/";>
-	  C++ ABI Summary
+	  Itanium C++ ABI
 	
   
 
diff --git a/libstdc++-v3/doc/xml/manual/test.xml b/libstdc++-v3/doc/xml/manual/test.xml
index 8ae88b3..7cb7daf 100644
--- a/libstdc++-v3/doc/xml/manual/test.xml
+++ b/libstdc++-v3/doc/xml/manual/test.xml
@@ -563,8 +563,11 @@ cat 27_io/objects/char/3_xin.in | a.out
   the CXXFLAGS variable when running
   make, or via options for the DejaGnu test framework
   (described below). The latter approach uses the
-  --target_board option that was shown earlier.
-  For example, to run the tests with -O1 -D_GLIBCXX_ASSERTIONS
+  --target_board option that was shown earlier,
+  but requires DejaGnu version 1.5.3 or newer to work reliably, so that the
+  dg-options in the test aren't overridden.
+  For example, to run the tests with
+  -O1 -D_GLIBCXX_ASSERTIONS
   you could use:
 make RUNTESTFLAGS=--target_board=unix/-O1/-D_GLIBCXX_ASSERTIONS
 

[PATCH] Implement C++17 changes to std::atomic (P0558R1 partial)

[Jonathan Wakely]

This implements the significant changes from P0558R1 for C++17, adding
nested typedefs and making it ill-formed to do arithmetic on
std::atomic if !is_object::value.

We currently support such arithmetic for std::atomic, and even
have a test checking it, so I've only made it ill-formed for C++17
mode. I'd like to deprecate that extension for GCC 8 and make it
ill-formed in all modes at some point. PR 69769 points out that we
also allow that arithmetic for pointers to functions, which is just
crazy.

The unimplemented parts of the paper are changing the non-member
functions to use the new std::atomic::value_type and
std::atomic::difference_type types for the parameters, so they are
non-deduced contexts. That would be too big a change to make now, so
we can revisit that for GCC 8 too.

PR libstdc++/69769
* include/bits/atomic_base.h (__atomic_base): Add new typedefs for
C++17.
* include/std/atomic (atomic, atomic, atomic): Likewise.
(atomic::operator++, atomic::operator--)
(atomic::operator+=, atomic::operator-=)
(atomic::fetch_add, atomic::fetch_sub): Add static assertion
to enforce C++17 requirement on pointer arithmetic.
* testsuite/29_atomics/atomic/60695.cc: Adjust dg-error lineno.
* testsuite/29_atomics/atomic/69769.cc: New test.
* testsuite/29_atomics/atomic/operators/pointer_partial_void.cc:
Disable test for C++17.
* testsuite/29_atomics/atomic/requirements/typedefs.cc: New test.
* testsuite/29_atomics/atomic_integral/requirements/typedefs.cc: New
test.

Tested powerpc64le-linux, with all -std=gnu++?? options.

I plan to commit this tomorrow.

commit 8b28c80f1c250d87d8a30a99a2f190f2e17a8981
Author: Jonathan Wakely 
Date:   Wed Apr 19 16:30:18 2017 +0100

Implement C++17 changes to std::atomic (P0558R1 partial)

PR libstdc++/69769
* include/bits/atomic_base.h (__atomic_base): Add new typedefs for
C++17.
* include/std/atomic (atomic, atomic, atomic): Likewise.
(atomic::operator++, atomic::operator--)
(atomic::operator+=, atomic::operator-=)
(atomic::fetch_add, atomic::fetch_sub): Add static assertion
to enforce C++17 requirement on pointer arithmetic.
* testsuite/29_atomics/atomic/60695.cc: Adjust dg-error lineno.
* testsuite/29_atomics/atomic/69769.cc: New test.
* testsuite/29_atomics/atomic/operators/pointer_partial_void.cc:
Disable test for C++17.
* testsuite/29_atomics/atomic/requirements/typedefs.cc: New test.
* testsuite/29_atomics/atomic_integral/requirements/typedefs.cc: New
test.

diff --git a/libstdc++-v3/include/bits/atomic_base.h 
b/libstdc++-v3/include/bits/atomic_base.h
index e79ff67..93f85c3 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -237,6 +237,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 struct __atomic_base
 {
+#if __cplusplus > 201402L
+  using value_type = _ITp;
+  using difference_type = value_type;
+#endif
+
 private:
   typedef _ITp __int_type;
 
diff --git a/libstdc++-v3/include/std/atomic b/libstdc++-v3/include/std/atomic
index 5b252a4..47d3004 100644
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -62,6 +62,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template<>
   struct atomic
   {
+#if __cplusplus > 201402L
+using value_type = bool;
+#endif
+
   private:
 __atomic_base_M_base;
 
@@ -173,6 +177,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 struct atomic
 {
+#if __cplusplus > 201402L
+  using value_type = _Tp;
+#endif
+
 private:
   // Align 1/2/4/8/16-byte types to at least their size.
   static constexpr int _S_min_alignment
@@ -351,6 +359,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 struct atomic<_Tp*>
 {
+#if __cplusplus > 201402L
+  using value_type = _Tp*;
+  using difference_type = ptrdiff_t;
+#endif
+
   typedef _Tp* __pointer_type;
   typedef __atomic_base<_Tp*>  __base_type;
   __base_type  _M_b;
@@ -379,51 +392,111 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   __pointer_type
   operator++(int) noexcept
-  { return _M_b++; }
+  {
+#if __cplusplus > 201402L
+   static_assert( is_object<_Tp>::value, "pointer to object type" );
+#endif
+   return _M_b++;
+  }
 
   __pointer_type
   operator++(int) volatile noexcept
-  { return _M_b++; }
+  {
+#if __cplusplus > 201402L
+   static_assert( is_object<_Tp>::value, "pointer to object type" );
+#endif
+   return _M_b++;
+  }
 
   __pointer_type
   operator--(int) noexcept
-  { return _M_b--; }
+  {
+#if __cplusplus > 201402L
+   static_assert( is_object<_Tp>::value, "pointer to object type" );
+#endif
+   return _M_b--;
+  }
 
   __pointer_type
   operat

[gomp4] add support for allocatable scalars in OpenACC declare constructs

[Cesar Philippidis]

I've applied this patch to gomp-4_0-branch to add support for fortran
allocatable scalars inside OpenACC declare constructs. In order to
update the declared variable on the device, the fortran FE now uses the
GOMP_MAP_ALWAYS_POINTERS for declared allocatable scalars. That
necessitated some minor tweaking in the runtime. Note that I didn't add
support for allocatable derived types in this patch as the OpenACC 2.5
spec is still unclear on them.

Included in this patch is a bug fix for non-declared allocatable
scalars. Specifically, prior to this patch, the gimplifier would treat
allocatable scalar variables like C pointers, so only the pointer would
be updated on the accelerator and not the value being pointed to. If the
user explicitly specified a data clause for the variable, the fortran FE
itself would generate code to copy the value being pointed to along with
the pointer itself. I.e. this bug only affects implicit firstprivate
allocatable scalar variables. To resolve this issue, this patch teaches
lower_omp_target to pass the value being pointed to by a
GOMP_MAP_FIRSTPRIVATE_INT data mapping instead of the pointer itself to
the accelerator, then on entry to the offloaded region, lower_omp_target
will create a local copy of the pointed to value on target and along
with a local pointer to it.

Cesar
2017-04-19  Cesar Philippidis  

	gcc/fortran/
	* trans-decl.c (add_clause): Populate sym->backend_decl so that it
	can be used to determine if two symbols are unique.
	* trans-openmp.c (gfc_trans_oacc_executable_directive): Use
	GOMP_MAP_ALWAYS_POINTER for fortran allocatable pointers.
	* trans-stmt.c (gfc_trans_allocate): Call
	gfc_trans_oacc_declare_allocate for declared allocatable pointers.
	(gfc_trans_deallocate): Likewise.

	gcc/
	* omp-low.c (convert_to_firstprivate_int): Handle pointer types.
	(convert_from_firstprivate_int): Likewise.  Create local storage for
	the values being pointed too.  Add new argument orig_type.
	(lower_omp_target): Allow pointer types with GOMP_MAP_FIRSTPRIVATE_INT.

	gcc/testsuite/
	* gfortran.dg/goacc/declare-allocatable-1.f90: Update test case to
	exercise allocatable scalars.

	libgomp/
	* oacc-parallel.c (GOACC_enter_exit_data): Add support for
	GOMP_MAP_DECLARE_{ALLOCATE,DEALLOCATE}.
	(GOACC_update): Add support for GOMP_MAP_ALWAYS_POINTER.
	* testsuite/libgomp.oacc-fortran/allocatable-scalar.f90: New test.
	* testsuite/libgomp.oacc-fortran/declare-allocatable-2.f90: New test.
	* testsuite/libgomp.oacc-fortran/declare-allocatable-3.f90: New test.
	* testsuite/libgomp.oacc-fortran/declare-allocatable-4.f90: New test.


diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index b4db6b0..c0efc1a 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -5935,6 +5935,9 @@ add_clause (gfc_symbol *sym, gfc_omp_map_op map_op)
   if (!module_oacc_clauses)
 module_oacc_clauses = gfc_get_omp_clauses ();
 
+  if (sym->backend_decl == NULL)
+gfc_get_symbol_decl (sym);
+
   for (n = module_oacc_clauses->lists[OMP_LIST_MAP]; n != NULL; n = n->next)
 if (n->sym->backend_decl == sym->backend_decl)
   return;
diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
index 238eebe..3718da2 100644
--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -3336,6 +3336,18 @@ gfc_trans_oacc_executable_directive (gfc_code *code)
   gfc_start_block (&block);
   oacc_clauses = gfc_trans_omp_clauses (&block, code->ext.omp_clauses,
 	code->loc);
+
+  /* Promote GOMP_MAP_FIRSTPRIVATE_POINTER to GOMP_MAP_ALWAYS_POINTER for
+ variables inside OpenACC update directives.  */
+  if (code->op == EXEC_OACC_UPDATE)
+for (tree c = oacc_clauses; c; c = OMP_CLAUSE_CHAIN (c))
+  {
+if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP
+	&& OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_FIRSTPRIVATE_POINTER)
+	  OMP_CLAUSE_SET_MAP_KIND (c, GOMP_MAP_ALWAYS_POINTER);
+  }
+
+
   stmt = build1_loc (input_location, construct_code, void_type_node,
 		 oacc_clauses);
   gfc_add_expr_to_block (&block, stmt);
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index dcf17694..faf19e6 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -5883,6 +5883,10 @@ gfc_trans_allocate (gfc_code * code)
 	  tmp = gfc_nullify_alloc_comp (expr->ts.u.derived, tmp, 0);
 	  gfc_add_expr_to_block (&se.pre, tmp);
 	}
+
+	  /* Allocate memory for OpenACC declared variables.  */
+	  if (expr->symtree->n.sym->attr.oacc_declare_create)
+	gfc_trans_oacc_declare_allocate (&se.pre, expr, true);
 	}
   else
 	{
@@ -6360,6 +6364,10 @@ gfc_trans_deallocate (gfc_code *code)
 	}
   else
 	{
+	  /* Deallocate memory for OpenACC declared variables.  */
+	  if (expr->symtree->n.sym->attr.oacc_declare_create)
+	gfc_trans_oacc_declare_allocate (&se.pre, expr, false);
+
 	  tmp = gfc_deallocate_scalar_with_status (se.expr, pstat, false,
 		   al->expr, al->expr->ts);
 	  gfc_add_expr_to_block (&se.pre, tmp);
diff -

Re: [PATCH] PR80101: Fix ICE in store_data_bypass_p

[Segher Boessenkool]

On Tue, Apr 18, 2017 at 10:01:02PM +0200, Eric Botcazou wrote:
> > There are workarounds to this problem as well: mips_store_data_bypass_p,
> > added in 2006.  mep_store_data_bypass_p, added in 2009 (the port has
> > been removed since then, of course).
> 
> I see, no strong opinion then, but individual back-ends should be preferably 
> fixed if this is easily doable instead of changing the middle-end, which may 
> affect the other ~50 back-ends.

Okay, for GCC 7 we'll change the backend.  Maybe for GCC 8 we can
revisit this.

Thanks,


Segher

Re: [patch] Fix PR tree-optimization/80426

[Jeff Law]

On 04/19/2017 08:59 AM, Eric Botcazou wrote:

I know this attempts to be a copy of what is used elsewhere, but
at least there it is a result of wi::sub etc.
Wouldn't it be simpler to
   if (sgn == SIGNED && wi::neg_p (min_op1) && wi::neg_p (wmin))
 min_ovf = 1;
   else if (sgn == UNSIGNED && wi::ne_p (min_op1, 0))
 min_ovf = -1;

I mean, for SIGNED if min_op1 is 0, then wmin is 0 to and we want
min_ovf = 0;
If it is positive, wmin will be surely negative and again we want
min_ovf = 0.  Only if it is negative and its negation is negative
too we want min_ovf = 1 (i.e. wi::cmps (0, most_negative) result).
For UNSIGNED, if min_op1 is 0, again all 3 wi::cmp will yield
0 and min_ovf = 0.  If it is non-zero, it is > 0, therefore it
the first wi::cmp will return -1, the second wi::cmp returns
1 and the third one -1.


Fine with me.


Is that what we want (e.g. the UNSIGNED case to overflow pretty much always
except for 0 which should be optimized away anyway)?


I think so, you'd better be very cautious with overflow and symbolic ranges.


Or, shouldn't we just set if (!min_op0 && min_op1 && minus_p) min_op0 =
build_int_cst (expr_type, 0); before the if (min_op0 && min_op1) case
and don't duplicate that?


This isn't better than my version IMO.

Tested on x86_64-suse-linux, OK for mainline and 6 branch?


2017-04-19  Eric Botcazou  
 Jakub Jelinek  

 PR tree-optimization/80426
 * tree-vrp.c (extract_range_from_binary_expr_1): For an additive
 operation on symbolic operands, also compute the overflow for the
 invariant part when the operation degenerates into a negation.

Jakub ACKd and I'm going to go ahead and install.  I'll pull the 
testsuite bits from a prior version.


Thanks,
Jeff

Re: [PATCH GCC8][33/33]Fix PR69710/PR68030 by reassociate vect base address and a simple CSE pass

[Michael Meissner]

On Wed, Apr 19, 2017 at 02:08:49PM +0100, Bin.Cheng wrote:
> Hi Michael,
> Thanks for testing it.  Could you have a check if updated patch
> resolves the ICE?
> As for sms-*.c tests, I had difficulty in reproducing it.  Both trunk
> and patched GCC have the same behavior with my local ppc cross
> toolchain, sms-1.c fails and sms-4.c succeeds.

I backed out the original patch #33, and replaced it with the one you sent me,
and it does allow dealII to be built.  I rebuilt all 30 benchmarks in Spec
2006, and now they all build.

I ran a full spec 2006 suite on a little endian power8 that we normally use to
run Spec.  Note, I use different options to build spec that the people that do
the official runs, so the results are in no way official results.  I'm only
providing the differences, and not the spec numbers.

Generally, I consider differences between runs that were less than 2% to be in
the noise level.  There were only two benchmarks that had differences more than
2%:

 * 456.hmmer had an 8% regression
 * 434.zeusmp had a 3% speedup.

In terms of smaller differences, the following had 1% differences:

 * 410.bwaves had a 1% regression
 * 459.GemsFDTD had a 1% regression
 * 437.leslie3d had a 1% speedup
 * 453.povray had a 1.6% speedup

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


2017-04-19-ivopts-64bit.out.bz2
Description: BZip2 compressed data

Re: [PATCH GCC8][33/33]Fix PR69710/PR68030 by reassociate vect base address and a simple CSE pass

[Bin.Cheng]

On Wed, Apr 19, 2017 at 9:33 PM, Michael Meissner
 wrote:
> On Wed, Apr 19, 2017 at 02:08:49PM +0100, Bin.Cheng wrote:
>> Hi Michael,
>> Thanks for testing it.  Could you have a check if updated patch
>> resolves the ICE?
>> As for sms-*.c tests, I had difficulty in reproducing it.  Both trunk
>> and patched GCC have the same behavior with my local ppc cross
>> toolchain, sms-1.c fails and sms-4.c succeeds.
>
> I backed out the original patch #33, and replaced it with the one you sent me,
> and it does allow dealII to be built.  I rebuilt all 30 benchmarks in Spec
> 2006, and now they all build.
>
> I ran a full spec 2006 suite on a little endian power8 that we normally use to
> run Spec.  Note, I use different options to build spec that the people that do
> the official runs, so the results are in no way official results.  I'm only
> providing the differences, and not the spec numbers.
>
Thanks very much for testing.

> Generally, I consider differences between runs that were less than 2% to be in
> the noise level.  There were only two benchmarks that had differences more 
> than
> 2%:
>
>  * 456.hmmer had an 8% regression
I will have a look.

>  * 434.zeusmp had a 3% speedup.
This one is expected, also saw this on other targets.

Thanks,
bin
>
> In terms of smaller differences, the following had 1% differences:
>
>  * 410.bwaves had a 1% regression
>  * 459.GemsFDTD had a 1% regression
>  * 437.leslie3d had a 1% speedup
>  * 453.povray had a 1.6% speedup
>
> --
> Michael Meissner, IBM
> IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
> email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

[Patch, testsuite] Skip pr80170.c for non-ptr32plus targets

[Senthil Kumar Selvaraj]

Hi,

  The below patch skips gcc.dg/pr80170.c for targets with pointer size
  less than 32. The testcase uses pointer offsets that are 32 bit or
  higher, and this ends up triggering an ICE because a ptrofftype_p
  assert fires for non-ptr32 plus targets.

  Committed as obvious.

Regards
Senthil

gcc/testsuite/ChangeLog

2017-04-19  Senthil Kumar Selvaraj  

* gcc.dg/pr80170.c: Require ptr32plus.


Index: gcc.dg/pr80170.c
===
--- gcc.dg/pr80170.c(revision 247010)
+++ gcc.dg/pr80170.c(working copy)
@@ -1,5 +1,6 @@
 /* { dg-do run } */
 /* { dg-options "-fgimple -O2 -ftree-slp-vectorize" } */
+/* { dg-require-effective-target ptr32plus } *
 
 struct  A
 {

Re: [PATCH] Fix TYPE_TYPELESS_STORAGE handling (PR middle-end/80423)

[Jakub Jelinek]

On Wed, Apr 19, 2017 at 08:22:23AM +0200, Jakub Jelinek wrote:
> Here in (so far untested) patch form:
> 
> 2017-04-19  Jakub Jelinek  
> 
>   PR middle-end/80423
>   * tree.h (build_array_type): Add typeless_storage default argument.
>   * tree.c (type_cache_hasher::equal): Also compare
>   TYPE_TYPELESS_STORAGE flag for ARRAY_TYPEs.
>   (build_array_type): Add typeless_storage argument, set
>   TYPE_TYPELESS_STORAGE to it, if shared also hash it, and pass to
>   recursive call.
>   (build_nonshared_array_type): Adjust build_array_type_1 caller.
>   (build_array_type): Likewise.  Add typeless_storage argument.
> c-family/
>   * c-common.c (complete_array_type): Preserve TYPE_TYPELESS_STORAGE.
> cp/
>   * tree.c (build_cplus_array_type): Call build_array_type
>   with the intended TYPE_TYPELESS_STORAGE flag value, instead
>   of calling build_array_type and modifying later TYPE_TYPELESS_STORAGE
>   on the shared type.
> testsuite/
>   * g++.dg/other/pr80423.C: New test.

Just for completeness, it bootstrapped/regtested successfully on x86_64-linux
and i686-linux.

Jakub