Re: [Patch, gcc-wwdocs] Update to Fortran changes

[Janne Blomqvist]

On Tue, Nov 26, 2019 at 1:12 PM Tobias Burnus  wrote:
> In particular, currently, the following item does not make clear that it
> is about legacy support: "Variables with the AUTOMATIC
> attribute can be used in EQUIVALENCE statements."
>
> I think it can remain as is with the -fdec umbrella item. But without it
> really requires the background knowledge that the AUTOMATIC attribute is
> only available with -fdec-static (or -fdec).

Speaking of which, to avoid confusion maybe we should rename the
-f[no-]automatic option to something like -f[no-]save, since the
Fortran standard description of an "automatic data object" doesn't
really have anything to do with the option, and neither does the
option have anything to do specifically with the DEC AUTOMATIC
specifier?


-- 
Janne Blomqvist

Re: [PATCH] Fix PR91790 by considering different first_stmt_info for realign

[Richard Biener]

On Wed, 27 Nov 2019, Kewen.Lin wrote:

> Hi,
> 
> As PR91790 exposed, when we have one slp node whose first_stmt_info_for_drptr
> is different from first_stmt_info, it's possible that the first_stmt DR isn't
> initialized yet before stmt SLP_TREE_SCALAR_STMTS[0] of slp node. So we
> shouldn't use first_stmt_info for vect_setup_realignment, instead we can use
> the one based on first_stmt_info_for_drptr DR with additional adjustment by
> bumping the distance from first_stmt DR.
> 
> Bootstrapped and tested on powerpc64le-linux-gnu (P8LE) and
> ppc64-redhat-linux (P7BE) which need to use realign_load.
> 
> Is it ok for trunk? and backport to GCC 9 after some burn-in time?

OK.

Thanks,
Richard.

Re: [PATCH] Fix two potential memory leak

[luoxhu]

Thanks,

On 2019/11/26 18:15, Jan Hubicka wrote:
>> Hi,
>>
>> On 2019/11/26 16:04, Jan Hubicka wrote:
 Summary variables should be deleted at the end of write_summary.
 It's first newed in generate_summary, and second newed in read_summary.
 Therefore, delete the first in write_summary, delete the second in
 execute.

 gcc/ChangeLog:

2019-11-26  Luo Xiong Hu  

* ipa-pure-const.c (pure_const_write_summary): Fix memory leak.
* ipa-sra.c (ipa_sra_write_summary): Likewise.
>>>
>>> This is not going to work with -ffat-lto-objects because in this case
>>> IPA pass is executed later.  So you will need
>>> if (!flag_fat_lto_objects).
>>>
>>> I think most IPA passes just waits for compiler to exit with LTO rather
>>> than free the summary.  ipa-fnsummary and ipa-prop allocate optimization
>>> summaries, too. Are those freed?
>>
>> ipa-prop is a bit different, the ipcp_transformation_sum is only created in
>> read_summary, so need only delete once after execute.
> 
> It also has ipa_node_params_sum and ipa_edge_args_sum which live from
> ipa-prop analysis until after ipa-inlining.
>>
>> ipa-fnsummary also forgot to free the ipa summaries at the end of
>> write_summary.  The pass pass_ipa_free_fn_summary will delete all summaries
>> in execute.
>>
>> For -ffat-lto-objects, I suppose there would be no write_summary and
>> read_summary?  so summaries are also newed once and delete once?  Thanks.
>>
>> Anyway, lto1 will run after cc1, which means cc1 is finished, the memory is
>> freed theoretically.
> 
> With -ffat-lto-object we run full optimization pipieline at compile
> time. This means that we first write summary, then execute the pass
> (which uses the summary and frees it) and proceed by compilation.
> With -fno-fat-lto-object the pipieline is terminated after summary
> writting. By quiting compiler we free all the memory.
> 
> We do have a lot of places where memory leaks this way and is freed at
> exit. I see that for jit we added sume explicit free calls, but I think
> jit is not using this path.
> 
> I am not against freeing things explicitly since it makes it easier to
> identify real leaks, but we should do it systematically. Thinking of
> this case probably may even lead to some memory savings because after
> summary streaming the global stream is produced which is typically the
> biggest object streamed.  So freeing it is OK, but please add check for
> !fat lto objects and also free ipa-fnsummary (there is
> ipa_free_fn_summary, ipa_free_size_summary for that) and ipa-prop
> summaries.

Verified that "if (!flag_fat_lto_objects)" is required for explicitly
deleting the summaries when built with -ffat-lto-objects.

> 
> I will also look into your changes for ipa-profile tomorrow (I suppose
> you noticed this while looking into summaries for that patch :)

It's true that I am moving the speculative target summaries from cgraph.h
to ipa-profile.c, code is exploded with hundred of new lines.  Simple test
case could work now with write_summary/read_summary/execute, but most spec
test cases ICEd due to ggc_grow() or ggc_collect(), I debugged the code and
found that read_summary is correct streaming in the target summaries, but some
edge's summary was GCed UNEXPECTEDLY by followed ggc_grow() or ggc_collect()
before calling ipa_profile, any clue on this, please?
Great that you take time on this!:)


ipa-profile.c
...
+/* Structure containing speculative target information from profile.  */
+
+struct GTY (()) speculative_call_target
+{
+  speculative_call_target (unsigned int id, int prob)
+: target_id (id), target_probability (prob)
+  {
+  }
+
+  /* Profile_id of target obtained from profile.  */
+  unsigned int target_id;
+  /* Probability that call will land in function with target_id.  */
+  int target_probability;
+};
+
+class speculative_call_summary
+{
+public:
+  speculative_call_summary () : speculative_call_targets () {}
+
+  vec *speculative_call_targets;
+  ~speculative_call_summary ();
+
+  void dump (FILE *f);
+
+  /* Check whether this is a empty summary.  */
+  bool is_empty ();
+};
...

Xiong Hu

> Honza
>>
>> Xiong Hu
>>
>>
>>>
>>> Honza
 ---
gcc/ipa-pure-const.c | 3 +++
gcc/ipa-sra.c| 5 +
2 files changed, 8 insertions(+)

 diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
 index a142e0cc8f6..89f334cedac 100644
 --- a/gcc/ipa-pure-const.c
 +++ b/gcc/ipa-pure-const.c
 @@ -1260,6 +1260,9 @@ pure_const_write_summary (void)
}
  lto_destroy_simple_output_block (ob);
 +
 +  delete funct_state_summaries;
 +  funct_state_summaries = NULL;
}
 diff --git a/gcc/ipa-sra.c b/gcc/ipa-sra.c
 index c6ed0f44b87..bbc5e84edfb 100644
 --- a/gcc/ipa-sra.c
 +++ b/gcc/ipa-sra.c
 @@ -2671,6 +2671,11 @@ ipa_sra_write_summary (void)
  streamer_write_char_stream (ob->main_stream, 0);
  produce_asm (ob, NULL);

Re: [PATCH] [rs6000] Fix PR92098

[Li Jia He]

On 2019/11/27 2:42 PM, Kewen.Lin wrote:

Hi Lijia,

on 2019/11/27 下午2:31, Li Jia He wrote:

Hi,

In order to fix PR92098, we need to define vec_cmp_* and vcond_mask_*.  In fact,
PR92132 already fixed the issue on the trunk.  We need to backport PR92132 int
part to gcc-9-branch.  This patch backport vector_{ungt,unge,unlt,unle}
for vec_{cmp,cmpu} interface and related expand to gcc-9-branch.



Is it a typo here?  I didn't see any parts on those FP comparison operators 
that is
vector_{ungt,unge,unlt,unle} in this patch, I guess you means to give up that 
part?


Hi Kewen,

Yes.  I just want to backport int part of PR92132 fix to gcc-9-branch.

Thanks,
Lijia He


since I noticed you just ported two cases on integral type.

BR,
Kewen

Re: [PATCH] [rs6000] Fix PR92098

[Kewen.Lin]

Hi Lijia,

on 2019/11/27 下午2:31, Li Jia He wrote:
> Hi,
> 
> In order to fix PR92098, we need to define vec_cmp_* and vcond_mask_*.  In 
> fact,
> PR92132 already fixed the issue on the trunk.  We need to backport PR92132 int
> part to gcc-9-branch.  This patch backport vector_{ungt,unge,unlt,unle}
> for vec_{cmp,cmpu} interface and related expand to gcc-9-branch.
> 

Is it a typo here?  I didn't see any parts on those FP comparison operators 
that is
vector_{ungt,unge,unlt,unle} in this patch, I guess you means to give up that 
part?
since I noticed you just ported two cases on integral type.

BR,
Kewen

[PATCH] [rs6000] Fix PR92098

[Li Jia He]

Hi,

In order to fix PR92098, we need to define vec_cmp_* and vcond_mask_*.  In fact,
PR92132 already fixed the issue on the trunk.  We need to backport PR92132 int
part to gcc-9-branch.  This patch backport vector_{ungt,unge,unlt,unle}
for vec_{cmp,cmpu} interface and related expand to gcc-9-branch.

The regression testing for the patch was done on GCC 9 branch on

powerpc64le-unknown-linux-gnu (Power 9 LE)

with no regressions.  Is it OK for GCC 9 branch ?

Thanks,
Lijia He

gcc/ChangeLog

2019-11-27  Li Jia He  

PR target/92098
* config/rs6000/predicates.md
(signed_or_equality_comparison_operator): New predicate.
(unsigned_or_equality_comparison_operator): Likewise.
* config/rs6000/rs6000.md (one_cmpl2): Remove expand.
(one_cmpl3_internal): Rename to one_cmpl2.
* config/rs6000/vector.md
(vcond_mask_ for VEC_I and VEC_I): New expand.
(vec_cmp for VEC_I and VEC_I): Likewise.
(vec_cmpu for VEC_I and VEC_I): Likewise.

gcc/testsuite/ChangeLog

2019-11-27  Li Jia He  

PR target/92098
* gcc.target/powerpc/pr92098-int-1.c: New test.
* gcc.target/powerpc/pr92098-int-2.c: New test.
---
 gcc/config/rs6000/predicates.md   |  10 ++
 gcc/config/rs6000/rs6000.md   |   8 +-
 gcc/config/rs6000/vector.md   |  95 +
 .../gcc.target/powerpc/pr92098-int-1.c| 126 ++
 .../gcc.target/powerpc/pr92098-int-2.c| 126 ++
 5 files changed, 358 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr92098-int-1.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr92098-int-2.c

diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000/predicates.md
index 5cc80dea66c..e6e81471a02 100644
--- a/gcc/config/rs6000/predicates.md
+++ b/gcc/config/rs6000/predicates.md
@@ -1154,6 +1154,16 @@
 (define_predicate "signed_comparison_operator"
   (match_code "lt,gt,le,ge"))
 
+;; Return 1 if OP is a signed comparison or an equality operator.
+(define_predicate "signed_or_equality_comparison_operator"
+  (ior (match_operand 0 "equality_operator")
+   (match_operand 0 "signed_comparison_operator")))
+
+;; Return 1 if OP is an unsigned comparison or an equality operator.
+(define_predicate "unsigned_or_equality_comparison_operator"
+  (ior (match_operand 0 "equality_operator")
+   (match_operand 0 "unsigned_comparison_operator")))
+
 ;; Return 1 if OP is a comparison operation that is valid for an SCC insn --
 ;; it must be a positive comparison.
 (define_predicate "scc_comparison_operator"
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 7bfa5eea2ee..32da805a32d 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -6430,12 +6430,6 @@
   ""
   "")
 
-(define_expand "one_cmpl2"
-  [(set (match_operand:BOOL_128 0 "vlogical_operand")
-(not:BOOL_128 (match_operand:BOOL_128 1 "vlogical_operand")))]
-  ""
-  "")
-
 (define_expand "nor3"
   [(set (match_operand:BOOL_128 0 "vlogical_operand")
(and:BOOL_128
@@ -6730,7 +6724,7 @@
 (const_string "16")))])
 
 ;; 128-bit one's complement
-(define_insn_and_split "*one_cmpl3_internal"
+(define_insn_and_split "one_cmpl2"
   [(set (match_operand:BOOL_128 0 "vlogical_operand" "=")
(not:BOOL_128
  (match_operand:BOOL_128 1 "vlogical_operand" "")))]
diff --git a/gcc/config/rs6000/vector.md b/gcc/config/rs6000/vector.md
index 70bcfe02e22..0b62dd04bde 100644
--- a/gcc/config/rs6000/vector.md
+++ b/gcc/config/rs6000/vector.md
@@ -493,6 +493,101 @@
 FAIL;
 })
 
