[testsuite, i386] Compile gcc.target/i386/pr70322-?.c with -mno-stackrealign

[Rainer Orth]

Between 20161202 and 20161205, a couple of testcases started to FAIL on
32-bit Solaris/x86:

+FAIL: gcc.target/i386/pr70322-1.c scan-assembler pandn
+FAIL: gcc.target/i386/pr70322-2.c scan-assembler pandn
+FAIL: gcc.target/i386/pr70322-3.c scan-assembler por
+FAIL: gcc.target/i386/pr70322-3.c scan-assembler pxor
+FAIL: gcc.target/i386/pr70322-4.c scan-assembler por
+FAIL: gcc.target/i386/pr70322-4.c scan-assembler psub

This is the same issue as PR target/77483, as is the solution.

The following patch implements it.  Bootstrapped without regressions on
i386-pc-solaris2.12 and x86_64-pc-linux-gnu (both 32 and 64-bit
multilibs).  Ok for mainline?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2016-12-06  Rainer Orth  

* gcc.target/i386/pr70322-1.c: Add -mno-stackrealign to dg-options.
* gcc.target/i386/pr70322-2.c: Likewise.
* gcc.target/i386/pr70322-3.c: Likewise.
* gcc.target/i386/pr70322-4.c: Likewise.

# HG changeset patch
# Parent  803dbc1539b116e06f7ec76ef3258b07ffa01b80
Compile gcc.target/i386/pr70322-?.c with -mno-stackrealign

diff --git a/gcc/testsuite/gcc.target/i386/pr70322-1.c b/gcc/testsuite/gcc.target/i386/pr70322-1.c
--- a/gcc/testsuite/gcc.target/i386/pr70322-1.c
+++ b/gcc/testsuite/gcc.target/i386/pr70322-1.c
@@ -1,6 +1,6 @@
 /* PR target/70322 */
 /* { dg-do compile { target ia32 } } */
-/* { dg-options "-O2 -msse2 -mstv -mbmi" } */
+/* { dg-options "-O2 -msse2 -mstv -mbmi -mno-stackrealign" } */
 /* { dg-final { scan-assembler "pandn" } } */
 
 extern long long z;
diff --git a/gcc/testsuite/gcc.target/i386/pr70322-2.c b/gcc/testsuite/gcc.target/i386/pr70322-2.c
--- a/gcc/testsuite/gcc.target/i386/pr70322-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr70322-2.c
@@ -1,6 +1,6 @@
 /* PR target/70322 */
 /* { dg-do compile { target ia32 } } */
-/* { dg-options "-O2 -msse2 -mstv -mno-bmi" } */
+/* { dg-options "-O2 -msse2 -mstv -mno-bmi -mno-stackrealign" } */
 /* { dg-final { scan-assembler "pandn" } } */
 
 extern long long z;
diff --git a/gcc/testsuite/gcc.target/i386/pr70322-3.c b/gcc/testsuite/gcc.target/i386/pr70322-3.c
--- a/gcc/testsuite/gcc.target/i386/pr70322-3.c
+++ b/gcc/testsuite/gcc.target/i386/pr70322-3.c
@@ -1,6 +1,6 @@
 /* PR target/70322 */
 /* { dg-do compile { target ia32 } } */
-/* { dg-options "-O2 -msse2 -mstv" } */
+/* { dg-options "-O2 -msse2 -mstv -mno-stackrealign" } */
 /* { dg-final { scan-assembler "pxor" } } */
 /* { dg-final { scan-assembler "por" } } */
 
diff --git a/gcc/testsuite/gcc.target/i386/pr70322-4.c b/gcc/testsuite/gcc.target/i386/pr70322-4.c
--- a/gcc/testsuite/gcc.target/i386/pr70322-4.c
+++ b/gcc/testsuite/gcc.target/i386/pr70322-4.c
@@ -1,6 +1,6 @@
 /* PR target/70322 */
 /* { dg-do compile { target ia32 } } */
-/* { dg-options "-O2 -msse2 -mstv" } */
+/* { dg-options "-O2 -msse2 -mstv -mno-stackrealign" } */
 /* { dg-final { scan-assembler "psub" } } */
 /* { dg-final { scan-assembler "por" } } */
 

Re: [testsuite, i386] Compile gcc.target/i386/pr70322-?.c with -mno-stackrealign

[Jakub Jelinek]

On Wed, Dec 07, 2016 at 09:11:21AM +0100, Rainer Orth wrote:
> Between 20161202 and 20161205, a couple of testcases started to FAIL on
> 32-bit Solaris/x86:
> 
> +FAIL: gcc.target/i386/pr70322-1.c scan-assembler pandn
> +FAIL: gcc.target/i386/pr70322-2.c scan-assembler pandn
> +FAIL: gcc.target/i386/pr70322-3.c scan-assembler por
> +FAIL: gcc.target/i386/pr70322-3.c scan-assembler pxor
> +FAIL: gcc.target/i386/pr70322-4.c scan-assembler por
> +FAIL: gcc.target/i386/pr70322-4.c scan-assembler psub
> 
> This is the same issue as PR target/77483, as is the solution.
> 
> The following patch implements it.  Bootstrapped without regressions on
> i386-pc-solaris2.12 and x86_64-pc-linux-gnu (both 32 and 64-bit
> multilibs).  Ok for mainline?
> 
>   Rainer
> 
> -- 
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
> 
> 
> 2016-12-06  Rainer Orth  
> 
>   * gcc.target/i386/pr70322-1.c: Add -mno-stackrealign to dg-options.
>   * gcc.target/i386/pr70322-2.c: Likewise.
>   * gcc.target/i386/pr70322-3.c: Likewise.
>   * gcc.target/i386/pr70322-4.c: Likewise.

Ok, thanks.

Jakub

Re: [PATCH 8c/9] Add aarch64-specific selftests for RTL function reader

[James Greenhalgh]

On Tue, Dec 06, 2016 at 02:38:45PM -0500, David Malcolm wrote:
> On Tue, 2016-12-06 at 17:22 +, James Greenhalgh wrote:
> > On Thu, Dec 01, 2016 at 09:00:11PM -0500, David Malcolm wrote:
> > > This patch adds more selftests for class function_reader, where
> > > the dumps to be read contain aarch64-specific features.
> > > 
> > > In an earlier version of the patch kit, these were handled using
> > > #ifndef GCC_AARCH64_H to conditionalize running them.
> > > This version instead runs them via a target hook for running
> > > target-specific selftests, thus putting them within aarch64.c.
> > 
> > I'm probably missing something obvious here.
> > 
> > This looks OK, but can we have a comment somewhere near the code as
> > to
> > what this test is actually testing?
> > 
> > Is it just that x0 is correctly identfied as the return register?
> 
> The original point of the test was to have an integration test of
> loading a real dump from print_rtx_function, to verify that the loader
> can actually load it.
> 
> The dump contains a target-specific item, and thus the test needs to be
> made target-specific (I did one of these for x86_64, and one for
> aarch64, which are the two targets that I've done the most testing of
> the patch kit on).
> 
> Looking over it now, yeah, it's not a great test (but hopefully not a
> bad one either).
> 
> It does verify that "x0" is correctly parsed, so it is giving some test
> coverage for lookup_reg_by_dump_name's handling of hard regs (in patch
> 8a in the kit).  I also picked a couple of insns to verify (one outside
> of a bb, the other inside of a bb).
> 
> Currently the comment reads:
> 
>/* Selftest for the RTL loader.  This test is target-specific and
>   here since the dump contains target-specific hard reg names.
>   Verify that the RTL loader copes with a dump from
>   print_rtx_function.  */
> 
> Would you be OK with the test if it read:
> 
>/* Selftest for the RTL loader.
>   Verify that the RTL loader copes with a dump from
>   print_rtx_function.  This is essentially just a test that class
>   function_reader can handle a real dump, but it also verifies
>   that lookup_reg_by_dump_name correctly handles hard regs.
>   The presence of hard reg names in the dump means that the test is
>   target-specific, hence it is in this file.  */
> 
> or somesuch?

That looks fine to me. Thanks for the more detailed explanation.

> Alternatively, I can drop this patch.

No, this is good, and I'm happy to approve it - I just haven't followed the
rest of the patch series so it wasn't clear to me from the syntax what made
this target specific. With your explanation I now understand.

This is OK for trunk.

Thanks,
James

Re: [LRA] Fix ICE on pathological testcase

[Richard Sandiford]

Bernd Edlinger  writes:
> Hi Eric,
>
> what you got there, looks more or less exactly like what I tried
> to fix with that patch a few months ago, but unfortunately
> we were unable to get a consensus on that approach:
>
> [PATCH] Fix asm X constraint (PR inline-asm/59155)
> https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01649.html

Does your patch also fix Eric's testcase?  If so then that approach
looks safer to me FWIW.  The problem with allowing arbitrary MEMs
is that it's just not clear:

(a) which other parts of the compiler (including target code) needs
to handle these arbitrary MEMs.  One instance is the target-specific
code for printing an address, as Jakub says in that thread, but it
could also affect things like cost calculations, etc.

(b) should a spilled pseudo in the MEM be replaced with a MEM itself,
so that even RISC targets have to support nested MEMs?  Or should
pseudo registers be reloaded?  If so, into which register classes?
Should they be divided into base and index registers in the normal
way?  That's difficult to do if we can't decompose the address.

Reload's always been a recurring source of problems, so the fact
that this particular case went through without an ICE doesn't mean
that arbitrary MEMs were actually safe in general.

Thanks,
Richard

Re: [PR78365] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

[Martin Jambor]

Hello Kugan,

sorry, I have lost track of this patch and re-discovered it only now.

On Mon, Nov 28, 2016 at 04:25:00PM +1100, kugan wrote:
> Hi,
> 
> On 24/11/16 19:48, Richard Biener wrote:
> > On Wed, Nov 23, 2016 at 4:33 PM, Martin Jambor  wrote:
> > > Hi,
> > > 
> > > On Fri, Nov 18, 2016 at 12:38:18PM +1100, kugan wrote:
> > > > Hi,
> > > > 
> > > > I was relying on ipa_get_callee_param_type to get type of parameter and 
> > > > then
> > > > convert arguments to this type while computing jump functions. However, 
> > > > in
> > > > cases like shown in PR78365, ipa_get_callee_param_type, instead of 
> > > > giving
> > > > up, would return the wrong type.
> > > 
> > > At what stage does this happen?  During analysis
> > > (ipa_compute_jump_functions_for_edge) or at WPA
> > > (propagate_constants_accross_call)?  Both?
> > 
> > Hmm, where does jump function compute require the callee type?
> > In my view the jump function should record
> > 
> >  (expected-incoming-type) arg [OP X]
> > 
> > for each call argument in its body.  Thus required conversions are
> > done at WPA propagation time.
> > 
> > > > I think the current uses of
> > > > ipa_get_callee_param_type are fine with this.
> > > > 
> > > > Attached patch now uses callee's DECL_ARGUMENTS to get the type. If it
> > > > cannot be found, then I would give up and set the jump function to 
> > > > varying.
> > > 
> > > But DECL_ARGUMENTS is not available at WPA stage with LTO so your
> > > patch would make our IPA layer to optimize less with LTO.  This was
> > > the reason to go through the hoops of TYPE_ARG_TYPES in the first
> > > place.
> > > 
> > > If TYPE_ARG_TYPES cannot be trusted, then I'm afraid we are back to
> > > square one and indeed need to put the correct type in jump functions.
> > 
> > If DECL_ARGUMENTS is not available at WPA stage then I see no other
> > way than to put the types on the jump functions.
> 
> Here is a patch that does this. To fox PR78365, in
> ipa_get_callee_param_type, I am now checking DECL_ARGUMENTS first. I lto
> bootstrapped and regression tested on x86_64-linux-gnu and ppc64le-linux
> with no new regressions. I will build Firefox and measure the memory usage
> as Honza suggested based on the feedback.
> 

So, do you have any numbers?


> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
> index 2ec671f..3d50041 100644
> --- a/gcc/ipa-cp.c
> +++ b/gcc/ipa-cp.c
> @@ -1846,11 +1846,11 @@ propagate_bits_accross_jump_function (cgraph_edge 
> *cs, int idx, ipa_jump_func *j
>  static bool
>  propagate_vr_accross_jump_function (cgraph_edge *cs,
>   ipa_jump_func *jfunc,
> - struct ipcp_param_lattices *dest_plats,
> - tree param_type)
> + struct ipcp_param_lattices *dest_plats)
>  {
>struct ipcp_param_lattices *src_lats;
>ipcp_vr_lattice *dest_lat = &dest_plats->m_value_range;
> +  tree param_type = jfunc->param_type;
>  
>if (dest_lat->bottom_p ())
>  return false;
> @@ -1895,9 +1895,9 @@ propagate_vr_accross_jump_function (cgraph_edge *cs,
>tree val = ipa_get_jf_constant (jfunc);
>if (TREE_CODE (val) == INTEGER_CST)
>   {
> +   val = fold_convert (param_type, val);
> if (TREE_OVERFLOW_P (val))
>   val = drop_tree_overflow (val);
> -   val = fold_convert (param_type, val);
> jfunc->vr_known = true;
> jfunc->m_vr.type = VR_RANGE;
> jfunc->m_vr.min = val;
> @@ -2247,7 +2247,6 @@ propagate_constants_accross_call (struct cgraph_edge 
> *cs)
>  {
>struct ipa_jump_func *jump_func = ipa_get_ith_jump_func (args, i);
>struct ipcp_param_lattices *dest_plats;
> -  tree param_type = ipa_get_callee_param_type (cs, i);
>  
>dest_plats = ipa_get_parm_lattices (callee_info, i);
>if (availability == AVAIL_INTERPOSABLE)
> @@ -2264,8 +2263,7 @@ propagate_constants_accross_call (struct cgraph_edge 
> *cs)
>  dest_plats);
> if (opt_for_fn (callee->decl, flag_ipa_vrp))
>   ret |= propagate_vr_accross_jump_function (cs,
> -jump_func, dest_plats,
> -param_type);
> +jump_func, dest_plats);
> else
>   ret |= dest_plats->m_value_range.set_to_bottom ();
>   }
> diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
> index 90c19fc..235531b 100644
> --- a/gcc/ipa-prop.c
> +++ b/gcc/ipa-prop.c
> @@ -1651,14 +1651,24 @@ determine_locally_known_aggregate_parts (gcall *call, 
> tree arg,
>  /* Return the Ith param type of callee associated with call graph
> edge E.  */
>  
> -tree
> +static tree
>  ipa_get_callee_param_type (struct cgraph_edge *e, int i)
>  {
>int n;
> +  tree t = e->callee ? DECL_ARGUMENTS (e->callee->decl) : NULL_TREE;
> +  if (t)
> +for (n = 0; n < i; 

[Patch PR78561 PowerPC] Revert to old behaviour for counting constant pools

[James Greenhalgh]

Hi,

This patch is a bit of a shot in the dark, as I've been unable to reproduce
Segher's failures reported in the PR. But, he has confirmed on the PR that
this patch fixes the issue he was seeing.

Before my patch set, rs6000 was reading the size of the constant pool at
several points in compilation, and expecting that if it read non-zero at one
point in compilation, it would always read non-zero.

That doesn't hold if we recompute the size of the constant pool just before
emitting it and decide that actually the size is zero. That can mean some
of the preparation statements emitted early in the PowerPC back end can think
a constant pool is needed, while later passes know there won't be one as all
the references are unused. That then causes issues for PIC register set up.

We always keep the entries in the constant pool after we first see them, and
we figure out what gets used in the constant pool by sweeping through
looking for referenced entries. That means we can always answer the
question "has the constant pool ever had entries?" by checking if there
is anything at all in there.

So that's what this patch does.

Bootstrapped on gcc110 (powerpc64-none-linux-gnu) configured with
--enable-languages=all,ada,go,obj-c++ with no issues, Segher has also
tested it with no issues, and I've tested an aarch64-none-elf cross
compiler to ensure that the original fix still works on AArch64.

OK?

Thanks,
James

---
2016-12-07  James Greenhalgh  

PR rtl-optimization/78561
* config/rs6000/rs6000.c (rs6000_reg_live_or_pic_offset_p) Use
constant_pool_empty_p in place of get_pool_size_upper_bound.
(rs6000_stack_info): Likewise.
(rs6000_emit_prologue): Likewise.
(rs6000_elf_declare_function_name): Likewise.
(rs6000_set_up_by_prologue): Likewise.
(rs6000_can_eliminate): Likewise.
* output.h (get_pool_size_upper_bound): Delete.
(constant_pool_empty_p): New.
* varasm.c (get_pool_size_upper_bound): Delete
(constant_pool_empty_p): New.

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 59bd3fe..b75a290 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -25460,7 +25460,7 @@ rs6000_reg_live_or_pic_offset_p (int reg)
   if (TARGET_TOC && TARGET_MINIMAL_TOC
 	  && (crtl->calls_eh_return
 	  || df_regs_ever_live_p (reg)
-	  || get_pool_size_upper_bound ()))
+	  || !constant_pool_empty_p ()))
 	return true;
 
   if ((DEFAULT_ABI == ABI_V4 || DEFAULT_ABI == ABI_DARWIN)
@@ -26266,7 +26266,7 @@ rs6000_stack_info (void)
 #ifdef TARGET_RELOCATABLE
   || (DEFAULT_ABI == ABI_V4
 	  && (TARGET_RELOCATABLE || flag_pic > 1)
-	  && get_pool_size_upper_bound () != 0)
+	  && !constant_pool_empty_p ())
 #endif
   || rs6000_ra_ever_killed ())
 info->lr_save_p = 1;
@@ -28044,7 +28044,7 @@ rs6000_emit_prologue (void)
 
   /* With -mminimal-toc we may generate an extra use of r2 below.  */
   if (TARGET_TOC && TARGET_MINIMAL_TOC
-	  && get_pool_size_upper_bound () != 0)
+	  && !constant_pool_empty_p ())
 	cfun->machine->r2_setup_needed = true;
 }
 
