Re: [PATCH, 2 of 4], Enhance PowerPC vec_extract support for power8/power9 machines

[Segher Boessenkool]

On Thu, Jul 28, 2016 at 03:44:25PM -0400, Michael Meissner wrote:
> > This isn't in the changelog.
> 
> Yes it is.

I need new glasses.

> > > +/* Macro to say whether we can optimize vector extracts.  */
> > > +#define VEC_EXTRACT_OPTIMIZE_P   (TARGET_DIRECT_MOVE 
> > > \
> > > +  && TARGET_POWERPC64\
> > > +  && TARGET_UPPER_REGS_DI)
> > 
> > I'm not a big fan of this name.  "Optimize" will quickly become dated,
> > everyone will take the current new hot thing for granted, and then when
> > you want to optimise even more (say, for ISA 6.0 or whatever) the name
> > is really out of place.
> > 
> > But I don't know a much better name either.
> 
> I changed it to TARGET_DIRECT_MOVE_64BIT, which hopefully is clearer of what
> exactly we need.  In particular, the calculation of the bit shift is done in
> the GPR and direct move creates teh vector used by VSLO to do a byte shift.

That is a much better name, thanks!


Segher

Re: Implement -Wimplicit-fallthrough (take 2): fix missing breaks

[Segher Boessenkool]

On Thu, Jul 28, 2016 at 05:57:34PM +0200, Marek Polacek wrote:
> Segher, is the rs6000.c part ok?

Yes, that looks fine, thanks!  Will you handle the backports as well?


Segher

[PING][PATCH 3/3][GCC-6] Backport support for arm*-*-phoenix* targets in libgcc.

[Jakub Sejdak]

Hi,

I'd like to ping this patch to GCC-6 branch.

Regards,
Kuba Sejdak

2016-07-22 8:27 GMT+02:00 Kuba Sejdak :
> This patch is already in trunk. It adds no new features, just new arm-phoenix*
> OS target to libgcc.
> I have SVN write access, so only approval is needed. Is it OK for gcc-6 
> branch?
>
> 2016-07-22  Jakub Sejdak  
>
>* config.host: Add suport for arm*-*-phoenix* targets.
>
> ---
>  libgcc/ChangeLog   | 4 
>  libgcc/config.host | 7 +++
>  2 files changed, 11 insertions(+)
>
> diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog
> index 934cddf..fd6e5b3 100644
> --- a/libgcc/ChangeLog
> +++ b/libgcc/ChangeLog
> @@ -1,3 +1,7 @@
> +2016-07-22  Jakub Sejdak  
> +
> +   * config.host: Add suport for arm*-*-phoenix* targets.
> +
>  2016-07-14  Bill Schmidt  
>
> Backport from mainline
> diff --git a/libgcc/config.host b/libgcc/config.host
> index 16a45c8..cf5fae2 100644
> --- a/libgcc/config.host
> +++ b/libgcc/config.host
> @@ -402,6 +402,13 @@ arm*-*-uclinux*)   # ARM ucLinux
> unwind_header=config/arm/unwind-arm.h
> extra_parts="$extra_parts crti.o crtn.o"
> ;;
> +arm*-*-phoenix*)
> +   tmake_file="t-hardfp t-softfp arm/t-arm arm/t-elf arm/t-softfp 
> arm/t-phoenix"
> +   tmake_file="${tmake_file} arm/t-bpabi"
> +   tm_file="$tm_file arm/bpabi-lib.h"
> +   extra_parts="crtbegin.o crtend.o crti.o crtn.o"
> +   unwind_header=config/arm/unwind-arm.h
> +   ;;
>  arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
> tmake_file="${tmake_file} arm/t-arm arm/t-elf t-fixedpoint-gnu-prefix"
> tm_file="$tm_file arm/bpabi-lib.h"
> --
> 2.7.4
>

-- 
Jakub Sejdak
Software Engineer
Phoenix Systems (www.phoesys.com)
+48 608 050 163

[PING][PATCH 2/3][GCC-6] Backport support for arm*-*-phoenix* targets.

[Jakub Sejdak]

Hi,

I'd like to ping this patch to GCC-6 branch.

Regards,
Kuba Sejdak

2016-07-22 8:27 GMT+02:00 Kuba Sejdak :
> This patch is already in trunk. It adds no new features, just new arm-phoenix*
> OS target to gcc config.
> I have SVN write access, so only approval is needed. Is it OK for gcc-6 
> branch?
>
> 2016-07-22  Jakub Sejdak  
>
>* config.gcc: Add support for arm*-*-phoenix* targets.
>* config/arm/t-phoenix: New.
>* config/phoenix.h: New.
>
> ---
>  gcc/ChangeLog|  6 ++
>  gcc/config.gcc   | 11 +++
>  gcc/config/arm/t-phoenix | 29 +
>  gcc/config/phoenix.h | 33 +
>  4 files changed, 79 insertions(+)
>  create mode 100644 gcc/config/arm/t-phoenix
>  create mode 100644 gcc/config/phoenix.h
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 262456a..0591a49 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,9 @@
> +2016-07-22  Jakub Sejdak  
> +
> +   * config.gcc: Add support for arm*-*-phoenix* targets.
> +   * config/arm/t-phoenix: New.
> +   * config/phoenix.h: New.
> +
>  2016-07-21  Jakub Jelinek  
>
> * tree-object-size.c (unknown): Use HOST_WIDE_INT_M1U instead of -1.
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 82cc9a9..cc0a175 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -815,6 +815,11 @@ case ${target} in
>;;
>esac
>;;
> +*-*-phoenix*)
> +  gas=yes
> +  gnu_ld=yes
> +  default_use_cxa_atexit=yes
> +  ;;
>  *-*-rtems*)
>case ${enable_threads} in
>  "" | yes | rtems) thread_file='rtems' ;;
> @@ -1097,6 +1102,12 @@ arm*-*-uclinux*eabi*)# ARM ucLinux
> # The EABI requires the use of __cxa_atexit.
> default_use_cxa_atexit=yes
> ;;
> +arm*-*-phoenix*)
> +   tm_file="elfos.h arm/unknown-elf.h arm/elf.h arm/bpabi.h"
> +   tm_file="${tm_file} newlib-stdint.h phoenix.h"
> +   tm_file="${tm_file} arm/aout.h arm/arm.h"
> +   tmake_file="${tmake_file} arm/t-arm arm/t-bpabi arm/t-phoenix"
> +   ;;
>  arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
> case ${target} in
> arm*eb-*-eabi*)
> diff --git a/gcc/config/arm/t-phoenix b/gcc/config/arm/t-phoenix
> new file mode 100644
> index 000..d881884
> --- /dev/null
> +++ b/gcc/config/arm/t-phoenix
> @@ -0,0 +1,29 @@
> +# Copyright (C) 2016 Free Software Foundation, Inc.
> +#
> +# This file is part of GCC.
> +#
> +# GCC is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3, or (at your option)
> +# any later version.
> +#
> +# GCC is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with GCC; see the file COPYING3.  If not see
> +# .
> +
> +MULTILIB_OPTIONS = marm/mthumb
> +MULTILIB_DIRNAMES= arm thumb
> +MULTILIB_EXCEPTIONS  =
> +MULTILIB_MATCHES =
> +
> +MULTILIB_OPTIONS += mfloat-abi=hard
> +MULTILIB_DIRNAMES+= fpu
> +MULTILIB_MATCHES += mfloat-abi?hard=mhard-float
> +
> +MULTILIB_OPTIONS += mno-thumb-interwork/mthumb-interwork
> +MULTILIB_DIRNAMES+= normal interwork
> diff --git a/gcc/config/phoenix.h b/gcc/config/phoenix.h
> new file mode 100644
> index 000..9ffb958
> --- /dev/null
> +++ b/gcc/config/phoenix.h
> @@ -0,0 +1,33 @@
> +/* Base configuration file for all Phoenix-RTOS targets.
> +   Copyright (C) 2016 Free Software Foundation, Inc.
> +
> +This file is part of GCC.
> +
> +GCC is free software; you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation; either version 3, or (at your option)
> +any later version.
> +
> +GCC is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +GNU General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with GCC; see the file COPYING3.  If not see
> +.  */
> +
> +#undef TARGET_OS_CPP_BUILTINS
> +#define TARGET_OS_CPP_BUILTINS()   \
> +do {   \
> +  builtin_define_std ("phoenix");  \
> +  builtin_define_std ("unix"); \
> +  builtin_assert ("system=phoenix");   \
> +  builtin_assert ("system=unix");  \
> +} while(0);
> +
> +#define STD_LIB_SPEC "%{!shared:%{g*:-lg} 
> %{!p:%{!pg:-lc}}%{p:-lc_p}%{pg:-lc_p}}"
> +
> +/* This will prevent selecting 'unsigned long int' instead of 'unsigned int' 
> as 'uint32_t' in stdi

[PING][PATCH 1/3][GCC-6] Backport support for Phoenix-RTOS targets in config.sub.

[Jakub Sejdak]

Hi,

I'd like to ping this patch to GCC-6 branch.

Regards,
Kuba Sejdak

2016-07-22 8:27 GMT+02:00 Kuba Sejdak :
> This patch is already in trunk. It adds no new features, just new OS target.
> I have SVN write access, so only approval is needed. Is it OK for gcc-6 
> branch?
>
> 2016-07-22  Jakub Sejdak  
>
>* config.sub: Add support for Phoenix-RTOS targets.
>
> ---
>  ChangeLog  | 4 
>  config.sub | 2 +-
>  2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/ChangeLog b/ChangeLog
> index 4a1334a..68f4a83 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,7 @@
> +2016-07-22  Jakub Sejdak  
> +
> +   * config.sub: Add support for Phoenix-RTOS targets.
> +
>  2016-04-27  Release Manager
>
> * GCC 6.1.0 released.
> diff --git a/config.sub b/config.sub
> index da6d1b6..41146e1 100755
> --- a/config.sub
> +++ b/config.sub
> @@ -1399,7 +1399,7 @@ case $os in
>   | -morphos* | -superux* | -rtmk* | -rtmk-nova* | -windiss* \
>   | -powermax* | -dnix* | -nx6 | -nx7 | -sei* | -dragonfly* \
>   | -skyos* | -haiku* | -rdos* | -toppers* | -drops* | -es* \
> - | -onefs* | -tirtos*)
> + | -onefs* | -tirtos* | -phoenix*)
> # Remember, each alternative MUST END IN *, to match a version number.
> ;;
> -qnx*)
> --
> 2.7.4
>

-- 
Jakub Sejdak
Software Engineer
Phoenix Systems (www.phoesys.com)
+48 608 050 163

[gomp4] Fix PR72741

[Cesar Philippidis]

Thomas found a bug in the fortran routine parser where errors involving
invalid combinations of gang, worker, vector and seq clauses were
getting suppressed. This patch does two things:

  1) It moves the error handling into gfc_match_oacc_routine. So now
 gfc_oacc_routine_dims returns OACC_FUNCTION_NONE when it detects
 an error. That's fine because it's ok for routines to default to
 OACC_FUNCTION_SEQ.

  2) It makes gfc_match_oacc_routine return a MATCH_ERROR when an error
 has been detected in gfc_oacc_routine_dims.

This bug is also present in trunk, but I'd like to see my other fortran
module patch go in first. In the meantime, I'll commit this patch to
gomp-4_0-branch.

Cesar
2016-07-28  Cesar Philippidis  

	PR fortran/72741
	gcc/fortran/
	* openmp.c (gfc_oacc_routine_dims): Move gfc_error to
	gfc_match_oacc_routine.  Return OACC_FUNCTION_NONE on error.
	(gfc_match_oacc_routine): Call gfc_oacc_routine_dims for all
	routines directives.  Propagate error as appropriate.

	gcc/testsuite/
	* gfortran.dg/goacc/pr72741.f90: New test.


diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index c20a0a3..3c39836 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -1877,7 +1877,8 @@ gfc_match_oacc_cache (void)
   return MATCH_YES;
 }
 
-/* Determine the loop level for a routine.   */
+/* Determine the loop level for a routine.  Returns OACC_FUNCTION_NONE if
+   any error is detected.  */
 
 static oacc_function
 gfc_oacc_routine_dims (gfc_omp_clauses *clauses)
@@ -1908,7 +1909,7 @@ gfc_oacc_routine_dims (gfc_omp_clauses *clauses)
 	level = GOMP_DIM_MAX, mask |= GOMP_DIM_MASK (level);
 
   if (mask != (mask & -mask))
-	gfc_error ("Multiple loop axes specified for routine");
+	ret = OACC_FUNCTION_NONE;
 }
 
   return ret;
@@ -1923,6 +1924,7 @@ gfc_match_oacc_routine (void)
   gfc_omp_clauses *c = NULL;
   gfc_oacc_routine_name *n = NULL;
   gfc_intrinsic_sym *isym = NULL;
+  oacc_function dims = OACC_FUNCTION_NONE;
 
   old_loc = gfc_current_locus;
 
@@ -1991,6 +1993,14 @@ gfc_match_oacc_routine (void)
 	  != MATCH_YES))
 return MATCH_ERROR;
 
+  dims = gfc_oacc_routine_dims (c);
+  if (dims == OACC_FUNCTION_NONE)
+{
+  gfc_error ("Multiple loop axes specified for routine %C");
+  gfc_current_locus = old_loc;
+  return MATCH_ERROR;
+}
+
   if (isym != NULL)
 /* There is nothing to do for intrinsic procedures.  */
 ;
@@ -2011,8 +2021,7 @@ gfc_match_oacc_routine (void)
    gfc_current_ns->proc_name->name,
    &old_loc))
 	goto cleanup;
-  gfc_current_ns->proc_name->attr.oacc_function
-	= gfc_oacc_routine_dims (c);
+  gfc_current_ns->proc_name->attr.oacc_function = dims;
   gfc_current_ns->proc_name->attr.oacc_function_nohost
 	= c ? c->nohost : false;
 }
diff --git a/gcc/testsuite/gfortran.dg/goacc/pr72741.f90 b/gcc/testsuite/gfortran.dg/goacc/pr72741.f90
new file mode 100644
index 000..cf89727
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/pr72741.f90
@@ -0,0 +1,28 @@
+SUBROUTINE v_1
+  !$ACC ROUTINE VECTOR WORKER ! { dg-error "Multiple loop axes" }
+END SUBROUTINE v_1
+
+SUBROUTINE sub_1
+  IMPLICIT NONE
+  EXTERNAL :: g_1
+  !$ACC ROUTINE (g_1) GANG WORKER ! { dg-error "Multiple loop axes" }
+  !$ACC ROUTINE (ABORT) SEQ VECTOR ! { dg-error "Multiple loop axes" }
+
+  CALL v_1
+  CALL g_1
+  CALL ABORT
+END SUBROUTINE sub_1
+
+MODULE m_w_1
+  IMPLICIT NONE
+  EXTERNAL :: w_1
+  !$ACC ROUTINE (w_1) WORKER SEQ ! { dg-error "Multiple loop axes" }
+  !$ACC ROUTINE (ABORT) VECTOR GANG ! { dg-error "Multiple loop axes" }
+
+CONTAINS
+  SUBROUTINE sub_2
+CALL v_1
+CALL w_1
+CALL ABORT
+  END SUBROUTINE sub_2
+END MODULE m_w_1

Re: [PATCH] Improve forward jump threading of switch statements (PR18046)

[Patrick Palka]

On Thu, Jul 28, 2016 at 11:46 PM, Patrick Palka  wrote:
> This patch improves the forward jump threader's ability to thread
> GIMPLE_SWITCHes by making the VRP simplification callback attempt to
> determine which case label will be taken.
>
> For example, if the index operand of a switch has a value range ~[5,6]
> along some edge and the switch statement has no "case 5" or "case 6"
> label then this patch recognizes such a scenario as an opportunity for
> threading through the switch and to the switch's default bb.

Uh, sorry, this example I gave is completely bogus... Given a value
range of ~[5,6],  "case 5" and "case 6" would have to be the only
non-default labels in the switch for threading to occur, which is how
the patch behaves.

[PATCH] Improve forward jump threading of switch statements (PR18046)

[Patrick Palka]

This patch improves the forward jump threader's ability to thread
GIMPLE_SWITCHes by making the VRP simplification callback attempt to
determine which case label will be taken.

For example, if the index operand of a switch has a value range ~[5,6]
along some edge and the switch statement has no "case 5" or "case 6"
label then this patch recognizes such a scenario as an opportunity for
threading through the switch and to the switch's default bb.

This improvement is necessary for the code in comment #1 of PR18046 to
get threaded.  There we have (in the VRP2 dump):

bar ()
{
  int i.0_1;
  int i.0_2;
  int pretmp_8;
  int prephitmp_9;
  int i.0_10;

  :
  i.0_1 = i;
  switch (i.0_1) , case 0: >

:
  i.0_10 = ASSERT_EXPR ;
  goto  ();  // <-- this can be threaded to 

:
  i.0_2 = ASSERT_EXPR ;
  foo ();
  pretmp_8 = i;

  # prephitmp_9 = PHI 
:
  switch (prephitmp_9) , case 0: >

:
  foo ();

:
  return;

}

The FSM threader can't thread the default edge of the 1st switch through
to the default edge of the 2nd switch because i.0_1 doesn't have a known
constant value along that path -- it could have any non-zero value.  For
this scenario and others like it, it is necessary to consider value
ranges.

During bootstrap this simplification triggered about 1000 times in
total.  It's not an impressive amount but the simplification itself is
cheap.

Bootstrap + regtest in progress on x86_64-pc-linux-gnu.  Does this look
OK to commit if there are no new regressions?

gcc/ChangeLog:

PR tree-optimization/18046
* tree-ssa-threadedge.c: Include cfganal.h.
(simplify_control_statement_condition): If simplifying a
GIMPLE_SWITCH, replace the index operand of the GIMPLE_SWITCH
with the dominating ASSERT_EXPR before handing it off to VRP.
Mention that a CASE_LABEL_EXPR may be returned.
(thread_around_empty_blocks): Adjust to handle
simplify_control_statement_condition() returning a
CASE_LABEL_EXPR.
(thread_through_normal_block): Likewise.
* tree-vrp.c (simplify_stmt_for_jump_threading): Simplify
a switch statement by trying to determine which case label
will be taken.

gcc/testsuite/ChangeLog:

PR tree-optimization/18046
* gcc.dg/tree-ssa/vrp105.c: New test.
* gcc.dg/tree-ssa/vrp106.c: New test.
---
 gcc/testsuite/gcc.dg/tree-ssa/vrp105.c | 37 +
 gcc/testsuite/gcc.dg/tree-ssa/vrp106.c | 27 +++
 gcc/tree-ssa-threadedge.c  | 40 ++
 gcc/tree-vrp.c | 61 ++
 4 files changed, 159 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp105.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/vrp106.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp105.c 
b/gcc/testsuite/gcc.dg/tree-ssa/vrp105.c
new file mode 100644
index 000..7cdd4dd
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp105.c
@@ -0,0 +1,37 @@
+/* PR tree-optimization/18046  */
+/* { dg-options "-O2 -fdump-tree-vrp2-details" }  */
+/* { dg-final { scan-tree-dump-times "Threaded jump" 1 "vrp2" } }  */
+/* In the 2nd VRP pass (after PRE) we expect to thread the default label of the
+   1st switch straight to that of the 2nd switch.  */
+
+extern void foo (void);
+extern void bar (void);
+
+extern int i;
+void
+test (void)
+{
+  switch (i)
+{
+case 0:
+  foo ();
+  break;
+case 1:
+  bar ();
+  break;
+default:
+  break;
+}
+
+  switch (i)
+{
+case 0:
+  foo ();
+  break;
+case 1:
+  bar ();
+  break;
+default:
+  break;
+}
+}
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp106.c 
b/gcc/testsuite/gcc.dg/tree-ssa/vrp106.c
new file mode 100644
index 000..e2e48d8
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp106.c
@@ -0,0 +1,27 @@
+/* PR tree-optimization/18046  */
+/* { dg-options "-O2 -fdump-tree-vrp1-details" }  */
+/* { dg-final { scan-tree-dump-times "Threaded jump" 1 "vrp1" } }  */
+/* During VRP we expect to thread the true arm of the conditional through the 
switch
+   and to the BB that corresponds to the 7 ... 9 case label.  */
+extern void foo (void);
+extern void bar (void);
+extern void baz (void);
+
+void
+test (int i)
+{
+  if (i >= 7 && i <= 8)
+foo ();
+
+  switch (i)
+  {
+case 1:
+  bar ();
+  break;
+case 7:
+case 8:
+case 9:
+  baz ();
+  break;
+  }
+}
diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index de671b9..170e456 100644
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@ -36,6 +36,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-ssa-threadedge.h"
 #include "tree-ssa-dom.h"
 #include "gimple-fold.h"
+#include "cfganal.h"
 
 /* To avoid code explosion due to jump threading, we limit the
number

Re: [PR70920] transform (intptr_t) x eq/ne CST to x eq/ne (typeof x) cst

[Prathamesh Kulkarni]

On 28 July 2016 at 19:18, Richard Biener  wrote:
> On Thu, 28 Jul 2016, Prathamesh Kulkarni wrote:
>
>> On 28 July 2016 at 15:58, Andreas Schwab  wrote:
>> > On Mo, Jul 25 2016, Prathamesh Kulkarni  
>> > wrote:
>> >
>> >> diff --git a/gcc/testsuite/gcc.dg/pr70920-4.c 
>> >> b/gcc/testsuite/gcc.dg/pr70920-4.c
>> >> new file mode 100644
>> >> index 000..dedb895
>> >> --- /dev/null
>> >> +++ b/gcc/testsuite/gcc.dg/pr70920-4.c
>> >> @@ -0,0 +1,21 @@
>> >> +/* { dg-do compile } */
>> >> +/* { dg-options "-O2 -fdump-tree-ccp-details -Wno-int-to-pointer-cast" } 
>> >> */
>> >> +
>> >> +#include 
>> >> +
>> >> +void f1();
>> >> +void f2();
>> >> +
>> >> +void
>> >> +foo (int a)
>> >> +{
>> >> +  void *cst = 0;
>> >> +  if ((int *) a == cst)
>> >> +{
>> >> +  f1 ();
>> >> +  if (a)
>> >> + f2 ();
>> >> +}
>> >> +}
>> >> +
>> >> +/* { dg-final { scan-tree-dump "gimple_simplified to if \\(_\[0-9\]* == 
>> >> 0\\)" "ccp1" } } */
>> >
>> > This fails on all ilp32 platforms.
>> Oops, sorry for the breakage.
>> With -m32, the pattern is applied during forwprop1 rather than ccp1.
>> I wonder though why ccp1 fails to fold the pattern with -m32 ?
>> Looking at the dumps:
>>
>> without -m32:
>> input to ccp1 pass:
>>   :
>>   cst_4 = 0B;
>>   _1 = (long int) a_5(D);
>>   _2 = (void *) _1;
>>   if (cst_4 == _2)
>> goto ;
>>   else
>> goto ;
>>
>> cc1 pass dump shows:
>> Substituting values and folding statements
>>
>> Folding statement: _1 = (long int) a_5(D);
>> Not folded
>> Folding statement: _2 = (void *) _1;
>> Not folded
>> Folding statement: if (cst_4 == _2)
>> which is likely CONSTANT
>> Applying pattern match.pd:2537, gimple-match.c:6530
>> gimple_simplified to if (_1 == 0)
>> Folded into: if (_1 == 0)
>>
>> with -m32:
>> input to ccp1 pass:
>>  :
>>   cst_3 = 0B;
>>   a.0_1 = (void *) a_4(D);
>>   if (cst_3 == a.0_1)
>> goto ;
>>   else
>> goto ;
>>
>> ccp1 pass dump shows:
>> Substituting values and folding statements
>>
>> Folding statement: a.0_1 = (void *) a_4(D);
>> Not folded
>> Folding statement: if (cst_3 == a.0_1)
>> which is likely CONSTANT
>> Folded into: if (a.0_1 == 0B)
>>
>> I am not able to understand why it doesn't fold it to
>> if (a_4(D) == 0) ?
>> forwprop1 folds a.0_1 == 0B to a_4(D) == 0.
>
> It's because CCP folds with follow-single-use edges but the
> match-and-simplify code uses a single callback to valueize and
> decide whether its valid to follow the SSA edge.  I did have some
> old patches trying to fix that but never followed up on those.
Thanks for the explanation.
>
>> I suppose the test-case would need to scan ccp1 for non-ilp targets
>> and forwprop1 for
>> ilp targets. How do update the test-case to reflect this ?
>
> It's simpler to verify that at some point (forwprop) we have the
> expected IL rather than testing for the match debug prints.
In forwprop dump,
For m32, we have if (a_4(D) == 0)
and without m32: if (_1 == 0)
So need to match either a default def or anonymous name
in the test-case, which I am having a bit of trouble writing regex for.
In the patch i simply chose to match "== 0\\)", not sure if that's a good idea.
Also how do I update the test-case so that it gets tested twice, once with -m32
and once without ?

Thanks,
Prathamesh
>
> Richard.
>
>> Thanks,
>> Prathamesh
>> >
>> > Andreas.
>> >
>> > --
>> > Andreas Schwab, SUSE Labs, sch...@suse.de
>> > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
>> > "And now for something completely different."
>>
>>
>
> --
> Richard Biener 
> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
> 21284 (AG Nuernberg)
diff --git a/gcc/testsuite/gcc.dg/pr70920-4.c b/gcc/testsuite/gcc.dg/pr70920-4.c
index dedb895..035c3cb 100644
--- a/gcc/testsuite/gcc.dg/pr70920-4.c
+++ b/gcc/testsuite/gcc.dg/pr70920-4.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-ccp-details -Wno-int-to-pointer-cast" } */
+/* { dg-options "-O2 -fdump-tree-forwprop-details -Wno-int-to-pointer-cast" } 
*/
 
 #include 
 
@@ -18,4 +18,4 @@ foo (int a)
 }
 }
 
-/* { dg-final { scan-tree-dump "gimple_simplified to if \\(_\[0-9\]* == 0\\)" 
"ccp1" } } */
+/* { dg-final { scan-tree-dump "== 0\\)" "forwprop1" } } */

Re: [RFC][PR68217] Improve value range for signed & sign-bit-CST

[kugan]

Hi Richard,

Thanks for the review.

On 27/04/16 00:14, Richard Biener wrote:

On Fri, Apr 15, 2016 at 12:44 PM, kugan
 wrote:

As pointed out by Richard, for signed & sign-bit-CST value range should be
[-INF, 0] range, not a [-INF, INF] range as happens now.

This patch fixes this. I bootstrapped and regression tested for
x86-64-linux-gnu with no new regression. Is this OK for statege-1.


I think you need to check vr0 for singleton-constant == sign_bit as well,
there is nothing that canonicalizes this during propagation.

Otherwise ok.


Committed as r238846 with the above change.

Thanks,
Kugan




Thanks,
Richard.


Thanks,
Kugan


gcc/ChangeLog:

2016-04-14  Kugan Vivekanandarajah  

PR middle-end/68217
* tree-vrp.c (extract_range_from_binary_expr_1): In case of signed &
sign-bit-CST,
 generate [-INF, 0] instead of [-INF, INF].


gcc/testsuite/ChangeLog:

2016-04-14  Kugan Vivekanandarajah  

PR middle-end/68217
* gcc.dg/pr68217.c: New test.

Re: [RFC] [2/2] divmod transform: override expand_divmod_libfunc for ARM and add test-cases

[Prathamesh Kulkarni]

On 28 July 2016 at 20:39, Richard Earnshaw
 wrote:
> On 28/07/16 14:36, Prathamesh Kulkarni wrote:
>> Um I had configured with --with-tune=cortex-a9. Is that incorrect for
>> armv8l-unknown-linux-gnueabihf ?
>
> Why on earth would you want to generate code for ARMv8 and then tune for
> best performance on a core that can only run ARMv7?
Oops, I realized later that was a mistake, sorry about that.

Regards,
Prathamesh
>
> R.

Re: [RFC] [2/2] divmod transform: override expand_divmod_libfunc for ARM and add test-cases

[Prathamesh Kulkarni]

On 28 July 2016 at 20:14, Ramana Radhakrishnan
 wrote:
>
>> appear UNSUPPORTED.
>> That's because this config appears to define
>> __ARM_ARCH_EXT_IDIV__ however idiv appears not to be present.
>>
>> For instance __aeabi_div is called to perform
>> division for the following test-case:
>> int f(int x, int y)
>> {
>>   int r = x / y;
>>   return r;
>> }
>>
>> Compiling with -O2:
>> f:
>> @ args = 0, pretend = 0, frame = 0
>> @ frame_needed = 0, uses_anonymous_args = 0
>> push{r4, lr}
>> bl  __aeabi_idiv
>> pop {r4, pc}
>>
>> I assumed if __ARM_ARCH_EXT_IDIV was defined, then
>> there should have been idiv instead of call to __aeabi_div
>> or am I missing something ?
>>
>> Um I had configured with --with-tune=cortex-a9. Is that incorrect for
>> armv8l-unknown-linux-gnueabihf ?
>
> --with-tune shouldn't make a difference to code generation settings. The code 
> generation you are showing is certainly odd for this testcase  - and not 
> something I can reproduce on pristine trunk - so sounds like something's 
> broken by your patch . You should be seeing an sdiv in this case in the 
> output - Look at the .arch directive at the top of your file - maybe that 
> gives you a clue in terms of making sure that you had configured the 
> toolchain correctly.
Hi,
There is no .arch in the assembly however there's .cpu arm10dtmi at
the top, full assembly: http://pastebin.com/6tzckiG0
With pristine trunk (r238800), I still get __aeabi_idiv for the above test-case.
config opts: --enable-languages=c,c++ --target=armv8l-linux-gnueabihf
--with-arch=armv8-a --with-fpu=neon-fp-armv8 --with-float=hard
--with-mode=thumb --enable-multiarch --disable-multilib
Tried with native stage-1 build and cross build.
I verified that __ARM_ARCH_EXT_IDIV__ is defined, with following
test-case, which fails to compile.
#ifdef __ARM_ARCH_EXT_IDIV__
#error "has div insn"
#endif
int x;

