Re: [PATCH] Clear BB_VISITED in bb-reorder

[Andrew Pinski]

On Mon, Oct 17, 2016 at 5:26 AM, Richard Biener  wrote:
>
> $subject, applied as obvious.

I think you should do the same for the vectorizer too.  I noticed that
when testing the patch for loop splitting.

Thanks,
Andrew

>
> Richard.
>
> 2016-10-17  Richard Biener  
>
> * bb-reorder.c (reorder_basic_blocks_simple): Clear BB_VISITED
> before using it.
>
> Index: gcc/bb-reorder.c
> ===
> --- gcc/bb-reorder.c(revision 241228)
> +++ gcc/bb-reorder.c(working copy)
> @@ -2355,7 +2355,10 @@ reorder_basic_blocks_simple (void)
>   To start with, everything points to itself, nothing is assigned yet.  */
>
>FOR_ALL_BB_FN (bb, cfun)
> -bb->aux = bb;
> +{
> +  bb->aux = bb;
> +  bb->flags &= ~BB_VISITED;
> +}
>
>EXIT_BLOCK_PTR_FOR_FN (cfun)->aux = 0;
>

[Bug tree-optimization/61247] vectorization fails for unsigned is used for IV but casted to int before using as the index (and then casted for internal type)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
Summary|vectorization fails if  |vectorization fails for
   |conversion from unsigned|unsigned is used for IV but
   |int to signed int is|casted to int before using
   |involved|as the index (and then
   ||casted for internal type)
   Severity|minor   |enhancement

--- Comment #2 from Andrew Pinski  ---
t999.cc:12:17: note: not vectorized: data ref analysis failed _4 = *_18;
t999.cc:12:17: note: bad data references.
Creating dr for *_18
analyze_innermost: failed: evolution of base is not affine.
base_address:
offset from base address:
constant offset from base address:
step:
aligned to:
base_object: *_18

Re: Use FOR_ALL_BB_FN in a few more places (was: [PATCH] Clear BB_VISITED in bb-reorder)

[Richard Biener]

On October 17, 2016 6:09:02 PM GMT+02:00, Thomas Schwinge 
 wrote:
>Hi!
>
>On Mon, 17 Oct 2016 15:17:13 +0200, Richard Biener
> wrote:
>> On Mon, Oct 17, 2016 at 3:12 PM, Thomas Schwinge
>>  wrote:
>> > On Mon, 17 Oct 2016 14:26:42 +0200 (CEST), Richard Biener
> wrote:
>> >> --- gcc/bb-reorder.c  (revision 241228)
>> >> +++ gcc/bb-reorder.c  (working copy)
>> >> @@ -2355,7 +2355,10 @@ reorder_basic_blocks_simple (void)
>> >>   To start with, everything points to itself, nothing is
>assigned yet.  */
>> >>
>> >>FOR_ALL_BB_FN (bb, cfun)
>> >> -bb->aux = bb;
>> >> +{
>> >> +  bb->aux = bb;
>> >> +  bb->flags &= ~BB_VISITED;
>> >> +}
>> >>
>> >>EXIT_BLOCK_PTR_FOR_FN (cfun)->aux = 0;
>> >
>> > "EXIT_BLOCK_PTR_FOR_FN (cfun)->flags &= ~BB_VISITED;" is not
>required
>> > here, additionally?
>> 
>> ALL_BB includes EXIT_BLOCK.
>
>I see -- ;-) FOR_ALL_BB_FN is something different from
>FOR_EACH_BB_FN...
>
>
>We could use the former in a few more places; OK for trunk once tested?

OK.

Richard.

>commit 183433526b2befb7bd75e74f753b8a5d4bec14b0
>Author: Thomas Schwinge 
>Date:   Mon Oct 17 18:07:16 2016 +0200
>
>Use FOR_ALL_BB_FN in a few more places
>
>   gcc/
>   * cfg.c (clear_bb_flags): Use FOR_ALL_BB_FN.
>   * config/nvptx/nvptx.c (nvptx_find_sese): Likewise.
>---
> gcc/cfg.c| 2 +-
> gcc/config/nvptx/nvptx.c | 8 +---
> 2 files changed, 2 insertions(+), 8 deletions(-)
>
>diff --git gcc/cfg.c gcc/cfg.c
>index ee2e42c..6604b02 100644
>--- gcc/cfg.c
>+++ gcc/cfg.c
>@@ -386,7 +386,7 @@ clear_bb_flags (void)
> {
>   basic_block bb;
> 
>-  FOR_BB_BETWEEN (bb, ENTRY_BLOCK_PTR_FOR_FN (cfun), NULL, next_bb)
>+  FOR_ALL_BB_FN (bb, cfun)
> bb->flags &= BB_FLAGS_TO_PRESERVE;
> }
>
>diff --git gcc/config/nvptx/nvptx.c gcc/config/nvptx/nvptx.c
>index 6ec8eb4..80fa9ae 100644
>--- gcc/config/nvptx/nvptx.c
>+++ gcc/config/nvptx/nvptx.c
>@@ -3091,17 +3091,11 @@ nvptx_find_sese (auto_vec ,
>bb_pair_vec_t )
>   int ix;
> 
>   /* First clear each BB of the whole function.  */ 
>-  FOR_EACH_BB_FN (block, cfun)
>+  FOR_ALL_BB_FN (block, cfun)
> {
>   block->flags &= ~BB_VISITED;
>   BB_SET_SESE (block, 0);
> }
>-  block = EXIT_BLOCK_PTR_FOR_FN (cfun);
>-  block->flags &= ~BB_VISITED;
>-  BB_SET_SESE (block, 0);
>-  block = ENTRY_BLOCK_PTR_FOR_FN (cfun);
>-  block->flags &= ~BB_VISITED;
>-  BB_SET_SESE (block, 0);
> 
>   /* Mark blocks in the function that are in this graph.  */
>   for (ix = 0; blocks.iterate (ix, ); ix++)
>
>
>Grüße
> Thomas

Re: RFC [1/3] divmod transform v2

[Prathamesh Kulkarni]

On 18 October 2016 at 02:46, Jeff Law  wrote:
> On 10/15/2016 11:59 PM, Prathamesh Kulkarni wrote:
>>
>> This patch is mostly the same as previous one, except it drops
>> targeting __udivmoddi4() because it gave undefined reference link
>> error for calling __udivmoddi4() on aarch64-linux-gnu. It appears
>> aarch64 has hardware insn for DImode div, so __udivmoddi4() isn't
>> needed for the target (it was a bug in my patch that called
>> __udivmoddi4() even though aarch64 supported hardware div).
>
> This touches on the one high level question I had.  Namely what is the code
> generation strategy if the hardware has a div, but not divmod.
The divmod transform isn't enabled if target supports hardware div in the same
or wider mode even if divmod libfunc is available for the given mode.
>
> ISTM in that case I think we want to use the div instruction and synthesize
> mod from that result rather than relying on a software divmod.  So it looks
> like you ought to be doing the right thing for that case now based on your
> comment above.
>>
>>
>> However this makes me wonder if it's guaranteed that __udivmoddi4()
>> will be available for a target if it doesn't have hardware div and
>> divmod insn and doesn't have target-specific libfunc for DImode
>> divmod ? To be conservative, the attached patch doesn't generate call
>> to __udivmoddi4.
>
> I don't think that's a safe assumption.  Addition of the divmod routines
> into libgcc is controlled by the target and have to be explicitly added
> AFAICT.
>
> So on a target like the fr30 which has no div or mod insn and doesn't define
> the right bits in libgcc, there is no divmod libcall available. (On these
> targets there's a div libcall and a mod libcall, but not a combined one).
Thanks. I had erroneously  assumed __udivimoddi4() was available for all targets
because it was defined in libgcc2.c and generated call to it as "last
resort" for unsigned
DImode case if target didn't support hardware div and divmod insn and
didn't have
target-specific divmod libfunc for DImode.
The reason why it generated undefined reference on aarch64-linux-gnu
was because I
didn't properly check in the patch if target supported hardware div,
and ended up generating call to
__udivmoddi4() even though aarch64 has hardware div. I rectified that
before posting the
patch.
>
> I don't even think we have a way of knowing in the compiler if the target
> has enabled divmod support in libgcc.
Well the arm and c6x backends register target-specific divmod libfunc via
set_optab_libfunc(). I suppose that's sufficient to know if target has
divmod enabled
in libgcc ?
>
> ISTM that for now we have to limit to cases where we have a divmod
> insn/libcall defined.
Indeed. The transform is enabled only if the target has hardware divmod insn
or divmod libfunc (in the libfunc case, no hardware div insn).
Please see divmod_candidate_p() in the patch for cases when the
transform gets enabled.

Thanks,
Prathamesh
>
> jeff
>

[Bug c++/78011] [DR325] Compiler error when initializing a member of template type where the second template argument is a typedef

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE
   Target Milestone|5.5 |---
Summary|Compiler error when |[DR325] Compiler error when
   |initializing a member of|initializing a member of
   |template type where the |template type where the
   |second template argument is |second template argument is
   |a typedef   |a typedef

--- Comment #5 from Andrew Pinski  ---
DR 325 also applies here.

Actually this is a dup of bug 52595 since that was fixed in GCC 6.  Anyways the
C++ standard is not fully clear here :).

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

[Bug c++/52595] [DR 325] commas and non-static data member initializers don't mix

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||b.stanimirov at abv dot bg

--- Comment #14 from Andrew Pinski  ---
*** Bug 78011 has been marked as a duplicate of this bug. ***

[Bug c++/78011] Compiler error when initializing a member of template type where the second template argument is a typedef

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
PR 52595

[Bug c++/78011] Compiler error when initializing a member of template type where the second template argument is a typedef

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
PR 57

[Bug c++/78011] Compiler error when initializing a member of template type where the second template argument is a typedef

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
There is most likely a dup about this bug.  (Oh and a C++ defect report; the
comma is confusing things).

[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)

[jvdelisle at gcc dot gnu.org]

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

--- Comment #28 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue Oct 18 04:14:25 2016
New Revision: 241294

URL: https://gcc.gnu.org/viewcvs?rev=241294=gcc=rev
Log:
2016-10-17  Jerry DeLisle  

PR fortran/48298
* io/io.h: Move size_used from dtp to unit structure. Add bool
has_size to unit structure.
* read.c (read_x): Use has_size and size_used.
* transfer.c (read_sf_internal,read_sf,read_block_form,
read_block_form4): Likewise.
(data_transfer_init): If parent, initialize the size variables.
(finalize_transfer): Set the size variable using size_used in
gfc_unit. (write_block): Delete bogus/dead code.

* gfortran.dg/dtio_17.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/dtio_17.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h
trunk/libgfortran/io/read.c
trunk/libgfortran/io/transfer.c

Re: [PATCH] Fix PR77916

[Markus Trippelsdorf]

On 2016.10.18 at 05:13 +0200, Markus Trippelsdorf wrote:
> On 2016.10.17 at 17:23 -0500, Bill Schmidt wrote:
> > Hi,
> > 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77916 identifies a situation
> > where SLSR will ICE when exposed to a cast from integer to pointer.  This
> > is because we try to convert a PLUS_EXPR with an addend of -1 * S into a
> > MINUS_EXPR with a subtrahend of S, but the base operand is unexpectedly
> > of pointer type.  This patch recognizes when pointer arithmetic is taking
> > place and ensures that we use a POINTER_PLUS_EXPR at all such times.  In
> > the case of the PR, this occurs in the logic where the stride S is a known
> > constant value, but the same problem could occur when it is an SSA_NAME
> > without known value.  Both possibilities are handled here.
> > 
> > Fixing the code to ensure that the unknown stride case always uses an 
> > initializer for a negative increment allows us to remove the stopgap fix
> > added for PR77937 as well.
> > 
> > Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> > regressions, committed.
> 
> Perhaps you should consider building ffmpeg with -O3 -march=amdfam10 on
> X86_64 before committing these patches, because you broke it for the
> third time in the last couple of days.
> 
> markus@x4 ffmpeg % cat h264dsp.i
> extern int fn2(int);
> extern int fn3(int);
> int a, b, c;
> void fn1(long p1) {
>   char *d;
>   for (;; d += p1) {
> d[0] = fn2(1 >> c >> 1);
> fn2(c >> a);
> d[1] = fn3(d[1]) >> 1;
> d[6] = fn3(d[6] * b + 1) >> 1;
> d[7] = fn3(d[7] * b + 1) >> 1;
> d[8] = fn3(d[8] * b + 1) >> 1;
>   }
> }
> 
> markus@x4 ffmpeg % gcc -O3 -march=amdfam10 -c h264dsp.i
> h264dsp.i: In function ‘fn1’:
> h264dsp.i:4:6: internal compiler error: in replace_one_candidate, at 
> gimple-ssa-strength-reduction.c:3375
>  void fn1(long p1) {
>   ^~~
> 0x12773a9 replace_one_candidate
> ../../gcc/gcc/gimple-ssa-strength-reduction.c:3375
> 0x127af77 replace_profitable_candidates
> ../../gcc/gcc/gimple-ssa-strength-reduction.c:3486
> 0x127aeeb replace_profitable_candidates
> ../../gcc/gcc/gimple-ssa-strength-reduction.c:3495
> 0x127f3ee analyze_candidates_and_replace
> ../../gcc/gcc/gimple-ssa-strength-reduction.c:3574
> 0x127f3ee execute
> ../../gcc/gcc/gimple-ssa-strength-reduction.c:3648

Just figured out that this testcase is identical to:
gcc/testsuite/gcc.dg/torture/pr77937-2.c 

So please run the testsuite on X86_64 in the future.

-- 
Markus

Re: [PATCH] Fix PR77916

[Markus Trippelsdorf]

On 2016.10.17 at 17:23 -0500, Bill Schmidt wrote:
> Hi,
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77916 identifies a situation
> where SLSR will ICE when exposed to a cast from integer to pointer.  This
> is because we try to convert a PLUS_EXPR with an addend of -1 * S into a
> MINUS_EXPR with a subtrahend of S, but the base operand is unexpectedly
> of pointer type.  This patch recognizes when pointer arithmetic is taking
> place and ensures that we use a POINTER_PLUS_EXPR at all such times.  In
> the case of the PR, this occurs in the logic where the stride S is a known
> constant value, but the same problem could occur when it is an SSA_NAME
> without known value.  Both possibilities are handled here.
> 
> Fixing the code to ensure that the unknown stride case always uses an 
> initializer for a negative increment allows us to remove the stopgap fix
> added for PR77937 as well.
> 
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> regressions, committed.

Perhaps you should consider building ffmpeg with -O3 -march=amdfam10 on
X86_64 before committing these patches, because you broke it for the
third time in the last couple of days.

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

markus@x4 ffmpeg % gcc -O3 -march=amdfam10 -c h264dsp.i
h264dsp.i: In function ‘fn1’:
h264dsp.i:4:6: internal compiler error: in replace_one_candidate, at 
gimple-ssa-strength-reduction.c:3375
 void fn1(long p1) {
  ^~~
0x12773a9 replace_one_candidate
../../gcc/gcc/gimple-ssa-strength-reduction.c:3375
0x127af77 replace_profitable_candidates
../../gcc/gcc/gimple-ssa-strength-reduction.c:3486
0x127aeeb replace_profitable_candidates
../../gcc/gcc/gimple-ssa-strength-reduction.c:3495
0x127f3ee analyze_candidates_and_replace
../../gcc/gcc/gimple-ssa-strength-reduction.c:3574
0x127f3ee execute
../../gcc/gcc/gimple-ssa-strength-reduction.c:3648




-- 
Markus

Re: [patch, gfortran] PR48298 DTIO, implement size=

[Steve Kargl]

On Mon, Oct 17, 2016 at 06:02:52PM -0700, Jerry DeLisle wrote:
> Hi all,
> 
> The attached patch enables the size= specifier in a READ statement to work 
> with 
> child DTIO procedures. This is accomplished by moving the size_used variable 
> from the dtp structure to the gfc_unit structure so that the accumulation of 
> bytes during READ is carried across the procedures via the UNIT.
> 
> As far as I know, this is the last DTIO patch needed for full implementation 
> and 
> will close the PR.
> 
> After this patch is committed I plan to prepare a clean up patch to 
> reorganize 
> the dtp structure and clear at least one TODO related to stream IO. The 
> follow-on patch will bump the major version number of libgfortran to 4.
> 
> Regression tested on x86-64-linux. New test case attached.
> 
> OK for trunk?

Lookd good to me.

>   * transfer.c (read_sf_internal): Likewise. (read_sf): Likewise.
>   (read_block_form): Likewise. (read_block_form4): Likewise.


You can simplify this by

* transfer.c (read_sf_internal, read_sf, read_block_form,
read_block_form4): Likewise.

-- 
Steve

[PATCH] xtensa: add -mpreferred-stack-boundary option

[Max Filippov]

2016-05-24  Max Filippov  
gcc/
* config/xtensa/xtensa.opt (mpreferred-stack-boundary=): New
option.
* config/xtensa/xtensa.h (STACK_BOUNDARY): Redefine as 64 for
windowed ABI/32 for call0 ABI.
(PREFERRED_STACK_BOUNDARY): New definition.
* config/xtensa/xtensa.c (xtensa_function_arg_1,
xtensa_function_arg_boundary, STACK_BYTES,
xtensa_gimplify_va_arg_expr): Use PREFERRED_STACK_BOUNDARY
instead of STACK_BOUNDARY.
* doc/invoke.texi: Document -mpreferred-stack-boundary.
---
 gcc/config/xtensa/xtensa.c   | 12 +++-
 gcc/config/xtensa/xtensa.h   | 16 +---
 gcc/config/xtensa/xtensa.opt |  4 
 gcc/doc/invoke.texi  | 16 
 4 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/gcc/config/xtensa/xtensa.c b/gcc/config/xtensa/xtensa.c
index 60e5029..332aa81 100644
--- a/gcc/config/xtensa/xtensa.c
+++ b/gcc/config/xtensa/xtensa.c
@@ -2117,7 +2117,8 @@ xtensa_function_arg_1 (cumulative_args_t cum_v, 
machine_mode mode,
 
   if (type && (TYPE_ALIGN (type) > BITS_PER_WORD))
 {
-  int align = MIN (TYPE_ALIGN (type), STACK_BOUNDARY) / BITS_PER_WORD;
+  int align = MIN (TYPE_ALIGN (type),
+  PREFERRED_STACK_BOUNDARY) / BITS_PER_WORD;
   *arg_words = (*arg_words + align - 1) & -align;
 }
 
@@ -2158,8 +2159,8 @@ xtensa_function_arg_boundary (machine_mode mode, 
const_tree type)
   alignment = type ? TYPE_ALIGN (type) : GET_MODE_ALIGNMENT (mode);
   if (alignment < PARM_BOUNDARY)
 alignment = PARM_BOUNDARY;
-  if (alignment > STACK_BOUNDARY)
-alignment = STACK_BOUNDARY;
+  if (alignment > PREFERRED_STACK_BOUNDARY)
+alignment = PREFERRED_STACK_BOUNDARY;
   return alignment;
 }
 
@@ -2624,7 +2625,7 @@ xtensa_call_save_reg(int regno)
 /* Return the bytes needed to compute the frame pointer from the current
stack pointer.  */
 
-#define STACK_BYTES (STACK_BOUNDARY / BITS_PER_UNIT)
+#define STACK_BYTES (PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT)
 #define XTENSA_STACK_ALIGN(LOC) (((LOC) + STACK_BYTES-1) & ~(STACK_BYTES-1))
 
 long
@@ -3184,7 +3185,8 @@ xtensa_gimplify_va_arg_expr (tree valist, tree type, 
gimple_seq *pre_p,
 
   if (TYPE_ALIGN (type) > BITS_PER_WORD)
 {
-  int align = MIN (TYPE_ALIGN (type), STACK_BOUNDARY) / BITS_PER_UNIT;
+  int align = MIN (TYPE_ALIGN (type),
+  PREFERRED_STACK_BOUNDARY) / BITS_PER_UNIT;
 
   t = build2 (PLUS_EXPR, integer_type_node, unshare_expr (orig_ndx),
  build_int_cst (integer_type_node, align - 1));
diff --git a/gcc/config/xtensa/xtensa.h b/gcc/config/xtensa/xtensa.h
index 82e9900..abcb799 100644
--- a/gcc/config/xtensa/xtensa.h
+++ b/gcc/config/xtensa/xtensa.h
@@ -504,9 +504,19 @@ enum reg_class
location above the first argument's address.  */
 #define FIRST_PARM_OFFSET(FNDECL) 0
 
-/* Align stack frames on 128 bits for Xtensa.  This is necessary for
-   128-bit datatypes defined in TIE (e.g., for Vectra).  */
-#define STACK_BOUNDARY 128
+/* Align stack frames on 32 bits for call0 ABI or on 64 bits for windowed
+   ABI on Xtensa.  These are the absolute minimums dictated by the hardware
+   (windowed is 64 bits because the entry instruction moves SP in multiples
+   of 8 bytes).  ABIs require alignment to be 128 bits to support datatypes
+   defined in TIE (e.g., for Vectra).  */
+#define STACK_BOUNDARY (TARGET_WINDOWED_ABI ? 64 : 32)
+
+/* Align stack frames on 128 bits in accordance with ABI.  This alignment
+   may be reduced when stack space conservation is preferred over ABI
+   compliance with -mpreferred-stack-boundary option.  */
+#define PREFERRED_STACK_BOUNDARY   \
+   MAX (STACK_BOUNDARY,\
+(BITS_PER_UNIT << xtensa_preferred_stack_boundary))
 
 /* Use a fixed register window size of 8.  */
 #define WINDOW_SIZE (TARGET_WINDOWED_ABI ? 8 : 0)
diff --git a/gcc/config/xtensa/xtensa.opt b/gcc/config/xtensa/xtensa.opt
index ea5c7d5..85e9622 100644
--- a/gcc/config/xtensa/xtensa.opt
+++ b/gcc/config/xtensa/xtensa.opt
@@ -45,3 +45,7 @@ Relax literals in assembler and place them automatically in 
the text section.
 mserialize-volatile
 Target Report Mask(SERIALIZE_VOLATILE)
 -mno-serialize-volatileDo not serialize volatile memory references 
with MEMW instructions.
+
+mpreferred-stack-boundary=
+Target RejectNegative Joined UInteger Var(xtensa_preferred_stack_boundary) 
Init(4)
+Attempt to keep stack aligned to this power of 2.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 0241cb5..2e885a8 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1202,6 +1202,7 @@ See RS/6000 and PowerPC Options.
 -mtext-section-literals  -mno-text-section-literals @gol
 -mauto-litpools  -mno-auto-litpools @gol
 -mtarget-align  -mno-target-align @gol
+-mpreferred-stack-boundary=@var{num} @gol
 -mlongcalls  

[patch, gfortran] PR48298 DTIO, implement size=

[Jerry DeLisle]

Hi all,

The attached patch enables the size= specifier in a READ statement to work with 
child DTIO procedures. This is accomplished by moving the size_used variable 
from the dtp structure to the gfc_unit structure so that the accumulation of 
bytes during READ is carried across the procedures via the UNIT.


As far as I know, this is the last DTIO patch needed for full implementation and 
will close the PR.


After this patch is committed I plan to prepare a clean up patch to reorganize 
the dtp structure and clear at least one TODO related to stream IO. The 
follow-on patch will bump the major version number of libgfortran to 4.


Regression tested on x86-64-linux. New test case attached.

OK for trunk?

Jerry

2016-10-17  Jerry DeLisle  

PR fortran/48298
* io/io.h: Move size_used from dtp to unit structure. Add bool
has_size to unit structure.
* read.c (read_x): Use has_size and size_used.
* transfer.c (read_sf_internal): Likewise. (read_sf): Likewise.
(read_block_form): Likewise. (read_block_form4): Likewise.
(data_transfer_init): If parent, initialize the size variables.
(finalize_transfer): Set the size variable using size_used in
gfc_unit. (write_block): Delete bogus/dead code.


diff --git a/libgfortran/ChangeLog b/libgfortran/ChangeLog
index bfda86df..f20c5106 100644
--- a/libgfortran/ChangeLog
+++ b/libgfortran/ChangeLog
@@ -1,3 +1,15 @@
+2016-10-17  Jerry DeLisle  
+
+	PR fortran/48298
+	* io/io.h: Move size_used from dtp to unit structure. Add bool
+	has_size to unit structure.
+	* read.c (read_x): Use has_size and size_used.
+	* transfer.c (read_sf_internal): Likewise. (read_sf): Likewise.
+	(read_block_form): Likewise. (read_block_form4): Likewise.
+	(data_transfer_init): If parent, initialize the size variables.
+	(finalize_transfer): Set the size variable using size_used in
+	gfc_unit. (write_block): Delete bogus/dead code.
+
 2016-10-16  Janne Blomqvist  
 
 	PR libfortran/48587
diff --git a/libgfortran/io/io.h b/libgfortran/io/io.h
index aaacc089..edc520a9 100644
--- a/libgfortran/io/io.h
+++ b/libgfortran/io/io.h
@@ -514,7 +514,6 @@ typedef struct st_parameter_dt
 	 large enough to hold a complex value (two reals) of the
 	 largest kind.  */
 	  char value[32];
-	  GFC_IO_INT size_used;
 	  formatted_dtio fdtio_ptr;
 	  unformatted_dtio ufdtio_ptr;
 	} p;
@@ -650,6 +649,8 @@ typedef struct gfc_unit
   /* DTIO Parent/Child procedure, 0 = parent, >0 = child level.  */
   int child_dtio;
   int last_char;
+  bool has_size;
+  GFC_IO_INT size_used;
 }
 gfc_unit;
 
diff --git a/libgfortran/io/read.c b/libgfortran/io/read.c
index f8d5b72e..d72cdb37 100644
--- a/libgfortran/io/read.c
+++ b/libgfortran/io/read.c
@@ -1282,8 +1282,9 @@ read_x (st_parameter_dt *dtp, int n)
 } 
 
  done:
-  if ((dtp->common.flags & IOPARM_DT_HAS_SIZE) != 0)
-dtp->u.p.size_used += (GFC_IO_INT) n;
+  if (((dtp->common.flags & IOPARM_DT_HAS_SIZE) != 0) ||
+  dtp->u.p.current_unit->has_size)
+dtp->u.p.current_unit->size_used += (GFC_IO_INT) n;
   dtp->u.p.current_unit->bytes_left -= n;
   dtp->u.p.current_unit->strm_pos += (gfc_offset) n;
 }
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 2232417a..e5805772 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -267,8 +267,9 @@ read_sf_internal (st_parameter_dt *dtp, int * length)
 
   dtp->u.p.current_unit->bytes_left -= *length;
 