@@ -28900,7 +28900,7 @@ rs6000_emit_prologue (void)
   /* If we are using RS6000_PIC_OFFSET_TABLE_REGNUM, we need to set it up.  */
   if (!TARGET_SINGLE_PIC_BASE
   && ((TARGET_TOC && TARGET_MINIMAL_TOC
-	   && get_pool_size_upper_bound () != 0)
+	   && !constant_pool_empty_p ())
 	  || (DEFAULT_ABI == ABI_V4
 	  && (flag_pic == 1 || (flag_pic && TARGET_SECURE_PLT))
 	  && df_regs_ever_live_p (RS6000_PIC_OFFSET_TABLE_REGNUM
@@ -34967,7 +34967,7 @@ rs6000_elf_declare_function_name (FILE *file, const char *name, tree decl)
   if (DEFAULT_ABI == ABI_V4
   && (TARGET_RELOCATABLE || flag_pic > 1)
   && !TARGET_SECURE_PLT
-  && (get_pool_size_upper_bound () != 0 || crtl->profile)
+  && (!constant_pool_empty_p () || crtl->profile)
   && uses_TOC ())
 {
   char buf[256];
@@ -37453,7 +37453,7 @@ rs6000_can_eliminate (const int from, const int to)
 	  ? ! frame_pointer_needed
 	  : from == RS6000_PIC_OFFSET_TABLE_REGNUM
 	? ! TARGET_MINIMAL_TOC || TARGET_NO_TOC
-		|| get_pool_size_upper_bound () == 0
+		|| constant_pool_empty_p ()
 	: true);
 }
 
@@ -38990,7 +38990,7 @@ rs6000_set_up_by_prologue (struct hard_reg_set_container *set)
   if (!TARGET_SINGLE_PIC_BASE
   && TARGET_TOC
   && TARGET_MINIMAL_TOC
-  && get_pool_size_upper_bound () != 0)
+  && !constant_pool_empty_p ())
 add_to_hard_reg_set (&set->set, Pmode, RS6000_PIC_OFFSET_TABLE_REGNUM);
   if (cfun->machine->split_stack_argp_used)
 add_to_hard_reg_set (&set->set, Pmode, 12);
diff --git a/gcc/output.h b/gcc/output.h
index 7186dc1..6c99381 100644
--- a/gcc/output.h
+++ b/gcc/output.h
@@ -287,11 +287,10 @@ extern void assemble_real (REAL_VALUE_TYPE, machine_mode, unsigned,
 /* Write the address of the entity given by SYMBOL to SEC.  */
 extern void assemble_addr_to_section (rtx, section *);
 
-

Re: [PATCH] [AArch64] Fix PR71112

[James Greenhalgh]

On Wed, Dec 07, 2016 at 07:25:21AM +, Hurugalawadi, Naveen wrote:
> Hi James,
> 
> Thanks for the review and suggestions regarding the testcase.
> 
> >> Why limit the ABI and endianness here, and if you do plan to do that
> 
> Extra options have been dropped and the testcase will check across
> all variants and endianness.
> 
> Please find attached the modified patch as per the comments and let
> me know if its okay?

OK with an appropriate ChangeLog entry.

Thanks,
James

> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index dab46b5..9fce849 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -1302,7 +1302,8 @@ aarch64_load_symref_appropriately (rtx dest, rtx imm,
>   emit_move_insn (gp_rtx, gen_rtx_HIGH (Pmode, s));
>  
>   if (mode != GET_MODE (gp_rtx))
> -   gp_rtx = simplify_gen_subreg (mode, gp_rtx, GET_MODE (gp_rtx), 0);
> + gp_rtx = gen_lowpart (mode, gp_rtx);
> +
> }
>  
>   if (mode == ptr_mode)
> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr71112.c 
> b/gcc/testsuite/gcc.c-torture/compile/pr71112.c
> new file mode 100644
> index 000..69e2df6
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/compile/pr71112.c
> @@ -0,0 +1,10 @@
> +/* PR target/71112.  */
> +/* { dg-additional-options "-fpie" { target pie } } */
> +
> +extern int dbs[100];
> +void f (int *);
> +int nscd_init (void)
> +{
> +  f (dbs);
> +  return 0;
> +}

Re: [PATCH] [AArch64] Fix PR78382

[James Greenhalgh]

On Wed, Dec 07, 2016 at 07:25:29AM +, Hurugalawadi, Naveen wrote:
> Hi James,
> 
> Thanks for the review and suggestions regarding the testcase.
> 
> >> Why limit the ABI and endianness here
> 
> Extra options have been dropped and the testcase will check across
> all variants and endianness.
> 
> Please find attached the modified patch as per the comments and let
> me know if its okay?

OK with an appropriate ChangeLog entry.

Thanks,
James

> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index dab46b5..2b61897 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -1378,10 +1378,14 @@ aarch64_load_symref_appropriately (rtx dest, rtx imm,
>  case SYMBOL_SMALL_TLSGD:
>{
>   rtx_insn *insns;
> - rtx result = gen_rtx_REG (Pmode, R0_REGNUM);
> + machine_mode mode = GET_MODE (dest);
> + rtx result = gen_rtx_REG (mode, R0_REGNUM);
>  
>   start_sequence ();
> - aarch64_emit_call_insn (gen_tlsgd_small (result, imm));
> + if (TARGET_ILP32)
> +   aarch64_emit_call_insn (gen_tlsgd_small_si (result, imm));
> + else
> +   aarch64_emit_call_insn (gen_tlsgd_small_di (result, imm));
>   insns = get_insns ();
>   end_sequence ();
>  
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index 1e6b6f5..9d89ee8 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -5173,20 +5173,20 @@
>  ;; The TLS ABI specifically requires that the compiler does not schedule
>  ;; instructions in the TLS stubs, in order to enable linker relaxation.
>  ;; Therefore we treat the stubs as an atomic sequence.
> -(define_expand "tlsgd_small"
> +(define_expand "tlsgd_small_"
>   [(parallel [(set (match_operand 0 "register_operand" "")
>(call (mem:DI (match_dup 2)) (const_int 1)))
> -  (unspec:DI [(match_operand:DI 1 "aarch64_valid_symref" "")] 
> UNSPEC_GOTSMALLTLS)
> +  (unspec:DI [(match_operand:PTR 1 "aarch64_valid_symref" "")] 
> UNSPEC_GOTSMALLTLS)
>(clobber (reg:DI LR_REGNUM))])]
>   ""
>  {
>operands[2] = aarch64_tls_get_addr ();
>  })
>  
> -(define_insn "*tlsgd_small"
> +(define_insn "*tlsgd_small_"
>[(set (match_operand 0 "register_operand" "")
>   (call (mem:DI (match_operand:DI 2 "" "")) (const_int 1)))
> -   (unspec:DI [(match_operand:DI 1 "aarch64_valid_symref" "S")] 
> UNSPEC_GOTSMALLTLS)
> +   (unspec:DI [(match_operand:PTR 1 "aarch64_valid_symref" "S")] 
> UNSPEC_GOTSMALLTLS)
> (clobber (reg:DI LR_REGNUM))
>]
>""
> diff --git a/gcc/testsuite/gcc.target/aarch64/pr78382.c 
> b/gcc/testsuite/gcc.target/aarch64/pr78382.c
> new file mode 100644
> index 000..febe7bc
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/pr78382.c
> @@ -0,0 +1,10 @@
> +/* { dg-require-effective-target fpic } */
> +/* { dg-options "-mtls-dialect=trad -fpic" } */
> +
> +__thread int abc;
> +void
> +foo ()
> +{
> +  int *p;
> +  p = &abc;
> +}

Re: [PATCH], PR target/72717, Fix PowerPC abort in emit_move_insn from rs6000_expand_vector_init

[Segher Boessenkool]

Hi Mike,

On Wed, Dec 07, 2016 at 12:43:12AM -0500, Michael Meissner wrote:
> I did a build on a little endian Power8 system and ran make check.  There were
> no regressions.  Can I check it in the trunk?
> 
> The bug also shows up in GCC 6, and I would like to install it into GCC 6 as
> well.

> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c(revision 243318)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@ -6891,25 +6891,43 @@ rs6000_expand_vector_init (rtx target, r
>/* Double word values on VSX can use xxpermdi or lxvdsx.  */
>if (VECTOR_MEM_VSX_P (mode) && (mode == V2DFmode || mode == V2DImode))
>  {
> -  rtx op0 = XVECEXP (vals, 0, 0);
> -  rtx op1 = XVECEXP (vals, 0, 1);
> +  rtx op[2];
> +  size_t i;
> +  size_t num_elements = (all_same) ? 1 : 2;

No parens here please.

Rest looks fine, please check in.  Okay for 6 too, after some delay
(making sure it works on BE and 32-bit and AIX, etc.)

Thanks,


Segher

Re: [PATCH] Make check_effective_target_c++ work for libstdc++

[Jonathan Wakely]

On 29/07/16 20:43 +0100, Jonathan Wakely wrote:

I've been working on some changes to let the libstdc++ testsuite use
the same approach as G++ to specify a minimum language dialect for
tests. That means instead of hardcoding { dg-options "-std=gnu++11" }
we can use { dg-do run { target c++11 } } and the test will be run for
any implicit or explicit -std mode that meets that minimum.

For that to work I need check_effective_target_c++ to return true when
the dg tool is "libstdc++".

The patch looks a bit messy, because it's fixing some messy
indentiation.

Tested x86_64-linux.

OK for trunk?

* lib/target-supports.exp (check_effective_target_c): Fix indentation.
(check_effective_target_c++): Likewise. Also match for libstdc++.



I'd like to backport this (r238916) to the gcc-6-branch too.

It's been very useful on trunk. The only problems are when we backport
new tests from trunk to the branch and forget that the effective
target doesn't work there (which leads to those new tests being
skipped on the branch as UNSUPPORTED).

Backporting this change to the branch would allow us to backport tests
without having to tweak them.

OK?



commit 56250fec9250e6864a9d7471ead2b08a77b89952
Author: Jonathan Wakely 
Date:   Tue Jul 26 15:49:07 2016 +0100

   Make check_effective_target_c++ work for libstdc++

* lib/target-supports.exp (check_effective_target_c): Fix indentation.
(check_effective_target_c++): Likewise. Also match for libstdc++.

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 770268f..9c5194d 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -7001,9 +7001,9 @@ proc check_effective_target_masm_intel  {} {
# Return 1 if the language for the compiler under test is C.

proc check_effective_target_c { } {
- global tool
+global tool
if [string match $tool "gcc"] {
-   return 1
+   return 1
}
 return 0
}
@@ -7011,9 +7011,9 @@ proc check_effective_target_c { } {
# Return 1 if the language for the compiler under test is C++.

proc check_effective_target_c++ { } {
- global tool
-if [string match $tool "g++"] {
-   return 1
+global tool
+if { [string match $tool "g++"] || [string match $tool "libstdc++"] } {
+   return 1
}
 return 0
}

Re: [PATCH] Make check_effective_target_c++ work for libstdc++

[Ville Voutilainen]

On 7 December 2016 at 13:24, Jonathan Wakely  wrote:
> I'd like to backport this (r238916) to the gcc-6-branch too.
>
> It's been very useful on trunk. The only problems are when we backport
> new tests from trunk to the branch and forget that the effective
> target doesn't work there (which leads to those new tests being
> skipped on the branch as UNSUPPORTED).
>
> Backporting this change to the branch would allow us to backport tests
> without having to tweak them.
>
> OK?


+1, this is immensely useful and indeed helps backporting tests quite a bit.

[Ada] Fix debug info for character subtypes

[Eric Botcazou]

This fixes a regression present on the mainline and 6 branch for the debug 
info of character subtypes, whose bounds are output as signed instead of 
unsigned values as per the language.

Tested on x86_64-suse-linux, applied on the mainline and 6 branch.


2016-12-07  Eric Botcazou  

* gcc-interface/decl.c (gnat_to_gnu_entity) :
Also call finish_character_type on Character subtypes.
* gcc-interface/utils.c (finish_character_type): Deal with subtypes.

-- 
Eric BotcazouIndex: gcc-interface/decl.c
===
--- gcc-interface/decl.c	(revision 24)
+++ gcc-interface/decl.c	(working copy)
@@ -1859,8 +1859,14 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
   TYPE_BIASED_REPRESENTATION_P (gnu_type)
 	= Has_Biased_Representation (gnat_entity);
 
-  /* Set TYPE_STRING_FLAG for Character and Wide_Character subtypes.  */
-  TYPE_STRING_FLAG (gnu_type) = TYPE_STRING_FLAG (TREE_TYPE (gnu_type));
+  /* Do the same processing for Character subtypes as for types.  */
+  if (TYPE_STRING_FLAG (TREE_TYPE (gnu_type)))
+	{
+	  TYPE_NAME (gnu_type) = gnu_entity_name;
+	  TYPE_STRING_FLAG (gnu_type) = 1;
+	  TYPE_ARTIFICIAL (gnu_type) = artificial_p;
+	  finish_character_type (gnu_type);
+	}
 
   /* Inherit our alias set from what we're a subtype of.  Subtypes
 	 are not different types and a pointer can designate any instance
Index: gcc-interface/utils.c
===
--- gcc-interface/utils.c	(revision 24)
+++ gcc-interface/utils.c	(working copy)
@@ -1641,10 +1641,7 @@ record_builtin_type (const char *name, t
   character subtypes with RM_Size = Esize = CHAR_TYPE_SIZE into signed
   types.  The idea is to ensure that the bit pattern contained in the
   Esize'd objects is not changed, even though the numerical value will
-  be interpreted differently depending on the signedness.
-
-  For character types, the bounds are implicit and, therefore, need to
-  be adjusted.  Morever, the debug info needs the unsigned version.  */
+  be interpreted differently depending on the signedness.  */
 
 void
 finish_character_type (tree char_type)
@@ -1658,11 +1655,32 @@ finish_character_type (tree char_type)
? unsigned_char_type_node
: copy_type (gnat_unsigned_type_for (char_type)));
 
+  /* Create an unsigned version of the type and set it as debug type.  */
   TYPE_NAME (unsigned_char_type) = TYPE_NAME (char_type);
   TYPE_STRING_FLAG (unsigned_char_type) = TYPE_STRING_FLAG (char_type);
   TYPE_ARTIFICIAL (unsigned_char_type) = TYPE_ARTIFICIAL (char_type);
-
   SET_TYPE_DEBUG_TYPE (char_type, unsigned_char_type);
+
+  /* If this is a subtype, make the debug type a subtype of the debug type
+ of the base type and convert literal bounds to unsigned.  */
+  if (TREE_TYPE (char_type))
+{
+  tree base_unsigned_char_type = TYPE_DEBUG_TYPE (TREE_TYPE (char_type));
+  tree min_value = TYPE_MIN_VALUE (char_type);
+  tree max_value = TYPE_MAX_VALUE (char_type);
+
+  if (TREE_CODE (min_value) == INTEGER_CST)
+	min_value = fold_convert (base_unsigned_char_type, min_value);
+  if (TREE_CODE (max_value) == INTEGER_CST)
+	max_value = fold_convert (base_unsigned_char_type, max_value);
+
+  TREE_TYPE (unsigned_char_type) = base_unsigned_char_type;
+  SET_TYPE_RM_MIN_VALUE (unsigned_char_type, min_value);
+  SET_TYPE_RM_MAX_VALUE (unsigned_char_type, max_value);
+}
+
+  /* Adjust the bounds of the original type to unsigned; that's especially
+ important for types since they are implicit in this case.  */
   SET_TYPE_RM_MIN_VALUE (char_type, TYPE_MIN_VALUE (unsigned_char_type));
   SET_TYPE_RM_MAX_VALUE (char_type, TYPE_MAX_VALUE (unsigned_char_type));
 }

Re: Fold strstr (s, t) eq/ne s to strcmp (s, t) eq/ne 0 if strlen (t) is known

[Prathamesh Kulkarni]

On 5 December 2016 at 23:47, Jakub Jelinek  wrote:
> On Mon, Dec 05, 2016 at 11:32:15PM +0530, Prathamesh Kulkarni wrote:
>> So I had to check if SSA_NAME_DEF_STMT (rhs2) was call to strstr
>> rather than rhs1.
>
> Then you need to test both whether it is strstr (s, t) == s or
> s == strstr (s, t).
>
>> +   gassign *ga = gimple_build_assign (lhs, code,
>> + strcmp_lhs, zero);
>
> The formatting is wrong here.
>
>> +   gsi_replace (&gsi, ga, false);
>> + }
>> + }
>> + }
>> + }
>> + }
>> + }
>>else if (TREE_CODE (lhs) != SSA_NAME && !TREE_SIDE_EFFECTS (lhs))
>>   {
>> tree type = TREE_TYPE (lhs);
>> @@ -2505,7 +2554,7 @@ const pass_data pass_data_strlen =
>>0, /* properties_provided */
>>0, /* properties_destroyed */
>>0, /* todo_flags_start */
>> -  0, /* todo_flags_finish */
>> +  TODO_update_ssa, /* todo_flags_finish */
>
> No, please don't.  Just make sure to build proper SSA right away.
Hi,
Thanks for the suggestions, I have tried to modify the patch accordingly.
Does this version look OK ?
Bootstrap+tested on x86_64-unknown-linux-gnu with --enable-languages=all,ada
Cross tested on arm*-*-*, aarch64*-*-*.

Thanks,
Prathamesh
>
> Jakub
2016-12-07  Prathamesh Kulkarni  

* tree-ssa-strlen.c (strlen_optimize_stmt): Fold strstr(s, t) == s to
memcmp (s, t, strlen (t)) == 0.
Include tree-into-ssa.h.

testsuite/
* gcc.dg/strlenopt-30.c: New test-case.

diff --git a/gcc/testsuite/gcc.dg/strlenopt-30.c 
b/gcc/testsuite/gcc.dg/strlenopt-30.c
new file mode 100644
index 000..603e23c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/strlenopt-30.c
@@ -0,0 +1,42 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-strlen" } */
+
+__attribute__((no_icf))
+_Bool f1(char *s)
+{
+  return __builtin_strstr (s, "hello") == s;
+}
+
+__attribute__((no_icf))
+_Bool f2(char *s)
+{
+  return s == __builtin_strstr (s, "hello");
+}
+
+__attribute__((no_icf))
+_Bool f3(char *s)
+{
+  return s != __builtin_strstr (s, "hello");
+}
+
+__attribute__((no_icf))
+_Bool f4(char *s, char *t)
+{
+  return __builtin_strstr (s, t) == s;
+}
+
+/* Do not perform transform in this case, since
+   t1 doesn't have single use.  */
+
+__attribute__((no_icf))
+_Bool f5(char *s, char *t)
+{
+  void foo(char *);
+
+  char *t1 = __builtin_strstr (s, t);
+  foo (t1);
+  return (t1 == s);
+}
+
+/* { dg-final { scan-tree-dump-times "__builtin_memcmp" 4 "strlen" } } */
+/* { dg-final { scan-tree-dump-times "__builtin_strlen" 1 "strlen" } } */
diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index 339812e..b7f4cee 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -45,6 +45,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "ipa-chkp.h"
 #include "tree-hash-traits.h"
 #include "builtins.h"
+#include "tree-into-ssa.h"
 
 /* A vector indexed by SSA_NAME_VERSION.  0 means unknown, positive value
is an index into strinfo vector, negative value stands for
@@ -2302,7 +2303,94 @@ strlen_optimize_stmt (gimple_stmt_iterator *gsi)
  else if (gimple_assign_rhs_code (stmt) == POINTER_PLUS_EXPR)
handle_pointer_plus (gsi);
}
-  else if (TREE_CODE (lhs) != SSA_NAME && !TREE_SIDE_EFFECTS (lhs))
+
+  /* Fold strstr (s, t) == s to memcmp (s, t, strlen (t)) == 0.
+if var holding return value of strstr has single use.  */
+
+  else if (TREE_CODE (lhs) == SSA_NAME && INTEGRAL_TYPE_P (TREE_TYPE 
(lhs)))
+   {
+ enum tree_code code = gimple_assign_rhs_code (stmt);
+ if (code == EQ_EXPR || code == NE_EXPR)
+   {
+ tree rhs1 = gimple_assign_rhs1 (stmt);
+ tree rhs2 = gimple_assign_rhs2 (stmt);
+ if (TREE_CODE (rhs1) == SSA_NAME
+ && TREE_CODE (rhs2) == SSA_NAME)
+   {
+ gcall *call_stmt = dyn_cast (SSA_NAME_DEF_STMT 
(rhs1));
+ if (!call_stmt)
+   {
+ call_stmt = dyn_cast (SSA_NAME_DEF_STMT (rhs2));
+ tree tmp = rhs1;
+ rhs1 = rhs2;
+ rhs2 = tmp;
+   }
+
+ tree call_lhs;
+ if (call_stmt
+ && gimple_call_builtin_p (call_stmt, BUILT_IN_STRSTR)
+ && (call_lhs = gimple_call_lhs (call_stmt))
+ && has_single_use (call_lhs))
+   {
+ tree arg0 = gimple_call_arg (call_stmt, 0);
+ if (operand_equal_p (arg0, rhs2, 0))
+   {
+ tree arg1 = gimple_call_arg (call_stmt, 1);
+ tree arg1_len = NULL_TREE;
+ int idx = get_stridx (arg1);
+
+ if (idx)
+

Re: config/ sync with binutils vs. removing gcc targets.

[Oleg Endo]

Hi,

Yeah, my SH5/SH64 removal procedures might have been a little too
radical, sorry about that.  However ...

On Wed, 2016-12-07 at 09:10 +1030, Alan Modra wrote:
> I understand that config/ in the gcc repository is the master source
> for binutils-gdb config/.  If that's the case then people removing
> gcc support for particular targets need to be careful about their
> config/ edits.  If a target is still supported in binutils, then
> please don't rip out config/ support for the target.

How exactly is this going to work when support for a configuration has
been removed from the compiler, but not from the configuration itself?
 That's just confusing for the user and doesn't make sense, I believe.

Cheers,
Oleg

[Ada] Translate System.Address into void* for foreign convention

[Eric Botcazou]

This was already the case for convention C.

Tested on x86_64-suse-linux, applied on the mainline.


2016-12-07  Eric Botcazou  

* gcc-interface/decl.c (gnat_to_gnu_entity) : Translate
System.Address into ptr_type_node for every foreign convention.
(gnat_to_gnu_subprog_type): Likewise for result and parameter types.
(gnat_to_gnu_param): Do not do it here for GCC builtins.
(intrin_return_compatible_p): Likewise.

-- 
Eric BotcazouIndex: gcc-interface/decl.c
===
--- gcc-interface/decl.c	(revision 243336)
+++ gcc-interface/decl.c	(working copy)
@@ -645,7 +645,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
 	  }
 
 	/* Get the type after elaborating the renamed object.  */
-	if (Convention (gnat_entity) == Convention_C
+	if (Has_Foreign_Convention (gnat_entity)
 	&& Is_Descendant_Of_Address (gnat_type))
 	  gnu_type = ptr_type_node;
 	else
@@ -5404,12 +5404,6 @@ gnat_to_gnu_param (Entity_Id gnat_param,
 gnu_param_type
   = TREE_TYPE (TREE_TYPE (TYPE_FIELDS (TREE_TYPE (gnu_param_type;
 
-  /* For GCC builtins, pass Address integer types as (void *)  */
-  if (Convention (gnat_subprog) == Convention_Intrinsic
-  && Present (Interface_Name (gnat_subprog))
-  && Is_Descendant_Of_Address (gnat_param_type))
-gnu_param_type = ptr_type_node;
-
   /* Arrays are passed as pointers to element type for foreign conventions.  */
   if (foreign && mech != By_Copy && TREE_CODE (gnu_param_type) == ARRAY_TYPE)
 {
@@ -5784,7 +5778,9 @@ gnat_to_gnu_subprog_type (Entity_Id gnat
 
   else
 {
-  if (Convention (gnat_subprog) == Convention_C
+  /* For foreign convention subprograms, return System.Address as void *
+	 or equivalent.  Note that this comprises GCC builtins.  */
+  if (Has_Foreign_Convention (gnat_subprog)
 	  && Is_Descendant_Of_Address (gnat_return_type))
 	gnu_return_type = ptr_type_node;
   else
@@ -5949,7 +5945,9 @@ gnat_to_gnu_subprog_type (Entity_Id gnat
 	{
 	  Entity_Id gnat_param_type = Etype (gnat_param);
 
-	  if (Convention (gnat_subprog) == Convention_C
+	  /* For foreign convention subprograms, pass System.Address as void *
+	 or equivalent.  Note that this comprises GCC builtins.  */
+	  if (Has_Foreign_Convention (gnat_subprog)
 	  && Is_Descendant_Of_Address (gnat_param_type))
 	gnu_param_type = ptr_type_node;
 	  else
@@ -8910,10 +8908,6 @@ intrin_return_compatible_p (intrin_bindi
   && !VOID_TYPE_P (btin_return_type))
 return true;
 
-  /* If return type is Address (integer type), map it to void *.  */
-  if (Is_Descendant_Of_Address (Etype (inb->gnat_entity)))
-ada_return_type = ptr_type_node;
-
   /* Check return types compatibility otherwise.  Note that this
  handles void/void as well.  */
   if (intrin_types_incompatible_p (btin_return_type, ada_return_type))

Re: [Patch PR78561 PowerPC] Revert to old behaviour for counting constant pools

[Segher Boessenkool]

Hi James,

On Wed, Dec 07, 2016 at 10:31:14AM +, James Greenhalgh wrote:
> We always keep the entries in the constant pool after we first see them, and
> we figure out what gets used in the constant pool by sweeping through
> looking for referenced entries. That means we can always answer the
> question "has the constant pool ever had entries?" by checking if there
> is anything at all in there.
> 
> So that's what this patch does.
> 
> Bootstrapped on gcc110 (powerpc64-none-linux-gnu) configured with
> --enable-languages=all,ada,go,obj-c++ with no issues, Segher has also
> tested it with no issues, and I've tested an aarch64-none-elf cross
> compiler to ensure that the original fix still works on AArch64.
> 
> OK?

The rs6000 changes are okay for trunk.  The rest I cannot approve (but
it does look fine).  Thanks,


Segher


> 2016-12-07  James Greenhalgh  
> 
>   PR rtl-optimization/78561
>   * config/rs6000/rs6000.c (rs6000_reg_live_or_pic_offset_p) Use

(Missing colon here)

>   constant_pool_empty_p in place of get_pool_size_upper_bound.
>   (rs6000_stack_info): Likewise.
>   (rs6000_emit_prologue): Likewise.
>   (rs6000_elf_declare_function_name): Likewise.
>   (rs6000_set_up_by_prologue): Likewise.
>   (rs6000_can_eliminate): Likewise.
>   * output.h (get_pool_size_upper_bound): Delete.
>   (constant_pool_empty_p): New.
>   * varasm.c (get_pool_size_upper_bound): Delete
>   (constant_pool_empty_p): New.

[Ada] Fix glitch in debug info for renaming

[Eric Botcazou]

GDB cannot inspect renamings declared at library level when it relies on the 
special __XR variable generated as per the GNAT encodings.

Tested on x86_64-suse-linux, applied on the mainline.


2016-12-07  Pierre-Marie de Rodat  

* gcc-interface/decl.c (gnat_to_gnu_entity): When they are global,
consider ___XR GNAT encodings variables for renamings as static so
they have a location in the debug info.

-- 
Eric BotcazouIndex: gcc-interface/decl.c
===
--- gcc-interface/decl.c	(revision 243340)
+++ gcc-interface/decl.c	(working copy)
@@ -672,6 +672,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
    VAR_DECL, gnu_entity_name, gnu_type);
 	SET_DECL_VALUE_EXPR (gnu_decl, value);
 	DECL_HAS_VALUE_EXPR_P (gnu_decl) = 1;
+	TREE_STATIC (gnu_decl) = global_bindings_p ();
 	gnat_pushdecl (gnu_decl, gnat_entity);
 	break;
 	  }

Re: Fold strstr (s, t) eq/ne s to strcmp (s, t) eq/ne 0 if strlen (t) is known

[Jakub Jelinek]

On Wed, Dec 07, 2016 at 05:02:46PM +0530, Prathamesh Kulkarni wrote:
> +   if (arg1_len == NULL_TREE)
> + {
> +   gimple_stmt_iterator gsi;
> +   tree strlen_decl;
> +   gimple *strlen_call;
> +
> +   strlen_decl = builtin_decl_explicit 
> (BUILT_IN_STRLEN);
> +   strlen_call = gimple_build_call (strlen_decl, 1,
> +arg1);
> +   arg1_len = make_ssa_name (size_type_node);
> +   gimple_call_set_lhs (strlen_call, arg1_len);
> +   update_stmt (strlen_call);
> +   gsi = gsi_for_stmt (call_stmt);
> +   gsi_insert_before (&gsi, strlen_call, 
> GSI_SAME_STMT);
> + }

Why?  If the strlen isn't readily available, do you really think it is
always a win to replace one call with 2 calls?  The string you want to do
strlen on can be huge, the haystack could be empty or very short, etc.
I'd just punt if strlen isn't known.
> +
> +   gimple_stmt_iterator gsi = gsi_for_stmt (call_stmt);
> +   tree memcmp_decl = builtin_decl_explicit 
> (BUILT_IN_MEMCMP);
> +   gcall *memcmp_call
> + = gimple_build_call (memcmp_decl, 3, arg0, arg1,
> +  arg1_len);
> +   tree memcmp_lhs = make_ssa_name (integer_type_node);
> +   gimple_call_set_lhs (memcmp_call, memcmp_lhs);
> +   update_stmt (memcmp_call);
> +   gsi_remove (&gsi, true);
> +   gsi_insert_before (&gsi, memcmp_call, GSI_SAME_STMT);
> +
> +   gsi = gsi_for_stmt (stmt);
> +   tree zero = build_zero_cst (TREE_TYPE (memcmp_lhs));
> +   gassign *ga = gimple_build_assign (lhs, code,
> +  memcmp_lhs, zero);
> +   gsi_replace (&gsi, ga, false);
> +   update_ssa (TODO_update_ssa);

And this is certainly even more wrong than the old TODO_update_ssa at the
end of the pass, now you'll do it for every single replacement in the
function.  Why do you need it?  The old call stmt has gimple_vdef and
gimple_vuse, so just copy those over, see how e.g.
replace_call_with_call_and_fold in gimple-fold.c does that.
If you don't add strlen, you need to move the vdef/vuse from stmt to
memcmp_call, if you really want to add strlen (see above note though),
then that call should have a vuse added (same vuse as the stmt originally
had).

Jakub

Re: [Patch, fortran] PR44265 - Link error with reference to parameter array in specification expression

[Dominique d'Humières]

Dear Paul,

I have found another glitch with all the patches in this thread: they transform 
an ICE to accept-invalid for the tests z7.f90, z8.f90, and z9.f90 in pr77414.

Dominique

> Le 10 nov. 2016 à 23:48, Dominique d'Humières  a écrit :
> 
> FAIL: gfortran.dg/char_result_16.f90   -g -flto  (internal compiler error)
> FAIL: gfortran.dg/char_result_16.f90   -g -flto  (test for excess errors)
> 
> The ICE is for both -m32 and -m64 (module_procedure_3_db_1.f90 is the test 
> posted in my last mail)
> 
> % gfc module_procedure_3_db_1.f90 -flto
> module_procedure_3_db_1.f90:29:0: internal compiler error: in 
> get_partitioning_class, at symtab.c:1848
> END PROGRAM WheresThatbLinkingConstantGone
> 
> Sorry to be such a nuisance!-(
> 
> Dominique
> 

Re: [PATCH] Remove x86 pcommit instruction

[Andrew Senkevich]

2016-10-14 12:23 GMT+03:00 Richard Biener :
> On Thu, Oct 13, 2016 at 11:39 PM, H.J. Lu  wrote:
>> On Thu, Oct 13, 2016 at 5:09 AM, Andrew Senkevich
>>  wrote:
>>> 2016-10-11 20:09 GMT+03:00 H.J. Lu :
 On Tue, Oct 11, 2016 at 10:04 AM, Andrew Senkevich
  wrote:
> 2016-10-06 1:07 GMT+03:00 H.J. Lu :
>> On Wed, Oct 5, 2016 at 1:42 PM, Andrew Senkevich
>>  wrote:
>>> 2016-10-05 18:06 GMT+03:00 Uros Bizjak :
 On Wed, Oct 5, 2016 at 3:47 PM, Andrew Senkevich
  wrote:
>> -mpcommit
>> -Target Report Mask(ISA_PCOMMIT) Var(ix86_isa_flags) Save
>> -Support PCOMMIT instruction.
>> -
>>
>> You should not simply delete a option that was in the released
>> compiler, but a warning should be emitted instead. Please see how
>> msse5 is handled in i386.opt.
>
> Thank you, it is fixed in patch below. Ok for trunk?

 OK.

> Is it subject for backport for 5.* and 6.* releases?

 Yes, but please wait a couple of days if any problem arises in trunk.

 (Please also provide an entry for Release Changes, since this is
 user-facing change. Also for release branches.)
>>>
>>> Hi HJ,
>>>
>>> could you please commit this patch for trunk since I have no commit 
>>> rights.
>>> Attached in format for git am.
>>>
>>>
>>
>> Done.
>
> Thanks, HJ!
>
> Should I ask you or somebody else for backports for to 5.* and 6.* or
> may be I can somehow get commit after approval rights to don't disturb
> others with commits? I am preparing several patches.
>

 Please provide patches for GCC 5 and 6.
>>>
>>> Attached.
>>
>> I checked them into GCC 5 and GCC 6 branches.
>>
>>> Have you possibility to update according changes.html files?
>>>
>>
>> Here is the patch for GCC 7.  I am not sure what to do with GCC
>> 5 and 6.
>
> There are entries for each sub-release (if not for the next then add one).
>
> Richard.
>
>> --
>> H.J.
>> ---
>> Index: gcc-7/changes.html
>> ===
>> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
>> retrieving revision 1.18
>> diff -u -p -r1.18 changes.html
>> --- gcc-7/changes.html 12 Oct 2016 11:08:25 - 1.18
>> +++ gcc-7/changes.html 13 Oct 2016 21:37:18 -
>> @@ -318,7 +318,14 @@ const int* get_address (unsigned idx)
>>
>>  
>>
>> -
>> +IA-32/x86-64
>> +   
>> + 
>> +   Support for
>> +   > href="https://software.intel.com/en-us/blogs/2016/09/12/deprecate-pcommit-instruction";>deprecated
>> +   pcommit instruction has been removed.
>> + 
>> +   
>>
>>  

But how to update changes for upcoming GCC 6.3 (and future GCC 5.5)?


--
WBR,
Andrew

Re: [PATCH] Remove x86 pcommit instruction

[Uros Bizjak]

On Wed, Dec 7, 2016 at 1:25 PM, Andrew Senkevich
 wrote:

> But how to update changes for upcoming GCC 6.3 (and future GCC 5.5)?

There are corresponding documents at  [1] and [2], please add a "GCC
6.3" or "GCC 5.5" entry with "Target Specific Changes" at the end of
the documents.

[1] https://gcc.gnu.org/gcc-6/changes.html
[2] https://gcc.gnu.org/gcc-5/changes.html

Uros.

Re: config/ sync with binutils vs. removing gcc targets.

[Alan Modra]

On Wed, Dec 07, 2016 at 08:46:32PM +0900, Oleg Endo wrote:
> Hi,
> 
> Yeah, my SH5/SH64 removal procedures might have been a little too
> radical, sorry about that.  However ...
> 
> On Wed, 2016-12-07 at 09:10 +1030, Alan Modra wrote:
> > I understand that config/ in the gcc repository is the master source
> > for binutils-gdb config/.  If that's the case then people removing
> > gcc support for particular targets need to be careful about their
> > config/ edits.  If a target is still supported in binutils, then
> > please don't rip out config/ support for the target.
> 
> How exactly is this going to work when support for a configuration has
> been removed from the compiler, but not from the configuration itself?
>  That's just confusing for the user and doesn't make sense, I believe.

The files in the config/ directory don't select which targets are
supported by gcc.  That selection is done in other files, like
config.gcc.  I don't see anything that would be confusing to users by
leaving sh5 patterns in say config/picflag.m4.

The config/* files are similar to config.guess and config.sub.  Just
as you do not touch config.guess and config.sub when removing a target
from gcc support, so you should not need to modify config/*.

-- 
Alan Modra
Australia Development Lab, IBM

[C++ PATCH] cache auto/decltype(auto) identifiers

[Nathan Sidwell]

While lookign at generic lambda mangling, I noticed we like to use 
'get_identifier ("auto")' a lot.  Particularly in is_auto, which is 
called during tree walking.  That's needlessly expensive.


Fixed by adding a couple of new global identifiers.  Committed.

nathan
--
Nathan Sidwell
2016-12-07  Nathan Sidwell  

	* cp-tree.h (enum cp_tree_index): Add CPTI_AUTO_IDENTIFIER &
	CPTI_DECLTYPE_AUTO_IDENTIFIER.
	(auto_identifier, decltype_auto_identifier): New.
	*decl.c (initialize_predefined_identifiers): Add 'auto' and
	'decltype(auto)'.
	(grokdeclarator): Use cached identifier.
	* pt.c (make_decltype_auto, make_auto, make_constrained_auto,
	is_auto): Likewise.

Index: cp/cp-tree.h
===
--- cp/cp-tree.h	(revision 243314)
+++ cp/cp-tree.h	(working copy)
@@ -1117,6 +1117,8 @@ enum cp_tree_index
 CPTI_PFN_IDENTIFIER,
 CPTI_VPTR_IDENTIFIER,
 CPTI_STD_IDENTIFIER,
+CPTI_AUTO_IDENTIFIER,
+CPTI_DECLTYPE_AUTO_IDENTIFIER,
 
 CPTI_LANG_NAME_C,
 CPTI_LANG_NAME_CPLUSPLUS,
@@ -1200,6 +1202,9 @@ extern GTY(()) tree cp_global_trees[CPTI
 #define vptr_identifier			cp_global_trees[CPTI_VPTR_IDENTIFIER]
 /* The name of the std namespace.  */
 #define std_identifier			cp_global_trees[CPTI_STD_IDENTIFIER]
+/* auto and declspec(auto) identifiers.  */
+#define auto_identifier			cp_global_trees[CPTI_AUTO_IDENTIFIER]
+#define decltype_auto_identifier	cp_global_trees[CPTI_DECLTYPE_AUTO_IDENTIFIER]
 /* The name of a C++17 deduction guide.  */
 #define lang_name_c			cp_global_trees[CPTI_LANG_NAME_C]
 #define lang_name_cplusplus		cp_global_trees[CPTI_LANG_NAME_CPLUSPLUS]
Index: cp/decl.c
===
--- cp/decl.c	(revision 243314)
+++ cp/decl.c	(working copy)
@@ -4034,6 +4034,8 @@ initialize_predefined_identifiers (void)
 { "__vtt_parm", &vtt_parm_identifier, 0 },
 { "::", &global_scope_name, 0 },
 { "std", &std_identifier, 0 },
+{ "auto", &auto_identifier, 0 },
+{ "decltype(auto)", &decltype_auto_identifier, 0 },
 { NULL, NULL, 0 }
   };
 
@@ -10600,7 +10602,7 @@ grokdeclarator (const cp_declarator *dec
 	  gcc_unreachable ();
 	}
   if (TREE_CODE (type) != TEMPLATE_TYPE_PARM
-	  || TYPE_IDENTIFIER (type) != get_identifier ("auto"))
+	  || TYPE_IDENTIFIER (type) != auto_identifier)
 	{
 	  if (type != error_mark_node)
 	{
Index: cp/pt.c
===
--- cp/pt.c	(revision 243314)
+++ cp/pt.c	(working copy)
@@ -24302,13 +24302,13 @@ make_auto_1 (tree name, bool set_canonic
 tree
 make_decltype_auto (void)
 {
-  return make_auto_1 (get_identifier ("decltype(auto)"), true);
+  return make_auto_1 (decltype_auto_identifier, true);
 }
 
 tree
 make_auto (void)
 {
-  return make_auto_1 (get_identifier ("auto"), true);
+  return make_auto_1 (auto_identifier, true);
 }
 
 /* Return a C++17 deduction placeholder for class template TMPL.  */
@@ -24330,7 +24330,7 @@ make_template_placeholder (tree tmpl)
 tree
 make_constrained_auto (tree con, tree args)
 {
-  tree type = make_auto_1 (get_identifier ("auto"), false);
+  tree type = make_auto_1 (auto_identifier, false);
 
   /* Build the constraint. */
   tree tmpl = DECL_TI_TEMPLATE (con);
@@ -25016,8 +25016,8 @@ bool
 is_auto (const_tree type)
 {
   if (TREE_CODE (type) == TEMPLATE_TYPE_PARM
-  && (TYPE_IDENTIFIER (type) == get_identifier ("auto")
-	  || TYPE_IDENTIFIER (type) == get_identifier ("decltype(auto)")
+  && (TYPE_IDENTIFIER (type) == auto_identifier
+	  || TYPE_IDENTIFIER (type) == decltype_auto_identifier
 	  || CLASS_PLACEHOLDER_TEMPLATE (type)))
 return true;
   else

[C++ PATCH] {NON,}TYPE_ARGUMENT_PACK substitution

[Nathan Sidwell]

I also noticed argument pack substitution was doing more work than 
necessary -- we've already tsubst'd TYPE just before the big switch. 
Took the opportunity to simplify the control flow a bit further too.


Committed.

nathan
--
Nathan Sidwell
2016-12-07  Nathan Sidwell  

	* pt.c (tsubst <{NON,}TYPE_ARGUMENT_PACK>: Simplify control flow
	and avoid re-tsubsting type.

Index: cp/pt.c
===
--- cp/pt.c	(revision 243342)
+++ cp/pt.c	(working copy)
@@ -13795,22 +13795,23 @@ tsubst (tree t, tree args, tsubst_flags_
 case TYPE_ARGUMENT_PACK:
 case NONTYPE_ARGUMENT_PACK:
   {
-tree r = TYPE_P (t) ? cxx_make_type (code) : make_node (code);
-tree packed_out = 
-  tsubst_template_args (ARGUMENT_PACK_ARGS (t), 
-args,
-complain,
-in_decl);
-SET_ARGUMENT_PACK_ARGS (r, packed_out);
+tree r;
 
-/* For template nontype argument packs, also substitute into
-   the type.  */
-if (code == NONTYPE_ARGUMENT_PACK)
-  TREE_TYPE (r) = tsubst (TREE_TYPE (t), args, complain, in_decl);
+	if (code == NONTYPE_ARGUMENT_PACK)
+	  {
+	r = make_node (code);
+	/* Set the already-substituted type.  */
+	TREE_TYPE (r) = type;
+	  }
+	else
+	  r = cxx_make_type (code);
 
-return r;
+	tree pack_args = ARGUMENT_PACK_ARGS (t);
+	pack_args = tsubst_template_args (pack_args, args, complain, in_decl);
+	SET_ARGUMENT_PACK_ARGS (r, pack_args);
+
+	return r;
   }
-  break;
 
 case VOID_CST:
 case INTEGER_CST:

Re: Fix PR77309, combine eliminates sign bit comparison

[Bernd Schmidt]

On 10/28/2016 03:43 PM, Segher Boessenkool wrote:

On Fri, Oct 28, 2016 at 01:18:19PM +0200, Bernd Schmidt wrote:

In this PR, we manage to simplify the code down to

(lt (and (reg) (signbit)) (const 0))

simplify_comparison then calls make_compound_operation on the AND
expression, and that turns it into a ZERO_EXTRACT of a single bit,
changing the meaning of the comparison.

The problem is a special case we have for comparisons in
make_compound_operation, it thinks it should convert single-bit ANDs
into such extractions. But this is only valid if the bit isn't the sign
bit, or if we're testing for equality with zero.

The following patch was bootstrapped and tested on x86_64-linux. Ok?


Okay, thanks!


Branches too?


Bernd

Re: config/ sync with binutils vs. removing gcc targets.

[Bernd Schmidt]

On 12/06/2016 11:40 PM, Alan Modra wrote:

I understand that config/ in the gcc repository is the master source
for binutils-gdb config/.  If that's the case then people removing
gcc support for particular targets need to be careful about their
config/ edits.  If a target is still supported in binutils, then
please don't rip out config/ support for the target.

I also didn't apply one of my binutils changes to gcc's config/,
so to sync with binutils I'd like to apply the following to gcc.
gcc doesn't use AC_PROG_LEX.

OK to apply?

* elf.m4: Revert 2016-06-21 change.
* picflag.m4: Likewise.  Revert 2016-04-30 change too.
* override.m4 (AC_PROG_LEX): Import 2016-01-18 binutils fix
for PR binutils/19481.


I think this is OK for now. Have you considered removing support for 
those dead targets from binutils?



Bernd

Re: [PATCH][AArch64] Improve SHA1 scheduling

[Wilco Dijkstra]

James Greenhalgh wrote:

> I haven't seen a follow-up to Andrew's point regarding other
> read-modify-write operations.
> 
> Did youi investigate the cost of these?

I looked at whether there are other similar cases, but it appears SHA1
is unique due to the odd dataflow, the mismatch in latencies and the high
repetition.  So it seems best to handle it as a special case.

What does seem useful is teaching GCC to prefer using the same
register for accumulators.  That is a general issue that would improve
performance in many cases. 

Wilco

Re: [PATCH] Remove x86 pcommit instruction

[Andrew Senkevich]

2016-12-07 15:34 GMT+03:00 Uros Bizjak :
> On Wed, Dec 7, 2016 at 1:25 PM, Andrew Senkevich
>  wrote:
>
>> But how to update changes for upcoming GCC 6.3 (and future GCC 5.5)?
>
> There are corresponding documents at  [1] and [2], please add a "GCC
> 6.3" or "GCC 5.5" entry with "Target Specific Changes" at the end of
> the documents.
>
> [1] https://gcc.gnu.org/gcc-6/changes.html
> [2] https://gcc.gnu.org/gcc-5/changes.html

Attached patches, who will apply them?


--
WBR,
Andrew


gcc5.5_changes.patch
Description: Binary data


gcc6.3_changes.patch
Description: Binary data

Re: Fix PR77309, combine eliminates sign bit comparison

[Segher Boessenkool]

On Wed, Dec 07, 2016 at 02:02:17PM +0100, Bernd Schmidt wrote:
> On 10/28/2016 03:43 PM, Segher Boessenkool wrote:
> >On Fri, Oct 28, 2016 at 01:18:19PM +0200, Bernd Schmidt wrote:
> >>In this PR, we manage to simplify the code down to
> >>
> >>(lt (and (reg) (signbit)) (const 0))
> >>
> >>simplify_comparison then calls make_compound_operation on the AND
> >>expression, and that turns it into a ZERO_EXTRACT of a single bit,
> >>changing the meaning of the comparison.
> >>
> >>The problem is a special case we have for comparisons in
> >>make_compound_operation, it thinks it should convert single-bit ANDs
> >>into such extractions. But this is only valid if the bit isn't the sign
> >>bit, or if we're testing for equality with zero.
> >>
> >>The following patch was bootstrapped and tested on x86_64-linux. Ok?
> >
> >Okay, thanks!
> 
> Branches too?

Sure, after it has soaked on trunk for a while.


Segher

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

[Lynn A. Boger]

Yes I rebuilt everything and now it all looks good.  The previously 
failing testcases


are now passing and no new regressions.  I must have had something set 
incorrectly


in my environment on my first try.

Thanks!

On 12/06/2016 04:26 PM, Eric Botcazou wrote:

I tried this patch applied against latest and it fixed the testcases
that I had reported as failing, but the patch also causes

libgo reflect testcase to fail.  Still testing to verify and will report
the failure details.

Please double check, as I can reproduce neither on PowerPC64 nor on x86-64.

In any case, the patch just reverts a problematic change so can do no harm.

Re: Hurd port for gcc go PATCH 1-4(23)

[Svante Signell]

On Sun, 2016-11-27 at 18:02 +0100, Samuel Thibault wrote:
> Hello,
> 
> Svante Signell, on Sun 27 Nov 2016 17:33:52 +0100, wrote:
> > > > 
> > > And
> > > src_libgo_go_syscall_syscall_gnu_test.go: New file:
> > >   Define Type and Whence as 32bit in syscall.Flock_t
> > > 
> > > Again, you'll probably have to discuss with upstream to see how they
> > > prefer to make it configurable rather than forking the whole file.
> > > 

I found the answer, see below!

> > I tried to patch the syscall_unix_test.go file, but did not succeed. 
> > Definitely if runtime.GOOS == "GNU" ... else ... or switch runtime.GOOS
> > ... does not work. The compiler sees all code and complains, also the
> > else part of the code :( Therefore I created a new file.
> 
> Then ask upstream how they think it can and should be done.
> 

Since go does not have a preprocessor allowing conditional code paths this is
how it should be done (and as I did):
http://blog.ralch.com/tutorial/golang-conditional-compilation/

Verdict
===
We should aim to develop and build our Go applications by following Go idioms.
If the source file targets a specific platform, we should choose file suffix
approach. Otherwise, if the source file is applicable for multiple platforms and
we want to exclude a specific feature or platform, we should use build
constraints instead.

Build constraints
=
A build constraints (known as build tags) is an optional top line comment that
starts with

// +build

package api

File suffixes
=
The second option for conditional compilation is the name of the
source file itself. This approach is simpler than build tags, and allows
the Go build system to exclude files without having to process the file.

We should add one of the following suffixes to desired files:

*_GOOS // operation system
*_GOARCH // platform architecture
*_GOOS_GOARCH // both combined

Re: [Patch PR78561 PowerPC] Revert to old behaviour for counting constant pools

[Bernd Schmidt]

On 12/07/2016 12:56 PM, Segher Boessenkool wrote:

On Wed, Dec 07, 2016 at 10:31:14AM +, James Greenhalgh wrote:

We always keep the entries in the constant pool after we first see them, and
we figure out what gets used in the constant pool by sweeping through
looking for referenced entries. That means we can always answer the
question "has the constant pool ever had entries?" by checking if there
is anything at all in there.

So that's what this patch does.

Bootstrapped on gcc110 (powerpc64-none-linux-gnu) configured with
--enable-languages=all,ada,go,obj-c++ with no issues, Segher has also
tested it with no issues, and I've tested an aarch64-none-elf cross
compiler to ensure that the original fix still works on AArch64.

OK?


The rs6000 changes are okay for trunk.  The rest I cannot approve (but
it does look fine).  Thanks,


Ok for the rest.


Bernd

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

[Eric Botcazou]

> Yes I rebuilt everything and now it all looks good.  The previously
> failing testcases are now passing and no new regressions.  I must have had
> something set incorrectly in my environment on my first try.

Thanks for confirming.

-- 
Eric Botcazou

Re: Hurd port for gcc go PATCH 1-4(23)

[Samuel Thibault]

Svante Signell, on Wed 07 Dec 2016 14:52:35 +0100, wrote:
> Since go does not have a preprocessor allowing conditional code paths this is
> how it should be done (and as I did):
> http://blog.ralch.com/tutorial/golang-conditional-compilation/

Ok, but then I'd say move the function which change to a separate file,
so that the other functions are kept shared.
Otherwise it'll be tedious to maintain.

Samuel

Re: [LRA] Fix ICE on pathological testcase

[Bernd Edlinger]

On 12/07/16 10:44, Richard Sandiford wrote:
> Bernd Edlinger  writes:
>> Hi Eric,
>>
>> what you got there, looks more or less exactly like what I tried
>> to fix with that patch a few months ago, but unfortunately
>> we were unable to get a consensus on that approach:
>>
>> [PATCH] Fix asm X constraint (PR inline-asm/59155)
>> https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01649.html
>
> Does your patch also fix Eric's testcase?  If so then that approach
> looks safer to me FWIW.  The problem with allowing arbitrary MEMs
> is that it's just not clear:
>

Yes.  I tried the latest patch from here:
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01363.html

And built a sparc64-elf cross-compiler with that.  It fixes the
reported crash and makes the asm argument even printable.

> (a) which other parts of the compiler (including target code) needs
> to handle these arbitrary MEMs.  One instance is the target-specific
> code for printing an address, as Jakub says in that thread, but it
> could also affect things like cost calculations, etc.
>
> (b) should a spilled pseudo in the MEM be replaced with a MEM itself,
> so that even RISC targets have to support nested MEMs?  Or should
> pseudo registers be reloaded?  If so, into which register classes?
> Should they be divided into base and index registers in the normal
> way?  That's difficult to do if we can't decompose the address.
>

(c) there is no way how to test these unreasonably complex RTXes.
 They are created just by random optimizations.

> Reload's always been a recurring source of problems, so the fact
> that this particular case went through without an ICE doesn't mean
> that arbitrary MEMs were actually safe in general.
>

There are not safe at all.  There are lots of different ways how we can
ICE with asm X constraints.


Jeff, what should we do here?


Thanks
Bernd.

Re: Hurd port for gcc go PATCH 1-4(23)

[Svante Signell]

On Wed, 2016-12-07 at 15:08 +0100, Samuel Thibault wrote:
> Svante Signell, on Wed 07 Dec 2016 14:52:35 +0100, wrote:
> > Since go does not have a preprocessor allowing conditional code paths this
> > is
> > how it should be done (and as I did):
> > http://blog.ralch.com/tutorial/golang-conditional-compilation/
> 
> Ok, but then I'd say move the function which change to a separate file,
> so that the other functions are kept shared.
> Otherwise it'll be tedious to maintain.

One problem is the file go/syscall/libcall_posix-1.go, derived
from go/syscall/libcall_posix.go but _removing_ four function definitions:
mount, madvise, mlockall and munlockall. A possible solution would then be to
rename that file to libcall_posix_gnu.go. The file libcall_gnu.go name is
already used.

Re: IRA combine_and_move_insns fix, PR78669

[Vladimir N Makarov]

On 12/06/2016 01:10 PM, Bernd Schmidt wrote:
In this PR, we have two registers with "replace" set for them. When 
processing the first, we delete its setter, which happens to be the 
only use of the other register. In the second iteration we then assert 
that the other register has a use, which would be reasonable if we 
hadn't deleted it.


The following fixes it. Bootstrapped and tested on x86_64-linux, ok?


Sure, Bernd.

Please, use effective target Uros proposed in the test (btw I recently 
did the same mistake with one my test too).

[PATCH PR78684]Check sign bit for index step of data reference.

[Bin Cheng]

Hi,
This patch fixes ICE reported in PR78684, it checks sign bit of integer const 
thus can handle unsigned types.  Bootstrap and test on x86_64, is it OK?

Thanks,
bin

2016-12-06  Bin Cheng  

PR middle-end/78684
* tree-vect-loop-manip.c (create_intersect_range_checks_index): Check
sign bit for index step of data reference.

gcc/testsuite/ChangeLog
2016-12-06  Bin Cheng  

PR middle-end/78684
* g++.dg/torture/pr78684.C: New test.diff --git a/gcc/testsuite/g++.dg/torture/pr78684.C 
b/gcc/testsuite/g++.dg/torture/pr78684.C
new file mode 100644
index 000..5d71be5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/pr78684.C
@@ -0,0 +1,20 @@
+// PR middle-end/78684
+// { dg-do compile }
+
+class a {
+public:
+  a(long);
+  void operator<<=(long) {
+long b;
+for (unsigned long c; c; c--)
+  d[c + b] = d[c];
+  }
+  a &g();
+  long d[28];
+};
+long e;
+int f;
+void j() {
+  a h(e), i = h;
+  i.g() <<= f;
+}
diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index e13d6a2..beb2f06 100644
--- a/gcc/tree-vect-loop-manip.c
+++ b/gcc/tree-vect-loop-manip.c
@@ -2070,8 +2070,7 @@ create_intersect_range_checks_index (loop_vec_info 
loop_vinfo, tree *cond_expr,
   /* Index must have const step, otherwise DR_STEP won't be constant.  */
   gcc_assert (TREE_CODE (idx_step) == INTEGER_CST);
   /* Index must evaluate in the same direction as DR.  */
-  gcc_assert (!neg_step
- || tree_int_cst_compare (idx_step, size_zero_node) < 0);
+  gcc_assert (!neg_step || tree_int_cst_sign_bit (idx_step) == 1);
 
   tree min1 = CHREC_LEFT (access1);
   tree min2 = CHREC_LEFT (access2);

[PATCH] Improve tests for contents of header

[Jonathan Wakely]

This test for the contents of the  header doesn't get run for
C++98 mode and doesn't include the C++14 and C++17 additions. I've
split the C++98-only test into a separate file, and added the new
parts so they're tested conditionally depending on how the test is
run.

* testsuite/18_support/headers/new/synopsis.cc: Add C++14 and C++17
declarations.
* testsuite/18_support/headers/new/synopsis_cxx98.cc: New test.

Tested powerpc64le-linux, committed to trunk.

commit ebe7800d702d0019b290d0ce801f4f5f92bc1c20
Author: Jonathan Wakely 
Date:   Wed Dec 7 12:52:33 2016 +

Improve tests for contents of  header

* testsuite/18_support/headers/new/synopsis.cc: Add C++14 and C++17
declarations.
* testsuite/18_support/headers/new/synopsis_cxx98.cc: New test.

diff --git a/libstdc++-v3/testsuite/18_support/headers/new/synopsis.cc 
b/libstdc++-v3/testsuite/18_support/headers/new/synopsis.cc
index f193bf2..8013eea 100644
--- a/libstdc++-v3/testsuite/18_support/headers/new/synopsis.cc
+++ b/libstdc++-v3/testsuite/18_support/headers/new/synopsis.cc
@@ -21,18 +21,25 @@
 
 namespace std {
   class bad_alloc;
+  class bad_array_new_length;
   struct nothrow_t;
   extern const nothrow_t nothrow;
   typedef void (*new_handler)();
-  new_handler set_new_handler(new_handler new_p) throw();
   new_handler get_new_handler() noexcept;
+  new_handler set_new_handler(new_handler new_p) noexcept;
+
+#if __cplusplus > 201402L
+  enum class align_val_t : size_t;
+  // static constexpr size_t hardware_destructive_interference_size;
+  // static constexpr size_t hardware_constructive_interference_size;
+#endif
 }
 
-void* operator new(std::size_t size) throw(std::bad_alloc);
-void* operator new(std::size_t size, const std::nothrow_t&) throw();
+void* operator new(std::size_t size);
+void* operator new(std::size_t size, const std::nothrow_t&) noexcept;
 void  operator delete(void* ptr) throw();
 void  operator delete(void* ptr, const std::nothrow_t&) throw();
-void* operator new[](std::size_t size) throw(std::bad_alloc);
+void* operator new[](std::size_t size);
 void* operator new[](std::size_t size, const std::nothrow_t&) throw();
 void  operator delete[](void* ptr) throw();
 void  operator delete[](void* ptr, const std::nothrow_t&) throw();
@@ -41,3 +48,32 @@ void* operator new  (std::size_t size, void* ptr) throw();
 void* operator new[](std::size_t size, void* ptr) throw();
 void  operator delete  (void* ptr, void*) throw();
 void  operator delete[](void* ptr, void*) throw();
+
+#if __cplusplus >= 201402L
+// C++14 sized deallocation functions
+void  operator delete(void* ptr, std::size_t size) noexcept;
+void  operator delete(void* ptr, std::size_t size,
+  const std::nothrow_t&) noexcept;
+void  operator delete[](void* ptr, std::size_t size) noexcept;
+void  operator delete[](void* ptr, std::size_t size,
+const std::nothrow_t&) noexcept;
+#endif
+
+#if __cplusplus > 201402L
+// C++17 (de)allocation functions for types with new-extended alignment
+void* operator new(std::size_t, std::align_val_t);
+void* operator new(std::size_t, std::align_val_t,
+   const std::nothrow_t&) noexcept;
+void  operator delete(void*, std::align_val_t) noexcept;
+void  operator delete(void*, std::size_t, std::align_val_t) noexcept;
+void  operator delete(void*, std::align_val_t,
+  const std::nothrow_t&) noexcept;
+
+void* operator new[](std::size_t, std::align_val_t);
+void* operator new[](std::size_t, std::align_val_t,
+ const std::nothrow_t&) noexcept;
+void  operator delete[](void*, std::align_val_t) noexcept;
+void  operator delete[](void*, std::size_t, std::align_val_t) noexcept;
+void  operator delete[](void*, std::align_val_t,
+const std::nothrow_t&) noexcept;
+#endif
diff --git a/libstdc++-v3/testsuite/18_support/headers/new/synopsis_cxx98.cc 
b/libstdc++-v3/testsuite/18_support/headers/new/synopsis_cxx98.cc
new file mode 100644
index 000..2b2abd2
--- /dev/null
+++ b/libstdc++-v3/testsuite/18_support/headers/new/synopsis_cxx98.cc
@@ -0,0 +1,43 @@
+// { dg-options "-std=gnu++98" }
+// { dg-do compile }
+
+// Copyright (C) 2007-2016 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// 

[PATCH 1/3] Disable test using std::set_unexcepted for C++17

[Jonathan Wakely]

This function has been removed from C++17, along with dynamic
exception specifications. We haven't removed the function from the
headers yet, but this ensures the test won't start failing once the
front end starts giving an error for the exceptions specs.

* testsuite/18_support/bad_exception/59392.cc: Disable for C++17.

Tested powerpc64le-linux, committed to trunk.

commit dcd76a3e0fb57c41eb8c89bc39f0d543c268f7fb
Author: Jonathan Wakely 
Date:   Wed Dec 7 13:11:36 2016 +

Disable test using std::set_unexcepted for C++17

	* testsuite/18_support/bad_exception/59392.cc: Disable for C++17.

diff --git a/libstdc++-v3/testsuite/18_support/bad_exception/59392.cc b/libstdc++-v3/testsuite/18_support/bad_exception/59392.cc
index 1f11e7a..717f229 100644
--- a/libstdc++-v3/testsuite/18_support/bad_exception/59392.cc
+++ b/libstdc++-v3/testsuite/18_support/bad_exception/59392.cc
@@ -15,6 +15,9 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
+// { dg-options "-Wno-deprecated" }
+// { dg-do run { target c++14_down } }
+
 #include 
 #include 
 

[PATCH 2/3] Use _GLIBCXX_THROW macro in bitmap_allocator

[Jonathan Wakely]

This header should use _GLIBCXX_THROW to make it C++17-friendly.

   * include/ext/bitmap_allocator.h (bitmap_allocator::_S_refill_pool)
   (bitmap_allocator::_M_allocate_single_object)
   (bitmap_allocator::_M_get): Use _GLIBCXX_THROW macro.

Tested powerpc64le-linux, committed to trunk.

commit 88a365b3cc85fdb5260bb6673a6cd1bbff24de72
Author: Jonathan Wakely 
Date:   Wed Dec 7 13:22:24 2016 +

Use _GLIBCXX_THROW macro in bitmap_allocator

* include/ext/bitmap_allocator.h (bitmap_allocator::_S_refill_pool)
(bitmap_allocator::_M_allocate_single_object)
(bitmap_allocator::_M_get): Use _GLIBCXX_THROW macro.

diff --git a/libstdc++-v3/include/ext/bitmap_allocator.h 
b/libstdc++-v3/include/ext/bitmap_allocator.h
index 836abc8..80ea64f 100644
--- a/libstdc++-v3/include/ext/bitmap_allocator.h
+++ b/libstdc++-v3/include/ext/bitmap_allocator.h
@@ -648,7 +648,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  *  equal to that requested.
  */
 size_t*
-_M_get(size_t __sz) throw(std::bad_alloc);
+_M_get(size_t __sz) _GLIBCXX_THROW(std::bad_alloc);
 
 /** @brief  This function just clears the internal Free List, and
  *  gives back all the memory to the OS.
@@ -766,7 +766,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*  the newly acquired block. Having a tight bound.
*/
   void 
-  _S_refill_pool() throw(std::bad_alloc)
+  _S_refill_pool() _GLIBCXX_THROW(std::bad_alloc)
   {
 #if defined _GLIBCXX_DEBUG
_S_check_for_free_blocks();
@@ -824,7 +824,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*  Amortized Constant time.
*/
   pointer 
-  _M_allocate_single_object() throw(std::bad_alloc)
+  _M_allocate_single_object() _GLIBCXX_THROW(std::bad_alloc)
   {
 #if defined __GTHREADS
__scoped_lock __bit_lock(_S_mut);

[PATCH 3/3] Replace dynamic exception specifications in testsuite

[Jonathan Wakely]

This replaces a number of dynamic exeptions spces in the testsuite,
for C++17 compatibility.

I introduced a new THROW macro for use in the tests, so they are not
coupled to our internal _GLIBCXX_THROW macro which is only meant for
use internally in the library.

   * testsuite/util/testsuite_hooks.h (THROW): Define.
   * testsuite/util/replacement_memory_operators.h: Include
   testsuite_hooks.h and use THROW macro.
   * testsuite/util/testsuite_tr1.h: Likewise.
   * testsuite/20_util/allocator/1.cc: Use THROW macro.
   * testsuite/22_locale/locale/cons/12352.cc: Likewise.
   * testsuite/23_containers/vector/zero_sized_allocations.cc: Likewise.
   * testsuite/30_threads/lock_guard/cons/1.cc: Replace dynamic exception
   specification with noexcept-specifier.
   * testsuite/ext/pool_allocator/allocate_chunk.cc: Include
   testsuite_hooks.h and use THROW macro.
   * testsuite/ext/profile/replace_new.cc: Likewise.

Tested powerpc64le-linux, committed to trunk.
commit 5500cce3cd8530bdbeca46a1df6fcb9a318afc36
Author: Jonathan Wakely 
Date:   Wed Dec 7 13:24:11 2016 +

Replace dynamic exception specifications in testsuite

* testsuite/util/testsuite_hooks.h (THROW): Define.
* testsuite/util/replacement_memory_operators.h: Include
testsuite_hooks.h and use THROW macro.
* testsuite/util/testsuite_tr1.h: Likewise.
* testsuite/20_util/allocator/1.cc: Use THROW macro.
* testsuite/22_locale/locale/cons/12352.cc: Likewise.
* testsuite/23_containers/vector/zero_sized_allocations.cc: Likewise.
* testsuite/30_threads/lock_guard/cons/1.cc: Replace dynamic exception
specification with noexcept-specifier.
* testsuite/ext/pool_allocator/allocate_chunk.cc: Include
testsuite_hooks.h and use THROW macro.
* testsuite/ext/profile/replace_new.cc: Likewise.

diff --git a/libstdc++-v3/testsuite/20_util/allocator/1.cc 
b/libstdc++-v3/testsuite/20_util/allocator/1.cc
index 6905c86..0c06839 100644
--- a/libstdc++-v3/testsuite/20_util/allocator/1.cc
+++ b/libstdc++-v3/testsuite/20_util/allocator/1.cc
@@ -30,7 +30,7 @@ bool check_new = false;
 bool check_delete = false;
 
 void* 
-operator new(std::size_t n) throw(std::bad_alloc)
+operator new(std::size_t n) THROW(std::bad_alloc)
 {
   check_new = true;
   return std::malloc(n);
diff --git a/libstdc++-v3/testsuite/22_locale/locale/cons/12352.cc 
b/libstdc++-v3/testsuite/22_locale/locale/cons/12352.cc
index 8faf714..d514b2a 100644
--- a/libstdc++-v3/testsuite/22_locale/locale/cons/12352.cc
+++ b/libstdc++-v3/testsuite/22_locale/locale/cons/12352.cc
@@ -45,7 +45,7 @@ void deallocate(void* p)
 std::free(p);
 }
 
-void* operator new(std::size_t n) throw (std::bad_alloc)
+void* operator new(std::size_t n) THROW (std::bad_alloc)
 {
   void* ret = allocate(n);
   if (!ret)
@@ -53,7 +53,7 @@ void* operator new(std::size_t n) throw (std::bad_alloc)
   return ret;
 }
 
-void* operator new[](std::size_t n) throw (std::bad_alloc)
+void* operator new[](std::size_t n) THROW (std::bad_alloc)
 {
   void* ret = allocate(n);
   if (!ret)
diff --git 
a/libstdc++-v3/testsuite/23_containers/vector/zero_sized_allocations.cc 
b/libstdc++-v3/testsuite/23_containers/vector/zero_sized_allocations.cc
index 272caf3..524241b 100644
--- a/libstdc++-v3/testsuite/23_containers/vector/zero_sized_allocations.cc
+++ b/libstdc++-v3/testsuite/23_containers/vector/zero_sized_allocations.cc
@@ -22,7 +22,7 @@
 
 unsigned int zero_sized_news = 0;
 
-void *operator new(std::size_t size) throw (std::bad_alloc)
+void *operator new(std::size_t size) THROW (std::bad_alloc)
 {
   /* malloc(0) is unpredictable; avoid it.  */
   if (size == 0)
diff --git a/libstdc++-v3/testsuite/30_threads/lock_guard/cons/1.cc 
b/libstdc++-v3/testsuite/30_threads/lock_guard/cons/1.cc
index 1296760..414b678 100644
--- a/libstdc++-v3/testsuite/30_threads/lock_guard/cons/1.cc
+++ b/libstdc++-v3/testsuite/30_threads/lock_guard/cons/1.cc
@@ -26,7 +26,7 @@ struct Mutex
 {
   Mutex() : locked(false) { }
 
-  ~Mutex() throw(int)
+  ~Mutex() noexcept(false)
   {
 if (locked)
   throw 0;
diff --git a/libstdc++-v3/testsuite/ext/pool_allocator/allocate_chunk.cc 
b/libstdc++-v3/testsuite/ext/pool_allocator/allocate_chunk.cc
index c751739..7838039 100644
--- a/libstdc++-v3/testsuite/ext/pool_allocator/allocate_chunk.cc
+++ b/libstdc++-v3/testsuite/ext/pool_allocator/allocate_chunk.cc
@@ -20,6 +20,7 @@
 // 20.4.1.1 allocator members
 
 #include 
+#include 
 
 struct small
 {
@@ -32,7 +33,7 @@ struct big
 };
 
 void*
-operator new(size_t n) throw(std::bad_alloc)
+operator new(size_t n) THROW(std::bad_alloc)
 {
   static bool first = true;
   if (!first)
diff --git a/libstdc++-v3/testsuite/ext/profile/replace_new.cc 
b/libstdc++-v3/testsuite/ext/profile/replace_new.cc
index be5ec09..9c94594 100644
--- a/libstdc++-v3/testsuite/ext/profile/replace_new.cc
+++ b/libstdc++-v3/testsuite/ext/profile/replace_ne

[PATCH 1/2] Replace use of C++14 std::exchange in C++11 testcase

[Jonathan Wakely]

This test fails when run with -std=gnu++11

* testsuite/28_regex/traits/char/user_defined.cc: Replace uses of
C++14 std::exchange function.

Tested x86_64-linux, committed to trunk.

commit 897fb3679fda13a8ebda39cf8a60810b03f09e06
Author: Jonathan Wakely 
Date:   Wed Dec 7 14:25:34 2016 +

Replace use of C++14 std::exchange in C++11 testcase

* testsuite/28_regex/traits/char/user_defined.cc: Replace uses of
C++14 std::exchange function.

diff --git a/libstdc++-v3/testsuite/28_regex/traits/char/user_defined.cc 
b/libstdc++-v3/testsuite/28_regex/traits/char/user_defined.cc
index 5888ce1..d4f4abc 100644
--- a/libstdc++-v3/testsuite/28_regex/traits/char/user_defined.cc
+++ b/libstdc++-v3/testsuite/28_regex/traits/char/user_defined.cc
@@ -72,13 +72,15 @@ test01()
 VERIFY(!called_transform);
 basic_regex> re("[a]", regex::collate);
 VERIFY(regex_match("a", re));
-VERIFY(exchange(called_transform, false));
+VERIFY(called_transform);
+called_transform = false;
   }
   {
 VERIFY(!called_nocase);
 basic_regex> re("[a]", regex::icase);
 VERIFY(regex_match("A", re));
-VERIFY(exchange(called_nocase, false));
+VERIFY(called_nocase);
+called_nocase = false;
   }
   {
 basic_regex> re("[T-f]", regex::icase);

[PATCH 2/2] Replace uses of C++14 remove_cv_t alias in C++11 header

[Jonathan Wakely]

Most filesystem tests test fail when run with -std=gnu++11

   * include/experimental/bits/fs_path.h (path::_S_convert):
   * Replace uses of C++14 std::remove_cv_t alias template.

Tested x86_64-linux, committed to trunk.
commit c5d7518d15c540541a77e997ba4bb6d33703bedd
Author: Jonathan Wakely 
Date:   Wed Dec 7 14:33:24 2016 +

Replace uses of C++14 remove_cv_t alias in C++11 header

	* include/experimental/bits/fs_path.h (path::_S_convert): Replace
	uses of C++14 std::remove_cv_t alias template.

diff --git a/libstdc++-v3/include/experimental/bits/fs_path.h b/libstdc++-v3/include/experimental/bits/fs_path.h
index 70a5445..a69fb9d 100644
--- a/libstdc++-v3/include/experimental/bits/fs_path.h
+++ b/libstdc++-v3/include/experimental/bits/fs_path.h
@@ -418,7 +418,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   _S_convert(_Iter __first, _Iter __last)
   {
 	using __value_type = typename std::iterator_traits<_Iter>::value_type;
-	return _Cvt>::_S_convert(__first, __last);
+	return _Cvt::type>::
+	  _S_convert(__first, __last);
   }
 
 template
@@ -426,7 +427,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   _S_convert(_InputIterator __src, __null_terminated)
   {
 	using _Tp = typename std::iterator_traits<_InputIterator>::value_type;
-	std::basic_string> __tmp;
+	std::basic_string::type> __tmp;
 	for (; *__src != _Tp{}; ++__src)
 	  __tmp.push_back(*__src);
 	return _S_convert(__tmp.c_str(), __tmp.c_str() + __tmp.size());

Re: [PATCH, GCC/LRA] Fix PR78617: Fix conflict detection in rematerialization

[Vladimir N Makarov]

On 12/01/2016 12:40 PM, Thomas Preudhomme wrote:

Hi,

When considering a candidate for rematerialization, LRA verifies if 
the candidate clobbers a live register before going forward with the 
rematerialization (see code starting with comment "Check clobbers do 
not kill something living."). To do this check, the set of live 
registers at any given instruction needs to be maintained. This is 
done by initializing the set of live registers when starting the 
forward scan of instruction in a basic block and updating the set by 
looking at REG_DEAD notes and destination register at the end of an 
iteration of the scan loop.


However the initialization suffers from 2 issues:

1) it is done from the live out set rather than live in (uses 
df_get_live_out (bb))
2) it ignores pseudo registers that have already been allocated a hard 
register (uses REG_SET_TO_HARD_REG_SET that only looks at hard 
register and does not look at reg_renumber for pseudo registers)


This patch changes the code to use df_get_live_in (bb) to initialize 
the live_hard_regs variable using a loop to check reg_renumber for 
pseudo registers. Please let me know if there is a macro to do that, I 
failed to find one.


ChangeLog entries are as follow:

gcc/testsuite/ChangeLog:

2016-12-01  Thomas Preud'homme  

PR rtl-optimization/78617
* gcc.c-torture/execute/pr78617.c: New test.


gcc/ChangeLog:

2016-12-01  Thomas Preud'homme  

PR rtl-optimization/78617
* lra-remat.c (do_remat): Initialize live_hard_regs from live in
registers, also setting hard registers mapped to pseudo 
registers.



Note however that as explained in the problem report, the testcase 
does not trigger the bug on GCC 7 due to better optimization before 
LRA rematerialization is reached.


Testing: testsuite shows no regression when run using:
 + an arm-none-eabi GCC cross-compiler targeting Cortex-M0 and Cortex-M3
 + a bootstrapped arm-linux-gnueabihf GCC native compiler
 + a bootstrapped x86_64-linux-gnu GCC native compiler

Is this ok for stage3?

Yes.

Thomas, thank you very much for the patch.  Using live_out was my typo, 
not using reg_renumber is my more serious mistake (although it is 
non-trivial case with unused pseudo).

Re: [Patch, fortran] PR44265 - Link error with reference to parameter array in specification expression

[Paul Richard Thomas]

Dear Dominique,

I will turn to the effect on PR77414 after committing the patch for PR44265.

The attached fixes the -flto problem. The chunk in
trans-decl.c(gfc_finish_var_decl) did the job. It is quite obvious now
and, in fact, I am a bit surprised that the patch worked at all
without the DECL_EXTERNAL.

Bootstraps and regtests on FC21/x86_64 - OK for trunk?

Paul

2016-12-07  Paul Thomas  

PR fortran/44265
* gfortran.h : Add fn_result_spec bitfield to gfc_symbol.
* resolve.c (flag_fn_result_spec): New function.
(resolve_fntype): Call it for character result lengths.
* symbol.c (gfc_new_symbol): Set fn_result_spec to zero.
* trans-decl.c (gfc_sym_mangled_identifier): Include the
procedure name in the mangled name for symbols with the
fn_result_spec bit set.
(gfc_finish_var_decl): Mark the decls of these symbols
appropriately for the case where the function is external.
(gfc_get_symbol_decl): Mangle the name of these symbols.
(gfc_create_module_variable): Allow them through the assert.
(gfc_generate_function_code): Remove the assert before the
initialization of sym->tlink because the frontend no longer
uses this field.
* trans-expr.c (gfc_map_intrinsic_function): Add a case to
treat the LEN_TRIM intrinsic.

2016-12-07  Paul Thomas  

PR fortran/44265
* gfortran.dg/char_result_14.f90: New test.
* gfortran.dg/char_result_15.f90: New test.
* gfortran.dg/char_result_16.f90: New test.
* gfortran.dg/char_result_17.f90: New test.


On 7 December 2016 at 13:21, Dominique d'Humières  wrote:
> Dear Paul,
>
> I have found another glitch with all the patches in this thread: they 
> transform an ICE to accept-invalid for the tests z7.f90, z8.f90, and z9.f90 
> in pr77414.
>
> Dominique
>
>> Le 10 nov. 2016 à 23:48, Dominique d'Humières  a écrit :
>>
>> FAIL: gfortran.dg/char_result_16.f90   -g -flto  (internal compiler error)
>> FAIL: gfortran.dg/char_result_16.f90   -g -flto  (test for excess errors)
>>
>> The ICE is for both -m32 and -m64 (module_procedure_3_db_1.f90 is the test 
>> posted in my last mail)
>>
>> % gfc module_procedure_3_db_1.f90 -flto
>> module_procedure_3_db_1.f90:29:0: internal compiler error: in 
>> get_partitioning_class, at symtab.c:1848
>> END PROGRAM WheresThatbLinkingConstantGone
>>
>> Sorry to be such a nuisance!-(
>>
>> Dominique
>>
>



-- 
If you're walking down the right path and you're willing to keep
walking, eventually you'll make progress.

Barack Obama
Index: gcc/fortran/gfortran.h
===
*** gcc/fortran/gfortran.h  (revision 243235)
--- gcc/fortran/gfortran.h  (working copy)
*** typedef struct gfc_symbol
*** 1545,1550 
--- 1545,1552 
unsigned equiv_built:1;
/* Set if this variable is used as an index name in a FORALL.  */
unsigned forall_index:1;
+   /* Set if the symbol is used in a function result specification .  */
+   unsigned fn_result_spec:1;
/* Used to avoid multiple resolutions of a single symbol.  */
unsigned resolved:1;
/* Set if this is a module function or subroutine with the
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c   (revision 243235)
--- gcc/fortran/resolve.c   (working copy)
*** resolve_equivalence (gfc_equiv *eq)
*** 15755,15760 
--- 15755,15808 
  }
  
  
+ /* Function called by resolve_fntype to flag other symbol used in the
+length type parameter specification of function resuls.  */
+ 
+ static bool
+ flag_fn_result_spec (gfc_expr *expr,
+  gfc_symbol *sym ATTRIBUTE_UNUSED,
+  int *f ATTRIBUTE_UNUSED)
+ {
+   gfc_namespace *ns;
+   gfc_symbol *s;
+ 
+   if (expr->expr_type == EXPR_VARIABLE)
+ {
+   s = expr->symtree->n.sym;
+   for (ns = s->ns; ns; ns = ns->parent)
+   if (!ns->parent)
+ break;
+ 
+   if (!s->fn_result_spec
+ && s->attr.flavor == FL_PARAMETER)
+   {
+ /* Function contained in a module */
+ if (ns->proc_name && ns->proc_name->attr.flavor == FL_MODULE)
+   {
+ gfc_symtree *st;
+ s->fn_result_spec = 1;
+ /* Make sure that this symbol is translated as a module
+variable.  */
+ st = gfc_get_unique_symtree (ns);
+ st->n.sym = s;
+ s->refs++;
+   }
+ /* ... which is use associated and called.  */
+ else if (s->attr.use_assoc || s->attr.used_in_submodule
+   ||
+ /* External function matched with an interface.  */
+ (s->ns->proc_name
+  && ((s->ns == ns
+&& s->ns->proc_name->attr.if_source == IFSRC_DECL)
+  || s->ns->proc_name->attr.if_source == IFSRC_IFBODY)
+  && s->ns->proc_name->attr.function))

Re: [PATCH, rs6000] pr65479 Add -fasynchronous-unwind-tables when the -fsanitize=address option is seen

[Peter Bergner]

On 12/6/16 3:55 PM, Segher Boessenkool wrote:
> On Tue, Dec 06, 2016 at 03:23:06PM -0600, Bill Seurer wrote:
>> --- gcc/config/rs6000/rs6000.c   (revision 243308)
>> +++ gcc/config/rs6000/rs6000.c   (working copy)
>> @@ -5204,6 +5204,11 @@ rs6000_option_override (void)
>>  {
>>(void) rs6000_option_override_internal (true);
>>  
>> +  /* -fsanitize=address needs to turn on -fasynchronous-unwind-tables for
>> + ppc64 in order for tracebacks to be complete.  */
>> +  if (global_options.x_flag_sanitize & SANITIZE_USER_ADDRESS)
>> +global_options.x_flag_asynchronous_unwind_tables = 1;
> 
> Do you need to check if the user specified -fno-asynchronous-unwind-tables
> here, and then not do this?  I.e. similar to the rs6000_isa_flags_explicit
> handling (in the _internal function).

I agree that if the user explicitly says -fno-asynchronous-unwind-tables,
we shouldn't implicitly enable it behind their back.

I also don't see how this is ppc64 specific, but your comment mentions
it.  The way the code is written here, this will be used for ppc32, ppc64
and ppc64le.  I'd just rewrite the comment without mentioning ppc64 or
replace it with a more general term (PowerPC?).

Peter

[PATCH, testsuite]: Require int128 effective target for gcc.target/i386/pr77761.c

[Uros Bizjak]

Also remove unneded functions.

2016-12-07  Uros Bizjak  

* gcc.target/i386/pr77761.c: Require int128 effective target.
(avx512f_test): Delete.
(do_main): Rename to avx512f_test.

Tested on x86_64-linux-gnu {,-m32} and committed to mainline SVN.

Uros.
diff --git a/gcc/testsuite/gcc.target/i386/pr77761.c 
b/gcc/testsuite/gcc.target/i386/pr77761.c
index a39b3af..213a93f 100644
--- a/gcc/testsuite/gcc.target/i386/pr77761.c
+++ b/gcc/testsuite/gcc.target/i386/pr77761.c
@@ -1,5 +1,6 @@
 /* { dg-do run } */
 /* { dg-options "-O2 -fno-guess-branch-probability -fschedule-insns 
-fno-tree-ter -mavx512f --param=max-pending-list-length=512" } */
+/* { dg-require-effective-target int128 } */
 /* { dg-require-effective-target avx512f } */
 
 #include "avx512f-check.h"
@@ -29,8 +30,8 @@ foo(u8 x1, u16 x2, u32 x3, u64 x4, v64u8 x5, v64u16 x6, 
v64u32 x7, v64u64 x8, v6
 (v64u128) x8 + x9;
 }
 
-int
-do_main ()
+static void
+avx512f_test (void)
 {
   v64u128 x = foo(1, 0, 0, 0, (v64u8){}, (v64u16){}, (v64u32){}, (v64u64){}, 
(v64u128){});
 
@@ -45,11 +46,4 @@ do_main ()
 __builtin_abort();
   if (x[3] != 1)
 __builtin_abort();
-  return 0;
-}
-
-static void
-avx512f_test (void)
-{
-  do_main ();
 }

Re: [PATCH] Tree-level fix for PR 69526

[Robin Dapp]

> So we have (uint64_t)(uint32 + -1U) + 1 and using TYPE_SIGN (inner_type)
> produces (uint64_t)uint32 + -1U + 1.  This simply means that we cannot ignore
> overflow of the inner operation and for some reason your change
> to extract_range_from_binary_expr didn't catch this.  That is _8 + 4294967295
> overflows but we ignored that.

In this case the range of _8 was [1,1] so no overflow.
I think the problem is rather about the interpretation of the inner
constant. I tried discerning two cases now, a range split (i.e. when the
single range of a binop variable becomes an anti range or two ranges
after combining it with the binop's other range) and an overflow of the
range's min and max.
If the range didn't split, we can perform the simplification. If there
was a min and max overflow, we have to interpret the inner constant as
signed and perform a sign extension before converting it to the outer
type. Without overflow we can use TYPE_SIGN (inner_type).
Does this make sense?

Included the remarks and attached the new version.

Regards
 Robin
diff --git a/gcc/match.pd b/gcc/match.pd
index feaa4a1..19df142 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1195,6 +1195,81 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(minus @0 (minus @0 @1))
@1)
 
+  /* ((T)(A +- CST)) +- CST -> (T)(A) +- CST)  */
+#if GIMPLE
+   (for outer_op (plus minus)
+ (for inner_op (plus minus)
+   (simplify
+	 (outer_op (convert (inner_op@3 @0 INTEGER_CST@1)) INTEGER_CST@2)
+	   (if (TREE_CODE (type) == INTEGER_TYPE
+		&& TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (@3)))
+	(with
+	{
+	  struct vr_binop_overflow ovf;
+	  tree cst = NULL_TREE;
+	  tree inner_type = TREE_TYPE (@3);
+	  value_range vr = VR_INITIALIZER;
+
+	  /* Convert combined constant to tree of outer type if
+		 there was no value range split in the original operation.  */
+	  if (TYPE_OVERFLOW_UNDEFINED (inner_type)
+		  || (extract_range_from_binary_expr (&vr, inner_op,
+		inner_type, @0, @1, &ovf), !ovf.range_split))
+	  {
+		wide_int w1 = @1;
+		wide_int w2 = @2;
+
+		wide_int combined_cst;
+
+		/* Extend @1 to TYPE.  Perform sign extension if the range
+		   overflowed but did not split.  */
+		w1 = w1.from (w1, TYPE_PRECISION (type), ovf.ovf ? SIGNED :
+		TYPE_SIGN (inner_type));
+
+		if (inner_op == MINUS_EXPR)
+		  w1 = wi::neg (w1);
+
+		if (outer_op == MINUS_EXPR)
+		  w2 = wi::neg (w2);
+
+		/* Combine in outer, larger type.  */
+		bool combine_ovf = true;
+		combined_cst = wi::add (w1, w2);
+
+		cst = wide_int_to_tree (type, combined_cst);
+	  }
+	}
+	(if (cst)
+	 (outer_op (convert @0) { cst; }))
+	)
+#endif
+
+  /* ((T)(A)) +- CST -> (T)(A +- CST)  */
+#if GIMPLE
+   (for outer_op (plus minus)
+(simplify
+ (outer_op (convert @0) INTEGER_CST@2)
+  (if (TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (@0))
+	   && TREE_CODE (TREE_TYPE (@0)) == INTEGER_TYPE
+	   && TREE_CODE (type) == INTEGER_TYPE)
+   /* Perform binary operation inside the cast if the constant fits
+	  and there is no overflow.  */
+   (with
+	{
+	  struct vr_binop_overflow ovf;
+
+	  int_fits_type_p (@2, TREE_TYPE (@0));
+	  tree cst_inner = fold_convert (TREE_TYPE (@0), @2);
+
+	  value_range vr = VR_INITIALIZER;
+	  extract_range_from_binary_expr (&vr, outer_op, TREE_TYPE (@0),
+	  @0, cst_inner, &ovf);
+	}
+	(if (!ovf.range_split)
+	 (convert (outer_op @0 { cst_inner; })))
+	
+#endif
+
   /* (A +- CST1) +- CST2 -> A + CST3  */
   (for outer_op (plus minus)
(for inner_op (plus minus)
diff --git a/gcc/testsuite/gcc.dg/wrapped-binop-simplify-signed-1.c b/gcc/testsuite/gcc.dg/wrapped-binop-simplify-signed-1.c
new file mode 100644
index 000..19b787b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/wrapped-binop-simplify-signed-1.c
@@ -0,0 +1,60 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-ccp1-details" } */
+/* { dg-final { scan-tree-dump-times "gimple_simplified to" 11 "ccp1" } } */
+
+#include 
+
+long foo(int a)
+{
+  return (long)(a - 2) + 1;
+}
+
+long bar(int a)
+{
+  return (long)(a + 3) - 1;
+}
+
+long baz(int a)
+{
+  return (long)(a - 1) + 2;
+}
+
+long baf(int a)
+{
+  return (long)(a + 1) - 2;
+}
+
+long bak(int a)
+{
+  return (long)(a + 1) + 3;
+}
+
+long bal(int a)
+{
+  return (long)(a - 7) - 4;
+}
+
+long bam(int a)
+{
+  return (long)(a - 1) - INT_MAX;
+}
+
+long bam2(int a)
+{
+  return (long)(a + 1) + INT_MAX;
+}
+
+long ban(int a)
+{
+  return (long)(a - 1) + INT_MIN;
+}
+
+long ban2(int a)
+{
+  return (long)(a + 1) - INT_MIN;
+}
+
+unsigned long baq(int a)
+{
+  return (unsigned long)(a + 1) - 1;
+}
diff --git a/gcc/testsuite/gcc.dg/wrapped-binop-simplify-unsigned-1.c b/gcc/testsuite/gcc.dg/wrapped-binop-simplify-unsigned-1.c
new file mode 100644
index 000..8befc96
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/wrapped-binop-simplify-unsigned-1.c
@@ -0,0 +1,51 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-ccp1-details -fdump-tree-evrp-details 

Re: Hurd port for gcc go PATCH 1-4(23)

[Samuel Thibault]

Svante Signell, on Wed 07 Dec 2016 15:32:31 +0100, wrote:
> On Wed, 2016-12-07 at 15:08 +0100, Samuel Thibault wrote:
> > Ok, but then I'd say move the function which change to a separate file,
> > so that the other functions are kept shared.
> > Otherwise it'll be tedious to maintain.
> 
> One problem is the file go/syscall/libcall_posix-1.go, derived
> from go/syscall/libcall_posix.go but _removing_ four function definitions:
> mount, madvise, mlockall and munlockall.

That's not a problem: move them out to another file, and include that
file in the non-gnu case, but do not include that file in the gnu case.

Actually it's even odd to see mount among them, it's not a standard
posix interface.

Samuel

Re: [PATCH v3, rs6000] Add built-in support for vector compare listed in the ABI

[Carl E. Love]

On Tue, 2016-12-06 at 15:59 -0600, Segher Boessenkool wrote:
> On Tue, Dec 06, 2016 at 01:23:24PM -0800, Carl E. Love wrote:
> > Per the feedback I received on the first and second versions of the
> > patch I have created the following patch to modify the original commit
> > for the vector compare built-in support.  Specifically, the tests were
> > broken into files for the processors that supports them.  This allows
> > for specific control over specifying the effective targets and compiler
> > options.
> > 
> > The patch has been boot strapped and tested on
> > powerpc64le-unknown-linux-gnu (Power 8) and on 
> > powerpc64-unknown-linux-gnu (Power 7).  
> > 
> > 
> > Is this ok for trunk?
> 
> This looks good, please apply.  Thanks,
> 
> 
> Segher

Segher:

Thanks, patch applied


Revision 243370 - Directory Listing
Modified Wed Dec 7 16:21:16 2016 UTC (68 seconds ago) by carll

2016-12-07  Carl Love  

* gcc.target/powerpc/builtins-3.c: Move built-in tests for P8 and
P9 to their own test file.  This allows precise constraints on the
effective target and compile options.
* gcc.target/powerpc/builtins-3-p8.c: New file for the vector
compare P8 built-in tests.
* gcc.target/powerpc/builtins-3-p9.c: New file for the vector
compare P9 built-in tests.

Re: [tree-tailcall] Check if function returns it's argument

[Jeff Law]

On 12/06/2016 01:25 AM, Richard Biener wrote:

But if the function returns the value from the tail call, then going through
an LHS is the right thing to do.  Using the magic "argX will be the return
value" seems clever, but actually hurts in practice.


So we do want the reverse transform (for the case of returning by
reference that's going to be tricky if not impossible due to the
IL hygiene we enforce).
It might be useful, but I'd like to see instrumentation before doing any 
significant work on this problem.


jeff

[PATCH] Fix cgraph_edge::redirect_call_stmt_to_callee noreturn call handling (PR c++/78692)

[Jakub Jelinek]

Hi!

The code in this function assumes that lhs is the lhs of new_stmt (it tests
that new_stmt is a noreturn call etc.), but that is only the case if
new_stmt == e->call_stmt.  But in the function it can be set to various
other stmts.  Nothing tests the lhs before this noreturn handling, so this
patch fixes it by moving the initialization of lhs right before the use.

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

2016-12-07  Jakub Jelinek  

PR c++/78692
* cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Set lhs
var to lhs of new_stmt right before noreturn handling rather than to
lhs of e->call_stmt early.

* g++.dg/torture/pr78692.C: New test.

--- gcc/cgraph.c.jj 2016-11-30 13:57:11.0 +0100
+++ gcc/cgraph.c2016-12-06 09:51:32.513140728 +0100
@@ -1271,7 +1271,6 @@ cgraph_edge::redirect_call_stmt_to_calle
   cgraph_edge *e = this;
 
   tree decl = gimple_call_fndecl (e->call_stmt);
-  tree lhs = gimple_call_lhs (e->call_stmt);
   gcall *new_stmt;
   gimple_stmt_iterator gsi;
   bool skip_bounds = false;
@@ -1526,6 +1525,7 @@ cgraph_edge::redirect_call_stmt_to_calle
 gimple_call_set_fntype (new_stmt, TREE_TYPE (e->callee->decl));
 
   /* If the call becomes noreturn, remove the LHS if possible.  */
+  tree lhs = gimple_call_lhs (new_stmt);
   if (lhs
   && gimple_call_noreturn_p (new_stmt)
   && (VOID_TYPE_P (TREE_TYPE (gimple_call_fntype (new_stmt)))
--- gcc/testsuite/g++.dg/torture/pr78692.C.jj   2016-12-06 09:55:39.295999164 
+0100
+++ gcc/testsuite/g++.dg/torture/pr78692.C  2016-12-06 09:55:25.0 
+0100
@@ -0,0 +1,26 @@
+// PR c++/78692
+
+int a;
+void *b;
+extern "C" {
+struct C {
+  virtual int d ();
+};
+struct E {
+  virtual int operator () (int, const void *, int) = 0;
+};
+class F {
+  int g ();
+  int h;
+  E &i;
+};
+struct : C, E {
+  int operator () (int, const void *, int) { throw int(); }
+} j;
+
+int
+F::g ()
+{
+  a = i (h, b, 0);
+}
+}

Jakub

[PATCH] Move __builtin_strstr folding from builtins.c to fold-const-call.c + gimple-fold.c; plus a constexpr testcase for strstr

[Jakub Jelinek]

Hi!

As discussed on IRC, this patch adds a constexpr handling testcase for
the strstr builtin and moves it over to the desired files (gimple-fold.c
and fold-const-call.c).

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

2016-12-07  Jakub Jelinek  

* builtins.c (fold_builtin_strstr): Removed.
(fold_builtin_2): Don't call fold_builtin_strstr.
* gimple-fold.c (gimple_fold_builtin_strchr): Check is_strrchr
earlier in the strrchr (x, 0) -> strchr (x, 0) optimization.
(gimple_fold_builtin_strstr): New function.
(gimple_fold_builtin): Call it.
* fold-const-call.c (fold_const_call): Handle CFN_BUILT_IN_STRSTR.

--- gcc/builtins.c.jj   2016-11-18 20:04:26.0 +0100
+++ gcc/builtins.c  2016-12-07 11:45:05.466826715 +0100
@@ -163,7 +163,6 @@ static tree fold_builtin_3 (location_t,
 static tree fold_builtin_varargs (location_t, tree, tree*, int);
 
 static tree fold_builtin_strpbrk (location_t, tree, tree, tree);
-static tree fold_builtin_strstr (location_t, tree, tree, tree);
 static tree fold_builtin_strspn (location_t, tree, tree);
 static tree fold_builtin_strcspn (location_t, tree, tree);
 
@@ -8303,9 +8302,6 @@ fold_builtin_2 (location_t loc, tree fnd
 CASE_FLT_FN (BUILT_IN_MODF):
   return fold_builtin_modf (loc, arg0, arg1, type);
 
-case BUILT_IN_STRSTR:
-  return fold_builtin_strstr (loc, arg0, arg1, type);
-
 case BUILT_IN_STRSPN:
   return fold_builtin_strspn (loc, arg0, arg1);
 
@@ -8729,72 +8725,6 @@ readonly_data_expr (tree exp)
 return false;
 }
 
-/* Simplify a call to the strstr builtin.  S1 and S2 are the arguments
-   to the call, and TYPE is its return type.
-
-   Return NULL_TREE if no simplification was possible, otherwise return the
-   simplified form of the call as a tree.
-
-   The simplified form may be a constant or other expression which
-   computes the same value, but in a more efficient manner (including
-   calls to other builtin functions).
-
-   The call may contain arguments which need to be evaluated, but
-   which are not useful to determine the result of the call.  In
-   this case we return a chain of COMPOUND_EXPRs.  The LHS of each
-   COMPOUND_EXPR will be an argument which must be evaluated.
-   COMPOUND_EXPRs are chained through their RHS.  The RHS of the last
-   COMPOUND_EXPR in the chain will contain the tree for the simplified
-   form of the builtin function call.  */
-
-static tree
-fold_builtin_strstr (location_t loc, tree s1, tree s2, tree type)
-{
-  if (!validate_arg (s1, POINTER_TYPE)
-  || !validate_arg (s2, POINTER_TYPE))
-return NULL_TREE;
-  else
-{
-  tree fn;
-  const char *p1, *p2;
-
-  p2 = c_getstr (s2);
-  if (p2 == NULL)
-   return NULL_TREE;
-
-  p1 = c_getstr (s1);
-  if (p1 != NULL)
-   {
- const char *r = strstr (p1, p2);
- tree tem;
-
- if (r == NULL)
-   return build_int_cst (TREE_TYPE (s1), 0);
-
- /* Return an offset into the constant string argument.  */
- tem = fold_build_pointer_plus_hwi_loc (loc, s1, r - p1);
- return fold_convert_loc (loc, type, tem);
-   }
-
-  /* The argument is const char *, and the result is char *, so we need
-a type conversion here to avoid a warning.  */
-  if (p2[0] == '\0')
-   return fold_convert_loc (loc, type, s1);
-
-  if (p2[1] != '\0')
-   return NULL_TREE;
-
-  fn = builtin_decl_implicit (BUILT_IN_STRCHR);
-  if (!fn)
-   return NULL_TREE;
-
-  /* New argument list transforming strstr(s1, s2) to
-strchr(s1, s2[0]).  */
-  return build_call_expr_loc (loc, fn, 2, s1,
- build_int_cst (integer_type_node, p2[0]));
-}
-}
-
 /* Simplify a call to the strpbrk builtin.  S1 and S2 are the arguments
to the call, and TYPE is its return type.
 
--- gcc/gimple-fold.c.jj2016-11-25 18:11:05.0 +0100
+++ gcc/gimple-fold.c   2016-12-07 11:47:15.928167796 +0100
@@ -1506,11 +1506,11 @@ gimple_fold_builtin_strchr (gimple_stmt_
 return false;
 
   /* Transform strrchr (s, 0) to strchr (s, 0) when optimizing for size.  */
-  if (optimize_function_for_size_p (cfun))
+  if (is_strrchr && optimize_function_for_size_p (cfun))
 {
   tree strchr_fn = builtin_decl_implicit (BUILT_IN_STRCHR);
 
-  if (is_strrchr && strchr_fn)
+  if (strchr_fn)
{
  gimple *repl = gimple_build_call (strchr_fn, 2, str, c);
  replace_call_with_call_and_fold (gsi, repl);
@@ -1549,6 +1549,68 @@ gimple_fold_builtin_strchr (gimple_stmt_
   return true;
 }
 
+/* Fold function call to builtin strstr.
+   If both arguments are constant, evaluate and fold the result,
+   additionally fold strstr (x, "") into x and strstr (x, "c")
+   into strchr (x, 'c').  */
+static bool
+gimple_fold_builtin_strstr (gimple_stmt_iterator *gsi)
+{
+  gimple *stmt = gsi_stmt (*gsi);
+  tree haystack = gimple_call

[PATCH] improve string find algorithm

[Aditya Kumar]

Here is an improved version of basic_string::find. The idea is to
split the string find in two parts:
1. search for the first match by using traits_type::find (this gets converted 
to memchr for x86)
2. see if there is a match (this gets converted to memcmp for x86)

Passes bootstrap on x86-64.

The patch results in good improvements on a synthetic test case I wrote using 
the google-benchmark.
following are the results.


Branch: master without patch
$ ./bin/string.libcxx.out
Run on (24 X 1899.12 MHz CPU s)
2016-12-06 16:41:55
***WARNING*** CPU scaling is enabled, the benchmark real time measurements may 
be noisy and will incur extra overhead.
Benchmark   Time   CPU Iterations
-
BM_StringFindNoMatch/10 8 ns  8 ns   81880927
BM_StringFindNoMatch/6452 ns 52 ns   13235018
BM_StringFindNoMatch/512  355 ns355 ns1962488
BM_StringFindNoMatch/4k  2769 ns   2772 ns 249090
BM_StringFindNoMatch/32k22598 ns  22619 ns  30984
BM_StringFindNoMatch/128k   89745 ns  89830 ns   7996
BM_StringFindAllMatch/1 7 ns  7 ns  102893835
BM_StringFindAllMatch/8 9 ns  9 ns   75403364
BM_StringFindAllMatch/64   12 ns 12 ns   60766893
BM_StringFindAllMatch/512  31 ns 31 ns   23163999
BM_StringFindAllMatch/4k  141 ns141 ns4980386
BM_StringFindAllMatch/32k1402 ns   1403 ns 483581
BM_StringFindAllMatch/128k   5604 ns   5609 ns 126123
BM_StringFindMatch1/1   44430 ns  44473 ns  15804
BM_StringFindMatch1/8   44315 ns  44357 ns  15741
BM_StringFindMatch1/64  44689 ns  44731 ns  15712
BM_StringFindMatch1/512 44247 ns  44290 ns  15724
BM_StringFindMatch1/4k  45010 ns  45053 ns  15678
BM_StringFindMatch1/32k 45717 ns  45761 ns  15278
BM_StringFindMatch2/1   44307 ns  44349 ns  15730
BM_StringFindMatch2/8   44631 ns  44674 ns  15721
BM_StringFindMatch2/64  44300 ns  44342 ns  15750
BM_StringFindMatch2/512 44239 ns  44281 ns  15713
BM_StringFindMatch2/4k  44886 ns  44928 ns  15787

Branch: master with patch
$ ./bin/string.libcxx.out
Run on (24 X 2892.28 MHz CPU s)
2016-12-06 18:51:38
***WARNING*** CPU scaling is enabled, the benchmark real time measurements may 
be noisy and will incur extra overhead.
Benchmark   Time   CPU Iterations
-
BM_StringFindNoMatch/1011 ns 11 ns   63049677
BM_StringFindNoMatch/6412 ns 12 ns   57259381
BM_StringFindNoMatch/512   27 ns 27 ns   25495432
BM_StringFindNoMatch/4k   130 ns130 ns5301301
BM_StringFindNoMatch/32k  858 ns859 ns 824048
BM_StringFindNoMatch/128k4091 ns   4095 ns 171493
BM_StringFindAllMatch/114 ns 14 ns   53023977
BM_StringFindAllMatch/814 ns 14 ns   51516536
BM_StringFindAllMatch/64   17 ns 17 ns   40992668
BM_StringFindAllMatch/512  37 ns 37 ns   18503267
BM_StringFindAllMatch/4k  153 ns153 ns4494458
BM_StringFindAllMatch/32k1460 ns   1461 ns 483380
BM_StringFindAllMatch/128k   5801 ns   5806 ns 120680
BM_StringFindMatch1/12062 ns   2064 ns 333144
BM_StringFindMatch1/82057 ns   2059 ns 335496
BM_StringFindMatch1/64   2083 ns   2085 ns 341469
BM_StringFindMatch1/512  2134 ns   2136 ns 336880
BM_StringFindMatch1/4k   2309 ns   2312 ns 308745
BM_StringFindMatch1/32k  3413 ns   3417 ns 208206
BM_StringFindMatch2/12053 ns   2055 ns 341523
BM_StringFindMatch2/82061 ns   2063 ns 343999
BM_StringFindMatch2/64   2075 ns   2077 ns 338479
BM_StringFindMatch2/512  2102 ns   2104 ns 332276
BM_StringFindMatch2/4k   2286 ns   2288 ns 300416
BM_StringFindMatch2/32k  3385 ns   3388 ns 204158


ChangeLog:

2016-12-07  Aditya Kumar 
   * include/bits/basic_string.tcc(find(const _CharT* __s, size_type
   __pos, size_type __n) const)): Improve the algorithm


---
 libstdc++-v3/include/bits/basic_string.tcc | 31 ++
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/libstdc++-v3/include/bits/basic_string.tcc 
b/libstdc++-v3/include/bits/basic_string.tcc
index df1e8dd..7942ee6 100644
--- a/libstdc++-v3/include/bits/basic_string.tcc
+++ b/libstdc++-v3/include/bits/basic_string.tcc
@@ -1194,14 +1194,29 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   if (__n == 0)

Re: [PATCH, GCC/ARM, gcc-5/6-branch, ping] Fix ICE when compiling empty FIQ interrupt handler in ARM mode

[Thomas Preudhomme]

On 06/12/16 11:37, Kyrill Tkachov wrote:


On 06/12/16 11:36, Thomas Preudhomme wrote:

Ping?

Best regards,



Ok if bootstrap and testing on those branches doesn't reveal any issues.


Both backport bootstrapped fine when configured with: --with-arch=armv7-a 
--with-mode=arm -with-fpu=neon-vfpv4 --with-float=hard 
--enable-languages=c,c++,fortran


Testsuite did not show any regression when compared without the patch, hence 
both committed.


Thanks!

Thomas

[arm-embedded] [PATCH, GCC/LRA] Fix PR78617: Fix conflict detection in rematerialization

[Thomas Preudhomme]

We decided to also apply this patch to fix a wrong code generation to the ARM 
embedded 6 branch.



2016-12-07  Thomas Preud'homme  

Backport from mainline
2016-12-07  Thomas Preud'homme  

gcc/
PR rtl-optimization/78617
* lra-remat.c (do_remat): Initialize live_hard_regs from live in
registers, also setting hard registers mapped to pseudo registers.

gcc/testsuite/
PR rtl-optimization/78617
* gcc.c-torture/execute/pr78617.c: New test.


Best regards,

Thomas
--- Begin Message ---

Hi,

When considering a candidate for rematerialization, LRA verifies if the 
candidate clobbers a live register before going forward with the 
rematerialization (see code starting with comment "Check clobbers do not kill 
something living."). To do this check, the set of live registers at any given 
instruction needs to be maintained. This is done by initializing the set of live 
registers when starting the forward scan of instruction in a basic block and 
updating the set by looking at REG_DEAD notes and destination register at the 
end of an iteration of the scan loop.


However the initialization suffers from 2 issues:

1) it is done from the live out set rather than live in (uses df_get_live_out 
(bb))
2) it ignores pseudo registers that have already been allocated a hard register 
(uses REG_SET_TO_HARD_REG_SET that only looks at hard register and does not look 
at reg_renumber for pseudo registers)


This patch changes the code to use df_get_live_in (bb) to initialize the 
live_hard_regs variable using a loop to check reg_renumber for pseudo registers. 
Please let me know if there is a macro to do that, I failed to find one.


ChangeLog entries are as follow:

gcc/testsuite/ChangeLog:

2016-12-01  Thomas Preud'homme  

PR rtl-optimization/78617
* gcc.c-torture/execute/pr78617.c: New test.


gcc/ChangeLog:

2016-12-01  Thomas Preud'homme  

PR rtl-optimization/78617
* lra-remat.c (do_remat): Initialize live_hard_regs from live in
registers, also setting hard registers mapped to pseudo registers.


Note however that as explained in the problem report, the testcase does not 
trigger the bug on GCC 7 due to better optimization before LRA rematerialization 
is reached.


Testing: testsuite shows no regression when run using:
 + an arm-none-eabi GCC cross-compiler targeting Cortex-M0 and Cortex-M3
 + a bootstrapped arm-linux-gnueabihf GCC native compiler
 + a bootstrapped x86_64-linux-gnu GCC native compiler

Is this ok for stage3?

Best regards,

Thomas
diff --git a/gcc/lra-remat.c b/gcc/lra-remat.c
index f01c6644c428fd9b5efdf6cc98788e5f6fadba62..cdd7057f602098d33ec3acfdaaac66556640bd82 100644
--- a/gcc/lra-remat.c
+++ b/gcc/lra-remat.c
@@ -1047,6 +1047,7 @@ update_scratch_ops (rtx_insn *remat_insn)
 static bool
 do_remat (void)
 {
+  unsigned regno;
   rtx_insn *insn;
   basic_block bb;
   bitmap_head avail_cands;
@@ -1054,12 +1055,21 @@ do_remat (void)
   bool changed_p = false;
   /* Living hard regs and hard registers of living pseudos.  */
   HARD_REG_SET live_hard_regs;
+  bitmap_iterator bi;
 
   bitmap_initialize (&avail_cands, ®_obstack);
   bitmap_initialize (&active_cands, ®_obstack);
   FOR_EACH_BB_FN (bb, cfun)
 {
-  REG_SET_TO_HARD_REG_SET (live_hard_regs, df_get_live_out (bb));
+  CLEAR_HARD_REG_SET (live_hard_regs);
+  EXECUTE_IF_SET_IN_BITMAP (df_get_live_in (bb), 0, regno, bi)
+	{
+	  int hard_regno = regno < FIRST_PSEUDO_REGISTER
+			   ? regno
+			   : reg_renumber[regno];
+	  if (hard_regno >= 0)
+	SET_HARD_REG_BIT (live_hard_regs, hard_regno);
+	}
   bitmap_and (&avail_cands, &get_remat_bb_data (bb)->avin_cands,
 		  &get_remat_bb_data (bb)->livein_cands);
   /* Activating insns are always in the same block as their corresponding
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr78617.c b/gcc/testsuite/gcc.c-torture/execute/pr78617.c
new file mode 100644
index ..89c4f6dea8cb507b963f91debb94cbe16eb1db90
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr78617.c
@@ -0,0 +1,25 @@
+int a = 0;
+int d = 1;
+int f = 1;
+
+int fn1() {
+  return a || 1 >> a;
+}
+
+int fn2(int p1, int p2) {
+  return p2 >= 2 ? p1 : p1 >> 1;
+}
+
+int fn3(int p1) {
+  return d ^ p1;
+}
+
+int fn4(int p1, int p2) {
+  return fn3(!d > fn2((f = fn1() - 1000) || p2, p1));
+}
+
+int main() {
+  if (fn4(0, 0) != 1)
+__builtin_abort ();
+  return 0;
+}
--- End Message ---

[PATCH] Fix c++/78621 generic lambda mangling

[Nathan Sidwell]

This patch fixes the generic lambda mangling bug that caused the 
demangler to infinitely recurse (78252).  The generic's auto parms fail 
the is_auto check because that's testing for the 'auto' identifier, 
whereas the parms are distinct template type parms named 'auto:$N'. 
Amending is_auto to do a textual compare of the identifier breaks 
things, and is insufficient anyway.  The mangler's squangling must (a) 
squangle subsequent auto uses as expected and (b) NOT squangle 
subsequent template type parm references to refer the the lambda's autos.


This patch achieves that by tsubsting the generic fn's parameters using 
a consed up array of regular auto types.  The make_auto_1 function is 
further split, so we can control the template LEVEL and ORIG_LEVEL 
values.  When mangling a lambda, we check if it's a generic lambda and 
then (after checking the ABI flag) perform this substitution.  We also 
set the needs_warning flag, if we detect the user's asked about ABI 
compatibility crossing version 11.


This use of tsubst can meet {TYPE,EXPR}_PARAMETER_PACKs, so I had to 
extend tsubst to process those objects.


lambda-mangle-1 is an augmented version of the testcase I included with 
78252.  It checks we retain the old mangling for ABI 10 and below.
lambda-mangle-2 is essentially the same testcase, but checks we use the 
new mangling for ABI=0

lambda-mangle-3 checks we issue a warning for -Wabi=10

I also included a demangler test for the new mangling.  It does demangle 
as expected.


Documentation about -fabi-version=11 also updated.

ok?

nathan
--
Nathan Sidwell

2016-12-07  Nathan Sidwell  

	gcc/
	PR c++/78621
	* doc/invoke.texi (-fabi-version): Document generic lambda
	mangling for version 11.

	gcc/cp/
	PR c++/78621
	* cp-tree.h (make_auto_for_mangle): Declare.
	* mangle.c (write_closure_type_name): Handle generic lambdas
	correctly.
	* pt.c (tsubst): Add {TYPE,EXPR}_PACK_EXPANSION handling.
	(make_auto_raw): Break out of ...
	(make_auto_1): ... here.  Call it.
	(make_auto_for_mangle): New.

	gcc/testsuite/
	PR c++/78621
	* g++.dg/cpp1y/lambda-mangle-1.C: New.
	* g++.dg/cpp1y/lambda-mangle-2.C: New.
	* g++.dg/cpp1y/lambda-mangle-3.C: New.

	libiberty/
	PR c++/78621
	* testsuite/demangle-expected: Add fixed-ABI generic lambda tests.

Index: gcc/cp/cp-tree.h
===
--- gcc/cp/cp-tree.h	(revision 243371)
+++ gcc/cp/cp-tree.h	(working copy)
@@ -6108,6 +6108,7 @@
 extern void check_template_variable		(tree);
 extern tree make_auto(void);
 extern tree make_decltype_auto			(void);
+extern tree make_auto_for_mangle		(tree, tree);
 extern tree make_template_placeholder		(tree);
 extern tree do_auto_deduction   (tree, tree, tree);
 extern tree do_auto_deduction   (tree, tree, tree,
Index: gcc/cp/mangle.c
===
--- gcc/cp/mangle.c	(revision 243371)
+++ gcc/cp/mangle.c	(working copy)
@@ -1640,6 +1640,19 @@
   tree lambda = CLASSTYPE_LAMBDA_EXPR (type);
   tree parms = TYPE_ARG_TYPES (TREE_TYPE (fn));
 
+  if (generic_lambda_fn_p (fn))
+{
+  /* A generic lambda's auto parms are represented as distinct
+ TEMPLATE_TYPE_PARMs, which are both distinct and not is_auto.
+ But we must mangle (& squangle) them as (the same) 'auto'.
+ So do some substitution to arrange that.  */
+  if (abi_warn_or_compat_version_crosses (11))
+	G.need_abi_warning = 1;
+
+  if (abi_version_at_least (11))
+	parms = make_auto_for_mangle (fn, parms);
+}
+
   MANGLE_TRACE_TREE ("closure-type-name", type);
 
   write_string ("Ul");
Index: gcc/cp/pt.c
===
--- gcc/cp/pt.c	(revision 243371)
+++ gcc/cp/pt.c	(working copy)
@@ -13813,6 +13813,42 @@
 	return r;
   }
 
+case TYPE_PACK_EXPANSION:
+case EXPR_PACK_EXPANSION:
+  {
+	tree r;
+
+	if (code == EXPR_PACK_EXPANSION)
+	  {
+	r = make_node (code);
+	TREE_TYPE (r) = type;
+	TREE_CONSTANT (r) = TREE_CONSTANT (t);
+	PACK_EXPANSION_SIZEOF_P (r) = PACK_EXPANSION_SIZEOF_P (t);
+	  }
+	else
+	  {
+	r = cxx_make_type (code);
+	SET_TYPE_STRUCTURAL_EQUALITY (r);
+	  }
+
+	WILDCARD_PACK_P (r) = WILDCARD_PACK_P (t);
+	PACK_EXPANSION_LOCAL_P (r) = PACK_EXPANSION_LOCAL_P (t);
+
+	tree pattern = PACK_EXPANSION_PATTERN (t);
+	pattern = tsubst (pattern, args, complain, in_decl);
+	SET_PACK_EXPANSION_PATTERN (r, pattern);
+
+	tree packs = PACK_EXPANSION_PARAMETER_PACKS (t);
+	packs = tsubst (packs, args, complain, in_decl);
+	PACK_EXPANSION_PARAMETER_PACKS (r) = packs;
+
+	tree extra = PACK_EXPANSION_EXTRA_ARGS (t);
+	extra = tsubst (extra, args, complain, in_decl);
+	PACK_EXPANSION_EXTRA_ARGS (r) = extra;
+
+	return r;
+  }
+
 case VOID_CST:
 case INTEGER_CST:
 case REAL_CST:
@@ -24278,20 +24314,19 @@
 }
 }
 
-/* Returns a type which represents 'auto' or 'decltype(auto)'.  We use a
-   TEMP

Re: [PATCH] handle integer overflow/wrapping in printf directives (PR 78622)

[Jeff Law]

On 12/02/2016 03:54 PM, Martin Sebor wrote:

Thanks for looking at this!  I realize it's dense code and not easy
to make sense out of.

+
+  if (TREE_CODE (*argmin) == INTEGER_CST
+  && TREE_CODE (*argmax) == INTEGER_CST
+  && (dirprec >= argprec
+  || integer_zerop (int_const_binop (RSHIFT_EXPR,
+ int_const_binop (MINUS_EXPR,
+  *argmax,
+  *argmin),
+ size_int (dirprec)
+  {
+*argmin = force_fit_type (dirtype, wi::to_widest (*argmin), 0,
false);
+*argmax = force_fit_type (dirtype, wi::to_widest (*argmax), 0,
false);
+return false;
+  }

So in this case we're not changing the values, we're just converting
them to a equal or wider type, right?  Thus no adjustment (what about a
sign change?  Is that an adjustment?) and we return false per the
function's specifications.


This casts the value to the destination type, so it may result in
different values.  The important postcondition it preserves is that
the difference ARGMAX - ARGMIN is less than or equal to TYPE_MAX of
the directive's unsigned TYPE.  (If it isn't, the range cannot be
converted.)  This lets us take, say:

  int f (int i)
  {
if (i < 1024 || 1033 < i)
   i = 1024;

return snprintf (0, 0, "%hhi", i);
  }

and fold the function call into 1 because (signed char)1024 is 0 and
(signed char)1033 is 9, and every other value in that same original
range is also in the same range after the conversion.  We know it's
safe because (1033 - 1024 <= UCHAR_MAX) holds.
But the code in question is guarded by dirprec >= argprec.  Thus aren't 
we converting to an equal or wider type?  In the case of converting to a 
wider type, ISTM the values won't change and thus we return false.


If we are converting to the same sized type, but with a different 
signedness, then the values will have been adjusted and ISTM we ought to 
be returning true in that case.  But the code actually returns false.


I must be missing something here.








What about overflows when either argmin or argmax won't fit into dirtype
without an overflow?  What's the right behavior there?


That's fine just as long as the property above holds.

I think the algorithm works but the code came from tree-vrp where
there are all sorts of additional checks for some infinities which
VRP distinguishes from type limits like SCHAR_MIN and _MAX.  I don't
fully understand those and so I'd feel better if someone who does
double checked this code.
That's what prompted my question about overflows.  It was a general 
concern after reading the VRP code.  I did not have a specific case in 
mind that would be mis-handled.








+
+  tree dirmin = TYPE_MIN_VALUE (dirtype);
+  tree dirmax = TYPE_MAX_VALUE (dirtype);

From this point onward argmin/argmax are either not integers or we're
doing a narrowing conversion, right?  In both cases the fact that we're
doing a narrowing conversion constrains the range


Argmin and argmax are always integers.  The rest of the function
handles the case where the postcondition above doesn't hold (e.g.,
in function g above).
OK.  So is the hangup really a problem in how the return type is 
documented?  I parsed the comment as essentially saying we return true 
if the range gets adjusted in any way -- thus a sign change in the first 
block would qualify, but we returned false which seemed inconsistent.


Looking at it again, what I think it's saying is we're returning true 
only for a subset of adjustments to the range, ie, those cases where the 
postcondition does not hold.  Correct?








+
+  if (TYPE_UNSIGNED (dirtype))
+{
+  *argmin = dirmin;
+  *argmax = dirmax;
+}
+  else
+{
+  *argmin = integer_zero_node;
+  *argmax = dirmin;
+}

Should this be dirmax? Am I missing something here?


It's dirmin because for a signed type, due to the sign, it results
in more bytes on output than dirmin would.  (E.g., with SCHAR_MIN
= -128 and SCHAR_MAX = 127 it's four bytes vs three.)

Ah.  I understand that.  THanks for clarifying.

jeff

[PATCH] Enable -fsanitize-address-use-after-scope only if -fsanitize=address is enabled

[Dmitry Vyukov]

Hello,

Revision 241896 added -fsanitize-address-use-after-scope and enabled
it whenever any sanitizer is enabled. This caused problems for kernel
which does not have necessary callbacks for
-fsanitize-address-use-after-scope. I've added the callbacks to kernel
tip, but older kernel branches still don't have them.

So enable -fsanitize-address-use-after-scope iff -fsanitize=address is
enabled. In the kernel we will check if
-fsanitize-address-use-after-scope is present and enable it only on
versions that have the callbacks.
As a side effect this also doesn't enable
-fsanitize-address-use-after-scope for e.g. -fsanitize=thread, which
is I believe unnecessary.

OK for trunk?
Index: gcc/ChangeLog
===
--- gcc/ChangeLog	(revision 243344)
+++ gcc/ChangeLog	(working copy)
@@ -1,3 +1,10 @@
+2016-12-07  Dmitry Vyukov  
+
+	* opts.c (finish_options): Enable
+	-fsanitize-address-use-after-scope only if
+	-fsanitize=address is enabled (not
+	-fsanitize=kernel-address).
+
 2016-12-07  Bin Cheng  
 
 	PR tree-optimization/78691
Index: gcc/opts.c
===
--- gcc/opts.c	(revision 243344)
+++ gcc/opts.c	(working copy)
@@ -990,7 +990,7 @@
 
   /* Enable -fsanitize-address-use-after-scope if address sanitizer is
  enabled.  */
-  if (opts->x_flag_sanitize
+  if ((opts->x_flag_sanitize & SANITIZE_USER_ADDRESS)
   && !opts_set->x_flag_sanitize_address_use_after_scope)
 opts->x_flag_sanitize_address_use_after_scope = true;
 

Re: [PATCH] Enable -fsanitize-address-use-after-scope only if -fsanitize=address is enabled

[Jakub Jelinek]

On Wed, Dec 07, 2016 at 07:44:39PM +0100, Dmitry Vyukov wrote:
> OK for trunk?

> Index: gcc/ChangeLog
> ===
> --- gcc/ChangeLog (revision 243344)
> +++ gcc/ChangeLog (working copy)
> @@ -1,3 +1,10 @@
> +2016-12-07  Dmitry Vyukov  
> +
> + * opts.c (finish_options): Enable
> + -fsanitize-address-use-after-scope only if
> + -fsanitize=address is enabled (not
> + -fsanitize=kernel-address).
> +
>  2016-12-07  Bin Cheng  
>  
>   PR tree-optimization/78691

Ok, thanks.

> Index: gcc/opts.c
> ===
> --- gcc/opts.c(revision 243344)
> +++ gcc/opts.c(working copy)
> @@ -990,7 +990,7 @@
>  
>/* Enable -fsanitize-address-use-after-scope if address sanitizer is
>   enabled.  */
> -  if (opts->x_flag_sanitize
> +  if ((opts->x_flag_sanitize & SANITIZE_USER_ADDRESS)
>&& !opts_set->x_flag_sanitize_address_use_after_scope)
>  opts->x_flag_sanitize_address_use_after_scope = true;
>  


Jakub

Re: [PATCH] handle integer overflow/wrapping in printf directives (PR 78622)

[Jeff Law]

On 12/05/2016 08:43 PM, Martin Sebor wrote:


Martin

$ cat b.c && /build/gcc-78622/gcc/xgcc -B /build/gcc-78622/gcc -O2 -S
-Wall -Wextra -Wpedantic b.c
char d[1];

void f (int i)
{
  if (i < 1024 || 1033 < i) i = 1024;

  __builtin_sprintf (d + 1, "%hhi", i);
}

void g (int i)
{
  if (i < 1024 || 3456 < i) i = 1024;

  __builtin_sprintf (d + 1, "%hhi", i);
}

b.c: In function ‘f’:
b.c:7:30: warning: ‘%hhi’ directive writing 1 byte into a region of size
0 [-Wformat-length=]
   __builtin_sprintf (d + 1, "%hhi", i);
  ^~~~
b.c:7:29: note: directive argument in the range [1024, 1033]
   __builtin_sprintf (d + 1, "%hhi", i);
 ^~
b.c:7:3: note: format output 2 bytes into a destination of size 0
   __builtin_sprintf (d + 1, "%hhi", i);
   ^~~~
b.c: In function ‘g’:
b.c:14:30: warning: ‘%hhi’ directive writing between 1 and 4 bytes into
a region of size 0 [-Wformat-length=]
   __builtin_sprintf (d + 1, "%hhi", i);
  ^~~~
b.c:14:29: note: using the range [0, -128] for directive argument
   __builtin_sprintf (d + 1, "%hhi", i);
 ^~
b.c:14:3: note: format output between 2 and 5 bytes into a destination
of size 0
   __builtin_sprintf (d + 1, "%hhi", i);
   ^~~~


gcc-78622.diff


PR middle-end/78622 - [7 Regression] -Wformat-length/-fprintf-return-value 
incorrect with overflow/wrapping

gcc/ChangeLog:

PR middle-end/78622
* gimple-ssa-sprintf.c (min_bytes_remaining): Use res.knownrange
rather than res.bounded.
(adjust_range_for_overflow): New function.
(format_integer): Always set res.bounded to true unless either
precision or width is specified and unknown.
Call adjust_range_for_overflow.
(format_directive): Remove vestigial quoting.  Always inform of
argument value or range when it's available.
(add_bytes): Correct the computation of boundrange used to
decide whether a warning is of a "maybe" or "defnitely" kind.

gcc/testsuite/ChangeLog:

PR middle-end/78622
* gcc.c-torture/execute/pr78622.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-2.c: Remove "benign" undefined
behavior inadvertently introduced in a previous commit.  Tighten
up final checking.
* gcc.dg/tree-ssa/builtin-sprintf-5.c: Rename macros for clarity.
Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-6.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-5.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-6.c: Remove xfails and
add a final optimization check.
* 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 99a635a..a888f55 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -795,6 +795,59 @@ get_width_and_precision (const conversion_spec &spec,
   *pprec = prec;
 }

+/* With the range [*ARGMIN, *ARGMAX] of an integer directive's actual
+   argument, due to the conversion from either *ARGMIN or *ARGMAX to
+   the type of the directive's formal argument it's possible for both
+   to result in the same number of bytes or a range of bytes that's
+   less than the number of bytes that would result from formatting
+   some other value in the range [*ARGMIN, *ARGMAX].  This can be
+   determined by checking for the actual argument being in the range
+   of the type of the directive.  If it isn't it must be assumed to
+   take on the full range of the directive's type.
+   Return true when the range has been adjusted to the range of
+   DIRTYPE, false otherwise.  */
So I think the return value needs a bit of clarification here.  Take 
guidance from our discussion on this thread.


OK with that fixed.

jeff

[C++ PATCH] P0003R5 - removal of dynamic exception specification from C++17

[Jakub Jelinek]

Hi!

This patch attempts to implement the P0003R5 paper (I could find
just traces of it in the github repo and the wording in n4618.pdf).
I think throw() is still so commonly used that emitting deprecation warning
for it is undesirable (in any mode).

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

I've tried to keep dynamic exception specification tests in the testsuite as
much as possible even for -std=c++11 and -std=c++14, so often it means
expecting the deprecation warning for those.  For -std=c++1z, the behavior
of throw() changes, it works as noexcept(true), so e.g. tests that expect
the unexpected handler to be called had to be guarded for c++14_down.
For destructors for C++17 typically I've been replacing throw (type-id-list) 
with
noexcept(false), otherwise ifdefing it out, though in some testcases it has
the dg-error lines to ensure it is properly rejected for C++17.

Jonathan, there is one hunk in libstdc++ still needed (on top of what you've
committed today).  Is that ok with you?

2016-12-07  Jakub Jelinek  

P0003R5 - removal of dynamic exception specification from C++17
* parser.c (cp_parser_exception_specification_opt): For C++17
error out on throw ( type-id-list ), for C++11 and C++14 issue
-Wdeprecated warning on it.  Formatting fix.  Treat throw()
in C++17 as noexcept(true).

* g++.dg/template/error36.C: Adjust for deprecation of
throw (type-id-list) in C++11 and C++14 and removal in C++17.
* g++.dg/template/eh2.C: Likewise.
* g++.dg/cpp1z/noexcept-type1.C: Likewise.
* g++.dg/compat/eh/spec3_x.C: Likewise.
* g++.dg/compat/eh/new1_y.C: Likewise.
* g++.dg/compat/eh/new1_x.C: Likewise.
* g++.dg/compat/eh/template1_y.C: Likewise.
* g++.dg/compat/eh/template1.h: Likewise.
* g++.dg/compat/eh/ctor1.h: Likewise.
* g++.dg/compat/eh/ctor1_y.C: Likewise.
* g++.dg/compat/eh/spec3_y.C: Likewise.
* g++.dg/compat/eh/unexpected1_x.C: Likewise.
* g++.dg/compat/eh/unexpected1_y.C: Likewise.
* g++.dg/init/new13.C: Likewise.
* g++.dg/init/new25.C: Likewise.
* g++.dg/opt/noreturn-1.C: Likewise.
* g++.dg/eh/spec3.C: Likewise.
* g++.dg/eh/forced3.C: Likewise.
* g++.dg/eh/forced4.C: Likewise.
* g++.dg/eh/async-unwind2.C: Likewise.
* g++.dg/eh/template1.C: Likewise.
* g++.dg/eh/pr38662.C: Likewise.
* g++.dg/eh/spec2.C: Likewise.
* g++.dg/eh/shadow1.C: Likewise.
* g++.dg/eh/spec7.C: Likewise.
* g++.dg/eh/spec5.C: Likewise.
* g++.dg/eh/spec6.C: Likewise.
* g++.dg/eh/delete1.C: Likewise.
* g++.dg/eh/spec9.C: Likewise.
* g++.dg/eh/pr41819.C: Likewise.
* g++.dg/eh/init-temp2.C: Likewise.
* g++.dg/eh/ehopt1.C: Likewise.
* g++.dg/eh/unexpected1.C: Likewise.
* g++.dg/eh/cond4.C: Likewise.
* g++.dg/eh/spec8.C: Likewise.
* g++.dg/other/error3.C: Likewise.
* g++.dg/rtti/crash3.C: Likewise.
* g++.dg/warn/Wreturn-type-3.C: Likewise.
* g++.dg/gcov/gcov-7.C: Likewise.
* g++.dg/tree-ssa/pr45605.C: Likewise.
* g++.dg/lookup/exception1.C: Likewise.
* g++.dg/tm/pr46567.C: Likewise.
* g++.dg/tm/pr47340.C: Likewise.
* g++.dg/ext/has_nothrow_copy-1.C: Likewise.
* g++.dg/ext/has_nothrow_copy-6.C: Likewise.
* g++.dg/ext/has_nothrow_copy-7.C: Likewise.
* g++.dg/ext/has_nothrow_copy-4.C: Likewise.
* g++.dg/ext/has_nothrow_copy-2.C: Likewise.
* g++.dg/ext/has_nothrow_assign.C: Likewise.
* g++.dg/ext/has_nothrow_copy-5.C: Likewise.
* g++.dg/ext/has_nothrow_constructor.C: Likewise.
* g++.dg/torture/pr49394.C: Likewise.
* g++.dg/torture/pr52918-1.C: Likewise.
* g++.dg/torture/pr57190.C: Likewise.
* g++.dg/torture/pr46364.C: Likewise.
* g++.dg/torture/stackalign/eh-global-1.C: Likewise.
* g++.dg/torture/stackalign/eh-fastcall-1.C: Likewise.
* g++.dg/torture/stackalign/eh-vararg-2.C: Likewise.
* g++.dg/torture/stackalign/eh-vararg-1.C: Likewise.
* g++.dg/torture/stackalign/eh-inline-2.C: Likewise.
* g++.dg/torture/stackalign/eh-thiscall-1.C: Likewise.
* g++.dg/torture/stackalign/eh-inline-1.C: Likewise.
* g++.dg/torture/stackalign/eh-alloca-1.C: Likewise.
* g++.dg/cpp0x/variadic73.C: Likewise.
* g++.dg/cpp0x/noexcept02.C: Likewise.
* g++.dg/cpp0x/noexcept07.C: Likewise.
* g++.dg/cpp0x/noexcept08.C: Likewise.
* g++.dg/cpp0x/defaulted23.C: Likewise.
* g++.dg/cpp0x/auto9.C: Likewise.
* g++.dg/cpp0x/variadic-throw.C: Likewise.
* g++.dg/cpp0x/error5.C: Likewise.
* g++.dg/cpp0x/noexcept19.C: Likewise.
* g++.dg/cpp0x/lambda/lambda-eh2.C: Likewise.
* g++.old-deja/g++.robertl/eb123.C: Likewise.

Re: [PATCH] Fix cgraph_edge::redirect_call_stmt_to_callee noreturn call handling (PR c++/78692)

[Jeff Law]

On 12/07/2016 10:28 AM, Jakub Jelinek wrote:

Hi!

The code in this function assumes that lhs is the lhs of new_stmt (it tests
that new_stmt is a noreturn call etc.), but that is only the case if
new_stmt == e->call_stmt.  But in the function it can be set to various
other stmts.  Nothing tests the lhs before this noreturn handling, so this
patch fixes it by moving the initialization of lhs right before the use.

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

2016-12-07  Jakub Jelinek  

PR c++/78692
* cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Set lhs
var to lhs of new_stmt right before noreturn handling rather than to
lhs of e->call_stmt early.

* g++.dg/torture/pr78692.C: New test.

OK.
jeff

Re: [Patch, fortran] PR44265 - Link error with reference to parameter array in specification expression

[Dominique d'Humières]

The tests gfortran.dg/char_result_16.f90 and gfortran.dg/char_result_17.f90 
fail with

lto1: error: two or more sections for .gnu.lto___get_PROC_names.3e3ee55b08747e7c
lto1: internal compiler error: cannot read LTO decls from 
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccEJosbA.o

This may be darwin specific as the linker is more picky than the linux one.

Dominique

> Le 7 déc. 2016 à 16:47, Paul Richard Thomas  a 
> écrit :
> 
> Dear Dominique,
> 
> I will turn to the effect on PR77414 after committing the patch for PR44265.
> 
> The attached fixes the -flto problem. The chunk in
> trans-decl.c(gfc_finish_var_decl) did the job. It is quite obvious now
> and, in fact, I am a bit surprised that the patch worked at all
> without the DECL_EXTERNAL.
> 
> Bootstraps and regtests on FC21/x86_64 - OK for trunk?
> 
> Paul
> 
> 2016-12-07  Paul Thomas  
> 
>PR fortran/44265
>* gfortran.h : Add fn_result_spec bitfield to gfc_symbol.
>* resolve.c (flag_fn_result_spec): New function.
>(resolve_fntype): Call it for character result lengths.
>* symbol.c (gfc_new_symbol): Set fn_result_spec to zero.
>* trans-decl.c (gfc_sym_mangled_identifier): Include the
>procedure name in the mangled name for symbols with the
>fn_result_spec bit set.
>(gfc_finish_var_decl): Mark the decls of these symbols
>appropriately for the case where the function is external.
>(gfc_get_symbol_decl): Mangle the name of these symbols.
>(gfc_create_module_variable): Allow them through the assert.
>(gfc_generate_function_code): Remove the assert before the
>initialization of sym->tlink because the frontend no longer
>uses this field.
>* trans-expr.c (gfc_map_intrinsic_function): Add a case to
>treat the LEN_TRIM intrinsic.
> 
> 2016-12-07  Paul Thomas  
> 
>PR fortran/44265
>* gfortran.dg/char_result_14.f90: New test.
>* gfortran.dg/char_result_15.f90: New test.
>* gfortran.dg/char_result_16.f90: New test.
>* gfortran.dg/char_result_17.f90: New test.
> 
> 

Re: [PATCH] handle integer overflow/wrapping in printf directives (PR 78622)

[Martin Sebor]

On 12/07/2016 11:43 AM, Jeff Law wrote:

On 12/02/2016 03:54 PM, Martin Sebor wrote:

Thanks for looking at this!  I realize it's dense code and not easy
to make sense out of.

+
+  if (TREE_CODE (*argmin) == INTEGER_CST
+  && TREE_CODE (*argmax) == INTEGER_CST
+  && (dirprec >= argprec
+  || integer_zerop (int_const_binop (RSHIFT_EXPR,
+ int_const_binop (MINUS_EXPR,
+  *argmax,
+  *argmin),
+ size_int (dirprec)
+  {
+*argmin = force_fit_type (dirtype, wi::to_widest (*argmin), 0,
false);
+*argmax = force_fit_type (dirtype, wi::to_widest (*argmax), 0,
false);
+return false;
+  }

So in this case we're not changing the values, we're just converting
them to a equal or wider type, right?  Thus no adjustment (what about a
sign change?  Is that an adjustment?) and we return false per the
function's specifications.


This casts the value to the destination type, so it may result in
different values.  The important postcondition it preserves is that
the difference ARGMAX - ARGMIN is less than or equal to TYPE_MAX of
the directive's unsigned TYPE.  (If it isn't, the range cannot be
converted.)  This lets us take, say:

  int f (int i)
  {
if (i < 1024 || 1033 < i)
   i = 1024;

return snprintf (0, 0, "%hhi", i);
  }

and fold the function call into 1 because (signed char)1024 is 0 and
(signed char)1033 is 9, and every other value in that same original
range is also in the same range after the conversion.  We know it's
safe because (1033 - 1024 <= UCHAR_MAX) holds.

But the code in question is guarded by dirprec >= argprec.  Thus aren't
we converting to an equal or wider type?  In the case of converting to a
wider type, ISTM the values won't change and thus we return false.


I just saw your other response after I typed this up (thanks!) but
so just to close the loop:

You're right, when converting to a wider type the values won't change.

The guard is an OR expression:

  dirprec >= argprec
  OR
  0 == ((ARGMAX - ARGMIN) >> TYPE_PRECISION (dirtype))

and so when (dirprec < argprec) holds the values might change if
the other operand is true.  In both of these cases the function
returns false to indicate that the original range the arguments
were in hasn't changed as a result.



If we are converting to the same sized type, but with a different
signedness, then the values will have been adjusted and ISTM we ought to
be returning true in that case.  But the code actually returns false.

I must be missing something here.


The return value of the function is only used to decide the phrasing
of the notes printed after warnings and what values to include in
them.  Returning false means that the notes will say something like
"directive argument in the range [ARGMIN, ARGMAX]" where the values
are those determined by VRP.  Returning true means that the note
will instead say "using the range [TYPE_MIN, 0] for directive
argument." This distinction will (I hope) let the user know that
the second case is less accurate than the first.  It's somewhat
subtle but I think useful to understand why the checker decided
to warn.  Once I'm done with all my work I'd like to document this
in more  detail on the Wiki.



What about overflows when either argmin or argmax won't fit into dirtype
without an overflow?  What's the right behavior there?


That's fine just as long as the property above holds.

I think the algorithm works but the code came from tree-vrp where
there are all sorts of additional checks for some infinities which
VRP distinguishes from type limits like SCHAR_MIN and _MAX.  I don't
fully understand those and so I'd feel better if someone who does
double checked this code.

That's what prompted my question about overflows.  It was a general
concern after reading the VRP code.  I did not have a specific case in
mind that would be mis-handled.


Okay.


+  tree dirmin = TYPE_MIN_VALUE (dirtype);
+  tree dirmax = TYPE_MAX_VALUE (dirtype);

From this point onward argmin/argmax are either not integers or we're
doing a narrowing conversion, right?  In both cases the fact that we're
doing a narrowing conversion constrains the range


Argmin and argmax are always integers.  The rest of the function
handles the case where the postcondition above doesn't hold (e.g.,
in function g above).

OK.  So is the hangup really a problem in how the return type is
documented?  I parsed the comment as essentially saying we return true
if the range gets adjusted in any way -- thus a sign change in the first
block would qualify, but we returned false which seemed inconsistent.

Looking at it again, what I think it's saying is we're returning true
only for a subset of adjustments to the range, ie, those cases where the
postcondition does not hold.  Correct?


Correct.  Would changing the description of the return value to
this make it clearer?

   Return true when the range has been adjuste

Re: [PATCH] Enable -fsanitize-address-use-after-scope only if -fsanitize=address is enabled

[Sandra Loosemore]

On 12/07/2016 11:44 AM, Dmitry Vyukov wrote:

Hello,

Revision 241896 added -fsanitize-address-use-after-scope and enabled
it whenever any sanitizer is enabled. This caused problems for kernel
which does not have necessary callbacks for
-fsanitize-address-use-after-scope. I've added the callbacks to kernel
tip, but older kernel branches still don't have them.

So enable -fsanitize-address-use-after-scope iff -fsanitize=address is
enabled. In the kernel we will check if
-fsanitize-address-use-after-scope is present and enable it only on
versions that have the callbacks.
As a side effect this also doesn't enable
-fsanitize-address-use-after-scope for e.g. -fsanitize=thread, which
is I believe unnecessary.

OK for trunk?

Index: gcc/ChangeLog
===
--- gcc/ChangeLog   (revision 243344)
+++ gcc/ChangeLog   (working copy)
@@ -1,3 +1,10 @@
+2016-12-07  Dmitry Vyukov  
+
+   * opts.c (finish_options): Enable
+   -fsanitize-address-use-after-scope only if
+   -fsanitize=address is enabled (not
+   -fsanitize=kernel-address).
+
 2016-12-07  Bin Cheng  

PR tree-optimization/78691


You need to fix doc/invoke.texi as well to reflect this change.

-Sandra

Re: [PATCH] Enable -fsanitize-address-use-after-scope only if -fsanitize=address is enabled

[Dmitry Vyukov]

On Wed, Dec 7, 2016 at 8:23 PM, Sandra Loosemore
 wrote:
> On 12/07/2016 11:44 AM, Dmitry Vyukov wrote:
>>
>> Hello,
>>
>> Revision 241896 added -fsanitize-address-use-after-scope and enabled
>> it whenever any sanitizer is enabled. This caused problems for kernel
>> which does not have necessary callbacks for
>> -fsanitize-address-use-after-scope. I've added the callbacks to kernel
>> tip, but older kernel branches still don't have them.
>>
>> So enable -fsanitize-address-use-after-scope iff -fsanitize=address is
>> enabled. In the kernel we will check if
>> -fsanitize-address-use-after-scope is present and enable it only on
>> versions that have the callbacks.
>> As a side effect this also doesn't enable
>> -fsanitize-address-use-after-scope for e.g. -fsanitize=thread, which
>> is I believe unnecessary.
>>
>> OK for trunk?
>>
>> Index: gcc/ChangeLog
>> ===
>> --- gcc/ChangeLog   (revision 243344)
>> +++ gcc/ChangeLog   (working copy)
>> @@ -1,3 +1,10 @@
>> +2016-12-07  Dmitry Vyukov  
>> +
>> +   * opts.c (finish_options): Enable
>> +   -fsanitize-address-use-after-scope only if
>> +   -fsanitize=address is enabled (not
>> +   -fsanitize=kernel-address).
>> +
>>  2016-12-07  Bin Cheng  
>>
>> PR tree-optimization/78691
>
>
> You need to fix doc/invoke.texi as well to reflect this change.

Done.

Attached updated patch.
Index: gcc/ChangeLog
===
--- gcc/ChangeLog	(revision 243344)
+++ gcc/ChangeLog	(working copy)
@@ -1,3 +1,11 @@
+2016-12-07  Dmitry Vyukov  
+
+	* opts.c (finish_options): Enable
+	-fsanitize-address-use-after-scope only if -fsanitize=address is enabled
+	(not -fsanitize=kernel-address).
+	* doc/invoke.texi (-fsanitize=kernel-address):
+	Don't say that it enables -fsanitize-address-use-after-scope.
+
 2016-12-07  Bin Cheng  
 
 	PR tree-optimization/78691
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 243344)
+++ gcc/doc/invoke.texi	(working copy)
@@ -10559,7 +10559,6 @@
 @item -fsanitize=kernel-address
 @opindex fsanitize=kernel-address
 Enable AddressSanitizer for Linux kernel.
-The option enables @option{-fsanitize-address-use-after-scope}.
 See @uref{https://github.com/google/kasan/wiki} for more details.
 
 @item -fsanitize=thread
Index: gcc/opts.c
===
--- gcc/opts.c	(revision 243344)
+++ gcc/opts.c	(working copy)
@@ -990,7 +990,7 @@
 
   /* Enable -fsanitize-address-use-after-scope if address sanitizer is
  enabled.  */
-  if (opts->x_flag_sanitize
+  if ((opts->x_flag_sanitize & SANITIZE_USER_ADDRESS)
   && !opts_set->x_flag_sanitize_address_use_after_scope)
 opts->x_flag_sanitize_address_use_after_scope = true;
 

Re: [PING] [PATCH] enhance buffer overflow warnings (and c/53562)

[Jeff Law]

On 11/09/2016 03:49 PM, Martin Sebor wrote:




gcc-53562.diff


PR c/53562 - Add -Werror= support for -D_FORTIFY_SOURCE / __builtin___memcpy_chk
PR middle-end/77784 - duplicate warning for snprintf when n > object size
PR middle-end/78149 - missing warning on strncpy buffer overflow due to an 
excessive bound
PR middle-end/78138 - missing warnings on buffer overflow with non-constant 
source length

gcc/c-family/ChangeLog:
PR c/53562
* c.opt (-Wstringop-overflow): New option.

gcc/ChangeLog:
PR c/53562
PR middle-end/77784
PR middle-end/78149
PR middle-end/78138

* builtins.c (expand_builtin_strcat, expand_builtin_strncat): New
functions.
(compute_dest_size, get_size_range, check_sizes, check_strncat_sizes)
(check_memop_sizes): Same.
(expand_builtin_memcpy): Call check memop_sizes.
(expand_builtin_mempcpy): Same.
(expand_builtin_memset): Same,
(expand_builtin_bzero): Same.
(expand_builtin_memory_chk): Call check_sizes.
(expand_builtin_strcpy): Same.
(expand_builtin_strncpy): Same.
(maybe_emit_sprintf_chk_warning): Same.
(expand_builtin): Handle strcat and strncat.
(fini_object_sizes): Reset pointers.
(compute_object_size): New function.
* gimple-ssa-sprintf.c (pass_sprintf_length::handle_gimple_call):
Avoid issuing warnings also issued during built-in expansion.
* doc/invoke.texi (Warning Options): Document -Wstringop-overflow.

gcc/testsuite/ChangeLog:
PR c/53562
PR middle-end/77784
PR middle-end/78149
PR middle-end/78138

* c-c++-common/Wsizeof-pointer-memaccess2.c: Adjust expected diagnostic.
* g++.dg/ext/builtin-object-size3.C (bar): Same.
* g++.dg/ext/strncpy-chk1.C: Same.
* g++.dg/opt/memcpy1.C: Same.
* g++.dg/torture/Wsizeof-pointer-memaccess1.C: Same.
* gcc.c-torture/compile/pr55569.c: Disable -Wstringop-overflow.
* gcc.dg/Wobjsize-1.c: Adjust expected diagnostic.
* gcc.dg/attr-alloc_size.c: Same.
* gcc.dg/builtin-stringop-chk-1.c: Adjust expected diagnostic.
* gcc.dg/builtin-stringop-chk-2.c: Same.
* gcc.dg/builtin-stringop-chk-4.c: New test.
* gcc.dg/builtin-strncat-chk-1.c: Adjust expected diagnostic.
* gcc.dg/memcpy-2.c: Same.
* gcc.dg/pr40340-1.c: Same.
* gcc.dg/pr40340-2.c (main): Same.
* gcc.dg/pr40340-5.c (main): Same.
* gcc.dg/torture/Wsizeof-pointer-memaccess1.c: Same.
* gcc.dg/torture/pr71132.c: Disable -Wstringop-overflow.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust text of expected
warning.

* gcc.dg/fstack-protector-strong.c: Add expected diagnostic.
diff --git a/gcc/builtins.c b/gcc/builtins.c
index cc711a0..cb7bbaf 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -3011,6 +3013,295 @@ expand_builtin_memcpy_args (tree dest, tree src, tree 
len, rtx target, tree exp)
   return dest_addr;
 }

+/* Fill the 2-element RANGE array with the minimum and maximum values
+   EXP is known to have and return true, otherwise null and return
+   false.  */
+
+static bool
+get_size_range (tree exp, tree range[2])
+{
+  if (tree_fits_uhwi_p (exp))
+{
+  range[0] = range[1] = exp;
+  return true;
+}
+
+  if (TREE_CODE (exp) == SSA_NAME)
+{
+  wide_int min, max;
+  enum value_range_type range_type = get_range_info (exp, &min, &max);
+
+  if (range_type == VR_RANGE)
+   {
+ /* Interpret the bound in the variable's type.  */
+ range[0] = wide_int_to_tree (TREE_TYPE (exp), min);
+ range[1] = wide_int_to_tree (TREE_TYPE (exp), max);
+ return true;
+   }
+  else if (range_type == VR_ANTI_RANGE)
+   {
+ /* An anti-range implies the original variable is signed and
+its lower bound is negative and the upper bound positive.
+Since that means that the expression's value could be zero
+nothing interesting can be inferred from this.  */
I'm not sure I agree with this comment.  For example, we often get an 
anti-range like ~[0,0].


I don't mind punting anti-ranges, but I think the comments needs 
updating unless there's something else in this code that ensures that an 
anti range reaching this point fits the property above.




+/* Try to verify that the sizes and lengths of the arguments to a string
+   manipulation function given by EXP are within valid bounds and that
+   the operation does not lead to buffer overflow.  Arguments other than
+   EXP may be null.  When non-null, the arguments have the following
+   meaning:
+   SIZE is the user-supplied size argument to the function (such as in
+   memcpy(d, s, SIZE) or strncpy(d, s, SIZE).  It specifies the exact
+   number of bytes to write.
+   MAXLEN is the user-supplied bound on the length of the source sequence
+   (such as in strnca

Re: [PATCH] Move __builtin_strstr folding from builtins.c to fold-const-call.c + gimple-fold.c; plus a constexpr testcase for strstr

[Jeff Law]

On 12/07/2016 10:30 AM, Jakub Jelinek wrote:

Hi!

As discussed on IRC, this patch adds a constexpr handling testcase for
the strstr builtin and moves it over to the desired files (gimple-fold.c
and fold-const-call.c).

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

2016-12-07  Jakub Jelinek  

* builtins.c (fold_builtin_strstr): Removed.
(fold_builtin_2): Don't call fold_builtin_strstr.
* gimple-fold.c (gimple_fold_builtin_strchr): Check is_strrchr
earlier in the strrchr (x, 0) -> strchr (x, 0) optimization.
(gimple_fold_builtin_strstr): New function.
(gimple_fold_builtin): Call it.
* fold-const-call.c (fold_const_call): Handle CFN_BUILT_IN_STRSTR.

OK.
jeff

Re: [PATCH] C FE: implement fix-it hint for -Wmissing-braces

[Jeff Law]

On 11/11/2016 06:30 PM, David Malcolm wrote:

This patch implements fix-it hints to -Wmissing-braces, showing where to
add braces.

For example:

  $ cat test.c
  int arr_2_3_2[2][3][2] =
{ 0, 1, 2, 3, 4, 5,
  6, 7, 8, 9, 10, 11};

  $ ./xgcc -B. -c test.c -Wall -fdiagnostics-generate-patch
  test.c:2:3: warning: missing braces around initializer [-Wmissing-braces]
 { 0, 1, 2, 3, 4, 5,
 ^
   {
   {   } {   } {   }
   }
   6, 7, 8, 9, 10, 11};
   {
   {   } {   } { }
 }
  --- test.c
  +++ test.c
  @@ -1,3 +1,3 @@
   int arr_2_3_2[2][3][2] =
  -  { 0, 1, 2, 3, 4, 5,
  -6, 7, 8, 9, 10, 11};
  +  { {{0, 1}, {2, 3}, {4, 5}},
  +{{6, 7}, {8, 9}, {10, 11}}};

Successfully bootstrapped®rtested on x86_64-pc-linux-gnu; adds
29 PASS results to gcc.sum.

OK for trunk?

gcc/c/ChangeLog:
* c-parser.c (c_parser_declaration_or_fndef): Create a
rich_location at init_loc and parse it to start_init.
(last_init_list_comma): New global.
(c_parser_braced_init): Update last_init_list_comma when parsing
commas.  Pass it to pop_init_level.  Pass location of closing
brace to pop_init_level.
(c_parser_postfix_expression_after_paren_type): Create a
rich_location at type_loc and parse it to start_init.
(c_parser_omp_declare_reduction): Likewise for loc.
* c-tree.h (start_init): Add rich_location * param.
(pop_init_level): Add location_t param.
* c-typeck.c (struct initializer_stack): Add field
"missing_brace_richloc".
(start_init): Add richloc param, use it to initialize
the stack node's missing_brace_richloc.
(last_init_list_comma): New decl.
(finish_implicit_inits): Pass last_init_list_comma to
pop_init_level.
(push_init_level): When finding missing open braces, add fix-it
hints to the richloc.
(pop_init_level): Add "insert_before" param and pass it
when calling pop_init_level.  Add fixits about missing
close braces to any richloc.  Use the richloc for the
-Wmissing-braces warning.
(set_designator): Pass last_init_list_comma to pop_init_level.
(process_init_element): Likewise.

gcc/testsuite/ChangeLog:
* gcc.dg/Wmissing-braces-fixits.c: New test case.

I'm a bit unsure about how useful this is in practice.  But OK.

jeff

Re: [PATCH PR78684]Check sign bit for index step of data reference.

[Jeff Law]

On 12/07/2016 08:10 AM, Bin Cheng wrote:

Hi,
This patch fixes ICE reported in PR78684, it checks sign bit of integer const 
thus can handle unsigned types.  Bootstrap and test on x86_64, is it OK?

Thanks,
bin

2016-12-06  Bin Cheng  

PR middle-end/78684
* tree-vect-loop-manip.c (create_intersect_range_checks_index): Check
sign bit for index step of data reference.

gcc/testsuite/ChangeLog
2016-12-06  Bin Cheng  

PR middle-end/78684
* g++.dg/torture/pr78684.C: New test.


OK.
jeff

C++ PATCH to reject initializating flexible array members in constructors (PR c++/72775)

[Marek Polacek]

We were crashing in finish_expr_stmt here:
 676   /* If we ran into a problem, make sure we complained.  */
 677   gcc_assert (expr != error_mark_node || seen_error ());
Well, we ran into a problem, but never raised an error.  The problem was that
we couldn't determine the max index of the array when default-initizalizing the
members (at the beginning of cp_parser_ctor_initializer_opt).  Jason's
preference seems to be to disable initialization of a flexible array member in
a constructor and that is what this patch attempts to do.

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

2016-12-07  Marek Polacek  

PR c++/72775
* init.c (perform_member_init): Diagnose initialization of a flexible
array member in a constructor.

* g++.dg/ext/flexary20.C: New.

diff --git gcc/cp/init.c gcc/cp/init.c
index b4b6cdb..01009c9 100644
--- gcc/cp/init.c
+++ gcc/cp/init.c
@@ -800,6 +800,10 @@ perform_member_init (tree member, tree init)
   in that case.  */
init = build_x_compound_expr_from_list (init, ELK_MEM_INIT,
tf_warning_or_error);
+  else if (TREE_CODE (type) == ARRAY_TYPE
+  && TYPE_DOMAIN (type) == NULL_TREE)
+   error_at (DECL_SOURCE_LOCATION (member),
+ "initialization of a flexible array member in a constructor");
 
   if (init)
finish_expr_stmt (cp_build_modify_expr (input_location, decl,
diff --git gcc/testsuite/g++.dg/ext/flexary20.C 
gcc/testsuite/g++.dg/ext/flexary20.C
index e69de29..ff97b06 100644
--- gcc/testsuite/g++.dg/ext/flexary20.C
+++ gcc/testsuite/g++.dg/ext/flexary20.C
@@ -0,0 +1,49 @@
+// PR c++/72775
+// { dg-do compile { target c++11 } }
+// { dg-options -Wno-pedantic }
+
+struct S {
+  int i;
+  char a[] = "foo"; // { dg-error "initialization of a flexible array member 
in a constructor" }
+  S () {}
+};
+
+struct T {
+  int i;
+  char a[] = "foo"; // { dg-error "initialization of a flexible array member 
in a constructor" }
+};
+
+struct U {
+  int i;
+  char a[] = "foo"; // { dg-error "initialization of a flexible array member 
in a constructor" }
+  U ();
+};
+
+U::U() {}
+
+int
+main ()
+{
+  struct T t;
+}
+
+struct V {
+  int i;
+  struct W {
+int j;
+char a[] = "foo"; // { dg-error "initialization of a flexible array member 
in a constructor" }
+  } w;
+  V () {}
+};
+
+template 
+struct X {
+  int i;
+  T a[] = "foo"; // { dg-error "initialization of a flexible array member in a 
constructor" }
+};
+
+void
+fn ()
+{
+  struct X x;
+}

Marek

[PATCH] fix c++/78551 ICE in constexpr

[Nathan Sidwell]

This patch fixes 78551.  The union was a red herring.  The underlying 
problem is that we first initialize a char array with a string constant, 
and then zap a random element of that array.  That zapping expects to 
see a CONSTRUCTOR, not a STRING_CST.  Fixed by expanding the STRING_CST 
into a CONSTRUCTOR for each element, when we encounter this situation.


Patch tested on HEAD and gcc-6 branch.  Is gcc-5 still live (testcase is 
marked as a  5/6/7 regression)?


nathan
--
Nathan Sidwell
2016-12-07  Nathan Sidwell  

	PR c++/78551
	* constexpr.c (extract_string_elt): New.  Broken out of ...
	(cxx_eval_array_reference): ... here.  Call it.
	(cxx_eval_store_expression): Convert init by STRING_CST into
	CONSTRUCTOR, if needed.

	PR c++/78551
	* g++.dg/cpp1y/pr78551.C: New.

Index: cp/constexpr.c
===
--- cp/constexpr.c	(revision 243344)
+++ cp/constexpr.c	(working copy)
@@ -2149,6 +2149,27 @@ diag_array_subscript (const constexpr_ct
 }
 }
 
+/* Extract element INDEX consisting of CHARS_PER_ELT chars from
+   STRING_CST STRING.  */
+
+static tree
+extract_string_elt (tree string, unsigned chars_per_elt, unsigned index)
+{
+  tree type = cv_unqualified (TREE_TYPE (TREE_TYPE (string)));
+  tree r;
+
+  if (chars_per_elt == 1)
+r = build_int_cst (type, TREE_STRING_POINTER (string)[index]);
+  else
+{
+  const unsigned char *ptr
+	= ((const unsigned char *)TREE_STRING_POINTER (string)
+	   + index * chars_per_elt);
+  r = native_interpret_expr (type, ptr, chars_per_elt);
+}
+  return r;
+}
+
 /* Subroutine of cxx_eval_constant_expression.
Attempt to reduce a reference to an array slot.  */
 
@@ -2244,16 +2265,9 @@ cxx_eval_array_reference (const constexp
 	r = (*CONSTRUCTOR_ELTS (ary))[i].value;
   else if (TREE_CODE (ary) == VECTOR_CST)
 	r = VECTOR_CST_ELT (ary, i);
-  else if (elem_nchars == 1)
-	r = build_int_cst (cv_unqualified (TREE_TYPE (TREE_TYPE (ary))),
-			   TREE_STRING_POINTER (ary)[i]);
   else
-	{
-	  tree type = cv_unqualified (TREE_TYPE (TREE_TYPE (ary)));
-	  r = native_interpret_expr (type, (const unsigned char *)
- TREE_STRING_POINTER (ary)
- + i * elem_nchars, elem_nchars);
-	}
+	r = extract_string_elt (ary, elem_nchars, i);
+
   if (r)
 	/* Don't VERIFY_CONSTANT here.  */
 	return r;
@@ -3326,6 +3340,35 @@ cxx_eval_store_expression (const constex
 	  *valp = build_constructor (type, NULL);
 	  CONSTRUCTOR_NO_IMPLICIT_ZERO (*valp) = no_zero_init;
 	}
+  else if (TREE_CODE (*valp) == STRING_CST)
+	{
+	  /* An array was initialized with a string constant, and now
+	 we're writing into one of its elements.  Explode the
+	 single initialization into a set of element
+	 initializations.  */
+	  gcc_assert (TREE_CODE (type) == ARRAY_TYPE);
+
+	  tree string = *valp;
+	  tree elt_type = TREE_TYPE (type);
+	  unsigned chars_per_elt = (TYPE_PRECISION (elt_type)
+/ TYPE_PRECISION (char_type_node));
+	  unsigned num_elts = TREE_STRING_LENGTH (string) / chars_per_elt;
+	  tree ary_ctor = build_constructor (type, NULL);
+
+	  vec_safe_reserve (CONSTRUCTOR_ELTS (ary_ctor), num_elts);
+	  for (unsigned ix = 0; ix != num_elts; ix++)
+	{
+	  constructor_elt elt = 
+		{
+		  build_int_cst (size_type_node, ix),
+		  extract_string_elt (string, chars_per_elt, ix)
+		};
+	  CONSTRUCTOR_ELTS (ary_ctor)->quick_push (elt);
+	}
+	  
+	  *valp = ary_ctor;
+	}
+
   /* If the value of object is already zero-initialized, any new ctors for
 	 subobjects will also be zero-initialized.  */
   no_zero_init = CONSTRUCTOR_NO_IMPLICIT_ZERO (*valp);
Index: testsuite/g++.dg/cpp1y/pr78551.C
===
--- testsuite/g++.dg/cpp1y/pr78551.C	(nonexistent)
+++ testsuite/g++.dg/cpp1y/pr78551.C	(working copy)
@@ -0,0 +1,32 @@
+// { dg-do compile { target c++14 } }
+
+// PR c++/78551 ICE in constexpr evaluation overwriting array
+// intialized by string constant.
+
+constexpr char Foo (char x, int ix)
+{
+  char d[4] = "012";
+  d[0] = x;
+  return d[ix];
+}
+
+static const char a = Foo ('a', 1);
+static const char b = Foo ('a', 0);
+
+static_assert (a == '1', "");
+static_assert (b == 'a', "");
+
+struct A {
+  union {
+long s;
+char d[4];
+  };
+  constexpr A (char x)
+: d("012")
+  { d[0] = x; }
+};
+
+static constexpr A c{'a'};
+
+static_assert (c.d[0] == 'a', "");
+static_assert (c.d[1] == '1', "");

Re: [PATCH] Fix ICE due to IPA-VRP (PR tree-optimization/78681)

[Jeff Law]

On 12/05/2016 02:14 PM, Jakub Jelinek wrote:

Hi!

As shown on the testcase, with K&R definitions and fn prototypes with
promoted types, we can end up computing caller's value ranges in wider
type than the parameter actually has in the function.
The problem with that is that wide_int_storage::from can actually wrap
around, so either as in the testcase we end up with invalid range (minimum
larger than maximum), or just with a range that doesn't cover all the values
the parameter can have.
The patch punts if the range bounds cast to type aren't equal to the
original values.  Similarly (just theoretical), for pointers it only
optimizes if the caller's precision as at most as wide as the pointer,
if it would be wider, even ~[0, 0] range could actually be a NULL pointer
(some multiple of ~(uintptr_t)0 + (uintmax_t) 1).

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

2016-12-05  Jakub Jelinek  

PR tree-optimization/78681
* ipa-prop.c (ipcp_update_vr): Punt if vr[i].min precision is bigger
then type's precision and vr[i].min or vr[i].max in type would wrap.

* gcc.c-torture/compile/pr78681.c: New test.
OK.  If the work on the thread for 78365 produces fruit we can always go 
back and make this less pessimistic.


jeff

Re: [tree-tailcall] Check if function returns it's argument

[Jeff Law]

On 12/06/2016 03:16 AM, Richard Biener wrote:

On Tue, 6 Dec 2016, Richard Biener wrote:


On Mon, 5 Dec 2016, Jeff Law wrote:


On 12/02/2016 01:33 AM, Richard Biener wrote:

The LHS on the assignment makes it easier to identify when a tail call is
possible.  It's not needed for correctness.  Not having the LHS on the
assignment just means we won't get an optimized tail call.

Under what circumstances would the LHS possibly be removed?  We know the
return statement references the LHS, so it's not going to be something
that
DCE will do.


Well, I thought Prathamesh added the optimization to copy-propagate
the lhs from the returned argument.  So we'd have both transforms here.

That seems like a mistake -- the fact that we can copy propagate the LHS from
the returned argument is interesting, but in practice I've found it to not be
useful to do so.

The problem is it makes the value look live across a the call and we're then
dependent upon the register allocator to know the trick about the returned
argument value and apply it consistently -- which it does not last I checked.

I think we're better off leaving the call in the form of LHS = call () if the
return value is used.  That's going to be more palatable to tail calling.


Yes, that's something I also raised earlier in the thread.  Note that
any kind of value-numbering probably wants to know the equivalence
for simplifications but in the end wants to disable propagating the
copy (in fact it should propagate the return value from the point of
the call).  I suppose I know how to implement that in FRE/PRE given it has
separate value-numbering and elimination phases.  Something for GCC 8.


The following does that (it shows we don't handle separating LHS
and overall stmt effect very well).  It optimizes a testcase like

void *foo (void *p, int c, __SIZE_TYPE__ n)
{
  void *q = __builtin_memset (p, c, n);
  if (q == p)
return p;
  return q;
}

to

foo (void * p, int c, long unsigned int n)
{
  void * q;

   [0.0%]:
  q_7 = __builtin_memset (p_3(D), c_4(D), n_5(D));
  return q_7;

in early FRE.
Yea.  Not sure how often something like that would happen in practice, 
but using the equivalence to simplify rather than for propagation seems 
like the way to go.


I keep thinking about doing some similar in DOM, but haven't gotten 
around to seeing what the fallout would be.


jeff

Re: [LRA] Fix ICE on pathological testcase

[Jeff Law]

On 12/06/2016 05:28 AM, Eric Botcazou wrote:

Hi,

the compiler ICEs for SPARC 64-bit with LRA on the asm-subreg-1.c test:

volatile unsigned short _const_32 [4] = {1,2,3,4};
void
evas_common_convert_yuv_420p_601_rgba()
{
  __asm__ __volatile__ ("" : : "X" (*_const_32));
}

The issue is that combine merges back the 3 instructions necessary to build
the address of _const_32 into a big MEM expression:

(insn 10 9 0 2 (asm_operands/v ("") ("") 0 [
(mem/v/c:HI (lo_sum:DI (mult:DI (lo_sum:DI (high:DI (unspec:DI [
(symbol_ref:DI ("_const_32") [flags
0x2]  )
] UNSPEC_SETH44))
(unspec:DI [
(symbol_ref:DI ("_const_32") [flags 0x2]
)
] UNSPEC_SETM44))
(const_int 4096 [0x1000]))
(symbol_ref:DI ("_const_32") [flags 0x2]  )) [1 _const_32+0 S2 A16])
]
 [
(asm_input:HI ("X") asm-subreg-1.c:13)
]
 [] asm-subreg-1.c:13) "asm-subreg-1.c":13 -1
 (nil))

and LRA calls decompose_mem_address on the address, which aborts out of
confusion; reload (and all subsequent passes) lets it go through unmodified.

The attached patch simply adds a bypass to process_address_1 in order to avoid
invoking decompose_mem_address in this case.

Tested on SPARC/Solaris with LRA and x86-64/Linux, OK for the mainline?


2016-12-06  Eric Botcazou  

* lra-constraints.c (process_address_1): Do not attempt to decompose
addresses for MEMs that satisfy fixed-form constraints.
Presumably the MEM isn't a valid memory address, but it's allowed 
through due to the use of an "X" constraint?


ISTM that LRA has to be prepared to handle an arbitrary RTX, so punting 
seems appropriate.


jeff

Re: [PATCH] Fix ICE due to IPA-VRP (PR tree-optimization/78681)

[Jakub Jelinek]

On Wed, Dec 07, 2016 at 02:18:15PM -0700, Jeff Law wrote:
> On 12/05/2016 02:14 PM, Jakub Jelinek wrote:
> >Hi!
> >
> >As shown on the testcase, with K&R definitions and fn prototypes with
> >promoted types, we can end up computing caller's value ranges in wider
> >type than the parameter actually has in the function.
> >The problem with that is that wide_int_storage::from can actually wrap
> >around, so either as in the testcase we end up with invalid range (minimum
> >larger than maximum), or just with a range that doesn't cover all the values
> >the parameter can have.
> >The patch punts if the range bounds cast to type aren't equal to the
> >original values.  Similarly (just theoretical), for pointers it only
> >optimizes if the caller's precision as at most as wide as the pointer,
> >if it would be wider, even ~[0, 0] range could actually be a NULL pointer
> >(some multiple of ~(uintptr_t)0 + (uintmax_t) 1).
> >
> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> >2016-12-05  Jakub Jelinek  
> >
> > PR tree-optimization/78681
> > * ipa-prop.c (ipcp_update_vr): Punt if vr[i].min precision is bigger
> > then type's precision and vr[i].min or vr[i].max in type would wrap.
> >
> > * gcc.c-torture/compile/pr78681.c: New test.
> OK.  If the work on the thread for 78365 produces fruit we can always go
> back and make this less pessimistic.

Richard actually prefers the other patch (still pending review).

Jakub

Re: [PATCH] Fix ICE due to IPA-VRP (PR tree-optimization/78681)

[Jeff Law]

On 12/07/2016 02:24 PM, Jakub Jelinek wrote:

On Wed, Dec 07, 2016 at 02:18:15PM -0700, Jeff Law wrote:

On 12/05/2016 02:14 PM, Jakub Jelinek wrote:

Hi!

As shown on the testcase, with K&R definitions and fn prototypes with
promoted types, we can end up computing caller's value ranges in wider
type than the parameter actually has in the function.
The problem with that is that wide_int_storage::from can actually wrap
around, so either as in the testcase we end up with invalid range (minimum
larger than maximum), or just with a range that doesn't cover all the values
the parameter can have.
The patch punts if the range bounds cast to type aren't equal to the
original values.  Similarly (just theoretical), for pointers it only
optimizes if the caller's precision as at most as wide as the pointer,
if it would be wider, even ~[0, 0] range could actually be a NULL pointer
(some multiple of ~(uintptr_t)0 + (uintmax_t) 1).

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

2016-12-05  Jakub Jelinek  

PR tree-optimization/78681
* ipa-prop.c (ipcp_update_vr): Punt if vr[i].min precision is bigger
then type's precision and vr[i].min or vr[i].max in type would wrap.

* gcc.c-torture/compile/pr78681.c: New test.

OK.  If the work on the thread for 78365 produces fruit we can always go
back and make this less pessimistic.


Richard actually prefers the other patch (still pending review).
Then let's wait for Richard to chime in on the other patch.  I'm not 
real familiar with this code, but I could easy convince myself your 
change could do no harm.  I'm much less comfortable evaluating the other 
approach.


jeff

Re: [PATCH] Fix up ICEs with TREE_CONSTANT references (PR c++/78373)

[Jeff Law]

On 11/16/2016 02:00 PM, Jakub Jelinek wrote:

Hi!

Jason's recent patch to turn reference vars initialized with invariant
addresses broke the first testcase below, because &self->singleton
is considered TREE_CONSTANT (because self is TREE_CONSTANT VAR_DECL and
singleton field has constant offset), but after going into SSA form
it is not supposed to be TREE_CONSTANT anymore (&self_2->singleton),
because SSA_NAMEs don't have TREE_CONSTANT set on them.

The following patch fixes it by gimplifying such vars into their
DECL_INITIAL unless in OpenMP regions, where such folding is deferred
until omplower pass finishes.

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

2016-11-16  Jakub Jelinek  

PR c++/78373
* gimplify.c (gimplify_decl_expr): For TREE_CONSTANT reference
vars with is_gimple_min_invariant initializer after stripping
useless conversions keep non-NULL DECL_INITIAL.
(gimplify_var_or_parm_decl): Add fallback argument.  Gimplify
TREE_CONSTANT reference vars with is_gimple_min_invariant initializer
outside of OpenMP contexts to the initializer if fb_rvalue is
allowed.
(gimplify_compound_lval, gimplify_expr): Pass through fallback
argument to gimplify_var_or_parm_decl.
* omp-low.c (lower_omp_regimplify_p): Return non-zero for
TREE_CONSTANT reference vars with is_gimple_min_invariant
initializer.

* g++.dg/opt/pr78373.C: New test.
* g++.dg/gomp/pr78373.C: New test.

Is this still relevant?

jeff

Re: [PATCH] Fix up ICEs with TREE_CONSTANT references (PR c++/78373)

[Jakub Jelinek]

On Wed, Dec 07, 2016 at 02:42:12PM -0700, Jeff Law wrote:
> >2016-11-16  Jakub Jelinek  
> >
> > PR c++/78373
> > * gimplify.c (gimplify_decl_expr): For TREE_CONSTANT reference
> > vars with is_gimple_min_invariant initializer after stripping
> > useless conversions keep non-NULL DECL_INITIAL.
> > (gimplify_var_or_parm_decl): Add fallback argument.  Gimplify
> > TREE_CONSTANT reference vars with is_gimple_min_invariant initializer
> > outside of OpenMP contexts to the initializer if fb_rvalue is
> > allowed.
> > (gimplify_compound_lval, gimplify_expr): Pass through fallback
> > argument to gimplify_var_or_parm_decl.
> > * omp-low.c (lower_omp_regimplify_p): Return non-zero for
> > TREE_CONSTANT reference vars with is_gimple_min_invariant
> > initializer.
> >
> > * g++.dg/opt/pr78373.C: New test.
> > * g++.dg/gomp/pr78373.C: New test.
> Is this still relevant?

No, Jason has committed a simpler change, see the PR.

Jakub

Re: [Patch, fortran] PR44265 - Link error with reference to parameter array in specification expression

[Paul Richard Thomas]

Dear Dominique,

Thanks for the feedback. However, I don't know what to do about it.
Perhaps I should commit the patch without char_result_[16,17].f90 and
pass it on to somebody who is a bit more conversent with these issues?
As far as I am concerned, it is fixed on Linux.

Any ideas anybody?

Paul

On 7 December 2016 at 20:11, Dominique d'Humières  wrote:
> The tests gfortran.dg/char_result_16.f90 and gfortran.dg/char_result_17.f90 
> fail with
>
> lto1: error: two or more sections for 
> .gnu.lto___get_PROC_names.3e3ee55b08747e7c
> lto1: internal compiler error: cannot read LTO decls from 
> /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccEJosbA.o
>
> This may be darwin specific as the linker is more picky than the linux one.
>
> Dominique
>
>> Le 7 déc. 2016 à 16:47, Paul Richard Thomas  
>> a écrit :
>>
>> Dear Dominique,
>>
>> I will turn to the effect on PR77414 after committing the patch for PR44265.
>>
>> The attached fixes the -flto problem. The chunk in
>> trans-decl.c(gfc_finish_var_decl) did the job. It is quite obvious now
>> and, in fact, I am a bit surprised that the patch worked at all
>> without the DECL_EXTERNAL.
>>
>> Bootstraps and regtests on FC21/x86_64 - OK for trunk?
>>
>> Paul
>>
>> 2016-12-07  Paul Thomas  
>>
>>PR fortran/44265
>>* gfortran.h : Add fn_result_spec bitfield to gfc_symbol.
>>* resolve.c (flag_fn_result_spec): New function.
>>(resolve_fntype): Call it for character result lengths.
>>* symbol.c (gfc_new_symbol): Set fn_result_spec to zero.
>>* trans-decl.c (gfc_sym_mangled_identifier): Include the
>>procedure name in the mangled name for symbols with the
>>fn_result_spec bit set.
>>(gfc_finish_var_decl): Mark the decls of these symbols
>>appropriately for the case where the function is external.
>>(gfc_get_symbol_decl): Mangle the name of these symbols.
>>(gfc_create_module_variable): Allow them through the assert.
>>(gfc_generate_function_code): Remove the assert before the
>>initialization of sym->tlink because the frontend no longer
>>uses this field.
>>* trans-expr.c (gfc_map_intrinsic_function): Add a case to
>>treat the LEN_TRIM intrinsic.
>>
>> 2016-12-07  Paul Thomas  
>>
>>PR fortran/44265
>>* gfortran.dg/char_result_14.f90: New test.
>>* gfortran.dg/char_result_15.f90: New test.
>>* gfortran.dg/char_result_16.f90: New test.
>>* gfortran.dg/char_result_17.f90: New test.
>>
>>
>



-- 
If you're walking down the right path and you're willing to keep
walking, eventually you'll make progress.

Barack Obama

Re: [Patch, fortran] PR44265 - Link error with reference to parameter array in specification expression

[Andre Vehreschild]

Hi Paul,

When you can narrow it down to only failing on Darwin, then filter the 
testcases not to run on that system.

- Andre

Am 7. Dezember 2016 22:44:15 MEZ, schrieb Paul Richard Thomas 
:
>Dear Dominique,
>
>Thanks for the feedback. However, I don't know what to do about it.
>Perhaps I should commit the patch without char_result_[16,17].f90 and
>pass it on to somebody who is a bit more conversent with these issues?
>As far as I am concerned, it is fixed on Linux.
>
>Any ideas anybody?
>
>Paul
>
>On 7 December 2016 at 20:11, Dominique d'Humières 
>wrote:
>> The tests gfortran.dg/char_result_16.f90 and
>gfortran.dg/char_result_17.f90 fail with
>>
>> lto1: error: two or more sections for
>.gnu.lto___get_PROC_names.3e3ee55b08747e7c
>> lto1: internal compiler error: cannot read LTO decls from
>/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccEJosbA.o
>>
>> This may be darwin specific as the linker is more picky than the
>linux one.
>>
>> Dominique
>>
>>> Le 7 déc. 2016 à 16:47, Paul Richard Thomas
> a écrit :
>>>
>>> Dear Dominique,
>>>
>>> I will turn to the effect on PR77414 after committing the patch for
>PR44265.
>>>
>>> The attached fixes the -flto problem. The chunk in
>>> trans-decl.c(gfc_finish_var_decl) did the job. It is quite obvious
>now
>>> and, in fact, I am a bit surprised that the patch worked at all
>>> without the DECL_EXTERNAL.
>>>
>>> Bootstraps and regtests on FC21/x86_64 - OK for trunk?
>>>
>>> Paul
>>>
>>> 2016-12-07  Paul Thomas  
>>>
>>>PR fortran/44265
>>>* gfortran.h : Add fn_result_spec bitfield to gfc_symbol.
>>>* resolve.c (flag_fn_result_spec): New function.
>>>(resolve_fntype): Call it for character result lengths.
>>>* symbol.c (gfc_new_symbol): Set fn_result_spec to zero.
>>>* trans-decl.c (gfc_sym_mangled_identifier): Include the
>>>procedure name in the mangled name for symbols with the
>>>fn_result_spec bit set.
>>>(gfc_finish_var_decl): Mark the decls of these symbols
>>>appropriately for the case where the function is external.
>>>(gfc_get_symbol_decl): Mangle the name of these symbols.
>>>(gfc_create_module_variable): Allow them through the assert.
>>>(gfc_generate_function_code): Remove the assert before the
>>>initialization of sym->tlink because the frontend no longer
>>>uses this field.
>>>* trans-expr.c (gfc_map_intrinsic_function): Add a case to
>>>treat the LEN_TRIM intrinsic.
>>>
>>> 2016-12-07  Paul Thomas  
>>>
>>>PR fortran/44265
>>>* gfortran.dg/char_result_14.f90: New test.
>>>* gfortran.dg/char_result_15.f90: New test.
>>>* gfortran.dg/char_result_16.f90: New test.
>>>* gfortran.dg/char_result_17.f90: New test.
>>>
>>>
>>

-- 
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 241 929 10 18 * ve...@gmx.de

Re: [PATCH] Enable -fsanitize-address-use-after-scope only if -fsanitize=address is enabled

[Sandra Loosemore]

On 12/07/2016 12:30 PM, Dmitry Vyukov wrote:

On Wed, Dec 7, 2016 at 8:23 PM, Sandra Loosemore
 wrote:


You need to fix doc/invoke.texi as well to reflect this change.


Done.

Attached updated patch.


The documentation change is OK.

-Sandra

Re: Hurd port for gcc go PATCH 1-4(23)

[Svante Signell]

On Wed, 2016-12-07 at 17:25 +0100, Samuel Thibault wrote:
> Svante Signell, on Wed 07 Dec 2016 15:32:31 +0100, wrote:
> > On Wed, 2016-12-07 at 15:08 +0100, Samuel Thibault wrote:
> > > Ok, but then I'd say move the function which change to a separate file,
> > > so that the other functions are kept shared.
> > > Otherwise it'll be tedious to maintain.
> > 
> > One problem is the file go/syscall/libcall_posix-1.go, derived
> > from go/syscall/libcall_posix.go but _removing_ four function definitions:
> > mount, madvise, mlockall and munlockall.
> 
> That's not a problem: move them out to another file, and include that
> file in the non-gnu case, but do not include that file in the gnu case.
> 
> Actually it's even odd to see mount among them, it's not a standard
> posix interface.

I'm sorry but neither of you or I are in the position to request changes of
already existing file names e.g. replacing linux with glibc in:
os/pipe_linux.go
crypto/x509/root_linux.go
syscall/errstr_linux.go

Neither are we in the position to request to rename libcall_posix.go to
something else, or move the four functions definitions mount, mlocall,
munlockall, madvise, mentioned above to a separate file.

So far, nobody, upstream or debian-gcc, have made any comment on the patches
whatsoever. So what are we doing? Let's forget about porting gccgo to GNU/Hurd.

Thanks!

Re: [C++ PATCH] P0003R5 - removal of dynamic exception specification from C++17

[Jonathan Wakely]

On 07/12/16 20:00 +0100, Jakub Jelinek wrote:

Jonathan, there is one hunk in libstdc++ still needed (on top of what you've
committed today).  Is that ok with you?


Yes, sorry I missed that one. Your fix is OK, thanks.

Re: [PATCH] warn on overflow in calls to allocation functions (bugs 77531 and 78284)

[Jeff Law]

On 11/19/2016 05:55 PM, Martin Sebor wrote:



gcc-78284.diff


PR c/77531 - __attribute__((alloc_size(1,2))) could also warn on multiplication 
overflow
PR c/78284 - warn on malloc with very large arguments

gcc/c-family/ChangeLog:

PR c/77531
PR c/78284
* c.opt (-Walloc-zero, -Walloc-size-larger-than): New options.

gcc/ChangeLog:

PR c/77531
PR c/78284
* builtin-attrs.def (ATTR_ALLOC_SIZE, ATTR_RETURNS_NONNULL): New
identifier tree nodes.
(ATTR_ALLOCA_SIZE_1_NOTHROW_LEAF_LIST): New attribute list.
(ATTR_MALLOC_SIZE_1_NOTHROW_LIST): Same.
(ATTR_MALLOC_SIZE_1_NOTHROW_LEAF_LIST): Same.
(ATTR_MALLOC_SIZE_1_2_NOTHROW_LEAF_LIST): Same.
(ATTR_ALLOC_SIZE_2_NOTHROW_LEAF_LIST): Same.
* builtins.c (expand_builtin_alloca): Call
maybe_warn_alloc_args_overflow.
* builtins.def (aligned_alloc, calloc, malloc, realloc):
Add attribute alloc_size.
(alloca): Add attribute alloc_size and returns_nonnull.
* calls.h (maybe_warn_alloc_args_overflow): Declare.
* calls.c (alloc_max_size, operand_signed_p): New functions.
(maybe_warn_alloc_args_overflow): Define.
(initialize_argument_information): Diagnose overflow in functions
declared with attaribute alloc_size.
* doc/invoke.texi (Warning Options): Document -Walloc-zero and
-Walloc-size-larger-than.

gcc/testsuite/ChangeLog:

PR c/77531
PR c/78284
* gcc.dg/attr-alloc_size-3.c: New test.
* gcc.dg/attr-alloc_size-4.c: New test.
* gcc.dg/attr-alloc_size-5.c: New test.
* gcc.dg/attr-alloc_size-6.c: New test.
* gcc.dg/attr-alloc_size-7.c: New test.
* gcc.dg/attr-alloc_size-8.c: New test.
* gcc.dg/attr-alloc_size-9.c: New test.
* gcc/testsuite/gcc.dg/errno-1.c: Adjust.




diff --git a/gcc/calls.c b/gcc/calls.c
index c916e07..05e6e09 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -1181,6 +1183,310 @@ store_unaligned_arguments_into_pseudos (struct arg_data 
*args, int num_actuals)
   }
 }

+static tree alloc_object_size_limit;
Is this object live across GCC passes (I think it is)?  If so, then it 
needs a GTY marker.







+ /* G++ emits calls to ::operator new[](SIZE_MAX) in C++98
+mode and with -fno-exceptions as a way to indicate array
+size overflow.  There's no good way to detect C++98 here
+so avoid diagnosing these calls for all C++ modes.  */

How unfortunate :(



+ else if (range_type == VR_ANTI_RANGE)
+   {
+ /* For an anti-range, if the type of the formal argument
+is unsigned and the bounds of the range are of opposite
+signs when interpreted as signed, check to see if the
+type of the actual argument is signed.  If so, the lower
+bound must be taken to be zero (rather than a large
+positive value corresonding to the actual lower bound
+interpreted as unsigned) and there is nothing else that
+can be inferred from it.  */

s/corresonding/corresponding/







+@item -Walloc-zero
+@opindex Wno-alloc-zero
+@opindex Walloc-zero
+Warn about calls to allocation functions decorated with attribute
+@code{alloc_size} that specify zero bytes, including those to the built-in
+forms of the functions @code{aligned_alloc}, @code{alloca}, @code{calloc},
+@code{malloc}, and @code{realloc}.  Because the behavior of these functions
+when called with a zero size differs among implementations relying on it may
+result in subtle portability bugs and should be avoided.  This option is
+enabled with @option{-Wextra}.
So I think we should in the immediate term not enable this in Wextra. 
However, I think for gcc-8 we should revisit after fixing GCC to be 
cleaner WRT alloc-zero.


So disable alloc-zero by default, comment typo and potentially adding 
the GTY marker to alloc_object_size_limit and this is OK.


Jeff

Re: [PR78365] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

[kugan]

Hi Martin,

On 07/12/16 21:08, Martin Jambor wrote:

Hello Kugan,

sorry, I have lost track of this patch and re-discovered it only now.

On Mon, Nov 28, 2016 at 04:25:00PM +1100, kugan wrote:

Hi,

On 24/11/16 19:48, Richard Biener wrote:

On Wed, Nov 23, 2016 at 4:33 PM, Martin Jambor  wrote:

Hi,

On Fri, Nov 18, 2016 at 12:38:18PM +1100, kugan wrote:

Hi,

I was relying on ipa_get_callee_param_type to get type of parameter and then
convert arguments to this type while computing jump functions. However, in
cases like shown in PR78365, ipa_get_callee_param_type, instead of giving
up, would return the wrong type.


At what stage does this happen?  During analysis
(ipa_compute_jump_functions_for_edge) or at WPA
(propagate_constants_accross_call)?  Both?


Hmm, where does jump function compute require the callee type?
In my view the jump function should record

 (expected-incoming-type) arg [OP X]

for each call argument in its body.  Thus required conversions are
done at WPA propagation time.


I think the current uses of
ipa_get_callee_param_type are fine with this.

Attached patch now uses callee's DECL_ARGUMENTS to get the type. If it
cannot be found, then I would give up and set the jump function to varying.


But DECL_ARGUMENTS is not available at WPA stage with LTO so your
patch would make our IPA layer to optimize less with LTO.  This was
the reason to go through the hoops of TYPE_ARG_TYPES in the first
place.

If TYPE_ARG_TYPES cannot be trusted, then I'm afraid we are back to
square one and indeed need to put the correct type in jump functions.


If DECL_ARGUMENTS is not available at WPA stage then I see no other
way than to put the types on the jump functions.


Here is a patch that does this. To fox PR78365, in
ipa_get_callee_param_type, I am now checking DECL_ARGUMENTS first. I lto
bootstrapped and regression tested on x86_64-linux-gnu and ppc64le-linux
with no new regressions. I will build Firefox and measure the memory usage
as Honza suggested based on the feedback.



So, do you have any numbers?
I am starting this now. Do we have an easiest and accurate way to 
measure memory usage by gcc for Firefox compilation. Honza's LTO blog 
talks about using vmstat.



Thanks,
Kugan




diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 2ec671f..3d50041 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1846,11 +1846,11 @@ propagate_bits_accross_jump_function (cgraph_edge *cs, 
int idx, ipa_jump_func *j
 static bool
 propagate_vr_accross_jump_function (cgraph_edge *cs,
ipa_jump_func *jfunc,
-   struct ipcp_param_lattices *dest_plats,
-   tree param_type)
+   struct ipcp_param_lattices *dest_plats)
 {
   struct ipcp_param_lattices *src_lats;
   ipcp_vr_lattice *dest_lat = &dest_plats->m_value_range;
+  tree param_type = jfunc->param_type;

   if (dest_lat->bottom_p ())
 return false;
@@ -1895,9 +1895,9 @@ propagate_vr_accross_jump_function (cgraph_edge *cs,
   tree val = ipa_get_jf_constant (jfunc);
   if (TREE_CODE (val) == INTEGER_CST)
{
+ val = fold_convert (param_type, val);
  if (TREE_OVERFLOW_P (val))
val = drop_tree_overflow (val);
- val = fold_convert (param_type, val);
  jfunc->vr_known = true;
  jfunc->m_vr.type = VR_RANGE;
  jfunc->m_vr.min = val;
@@ -2247,7 +2247,6 @@ propagate_constants_accross_call (struct cgraph_edge *cs)
 {
   struct ipa_jump_func *jump_func = ipa_get_ith_jump_func (args, i);
   struct ipcp_param_lattices *dest_plats;
-  tree param_type = ipa_get_callee_param_type (cs, i);

   dest_plats = ipa_get_parm_lattices (callee_info, i);
   if (availability == AVAIL_INTERPOSABLE)
@@ -2264,8 +2263,7 @@ propagate_constants_accross_call (struct cgraph_edge *cs)
   dest_plats);
  if (opt_for_fn (callee->decl, flag_ipa_vrp))
ret |= propagate_vr_accross_jump_function (cs,
-  jump_func, dest_plats,
-  param_type);
+  jump_func, dest_plats);
  else
ret |= dest_plats->m_value_range.set_to_bottom ();
}
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 90c19fc..235531b 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -1651,14 +1651,24 @@ determine_locally_known_aggregate_parts (gcall *call, 
tree arg,
 /* Return the Ith param type of callee associated with call graph
edge E.  */

-tree
+static tree
 ipa_get_callee_param_type (struct cgraph_edge *e, int i)
 {
   int n;
+  tree t = e->callee ? DECL_ARGUMENTS (e->callee->decl) : NULL_TREE;
+  if (t)
+for (n = 0; n < i; n++)
+  {
+   if (!t)
+ return NULL;
+   t = TREE_CHAIN (t);
+  }
+  if (t)
+return TREE_TYPE (t);
   tree 

New Spanish PO file for 'gcc' (version 6.2.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators.  The file is available at:

http://translationproject.org/latest/gcc/es.po

(This file, 'gcc-6.2.0.es.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [LRA] Fix ICE on pathological testcase

[Eric Botcazou]

> Presumably the MEM isn't a valid memory address, but it's allowed
> through due to the use of an "X" constraint?

Yes (that was supposed to be more or less clear given the description :-).

> ISTM that LRA has to be prepared to handle an arbitrary RTX, so punting
> seems appropriate.

My opinion too.  Note that Bernd E. has another solution though.

-- 
Eric Botcazou

Re: Hurd port for gcc go PATCH 1-4(23)

[Ian Lance Taylor]

On Wed, Dec 7, 2016 at 2:02 PM, Svante Signell  wrote:
>
> I'm sorry but neither of you or I are in the position to request changes of
> already existing file names e.g. replacing linux with glibc in:
> os/pipe_linux.go
> crypto/x509/root_linux.go
> syscall/errstr_linux.go

As you know, the name "linux" in those files means that the files are
only compiled on GNU/Linux systems.  The files in os and crypto are
copied from the master library in the gc repository.  Those names are
not going to change.  The file syscall/errstr_linux.go is specific to
gccgo, and that name could change easily enough.

> Neither are we in the position to request to rename libcall_posix.go to
> something else, or move the four functions definitions mount, mlocall,
> munlockall, madvise, mentioned above to a separate file.

Making those changes is fine.

> So far, nobody, upstream or debian-gcc, have made any comment on the patches
> whatsoever. So what are we doing? Let's forget about porting gccgo to 
> GNU/Hurd.

Yes, I'm sorry that this never gets high enough on my list for a serious review.

The best way to contribute to gccgo is to use the process described at
https://golang.org/doc/gccgo_contribute.html.  That explains how to
send changes to Gerrit in a way that is easy for me to review and
apply (Gerrit is itself free software).  You are much more likely to
get a response if you are able to follow that approach.

Ian

Re: [PING] [PATCH] enhance buffer overflow warnings (and c/53562)

[Martin Sebor]

+  /* An anti-range implies the original variable is signed and
+ its lower bound is negative and the upper bound positive.
+ Since that means that the expression's value could be zero
+ nothing interesting can be inferred from this.  */

I'm not sure I agree with this comment.  For example, we often get an
anti-range like ~[0,0].

I don't mind punting anti-ranges, but I think the comments needs
updating unless there's something else in this code that ensures that an
anti range reaching this point fits the property above.


I'm not sure it's 100% correct either so I replaced the comment
with a FIXME as reminder to revisit it.  It is what I saw while
debugging this code.  For example, in this:

  char d[3];

  void f (int n)
  {
if (n < -7 || 4 < n)
  n = -7;

__builtin_memset (d, 0, n);
  }

VRP reports this:

  n_4: [-7, 4]  EQUIVALENCES: { n_5(D) } (1 elements)
  ...
  prephitmp_9: ~[5, 18446744073709551608]
  ...
  # prephitmp_9 = PHI <_8(3), 18446744073709551609(2)>
  __builtin_memset (&d, 0, prephitmp_9);



With the comment fixes noted above, this is OK.


Thanks.  I've made the changes above.  While retesting the patch
I noticed a couple of Fortran test failures that I must have missed
the first time around.  I fixed those and wound up committing r243419.

Martin

Re: [libgo] Remove unused declarations in runtime.h

[Ian Lance Taylor]

On Wed, Oct 19, 2016 at 3:38 PM, Eric Botcazou  wrote:
>
> linking any Go program on SPARC/Solaris with the GNU assembler and the Sun
> linker yields a warning:
>
> ld: warning: relocation error: R_SPARC_UA32: file
> /sydney.a/users/botcazou/gcc-head/sparc-sun-
> solaris2.10/./libgo/libgobegin.a(libgobegin_a-go-main.o): symbol
> runtime_startup_random_data: external symbolic relocation against non-
> allocatable section .debug_info; cannot be processed at runtime: relocation
> ignored
>
> It's because (almost) every C file in runtime/ includes runtime.h, which has
> these lines:
>
> byte*  runtime_startup_random_data;
> uint32 runtime_startup_random_data_len;
> void   runtime_get_random_data(byte**, int32*);
>
> which cause (almost) every object file to have the first 2 as common symbols
> and this runs afoul of some limitation of the Sun linker.  Now there seem to
> be no other references to these 3 objects in the libgo directory and removing
> them doesn't seem to change the behavior of the Go compiler so the attached
> patch does just that.
>
> Tested on x86_64-suse-linux and SPARC/Solaris, OK for mainline?
>
>
> 2016-10-19  Eric Botcazou  
>
> * runtime/runtime.h (runtime_startup_random_data): Delete.
> (runtime_startup_random_data_len): Likewise.
> (runtime_get_random_data): Likewise.

Sorry, I missed this.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 243321)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-2102112e26a21589455f940ec6b409766d942c62
+08d221726e3f50cb197a931ba385fac67f66a028
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/runtime/runtime.h
===
--- libgo/runtime/runtime.h (revision 243084)
+++ libgo/runtime/runtime.h (working copy)
@@ -212,10 +212,6 @@ extern bool runtime_copystack;
 #define USED(v)((void) v)
 #defineROUND(x, n) (((x)+(n)-1)&~(uintptr)((n)-1)) /* all-caps to 
mark as macro: it evaluates n twice */
 
-byte*  runtime_startup_random_data;
-uint32 runtime_startup_random_data_len;
-void   runtime_get_random_data(byte**, int32*);
-
 enum {
// hashinit wants this many random bytes
HashRandomBytes = 32

[PATCH] PR fortran/65173 -- kill off old_cl_list from gfc_namespace.

[Steve Kargl]

All,

The attach patch fixes an ICE from a testcase in PR fortran/65173.

First, I draw your attention to the comment in gfortran.h above
the definition of gfc_charlen.  It is

/* Character length structures hold the expression that gives the
   length of a character variable.  We avoid putting these into
   gfc_typespec because doing so prevents us from doing structure
   copies and forces us to deallocate any typespecs we create, as well
   as structures that contain typespecs.  They also can have multiple
   character typespecs pointing to them.

   These structures form a singly linked list within the current
   namespace and are deallocated with the namespace.  It is possible to
   end up with gfc_charlen structures that have nothing pointing to them.  */

The last paragraph is important, here.  So, the problematic code was 

program foo
   type t
 character, allocatable :: z1(:), z1(:)
   end type t
end program foo

gfortran rightly rejected this code and issues an appropriate error.
However, when parse.c (reject_statement) tries to cleanup the parsing
of the invalid statement, it manages to corrupt the namespace's cl_list.
How? Well, that's a good question on which I wasted too much time given 
the last paragraph in the gfortran.h comment.  Removing the manipulations
of the cl_list in reject_statement, then revealed that old_cl_list is
unneeded.  So, I give unto you

2016-12-07  Steven G. Kargl  

PR fortran/65173
* gfortran.h (gfc_namespace): Remove old_cl_list member.
* parse.c (use_modules, next_statement): old_cl_list is gone.
(clear_default_charlen): Remove no longer used function.
(reject_statement): Do not try to clean up gfc_charlen structure(s)
that may have been added to a cl_list list.
* symbol.c (gfc_new_charlen): old_cl_list structure is gone.

2016-12-07  Steven G. Kargl  

PR fortran/65173
* gfortran.dg/misplaced_implicit_character.f90: Adjust errors.
* gfortran.dg/pr65173.f90: New test.

The patch is attached and regression tested on x86_64-*-freebsd.
OK to commit?

-- 
Steve
Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h	(revision 243376)
+++ gcc/fortran/gfortran.h	(working copy)
@@ -1768,7 +1768,7 @@ typedef struct gfc_namespace
   /* !$ACC ROUTINE names.  */
   gfc_oacc_routine_name *oacc_routine_names;
 
-  gfc_charlen *cl_list, *old_cl_list;
+  gfc_charlen *cl_list;
 
   gfc_dt_list *derived_types;
 
Index: gcc/fortran/parse.c
===
--- gcc/fortran/parse.c	(revision 243376)
+++ gcc/fortran/parse.c	(working copy)
@@ -116,7 +116,6 @@ use_modules (void)
   gfc_pop_error (&old_error);
   gfc_commit_symbols ();
   gfc_warning_check ();
-  gfc_current_ns->old_cl_list = gfc_current_ns->cl_list;
   gfc_current_ns->old_equiv = gfc_current_ns->equiv;
   gfc_current_ns->old_data = gfc_current_ns->data;
   last_was_use_stmt = false;
@@ -1386,7 +1385,6 @@ next_statement (void)
 
   gfc_new_block = NULL;
 
-  gfc_current_ns->old_cl_list = gfc_current_ns->cl_list;
   gfc_current_ns->old_equiv = gfc_current_ns->equiv;
   gfc_current_ns->old_data = gfc_current_ns->data;
   for (;;)
@@ -2483,41 +2481,13 @@ accept_statement (gfc_statement st)
 }
 
 
-/* Clear default character types with charlen pointers that are about
-   to become invalid.  */
-
-static void
-clear_default_charlen (gfc_namespace *ns, const gfc_charlen *cl,
-		   const gfc_charlen *end)
-{
-  gfc_typespec *ts;
-
-  for (ts = &ns->default_type[0]; ts < &ns->default_type[GFC_LETTERS]; ts++)
-  if (ts->type == BT_CHARACTER)
-	{
-	  const gfc_charlen *cl2;
-	  for (cl2 = cl; cl2 != end; cl2 = cl2->next)
-	if (ts->u.cl == cl2)
-	  {
-		ts->u.cl = NULL;
-		ts->type = BT_UNKNOWN;
-		break;
-	  }
-	 }
-}
-
-/* Undo anything tentative that has been built for the current
-   statement.  */
+/* Undo anything tentative that has been built for the current statement,
+   except if a gfc_charlen structure has been added to current namespace's
+   list of gfc_charlen structure.  */
 
 static void
 reject_statement (void)
 {
-  /* Revert to the previous charlen chain.  */
-  clear_default_charlen (gfc_current_ns,
-			 gfc_current_ns->cl_list, gfc_current_ns->old_cl_list);
-  gfc_free_charlen (gfc_current_ns->cl_list, gfc_current_ns->old_cl_list);
-  gfc_current_ns->cl_list = gfc_current_ns->old_cl_list;
-
   gfc_free_equiv_until (gfc_current_ns->equiv, gfc_current_ns->old_equiv);
   gfc_current_ns->equiv = gfc_current_ns->old_equiv;
 
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c	(revision 243376)
+++ gcc/fortran/symbol.c	(working copy)
@@ -3794,31 +3794,22 @@ gfc_charlen*
 gfc_new_charlen (gfc_namespace *ns, gfc_charlen *old_cl)
 {
   gfc_charlen *cl;
+
   cl = gfc_get_charlen ();
 
   /* Copy old_cl.  */
   if (old_cl)
 {
-

[PATCH] Avoid double unread_char (c) in patch 8a of RTL frontend

[David Malcolm]

The RTL frontend patch kit failed to build on powerpc-ibm-aix7.1.3.0
(gcc111), with this error:

build/genmddeps ../../src/gcc/common.md ../../src/gcc/config/rs6000/rs6000.md > 
tmp-mddeps
../../src/gcc/config/rs6000/rs6000.md:2255:1: unterminated construct

due to the final close paren on line 2259 of rs6000.md:

  2259  (and:GPR (match_dup 1)

not being detected by read_skip_construct.

Bisecting the patch kit, it appears to be due to this hunk in patch 8a:

@@ -463,8 +481,12 @@ md_reader::read_name (struct md_name *name)
   c = read_char ();
 }

+  unread_char (c);
+  *out_loc = get_current_location ();
+  read_char ();
+

It appears that this can lead to unread_char (c) being called twice
for the same c, followed by a read_char () (i.e. the 2nd call to
unread_char passes the wrong character back).  Given that unread_char
is a wrapper around libc's ungetc, I *think* this is showing up a
difference between glibc and AIX's libc implementation (and possibly
a reliance on undefined behavior).

The attached tweak to patch 8a simplifies the function, eliminating
these calls, by using the start of the name for the location, rather
than the end.

It fixes the build of the kit on powerpc-ibm-aix7.1.3.0
(and continues to build correctly on x86_64-pc-linux-gnu).

gcc/ChangeLog:
* read-md.c (md_reader::read_name_1): Write out the location of
the start of the name, rather than the end, eliminating
unread_char and read_char calls.
---
 gcc/read-md.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/gcc/read-md.c b/gcc/read-md.c
index e581326..ad61cdd 100644
--- a/gcc/read-md.c
+++ b/gcc/read-md.c
@@ -461,6 +461,8 @@ md_reader::read_name_1 (struct md_name *name, file_location 
*out_loc)
 
   c = read_skip_spaces ();
 
+  *out_loc = get_current_location ();
+
   i = 0;
   angle_bracket_depth = 0;
   while (1)
@@ -491,10 +493,6 @@ md_reader::read_name_1 (struct md_name *name, 
file_location *out_loc)
   c = read_char ();
 }
 
-  unread_char (c);
-  *out_loc = get_current_location ();
-  read_char ();
-
   if (i == 0)
 return false;
 
-- 
1.8.5.3

[PATCH, rs6000] Fix 32-bit BE failure for gcc.target/powerpc/fold-vec-add-7.c

[Bill Schmidt]

Hi,

Andreas Schwab observed that the subject test case fails on 32-bit big-endian
because the test is not restricted to targets that support __int128.  This
patch rectifies that.

Tested on powerpc64-unknown-linux-gnu and verified that the test is flagged
as unsupported for BE, but runs correctly on LE.  Tested on powerpc64le-
unknown-linux-gnu and verified that the test runs correctly there.  Is this
ok for trunk?

Thanks,
Bill


2016-12-07  Bill Schmidt  

* gcc.target/powerpc/fold-vec-add-7.c: Require effective target to
support __int128.


Index: gcc/testsuite/gcc.target/powerpc/fold-vec-add-7.c
===
--- gcc/testsuite/gcc.target/powerpc/fold-vec-add-7.c   (revision 243331)
+++ gcc/testsuite/gcc.target/powerpc/fold-vec-add-7.c   (working copy)
@@ -3,6 +3,7 @@
 
 /* { dg-do compile } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-require-effective-target int128 } */
 /* { dg-options "-maltivec -mvsx -mpower8-vector" } */
 /* { dg-additional-options "-maix64" { target powerpc-ibm-aix* } } */
 

Re: [PATCH] add missing attribute nonnull to stdio functions (PR 78673 and 17308)

[Martin Sebor]

+bitmap
+get_nonnull_args (const_tree callexpr)
+{
+  tree fn = CALL_EXPR_FN (callexpr);
+  if (!fn || TREE_CODE (fn) != ADDR_EXPR)
+return NULL;
+
+  tree fndecl = TREE_OPERAND (fn, 0);
+  tree fntype = TREE_TYPE (fndecl);
+  tree attrs = TYPE_ATTRIBUTES (fntype);
+  if (!attrs)
+return NULL;
+
+  attrs = lookup_attribute ("nonnull", attrs);
+  if (!attrs)
+return NULL;
+
+  /* Return an empty but non-null bitmap as an indication that all
+ of the function's arguments must be non-null.  */
+  bitmap argmap = BITMAP_ALLOC (NULL);
+  if (!TREE_VALUE (attrs))
+return argmap;
+
+  /* Iterate over the indices of the format arguments declared nonnull
+ and set a bit for each.  */
+  for (tree idx = TREE_VALUE (attrs); idx; idx = TREE_CHAIN (idx))
+{
+  unsigned int val = TREE_INT_CST_LOW (TREE_VALUE (idx)) - 1;
+  bitmap_set_bit (argmap, val);
+}
+
+  return argmap;
+}

I'm not entirely sure you're using lookup_attribute properly here.  The
docs for that function make me believe you need to call back into
lookup_attribute with the TREE_CHAIN of the previous return value to
find the next occurrence.


You're right!  Good chatch! I missed that there are two ways to
represent the same thing.  For example, these two declarations

  void __attribute ((nonnull (1, 2)))
  f (void);

  void __attribute ((nonnull (1))) __attribute ((nonnull (2)))
  f (void);

apply to the same arguments but each is represented differently,
as is this one:

  void __attribute ((nonnull))
  f (void);

The builtins use the first form and I didn't have tests for user-
defined attributes in the second form.  I've fixed that in the
attached updated patch (and added more tests).  It does seem,
though, that it would be better to represent these declarations
canonically.  It would simplify the processing and avoid bugs.

Thanks
Martin
PR c/78673 - sprintf missing attribute nonnull on destination argument
PR c/17308 - nonnull attribute not as useful as it could be

gcc/ChangeLog:

	PR c/78673
	PR c/17308
	* builtin-attrs.def (ATTR_NONNULL_1_1, ATTR_NONNULL_1_2): Defined.
	(ATTR_NONNULL_1_3, ATTR_NONNULL_1_4, ATTR_NONNULL_1_5): Same.
	(ATTR_NOTHROW_NONNULL_1_1, ATTR_NOTHROW_NONNULL_1_2): Same.
	(ATTR_NOTHROW_NONNULL_1_3, ATTR_NOTHROW_NONNULL_1_4): Same.
	(ATTR_NOTHROW_NONNULL_1_5): Same.
	(ATTR_NONNULL_1_FORMAT_PRINTF_1_2): Same.
	(ATTR_NONNULL_1_FORMAT_PRINTF_2_0): Same.
	(ATTR_NONNULL_1_FORMAT_PRINTF_2_3): Same.
	(ATTR_NONNULL_1_FORMAT_PRINTF_3_0): Same.
	(ATTR_NONNULL_1_FORMAT_PRINTF_3_4): Same.
	(ATTR_NONNULL_1_FORMAT_PRINTF_4_0): Same.
	(ATTR_NONNULL_1_FORMAT_PRINTF_4_5): Same.
	* builtins.c (validate_arg): Add argument.  Treat null pointers
	passed to nonnull arguments as invalid.
	(validate_arglist): Same.
	* builtins.def (fprintf, fprintf_unlocked): Add nonnull attribute.
	(printf, printf_unlocked, sprintf. vfprintf, vsprintf): Same.
	(__sprintf_chk, __vsprintf_chk, __fprintf_chk, __vfprintf_chk): Same.
	* calls.c (get_nonnull_ags, maybe_warn_null_arg): New functions.
	(initialize_argument_information): Diagnose null pointers passed to
	arguments declared nonnull.
	* calls.h (get_nonnull_args): Declared.

gcc/c-family/ChangeLog:

	PR c/78673
	PR c/17308
	* c-common.c (check_nonnull_arg): Disable when optimization
	is enabled.

gcc/testsuite/ChangeLog:

	PR c/78673
	PR c/17308
	* gcc.dg/builtins-nonnull.c: New test.
	* gcc.dg/nonnull-4.c: New test.

diff --git a/gcc/builtin-attrs.def b/gcc/builtin-attrs.def
index 1520d15..c55523e 100644
--- a/gcc/builtin-attrs.def
+++ b/gcc/builtin-attrs.def
@@ -72,6 +72,9 @@ DEF_ATTR_FOR_STRING (STR1, "1")
 		  ATTR_##VALUE1, ATTR_LIST_##VALUE2)
 DEF_LIST_INT_INT (1,0)
 DEF_LIST_INT_INT (1,2)
+DEF_LIST_INT_INT (1,3)
+DEF_LIST_INT_INT (1,4)
+DEF_LIST_INT_INT (1,5)
 DEF_LIST_INT_INT (2,0)
 DEF_LIST_INT_INT (2,3)
 DEF_LIST_INT_INT (3,0)
@@ -205,6 +208,40 @@ DEF_ATTR_TREE_LIST (ATTR_NOTHROW_NONNULL_4, ATTR_NONNULL, ATTR_LIST_4, \
 /* Nothrow functions whose fifth parameter is a nonnull pointer.  */
 DEF_ATTR_TREE_LIST (ATTR_NOTHROW_NONNULL_5, ATTR_NONNULL, ATTR_LIST_5, \
 			ATTR_NOTHROW_LIST)
+
+/* Same as ATTR_NONNULL_1.  */
+DEF_ATTR_TREE_LIST (ATTR_NONNULL_1_1, ATTR_NONNULL, ATTR_LIST_1, ATTR_NULL)
+/* Functions like {v,}fprintf whose first and second parameters are
+   nonnull pointers.  As cancellation points the functions are not
+   nothrow.  */
+DEF_ATTR_TREE_LIST (ATTR_NONNULL_1_2, ATTR_NONNULL, ATTR_LIST_1_2, ATTR_NULL)
+/* The following don't have {v,}fprintf forms.  They exist only to
+   make it possible to declare {v,}{f,s}printf attributes using
+   the same macro.  */
+DEF_ATTR_TREE_LIST (ATTR_NONNULL_1_3, ATTR_NONNULL, ATTR_LIST_1_3, ATTR_NULL)
+DEF_ATTR_TREE_LIST (ATTR_NONNULL_1_4, ATTR_NONNULL, ATTR_LIST_1_4, ATTR_NULL)
+DEF_ATTR_TREE_LIST (ATTR_NONNULL_1_5, ATTR_NONNULL, ATTR_LIST_1_5, ATTR_NULL)
+
+/* Same as ATTR_NOTHROW_NONNULL_1.  */
+DEF_ATTR_TREE_LIST (ATTR_NOTHROW_NONNULL_1_1, ATTR_NONNULL, ATTR_LIST_1,
+		ATTR_NOTHROW_LIST)
+/* Nothr

Re: [PATCH] PR fortran/65173 -- kill off old_cl_list from gfc_namespace.

[Steve Kargl]

On Wed, Dec 07, 2016 at 06:14:34PM -0800, Steve Kargl wrote:
> 
> 2016-12-07  Steven G. Kargl  
> 
>   PR fortran/65173
>   * gfortran.h (gfc_namespace): Remove old_cl_list member.
>   * parse.c (use_modules, next_statement): old_cl_list is gone.
>   (clear_default_charlen): Remove no longer used function.
>   (reject_statement): Do not try to clean up gfc_charlen structure(s)
>   that may have been added to a cl_list list.
>   * symbol.c (gfc_new_charlen): old_cl_list structure is gone.
> 

Appears to fix PR fortran/78350 as well.

-- 
Steve

Re: [PATCH] PR fortran/65173 -- kill off old_cl_list from gfc_namespace.

[Steve Kargl]

On Wed, Dec 07, 2016 at 07:55:01PM -0800, Steve Kargl wrote:
> On Wed, Dec 07, 2016 at 06:14:34PM -0800, Steve Kargl wrote:
> > 
> > 2016-12-07  Steven G. Kargl  
> > 
> > PR fortran/65173
> > * gfortran.h (gfc_namespace): Remove old_cl_list member.
> > * parse.c (use_modules, next_statement): old_cl_list is gone.
> > (clear_default_charlen): Remove no longer used function.
> > (reject_statement): Do not try to clean up gfc_charlen structure(s)
> > that may have been added to a cl_list list.
> > * symbol.c (gfc_new_charlen): old_cl_list structure is gone.
> > 
> 
> Appears to fix PR fortran/78350 as well.
  Appears to fix PR fortran/69859 as well.

-- 
Steve

Re: [PATCH] PR fortran/65173 -- kill off old_cl_list from gfc_namespace.

[Steve Kargl]

On Wed, Dec 07, 2016 at 08:51:11PM -0800, Steve Kargl wrote:
> On Wed, Dec 07, 2016 at 07:55:01PM -0800, Steve Kargl wrote:
> > On Wed, Dec 07, 2016 at 06:14:34PM -0800, Steve Kargl wrote:
> > > 
> > > 2016-12-07  Steven G. Kargl  
> > > 
> > >   PR fortran/65173
> > >   * gfortran.h (gfc_namespace): Remove old_cl_list member.
> > >   * parse.c (use_modules, next_statement): old_cl_list is gone.
> > >   (clear_default_charlen): Remove no longer used function.
> > >   (reject_statement): Do not try to clean up gfc_charlen structure(s)
> > >   that may have been added to a cl_list list.
> > >   * symbol.c (gfc_new_charlen): old_cl_list structure is gone.
> > > 
> > 
> > Appears to fix PR fortran/78350 as well.
>   Appears to fix PR fortran/69859 as well.
Appears to fix PR fortran/69064 (although I had no intention to ever
fix this PR.  Sigh, accidence happens).

-- 
Steve