Thanks,
Prathamesh
>
>
> regards
> Ramana
>
>>
>> xgcc -v:
>> Using built-in specs.
>> COLLECT_GCC=armhf-bootstrap-build/gcc/xgcc
>> Target: armv8l-unknown-linux-gnueabihf
>> Configured with: ../gcc/configure --enable-languages=c,c++,fortran
>> --with-arch=armv8-a --with-fpu=neon-fp-armv8 --with-float=hard
>> --with-mode=thumb --enable-multiarch --with-tune=cortex-a9
>> --disable-multilib
>> Thread model: posix
>> gcc version 7.0.0 20160727 (experimental) (GCC)
>>
>> Thanks,
>> Prathamesh
>>>
>>> Thanks,
>>> Ramana
>

PR fortran/70006 -- Patch

[Steve Kargl]

I intend to commit this patch in the next day or two
unless someone objects.

2016-07-28  Steven G. Kargl  

PR fortran/70006
* io.c (gfc_resolve_dt): Use correct locus.
* resolve.c (resolve_branch): Ditto.

2016-07-28  Steven G. Kargl  

PR fortran/70006
* gfortran.dg/pr70006.f90: New test.

Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c(revision 238842)
+++ gcc/fortran/io.c(working copy)
@@ -3052,7 +3052,7 @@ gfc_resolve_dt (gfc_dt *dt, locus *loc)
   && dt->format_label->defined == ST_LABEL_UNKNOWN)
 {
   gfc_error ("FORMAT label %d at %L not defined", dt->format_label->value,
-&dt->format_label->where);
+loc);
   return false;
 }
 
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 238842)
+++ gcc/fortran/resolve.c   (working copy)
@@ -8966,7 +8966,7 @@ resolve_branch (gfc_st_label *label, gfc
   if (label->defined == ST_LABEL_UNKNOWN)
 {
   gfc_error ("Label %d referenced at %L is never defined", label->value,
-&label->where);
+&code->loc);
   return;
 }
 
Index: gcc/testsuite/gfortran.dg/pr70006.f90
===
--- gcc/testsuite/gfortran.dg/pr70006.f90   (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr70006.f90   (working copy)
@@ -0,0 +1,9 @@
+! { dg-do compile}
+program test
+   print 1, 'string 1' ! { dg-error "FORMAT label 1" " " { target *-*-* } 3 }
+   print 1, 'string 2' ! { dg-error "FORMAT label 1" " " { target *-*-* } 4 }
+!1 format(a)
+   goto 2 ! { dg-error "Label 2 referenced" " " { target *-*-* } 6 }
+   goto 2 ! { dg-error "Label 2 referenced" " " { target *-*-* } 7 }
+!2 continue
+end program
-- 
Steve

[Committed] PR fortran/71067 -- set a pointer to NULL

[Steve Kargl]

Committed as obvious.

2016-07-28  Steven G. Kargl  

PR fortran/71067
* decl.c (match_data_constant): On error, set 'result' to NULL.

2016-07-28  Steven G. Kargl  

PR fortran/71067
* gfortran.dg/pr71067_1.f90: New test.
* gfortran.dg/pr71067_2.f90: Ditto.

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 238824)
+++ gcc/fortran/decl.c  (working copy)
@@ -395,6 +395,7 @@ match_data_constant (gfc_expr **result)
 {
   gfc_error ("Symbol %qs must be a PARAMETER in DATA statement at %C",
 name);
+  *result = NULL;
   return MATCH_ERROR;
 }
   else if (dt_sym && gfc_fl_struct (dt_sym->attr.flavor))
Index: gcc/testsuite/gfortran.dg/pr71067_1.f90
===
--- gcc/testsuite/gfortran.dg/pr71067_1.f90 (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr71067_1.f90 (working copy)
@@ -0,0 +1,5 @@
+program p
+   integer :: i = 0
+   integer :: z(2)
+   data z /2*i/ ! { dg-error "must be a PARAMETER in DATA" }
+end
Index: gcc/testsuite/gfortran.dg/pr71067_2.f90
===
--- gcc/testsuite/gfortran.dg/pr71067_2.f90 (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr71067_2.f90 (working copy)
@@ -0,0 +1,7 @@
+! { dg-do compile }
+program p
+   integer :: a(2), b(2), c(2)
+   data a /2*b1'/ ! { dg-error "must be a PARAMETER in DATA" }
+   data b /2*o1'  ! { dg-error "must be a PARAMETER in DATA" }
+   data c /2*z1   ! { dg-error "must be a PARAMETER in DATA" }
+end
-- 
Steve

Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)

[Joseph Myers]

On Tue, 19 Jul 2016, Bernd Edlinger wrote:

> It is however not possible to remove the special handling by name
> altogether, because the glibc does not add the return_twice function
> attribute on _setjmp, __sigsetjmp and getcontext until today; a glibc
> BZ is filed at: https://sourceware.org/bugzilla/show_bug.cgi?id=20382

Once you have the attribute (__returns_twice__, of course, to be 
namespace-clean) in the headers, fixing old versions of the headers with 
fixincludes would seem appropriate (see what projects/beginner.html says 
about the special_function_p issue).

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

Re: [PATCH, rs6000, libgcc] Implement temporary solution for __divkc3 and __mulkc3

[Joseph Myers]

On Mon, 11 Jul 2016, Bill Schmidt wrote:

> Index: libgcc/config/rs6000/_divkc3.c
> ===
> --- libgcc/config/rs6000/_divkc3.c(revision 0)
> +++ libgcc/config/rs6000/_divkc3.c(working copy)
> @@ -0,0 +1,64 @@
> +typedef float KFtype __attribute__ ((mode (KF)));

Even temporary files in libgcc should have the proper copyright and 
license notices (reflecting where the code was copied from).

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

Re: Implement C _FloatN, _FloatNx types [version 3]

[Joseph Myers]

On Tue, 19 Jul 2016, James Greenhalgh wrote:

> These slightly complicate the description you give above as we now want
> two behaviours. Where the 16-bit floating point extensions are available,
> we want to use the native operations (FLT_EVAL_METHOD == 16). Where they
> are not available we want to use promotion to float (FLT_EVAL_METHOD == 0).

That's not a complication since TARGET_FLT_EVAL_METHOD already can and 
does depend on target options.

The complications are that the present excess precision support includes 
code to default the options (in c-opts.c:c_common_post_options and 
toplev.c:init_excess_precision), and then to use them (in 
tree.c:excess_precision_type and c-cppbuiltin.c:c_cpp_builtins), that (a) 
only handles the C99/C11 values, (b) ignores the possibility of types 
narrower than float and (c) assumes, when determining the defaults, that 
excess precision is x86-style, i.e. the back end pretending to have 
operations it does not have and C99-style excess precision being 
inefficient so only desired in standards conformance modes.

(a) and (b) are straightforward to fix.  But to fix (c), first you need to 
work out the design for how you actually want the compiler to behave for 
ARM / AArch64, for both FLT_EVAL_METHOD values, outside standards 
conformance modes.  Then you need to work out what that means for the 
initialization of the relevant variables, inside and outside standards 
conformance modes (remembering that for most targets, all the excess 
precision logic *can* be elided because there aren't any types narrower 
than float and so FLT_EVAL_METHOD == 0 really does mean no excess 
precision).  And you need to make all the functions I listed respect the 
new values and the new semantics for the value 0, and add appropriate 
testcases.

> I'm hoping that enabling _Float16 for ARM/AArch64 should not be too
> difficult with the groundwork in your patches, but I would appreciate any
> pointers on where I am likely to run in to trouble; I haven't worked in the
> front-end before.

The actual C front-end code, outside of the functions I listed, should not 
require any changes; it just uses excess_precision_type.

You do need to make appropriate arrangements for _Complex _Float16 
arithmetic.  See PR 63250.  For things to work when you don't promote 
(FLT_EVAL_METHOD == 16) you'll need to arrange for the relevant libgcc 
functions to be built for HCmode (cf. the powerpc float128 issue of 
needing to build them for KCmode to avoid the present duplicate copies of 
those functions).

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

[v3 PATCH] Implement C++17 variable templates for type traits.

[Ville Voutilainen]

Tested on Linux-x64.

2016-07-29  Ville Voutilainen  

Implement C++17 variable templates for type traits.
* include/std/chrono (treat_as_floating_point_v): New.
* include/std/ratio: (ratio_equal_v, ratio_not_equal_v)
(ratio_less_v, ratio_less_equal_v, ratio_greater_v)
(ratio_greater_equal_v): Likewise.
* include/std/system_error (is_error_code_enum_v)
(is_error_condition_enum_v): Likewise.
* include/std/tuple (tuple_size_v): Likewise.
* type_traits: (conjunction_v, disjunction_v, negation_v)
(is_void_v, is_null_pointer_v, is_integral_v, is_floating_point_v)
(is_array_v, is_pointer_v, is_lvalue_reference_v)
(is_rvalue_reference_v, is_member_object_pointer_v)
(is_member_function_pointer_v, is_enum_v, is_union_v)
(is_class_v, is_function_v, is_reference_v, is_arithmetic_v)
(is_fundamental_v, is_object_v, is_scalar_v, is_compound_v)
(is_member_pointer_v, is_const_v, is_volatile_v, is_trivial_v)
(is_trivially_copyable_v, is_standard_layout_v)
(is_pod_v, is_literal_type_v, is_empty_v, is_polymorphic_v)
(is_abstract_v, is_final_v, is_signed_v, is_unsigned_v)
(is_constructible_v, is_default_constructible_v)
(is_copy_constructible_v, is_move_constructible_v)
(is_assignable_v, is_copy_assignable_v, is_move_assignable_v)
(is_destructible_v, is_trivially_constructible_v)
(is_trivially_default_constructible_v)
 (is_trivially_copy_constructible_v, is_trivially_move_constructible_v)
(is_trivially_assignable_v, is_trivially_copy_assignable_v)
(is_trivially_move_assignable_v, is_trivially_destructible_v)
(is_nothrow_constructible_v, is_nothrow_default_constructible_v)
(is_nothrow_copy_constructible_v, is_nothrow_move_constructible_v)
(is_nothrow_assignable_v, is_nothrow_copy_assignable_v)
(is_nothrow_move_assignable_v, is_nothrow_destructible_v)
(has_virtual_destructor_v, alignment_of_v, rank_v, extent_v)
(is_same_v, is_base_of_v, is_convertible_v) : Likewise.
* testsuite/19_diagnostics/error_code/is_error_code_v.cc: Likewise.
* testsuite/20_util/duration/requirements/treat_as_floating_point_v.cc:
Likewise.
* testsuite/20_util/duration/requirements/treat_as_floating_point_v.cc:
Likewise.
* testsuite/20_util/ratio/requirements/ratio_equal_v.cc: Likewise.
* testsuite/20_util/tuple/tuple_size_v.cc: Likewise.
* testsuite/20_util/variable_templates_for_traits.cc: Likewise.


std_variable_templates_for_type_traits.diff.gz
Description: GNU Zip compressed data

Re: [PATCH PR71734] Add missed check that reference defined inside loop.

[H.J. Lu]

On Thu, Jul 28, 2016 at 6:49 AM, Yuri Rumyantsev  wrote:
> Richard,
>
> I prepare a patch which is based on yours. New test is also included.
> Bootstrapping and regression testing did not show any new failures.
> Is it OK for trunk?
>
> Thanks.
> ChangeLog:
> 2016-07-28  Yuri Rumyantsev  
>
> PR tree-optimization/71734
> * tree-ssa-loop-im.c (ref_indep_loop_p_1): Pass value of safelen
> attribute instead of REF_LOOP and use it.
> (ref_indep_loop_p_2): Use SAFELEN argument instead of REF_LOOP and
> set it for Loops having non-zero safelen attribute.
> (ref_indep_loop_p): Pass zero as initial value for safelen.
> gcc/testsuite/ChangeLog:
> * g++.dg/vect/pr70729-nest.cc: New test.
>

Does this cause

FAIL: libgomp.fortran/pr71734-1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution
test
FAIL: libgomp.fortran/pr71734-1.f90   -O3 -g  execution test
FAIL: libgomp.fortran/pr71734-2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution
test
FAIL: libgomp.fortran/pr71734-2.f90   -O3 -g  execution test

on AVX machines and

FAIL: libgomp.fortran/simd3.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution
test
FAIL: libgomp.fortran/simd3.f90   -O3 -g  execution test
FAIL: libgomp.fortran/simd4.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution
test
FAIL: libgomp.fortran/simd4.f90   -O3 -g  execution test

on non-AVX machines?

-- 
H.J.

Re: [PATCH] OpenACC routines in fortran modules

[Cesar Philippidis]

On 07/28/2016 02:55 AM, Tobias Burnus wrote:
> Cesar Philippidis wrote:
>> It turns out that the acc routine parallelism isn't being recorded in
>> fortran .mod files. This is a problem because then the ME can't validate
>> if a routine has compatible parallelism with the call site. 
> 
> Nothing against saving such information in .mod files. However, I wonder
> whether it can happen that one places such an 'acc routine' outside of a
> module in one file - and still accesses it from another file. In the simple
> non-ACC case, one can have:
> 
> !- one.f90 
> subroutine foo()
>   print *, "abc"
> end subroutine foo
> 
> ! two.f90 ---
> program example
>   call foo()
> end program example
> 
> where "foo()" is torn in without any information about it (except that it
> is a subroutine, does not require an explicit interface, and takes no
> arguments).
> 
> I don't know whether the ACC spec requires an explicit interface in that
> case (i.e. for acc routines); I bet it does - or at least should. In that

Jakub and I discussed this issue a while ago. There were two major
problems with treating calls to non-acc routines as errors. 1) What do
we do about intrinsic procedures, and 2) how should builtin and
libc/libm functions get handled? Jakub and I came to the conclusion that
the linker should resolve those issues, hence this patch
 which teaches
the lto wrapper to error when it encounters missing symbols. From a
compiler standpoint, if the user does something like this

!$acc parallel
...
call foo()
...
!$acc end parallel

and if foo isn't marked as an acc routine, then the compiler will treat
that function as having an implicit 'acc routine seq'.

Note that trunk currently generates an error if the user tries apply an
acc routine directive on an intrinsic routine. This patch teaches
gfortran to accept acc routine directives on those procedures. However,
note that those routines aren't automatically parallelized though, i.e.
they are effectively implemented as 'acc routine seq'.

> case, something like the following would be valid - and should be supported
> as well. (I don't know whether it currently is.)
>
> !- one.f90 
> subroutine foo()
>   !$acc routine gang
>    ! something
> end subroutine foo
> 
> ! two.f90 ---
> program example
>   INTERFACE
> subroutine foo()
>   !$acc routine gang
>   ! Nothing here
> end subroutine foo
>   END INTERFACE
> 
>   call foo()
> end program example
> 
> Namely, a replication of the declaration of the procedure, including
> the "acc routine", in the 'interface'.
> (If one concats the two files, I would also expect an error with -fopenacc,
> if the "acc routine" doesn't match between "foo" and the "foo" in the
> "interface" block.)

I tested this case and it works. There is, however, a problem with
mismatched routine clauses. See PR72741 that Thomas filed recently.

> Otherwise: Have you checked whether an unmodified gfortran still accepts the
> .mod file written by the patched gfortran - and vice versa? Especially if
> -fopenacc is not used, backward compatibility of .mod files is a goal.
> (Even though we often have to bump the .mod version for major releases.)

I just tested this situation, and neither backward or forward compatible
isn't preserved. Basically, this patch introduces a mandatory
OACC_FUNCTION_ field inside the module file. Perhaps I should make that
field optional. At least that way we'd maintain backwards compatibility.
Is there something I can do to maintain forward compatibility?

Cesar

Re: [RFC, v2] Test coverage for --param boundary values

[Joseph Myers]

On Mon, 18 Jul 2016, Martin Liška wrote:

> Well, I can imaging a guard which will test whether 
> "$objdir/../../params.options" file exits, and if so, then the tests are 
> executed? Is it acceptable approach?

The correct way to test for build-tree testing is [info exists 
TESTING_IN_BUILD_TREE].  When testing outside the build tree, you should 
not assume anything about directories outside of the test and source 
directories, meaning you should not test for existence of paths in 
$objdir/../ in that case.

(The preferable approach is to factor out the code generating this file so 
it can be run from the testsuite.  Then you don't need to distinguish 
build-tree and other testing at all.)

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

PR fortran/71730 -- Patch

[Steve Kargl]

I plan to commit the following patch in the next day or
two if no one objects.  It falls into the trivially 
correct category.

2016-07-28  Steven G. Kargl  

PR fortran/71730
* decl.c (match_data_constant): Set 'result' to NULL in error case.
(char_len_param_value): Check return for gfc_reduce_init_expr().

2016-07-28  Steven G. Kargl  

PR fortran/71730
* gfortran.dg/pr71730.f90: New test.
* gfortran.dg/bounds_check_strlen_2.f90: Fix invalid code.
* gfortran.dg/array_constructor_27.f03: Update dg-error message.
* gfortran.dg/array_constructor_26.f03: Ditto.

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 238824)
+++ gcc/fortran/decl.c  (working copy)
@@ -395,6 +395,7 @@ match_data_constant (gfc_expr **result)
 {
   gfc_error ("Symbol %qs must be a PARAMETER in DATA statement at %C",
 name);
+  *result = NULL;
   return MATCH_ERROR;
 }
   else if (dt_sym && gfc_fl_struct (dt_sym->attr.flavor))