+;; To support vector condition vectorization, define vcond_mask and vec_cmp.
+
+;; Same mode for condition true/false values and predicate operand.
+(define_expand "vcond_mask_"
+  [(match_operand:VEC_I 0 "vint_operand")
+   (match_operand:VEC_I 1 "vint_operand")
+   (match_operand:VEC_I 2 "vint_operand")
+   (match_operand:VEC_I 3 "vint_operand")]
+  "VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)"
+{
+  emit_insn (gen_vector_select_ (operands[0], operands[2], operands[1],
+  operands[3]));
+  DONE;
+})
+
+;; For signed integer vectors comparison.
+(define_expand "vec_cmp"
+  [(set (match_operand:VEC_I 0 "vint_operand")
+(match_operator 1 "signed_or_equality_comparison_operator"
+  [(match_operand:VEC_I 2 "vint_operand")
+   (match_operand:VEC_I 3 "vint_operand")]))]
+  "VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)"
+{
+  enum rtx_code code = GET_CODE (operands[1]);
+  rtx tmp = gen_reg_rtx (mode);
+  switch (code)
+{
+case NE:
+  emit_insn (gen_vector_eq (operands[0], operands[2], operands[3]));
+  emit_insn (gen_one_cmpl2 (operands[0], operands[0]));
+  break;
+case EQ:
+  emit_insn (gen_vector_eq (operands[0], operands[2], operands[3]));
+  break;
+case GE:
+  emit_insn (gen_vector_nlt (operands[0],operands[2], operands[3],
+   

[PATCH] Fix PR91790 by considering different first_stmt_info for realign

[Kewen.Lin]

Hi,

As PR91790 exposed, when we have one slp node whose first_stmt_info_for_drptr
is different from first_stmt_info, it's possible that the first_stmt DR isn't
initialized yet before stmt SLP_TREE_SCALAR_STMTS[0] of slp node. So we
shouldn't use first_stmt_info for vect_setup_realignment, instead we can use
the one based on first_stmt_info_for_drptr DR with additional adjustment by
bumping the distance from first_stmt DR.

Bootstrapped and tested on powerpc64le-linux-gnu (P8LE) and
ppc64-redhat-linux (P7BE) which need to use realign_load.

Is it ok for trunk? and backport to GCC 9 after some burn-in time?

BR,
Kewen



gcc/ChangeLog

2019-11-27  Kewen Lin  

PR tree-optimization/91790
* gcc/tree-vect-stmts.c (vectorizable_load): Use the adjusted DR for
vect_setup_realignment when first_stmt_info is different from
first_stmt_info_for_drptr.
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index fb669cd..422947b 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -9186,18 +9186,27 @@ vectorizable_load (stmt_vec_info stmt_info, 
gimple_stmt_iterator *gsi,
   compute_in_loop = true;
 }
 
+  bool diff_first_stmt_info
+= first_stmt_info_for_drptr && first_stmt_info != 
first_stmt_info_for_drptr;
+
   if ((alignment_support_scheme == dr_explicit_realign_optimized
|| alignment_support_scheme == dr_explicit_realign)
   && !compute_in_loop)
 {
-  msq = vect_setup_realignment (first_stmt_info, gsi, _token,
-   alignment_support_scheme, NULL_TREE,
-   _loop);
+  /* If we have different first_stmt_info, we can't set up realignment
+here, since we can't guarantee first_stmt_info DR has been
+initialized yet, use first_stmt_info_for_drptr DR by bumping the
+distance from first_stmt_info DR instead as below.  */
+  if (!diff_first_stmt_info)
+   msq = vect_setup_realignment (first_stmt_info, gsi, _token,
+ alignment_support_scheme, NULL_TREE,
+ _loop);
   if (alignment_support_scheme == dr_explicit_realign_optimized)
{
  phi = as_a  (SSA_NAME_DEF_STMT (msq));
  byte_offset = size_binop (MINUS_EXPR, TYPE_SIZE_UNIT (vectype),
size_one_node);
+ gcc_assert (!first_stmt_info_for_drptr);
}
 }
   else
@@ -9253,8 +9262,7 @@ vectorizable_load (stmt_vec_info stmt_info, 
gimple_stmt_iterator *gsi,
  dataref_ptr = unshare_expr (DR_BASE_ADDRESS (first_dr_info->dr));
  dataref_offset = build_int_cst (ref_type, 0);
}
- else if (first_stmt_info_for_drptr
-  && first_stmt_info != first_stmt_info_for_drptr)
+ else if (diff_first_stmt_info)
{
  dataref_ptr
= vect_create_data_ref_ptr (first_stmt_info_for_drptr,
@@ -9271,6 +9279,14 @@ vectorizable_load (stmt_vec_info stmt_info, 
gimple_stmt_iterator *gsi,
DR_INIT (ptrdr)));
  dataref_ptr = bump_vector_ptr (dataref_ptr, ptr_incr, gsi,
 stmt_info, diff);
+ if (alignment_support_scheme == dr_explicit_realign)
+   {
+ msq = vect_setup_realignment (first_stmt_info_for_drptr, gsi,
+   _token,
+   alignment_support_scheme,
+   dataref_ptr, _loop);
+ gcc_assert (!compute_in_loop);
+   }
}
  else if (STMT_VINFO_GATHER_SCATTER_P (stmt_info))
vect_get_gather_scatter_ops (loop, stmt_info, _info,

[PATCH, rs6000] Fix PR92566 by checking VECTOR_UNIT_NONE_P

[Kewen.Lin]

Hi,

As Segher pointed out in PR92566, we shouldn't offer some vector modes which
aren't supported under current setting.  This patch is to make it check by
VECTOR_UNIT_NONE_P which is initialized as current architecture masks.

Bootstrapped and tested on powerpc64le-linux-gnu.
Is it ok for trunk?

BR,
Kewen


gcc/ChangeLog

2019-11-27  Kewen Lin  

PR tree-optimization/91790
* gcc/config/rs6000/rs6000.c (rs6000_preferred_simd_mode): Check by
VECTOR_UNIT_NONE_P instead.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 5876714..40529e6 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -4906,30 +4906,11 @@ rs6000_builtin_vectorization_cost (enum 
vect_cost_for_stmt type_of_cost,
 static machine_mode
 rs6000_preferred_simd_mode (scalar_mode mode)
 {
-  if (TARGET_VSX)
-switch (mode)
-  {
-  case E_DFmode:
-   return V2DFmode;
-  default:;
-  }
-  if (TARGET_ALTIVEC || TARGET_VSX)
-switch (mode)
-  {
-  case E_SFmode:
-   return V4SFmode;
-  case E_TImode:
-   return V1TImode;
-  case E_DImode:
-   return V2DImode;
-  case E_SImode:
-   return V4SImode;
-  case E_HImode:
-   return V8HImode;
-  case E_QImode:
-   return V16QImode;
-  default:;
-  }
+  opt_machine_mode vmode = mode_for_vector (mode, 16 / GET_MODE_SIZE (mode));
+
+  if (vmode.exists () && !VECTOR_UNIT_NONE_P (vmode.require ()))
+return vmode.require ();
+
   return word_mode;
 }
 

Re: [PATCH][_GLIBCXX_DEBUG] Improve valid_range check

[François Dumont]

On 11/26/19 10:52 PM, Jonathan Wakely wrote:

On 26/11/19 20:07 +0100, François Dumont wrote:

Sure, I am about to do so.

However I wasn't sure about this syntax before the commit so I had 
run the new 2_neg.cc with:


make CXXFLAGS=-std=c++98 check-debug

and it worked fine and still is !


The testsuite doesn't use CXXFLAGS.


Did you mean CPPFLAGS ?

I do see the option added to the compiler call in libstdc++.log file. 
And I used it to build for instance pretty-printers tests in 
_GLIBCXX_DEBUG mode with success.




I also try -std=gnu++98 and made sure that pch had been updated by 
re-building libstdc++ first. I just can't get the expected 
compilation error.


Maybe I need to rebuild the whole stuff to get an error...


No, you need to pass the right flags so they are used by the
testsuite. This will do it:

make -C testsuite/  check-debug 
debug_flags=unix/-D_GLIBCXX_DEBUG/-std=gnu++98/-Wsystem-headers

I'll have to keep your mail to remember it !


But since it only shows up with -Wsystem-headers, there's no point
trying to test for it.



Ok, makes sens.

Thanks

Re: [PATCH/AARCH64] Generate FRINTZ for (double)(long) under -ffast-math on aarch64

[Andrew Pinski]

On Tue, Nov 26, 2019 at 2:30 PM Richard Sandiford
 wrote:
>
> Andrew Pinski  writes:
> > On Fri, Aug 18, 2017 at 12:17 PM Andrew Pinski  wrote:
> >>
> >> Like https://gcc.gnu.org/ml/gcc-patches/2010-09/msg00060.html for
> >> PowerPC, we should do something similar for aarch64.  This pattern
> >> does show up in SPEC CPU 2006 in astar but I did not look into
> >> performance improvement of it though.
> >>
> >> OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.
> >
> > Ping?  I has been over 2 years now too.
>
> I think it'd better to do this in match.pd, folding to IFN_TRUNC.
> The rule will then automatically check whether the target supports
> IFN_TRUNC/btrunc_optab for the required mode.

Yes I agree, it should be done generically.  I will look into doing
that for stage 1.

Thanks,
Andrew

>
> Thanks,
> Richard

[PATCH] Fix TYPO of avx512f_maskcmp3.

[Hongtao Liu]

hi jakub:
  VF is used for differentiating AVX512F/AVX/SSE, but there's
condition TARGET_AVX512F in avx512f_maskcmp3, it must be a TYPO
and should be VF_AVX512VL instead.

Bootstrap and regression test on i386/x86_64 backend is ok.
OK for trunk?


diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 62c68053563..fb43cafaad0 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -3129,8 +3129,8 @@
 (define_insn "avx512f_maskcmp3"
   [(set (match_operand: 0 "register_operand" "=k")
(match_operator: 3 "sse_comparison_operator"
- [(match_operand:VF 1 "register_operand" "v")
-  (match_operand:VF 2 "nonimmediate_operand" "vm")]))]
+ [(match_operand:VF_AVX512VL 1 "register_operand" "v")
+  (match_operand:VF_AVX512VL 2 "nonimmediate_operand" "vm")]))]
   "TARGET_AVX512F"
   "vcmp%D3\t{%2, %1, %0|%0, %1, %2}"
   [(set_attr "type" "ssecmp")


-- 
BR,
Hongtao

[C++ PATCH] Remember the location of a variable template-id.

[Jason Merrill]

I noticed that tsubst of a TEMPLATE_ID_EXPR was losing the location
information from its EXPR_LOCATION.  Then I noticed that
cxx_eval_constant_expression was also throwing away location information for
variable references.

Tested x86_64-pc-linux-gnu, applying to trunk.

* pt.c (tsubst_copy_and_build) [TEMPLATE_ID_EXPR]: Remember the
location of a variable template-id.
* constexpr.c (cxx_eval_constant_expression): Get expr location
before stripping location wrappers.
(non_const_var_error): Take location argument.
---
 gcc/cp/constexpr.c   | 44 +++-
 gcc/cp/pt.c  |  7 +++-
 gcc/testsuite/g++.dg/concepts/pr67595.C  |  2 +-
 gcc/testsuite/g++.dg/cpp1y/var-templ64.C | 14 
 4 files changed, 41 insertions(+), 26 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/var-templ64.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 658455cce96..f648b1d8e4c 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -3786,27 +3786,27 @@ cxx_eval_indirect_ref (const constexpr_ctx *ctx, tree t,
cxx_eval_constant_expression.  */
 
 static void
-non_const_var_error (tree r)
+non_const_var_error (location_t loc, tree r)
 {
   auto_diagnostic_group d;
   tree type = TREE_TYPE (r);
   if (DECL_NAME (r) == heap_uninit_identifier
   || DECL_NAME (r) == heap_identifier)
 {
-  error ("the content of uninitialized storage is not usable "
-"in a constant expression");
+  error_at (loc, "the content of uninitialized storage is not usable "
+   "in a constant expression");
   inform (DECL_SOURCE_LOCATION (r), "allocated here");
   return;
 }
   if (DECL_NAME (r) == heap_deleted_identifier)
 {
-  error ("use of allocated storage after deallocation in a "
-"constant expression");
+  error_at (loc, "use of allocated storage after deallocation in a "
+   "constant expression");
   inform (DECL_SOURCE_LOCATION (r), "allocated here");
   return;
 }
-  error ("the value of %qD is not usable in a constant "
-"expression", r);
+  error_at (loc, "the value of %qD is not usable in a constant "
+   "expression", r);
   /* Avoid error cascade.  */
   if (DECL_INITIAL (r) == error_mark_node)
 return;
@@ -4765,6 +4765,8 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,
   return t;
 }
 
+  location_t loc = cp_expr_loc_or_input_loc (t);
+
   STRIP_ANY_LOCATION_WRAPPER (t);
 
   if (CONSTANT_CLASS_P (t))
@@ -4794,7 +4796,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,
   if (++ctx->global->constexpr_ops_count >= constexpr_ops_limit)
 {
   if (!ctx->quiet)
-   error_at (cp_expr_loc_or_input_loc (t),
+   error_at (loc,
  "% evaluation operation count exceeds limit of "
  "%wd (use %<-fconstexpr-ops-limit=%> to increase the limit)",
  constexpr_ops_limit);
@@ -4877,7 +4879,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,
   if (DECL_P (r))
{
  if (!ctx->quiet)
-   non_const_var_error (r);
+   non_const_var_error (loc, r);
  *non_constant_p = true;
}
   break;
@@ -5086,9 +5088,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,
  jump_target);
if (!CLEANUP_EH_ONLY (t) && !*non_constant_p)
  {
-   location_t loc = input_location;
-   if (EXPR_HAS_LOCATION (t))
- input_location = EXPR_LOCATION (t);
+   iloc_sentinel ils (loc);
/* Also evaluate the cleanup.  If we weren't skipping at the
   start of the CLEANUP_BODY, change jump_target temporarily
   to _jump_target, so that even a return or break or
@@ -5097,7 +5097,6 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,
  non_constant_p, overflow_p,
  jump_target ? _jump_target
  : NULL);
-   input_location = loc;
  }
   }
   break;
@@ -5365,7 +5364,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,
   if (REINTERPRET_CAST_P (t))
{
  if (!ctx->quiet)
-   error_at (cp_expr_loc_or_input_loc (t),
+   error_at (loc,
  "% is not a constant expression");
  *non_constant_p = true;
  return t;
@@ -5405,7 +5404,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,
if (TYPE_REF_P (type))
  {
if (!ctx->quiet)
- error_at (cp_expr_loc_or_input_loc (t),
+ error_at (loc,
"dereferencing a null pointer");
*non_constant_p = true;
  

[analyzer] Don't use shape=record in .dot output

[David Malcolm]

Recent versions of graphviz reject the .dot files emitted by the
analyzer, with messages such as:

  Warning: flat edge between adjacent nodes one of which has a record shape - 
replace records with HTML-like labels
Edge node_9 -> node_8

The above warning seems to have been added to graphviz on 2014-07-25 in:
  
https://gitlab.com/graphviz/graphviz/commit/763f02ef3cb7fbb62336f372b42279bd63266727

This patch reworks the .dot output from the analyzer so that it works
with newer graphviz (tested with graphviz-2.40.1-46.fc30.x86_64), and
adds DejaGnu test coverage that the .dot files can be parsed by "dot",
if installed on the host.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

Pushed to branch "dmalcolm/analyzer" on the GCC git mirror.

gcc/ChangeLog:
* analyzer/engine.cc (exploded_node::dump_dot): Replace
'shape=record' with 'shape=none,margin=0' and eliminate outermost
braces.
(viz_callgraph_node::dump_dot): Replace 'shape=record' with
'shape=none,margin=0' and use an HTML-like TABLE label.
* analyzer/graphviz.cc (graphviz_out::begin_tr): New function.
(graphviz_out::end_tr): New function.
* analyzer/graphviz.h (graphviz_out::begin_tr): New decl.
(graphviz_out::end_tr): New decl.
* analyzer/region-model.cc (region::dump_dot_to_pp): Replace
'shape=record' with 'shape=none,margin=0', and switch to
non-record escaping.
* analyzer/state-purge.cc
(state_purge_annotator::add_node_annotations): Pass in a
graphviz_out * rather than a pretty_printer *.  Replace
'shape=record' with 'shape=none,margin=0' and eliminate outermost
braces.
(print_vec_of_names): Pass in a graphviz_out * rather than a
pretty_printer *.  Wrap the output in a .
(state_purge_annotator::add_stmt_annotations): Pass in a
graphviz_out * rather than a pretty_printer *.
* analyzer/state-purge.h
(state_purge_annotator::add_node_annotations): Pass in a
graphviz_out * rather than a pretty_printer *.
(state_purge_annotator::add_stmt_annotations): Likewise.
* analyzer/supergraph.cc (supernode::dump_dot): Update for above
annotator changes.  Replace 'shape=record' with
'shape=none,margin=0' and convert label to an HTML-like TABLE.
* analyzer/supergraph.h (dot_annotator::add_node_annotations):
Pass in a graphviz_out * rather than a pretty_printer *.
(dot_annotator::add_stmt_annotations): Likewise.
* pretty-print.c (pp_write_text_as_html_like_dot_to_stream): New
function.
* pretty-print.h (pp_write_text_as_html_like_dot_to_stream): New decl.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/dot-output.c: New test.
* lib/gcc-defs.exp (dg-check-dot): New procedure.
* lib/target-supports-dg.exp (dg-require-dot): New procedure.
* lib/target-supports.exp (check_dot_available): New procedure.
---
 gcc/analyzer/engine.cc | 30 +-
 gcc/analyzer/graphviz.cc   | 20 +
 gcc/analyzer/graphviz.h|  3 ++
 gcc/analyzer/region-model.cc   |  6 +--
 gcc/analyzer/state-purge.cc| 29 +++--
 gcc/analyzer/state-purge.h |  4 +-
 gcc/analyzer/supergraph.cc | 44 +---
 gcc/analyzer/supergraph.h  |  4 +-
 gcc/pretty-print.c | 48 ++
 gcc/pretty-print.h |  3 ++
 gcc/testsuite/gcc.dg/analyzer/dot-output.c | 33 +++
 gcc/testsuite/lib/gcc-defs.exp | 21 ++
 gcc/testsuite/lib/target-supports-dg.exp   | 10 +
 gcc/testsuite/lib/target-supports.exp  | 13 ++
 14 files changed, 224 insertions(+), 44 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/dot-output.c

diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index aa4a3590574d..e02ac7de6577 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -702,10 +702,8 @@ exploded_node::dump_dot (graphviz_out *gv, const 
dump_args_t ) const
   pretty_printer *pp = gv->get_pp ();
 
   dump_dot_id (pp);
-  pp_printf (pp, " [shape=%s,style=filled,fillcolor=%s,label=\"",
-"record",
+  pp_printf (pp, " [shape=none,margin=0,style=filled,fillcolor=%s,label=\"",
 get_dot_fillcolor ());
-  pp_left_brace (pp);
   pp_write_text_to_stream (pp);
 
   pp_printf (pp, "EN: %i", m_index);
@@ -735,7 +733,6 @@ exploded_node::dump_dot (graphviz_out *gv, const 
dump_args_t ) const
 
   pp_write_text_as_dot_label_to_stream (pp, /*for_record=*/true);
 
-  pp_right_brace (pp);
   pp_string (pp, "\"];\n\n");
   pp_flush (pp);
 }
@@ -3125,17 +3122,24 @@ public:
 pretty_printer *pp = gv->get_pp ();
 
 dump_dot_id (pp);
-pp_printf (pp, " [shape=%s,style=filled,fillcolor=%s,label=\"",
-  "record", 

Re: [C++ PATCH] Fix ICE in build_ctor_subob_ref during replace_placeholders (PR c++/92524, take 2)

[Jason Merrill]

On 11/26/19 6:42 PM, Jakub Jelinek wrote:

On Tue, Nov 26, 2019 at 04:58:01PM -0500, Jason Merrill wrote:

Hmm, we shouldn't have any PLACEHOLDER_EXPR under a RANGE_EXPR; if we did,
any references to its address would end up all referring to the first
element of the range, which would be wrong.  How about skipping RANGE_EXPR
in replace_placeholders_r?


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


OK.


2019-11-27  Jakub Jelinek  

PR c++/92524
* tree.c (replace_placeholders_r): Don't walk constructor elts with
RANGE_EXPR indexes.

* g++.dg/cpp0x/pr92524.C: New test.

--- gcc/cp/tree.c.jj2019-11-26 23:09:55.904101392 +0100
+++ gcc/cp/tree.c   2019-11-26 23:13:14.308070759 +0100
@@ -3144,6 +3144,11 @@ replace_placeholders_r (tree* t, int* wa
tree type = TREE_TYPE (*valp);
tree subob = obj;
  
+	/* Elements with RANGE_EXPR index shouldn't have any

+  placeholders in them.  */
+   if (ce->index && TREE_CODE (ce->index) == RANGE_EXPR)
+ continue;
+
if (TREE_CODE (*valp) == CONSTRUCTOR
&& AGGREGATE_TYPE_P (type))
  {
--- gcc/testsuite/g++.dg/cpp0x/pr92524.C.jj 2019-11-26 23:09:46.810240310 
+0100
+++ gcc/testsuite/g++.dg/cpp0x/pr92524.C2019-11-26 23:09:46.810240310 
+0100
@@ -0,0 +1,12 @@
+// PR c++/92524
+// { dg-do compile { target c++11 } }
+
+struct A { char a = '*'; };
+struct B { A b[64]; };
+
+void
+foo ()
+{
+  A a;
+  B{a};
+}

Jakub

Re: [PATCH] Support multi-versioning on self-recursive function (ipa/92133)

[Feng Xue OS]

Hi, Richard,

  This patch is a not bugfix, while it is small. Martin and Honza are fine with 
it.
But now we are in stage 3, is it ok to commit?

Thanks,
Feng


From: Feng Xue OS 
Sent: Monday, November 25, 2019 10:17 PM
To: Martin Jambor; Jan Hubicka
Cc: luoxhu; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Support multi-versioning on self-recursive function 
(ipa/92133)

Martin,

Thanks for your review. I updated the patch with your comments.

Feng
---
2019-11-15  Feng Xue 

PR ipa/92133
* doc/invoke.texi (ipa-cp-max-recursive-depth): Document new option.
(ipa-cp-min-recursive-probability): Likewise.
* params.opt (ipa-cp-max-recursive-depth): New.
(ipa-cp-min-recursive-probability): Likewise.
* ipa-cp.c (ipcp_lattice::add_value): Add two new parameters
val_p and unlimited.
(self_recursively_generated_p): New function.
(get_val_across_arith_op): Likewise.
(propagate_vals_across_arith_jfunc): Add constant propagation for
self-recursive function.
(incorporate_penalties): Do not penalize pure self-recursive function.
(good_cloning_opportunity_p): Dump node_is_self_scc flag.
(propagate_constants_topo): Set node_is_self_scc flag for cgraph node.
(get_info_about_necessary_edges): Relax hotness check for edge to
self-recursive function.
* ipa-prop.h (ipa_node_params): Add new field node_is_self_scc.
---

> The least important comment: Thanks for providing the ChangeLog but
> sending ChangeLog in the patch itself makes it difficult for people to
> apply the patch because the ChangeLog hunks will never apply cleanly.
> That's why people send them in the email body when they email
> gcc-patches.  Hopefully we'll be putting ChangeLogs only into the commit
> message soon and all of this will be a non-issue.
Ok.

>> +  if (val_pos_p)
>> +{
>> +  for (val = values; val && val != *val_pos_p; val = val->next);

> Please put empty statements on a separate line (I think there is one
> more in the patch IIRC).
Done.

>> +  if (val_pos_p)
>> +{
>> +  val->next = (*val_pos_p)->next;
>> +  (*val_pos_p)->next = val;
>> +  *val_pos_p = val;
>> +}

> I must say I am not a big fan of the val_pos_p parameter.  Would simply
> putting new values always at the end of the list work to reduce the
> iterations?  At this point the function has traversed all the values
> already when searching if it is present, so it can remember the last
> one and just add stuff after it.
We need a parameter to record address of the added value, which will be used
in constructing next one. To place new value at the end of list is a good idea,
thus meaning of val_pos_p becomes simpler, it is only an out parameter now.

>> +  if (!src->val || cs->caller != cs->callee->function_symbol ()
>> +   || src->val == val)
>> + return false;

> I'd suggest putting the condition calling function_symbol last.
Original condition order can reduce unnecessary evaluations on src->val==val,
which is false in most situation, while cs->caller != 
cs->callee->function_symbol ()
is true.

>> +  for (src_val = src_lat->values; src_val && src_val != val;
>> +src_val = src_val->next);

> I think that GNU code style dictates that when a for does not fit on a
> single line, the three bits have to be on a separate line each.  Plus
> please put the empty statement on its own line too.
Done.

>> +static tree
>> +get_val_across_arith_op (enum tree_code opcode,
>> +  tree opnd1_type,
>> +  tree opnd2,
>> +  ipcp_value *src_val,
>> +  tree res_type)

> The function should get at least a brief comment.
Done.

>> +   for (ipcp_value_source *s = src_val->sources; s;
>> +s = s->next)

> I'm afraid you'll have to reformat this for loop too.
Done.
>> + if (self_recursively_generated_p (src_val))
>> +   continue;

> I think you are missing a necessary call to
> dest_lat->set_contains_variable() here.  Either call it or initialize
> cstval to zero and call get_val_across_arith_op only when
> self_recursively_generated_p returns false;
Yes, this is a bug. Fixed.


0001-Enable-recursive-function-versioning.patch
Description: 0001-Enable-recursive-function-versioning.patch

[PATCH] Reformat PowerPC movdi_internal64

[Michael Meissner]

As we discussed in the V6 patches #1 and #2, before submitting the patches
adding eI support for movdi and movsi, you prefered that I reformat the patches
to make them easier in the future to identify the changes.

This patch changes just the movdi_internal64 insn.  All of the constraints are
in the same order as the current sources.  I did add setting "num_insns" to
this patch, but I left in setting "length".  I found otherwise the Spec
benchmarks did not generate the same code with the patch.

I have bootstrapped the compiler with this change and the movdi_internal64
patch that will be submitted next, and there were no problems with the
bootstrap or tests that regressed.  I compared Spec 2017 INT benchmarks and the
number of each instruction matches the previous version I tested.  Can I check
this into the GCC trunk?

2019-11-26  Michael Meissner  

* config/rs6000/rs6000.md (movdi_internal64): Logically align the
columns of constraints and attributes to make it easier to add new
patterns in the middle.  Set the num_insns insn attribute.

Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 278747)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -8838,24 +8838,35 @@ (define_split
   DONE;
 })
 
-;;  GPR store  GPR load   GPR move   GPR li GPR lis GPR #
-;;  FPR store  FPR load   FPR move   AVX store  AVX store   AVX 
load
-;;  AVX load   VSX move   P9 0   P9 -1  AVX 0/-1VSX 0
-;;  VSX -1 P9 const   AVX const  From SPR   To SPR  
SPR<->SPR
+;;  GPR store  GPR load   GPR move
+;;  GPR li GPR lisGPR #
+;;  FPR store  FPR load   FPR move
+;;  AVX store  AVX store  AVX load   AVX load   VSX move
+;;  P9 0   P9 -1  AVX 0/-1   VSX 0  VSX -1
+;;  P9 const   AVX const
+;;  From SPR   To SPR SPR<->SPR
 ;;  VSX->GPR   GPR->VSX
+
 (define_insn "*movdi_internal64"
   [(set (match_operand:DI 0 "nonimmediate_operand"
-   "=YZ,   r, r, r, r,  r,
-m, ^d,^d,wY,Z,  $v,
-$v,^wa,   wa,wa,v,  wa,
-wa,v, v, r, *h, *h,
+   "=YZ,   r, r,
+r, r, r,
+m, ^d,^d,
+wY,Z, $v,$v,^wa,
+wa,wa,v, wa,wa,
+v, v,
+r, *h,*h,
 ?r,?wa")
+
(match_operand:DI 1 "input_operand"
-   "r, YZ,r, I, L,  nF,
-^d,m, ^d,^v,$v, wY,
-Z, ^wa,   Oj,wM,OjwM,   Oj,
-wM,wS,wB,*h,r,  0,
+   "r, YZ,r,
+I, L, nF,
+^d,m, ^d,^v,$v,
+wY,Z, ^wa,   Oj,wM,
+OjwM,  Oj,wM,wS,wB,
+*h,r, 0,
 wa,r"))]
+
   "TARGET_POWERPC64
&& (gpc_reg_operand (operands[0], DImode)
|| gpc_reg_operand (operands[1], DImode))"
@@ -8887,23 +8898,41 @@ (define_insn "*movdi_internal64"
mfvsrd %0,%x1
mtvsrd %x0,%1"
   [(set_attr "type"
-   "store,  load,  *, *, *, *,
-fpstore,fpload, fpsimple,  fpstore,   fpstore,   
fpload,
-fpload, veclogical, vecsimple, vecsimple, vecsimple, 
veclogical,
-veclogical, vecsimple,  vecsimple, mfjmpr,mtjmpr,*,
-mftgpr,mffgpr")
+   "store,  load,  *,
+*,  *,  *,
+fpstore,fpload,fpsimple,
+fpstore,fpstore,   fpload, fpload, veclogical,
+vecsimple,  vecsimple, vecsimple,  veclogical, veclogical,
+vecsimple,  vecsimple,
+mfjmpr, mtjmpr,*,
+mftgpr, mffgpr")
(set_attr "size" "64")
(set_attr "length"
-   "*, *, *, *, *,  20,
-*, *, *, *, *,  *,
-*, *, *, *, *,  *,
-*, 8, *, *, *,  *,
-*, *")
+"*, *, *,
+*,  *, 

[PATCH] Reformat PowerPC movsi_internal

[Michael Meissner]

As we discussed in the V6 patches #1 and #2, before submitting the patches
adding eI support for movdi and movsi, you prefered that I reformat the patches
to make them easier in the future to identify the changes.

This patch changes just the movsi_internal insn.  All of the constraints are in
the same order as the current sources.  I did add setting "num_insns" to this
patch, but I left in setting "length".  I found otherwise the Spec benchmarks
did not generate the same code with the patch.

I have bootstrapped the compiler with this change and the movdi_internal64
patch that will be submitted next, and there were no problems with the
bootstrap or tests that regressed.  I compared Spec 2017 INT benchmarks and the
number of each instruction matches the previous version I tested.  Can I check
this into the GCC trunk?

2019-11-26  Michael Meissner  

* config/rs6000/rs6000.md (movsi_internal): Logically align the
columns of constraints and attributes to make it easier to add new
patterns in the middle.  Set the num_insns insn attribute.

Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 278746)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -6889,24 +6889,36 @@ (define_split
 UNSPEC_MOVSI_GOT))]
   "")
 
-;; MR   LA   LWZ  LFIWZX   LXSIWZX
-;; STW  STFIWX   STXSIWX  LI   LIS
-;; #XXLORXXSPLTIB 0   XXSPLTIB -1  VSPLTISW
-;; XXLXOR 0 XXLORC -1P9 const MTVSRWZ  MFVSRWZ
-;; MF%1 MT%0 NOP
+;;  MR   LA
+;;  LWZ  LFIWZX  LXSIWZX
+;;  STW  STFIWX  STXSIWX
+;;  LI   LIS #
+;;  XXLORXXSPLTIB 0  XXSPLTIB -1 VSPLTISW
+;;  XXLXOR 0 XXLORC -1   P9 const
+;;  MTVSRWZ  MFVSRWZ
+;; MF%1 MT%0NOP
+
 (define_insn "*movsi_internal1"
   [(set (match_operand:SI 0 "nonimmediate_operand"
-   "=r, r,   r,   d,   v,
-m,  Z,   Z,   r,   r,
-r,  wa,  wa,  wa,  v,
-wa, v,   v,   wa,  r,
-r,  *h,  *h")
+   "=r,  r,
+r,   d,  v,
+m,   Z,  Z,
+r,   r,  r,
+wa,  wa, wa, v,
+wa,  v,  v,
+wa,  r,
+   r,   *h, *h")
+
(match_operand:SI 1 "input_operand"
-   "r,  U,   m,   Z,   Z,
-r,  d,   v,   I,   L,
-n,  wa,  O,   wM,  wB,
-O,  wM,  wS,  r,   wa,
-*h, r,   0"))]
+"r,  U,
+m,   Z,  Z,
+r,   d,  v,
+I,   L,  n,
+wa,  O,  wM, wB,
+O,   wM, wS,
+r,   wa,
+*h,  r,  0"))]
+
   "gpc_reg_operand (operands[0], SImode)
|| gpc_reg_operand (operands[1], SImode)"
   "@
@@ -6934,23 +6946,41 @@ (define_insn "*movsi_internal1"
mt%0 %1
nop"
   [(set_attr "type"
-   "*,  *,   load,fpload,  fpload,
-store,  fpstore, fpstore, *,   *,
-*,  veclogical,  vecsimple,   vecsimple,   vecsimple,
-veclogical, veclogical,  vecsimple,   mffgpr,  mftgpr,
-*,  *,   *")
+ "*, *,
+ load,   fpload, fpload,
+ store,  fpstore,fpstore,
+ *,  *,  *,
+ veclogical, vecsimple,  vecsimple,  vecsimple,
+ veclogical, veclogical, vecsimple,
+ mffgpr, mftgpr,
+ *,  *,  *")
(set_attr "length"
-   "*,  *,   *,   *,   *,
-*,  *,   *,   *,   *,
-8,  *,   *,   *,   *,
-*,  *,   8,   *,   *,
-*,  *,   *")
+ "*, *,
+ *,  *,   *,
+ *,  *,   

Re: [PATCH] Fix gen_lowpart_for_combine (PR rtl-optimization/92510)

[Segher Boessenkool]

Hi!

On Wed, Nov 27, 2019 at 12:51:35AM +0100, Jakub Jelinek wrote:
> As mentioned in the PR, on the following testcase we ICE during combine.
> We have (subreg:V1DI (ne:DI (reg:CC flags) (const_int 0)) 0) and

A subreg of something that is not a reg (or mem, if your port still does
that) is invalid RTL.  Where this did come from?  Fix that instead?

> gen_lowpart_for_combine turns that into (ne:V1DI (reg:CC flags) (const_int 0))
> which looks wrong to me,

Why would that be wrong?

> transforming
> (subreg:V8QI (ne:DI (reg:CC flags) (const_int 0)) 0)
> into
> (ne:V8QI (reg:CC flags) (const_int 0))
> looks completely broken to me.

The original RTL is invalid already.

The patch should be harmless, but your bug is elsewhere?


Segher

Re: Autoinc vs reload and LRA

[Jeff Law]

On 11/25/19 1:22 PM, Bernd Schmidt wrote:
> So I was curious what would happen if I turned on LRA for m68k. It turns
> out my autoinc patches from the cc0 patch set expose a bug in how LRA
> handles autoincrement. While it copies the logic from reload's
> inc_for_reload, it appears to be missing the find_reloads_address code
> to ensure an autoinc address is reloaded entirely if it is part of a
> jump. LRA can reload just the register inside a POST_INC, which leads to
> creating an output reload.
> 
> Hence, a new version of the autoinc changes, below. Since reload is
> known to work, we allow autoinc in jumps unless targetm.lra_p. One part
> of the patch is a fix for the earlier combine patch which was already
> checked in, the other part is a new version of the auto-inc-dec patch.
> Bootstrapped and tested on the gcc135 machine
> (powerpc64le-unknown-linux-gnu). OK?
This is OK.
jeff

Re: [PATCH] Fix DWARF -g3 with - as source (PR debug/92664)

[Jeff Law]

On 11/26/19 4:45 PM, Jakub Jelinek wrote:
> Hi!
> 
> Without this patch, we emit in .debug_macro with -g3 -xc -
> a .file N "" directive which makes e.g. readelf unhappy.
> Elsewhere, we handle "" filename as "", so this patch does that too
> for .debug_macro.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2019-11-27  Jakub Jelinek  
> 
>   PR debug/92664
>   * dwarf2out.c (lookup_filename): Use "" instead of "".
OK
jeff

[committed] restore a test inadvertently removed in r278621 (PR 92683))

[Martin Sebor]

In r278621 I accidentally removed a test that prevented
an optimization from taking place when it wasn't supposed to,
causing test failures in Jeff's mass rebuilds of downstream
packages (e.g., snapd).  In r278742 I committed the attached
patch, restoring the test.

Martin
PR tree-optimization/92683 - strncmp incorrect result with equal substrings and non-const bound

gcc/testsuite/ChangeLog:

	PR tree-optimization/92683
	* gcc.dg/strcmpopt_8.c: New test.
	* gcc.dg/strcmpopt_9.c: New test.

gcc/ChangeLog:

	PR tree-optimization/92683
	* gimple-fold.c (gimple_fold_builtin_string_compare): Restore a test
	inadvertently removed in a previous change.  Rename local variable
	for clarity.


Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c	(revision 278733)
+++ gcc/gimple-fold.c	(working copy)
@@ -2346,15 +2346,16 @@ gimple_fold_builtin_string_compare (gimple_stmt_it
   tree str1 = gimple_call_arg (stmt, 0);
   tree str2 = gimple_call_arg (stmt, 1);
   tree lhs = gimple_call_lhs (stmt);
-  tree len = NULL_TREE;
+
+  tree bound_node = NULL_TREE;
   unsigned HOST_WIDE_INT bound = HOST_WIDE_INT_M1U;
 
   /* Handle strncmp and strncasecmp functions.  */
   if (gimple_call_num_args (stmt) == 3)
 {
-  len = gimple_call_arg (stmt, 2);
-  if (tree_fits_uhwi_p (len))
-	bound = tree_to_uhwi (len);
+  bound_node = gimple_call_arg (stmt, 2);
+  if (tree_fits_uhwi_p (bound_node))
+	bound = tree_to_uhwi (bound_node);
 }
 
   /* If the LEN parameter is zero, return zero.  */
@@ -2418,6 +2419,9 @@ gimple_fold_builtin_string_compare (gimple_stmt_it
 	case BUILT_IN_STRNCMP:
 	case BUILT_IN_STRNCMP_EQ:
 	  {
+	if (bound == HOST_WIDE_INT_M1U)
+	  break;
+
 	/* Reduce the bound to be no more than the length
 	   of the shorter of the two strings, or the sizes
 	   of the unterminated arrays.  */
Index: gcc/testsuite/gcc.dg/strcmpopt_8.c
===
--- gcc/testsuite/gcc.dg/strcmpopt_8.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/strcmpopt_8.c	(working copy)
@@ -0,0 +1,177 @@
+/* PR tree-optimization/92683 - strncmp incorrect result with equal substrings
+   and nonconst bound
+   { dg-do compile }
+   { dg-options "-O1 -Wall -fdump-tree-forwprop1" } */
+
+#define SIZE_MAX  __SIZE_MAX__
+
+#define S123  "123"
+#define S1234 "1234"
+
+typedef __SIZE_TYPE__ size_t;
+
+#ifndef ident
+#  define ident(n) n
+#endif
+
+extern void failure_on_line (int);
+
+/* Verify that the test in 'if (EQL strncmp (S, T, N))' is folded.  */
+#define T(eql, s, t, n) do {			\
+max = ident (n);\
+if (!(eql __builtin_strncmp (s, t, max)))	\
+  failure_on_line (__LINE__);		\
+  } while (0)
+
+void test_literal (void)
+{
+  size_t max;
+
+  T (0 ==, S123, S1234, 0);
+  T (0 ==, S123, S1234, 1);
+  T (0 ==, S123, S1234, 2);
+  T (0 ==, S123, S1234, 3);
+  T (0 >,  S123, S1234, 4);
+  T (0 >,  S123, S1234, 5);
+  T (0 >,  S123, S1234, SIZE_MAX - 2);
+  T (0 >,  S123, S1234, SIZE_MAX - 1);
+  T (0 >,  S123, S1234, SIZE_MAX);
+
+  T (0 ==, S123 + 1, S1234, 0);
+  T (0 <,  S123 + 1, S1234, 1);
+  T (0 <,  S123 + 1, S1234, 2);
+  T (0 <,  S123 + 1, S1234, 3);
+  T (0 <,  S123 + 1, S1234, 4);
+  T (0 <,  S123 + 1, S1234, SIZE_MAX - 2);
+  T (0 <,  S123 + 1, S1234, SIZE_MAX - 1);
+  T (0 <,  S123 + 1, S1234, SIZE_MAX);
+
+  T (0 ==, S123 + 1, S1234 + 1, 0);
+  T (0 ==, S123 + 1, S1234 + 1, 1);
+  T (0 ==, S123 + 1, S1234 + 1, 2);
+  T (0 >,  S123 + 1, S1234 + 1, 3);
+  T (0 >,  S123 + 1, S1234 + 1, SIZE_MAX - 1);
+  T (0 >,  S123 + 1, S1234 + 1, SIZE_MAX);
+
+  T (0 ==, S123 + 3, S1234 + 1, 0);
+  T (0 >,  S123 + 3, S1234 + 1, 1);
+  T (0 >,  S123 + 3, S1234 + 1, 2);
+  T (0 >,  S123 + 3, S1234 + 1, 3);
+  T (0 >,  S123 + 3, S1234 + 1, SIZE_MAX - 1);
+  T (0 >,  S123 + 3, S1234 + 1, SIZE_MAX);
+
+  int zero = 0;
+
+  T (zero ==, S123, S1234, 0);
+  T (zero ==, S123, S1234, 1);
+  T (zero ==, S123, S1234, 2);
+  T (zero ==, S123, S1234, 3);
+  T (zero >,  S123, S1234, 4);
+  T (zero >,  S123, S1234, 5);
+  T (zero >,  S123, S1234, SIZE_MAX - 2);
+  T (zero >,  S123, S1234, SIZE_MAX - 1);
+  T (zero >,  S123, S1234, SIZE_MAX);
+
+  T (zero ==, S123 + 1, S1234, 0);
+  T (zero <,  S123 + 1, S1234, 1);
+  T (zero <,  S123 + 1, S1234, 2);
+  T (zero <,  S123 + 1, S1234, 3);
+  T (zero <,  S123 + 1, S1234, 4);
+  T (zero <,  S123 + 1, S1234, SIZE_MAX - 2);
+  T (zero <,  S123 + 1, S1234, SIZE_MAX - 1);
+  T (zero <,  S123 + 1, S1234, SIZE_MAX);
+
+  T (zero ==, S123 + 1, S1234 + 1, 0);
+  T (zero ==, S123 + 1, S1234 + 1, 1);
+  T (zero ==, S123 + 1, S1234 + 1, 2);
+  T (zero >,  S123 + 1, S1234 + 1, 3);
+  T (zero >,  S123 + 1, S1234 + 1, SIZE_MAX - 1);
+  T (zero >,  S123 + 1, S1234 + 1, SIZE_MAX);
+
+  T (zero ==, S123 + 3, S1234 + 1, 0);
+  T (zero >,  S123 + 3, S1234 + 1, 1);
+  T (zero >,  S123 + 3, S1234 + 1, 2);
+  T (zero >,  S123 + 3, S1234 + 1, 3);
+  T (zero >,  S123 + 3, S1234 + 1, 

[PATCH] Fix spread simplification in initializers (PR fortran/91944)

[Jakub Jelinek]

Hi!

The following testcase started ICEing with my r241630 PR78026 fix.
Before we created a new namespace and the check gfc_simplify_spread did
happened to work during that, but it doesn't anymore.
I believe gfc_init_expr_flag is the right flag to use when checking if
something has to be folded at compile time and we can't defer it to runtime
expansion.

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

2019-11-27  Jakub Jelinek  

PR fortran/91944
* simplify.c (gfc_simplify_spread): Check gfc_init_expr_flag instead
of gfc_current_ns->sym_root->n.sym->attr.flavor == FL_PARAMETER.

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

--- gcc/fortran/simplify.c.jj   2019-11-25 22:44:26.127328111 +0100
+++ gcc/fortran/simplify.c  2019-11-26 17:32:26.963525721 +0100
@@ -7656,7 +7656,7 @@ gfc_simplify_spread (gfc_expr *source, g
   nelem = mpz_get_si (size) * ncopies;
   if (nelem > flag_max_array_constructor)
 {
-  if (gfc_current_ns->sym_root->n.sym->attr.flavor == FL_PARAMETER)
+  if (gfc_init_expr_flag)
{
  gfc_error ("The number of elements (%d) in the array constructor "
 "at %L requires an increase of the allowed %d upper "
--- gcc/testsuite/gfortran.dg/spread_size_limit_2.f90.jj2019-11-26 
17:47:25.578719250 +0100
+++ gcc/testsuite/gfortran.dg/spread_size_limit_2.f90   2019-11-26 
17:40:48.881815325 +0100
@@ -0,0 +1,11 @@
+! PR fortran/91944
+! { dg-do compile }
+! { dg-options "-fmax-array-constructor=65535" }
+
+program pr91944
+  integer, parameter :: n = 10
+  integer, parameter :: m = 65536
+  integer :: i
+  integer :: x(n,m) = spread([(i,i=1,n)], dim=2, ncopies=m)! { dg-error 
"requires an increase of the allowed 65535 upper limit" }
+  print *, x(n,m)
+end

Jakub

[PATCH] Fix gen_lowpart_for_combine (PR rtl-optimization/92510)

[Jakub Jelinek]

Hi!

As mentioned in the PR, on the following testcase we ICE during combine.
We have (subreg:V1DI (ne:DI (reg:CC flags) (const_int 0)) 0) and
gen_lowpart_for_combine turns that into (ne:V1DI (reg:CC flags) (const_int 0))
which looks wrong to me, later on the if_then_else simplifications try to
simplify (subreg:V1DI (const_int 1) 0) with DImode as the inner mode and
native_encode_rtx ICEs.
As gen_lowpart_for_combine exits early for imode == omode, I think the
optimization to change the type of comparison is only useful for scalar
integral modes, for say vector modes we need the element mode to be the same
as well as the number of units to be meaningful, say
transforming
(subreg:V8QI (ne:DI (reg:CC flags) (const_int 0)) 0)
into
(ne:V8QI (reg:CC flags) (const_int 0))
looks completely broken to me.

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

2019-11-27  Jakub Jelinek  

PR rtl-optimization/92510
* combine.c (gen_lowpart_for_combine): Only transform lowpart subreg
of comparison into a comparison with different mode if both imode and
omode are scalar integral modes.

* gcc.dg/pr92510.c: New test.

--- gcc/combine.c.jj2019-11-25 11:33:41.538074339 +0100
+++ gcc/combine.c   2019-11-26 15:55:35.433676263 +0100
@@ -11808,7 +11808,9 @@ gen_lowpart_for_combine (machine_mode om
 
   /* If X is a comparison operator, rewrite it in a new mode.  This
  probably won't match, but may allow further simplifications.  */
-  else if (COMPARISON_P (x))
+  else if (COMPARISON_P (x)
+  && SCALAR_INT_MODE_P (imode)
+  && SCALAR_INT_MODE_P (omode))
 return gen_rtx_fmt_ee (GET_CODE (x), omode, XEXP (x, 0), XEXP (x, 1));
 
   /* If we couldn't simplify X any other way, just enclose it in a
--- gcc/testsuite/gcc.dg/pr92510.c.jj   2019-11-26 16:04:17.492688012 +0100
+++ gcc/testsuite/gcc.dg/pr92510.c  2019-11-26 15:52:28.035538275 +0100
@@ -0,0 +1,16 @@
+/* PR rtl-optimization/92510 */
+/* { dg-do compile } */
+/* { dg-options "-O1 -ftree-loop-vectorize -fno-forward-propagate 
-fno-tree-scev-cprop" } */
+
+int v;
+
+long int
+foo (long int x)
+{
+  signed char i;
+
+  for (i = 0; i < 8; ++i)
+x |= !!v;
+
+  return x + i;
+}

Jakub

[PATCH] Fix DWARF -g3 with - as source (PR debug/92664)

[Jakub Jelinek]

Hi!

Without this patch, we emit in .debug_macro with -g3 -xc -
a .file N "" directive which makes e.g. readelf unhappy.
Elsewhere, we handle "" filename as "", so this patch does that too
for .debug_macro.

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

2019-11-27  Jakub Jelinek  

PR debug/92664
* dwarf2out.c (lookup_filename): Use "" instead of "".

--- gcc/dwarf2out.c.jj  2019-10-17 08:44:08.594363833 +0200
+++ gcc/dwarf2out.c 2019-11-26 12:35:46.419184285 +0100
@@ -27118,6 +27118,9 @@ lookup_filename (const char *file_name)
   if (!file_name)
 return NULL;
 
+  if (!file_name[0])
+file_name = "";
+
   dwarf_file_data **slot
 = file_table->find_slot_with_hash (file_name, htab_hash_string (file_name),
   INSERT);

Jakub

[C++ PATCH] Fix ICE in build_ctor_subob_ref during replace_placeholders (PR c++/92524, take 2)

[Jakub Jelinek]

On Tue, Nov 26, 2019 at 04:58:01PM -0500, Jason Merrill wrote:
> Hmm, we shouldn't have any PLACEHOLDER_EXPR under a RANGE_EXPR; if we did,
> any references to its address would end up all referring to the first
> element of the range, which would be wrong.  How about skipping RANGE_EXPR
> in replace_placeholders_r?

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

2019-11-27  Jakub Jelinek  

PR c++/92524
* tree.c (replace_placeholders_r): Don't walk constructor elts with
RANGE_EXPR indexes.

* g++.dg/cpp0x/pr92524.C: New test.

--- gcc/cp/tree.c.jj2019-11-26 23:09:55.904101392 +0100
+++ gcc/cp/tree.c   2019-11-26 23:13:14.308070759 +0100
@@ -3144,6 +3144,11 @@ replace_placeholders_r (tree* t, int* wa
tree type = TREE_TYPE (*valp);
tree subob = obj;
 
+   /* Elements with RANGE_EXPR index shouldn't have any
+  placeholders in them.  */
+   if (ce->index && TREE_CODE (ce->index) == RANGE_EXPR)
+ continue;
+
if (TREE_CODE (*valp) == CONSTRUCTOR
&& AGGREGATE_TYPE_P (type))
  {
--- gcc/testsuite/g++.dg/cpp0x/pr92524.C.jj 2019-11-26 23:09:46.810240310 
+0100
+++ gcc/testsuite/g++.dg/cpp0x/pr92524.C2019-11-26 23:09:46.810240310 
+0100
@@ -0,0 +1,12 @@
+// PR c++/92524
+// { dg-do compile { target c++11 } }
+
+struct A { char a = '*'; };
+struct B { A b[64]; };
+
+void
+foo ()
+{
+  A a;
+  B{a};
+}

Jakub

Re: [PATCH], V7, #7 of 7, Turn on -mpcrel for Linux 64-bit, but not for other targets

[Segher Boessenkool]

On Thu, Nov 14, 2019 at 06:14:47PM -0500, Michael Meissner wrote:
>   * config/rs6000/linux64.h (TARGET_PREFIXED_ADDR_DEFAULT): Enable
>   prefixed addressing by default.
>   (TARGET_PCREL_DEFAULT): Enable pc-relative addressing by default.
>   * config/rs6000/rs6000-cpus.def (ISA_FUTURE_MASKS_SERVER): Only
>   enable -mprefixed-addr and -mpcrel if the OS tm.h says to enable
>   it.
>   (ADDRESSING_FUTURE_MASKS): New mask macro.
>   (OTHER_FUTURE_MASKS): Use ADDRESSING_FUTURE_MASKS.
>   * config/rs6000/rs6000.c (TARGET_PREFIXED_ADDR_DEFAULT): Do not
>   enable -mprefixed-addr unless the OS tm.h says to.
>   (TARGET_PCREL_DEFAULT): Do not enable -mpcrel unless the OS tm.h
>   says to.
>   (rs6000_option_override_internal): Do not enable -mprefixed-addr
>   or -mpcrel unless the OS tm.h says to enable it.  Add more checks
>   for -mcpu=future.

> +/* Support for a future processor's features.  The prefixed and pc-relative
> +   addressing bits are not added here.  Instead, rs6000.c adds them if the OS
> +   tm.h says that it supports the addressing modes.  */

This comment could be a lot clearer.  It should just say it is about
ADRESSING_FUTURE_MASKS, and not mention rs6000.c at all.

>  #define ISA_FUTURE_MASKS_SERVER  (ISA_3_0_MASKS_SERVER   
> \
> -  | OPTION_MASK_FUTURE   \
> +  | OPTION_MASK_FUTURE)
> +
> +/* Addressing related flags on a future processor.  These flags are broken 
> out
> +   because not all targets will support either pc-relative addressing, or 
> even
> +   prefixed addressing, and we want to clear all of the addressing bits
> +   on targets that cannot support prefixed/pcrel addressing.  */
> +#define ADDRESSING_FUTURE_MASKS  (OPTION_MASK_PCREL  
> \
>| OPTION_MASK_PREFIXED_ADDR)

> --- gcc/config/rs6000/rs6000.c(revision 278181)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@ -98,6 +98,16 @@
>  #endif
>  #endif
>  
> +/* Set up the defaults for whether prefixed addressing is used, and if it is
> +   used, whether we want to turn on pc-relative support by default.  */
> +#ifndef TARGET_PREFIXED_ADDR_DEFAULT
> +#define TARGET_PREFIXED_ADDR_DEFAULT 0
> +#endif
> +
> +#ifndef TARGET_PCREL_DEFAULT
> +#define TARGET_PCREL_DEFAULT 0
> +#endif

"DEFAULT" is a bad name for this?  "SUPPORTED"?

We do *not* turn on prefixed or pcrel by default on most linux64 targets
-- most of those are p9 or p8 or p7 or older!  So "SUPPORTED" isn't good
either.  SUPPORTED_BY_OS?

A name like "XXX_DEFAULT" inevitably means we will later get an
"XXX_REALLY_DEFAULT" macro as well.  Not good.

> +  /* Enable prefixed addressing and pc-relative addressing on 64-bit ELF v2
> + systems if the OS tm.h file says that it is supported and the user did 
> not
> + explicitly use -mprefixed-addr or -mpcrel.  At the present time, only
> + 64-bit Linux enables this.


> +  /* Enable defaults if desired.  */

This comment does not say anything.  Please say something like "Enable
PCREL and PREFIXED if [...]"

> +  else
> + {
> +   if (!explicit_prefixed
> +   && (TARGET_PREFIXED_ADDR_DEFAULT
> +   || TARGET_PCREL
> +   || TARGET_PCREL_DEFAULT))
> + rs6000_isa_flags |= OPTION_MASK_PREFIXED_ADDR;
> +
> +   if (!explicit_pcrel && TARGET_PCREL_DEFAULT
> +   && TARGET_CMODEL == CMODEL_MEDIUM)
> + rs6000_isa_flags |= OPTION_MASK_PCREL;
> + }
> +}

... and I don't understand this code.  If you use -mpcrel but you do not
have the medium model, you _do_ get prefixed but you do _not_ get pcrel?
And this all quietly?


Segher

Re: [PATCH 2/4] The main m68k cc0 conversion

[Joseph Myers]

On Tue, 26 Nov 2019, Bernd Schmidt wrote:

> On 11/26/19 3:21 AM, Joseph Myers wrote:
> > 
> > The soft-float ColdFire build (--with-arch=cf --with-cpu=54455 
> > --disable-multilib) successfully built libgcc and glibc, but ran into an 
> > ICE building the glibc tests.  Again, I've not bisected but this commit 
> > seems likely to be responsible.  Compile the attached preprocessed source 
> > with -O2.
> 
> Try the following. This seems to be the same (preexisting) problem which
> got fixed for the normal 68k compare patterns, where an operand with
> nonimmediate_operand predicate allows constants in its constraints.

I confirm that this and the previous patch together allow both the 
ColdFire configurations in build-many-glibcs.py to complete clean builds 
of GCC, glibc and glibc tests.

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

Re: [PATCH] Fix libstdc++ compiling for an aarch64 multilib with big-endian.

[Jonathan Wakely]

On 26/11/19 22:22 +, Richard Sandiford wrote:

+ libstd...@gcc.gnu.org

 writes:

From: Andrew Pinski 

Hi if we have a aarch64 compiler that has a big-endian
multi-lib, it fails to compile libstdc++ because
simd_fast_mersenne_twister_engine is only defined for little-endian
in ext/random but ext/opt_random.h thinks it is defined always.

OK?  Built an aarch64-elf toolchain which has a big-endian multi-lib enabled.


Looks good to me in the sense that I see the same preprocessor
conditions you see.  OK if no libstdc++ maintainer tells us it's
the wrong fix in the next 24 hrs.


Looks right.

The #if could even be moved earlier, as the __VEXT macros don't seem
to be used anywhere except that file. If most of the file gets skipped
for big endian, that macro isn't needed either (and it looks like the
__ARM_BIG_ENDIAN version of it is never used at all).

No harm leaving the macro though, so as far as I'm concerned the patch
is fine.

Re: [PATCH/AARCH64] Generate FRINTZ for (double)(long) under -ffast-math on aarch64

[Richard Sandiford]

Andrew Pinski  writes:
> On Fri, Aug 18, 2017 at 12:17 PM Andrew Pinski  wrote:
>>
>> Like https://gcc.gnu.org/ml/gcc-patches/2010-09/msg00060.html for
>> PowerPC, we should do something similar for aarch64.  This pattern
>> does show up in SPEC CPU 2006 in astar but I did not look into
>> performance improvement of it though.
>>
>> OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.
>
> Ping?  I has been over 2 years now too.

I think it'd better to do this in match.pd, folding to IFN_TRUNC.
The rule will then automatically check whether the target supports
IFN_TRUNC/btrunc_optab for the required mode.

Thanks,
Richard

Re: [PATCH] Fix libstdc++ compiling for an aarch64 multilib with big-endian.

[Richard Sandiford]

+ libstd...@gcc.gnu.org

 writes:
> From: Andrew Pinski 
>
> Hi if we have a aarch64 compiler that has a big-endian
> multi-lib, it fails to compile libstdc++ because
> simd_fast_mersenne_twister_engine is only defined for little-endian
> in ext/random but ext/opt_random.h thinks it is defined always.
>
> OK?  Built an aarch64-elf toolchain which has a big-endian multi-lib enabled.

Looks good to me in the sense that I see the same preprocessor
conditions you see.  OK if no libstdc++ maintainer tells us it's
the wrong fix in the next 24 hrs.

Thanks,
Richard

>
> Thanks,
> Andrew Pinski
>
> libstdc++/ChangeLog:
> * config/cpu/aarch64/opt/ext/opt_random.h: Wrap around with check
> for little-endian like ext/random is done.
>
> Signed-off-by: Andrew Pinski 
> ---
>  libstdc++-v3/config/cpu/aarch64/opt/ext/opt_random.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libstdc++-v3/config/cpu/aarch64/opt/ext/opt_random.h 
> b/libstdc++-v3/config/cpu/aarch64/opt/ext/opt_random.h
> index 696a6d18ab4..9eca9b7df74 100644
> --- a/libstdc++-v3/config/cpu/aarch64/opt/ext/opt_random.h
> +++ b/libstdc++-v3/config/cpu/aarch64/opt/ext/opt_random.h
> @@ -44,6 +44,7 @@
>   _C+8, _C+9, _C+10, _C+11, _C+12, _C+13, _C+14, _C+15})
>  #endif
>  
> +#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
>  namespace __gnu_cxx _GLIBCXX_VISIBILITY (default)
>  {
>  _GLIBCXX_BEGIN_NAMESPACE_VERSION
> @@ -175,6 +176,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  _GLIBCXX_END_NAMESPACE_VERSION
>} // namespace
>  
> +#endif // __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
>  #endif // __ARM_NEON
>  
>  #endif // _EXT_OPT_RANDOM_H

Re: [vect][testsuite] Update vect_char_add target selector to use its own cache

[Richard Sandiford]

Joel Hutton  writes:
> Hi all,
>
> This patch updates the vect_char_add target selector to use its own 
> cache instead of the vect_int cache.
>
> This was causing a situation where bb-slp-40.c would fail on sparc when 
> run after other tests that use the vect_int target selector, but pass 
> when run on its own.
>
> This fixes Bug 92391
>
> Tested on x86 and sparc64.
>
> 2019-11-26  Joel Hutton  
>
>      * lib/target-supports.exp: Update vect_char_add target selector 
> to use its own cache.

Thanks, applied as r278738.

Richard

>
> From 7ed08950f4440f8605b9df1114edcc8ee834 Mon Sep 17 00:00:00 2001
> From: Joel Hutton 
> Date: Tue, 26 Nov 2019 17:09:12 +
> Subject: [PATCH] Update vect_char_add target selector to use its own cache
>
> ---
>  gcc/testsuite/lib/target-supports.exp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index 
> 5fe1e83492cae97adf82ed53e12d8f5f7ea5a951..a4418a3151677a2a45275463b9828db7e7755b28
>  100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -5753,7 +5753,7 @@ proc check_effective_target_vect_bswap { } {
>  # one vector length.
>  
>  proc check_effective_target_vect_char_add { } {
> -return [check_cached_effective_target_indexed vect_int {
> +return [check_cached_effective_target_indexed vect_char_add {
>expr {
>   [istarget i?86-*-*] || [istarget x86_64-*-*]
>   || ([istarget powerpc*-*-*]

Re: [C++ PATCH] Fix ICE in build_ctor_subob_ref during replace_placeholders (PR c++/92524)

[Jason Merrill]

On 11/22/19 9:19 AM, Jakub Jelinek wrote:

Hi!

On the following testcase, replace_placeholders is called on a CONSTRUCTOR
{ a, [1..63] = NON_LVALUE_EXPR<42> }
and call build_ctor_subob_ref in that case.  The problem is that index is
RANGE_EXPR and as it is not INTEGER_CST, we call
build_class_member_access_expr which is not appropriate for array indexes.
cp_build_array_ref will not really work with RANGE_EXPR either, the
following patch just usesthe low bound of the range.  At least when trying
to read it, it should be equivalent to any other value in the range.


Hmm, we shouldn't have any PLACEHOLDER_EXPR under a RANGE_EXPR; if we 
did, any references to its address would end up all referring to the 
first element of the range, which would be wrong.  How about skipping 
RANGE_EXPR in replace_placeholders_r?



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



2019-11-22  Jakub Jelinek  

PR c++/92524
* tree.c (build_ctor_subob_ref): For RANGE_EXPR index, build
array reference for the low bound.

* g++.dg/cpp0x/pr92524.C: New test.

--- gcc/cp/tree.c.jj2019-11-16 18:13:28.571821577 +0100
+++ gcc/cp/tree.c   2019-11-21 12:22:27.260660874 +0100
@@ -3064,6 +3064,10 @@ build_ctor_subob_ref (tree index, tree t
  obj = NULL_TREE;
else if (TREE_CODE (index) == INTEGER_CST)
  obj = cp_build_array_ref (input_location, obj, index, tf_none);
+  else if (TREE_CODE (index) == RANGE_EXPR)
+/* Use low bound for ranges.  */
+obj = cp_build_array_ref (input_location, obj, TREE_OPERAND (index, 0),
+ tf_none);
else
  obj = build_class_member_access_expr (obj, index, NULL_TREE,
  /*reference*/false, tf_none);
--- gcc/testsuite/g++.dg/cpp0x/pr92524.C.jj 2019-11-21 12:34:53.350406680 
+0100
+++ gcc/testsuite/g++.dg/cpp0x/pr92524.C2019-11-21 12:34:18.943925681 
+0100
@@ -0,0 +1,12 @@
+// PR c++/92524
+// { dg-do compile { target c++11 } }
+
+struct A { char a = '*'; };
+struct B { A b[64]; };
+
+void
+foo ()
+{
+  A a;
+  B{a};
+}

Jakub

Re: [PATCH][_GLIBCXX_DEBUG] Improve valid_range check

[Jonathan Wakely]

On 26/11/19 20:07 +0100, François Dumont wrote:

On 11/26/19 1:21 PM, Jonathan Wakely wrote:

On 26/11/19 12:33 +0100, Stephan Bergmann wrote:

On 22/11/2019 18:59, Jonathan Wakely wrote:

On 22/11/19 18:38 +0100, François Dumont wrote:
    I noticed that we are not checking that iterators are not 
singular in valid_range. Moreover __check_singular signature 
for pointers is not intercepting all kind of pointers in terms 
of qualification.


    I'd like to commit it next week but considering we are in 
stage 3 I need proper acceptance.


    * include/debug/functions.h: Remove  include.
    (__check_singular_aux, __check_singular): Move...
    * include/debug/helper_functions.h:
    (__check_singular_aux, __check_singular): ...here.
    (__valid_range_aux): Adapt to use latter.
    * testsuite/25_algorithms/copy/debug/2_neg.cc: New.

Tested under Linux x86_64 normal and debug modes.


OK for trunk, thanks.


The curly braces...

diff --git a/libstdc++-v3/include/debug/helper_functions.h 
b/libstdc++-v3/include/debug/helper_functions.h

index c3e7478f649..5a858754875 100644
--- a/libstdc++-v3/include/debug/helper_functions.h
+++ b/libstdc++-v3/include/debug/helper_functions.h

[...]

@@ -138,14 +156,23 @@ namespace __gnu_debug
    inline bool
    __valid_range_aux(_InputIterator __first, _InputIterator __last,
  std::input_iterator_tag)
-    { return true; }
+    {
+  if (__first != __last)
+    return !__check_singular(__first) && !__check_singular(__last);
+
+  return true;
+    }
  template
    _GLIBCXX_CONSTEXPR
    inline bool
    __valid_range_aux(_InputIterator __first, _InputIterator __last,
  std::random_access_iterator_tag)
-    { return __first <= __last; }
+    {
+  return
+    __valid_range_aux(__first, __last, std::input_iterator_tag{})


...^^^ here...


+    && __first <= __last;
+    }
  /** We have iterators, so figure out what kind of iterators they are
   *  to see if we can check the range ahead of time.
@@ -167,6 +194,9 @@ namespace __gnu_debug
  typename _Distance_traits<_InputIterator>::__type& 
__dist,

  std::__false_type)
    {
+  if (!__valid_range_aux(__first, __last, 
std::input_iterator_tag{}))


...and ^^^ here are not allowed pre C++11.  Replacing those with

 std::input_iterator_tag()

should fix it.


Indeed. We should also have tests that use "-std=gnu++98
-D_GLIBCXX_DEBUG" so they'd catch this.

François, can you take care of the fix please?




Sure, I am about to do so.

However I wasn't sure about this syntax before the commit so I had run 
the new 2_neg.cc with:


make CXXFLAGS=-std=c++98 check-debug

and it worked fine and still is !


The testsuite doesn't use CXXFLAGS.


I also try -std=gnu++98 and made sure that pch had been updated by 
re-building libstdc++ first. I just can't get the expected compilation 
error.


Maybe I need to rebuild the whole stuff to get an error...


No, you need to pass the right flags so they are used by the
testsuite. This will do it:

make -C testsuite/  check-debug 
debug_flags=unix/-D_GLIBCXX_DEBUG/-std=gnu++98/-Wsystem-headers

But since it only shows up with -Wsystem-headers, there's no point
trying to test for it.

Re: [C++ PATCH] Fix up parsing of attribute-argument-clause of unknown attributes (PR c++/92648)

[Jason Merrill]

On 11/25/19 6:41 PM, Jakub Jelinek wrote:

Hi!

The standard says that argument-attribute-clause is:
attribute-argument-clause:
( balanced-token-seq[opt] )
balanced-token-seq:
balanced-token
balanced-token-seq balanced-token
balanced-token:
( balanced-token-seq[opt] )
[ balanced-token-seq[opt] ]
{ balanced-token-seq[opt] }
any token other than a parenthesis, a bracket, or a brace
but the C++ FE parses the attribute arguments always as an expression list
with the exception of identifier kept as is in certain cases.
That is just fine for all attributes we support right now, but what
arguments can have attributes of other compilers or not yet invented
attributes and how they should be parsed is unknown, so the only option is
IMHO to skip the balanced token set.  That is also what the C FE does and
what e.g. clang++ seems to do.

I'm not using cp_parser_skip_to_closing_parenthesis in the patch, because
cp_parser_skip_to_closing_parenthesis_1 has code to handle ?: specially and
I believe given the current grammar and that the argument doesn't have to be
necessarily an expression it is wrong, e.g.
[[whatever::whatever_else(???)]] could in theory be valid.

The primary reason for this change is that OpenMP 5.1 is likely going to
have some form of [[omp::... (arguments)]] attributes and the arguments
being considered there would be rejected by the current parser.

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


OK.


2019-11-26  Jakub Jelinek  

PR c++/92648
* parser.c (cp_parser_std_attribute): For unknown attributes,
skip balanced token seq instead of trying to parse
attribute-argument-clause as expression list.  Formatting fix.

* g++.dg/cpp0x/gen-attrs-71.C: New test.

--- gcc/cp/parser.c.jj  2019-11-22 09:33:08.899909913 +0100
+++ gcc/cp/parser.c 2019-11-25 18:29:06.230699448 +0100
@@ -26629,6 +26629,15 @@ cp_parser_std_attribute (cp_parser *pars
/* A GNU attribute that takes an identifier in parameter.  */
attr_flag = id_attr;
  
+if (as == NULL)

+  {
+   /* For unknown attributes, just skip balanced tokens instead of
+  trying to parse the arguments.  */
+   for (size_t n = cp_parser_skip_balanced_tokens (parser, 1) - 1; n; --n)
+ cp_lexer_consume_token (parser->lexer);
+   return attribute;
+  }
+
  vec = cp_parser_parenthesized_expression_list
(parser, attr_flag, /*cast_p=*/false,
 /*allow_expansion_p=*/true,
@@ -26637,7 +26646,7 @@ cp_parser_std_attribute (cp_parser *pars
arguments = error_mark_node;
  else
{
-   if (vec->is_empty())
+   if (vec->is_empty ())
  /* e.g. [[attr()]].  */
  error_at (token->location, "parentheses must be omitted if "
"%qE attribute argument list is empty",
--- gcc/testsuite/g++.dg/cpp0x/gen-attrs-71.C.jj2019-11-25 
18:22:09.486082583 +0100
+++ gcc/testsuite/g++.dg/cpp0x/gen-attrs-71.C   2019-11-25 18:31:14.695730765 
+0100
@@ -0,0 +1,7 @@
+// PR c++/92648
+// { dg-do compile { target c++11 } }
+
+int a [[gnu::no_such_attribute(![!(!)!]!,;;)]];// { dg-warning 
"ignored" }
+int b [[no_such_namespace::nonexisting_attribute(linear(c, d : 2), reduction(*:e), 
linear(uval (f)))]];// { dg-warning "ignored" }
+int c [[gnu::nonexisting_attribute()]];// { dg-warning "ignored" }
+int d [[gnu::another_nonexistent_attr(1,"abcd",g+6)]];   // { dg-warning 
"ignored" }

Jakub

Re: [C++ PATCH] Fix up is too small to hold all values of enum warning (PR c++/61414)

[Jason Merrill]

On 11/25/19 6:32 PM, Jakub Jelinek wrote:

Hi!

On Mon, Nov 25, 2019 at 03:46:23PM +0100, Jakub Jelinek wrote:

On Mon, Nov 25, 2019 at 03:39:32PM +0100, Jakub Jelinek wrote:

I guess the question is, shall we store the minimum precision needed
somewhere by finish_enum_value_list (perhaps only bother if the precision
of the underlying type is not the same) or compute it each time again
(which would mean for each bitfield of enum type walk the list of all the
enum values)?  And, if we should store it somewhere, any preferences where?
These days C++ FE has TYPE_LANG_SPECIFIC just for classes, so options are
just use the class TYPE_LANG_SPECIFIC and just stick the min/max values in
some trees in there, restore having different lang specific variants and
store just minimum precision in there, add hash map from tree (hashed using
TYPE_UID) to precision, something else?


Or yet another possibility, only compute it on demand and use a hash map as
cache.


Here is that option implemented, bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?


OK, thanks.


2019-11-26  Jakub Jelinek  

PR c++/61414
* c-attribs.c (handle_mode_attribute): Add mode attribute to
ENUMERAL_TYPEs.

* class.c (enum_to_min_precision): New hash_map.
(enum_min_precision): New function.
(check_bitfield_decl): Use it.

* g++.dg/cpp0x/enum23.C: Remove xfail.
* g++.dg/cpp0x/enum28.C: New test.

--- gcc/c-family/c-attribs.c.jj 2019-11-23 11:05:50.813492164 +0100
+++ gcc/c-family/c-attribs.c2019-11-25 16:47:35.317750531 +0100
@@ -1866,6 +1866,7 @@ handle_mode_attribute (tree *node, tree
typefm = make_signed_type (TYPE_PRECISION (typefm));
  TREE_TYPE (typefm) = type;
}
+ *no_add_attrs = false;
}
else if (VECTOR_MODE_P (mode)
   ? TREE_CODE (type) != TREE_CODE (TREE_TYPE (typefm))
--- gcc/cp/class.c.jj   2019-11-16 18:13:42.844606979 +0100
+++ gcc/cp/class.c  2019-11-25 16:42:15.050633229 +0100
@@ -3265,6 +3265,60 @@ add_implicitly_declared_members (tree t,
  }
  }
  
+/* Cache of enum_min_precision values.  */

+static GTY((deletable)) hash_map *enum_to_min_precision;
+
+/* Return the minimum precision of a bit-field needed to store all
+   enumerators of ENUMERAL_TYPE TYPE.  */
+
+static int
+enum_min_precision (tree type)
+{
+  type = TYPE_MAIN_VARIANT (type);
+  /* For unscoped enums without fixed underlying type and without mode
+ attribute we can just use precision of the underlying type.  */
+  if (UNSCOPED_ENUM_P (type)
+  && !ENUM_FIXED_UNDERLYING_TYPE_P (type)
+  && !lookup_attribute ("mode", TYPE_ATTRIBUTES (type)))
+return TYPE_PRECISION (ENUM_UNDERLYING_TYPE (type));
+
+  if (enum_to_min_precision == NULL)
+enum_to_min_precision = hash_map::create_ggc (37);
+
+  bool existed;
+  int prec = enum_to_min_precision->get_or_insert (type, );
+  if (existed)
+return prec;
+
+  tree minnode, maxnode;
+  if (TYPE_VALUES (type))
+{
+  minnode = maxnode = NULL_TREE;
+  for (tree values = TYPE_VALUES (type);
+  values; values = TREE_CHAIN (values))
+   {
+ tree decl = TREE_VALUE (values);
+ tree value = DECL_INITIAL (decl);
+ if (value == error_mark_node)
+   value = integer_zero_node;
+ if (!minnode)
+   minnode = maxnode = value;
+ else if (tree_int_cst_lt (maxnode, value))
+   maxnode = value;
+ else if (tree_int_cst_lt (value, minnode))
+   minnode = value;
+   }
+}
+  else
+minnode = maxnode = integer_zero_node;
+
+  signop sgn = tree_int_cst_sgn (minnode) >= 0 ? UNSIGNED : SIGNED;
+  int lowprec = tree_int_cst_min_precision (minnode, sgn);
+  int highprec = tree_int_cst_min_precision (maxnode, sgn);
+  prec = MAX (lowprec, highprec);
+  return prec;
+}
+
  /* FIELD is a bit-field.  We are finishing the processing for its
 enclosing type.  Issue any appropriate messages and set appropriate
 flags.  Returns false if an error has been diagnosed.  */
@@ -3326,7 +3380,7 @@ check_bitfield_decl (tree field)
"width of %qD exceeds its type", field);
else if (TREE_CODE (type) == ENUMERAL_TYPE)
{
- int prec = TYPE_PRECISION (ENUM_UNDERLYING_TYPE (type));
+ int prec = enum_min_precision (type);
  if (compare_tree_int (w, prec) < 0)
warning_at (DECL_SOURCE_LOCATION (field), 0,
"%qD is too small to hold all values of %q#T",
--- gcc/testsuite/g++.dg/cpp0x/enum23.C.jj  2013-02-16 09:31:06.400506406 
+0100
+++ gcc/testsuite/g++.dg/cpp0x/enum23.C 2019-11-25 16:51:19.532332223 +0100
@@ -5,5 +5,5 @@ enum class MyEnum { A = 1 };
  
  struct MyClass

  {
-  MyEnum Field1 : 3; // { dg-bogus "warning: 'MyClass::Field1' is too small" 
"" { xfail *-*-* } }
+  MyEnum Field1 : 3; // { dg-bogus "warning: 'MyClass::Field1' is too small" }
  };
--- 

Re: [C++ Patch] More accurate locations in cp_build_unary_op and cp_build_compound_expr

[Jason Merrill]

On 11/25/19 3:34 PM, Paolo Carlini wrote:

Hi,

a bunch of straightforward tweaks: let's use the available location in 
some additional places. Tested x86_64-linux, as usual.


Thanks, Paolo.

///


OK.

Re: [PATCH] Prevent recursive satisfaction (PR c++/88395)

[Jason Merrill]

On 11/18/19 10:18 AM, Andrew Sutton wrote:

I forgot to mention a somewhat odd test included in the patch:
concepts-recursive-sat3.C does not recurse. Code follows:

template
concept Fooable = requires(T t) { foo(t); };

template
void foo(T t) { }

void test()
{
   foo(0); // { dg-error "unsatisfied constraints" }
}

It doesn't crash, but it doesn't diagnose also doesn't fail as a
result of recursive instantiation. The recursive-sat2.C test is the
same except that it instantiates foo with a class type. This seems
like it might be related to ADL, but entirely certain.


Yes; since 0 has non-class type, we don't do ADL to find a declaration 
of foo, and there were no declarations of foo before the call in 
Fooable, so the call fails.


Jason

[Patch] PR 92463 - Cleanups due to minimum MPFR version bump to 3.1.0

[Tobias Burnus]

Recently, Janne bumped the minimal MPFR version from 2.4 to 3.1. As a 
follow-up cleanup, the mp_ data types can now be changed to mpfr_ and 
GMP_RNDx rounding to MPFR_RNDx (with an additional MPFR_RNDA).


This patch changes the types in the middle end and a left over from 
previous patch round in Fortran. However, I have not touched the MPFR 
users in GO.


See https://www.mpfr.org/mpfr-3.0.0/#changes for the 2.4 to 3.0 changes. 
("mp_rnd_t may be removed in the future").


Bootstrapped and regtested on x86-64-gnu-linux.
OK for the trunk?

Tobias

	PR middle-end/92463
	* configure.ac: Use MPFR_RNDN instead of GMP's MP_RNDN.
	* configure: Regenerate

	gcc/
	PR middle-end/92463
	* builtins.c (do_mpfr_ckconv, do_mpc_ckconv, do_mpfr_remquo,
	do_mpfr_lgamma_r, do_mpc_arg2): Use MPFR_RNDx instead of GMP_RNDx,
	mpfr_rnd_t instead of mp_rnd_t.
	* fold-const-call.c (do_mpfr_ckconv, do_mpfr_arg1, do_mpfr_sincos,
	do_mpfr_arg2, do_mpfr_arg3, do_mpc_arg1, do_mpc_arg2): Likewise.
	* gimple-ssa-sprintf.c (format_floating_max, format_floating):
	Use mpfr_exp_t instead of mp_exp_t.
	* real.c (real_from_string, dconst_e_ptr, dconst_sqrt2_ptr): Use
	MPFR_RNDx instead of GMP_RNDx.
 	* realmpfr.c (real_from_mpfr, mpfr_from_real): Use mpfr_rnd_t and
	mpfr_exp_t instead mp_rnd_t and mp_exp_t, respectively.
	* realmpfr.h (real_from_mpfr, mpfr_from_real): Use mpfr_rnd_t instead
	of mp_rnd_t and remove MPFR_RNDx poisoning.
	* ubsan.c (ubsan_instrument_float_cast): MPFR_RNDx instead of GMP_RNDx.

	fortran/
	PR middle-end/92463
	* arith.c (gfc_check_real_range): Replace mp_exp_t by mpfr_exp_t.

diff --git a/configure b/configure
index 00f7487e2e9..f6027397ced 100755
--- a/configure
+++ b/configure
@@ -5865,9 +5865,9 @@ main ()
 int t;
 mpfr_init (n);
 mpfr_init (x);
-mpfr_atan2 (n, n, x, GMP_RNDN);
-mpfr_erfc (n, x, GMP_RNDN);
-mpfr_subnormalize (x, t, GMP_RNDN);
+mpfr_atan2 (n, n, x, MPFR_RNDN);
+mpfr_erfc (n, x, MPFR_RNDN);
+mpfr_subnormalize (x, t, MPFR_RNDN);
 mpfr_clear(n);
 mpfr_clear(x);
 mpc_init2 (c, 53);
diff --git a/configure.ac b/configure.ac
index 29e25f13278..50e2fa135b1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1641,9 +1641,9 @@ if test -d ${srcdir}/gcc && test "x$have_gmp" = xno; then
 int t;
 mpfr_init (n);
 mpfr_init (x);
-mpfr_atan2 (n, n, x, GMP_RNDN);
-mpfr_erfc (n, x, GMP_RNDN);
-mpfr_subnormalize (x, t, GMP_RNDN);
+mpfr_atan2 (n, n, x, MPFR_RNDN);
+mpfr_erfc (n, x, MPFR_RNDN);
+mpfr_subnormalize (x, t, MPFR_RNDN);
 mpfr_clear(n);
 mpfr_clear(x);
 mpc_init2 (c, 53);
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 8296d846171..36319a97b52 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -11045,7 +11045,7 @@ do_mpfr_ckconv (mpfr_srcptr m, tree type, int inexact)
 {
   REAL_VALUE_TYPE rr;
 
-  real_from_mpfr (, m, type, GMP_RNDN);
+  real_from_mpfr (, m, type, MPFR_RNDN);
   /* Proceed iff GCC's REAL_VALUE_TYPE can hold the MPFR value,
 	 check for overflow/underflow.  If the REAL_VALUE_TYPE is zero
 	 but the mpft_t is not, then we underflowed in the
@@ -11085,8 +11085,8 @@ do_mpc_ckconv (mpc_srcptr m, tree type, int inexact, int force_convert)
 {
   REAL_VALUE_TYPE re, im;
 
-  real_from_mpfr (, mpc_realref (m), TREE_TYPE (type), GMP_RNDN);
-  real_from_mpfr (, mpc_imagref (m), TREE_TYPE (type), GMP_RNDN);
+  real_from_mpfr (, mpc_realref (m), TREE_TYPE (type), MPFR_RNDN);
+  real_from_mpfr (, mpc_imagref (m), TREE_TYPE (type), MPFR_RNDN);
   /* Proceed iff GCC's REAL_VALUE_TYPE can hold the MPFR values,
 	 check for overflow/underflow.  If the REAL_VALUE_TYPE is zero
 	 but the mpft_t is not, then we underflowed in the
@@ -11138,14 +11138,14 @@ do_mpfr_remquo (tree arg0, tree arg1, tree arg_quo)
 {
 	  const struct real_format *fmt = REAL_MODE_FORMAT (TYPE_MODE (type));
 	  const int prec = fmt->p;
-	  const mp_rnd_t rnd = fmt->round_towards_zero? GMP_RNDZ : GMP_RNDN;
+	  const mpfr_rnd_t rnd = fmt->round_towards_zero? MPFR_RNDZ : MPFR_RNDN;
 	  tree result_rem;
 	  long integer_quo;
 	  mpfr_t m0, m1;
 
 	  mpfr_inits2 (prec, m0, m1, NULL);
-	  mpfr_from_real (m0, ra0, GMP_RNDN);
-	  mpfr_from_real (m1, ra1, GMP_RNDN);
+	  mpfr_from_real (m0, ra0, MPFR_RNDN);
+	  mpfr_from_real (m1, ra1, MPFR_RNDN);
 	  mpfr_clear_flags ();
 	  mpfr_remquo (m0, _quo, m0, m1, rnd);
 	  /* Remquo is independent of the rounding mode, so pass
@@ -11218,13 +11218,13 @@ do_mpfr_lgamma_r (tree arg, tree arg_sg, tree type)
 {
 	  const struct real_format *fmt = REAL_MODE_FORMAT (TYPE_MODE (type));
 	  const int prec = fmt->p;
-	  const mp_rnd_t rnd = fmt->round_towards_zero? GMP_RNDZ : GMP_RNDN;
+	  const mpfr_rnd_t rnd = fmt->round_towards_zero? MPFR_RNDZ : MPFR_RNDN;
 	  int inexact, sg;
 	  mpfr_t m;
 	  tree result_lg;
 
 	  mpfr_init2 (m, prec);
-	  mpfr_from_real (m, ra, GMP_RNDN);
+	  mpfr_from_real (m, ra, MPFR_RNDN);
 	  mpfr_clear_flags ();
 	  inexact 

Re: [PATCH] Prevent recursive satisfaction (PR c++/88395)

[Jason Merrill]

On 11/18/19 10:13 AM, Andrew Sutton wrote:

This applies on top of the patch here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01034.html

Wrap satisfaction with push/pop_tinst_level to force termination on recursion.



+  if (tmpl)
+   push_tinst_level (tmpl);


Actually, why not pass 't' here?

Jason

Re: [PATCH] PR c++/92439: Improve diagnostics for ill-formed requires-clauses

[Jason Merrill]

On 11/22/19 10:28 AM, Andrew Sutton wrote:

This does a much better job identifying when an expression in a
requires-clause needs parentheses.

Andrew Sutton


OK.

Jason

Re: [PATCH] PR c++/92236: Improve static assertions of concepts

[Jason Merrill]

On 11/20/19 10:45 AM, Andrew Sutton wrote:

This patch builds on https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01034.html.

Tie static assertion diagnostics into constraint diagnostic. For
example, this program:

template
concept iterator =
   requires (I i)
   {
 ++i;
 *i;
   };

static_assert(iterator);

Yields these errors:

x.cpp:11:15: error: static assertion failed
11 | static_assert(iterator);
   |   ^
x.cpp:11:15: note: constraints not satisfied
x.cpp:4:9:   required by the constraints of ‘template concept iterator’
x.cpp:5:3:   in requirements with ‘int i’
x.cpp:8:5: note: the required expression ‘* i’ is invalid
 8 | *i;
   | ^~

Andrew Sutton


OK.

Jason

Re: [PATCH] Prevent recursive satisfaction (PR c++/88395)

[Jason Merrill]

On 11/18/19 10:13 AM, Andrew Sutton wrote:

This applies on top of the patch here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01034.html

Wrap satisfaction with push/pop_tinst_level to force termination on recursion.

Andrew Sutton


OK.

Re: [PATCH] Diagnose hard errors during constraint satisfaction

[Jason Merrill]

On 11/13/19 8:28 AM, Andrew Sutton wrote:

This changes the diagnostic of non-boolean constraints and rvalue
conversion failures in constraint satisfaction into hard errors. I
also cleaned up the satisfaction routines to reduce the number of
functions involved.

Jason, this is a squashed version of the patches I sent earlier today.

This patch also fixes the crash PR92439, which was caused by not
building the normalization tree in satisfy_constraint_expression.
However, there are some other problems with that example that cause it
to not compile (e.g., non-boolean atomic constraints).

Andrew Sutton



OK.

Re: [PATCH][_GLIBCXX_DEBUG] Improve valid_range check

[François Dumont]

On 11/26/19 9:49 PM, Stephan Bergmann wrote:

On 26/11/2019 20:07, François Dumont wrote:
However I wasn't sure about this syntax before the commit so I had 
run the new 2_neg.cc with:


make CXXFLAGS=-std=c++98 check-debug

and it worked fine and still is !

I also try -std=gnu++98 and made sure that pch had been updated by 
re-building libstdc++ first. I just can't get the expected 
compilation error.


Maybe I need to rebuild the whole stuff to get an error...


I saw the error with recent Clang and -std=gnu++98.  Recent GCC indeed 
seems to give at most a warning.




Ok, thanks for the feedback, gcc might be more permissive then.

Whatever I committed the fix an hour ago.

Re: [PATCH][_GLIBCXX_DEBUG] Improve valid_range check

[Stephan Bergmann]

On 26/11/2019 20:07, François Dumont wrote:
However I wasn't sure about this syntax before the commit so I had run 
the new 2_neg.cc with:


make CXXFLAGS=-std=c++98 check-debug

and it worked fine and still is !

I also try -std=gnu++98 and made sure that pch had been updated by 
re-building libstdc++ first. I just can't get the expected compilation 
error.


Maybe I need to rebuild the whole stuff to get an error...


I saw the error with recent Clang and -std=gnu++98.  Recent GCC indeed 
seems to give at most a warning.

Re: [Patch, build] Unbreak objc build

[Andrew Pinski]

On Tue, Nov 26, 2019 at 10:48 AM Tobias Burnus  wrote:
>
> When I tried to bootstrap with --enable-languages=default, which
> includes objc, it failed to build libobj.
>
> As Rhy0lite on IRC correctly guessed, the issue is that the cet.m4 file
> is at a different location. I wonder why no one had the problem before
> in the last years – the libobjc/Makefile.in change was r254904 on Nov
> 17, 2017 (!). The config/cet.m4 file itself was also added on 2017-11-17
> in r254868.
>
> Doing some more archeology, the the Makefile.in was changed by the patch
> https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02314.html – and one sees
> that libobjc/aclocal.m4 has /../config/cet.m4 while libobjc/Makefile.in
> uses /../cet.m4.m4. – Actually, that's not the submitted version
> (cet.m4.m4) – as the committed version has 'cet.m4'. Approval was:
> https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00641.html
>
> Build on x86-64-gnu-linux.
> OK for the trunk?

Yes.


>
> Tobias
>
> PS: Assuming the build was indeed broken for everyone since 2 years,
> maybe one should remove 'objc' from the 'default' languages? – Which
> languages is now nowadays supposed to use when bootstrapping? I usually
> have 'c,c++,fortran,lto', 'default' seems to be 'c,c++,fortran,objc'
> (plus 'lto' which is implied by --enable-lto, which is default).

Though as mentioned, the problem only shows up with
--enable-maintainer-mode which nobody uses as the requirements for
automake/autoconfig is different through out of a combined tree.

Thanks,
Andrew Pinski

>

Re: [Patch, build] Unbreak objc build

[Jakub Jelinek]

On Tue, Nov 26, 2019 at 07:47:44PM +0100, Tobias Burnus wrote:
> Build on x86-64-gnu-linux.
> OK for the trunk?

The patch is obvious.

> PS: Assuming the build was indeed broken for everyone since 2 years, maybe
> one should remove 'objc' from the 'default' languages? – Which languages is
> now nowadays supposed to use when bootstrapping? I usually have
> 'c,c++,fortran,lto', 'default' seems to be 'c,c++,fortran,objc' (plus 'lto'
> which is implied by --enable-lto, which is default).

No, it isn't really broken unless --enable-maintainer-mode.
aclocal_deps variable in libobjc/Makefile.in in which this bug is is only
used in:
$(srcdir)/aclocal.m4: @MAINT@ $(aclocal_deps)
cd $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS)
and when not --enable-maintainer-mode, @MAINT@ is replaced with #
(otherwise with nothing).
And many people test objc or obj-c++ daily or whenever they are
bootstrapping.  I do all my x86_64-linux bootstraps with
--enable-languages=default,ada,obj-c++,lto,go,brig,d
and i686-linux bootstraps with
--enable-languages=default,obj-c++,lto,go,brig,d
others are using =all etc.

>   libobjc/
>   * Makefile.in (aclocal_deps): Fix path to cet.m4.
> 
> diff --git a/libobjc/Makefile.in b/libobjc/Makefile.in
> index d733fb2606b..f029880265e 100644
> --- a/libobjc/Makefile.in
> +++ b/libobjc/Makefile.in
> @@ -297,7 +297,7 @@ aclocal_deps = \
>   $(srcdir)/../ltsugar.m4 \
>   $(srcdir)/../ltversion.m4 \
>   $(srcdir)/../lt~obsolete.m4 \
> - $(srcdir)/../cet.m4 \
> + $(srcdir)/../config/cet.m4 \
>   $(srcdir)/acinclude.m4
>  
>  $(srcdir)/configure: @MAINT@ configure.ac $(srcdir)/aclocal.m4


Jakub

Re: Move -Wmaybe-uninitialized to -Wextra

[Michael Witten]

The problem with false positives is correlated with the degree of
optimization; a lot of people  have reported problems at only the
`-Og'  optimization level  (even  when the  code  in question  is
embarrassingly correct).

Therefore,  the general  solution  is probably  that the  implem-
entation of  `-Wmaybe-uninitialized' be customized for  the given
level of optimization.

However, I get the impression that this is easier said than done.

>From  what  I've  read,  `-Wmaybe-uninitialized'  is  essentially
customized for `-O2',  which means that it will  work pretty darn
well at that optimization level. So,  in the interim, I propose a
simple approximation of the general solution:

  At an optimization level below `-O2' (or other than `-O2'):

* `-Wmaybe-uninitialized' is moved to `-Wextra'.

  If  `-Wall'   has  been   specified,  then  gcc   emits  an
  informational note stating that `-Wmaybe-uninitialized' (or
  any  other  warning that  has  similar  problems) has  been
  disabled.

* Provide a command-line option to disable such a note.

* The user  may always enable  `-Wmaybe-uninitialized' either
  explicitly or as part of `-Wextra'.

* If `-Wmaybe-uninitialized' is enabled  by the user, then it
  implies `-O2' computations.

  That is to say, when the user specifies:

-Og -Wmaybe-uninitialized

  or:

-Og -Wextra

  then the user is explicitly  telling the compiler to do all
  the optimizations  of `-O2',  but ONLY  for the  purpose of
  implementing `-Wmaybe-uninitialized'  (or whichever warning
  requires those  optimizations to function well);  all those
  optimizations are  to be  thrown out  after they  have been
  used to  good effect  by `-Wmaybe-uninitialized'.  The Code
  generation, etc.,  shall be  performed at  the optimization
  level the user specified (namely, `-Og' in this case).

In other  words, save the  user from  gcc's foibles, but  let the
user pay for the extra computation if so desired!

What do you think?

Sincerely,
Michael Witten


PS

All  of  this trouble  indicates  that  C (and  other  languages)
are  just not  expressive enough  with regard  to initialization.

Initialization semantics  are basically a matter  of API contract
specification; the programmer needs the tools to write it down.

Surely, gcc could  provide `__builtin_assume_initialized(x);' and
parameter attributes  to help  inform the  reader (i.e.,  to help
inform  the  compiler)  about  the  code;  a  function  parameter
attribute  could  specify  whether  the  given  argument  can  be
considered initialized  after a  call, and maybe  specify further
constraints, such as whether the  guarantee is made only when the
function return value is nonzero (or a certain value), etc.

We need the language to write our thoughts down!

Re: [Patch, build] Unbreak objc build

[Tobias Burnus]

Actually, can you both try with my patch applied? If it still builds for 
you and then builds for me, the problem is also solved. And with proper 
path it looks better in any case.


(Remark: The compilation w/o maintainer mode was the usual Linux path, 
i.e. all under /usr/bin.)


Tobias

On 11/26/19 8:27 PM, Tobias Burnus wrote:

On 11/26/19 8:13 PM, Iain Sandoe wrote:

Right, It’s not been broken at all AFAICT - I build it daily on 
Darwin (often several times) and

frequently on Linux - as does anyone building —enable-languages=all


Ideas are welcome. I first did:

.../configure --prefix=/home/tburnus/projects/gcc-trunk 
--enable-maintainer-mode --enable-languages=c,c++,fortran,lto,default 
--prefix=…

make -j12

with PATH=$pathToAutoTools/bin:$HOME with autoconf-2.69 and 
automake-1.15.1 installed there. And that failed with:


*** No rule to make target '…/libobjc/../cet.m4', needed by 
'…/libobjc/aclocal.m4'.  Stop.


Note the wrong path – the file is in ../libobjc/../config/cet.m4.

Afterwards, I tried without --enable-maintainer-mode – and got exactly 
the same error.


In any case, the directory in libobj/Makefile.in is wrong.

Cheers,

Tobias


see, for example
https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01480.html

there must be some other explanation ;)

Suggestions?

cheers
Iain

Re: [Patch, build] Unbreak objc build

[Tobias Burnus]

On 11/26/19 8:13 PM, Iain Sandoe wrote:

Right, It’s not been broken at all AFAICT - I build it daily on Darwin 
(often several times) and

frequently on Linux - as does anyone building —enable-languages=all


Ideas are welcome. I first did:

.../configure --prefix=/home/tburnus/projects/gcc-trunk 
--enable-maintainer-mode --enable-languages=c,c++,fortran,lto,default 
--prefix=…

make -j12

with PATH=$pathToAutoTools/bin:$HOME with autoconf-2.69 and 
automake-1.15.1 installed there. And that failed with:


*** No rule to make target '…/libobjc/../cet.m4', needed by 
'…/libobjc/aclocal.m4'.  Stop.


Note the wrong path – the file is in ../libobjc/../config/cet.m4.

Afterwards, I tried without --enable-maintainer-mode – and got exactly 
the same error.


In any case, the directory in libobj/Makefile.in is wrong.

Cheers,

Tobias


see, for example
https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01480.html

there must be some other explanation ;)

Suggestions?

cheers
Iain

Re: [PATCH], V7, #6 of 7, Fix issues with vector extract and prefixed instructions

[Segher Boessenkool]

Hi!

On Thu, Nov 14, 2019 at 06:09:09PM -0500, Michael Meissner wrote:
> In this case, the current code re-uses the temporary for calculating the 
> offset
> of the element to load up the address of the vector, losing the offset.

Reusing the same pseudo is *always* a bad idea.  You get better
optimisation if most code is "SSA-like": write to every pseudo only
once.  Of course you need to violate this where you woule have PHIs in
actual SSA.

> I needed to add a new constraint (em) in addition to new predicate functions.
> I discovered that with the predicate function alone, the register allocator
> would re-create the address.  The constraint prevents this combination.

It's a reasonable thing to have as a contraint, too.

Once again, how should things work in inline assembler?  Can we allow
prefixed addressing there, or should "m" in inline asm mean "em"?

> I also modified the vector extract code to generate a single PC-relative load
> if the vector has a PC-relative address and the offset is constant.

That should be handled by the RTL optimisers anyway, no?  Or is this
for post-reload splitters (a bad idea always).

>   * config/rs6000/rs6000.c (rs6000_adjust_vec_address): Add support
>   for optimizing extracting a constant vector element from a vector
>   that uses a prefixed address.  If the element number is variable
>   and the address uses a prefixed address, abort.

It doesn't abort.  Erm, wait, it *does* ICE.  Please make that more
prominent (in the code).  It's not clear why you mention it in the
changelog while allt he other details are just "add support"?

I find the control flow very hard to read here.

> +  /* Optimize PC-relative addresses with a constant offset.  */
> +  else if (pcrel_p && CONST_INT_P (element_offset))
> +{
> +  rtx addr2 = addr;

addr isn't used after this anyway, so you can clobber it just fine.

> +  /* With only one temporary base register, we can't support a PC-relative
> + address added to a variable offset.  This is because the PADDI 
> instruction
> + requires RA to be 0 when doing a PC-relative add (i.e. no register to 
> add
> + to).  */
> +  else if (pcrel_p)
> +gcc_unreachable ();

That comment suggests we just ICE when we get unwanted input.  Such a
comment belongs where we prevent such code from being formed in the
first place (or nowhere, if it is obvious).


Segher

Re: [Patch, build] Unbreak objc build

[Iain Sandoe]

Hi
Rainer Orth  wrote:



When I tried to bootstrap with --enable-languages=default, which includes
objc, it failed to build libobj.


care to describe exactly how the build fails?


PS: Assuming the build was indeed broken for everyone since 2 years, maybe
one should remove 'objc' from the 'default' languages?
– Which languages is
now nowadays supposed to use when bootstrapping? I usually have
'c,c++,fortran,lto', 'default' seems to be 'c,c++,fortran,objc' (plus  
'lto'

which is implied by --enable-lto, which is default).


There's certainly more to that failure than just
--enable-languages=default: I'm regularly using
--enable-languages=all,... (which includes objc) without any issues, on
all of Solaris, Linux/x86_64, and Darwin


Right, It’s not been broken at all AFAICT - I build it daily on Darwin  
(often several times) and

frequently on Linux - as does anyone building —enable-languages=all

see, for example
https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01480.html

there must be some other explanation ;)

cheers
Iain

Re: [Patch, build] Unbreak objc build

[Rainer Orth]

Hi Tobias,

> When I tried to bootstrap with --enable-languages=default, which includes
> objc, it failed to build libobj.

care to describe exactly how the build fails?

> PS: Assuming the build was indeed broken for everyone since 2 years, maybe
> one should remove 'objc' from the 'default' languages? – Which languages is
> now nowadays supposed to use when bootstrapping? I usually have
> 'c,c++,fortran,lto', 'default' seems to be 'c,c++,fortran,objc' (plus 'lto'
> which is implied by --enable-lto, which is default).

There's certainly more to that failure than just
--enable-languages=default: I'm regularly using
--enable-languages=all,... (which includes objc) without any issues, on
all of Solaris, Linux/x86_64, and Darwin.

Rainer

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

Re: [PATCH][_GLIBCXX_DEBUG] Improve valid_range check

[François Dumont]

On 11/26/19 1:21 PM, Jonathan Wakely wrote:

On 26/11/19 12:33 +0100, Stephan Bergmann wrote:

On 22/11/2019 18:59, Jonathan Wakely wrote:

On 22/11/19 18:38 +0100, François Dumont wrote:
    I noticed that we are not checking that iterators are not 
singular in valid_range. Moreover __check_singular signature for 
pointers is not intercepting all kind of pointers in terms of 
qualification.


    I'd like to commit it next week but considering we are in stage 
3 I need proper acceptance.


    * include/debug/functions.h: Remove  include.
    (__check_singular_aux, __check_singular): Move...
    * include/debug/helper_functions.h:
    (__check_singular_aux, __check_singular): ...here.
    (__valid_range_aux): Adapt to use latter.
    * testsuite/25_algorithms/copy/debug/2_neg.cc: New.

Tested under Linux x86_64 normal and debug modes.


OK for trunk, thanks.


The curly braces...

diff --git a/libstdc++-v3/include/debug/helper_functions.h 
b/libstdc++-v3/include/debug/helper_functions.h

index c3e7478f649..5a858754875 100644
--- a/libstdc++-v3/include/debug/helper_functions.h
+++ b/libstdc++-v3/include/debug/helper_functions.h

[...]

@@ -138,14 +156,23 @@ namespace __gnu_debug
    inline bool
    __valid_range_aux(_InputIterator __first, _InputIterator __last,
  std::input_iterator_tag)
-    { return true; }
+    {
+  if (__first != __last)
+    return !__check_singular(__first) && !__check_singular(__last);
+
+  return true;
+    }
  template
    _GLIBCXX_CONSTEXPR
    inline bool
    __valid_range_aux(_InputIterator __first, _InputIterator __last,
  std::random_access_iterator_tag)
-    { return __first <= __last; }
+    {
+  return
+    __valid_range_aux(__first, __last, std::input_iterator_tag{})


...^^^ here...


+    && __first <= __last;
+    }
  /** We have iterators, so figure out what kind of iterators they are
   *  to see if we can check the range ahead of time.
@@ -167,6 +194,9 @@ namespace __gnu_debug
  typename _Distance_traits<_InputIterator>::__type& 
__dist,

  std::__false_type)
    {
+  if (!__valid_range_aux(__first, __last, 
std::input_iterator_tag{}))


...and ^^^ here are not allowed pre C++11.  Replacing those with

 std::input_iterator_tag()

should fix it.


Indeed. We should also have tests that use "-std=gnu++98
-D_GLIBCXX_DEBUG" so they'd catch this.

François, can you take care of the fix please?




Sure, I am about to do so.

However I wasn't sure about this syntax before the commit so I had run 
the new 2_neg.cc with:


make CXXFLAGS=-std=c++98 check-debug

and it worked fine and still is !

I also try -std=gnu++98 and made sure that pch had been updated by 
re-building libstdc++ first. I just can't get the expected compilation 
error.


Maybe I need to rebuild the whole stuff to get an error...

Sorry

[Patch, build] Unbreak objc build

[Tobias Burnus]

When I tried to bootstrap with --enable-languages=default, which 
includes objc, it failed to build libobj.


As Rhy0lite on IRC correctly guessed, the issue is that the cet.m4 file 
is at a different location. I wonder why no one had the problem before 
in the last years – the libobjc/Makefile.in change was r254904 on Nov 
17, 2017 (!). The config/cet.m4 file itself was also added on 2017-11-17 
in r254868.


Doing some more archeology, the the Makefile.in was changed by the patch 
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02314.html – and one sees 
that libobjc/aclocal.m4 has /../config/cet.m4 while libobjc/Makefile.in 
uses /../cet.m4.m4. – Actually, that's not the submitted version 
(cet.m4.m4) – as the committed version has 'cet.m4'. Approval was: 
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00641.html


Build on x86-64-gnu-linux.
OK for the trunk?

Tobias

PS: Assuming the build was indeed broken for everyone since 2 years, 
maybe one should remove 'objc' from the 'default' languages? – Which 
languages is now nowadays supposed to use when bootstrapping? I usually 
have 'c,c++,fortran,lto', 'default' seems to be 'c,c++,fortran,objc' 
(plus 'lto' which is implied by --enable-lto, which is default).


	libobjc/
	* Makefile.in (aclocal_deps): Fix path to cet.m4.

diff --git a/libobjc/Makefile.in b/libobjc/Makefile.in
index d733fb2606b..f029880265e 100644
--- a/libobjc/Makefile.in
+++ b/libobjc/Makefile.in
@@ -297,7 +297,7 @@ aclocal_deps = \
 	$(srcdir)/../ltsugar.m4 \
 	$(srcdir)/../ltversion.m4 \
 	$(srcdir)/../lt~obsolete.m4 \
-	$(srcdir)/../cet.m4 \
+	$(srcdir)/../config/cet.m4 \
 	$(srcdir)/acinclude.m4
 
 $(srcdir)/configure: @MAINT@ configure.ac $(srcdir)/aclocal.m4

Re: [Patch, gcc-wwdocs] Update to Fortran changes

[Mark Eggleston]

Second attempt this time with attachment.

Apologies.

regards,

Mark

On 26/11/2019 15:56, Mark Eggleston wrote:


On 26/11/2019 11:12, Tobias Burnus wrote:

Hi Mark,

On 11/26/19 11:46 AM, Mark Eggleston wrote:
I've check the changes with W3 validator. There are no problems 
related to my changes, however, it does object to the lack of 
character encoding in the file.


Note that some script modifies the file a bit – the final file does 
have a character encoding (content="text/html; charset=utf-8").

Understood.


This is the first time in changing the wwwdoc, I haven't included a 
change log as there there doesn't appear to be any ChangeLog files.


There is only a commit log (see 'git log'); the format is still a bit 
in a flux as before there was only 'csv' where it applied to a single 
file.


[With git it is useful to have a meaningful single line (for "git log 
--pretty=oneline") and, if needed, an empty line and something more. 
As the main repository is going to move to GIT as well, this also 
applies there. – But you already follow this style.]



The patch is attached. OK to commit?


I wonder whether you should use a main bullet point with something 
like "Legacy improvements (-fdec)" under which you put 
the current list. [Or some other wording.] That makes it easier to 
read for users – those, who care about legacy support, can quickly 
look at the -fdec changes – while those interested in standard 
Fortran can skip it. (Except for the character-diagnostic type-info 
improvement, all are items seem to be for -fdec or -fdec-…)

Used "Legacy extension:".


In particular, currently, the following item does not make clear that 
it is about legacy support: "Variables with the 
AUTOMATIC attribute can be used in 
EQUIVALENCE statements."

Made it clear that this an extension of -fdec-static.


I think it can remain as is with the -fdec umbrella item. But without 
it really requires the background knowledge that the AUTOMATIC 
attribute is only available with -fdec-static (or -fdec).


Stated that -fdec-static or -fdec are needed to use AUTOMATIC in 
EQUIVALENCE.




Cheers,

Tobias



Changes acceptable? OK to commit?


--
https://www.codethink.co.uk/privacy.html

>From f884924877ba84578e75bd16cb127bab33eb5ee6 Mon Sep 17 00:00:00 2001
From: Mark Eggleston 
Date: Tue, 26 Nov 2019 10:12:44 +
Subject: [PATCH] Update Fortran changes

---
 htdocs/gcc-10/changes.html | 41 +
 1 file changed, 41 insertions(+)

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 52eb303..a31e7e5 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -206,6 +206,47 @@ a work-in-progress.
 with -std=legacy.  -Wargument-mismatch
 has been removed.
   
+  
+Legacy extensions:
+
+  
+Default fields widths can be used for I, F
+and G format specifiers when excplicit widths are omitted.
+Use the option -fdec-format-defaults, this options is implied
+with -fdec. 
+  
+  
+A blank format item at the end of a format specification i.e. nothing
+following the final comma is allowed.  Use the option
+-fdec-blank-format-item, this options is implied with
+-fdec.
+  
+  
+The existing support for AUTOMATIC and STATIC
+attributes has been extended to allow variables with the
+AUTOMATIC attribute to be used in EQUIVALENCE
+statements. Use -fdec-static, this option is implied by
+-fdec.
+  
+  
+Allow character literals in assignments and DATA statements
+for numeric (INTEGER, REAL, or
+COMPLEX) or LOGICAL variables.  Use the option
+-fdec-char-conversions, this options is implied with
+-fdec.
+  
+  
+DEC comparisons, i.e. allow Hollerith constants to be used in comparisons
+with INTEGER, REAL, COMPLEX and
+CHARACTER expressions. Use the option -fdec.
+  
+
+
+  Character type names in errors and warnings now include len
+  in addition to kind, * is used for assumed
+  length. The kind is omitted if it the default kind. Examples:
+  CHARACTER(12), CHARACTER(6,4).
+
 
 
 
-- 
1.8.3.1

[vect][testsuite] Update vect_char_add target selector to use its own cache

[Joel Hutton]

Hi all,

This patch updates the vect_char_add target selector to use its own 
cache instead of the vect_int cache.

This was causing a situation where bb-slp-40.c would fail on sparc when 
run after other tests that use the vect_int target selector, but pass 
when run on its own.

This fixes Bug 92391

Tested on x86 and sparc64.

2019-11-26  Joel Hutton  

     * lib/target-supports.exp: Update vect_char_add target selector 
to use its own cache.

From 7ed08950f4440f8605b9df1114edcc8ee834 Mon Sep 17 00:00:00 2001
From: Joel Hutton 
Date: Tue, 26 Nov 2019 17:09:12 +
Subject: [PATCH] Update vect_char_add target selector to use its own cache

---
 gcc/testsuite/lib/target-supports.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 5fe1e83492cae97adf82ed53e12d8f5f7ea5a951..a4418a3151677a2a45275463b9828db7e7755b28 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5753,7 +5753,7 @@ proc check_effective_target_vect_bswap { } {
 # one vector length.
 
 proc check_effective_target_vect_char_add { } {
-return [check_cached_effective_target_indexed vect_int {
+return [check_cached_effective_target_indexed vect_char_add {
   expr {
  [istarget i?86-*-*] || [istarget x86_64-*-*]
  || ([istarget powerpc*-*-*]
-- 
2.17.1

Re: [PATCH v2][ARM] Disable code hoisting with -O3 (PR80155)

[Wilco Dijkstra]

Hi Christophe,

> Some time ago, you proposed to enable code hoisting for -Os instead,
> and this is the approach that was chosen
> in arm-9-branch. Why are you proposing a different setting for trunk?

Like I said in my message, I've now done more detailed benchmarking which
shows it affects -O3 performance very significantly but -O2 by not much.
Since it's a good idea to keep the O1/O2 configs as standard as possible (as
Richi suggests), just disabling with -O3 seems better than the previous version.

Cheers,
Wilco

[PATCH][AArch64] Enable CLI for Armv8.6-a: armv8.6-a, i8mm and bf16

[Dennis Zhang]

Hi all,

This patch is part of a series adding support for Armv8.6-A features.
It enables options including -march=armv8.6-a, +i8mm and +bf16.
The +i8mm and +bf16 features are mandatory for Armv8.6-a and optional 
for Armv8.2-a and onward.
Documents are at https://developer.arm.com/docs/ddi0596/latest

Regtested for aarch64-none-linux-gnu.

Please help to check if it's ready for trunk.

Many thanks!
Dennis

gcc/ChangeLog:

2019-11-26  Dennis Zhang  

* config/aarch64/aarch64-arches.def (armv8.6-a): New.
* config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Define
__ARM_FEATURE_MATMUL_INT8, __ARM_FEATURE_BF16_VECTOR_ARITHMETIC and
__ARM_FEATURE_BF16_SCALAR_ARITHMETIC when enabled.
* config/aarch64/aarch64-option-extensions.def (i8mm, bf16): New.
* config/aarch64/aarch64.h (AARCH64_FL_V8_6): New macro.
(AARCH64_FL_I8MM, AARCH64_FL_BF16, AARCH64_FL_FOR_ARCH8_6): Likewise.
(AARCH64_ISA_V8_6, AARCH64_ISA_I8MM, AARCH64_ISA_BF16): Likewise.
(TARGET_I8MM, TARGET_BF16_FP, TARGET_BF16_SIMD): Likewise.
* doc/invoke.texi (armv8.6-a, i8mm, bf16): Document new options.

gcc/testsuite/ChangeLog:

2019-11-26  Dennis Zhang  

* gcc.target/aarch64/pragma_cpp_predefs_2.c: Add tests for i8mm
and bf16 features.
diff --git a/gcc/config/aarch64/aarch64-arches.def b/gcc/config/aarch64/aarch64-arches.def
index d258bd49244..e464d329c1a 100644
--- a/gcc/config/aarch64/aarch64-arches.def
+++ b/gcc/config/aarch64/aarch64-arches.def
@@ -36,5 +36,6 @@ AARCH64_ARCH("armv8.2-a", generic,	 8_2A,	8,  AARCH64_FL_FOR_ARCH8_2)
 AARCH64_ARCH("armv8.3-a", generic,	 8_3A,	8,  AARCH64_FL_FOR_ARCH8_3)
 AARCH64_ARCH("armv8.4-a", generic,	 8_4A,	8,  AARCH64_FL_FOR_ARCH8_4)
 AARCH64_ARCH("armv8.5-a", generic,	 8_5A,	8,  AARCH64_FL_FOR_ARCH8_5)
+AARCH64_ARCH("armv8.6-a", generic,	 8_6A,	8,  AARCH64_FL_FOR_ARCH8_6)
 
 #undef AARCH64_ARCH
diff --git a/gcc/config/aarch64/aarch64-c.c b/gcc/config/aarch64/aarch64-c.c
index f3da07fd28a..20d1e00552b 100644
--- a/gcc/config/aarch64/aarch64-c.c
+++ b/gcc/config/aarch64/aarch64-c.c
@@ -165,6 +165,12 @@ aarch64_update_cpp_builtins (cpp_reader *pfile)
   aarch64_def_or_undef (TARGET_RNG, "__ARM_FEATURE_RNG", pfile);
   aarch64_def_or_undef (TARGET_MEMTAG, "__ARM_FEATURE_MEMORY_TAGGING", pfile);
 
+  aarch64_def_or_undef (TARGET_I8MM, "__ARM_FEATURE_MATMUL_INT8", pfile);
+  aarch64_def_or_undef (TARGET_BF16_SIMD,
+			"__ARM_FEATURE_BF16_VECTOR_ARITHMETIC", pfile);
+  aarch64_def_or_undef (TARGET_BF16_FP,
+			"__ARM_FEATURE_BF16_SCALAR_ARITHMETIC", pfile);
+
   /* Not for ACLE, but required to keep "float.h" correct if we switch
  target between implementations that do or do not support ARMv8.2-A
  16-bit floating-point extensions.  */
diff --git a/gcc/config/aarch64/aarch64-option-extensions.def b/gcc/config/aarch64/aarch64-option-extensions.def
index d3ae1b2431b..5b7c3b8a213 100644
--- a/gcc/config/aarch64/aarch64-option-extensions.def
+++ b/gcc/config/aarch64/aarch64-option-extensions.def
@@ -198,4 +198,14 @@ AARCH64_OPT_EXTENSION("sve2-bitperm", AARCH64_FL_SVE2_BITPERM, AARCH64_FL_SIMD |
 /* Enabling or disabling "tme" only changes "tme".  */
 AARCH64_OPT_EXTENSION("tme", AARCH64_FL_TME, 0, 0, false, "")
 
+/* Enabling "i8mm" also enables "simd".
+   Disabling "i8mm" only disables "i8mm".  */
+AARCH64_OPT_EXTENSION("i8mm", AARCH64_FL_I8MM, AARCH64_FL_SIMD, \
+		  0, false, "i8mm")
+
+/* Enabling "bf16" also enables "simd" and "fp".
+   Disabling "bf16" only disables "bf16".  */
+AARCH64_OPT_EXTENSION("bf16", AARCH64_FL_BF16, AARCH64_FL_SIMD | AARCH64_FL_FP,
+		  0, false, "bf16")
+
 #undef AARCH64_OPT_EXTENSION
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index ee01909abb9..7de99285e8a 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -202,6 +202,15 @@ extern unsigned aarch64_architecture_version;
 /* Transactional Memory Extension.  */
 #define AARCH64_FL_TME	  (1ULL << 33)  /* Has TME instructions.  */
 
+/* Armv8.6-A architecture extensions.  */
+#define AARCH64_FL_V8_6	  (1ULL << 34)
+
+/* 8-bit Integer Matrix Multiply (I8MM) extensions.  */
+#define AARCH64_FL_I8MM   (1ULL << 35)
+
+/* Brain half-precision floating-point (BFloat16) Extension.  */
+#define AARCH64_FL_BF16	  (1ULL << 36)
+
 /* Has FP and SIMD.  */
 #define AARCH64_FL_FPSIMD (AARCH64_FL_FP | AARCH64_FL_SIMD)
 
@@ -223,6 +232,9 @@ extern unsigned aarch64_architecture_version;
 #define AARCH64_FL_FOR_ARCH8_5			\
   (AARCH64_FL_FOR_ARCH8_4 | AARCH64_FL_V8_5	\
| AARCH64_FL_SB | AARCH64_FL_SSBS | AARCH64_FL_PREDRES)
+#define AARCH64_FL_FOR_ARCH8_6			\
+  (AARCH64_FL_FOR_ARCH8_5 | AARCH64_FL_V8_6 | AARCH64_FL_FPSIMD \
+   | AARCH64_FL_I8MM | AARCH64_FL_BF16)
 
 /* Macros to test ISA flags.  */
 
@@ -249,6 +261,9 @@ extern unsigned aarch64_architecture_version;
 #define AARCH64_ISA_V8_5	   (aarch64_isa_flags & 

Re: [Patch, gcc-wwdocs] Update to Fortran changes

[Mark Eggleston]

On 26/11/2019 11:12, Tobias Burnus wrote:

Hi Mark,

On 11/26/19 11:46 AM, Mark Eggleston wrote:
I've check the changes with W3 validator. There are no problems 
related to my changes, however, it does object to the lack of 
character encoding in the file.


Note that some script modifies the file a bit – the final file does 
have a character encoding (content="text/html; charset=utf-8").

Understood.


This is the first time in changing the wwwdoc, I haven't included a 
change log as there there doesn't appear to be any ChangeLog files.


There is only a commit log (see 'git log'); the format is still a bit 
in a flux as before there was only 'csv' where it applied to a single 
file.


[With git it is useful to have a meaningful single line (for "git log 
--pretty=oneline") and, if needed, an empty line and something more. 
As the main repository is going to move to GIT as well, this also 
applies there. – But you already follow this style.]



The patch is attached. OK to commit?


I wonder whether you should use a main bullet point with something 
like "Legacy improvements (-fdec)" under which you put 
the current list. [Or some other wording.] That makes it easier to 
read for users – those, who care about legacy support, can quickly 
look at the -fdec changes – while those interested in standard Fortran 
can skip it. (Except for the character-diagnostic type-info 
improvement, all are items seem to be for -fdec or -fdec-…)

Used "Legacy extension:".


In particular, currently, the following item does not make clear that 
it is about legacy support: "Variables with the AUTOMATIC 
attribute can be used in EQUIVALENCE statements."

Made it clear that this an extension of -fdec-static.


I think it can remain as is with the -fdec umbrella item. But without 
it really requires the background knowledge that the AUTOMATIC 
attribute is only available with -fdec-static (or -fdec).


Stated that -fdec-static or -fdec are needed to use AUTOMATIC in 
EQUIVALENCE.




Cheers,

Tobias



Changes acceptable? OK to commit?

--
https://www.codethink.co.uk/privacy.html

[PING][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Mon, 11 Nov 2019, Maciej W. Rozycki wrote:

>  This patch series addresses a problem with the testsuite compiler being 
> set up across libatomic, libffi, libgo, libgomp with no correlation 
> whatsoever to the target compiler being used in GCC compilation.  
> Consequently there in no arrangement made to set up the compilation 
> sysroot according to the build sysroot specified for GCC compilation, 
> causing a catastrophic failure across the testsuites affected from the 
> inability to link executables.

 Ping for:





  Maciej

Re: [PATCH v2][ARM] Disable code hoisting with -O3 (PR80155)

[Richard Biener]

On November 26, 2019 4:39:09 PM GMT+01:00, Christophe Lyon 
 wrote:
>On Tue, 26 Nov 2019 at 16:18, Wilco Dijkstra 
>wrote:
>>
>> Hi,
>>
>> While code hoisting generally improves codesize, it can affect
>performance
>> negatively. Benchmarking shows it doesn't help SPEC and negatively
>affects
>> embedded benchmarks. Since the impact is relatively small with -O2
>and mainly
>> affects -O3, the simplest option is to disable code hoisting for -O3
>and higher.
>>
>> OK for commit?
>>
>
>Hi,
>
>Some time ago, you proposed to enable code hoisting for -Os instead,
>and this is the approach that was chosen
>in arm-9-branch. Why are you proposing a different setting for trunk?

These kind of tweaks also single out targets in intransparent ways for the user 
and for debugging code generation issues.

But it's your target... 

Richard 

>Thanks,
>
>Christophe
>
>> ChangeLog:
>> 2019-11-26  Wilco Dijkstra  
>>
>> PR tree-optimization/80155
>> * common/config/arm/arm-common.c
>(arm_option_optimization_table):
>> Disable -fcode-hoisting with -O3.
>> --
>>
>> diff --git a/gcc/common/config/arm/arm-common.c
>b/gcc/common/config/arm/arm-common.c
>> index
>b761d3abd670a144a593c4b410b1e7fbdcb52f56..3e11f21b7dd76cc071b645c32a6fdb4a92511279
>100644
>> --- a/gcc/common/config/arm/arm-common.c
>> +++ b/gcc/common/config/arm/arm-common.c
>> @@ -39,6 +39,8 @@ static const struct default_options
>arm_option_optimization_table[] =
>>  /* Enable section anchors by default at -O1 or higher.  */
>>  { OPT_LEVELS_1_PLUS, OPT_fsection_anchors, NULL, 1 },
>>  { OPT_LEVELS_FAST, OPT_fsched_pressure, NULL, 1 },
>> +/* Disable code hoisting with -O3 or higher.  */
>> +{ OPT_LEVELS_3_PLUS, OPT_fcode_hoisting, NULL, 0 },
>>  { OPT_LEVELS_NONE, 0, NULL, 0 }
>>};
>>

Re: [PATCH v2][ARM] Disable code hoisting with -O3 (PR80155)

[Christophe Lyon]

On Tue, 26 Nov 2019 at 16:18, Wilco Dijkstra  wrote:
>
> Hi,
>
> While code hoisting generally improves codesize, it can affect performance
> negatively. Benchmarking shows it doesn't help SPEC and negatively affects
> embedded benchmarks. Since the impact is relatively small with -O2 and mainly
> affects -O3, the simplest option is to disable code hoisting for -O3 and 
> higher.
>
> OK for commit?
>

Hi,

Some time ago, you proposed to enable code hoisting for -Os instead,
and this is the approach that was chosen
in arm-9-branch. Why are you proposing a different setting for trunk?

Thanks,

Christophe

> ChangeLog:
> 2019-11-26  Wilco Dijkstra  
>
> PR tree-optimization/80155
> * common/config/arm/arm-common.c (arm_option_optimization_table):
> Disable -fcode-hoisting with -O3.
> --
>
> diff --git a/gcc/common/config/arm/arm-common.c 
> b/gcc/common/config/arm/arm-common.c
> index 
> b761d3abd670a144a593c4b410b1e7fbdcb52f56..3e11f21b7dd76cc071b645c32a6fdb4a92511279
>  100644
> --- a/gcc/common/config/arm/arm-common.c
> +++ b/gcc/common/config/arm/arm-common.c
> @@ -39,6 +39,8 @@ static const struct default_options 
> arm_option_optimization_table[] =
>  /* Enable section anchors by default at -O1 or higher.  */
>  { OPT_LEVELS_1_PLUS, OPT_fsection_anchors, NULL, 1 },
>  { OPT_LEVELS_FAST, OPT_fsched_pressure, NULL, 1 },
> +/* Disable code hoisting with -O3 or higher.  */
> +{ OPT_LEVELS_3_PLUS, OPT_fcode_hoisting, NULL, 0 },
>  { OPT_LEVELS_NONE, 0, NULL, 0 }
>};
>

Re: [PATCH 2/2] [ARM] Add support for -mpure-code in thumb-1 (v6m)

[Christophe Lyon]

ping?

On Mon, 18 Nov 2019 at 10:00, Christophe Lyon
 wrote:
>
> On Wed, 13 Nov 2019 at 15:46, Christophe Lyon
>  wrote:
> >
> > On Tue, 12 Nov 2019 at 12:13, Richard Earnshaw (lists)
> >  wrote:
> > >
> > > On 18/10/2019 14:18, Christophe Lyon wrote:
> > > > +  bool not_supported = arm_arch_notm || flag_pic || TARGET_NEON;
> > > >
> > >
> > > This is a poor name in the context of the function as a whole.  What's
> > > not supported.  Please think of a better name so that I have some idea
> > > what the intention is.
> >
> > That's to keep most of the code common when checking if -mpure-code
> > and -mslow-flash-data are supported.
> > These 3 cases are common to the two compilation flags, and
> > -mslow-flash-data still needs to check TARGET_HAVE_MOVT in addition.
> >
> > Would "common_unsupported_modes" work better for you?
> > Or I can duplicate the "arm_arch_notm || flag_pic || TARGET_NEON" in
> > the two tests.
> >
>
> Hi,
>
> Here is an updated version, using "common_unsupported_modes" instead
> of "not_supported", and fixing the typo reported by Kyrill.
> The ChangeLog is still the same.
>
> OK?
>
> Thanks,
>
> Christophe
>
> > Thanks,
> >
> > Christophe
> >
> > >
> > > R.

[PATCH v2][ARM] Disable code hoisting with -O3 (PR80155)

[Wilco Dijkstra]

Hi,

While code hoisting generally improves codesize, it can affect performance
negatively. Benchmarking shows it doesn't help SPEC and negatively affects
embedded benchmarks. Since the impact is relatively small with -O2 and mainly
affects -O3, the simplest option is to disable code hoisting for -O3 and higher.

OK for commit?

ChangeLog:
2019-11-26  Wilco Dijkstra  

PR tree-optimization/80155
* common/config/arm/arm-common.c (arm_option_optimization_table):
Disable -fcode-hoisting with -O3.
--

diff --git a/gcc/common/config/arm/arm-common.c 
b/gcc/common/config/arm/arm-common.c
index 
b761d3abd670a144a593c4b410b1e7fbdcb52f56..3e11f21b7dd76cc071b645c32a6fdb4a92511279
 100644
--- a/gcc/common/config/arm/arm-common.c
+++ b/gcc/common/config/arm/arm-common.c
@@ -39,6 +39,8 @@ static const struct default_options 
arm_option_optimization_table[] =
 /* Enable section anchors by default at -O1 or higher.  */
 { OPT_LEVELS_1_PLUS, OPT_fsection_anchors, NULL, 1 },
 { OPT_LEVELS_FAST, OPT_fsched_pressure, NULL, 1 },
+/* Disable code hoisting with -O3 or higher.  */
+{ OPT_LEVELS_3_PLUS, OPT_fcode_hoisting, NULL, 0 },
 { OPT_LEVELS_NONE, 0, NULL, 0 }
   };
 

Ping: RFA: patch to fix PR90007

[Vladimir Makarov]

This is the patch removing discrepancy between recog and LRA insn 
recognition:


https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01842.html

Index: ChangeLog
===
--- ChangeLog	(revision 278451)
+++ ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2019-11-19  Vladimir Makarov  
+
+	PR rtl-optimization/90007
+	* recog.c (constrain_operands): Permit hard registers too for
+	memory when LRA is used.
+
 2019-11-19  Martin Liska  
 
 	* toplev.c (general_init): Move the call...
Index: recog.c
===
--- recog.c	(revision 278413)
+++ recog.c	(working copy)
@@ -2757,10 +2757,9 @@ constrain_operands (int strict, alternat
 			   /* Before reload, accept what reload can turn
   into a mem.  */
 			   || (strict < 0 && CONSTANT_P (op))
-			   /* Before reload, accept a pseudo,
+			   /* Before reload, accept a pseudo or hard register,
   since LRA can turn it into a mem.  */
-			   || (strict < 0 && targetm.lra_p () && REG_P (op)
-   && REGNO (op) >= FIRST_PSEUDO_REGISTER)
+			   || (strict < 0 && targetm.lra_p () && REG_P (op))
 			   /* During reload, accept a pseudo  */
 			   || (reload_in_progress && REG_P (op)
    && REGNO (op) >= FIRST_PSEUDO_REGISTER)))
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog	(revision 278451)
+++ testsuite/ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2019-11-19  Vladimir Makarov  
+
+	PR rtl-optimization/90007
+	* gcc.target/i386/pr90007.c: New test.
+
 2019-11-15  Andrew Sutton  
 
 	PR c++/89913
Index: testsuite/gcc.target/i386/pr90007.c
===
--- testsuite/gcc.target/i386/pr90007.c	(nonexistent)
+++ testsuite/gcc.target/i386/pr90007.c	(working copy)
@@ -0,0 +1,15 @@
+/* PR rtl-optimization/90007 */
+/* { dg-do compile { target x86_64-*-* } } */
+/* { dg-options "-march=bdver1 -mfpmath=387 -O1 -fschedule-insns -fselective-scheduling" } */
+
+void
+qj (int b9, int r9, int k4, int k0, int e7)
+{
+  (void) b9;
+  (void) r9;
+  (void) k4;
+
+  while (!!k0 == e7 * 1.1)
+{
+}
+}

[PATCH, OpenACC, v3] Non-contiguous array support for OpenACC data clauses

[Chung-Lin Tang]

Hi Thomas,
this is a reorg of the last non-contiguous arrays patch. You'll notice that:

(1) A large part of the code has been pulled into oacc-parallel.c, with most
of the data structure declarations in oacc-int.h.

(2) target.c only contains relatively little code from gomp_map_vars_internal
that processes what GOACC_parallel_keyed/data_start gives it.

(3) Instead of directly passed in the map pointer, the array descriptor
pointers are now passed to GOACC_parallel_keyed/data_start using varargs.
(I believe the adding of '...' to GOACC_data_start does not break any
compatiblity)

(4) Along the way, I've added a 'gomp_map_vars_openacc' for specializing our
uses, which should shave off quite some code through inlining.

The GOMP_MAP_NONCONTIG_ARRAY_P maps are still placed at the beginning of the
recieved map sequence in this patch. It should still be relatively easy to
use a GOACC_FLAG_* to do so if deemed better before committing.

Thanks,
Chung-Lin

PR other/76739

gcc/c/
* c-typeck.c (handle_omp_array_sections_1): Add 'bool _contiguous'
parameter, adjust recursive call site, add cases for allowing
pointer based multi-dimensional arrays for OpenACC.
(handle_omp_array_sections): Adjust handle_omp_array_sections_1 call,
handle non-contiguous case to create dynamic array map.

gcc/cp/
* semantics.c (handle_omp_array_sections_1): Add 'bool _contiguous'
parameter, adjust recursive call site, add cases for allowing
pointer based multi-dimensional arrays for OpenACC.
(handle_omp_array_sections): Adjust handle_omp_array_sections_1 call,
handle non-contiguous case to create dynamic array map.

gcc/fortran/
* f95-lang.c (DEF_FUNCTION_TYPE_VAR_5): New symbol.
* types.def (BT_FN_VOID_INT_SIZE_PTR_PTR_PTR_VAR): New type.

gcc/
* builtin-types.def (BT_FN_VOID_INT_SIZE_PTR_PTR_PTR_VAR): New type.
* omp-builtins.def (BUILT_IN_GOACC_DATA_START): Adjust function type
to new BT_FN_VOID_INT_SIZE_PTR_PTR_PTR_VAR.
* gimplify.c (gimplify_scan_omp_clauses): Skip gimplification of
OMP_CLAUSE_SIZE of non-contiguous array maps (which is a TREE_LIST).
* omp-expand.c (expand_omp_target): Add non-contiguous array descriptor
pointers to variadic arguments.
* omp-low.c (append_field_to_record_type): New function.
(create_noncontig_array_descr_type): Likewise.
(create_noncontig_array_descr_init_code): Likewise.
(scan_sharing_clauses): For non-contiguous array map kinds, check for
supported dimension structure, and install non-contiguous array
variable into current omp_context.
(reorder_noncontig_array_clauses): New function.
(scan_omp_target): Call reorder_noncontig_array_clauses to place
non-contiguous array map clauses at beginning of clause sequence.
(lower_omp_target): Add handling for non-contiguous array map kinds,
add all created non-contiguous array descriptors to
gimple_omp_target_data_arg.

gcc/testsuite/
* c-c++-common/goacc/noncontig_array-1.c: New test.

libgomp/
* libgomp_g.h (GOACC_data_start): Add variadic '...' to declaration.
* libgomp.h (gomp_map_vars_openacc): New function declaration.
* oacc-int.h (struct goacc_ncarray_dim): New struct declaration.
(struct goacc_ncarray_descr_type): Likewise.
(struct goacc_ncarray): Likewise.
(struct goacc_ncarray_info): Likewise.
(goacc_noncontig_array_create_ptrblock): New function declaration.
* oacc-parallel.c (goacc_noncontig_array_count_rows): New function.
(goacc_noncontig_array_compute_sizes): Likewise.
(goacc_noncontig_array_fill_rows_1): Likewise.
(goacc_noncontig_array_fill_rows): Likewise.
(goacc_process_noncontiguous_arrays): Likewise.
(goacc_noncontig_array_create_ptrblock): Likewise.
(GOACC_parallel_keyed): Use goacc_process_noncontiguous_arrays to
handle non-contiguous array descriptors at end of varargs, adjust
to use gomp_map_vars_openacc.
(GOACC_data_start): Likewise. Adjust function type to accept varargs.
* target.c (gomp_map_vars_internal): Add struct goacc_ncarray_info *
nca_info parameter, add handling code for non-contiguous arrays.
(gomp_map_vars_openacc): Add new function for specialization of
gomp_map_vars_internal for OpenACC structured region usage.

* testsuite/libgomp.oacc-c-c++-common/noncontig_array-1.c: New test.
* testsuite/libgomp.oacc-c-c++-common/noncontig_array-2.c: New test.
* testsuite/libgomp.oacc-c-c++-common/noncontig_array-3.c: New test.
* testsuite/libgomp.oacc-c-c++-common/noncontig_array-4.c: New test.
* testsuite/libgomp.oacc-c-c++-common/noncontig_array-utils.h: Support
header for new tests.

Index: 

Re: [PATCH, nvptx] Expand OpenACC child function arguments to use CUDA params space

[Chung-Lin Tang]

On 2019/11/8 8:55 PM, Chung-Lin Tang wrote:

On 2019/10/8 10:05 PM, Thomas Schwinge wrote:

Hi Chung-Lin!

While we're all waiting for Tom to comment on this;-)  -- here's another
item I realized:

On 2019-09-10T19:41:59+0800, Chung-Lin Tang  wrote:

The libgomp nvptx plugin changes are also quite contained, with lots of
now unneeded [...] code deleted (since we no longer first cuAlloc a
buffer for the argument record before cuLaunchKernel)

It would be nice;-)  -- but unless I'm confused, it's not that simple: we
either have to reject (force host-fallback execution) or keep supporting
"old-style" nvptx offloading code: new-libgomp has to continue to work
with nvptx offloading code once generated by old-GCC.  Possibly even a
mixture of old and new nvptx offloading code, if libraries are involved,
huh!

I have not completely thought that through, but I suppose this could be
addressed by adding a flag to the 'struct nvptx_fn' (or similar) that's
synthesized by nvptx 'mkoffload'?


Hi Thomas, Tom,
I've looked at the problem, it is unfortunate that we overlooked the
need for versioning of NVPTX images, and did not reserve something in
'struct nvptx_tdata' for something like this.

But how about something like:

typedef struct nvptx_tdata
{
   const struct targ_ptx_obj *ptx_objs;
   unsigned ptx_num;

   unsigned ptx_version; /* < Add version field here.  */

   const char *const *var_names;
   unsigned var_num;

   const struct targ_fn_launch *fn_descs;
   unsigned fn_num;
} nvptx_tdata_t;

We currently only support x86_64 and powerpc64le hosts, which are both LP64 
targets.

Assuming that, the position above where I put the new 'ptx_version' field is 
already
a 32-bit sized alignment hole, doesn't change the layout of other fields, and 
in the
static 'target_data' variable generated by mkoffload should be zeroed in current
circulating binaries (unless binutils is not doing the intuitive thing...)

If these assumptions are safe, then we can treat as if ptx_version == 0 right 
now,
and from now on bump it to 1 for these new nvptx convention changes.

(We can do a similar thing in 'struct targ_fn_launch' if we want to 
differentiate
at a per-function level.)

Any considerations?


Hi Tom, Thomas,
as a concept, here is a version of what I mentioned above. The 
_exec,_async_exec plugin
hooks now switch between versions of code based on image version.

Thanks,
Chung-Lin

gcc/
* config/nvptx/mkoffload.c (process): Add 'ptx_version' field to
generated struct nvptx_tdata, and initialized to '1'.
* config/nvptx/nvptx.c (nvptx_expand_to_rtl_hook): New function
implementing CUDA .params space transformation.
(TARGET_EXPAND_TO_RTL_HOOK): implement hook with
nvptx_expand_to_rtl_hook.

libgomp/
* plugin/plugin-nvptx.c (struct nvptx_tdata): Add 'ptx_version' field.
(struct targ_fn_descriptor): Add 'image' field.
(struct ptx_image_data): Adjust 'target_data' to be proper pointer
type of 'const nvptx_tdata_t *'.
(nvptx_exec): Adjust arguments, add kernel argument setup code,
adjust cuLaunchKernel calling code.
(GOMP_OFFLOAD_load_image): Remove now unneeded pointer cast for
target_data, initialize 'image' link for each function descriptor,
move adding of new_image to dev->images later after everythin
is set up.
(openacc_exec_v0): Rename from old GOMP_OFFLOAD_openacc_exec.
(openacc_async_exec_v0): Rename from old 
GOMP_OFFLOAD_openacc_async_exec.
(GOMP_OFFLOAD_openacc_exec): Switch between v0/v1 versions of code.
(GOMP_OFFLOAD_openacc_async_exec): Likewise.
(openacc_exec_v1): New function.
(openacc_async_exec_v1): Likewise.





Index: gcc/config/nvptx/mkoffload.c
===
--- gcc/config/nvptx/mkoffload.c(revision 278656)
+++ gcc/config/nvptx/mkoffload.c(working copy)
@@ -310,12 +310,13 @@ process (FILE *in, FILE *out)
   "static const struct nvptx_tdata {\n"
   "  const struct ptx_obj *ptx_objs;\n"
   "  unsigned ptx_num;\n"
+  "  unsigned char ptx_version;\n"
   "  const char *const *var_names;\n"
   "  unsigned var_num;\n"
   "  const struct nvptx_fn *fn_names;\n"
   "  unsigned fn_num;\n"
   "} target_data = {\n"
-  "  ptx_objs, sizeof (ptx_objs) / sizeof (ptx_objs[0]),\n"
+  "  ptx_objs, sizeof (ptx_objs) / sizeof (ptx_objs[0]), 1,\n"
   "  var_mappings,"
   "  sizeof (var_mappings) / sizeof (var_mappings[0]),\n"
   "  func_mappings,"
Index: gcc/config/nvptx/nvptx.c
===
--- gcc/config/nvptx/nvptx.c(revision 278656)
+++ gcc/config/nvptx/nvptx.c(working copy)
@@ -68,6 +68,10 @@
 #include "attribs.h"
 #include "tree-vrp.h"
 #include "tree-ssa-operands.h"
+#include 

[PATCH] Fix PR92674

[Richard Biener]

The following delays all edge pruning until inlining into a function
is complete.  This avoids crashes with stmt folding walking the
SSA use->def chain and arriving at PHIs without arguments.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

2019-11-26  Richard Biener  

PR middle-end/92674
* tree-inline.c (expand_call_inline): Delay purging EH/abnormal
edges and instead record blocks in bitmap.
(gimple_expand_calls_inline): Adjust.
(fold_marked_statements): Delay EH cleanup until all folding is
done.
(optimize_inline_calls): Do EH/abnormal cleanup for calls after
inlining finished.

Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c   (revision 278722)
+++ gcc/tree-inline.c   (working copy)
@@ -4623,7 +4623,8 @@ reset_debug_bindings (copy_body_data *id
 /* If STMT is a GIMPLE_CALL, replace it with its inline expansion.  */
 
 static bool
-expand_call_inline (basic_block bb, gimple *stmt, copy_body_data *id)
+expand_call_inline (basic_block bb, gimple *stmt, copy_body_data *id,
+   bitmap to_purge)
 {
   tree use_retvar;
   tree fn;
@@ -4768,7 +4769,7 @@ expand_call_inline (basic_block bb, gimp
   gimple_call_set_fndecl (stmt, edge->callee->decl);
   update_stmt (stmt);
   id->src_node->remove ();
-  expand_call_inline (bb, stmt, id);
+  expand_call_inline (bb, stmt, id, to_purge);
   maybe_remove_unused_call_args (cfun, stmt);
   return true;
 }
@@ -5156,10 +5157,7 @@ expand_call_inline (basic_block bb, gimp
 }
 
   if (purge_dead_abnormal_edges)
-{
-  gimple_purge_dead_eh_edges (return_block);
-  gimple_purge_dead_abnormal_call_edges (return_block);
-}
+bitmap_set_bit (to_purge, return_block->index);
 
   /* If the value of the new expression is ignored, that's OK.  We
  don't warn about this for CALL_EXPRs, so we shouldn't warn about
@@ -5197,7 +5195,8 @@ expand_call_inline (basic_block bb, gimp
in a MODIFY_EXPR.  */
 
 static bool
-gimple_expand_calls_inline (basic_block bb, copy_body_data *id)
+gimple_expand_calls_inline (basic_block bb, copy_body_data *id,
+   bitmap to_purge)
 {
   gimple_stmt_iterator gsi;
   bool inlined = false;
@@ -5209,7 +5208,7 @@ gimple_expand_calls_inline (basic_block
 
   if (is_gimple_call (stmt)
  && !gimple_call_internal_p (stmt))
-   inlined |= expand_call_inline (bb, stmt, id);
+   inlined |= expand_call_inline (bb, stmt, id, to_purge);
 }
 
   return inlined;
@@ -5222,6 +5221,7 @@ gimple_expand_calls_inline (basic_block
 static void
 fold_marked_statements (int first, hash_set *statements)
 {
+  auto_bitmap to_purge;
   for (; first < last_basic_block_for_fn (cfun); first++)
 if (BASIC_BLOCK_FOR_FN (cfun, first))
   {
@@ -5233,7 +5233,8 @@ fold_marked_statements (int first, hash_
  if (statements->contains (gsi_stmt (gsi)))
{
  gimple *old_stmt = gsi_stmt (gsi);
- tree old_decl = is_gimple_call (old_stmt) ? gimple_call_fndecl 
(old_stmt) : 0;
+ tree old_decl
+   = is_gimple_call (old_stmt) ? gimple_call_fndecl (old_stmt) : 0;
 
  if (old_decl && fndecl_built_in_p (old_decl))
{
@@ -5277,8 +5278,7 @@ fold_marked_statements (int first, hash_
 is mood anyway.  */
  if (maybe_clean_or_replace_eh_stmt (old_stmt,
  new_stmt))
-   gimple_purge_dead_eh_edges (
- BASIC_BLOCK_FOR_FN (cfun, first));
+   bitmap_set_bit (to_purge, first);
  break;
}
  gsi_next ();
@@ -5298,11 +5298,11 @@ fold_marked_statements (int first, hash_
   new_stmt);
 
  if (maybe_clean_or_replace_eh_stmt (old_stmt, new_stmt))
-   gimple_purge_dead_eh_edges (BASIC_BLOCK_FOR_FN (cfun,
-   first));
+   bitmap_set_bit (to_purge, first);
}
}
   }
+  gimple_purge_all_dead_eh_edges (to_purge);
 }
 
 /* Expand calls to inline functions in the body of FN.  */
@@ -5348,8 +5348,9 @@ optimize_inline_calls (tree fn)
  will split id->current_basic_block, and the new blocks will
  follow it; we'll trudge through them, processing their CALL_EXPRs
  along the way.  */
+  auto_bitmap to_purge;
   FOR_EACH_BB_FN (bb, cfun)
-inlined_p |= gimple_expand_calls_inline (bb, );
+inlined_p |= gimple_expand_calls_inline (bb, , to_purge);
 
   pop_gimplify_context (NULL);
 
@@ -5369,6 +5370,21 @@ optimize_inline_calls (tree fn)
   fold_marked_statements 

[PATCH] More PR92645 massaging

[Richard Biener]

The following enhances vector CTOR simplification to cover the
case where we select a vector part.  I've included testcases
for highpart, lowpart and odd/even extracts (with conversion).

The only case we cannot handle right now is conversion with
constants (but there's a latent bug there which I'm going to
fix after finding a testcase which would make that supported as well).

For PR92645 we also need widening, I'll see whether I can make that
work as well (after fixing that latent bug).

One interesting part here is that VEC_PERM_EXPR requires the same
number of output as input lanes and so for extracts we have
"don't care" values as we follow that VEC_PERM_EXPR with a
BIT_FIELD_REF for a lowpart extract.  While it looks convenient
to simply relax that VEC_PERM_EXPR constraint at this point this
would be too intrusive.  Alternatively we can have a special
permute index (say, -1) that could signal the target the lane
is "don't care" which would be more powerful.  I'm implementing
neither and simply place some random values there.

Bootstrapped on x86-64-unknonw-linux-gnu, testing in progress.

Richard.

2019-11-26  Richard Biener  

PR tree-optimization/92645
* tree-ssa-forwprop.c (simplify_vector_constructor): Handle
CTORs with just a subset of the original vectors.

* gcc.target/i386/pr92645-2.c: New testcase.
* gcc.target/i386/pr92645-3.c: Likewise.

Index: gcc/tree-ssa-forwprop.c
===
--- gcc/tree-ssa-forwprop.c (revision 278722)
+++ gcc/tree-ssa-forwprop.c (working copy)
@@ -2037,6 +2033,7 @@ simplify_vector_constructor (gimple_stmt
   tree op, op2, orig[2], type, elem_type;
   unsigned elem_size, i;
   unsigned HOST_WIDE_INT nelts;
+  unsigned HOST_WIDE_INT refnelts;
   enum tree_code conv_code;
   constructor_elt *elt;
   bool maybe_ident;
@@ -2052,7 +2049,6 @@ simplify_vector_constructor (gimple_stmt
   elem_type = TREE_TYPE (type);
   elem_size = TREE_INT_CST_LOW (TYPE_SIZE (elem_type));
 
-  vec_perm_builder sel (nelts, nelts, 1);
   orig[0] = NULL;
   orig[1] = NULL;
   conv_code = ERROR_MARK;
@@ -2061,6 +2057,7 @@ simplify_vector_constructor (gimple_stmt
   tree one_nonconstant = NULL_TREE;
   auto_vec constants;
   constants.safe_grow_cleared (nelts);
+  auto_vec, 64> elts;
   FOR_EACH_VEC_SAFE_ELT (CONSTRUCTOR_ELTS (op), i, elt)
 {
   tree ref, op1;
@@ -2079,7 +2076,8 @@ simplify_vector_constructor (gimple_stmt
TREE_TYPE (TREE_TYPE (ref)))
  && known_eq (bit_field_size (op1), elem_size)
  && constant_multiple_p (bit_field_offset (op1),
- elem_size, ))
+ elem_size, )
+ && TYPE_VECTOR_SUBPARTS (TREE_TYPE (ref)).is_constant ())
{
  unsigned int j;
  for (j = 0; j < 2; ++j)
@@ -2098,11 +2096,9 @@ simplify_vector_constructor (gimple_stmt
  if (j < 2)
{
  orig[j] = ref;
- if (j)
-   elem += nelts;
- if (elem != i)
+ if (elem != i || j != 0)
maybe_ident = false;
- sel.quick_push (elem);
+ elts.safe_push (std::make_pair (j, elem));
  continue;
}
  /* Else fallthru.  */
@@ -2131,28 +2127,41 @@ simplify_vector_constructor (gimple_stmt
  else if (!operand_equal_p (one_nonconstant, elt->value, 0))
return false;
}
-  sel.quick_push (i + nelts);
+  elts.safe_push (std::make_pair (1, i));
   maybe_ident = false;
 }
   if (i < nelts)
 return false;
 
   if (! orig[0]
-  || ! VECTOR_TYPE_P (TREE_TYPE (orig[0]))
-  || maybe_ne (TYPE_VECTOR_SUBPARTS (type),
-  TYPE_VECTOR_SUBPARTS (TREE_TYPE (orig[0]
-return false;
-
-  tree tem;
-  if (conv_code != ERROR_MARK
-  && (! supportable_convert_operation (conv_code, type,
-  TREE_TYPE (orig[0]),
-  , _code)
- || conv_code == CALL_EXPR))
+  || ! VECTOR_TYPE_P (TREE_TYPE (orig[0])))
 return false;
+  refnelts = TYPE_VECTOR_SUBPARTS (TREE_TYPE (orig[0])).to_constant ();
 
   if (maybe_ident)
 {
+  tree conv_src_type
+   = (nelts != refnelts
+  ? (conv_code != ERROR_MARK
+ ? build_vector_type (TREE_TYPE (TREE_TYPE (orig[0])), nelts)
+ : type)
+  : TREE_TYPE (orig[0]));
+  tree tem;
+  if (conv_code != ERROR_MARK
+ && (!supportable_convert_operation (conv_code, type, conv_src_type,
+ , _code)
+ || conv_code == CALL_EXPR))
+   return false;
+  if (nelts != refnelts)
+   {
+ gassign *lowpart
+   = gimple_build_assign (make_ssa_name (conv_src_type),
+  build3 (BIT_FIELD_REF, conv_src_type,
+ 

Re: [PATCH/AARCH64] Generate FRINTZ for (double)(long) under -ffast-math on aarch64

[Wilco Dijkstra]

Hi Andrew,

Could you repost your patch please to make review easier/quicker? It's no 
longer linked...

Cheers,
Wilco

Re: [PATCH] Fix libstdc++ compiling for an aarch64 multilib with big-endian.

[Wilco Dijkstra]

Hi Andrew,

> Hi if we have a aarch64 compiler that has a big-endian
> multi-lib, it fails to compile libstdc++ because
> simd_fast_mersenne_twister_engine is only defined for little-endian
> in ext/random but ext/opt_random.h thinks it is defined always.
>
> OK?  Built an aarch64-elf toolchain which has a big-endian multi-lib enabled.

This looks good to me (it's safe since the limitation is due to the generic 
version),
but I can't approve.

Wilco

Re: [Patch][Fortran] OpenACC – permit common blocks in some clauses

[Tobias Burnus]

Hi Thomas,

I now played also around common blocks with "!$acc declare 
device_resident (/block/)". [See attached test-case diff.]


Observations:

* !$acc declare has to come after the declaration of the common block. 
In terms of the spec, it just needs to be in the declaration section, 
i.e. it could also be before. – Seems as if one needs to split parsing 
and resolving clauses.


* If I just use '!$acc parallel', the used variables are copied in 
according to OpenMP 4.0 semantics, i.e. without a defaultmap clause (of 
OpenMP 4.5+; not yet in gfortran), scalars are firstprivate and arrays 
are map(fromto:). – Does this behaviour match the spec or should this 
automatically mapped to, e.g., no_create as the 'device_resident' is 
known? [Side remark: the module file does contain 
"OACC_DECLARE_DEVICE_RESIDENT".]


* If I explicitly use '!$acc parallel present(/block/)' that fails 
because present() does not permit common blocks.
(OpenACC 2.7, p36, l.1054: "For all clauses except deviceptr and 
present, the list argument may include a Fortran common block name 
enclosed within slashes"). I could use no_create, but that's not yet 
supported.


Cheers,

Tobias

diff --git a/libgomp/testsuite/libgomp.oacc-fortran/declare-5.f90 b/libgomp/testsuite/libgomp.oacc-fortran/declare-5.f90
index 3ab91147e07..fd46b02abf9 100644
--- a/libgomp/testsuite/libgomp.oacc-fortran/declare-5.f90
+++ b/libgomp/testsuite/libgomp.oacc-fortran/declare-5.f90
@@ -1,29 +1,106 @@
 ! { dg-do run }
 
 module vars
   implicit none
   real b
- !$acc declare device_resident (b)
+  !$acc declare device_resident (b)
+
+  integer :: x, y, z
+  common /block/ x, y, z
+  !$acc declare device_resident (/block/)
 end module vars
 
+subroutine set()
+  use openacc
+  implicit none
+  integer :: a(5), b(1), c, vals(7)
+  common /another/ a, b, c
+  !$acc declare device_resident (/another/)
+  if (.not. acc_is_present (a)) stop 10
+  if (.not. acc_is_present (b)) stop 11
+  if (.not. acc_is_present (c)) stop 12
+
+  vals = 99
+  !$acc parallel copyout(vals) present(a, b, c) ! OK
+! but w/o 'present', 'c' is firstprivate and a+b are 'map(fromto:'
+! additionally, OpenACC 2.7 does not permit present(/another/)
+! and no_create is not yet in the trunk (but submitted)
+a = [11,12,13,14,15]
+b = 16
+c = 47
+vals(1:5) = a
+vals(6:6) = b
+vals(7) = c
+  !$acc end parallel
+
+  if (.not. acc_is_present (a)) stop 13
+  if (.not. acc_is_present (b)) stop 14
+  if (.not. acc_is_present (c)) stop 15
+
+  if (any (vals /= [11,12,13,14,15,16,47])) stop 16
+end subroutine set
+
+subroutine check()
+  use openacc
+  implicit none
+  integer :: g, h(3), i(3)
+  common /another/ g, h, i
+  integer :: val(7)
+  !$acc declare device_resident (/another/)
+  if (.not. acc_is_present (g)) stop 20
+  if (.not. acc_is_present (h)) stop 21
+  if (.not. acc_is_present (i)) stop 22
+
+  val = 99
+  !$acc parallel copyout(val) present(g, h, i)
+val(5:7) = i
+val(1) = g
+val(2:4) = h
+  !$acc end parallel
+
+  if (.not. acc_is_present (g)) stop 23
+  if (.not. acc_is_present (h)) stop 24
+  if (.not. acc_is_present (i)) stop 25
+
+
+  !print *, val
+  if (any (val /= [11,12,13,14,15,16,47])) stop 26
+end subroutine check
+
+
 program test
   use vars
   use openacc
   implicit none
   real a
+  integer :: k
 
-  if (acc_is_present (b) .neqv. .true.) STOP 1
+  call set()
+  call check()
+
+  if (.not. acc_is_present (b)) stop 1
+  if (.not. acc_is_present (x)) stop 2
+  if (.not. acc_is_present (y)) stop 3
+  if (.not. acc_is_present (z)) stop 4
 
   a = 2.0
+  k = 42
 
-  !$acc parallel copy (a)
+  !$acc parallel copy (a, k)
 b = a
 a = 1.0
 a = a + b
+x = k
+y = 7*k - 2*x
+z = 3*y
+k = k - z + y
!$acc end parallel
 
-  if (acc_is_present (b) .neqv. .true.) STOP 2
-
-  if (a .ne. 3.0) STOP 3
+  if (.not. acc_is_present (b)) stop 5
+  if (.not. acc_is_present (x)) stop 6
+  if (.not. acc_is_present (y)) stop 7
+  if (.not. acc_is_present (z)) stop 8
 
+  if (a /= 3.0) stop 3
+  if (k /= -378) stop 3
 end program test

Re: Prevent all uses of DFP when unsupported (PR c/91985)

[Andreas Schwab]

On Nov 25 2019, Rainer Orth wrote:

> AFAICS this caused
>
> +FAIL: libstdc++-abi/abi_check
>
> on Solaris.  In libstdc++.log I find

That happens on all targets that don't support decimal float.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH][_GLIBCXX_DEBUG] Improve valid_range check

[Jonathan Wakely]

On 26/11/19 12:33 +0100, Stephan Bergmann wrote:

On 22/11/2019 18:59, Jonathan Wakely wrote:

On 22/11/19 18:38 +0100, François Dumont wrote:
    I noticed that we are not checking that iterators are not 
singular in valid_range. Moreover __check_singular signature for 
pointers is not intercepting all kind of pointers in terms of 
qualification.


    I'd like to commit it next week but considering we are in 
stage 3 I need proper acceptance.


    * include/debug/functions.h: Remove  include.
    (__check_singular_aux, __check_singular): Move...
    * include/debug/helper_functions.h:
    (__check_singular_aux, __check_singular): ...here.
    (__valid_range_aux): Adapt to use latter.
    * testsuite/25_algorithms/copy/debug/2_neg.cc: New.

Tested under Linux x86_64 normal and debug modes.


OK for trunk, thanks.


The curly braces...


diff --git a/libstdc++-v3/include/debug/helper_functions.h 
b/libstdc++-v3/include/debug/helper_functions.h
index c3e7478f649..5a858754875 100644
--- a/libstdc++-v3/include/debug/helper_functions.h
+++ b/libstdc++-v3/include/debug/helper_functions.h

[...]

@@ -138,14 +156,23 @@ namespace __gnu_debug
inline bool
__valid_range_aux(_InputIterator __first, _InputIterator __last,
  std::input_iterator_tag)
-{ return true; }
+{
+  if (__first != __last)
+   return !__check_singular(__first) && !__check_singular(__last);
+
+  return true;
+}
  template
_GLIBCXX_CONSTEXPR
inline bool
__valid_range_aux(_InputIterator __first, _InputIterator __last,
  std::random_access_iterator_tag)
-{ return __first <= __last; }
+{
+  return
+   __valid_range_aux(__first, __last, std::input_iterator_tag{})


...^^^ here...


+   && __first <= __last;
+}
  /** We have iterators, so figure out what kind of iterators they are
   *  to see if we can check the range ahead of time.
@@ -167,6 +194,9 @@ namespace __gnu_debug
  typename _Distance_traits<_InputIterator>::__type& __dist,
  std::__false_type)
{
+  if (!__valid_range_aux(__first, __last, std::input_iterator_tag{}))


...and ^^^ here are not allowed pre C++11.  Replacing those with

 std::input_iterator_tag()

should fix it.


Indeed. We should also have tests that use "-std=gnu++98
-D_GLIBCXX_DEBUG" so they'd catch this.

François, can you take care of the fix please?

Re: Prevent all uses of DFP when unsupported (PR c/91985)

[Jonathan Wakely]

On 26/11/19 00:57 +, Joseph Myers wrote:

On Mon, 25 Nov 2019, Rainer Orth wrote:


and a few more, all DFP related.  They used to be emitted by g++ for
__fundamental_type_info in libsupc++/fundamental_type_info.cc and lived
in the CXXABI_1.3.4 version.  However, since Solaris *does* lack DFP
support, that's no longer the case.  I'm uncertain how best to deal with
this, however.


As I understand it, _GLIBCXX_USE_DECIMAL_FLOAT should already have been
undefined for this target, and so std::decimal::decimal32 etc. should not
have been usable (both the header not working without that define, and the
mode attributes in the header being rejected by the front end when DFP is
unsupported).  I.e. such defines in libsupc++ would never have been usable
on this target, so I think they are something it should be safe to remove
from the ABI baseline.


If it's actually impossible that any real program could have depended
on those symbols, then I agree.

We could consider adding some useless stubs with those symbol names
(as aliases of something else?) so the symbols are still in the
library, to keep various tools happy.

[PATCH] Fix PR92669

[Richard Biener]

Committed as obvious.

Richard.

2019-11-26  Richard Biener  

PR middle-end/92669
* cfganal.c (pre_and_rev_post_order_compute_fn): Deal with
NULL pre_order.

Index: gcc/cfganal.c
===
--- gcc/cfganal.c   (revision 278681)
+++ gcc/cfganal.c   (working copy)
@@ -1030,6 +1030,8 @@ pre_and_rev_post_order_compute_fn (struc
 }
 
   /* Clear the temporarily allocated flag.  */
+  if (!rev_post_order)
+rev_post_order = pre_order;
   for (int i = 0; i < pre_order_num; ++i)
 BASIC_BLOCK_FOR_FN (fn, rev_post_order[i])->flags &= ~visited;
 

Re: [PATCH][_GLIBCXX_DEBUG] Improve valid_range check

[Stephan Bergmann]

On 22/11/2019 18:59, Jonathan Wakely wrote:

On 22/11/19 18:38 +0100, François Dumont wrote:
    I noticed that we are not checking that iterators are not singular 
in valid_range. Moreover __check_singular signature for pointers is 
not intercepting all kind of pointers in terms of qualification.


    I'd like to commit it next week but considering we are in stage 3 
I need proper acceptance.


    * include/debug/functions.h: Remove  include.
    (__check_singular_aux, __check_singular): Move...
    * include/debug/helper_functions.h:
    (__check_singular_aux, __check_singular): ...here.
    (__valid_range_aux): Adapt to use latter.
    * testsuite/25_algorithms/copy/debug/2_neg.cc: New.

Tested under Linux x86_64 normal and debug modes.


OK for trunk, thanks.


The curly braces...


diff --git a/libstdc++-v3/include/debug/helper_functions.h 
b/libstdc++-v3/include/debug/helper_functions.h
index c3e7478f649..5a858754875 100644
--- a/libstdc++-v3/include/debug/helper_functions.h
+++ b/libstdc++-v3/include/debug/helper_functions.h

[...]

@@ -138,14 +156,23 @@ namespace __gnu_debug
 inline bool
 __valid_range_aux(_InputIterator __first, _InputIterator __last,
  std::input_iterator_tag)
-{ return true; }
+{
+  if (__first != __last)
+   return !__check_singular(__first) && !__check_singular(__last);
+
+  return true;
+}
 
   template

 _GLIBCXX_CONSTEXPR
 inline bool
 __valid_range_aux(_InputIterator __first, _InputIterator __last,
  std::random_access_iterator_tag)
-{ return __first <= __last; }
+{
+  return
+   __valid_range_aux(__first, __last, std::input_iterator_tag{})


...^^^ here...


+   && __first <= __last;
+}
 
   /** We have iterators, so figure out what kind of iterators they are

*  to see if we can check the range ahead of time.
@@ -167,6 +194,9 @@ namespace __gnu_debug
  typename _Distance_traits<_InputIterator>::__type& __dist,
  std::__false_type)
 {
+  if (!__valid_range_aux(__first, __last, std::input_iterator_tag{}))


...and ^^^ here are not allowed pre C++11.  Replacing those with

  std::input_iterator_tag()

should fix it.


+   return false;
+
   __dist = __get_distance(__first, __last);
   switch (__dist.second)
{

Re: [Patch, gcc-wwdocs] Update to Fortran changes

[Tobias Burnus]

Hi Mark,

On 11/26/19 11:46 AM, Mark Eggleston wrote:
I've check the changes with W3 validator. There are no problems 
related to my changes, however, it does object to the lack of 
character encoding in the file.


Note that some script modifies the file a bit – the final file does have 
a character encoding (content="text/html; charset=utf-8").


This is the first time in changing the wwwdoc, I haven't included a 
change log as there there doesn't appear to be any ChangeLog files.


There is only a commit log (see 'git log'); the format is still a bit in 
a flux as before there was only 'csv' where it applied to a single file.


[With git it is useful to have a meaningful single line (for "git log 
--pretty=oneline") and, if needed, an empty line and something more. As 
the main repository is going to move to GIT as well, this also applies 
there. – But you already follow this style.]



The patch is attached. OK to commit?


I wonder whether you should use a main bullet point with something like 
"Legacy improvements (-fdec)" under which you put the 
current list. [Or some other wording.] That makes it easier to read for 
users – those, who care about legacy support, can quickly look at the 
-fdec changes – while those interested in standard Fortran can skip it. 
(Except for the character-diagnostic type-info improvement, all are 
items seem to be for -fdec or -fdec-…)


In particular, currently, the following item does not make clear that it 
is about legacy support: "Variables with the AUTOMATIC 
attribute can be used in EQUIVALENCE statements."


I think it can remain as is with the -fdec umbrella item. But without it 
really requires the background knowledge that the AUTOMATIC attribute is 
only available with -fdec-static (or -fdec).


Cheers,

Tobias

Re: [PATCH][ARM] Improve max_cond_insns setting for Cortex cores

[Kyrill Tkachov]

Hi Wilco,

On 11/19/19 3:11 PM, Wilco Dijkstra wrote:

ping

Various CPUs have max_cond_insns set to 5 due to historical reasons.
Benchmarking shows that max_cond_insns=2 is fastest on modern Cortex-A
cores, so change it to 2 for all Cortex-A cores.


Hmm, I'm not too confident on that. I'd support such a change for the 
generic arm_cortex_tune, definitely, and the Armv8-a based ones, but I 
don't think the argument is as strong for Cortex-A7, Cortex-A8, Cortex-A9.


So let's make the change for the Armv8-A-based cores now. If you get 
benchmarking data for the older ones (such systems may or may not be 
easy to get a hold of) we can update those separately.




  Set max_cond_insns
to 4 on Thumb-2 architectures given it's already limited to that by
MAX_INSN_PER_IT_BLOCK.  Also use the CPU tuning setting when a CPU/tune
is selected if -mrestrict-it is not explicitly set.



This can go in as a separate patch from the rest, thanks.




On Cortex-A57 this gives 1.1% performance gain on SPECINT2006 as well
as a 0.4% codesize reduction.

Bootstrapped on armhf. OK for commit?

ChangeLog:

2019-08-19  Wilco Dijkstra  

    * gcc/config/arm/arm.c (arm_option_override_internal):
    Use max_cond_insns from CPU tuning unless -mrestrict-it is used.
    (arm_v6t2_tune): set max_cond_insns to 4.
    (arm_cortex_tune): set max_cond_insns to 2.
    (arm_cortex_a8_tune): Likewise.
    (arm_cortex_a7_tune): Likewise.
    (arm_cortex_a35_tune): Likewise.
    (arm_cortex_a53_tune): Likewise.
    (arm_cortex_a5_tune): Likewise.
    (arm_cortex_a9_tune): Likewise.
    (arm_v6m_tune): set max_cond_insns to 4.


No "gcc/" in the ChangeLog path.

Thanks,

Kyrill


---

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
628cf02f23fb29392a63d87f561c3ee2fb73a515..38ac16ad1def91ca78ccfa98fd1679b2b5114851 
100644

--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -1943,7 +1943,7 @@ const struct tune_params arm_v6t2_tune =
   arm_default_branch_cost,
   _default_vec_cost,
   1,   /* Constant limit.  */
-  5,   /* Max cond insns.  */
+  4,   /* Max cond insns.  */
   8,   /* Memset max inline.  */
   1,   /* Issue rate.  */
   ARM_PREFETCH_NOT_BENEFICIAL,
@@ -1968,7 +1968,7 @@ const struct tune_params arm_cortex_tune =
   arm_default_branch_cost,
   _default_vec_cost,
   1,   /* Constant limit.  */
-  5,   /* Max cond insns.  */
+  2,   /* Max cond insns.  */
   8,   /* Memset max inline.  */
   2,   /* Issue rate.  */
   ARM_PREFETCH_NOT_BENEFICIAL,
@@ -1991,7 +1991,7 @@ const struct tune_params arm_cortex_a8_tune =
   arm_default_branch_cost,
   _default_vec_cost,
   1,   /* Constant limit.  */
-  5,   /* Max cond insns.  */
+  2,   /* Max cond insns.  */
   8,   /* Memset max inline.  */
   2,   /* Issue rate.  */
   ARM_PREFETCH_NOT_BENEFICIAL,
@@ -2014,7 +2014,7 @@ const struct tune_params arm_cortex_a7_tune =
   arm_default_branch_cost,
   _default_vec_cost,
   1,   /* Constant limit.  */
-  5,   /* Max cond insns.  */
+  2,   /* Max cond insns.  */
   8,   /* Memset max inline.  */
   2,   /* Issue rate.  */
   ARM_PREFETCH_NOT_BENEFICIAL,
@@ -2060,7 +2060,7 @@ const struct tune_params arm_cortex_a35_tune =
   arm_default_branch_cost,
   _default_vec_cost,
   1,   /* Constant limit.  */
-  5,   /* Max cond insns.  */
+  2,   /* Max cond insns.  */
   8,   /* Memset max inline.  */
   1,   /* Issue rate.  */
   ARM_PREFETCH_NOT_BENEFICIAL,
@@ -2083,7 +2083,7 @@ const struct tune_params arm_cortex_a53_tune =
   arm_default_branch_cost,
   _default_vec_cost,
   1,   /* Constant limit.  */
-  5,   /* Max cond insns.  */
+  2,   /* Max cond insns.  */
   8,   /* Memset max inline.  */
   2,   /* Issue rate.  */
   ARM_PREFETCH_NOT_BENEFICIAL,
@@ -2167,9 +2167,6 @@ const struct tune_params 

[Patch, gcc-wwdocs] Update to Fortran changes

[Mark Eggleston]

I've check the changes with W3 validator. There are no problems related 
to my changes, however, it does object to the lack of character encoding 
in the file. My knowledge of HTML is limited, so don't know how to fix that.


This is the first time in changing the wwwdoc, I haven't included a 
change log as there there doesn't appear to be any ChangeLog files.


The patch is attached. OK to commit?

--
https://www.codethink.co.uk/privacy.html

>From 2090a5d6d2e96c2a99094cd0a5f5d6e5c5bd3409 Mon Sep 17 00:00:00 2001
From: Mark Eggleston 
Date: Tue, 26 Nov 2019 10:12:44 +
Subject: [PATCH] Update Fortran changes

---
 htdocs/gcc-10/changes.html | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 52eb303..81f2280 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -206,6 +206,40 @@ a work-in-progress.
 with -std=legacy.  -Wargument-mismatch
 has been removed.
   
+  
+Default fields widths can be used for I, F
+and G format specifiers when excplicit widths are omitted.
+Use the option -fdec-format-defaults, this options is implied
+with -fdec. 
+  
+  
+A blank format item at the end of a format specification i.e. nothing
+following the final comma is allowed.  Use the option
+-fdec-blank-format-item, this options is implied with
+-fdec.
+  
+  
+Variables with the AUTOMATIC attribute can be used in
+EQUIVALENCE statements.
+  
+  
+Character type names in errors and warnings now include len
+in addition to kind, * is used for assumed
+length. The kind is omitted if it the default kind. Examples:
+CHARACTER(12), CHARACTER(6,4).
+  
+  
+Allow character literals in assignments and DATA statements
+for numeric (INTEGER, REAL, or
+COMPLEX) or LOGICAL variables.  Use the option
+-fdec-char-conversions, this options is implied with
+-fdec.
+  
+  
+DEC comparisons, i.e. allow Hollerith constants to be used in comparisons
+with INTEGER, REAL, COMPLEX and
+CHARACTER expressions. Use the option -fdec.
+  
 
 
 
-- 
1.8.3.1

Re: [PATCH] S/390: Add undef for MUSL_DYNAMIC_LINKERxx

[Szabolcs Nagy]

On 26/11/2019 09:01, Robin Dapp wrote:
> I committed this patch (obvious). It fixes the s390 bootstrap by
> undefining existing defines before redefining them.

thanks.
sorry for the trouble.

Re: [PATCH] Fix two potential memory leak

[Jan Hubicka]

> Hi,
> 
> On 2019/11/26 16:04, Jan Hubicka wrote:
> > > Summary variables should be deleted at the end of write_summary.
> > > It's first newed in generate_summary, and second newed in read_summary.
> > > Therefore, delete the first in write_summary, delete the second in
> > > execute.
> > > 
> > > gcc/ChangeLog:
> > > 
> > >   2019-11-26  Luo Xiong Hu  
> > > 
> > >   * ipa-pure-const.c (pure_const_write_summary): Fix memory leak.
> > >   * ipa-sra.c (ipa_sra_write_summary): Likewise.
> > 
> > This is not going to work with -ffat-lto-objects because in this case
> > IPA pass is executed later.  So you will need
> > if (!flag_fat_lto_objects).
> > 
> > I think most IPA passes just waits for compiler to exit with LTO rather
> > than free the summary.  ipa-fnsummary and ipa-prop allocate optimization
> > summaries, too. Are those freed?
> 
> ipa-prop is a bit different, the ipcp_transformation_sum is only created in
> read_summary, so need only delete once after execute.

It also has ipa_node_params_sum and ipa_edge_args_sum which live from
ipa-prop analysis until after ipa-inlining.
> 
> ipa-fnsummary also forgot to free the ipa summaries at the end of
> write_summary.  The pass pass_ipa_free_fn_summary will delete all summaries
> in execute.
> 
> For -ffat-lto-objects, I suppose there would be no write_summary and
> read_summary?  so summaries are also newed once and delete once?  Thanks.
> 
> Anyway, lto1 will run after cc1, which means cc1 is finished, the memory is
> freed theoretically.

With -ffat-lto-object we run full optimization pipieline at compile
time. This means that we first write summary, then execute the pass
(which uses the summary and frees it) and proceed by compilation.
With -fno-fat-lto-object the pipieline is terminated after summary
writting. By quiting compiler we free all the memory. 

We do have a lot of places where memory leaks this way and is freed at
exit. I see that for jit we added sume explicit free calls, but I think
jit is not using this path.

I am not against freeing things explicitly since it makes it easier to
identify real leaks, but we should do it systematically. Thinking of
this case probably may even lead to some memory savings because after
summary streaming the global stream is produced which is typically the
biggest object streamed.  So freeing it is OK, but please add check for
!fat lto objects and also free ipa-fnsummary (there is
ipa_free_fn_summary, ipa_free_size_summary for that) and ipa-prop
summaries.

I will also look into your changes for ipa-profile tomorrow (I suppose
you noticed this while looking into summaries for that patch :)
Honza
> 
> Xiong Hu
> 
> 
> > 
> > Honza
> > > ---
> > >   gcc/ipa-pure-const.c | 3 +++
> > >   gcc/ipa-sra.c| 5 +
> > >   2 files changed, 8 insertions(+)
> > > 
> > > diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
> > > index a142e0cc8f6..89f334cedac 100644
> > > --- a/gcc/ipa-pure-const.c
> > > +++ b/gcc/ipa-pure-const.c
> > > @@ -1260,6 +1260,9 @@ pure_const_write_summary (void)
> > >   }
> > > lto_destroy_simple_output_block (ob);
> > > +
> > > +  delete funct_state_summaries;
> > > +  funct_state_summaries = NULL;
> > >   }
> > > diff --git a/gcc/ipa-sra.c b/gcc/ipa-sra.c
> > > index c6ed0f44b87..bbc5e84edfb 100644
> > > --- a/gcc/ipa-sra.c
> > > +++ b/gcc/ipa-sra.c
> > > @@ -2671,6 +2671,11 @@ ipa_sra_write_summary (void)
> > > streamer_write_char_stream (ob->main_stream, 0);
> > > produce_asm (ob, NULL);
> > > destroy_output_block (ob);
> > > +
> > > +  ggc_delete (func_sums);
> > > +  func_sums = NULL;
> > > +  delete call_sums;
> > > +  call_sums = NULL;
> > >   }
> > >   /* Read intraprocedural analysis information about E and all of its 
> > > outgoing
> > > -- 
> > > 2.21.0.777.g83232e3864
> > > 
> 

Re: [PATCH 3/X] [libsanitizer] Add option to bootstrap using HWASAN

[Martin Liška]

On 11/20/19 3:33 PM, Martin Liška wrote:

I can come up with an upstream patch as well.


Hello.

I've just made an upstream review request for that:
https://reviews.llvm.org/D70707

Martin

Re: [PATCH] Fix two potential memory leak

[luoxhu]

Hi,

On 2019/11/26 16:04, Jan Hubicka wrote:

Summary variables should be deleted at the end of write_summary.
It's first newed in generate_summary, and second newed in read_summary.
Therefore, delete the first in write_summary, delete the second in
execute.

gcc/ChangeLog:

2019-11-26  Luo Xiong Hu  

* ipa-pure-const.c (pure_const_write_summary): Fix memory leak.
* ipa-sra.c (ipa_sra_write_summary): Likewise.


This is not going to work with -ffat-lto-objects because in this case
IPA pass is executed later.  So you will need
if (!flag_fat_lto_objects).

I think most IPA passes just waits for compiler to exit with LTO rather
than free the summary.  ipa-fnsummary and ipa-prop allocate optimization
summaries, too. Are those freed?


ipa-prop is a bit different, the ipcp_transformation_sum is only created in
read_summary, so need only delete once after execute.

ipa-fnsummary also forgot to free the ipa summaries at the end of 
write_summary.  The pass pass_ipa_free_fn_summary will delete all summaries 
in execute.


For -ffat-lto-objects, I suppose there would be no write_summary and 
read_summary?  so summaries are also newed once and delete once?  Thanks.


Anyway, lto1 will run after cc1, which means cc1 is finished, the memory is 
freed theoretically.


Xiong Hu




Honza

---
  gcc/ipa-pure-const.c | 3 +++
  gcc/ipa-sra.c| 5 +
  2 files changed, 8 insertions(+)

diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
index a142e0cc8f6..89f334cedac 100644
--- a/gcc/ipa-pure-const.c
+++ b/gcc/ipa-pure-const.c
@@ -1260,6 +1260,9 @@ pure_const_write_summary (void)
  }
  
lto_destroy_simple_output_block (ob);

+
+  delete funct_state_summaries;
+  funct_state_summaries = NULL;
  }
  
  
diff --git a/gcc/ipa-sra.c b/gcc/ipa-sra.c

index c6ed0f44b87..bbc5e84edfb 100644
--- a/gcc/ipa-sra.c
+++ b/gcc/ipa-sra.c
@@ -2671,6 +2671,11 @@ ipa_sra_write_summary (void)
streamer_write_char_stream (ob->main_stream, 0);
produce_asm (ob, NULL);
destroy_output_block (ob);
+
+  ggc_delete (func_sums);
+  func_sums = NULL;
+  delete call_sums;
+  call_sums = NULL;
  }
  
  /* Read intraprocedural analysis information about E and all of its outgoing

--
2.21.0.777.g83232e3864

[committed] Fix up libsanitizer build with master glibc

[Jakub Jelinek]

Hi!

On Tue, Nov 12, 2019 at 12:27:26PM +0100, Jakub Jelinek wrote:
> But I'm afraid I don't really have the cycles to test this on all targets,
> nor does it fix the arm be or s390 31-bit problem with shmctl.

I have committed the following change cherry-picked from upstream,
before submitting there tested on
{x86_64,i686,ppc64le,s390x,armv7hl,aarch64}-linux with both older glibc and
with master glibc (in that case the patch tweaked to have __GLIBC_PREREQ (2,
30) instead of 2, 31, so that even before the 2.31 release on a glibc known
to have the new layout it would verify what will be verified in glibc 2.31.

arm big endian and s390 31-bit is still broken for shmctl and I'm afraid
fixing that is going to be extremely hard.

2019-11-26  Jakub Jelinek  

PR sanitizer/92154
* sanitizer_common/sanitizer_platform_limits_posix.h: Cherry-pick
llvm-project revision 947f9692440836dcb8d88b74b69dd379d85974ce.
* sanitizer_common/sanitizer_platform_limits_posix.cpp: Likewise.

--- libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp   
(revision 278721)
+++ libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp   
(working copy)
@@ -1128,11 +1128,9 @@ CHECK_SIZE_AND_OFFSET(ipc_perm, uid);
 CHECK_SIZE_AND_OFFSET(ipc_perm, gid);
 CHECK_SIZE_AND_OFFSET(ipc_perm, cuid);
 CHECK_SIZE_AND_OFFSET(ipc_perm, cgid);
-#if (!defined(__aarch64__) || !SANITIZER_LINUX || __GLIBC_PREREQ (2, 21)) && \
-!defined(__arm__)
-/* On aarch64 glibc 2.20 and earlier provided incorrect mode field.  */
-/* On Arm newer glibc provide a different mode field, it's hard to detect
-   so just disable the check.  */
+#if !SANITIZER_LINUX || __GLIBC_PREREQ (2, 31)
+/* glibc 2.30 and earlier provided 16-bit mode field instead of 32-bit
+   on many architectures.  */
 CHECK_SIZE_AND_OFFSET(ipc_perm, mode);
 #endif
 
--- libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h 
(revision 278721)
+++ libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h 
(working copy)
@@ -207,26 +207,13 @@ struct __sanitizer_ipc_perm {
   u64 __unused1;
   u64 __unused2;
 #elif defined(__sparc__)
-#if defined(__arch64__)
   unsigned mode;
-  unsigned short __pad1;
-#else
-  unsigned short __pad1;
-  unsigned short mode;
   unsigned short __pad2;
-#endif
   unsigned short __seq;
   unsigned long long __unused1;
   unsigned long long __unused2;
-#elif defined(__mips__) || defined(__aarch64__) || defined(__s390x__)
-  unsigned int mode;
-  unsigned short __seq;
-  unsigned short __pad1;
-  unsigned long __unused1;
-  unsigned long __unused2;
 #else
-  unsigned short mode;
-  unsigned short __pad1;
+  unsigned int mode;
   unsigned short __seq;
   unsigned short __pad2;
 #if defined(__x86_64__) && !defined(_LP64)


Jakub

[PATCH] S/390: Add undef for MUSL_DYNAMIC_LINKERxx

[Robin Dapp]

Hi,

I committed this patch (obvious). It fixes the s390 bootstrap by
undefining existing defines before redefining them.

Regards
 Robin

--

gcc/ChangeLog:

2019-11-26  Robin Dapp  

* config/s390/linux.h: Add undef for MUSL_DYNAMIC_LINKERxx.
commit aa2879c029af2ae70067df23bc68081f62abb139
Author: Robin Dapp 
Date:   Mon Nov 25 12:26:18 2019 +0100

S/390: Add undef before definition of MUSL_DYNAMIC_LINKER.

Fix bootstrap by not defining symbols twice.

diff --git a/gcc/config/s390/linux.h b/gcc/config/s390/linux.h
index 5f6b7041f0f..b7d440543f7 100644
--- a/gcc/config/s390/linux.h
+++ b/gcc/config/s390/linux.h
@@ -75,7 +75,9 @@ along with GCC; see the file COPYING3.  If not see
 #define GLIBC_DYNAMIC_LINKER32 "/lib/ld.so.1"
 #define GLIBC_DYNAMIC_LINKER64 "/lib/ld64.so.1"
 
+#undef MUSL_DYNAMIC_LINKER32
 #define MUSL_DYNAMIC_LINKER32 "/lib/ld-musl-s390.so.1"
+#undef MUSL_DYNAMIC_LINKER64
 #define MUSL_DYNAMIC_LINKER64 "/lib/ld-musl-s390x.so.1"
 
 #undef  LINK_SPEC

Re: [PATCH] Fix phiopt minmax optimization with NULLPTR_TYPE (PR tree-optimization/92644)

[Jakub Jelinek]

On Tue, Nov 26, 2019 at 09:07:11AM +0100, Richard Biener wrote:
> OK.
> 
> It just occured to me - what if we'd use the type of the non-constant
> argument for creating the adjusted constant?  Wouldn't that avoid
> the issue as well?

No, the type type of the non-constant argument is NULLPTR_TYPE too.
I guess we could have some VRP optimization that range of NULLPTR_TYPE is
[0, 0], but I think we don't really perform VRP on
non-INTEGRAL/POINTER_TYPE_P, still, phiopt couldn't rely on that.

What could work is checking the PHI args earlier if at least one of them
matches the non-constant one, but I think that would break the
 if (a <= u)
   b = MAX (a, d);
 x = PHI 
opt.  In particular, on this exact testcase the EQ/NE transformation to
non-equality comparison is useless, as it will not really match.  But say
with pointers it could hit even if it is not useless.

Jakub

Re: [PATCH] Fix phiopt minmax optimization with NULLPTR_TYPE (PR tree-optimization/92644)

[Richard Biener]

On Tue, 26 Nov 2019, Jakub Jelinek wrote:

> Hi!
> 
> The following testcase ICEs, because we assert the only constants with
> NULLPTR_TYPE created are 0.
> 
> The fix is to perform the value adjustment of boundary value and EQ/NE
> conversion to other comparisons only for scalar integral types, not anything
> that happens to be INTEGER_CST (other types are pointers/references or
> NULLPTR_TYPE, maybe something else).
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

It just occured to me - what if we'd use the type of the non-constant
argument for creating the adjusted constant?  Wouldn't that avoid
the issue as well?

Thanks,
Richard.

> 2019-11-26  Jakub Jelinek  
> 
>   PR tree-optimization/92644
>   * tree-ssa-phiopt.c (minmax_replacement): Add INTEGRAL_TYPE_P check
>   next to INTEGER_CST checks.
> 
>   * g++.dg/opt/pr92644.C: New test.
> 
> --- gcc/tree-ssa-phiopt.c.jj  2019-11-20 09:25:42.552157763 +0100
> +++ gcc/tree-ssa-phiopt.c 2019-11-25 11:38:04.181024587 +0100
> @@ -1381,7 +1381,8 @@ minmax_replacement (basic_block cond_bb,
>  
>/* Turn EQ/NE of extreme values to order comparisons.  */
>if ((cmp == NE_EXPR || cmp == EQ_EXPR)
> -  && TREE_CODE (rhs) == INTEGER_CST)
> +  && TREE_CODE (rhs) == INTEGER_CST
> +  && INTEGRAL_TYPE_P (TREE_TYPE (rhs)))
>  {
>if (wi::eq_p (wi::to_wide (rhs), wi::min_value (TREE_TYPE (rhs
>   {
> @@ -1407,7 +1408,8 @@ minmax_replacement (basic_block cond_bb,
>larger = rhs;
>/* If we have smaller < CST it is equivalent to smaller <= CST-1.
>Likewise smaller <= CST is equivalent to smaller < CST+1.  */
> -  if (TREE_CODE (larger) == INTEGER_CST)
> +  if (TREE_CODE (larger) == INTEGER_CST
> +   && INTEGRAL_TYPE_P (TREE_TYPE (larger)))
>   {
> if (cmp == LT_EXPR)
>   {
> @@ -1435,7 +1437,8 @@ minmax_replacement (basic_block cond_bb,
>larger = gimple_cond_lhs (cond);
>/* If we have larger > CST it is equivalent to larger >= CST+1.
>Likewise larger >= CST is equivalent to larger > CST-1.  */
> -  if (TREE_CODE (smaller) == INTEGER_CST)
> +  if (TREE_CODE (smaller) == INTEGER_CST
> +   && INTEGRAL_TYPE_P (TREE_TYPE (smaller)))
>   {
> wi::overflow_type overflow;
> if (cmp == GT_EXPR)
> --- gcc/testsuite/g++.dg/opt/pr92644.C.jj 2019-11-25 11:38:34.59957 
> +0100
> +++ gcc/testsuite/g++.dg/opt/pr92644.C2019-11-25 11:39:59.630244452 
> +0100
> @@ -0,0 +1,6 @@
> +// PR tree-optimization/92644
> +// { dg-do compile { target c++14 } }
> +// { dg-options "-O2 -fno-early-inlining" }
> +
> +inline auto foo () { return nullptr; }
> +int bar () { return foo () ? 1 : 0; }
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [PATCH] Fix two potential memory leak

[Jan Hubicka]

> Summary variables should be deleted at the end of write_summary.
> It's first newed in generate_summary, and second newed in read_summary.
> Therefore, delete the first in write_summary, delete the second in
> execute.
> 
> gcc/ChangeLog:
> 
>   2019-11-26  Luo Xiong Hu  
> 
>   * ipa-pure-const.c (pure_const_write_summary): Fix memory leak.
>   * ipa-sra.c (ipa_sra_write_summary): Likewise.

This is not going to work with -ffat-lto-objects because in this case
IPA pass is executed later.  So you will need
if (!flag_fat_lto_objects).

I think most IPA passes just waits for compiler to exit with LTO rather
than free the summary.  ipa-fnsummary and ipa-prop allocate optimization
summaries, too. Are those freed?

Honza
> ---
>  gcc/ipa-pure-const.c | 3 +++
>  gcc/ipa-sra.c| 5 +
>  2 files changed, 8 insertions(+)
> 
> diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
> index a142e0cc8f6..89f334cedac 100644
> --- a/gcc/ipa-pure-const.c
> +++ b/gcc/ipa-pure-const.c
> @@ -1260,6 +1260,9 @@ pure_const_write_summary (void)
>  }
>  
>lto_destroy_simple_output_block (ob);
> +
> +  delete funct_state_summaries;
> +  funct_state_summaries = NULL;
>  }
>  
>  
> diff --git a/gcc/ipa-sra.c b/gcc/ipa-sra.c
> index c6ed0f44b87..bbc5e84edfb 100644
> --- a/gcc/ipa-sra.c
> +++ b/gcc/ipa-sra.c
> @@ -2671,6 +2671,11 @@ ipa_sra_write_summary (void)
>streamer_write_char_stream (ob->main_stream, 0);
>produce_asm (ob, NULL);
>destroy_output_block (ob);
> +
> +  ggc_delete (func_sums);
> +  func_sums = NULL;
> +  delete call_sums;
> +  call_sums = NULL;
>  }
>  
>  /* Read intraprocedural analysis information about E and all of its outgoing
> -- 
> 2.21.0.777.g83232e3864
>