Re: [PATCH] recog: Use parameter packs for operator()

[Richard Sandiford]

Sebastian Huber  writes:
> On 16/06/2020 12:42, Richard Sandiford wrote:
>
>> [...]
>> 2020-06-16  Richard Sandiford  
>>
>> gcc/
>>  * coretypes.h (first_type): New alias template.
>>  * recog.h (insn_gen_fn::operator()): Use it instead of a decltype.
>>  Remove spurious “...” and split the function type out into a typedef.
>> ---
>>   gcc/coretypes.h | 4 
>>   gcc/recog.h | 5 +++--
>>   2 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/gcc/coretypes.h b/gcc/coretypes.h
>> index cda22697cc3..01ec2e23ce2 100644
>> --- a/gcc/coretypes.h
>> +++ b/gcc/coretypes.h
>> @@ -359,6 +359,10 @@ struct kv_pair
>> const ValueType value;   /* the value of the name */
>>   };
>>   
>> +/* Alias of the first type, ignoring the second.  */
>> +template
>> +using first_type = T1;
>> +
>>   #else
>>   
>>   struct _dont_use_rtx_here_;
>> diff --git a/gcc/recog.h b/gcc/recog.h
>> index 0a71a02c4a9..d674d384723 100644
>> --- a/gcc/recog.h
>> +++ b/gcc/recog.h
>> @@ -295,9 +295,10 @@ struct insn_gen_fn
>> typedef void (*stored_funcptr) (void);
>>   
>> template
>> -  rtx_insn *operator() (Ts... args...) const
>> +  rtx_insn *operator() (Ts... args) const
>> {
>> -return ((rtx_insn *(*) (decltype(args, NULL_RTX)...)) func) (args...);
>> +typedef rtx_insn *(*funcptr) (first_type...);
>> +return ((funcptr) func) (args...);
>> }
>>   
>> // This is for compatibility of code that invokes functions like
>
> I get this error on FreeBSD 12.1 with
>
> c++ --version
> FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on 
> LLVM 8.0.1)
> Target: x86_64-unknown-freebsd12.1
> Thread model: posix
> InstalledDir: /usr/bin
>
> In file included from ../../gnu-mirror-gcc-aff95ee/gcc/function.c:51:
> ../../gnu-mirror-gcc-aff95ee/gcc/recog.h:301:30: error: too many 
> arguments to function call, expected 1, have 2
>      return ((funcptr) func) (args...);
>       ^~~~
> ../../gnu-mirror-gcc-aff95ee/gcc/function.c:3315:29: note: in 
> instantiation of function template specialization 
> 'insn_gen_fn::operator()' requested here
>      emit_insn (GEN_FCN (icode) (parmreg, validated_mem));

Thanks for the report.  Was clang OK with the earlier version
(i.e. before 4e49b994de060d4a6c9318d0ed52ef038153426e)?

Richard

Re: [PATCH] recog: Use parameter packs for operator()

[Sebastian Huber]

On 18/06/2020 09:09, Richard Sandiford wrote:


Sebastian Huber  writes:

On 16/06/2020 12:42, Richard Sandiford wrote:


[...]
2020-06-16  Richard Sandiford  

gcc/
* coretypes.h (first_type): New alias template.
* recog.h (insn_gen_fn::operator()): Use it instead of a decltype.
Remove spurious “...” and split the function type out into a typedef.
---
   gcc/coretypes.h | 4 
   gcc/recog.h | 5 +++--
   2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/gcc/coretypes.h b/gcc/coretypes.h
index cda22697cc3..01ec2e23ce2 100644
--- a/gcc/coretypes.h
+++ b/gcc/coretypes.h
@@ -359,6 +359,10 @@ struct kv_pair
 const ValueType value; /* the value of the name */
   };
   
+/* Alias of the first type, ignoring the second.  */

+template
+using first_type = T1;
+
   #else
   
   struct _dont_use_rtx_here_;

diff --git a/gcc/recog.h b/gcc/recog.h
index 0a71a02c4a9..d674d384723 100644
--- a/gcc/recog.h
+++ b/gcc/recog.h
@@ -295,9 +295,10 @@ struct insn_gen_fn
 typedef void (*stored_funcptr) (void);
   
 template

-  rtx_insn *operator() (Ts... args...) const
+  rtx_insn *operator() (Ts... args) const
 {
-return ((rtx_insn *(*) (decltype(args, NULL_RTX)...)) func) (args...);
+typedef rtx_insn *(*funcptr) (first_type...);
+return ((funcptr) func) (args...);
 }
   
 // This is for compatibility of code that invokes functions like

I get this error on FreeBSD 12.1 with

c++ --version
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on
LLVM 8.0.1)
Target: x86_64-unknown-freebsd12.1
Thread model: posix
InstalledDir: /usr/bin

In file included from ../../gnu-mirror-gcc-aff95ee/gcc/function.c:51:
../../gnu-mirror-gcc-aff95ee/gcc/recog.h:301:30: error: too many
arguments to function call, expected 1, have 2
      return ((funcptr) func) (args...);
       ^~~~
../../gnu-mirror-gcc-aff95ee/gcc/function.c:3315:29: note: in
instantiation of function template specialization
'insn_gen_fn::operator()' requested here
      emit_insn (GEN_FCN (icode) (parmreg, validated_mem));

Thanks for the report.  Was clang OK with the earlier version
(i.e. before 4e49b994de060d4a6c9318d0ed52ef038153426e)?
Yes, the last version I built successfully was 
b952c2cfcd74c284970e1b9bf1fca58f5f69ab23 on 10th of June. I build GCC 
roughly once per week.

[PATCH] Add missing check for gassign.

[Martin Liška]

Hi.

We should check for gassign before doing gimple_assign_rhs_code and friends.

Ready to be installed after proper testing?

Thanks,
Martin

gcc/ChangeLog:

* tree-vect-generic.c (expand_vector_condition): Check
for gassign before inspecting RHS.
---
 gcc/tree-vect-generic.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gcc/tree-vect-generic.c b/gcc/tree-vect-generic.c
index fb955bbf3d2..83d399a7898 100644
--- a/gcc/tree-vect-generic.c
+++ b/gcc/tree-vect-generic.c
@@ -957,8 +957,9 @@ expand_vector_condition (gimple_stmt_iterator *gsi)
 
   if (code == SSA_NAME)

 {
-  gimple *assign = SSA_NAME_DEF_STMT (a);
-  if (TREE_CODE_CLASS (gimple_assign_rhs_code (assign)) == tcc_comparison)
+  gassign *assign = dyn_cast (SSA_NAME_DEF_STMT (a));
+  if (assign != NULL
+ && TREE_CODE_CLASS (gimple_assign_rhs_code (assign)) == 
tcc_comparison)
{
  a_is_comparison = true;
  a1 = gimple_assign_rhs1 (assign);
--
2.27.0

[PATCH] rs6000: assign first operand of VEC_COND_EXPR to a SSA_NAME

[Martin Liška]

Hi.

This breaks quite some powerpc.exp tests. Right now VEC_COND_EXPR expects first
argument to be a SSA_NAME (or constant) and so the patch fixes that.

Using the patch, I survive powerpc.exp test-suite.
Ready for master?
Martin

gcc/ChangeLog:

* config/rs6000/rs6000-call.c (fold_build_vec_cmp):
Assign first argument of VEC_COND_EXPR to a SSA_NAME.
(fold_compare_helper): Pass gsi to fold_build_vec_cmp.
---
 gcc/config/rs6000/rs6000-call.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 817a14c9c0d..f613d372a13 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -10716,14 +10716,16 @@ rs6000_builtin_valid_without_lhs (enum 
rs6000_builtins fn_code)
CODE indicates which comparison is to be made. (EQ, GT, ...).
TYPE indicates the type of the result.  */
 static tree
-fold_build_vec_cmp (tree_code code, tree type,
-   tree arg0, tree arg1)
+fold_build_vec_cmp (tree_code code, tree type, tree arg0, tree arg1,
+   gimple_stmt_iterator *gsi)
 {
   tree cmp_type = truth_type_for (type);
   tree zero_vec = build_zero_cst (type);
   tree minus_one_vec = build_minus_one_cst (type);
-  tree cmp = fold_build2 (code, cmp_type, arg0, arg1);
-  return fold_build3 (VEC_COND_EXPR, type, cmp, minus_one_vec, zero_vec);
+  tree temp = create_tmp_reg_or_ssa_name (cmp_type);
+  gimple *g = gimple_build_assign (temp, code, arg0, arg1);
+  gsi_insert_before (gsi, g, GSI_SAME_STMT);
+  return fold_build3 (VEC_COND_EXPR, type, temp, minus_one_vec, zero_vec);
 }
 
 /* Helper function to handle the in-between steps for the

@@ -10734,7 +10736,7 @@ fold_compare_helper (gimple_stmt_iterator *gsi, 
tree_code code, gimple *stmt)
   tree arg0 = gimple_call_arg (stmt, 0);
   tree arg1 = gimple_call_arg (stmt, 1);
   tree lhs = gimple_call_lhs (stmt);
-  tree cmp = fold_build_vec_cmp (code, TREE_TYPE (lhs), arg0, arg1);
+  tree cmp = fold_build_vec_cmp (code, TREE_TYPE (lhs), arg0, arg1, gsi);
   gimple *g = gimple_build_assign (lhs, cmp);
   gimple_set_location (g, gimple_location (stmt));
   gsi_replace (gsi, g, true);
--
2.27.0

Re: [PATCH] recog: Use parameter packs for operator()

[Richard Sandiford]

Sebastian Huber  writes:
> On 18/06/2020 09:09, Richard Sandiford wrote:
>
>> Sebastian Huber  writes:
>>> On 16/06/2020 12:42, Richard Sandiford wrote:
>>>
 [...]
 2020-06-16  Richard Sandiford  

 gcc/
* coretypes.h (first_type): New alias template.
* recog.h (insn_gen_fn::operator()): Use it instead of a decltype.
Remove spurious “...” and split the function type out into a typedef.
 ---
gcc/coretypes.h | 4 
gcc/recog.h | 5 +++--
2 files changed, 7 insertions(+), 2 deletions(-)

 diff --git a/gcc/coretypes.h b/gcc/coretypes.h
 index cda22697cc3..01ec2e23ce2 100644
 --- a/gcc/coretypes.h
 +++ b/gcc/coretypes.h
 @@ -359,6 +359,10 @@ struct kv_pair
  const ValueType value;/* the value of the name */
};

 +/* Alias of the first type, ignoring the second.  */
 +template
 +using first_type = T1;
 +
#else

struct _dont_use_rtx_here_;
 diff --git a/gcc/recog.h b/gcc/recog.h
 index 0a71a02c4a9..d674d384723 100644
 --- a/gcc/recog.h
 +++ b/gcc/recog.h
 @@ -295,9 +295,10 @@ struct insn_gen_fn
  typedef void (*stored_funcptr) (void);

  template
 -  rtx_insn *operator() (Ts... args...) const
 +  rtx_insn *operator() (Ts... args) const
  {
 -return ((rtx_insn *(*) (decltype(args, NULL_RTX)...)) func) (args...);
 +typedef rtx_insn *(*funcptr) (first_type...);
 +return ((funcptr) func) (args...);
  }

  // This is for compatibility of code that invokes functions like
>>> I get this error on FreeBSD 12.1 with
>>>
>>> c++ --version
>>> FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on
>>> LLVM 8.0.1)
>>> Target: x86_64-unknown-freebsd12.1
>>> Thread model: posix
>>> InstalledDir: /usr/bin
>>>
>>> In file included from ../../gnu-mirror-gcc-aff95ee/gcc/function.c:51:
>>> ../../gnu-mirror-gcc-aff95ee/gcc/recog.h:301:30: error: too many
>>> arguments to function call, expected 1, have 2
>>>       return ((funcptr) func) (args...);
>>>        ^~~~
>>> ../../gnu-mirror-gcc-aff95ee/gcc/function.c:3315:29: note: in
>>> instantiation of function template specialization
>>> 'insn_gen_fn::operator()' requested here
>>>       emit_insn (GEN_FCN (icode) (parmreg, validated_mem));
>> Thanks for the report.  Was clang OK with the earlier version
>> (i.e. before 4e49b994de060d4a6c9318d0ed52ef038153426e)?
> Yes, the last version I built successfully was 
> b952c2cfcd74c284970e1b9bf1fca58f5f69ab23 on 10th of June. I build GCC 
> roughly once per week.

Hmm, yeah, can reproduce with a recentish build from clang master:

template using int_t = int;
void (*f)();
template
void g(Ts... args) {
#if A
  ((void (*)(int_t...)) f)(args...);
#elif B
  typedef void (*funcptr)(decltype((void)args, 0)...);
  ((funcptr) f)(args...);
#else
  typedef void (*funcptr)(int_t...);
  ((funcptr) f)(args...);
#endif
}
void h(int x, int y) { g(x, y); }

Works with -DA and -DB, but fails with the final version.

So it looks like the obvious choices are:

(1) Remove the typedef.
(2) Go back to using decltype.
(3) Revert the whole thing and go back to the overloads.

Not sure about (1), because it leads to awkward formatting, and would
need a comment to say “Don't use a typedef!”.  The above error shows
that we're probably close to the edge of what compilers will support
reliably.

(2) seems to work more reliably, and gives nicer error messages,
but was unpopular for being unidiomatic C++.

I guess at this point, (3) is the way to go.

Thanks,
Richard

Re: [PATCH] rs6000: assign first operand of VEC_COND_EXPR to a SSA_NAME

[Segher Boessenkool]

Hi!

On Thu, Jun 18, 2020 at 09:44:58AM +0200, Martin Liška wrote:
> This breaks quite some powerpc.exp tests. Right now VEC_COND_EXPR expects 
> first
> argument to be a SSA_NAME (or constant) and so the patch fixes that.

What does this mean?  All context is missing here.

Also, is expecting that correct or not?  Was that a change?  Please
explain.

> Using the patch, I survive powerpc.exp test-suite.

So this patch does *not* break quite some tests, it fixes them instead?

Please fix your commit message (and the Subject: even).

> diff --git a/gcc/config/rs6000/rs6000-call.c 
> b/gcc/config/rs6000/rs6000-call.c
> index 817a14c9c0d..f613d372a13 100644
> --- a/gcc/config/rs6000/rs6000-call.c
> +++ b/gcc/config/rs6000/rs6000-call.c
> @@ -10716,14 +10716,16 @@ rs6000_builtin_valid_without_lhs (enum 
> rs6000_builtins fn_code)
> CODE indicates which comparison is to be made. (EQ, GT, ...).
> TYPE indicates the type of the result.  */
>  static tree
> -fold_build_vec_cmp (tree_code code, tree type,
> - tree arg0, tree arg1)
> +fold_build_vec_cmp (tree_code code, tree type, tree arg0, tree arg1,
> + gimple_stmt_iterator *gsi)

The comment needs changing, explaining what the new arg is.


Segher

[PATCH] vect: Use vect_relevant_for_alignment_p consistently

[Yangfei (Felix)]

Hi,

  Noticed two places in tree-vect-data-refs.c where we can use function 
vect_relevant_for_alignment_p.
  Looks like these two are missed when we were introducing the function.
  Bootstrapped and tested on aarch64-linux-gnu.  OK to go?

  ChangeLog modification is contained in the patch.

Thanks,
Felix


patch-v1.diff
Description: patch-v1.diff

Re: [PATCH] Add missing check for gassign.

[Richard Biener via Gcc-patches]

On Thu, Jun 18, 2020 at 9:42 AM Martin Liška  wrote:
>
> Hi.
>
> We should check for gassign before doing gimple_assign_rhs_code and friends.
>
> Ready to be installed after proper testing?

OK.

> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * tree-vect-generic.c (expand_vector_condition): Check
> for gassign before inspecting RHS.
> ---
>   gcc/tree-vect-generic.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/tree-vect-generic.c b/gcc/tree-vect-generic.c
> index fb955bbf3d2..83d399a7898 100644
> --- a/gcc/tree-vect-generic.c
> +++ b/gcc/tree-vect-generic.c
> @@ -957,8 +957,9 @@ expand_vector_condition (gimple_stmt_iterator *gsi)
>
> if (code == SSA_NAME)
>   {
> -  gimple *assign = SSA_NAME_DEF_STMT (a);
> -  if (TREE_CODE_CLASS (gimple_assign_rhs_code (assign)) == 
> tcc_comparison)
> +  gassign *assign = dyn_cast (SSA_NAME_DEF_STMT (a));
> +  if (assign != NULL
> + && TREE_CODE_CLASS (gimple_assign_rhs_code (assign)) == 
> tcc_comparison)
> {
>   a_is_comparison = true;
>   a1 = gimple_assign_rhs1 (assign);
> --
> 2.27.0
>

[PATCH] gcc-changelog: fix Backported from timestamp.

[Martin Liška]

We should have generated:

+2020-06-17  Harald Anlauf  
+
+   Backported from master:
+   2020-06-14  Harald Anlauf  
+
+   PR fortran/95088
+   * gfortran.dg/pr95088.f90: New file.

but the script did:

+2020-06-17  Harald Anlauf  
+
+   Backported from master:
+   2020-06-17  Harald Anlauf  
+
+   PR fortran/95088
+   * class.c (get_unique_type_string): Replace use of fixed size
+   buffer by internally passing a pointer to strings.

It's fixed in the patch that I'm going to push.

Martin

contrib/ChangeLog:

* gcc-changelog/git_commit.py: Fix Backported from timestamp when
use_commit_ts=True is used.
---
 contrib/gcc-changelog/git_commit.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/contrib/gcc-changelog/git_commit.py 
b/contrib/gcc-changelog/git_commit.py
index ab9fdbd52fd..4a78793b87e 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -615,9 +615,13 @@ class GitCommit:
 timestamp = entry.datetime
 if self.cherry_pick_commit:
 timestamp = self.commit_to_date_hook(self.cherry_pick_commit)
+# it can happen that it is a cherry-pick for a different
+# repository
 if timestamp:
 timestamp = timestamp.strftime(DATE_FORMAT)
-if not timestamp or use_commit_ts:
+else:
+timestamp = current_timestamp
+elif not timestamp or use_commit_ts:
 timestamp = current_timestamp
 authors = entry.authors if entry.authors else [self.author]
 # add Co-Authored-By authors to all ChangeLog entries
--
2.27.0

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

[Martin Liška]

On 6/17/20 3:15 PM, Richard Biener wrote:

On Wed, Jun 17, 2020 at 10:50 AM Richard Biener
 wrote:


On Mon, Jun 15, 2020 at 2:20 PM Martin Liška  wrote:


On 6/15/20 1:59 PM, Richard Biener wrote:

On Mon, Jun 15, 2020 at 1:19 PM Martin Liška  wrote:


On 6/15/20 9:14 AM, Richard Biener wrote:

On Fri, Jun 12, 2020 at 3:24 PM Martin Liška  wrote:


On 6/12/20 11:43 AM, Richard Biener wrote:

So ... how far are you with enforcing a split VEC_COND_EXPR?
Thus can we avoid the above completely (even as intermediate
state)?


Apparently, I'm quite close. Using the attached patch I see only 2 testsuite
failures:

FAIL: gcc.dg/tree-ssa/pr68714.c scan-tree-dump-times reassoc1 " <= " 1
FAIL: gcc.target/i386/pr78102.c scan-assembler-times pcmpeqq 3

The first one is about teaching reassoc about the SSA_NAMEs in VEC_COND_EXPR. I 
haven't
analyze the second failure.

I'm also not sure about the gimlification change, I see a superfluous 
assignments:
  vec_cond_cmp.5 = _1 == _2;
  vec_cond_cmp.6 = vec_cond_cmp.5;
  vec_cond_cmp.7 = vec_cond_cmp.6;
  _3 = VEC_COND_EXPR ;
?

So with the suggested patch, the EH should be gone as you suggested. Right?


Right, it should be on the comparison already from the start.

@@ -14221,9 +14221,13 @@ gimplify_expr (tree *expr_p, gimple_seq
*pre_p, gimple_seq *post_p,
   case VEC_COND_EXPR:
 {
   enum gimplify_status r0, r1, r2;
-
   r0 = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p,
   post_p, is_gimple_condexpr, fb_rvalue);
+   tree xop0 = TREE_OPERAND (*expr_p, 0);
+   tmp = create_tmp_var_raw (TREE_TYPE (xop0), "vec_cond_cmp");
+   gimple_add_tmp_var (tmp);
+   gimplify_assign (tmp, xop0, pre_p);
+   TREE_OPERAND (*expr_p, 0) = tmp;
   r1 = gimplify_expr (&TREE_OPERAND (*expr_p, 1), pre_p,
   post_p, is_gimple_val, fb_rvalue);

all of VEC_COND_EXPR can now be a simple goto expr_3;


Works for me, thanks!



diff --git a/gcc/tree-ssa-forwprop.c b/gcc/tree-ssa-forwprop.c
index 494c9e9c20b..090fb52a2f1 100644
--- a/gcc/tree-ssa-forwprop.c
+++ b/gcc/tree-ssa-forwprop.c
@@ -3136,6 +3136,10 @@ pass_forwprop::execute (function *fun)
   if (code == COND_EXPR
   || code == VEC_COND_EXPR)
 {
+   /* Do not propagate into VEC_COND_EXPRs.  */
+   if (code == VEC_COND_EXPR)
+ break;
+

err - remove the || code == VEC_COND_EXPR instead?


Yep.



@@ -2221,24 +2226,12 @@ expand_vector_operations (void)
{
  gimple_stmt_iterator gsi;
  basic_block bb;
-  bool cfg_changed = false;

  FOR_EACH_BB_FN (bb, cfun)
-{
-  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
-   {
- expand_vector_operations_1 (&gsi);
- /* ???  If we do not cleanup EH then we will ICE in
-verification.  But in reality we have created wrong-code
-as we did not properly transition EH info and edges to
-the piecewise computations.  */
- if (maybe_clean_eh_stmt (gsi_stmt (gsi))
- && gimple_purge_dead_eh_edges (bb))
-   cfg_changed = true;
-   }
-}

I'm not sure about this.  Consider the C++ testcase where
the ?: is replaced by a division.  If veclower needs to replace
that with four scalrar division statements then the above
still applies - veclower does not correctly duplicate EH info
and EH edges to the individual divisions (and we do not know
which component might trap).

So please leave the above in.  You can try if using integer
division makes it break and add such a testcase if there's
no coverage for this in the testsuite.


I'm leaving that above. Can you please explain how can a division test-case
be created?


typedef long v2di __attribute__((vector_size(16)));

v2di foo (v2di a, v2di b)
{
try
{
  v2di res = a / b;
  return res;
  }
  catch (...)
  {
  return (v2di){};
  }
}

with -fnon-call-exceptions I see in t.ii.090t.ehdisp (correctly):

;;   basic block 2, loop depth 0
;;pred:   ENTRY
[LP 1] _6 = a_4(D) / b_5(D);
;;succ:   5
;;3

while after t.ii.226t.veclower we have

;;   basic block 2, loop depth 0
;;pred:   ENTRY
_13 = BIT_FIELD_REF ;
_14 = BIT_FIELD_REF ;
_15 = _13 / _14;
_16 = BIT_FIELD_REF ;
_17 = BIT_FIELD_REF ;
_18 = _16 / _17;
_6 = {_15, _18};
res_7 = _6;
_8 = res_7;
;;succ:   3

and all EH is gone and we'd ICE if you remove the above hunk.  Hopefully.


Yes, it ICEs then:


./xg++ -B. ~/Programming/testcases/ice.c -c -fnon-call-exceptions -O3
/home/marxin/Programming/testcases/ice.c: In function ‘v2di foo(v2di, v2di)’:
/home/marxin/Programming/testcases/ice.c:3:6: error: statement marked for 
throw, but doesn’t
  3 | v2di foo (v2di a, v2di b)
 

[PATCH] Fortran : ICE in gfc_check_reshape PR95585

[Mark Eggleston]

Please find attached fix for PR95585.

OK to commit and backport?

Commit message:

Fortran  : ICE in gfc_check_reshape PR95585

Issue an error where an array is used before its definition
instead of an ICE.

2020-06-18  Steven G. Kargl  

gcc/fortran/

    PR fortran/PR95585
    *check.c (gfc_check_reshape): Add check for a value when
    the symbol has an attribute flavor FL_PARAMETER.

2020-06-17  Mark Eggleston 

gcc/testsuite/

    PR fortran/95585
    * gfortran.dg/pr95585.f90: New test.


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

>From ac759f1708e6b325abdb8586ea378fe5b8a234ba Mon Sep 17 00:00:00 2001
From: Mark Eggleston 
Date: Thu, 11 Jun 2020 06:42:36 +0100
Subject: [PATCH] Fortran  : ICE in gfc_check_reshape PR95585

Issue an error where an array is used before its definition
instead of an ICE.

2020-06-18  Steven G. Kargl  

gcc/fortran/

	PR fortran/PR95585
	*check.c (gfc_check_reshape): Add check for a value when
	the symbol has an attribute flavor FL_PARAMETER.

2020-06-17  Mark Eggleston  

gcc/testsuite/

	PR fortran/95585
	* gfortran.dg/pr95585.f90: New test.
---
 gcc/fortran/check.c   | 3 ++-
 gcc/testsuite/gfortran.dg/pr95585.f90 | 6 ++
 2 files changed, 8 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr95585.f90

diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 0afb96c0414..992fbd77727 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -4739,7 +4739,8 @@ gfc_check_reshape (gfc_expr *source, gfc_expr *shape,
 	   && shape->ref->u.ar.as->lower[0]->ts.type == BT_INTEGER
 	   && shape->ref->u.ar.as->upper[0]->expr_type == EXPR_CONSTANT
 	   && shape->ref->u.ar.as->upper[0]->ts.type == BT_INTEGER
-	   && shape->symtree->n.sym->attr.flavor == FL_PARAMETER)
+	   && shape->symtree->n.sym->attr.flavor == FL_PARAMETER
+	   && shape->symtree->n.sym->value)
 {
   int i, extent;
   gfc_expr *e, *v;
diff --git a/gcc/testsuite/gfortran.dg/pr95585.f90 b/gcc/testsuite/gfortran.dg/pr95585.f90
new file mode 100644
index 000..b0e6cdc5bea
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr95585.f90
@@ -0,0 +1,6 @@
+! { dg-do compile }
+
+program test
+  integer, parameter :: a(2) = reshape([1, 2], a) ! { dg-error "before its definition" }
+end program
+
-- 
2.11.0

[PATCH] rs6000: fix creation of VEC_COND_EXPR

[Martin Liška]

On 6/18/20 10:00 AM, Segher Boessenkool wrote:

Hi!

On Thu, Jun 18, 2020 at 09:44:58AM +0200, Martin Liška wrote:

This breaks quite some powerpc.exp tests. Right now VEC_COND_EXPR expects
first
argument to be a SSA_NAME (or constant) and so the patch fixes that.


What does this mean?  All context is missing here.

Also, is expecting that correct or not?  Was that a change?  Please
explain.


Using the patch, I survive powerpc.exp test-suite.


So this patch does *not* break quite some tests, it fixes them instead?

Please fix your commit message (and the Subject: even).


diff --git a/gcc/config/rs6000/rs6000-call.c
b/gcc/config/rs6000/rs6000-call.c
index 817a14c9c0d..f613d372a13 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -10716,14 +10716,16 @@ rs6000_builtin_valid_without_lhs (enum
rs6000_builtins fn_code)
 CODE indicates which comparison is to be made. (EQ, GT, ...).
 TYPE indicates the type of the result.  */
  static tree
-fold_build_vec_cmp (tree_code code, tree type,
-   tree arg0, tree arg1)
+fold_build_vec_cmp (tree_code code, tree type, tree arg0, tree arg1,
+   gimple_stmt_iterator *gsi)


The comment needs changing, explaining what the new arg is.


Segher



All right, let's do it better.

Martin
>From 9ba94cec649ef84399531f43d5c7171328a3f704 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Thu, 18 Jun 2020 09:25:32 +0200
Subject: [PATCH] rs6000: fix creation of VEC_COND_EXPR

gcc/ChangeLog:

	* config/rs6000/rs6000-call.c (fold_build_vec_cmp):
	Since 502d63b6d6141597bb18fd23c87736a1b384cf8f, first argument
	of a VEC_COND_EXPR cannot be tcc_comparison and so that
	a SSA_NAME needs to be created before we use it for the first
	argument of the VEC_COND_EXPR.
	(fold_compare_helper): Pass gsi to fold_build_vec_cmp.
---
 gcc/config/rs6000/rs6000-call.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 817a14c9c0d..5bc6952214c 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -10714,16 +10714,19 @@ rs6000_builtin_valid_without_lhs (enum rs6000_builtins fn_code)
operation.  This sets up true/false vectors, and uses the
VEC_COND_EXPR operation.
CODE indicates which comparison is to be made. (EQ, GT, ...).
-   TYPE indicates the type of the result.  */
+   TYPE indicates the type of the result.  
+   GSI points to a GIMPLE statement that we are currently folding.  */
 static tree
-fold_build_vec_cmp (tree_code code, tree type,
-		tree arg0, tree arg1)
+fold_build_vec_cmp (tree_code code, tree type, tree arg0, tree arg1,
+		gimple_stmt_iterator *gsi)
 {
   tree cmp_type = truth_type_for (type);
   tree zero_vec = build_zero_cst (type);
   tree minus_one_vec = build_minus_one_cst (type);
-  tree cmp = fold_build2 (code, cmp_type, arg0, arg1);
-  return fold_build3 (VEC_COND_EXPR, type, cmp, minus_one_vec, zero_vec);
+  tree temp = create_tmp_reg_or_ssa_name (cmp_type);
+  gimple *g = gimple_build_assign (temp, code, arg0, arg1);
+  gsi_insert_before (gsi, g, GSI_SAME_STMT);
+  return fold_build3 (VEC_COND_EXPR, type, temp, minus_one_vec, zero_vec);
 }
 
 /* Helper function to handle the in-between steps for the
@@ -10734,7 +10737,7 @@ fold_compare_helper (gimple_stmt_iterator *gsi, tree_code code, gimple *stmt)
   tree arg0 = gimple_call_arg (stmt, 0);
   tree arg1 = gimple_call_arg (stmt, 1);
   tree lhs = gimple_call_lhs (stmt);
-  tree cmp = fold_build_vec_cmp (code, TREE_TYPE (lhs), arg0, arg1);
+  tree cmp = fold_build_vec_cmp (code, TREE_TYPE (lhs), arg0, arg1, gsi);
   gimple *g = gimple_build_assign (lhs, cmp);
   gimple_set_location (g, gimple_location (stmt));
   gsi_replace (gsi, g, true);
-- 
2.27.0

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

[Richard Biener via Gcc-patches]

On Thu, Jun 18, 2020 at 10:10 AM Martin Liška  wrote:
>
> On 6/17/20 3:15 PM, Richard Biener wrote:
> > On Wed, Jun 17, 2020 at 10:50 AM Richard Biener
> >  wrote:
> >>
> >> On Mon, Jun 15, 2020 at 2:20 PM Martin Liška  wrote:
> >>>
> >>> On 6/15/20 1:59 PM, Richard Biener wrote:
>  On Mon, Jun 15, 2020 at 1:19 PM Martin Liška  wrote:
> >
> > On 6/15/20 9:14 AM, Richard Biener wrote:
> >> On Fri, Jun 12, 2020 at 3:24 PM Martin Liška  wrote:
> >>>
> >>> On 6/12/20 11:43 AM, Richard Biener wrote:
>  So ... how far are you with enforcing a split VEC_COND_EXPR?
>  Thus can we avoid the above completely (even as intermediate
>  state)?
> >>>
> >>> Apparently, I'm quite close. Using the attached patch I see only 2 
> >>> testsuite
> >>> failures:
> >>>
> >>> FAIL: gcc.dg/tree-ssa/pr68714.c scan-tree-dump-times reassoc1 " <= " 1
> >>> FAIL: gcc.target/i386/pr78102.c scan-assembler-times pcmpeqq 3
> >>>
> >>> The first one is about teaching reassoc about the SSA_NAMEs in 
> >>> VEC_COND_EXPR. I haven't
> >>> analyze the second failure.
> >>>
> >>> I'm also not sure about the gimlification change, I see a superfluous 
> >>> assignments:
> >>>   vec_cond_cmp.5 = _1 == _2;
> >>>   vec_cond_cmp.6 = vec_cond_cmp.5;
> >>>   vec_cond_cmp.7 = vec_cond_cmp.6;
> >>>   _3 = VEC_COND_EXPR  >>> -1, -1 }, { 0, 0, 0, 0, 0, 0, 0, 0 }>;
> >>> ?
> >>>
> >>> So with the suggested patch, the EH should be gone as you suggested. 
> >>> Right?
> >>
> >> Right, it should be on the comparison already from the start.
> >>
> >> @@ -14221,9 +14221,13 @@ gimplify_expr (tree *expr_p, gimple_seq
> >> *pre_p, gimple_seq *post_p,
> >>case VEC_COND_EXPR:
> >>  {
> >>enum gimplify_status r0, r1, r2;
> >> -
> >>r0 = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p,
> >>post_p, is_gimple_condexpr, 
> >> fb_rvalue);
> >> +   tree xop0 = TREE_OPERAND (*expr_p, 0);
> >> +   tmp = create_tmp_var_raw (TREE_TYPE (xop0), 
> >> "vec_cond_cmp");
> >> +   gimple_add_tmp_var (tmp);
> >> +   gimplify_assign (tmp, xop0, pre_p);
> >> +   TREE_OPERAND (*expr_p, 0) = tmp;
> >>r1 = gimplify_expr (&TREE_OPERAND (*expr_p, 1), pre_p,
> >>post_p, is_gimple_val, fb_rvalue);
> >>
> >> all of VEC_COND_EXPR can now be a simple goto expr_3;
> >
> > Works for me, thanks!
> >
> >>
> >> diff --git a/gcc/tree-ssa-forwprop.c b/gcc/tree-ssa-forwprop.c
> >> index 494c9e9c20b..090fb52a2f1 100644
> >> --- a/gcc/tree-ssa-forwprop.c
> >> +++ b/gcc/tree-ssa-forwprop.c
> >> @@ -3136,6 +3136,10 @@ pass_forwprop::execute (function *fun)
> >>if (code == COND_EXPR
> >>|| code == VEC_COND_EXPR)
> >>  {
> >> +   /* Do not propagate into VEC_COND_EXPRs.  */
> >> +   if (code == VEC_COND_EXPR)
> >> + break;
> >> +
> >>
> >> err - remove the || code == VEC_COND_EXPR instead?
> >
> > Yep.
> >
> >>
> >> @@ -2221,24 +2226,12 @@ expand_vector_operations (void)
> >> {
> >>   gimple_stmt_iterator gsi;
> >>   basic_block bb;
> >> -  bool cfg_changed = false;
> >>
> >>   FOR_EACH_BB_FN (bb, cfun)
> >> -{
> >> -  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
> >> -   {
> >> - expand_vector_operations_1 (&gsi);
> >> - /* ???  If we do not cleanup EH then we will ICE in
> >> -verification.  But in reality we have created wrong-code
> >> -as we did not properly transition EH info and edges to
> >> -the piecewise computations.  */
> >> - if (maybe_clean_eh_stmt (gsi_stmt (gsi))
> >> - && gimple_purge_dead_eh_edges (bb))
> >> -   cfg_changed = true;
> >> -   }
> >> -}
> >>
> >> I'm not sure about this.  Consider the C++ testcase where
> >> the ?: is replaced by a division.  If veclower needs to replace
> >> that with four scalrar division statements then the above
> >> still applies - veclower does not correctly duplicate EH info
> >> and EH edges to the individual divisions (and we do not know
> >> which component might trap).
> >>
> >> So please leave the above in.  You can try if using integer
> >> division makes it break and add such a testcase if there's
> >> no coverage for this in the testsuite.
> >
> > I'm leaving that above. Can you please explain how can a division 
> > test-case
> > be c

Re: [PATCH] rs6000: fix creation of VEC_COND_EXPR

[Richard Biener via Gcc-patches]

On Thu, Jun 18, 2020 at 10:21 AM Martin Liška  wrote:
>
> On 6/18/20 10:00 AM, Segher Boessenkool wrote:
> > Hi!
> >
> > On Thu, Jun 18, 2020 at 09:44:58AM +0200, Martin Liška wrote:
> >> This breaks quite some powerpc.exp tests. Right now VEC_COND_EXPR expects
> >> first
> >> argument to be a SSA_NAME (or constant) and so the patch fixes that.
> >
> > What does this mean?  All context is missing here.
> >
> > Also, is expecting that correct or not?  Was that a change?  Please
> > explain.

And to explain - yes, VEC_COND_EXPR was changed to no longer allow
an embedded comparison operand.

> >> Using the patch, I survive powerpc.exp test-suite.
> >
> > So this patch does *not* break quite some tests, it fixes them instead?
> >
> > Please fix your commit message (and the Subject: even).
> >
> >> diff --git a/gcc/config/rs6000/rs6000-call.c
> >> b/gcc/config/rs6000/rs6000-call.c
> >> index 817a14c9c0d..f613d372a13 100644
> >> --- a/gcc/config/rs6000/rs6000-call.c
> >> +++ b/gcc/config/rs6000/rs6000-call.c
> >> @@ -10716,14 +10716,16 @@ rs6000_builtin_valid_without_lhs (enum
> >> rs6000_builtins fn_code)
> >>  CODE indicates which comparison is to be made. (EQ, GT, ...).
> >>  TYPE indicates the type of the result.  */
> >>   static tree
> >> -fold_build_vec_cmp (tree_code code, tree type,
> >> -tree arg0, tree arg1)
> >> +fold_build_vec_cmp (tree_code code, tree type, tree arg0, tree arg1,
> >> +gimple_stmt_iterator *gsi)
> >
> > The comment needs changing, explaining what the new arg is.
> >
> >
> > Segher
> >
>
> All right, let's do it better.
>
> Martin

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

[Martin Liška]

On 6/18/20 10:52 AM, Richard Biener wrote:

On Thu, Jun 18, 2020 at 10:10 AM Martin Liška  wrote:


On 6/17/20 3:15 PM, Richard Biener wrote:

On Wed, Jun 17, 2020 at 10:50 AM Richard Biener
 wrote:


On Mon, Jun 15, 2020 at 2:20 PM Martin Liška  wrote:


On 6/15/20 1:59 PM, Richard Biener wrote:

On Mon, Jun 15, 2020 at 1:19 PM Martin Liška  wrote:


On 6/15/20 9:14 AM, Richard Biener wrote:

On Fri, Jun 12, 2020 at 3:24 PM Martin Liška  wrote:


On 6/12/20 11:43 AM, Richard Biener wrote:

So ... how far are you with enforcing a split VEC_COND_EXPR?
Thus can we avoid the above completely (even as intermediate
state)?


Apparently, I'm quite close. Using the attached patch I see only 2 testsuite
failures:

FAIL: gcc.dg/tree-ssa/pr68714.c scan-tree-dump-times reassoc1 " <= " 1
FAIL: gcc.target/i386/pr78102.c scan-assembler-times pcmpeqq 3

The first one is about teaching reassoc about the SSA_NAMEs in VEC_COND_EXPR. I 
haven't
analyze the second failure.

I'm also not sure about the gimlification change, I see a superfluous 
assignments:
   vec_cond_cmp.5 = _1 == _2;
   vec_cond_cmp.6 = vec_cond_cmp.5;
   vec_cond_cmp.7 = vec_cond_cmp.6;
   _3 = VEC_COND_EXPR ;
?

So with the suggested patch, the EH should be gone as you suggested. Right?


Right, it should be on the comparison already from the start.

@@ -14221,9 +14221,13 @@ gimplify_expr (tree *expr_p, gimple_seq
*pre_p, gimple_seq *post_p,
case VEC_COND_EXPR:
  {
enum gimplify_status r0, r1, r2;
-
r0 = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p,
post_p, is_gimple_condexpr, fb_rvalue);
+   tree xop0 = TREE_OPERAND (*expr_p, 0);
+   tmp = create_tmp_var_raw (TREE_TYPE (xop0), "vec_cond_cmp");
+   gimple_add_tmp_var (tmp);
+   gimplify_assign (tmp, xop0, pre_p);
+   TREE_OPERAND (*expr_p, 0) = tmp;
r1 = gimplify_expr (&TREE_OPERAND (*expr_p, 1), pre_p,
post_p, is_gimple_val, fb_rvalue);

all of VEC_COND_EXPR can now be a simple goto expr_3;


Works for me, thanks!



diff --git a/gcc/tree-ssa-forwprop.c b/gcc/tree-ssa-forwprop.c
index 494c9e9c20b..090fb52a2f1 100644
--- a/gcc/tree-ssa-forwprop.c
+++ b/gcc/tree-ssa-forwprop.c
@@ -3136,6 +3136,10 @@ pass_forwprop::execute (function *fun)
if (code == COND_EXPR
|| code == VEC_COND_EXPR)
  {
+   /* Do not propagate into VEC_COND_EXPRs.  */
+   if (code == VEC_COND_EXPR)
+ break;
+

err - remove the || code == VEC_COND_EXPR instead?


Yep.



@@ -2221,24 +2226,12 @@ expand_vector_operations (void)
 {
   gimple_stmt_iterator gsi;
   basic_block bb;
-  bool cfg_changed = false;

   FOR_EACH_BB_FN (bb, cfun)
-{
-  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
-   {
- expand_vector_operations_1 (&gsi);
- /* ???  If we do not cleanup EH then we will ICE in
-verification.  But in reality we have created wrong-code
-as we did not properly transition EH info and edges to
-the piecewise computations.  */
- if (maybe_clean_eh_stmt (gsi_stmt (gsi))
- && gimple_purge_dead_eh_edges (bb))
-   cfg_changed = true;
-   }
-}

I'm not sure about this.  Consider the C++ testcase where
the ?: is replaced by a division.  If veclower needs to replace
that with four scalrar division statements then the above
still applies - veclower does not correctly duplicate EH info
and EH edges to the individual divisions (and we do not know
which component might trap).

So please leave the above in.  You can try if using integer
division makes it break and add such a testcase if there's
no coverage for this in the testsuite.


I'm leaving that above. Can you please explain how can a division test-case
be created?


typedef long v2di __attribute__((vector_size(16)));

v2di foo (v2di a, v2di b)
{
 try
 {
   v2di res = a / b;
   return res;
   }
   catch (...)
   {
   return (v2di){};
   }
}

with -fnon-call-exceptions I see in t.ii.090t.ehdisp (correctly):

;;   basic block 2, loop depth 0
;;pred:   ENTRY
 [LP 1] _6 = a_4(D) / b_5(D);
;;succ:   5
;;3

while after t.ii.226t.veclower we have

;;   basic block 2, loop depth 0
;;pred:   ENTRY
 _13 = BIT_FIELD_REF ;
 _14 = BIT_FIELD_REF ;
 _15 = _13 / _14;
 _16 = BIT_FIELD_REF ;
 _17 = BIT_FIELD_REF ;
 _18 = _16 / _17;
 _6 = {_15, _18};
 res_7 = _6;
 _8 = res_7;
;;succ:   3

and all EH is gone and we'd ICE if you remove the above hunk.  Hopefully.


Yes, it ICEs then:


./xg++ -B. ~/Programming/testcases/ice.c -c -fnon-call-exceptions -O3
/home/marxin/Programming/testcases/ice.c: In function ‘v2di foo(v2di, v2

Re: [PATCH] recog: Use parameter packs for operator()

[Jonathan Wakely via Gcc-patches]

On 18/06/20 08:55 +0100, Richard Sandiford wrote:

Sebastian Huber  writes:

On 18/06/2020 09:09, Richard Sandiford wrote:


Sebastian Huber  writes:

On 16/06/2020 12:42, Richard Sandiford wrote:


[...]
2020-06-16  Richard Sandiford  

gcc/
* coretypes.h (first_type): New alias template.
* recog.h (insn_gen_fn::operator()): Use it instead of a decltype.
Remove spurious “...” and split the function type out into a typedef.
---
   gcc/coretypes.h | 4 
   gcc/recog.h | 5 +++--
   2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/gcc/coretypes.h b/gcc/coretypes.h
index cda22697cc3..01ec2e23ce2 100644
--- a/gcc/coretypes.h
+++ b/gcc/coretypes.h
@@ -359,6 +359,10 @@ struct kv_pair
 const ValueType value; /* the value of the name */
   };

+/* Alias of the first type, ignoring the second.  */
+template
+using first_type = T1;
+
   #else

   struct _dont_use_rtx_here_;
diff --git a/gcc/recog.h b/gcc/recog.h
index 0a71a02c4a9..d674d384723 100644
--- a/gcc/recog.h
+++ b/gcc/recog.h
@@ -295,9 +295,10 @@ struct insn_gen_fn
 typedef void (*stored_funcptr) (void);

 template
-  rtx_insn *operator() (Ts... args...) const
+  rtx_insn *operator() (Ts... args) const
 {
-return ((rtx_insn *(*) (decltype(args, NULL_RTX)...)) func) (args...);
+typedef rtx_insn *(*funcptr) (first_type...);
+return ((funcptr) func) (args...);
 }

 // This is for compatibility of code that invokes functions like

I get this error on FreeBSD 12.1 with

c++ --version
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on
LLVM 8.0.1)
Target: x86_64-unknown-freebsd12.1
Thread model: posix
InstalledDir: /usr/bin

In file included from ../../gnu-mirror-gcc-aff95ee/gcc/function.c:51:
../../gnu-mirror-gcc-aff95ee/gcc/recog.h:301:30: error: too many
arguments to function call, expected 1, have 2
      return ((funcptr) func) (args...);
       ^~~~
../../gnu-mirror-gcc-aff95ee/gcc/function.c:3315:29: note: in
instantiation of function template specialization
'insn_gen_fn::operator()' requested here
      emit_insn (GEN_FCN (icode) (parmreg, validated_mem));

Thanks for the report.  Was clang OK with the earlier version
(i.e. before 4e49b994de060d4a6c9318d0ed52ef038153426e)?

Yes, the last version I built successfully was
b952c2cfcd74c284970e1b9bf1fca58f5f69ab23 on 10th of June. I build GCC
roughly once per week.


Hmm, yeah, can reproduce with a recentish build from clang master:

template using int_t = int;
void (*f)();
template
void g(Ts... args) {
#if A
 ((void (*)(int_t...)) f)(args...);
#elif B
 typedef void (*funcptr)(decltype((void)args, 0)...);
 ((funcptr) f)(args...);
#else
 typedef void (*funcptr)(int_t...);
 ((funcptr) f)(args...);
#endif
}
void h(int x, int y) { g(x, y); }

Works with -DA and -DB, but fails with the final version.

So it looks like the obvious choices are:

(1) Remove the typedef.
(2) Go back to using decltype.
(3) Revert the whole thing and go back to the overloads.

Not sure about (1), because it leads to awkward formatting, and would
need a comment to say “Don't use a typedef!”.  The above error shows
that we're probably close to the edge of what compilers will support
reliably.


That's extremely surprising. It's basic C++11 and so Clang should have
been able to do it 10+ years ago. I'll look into it.


(2) seems to work more reliably, and gives nicer error messages,
but was unpopular for being unidiomatic C++.

I guess at this point, (3) is the way to go.


Yuck, (2) is better than (3).

I'm not massively fond of (2) but (3) is horrible and just unnecessary
with variadics.

Re: [PATCH] vectorizer: add _bb_vec_info::const_iterator

[Jonathan Wakely via Gcc-patches]

On 18/06/20 07:34 +0100, Richard Sandiford wrote:

Thanks for the comments, just had a question about one of them…

Jonathan Wakely  writes:

On 16/06/20 15:14 +0100, Richard Sandiford wrote:

Martin Li?ka  writes:

On 6/16/20 10:50 AM, Richard Sandiford wrote:
Hmm, sounds like a nice abstraction but I see 2 problems with that:

1) How can I define a constructor of the iterator_pair when I need something 
like:
iterator_pair (region_begin, region_end)?


Not sure if I'm answering the right question, sorry, but I meant
something along the lines of:

 template
 struct iterator_pair
 {
 public:
   iterator_pair (const T &begin, const T &end)
 : m_begin (begin), m_end (end) {}

   T begin () const { return m_begin; }
   T end () const { return m_end; }

 private:
   T m_begin;
   T m_end;
 };


You could also add an "object generator" for that type:

template
iterator_range
make_iterator_range(T begin, T end)
{
   return iterator_range(begin, end);
}

This deduces the type T from the function arguments, so will allow you
to write:

   return make_iterator_range(x, y);

instead of:

   return iterator_range(x, y);

i.e. you don't need to say  because the compiler can
deduce it from the arguments.


In Martin's case the x and y arguments don't naturally have type
const_iterator, so I guess this would become:

 return make_iterator_range (const_iterator (x), const_iterator (y));


Ah yes, of course..


Is that more idiomatic than:

 return iterator_range (x, y);

?


Idiomatic or not, the make_iterator_range function is more verbose, so
defeats the purpose of using it.

[PATCH] avoid early asm output

[Richard Biener]

This avoids early assembler output via the gimplifier creating
new static CTORs.  The output machinery seems to be prepared to
output constants recursively and it's just a matter of
appropriately defering or not defering output.

This also has the advantage of not outputting .string for
optimized away local aggregate initializers containing string
references.

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

2020-06-18  Richard Biener  

* varasm.c (assemble_variable): Make sure to not
defer output when outputting addressed constants.
(output_constant_def_contents): Likewise.
(add_constant_to_table): Take and pass on whether to
defer output.
(output_addressed_constants): Likewise.
(output_constant_def): Pass on whether to defer output
to add_constant_to_table.
(tree_output_constant_def): Defer output of constants.
---
 gcc/varasm.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/gcc/varasm.c b/gcc/varasm.c
index 4070f9c17e8..84df52013d7 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -110,7 +110,7 @@ static void decode_addr_const (tree, class addr_const *);
 static hashval_t const_hash_1 (const tree);
 static int compare_constant (const tree, const tree);
 static void output_constant_def_contents (rtx);
-static void output_addressed_constants (tree);
+static void output_addressed_constants (tree, int);
 static unsigned HOST_WIDE_INT output_constant (tree, unsigned HOST_WIDE_INT,
   unsigned int, bool, bool);
 static void globalize_decl (tree);
@@ -2272,7 +2272,7 @@ assemble_variable (tree decl, int top_level 
ATTRIBUTE_UNUSED,
 
   /* Output any data that we will need to use the address of.  */
   if (DECL_INITIAL (decl) && DECL_INITIAL (decl) != error_mark_node)
-output_addressed_constants (DECL_INITIAL (decl));
+output_addressed_constants (DECL_INITIAL (decl), 0);
 
   /* dbxout.c needs to know this.  */
   if (sect && (sect->common.flags & SECTION_CODE) != 0)
@@ -3426,11 +3426,11 @@ build_constant_desc (tree exp)
already have labels.  */
 
 static constant_descriptor_tree *
-add_constant_to_table (tree exp)
+add_constant_to_table (tree exp, int defer)
 {
   /* The hash table methods may call output_constant_def for addressed
  constants, so handle them first.  */
-  output_addressed_constants (exp);
+  output_addressed_constants (exp, defer);
 
   /* Sanity check to catch recursive insertion.  */
   static bool inserting;
@@ -3474,7 +3474,7 @@ add_constant_to_table (tree exp)
 rtx
 output_constant_def (tree exp, int defer)
 {
-  struct constant_descriptor_tree *desc = add_constant_to_table (exp);
+  struct constant_descriptor_tree *desc = add_constant_to_table (exp, defer);
   maybe_output_constant_def_contents (desc, defer);
   return desc->rtl;
 }
@@ -3544,7 +3544,7 @@ output_constant_def_contents (rtx symbol)
 
   /* Make sure any other constants whose addresses appear in EXP
  are assigned label numbers.  */
-  output_addressed_constants (exp);
+  output_addressed_constants (exp, 0);
 
   /* We are no longer deferring this constant.  */
   TREE_ASM_WRITTEN (decl) = TREE_ASM_WRITTEN (exp) = 1;
@@ -3608,7 +3608,7 @@ lookup_constant_def (tree exp)
 tree
 tree_output_constant_def (tree exp)
 {
-  struct constant_descriptor_tree *desc = add_constant_to_table (exp);
+  struct constant_descriptor_tree *desc = add_constant_to_table (exp, 1);
   tree decl = SYMBOL_REF_DECL (XEXP (desc->rtl, 0));
   varpool_node::finalize_decl (decl);
   return decl;
@@ -4327,7 +4327,7 @@ compute_reloc_for_constant (tree exp)
Indicate whether an ADDR_EXPR has been encountered.  */
 
 static void
-output_addressed_constants (tree exp)
+output_addressed_constants (tree exp, int defer)
 {
   tree tem;
 
@@ -4347,21 +4347,21 @@ output_addressed_constants (tree exp)
tem = DECL_INITIAL (tem);
 
   if (CONSTANT_CLASS_P (tem) || TREE_CODE (tem) == CONSTRUCTOR)
-   output_constant_def (tem, 0);
+   output_constant_def (tem, defer);
 
   if (TREE_CODE (tem) == MEM_REF)
-   output_addressed_constants (TREE_OPERAND (tem, 0));
+   output_addressed_constants (TREE_OPERAND (tem, 0), defer);
   break;
 
 case PLUS_EXPR:
 case POINTER_PLUS_EXPR:
 case MINUS_EXPR:
-  output_addressed_constants (TREE_OPERAND (exp, 1));
+  output_addressed_constants (TREE_OPERAND (exp, 1), defer);
   gcc_fallthrough ();
 
 CASE_CONVERT:
 case VIEW_CONVERT_EXPR:
-  output_addressed_constants (TREE_OPERAND (exp, 0));
+  output_addressed_constants (TREE_OPERAND (exp, 0), defer);
   break;
 
 case CONSTRUCTOR:
@@ -4369,7 +4369,7 @@ output_addressed_constants (tree exp)
unsigned HOST_WIDE_INT idx;
FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (exp), idx, tem)
  if (tem != 0)
-   output_addressed_constants (tem);
+   output_addressed_constants (te

[Ada] Small improvement to Optimize_Length_Comparison

[Pierre-Marie de Rodat]

This just changes Optimize_Length_Comparison to accept 32-bit values in
the full unsigned range, so that the length of all arrays with a 32-bit
or smaller index can be optimized.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Eric Botcazou  

gcc/ada/

* exp_ch4.adb (Optimize_Length_Comparison): Accept 32-bit values
in the full unsigned range.--- gcc/ada/exp_ch4.adb
+++ gcc/ada/exp_ch4.adb
@@ -13898,13 +13898,14 @@ package body Exp_Ch4 is
 end if;
  end if;
 
- --  Here we have to make sure of being within 32-bits
+ --  Here we have to make sure of being within a 32-bit range (take the
+ --  full unsigned range so the length of 32-bit arrays is accepted).
 
  Determine_Range (N, OK, Lo, Hi, Assume_Valid => True);
 
  if not OK
or else Lo < Uint_0
-   or else Hi > UI_From_Int (Int'Last)
+   or else Hi > Uint_2 ** 32
  then
 return False;
  end if;

[Ada] Small adjustment to Get_Integer_Type function

[Pierre-Marie de Rodat]

The Get_Integer_Type function is used by the expander when generating
code for the Enum_Rep and Pos attributes applied to an enumeration type.
The expansion generates a direct conversion from the enumeration type
to the result type, which is nominally Universal_Integer; therefore,
in order to preserve the size information, an intermediate conversion
to a smaller integer type is introduced by means of Get_Integer_Type.

The type is picked based on the RM_Size of the base type, which means
that it may not be large enough to handle invalid values of this base
type, which might seem desirable for the Enum_Rep and Pos attributes.

So this changes the function to use the Esize of the base type instead,
and also to return an unsigned type, which is more consistent with the
enumeration type source.  There is also a small tweak for CCG.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Eric Botcazou  

gcc/ada/

* exp_attr.adb (Get_Integer_Type): Pick an unsigned type based
on the Esize of the base type of the input type.--- gcc/ada/exp_attr.adb
+++ gcc/ada/exp_attr.adb
@@ -1750,23 +1750,25 @@ package body Exp_Attr is
   --
 
   function Get_Integer_Type (Typ : Entity_Id) return Entity_Id is
- Siz : constant Uint := RM_Size (Base_Type (Typ));
+ Siz : constant Uint := Esize (Base_Type (Typ));
  Int_Typ : Entity_Id;
 
   begin
- --  We need to accommodate unsigned values
+ --  We need to accommodate invalid values of the base type since we
+ --  accept them for Enum_Rep and Pos, so we reason on the Esize. And
+ --  we use an unsigned type since the enumeration type is unsigned.
 
- if Siz < RM_Size (Standard_Short_Short_Integer) then
-Int_Typ := Standard_Short_Short_Integer;
+ if Siz <= Esize (Standard_Short_Short_Unsigned) then
+Int_Typ := Standard_Short_Short_Unsigned;
 
- elsif Siz < RM_Size (Standard_Short_Integer) then
-Int_Typ := Standard_Short_Integer;
+ elsif Siz <= Esize (Standard_Short_Unsigned) then
+Int_Typ := Standard_Short_Unsigned;
 
- elsif Siz < RM_Size (Standard_Integer) then
-Int_Typ := Standard_Integer;
+ elsif Siz <= Esize (Standard_Unsigned) then
+Int_Typ := Standard_Unsigned;
 
  else
-Int_Typ := Standard_Long_Long_Integer;
+raise Program_Error;
  end if;
 
  return Int_Typ;

[Ada] Fix failed assertion on a slice indexed by a subtype_indication

[Pierre-Marie de Rodat]

An assignment with a slice indexed by a subtype_indication, e.g.:

   Y : T := X (Positive range Low .. High);

is expanded into:

   [subtype S is Positive range Low .. High;]
   Y : S := X (Positive range Low .. High);

The bounds of the target subtype S were queried with Scalar_Range, which
might return N_Subtype_Indication node (as documented in einfo.ads) and
we didn't expect it. Now fixed.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Piotr Trojanek  

gcc/ada/

* checks.adb (Generate_Index_Checks): Handle
N_Subtype_Indication returned from Scalar_Range.--- gcc/ada/checks.adb
+++ gcc/ada/checks.adb
@@ -6842,6 +6842,10 @@ package body Checks is
   elsif Nkind_In (A_Idx, N_Identifier, N_Expanded_Name) then
  A_Range := Scalar_Range (Entity (A_Idx));
 
+ if Nkind (A_Range) = N_Subtype_Indication then
+A_Range := Range_Expression (Constraint (A_Range));
+ end if;
+
   else pragma Assert (Nkind (A_Idx) = N_Subtype_Indication);
  A_Range := Range_Expression (Constraint (A_Idx));
   end if;

[Ada] The definition of constants in declare expressions is an interfering context

[Pierre-Marie de Rodat]

The definition of constants can be nested inside declare expressions in
which case they cannot be considered as valid contexts for calls to
volatile functions and access to volatile variable.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Claire Dross  

gcc/ada/

* sem_util.adb (Is_OK_Volatile_Context): Return False on
definitions of constants declared in declare expressions.--- gcc/ada/sem_util.adb
+++ gcc/ada/sem_util.adb
@@ -17298,6 +17298,7 @@ package body Sem_Util is
   elsif Nkind (Context) = N_Object_Declaration
 and then Present (Expression (Context))
 and then Expression (Context) = Obj_Ref
+and then Nkind (Parent (Context)) /= N_Expression_With_Actions
   then
  Obj_Id := Defining_Entity (Context);
 

[Ada] AI12-0293-1 Implement storage streams

[Pierre-Marie de Rodat]

This patch implements storage streams, as specified by three Ada Issues:
AI12-0293-1, AI12-0329-1, and AI12-0361-1.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Bob Duff  

gcc/ada/

* libgnat/a-strsto.ads, libgnat/a-ststbo.adb,
libgnat/a-ststbo.ads, libgnat/a-ststun.adb,
libgnat/a-ststun.ads: New files, containing packages
Ada.Streams.Storage, Ada.Streams.Storage.Bounded, and
Ada.Streams.Storage.Unbounded.
* impunit.adb, Makefile.rtl: Add new file names.--- gcc/ada/Makefile.rtl
+++ gcc/ada/Makefile.rtl
@@ -274,6 +274,9 @@ GNATRTL_NONTASKING_OBJS= \
   a-stouut$(objext) \
   a-strbou$(objext) \
   a-stream$(objext) \
+  a-strsto$(objext) \
+  a-ststbo$(objext) \
+  a-ststun$(objext) \
   a-strfix$(objext) \
   a-strhas$(objext) \
   a-string$(objext) \

--- gcc/ada/impunit.adb
+++ gcc/ada/impunit.adb
@@ -635,7 +635,10 @@ package body Impunit is
 ("a-stoufi", T),  -- Ada.Strings.Text_Output.Files
 ("a-stobfi", T),  -- Ada.Strings.Text_Output.Basic_Files
 ("a-stobbu", T),  -- Ada.Strings.Text_Output.Bit_Buckets
-("a-stoufo", T)   -- Ada.Strings.Text_Output.Formatting
+("a-stoufo", T),  -- Ada.Strings.Text_Output.Formatting
+("a-strsto", T),  -- Ada.Streams.Storage
+("a-ststbo", T),  -- Ada.Streams.Storage.Bounded
+("a-ststun", T)   -- Ada.Streams.Storage.Unbounded
);
 
---

--- /dev/null
new file mode 100644
+++ gcc/ada/libgnat/a-strsto.ads
@@ -0,0 +1,45 @@
+--
+--  --
+-- GNAT LIBRARY COMPONENTS  --
+--  --
+--   A D A . S T R E A M S . S T O R A G E  --
+--  --
+-- S p e c  --
+--  --
+-- Copyright (C) 2020, Free Software Foundation, Inc.   --
+--  --
+-- This specification is derived from the Ada Reference Manual for use with --
+-- GNAT. The copyright notice above, and the license provisions that follow --
+-- apply solely to the  contents of the part following the private keyword. --
+--  --
+-- GNAT is free software;  you can  redistribute it  and/or modify it under --
+-- terms of the  GNU General Public License as published  by the Free Soft- --
+-- ware  Foundation;  either version 3,  or (at your option) any later ver- --
+-- sion.  GNAT is distributed in the hope that it will be useful, but WITH- --
+-- OUT ANY WARRANTY;  without even the  implied warranty of MERCHANTABILITY --
+-- or FITNESS FOR A PARTICULAR PURPOSE. --
+--  --
+-- As a special exception under Section 7 of GPL version 3, you are granted --
+-- additional permissions described in the GCC Runtime Library Exception,   --
+-- version 3.1, as published by the Free Software Foundation.   --
+--  --
+-- You should have received a copy of the GNU General Public License and--
+-- a copy of the GCC Runtime Library Exception along with this program; --
+-- see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see--
+-- .  --
+--  --
+--
+
+pragma Ada_2020;
+package Ada.Streams.Storage with Pure is
+
+   type Storage_Stream_Type is abstract new Root_Stream_Type with private;
+
+   function Element_Count
+ (Stream : Storage_Stream_Type) return Stream_Element_Count is abstract;
+
+   procedure Clear (Stream : in out Storage_Stream_Type) is abstract;
+
+private
+   type Storage_Stream_Type is abstract new Root_Stream_Type with null record;
+end Ada.Streams.Storage;

--- /dev/null
new file mode 100644
+++ gcc/ada/libgnat/a-ststbo.adb
@@ -0,0 +1,115 @@
+--
+--  --
+-- GNAT LIBRARY COMPONENTS  --
+--  --
+--   A D A . S T R E A M S . S T O R A G E . B O U N D E D  --
+--  --
+--   

[Ada] List aspect Relaxed_Initialization in GNAT RM

[Pierre-Marie de Rodat]

Aspect Relaxed_Initialization and attribute Initialized are now listed
as implementation-defined with a reference to the SPARK RM, where their
full description will appear shortly.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Piotr Trojanek  

gcc/ada/

* doc/gnat_rm/implementation_defined_aspects.rst
(Relaxed_Initialization): New implementation-defined aspect.
* doc/gnat_rm/implementation_defined_attributes.rst
(Initialized): New implementation-defined attribute.
* gnat_rm.texi: Regenerate.

patch.diff.gz
Description: application/gzip

[Ada] Do not treat pragma Compile_Time_Warning as error even with -gnatwe

[Pierre-Marie de Rodat]

Not treating 'pragma Compile_Time_Warning' warnings as errors even with
the -gnatwe switch makes sense because if users desire errors, they
can use the Compile_Time_Error pragma.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Ghjuvan Lacambre  

gcc/ada/

* erroutc.ads: Declare new Is_Compile_Time_Msg boolean,
add new Compile_Time_Pragma field to Error_Msg_Object type.
(Count_Compile_Time_Pragma_Warnings): New function.
* erroutc.adb (Count_Compile_Time_Pragma_Warnings): New
function.
(Compilation_Errors): Take Compile_Time warnings into account
when tallying Errors/Warnings.
* errout.ads (Error_Msg): New procedure.
* errout.adb (Error_Msg): New procedure.
(Error_Msg_Internal): Set new Compile_Time_Pragma field in
Error_Msg_Object.
* errutil.adb (Error_Msg): Set new Compile_Time_Pragma field in
Error_Msg_Object.
* sem_prag.adb (Validate_Compile_Time_Warning_Or_Error): Pass
True to new Error_Msg procedure.
* doc/gnat_rm/implementation_defined_pragmas.rst: Update doc for
the Compile_Time_Warning pragma.
* gnat_rm.texi: Regenerate.
* opt.ads: Update comment.

patch.diff.gz
Description: application/gzip

[Ada] Missing error on aspects Input and Output

[Pierre-Marie de Rodat]

The frontend does not report an error on the illegal use of a non
class-wide subprogram with class-wide aspects Input and Output;
similarly it also skips reporting the error when a class-wide subprogram
is used with the non class-wide aspects.  As a consequence of not
reporting these errors at compile time errors are reported at link time
as undefined symbols.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Javier Miranda  

gcc/ada/

* sem_ch13.adb (Has_Good_Profile): Enforce strictness in the
check. Required to detect wrong profiles for Input and Output.
(Analyze_Stream_TSS_Definition): Minor enhancement in the text
of the error for class-wide attributes.--- gcc/ada/sem_ch13.adb
+++ gcc/ada/sem_ch13.adb
@@ -5019,33 +5019,14 @@ package body Sem_Ch13 is
 
Typ := Etype (F);
 
-   --  If the attribute specification comes from an aspect
-   --  specification for a class-wide stream, the parameter must be
-   --  a class-wide type of the entity to which the aspect applies.
-
-   if From_Aspect_Specification (N)
- and then Class_Present (Parent (N))
- and then Is_Class_Wide_Type (Typ)
-   then
-  Typ := Etype (Typ);
-   end if;
-
 else
Typ := Etype (Subp);
 end if;
 
 --  Verify that the prefix of the attribute and the local name for
---  the type of the formal match, or one is the class-wide of the
---  other, in the case of a class-wide stream operation.
-
-if Base_Type (Typ) = Base_Type (Ent)
-  or else (Is_Class_Wide_Type (Typ)
-and then Typ = Class_Wide_Type (Base_Type (Ent)))
-  or else (Is_Class_Wide_Type (Ent)
-and then Ent = Class_Wide_Type (Base_Type (Typ)))
-then
-   null;
-else
+--  the type of the formal match.
+
+if Base_Type (Typ) /= Base_Type (Ent) then
return False;
 end if;
 
@@ -5158,7 +5139,13 @@ package body Sem_Ch13 is
 
  else
 Error_Msg_Name_1 := Attr;
-Error_Msg_N ("incorrect expression for% attribute", Expr);
+
+if Is_Class_Wide_Type (Base_Type (Ent)) then
+   Error_Msg_N
+ ("incorrect expression for class-wide% attribute", Expr);
+else
+   Error_Msg_N ("incorrect expression for% attribute", Expr);
+end if;
  end if;
   end Analyze_Stream_TSS_Definition;
 

[Ada] Add second warning for convention C_Variadic_n

[Pierre-Marie de Rodat]

This adds a second warning related to the new C_Variadic_n convention,
for the cases where the aspect/pragma is applied to a subprogram with
exactly n parameters since, in this case, the aspect/pragma is useless.

The warning is given as such:

btest.ads:16:05: warning: subprogram should have at least 4 parameters

for an aspect/pragma C_Variadic_3.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Eric Botcazou  

gcc/ada/

* sem_prag.adb (Process_Convention): Give a warning on C_Variadic_n
being applied to a subprogram with exactly n parameters.--- gcc/ada/sem_prag.adb
+++ gcc/ada/sem_prag.adb
@@ -8323,11 +8323,21 @@ package body Sem_Prag is
  Next_Formal (Formal);
   end loop;
 
+  --  Error out if the number of parameters is lower than n
+
   if Count < Minimum then
  Error_Msg_Uint_1 := UI_From_Int (Minimum);
  Error_Pragma_Arg
("argument of pragma% must have at least"
 & "^ parameters", Arg2);
+
+  --  But warn if it is exactly n because this is useless
+
+  elsif Count = Minimum then
+ Error_Msg_Uint_1 := UI_From_Int (Minimum + 1);
+ Error_Msg_N
+   ("??subprogram should have at least ^ parameters",
+Get_Pragma_Arg (Arg2));
   end if;
end;
 end if;

[Ada] Improve compile-time evaluation of value ranges

[Pierre-Marie de Rodat]

The main goal of this change is to improve the evaluation at compile
time of the ranges of values that an expression can have at run time
and to apply it in as many cases as possible during the compilation.

It turns out that the front-end contains two separate engines that
can evaluate value ranges at compile time: the historical one is in
Determine_Range and is used in most cases, and the more recent but
more specialized one is in Minimize_Eliminate_Overflows and is used
for the -gnato2 and -gnato3 compilation modes.

The latter is more complete and more precise for arithmetic expressions
so the main change is to make it independent and use it in lieu of the
former in Determine_Range for arithmetic expressions. Two additional
improvements are made to Determine_Range: the built-in cache is made
aware of expression rewriting and more attributes are handled.

As a prerequisite of the last change, the compile-time evaluation of
some attributes is moved from the expander to the semantic analyzer.
This in particular covers Position, First_Bit and Last_Bit, which have
nontrivial semantics in Ada 2005 when a component clause with reverse
bit order is specified.

The main visible effect of the change is to prevent the compiler from
generating arithmetic checks that can never fail at low optimization.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Eric Botcazou  

gcc/ada/

* checks.adb (Compute_Range_For_Arithmetic_Op): New procedure to
compute a range for an arithmetical operation extracted from...
(Minimize_Eliminate_Overflows): ...here.  Call it.
(Determine_Range_Cache_O): New cache for Original_Node nodes.
(Determine_Range): Call Compute_Range_For_Arithmetic_Op for all
arithmetic expressions. Use Attribute_Id in lieu of Attribute_Name
for attributes. Add handling for Range_Length alongside Length.
Add specific handling for Alignment, Bit, First_Bit, Last_Bit,
Max_Size_In_Storage_Elements, Position, Bit_Position,
Component_Size, Object_Size, Size, Value_Size, Descriptor_Size.
(Enable_Overflow_Check): Omit the check for Abs and Minus if the
operand cannot be the largest negative number.
(Selected_Length_Checks): Use Pos for Number_Dimensions.
* exp_attr.adb (Expand_N_Attribute_Reference): Move compile-time
handling of Bit_Position, Descriptor_Size, First_Bit, Last_Bit
and Position to...
* sem_attr.adb (Eval_Attribute): ...here.  Move up Alignment for
objects and use Compile_Time_Known_Attribute in this case too.

patch.diff.gz
Description: application/gzip

[Ada] ACATS 4.1L - B452002 - Wrong universal access "=" rules

[Pierre-Marie de Rodat]

This ACATS test shows that:

- GNAT does not allow a named access type in the universal access
  "=" operator.
- GNAT does not enforce the static matching requirement for designated
  elementary and array types.
- GNAT does not allow designated types where one covers the other.
- GNAT does not enforce the subtype conformance requirement on
  access-to-subprogram types that are used in the universal access "=".

All these issues are fixed here by ensuring that we use
Is_Anonymous_Access_Type consistently, and by introducing new predicates
Check_Access_Object_Types, Check_Compatible_Profiles and
Reference_Anonymous_Access_Type.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Arnaud Charlet  

gcc/ada/

* sem_ch4.adb (Find_Equality_Types.Check_Access_Object_Types):
New function, used to implement RM 4.5.2 (9.6/2).
(Find_Equality_Types.Check_Compatible_Profiles): New function,
used to implement RM 4.5.2(9.7/2).
(Find_Equality_Types.Reference_Anonymous_Access_Type): New
function.
(Find_Equality_Types.Try_One_Interp): Fix handling of anonymous
access types which was accepting both too much and too little.
Remove accumulated special and incomplete cases for
instantiations, replaced by Has_Compatible_Type.
(Analyze_Overloaded_Selected_Component): Use
Is_Anonymous_Access_Type instead of Ekind_In.
* sem_res.adb: Code cleanup and bug fix: use
Is_Anonymous_Access_Type instead of Ekind_In.  Relax checking of
anonymous access parameter when universal_access "=" is
involved.
* sem_type.adb: Likewise.
(Find_Unique_Type): Move code from here...
(Specific_Type): ...to here. Also add missing handling of access
to class wide types.
* einfo.ads, einfo.adb (Is_Access_Object_Type): New.--- gcc/ada/einfo.adb
+++ gcc/ada/einfo.adb
@@ -3644,6 +3644,11 @@ package body Einfo is
-- Classification Functions --
--
 
+   function Is_Access_Object_Type   (Id : E) return B is
+   begin
+  return Is_Access_Type (Id) and then not Is_Access_Subprogram_Type (Id);
+   end Is_Access_Object_Type;
+
function Is_Access_Type  (Id : E) return B is
begin
   return Ekind (Id) in Access_Kind;

--- gcc/ada/einfo.ads
+++ gcc/ada/einfo.ads
@@ -2331,6 +2331,9 @@ package Einfo is
 --Is_Access_Type (synthesized)
 --   Applies to all entities, true for access types and subtypes
 
+--Is_Access_Object_Type (synthesized)
+--   Applies to all entities, true for access-to-object types and subtypes
+
 --Is_Activation_Record (Flag305)
 --   Applies to E_In_Parameters generated in Exp_Unst for nested
 --   subprograms, to mark the added formal that carries the activation
@@ -7588,6 +7591,7 @@ package Einfo is
--  Is_Generic_Type where the Ekind does not provide the needed
--  information).
 
+   function Is_Access_Object_Type   (Id : E) return B;
function Is_Access_Type  (Id : E) return B;
function Is_Access_Protected_Subprogram_Type (Id : E) return B;
function Is_Access_Subprogram_Type   (Id : E) return B;

--- gcc/ada/sem_ch4.adb
+++ gcc/ada/sem_ch4.adb
@@ -3929,15 +3929,13 @@ package body Sem_Ch4 is
  and then Is_Visible_Component (Comp, Sel)
then
 
-  --  AI05-105:  if the context is an object renaming with
+  --  AI05-105: if the context is an object renaming with
   --  an anonymous access type, the expected type of the
   --  object must be anonymous. This is a name resolution rule.
 
   if Nkind (Parent (N)) /= N_Object_Renaming_Declaration
 or else No (Access_Definition (Parent (N)))
-or else Ekind (Etype (Comp)) = E_Anonymous_Access_Type
-or else
-  Ekind (Etype (Comp)) = E_Anonymous_Access_Subprogram_Type
+or else Is_Anonymous_Access_Type (Etype (Comp))
   then
  Set_Entity (Sel, Comp);
  Set_Etype (Sel, Etype (Comp));
@@ -6542,13 +6540,33 @@ package body Sem_Ch4 is
   Op_Id : Entity_Id;
   N : Node_Id)
is
-  Index : Interp_Index;
+  Index : Interp_Index := 0;
   It: Interp;
   Found : Boolean := False;
   I_F   : Interp_Index;
   T_F   : Entity_Id;
   Scop  : Entity_Id := Empty;
 
+  function Check_Access_Object_Types
+(N : Node_Id; Typ : Entity_Id) return Boolean;
+  --  Check for RM 4.5.2 (9.6/2): When both are of access-to-object types,
+  --  the designated types shall be the same or one shall cover the other,
+  --  and if the designated types are elementary or array types, then the
+  --  designated subtypes shall statically match.
+  --  If N is not overloade

[Ada] Fix host/target confusion for attribute To_Address

[Pierre-Marie de Rodat]

The check applied to the expression of the To_Address attribute in
the case where it is static is done with the address size of the
host instead of the target, resulting in missing error messages.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Eric Botcazou  

gcc/ada/

* sem_attr.adb (Analyze_Attribute) : Use the address
size of the target instead of the host when checking the value of
a static expression.  Also use standard idiom for exponentiation.--- gcc/ada/sem_attr.adb
+++ gcc/ada/sem_attr.adb
@@ -6274,9 +6274,9 @@ package body Sem_Attr is
  if Is_OK_Static_Expression (E1) then
 Val := Expr_Value (E1);
 
-if Val < -(2 ** UI_From_Int (Standard'Address_Size - 1))
+if Val < -(Uint_2 ** (System_Address_Size - 1))
  or else
-   Val > 2 ** UI_From_Int (Standard'Address_Size) - 1
+   Val > Uint_2 ** System_Address_Size - 1
 then
Error_Attr ("address value out of range for % attribute", E1);
 end if;
@@ -6293,7 +6293,7 @@ package body Sem_Attr is
 elsif Val < 0 then
Set_Etype (E1, Universal_Integer);
 
---  Otherwise set type to Unsigned_64 to accommodate max values
+--  Otherwise set type to Unsigned_64 to accommodate large values
 
 else
Set_Etype (E1, Standard_Unsigned_64);

[Ada] Minor cleanup in Expand_Call_Helper

[Pierre-Marie de Rodat]

This makes a couple of changes in the code dealing with a call to a
derived subprogram: first, it removes useless calls to Relocate_Node
before calls to OK_Convert_To and Unchecked_Convert_To (these functions
already call Relocate_Node on their second operand) and merge calls to
Analyze and Resolve; second, it removes the generation of a potential
range check for the actual against the formal's type of the derived
subprogram after the conversion (and thus a potential range check)
to the formal's type of the parent subprogram, which does not seem
to serve any useful purpose.

No functional changes.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Eric Botcazou  

gcc/ada/

* exp_ch6.adb (Expand_Call_Helper): Remove superfluous calls
to Relocate_Node and merge calls to Analyze and Resolve in a
couple of places.  Do not attempt to generate a range check
for an actual parameter against the formal's type of a derived
subprogram after generating a conversion to the formal's type
of the parent subprogram.--- gcc/ada/exp_ch6.adb
+++ gcc/ada/exp_ch6.adb
@@ -4666,9 +4666,8 @@ package body Exp_Ch6 is
 
procedure Convert (Act : Node_Id; Typ : Entity_Id) is
begin
-  Rewrite (Act, OK_Convert_To (Typ, Relocate_Node (Act)));
-  Analyze (Act);
-  Resolve (Act, Typ);
+  Rewrite (Act, OK_Convert_To (Typ, Act));
+  Analyze_And_Resolve (Act, Typ);
end Convert;
 
--  Local variables
@@ -4686,8 +4685,8 @@ package body Exp_Ch6 is
   Formal_Typ := Etype (Formal);
   Parent_Typ := Etype (Parent_Formal);
 
-  --  For an IN parameter of a scalar type, the parent formal
-  --  type and derived formal type differ or the parent formal
+  --  For an IN parameter of a scalar type, the derived formal
+  --  type and parent formal type differ, and the parent formal
   --  type and actual type do not match statically.
 
   if Is_Scalar_Type (Formal_Typ)
@@ -4698,15 +4697,6 @@ package body Exp_Ch6 is
 and then not Raises_Constraint_Error (Actual)
   then
  Convert (Actual, Parent_Typ);
- Enable_Range_Check (Actual);
-
- --  If the actual has been marked as requiring a range
- --  check, then generate it here.
-
- if Do_Range_Check (Actual) then
-Generate_Range_Check
-  (Actual, Etype (Formal), CE_Range_Check_Failed);
- end if;
 
   --  For access types, the parent formal type and actual type
   --  differ.
@@ -4728,10 +4718,8 @@ package body Exp_Ch6 is
 --  inlined.
 
 Rewrite (Actual,
-  Unchecked_Convert_To (Parent_Typ,
-Relocate_Node (Actual)));
-Analyze (Actual);
-Resolve (Actual, Parent_Typ);
+  Unchecked_Convert_To (Parent_Typ, Actual));
+Analyze_And_Resolve (Actual, Parent_Typ);
  end if;
 
   --  If there is a change of representation, then generate a

[Ada] Update output of verbose error summary

[Pierre-Marie de Rodat]

GNAT does not count warnings originating from a Compile_Time_Warning
pragma as an error anymore, even if the -gnatwe flag is provided. This
requires updating the output of its error summary.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Ghjuvan Lacambre  

gcc/ada/

* errout.adb (Write_Error_Summary): Display number of warnings
treated as errors.
* errutil.ads: Update comment.--- gcc/ada/errout.adb
+++ gcc/ada/errout.adb
@@ -1870,30 +1870,77 @@ package body Errout is
 Write_Str (" errors");
  end if;
 
- if Warnings_Detected - Warning_Info_Messages /= 0 then
-Write_Str (", ");
-Write_Int (Warnings_Detected);
-Write_Str (" warning");
+ --  We now need to output warnings. When using -gnatwe, all warnings
+ --  should be treated as errors, except for warnings originating from
+ --  the use of the Compile_Time_Warning pragma. Another situation
+ --  where a warning might be treated as an error is when the source
+ --  code contains a Warning_As_Error pragma.
+ --  When warnings are treated as errors, we still log them as
+ --  warnings, but we add a message denoting how many of these warnings
+ --  are also errors.
 
-if Warnings_Detected - Warning_Info_Messages /= 1 then
-   Write_Char ('s');
-end if;
+ declare
+Warnings_Count : constant Int :=
+   Warnings_Detected - Warning_Info_Messages;
+
+Compile_Time_Warnings : Int;
+--  Number of warnings that come from a Compile_Time_Warning
+--  pragma.
+
+Non_Compile_Time_Warnings : Int;
+--  Number of warnings that do not come from a Compile_Time_Warning
+--  pragmas.
 
-if Warning_Mode = Treat_As_Error then
-   Write_Str (" (treated as error");
+ begin
+if Warnings_Count > 0 then
+   Write_Str (", ");
+   Write_Int (Warnings_Count);
+   Write_Str (" warning");
 
-   if Warnings_Detected /= 1 then
+   if Warnings_Count > 1 then
   Write_Char ('s');
end if;
 
-   Write_Char (')');
+   Compile_Time_Warnings := Count_Compile_Time_Pragma_Warnings;
+   Non_Compile_Time_Warnings :=
+  Warnings_Count - Compile_Time_Warnings;
+
+   if Warning_Mode = Treat_As_Error
+ and then Non_Compile_Time_Warnings > 0
+   then
+  Write_Str (" (");
+
+  if Compile_Time_Warnings > 0 then
+ Write_Int (Non_Compile_Time_Warnings);
+ Write_Str (" ");
+  end if;
+
+  Write_Str ("treated as error");
 
-elsif Warnings_Treated_As_Errors /= 0 then
-   Write_Str (" (");
-   Write_Int (Warnings_Treated_As_Errors);
-   Write_Str (" treated as errors)");
+  if Non_Compile_Time_Warnings > 1 then
+ Write_Char ('s');
+  end if;
+
+  Write_Char (')');
+
+   elsif Warnings_Treated_As_Errors > 0 then
+  Write_Str (" (");
+
+  if Warnings_Treated_As_Errors /= Warnings_Count then
+ Write_Int (Warnings_Treated_As_Errors);
+ Write_Str (" ");
+  end if;
+
+  Write_Str ("treated as error");
+
+  if Warnings_Treated_As_Errors > 1 then
+ Write_Str ("s");
+  end if;
+
+  Write_Str (")");
+   end if;
 end if;
- end if;
+ end;
 
  if Warning_Info_Messages + Report_Info_Messages /= 0 then
 Write_Str (", ");

--- gcc/ada/errutil.ads
+++ gcc/ada/errutil.ads
@@ -30,8 +30,7 @@
 --  Err_Vars. Like Errout, it also uses the common variables and routines
 --  in package Erroutc.
 
---  This package is used by the preprocessor (gprep.adb) and the project
---  manager (prj-err.ads).
+--  This package is used by the preprocessor (gprep.adb).
 
 with Styleg;
 with Types; use Types;

[Ada] Add support for XDR streaming in the default runtime

[Pierre-Marie de Rodat]

Currently we provide a separate implementation of Stream_Attributes via
s-stratt__xdr.adb which needs to be recompiled manually.

This change introduces instead a new binder switch to choose at bind
time which stream implementation to use and replaces s-stratt__xdr.adb
by a new unit System.Stream_Attributes.XDR.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Arnaud Charlet  

gcc/ada/

* Makefile.rtl: Add s-statxd.o.
* bindgen.adb (Gen_Adainit): Add support for XDR_Stream.
* bindusg.adb (Display): Add mention of -xdr.
* gnatbind.adb: Process -xdr switch.
* init.c (__gl_xdr_stream): New.
* opt.ads (XDR_Stream): New.
* libgnat/s-stratt__xdr.adb: Rename to...
* libgnat/s-statxd.adb: this and adjust.
* libgnat/s-statxd.ads: New.
* libgnat/s-stratt.ads, libgnat/s-stratt.adb: Choose between
default and XDR implementation at runtime.
* libgnat/s-ststop.ads: Update comments.
* doc/gnat_rm/implementation_advice.rst: Update doc on XDR
streaming.
* gnat_rm.texi: Regenerate.

patch.diff.gz
Description: application/gzip

[Ada] Narrow large arithmetic and comparison operations

[Pierre-Marie de Rodat]

The goal of this enhancement is to make it possible for the expander
to rewrite both arithmetic and comparison operations that have been
resolved to a large type, namely Universal_Integer, into equivalent
operations in a smaller type, namely Integer (or Long_Long_Integer).

In certain contexts involving attributes whose result type is fixed
to Universal_Integer by the RM, the resolver cannot do anything else
than resolving these operations to Universal_Integer.  Later, after
the expander has rewritten the attributes, e.g. info function calls,
the magnitude of the actual type of the attribute is reduced, but
this is too late for the resolution phase and the large operations
are handed down to the code generator.

The change implements a new procedure Narrow_Large_Operation in the
expander, which uses the value ranges machinery to determine whether
the operation can be done in a narrower type; if so, it rewrites the
operation into the narrower type, without overflow checks in almost
all cases, and adds the required type conversions for consistency.

The change also contains a fixlet for Is_Pure_Barrier, which was a
little confused about whether a type conversion can raise CE.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Eric Botcazou  

gcc/ada/

* exp_ch4.adb (Narrow_Large_Operation): New procedure to try
and narrow large arithmetic and comparison operations.
(Expand_N_In): Call it.
(Expand_N_Op_Abs): Likewise.
(Expand_N_Op_Add): Likewise.
(Expand_N_Op_Divide): Likewise.
(Expand_N_Op_Eq): Likewise.
(Expand_N_Op_Ge): Likewise.
(Expand_N_Op_Gt): Likewise.
(Expand_N_Op_Le): Likewise.
(Expand_N_Op_Lt): Likewise.
(Expand_N_Op_Minus): Likewise.
(Expand_N_Op_Mod): Likewise.
(Expand_N_Op_Multiply): Likewise.
(Expand_N_Op_Ne): Likewise.
(Expand_N_Op_Plus): Likewise.
(Expand_N_Op_Rem): Likewise.
(Expand_N_Op_Subtract): Likewise.
(Expand_N_Type_Conversion): Use Convert_To procedure.
* exp_ch9.adb (Is_Pure_Barrier) : Skip all
numeric types.
: Use explicit criterion.--- gcc/ada/exp_ch4.adb
+++ gcc/ada/exp_ch4.adb
@@ -224,6 +224,11 @@ package body Exp_Ch4 is
--  skipped if the operation is done in Bignum mode but that's fine, since
--  the Bignum call takes care of everything.
 
+   procedure Narrow_Large_Operation (N : Node_Id);
+   --  Try to compute the result of a large operation in a narrower type than
+   --  its nominal type. This is mainly aimed to get rid of operations done in
+   --  Universal_Integer that can be generated for attributes.
+
procedure Optimize_Length_Comparison (N : Node_Id);
--  Given an expression, if it is of the form X'Length op N (or the other
--  way round), where N is known at compile time to be 0 or 1, or something
@@ -6545,6 +6550,12 @@ package body Exp_Ch4 is
 end if;
  end;
 
+ --  Try to narrow the operation
+
+ if Ltyp = Universal_Integer and then Nkind (N) = N_In then
+Narrow_Large_Operation (N);
+ end if;
+
  --  For all other cases of an explicit range, nothing to be done
 
  goto Leave;
@@ -7224,6 +7235,7 @@ package body Exp_Ch4 is
procedure Expand_N_Op_Abs (N : Node_Id) is
   Loc  : constant Source_Ptr := Sloc (N);
   Expr : constant Node_Id:= Right_Opnd (N);
+  Typ  : constant Entity_Id  := Etype (N);
 
begin
   Unary_Op_Validity_Checks (N);
@@ -7235,9 +7247,19 @@ package body Exp_Ch4 is
  return;
   end if;
 
+  --  Try to narrow the operation
+
+  if Typ = Universal_Integer then
+ Narrow_Large_Operation (N);
+
+ if Nkind (N) /= N_Op_Abs then
+return;
+ end if;
+  end if;
+
   --  Deal with software overflow checking
 
-  if Is_Signed_Integer_Type (Etype (N))
+  if Is_Signed_Integer_Type (Typ)
 and then Do_Overflow_Check (N)
   then
  --  The only case to worry about is when the argument is equal to the
@@ -7297,6 +7319,16 @@ package body Exp_Ch4 is
  end if;
   end if;
 
+  --  Try to narrow the operation
+
+  if Typ = Universal_Integer then
+ Narrow_Large_Operation (N);
+
+ if Nkind (N) /= N_Op_Add then
+return;
+ end if;
+  end if;
+
   --  Arithmetic overflow checks for signed integer/fixed point types
 
   if Is_Signed_Integer_Type (Typ) or else Is_Fixed_Point_Type (Typ) then
@@ -7474,6 +7506,16 @@ package body Exp_Ch4 is
  return;
   end if;
 
+  --  Try to narrow the operation
+
+  if Typ = Universal_Integer then
+ Narrow_Large_Operation (N);
+
+ if Nkind (N) /= N_Op_Divide then
+return;
+ end if;
+  end if;
+
   --  Convert x / 2 ** y to Shift_Right (x, y). Note that the fact that
   --  Is_Power_Of_2_For_Shift is set means that we kno

[Ada] No Default_Initial_Condition check when declaring an imported object

[Pierre-Marie de Rodat]

Default initialization is not performed when an imported object is
declared, so there should also be no Default_Initial_Condition check
generated for such an object declaration.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Steve Baird  

gcc/ada/

* exp_ch3.adb (Expand_N_Object_Declaration): Do not generate a
default initial condition check for the declaration of an
imported object.--- gcc/ada/exp_ch3.adb
+++ gcc/ada/exp_ch3.adb
@@ -7516,6 +7516,7 @@ package body Exp_Ch3 is
 and then Has_DIC (Typ)
 and then Present (DIC_Procedure (Typ))
 and then not Has_Init_Expression (N)
+and then not Is_Imported (Def_Id)
   then
  declare
 DIC_Call : constant Node_Id := Build_DIC_Call (Loc, Def_Id, Typ);

[Ada] Small cleanup in constraint checking code for allocators

[Pierre-Marie de Rodat]

This consolidates the constraint checking code for allocators in only
two places, Expand_Allocator_Expression for the qualified expression
case and Expand_N_Allocator for the subtype indication case, getting
rid of some duplication and plugging some loopholes in the process.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Eric Botcazou  

gcc/ada/

* exp_ch4.adb (Expand_Allocator_Expression): Apply constraint
and predicate checks for the qualified expression on entry,
followed by constraint and predicate checks for the allocator
itself, and return early if this results in a static error.
(Expand_N_Allocator): Do not do the same here.  Instead apply
constraint and predicate checks for arrays in the subtype
indication case.
* exp_ch5.adb (Expand_N_Assignment_Statement): Do not apply
range checks to allocators here.--- gcc/ada/exp_ch4.adb
+++ gcc/ada/exp_ch4.adb
@@ -99,7 +99,7 @@ package body Exp_Ch4 is
 
procedure Expand_Allocator_Expression (N : Node_Id);
--  Subsidiary to Expand_N_Allocator, for the case when the expression
-   --  is a qualified expression or an aggregate.
+   --  is a qualified expression.
 
procedure Expand_Array_Comparison (N : Node_Id);
--  This routine handles expansion of the comparison operators (N_Op_Lt,
@@ -781,10 +781,10 @@ package body Exp_Ch4 is
 
   --  Local variables
 
-  Aggr_In_Place : constant Boolean   := Is_Delayed_Aggregate (Exp);
   Indic : constant Node_Id   := Subtype_Mark (Expression (N));
   T : constant Entity_Id := Entity (Indic);
   Adj_Call  : Node_Id;
+  Aggr_In_Place : Boolean;
   Node  : Node_Id;
   Tag_Assign: Node_Id;
   Temp  : Entity_Id;
@@ -808,6 +808,44 @@ package body Exp_Ch4 is
  return;
   end if;
 
+  --  If we have:
+  --type A is access T1;
+  --X : A := new T2'(...);
+  --  T1 and T2 can be different subtypes, and we might need to check
+  --  both constraints. First check against the type of the qualified
+  --  expression.
+
+  Apply_Constraint_Check (Exp, T, No_Sliding => True);
+
+  Apply_Predicate_Check (Exp, T);
+
+  if Do_Range_Check (Exp) then
+ Generate_Range_Check (Exp, T, CE_Range_Check_Failed);
+  end if;
+
+  --  A check is also needed in cases where the designated subtype is
+  --  constrained and differs from the subtype given in the qualified
+  --  expression. Note that the check on the qualified expression does
+  --  not allow sliding, but this check does (a relaxation from Ada 83).
+
+  if Is_Constrained (DesigT)
+and then not Subtypes_Statically_Match (T, DesigT)
+  then
+ Apply_Constraint_Check (Exp, DesigT, No_Sliding => False);
+
+ Apply_Predicate_Check (Exp, DesigT);
+
+ if Do_Range_Check (Exp) then
+Generate_Range_Check (Exp, DesigT, CE_Range_Check_Failed);
+ end if;
+  end if;
+
+  if Nkind (Exp) = N_Raise_Constraint_Error then
+ Rewrite (N, New_Copy (Exp));
+ Set_Etype (N, PtrT);
+ return;
+  end if;
+
   --  In the case of an Ada 2012 allocator whose initial value comes from a
   --  function call, pass "the accessibility level determined by the point
   --  of call" (AI05-0234) to the function. Conceptually, this belongs in
@@ -837,6 +875,8 @@ package body Exp_Ch4 is
  end;
   end if;
 
+  Aggr_In_Place := Is_Delayed_Aggregate (Exp);
+
   --  Case of tagged type or type requiring finalization
 
   if Is_Tagged_Type (T) or else Needs_Finalization (T) then
@@ -1218,35 +1258,6 @@ package body Exp_Ch4 is
   else
  Build_Allocate_Deallocate_Proc (N, True);
 
- --  If we have:
- --type A is access T1;
- --X : A := new T2'(...);
- --  T1 and T2 can be different subtypes, and we might need to check
- --  both constraints. First check against the type of the qualified
- --  expression.
-
- Apply_Constraint_Check (Exp, T, No_Sliding => True);
-
- if Do_Range_Check (Exp) then
-Generate_Range_Check (Exp, DesigT, CE_Range_Check_Failed);
- end if;
-
- --  A check is also needed in cases where the designated subtype is
- --  constrained and differs from the subtype given in the qualified
- --  expression. Note that the check on the qualified expression does
- --  not allow sliding, but this check does (a relaxation from Ada 83).
-
- if Is_Constrained (DesigT)
-   and then not Subtypes_Statically_Match (T, DesigT)
- then
-Apply_Constraint_Check
-  (Exp, DesigT, No_Sliding => False);
-
-if Do_Range_Check (Exp) then
-   Generate_Range_Check (Exp, DesigT, CE_Range_Check_Failed);
-end if;
- end if;
-
  --  For

[Ada] Small cleanup in the attribute code of the expander

[Pierre-Marie de Rodat]

This fixes a few minor glitches in the part of the expander dealing
with attributes: missing check for Component_Size, alphabetization
issues and wrong classification of few other attributes.

No functional changes.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Eric Botcazou  

gcc/ada/

* exp_attr.adb (Analyze_Attribute) : Alphabetize.
: Add check for universal integer attribute.
, , , ,
: Raise Program_Error on them.
* sem_attr.adb (Eval_Attribute) : Add comment on
the packed array case.--- gcc/ada/exp_attr.adb
+++ gcc/ada/exp_attr.adb
@@ -2531,6 +2531,19 @@ package body Exp_Attr is
  end if;
   end Alignment;
 
+  ---
+  -- Asm_Input, Asm_Output --
+  ---
+
+  --  The Asm_Input and Asm_Output attributes are not expanded at this
+  --  stage, but will be eliminated in the expansion of the Asm call,
+  --  see Exp_Intr for details. So the back end will never see them.
+
+  when Attribute_Asm_Input
+ | Attribute_Asm_Output
+  =>
+ null;
+
   -
   -- Bit --
   -
@@ -2796,6 +2809,15 @@ package body Exp_Attr is
  Analyze_And_Resolve (N, Id_Kind);
   end Caller;
 
+  
+  -- Component_Size --
+  
+
+  --  Component_Size is handled by the back end
+
+  when Attribute_Component_Size =>
+ Apply_Universal_Integer_Attribute_Checks (N);
+
   -
   -- Compose --
   -
@@ -2999,7 +3021,7 @@ package body Exp_Attr is
   -- Descriptor_Size --
   -
 
-  --  Attribute Descriptor_Size is handled by the back end
+  --  Descriptor_Size is handled by the back end
 
   when Attribute_Descriptor_Size =>
  Apply_Universal_Integer_Attribute_Checks (N);
@@ -7444,53 +7466,33 @@ package body Exp_Attr is
  Rewrite_Attribute_Proc_Call (Pname);
   end Write;
 
-  --  Component_Size is handled by the back end, unless the component size
-  --  is known at compile time, which is always true in the packed array
-  --  case. It is important that the packed array case is handled in the
-  --  front end (see Eval_Attribute) since the back end would otherwise get
-  --  confused by the equivalent packed array type.
-
-  when Attribute_Component_Size =>
- null;
-
   --  The following attributes are handled by the back end (except that
   --  static cases have already been evaluated during semantic processing,
   --  but in any case the back end should not count on this).
 
-  --  The back end also handles the non-class-wide cases of Size
-
-  when Attribute_Bit_Order
- | Attribute_Code_Address
- | Attribute_Definite
+  when Attribute_Code_Address
  | Attribute_Deref
  | Attribute_Null_Parameter
  | Attribute_Passed_By_Reference
  | Attribute_Pool_Address
- | Attribute_Scalar_Storage_Order
   =>
  null;
 
-  --  The following attributes are also handled by the back end, but return
-  --  a universal integer result, so may need a conversion for checking
-  --  that the result is in range.
-
-  when Attribute_Aft
- | Attribute_Max_Alignment_For_Allocation
-  =>
- Apply_Universal_Integer_Attribute_Checks (N);
-
   --  The following attributes should not appear at this stage, since they
   --  have already been handled by the analyzer (and properly rewritten
   --  with corresponding values or entities to represent the right values)
 
   when Attribute_Abort_Signal
  | Attribute_Address_Size
+ | Attribute_Aft
  | Attribute_Atomic_Always_Lock_Free
  | Attribute_Base
+ | Attribute_Bit_Order
  | Attribute_Class
  | Attribute_Compiler_Version
  | Attribute_Default_Bit_Order
  | Attribute_Default_Scalar_Storage_Order
+ | Attribute_Definite
  | Attribute_Delta
  | Attribute_Denorm
  | Attribute_Digits
@@ -7512,6 +7514,7 @@ package body Exp_Attr is
  | Attribute_Machine_Overflows
  | Attribute_Machine_Radix
  | Attribute_Machine_Rounds
+ | Attribute_Max_Alignment_For_Allocation
  | Attribute_Maximum_Alignment
  | Attribute_Model_Emin
  | Attribute_Model_Epsilon
@@ -7526,6 +7529,7 @@ package body Exp_Attr is
  | Attribute_Safe_Large
  | Attribute_Safe_Last
  | Attribute_Safe_Small
+ | Attribute_Scalar_Storage_Order
  | Attribute_Scale
  | Attribute_Signed_Zeros
  | Attribute_Small
@@ -7541,15 +7545,6 @@ package body Exp_Attr is
  | Attribute_Word_Size
   =>
  raise Program_Error;
-
-  --  The Asm_Input and Asm_Output attributes are not expanded at this
-  --  stage, but will be 

[Ada] Implement AI12-0032 fixes for 'Old attribute accessibility

[Pierre-Marie de Rodat]

AI12-0032 modifies/clarifies many of the rules pertaining to uses of the
Old attribute. Most of these 7 changes were already implemented by GNAT
but a couple having to do with accessibility were not. Implement those
unimplemented rules.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Steve Baird  

gcc/ada/

* sem_util.adb (Object_Access_Level): Treat a 'Old attribute
reference like an aggregate in determining its static
accessibility level; after the evaluation of the relevant
post-condition, the implicitly declared constant associated with
an Old attribute reference ceases to exist. Similarly for
Loop_Entry attribute.
* exp_ch6.adb (Expand_Call_Helper): For an attribute reference
that is expanded into a reference to an implicitly declared
constant (e.g., a 'Old or 'Loop_Entry attribute), compute the
dynamic accessibility level of that constant by looking at the
declaration of the constant (as opposed to looking at the
attribute reference).--- gcc/ada/exp_ch6.adb
+++ gcc/ada/exp_ch6.adb
@@ -3617,6 +3617,21 @@ package body Exp_Ch6 is
 then
Prev_Orig := Prev;
 
+--  If the actual is an attribute reference that was expanded
+--  into a reference to an entity, then get accessibility level
+--  from that entity. AARM 6.1.1(27.d) says "... the implicit
+--  constant declaration defines the accessibility level of X'Old".
+
+elsif Nkind (Prev_Orig) = N_Attribute_Reference
+  and then Nam_In (Attribute_Name (Prev_Orig),
+   Name_Old,
+   Name_Loop_Entry)
+  and then Is_Entity_Name (Prev)
+  and then Present (Entity (Prev))
+  and then Is_Object (Entity (Prev))
+then
+   Prev_Orig := Prev;
+
 elsif Nkind (Prev_Orig) = N_Type_Conversion then
Prev_Orig := Expression (Prev_Orig);
 end if;

--- gcc/ada/sem_util.adb
+++ gcc/ada/sem_util.adb
@@ -24237,6 +24237,18 @@ package body Sem_Util is
   elsif Nkind (Orig_Obj) = N_Aggregate then
  return Object_Access_Level (Current_Scope);
 
+  --  Treat an Old/Loop_Entry attribute reference like an aggregate.
+  --  AARM 6.1.1(27.d) says "... the implicit constant declaration
+  --  defines the accessibility level of X'Old", so that is what
+  --  we are trying to implement here.
+
+  elsif Nkind (Orig_Obj) = N_Attribute_Reference
+and then Nam_In (Attribute_Name (Orig_Obj),
+ Name_Old,
+ Name_Loop_Entry)
+  then
+ return Object_Access_Level (Current_Scope);
+
   --  Otherwise return the scope level of Standard. (If there are cases
   --  that fall through to this point they will be treated as having
   --  global accessibility for now. ???)

[Ada] Fix invalid expression sharing in Expand_Array_Equality

[Pierre-Marie de Rodat]

The procedure Expand_Array_Equality has an optimization whereby the
equality operation for an array of 2 elements is expanded into a
simple conjunction of two component comparisons instead of into
the generic loop.

But this special circuitry reuses the same expression list for the
indexed component built for both elements, which can cause problems
later when the index type is an enumeration type with a non-standard
representation, because of successive rewriting.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Eric Botcazou  

gcc/ada/

* exp_ch4.adb (Expand_Array_Equality): For the optimization of
the 2-element case, build new expression lists for the indices.--- gcc/ada/exp_ch4.adb
+++ gcc/ada/exp_ch4.adb
@@ -2009,34 +2009,33 @@ package body Exp_Ch4 is
 Ctyp : constant Entity_Id := Component_Type (Ltyp);
 L, R : Node_Id;
 TestL, TestH : Node_Id;
-Index_List   : List_Id;
 
  begin
-Index_List := New_List (New_Copy_Tree (Low_Bound (First_Idx)));
-
 L :=
   Make_Indexed_Component (Loc,
 Prefix  => New_Copy_Tree (New_Lhs),
-Expressions => Index_List);
+Expressions =>
+  New_List (New_Copy_Tree (Low_Bound (First_Idx;
 
 R :=
   Make_Indexed_Component (Loc,
 Prefix  => New_Copy_Tree (New_Rhs),
-Expressions => Index_List);
+Expressions =>
+  New_List (New_Copy_Tree (Low_Bound (First_Idx;
 
 TestL := Expand_Composite_Equality (Nod, Ctyp, L, R, Bodies);
 
-Index_List := New_List (New_Copy_Tree (High_Bound (First_Idx)));
-
 L :=
   Make_Indexed_Component (Loc,
 Prefix  => New_Lhs,
-Expressions => Index_List);
+Expressions =>
+  New_List (New_Copy_Tree (High_Bound (First_Idx;
 
 R :=
   Make_Indexed_Component (Loc,
 Prefix  => New_Rhs,
-Expressions => Index_List);
+Expressions =>
+  New_List (New_Copy_Tree (High_Bound (First_Idx;
 
 TestH := Expand_Composite_Equality (Nod, Ctyp, L, R, Bodies);
 

[Ada] ACATS 4.1J - B854003 - Subtype conformance check missed

[Pierre-Marie de Rodat]

This test shows that GNAT was missing formal subprogram conformance
checking in some cases, now fixed.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Arnaud Charlet  

gcc/ada/

* sem_ch6.ads, sem_ch6.adb (Check_Formal_Conformance): New
subprogram.
(Check_Conformance): Move code to Check_Formal_Conformance.
* sem_ch8.adb (Analyze_Subprogram_Renaming): Check for formal
conformance when needed.--- gcc/ada/sem_ch6.adb
+++ gcc/ada/sem_ch6.adb
@@ -5734,16 +5734,8 @@ package body Sem_Ch6 is
 end if;
 
 return;
-
- elsif Is_Formal_Subprogram (Old_Id)
-   or else Is_Formal_Subprogram (New_Id)
-   or else (Is_Subprogram (New_Id)
- and then Present (Alias (New_Id))
- and then Is_Formal_Subprogram (Alias (New_Id)))
- then
-Conformance_Error
-  ("\formal subprograms are not subtype conformant "
-   & "(RM 6.3.1 (17/3))");
+ else
+Check_Formal_Subprogram_Conformance (New_Id, Old_Id, Err_Loc);
  end if;
   end if;
 
@@ -6516,6 +6508,37 @@ package body Sem_Ch6 is
   end if;
end Check_Discriminant_Conformance;
 
+   -
+   -- Check_Formal_Subprogram_Conformance --
+   -
+
+   procedure Check_Formal_Subprogram_Conformance
+ (New_Id  : Entity_Id;
+  Old_Id  : Entity_Id;
+  Err_Loc : Node_Id := Empty)
+   is
+  N : Node_Id;
+   begin
+  if Is_Formal_Subprogram (Old_Id)
+or else Is_Formal_Subprogram (New_Id)
+or else (Is_Subprogram (New_Id)
+  and then Present (Alias (New_Id))
+  and then Is_Formal_Subprogram (Alias (New_Id)))
+  then
+ if Present (Err_Loc) then
+N := Err_Loc;
+ else
+N := New_Id;
+ end if;
+
+ Error_Msg_Sloc := Sloc (Old_Id);
+ Error_Msg_N ("not subtype conformant with declaration#!", N);
+ Error_Msg_NE
+   ("\formal subprograms are not subtype conformant "
+& "(RM 6.3.1 (17/3))", N, New_Id);
+  end if;
+   end Check_Formal_Subprogram_Conformance;
+

-- Check_Fully_Conformant --


--- gcc/ada/sem_ch6.ads
+++ gcc/ada/sem_ch6.ads
@@ -69,6 +69,16 @@ package Sem_Ch6 is
--  the source location of the partial view, which may be different than
--  Prev in the case of private types.
 
+   procedure Check_Formal_Subprogram_Conformance
+ (New_Id  : Entity_Id;
+  Old_Id  : Entity_Id;
+  Err_Loc : Node_Id := Empty);
+   --  Check RM 6.3.1(17/3): the profile of a generic formal subprogram is not
+   --  subtype conformant with any other profile and post an error message if
+   --  either New_Id or Old_Id denotes a formal subprogram, with the flag being
+   --  placed on the Err_Loc node if it is specified, and on New_Id if not. See
+   --  also spec of Check_Fully_Conformant below for New_Id and Old_Id usage.
+
procedure Check_Fully_Conformant
  (New_Id  : Entity_Id;
   Old_Id  : Entity_Id;

--- gcc/ada/sem_ch8.adb
+++ gcc/ada/sem_ch8.adb
@@ -3171,7 +3171,7 @@ package body Sem_Ch8 is
 
   Set_Kill_Elaboration_Checks (New_S, True);
 
-  --  If we had a previous error, indicate a completely is present to stop
+  --  If we had a previous error, indicate a completion is present to stop
   --  junk cascaded messages, but don't take any further action.
 
   if Etype (Nam) = Any_Type then
@@ -3409,6 +3409,8 @@ package body Sem_Ch8 is
 
if Original_Subprogram (Old_S) = Rename_Spec then
   Error_Msg_N ("unfrozen subprogram cannot rename itself ", N);
+   else
+  Check_Formal_Subprogram_Conformance (New_S, Old_S, Spec);
end if;
 else
Check_Subtype_Conformant (New_S, Old_S, Spec);

[Ada] Fix small inefficiency in previous change to expander

[Pierre-Marie de Rodat]

The procedure Get_Size_For_Range does not need to return the smallest
size for a signed integer type covering the range, the important thing
is instead to return a size lower than that of the original type; this
saves a bunch of lookups in the power-of-two table of the Uint unit.

The change also backs out an optimization previously added for 32-bit
types in System.Random_Numbers.Random_Discrete since the compiler can
now do it on its own.

No functional changes.

Tested on x86_64-pc-linux-gnu, committed on trunk

2020-06-18  Eric Botcazou  

gcc/ada/

* exp_ch4.adb (Get_Size_For_Range): Only make sure to return a
size lower than that of the original type if possible.
* libgnat/s-rannum.adb (Random_Discrete): Back out optimization
added for 32-bit types.--- gcc/ada/exp_ch4.adb
+++ gcc/ada/exp_ch4.adb
@@ -13919,28 +13919,50 @@ package body Exp_Ch4 is
   Typ: constant Entity_Id := Etype (R);
 
   function Get_Size_For_Range (Lo, Hi : Uint) return Nat;
-  --  Return the size of the smallest signed integer type covering Lo .. Hi
+  --  Return the size of a small signed integer type covering Lo .. Hi.
+  --  The important thing is to return a size lower than that of Typ.
 
   
   -- Get_Size_For_Range --
   
 
   function Get_Size_For_Range (Lo, Hi : Uint) return Nat is
- B : Uint;
- S : Nat;
+
+ function Is_OK_For_Range (Siz : Nat) return Boolean;
+ --  Return True if a signed integer with given size can cover Lo .. Hi
+
+ --
+ -- Is_OK_For_Range --
+ --
+
+ function Is_OK_For_Range (Siz : Nat) return Boolean is
+B : constant Uint := Uint_2 ** (Siz - 1);
+
+ begin
+--  Test B = 2 ** (size - 1) (can accommodate -B .. +(B - 1))
+
+return Lo >= -B and then Hi >= -B and then Lo < B and then Hi < B;
+ end Is_OK_For_Range;
 
   begin
- S := 1;
- B := Uint_1;
+ --  This is (almost always) the size of Integer
 
- --  S = size, B = 2 ** (size - 1) (can accommodate -B .. +(B - 1))
+ if Is_OK_For_Range (32) then
+return 32;
 
- while Lo < -B or else Hi < -B or else Lo >= B or else Hi >= B loop
-B := Uint_2 ** S;
-S := S + 1;
- end loop;
+ --  If the size of Typ is 64 then check 63
+
+ elsif RM_Size (Typ) = 64 and then Is_OK_For_Range (63) then
+return 63;
+
+ --  This is (almost always) the size of Long_Long_Integer
 
- return S;
+ elsif Is_OK_For_Range (64) then
+return 64;
+
+ else
+return 128;
+ end if;
   end Get_Size_For_Range;
 
   --  Local variables

--- gcc/ada/libgnat/s-rannum.adb
+++ gcc/ada/libgnat/s-rannum.adb
@@ -402,10 +402,11 @@ is
   elsif Max < Min then
  raise Constraint_Error;
 
+  --  In the 64-bit case, we have to be careful since not all 64-bit
+  --  unsigned values are representable in GNAT's universal integer.
+
   elsif Result_Subtype'Base'Size > 32 then
  declare
---  In the 64-bit case, we have to be careful since not all 64-bit
---  unsigned values are representable in GNAT's universal integer.
 --  Ignore unequal-size warnings since GNAT's handling is correct.
 
 pragma Warnings ("Z");
@@ -422,8 +423,7 @@ is
 
  begin
 if N = 0 then
-   X := Random (Gen);
-   return Conv_To_Result (Conv_To_Unsigned (Min) + X);
+   return Conv_To_Result (Conv_To_Unsigned (Min) + Random (Gen));
 
 else
Slop := Unsigned_64'Last rem N + 1;
@@ -437,73 +437,31 @@ is
 end if;
  end;
 
-  else
- declare
---  In the 32-bit case, unlike the above case, we need to handle
---  both integer and enumeration types. If the values of the result
---  subtype are contiguous, then we can still use the above trick.
---  Otherwise we need to rely on 'Pos and 'Val in the computation,
---  which is more costly since it will thus be done in universal
---  integer. And ignore unequal-size warnings in this case too.
+  --  In the 32-bit case, we need to handle both integer and enumeration
+  --  types and, therefore, rely on 'Pos and 'Val in the computation.
 
-pragma Warnings ("Z");
-function Conv_To_Unsigned is
-   new Unchecked_Conversion (Result_Subtype'Base, Unsigned_32);
-function Conv_To_Result is
-   new Unchecked_Conversion (Unsigned_32, Result_Subtype'Base);
-pragma Warnings ("z");
-
-Contiguous : constant Boolean :=
-  Result_Subtype'Pos (Result_Subtype'Last) -
- 

Re: [PATCH] recog: Use parameter packs for operator()

[Jonathan Wakely via Gcc-patches]

On 18/06/20 10:02 +0100, Jonathan Wakely wrote:

On 18/06/20 08:55 +0100, Richard Sandiford wrote:

Sebastian Huber  writes:

On 18/06/2020 09:09, Richard Sandiford wrote:


Sebastian Huber  writes:

On 16/06/2020 12:42, Richard Sandiford wrote:


[...]
2020-06-16  Richard Sandiford  

gcc/
* coretypes.h (first_type): New alias template.
* recog.h (insn_gen_fn::operator()): Use it instead of a decltype.
Remove spurious “...” and split the function type out into a typedef.
---
  gcc/coretypes.h | 4 
  gcc/recog.h | 5 +++--
  2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/gcc/coretypes.h b/gcc/coretypes.h
index cda22697cc3..01ec2e23ce2 100644
--- a/gcc/coretypes.h
+++ b/gcc/coretypes.h
@@ -359,6 +359,10 @@ struct kv_pair
const ValueType value;  /* the value of the name */
  };

+/* Alias of the first type, ignoring the second.  */
+template
+using first_type = T1;
+
  #else

  struct _dont_use_rtx_here_;
diff --git a/gcc/recog.h b/gcc/recog.h
index 0a71a02c4a9..d674d384723 100644
--- a/gcc/recog.h
+++ b/gcc/recog.h
@@ -295,9 +295,10 @@ struct insn_gen_fn
typedef void (*stored_funcptr) (void);

template
-  rtx_insn *operator() (Ts... args...) const
+  rtx_insn *operator() (Ts... args) const
{
-return ((rtx_insn *(*) (decltype(args, NULL_RTX)...)) func) (args...);
+typedef rtx_insn *(*funcptr) (first_type...);
+return ((funcptr) func) (args...);
}

// This is for compatibility of code that invokes functions like

I get this error on FreeBSD 12.1 with

c++ --version
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on
LLVM 8.0.1)
Target: x86_64-unknown-freebsd12.1
Thread model: posix
InstalledDir: /usr/bin

In file included from ../../gnu-mirror-gcc-aff95ee/gcc/function.c:51:
../../gnu-mirror-gcc-aff95ee/gcc/recog.h:301:30: error: too many
arguments to function call, expected 1, have 2
     return ((funcptr) func) (args...);
      ^~~~
../../gnu-mirror-gcc-aff95ee/gcc/function.c:3315:29: note: in
instantiation of function template specialization
'insn_gen_fn::operator()' requested here
     emit_insn (GEN_FCN (icode) (parmreg, validated_mem));

Thanks for the report.  Was clang OK with the earlier version
(i.e. before 4e49b994de060d4a6c9318d0ed52ef038153426e)?

Yes, the last version I built successfully was
b952c2cfcd74c284970e1b9bf1fca58f5f69ab23 on 10th of June. I build GCC
roughly once per week.


Hmm, yeah, can reproduce with a recentish build from clang master:

template using int_t = int;
void (*f)();
template
void g(Ts... args) {
#if A
((void (*)(int_t...)) f)(args...);
#elif B
typedef void (*funcptr)(decltype((void)args, 0)...);
((funcptr) f)(args...);
#else
typedef void (*funcptr)(int_t...);
((funcptr) f)(args...);
#endif
}
void h(int x, int y) { g(x, y); }

Works with -DA and -DB, but fails with the final version.

So it looks like the obvious choices are:

(1) Remove the typedef.
(2) Go back to using decltype.
(3) Revert the whole thing and go back to the overloads.

Not sure about (1), because it leads to awkward formatting, and would
need a comment to say “Don't use a typedef!”.  The above error shows
that we're probably close to the edge of what compilers will support
reliably.


That's extremely surprising. It's basic C++11 and so Clang should have
been able to do it 10+ years ago. I'll look into it.


(2) seems to work more reliably, and gives nicer error messages,
but was unpopular for being unidiomatic C++.

I guess at this point, (3) is the way to go.


Yuck, (2) is better than (3).

I'm not massively fond of (2) but (3) is horrible and just unnecessary
with variadics.


I reported https://bugs.llvm.org/show_bug.cgi?id=46377 because it
doesn't seem to be known (which is almost as surprising as the fact it
fails in the first place). It used to work with Clang 3.0 back in 2011
but fails with every release since.

I thought I'd seen it before, but I was thinking of
https://bugs.llvm.org/show_bug.cgi?id=14858 which got fixed years ago.

Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

[Martin Liška]

On 6/18/20 11:02 AM, Martin Liška wrote:

Now I've got it.


I've just reduced that to:

$ cat pr50310.c
double s1[4], s2[4], s3[64];

int
main ()
{
  s1[0] = 5.0;
  s1[1] = 6.0;
  s1[2] = 5.0;
  s1[3] = __builtin_nan ("");
  s2[0] = 6.0;
  s2[1] = 5.0;
  s2[2] = 5.0;
  s2[3] = 5.0;

  asm volatile ("" : : : "memory");
  for (int i = 1; i < 4; i++)
s3[i] = __builtin_isgreater (s1[i], s2[i]) ? -1.0 : 0.0;
  asm volatile ("" : : : "memory");

  __builtin_printf ("val: %f\n", s3[1]);
  if (s3[1] != -1.0)
__builtin_abort ();
  return 0;
}

Optimized dump differs in expected manner:

[local count: 805306369]:
   MEM  [(double *)&s1] = { 5.0e+0, 6.0e+0 };
   MEM  [(double *)&s1 + 16B] = { 5.0e+0,  Nan };
   MEM  [(double *)&s2] = { 6.0e+0, 5.0e+0 };
   MEM  [(double *)&s2 + 16B] = { 5.0e+0, 5.0e+0 };
   __asm__ __volatile__("" :  :  : "memory");
   vect__1.13_51 = MEM  [(double *)&s1 + 8B];
   vect__2.16_55 = MEM  [(double *)&s2 + 8B];
-  vect_iftmp.17_58 = VEC_COND_EXPR ;
-  MEM  [(double *)&s3 + 8B] = vect_iftmp.17_58;
+  _58 = vect__1.13_51 u<= vect__2.16_55;
+  vect_iftmp.17_59 = .VCOND (vect__1.13_51, vect__2.16_55, { 0.0, 0.0 }, { 
-1.0e+0, -1.0e+0 }, 117);
+  MEM  [(double *)&s3 + 8B] = vect_iftmp.17_59;
   _41 = s1[3];
   _42 = s2[3];
   if (_41 u<= _42)
 goto ; [50.00%]
   else
 goto ; [50.00%]
 
[local count: 402653185]:
 
[local count: 805306369]:

   # iftmp.0_43 = PHI <-1.0e+0(2), 0.0(3)>
   s3[3] = iftmp.0_43;
   __asm__ __volatile__("" :  :  : "memory");

but we fail with:

$ gcc pr50310.c -m32 -O3 -ffloat-store && ./a.out
val: -nan
Aborted (core dumped)

I'm digging deeper.
Martin

[PATCH] forwprop: simplify_vector_constructor follow-up fix [PR95713]

[Jakub Jelinek via Gcc-patches]

Hi!

As the following testcase shows, the exception for the aarch64
vec_pack_trunc_di is not sufficient on x86, the halfvectype
"vectors" have SImode but the x86 vec_pack_trunc_si meant for
the bool bitmasks combines 2x SImode into DImode, while in the
testcase the halfvectype is 1x SImode "vector" with SImode and
result is 2x HImode "vector" with SImode.

The patch also verifies the result mode.  The other option is
to throw away the aarch64 exception.  And yet another option
would be to use different optabs for vector bools with integral modes.

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

2020-06-18  Jakub Jelinek  

PR target/95713
* tree-ssa-forwprop.c: Include insn-config.h and recog.h.
(simplify_vector_constructor): For integral TYPE_MODE of
non-VECTOR_BOOLEAN_P vector same as element mode, verify also
that lhs mode matches the output operand mode of the expander.

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

--- gcc/tree-ssa-forwprop.c.jj  2020-06-08 11:05:04.196939262 +0200
+++ gcc/tree-ssa-forwprop.c 2020-06-17 11:18:10.816155772 +0200
@@ -51,6 +51,8 @@ along with GCC; see the file COPYING3.
 #include "internal-fn.h"
 #include "cgraph.h"
 #include "tree-ssa.h"
+#include "insn-config.h"
+#include "recog.h"
 
 /* This pass propagates the RHS of assignment statements into use
sites of the LHS of the assignment.  It's basically a specialized
@@ -2391,7 +2393,8 @@ simplify_vector_constructor (gimple_stmt
  /* Only few targets implement direct conversion patterns so try
 some simple special cases via VEC_[UN]PACK[_FLOAT]_LO_EXPR.  */
  optab optab;
- tree halfvectype, dblvectype;
+ enum insn_code icode;
+ tree halfvectype, dblvectype, lhs;
  if (CONVERT_EXPR_CODE_P (conv_code)
  && (2 * TYPE_PRECISION (TREE_TYPE (TREE_TYPE (orig[0])))
  == TYPE_PRECISION (TREE_TYPE (type)))
@@ -2446,18 +2449,21 @@ simplify_vector_constructor (gimple_stmt
   && (halfvectype
 = build_vector_type (TREE_TYPE (TREE_TYPE (orig[0])),
  nelts / 2))
+  && (optab = optab_for_tree_code (VEC_PACK_TRUNC_EXPR,
+   halfvectype,
+   optab_default))
+  && ((icode = optab_handler (optab, TYPE_MODE (halfvectype)))
+  != CODE_FOR_nothing)
   /* Only use it for vector modes or for vector booleans
  represented as scalar bitmasks, or allow halfvectype
  be the element mode.  See PR95528.  */
   && (VECTOR_MODE_P (TYPE_MODE (halfvectype))
   || VECTOR_BOOLEAN_TYPE_P (halfvectype)
   || (TYPE_MODE (halfvectype)
-  == TYPE_MODE (TREE_TYPE (halfvectype
-  && (optab = optab_for_tree_code (VEC_PACK_TRUNC_EXPR,
-   halfvectype,
-   optab_default))
-  && (optab_handler (optab, TYPE_MODE (halfvectype))
-  != CODE_FOR_nothing))
+  == TYPE_MODE (TREE_TYPE (halfvectype))
+  && (lhs == gimple_assign_lhs (stmt))
+  && (insn_data[icode].operand[0].mode
+  == TYPE_MODE (TREE_TYPE (lhs))
{
  gimple_seq stmts = NULL;
  tree low = gimple_build (&stmts, BIT_FIELD_REF, halfvectype,
--- gcc/testsuite/gcc.dg/pr95713.c.jj   2020-06-17 11:20:12.288381166 +0200
+++ gcc/testsuite/gcc.dg/pr95713.c  2020-06-17 11:19:56.057618283 +0200
@@ -0,0 +1,15 @@
+/* PR target/95713 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -Wno-psabi -w" } */
+/* { dg-additional-options "-mavx512bw" { target i?86-*-* x86_64-*-* } } */
+
+typedef int v2si __attribute__((vector_size (8)));
+typedef short int v2hi __attribute__((vector_size (4)));
+void foo (v2hi);
+
+void
+bar (v2si x)
+{
+  v2hi a = (v2hi) { (short) x[0], (short) x[1] };
+  foo (4 > a);
+}

Jakub

[PATCH] phiopt: Improve minmax optimization [PR95699]

[Jakub Jelinek via Gcc-patches]

Hi!

As discussed in the PR, the
x < 0x8000U to (int) x >= 0
optimization stands in the way of minmax_replacement optimization,
so for comparisons with most of the constants it works well, but when the
above mentioned optimization triggers, it is unable to do it.
The match.pd (cond (cmp (convert? x) c1) (op x c2) c3) -> (op (minmax x c1) c2)
optimization is able to look through that and this patch
teaches minmax_replacement about it too.

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

2020-06-18  Jakub Jelinek  

PR tree-optimization/95699
* tree-ssa-phiopt.c (minmax_replacement): Treat (signed int)x < 0
as x > INT_MAX and (signed int)x >= 0 as x <= INT_MAX.  Move variable
declarations to the statements that set them where possible.

* gcc.dg/tree-ssa/pr95699.c: New test.

--- gcc/tree-ssa-phiopt.c.jj2020-06-05 10:42:40.792893013 +0200
+++ gcc/tree-ssa-phiopt.c   2020-06-17 13:36:20.600659487 +0200
@@ -1363,22 +1363,21 @@ minmax_replacement (basic_block cond_bb,
edge e0, edge e1, gimple *phi,
tree arg0, tree arg1)
 {
-  tree result, type, rhs;
-  gcond *cond;
+  tree result;
   edge true_edge, false_edge;
-  enum tree_code cmp, minmax, ass_code;
-  tree smaller, alt_smaller, larger, alt_larger, arg_true, arg_false;
+  enum tree_code minmax, ass_code;
+  tree smaller, larger, arg_true, arg_false;
   gimple_stmt_iterator gsi, gsi_from;
 
-  type = TREE_TYPE (PHI_RESULT (phi));
+  tree type = TREE_TYPE (PHI_RESULT (phi));
 
   /* The optimization may be unsafe due to NaNs.  */
   if (HONOR_NANS (type) || HONOR_SIGNED_ZEROS (type))
 return false;
 
-  cond = as_a  (last_stmt (cond_bb));
-  cmp = gimple_cond_code (cond);
-  rhs = gimple_cond_rhs (cond);
+  gcond *cond = as_a  (last_stmt (cond_bb));
+  enum tree_code cmp = gimple_cond_code (cond);
+  tree rhs = gimple_cond_rhs (cond);
 
   /* Turn EQ/NE of extreme values to order comparisons.  */
   if ((cmp == NE_EXPR || cmp == EQ_EXPR)
@@ -1401,8 +1400,8 @@ minmax_replacement (basic_block cond_bb,
 
   /* This transformation is only valid for order comparisons.  Record which
  operand is smaller/larger if the result of the comparison is true.  */
-  alt_smaller = NULL_TREE;
-  alt_larger = NULL_TREE;
+  tree alt_smaller = NULL_TREE;
+  tree alt_larger = NULL_TREE;
   if (cmp == LT_EXPR || cmp == LE_EXPR)
 {
   smaller = gimple_cond_lhs (cond);
@@ -1463,6 +1462,50 @@ minmax_replacement (basic_block cond_bb,
   else
 return false;
 
+  /* Handle the special case of (signed_type)x < 0 being equivalent
+ to x > MAX_VAL(signed_type) and (signed_type)x >= 0 equivalent
+ to x <= MAX_VAL(signed_type).  */
+  if ((cmp == GE_EXPR || cmp == LT_EXPR)
+  && INTEGRAL_TYPE_P (type)
+  && TYPE_UNSIGNED (type)
+  && integer_zerop (rhs))
+{
+  tree op = gimple_cond_lhs (cond);
+  if (TREE_CODE (op) == SSA_NAME
+ && INTEGRAL_TYPE_P (TREE_TYPE (op))
+ && !TYPE_UNSIGNED (TREE_TYPE (op)))
+   {
+ gimple *def_stmt = SSA_NAME_DEF_STMT (op);
+ if (gimple_assign_cast_p (def_stmt))
+   {
+ tree op1 = gimple_assign_rhs1 (def_stmt);
+ if (INTEGRAL_TYPE_P (TREE_TYPE (op1))
+ && TYPE_UNSIGNED (TREE_TYPE (op1))
+ && (TYPE_PRECISION (TREE_TYPE (op))
+ == TYPE_PRECISION (TREE_TYPE (op1)))
+ && useless_type_conversion_p (type, TREE_TYPE (op1)))
+   {
+ wide_int w1 = wi::max_value (TREE_TYPE (op));
+ wide_int w2 = wi::add (w1, 1);
+ if (cmp == LT_EXPR)
+   {
+ larger = op1;
+ smaller = wide_int_to_tree (TREE_TYPE (op1), w1);
+ alt_smaller = wide_int_to_tree (TREE_TYPE (op1), w2);
+ alt_larger = NULL_TREE;
+   }
+ else
+   {
+ smaller = op1;
+ larger = wide_int_to_tree (TREE_TYPE (op1), w1);
+ alt_larger = wide_int_to_tree (TREE_TYPE (op1), w2);
+ alt_smaller = NULL_TREE;
+   }
+   }
+   }
+   }
+}
+
   /* We need to know which is the true edge and which is the false
   edge so that we know if have abs or negative abs.  */
   extract_true_false_edges_from_block (cond_bb, &true_edge, &false_edge);
--- gcc/testsuite/gcc.dg/tree-ssa/pr95699.c.jj  2020-06-17 13:45:31.308686080 
+0200
+++ gcc/testsuite/gcc.dg/tree-ssa/pr95699.c 2020-06-17 13:44:29.715577853 
+0200
@@ -0,0 +1,39 @@
+/* PR tree-optimization/95699 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+/* { dg-final { scan-tree-dump "MAX_EXPR 
<\[^>\n\r]*9223372036854775807\[^>\n\r]*>" "optimized" } } */
+/* { dg-final { scan-tree-dump "MAX_EXPR 
<\[^>\n\r]*9223372036854775808\[^>\n\r]*>"

Re: [PATCH] avoid early asm output

[Jakub Jelinek via Gcc-patches]

On Thu, Jun 18, 2020 at 11:08:53AM +0200, Richard Biener wrote:
> This avoids early assembler output via the gimplifier creating
> new static CTORs.  The output machinery seems to be prepared to
> output constants recursively and it's just a matter of
> appropriately defering or not defering output.
> 
> This also has the advantage of not outputting .string for
> optimized away local aggregate initializers containing string
> references.
> 
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Use bool instead of int?

Jakub

Re: drop -aux{dir,base}, revamp -dump{dir,base}

[Tobias Burnus]

x86_64-none-linux-gnu/test-support/cuda-9.1.85_387.26-390.12/cuda-driver/lib -Wl,-rpath,/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/obj/test-2018.11-99-x86_64-none-linux-gnu/test-support/cuda-9.1.85_387.26-390.12/cuda-driver/lib -I/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/obj/test-2018.11-99-x86_64-none-linux-gnu/test-support/cuda-9.1.85_387.26-390.12/cuda-runtime/include -L/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/obj/test-2018.11-99-x86_64-none-linux-gnu/test-support/cuda-9.1.85_387.26-390.12/cuda-runtime/lib -Wl,-rpath,/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/obj/test-2018.11-99-x86_64-none-linux-gnu/test-support/cuda-9.1.85_387.26-390.12/cuda-runtime/lib -Wl,--allow-shlib-undefined -I/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/libgomp/testsuite/../../include -I/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -B/opt/codesourcery/libexec/gcc/x86_64-none-linux-gnu/11.0.0 -B/opt/codesourcery/bin -fopenacc -I/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/libgomp/testsuite/libgomp.oacc-c-c++-common -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 -foffload=-fdump-rtl-mach -save-temps -lm -o ./nvptx-merged-loop.exe -v -foffload=-v

Using built-in specs.
COLLECT_GCC=./install/opt/codesourcery/bin/x86_64-none-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/install/opt/codesourcery/bin/../libexec/gcc/x86_64-none-linux-gnu/11.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-none-linux-gnu
Configured with: /net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-none-linux-gnu --enable-threads --disable-libmudflap --disable-libstdcxx-pch --disable-multilib --disable-libsanitizer --disable-libcc1 --enable-checking=yes,rtl --with-gnu-as --with-gnu-ld --enable-languages=c,c++,fortran --enable-shared --enable-lto --with-pkgversion='Sourcery CodeBench (OpenACC/PTX) Lite 2018.11-99' --with-bugurl=https://sourcery.mentor.com/GNUToolchain/ --disable-nls --prefix=/opt/codesourcery --enable-offload-targets=nvptx-none --with-sysroot=/opt/codesourcery/x86_64-none-linux-gnu/libc --with-build-sysroot=/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/libc --with-gmp=/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/obj/pkg-2018.11-99-x86_64-none-linux-gnu/sourceryg++-2018.11-99-x86_64-none-linux-gnu.extras/host-libs-x86_64-linux-gnu/usr --with-mpfr=/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/obj/pkg-2018.11-99-x86_64-none-linux-gnu/sourceryg++-2018.11-99-x86_64-none-linux-gnu.extras/host-libs-x86_64-linux-gnu/usr --with-mpc=/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/obj/pkg-2018.11-99-x86_64-none-linux-gnu/sourceryg++-2018.11-99-x86_64-none-linux-gnu.extras/host-libs-x86_64-linux-gnu/usr --with-isl=/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/obj/pkg-2018.11-99-x86_64-none-linux-gnu/sourceryg++-2018.11-99-x86_64-none-linux-gnu.extras/host-libs-x86_64-linux-gnu/usr --with-cuda-driver-include=/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/obj/cuda-2018.11-99-x86_64-none-linux-gnu-x86_64-linux-gnu/cuda-runtime/include --with-cuda-driver-lib=/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/obj/cuda-2018.11-99-x86_64-none-linux-gnu-x86_64-linux-gnu/cuda-driver/lib --enable-libgomp --disable-libitm --enable-libatomic --disable-libssp --disable-libcc1 --with-python-dir=x86_64-none-linux-gnu/share/gdb/python --with-build-time-tools=/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/bin --with-build-time-tools=/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/install/opt/codesourcery/x86_64-none-linux-gnu/bin SED=sed
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200618 (experimental) (Sourcery CodeBench (OpenACC/PTX) Lite 2018.11-99) 
COLLECT_GCC_OPTIONS='-fdiagnostics-color=never' '-I' '../libgomp-config-h/.' '-L/net/build5-trusty-cs/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/obj/test-2018.11-99-x86_64-none-linux-gnu/test-support/cuda-9.1.85_387.26-390.12/cuda-driver/lib' '-I'

RE: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift intrinsics code-gen.

[Kyrylo Tkachov]

> -Original Message-
> From: Srinath Parvathaneni 
> Sent: 17 June 2020 17:17
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov 
> Subject: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift intrinsics code-
> gen.
> 
> Hello,
> 
> This patch modifies the MVE scalar shift RTL patterns. The current patterns
> have wrong constraints and predicates due to which the values returned
> from
> MVE scalar shift instructions are overwritten in the code-gen.
> 
> example:
> $ cat x.c
> int32_t  foo(int64_t acc, int shift)
> {
>   return sqrshrl_sat48 (acc, shift);
> }
> 
> Code-gen before applying this patch:
> $ arm-none-eabi-gcc -march=armv8.1-m.main+mve -mfloat-abi=hard -O2 -S
> $  cat x.s
> foo:
>push{r4, r5}
>sqrshrl r0, r1, #48, r2   > (a)
>mov r0, r4  > (b)
>pop {r4, r5}
>bx  lr
> 
> Code-gen after applying this patch:
> foo:
>sqrshrl r0, r1, #48, r2
>bx  lr
> 
> In the current compiler the return value (r0) from sqrshrl (a) is getting
> overwritten by the mov statement (b).
> This patch fixes above issue.
> 
> Regression tested on arm-none-eabi and found no regressions.
> 
> Ok for gcc-10 branch?
> 

Ok.
Thanks,
Kyrill

> Thanks,
> Srinath.
> 
> 2020-06-12  Srinath Parvathaneni  
> 
> gcc/
>   * config/arm/mve.md (mve_uqrshll_sat_di): Correct the
> predicate
>   and constraint of all the operands.
>   (mve_sqrshrl_sat_di): Likewise.
>   (mve_uqrshl_si): Likewise.
>   (mve_sqrshr_si): Likewise.
>   (mve_uqshll_di): Likewise.
>   (mve_urshrl_di): Likewise.
>   (mve_uqshl_si): Likewise.
>   (mve_urshr_si): Likewise.
>   (mve_sqshl_si): Likewise.
>   (mve_srshr_si): Likewise.
>   (mve_srshrl_di): Likewise.
>   (mve_sqshll_di): Likewise.
>   * config/arm/predicates.md (arm_low_register_operand): Define.
> 
> gcc/testsuite/
>   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts1.c: New test.
>   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts2.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts3.c: Likewise.
>   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts4.c: Likewise.
> 
> (cherry picked from commit 6af598703f919b56f628c496843cdfe6f0cb8276)
> 
> 
> ### Attachment also inlined for ease of reply
> ###
> 
> 
> diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
> index
> 3a57901bd5bcd770832d59dc77cd92b6d9b5ecb4..9758862ac2bb40805dc5b6
> 6c9b05466fffcf91df 100644
> --- a/gcc/config/arm/mve.md
> +++ b/gcc/config/arm/mve.md
> @@ -11344,9 +11344,9 @@
>  ;; [uqrshll_di]
>  ;;
>  (define_insn "mve_uqrshll_sat_di"
> -  [(set (match_operand:DI 0 "arm_general_register_operand" "+r")
> - (unspec:DI [(match_operand:DI 1 "arm_general_register_operand"
> "r")
> - (match_operand:SI 2 "s_register_operand" "r")]
> +  [(set (match_operand:DI 0 "arm_low_register_operand" "=l")
> + (unspec:DI [(match_operand:DI 1 "arm_low_register_operand" "0")
> + (match_operand:SI 2 "register_operand" "r")]
>UQRSHLLQ))]
>"TARGET_HAVE_MVE"
>"uqrshll%?\\t%Q1, %R1, #, %2"
> @@ -11356,9 +11356,9 @@
>  ;; [sqrshrl_di]
>  ;;
>  (define_insn "mve_sqrshrl_sat_di"
> -  [(set (match_operand:DI 0 "arm_general_register_operand" "+r")
> - (unspec:DI [(match_operand:DI 1 "arm_general_register_operand"
> "r")
> - (match_operand:SI 2 "s_register_operand" "r")]
> +  [(set (match_operand:DI 0 "arm_low_register_operand" "=l")
> + (unspec:DI [(match_operand:DI 1 "arm_low_register_operand" "0")
> + (match_operand:SI 2 "register_operand" "r")]
>SQRSHRLQ))]
>"TARGET_HAVE_MVE"
>"sqrshrl%?\\t%Q1, %R1, #, %2"
> @@ -11368,9 +11368,9 @@
>  ;; [uqrshl_si]
>  ;;
>  (define_insn "mve_uqrshl_si"
> -  [(set (match_operand:SI 0 "arm_general_register_operand" "+r")
> - (unspec:SI [(match_operand:SI 1 "arm_general_register_operand"
> "r")
> - (match_operand:SI 2 "s_register_operand" "r")]
> +  [(set (match_operand:SI 0 "arm_general_register_operand" "=r")
> + (unspec:SI [(match_operand:SI 1 "arm_general_register_operand"
> "0")
> + (match_operand:SI 2 "register_operand" "r")]
>UQRSHL))]
>"TARGET_HAVE_MVE"
>"uqrshl%?\\t%1, %2"
> @@ -11380,9 +11380,9 @@
>  ;; [sqrshr_si]
>  ;;
>  (define_insn "mve_sqrshr_si"
> -  [(set (match_operand:SI 0 "arm_general_register_operand" "+r")
> - (unspec:SI [(match_operand:SI 1 "arm_general_register_operand"
> "r")
> - (match_operand:SI 2 "s_register_operand" "r")]
> +  [(set (match_operand:SI 0 "arm_general_register_operand" "=r")
> + (unspec:SI [(match_operand:SI 1 "arm_general_register_operand"
> "0")
> + (match_operand:SI 2 "register_operand" "r")]
>SQRSHR))]
>"TARGET_HAVE_MVE"
>"sqrshr%?\\t%1, %2"
> @@ -11392,9 +11392,9 @@
>  ;; [uqshll_di]
>  ;;
>  (define_insn "mve_uqshll_di"
> -  [(set (match_operand:DI 0 "arm_general_register_operan

Re: [PATCH] vectorizer: add _bb_vec_info::const_iterator

[Jonathan Wakely via Gcc-patches]

On 18/06/20 00:55 +0100, Jonathan Wakely wrote:

Does your reverse iterator work correctly? It looks to me like it will
fail to visit the region_begin statement, because this loop will
terminate when the reverse iterator reaches the end() value, and will
not actually process that gsi:

-  gimple_stmt_iterator si = bb_vinfo->region_end;
-  gimple *stmt;
-  do
+  for (gimple *stmt : bb_vinfo->reverse_region_stmts ())

Adding const_iterator::operator--() and using
std::reverse_iterator would fix that problem. The
std::reverse_iterator utility already solves the problem of getting
the begin and end of a reversed range correct.

You might need to add a couple of things to your const_iterator to
make it more like a conventional STL iterator in order to use
std::reverse_iterator, but IMHO it would be worth it. I can look at
that in the morning.


Using std::reverse_iterator won't work, because this iterator is an
"input iterator" i.e. single pass. Incrementing it modifies the
underlying data structure (the gimple_statement_iterator) so it can't
meet the requirements for a bidirectional iterator.

But fixing the reverse iterator to visit the last statement isn't
hard.

N.B. the fact that the bug in reverse iteration wasn't noticed
suggests missing tests :-)

RE: [PATCH][GCC-10 Backport] arm: Fix the MVE ACLE vaddq_m polymorphic variants.

[Kyrylo Tkachov]

> -Original Message-
> From: Srinath Parvathaneni 
> Sent: 17 June 2020 18:32
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov 
> Subject: [PATCH][GCC-10 Backport] arm: Fix the MVE ACLE vaddq_m
> polymorphic variants.
> 
> Hello,
> 
> This patch fixes the MVE ACLE vaddq_m polymorphic variants by modifying
> the corresponding
> intrinsic parameters and vaddq_m polymorphic variant's _Generic case
> entries in "arm_mve.h"
> header file.
> 
> Regression tested on arm-none-eabi and found no regressions.
> 
> Ok for gcc-10 branch?

Ok.
Thanks,
Kyrill

> 
> Thanks,
> Srinath.
> 
> 2020-06-04  Srinath Parvathaneni  
> 
> gcc/
>   * config/arm/arm_mve.h (__arm_vaddq_m_n_s8): Correct the
> intrinsic
>   arguments.
>   (__arm_vaddq_m_n_s32): Likewise.
>   (__arm_vaddq_m_n_s16): Likewise.
>   (__arm_vaddq_m_n_u8): Likewise.
>   (__arm_vaddq_m_n_u32): Likewise.
>   (__arm_vaddq_m_n_u16): Likewise.
>   (__arm_vaddq_m): Modify polymorphic variant.
> 
> gcc/testsuite/
>   * gcc.target/arm/mve/intrinsics/mve_vaddq_m.c: New test.
> 
> (cherry picked from commit dc39db873670bea8d8e655444387ceaa53a01a79)
> 
> 
> ### Attachment also inlined for ease of reply
> ###
> 
> 
> diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h
> index
> 9bc5c97db8fea15d8140d966bc501b8a457a1abf..a801705ced582105df60ccdc
> 79a7500b320e12d4 100644
> --- a/gcc/config/arm/arm_mve.h
> +++ b/gcc/config/arm/arm_mve.h
> @@ -9713,42 +9713,42 @@ __arm_vabdq_m_u16 (uint16x8_t __inactive,
> uint16x8_t __a, uint16x8_t __b, mve_pr
> 
>  __extension__ extern __inline int8x16_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vaddq_m_n_s8 (int8x16_t __inactive, int8x16_t __a, int8_t __b,
> mve_pred16_t __p)
> +__arm_vaddq_m_n_s8 (int8x16_t __inactive, int8x16_t __a, int __b,
> mve_pred16_t __p)
>  {
>return __builtin_mve_vaddq_m_n_sv16qi (__inactive, __a, __b, __p);
>  }
> 
>  __extension__ extern __inline int32x4_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vaddq_m_n_s32 (int32x4_t __inactive, int32x4_t __a, int32_t __b,
> mve_pred16_t __p)
> +__arm_vaddq_m_n_s32 (int32x4_t __inactive, int32x4_t __a, int __b,
> mve_pred16_t __p)
>  {
>return __builtin_mve_vaddq_m_n_sv4si (__inactive, __a, __b, __p);
>  }
> 
>  __extension__ extern __inline int16x8_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vaddq_m_n_s16 (int16x8_t __inactive, int16x8_t __a, int16_t __b,
> mve_pred16_t __p)
> +__arm_vaddq_m_n_s16 (int16x8_t __inactive, int16x8_t __a, int __b,
> mve_pred16_t __p)
>  {
>return __builtin_mve_vaddq_m_n_sv8hi (__inactive, __a, __b, __p);
>  }
> 
>  __extension__ extern __inline uint8x16_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vaddq_m_n_u8 (uint8x16_t __inactive, uint8x16_t __a, uint8_t __b,
> mve_pred16_t __p)
> +__arm_vaddq_m_n_u8 (uint8x16_t __inactive, uint8x16_t __a, int __b,
> mve_pred16_t __p)
>  {
>return __builtin_mve_vaddq_m_n_uv16qi (__inactive, __a, __b, __p);
>  }
> 
>  __extension__ extern __inline uint32x4_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vaddq_m_n_u32 (uint32x4_t __inactive, uint32x4_t __a, uint32_t
> __b, mve_pred16_t __p)
> +__arm_vaddq_m_n_u32 (uint32x4_t __inactive, uint32x4_t __a, int __b,
> mve_pred16_t __p)
>  {
>return __builtin_mve_vaddq_m_n_uv4si (__inactive, __a, __b, __p);
>  }
> 
>  __extension__ extern __inline uint16x8_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vaddq_m_n_u16 (uint16x8_t __inactive, uint16x8_t __a, uint16_t
> __b, mve_pred16_t __p)
> +__arm_vaddq_m_n_u16 (uint16x8_t __inactive, uint16x8_t __a, int __b,
> mve_pred16_t __p)
>  {
>return __builtin_mve_vaddq_m_n_uv8hi (__inactive, __a, __b, __p);
>  }
> @@ -26493,42 +26493,42 @@ __arm_vabdq_m (uint16x8_t __inactive,
> uint16x8_t __a, uint16x8_t __b, mve_pred16
> 
>  __extension__ extern __inline int8x16_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vaddq_m (int8x16_t __inactive, int8x16_t __a, int8_t __b,
> mve_pred16_t __p)
> +__arm_vaddq_m (int8x16_t __inactive, int8x16_t __a, int __b,
> mve_pred16_t __p)
>  {
>   return __arm_vaddq_m_n_s8 (__inactive, __a, __b, __p);
>  }
> 
>  __extension__ extern __inline int32x4_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vaddq_m (int32x4_t __inactive, int32x4_t __a, int32_t __b,
> mve_pred16_t __p)
> +__arm_vaddq_m (int32x4_t __inactive, int32x4_t __a, int __b,
> mve_pred16_t __p)
>  {
>   return __arm_vaddq_m_n_s32 (__inactive, __a, __b, __p);
>  }
> 
>  __extension__ extern __inline int16x8_t
>  __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> -__arm_vaddq_m (int16x8_t __inactive, int16x8_t __a, int16_t __b,
> mve_pred16_t __p)
> +__arm_vaddq_m (int16x8_t __inactive, int16x8_t __a, int __b,
> mve_p

Re: [PATCH] forwprop: simplify_vector_constructor follow-up fix [PR95713]

[Richard Biener]

On Thu, 18 Jun 2020, Jakub Jelinek wrote:

> Hi!
> 
> As the following testcase shows, the exception for the aarch64
> vec_pack_trunc_di is not sufficient on x86, the halfvectype
> "vectors" have SImode but the x86 vec_pack_trunc_si meant for
> the bool bitmasks combines 2x SImode into DImode, while in the
> testcase the halfvectype is 1x SImode "vector" with SImode and
> result is 2x HImode "vector" with SImode.
> 
> The patch also verifies the result mode.  The other option is
> to throw away the aarch64 exception.  And yet another option
> would be to use different optabs for vector bools with integral modes.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/10.2?

OK.

Given we now have expanders for the actual conversion operation on
x86_64 as well we might consider removing all this VEC_[UN]PACK[_FLOAT]_..
stuff again.  Though I guess the VEC_[UN]PACK_FLOAT variants are
still not covered by vector mode [us]float_optab and
vector typed FLOAT_EXPR?

Thanks,
Richard.

> 2020-06-18  Jakub Jelinek  
> 
>   PR target/95713
>   * tree-ssa-forwprop.c: Include insn-config.h and recog.h.
>   (simplify_vector_constructor): For integral TYPE_MODE of
>   non-VECTOR_BOOLEAN_P vector same as element mode, verify also
>   that lhs mode matches the output operand mode of the expander.
> 
>   * gcc.dg/pr95713.c: New test.
> 
> --- gcc/tree-ssa-forwprop.c.jj2020-06-08 11:05:04.196939262 +0200
> +++ gcc/tree-ssa-forwprop.c   2020-06-17 11:18:10.816155772 +0200
> @@ -51,6 +51,8 @@ along with GCC; see the file COPYING3.
>  #include "internal-fn.h"
>  #include "cgraph.h"
>  #include "tree-ssa.h"
> +#include "insn-config.h"
> +#include "recog.h"
>  
>  /* This pass propagates the RHS of assignment statements into use
> sites of the LHS of the assignment.  It's basically a specialized
> @@ -2391,7 +2393,8 @@ simplify_vector_constructor (gimple_stmt
> /* Only few targets implement direct conversion patterns so try
>some simple special cases via VEC_[UN]PACK[_FLOAT]_LO_EXPR.  */
> optab optab;
> -   tree halfvectype, dblvectype;
> +   enum insn_code icode;
> +   tree halfvectype, dblvectype, lhs;
> if (CONVERT_EXPR_CODE_P (conv_code)
> && (2 * TYPE_PRECISION (TREE_TYPE (TREE_TYPE (orig[0])))
> == TYPE_PRECISION (TREE_TYPE (type)))
> @@ -2446,18 +2449,21 @@ simplify_vector_constructor (gimple_stmt
>  && (halfvectype
>= build_vector_type (TREE_TYPE (TREE_TYPE (orig[0])),
> nelts / 2))
> +&& (optab = optab_for_tree_code (VEC_PACK_TRUNC_EXPR,
> + halfvectype,
> + optab_default))
> +&& ((icode = optab_handler (optab, TYPE_MODE (halfvectype)))
> +!= CODE_FOR_nothing)
>  /* Only use it for vector modes or for vector booleans
> represented as scalar bitmasks, or allow halfvectype
> be the element mode.  See PR95528.  */
>  && (VECTOR_MODE_P (TYPE_MODE (halfvectype))
>  || VECTOR_BOOLEAN_TYPE_P (halfvectype)
>  || (TYPE_MODE (halfvectype)
> -== TYPE_MODE (TREE_TYPE (halfvectype
> -&& (optab = optab_for_tree_code (VEC_PACK_TRUNC_EXPR,
> - halfvectype,
> - optab_default))
> -&& (optab_handler (optab, TYPE_MODE (halfvectype))
> -!= CODE_FOR_nothing))
> +== TYPE_MODE (TREE_TYPE (halfvectype))
> +&& (lhs == gimple_assign_lhs (stmt))
> +&& (insn_data[icode].operand[0].mode
> +== TYPE_MODE (TREE_TYPE (lhs))
>   {
> gimple_seq stmts = NULL;
> tree low = gimple_build (&stmts, BIT_FIELD_REF, halfvectype,
> --- gcc/testsuite/gcc.dg/pr95713.c.jj 2020-06-17 11:20:12.288381166 +0200
> +++ gcc/testsuite/gcc.dg/pr95713.c2020-06-17 11:19:56.057618283 +0200
> @@ -0,0 +1,15 @@
> +/* PR target/95713 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -Wno-psabi -w" } */
> +/* { dg-additional-options "-mavx512bw" { target i?86-*-* x86_64-*-* } } */
> +
> +typedef int v2si __attribute__((vector_size (8)));
> +typedef short int v2hi __attribute__((vector_size (4)));
> +void foo (v2hi);
> +
> +void
> +bar (v2si x)
> +{
> +  v2hi a = (v2hi) { (short) x[0], (short) x[1] };
> +  foo (4 > a);
> +}
> 
>   Jakub
> 
> 

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

Re: [PATCH] phiopt: Improve minmax optimization [PR95699]

[Richard Biener]

On Thu, 18 Jun 2020, Jakub Jelinek wrote:

> Hi!
> 
> As discussed in the PR, the
> x < 0x8000U to (int) x >= 0
> optimization stands in the way of minmax_replacement optimization,
> so for comparisons with most of the constants it works well, but when the
> above mentioned optimization triggers, it is unable to do it.
> The match.pd (cond (cmp (convert? x) c1) (op x c2) c3) -> (op (minmax x c1) 
> c2)
> optimization is able to look through that and this patch
> teaches minmax_replacement about it too.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

I wonder if we can leverage gimple_build or gimple_match_op::resimplify
to move the actual pattern matching to match.pd completely in at least
part of phiopt?  We'd feed a COND_EXPR to the matcher and similar
to maybe_fold_comparisons_from_match_pd we'd need one "on stack"
GIMPLE stmt for the comparison to avoid building it as GENERIC tree
(which for COND_EXPR would of course also work up to now).

Thanks,
Richard.

> 2020-06-18  Jakub Jelinek  
> 
>   PR tree-optimization/95699
>   * tree-ssa-phiopt.c (minmax_replacement): Treat (signed int)x < 0
>   as x > INT_MAX and (signed int)x >= 0 as x <= INT_MAX.  Move variable
>   declarations to the statements that set them where possible.
> 
>   * gcc.dg/tree-ssa/pr95699.c: New test.
> 
> --- gcc/tree-ssa-phiopt.c.jj  2020-06-05 10:42:40.792893013 +0200
> +++ gcc/tree-ssa-phiopt.c 2020-06-17 13:36:20.600659487 +0200
> @@ -1363,22 +1363,21 @@ minmax_replacement (basic_block cond_bb,
>   edge e0, edge e1, gimple *phi,
>   tree arg0, tree arg1)
>  {
> -  tree result, type, rhs;
> -  gcond *cond;
> +  tree result;
>edge true_edge, false_edge;
> -  enum tree_code cmp, minmax, ass_code;
> -  tree smaller, alt_smaller, larger, alt_larger, arg_true, arg_false;
> +  enum tree_code minmax, ass_code;
> +  tree smaller, larger, arg_true, arg_false;
>gimple_stmt_iterator gsi, gsi_from;
>  
> -  type = TREE_TYPE (PHI_RESULT (phi));
> +  tree type = TREE_TYPE (PHI_RESULT (phi));
>  
>/* The optimization may be unsafe due to NaNs.  */
>if (HONOR_NANS (type) || HONOR_SIGNED_ZEROS (type))
>  return false;
>  
> -  cond = as_a  (last_stmt (cond_bb));
> -  cmp = gimple_cond_code (cond);
> -  rhs = gimple_cond_rhs (cond);
> +  gcond *cond = as_a  (last_stmt (cond_bb));
> +  enum tree_code cmp = gimple_cond_code (cond);
> +  tree rhs = gimple_cond_rhs (cond);
>  
>/* Turn EQ/NE of extreme values to order comparisons.  */
>if ((cmp == NE_EXPR || cmp == EQ_EXPR)
> @@ -1401,8 +1400,8 @@ minmax_replacement (basic_block cond_bb,
>  
>/* This transformation is only valid for order comparisons.  Record which
>   operand is smaller/larger if the result of the comparison is true.  */
> -  alt_smaller = NULL_TREE;
> -  alt_larger = NULL_TREE;
> +  tree alt_smaller = NULL_TREE;
> +  tree alt_larger = NULL_TREE;
>if (cmp == LT_EXPR || cmp == LE_EXPR)
>  {
>smaller = gimple_cond_lhs (cond);
> @@ -1463,6 +1462,50 @@ minmax_replacement (basic_block cond_bb,
>else
>  return false;
>  
> +  /* Handle the special case of (signed_type)x < 0 being equivalent
> + to x > MAX_VAL(signed_type) and (signed_type)x >= 0 equivalent
> + to x <= MAX_VAL(signed_type).  */
> +  if ((cmp == GE_EXPR || cmp == LT_EXPR)
> +  && INTEGRAL_TYPE_P (type)
> +  && TYPE_UNSIGNED (type)
> +  && integer_zerop (rhs))
> +{
> +  tree op = gimple_cond_lhs (cond);
> +  if (TREE_CODE (op) == SSA_NAME
> +   && INTEGRAL_TYPE_P (TREE_TYPE (op))
> +   && !TYPE_UNSIGNED (TREE_TYPE (op)))
> + {
> +   gimple *def_stmt = SSA_NAME_DEF_STMT (op);
> +   if (gimple_assign_cast_p (def_stmt))
> + {
> +   tree op1 = gimple_assign_rhs1 (def_stmt);
> +   if (INTEGRAL_TYPE_P (TREE_TYPE (op1))
> +   && TYPE_UNSIGNED (TREE_TYPE (op1))
> +   && (TYPE_PRECISION (TREE_TYPE (op))
> +   == TYPE_PRECISION (TREE_TYPE (op1)))
> +   && useless_type_conversion_p (type, TREE_TYPE (op1)))
> + {
> +   wide_int w1 = wi::max_value (TREE_TYPE (op));
> +   wide_int w2 = wi::add (w1, 1);
> +   if (cmp == LT_EXPR)
> + {
> +   larger = op1;
> +   smaller = wide_int_to_tree (TREE_TYPE (op1), w1);
> +   alt_smaller = wide_int_to_tree (TREE_TYPE (op1), w2);
> +   alt_larger = NULL_TREE;
> + }
> +   else
> + {
> +   smaller = op1;
> +   larger = wide_int_to_tree (TREE_TYPE (op1), w1);
> +   alt_larger = wide_int_to_tree (TREE_TYPE (op1), w2);
> +   alt_smaller = NULL_TREE;
> + }
> + }
> + }
> + }
> +}
> +
>/* We need to know which is the true edge and which is the false
>  

Re: [PATCH] forwprop: simplify_vector_constructor follow-up fix [PR95713]

[Richard Sandiford]

Richard Biener  writes:
> On Thu, 18 Jun 2020, Jakub Jelinek wrote:
>
>> Hi!
>> 
>> As the following testcase shows, the exception for the aarch64
>> vec_pack_trunc_di is not sufficient on x86, the halfvectype
>> "vectors" have SImode but the x86 vec_pack_trunc_si meant for
>> the bool bitmasks combines 2x SImode into DImode, while in the
>> testcase the halfvectype is 1x SImode "vector" with SImode and
>> result is 2x HImode "vector" with SImode.
>> 
>> The patch also verifies the result mode.  The other option is
>> to throw away the aarch64 exception.  And yet another option
>> would be to use different optabs for vector bools with integral modes.
>> 
>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/10.2?
>
> OK.

FWIW, since the aarch64 case was only found by inspection and might
not be useful, personally I'd prefer to drop that case after all.

Thanks,
Richard

Re: [PATCH] avoid early asm output

[Richard Biener]

On Thu, 18 Jun 2020, Jakub Jelinek wrote:

> On Thu, Jun 18, 2020 at 11:08:53AM +0200, Richard Biener wrote:
> > This avoids early assembler output via the gimplifier creating
> > new static CTORs.  The output machinery seems to be prepared to
> > output constants recursively and it's just a matter of
> > appropriately defering or not defering output.
> > 
> > This also has the advantage of not outputting .string for
> > optimized away local aggregate initializers containing string
> > references.
> > 
> > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> 
> Use bool instead of int?

Shortly thought about it but then went with int because of the
pre-existing interface of output_constant_def which "interferes"
with this (ripples down into users in expr.c as well).

If you insist I'll hunt them all down ...

Thanks,
Richard.

Re: [PATCH] avoid early asm output

[Jakub Jelinek via Gcc-patches]

On Thu, Jun 18, 2020 at 12:03:26PM +0200, Richard Biener wrote:
> Shortly thought about it but then went with int because of the
> pre-existing interface of output_constant_def which "interferes"
> with this (ripples down into users in expr.c as well).
> 
> If you insist I'll hunt them all down ...

I don't insist, it was just a random comment.

Jakub

Re: drop -aux{dir,base}, revamp -dump{dir,base}

[Alexandre Oliva]

On Jun 18, 2020, Tobias Burnus  wrote:

> On 6/18/20 8:10 AM, Alexandre Oliva wrote:
>> Could you possibly give this *completely* untested patch a try and let
>> me know whether it does any good?

> Otherwise, see attachment. I now added also the @/tmp file which is
> passed to mkoffload.

Thanks.  I see the main problem besides the dumppfx constness is the
double dot before target, fixed in the revised patch below.

With this, I think the libgomp testsuite might work with offloading
again.

>> I actually thought it might be appropriate to use ".x"
>> instead of ".target" in the dumpbase passed to mkoffload, so that we
>> create different file names for different offload targets,

> I wonder whether we need to do this – as one can create code for
> multiple offload targets by the same compiler at the same time.

Aah, I wasn't sure this was indeed the case.

Well, then, I'll try to figure out how to get to the selected offloading
target from the scandump machinery.

> and intelmic.

How does intelmic get into the picture?  I looked for a mkoffload
program for it in the GCC source tree and couldn't find one.  This
suggests that the addition of -dumpbase to the mkoffload interface might
require changes elsewhere.


handle dumpbase in offloading

From: Alexandre Oliva 

Pass dumpbase on to mkoffloads and their offload-target compiler runs.
Obey -save-temps in naming temporary files while at that.


for  gcc/ChangeLog

* colllect-utils.h (dumppfx): New.
* colllect-utils.c (dumppfx): Likewise.
* lto-wrapper.c (run_gcc): Set global dumppfx.
(compile_offload_image): Pass a -dumpbase on to mkoffload.
* config/nvptx/mkoffload.c (ptx_dumpbase): New.
(main): Handle incoming -dumpbase.  Set ptx_dumpbase.  Obey
save_temps.
(compile_native): Pass -dumpbase et al to compiler.
* config/gcn/mkoffload.c (gcn_dumpbase): New.
(main): Handle incoming -dumpbase.  Set gcn_dumpbase.  Obey
save_temps.  Pass -dumpbase et al to offload target compiler.
(compile_native): Pass -dumpbase et al to compiler.

for  gcc/testsuite/ChangeLog

* lib/scanoffloadrtl.exp: Replace ".o" with
".target.mkoffload" globally as the dump base suffix.
* lib/scanoffloadtree.exp: Likewise.
---
 gcc/collect-utils.c   |1 +
 gcc/collect-utils.h   |1 +
 gcc/config/gcn/mkoffload.c|   52 ++---
 gcc/config/nvptx/mkoffload.c  |   31 ++--
 gcc/lto-wrapper.c |   16 +-
 gcc/testsuite/lib/scanoffloadrtl.exp  |   28 +-
 gcc/testsuite/lib/scanoffloadtree.exp |   30 ++-
 7 files changed, 121 insertions(+), 38 deletions(-)

diff --git a/gcc/collect-utils.c b/gcc/collect-utils.c
index e85843bc..d4fa2c3 100644
--- a/gcc/collect-utils.c
+++ b/gcc/collect-utils.c
@@ -34,6 +34,7 @@ static char *response_file;
 bool debug;
 bool verbose;
 bool save_temps;
+const char *dumppfx;
 
 
 /* Notify user of a non-error.  */
diff --git a/gcc/collect-utils.h b/gcc/collect-utils.h
index e7c955f..6ff7d9d9 100644
--- a/gcc/collect-utils.h
+++ b/gcc/collect-utils.h
@@ -37,6 +37,7 @@ extern void utils_cleanup (bool);
 extern bool debug;
 extern bool verbose;
 extern bool save_temps;
+extern const char *dumppfx;
 
 /* Provided by the tool itself.  */
 
diff --git a/gcc/config/gcn/mkoffload.c b/gcc/config/gcn/mkoffload.c
index 4a99d70..9046451a 100644
--- a/gcc/config/gcn/mkoffload.c
+++ b/gcc/config/gcn/mkoffload.c
@@ -41,6 +41,7 @@ static const char *gcn_s1_name;
 static const char *gcn_s2_name;
 static const char *gcn_o_name;
 static const char *gcn_cfile_name;
+static const char *gcn_dumpbase;
 
 enum offload_abi offload_abi = OFFLOAD_ABI_UNSET;
 
@@ -496,6 +497,12 @@ compile_native (const char *infile, const char *outfile, 
const char *compiler)
 obstack_ptr_grow (&argv_obstack, "-save-temps");
   if (verbose)
 obstack_ptr_grow (&argv_obstack, "-v");
+  obstack_ptr_grow (&argv_obstack, "-dumpdir");
+  obstack_ptr_grow (&argv_obstack, "");
+  obstack_ptr_grow (&argv_obstack, "-dumpbase");
+  obstack_ptr_grow (&argv_obstack, gcn_dumpbase);
+  obstack_ptr_grow (&argv_obstack, "-dumpbase-ext");
+  obstack_ptr_grow (&argv_obstack, ".c");
   switch (offload_abi)
 {
 case OFFLOAD_ABI_LP64:
@@ -525,6 +532,7 @@ main (int argc, char **argv)
   FILE *out = stdout;
   FILE *cfile = stdout;
   const char *outname = 0;
+  char *dumpbase;
 
   progname = "mkoffload";
   diagnostic_initialize (global_dc, 0);
@@ -611,6 +619,9 @@ main (int argc, char **argv)
save_temps = true;
   else if (strcmp (argv[i], "-v") == 0)
verbose = true;
+  else if (strcmp (argv[i], "-dumpbase") == 0
+  && i + 1 < argc)
+   dumppfx = argv[++i];
 }
   if (!(fopenacc ^ fopenmp))
 fatal_error (input_location, "either -fopenacc or -fopenmp must be set");
@@ -628,11 +639,6 @@ main (int argc, c

Move simplification of statements using ranges into its own class.

[Aldy Hernandez via Gcc-patches]

Howdy.

This moves all the simplification code from vr_values into a separate 
class (simplify_using_ranges).  In doing so, we get rid of a bunch of 
dependencies on the internals of vr_values.  The goal is to (a) remove 
unnecessary interdependendcies (b) be able to use this engine with any 
range infrastructure, as all it needs is a method to get the range for 
an SSA name (get_value_range).


I also removed as many dependencies on value_range_equiv as possible, 
preferring value_range.  A few value_range_equiv uses remain, but for 
cases where equivalences are actually used (folding conditionals, etc).


The plan is to use it like this:

  simplify_using_ranges simplifier (vr_values_thinggie);
  simplifier.simplify (gsi);

OK?

Aldy

commit 753d495161942d7085c5955f47fefa7a4378562a
Author: Aldy Hernandez 
Date:   Thu Jun 18 10:37:14 2020 +0200

Move simplification of statements using ranges into its own class.

This moves all the simplification code from vr_values into a separate
class (simplify_using_ranges).  In doing so, we get rid of a bunch of
dependencies on the internals of vr_values.  The goal is to (a) remove
unnecessary interdependendcies (b) be able to use this engine with any
range infrastructure, as all it needs is a method to get the range for
an SSA name (get_value_range).

I also removed as many dependencies on value_range_equiv as possible,
preferring value_range.  A few value_range_equiv uses remain, but for
cases where equivalences are actually used (folding conditionals, etc).

gcc/ChangeLog:

* gimple-ssa-evrp-analyze.h (vrp_visit_cond_stmt): Use
simplify_using_ranges class.
* gimple-ssa-evrp.c (class evrp_folder): New simplify_using_ranges
field.  Adjust all methods to use new field.
* tree-ssa-dom.c (simplify_stmt_for_jump_threading): Use
simplify_using_ranges class.
* tree-vrp.c (class vrp_folder): New simplify_using_ranges
field.  Adjust all methods to use new field.
(simplify_stmt_for_jump_threading): Use simplify_using_ranges class.
(vrp_prop::vrp_finalize): New vrp_folder argument.
(execute_vrp): Pass folder to vrp_finalize.  Use
simplify_using_ranges class.
Remove cleanup_edges_and_switches call.
* vr-values.c (vr_values::op_with_boolean_value_range_p): Change
value_range_equiv uses to value_range.
(simplify_using_ranges::op_with_boolean_value_range_p): Use
simplify_using_ranges class.
(check_for_binary_op_overflow): Make static.
(vr_values::extract_range_basic): Pass this to
check_for_binary_op_overflow.
(compare_range_with_value): Change value_range_equiv uses to
value_range.
(vr_values::vr_values): Initialize simplifier field.
Remove uses of to_remove_edges and to_update_switch_stmts.
(vr_values::~vr_values): Remove uses of to_remove_edges and
to_update_switch_stmts.
(vr_values::get_vr_for_comparison): Move to simplify_using_ranges
class.
(vr_values::compare_name_with_value): Same.
(vr_values::compare_names): Same.
(vr_values::vrp_evaluate_conditional_warnv_with_ops): Same.
(vr_values::vrp_evaluate_conditional): Same.
(vr_values::vrp_visit_cond_stmt): Same.
(find_case_label_ranges): Change value_range_equiv uses to
value_range.
(vr_values::extract_range_from_stmt): Use simplify_using_ranges class.
(vr_values::simplify_truth_ops_using_ranges): Move to
simplify_using_ranges class.
(vr_values::simplify_div_or_mod_using_ranges): Same.
(vr_values::simplify_min_or_max_using_ranges): Same.
(vr_values::simplify_abs_using_ranges): Same.
(vr_values::simplify_bit_ops_using_ranges): Same.
(test_for_singularity): Change value_range_equiv uses to
value_range.
(range_fits_type_p): Same.
(vr_values::simplify_cond_using_ranges_1): Same.
(vr_values::simplify_cond_using_ranges_2): Make extern.
(vr_values::fold_cond): Move to simplify_using_ranges class.
(vr_values::simplify_switch_using_ranges): Same.
(vr_values::cleanup_edges_and_switches): Same.
(vr_values::simplify_float_conversion_using_ranges): Same.
(vr_values::simplify_internal_call_using_ranges): Same.
(vr_values::two_valued_val_range_p): Same.
(vr_values::simplify_stmt_using_ranges): Move to...
(simplify_using_ranges::simplify): ...here.
* vr-values.h (class vr_values): Move all the simplification of
statements using ranges methods and code from here...
(class simplify_using_ranges): ...to 

Re: [stage1][PATCH] Add gcc_assert that &global_options are not dirty modified.

[Luis Machado via Gcc-patches]

FTR, I'm running into this ICE when attempting to build the Linux Kernel 
for arm64.


More specifically:

/repos/linux-arm/kernel/bpf/core.c:1368:1: internal compiler error: 
‘global_options’ are modified in local context

 1368 | {
  | ^
0xc0554b cl_optimization_compare(gcc_options*, gcc_options*)
/build/gcc-master/gcc/options-save.c:9786
0x7812df handle_optimize_attribute
../../../repos/gcc/gcc/c-family/c-attribs.c:4475
0x666477 decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../../repos/gcc/gcc/attribs.c:714
0x688c9b start_function(c_declspecs*, c_declarator*, tree_node*)
../../../repos/gcc/gcc/c/c-decl.c:9177
0x6f85f3 c_parser_declaration_or_fndef
../../../repos/gcc/gcc/c/c-parser.c:2434
0x7038af c_parser_external_declaration
../../../repos/gcc/gcc/c/c-parser.c:1773
0x7044c7 c_parser_translation_unit
../../../repos/gcc/gcc/c/c-parser.c:1646
0x7044c7 c_parse_file()
../../../repos/gcc/gcc/c/c-parser.c:21822
0x764897 c_common_parse_file()
../../../repos/gcc/gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I don't have a reduced testcase for this, but I thought I'd check if 
this is known/being worked on before filing a bug.


On 6/9/20 6:01 PM, Jeff Law via Gcc-patches wrote:

On Thu, 2020-05-21 at 14:04 +0200, Martin Liška wrote:

PING^1

On 3/20/20 4:55 PM, Martin Liška wrote:

Ok, it would be possible, but if you take a look at options-save.c there's no
function that will leverage that. It's a generated code so I guess we can
live with that?

Given the size increase is under control now, I think this is fine for the 
trunk.

jeff

[PATCH] [RFC] Delay asm_out_file initialization

[Richard Biener]

This delays asm_out_file initialization to until after IPA.
OK, not actually for LTO for which the situation is more complicated
since during IPA phases we write LTO IL and very early we output
early debug DIEs.

The RTL FE bits are a bit ugly and require checking for
multiple invocations of init_asm_output since it directly
runs the RTL passes for reach parsed function rather than
somehow funneling all of it through the cgraph machinery.

All -gstabs tests ICE because stabs outputs assembly in dbxout_init.
That needs to be put into dbxout_assembly_start (which doesn't
exist yet).  But .. can we kill stabs please?

Given all of the above - not sure if I want to pursue this
further at this point.

* toplev.h (init_asm_output): Declare.
* toplev.c (init_asm_output): Export.
(lang_dependent_init): Do not call it here,
* cgrapunit.c (symbol_table::compile): but here.
...
---
 gcc/cgraph.h |  4 ++--
 gcc/cgraphunit.c | 17 ++---
 gcc/lto/lto.c|  2 +-
 gcc/run-rtl-passes.c |  3 +++
 gcc/toplev.c | 13 +
 gcc/toplev.h |  1 +
 6 files changed, 26 insertions(+), 14 deletions(-)

diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index cfae6e91da9..db4a248e337 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -2278,7 +2278,7 @@ public:
   inline asm_node *finalize_toplevel_asm (tree asm_str);
 
   /* Analyze the whole compilation unit once it is parsed completely.  */
-  void finalize_compilation_unit (void);
+  void finalize_compilation_unit (const char *);
 
   /* C++ frontend produce same body aliases all over the place, even before PCH
  gets streamed out. It relies on us linking the aliases with their function
@@ -2288,7 +2288,7 @@ public:
   void process_same_body_aliases (void);
 
   /* Perform simple optimizations based on callgraph.  */
-  void compile (void);
+  void compile (const char *);
 
   /* Process CGRAPH_NEW_FUNCTIONS and perform actions necessary to add these
  functions into callgraph in a way so they look like ordinary reachable
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index ea9a34bda6f..7836761f21b 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -2731,7 +2731,7 @@ symbol_table::output_weakrefs (void)
 /* Perform simple optimizations based on callgraph.  */
 
 void
-symbol_table::compile (void)
+symbol_table::compile (const char *name)
 {
   if (seen_error ())
 return;
@@ -2753,6 +2753,8 @@ symbol_table::compile (void)
   if (!seen_error ())
   {
 timevar_start (TV_CGRAPH_IPA_PASSES);
+if (flag_wpa)
+  init_asm_output (name);
 ipa_passes ();
 timevar_stop (TV_CGRAPH_IPA_PASSES);
   }
@@ -2776,6 +2778,12 @@ symbol_table::compile (void)
   timevar_pop (TV_CGRAPHOPT);
 
   /* Output everything.  */
+  if (!flag_wpa && !flag_generate_lto && !flag_generate_offload)
+{
+  /* ???  The RTL FE may already have opened asm_out_file.  */
+  if (!asm_out_file)
+   init_asm_output (name);
+}
   switch_to_section (text_section);
   (*debug_hooks->assembly_start) ();
   if (!quiet_flag)
@@ -2943,7 +2951,7 @@ debuginfo_early_stop (void)
 /* Analyze the whole compilation unit once it is parsed completely.  */
 
 void
-symbol_table::finalize_compilation_unit (void)
+symbol_table::finalize_compilation_unit (const char *name)
 {
   timevar_push (TV_CGRAPH);
 
@@ -2994,13 +3002,16 @@ symbol_table::finalize_compilation_unit (void)
 
   /* Clean up anything that needs cleaning up after initial debug
 generation.  */
+
+  if (flag_generate_lto || flag_generate_offload)
+   init_asm_output (name);
   debuginfo_early_start ();
   (*debug_hooks->early_finish) (main_input_filename);
   debuginfo_early_stop ();
 }
 
   /* Finally drive the pass manager.  */
-  compile ();
+  compile (name);
 
   timevar_pop (TV_CGRAPH);
 }
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 1c37814bde4..b92658e0576 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -650,7 +650,7 @@ lto_main (void)
 
  /* Let the middle end know that we have read and merged all of
 the input files.  */
- symtab->compile ();
+ symtab->compile (main_input_filename);
 
  timevar_stop (TV_PHASE_OPT_GEN);
 
diff --git a/gcc/run-rtl-passes.c b/gcc/run-rtl-passes.c
index fdb24816b4d..b1c5c646125 100644
--- a/gcc/run-rtl-passes.c
+++ b/gcc/run-rtl-passes.c
@@ -35,6 +35,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "insn-attr-common.h" /* for INSN_SCHEDULING.  */
 #include "insn-attr.h" /* for init_sched_attrs.  */
 #include "run-rtl-passes.h"
+#include "toplev.h"
 
 /* Run the backend passes, starting at the given pass.
Take ownership of INITIAL_PASS_NAME.  */
@@ -46,6 +47,8 @@ run_rtl_passes (char *initial_pass_name)
   max_regno = max_reg_num ();
 
   /* cgraphunit.c normally handles this.  */
+  if (!asm_out_file)
+init_asm_output (main_input_filename);
   switch_to_section (text_section);
   (*debug_hooks->as

Re: drop -aux{dir,base}, revamp -dump{dir,base}

[Tobias Burnus]

On 6/18/20 12:39 PM, Alexandre Oliva wrote:

Thanks.  I see the main problem besides the dumppfx constness is the
double dot before target, fixed in the revised patch below.

With this, I think the libgomp testsuite might work with offloading
again.


Thanks. I have only tried the first one of the list Thomas has sent.

Result as follows – seems to work: PASS :-)
(last but one line: 'scan-…'):

UNSUPPORTED: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-merged-loop.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0
PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-merged-loop.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O2  (test 
for excess errors)
PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-merged-loop.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O2  
execution test
PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-merged-loop.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O2   
scan-offload-rtl-dump mach "Merging loop .* into "
UNSUPPORTED: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-merged-loop.c 
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable  -O2

[As previously mentioned, the libgomp OpenACC tests cycle through:
-foffload=nvptx-none + ...=disable  plus the -D… defines.
(That build supports neither amdgcn, hsa nor intelmic.)]


and intelmic.

How does intelmic get into the picture?


No idea – I just know that it counts as offloading platform,
ENABLE_OFFLOAD is set for it (but not for has).
I just wanted to mention it GCC supports it, in principle.
(What I have heard is that it does not exist in silicon but
only as simulator, which can be used for testing with GCC,
but I did not follow this at all.)


   I looked for a mkoffload
program for it in the GCC source tree and couldn't find one.  This
suggests that the addition of -dumpbase to the mkoffload interface might
require changes elsewhere.


Maybe. I think Thomas is the only one who runs GCC with
emulated intelmic once in a while – thus, he surely knows a bit more about it.
But also Jakub should have an idea.

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

[PATCH] gcc-changelog: support merge commits in git_update_version

[Martin Liška]

The patch addresses need to generate ChangeLog for a vendor branch
(redhat/gcc-10-branch) that can contain merge commits.

Tested on c518050989be3a224a04a8b33d73f37a16c30fbb and current active branches.
Jakub: Can you please test it?

Martin

contrib/ChangeLog:

* gcc-changelog/git_update_version.py: Support merge commits
and walk only on the branch that is being merged and generate
missing ChangeLog entries.
---
 contrib/gcc-changelog/git_update_version.py | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/contrib/gcc-changelog/git_update_version.py 
b/contrib/gcc-changelog/git_update_version.py
index 733a1a0f14a..7077880cf80 100755
--- a/contrib/gcc-changelog/git_update_version.py
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -81,15 +81,23 @@ def update_current_branch():
 if (commit.author.email == 'gccad...@gcc.gnu.org'
 and commit.message.strip() == 'Daily bump.'):
 break
-commit = commit.parents[0]
+# We support merge commits but only with 2 parensts
+assert len(commit.parents) <= 2
+commit = commit.parents[-1]
 commit_count += 1
 
 print('%d revisions since last Daily bump' % commit_count)

 datestamp_path = os.path.join(args.git_path, 'gcc/DATESTAMP')
 if (read_timestamp(datestamp_path) != current_timestamp
 or args.dry_mode or args.current):
-commits = parse_git_revisions(args.git_path, '%s..HEAD'
-  % commit.hexsha)
+head = repo.head.commit
+# if HEAD is a merge commit, start with second parent
+# (branched that is being merged into the current one)
+assert len(head.parents) <= 2
+if len(head.parents) == 2:
+head = head.parents[1]
+commits = parse_git_revisions(args.git_path, '%s..%s'
+  % (commit.hexsha, head.hexsha))
 for git_commit in reversed(commits):
 prepend_to_changelog_files(repo, args.git_path, git_commit,
not args.dry_mode)
--
2.27.0

Re: [stage1][PATCH] Add gcc_assert that &global_options are not dirty modified.

[Martin Liška]

On 6/18/20 1:32 PM, Luis Machado wrote:

FTR, I'm running into this ICE when attempting to build the Linux Kernel for 
arm64.


Hello.

Thanks for the report.



More specifically:

/repos/linux-arm/kernel/bpf/core.c:1368:1: internal compiler error: 
‘global_options’ are modified in local context
  1368 | {
   | ^
0xc0554b cl_optimization_compare(gcc_options*, gcc_options*)
     /build/gcc-master/gcc/options-save.c:9786
0x7812df handle_optimize_attribute
     ../../../repos/gcc/gcc/c-family/c-attribs.c:4475
0x666477 decl_attributes(tree_node**, tree_node*, int, tree_node*)
     ../../../repos/gcc/gcc/attribs.c:714
0x688c9b start_function(c_declspecs*, c_declarator*, tree_node*)
     ../../../repos/gcc/gcc/c/c-decl.c:9177
0x6f85f3 c_parser_declaration_or_fndef
     ../../../repos/gcc/gcc/c/c-parser.c:2434
0x7038af c_parser_external_declaration
     ../../../repos/gcc/gcc/c/c-parser.c:1773
0x7044c7 c_parser_translation_unit
     ../../../repos/gcc/gcc/c/c-parser.c:1646
0x7044c7 c_parse_file()
     ../../../repos/gcc/gcc/c/c-parser.c:21822
0x764897 c_common_parse_file()
     ../../../repos/gcc/gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I don't have a reduced testcase for this, but I thought I'd check if this is 
known/being worked on before filing a bug.


It's not a known issue. Please attach me the used command line and 
pre-processed source file
(using -E option).

Martin



On 6/9/20 6:01 PM, Jeff Law via Gcc-patches wrote:

On Thu, 2020-05-21 at 14:04 +0200, Martin Liška wrote:

PING^1

On 3/20/20 4:55 PM, Martin Liška wrote:

Ok, it would be possible, but if you take a look at options-save.c there's no
function that will leverage that. It's a generated code so I guess we can
live with that?

Given the size increase is under control now, I think this is fine for the 
trunk.

jeff

Re: [PATCH] gcc-changelog: support merge commits in git_update_version

[Jakub Jelinek via Gcc-patches]

On Thu, Jun 18, 2020 at 02:16:32PM +0200, Martin Liška wrote:
> The patch addresses need to generate ChangeLog for a vendor branch
> (redhat/gcc-10-branch) that can contain merge commits.
> 
> Tested on c518050989be3a224a04a8b33d73f37a16c30fbb and current active 
> branches.
> Jakub: Can you please test it?

Works for me, LGTM, thanks.

> contrib/ChangeLog:
> 
>   * gcc-changelog/git_update_version.py: Support merge commits
>   and walk only on the branch that is being merged and generate
>   missing ChangeLog entries.

Jakub

Re: [PATCH] gcc-changelog: support merge commits in git_update_version

[Martin Liška]

On 6/18/20 2:28 PM, Jakub Jelinek wrote:

On Thu, Jun 18, 2020 at 02:16:32PM +0200, Martin Liška wrote:

The patch addresses need to generate ChangeLog for a vendor branch
(redhat/gcc-10-branch) that can contain merge commits.

Tested on c518050989be3a224a04a8b33d73f37a16c30fbb and current active branches.
Jakub: Can you please test it?


Works for me, LGTM, thanks.


Good, I've just pushed the script.

Martin




contrib/ChangeLog:

* gcc-changelog/git_update_version.py: Support merge commits
and walk only on the branch that is being merged and generate
missing ChangeLog entries.


Jakub

[PATCH] gcc-changelog: checkout & pull order

[Martin Liška]

This fixes an order of commands.

Installed to master.

contrib/ChangeLog:

* gcc-changelog/git_update_version.py: First checkout and then
run git pull ---rebase.
---
 contrib/gcc-changelog/git_update_version.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/gcc-changelog/git_update_version.py 
b/contrib/gcc-changelog/git_update_version.py
index 7077880cf80..ac1b206d238 100755
--- a/contrib/gcc-changelog/git_update_version.py
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -137,8 +137,8 @@ else:
 else:
 branch = repo.create_head(name, ref).set_tracking_branch(ref)
 print('=== Working on: %s ===' % branch, flush=True)
-origin.pull(rebase=True)
 branch.checkout()
+origin.pull(rebase=True)
 print('branch pulled and checked out')
 update_current_branch()
 assert not repo.index.diff(None)
--
2.27.0

[PATCH] middle-end/95739 - fix vector condition IFN expansion

[Richard Biener]

This fixes the omission of moving the expansion result to the
target.

Bootstrapped and tested on x86_64-unknown-linux-gnu, fixes the
observed -m32 FAIL.

2020-06-18  Richard Biener  

PR middle-end/95739
* internal-fn.c (expand_vect_cond_optab_fn): Move the result
to the target if necessary.
(expand_vect_cond_mask_optab_fn): Likewise.
---
 gcc/internal-fn.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
index 644f234e087..2329e3db22f 100644
--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -2589,6 +2589,8 @@ expand_vect_cond_optab_fn (internal_fn, gcall *stmt, 
convert_optab optab)
   create_fixed_operand (&ops[4], XEXP (comparison, 0));
   create_fixed_operand (&ops[5], XEXP (comparison, 1));
   expand_insn (icode, 6, ops);
+  if (!rtx_equal_p (ops[0].value, target))
+emit_move_insn (target, ops[0].value);
 }
 
 #define expand_vec_cond_optab_fn expand_vect_cond_optab_fn
@@ -2629,6 +2631,8 @@ expand_vect_cond_mask_optab_fn (internal_fn, gcall *stmt, 
convert_optab optab)
   create_input_operand (&ops[2], rtx_op2, mode);
   create_input_operand (&ops[3], mask, mask_mode);
   expand_insn (icode, 4, ops);
+  if (!rtx_equal_p (ops[0].value, target))
+emit_move_insn (target, ops[0].value);
 }
 
 #define expand_vec_cond_mask_optab_fn expand_vect_cond_mask_optab_fn
-- 
2.26.2

[PATCH] Fix typo in tree-ssa-reassoc.c.

[Martin Liška]

I'm pushing the following fix that caused occasional ICEs:

gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr68714.c  -O3 -c
during GIMPLE pass: reassoc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr68714.c: In 
function ‘f’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr68714.c:6:5: 
internal compiler error: Segmentation fault
6 | vec f(vec x,vec y){
  | ^
0xdc7f1f crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:328
0x778b752f ???

/usr/src/debug/glibc-2.31-5.9.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xac63e0 gimple_bb
/home/marxin/Programming/gcc/gcc/gimple.h:1847
0xac63e0 gsi_for_stmt(gimple*)
/home/marxin/Programming/gcc/gcc/gimple-iterator.c:613
0xf6e96f optimize_vec_cond_expr
/home/marxin/Programming/gcc/gcc/tree-ssa-reassoc.c:3954
0xf6e96f reassociate_bb

Martin

gcc/ChangeLog:

* tree-ssa-reassoc.c (ovce_extract_ops): Replace *vcond with
vcond as we check for NULL pointer.
---
 gcc/tree-ssa-reassoc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/tree-ssa-reassoc.c b/gcc/tree-ssa-reassoc.c
index 2cc50f41cdd..2e67987f6c6 100644
--- a/gcc/tree-ssa-reassoc.c
+++ b/gcc/tree-ssa-reassoc.c
@@ -3840,7 +3840,7 @@ ovce_extract_ops (tree var, gassign **rets, bool *reti, 
tree *type,
   gassign *stmt = dyn_cast  (SSA_NAME_DEF_STMT (var));
   if (stmt == NULL)
 return ERROR_MARK;
-  if (*vcond)
+  if (vcond)
 *vcond = stmt;
 
   /* ??? If we start creating more COND_EXPR, we could perform

--
2.27.0

Re: [PATCH] middle-end/95739 - fix vector condition IFN expansion

[Martin Liška]

On 6/18/20 2:47 PM, Richard Biener wrote:

This fixes the omission of moving the expansion result to the
target.


Thank you for the fix, it's new for me that this can happen.

Martin



Bootstrapped and tested on x86_64-unknown-linux-gnu, fixes the
observed -m32 FAIL.

2020-06-18  Richard Biener  

PR middle-end/95739
* internal-fn.c (expand_vect_cond_optab_fn): Move the result
to the target if necessary.
(expand_vect_cond_mask_optab_fn): Likewise.
---
  gcc/internal-fn.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
index 644f234e087..2329e3db22f 100644
--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -2589,6 +2589,8 @@ expand_vect_cond_optab_fn (internal_fn, gcall *stmt, 
convert_optab optab)
create_fixed_operand (&ops[4], XEXP (comparison, 0));
create_fixed_operand (&ops[5], XEXP (comparison, 1));
expand_insn (icode, 6, ops);
+  if (!rtx_equal_p (ops[0].value, target))
+emit_move_insn (target, ops[0].value);
  }
  
  #define expand_vec_cond_optab_fn expand_vect_cond_optab_fn

@@ -2629,6 +2631,8 @@ expand_vect_cond_mask_optab_fn (internal_fn, gcall *stmt, 
convert_optab optab)
create_input_operand (&ops[2], rtx_op2, mode);
create_input_operand (&ops[3], mask, mask_mode);
expand_insn (icode, 4, ops);
+  if (!rtx_equal_p (ops[0].value, target))
+emit_move_insn (target, ops[0].value);
  }
  
  #define expand_vec_cond_mask_optab_fn expand_vect_cond_mask_optab_fn

[Patch]O penMP/Fortran: Reject allocatable components in map clause

[Tobias Burnus]

OpenMP 4.5 does not permit allocatable components in
list items of the map clause. (OpenMP 5 does.)
As OpenMP 5 support is not implemented, let's avoid
generating wrong code by diagnosing this (until
implemented).

OK?

Tobias

PS: I wonder whether something similar is needed
for 'private' and 'firstprivate' on target. The
allocatable-component restriction is only in the
'map' clause. However, private/firstprivate have
the same issue. (Except that it is much less likely
that a user puts a complicated variable in 'private'
or 'firstprivate'.)

PPS: Not only the OpenMP 5 changes are not yet
supported, also some mapping clause support for
OpenMP 4.5 is still missing on the Fortran side.

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
OpenMP/Fortran: Reject allocatable components in map clause

gcc/fortran/ChangeLog:

	* openmp.c (resolve_omp_clauses): Reject vars with
	allocatable components in OpenMP map clauses.

gcc/testsuite/ChangeLog:

	* gfortran.dg/gomp/map-alloc-comp-1.f90: New test.

diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 94522d16e6d..e681903c7c2 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -4636,6 +4636,13 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses *omp_clauses,
 			 && n->sym->as->type == AS_ASSUMED_SIZE)
 		  gfc_error ("Assumed size array %qs in %s clause at %L",
 			 n->sym->name, name, &n->where);
+		if (!openacc
+		&& list == OMP_LIST_MAP
+		&& n->sym->ts.type == BT_DERIVED
+		&& n->sym->ts.u.derived->attr.alloc_comp)
+		  gfc_error ("List item %qs with allocatable components is not "
+			 "permitted in map clause at %L", n->sym->name,
+			 &n->where);
 		if (list == OMP_LIST_MAP && !openacc)
 		  switch (code->op)
 		{
diff --git a/gcc/testsuite/gfortran.dg/gomp/map-alloc-comp-1.f90 b/gcc/testsuite/gfortran.dg/gomp/map-alloc-comp-1.f90
new file mode 100644
index 000..0c4429677bd
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/gomp/map-alloc-comp-1.f90
@@ -0,0 +1,14 @@
+!
+! ALLOCATABLE COMPONENTS:
+! - OpenMP 5: Permitted (and automatically recursively mapped)
+!   -> Not yet supported.
+! - OpenMP 4.5: Not permitted.
+!
+implicit none (type, external)
+type sct
+  integer, allocatable :: c
+end type
+type(sct) var
+
+!$omp target enter data map(to:var)  ! { dg-error "allocatable components is not permitted in map clause" }
+end

Re: [Patch]O penMP/Fortran: Reject allocatable components in map clause

[Jakub Jelinek via Gcc-patches]

On Thu, Jun 18, 2020 at 03:08:53PM +0200, Tobias Burnus wrote:
> OpenMP 4.5 does not permit allocatable components in
> list items of the map clause. (OpenMP 5 does.)
> As OpenMP 5 support is not implemented, let's avoid
> generating wrong code by diagnosing this (until
> implemented).
> 
> OK?

Ok.

> PS: I wonder whether something similar is needed
> for 'private' and 'firstprivate' on target. The
> allocatable-component restriction is only in the
> 'map' clause. However, private/firstprivate have
> the same issue. (Except that it is much less likely
> that a user puts a complicated variable in 'private'
> or 'firstprivate'.)

Probably.

Jakub

[PATCH][GCC] arm: Fix the failing mve scalar shift execution tests.

[Srinath Parvathaneni]

Hello,

In GCC testsuite the MVE scalar shift execution tests 
(mve_scalar_shifts[1-4].c) are failings
because of executing them on target hardware which doesn't support MVE 
instructions. This patch
restricts those tests to execute only on target hardware that support MVE 
instructions.

Regression tested on arm-none-eabi and found no regressions.

Ok for master? Ok for GCC-10 branch?

Thanks,
Srinath.

2020-06-18  Srinath Parvathaneni  

gcc/
* doc/sourcebuild.texi (arm_v8_1m_mve_fp_ok): Add item.
(arm_mve_hw): Likewise.

gcc/testsuite/
* gcc.target/arm/mve/mve.exp (check_effective_target_arm_mve_hw): Check
availability of hardware supporting MVE instructions.
* lib/target-supports.exp (check_effective_target_arm_mve_hw): Define.


### Attachment also inlined for ease of reply###


diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 
e5554c4666eb217844598352ced5a9597652f07c..a12af822443ad41afba816ed640d80d182859239
 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1925,6 +1925,15 @@ ARM target supports options to generate instructions 
from ARMv8.1-M with
 the M-Profile Vector Extension (MVE). Some multilibs may be incompatible
 with these options.
 
+@item arm_v8_1m_mve_fp_ok
+ARM target supports options to generate instructions from ARMv8.1-M with
+the Half-precision floating-point instructions (HP), Floating-point Extension
+(FP) along with M-Profile Vector Extension (MVE). Some multilibs may be
+incompatible with these options.
+
+@item arm_mve_hw
+Test system supports executing MVE instructions.
+
 @item arm_v8m_main_cde
 ARM target supports options to generate instructions from ARMv8-M with
 the Custom Datapath Extension (CDE). Some multilibs may be incompatible
diff --git a/gcc/testsuite/gcc.target/arm/mve/mve.exp 
b/gcc/testsuite/gcc.target/arm/mve/mve.exp
index 
e84cb068940e2cb4ed7bbdd51b14d52cec3e323f..aaa3b78b2a9400070d0ca33cb0e98bd0fad7d408
 100644
--- a/gcc/testsuite/gcc.target/arm/mve/mve.exp
+++ b/gcc/testsuite/gcc.target/arm/mve/mve.exp
@@ -24,6 +24,11 @@ if ![istarget arm*-*-*] then {
 # Load support procs.
 load_lib gcc-dg.exp
 
+# Exit immediately if the target does not support MVE instructions.
+if ![check_effective_target_arm_mve_hw] then {
+return
+}
+
 # If a testcase doesn't have special options, use these.
 global DEFAULT_CFLAGS
 if ![info exists DEFAULT_CFLAGS] then {
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 
862a0735b49582f7f35a9a4009f5752cf8f7e3ba..ab0ee32fc911622b4716c272df4e656698b81a70
 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -4671,6 +4671,24 @@ proc check_effective_target_arm_cmse_ok {} {
 } "-mcmse"];
 }
 
+# Return 1 if the target supports executing MVE instructions, 0
+# otherwise.
+
+proc check_effective_target_arm_mve_hw {} {
+return [check_runtime arm_mve_hw_available {
+   int
+   main (void)
+   {
+ long long a = 16;
+ int b = 3;
+ asm ("sqrshrl %Q1, %R1, #64, %2"
+  : "=l" (a)
+  : "0" (a), "r" (b));
+ return (a != 2);
+   }
+} ""]
+}
+
 # Return 1 if this is an ARM target where ARMv8-M Security Extensions with
 # clearing instructions (clrm, vscclrm, vstr/vldr with FPCXT) is available.
 

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 
e5554c4666eb217844598352ced5a9597652f07c..a12af822443ad41afba816ed640d80d182859239
 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1925,6 +1925,15 @@ ARM target supports options to generate instructions 
from ARMv8.1-M with
 the M-Profile Vector Extension (MVE). Some multilibs may be incompatible
 with these options.
 
+@item arm_v8_1m_mve_fp_ok
+ARM target supports options to generate instructions from ARMv8.1-M with
+the Half-precision floating-point instructions (HP), Floating-point Extension
+(FP) along with M-Profile Vector Extension (MVE). Some multilibs may be
+incompatible with these options.
+
+@item arm_mve_hw
+Test system supports executing MVE instructions.
+
 @item arm_v8m_main_cde
 ARM target supports options to generate instructions from ARMv8-M with
 the Custom Datapath Extension (CDE). Some multilibs may be incompatible
diff --git a/gcc/testsuite/gcc.target/arm/mve/mve.exp 
b/gcc/testsuite/gcc.target/arm/mve/mve.exp
index 
e84cb068940e2cb4ed7bbdd51b14d52cec3e323f..aaa3b78b2a9400070d0ca33cb0e98bd0fad7d408
 100644
--- a/gcc/testsuite/gcc.target/arm/mve/mve.exp
+++ b/gcc/testsuite/gcc.target/arm/mve/mve.exp
@@ -24,6 +24,11 @@ if ![istarget arm*-*-*] then {
 # Load support procs.
 load_lib gcc-dg.exp
 
+# Exit immediately if the target does not support MVE instructions.
+if ![check_effective_target_arm_mve_hw] then {
+return
+}
+
 # If a testcase doesn't have special options, use these.
 global DEFAULT_CFLAGS
 if ![info exists DEFAULT_CFLAGS] then {
diff

Re: [PATCH][GCC] arm: Fix the failing mve scalar shift execution tests.

[Christophe Lyon via Gcc-patches]

Hi,


On Thu, 18 Jun 2020 at 15:30, Srinath Parvathaneni
 wrote:
>
> Hello,
>
> In GCC testsuite the MVE scalar shift execution tests 
> (mve_scalar_shifts[1-4].c) are failings
> because of executing them on target hardware which doesn't support MVE 
> instructions. This patch
> restricts those tests to execute only on target hardware that support MVE 
> instructions.
>
> Regression tested on arm-none-eabi and found no regressions.
>
> Ok for master? Ok for GCC-10 branch?
>
> Thanks,
> Srinath.
>
> 2020-06-18  Srinath Parvathaneni  
>
> gcc/
> * doc/sourcebuild.texi (arm_v8_1m_mve_fp_ok): Add item.
> (arm_mve_hw): Likewise.
>
> gcc/testsuite/
> * gcc.target/arm/mve/mve.exp (check_effective_target_arm_mve_hw): 
> Check
> availability of hardware supporting MVE instructions.
> * lib/target-supports.exp (check_effective_target_arm_mve_hw): Define.
>
>
> ### Attachment also inlined for ease of reply
> ###
>
>
> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> index 
> e5554c4666eb217844598352ced5a9597652f07c..a12af822443ad41afba816ed640d80d182859239
>  100644
> --- a/gcc/doc/sourcebuild.texi
> +++ b/gcc/doc/sourcebuild.texi
> @@ -1925,6 +1925,15 @@ ARM target supports options to generate instructions 
> from ARMv8.1-M with
>  the M-Profile Vector Extension (MVE). Some multilibs may be incompatible
>  with these options.
>
> +@item arm_v8_1m_mve_fp_ok
> +ARM target supports options to generate instructions from ARMv8.1-M with
> +the Half-precision floating-point instructions (HP), Floating-point Extension
> +(FP) along with M-Profile Vector Extension (MVE). Some multilibs may be
> +incompatible with these options.
> +
> +@item arm_mve_hw
> +Test system supports executing MVE instructions.
> +
>  @item arm_v8m_main_cde
>  ARM target supports options to generate instructions from ARMv8-M with
>  the Custom Datapath Extension (CDE). Some multilibs may be incompatible
> diff --git a/gcc/testsuite/gcc.target/arm/mve/mve.exp 
> b/gcc/testsuite/gcc.target/arm/mve/mve.exp
> index 
> e84cb068940e2cb4ed7bbdd51b14d52cec3e323f..aaa3b78b2a9400070d0ca33cb0e98bd0fad7d408
>  100644
> --- a/gcc/testsuite/gcc.target/arm/mve/mve.exp
> +++ b/gcc/testsuite/gcc.target/arm/mve/mve.exp
> @@ -24,6 +24,11 @@ if ![istarget arm*-*-*] then {
>  # Load support procs.
>  load_lib gcc-dg.exp
>
> +# Exit immediately if the target does not support MVE instructions.
> +if ![check_effective_target_arm_mve_hw] then {
> +return
> +}

So you are going to skip all tests, not only the ones with "dg-do run", right?

Don't you want to add this effective target test to the offending tests only?

Thanks,

Christophe

> +
>  # If a testcase doesn't have special options, use these.
>  global DEFAULT_CFLAGS
>  if ![info exists DEFAULT_CFLAGS] then {
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index 
> 862a0735b49582f7f35a9a4009f5752cf8f7e3ba..ab0ee32fc911622b4716c272df4e656698b81a70
>  100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -4671,6 +4671,24 @@ proc check_effective_target_arm_cmse_ok {} {
>  } "-mcmse"];
>  }
>
> +# Return 1 if the target supports executing MVE instructions, 0
> +# otherwise.
> +
> +proc check_effective_target_arm_mve_hw {} {
> +return [check_runtime arm_mve_hw_available {
> +   int
> +   main (void)
> +   {
> + long long a = 16;
> + int b = 3;
> + asm ("sqrshrl %Q1, %R1, #64, %2"
> +  : "=l" (a)
> +  : "0" (a), "r" (b));
> + return (a != 2);
> +   }
> +} ""]
> +}
> +
>  # Return 1 if this is an ARM target where ARMv8-M Security Extensions with
>  # clearing instructions (clrm, vscclrm, vstr/vldr with FPCXT) is available.
>
>

[committed][OG10] amdgcn: Switch to HSACO v3 binary format

[Andrew Stubbs]

This patch is now backported to the devel/omp/gcc-10 branch.

Andrew

On 17/06/2020 10:13, Andrew Stubbs wrote:
This upgrades the compiler to emit HSA Code Object v3 binaries.  This 
means changing the assembler directives, and linker command line options.


The gcn-run and libgomp loaders need corresponding alterations.  The
relocations no longer need to be fixed up manually, and the kernel 
symbol names have changed slightly.


This move makes the binaries compatible with the new rocgdb from ROCm 3.5.

Additional changes are required to
  * Replace the HSA runtime APIs calls that are now deprecated.
  * Provide proper DWARF register mappings.
  * Implement CFI.

However, it is now possible to set breakpoints, view running threads, 
single-step both source and instructions, view register contents, and 
catch memory faults.  This is a huge improvement over our previous debug 
technique of change-something-and-see-what-happens. :-D


Andrew


amdgcn: Switch to HSACO v3 binary format

This upgrades the compiler to emit HSA Code Object v3 binaries.  This means
changing the assembler directives, and linker command line options.

The gcn-run and libgomp loaders need corresponding alterations.  The
relocations no longer need to be fixed up manually, and the kernel symbol
names have changed slightly.

This move makes the binaries compatible with the new rocgdb from ROCm 3.5.

2020-06-17  Andrew Stubbs  

	gcc/
	* config/gcn/gcn-hsa.h (TEXT_SECTION_ASM_OP): Use ".text".
	(BSS_SECTION_ASM_OP): Use ".bss".
	(ASM_SPEC): Remove "-mattr=-code-object-v3".
	(LINK_SPEC): Add "--export-dynamic".
	* config/gcn/gcn-opts.h (processor_type): Replace PROCESSOR_VEGA with
	PROCESSOR_VEGA10 and PROCESSOR_VEGA20.
	* config/gcn/gcn-run.c (HSA_RUNTIME_LIB): Use ".so.1" variant.
	(load_image): Remove obsolete relocation handling.
	Add ".kd" suffix to the symbol names.
	* config/gcn/gcn.c (MAX_NORMAL_SGPR_COUNT): Set to 62.
	(gcn_option_override): Update gcn_isa test.
	(gcn_kernel_arg_types): Update all the assembler directives.
	Remove the obsolete options.
	(gcn_conditional_register_usage): Update MAX_NORMAL_SGPR_COUNT usage.
	(gcn_omp_device_kind_arch_isa): Handle PROCESSOR_VEGA10 and
	PROCESSOR_VEGA20.
	(output_file_start): Rework assembler file header.
	(gcn_hsa_declare_function_name): Rework kernel metadata.
	* config/gcn/gcn.h (GCN_KERNEL_ARG_TYPES): Set to 16.
	* config/gcn/gcn.opt (PROCESSOR_VEGA): Remove enum.
	(PROCESSOR_VEGA10): New enum value.
	(PROCESSOR_VEGA20): New enum value.

	libgomp/
	* plugin/plugin-gcn.c (init_environment_variables): Use ".so.1"
	variant for HSA_RUNTIME_LIB name.
	(find_executable_symbol_1): Delete.
	(find_executable_symbol): Delete.
	(init_kernel_properties): Add ".kd" suffix to symbol names.
	(find_load_offset): Delete.
	(create_and_finalize_hsa_program): Remove relocation handling.

diff --git a/gcc/config/gcn/gcn-hsa.h b/gcc/config/gcn/gcn-hsa.h
index 2eaf4149f4c..4fd1365416f 100644
--- a/gcc/config/gcn/gcn-hsa.h
+++ b/gcc/config/gcn/gcn-hsa.h
@@ -18,8 +18,8 @@
  #error elf.h included before elfos.h
 #endif
 
-#define TEXT_SECTION_ASM_OP "\t.section\t.text"
-#define BSS_SECTION_ASM_OP  "\t.section\t.bss"
+#define TEXT_SECTION_ASM_OP "\t.text"
+#define BSS_SECTION_ASM_OP  "\t.bss"
 #define GLOBAL_ASM_OP   "\t.globl\t"
 #define DATA_SECTION_ASM_OP "\t.data\t"
 #define SET_ASM_OP  "\t.set\t"
@@ -76,10 +76,10 @@ extern unsigned int gcn_local_sym_hash (const char *name);
 #define GOMP_SELF_SPECS ""
 
 /* Use LLVM assembler and linker options.  */
-#define ASM_SPEC  "-triple=amdgcn--amdhsa -mattr=-code-object-v3 "  \
+#define ASM_SPEC  "-triple=amdgcn--amdhsa "  \
 		  "%:last_arg(%{march=*:-mcpu=%*}) " \
 		  "-filetype=obj"
-#define LINK_SPEC "--pie"
+#define LINK_SPEC "--pie --export-dynamic"
 #define LIB_SPEC  "-lc"
 
 /* Provides a _start symbol to keep the linker happy.  */
diff --git a/gcc/config/gcn/gcn-opts.h b/gcc/config/gcn/gcn-opts.h
index 385d2be8675..8eefb7a348a 100644
--- a/gcc/config/gcn/gcn-opts.h
+++ b/gcc/config/gcn/gcn-opts.h
@@ -20,8 +20,9 @@
 /* Which processor to generate code or schedule for.  */
 enum processor_type
 {
-  PROCESSOR_FIJI,
-  PROCESSOR_VEGA
+  PROCESSOR_FIJI,// gfx803
+  PROCESSOR_VEGA10,  // gfx900
+  PROCESSOR_VEGA20   // gfx906
 };
 
 /* Set in gcn_option_override.  */
diff --git a/gcc/config/gcn/gcn-run.c b/gcc/config/gcn/gcn-run.c
index 1e952e92b76..8961ea17d37 100644
--- a/gcc/config/gcn/gcn-run.c
+++ b/gcc/config/gcn/gcn-run.c
@@ -55,7 +55,7 @@
 #include "hsa.h"
 
 #ifndef HSA_RUNTIME_LIB
-#define HSA_RUNTIME_LIB "libhsa-runtime64.so"
+#define HSA_RUNTIME_LIB "libhsa-runtime64.so.1"
 #endif
 
 #ifndef VERSION_STRING
@@ -429,20 +429,6 @@ load_image (const char *filename)
 	  &executable),
 	"Initialize GCN executable");
 
-  /* Hide relocations from the HSA runtime loader.
- Keep a copy of the unmodified section headers to use later.  */
-  Elf64_Shdr *image_sections =
-(Elf64_Shdr *) ((char *) image + image->e_shoff);
-  Elf

Re: [PATCH] rs6000: fix creation of VEC_COND_EXPR

[Segher Boessenkool]

On Thu, Jun 18, 2020 at 10:21:00AM +0200, Martin Liška wrote:
> All right, let's do it better.

Thanks!

(Btw, the MIME sub-type of "x-patch" makes this unviewable on many
browsers, in the gcc-patches@ archive (and unusable in many mail
clients of course).  Anything "x-*" should never be used on public
mailing lists, or anywhere else where you didn't get all people
receiving this to agree what this type means).

> >From 9ba94cec649ef84399531f43d5c7171328a3f704 Mon Sep 17 00:00:00 2001
> From: Martin Liska 
> Date: Thu, 18 Jun 2020 09:25:32 +0200
> Subject: [PATCH] rs6000: fix creation of VEC_COND_EXPR

Capital F on Fix.  Easy check is to run "git log --oneline" and see
if your commit seems out of place ;-)

>   * config/rs6000/rs6000-call.c (fold_build_vec_cmp):
>   Since 502d63b6d6141597bb18fd23c87736a1b384cf8f, first argument
>   of a VEC_COND_EXPR cannot be tcc_comparison and so that
>   a SSA_NAME needs to be created before we use it for the first
>   argument of the VEC_COND_EXPR.

This isn't documented (in generic.texi).  Please fix that?  (In a
separate patch of course.)

> @@ -10714,16 +10714,19 @@ rs6000_builtin_valid_without_lhs (enum 
> rs6000_builtins fn_code)
> operation.  This sets up true/false vectors, and uses the
> VEC_COND_EXPR operation.
> CODE indicates which comparison is to be made. (EQ, GT, ...).
> -   TYPE indicates the type of the result.  */
> +   TYPE indicates the type of the result.  

(trailing spaces)

> +   GSI points to a GIMPLE statement that we are currently folding.  */

That isn't a useful thing to say.  Write that this function inserts new
code before there?

Okay for trunk with those changes.  Thanks!


Segher

Re: [committed] Fix use of inaccessible member in pr85503.C [PR95716]

[Christophe Lyon via Gcc-patches]

Hi,

On Wed, 17 Jun 2020 at 15:16, Patrick Palka via Gcc-patches
 wrote:
>
> The recent PR41437 fix exposed a latent use of an inaccessible member in
> the below testcase.
>
> Committed as obvious after verifying that the testcase no longer fails to
> compile due to the reported access error.
>

I've noticed a similar problem in g++.target/aarch64/pr94052.C.
The small patch below fixes it, OK for trunk?

diff --git a/gcc/testsuite/g++.target/aarch64/pr94052.C
b/gcc/testsuite/g++.target/aarch64/pr94052.C
index d36c9bd..b3bc3e2 100644
--- a/gcc/testsuite/g++.target/aarch64/pr94052.C
+++ b/gcc/testsuite/g++.target/aarch64/pr94052.C
@@ -26,7 +26,7 @@ public:
   d x();
   d y();
 };
-class z : ad {};
+class z : public ad {};
 struct ae {
   p af;
 };


Thanks,

Christophe

> gcc/testsuite/ChangeLog:
>
> PR testsuite/95716
> * g++.dg/ext/pr85503.C: Give ai::cv public access.
> ---
>  gcc/testsuite/g++.dg/ext/pr85503.C | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/gcc/testsuite/g++.dg/ext/pr85503.C 
> b/gcc/testsuite/g++.dg/ext/pr85503.C
> index 7e17943e353..832952a8774 100644
> --- a/gcc/testsuite/g++.dg/ext/pr85503.C
> +++ b/gcc/testsuite/g++.dg/ext/pr85503.C
> @@ -138,6 +138,7 @@ struct ad< ai< cr, ag, ah, cu, ct, cw > > {
>  };
>  template < typename, int ag, int ah, int, int, int >
>  class ai : public af< ai< double, ag, ah > > {
> +public:
>typedef ai cv;
>  };
>  template < typename bk, typename ce, typename cf >
> --
> 2.27.0.83.g0313f36c6e
>

RE: [PATCH][GCC] arm: Fix the failing mve scalar shift execution tests.

[Srinath Parvathaneni]

Hi,

> -Original Message-
> From: Christophe Lyon 
> Sent: 18 June 2020 14:38
> To: Srinath Parvathaneni 
> Cc: gcc Patches 
> Subject: Re: [PATCH][GCC] arm: Fix the failing mve scalar shift execution 
> tests.
> 
> Hi,
> 
> 
> On Thu, 18 Jun 2020 at 15:30, Srinath Parvathaneni
>  wrote:
> >
> > Hello,
> >
> > In GCC testsuite the MVE scalar shift execution tests
> > (mve_scalar_shifts[1-4].c) are failings because of executing them on
> > target hardware which doesn't support MVE instructions. This patch
> restricts those tests to execute only on target hardware that support MVE
> instructions.
> >
> > Regression tested on arm-none-eabi and found no regressions.
> >
> > Ok for master? Ok for GCC-10 branch?
> >
> > Thanks,
> > Srinath.
> >
> > 2020-06-18  Srinath Parvathaneni  
> >
> > gcc/
> > * doc/sourcebuild.texi (arm_v8_1m_mve_fp_ok): Add item.
> > (arm_mve_hw): Likewise.
> >
> > gcc/testsuite/
> > * gcc.target/arm/mve/mve.exp (check_effective_target_arm_mve_hw):
> Check
> > availability of hardware supporting MVE instructions.
> > * lib/target-supports.exp (check_effective_target_arm_mve_hw):
> Define.
> >
> >
> > ### Attachment also inlined for ease of reply
> ###
> >
> >
> > diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi index
> >
> e5554c4666eb217844598352ced5a9597652f07c..a12af822443ad41afba816ed
> 640d
> > 80d182859239 100644
> > --- a/gcc/doc/sourcebuild.texi
> > +++ b/gcc/doc/sourcebuild.texi
> > @@ -1925,6 +1925,15 @@ ARM target supports options to generate
> > instructions from ARMv8.1-M with  the M-Profile Vector Extension
> > (MVE). Some multilibs may be incompatible  with these options.
> >
> > +@item arm_v8_1m_mve_fp_ok
> > +ARM target supports options to generate instructions from ARMv8.1-M
> > +with the Half-precision floating-point instructions (HP),
> > +Floating-point Extension
> > +(FP) along with M-Profile Vector Extension (MVE). Some multilibs may
> > +be incompatible with these options.
> > +
> > +@item arm_mve_hw
> > +Test system supports executing MVE instructions.
> > +
> >  @item arm_v8m_main_cde
> >  ARM target supports options to generate instructions from ARMv8-M
> > with  the Custom Datapath Extension (CDE). Some multilibs may be
> > incompatible diff --git a/gcc/testsuite/gcc.target/arm/mve/mve.exp
> > b/gcc/testsuite/gcc.target/arm/mve/mve.exp
> > index
> >
> e84cb068940e2cb4ed7bbdd51b14d52cec3e323f..aaa3b78b2a9400070d0ca33
> cb0e9
> > 8bd0fad7d408 100644
> > --- a/gcc/testsuite/gcc.target/arm/mve/mve.exp
> > +++ b/gcc/testsuite/gcc.target/arm/mve/mve.exp
> > @@ -24,6 +24,11 @@ if ![istarget arm*-*-*] then {  # Load support
> > procs.
> >  load_lib gcc-dg.exp
> >
> > +# Exit immediately if the target does not support MVE instructions.
> > +if ![check_effective_target_arm_mve_hw] then {
> > +return
> > +}
> 
> So you are going to skip all tests, not only the ones with "dg-do run", right?

No, that was a mistake, I wanted to skip only the tests with "dg-do run".
> Don't you want to add this effective target test to the offending tests only?

Done it now and attached updated cover letter and patch in this e-mail.
Thanks for pointing this out.
> 
> Thanks,
> 
> Christophe
> 
> > +
> >  # If a testcase doesn't have special options, use these.
> >  global DEFAULT_CFLAGS
> >  if ![info exists DEFAULT_CFLAGS] then { diff --git
> > a/gcc/testsuite/lib/target-supports.exp
> > b/gcc/testsuite/lib/target-supports.exp
> > index
> >
> 862a0735b49582f7f35a9a4009f5752cf8f7e3ba..ab0ee32fc911622b4716c272d
> f4e
> > 656698b81a70 100644
> > --- a/gcc/testsuite/lib/target-supports.exp
> > +++ b/gcc/testsuite/lib/target-supports.exp
> > @@ -4671,6 +4671,24 @@ proc check_effective_target_arm_cmse_ok {} {
> >  } "-mcmse"];
> >  }
> >
> > +# Return 1 if the target supports executing MVE instructions, 0 #
> > +otherwise.
> > +
> > +proc check_effective_target_arm_mve_hw {} {
> > +return [check_runtime arm_mve_hw_available {
> > +   int
> > +   main (void)
> > +   {
> > + long long a = 16;
> > + int b = 3;
> > + asm ("sqrshrl %Q1, %R1, #64, %2"
> > +  : "=l" (a)
> > +  : "0" (a), "r" (b));
> > + return (a != 2);
> > +   }
> > +} ""]
> > +}
> > +
> >  # Return 1 if this is an ARM target where ARMv8-M Security Extensions
> > with  # clearing instructions (clrm, vscclrm, vstr/vldr with FPCXT) is 
> > available.
> >
> >


diff
Description: diff
Hello,

In GCC testsuite the MVE scalar shift execution tests 
(mve_scalar_shifts[1-4].c) are failings
because of executing them on target hardware which doesn't support MVE 
instructions. This patch
restricts those tests to execute only on target hardware that support MVE 
instructions.

Regression tested on arm-none-eabi and found no regressions.

Ok for master? Ok for GCC-10 branch?

Thanks,
Srinath.

2020-06-18  Srinath Parvathaneni  

gcc/
* doc/sourcebuild.texi (arm_v

Re: [PATCH] vectorizer: add _bb_vec_info::const_iterator

[Martin Liška]

On 6/18/20 11:43 AM, Jonathan Wakely wrote:

On 18/06/20 00:55 +0100, Jonathan Wakely wrote:

Does your reverse iterator work correctly? It looks to me like it will
fail to visit the region_begin statement, because this loop will
terminate when the reverse iterator reaches the end() value, and will
not actually process that gsi:

-  gimple_stmt_iterator si = bb_vinfo->region_end;
-  gimple *stmt;
-  do
+  for (gimple *stmt : bb_vinfo->reverse_region_stmts ())

Adding const_iterator::operator--() and using
std::reverse_iterator would fix that problem. The
std::reverse_iterator utility already solves the problem of getting
the begin and end of a reversed range correct.

You might need to add a couple of things to your const_iterator to
make it more like a conventional STL iterator in order to use
std::reverse_iterator, but IMHO it would be worth it. I can look at
that in the morning.


Using std::reverse_iterator won't work, because this iterator is an
"input iterator" i.e. single pass. Incrementing it modifies the
underlying data structure (the gimple_statement_iterator) so it can't
meet the requirements for a bidirectional iterator.

But fixing the reverse iterator to visit the last statement isn't
hard.


Nice catch from Jonathan!

I'm leaving the idea of std::reverse_iterator and make_iterator_range and I'm 
testing
a patch version that I'll install (if there are no objections).



N.B. the fact that the bug in reverse iteration wasn't noticed
suggests missing tests :-)


Yes, so far we don't have any selftests for _bb_vec_info and friends.

Martin






>From 15ac28bcb05bfbdebb958bef0b43e8e60d3cc2cd Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Thu, 11 Jun 2020 13:25:40 +0200
Subject: [PATCH] vectorizer: add _bb_vec_info::region_stmts and
 reverse_region_stmts

gcc/ChangeLog:

	* coretypes.h (struct iterator_range): New type.
	* tree-vect-patterns.c (vect_determine_precisions): Use
	range-based iterator.
	(vect_pattern_recog): Likewise.
	* tree-vect-slp.c (_bb_vec_info):  Likewise.
	(_bb_vec_info::~_bb_vec_info): Likewise.
	(vect_slp_check_for_constructors): Likewise.
	* tree-vectorizer.h:Add new iterators
	and functions that use it.
---
 gcc/coretypes.h  | 17 +
 gcc/tree-vect-patterns.c | 14 +--
 gcc/tree-vect-slp.c  | 24 
 gcc/tree-vectorizer.h| 82 
 4 files changed, 109 insertions(+), 28 deletions(-)

diff --git a/gcc/coretypes.h b/gcc/coretypes.h
index 01ec2e23ce2..720f9f9c63f 100644
--- a/gcc/coretypes.h
+++ b/gcc/coretypes.h
@@ -363,6 +363,23 @@ struct kv_pair
 template
 using first_type = T1;
 
+/* Iterator pair used for a collection iteration with range-based loops.  */
+
+template
+struct iterator_range
+{
+public:
+  iterator_range (const T &begin, const T &end)
+: m_begin (begin), m_end (end) {}
+
+  T begin () const { return m_begin; }
+  T end () const { return m_end; }
+
+private:
+  T m_begin;
+  T m_end;
+};
+
 #else
 
 struct _dont_use_rtx_here_;
diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
index 636ad59c001..03d50ec5c90 100644
--- a/gcc/tree-vect-patterns.c
+++ b/gcc/tree-vect-patterns.c
@@ -5120,20 +5120,12 @@ vect_determine_precisions (vec_info *vinfo)
   else
 {
   bb_vec_info bb_vinfo = as_a  (vinfo);
-  gimple_stmt_iterator si = bb_vinfo->region_end;
-  gimple *stmt;
-  do
+  for (gimple *stmt : bb_vinfo->reverse_region_stmts ())
 	{
-	  if (!gsi_stmt (si))
-	si = gsi_last_bb (bb_vinfo->bb);
-	  else
-	gsi_prev (&si);
-	  stmt = gsi_stmt (si);
 	  stmt_vec_info stmt_info = vinfo->lookup_stmt (stmt);
 	  if (stmt_info && STMT_VINFO_VECTORIZABLE (stmt_info))
 	vect_determine_stmt_precisions (vinfo, stmt_info);
 	}
-  while (stmt != gsi_stmt (bb_vinfo->region_begin));
 }
 }
 
@@ -5492,10 +5484,8 @@ vect_pattern_recog (vec_info *vinfo)
   else
 {
   bb_vec_info bb_vinfo = as_a  (vinfo);
-  for (si = bb_vinfo->region_begin;
-	   gsi_stmt (si) != gsi_stmt (bb_vinfo->region_end); gsi_next (&si))
+  for (gimple *stmt : bb_vinfo->region_stmts ())
 	{
-	  gimple *stmt = gsi_stmt (si);
 	  stmt_vec_info stmt_info = bb_vinfo->lookup_stmt (stmt);
 	  if (!stmt_info || !STMT_VINFO_VECTORIZABLE (stmt_info))
 	continue;
diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index fe946738a97..09cdc353a43 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -2561,12 +2561,8 @@ _bb_vec_info::_bb_vec_info (gimple_stmt_iterator region_begin_in,
 region_begin (region_begin_in),
 region_end (region_end_in)
 {
-  gimple_stmt_iterator gsi;
-
-  for (gsi = region_begin; gsi_stmt (gsi) != gsi_stmt (region_end);
-   gsi_next (&gsi))
+  for (gimple *stmt : this->region_stmts ())
 {
-  gimple *stmt = gsi_stmt (gsi);
   gimple_set_uid (stmt, 0);
   if (is_gimple_debug (stmt))
 	continue;
@@ -2582,10 +2578,9 @@ _bb_vec_info::_bb_vec_info (gimple_stmt_iterator region_begin_in,
 
 _bb_vec_i

Re: [PATCH] vectorizer: add _bb_vec_info::const_iterator

[Jonathan Wakely via Gcc-patches]

On 18/06/20 16:25 +0200, Martin Liška wrote:

On 6/18/20 11:43 AM, Jonathan Wakely wrote:

On 18/06/20 00:55 +0100, Jonathan Wakely wrote:

Does your reverse iterator work correctly? It looks to me like it will
fail to visit the region_begin statement, because this loop will
terminate when the reverse iterator reaches the end() value, and will
not actually process that gsi:

-  gimple_stmt_iterator si = bb_vinfo->region_end;
-  gimple *stmt;
-  do
+  for (gimple *stmt : bb_vinfo->reverse_region_stmts ())

Adding const_iterator::operator--() and using
std::reverse_iterator would fix that problem. The
std::reverse_iterator utility already solves the problem of getting
the begin and end of a reversed range correct.

You might need to add a couple of things to your const_iterator to
make it more like a conventional STL iterator in order to use
std::reverse_iterator, but IMHO it would be worth it. I can look at
that in the morning.


Using std::reverse_iterator won't work, because this iterator is an
"input iterator" i.e. single pass. Incrementing it modifies the
underlying data structure (the gimple_statement_iterator) so it can't
meet the requirements for a bidirectional iterator.

But fixing the reverse iterator to visit the last statement isn't
hard.


Nice catch from Jonathan!

I'm leaving the idea of std::reverse_iterator and make_iterator_range and I'm 
testing
a patch version that I'll install (if there are no objections).


Yes, the std::reverse_iterator idea is a dead end, and I agree that
make_iterator_range doesn't seem like an improvement.

Re: [committed] Fix use of inaccessible member in pr85503.C [PR95716]

[Patrick Palka via Gcc-patches]

On Thu, 18 Jun 2020, Christophe Lyon wrote:

> Hi,
> 
> On Wed, 17 Jun 2020 at 15:16, Patrick Palka via Gcc-patches
>  wrote:
> >
> > The recent PR41437 fix exposed a latent use of an inaccessible member in
> > the below testcase.
> >
> > Committed as obvious after verifying that the testcase no longer fails to
> > compile due to the reported access error.
> >
> 
> I've noticed a similar problem in g++.target/aarch64/pr94052.C.
> The small patch below fixes it, OK for trunk?

The patch looks good to me, thanks!  (I can't formally approve it, but
I think the patch is simple/obvious enough to be able to commit without
formal approval.)

> 
> diff --git a/gcc/testsuite/g++.target/aarch64/pr94052.C
> b/gcc/testsuite/g++.target/aarch64/pr94052.C
> index d36c9bd..b3bc3e2 100644
> --- a/gcc/testsuite/g++.target/aarch64/pr94052.C
> +++ b/gcc/testsuite/g++.target/aarch64/pr94052.C
> @@ -26,7 +26,7 @@ public:
>d x();
>d y();
>  };
> -class z : ad {};
> +class z : public ad {};
>  struct ae {
>p af;
>  };
> 
> 
> Thanks,
> 
> Christophe
> 
> > gcc/testsuite/ChangeLog:
> >
> > PR testsuite/95716
> > * g++.dg/ext/pr85503.C: Give ai::cv public access.
> > ---
> >  gcc/testsuite/g++.dg/ext/pr85503.C | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/gcc/testsuite/g++.dg/ext/pr85503.C 
> > b/gcc/testsuite/g++.dg/ext/pr85503.C
> > index 7e17943e353..832952a8774 100644
> > --- a/gcc/testsuite/g++.dg/ext/pr85503.C
> > +++ b/gcc/testsuite/g++.dg/ext/pr85503.C
> > @@ -138,6 +138,7 @@ struct ad< ai< cr, ag, ah, cu, ct, cw > > {
> >  };
> >  template < typename, int ag, int ah, int, int, int >
> >  class ai : public af< ai< double, ag, ah > > {
> > +public:
> >typedef ai cv;
> >  };
> >  template < typename bk, typename ce, typename cf >
> > --
> > 2.27.0.83.g0313f36c6e
> >
> 
> 

[PATCH] avoid warning for memset writing over multiple members (PR 95667)

[Martin Sebor via Gcc-patches]

In the recent fix to avoid false positives due to compute_objsize
(PR 95353)​ where I removed the call to compute_builtin_object_size
when computing object sizes for calls to string functions like
strcpy, I kept it out of a misplaced abundance of caution when
doing the same for the more permissive memcpy and memset.  It
turned out to be a mistake because it triggered another false
positive warning in a case when the call wasn't made due to
the new structure.  Rather than continuing to rely on the function
(and continue to try to cope with its limitations) the attached
patch replaces the call with its own computation.  That keeps all
the logic in one place and avoids the limitations.

Like the patch for PR 95353, I tested this fix by building Glibc,
Binutils/GDB, and the kernel on x86_64-linux with no new warnings
(of course, that didn't prevent the false positive from turning
up in a Glibc build on nios2-linux-gnu).

Martin

PS This isn't meant to resolve the underlying problem with the PRE
transformation substituting one member for another with the same
offset.

PPS I have WIP patches for GCC 11 tweaking this area in a number
of ways, so this is just a narrow fix for the expected permissive
treatment of memset and other memory functions writing across
subobject boundaries.
PR middle-end/95667 - unintended warning for memset writing across multiple members
PR middle-end/92814 - missing -Wstringop-overflow writing into a dynamically allocated flexible array member

gcc/ChangeLog:

	PR middle-end/95667
	PR middle-end/92814
	* builtins.c (compute_objsize): Remove call to
	compute_builtin_object_size and instead compute conservative sizes
	directly here.

gcc/testsuite/ChangeLog:

	PR middle-end/95667
	PR middle-end/92814
	* gcc.dg/Wstringop-overflow-25.c: Remove xfails.
	* gcc.dg/Wstringop-overflow-39.c: New test.

diff --git a/gcc/builtins.c b/gcc/builtins.c
index caab188e81c..4754602e0ec 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -4009,31 +4009,6 @@ static bool
 compute_objsize (tree ptr, int ostype, access_ref *pref,
 		 bitmap *visited, const vr_values *rvals /* = NULL */)
 {
-  if (ostype == 0)
-{
-  /* Use BOS only for raw memory functions like memcpy to get
-	 the size of the largest enclosing object.  */
-  tree off = NULL_TREE;
-  unsigned HOST_WIDE_INT size;
-  if (compute_builtin_object_size (ptr, ostype, &size, &pref->ref, &off))
-	{
-	  if (off)
-	{
-	  offset_int offset = wi::to_offset (off);
-	  pref->offrng[0] += offset;
-	  pref->offrng[1] += offset;
-
-	  /* compute_builtin_object_size() returns the remaining
-		 size in PTR.  Add the offset to it to get the full
-		 size.  */
-	  pref->sizrng[0] = pref->sizrng[1] = size + offset;
-	}
-	  else
-	pref->sizrng[0] = pref->sizrng[1] = size;
-	  return true;
-	}
-}
-
   const bool addr = TREE_CODE (ptr) == ADDR_EXPR;
   if (addr)
 ptr = TREE_OPERAND (ptr, 0);
@@ -4058,18 +4033,28 @@ compute_objsize (tree ptr, int ostype, access_ref *pref,
 
   if (code == COMPONENT_REF)
 {
+  tree field = TREE_OPERAND (ptr, 1);
+
   if (ostype == 0)
 	{
 	  /* For raw memory functions like memcpy bail if the size
 	 of the enclosing object cannot be determined.  */
-	  access_ref tmpref;
 	  tree ref = TREE_OPERAND (ptr, 0);
-	  if (!compute_objsize (ref, ostype, &tmpref, visited, rvals)
-	  || !tmpref.ref)
+	  if (!compute_objsize (ref, ostype, pref, visited, rvals)
+	  || !pref->ref)
 	return false;
+
+	  /* Otherwise, use the size of the enclosing object and add
+	 the offset of the member to the offset computed so far.  */
+	  tree offset = byte_position (field);
+	  if (TREE_CODE (offset) != INTEGER_CST)
+	return false;
+	  offset_int off = wi::to_offset (offset);
+	  pref->offrng[0] += off;
+	  pref->offrng[1] += off;
+	  return true;
 	}
 
-  tree field = TREE_OPERAND (ptr, 1);
   /* Bail if the reference is to the pointer itself (as opposed
 	 to what it points to).  */
   if (!addr && POINTER_TYPE_P (TREE_TYPE (field)))
@@ -4147,8 +4132,11 @@ compute_objsize (tree ptr, int ostype, access_ref *pref,
 	  orng[0] *= sz;
 	  orng[1] *= sz;
 
-	  if (TREE_CODE (eltype) == ARRAY_TYPE)
+	  if (ostype && TREE_CODE (eltype) == ARRAY_TYPE)
 	{
+	  /* Execpt for the permissive raw memory functions which
+		 use the size of the whole object determined above,
+		 use the size of the referenced array.  */
 	  pref->sizrng[0] = pref->offrng[0] + orng[0] + sz;
 	  pref->sizrng[1] = pref->offrng[1] + orng[1] + sz;
 	}
diff --git a/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c b/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c
index 01807207acc..109a1dd9127 100644
--- a/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c
+++ b/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c
@@ -370,14 +370,14 @@ NOIPA void test_strcpy_malloc_flexarray (void)
   size_t r_2_3 = UR (2, 3);
 
   T (char, S (0), r_0_1);
-  T (char, S (1), r_0_1);   // { dg-warning "\\\

Re: [stage1][PATCH] Add gcc_assert that &global_options are not dirty modified.

[Jeff Law via Gcc-patches]

On Thu, 2020-06-18 at 14:21 +0200, Martin Liška wrote:
> On 6/18/20 1:32 PM, Luis Machado wrote:
> > FTR, I'm running into this ICE when attempting to build the Linux Kernel 
> > for arm64.
> 
> Hello.
> 
> Thanks for the report.
> 
> > More specifically:
> > 
> > /repos/linux-arm/kernel/bpf/core.c:1368:1: internal compiler error: 
> > ‘global_options’ are modified in local context
> >   1368 | {
> >| ^
> > 0xc0554b cl_optimization_compare(gcc_options*, gcc_options*)
> >  /build/gcc-master/gcc/options-save.c:9786
> > 0x7812df handle_optimize_attribute
> >  ../../../repos/gcc/gcc/c-family/c-attribs.c:4475
> > 0x666477 decl_attributes(tree_node**, tree_node*, int, tree_node*)
> >  ../../../repos/gcc/gcc/attribs.c:714
> > 0x688c9b start_function(c_declspecs*, c_declarator*, tree_node*)
> >  ../../../repos/gcc/gcc/c/c-decl.c:9177
> > 0x6f85f3 c_parser_declaration_or_fndef
> >  ../../../repos/gcc/gcc/c/c-parser.c:2434
> > 0x7038af c_parser_external_declaration
> >  ../../../repos/gcc/gcc/c/c-parser.c:1773
> > 0x7044c7 c_parser_translation_unit
> >  ../../../repos/gcc/gcc/c/c-parser.c:1646
> > 0x7044c7 c_parse_file()
> >  ../../../repos/gcc/gcc/c/c-parser.c:21822
> > 0x764897 c_common_parse_file()
> >  ../../../repos/gcc/gcc/c-family/c-opts.c:1190
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > Please include the complete backtrace with any bug report.
> > See  for instructions.
> > 
> > I don't have a reduced testcase for this, but I thought I'd check if this 
> > is known/being worked on before filing a bug.
> 
> It's not a known issue. Please attach me the used command line and 
> pre-processed source file
> (using -E option).
You might try arc-elf gcc.dg/pr91734.c.  I've been behind and just peeked at the
arc-elf regressions in the tester a moment ago and it's tripping this as well.

Executing on host: /home/jenkins/workspace/arc-elf/arc-elf-obj/gcc/gcc/xgcc 
-B/home/jenkins/workspace/arc-elf/arc-elf-obj/gcc/gcc/ 
/home/jenkins/gcc/gcc/testsuite/gcc.dg/pr91734.c gcc_tg.o
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers 
-fdiagnostics-color=never  -fdiagnostics-urls=never   -ansi -pedantic-errors 
-O2 -std=gnu99 -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main 
-Wl,-wrap,abort -lm  -o ./pr91734.exe(timeout = 300)
spawn -ignore SIGHUP /home/jenkins/workspace/arc-elf/arc-elf-obj/gcc/gcc/xgcc 
-B/home/jenkins/workspace/arc-elf/arc-elf-obj/gcc/gcc/ 
/home/jenkins/gcc/gcc/testsuite/gcc.dg/pr91734.c gcc_tg.o 
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers 
-fdiagnostics-color=never -fdiagnostics-urls=never -ansi -pedantic-errors -O2 
-std=gnu99 -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o 
./pr91734.exe^M
/home/jenkins/gcc/gcc/testsuite/gcc.dg/pr91734.c:8:1: internal compiler error: 
'global_options' are modified in local context^M
0xc8590f cl_optimization_compare(gcc_options*, gcc_options*)^M

/home/jenkins/workspace/arc-elf/arc-elf-obj/gcc/gcc/options-save.c:9479^M
0x870808 handle_optimize_attribute^M
../../../../../gcc/gcc/c-family/c-attribs.c:4475^M
0x784d3f decl_attributes(tree_node**, tree_node*, int, tree_node*)^M
../../../../../gcc/gcc/attribs.c:714^M
0x7a0b90 start_function(c_declspecs*, c_declarator*, tree_node*)^M
../../../../../gcc/gcc/c/c-decl.c:9177^M
0x7f97f7 c_parser_declaration_or_fndef^M
../../../../../gcc/gcc/c/c-parser.c:2434^M
0x801e33 c_parser_external_declaration^M
../../../../../gcc/gcc/c/c-parser.c:1773^M
0x802881 c_parser_translation_unit^M
../../../../../gcc/gcc/c/c-parser.c:1646^M
0x802881 c_parse_file()^M
../../../../../gcc/gcc/c/c-parser.c:21822^M
0x85ab6b c_common_parse_file()^M
../../../../../gcc/gcc/c-family/c-opts.c:1190^M
> 

Re: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift intrinsics code-gen.

[Christophe Lyon via Gcc-patches]

Hi,

On Thu, 18 Jun 2020 at 11:43, Kyrylo Tkachov  wrote:
>
>
>
> > -Original Message-
> > From: Srinath Parvathaneni 
> > Sent: 17 June 2020 17:17
> > To: gcc-patches@gcc.gnu.org
> > Cc: Kyrylo Tkachov 
> > Subject: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift intrinsics code-
> > gen.
> >
> > Hello,
> >
> > This patch modifies the MVE scalar shift RTL patterns. The current patterns
> > have wrong constraints and predicates due to which the values returned
> > from
> > MVE scalar shift instructions are overwritten in the code-gen.
> >
> > example:
> > $ cat x.c
> > int32_t  foo(int64_t acc, int shift)
> > {
> >   return sqrshrl_sat48 (acc, shift);
> > }
> >
> > Code-gen before applying this patch:
> > $ arm-none-eabi-gcc -march=armv8.1-m.main+mve -mfloat-abi=hard -O2 -S
> > $  cat x.s
> > foo:
> >push{r4, r5}
> >sqrshrl r0, r1, #48, r2   > (a)
> >mov r0, r4  > (b)
> >pop {r4, r5}
> >bx  lr
> >
> > Code-gen after applying this patch:
> > foo:
> >sqrshrl r0, r1, #48, r2
> >bx  lr
> >
> > In the current compiler the return value (r0) from sqrshrl (a) is getting
> > overwritten by the mov statement (b).
> > This patch fixes above issue.
> >
> > Regression tested on arm-none-eabi and found no regressions.
> >
> > Ok for gcc-10 branch?
> >
>
> Ok.
> Thanks,
> Kyrill
>
> > Thanks,
> > Srinath.
> >
> > 2020-06-12  Srinath Parvathaneni  
> >
> > gcc/
> >   * config/arm/mve.md (mve_uqrshll_sat_di): Correct the
> > predicate
> >   and constraint of all the operands.
> >   (mve_sqrshrl_sat_di): Likewise.
> >   (mve_uqrshl_si): Likewise.
> >   (mve_sqrshr_si): Likewise.
> >   (mve_uqshll_di): Likewise.
> >   (mve_urshrl_di): Likewise.
> >   (mve_uqshl_si): Likewise.
> >   (mve_urshr_si): Likewise.
> >   (mve_sqshl_si): Likewise.
> >   (mve_srshr_si): Likewise.
> >   (mve_srshrl_di): Likewise.
> >   (mve_sqshll_di): Likewise.
> >   * config/arm/predicates.md (arm_low_register_operand): Define.
> >
> > gcc/testsuite/
> >   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts1.c: New test.
> >   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts2.c: Likewise.
> >   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts3.c: Likewise.
> >   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts4.c: Likewise.
> >

These new tests fails to link on arm-linux-gnueabi* targets with no
m-profile multilibs:
FAIL: gcc.target/arm/mve/intrinsics/mve_scalar_shifts1.c (test for
excess errors)
Excess errors:
/aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/tools/arm-none-linux-gnueabi/bin/ld:
error: ./mve_scalar_shifts1.o: conflicting architecture profiles M/A
/aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/tools/arm-none-linux-gnueabi/bin/ld:
failed to merge target specific data of file ./mve_scalar_shifts1.o

probably because arm_v8_1m_mve_ok only checks that compilation is OK
and does not try to link

(same applies to the trunk commit)

Christophe


> > (cherry picked from commit 6af598703f919b56f628c496843cdfe6f0cb8276)
> >
> >
> > ### Attachment also inlined for ease of reply
> > ###
> >
> >
> > diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
> > index
> > 3a57901bd5bcd770832d59dc77cd92b6d9b5ecb4..9758862ac2bb40805dc5b6
> > 6c9b05466fffcf91df 100644
> > --- a/gcc/config/arm/mve.md
> > +++ b/gcc/config/arm/mve.md
> > @@ -11344,9 +11344,9 @@
> >  ;; [uqrshll_di]
> >  ;;
> >  (define_insn "mve_uqrshll_sat_di"
> > -  [(set (match_operand:DI 0 "arm_general_register_operand" "+r")
> > - (unspec:DI [(match_operand:DI 1 "arm_general_register_operand"
> > "r")
> > - (match_operand:SI 2 "s_register_operand" "r")]
> > +  [(set (match_operand:DI 0 "arm_low_register_operand" "=l")
> > + (unspec:DI [(match_operand:DI 1 "arm_low_register_operand" "0")
> > + (match_operand:SI 2 "register_operand" "r")]
> >UQRSHLLQ))]
> >"TARGET_HAVE_MVE"
> >"uqrshll%?\\t%Q1, %R1, #, %2"
> > @@ -11356,9 +11356,9 @@
> >  ;; [sqrshrl_di]
> >  ;;
> >  (define_insn "mve_sqrshrl_sat_di"
> > -  [(set (match_operand:DI 0 "arm_general_register_operand" "+r")
> > - (unspec:DI [(match_operand:DI 1 "arm_general_register_operand"
> > "r")
> > - (match_operand:SI 2 "s_register_operand" "r")]
> > +  [(set (match_operand:DI 0 "arm_low_register_operand" "=l")
> > + (unspec:DI [(match_operand:DI 1 "arm_low_register_operand" "0")
> > + (match_operand:SI 2 "register_operand" "r")]
> >SQRSHRLQ))]
> >"TARGET_HAVE_MVE"
> >"sqrshrl%?\\t%Q1, %R1, #, %2"
> > @@ -11368,9 +11368,9 @@
> >  ;; [uqrshl_si]
> >  ;;
> >  (define_insn "mve_uqrshl_si"
> > -  [(set (match_operand:SI 0 "arm_general_register_operand" "+r")
> > - (unspec:SI [(match_operand:SI 1 "arm_general_register_operand"
> > "r")
> > - (match_operand:SI 2 "s_register_operand" "r")]
> > +  [(set (match_operand:SI 0 "arm_general_register_operand" "=r")
>

[PATCH] c++: ICE in requires-expressions with invalid args [PR95735]

[Marek Polacek via Gcc-patches]

This ICE-on-invalid goes back to GCC 6.  In finish_template_variable,
if coerce_innermost_template_parms returns error_mark_node, we pass
it down to constraints_satisfied_p and that error_mark_node flows
down to various satisfy_* functions and then to various tsubst_*
functions, where we crash.  diagnose_constraints also doesn't cope
with error arglist, so I think we should just return as in the
patch below.

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

gcc/cp/ChangeLog:

PR c++/95735
* pt.c (finish_template_variable): Return if
coerce_innermost_template_parms return error_mark_node.

gcc/testsuite/ChangeLog:

PR c++/95735
* g++.dg/cpp2a/concepts-err2.C: New test.
---
 gcc/cp/pt.c|  2 ++
 gcc/testsuite/g++.dg/cpp2a/concepts-err2.C | 11 +++
 2 files changed, 13 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-err2.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 9732e3b78c7..1c0759edcae 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10154,6 +10154,8 @@ finish_template_variable (tree var, tsubst_flags_t 
complain)
   arglist = coerce_innermost_template_parms (parms, arglist, templ, complain,
 /*req_all*/true,
 /*use_default*/true);
+  if (arglist == error_mark_node)
+return error_mark_node;
 
   if (flag_concepts && !constraints_satisfied_p (templ, arglist))
 {
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-err2.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-err2.C
new file mode 100644
index 000..c0372a6096b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-err2.C
@@ -0,0 +1,11 @@
+// PR c++/95735
+// { dg-do compile { target concepts } }
+
+template 
+requires requires { F(); }
+bool v{};
+
+void f() {
+int x;
+static_assert(v<[&] { x++; }>); // { dg-error "not a constant expression" }
+}

base-commit: 72cb486456a39524c6f822327ba8654b0221ff4c
-- 
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Re: [PATCH] avoid warning for memset writing over multiple members (PR 95667)

[Jeff Law via Gcc-patches]

On Thu, 2020-06-18 at 08:56 -0600, Martin Sebor via Gcc-patches wrote:
> In the recent fix to avoid false positives due to compute_objsize
> (PR 95353) where I removed the call to compute_builtin_object_size
> when computing object sizes for calls to string functions like
> strcpy, I kept it out of a misplaced abundance of caution when
> doing the same for the more permissive memcpy and memset.  It
> turned out to be a mistake because it triggered another false
> positive warning in a case when the call wasn't made due to
> the new structure.  Rather than continuing to rely on the function
> (and continue to try to cope with its limitations) the attached
> patch replaces the call with its own computation.  That keeps all
> the logic in one place and avoids the limitations.
> 
> Like the patch for PR 95353, I tested this fix by building Glibc,
> Binutils/GDB, and the kernel on x86_64-linux with no new warnings
> (of course, that didn't prevent the false positive from turning
> up in a Glibc build on nios2-linux-gnu).
> 
> Martin
> 
> PS This isn't meant to resolve the underlying problem with the PRE
> transformation substituting one member for another with the same
> offset.
> 
> PPS I have WIP patches for GCC 11 tweaking this area in a number
> of ways, so this is just a narrow fix for the expected permissive
> treatment of memset and other memory functions writing across
> subobject boundaries.
OK
jeff

Re: [committed] Fix use of inaccessible member in pr85503.C [PR95716]

[Christophe Lyon via Gcc-patches]

On Thu, 18 Jun 2020 at 16:56, Patrick Palka  wrote:
>
> On Thu, 18 Jun 2020, Christophe Lyon wrote:
>
> > Hi,
> >
> > On Wed, 17 Jun 2020 at 15:16, Patrick Palka via Gcc-patches
> >  wrote:
> > >
> > > The recent PR41437 fix exposed a latent use of an inaccessible member in
> > > the below testcase.
> > >
> > > Committed as obvious after verifying that the testcase no longer fails to
> > > compile due to the reported access error.
> > >
> >
> > I've noticed a similar problem in g++.target/aarch64/pr94052.C.
> > The small patch below fixes it, OK for trunk?
>
> The patch looks good to me, thanks!  (I can't formally approve it, but
> I think the patch is simple/obvious enough to be able to commit without
> formal approval.)
>

OK thanks, pushed as r11-1515-g634e6f49101c92ccb83ad3d65f975162582c5dea

Christophe

> >
> > diff --git a/gcc/testsuite/g++.target/aarch64/pr94052.C
> > b/gcc/testsuite/g++.target/aarch64/pr94052.C
> > index d36c9bd..b3bc3e2 100644
> > --- a/gcc/testsuite/g++.target/aarch64/pr94052.C
> > +++ b/gcc/testsuite/g++.target/aarch64/pr94052.C
> > @@ -26,7 +26,7 @@ public:
> >d x();
> >d y();
> >  };
> > -class z : ad {};
> > +class z : public ad {};
> >  struct ae {
> >p af;
> >  };
> >
> >
> > Thanks,
> >
> > Christophe
> >
> > > gcc/testsuite/ChangeLog:
> > >
> > > PR testsuite/95716
> > > * g++.dg/ext/pr85503.C: Give ai::cv public access.
> > > ---
> > >  gcc/testsuite/g++.dg/ext/pr85503.C | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/gcc/testsuite/g++.dg/ext/pr85503.C 
> > > b/gcc/testsuite/g++.dg/ext/pr85503.C
> > > index 7e17943e353..832952a8774 100644
> > > --- a/gcc/testsuite/g++.dg/ext/pr85503.C
> > > +++ b/gcc/testsuite/g++.dg/ext/pr85503.C
> > > @@ -138,6 +138,7 @@ struct ad< ai< cr, ag, ah, cu, ct, cw > > {
> > >  };
> > >  template < typename, int ag, int ah, int, int, int >
> > >  class ai : public af< ai< double, ag, ah > > {
> > > +public:
> > >typedef ai cv;
> > >  };
> > >  template < typename bk, typename ce, typename cf >
> > > --
> > > 2.27.0.83.g0313f36c6e
> > >
> >
> >
>

RE: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift intrinsics code-gen.

[Srinath Parvathaneni]

Hi,

> -Original Message-
> From: Christophe Lyon 
> Sent: 18 June 2020 16:06
> To: Kyrylo Tkachov 
> Cc: Srinath Parvathaneni ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift intrinsics
> code-gen.
> 
> Hi,
> 
> On Thu, 18 Jun 2020 at 11:43, Kyrylo Tkachov 
> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Srinath Parvathaneni 
> > > Sent: 17 June 2020 17:17
> > > To: gcc-patches@gcc.gnu.org
> > > Cc: Kyrylo Tkachov 
> > > Subject: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift
> > > intrinsics code- gen.
> > >
> > > Hello,
> > >
> > > This patch modifies the MVE scalar shift RTL patterns. The current
> > > patterns have wrong constraints and predicates due to which the
> > > values returned from MVE scalar shift instructions are overwritten
> > > in the code-gen.
> > >
> > > example:
> > > $ cat x.c
> > > int32_t  foo(int64_t acc, int shift) {
> > >   return sqrshrl_sat48 (acc, shift); }
> > >
> > > Code-gen before applying this patch:
> > > $ arm-none-eabi-gcc -march=armv8.1-m.main+mve -mfloat-abi=hard -O2
> > > -S $  cat x.s
> > > foo:
> > >push{r4, r5}
> > >sqrshrl r0, r1, #48, r2   > (a)
> > >mov r0, r4  > (b)
> > >pop {r4, r5}
> > >bx  lr
> > >
> > > Code-gen after applying this patch:
> > > foo:
> > >sqrshrl r0, r1, #48, r2
> > >bx  lr
> > >
> > > In the current compiler the return value (r0) from sqrshrl (a) is
> > > getting overwritten by the mov statement (b).
> > > This patch fixes above issue.
> > >
> > > Regression tested on arm-none-eabi and found no regressions.
> > >
> > > Ok for gcc-10 branch?
> > >
> >
> > Ok.
> > Thanks,
> > Kyrill
> >
> > > Thanks,
> > > Srinath.
> > >
> > > 2020-06-12  Srinath Parvathaneni  
> > >
> > > gcc/
> > >   * config/arm/mve.md (mve_uqrshll_sat_di): Correct the
> > > predicate
> > >   and constraint of all the operands.
> > >   (mve_sqrshrl_sat_di): Likewise.
> > >   (mve_uqrshl_si): Likewise.
> > >   (mve_sqrshr_si): Likewise.
> > >   (mve_uqshll_di): Likewise.
> > >   (mve_urshrl_di): Likewise.
> > >   (mve_uqshl_si): Likewise.
> > >   (mve_urshr_si): Likewise.
> > >   (mve_sqshl_si): Likewise.
> > >   (mve_srshr_si): Likewise.
> > >   (mve_srshrl_di): Likewise.
> > >   (mve_sqshll_di): Likewise.
> > >   * config/arm/predicates.md (arm_low_register_operand): Define.
> > >
> > > gcc/testsuite/
> > >   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts1.c: New test.
> > >   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts2.c: Likewise.
> > >   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts3.c: Likewise.
> > >   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts4.c: Likewise.
> > >
> 
> These new tests fails to link on arm-linux-gnueabi* targets with no m-profile
> multilibs:
> FAIL: gcc.target/arm/mve/intrinsics/mve_scalar_shifts1.c (test for excess
> errors) Excess errors:
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/tools/arm-none-linux-
> gnueabi/bin/ld:
> error: ./mve_scalar_shifts1.o: conflicting architecture profiles M/A
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/tools/arm-none-linux-
> gnueabi/bin/ld:
> failed to merge target specific data of file ./mve_scalar_shifts1.o
> 
> probably because arm_v8_1m_mve_ok only checks that compilation is OK
> and does not try to link
> 
> (same applies to the trunk commit)

Following patch is posted to fix above failures.
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548507.html

Regards,
SRI.
> 
> Christophe
> 
> 
> > > (cherry picked from commit
> 6af598703f919b56f628c496843cdfe6f0cb8276)
> > >
> > >
> > > ### Attachment also inlined for ease of reply
> > > ###
> > >
> > >
> > > diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md index
> > >
> 3a57901bd5bcd770832d59dc77cd92b6d9b5ecb4..9758862ac2bb40805dc5b6
> > > 6c9b05466fffcf91df 100644
> > > --- a/gcc/config/arm/mve.md
> > > +++ b/gcc/config/arm/mve.md
> > > @@ -11344,9 +11344,9 @@
> > >  ;; [uqrshll_di]
> > >  ;;
> > >  (define_insn "mve_uqrshll_sat_di"
> > > -  [(set (match_operand:DI 0 "arm_general_register_operand" "+r")
> > > - (unspec:DI [(match_operand:DI 1 "arm_general_register_operand"
> > > "r")
> > > - (match_operand:SI 2 "s_register_operand" "r")]
> > > +  [(set (match_operand:DI 0 "arm_low_register_operand" "=l")
> > > + (unspec:DI [(match_operand:DI 1 "arm_low_register_operand" "0")
> > > + (match_operand:SI 2 "register_operand" "r")]
> > >UQRSHLLQ))]
> > >"TARGET_HAVE_MVE"
> > >"uqrshll%?\\t%Q1, %R1, #, %2"
> > > @@ -11356,9 +11356,9 @@
> > >  ;; [sqrshrl_di]
> > >  ;;
> > >  (define_insn "mve_sqrshrl_sat_di"
> > > -  [(set (match_operand:DI 0 "arm_general_register_operand" "+r")
> > > - (unspec:DI [(match_operand:DI 1 "arm_general_register_operand"
> > > "r")
> > > - (match_operand:SI 2 "s_register_operand" "r")]
> > > +  [(set (match

Re: [stage1][PATCH] Add gcc_assert that &global_options are not dirty modified.

[Martin Liška]

On 6/18/20 5:02 PM, Jeff Law wrote:

On Thu, 2020-06-18 at 14:21 +0200, Martin Liška wrote:

On 6/18/20 1:32 PM, Luis Machado wrote:

FTR, I'm running into this ICE when attempting to build the Linux Kernel for 
arm64.


Hello.

Thanks for the report.


More specifically:

/repos/linux-arm/kernel/bpf/core.c:1368:1: internal compiler error: 
‘global_options’ are modified in local context
   1368 | {
| ^
0xc0554b cl_optimization_compare(gcc_options*, gcc_options*)
  /build/gcc-master/gcc/options-save.c:9786
0x7812df handle_optimize_attribute
  ../../../repos/gcc/gcc/c-family/c-attribs.c:4475
0x666477 decl_attributes(tree_node**, tree_node*, int, tree_node*)
  ../../../repos/gcc/gcc/attribs.c:714
0x688c9b start_function(c_declspecs*, c_declarator*, tree_node*)
  ../../../repos/gcc/gcc/c/c-decl.c:9177
0x6f85f3 c_parser_declaration_or_fndef
  ../../../repos/gcc/gcc/c/c-parser.c:2434
0x7038af c_parser_external_declaration
  ../../../repos/gcc/gcc/c/c-parser.c:1773
0x7044c7 c_parser_translation_unit
  ../../../repos/gcc/gcc/c/c-parser.c:1646
0x7044c7 c_parse_file()
  ../../../repos/gcc/gcc/c/c-parser.c:21822
0x764897 c_common_parse_file()
  ../../../repos/gcc/gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I don't have a reduced testcase for this, but I thought I'd check if this is 
known/being worked on before filing a bug.


It's not a known issue. Please attach me the used command line and 
pre-processed source file
(using -E option).

You might try arc-elf gcc.dg/pr91734.c.  I've been behind and just peeked at the
arc-elf regressions in the tester a moment ago and it's tripping this as well.


Thanks for it. This one is one another example where an optimization level 
affects
a target option:

$ cat x.c
__attribute__((optimize ("O3"))) void
f1 ()
{
}

int
main ()
{
  return 0;
}

11682 if (ptr1->x_TARGET_ALIGN_CALL != ptr2->x_TARGET_ALIGN_CALL)
11683   internal_error ("% are modified in local context");

set here:
{ OPT_LEVELS_3_PLUS_SPEED_ONLY, OPT_malign_call, NULL, 1 },

I'm going to add this to exception list.




Executing on host: /home/jenkins/workspace/arc-elf/arc-elf-obj/gcc/gcc/xgcc 
-B/home/jenkins/workspace/arc-elf/arc-elf-obj/gcc/gcc/ 
/home/jenkins/gcc/gcc/testsuite/gcc.dg/pr91734.c gcc_tg.o
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers 
-fdiagnostics-color=never  -fdiagnostics-urls=never   -ansi -pedantic-errors 
-O2 -std=gnu99 -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main 
-Wl,-wrap,abort -lm  -o ./pr91734.exe(timeout = 300)
spawn -ignore SIGHUP /home/jenkins/workspace/arc-elf/arc-elf-obj/gcc/gcc/xgcc 
-B/home/jenkins/workspace/arc-elf/arc-elf-obj/gcc/gcc/ 
/home/jenkins/gcc/gcc/testsuite/gcc.dg/pr91734.c gcc_tg.o 
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers 
-fdiagnostics-color=never -fdiagnostics-urls=never -ansi -pedantic-errors -O2 
-std=gnu99 -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o 
./pr91734.exe^M
/home/jenkins/gcc/gcc/testsuite/gcc.dg/pr91734.c:8:1: internal compiler error: 
'global_options' are modified in local context^M
0xc8590f cl_optimization_compare(gcc_options*, gcc_options*)^M
 
/home/jenkins/workspace/arc-elf/arc-elf-obj/gcc/gcc/options-save.c:9479^M
0x870808 handle_optimize_attribute^M
 ../../../../../gcc/gcc/c-family/c-attribs.c:4475^M
0x784d3f decl_attributes(tree_node**, tree_node*, int, tree_node*)^M
 ../../../../../gcc/gcc/attribs.c:714^M
0x7a0b90 start_function(c_declspecs*, c_declarator*, tree_node*)^M
 ../../../../../gcc/gcc/c/c-decl.c:9177^M
0x7f97f7 c_parser_declaration_or_fndef^M
 ../../../../../gcc/gcc/c/c-parser.c:2434^M
0x801e33 c_parser_external_declaration^M
 ../../../../../gcc/gcc/c/c-parser.c:1773^M
0x802881 c_parser_translation_unit^M
 ../../../../../gcc/gcc/c/c-parser.c:1646^M
0x802881 c_parse_file()^M
 ../../../../../gcc/gcc/c/c-parser.c:21822^M
0x85ab6b c_common_parse_file()^M
 ../../../../../gcc/gcc/c-family/c-opts.c:1190^M

Re: [stage1][PATCH] Add gcc_assert that &global_options are not dirty modified.

[Martin Liška]

I see the following ICE for aarch64 kernel build:

$ cat neon.i
#pragma GCC push_options
#pragma GCC target "arch=armv8.2-a+bf16"
#pragma GCC pop_options

$ ./xgcc -B. ~/Programming/testcases/neon.i -c -mbranch-protection=pac-ret
/home/marxin/Programming/testcases/neon.i:3:9: internal compiler error: 
‘global_options’ are modified in local context
3 | #pragma GCC pop_options
  | ^~~
0xf73 cl_optimization_compare(gcc_options*, gcc_options*)
/dev/shm/objdir3/gcc/options-save.c:11996
0xb02ff4 handle_pragma_pop_options
/home/marxin/Programming/gcc/gcc/c-family/c-pragma.c:1090
0xb03953 c_invoke_pragma_handler(unsigned int)
/home/marxin/Programming/gcc/gcc/c-family/c-pragma.c:1512
0xa5ae39 c_parser_pragma
/home/marxin/Programming/gcc/gcc/c/c-parser.c:12544
0xa3f9fc c_parser_external_declaration
/home/marxin/Programming/gcc/gcc/c/c-parser.c:1754
0xa3f5c8 c_parser_translation_unit
/home/marxin/Programming/gcc/gcc/c/c-parser.c:1646
0xa7db4d c_parse_file()
/home/marxin/Programming/gcc/gcc/c/c-parser.c:21822
0xafd0b6 c_common_parse_file()
/home/marxin/Programming/gcc/gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

#1  0x0f74 in cl_optimization_compare (ptr1=0x2d5e3f0, ptr2=0x2cc7760 
) at options-save.c:11996
11996   internal_error ("% are modified in local context");
(gdb) p ptr2->x_aarch64_branch_protection_string
$2 = 0x2cf52e0 "pac-ret"
(gdb) p ptr1->x_aarch64_branch_protection_string
$3 = 0x2d3c190 "pac-ret"


   │11995 if (ptr1->x_aarch64_branch_protection_string != 
ptr2->x_aarch64_branch_protection_string)
  >│11996   internal_error ("% are modified in local 
context");

This is bogus as these are 2 strings that are equal. Let me fix it.

Martin

Re: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift intrinsics code-gen.

[Christophe Lyon via Gcc-patches]

On Thu, 18 Jun 2020 at 17:34, Srinath Parvathaneni
 wrote:
>
> Hi,
>
> > -Original Message-
> > From: Christophe Lyon 
> > Sent: 18 June 2020 16:06
> > To: Kyrylo Tkachov 
> > Cc: Srinath Parvathaneni ; gcc-
> > patc...@gcc.gnu.org
> > Subject: Re: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift intrinsics
> > code-gen.
> >
> > Hi,
> >
> > On Thu, 18 Jun 2020 at 11:43, Kyrylo Tkachov 
> > wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Srinath Parvathaneni 
> > > > Sent: 17 June 2020 17:17
> > > > To: gcc-patches@gcc.gnu.org
> > > > Cc: Kyrylo Tkachov 
> > > > Subject: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift
> > > > intrinsics code- gen.
> > > >
> > > > Hello,
> > > >
> > > > This patch modifies the MVE scalar shift RTL patterns. The current
> > > > patterns have wrong constraints and predicates due to which the
> > > > values returned from MVE scalar shift instructions are overwritten
> > > > in the code-gen.
> > > >
> > > > example:
> > > > $ cat x.c
> > > > int32_t  foo(int64_t acc, int shift) {
> > > >   return sqrshrl_sat48 (acc, shift); }
> > > >
> > > > Code-gen before applying this patch:
> > > > $ arm-none-eabi-gcc -march=armv8.1-m.main+mve -mfloat-abi=hard -O2
> > > > -S $  cat x.s
> > > > foo:
> > > >push{r4, r5}
> > > >sqrshrl r0, r1, #48, r2   > (a)
> > > >mov r0, r4  > (b)
> > > >pop {r4, r5}
> > > >bx  lr
> > > >
> > > > Code-gen after applying this patch:
> > > > foo:
> > > >sqrshrl r0, r1, #48, r2
> > > >bx  lr
> > > >
> > > > In the current compiler the return value (r0) from sqrshrl (a) is
> > > > getting overwritten by the mov statement (b).
> > > > This patch fixes above issue.
> > > >
> > > > Regression tested on arm-none-eabi and found no regressions.
> > > >
> > > > Ok for gcc-10 branch?
> > > >
> > >
> > > Ok.
> > > Thanks,
> > > Kyrill
> > >
> > > > Thanks,
> > > > Srinath.
> > > >
> > > > 2020-06-12  Srinath Parvathaneni  
> > > >
> > > > gcc/
> > > >   * config/arm/mve.md (mve_uqrshll_sat_di): Correct the
> > > > predicate
> > > >   and constraint of all the operands.
> > > >   (mve_sqrshrl_sat_di): Likewise.
> > > >   (mve_uqrshl_si): Likewise.
> > > >   (mve_sqrshr_si): Likewise.
> > > >   (mve_uqshll_di): Likewise.
> > > >   (mve_urshrl_di): Likewise.
> > > >   (mve_uqshl_si): Likewise.
> > > >   (mve_urshr_si): Likewise.
> > > >   (mve_sqshl_si): Likewise.
> > > >   (mve_srshr_si): Likewise.
> > > >   (mve_srshrl_di): Likewise.
> > > >   (mve_sqshll_di): Likewise.
> > > >   * config/arm/predicates.md (arm_low_register_operand): Define.
> > > >
> > > > gcc/testsuite/
> > > >   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts1.c: New test.
> > > >   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts2.c: Likewise.
> > > >   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts3.c: Likewise.
> > > >   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts4.c: Likewise.
> > > >
> >
> > These new tests fails to link on arm-linux-gnueabi* targets with no 
> > m-profile
> > multilibs:
> > FAIL: gcc.target/arm/mve/intrinsics/mve_scalar_shifts1.c (test for excess
> > errors) Excess errors:
> > /aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/tools/arm-none-linux-
> > gnueabi/bin/ld:
> > error: ./mve_scalar_shifts1.o: conflicting architecture profiles M/A
> > /aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/tools/arm-none-linux-
> > gnueabi/bin/ld:
> > failed to merge target specific data of file ./mve_scalar_shifts1.o
> >
> > probably because arm_v8_1m_mve_ok only checks that compilation is OK
> > and does not try to link
> >
> > (same applies to the trunk commit)
>
> Following patch is posted to fix above failures.
> https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548507.html
>

I thought that one was meant to make sure the right HW or simulator is
available to run the test.
There are other cases where the tests are compile-only when
HW/simulator is not available.

> Regards,
> SRI.
> >
> > Christophe
> >
> >
> > > > (cherry picked from commit
> > 6af598703f919b56f628c496843cdfe6f0cb8276)
> > > >
> > > >
> > > > ### Attachment also inlined for ease of reply
> > > > ###
> > > >
> > > >
> > > > diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md index
> > > >
> > 3a57901bd5bcd770832d59dc77cd92b6d9b5ecb4..9758862ac2bb40805dc5b6
> > > > 6c9b05466fffcf91df 100644
> > > > --- a/gcc/config/arm/mve.md
> > > > +++ b/gcc/config/arm/mve.md
> > > > @@ -11344,9 +11344,9 @@
> > > >  ;; [uqrshll_di]
> > > >  ;;
> > > >  (define_insn "mve_uqrshll_sat_di"
> > > > -  [(set (match_operand:DI 0 "arm_general_register_operand" "+r")
> > > > - (unspec:DI [(match_operand:DI 1 "arm_general_register_operand"
> > > > "r")
> > > > - (match_operand:SI 2 "s_register_operand" "r")]
> > > > +  [(set (match_operand:DI 0 "arm_low_register_operand" "=l")
> > > > + (unspec:DI [(match_operand:DI 1 "arm_low_reg

Re: [PATCH] c++: ICE in requires-expressions with invalid args [PR95735]

[Jason Merrill via Gcc-patches]

On 6/18/20 11:11 AM, Marek Polacek wrote:

This ICE-on-invalid goes back to GCC 6.  In finish_template_variable,
if coerce_innermost_template_parms returns error_mark_node, we pass
it down to constraints_satisfied_p and that error_mark_node flows
down to various satisfy_* functions and then to various tsubst_*
functions, where we crash.  diagnose_constraints also doesn't cope
with error arglist, so I think we should just return as in the
patch below.

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


OK.


gcc/cp/ChangeLog:

PR c++/95735
* pt.c (finish_template_variable): Return if
coerce_innermost_template_parms return error_mark_node.

gcc/testsuite/ChangeLog:

PR c++/95735
* g++.dg/cpp2a/concepts-err2.C: New test.
---
  gcc/cp/pt.c|  2 ++
  gcc/testsuite/g++.dg/cpp2a/concepts-err2.C | 11 +++
  2 files changed, 13 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-err2.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 9732e3b78c7..1c0759edcae 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10154,6 +10154,8 @@ finish_template_variable (tree var, tsubst_flags_t 
complain)
arglist = coerce_innermost_template_parms (parms, arglist, templ, complain,
 /*req_all*/true,
 /*use_default*/true);
+  if (arglist == error_mark_node)
+return error_mark_node;
  
if (flag_concepts && !constraints_satisfied_p (templ, arglist))

  {
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-err2.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-err2.C
new file mode 100644
index 000..c0372a6096b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-err2.C
@@ -0,0 +1,11 @@
+// PR c++/95735
+// { dg-do compile { target concepts } }
+
+template 
+requires requires { F(); }
+bool v{};
+
+void f() {
+int x;
+static_assert(v<[&] { x++; }>); // { dg-error "not a constant expression" }
+}

base-commit: 72cb486456a39524c6f822327ba8654b0221ff4c

Re: [stage1][PATCH] Add gcc_assert that &global_options are not dirty modified.

[Luis Machado via Gcc-patches]

On 6/18/20 12:40 PM, Martin Liška wrote:

I see the following ICE for aarch64 kernel build:

$ cat neon.i
#pragma GCC push_options
#pragma GCC target "arch=armv8.2-a+bf16"
#pragma GCC pop_options

$ ./xgcc -B. ~/Programming/testcases/neon.i -c -mbranch-protection=pac-ret
/home/marxin/Programming/testcases/neon.i:3:9: internal compiler error: 
‘global_options’ are modified in local context

     3 | #pragma GCC pop_options
   | ^~~
0xf73 cl_optimization_compare(gcc_options*, gcc_options*)
 /dev/shm/objdir3/gcc/options-save.c:11996
0xb02ff4 handle_pragma_pop_options
 /home/marxin/Programming/gcc/gcc/c-family/c-pragma.c:1090
0xb03953 c_invoke_pragma_handler(unsigned int)
 /home/marxin/Programming/gcc/gcc/c-family/c-pragma.c:1512
0xa5ae39 c_parser_pragma
 /home/marxin/Programming/gcc/gcc/c/c-parser.c:12544
0xa3f9fc c_parser_external_declaration
 /home/marxin/Programming/gcc/gcc/c/c-parser.c:1754
0xa3f5c8 c_parser_translation_unit
 /home/marxin/Programming/gcc/gcc/c/c-parser.c:1646
0xa7db4d c_parse_file()
 /home/marxin/Programming/gcc/gcc/c/c-parser.c:21822
0xafd0b6 c_common_parse_file()
 /home/marxin/Programming/gcc/gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

#1  0x0f74 in cl_optimization_compare (ptr1=0x2d5e3f0, 
ptr2=0x2cc7760 ) at options-save.c:11996
11996    internal_error ("% are modified in local 
context");

(gdb) p ptr2->x_aarch64_branch_protection_string
$2 = 0x2cf52e0 "pac-ret"
(gdb) p ptr1->x_aarch64_branch_protection_string
$3 = 0x2d3c190 "pac-ret"


    │11995 if (ptr1->x_aarch64_branch_protection_string != 
ptr2->x_aarch64_branch_protection_string)
   >│11996   internal_error ("% are modified in 
local context");


This is bogus as these are 2 strings that are equal. Let me fix it.

Martin


That's another one I noticed alongside the first one I reported. That's 
good that you managed to reproduce it.

Re: [stage1][PATCH] Add gcc_assert that &global_options are not dirty modified.

[Martin Liška]

On 6/18/20 5:47 PM, Luis Machado wrote:

That's another one I noticed alongside the first one I reported. That's good 
that you managed to reproduce it.


Can you please send me your .config and I can reproduce that locally.

Thanks,
Martin

Re: [PATCH 00/28] rs6000: Auto-generate builtins from descriptions

[will schmidt via Gcc-patches]

On Wed, 2020-06-17 at 14:46 -0500, Bill Schmidt wrote:
> I posted a version of these patches back in stage 4 (February),
> but we agreed that holding off until stage 1 was a better idea.
> Since then I've made more progress and reorganized the patches
> accordingly.  This group of patches lays groundwork, but does not
> actually change GCC's behavior yet, other than to generate the
> new initialization information and ignore it.
> 
> The current built-in support in the rs6000 back end requires at least
> a master's degree in spelunking to comprehend.  It's full of cruft,
> redundancy, and unused bits of code, and long overdue for a
> replacement.  This is the first part of my project to do that.
> 
> My intent is to make adding new built-in functions as simple as
> adding
> a few lines to a couple of files, and automatically generating as
> much
> of the initialization, overload resolution, and expansion logic as
> possible.  This patch series establishes the format of the input
> files
> and creates a new program (rs6000-gen-builtins) to:
> 
>  * Parse the input files into an internal representation;
>  * Generate a file of #defines (rs6000-vecdefines.h) for eventual
>inclusion into altivec.h; and
>  * Generate an initialization file to create and initialize tables of
>built-in functions and overloads.
> 
> Patches 1, 3-7, and 9-19 contain the logic for rs6000-gen-builtins.
> Patch 8 provides balanced tree search support for parsing
> scalability.
> Patches 2 and 21-27 provide a first cut at the input files.
> Patch 20 incorporates the new code into the GCC build.
> Patch 28 adds comments to some existing files that will help
> during the transition from the previous builtin mechanism.
> 
> The patch series is constructed so that any prefix set of the patches
> can be upstreamed without breaking anything, so we can take the
> reviews slowly.  There's still plenty of work left, but I think it
> will be helpful to get this big chunk of patches upstream to make
> further progress easier.
> 
> Thanks in advance for your reviews!
> 

I've read through the series.  Nothing significant, just a few cosmetic
nits, i've called them out below here, versus replying to the
individual emails.  

generally lgtm.  
thanks
-Will


> 
> Bill Schmidt (28):
>   rs6000: Initial create of rs6000-gen-builtins.c
ok
>   rs6000: Add initial input files
Whitespace/tabs in "Legal values of " blurb.
otherwise ok
>   rs6000: Add file support and functions for diagnostic support
ok
>   rs6000: Add helper functions for parsing
ok
>   rs6000: Add functions for matching types, part 1 of 3
ok

>   rs6000: Add functions for matching types, part 2 of 3
ok

>   rs6000: Add functions for matching types, part 3 of 3
ok

>   rs6000: Red-black tree implementation for balanced tree search
ok

>   rs6000: Main function with stubs for parsing and output
ok

>   rs6000: Parsing built-in input file, part 1 of 3
ok
>   rs6000: Parsing built-in input file, part 2 of 3
ok
>   rs6000: Parsing built-in input file, part 3 of 3
ok
>   rs6000: Parsing of overload input file
use enums or consts instead of hardcoding values ? 

>   rs6000: Build and store function type identifiers
ok

>   rs6000: Write output to the vector definition include file
ok

>   rs6000: Write output to the builtins header file

Nit, i'd probably add a 'FIXME' keyword near the "_x" conflict
avoidance so this is easy to find later on.  That said, this is rather
obvious, so nbd. :-)
ok.

>   rs6000: Write output to the builtins init file, part 1 of 3
BILLDEBUG reference should probably be culled. :-)
ok

>   rs6000: Write output to the builtins init file, part 2 of 3
ok

>   rs6000: Write output to the builtins init file, part 3 of 3
ok

>   rs6000: Incorporate new builtins code into the build machinery
ok

>   rs6000: Add remaining MASK_ALTIVEC builtins

A few very long lines (__builtin_vec_init_v16qi, etc) ; but I think
those are fine.
ok

>   rs6000: Add MASK_VSX builtins

For the pick-one-or-the-other, i'd tend to the generic looking one. 
i.e.
const vf __builtin_vsx_xvcvuxwsp(vui);
 CVCVUXWSP_V4SF vsx_xvcvuxwsp {}
.. looks better to me.  Though there may be subtlety that I don't
understand.
ok

>   rs6000: Add available-everywhere and ancient builtins

No opinion or thoughts on the packtf or unpacktf entries.
ok

>   rs6000: Add Power7 builtins
ok
>   rs6000: Add MASK_P8_VECTOR builtins
ok
>   rs6000: Add MASK_P9_VECTOR and MASK_P9_MISC builtins
ok

>   rs6000: Add remaining builtins
ok

>   rs6000: Add comments to help with transition

Are the deprecations old enough that these can be dropped outright?

ok


> 
>  gcc/config.gcc   |3 +-
>  gcc/config/rs6000/rbtree.c   |  233 ++
>  gcc/config/rs6000/rbtree.h   |   51 +
>  gcc/config/rs6000/rs6000-builtin-new.def | 2965
> ++
>  gcc/config/rs6000/rs6000-builtin.def |   15 +
>  gcc/config/rs6000/rs6000-call.c  |  166 ++
>  gcc/config/rs6000/r

RE: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift intrinsics code-gen.

[Srinath Parvathaneni]

Hi,

> -Original Message-
> From: Christophe Lyon 
> Sent: 18 June 2020 16:44
> To: Srinath Parvathaneni 
> Cc: gcc-patches@gcc.gnu.org; Kyrylo Tkachov 
> Subject: Re: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift intrinsics
> code-gen.
> 
> On Thu, 18 Jun 2020 at 17:34, Srinath Parvathaneni
>  wrote:
> >
> > Hi,
> >
> > > -Original Message-
> > > From: Christophe Lyon 
> > > Sent: 18 June 2020 16:06
> > > To: Kyrylo Tkachov 
> > > Cc: Srinath Parvathaneni ; gcc-
> > > patc...@gcc.gnu.org
> > > Subject: Re: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift
> > > intrinsics code-gen.
> > >
> > > Hi,
> > >
> > > On Thu, 18 Jun 2020 at 11:43, Kyrylo Tkachov
> > > 
> > > wrote:
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Srinath Parvathaneni 
> > > > > Sent: 17 June 2020 17:17
> > > > > To: gcc-patches@gcc.gnu.org
> > > > > Cc: Kyrylo Tkachov 
> > > > > Subject: [PATCH][GCC-10 Backport] arm: Fix MVE scalar shift
> > > > > intrinsics code- gen.
> > > > >
> > > > > Hello,
> > > > >
> > > > > This patch modifies the MVE scalar shift RTL patterns. The
> > > > > current patterns have wrong constraints and predicates due to
> > > > > which the values returned from MVE scalar shift instructions are
> > > > > overwritten in the code-gen.
> > > > >
> > > > > example:
> > > > > $ cat x.c
> > > > > int32_t  foo(int64_t acc, int shift) {
> > > > >   return sqrshrl_sat48 (acc, shift); }
> > > > >
> > > > > Code-gen before applying this patch:
> > > > > $ arm-none-eabi-gcc -march=armv8.1-m.main+mve -mfloat-abi=hard
> > > > > -O2 -S $  cat x.s
> > > > > foo:
> > > > >push{r4, r5}
> > > > >sqrshrl r0, r1, #48, r2   > (a)
> > > > >mov r0, r4  > (b)
> > > > >pop {r4, r5}
> > > > >bx  lr
> > > > >
> > > > > Code-gen after applying this patch:
> > > > > foo:
> > > > >sqrshrl r0, r1, #48, r2
> > > > >bx  lr
> > > > >
> > > > > In the current compiler the return value (r0) from sqrshrl (a)
> > > > > is getting overwritten by the mov statement (b).
> > > > > This patch fixes above issue.
> > > > >
> > > > > Regression tested on arm-none-eabi and found no regressions.
> > > > >
> > > > > Ok for gcc-10 branch?
> > > > >
> > > >
> > > > Ok.
> > > > Thanks,
> > > > Kyrill
> > > >
> > > > > Thanks,
> > > > > Srinath.
> > > > >
> > > > > 2020-06-12  Srinath Parvathaneni  
> > > > >
> > > > > gcc/
> > > > >   * config/arm/mve.md (mve_uqrshll_sat_di): Correct
> > > > > the predicate
> > > > >   and constraint of all the operands.
> > > > >   (mve_sqrshrl_sat_di): Likewise.
> > > > >   (mve_uqrshl_si): Likewise.
> > > > >   (mve_sqrshr_si): Likewise.
> > > > >   (mve_uqshll_di): Likewise.
> > > > >   (mve_urshrl_di): Likewise.
> > > > >   (mve_uqshl_si): Likewise.
> > > > >   (mve_urshr_si): Likewise.
> > > > >   (mve_sqshl_si): Likewise.
> > > > >   (mve_srshr_si): Likewise.
> > > > >   (mve_srshrl_di): Likewise.
> > > > >   (mve_sqshll_di): Likewise.
> > > > >   * config/arm/predicates.md (arm_low_register_operand): Define.
> > > > >
> > > > > gcc/testsuite/
> > > > >   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts1.c: New test.
> > > > >   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts2.c: Likewise.
> > > > >   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts3.c: Likewise.
> > > > >   * gcc.target/arm/mve/intrinsics/mve_scalar_shifts4.c: Likewise.
> > > > >
> > >
> > > These new tests fails to link on arm-linux-gnueabi* targets with no
> > > m-profile
> > > multilibs:
> > > FAIL: gcc.target/arm/mve/intrinsics/mve_scalar_shifts1.c (test for
> > > excess
> > > errors) Excess errors:
> > > /aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/tools/arm-none-linux-
> > > gnueabi/bin/ld:
> > > error: ./mve_scalar_shifts1.o: conflicting architecture profiles M/A
> > > /aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/tools/arm-none-linux-
> > > gnueabi/bin/ld:
> > > failed to merge target specific data of file ./mve_scalar_shifts1.o
> > >
> > > probably because arm_v8_1m_mve_ok only checks that compilation is OK
> > > and does not try to link

You are correct, arm_v8_1m_mve_ok only checks that compilation is OK
and does not try to link.

> > >
> > > (same applies to the trunk commit)
> >
> > Following patch is posted to fix above failures.
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548507.html
> >
> 
> I thought that one was meant to make sure the right HW or simulator is
> available to run the test.

That patch was meant to check availability of HW/simulator and also check
linking and execution of M-profile (MVE) test.

> There are other cases where the tests are compile-only when HW/simulator
> is not available.

I haven't done any modifications or added any restrictions to compile-only 
cases.
> 
> > Regards,
> > SRI.
> > >
> > > Christophe
> > >
> > >
> > > > > (cherry picked from commit
> > > 6af598703f919b56f628c496843cdfe6f0cb8276)
> > > > >
> > > > >
> > > >

Re: [stage1][PATCH] Add gcc_assert that &global_options are not dirty modified.

[Luis Machado via Gcc-patches]

On 6/18/20 1:02 PM, Martin Liška wrote:

On 6/18/20 5:47 PM, Luis Machado wrote:
That's another one I noticed alongside the first one I reported. 
That's good that you managed to reproduce it.


Can you please send me your .config and I can reproduce that locally.

Thanks,
Martin


Here it is. It is a defconfig with a gas that supports aarch64 memtag 
(binutils-gdb master will do). I hope this helps. Otherwise I can 
compile the information and dump it in a ticket later.


.config.gz
Description: application/gzip

Re: [PATCH] Fix stack pointer handling in ms_hook_prologue functions for i386 target.

[Paul Gofman via Gcc-patches]

Hello Jeff,

    pinging the patch.

Regards,
    Paul.

On 3/26/20 01:49, Jeff Law wrote:
> On Mon, 2020-02-10 at 19:22 +0300, Paul Gofman wrote:
>> ChangeLog:
>> PR target/91489
>> * config/i386/i386.md (simple_return): Also check
>> for ms_hook_prologue function attribute.
>> * config/i386/i386.c (ix86_can_use_return_insn_p):
>> Also check for ms_hook_prologue function attribute.
>>
>> testsuite/ChangeLog:
>> PR target/91489
>> * gcc.target/i386/ms_hook_prologue.c: Expand testcase
>> to reproduce PR target/91489 issue.
> I'm going to queue this for gcc-11.  While I realize this is a codegen issue, 
> I'm
> not familiar enough with the stdcall conventions to give this the review it 
> would
> need at this stage in gcc-10 development.
>
> jeff

[PATCH] i386: Fix mode of ZERO_EXTRACT RTXes, remove ext_register_operand predicate.

[Uros Bizjak via Gcc-patches]

The mode of ZERO_EXTRACT RTX should match the mode of its LOC register
operand.  The mode should be HI, SI or DImode to enable combine to synthesize
extractions from HImode and DImode operands, in addition to existing SImode.
Further, these changes tighten allowed modes for extv, extzv and insv
named patterns and finally enable removal of ext_register_operand
special predicate.

2020-18-06  Uroš Bizjak  

gcc/ChangeLog:

* config/i386/i386.md (*cmpqi_ext_1): Use SWI248 mode
iterator instead of SImode for ZERO_EXTRACT RTX.  Use SWI248
mode iterator for the first operand of ZERO_EXTRACT RTX.
Change ext_register_operand predicate to register_operand.
Rename from *cmpqi_ext_1.
(*cmpqi_ext_2): Ditto.  Rename from *cmpqi_ext_2.
(*cmpqi_ext_3): Ditto.  Rename from *cmpqi_ext_3.
(*cmpqi_ext_4): Ditto.  Rename from *cmpqi_ext_4.
(cmpi_ext_3): Use HImode instead of SImode for ZERO_EXTRACT RTX.
(*extv): Use SWI24 mode iterator for the first operand
of ZERO_EXTRACT RTX.  Change ext_register_operand predicate
to register_operand.
(*extzv): Use SWI248 mode iterator for the first operand
of ZERO_EXTRACT RTX.  Change ext_register_operand predicate
to register_operand.
(*extzvqi): Use SWI248 mode iterator instead of SImode for
ZERO_EXTRACT RTX.  Use SWI248 mode iterator for the first operand
of ZERO_EXTRACT RTX.  Change ext_register_operand predicate to
register_operand.
(*extzvqi_mem_rex64 and corresponding peephole2):  Use SWI248 mode
iterator instead of SImode for ZERO_EXTRACT RTX.  Use SWI248
mode iterator for the first operand of ZERO_EXTRACT RTX.
Change ext_register_operand predicate to register_operand.
(@insv_1): Use SWI248 mode iterator for the first operand
of ZERO_EXTRACT RTX.  Change ext_register_operand predicate to
register_operand.
(*insvqi_1): Use SWI248 mode iterator instead of SImode
for ZERO_EXTRACT RTX.  Use SWI248 mode iterator for the
first operand of ZERO_EXTRACT RTX.  Change ext_register_operand
predicate to register_operand.
(*insvqi_2): Ditto.
(*insvqi_3): Ditto.
(*insvqi_1_mem_rex64 and corresponding peephole2):  Use SWI248 mode
iterator instead of SImode for ZERO_EXTRACT RTX.  Use SWI248
mode iterator for the first operand of ZERO_EXTRACT RTX.
Change ext_register_operand predicate to register_operand.
(addqi_ext_1): New expander.
(*addqi_ext_1): Use SWI248 mode iterator instead of SImode
for ZERO_EXTRACT RTX.  Use SWI248 mode iterator for the first
operand of ZERO_EXTRACT RTX.  Change ext_register_operand predicate
to register_operand.  Rename from *addqi_ext_1.
(*addqi_ext_2): Ditto. Rename from *addqi_ext_2.
(divmodqi4): Use HImode instead of SImode for ZERO_EXTRACT RTX.
(udivmodqi4): Ditto.
(testqi_ext_1): Use HImode instead of SImode for ZERO_EXTRACT RTX.
(*testqi_ext_1): Use SWI248 mode iterator instead of SImode
for ZERO_EXTRACT RTX.  Use SWI248 mode iterator for the first
operand of ZERO_EXTRACT RTX.  Change ext_register_operand predicate
to register_operand.  Rename from *testqi_ext_1.
(*testqi_ext_2): Ditto.  Rename from *testqi_ext_2.
(andqi_ext_1): New expander.
(*andqi_ext_1): Use SWI248 mode iterator instead of SImode
for ZERO_EXTRACT RTX.  Use SWI248 mode iterator for the first
operand of ZERO_EXTRACT RTX.  Change ext_register_operand predicate
to register_operand.  Rename from andqi_ext_1.
(*andqi_ext_1_cc): Ditto.  Rename from *andqi_ext_1_cc.
(*andqi_ext_2): Ditto.  Rename from *andqi_ext_2.
(*qi_ext_1): Ditto.  Rename from *qi_ext_1.
(*qi_ext_2): Ditto.  Rename from *qi_ext_2.
(xorqi_ext_1_cc): Use HImode instead of SImode for ZERO_EXTRACT RTX.
(*xorqi_ext_1_cc):  Use SWI248 mode iterator instead of SImode
for ZERO_EXTRACT RTX.  Use SWI248 mode iterator for the first
operand of ZERO_EXTRACT RTX.  Change ext_register_operand predicate
to register_operand.  Rename from *xorqi_ext_1_cc.
* config/i386/i386-expand.c (ix86_split_idivmod): Emit ZERO_EXTRACT
in mode, matching its first operand.
(promote_duplicated_reg): Update for renamed insv_1.
* config/i386/predicates.md (ext_register_operand): Remove predicate.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr78904-1a.c: New test.
* gcc.target/i386/pr78904-1b.c: Ditto.
* gcc.target/i386/pr78904-2a.c: Ditto.
* gcc.target/i386/pr78904-2b.c: Ditto.
* gcc.target/i386/pr78904-3a.c: Ditto.
* gcc.target/i386/pr78904-3b.c: Ditto.
* gcc.target/i386/pr78904-4a.c: Ditto.
* gcc.target/i386/pr78904-4b.c: Ditto.
* gcc.target/i386/pr78904-5a.c: Ditto.
* gcc.target/i386/pr78904-5b.c: Ditto.
* gcc.target/i386/pr78904-6a.c: Ditto.
* gcc.target/i386/pr78904-6b.c: Ditto.
* gcc.target/i386/pr78967-1a.c: Ditto.
* gcc.target/i386/pr78967-1b.c: Ditto.
* gcc.target/i386/pr78967-2a.c: Ditto.
* gcc.target/i386/pr78967-2b.c: Ditto.

Re: OpenACC 'attach'/'detach' has no business affecting user-visible reference counting (was: [PATCH 07/13] OpenACC 2.6 deep copy: libgomp parts)

[Julian Brown]

Hi!

On Tue, 9 Jun 2020 12:41:21 +0200
Thomas Schwinge  wrote:

> Hi Julian!
> 
> On 2020-06-05T21:31:08+0100, Julian Brown 
> wrote:
> > On Fri, 5 Jun 2020 13:17:09 +0200
> > Thomas Schwinge  wrote:  
> >> On 2019-12-17T21:03:47-0800, Julian Brown 
> >> wrote:  
> >> > This part contains the libgomp runtime support for the
> >> > GOMP_MAP_ATTACH and GOMP_MAP_DETACH mapping kinds
> >>   
> >> > --- a/libgomp/target.c
> >> > +++ b/libgomp/target.c
> >>   
> >> > @@ -1203,6 +1211,32 @@ gomp_map_vars_internal (struct
> >> > gomp_device_descr *devicep,
> >>   
> >> > +  case GOMP_MAP_ATTACH:
> >> > +{
> >> > +  cur_node.host_start = (uintptr_t)
> >> > hostaddrs[i];
> >> > +  cur_node.host_end = cur_node.host_start +
> >> > sizeof (void *);
> >> > +  splay_tree_key n = splay_tree_lookup
> >> > (mem_map, &cur_node);
> >> > +  if (n != NULL)
> >> > +{
> >> > +  tgt->list[i].key = n;
> >> > +  tgt->list[i].offset = cur_node.host_start
> >> > - n->host_start;
> >> > +  tgt->list[i].length = n->host_end -
> >> > n->host_start;
> >> > +  tgt->list[i].copy_from = false;
> >> > +  tgt->list[i].always_copy_from = false;
> >> > +  tgt->list[i].do_detach
> >> > += (pragma_kind !=
> >> > GOMP_MAP_VARS_OPENACC_ENTER_DATA);
> >> > +  n->refcount++;
> >> > +}
> >> > +  else
> >> > +{
> >> > +  gomp_mutex_unlock (&devicep->lock);
> >> > +  gomp_fatal ("outer struct not mapped for
> >> > attach");
> >> > +}
> >> > +  gomp_attach_pointer (devicep, aq, mem_map, n,
> >> > +   (uintptr_t)
> >> > hostaddrs[i], sizes[i],
> >> > +   cbufp);
> >> > +  continue;
> >> > +}
> >> 
> >> For the OpenACC runtime API 'acc_attach' etc. routines they don't,
> >> so what's the conceptual reason that for the corresponding OpenACC
> >> directive variants, 'GOMP_MAP_ATTACH' etc. here participate in
> >> reference counting ('n->refcount++' above)?  I understand OpenACC
> >> 'attach'/'detach' clauses to be simple "executable clauses", which
> >> just update some values somewhere (say, like
> >> 'GOMP_MAP_ALWAYS_POINTER'), but they don't alter any mapping state,
> >> thus wouldn't appear to need reference counting?  
> >
> > IIUC, n->refcount is not directly the "structural reference count"
> > as seen at source level, but rather counts the number of
> > target_var_descs in the lists appended to each target_mem_desc --
> > and GOMP_MAP_ATTACH have variable entries in those lists.  
> 
> That may be OK if that's purely an implementation detail that isn't
> visible to the user, however:
> 
> > That's not the case for the API
> > routines.  
> 
> As I had mentioned, the problem is: in contrast to 'acc_attach', an
> OpenACC 'enter data' directive with 'attach' clause currently uses
> this same reference-counted code path, and thus such an 'attach'
> without corresponding 'detach' inhibits unmapping; [...]

The attached patch stops attach/detach operations from affecting
reference counts (either structured or dynamic). This isn't as invasive
as I'd imagined: we can extend the use of the "do_detach" flag in
target_mem_descs' variable lists to mark mappings that correspond to
attach operations, then use that flag to avoid refcount
increment/decrements. (The flag should possibly be renamed now.)

I've modified the refcount self-testing code successfully to work with
this new scheme too, in case that's helpful. I'll send the patches for
that separately.

Tested with offloading to NVPTX. OK?

Thanks,

Julian

ChangeLog

libgomp/
* oacc-mem.c (goacc_enter_data_internal): Don't affect
reference counts for attach mappings.
(goacc_exit_data_internal): Don't affect reference counts for
detach mappings.
* target.c (gomp_map_vars_existing): Don't affect reference
counts for attach mappings.
(gomp_map_vars_internal): Set do_detach flag unconditionally to
mark attach mappings.
(gomp_unmap_vars_internal): Use above flag to prevent affecting
reference count for attach mappings.
* testsuite/libgomp.oacc-c-c++-common/attach-detach-rc-1.c: New
test.
* testsuite/libgomp.oacc-c-c++-common/attach-detach-rc-2.c:
Likewise.
* testsuite/libgomp.oacc-fortran/deep-copy-6-no_finalize.F90:
Mark test as shouldfail.
* testsuite/libgomp.oacc-fortran/deep-copy-6.f90: Adjust to fail
gracefully in no-finalize mode.
commit e5fd3efda7f176f035c5ed2e3095d4a49a780864
Author: Julian Brown 
Date:   Thu Jun 18 05:11:08 2020 -0700

  

[PATCH RFC] Propose Updating Basic Block Checking Limits in variable_tracking_main_1

[Nicholas Krause via Gcc-patches]

From: Nicholas Krause 

Changelog:gcc/
*var-tracking.c(variable_tracking_main): Update
numbers for both number of basic blocks per
function and number of edges per function to 
basic blocks to more sane numbers, in order to 
avoid extra edge cases.

Signed-off-by: Nicholas Krause 
---
 gcc/var-tracking.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c
index fc861a0..9cf1b5d 100644
--- a/gcc/var-tracking.c
+++ b/gcc/var-tracking.c
@@ -10470,8 +10470,8 @@ variable_tracking_main_1 (void)
   if (!flag_var_tracking)
 return 0;
 
-  if (n_basic_blocks_for_fn (cfun) > 500
-  && n_edges_for_fn (cfun) / n_basic_blocks_for_fn (cfun) >= 20)
+  if (n_basic_blocks_for_fn (cfun) > 1
+  && n_edges_for_fn (cfun) / n_basic_blocks_for_fn (cfun) >= 500)
 {
   vt_debug_insns_local (true);
   return 0;
-- 
1.8.3.1

Re: [stage1][PATCH] Add gcc_assert that &global_options are not dirty modified.

[Martin Liška]

On 6/18/20 7:18 PM, Luis Machado wrote:

On 6/18/20 1:02 PM, Martin Liška wrote:

On 6/18/20 5:47 PM, Luis Machado wrote:

That's another one I noticed alongside the first one I reported. That's good 
that you managed to reproduce it.


Can you please send me your .config and I can reproduce that locally.

Thanks,
Martin


Here it is. It is a defconfig with a gas that supports aarch64 memtag 
(binutils-gdb master will do). I hope this helps. Otherwise I can compile the 
information and dump it in a ticket later.


In that case please attach output of -E option for the problematic compilation 
unit.

Martin