@@ -905,6 +906,7 @@ char_len_param_value (gfc_expr **expr, b
 goto syntax;
   else if ((*expr)->expr_type == EXPR_VARIABLE)
 {
+  bool t;
   gfc_expr *e;
 
   e = gfc_copy_expr (*expr);
@@ -916,7 +918,15 @@ char_len_param_value (gfc_expr **expr, b
  && e->ref->u.ar.dimen_type[0] == DIMEN_RANGE)
goto syntax;
 
-  gfc_reduce_init_expr (e);
+  t = gfc_reduce_init_expr (e);
+
+  if (!t && (e->ts.type == BT_UNKNOWN
+&& e->symtree->n.sym->attr.untyped == 1
+&& e->symtree->n.sym->ns->seen_implicit_none == 1))
+   {
+ gfc_free_expr (e);
+ goto syntax;
+   }
 
   if ((e->ref && e->ref->type == REF_ARRAY
   && e->ref->u.ar.type != AR_ELEMENT)
Index: gcc/testsuite/gfortran.dg/pr71730.f90
===
--- gcc/testsuite/gfortran.dg/pr71730.f90   (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr71730.f90   (working copy)
@@ -0,0 +1,5 @@
+! { dg-do compile }
+subroutine foo
+  implicit none
+  character(len=bar) :: a ! { dg-error "Scalar INTEGER expression" }
+end subroutine foo
Index: gcc/testsuite/gfortran.dg/bounds_check_strlen_2.f90
===
--- gcc/testsuite/gfortran.dg/bounds_check_strlen_2.f90 (revision 238829)
+++ gcc/testsuite/gfortran.dg/bounds_check_strlen_2.f90 (working copy)
@@ -11,8 +11,8 @@ CONTAINS
 
   SUBROUTINE test (str, n)
 IMPLICIT NONE
-CHARACTER(len=n) :: str
 INTEGER :: n
+CHARACTER(len=n) :: str
   END SUBROUTINE test
 
   SUBROUTINE test2 (str)
Index: gcc/testsuite/gfortran.dg/array_constructor_27.f03
===
--- gcc/testsuite/gfortran.dg/array_constructor_27.f03  (revision 238829)
+++ gcc/testsuite/gfortran.dg/array_constructor_27.f03  (working copy)
@@ -8,8 +8,7 @@
 implicit none
 
 type t
-  character (a) :: arr (1) = [ "a" ]
-  ! { dg-error "specification expression" "" { target *-*-* } 11 }
+  character (a) :: arr (1) = [ "a" ] ! { dg-error "Scalar INTEGER expression" }
 end type t
 
 end
Index: gcc/testsuite/gfortran.dg/array_constructor_26.f03
===
--- gcc/testsuite/gfortran.dg/array_constructor_26.f03  (revision 238829)
+++ gcc/testsuite/gfortran.dg/array_constructor_26.f03  (working copy)
@@ -10,7 +10,6 @@ MODULE WinData
   INTEGER (1), PARAMETER :: MAXFLD = 25_1, MAXHED = 5_1, MAXCHR = 80_1
   integer :: i
   TYPE TWindowData
-CHARACTER (MAX_FLD_HED, 1) :: DWFdHd(MAXFLD) = [(" ", i = 1, MAXFLD)]
-! { dg-error "specification expression" "" { target *-*-* } 13 }
+CHARACTER (MAX_FLD_HED, 1) :: DWFdHd(MAXFLD) = [(" ", i = 1, MAXFLD)] ! { 
dg-error "Scalar INTEGER expression" }
   END TYPE TWindowData
 END MODULE WinData
-- 
Steve

Re: [PATCH 1/3] (v2) On-demand locations within string-literals

[Martin Sebor]

On 07/28/2016 02:38 PM, Martin Sebor wrote:

On 07/28/2016 02:12 PM, David Malcolm wrote:

On Wed, 2016-07-27 at 23:41 +0100, Manuel López-Ibáñez wrote:

On 27 July 2016 at 15:30, David Malcolm  wrote:

Perhaps it could live for now in c-format.c, since it is the only
place using it?


Martin Sebor [CC-ed] wants to use it from the middle-end:
   https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01088.html
so it's unclear to me that c-format.c would be a better location.


Fine. He will have to figure out how to get a cpp_reader from the
middle-end, though.


It seems to me that on-demand reconstruction of source locations for
STRING_CST nodes is inherently frontend-specific: unless we have the
frontend record the information in some fe-independent way (which I
assume we *don't* want to do, for space-efficiency), we need to be able
to effectively re-run part of the frontend.

So maybe this needs to be a langhook; the c-family can use the global
cpp_reader * there, and everything else can return a "not supported"
code if a diagnostic requests substring location information (and the
diagnostic needs to be able to cope with that).


The problem with the lanhook approach, as I learned from my first
-Wformat-length attempt, is that it doesn't make the front end
implementation available to LTO.  So passes that run late enough
with LTO (like the latest version of the -Wformat-length pass
does) would not be bale to make use of it.


I'm sorry, I didn't mean to sound like I was dismissing the idea.
I agree that string processing is language and front-end specific.
Having the middle end call back into the front-end also seems like
the right thing to do, not just to make this case work, but others
like it as well.  So perhaps the problem to solve is how to teach
LTO to talk to the front end.  One way to do it would be to build
the front ends as shared libraries.

Martin

[patch] Some testsuite cleanup

[Jonathan Wakely]

This is a set of small patches for issues in the testsuite that I
noticed while working on a big change (coming soon).

Self-explanatory:

   Fix invalid dg-do directives in libstdc++ tests
   
   * testsuite/22_locale/conversions/string/1.cc: Remove unintended

   dg-do compile directive.
   * testsuite/26_numerics/headers/cmath/fabs_inline.cc: Fix syntax of
   dg-do directive.
   * testsuite/26_numerics/valarray/const_bracket.cc: Likewise.

The dg-options for FreeBSD and Dragonfly should have included
-std=gnu++11, or should have used dg-additional-options to add to,
rather than override, the common dg-options.

   Use dg-additional-options in libstdc++ tests
   
   * testsuite/17_intro/headers/c++2011/stdc++.cc: Change target-specific

   dg-options to dg-additional-options so that default options are used.
   * testsuite/17_intro/headers/c++2011/stdc++_multiple_inclusion.cc:
   Likewise.
   * testsuite/17_intro/headers/c++2014/stdc++.cc: Likewise.
   * testsuite/17_intro/headers/c++2014/stdc++_multiple_inclusion.cc:
   Likewise.
   * testsuite/29_atomics/atomic_flag/test_and_set/explicit-hle.cc:
   Use dg-additional-options instead of repeating the common options.

When I added _Temporary_object to vector recently I updated the
construct/destroy counts in this test to match, but the changes only
apply for C++11 and later. This makes the test pass whether run as
C++98 or C++11 and later.

   Fix std::vector test to pass in C++98 mode
   
   * testsuite/23_containers/vector/check_construct_destroy.cc: Account

   for different construct/destroy counts in C++98 mode.

The dg-prune-output directives in these tests are needed to prune some
additional errors that are only issued in C++98 mode, but the line
numbers had got out of date. I've replaced the hardcoded numbers with
strings that will stay valid.

   Fix DR 438 container tests to pass in C++98 mode
   
   * testsuite/23_containers/deque/requirements/dr438/assign_neg.cc:

   Adjust dg-prune-output pattern for error in C++98 mode.
   * testsuite/23_containers/deque/requirements/dr438/
   constructor_1_neg.cc: Likewise.
   * testsuite/23_containers/deque/requirements/dr438/
   constructor_2_neg.cc: Likewise.
   * testsuite/23_containers/deque/requirements/dr438/insert_neg.cc:
   Likewise.
   * testsuite/23_containers/list/requirements/dr438/assign_neg.cc:
   Likewise.
   * testsuite/23_containers/list/requirements/dr438/
   constructor_1_neg.cc: Likewise.
   * testsuite/23_containers/list/requirements/dr438/insert_neg.cc:
   Likewise.
   * testsuite/23_containers/vector/requirements/dr438/assign_neg.cc:
   Likewise.
   * testsuite/23_containers/vector/requirements/dr438/
   constructor_1_neg.cc: Likewise.
   * testsuite/23_containers/vector/requirements/dr438/
   constructor_2_neg.cc: Likewise.
   * testsuite/23_containers/vector/requirements/dr438/insert_neg.cc:
   Likewise.

Tested x86_64-linux, committed to trunk.


commit 9afdeaa821412a2311a4ede6b77b032a99a94f2f
Author: Jonathan Wakely 
Date:   Thu Jul 28 21:13:59 2016 +0100

Fix DR 438 container tests to pass in C++98 mode

	* testsuite/23_containers/deque/requirements/dr438/assign_neg.cc:
	Adjust dg-prune-output pattern for error in C++98 mode.
	* testsuite/23_containers/deque/requirements/dr438/
	constructor_1_neg.cc: Likewise.
	* testsuite/23_containers/deque/requirements/dr438/
	constructor_2_neg.cc: Likewise.
	* testsuite/23_containers/deque/requirements/dr438/insert_neg.cc:
	Likewise.
	* testsuite/23_containers/list/requirements/dr438/assign_neg.cc:
	Likewise.
	* testsuite/23_containers/list/requirements/dr438/
	constructor_1_neg.cc: Likewise.
	* testsuite/23_containers/list/requirements/dr438/insert_neg.cc:
	Likewise.
	* testsuite/23_containers/vector/requirements/dr438/assign_neg.cc:
	Likewise.
	* testsuite/23_containers/vector/requirements/dr438/
	constructor_1_neg.cc: Likewise.
	* testsuite/23_containers/vector/requirements/dr438/
	constructor_2_neg.cc: Likewise.
	* testsuite/23_containers/vector/requirements/dr438/insert_neg.cc:
	Likewise.

diff --git a/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/assign_neg.cc b/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/assign_neg.cc
index 7851243..49a05e6 100644
--- a/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/assign_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/assign_neg.cc
@@ -18,7 +18,7 @@
 // .
 
 // { dg-do compile }
-// { dg-prune-output 1879 }
+// { dg-prune-output "no matching function .*_M_fill_assign" }
 
 #include 
 
diff --git a/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc b/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/construct

Re: [PATCH] Fix wrong code on aarch64 due to paradoxical subreg

[Bernd Edlinger]

Hi,

On 07/27/16 23:31, Jeff Law wrote:
> So you're stumbling into another really interesting area.
>

Absolutely, I am just too curious what's going on here ;-)


> I can hazard a guess that the reason we create the paradoxical SUBREG
> rather than a zero or sign extension is because various optimizers know
> that the upper bits in a paradoxical are don't care bits and may make
> transformations with that knowledge.
>
> Once you turn that into a zero/sign extend, then the rest of the
> optimizers must preserve the zero/sign extension property -- they have
> no way of knowing the bits were don't cares.
>
> So it's not necessarily clear that your change results in generally
> better code or not.
>
> More importantly, it really feels like you're papering over a real bug
> elsewhere.  AFAICT the use of a paradoxical subreg here is safe.  So the
> real bug ought to be downstream of this point.  Several folks have
> pointed at reload, which would certainly be a point ripe for a
> paradoxical subreg problem.


I have looked again at the test case of PR 71779 and discovered
something that I wanted to discuss here.

I have tried to figure out what made combine change this:


(insn 1048 1047 1049 101 (set (zero_extract:DI (reg/v:DI 191 [ 
obj1D.17943 ])
 (const_int 32 [0x20])
 (const_int 0 [0]))
 (reg/f:DI 481)) isl_input.c:2496 691 {*insv_regdi}
  (nil))
(insn 1049 1048 1050 101 (set (zero_extract:DI (reg/v:DI 191 [ 
obj1D.17943 ])
 (const_int 32 [0x20])
 (const_int 32 [0x20]))
 (reg/v/f:DI 145 [ SR.327D.17957 ])) isl_input.c:2496 691 
{*insv_regdi}
  (expr_list:REG_DEAD (reg/v/f:DI 145 [ SR.327D.17957 ])
 (nil)))
(insn 1050 1049 1051 101 (set (reg:DI 1 x1)
 (reg/v:DI 191 [ obj1D.17943 ])) isl_input.c:2496 50 
{*movdi_aarch64}
  (expr_list:REG_DEAD (reg/v:DI 191 [ obj1D.17943 ])
 (nil)))


into that (which is wrong because reg 481 has undefined bits
in insn 1050):


(insn 1048 1047 1049 101 (set (zero_extract:DI (reg/v:DI 191 [ 
obj1D.17943 ])
 (const_int 32 [0x20])
 (const_int 0 [0]))
 (reg/f:DI 481)) isl_input.c:2496 691 {*insv_regdi}
  (nil))
(insn 1049 1048 1050 101 (set (zero_extract:DI (reg/v:DI 191 [ 
obj1D.17943 ])
 (const_int 32 [0x20])
 (const_int 32 [0x20]))
 (reg/v/f:DI 145 [ SR.327D.17957 ])) isl_input.c:2496 691 
{*insv_regdi}
  (expr_list:REG_DEAD (reg/v/f:DI 145 [ SR.327D.17957 ])
 (nil)))
(insn 1050 1049 1051 101 (set (reg:DI 1 x1)
 (ior:DI (ashift:DI (reg/v/f:DI 145 [ SR.327D.17957 ])
 (const_int 32 [0x20]))
 (reg/f:DI 481))) isl_input.c:2496 50 {*movdi_aarch64}
  (nil))


The interesting fact is that combine did that while it
was only considering 1048, 1049 -> 1050,
and not the instruction with the paradoxical subreg:

(insn 1047 1044 1048 101 (set (reg/f:DI 481)
 (subreg:DI (reg/f:SI 545) 0)) isl_input.c:2496 50 {*movdi_aarch64}
  (nil))

I found by debugging that expand_field_assignment
was trying to build:

(and:DI (reg/f:DI 481)
 (const_int -4294967296 [0x]))

with this statement:

   masked = simplify_gen_binary (ASHIFT, compute_mode,
 simplify_gen_binary (
   AND, compute_mode,
   gen_lowpart (compute_mode, 
SET_SRC (x)),
   mask),
 pos);

but the result is just (reg/f:DI 481) !

I debugged and found the first wrong result in
rtlanal.c (nonzero_bits1) where the following if-statement
tells us that the upper 32 bits of reg 481 must be zero:

   switch (code)
 {
 case REG:
#if defined(POINTERS_EXTEND_UNSIGNED)
   /* If pointers extend unsigned and this is a pointer in Pmode, 
say that
  all the bits above ptr_mode are known to be zero.  */
   /* As we do not know which address space the pointer is referring to,
  we can do this only if the target does not support different 
pointer
  or address modes depending on the address space.  */
   if (target_default_pointer_address_modes_p ()
   && POINTERS_EXTEND_UNSIGNED && GET_MODE (x) == Pmode
   && REG_POINTER (x)
   && !targetm.have_ptr_extend ())
 nonzero &= GET_MODE_MASK (ptr_mode);
#endif


Pmode = DImode, ptr_mode=SImode, and REG_POINTER(x) is true.

Yes, the value is actually a pointer!

Which means, that it is not safe to extend a pointer from SI to DI
with anything but a zero-extend.

And if I remove this statement the wrong code is still not fixed.
So there must be more places where the similar assumptions are
made.

However, PR 70903 is not about pointers, and uses a mode where
Pmode=ptr_mode=DImode, so there must be a different as hard to track
down reason why this did not work out right.


So the question is, if the paradoxical

Re: [v3 PATCH] Implement std::string_view and P0254r2, Integrating std::string_view and std::string.

[Jonathan Wakely]

On 27/07/16 17:53 +0100, Jonathan Wakely wrote:

On 25/07/16 00:41 +0300, Ville Voutilainen wrote:

Changelog as it was before, tested on Linux-x64.

I haven't fixed all section references of string tests, and I haven't
added section references
to string_view tests, because they didn't have any. I also haven't
added tests that test the various
exception-throwing cases for the various operations. Doing those changes is
a) going to change many many files
b) probably not urgent
so here's a modest suggestion:
let's put this patch in, and tweak the section references in the other
tests later with separate patches,
as well as add more comprehensive exception-tests.

Ok for trunk?


+#if __cplusplus > 201402L
+  /**
+   *  @brief  Append a string_view.
+   *  @param __sv  The string_view to be appended.
+   *  @return  Reference to this string.
+   */
+  basic_string& append(__sv_type __sv)
+  {
+   return this->append(__sv.data(), __sv.size());
+  }


The new member functions in std::string aren't instantiated in the
library, because the relevant files are compiled as C++14, so any file
which doesn't inline the new functions (e.g. at -O0) gets undefined
references. I'll fix that after I update the baseline files.

Re: [PATCH] Move allocator in std::string and RB tree move constructors

[Jonathan Wakely]

On 22/07/16 16:06 +0100, Jonathan Wakely wrote:

The move constructors for strings and RB trees were not move
constructing the allocator.

PR libstdc++/71964
* include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI]
(basic_string::_Alloc_hider(pointer, _Alloc&&)): Add constructor.


This new constructor adds a new symbol, which needs a new symbol
version (so the abi-check is failing currently).

I'll update the baselines and add that new version, and then I can
also un-revert the basic_string::allocator_type::pointer changes I did
recently.

Re: [PATCH 1/3] (v2) On-demand locations within string-literals

[Martin Sebor]

On 07/28/2016 02:12 PM, David Malcolm wrote:

On Wed, 2016-07-27 at 23:41 +0100, Manuel López-Ibáñez wrote:

On 27 July 2016 at 15:30, David Malcolm  wrote:

Perhaps it could live for now in c-format.c, since it is the only
place using it?


Martin Sebor [CC-ed] wants to use it from the middle-end:
   https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01088.html
so it's unclear to me that c-format.c would be a better location.


Fine. He will have to figure out how to get a cpp_reader from the
middle-end, though.


It seems to me that on-demand reconstruction of source locations for
STRING_CST nodes is inherently frontend-specific: unless we have the
frontend record the information in some fe-independent way (which I
assume we *don't* want to do, for space-efficiency), we need to be able
to effectively re-run part of the frontend.

So maybe this needs to be a langhook; the c-family can use the global
cpp_reader * there, and everything else can return a "not supported"
code if a diagnostic requests substring location information (and the
diagnostic needs to be able to cope with that).


The problem with the lanhook approach, as I learned from my first
-Wformat-length attempt, is that it doesn't make the front end
implementation available to LTO.  So passes that run late enough
with LTO (like the latest version of the -Wformat-length pass
does) would not be bale to make use of it.

Martin

[PATCH] aarch64: Add split-stack initial support

[Adhemerval Zanella]

From: Adhemerval Zanella 

This patch adds the split-stack support on aarch64 (PR #67877).  As for
other ports this patch should be used along with glibc and gold support.

The support is done similar to other architectures: a __private_ss field is
added on TCB in glibc, a target-specific __morestack implementation and
helper functions are added in libgcc and compiler supported adjustments
(split-stack prologue, va_start for argument handling).  I also plan to
send the gold support to adjust stack allocation acrosss split-stack
and default code calls.

Current approach is similar to powerpc one: at most 2 GB of stack allocation
is support so stack adjustments can be done with 2 instructions (either just
a movn plus nop or a movn followed by movk).  The morestack call is non
standard with x10 hollding the requested stack pointer and x11 the required
stack size to be copied.  Also function arguments on the old stack are
accessed based on a value relative to the stack pointer, so x10 is used to
hold theold stack value.  Unwinding is handled by a personality routine that
knows how to find stack segments.

Split-stack prologue on function entry is as follow (this goes before the
usual function prologue):

mrsx9, tpidr_el0
movx10, -
nop/movk
addx10, sp, x10
ldrx9, [x9, 16]
cmpx10, x9
b.csenough
stpx30, [sp, -16]movx11, 
movx11, 
bl __morestack
ldpx30, [sp], 16
ret
enough:
# usual function prologue, modified a little at the end to set up the
# arg_pointer in x10, starts here.  The arg_pointer is initialized,
# if it is used, with
mov x11, 
add x10, x29, x11
b.csfunction
mov x10, x28
function:

Notes:
 1. Even if a function does not allocate a stack frame, a split-stack prologue
is created.  It is to avoid issues with tail call for external symbols
which might require linker adjustment (libgo/runtime/go-varargs.c).

 2. Basic-block reordering (enabled with -O2) will move split-stack TCB ldr
to after the required stack calculation.

 3. Similar to powerpc, When the linker detects a call from split-stack to
non-split-stack code, it adds 16k (or more) to the value found in "allocate"
instructions (so non-split-stack code gets a larger stack).  The amount is
tunable by a linker option.  The edit means aarch64 does not need to
implement __morestack_non_split, necessary on x86 because insufficient
space is available there to edit the stack comparison code.  This feature
is only implemented in the GNU gold linker.

 4. AArch64 does not handle >2G stack initially and although it is possible
to implement it, limiting to 2G allows to materize the allocation with
only 2 instructions (mov + movk) and thus simplifying the linker
adjustments required.  Supporting multiple threads each requiring more
than 2G of stack is probably not that important, and likely to OOM at
run time.

 5. The TCB support on GLIBC is meant to be included in version 2.25 [1].

I tested bootstrapping on aarch64-linux-gnu and although still digesting
the results I saw no regression.  All cgo tests are passing, although based
on previous reports in other archs gold support should be present to avoid
issues on split calling non-split code.

libgcc/ChangeLog:

* libgcc/config.host: Use t-stack and t-statck-aarch64 for
aarch64*-*-linux.
* libgcc/config/aarch64/morestack-c.c: New file.
* libgcc/config/aarch64/morestack.S: Likewise.
* libgcc/config/aarch64/t-stack-aarch64: Likewise.
* libgcc/generic-morestack.c (__splitstack_find): Add aarch64-specific
code.

gcc/ChangeLog:

* common/config/aarch64/aarch64-common.c
(aarch64_supports_split_stack): New function.
(TARGET_SUPPORTS_SPLIT_STACK): New macro.
* gcc/config/aarch64/aarch64-linux.h (TARGET_ASM_FILE_END): Remove
macro.
* gcc/config/aarch64/aarch64-protos.h: Add
aarch64_expand_split_stack_prologue and
aarch64_split_stack_space_check.
* gcc/config/aarch64/aarch64.c (aarch64_expand_prologue): Setup the
argument pointer (x10) for split-stack.
(aarch64_expand_builtin_va_start): Use internal argument pointer
instead of virtual_incoming_args_rtx.
(aarch64_expand_split_stack_prologue): New function.
(aarch64_file_end): Emit the split-stack note sections.
(aarch64_internal_arg_pointer): Likewise.
(aarch64_live_on_entry): Set the argument pointer for split-stack.
(aarch64_split_stack_space_check): Likewise.
(TARGET_ASM_FILE_END): New macro.
(TARGET_INTERNAL_ARG_POINTER): Likewise.
* gcc/config/aarch64/aarch64.h (aarch64_frame): Add
split_stack_arg_pointer to setup the argument pointer when using
split-stack.
* gcc/co

Re: [PATCH 1/3] (v2) On-demand locations within string-literals

[David Malcolm]

On Wed, 2016-07-27 at 23:41 +0100, Manuel López-Ibáñez wrote:
> On 27 July 2016 at 15:30, David Malcolm  wrote:
> > > Perhaps it could live for now in c-format.c, since it is the only
> > > place using it?
> > 
> > Martin Sebor [CC-ed] wants to use it from the middle-end:
> >   https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01088.html
> > so it's unclear to me that c-format.c would be a better location.
> 
> Fine. He will have to figure out how to get a cpp_reader from the
> middle-end, though.

It seems to me that on-demand reconstruction of source locations for
STRING_CST nodes is inherently frontend-specific: unless we have the
frontend record the information in some fe-independent way (which I
assume we *don't* want to do, for space-efficiency), we need to be able
to effectively re-run part of the frontend.

So maybe this needs to be a langhook; the c-family can use the global
cpp_reader * there, and everything else can return a "not supported"
code if a diagnostic requests substring location information (and the
diagnostic needs to be able to cope with that).

> > There are various places it could live; but getting it working took
> > a
> > lot of effort to achieve - the currently proposed mixture of
> > libcpp,
> > input.c and c-format.c for the locations of the various pieces
> > works
> > (for example, auto_vec isn't available in libcpp).
> 
> I don't doubt it. I tried to do something similar in the past and I
> failed, this is why I ended up with the poor approximation that was
> in
> place until now. This is a significant step forward.

Thanks (for the current implementation, and for the kind words).

> Is libcpp still C? When would be the time to move it to C++ already
> and start using common utilities?

libcpp is very much C++: I converted the linemap types to use
inheritance as part of gcc 6 (and it helped a lot when implementing the
range-tracking stuff).

> Also, moving vec.h, sbitmap, etc to their own directory/library so
> that they can be used by other parts of the compiler (hey! maybe even
> by other parts of the toolchain?) is desirable. Richard has said in
> the past that he supports such moves. Did I understand correctly
> Richard?

FWIW, I'd want the selftest framework there too; part of the reason
things are in input.c rather than libcpp in the current patch is that
selftests aren't yet available from libcpp (and reworking that seems
orthogonal).

> > Given that both Martin and I have candidate patches that are
> > touching
> > the same area, I'd prefer to focus on getting this code in to
> > trunk,
> > rather than rewrite it out-of-tree, so that we can at least have
> > the
> > improvement to location-handling for Wformat.  Once the code is in
> > the
> > tree, it should be easier to figure out how to access it from the
> > middle-end.
> 
> Sure, I think this version is fine. I'm a big proponent of
> step-by-step, even if the steps are only approximations to the
> optimal
> solution :)
> It may be enough to motivate someone else more capable to improve
> over
> my poor approximations ;-)

:)

> > > [*] In an ideal world, we would have a language-agnostic
> > > diagnostics
> > > library
> > > that would include line-map and that would be used by libcpp and
> > > the
> > > rest of
> > > GCC, so that we can remove all the error-routines in libcpp and
> > > the
> > > awkward
> > > glue code that ties it into diagnostics.c.,
> > 
> > Agreed, though that may have to wait until gcc 8 at this point.
> > (Given that the proposed diagnostics library would use line maps,
> > and
> > would be used by libcpp, would it make sense to move the
> > diagnostics
> > into libcpp itself?  Diagnostics would seem to be intimately
> > related to
> > location-tracking)
> 
> I don't think so. There is nothing in diagnostic.* pretty-print.*
> input.* line-map.* that requires libcpp (and only two mentions of
> tree
> that could be easily abstracted out). This was a deliberate design
> goal of Gabriel and followed by most of us later working on
> diagnostics. Of course, cpp may make use of the new library, but also
> other parts of the toolchain (GAS?). The main obstacle I faced when
> trying to do this move was the build machinery to make both libcpp
> and
> gcc build and statically link with this new library.
> 
> Once that move is done, the main abstraction challenge to remove the
> glue is that libcpp has its own flags for options and diagnostics
> that
> are independent from those of gcc (see c_cpp_error in c-common.c). It
> would be great if libcpp used the common flags, but then one would
> have to figure out a way to reorder things so that the diagnostic
> library, libcpp and gcc can use (or avoid being dependent on) the
> same
> flags.

Thanks.

Dave

Re: [PATCH, 2 of 4], Enhance PowerPC vec_extract support for power8/power9 machines

[Michael Meissner]

On Thu, Jul 28, 2016 at 04:57:53AM -0500, Segher Boessenkool wrote:
> On Wed, Jul 27, 2016 at 05:16:28PM -0400, Michael Meissner wrote:
> > * config/rs6000/vsx.md (UNSPEC_VSX_VSLO): New unspecs.
> > (UNSPEC_VSX_EXTRACT): Likewise.
> 
> "New unspec".

Thanks.

> > (VEC_EXTRACT_OPTIMIZE_P): New macro to say whether we can optmize
> > vec_extract on 64-bit ISA 2.07 systems and newer.
> 
> "optimize".

Thanks.

> > --- gcc/config/rs6000/rs6000-protos.h   (revision 238775)
> > +++ gcc/config/rs6000/rs6000-protos.h   (working copy)
> > @@ -62,6 +62,7 @@ extern void rs6000_expand_vector_init (r
> >  extern void paired_expand_vector_init (rtx, rtx);
> >  extern void rs6000_expand_vector_set (rtx, rtx, int);
> >  extern void rs6000_expand_vector_extract (rtx, rtx, rtx);
> > +extern void rs6000_split_vec_extract_var (rtx, rtx, rtx, rtx, rtx);
> >  extern bool altivec_expand_vec_perm_const (rtx op[4]);
> >  extern void altivec_expand_vec_perm_le (rtx op[4]);
> >  extern bool rs6000_expand_vec_perm_const (rtx op[4]);
> 
> This isn't in the changelog.

Yes it is.

2016-07-27  Michael Meissner  

* config/rs6000/rs6000-protos.h (rs6000_split_vec_extract_var):
New declaration.

> > +  /* For little endian, adjust element ordering.  For V2DI/V2DF, we 
> > can use
> > +an XOR, otherwise we need to subtract.  The shift amount is so VSLO
> > +will shift the element into the upper position (adding 3 to convert a
> > +byte shift into a bit shift). */
> 
> Two spaces after dot.

Thanks.

> > +;; Variable V2DI/V2DF extract
> > +(define_insn_and_split "vsx_extract__var"
> > +  [(set (match_operand: 0 "gpc_reg_operand" "=v")
> > +   (unspec: [(match_operand:VSX_D 1 "input_operand" "v")
> > +(match_operand:DI 2 "gpc_reg_operand" "r")]
> > +   UNSPEC_VSX_EXTRACT))
> > +   (clobber (match_scratch:DI 3 "=r"))
> > +   (clobber (match_scratch:V2DI 4 "=&v"))]
> > +  "VECTOR_MEM_VSX_P (mode) && VEC_EXTRACT_OPTIMIZE_P"
> > +  "#"
> > +  "&& reload_completed"
> > +  [(const_int 0)]
> > +{
> > +  rs6000_split_vec_extract_var (operands[0], operands[1], operands[2],
> > +   operands[3], operands[4]);
> > +  DONE;
> > +})
> 
> Why reload_completed?  Can it not run earlier?

This patch can perhaps run earlier, but the next patch that adds optimizing
memory references cannot be.

In order to change memory addresses, I need to know exactly which register set
(GPR, traditional floating point, and traditional Altivec register), and what
address modes they support.  Keeping it until after reload will also allow for
some flexibility if the vector was not in register, it can just access the
memory value, instead of forcing it to be in a register.

> > +/* Macro to say whether we can optimize vector extracts.  */
> > +#define VEC_EXTRACT_OPTIMIZE_P (TARGET_DIRECT_MOVE 
> > \
> > +&& TARGET_POWERPC64\
> > +&& TARGET_UPPER_REGS_DI)
> 
> I'm not a big fan of this name.  "Optimize" will quickly become dated,
> everyone will take the current new hot thing for granted, and then when
> you want to optimise even more (say, for ISA 6.0 or whatever) the name
> is really out of place.
> 
> But I don't know a much better name either.

I changed it to TARGET_DIRECT_MOVE_64BIT, which hopefully is clearer of what
exactly we need.  In particular, the calculation of the bit shift is done in
the GPR and direct move creates teh vector used by VSLO to do a byte shift.

> > --- gcc/testsuite/gcc.target/powerpc/vec-extract-1.c(revision 0)
> > +++ gcc/testsuite/gcc.target/powerpc/vec-extract-1.c(revision 0)
> > @@ -0,0 +1,27 @@
> > +/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
> 
> Maybe you can add a "run" test as well?

I added the run tests on July 21st that explicitly checks for just about every
combination that is being optimized by these paches to make sure it generates
the correct code.
 
> Looks good otherwise, okay for trunk with those nits fixed.

Here is the revised patch that I will check in after the tests are rerun:

[gcc, patch #2]
2016-07-28  Michael Meissner  

* config/rs6000/rs6000-protos.h (rs6000_split_vec_extract_var):
New declaration.
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
Add support for vec_extract of vector double or vector long having
a variable element number on 64-bit ISA 2.07 systems or newer.
* config/rs6000/rs6000.c (rs6000_expand_vector_extract):
Likewise.
(rs6000_split_vec_extract_var): New function to split a
vec_extract built-in function with variable element number.
(rtx_is_swappable_p): Variable vec_extracts and shifts are not
swappable.
* config/rs6000/vsx.md (UNSPEC_VSX_VSLO): New unspec.
(UNSPEC_VSX_EXTRACT): Likewise.
(vsx_extract_, VSX_D iterator):

Re: Implement -Wswitch-fallthrough

[Marek Polacek]

On Tue, Jul 12, 2016 at 10:10:23AM -0600, Jeff Law wrote:
> On 07/11/2016 01:43 PM, Marek Polacek wrote:
> > The switch fallthrough has been widely considered a design defect in C, a
> > misfeature or, to use Marshall Cline's definition, evil.  The overwhelming
> > majority of the time you don't want to fall through to the next case, but 
> > it is
> > easy to forget to "break" at the end of the case, making this far too error
> > prone.  Yet GCC (and probably other compilers, too) doesn't have the 
> > ability to
> > warn in this case.  A feature request for such warning was opened back in 
> > 2002,
> > but it's mostly been untouched since.  But then the [[fallthrough]] 
> > attribute was
> > approved for C++17 [1], and that's what has got me to do all this.
> [ ... ]
> This is going to be rather contentious.  So as we're hashing through that,
> can you split off the patches which fix bugs rather than those which add
> fallthru annotations?

To (belatedly) answer this, I posted
 to address this.

Marek

Re: Implement -Wswitch-fallthrough

[Marek Polacek]

Coming back to this...

On Tue, Jul 12, 2016 at 03:00:43PM -0600, Martin Sebor wrote:
> > This patch is accompanied by more than 2000 lines of new tests to get the
> > warning covered though I'm sure folks will come up with other test cases
> > that I hadn't considered (hi Martin S. ;).
> > 
> > This warning is enabled by default for C/C++.  I was more inclined to put 
> > this
> > into -Wall, but our common.opt machinery doesn't seem to allow that (ugh!).
> > The clang version I have installed doesn't have this warning so I couldn't
> > compare my implementation with others.
> > 
> > I plan to plunge into the C++ [[fallthrough]] thingie after this core part 
> > is
> > dealt with.
> 
> I think this is a useful feature though like others I'm not
> entirely sure that a built-in is the right interface.  I think
> I would find a pragma or an attribute preferable.  At a minimum,
> it would obviate some questions raised by my testing (i.e.,
> whether the built-in be accepted when an attribute would
> otherwise not be syntactically allowed).
> 
> I applied the core patch and ran a few experiments with it on
> the assumption that __builtin_fallthrough() should behave roughly
> correspondingly to [[fallthrough]].  I.e., be rejected where
> [[fallthrough]] is rejected (but where attributes are otherwise
> valid) and be accepted where the latter is accepted.  This may
> not be intended but the text added to the manual is too vague
> to tell.  I also compared the results to Clang's [[fallthrough]]
> to make sure I wasn't missing something (or too much).
> 
> I ran into a few of what seems like subtle bugs or limitations
> some of which I'm not sure are going to be solvable in the middle
> end (at least not after the control flow graph has been built)
> because by the time the middle end sees the code (certainly by
> the time it gets to expansion) some of it has been eliminated.
> An illustrative example of this class of problems might be this
> function:
> 
>   void f (void)
>   {
> if (0) __builtin_fallthrough ();   // never diagnosed
> 
> int i = 0;
> if (i) __builtin_fallthrough ();   // not diagnosed with -O
>   }
> 
> With the built-in replaced by [[fallthrough]] Clang diagnoses
> both of these.
> 
> This may be an okay limitation for __builtin_fallthrough since
> it's GCC-specific, but it won't do for the C++ attribute or for
> the C attribute if one is added with matching constraints.
> 
> The tests I tried are in the attached file.  Most of them are
> edge cases but some I think point out more serious problems
> (the checker getting confused/disabled by a prior switch
> statement).
> 
> Hopefully this will be useful.

Sure it is, thanks.  Since I've replaced __builtin_fallthrough ()
with an attribute, most of your observations should be fixed now.
But there was an ICE happening even with __attribute__((fallthrough)),
which I fixed now.  Your testcase is included (in a bit different
form) in the latest patch submission.

Marek

Re: Implement -Wimplicit-fallthrough: core

[Marek Polacek]

On Wed, Jul 27, 2016 at 02:15:54PM -0600, Jeff Law wrote:
> > Yeah, that is true.  I'm not sure if the warning can reasonably be expected 
> > to
> > handle all such cases and really see through loops like that, most likely 
> > not.
> > It's really just a heuristics.
> > Fortunately I didn't see any false positives due to that while 
> > bootstrapping.
> Can you add it as an xfail'd test?

Sure.  This is the (so far) latest version of the -Wimplicit-fallthrough core
patch, taking into account other remarks, too.  The new test is named
Wimplicit-fallthrough-18.c.

2016-07-28  Marek Polacek  
Jakub Jelinek  

PR c/7652
gcc/
* common.opt (Wimplicit-fallthrough): New option.
* doc/extend.texi: Document statement attributes and the fallthrough
attribute.
* doc/invoke.texi: Document -Wimplicit-fallthrough.
* gimple.h (gimple_call_internal_p): New function.
* gimplify.c (struct gimplify_ctx): Add in_switch_expr.
(struct label_entry): New struct.
(find_label_entry): New function.
(last_stmt_in_scope): New function.
(warn_implicit_fallthrough_r): New function.
(maybe_warn_implicit_fallthrough): New function.
(expand_FALLTHROUGH_r): New function.
(expand_FALLTHROUGH): New function.
(gimplify_switch_expr): Call maybe_warn_implicit_fallthrough and
expand_FALLTHROUGH for the innermost GIMPLE_SWITCH.
(gimplify_label_expr): New function.
(gimplify_case_label_expr): Set location.
(gimplify_expr): Call gimplify_label_expr.
* internal-fn.c (expand_FALLTHROUGH): New function.
* internal-fn.def (FALLTHROUGH): New internal function.
* system.h (gcc_fallthrough): Define.
* tree-core.h: Add FALLTHROUGH_LABEL_P comment.
* tree.h (FALLTHROUGH_LABEL_P): Define.
gcc/c-family/
* c-common.c (c_common_attribute_table): Add fallthrough attribute.
(handle_fallthrough_attribute): New function.
gcc/c/
* c-parser.c (struct c_token): Add flags field.
(c_lex_one_token): Pass it to c_lex_with_flags.
(c_parser_declaration_or_fndef): Turn __attribute__((fallthrough));
into IFN_FALLTHROUGH.
(c_parser_label): Set FALLTHROUGH_LABEL_P on labels.
(c_parser_statement_after_labels): Handle RID_ATTRIBUTE.
gcc/cp/
* constexpr.c (cxx_eval_internal_function): Handle IFN_FALLTHROUGH.
(potential_constant_expression_1): Likewise.
* parser.c (cp_parser_primary_expression): Handle RID_ATTRIBUTE.
(cp_parser_statement): Handle fallthrough attribute.
(cp_parser_label_for_labeled_statement): Set FALLTHROUGH_LABEL_P on
labels.
(cp_parser_std_attribute): Handle fallthrough attribute.
(cp_parser_check_std_attribute): Detect duplicated fallthrough
attribute.
gcc/testsuite/
* c-c++-common/Wimplicit-fallthrough-1.c: New test.
* c-c++-common/Wimplicit-fallthrough-10.c: New test.
* c-c++-common/Wimplicit-fallthrough-11.c: New test.
* c-c++-common/Wimplicit-fallthrough-12.c: New test.
* c-c++-common/Wimplicit-fallthrough-13.c: New test.
* c-c++-common/Wimplicit-fallthrough-14.c: New test.
* c-c++-common/Wimplicit-fallthrough-15.c: New test.
* c-c++-common/Wimplicit-fallthrough-16.c: New test.
* c-c++-common/Wimplicit-fallthrough-17.c: New test.
* c-c++-common/Wimplicit-fallthrough-18.c: New test.
* c-c++-common/Wimplicit-fallthrough-2.c: New test.
* c-c++-common/Wimplicit-fallthrough-3.c: New test.
* c-c++-common/Wimplicit-fallthrough-4.c: New test.
* c-c++-common/Wimplicit-fallthrough-5.c: New test.
* c-c++-common/Wimplicit-fallthrough-6.c: New test.
* c-c++-common/Wimplicit-fallthrough-7.c: New test.
* c-c++-common/Wimplicit-fallthrough-8.c: New test.
* c-c++-common/Wimplicit-fallthrough-9.c: New test.
* c-c++-common/attr-fallthrough-1.c: New test.
* c-c++-common/attr-fallthrough-2.c: New test.
* g++.dg/cpp0x/fallthrough1.C: New test.
* g++.dg/cpp0x/fallthrough2.C: New test.
* g++.dg/cpp1z/fallthrough1.C: New test.
libcpp/
* include/cpplib.h (PREV_FALLTHROUGH): Define.
* internal.h (CPP_FALLTHRU): Define.
* lex.c (fallthrough_comment_p): New function.
(_cpp_lex_direct): Set PREV_FALLTHROUGH on tokens succeeding a falls
through comment.

diff --git gcc/gcc/c-family/c-common.c gcc/gcc/c-family/c-common.c
index 16e3965..4510832 100644
--- gcc/gcc/c-family/c-common.c
+++ gcc/gcc/c-family/c-common.c
@@ -394,6 +394,7 @@ static tree handle_designated_init_attribute (tree *, tree, 
tree, int, bool *);
 static tree handle_bnd_variable_size_attribute (tree *, tree, tree, int, bool 
*);
 static tree handle_bnd_legacy (tree *, tree, tree, int, bool *);
 static tree handle_bnd_instrument (tree *, tree, tree, int, bool *);
+static 

Re: Implement -Wimplicit-fallthrough (take 2): fix missing breaks

[Marek Polacek]

On Wed, Jul 27, 2016 at 02:17:35PM -0600, Jeff Law wrote:
> On 07/27/2016 10:52 AM, Marek Polacek wrote:
> > This is what the new warning pointed out.  I think all these are bugs.
> > 
> > This patch has been tested on powerpc64le-unknown-linux-gnu, 
> > aarch64-linux-gnu,
> > and x86_64-redhat-linux.
> > 
> > 2016-07-27  Marek Polacek  
> > 
> > PR c/7652
> > gcc/
> > * config/i386/i386.c (ix86_expand_args_builtin): Add break.
> > (ix86_expand_round_builtin): Likewise.
> > * config/rs6000/rs6000.c (altivec_expand_ld_builtin): Add break.
> > (altivec_expand_st_builtin): Likewise.
> > * gengtype.c (dbgprint_count_type_at): Add break.
> > gcc/java/
> > * jcf-dump.c (print_constant): Add break.
> > libgo/
> > * runtime/heapdump.c (dumpefacetypes): Add break.
> Note that I think libgo's runtime is shared with golang and that Ian imports
> the runtime from that project.

Yea, I think so; I asked Ian whether he wants to help out with that.

Marek

Re: Implement -Wimplicit-fallthrough (take 2): fix missing breaks

[Marek Polacek]

On Wed, Jul 27, 2016 at 10:05:25AM -0700, Mike Stump wrote:
> On Jul 27, 2016, at 9:52 AM, Marek Polacek  wrote:
> > 
> > This is what the new warning pointed out.  I think all these are bugs.
> > 
> > --- gcc/libgo/runtime/heapdump.c
> > +++ gcc/libgo/runtime/heapdump.c
> > @@ -766,6 +766,7 @@ dumpefacetypes(void *obj __attribute__ ((unused)), 
> > uintptr size, const Type *typ
> > for(i = 0; i <= size - type->__size; i += type->__size)
> > //playgcprog(i, (uintptr*)type->gc + 1, 
> > dumpeface_callback, obj);
> > break;
> > +   break;
> > case TypeInfo_Chan:
> > if(type->__size == 0) // channels may have zero-sized objects 
> > in them
> > break;
> 
> I disagree that's the best fix.  Better would be to uncomment out the 
> playgcprog calls, and #if 0 the entire contents of the function.

You're right -- I only looked at the particular switch case, not the entire
function.  I did as you suggested.  Ian, do you want to take care of this?

Segher, is the rs6000.c part ok?

How about the rest?

Thanks.

2016-07-28  Marek Polacek  

PR c/7652
gcc/
* config/i386/i386.c (ix86_expand_args_builtin): Add break.
(ix86_expand_round_builtin): Likewise.
* config/rs6000/rs6000.c (altivec_expand_ld_builtin): Likewise.
(altivec_expand_st_builtin): Likewise.
* gengtype.c (dbgprint_count_type_at): Likewise.
libgo/
* runtime/heapdump.c (dumpefacetypes): Comment out content.  Add unused
attribute.

diff --git gcc/gcc/config/i386/i386.c gcc/gcc/config/i386/i386.c
index 246c6b5..7c8bb17 100644
--- gcc/gcc/config/i386/i386.c
+++ gcc/gcc/config/i386/i386.c
@@ -40172,6 +40172,7 @@ ix86_expand_args_builtin (const struct 
builtin_description *d,
 case 5:
   pat = GEN_FCN (icode) (real_target, args[0].op, args[1].op,
 args[2].op, args[3].op, args[4].op);
+  break;
 case 6:
   pat = GEN_FCN (icode) (real_target, args[0].op, args[1].op,
 args[2].op, args[3].op, args[4].op,
@@ -40546,6 +40547,7 @@ ix86_expand_round_builtin (const struct 
builtin_description *d,
 case 5:
   pat = GEN_FCN (icode) (target, args[0].op, args[1].op,
 args[2].op, args[3].op, args[4].op);
+  break;
 case 6:
   pat = GEN_FCN (icode) (target, args[0].op, args[1].op,
 args[2].op, args[3].op, args[4].op,
diff --git gcc/gcc/config/rs6000/rs6000.c gcc/gcc/config/rs6000/rs6000.c
index e5d8ad0..27442e1 100644
--- gcc/gcc/config/rs6000/rs6000.c
+++ gcc/gcc/config/rs6000/rs6000.c
@@ -14421,6 +14421,7 @@ altivec_expand_ld_builtin (tree exp, rtx target, bool 
*expandedp)
   break;
 case ALTIVEC_BUILTIN_LD_INTERNAL_2di:
   icode = CODE_FOR_vector_altivec_load_v2di;
+  break;
 case ALTIVEC_BUILTIN_LD_INTERNAL_1ti:
   icode = CODE_FOR_vector_altivec_load_v1ti;
   break;
@@ -14482,6 +14483,7 @@ altivec_expand_st_builtin (tree exp, rtx target 
ATTRIBUTE_UNUSED,
   break;
 case ALTIVEC_BUILTIN_ST_INTERNAL_2di:
   icode = CODE_FOR_vector_altivec_store_v2di;
+  break;
 case ALTIVEC_BUILTIN_ST_INTERNAL_1ti:
   icode = CODE_FOR_vector_altivec_store_v1ti;
   break;
diff --git gcc/gcc/gengtype.c gcc/gcc/gengtype.c
index 5479b8f..0518355 100644
--- gcc/gcc/gengtype.c
+++ gcc/gcc/gengtype.c
@@ -175,6 +175,7 @@ dbgprint_count_type_at (const char *fil, int lin, const 
char *msg, type_p t)
{
case TYPE_UNDEFINED:
  nb_undefined++;
+ break;
case TYPE_SCALAR:
  nb_scalar++;
  break;
diff --git gcc/libgo/runtime/heapdump.c gcc/libgo/runtime/heapdump.c
index d0cfb01..1e7678a 100644
--- gcc/libgo/runtime/heapdump.c
+++ gcc/libgo/runtime/heapdump.c
@@ -754,23 +754,28 @@ dumpeface_callback(void *p, uintptr kind, uintptr offset)
 // Dump all the types that appear in the type field of
 // any Eface contained in obj.
 static void
-dumpefacetypes(void *obj __attribute__ ((unused)), uintptr size, const Type 
*type, uintptr kind)
+dumpefacetypes(void *obj __attribute__ ((unused)),
+  uintptr size __attribute__ ((unused)),
+  const Type *type __attribute__ ((unused)),
+  uintptr kind __attribute__ ((unused)))
 {
+#if 0
uintptr i;
 
switch(kind) {
case TypeInfo_SingleObject:
-   //playgcprog(0, (uintptr*)type->gc + 1, dumpeface_callback, 
obj);
+   playgcprog(0, (uintptr*)type->gc + 1, dumpeface_callback, obj);
break;
case TypeInfo_Array:
for(i = 0; i <= size - type->__size; i += type->__size)
-   //playgcprog(i, (uintptr*)type->gc + 1, 
dumpeface_callback, obj);
+   playgcprog(i, (uintptr*)type->gc + 1, 
dumpeface_callback, obj);
break;
case TypeInfo_Chan:
if(type->__size == 0) // channels may h

Re: [C++ RFC/Patch] PR c++/71665

[Paolo Carlini]

Hi,

On 28/07/2016 16:28, Jason Merrill wrote:

On Thu, Jul 28, 2016 at 7:48 AM, Paolo Carlini  wrote:

Ah sorry, I missed the *type* bit. The below passes testing on x86_64-linux.
I don't think we need to check the type again after cxx_constant_value?!?

No, we don't.  The patch is OK.


While finally spending a decent amount of time on this issue I noticed that
current clang appears to enforce integral or *unscoped* enumeration type and
tweaking our code in the obvious way doesn't cause regressions, we of course
reject earlier (ie, not as "could not convert ‘(E)1’ from ‘E’ to ‘unsigned
int’") in build_enumerator snippets like:

enum class E { e = 1 };

class A
{
   enum { a = E::e };
};

Sure, that change could improve diagnostic quality a bit.
Thanks Jason. Then I'm regression testing again the below and I mean to 
commit it later today.


Thanks again,
Paolo.

/
/cp
2016-07-28  Paolo Carlini  

PR c++/71665
* decl.c (build_enumerator): Check the type of the enumerator before
calling cxx_constant_value.

/testsuite
2016-07-28  Paolo Carlini  

PR c++/71665
* g++.dg/cpp0x/pr71665-1.C: New.
* g++.dg/cpp0x/pr71665-2.C: Likewise.
* g++.dg/cpp0x/enum29.C: Adjust dg-error string.
* g++.dg/ext/label10.C: Likewise.
* g++.dg/parse/constant5.C: Likewise.
Index: cp/decl.c
===
--- cp/decl.c   (revision 238822)
+++ cp/decl.c   (working copy)
@@ -13587,15 +13587,24 @@ build_enumerator (tree name, tree value, tree enum
 
  if (value != NULL_TREE)
{
- value = cxx_constant_value (value);
-
- if (TREE_CODE (value) != INTEGER_CST
- || ! INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (value)))
+ if (! INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P
+ (TREE_TYPE (value)))
{
- error ("enumerator value for %qD is not an integer constant",
-name);
+ error ("enumerator for %qD must have integral or "
+"unscoped enumeration type", name);
  value = NULL_TREE;
}
+ else
+   {
+ value = cxx_constant_value (value);
+
+ if (TREE_CODE (value) != INTEGER_CST)
+   {
+ error ("enumerator value for %qD is not an integer "
+"constant", name);
+ value = NULL_TREE;
+   }
+   }
}
}
 
Index: testsuite/g++.dg/cpp0x/enum29.C
===
--- testsuite/g++.dg/cpp0x/enum29.C (revision 238822)
+++ testsuite/g++.dg/cpp0x/enum29.C (working copy)
@@ -38,7 +38,7 @@ enum E0 { e0 = X0() };
 enum E1 { e1 = X1() };
 enum E2 { e2 = X2() };
 enum E3 { e3 = X3() };
-enum E4 { e4 = X4() };  // { dg-error "integer constant" }
+enum E4 { e4 = X4() };  // { dg-error "integral" }
 enum E5 { e5 = X5() };  // { dg-error "ambiguous" }
 
 enum F0 : int { f0 = X0() };
Index: testsuite/g++.dg/cpp0x/pr71665-1.C
===
--- testsuite/g++.dg/cpp0x/pr71665-1.C  (revision 0)
+++ testsuite/g++.dg/cpp0x/pr71665-1.C  (working copy)
@@ -0,0 +1,8 @@
+// PR c++/71665
+// { dg-do compile { target c++11 } }
+
+class A 
+{
+  int f ();
+  enum { a = f }; // { dg-error "enumerator" }
+};
Index: testsuite/g++.dg/cpp0x/pr71665-2.C
===
--- testsuite/g++.dg/cpp0x/pr71665-2.C  (revision 0)
+++ testsuite/g++.dg/cpp0x/pr71665-2.C  (working copy)
@@ -0,0 +1,8 @@
+// PR c++/71665
+// { dg-do compile { target c++11 } }
+
+class A 
+{
+  enum class E { e = 1 };
+  enum { a = E::e };  // { dg-error "integral or unscoped enumeration" }
+};
Index: testsuite/g++.dg/ext/label10.C
===
--- testsuite/g++.dg/ext/label10.C  (revision 238822)
+++ testsuite/g++.dg/ext/label10.C  (working copy)
@@ -4,7 +4,7 @@
 
 template struct A
 {
-  enum { M = && N };   // { dg-error "referenced outside|cannot appear in|not 
an integer constant" }
+  enum { M = && N };   // { dg-error "referenced outside|cannot appear 
in|integral" }
 };
 
 A<0> a;
@@ -12,6 +12,6 @@ A<0> a;
 void foo ()
 {
   __label__ P;
-  enum { O = && P };   // { dg-error "cannot appear in|not an integer 
constant" }
+  enum { O = && P };   // { dg-error "cannot appear in|integral" }
   P:;
 }
Index: testsuite/g++.dg/parse/constant5.C
===
--- testsuite/g++.dg/parse/constant5.C  (revision 238822)
+++ testsuite/g++.dg/parse/constant5.C  (working copy)
@@ -1,7 +1,7 @@
 // { dg-options "-std=c++98 -pedantic-errors" }
 
 enum E { 
-  a = 24.2, // { dg-error "constant" }
+  a = 24.2, // { dg-error "inte

Re: Implement -Wimplicit-fallthrough (take 2): fix missing breaks

[Marek Polacek]

On Wed, Jul 27, 2016 at 11:43:22AM -0600, Tom Tromey wrote:
> > "Marek" == Marek Polacek  writes:
> 
> Marek> gcc/java/
> Marek>* jcf-dump.c (print_constant): Add break.
> 
> This bit is ok.

Thanks Tom.  I think I'll just commit this hunk separately to not post
already approved bits again.

Marek

C PATCH for c/71573 (ICE with invalid redeclaration)

[Marek Polacek]

When we're trying to implicitly declare a function, we first search the scope
looking for whether the function identifier is already bound to a declaration.
But as the following test shows, we might find something else other than a
FUNCTION_DECL like we're expecting, which would mean that an ICE ensues.  So
return early not only for error_mark_nodes, but also for anything that isn't a
FUNCTION_DECL.

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

2016-07-28  Marek Polacek  

PR c/71573
* c-decl.c (implicitly_declare): Return decl early not only for
error_mark_nodes, but for anything that is not a FUNCTION_DECL.

* gcc.dg/noncompile/pr71573.c: New test.

diff --git gcc/c/c-decl.c gcc/c/c-decl.c
index 41aabeb..24d3a45 100644
--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -3327,7 +3327,7 @@ implicitly_declare (location_t loc, tree functionid)
 
   if (decl)
 {
-  if (decl == error_mark_node)
+  if (TREE_CODE (decl) != FUNCTION_DECL)
return decl;
 
   /* FIXME: Objective-C has weird not-really-builtin functions
diff --git gcc/testsuite/gcc.dg/noncompile/pr71573.c 
gcc/testsuite/gcc.dg/noncompile/pr71573.c
index e69de29..8ace94a 100644
--- gcc/testsuite/gcc.dg/noncompile/pr71573.c
+++ gcc/testsuite/gcc.dg/noncompile/pr71573.c
@@ -0,0 +1,14 @@
+/* PR c/71573 */
+/* { dg-do compile } */
+
+void
+f1 (void)
+{
+  extern int t;
+}
+
+void
+f2 (void)
+{
+  t (0); /* { dg-error "called object .t. is not a function or function 
pointer" } */
+}

Marek

Re: [RFC] [2/2] divmod transform: override expand_divmod_libfunc for ARM and add test-cases

[Richard Earnshaw]

On 28/07/16 14:36, Prathamesh Kulkarni wrote:
> Um I had configured with --with-tune=cortex-a9. Is that incorrect for
> armv8l-unknown-linux-gnueabihf ?

Why on earth would you want to generate code for ARMv8 and then tune for
best performance on a core that can only run ARMv7?

R.

[Patch, fortran] PR71883] [5/6/7 Regression] ICE in identical_array_ref, at fortran/dependency.c:104

[Paul Richard Thomas]

Dear All,

Given the origins of the patch, it has been committed as 'obvious' to
trunk. It both bootstraps and regtests OK.

I will apply to the 5- and 6-branches.

Cheers

Paul


> --- Comment #11 from Paul Thomas  ---
> Author: pault
> Date: Thu Jul 28 14:47:02 2016
> New Revision: 238822
>
> URL: https://gcc.gnu.org/viewcvs?rev=238822&root=gcc&view=rev
> Log:
> 2016-07-28  Steven G. Kargl  
> Thomas Koenig  
>
> PR fortran/71883
> * frontend-passes.c (gfc_run_passes): Bail out if there are any
> errors.
> * error.c (gfc_internal_error): If there are any errors in the
> buffer, exit with EXIT_FAILURE.
>
> 2016-07-28  Paul Thomas  
>
> PR fortran/71883
> * gfortran.dg/pr71883.f90 : New test.
>
>
> Added:
> trunk/gcc/testsuite/gfortran.dg/pr71883.f90
> Modified:
> trunk/gcc/fortran/ChangeLog
> trunk/gcc/fortran/error.c
> trunk/gcc/fortran/frontend-passes.c
> trunk/gcc/testsuite/ChangeLog

Re: [RFC] [2/2] divmod transform: override expand_divmod_libfunc for ARM and add test-cases

[Ramana Radhakrishnan]

> appear UNSUPPORTED.
> That's because this config appears to define
> __ARM_ARCH_EXT_IDIV__ however idiv appears not to be present.
> 
> For instance __aeabi_div is called to perform
> division for the following test-case:
> int f(int x, int y)
> {
>   int r = x / y;
>   return r;
> }
> 
> Compiling with -O2:
> f:
> @ args = 0, pretend = 0, frame = 0
> @ frame_needed = 0, uses_anonymous_args = 0
> push{r4, lr}
> bl  __aeabi_idiv
> pop {r4, pc}
> 
> I assumed if __ARM_ARCH_EXT_IDIV was defined, then
> there should have been idiv instead of call to __aeabi_div
> or am I missing something ?
> 
> Um I had configured with --with-tune=cortex-a9. Is that incorrect for
> armv8l-unknown-linux-gnueabihf ?

--with-tune shouldn't make a difference to code generation settings. The code 
generation you are showing is certainly odd for this testcase  - and not 
something I can reproduce on pristine trunk - so sounds like something's broken 
by your patch . You should be seeing an sdiv in this case in the output - Look 
at the .arch directive at the top of your file - maybe that gives you a clue in 
terms of making sure that you had configured the toolchain correctly.


regards
Ramana

> 
> xgcc -v:
> Using built-in specs.
> COLLECT_GCC=armhf-bootstrap-build/gcc/xgcc
> Target: armv8l-unknown-linux-gnueabihf
> Configured with: ../gcc/configure --enable-languages=c,c++,fortran
> --with-arch=armv8-a --with-fpu=neon-fp-armv8 --with-float=hard
> --with-mode=thumb --enable-multiarch --with-tune=cortex-a9
> --disable-multilib
> Thread model: posix
> gcc version 7.0.0 20160727 (experimental) (GCC)
> 
> Thanks,
> Prathamesh
>>
>> Thanks,
>> Ramana

Re: [C++ RFC/Patch] PR c++/71665

[Jason Merrill]

On Thu, Jul 28, 2016 at 7:48 AM, Paolo Carlini  wrote:
> Ah sorry, I missed the *type* bit. The below passes testing on x86_64-linux.
> I don't think we need to check the type again after cxx_constant_value?!?

No, we don't.  The patch is OK.

> While finally spending a decent amount of time on this issue I noticed that
> current clang appears to enforce integral or *unscoped* enumeration type and
> tweaking our code in the obvious way doesn't cause regressions, we of course
> reject earlier (ie, not as "could not convert ‘(E)1’ from ‘E’ to ‘unsigned
> int’") in build_enumerator snippets like:
>
> enum class E { e = 1 };
>
> class A
> {
>   enum { a = E::e };
> };

Sure, that change could improve diagnostic quality a bit.

Jason

Re: [PATCH PR71734] Add missed check that reference defined inside loop.

[Richard Biener]

On Thu, Jul 28, 2016 at 3:49 PM, Yuri Rumyantsev  wrote:
> Richard,
>
> I prepare a patch which is based on yours. New test is also included.
> Bootstrapping and regression testing did not show any new failures.
> Is it OK for trunk?

Ok.

Thanks,
Richard.

> Thanks.
> ChangeLog:
> 2016-07-28  Yuri Rumyantsev  
>
> PR tree-optimization/71734
> * tree-ssa-loop-im.c (ref_indep_loop_p_1): Pass value of safelen
> attribute instead of REF_LOOP and use it.
> (ref_indep_loop_p_2): Use SAFELEN argument instead of REF_LOOP and
> set it for Loops having non-zero safelen attribute.
> (ref_indep_loop_p): Pass zero as initial value for safelen.
> gcc/testsuite/ChangeLog:
> * g++.dg/vect/pr70729-nest.cc: New test.
>
> 2016-07-27 16:25 GMT+03:00 Richard Biener :
>> On Tue, Jul 26, 2016 at 5:49 PM, Yuri Rumyantsev  wrote:
>>> Hi Richard,
>>>
>>> It turned out that the patch proposed by you does not work properly
>>> for nested loop. If we slightly change pr70729.cc to
>>> (non-essential part is omitted
>>> void inline Ss::foo (float w)
>>> {
>>> #pragma omp simd
>>>   for (int i=0; i>> {
>>>   float w1 = C2[S_n + i] * w;
>>>   v1.v_i[i] += (int)w1;
>>>   C1[S_n + i] += w1;
>>> }
>>> }
>>> void Ss::boo (int n)
>>> {
>>>   for (int i = 0; i>> foo(ww[i]);
>>> }
>>> loop in foo won't be vectorized since REF_LOOP is outer loop which is
>>> not marked with omp simd pragma:
>>>  t1.cc:73:25: note: not vectorized: not suitable for scatter store *_31 = 
>>> _33;
>>> t1.cc:73:25: note: bad data references.
>>>
>>> Note that the check I proposed before works fine.
>>
>> The attached works for me (current trunk doesn't work because of caching
>> we do - I suppose we should try again to avoid the quadraticness in other
>> ways when ref_indep_loop_p is called from outermost_indep_loop).
>>
>> Richard.
>>
>>> 2016-07-20 12:35 GMT+03:00 Yuri Rumyantsev :
 Richard,

 Jakub has already fixed it.
 Sorry for troubles.
 Yuri.

 2016-07-19 18:29 GMT+03:00 Renlin Li :
> Hi Yuri,
>
> I saw this test case runs on arm platforms, and maybe other platforms as
> well.
>
> testsuite/g++.dg/vect/pr70729.cc:7:10: fatal error: xmmintrin.h: No such
> file or directory
>
> Before the change here, it's gated by vect_simd_clones target selector,
> which limit it to i?86/x86_64 platform only.
>
> Regards,
> Renlin Li
>
>
>
>
> On 08/07/16 15:07, Yuri Rumyantsev wrote:
>>
>> Hi Richard,
>>
>> Thanks for your help - your patch looks much better.
>> Here is new patch in which additional argument was added to determine
>> source loop of reference.
>>
>> Bootstrap and regression testing did not show any new failures.
>>
>> Is it OK for trunk?
>> ChangeLog:
>> 2016-07-08  Yuri Rumyantsev  
>>
>> PR tree-optimization/71734
>> * tree-ssa-loop-im.c (ref_indep_loop_p_1): Add REF_LOOP argument which
>> contains REF, use it to check safelen, assume that safelen value
>> must be greater 1, fix style.
>> (ref_indep_loop_p_2): Add REF_LOOP argument.
>> (ref_indep_loop_p): Pass LOOP as additional argument to
>> ref_indep_loop_p_2.
>> gcc/testsuite/ChangeLog:
>>  * g++.dg/vect/pr70729.cc: Delete redundant dg options, fix 
>> style.
>>
>> 2016-07-08 11:18 GMT+03:00 Richard Biener :
>>>
>>> On Thu, Jul 7, 2016 at 5:38 PM, Yuri Rumyantsev 
>>> wrote:

 I checked simd3.f90 and found out that my additional check reject
 independence of references

 REF is independent in loop#3
 .istart0.19, .iend0.20
 which are defined in loop#1 which is outer for loop#3.
 Note that these references are defined by
 _103 = __builtin_GOMP_loop_dynamic_next (&.istart0.19, &.iend0.20);
 which is in loop#1.
 It is clear that both these references can not be independent for
 loop#3.
>>>
>>>
>>> Ok, so we end up calling ref_indep_loop for ref in LOOP also for inner
>>> loops
>>> of LOOP to catch memory references in those as well.  So the issue is
>>> really
>>> that we look at the wrong loop for safelen and we _do_ want to apply
>>> safelen
>>> to inner loops as well.
>>>
>>> So better track the loop we are ultimately asking the question for, like
>>> in the
>>> attached patch (fixes the testcase for me).
>>>
>>> Richard.
>>>
>>>
>>>
 2016-07-07 17:11 GMT+03:00 Richard Biener :
>
> On Thu, Jul 7, 2016 at 4:04 PM, Yuri Rumyantsev 
> wrote:
>>
>> I Added this check because of new failures in libgomp.fortran suite.
>> Here is copy of Jakub message:
>> --- Comment #29 from Jakub Jelinek  ---
>> The #c27 r237844 change looks bogus to me.
>> First of all, IMNSHO you can argue this way only if ref is a 
>> refer

Re: [PATCH PR71734] Add missed check that reference defined inside loop.

[Yuri Rumyantsev]

Richard,

I prepare a patch which is based on yours. New test is also included.
Bootstrapping and regression testing did not show any new failures.
Is it OK for trunk?

Thanks.
ChangeLog:
2016-07-28  Yuri Rumyantsev  

PR tree-optimization/71734
* tree-ssa-loop-im.c (ref_indep_loop_p_1): Pass value of safelen
attribute instead of REF_LOOP and use it.
(ref_indep_loop_p_2): Use SAFELEN argument instead of REF_LOOP and
set it for Loops having non-zero safelen attribute.
(ref_indep_loop_p): Pass zero as initial value for safelen.
gcc/testsuite/ChangeLog:
* g++.dg/vect/pr70729-nest.cc: New test.

2016-07-27 16:25 GMT+03:00 Richard Biener :
> On Tue, Jul 26, 2016 at 5:49 PM, Yuri Rumyantsev  wrote:
>> Hi Richard,
>>
>> It turned out that the patch proposed by you does not work properly
>> for nested loop. If we slightly change pr70729.cc to
>> (non-essential part is omitted
>> void inline Ss::foo (float w)
>> {
>> #pragma omp simd
>>   for (int i=0; i> {
>>   float w1 = C2[S_n + i] * w;
>>   v1.v_i[i] += (int)w1;
>>   C1[S_n + i] += w1;
>> }
>> }
>> void Ss::boo (int n)
>> {
>>   for (int i = 0; i> foo(ww[i]);
>> }
>> loop in foo won't be vectorized since REF_LOOP is outer loop which is
>> not marked with omp simd pragma:
>>  t1.cc:73:25: note: not vectorized: not suitable for scatter store *_31 = 
>> _33;
>> t1.cc:73:25: note: bad data references.
>>
>> Note that the check I proposed before works fine.
>
> The attached works for me (current trunk doesn't work because of caching
> we do - I suppose we should try again to avoid the quadraticness in other
> ways when ref_indep_loop_p is called from outermost_indep_loop).
>
> Richard.
>
>> 2016-07-20 12:35 GMT+03:00 Yuri Rumyantsev :
>>> Richard,
>>>
>>> Jakub has already fixed it.
>>> Sorry for troubles.
>>> Yuri.
>>>
>>> 2016-07-19 18:29 GMT+03:00 Renlin Li :
 Hi Yuri,

 I saw this test case runs on arm platforms, and maybe other platforms as
 well.

 testsuite/g++.dg/vect/pr70729.cc:7:10: fatal error: xmmintrin.h: No such
 file or directory

 Before the change here, it's gated by vect_simd_clones target selector,
 which limit it to i?86/x86_64 platform only.

 Regards,
 Renlin Li




 On 08/07/16 15:07, Yuri Rumyantsev wrote:
>
> Hi Richard,
>
> Thanks for your help - your patch looks much better.
> Here is new patch in which additional argument was added to determine
> source loop of reference.
>
> Bootstrap and regression testing did not show any new failures.
>
> Is it OK for trunk?
> ChangeLog:
> 2016-07-08  Yuri Rumyantsev  
>
> PR tree-optimization/71734
> * tree-ssa-loop-im.c (ref_indep_loop_p_1): Add REF_LOOP argument which
> contains REF, use it to check safelen, assume that safelen value
> must be greater 1, fix style.
> (ref_indep_loop_p_2): Add REF_LOOP argument.
> (ref_indep_loop_p): Pass LOOP as additional argument to
> ref_indep_loop_p_2.
> gcc/testsuite/ChangeLog:
>  * g++.dg/vect/pr70729.cc: Delete redundant dg options, fix style.
>
> 2016-07-08 11:18 GMT+03:00 Richard Biener :
>>
>> On Thu, Jul 7, 2016 at 5:38 PM, Yuri Rumyantsev 
>> wrote:
>>>
>>> I checked simd3.f90 and found out that my additional check reject
>>> independence of references
>>>
>>> REF is independent in loop#3
>>> .istart0.19, .iend0.20
>>> which are defined in loop#1 which is outer for loop#3.
>>> Note that these references are defined by
>>> _103 = __builtin_GOMP_loop_dynamic_next (&.istart0.19, &.iend0.20);
>>> which is in loop#1.
>>> It is clear that both these references can not be independent for
>>> loop#3.
>>
>>
>> Ok, so we end up calling ref_indep_loop for ref in LOOP also for inner
>> loops
>> of LOOP to catch memory references in those as well.  So the issue is
>> really
>> that we look at the wrong loop for safelen and we _do_ want to apply
>> safelen
>> to inner loops as well.
>>
>> So better track the loop we are ultimately asking the question for, like
>> in the
>> attached patch (fixes the testcase for me).
>>
>> Richard.
>>
>>
>>
>>> 2016-07-07 17:11 GMT+03:00 Richard Biener :

 On Thu, Jul 7, 2016 at 4:04 PM, Yuri Rumyantsev 
 wrote:
>
> I Added this check because of new failures in libgomp.fortran suite.
> Here is copy of Jakub message:
> --- Comment #29 from Jakub Jelinek  ---
> The #c27 r237844 change looks bogus to me.
> First of all, IMNSHO you can argue this way only if ref is a reference
> seen in
> loop LOOP,


 or inner loops of LOOP I guess.  I _think_ we never call
 ref_indep_loop_p_1 with
 a REF whose loop is not a sub-loop of LOOP or LOOP itself (as it would
 not make

Re: [PR70920] transform (intptr_t) x eq/ne CST to x eq/ne (typeof x) cst

[Richard Biener]

On Thu, 28 Jul 2016, Prathamesh Kulkarni wrote:

> On 28 July 2016 at 15:58, Andreas Schwab  wrote:
> > On Mo, Jul 25 2016, Prathamesh Kulkarni  
> > wrote:
> >
> >> diff --git a/gcc/testsuite/gcc.dg/pr70920-4.c 
> >> b/gcc/testsuite/gcc.dg/pr70920-4.c
> >> new file mode 100644
> >> index 000..dedb895
> >> --- /dev/null
> >> +++ b/gcc/testsuite/gcc.dg/pr70920-4.c
> >> @@ -0,0 +1,21 @@
> >> +/* { dg-do compile } */
> >> +/* { dg-options "-O2 -fdump-tree-ccp-details -Wno-int-to-pointer-cast" } 
> >> */
> >> +
> >> +#include 
> >> +
> >> +void f1();
> >> +void f2();
> >> +
> >> +void
> >> +foo (int a)
> >> +{
> >> +  void *cst = 0;
> >> +  if ((int *) a == cst)
> >> +{
> >> +  f1 ();
> >> +  if (a)
> >> + f2 ();
> >> +}
> >> +}
> >> +
> >> +/* { dg-final { scan-tree-dump "gimple_simplified to if \\(_\[0-9\]* == 
> >> 0\\)" "ccp1" } } */
> >
> > This fails on all ilp32 platforms.
> Oops, sorry for the breakage.
> With -m32, the pattern is applied during forwprop1 rather than ccp1.
> I wonder though why ccp1 fails to fold the pattern with -m32 ?
> Looking at the dumps:
> 
> without -m32:
> input to ccp1 pass:
>   :
>   cst_4 = 0B;
>   _1 = (long int) a_5(D);
>   _2 = (void *) _1;
>   if (cst_4 == _2)
> goto ;
>   else
> goto ;
> 
> cc1 pass dump shows:
> Substituting values and folding statements
> 
> Folding statement: _1 = (long int) a_5(D);
> Not folded
> Folding statement: _2 = (void *) _1;
> Not folded
> Folding statement: if (cst_4 == _2)
> which is likely CONSTANT
> Applying pattern match.pd:2537, gimple-match.c:6530
> gimple_simplified to if (_1 == 0)
> Folded into: if (_1 == 0)
> 
> with -m32:
> input to ccp1 pass:
>  :
>   cst_3 = 0B;
>   a.0_1 = (void *) a_4(D);
>   if (cst_3 == a.0_1)
> goto ;
>   else
> goto ;
> 
> ccp1 pass dump shows:
> Substituting values and folding statements
> 
> Folding statement: a.0_1 = (void *) a_4(D);
> Not folded
> Folding statement: if (cst_3 == a.0_1)
> which is likely CONSTANT
> Folded into: if (a.0_1 == 0B)
> 
> I am not able to understand why it doesn't fold it to
> if (a_4(D) == 0) ?
> forwprop1 folds a.0_1 == 0B to a_4(D) == 0.

It's because CCP folds with follow-single-use edges but the 
match-and-simplify code uses a single callback to valueize and
decide whether its valid to follow the SSA edge.  I did have some
old patches trying to fix that but never followed up on those.

> I suppose the test-case would need to scan ccp1 for non-ilp targets
> and forwprop1 for
> ilp targets. How do update the test-case to reflect this ?

It's simpler to verify that at some point (forwprop) we have the
expected IL rather than testing for the match debug prints.

Richard.

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

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

divmod transform: add test-cases

[Prathamesh Kulkarni]

Hi,
The following patch adds test-cases for divmod transform.
I separated the SImode tests into separate file from DImode tests
because certain arm configs (cortex-15) have hardware div insn for
SImode but not for DImode,
and for that config we want SImode tests to be disabled but not DImode tests.
The patch therefore has two target-effective checks: divmod and divmod_simode.
Is it OK for trunk ?

Thanks,
Prathamesh
diff --git a/gcc/testsuite/gcc.dg/divmod-1-simode.c 
b/gcc/testsuite/gcc.dg/divmod-1-simode.c
new file mode 100644
index 000..7405f66
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/divmod-1-simode.c
@@ -0,0 +1,22 @@
+/* { dg-require-effective-target divmod_simode } */
+/* { dg-options "-O2 -fdump-tree-widening_mul-details" } */
+/* div dominates mod.  */
+
+extern int cond;
+void foo(void);
+
+#define FOO(smalltype, bigtype, no)  \
+bigtype f_##no(smalltype x, bigtype y) \
+{   \
+  bigtype q = x / y; \
+  if (cond)  \
+foo ();  \
+  bigtype r = x % y; \
+  return q + r;  \
+}
+
+FOO(int, int, 1)
+FOO(int, unsigned, 2)
+FOO(unsigned, unsigned, 5)
+
+/* { dg-final { scan-tree-dump-times "DIVMOD" 3 "widening_mul" } } */
diff --git a/gcc/testsuite/gcc.dg/divmod-1.c b/gcc/testsuite/gcc.dg/divmod-1.c
new file mode 100644
index 000..40aec74
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/divmod-1.c
@@ -0,0 +1,26 @@
+/* { dg-require-effective-target divmod } */
+/* { dg-options "-O2 -fdump-tree-widening_mul-details" } */
+/* div dominates mod.  */
+
+extern int cond;
+void foo(void);
+
+#define FOO(smalltype, bigtype, no) \
+bigtype f_##no(smalltype x, bigtype y)   \
+{   \
+  bigtype q = x / y; \
+  if (cond)  \
+foo ();  \
+  bigtype r = x % y; \
+  return q + r;  \
+}
+
+FOO(int, long long, 3)
+FOO(int, unsigned long long, 4)
+FOO(unsigned, long long, 6)
+FOO(unsigned, unsigned long long, 7)
+FOO(long long, long long, 8)
+FOO(long long, unsigned long long, 9)
+FOO(unsigned long long, unsigned long long, 10)
+
+/* { dg-final { scan-tree-dump-times "DIVMOD" 7 "widening_mul" } } */
diff --git a/gcc/testsuite/gcc.dg/divmod-2-simode.c 
b/gcc/testsuite/gcc.dg/divmod-2-simode.c
new file mode 100644
index 000..7c8313b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/divmod-2-simode.c
@@ -0,0 +1,22 @@
+/* { dg-require-effective-target divmod_simode } */
+/* { dg-options "-O2 -fdump-tree-widening_mul-details" } */
+/* mod dominates div.  */
+
+extern int cond;
+void foo(void);
+
+#define FOO(smalltype, bigtype, no)  \
+bigtype f_##no(smalltype x, bigtype y) \
+{   \
+  bigtype r = x % y; \
+  if (cond)  \
+foo ();  \
+  bigtype q = x / y; \
+  return q + r;  \
+}
+
+FOO(int, int, 1)
+FOO(int, unsigned, 2)
+FOO(unsigned, unsigned, 5)
+
+/* { dg-final { scan-tree-dump-times "DIVMOD" 3 "widening_mul" } } */
diff --git a/gcc/testsuite/gcc.dg/divmod-2.c b/gcc/testsuite/gcc.dg/divmod-2.c
new file mode 100644
index 000..6a2216c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/divmod-2.c
@@ -0,0 +1,26 @@
+/* { dg-require-effective-target divmod } */
+/* { dg-options "-O2 -fdump-tree-widening_mul-details" } */
+/* mod dominates div.  */
+
+extern int cond;
+void foo(void);
+
+#define FOO(smalltype, bigtype, no) \
+bigtype f_##no(smalltype x, bigtype y)   \
+{   \
+  bigtype r = x % y; \
+  if (cond)  \
+foo ();  \
+  bigtype q = x / y; \
+  return q + r;  \
+}
+
+FOO(int, long long, 3)
+FOO(int, unsigned long long, 4)
+FOO(unsigned, long long, 6)
+FOO(unsigned, unsigned long long, 7)
+FOO(long long, long long, 8)
+FOO(long long, unsigned long long, 9)
+FOO(unsigned long long, unsigned long long, 10)
+
+/* { dg-final { scan-tree-dump-times "DIVMOD" 7 "widening_mul" } } */
diff --git a/gcc/testsuite/gcc.dg/divmod-3-simode.c 
b/gcc/testsuite/gcc.dg/divmod-3-simode.c
new file mode 100644
index 000..6f0f63d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/divmod-3-simode.c
@@ -0,0 +1,20 @@
+/* { dg-require-effective-target divmod_simode } */
+/* { dg-options "-O2 -fdump-tree-widening_mul-details" } */
+/* div comes before mod in same bb.  */
+
+extern int cond;
+void foo(void);
+
+#define FOO(smalltype, bigtype, no) \
+bigtype f_##no(smalltype x, bigtype y)  \
+{   \
+  bigtype q = x / y; \
+  bigtype r = x % y; \
+  return q + r;  \
+}
+
+FOO(int, int, 1)
+FOO(int, unsigned, 2)
+FOO(unsigned, unsigne

Re: [RFC] [2/2] divmod transform: override expand_divmod_libfunc for ARM and add test-cases

[Prathamesh Kulkarni]

On 27 July 2016 at 18:56, Ramana Radhakrishnan
 wrote:
> On Wed, May 25, 2016 at 1:49 PM, Prathamesh Kulkarni
>  wrote:
>> On 23 May 2016 at 14:28, Prathamesh Kulkarni
>>  wrote:
>>> Hi,
>>> This patch overrides expand_divmod_libfunc for ARM port and adds test-cases.
>>> I separated the SImode tests into separate file from DImode tests
>>> because certain arm configs (cortex-15) have hardware div insn for
>>> SImode but not for DImode,
>>> and for that config we want SImode tests to be disabled but not DImode 
>>> tests.
>>> The patch therefore has two target-effective checks: divmod and 
>>> divmod_simode.
>>> Cross-tested on arm*-*-*.
>>> Bootstrap+test on arm-linux-gnueabihf in progress.
>>> Does this patch look OK ?
>> Hi,
>> This version adds couple of more test-cases and fixes typo in
>> divmod-3-simode.c, divmod-4-simode.c
>>
>> Thanks,
>> Prathamesh
>>>
>>> Thanks,
>>> Prathamesh
>
> From the patch (snipped out unnecessary parts)
>
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 201aeb4..3bbf11b 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
>
> 
>
> +  gcc_assert (quotient);
> +  gcc_assert (remainder);
> +
>
> There's a trailing white space here.
>
> +  *quot_p = quotient;
> +  *rem_p = remainder;
> +}
>
>
>
> +# For ARM configs defining __ARM_ARCH_EXT_IDIV__, disable
> divmod_simode test-cases
>
> Very unhelpful comment ...
>
> For versions of the architecture where there exists a DIV instruction,
> the divmod helper function is not used, disable the software divmod
> optimization.
>
>
> +
> +proc check_effective_target_arm_divmod_simode { } {
> +return [check_no_compiler_messages arm_divmod assembly {
> +   #ifdef __ARM_ARCH_EXT_IDIV__
> +   #error has div insn
> +   #endif
> +   int i;
> +}]
> +}
> +
> +proc check_effective_target_divmod { } {
>
> Missing comment above.
>
> +#TODO: Add checks for all targets that have either hardware divmod insn
> +# or define libfunc for divmod.
> +if { [istarget arm*-*-*]
> +|| [istarget x86_64-*-*] } {
> +   return 1
> +}
> +return 0
> +}
>
>
>
>
>
> The new helper functions need documentation in doc/sourcebuild.texi
>
> Please repost with the doc changes, otherwise this is OK from my side.
Hi Ramana,
Thanks for the review, I have updated the patch
with your suggestions.
Cross-tested on arm*-*-*.

I came across following issue while bootstrapping
on armv8l-unknown-linux-gnueabihf:
All the divmod-*-simode.c tests which have
/* { dg-require-effective-target divmod_simode } */
appear UNSUPPORTED.
That's because this config appears to define
__ARM_ARCH_EXT_IDIV__ however idiv appears not to be present.

For instance __aeabi_div is called to perform
division for the following test-case:
int f(int x, int y)
{
  int r = x / y;
  return r;
}

Compiling with -O2:
f:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
push{r4, lr}
bl  __aeabi_idiv
pop {r4, pc}

I assumed if __ARM_ARCH_EXT_IDIV was defined, then
there should have been idiv instead of call to __aeabi_div
or am I missing something ?

Um I had configured with --with-tune=cortex-a9. Is that incorrect for
armv8l-unknown-linux-gnueabihf ?

xgcc -v:
Using built-in specs.
COLLECT_GCC=armhf-bootstrap-build/gcc/xgcc
Target: armv8l-unknown-linux-gnueabihf
Configured with: ../gcc/configure --enable-languages=c,c++,fortran
--with-arch=armv8-a --with-fpu=neon-fp-armv8 --with-float=hard
--with-mode=thumb --enable-multiarch --with-tune=cortex-a9
--disable-multilib
Thread model: posix
gcc version 7.0.0 20160727 (experimental) (GCC)

Thanks,
Prathamesh
>
> Thanks,
> Ramana
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 195de48..f449e46 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -61,6 +61,7 @@
 #include "builtins.h"
 #include "tm-constrs.h"
 #include "rtl-iter.h"
+#include "optabs-libfuncs.h"

 /* This file should be included last.  */
 #include "target-def.h"
@@ -299,6 +300,7 @@ static unsigned HOST_WIDE_INT arm_asan_shadow_offset (void);
 static void arm_sched_fusion_priority (rtx_insn *, int, int *, int*);
 static bool arm_can_output_mi_thunk (const_tree, HOST_WIDE_INT, HOST_WIDE_INT,
 const_tree);
+static void arm_expand_divmod_libfunc (bool, machine_mode, rtx, rtx, rtx *, 
rtx *);


 /* Table of machine attributes.  */
@@ -729,6 +731,9 @@ static const struct attribute_spec arm_attribute_table[] =
 #undef TARGET_SCHED_FUSION_PRIORITY
 #define TARGET_SCHED_FUSION_PRIORITY arm_sched_fusion_priority

+#undef TARGET_EXPAND_DIVMOD_LIBFUNC
+#define TARGET_EXPAND_DIVMOD_LIBFUNC arm_expand_divmod_libfunc
+
 struct gcc_target targetm = TARGET_INITIALIZER;

 /* Obstack for minipool constant handling.  */
@@ -30486,6 +30491,38 @@ arm_sched_fusion_priority (rtx_insn *insn, int max_pri,
   return;
 }

+/* Expand call to __aeabi_[mode]divmod (op0, op1).  */
+
+static void
+arm_expand_divmod_libfunc (bool unsignedp, machine_mode 

Re: RFC [1/2] divmod transform

[Prathamesh Kulkarni]

On 8 June 2016 at 19:53, Richard Biener  wrote:
> On Fri, 3 Jun 2016, Jim Wilson wrote:
>
>> On Mon, May 30, 2016 at 12:45 AM, Richard Biener  wrote:
>> > Joseph - do you know sth about why there's not a full set of divmod
>> > libfuncs in libgcc?
>>
>> Because udivmoddi4 isn't a libfunc, it is a helper function for the
>> div and mov libfuncs.  Since we can compute the signed div and mod
>> results from udivmoddi4, there was no need to also add a signed
>> version of it.  It was given a libfunc style name so that we had the
>> option of making it a libfunc in the future, but that never happened.
>> There was no support for calling any divmod libfunc until it was added
>> as a special case to call an ARM library (not libgcc) function.  This
>> happened here
>>
>> 2004-08-09  Mark Mitchell  
>>
>> * config.gcc (arm*-*-eabi*): New target.
>> * defaults.h (TARGET_LIBGCC_FUNCS): New macro.
>> (TARGET_LIB_INT_CMP_BIASED): Likewise.
>> * expmed.c (expand_divmod): Try a two-valued divmod function as a
>> last resort.
>> ...
>> * config/arm/arm.c (arm_init_libfuncs): New function.
>> (arm_compute_initial_eliminatino_offset): Return HOST_WIDE_INT.
>> (TARGET_INIT_LIBFUNCS): Define it.
>> ...
>>
>> Later, two ports added their own divmod libfuncs, but I don't see any
>> evidence that they were ever used, since there is no support for
>> calling divmod other than the expand_divmod last resort code that only
>> triggers for ARM.
>>
>> It is only now that Prathamesh is adding gimple support for divmod
>> operations that we need to worry about getting this right, without
>> breaking the existing ARM library support or the existing udivmoddi4
>> support.
>
> Ok, so as he is primarily targeting the special arm divmod libcall
> I suppose we can live with special-casing libcall handling to
> udivmoddi3.  It would be nice to not lie about divmod availablilty
> as libcall though... - it looks like the libcall is also guarded
> on TARGET_HAS_NO_HW_DIVIDE (unless it was available historically
> like on x86).
>
> So not sure where to go from here.
Hi,
I have attached patch, which is rebased on trunk.
Needed to update divmod-7.c, which now gets transformed to divmod
thanks to your code-hoisting patch -;)
We still have the issue of optab_libfunc() returning non-existent
libcalls. As in previous patch, I am checking
explicitly for "__udivmoddi4", with a FIXME note.
I hope that's okay for now ?

Bootstrapped and tested on x86_64-unknown-linux-gnu,
armv8l-unknown-linux-gnueabihf.
Bootstrap+test in progress on i686-linux-gnu.
Cross-tested on arm*-*-*.

Thanks,
Prathamesh
>
> Richard.
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 83bd9ab..e4815cf 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -7010,6 +7010,12 @@ This is firstly introduced on ARM/AArch64 targets, 
please refer to
 the hook implementation for how different fusion types are supported.
 @end deftypefn

+@deftypefn {Target Hook} void TARGET_EXPAND_DIVMOD_LIBFUNC (bool 
@var{unsignedp}, machine_mode @var{mode}, @var{rtx}, @var{rtx}, rtx 
*@var{quot}, rtx *@var{rem})
+Define this hook if the port does not have hardware div and divmod insn for
+the given mode but has divmod libfunc, which is incompatible
+with libgcc2.c:__udivmoddi4
+@end deftypefn
+
 @node Sections
 @section Dividing the Output into Sections (Texts, Data, @dots{})
 @c the above section title is WAY too long.  maybe cut the part between
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index a72c3d8..3efaf4d 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -4864,6 +4864,8 @@ them: try the first ones in this list first.

 @hook TARGET_SCHED_FUSION_PRIORITY

+@hook TARGET_EXPAND_DIVMOD_LIBFUNC
+
 @node Sections
 @section Dividing the Output into Sections (Texts, Data, @dots{})
 @c the above section title is WAY too long.  maybe cut the part between
diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
index 49f3495..18876ce 100644
--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -2326,6 +2326,48 @@ multi_vector_optab_supported_p (convert_optab optab, 
tree_pair types,
 #define direct_mask_store_optab_supported_p direct_optab_supported_p
 #define direct_store_lanes_optab_supported_p multi_vector_optab_supported_p

+/* Expand DIVMOD() using:
+ a) optab handler for udivmod/sdivmod if it is available.
+ b) If optab_handler doesn't exist, Generate call to
+optab_libfunc for udivmod/sdivmod.  */
+
+static void
+expand_DIVMOD (internal_fn, gcall *stmt)
+{
+  tree lhs = gimple_call_lhs (stmt);
+  tree arg0 = gimple_call_arg (stmt, 0);
+  tree arg1 = gimple_call_arg (stmt, 1);
+
+  gcc_assert (TREE_CODE (TREE_TYPE (lhs)) == COMPLEX_TYPE);
+  tree type = TREE_TYPE (TREE_TYPE (lhs));
+  machine_mode mode = TYPE_MODE (type);
+  bool unsignedp = TYPE_UNSIGNED (type);
+  optab tab = (unsignedp) ? udivmod_optab : sdivmod_optab;
+
+  rtx op0 = expand_normal (arg0);
+  rtx op1 = expand_normal (arg1);
+  rtx target = exp

C PATCH for c/71574 (ICE with alloc_align attribute)

[Marek Polacek]

Many attributes that accept integer constant as a parameter call
default_conversion for such constants to perform the usual arithmetic
conversions.  The call to default_conversion is always guarded so as
to prevent a NULL_TREE, an IDENTIFIER_NODE, or a FUNCTION_DECL from
getting into this function.  But the alloc_align attribute was missing
the FUNCTION_DECL check, so we were crashing when someone passed a
function decl as a parameter to it.

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

2016-07-28  Marek Polacek  

PR c/71574
* c-common.c (handle_alloc_align_attribute): Also check FUNCTION_DECL.

* c-c++-common/pr71574.c: New test.

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index 16e3965..efd9815 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -8370,7 +8370,8 @@ handle_alloc_align_attribute (tree *node, tree, tree 
args, int,
 {
   unsigned arg_count = type_num_arguments (*node);
   tree position = TREE_VALUE (args);
-  if (position && TREE_CODE (position) != IDENTIFIER_NODE)
+  if (position && TREE_CODE (position) != IDENTIFIER_NODE
+  && TREE_CODE (position) != FUNCTION_DECL)
 position = default_conversion (position);
 
   if (!tree_fits_uhwi_p (position)
diff --git gcc/testsuite/c-c++-common/pr71574.c 
gcc/testsuite/c-c++-common/pr71574.c
index e69de29..320ae38 100644
--- gcc/testsuite/c-c++-common/pr71574.c
+++ gcc/testsuite/c-c++-common/pr71574.c
@@ -0,0 +1,12 @@
+/* PR c/71574 */
+/* { dg-do compile } */
+
+int fn1 (void);
+int fn2 (void) __attribute__ ((alloc_align (fn1))); /* { dg-warning "parameter 
outside range" } */
+int fn3 (void) __attribute__ ((alloc_size (fn1))); /* { dg-warning "parameter 
outside range" } */
+int fn4 (void) __attribute__ ((assume_aligned (fn1))); /* { dg-warning "not 
integer constant" } */
+int fn5 (char *, char *) __attribute__((nonnull (fn1))); /* { dg-error 
"nonnull argument has invalid operand" } */
+int fn6 (const char *, ...) __attribute__ ((sentinel (fn1))); /* { dg-warning 
"not an integer constant" } */
+
+typedef int __attribute__((vector_size (fn1))) v4si; /* { dg-warning 
"attribute ignored" } */
+typedef int T __attribute__((aligned (fn1))); /* { dg-error "requested 
alignment is not" } */

Marek

C PATCH for c/71583 (ICE with bogus compound literal)

[Marek Polacek]

Since r157233, build_compound_literal will return error_mark_node for
erroneous initializers of compound literals.  This caused an ICE in
c_parser_postfix_expression_after_paren_type because the code dealing
with evaluating variably modified types wasn't prepared for expr.value
being error_mark_node.  Fixed thus.

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

2016-07-28  Marek Polacek  

PR c/71583
* c-parser.c (c_parser_postfix_expression_after_paren_type): Also
check expr.value.

* gcc.dg/noncompile/pr71583.c: New test.

diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index 8952bca..a86cae2 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -8232,7 +8232,9 @@ c_parser_postfix_expression_after_paren_type (c_parser 
*parser,
   set_c_expr_source_range (&expr, init.src_range);
   expr.original_code = ERROR_MARK;
   expr.original_type = NULL;
-  if (type != error_mark_node && type_expr)
+  if (type != error_mark_node
+  && expr.value != error_mark_node
+  && type_expr)
 {
   if (TREE_CODE (expr.value) == C_MAYBE_CONST_EXPR)
{
diff --git gcc/testsuite/gcc.dg/noncompile/pr71583.c 
gcc/testsuite/gcc.dg/noncompile/pr71583.c
index e69de29..5045b88 100644
--- gcc/testsuite/gcc.dg/noncompile/pr71583.c
+++ gcc/testsuite/gcc.dg/noncompile/pr71583.c
@@ -0,0 +1,11 @@
+/* PR c/71583 */
+/* { dg-do compile } */
+
+void
+f (int i)
+{
+  (int (*)[++i]) { int }; /* { dg-error "expected" } */
+  (int (*)[++i]) { }; /* { dg-error "empty" } */
+  (int (*)[++i]) { , }; /* { dg-error "expected" } */
+  (int (*)[++i]) { f () }; /* { dg-error "too few" } */
+}

Marek

Re: [Patch GCC]Support constraint flags in loop structure.

[Richard Biener]

On Thu, Jul 28, 2016 at 2:51 PM, Bin.Cheng  wrote:
> On Wed, Jul 27, 2016 at 11:07 AM, Richard Biener
>  wrote:
>> On Tue, Jul 26, 2016 at 7:10 PM, Bin Cheng  wrote:
>>> Hi,
>>> This patch adds support for constraint flags in loop structure.  Different 
>>> to existing boolean flags which are set by niter analyzer, constraint flag 
>>> is mainly set by consumers and affects certain semantics of niter analyzer 
>>> APIs.  Currently niter APIs affected are number_of_iterations_exit* and 
>>> their callers.  Constraint flags are added to support handling of possible 
>>> infinite loops in GCC.  One typical usecase of constraint is in vectorizer, 
>>> as described in patch's comment:
>>>
>>>   /* ...
>>>1) Compute niter->assumptions by calling niter analyzer API and
>>>   record it as possible condition for loop versioning.
>>>2) Clear buffered result of niter/scev analyzer.
>>>3) Set constraint LOOP_C_FINITE assuming the loop is finite.
>>>4) Analyze data references.  Since data reference analysis depends
>>>   on niter/scev analyzer, the point is that niter/scev analysis
>>>   is done under circumstance of LOOP_C_FINITE constraint.
>>>5) Version the loop with assumptions computed in step 1).
>>>6) Vectorize the versioned loop in which assumptions is guarded to
>>>   be true.
>>>7) Update constraints in versioned loops so that niter analyzer
>>>   in following passes can use it.
>>>
>>>  Note consumers are usually the loop optimizers and it is consumers'
>>>  responsibility to set/clear constraints correctly.  Failing to do
>>>  that might result in hard to track bugs in niter/scev analyzer.  */
>>>
>>> Next patch will use constraint to vectorize possible infinite loop by 
>>> versioning, I would also expect possible infinite loops (loops with 
>>> assumptions) can be handled by more optimizers.  This patch itself doesn't 
>>> change GCC behavior, bootstrap and test on x86_64.  Any comments?
>>
>> + Note consumers are usually the loop optimizers and it is consumers'
>> + responsibility to set/clear constraints correctly.  Failing to do
>> + that might result in hard to track bugs in niter/scev analyzer.  */
>>
>> "in hard to track down bugs in niter/scev consumers"
>>
>> +static inline void
>> +loop_constraint_clr (struct loop *loop, unsigned c)
>> +{
>>
>> use _clear (similar to loops_state_clear).  Function comments missing.
>>
>> I think we want to copy constraints in copy_loop_info.
>>
>> Please place the 'constraints' field in struct loop somewhere better,
>> between two pointers we have 4 bytes wasted on a 64bit arch.
>> Maybe you can group all bools and put constraints next to safelen
>> (yeah, we'd still waste some padding, not sure if we want to turn
>> the bools and estimate_state into a bitfield).
>>
>> It would be nice to document the constraints in doc/loop.texi.
>>
>> Ok with that changes.
> Hi,
> Attachment is the updated patch with comments addressed.

Ok.

Thanks,
Richard.

> Thanks,
> bin
>
>
> 2016-07-27  Bin Cheng  
>
> * cfgloop.h (struct loop): New field constraints.
> (LOOP_C_INFINITE, LOOP_C_FINITE): New macros.
> (loop_constraint_set, loop_constraint_clr, loop_constraint_set_p): New
> functions.
> * cfgloop.c (alloc_loop): Initialize new field.
> * cfgloopmanip.c (copy_loop_info): Copy constraints.
> * tree-ssa-loop-niter.c (number_of_iterations_exit_assumptions):
> Adjust niter analysis wrto loop constraints.
> * doc/loop.texi (@node Number of iterations): Add description for loop
> constraints.

Re: [Patch GCC]Support constraint flags in loop structure.

[Bin.Cheng]

On Wed, Jul 27, 2016 at 11:07 AM, Richard Biener
 wrote:
> On Tue, Jul 26, 2016 at 7:10 PM, Bin Cheng  wrote:
>> Hi,
>> This patch adds support for constraint flags in loop structure.  Different 
>> to existing boolean flags which are set by niter analyzer, constraint flag 
>> is mainly set by consumers and affects certain semantics of niter analyzer 
>> APIs.  Currently niter APIs affected are number_of_iterations_exit* and 
>> their callers.  Constraint flags are added to support handling of possible 
>> infinite loops in GCC.  One typical usecase of constraint is in vectorizer, 
>> as described in patch's comment:
>>
>>   /* ...
>>1) Compute niter->assumptions by calling niter analyzer API and
>>   record it as possible condition for loop versioning.
>>2) Clear buffered result of niter/scev analyzer.
>>3) Set constraint LOOP_C_FINITE assuming the loop is finite.
>>4) Analyze data references.  Since data reference analysis depends
>>   on niter/scev analyzer, the point is that niter/scev analysis
>>   is done under circumstance of LOOP_C_FINITE constraint.
>>5) Version the loop with assumptions computed in step 1).
>>6) Vectorize the versioned loop in which assumptions is guarded to
>>   be true.
>>7) Update constraints in versioned loops so that niter analyzer
>>   in following passes can use it.
>>
>>  Note consumers are usually the loop optimizers and it is consumers'
>>  responsibility to set/clear constraints correctly.  Failing to do
>>  that might result in hard to track bugs in niter/scev analyzer.  */
>>
>> Next patch will use constraint to vectorize possible infinite loop by 
>> versioning, I would also expect possible infinite loops (loops with 
>> assumptions) can be handled by more optimizers.  This patch itself doesn't 
>> change GCC behavior, bootstrap and test on x86_64.  Any comments?
>
> + Note consumers are usually the loop optimizers and it is consumers'
> + responsibility to set/clear constraints correctly.  Failing to do
> + that might result in hard to track bugs in niter/scev analyzer.  */
>
> "in hard to track down bugs in niter/scev consumers"
>
> +static inline void
> +loop_constraint_clr (struct loop *loop, unsigned c)
> +{
>
> use _clear (similar to loops_state_clear).  Function comments missing.
>
> I think we want to copy constraints in copy_loop_info.
>
> Please place the 'constraints' field in struct loop somewhere better,
> between two pointers we have 4 bytes wasted on a 64bit arch.
> Maybe you can group all bools and put constraints next to safelen
> (yeah, we'd still waste some padding, not sure if we want to turn
> the bools and estimate_state into a bitfield).
>
> It would be nice to document the constraints in doc/loop.texi.
>
> Ok with that changes.
Hi,
Attachment is the updated patch with comments addressed.

Thanks,
bin


2016-07-27  Bin Cheng  

* cfgloop.h (struct loop): New field constraints.
(LOOP_C_INFINITE, LOOP_C_FINITE): New macros.
(loop_constraint_set, loop_constraint_clr, loop_constraint_set_p): New
functions.
* cfgloop.c (alloc_loop): Initialize new field.
* cfgloopmanip.c (copy_loop_info): Copy constraints.
* tree-ssa-loop-niter.c (number_of_iterations_exit_assumptions):
Adjust niter analysis wrto loop constraints.
* doc/loop.texi (@node Number of iterations): Add description for loop
constraints.
diff --git a/gcc/cfgloop.c b/gcc/cfgloop.c
index 2087b90..b5c920c 100644
--- a/gcc/cfgloop.c
+++ b/gcc/cfgloop.c
@@ -339,6 +339,7 @@ alloc_loop (void)
   loop->exits = ggc_cleared_alloc ();
   loop->exits->next = loop->exits->prev = loop->exits;
   loop->can_be_parallel = false;
+  loop->constraints = 0;
   loop->nb_iterations_upper_bound = 0;
   loop->nb_iterations_likely_upper_bound = 0;
   loop->nb_iterations_estimate = 0;
diff --git a/gcc/cfgloop.h b/gcc/cfgloop.h
index dfc7525..5c202eb 100644
--- a/gcc/cfgloop.h
+++ b/gcc/cfgloop.h
@@ -188,6 +188,29 @@ struct GTY ((chain_next ("%h.next"))) loop {
  of the loop can be safely evaluated concurrently.  */
   int safelen;
 
+  /* Constraints are generally set by consumers and affect certain
+ semantics of niter analyzer APIs.  Currently the APIs affected are
+ number_of_iterations_exit* functions and their callers.  One typical
+ use case of constraints is to vectorize possibly infinite loop:
+
+   1) Compute niter->assumptions by calling niter analyzer API and
+ record it as possible condition for loop versioning.
+   2) Clear buffered result of niter/scev analyzer.
+   3) Set constraint LOOP_C_FINITE assuming the loop is finite.
+   4) Analyze data references.  Since data reference analysis depends
+ on niter/scev analyzer, the point is that niter/scev analysis
+ is done under circumstance of LOOP_C_FINITE constraint.
+   5) Version the loop with niter->assumptions computed in step 1).
+ 

Re: [PR70920] transform (intptr_t) x eq/ne CST to x eq/ne (typeof x) cst

[Prathamesh Kulkarni]

On 28 July 2016 at 15:58, Andreas Schwab  wrote:
> On Mo, Jul 25 2016, Prathamesh Kulkarni  
> wrote:
>
>> diff --git a/gcc/testsuite/gcc.dg/pr70920-4.c 
>> b/gcc/testsuite/gcc.dg/pr70920-4.c
>> new file mode 100644
>> index 000..dedb895
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/pr70920-4.c
>> @@ -0,0 +1,21 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-O2 -fdump-tree-ccp-details -Wno-int-to-pointer-cast" } */
>> +
>> +#include 
>> +
>> +void f1();
>> +void f2();
>> +
>> +void
>> +foo (int a)
>> +{
>> +  void *cst = 0;
>> +  if ((int *) a == cst)
>> +{
>> +  f1 ();
>> +  if (a)
>> + f2 ();
>> +}
>> +}
>> +
>> +/* { dg-final { scan-tree-dump "gimple_simplified to if \\(_\[0-9\]* == 
>> 0\\)" "ccp1" } } */
>
> This fails on all ilp32 platforms.
Oops, sorry for the breakage.
With -m32, the pattern is applied during forwprop1 rather than ccp1.
I wonder though why ccp1 fails to fold the pattern with -m32 ?
Looking at the dumps:

without -m32:
input to ccp1 pass:
  :
  cst_4 = 0B;
  _1 = (long int) a_5(D);
  _2 = (void *) _1;
  if (cst_4 == _2)
goto ;
  else
goto ;

cc1 pass dump shows:
Substituting values and folding statements

Folding statement: _1 = (long int) a_5(D);
Not folded
Folding statement: _2 = (void *) _1;
Not folded
Folding statement: if (cst_4 == _2)
which is likely CONSTANT
Applying pattern match.pd:2537, gimple-match.c:6530
gimple_simplified to if (_1 == 0)
Folded into: if (_1 == 0)

with -m32:
input to ccp1 pass:
 :
  cst_3 = 0B;
  a.0_1 = (void *) a_4(D);
  if (cst_3 == a.0_1)
goto ;
  else
goto ;

ccp1 pass dump shows:
Substituting values and folding statements

Folding statement: a.0_1 = (void *) a_4(D);
Not folded
Folding statement: if (cst_3 == a.0_1)
which is likely CONSTANT
Folded into: if (a.0_1 == 0B)

I am not able to understand why it doesn't fold it to
if (a_4(D) == 0) ?
forwprop1 folds a.0_1 == 0B to a_4(D) == 0.

I suppose the test-case would need to scan ccp1 for non-ilp targets
and forwprop1 for
ilp targets. How do update the test-case to reflect this ?

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

Re: [PATCH 13/17][ARM] Add VFP FP16 instrinsics.

[Ramana Radhakrishnan]

On Mon, Jul 4, 2016 at 3:14 PM, Matthew Wahab
 wrote:
> On 17/05/16 15:44, Matthew Wahab wrote:
>> The ARMv8.2-A architecture introduces an optional FP16 extension adding
>> half-precision floating point data processing instructions to the
>> existing scalar (floating point) support. A future version of the ACLE
>> will add support for these instructions and this patch implements that
>> support.
>
> Updated to use the standard arithmetic operations for vnegh_f16,
> vaddh_f16, vsubh_f16, vmulh_f16 and vdivh_f16.
>
> Tested the series for arm-none-linux-gnueabihf with native bootstrap and
> make check and for arm-none-eabi and armeb-none-eabi with make check on
> an ARMv8.2-A emulator.
>
> Ok for trunk?
> Matthew
>
> 2016-07-04  Matthew Wahab  
>
> * config.gcc (extra_headers): Add arm_fp16.h
> * config/arm/arm_fp16.h: New.
> * config/arm/arm_neon.h: Include "arm_fp16.h".
>


OK.

Ramana

Re: [PATCH 12/17][ARM] Add builtins for NEON FP16 intrinsics.

[Ramana Radhakrishnan]

On Mon, Jul 4, 2016 at 3:13 PM, Matthew Wahab
 wrote:
> On 17/05/16 15:42, Matthew Wahab wrote:
>> This patch adds the builtins data for the ACLE intrinsics introduced to
>> support the NEON instructions of the ARMv8.2-A FP16 extension.
>
> Updated to fix the vsqrte/vrsqrte spelling mistake and correct the
> changelog.
>
> Tested the series for arm-none-linux-gnueabihf with native bootstrap and
> make check and for arm-none-eabi and armeb-none-eabi with make check on
> an ARMv8.2-A emulator.
>
> Ok for trunk?

Ok ...

Ramana


> Matthew
>
> 2016-07-04  Matthew Wahab  
>
>
> * config/arm/arm_neon_builtins.def (vadd): New (v8hf, v4hf
> variants).
> (vmulf): New (v8hf, v4hf variants).
> (vfma): New (v8hf, v4hf variants).
> (vfms): New (v8hf, v4hf variants).
> (vsub): New (v8hf, v4hf variants).
> (vcage): New (v8hf, v4hf variants).
> (vcagt): New (v8hf, v4hf variants).
> (vcale): New (v8hf, v4hf variants).
> (vcalt): New (v8hf, v4hf variants).
> (vceq): New (v8hf, v4hf variants).
> (vcgt): New (v8hf, v4hf variants).
> (vcge): New (v8hf, v4hf variants).
> (vcle): New (v8hf, v4hf variants).
> (vclt): New (v8hf, v4hf variants).
> (vceqz): New (v8hf, v4hf variants).
> (vcgez): New (v8hf, v4hf variants).
> (vcgtz): New (v8hf, v4hf variants).
> (vcltz): New (v8hf, v4hf variants).
> (vclez): New (v8hf, v4hf variants).
> (vabd): New (v8hf, v4hf variants).
> (vmaxf): New (v8hf, v4hf variants).
> (vmaxnm): New (v8hf, v4hf variants).
> (vminf): New (v8hf, v4hf variants).
> (vminnm): New (v8hf, v4hf variants).
> (vpmaxf): New (v4hf variant).
> (vpminf): New (v4hf variant).
> (vpadd): New (v4hf variant).
> (vrecps): New (v8hf, v4hf variants).
> (vrsqrts): New (v8hf, v4hf variants).
> (vabs): New (v8hf, v4hf variants).
> (vneg): New (v8hf, v4hf variants).
> (vrecpe): New (v8hf, v4hf variants).
> (vrnd): New (v8hf, v4hf variants).
> (vrnda): New (v8hf, v4hf variants).
> (vrndm): New (v8hf, v4hf variants).
> (vrndn): New (v8hf, v4hf variants).
> (vrndp): New (v8hf, v4hf variants).
> (vrndx): New (v8hf, v4hf variants).
> (vrsqrte): New (v8hf, v4hf variants).
> (vmul_lane): Add v4hf and v8hf variants.
> (vmul_n): Add v4hf and v8hf variants.
> (vext): New (v8hf, v4hf variants).
> (vcvts): New (v8hi, v4hi variants).
> (vcvts): New (v8hf, v4hf variants).
> (vcvtu): New (v8hi, v4hi variants).
> (vcvtu): New (v8hf, v4hf variants).
> (vcvts_n): New (v8hf, v4hf variants).
> (vcvtu_n): New (v8hi, v4hi variants).
> (vcvts_n): New (v8hi, v4hi variants).
> (vcvtu_n): New (v8hf, v4hf variants).
> (vbsl): New (v8hf, v4hf variants).
> (vcvtas): New (v8hf, v4hf variants).
> (vcvtau): New (v8hf, v4hf variants).
> (vcvtms): New (v8hf, v4hf variants).
> (vcvtmu): New (v8hf, v4hf variants).
> (vcvtns): New (v8hf, v4hf variants).
> (vcvtnu): New (v8hf, v4hf variants).
> (vcvtps): New (v8hf, v4hf variants).
> (vcvtpu): New (v8hf, v4hf variants).
>

Re: [PATCH 11/17][ARM] Add builtins for VFP FP16 intrinsics.

[Ramana Radhakrishnan]

On Mon, Jul 4, 2016 at 3:11 PM, Matthew Wahab
 wrote:
> On 17/05/16 15:41, Matthew Wahab wrote:
>> The ACLE intrinsics introduced to support the ARMv8.2 FP16 extensions
>> require that intrinsics for scalar floating pointer (VFP) instructions
>> are available under different conditions from those for the NEON
>> intrinsics.
>>
>> This patch adds the support code and builtins data for the new VFP
>> intrinsics. Because of the similarities between the scalar and NEON
>> builtins, the support code for the scalar builtins follows the code for
>> the NEON builtins. The declarations for the VFP builtins are also added
>> in this patch since the support code expects non-empty tables.
>
> Updated the patch to drop the builtins for vneg, vadd, vsub, vmul and
> vdiv, which are no longer needed.
>
> Tested the series for arm-none-linux-gnueabihf with native bootstrap and
> make check and for arm-none-eabi and armeb-none-eabi with make check on
> an ARMv8.2-A emulator.
>
> Ok for trunk?
> Matthew
>
> 2016-07-04  Matthew Wahab  
>
> * config/arm/arm-builtins.c (hf_UP): New.
> (si_UP): New.
> (vfp_builtin_data): New.  Update comment.
> (enum arm_builtins): Include "arm_vfp_builtins.def".
> (ARM_BUILTIN_VFP_PATTERN_START): New.
> (arm_init_vfp_builtins): New.
> (arm_init_builtins): Add arm_init_vfp_builtins.
> (arm_expand_vfp_builtin): New.
> (arm_expand_builtins): Update for arm_expand_vfp_builtin.  Fix
> long line.
> * config/arm/arm_vfp_builtins.def: New file.
>
> * config/arm/t-arm (arm.o): Add arm_vfp_builtins.def.
> (arm-builtins.o): Likewise.
>


OK.

Ramana

Re: [PATCH 10/17][ARM] Refactor support code for NEON builtins.

[Ramana Radhakrishnan]

On Tue, May 17, 2016 at 3:39 PM, Matthew Wahab
 wrote:
> The ACLE intrinsics introduced to support the ARMv8.2 FP16 extensions
> require that intrinsics for scalar (VFP) instructions are available
> under different conditions from those for the NEON intrinsics. To
> support this, changes to the builtins support code are needed to enable
> the scalar intrinsics to be initialized and expanded independently of
> the NEON intrinsics.
>
> This patch prepares for this by refactoring some of the builtin support
> code so that it can be used for both the scalar and the NEON intrinsics.
>
> Tested the series for arm-none-linux-gnueabihf with native bootstrap and
> make check and for arm-none-eabi and armeb-none-eabi with make check on
> an ARMv8.2-A emulator.


OK.

Ramana
>
> Ok for trunk?
> Matthew
>
> 2016-05-17  Matthew Wahab  
>
> * config/arm/arm-builtins.c (ARM_BUILTIN_NEON_PATTERN_START):
> Change offset calculation.
> (arm_init_neon_builtin): New.
> (arm_init_builtins): Move body of a loop to the standalone
> function arm_init_neon_builtin.
> (arm_expand_neon_builtin_1): New.  Update comment.  Function body
> moved from arm_expand_neon_builtin with some white-space fixes.
> (arm_expand_neon_builtin): Move code into the standalone function
> arm_expand_neon_builtin_1.
>

Re: [PATCH 9/17][ARM] Add NEON FP16 arithmetic instructions.

[Ramana Radhakrishnan]

On Mon, Jul 4, 2016 at 3:09 PM, Matthew Wahab
 wrote:
> On 18/05/16 01:58, Joseph Myers wrote:
>> On Tue, 17 May 2016, Matthew Wahab wrote:
>>
>>> As with the VFP FP16 arithmetic instructions, operations on __fp16
>>> values are done by conversion to single-precision. Any new optimization
>>> supported by the instruction descriptions can only apply to code
>>> generated using intrinsics added in this patch series.
>>
>> As with the scalar instructions, I think it is legitimate in most cases to
>> optimize arithmetic via single precision to work direct on __fp16 values
>> (and this would be natural for vectorization of __fp16 arithmetic).
>>
>>> A number of the instructions are modelled as two variants, one using
>>> UNSPEC and the other using RTL operations, with the model used decided
>>> by the funsafe-math-optimizations flag. This follows the
>>> single-precision instructions and is due to the half-precision
>>> operations having the same conditions and restrictions on their use in
>>> optmizations (when they are enabled).
>>
>> (Of course, these restrictions still apply.)
>
> The F16 support generally follows the F32 implementation and, for F32,
> direct arithmetic vector operations are only available when
> unsafe-math-optimizations is enabled. I want to check the behaviour of
> the F16 operations when unsafe-math is enabled so I'll defer to a follow
> up patch the change to use standard names for the vector operations.
>
> There are still some changes from the previous patch:
>
> - Two fma/fmsub patterns *fma4 and <*fmsub4 are
>   dropped since they just duplicated *fma4_intrinsic and
>   <*fmsub4_intrinsic.
>
> - Patterns neon_vadd_unspec and neon_vsub_unspec are
>   dropped, they were redundant.
>
> - 2_fp16 is renamed to 2. This
>   implements the abs and neg operations which are always safe to use.
>
> - neon_vsqrte is renamed to neon_vrsqrte. This is a
>   misspelled intrinsic that wasn't caught in testing because the
>   relevant test case is missing. The intrinsic is fixed here and in
>   other patches and an advsimd-intrinsics test added later in the
>   (updated) series.
>
> - neon_vcvt_n   correct range for f16 is 0-17.
>
> - Test armv8_2-fp16-arith-1.c is updated to expect f16 arithmetic
>   instructions rather then f32 and to use the neon command line options.
>
> Tested the series for arm-none-linux-gnueabihf with native bootstrap and
> make check and for arm-none-eabi and armeb-none-eabi with make check on
> an ARMv8.2-A emulator.
>
> Ok for trunk?

OK.

Ramana
> Matthew
>
> 2016-07-04  Matthew Wahab  
>
> * config/arm/iterators.md (VCVTHI): New.
> (NEON_VCMP): Add UNSPEC_VCLT and UNSPEC_VCLE.  Fix a long line.
> (NEON_VAGLTE): New.
> (VFM_LANE_AS): New.
> (VH_CVTTO): New.
> (V_reg): Add HF, V4HF and V8HF.  Fix white-space.
> (V_HALF): Add V4HF.  Fix white-space.
> (V_if_elem): Add HF, V4HF and V8HF.  Fix white-space.
> (V_s_elem): Likewise.
> (V_sz_elem): Fix white-space.
> (V_elem_ch): Likewise.
> (VH_elem_ch): New.
> (scalar_mul_constraint): Add V8HF and V4HF.
> (Is_float_mode): Fix white-space.
> (Is_d_reg): Fix white-space.
> (q): Add HF.  Fix white-space.
> (float_sup): New.
> (float_SUP): New.
> (cmp_op_unsp): Add UNSPEC_VCALE and UNSPEC_VCALT.
> (neon_vfm_lane_as): New.
> * config/arm/neon.md (add3_fp16): New.
> (sub3_fp16): New.
> (mul3add_neon): New.
> (fma4_intrinsic): New.
> (fmsub4_intrinsic): Fix white-space.
> (fmsub4_intrinsic): New.
> (2): New.
> (neon_v): New.
> (neon_v): New.
> (neon_vrsqrte): New.
> (neon_vpaddv4hf): New.
> (neon_vadd): New.
> (neon_vsub): New.
> (neon_vmulf): New.
> (neon_vfma): New.
> (neon_vfms): New.
> (neon_vc): New.
> (neon_vc_fp16insn): New
> (neon_vc_fp16insn_unspec): New.
> (neon_vca): New.
> (neon_vca_fp16insn): New.
> (neon_vca_fp16insn_unspec): New.
> (neon_vcz): New.
> (neon_vabd): New.
> (neon_vf): New.
> (neon_vpfv4hf: New.
> (neon_): New.
> (neon_vrecps): New.
> (neon_vrsqrts): New.
> (neon_vrecpe): New (VH variant).
> (neon_vdup_lane_internal): New.
> (neon_vdup_lane): New.
> (neon_vcvt): New (VCVTHI variant).
> (neon_vcvt): New (VH variant).
> (neon_vcvt_n): New (VH variant).
> (neon_vcvt_n): New (VCVTHI variant).
> (neon_vcvt): New.
> (neon_vmul_lane): New.
> (neon_vmul_n): New.
> * config/arm/unspecs.md (UNSPEC_VCALE): New
> (UNSPEC_VCALT): New.
> (UNSPEC_VFMA_LANE): New.
> (UNSPECS_VFMS_LANE): New.
>
> testsuite/
> 2016-07-04  Matthew Wahab  
>
> * gcc.target/arm/armv8_2-fp16-arith-1.c: Use arm_v8_2a_fp16_neon
> options

Re: [patch, avr] Fix mmcu to specs issues

[Pitchumani Sivanupandi]

On Tuesday 26 July 2016 06:00 PM, Georg-Johann Lay wrote:

On 26.07.2016 12:20, Pitchumani Sivanupandi wrote:
avr-gcc expected to find the device specs in the search paths 
specified. But
it doesn't work as expected when device specs in different place than 
the

installed location.

Example-1:
avr-gcc wrongly assumes the device specs will be in first identified
'device-specs' folder in prefix path. avr-gcc natively supports device
at90pwm1, but complains as it couldn't find the specs file in the first
'device-specs' directory in the search path.


$ avr-gcc test.c -mmcu=at90pwm1 -B /home/install/dev/atxmega128a1u/

avr-gcc: error: cannot access device-specs for _at90pwm1_ expected at


Are the "_"s literally? Then the spec file name should be 
"specs-_at90pwm1_".
No, It was mangled character shown by my terminal for format specifier 
"%qs" in printf.

Ignore it.
...

Example-2:
Similar issue happens when -flto option is enabled and device specs 
in custom

search path.

atxmega128a1u device specs in custom path and that is passed with -B 
option.
Architecture spec files such as specs-avrxmega7 will be in installed 
location.


$ avr-gcc test.c -mmcu=atxmega128a1u -flto -B 
/home/install/dev/atxmega128a1u/


avr-gcc: error: cannot access device-specs for _avrxmega7_ expected at
_/home/install/dev/atxmega128a1u/device-specs/specs-avrxmega7_
avr-gcc: note: supported core architectures: avr2 avr25 avr3 avr31 
avr35 avr4
avr5 avr51 avr6 avrxmega2 avrxmega4 avrxmega5 avrxmega6 avrxmega7 
avrtiny avr1

avr-gcc: note: you can provide your own specs files, see
 for details
lto-wrapper: fatal error: avr-gcc returned 1 exit status
compilation terminated.
/home/avr-trunk/install/lib/gcc/avr/7.0.0/../../../../avr/bin/ld: error:
lto-wrapper failed
collect2: error: ld returned 1 exit status

Attached patch to address these issues.

Fix:
Replace device-specs-file spec function with mmcu-to-device-specs. 
This will
not assume that specs files are in first identified device-specs 
directory.
Instead this spec function will let gcc identify the absolute path of 
specs file

using spec string "device-specs-file (device-specs/specs-%s)".


IIUC this leads to problems with LTO and when the install path 
contains spaces which windows distros usually have.  The problem is 
that the spec function cannot escape the spaces as it would need more 
than 1 escape level.


It might also be the case that -mmcu= is specified more than once 
(with the same MCU), but I don't remember exactly in which situations 
this happens... Doesn't this lead to inclusion of more than one 
specs-file?


Yes, it lead to space problem.

Modified the patch because of path with spaces problem. When LTO 
enabled, multiple specs-file are
included as -mmcu= is fed back to gcc. It happens with/ without of 
this patch.
e.g. For atmega164p, device's and architecture's specs file given when 
invoking collect2.

 -specs=device-specs/specs-atmega164p -specs=device-specs/specs-avr5

Attached new patch. It just removes the conditions that led to 
originally stated issues.

(In driver-avr.c:avr_devicespecs_file)
Removed first condition as -mmcu=avr* shall come when LTO enabled. 
Second condition to
check absolute path is wrong as the specfile_name composed here will not 
be available

if the specs file is not present in first 'device-specs' directory.

With this approach, we can't issue 'descriptive' error for unavailable 
specs-file.

But, avr-gcc will issue below error if specs file is not found.
$ avr-gcc -mmcu=unknown test.c
avr-gcc: error: device-specs/specs-unknown: No such file or directory

Is that Ok?

Regards,
Pitchumani

gcc/ChangeLog

2016-07-28  Pitchumani Sivanupandi 

* config/avr/driver-avr.c (specfiles_doc_url): Remove.
(avr_diagnose_devicespecs_error): Remove.
(avr_devicespecs_file): Remove conditions to check specs-file,
let -specs= option handler do the validation.
diff --git a/gcc/config/avr/driver-avr.c b/gcc/config/avr/driver-avr.c
index 83ca373..647f91b 100644
--- a/gcc/config/avr/driver-avr.c
+++ b/gcc/config/avr/driver-avr.c
@@ -29,41 +29,18 @@ along with GCC; see the file COPYING3.  If not see
 
 static const char dir_separator_str[] = { DIR_SEPARATOR, 0 };
 
-static const char specfiles_doc_url[] =
-  "http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html";;
-
-
-static const char*
-avr_diagnose_devicespecs_error (const char *mcu, const char *filename)
-{
-  error ("cannot access device-specs for %qs expected at %qs",
- mcu, filename);
-
-  // Inform about natively supported devices and cores.
-
-  if (strncmp (mcu, "avr", strlen ("avr")))
-avr_inform_devices ();
-
-  avr_inform_core_architectures ();
-
-  inform (input_location, "you can provide your own specs files, "
-  "see <%s> for details", specfiles_doc_url);
-
-  return X_NODEVLIB;
-}
-
 
 /* Implement spec function `device-specs-file´.
 
-   Compose -specs=%s.  If everything went well then argv[0]
- 

Re: [C++ RFC/Patch] PR c++/71665

[Paolo Carlini]

Hi,

On 18/07/2016 20:16, Jason Merrill wrote:

On Tue, Jul 12, 2016 at 10:30 AM, Paolo Carlini
 wrote:

On 30/06/2016 19:49, Jason Merrill wrote:

I think we should check the type before calling cxx_constant_value.


Ok, I got the point. I'm not sure however how far we want to go with this
and which kind of consistency we want to achieve (vs error messages issued
in other similar circumstances). The below certainly passes testing on
x86_64-linux.

I meant the actual type of the expression: that is, check
INTEGRAL_OR_ENUMERATION_TYPE_P before calling cxx_constant_value.
Ah sorry, I missed the *type* bit. The below passes testing on 
x86_64-linux. I don't think we need to check the type again after 
cxx_constant_value?!?


While finally spending a decent amount of time on this issue I noticed 
that current clang appears to enforce integral or *unscoped* enumeration 
type and tweaking our code in the obvious way doesn't cause regressions, 
we of course reject earlier (ie, not as "could not convert ‘(E)1’ from 
‘E’ to ‘unsigned int’") in build_enumeraror snippets like:


enum class E { e = 1 };

class A
{
  enum { a = E::e };
};

I didn't investigate the issue further, however.

Thanks,
Paolo.

//

Index: cp/decl.c
===
--- cp/decl.c   (revision 238807)
+++ cp/decl.c   (working copy)
@@ -13587,15 +13587,23 @@ build_enumerator (tree name, tree value, tree enum
 
  if (value != NULL_TREE)
{
- value = cxx_constant_value (value);
-
- if (TREE_CODE (value) != INTEGER_CST
- || ! INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (value)))
+ if (! INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (value)))
{
- error ("enumerator value for %qD is not an integer constant",
-name);
+ error ("enumerator for %qD must have integral or "
+"enumeration type", name);
  value = NULL_TREE;
}
+ else
+   {
+ value = cxx_constant_value (value);
+
+ if (TREE_CODE (value) != INTEGER_CST)
+   {
+ error ("enumerator value for %qD is not an integer "
+"constant", name);
+ value = NULL_TREE;
+   }
+   }
}
}
 
Index: testsuite/g++.dg/cpp0x/enum29.C
===
--- testsuite/g++.dg/cpp0x/enum29.C (revision 238807)
+++ testsuite/g++.dg/cpp0x/enum29.C (working copy)
@@ -38,7 +38,7 @@ enum E0 { e0 = X0() };
 enum E1 { e1 = X1() };
 enum E2 { e2 = X2() };
 enum E3 { e3 = X3() };
-enum E4 { e4 = X4() };  // { dg-error "integer constant" }
+enum E4 { e4 = X4() };  // { dg-error "integral" }
 enum E5 { e5 = X5() };  // { dg-error "ambiguous" }
 
 enum F0 : int { f0 = X0() };
Index: testsuite/g++.dg/cpp0x/pr71665.C
===
--- testsuite/g++.dg/cpp0x/pr71665.C(revision 0)
+++ testsuite/g++.dg/cpp0x/pr71665.C(working copy)
@@ -0,0 +1,8 @@
+// PR c++/71665
+// { dg-do compile { target c++11 } }
+
+class A 
+{
+  int f ();
+  enum { a = f }; // { dg-error "enumerator" }
+};
Index: testsuite/g++.dg/ext/label10.C
===
--- testsuite/g++.dg/ext/label10.C  (revision 238807)
+++ testsuite/g++.dg/ext/label10.C  (working copy)
@@ -4,7 +4,7 @@
 
 template struct A
 {
-  enum { M = && N };   // { dg-error "referenced outside|cannot appear in|not 
an integer constant" }
+  enum { M = && N };   // { dg-error "referenced outside|cannot appear 
in|integral" }
 };
 
 A<0> a;
@@ -12,6 +12,6 @@ A<0> a;
 void foo ()
 {
   __label__ P;
-  enum { O = && P };   // { dg-error "cannot appear in|not an integer 
constant" }
+  enum { O = && P };   // { dg-error "cannot appear in|integral" }
   P:;
 }
Index: testsuite/g++.dg/parse/constant5.C
===
--- testsuite/g++.dg/parse/constant5.C  (revision 238807)
+++ testsuite/g++.dg/parse/constant5.C  (working copy)
@@ -1,7 +1,7 @@
 // { dg-options "-std=c++98 -pedantic-errors" }
 
 enum E { 
-  a = 24.2, // { dg-error "constant" }
+  a = 24.2, // { dg-error "integral|constant" }
   b = (int)3.7, 
   c = int(4.2),
   d = (int)(4.2 + 3.7), // { dg-error "constant" }

Re: [PATCH 8/17][ARM] Add VFP FP16 arithmetic instructions.

[Ramana Radhakrishnan]

On Mon, Jul 4, 2016 at 3:02 PM, Matthew Wahab
 wrote:
> On 19/05/16 15:54, Matthew Wahab wrote:
>> On 18/05/16 16:20, Joseph Myers wrote:
>>> On Wed, 18 May 2016, Matthew Wahab wrote:
>>>
>>> In short: instructions for direct HFmode arithmetic should be described
>>> with patterns with the standard names.  It's the job of the
>>> architecture-independent compiler to ensure that fp16 arithmetic in the
>>> user's source code only generates direct fp16 arithmetic in GIMPLE (and
>>> thus ends up using those patterns) if that is a correct representation of
>>> the source code's semantics according to ACLE.
>>>
>>> The intrinsics you provide can then be written to use direct arithmetic,
>>> and rely on convert_to_real_1 eliminating the promotions, rather than
>>> needing built-in functions at all, just like many arm_neon.h intrinsics
>>> make direct use of GNU C vector arithmetic.
>>
>> I think it's clear that this has exhausted my knowledge of FP semantics.
>>
>> Forcing promotion to single-precision was to settle concerns brought up in
>> internal discussions about __fp16 semantics. I'll see if anybody has any
>> problem with the changes you suggest.
>
> This patch changes the implementation to use the standard names for the
> HFmode arithmetic. Later patches will also be updated to use the
> arithmetic operators where appropriate.
>
> Changes since the last version of this patch:
> - The standard names for plus, minus, mult, div and fma are defined for
>   HF mode.
> - The patterns supporting the new ACLE intrinsics vnegh_f16, vaddh_f16,
>   vsubh_f16, vmulh_f16 and vdivh_f16 are removed, the arithmetic
>   operators will be used instead.
> - The tests are updated to expect f16 instructions rather than the f32
>   instructions that were previously emitted.
>
> Tested the series for arm-none-linux-gnueabihf with native bootstrap and
> make check and for arm-none-eabi and armeb-none-eabi with make check on
> an ARMv8.2-A emulator.


All fine except -

Why can we not extend the  and the l in
vfp.md for fp16 and avoid all the unspecs for vcvta and vrnd*
instructions ?

Ramana




>
> Ok for trunk?
> Matthew
>
> 2016-07-04  Matthew Wahab  
>
> * config/arm/iterators.md (Code iterators): Fix some white-space
> in the comments.
> (GLTE): New.
> (ABSNEG): New
> (FCVT): Moved from vfp.md.
> (VCVT_HF_US_N): New.
> (VCVT_SI_US_N): New.
> (VCVT_HF_US): New.
> (VCVTH_US): New.
> (FP16_RND): New.
> (absneg_str): New.
> (FCVTI32typename): Moved from vfp.md.
> (sup): Add UNSPEC_VCVTA_S, UNSPEC_VCVTA_U, UNSPEC_VCVTM_S,
> UNSPEC_VCVTM_U, UNSPEC_VCVTN_S, UNSPEC_VCVTN_U, UNSPEC_VCVTP_S,
> UNSPEC_VCVTP_U, UNSPEC_VCVT_HF_S_N, UNSPEC_VCVT_HF_U_N,
> UNSPEC_VCVT_SI_S_N, UNSPEC_VCVT_SI_U_N,  UNSPEC_VCVTH_S_N,
> UNSPEC_VCVTH_U_N, UNSPEC_VCVTH_S and UNSPEC_VCVTH_U.
>
> (vcvth_op): New.
> (fp16_rnd_str): New.
> (fp16_rnd_insn): New.


> * config/arm/unspecs.md (UNSPEC_VCVT_HF_S_N): New.
> (UNSPEC_VCVT_HF_U_N): New.
> (UNSPEC_VCVT_SI_S_N): New.
> (UNSPEC_VCVT_SI_U_N): New.
> (UNSPEC_VCVTH_S): New.
> (UNSPEC_VCVTH_U): New.
> (UNSPEC_VCVTA_S): New.
> (UNSPEC_VCVTA_U): New.
> (UNSPEC_VCVTM_S): New.
> (UNSPEC_VCVTM_U): New.
> (UNSPEC_VCVTN_S): New.
> (UNSPEC_VCVTN_U): New.
> (UNSPEC_VCVTP_S): New.
> (UNSPEC_VCVTP_U): New.
> (UNSPEC_VCVTP_S): New.
> (UNSPEC_VCVTP_U): New.
> (UNSPEC_VRND): New.
> (UNSPEC_VRNDA): New.
> (UNSPEC_VRNDI): New.
> (UNSPEC_VRNDM): New.
> (UNSPEC_VRNDN): New.
> (UNSPEC_VRNDP): New.
> (UNSPEC_VRNDX): New.
> * config/arm/vfp.md (hf2): New.
> (neon_vabshf): New.
> (neon_vhf): New.
> (neon_vrndihf): New.
> (addhf3): New.
> (subhf3): New.
> (divhf3): New.
> (mulhf3): New.
> (*mulsf3neghf_vfp): New.
> (*negmulhf3_vfp): New.
> (*mulsf3addhf_vfp): New.
> (*mulhf3subhf_vfp): New.
> (*mulhf3neghfaddhf_vfp): New.
> (*mulhf3neghfsubhf_vfp): New.
> (fmahf4): New.
> (neon_vfmahf): New.
> (fmsubhf4_fp16): New.
> (neon_vfmshf): New.
> (*fnmsubhf4): New.
> (*fnmaddhf4): New.
> (neon_vsqrthf): New.
> (neon_vrsqrtshf): New.
> (FCVT): Move to iterators.md.
> (FCVTI32typename): Likewise.
> (neon_vcvthhf): New.
> (neon_vcvthsi): New.
> (neon_vcvth_nhf_unspec): New.
> (neon_vcvth_nhf): New.
> (neon_vcvth_nsi_unspec): New.
> (neon_vcvth_nsi): New.
> (neon_vcvthsi): New.
> (neon_hf): New.
>
> testsuite/
> 2016-07-04  Matthew Wahab  
>
>
> * gcc.target/arm/armv8_2-fp16-arith-1.c: New.
> * gcc.target/arm/armv8_2-fp16-conv-1.c: New.
>

Re: [RFC][IPA-VRP] Early VRP Implementation

[Richard Biener]

On Thu, Jul 28, 2016 at 9:35 AM, kugan
 wrote:
> Hi Richard,
>
> Thanks for the review.
>>
>>
>> It seems that in your pop_value_range you assume you only pop one
>> range per BB - while that's likely true at the moment it will be a
>> limitation
>> in the future.  You want to pop ranges until you hit the NULL marker
>> in after_dom_children and unconditionally push a NULL marker.
>>
> I understand. Right now, I am adding only one assert based on the condition.
> But in future, we will be adding more so this is needed. I will do that.
>
>> For example to match current VRPs behavior on say
>>
>>i_2 = (int) j_3;
>>if (i_2 < 0)
>>  ...
>>
>> which can register an assert for j_3 when i_2 < 0 is true we'd do that
>> by re-simulating DEFs of uses we figured out new ranges of (and all
>> their uses).  All those ranges would be temporary as well, thus they'd
>> need to be pushed/popped.  In my quick prototype this was done
>> using a worklist seeded by the names we can derive a range from from
>> conditionals and "SSA propagating" from it.  Note that for this
>> the generic vrp_visit_stmt cannot be re-used as it doesn't push/pop,
>> factoring out the lattice update is what is needed here.
>>
>
> I dont think I understand this part. vrp_visit_stmt is going to add value
> ranges for the variables defined in the if-block (in the example below it is
> for t). If we push the value range for i_2 and j_3 when we enter if-block,
> vrp_visit_stmt should compute "t" correctly. When we leave the if-block, we
> will pop i_2 and j_3.
>
> i_2 = (int) j_3;
> if (i_2 < 0)
> {
>   t = j_2 * 2;
> }
> Am I missing something here?

It works if you push the old value before calling vrp_visit_stmt, yes.
But I think
you want to do that only if the value-range changed to avoid too many changes
on the stack.  I guess we can defer further refactoring and
optimization of this case
to the point where we consider looking back very aggressively.

>> +/* Visit the basic blocks in the dominance order and set the Value Ranges
>> (VR)
>> +   for SSA_NAMEs in the scope.  Use this VR to discover more VRs.
>> Restore the
>> +   old VR once the scope is exited.  */
>> +
>> +static bool
>> +evrp_visit_phi_node_local (gphi *phi)
>> +{
>> +  size_t i;
>> +  tree lhs = PHI_RESULT (phi);
>> +  value_range vr_result = VR_INITIALIZER;
>> +  bool first = true;
>> +  int edges;
>> +
>> +  edges = 0;
>> +  for (i = 0; i < gimple_phi_num_args (phi); i++)
>> +{
>> +  edge e = gimple_phi_arg_edge (phi, i);
>> +  tree arg = PHI_ARG_DEF (phi, i);
>> +  value_range vr_arg = VR_INITIALIZER;
>> +  ++edges;
>> +
>> +  /* If there is a back-edge, set the result to VARYING.  */
>> +  if (e->flags & (EDGE_DFS_BACK | EDGE_COMPLEX))
>> +   {
>> + set_value_range_to_varying (&vr_result);
>> + break;
>> +   }
>> ...
>> +  /* If any of the RHS value is VARYING, set the result to VARYING.
>> */
>> +  if ((vr_arg.type != VR_RANGE)
>> + && (vr_arg.type != VR_ANTI_RANGE))
>> +   {
>> + set_value_range_to_varying (&vr_result);
>> + break;
>> +   }
>>
>> this shows that you need to start conservative for a DOM based VRP,
>> thus with all lattice values initialized to VARYING (but undefined SSA
>> names of course still can be UNDEFINED) rather than UNDEFINED.
>>
>> +  if (TREE_CODE (arg) == SSA_NAME)
>> +   vr_arg = *(get_value_range (arg));
>> +  else
>> +   set_value_range_to_varying (&vr_arg);
>>
>> err - what about constants?  When you initialize the lattice properly
>> you should be able to re-use vrp_visit_phi_node (maybe split out
>> its head to avoid using SCEV or the iteration limitation).
>
>
> I also like re-using vrp_visit_phi_node but the issue is, we will have to
> keep a work-list of nodes to be re-evaluated till the lattice reach a
> fixpoint. Is that OK with you?

No, why would you need to iterate here?  As said, the key point is to
initialize value-ranges as VARYING rather than UNDEFINED.

> If we are to do this, we should be able to reuse the callbacks
> vrp_visit_phi_node and vrp_visit_stmt as it is.
>
> Do you have a reference to your DOM based prototype?

I never posted it I think, it's structure is similar to yours with lots
of ??? comments ;)

Richard.

> Thanks,
> Kugan
>
>
>> Btw, you don't want to call vrp_initialize in evrp either, this is setting
>> SSA propagator state which you do not want to do.  Please factor
>> out lattice allocation/deallocation instead.  I see that might require
>> really factoring vrp_visit_stmt into a function that omits updating
>> the lattice and just returns a range for the single DEF.
>>
>> That said, a good refactoring is to split the SSA propagator callback
>> implementations (vrp_visit_stmt and vrp_visit_phi_node) into workers
>> returning a value range and the callback that does the update_value_range
>> call plus returing a SSA propgator state.  You can then re-use the worker.
>>
>> T

RE: [PATCH][COMMITTED] Revert r238497 because of PR 71961.

[VandeVondele Joost]

Thanks.. I wonder if you could add the testcase in

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71961#c11

to the testsuite, as it catches the underlying issue.

Regards,

Joost VandeVondele

[PATCH][COMMITTED] Revert r238497 because of PR 71961.

[Renlin Li]

Hi all,

This patch reverts the change for PR 71902 since it causes 178.gagel 
miscompile in spec2000 as reported in PR 71961 which was observed in 
x86_64, aarch64, powerpc64.

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

As a consequence, I will reopen PR 71902: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71902


Regards,
Renlin Li


gcc/fortran/ChangeLog:
c
2016-07-28  Renlin Li  

Revert
2016-07-19  Thomas Koenig  

PR fortran/71902
* dependency.c (gfc_check_dependency): Use dep_ref.  Handle case
if identical is true and two array element references differ.
(gfc_dep_resovler):  Move most of the code to dep_ref.
(dep_ref):  New function.
* frontend-passes.c (realloc_string_callback):  Name temporary
variable "realloc_string".

gcc/testsuite/ChangeLog:

2016-07-28  Renlin Li  

Revert
2016-07-19  Thomas Koenig  

PR fortran/71902
* gfortran.dg/dependency_47.f90:  New test.
diff --git a/gcc/fortran/dependency.c b/gcc/fortran/dependency.c
index a873dbe..f117de0 100644
--- a/gcc/fortran/dependency.c
+++ b/gcc/fortran/dependency.c
@@ -54,8 +54,6 @@ enum gfc_dependency
 static gfc_dependency check_section_vs_section (gfc_array_ref *,
 		gfc_array_ref *, int);
 
-static gfc_dependency dep_ref (gfc_ref *, gfc_ref *, gfc_reverse *);
-
 /* Returns 1 if the expr is an integer constant value 1, 0 if it is not or
def if the value could not be determined.  */
 
@@ -1318,33 +1316,13 @@ gfc_check_dependency (gfc_expr *expr1, gfc_expr *expr2, bool identical)
 	  return 0;
 	}
 
+  if (identical)
+	return 1;
+
   /* Identical and disjoint ranges return 0,
 	 overlapping ranges return 1.  */
   if (expr1->ref && expr2->ref)
-	{
-	  gfc_dependency dep;
-	  dep = dep_ref (expr1->ref, expr2->ref, NULL);
-	  switch (dep)
-	{
-	case GFC_DEP_EQUAL:
-	  return identical;
-
-	case GFC_DEP_FORWARD:
-	  return 0;
-
-	case GFC_DEP_BACKWARD:
-	  return 1;
-
-	case GFC_DEP_OVERLAP:
-	  return 1;
-
-	case GFC_DEP_NODEP:
-	  return 0;
-
-	default:
-	  gcc_unreachable();
-	}
-	}
+	return gfc_dep_resolver (expr1->ref, expr2->ref, NULL);
 
   return 1;
 
@@ -2074,39 +2052,11 @@ ref_same_as_full_array (gfc_ref *full_ref, gfc_ref *ref)
	2 : array references are overlapping but reversal of one or
 	more dimensions will clear the dependency.
	1 : array references are overlapping.
-   	0 : array references are identical or can be handled in a forward loop.  */
+   	0 : array references are identical or not overlapping.  */
 
 int
 gfc_dep_resolver (gfc_ref *lref, gfc_ref *rref, gfc_reverse *reverse)
 {
-  enum gfc_dependency dep;
-  dep = dep_ref (lref, rref, reverse);
-  switch (dep)
-{
-case GFC_DEP_EQUAL:
-  return 0;
-
-case GFC_DEP_FORWARD:
-  return 0;
-
-case GFC_DEP_BACKWARD:
-  return 2;
-
-case GFC_DEP_OVERLAP:
-  return 1;
-
-case GFC_DEP_NODEP:
-  return 0;
-
-default:
-  gcc_unreachable();
-}
-}
-
-
-static gfc_dependency
-dep_ref (gfc_ref *lref, gfc_ref *rref, gfc_reverse *reverse)
-{
   int n;
   int m;
   gfc_dependency fin_dep;
@@ -2129,22 +2079,21 @@ dep_ref (gfc_ref *lref, gfc_ref *rref, gfc_reverse *reverse)
 	  /* The two ranges can't overlap if they are from different
 	 components.  */
 	  if (lref->u.c.component != rref->u.c.component)
-	return GFC_DEP_NODEP;
+	return 0;
 	  break;
 
 	case REF_SUBSTRING:
 	  /* Substring overlaps are handled by the string assignment code
 	 if there is not an underlying dependency.  */
-
-	  return fin_dep == GFC_DEP_ERROR ? GFC_DEP_NODEP : fin_dep;
+	  return (fin_dep == GFC_DEP_OVERLAP) ? 1 : 0;
 
 	case REF_ARRAY:
 
 	  if (ref_same_as_full_array (lref, rref))
-	return GFC_DEP_EQUAL;
+	return 0;
 
 	  if (ref_same_as_full_array (rref, lref))
-	return GFC_DEP_EQUAL;
+	return 0;
 
 	  if (lref->u.ar.dimen != rref->u.ar.dimen)
 	{
@@ -2155,7 +2104,7 @@ dep_ref (gfc_ref *lref, gfc_ref *rref, gfc_reverse *reverse)
 		fin_dep = gfc_full_array_ref_p (lref, NULL) ? GFC_DEP_EQUAL
 			: GFC_DEP_OVERLAP;
 	  else
-		return GFC_DEP_OVERLAP;
+		return 1;
 	  break;
 	}
 
@@ -2199,7 +2148,7 @@ dep_ref (gfc_ref *lref, gfc_ref *rref, gfc_reverse *reverse)
 
 	  /* If any dimension doesn't overlap, we have no dependency.  */
 	  if (this_dep == GFC_DEP_NODEP)
-		return GFC_DEP_NODEP;
+		return 0;
 
 	  /* Now deal with the loop reversal logic:  This only works on
 		 ranges and is activated by setting
@@ -2266,7 +2215,7 @@ dep_ref (gfc_ref *lref, gfc_ref *rref, gfc_reverse *reverse)
 	  /* Exactly matching and forward overlapping ranges don't cause a
 	 dependency.  */
 	  if (fin_dep < GFC_DEP_BACKWARD)
-	return fin_dep == GFC_DEP_ERROR ? GFC_DEP_NODEP : fin_dep;
+	return 0;
 
 	  /* Keep checking.  We only have a dependency if
 	 subsequent references also ov

Re: libgo patch committed: Update to 1.7rc3

[Uros Bizjak]

> I have committed a patch to update libgo to the 1.7rc3 release
> candidate.  This is very close to the upcoming 1.7 release.  As usual
> with libgo updates, the patch is too large to include in this e-mail
> message.  I've appended the changes to the gccgo-specific directories.

A new testsuite failure is introduced:

FAIL: text/template

on both, x86_64-linux-gnu and alpha-linux-gnu.

The testcase corrupts stack with a too deep recursion.

There is a part in libgo/go/text/template/exec.go that should handle
this situaiton:

// maxExecDepth specifies the maximum stack depth of templates within
// templates. This limit is only practically reached by accidentally
// recursive template invocations. This limit allows us to return
// an error instead of triggering a stack overflow.
const maxExecDepth = 10

but the limit is either set too high, or the error handling code is
inefficient on both, split-stack (x86_64) and non-split-stack (alpha)
targets. Lowering this value to 1 "fixes" the testcase on both
targets.

Uros.

Re: [PR70920] transform (intptr_t) x eq/ne CST to x eq/ne (typeof x) cst

[Andreas Schwab]

On Mo, Jul 25 2016, Prathamesh Kulkarni  wrote:

> diff --git a/gcc/testsuite/gcc.dg/pr70920-4.c 
> b/gcc/testsuite/gcc.dg/pr70920-4.c
> new file mode 100644
> index 000..dedb895
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr70920-4.c
> @@ -0,0 +1,21 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-ccp-details -Wno-int-to-pointer-cast" } */
> +
> +#include 
> +
> +void f1();
> +void f2();
> +
> +void
> +foo (int a)
> +{
> +  void *cst = 0; 
> +  if ((int *) a == cst)
> +{
> +  f1 ();
> +  if (a) 
> + f2 (); 
> +}
> +}
> +
> +/* { dg-final { scan-tree-dump "gimple_simplified to if \\(_\[0-9\]* == 
> 0\\)" "ccp1" } } */

This fails on all ilp32 platforms.

Andreas.

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

Re: [PATCH v3] S/390: Add splitter for "and" with complement.

[Dominik Vogt]

Version 4 of the patch.  Activated the patterns als for -mesa, as
discussed internally.  Bootstrapped and regression testes on s390
and s390x biarch.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany
gcc/ChangeLog

* config/s390/s390.md ("*andc_split", "*andc_split2"): New splitters
for and with complement.
gcc/testsuite/ChangeLog

* gcc.target/s390/md/andc-splitter-1.c: New test case.
* gcc.target/s390/md/andc-splitter-2.c: Likewise.
>From c45f7038546dd1a701a17072cb5ff65c6b9f0476 Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Mon, 14 Mar 2016 17:48:17 +0100
Subject: [PATCH] S/390: Add splitter for "and" with complement.

Force splitting of logical operator expressions ...  with three operands, a
register destination and a memory operand because there are no instructions for
that and combine results in inefficient code.
---
 gcc/config/s390/s390.md| 43 +++
 gcc/testsuite/gcc.target/s390/md/andc-splitter-1.c | 61 ++
 gcc/testsuite/gcc.target/s390/md/andc-splitter-2.c | 61 ++
 3 files changed, 165 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/s390/md/andc-splitter-1.c
 create mode 100644 gcc/testsuite/gcc.target/s390/md/andc-splitter-2.c

diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index f8c61a8..66bb922 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -7262,6 +7262,49 @@
(set_attr "z10prop" "z10_super_E1,z10_super,*")])
 
 ;
+; And with complement
+;
+; c = ~b & a = (b & a) ^ a
+
+(define_insn_and_split "*andc_split_"
+  [(set (match_operand:GPR 0 "nonimmediate_operand" "")
+   (and:GPR (not:GPR (match_operand:GPR 1 "nonimmediate_operand" ""))
+(match_operand:GPR 2 "general_operand" "")))
+   (clobber (reg:CC CC_REGNUM))]
+  "! reload_completed && s390_logical_operator_ok_p (operands)"
+  "#"
+  "&& 1"
+  [
+  (parallel
+   [(set (match_dup 3) (and:GPR (match_dup 1) (match_dup 2)))
+   (clobber (reg:CC CC_REGNUM))])
+  (parallel
+   [(set (match_dup 0) (xor:GPR (match_dup 3) (match_dup 2)))
+   (clobber (reg:CC CC_REGNUM))])]
+{
+  if (reg_overlap_mentioned_p (operands[0], operands[2]))
+operands[3] = gen_reg_rtx (mode);
+  else
+operands[3] = operands[0];
+})
+
+; Convert "(xor (operand) (-1))" to "(not (operand))" for low optimization
+; levels so that "*andc_split" matches.
+(define_insn_and_split "*andc_split2_"
+  [(set (match_operand:GPR 0 "nonimmediate_operand" "")
+(and:GPR (xor:GPR (match_operand:GPR 1 "nonimmediate_operand" "")
+ (const_int -1))
+(match_operand:GPR 2 "general_operand" "")))
+(clobber (reg:CC CC_REGNUM))]
+  "s390_logical_operator_ok_p (operands)"
+  "#"
+  "&& 1"
+  [(parallel
+[(set (match_dup 0) (and:GPR (not:GPR (match_dup 1)) (match_dup 2)))
+(clobber (reg:CC CC_REGNUM))])]
+)
+
+;
 ; Block and (NC) patterns.
 ;
 
diff --git a/gcc/testsuite/gcc.target/s390/md/andc-splitter-1.c 
b/gcc/testsuite/gcc.target/s390/md/andc-splitter-1.c
new file mode 100644
index 000..ed78921
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/md/andc-splitter-1.c
@@ -0,0 +1,61 @@
+/* Machine description pattern tests.  */
+
+/* { dg-do run { target { lp64 } } } */
+/* { dg-options "-mzarch -save-temps -dP" } */
+/* Skip test if -O0 is present on the command line:
+
+{ dg-skip-if "" { *-*-* } { "-O0" } { "" } }
+
+   Skip test if the -O option is missing from the command line
+{ dg-skip-if "" { *-*-* } { "*" } { "-O*" } }
+*/
+
+__attribute__ ((noinline))
+unsigned long andc_vv(unsigned long a, unsigned long b)
+{ return ~b & a; }
+/* { dg-final { scan-assembler ":15 .\* \{\\*anddi3\}" } } */
+/* { dg-final { scan-assembler ":15 .\* \{\\*xordi3\}" } } */
+
+__attribute__ ((noinline))
+unsigned long andc_pv(unsigned long *a, unsigned long b)
+{ return ~b & *a; }
+/* { dg-final { scan-assembler ":21 .\* \{\\*anddi3\}" } } */
+/* { dg-final { scan-assembler ":21 .\* \{\\*xordi3\}" } } */
+
+__attribute__ ((noinline))
+unsigned long andc_vp(unsigned long a, unsigned long *b)
+{ return ~*b & a; }
+/* { dg-final { scan-assembler ":27 .\* \{\\*anddi3\}" } } */
+/* { dg-final { scan-assembler ":27 .\* \{\\*xordi3\}" } } */
+
+__attribute__ ((noinline))
+unsigned long andc_pp(unsigned long *a, unsigned long *b)
+{ return ~*b & *a; }
+/* { dg-final { scan-assembler ":33 .\* \{\\*anddi3\}" } } */
+/* { dg-final { scan-assembler ":33 .\* \{\\*xordi3\}" } } */
+
+/* { dg-final { scan-assembler-times "\tngr\?k\?\t" 4 } } */
+/* { dg-final { scan-assembler-times "\txgr\?\t" 4 } } */
+
+int
+main (void)
+{
+  unsigned long a = 0xc00cllu;
+  unsigned long b = 0x500allu;
+  unsigned long e = 0x8004llu;
+  unsigned long c;
+
+  c = andc_vv (a, b);
+  if (c != e)
+__builtin_abort ();
+  c = andc_pv (&a, b);
+  if (c != e)
+__builtin_abort ();
+  c = andc_vp (a, &b);
+  if (c != e)
+__builtin_abort ();

Re: C PATCH for c/71853 (ICE with uninitialized memory on invalid)

[Marek Polacek]

On Wed, Jul 27, 2016 at 11:50:56PM +0200, Marek Polacek wrote:
> This testcase was breaking because we were using uninitialized memory
> coming from c_expr in c_parser_switch_statement.  There, in case we hadn't
> seen '(' after switch, we called c_finish_case with uninitialized CE.
> Fixed thus.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2016-07-27  Marek Polacek  
> 
>   PR c/71853
>   * c-parser.c (c_parser_switch_statement): Initialize ce.original_type
>   to error node for invalid code.
> 
>   * gcc.dg/noncompile/pr71853.c: New test.
> 
> diff --git gcc/c/c-parser.c gcc/c/c-parser.c
> index 8952bca..3679654 100644
> --- gcc/c/c-parser.c
> +++ gcc/c/c-parser.c
> @@ -5661,6 +5661,7 @@ c_parser_switch_statement (c_parser *parser, bool *if_p)
>  {
>switch_cond_loc = UNKNOWN_LOCATION;
>expr = error_mark_node;
> +  ce.original_type = error_mark_node;
>  }
>c_start_case (switch_loc, switch_cond_loc, expr, explicit_cast_p);
>save_break = c_break_label;
> diff --git gcc/testsuite/gcc.dg/noncompile/pr71853.c 
> gcc/testsuite/gcc.dg/noncompile/pr71853.c
> index e69de29..e049c8e 100644
> --- gcc/testsuite/gcc.dg/noncompile/pr71853.c
> +++ gcc/testsuite/gcc.dg/noncompile/pr71853.c
> @@ -0,0 +1,9 @@
> +/* PR c/71426 */

Bad PR number.  Fixed in my local copy.

Marek

Re: [PATCH, 2 of 4], Enhance PowerPC vec_extract support for power8/power9 machines

[Segher Boessenkool]

On Wed, Jul 27, 2016 at 05:16:28PM -0400, Michael Meissner wrote:
>   * config/rs6000/vsx.md (UNSPEC_VSX_VSLO): New unspecs.
>   (UNSPEC_VSX_EXTRACT): Likewise.

"New unspec".

>   (VEC_EXTRACT_OPTIMIZE_P): New macro to say whether we can optmize
>   vec_extract on 64-bit ISA 2.07 systems and newer.

"optimize".

> --- gcc/config/rs6000/rs6000-protos.h (revision 238775)
> +++ gcc/config/rs6000/rs6000-protos.h (working copy)
> @@ -62,6 +62,7 @@ extern void rs6000_expand_vector_init (r
>  extern void paired_expand_vector_init (rtx, rtx);
>  extern void rs6000_expand_vector_set (rtx, rtx, int);
>  extern void rs6000_expand_vector_extract (rtx, rtx, rtx);
> +extern void rs6000_split_vec_extract_var (rtx, rtx, rtx, rtx, rtx);
>  extern bool altivec_expand_vec_perm_const (rtx op[4]);
>  extern void altivec_expand_vec_perm_le (rtx op[4]);
>  extern bool rs6000_expand_vec_perm_const (rtx op[4]);

This isn't in the changelog.

> +  /* For little endian, adjust element ordering.  For V2DI/V2DF, we can 
> use
> +  an XOR, otherwise we need to subtract.  The shift amount is so VSLO
> +  will shift the element into the upper position (adding 3 to convert a
> +  byte shift into a bit shift). */

Two spaces after dot.

> +;; Variable V2DI/V2DF extract
> +(define_insn_and_split "vsx_extract__var"
> +  [(set (match_operand: 0 "gpc_reg_operand" "=v")
> + (unspec: [(match_operand:VSX_D 1 "input_operand" "v")
> +  (match_operand:DI 2 "gpc_reg_operand" "r")]
> + UNSPEC_VSX_EXTRACT))
> +   (clobber (match_scratch:DI 3 "=r"))
> +   (clobber (match_scratch:V2DI 4 "=&v"))]
> +  "VECTOR_MEM_VSX_P (mode) && VEC_EXTRACT_OPTIMIZE_P"
> +  "#"
> +  "&& reload_completed"
> +  [(const_int 0)]
> +{
> +  rs6000_split_vec_extract_var (operands[0], operands[1], operands[2],
> + operands[3], operands[4]);
> +  DONE;
> +})

Why reload_completed?  Can it not run earlier?

> +/* Macro to say whether we can optimize vector extracts.  */
> +#define VEC_EXTRACT_OPTIMIZE_P   (TARGET_DIRECT_MOVE 
> \
> +  && TARGET_POWERPC64\
> +  && TARGET_UPPER_REGS_DI)

I'm not a big fan of this name.  "Optimize" will quickly become dated,
everyone will take the current new hot thing for granted, and then when
you want to optimise even more (say, for ISA 6.0 or whatever) the name
is really out of place.

But I don't know a much better name either.

> --- gcc/testsuite/gcc.target/powerpc/vec-extract-1.c  (revision 0)
> +++ gcc/testsuite/gcc.target/powerpc/vec-extract-1.c  (revision 0)
> @@ -0,0 +1,27 @@
> +/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */

Maybe you can add a "run" test as well?

Looks good otherwise, okay for trunk with those nits fixed.

Thanks,


Segher

Re: [PATCH] OpenACC routines in fortran modules

[Tobias Burnus]

Cesar Philippidis wrote:
> It turns out that the acc routine parallelism isn't being recorded in
> fortran .mod files. This is a problem because then the ME can't validate
> if a routine has compatible parallelism with the call site. 

Nothing against saving such information in .mod files. However, I wonder
whether it can happen that one places such an 'acc routine' outside of a
module in one file - and still accesses it from another file. In the simple
non-ACC case, one can have:

!- one.f90 
subroutine foo()
  print *, "abc"
end subroutine foo

! two.f90 ---
program example
  call foo()
end program example

where "foo()" is torn in without any information about it (except that it
is a subroutine, does not require an explicit interface, and takes no
arguments).

I don't know whether the ACC spec requires an explicit interface in that
case (i.e. for acc routines); I bet it does - or at least should. In that
case, something like the following would be valid - and should be supported
as well. (I don't know whether it currently is.)

!- one.f90 
subroutine foo()
  !$acc routine gang
   ! something
end subroutine foo

! two.f90 ---
program example
  INTERFACE
subroutine foo()
  !$acc routine gang
  ! Nothing here
end subroutine foo
  END INTERFACE

  call foo()
end program example

Namely, a replication of the declaration of the procedure, including
the "acc routine", in the 'interface'.
(If one concats the two files, I would also expect an error with -fopenacc,
if the "acc routine" doesn't match between "foo" and the "foo" in the
"interface" block.)


Otherwise: Have you checked whether an unmodified gfortran still accepts the
.mod file written by the patched gfortran - and vice versa? Especially if
-fopenacc is not used, backward compatibility of .mod files is a goal.
(Even though we often have to bump the .mod version for major releases.)

Cheers,

Tobias

Re: libgo patch committed: Update to 1.7rc3

[Uros Bizjak]

Hello!

> I have committed a patch to update libgo to the 1.7rc3 release
> candidate.  This is very close to the upcoming 1.7 release.  As usual
> with libgo updates, the patch is too large to include in this e-mail
> message.  I've appended the changes to the gccgo-specific directories.

There is an issue with

libgo/go/crypto/sha1/issue15617_test.go.

The test crypto/sha1 fails on alpha-linux-gnu with:

--- FAIL: TestOutOfBoundsRead (0.00s)
panic: invalid argument [recovered]
panic: invalid argument
...

since the test hard-codes 4k pages, but alpha uses 8k pages.

It looks that the second line of build directives in the test:

// +build amd64
// +build linux darwin

overwrites the first one, so the test runs also on non-amd64
architecture linux OS. I have confirmed this by removing the second
build directive, and crypto/sha1 test then passed, since
issue15617_test.go was not linked into the final executable.

Another possible solution is to avoid hard-coding 4k pages in the
test. The mentioned test will pass on alpha when

const pageSize = 4 << 10

is changed to

const pageSize = 8 << 10

Uros.

Re: [PATCH] Introduce no_profile_instrument_function attribute (PR gcov-profile/68025)

[Martin Liška]

On 07/27/2016 11:33 PM, Jeff Law wrote:
> On 07/27/2016 02:27 AM, Martin Liška wrote:
>> Hi.
>>
>> As mentioned in the PR gcov-profile/68025, there's a request not to 
>> instrument
>> some functions (e.g. a in linux kernel). Thus, I come with a new attribute 
>> no_profile_instrument_function
>> which skips any profiling instrumentation.
>>
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> Conceptually fine.  I think you need an update to extensions.texi to document 
> the new attribute.  With that missing bit added, this will be fine for the 
> trunk.
> 
> jeff

Thanks for the review, attaching final version of the patch I've just installed.

Martin
>From aa758454a83da441e5679eaa5f37a00126eb3298 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 26 Jul 2016 15:03:29 +0200
Subject: [PATCH] Introduce no_profile_instrument_function attribute

gcc/ChangeLog:

2016-07-26  Martin Liska  

	PR gcov-profile/68025
	* tree-profile.c (tree_profiling): Respect
	no_profile_instrument_function attribute.
	* doc/extend.texi: Document no_profile_instrument_function
	attribute.

gcc/c-family/ChangeLog:

2016-07-26  Martin Liska  

	PR gcov-profile/68025
	* c-common.c (handle_no_profile_instrument_function_attribute):

gcc/testsuite/ChangeLog:

2016-07-26  Martin Liska  

	PR gcov-profile/68025
	* gcc.dg/no_profile_instrument_function-attr-1.c: New test.
---
 gcc/c-family/c-common.c| 21 
 gcc/doc/extend.texi|  6 ++
 .../gcc.dg/no_profile_instrument_function-attr-1.c | 23 ++
 gcc/tree-profile.c |  3 +++
 4 files changed, 53 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/no_profile_instrument_function-attr-1.c

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 1c5974a..35b5e5d 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -353,6 +353,8 @@ static tree handle_tls_model_attribute (tree *, tree, tree, int,
 	bool *);
 static tree handle_no_instrument_function_attribute (tree *, tree,
 		 tree, int, bool *);
+static tree handle_no_profile_instrument_function_attribute (tree *, tree,
+			 tree, int, bool *);
 static tree handle_malloc_attribute (tree *, tree, tree, int, bool *);
 static tree handle_returns_twice_attribute (tree *, tree, tree, int, bool *);
 static tree handle_no_limit_stack_attribute (tree *, tree, tree, int,
@@ -717,6 +719,9 @@ const struct attribute_spec c_common_attribute_table[] =
   { "no_instrument_function", 0, 0, true,  false, false,
 			  handle_no_instrument_function_attribute,
 			  false },
+  { "no_profile_instrument_function",  0, 0, true, false, false,
+			  handle_no_profile_instrument_function_attribute,
+			  false },
   { "malloc", 0, 0, true,  false, false,
 			  handle_malloc_attribute, false },
   { "returns_twice",  0, 0, true,  false, false,
@@ -8293,6 +8298,22 @@ handle_no_instrument_function_attribute (tree *node, tree name,
   return NULL_TREE;
 }
 
+/* Handle a "no_profile_instrument_function" attribute; arguments as in
+   struct attribute_spec.handler.  */
+
+static tree
+handle_no_profile_instrument_function_attribute (tree *node, tree name, tree,
+		 int, bool *no_add_attrs)
+{
+  if (TREE_CODE (*node) != FUNCTION_DECL)
+{
+  warning (OPT_Wattributes, "%qE attribute ignored", name);
+  *no_add_attrs = true;
+}
+
+  return NULL_TREE;
+}
+
 /* Handle a "malloc" attribute; arguments as in
struct attribute_spec.handler.  */
 
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index ad8898c..70636c1 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2853,6 +2853,12 @@ If @option{-finstrument-functions} is given, profiling function calls are
 generated at entry and exit of most user-compiled functions.
 Functions with this attribute are not so instrumented.
 
+@item no_profile_instrument_function
+@cindex @code{no_profile_instrument_function} function attribute
+The @code{no_profile_instrument_function} attribute on functions is used
+to inform the compiler that it should not process any profile feedback based
+optimization code instrumentation.
+
 @item no_reorder
 @cindex @code{no_reorder} function attribute
 Do not reorder functions or variables marked @code{no_reorder}
diff --git a/gcc/testsuite/gcc.dg/no_profile_instrument_function-attr-1.c b/gcc/testsuite/gcc.dg/no_profile_instrument_function-attr-1.c
new file mode 100644
index 000..c93d171
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/no_profile_instrument_function-attr-1.c
@@ -0,0 +1,23 @@
+/* { dg-options "-O2 -fprofile-generate -fdump-tree-optimized" } */
+
+__attribute__ ((no_profile_instrument_function))
+int foo()
+{
+  return 0;
+}
+
+__attribute__ ((no_profile_instrument_function))
+int bar()
+{
+  return 1;
+}
+
+int main ()
+{
+  return foo ();
+}
+
+/* { dg-final { scan-tree-dump-times "__gcov0\\.main.* = P

Re: PR fortran/71859 -- Patch

[Andre Vehreschild]

Hi Karl,

see below for comment:

On Wed, 27 Jul 2016 17:19:42 -0700
Steve Kargl  wrote:

> Patch is self-explanatory.  OK?
> 
> 2016-07-26  Steven G. Kargl  
> 
>   PR fortran/71859
>   * check.c(numeric_check): Prevent ICE.  Issue error for
> invalid subroutine as an actual argument when numeric argument is
> expected.
> 
> 2016-07-26  Steven G. Kargl  
> 
>   PR fortran/71859
>   * gfortran.dg/pr71859.f90: New test.
>   * gfortran.dg/intrinsic_numeric_arg.f: Update error message.
>   * gfortran.dg/coarray_collectives_1.f90: Ditto.
> 
> Index: gcc/fortran/check.c
> ===
> --- gcc/fortran/check.c   (revision 238665)
> +++ gcc/fortran/check.c   (working copy)
> @@ -72,6 +72,11 @@ type_check (gfc_expr *e, int n, bt type)
>  static bool
>  numeric_check (gfc_expr *e, int n)
>  {
> +  /* Users sometime use a subroutine designator as an actual
> argument to
> + an intrinsic subprogram that expects an argument with a numeric
> type.  */
> +  if (e->symtree && e->symtree->n.sym->attr.subroutine)
> +goto bandaid;
> +
>if (gfc_numeric_ts (&e->ts))
>  return true;
>  
> @@ -86,7 +91,9 @@ numeric_check (gfc_expr *e, int n)
>return true;
>  }
>  
> -  gfc_error ("%qs argument of %qs intrinsic at %L must be a numeric
> type",
> +bandaid:

Why bandaid? I would prefer error as label here, like it is done in
several places in the code. Being a non-English-native I had to look up
band-aid first to figure what it means. So that id is not intuitive to
me.

Besides that is the patch ok with me. Thanks.

- Andre


> +
> +  gfc_error ("%qs argument of %qs intrinsic at %L must have a
> numeric type", gfc_current_intrinsic_arg[n]->name,
> gfc_current_intrinsic, &e->where);
>  
> Index: gcc/testsuite/gfortran.dg/pr71859.f90
> ===
> --- gcc/testsuite/gfortran.dg/pr71859.f90 (nonexistent)
> +++ gcc/testsuite/gfortran.dg/pr71859.f90 (working copy)
> @@ -0,0 +1,8 @@
> +! { dg-do compile }
> +program p
> +   call s(1)
> +   x = abs(s)  ! { dg-error "must have a numeric type" }
> +end
> +subroutine s(n)
> +   print *, n
> +end
> Index: gcc/testsuite/gfortran.dg/intrinsic_numeric_arg.f
> ===
> --- gcc/testsuite/gfortran.dg/intrinsic_numeric_arg.f
> (revision 238665) +++
> gcc/testsuite/gfortran.dg/intrinsic_numeric_arg.f (working
> copy) @@ -4,6 +4,6 @@ LOGICAL Z
> CHARACTER A
> REAL R
> -   R = ABS(Z) !  { dg-error " must be a numeric type" }
> -   R = ABS(A) !  { dg-error " must be a numeric type" }
> +   R = ABS(Z) !  { dg-error " must have a numeric type" }
> +   R = ABS(A) !  { dg-error " must have a numeric type" }
> END
> Index: gcc/testsuite/gfortran.dg/coarray_collectives_1.f90
> ===
> --- gcc/testsuite/gfortran.dg/coarray_collectives_1.f90
> (revision 238665) +++
> gcc/testsuite/gfortran.dg/coarray_collectives_1.f90   (working
> copy) @@ -14,7 +14,7 @@ program test integer(8) :: i8
>character(len=19, kind=4) :: msg4
>  
> -  call co_sum("abc") ! { dg-error "must be a numeric type" }
> +  call co_sum("abc") ! { dg-error "must have a numeric type" }
>call co_max(cmplx(1.0,0.0)) ! { dg-error "shall be of type
> integer, real or character" } call co_min(cmplx(0.0,1.0)) !
> { dg-error "shall be of type integer, real or character" } 
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: [RFC][IPA-VRP] Early VRP Implementation

[kugan]

Hi Richard,

Thanks for the review.


It seems that in your pop_value_range you assume you only pop one
range per BB - while that's likely true at the moment it will be a limitation
in the future.  You want to pop ranges until you hit the NULL marker
in after_dom_children and unconditionally push a NULL marker.

I understand. Right now, I am adding only one assert based on the 
condition. But in future, we will be adding more so this is needed. I 
will do that.



For example to match current VRPs behavior on say

   i_2 = (int) j_3;
   if (i_2 < 0)
 ...

which can register an assert for j_3 when i_2 < 0 is true we'd do that
by re-simulating DEFs of uses we figured out new ranges of (and all
their uses).  All those ranges would be temporary as well, thus they'd
need to be pushed/popped.  In my quick prototype this was done
using a worklist seeded by the names we can derive a range from from
conditionals and "SSA propagating" from it.  Note that for this
the generic vrp_visit_stmt cannot be re-used as it doesn't push/pop,
factoring out the lattice update is what is needed here.



I dont think I understand this part. vrp_visit_stmt is going to add 
value ranges for the variables defined in the if-block (in the example 
below it is for t). If we push the value range for i_2 and j_3 when we 
enter if-block, vrp_visit_stmt should compute "t" correctly. When we 
leave the if-block, we will pop i_2 and j_3.


i_2 = (int) j_3;
if (i_2 < 0)
{
  t = j_2 * 2;  
}
Am I missing something here?


+/* Visit the basic blocks in the dominance order and set the Value Ranges (VR)
+   for SSA_NAMEs in the scope.  Use this VR to discover more VRs.  Restore the
+   old VR once the scope is exited.  */
+
+static bool
+evrp_visit_phi_node_local (gphi *phi)
+{
+  size_t i;
+  tree lhs = PHI_RESULT (phi);
+  value_range vr_result = VR_INITIALIZER;
+  bool first = true;
+  int edges;
+
+  edges = 0;
+  for (i = 0; i < gimple_phi_num_args (phi); i++)
+{
+  edge e = gimple_phi_arg_edge (phi, i);
+  tree arg = PHI_ARG_DEF (phi, i);
+  value_range vr_arg = VR_INITIALIZER;
+  ++edges;
+
+  /* If there is a back-edge, set the result to VARYING.  */
+  if (e->flags & (EDGE_DFS_BACK | EDGE_COMPLEX))
+   {
+ set_value_range_to_varying (&vr_result);
+ break;
+   }
...
+  /* If any of the RHS value is VARYING, set the result to VARYING.  */
+  if ((vr_arg.type != VR_RANGE)
+ && (vr_arg.type != VR_ANTI_RANGE))
+   {
+ set_value_range_to_varying (&vr_result);
+ break;
+   }

this shows that you need to start conservative for a DOM based VRP,
thus with all lattice values initialized to VARYING (but undefined SSA
names of course still can be UNDEFINED) rather than UNDEFINED.

+  if (TREE_CODE (arg) == SSA_NAME)
+   vr_arg = *(get_value_range (arg));
+  else
+   set_value_range_to_varying (&vr_arg);

err - what about constants?  When you initialize the lattice properly
you should be able to re-use vrp_visit_phi_node (maybe split out
its head to avoid using SCEV or the iteration limitation).


I also like re-using vrp_visit_phi_node but the issue is, we will have 
to keep a work-list of nodes to be re-evaluated till the lattice reach a 
fixpoint. Is that OK with you?


If we are to do this, we should be able to reuse the callbacks 
vrp_visit_phi_node and vrp_visit_stmt as it is.


Do you have a reference to your DOM based prototype?

Thanks,
Kugan


Btw, you don't want to call vrp_initialize in evrp either, this is setting
SSA propagator state which you do not want to do.  Please factor
out lattice allocation/deallocation instead.  I see that might require
really factoring vrp_visit_stmt into a function that omits updating
the lattice and just returns a range for the single DEF.

That said, a good refactoring is to split the SSA propagator callback
implementations (vrp_visit_stmt and vrp_visit_phi_node) into workers
returning a value range and the callback that does the update_value_range
call plus returing a SSA propgator state.  You can then re-use the worker.

Thanks,
Richard.


I  have tested the last set of patch separately.

I will do more testing on this patch based on your feedback. Does this look
better?

Thanks,
Kugan

[Patch, tentative, reload] Make push_reload work with more types of subregs?

[Senthil Kumar Selvaraj]

Hi,

  When analyzing PR 71873 (ICE in push_reload), I found that that code
  in push_reload that recursively calls push_reload for subreg
  expressions doesn't correctly set subreg_in_class for a few cases.

  Specifically, reload_inner_reg_of_subreg returns true if SUBREG_REG(x)
  is CONSTANT_P or if it's code is PLUS. The code that tries to find a
  valid class (before recursively calling push_reload), however, only
  does that if SUBREG_REG is REG_P or if it's a SYMBOL_REF. For the
  other cases, subreg_in_class is set to the default NO_REGS, and this
  triggers the rclass != NO_REGS assert just before find_reusable_reload.

  For PR 71873, reload sees

  (set (reg/f:HI 87)
(const:HI (plus:HI (symbol_ref:HI ("a")  )  
(const_int 1 [0x1] ../test.c:24 83 {*movhi}
 (expr_list:REG_EQUIV (const:HI (plus:HI (symbol_ref:HI ("a")  ) 
(const_int 1 [0x1])))
  and

  (set (mem:QI (post_dec:HI (reg/f:HI 32 __SP_L__)) [0  S1 A8]) 
(subreg:QI (reg/f:HI 87) 1))

  and decides to replace pseudo reg 87 in the latter insn with the
  REG_EQUIV it found in the former. The resulting RTL expression
   
  (subreg:QI (const:HI (plus:HI (symbol_ref:HI ("a") )
(const_int 1 [0x1]))) 1)

   does not match any of the conditions that handle subregs because
   subreg_low_part is false and the inner expr is not a REG or a SYMBOL_REF.

  Is there a reason why only REG and SYMBOL_REFs get valid
  subreg_in_class? I tried extending it handle constants and PLUS
  expressions, and it fixes PR 71873. It also fixes a another
  bug that was a work around for the reload failure (PR 64452) - that
  had a plus expression instead of the const.

  Reg testing on avr and x86_64 did not show any new failures. Is this
  the right way to fix this?

Regards
Senthil

diff --git gcc/reload.c gcc/reload.c
index 06426d9..f80d849 100644
--- gcc/reload.c
+++ gcc/reload.c
@@ -1141,7 +1141,9 @@ push_reload (rtx in, rtx out, rtx *inloc, rtx *outloc,
   SUBREG_BYTE (in),
   GET_MODE (in)),
  REGNO (SUBREG_REG (in)));
-  else if (GET_CODE (SUBREG_REG (in)) == SYMBOL_REF)
+  else if (GET_CODE (SUBREG_REG (in)) == SYMBOL_REF
+   || CONSTANT_P (SUBREG_REG (in))
+   || GET_CODE (SUBREG_REG (in)) == PLUS)
subreg_in_class = find_valid_class_1 (inmode,
  GET_MODE (SUBREG_REG (in)),
  rclass);

[PATCH RFC] do not throw in std::make_exception_ptr

[Gleb Natapov]

[resent with hopefully correct libstdc++ mailing list address this time]

Here is my attempt to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68297. The resulting patch
is a little bit long because I had to split  and cxxabi.h
include files. The former had to be split due to circular dependency
that formed after including  in exception_ptr.h and the later
is because of inability to include cxxabi.h in exception_ptr.h because
it makes libstdc++/30586 to reappear again.

Comments are welcome.

diff --git a/libcilkrts/runtime/except-gcc.h b/libcilkrts/runtime/except-gcc.h
index 3ef4061..113fade 100644
--- a/libcilkrts/runtime/except-gcc.h
+++ b/libcilkrts/runtime/except-gcc.h
@@ -65,7 +65,7 @@
 #endif
 
 #include 
-#include 
+#include 
 #include 
 
 struct __cxa_exception;
diff --git a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver 
b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
index 8304dee..65866a3 100644
--- a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
+++ b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
@@ -179,6 +179,7 @@ CXXABI_2.0 {
 __cxa_free_exception;
 __cxa_free_dependent_exception;
 __cxa_get_exception_ptr;
+__cxa_init_primary_exception;
 __cxa_get_globals;
 __cxa_get_globals_fast;
 __cxa_guard_abort;
@@ -205,6 +206,7 @@ CXXABI_2.0 {
 # std::exception_ptr
 _ZNSt15__exception_ptr13exception_ptrC1Ev;
 _ZNSt15__exception_ptr13exception_ptrC2Ev;
+_ZNSt15__exception_ptr13exception_ptrC1EPv;
 _ZNSt15__exception_ptr13exception_ptrC1ERKS0_;
 _ZNSt15__exception_ptr13exception_ptrC2ERKS0_;
 _ZNSt15__exception_ptr13exception_ptrC1EMS0_FvvE;
diff --git a/libstdc++-v3/config/abi/pre/gnu.ver 
b/libstdc++-v3/config/abi/pre/gnu.ver
index 5c6b0fe..2425dca 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2152,6 +2152,13 @@ CXXABI_1.3.10 {
 
 } CXXABI_1.3.9;
 
+CXXABI_1.3.11 {
+
+__cxa_init_primary_exception;
+_ZNSt15__exception_ptr13exception_ptrC1EPv;
+
+} CXXABI_1.3.10;
+
 # Symbols in the support library (libsupc++) supporting transactional memory.
 CXXABI_TM_1 {
 
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 4bc3354..8eee88b 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -201,8 +201,10 @@ bits_sup_srcdir = ${glibcxx_srcdir}/libsupc++
 bits_sup_headers = \
${bits_sup_srcdir}/atomic_lockfree_defines.h \
${bits_sup_srcdir}/cxxabi_forced.h \
+   ${bits_sup_srcdir}/cxxabiv1.h \
${bits_sup_srcdir}/exception_defines.h \
${bits_sup_srcdir}/exception_ptr.h \
+   ${bits_sup_srcdir}/exception.h \
${bits_sup_srcdir}/hash_bytes.h \
${bits_sup_srcdir}/nested_exception.h
 
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index 1f255a9..18e6073 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -491,8 +491,10 @@ bits_sup_srcdir = ${glibcxx_srcdir}/libsupc++
 bits_sup_headers = \
${bits_sup_srcdir}/atomic_lockfree_defines.h \
${bits_sup_srcdir}/cxxabi_forced.h \
+   ${bits_sup_srcdir}/cxxabiv1.h \
${bits_sup_srcdir}/exception_defines.h \
${bits_sup_srcdir}/exception_ptr.h \
+   ${bits_sup_srcdir}/exception.h \
${bits_sup_srcdir}/hash_bytes.h \
${bits_sup_srcdir}/nested_exception.h
 
diff --git a/libstdc++-v3/libsupc++/Makefile.am 
b/libstdc++-v3/libsupc++/Makefile.am
index b45b5ae..644e51e 100644
--- a/libstdc++-v3/libsupc++/Makefile.am
+++ b/libstdc++-v3/libsupc++/Makefile.am
@@ -34,8 +34,8 @@ std_HEADERS = \
cxxabi.h exception initializer_list new typeinfo
 
 bits_HEADERS = \
-   atomic_lockfree_defines.h cxxabi_forced.h \
-   exception_defines.h exception_ptr.h hash_bytes.h nested_exception.h
+   atomic_lockfree_defines.h cxxabi_forced.h cxxabiv1.h\
+   exception_defines.h exception_ptr.h exception.h hash_bytes.h 
nested_exception.h
 
 headers = $(std_HEADERS) $(bits_HEADERS)
 
diff --git a/libstdc++-v3/libsupc++/Makefile.in 
b/libstdc++-v3/libsupc++/Makefile.in
index f3648ac..bbb837a 100644
--- a/libstdc++-v3/libsupc++/Makefile.in
+++ b/libstdc++-v3/libsupc++/Makefile.in
@@ -394,8 +394,8 @@ std_HEADERS = \
cxxabi.h exception initializer_list new typeinfo
 
 bits_HEADERS = \
-   atomic_lockfree_defines.h cxxabi_forced.h \
-   exception_defines.h exception_ptr.h hash_bytes.h nested_exception.h
+   atomic_lockfree_defines.h cxxabi_forced.h cxxabiv1.h \
+   exception_defines.h exception_ptr.h exception.h hash_bytes.h 
nested_exception.h
 
 headers = $(std_HEADERS) $(bits_HEADERS)
 @GLIBCXX_HOSTED_TRUE@c_sources = \
diff --git a/libstdc++-v3/libsupc++/cxxabi.h b/libstdc++-v3/libsupc++/cxxabi.h
index 11ff9e5..a33cc90 100644
--- a/libstdc++-v3/libsupc++/cxxabi.h
+++ b/libstdc++-v3/libsupc++/cxxabi.h
@@ -45,622 +45,11 @@
 
 #pragma GCC visibility push(default)
 
-#include

[PATCH RFC] do not throw in std::make_exception_ptr

[Gleb Natapov]

Here is my attempt to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68297. The resulting patch
is a little bit long because I had to split  and cxxabi.h
include files. The former had to be split due to circular dependency
that formed after including  in exception_ptr.h and the later
is because of inability to include cxxabi.h in exception_ptr.h because
it makes libstdc++/30586 to reappear again.

Comments are welcome.

diff --git a/libcilkrts/runtime/except-gcc.h b/libcilkrts/runtime/except-gcc.h
index 3ef4061..113fade 100644
--- a/libcilkrts/runtime/except-gcc.h
+++ b/libcilkrts/runtime/except-gcc.h
@@ -65,7 +65,7 @@
 #endif
 
 #include 
-#include 
+#include 
 #include 
 
 struct __cxa_exception;
diff --git a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver 
b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
index 8304dee..65866a3 100644
--- a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
+++ b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
@@ -179,6 +179,7 @@ CXXABI_2.0 {
 __cxa_free_exception;
 __cxa_free_dependent_exception;
 __cxa_get_exception_ptr;
+__cxa_init_primary_exception;
 __cxa_get_globals;
 __cxa_get_globals_fast;
 __cxa_guard_abort;
@@ -205,6 +206,7 @@ CXXABI_2.0 {
 # std::exception_ptr
 _ZNSt15__exception_ptr13exception_ptrC1Ev;
 _ZNSt15__exception_ptr13exception_ptrC2Ev;
+_ZNSt15__exception_ptr13exception_ptrC1EPv;
 _ZNSt15__exception_ptr13exception_ptrC1ERKS0_;
 _ZNSt15__exception_ptr13exception_ptrC2ERKS0_;
 _ZNSt15__exception_ptr13exception_ptrC1EMS0_FvvE;
diff --git a/libstdc++-v3/config/abi/pre/gnu.ver 
b/libstdc++-v3/config/abi/pre/gnu.ver
index 5c6b0fe..2425dca 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2152,6 +2152,13 @@ CXXABI_1.3.10 {
 
 } CXXABI_1.3.9;
 
+CXXABI_1.3.11 {
+
+__cxa_init_primary_exception;
+_ZNSt15__exception_ptr13exception_ptrC1EPv;
+
+} CXXABI_1.3.10;
+
 # Symbols in the support library (libsupc++) supporting transactional memory.
 CXXABI_TM_1 {
 
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 4bc3354..8eee88b 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -201,8 +201,10 @@ bits_sup_srcdir = ${glibcxx_srcdir}/libsupc++
 bits_sup_headers = \
${bits_sup_srcdir}/atomic_lockfree_defines.h \
${bits_sup_srcdir}/cxxabi_forced.h \
+   ${bits_sup_srcdir}/cxxabiv1.h \
${bits_sup_srcdir}/exception_defines.h \
${bits_sup_srcdir}/exception_ptr.h \
+   ${bits_sup_srcdir}/exception.h \
${bits_sup_srcdir}/hash_bytes.h \
${bits_sup_srcdir}/nested_exception.h
 
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index 1f255a9..18e6073 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -491,8 +491,10 @@ bits_sup_srcdir = ${glibcxx_srcdir}/libsupc++
 bits_sup_headers = \
${bits_sup_srcdir}/atomic_lockfree_defines.h \
${bits_sup_srcdir}/cxxabi_forced.h \
+   ${bits_sup_srcdir}/cxxabiv1.h \
${bits_sup_srcdir}/exception_defines.h \
${bits_sup_srcdir}/exception_ptr.h \
+   ${bits_sup_srcdir}/exception.h \
${bits_sup_srcdir}/hash_bytes.h \
${bits_sup_srcdir}/nested_exception.h
 
diff --git a/libstdc++-v3/libsupc++/Makefile.am 
b/libstdc++-v3/libsupc++/Makefile.am
index b45b5ae..644e51e 100644
--- a/libstdc++-v3/libsupc++/Makefile.am
+++ b/libstdc++-v3/libsupc++/Makefile.am
@@ -34,8 +34,8 @@ std_HEADERS = \
cxxabi.h exception initializer_list new typeinfo
 
 bits_HEADERS = \
-   atomic_lockfree_defines.h cxxabi_forced.h \
-   exception_defines.h exception_ptr.h hash_bytes.h nested_exception.h
+   atomic_lockfree_defines.h cxxabi_forced.h cxxabiv1.h\
+   exception_defines.h exception_ptr.h exception.h hash_bytes.h 
nested_exception.h
 
 headers = $(std_HEADERS) $(bits_HEADERS)
 
diff --git a/libstdc++-v3/libsupc++/Makefile.in 
b/libstdc++-v3/libsupc++/Makefile.in
index f3648ac..bbb837a 100644
--- a/libstdc++-v3/libsupc++/Makefile.in
+++ b/libstdc++-v3/libsupc++/Makefile.in
@@ -394,8 +394,8 @@ std_HEADERS = \
cxxabi.h exception initializer_list new typeinfo
 
 bits_HEADERS = \
-   atomic_lockfree_defines.h cxxabi_forced.h \
-   exception_defines.h exception_ptr.h hash_bytes.h nested_exception.h
+   atomic_lockfree_defines.h cxxabi_forced.h cxxabiv1.h \
+   exception_defines.h exception_ptr.h exception.h hash_bytes.h 
nested_exception.h
 
 headers = $(std_HEADERS) $(bits_HEADERS)
 @GLIBCXX_HOSTED_TRUE@c_sources = \
diff --git a/libstdc++-v3/libsupc++/cxxabi.h b/libstdc++-v3/libsupc++/cxxabi.h
index 11ff9e5..a33cc90 100644
--- a/libstdc++-v3/libsupc++/cxxabi.h
+++ b/libstdc++-v3/libsupc++/cxxabi.h
@@ -45,622 +45,11 @@
 
 #pragma GCC visibility push(default)
 
-#include 
-#include 
-#include 
 #include 
-
-#ifndef _GLIBCXX_CDTOR_CALLABI
-#def