-  if ((dtp->common.flags & IOPARM_DT_HAS_SIZE) != 0)
-dtp->u.p.size_used += (GFC_IO_INT) *length;
+  if (((dtp->common.flags & IOPARM_DT_HAS_SIZE) != 0) ||
+  dtp->u.p.current_unit->has_size)
+dtp->u.p.current_unit->size_used += (GFC_IO_INT) *length;
 
   return base;
 
@@ -397,8 +398,9 @@ read_sf (st_parameter_dt *dtp, int * length)
 
   dtp->u.p.current_unit->bytes_left -= n;
 
-  if ((dtp->common.flags & IOPARM_DT_HAS_SIZE) != 0)
-dtp->u.p.size_used += (GFC_IO_INT) n;
+  if (((dtp->common.flags & IOPARM_DT_HAS_SIZE) != 0) ||
+  dtp->u.p.current_unit->has_size)
+dtp->u.p.current_unit->size_used += (GFC_IO_INT) n;
 
   /* We can't call fbuf_getptr before the loop doing fbuf_getc, because
  fbuf_getc might reallocate the buffer.  So return current pointer
@@ -478,8 +480,9 @@ read_block_form (st_parameter_dt *dtp, int * nbytes)
   source = fbuf_read (dtp->u.p.current_unit, nbytes);
   fbuf_seek (dtp->u.p.current_unit, *nbytes, SEEK_CUR);
 
-  if ((dtp->common.flags & IOPARM_DT_HAS_SIZE) != 0)
-dtp->u.p.size_used += (GFC_IO_INT) *nbytes;
+  if (((dtp->common.flags & IOPARM_DT_HAS_SIZE) != 0) ||
+  dtp->u.p.current_unit->has_size)
+dtp->u.p.current_unit->size_used += (GFC_IO_INT) *nbytes;
 
   if (norig != *nbytes)
 {
@@ -536,8 +539,9 @@ read_block_form4 (st_parameter_dt *dtp, int * nbytes)
 
   dtp->u.p.current_unit->bytes_left -= *nbytes;
 
-  if ((dtp->common.flags & IOPARM_DT_HAS_SIZE) != 0)

[Bug fortran/77978] stop codes misinterpreted in both f2003 and f2008

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.5

--- Comment #7 from kargl at gcc dot gnu.org ---
Fixed on 5, 6, and 7.

[PATCH] xtensa: don't use unwind-dw2-fde-dip with elf targets

[Max Filippov]

Define LIB2ADDEH_XTENSA_UNWIND_DW2_FDE to unwind-dw2-fde.c in
xtensa/t-elf and to unwind-dw2-fde-dip.c in xtensa/t-linux and use
LIB2ADDEH_XTENSA_UNWIND_DW2_FDE in LIB2ADDEH definition.

2016-10-17  Max Filippov  
libgcc/
* config/xtensa/t-elf (LIB2ADDEH_XTENSA_UNWIND_DW2_FDE): New
definition.
* config/xtensa/t-linux (LIB2ADDEH_XTENSA_UNWIND_DW2_FDE): New
definition.
* config/xtensa/t-windowed (LIB2ADDEH): Use
LIB2ADDEH_XTENSA_UNWIND_DW2_FDE defined by either xtensa/t-elf
or xtensa/t-linux.

Signed-off-by: Max Filippov 
---
 libgcc/config/xtensa/t-elf  | 2 ++
 libgcc/config/xtensa/t-linux| 2 ++
 libgcc/config/xtensa/t-windowed | 2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/libgcc/config/xtensa/t-elf b/libgcc/config/xtensa/t-elf
index 59d5121..967cf9b 100644
--- a/libgcc/config/xtensa/t-elf
+++ b/libgcc/config/xtensa/t-elf
@@ -3,3 +3,5 @@ CRTSTUFF_T_CFLAGS += -mlongcalls
 CRTSTUFF_T_CFLAGS_S += -mlongcalls
 
 HOST_LIBGCC2_CFLAGS += -mlongcalls
+
+LIB2ADDEH_XTENSA_UNWIND_DW2_FDE = $(srcdir)/unwind-dw2-fde.c
diff --git a/libgcc/config/xtensa/t-linux b/libgcc/config/xtensa/t-linux
index 6f4ae89..412ecca 100644
--- a/libgcc/config/xtensa/t-linux
+++ b/libgcc/config/xtensa/t-linux
@@ -1 +1,3 @@
 SHLIB_MAPFILES += $(srcdir)/config/xtensa/libgcc-glibc.ver
+
+LIB2ADDEH_XTENSA_UNWIND_DW2_FDE = $(srcdir)/unwind-dw2-fde-dip.c
diff --git a/libgcc/config/xtensa/t-windowed b/libgcc/config/xtensa/t-windowed
index a99156c..f140136 100644
--- a/libgcc/config/xtensa/t-windowed
+++ b/libgcc/config/xtensa/t-windowed
@@ -1,2 +1,2 @@
 LIB2ADDEH = $(srcdir)/config/xtensa/unwind-dw2-xtensa.c \
-   $(srcdir)/unwind-dw2-fde-dip.c $(srcdir)/unwind-sjlj.c $(srcdir)/unwind-c.c
+   $(LIB2ADDEH_XTENSA_UNWIND_DW2_FDE) $(srcdir)/unwind-sjlj.c 
$(srcdir)/unwind-c.c
-- 
2.1.4

[Bug fortran/77978] stop codes misinterpreted in both f2003 and f2008

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Oct 17 23:22:54 2016
New Revision: 241286

URL: https://gcc.gnu.org/viewcvs?rev=241286=gcc=rev
Log:
2016-10-17  Steven G. Kargl  

Backport from trunk
PR fortran/77978
* match.c (gfc_match_stopcode): Fix error reporting for several
deficiencies in matching stop-codes.

2016-10-17  Steven G. Kargl  

PR fortran/77978
* gfortran.dg/pr77978_1.f90: New test.
* gfortran.dg/pr77978_2.f90: Ditto.
* gfortran.dg/pr77978_3.f90: Ditto.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr77978_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr77978_2.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr77978_3.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/match.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

Re: [PATCH] rs6000: Fix separate shrink-wrapping for TARGET_MULTIPLE

[Iain Sandoe]

Hi Segher,

> On 17 Oct 2016, at 09:13, Segher Boessenkool  
> wrote:
> 
> We cannot use {SAVE,REST}_MULTIPLE and separate shrink-wrapping together,
> not without checking when actually emitting the prologue/epilogue that the
> registers to save/restore are actually still one contiguous block up to
> (and including) 31.  So either:
> 
> 1) We delay the decision of whether to use lmw/stmw to later;
> 2) We disallow shrink-wrapping separate (integer) components when those
> strategies are selected; or
> 3) We don't use those strategies if we use separate shrink-wrapping.
> 
> This patch does 3).  In the long term it may be best to do 1) instead,
> it can be slightly more efficient.
> 
> This caused problems on darwin (it is the only config that uses lmw/stmw
> instructions by default).
> 
> Bootstrapped and tested on powerpc64-linux {-m64,-m32}.  I'll commit it
> if Iain's testing (on darwin) also succeeds.

thanks!

All-langs bootstrap was restored with the patch (and others in progress for 
existing known issues); 

I can’t see any evidence of the assert firing in the test-suite, so it all 
looks good to me (there’s quite a bit of stage-1-ish testsuite noise at 
present, however).

cheers
Iain
> 
> 
> 2016-10-17  Segher Boessenkool  
> 
>   * config/rs6000/rs6000.c: Add include of shrink-wrap.h .
>   (rs6000_savres_strategy): Do not select {SAVE,REST}_MULTIPLE if
>   shrink-wrapping separate components.
>   (rs6000_get_separate_components): Assert we do not have those
>   strategies selected.
> 
> ---
> gcc/config/rs6000/rs6000.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index df48980..83a7139 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -64,6 +64,7 @@
> #include "target-globals.h"
> #include "builtins.h"
> #include "context.h"
> +#include "shrink-wrap.h"
> #include "tree-pass.h"
> #if TARGET_XCOFF
> #include "xcoffout.h"  /* get declarations of xcoff_*_section_name */
> @@ -25506,7 +25507,10 @@ rs6000_savres_strategy (rs6000_stack_t *info,
>   if (TARGET_MULTIPLE
>   && !TARGET_POWERPC64
>   && !(TARGET_SPE_ABI && info->spe_64bit_regs_used)
> -  && info->first_gp_reg_save < 31)
> +  && info->first_gp_reg_save < 31
> +  && !(SHRINK_WRAPPING_ENABLED
> +&& flag_shrink_wrap_separate
> +&& optimize_function_for_speed_p (cfun)))
> {
>   /* Prefer store multiple for saves over out-of-line routines,
>since the store-multiple instruction will always be smaller.  */
> @@ -27440,6 +27444,9 @@ rs6000_get_separate_components (void)
>   sbitmap components = sbitmap_alloc (32);
>   bitmap_clear (components);
> 
> +  gcc_assert (!(info->savres_strategy & SAVE_MULTIPLE)
> +   && !(info->savres_strategy & REST_MULTIPLE));
> +
>   /* The GPRs we need saved to the frame.  */
>   if ((info->savres_strategy & SAVE_INLINE_GPRS)
>   && (info->savres_strategy & REST_INLINE_GPRS))
> -- 
> 1.9.3
> 

[SOLVED-ish] Question about sibling call epilogues & registers

[Daniel Santos]

So the core problem was my "restore multiple" insn contained a CALL insn 
and was a call_insn. The symbol it called is in the static section of 
libgcc. However, during peephole2 pass, get_call_reg_set_usage in 
final.c didn't find a function declaration attached to the symbol and so 
defaulted to say that it depends upon and clobbers most registers. (the 
target's default set)


My solution was to change the pattern so that I do not generate a CALL 
and emit the parallel using emit_insn instead of emit_call_insn. In this 
way, I still declare everything that calling stub ("__msabi_restore_15" 
in the below case) does and it doesn't presume that I depend upon or 
clobber any other regs, so that the sibling call emitted after this 
still works. Since I'm using RSI for the base address, I'm only changing 
registers that have to be saved anyway, so the sibcall should never need 
to use one of these registers anyway (I hope :)



(insn/f 148 147 149 11 (parallel [
(use (symbol_ref:DI ("__msabi_restore_15")))
(clobber (reg:CC 17 flags))
(set (reg:V4SF 52 xmm15)
(mem/c:V4SF (plus:DI (reg:DI 4 si)
(const_int -88 [0xffa8])) [0 S16 A8]))
(set (reg:V4SF 51 xmm14)
(mem/c:V4SF (plus:DI (reg:DI 4 si)
(const_int -72 [0xffb8])) [0 S16 A8]))
(set (reg:V4SF 50 xmm13)
(mem/c:V4SF (plus:DI (reg:DI 4 si)
(const_int -56 [0xffc8])) [0 S16 A8]))
(set (reg:V4SF 49 xmm12)
(mem/c:V4SF (plus:DI (reg:DI 4 si)
(const_int -40 [0xffd8])) [0 S16 A8]))
(set (reg:V4SF 48 xmm11)
(mem/c:V4SF (plus:DI (reg:DI 4 si)
(const_int -24 [0xffe8])) [0 S16 A8]))
(set (reg:V4SF 47 xmm10)
(mem/c:V4SF (plus:DI (reg:DI 4 si)
(const_int -8 [0xfff8])) [0  S16 A8]))
(set (reg:V4SF 46 xmm9)
(mem/c:V4SF (plus:DI (reg:DI 4 si)
(const_int 8 [0x8])) [0  S16 A8]))
(set (reg:V4SF 45 xmm8)
(mem/c:V4SF (plus:DI (reg:DI 4 si)
(const_int 24 [0x18])) [0  S16 A8]))
(set (reg:V4SF 28 xmm7)
(mem/c:V4SF (plus:DI (reg:DI 4 si)
(const_int 40 [0x28])) [0  S16 A8]))
(set (reg:V4SF 27 xmm6)
(mem/c:V4SF (plus:DI (reg:DI 4 si)
(const_int 56 [0x38])) [0  S16 A8]))
(set (reg:DI 5 di)
(mem/c:DI (plus:DI (reg:DI 4 si)
(const_int 72 [0x48])) [0  S8 A8]))
(set (reg:DI 3 bx)
(mem/c:DI (plus:DI (reg:DI 4 si)
(const_int 80 [0x50])) [0  S8 A8]))
(set (reg:DI 6 bp)
(mem/c:DI (plus:DI (reg:DI 4 si)
(const_int 88 [0x58])) [0  S8 A8]))
(set (reg:DI 41 r12)
(mem/c:DI (plus:DI (reg:DI 4 si)
(const_int 96 [0x60])) [0  S8 A8]))
(set (reg:DI 4 si)
(mem/c:DI (plus:DI (reg:DI 4 si)
(const_int 64 [0x40])) [0  S8 A8]))
]) 
/home/daniel/proj/emu/wine/github/dlls/winex11.drv/window.c:1655 -1

 (expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_CFA_RESTORE (reg:DI 4 si)
(expr_list:REG_CFA_RESTORE (reg:DI 41 r12)
(expr_list:REG_CFA_RESTORE (reg:DI 6 bp)
(expr_list:REG_CFA_RESTORE (reg:DI 3 bx)
(expr_list:REG_CFA_RESTORE (reg:DI 5 di)
(expr_list:REG_CFA_RESTORE (reg:V4SF 27 xmm6)
(expr_list:REG_CFA_RESTORE (reg:V4SF 28 
xmm7)
(expr_list:REG_CFA_RESTORE 
(reg:V4SF 45 xmm8)
(expr_list:REG_CFA_RESTORE 
(reg:V4SF 46 xmm9)

(nil

[PATCH] Remove leftover comment

[Bill Schmidt]

Whoops.  Discovered I had inadvertently left in a comment that made no
sense when fixing PR77916.  This patch removes it.  Committed as obvious.

Thanks,
Bill


2016-10-17  Bill Schmidt  

* gimple-ssa-strength-reduction.c (record_increment): Remove
garbage comment.


Index: gcc/gimple-ssa-strength-reduction.c
===
--- gcc/gimple-ssa-strength-reduction.c (revision 241281)
+++ gcc/gimple-ssa-strength-reduction.c (working copy)
@@ -2507,9 +2507,7 @@ record_increment (slsr_cand_t c, widest_int increm
 as providing an initializer (if it does); we will revise this
 opinion later if it doesn't dominate all other occurrences.
  Exception:  increments of 0, 1 never need initializers;
-and phi adjustments don't ever provide initializers.  Note
- that we only will see an increment of -1 here for pointer
-arithmetic (otherwise we will have an initializer).  */
+and phi adjustments don't ever provide initializers.  */
   if (c->kind == CAND_ADD
  && !is_phi_adjust
  && c->index == increment

Re: [patch v2] Get rid of stack trampolines for nested functions (0/4)

[Eric Botcazou]

> On ia64 I get this regression:
> 
> FAIL: gcc.dg/Wtrampolines.c  (test for warnings, line 31)
> 
> Since ia64 never uses trampolines this is probably ok and the test
> should be adjusted.

This actually revealed a problem: the same regression should have appeared on 
PowerPC64/Linux (ELFv1 ABI) but it didn't because I botched the hookization of 
TARGET_CUSTOM_FUNCTION_DESCRIPTORS, which started as a good old macro:

/* Use custom descriptors instead of trampolines if not AIX or ELFv1.  */
#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS (DEFAULT_ABI != ABI_AIX)

doesn't work as intended on PowerPC64 because DEFAULT_ABI is a variable...

Corrective patch attached, tested on x86/Linux, x86-64/Linux, PowerPC/Linux, 
PowerPC64/Linux, IA-64/Linux and SPARC/Solaris, applied as obvious.


* config/i386/i386.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): Move to...
* config/i386/i386.c (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): ...here.
* config/ia64/ia64.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): Move to...
* config/ia64/ia64.c (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): ...here.
* config/rs6000/rs6000.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): Move
to...
* config/rs6000/rs6000.c (TARGET_CUSTOM_FUNCTION_DESCRIPTORS):...here.
(rs6000_option_override_internal): Clear it if ABI_AIX.
* config/sparc/sparc.h (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): Move
to...
* config/sparc/sparc.c (TARGET_CUSTOM_FUNCTION_DESCRIPTORS): ...here.
testsuite/
* gcc.dg/Wtrampolines.c: XFAIL warning on ia64-*-* and powerpc64-*-*.
* gnat.dg/trampoline4.adb: Minor tweak.

-- 
Eric BotcazouIndex: config/i386/i386.c
===
--- config/i386/i386.c	(revision 241222)
+++ config/i386/i386.c	(working copy)
@@ -50833,6 +50833,9 @@ ix86_addr_space_zero_address_valid (addr
 #undef TARGET_HARD_REGNO_SCRATCH_OK
 #define TARGET_HARD_REGNO_SCRATCH_OK ix86_hard_regno_scratch_ok
 
+#undef TARGET_CUSTOM_FUNCTION_DESCRIPTORS
+#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 1
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 #include "gt-i386.h"
Index: config/i386/i386.h
===
--- config/i386/i386.h	(revision 241222)
+++ config/i386/i386.h	(working copy)
@@ -2666,9 +2666,6 @@ extern void debug_dispatch_window (int);
 
 #define TARGET_SUPPORTS_WIDE_INT 1
 
-/* Use custom descriptors instead of trampolines when possible.  */
-#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 1
-
 /*
 Local variables:
 version-control: t
Index: config/ia64/ia64.c
===
--- config/ia64/ia64.c	(revision 241222)
+++ config/ia64/ia64.c	(working copy)
@@ -649,6 +649,9 @@ static const struct attribute_spec ia64_
 #undef TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P
 #define TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P ia64_attribute_takes_identifier_p
 
+#undef TARGET_CUSTOM_FUNCTION_DESCRIPTORS
+#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 0
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 /* Returns TRUE iff the target attribute indicated by ATTR_ID takes a plain
Index: config/ia64/ia64.h
===
--- config/ia64/ia64.h	(revision 241222)
+++ config/ia64/ia64.h	(working copy)
@@ -1715,7 +1715,4 @@ struct GTY(()) machine_function
 /* Switch on code for querying unit reservations.  */
 #define CPU_UNITS_QUERY 1
 
-/* IA-64 already uses descriptors for its standard calling sequence.  */
-#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 0
-
 /* End of ia64.h */
Index: config/rs6000/rs6000.c
===
--- config/rs6000/rs6000.c	(revision 241222)
+++ config/rs6000/rs6000.c	(working copy)
@@ -1867,6 +1867,9 @@ static const struct attribute_spec rs600
 
 #undef TARGET_OPTAB_SUPPORTED_P
 #define TARGET_OPTAB_SUPPORTED_P rs6000_optab_supported_p
+
+#undef TARGET_CUSTOM_FUNCTION_DESCRIPTORS
+#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 1
 
 
 /* Processor table.  */
@@ -4862,6 +4865,10 @@ rs6000_option_override_internal (bool gl
 	 Linux and Darwin ABIs at the moment.  For now, only AIX is fixed.  */
   if (DEFAULT_ABI == ABI_V4 || DEFAULT_ABI == ABI_DARWIN)
 	targetm.calls.split_complex_arg = NULL;
+
+  /* The AIX and ELFv1 ABIs define standard function descriptors.  */
+  if (DEFAULT_ABI == ABI_AIX)
+	targetm.calls.custom_function_descriptors = 0;
 }
 
   /* Initialize rs6000_cost with the appropriate target costs.  */
Index: config/rs6000/rs6000.h
===
--- config/rs6000/rs6000.h	(revision 241222)
+++ config/rs6000/rs6000.h	(working copy)
@@ -2922,9 +2922,6 @@ extern GTY(()) tree rs6000_builtin_decls
 
 #define TARGET_SUPPORTS_WIDE_INT 1
 
-/* Use custom descriptors instead of trampolines if not AIX or ELFv1.  */
-#define TARGET_CUSTOM_FUNCTION_DESCRIPTORS (DEFAULT_ABI != 

[PATCH] Fix PR77916

[Bill Schmidt]

Hi,

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77916 identifies a situation
where SLSR will ICE when exposed to a cast from integer to pointer.  This
is because we try to convert a PLUS_EXPR with an addend of -1 * S into a
MINUS_EXPR with a subtrahend of S, but the base operand is unexpectedly
of pointer type.  This patch recognizes when pointer arithmetic is taking
place and ensures that we use a POINTER_PLUS_EXPR at all such times.  In
the case of the PR, this occurs in the logic where the stride S is a known
constant value, but the same problem could occur when it is an SSA_NAME
without known value.  Both possibilities are handled here.

Fixing the code to ensure that the unknown stride case always uses an 
initializer for a negative increment allows us to remove the stopgap fix
added for PR77937 as well.

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

Thanks,
Bill


[gcc]

2016-10-17  Bill Schmidt  

PR tree-optimization/77916
* gimple-ssa-strength-reduction.c (create_add_on_incoming_edge):
Don't allow a MINUS_EXPR for pointer arithmetic for either known
or unknown strides.
(record_increment): Increments of -1 for unknown strides just use
a multiply initializer like other negative values.
(analyze_increments): Remove stopgap solution for -1 increment
applied to pointer arithmetic.

[gcc/testsuite]

2016-10-17  Bill Schmidt  

PR tree-optimization/77916
* gcc.dg/torture/pr77916.c: New.


Index: gcc/gimple-ssa-strength-reduction.c
===
--- gcc/gimple-ssa-strength-reduction.c (revision 241245)
+++ gcc/gimple-ssa-strength-reduction.c (working copy)
@@ -2154,35 +2154,41 @@ create_add_on_incoming_edge (slsr_cand_t c, tree b
   basis_type = TREE_TYPE (basis_name);
   lhs = make_temp_ssa_name (basis_type, NULL, "slsr");
 
+  /* Occasionally people convert integers to pointers without a 
+ cast, leading us into trouble if we aren't careful.  */
+  enum tree_code plus_code
+= POINTER_TYPE_P (basis_type) ? POINTER_PLUS_EXPR : PLUS_EXPR;
+
   if (known_stride)
 {
   tree bump_tree;
-  enum tree_code code = PLUS_EXPR;
+  enum tree_code code = plus_code;
   widest_int bump = increment * wi::to_widest (c->stride);
-  if (wi::neg_p (bump))
+  if (wi::neg_p (bump) && !POINTER_TYPE_P (basis_type))
{
  code = MINUS_EXPR;
  bump = -bump;
}
 
-  bump_tree = wide_int_to_tree (basis_type, bump);
+  tree stride_type = POINTER_TYPE_P (basis_type) ? sizetype : basis_type;
+  bump_tree = wide_int_to_tree (stride_type, bump);
   new_stmt = gimple_build_assign (lhs, code, basis_name, bump_tree);
 }
   else
 {
   int i;
-  bool negate_incr = (!address_arithmetic_p && wi::neg_p (increment));
+  bool negate_incr = !POINTER_TYPE_P (basis_type) && wi::neg_p (increment);
   i = incr_vec_index (negate_incr ? -increment : increment);
   gcc_assert (i >= 0);
 
   if (incr_vec[i].initializer)
{
- enum tree_code code = negate_incr ? MINUS_EXPR : PLUS_EXPR;
+ enum tree_code code = negate_incr ? MINUS_EXPR : plus_code;
  new_stmt = gimple_build_assign (lhs, code, basis_name,
  incr_vec[i].initializer);
}
   else if (increment == 1)
-   new_stmt = gimple_build_assign (lhs, PLUS_EXPR, basis_name, c->stride);
+   new_stmt = gimple_build_assign (lhs, plus_code, basis_name, c->stride);
   else if (increment == -1)
new_stmt = gimple_build_assign (lhs, MINUS_EXPR, basis_name,
c->stride);
@@ -2500,12 +2506,14 @@ record_increment (slsr_cand_t c, widest_int increm
   /* Optimistically record the first occurrence of this increment
 as providing an initializer (if it does); we will revise this
 opinion later if it doesn't dominate all other occurrences.
- Exception:  increments of -1, 0, 1 never need initializers;
-and phi adjustments don't ever provide initializers.  */
+ Exception:  increments of 0, 1 never need initializers;
+and phi adjustments don't ever provide initializers.  Note
+ that we only will see an increment of -1 here for pointer
+arithmetic (otherwise we will have an initializer).  */
   if (c->kind == CAND_ADD
  && !is_phi_adjust
  && c->index == increment
- && (increment > 1 || increment < -1)
+ && (increment > 1 || increment < 0)
  && (gimple_assign_rhs_code (c->cand_stmt) == PLUS_EXPR
  || gimple_assign_rhs_code (c->cand_stmt) == POINTER_PLUS_EXPR))
{
@@ -2819,11 +2827,6 @@ analyze_increments (slsr_cand_t first_dep, machine
   && !POINTER_TYPE_P (first_dep->cand_type)))

[Bug tree-optimization/77916] [6/7 Regression] ICE in verify_gimple_in_cfg: invalid (pointer) operands to plus/minus

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
Author: wschmidt
Date: Mon Oct 17 22:08:56 2016
New Revision: 241281

URL: https://gcc.gnu.org/viewcvs?rev=241281=gcc=rev
Log:
[gcc]

2016-10-17  Bill Schmidt  

PR tree-optimization/77916
* gimple-ssa-strength-reduction.c (create_add_on_incoming_edge):
Don't allow a MINUS_EXPR for pointer arithmetic for either known
or unknown strides.
(record_increment): Increments of -1 for unknown strides just use
a multiply initializer like other negative values.
(analyze_increments): Remove stopgap solution for -1 increment
applied to pointer arithmetic.

[gcc/testsuite]

2016-10-17  Bill Schmidt  

PR tree-optimization/77916
* gcc.dg/torture/pr77916.c: New.


Added:
trunk/gcc/testsuite/gcc.dg/torture/pr77916.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c
trunk/gcc/testsuite/ChangeLog

Re: [PATCH] fix outstanding -Wformat-length failures (pr77735 et al.)

[Martin Sebor]

On 10/17/2016 01:11 PM, Jeff Law wrote:

On 10/02/2016 02:10 PM, Martin Sebor wrote:

The attached patch fixes a number of outstanding test failures
and ILP32-related bugs in the gimple-ssa-sprintf pattch pointed
out in bug 77676 and 77735).  The patch also fixes c_strlen to
correctly handle wide strings (previously it accepted them but
treated them as nul-terminated byte sequences), and adjusts the
handling of "%a" to avoid assuming a specific number of decimal
digits (this is likely a defect in C11 that I'm pursuing with
WG14).

Tested on powerpc64le, i386, and x86_64.

There is one outstanding failure in the builtin-sprintf-warn-1.c
test on powerpc64le that looks like it might be due to the
printf_pointer_format target hook not having been set up entirely
correctly.  I'll look into that separately, along with pr77819.

Martin

gcc-77735.diff


PR middle-end/77735 - FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c

gcc/ChangeLog:
2016-10-02  Martin Sebor  

PR middle-end/77735
* builtins.c (string_length): New function.
(c_strlen): Use string_length.  Correctly handle wide strings.
* gimple-ssa-sprintf.c (target_max_value, target_size_max): New
functions.
(target_int_max): Call target_max_value.
(format_result::knownrange): New data member.
(fmtresult::fmtresult): Define default constructor.
(format_integer): Use it and set format_result::knownrange.
Handle global constants.
(format_floating_max): Add third argument.
(format_floating): Recompute maximum value for %a for each argument.
(get_string_length): Use fmtresult default ctor.
(format_string): Set format_result::knownrange.
(format_directive): Check format_result::knownrange.
(add_bytes): Same.  Correct caret placement in diagnostics.
(pass_sprintf_length::compute_format_length): Set
format_result::knownrange.
(pass_sprintf_length::handle_gimple_call): Use target_size_max.

gcc/testsuite/ChangeLog:
2016-10-02  Martin Sebor  

PR middle-end/77735
* gcc.dg/tree-ssa/builtin-sprintf-2.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-2.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Adjust/relax.
* gcc.dg/tree-ssa/builtin-sprintf-warn-4.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-6.c: XFAIL for LP64 only.
* gcc.dg/tree-ssa/builtin-sprintf.c: Add test cases.

diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 92f939e..410bbc3 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -1281,9 +1330,9 @@ format_floating (const conversion_spec ,
int width, int prec)
 res.range.max = width;
 }

-  /* The argument is only considered bounded when the range of output
- bytes is exact.  */
-  res.bounded = res.range.min == res.range.max;
+  /* The argument is considered bounded when the output of a directive
+ is fully specified and the range of output bytes is exact.  */
+  // res.bounded &= res.range.min == res.range.max;

Did you mean to leave this commented out?


I'm pretty sure I didn't mean to leave the code commented out like
that.  I suspect I commented it out to confirm that it's not needed,
and forgot to remove it after it passed my testing.  Let me remove
it (and thanks for pointing it out!)


It looks like you're defining a constructor for "struct fmtresult".
Normally once we define a constructor we turn the underlying object into
a class.It appears that the constructor leaves argmin, argmax,
knownrange, bounded & constant uninitialized?  Am I missing something here?


I added the default ctor to avoid having to explicitly clear the
members.  The member() syntax means to default-initialize them by
setting them to zero or null:

 struct fmtresult
 {
+  fmtresult ()
+  : argmin (), argmax (), knownrange (), bounded (), constant ()
+  {
+range.min = range.max = HOST_WIDE_INT_MAX;
+  }
+

Or did you have something else in mind?  (I want to leave the members
public so they can conveniently accessed.)





+  /* A plain '%c' directive.  Its ouput is excactly 1.  */

Typo for exactly.



Will fix.

With that and with the comment above removed, would like me to post
an updated patch or is it okay commit?

Martin

[PATCH] DWARF5 DW_FORM_implicit_const support

[Jakub Jelinek]

Hi!

This patch starts using DW_FORM_implicit_const (new in DWARF5), though only
for cases where the constants are the same among all DIEs with the same
abbreviation (and only for abbrevs used only in the main compilation unit,
because right now we don't give all DIEs abbreviations first before
outputing anything.  I think more precise optimizations could be left to DWZ
(when it sees the whole binary or library, it can better simulate different
decisions like using two different abbreviations for different subsets of
DIEs which have the same attributes and forms, but differ in some const
values, etc.

The patch also switches the abbrev table from GC registered array with used
and allocated integers to normal va_gc vector.

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

2016-10-17  Jakub Jelinek  

* dwarf2out.h (enum dw_val_class): Add dw_val_class_const_implicit,
dw_val_class_unsigned_const_implicit and dw_val_class_file_implicit.
(struct dw_val_node): Add val_file_implicit field.
* dwarf2out.c (dw_val_equal_p, print_dw_val, attr_checksum,
attr_checksum_ordered, same_dw_val_p, size_of_die, value_format,
output_die): Handle dw_val_class_const_implicit,
dw_val_class_unsigned_const_implicit and dw_val_class_file_implicit.
(abbrev_die_table): Change into va_gc vec.
(abbrev_die_table_allocated, abbrev_die_table_in_use,
ABBREV_DIE_TABLE_INCREMENT): Remove.
(AT_int, AT_unsigned, AT_file): Allow dw_val_class_*_implicit.
(abbrev_opt_start, abbrev_usage_count, abbrev_dies): New variables.
(build_abbrev_table): Adjust for abbrev_die_table being a va_gc vec.
If abbrev_opt_start, fill in abbrev_usage_count and abbrev_dies
vectors.
(die_abbrev_cmp, optimize_implicit_const, optimize_abbrev_table): New
functions.
(output_die_abbrevs): For DW_FORM_implicit_const emit sleb128 with
the implicit value.
(output_abbrev_section): Adjust for abbrev_die_table being a va_gc
vec.
(output_comp_unit): Initialize abbrev_opt_start if emitting the main
unit.  Call optimize_abbrev_table.
(dwarf2out_init, dwarf2out_finish, dwarf2out_c_finalize): Adjust for
abbrev_die_table being a va_gc vec.

--- gcc/dwarf2out.h.jj  2016-04-28 17:26:05.0 +0200
+++ gcc/dwarf2out.h 2016-10-17 19:07:45.425312870 +0200
@@ -153,7 +153,10 @@ enum dw_val_class
   dw_val_class_vms_delta,
   dw_val_class_high_pc,
   dw_val_class_discr_value,
-  dw_val_class_discr_list
+  dw_val_class_discr_list,
+  dw_val_class_const_implicit,
+  dw_val_class_unsigned_const_implicit,
+  dw_val_class_file_implicit
 };
 
 /* Describe a floating point constant value, or a vector constant value.  */
@@ -198,7 +201,8 @@ struct GTY(()) dw_val_node {
   dw_loc_list_ref GTY ((tag ("dw_val_class_loc_list"))) val_loc_list;
   dw_loc_descr_ref GTY ((tag ("dw_val_class_loc"))) val_loc;
   HOST_WIDE_INT GTY ((default)) val_int;
-  unsigned HOST_WIDE_INT GTY ((tag ("dw_val_class_unsigned_const"))) 
val_unsigned;
+  unsigned HOST_WIDE_INT
+   GTY ((tag ("dw_val_class_unsigned_const"))) val_unsigned;
   double_int GTY ((tag ("dw_val_class_const_double"))) val_double;
   wide_int_ptr GTY ((tag ("dw_val_class_wide_int"))) val_wide;
   dw_vec_const GTY ((tag ("dw_val_class_vec"))) val_vec;
@@ -212,6 +216,8 @@ struct GTY(()) dw_val_node {
   char * GTY ((tag ("dw_val_class_lbl_id"))) val_lbl_id;
   unsigned char GTY ((tag ("dw_val_class_flag"))) val_flag;
   struct dwarf_file_data * GTY ((tag ("dw_val_class_file"))) val_file;
+  struct dwarf_file_data *
+   GTY ((tag ("dw_val_class_file_implicit"))) val_file_implicit;
   unsigned char GTY ((tag ("dw_val_class_data8"))) val_data8[8];
   tree GTY ((tag ("dw_val_class_decl_ref"))) val_decl_ref;
   struct dw_val_vms_delta_union
--- gcc/dwarf2out.c.jj  2016-10-17 14:46:46.0 +0200
+++ gcc/dwarf2out.c 2016-10-17 19:17:54.350626382 +0200
@@ -1363,6 +1363,8 @@ dw_val_equal_p (dw_val_node *a, dw_val_n
 case dw_val_class_offset:
 case dw_val_class_unsigned_const:
 case dw_val_class_const:
+case dw_val_class_unsigned_const_implicit:
+case dw_val_class_const_implicit:
 case dw_val_class_range_list:
 case dw_val_class_lineptr:
 case dw_val_class_macptr:
@@ -1385,6 +1387,7 @@ dw_val_equal_p (dw_val_node *a, dw_val_n
 case dw_val_class_flag:
   return a->v.val_flag == b->v.val_flag;
 case dw_val_class_file:
+case dw_val_class_file_implicit:
   return a->v.val_file == b->v.val_file;
 case dw_val_class_decl_ref:
   return a->v.val_decl_ref == b->v.val_decl_ref;
@@ -3006,17 +3009,9 @@ struct dw_loc_list_hasher : ggc_ptr_hash
 /* Table of cached location lists.  */
 static GTY (()) hash_table *cached_dw_loc_list_table;
 
-/* A pointer to the base of a list of references to DIE's that

Re: [PATCH] PR77895: DWARF: Emit DW_AT_comp_dir in all cases, even if source is an absolute path

[Mike Stump]

On Oct 17, 2016, at 2:38 PM, Ximin Luo  wrote:
> 
> Mike Stump:
>> On Oct 17, 2016, at 11:00 AM, Ximin Luo  wrote:
>>> Therefore, it is better to emit it in all circumstances, in case the reader 
>>> needs to know what the working
>>> directory was at compile-time.
>> 
>> I can't help but wonder if this would break ccache some?
>> 
> 
> Could you explain this in some more detail? At the moment, GCC will already 
> emit DW_AT_name with an absolute path (in the scenario that this patch is 
> relevant to). How does ccache work around this at the moment? (Does it use 
> debug-prefix-map? In which case, this also affects DW_AT_comp_dir, so my 
> patch should be fine.)

If you compile the same file, but in a different directory, I wonder if cwd 
will cause the cache entry to not be reused.

I expect one of the ccache people that are around would just know if it will 
care at all.

[PATCH] DWARF5 DW_FORM_data16 support

[Jakub Jelinek]

Hi!

DWARF5 has a new 128-bit constant class form, this patch uses it
e.g. for __int128 values.

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

2016-10-17  Jakub Jelinek  

* dwarf2out.c (size_of_die, value_format, output_die): Use
DW_FORM_data16 for 128-bit dw_val_class_const_double or
dw_val_class_wide_int.

--- gcc/dwarf2out.c.jj  2016-10-17 11:45:03.0 +0200
+++ gcc/dwarf2out.c 2016-10-17 14:46:46.369083146 +0200
@@ -8591,14 +8591,14 @@ size_of_die (dw_die_ref die)
  break;
case dw_val_class_const_double:
  size += HOST_BITS_PER_DOUBLE_INT / HOST_BITS_PER_CHAR;
- if (HOST_BITS_PER_WIDE_INT >= 64)
+ if (HOST_BITS_PER_WIDE_INT >= (dwarf_version >= 5 ? 128 : 64))
size++; /* block */
  break;
case dw_val_class_wide_int:
  size += (get_full_len (*a->dw_attr_val.v.val_wide)
   * HOST_BITS_PER_WIDE_INT / HOST_BITS_PER_CHAR);
  if (get_full_len (*a->dw_attr_val.v.val_wide) * HOST_BITS_PER_WIDE_INT
- > 64)
+ > (dwarf_version >= 5 ? 128 : 64))
size++; /* block */
  break;
case dw_val_class_vec:
@@ -8979,6 +8979,9 @@ value_format (dw_attr_node *a)
case 32:
  return DW_FORM_data8;
case 64:
+ if (dwarf_version >= 5)
+   return DW_FORM_data16;
+ /* FALLTHRU */
default:
  return DW_FORM_block1;
}
@@ -8993,6 +8996,10 @@ value_format (dw_attr_node *a)
  return DW_FORM_data4;
case 64:
  return DW_FORM_data8;
+   case 128:
+ if (dwarf_version >= 5)
+   return DW_FORM_data16;
+ /* FALLTHRU */
default:
  return DW_FORM_block1;
}
@@ -9439,7 +9446,7 @@ output_die (dw_die_ref die)
  {
unsigned HOST_WIDE_INT first, second;
 
-   if (HOST_BITS_PER_WIDE_INT >= 64)
+   if (HOST_BITS_PER_WIDE_INT >= (dwarf_version >= 5 ? 128 : 64))
  dw2_asm_output_data (1,
   HOST_BITS_PER_DOUBLE_INT
   / HOST_BITS_PER_CHAR,
@@ -9468,9 +9475,9 @@ output_die (dw_die_ref die)
int i;
int len = get_full_len (*a->dw_attr_val.v.val_wide);
int l = HOST_BITS_PER_WIDE_INT / HOST_BITS_PER_CHAR;
-   if (len * HOST_BITS_PER_WIDE_INT > 64)
- dw2_asm_output_data (1, get_full_len (*a->dw_attr_val.v.val_wide) 
* l,
-  NULL);
+   if (len * HOST_BITS_PER_WIDE_INT > (dwarf_version >= 5 ? 128 : 64))
+ dw2_asm_output_data (1, get_full_len (*a->dw_attr_val.v.val_wide)
+ * l, NULL);
 
if (WORDS_BIG_ENDIAN)
  for (i = len - 1; i >= 0; --i)

Jakub

Re: [PATCH] PR77895: DWARF: Emit DW_AT_comp_dir in all cases, even if source is an absolute path

[Ximin Luo]

Mike Stump:
> On Oct 17, 2016, at 11:00 AM, Ximin Luo  wrote:
>> Therefore, it is better to emit it in all circumstances, in case the reader 
>> needs to know what the working
>> directory was at compile-time.
> 
> I can't help but wonder if this would break ccache some?
> 

Could you explain this in some more detail? At the moment, GCC will already 
emit DW_AT_name with an absolute path (in the scenario that this patch is 
relevant to). How does ccache work around this at the moment? (Does it use 
debug-prefix-map? In which case, this also affects DW_AT_comp_dir, so my patch 
should be fine.)

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

[PATCH] DWARF5 DW_TAG_call_site support

[Jakub Jelinek]

Hi!

This is on top of the
http://gcc.gnu.org/ml/gcc-patches/2016-10/msg01202.html
patch.  This is yet another GNU extension that got accepted into DWARF5,
though in this case various attributes got renamed (other than just dropping
GNU_ middle parts), or extra attributes have been added instead of reusing
preexisting ones like DW_AT_location or DW_AT_abstract_origin.

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

2016-10-17  Jakub Jelinek  

* dwarf2out.c (dwarf_op): Renamed to ...
(dwarf_OP): ... this.
(convert_descriptor_to_mode, scompare_loc_descriptor,
minmax_loc_descriptor, typed_binop, mem_loc_descriptor,
implicit_ptr_descriptor, optimize_one_addr_into_implicit_ptr): Adjust
callers.
(dwarf_AT, dwarf_TAG): New functions.
(check_die): Disallow DW_AT_call_all_calls next to
DW_AT_GNU_all_call_sites.
(gen_call_site_die): Use dwarf_TAG and dwarf_AT with DWARF 5 tag
and attributes instead of the corresponding GNU tag and attributes.
(gen_subprogram_die): Likewise.  Emit call site information even
for -gdwarf-5 -gstrict-dwarf.  Replace DW_AT_GNU_defaulted with
DW_AT_defaulted in comment.
(resolve_addr): Handle DW_AT_call_origin attribute on
DW_TAG_call_site DIE like DW_AT_abstract_origin on
DW_TAG_GNU_call_site DIE.

--- gcc/dwarf2out.c.jj  2016-10-17 10:03:14.0 +0200
+++ gcc/dwarf2out.c 2016-10-17 11:45:03.113680457 +0200
@@ -1517,7 +1517,7 @@ loc_list_plus_const (dw_loc_list_ref lis
 /* Utility inline function for construction of ops that were GNU extension
before DWARF 5.  */
 static inline enum dwarf_location_atom
-dwarf_op (enum dwarf_location_atom op)
+dwarf_OP (enum dwarf_location_atom op)
 {
   switch (op)
 {
@@ -1562,6 +1562,90 @@ dwarf_op (enum dwarf_location_atom op)
   return op;
 }
 
+/* Similarly for attributes.  */
+static inline enum dwarf_attribute
+dwarf_AT (enum dwarf_attribute at)
+{
+  switch (at)
+{
+case DW_AT_call_return_pc:
+  if (dwarf_version < 5)
+   return DW_AT_low_pc;
+  break;
+
+case DW_AT_call_tail_call:
+  if (dwarf_version < 5)
+   return DW_AT_GNU_tail_call;
+  break;
+
+case DW_AT_call_origin:
+  if (dwarf_version < 5)
+   return DW_AT_abstract_origin;
+  break;
+
+case DW_AT_call_target:
+  if (dwarf_version < 5)
+   return DW_AT_GNU_call_site_target;
+  break;
+
+case DW_AT_call_target_clobbered:
+  if (dwarf_version < 5)
+   return DW_AT_GNU_call_site_target_clobbered;
+  break;
+
+case DW_AT_call_parameter:
+  if (dwarf_version < 5)
+   return DW_AT_abstract_origin;
+  break;
+
+case DW_AT_call_value:
+  if (dwarf_version < 5)
+   return DW_AT_GNU_call_site_value;
+  break;
+
+case DW_AT_call_data_value:
+  if (dwarf_version < 5)
+   return DW_AT_GNU_call_site_data_value;
+  break;
+
+case DW_AT_call_all_calls:
+  if (dwarf_version < 5)
+   return DW_AT_GNU_all_call_sites;
+  break;
+
+case DW_AT_call_all_tail_calls:
+  if (dwarf_version < 5)
+   return DW_AT_GNU_all_tail_call_sites;
+  break;
+
+default:
+  break;
+}
+  return at;
+}
+
+/* And similarly for tags.  */
+static inline enum dwarf_tag
+dwarf_TAG (enum dwarf_tag tag)
+{
+  switch (tag)
+{
+case DW_TAG_call_site:
+  if (dwarf_version < 5)
+   return DW_TAG_GNU_call_site;
+  break;
+
+case DW_TAG_call_site_parameter:
+  if (dwarf_version < 5)
+   return DW_TAG_GNU_call_site_parameter;
+  break;
+
+default:
+  break;
+}
+  return tag;
+}
+
 static unsigned long int get_base_type_offset (dw_die_ref);
 
 /* Return the size of a location descriptor.  */
@@ -5998,6 +6082,7 @@ check_die (dw_die_ref die)
&& a->dw_attr != DW_AT_high_pc
&& a->dw_attr != DW_AT_location
&& a->dw_attr != DW_AT_frame_base
+   && a->dw_attr != DW_AT_call_all_calls
&& a->dw_attr != DW_AT_GNU_all_call_sites);
 }
 }
@@ -12696,13 +12781,13 @@ convert_descriptor_to_mode (machine_mode
 
   if (GET_MODE_SIZE (mode) <= DWARF2_ADDR_SIZE)
 {
-  add_loc_descr (, new_loc_descr (dwarf_op (DW_OP_convert), 0, 0));
+  add_loc_descr (, new_loc_descr (dwarf_OP (DW_OP_convert), 0, 0));
   return op;
 }
   type_die = base_type_for_mode (outer_mode, 1);
   if (type_die == NULL)
 return NULL;
-  cvt = new_loc_descr (dwarf_op (DW_OP_convert), 0, 0);
+  cvt = new_loc_descr (dwarf_OP (DW_OP_convert), 0, 0);
   cvt->dw_loc_oprnd1.val_class = dw_val_class_die_ref;
   cvt->dw_loc_oprnd1.v.val_die_ref.die = type_die;
   cvt->dw_loc_oprnd1.v.val_die_ref.external = 0;
@@ -12767,12 +12852,12 @@ scompare_loc_descriptor (enum dwarf_loca
 
   if (type_die == NULL)
return NULL;
-  cvt = new_loc_descr (dwarf_op 

[Bug fortran/77978] stop codes misinterpreted in both f2003 and f2008

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Oct 17 21:29:31 2016
New Revision: 241280

URL: https://gcc.gnu.org/viewcvs?rev=241280=gcc=rev
Log:
2016-10-17  Steven G. Kargl  

PR fortran/77978
* match.c (gfc_match_stopcode): Fix error reporting for several
deficiencies in matching stop-codes.

2016-10-17  Steven G. Kargl  

PR fortran/77978
* gfortran.dg/pr77978_1.f90: New test.
* gfortran.dg/pr77978_2.f90: Ditto.
* gfortran.dg/pr77978_3.f90: Ditto.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr77978_1.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr77978_2.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr77978_3.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/match.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

Re: [PATCH] PR77895: DWARF: Emit DW_AT_comp_dir in all cases, even if source is an absolute path

[Mike Stump]

On Oct 17, 2016, at 11:00 AM, Ximin Luo  wrote:
> Therefore, it is better to emit it in all circumstances, in case the reader 
> needs to know what the working
> directory was at compile-time.

I can't help but wonder if this would break ccache some?

Re: RFC [1/3] divmod transform v2

[Jeff Law]

On 10/15/2016 11:59 PM, Prathamesh Kulkarni wrote:

This patch is mostly the same as previous one, except it drops
targeting __udivmoddi4() because it gave undefined reference link
error for calling __udivmoddi4() on aarch64-linux-gnu. It appears
aarch64 has hardware insn for DImode div, so __udivmoddi4() isn't
needed for the target (it was a bug in my patch that called
__udivmoddi4() even though aarch64 supported hardware div).
This touches on the one high level question I had.  Namely what is the 
code generation strategy if the hardware has a div, but not divmod.


ISTM in that case I think we want to use the div instruction and 
synthesize mod from that result rather than relying on a software 
divmod.  So it looks like you ought to be doing the right thing for that 
case now based on your comment above.


However this makes me wonder if it's guaranteed that __udivmoddi4()
will be available for a target if it doesn't have hardware div and
divmod insn and doesn't have target-specific libfunc for DImode
divmod ? To be conservative, the attached patch doesn't generate call
to __udivmoddi4.
I don't think that's a safe assumption.  Addition of the divmod routines 
into libgcc is controlled by the target and have to be explicitly added 
AFAICT.


So on a target like the fr30 which has no div or mod insn and doesn't 
define the right bits in libgcc, there is no divmod libcall available. 
(On these targets there's a div libcall and a mod libcall, but not a 
combined one).


I don't even think we have a way of knowing in the compiler if the 
target has enabled divmod support in libgcc.


ISTM that for now we have to limit to cases where we have a divmod 
insn/libcall defined.


jeff

[Bug c++/78014] -Wformat -vs- size_t

[tromey at gcc dot gnu.org]

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

--- Comment #3 from Tom Tromey  ---
(In reply to jos...@codesourcery.com from comment #2)

> Likewise an expression where the user did "typedef size_t my_size_t;" and 
> then used my_size_t.  And what about expressions resulting from arithmetic 
> on size_t values?  So it may be hard for the compiler to tell exactly what 
> expressions are appropriate for use with %zu (even without direct use of 
> __SIZE_TYPE__).

I think it's still preferable for gcc to be better about this even if it
can't be perfect.

First, in my particular case, I think all the types in question are just
"size_t" -- it's common to use this in spidermonkey.

Second, the problem I have is that I wanted to enable -Wformat.  So, I
wrote a bunch of patches -- which then failed to build on other arches.
In this case, if gcc had warned about size_t/%lu mixups in the code, while
perhaps I wouldn't have caught every possible cross-arch build bug, I
certainly would have far fewer of them.

Re: [PATCH] read-md.c: Move various state to within class rtx_reader (v3)

[Richard Sandiford]

David Malcolm  writes:
>> I assume you didn't turn the functions above into member functions
>> because they aren't primitives.  OTOH it might seem inconsistent
>> to have things like traverse_enum_types as member functions but
>> traverse_md_constants not.
>
> In the following I've converted traverse_md_constants to a member
> function.
>
> Successfully bootstrapped on x86_64-pc-linux-gnu.
>
> OK for trunk?

OK, thanks.  And thanks for doing this -- nice clean-up!

Richard

Re: [PATCH] (PR 65950) Improve predicate for exit(0);

[Andrew Pinski]

On Wed, Sep 21, 2016 at 1:53 AM, Richard Biener
 wrote:
> On Wed, Sep 21, 2016 at 10:45 AM, Andrew Pinski  wrote:
>> On Wed, Sep 21, 2016 at 4:32 PM, Richard Biener
>>  wrote:
>>> On Wed, Sep 21, 2016 at 9:13 AM, Andrew Pinski  wrote:
 Hi,
   While looking through bug reports, I noticed someone had reported
 that LTO caused the vectorizer not to kick in.  Originally it was not
 obvious why it would change the behavior since this was a simple
 program with nothing out of the ordinary.  Well it turned out paths
 leading to the exit(0); at the end of main was being marked as cold
 and in the LTO case the funciton (which had loop which should have
 been vectorized) was considered local and being marked as cold as it
 was only called now from the path leading to the exit(0);  Since
 exit(0); is considered a normal exit path, there is no reason to mark
 it as being as a cold path; let the other predicate handle it.

 So this patch changes the predicate for exit(0) not to mark the paths
 leading up to that function call as being cold.  Note this patch only
 disables that when the argument is a literal zero so if we a PHI node
 which contains the exit value, we still cause those paths to be
 considered cold; this will be for another patch.
>>>
>>> Hmm, it also doesn't work for main calling a function not returning but 
>>> exiting
>>> with exit (0) (it will be discovered as noreturn).
>>>
>>> I don't think that treating exit (0) as generally not terminating a cold 
>>> code
>>> sequence is good either.
>>>
>>> Predictions are always hard I guess ...
>>>
>>> But the thing to improve is maybe the different handling of main with
>>> respect to the guessed profile -- this is something that should not happen
>>> inconsistently between LTO / non-LTO as main is special in all cases.  
>>> Honza?
>>
>> Maybe I did not explain it very well but what is happening is a
>> function which is only called in the cold path is marked as cold only
>> in the LTO case as it is extern call.. Basically with LTO, the
>> function becomes local so it can be marked as cold while without LTO,
>> it cannot.
>
> Ah, so you have
>
> foo () { loop }
> main()
> {
>   if ()
>{
>   foo ();
>   exit (0);
>}
> ...
>   return 0;
> }
>
> and foo is marked cold because its only call is on the path to exit (0)?


Actually the case I have here is just:
foo () { loop }
int main(void)
{
.
foo();
...
exit (0);
}

Just an exit at the end of main.
Basically if we treat exit(0) as a normal function, main becomes hot again.

Thanks,
Andrew

>
> noreturn prediction is quite aggressive but it works also quite well.  Given
> you can only detect a very minor fraction of cases (consider exit (0) being
> in foo itself) I'm not sure that your fix is good progress.  IMHO we might
> want to switch from 'noreturn' to 'noreturn' + likely error which needs
> another attribute / auto-discovery and IPA propagation to handle this case
> better.
>
> Anyway, I'll leave the patch to Honza.
>
> Richard.
>
>> Thanks,
>> Andrew
>>
>>>
>>> Richard.
>>>
 OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.
 Also tested it with SPEC CPU 2006 with no performance regressions.

 Thanks,
 Andrew Pinski

 ChangeLog:
 * predict.c (is_exit_with_zero_arg): New function.
 (tree_bb_level_predictions): Don't consider paths leading to exit(0)
 as nottaken.

[Bug fortran/77978] stop codes misinterpreted in both f2003 and f2008

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Oct 17 19:57:12 2016
New Revision: 241279

URL: https://gcc.gnu.org/viewcvs?rev=241279=gcc=rev
Log:
2016-10-17  Steven G. Kargl  

PR fortran/77978
* match.c (gfc_match_stopcode): Fix error reporting for several
deficiencies in matching stop-codes.

2016-10-17  Steven G. Kargl  

PR fortran/77978
* gfortran.dg/pr77978_1.f90: New test.
* gfortran.dg/pr77978_2.f90: Ditto.
* gfortran.dg/pr77978_3.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/pr77978_1.f90
trunk/gcc/testsuite/gfortran.dg/pr77978_2.f90
trunk/gcc/testsuite/gfortran.dg/pr77978_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/78014] -Wformat -vs- size_t

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
I think this is essentially the same as bug 77970 - making such warnings 
smarter about the case of standard typedefs.

Of course an expression resulting from sizeof must be considered 
appropriate for %zu.  Likewise _Alignof.  Likewise SIZE_MAX, but headers 
or predefines just define it to use an appropriate constant suffix, so 
without looking at the macro being expanded there's nothing to distinguish 
it from any constant where the user wrong such a suffix directly.  
Likewise an expression where the user did "typedef size_t my_size_t;" and 
then used my_size_t.  And what about expressions resulting from arithmetic 
on size_t values?  So it may be hard for the compiler to tell exactly what 
expressions are appropriate for use with %zu (even without direct use of 
__SIZE_TYPE__).

[Bug c++/78014] -Wformat -vs- size_t

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
Since size_t is a typedef, long int might be typedef so size_t works there.

I don't see a reason for a warning on those targets.  Yes a warning for
portability would be nice but I don't know if it is easy to do and if people
want it turned on by default.

[PATCH 7/7] make targetm.gen_ccmp{first,next} take rtx_insn **

[tbsaunde+gcc]

From: Trevor Saunders 

gcc/ChangeLog:

2016-10-17  Trevor Saunders  

* ccmp.c (expand_ccmp_expr_1): Adjust.
(expand_ccmp_expr): Likewise.
(expand_ccmp_next): Likewise.
* config/aarch64/aarch64.c (aarch64_gen_ccmp_next): Likewise.
(aarch64_gen_ccmp_first): Likewise.
* doc/tm.texi: Regenerate.
* target.def (gen_ccmp_first): Change argument types to rtx_insn *.
(gen_ccmp_next): Likewise.
---
 gcc/ccmp.c   | 21 ++---
 gcc/config/aarch64/aarch64.c | 10 +-
 gcc/doc/tm.texi  |  4 ++--
 gcc/target.def   |  4 ++--
 4 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/gcc/ccmp.c b/gcc/ccmp.c
index 615b7e6..14222ca 100644
--- a/gcc/ccmp.c
+++ b/gcc/ccmp.c
@@ -122,7 +122,7 @@ ccmp_candidate_p (gimple *g)
GEN_SEQ returns all compare insns.  */
 static rtx
 expand_ccmp_next (gimple *g, tree_code code, rtx prev,
- rtx *prep_seq, rtx *gen_seq)
+ rtx_insn **prep_seq, rtx_insn **gen_seq)
 {
   rtx_code rcode;
   int unsignedp = TYPE_UNSIGNED (TREE_TYPE (gimple_assign_rhs1 (g)));
@@ -149,10 +149,8 @@ expand_ccmp_next (gimple *g, tree_code code, rtx prev,
PREP_SEQ returns all insns to prepare opearand.
GEN_SEQ returns all compare insns.  */
 static rtx
-expand_ccmp_expr_1 (gimple *g, rtx *prep_seq, rtx *gen_seq)
+expand_ccmp_expr_1 (gimple *g, rtx_insn **prep_seq, rtx_insn **gen_seq)
 {
-  rtx prep_seq_1, gen_seq_1;
-  rtx prep_seq_2, gen_seq_2;
   tree exp = gimple_assign_rhs_to_tree (g);
   tree_code code = TREE_CODE (exp);
   gimple *gs0 = get_gimple_for_ssa_name (TREE_OPERAND (exp, 0));
@@ -180,6 +178,7 @@ expand_ccmp_expr_1 (gimple *g, rtx *prep_seq, rtx *gen_seq)
  rcode0 = get_rtx_code (code0, unsignedp0);
  rcode1 = get_rtx_code (code1, unsignedp1);
 
+ rtx_insn *prep_seq_1, *gen_seq_1;
  tmp = targetm.gen_ccmp_first (_seq_1, _seq_1, rcode0,
gimple_assign_rhs1 (gs0),
gimple_assign_rhs2 (gs0));
@@ -187,14 +186,15 @@ expand_ccmp_expr_1 (gimple *g, rtx *prep_seq, rtx 
*gen_seq)
  if (tmp != NULL)
{
  ret = expand_ccmp_next (gs1, code, tmp, _seq_1, _seq_1);
- cost1 = seq_cost (safe_as_a  (prep_seq_1), speed_p);
- cost1 += seq_cost (safe_as_a  (gen_seq_1), speed_p);
+ cost1 = seq_cost (prep_seq_1, speed_p);
+ cost1 += seq_cost (gen_seq_1, speed_p);
}
 
  /* FIXME: Temporary workaround for PR69619.
 Avoid exponential compile time due to expanding gs0 and gs1 twice.
 If gs0 and gs1 are complex, the cost will be high, so avoid
 reevaluation if above an arbitrary threshold.  */
+ rtx_insn *prep_seq_2, *gen_seq_2;
  if (tmp == NULL || cost1 < COSTS_N_INSNS (25))
tmp2 = targetm.gen_ccmp_first (_seq_2, _seq_2, rcode1,
   gimple_assign_rhs1 (gs1),
@@ -207,8 +207,8 @@ expand_ccmp_expr_1 (gimple *g, rtx *prep_seq, rtx *gen_seq)
{
  ret2 = expand_ccmp_next (gs0, code, tmp2, _seq_2,
   _seq_2);
- cost2 = seq_cost (safe_as_a  (prep_seq_2), speed_p);
- cost2 += seq_cost (safe_as_a  (gen_seq_2), speed_p);
+ cost2 = seq_cost (prep_seq_2, speed_p);
+ cost2 += seq_cost (gen_seq_2, speed_p);
}
 
  if (cost2 < cost1)
@@ -262,14 +262,13 @@ expand_ccmp_expr (gimple *g)
 {
   rtx_insn *last;
   rtx tmp;
-  rtx prep_seq, gen_seq;
-
-  prep_seq = gen_seq = NULL_RTX;
 
   if (!ccmp_candidate_p (g))
 return NULL_RTX;
 
   last = get_last_insn ();
+
+  rtx_insn *prep_seq = NULL, *gen_seq = NULL;
   tmp = expand_ccmp_expr_1 (g, _seq, _seq);
 
   if (tmp)
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 74f1a6a..771421c 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -13160,7 +13160,7 @@ aarch64_use_by_pieces_infrastructure_p (unsigned 
HOST_WIDE_INT size,
 }
 
 static rtx
-aarch64_gen_ccmp_first (rtx *prep_seq, rtx *gen_seq,
+aarch64_gen_ccmp_first (rtx_insn **prep_seq, rtx_insn **gen_seq,
int code, tree treeop0, tree treeop1)
 {
   machine_mode op_mode, cmp_mode, cc_mode = CCmode;
@@ -13234,8 +13234,8 @@ aarch64_gen_ccmp_first (rtx *prep_seq, rtx *gen_seq,
 }
 
 static rtx
-aarch64_gen_ccmp_next (rtx *prep_seq, rtx *gen_seq, rtx prev, int cmp_code,
-  tree treeop0, tree treeop1, int bit_code)
+aarch64_gen_ccmp_next (rtx_insn **prep_seq, rtx_insn **gen_seq, rtx prev,
+  int cmp_code, tree treeop0, tree treeop1, int bit_code)
 {
   rtx op0, op1, target;
   machine_mode op_mode, cmp_mode, cc_mode = CCmode;
@@ -13244,7 +13244,7 @@ aarch64_gen_ccmp_next 

[PATCH 5/7] remove cast in delete_insn_chain

[tbsaunde+gcc]

From: Trevor Saunders 

gcc/ChangeLog:

2016-10-17  Trevor Saunders  

* cfgrtl.c (delete_insn_chain): Change argument type to rtx_insn *
and adjust for that.
* cfgrtl.h (delete_insn_chain): Adjust prototype.
---
 gcc/cfgrtl.c | 8 +++-
 gcc/cfgrtl.h | 2 +-
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c
index 813f7ce..d2719db 100644
--- a/gcc/cfgrtl.c
+++ b/gcc/cfgrtl.c
@@ -240,17 +240,15 @@ delete_insn_and_edges (rtx_insn *insn)
insns that cannot be removed to NULL.  */
 
 void
-delete_insn_chain (rtx start, rtx finish, bool clear_bb)
+delete_insn_chain (rtx start, rtx_insn *finish, bool clear_bb)
 {
-  rtx_insn *prev, *current;
-
   /* Unchain the insns one by one.  It would be quicker to delete all of these
  with a single unchaining, rather than one at a time, but we need to keep
  the NOTE's.  */
-  current = safe_as_a  (finish);
+  rtx_insn *current = finish;
   while (1)
 {
-  prev = PREV_INSN (current);
+  rtx_insn *prev = PREV_INSN (current);
   if (NOTE_P (current) && !can_delete_note_p (as_a  (current)))
;
   else
diff --git a/gcc/cfgrtl.h b/gcc/cfgrtl.h
index d81928a..f4c1396 100644
--- a/gcc/cfgrtl.h
+++ b/gcc/cfgrtl.h
@@ -22,7 +22,7 @@ along with GCC; see the file COPYING3.  If not see
 
 extern void delete_insn (rtx);
 extern bool delete_insn_and_edges (rtx_insn *);
-extern void delete_insn_chain (rtx, rtx, bool);
+extern void delete_insn_chain (rtx, rtx_insn *, bool);
 extern basic_block create_basic_block_structure (rtx_insn *, rtx_insn *,
 rtx_note *, basic_block);
 extern void compute_bb_for_insn (void);
-- 
2.9.3

[PATCH 3/7] use rtx_insn * more

[tbsaunde+gcc]

From: Trevor Saunders 

gcc/ChangeLog:

2016-10-17  Trevor Saunders  

* config/alpha/alpha.c (alpha_legitimize_address_1): Change
variable types from rtx to rtx_insn *.
(alpha_emit_xfloating_libcall): Likewise.
* config/arc/arc.c (arc_emit_call_tls_get_addr): Likewise.
* config/arm/arm.c (arm_call_tls_get_addr): Likewise.
(legitimize_tls_address): Likewise.
* config/bfin/bfin.c (hwloop_optimize): Likewise.
(bfin_gen_bundles): Likewise.
* config/c6x/c6x.c (reorg_split_calls): Likewise.
(c6x_reorg): Likewise.
* config/frv/frv.c (frv_reorder_packet): Likewise.
* config/i386/i386.c (ix86_split_idivmod): Likewise.
* config/ia64/ia64.c (ia64_expand_compare): Likewise.
* config/m32c/m32c.c (m32c_prepare_shift): Likewise.
* config/mips/mips.c (mips_call_tls_get_addr): Likewise.
(mips_legitimize_tls_address): Likewise.
* config/mn10300/mn10300.c: Likewise.
* config/rl78/rl78.c: Likewise.
* config/s390/s390.c (s390_fix_long_loop_prediction): Likewise.
* config/sh/sh-mem.cc (sh_expand_cmpstr): Likewise.
(sh_expand_cmpnstr): Likewise.
(sh_expand_strlen): Likewise.
(sh_expand_setmem): Likewise.
* config/sh/sh.md: Likewise.
* emit-rtl.c (emit_pattern_before): Likewise.
* except.c: Likewise.
* final.c: Likewise.
* jump.c: Likewise.
* optabs.c (expand_binop): Likewise.
* reload1.c (gen_reload): Likewise.
* reorg.c (relax_delay_slots): Likewise.
---
 gcc/config/alpha/alpha.c | 117 ++-
 gcc/config/arc/arc.c |   3 +-
 gcc/config/arm/arm.c |   9 ++--
 gcc/config/bfin/bfin.c   |   7 +--
 gcc/config/c6x/c6x.c |   9 ++--
 gcc/config/frv/frv.c |   2 +-
 gcc/config/i386/i386.c   |   3 +-
 gcc/config/ia64/ia64.c   |   4 +-
 gcc/config/m32c/m32c.c   |   4 +-
 gcc/config/mips/mips.c   |  61 +++---
 gcc/config/mn10300/mn10300.c |   2 +-
 gcc/config/rl78/rl78.c   |   2 +-
 gcc/config/s390/s390.c   |   7 +--
 gcc/config/sh/sh-mem.cc  |   8 +--
 gcc/config/sh/sh.md  |  18 +++
 gcc/emit-rtl.c   |   2 +-
 gcc/except.c |   2 +-
 gcc/final.c  |   4 +-
 gcc/jump.c   |   4 +-
 gcc/optabs.c |   5 +-
 gcc/reload1.c|   9 ++--
 gcc/reorg.c  |  19 ---
 22 files changed, 156 insertions(+), 145 deletions(-)

diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
index 7f53967..6d390ae 100644
--- a/gcc/config/alpha/alpha.c
+++ b/gcc/config/alpha/alpha.c
@@ -1017,7 +1017,8 @@ alpha_legitimize_address_1 (rtx x, rtx scratch, 
machine_mode mode)
   && GET_MODE_SIZE (mode) <= UNITS_PER_WORD
   && symbolic_operand (x, Pmode))
 {
-  rtx r0, r16, eqv, tga, tp, insn, dest, seq;
+  rtx r0, r16, eqv, tga, tp, dest, seq;
+  rtx_insn *insn;
 
   switch (tls_symbolic_operand_type (x))
{
@@ -1025,66 +1026,70 @@ alpha_legitimize_address_1 (rtx x, rtx scratch, 
machine_mode mode)
  break;
 
case TLS_MODEL_GLOBAL_DYNAMIC:
- start_sequence ();
+ {
+   start_sequence ();
 
- r0 = gen_rtx_REG (Pmode, 0);
- r16 = gen_rtx_REG (Pmode, 16);
- tga = get_tls_get_addr ();
- dest = gen_reg_rtx (Pmode);
- seq = GEN_INT (alpha_next_sequence_number++);
+   r0 = gen_rtx_REG (Pmode, 0);
+   r16 = gen_rtx_REG (Pmode, 16);
+   tga = get_tls_get_addr ();
+   dest = gen_reg_rtx (Pmode);
+   seq = GEN_INT (alpha_next_sequence_number++);
 
- emit_insn (gen_movdi_er_tlsgd (r16, pic_offset_table_rtx, x, seq));
- insn = gen_call_value_osf_tlsgd (r0, tga, seq);
- insn = emit_call_insn (insn);
- RTL_CONST_CALL_P (insn) = 1;
- use_reg (_INSN_FUNCTION_USAGE (insn), r16);
+   emit_insn (gen_movdi_er_tlsgd (r16, pic_offset_table_rtx, x, seq));
+   rtx val = gen_call_value_osf_tlsgd (r0, tga, seq);
+   insn = emit_call_insn (val);
+   RTL_CONST_CALL_P (insn) = 1;
+   use_reg (_INSN_FUNCTION_USAGE (insn), r16);
 
-  insn = get_insns ();
- end_sequence ();
+   insn = get_insns ();
+   end_sequence ();
 
- emit_libcall_block (insn, dest, r0, x);
- return dest;
+   emit_libcall_block (insn, dest, r0, x);
+   return dest;
+ }
 
case TLS_MODEL_LOCAL_DYNAMIC:
- start_sequence ();
+ {
+   start_sequence ();
 
- r0 = gen_rtx_REG (Pmode, 0);
- r16 = gen_rtx_REG (Pmode, 16);
- tga = get_tls_get_addr ();
- scratch = gen_reg_rtx (Pmode);
- seq = GEN_INT (alpha_next_sequence_number++);
+

[PATCH 1/7] make LABEL_REF_LABEL a rtx_insn *

[tbsaunde+gcc]

From: Trevor Saunders 

While chainging LABEL_REF_LABEL it might as well become an inline
function, so that its clearer what types are involved.  Unfortunately
because it is still possible to use XEXP and related macros on a
LABEL_REF rtx you can still set the field to be a non insn rtx.  The
other unfortunate thing is that the generators actually create LABEL_REF
rtx that refer to MATCH_x rtx, so there we actually need to use XEXP to
bypass the checking this patch adds.

gcc/ChangeLog:

2016-10-17  Trevor Saunders  

* rtl.h (label_ref_label): New function.
(set_label_ref_label): New function.
(LABEL_REF_LABEL): Delete.
* alias.c (rtx_equal_for_memref_p): Adjust.
* cfgbuild.c (make_edges): Likewise.
(purge_dead_tablejump_edges): Likewise.
* cfgexpand.c (convert_debug_memory_address): Likewise.
* cfgrtl.c (patch_jump_insn): Likewise.
* combine.c (distribute_notes): Likewise.
* cse.c (hash_rtx_cb): Likewise.
(exp_equiv_p): Likewise.
(fold_rtx): Likewise.
(check_for_label_ref): Likewise.
* cselib.c (rtx_equal_for_cselib_1): Likewise.
(cselib_hash_rtx): Likewise.
* emit-rtl.c (mark_label_nuses): Likewise.
* explow.c (convert_memory_address_addr_space_1): Likewise.
* final.c (output_asm_label): Likewise.
(output_addr_const): Likewise.
* gcse.c (add_label_notes): Likewise.
* genconfig.c (walk_insn_part): Likewise.
* genrecog.c (validate_pattern): Likewise.
* ifcvt.c (cond_exec_get_condition): Likewise.
(noce_emit_store_flag): Likewise.
(noce_get_alt_condition): Likewise.
(noce_get_condition): Likewise.
* jump.c (maybe_propagate_label_ref): Likewise.
(mark_jump_label_1): Likewise.
(redirect_exp_1): Likewise.
(rtx_renumbered_equal_p): Likewise.
* lra-constraints.c (operands_match_p): Likewise.
* print-rtl.c (print_value): Likewise.
* reload.c (find_reloads): Likewise.
* reload1.c (set_label_offsets): Likewise.
* reorg.c (get_branch_condition): Likewise.
* rtl-tests.c (test_uncond_jump): Likewise.
* rtl.c (rtx_equal_p_cb): Likewise.
(rtx_equal_p): Likewise.
* rtlanal.c (reg_mentioned_p): Likewise.
(rtx_referenced_p): Likewise.
(get_condition): Likewise.
* varasm.c (const_hash_1): Likewise.
(compare_constant): Likewise.
(const_rtx_hash_1): Likewise.
(output_constant_pool_1): Likewise.
---
 gcc/alias.c   |  2 +-
 gcc/cfgbuild.c|  4 ++--
 gcc/cfgexpand.c   |  2 +-
 gcc/cfgrtl.c  |  2 +-
 gcc/combine.c |  4 ++--
 gcc/cse.c | 20 ++--
 gcc/cselib.c  |  4 ++--
 gcc/emit-rtl.c|  4 ++--
 gcc/explow.c  |  2 +-
 gcc/final.c   |  4 ++--
 gcc/gcse.c|  6 +++---
 gcc/genconfig.c   |  4 ++--
 gcc/genrecog.c|  4 ++--
 gcc/ifcvt.c   |  8 
 gcc/jump.c| 18 --
 gcc/lra-constraints.c |  2 +-
 gcc/print-rtl.c   |  2 +-
 gcc/reload.c  | 12 ++--
 gcc/reload1.c |  6 +++---
 gcc/reorg.c   |  6 +++---
 gcc/rtl-tests.c   |  2 +-
 gcc/rtl.c |  4 ++--
 gcc/rtl.h | 11 ++-
 gcc/rtlanal.c |  6 +++---
 gcc/varasm.c  | 20 +++-
 25 files changed, 84 insertions(+), 75 deletions(-)

diff --git a/gcc/alias.c b/gcc/alias.c
index f4a0a29..ca475ff 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -1767,7 +1767,7 @@ rtx_equal_for_memref_p (const_rtx x, const_rtx y)
   return REGNO (x) == REGNO (y);
 
 case LABEL_REF:
-  return LABEL_REF_LABEL (x) == LABEL_REF_LABEL (y);
+  return label_ref_label (x) == label_ref_label (y);
 
 case SYMBOL_REF:
   return compare_base_symbol_refs (x, y) == 1;
diff --git a/gcc/cfgbuild.c b/gcc/cfgbuild.c
index 40c011d..6c70971 100644
--- a/gcc/cfgbuild.c
+++ b/gcc/cfgbuild.c
@@ -275,7 +275,7 @@ make_edges (basic_block min, basic_block max, int update_p)
  && GET_CODE (SET_SRC (tmp)) == IF_THEN_ELSE
  && GET_CODE (XEXP (SET_SRC (tmp), 2)) == LABEL_REF)
make_label_edge (edge_cache, bb,
-LABEL_REF_LABEL (XEXP (SET_SRC (tmp), 2)), 0);
+label_ref_label (XEXP (SET_SRC (tmp), 2)), 0);
}
 
  /* If this is a computed jump, then mark it as reaching
@@ -415,7 +415,7 @@ purge_dead_tablejump_edges (basic_block bb, 
rtx_jump_table_data *table)
&& SET_DEST (tmp) == pc_rtx
&& GET_CODE (SET_SRC (tmp)) == IF_THEN_ELSE
&& GET_CODE (XEXP (SET_SRC (tmp), 2)) == LABEL_REF)
-mark_tablejump_edge (LABEL_REF_LABEL (XEXP (SET_SRC (tmp), 2)));
+mark_tablejump_edge (label_ref_label (XEXP (SET_SRC (tmp), 

[PATCH 6/7] remove cast from prev_nonnote_insn_bb

[tbsaunde+gcc]

From: Trevor Saunders 

gcc/ChangeLog:

2016-10-17  Trevor Saunders  

* emit-rtl.c (prev_nonnote_insn_bb): Change argument type to
rtx_insn *.
* rtl.h (prev_nonnote_insn_bb): Adjust prototype.
---
 gcc/emit-rtl.c | 3 +--
 gcc/rtl.h  | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index a8516eb..e27587b 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -3354,9 +3354,8 @@ prev_nonnote_insn (rtx_insn *insn)
not look inside SEQUENCEs.  */
 
 rtx_insn *
-prev_nonnote_insn_bb (rtx uncast_insn)
+prev_nonnote_insn_bb (rtx_insn *insn)
 {
-  rtx_insn *insn = safe_as_a  (uncast_insn);
 
   while (insn)
 {
diff --git a/gcc/rtl.h b/gcc/rtl.h
index 9abb054..3901749 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -2856,7 +2856,7 @@ extern rtx_call_insn *last_call_insn (void);
 extern rtx_insn *previous_insn (rtx_insn *);
 extern rtx_insn *next_insn (rtx_insn *);
 extern rtx_insn *prev_nonnote_insn (rtx_insn *);
-extern rtx_insn *prev_nonnote_insn_bb (rtx);
+extern rtx_insn *prev_nonnote_insn_bb (rtx_insn *);
 extern rtx_insn *next_nonnote_insn (rtx_insn *);
 extern rtx_insn *next_nonnote_insn_bb (rtx_insn *);
 extern rtx_insn *prev_nondebug_insn (rtx_insn *);
-- 
2.9.3

[PATCH 2/7] make tablejump_p return the label as a rtx_insn *

[tbsaunde+gcc]

From: Trevor Saunders 

gcc/ChangeLog:

2016-10-17  Trevor Saunders  

* cfgcleanup.c (merge_blocks_move_successor_nojumps): Adjust.
(outgoing_edges_match): Likewise.
(try_crossjump_to_edge): Likewise.
* cfgrtl.c (try_redirect_by_replacing_jump): Likewise.
(rtl_tidy_fallthru_edge): Likewise.
* rtl.h (tablejump_p): Adjust prototype.
* rtlanal.c (tablejump_p): Return the label as a rtx_insn *.
---
 gcc/cfgcleanup.c |  8 
 gcc/cfgrtl.c |  7 +++
 gcc/rtl.h|  2 +-
 gcc/rtlanal.c| 32 
 4 files changed, 24 insertions(+), 25 deletions(-)

diff --git a/gcc/cfgcleanup.c b/gcc/cfgcleanup.c
index 1c9691d..c67b4d7 100644
--- a/gcc/cfgcleanup.c
+++ b/gcc/cfgcleanup.c
@@ -688,7 +688,7 @@ static void
 merge_blocks_move_successor_nojumps (basic_block a, basic_block b)
 {
   rtx_insn *barrier, *real_b_end;
-  rtx label;
+  rtx_insn *label;
   rtx_jump_table_data *table;
 
   /* If we are partitioning hot/cold basic blocks, we don't want to
@@ -709,7 +709,7 @@ merge_blocks_move_successor_nojumps (basic_block a, 
basic_block b)
   /* If there is a jump table following block B temporarily add the jump table
  to block B so that it will also be moved to the correct location.  */
   if (tablejump_p (BB_END (b), , )
-  && prev_active_insn (as_a (label)) == BB_END (b))
+  && prev_active_insn (label) == BB_END (b))
 {
   BB_END (b) = table;
 }
@@ -1697,7 +1697,7 @@ outgoing_edges_match (int mode, basic_block bb1, 
basic_block bb2)
   /* Check whether there are tablejumps in the end of BB1 and BB2.
  Return true if they are identical.  */
 {
-  rtx label1, label2;
+  rtx_insn *label1, *label2;
   rtx_jump_table_data *table1, *table2;
 
   if (tablejump_p (BB_END (bb1), , )
@@ -1994,7 +1994,7 @@ try_crossjump_to_edge (int mode, edge e1, edge e2,
  they have been already compared for equivalence in outgoing_edges_match ()
  so replace the references to TABLE1 by references to TABLE2.  */
   {
-  rtx label1, label2;
+  rtx_insn *label1, *label2;
   rtx_jump_table_data *table1, *table2;
 
   if (tablejump_p (BB_END (osrc1), , )
diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c
index 67cab71..813f7ce 100644
--- a/gcc/cfgrtl.c
+++ b/gcc/cfgrtl.c
@@ -1101,7 +1101,7 @@ try_redirect_by_replacing_jump (edge e, basic_block 
target, bool in_cfglayout)
 {
   rtx_code_label *target_label = block_label (target);
   rtx_insn *barrier;
-  rtx label;
+  rtx_insn *label;
   rtx_jump_table_data *table;
 
   emit_jump_insn_after_noloc (targetm.gen_jump (target_label), insn);
@@ -1773,7 +1773,7 @@ rtl_tidy_fallthru_edge (edge e)
   && (any_uncondjump_p (q)
  || single_succ_p (b)))
 {
-  rtx label;
+  rtx_insn *label;
   rtx_jump_table_data *table;
 
   if (tablejump_p (q, , ))
@@ -1786,8 +1786,7 @@ rtl_tidy_fallthru_edge (edge e)
  PUT_CODE (label, NOTE);
  NOTE_KIND (label) = NOTE_INSN_DELETED_LABEL;
  NOTE_DELETED_LABEL_NAME (label) = name;
- rtx_insn *lab = safe_as_a  (label);
- reorder_insns (lab, lab, PREV_INSN (q));
+ reorder_insns (label, label, PREV_INSN (q));
  delete_insn (table);
}
 
diff --git a/gcc/rtl.h b/gcc/rtl.h
index 7ee0b61..c84fe71 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -3038,7 +3038,7 @@ extern rtx replace_rtx (rtx, rtx, rtx, bool = false);
 extern void replace_label (rtx *, rtx, rtx, bool);
 extern void replace_label_in_insn (rtx_insn *, rtx, rtx, bool);
 extern bool rtx_referenced_p (const_rtx, const_rtx);
-extern bool tablejump_p (const rtx_insn *, rtx *, rtx_jump_table_data **);
+extern bool tablejump_p (const rtx_insn *, rtx_insn **, rtx_jump_table_data 
**);
 extern int computed_jump_p (const rtx_insn *);
 extern bool tls_referenced_p (const_rtx);
 
diff --git a/gcc/rtlanal.c b/gcc/rtlanal.c
index 90b55b6..4e600c0 100644
--- a/gcc/rtlanal.c
+++ b/gcc/rtlanal.c
@@ -3103,26 +3103,26 @@ rtx_referenced_p (const_rtx x, const_rtx body)
*LABELP and the jump table to *TABLEP.  LABELP and TABLEP may be NULL.  */
 
 bool
-tablejump_p (const rtx_insn *insn, rtx *labelp, rtx_jump_table_data **tablep)
+tablejump_p (const rtx_insn *insn, rtx_insn **labelp,
+rtx_jump_table_data **tablep)
 {
-  rtx label;
-  rtx_insn *table;
-
   if (!JUMP_P (insn))
 return false;
 
-  label = JUMP_LABEL (insn);
-  if (label != NULL_RTX && !ANY_RETURN_P (label)
-  && (table = NEXT_INSN (as_a  (label))) != NULL_RTX
-  && JUMP_TABLE_DATA_P (table))
-{
-  if (labelp)
-   *labelp = label;
-  if (tablep)
-   *tablep = as_a  (table);
-  return true;
-}
-  return false;
+  rtx target = JUMP_LABEL (insn);
+  if (target == NULL_RTX || ANY_RETURN_P (target))
+return false;
+
+  rtx_insn *label = as_a (target);
+  rtx_insn *table = next_insn (label);
+  if 

[PATCH 4/7] remove cast to rtx_insn * in remove_note

[tbsaunde+gcc]

From: Trevor Saunders 

gcc/ChangeLog:

2016-10-17  Trevor Saunders  

* config/rl78/rl78.c (gen-and_emit_move): Change argument type
to rtx_insn *.
(transcode_memory_rtx): Likewise.
(move_to_acc): Likewise.
(move_from_acc): Likewise.
(move_acc_to_reg): Likewise.
(move_to_x): Likewise.
(move_to_hl): Likewise.
(move_to_de): Likewise.
* config/rs6000/rs6000.c (emit_frame_save): Likewise.
(rs6000_emit_savres_rtx): Likewise.
(rs6000_emit_prologue): Likewise.
* reorg.c (update_reg_unused_notes): Likewise.
* rtl.h (remove_note): Adjust prototype.
* rtlanal.c (remove_note): Make argument type rtx_insn *.
---
 gcc/config/rl78/rl78.c | 16 
 gcc/config/rs6000/rs6000.c | 26 ++
 gcc/reorg.c|  4 ++--
 gcc/rtl.h  |  2 +-
 gcc/rtlanal.c  |  4 ++--
 5 files changed, 27 insertions(+), 25 deletions(-)

diff --git a/gcc/config/rl78/rl78.c b/gcc/config/rl78/rl78.c
index fd72a58..db3e25f 100644
--- a/gcc/config/rl78/rl78.c
+++ b/gcc/config/rl78/rl78.c
@@ -2778,7 +2778,7 @@ process_postponed_content_update (void)
after WHERE.  If TO already contains FROM then do nothing.  Returns TO if
BEFORE is true, FROM otherwise.  */
 static rtx
-gen_and_emit_move (rtx to, rtx from, rtx where, bool before)
+gen_and_emit_move (rtx to, rtx from, rtx_insn *where, bool before)
 {
   machine_mode mode = GET_MODE (to);
 
@@ -2833,7 +2833,7 @@ gen_and_emit_move (rtx to, rtx from, rtx where, bool 
before)
copy it into NEWBASE and return the updated MEM.  Otherwise just
return M.  Any needed insns are emitted before BEFORE.  */
 static rtx
-transcode_memory_rtx (rtx m, rtx newbase, rtx before)
+transcode_memory_rtx (rtx m, rtx newbase, rtx_insn *before)
 {
   rtx base, index, addendr;
   int addend = 0;
@@ -2934,7 +2934,7 @@ transcode_memory_rtx (rtx m, rtx newbase, rtx before)
 /* Copy SRC to accumulator (A or AX), placing any generated insns
before BEFORE.  Returns accumulator RTX.  */
 static rtx
-move_to_acc (int opno, rtx before)
+move_to_acc (int opno, rtx_insn *before)
 {
   rtx src = OP (opno);
   machine_mode mode = GET_MODE (src);
@@ -2968,7 +2968,7 @@ force_into_acc (rtx src, rtx_insn *before)
 /* Copy accumulator (A or AX) to DEST, placing any generated insns
after AFTER.  Returns accumulator RTX.  */
 static rtx
-move_from_acc (unsigned int opno, rtx after)
+move_from_acc (unsigned int opno, rtx_insn *after)
 {
   rtx dest = OP (opno);
   machine_mode mode = GET_MODE (dest);
@@ -2982,7 +2982,7 @@ move_from_acc (unsigned int opno, rtx after)
 /* Copy accumulator (A or AX) to REGNO, placing any generated insns
before BEFORE.  Returns reg RTX.  */
 static rtx
-move_acc_to_reg (rtx acc, int regno, rtx before)
+move_acc_to_reg (rtx acc, int regno, rtx_insn *before)
 {
   machine_mode mode = GET_MODE (acc);
   rtx reg;
@@ -2995,7 +2995,7 @@ move_acc_to_reg (rtx acc, int regno, rtx before)
 /* Copy SRC to X, placing any generated insns before BEFORE.
Returns X RTX.  */
 static rtx
-move_to_x (int opno, rtx before)
+move_to_x (int opno, rtx_insn *before)
 {
   rtx src = OP (opno);
   machine_mode mode = GET_MODE (src);
@@ -3018,7 +3018,7 @@ move_to_x (int opno, rtx before)
 /* Copy OP (opno) to H or HL, placing any generated insns before BEFORE.
Returns H/HL RTX.  */
 static rtx
-move_to_hl (int opno, rtx before)
+move_to_hl (int opno, rtx_insn *before)
 {
   rtx src = OP (opno);
   machine_mode mode = GET_MODE (src);
@@ -3041,7 +3041,7 @@ move_to_hl (int opno, rtx before)
 /* Copy OP (opno) to E or DE, placing any generated insns before BEFORE.
Returns E/DE RTX.  */
 static rtx
-move_to_de (int opno, rtx before)
+move_to_de (int opno, rtx_insn *before)
 {
   rtx src = OP (opno);
   machine_mode mode = GET_MODE (src);
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 613af48..b5f1dc9 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -26805,8 +26805,8 @@ output_probe_stack_range (rtx reg1, rtx reg2)
pointer.  That fails when saving regs off r1, and sched moves the
r31 setup past the reg saves.  */
 
-static rtx
-rs6000_frame_related (rtx insn, rtx reg, HOST_WIDE_INT val,
+static rtx_insn *
+rs6000_frame_related (rtx_insn *insn, rtx reg, HOST_WIDE_INT val,
  rtx reg2, rtx repl2)
 {
   rtx repl;
@@ -26970,11 +26970,11 @@ gen_frame_store (rtx reg, rtx frame_reg, int offset)
 /* Save a register into the frame, and emit RTX_FRAME_RELATED_P notes.
Save REGNO into [FRAME_REG + OFFSET] in mode MODE.  */
 
-static rtx
+static rtx_insn *
 emit_frame_save (rtx frame_reg, machine_mode mode,
 unsigned int regno, int offset, HOST_WIDE_INT frame_reg_to_sp)
 {
-  rtx reg, insn;
+  rtx reg;
 
   /* Some cases that need register indexed addressing.  */
   

[PATCH 0/7] more rtx-insn stuff

[tbsaunde+gcc]

From: Trevor Saunders 

Hi,

Rather late (travel and then busy day job interfiered), but this includes the
promised conversion of LABEL_REF_LABEL and tablejump_p to use rtx_insn *.  
Followed by a bit more random conversion of things to use rtx_insn *.

patches individually bootstrapped + regtested on x86_64-linux-gnu, and run
through config-list.mk as a whole.  Ok?

Thanks!

Trev

Trevor Saunders (7):
  make LABEL_REF_LABEL a rtx_insn *
  make tablejump_p return the label as a rtx_insn *
  use rtx_insn * more
  remove cast to rtx_insn * in remove_note
  remove cast in delete_insn_chain
  remove cast from prev_nonnote_insn_bb
  make targetm.gen_ccmp{first,next} take rtx_insn **

 gcc/alias.c  |   2 +-
 gcc/ccmp.c   |  21 
 gcc/cfgbuild.c   |   4 +-
 gcc/cfgcleanup.c |   8 +--
 gcc/cfgexpand.c  |   2 +-
 gcc/cfgrtl.c |  17 +++
 gcc/cfgrtl.h |   2 +-
 gcc/combine.c|   4 +-
 gcc/config/aarch64/aarch64.c |  10 ++--
 gcc/config/alpha/alpha.c | 117 ++-
 gcc/config/arc/arc.c |   3 +-
 gcc/config/arm/arm.c |   9 ++--
 gcc/config/bfin/bfin.c   |   7 +--
 gcc/config/c6x/c6x.c |   9 ++--
 gcc/config/frv/frv.c |   2 +-
 gcc/config/i386/i386.c   |   3 +-
 gcc/config/ia64/ia64.c   |   4 +-
 gcc/config/m32c/m32c.c   |   4 +-
 gcc/config/mips/mips.c   |  61 +++---
 gcc/config/mn10300/mn10300.c |   2 +-
 gcc/config/rl78/rl78.c   |  18 +++
 gcc/config/rs6000/rs6000.c   |  26 +-
 gcc/config/s390/s390.c   |   7 +--
 gcc/config/sh/sh-mem.cc  |   8 +--
 gcc/config/sh/sh.md  |  18 +++
 gcc/cse.c|  20 
 gcc/cselib.c |   4 +-
 gcc/doc/tm.texi  |   4 +-
 gcc/emit-rtl.c   |   9 ++--
 gcc/except.c |   2 +-
 gcc/explow.c |   2 +-
 gcc/final.c  |   8 +--
 gcc/gcse.c   |   6 +--
 gcc/genconfig.c  |   4 +-
 gcc/genrecog.c   |   4 +-
 gcc/ifcvt.c  |   8 +--
 gcc/jump.c   |  22 
 gcc/lra-constraints.c|   2 +-
 gcc/optabs.c |   5 +-
 gcc/print-rtl.c  |   2 +-
 gcc/reload.c |  12 ++---
 gcc/reload1.c|  15 +++---
 gcc/reorg.c  |  29 ++-
 gcc/rtl-tests.c  |   2 +-
 gcc/rtl.c|   4 +-
 gcc/rtl.h|  17 +--
 gcc/rtlanal.c|  42 
 gcc/target.def   |   4 +-
 gcc/varasm.c |  20 
 49 files changed, 316 insertions(+), 299 deletions(-)

-- 
2.9.3

[Bug c++/78014] New: -Wformat -vs- size_t

[tromey at gcc dot gnu.org]

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

Bug ID: 78014
   Summary: -Wformat -vs- size_t
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

Compile this test program with -Wformat:

#include 

int main() {
  size_t x = 0;

  printf("got %lu\n", x);
}

I expected this to give a warning, because the correct format should
be %zu.  %lu happens to be correct on this machine, but on a 32-bit
machine it is not.

Re: [Patch 3/11] Implement TARGET_C_EXCESS_PRECISION for s390

[Andreas Krebbel1]

> Here is a patch implementing what I think has been discussed in this 
thread.
> 
> OK?

Looks good to me.

Uli, do you agree with that change for S/390 or would you rather see us 
fixing the float_t type definition in Glibc?

-Andreas-

Re: [PATCH 1/2] Fix GCC split-stack variadic argument tests

[Jeff Law]

On 10/17/2016 01:12 PM, Adhemerval Zanella wrote:

This test adds the expect va_end after va_start on split-stack tests.

gcc/ChangeLog:

* gcc/testsuite/gcc.dg/split-3.c (down): Call va_end after va_start.
* gcc/testsuite/gcc.dg/split-6.c (down): Likewise.

OK.  Would probably fall under the obvious rule.
jeff

Re: [PATCH] Extend -Wint-in-bool-context to suspicious enum values (PR 77700)

[Jeff Law]

On 10/08/2016 04:50 PM, Trevor Saunders wrote:

On Fri, Oct 07, 2016 at 03:18:07PM +, Bernd Edlinger wrote:

Hi!

This extends -Wint-in-bool-context to uses of enum values in boolean
context, and fixes one place where accidentally an enum value was
passed to a bool parameter.

I excluded enum values 0 and 1 because that is used in
gimple-ssa-strength-reduction.c, where we have enums
which are passed in bool function arguments:

enum stride_status
{
   UNKNOWN_STRIDE = 0,
   KNOWN_STRIDE = 1
};

enum phi_adjust_status
{
   NOT_PHI_ADJUST = 0,
   PHI_ADJUST = 1
};

enum count_phis_status
{
   DONT_COUNT_PHIS = 0,
   COUNT_PHIS = 1
};

I would'nt use an enum in that way, but I think it is
at least not completely wrong to do it like that...


Using enums here seems reasonable see the discussion here
http://gcc.gnu.org/ml/gcc/2016-10/msg6.html however I don't
understand why that code makes the argument type bool instead of the
enum type.  Here's an untested patch to change those functions to take
the enum type.  It might make sense to change naming some, but I think
this is somewhat of an improvement as it is.

Trev

diff --git a/gcc/gimple-ssa-strength-reduction.c 
b/gcc/gimple-ssa-strength-reduction.c
index 7b14b91..f61805c 100644
--- a/gcc/gimple-ssa-strength-reduction.c
+++ b/gcc/gimple-ssa-strength-reduction.c

[ ... ]
Seems reasonable.  Feel free to commit after the usual testing.

jeff

Re: [PATCH][2/2] Enable SSA propagator "DCE" for VRP

[Jeff Law]

On 10/12/2016 01:08 AM, Richard Biener wrote:

On Fri, 7 Oct 2016, Richard Biener wrote:



This turns the switch (which also requires propagating into ASSERT_EXPRs,
otherwise those will end up with released SSA names eventually).

A [3/2] would be to let ASSERT_EXPRs be removed by the propagator
which would a) require VRP to fix up its lattice for this task,
b) make match-and-simplify not be confused by them during
substitute-and-fold folding.  This also requires (I think) dealing
with symbolic valueizations during substitute-and-fold in a
way FRE does (track availability) -- currently propagators restrict
themselves to constants due to that (avoid substituting to where
the use does not dominate the definition).

Re-bootstrap / regtest pending on x86_64-unknown-linux-gnu.


The following is what I have applied -- for now we can't DCE ASSERT_EXPRs
because VRP jump threading relies on them (in fact, it looks like VRPs
jump threading "implementation" is nothing but backwards threading,
looking for ASSERT_EXPRs rather than dominating conditions ... Jeff,
you may be more familiar with the VRP threading code, it looks like
we might be able to rip it out without regressions?)
That'd be the one I'd want to see ripped out first as it's the least 
"interesting" lot term.  I haven't actually tried it though.


I can't remember all the details anymore, but there was some major 
headaches around sequencing threading into VRP.  IIRC we use two things 
from VRP.  First the threader knows that an ASSERT_EXPR is just a copy. 
Second, it uses the range information via the callback and I believe it 
can use those together.


In today's world where range information has become a first class 
citizen, there's a reasonable chance that we could drop the ASSERT_EXPRs 
from the IL and just query the range information.  However, I suspect 
we'll see regressions as range information is often lost (the same issue 
Aldy, Martin and Andrew have poked at recently).


But it's certainly worth investigation.

jeff

[Bug c++/77656] 64-bit integral template parameter gets incorrectly sized as 32-bits

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #1)
> Perhaps tsubst of TEMPLATE_PARM_INDEX instead of just
> return convert_from_reference (unshare_expr (arg));
> also convert it to the TEMPLATE_PARM_INDEX's type (if it is integral type
> only, or when?)?

That would work, but the arg ought to already have the right type from
convert_nontype_argument.  I'll take a look.

Re: [PATCH, C++] Warn on redefinition of builtin functions (PR c++/71973)

[Bernd Edlinger]

On 10/17/16 20:05, Joseph Myers wrote:
> On Sun, 16 Oct 2016, Bernd Edlinger wrote:
>
>> Second, the declaration in the glibc header files simply look wrong,
>> because the type of argv, and envp is "char *const *" while the
>> builtin function wants "const char**", thus only the array of char*
>> itself is const, not the actual char stings they point to.
>
> char *const * is the POSIX type.  (It can't be const char ** or const char
> *const * because you can't convert char ** implicitly to those types in
> ISO C.)  You'd need to check the list archives for rationale for the
> built-in functions doing something different.
>

Yes, that was discussed here:
https://gcc.gnu.org/ml/gcc-patches/2004-03/msg01148.html

No mention why the BT_PTR_CONST_TYPE does not match the posix type.
But the right types were used on __gcov_execv/e/p stubs, so the author
did know the right types at least.

So I think that was broken from the beginning, but that was hidden by
the loose checking in the C FE and not warning in the C++ FE when
prototypes don't match.

>> Third, in C the  builtins are not diagnosed, because C does only look
>> at the mode of the parameters see match_builtin_function_types in
>> c/c-decl.c, which may itself be wrong, because that makes an ABI
>> decision dependent on the mode of the parameter.
>
> The matching needs to be loose because of functions using types such as
> FILE * where the compiler doesn't know the exact contents of the type when
> processing built-in function definitions.  (Historically there were also
> issues with pre-ISO headers, but that may be less relevant now.)
>

The C++ FE has exactly the same problem with FILE* and struct tm*
but it solves it differently and "learns" the type but only for FILE*
and with this patch also for const struct tm*.  It is a lot more
restrictive than C, but that is because of the ++ ;)

Well in that case the posix functions have to use the prototypes
from POSIX.1.2008 although their rationale is a bit silly...

This updated patch fixes the prototype of execv/p/e,
and adds a new test case that checks that no type conflict
exists in the execve built-in any more.

Now we have no -Wsystem-headers warnings with glibc-headers any more.
And the gcov builtin also is working with C++.

Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
gcc:
2016-10-17  Bernd Edlinger  

PR c++/71973
* doc/invoke.texi: Document -Wbuiltin-function-redefined.
* builtin-types.def (BT_CONST_TM_PTR): New primitive type.
(BT_PTR_CONST_STRING): Updated.
(BT_FN_SIZE_STRING_SIZE_CONST_STRING_CONST_PTR): Removed.
(BT_FN_SIZE_STRING_SIZE_CONST_STRING_CONST_TM_PTR): New function type.
* builtins.def (strftime): Update builtin function.
* tree-core.h (TI_CONST_TM_PTR_TYPE): New enum value.
* tree.h (const_tm_ptr_type_node): New type node.
* tree.c (free_lang_data, build_common_tree_nodes): Initialize
const_tm_ptr_type_node.

c-family:
2016-10-17  Bernd Edlinger  

PR c++/71973
* c.opt (Wbuiltin-function-redefined): New warning.
* c-common.c (c_common_nodes_and_builtins): Initialize
const_tm_ptr_type_node.

cp:
2016-10-17  Bernd Edlinger  

PR c++/71973
* decl.c (duplicate_decls): Warn when a built-in function is redefined.
Don't overload builtin functions with C++ functions.
Handle const_tm_ptr_type_node like file_ptr_node.
Copy the TREE_NOTHROW flag unmodified to the old decl.

lto:
2016-10-17  Bernd Edlinger  

PR c++/71973
* lto-lang.c (lto_init): Assert const_tm_ptr_type_node is sane.

testsuite:
2016-10-17  Bernd Edlinger  

PR c++/71973
* g++.dg/pr71973-1.C: New test.
* g++.dg/pr71973-2.C: New test.
* g++.dg/pr71973-3.C: New test.
* g++.dg/lookup/extern-c-redecl4.C: Adjust test expectations.
Index: gcc/builtin-types.def
===
--- gcc/builtin-types.def	(revision 241271)
+++ gcc/builtin-types.def	(working copy)
@@ -103,6 +103,7 @@ DEF_PRIMITIVE_TYPE (BT_COMPLEX_LONGDOUBLE, complex
 
 DEF_PRIMITIVE_TYPE (BT_PTR, ptr_type_node)
 DEF_PRIMITIVE_TYPE (BT_FILEPTR, fileptr_type_node)
+DEF_PRIMITIVE_TYPE (BT_CONST_TM_PTR, const_tm_ptr_type_node)
 DEF_PRIMITIVE_TYPE (BT_CONST_PTR, const_ptr_type_node)
 DEF_PRIMITIVE_TYPE (BT_VOLATILE_PTR,
 		build_pointer_type
@@ -146,7 +147,12 @@ DEF_PRIMITIVE_TYPE (BT_I16, builtin_type_for_size
 
 DEF_PRIMITIVE_TYPE (BT_BND, pointer_bounds_type_node)
 
-DEF_POINTER_TYPE (BT_PTR_CONST_STRING, BT_CONST_STRING)
+/* The C type `char * const *'.  */
+DEF_PRIMITIVE_TYPE (BT_PTR_CONST_STRING,
+		build_pointer_type
+		 (build_qualified_type (string_type_node,
+	TYPE_QUAL_CONST)))
+
 DEF_POINTER_TYPE 

[PATCH v3 2/2] aarch64: Add split-stack initial support

[Adhemerval Zanella]

From: Adhemerval Zanella 

Changes from previous version:

 * Add missing new function comments;
 * Using gen_rtx_fmt_ee instead of gen_rtx_IF_THEN_ELSE to create
   conditional jumps;
 * Some typos and withspace issues.

--

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 in adjusted
(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:
mov x10, sp
[...]
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.

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 (split_stack_arg_pointer_used_p): New
function.
(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.
(morestack_ref): New symbol.
(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_EXTRA_LIVE_ON_ENTRY): Likewise.
(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/config/aarch64/aarch64.md (UNSPEC_STACK_CHECK): New unspec.
(UNSPECV_SPLIT_STACK_RETURN): Likewise.

[PATCH 1/2] Fix GCC split-stack variadic argument tests

[Adhemerval Zanella]

This test adds the expect va_end after va_start on split-stack tests.

gcc/ChangeLog:

* gcc/testsuite/gcc.dg/split-3.c (down): Call va_end after va_start.
* gcc/testsuite/gcc.dg/split-6.c (down): Likewise.
---
 gcc/ChangeLog  | 5 +
 gcc/testsuite/gcc.dg/split-3.c | 1 +
 gcc/testsuite/gcc.dg/split-6.c | 1 +
 3 files changed, 7 insertions(+)

diff --git a/gcc/testsuite/gcc.dg/split-3.c b/gcc/testsuite/gcc.dg/split-3.c
index 64bbb8c..5ba7616 100644
--- a/gcc/testsuite/gcc.dg/split-3.c
+++ b/gcc/testsuite/gcc.dg/split-3.c
@@ -40,6 +40,7 @@ down (int i, ...)
   || va_arg (ap, int) != 9
   || va_arg (ap, int) != 10)
 abort ();
+  va_end (ap);
 
   if (i > 0)
 {
diff --git a/gcc/testsuite/gcc.dg/split-6.c b/gcc/testsuite/gcc.dg/split-6.c
index b32cf8d..b3016ba 100644
--- a/gcc/testsuite/gcc.dg/split-6.c
+++ b/gcc/testsuite/gcc.dg/split-6.c
@@ -37,6 +37,7 @@ down (int i, ...)
   || va_arg (ap, int) != 9
   || va_arg (ap, int) != 10)
 abort ();
+  va_end (ap);
 
   if (i > 0)
 {
-- 
2.7.4

Re: PATCH to tidy up code in c-warn.c

[Jeff Law]

On 10/16/2016 04:53 AM, Marek Polacek wrote:

Found when looking at something else.  find_array_ref_with_const_idx_r would
uselessly keep on looking for other array refs with constant indices, even
though finding one is enough.  So return when something is found, instead of
just ignoring the subtrees.

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

2016-10-16  Marek Polacek  

* c-warn.c (find_array_ref_with_const_idx_r): Remove parameter names.
Return immediately when finding a match.
(warn_tautological_cmp): Remove a boolean variable that is no longer
needed.

OK.
jeff

Re: [PATCH] fix outstanding -Wformat-length failures (pr77735 et al.)

[Jeff Law]

On 10/02/2016 02:10 PM, Martin Sebor wrote:

The attached patch fixes a number of outstanding test failures
and ILP32-related bugs in the gimple-ssa-sprintf pattch pointed
out in bug 77676 and 77735).  The patch also fixes c_strlen to
correctly handle wide strings (previously it accepted them but
treated them as nul-terminated byte sequences), and adjusts the
handling of "%a" to avoid assuming a specific number of decimal
digits (this is likely a defect in C11 that I'm pursuing with
WG14).

Tested on powerpc64le, i386, and x86_64.

There is one outstanding failure in the builtin-sprintf-warn-1.c
test on powerpc64le that looks like it might be due to the
printf_pointer_format target hook not having been set up entirely
correctly.  I'll look into that separately, along with pr77819.

Martin

gcc-77735.diff


PR middle-end/77735 - FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c

gcc/ChangeLog:
2016-10-02  Martin Sebor  

PR middle-end/77735
* builtins.c (string_length): New function.
(c_strlen): Use string_length.  Correctly handle wide strings.
* gimple-ssa-sprintf.c (target_max_value, target_size_max): New
functions.
(target_int_max): Call target_max_value.
(format_result::knownrange): New data member.
(fmtresult::fmtresult): Define default constructor.
(format_integer): Use it and set format_result::knownrange.
Handle global constants.
(format_floating_max): Add third argument.
(format_floating): Recompute maximum value for %a for each argument.
(get_string_length): Use fmtresult default ctor.
(format_string): Set format_result::knownrange.
(format_directive): Check format_result::knownrange.
(add_bytes): Same.  Correct caret placement in diagnostics.
(pass_sprintf_length::compute_format_length): Set
format_result::knownrange.
(pass_sprintf_length::handle_gimple_call): Use target_size_max.

gcc/testsuite/ChangeLog:
2016-10-02  Martin Sebor  

PR middle-end/77735
* gcc.dg/tree-ssa/builtin-sprintf-2.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-2.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Adjust/relax.
* gcc.dg/tree-ssa/builtin-sprintf-warn-4.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-6.c: XFAIL for LP64 only.
* gcc.dg/tree-ssa/builtin-sprintf.c: Add test cases.

diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 92f939e..410bbc3 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -1281,9 +1330,9 @@ format_floating (const conversion_spec , int width, 
int prec)
res.range.max = width;
 }

-  /* The argument is only considered bounded when the range of output
- bytes is exact.  */
-  res.bounded = res.range.min == res.range.max;
+  /* The argument is considered bounded when the output of a directive
+ is fully specified and the range of output bytes is exact.  */
+  // res.bounded &= res.range.min == res.range.max;

Did you mean to leave this commented out?

It looks like you're defining a constructor for "struct fmtresult". 
Normally once we define a constructor we turn the underlying object into 
a class.It appears that the constructor leaves argmin, argmax, 
knownrange, bounded & constant uninitialized?  Am I missing something here?




+ /* A plain '%c' directive.  Its ouput is excactly 1.  */

Typo for exactly.


Jeff

Re: Who played with the GCC Bugzilla git repo?

[Frank Ch. Eigler]

Frédéric Buclin  writes:

> Someone played with the GCC Bugzilla git repo last week with no real reason:
> Author: root 
> Date:   Fri Oct 7 15:28:43 2016 +
> snap-data
> [...]

That was little old me, with the reason being to conserve local changes
with version control.

> Looks like the goal was to drop all CSS and JS files in data/assets/.

No, I believe there was some other sourceware-oriented customization in
there, but I forget the details.

> [...]  Moreover, this means that the GCC Bugzilla git repo is no
> longer in sync with the upstream Bugzilla git repo, because the one
> who played with git also committed my local changes (I didn't do it
> for a reason). I can no longer view my local changes, nor can I easily
> sync both repos with a fast-forward merge (I think). [...]

That's just a matter of tracking upstream bugzilla on one branch, and
the sourceware installation of bugzilla on another branch, and merging
from the former into the latter periodically.  I renamed "5.0" to
"5.0-sourceware", and recreated the "5.0" branch to assist this.

- FChE

Re: [PATCH] AIX symbol encoding

[Segher Boessenkool]

Hi David,

On Mon, Oct 17, 2016 at 09:54:35AM -0400, David Edelsohn wrote:
> This patch shifts earlier the point during compilation where the
> rs6000 backend adds decoration to symbols: to encode_section_info.

> -  /* Currently C++ toc references to vtables can be emitted before it
> - is decided whether the vtable is public or private.  If this is
> - the case, then the linker will eventually complain that there is
> - a reference to an unknown section.  Thus, for vtables only,
> - we emit the TOC reference to reference the symbol and not the
> - section.  */

I think this comment should go...

>if (VTABLE_NAME_P (name))
>  {
>RS6000_OUTPUT_BASENAME (file, name);

... before here.

Otherwise looks fine.  Do you want this tested on Linux before you
commit?  We never test on AIX beforehand either ;-)


Segher

[Bug libstdc++/77987] [6/7 Regression] unique_ptr<T[]> reset rejects cv-compatible pointers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||5.4.0
 Resolution|--- |FIXED
   Target Milestone|--- |6.3
Summary|unique_ptr reset   |[6/7 Regression]
   |rejects cv-compatible   |unique_ptr reset
   |pointers|rejects cv-compatible
   ||pointers
  Known to fail||6.2.0, 7.0

--- Comment #5 from Jonathan Wakely  ---
Fixed for 6.3

[Bug libstdc++/77987] unique_ptr<T[]> reset rejects cv-compatible pointers

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Mon Oct 17 18:21:26 2016
New Revision: 241276

URL: https://gcc.gnu.org/viewcvs?rev=241276=gcc=rev
Log:
PR77987 Fix unique_ptr::reset(U) for T != U

PR libstdc++/77987
* include/bits/unique_ptr.h (unique_ptr::reset(U)): Copy
value to pointer of the correct type to swap, to support conversions
allowed by LWG 2118 / N4089.
* testsuite/20_util/unique_ptr/assign/assign_neg.cc: Move test for
incompatible deleters from ...
* testsuite/20_util/unique_ptr/assign/cv_qual.cc: ... here.
* testsuite/20_util/unique_ptr/modifiers/cv_qual.cc: Move tests for
incompatible pointers to ...
* testsuite/20_util/unique_ptr/modifiers/reset_neg.cc: ... here. Move
destructor definition to base class. Test for invalid derived-to-base
conversion.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/bits/unique_ptr.h
   
branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/unique_ptr/assign/assign_neg.cc
   
branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/unique_ptr/assign/cv_qual.cc
   
branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/unique_ptr/modifiers/cv_qual.cc
   
branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/unique_ptr/modifiers/reset_neg.cc

Re: [PATCH AArch64]Penalize vector cost for large loops with too many vect insns.

[Bill Schmidt]

> On Oct 17, 2016, at 12:26 PM, Bin.Cheng  wrote:
> 
> On Sat, Oct 15, 2016 at 3:07 AM, kugan
>  wrote:
>> Hi Bin,
>> 
>> On 15/10/16 00:15, Bin Cheng wrote:
>>> 
>>> +/* Test for likely overcommitment of vector hardware resources.  If a
>>> +   loop iteration is relatively large, and too large a percentage of
>>> +   instructions in the loop are vectorized, the cost model may not
>>> +   adequately reflect delays from unavailable vector resources.
>>> +   Penalize the loop body cost for this case.  */
>>> +
>>> +static void
>>> +aarch64_density_test (struct aarch64_vect_loop_cost_data *data)
>>> +{
>>> +  const int DENSITY_PCT_THRESHOLD = 85;
>>> +  const int DENSITY_SIZE_THRESHOLD = 128;
>>> +  const int DENSITY_PENALTY = 10;
>>> +  struct loop *loop = data->loop_info;
>>> +  basic_block *bbs = get_loop_body (loop);
>> 
>> 
>> Is this worth being part of the cost model such that it can have different
>> defaults for different micro-architecture?
> Hi,
> I don't know.  From my running, this penalizing function looks like a
> quite benchmark specific tuning.  If that's the case, tuning for
> different micro architecture may not give meaningful different
> results, at the cost of three parameters.
> Hi Bill,  I guess you are the original author?  Do you recall any
> motivation of this code or have some comments?  Thanks very much.
> Meanwhile, I can do some experiments on different AArch64 processors.

Hi Bin,

Yes, this is specific tuning due to problems observed on a
POWER model.  I don't necessarily recommend this approach for
other architectures without appropriate experimental verification
and tuning.

Bill

> 
> Thanks,
> bin
> 

Re: [PATCH/AARCH64] Fix some testcases for AARCH64 ILP32

[Andrew Pinski]

On Mon, Oct 17, 2016 at 2:55 AM, Richard Earnshaw (lists)
 wrote:
> On 16/10/16 22:39, Andrew Pinski wrote:
>> Hi,
>>   These testcases use long for 64bit integer which means they will
>> fail with -mabi=ilp32 on aarch64.  This reduces the number of failures
>> down for ILP32.
>>
>> OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions
>> (including with a multi-lib for ilp32).
>>
>> Thanks,
>> Andrew Pinski
>>
>> testsuite/ChangeLog:
>> * gcc.dg/tree-ssa/sra-17.c: Use long long instead of long.
>> * gcc.dg/tree-ssa/sra-18.c: Likewise.
>
> This changes the behaviour for these two tests on ARM, which is a 32-bit
> target.  What testing other than aarch64 have you done?   I'd like to
> see testing results for both 32-bit and 64-bit (including non-arm) systems.
>
>> * gcc.target/aarch64/aapcs64/test_align-7.c: Likewise.
>> * gcc.target/aarch64/cinc_common_1.c: Likewise.
>> * gcc.target/aarch64/combine_bfi_1.c: Likewise.
>> * gcc.target/aarch64/fmul_fcvt_1.c: Likewise.
>> * gcc.target/aarch64/mult-synth_4.c: Likewise.
>> * gcc.target/aarch64/pr68102_1.c: Likewise.
>> * gcc.target/aarch64/target_attr_3.c: Likewise.
>
> These are OK.

I committed the gcc.target changes and will be looking into
sra-17/sra-18 issue later this week.

Thanks,
Andrew

>
>>
>>
>> fixsometestcases.diff.txt
>>
>>
>> Index: testsuite/gcc.dg/tree-ssa/sra-17.c
>> ===
>> --- testsuite/gcc.dg/tree-ssa/sra-17.c(revision 241217)
>> +++ testsuite/gcc.dg/tree-ssa/sra-17.c(working copy)
>> @@ -7,7 +7,7 @@ extern void abort (void);
>>  int
>>  main (int argc, char **argv)
>>  {
>> -  long a[4] = { 7, 19, 11, 255 };
>> +  long long a[4] = { 7, 19, 11, 255 };
>>int tot = 0;
>>for (int i = 0; i < 4; i++)
>>  tot = (tot*256) + a[i];
>> Index: testsuite/gcc.dg/tree-ssa/sra-18.c
>> ===
>> --- testsuite/gcc.dg/tree-ssa/sra-18.c(revision 241217)
>> +++ testsuite/gcc.dg/tree-ssa/sra-18.c(working copy)
>> @@ -3,7 +3,7 @@
>>  /* { dg-additional-options "-mcpu=ev4" { target alpha*-*-* } } */
>>
>>  extern void abort (void);
>> -struct foo { long x; };
>> +struct foo { long long x; };
>>
>>  struct bar { struct foo f[2]; };
>>
>> Index: testsuite/gcc.target/aarch64/aapcs64/test_align-7.c
>> ===
>> --- testsuite/gcc.target/aarch64/aapcs64/test_align-7.c   (revision 
>> 241217)
>> +++ testsuite/gcc.target/aarch64/aapcs64/test_align-7.c   (working copy)
>> @@ -7,8 +7,8 @@
>>
>>  struct s
>>{
>> -long x;
>> -long y;
>> +long long x;
>> +long long y;
>>};
>>
>>  /* This still has size 16, so is still passed by value.  */
>> Index: testsuite/gcc.target/aarch64/cinc_common_1.c
>> ===
>> --- testsuite/gcc.target/aarch64/cinc_common_1.c  (revision 241217)
>> +++ testsuite/gcc.target/aarch64/cinc_common_1.c  (working copy)
>> @@ -15,14 +15,14 @@ barsi (int x)
>>return x > 100 ? x + 4 : x + 3;
>>  }
>>
>> -long
>> -foodi (long x)
>> +long long
>> +foodi (long long x)
>>  {
>>return x > 100 ? x - 2 : x - 1;
>>  }
>>
>> -long
>> -bardi (long x)
>> +long long
>> +bardi (long long x)
>>  {
>>return x > 100 ? x + 4 : x + 3;
>>  }
>> Index: testsuite/gcc.target/aarch64/combine_bfi_1.c
>> ===
>> --- testsuite/gcc.target/aarch64/combine_bfi_1.c  (revision 241217)
>> +++ testsuite/gcc.target/aarch64/combine_bfi_1.c  (working copy)
>> @@ -25,8 +25,8 @@ f4 (int x, int y)
>>return (x & ~0xff) | (y & 0xff);
>>  }
>>
>> -long
>> -f5 (long x, long y)
>> +long long
>> +f5 (long long x, long long y)
>>  {
>>return (x & ~0xull) | (y & 0x);
>>  }
>> Index: testsuite/gcc.target/aarch64/fmul_fcvt_1.c
>> ===
>> --- testsuite/gcc.target/aarch64/fmul_fcvt_1.c(revision 241217)
>> +++ testsuite/gcc.target/aarch64/fmul_fcvt_1.c(working copy)
>> @@ -27,13 +27,13 @@ ulsffoo##__a (float x)\
>>  }
>>
>>  #define FUNC_DEFD(__a)   \
>> -long \
>> +long long\
>>  dffoo##__a (double x)\
>>  {\
>>return x * __a##.0;\
>>  }\
>>   \
>> -unsigned long\
>> +unsigned long long   \
>>  udffoo##__a (double x)   \
>>  {\
>>return x * __a##.0;\
>> @@ -101,18 +101,18 @@ do 
>>  \
>>__builtin_abort ();\
>>  if (usffoo##__a (__b) != (unsigned int)(__b * __a))  \
>>__builtin_abort ();\
>> -if (lsffoo##__a (__b) != (long)(__b * 

Re: [PATCH, C++] Warn on redefinition of builtin functions (PR c++/71973)

[Joseph Myers]

On Sun, 16 Oct 2016, Bernd Edlinger wrote:

> Second, the declaration in the glibc header files simply look wrong,
> because the type of argv, and envp is "char *const *" while the
> builtin function wants "const char**", thus only the array of char*
> itself is const, not the actual char stings they point to.

char *const * is the POSIX type.  (It can't be const char ** or const char 
*const * because you can't convert char ** implicitly to those types in 
ISO C.)  You'd need to check the list archives for rationale for the 
built-in functions doing something different.

> Third, in C the  builtins are not diagnosed, because C does only look
> at the mode of the parameters see match_builtin_function_types in
> c/c-decl.c, which may itself be wrong, because that makes an ABI
> decision dependent on the mode of the parameter.

The matching needs to be loose because of functions using types such as 
FILE * where the compiler doesn't know the exact contents of the type when 
processing built-in function definitions.  (Historically there were also 
issues with pre-ISO headers, but that may be less relevant now.)

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

Re: [patch] Fix ICE on ACATS test for Aarch64 at -O

[Jeff Law]

On 10/03/2016 09:45 AM, Eric Botcazou wrote:

Ping: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01781.html


2016-09-26  Eric Botcazou  

* expmed.c (expand_shift_1): Add MAY_FAIL parameter and do not assert
that the result is non-zero if it is true.
(maybe_expand_shift): New wrapper around expand_shift_1.
(emit_store_flag): Call maybe_expand_shift in lieu of expand_shift.



OK.  Sorry for the delay.

jeff

[PATCH] PR77895: DWARF: Emit DW_AT_comp_dir in all cases, even if source is an absolute path

[Ximin Luo]

(Please keep me on CC, I am not subscribed)

In working on another patch for DW_AT_comp_dir behaviour, I tried to write a
test for that other patch. This test did not work as expected - DW_AT_comp_dir
was not even generated in the resulting output! But this had nothing to do with
my patch so I dug a bit deeper.

It turns out that GCC does not emit DW_AT_comp_dir if the source path given is
an absolute path, and the file being compiled contains a typedef to a compiler
builtin (sorry, I don't know the terminology here very well). This typedef
exists in the vast majority of cases in the real world via standard library
includes, so from the outside, the behaviour of GCC "looks like" it emits
DW_AT_comp_dir in all/most cases.

>From looking at the source code dwarf2out.c, Richard Biener determined that the
current code is written to "intend to" not emit DW_AT_comp_dir if to path is
absolute, regardless of the typedef. It is possible to "fix" this bug by a
1-line change, to conform to the way currently "intended" by GCC code. However,
I think a much better fix is a 22-line deletion of code from dwarf2out.c, to
instead emit DW_AT_comp_dir in all cases.

The original aim of not emitting DW_AT_comp_dir seems to be to avoid emitting
redundant information. However, this information is *not* redundant! The DWARF2
spec says:

"A DW_AT_comp_dir attribute whose value is a null-terminated string containing
the current working directory of the compilation command that produced this
compilation unit in whatever form makes sense for the host system."

Conceptually, the working directory is independent from an input file, so it
would *not* be redundant to emit it in the general case. In future versions of
DWARF, other information might be added (such as relative -I flags, etc) that
are dependent on knowing the working directory. The logic of "don't emit
DW_AT_comp_dir if DW_AT_name is absolute" would then break. In other words, the
choice to avoid emitting DW_AT_comp_dir is a brittle and premature optimisation
that loses information in the general case. Therefore, it is better to emit it
in all circumstances, in case the reader needs to know what the working
directory was at compile-time.

*Sometimes*, *parts* of it might be redundant yes - and rewriting DW_AT_name to
be relative to this, would remove the redundancy. Doing this is compatible with
the above points, and I could amend the patch to do this - although I suggest
it's not worth the effort, unless there is a function in GCC code that already
does this.

Some more minor advantages are:

- We delete 21 lines, this reduces complexity in the already-complex code.
  We can also get rid of the Darwin-specific workaround described here:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453 (Not currently part of my
  patch, but I can add this in.)

- The GCC test suite compiles tests via their absolute paths, and many many
  other buildsystems do this too. This was in fact my original problem - I was
  trying to test something involving DW_AT_comp_dir, but GCC does not emit this
  in the testsuite! Rather than saying "this is a bug, everyone else should
  spend effort fixing this", it is better to fix it in one place, i.e. the
  source of where it is (not) generated.

Thanks for your time,

Ximin

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
Index: gcc-7-20161009/gcc/dwarf2out.c
===
--- gcc-7-20161009.orig/gcc/dwarf2out.c
+++ gcc-7-20161009/gcc/dwarf2out.c
@@ -21994,7 +21994,7 @@ gen_compile_unit_die (const char *filena
 {
   add_name_attribute (die, filename);
   /* Don't add cwd for .  */
-  if (!IS_ABSOLUTE_PATH (filename) && filename[0] != '<')
+  if (filename[0] != '<')
 	add_comp_dir_attribute (die);
 }
 
@@ -26332,20 +26332,6 @@ prune_unused_types (void)
 prune_unmark_dies (ctnode->root_die);
 }
 
-/* Set the parameter to true if there are any relative pathnames in
-   the file table.  */
-int
-file_table_relative_p (dwarf_file_data **slot, bool *p)
-{
-  struct dwarf_file_data *d = *slot;
-  if (!IS_ABSOLUTE_PATH (d->filename))
-{
-  *p = true;
-  return 0;
-}
-  return 1;
-}
-
 /* Helpers to manipulate hash table of comdat type units.  */
 
 struct comdat_type_hasher : nofree_ptr_hash 
@@ -28152,15 +28138,7 @@ dwarf2out_early_finish (const char *file
   /* Add the name for the main input file now.  We delayed this from
  dwarf2out_init to avoid complications with PCH.  */
   add_name_attribute (comp_unit_die (), remap_debug_filename (filename));
-  if (!IS_ABSOLUTE_PATH (filename) || targetm.force_at_comp_dir)
-add_comp_dir_attribute (comp_unit_die ());
-  else if (get_AT (comp_unit_die (), DW_AT_comp_dir) == NULL)
-{
-  bool p = false;
-  file_table->traverse ();
-  if (p)
-	add_comp_dir_attribute (comp_unit_die ());
-}
+  add_comp_dir_attribute (comp_unit_die ());
 
   

[Patch, fortran] PR61420 [5/6/7 Regression] [OOP] type-bound procedure returning a procedure pointer fails to compile

[Paul Richard Thomas]

Dear All,

Committed as 'obvious' on trunk as revision 241274.

I will commit to 5- and 6-branches at the end of the week.

Cheers

Paul

2016-10-17  Paul Thomas  

PR fortran/61420
PR fortran/78013
* resolve.c (resolve_variable): Obtain the typespec for a
variable expression, when the variable is a function result
that is a procedure pointer.

2016-10-17  Paul Thomas  

PR fortran/61420
PR fortran/78013
* gfortran.dg/proc_ptr_49.f90: New test.
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c   (revision 241226)
--- gcc/fortran/resolve.c   (working copy)
*** resolve_variable (gfc_expr *e)
*** 5112,5117 
--- 5112,5122 
  
if (sym->ts.type != BT_UNKNOWN)
  gfc_variable_attr (e, >ts);
+   else if (sym->attr.flavor == FL_PROCEDURE
+  && sym->attr.function && sym->result
+  && sym->result->ts.type != BT_UNKNOWN
+  && sym->result->attr.proc_pointer)
+ e->ts = sym->result->ts;
else
  {
/* Must be a simple variable reference.  */
Index: gcc/testsuite/gfortran.dg/proc_ptr_49.f90
===
*** gcc/testsuite/gfortran.dg/proc_ptr_49.f90   (revision 0)
--- gcc/testsuite/gfortran.dg/proc_ptr_49.f90   (working copy)
***
*** 0 
--- 1,50 
+ ! { dg-do compile }
+ !
+ ! Tests the fix for PRs 78013 and 61420, both of which gave a
+ ! no IMPLICIT type message for the procedure pointer at assignment.
+ !
+ module m
+ 
+   implicit none
+ 
+   abstract interface
+ function I_f() result( r )
+   real :: r
+ end function I_f
+   end interface
+ 
+   type, abstract :: a_t
+ private
+ procedure(I_f), nopass, pointer :: m_f => null()
+   contains
+ private
+ procedure, pass(this), public :: f => get_f
+   end type a_t
+ 
+ contains
+ 
+   function get_f( this ) result( f_ptr )  ! Error message here.
+ class(a_t), intent(in)  :: this
+ procedure(I_f), pointer :: f_ptr
+ f_ptr => this%m_f ! Error here :-)
+   end function get_f
+ 
+ end module m
+ 
+ module test
+   implicit none
+ 
+   type functions
+   contains
+ procedure, nopass :: get_pf => get_it ! Error here
+   end type
+ 
+   class(functions), allocatable :: f
+ 
+ contains
+ 
+   function get_it()  ! Error message here.
+ procedure (real), pointer :: get_it
+   end function
+ 
+ end module

[Bug fortran/61420] [5/6/7 Regression] [OOP] type-bound procedure returning a procedure pointer fails to compile

[pault at gcc dot gnu.org]

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

--- Comment #11 from Paul Thomas  ---
Author: pault
Date: Mon Oct 17 17:52:05 2016
New Revision: 241274

URL: https://gcc.gnu.org/viewcvs?rev=241274=gcc=rev
Log:
2016-10-17  Paul Thomas  

PR fortran/61420
PR fortran/78013
* resolve.c (resolve_variable): Obtain the typespec for a
variable expression, when the variable is a function result
that is a procedure pointer.

2016-10-17  Paul Thomas  

PR fortran/61420
PR fortran/78013
* gfortran.dg/proc_ptr_49.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/proc_ptr_49.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/78013] unexpected 'has no IMPLICIT type' error for a type-bound function returning a procedure pointer

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas  ---
Author: pault
Date: Mon Oct 17 17:52:05 2016
New Revision: 241274

URL: https://gcc.gnu.org/viewcvs?rev=241274=gcc=rev
Log:
2016-10-17  Paul Thomas  

PR fortran/61420
PR fortran/78013
* resolve.c (resolve_variable): Obtain the typespec for a
variable expression, when the variable is a function result
that is a procedure pointer.

2016-10-17  Paul Thomas  

PR fortran/61420
PR fortran/78013
* gfortran.dg/proc_ptr_49.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/proc_ptr_49.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[edlinger at gcc dot gnu.org]

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

--- Comment #11 from Bernd Edlinger  ---
Author: edlinger
Date: Mon Oct 17 17:46:59 2016
New Revision: 241273

URL: https://gcc.gnu.org/viewcvs?rev=241273=gcc=rev
Log:
2016-10-17  Bernd Edlinger  

PR target/77308
* config/arm/arm.c (arm_emit_coreregs_64bit_shift): Clear the result
register explicitly.
* config/arm/arm.md (ashldi3, ashrdi3, lshrdi3): Don't FAIL if
optimizing for size.

testsuite:
2016-10-17  Bernd Edlinger  

PR target/77308
* gcc.target/arm/pr77308.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr77308.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.md
trunk/gcc/testsuite/ChangeLog

Re: [PATCH] Make -Wint-in-bool-context warn on suspicious shift ops

[Markus Trippelsdorf]

On 2016.10.17 at 17:30 +, Bernd Edlinger wrote:
> On 10/17/16 19:11, Markus Trippelsdorf wrote:
> >>> I'm seeing this warning a lot in valid low level C code for unsigned
> >>> integers. And I must say it look bogus in this context. Some examples:
> >
> > (All these examples are from qemu trunk.)
> >
> >>>  return ((a.high & 0x7fff) == 0x7fff) && (a.low<<1);
> >>>
> >
> > typedef struct {
> > uint64_t low;
> > uint16_t high;
> > } floatx80;
> >
> > static inline int floatx80_is_any_nan(floatx80 a)
> > {
> > return ((a.high & 0x7fff) == 0x7fff) && (a.low<<1);
> > }
> >
> >> With the shift op, the result depends on integer promotion rules,
> >> and if the value is signed, it can invoke undefined behavior.
> >>
> >> But if a.low is a unsigned short for instance, a warning would be
> >> more than justified here.
> >
> >>>  if ( (uint32_t) ( aSig<<( shiftCount & 31 ) ) ) {
> >>>
> >>
> >> Yes interesting, aSig is signed int, right?
> >
> > No, it is uint32_t.
> >
> >> So if the << will overflow, the code is invoking undefined behavior.
> >>
> >>
> >>>  && (uint64_t) (extractFloatx80Frac(a) << 1))
> >>>
> >>
> >> What is the result type of extractFloatx80Frac() ?
> >
> > static inline uint64_t extractFloatx80Frac( floatx80 a )
> >
> >>
> >>>  if ((plen < KEYLENGTH) && (key << plen))
> >>>
> >>
> >> This is from linux, yes, I have not seen that with the first
> >> version where the warning is only for signed shift ops.
> >>
> >> At first sight it looks really, like could it be that "key < plen"
> >> was meant? But yes, actually it works correctly as long
> >> as int is 32 bit, if int is 64 bits, that code would break
> >> immediately.
> >
> > u8 plen;
> > u32 key;
> >
> >> I think in the majority of code, where the author was aware of
> >> possible overflow issues and integer promotion rules, he will
> >> have used unsigned integer types, of sufficient precision.
> >
> > As I wrote above, all these warning were for unsigned integer types.
> > And all examples are perfectly valid code as far as I can see.
> >
> 
> I would be fine with disabling the warning in cases where the shift
> is done in unsigned int.  Note however, that the linux code is
> dependent on sizeof(int)<=sizeof(u32), but the warning would certainly
> be more helpful if it comes back at the day when int starts to be 64
> bits wide.
> 
> 
> How about this untested patch, does it reduce the false positive rate
> for you?

Yes, now everything is fine. Thank you.

-- 
Markus

[Bug c/77992] Provide feature to initialize padding bytes to avoid information leaks

[joseph at codesourcery dot com]

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

--- Comment #16 from joseph at codesourcery dot com  ---
Obviously any fields implicitly inserted like that must be ignored by the 
front ends when processing positional initializers - an initializer { 1, 
2, 3 } must initialize three explicitly declared fields and ignore any 
inserted padding fields between them (to be implicitly initialized with 
0).

Presumably you'd want such padding fields to be inserted for unused bits 
in the presence of bit-fields, and you'd want to make sure unnamed 
bit-fields, and bits unused as a result of an unnamed bit-field of width 
0, get properly initialized as well in the presence of such an option.

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the
[C++ PATCH] Fix -Wimplicit-fallthrough in templates (PR c++/77886)
patch:

On Sat, Oct 08, 2016 at 08:13:50AM +0200, Jakub Jelinek wrote:
> 2016-10-08  Jakub Jelinek  
> 
>   PR c++/77886
>   * pt.c (tsubst_expr)  Copy over
>   FALLTHROUGH_LABEL_P flag to the new LABEL_DECL.
>   (tsubst_expr) : Likewise.
> 
>   * g++.dg/warn/Wimplicit-fallthrough-2.C: New test.

Thanks.

Jakub

[Bug c/78000] -Wimplicit-function-declaration inhibited with macro from system headers

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
As I've said before, we have to stop doing individual ad hoc fixes for 
bugs like this; there are too many of them.  We have to work out the 
general principles for which warnings should or should not be inhibited 
for macros from system headers (roughly, the question is whether the macro 
or its user is responsible for the warning) and then design APIs that make 
it easy to get it right for each individual warning - and review existing 
warnings systematically.  Failing that, disable inhibiting such warnings 
for macros from system headers globally.

Re: [PATCH] Make -Wint-in-bool-context warn on suspicious shift ops

[Bernd Edlinger]

On 10/17/16 19:11, Markus Trippelsdorf wrote:
>>> I'm seeing this warning a lot in valid low level C code for unsigned
>>> integers. And I must say it look bogus in this context. Some examples:
>
> (All these examples are from qemu trunk.)
>
>>>  return ((a.high & 0x7fff) == 0x7fff) && (a.low<<1);
>>>
>
> typedef struct {
> uint64_t low;
> uint16_t high;
> } floatx80;
>
> static inline int floatx80_is_any_nan(floatx80 a)
> {
> return ((a.high & 0x7fff) == 0x7fff) && (a.low<<1);
> }
>
>> With the shift op, the result depends on integer promotion rules,
>> and if the value is signed, it can invoke undefined behavior.
>>
>> But if a.low is a unsigned short for instance, a warning would be
>> more than justified here.
>
>>>  if ( (uint32_t) ( aSig<<( shiftCount & 31 ) ) ) {
>>>
>>
>> Yes interesting, aSig is signed int, right?
>
> No, it is uint32_t.
>
>> So if the << will overflow, the code is invoking undefined behavior.
>>
>>
>>>  && (uint64_t) (extractFloatx80Frac(a) << 1))
>>>
>>
>> What is the result type of extractFloatx80Frac() ?
>
> static inline uint64_t extractFloatx80Frac( floatx80 a )
>
>>
>>>  if ((plen < KEYLENGTH) && (key << plen))
>>>
>>
>> This is from linux, yes, I have not seen that with the first
>> version where the warning is only for signed shift ops.
>>
>> At first sight it looks really, like could it be that "key < plen"
>> was meant? But yes, actually it works correctly as long
>> as int is 32 bit, if int is 64 bits, that code would break
>> immediately.
>
> u8 plen;
> u32 key;
>
>> I think in the majority of code, where the author was aware of
>> possible overflow issues and integer promotion rules, he will
>> have used unsigned integer types, of sufficient precision.
>
> As I wrote above, all these warning were for unsigned integer types.
> And all examples are perfectly valid code as far as I can see.
>

I would be fine with disabling the warning in cases where the shift
is done in unsigned int.  Note however, that the linux code is
dependent on sizeof(int)<=sizeof(u32), but the warning would certainly
be more helpful if it comes back at the day when int starts to be 64
bits wide.


How about this untested patch, does it reduce the false positive rate
for you?


Thanks
Bernd.

2016-10-17  Bernd Edlinger  

	* c-common.c (c_common_truthvalue_conversion): Warn only for signed
	integer shift ops in boolean context.

Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c	(revision 241270)
+++ gcc/c-family/c-common.c	(working copy)
@@ -3328,8 +3328,10 @@
 	   TREE_OPERAND (expr, 0));
 
 case LSHIFT_EXPR:
-  warning_at (EXPR_LOCATION (expr), OPT_Wint_in_bool_context,
-		  "<< in boolean context, did you mean '<' ?");
+  if (TREE_CODE (TREE_TYPE (expr)) == INTEGER_TYPE
+	  && !TYPE_UNSIGNED (TREE_TYPE (expr)))
+	warning_at (EXPR_LOCATION (expr), OPT_Wint_in_bool_context,
+		"<< in boolean context, did you mean '<' ?");
   break;
 
 case COND_EXPR:

Re: [PATCH AArch64]Penalize vector cost for large loops with too many vect insns.

[Bin.Cheng]

On Sat, Oct 15, 2016 at 3:07 AM, kugan
 wrote:
> Hi Bin,
>
> On 15/10/16 00:15, Bin Cheng wrote:
>>
>> +/* Test for likely overcommitment of vector hardware resources.  If a
>> +   loop iteration is relatively large, and too large a percentage of
>> +   instructions in the loop are vectorized, the cost model may not
>> +   adequately reflect delays from unavailable vector resources.
>> +   Penalize the loop body cost for this case.  */
>> +
>> +static void
>> +aarch64_density_test (struct aarch64_vect_loop_cost_data *data)
>> +{
>> +  const int DENSITY_PCT_THRESHOLD = 85;
>> +  const int DENSITY_SIZE_THRESHOLD = 128;
>> +  const int DENSITY_PENALTY = 10;
>> +  struct loop *loop = data->loop_info;
>> +  basic_block *bbs = get_loop_body (loop);
>
>
> Is this worth being part of the cost model such that it can have different
> defaults for different micro-architecture?
Hi,
I don't know.  From my running, this penalizing function looks like a
quite benchmark specific tuning.  If that's the case, tuning for
different micro architecture may not give meaningful different
results, at the cost of three parameters.
Hi Bill,  I guess you are the original author?  Do you recall any
motivation of this code or have some comments?  Thanks very much.
Meanwhile, I can do some experiments on different AArch64 processors.

Thanks,
bin

[Bug fortran/61420] [5/6/7 Regression] [OOP] type-bound procedure returning a procedure pointer fails to compile

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #10 from Paul Thomas  ---
Created attachment 39825
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39825=edit
Patch for this and PR78013

2016-10-17  Paul Thomas  

PR fortran/61420
PR fortran/78013
* resolve.c (resolve_variable): Obtain the typespec for a
variable expression, when the variable is a function result
that is a procedure pointer.

2016-10-17  Paul Thomas  

PR fortran/61420
PR fortran/78013
* gfortran.dg/proc_ptr_49.f90: New test.

I'll submit to the list in a little while (~1 hour).

Paul

Re: [RFC] Reliable compiler specification setting (at least include/lib dirs) through the process environment

[Joseph Myers]

On Sun, 16 Oct 2016, Shea Levy wrote:

> options) and clearly have the semantics we want. Ideally we would be
> able to specify something on the level of abstraction of "this directory
> should be treated like you would normally treat /usr" and get
> e.g. /include, /lib, frameworks on OS X, etc. handled properly.

What that suggests to me is options for having multiple sysroots (which 
are treated like / not like /usr, but that's the existing concept for a 
directory containing both header and library subdirectories, and you could 
combine this with a Hurd-style configuration of the expected sysroot 
subdirectories, i.e. no /usr inside the sysroot).  That would however be 
rather complex; both GCC and ld presume there is a single global sysroot 
(modulo SYSROOT_SUFFIX_SPEC / SYSROOT_HEADERS_SUFFIX_SPEC that append to 
it), as do the interfaces for other specs that pass down sysroot 
information to cc1 etc. - and ld then interprets absolute paths in linker 
scripts such as libc.so in a sysroot relative to that sysroot (so would 
need to track which sysroot a particular linker script was found in to 
know how to interpret absolute paths in it), and options such as -I=dir 
for a sysroot-relative include don't have a clear meaning with multiple 
sysroots.

I'm wary of adding environment variables as they tend to make debugging 
hard when the same compiler behaves differently for different people for 
no obvious reason.

You should not need to exclude linker options (as opposed to linker input 
files) from the command line when not linking, or compiler options when 
linking.

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

Re: [PATCH] Make -Wint-in-bool-context warn on suspicious shift ops

[Markus Trippelsdorf]

On 2016.10.17 at 16:51 +, Bernd Edlinger wrote:
> On 10/17/16 17:23, Markus Trippelsdorf wrote:
> > On 2016.09.29 at 18:52 +, Bernd Edlinger wrote:
> >> On 09/29/16 20:03, Jason Merrill wrote:
> >>> On Wed, Sep 28, 2016 at 12:09 PM, Bernd Edlinger
> >>>  wrote:
>  On 09/28/16 16:41, Jason Merrill wrote:
> > On Tue, Sep 27, 2016 at 11:10 AM, Bernd Edlinger
> >  wrote:
> >> On 09/27/16 16:42, Jason Merrill wrote:
> >>> On Tue, Sep 27, 2016 at 10:28 AM, Bernd Edlinger
> >>>  wrote:
>  On 09/27/16 16:10, Florian Weimer wrote:
> > * Bernd Edlinger:
> >
> >>> “0 << 0” is used in a similar context, to create a zero constant 
> >>> for a
> >>> multi-bit subfield of an integer.
> >>>
> >>> This example comes from GDB, in bfd/elf64-alpha.c:
> >>>
> >>> |   insn = INSN_ADDQ | (16 << 21) | (0 << 16) | (0 << 0);
> >>>
> >>
> >> Of course that is not a boolean context, and will not get a 
> >> warning.
> >>
> >> Question is if "if (1 << 0)" is possibly a miss-spelled "if (1 < 
> >> 0)".
> >>
> >> Maybe 1 and 0 come from macro expansion
> >
> > But what's the intent of treating 1 << 0 and 0 << 0 differently in 
> > the
> > patch, then?
> 
>  I am not sure if it was a good idea.
> 
>  I saw, we had code of the form
>  bool flag = 1 << 2;
> 
>  another value LOOKUP_PROTECT is  1 << 0, and
>  bool flag = 1 << 0;
> 
>  would at least not overflow the allowed value range of a boolean.
> >>>
> >>> Assigning a bit mask to a bool variable is still probably not what was
> >>> intended, even if it doesn't change the value.
> >>
> >> That works for me too.
> >> I can simply remove that exception.
> >
> > Sounds good.
> 
>  Great.  Is that an "OK with that change"?
> >>>
> >>> What do you think about dropping the TYPE_UNSIGNED exception as well?
> >>> I don't see what difference that makes.
> >>>
> >>
> >>
> >> If I drop that exception, then I could also drop the check for
> >> INTEGER_TYPE and the whole if, because I think other types can not
> >> happen, but if they are allowed they are as well bogus here.
> >>
> >> I can try a bootstrap and see if there are false positives.
> >>
> >> But I can do that as well in a follow-up patch, this should probably
> >> be done step by step, especially when it may trigger some false
> >> positives.
> >>
> >> I think I could also add more stuff, like unary + or - ?
> >> or maybe also binary +, -, * and / ?
> >>
> >> We already discussed making this a multi-level option,
> >> and maybe enabling the higher level explicitly in the
> >> boot-strap.
> >>
> >> As long as the warning continues to find more bugs than false
> >> positives, it is probably worth extending it to more cases.
> >>
> >> However unsigned integer shift are not undefined if they overflow.
> >>
> >> It is possible that this warning will then trigger also on valid
> >> code that does loop termination with unsigned int left shifting.
> >> I dont have a real example, but maybe  like this hypothetical C-code:
> >>
> >>   unsigned int x=1, bits=0;
> >>   while (x << bits) bits++;
> >>   printf("bits=%d\n", bits);
> >>
> >>
> >> Is it OK for everybody to warn for this on -Wall, or maybe only
> >> when -Wextra or for instance -Wint-in-bool-context=2 is used ?
> >
> > I'm seeing this warning a lot in valid low level C code for unsigned
> > integers. And I must say it look bogus in this context. Some examples:

(All these examples are from qemu trunk.)

> >  return ((a.high & 0x7fff) == 0x7fff) && (a.low<<1);
> >

typedef struct {
uint64_t low;
uint16_t high;
} floatx80;

static inline int floatx80_is_any_nan(floatx80 a)
{
return ((a.high & 0x7fff) == 0x7fff) && (a.low<<1);
}

> With the shift op, the result depends on integer promotion rules,
> and if the value is signed, it can invoke undefined behavior.
>
> But if a.low is a unsigned short for instance, a warning would be
> more than justified here.

> >  if ( (uint32_t) ( aSig<<( shiftCount & 31 ) ) ) {
> >
>
> Yes interesting, aSig is signed int, right?

No, it is uint32_t.

> So if the << will overflow, the code is invoking undefined behavior.
>
>
> >  && (uint64_t) (extractFloatx80Frac(a) << 1))
> >
>
> What is the result type of extractFloatx80Frac() ?

static inline uint64_t extractFloatx80Frac( floatx80 a )

>
> >  if ((plen < KEYLENGTH) && (key << plen))
> >
>
> This is from linux, yes, I have not seen that with the first
> version where the warning is only for signed shift ops.
>
> At first sight it looks really, like could it be that "key < plen"
> was meant? But yes, actually it works correctly as long
> as int is 32 bit, if int is 64 bits, that 

[Bug fortran/61420] [5/6/7 Regression] [OOP] type-bound procedure returning a procedure pointer fails to compile

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #9 from Paul Thomas  ---
*** Bug 78013 has been marked as a duplicate of this bug. ***

[Bug fortran/78013] unexpected 'has no IMPLICIT type' error for a type-bound function returning a procedure pointer

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #1 from Paul Thomas  ---
This is an exact duplicate of PR61420. I will post the fix for both there.

Paul

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

Re: [PATCH 0/8] NVPTX offloading to NVPTX: backend patches

[Alexander Monakov]

On Mon, 17 Oct 2016, Bernd Schmidt wrote:
> On 10/14/2016 06:39 PM, Alexander Monakov wrote:
> > I'm resending the patch series with backend prerequisites for OpenMP
> > offloading to the NVIDIA PTX ISA.  The patches are rebased on trunk.
> 
> What's the status of the branch? Is it expected to work? I'm trying to compile
> the OpenMP version of these benchmarks:
>   https://codesign.llnl.gov/lulesh.php
> 
> and the resulting binary fails as follows:
> 
> libgomp: Link error log error   : Size doesn't match for '__nvptx_stacks' in
> 'Input 8', first specified in 'Input 8'
> error   : Multiple definition of '__nvptx_stacks' in 'Input 8', first defined
> in 'Input 8'

I've just pushed two commits to the branch to fix this issue.  Before those, the
last commit left the branch in a state where an incremental build seemed ok
(because libgcc/libgomp weren't rebuilt with the new cc1), but a from-scratch
build was broken like you've shown.  LULESH is known to work.  I also intend to
perform a trunk merge soon.

> I think before merging this work we'll need to have some idea of how well it
> works on real-world code.

This patchset and the branch lay the foundation, there's more work to be
done, in particular on the performance improvements side. There should be
an agreement on these fundamental bits first, before moving on to fine-tuning.

Alexander

[Bug libstdc++/77641] std::variant copy-initialization fails for type with non-trivial constexpr ctor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #5 from Jonathan Wakely  ---
.

[Bug libstdc++/77322] [C++11] std::function::swap should be noexcept.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |6.3

--- Comment #6 from Jonathan Wakely  ---
Fixed for 5.5 and 6.3 too

[Bug libstdc++/72820] std::function can't store types with overloaded operator new

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.3

--- Comment #4 from Jonathan Wakely  ---
Fixed for 5.5 and 6.3 too

[Bug libstdc++/77994] std::sample uses incorrect integer types internally

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Mon Oct 17 17:03:09 2016
New Revision: 241263

URL: https://gcc.gnu.org/viewcvs?rev=241263=gcc=rev
Log:
Backport fixes to std::experimental::sample

PR libstdc++/77994
* include/experimental/algorithm (experimental::sample): Convert size
argument to iterator difference type. Fix invalid use of input
iterator. Defend against overloaded comma operator.

Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/experimental/algorithm
   
branches/gcc-5-branch/libstdc++-v3/testsuite/experimental/algorithm/sample.cc

[Bug libstdc++/77322] [C++11] std::function::swap should be noexcept.

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Mon Oct 17 17:03:31 2016
New Revision: 241266

URL: https://gcc.gnu.org/viewcvs?rev=241266=gcc=rev
Log:
Add noexcept to std::function swap

Backport from mainline:
2016-08-22  Jonathan Wakely  

PR libstdc++/77322
* doc/xml/manual/intro.xml: Document DR 2062 change.
* include/std/functional (function::swap): Add noexcept.
(swap(function

[Bug libstdc++/72820] std::function can't store types with overloaded operator new

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Mon Oct 17 17:03:19 2016
New Revision: 241264

URL: https://gcc.gnu.org/viewcvs?rev=241264=gcc=rev
Log:
Use ::new to avoid finding overloaded operator new

Backport from mainline:
2016-08-06  Jonathan Wakely  

PR libstdc++/72820
* include/std/functional (_Function_base::_Base_manager::_M_clone):
Qualify new operator.
* testsuite/20_util/function/cons/72820.cc: New test.

Added:
branches/gcc-5-branch/libstdc++-v3/testsuite/20_util/function/cons/72820.cc
Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/std/functional

Re: [PATCH AArch64]Penalize vector cost for large loops with too many vect insns.

[James Greenhalgh]

On Sat, Oct 15, 2016 at 01:07:12PM +1100, kugan wrote:
> Hi Bin,
> 
> On 15/10/16 00:15, Bin Cheng wrote:
> >+/* Test for likely overcommitment of vector hardware resources.  If a
> >+   loop iteration is relatively large, and too large a percentage of
> >+   instructions in the loop are vectorized, the cost model may not
> >+   adequately reflect delays from unavailable vector resources.
> >+   Penalize the loop body cost for this case.  */
> >+
> >+static void
> >+aarch64_density_test (struct aarch64_vect_loop_cost_data *data)
> >+{
> >+  const int DENSITY_PCT_THRESHOLD = 85;
> >+  const int DENSITY_SIZE_THRESHOLD = 128;
> >+  const int DENSITY_PENALTY = 10;
> >+  struct loop *loop = data->loop_info;
> >+  basic_block *bbs = get_loop_body (loop);
> 
> Is this worth being part of the cost model such that it can have
> different defaults for different micro-architecture?

I think this is a relevant point, even if we do choose these values for
the generic compilation model, we may want to tune this on a per-core basis.

So, pulling these magic numbers out in to a new field in the CPU tuning
structures (tune_params) is probably the right approach.

Thanks,
James

[Bug fortran/67091] [OOP] Bad result for type-bound procedures returning pointers to the intrinsic function ASSOCIATED

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Paul Thomas  ---
I have left this for so long now that it is not worth backporting to 5-branch.

Sorry about that.

Paul

Re: [Patch] Backport fix for PR 52085 to gcc-5-branch?

[Senthil Kumar Selvaraj]

Richard Biener writes:

> On Mon, Oct 17, 2016 at 12:21 PM, Senthil Kumar Selvaraj
>  wrote:
>> Hi,
>>
>>   The fix for PR 52085 went into trunk when trunk was 6.0. I ran into the
>>   same issue on a gcc 5.x and found that the fix didn't get backported.
>>
>>   Bootstrapped and reg tested below patch with x86-64-pc-linux. Ok to
>>   backport to gcc-5-branch?
>
> Ok with me but please double-check there was no fallout.

I boostrapped and ran against x86_64-pc-linux again, just to be sure.
No regressions.

I'll run the reg tests against arm-none-eabi. Can I commit it if that
passes?

Regards
Senthil
>
> Richard.
>
>> Regards
>> Senthil
>>
>> gcc/c/ChangeLog
>>
>> 2016-10-17  Senthil Kumar Selvaraj  
>>
>>   Backport from mainline
>> 2015-04-25  Marek Polacek  
>> PR c/52085
>> * c-decl.c (finish_enum): Copy over TYPE_ALIGN.  Also check for 
>> "mode"
>> attribute.
>>
>> gcc/testsuite/ChangeLog
>> 2016-10-17  Senthil Kumar Selvaraj  
>>
>> Backport from mainline
>> 2015-04-25  Marek Polacek  
>> PR c/52085
>> * gcc.dg/enum-incomplete-2.c: New test.
>> * gcc.dg/enum-mode-1.c: New test.
>>
>>
>> diff --git gcc/c/c-decl.c gcc/c/c-decl.c
>> index d1e7444..c508e7f 100644
>> --- gcc/c/c-decl.c
>> +++ gcc/c/c-decl.c
>> @@ -8050,7 +8050,7 @@ finish_enum (tree enumtype, tree values, tree 
>> attributes)
>>
>>/* If the precision of the type was specified with an attribute and it
>>   was too small, give an error.  Otherwise, use it.  */
>> -  if (TYPE_PRECISION (enumtype))
>> +  if (TYPE_PRECISION (enumtype) && lookup_attribute ("mode", attributes))
>>  {
>>if (precision > TYPE_PRECISION (enumtype))
>> {
>> @@ -8078,6 +8078,7 @@ finish_enum (tree enumtype, tree values, tree 
>> attributes)
>>TYPE_MIN_VALUE (enumtype) = TYPE_MIN_VALUE (tem);
>>TYPE_MAX_VALUE (enumtype) = TYPE_MAX_VALUE (tem);
>>TYPE_UNSIGNED (enumtype) = TYPE_UNSIGNED (tem);
>> +  TYPE_ALIGN (enumtype) = TYPE_ALIGN (tem);
>>TYPE_SIZE (enumtype) = 0;
>>TYPE_PRECISION (enumtype) = TYPE_PRECISION (tem);
>>
>> diff --git gcc/testsuite/gcc.dg/enum-incomplete-2.c 
>> gcc/testsuite/gcc.dg/enum-incomplete-2.c
>> new file mode 100644
>> index 000..5970551
>> --- /dev/null
>> +++ gcc/testsuite/gcc.dg/enum-incomplete-2.c
>> @@ -0,0 +1,41 @@
>> +/* PR c/52085 */
>> +/* { dg-do compile } */
>> +/* { dg-options "" } */
>> +
>> +#define SA(X) _Static_assert((X),#X)
>> +
>> +enum e1;
>> +enum e1 { A } __attribute__ ((__packed__));
>> +enum e2 { B } __attribute__ ((__packed__));
>> +SA (sizeof (enum e1) == sizeof (enum e2));
>> +SA (_Alignof (enum e1) == _Alignof (enum e2));
>> +
>> +enum e3;
>> +enum e3 { C = 256 } __attribute__ ((__packed__));
>> +enum e4 { D = 256 } __attribute__ ((__packed__));
>> +SA (sizeof (enum e3) == sizeof (enum e4));
>> +SA (_Alignof (enum e3) == _Alignof (enum e4));
>> +
>> +enum e5;
>> +enum e5 { E = __INT_MAX__ } __attribute__ ((__packed__));
>> +enum e6 { F = __INT_MAX__ } __attribute__ ((__packed__));
>> +SA (sizeof (enum e5) == sizeof (enum e6));
>> +SA (_Alignof (enum e5) == _Alignof (enum e6));
>> +
>> +enum e7;
>> +enum e7 { G } __attribute__ ((__mode__(__byte__)));
>> +enum e8 { H } __attribute__ ((__mode__(__byte__)));
>> +SA (sizeof (enum e7) == sizeof (enum e8));
>> +SA (_Alignof (enum e7) == _Alignof (enum e8));
>> +
>> +enum e9;
>> +enum e9 { I } __attribute__ ((__packed__, __mode__(__byte__)));
>> +enum e10 { J } __attribute__ ((__packed__, __mode__(__byte__)));
>> +SA (sizeof (enum e9) == sizeof (enum e10));
>> +SA (_Alignof (enum e9) == _Alignof (enum e10));
>> +
>> +enum e11;
>> +enum e11 { K } __attribute__ ((__mode__(__word__)));
>> +enum e12 { L } __attribute__ ((__mode__(__word__)));
>> +SA (sizeof (enum e11) == sizeof (enum e12));
>> +SA (_Alignof (enum e11) == _Alignof (enum e12));
>> diff --git gcc/testsuite/gcc.dg/enum-mode-1.c 
>> gcc/testsuite/gcc.dg/enum-mode-1.c
>> new file mode 100644
>> index 000..a701123
>> --- /dev/null
>> +++ gcc/testsuite/gcc.dg/enum-mode-1.c
>> @@ -0,0 +1,10 @@
>> +/* { dg-do compile } */
>> +
>> +enum e1 { A = 256 } __attribute__((__mode__(__byte__))); /* { dg-error 
>> "specified mode too small for enumeral values" } */
>> +enum e2 { B = 256 } __attribute__((__packed__, __mode__(__byte__))); /* { 
>> dg-error "specified mode too small for enumeral values" } */
>> +
>> +enum e3 { C = __INT_MAX__ } __attribute__((__mode__(__QI__))); /* { 
>> dg-error "specified mode too small for enumeral values" } */
>> +enum e4 { D = __INT_MAX__ } __attribute__((__packed__, __mode__(__QI__))); 
>> /* { dg-error "specified mode too small for enumeral values" } */
>> +
>> +enum e5 { E = __INT_MAX__ } __attribute__((__mode__(__HI__))); /* { 
>> dg-error "specified mode too small for enumeral values" } */
>> +enum e6 { F = __INT_MAX__ } 

libgo patch committed: copy rdebug code from Go 1.7

[Ian Lance Taylor]

This patch to libgo copies the rdebug code from the Go 1.7 runtime to libgo.

While we're at it, this updates the runtime/debug package, and starts
running its testsuite by default.  I'm not sure why runtime/debug was
not previously updated to 1.7.  Doing that led me to fix some minor
aspects of runtime.Stack and the C function runtime/debug.readGCStats.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 241197)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-880cb0a45590d992880fc6aabc7484e54c817eeb
+314ba28067383516c213ba84c931f93325a48c39
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 241197)
+++ libgo/Makefile.am   (working copy)
@@ -515,7 +515,6 @@ runtime_files = \
lfstack.c \
malloc.c \
netpoll.c \
-   rdebug.c \
reflect.c \
runtime1.c \
sigqueue.c \
@@ -3035,6 +3034,7 @@ TEST_PACKAGES = \
os/user/check \
path/filepath/check \
regexp/syntax/check \
+   runtime/debug/check \
runtime/pprof/check \
runtime/internal/atomic/check \
runtime/internal/sys/check \
Index: libgo/go/runtime/debug/garbage.go
===
--- libgo/go/runtime/debug/garbage.go   (revision 240942)
+++ libgo/go/runtime/debug/garbage.go   (working copy)
@@ -16,17 +16,10 @@ type GCStats struct {
NumGC  int64   // number of garbage collections
PauseTotal time.Duration   // total pause for all collections
Pause  []time.Duration // pause history, most recent first
+   PauseEnd   []time.Time // pause end times history, most recent 
first
PauseQuantiles []time.Duration
 }
 
-// Implemented in package runtime.
-func readGCStats(*[]time.Duration)
-func enableGC(bool) bool
-func setGCPercent(int) int
-func freeOSMemory()
-func setMaxStack(int) int
-func setMaxThreads(int) int
-
 // ReadGCStats reads statistics about garbage collection into stats.
 // The number of entries in the pause history is system-dependent;
 // stats.Pause slice will be reused if large enough, reallocated otherwise.
@@ -38,25 +31,36 @@ func setMaxThreads(int) int
 func ReadGCStats(stats *GCStats) {
// Create a buffer with space for at least two copies of the
// pause history tracked by the runtime. One will be returned
-   // to the caller and the other will be used as a temporary buffer
-   // for computing quantiles.
+   // to the caller and the other will be used as transfer buffer
+   // for end times history and as a temporary buffer for
+   // computing quantiles.
const maxPause = len(((*runtime.MemStats)(nil)).PauseNs)
-   if cap(stats.Pause) < 2*maxPause {
-   stats.Pause = make([]time.Duration, 2*maxPause)
+   if cap(stats.Pause) < 2*maxPause+3 {
+   stats.Pause = make([]time.Duration, 2*maxPause+3)
}
 
-   // readGCStats fills in the pause history (up to maxPause entries)
-   // and then three more: Unix ns time of last GC, number of GC,
-   // and total pause time in nanoseconds. Here we depend on the
-   // fact that time.Duration's native unit is nanoseconds, so the
-   // pauses and the total pause time do not need any conversion.
+   // readGCStats fills in the pause and end times histories (up to
+   // maxPause entries) and then three more: Unix ns time of last GC,
+   // number of GC, and total pause time in nanoseconds. Here we
+   // depend on the fact that time.Duration's native unit is
+   // nanoseconds, so the pauses and the total pause time do not need
+   // any conversion.
readGCStats()
n := len(stats.Pause) - 3
stats.LastGC = time.Unix(0, int64(stats.Pause[n]))
stats.NumGC = int64(stats.Pause[n+1])
stats.PauseTotal = stats.Pause[n+2]
+   n /= 2 // buffer holds pauses and end times
stats.Pause = stats.Pause[:n]
 
+   if cap(stats.PauseEnd) < maxPause {
+   stats.PauseEnd = make([]time.Time, 0, maxPause)
+   }
+   stats.PauseEnd = stats.PauseEnd[:0]
+   for _, ns := range stats.Pause[n : n+n] {
+   stats.PauseEnd = append(stats.PauseEnd, time.Unix(0, int64(ns)))
+   }
+
if len(stats.PauseQuantiles) > 0 {
if n == 0 {
for i := range stats.PauseQuantiles {
@@ -91,9 +95,9 @@ func (x byDuration) Less(i, j int) bool
 // at startup, or 100 if the variable is not set.
 // A negative percentage disables garbage collection.
 func SetGCPercent(percent int) int {
-   old := 

[Bug libstdc++/72820] std::function can't store types with overloaded operator new

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Mon Oct 17 16:50:43 2016
New Revision: 241250

URL: https://gcc.gnu.org/viewcvs?rev=241250=gcc=rev
Log:
Use ::new to avoid finding overloaded operator new

Backport from mainline:
2016-08-06  Jonathan Wakely  

PR libstdc++/72820
* include/std/functional (_Function_base::_Base_manager::_M_clone):
Qualify new operator.
* testsuite/20_util/function/cons/72820.cc: New test.

Added:
branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/function/cons/72820.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/std/functional

[Bug libstdc++/77322] [C++11] std::function::swap should be noexcept.

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Mon Oct 17 16:50:53 2016
New Revision: 241252

URL: https://gcc.gnu.org/viewcvs?rev=241252=gcc=rev
Log:
Add noexcept to std::function swap

Backport from mainline:
2016-08-22  Jonathan Wakely  

PR libstdc++/77322
* doc/xml/manual/intro.xml: Document DR 2062 change.
* include/std/functional (function::swap): Add noexcept.
(swap(function

Re: [PATCH] Make -Wint-in-bool-context warn on suspicious shift ops

[Bernd Edlinger]

On 10/17/16 17:23, Markus Trippelsdorf wrote:
> On 2016.09.29 at 18:52 +, Bernd Edlinger wrote:
>> On 09/29/16 20:03, Jason Merrill wrote:
>>> On Wed, Sep 28, 2016 at 12:09 PM, Bernd Edlinger
>>>  wrote:
 On 09/28/16 16:41, Jason Merrill wrote:
> On Tue, Sep 27, 2016 at 11:10 AM, Bernd Edlinger
>  wrote:
>> On 09/27/16 16:42, Jason Merrill wrote:
>>> On Tue, Sep 27, 2016 at 10:28 AM, Bernd Edlinger
>>>  wrote:
 On 09/27/16 16:10, Florian Weimer wrote:
> * Bernd Edlinger:
>
>>> “0 << 0” is used in a similar context, to create a zero constant 
>>> for a
>>> multi-bit subfield of an integer.
>>>
>>> This example comes from GDB, in bfd/elf64-alpha.c:
>>>
>>> |   insn = INSN_ADDQ | (16 << 21) | (0 << 16) | (0 << 0);
>>>
>>
>> Of course that is not a boolean context, and will not get a warning.
>>
>> Question is if "if (1 << 0)" is possibly a miss-spelled "if (1 < 0)".
>>
>> Maybe 1 and 0 come from macro expansion
>
> But what's the intent of treating 1 << 0 and 0 << 0 differently in the
> patch, then?

 I am not sure if it was a good idea.

 I saw, we had code of the form
 bool flag = 1 << 2;

 another value LOOKUP_PROTECT is  1 << 0, and
 bool flag = 1 << 0;

 would at least not overflow the allowed value range of a boolean.
>>>
>>> Assigning a bit mask to a bool variable is still probably not what was
>>> intended, even if it doesn't change the value.
>>
>> That works for me too.
>> I can simply remove that exception.
>
> Sounds good.

 Great.  Is that an "OK with that change"?
>>>
>>> What do you think about dropping the TYPE_UNSIGNED exception as well?
>>> I don't see what difference that makes.
>>>
>>
>>
>> If I drop that exception, then I could also drop the check for
>> INTEGER_TYPE and the whole if, because I think other types can not
>> happen, but if they are allowed they are as well bogus here.
>>
>> I can try a bootstrap and see if there are false positives.
>>
>> But I can do that as well in a follow-up patch, this should probably
>> be done step by step, especially when it may trigger some false
>> positives.
>>
>> I think I could also add more stuff, like unary + or - ?
>> or maybe also binary +, -, * and / ?
>>
>> We already discussed making this a multi-level option,
>> and maybe enabling the higher level explicitly in the
>> boot-strap.
>>
>> As long as the warning continues to find more bugs than false
>> positives, it is probably worth extending it to more cases.
>>
>> However unsigned integer shift are not undefined if they overflow.
>>
>> It is possible that this warning will then trigger also on valid
>> code that does loop termination with unsigned int left shifting.
>> I dont have a real example, but maybe  like this hypothetical C-code:
>>
>>   unsigned int x=1, bits=0;
>>   while (x << bits) bits++;
>>   printf("bits=%d\n", bits);
>>
>>
>> Is it OK for everybody to warn for this on -Wall, or maybe only
>> when -Wextra or for instance -Wint-in-bool-context=2 is used ?
>
> I'm seeing this warning a lot in valid low level C code for unsigned
> integers. And I must say it look bogus in this context. Some examples:
>
>  return ((a.high & 0x7fff) == 0x7fff) && (a.low<<1);
>

With the shift op, the result depends on integer promotion rules,
and if the value is signed, it can invoke undefined behavior.

But if a.low is a unsigned short for instance, a warning would be
more than justified here.

>  if ( (uint32_t) ( aSig<<( shiftCount & 31 ) ) ) {
>

Yes interesting, aSig is signed int, right?

So if the << will overflow, the code is invoking undefined behavior.


>  && (uint64_t) (extractFloatx80Frac(a) << 1))
>

What is the result type of extractFloatx80Frac() ?


>  if ((plen < KEYLENGTH) && (key << plen))
>

This is from linux, yes, I have not seen that with the first
version where the warning is only for signed shift ops.

At first sight it looks really, like could it be that "key < plen"
was meant? But yes, actually it works correctly as long
as int is 32 bit, if int is 64 bits, that code would break
immediately.

I think in the majority of code, where the author was aware of
possible overflow issues and integer promotion rules, he will
have used unsigned integer types, of sufficient precision.

I think all of the places where I have seen this warning was issued for
wrong code it was with signed integer shifts.



Bernd.

[Bug libstdc++/77994] std::sample uses incorrect integer types internally

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Mon Oct 17 16:50:37 2016
New Revision: 241249

URL: https://gcc.gnu.org/viewcvs?rev=241249=gcc=rev
Log:
Backport fixes to std::experimental::sample

PR libstdc++/77994
* include/experimental/algorithm (experimental::sample): Convert size
argument to iterator difference type. Fix invalid use of input
iterator. Defend against overloaded comma operator.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/experimental/algorithm
   
branches/gcc-6-branch/libstdc++-v3/testsuite/experimental/algorithm/sample.cc

Re: [PATCH] Reduce stack usage in sha512 (PR target/77308)

[Kyrill Tkachov]

On 30/09/16 14:34, Bernd Edlinger wrote:

On 09/30/16 12:14, Bernd Edlinger wrote:

Eric Botcazou wrote:

A comment before the SETs and a testcase would be nice.  IIRC
we do have stack size testcases via using -fstack-usage.

Or -Wstack-usage, which might be more appropriate here.

Yes.  good idea.  I was not aware that we already have that kind of tests.

When trying to write this test. I noticed, that I did not try -Os so far.
But for -Os the stack is still the unchanged 3500 bytes.

However for embedded targets I am often inclined to use -Os, and
would certainly not expect the stack to explode...

I see in arm.md there are places like

/* If we're optimizing for size, we prefer the libgcc calls.  */
if (optimize_function_for_size_p (cfun))
  FAIL;


Oh, yeah.  The comment is completely misleading.

If this pattern fails, expmed.c simply expands some
less efficient rtl, which also results in two shifts
and one or-op.  No libgcc calls at all.

So in simple cases without spilling the resulting
assembler is the same, regardless if this pattern
fails or not.  But the half-defined out registers
make a big difference when it has to be spilled.


/* Expand operation using core-registers.
   'FAIL' would achieve the same thing, but this is a bit smarter.  */
scratch1 = gen_reg_rtx (SImode);
scratch2 = gen_reg_rtx (SImode);
arm_emit_coreregs_64bit_shift (LSHIFTRT, operands[0], operands[1],
   operands[2], scratch1, scratch2);


.. that explains why this happens.  I think it would be better to
use the emit_coreregs for shift count >= 32, because these are
effectively 32-bit shifts.

Will try if that can be improved, and come back with the
results.


The test case with -Os has 3520 bytes stack usage.
When only shift count >= 32 are handled we
have still 3000 bytes stack usage.
And when arm_emit_coreregs_64bit_shift is always
allowed to run, we have 2360 bytes stack usage.

Also for the code size it is better not to fail this
pattern.  So I propose to remove this exception in all
three expansions.

Here is an improved patch with the test case from the PR.
And a comment on the redundant SET why it is better to clear
the out register first.


Bootstrap and reg-testing on arm-linux-gnueabihf.
Is it OK for trunk?


This looks ok to me.
Thanks,
Kyrill



Thanks
Bernd.

[Bug fortran/78013] New: unexpected 'has no IMPLICIT type' error for a type-bound function returning a procedure pointer

[pault at gcc dot gnu.org]

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

Bug ID: 78013
   Summary: unexpected 'has no IMPLICIT type' error for a
type-bound function returning a procedure pointer
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pault at gcc dot gnu.org
  Target Milestone: ---

Reported at
https://groups.google.com/forum/#!topic/comp.lang.fortran/OIEdfZunBPk

module m

   implicit none

   abstract interface
  function I_f() result( r )
 real :: r
  end function I_f
   end interface

   type, abstract :: a_t
  private
  procedure(I_f), nopass, pointer :: m_f => null()
   contains
  private
  procedure, pass(this), public :: f => get_f
   end type a_t

contains

   function get_f( this ) result( f_ptr )

  class(a_t), intent(in)  :: this
  procedure(I_f), pointer :: f_ptr

  f_ptr => this%m_f

   end function get_f

end module m 

Upon compilation,
function get_f( this ) result( f_ptr )
   1
Error: Symbol 'get_f' at (1) has no IMPLICIT type

ifort compiles it without problem.

I have a fix, which is just regtesting.

Paul

[PING #2] [PATCH] fix outstanding -Wformat-length failures (pr77735 et al.)

[Martin Sebor]

I'm still looking for a review of the patch below:

  https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00043.html



The patch should clean up the remaining test suite failures on
ILP32 targets and also fixes up some remaining issues in the
gimple-ssa-sprintf pass that stand in the way of re-enabling
the printf-return-value optimization.

I'm traveling next week so I'm hoping to enable the optimization
shortly after this patch goes in so that if there's any fallout
from it I can fix it before I leave.

Thanks
Martin

On 10/02/2016 02:10 PM, Martin Sebor wrote:

The attached patch fixes a number of outstanding test failures
and ILP32-related bugs in the gimple-ssa-sprintf pattch pointed
out in bug 77676 and 77735).  The patch also fixes c_strlen to
correctly handle wide strings (previously it accepted them but
treated them as nul-terminated byte sequences), and adjusts the
handling of "%a" to avoid assuming a specific number of decimal
digits (this is likely a defect in C11 that I'm pursuing with
WG14).

Tested on powerpc64le, i386, and x86_64.

There is one outstanding failure in the builtin-sprintf-warn-1.c
test on powerpc64le that looks like it might be due to the
printf_pointer_format target hook not having been set up entirely
correctly.  I'll look into that separately, along with pr77819.

Martin