Re: [wwwdocs, PATCH v2] C++ terminology: the One Definition Rule in diagnostics

[Gerald Pfeifer]

On Thu, 6 Apr 2017, David Malcolm wrote:
> OK to commit?

If that's what the standard uses, yes, thanks.  (We still may
want to add "C++" in there, unless you feel the context is always
clear enough anyway, which I could well see...)

Gerald

[PATCH] Fix PR80344

[Richard Biener]

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

Richard.

2017-04-10  Richard Biener  

PR middle-end/80344
* gimplify.c (is_gimple_mem_rhs_or_call): Allow CLOBBERs.

Index: gcc/gimplify.c
===
--- gcc/gimplify.c  (revision 246757)
+++ gcc/gimplify.c  (working copy)
@@ -493,7 +493,9 @@ is_gimple_mem_rhs_or_call (tree t)
   if (is_gimple_reg_type (TREE_TYPE (t)))
 return is_gimple_val (t);
   else
-return (is_gimple_val (t) || is_gimple_lvalue (t)
+return (is_gimple_val (t)
+   || is_gimple_lvalue (t)
+   || TREE_CLOBBER_P (t)
|| TREE_CODE (t) == CALL_EXPR);
 }
 

[PATCH] Fix PR80362

[Richard Biener]

I am testing the following.

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

Richard.

2017-04-10  Richard Biener  

PR middle-end/80362
* fold-const.c (fold_binary_loc): Look at unstripped ops when
looking for NEGATE_EXPR in -A / -B to A / B folding.

* gcc.dg/torture/pr80362.c: New testcase.

Index: gcc/fold-const.c
===
*** gcc/fold-const.c(revision 246797)
--- gcc/fold-const.c(working copy)
*** fold_binary_loc (location_t loc,
*** 10205,10211 
/* Convert -A / -B to A / B when the type is signed and overflow is
 undefined.  */
if ((!INTEGRAL_TYPE_P (type) || TYPE_OVERFLOW_UNDEFINED (type))
! && TREE_CODE (arg0) == NEGATE_EXPR
  && negate_expr_p (op1))
{
  if (INTEGRAL_TYPE_P (type))
--- 10205,10211 
/* Convert -A / -B to A / B when the type is signed and overflow is
 undefined.  */
if ((!INTEGRAL_TYPE_P (type) || TYPE_OVERFLOW_UNDEFINED (type))
! && TREE_CODE (op0) == NEGATE_EXPR
  && negate_expr_p (op1))
{
  if (INTEGRAL_TYPE_P (type))
Index: gcc/testsuite/gcc.dg/torture/pr80362.c
===
*** gcc/testsuite/gcc.dg/torture/pr80362.c  (nonexistent)
--- gcc/testsuite/gcc.dg/torture/pr80362.c  (working copy)
***
*** 0 
--- 1,10 
+ /* { dg-do run } */
+ /* { dg-additional-options "-fstrict-overflow" } */
+ 
+ int main()
+ {
+   signed char var_0, var_1 = -128;
+   var_0 = (signed char)(-var_1) / 3;
+   if (var_0 > 0)
+ __builtin_abort();
+ }

[PATCH] Fix PR80304

[Richard Biener]

The following fixes a fortran testcase involving safelen where
store motion needs to be disabled for unanalyzable refs (we don't
know how to transform them).  But the safelen case missed to recurse
(because that's only necessary for unanalyzable mems).

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

I'll try to come up with a testcase later.

Richard.

2017-04-10  Richard Biener  

PR tree-optimization/80304
* tree-ssa-loop-im.c (ref_indep_loop_p_1): Also recurse
for safelen.

Index: gcc/tree-ssa-loop-im.c
===
--- gcc/tree-ssa-loop-im.c  (revision 246797)
+++ gcc/tree-ssa-loop-im.c  (working copy)
@@ -2145,9 +2145,21 @@ ref_indep_loop_p_1 (int safelen, struct
  fprintf (dump_file, "\n");
}
 
+  /* We need to recurse to properly handle UNANALYZABLE_MEM_ID.  */
+  struct loop *inner = loop->inner;
+  while (inner)
+   {
+ if (!ref_indep_loop_p_1 (safelen, inner, ref, stored_p, ref_loop))
+   {
+ indep_p = false;
+ break;
+   }
+ inner = inner->next;
+   }
+
   /* Avoid caching here as safelen depends on context and refs
  are shared between different contexts.  */
-  return true;
+  return indep_p;
 }
   else
 {

Re: [PATCH] S/390: Optimize atomic_compare_exchange and atomic_compare builtins.

[Dominik Vogt]

On Fri, Apr 07, 2017 at 07:22:23PM +0200, Ulrich Weigand wrote:
> Dominik Vogt wrote:
> > On Fri, Apr 07, 2017 at 04:34:44PM +0200, Ulrich Weigand wrote:
> > > > +; Peephole to combine a load-and-test from volatile memory which 
> > > > combine does
> > > > +; not do.
> > > > +(define_peephole2
> > > > +  [(set (match_operand:GPR 0 "register_operand")
> > > > +   (match_operand:GPR 2 "memory_operand"))
> > > > +   (set (reg CC_REGNUM)
> > > > +   (compare (match_dup 0) (match_operand:GPR 1 "const0_operand")))]
> > > > +  "s390_match_ccmode(insn, CCSmode) && TARGET_EXTIMM
> > > > +   && GENERAL_REG_P (operands[0])
> > > > +   && satisfies_constraint_T (operands[2])"
> > > > +  [(parallel
> > > > +[(set (reg:CCS CC_REGNUM)
> > > > + (compare:CCS (match_dup 2) (match_dup 1)))
> > > > + (set (match_dup 0) (match_dup 2))])])
> > > 
> > > Still wondering why this is necessary.
> > 
> > It's necessary vecause Combine refuses to match anything that
> > contains a volatile memory reference, using a global flag for
> > Recog.
> 
> So is this specifically to match the pre-test load emitted here?
> 
> +  emit_move_insn (output, mem);
> +  emit_insn (gen_rtx_SET (cc, gen_rtx_COMPARE (CCZmode, output, cmp)));
> 
> If so, since you already know that this should always map to a
> LOAD AND TEST, could simply just emit the LT pattern here,
> instead of relying on combine to do it ...

Well, only if the value to compare to is constant zero (which is
what Glibc does).  In all other cases this won't result in
load-and-test.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: [PATCH] Fix PR80304

[Richard Biener]

On Mon, 10 Apr 2017, Richard Biener wrote:

> 
> The following fixes a fortran testcase involving safelen where
> store motion needs to be disabled for unanalyzable refs (we don't
> know how to transform them).  But the safelen case missed to recurse
> (because that's only necessary for unanalyzable mems).
> 
> Bootstrap / regtest on x86_64-unknown-linux-gnu.
> 
> I'll try to come up with a testcase later.

Like this.

Richard.

2017-04-10  Richard Biener  

PR tree-optimization/80304
* tree-ssa-loop-im.c (ref_indep_loop_p_1): Also recurse
for safelen.

* gcc.dg/torture/pr80304.c: New testcase.

Index: gcc/tree-ssa-loop-im.c
===
--- gcc/tree-ssa-loop-im.c  (revision 246797)
+++ gcc/tree-ssa-loop-im.c  (working copy)
@@ -2145,9 +2145,21 @@ ref_indep_loop_p_1 (int safelen, struct
  fprintf (dump_file, "\n");
}
 
+  /* We need to recurse to properly handle UNANALYZABLE_MEM_ID.  */
+  struct loop *inner = loop->inner;
+  while (inner)
+   {
+ if (!ref_indep_loop_p_1 (safelen, inner, ref, stored_p, ref_loop))
+   {
+ indep_p = false;
+ break;
+   }
+ inner = inner->next;
+   }
+
   /* Avoid caching here as safelen depends on context and refs
  are shared between different contexts.  */
-  return true;
+  return indep_p;
 }
   else
 {
Index: gcc/testsuite/gcc.dg/torture/pr80304.c
===
--- gcc/testsuite/gcc.dg/torture/pr80304.c  (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr80304.c  (working copy)
@@ -0,0 +1,27 @@
+/* { dg-do run } */
+
+int __attribute__((pure,noinline,noclone)) foo (int *p)
+{
+  return *p * 2;
+}
+
+int main()
+{
+  int k = 0;
+  int i;
+#pragma GCC ivdep
+  for (k = 0; k < 9;)
+{
+  i = 0;
+  while (1)
+   {
+ k += foo (&i);
+ if (k > 7)
+   break;
+ i++;
+   }
+}
+  if (k != 12)
+__builtin_abort ();
+  return 0;
+}

Re: [PATCH] S/390: Optimize atomic_compare_exchange and atomic_compare builtins.

[Dominik Vogt]

On Mon, Apr 10, 2017 at 10:13:01AM +0100, Dominik Vogt wrote:
> On Fri, Apr 07, 2017 at 07:22:23PM +0200, Ulrich Weigand wrote:
> > Dominik Vogt wrote:
> > > On Fri, Apr 07, 2017 at 04:34:44PM +0200, Ulrich Weigand wrote:
> > > > > +; Peephole to combine a load-and-test from volatile memory which 
> > > > > combine does
> > > > > +; not do.
> > > > > +(define_peephole2
> > > > > +  [(set (match_operand:GPR 0 "register_operand")
> > > > > + (match_operand:GPR 2 "memory_operand"))
> > > > > +   (set (reg CC_REGNUM)
> > > > > + (compare (match_dup 0) (match_operand:GPR 1 "const0_operand")))]
> > > > > +  "s390_match_ccmode(insn, CCSmode) && TARGET_EXTIMM
> > > > > +   && GENERAL_REG_P (operands[0])
> > > > > +   && satisfies_constraint_T (operands[2])"
> > > > > +  [(parallel
> > > > > +[(set (reg:CCS CC_REGNUM)
> > > > > +   (compare:CCS (match_dup 2) (match_dup 1)))
> > > > > + (set (match_dup 0) (match_dup 2))])])
> > > > 
> > > > Still wondering why this is necessary.
> > > 
> > > It's necessary vecause Combine refuses to match anything that
> > > contains a volatile memory reference, using a global flag for
> > > Recog.
> > 
> > So is this specifically to match the pre-test load emitted here?
> > 
> > +  emit_move_insn (output, mem);
> > +  emit_insn (gen_rtx_SET (cc, gen_rtx_COMPARE (CCZmode, output, cmp)));
> > 
> > If so, since you already know that this should always map to a
> > LOAD AND TEST, could simply just emit the LT pattern here,
> > instead of relying on combine to do it ...
> 
> Well, only if the value to compare to is constant zero (which is
> what Glibc does).  In all other cases this won't result in
> load-and-test.

So, we could add a special case for const0_rtx that generates the
LT pattern and does not rely on Combine, and get rid of the
peephole.  I'm not sure this is worthwhile thoug, because the
peephole has other beneficial effects (as discussed), and until
we've solved the problems preventing Combine from merging L+LTR in
some cases, this is the best we have.  What do you think?

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

Re: [PATCH][ARM] PR target/79871: Clean up lane/constant bounds checking errors for translation

[Kyrill Tkachov]

Ping.

https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01271.html

Thanks,
Kyrill

On 24/03/17 11:14, Kyrill Tkachov wrote:

Hi all,

This PR complains that the bounds checking error strings contain a string placeholder for 
"constant" or "lane"
which makes it hard for translators (who may want to move words around in a 
different language for syntactical reasons).

This patch cleans that up. The bunching up of common functionality between 
neon_lane_bounds and arm_const_bounds was a bit
dubious in any case as arm_const_bounds never passed down a non-NULL tree 
anyway, so one of the paths of bonds_check was
always used in only the neon_lane_bounds case anyway.

I also add some function comments and use IN_RANGE for range checking.
Bootstrapped and tested on arm-none-linux-gnueabihf.

Ok for trunk? (I believe such translation improvements fall under the 
documentation rule at this stage).

Thanks,
Kyrill

2017-03-24  Kyrylo Tkachov  

PR target/79871
* config/arm/arm.c (bounds_check): Delete.
(neon_lane_bounds): Adjust.  Make sure error string template
doesn't use string placeholder.
(arm_const_bounds): Likewise.

[PATCH][ARM] Add source mode to coprocessor pattern SETs

[Kyrill Tkachov]

Hi all,

Something I've missed during the review of these coprocessor intrinsics 
patterns is that the SET source is missing a mode.
So we get warnings during the build process.

This patch just trivially adds the appropriate modes to silence the warning.

Bootstrapped and tested on arm-none-linux-gnueabihf.

Committing as obvious.

Thanks,
Kyrill

2016-04-10  Kyrylo Tkachov  

* config/arm/arm.md (): Add mode to SET source.
(): Likewise.
commit b010fcbdd4276a6dbd861e31ca7305c1c57e04ce
Author: Kyrylo Tkachov 
Date:   Thu Jan 19 14:16:23 2017 +

[ARM] Add source mode to coprocessor pattern SETs

diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 2251991..8f95a68 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -12050,7 +12050,7 @@ (define_insn ""
 
 (define_insn ""
   [(set (match_operand:SI 0 "s_register_operand" "=r")
-	(unspec_volatile [(match_operand:SI 1 "immediate_operand" "n")
+	(unspec_volatile:SI [(match_operand:SI 1 "immediate_operand" "n")
 			  (match_operand:SI 2 "immediate_operand" "n")
 			  (match_operand:SI 3 "immediate_operand" "n")
 			  (match_operand:SI 4 "immediate_operand" "n")
@@ -12085,7 +12085,7 @@ (define_insn ""
 
 (define_insn ""
   [(set (match_operand:DI 0 "s_register_operand" "=r")
-	(unspec_volatile [(match_operand:SI 1 "immediate_operand" "n")
+	(unspec_volatile:DI [(match_operand:SI 1 "immediate_operand" "n")
 			  (match_operand:SI 2 "immediate_operand" "n")
 			  (match_operand:SI 3 "immediate_operand" "n")] MRRCI))]
   "arm_coproc_builtin_available (VUNSPEC_)"

Re: [PR 79905] ICE with vector_type

[Nathan Sidwell]

On 04/06/2017 04:17 PM, Segher Boessenkool wrote:


I don't like this cryptic name very much.  Maybe you could just use a
longer name and indent differently (break at the "=" for example), or
do a macro around where it is used a lot?


I went with rs6000_vector_type




--
Nathan Sidwell

Re: [PATCH, GCC/ARM, gcc-5-branch] Fix PR80082: LDRD erronously used for 64bit load on ARMv7-R

[Thomas Preudhomme]

Hi,

Currently GCC is happy to use LDRD to perform a 64bit load on ARMv7-R,
as shown by the testcase on this patch. However, LDRD is only atomic
when LPAE extensions is available, which they are not for ARMv7-R. This
commit solve the issue by introducing a new feature bit to distinguish
LPAE extensions instead of deducing it from div instruction
availability.

ChangeLog entries are as follow:

*** gcc/ChangeLog ***

2017-03-22  Thomas Preud'homme  

PR target/80082
* config/arm/arm-protos.h (FL_LPAE): Define macro.
(FL_FOR_ARCH7VE): Add FL_LPAE.
(arm_arch_lpae): Declare extern.
* config/arm/arm.c (arm_arch_lpae): Declare.
(arm_option_override): Define arm_arch_lpae.
* config/arm/arm.h (TARGET_HAVE_LPAE): Redefine in term of
arm_arch_lpae.

*** gcc/testsuite/ChangeLog ***

2017-03-22  Thomas Preud'homme  

PR target/80082
* gcc.target/arm/atomic_loaddi_10.c: New testcase.
* gcc.target/arm/atomic_loaddi_11.c: Likewise.

Is this ok for gcc-5-branch?

Best regards,

Thomas

On 06/04/17 14:05, Ramana Radhakrishnan wrote:

On Mon, Mar 27, 2017 at 12:15 PM, Thomas Preudhomme
 wrote:

Hi,

Currently GCC is happy to use LDRD to perform a 64bit load on ARMv7-R,
as shown by the testcase on this patch. However, LDRD is only atomic
when LPAE extensions is available, which they are not for ARMv7-R. This
commit solve the issue by introducing a new feature bit to distinguish
LPAE extensions instead of deducing it from div instruction
availability.



Ok but with the testsuite fix that I just approved,  please also fix
in gcc-5 branch.

Thanks,
Ramana



ChangeLog entries are as follow:

*** gcc/ChangeLog ***

2017-03-22  Thomas Preud'homme  

PR target/80082
* config/arm/arm-protos.h (FL_LPAE): Define macro.
(FL_FOR_ARCH7VE): Add FL_LPAE.
(arm_arch_lpae): Declare extern.
* config/arm/arm.c (arm_arch_lpae): Declare.
(arm_option_override): Define arm_arch_lpae.
* config/arm/arm.h (TARGET_HAVE_LPAE): Redefine in term of
arm_arch_lpae.

*** gcc/testsuite/ChangeLog ***

2017-03-22  Thomas Preud'homme  

PR target/80082
* gcc.target/arm/atomic_loaddi_10.c: New testcase.
* gcc.target/arm/atomic_loaddi_11.c: Likewise.


Testing: bootstrapped for -march=armv7ve and testsuite shows no regression.

Is this ok for gcc-6-branch?

Best regards,

Thomas
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index ebaf746227723f68c4c1cda89ba35c598a3ae4ba..21df391789d3d9f7b1d28e2bb2f99458843d0c3e 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -343,7 +343,7 @@ extern bool arm_is_constant_pool_ref (rtx);
 #define FL_STRONG (1 << 8)	  /* StrongARM */
 #define FL_ARCH5E (1 << 9)/* DSP extensions to v5 */
 #define FL_XSCALE (1 << 10)	  /* XScale */
-/* spare	  (1 << 11)	*/
+#define FL_LPAE   (1 << 11)   /* ARMv7-A LPAE.  */
 #define FL_ARCH6  (1 << 12)   /* Architecture rel 6.  Adds
 	 media instructions.  */
 #define FL_VFPV2  (1 << 13)   /* Vector Floating Point V2.  */
@@ -392,7 +392,7 @@ extern bool arm_is_constant_pool_ref (rtx);
 #define FL_FOR_ARCH6M	(FL_FOR_ARCH6 & ~FL_NOTM)
 #define FL_FOR_ARCH7	((FL_FOR_ARCH6T2 & ~FL_NOTM) | FL_ARCH7)
 #define FL_FOR_ARCH7A	(FL_FOR_ARCH7 | FL_NOTM | FL_ARCH6K)
-#define FL_FOR_ARCH7VE	(FL_FOR_ARCH7A | FL_THUMB_DIV | FL_ARM_DIV)
+#define FL_FOR_ARCH7VE	(FL_FOR_ARCH7A | FL_THUMB_DIV | FL_ARM_DIV | FL_LPAE)
 #define FL_FOR_ARCH7R	(FL_FOR_ARCH7A | FL_THUMB_DIV)
 #define FL_FOR_ARCH7M	(FL_FOR_ARCH7 | FL_THUMB_DIV)
 #define FL_FOR_ARCH7EM  (FL_FOR_ARCH7M | FL_ARCH7EM)
@@ -487,6 +487,9 @@ extern int arm_arch_thumb2;
 extern int arm_arch_arm_hwdiv;
 extern int arm_arch_thumb_hwdiv;
 
+/* Nonzero if this chip supports the Large Physical Address Extension.  */
+extern int arm_arch_lpae;
+
 /* Nonzero if chip disallows volatile memory access in IT block.  */
 extern int arm_arch_no_volatile_ce;
 
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 5561e433b2929df311aec3263033c14b366836d3..4baf3e454b293c765c98948d86b23024ef84982d 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -370,8 +370,7 @@ extern void (*arm_lang_output_object_attributes_hook)(void);
 #define TARGET_HAVE_LDREX	((arm_arch6 && TARGET_ARM) || arm_arch7)
 
 /* Nonzero if this chip supports LPAE.  */
-#define TARGET_HAVE_LPAE		\
-  (arm_arch7 && ((insn_flags & FL_FOR_ARCH7VE) == FL_FOR_ARCH7VE))
+#define TARGET_HAVE_LPAE	(arm_arch_lpae)
 
 /* Nonzero if this chip supports ldrex{bh} and strex{bh}.  */
 #define TARGET_HAVE_LDREXBH	((arm_arch6k && TARGET_ARM) || arm_arch7)
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 6f9518995a387c84cd53deaa5ae6bac465d81ee8..c8aab8e09f83efd084a9d21e0d2fd04c04120877 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -866,6 +866,9 @@ int arm_arch_thumb2;
 int arm_arch_arm_hwdiv;
 

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 patches:

P2 PR c++/80176
   http://gcc.gnu.org/ml/gcc-patches/2017-04/msg00027.html
   reference binding to static member function

PR debug/80263
   http://gcc.gnu.org/ml/gcc-patches/2017-04/msg4.html
   avoid emitting sizetype artificial name into debug info

Thanks

Jakub

Re: [PATCH, GCC/ARM, Stage 1] Rename FPSCR builtins to correct names

[Prakhar Bahuguna]

On 22/03/2017 10:46:30, Prakhar Bahuguna wrote:
> The GCC documentation in section 6.60.8 ARM Floating Point Status and Control
> Intrinsics states that the FPSCR register can be read and written to using the
> intrinsics __builtin_arm_get_fpscr and __builtin_arm_set_fpscr. However, these
> are misnamed within GCC itself and these intrinsic names are not recognised.
> This patch corrects the intrinsic names to match the documentation, and adds
> tests to verify these intrinsics generate the correct instructions.
> 
> Testing done: Ran regression tests on arm-none-eabi for Cortex-M4.
> 
> 2017-03-09  Prakhar Bahuguna  
> 
> gcc/ChangeLog:
> 
>   * gcc/config/arm/arm-builtins.c (arm_init_builtins): Rename
> __builtin_arm_ldfscr to __builtin_arm_get_fpscr, and rename
> __builtin_arm_stfscr to __builtin_arm_set_fpscr.
>   * gcc/testsuite/gcc.target/arm/fpscr.c: New file.
> 
> Okay for stage 1?
> 
> --
> 
> Prakhar Bahuguna

Bumping, could I get a review for this please?

Thanks,

--

Prakhar Bahuguna

Re: [wwwdocs] Document C++ null pointer constant changes in gcc-7/porting_to.html

[Jonathan Wakely]

On 09/04/17 19:58 -0600, Sandra Loosemore wrote:

On 04/07/2017 03:25 AM, Jonathan Wakely wrote:

This issue caused a lot of build failures during the GCC mass rebuilds
for Fedora, but isn't in the porting to guide yet.

Is this accurate and clear enough for casual readers?


Index: htdocs/gcc-7/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/porting_to.html,v
retrieving revision 1.13
diff -u -r1.13 porting_to.html
--- htdocs/gcc-7/porting_to.html6 Apr 2017 17:12:16 -   1.13
+++ htdocs/gcc-7/porting_to.html7 Apr 2017 09:25:06 -
@@ -118,6 +118,39 @@
with GCC 7 and some are compiled with older releases.


+Null pointer constants
+
+
+When compiling as C++11 or later, GCC 7 follows the revised definition of a
+null pointer constant. This means conversions to pointers from other
+types of constant (such as character literals and boolean literals) will now
+be rejected.
+


Nit pick: s/will now be rejected/are now rejected/

since "now" means we are describing GCC's current behavior, not future 
behavior.  :-)


If you write such code (or try to compile existing code like that) it
will now be rejected - that's the first conditional isn't it?

"It's started raining and if you go outside again you will now get
wet."

Anyway, I've committed the attached patch with that change and a
similar one you noted previously for GCC 5.


? htdocs/gcc-7/porting_to.TODO
Index: htdocs/gcc-5/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/porting_to.html,v
retrieving revision 1.11
diff -u -r1.11 porting_to.html
--- htdocs/gcc-5/porting_to.html	21 Jan 2016 22:20:29 -	1.11
+++ htdocs/gcc-5/porting_to.html	10 Apr 2017 11:48:09 -
@@ -398,7 +398,7 @@
 
 GCC 5 implements
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579";>DR 1579
-which means that in a function like:
+which means that when compiling a function like:
 
 
   X
@@ -409,17 +409,17 @@
   }
 
 
-GCC will first attempt to construct the return value as if y 
-were an rvalue, and if that fails then it will try again for an lvalue
+GCC first attempts to construct the return value as though y 
+were an rvalue, and if that fails then it tries again using an lvalue
 (all C++11 compilers already do this when returning a variable of the
-same type as the function returns, but now they are required to do it
+same type as the function returns, but now they are also required to do it
 when the types are not the same).
-This will change the constructor that gets called in some cases,
+This changes the constructor that gets called in some cases,
 for example it might now call X(Y&&) instead of
 X(const Y&).
 
 
-In most cases the only observable difference will be code that runs faster
+In most cases the only observable difference is code that runs faster
 (by moving instead of copying) but if it causes a problem the new behavior
 can be prevented by ensuring the compiler treats y as an lvalue,
 using return X(y); or
Index: htdocs/gcc-7/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/porting_to.html,v
retrieving revision 1.13
diff -u -r1.13 porting_to.html
--- htdocs/gcc-7/porting_to.html	6 Apr 2017 17:12:16 -	1.13
+++ htdocs/gcc-7/porting_to.html	10 Apr 2017 11:48:09 -
@@ -118,6 +118,39 @@
 with GCC 7 and some are compiled with older releases.
 
 
+Null pointer constants
+
+
+When compiling as C++11 or later, GCC 7 follows the revised definition of a
+null pointer constant. This means conversions to pointers from other
+types of constant (such as character literals and boolean literals) are now
+rejected.
+
+
+void* f() {
+  char* p = '\0';
+  return false;
+}
+
+
+  
+error: invalid conversion from 'char' to 'char*' [-fpermissive]
+   char* p = '\0';
+ ^~~~
+error: cannot convert 'bool' to 'void*' in return
+   return false;
+  ^
+
+
+
+Such code should be fixed to use a valid null pointer constant such as
+0 or nullptr. Care should be taken when fixing
+invalid uses of '\0' as a pointer, as it may not be clear whether
+the intention was to create a null pointer (p = 0;), to create an
+empty string (p = "";), or to write a null terminator to the
+string (*p = '\0';).
+
+
 Header dependency changes
 
 

Re: Patch ping

[Nathan Sidwell]

On 04/10/2017 08:18 AM, Jakub Jelinek wrote:

Hi!

I'd like to ping 2 patches:

P2 PR c++/80176
   http://gcc.gnu.org/ml/gcc-patches/2017-04/msg00027.html
   reference binding to static member function


This smells fishy.  There's no reason one cannot have an overload set 
containing both static and non-static functions, in any order.  So it'll 
be 'random' as to which member of the set OVL_CURRENT looks at.


You at least want '&& !OVL_NEXT (..)' there to make sure you just have a 
single static fn (if that's what you want?)



nathan

--
Nathan Sidwell

Re: [PATCH] Add a new type attribute always_alias (PR79671)

[Richard Biener]

On Fri, 7 Apr 2017, Jason Merrill wrote:

> On Fri, Apr 7, 2017 at 11:32 AM, Bernd Edlinger
>  wrote:
> > On 04/07/17 17:10, Richard Biener wrote:
> >> On April 7, 2017 3:37:30 PM GMT+02:00, Bernd Edlinger 
> >>  wrote:
> >>> On 04/07/17 08:54, Richard Biener wrote:
>  On Thu, 6 Apr 2017, Bernd Edlinger wrote:
> > I think get_alias_set(t) will return 0 for typeless_storage
> > types, and therefore has_zero_child will be set anyway.
> > I think both mean the same thing in the end, but it depends on
> > what typeless_storage should actually mean, and we have
> > not yet the same idea about it.
> 
>  But has_zero_child does not do what we like it to because otherwise
>  in the PR using the char[] array member would have worked!
> 
>  has_zero_child doesn't do that on purpose of course, but this means
>  returing alias-set zero for the typeless storage _member_ doesn't
>  suffice.
> 
> >>>
> >>> I see you have a certain idea how to solve the C++17 issue.
> >>> And yes, I apologize, if I tried to pee on your tree :)
> >>
> >> We do have the need to support this part of the C++ standard.  For other 
> >> user code may_alias suffices and I see no reason to haste inventing sth 
> >> new without a single convincing testcase.  GCC/Language extensions should 
> >> not be added without a good reason.
> >>
> >> I didn't propose to expose the type flag to users at all.
> >>
> >> Richard.
> >>
> >
> > Well, actually you did:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671#c100
> >
> > But I won't argue if you prefer to do it as you like,
> > after all TBAA is your area.  So that is fine for me.
> >
> > Attached is the latest version of my patch, I fixed
> > the issue with the type-flag conversion, and it is
> > already fully functional.
> 
> I agree that we don't want a new attribute.
> 
> This should not be limited to C++17 mode; std::aligned_storage is in
> C++11 and we might as well have the same behavior in C++98 mode.

So here's my variant of a fix.  I constrained the new flag
TYPE_TYPELESS_STORAGE to arrays and thus hope my localized fix in
build_cplus_array_type will suffice (if I have time I'll play with
template instantiation).

I've created a nice small testcase that exposes the issue but it
needs a PTA fix to work (I'll commit the tree-ssa-structalias.c
fix separately).  Some more obfuscation might remove the requirement
of it (don't use an asm but a noinline const function maybe).

Bootstrap and regtest is underway on x86_64-unknown-linux-gnu.

There may be some issues with LTO / cross-language support remaining,
I need to think more about this (TYPE_CANONICAL merging plus alias.c
punning down to TYPE_CANONICAL).

Richard.

2017-04-10  Richard Biener  

PR c++/79671
cp/
* tree.c (build_cplus_array_type): Set TYPE_TYPELESS_STORAGE
for arrays of unsigned char or std::byte.

* tree-core.h (tree_type_common): Add typeless_storage flag.
* tree.h (TYPE_TYPELESS_STORAGE): New macro.
* alias.c (alias_set_entry): Add has_typeless_storage member.
(alias_set_subset_of): Handle it.
(alias_sets_conflict_p): Likewise.
(init_alias_set_entry): Initialize it.
(get_alias_set): For ARRAY_TYPEs handle TYPE_TYPELESS_STORAGE.
(record_alias_subset): Likewise.
* lto-streamer-out.c (hash_tree): Hash TYPE_TYPELESS_STORAGE.
* tree-streamer-in.c (unpack_ts_type_common_value_fields): Stream
TYPE_TYPELESS_STORAGE.
* tree-streamer-out.c (pack_ts_type_common_value_fields): Likewise.
* tree-ssa-structalias.c (find_func_aliases): Properly handle
asm inputs.

lto/
* lto.c (compare_tree_sccs_1): Compare TYPE_TYPELESS_STORAGE.

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


Index: gcc/alias.c
===
--- gcc/alias.c (revision 246803)
+++ gcc/alias.c (working copy)
@@ -136,6 +136,9 @@ struct GTY(()) alias_set_entry {
   bool is_pointer;
   /* Nonzero if is_pointer or if one of childs have has_pointer set.  */
   bool has_pointer;
+  /* Nonzero if we have a child serving as typeless storage (or are
+ such storage ourselves).  */
+  bool has_typeless_storage;
 
   /* The children of the alias set.  These are not just the immediate
  children, but, in fact, all descendants.  So, if we have:
@@ -419,7 +422,8 @@ alias_set_subset_of (alias_set_type set1
   /* Check if set1 is a subset of set2.  */
   ase2 = get_alias_set_entry (set2);
   if (ase2 != 0
-  && (ase2->has_zero_child
+  && (ase2->has_typeless_storage
+ || ase2->has_zero_child
  || (ase2->children && ase2->children->get (set1
 return true;
 
@@ -480,7 +484,8 @@ alias_sets_conflict_p (alias_set_type se
   /* See if the first alias set is a subset of the second.  */
   ase1 = get_alias_set_entry (set1);
   if (ase1 != 0
-  && ase1->children && ase1->children->get (set

Re: [PATCH] Define std::to_chars and std::from_chars for C++17 (P0067R5, partial)

[Jonathan Wakely]

On 07/04/17 13:29 +0100, Jonathan Wakely wrote:

This adds another piece of the C++17 library, the std::to_chars and
std::from_chars functions for converting numbers to/from strings. This
only adds the integer support, floating point types will require a lot
more work.

This has only been lightly optimised, so it beats printf on average,
but there's probably more opportunity for improvement. I didn't
investigate whether doing all work with unsigned long long would be
faster, instead of using function templates specialized for unsigned
int, unsigned long and unsigned long long. It should help code size,
but I don't know if it would be faster. I also didn't investigate
whether doing from_chars in two stages would be better, i.e. finding
all the characters that are valid digits in the given base first, and
then converting them to an integer in a second step. I'm sure there's
lots of tuning that could be done, but I hope this is good enough to
start with.


I forgot to say that most of the optimisations I did include come from
a talk by Andrei Alexandrescu:

https://www.slideshare.net/andreialexandrescu1/three-optimization-tips-for-c
https://www.facebook.com/notes/facebook-engineering/three-optimization-tips-for-c/10151361643253920

Whether these actually help might be debatable. I think I did test all
of them against the simpler code before including them.

Re: Patch ping

[Jakub Jelinek]

On Mon, Apr 10, 2017 at 08:41:28AM -0400, Nathan Sidwell wrote:
> On 04/10/2017 08:18 AM, Jakub Jelinek wrote:
> > Hi!
> > 
> > I'd like to ping 2 patches:
> > 
> > P2 PR c++/80176
> >http://gcc.gnu.org/ml/gcc-patches/2017-04/msg00027.html
> >reference binding to static member function
> 
> This smells fishy.  There's no reason one cannot have an overload set
> containing both static and non-static functions, in any order.  So it'll be
> 'random' as to which member of the set OVL_CURRENT looks at.

I actually don't know if I need the OVL_CURRENT thing, maybe not.
On the testcase there is an overloaded static member function and I don't
get an error on that, just on the non-overloaded one.
I've tried:
struct X { static void foo(); static void baz(int); static int baz(double); 
void m(int); void n(int); int n(float); } x;
void X::foo() {}
static void bar() {}
void (&r1)() = x.foo;
void (&r2)() = X::foo;
void (&r3)() = bar;
void (&r4)(int) = x.baz;
int (&r5)(double) = x.baz;
void (&r6)(int) = X::baz;
int (&r7)(double) = X::baz;
void (&r8)(int) = x.m;
void (&r9)(int) = x.n;
int (&r10)(float) = x.n;
and there I see COMPONENT_REF with BASELINK second operand with
BASELINK_FUNCTIONS being an overload only for the methods.
And even if I try overload with mixed methods and static member functions,
lvalue_kind with that is only called when seeing the invalid binding
to method:
struct X { void o(unsigned char); static void o(int); void o(double); } x;
void (&r12)(int) = x.o;
void (&r13)(double) = x.o;

Thus, would it be acceptable to omit the OVL_CURRENT as in (tested so far
just on the updated ref23.C with additional test from the above r12 snippet,
of course would perform full bootstrap/regtest with that)?

2017-04-08  Jakub Jelinek  

PR c++/80176
* tree.c (lvalue_kind): For COMPONENT_REF with BASELINK second
operand, if it is a static member function, recurse on the
BASELINK.

* g++.dg/init/ref23.C: New test.

--- gcc/cp/tree.c.jj2017-04-07 21:17:57.078208891 +0200
+++ gcc/cp/tree.c   2017-04-10 15:18:57.941508441 +0200
@@ -105,6 +105,14 @@ lvalue_kind (const_tree ref)
   return op1_lvalue_kind;
 
 case COMPONENT_REF:
+  if (BASELINK_P (TREE_OPERAND (ref, 1)))
+   {
+ tree fn = BASELINK_FUNCTIONS (TREE_OPERAND (ref, 1));
+
+ /* For static member function recurse on the BASELINK.  */
+ if (TREE_CODE (fn) == FUNCTION_DECL && DECL_STATIC_FUNCTION_P (fn))
+   return lvalue_kind (TREE_OPERAND (ref, 1));
+   }
   op1_lvalue_kind = lvalue_kind (TREE_OPERAND (ref, 0));
   /* Look at the member designator.  */
   if (!op1_lvalue_kind)
--- gcc/testsuite/g++.dg/init/ref23.C.jj2017-04-10 15:17:04.823911276 
+0200
+++ gcc/testsuite/g++.dg/init/ref23.C   2017-04-10 15:18:07.504133944 +0200
@@ -0,0 +1,15 @@
+// PR c++/80176
+// { dg-do compile }
+
+struct X { static void foo(); static void baz(int); static int baz(double); } 
x;
+struct Y { void o(unsigned char); static void o(int); void o(double); } y;
+void X::foo() {}
+static void bar() {}
+void (&r1)() = x.foo;
+void (&r2)() = X::foo;
+void (&r3)() = bar;
+void (&r4)(int) = x.baz;
+int (&r5)(double) = x.baz;
+void (&r6)(int) = X::baz;
+int (&r7)(double) = X::baz;
+void (&r8)(int) = y.o;

Jakub

Re: [PATCH, GCC/ARM, Stage 1] Rename FPSCR builtins to correct names

[Kyrill Tkachov]

Hi Prakhar,
Sorry for the delay,

On 22/03/17 10:46, Prakhar Bahuguna wrote:

The GCC documentation in section 6.60.8 ARM Floating Point Status and Control
Intrinsics states that the FPSCR register can be read and written to using the
intrinsics __builtin_arm_get_fpscr and __builtin_arm_set_fpscr. However, these
are misnamed within GCC itself and these intrinsic names are not recognised.
This patch corrects the intrinsic names to match the documentation, and adds
tests to verify these intrinsics generate the correct instructions.

Testing done: Ran regression tests on arm-none-eabi for Cortex-M4.

2017-03-09  Prakhar Bahuguna  

gcc/ChangeLog:

* gcc/config/arm/arm-builtins.c (arm_init_builtins): Rename
  __builtin_arm_ldfscr to __builtin_arm_get_fpscr, and rename
  __builtin_arm_stfscr to __builtin_arm_set_fpscr.
* gcc/testsuite/gcc.target/arm/fpscr.c: New file.

Okay for stage 1?


I see that the mistake was in not addressing one of the review comments in:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01832.html
properly in the patch that added these functions :(

This is ok for stage 1 if a bootstrap and test on arm-none-linux-gnueabihf 
works fine
I don't think we want to maintain the __builtin_arm_[ld,st]fscr names for 
backwards compatibility
as they were not documented and are __builtin_arm* functions that we don't 
guarantee to maintain.

Thanks,
Kyrill


--

Prakhar Bahuguna

[PATCH 80345]Backport pr68021 fix to GCC 5

[Bin Cheng]

Hi,
This patch fixes PR80345.  It is backport of PR68021 to GCC 5 branch with one 
assert statement removed.  It also includes test case provided in the PR.

Bootstrap and test on x86_64.  Is it OK?

Thanks,
bin
2017-04-07  Bin Cheng  

Backport from mainline
2016-02-10  Bin Cheng  

PR tree-optimization/68021
* tree-ssa-loop-ivopts.c (get_computation_aff): Set ratio to 1 if
when computing the value of biv cand by itself.

gcc/testsuite/ChangeLog
2017-04-07  Bin Cheng  

PR tree-optimization/80345
* gcc.c-torture/compile/pr80345.c

Backport from mainline
2016-02-10  Bin Cheng  

PR tree-optimization/68021
* gcc.dg/tree-ssa/pr68021.c: New test.diff --git a/gcc/testsuite/gcc.c-torture/compile/pr80345.c 
b/gcc/testsuite/gcc.c-torture/compile/pr80345.c
new file mode 100644
index 000..3a9f3d7
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr80345.c
@@ -0,0 +1,17 @@
+/* PR tree-optimization/80345 */
+
+typedef long mp_limb_signed_t;
+void fn1(mp_limb_signed_t p1) {
+  int *a = (int *)1;
+  mp_limb_signed_t i, j;
+  i = 0;
+  for (; i < p1; i++) {
+j = 0;
+for (; j <= i; j++)
+  *a++ = 0;
+j = i + 1;
+for (; j < p1; j++)
+  a++;
+  }
+}
+void fn2() { fn1((mp_limb_signed_t)fn2); }
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr68021.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr68021.c
new file mode 100644
index 000..f60b1ff
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr68021.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+
+char a;
+void fn1 (char *p1, int p2, int p3)
+{
+  int i, x;
+  for (i = 0; i < 10; i++)
+{
+  for (x = 0; x < p3; x++)
+   {
+ *p1 = a;
+ p1--;
+   }
+  p1 += p2;
+}
+}
diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c
index 6c96430..1d64261 100644
--- a/gcc/tree-ssa-loop-ivopts.c
+++ b/gcc/tree-ssa-loop-ivopts.c
@@ -3118,7 +3118,18 @@ get_computation_aff (struct loop *loop,
   var = fold_convert (uutype, var);
 }
 
-  if (!constant_multiple_of (ustep, cstep, &rat))
+  /* Ratio is 1 when computing the value of biv cand by itself.
+ We can't rely on constant_multiple_of in this case because the
+ use is created after the original biv is selected.  The call
+ could fail because of inconsistent fold behavior.  See PR68021
+ for more information.  */
+  if (cand->pos == IP_ORIGINAL && cand->incremented_at == use->stmt)
+{
+  gcc_assert (is_gimple_assign (use->stmt));
+  gcc_assert (gimple_assign_lhs (use->stmt) == cand->var_after);
+  rat = 1;
+}
+  else if (!constant_multiple_of (ustep, cstep, &rat))
 return false;
 
   /* In case both UBASE and CBASE are shortened to UUTYPE from some common

[PATCH PR80153]Part1, Get base pointer from the first element of pointer type aff_tree, Simplify add_elt_to_tree

[Bin Cheng]

Hi,
This is another try fixing PR80153.  It's based on richi's idea which is easier 
to understand than my
previous patch.  The patch gets base pointer from the first element of pointer 
aff_tree, builds result
expression in aff_tree's type unconditionally.  With this patch, A) we can do 
unconditional type
conversion on element in add_elt_to_tree, which simplify the function a lot; B) 
Except for below
mentioned fallout, customer of aff_tree doesn't need to do explicit conversion 
for result expression
of aff_combination_to_tree now.

Though this patch can handle normal constant base pointer_plus_expr, e.g, 
((char *)1024 + (size_t)x),
we still can't handle extreme case in which x is of pointer type and its coef 
is 1.  I believe this is
a latent problem in tree-affine.c all the time.  It's not exposed because the 
biggest customer (ivopt)
always generates code in unsigned, rather than pointer type.  Let's see if this 
patch will uncover the issue.

I also need to do more invariant check in rewrite_use_nonlinear_expr for test 
gcc.dg/tree-ssa/reassoc-19.c.
 It relies on wrong behavior of tree-affine.c addressed in this patch.

Bootstrap and test on X86_64 and AArch64.  Is it OK if no failures?  The next 
patch addresses a
breakage of tree-affine.c usage.

Thanks,
bin

2017-04-07  Richard Biener  
Bin Cheng  

PR tree-optimization/80153
* tree-affine.c (aff_combination_to_tree): Get base pointer from
the first element of pointer type aff_tree.  Build result expr in
aff_tree's type.
(add_elt_to_tree): Convert to type unconditionally.  Remove other
fold_convert calls.
* tree-ssa-loop-ivopts.c (alloc_iv): Pass in consistent types.
(rewrite_use_nonlinear_expr): Check invariant using iv information.

gcc/testsuite/ChangeLog
2017-04-07  Bin Cheng  

PR tree-optimization/80153
* gcc.c-torture/execute/pr80153.c: New.diff --git a/gcc/testsuite/gcc.c-torture/execute/pr80153.c 
b/gcc/testsuite/gcc.c-torture/execute/pr80153.c
new file mode 100644
index 000..3eed578
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr80153.c
@@ -0,0 +1,48 @@
+/* PR tree-optimization/80153 */
+
+void check (int, int, int) __attribute__((noinline));
+void check (int c, int c2, int val)
+{
+  if (!val) {
+__builtin_abort();
+  }
+}
+
+static const char *buf;
+static int l, i;
+
+void _fputs(const char *str)  __attribute__((noinline));
+void _fputs(const char *str)
+{
+  buf = str;
+  i = 0;
+  l = __builtin_strlen(buf);
+}
+
+char _fgetc() __attribute__((noinline));
+char _fgetc()
+{
+  char val = buf[i];
+  i++;
+  if (i > l)
+return -1;
+  else
+return val;
+}
+
+static const char *string = "oops!\n";
+
+int main(void)
+{
+  int i;
+  int c;
+
+  _fputs(string);
+
+  for (i = 0; i < __builtin_strlen(string); i++) {
+c = _fgetc();
+check(c, string[i], c == string[i]);
+  }
+
+  return 0;
+}
diff --git a/gcc/tree-affine.c b/gcc/tree-affine.c
index 30fff67..13c477d 100644
--- a/gcc/tree-affine.c
+++ b/gcc/tree-affine.c
@@ -377,58 +377,28 @@ static tree
 add_elt_to_tree (tree expr, tree type, tree elt, const widest_int &scale_in)
 {
   enum tree_code code;
-  tree type1 = type;
-  if (POINTER_TYPE_P (type))
-type1 = sizetype;
 
   widest_int scale = wide_int_ext_for_comb (scale_in, type);
 
-  if (scale == -1
-  && POINTER_TYPE_P (TREE_TYPE (elt)))
-{
-  elt = convert_to_ptrofftype (elt);
-  elt = fold_build1 (NEGATE_EXPR, TREE_TYPE (elt), elt);
-  scale = 1;
-}
-
+  elt = fold_convert (type, elt);
   if (scale == 1)
 {
   if (!expr)
-   {
- if (POINTER_TYPE_P (TREE_TYPE (elt)))
-   return elt;
- else
-   return fold_convert (type1, elt);
-   }
+   return elt;
 
-  if (POINTER_TYPE_P (TREE_TYPE (expr)))
-   return fold_build_pointer_plus (expr, elt);
-  if (POINTER_TYPE_P (TREE_TYPE (elt)))
-   return fold_build_pointer_plus (elt, expr);
-  return fold_build2 (PLUS_EXPR, type1,
- expr, fold_convert (type1, elt));
+  return fold_build2 (PLUS_EXPR, type, expr, elt);
 }
 
   if (scale == -1)
 {
   if (!expr)
-   return fold_build1 (NEGATE_EXPR, type1,
-   fold_convert (type1, elt));
+   return fold_build1 (NEGATE_EXPR, type, elt);
 
-  if (POINTER_TYPE_P (TREE_TYPE (expr)))
-   {
- elt = convert_to_ptrofftype (elt);
- elt = fold_build1 (NEGATE_EXPR, TREE_TYPE (elt), elt);
- return fold_build_pointer_plus (expr, elt);
-   }
-  return fold_build2 (MINUS_EXPR, type1,
- expr, fold_convert (type1, elt));
+  return fold_build2 (MINUS_EXPR, type, expr, elt);
 }
 
-  elt = fold_convert (type1, elt);
   if (!expr)
-return fold_build2 (MULT_EXPR, type1, elt,
-   wide_int_to_tree (type1, scale));
+return fold_build2 (MULT_EXPR, type, elt, wide_int_to_tree (type, scale

[PATCH PR80153]Part2, Check base pointer directly

[Bin Cheng]

Hi,
This is part 2 patch fixing PR80153, because we now explicitly rely on behavior 
that the first element being base pointer of pointer type aff_tree.  The 
original code removes base pointer from aff_tree without updating aff_tree's 
type.  Actually, we don't need to use tree-affine at all, we can directly look 
into pointer_plus_expr.

Bootstrap and test on x86_64 and AArch64 ongoing.  Is it OK if no failures?

Thanks,
bin

2017-04-07  Bin Cheng  

PR tree-optimization/80153
* tree-ssa-loop-ivopts.c (add_iv_candidate_for_use): Check and 
remove POINTER_PLUS_EXPR's base part directly, rather than through
aff_tree.diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c
index 036e041..4fc35fa 100644
--- a/gcc/tree-ssa-loop-ivopts.c
+++ b/gcc/tree-ssa-loop-ivopts.c
@@ -3335,41 +3335,20 @@ add_iv_candidate_for_use (struct ivopts_data *data, 
struct iv_use *use)
 }
 
   /* Record common candidate with base_object removed in base.  */
-  if (iv->base_object != NULL)
+  base = iv->base;
+  STRIP_NOPS (base);
+  if (iv->base_object != NULL && TREE_CODE (base) == POINTER_PLUS_EXPR)
 {
-  unsigned i;
-  aff_tree aff_base;
-  tree step, base_object = iv->base_object;
+  tree step = iv->step;
 
-  base = iv->base;
-  step = iv->step;
-  STRIP_NOPS (base);
   STRIP_NOPS (step);
-  STRIP_NOPS (base_object);
-  tree_to_aff_combination (base, TREE_TYPE (base), &aff_base);
-  for (i = 0; i < aff_base.n; i++)
-   {
- if (aff_base.elts[i].coef != 1)
-   continue;
-
- if (operand_equal_p (aff_base.elts[i].val, base_object, 0))
-   break;
-   }
-  if (i < aff_base.n)
-   {
- aff_combination_remove_elt (&aff_base, i);
- base = aff_combination_to_tree (&aff_base);
- basetype = TREE_TYPE (base);
- if (POINTER_TYPE_P (basetype))
-   basetype = sizetype;
-
- step = fold_convert (basetype, step);
- record_common_cand (data, base, step, use);
- /* Also record common candidate with offset stripped.  */
- base = strip_offset (base, &offset);
- if (offset)
-   record_common_cand (data, base, step, use);
-   }
+  base = TREE_OPERAND (base, 1);
+  step = fold_convert (sizetype, step);
+  record_common_cand (data, base, step, use);
+  /* Also record common candidate with offset stripped.  */
+  base = strip_offset (base, &offset);
+  if (offset)
+   record_common_cand (data, base, step, use);
 }
 
   /* At last, add auto-incremental candidates.  Make such variables

Re: Patch ping

[Nathan Sidwell]

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


and there I see COMPONENT_REF with BASELINK second operand with
BASELINK_FUNCTIONS being an overload only for the methods.
And even if I try overload with mixed methods and static member functions,
lvalue_kind with that is only called when seeing the invalid binding
to method:




struct X { void o(unsigned char); static void o(int); void o(double); } x;
void (&r12)(int) = x.o;
void (&r13)(double) = x.o;


Ok, that makes sense.  This patch is ok, with ...


+ /* For static member function recurse on the BASELINK.  */


Mention that overloads of more than one function go via a different path.

nathan

--
Nathan Sidwell

Re: [PATCH] Add a new type attribute always_alias (PR79671)

[Jason Merrill]

On Mon, Apr 10, 2017 at 8:50 AM, Richard Biener  wrote:
> So here's my variant of a fix.  I constrained the new flag
> TYPE_TYPELESS_STORAGE to arrays and thus hope my localized fix in
> build_cplus_array_type will suffice (if I have time I'll play with
> template instantiation).

Looks good.  I would expect this to just work with templates, but it
should of course be tested.  In particular, std::aligned_storage needs
to work.

> * tree.c (build_cplus_array_type): Set TYPE_TYPELESS_STORAGE
> for arrays of unsigned char or std::byte.

I think it would be good to have a flag to select whether these
semantics apply to any char variant and std::byte, only unsigned char
and std::byte, or only std::byte.

Jason

One more path to fix PR70478

[Vladimir Makarov]

  This is the second try to fix

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

  The first try patch triggered a latent bug and broke one Fortran 
testcase on x86-64.


  The patch was successfully bootstrapped on x86-64 and tested on 
x86-64, ppc64, and aarch64.


  Committed as rev. 246808.


Index: ChangeLog
===
--- ChangeLog	(revision 246807)
+++ ChangeLog	(working copy)
@@ -1,3 +1,12 @@
+2017-04-10  Vladimir Makarov  
+
+	PR rtl-optimization/70478
+	* lra-constraints.c (curr_small_class_check): New.
+	(update_and_check_small_class_inputs): New.
+	(process_alt_operands): Update curr_small_class_check.  Disfavor
+	alternative insn memory operands.  Check available regs for small
+	class operands.
+
 2017-03-31  Matthew Fortune  
 
 	PR target/80057
Index: lra-constraints.c
===
--- lra-constraints.c	(revision 246789)
+++ lra-constraints.c	(working copy)
@@ -1852,6 +1852,42 @@ prohibited_class_reg_set_mode_p (enum re
 	  (temp, ira_prohibited_class_mode_regs[rclass][mode]));
 }
 
+
+/* Used to check validity info about small class input operands.  It
+   should be incremented at start of processing an insn
+   alternative.  */
+static unsigned int curr_small_class_check = 0;
+
+/* Update number of used inputs of class OP_CLASS for operand NOP.
+   Return true if we have more such class operands than the number of
+   available regs.  */
+static bool
+update_and_check_small_class_inputs (int nop, enum reg_class op_class)
+{
+  static unsigned int small_class_check[LIM_REG_CLASSES];
+  static int small_class_input_nums[LIM_REG_CLASSES];
+  
+  if (SMALL_REGISTER_CLASS_P (op_class)
+  /* We are interesting in classes became small because of fixing
+	 some hard regs, e.g. by an user through GCC options.  */
+  && hard_reg_set_intersect_p (reg_class_contents[op_class],
+   ira_no_alloc_regs)
+  && (curr_static_id->operand[nop].type != OP_OUT
+	  || curr_static_id->operand[nop].early_clobber))
+{
+  if (small_class_check[op_class] == curr_small_class_check)
+	small_class_input_nums[op_class]++;
+  else
+	{
+	  small_class_check[op_class] = curr_small_class_check;
+	  small_class_input_nums[op_class] = 1;
+	}
+  if (small_class_input_nums[op_class] > ira_class_hard_regs_num[op_class])
+	return true;
+}
+  return false;
+}
+
 /* Major function to choose the current insn alternative and what
operands should be reloaded and how.	 If ONLY_ALTERNATIVE is not
negative we should consider only this alternative.  Return false if
@@ -1952,6 +1988,7 @@ process_alt_operands (int only_alternati
   if (!TEST_BIT (preferred, nalt))
 	continue;
 
+  curr_small_class_check++;
   overall = losers = addr_losers = 0;
   static_reject = reject = reload_nregs = reload_sum = 0;
   for (nop = 0; nop < n_operands; nop++)
@@ -2685,6 +2722,21 @@ process_alt_operands (int only_alternati
 		}
 		}
 
+	  /* When we use memory operand, the insn should read the
+		 value from memory and even if we just wrote a value
+		 into the memory it is costly in comparison with an
+		 insn alternative which does not use memory
+		 (e.g. register or immediate operand).  */
+	  if (no_regs_p && offmemok)
+		{
+		  if (lra_dump_file != NULL)
+		fprintf
+		  (lra_dump_file,
+		   "Using memory insn operand %d: reject+=3\n",
+		   nop);
+		  reject += 3;
+		}
+	  
 #ifdef SECONDARY_MEMORY_NEEDED
 	  /* If reload requires moving value through secondary
 		 memory, it will need one more insn at least.  */
@@ -2747,6 +2799,14 @@ process_alt_operands (int only_alternati
   goto fail;
 }
 
+	  if (update_and_check_small_class_inputs (nop, this_alternative))
+	{
+	  if (lra_dump_file != NULL)
+		fprintf (lra_dump_file,
+			 "alt=%d, not enough small class regs -- refuse\n",
+			 nalt);
+	  goto fail;
+	}
 	  curr_alt[nop] = this_alternative;
 	  COPY_HARD_REG_SET (curr_alt_set[nop], this_alternative_set);
 	  curr_alt_win[nop] = this_alternative_win;

Re: [PATCH] Add a new type attribute always_alias (PR79671)

[Richard Biener]

On Mon, 10 Apr 2017, Jason Merrill wrote:

> On Mon, Apr 10, 2017 at 8:50 AM, Richard Biener  wrote:
> > So here's my variant of a fix.  I constrained the new flag
> > TYPE_TYPELESS_STORAGE to arrays and thus hope my localized fix in
> > build_cplus_array_type will suffice (if I have time I'll play with
> > template instantiation).
> 
> Looks good.  I would expect this to just work with templates, but it
> should of course be tested.  In particular, std::aligned_storage needs
> to work.

The libstdc++ testsuite passes... (of course it did before as well).
I'll experiment with some trivial bits tomorrow.

> > * tree.c (build_cplus_array_type): Set TYPE_TYPELESS_STORAGE
> > for arrays of unsigned char or std::byte.
> 
> I think it would be good to have a flag to select whether these
> semantics apply to any char variant and std::byte, only unsigned char
> and std::byte, or only std::byte.

Any suggestion?  Not sure we really need it (I'm hesitant to write
all the testcases to verify it actually works).

Meanwhile re-testing with the following hunk to fix some LTO fallout.

Richard.

Index: gcc/tree.h
===
--- gcc/tree.h  (revision 246808)
+++ gcc/tree.h  (working copy)
@@ -4914,7 +4917,7 @@ inline bool
 canonical_type_used_p (const_tree t)
 {
   return !(POINTER_TYPE_P (t)
-  || TREE_CODE (t) == ARRAY_TYPE
+  || (TREE_CODE (t) == ARRAY_TYPE && ! TYPE_TYPELESS_STORAGE (t))
   || TREE_CODE (t) == VECTOR_TYPE);
 }
 

Re: [PATCH PR80153]Part1, Get base pointer from the first element of pointer type aff_tree, Simplify add_elt_to_tree

[Richard Biener]

On Mon, Apr 10, 2017 at 4:35 PM, Bin Cheng  wrote:
> Hi,
> This is another try fixing PR80153.  It's based on richi's idea which is 
> easier to understand than my
> previous patch.  The patch gets base pointer from the first element of 
> pointer aff_tree, builds result
> expression in aff_tree's type unconditionally.  With this patch, A) we can do 
> unconditional type
> conversion on element in add_elt_to_tree, which simplify the function a lot; 
> B) Except for below
> mentioned fallout, customer of aff_tree doesn't need to do explicit 
> conversion for result expression
> of aff_combination_to_tree now.
>
> Though this patch can handle normal constant base pointer_plus_expr, e.g, 
> ((char *)1024 + (size_t)x),
> we still can't handle extreme case in which x is of pointer type and its coef 
> is 1.  I believe this is
> a latent problem in tree-affine.c all the time.  It's not exposed because the 
> biggest customer (ivopt)
> always generates code in unsigned, rather than pointer type.  Let's see if 
> this patch will uncover the issue.
>
> I also need to do more invariant check in rewrite_use_nonlinear_expr for test 
> gcc.dg/tree-ssa/reassoc-19.c.
>  It relies on wrong behavior of tree-affine.c addressed in this patch.
>
> Bootstrap and test on X86_64 and AArch64.  Is it OK if no failures?  The next 
> patch addresses a
> breakage of tree-affine.c usage.

Ok.

Thanks,
Richard.

> Thanks,
> bin
>
> 2017-04-07  Richard Biener  
> Bin Cheng  
>
> PR tree-optimization/80153
> * tree-affine.c (aff_combination_to_tree): Get base pointer from
> the first element of pointer type aff_tree.  Build result expr in
> aff_tree's type.
> (add_elt_to_tree): Convert to type unconditionally.  Remove other
> fold_convert calls.
> * tree-ssa-loop-ivopts.c (alloc_iv): Pass in consistent types.
> (rewrite_use_nonlinear_expr): Check invariant using iv information.
>
> gcc/testsuite/ChangeLog
> 2017-04-07  Bin Cheng  
>
> PR tree-optimization/80153
> * gcc.c-torture/execute/pr80153.c: New.

Re: [PATCH PR80153]Part2, Check base pointer directly

[Richard Biener]

On Mon, Apr 10, 2017 at 4:35 PM, Bin Cheng  wrote:
> Hi,
> This is part 2 patch fixing PR80153, because we now explicitly rely on 
> behavior that the first element being base pointer of pointer type aff_tree.  
> The original code removes base pointer from aff_tree without updating 
> aff_tree's type.  Actually, we don't need to use tree-affine at all, we can 
> directly look into pointer_plus_expr.
>
> Bootstrap and test on x86_64 and AArch64 ongoing.  Is it OK if no failures?

Ok.

Thanks,
Richard.

> Thanks,
> bin
>
> 2017-04-07  Bin Cheng  
>
> PR tree-optimization/80153
> * tree-ssa-loop-ivopts.c (add_iv_candidate_for_use): Check and
> remove POINTER_PLUS_EXPR's base part directly, rather than through
> aff_tree.

Re: [PATCH 80345]Backport pr68021 fix to GCC 5

[Richard Biener]

On Mon, Apr 10, 2017 at 4:30 PM, Bin Cheng  wrote:
> Hi,
> This patch fixes PR80345.  It is backport of PR68021 to GCC 5 branch with one 
> assert statement removed.  It also includes test case provided in the PR.
>
> Bootstrap and test on x86_64.  Is it OK?

Ok.

Thanks,
Richard.

> Thanks,
> bin
> 2017-04-07  Bin Cheng  
>
> Backport from mainline
> 2016-02-10  Bin Cheng  
>
> PR tree-optimization/68021
> * tree-ssa-loop-ivopts.c (get_computation_aff): Set ratio to 1 if
> when computing the value of biv cand by itself.
>
> gcc/testsuite/ChangeLog
> 2017-04-07  Bin Cheng  
>
> PR tree-optimization/80345
> * gcc.c-torture/compile/pr80345.c
>
> Backport from mainline
> 2016-02-10  Bin Cheng  
>
> PR tree-optimization/68021
> * gcc.dg/tree-ssa/pr68021.c: New test.

Re: [PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[Jeff Law]

On 04/07/2017 04:30 AM, Martin Liška wrote:

On 04/06/2017 06:44 PM, Jeff Law wrote:

On 03/24/2017 03:29 AM, Martin Liška wrote:

I would like to ping that. I'm not sure what's agreement after I read
discussion in: https://gcc.gnu.org/ml/gcc/2017-03/msg00070.html

Martin Sebor may know, CC'ing him.

Not sure if you're pinging the internal_error_cont stuff, or the ODR 
diagnostics changes.

WRT the ODR diagnostics, I'd say let's go with the C++17 style (all-lowercase 
with a hyphen).

If you've got a pointer to the internal_err_cont changes, please pass it along.


Yep, I was interested in internal_err_cont. It's next stage1 material, but I'm 
willing to have
a feedback whether separation of internal messages is desired to be excluded 
from translation or not?

As stage1 stuff, I'll largely be ignoring.

I'm torn on translating this stuff.  It's hard enough for a 
non-developer to interpret an ICE message, if it's not in their native 
language it'd be impossible.


OTOH, if we translate and the user forwards the translated message to 
us, we may not be able to interpret.


That probably argues there's some part that should be translated to be 
easier for the users, but the real guts of the message should not be 
translated.


jeff

Re: [PATCH 0/3] Introduce internal_error_cont and exclude it from pot files

[Richard Biener]

On Mon, Apr 10, 2017 at 5:42 PM, Jeff Law  wrote:
> On 04/07/2017 04:30 AM, Martin Liška wrote:
>>
>> On 04/06/2017 06:44 PM, Jeff Law wrote:
>>>
>>> On 03/24/2017 03:29 AM, Martin Liška wrote:

 I would like to ping that. I'm not sure what's agreement after I read
 discussion in: https://gcc.gnu.org/ml/gcc/2017-03/msg00070.html

 Martin Sebor may know, CC'ing him.
>>>
>>> Not sure if you're pinging the internal_error_cont stuff, or the ODR
>>> diagnostics changes.
>>>
>>> WRT the ODR diagnostics, I'd say let's go with the C++17 style
>>> (all-lowercase with a hyphen).
>>>
>>> If you've got a pointer to the internal_err_cont changes, please pass it
>>> along.
>>
>>
>> Yep, I was interested in internal_err_cont. It's next stage1 material, but
>> I'm willing to have
>> a feedback whether separation of internal messages is desired to be
>> excluded from translation or not?
>
> As stage1 stuff, I'll largely be ignoring.
>
> I'm torn on translating this stuff.  It's hard enough for a non-developer to
> interpret an ICE message, if it's not in their native language it'd be
> impossible.
>
> OTOH, if we translate and the user forwards the translated message to us, we
> may not be able to interpret.
>
> That probably argues there's some part that should be translated to be
> easier for the users, but the real guts of the message should not be
> translated.

Message number and catalogue.

/me runs...

> jeff

Re: [libcp1] handle anon aggregates linkage-named by typedefs

[Jeff Law]

On 03/21/2017 05:32 PM, Alexandre Oliva wrote:

GDB has had a work-around that uses the typedef name as the name of an
anonymous class, struct or union, when introducing them through libcc1's
C++ API.  It didn't do that for enums, that remained anonymous, and GCC
warned about using types without linkage as members of types with
linkage, which enabled us to catch the shortcoming in libcc1.

Now GDB can introduce all anonymous aggregate types without a name, and
then introduce their names through typedefs, so as to get the expected
language behavior for typedef-named anonymous types.

Ok to install?  Regression-tested with GDB's gdb.compile tests in the
users/pmuldoon/c++compile branch.


Arrange for the first typedef to an anonymous type in the same context
to be used as the linkage name for the type.

for  libcc1/ChangeLog

* libcp1plugin.cc (plugin_build_decl): Propagate typedef name to
anonymous aggregate target type.
Can you put some kind of pointer in the code you copied from cp/decl.c 
so that there's some chance anyone changing that code would at least go 
look at the libcpplugin.cc copy and try to DTRT.


With that.  OK for the trunk.

jeff

Re: [PATCH, testsuite]: Fix gcc.dg/unroll-7.c FAIL for x32 target

[Jeff Law]

On 04/07/2017 01:36 AM, Uros Bizjak wrote:

Hello!

Attached patch mitigates:

FAIL: gcc.dg/unroll-7.c scan-rtl-dump loop2_unroll "number of
iterations: .const_int 99"

testsuite failure for x32 target. Loop analysis determines:

Loop 1 is simple:
  simple exit 3 -> 4
  infinite if: (expr_list:REG_DEP_TRUE (ne:SI (and:SI (minus:SI
(reg:SI 106 [ _13 ])
(reg:SI 105 [ ivtmp.10 ]))
(const_int 3 [0x3]))
(const_int 0 [0]))
(nil))
  number of iterations: (lshiftrt:SI (plus:SI (minus:SI (reg:SI 106 [ _13 ])
(reg:SI 105 [ ivtmp.10 ]))
(const_int -4 [0xfffc]))
(const_int 2 [0x2]))
  upper bound: 99
  likely upper bound: 99
  realistic bound: 99

but it doesn't figure out that with (reg 105) and (reg 106), defined as:

(insn 22 19 23 2 (set (reg:SI 105 [ ivtmp.10 ])
(subreg/s/v:SI (reg/v/f:DI 110 [ a ]) 0)) 82 {*movsi_internal}
 (nil))
(insn 23 22 28 2 (parallel [
(set (reg:SI 106 [ _13 ])
(plus:SI (subreg/s/v:SI (reg/v/f:DI 110 [ a ]) 0)
(const_int 400 [0x3d0900])))
(clobber (reg:CC 17 flags))
]) 217 {*addsi_1}

(minus:SI (reg:SI 106) ( reg:SI 105)) evaluates to (const_int
400). Probably, because subregs are involved.

Short of enhancing loop analysis to properly handle subregs, I propose
following testsuite patch that avoids particularities of argument
passing.

2017-04-07  Uros Bizjak  

* gcc.dg/unroll-7.c: Declare "a" as pointer to external array.

OK.

Jeff

Re: [PR59319] output friends in debug info

[Mike Stump]

On Apr 7, 2017, at 11:32 AM, Alexandre Oliva  wrote:
> 
> On Mar 21, 2017, Alexandre Oliva  wrote:
>> 
>> Ping?  https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02112.html
> Ping?

The Objective-C/C++ parts look fine.

Re: [C++ PATCH] New warning for extra semicolons after in-class function definitions

[Mike Stump]

On Apr 9, 2017, at 1:53 PM, Volker Reichelt  wrote:
>>> +Wextra-semi
>>> +C++ Var(warn_extra_semi) Warning
>>> +Warn about semicolon after in-class function definition.
>>> +

> Right now, the patch enables the warning only for C++.
> Would it make sense to enable it also for ObjC++?

This is reversed.  Always do the exact same thing for Objective-C++ as for C++ 
(unless there is a compelling reason why not).  I don't see any reason why we 
should avoid Objective-C++ in this case.

Re: [PATCH] Add a new type attribute always_alias (PR79671)

[Jason Merrill]

On Mon, Apr 10, 2017 at 11:30 AM, Richard Biener  wrote:
> On Mon, 10 Apr 2017, Jason Merrill wrote:
>> On Mon, Apr 10, 2017 at 8:50 AM, Richard Biener  wrote:
>> > * tree.c (build_cplus_array_type): Set TYPE_TYPELESS_STORAGE
>> > for arrays of unsigned char or std::byte.
>>
>> I think it would be good to have a flag to select whether these
>> semantics apply to any char variant and std::byte, only unsigned char
>> and std::byte, or only std::byte.
>
> Any suggestion?  Not sure we really need it (I'm hesitant to write
> all the testcases to verify it actually works).

Well, there's existing code that uses plain char (e.g. boost) that I
want to support.  If there's a significant optimization penalty for
allowing that, we probably also want to be able to limit the impact.
If there isn't much penalty, let's just support all char variants.

Jason

Re: port contrib/download_prerequisites script to macOS

[Mike Stump]

On Apr 4, 2017, at 6:10 PM, Damian Rouson  wrote:
> 
> The attached patch modifies the contrib/download_prerequisites script to work 
> on macOS. 

> Ok for trunk?

Don't know if others would prefer to review...  assuming no strong feelings 
against...

Ok.

[Patch, fortran] PR69498 ICE on unexpected Submodule

[Nicolas Koenig]

Hello everyone,

Dominique send me this patch written by Paul some time ago. For some 
reason it was never committed, so here we go :)


Ok for trunk?

Nicolas

Regression tested for x86_64-pc-linux-gnu.

Changelog:
2017-03-18  Nicolas Koenig  
PR fortran/69498
* module.c (gfc_match_submodule): Add error
if function is called in the wrong state.

2017-03-18  Nicolas Koenig  
PR fortran/69498
* gfortran.dg/submodule_unexp.f90: Modified test
to account for new error.


Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c	(revision 246743)
+++ gcc/fortran/module.c	(working copy)
@@ -741,6 +741,13 @@ gfc_match_submodule (void)
   if (!gfc_notify_std (GFC_STD_F2008, "SUBMODULE declaration at %C"))
 return MATCH_ERROR;
 
+  if (gfc_current_state () != COMP_NONE)
+{
+  gfc_error ("SUBMODULE declaration at %C cannot appear within "
+		 "another scoping unit");
+  return MATCH_ERROR;
+}
+
   gfc_new_block = NULL;
   gcc_assert (module_list == NULL);
 
Index: gcc/testsuite/gfortran.dg/submodule_unexp.f90
===
--- gcc/testsuite/gfortran.dg/submodule_unexp.f90	(revision 246743)
+++ gcc/testsuite/gfortran.dg/submodule_unexp.f90	(working copy)
@@ -3,6 +3,6 @@
 ! This used to ICE
 program p
type t
-   submodule (m) sm ! { dg-error "Unexpected SUBMODULE statement at" }
+   submodule (m) sm ! { dg-error "SUBMODULE declaration at" }
end type
 end

Re: [C++ PATCH] New warning for extra semicolons after in-class function definitions

[Jason Merrill]

On Mon, Apr 10, 2017 at 12:32 PM, Mike Stump  wrote:
> On Apr 9, 2017, at 1:53 PM, Volker Reichelt  wrote:
 +Wextra-semi
 +C++ Var(warn_extra_semi) Warning
 +Warn about semicolon after in-class function definition.
 +
>
>> Right now, the patch enables the warning only for C++.
>> Would it make sense to enable it also for ObjC++?
>
> This is reversed.  Always do the exact same thing for Objective-C++ as for 
> C++ (unless there is a compelling reason why not).  I don't see any reason 
> why we should avoid Objective-C++ in this case.

Agreed.  OK with that change.

Jason

Re: [Patch, testsuite] Fix failing builtin-sprintf-warn-{3,10}.c for avr

[Mike Stump]

On Apr 6, 2017, at 5:05 AM, Senthil Kumar Selvaraj 
 wrote:
>  builtin-sprintf-warn-10.c fails because the bounds in the warning
>  messages expect 4 digit wide exponents i.e. __DBL_MAX_EXP__ > 999.
>  For the avr, floats and doubles are both 32 bits wide, __DBL_MAX_EXP__
>  == 128, and the max number of exponent digits can only be 3 .
>  The computed size thus ends up one short of the value the test
>  expects. The patch makes the test run only for targets with double64plus.

Ok.

>  builtin-sprintf-warn-3.c fails because the test appears to assume all
>  non lp64 targets to be ilp32. For the avr, pointer size and int size
>  are equal, but both are 16 bits, not 32. The patch fixes this by
>  explicitly adding avr to the dejagnu selector.

Ok.

C++ PATCH for sanitizer/80348, another ICE with -fsanitize=integer-divide-by-zero

[Marek Polacek]

I was notified that I hadn't really fixed this PR, because with this test
we were still crashing on the assert in ubsan_instrument_division.  The
problem was that ORIG_TYPE was null, so we didn't do the conversion prior
calling ubsan_instrument_division.  ORIG_TYPE was null because in this case
we weren't shortening, so fixed by always setting the original type.

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

2017-04-10  Marek Polacek  

PR sanitizer/80348
* typeck.c (cp_build_binary_op): Use NULL_TREE instead of NULL.  Set
ORIG_TYPE earlier and not only when shortening.

* g++.dg/ubsan/div-by-zero-3.C: New test.

diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index 65a3435..e756f9a 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -4105,7 +4105,7 @@ cp_build_binary_op (location_t location,
 
   /* Data type in which the computation is to be performed.
  In the simplest cases this is the common type of the arguments.  */
-  tree result_type = NULL;
+  tree result_type = NULL_TREE;
 
   /* Nonzero means operands have already been type-converted
  in whatever way is necessary.
@@ -4121,7 +4121,9 @@ cp_build_binary_op (location_t location,
   tree final_type = 0;
 
   tree result, result_ovl;
-  tree orig_type = NULL;
+
+  /* The type to be used for diagnostic.  */
+  tree orig_type;
 
   /* Nonzero if this is an operation like MIN or MAX which can
  safely be computed in short if both args are promoted shorts.
@@ -4153,7 +4155,7 @@ cp_build_binary_op (location_t location,
   bool doing_shift = false;
 
   /* Tree holding instrumentation expression.  */
-  tree instrument_expr = NULL;
+  tree instrument_expr = NULL_TREE;
 
   if (code == TRUTH_AND_EXPR || code == TRUTH_ANDIF_EXPR
   || code == TRUTH_OR_EXPR || code == TRUTH_ORIF_EXPR
@@ -5042,6 +5044,10 @@ cp_build_binary_op (location_t location,
   return tmp;
 }
 
+  /* Remember the original type; RESULT_TYPE might be changed later on
+ by shorten_binary_op.  */
+  orig_type = result_type;
+
   if (arithmetic_types_p)
 {
   bool first_complex = (code0 == COMPLEX_TYPE);
@@ -5138,7 +5144,6 @@ cp_build_binary_op (location_t location,
 
   if (shorten && none_complex)
{
- orig_type = result_type;
  final_type = result_type;
  result_type = shorten_binary_op (result_type, op0, op1,
   shorten == -1);
@@ -5218,13 +5223,10 @@ cp_build_binary_op (location_t location,
 original result_type.  */
  tree cop0 = op0;
  tree cop1 = op1;
- if (orig_type != NULL_TREE)
-   {
- if (TREE_TYPE (cop0) != orig_type)
-   cop0 = cp_convert (orig_type, op0, complain);
- if (TREE_TYPE (cop1) != orig_type)
-   cop1 = cp_convert (orig_type, op1, complain);
-   }
+ if (TREE_TYPE (cop0) != orig_type)
+   cop0 = cp_convert (orig_type, op0, complain);
+ if (TREE_TYPE (cop1) != orig_type)
+   cop1 = cp_convert (orig_type, op1, complain);
  instrument_expr = ubsan_instrument_division (location, cop0, cop1);
}
   else if (doing_shift && (flag_sanitize & SANITIZE_SHIFT))
diff --git gcc/testsuite/g++.dg/ubsan/div-by-zero-3.C 
gcc/testsuite/g++.dg/ubsan/div-by-zero-3.C
index e69de29..589dd25 100644
--- gcc/testsuite/g++.dg/ubsan/div-by-zero-3.C
+++ gcc/testsuite/g++.dg/ubsan/div-by-zero-3.C
@@ -0,0 +1,22 @@
+// PR sanitizer/80348
+// { dg-do compile }
+// { dg-options "-fsanitize=integer-divide-by-zero" }
+
+extern long long int i;
+void
+fn1 ()
+{
+  (0 >= 10253361740180 >= long (0 >= 0)) % i;
+}
+
+void
+fn2 ()
+{
+  0 / unsigned (!(0 - 3) >= (0 > 0));
+}
+
+void
+fn3 ()
+{
+  (0 < 0 >= (0 < 0 < 0)) % (unsigned (2) << 0);
+}

Marek

Re: C++ PATCH for sanitizer/80348, another ICE with -fsanitize=integer-divide-by-zero

[Jakub Jelinek]

On Mon, Apr 10, 2017 at 06:55:07PM +0200, Marek Polacek wrote:
> 2017-04-10  Marek Polacek  
> 
>   PR sanitizer/80348
>   * typeck.c (cp_build_binary_op): Use NULL_TREE instead of NULL.  Set
>   ORIG_TYPE earlier and not only when shortening.
> 
>   * g++.dg/ubsan/div-by-zero-3.C: New test.
> 
> diff --git gcc/cp/typeck.c gcc/cp/typeck.c
> index 65a3435..e756f9a 100644
> --- gcc/cp/typeck.c
> +++ gcc/cp/typeck.c
> @@ -4105,7 +4105,7 @@ cp_build_binary_op (location_t location,
>  
>/* Data type in which the computation is to be performed.
>   In the simplest cases this is the common type of the arguments.  */
> -  tree result_type = NULL;
> +  tree result_type = NULL_TREE;
>  
>/* Nonzero means operands have already been type-converted
>   in whatever way is necessary.
> @@ -4121,7 +4121,9 @@ cp_build_binary_op (location_t location,
>tree final_type = 0;
>  
>tree result, result_ovl;
> -  tree orig_type = NULL;
> +
> +  /* The type to be used for diagnostic.  */
> +  tree orig_type;

Can't you define orig_type instead:

>/* Nonzero if this is an operation like MIN or MAX which can
>   safely be computed in short if both args are promoted shorts.
> @@ -4153,7 +4155,7 @@ cp_build_binary_op (location_t location,
>bool doing_shift = false;
>  
>/* Tree holding instrumentation expression.  */
> -  tree instrument_expr = NULL;
> +  tree instrument_expr = NULL_TREE;
>  
>if (code == TRUTH_AND_EXPR || code == TRUTH_ANDIF_EXPR
>|| code == TRUTH_OR_EXPR || code == TRUTH_ORIF_EXPR
> @@ -5042,6 +5044,10 @@ cp_build_binary_op (location_t location,
>return tmp;
>  }
>  
> +  /* Remember the original type; RESULT_TYPE might be changed later on
> + by shorten_binary_op.  */
> +  orig_type = result_type;

here?  tree orig_type = result_type;
Ok with that change.

> +
>if (arithmetic_types_p)
>  {
>bool first_complex = (code0 == COMPLEX_TYPE);
> @@ -5138,7 +5144,6 @@ cp_build_binary_op (location_t location,
>  
>if (shorten && none_complex)
>   {
> -   orig_type = result_type;
> final_type = result_type;
> result_type = shorten_binary_op (result_type, op0, op1,
>  shorten == -1);
> @@ -5218,13 +5223,10 @@ cp_build_binary_op (location_t location,
>original result_type.  */
> tree cop0 = op0;
> tree cop1 = op1;
> -   if (orig_type != NULL_TREE)
> - {
> -   if (TREE_TYPE (cop0) != orig_type)
> - cop0 = cp_convert (orig_type, op0, complain);
> -   if (TREE_TYPE (cop1) != orig_type)
> - cop1 = cp_convert (orig_type, op1, complain);
> - }
> +   if (TREE_TYPE (cop0) != orig_type)
> + cop0 = cp_convert (orig_type, op0, complain);
> +   if (TREE_TYPE (cop1) != orig_type)
> + cop1 = cp_convert (orig_type, op1, complain);

Other option would be to use instead of orig_type here
orig_type ? orig_type : result_type, but I agree your patch looks
better than that and orig_type is used solely for the ubsan
instrumentation.

Jakub

[PATCH, rs6000] Fix PR80376 (somewhat)

[Bill Schmidt]

Hi,

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80376 shows an ICE on invalid
code when using certain flavors of the vec_xxpermdi intrinsic.  The root
cause is that we were not checking the parameter for a legal value, and an
illegal value was being provided by the user (only an integer constant is
permissible for argument 3).

However, this brings up a slightly larger problem, in that the invalid
vec_xxpermdi call is nested within another call.  We have a lot of cases
in rs6000.c where we signal an error message and replace the offending
construct with a const0_rtx.  In this case, that const0_rtx was being used
as a vector argument to another call, leading to a follow-up ICE that is
not easy to parse.

The fix for the root problem is just to add some missing cases to existing
error checking.  To help reduce the mystery of the follow-up ICE, I added
some logic to the vector move pattern in vector.md to check for a scalar
constant being used in a vector context, and forced an ICE with an
explanatory message at that point.  The results look like this:

wschmidt@pike:~/src$ $GCC_INSTALL/bin/gcc pr80376.c 
pr80376.c: In function 'main':
pr80376.c:12:5: error: argument 3 must be a 2-bit unsigned literal
 vec_vsx_st(vec_xxpermdi(a, b, j), 0, c);
 ^~
pr80376.c:12:5: internal compiler error: non-vector constant found where vector 
expected
0x116cde0b gen_movv4si(rtx_def*, rtx_def*)
/home/wschmidt/gcc/gcc-mainline-test/gcc/config/rs6000/vector.md:114
0x105fd113 insn_gen_fn::operator()(rtx_def*, rtx_def*) const
/home/wschmidt/gcc/gcc-mainline-test/gcc/recog.h:301
0x1077a497 emit_move_insn_1(rtx_def*, rtx_def*)
/home/wschmidt/gcc/gcc-mainline-test/gcc/expr.c:3643
0x1077ab37 emit_move_insn(rtx_def*, rtx_def*)
/home/wschmidt/gcc/gcc-mainline-test/gcc/expr.c:3738
0x107826d3 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool, 
tree_node*)
/home/wschmidt/gcc/gcc-mainline-test/gcc/expr.c:5729
0x107802a3 expand_assignment(tree_node*, tree_node*, bool)
/home/wschmidt/gcc/gcc-mainline-test/gcc/expr.c:5321
0x1056ec0b expand_call_stmt
/home/wschmidt/gcc/gcc-mainline-test/gcc/cfgexpand.c:2656
0x10572b87 expand_gimple_stmt_1
/home/wschmidt/gcc/gcc-mainline-test/gcc/cfgexpand.c:3571
0x105734c3 expand_gimple_stmt
/home/wschmidt/gcc/gcc-mainline-test/gcc/cfgexpand.c:3737
0x1057cd03 expand_gimple_basic_block
/home/wschmidt/gcc/gcc-mainline-test/gcc/cfgexpand.c:5744
0x1057ef3b execute
/home/wschmidt/gcc/gcc-mainline-test/gcc/cfgexpand.c:6357
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I think this is the best way to handle this for stage 4.  At some point
we should review our error handling and see whether we can produce
better replacement values than const0_rtx, that won't immediately ICE 
when used in a call argument context.  This seems like too much churn
for late stage 4.

I've also fixed the documentation to clarify that the third argument
to vec_xxpermdi must be a constant.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions.  Is this ok for trunk, and eventual backport to GCC 6?

Thanks,
Bill


2017-04-10  Bill Schmidt  

PR target/80376
* config/rs6000/rs6000.c (rs6000_expand_ternop_builtin): Add
missing vsx_xxpermdi_* variants.
* config/rs6000/vector.md (mov): Add pre-emptive ICE when a
non-vector constant is used in a vector context.
* doc/extend.texi: Document that vec_xxpermdi's third argument
must be a constant.


Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 246804)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -15586,6 +15586,11 @@ rs6000_expand_ternop_builtin (enum insn_code icode
|| icode == CODE_FOR_vsx_xxpermdi_v2di
|| icode == CODE_FOR_vsx_xxpermdi_v2df_be
|| icode == CODE_FOR_vsx_xxpermdi_v2di_be
+  || icode == CODE_FOR_vsx_xxpermdi_v1ti
+  || icode == CODE_FOR_vsx_xxpermdi_v4sf
+  || icode == CODE_FOR_vsx_xxpermdi_v4si
+  || icode == CODE_FOR_vsx_xxpermdi_v8hi
+  || icode == CODE_FOR_vsx_xxpermdi_v16qi
|| icode == CODE_FOR_vsx_xxsldwi_v16qi
|| icode == CODE_FOR_vsx_xxsldwi_v8hi
|| icode == CODE_FOR_vsx_xxsldwi_v4si
Index: gcc/config/rs6000/vector.md
===
--- gcc/config/rs6000/vector.md (revision 246804)
+++ gcc/config/rs6000/vector.md (working copy)
@@ -109,6 +109,11 @@
 {
   if (CONSTANT_P (operands[1]))
{
+ /* Handle cascading error conditions.  */
+ if (VECTOR_MODE_P (mode)
+ && !VECTOR_MODE_P (GET_MODE (operands[1])))
+   internal_error ("non-vector cons

Re: C++ PATCH for sanitizer/80348, another ICE with -fsanitize=integer-divide-by-zero

[Marek Polacek]

On Mon, Apr 10, 2017 at 07:02:04PM +0200, Jakub Jelinek wrote:
> On Mon, Apr 10, 2017 at 06:55:07PM +0200, Marek Polacek wrote:
> > 2017-04-10  Marek Polacek  
> > 
> > PR sanitizer/80348
> > * typeck.c (cp_build_binary_op): Use NULL_TREE instead of NULL.  Set
> > ORIG_TYPE earlier and not only when shortening.
> > 
> > * g++.dg/ubsan/div-by-zero-3.C: New test.
> > 
> > diff --git gcc/cp/typeck.c gcc/cp/typeck.c
> > index 65a3435..e756f9a 100644
> > --- gcc/cp/typeck.c
> > +++ gcc/cp/typeck.c
> > @@ -4105,7 +4105,7 @@ cp_build_binary_op (location_t location,
> >  
> >/* Data type in which the computation is to be performed.
> >   In the simplest cases this is the common type of the arguments.  */
> > -  tree result_type = NULL;
> > +  tree result_type = NULL_TREE;
> >  
> >/* Nonzero means operands have already been type-converted
> >   in whatever way is necessary.
> > @@ -4121,7 +4121,9 @@ cp_build_binary_op (location_t location,
> >tree final_type = 0;
> >  
> >tree result, result_ovl;
> > -  tree orig_type = NULL;
> > +
> > +  /* The type to be used for diagnostic.  */
> > +  tree orig_type;
> 
> Can't you define orig_type instead:
> 
> >/* Nonzero if this is an operation like MIN or MAX which can
> >   safely be computed in short if both args are promoted shorts.
> > @@ -4153,7 +4155,7 @@ cp_build_binary_op (location_t location,
> >bool doing_shift = false;
> >  
> >/* Tree holding instrumentation expression.  */
> > -  tree instrument_expr = NULL;
> > +  tree instrument_expr = NULL_TREE;
> >  
> >if (code == TRUTH_AND_EXPR || code == TRUTH_ANDIF_EXPR
> >|| code == TRUTH_OR_EXPR || code == TRUTH_ORIF_EXPR
> > @@ -5042,6 +5044,10 @@ cp_build_binary_op (location_t location,
> >return tmp;
> >  }
> >  
> > +  /* Remember the original type; RESULT_TYPE might be changed later on
> > + by shorten_binary_op.  */
> > +  orig_type = result_type;
> 
> here?  tree orig_type = result_type;

Absolutely.

> Ok with that change.

Thanks.  I'll check this in.

2017-04-10  Marek Polacek  

PR sanitizer/80348
* typeck.c (cp_build_binary_op): Use NULL_TREE instead of NULL.  Set
ORIG_TYPE earlier and not only when shortening.

* g++.dg/ubsan/div-by-zero-3.C: New test.

diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index 65a3435..7aee0d6 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -4105,7 +4105,7 @@ cp_build_binary_op (location_t location,
 
   /* Data type in which the computation is to be performed.
  In the simplest cases this is the common type of the arguments.  */
-  tree result_type = NULL;
+  tree result_type = NULL_TREE;
 
   /* Nonzero means operands have already been type-converted
  in whatever way is necessary.
@@ -4121,7 +4121,6 @@ cp_build_binary_op (location_t location,
   tree final_type = 0;
 
   tree result, result_ovl;
-  tree orig_type = NULL;
 
   /* Nonzero if this is an operation like MIN or MAX which can
  safely be computed in short if both args are promoted shorts.
@@ -4153,7 +4152,7 @@ cp_build_binary_op (location_t location,
   bool doing_shift = false;
 
   /* Tree holding instrumentation expression.  */
-  tree instrument_expr = NULL;
+  tree instrument_expr = NULL_TREE;
 
   if (code == TRUTH_AND_EXPR || code == TRUTH_ANDIF_EXPR
   || code == TRUTH_OR_EXPR || code == TRUTH_ORIF_EXPR
@@ -5042,6 +5041,10 @@ cp_build_binary_op (location_t location,
   return tmp;
 }
 
+  /* Remember the original type; RESULT_TYPE might be changed later on
+ by shorten_binary_op.  */
+  tree orig_type = result_type;
+
   if (arithmetic_types_p)
 {
   bool first_complex = (code0 == COMPLEX_TYPE);
@@ -5138,7 +5141,6 @@ cp_build_binary_op (location_t location,
 
   if (shorten && none_complex)
{
- orig_type = result_type;
  final_type = result_type;
  result_type = shorten_binary_op (result_type, op0, op1,
   shorten == -1);
@@ -5218,13 +5220,10 @@ cp_build_binary_op (location_t location,
 original result_type.  */
  tree cop0 = op0;
  tree cop1 = op1;
- if (orig_type != NULL_TREE)
-   {
- if (TREE_TYPE (cop0) != orig_type)
-   cop0 = cp_convert (orig_type, op0, complain);
- if (TREE_TYPE (cop1) != orig_type)
-   cop1 = cp_convert (orig_type, op1, complain);
-   }
+ if (TREE_TYPE (cop0) != orig_type)
+   cop0 = cp_convert (orig_type, op0, complain);
+ if (TREE_TYPE (cop1) != orig_type)
+   cop1 = cp_convert (orig_type, op1, complain);
  instrument_expr = ubsan_instrument_division (location, cop0, cop1);
}
   else if (doing_shift && (flag_sanitize & SANITIZE_SHIFT))
diff --git gcc/testsuite/g++.dg/ubsan/div-by-zero-3.C 
gcc/testsuite/g++.dg/ubsan/div-by-zero-3.C
index e69de29..589dd25 100644
--- gcc/testsuite/g++.dg/ubsan/div-by-zero-3.C
+

Re: [PATCH] PR80101: Fix ICE in store_data_bypass_p

[Richard Sandiford]

Segher Boessenkool  writes:
> On Fri, Apr 07, 2017 at 10:39:03AM +0200, Eric Botcazou wrote:
>> > Or we could just change "blockage" and wait for the next bug report.
>> 
>> That's my suggestion, yes.
>> 
>> > Alternatively, we can arrange for the bypass functions to not ICE.  We
>> > can do that specific to these rs6000 pipeline descriptions, by having
>> > our own version of store_data_bypass_p; or we can make that function
>> > work for all insns (its definition works fine for insn pairs where
>> > not both the producer and consumer are SETs).  That's what Kelvin's
>> > patch does.  What is the value in ICEing here?
>> 
>> Telling the back-end writer that something may be wrong somewhere instead of 
>> silently accepting nonsense?
>
> Why is it nonsense?  The predicate gives the answer to the question
> "given these insns A and B, does A feed data that B stores in memory".
> That is a perfectly valid question to ask of any two insns.

Agreed FWIW, but for:

@@ -3701,7 +3704,8 @@ store_data_bypass_p (rtx_insn *out_insn, rtx_insn
 if (GET_CODE (out_exp) == CLOBBER)
   continue;

-gcc_assert (GET_CODE (out_exp) == SET);
+   if (GET_CODE (out_exp) != SET)
+ return false;

 if (reg_mentioned_p (SET_DEST (out_exp), SET_DEST (in_set)))
   return false;

how about instead changing the CLOBBER check so that we continue
when it isn't a SET?  That would allow things like UNSPECs and
USEs as well.

Thanks,
Richard

Re: [PATCH v2,testsuite] PR79867: Merge fixes for windows DLL loading problem from libffi

[Mike Stump]

On Apr 6, 2017, at 3:40 PM, Daniel Santos  wrote:
> This patch merges the changes from libffi upstream which correctly solve
> the Windows DLL load path problem in set_ld_library_path_env_vars and
> restore_ld_library_path_env_vars, thus fixing most PR79867.

Ok.

I checked it in for you, after stubbing in a ChangeLog entry for it.

Re: [Patch, fortran] PR69498 ICE on unexpected Submodule

[Nicolas Koenig]

Hello again,

I forgot to add the test case this patch fixes and to give Paul the 
credit. Attached the new test case.


Nicolas

New & improved changelog:

2017-04-10  Nicolas Koenig  
Paul Thomas  
PR fortran/69498
* module.c (gfc_match_submodule): Add error
if function is called in the wrong state.

2017-04-10  Nicolas Koenig  
PR fortran/69498
* gfortran.dg/submodule_unexp.f90: Modified test
to account for new error.
* gfortran.dg/submodule_twice.f90: New Test


On 04/10/2017 06:53 PM, Nicolas Koenig wrote:

Hello everyone,

Dominique send me this patch written by Paul some time ago. For some 
reason it was never committed, so here we go :)


Ok for trunk?

Nicolas

Regression tested for x86_64-pc-linux-gnu.

Changelog:
2017-03-18  Nicolas Koenig  
PR fortran/69498
* module.c (gfc_match_submodule): Add error
if function is called in the wrong state.

2017-03-18  Nicolas Koenig  
PR fortran/69498
* gfortran.dg/submodule_unexp.f90: Modified test
to account for new error.




! { dg-do compile }
! PR fortran/69498
! This used to ICE
program main
submodule (m) sm ! { dg-error "SUBMODULE declaration at" }
submodule (m2) sm2  ! { dg-error "SUBMODULE declaration at" }
end program

Re: [Patch, fortran] PR69498 ICE on unexpected Submodule

[Paul Richard Thomas]

Dear Nicolas,

The reasons are (i) moving country and (ii) the daytime job :-)

I think that in the circumstances somebody else should OK the patch,
although I think that it is perfect in every way possible.

Actually, perhaps it is sufficiently obvious that I would and should
have committed it - OK for trunk.

Thanks

Paul


On 10 April 2017 at 17:53, Nicolas Koenig  wrote:
> Hello everyone,
>
> Dominique send me this patch written by Paul some time ago. For some reason
> it was never committed, so here we go :)
>
> Ok for trunk?
>
> Nicolas
>
> Regression tested for x86_64-pc-linux-gnu.
>
> Changelog:
> 2017-03-18  Nicolas Koenig  
> PR fortran/69498
> * module.c (gfc_match_submodule): Add error
> if function is called in the wrong state.
>
> 2017-03-18  Nicolas Koenig  
> PR fortran/69498
> * gfortran.dg/submodule_unexp.f90: Modified test
> to account for new error.
>
>



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

[PING][PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace

[Denis Khalikov]

Hello everyone,

this is a ping for

https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01171.html

[P1] [PATCH] [PR tree-optimization/80374] Do not try to convert integer_zero_node to undesirable types

[Jeff Law]

fold_convert can fail for certain types.  It can fail either by 
returning a error_mark_node or triggering a gcc_assert depending on the 
exact situation.


Both are problematical.  This patch checks that we can convert 
integer_zero_node to the proper type before calling fold_convert.


Bootstrapped and regression tested on x86_64.  Installing on the trunk.

Jeff
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 6edad21..7db5359 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2017-04-10  Jeff Law  
+
+   PR tree-optimization/80374
+   * tree-ssa-dom.c (derive_equivalences_from_bit_ior): Do not try to
+   record anything if we can not convert integer_zero_node to the
+   desired type.
+
 2017-04-10  Bin Cheng  
 
PR tree-optimization/80153
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index b87d0ee..6ed3c99 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2017-04-10  Jeff Law  
+
+   PR tree-optimization/80374
+   * g++.dg/pr80374.c: New test.
+
 2017-04-10  Daniel Santos 
 
PR testsuite/79867
diff --git a/gcc/testsuite/g++.dg/pr80374.C b/gcc/testsuite/g++.dg/pr80374.C
new file mode 100644
index 000..b02b656
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr80374.C
@@ -0,0 +1,19 @@
+void a (const char *, const char *, int, const char *)
+  __attribute__ ((__noreturn__));
+template 
+void
+c () try
+  {
+throw;
+  }
+catch (b d)
+  {
+if (d)
+  a ("", "", 2, __PRETTY_FUNCTION__);
+  }
+main ()
+{
+  using e = decltype (nullptr);
+  c ();
+}
+
diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index d2263bb..d9e5942 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -701,7 +701,8 @@ derive_equivalences_from_bit_ior (tree name,
  const_and_copies *const_and_copies,
  int recursion_limit)
 {
-  if (recursion_limit == 0)
+  if (recursion_limit == 0
+  || !fold_convertible_p (TREE_TYPE (name), integer_zero_node))
 return;
 
   if (TREE_CODE (name) == SSA_NAME)

Re: [Patch, Fortran, F03] PR 80046: Explicit interface required: pointer argument

[Janus Weil]

Thanks, Paul. Committed as r246823.

Cheers,
Janus



2017-04-09 12:40 GMT+02:00 Paul Richard Thomas :
> Hi Janus,
>
> The patch is OK for trunk.
>
> Thanks
>
> Paul
>
>
> On 7 April 2017 at 17:51, Janus Weil  wrote:
>> ping!
>>
>> 2017-03-29 22:25 GMT+02:00 Janus Weil :
>>> Hi all,
>>>
>>> here is a patch that enhances the diagnostics for procedure-pointer
>>> assignments, so that procedure-pointer components that need an
>>> explicit interface are correctly rejected.
>>>
>>> Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
>>>
>>> Cheers,
>>> Janus
>>>
>>>
>>> 2017-03-29  Janus Weil  
>>>
>>> PR fortran/80046
>>> * expr.c (gfc_check_pointer_assign): Check if procedure pointer
>>> components in a pointer assignment need an explicit interface.
>>>
>>> 2017-03-29  Janus Weil  
>>>
>>> PR fortran/80046
>>> * gfortran.dg/proc_ptr_comp_48.f90: New test case.
>
>
>
> --
> "If you can't explain it simply, you don't understand it well enough"
> - Albert Einstein

[C++ PATCH] Fix ICE when dumping VEC_COND_EXPR (PR c++/80363)

[Jakub Jelinek]

Hi!

The following testcase emits vec_cond_expr not supported by dump_expr
inside of error message.

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

2017-04-10  Jakub Jelinek  

PR c++/80363
* error.c (dump_expr): Handle VEC_COND_EXPR like COND_EXPR.

* g++.dg/ext/pr80363.C: New test.

--- gcc/cp/error.c.jj   2017-02-09 23:01:49.0 +0100
+++ gcc/cp/error.c  2017-04-08 09:30:54.417681285 +0200
@@ -2080,6 +2080,7 @@ dump_expr (cxx_pretty_printer *pp, tree
   break;
 
 case COND_EXPR:
+case VEC_COND_EXPR:
   pp_cxx_left_paren (pp);
   dump_expr (pp, TREE_OPERAND (t, 0), flags | TFF_EXPR_IN_PARENS);
   pp_string (pp, " ? ");
--- gcc/testsuite/g++.dg/ext/pr80363.C.jj   2017-04-08 09:33:59.134213656 
+0200
+++ gcc/testsuite/g++.dg/ext/pr80363.C  2017-04-08 09:33:20.0 +0200
@@ -0,0 +1,12 @@
+// PR c++/80363
+// { dg-do compile }
+
+typedef int V __attribute__((vector_size (16)));
+
+int
+foo (V *a, V *b)
+{
+  if (*a < *b) // { dg-error "could not convert\[^#]*from" }
+return 1;
+  return 0;
+}

Jakub

[C++ PATCH] Fix decomp ICEs in templates (PR c++/80370)

[Jakub Jelinek]

Hi!

The following testcase ICEs, because when cp_finish_decomp is called
during parsing with processing_template_decl, but decl is not type
dependent, we finalize it at that point and when we try to do it again
during tsubst time, it doesn't find the expected trees (e.g. DECL_VALUE_EXPR
of the expected form on the corresponding user decls).

The following patch changes cp_finish_decomp processing_template_decl
handling when decl is not type dependent, such that it performs diagnostics
and sets types on the individual decls, but doesn't otherwise finalize them
(modify their DECL_VALUE_EXPR or clear them and cp_finish_decl them).

I think this way we can treat the decls as no longer type dependent, but
will let the final decomp finalization still to tsubst time.

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

2017-04-10  Jakub Jelinek  

PR c++/80370
* decl.c (cp_finish_decomp): If processing_template_decl on
non-dependent decl, only set TREE_TYPE on the v[i] decls, but don't
change their DECL_VALUE_EXPR nor cp_finish_decl them.  Instead make
sure DECL_VALUE_EXPR is the canonical NULL type ARRAY_REF for tsubst
processing.
* constexpr.c (cxx_eval_constant_expression) : Don't
recurse on DECL_VALUE_EXPR if the value expr has NULL type on a
decomposition decl.

* g++.dg/cpp1z/decomp28.C: New test.

--- gcc/cp/decl.c.jj2017-03-30 15:24:22.0 +0200
+++ gcc/cp/decl.c   2017-04-10 12:15:44.156022403 +0200
@@ -7473,6 +7473,8 @@ cp_finish_decomp (tree decl, tree first,
{
  TREE_TYPE (v[i]) = eltype;
  layout_decl (v[i], 0);
+ if (processing_template_decl)
+   continue;
  tree t = unshare_expr (dexp);
  t = build4_loc (DECL_SOURCE_LOCATION (v[i]), ARRAY_REF,
  eltype, t, size_int (i), NULL_TREE,
@@ -7492,6 +7494,8 @@ cp_finish_decomp (tree decl, tree first,
{
  TREE_TYPE (v[i]) = eltype;
  layout_decl (v[i], 0);
+ if (processing_template_decl)
+   continue;
  tree t = unshare_expr (dexp);
  t = build1_loc (DECL_SOURCE_LOCATION (v[i]),
  i ? IMAGPART_EXPR : REALPART_EXPR, eltype,
@@ -7510,6 +7514,8 @@ cp_finish_decomp (tree decl, tree first,
{
  TREE_TYPE (v[i]) = eltype;
  layout_decl (v[i], 0);
+ if (processing_template_decl)
+   continue;
  tree t = unshare_expr (dexp);
  convert_vector_to_array_for_subscript (DECL_SOURCE_LOCATION (v[i]),
 &t, size_int (i));
@@ -7549,7 +7555,8 @@ cp_finish_decomp (tree decl, tree first,
  goto error_out;
}
  /* Save the decltype away before reference collapse.  */
- store_decomp_type (v[i], eltype);
+ if (!processing_template_decl)
+   store_decomp_type (v[i], eltype);
  eltype = cp_build_reference_type (eltype, !lvalue_p (init));
  TREE_TYPE (v[i]) = eltype;
  layout_decl (v[i], 0);
@@ -7559,8 +7566,9 @@ cp_finish_decomp (tree decl, tree first,
  SET_DECL_VALUE_EXPR (v[i], NULL_TREE);
  DECL_HAS_VALUE_EXPR_P (v[i]) = 0;
}
- cp_finish_decl (v[i], init, /*constexpr*/false,
- /*asm*/NULL_TREE, LOOKUP_NORMAL);
+ if (!processing_template_decl)
+   cp_finish_decl (v[i], init, /*constexpr*/false,
+   /*asm*/NULL_TREE, LOOKUP_NORMAL);
}
 }
   else if (TREE_CODE (type) == UNION_TYPE)
@@ -7615,12 +7623,26 @@ cp_finish_decomp (tree decl, tree first,
  tt = TREE_OPERAND (tt, 0);
TREE_TYPE (v[i]) = TREE_TYPE (tt);
layout_decl (v[i], 0);
-   SET_DECL_VALUE_EXPR (v[i], tt);
-   DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
+   if (!processing_template_decl)
+ {
+   SET_DECL_VALUE_EXPR (v[i], tt);
+   DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
+ }
i++;
  }
 }
-  if (DECL_NAMESPACE_SCOPE_P (decl))
+  if (processing_template_decl)
+{
+  for (unsigned int i = 0; i < count; i++)
+   if (!DECL_HAS_VALUE_EXPR_P (v[i]))
+ {
+   tree a = build_nt (ARRAY_REF, decl, size_int (i),
+  NULL_TREE, NULL_TREE);
+   SET_DECL_VALUE_EXPR (v[i], a);
+   DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
+ }
+}
+  else if (DECL_NAMESPACE_SCOPE_P (decl))
 SET_DECL_ASSEMBLER_NAME (decl, mangle_decomp (decl, v));
 }
 
--- gcc/cp/constexpr.c.jj   2017-03-21 07:57:00.0 +0100
+++ gcc/cp/constexpr.c  2017-04-10 12:24:11.849717112 +0200
@@ -3935,7 +3935,10 @@ cxx_eval_constant_expression (const cons
   return (*ctx->values->get (t));
 
 case VAR_DECL:
-  if (DECL_HAS_VALUE_EXPR_P (t))
+  if (DECL_HAS_VALUE_EXPR_P (t)
+ /* Don't recurse on DE

[PATCH] Partially revert undesirable widest literal type changes from 1999 (PR middle-end/79788, PR middle-end/80375)

[Jakub Jelinek]

Hi!

The http://gcc.gnu.org/ml/gcc-patches/1999-07/msg00031.html change
appears to be IMHO highly undesirable loophole around the lack of
TImode support on 32-bit targets.  Those targets return
false from targetm.scalar_mode_supported_p (TImode) for a reason,
while for some arithmetics operation perhaps the middle-end manages
to emit something that doesn't ICE, as the following testcases shows
there are various other cases which just ICE.
While the 32-bit targets don't support __int128/__int128_t/__uint128_t,
because of the above change one can use instead
__typeof (1234567891234567891234567891234567812) or similar constructs
to get variables of that type and similarly expressions can still have
the 128-bit type, but as can be seen we don't really support those.

Thus, this patch reverts the effect of the above patch for 32-bit targets,
basically the type of the oversized literals is now __int128_t/__uint128_t
on 64-bit targets as before, but only long long/unsigned long long on
32-bit targets.  While this is an ABI change, it affects only code on which
we emit pedwarn, so I'd think it is unlikely to be used in the wild.

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

2017-04-10  Jakub Jelinek  

PR middle-end/79788
PR middle-end/80375
* c-common.c (c_common_type_for_mode): Don't handle
widest_*_literal_type_node here.
c_common_signed_or_unsigned_type): Likewise.
(c_common_nodes_and_builtins): Set widest_*_literal_type_node
to *intTI_type_node or *intDI_type_node depending on whether
TImode is supported by the target or not.

* gcc.dg/pr79788-1.c: New test.
* gcc.dg/pr79788-2.c: New test.

--- gcc/c-family/c-common.c.jj  2017-03-31 08:39:08.0 +0200
+++ gcc/c-family/c-common.c 2017-04-10 13:29:10.691179060 +0200
@@ -2179,10 +2179,6 @@ c_common_type_for_mode (machine_mode mod
   return (unsignedp ? int_n_trees[i].unsigned_type
  : int_n_trees[i].signed_type);
 
-  if (mode == TYPE_MODE (widest_integer_literal_type_node))
-return unsignedp ? widest_unsigned_literal_type_node
-: widest_integer_literal_type_node;
-
   if (mode == QImode)
 return unsignedp ? unsigned_intQI_type_node : intQI_type_node;
 
@@ -2412,8 +2408,6 @@ c_common_signed_or_unsigned_type (int un
   return (unsignedp ? int_n_trees[i].unsigned_type
  : int_n_trees[i].signed_type);
 
-  if (type1 == widest_integer_literal_type_node || type1 == 
widest_unsigned_literal_type_node)
-return unsignedp ? widest_unsigned_literal_type_node : 
widest_integer_literal_type_node;
 #if HOST_BITS_PER_WIDE_INT >= 64
   if (type1 == intTI_type_node || type1 == unsigned_intTI_type_node)
 return unsignedp ? unsigned_intTI_type_node : intTI_type_node;
@@ -2534,10 +2528,6 @@ c_common_signed_or_unsigned_type (int un
   return (unsignedp ? int_n_trees[i].unsigned_type
  : int_n_trees[i].signed_type);
 
-  if (TYPE_OK (widest_integer_literal_type_node))
-return (unsignedp ? widest_unsigned_literal_type_node
-   : widest_integer_literal_type_node);
-
 #if HOST_BITS_PER_WIDE_INT >= 64
   if (TYPE_OK (intTI_type_node))
 return unsignedp ? unsigned_intTI_type_node : intTI_type_node;
@@ -4164,17 +4154,16 @@ c_common_nodes_and_builtins (void)
 #endif
 
   /* Create the widest literal types.  */
-  widest_integer_literal_type_node
-= make_signed_type (HOST_BITS_PER_WIDE_INT * 2);
-  lang_hooks.decls.pushdecl (build_decl (UNKNOWN_LOCATION,
-TYPE_DECL, NULL_TREE,
-widest_integer_literal_type_node));
-
-  widest_unsigned_literal_type_node
-= make_unsigned_type (HOST_BITS_PER_WIDE_INT * 2);
-  lang_hooks.decls.pushdecl (build_decl (UNKNOWN_LOCATION,
-TYPE_DECL, NULL_TREE,
-widest_unsigned_literal_type_node));
+  if (targetm.scalar_mode_supported_p (TImode))
+{
+  widest_integer_literal_type_node = intTI_type_node;
+  widest_unsigned_literal_type_node = unsigned_intTI_type_node;
+}
+  else
+{
+  widest_integer_literal_type_node = intDI_type_node;
+  widest_unsigned_literal_type_node = unsigned_intDI_type_node;
+}
 
   signed_size_type_node = c_common_signed_type (size_type_node);
 
--- gcc/testsuite/gcc.dg/pr79788-1.c.jj 2017-04-10 13:58:33.399248477 +0200
+++ gcc/testsuite/gcc.dg/pr79788-1.c2017-04-10 13:59:17.980699210 +0200
@@ -0,0 +1,11 @@
+/* PR middle-end/79788 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+long long
+foo (long long x, long long y)
+{
+  if (y > 1234567891234567891234567891234567812 / x)   /* { dg-warning 
"integer constant is too large for its type" } */
+return x;
+  return 0;
+}
--- gcc/testsuite/gcc.dg/pr79788-2.c.jj 2017-04-10 13:58:37.171202004 +0200
+++ gcc/testsuite/gcc.dg/pr79788-2.c2017-04-10 13:57:33.0 +0200

[PATCH] Handle AVX512* 4 argument shift builtins similarly to 2 argument shift builtins (PR target/80381)

[Jakub Jelinek]

Hi!

As mentioned in the PR, apparently we have some specific handling for
the MMX/SSE/AVX2 shift builtins with *_COUNT function type aliases,
where the count argument (last == second) is not really required to be
constant e.g. for the srai/srli/slli builtins, and is converted as needed.

This patch adds similar handling also to the AVX512* 4 argument shifts
where the count is 2nd argument, followed by value for masked off elts
and mask.  While the intrinsic docs are ambiguous on if they allow
non-constant immediates or not, apparently what ICC implements matches
what we do for the 2 arg builtins.

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

2017-04-10  Jakub Jelinek  

PR target/80381
* config/i386/i386-builtin-types.def
(V16HI_FTYPE_V16HI_INT_V16HI_UHI_COUNT,
V16HI_FTYPE_V16HI_V8HI_V16HI_UHI_COUNT,
V16SI_FTYPE_V16SI_INT_V16SI_UHI_COUNT,
V16SI_FTYPE_V16SI_V4SI_V16SI_UHI_COUNT,
V2DI_FTYPE_V2DI_INT_V2DI_UQI_COUNT,
V2DI_FTYPE_V2DI_V2DI_V2DI_UQI_COUNT,
V32HI_FTYPE_V32HI_INT_V32HI_USI_COUNT,
V32HI_FTYPE_V32HI_V8HI_V32HI_USI_COUNT,
V4DI_FTYPE_V4DI_INT_V4DI_UQI_COUNT,
V4DI_FTYPE_V4DI_V2DI_V4DI_UQI_COUNT,
V4SI_FTYPE_V4SI_INT_V4SI_UQI_COUNT,
V4SI_FTYPE_V4SI_V4SI_V4SI_UQI_COUNT,
V8DI_FTYPE_V8DI_INT_V8DI_UQI_COUNT,
V8DI_FTYPE_V8DI_V2DI_V8DI_UQI_COUNT,
V8HI_FTYPE_V8HI_INT_V8HI_UQI_COUNT,
V8HI_FTYPE_V8HI_V8HI_V8HI_UQI_COUNT,
V8SI_FTYPE_V8SI_INT_V8SI_UQI_COUNT,
V8SI_FTYPE_V8SI_V4SI_V8SI_UQI_COUNT): New function type aliases.
* config/i386/i386-builtin.def (__builtin_ia32_pslld512_mask,
__builtin_ia32_pslldi512_mask, __builtin_ia32_psllq512_mask,
__builtin_ia32_psllqi512_mask, __builtin_ia32_psrad512_mask,
__builtin_ia32_psradi512_mask, __builtin_ia32_psraq512_mask,
__builtin_ia32_psraqi512_mask, __builtin_ia32_psrld512_mask,
__builtin_ia32_psrldi512_mask, __builtin_ia32_psrlq512_mask,
__builtin_ia32_psrlqi512_mask, __builtin_ia32_psllwi128_mask,
__builtin_ia32_pslldi128_mask, __builtin_ia32_psllqi128_mask,
__builtin_ia32_psllw128_mask, __builtin_ia32_pslld128_mask,
__builtin_ia32_psllq128_mask, __builtin_ia32_psllwi256_mask,
__builtin_ia32_psllw256_mask, __builtin_ia32_pslldi256_mask,
__builtin_ia32_pslld256_mask, __builtin_ia32_psllqi256_mask,
__builtin_ia32_psllq256_mask, __builtin_ia32_psradi128_mask,
__builtin_ia32_psrad128_mask, __builtin_ia32_psradi256_mask,
__builtin_ia32_psrad256_mask, __builtin_ia32_psraqi128_mask,
__builtin_ia32_psraq128_mask, __builtin_ia32_psraqi256_mask,
__builtin_ia32_psraq256_mask, __builtin_ia32_psrldi128_mask,
__builtin_ia32_psrld128_mask, __builtin_ia32_psrldi256_mask,
__builtin_ia32_psrld256_mask, __builtin_ia32_psrlqi128_mask,
__builtin_ia32_psrlq128_mask, __builtin_ia32_psrlqi256_mask,
__builtin_ia32_psrlq256_mask, __builtin_ia32_psrawi256_mask,
__builtin_ia32_psraw256_mask, __builtin_ia32_psrawi128_mask,
__builtin_ia32_psraw128_mask, __builtin_ia32_psrlwi256_mask,
__builtin_ia32_psrlw256_mask, __builtin_ia32_psrlwi128_mask,
__builtin_ia32_psrlw128_mask, __builtin_ia32_psllwi512_mask,
__builtin_ia32_psllw512_mask, __builtin_ia32_psrawi512_mask,
__builtin_ia32_psraw512_mask, __builtin_ia32_psrlwi512_mask,
__builtin_ia32_psrlw512_mask): Use _COUNT suffixed function type
aliases.
* config/i386/i386.c (ix86_expand_args_builtin): Rename last_arg_count
flag to second_arg_count, handle 4 argument function type _COUNT
aliases, handle second_arg_count on second argument rather than last.

* gcc.target/i386/pr80381.c: New test.

--- gcc/config/i386/i386-builtin-types.def.jj   2017-01-21 02:26:29.0 
+0100
+++ gcc/config/i386/i386-builtin-types.def  2017-04-10 17:32:39.845594182 
+0200
@@ -1146,6 +1146,24 @@ DEF_FUNCTION_TYPE_ALIAS (V8SI_FTYPE_V8SI
 DEF_FUNCTION_TYPE_ALIAS (V8SI_FTYPE_V8SI_V4SI, COUNT)
 DEF_FUNCTION_TYPE_ALIAS (V4DI_FTYPE_V4DI_INT, COUNT)
 DEF_FUNCTION_TYPE_ALIAS (V4DI_FTYPE_V4DI_V2DI, COUNT)
+DEF_FUNCTION_TYPE_ALIAS (V16HI_FTYPE_V16HI_INT_V16HI_UHI, COUNT)
+DEF_FUNCTION_TYPE_ALIAS (V16HI_FTYPE_V16HI_V8HI_V16HI_UHI, COUNT)
+DEF_FUNCTION_TYPE_ALIAS (V16SI_FTYPE_V16SI_INT_V16SI_UHI, COUNT)
+DEF_FUNCTION_TYPE_ALIAS (V16SI_FTYPE_V16SI_V4SI_V16SI_UHI, COUNT)
+DEF_FUNCTION_TYPE_ALIAS (V2DI_FTYPE_V2DI_INT_V2DI_UQI, COUNT)
+DEF_FUNCTION_TYPE_ALIAS (V2DI_FTYPE_V2DI_V2DI_V2DI_UQI, COUNT)
+DEF_FUNCTION_TYPE_ALIAS (V32HI_FTYPE_V32HI_INT_V32HI_USI, COUNT)
+DEF_FUNCTION_TYPE_ALIAS (V32HI_FTYPE_V32HI_V8HI_V32HI_USI, COUNT)
+DEF_FUNCTION_TYPE_ALIAS (V4DI_FTYPE_V4DI_INT_V4DI_UQI, COUNT)
+DEF_FUNCTION_TYPE_ALIAS (V4DI_FTYPE_V4DI_V2DI_V4DI_UQI, COUNT)
+DEF_FUNCTION_TYPE_ALIAS (V4SI_FTYPE_V4SI_INT_V4SI_UQI, COUNT)
+DEF_FUNCTION_TYPE_ALIAS (V4S

Re: [C++ PATCH] Fix decomp ICEs in templates (PR c++/80370)

[Jason Merrill]

On Mon, Apr 10, 2017 at 4:35 PM, Jakub Jelinek  wrote:
> - store_decomp_type (v[i], eltype);
> + if (!processing_template_decl)
> +   store_decomp_type (v[i], eltype);

This spot shouldn't change; we do want to remember the decltype even
in a template.

> @@ -3935,7 +3935,10 @@ cxx_eval_constant_expression (const cons
>return (*ctx->values->get (t));
>
>  case VAR_DECL:
> -  if (DECL_HAS_VALUE_EXPR_P (t))
> +  if (DECL_HAS_VALUE_EXPR_P (t)
> + /* Don't recurse on DECL_VALUE_EXPR of decomposition decls
> +that have not been finalized yet.  */
> + && (!DECL_DECOMPOSITION_P (t) || TREE_TYPE (DECL_VALUE_EXPR (t

Hmm, we shouldn't get here in this case.  I think
value_dependent_expression_p should return true for a VAR_DECL with
type-dependent DECL_VALUE_EXPR.

Jason

Re: [C++ PATCH] Fix decomp ICEs in templates (PR c++/80370)

[Jakub Jelinek]

On Mon, Apr 10, 2017 at 04:48:43PM -0400, Jason Merrill wrote:
> On Mon, Apr 10, 2017 at 4:35 PM, Jakub Jelinek  wrote:
> > - store_decomp_type (v[i], eltype);
> > + if (!processing_template_decl)
> > +   store_decomp_type (v[i], eltype);
> 
> This spot shouldn't change; we do want to remember the decltype even
> in a template.

Ok.

> > @@ -3935,7 +3935,10 @@ cxx_eval_constant_expression (const cons
> >return (*ctx->values->get (t));
> >
> >  case VAR_DECL:
> > -  if (DECL_HAS_VALUE_EXPR_P (t))
> > +  if (DECL_HAS_VALUE_EXPR_P (t)
> > + /* Don't recurse on DECL_VALUE_EXPR of decomposition decls
> > +that have not been finalized yet.  */
> > + && (!DECL_DECOMPOSITION_P (t) || TREE_TYPE (DECL_VALUE_EXPR (t
> 
> Hmm, we shouldn't get here in this case.  I think
> value_dependent_expression_p should return true for a VAR_DECL with
> type-dependent DECL_VALUE_EXPR.

Will try that tomorrow.

Jakub

Re: [CHKP] Fix for PR79990

[Ilya Enkovich]

2017-04-02 23:52 GMT+03:00 Alexander Ivchenko :
> Hi,
>
> Here is the patch that roughly follows your idea.
> Some comments:
>
> - There are more cases than array_ref overflow. We need to take care
> of component_ref and both underflows/overflows are possible
> - I could not make it work with "0" as a fake address, because then
> catching lower bounds violation is getting hard at O2 and above. E.g.
> consider this:
>
>0x004005f8 <+8>: bndmk  0x7(%rax),%bnd0
>0x004005fd <+13>:mov$0x400734,%edi
> => 0x00400602 <+18>:bndcl  0xfffc,%bnd0
> (gdb) p $bnd0
> $1 = {lbound = 0x0, ubound = 0x7} : size 8
>   0x0040060b <+27>:callq  0x400500 
>
> - bndcu is removed as not necessary and underflowed access is not
> caught. I used another fake value for lower bound address, which is
> 2^(bitness - 1)

Hi,

Looks like CHKP optimizations don't let us catch cases when pointer
arithmetc overflows. Using any fake value doesn't guarantee you don't
have overflow.

This overoptimization is definately a separate issue. It should be easy
to write a test where usage of a huge index in array causes
uncought bounds violation because of removed bndcl/bndcu. You should
file a bug for that.

If we don't try to work around overflow issues in this patch then using 0
should be more efficient because it allows you to always use bndcu only
(you just can't violate zero lower bound).

BTW please don't forget ChangeLogs for your patches.

>
> - hard-reg-3-[1,2]* tests fail with ICE right now because of PR80270.
> I will mark them as XFAIL if the patch is approved and the mentioned
> bug is not fixed
>
>
> 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" } */
> +
> +
> +#include "mpx-check.h"
> +
> +typedef int v8 __attribute__ ((vector_size (8)));
> +
> +s

Re: [PATCH, rs6000] Fix PR80376 (somewhat)

[Segher Boessenkool]

On Mon, Apr 10, 2017 at 12:08:50PM -0500, Bill Schmidt wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80376 shows an ICE on invalid
> code when using certain flavors of the vec_xxpermdi intrinsic.  The root
> cause is that we were not checking the parameter for a legal value, and an
> illegal value was being provided by the user (only an integer constant is
> permissible for argument 3).
> 
> However, this brings up a slightly larger problem, in that the invalid
> vec_xxpermdi call is nested within another call.  We have a lot of cases
> in rs6000.c where we signal an error message and replace the offending
> construct with a const0_rtx.  In this case, that const0_rtx was being used
> as a vector argument to another call, leading to a follow-up ICE that is
> not easy to parse.

i386 does this:

/* Errors in the source file can cause expand_expr to return const0_rtx
   where we expect a vector.  To avoid crashing, use one of the vector
   clear instructions.  */
static rtx
safe_vector_operand (rtx x, machine_mode mode)
{
  if (x == const0_rtx)
x = CONST0_RTX (mode);
  return x;
}

used in e.g. ix86_expand_binop_builtin as
  if (VECTOR_MODE_P (mode0))
op0 = safe_vector_operand (op0, mode0);
We might want something similar :-)

> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c(revision 246804)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@ -15586,6 +15586,11 @@ rs6000_expand_ternop_builtin (enum insn_code icode
> || icode == CODE_FOR_vsx_xxpermdi_v2di
> || icode == CODE_FOR_vsx_xxpermdi_v2df_be
> || icode == CODE_FOR_vsx_xxpermdi_v2di_be
> +|| icode == CODE_FOR_vsx_xxpermdi_v1ti
> +|| icode == CODE_FOR_vsx_xxpermdi_v4sf
> +|| icode == CODE_FOR_vsx_xxpermdi_v4si
> +|| icode == CODE_FOR_vsx_xxpermdi_v8hi
> +|| icode == CODE_FOR_vsx_xxpermdi_v16qi
> || icode == CODE_FOR_vsx_xxsldwi_v16qi
> || icode == CODE_FOR_vsx_xxsldwi_v8hi
> || icode == CODE_FOR_vsx_xxsldwi_v4si

The existing code is indented with spaces only; please keep the style
consistent (fixing it is fine, but then the whole block or function).

> --- gcc/config/rs6000/vector.md   (revision 246804)
> +++ gcc/config/rs6000/vector.md   (working copy)
> @@ -109,6 +109,11 @@
>  {
>if (CONSTANT_P (operands[1]))
>   {
> +   /* Handle cascading error conditions.  */
> +   if (VECTOR_MODE_P (mode)
> +   && !VECTOR_MODE_P (GET_MODE (operands[1])))
> + internal_error ("non-vector constant found where vector expected");
> +
> if (FLOAT128_VECTOR_P (mode))
>   {
> if (!easy_fp_constant (operands[1], mode))

You might not need this with the suggestion above?

The patch is okay if you want that for now; it's an improvement over
what we have.


Segher

Re: [PATCH, rs6000] Fix PR80376 (somewhat)

[Bill Schmidt]

Hi Segher,

> On Apr 10, 2017, at 4:31 PM, Segher Boessenkool  
> wrote:
> 
> On Mon, Apr 10, 2017 at 12:08:50PM -0500, Bill Schmidt wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80376 shows an ICE on invalid
>> code when using certain flavors of the vec_xxpermdi intrinsic.  The root
>> cause is that we were not checking the parameter for a legal value, and an
>> illegal value was being provided by the user (only an integer constant is
>> permissible for argument 3).
>> 
>> However, this brings up a slightly larger problem, in that the invalid
>> vec_xxpermdi call is nested within another call.  We have a lot of cases
>> in rs6000.c where we signal an error message and replace the offending
>> construct with a const0_rtx.  In this case, that const0_rtx was being used
>> as a vector argument to another call, leading to a follow-up ICE that is
>> not easy to parse.
> 
> i386 does this:
> 
> /* Errors in the source file can cause expand_expr to return const0_rtx
>   where we expect a vector.  To avoid crashing, use one of the vector
>   clear instructions.  */
> static rtx
> safe_vector_operand (rtx x, machine_mode mode)
> {
>  if (x == const0_rtx)
>x = CONST0_RTX (mode);
>  return x;
> }
> 
> used in e.g. ix86_expand_binop_builtin as
>  if (VECTOR_MODE_P (mode0))
>op0 = safe_vector_operand (op0, mode0);
> We might want something similar :-)

That's a nice idea.  That would at least keep us from having to fix this in 2-3 
dozen places.
Let me take a look.

Thanks!
Bill

> 
>> Index: gcc/config/rs6000/rs6000.c
>> ===
>> --- gcc/config/rs6000/rs6000.c   (revision 246804)
>> +++ gcc/config/rs6000/rs6000.c   (working copy)
>> @@ -15586,6 +15586,11 @@ rs6000_expand_ternop_builtin (enum insn_code icode
>>|| icode == CODE_FOR_vsx_xxpermdi_v2di
>>|| icode == CODE_FOR_vsx_xxpermdi_v2df_be
>>|| icode == CODE_FOR_vsx_xxpermdi_v2di_be
>> +   || icode == CODE_FOR_vsx_xxpermdi_v1ti
>> +   || icode == CODE_FOR_vsx_xxpermdi_v4sf
>> +   || icode == CODE_FOR_vsx_xxpermdi_v4si
>> +   || icode == CODE_FOR_vsx_xxpermdi_v8hi
>> +   || icode == CODE_FOR_vsx_xxpermdi_v16qi
>>|| icode == CODE_FOR_vsx_xxsldwi_v16qi
>>|| icode == CODE_FOR_vsx_xxsldwi_v8hi
>>|| icode == CODE_FOR_vsx_xxsldwi_v4si
> 
> The existing code is indented with spaces only; please keep the style
> consistent (fixing it is fine, but then the whole block or function).

OK.

> 
>> --- gcc/config/rs6000/vector.md  (revision 246804)
>> +++ gcc/config/rs6000/vector.md  (working copy)
>> @@ -109,6 +109,11 @@
>> {
>>   if (CONSTANT_P (operands[1]))
>>  {
>> +  /* Handle cascading error conditions.  */
>> +  if (VECTOR_MODE_P (mode)
>> +  && !VECTOR_MODE_P (GET_MODE (operands[1])))
>> +internal_error ("non-vector constant found where vector expected");
>> +
>>if (FLOAT128_VECTOR_P (mode))
>>  {
>>if (!easy_fp_constant (operands[1], mode))
> 
> You might not need this with the suggestion above?
> 
> The patch is okay if you want that for now; it's an improvement over
> what we have.
> 
> 
> Segher
> 

Re: [PATCH] PR80101: Fix ICE in store_data_bypass_p

[Segher Boessenkool]

On Mon, Apr 10, 2017 at 06:38:07PM +0100, Richard Sandiford wrote:
> Segher Boessenkool  writes:
> > On Fri, Apr 07, 2017 at 10:39:03AM +0200, Eric Botcazou wrote:
> >> > Or we could just change "blockage" and wait for the next bug report.
> >> 
> >> That's my suggestion, yes.
> >> 
> >> > Alternatively, we can arrange for the bypass functions to not ICE.  We
> >> > can do that specific to these rs6000 pipeline descriptions, by having
> >> > our own version of store_data_bypass_p; or we can make that function
> >> > work for all insns (its definition works fine for insn pairs where
> >> > not both the producer and consumer are SETs).  That's what Kelvin's
> >> > patch does.  What is the value in ICEing here?
> >> 
> >> Telling the back-end writer that something may be wrong somewhere instead 
> >> of 
> >> silently accepting nonsense?
> >
> > Why is it nonsense?  The predicate gives the answer to the question
> > "given these insns A and B, does A feed data that B stores in memory".
> > That is a perfectly valid question to ask of any two insns.
> 
> Agreed FWIW, but for:
> 
> @@ -3701,7 +3704,8 @@ store_data_bypass_p (rtx_insn *out_insn, rtx_insn
>  if (GET_CODE (out_exp) == CLOBBER)
>continue;
> 
> -gcc_assert (GET_CODE (out_exp) == SET);
> + if (GET_CODE (out_exp) != SET)
> +   return false;
> 
>  if (reg_mentioned_p (SET_DEST (out_exp), SET_DEST (in_set)))
>return false;
> 
> how about instead changing the CLOBBER check so that we continue
> when it isn't a SET?  That would allow things like UNSPECs and
> USEs as well.

Yeah that sounds good.  Kelvin, could you try that please?


Segher

Re: [PATCH] S/390: Optimize atomic_compare_exchange and atomic_compare builtins.

[Ulrich Weigand]

Dominik Vogt wrote:

> So, we could add a special case for const0_rtx that generates the
> LT pattern and does not rely on Combine, and get rid of the
> peephole.  I'm not sure this is worthwhile thoug, because the
> peephole has other beneficial effects (as discussed), and until
> we've solved the problems preventing Combine from merging L+LTR in
> some cases, this is the best we have.  What do you think?

If we removed the peephole (for now), the patch now only touches
parts of the backend used to emit atomic instructions, so code
generation for any code that doesn't use those is guaranteed to
be unchanged.  Given that we're quite late in the cycle, this
might be a good idea at this point ...

But I don't see anything actually incorrect in the peephole, and
it might indeed be a good thing in general -- just maybe more
appropriate for the next stage1. 

Andreas, do you have an opinion on this?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

Re: [PATCH] Add a new type attribute always_alias (PR79671)

[Pedro Alves]

On 04/10/2017 01:50 PM, Richard Biener wrote:

> +void *operator new(__SIZE_TYPE__, void *p2) { return p2; }
> +struct B { B(int i_) : i(i_) {} int i; };
> +struct X
> +{
> +  unsigned char buf[sizeof (B)];
> +};

Pedantically, shouldn't there be something here to enforce
X's alignment to be at least the same as B's ?

> +
> +int __attribute__((noinline)) foo()
> +{
> +  X x, y;
> +  new (&x) B (0);

Thanks,
Pedro Alves

Re: [Patch, fortran] PR69498 ICE on unexpected Submodule

[Nicolas Koenig]

Hello Paul,

I would argue that this is but an elaborate plan to teach a newbie the 
ways of the bugzilla and enable him to properly close his first bug ;)


Anyway, committed as r246826.

Thanks for the review.

Nicolas


On 04/10/2017 08:07 PM, Paul Richard Thomas wrote:

Dear Nicolas,

The reasons are (i) moving country and (ii) the daytime job :-)

I think that in the circumstances somebody else should OK the patch,
although I think that it is perfect in every way possible.

Actually, perhaps it is sufficiently obvious that I would and should
have committed it - OK for trunk.

Thanks

Paul


On 10 April 2017 at 17:53, Nicolas Koenig  wrote:

Hello everyone,

Dominique send me this patch written by Paul some time ago. For some reason
it was never committed, so here we go :)

Ok for trunk?

Nicolas

Regression tested for x86_64-pc-linux-gnu.

Changelog:
2017-03-18  Nicolas Koenig  
 PR fortran/69498
 * module.c (gfc_match_submodule): Add error
 if function is called in the wrong state.

2017-03-18  Nicolas Koenig  
 PR fortran/69498
 * gfortran.dg/submodule_unexp.f90: Modified test
 to account for new error.

Re: [PATCH] avoid using types wider than int for width and precision (PR 80364)

[Martin Sebor]

@@ -972,11 +972,11 @@ get_int_range (tree arg, tree type, HOST_WIDE_INT *pmin, 
HOST_WIDE_INT *pmax,
  if (range_type == VR_RANGE)
{
  HOST_WIDE_INT type_min
-   = (TYPE_UNSIGNED (type)
-  ? tree_to_uhwi (TYPE_MIN_VALUE (type))
-  : tree_to_shwi (TYPE_MIN_VALUE (type)));
+   = (TYPE_UNSIGNED (argtype)
+  ? tree_to_uhwi (TYPE_MIN_VALUE (argtype))
+  : tree_to_shwi (TYPE_MIN_VALUE (argtype)));

- HOST_WIDE_INT type_max = tree_to_uhwi (TYPE_MAX_VALUE (type));
+ HOST_WIDE_INT type_max = tree_to_uhwi (TYPE_MAX_VALUE (argtype));


For the start, consider what happens if argtype is __int128_t or __uint128_t
or unsigned int here.  For the first two, those tree_to_uhwi or tree_to_shwi
will just ICE above (if you have VR_RANGE for those, shouldn't be hard to
write testcase).  So likely you need to ignore range info for invalid
args with precision greater than that of integer_type_node (i.e. INT_TYPE_SIZE).


Right.  It's too bad that tree_to_uhwi is so brittle.



unsigned int is I think not UB when passed to var-args and read as int, it is 
just
implementation defined how is it converted into int (I could be wrong).
In that case (i.e. TYPE_UNSIGNED and precision equal to INT_TYPE_SIZE) I
think you need to either handle it like you do only if the max is smaller or
equal than INT_MAX and punt to full int range otherwise, or need to take the
unsigned -> int conversion into account.  I think passing unsigned int arg
bigger than __INT_MAX__ is not well defined, because that means negative
precision in the end.


C requires the type of the argument passed to the asterisk to be
int and so, strictly speaking, passing in an argument of any other
type is undefined just as is passing in any value that's not
representable in int.  The same is true for %d and %i.  But mixing
and matching signed and unsigned is common and GCC doesn't warn
about either unless -Wformat-signedness is used, so it makes sense
to handle this case more gracefully.



And, if you never change type, so type == integer_type_node, you might
consider not passing that argument at all, the behavior is hardcoded for
that type anyway (assumption that it fits into shwi or uhwi etc.).


I can do that.  I had initially intended the function to be more
general than that but in the end wound up only using it where int
is expected.



Perhaps in addition to the type_min/type_max check you do to determine
knownrange follow it by similar range check for integer_type_node range
and don't set unknown to false if it is not within integer_type_node range?
The TYPE_PRECISION <= INT_TYPE_SIZE check will be still needed not to
trigger the ICEs.


Yes, that makes sense.

Attached is an updated version with these changes.

Thanks
Martin
PR middle-end/80364 - sanitizer detects signed integer overflow in gimple-ssa-sprintf.c

gcc/ChangeLog:

	PR middle-end/80364
	* gimple-ssa-sprintf.c (get_int_range): Remove second argument and
	always use the int type.
	(directive::set_width, directive::set_precision, format_character):
	Adjust.

gcc/testsuite/ChangeLog:

	PR middle-end/80364
	* gcc.dg/tree-ssa/builtin-sprintf-warn-16.c: New test.

diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 2474391..be3a70e 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -599,8 +599,7 @@ fmtresult::type_max_digits (tree type, int base)
 }
 
 static bool
-get_int_range (tree, tree, HOST_WIDE_INT *, HOST_WIDE_INT *,
-	   bool, HOST_WIDE_INT);
+get_int_range (tree, HOST_WIDE_INT *, HOST_WIDE_INT *, bool, HOST_WIDE_INT);
 
 /* Description of a format directive.  A directive is either a plain
string or a conversion specification that starts with '%'.  */
@@ -674,7 +673,7 @@ struct directive
  For an indeterminate ARG set width to [0, INT_MAX].  */
   void set_width (tree arg)
   {
-get_int_range (arg, integer_type_node, width, width + 1, true, 0);
+get_int_range (arg, width, width + 1, true, 0);
   }
 
   /* Set both bounds of the precision range to VAL.  */
@@ -690,7 +689,7 @@ struct directive
  For an indeterminate ARG set precision to [-1, INT_MAX].  */
   void set_precision (tree arg)
   {
-get_int_range (arg, integer_type_node, prec, prec + 1, false, -1);
+get_int_range (arg, prec, prec + 1, false, -1);
   }
 
   /* Return true if both width and precision are known to be
@@ -927,25 +926,27 @@ build_intmax_type_nodes (tree *pintmax, tree *puintmax)
 }
 }
 
-/* Determine the range [*PMIN, *PMAX] that the expression ARG of TYPE
-   is in.  Return true when the range is a subrange of that of TYPE.
-   Whn ARG is null it is as if it had the full range of TYPE.
+/* Determine the range [*PMIN, *PMAX] that the expression ARG is
+   in and that is representable in type int.
+   Return true when the range is a subrange of that of int.
+   When ARG is null it is as if it had the full range of 

[committed] Adjust dg-bogus pattern to match the text of changed diagnostic

[Martin Sebor]

Martin L. (CC'd) pointed out to me that the introduction
of the -Wstringop-overflow option has changed the text of
the warning but failed to adjust a couple of dg-bogus
directives in existing tests that used the previous text
as the pattern.  r246827 adjusts the pattern to match
the new diagnostic.  I committed it as obvious.

Martin

commit c3f84aee68366cf40d9b62eb768bcf08c05eecb1
Author: msebor 
Date:   Mon Apr 10 23:26:17 2017 +

Adjust dg-bogus pattern to match the text of the changed diagnostic.

gcc/testsuite:
* gcc.dg/pr40340-3.c: Adjust directive pattern.
* gcc.dg/pr40340-4.c: Same.

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


diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 2104392..8da9f09 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,6 +1,11 @@
+2017-04-10  Martin Sebor  
+
+   * gcc.dg/pr40340-3.c: Adjust directive pattern.
+   * gcc.dg/pr40340-4.c: Same.
+
 2017-04-10  Nicolas Koenig  

-   PR fortran/69498
+   PR fortran/69498
* gfortran.dg/submodule_unexp.f90: Modified test
to account for new error.
* gfortran.dg/submodule_twice.f90: New Test
diff --git a/gcc/testsuite/gcc.dg/pr40340-3.c 
b/gcc/testsuite/gcc.dg/pr40340-3.c

index 5ef09e0..f771a00 100644
--- a/gcc/testsuite/gcc.dg/pr40340-3.c
+++ b/gcc/testsuite/gcc.dg/pr40340-3.c
@@ -12,4 +12,4 @@ main (void)
   return 0;
 }

-/* { dg-bogus "will always overflow destination buffer" "" { target 
*-*-* } 10 } */

+/* { dg-bogus "overflow" "" { target *-*-* } 10 } */
diff --git a/gcc/testsuite/gcc.dg/pr40340-4.c 
b/gcc/testsuite/gcc.dg/pr40340-4.c

index d3f020c..695d0ac 100644
--- a/gcc/testsuite/gcc.dg/pr40340-4.c
+++ b/gcc/testsuite/gcc.dg/pr40340-4.c
@@ -13,4 +13,4 @@ main (void)
   return 0;
 }

-/* { dg-bogus "will always overflow destination buffer" "" { target 
*-*-* } 10 } */

+/* { dg-bogus "overflow" "" { target *-*-* } 10 } */

[patch, libgfortran] Fix pointer declarations per coding standard

[Jerry DeLisle]

All,

Attached patch is removing the space after * in many pointer declarations and
references in the files in the io sub-directory.  Prompted by a comment from one
our C maintainers.  I noticed quite a few comment blocks not done right either,
so since I was there I did those as well.

This is whitespace change only.  Compiled all and regression tested on
x86_64-pc-linux-gnu

I will commit on the 11th.

Regards,

Jerry

2017-04-11  Jerry DeLisle  

* close.c: Fix white space in pointer declarations and comment
formats where applicable.
* fbuf.c: Likewise.
* fbuf.h: Likewise.
* format.c: Likewise.
* inquire.c: Likewise.
* intrinsics.c: Likewise.
* list_read.c: Likewise.
* lock.c: Likewise.
* open.c: Likewise.
* read.c: Likewise.
* transfer.c: Likewise.
* unit.c: Likewise.
* unix.c: Likewise.
* unix.h: Likewise.
* write.c: Likewise.
diff --git a/libgfortran/io/close.c b/libgfortran/io/close.c
index 8771d6ac..e40fd92b 100644
--- a/libgfortran/io/close.c
+++ b/libgfortran/io/close.c
@@ -46,7 +46,7 @@ st_close (st_parameter_close *clp)
   close_status status;
   gfc_unit *u;
 #if !HAVE_UNLINK_OPEN_FILE
-  char * path;
+  char *path;
 
   path = NULL;
 #endif
diff --git a/libgfortran/io/fbuf.c b/libgfortran/io/fbuf.c
index 931558c8..944469d8 100644
--- a/libgfortran/io/fbuf.c
+++ b/libgfortran/io/fbuf.c
@@ -33,7 +33,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 
 
 void
-fbuf_init (gfc_unit * u, int len)
+fbuf_init (gfc_unit *u, int len)
 {
   if (len == 0)
 len = 512;			/* Default size.  */
@@ -46,7 +46,7 @@ fbuf_init (gfc_unit * u, int len)
 
 
 void
-fbuf_destroy (gfc_unit * u)
+fbuf_destroy (gfc_unit *u)
 {
   if (u->fbuf == NULL)
 return;
@@ -58,7 +58,7 @@ fbuf_destroy (gfc_unit * u)
 
 static void
 #ifdef FBUF_DEBUG
-fbuf_debug (gfc_unit * u, const char * format, ...)
+fbuf_debug (gfc_unit *u, const char *format, ...)
 {
   va_list args;
   va_start(args, format);
@@ -73,8 +73,8 @@ fbuf_debug (gfc_unit * u, const char * format, ...)
   fprintf (stderr, "''\n");
 }
 #else
-fbuf_debug (gfc_unit * u __attribute__ ((unused)),
-const char * format __attribute__ ((unused)),
+fbuf_debug (gfc_unit *u __attribute__ ((unused)),
+const char *format __attribute__ ((unused)),
 ...) {}
 #endif
 
@@ -85,7 +85,7 @@ fbuf_debug (gfc_unit * u __attribute__ ((unused)),
modified.  */
 
 int
-fbuf_reset (gfc_unit * u)
+fbuf_reset (gfc_unit *u)
 {
   int seekval = 0;
 
@@ -111,7 +111,7 @@ fbuf_reset (gfc_unit * u)
reallocating if necessary.  */
 
 char *
-fbuf_alloc (gfc_unit * u, int len)
+fbuf_alloc (gfc_unit *u, int len)
 {
   int newlen;
   char *dest;
@@ -119,7 +119,7 @@ fbuf_alloc (gfc_unit * u, int len)
   if (u->fbuf->pos + len > u->fbuf->len)
 {
   /* Round up to nearest multiple of the current buffer length.  */
-  newlen = ((u->fbuf->pos + len) / u->fbuf->len + 1) * u->fbuf->len;
+  newlen = ((u->fbuf->pos + len) / u->fbuf->len + 1) *u->fbuf->len;
   u->fbuf->buf = xrealloc (u->fbuf->buf, newlen);
   u->fbuf->len = newlen;
 }
@@ -136,7 +136,7 @@ fbuf_alloc (gfc_unit * u, int len)
mode. Return value is 0 for success, -1 on failure.  */
 
 int
-fbuf_flush (gfc_unit * u, unit_mode mode)
+fbuf_flush (gfc_unit *u, unit_mode mode)
 {
   int nwritten;
 
@@ -175,7 +175,7 @@ fbuf_flush (gfc_unit * u, unit_mode mode)
Return value is 0 for success, -1 on failure.  */
 
 int
-fbuf_flush_list (gfc_unit * u, unit_mode mode)
+fbuf_flush_list (gfc_unit *u, unit_mode mode)
 {
   int nwritten;
 
@@ -207,7 +207,7 @@ fbuf_flush_list (gfc_unit * u, unit_mode mode)
 
 
 int
-fbuf_seek (gfc_unit * u, int off, int whence)
+fbuf_seek (gfc_unit *u, int off, int whence)
 {
   if (!u->fbuf)
 return -1;
@@ -248,7 +248,7 @@ fbuf_seek (gfc_unit * u, int off, int whence)
of bytes actually processed. */
 
 char *
-fbuf_read (gfc_unit * u, int * len)
+fbuf_read (gfc_unit *u, int *len)
 {
   char *ptr;
   int oldact, oldpos;
@@ -279,7 +279,7 @@ fbuf_read (gfc_unit * u, int * len)
reading. Never call this function directly.  */
 
 int
-fbuf_getc_refill (gfc_unit * u)
+fbuf_getc_refill (gfc_unit *u)
 {
   int nread;
   char *p;
diff --git a/libgfortran/io/fbuf.h b/libgfortran/io/fbuf.h
index 94a947b7..a0c57133 100644
--- a/libgfortran/io/fbuf.h
+++ b/libgfortran/io/fbuf.h
@@ -53,7 +53,7 @@ internal_proto(fbuf_destroy);
 extern int fbuf_reset (gfc_unit *);
 internal_proto(fbuf_reset);
 
-extern char * fbuf_alloc (gfc_unit *, int);
+extern char *fbuf_alloc (gfc_unit *, int);
 internal_proto(fbuf_alloc);
 
 extern int fbuf_flush (gfc_unit *, unit_mode);
@@ -65,7 +65,7 @@ internal_proto(fbuf_flush_list);
 extern int fbuf_seek (gfc_unit *, int, int);
 internal_proto(fbuf_seek);
 
-extern char * fbuf_read (gfc_unit *, int *);
+extern char *fbuf_read (gfc_unit *, int *);
 internal_proto(fbuf_read);
 
 /* Ne

Re: [PATCH] Handle AVX512* 4 argument shift builtins similarly to 2 argument shift builtins (PR target/80381)

[Uros Bizjak]

On Mon, Apr 10, 2017 at 10:46 PM, Jakub Jelinek  wrote:
> Hi!
>
> As mentioned in the PR, apparently we have some specific handling for
> the MMX/SSE/AVX2 shift builtins with *_COUNT function type aliases,
> where the count argument (last == second) is not really required to be
> constant e.g. for the srai/srli/slli builtins, and is converted as needed.
>
> This patch adds similar handling also to the AVX512* 4 argument shifts
> where the count is 2nd argument, followed by value for masked off elts
> and mask.  While the intrinsic docs are ambiguous on if they allow
> non-constant immediates or not, apparently what ICC implements matches
> what we do for the 2 arg builtins.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2017-04-10  Jakub Jelinek  
>
> PR target/80381
> * config/i386/i386-builtin-types.def
> (V16HI_FTYPE_V16HI_INT_V16HI_UHI_COUNT,
> V16HI_FTYPE_V16HI_V8HI_V16HI_UHI_COUNT,
> V16SI_FTYPE_V16SI_INT_V16SI_UHI_COUNT,
> V16SI_FTYPE_V16SI_V4SI_V16SI_UHI_COUNT,
> V2DI_FTYPE_V2DI_INT_V2DI_UQI_COUNT,
> V2DI_FTYPE_V2DI_V2DI_V2DI_UQI_COUNT,
> V32HI_FTYPE_V32HI_INT_V32HI_USI_COUNT,
> V32HI_FTYPE_V32HI_V8HI_V32HI_USI_COUNT,
> V4DI_FTYPE_V4DI_INT_V4DI_UQI_COUNT,
> V4DI_FTYPE_V4DI_V2DI_V4DI_UQI_COUNT,
> V4SI_FTYPE_V4SI_INT_V4SI_UQI_COUNT,
> V4SI_FTYPE_V4SI_V4SI_V4SI_UQI_COUNT,
> V8DI_FTYPE_V8DI_INT_V8DI_UQI_COUNT,
> V8DI_FTYPE_V8DI_V2DI_V8DI_UQI_COUNT,
> V8HI_FTYPE_V8HI_INT_V8HI_UQI_COUNT,
> V8HI_FTYPE_V8HI_V8HI_V8HI_UQI_COUNT,
> V8SI_FTYPE_V8SI_INT_V8SI_UQI_COUNT,
> V8SI_FTYPE_V8SI_V4SI_V8SI_UQI_COUNT): New function type aliases.
> * config/i386/i386-builtin.def (__builtin_ia32_pslld512_mask,
> __builtin_ia32_pslldi512_mask, __builtin_ia32_psllq512_mask,
> __builtin_ia32_psllqi512_mask, __builtin_ia32_psrad512_mask,
> __builtin_ia32_psradi512_mask, __builtin_ia32_psraq512_mask,
> __builtin_ia32_psraqi512_mask, __builtin_ia32_psrld512_mask,
> __builtin_ia32_psrldi512_mask, __builtin_ia32_psrlq512_mask,
> __builtin_ia32_psrlqi512_mask, __builtin_ia32_psllwi128_mask,
> __builtin_ia32_pslldi128_mask, __builtin_ia32_psllqi128_mask,
> __builtin_ia32_psllw128_mask, __builtin_ia32_pslld128_mask,
> __builtin_ia32_psllq128_mask, __builtin_ia32_psllwi256_mask,
> __builtin_ia32_psllw256_mask, __builtin_ia32_pslldi256_mask,
> __builtin_ia32_pslld256_mask, __builtin_ia32_psllqi256_mask,
> __builtin_ia32_psllq256_mask, __builtin_ia32_psradi128_mask,
> __builtin_ia32_psrad128_mask, __builtin_ia32_psradi256_mask,
> __builtin_ia32_psrad256_mask, __builtin_ia32_psraqi128_mask,
> __builtin_ia32_psraq128_mask, __builtin_ia32_psraqi256_mask,
> __builtin_ia32_psraq256_mask, __builtin_ia32_psrldi128_mask,
> __builtin_ia32_psrld128_mask, __builtin_ia32_psrldi256_mask,
> __builtin_ia32_psrld256_mask, __builtin_ia32_psrlqi128_mask,
> __builtin_ia32_psrlq128_mask, __builtin_ia32_psrlqi256_mask,
> __builtin_ia32_psrlq256_mask, __builtin_ia32_psrawi256_mask,
> __builtin_ia32_psraw256_mask, __builtin_ia32_psrawi128_mask,
> __builtin_ia32_psraw128_mask, __builtin_ia32_psrlwi256_mask,
> __builtin_ia32_psrlw256_mask, __builtin_ia32_psrlwi128_mask,
> __builtin_ia32_psrlw128_mask, __builtin_ia32_psllwi512_mask,
> __builtin_ia32_psllw512_mask, __builtin_ia32_psrawi512_mask,
> __builtin_ia32_psraw512_mask, __builtin_ia32_psrlwi512_mask,
> __builtin_ia32_psrlw512_mask): Use _COUNT suffixed function type
> aliases.
> * config/i386/i386.c (ix86_expand_args_builtin): Rename last_arg_count
> flag to second_arg_count, handle 4 argument function type _COUNT
> aliases, handle second_arg_count on second argument rather than last.
>
> * gcc.target/i386/pr80381.c: New test.

OK.

Thanks,
Uros.

> --- gcc/config/i386/i386-builtin-types.def.jj   2017-01-21 02:26:29.0 
> +0100
> +++ gcc/config/i386/i386-builtin-types.def  2017-04-10 17:32:39.845594182 
> +0200
> @@ -1146,6 +1146,24 @@ DEF_FUNCTION_TYPE_ALIAS (V8SI_FTYPE_V8SI
>  DEF_FUNCTION_TYPE_ALIAS (V8SI_FTYPE_V8SI_V4SI, COUNT)
>  DEF_FUNCTION_TYPE_ALIAS (V4DI_FTYPE_V4DI_INT, COUNT)
>  DEF_FUNCTION_TYPE_ALIAS (V4DI_FTYPE_V4DI_V2DI, COUNT)
> +DEF_FUNCTION_TYPE_ALIAS (V16HI_FTYPE_V16HI_INT_V16HI_UHI, COUNT)
> +DEF_FUNCTION_TYPE_ALIAS (V16HI_FTYPE_V16HI_V8HI_V16HI_UHI, COUNT)
> +DEF_FUNCTION_TYPE_ALIAS (V16SI_FTYPE_V16SI_INT_V16SI_UHI, COUNT)
> +DEF_FUNCTION_TYPE_ALIAS (V16SI_FTYPE_V16SI_V4SI_V16SI_UHI, COUNT)
> +DEF_FUNCTION_TYPE_ALIAS (V2DI_FTYPE_V2DI_INT_V2DI_UQI, COUNT)
> +DEF_FUNCTION_TYPE_ALIAS (V2DI_FTYPE_V2DI_V2DI_V2DI_UQI, COUNT)
> +DEF_FUNCTION_TYPE_ALIAS (V32HI_FTYPE_V32HI_INT_V32HI_USI, COUNT)
> +DEF_FUNCTION_TYPE_ALIAS (V32HI_FTYPE_V32H

Re: [patch, libgfortran] Fix pointer declarations per coding standard

[Janne Blomqvist]

On Tue, Apr 11, 2017 at 7:54 AM, Jerry DeLisle  wrote:
> All,
>
> Attached patch is removing the space after * in many pointer declarations and
> references in the files in the io sub-directory.

Hmm, I always considered having a space both before and after the "*"
in declarations to be an idiosyncratic thing mandated by the GNU style
guide, but now that I check
https://www.gnu.org/prep/standards/standards.html#Formatting there is
in fact no such thing.  Have I got it wrong all these years, or has
this changed?

Anyway, good that we can fix this now. Thanks for the patch!



-- 
Janne Blomqvist

Re: [P1] [PATCH] [PR tree-optimization/80374] Do not try to convert integer_zero_node to undesirable types

[Markus Trippelsdorf]

On 2017.04.10 at 13:20 -0600, Jeff Law wrote:
> 
> fold_convert can fail for certain types.  It can fail either by returning a
> error_mark_node or triggering a gcc_assert depending on the exact situation.
> 
> Both are problematical.  This patch checks that we can convert
> integer_zero_node to the proper type before calling fold_convert.
> 
> Bootstrapped and regression tested on x86_64.  Installing on the trunk.

I've fixed up the testcase:

FAIL: g++.dg/pr80374.C  -std=c++11 (test for excess errors)
FAIL: g++.dg/pr80374.C  -std=c++14 (test for excess errors)
FAIL: g++.dg/pr80374.C  -std=c++98 (test for excess errors)

Committed as obvious.

diff --git a/gcc/testsuite/g++.dg/pr80374.C b/gcc/testsuite/g++.dg/pr80374.C
index b02b65629aef..83f778be638a 100644
--- a/gcc/testsuite/g++.dg/pr80374.C
+++ b/gcc/testsuite/g++.dg/pr80374.C
@@ -1,3 +1,5 @@
+// { dg-do compile }
+// { dg-options "-O1 -std=c++11" }
 void a (const char *, const char *, int, const char *)
   __attribute__ ((__noreturn__));
 template 
@@ -11,7 +13,8 @@ catch (b d)
 if (d)
   a ("", "", 2, __PRETTY_FUNCTION__);
   }
-main ()
+void
+foo ()
 {
   using e = decltype (nullptr);
   c ();
-- 
Markus