[PATCH] Remove redundant code from reduction vectorization

[Richard Biener]

Some cleanup.

Bootstrapped & tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2019-10-08  Richard Biener  

* tree-vectorizer.h (_stmt_vec_info::reduc_vectype_in): New.
(_stmt_vec_info::force_single_cycle): Likewise.
(STMT_VINFO_FORCE_SINGLE_CYCLE): New.
(STMT_VINFO_REDUC_VECTYPE_IN): Likewise.
* tree-vect-loop.c (vectorizable_reduction): Set
STMT_VINFO_REDUC_VECTYPE_IN and STMT_VINFO_FORCE_SINGLE_CYCLE.
(vect_transform_reduction): Use them to remove redundant code.
(vect_transform_cycle_phi): Likewise.

diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index f63bb855618..a9ea0caf218 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -5983,9 +5983,13 @@ vectorizable_reduction (stmt_vec_info stmt_info, 
slp_tree slp_node,
}
}
 }
-
   if (!vectype_in)
 vectype_in = vectype_out;
+  STMT_VINFO_REDUC_VECTYPE_IN (reduc_info) = vectype_in;
+  /* For the SSA cycle we store on each participating stmt the operand index
+ where the cycle continues.  Store the one relevant for the actual
+ operation in the reduction meta.  */
+  STMT_VINFO_REDUC_IDX (reduc_info) = reduc_index;
 
   /* When vectorizing a reduction chain w/o SLP the reduction PHI is not
  directy used in stmt.  */
@@ -6457,7 +6461,7 @@ vectorizable_reduction (stmt_vec_info stmt_info, slp_tree 
slp_node,
   && (!STMT_VINFO_IN_PATTERN_P (use_stmt_info)
  || !STMT_VINFO_PATTERN_DEF_SEQ (use_stmt_info))
   && vect_stmt_to_vectorize (use_stmt_info) == stmt_info)
-single_defuse_cycle = true;
+STMT_VINFO_FORCE_SINGLE_CYCLE (reduc_info) = single_defuse_cycle = true;
 
   if (single_defuse_cycle
   || code == DOT_PROD_EXPR
@@ -6584,17 +6588,11 @@ vect_transform_reduction (stmt_vec_info stmt_info, 
gimple_stmt_iterator *gsi,
  stmt_vec_info *vec_stmt, slp_tree slp_node)
 {
   tree vectype_out = STMT_VINFO_VECTYPE (stmt_info);
-  tree vectype_in = NULL_TREE;
   loop_vec_info loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_info);
   class loop *loop = LOOP_VINFO_LOOP (loop_vinfo);
-  enum tree_code code;
-  int op_type;
-  bool is_simple_use;
   int i;
   int ncopies;
-  bool single_defuse_cycle = false;
   int j;
-  tree ops[3];
   int vec_num;
 
   stmt_vec_info reduc_info = info_for_reduction (stmt_info);
@@ -6607,30 +6605,20 @@ vect_transform_reduction (stmt_vec_info stmt_info, 
gimple_stmt_iterator *gsi,
 }
 
   gassign *stmt = as_a  (stmt_info->stmt);
+  enum tree_code code = gimple_assign_rhs_code (stmt);
+  int op_type = TREE_CODE_LENGTH (code);
 
   /* Flatten RHS.  */
-  switch (get_gimple_rhs_class (gimple_assign_rhs_code (stmt)))
+  tree ops[3];
+  switch (get_gimple_rhs_class (code))
 {
-case GIMPLE_BINARY_RHS:
-  code = gimple_assign_rhs_code (stmt);
-  op_type = TREE_CODE_LENGTH (code);
-  gcc_assert (op_type == binary_op);
-  ops[0] = gimple_assign_rhs1 (stmt);
-  ops[1] = gimple_assign_rhs2 (stmt);
-  break;
-
 case GIMPLE_TERNARY_RHS:
-  code = gimple_assign_rhs_code (stmt);
-  op_type = TREE_CODE_LENGTH (code);
-  gcc_assert (op_type == ternary_op);
+  ops[2] = gimple_assign_rhs3 (stmt);
+  /* Fall thru.  */
+case GIMPLE_BINARY_RHS:
   ops[0] = gimple_assign_rhs1 (stmt);
   ops[1] = gimple_assign_rhs2 (stmt);
-  ops[2] = gimple_assign_rhs3 (stmt);
   break;
-
-case GIMPLE_UNARY_RHS:
-  return false;
-
 default:
   gcc_unreachable ();
 }
@@ -6641,110 +6629,19 @@ vect_transform_reduction (stmt_vec_info stmt_info, 
gimple_stmt_iterator *gsi,
  reduction variable.  */
   stmt_vec_info phi_info = STMT_VINFO_REDUC_DEF (vect_orig_stmt (stmt_info));
   gphi *reduc_def_phi = as_a  (phi_info->stmt);
-  tree reduc_def = PHI_RESULT (reduc_def_phi);
-  int reduc_index = -1;
-  for (i = 0; i < op_type; i++)
-{
-  /* The condition of COND_EXPR is checked in vectorizable_condition().  */
-  if (i == 0 && code == COND_EXPR)
-continue;
-
-  stmt_vec_info def_stmt_info;
-  enum vect_def_type dt;
-  tree tem;
-  is_simple_use = vect_is_simple_use (ops[i], loop_vinfo, &dt, &tem,
- &def_stmt_info);
-  gcc_assert (is_simple_use);
-  if (dt == vect_reduction_def
- && ops[i] == reduc_def)
-   {
- reduc_index = i;
- continue;
-   }
-  else if (tem)
-   {
- /* To properly compute ncopies we are interested in the widest
-input type in case we're looking at a widening accumulation.  */
- if (!vectype_in
- || (GET_MODE_SIZE (SCALAR_TYPE_MODE (TREE_TYPE (vectype_in)))
- < GET_MODE_SIZE (SCALAR_TYPE_MODE (TREE_TYPE (tem)
-   vectype_in = tem;
-   }
-
-  if (dt == vect_nested_cycle
- && ops[i] == reduc_def)
-   {
- reduc_index = i;
-   }
-}
-
-  if (!vectype_in)
-v

Re: [PATCH] Come up with ipa passes introduction in gccint documentation

[Richard Biener]

On Tue, Oct 8, 2019 at 10:06 PM Sandra Loosemore
 wrote:
>
> On 10/8/19 2:52 AM, luoxhu wrote:
> > Hi,
> >
> > This is the formal documentation patch for IPA passes.  Thanks.
> >
> >
> > None of the IPA passes are documented in passes.texi.  This patch adds
> > a section IPA passes just before GIMPLE passes and RTL passes in
> > Chapter 9 "Passes and Files of the Compiler".  Also, a short description
> > for each IPA pass is provided.
> > gccint.pdf can be produced without errors.
> >
> > ChangeLog:
> >   PR middle-end/26241
> >   * doc/lto.texi (IPA): Reference to the IPA passes.
> >   * doc/passes.texi (Pass manager): Add node IPA passes and
> > description for each IPA pass.
>
> Thanks for submitting this documentation patch!  The content looks
> helpful to me, but I see that it has quite a few grammar bugs (I
> understand how hard English is even for native speakers), plus some
> issues like indexing, cross-referencing, use of jargon without defining
> it, etc.  I think it would be more efficient for me to take over
> polishing the text some more than to mark it up for you to fix, but I'd
> like to give others a few days to comment on technical content first.

I think the contents are OK for a first try, so please go ahead polishing
and commit.  We can then improve the content as followup (I'm making
a note for myself to not forget).

Thanks,
Richard.

> -Sandra

Re: [PATCH] Come up with ipa passes introduction in gccint documentation

[Jan Hubicka]

> On Tue, Oct 8, 2019 at 10:06 PM Sandra Loosemore
>  wrote:
> >
> > On 10/8/19 2:52 AM, luoxhu wrote:
> > > Hi,
> > >
> > > This is the formal documentation patch for IPA passes.  Thanks.
> > >
> > >
> > > None of the IPA passes are documented in passes.texi.  This patch adds
> > > a section IPA passes just before GIMPLE passes and RTL passes in
> > > Chapter 9 "Passes and Files of the Compiler".  Also, a short description
> > > for each IPA pass is provided.
> > > gccint.pdf can be produced without errors.
> > >
> > > ChangeLog:
> > >   PR middle-end/26241
> > >   * doc/lto.texi (IPA): Reference to the IPA passes.
> > >   * doc/passes.texi (Pass manager): Add node IPA passes and
> > > description for each IPA pass.
> >
> > Thanks for submitting this documentation patch!  The content looks
> > helpful to me, but I see that it has quite a few grammar bugs (I
> > understand how hard English is even for native speakers), plus some
> > issues like indexing, cross-referencing, use of jargon without defining
> > it, etc.  I think it would be more efficient for me to take over
> > polishing the text some more than to mark it up for you to fix, but I'd
> > like to give others a few days to comment on technical content first.
> 
> I think the contents are OK for a first try, so please go ahead polishing
> and commit.  We can then improve the content as followup (I'm making
> a note for myself to not forget).

I will add some extra info once patch is in :)

Thanks for working on this!
Honza
> 
> Thanks,
> Richard.
> 
> > -Sandra

[committed] Fix libgomp use_device_* handling (PR libgomp/92028)

[Jakub Jelinek]

Hi!

The following is what I've intended to do but actually ended up committing
a weird
  if (!not_found_cnt)
{
}
  else
...
The code used to be at the indentation level of if, so my suspicion is that
I've marked the block in an editor and tried to move that block into the
body, but as it was inside of the block it just removed it instead and I
haven't noticed.
Anyway, the comment which Thomas requested in the PR should hopefully
explain why this needs to be done.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.

2019-10-09  Jakub Jelinek  

PR libgomp/92028
* target.c (gomp_map_vars_internal): Readd the previous
GOMP_MAP_USE_DEVICE_PTR handling code in the first loop,
though do that just in the !not_found_cnt case.

--- libgomp/target.c.jj 2019-10-07 13:09:07.038253353 +0200
+++ libgomp/target.c2019-10-08 15:19:16.249439849 +0200
@@ -593,6 +593,30 @@ gomp_map_vars_internal (struct gomp_devi
  tgt->list[i].key = NULL;
  if (!not_found_cnt)
{
+ /* In OpenMP < 5.0 and OpenACC the mapping has to be done
+on a separate construct prior to using use_device_{addr,ptr}.
+In OpenMP 5.0, map directives need to be ordered by the
+middle-end before the use_device_* clauses.  If
+!not_found_cnt, all mappings requested (if any) are already
+mapped, so use_device_{addr,ptr} can be resolved right away.
+Otherwise, if not_found_cnt, gomp_map_lookup might fail
+now but would succeed after performing the mappings in the
+following loop.  We can't defer this always to the second
+loop, because it is not even invoked when !not_found_cnt
+after the first loop.  */
+ cur_node.host_start = (uintptr_t) hostaddrs[i];
+ cur_node.host_end = cur_node.host_start;
+ splay_tree_key n = gomp_map_lookup (mem_map, &cur_node);
+ if (n == NULL)
+   {
+ gomp_mutex_unlock (&devicep->lock);
+ gomp_fatal ("use_device_ptr pointer wasn't mapped");
+   }
+ cur_node.host_start -= n->host_start;
+ hostaddrs[i]
+   = (void *) (n->tgt->tgt_start + n->tgt_offset
+   + cur_node.host_start);
+ tgt->list[i].offset = ~(uintptr_t) 0;
}
  else
tgt->list[i].offset = 0;

Jakub

Re: Type representation in CTF and DWARF

[Richard Biener]

On Wed, Oct 9, 2019 at 7:26 AM Indu Bhagat  wrote:
>
>
>
> On 10/08/2019 08:37 AM, Pedro Alves wrote:
> > On 10/4/19 8:23 PM, Indu Bhagat wrote:
> >> Hello,
> >>
> >> At GNU Tools Cauldron this year, some folks were curious to know more on 
> >> how
> >> the "type representation" in CTF compares vis-a-vis DWARF.
> > I was one of those, and I brought this up to Jose, after your
> > presentation.  Glad to see the follow up!  Thanks much for this.
> >
> > In your Cauldron presentation we saw CTF compared to full blown DWARF
> > as justification for CTF,
>
> Hmm. And I thought I made the effort reqd to clarify my position that 
> comparing
> full-blown DWARF sizes to type-only CTF section sizes is not appropriate, let
> alone to not use as a justification for CTF. My intention to show those 
> numbers was
> only to give some perspective to users curious to know the sizes of CTF debug
> info (as generated by dwarf2ctf) because these sections will ideally be not
> stripped out of shipped binaries.
>
> The justification for CTF is and will remain - a compact, faster debug format
> for type information and support some online debugging use-cases (like
> backtraces) in future.
>
> > but I was more interested in a comparison between
> > CTF and a DWARF subset containing exactly only what you have available in
> > CTF.  Because if DWARF with everything-you-don't-need stripped out
> > is in the same ballpark, then I am puzzled on why add/maintain a new
> > Debug format, with all the duplication of effort that entails going
> > forward.
>
> I shared some numbers on this in the previous emails in this thread. I thought
> comparing DWARF's de-duplication-amenable offering (using
> -fdebug-types-section) will be useful in this context.
>
> For binaries compiled with -fdebug-types-section -gdwarf-4, here is some data.
> The CTF sections are generated with dwarf2ctf because CTF link-time de-dup is
> being worked on currently. The end result of link-time CTF de-dup is expected
> to be at par with these .ctf section sizes.
>
> The .ctf section sizes below include the CTF string table (.debug_str is
> excluded from the calculations however):
>
> (coreutils-0.22)
> .debug_info(D1) | .debug_abbrev(D2) | .debug_str | .debug_types(D3) | 
> .ctf (uncompressed) | ratio (.ctf/(D1+D2+D3))
> ls  109806 |  18876|  22042 |  12413   |   
> 26240 | 0.18
> pwd 27902  |  7914 |  10851 |  5753|   
> 13929 | 0.33
> groups 26920   |  8173 |  10674 |  5070|   
> 13378 | 0.33
>
> (emacs-26.3)
> .debug_info(D1) | .debug_abbrev(D2) | .debug_str | .debug_types(D3) | 
> .ctf (uncompressed) | ratio (.ctf/(D1+D2+D3))
> emacs 3755083  |   202926  |  431926|   143462 |   
> 273910| 0.06
>
>
> It is not easy to get an estimate of 'DWARF with everything-you-don't-need
> stripped out'. At this time, I don't know of an easy way to make this 
> comparison
> more meaningful. Any suggestions ?

There's a mechanism to get type (and decl - I suppose CTF also
contains debug info
for function declarations not only its type?) info as part of early
debug generation.
The attached "hack" simply mangles dwarf2out to output this early info as the
only debug info (only verified on a small .c file).  We still have things like
file, line and column numbers for entities (not sure if CTF has those).

It should be possible to "hide" the hack behind a -gdwarf-like-ctf or similar.
I guess -g0.5 isn't desirable and we've taken both -g0 and -g1 already...
(and -g1 doesn't include types but just decls).

Richard.

> > Also, it's my understanding that the current CTF format doesn't yet
> > support C++, Vector registers, etc., maybe other things, so if DWARF
> > was sufficient for your needs, then in the long run it sounds like
> > a better option to me, as then you wouldn't have to extend CTF _and_
> > DWARF whenever some feature is needed.
>
> Yes, CTF does not support C++ at this time. To cover all of C (including
> GNU C extensions), we need to add representation for things like Vector type,
> non IEEE float etc. (somewhat infrequently occurring constructs)
>
> The issue is not that DWARF cannot represent the required type information.
> DWARF is voluminous and secondly, the current workflow to get to CTF from
> source programs without direct toolchain support is tiresome and lengthy.
>
> For current and future users of CTF, having the support for the format in the
> toolchain is the best way to promote adoption and enhance community 
> experience.
>
> > Maybe it would make sense to work on integrating CTF into the DWARF
> > standard itself, not sure?
> >
> > I was also curious on your plans for adding unwinding support to CTF,
> > while the kernel (the main CTF user, IIUC), already has plans to
> > use its own unwinding format (ORC)?
>
> Kernel's unwinding format (ORC) helps generate backtrace with fun

Re: [libgomp][testsuite] PR testsuite/91884 Add -lquadmath if available

[Jakub Jelinek]

On Tue, Oct 08, 2019 at 08:33:03PM +0200, Tobias Burnus wrote:
>   libgomp/
>   * testsuite/libgomp.fortran/fortran.exp: Add -lquadmath if available.
>   * testsuite/libgomp.oacc-fortran/fortran.exp: Ditto.
> 
> diff --git a/libgomp/testsuite/libgomp.fortran/fortran.exp 
> b/libgomp/testsuite/libgomp.fortran/fortran.exp
> index d848ed4d47f..caffbfe0346 100644
> --- a/libgomp/testsuite/libgomp.fortran/fortran.exp
> +++ b/libgomp/testsuite/libgomp.fortran/fortran.exp
> @@ -54,11 +54,15 @@ if { $lang_test_file_found } {
>   # Allow for spec subsitution.
>   lappend ALWAYS_CFLAGS 
> "additional_flags=-B${blddir}/${quadmath_library_path}/"
>   set ld_library_path 
> "$always_ld_library_path:${blddir}/${lang_library_path}:${blddir}/${quadmath_library_path}"
> + append lang_link_flags " -lquadmath"
>   } else {
>   set ld_library_path 
> "$always_ld_library_path:${blddir}/${lang_library_path}"
>   }
>  } else {
>  set ld_library_path "$always_ld_library_path"
> +if { [check_no_compiler_messages has_libquadmath executable {int 
> main() {return 0;}} "-lgfortran -lquadmath"] } then {

Can you please split this line?  I know the above lines are quite long too,
but they at least have long strings that aren't easy to split.
While the check_no_compiler_messages are split very commonly in
target-supports.exp, like:
return [check_no_compiler_messages libatomic_available executable {
int main (void) { return 0; }
} "-latomic"]

> +append lang_link_flags " -lquadmath"
>  } else {
>  set ld_library_path "$always_ld_library_path"
> +if { [check_no_compiler_messages has_libquadmath executable {int 
> main() {return 0;}} "-lgfortran -lquadmath"] } then {
> +append lang_link_flags " -lquadmath"
> +}

Ditto.  Ok with that change.

Jakub

Re: Type representation in CTF and DWARF

[Jakub Jelinek]

On Wed, Oct 09, 2019 at 09:41:09AM +0200, Richard Biener wrote:
> There's a mechanism to get type (and decl - I suppose CTF also
> contains debug info
> for function declarations not only its type?) info as part of early
> debug generation.
> The attached "hack" simply mangles dwarf2out to output this early info as the
> only debug info (only verified on a small .c file).  We still have things like
> file, line and column numbers for entities (not sure if CTF has those).
> 
> It should be possible to "hide" the hack behind a -gdwarf-like-ctf or similar.
> I guess -g0.5 isn't desirable and we've taken both -g0 and -g1 already...
> (and -g1 doesn't include types but just decls).

Yeah.  And if location info isn't in CTF, you can as well add an early
return in add_src_coords_attributes, like it has one for UNKNOWN_LOCATION
already.  Or if it is there, but just file/line and not column, you can use
-gno-column-info.  As has been mentioned earlier, you can use dwz utility
post-linking instead of -fdebug-types-section.

Jakub

Re: GCC wwwdocs move to git done

[Thomas Schwinge]

Hi Joseph!

On 2019-10-09T00:27:38+, Joseph Myers  wrote:
> I've done the move of GCC wwwdocs to git

Thanks!  And now, ;-) as promised:

# apt-get --purge remove cvs
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  cvs*
0 upgraded, 0 newly installed, 1 to remove and 10 not upgraded.
After this operation, 4706 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 347879 files and directories currently installed.)
Removing cvs (2:1.12.13+real-27) ...
Processing triggers for install-info (6.5.0.dfsg.1-4+b1) ...
Processing triggers for man-db (2.8.5-2) ...
(Reading database ... 347817 files and directories currently installed.)
Purging configuration files for cvs (2:1.12.13+real-27) ...
Removing group `_cvsadmin' ...
Done.


> --- a/htdocs/about.html
> +++ b/htdocs/about.html

> + git clone 
> git+ssh://username@gcc.gnu.org/sourceware/projects/gcc-home/wwwdocs.git
> + where username is your user name at gcc.gnu.org

Confirmed.


Grüße
 Thomas


signature.asc
Description: PGP signature

Re: [PR 70929] IPA call type compatibility fix/workaround

[Richard Biener]

On Tue, 8 Oct 2019, Martin Jambor wrote:

> Hi,
> 
> I've been looking at PR 70929 and at the newly reported duplicate PR
> 91988 and would like to propose the following patch to address them.
> Basically, the idea is that if the types or arguments in TYPE_ARG_TYPES
> (as opposed to DECL_ARGUMENTS) from both the type from the target fndecl
> and from call statement fntype match, then we can assume that whatever
> promotions happened to the arguments they are the same in all
> compilation units and the calls will be compatible.  I inserted this
> test in the middle of gimple_check_call_args and it works for testcase
> from both bugs.
> 
> The new test of course can be fooled with programs with clearly
> undefined behavior, for example by having an indirect call which early
> optimizations would discover to call an incompatible functions - but the
> change considered in comment #5 of the bug would be too.  Moreover,
> unless we stream argument types one will always be able to fool the
> compiler and I find being careful about those and not inlining valid
> calls with references to TREE_ADDRESSABLE classes a bad tradeoff.
> 
> I verified that - at least on gcc/libstdc++ testsuites - the new
> gimple_check_call_args never returns false when the old one would return
> true.  I can imagine us not doing the
> 
>   fold_convertible_p (TREE_VALUE (f), arg)
> 
> bit or returning false whenever reach the line
> 
>   tree p;
> 
> and the function has any parameters at all.  This would make the
> function return false for on un-prototyped and/or K&R function
> declarations, but perhaps we don't care too much?
> 
> In any event, I have bootstrapped and tested this on x86_64-linux, is it
> perhaps OK for trunk?
> 
> Martin
> 
> 
> 2019-10-03  Martin Jambor  
> 
>   PR lto/70929
>   * cgraph.c (gimple_check_call_args): Also compare types of argumen
>   types and call statement fntype types.
> 
>   testsuite/
>   * g++.dg/lto/pr70929_[01].C: New test.
> ---
>  gcc/cgraph.c | 83 ++--
>  gcc/testsuite/g++.dg/lto/pr70929_0.C | 18 ++
>  gcc/testsuite/g++.dg/lto/pr70929_1.C | 10 
>  3 files changed, 95 insertions(+), 16 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/lto/pr70929_0.C
>  create mode 100644 gcc/testsuite/g++.dg/lto/pr70929_1.C
> 
> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> index 0c3c6e7cac4..5a4c5253b49 100644
> --- a/gcc/cgraph.c
> +++ b/gcc/cgraph.c
> @@ -3636,26 +3636,19 @@ cgraph_node::get_fun () const
>  static bool
>  gimple_check_call_args (gimple *stmt, tree fndecl, bool args_count_match)
>  {
> -  tree parms, p;
> -  unsigned int i, nargs;
> -
>/* Calls to internal functions always match their signature.  */
>if (gimple_call_internal_p (stmt))
>  return true;
>  
> -  nargs = gimple_call_num_args (stmt);
> +  unsigned int nargs = gimple_call_num_args (stmt);
>  
> -  /* Get argument types for verification.  */
> -  if (fndecl)
> -parms = TYPE_ARG_TYPES (TREE_TYPE (fndecl));
> -  else
> -parms = TYPE_ARG_TYPES (gimple_call_fntype (stmt));
> -
> -  /* Verify if the type of the argument matches that of the function
> - declaration.  If we cannot verify this or there is a mismatch,
> - return false.  */
> +  /* If we have access to the declarations of formal parameters, match 
> against
> + those.  */
>if (fndecl && DECL_ARGUMENTS (fndecl))
>  {
> +  unsigned int i;
> +  tree p;
> +
>for (i = 0, p = DECL_ARGUMENTS (fndecl);
>  i < nargs;
>  i++, p = DECL_CHAIN (p))
> @@ -3676,17 +3669,75 @@ gimple_check_call_args (gimple *stmt, tree fndecl, 
> bool args_count_match)
>   }
>if (args_count_match && p)
>   return false;
> +
> +  return true;
>  }
> -  else if (parms)
> +
> +  /* If we don't have decls of formal parameters, see if we have both the 
> type
> + of the callee arguments in the fntype of the call statement and compare
> + those.  We rely on the fact that whatever promotions happened to
> + declarations for exactly the same sequence of types of parameters also
> + happened on the callee side.  */
> +  if (fndecl
> +  && TYPE_ARG_TYPES (TREE_TYPE (fndecl))
> +  && TYPE_ARG_TYPES (gimple_call_fntype (stmt)))
>  {
> -  for (i = 0, p = parms; i < nargs; i++, p = TREE_CHAIN (p))
> +  unsigned int arg_idx = 0;
> +  for (tree f = TYPE_ARG_TYPES (TREE_TYPE (fndecl)),
> +  s = TYPE_ARG_TYPES (gimple_call_fntype (stmt));
> +f || s;
> +f = TREE_CHAIN (f), s = TREE_CHAIN (s), arg_idx++)
>   {
> +   if (!f
> +   || !s
> +   || TREE_VALUE (f) == error_mark_node
> +   || TREE_VALUE (s) == error_mark_node)
> + return false;
> +   if (TREE_CODE (TREE_VALUE (f)) == VOID_TYPE)
> + {
> +   if (TREE_CODE (TREE_VALUE (s)) != VOID_TYPE
> +   || arg_idx != nargs)
> + return false;
> +   else
> +

Re: [libgomp][testsuite] PR testsuite/91884 Add -lquadmath if available

[Tobias Burnus]

I have also an alternative version:

* For in-build-dir test runs, do as with previous patch, i.e. add 
"-lquadmath" to the "xgcc" call if the directory is available.


* For installed-compiler test runs, the new patch uses 
GFORTRAN_UNDER_TEST / GXX_UNDER_TEST
(It would also use them with in-build-dir runs, but nothing sets them. I 
have kept the -lgfortran / -lstdg++ flags, though they could be left out 
iff {GXX,GFORTRAN}_UNDER_TEST is set. Presumably, some linker will 
complain if they appear twice.)


Additionally, that patch does some cleanup:
* Only set always_ld_library_path to a blddir path if it exists
* Replace lang_test_file by (existing) lang_test_file_found in lib/*exp

That patch is based on a subset of patches posted by Thomas, extended to 
the new files; cf. PR or:


https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01374.html
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00157.html


What do you think? Which variant do you prefer? If the other one, should 
some cleanup of this patch be used nonetheless?


Tobias

PS: Tested with an in-build-tree test run and an installed-compiler test 
run on x86_64_gnu-linux


	2019-...  Tobias Burnus  
		  Thomas Schwinge  

	libgomp/
	* testsuite/lib/libgomp.exp (libgomp_init): Add blddir to
	always_ld_library_path only if it exists.
	(libgomp_target_compile): Use lang_test_file_found instead of
	lang_test_file and don't set compiler=.
	* testsuite/libgomp.c/c.exp: Do not set lang_test_file;
	unset lang_test_file_found for initialization.
	* testsuite/libgomp.hsa.c/c.exp: Likewise.
	* testsuite/libgomp.oacc-c/c.exp: Likewise.
	* testsuite/libgomp.graphite/graphite.exp: Likewise.
	* testsuite/libgomp.c++/c++.exp: Likewise; use GXX_UNDER_TEST
	if available.
	* testsuite/libgomp.oacc-c++/c++.exp: Likewise.
	* testsuite/libgomp.fortran/fortran.exp: Likewise but using
	GFORTRAN_UNDER_TEST.
	* testsuite/libgomp.oacc-fortran/fortran.exp: Likewise.

diff --git a/libgomp/testsuite/lib/libgomp.exp b/libgomp/testsuite/lib/libgomp.exp
index 14d9b5f1305..86c97239579 100644
--- a/libgomp/testsuite/lib/libgomp.exp
+++ b/libgomp/testsuite/lib/libgomp.exp
@@ -63,7 +63,6 @@ proc libgomp_init { args } {
 global srcdir blddir objdir tool_root_dir
 global libgomp_initialized
 global tmpdir
-global blddir
 global gluefile wrap_flags
 global ALWAYS_CFLAGS
 global CFLAGS
@@ -115,7 +114,7 @@ proc libgomp_init { args } {
 }
 
 # Compute what needs to be put into LD_LIBRARY_PATH
-set always_ld_library_path ".:${blddir}/.libs"
+set always_ld_library_path "."
 
 # Add liboffloadmic build directory in LD_LIBRARY_PATH to support
 # Intel MIC offloading testing.
@@ -166,6 +165,8 @@ proc libgomp_init { args } {
 lappend ALWAYS_CFLAGS "additional_flags=-B${blddir}/.libs"
 lappend ALWAYS_CFLAGS "additional_flags=-I${blddir}"
 lappend ALWAYS_CFLAGS "ldflags=-L${blddir}/.libs"
+
+append always_ld_library_path ":${blddir}/.libs"
 }
 # The top-level include directory, for gomp-constants.h.
 lappend ALWAYS_CFLAGS "additional_flags=-I${srcdir}/../../include"
@@ -241,13 +242,13 @@ proc libgomp_target_compile { source dest type options } {
 global gluefile wrap_flags
 global ALWAYS_CFLAGS
 global GCC_UNDER_TEST
-global lang_test_file
+global lang_test_file_found
 global lang_library_path
 global lang_link_flags
 global lang_include_flags
 global lang_source_re
 
-if { [info exists lang_test_file] } {
+if { [info exists lang_test_file_found] } {
 if { $blddir != "" } {
 # Some targets use libgfortran.a%s in their specs, so they need
 # a -B option for uninstalled testing.
@@ -268,7 +269,6 @@ proc libgomp_target_compile { source dest type options } {
 
 lappend options "additional_flags=[libio_include_flags]"
 lappend options "timeout=[timeout_value]"
-lappend options "compiler=$GCC_UNDER_TEST"
 
 set options [concat $libgomp_compile_options $options]
 
diff --git a/libgomp/testsuite/libgomp.c++/c++.exp b/libgomp/testsuite/libgomp.c++/c++.exp
index f4884e2ffa7..cab9e4eac2e 100644
--- a/libgomp/testsuite/libgomp.c++/c++.exp
+++ b/libgomp/testsuite/libgomp.c++/c++.exp
@@ -5,8 +5,10 @@ global shlib_ext
 
 set shlib_ext [get_shlib_extension]
 set lang_link_flags "-lstdc++"
-set lang_test_file_found 0
 set lang_library_path "../libstdc++-v3/src/.libs"
+if [info exists lang_test_file_found] then {
+unset lang_test_file_found
+}
 if [info exists lang_include_flags] then {
 unset lang_include_flags
 }
@@ -27,30 +29,28 @@ lappend ALWAYS_CFLAGS "additional_flags=-fopenmp"
 set SAVE_GCC_UNDER_TEST "$GCC_UNDER_TEST"
 set GCC_UNDER_TEST "$GCC_UNDER_TEST -x c++"
 
-set blddir [lookfor_file [get_multilibs] libgomp]
-
-
 if { $blddir != "" } {
 # Look for a static libstdc++ first.
 if [file exists "${blddir}/${lang_library_path}/libstdc++.a"] {
-set lang_test_file "${lang_library_path}/libstdc++.a"

[Patch] gcc-10/changes.html – mention OpenMP's use_device_addr support

[Tobias Burnus]

This mentioned the recently added OpenMP 5 feature "use_device_addr" 
which complements the (for Fortran) underspecified "use_device_ptr". The 
rest of the message, I have taken and modified from gcc-7/changes.html. 
– [On the C/C++, ME and libgomp side, OpenMP 4.5 is supported and 5.0 
partially.]


Comments?

Note: The webpages are now in GIT, cf. 
https://gcc.gnu.org/about.html#git + recent gcc-patches@ announcement.


Tobias

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index c8e4c81f..b4b5f687 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -107,6 +107,12 @@ a work-in-progress.
 
 Fortran
 
+  use_device_addr of version 5.0 of the
+  https://www.openmp.org/specifications/";>OpenMP specification
+  is now supported; note that otherwise OpenMP 4.5 is partially supported
+  in the Fortran compiler; the largest missing item is structure element
+  mapping.
+  
   
 The default buffer size for I/O using unformatted files has been
 increased to 1048576.  The buffer size for can now be set at

Re: [libgomp][testsuite] PR testsuite/91884 Add -lquadmath if available

[Tobias Burnus]

Thanks for the review. I have now committed this version as r276754 
(with splitting the long line).


If someone prefers the other variant or bits of it, I will do it as 
follow up.


Cheers,

Tobias

On 10/9/19 9:43 AM, Jakub Jelinek wrote:

On Tue, Oct 08, 2019 at 08:33:03PM +0200, Tobias Burnus wrote:

libgomp/
* testsuite/libgomp.fortran/fortran.exp: Add -lquadmath if available.
* testsuite/libgomp.oacc-fortran/fortran.exp: Ditto.

diff --git a/libgomp/testsuite/libgomp.fortran/fortran.exp 
b/libgomp/testsuite/libgomp.fortran/fortran.exp
index d848ed4d47f..caffbfe0346 100644
--- a/libgomp/testsuite/libgomp.fortran/fortran.exp
+++ b/libgomp/testsuite/libgomp.fortran/fortran.exp
@@ -54,11 +54,15 @@ if { $lang_test_file_found } {
# Allow for spec subsitution.
lappend ALWAYS_CFLAGS 
"additional_flags=-B${blddir}/${quadmath_library_path}/"
set ld_library_path 
"$always_ld_library_path:${blddir}/${lang_library_path}:${blddir}/${quadmath_library_path}"
+   append lang_link_flags " -lquadmath"
} else {
set ld_library_path 
"$always_ld_library_path:${blddir}/${lang_library_path}"
}
  } else {
  set ld_library_path "$always_ld_library_path"
+if { [check_no_compiler_messages has_libquadmath executable {int main() {return 
0;}} "-lgfortran -lquadmath"] } then {

Can you please split this line?  I know the above lines are quite long too,
but they at least have long strings that aren't easy to split.
While the check_no_compiler_messages are split very commonly in
target-supports.exp, like:
 return [check_no_compiler_messages libatomic_available executable {
 int main (void) { return 0; }
 } "-latomic"]


+append lang_link_flags " -lquadmath"
  } else {
  set ld_library_path "$always_ld_library_path"
+if { [check_no_compiler_messages has_libquadmath executable {int main() {return 
0;}} "-lgfortran -lquadmath"] } then {
+append lang_link_flags " -lquadmath"
+}

Ditto.  Ok with that change.

Jakub

Re: [PATCH 2/2][MSP430] Optimize zero_extend insns and PSImode pointer manipulation

[Segher Boessenkool]

Hi Jozef,

On Tue, Oct 08, 2019 at 11:39:57AM +0100, Jozef Lawrynowicz wrote:
> +;; 
> +;; ZERO EXTEND INSTRUCTIONS
> +;; Byte-writes to registers clear bits 19:8
> +;;   * Byte-writes to memory do not affect bits 15:8
> +;; Word-writes to registers clear bits 19:16
> +;; PSImode writes to memory clear bits 16:4 of the second memory word

Should that be 15:4 instead?

> +; FIXME many of these should be unnnecessary once combine deals with
> +; (sign_extend (zero_extend)) or (sign_extend (subreg)) BZ 91865.

I have looked at it some time ago, and it is quite hard :-/  It's not
forgotten though!


Segher

Re: [PATCH 1/2][vect]PR 88915: Vectorize epilogues when versioning loops

[Richard Biener]

On Tue, 8 Oct 2019, Andre Vieira (lists) wrote:

> Hi Richard,
> 
> As I mentioned in the IRC channel, I managed to get "most" of the regression
> testsuite working for x86_64 (avx512) and aarch64.
> 
> On x86_64 I get a failure that I can't explain, was hoping you might be able
> to have a look with me:
> "PASS->FAIL: gcc.target/i386/vect-perm-odd-1.c execution test"
> 
> vect-perm-odd-1.exe segfaults and when I gdb it seems to be the first
> iteration of the main loop.  The tree dumps look alright, but I do notice the
> stack usage seems to change between --param vect-epilogue-nomask={0,1}.

So the issue is that we have

=> 0x00400778 <+72>:vmovdqa64 %zmm1,-0x40(%rax)

but the memory accessed is not appropriately aligned.  The vectorizer
sets DECL_USER_ALIGN on the stack local but somehow later it downs
it to 256:

Old value = 640
New value = 576
ensure_base_align (dr_info=0x526f788) at 
/tmp/trunk/gcc/tree-vect-stmts.c:6294
6294  DECL_USER_ALIGN (base_decl) = 1;
(gdb) l
6289  if (decl_in_symtab_p (base_decl))
6290symtab_node::get (base_decl)->increase_alignment 
(align_base_to);
6291  else
6292{
6293  SET_DECL_ALIGN (base_decl, align_base_to);
6294  DECL_USER_ALIGN (base_decl) = 1;
6295}

this means vectorizing the epilogue modifies the DRs, in particular
the base alignment?

> Am I missing to update some field that may later lead to the amount of stack
> being used? I am confused, it could very well be that I am missing something
> obvious, I am not too familiar with x86's ISA. I will try to investigate
> further.
> 
> This patch needs further clean-up and more comments (or comment updates), but
> I thought I'd share current state to see if you can help me unblock.
> 
> Cheers,
> Andre
> 

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

Re: Type representation in CTF and DWARF

[Segher Boessenkool]

On Tue, Oct 08, 2019 at 10:26:13PM -0700, Indu Bhagat wrote:
> The justification for CTF is and will remain - a compact, faster debug 
> format
> for type information and support some online debugging use-cases (like
> backtraces) in future.

Approximate backtraces, sure.  (It cannot know if another frame has been
stacked by the current function already, or not).


Segher

Re: [Patch] gcc-10/changes.html – mention OpenMP's use_device_addr support

[Gerald Pfeifer]

On Wed, 9 Oct 2019, Tobias Burnus wrote:
> This mentioned the recently added OpenMP 5 feature "use_device_addr" 
> which complements the (for Fortran) underspecified "use_device_ptr". The 
> rest of the message, I have taken and modified from gcc-7/changes.html. 

Please use  instead of  and break the sentence with a full
stop before "note" (to avoid two semicolons).

Thanks for this update, and okay with the above.

> Note: The webpages are now in GIT, cf. https://gcc.gnu.org/about.html#git +
> recent gcc-patches@ announcement.

And yours is the very first patch I am processing in the new world. :-)
Congrats!

Gerald

Re: [PATCH, rs6000] Lower vec_promote_demote vectorization cost for P8/P9

[Segher Boessenkool]

Hi Kewen,

On Wed, Oct 09, 2019 at 02:43:02PM +0800, Kewen.Lin wrote:
> This patch is to lower vec_promote_demote vectorization cost in
> rs6000_builtin_vectorization_cost.  It's similar to what we committed
> for vec_perm, the current cost for vec_promote_demote is also
> overpriced for Power8 and Power9 since Power8 and Power9 has
> supported more units for permute/unpack/pack rather than single one
> on Power7.
> 
> The performance evaluation on SPEC2017 Power9 shows +2.88% gain on
> 525.x264_r, degraded -1.70% on 526.blender_r but which has been
> identified as just exposing some other issues and actually unrelated,
> while SPEC2017 Power8 evaluation shows +4.63% gain on 525.x264_r 
> without any significant degradations, SPEC2006 Power8 evaluation 
> shows 1.99% gain on 453.povray.  The geomean gain for SPEC2017
> on both Power8 and Power9 is +0.06%, and it's unchanged for SPEC2006
> Power8.

Small steps :-)

The patch is okay for trunk.  Thank you!


Segher


>   * config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Lower
>   vec_promote_demote cost to 1 for non-Power7 VSX architectures.

Re: GCC wwwdocs move to git done

[Jonathan Wakely]

On Wed, 9 Oct 2019 at 01:28, Joseph Myers wrote:
>
> I've done the move of GCC wwwdocs to git (using the previously posted and
> discussed scripts), including setting up the post-receive hook to do the
> same things previously covered by the old CVS hooks, and minimal updates
> to the web pages dealing with the CVS setup for wwwdocs.

Thanks, Joseph.

I just pushed a change and although it worked and appeared on
gcc.gnu.org, I got an error message during the push:

remote: hooks/post-receive: line 14: /www/gcc/updatelog: Permission denied
remote:   Updating /www/gcc/htdocs/gcc-10/changes.html

Re: [patch][Fortran] Actually permit OpenMP's 'target simd'

[Thomas Schwinge]

Hi!

Tobias, if that's not inconvenient for you for any reson (which?), would
you please adopt the habit of using the same text for a commit's first
line in the log message (r276698: "Fortran - fix OpenMP 'target simd'),
and the email's "Subject" line ("[Fortran] Actually permit OpenMP's
'target simd'").  That's less typing for you ;-) -- and more importantly,
makes it easy to find one from the other.


On 2019-10-09T08:04:29+0200, Bernhard Reutner-Fischer  
wrote:
> On 8 October 2019 14:12:47 CEST, Jakub Jelinek  wrote:
>>On Tue, Oct 08, 2019 at 02:04:17PM +0200, Tobias Burnus wrote:
>>> Seemingly, 'target simd' was forgotten – which yielded the error:
>>> "Unexpected !$OMP TARGET SIMD statement"

Shouldn't this get a PR opened, and the fix eventually backported also to
release branches?

(Note that at least for OpenACC changes, we're way, way behind on such
backports...)


> What is the reasoning to call the nonstandard abort instead if the usual STOP 
> N?

(ACK, that works.)


Grüße
 Thomas


signature.asc
Description: PGP signature

Re: C++ PATCH for C++20 P0388R4 (conversions to arrays of unknown bounds) and CWG 1307 (c++/91364, c++/69531)

[Jonathan Wakely]

On 07/10/19 14:56 -0400, Jason Merrill wrote:

On 10/7/19 1:42 PM, Marek Polacek wrote:

@@ -7401,8 +7432,20 @@ convert_like_real (conversion *convs, tree expr, tree 
fn, int argnum,
  error_at (loc, "cannot bind non-const lvalue reference of "
"type %qH to an rvalue of type %qI", totype, extype);
else if (!reference_compatible_p (TREE_TYPE (totype), extype))
- error_at (loc, "binding reference of type %qH to %qI "
-   "discards qualifiers", totype, extype);
+ {
+   /* If we're converting from T[] to T[N], don't talk
+  about discarding qualifiers.  (Converting from T[N] to
+  T[] is allowed by P0388R4.)  */
+   if (TREE_CODE (extype) == ARRAY_TYPE
+   && TYPE_DOMAIN (extype) == NULL_TREE
+   && TREE_CODE (TREE_TYPE (totype)) == ARRAY_TYPE
+   && TYPE_DOMAIN (TREE_TYPE (totype)) != NULL_TREE)
+ error_at (loc, "binding reference of type %qH to %qI "
+   "discards array bounds", totype, extype);


If we're converting to T[N], that would be adding, not discarding, 
array bounds?


I don't think the diagnostic would be very good if we say "adds array
bounds" though. How about being consistent with the existing error for
similar cases?

a.cc:4:17: error: invalid initialization of reference of type ‘int (&)[3]’ from 
expression of type ‘int []’
  int (&b)[3] = a;
^

Re: [Patch, fortran] PR91926 - assumed rank optional

[Christophe Lyon]

Hi,


On Sat, 5 Oct 2019 at 20:31, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:

> I must apologise not posting this before committing. I left for a
> vacation this morning and I thought that this problem and the one
> posted by Gilles were best fixed before departing. The patch only
> touches the new ISO_Fortran binding feature and so I thought that I
> would be safe to do this.
>
> It was fully regtested and only applies to trunk.
>
> Paul
>
> Author: pault
> Date: Sat Oct  5 08:17:55 2019
> New Revision: 276624
>
> URL: https://gcc.gnu.org/viewcvs?rev=276624&root=gcc&view=rev
> Log:
> 2019-10-05  Paul Thomas  
>
> PR fortran/91926
> * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Correct the
> assignment of the attribute field to account correctly for an
> assumed shape dummy. Assign separately to the gfc and cfi
> descriptors since the atribute can be different. Add btanch to
> correctly handle missing optional dummies.
>
> 2019-10-05  Paul Thomas  
>
> PR fortran/91926
> * gfortran.dg/ISO_Fortran_binding_13.f90 : New test.
> * gfortran.dg/ISO_Fortran_binding_13.c : Additional source.
> * gfortran.dg/ISO_Fortran_binding_14.f90 : New test.
>
> 2019-10-05  Paul Thomas  
>
> PR fortran/91926
> * runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc): Do not
> modify the bounds and offset for CFI_other.
>
> Added:
> trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_13.c
> trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_13.f90
> trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_14.f90
> Modified:
> trunk/gcc/fortran/ChangeLog
> trunk/gcc/fortran/trans-expr.c
> trunk/gcc/testsuite/ChangeLog
> trunk/libgfortran/ChangeLog
> trunk/libgfortran/runtime/ISO_Fortran_binding.c
>


Since this was committed (r276624), I have noticed regressions on
arm-linux-gnueabihf:
FAIL: gfortran.dg/ISO_Fortran_binding_11.f90   -O3 -g  execution test
I've seen other reports on gcc-testresults too.

Christophe

Re: [patch][Fortran] Actually permit OpenMP's 'target simd'

[Jakub Jelinek]

On Wed, Oct 09, 2019 at 11:46:37AM +0200, Thomas Schwinge wrote:
> On 2019-10-09T08:04:29+0200, Bernhard Reutner-Fischer  
> wrote:
> > On 8 October 2019 14:12:47 CEST, Jakub Jelinek  wrote:
> >>On Tue, Oct 08, 2019 at 02:04:17PM +0200, Tobias Burnus wrote:
> >>> Seemingly, 'target simd' was forgotten – which yielded the error:
> >>> "Unexpected !$OMP TARGET SIMD statement"
> 
> Shouldn't this get a PR opened, and the fix eventually backported also to
> release branches?

Not sure about that.  target simd is an OpenMP 4.5 feature, and we've never
claimed OpenMP 4.5 is fully implemented in GCC 9 or earlier, so I think it
is fine if it is just one of several missing 4.5 features implemented in
GCC 10.  If we've accepted target simd, fine, it would be a bug fix, but my
understanding is that because of this bug we've not really supported it.

The actual problem is that the
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01125.html
patch wasn't accompanied by sufficient test coverage, some of it has been later
covered, like taskloop/taskloop simd, but most of it has not, because I
eventually got busy with non-OpenMP stuff that year.
In particular, we don't have any testsuite coverage for
target enter data
target exit data
target parallel
target parallel do
target parallel do simd
(for target simd we now have some) just from the above patch.  The plan was
basically to port the C/C++ testcases from the OpenMP 4.5 submission, so
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01291.html
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00477.html
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01835.html
to Fortran, but that never happened, like finishing the 4.5 support.

Jakub

Re: [Patch 1/2][ipa] Add target hook to sanitize cloned declaration's attributes

[Andre Vieira (lists)]

Hi Martin,

Thanks for the suggestion.  I have moved the target hook to the 
following functions:

'create_clone'
'create_version_clone'
'create_version_clone_with_body'

I looked for all 'cgraph_node::create_*' functions and added the target 
hook to them. The exception is 'create_virtual_clone' which calls 
'create_clone' so it should be caught there.


Is this OK for trunk?

Cheers,
Andre

gcc/ChangeLog:

2019-10-09  Andre Vieira  

* cgraphclones.c(create_clone): Call new target hook when
creating a new node.
(create_version_clone): Likewise.
(create_version_clone_with_body): Likewise.
* target.def(sanitize_clone_attributes): New target hook.
* targhooks.c(default_sanitize_clone_attributes): New.
* targhooks.h(default_sanitize_clone_attributes): New.
* doc/tm.texi.in: Document new target hook.
* doc/tm.texi: Regenerated

On 08/10/2019 17:27, Martin Jambor wrote:

Hi,

On Tue, Oct 08 2019, Andre Vieira (lists) wrote:

Hi,

This patch adds a new target hook called
TARGET_HOOK_SANITIZE_CLONE_ATTRIBUTES.  This hook is meant to give each
target the ability to sanitize a cloned's declaration attribute list.


Is this OK for trunk?

Cheers,
Andre

gcc/ChangeLog:

2019-10-08  Andre Vieira  

* ipa-cp.c(create_specialized_node): Call new target hook when
  creating a new node.


I'm quite sure you don't want to call the hook here but from within
cgraph_node::create_virtual_clone (and perhaps also
cgraph_node::create_version_clone_with_body?), if only now there are two
passes creating clones and there may easily be more in the future.

Thanks,

Martin


  * target.def(sanitize_clone_attributes): New target hook.
  * targhooks.c(default_sanitize_clone_attributes): New.
  * targhooks.h(default_sanitize_clone_attributes): New.
  * doc/tm.texi.in: Document new target hook.
  * doc/tm.texi: Regenerated
diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index 909407b9a71690fe7b6ce731e5ddaa06af6d4410..84a8801c94c8810470e1cae2141452b22643bb24 100644
--- a/gcc/cgraphclones.c
+++ b/gcc/cgraphclones.c
@@ -80,6 +80,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-inline.h"
 #include "dumpfile.h"
 #include "gimple-pretty-print.h"
+#include "target.h"
 
 /* Create clone of edge in the node N represented by CALL_EXPR
the callgraph.  */
@@ -407,6 +408,8 @@ cgraph_node::create_clone (tree new_decl, profile_count prof_count,
   if (!new_inlined_to)
 dump_callgraph_transformation (this, new_node, suffix);
 
+  targetm.sanitize_clone_attributes (new_node);
+
   return new_node;
 }
 
@@ -889,6 +892,8 @@ cgraph_node::create_version_clone (tree new_decl,
 
dump_callgraph_transformation (this, new_version, suffix);
 
+   targetm.sanitize_clone_attributes (new_version);
+
return new_version;
  }
 
@@ -1004,6 +1009,9 @@ cgraph_node::create_version_clone_with_body
   update_call_expr (new_version_node);
 
   symtab->call_cgraph_insertion_hooks (new_version_node);
+
+  targetm.sanitize_clone_attributes (new_version_node);
+
   return new_version_node;
 }
 
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index a86c210d4fe390bd0356b6e50ba7c6c34a36239a..5c1149ccf47576d8d803d1ab712f6f1b9342d74c 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -12039,6 +12039,11 @@ If defined, this function returns an appropriate alignment in bits for an atomic
 ISO C11 requires atomic compound assignments that may raise floating-point exceptions to raise exceptions corresponding to the arithmetic operation whose result was successfully stored in a compare-and-exchange sequence.  This requires code equivalent to calls to @code{feholdexcept}, @code{feclearexcept} and @code{feupdateenv} to be generated at appropriate points in the compare-and-exchange sequence.  This hook should set @code{*@var{hold}} to an expression equivalent to the call to @code{feholdexcept}, @code{*@var{clear}} to an expression equivalent to the call to @code{feclearexcept} and @code{*@var{update}} to an expression equivalent to the call to @code{feupdateenv}.  The three expressions are @code{NULL_TREE} on entry to the hook and may be left as @code{NULL_TREE} if no code is required in a particular place.  The default implementation leaves all three expressions as @code{NULL_TREE}.  The @code{__atomic_feraiseexcept} function from @code{libatomic} may be of use as part of the code generated in @code{*@var{update}}.
 @end deftypefn
 
+@deftypefn {Target Hook} void TARGET_SANITIZE_CLONE_ATTRIBUTES (struct cgraph_node *@var{})
+This target hook sanitizes the cloned @code{*@var{node}} declaration
+attributes.
+@end deftypefn
+
 @deftypefn {Target Hook} void TARGET_RECORD_OFFLOAD_SYMBOL (tree)
 Used when offloaded functions are seen in the compilation unit and no named
 sections are available.  It is called once for each symbol that must be
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 06dfcda35abea7396c288a59c38e

Re: [Patch, fortran] PR91926 - assumed rank optional

[Paul Richard Thomas]

Hi Christophe,

Thanks for flagging this up - I am back at base on Saturday and will
take it up then.

Regards

Paul

On Wed, 9 Oct 2019 at 11:13, Christophe Lyon  wrote:
>
> Hi,
>
>
> On Sat, 5 Oct 2019 at 20:31, Paul Richard Thomas 
>  wrote:
>>
>> I must apologise not posting this before committing. I left for a
>> vacation this morning and I thought that this problem and the one
>> posted by Gilles were best fixed before departing. The patch only
>> touches the new ISO_Fortran binding feature and so I thought that I
>> would be safe to do this.
>>
>> It was fully regtested and only applies to trunk.
>>
>> Paul
>>
>> Author: pault
>> Date: Sat Oct  5 08:17:55 2019
>> New Revision: 276624
>>
>> URL: https://gcc.gnu.org/viewcvs?rev=276624&root=gcc&view=rev
>> Log:
>> 2019-10-05  Paul Thomas  
>>
>> PR fortran/91926
>> * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Correct the
>> assignment of the attribute field to account correctly for an
>> assumed shape dummy. Assign separately to the gfc and cfi
>> descriptors since the atribute can be different. Add btanch to
>> correctly handle missing optional dummies.
>>
>> 2019-10-05  Paul Thomas  
>>
>> PR fortran/91926
>> * gfortran.dg/ISO_Fortran_binding_13.f90 : New test.
>> * gfortran.dg/ISO_Fortran_binding_13.c : Additional source.
>> * gfortran.dg/ISO_Fortran_binding_14.f90 : New test.
>>
>> 2019-10-05  Paul Thomas  
>>
>> PR fortran/91926
>> * runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc): Do not
>> modify the bounds and offset for CFI_other.
>>
>> Added:
>> trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_13.c
>> trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_13.f90
>> trunk/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_14.f90
>> Modified:
>> trunk/gcc/fortran/ChangeLog
>> trunk/gcc/fortran/trans-expr.c
>> trunk/gcc/testsuite/ChangeLog
>> trunk/libgfortran/ChangeLog
>> trunk/libgfortran/runtime/ISO_Fortran_binding.c
>
>
>
> Since this was committed (r276624), I have noticed regressions on 
> arm-linux-gnueabihf:
> FAIL: gfortran.dg/ISO_Fortran_binding_11.f90   -O3 -g  execution test
> I've seen other reports on gcc-testresults too.
>
> Christophe
>


-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: [Patch 1/2][ipa] Add target hook to sanitize cloned declaration's attributes

[Martin Jambor]

Hi,

On Wed, Oct 09 2019, Andre Vieira (lists) wrote:
> Hi Martin,
>
> Thanks for the suggestion.  I have moved the target hook to the 
> following functions:
> 'create_clone'
> 'create_version_clone'

I am not sure that calling the hook in create_version_clone is what you
want.  It should perhaps be made clearer in the API but unlike
(functions that call) create_clone and create_version_clone_with_body,
the result is not a local symbol but it may also be an externally
visible "version" of the original.  OpenMP uses it to create nodes for
external declarations (not definitions!) of variants of functions marked
with omp declare simd and the function calling it in trans-mem.c also
apparently uses it to create possibly externally visible clones.

So, if the idea of the patch is to allow stripping some attributes from
functions that are not externally visible - which I believe it is but I
may be wrong - you do not want to do that here.  Alternatively, the hook
itself could check DECL_EXTERNAL (node->decl).  Whether you decide to
invoke the call for non-local clones or not, please include it in the
hook description.

> 'create_version_clone_with_body'

The other two additions look OK to me.  You might want to check that the
attribute stripping works with LTO (but I tend to think that attributes
are streamed for WPA so it should be OK).

>
> I looked for all 'cgraph_node::create_*' functions and added the target 
> hook to them. The exception is 'create_virtual_clone' which calls 
> 'create_clone' so it should be caught there.
>
> Is this OK for trunk?

I'm afraid you'll need an ACK from a global reviewer for something like
this.

Martin


>
> Cheers,
> Andre
>
> gcc/ChangeLog:
>
> 2019-10-09  Andre Vieira  
>
>   * cgraphclones.c(create_clone): Call new target hook when
>  creating a new node.
>  (create_version_clone): Likewise.
>  (create_version_clone_with_body): Likewise.
>  * target.def(sanitize_clone_attributes): New target hook.
>  * targhooks.c(default_sanitize_clone_attributes): New.
>  * targhooks.h(default_sanitize_clone_attributes): New.
>  * doc/tm.texi.in: Document new target hook.
>  * doc/tm.texi: Regenerated

Re: Make C2X imply -fno-fp-int-builtin-inexact

[Rainer Orth]

Hi Joseph,

> gcc/testsuite:
> 2019-10-08  Joseph Myers  
>
>   * gcc.dg/torture/builtin-fp-int-inexact-c2x.c: New test.
[...]
> Index: gcc/testsuite/gcc.dg/torture/builtin-fp-int-inexact-c2x.c
> ===
> --- gcc/testsuite/gcc.dg/torture/builtin-fp-int-inexact-c2x.c (nonexistent)
> +++ gcc/testsuite/gcc.dg/torture/builtin-fp-int-inexact-c2x.c (working copy)
> @@ -0,0 +1,7 @@
> +/* Test C2X enables -fno-fp-int-builtin-inexact.  */
> +/* { dg-do run } */
> +/* { dg-options "-std=c2x" } */
> +/* { dg-add-options c99_runtime } */
> +/* { dg-require-effective-target fenv_exceptions } */
> +
> +#include "builtin-fp-int-inexact.c"

the new test FAILs on Solaris/x86, both 32 and 64-bit:

FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O0  execution test
FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O1  execution test
FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O2  execution test
FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O2 -flto  execution test
FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O2 -flto 
-flto-partition=none  execution test
FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O3 -g  execution test

The test aborts.  This happens because dg-add-options c99_runtime
appends -std=c99 to the options, yielding -std=c2x -std=c99.  If I
manually omit the -std=c99, the test PASSes.  I'm uncertain yet how to
handle this.  Maybe prepending -std=c99 is an option, but that may well
break other tests...

Rainer

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

PR92036 "OpenACC 'firstprivate' clause: initial value"

[Thomas Schwinge]

Hi!

In r276757 "[PR92036] Add
'libgomp.oacc-c-c++-common/data-firstprivate-1.c'", I committed the
attached to document the status quo, and then what I think it instead
should be per PR92036 "OpenACC 'firstprivate' clause: initial value".


Grüße
 Thomas


From 5fc105387fda327bf5e36ae6f997e415da6d1f37 Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Wed, 9 Oct 2019 11:31:14 +
Subject: [PATCH] [PR92036] Add
 'libgomp.oacc-c-c++-common/data-firstprivate-1.c'

	libgomp/
	PR middle-end/92036
	* testsuite/libgomp.oacc-c-c++-common/data-firstprivate-1.c: New
	file.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@276757 138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog |   6 +
 .../data-firstprivate-1.c | 165 ++
 2 files changed, 171 insertions(+)
 create mode 100644 libgomp/testsuite/libgomp.oacc-c-c++-common/data-firstprivate-1.c

diff --git a/libgomp/ChangeLog b/libgomp/ChangeLog
index 1b43c456741..319a1911882 100644
--- a/libgomp/ChangeLog
+++ b/libgomp/ChangeLog
@@ -1,3 +1,9 @@
+2019-10-09  Thomas Schwinge  
+
+	PR middle-end/92036
+	* testsuite/libgomp.oacc-c-c++-common/data-firstprivate-1.c: New
+	file.
+
 2019-10-09  Tobias Burnus  
 
 	PR testsuite/91884
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/data-firstprivate-1.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/data-firstprivate-1.c
new file mode 100644
index 000..8900a4e070d
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/data-firstprivate-1.c
@@ -0,0 +1,165 @@
+/* Test behavior of 'firstprivate' lexically vs. dynamically nested inside a
+   'data' region.  */
+
+#include 
+
+
+#define VERIFY(x) \
+  do { \
+if (!(x)) \
+  abort (); \
+  } while (0);
+
+
+/* This is basically and extended version of 't2' from 'firstprivate-1.c'.  */
+
+int lexically_nested_val = 2;
+
+static void
+lexically_nested ()
+{
+#pragma acc data \
+  copy (lexically_nested_val)
+  {
+VERIFY (lexically_nested_val == 2);
+
+#pragma acc parallel \
+  present (lexically_nested_val)
+{
+  VERIFY (lexically_nested_val == 2);
+
+  /* This updates the device copy, or shared variable.  */
+  lexically_nested_val = 7;
+}
+
+#if ACC_MEM_SHARED
+VERIFY (lexically_nested_val == 7);
+#else
+VERIFY (lexically_nested_val == 2);
+#endif
+
+/* This only updates the local/shared variable, but not the device
+   copy.  */
+lexically_nested_val = 5;
+
+#pragma acc parallel \
+firstprivate (lexically_nested_val)
+  {
+#if 1 /* Current behavior.  */
+	/* The 'firstprivate' copy is initialized from the device copy, or
+	   shared variable.  */
+# if ACC_MEM_SHARED
+	VERIFY (lexically_nested_val == 5);
+# else
+	VERIFY (lexically_nested_val == 7);
+# endif
+#else /* Expected behavior per PR92036.  */
+	/* The 'firstprivate' copy is initialized from the local thread.  */
+	VERIFY (lexically_nested_val == 5);
+#endif
+
+	/* This updates the 'firstprivate' copy only, but not the shared
+	   variable.  */
+	lexically_nested_val = 9;
+  }
+
+VERIFY (lexically_nested_val == 5);
+  }
+  /* If not shared, the device copy has now been copied back.  */
+
+#if ACC_MEM_SHARED
+  VERIFY (lexically_nested_val == 5);
+#else
+  VERIFY (lexically_nested_val == 7);
+#endif
+}
+
+
+int dynamically_nested_val = 2;
+
+/* Same as above, but compute construct 1 broken out, so no longer lexically
+   nested inside 'data' region.  */
+
+static void
+dynamically_nested_compute_1 ()
+{
+#pragma acc parallel \
+  present (dynamically_nested_val)
+  {
+VERIFY (dynamically_nested_val == 2);
+
+/* This updates the device copy, or shared variable.  */
+dynamically_nested_val = 7;
+  }
+}
+
+/* Same as above, but compute construct 2 broken out, so no longer lexically
+   nested inside 'data' region.  */
+
+static void
+dynamically_nested_compute_2 ()
+{
+#pragma acc parallel \
+  firstprivate (dynamically_nested_val)
+{
+#if 1 /* Current behavior.  */
+  /* The 'firstprivate' copy is initialized from the device copy, or shared
+	 variable.  */
+# if ACC_MEM_SHARED
+  VERIFY (dynamically_nested_val == 5);
+# else
+  VERIFY (dynamically_nested_val == 7);
+# endif
+#else /* Expected behavior per PR92036.  */
+  /* The 'firstprivate' copy is initialized from the local thread.  */
+  VERIFY (dynamically_nested_val == 5);
+#endif
+
+  /* This updates the 'firstprivate' copy only, but not the shared
+	 variable.  */
+  dynamically_nested_val = 9;
+}
+}
+
+static void
+dynamically_nested ()
+{
+#pragma acc data \
+  copy (dynamically_nested_val)
+  {
+VERIFY (dynamically_nested_val == 2);
+
+dynamically_nested_compute_1 ();
+
+#if ACC_MEM_SHARED
+VERIFY (dynamically_nested_val == 7);
+#else
+VERIFY (dynamically_nested_val == 2);
+#endif
+
+/* This only updates the local/shared variable, but not the device
+   copy.  */
+dynamically_nested_val = 5;
+
+dynamically_nested_compute_2 ()

Re: GCC wwwdocs move to git done

[Iain Sandoe]

Jonathan Wakely  wrote:


On Wed, 9 Oct 2019 at 01:28, Joseph Myers wrote:

I've done the move of GCC wwwdocs to git (using the previously posted and
discussed scripts), including setting up the post-receive hook to do the
same things previously covered by the old CVS hooks, and minimal updates
to the web pages dealing with the CVS setup for wwwdocs.


Thanks, Joseph.


+1

I would like to be able to preview changes to the website by using it from  
a local
webserver.  I realise that individual pages can be viewed in a browser /  
validated

by uploading - but it would be nice to check connectivity etc.

At the moment, I can’t identify the “mhc” program that is used in preparing  
the text

(and too many unrelated hits from searches).

Is there any other “gotcha” known to prevent doing this?

thanks
iain

Re: GCC wwwdocs move to git done

[Mark Wielaard]

On Wed, 2019-10-09 at 10:44 +0100, Jonathan Wakely wrote:
> On Wed, 9 Oct 2019 at 01:28, Joseph Myers wrote:
> > 
> > I've done the move of GCC wwwdocs to git (using the previously
> > posted and
> > discussed scripts), including setting up the post-receive hook to
> > do the
> > same things previously covered by the old CVS hooks, and minimal
> > updates
> > to the web pages dealing with the CVS setup for wwwdocs.
> 
> Thanks, Joseph.
> 
> I just pushed a change and although it worked and appeared on
> gcc.gnu.org, I got an error message during the push:
> 
> remote: hooks/post-receive: line 14: /www/gcc/updatelog: Permission
> denied
> remote:   Updating /www/gcc/htdocs/gcc-10/changes.html

/www/gcc/updatelog is where the logs of the post-receive are written.
It was only readable by the gcc group, I did a chmod g+w.
Now things should work without warning.

Cheers,

Mark

[PATCH] PR libstdc++/78552 only construct std::locale for C locale once

[Jonathan Wakely]

PR libstdc++/78552
* src/c++98/locale_init.cc (locale::classic()): Do not construct a new
locale object for every call.
(locale::_S_initialize_once()): Construct C locale here.

Tested x86_64-linux, committed to trunk.

This should be safe to backport too, but I'll wait a while as usual.


commit 8551ad37ed959266b5aaeab5c29ddfe26e121060
Author: Jonathan Wakely 
Date:   Tue Jul 2 15:31:48 2019 +0100

PR libstdc++/78552 only construct std::locale for C locale once

PR libstdc++/78552
* src/c++98/locale_init.cc (locale::classic()): Do not construct a 
new
locale object for every call.
(locale::_S_initialize_once()): Construct C locale here.

diff --git a/libstdc++-v3/src/c++98/locale_init.cc 
b/libstdc++-v3/src/c++98/locale_init.cc
index e5e9d74379f..07d95dc09fd 100644
--- a/libstdc++-v3/src/c++98/locale_init.cc
+++ b/libstdc++-v3/src/c++98/locale_init.cc
@@ -303,7 +303,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   locale::classic()
   {
 _S_initialize();
-return *(new (&c_locale) locale(_S_classic));
+return *(const locale*)c_locale;
   }
 
   void
@@ -313,6 +313,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 // One reference for _S_classic, one for _S_global
 _S_classic = new (&c_locale_impl) _Impl(2);
 _S_global = _S_classic;
+new (&c_locale) locale(_S_classic);
   }
 
   void

Re: [libgomp][testsuite] PR testsuite/91884 Add -lquadmath if available

[Rainer Orth]

Hi Tobias,

> I have also an alternative version:
>
> * For in-build-dir test runs, do as with previous patch, i.e. add
> "-lquadmath" to the "xgcc" call if the directory is available.
>
> * For installed-compiler test runs, the new patch uses GFORTRAN_UNDER_TEST
> / GXX_UNDER_TEST
> (It would also use them with in-build-dir runs, but nothing sets them. I
> have kept the -lgfortran / -lstdg++ flags, though they could be left out
> iff {GXX,GFORTRAN}_UNDER_TEST is set. Presumably, some linker will complain
> if they appear twice.)

TBH, this whole dance of always using xgcc/gcc and repeating everything
the real language drivers (xg++/g++ resp. gfortran) and their spec files
do and know in the testsuite seems extremly fragile.  The only variant
that makes sense to me is one letting the correct drivers do their work
(as is done e.g. in single-language lib testing like libstdc++) and have
the testsuite provide the necessary -L and -B flags for in-tree builds.

While this how I believe things should work, I've been practically
unable to do any useful testsuite patch review let alone testsuite work
for quite some time, so take this with a large grain of salt...  The
testsuite as a whole is riddled with immense amounts of duplication and
diverging almost-copies of code.

Rainer

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

[PATCH] Relax nested cycle vectorization further

[Richard Biener]

This simplifies and refactors vect_is_simple_reduction to make sure
to not reject nested cycle vectorization just beacuse there are calls
in the innermost loop.  This lets us vectorize the new testcase
using outer loop vectorization.

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

Richard.

2019-10-09  Richard Biener  

* tree-vect-loop.c (vect_is_simple_reduction): Simplify and
allow stmts other than GIMPLE_ASSIGN in nested cycles.

* gcc.dg/vect/vect-outer-call-1.c: New testcase.

diff --git a/gcc/testsuite/gcc.dg/vect/vect-outer-call-1.c 
b/gcc/testsuite/gcc.dg/vect/vect-outer-call-1.c
new file mode 100644
index 000..f26d4220532
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/vect-outer-call-1.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target vect_float } */
+/* { dg-additional-options "-fno-math-errno" } */
+
+void
+foo (float * __restrict x, float *y, int n, int m)
+{
+  if (m > 0)
+for (int i = 0; i < n; ++i)
+  {
+   float tem = x[i], tem1;
+   for (int j = 0; j < m; ++j)
+ {
+   tem += y[j];
+   tem1 = tem;
+   tem = __builtin_sqrtf (tem);
+ }
+   x[i] = tem - tem1;
+  }
+}
+
+/* { dg-final { scan-tree-dump "OUTER LOOP VECTORIZED" "vect" { target { 
vect_call_sqrtf } } } } */
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index a9ea0caf218..14352102f54 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -2756,10 +2756,8 @@ vect_is_simple_reduction (loop_vec_info loop_info, 
stmt_vec_info phi_info,
   enum tree_code orig_code, code;
   tree op1, op2, op3 = NULL_TREE, op4 = NULL_TREE;
   tree type;
-  tree name;
   imm_use_iterator imm_iter;
   use_operand_p use_p;
-  bool phi_def;
 
   *double_reduc = false;
   STMT_VINFO_REDUC_TYPE (phi_info) = TREE_CODE_REDUCTION;
@@ -2791,44 +2789,24 @@ vect_is_simple_reduction (loop_vec_info loop_info, 
stmt_vec_info phi_info,
   phi_use_stmt = use_stmt;
 }
 
-  edge latch_e = loop_latch_edge (loop);
-  tree loop_arg = PHI_ARG_DEF_FROM_EDGE (phi, latch_e);
-  if (TREE_CODE (loop_arg) != SSA_NAME)
+  tree latch_def = PHI_ARG_DEF_FROM_EDGE (phi, loop_latch_edge (loop));
+  if (TREE_CODE (latch_def) != SSA_NAME)
 {
   if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
-"reduction: not ssa_name: %T\n", loop_arg);
+"reduction: not ssa_name: %T\n", latch_def);
   return NULL;
 }
 
-  stmt_vec_info def_stmt_info = loop_info->lookup_def (loop_arg);
+  stmt_vec_info def_stmt_info = loop_info->lookup_def (latch_def);
   if (!def_stmt_info
   || !flow_bb_inside_loop_p (loop, gimple_bb (def_stmt_info->stmt)))
 return NULL;
 
-  if (gassign *def_stmt = dyn_cast  (def_stmt_info->stmt))
-{
-  name = gimple_assign_lhs (def_stmt);
-  phi_def = false;
-}
-  else if (gphi *def_stmt = dyn_cast  (def_stmt_info->stmt))
-{
-  name = PHI_RESULT (def_stmt);
-  phi_def = true;
-}
-  else
-{
-  if (dump_enabled_p ())
-   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
-"reduction: unhandled reduction operation: %G",
-def_stmt_info->stmt);
-  return NULL;
-}
-
   unsigned nlatch_def_loop_uses = 0;
   auto_vec lcphis;
   bool inner_loop_of_double_reduc = false;
-  FOR_EACH_IMM_USE_FAST (use_p, imm_iter, name)
+  FOR_EACH_IMM_USE_FAST (use_p, imm_iter, latch_def)
 {
   gimple *use_stmt = USE_STMT (use_p);
   if (is_gimple_debug (use_stmt))
@@ -2846,11 +2824,21 @@ vect_is_simple_reduction (loop_vec_info loop_info, 
stmt_vec_info phi_info,
}
 }
 
+  /* If we are vectorizing an inner reduction we are executing that
+ in the original order only in case we are not dealing with a
+ double reduction.  */
+  if (nested_in_vect_loop && !inner_loop_of_double_reduc)
+{
+  if (dump_enabled_p ())
+   report_vect_op (MSG_NOTE, def_stmt_info->stmt,
+   "detected nested cycle: ");
+  return def_stmt_info;
+}
+
   /* If this isn't a nested cycle or if the nested cycle reduction value
  is used ouside of the inner loop we cannot handle uses of the reduction
  value.  */
-  if ((!nested_in_vect_loop || inner_loop_of_double_reduc)
-  && (nlatch_def_loop_uses > 1 || nphi_def_loop_uses > 1))
+  if (nlatch_def_loop_uses > 1 || nphi_def_loop_uses > 1)
 {
   if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
@@ -2860,9 +2848,8 @@ vect_is_simple_reduction (loop_vec_info loop_info, 
stmt_vec_info phi_info,
 
   /* If DEF_STMT is a phi node itself, we expect it to have a single argument
  defined in the inner loop.  */
-  if (phi_def)
+  if (gphi *def_stmt = dyn_cast  (def_stmt_info->stmt))
 {
-  gphi *def_stmt = as_a  (def_stmt_info->stmt);
   op1 = PHI_ARG_DEF (def_stmt, 0);
 
   if (gimpl

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

[Tom de Vries]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08-10-2019 16:05, Thomas Schwinge wrote:
> Hi Chung-Lin!
>
> While we're all waiting for Tom to comment on this ;-)

Ack, thanks for the ping ...

> -- here's another item I realized:
>
> On 2019-09-10T19:41:59+0800, Chung-Lin Tang
>  wrote:
>> The libgomp nvptx plugin changes are also quite contained, with
>> lots of now unneeded [...] code deleted (since we no longer first
>> cuAlloc a buffer for the argument record before cuLaunchKernel)
>
> It would be nice ;-) -- but unless I'm confused, it's not that
> simple: we either have to reject (force host-fallback execution) or
> keep supporting "old-style" nvptx offloading code: new-libgomp has
> to continue to work with nvptx offloading code once generated by
> old-GCC.  Possibly even a mixture of old and new nvptx offloading
> code, if libraries are involved, huh!
>
> I have not completely thought that through, but I suppose this
> could be addressed by adding a flag to the 'struct nvptx_fn' (or
> similar) that's synthesized by nvptx 'mkoffload'?
>
> Maybe if fact the 'enum id_map_flag' machinery that I once added
> for 'Un-parallelized OpenACC kernels constructs with nvptx
> offloading: "avoid offloading"'?  (That's part of og8 commit
> 2d42fbf7e989e4bb76727b32ef11deb5845d5ab1 -- not present on og9,
> huh?!) The 'enum id_map_flag' machinery serves the purpose of
> transporting information from the offload compiler to libgomp,
> which seems what's needed here?  (But please verify.)
>
... and for raising this issue. I think this needs to be addressed.

It would be great if we can avoid it, but ... AFAIU, this means
bumping GOMP_VERSION_NVIDIA_PTX (1 -> 2).

Using a new a.out (registers with GOMP_VERSION_NVIDIA_PTX == 2) with
an old libgomp (supports GOMP_VERSION_NVIDIA_PTX <= 1) will give us an
"Offload data incompatible with PTX plugin" error.

Using an old a.out (registers with GOMP_VERSION_NVIDIA_PTX == 1) with
a new libgomp (supports GOMP_VERSION_NVIDIA_PTX <= 2) will have to be
supported in the way that things are currently handled.

Using a new a.out (registers with GOMP_VERSION_NVIDIA_PTX == 2) with a
new libgomp (supports GOMP_VERSION_NVIDIA_PTX <= 2) will have to be
supported in the way that the patch implements things.

The current approach is that all offload-functions are assumed to be
transformed by the optimization, which implies that failure to
transform should be a compilation error (is that indeed ensured by the
patch?). Which is a bit funny for an 'optimization'. We might wanna
decide to do switch this on/off at offload-function level.

That ties in with the fact that if we're going to keep the path alive
for backward compatibility, it would be nice if we can actually test
this in the trunk version by disabling the optimization. Which is also
nice to have if we run into issues with the optimization. And once we
allow this to be disabled at user level, we're going to have to track
this at offload-function level.

So I'd say for GOMP_VERSION_NVIDIA_PTX == 2 we extend target_data with
a flag such that we can query things on a per offload-function level,
while taking care to represent the common case where the flag is the
same for all offload-functions in an economical way.

That leaves the question of how to get that information to mkoffload,
perhaps the patch Thomas mentioned can be of help there.

Thanks,
- - Tom
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEErJ0nuYSmyzCtZhpo7oVdq2ziRKAFAl2d4aEACgkQ7oVdq2zi
RKDhwQf/efEZRCR+HJ+M50FGKh5a1lrVm8QE5ue7SoY2rzjdKf2JT6tIUysJSYyP
JQYENHAz9Q/1uxYa3VYoFc1c8cVPyhutzezIWPXDVoNBoj/NEwFvQyZl4fqGfkFb
mRgEAHtfE1HZwfXp86UlJbgDV5wF1XGWQQad3P6F38NtXVTORoce79OViITnFq8I
YvfvZWx1EdomacW8oThzo9VY/CM4JeuY4r0dEv8REtk3Py5Cpw4E3xk195BgUAAS
OJj3g8Etg/wTBsgvrO6qqP8ie91Ys/9IRXjf238hay40i44Y7APGuRHgffFE6AE6
RPn24JUY0mdDj9WzlergTjsjWtfppQ==
=EdLk
-END PGP SIGNATURE-

Re: GCC wwwdocs move to git done

[Christopher Faylor]

On Wed, Oct 09, 2019 at 01:25:30PM +0100, Iain Sandoe wrote:
>Jonathan Wakely  wrote:
>
>>On Wed, 9 Oct 2019 at 01:28, Joseph Myers wrote:
>>>I've done the move of GCC wwwdocs to git (using the previously posted and
>>>discussed scripts), including setting up the post-receive hook to do the
>>>same things previously covered by the old CVS hooks, and minimal updates
>>>to the web pages dealing with the CVS setup for wwwdocs.
>>
>>Thanks, Joseph.
>
>+1
>
>I would like to be able to preview changes to the website by using it
>from a local
>webserver.  I realise that individual pages can be viewed in a
>browser / validated
>by uploading - but it would be nice to check connectivity etc.
>
>At the moment, I can’t identify the “mhc” program that is used in
>preparing the text
>(and too many unrelated hits from searches).

I think it's the "metahtml" processor:

https://ftp.gnu.org/gnu/metahtml/

The binary is 20 years old and, somehow, the source code used to build
it seems to have disappeared.

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

[Tom de Vries]

On 01-10-2019 14:45, Chung-Lin Tang wrote:

> Index: gcc/config/nvptx/nvptx.c
> ===
> --- gcc/config/nvptx/nvptx.c  (revision 276406)
> +++ gcc/config/nvptx/nvptx.c  (working copy)
> @@ -68,6 +68,10 @@
>  #include "attribs.h"
>  #include "tree-vrp.h"
>  #include "tree-ssa-operands.h"
> +#include "tree-pretty-print.h"
> +#include "gimple-pretty-print.h"
> +#include "tree-cfg.h"
> +#include "gimple-ssa.h"
>  #include "tree-ssanames.h"
>  #include "gimplify.h"
>  #include "tree-phinodes.h"
> @@ -6437,6 +6441,226 @@ nvptx_set_current_function (tree fndecl)
>oacc_bcast_partition = 0;
>  }
>  
> +static void
> +nvptx_expand_to_rtl_hook (void)
> +{
> +  /* For utilizing CUDA .param kernel arguments, we detect and modify
> + the gimple of offloaded child functions, here before RTL expansion,
> + starting with standard OMP form:
> +  foo._omp_fn.0 (const struct .omp_data_t.8 & restrict .omp_data_i) { 
> ... }
> +   
> + and transform it into a style where the OMP data record fields are
> + "exploded" into individual scalar arguments:
> +  foo._omp_fn.0 (int * a, int * b, int * c) { ... }
> +
> + Note that there are implicit assumptions of how OMP lowering (and/or 
> other
> + intervening passes) behaves contained in this transformation code;
> + if those passes change in their output, this code may possibly need
> + updating.  */
> +
> +  if (lookup_attribute ("omp target entrypoint",
> + DECL_ATTRIBUTES (current_function_decl))
> +  /* The rather indirect manner in which OpenMP target functions are
> +  launched makes this transformation only valid for OpenACC currently.
> +  TODO: e.g. write_omp_entry(), nvptx_declare_function_name(), etc.
> +  needs changes for this to work with OpenMP.  */
> +  && lookup_attribute ("oacc function",
> +DECL_ATTRIBUTES (current_function_decl)))
> +{

Please do an early-return here.

Otherwise, no comments to the code as such.

Thanks,
- Tom

Re: GCC wwwdocs move to git done

[Iain Sandoe]

Christopher Faylor  wrote:


On Wed, Oct 09, 2019 at 01:25:30PM +0100, Iain Sandoe wrote:

Jonathan Wakely  wrote:


On Wed, 9 Oct 2019 at 01:28, Joseph Myers wrote:
I've done the move of GCC wwwdocs to git (using the previously posted  
and

discussed scripts), including setting up the post-receive hook to do the
same things previously covered by the old CVS hooks, and minimal updates
to the web pages dealing with the CVS setup for wwwdocs.


Thanks, Joseph.


+1

I would like to be able to preview changes to the website by using it
from a local
webserver.  I realise that individual pages can be viewed in a
browser / validated
by uploading - but it would be nice to check connectivity etc.

At the moment, I can’t identify the “mhc” program that is used in
preparing the text
(and too many unrelated hits from searches).


I think it's the "metahtml" processor:

https://ftp.gnu.org/gnu/metahtml/

The binary is 20 years old and, somehow, the source code used to build
it seems to have disappeared.


Yeah - https://www.gnu.org/software/metahtml/

but the cvs co seems to hang on a lock :(

something to investigate later...
Iain

[PATCH][LTO] Do not merge anonymous NAMESPACE_DECLs

[Richard Biener]

The following does $subject which likely fixes some debuginfo issues
with anonymous namespaces (but likely artificial and not too
noticable?!  we'd get bogus contexts for DIEs)

Bootstrapped and tested on x86_64-unknown-linux-gnu.

I'm doin a LTO bootstrap right now (but IIRC it failed a few days ago)

Richard.

2019-10-09  Richard Biener  

lto/
* lto-common.c (unify_scc): Do not merge anonymous NAMESPACE_DECLs.

diff --git a/gcc/lto/lto-common.c b/gcc/lto/lto-common.c
index 9a17933d094..e5c15f2b844 100644
--- a/gcc/lto/lto-common.c
+++ b/gcc/lto/lto-common.c
@@ -1646,11 +1646,13 @@ unify_scc (class data_in *data_in, unsigned from,
   tree t = streamer_tree_cache_get_tree (cache, from + i);
   scc->entries[i] = t;
   /* Do not merge SCCs with local entities inside them.  Also do
-not merge TRANSLATION_UNIT_DECLs and anonymous namespace types.  */
+not merge TRANSLATION_UNIT_DECLs and anonymous namespaces
+and types therein types.  */
   if (TREE_CODE (t) == TRANSLATION_UNIT_DECL
  || (VAR_OR_FUNCTION_DECL_P (t)
  && !(TREE_PUBLIC (t) || DECL_EXTERNAL (t)))
  || TREE_CODE (t) == LABEL_DECL
+ || (TREE_CODE (t) == NAMESPACE_DECL && !DECL_NAME (t))
  || (TYPE_P (t)
  && type_with_linkage_p (TYPE_MAIN_VARIANT (t))
  && type_in_anonymous_namespace_p (TYPE_MAIN_VARIANT (t

Re: GCC wwwdocs move to git done

[Christopher Faylor]

On Wed, Oct 09, 2019 at 09:37:54AM -0400, Christopher Faylor wrote:
>The binary is 20 years old and, somehow, the source code used to build
>it seems to have disappeared.

Sorry. Not 20 years:

-rwxr-xr-x. 1 root root 574221 Mar 22  2013 /usr/local/bin/mhc

cgf

Re: [PATCH 2/2][MSP430] Optimize zero_extend insns and PSImode pointer manipulation

[Jozef Lawrynowicz]

Hi Segher!

On Wed, 9 Oct 2019 03:47:32 -0500
Segher Boessenkool  wrote:

> Hi Jozef,
> 
> On Tue, Oct 08, 2019 at 11:39:57AM +0100, Jozef Lawrynowicz wrote:
> > +;; 
> > +;; ZERO EXTEND INSTRUCTIONS
> > +;; Byte-writes to registers clear bits 19:8
> > +;;   * Byte-writes to memory do not affect bits 15:8
> > +;; Word-writes to registers clear bits 19:16
> > +;; PSImode writes to memory clear bits 16:4 of the second memory word  
> 
> Should that be 15:4 instead?

Whoops, nice spot. I'll fix that before applying (if it gets approved) rather
than re-submitting.
> 
> > +; FIXME many of these should be unnnecessary once combine deals with
> > +; (sign_extend (zero_extend)) or (sign_extend (subreg)) BZ 91865.  
> 
> I have looked at it some time ago, and it is quite hard :-/  It's not
> forgotten though!

Ok, thanks for the update!
Jozef
> 
> 
> Segher

Re: GCC wwwdocs move to git done

[David Malcolm]

On Wed, 2019-10-09 at 09:37 -0400, Christopher Faylor wrote:
> On Wed, Oct 09, 2019 at 01:25:30PM +0100, Iain Sandoe wrote:
> > Jonathan Wakely  wrote:
> > 
> > > On Wed, 9 Oct 2019 at 01:28, Joseph Myers wrote:
> > > > I've done the move of GCC wwwdocs to git (using the previously
> > > > posted and
> > > > discussed scripts), including setting up the post-receive hook
> > > > to do the
> > > > same things previously covered by the old CVS hooks, and
> > > > minimal updates
> > > > to the web pages dealing with the CVS setup for wwwdocs.
> > > 
> > > Thanks, Joseph.
> > 
> > +1
> > 
> > I would like to be able to preview changes to the website by using
> > it
> > from a local
> > webserver.  I realise that individual pages can be viewed in a
> > browser / validated
> > by uploading - but it would be nice to check connectivity etc.
> > 
> > At the moment, I can’t identify the “mhc” program that is used in
> > preparing the text
> > (and too many unrelated hits from searches).
> 
> I think it's the "metahtml" processor:
> 
> https://ftp.gnu.org/gnu/metahtml/
> 
> The binary is 20 years old and, somehow, the source code used to
> build
> it seems to have disappeared.

I wrote a replacement for this:
  "[PATCH] wwwdocs: port from MetaHTML to a Python 3 script"
 https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00176.html

I had it in my mind that this had gone in, but I guess I misremembered.

[I'm currently frantically trying to finish a major new feature for GCC
stage 1, so my cycles are limited right now, but if someone else wants
to finish the patch in the meantime that would be great]

Dave

[C++ Patch] Fix cp_build_binary_op locations

[Paolo Carlini]

Hi,

this largely mechanical patch fixes those errors in cp_build_binary_op 
which weren't exploiting yet the op_location_t argument, thus aligning 
the locations to those of the C front-end. Plus an additional use for 
DECL_SOURCE_LOCATION in decl.c. Tested x86_64-linux.


Thanks, Paolo.

///

/cp
2019-10-09  Paolo Carlini  

* decl.c (grok_ctor_properties): Use DECL_SOURCE_LOCATION.
* typeck.c (cp_build_binary_op): Use the op_location_t argument
in many error messages.

/testsuite
2019-10-09  Paolo Carlini  

* c-c++-common/Waddress-1.c: Test locations too.
* c-c++-common/Wpointer-compare-1.c: Likewise.
* c-c++-common/Wshift-count-negative-1.c: Likewise.
* c-c++-common/Wshift-count-overflow-1.c: Likewise.
* c-c++-common/Wshift-negative-value-1.c: Likewise.
* c-c++-common/Wshift-negative-value-2.c: Likewise.
* c-c++-common/Wshift-negative-value-5.c: Likewise.
* c-c++-common/pr48418.c: Likewise.
* c-c++-common/pr65830.c: Likewise.
* c-c++-common/pr69764.c: Likewise.
* g++.dg/cpp0x/constexpr-array-ptr10.C: Likewise.
* g++.dg/cpp0x/nullptr37.C: Likewise.
* g++.dg/template/crash126.C: Likewise.
* g++.dg/template/crash129.C: Likewise.
* g++.dg/warn/Wextra-3.C: Likewise.
* g++.dg/warn/Wfloat-equal-1.C: Likewise.
* g++.dg/warn/Wstring-literal-comparison-1.C: Likewise.
* g++.dg/warn/Wstring-literal-comparison-2.C: Likewise.
* g++.dg/warn/pointer-integer-comparison.C: Likewise.
* g++.old-deja/g++.jason/crash8.C: Likewise.
Index: cp/decl.c
===
--- cp/decl.c   (revision 276756)
+++ cp/decl.c   (working copy)
@@ -13738,7 +13738,8 @@ grok_ctor_properties (const_tree ctype, const_tree
 or implicitly defined), there's no need to worry about their
 existence.  Theoretically, they should never even be
 instantiated, but that's hard to forestall.  */
-  error ("invalid constructor; you probably meant %<%T (const %T&)%>",
+  error_at (DECL_SOURCE_LOCATION (decl),
+   "invalid constructor; you probably meant %<%T (const %T&)%>",
ctype, ctype);
   return false;
 }
Index: cp/typeck.c
===
--- cp/typeck.c (revision 276756)
+++ cp/typeck.c (working copy)
@@ -4475,7 +4475,8 @@ cp_build_binary_op (const op_location_t &location,
   if (t != error_mark_node)
{
  if (complain & tf_error)
-   permerror (input_location, "assuming cast to type %qT from 
overloaded function",
+   permerror (location,
+  "assuming cast to type %qT from overloaded function",
   TREE_TYPE (t));
  op0 = t;
}
@@ -4486,7 +4487,8 @@ cp_build_binary_op (const op_location_t &location,
   if (t != error_mark_node)
{
  if (complain & tf_error)
-   permerror (input_location, "assuming cast to type %qT from 
overloaded function",
+   permerror (location,
+  "assuming cast to type %qT from overloaded function",
   TREE_TYPE (t));
  op1 = t;
}
@@ -4809,8 +4811,8 @@ cp_build_binary_op (const op_location_t &location,
{
  if ((complain & tf_warning)
  && c_inhibit_evaluation_warnings == 0)
-   warning (OPT_Wshift_count_negative,
-"right shift count is negative");
+   warning_at (location, OPT_Wshift_count_negative,
+   "right shift count is negative");
}
  else
{
@@ -4817,8 +4819,8 @@ cp_build_binary_op (const op_location_t &location,
  if (compare_tree_int (const_op1, TYPE_PRECISION (type0)) >= 0
  && (complain & tf_warning)
  && c_inhibit_evaluation_warnings == 0)
-   warning (OPT_Wshift_count_overflow,
-"right shift count >= width of type");
+   warning_at (location, OPT_Wshift_count_overflow,
+   "right shift count >= width of type");
}
}
  /* Avoid converting op1 to result_type later.  */
@@ -4856,8 +4858,8 @@ cp_build_binary_op (const op_location_t &location,
  && tree_int_cst_sgn (const_op0) < 0
  && (complain & tf_warning)
  && c_inhibit_evaluation_warnings == 0)
-   warning (OPT_Wshift_negative_value,
-"left shift of negative value");
+   warning_at (location, OPT_Wshift_negative_value,
+   "left shift of negative value");
  if (TREE_CODE (const_op1) == INTEGER_CST)
{
  if (tree_int_cst_lt (const_op1, in

Re: GCC wwwdocs move to git done

[Joseph Myers]

On Tue, 8 Oct 2019, Frank Ch. Eigler wrote:

> Hi -
> 
> Thanks - good job with moving this to git!
> 
> > Note 1: someone with the right access needs to create the symlink 
> > /sourceware/git/gcc-wwwdocs.git -> 
> > /sourceware/projects/gcc-home/wwwdocs.git (and anything else needed for 
> > anonymous git access to that repository).
> 
> Done.

Thanks!  I've now updated the instructions to use the shorter path to the 
repository and restored the documentation of anonymous access.

diff --git a/htdocs/about.html b/htdocs/about.html
index 30a5c943..019b6fbd 100644
--- a/htdocs/about.html
+++ b/htdocs/about.html
@@ -54,10 +54,12 @@ a higher chance of being implemented soon. ;-)
 and SSH installed, you can check out the web pages as follows:
 
 
- git clone 
git+ssh://username@gcc.gnu.org/sourceware/projects/gcc-home/wwwdocs.git
+ git clone 
git+ssh://username@gcc.gnu.org/git/gcc-wwwdocs.git
  where username is your user name at gcc.gnu.org
 
 
+For anonymous access, use
+git://gcc.gnu.org/git/gcc-wwwdocs.git instead.
 
 Validating a change
 

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

Re: [Patch 1/2][ipa] Add target hook to sanitize cloned declaration's attributes

[Andre Vieira (lists)]

Hi Martin,

I see thank you. For my particular use case I only need to strip 
attributes for local symbols.  However, if I were to claim it is only 
used for non-externally visible clones than I would also need to make 
sure they are non-externally visible now and put something in place that 
checks this in the future.  I feel it's easier and more flexible to 
leave it up to the users of the hook to check it themselves using 
DECL_EXTERNAL.  I will mention it in the description though.


Cheers,
Andre

gcc/ChangeLog:

2019-10-09  Andre Vieira  

* cgraphclones.c(create_clone): Call new target hook when
creating a new node.
(create_version_clone): Likewise.
(create_version_clone_with_body): Likewise.
* target.def(sanitize_clone_attributes): New target hook.
* targhooks.c(default_sanitize_clone_attributes): New.
* targhooks.h(default_sanitize_clone_attributes): New.
* doc/tm.texi.in: Document new target hook.
* doc/tm.texi: Regenerated

On 09/10/2019 12:43, Martin Jambor wrote:

Hi,

On Wed, Oct 09 2019, Andre Vieira (lists) wrote:

Hi Martin,

Thanks for the suggestion.  I have moved the target hook to the
following functions:
'create_clone'
'create_version_clone'


I am not sure that calling the hook in create_version_clone is what you
want.  It should perhaps be made clearer in the API but unlike
(functions that call) create_clone and create_version_clone_with_body,
the result is not a local symbol but it may also be an externally
visible "version" of the original.  OpenMP uses it to create nodes for
external declarations (not definitions!) of variants of functions marked
with omp declare simd and the function calling it in trans-mem.c also
apparently uses it to create possibly externally visible clones.


diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index 909407b9a71690fe7b6ce731e5ddaa06af6d4410..f1fc77923f7f8125e973bc2fba0c00f7760e8acd 100644
--- a/gcc/cgraphclones.c
+++ b/gcc/cgraphclones.c
@@ -80,6 +80,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-inline.h"
 #include "dumpfile.h"
 #include "gimple-pretty-print.h"
+#include "target.h"
 
 /* Create clone of edge in the node N represented by CALL_EXPR
the callgraph.  */
@@ -407,6 +408,8 @@ cgraph_node::create_clone (tree new_decl, profile_count prof_count,
   if (!new_inlined_to)
 dump_callgraph_transformation (this, new_node, suffix);
 
+  targetm.sanitize_clone_attributes (new_node);
+
   return new_node;
 }
 
@@ -1004,6 +1007,9 @@ cgraph_node::create_version_clone_with_body
   update_call_expr (new_version_node);
 
   symtab->call_cgraph_insertion_hooks (new_version_node);
+
+  targetm.sanitize_clone_attributes (new_version_node);
+
   return new_version_node;
 }
 
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index a86c210d4fe390bd0356b6e50ba7c6c34a36239a..5c1149ccf47576d8d803d1ab712f6f1b9342d74c 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -12039,6 +12039,11 @@ If defined, this function returns an appropriate alignment in bits for an atomic
 ISO C11 requires atomic compound assignments that may raise floating-point exceptions to raise exceptions corresponding to the arithmetic operation whose result was successfully stored in a compare-and-exchange sequence.  This requires code equivalent to calls to @code{feholdexcept}, @code{feclearexcept} and @code{feupdateenv} to be generated at appropriate points in the compare-and-exchange sequence.  This hook should set @code{*@var{hold}} to an expression equivalent to the call to @code{feholdexcept}, @code{*@var{clear}} to an expression equivalent to the call to @code{feclearexcept} and @code{*@var{update}} to an expression equivalent to the call to @code{feupdateenv}.  The three expressions are @code{NULL_TREE} on entry to the hook and may be left as @code{NULL_TREE} if no code is required in a particular place.  The default implementation leaves all three expressions as @code{NULL_TREE}.  The @code{__atomic_feraiseexcept} function from @code{libatomic} may be of use as part of the code generated in @code{*@var{update}}.
 @end deftypefn
 
+@deftypefn {Target Hook} void TARGET_SANITIZE_CLONE_ATTRIBUTES (struct cgraph_node *@var{})
+This target hook sanitizes the cloned @code{*@var{node}} declaration
+attributes.
+@end deftypefn
+
 @deftypefn {Target Hook} void TARGET_RECORD_OFFLOAD_SYMBOL (tree)
 Used when offloaded functions are seen in the compilation unit and no named
 sections are available.  It is called once for each symbol that must be
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 06dfcda35abea7396c288a59c38ee4ef57c6fef6..f4ef164a595ca1c2e286a7d26020b63b4c966728 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -8134,6 +8134,8 @@ and the associated definitions of those functions.
 
 @hook TARGET_ATOMIC_ASSIGN_EXPAND_FENV
 
+@hook TARGET_SANITIZE_CLONE_ATTRIBUTES
+
 @hook TARGET_RECORD_OFFLOAD_SYMBOL
 
 @hook TARGET_OFFLOAD_OPTIONS
diff --git a/gcc/ipa-cp.c

[PATCH][gcov-profile/91971]Profile directory concatenated with object file path

[Qing Zhao]

Hi,

This is a patch for fix PR 91971: Profile directory concatenated with object 
file path

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

Gcc/ChangeLog:

+2019-10-09  qing zhao  
+
+   * coverage.c (coverage_init): Mangle the full path of filename when
+   filename is a absolute path.
+
 2019-10-07  Jozef Lawrynowicz  

$ git diff  gcc/coverage.c
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 0d5138f..bcba61c 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1229,6 +1229,14 @@ coverage_init (const char *filename)
   else
profile_data_prefix = getpwd ();
 }
+  else
+{
+  /* when filename is a absolute path, we also need to mangle the full
+  path of filename to prevent the profiling data being stored into a
+  different path than that specified by profile_data_prefix.  */
+  filename = mangle_path (filename);
+  len = strlen (filename);
+}
 
   if (profile_data_prefix)
 prefix_len = strlen (profile_data_prefix);

Okay to commit?

thanks.

Qing
 

> On Oct 2, 2019, at 11:05 AM, Qing Zhao  wrote:
> 
> Ping on:
> 
> https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01554.html 
> 
> 
> Anyway, I filed an gcc bug on this issue as:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91971 
> 
> 
> If you think that this is NOT a bug, please let me know.
> 
> thanks.
> 
> Qing

Re: [C++ Patch] Fix cp_build_binary_op locations

[Jason Merrill]

On 10/9/19 10:23 AM, Paolo Carlini wrote:

Hi,

this largely mechanical patch fixes those errors in cp_build_binary_op 
which weren't exploiting yet the op_location_t argument, thus aligning 
the locations to those of the C front-end. Plus an additional use for 
DECL_SOURCE_LOCATION in decl.c. Tested x86_64-linux.


Thanks, Paolo.

///


OK.

Jason

Re: [Patch 1/2][ipa] Add target hook to sanitize cloned declaration's attributes

[Andre Vieira (lists)]

Adding Jakub to CC'

On 09/10/2019 16:29, Andre Vieira (lists) wrote:

Hi Martin,

I see thank you. For my particular use case I only need to strip 
attributes for local symbols.  However, if I were to claim it is only 
used for non-externally visible clones than I would also need to make 
sure they are non-externally visible now and put something in place that 
checks this in the future.  I feel it's easier and more flexible to 
leave it up to the users of the hook to check it themselves using 
DECL_EXTERNAL.  I will mention it in the description though.


Cheers,
Andre

gcc/ChangeLog:

2019-10-09  Andre Vieira  

 * cgraphclones.c(create_clone): Call new target hook when
     creating a new node.
     (create_version_clone): Likewise.
     (create_version_clone_with_body): Likewise.
     * target.def(sanitize_clone_attributes): New target hook.
     * targhooks.c(default_sanitize_clone_attributes): New.
     * targhooks.h(default_sanitize_clone_attributes): New.
     * doc/tm.texi.in: Document new target hook.
     * doc/tm.texi: Regenerated

On 09/10/2019 12:43, Martin Jambor wrote:

Hi,

On Wed, Oct 09 2019, Andre Vieira (lists) wrote:

Hi Martin,

Thanks for the suggestion.  I have moved the target hook to the
following functions:
'create_clone'
'create_version_clone'


I am not sure that calling the hook in create_version_clone is what you
want.  It should perhaps be made clearer in the API but unlike
(functions that call) create_clone and create_version_clone_with_body,
the result is not a local symbol but it may also be an externally
visible "version" of the original.  OpenMP uses it to create nodes for
external declarations (not definitions!) of variants of functions marked
with omp declare simd and the function calling it in trans-mem.c also
apparently uses it to create possibly externally visible clones.

[PATCH] PR libstdc++/91057 set locale::id::_M_index atomically

[Jonathan Wakely]

If two threads see _M_index==0 concurrently they will both try to set
it, potentially storing the facet at two different indices in the array.

Either set the _M_index data member using an atomic compare-exchange
operation or while holding a mutex.

Also move the LONG_DOUBLE_COMPAT code into a separate function to remove
the visual noise it creates.

PR libstdc++/91057
* src/c++98/locale.cc (locale::id::_M_id()) [__GTHREADS]: Use atomic
compare-exchange or double-checked lock to ensure only one thread sets
the _M_index variable.
[_GLIBCXX_LONG_DOUBLE_COMPAT]: Call find_ldbl_sync_facet to detect
facets that share another facet's ID.
[_GLIBCXX_LONG_DOUBLE_COMPAT] (find_ldbl_sync_facet): New function.

Tested x86_64-linux, committed to trunk.

commit 9868e2cb77b226e7aeaeec4c04637a161d7f05fc
Author: Jonathan Wakely 
Date:   Fri Jul 5 14:03:30 2019 +0100

PR libstdc++/91057 set locale::id::_M_index atomically

If two threads see _M_index==0 concurrently they will both try to set
it, potentially storing the facet at two different indices in the array.

Either set the _M_index data member using an atomic compare-exchange
operation or while holding a mutex.

Also move the LONG_DOUBLE_COMPAT code into a separate function to remove
the visual noise it creates.

PR libstdc++/91057
* src/c++98/locale.cc (locale::id::_M_id()) [__GTHREADS]: Use atomic
compare-exchange or double-checked lock to ensure only one thread 
sets
the _M_index variable.
[_GLIBCXX_LONG_DOUBLE_COMPAT]: Call find_ldbl_sync_facet to detect
facets that share another facet's ID.
[_GLIBCXX_LONG_DOUBLE_COMPAT] (find_ldbl_sync_facet): New function.

diff --git a/libstdc++-v3/src/c++98/locale.cc b/libstdc++-v3/src/c++98/locale.cc
index 8652f8559c2..1d00edc6f51 100644
--- a/libstdc++-v3/src/c++98/locale.cc
+++ b/libstdc++-v3/src/c++98/locale.cc
@@ -474,6 +474,30 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // Definitions for static const data members of locale::id
   _Atomic_word locale::id::_S_refcount;  // init'd to 0 by linker
 
+  // XXX GLIBCXX_ABI Deprecated
+#ifdef _GLIBCXX_LONG_DOUBLE_COMPAT
+namespace {
+  inline locale::id*
+  find_ldbl_sync_facet(locale::id* __idp)
+  {
+# define _GLIBCXX_SYNC_ID(facet, mangled) \
+if (__idp == &::mangled) \
+  return &facet::id
+
+_GLIBCXX_SYNC_ID (num_get, 
_ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE);
+_GLIBCXX_SYNC_ID (num_put, 
_ZNSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE2idE);
+_GLIBCXX_SYNC_ID (money_get, 
_ZNSt9money_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE);
+_GLIBCXX_SYNC_ID (money_put, 
_ZNSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE2idE);
+# ifdef _GLIBCXX_USE_WCHAR_T
+_GLIBCXX_SYNC_ID (num_get, 
_ZNSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE2idE);
+_GLIBCXX_SYNC_ID (num_put, 
_ZNSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE2idE);
+_GLIBCXX_SYNC_ID (money_get, 
_ZNSt9money_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE2idE);
+_GLIBCXX_SYNC_ID (money_put, 
_ZNSt9money_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE2idE);
+# endif
+  }
+} // namespace
+#endif
+
   size_t
   locale::id::_M_id() const throw()
   {
@@ -481,26 +505,38 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
// XXX GLIBCXX_ABI Deprecated
 #ifdef _GLIBCXX_LONG_DOUBLE_COMPAT
-   locale::id *f = 0;
-# define _GLIBCXX_SYNC_ID(facet, mangled) \
-   if (this == &::mangled) \
- f = &facet::id
-   _GLIBCXX_SYNC_ID (num_get, 
_ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE);
-   _GLIBCXX_SYNC_ID (num_put, 
_ZNSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE2idE);
-   _GLIBCXX_SYNC_ID (money_get, 
_ZNSt9money_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE);
-   _GLIBCXX_SYNC_ID (money_put, 
_ZNSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE2idE);
-# ifdef _GLIBCXX_USE_WCHAR_T
-   _GLIBCXX_SYNC_ID (num_get, 
_ZNSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE2idE);
-   _GLIBCXX_SYNC_ID (num_put, 
_ZNSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE2idE);
-   _GLIBCXX_SYNC_ID (money_get, 
_ZNSt9money_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE2idE);
-   _GLIBCXX_SYNC_ID (money_put, 
_ZNSt9money_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE2idE);
-# endif
-   if (f)
- _M_index = 1 + f->_M_id();
+   if (locale::id* f = find_ldbl_sync_facet(this))
+   {
+ const size_t sync_id = f->_M_id();
+ _M_index = 1 + sync_id;
+ return sync_id;
+   }
+#endif
+
+#ifdef __GTHREADS
+   if (__gthread_active_p())
+ {
+   if (__atomic_always_lock_free(sizeof(_M_index), &_M_index))
+ {
+   const _Atomic

Re: GCC wwwdocs move to git done

[David Malcolm]

On Wed, 2019-10-09 at 15:06 +, Joseph Myers wrote:
> On Tue, 8 Oct 2019, Frank Ch. Eigler wrote:
> 
> > Hi -
> > 
> > Thanks - good job with moving this to git!

+1

> > > Note 1: someone with the right access needs to create the
> > > symlink 
> > > /sourceware/git/gcc-wwwdocs.git -> 
> > > /sourceware/projects/gcc-home/wwwdocs.git (and anything else
> > > needed for 
> > > anonymous git access to that repository).
> > 
> > Done.
> 
> Thanks!  I've now updated the instructions to use the shorter path to
> the 
> repository and restored the documentation of anonymous access.
> 
> diff --git a/htdocs/about.html b/htdocs/about.html
> index 30a5c943..019b6fbd 100644
> --- a/htdocs/about.html
> +++ b/htdocs/about.html
> @@ -54,10 +54,12 @@ a higher chance of being implemented soon. ;-
> )
>  and SSH installed, you can check out the web pages as follows:
>  
>  
> - git clone git+ssh://username@gcc.gnu.org/sourcewar
> e/projects/gcc-home/wwwdocs.git;
> + git clone git+ssh://username@gcc.gnu.org/git/gcc-w
> wwdocs.git;
>   where username is your user name at gcc.gnu.org
>  
>  
> +For anonymous access, use
> +git://gcc.gnu.org/git/gcc-wwwdocs.git instead.
>  
>  Validating a change

Is there a web UI for viewing this new git repo?

I don't see it listed at:
  https://gcc.gnu.org/git/
(or would adding it there complicate the migration of the main repo?)

Thanks.

Dave

Re: C++ PATCH for c++/92032 - DR 1601: Promotion of enum with fixed underlying type

[Jason Merrill]

OK.

On 10/8/19 6:14 PM, Marek Polacek wrote:

I've been messing with compare_ics recently and noticed that we don't
implement CWG 1601, which should be fairly easy.

The motivating example is

   enum E : char { e };
   void f(char);
   void f(int);
   void g() {
 f(e);
   }

where the call to f was ambiguous but we should choose f(char).

Currently we give f(int) cr_promotion in standard_conversion, while
f(char) remains cr_std, which is worse than cr_promotion.  So I thought
I'd give it cr_promotion also and then add a tiebreaker to compare_ics.

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

2019-10-08  Marek Polacek  

PR c++/92032 - DR 1601: Promotion of enum with fixed underlying type.
* call.c (standard_conversion): When converting an enumeration with
a fixed underlying type to the underlying type, give it the cr_promotion
rank.
(compare_ics): Implement a tiebreaker as per CWG 1601.

* g++.dg/cpp0x/scoped_enum10.C: New test.
* g++.dg/cpp0x/scoped_enum11.C: New test.

diff --git gcc/cp/call.c gcc/cp/call.c
index 6c9acac4614..10172855d4d 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -1484,8 +1484,18 @@ standard_conversion (tree to, tree from, tree expr, bool 
c_cast_p,
  
conv = build_conv (ck_std, to, conv);
  
-  /* Give this a better rank if it's a promotion.  */

-  if (same_type_p (to, type_promotes_to (from))
+  tree underlying_type = NULL_TREE;
+  if (TREE_CODE (from) == ENUMERAL_TYPE
+ && ENUM_FIXED_UNDERLYING_TYPE_P (from))
+   underlying_type = ENUM_UNDERLYING_TYPE (from);
+
+  /* Give this a better rank if it's a promotion.
+
+To handle CWG 1601, also bump the rank if we are converting
+an enumeration with a fixed underlying type to the underlying
+type.  */
+  if ((same_type_p (to, type_promotes_to (from))
+  || (underlying_type && same_type_p (to, underlying_type)))
  && next_conversion (conv)->rank <= cr_promotion)
conv->rank = cr_promotion;
  }
@@ -10506,6 +10516,31 @@ compare_ics (conversion *ics1, conversion *ics2)
}
  }
  
+  /* [over.ics.rank]

+
+ Per CWG 1601:
+ -- A conversion that promotes an enumeration whose underlying type
+ is fixed to its underlying type is better than one that promotes to
+ the promoted underlying type, if the two are different.  */
+  if (ics1->rank == cr_promotion
+  && ics2->rank == cr_promotion
+  && UNSCOPED_ENUM_P (from_type1)
+  && ENUM_FIXED_UNDERLYING_TYPE_P (from_type1)
+  && same_type_p (from_type1, from_type2))
+{
+  tree utype = ENUM_UNDERLYING_TYPE (from_type1);
+  tree prom = type_promotes_to (from_type1);
+  if (!same_type_p (utype, prom))
+   {
+ if (same_type_p (to_type1, utype)
+ && same_type_p (to_type2, prom))
+   return 1;
+ else if (same_type_p (to_type2, utype)
+  && same_type_p (to_type1, prom))
+   return -1;
+   }
+}
+
/* Neither conversion sequence is better than the other.  */
return 0;
  }
diff --git gcc/testsuite/g++.dg/cpp0x/scoped_enum10.C 
gcc/testsuite/g++.dg/cpp0x/scoped_enum10.C
new file mode 100644
index 000..b588581cd3e
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/scoped_enum10.C
@@ -0,0 +1,37 @@
+// PR c++/92032 - DR 1601: Promotion of enumeration with fixed underlying type.
+// { dg-do compile { target c++11 } }
+
+enum E : char { e };
+enum F : int { f };
+enum G : long { g };
+enum H : unsigned { h };
+
+int f1(char);
+void f1(int);
+
+void f2(int);
+int f2(char);
+
+int f3(int);
+void f3(short);
+
+int f4(long);
+void f4(int);
+
+void f5(unsigned);
+int f5(int);
+
+int f6(unsigned);
+void f6(int);
+
+void
+test ()
+{
+  int r = 0;
+  r += f1 (e);
+  r += f2 (e);
+  r += f3 (f);
+  r += f4 (g);
+  r += f5 (f);
+  r += f6 (h);
+}
diff --git gcc/testsuite/g++.dg/cpp0x/scoped_enum11.C 
gcc/testsuite/g++.dg/cpp0x/scoped_enum11.C
new file mode 100644
index 000..e6dcfbac9d8
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/scoped_enum11.C
@@ -0,0 +1,35 @@
+// PR c++/92032 - DR 1601: Promotion of enumeration with fixed underlying type.
+// { dg-do compile { target c++11 } }
+
+enum E1 : long { e1 };
+enum E2 : short { e2 };
+
+int f1(short);
+void f1(int);
+
+void f2(int);
+int f2(short);
+
+void f3(int);
+int f3(long);
+
+int f4(short);
+void f4(long);
+
+int f5(int);
+void f5(long);
+
+int f6(unsigned int); // { dg-message "candidate" }
+void f6(long); // { dg-message "candidate" }
+
+void
+fn ()
+{
+  int r = 0;
+  r += f1 (e2);
+  r += f2 (e2);
+  r += f3 (e1);
+  r += f4 (e2);
+  r += f5 (e2);
+  r += f6 (e2); // { dg-error "ambiguous" }
+}

[Darwin, machopic 3/n, committed] Set a SYMBOL flag for indirections.

[Iain Sandoe]

We are able to treat these specially where needed in legitimate address
tests (specifically, they are guaranteed to be pointer-aligned).

tested on x86_64-darwin16, powerpc-darwin9.
applied to mainline,
thanks
Iain

gcc/ChangeLog:

2019-10-09  Iain Sandoe  

* config/darwin.c (machopic_indirect_data_reference): Set flag to
indicate that the new symbol is an indirection.
(machopic_indirect_call_target): Likewise.
* config/darwin.h (MACHO_SYMBOL_FLAG_INDIRECTION): New.
(MACHO_SYMBOL_INDIRECTION_P): New.
(MACHO_SYMBOL_FLAG_STATIC): Adjust bit number.

diff --git a/gcc/config/darwin.c b/gcc/config/darwin.c
index 679e0c2291..35d0444b5c 100644
--- a/gcc/config/darwin.c
+++ b/gcc/config/darwin.c
@@ -707,6 +707,7 @@ machopic_indirect_data_reference (rtx orig, rtx reg)
  machopic_indirection_name (orig, /*stub_p=*/false)));
 
   SYMBOL_REF_DATA (ptr_ref) = SYMBOL_REF_DATA (orig);
+  SYMBOL_REF_FLAGS (ptr_ref) |= MACHO_SYMBOL_FLAG_INDIRECTION;
 
   ptr_ref = gen_const_mem (Pmode, ptr_ref);
   machopic_define_symbol (ptr_ref);
@@ -806,6 +807,7 @@ machopic_indirect_call_target (rtx target)
 
   XEXP (target, 0) = gen_rtx_SYMBOL_REF (mode, stub_name);
   SYMBOL_REF_DATA (XEXP (target, 0)) = SYMBOL_REF_DATA (sym_ref);
+  SYMBOL_REF_FLAGS (XEXP (target, 0)) |= MACHO_SYMBOL_FLAG_INDIRECTION;
   MEM_READONLY_P (target) = 1;
   MEM_NOTRAP_P (target) = 1;
 }
diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index 7fab8694f0..f331fa1aa8 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -843,12 +843,19 @@ extern GTY(()) section * 
darwin_sections[NUM_DARWIN_SECTIONS];
 #define MACHO_SYMBOL_HIDDEN_VIS_P(RTX) \
   ((SYMBOL_REF_FLAGS (RTX) & MACHO_SYMBOL_FLAG_HIDDEN_VIS) != 0)
 
+/* Set on a symbol that is a pic stub or symbol indirection (i.e. the
+   L_x${stub,non_lazy_ptr,lazy_ptr}.  */
+
+#define MACHO_SYMBOL_FLAG_INDIRECTION ((SYMBOL_FLAG_SUBT_DEP) << 5)
+#define MACHO_SYMBOL_INDIRECTION_P(RTX) \
+  ((SYMBOL_REF_FLAGS (RTX) & MACHO_SYMBOL_FLAG_INDIRECTION) != 0)
+
 /* Set on a symbol to indicate when fix-and-continue style code
generation is being used and the symbol refers to a static symbol
that should be rebound from new instances of a translation unit to
the original instance of the data.  */
 
-#define MACHO_SYMBOL_FLAG_STATIC ((SYMBOL_FLAG_SUBT_DEP) << 5)
+#define MACHO_SYMBOL_FLAG_STATIC ((SYMBOL_FLAG_SUBT_DEP) << 6)
 #define MACHO_SYMBOL_STATIC_P(RTX) \
   ((SYMBOL_REF_FLAGS (RTX) & MACHO_SYMBOL_FLAG_STATIC) != 0)
 

[Darwin, committed] Improve Objective-C NeXT ABI version check.

[Iain Sandoe]

While doing some wider testing on a patch to remove a build warning, I noticed
we were missing a check for the case that user's ABI version was set > 2 and
the codegen was for 64 bit.

Fixed thus,
tested on x86_64-dawin16,
Applied to mainline,
thanks
Iain

gcc/ChangeLog:

2019-10-09  Iain Sandoe  

* config/darwin.c (darwin_override_options): Make the check for
Objective-C ABI version more specific for 64bit code.

diff --git a/gcc/config/darwin.c b/gcc/config/darwin.c
index 35d0444b5c..f490f622fc 100644
--- a/gcc/config/darwin.c
+++ b/gcc/config/darwin.c
@@ -3114,18 +3114,19 @@ darwin_override_options (void)
: (generating_for_darwin_version >= 9) ? 1
   : 0);
 
-  /* Objective-C family ABI 2 is only valid for next/m64 at present.  */
   if (global_options_set.x_flag_objc_abi && flag_next_runtime)
 {
-  if (TARGET_64BIT && global_options.x_flag_objc_abi < 2)
-   error_at (UNKNOWN_LOCATION, "%<-fobjc-abi-version%> must be greater"
-   " than or equal to 2 for %<-m64%> targets"
-   " with %<-fnext-runtime%>");
-  if (!TARGET_64BIT && global_options.x_flag_objc_abi >= 2)
-   error_at (UNKNOWN_LOCATION, "%<-fobjc-abi-version%> %d is not"
-   " supported on %<-m32%> targets with"
-   " %<-fnext-runtime%>",
-   global_options.x_flag_objc_abi);
+  if (TARGET_64BIT && global_options.x_flag_objc_abi != 2)
+   /* The Objective-C family ABI 2 is the only valid version NeXT/m64.  */
+   error_at (UNKNOWN_LOCATION,
+ "%<-fobjc-abi-version%> 2 must be used for 64 bit targets"
+ " with %<-fnext-runtime%>");
+  else if (!TARGET_64BIT && global_options.x_flag_objc_abi >= 2)
+   /* ABI versions 0 and 1 are the only valid versions NeXT/m32.  */
+   error_at (UNKNOWN_LOCATION,
+ "%<-fobjc-abi-version%> %d is not supported for 32 bit"
+ " targets with %<-fnext-runtime%>",
+ global_options.x_flag_objc_abi);
 }
 
   /* Don't emit DWARF3/4 unless specifically selected.  This is a

[PR target/85401][v2] Add test-cases

[coypu]

On Fri, Oct 04, 2019 at 02:28:55PM -0600, Jeff Law wrote:
> On 10/4/19 1:43 PM, co...@sdf.org wrote:
> > On Tue, Oct 01, 2019 at 01:26:16PM -0600, Jeff Law wrote:
> >> On 9/30/19 2:45 PM, co...@sdf.org wrote:
> >>> On Mon, Sep 30, 2019 at 11:46:24AM -0400, Vladimir Makarov wrote:
>  Yes, the patch is mostly ok.  You can commit it into the trunk after
>  applying changes mentioned below. If you do not have a write access, let 
>  me
>  know I'll commit the patch by myself.
> >>>
> >>> I don't have commit access. It would be nice if you committed it :)
> >> I took care of the nits and committed the patch.
> >>
> >>
> >>>
>  It would be nice to add a small test too.  But it is not obligatory for 
>  this
>  case as the patch is obvious and it might be hard to create a small test 
>  to
>  reproduce the bug.
> >>>
> >>> I have the C code that produces this failure. I can creduce it, but I'm
> >>> not sure there's a relationship between it and the bug.
> >>> Doing unrelated changes (adding instruction scheduling) to vax also hid 
> >>> it.
> >>>
> >>> Is this kind of test still valuable?
> >> Often they are.
> >>
> >> jeff
> > 
> > Here's the two tests I used. It might be too machine-made.
> > One is in the vax specific directory since it needed -fno-pic.
> > 
> > 
> > 2019-10-04  Maya Rashish  
> > * gcc.c-torture/compile/pr85401-2.c: New test.
> > * gcc.target/vax/pr85401-1.c: New test.
> ISTM that both should be in c-torture.  We can use dg-* things in there too.
> 
> jeff

Sorry. I didn't realize while sending that they both produce the same
crash.

I was trying to produce test cases that don't produce warnings, and
didn't notice the change. The original second test case has an
unintialized variable use, so I am omitting it.


2019-10-09  Maya Rashish  
* gcc.c-torture/compile/pr85401: New test.


diff --git a/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c 
b/gcc/testsuite/gcc.c-torture/compile/pr85401-2.c
new file mode 100644
index 000..1d68d0b
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr85401.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int h(void);
+int i(int);
+
+struct a b;
+struct a {
+  unsigned c : 4;
+} d() {
+  int e, f = b.c << 2, g = h();
+  for (; g;)
+;
+  if (e == 0)
+if (f)
+  i(f);
+  return b;
+}

PowerPC future machine patches, version 5

[Michael Meissner]

I'm going to re-issue the outstanding 'future' patches as separate threads
under this message.

Compared to the original V4 patches, I have tried to break the larger patches
(particularly #4) into smaller chunks.

One of the V4 patches that I submitted was wrong, and this series of patches
corrects the issue (the issue was I used PC-relative offsets to add to a
register, and the current instruction definition does not support that).  The
code modified dealt with vector extracts where the vector has a PC-relative
address, but the insn I added also broke normal switch statements.

This series of patches only adds one new constraint (em) that matches any
memory operand that does not use prefixed addressing (including PC-relative
addressing).  In some of the previous V4 patches, I added two constraints.

I adjusted the code to address several of the previous comments:

   * Eliminate having a TARGET_ test before calling a function that does
 the same test;

   * Fixing vector moves instruction length.

There are currently 15 patches in this set (as of this writing).

   * Patches 1-10 provide the necessary functionality;

   * Patch 11 sets the default for Linux 64-bit to use PC-relative and prefixed
 instructions.

   * Patches 12-14 are the tests to the test suite.

   * Patch 15 is a patch to change how @pcrel is emitted to prevent some mixups
 (like I had).

I had originally posted a patch to support PCREL_OPT in the V3 series.  Given
your comments, I plan to re-implement it, so it is not part of this patch set.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] V5, #1 of 15: Support 34-bit offsets for prefixed instructions

[Michael Meissner]

This patch adds support in the various functions that check memory offsets for
the 34-bit offset with prefixed instructions on the 'future' machine.

Along with the other patches, I have done bootstraps on a little endian power8
system, and there were no regressions in the test suite.  Can I check this into
the trunk?

2019-10-08  Michael Meissner  

* config/rs6000/rs6000.c (quad_address_p): Add check for prefixed
addresses.
(mem_operand_gpr): Add check for prefixed addresses.
(mem_operand_ds_form): Add check for prefixed addresses.
(rs6000_legitimate_offset_address_p): If we support prefixed
addresses, check for a 34-bit offset instead of 16-bit.
(rs6000_legitimate_address_p): Add check for prefixed addresses.
Do not allow load/store with update if the address is prefixed.
(rs6000_mode_dependent_address):  If we support prefixed
addresses, check for a 34-bit offset instead of 16-bit.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 276713)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -7250,6 +7250,13 @@ quad_address_p (rtx addr, machine_mode m
   if (VECTOR_MODE_P (mode) && !mode_supports_dq_form (mode))
 return false;
 
+  /* Is this a valid prefixed address?  If the bottom four bits of the offset
+ are non-zero, we could use a prefixed instruction (which does not have the
+ DQ-form constraint that the traditional instruction had) instead of
+ forcing the unaligned offset to a GPR.  */
+  if (address_is_prefixed (addr, mode, NON_PREFIXED_DQ))
+return true;
+
   if (GET_CODE (addr) != PLUS)
 return false;
 
@@ -7351,6 +7358,13 @@ mem_operand_gpr (rtx op, machine_mode mo
   && legitimate_indirect_address_p (XEXP (addr, 0), false))
 return true;
 
+  /* Allow prefixed instructions if supported.  If the bottom two bits of the
+ offset are non-zero, we could use a prefixed instruction (which does not
+ have the DS-form constraint that the traditional instruction had) instead
+ of forcing the unaligned offset to a GPR.  */
+  if (address_is_prefixed (addr, mode, NON_PREFIXED_DS))
+return true;
+
   /* Don't allow non-offsettable addresses.  See PRs 83969 and 84279.  */
   if (!rs6000_offsettable_memref_p (op, mode, false))
 return false;
@@ -7385,6 +7399,13 @@ mem_operand_ds_form (rtx op, machine_mod
   int extra;
   rtx addr = XEXP (op, 0);
 
+  /* Allow prefixed instructions if supported.  If the bottom two bits of the
+ offset are non-zero, we could use a prefixed instruction (which does not
+ have the DS-form constraint that the traditional instruction had) instead
+ of forcing the unaligned offset to a GPR.  */
+  if (address_is_prefixed (addr, mode, NON_PREFIXED_DS))
+return true;
+
   if (!offsettable_address_p (false, mode, addr))
 return false;
 
@@ -7754,7 +7775,10 @@ rs6000_legitimate_offset_address_p (mach
   break;
 }
 
-  return SIGNED_16BIT_OFFSET_EXTRA_P (offset, extra);
+  if (TARGET_PREFIXED_ADDR)
+return SIGNED_34BIT_OFFSET_EXTRA_P (offset, extra);
+  else
+return SIGNED_16BIT_OFFSET_EXTRA_P (offset, extra);
 }
 
 bool
@@ -8651,6 +8675,11 @@ rs6000_legitimate_address_p (machine_mod
   && mode_supports_pre_incdec_p (mode)
   && legitimate_indirect_address_p (XEXP (x, 0), reg_ok_strict))
 return 1;
+
+  /* Handle prefixed addresses (PC-relative or 34-bit offset).  */
+  if (address_is_prefixed (x, mode, NON_PREFIXED_DEFAULT))
+return 1;
+
   /* Handle restricted vector d-form offsets in ISA 3.0.  */
   if (quad_offset_p)
 {
@@ -8709,7 +8738,11 @@ rs6000_legitimate_address_p (machine_mod
  || (!avoiding_indexed_address_p (mode)
  && legitimate_indexed_address_p (XEXP (x, 1), reg_ok_strict)))
   && rtx_equal_p (XEXP (XEXP (x, 1), 0), XEXP (x, 0)))
-return 1;
+{
+  /* There is no prefixed version of the load/store with update.  */
+  rtx addr = XEXP (x, 1);
+  return !address_is_prefixed (addr, mode, NON_PREFIXED_DEFAULT);
+}
   if (reg_offset_p && !quad_offset_p
   && legitimate_lo_sum_address_p (mode, x, reg_ok_strict))
 return 1;
@@ -8773,7 +8806,10 @@ rs6000_mode_dependent_address (const_rtx
{
  HOST_WIDE_INT val = INTVAL (XEXP (addr, 1));
  HOST_WIDE_INT extra = TARGET_POWERPC64 ? 8 : 12;
- return !SIGNED_16BIT_OFFSET_EXTRA_P (val, extra);
+ if (TARGET_PREFIXED_ADDR)
+   return !SIGNED_34BIT_OFFSET_EXTRA_P (val, extra);
+ else
+   return !SIGNED_16BIT_OFFSET_EXTRA_P (val, extra);
}
   break;
 

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] V5, #2 of 15: Fix prefixed instruction length for some 128-bit types

[Michael Meissner]

This patch fixes the prefixed and non-prefixed instruction sizes for the
128-bit types that aren't loaded into 128-bit vectors (TDmode, TFmode, IFmode,
PTImode).

Along with the other patches, I have done bootstraps on a little endian power8
system, and there were no regressions in the test suite.  Can I check this into
the trunk?

2019-10-08  Michael Meissner  

* config/rs6000/rs6000.md (mov_64bit_dm): Set prefixed and
non-prefixed length.
(movtd_64bit_nodm): Set prefixed and non-prefixed length.
(mov_ppc64): Set prefixed and non-prefixed length.

Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 276713)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -7773,9 +7773,13 @@ (define_insn_and_split "*mov_64bit
   "#"
   "&& reload_completed"
   [(pc)]
-{ rs6000_split_multireg_move (operands[0], operands[1]); DONE; }
-  [(set_attr "length" "8")
-   (set_attr "isa" "*,*,*,*,*,*,*,*,p8v,p8v")])
+{
+  rs6000_split_multireg_move (operands[0], operands[1]);
+  DONE;
+}
+  [(set_attr "isa" "*,*,*,*,*,*,*,*,p8v,p8v")
+   (set_attr "non_prefixed_length" "8")
+   (set_attr "prefixed_length" "20")])
 
 (define_insn_and_split "*movtd_64bit_nodm"
   [(set (match_operand:TD 0 "nonimmediate_operand" "=m,d,d,Y,r,r")
@@ -7786,8 +7790,12 @@ (define_insn_and_split "*movtd_64bit_nod
   "#"
   "&& reload_completed"
   [(pc)]
-{ rs6000_split_multireg_move (operands[0], operands[1]); DONE; }
-  [(set_attr "length" "8,8,8,12,12,8")])
+{
+  rs6000_split_multireg_move (operands[0], operands[1]);
+  DONE;
+}
+  [(set_attr "non_prefixed_length" "8")
+   (set_attr "prefixed_length" "20")])
 
 (define_insn_and_split "*mov_32bit"
   [(set (match_operand:FMOVE128_FPR 0 "nonimmediate_operand" "=m,d,d,d,Y,r,r")
@@ -8984,7 +8992,8 @@ (define_insn "*mov_ppc64"
   return rs6000_output_move_128bit (operands);
 }
   [(set_attr "type" "store,store,load,load,*,*")
-   (set_attr "length" "8")])
+   (set_attr "prefixed_length" "20")
+   (set_attr "non_prefixed_length" "8")])
 
 (define_split
   [(set (match_operand:TI2 0 "int_reg_operand")

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] V5, #3 of 15: Deal with prefixed instructions in rs6000_insn_cost

[Michael Meissner]

This patch is a simplification of the previous patch to adjust the rtx insn
cost for prefixed instructions.  Rather than making it a separate function with
only one caller, I folded the code into rs6000_insn_cost.

You had asked for this to be a separate patch, so it is in this patch.

The basic problem is if there is no explicit cost predicate, rs6000_insn_cost
uses the instruction size to figure out how many instructions are present, and
make the cost a fact on that.  Since prefixed instructions are 12 bytes within
GCC (to deal with the implicit NOP), if we did not do this change, the
optimizers would try to save registers from prefixed loads because they thought
the load was more expensive.

Along with the other patches, I have done bootstraps on a little endian power8
system, and there were no regressions in the test suite.  Can I check this into
the trunk?

2019-10-08  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_insn_cost): Do not make prefixed
instructions cost more because they are larger in size.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 276715)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -20972,14 +20972,38 @@ rs6000_insn_cost (rtx_insn *insn, bool s
   if (recog_memoized (insn) < 0)
 return 0;
 
-  if (!speed)
-return get_attr_length (insn);
+  if (speed)
+{
+  int cost = get_attr_cost (insn);
+  if (cost > 0)
+   return cost;
+}
 
-  int cost = get_attr_cost (insn);
-  if (cost > 0)
-return cost;
+  int cost;
+  int length = get_attr_length (insn);
+  int n = length / 4;
+
+  /* How many real instructions are generated for this insn?  This is slightly
+ different from the length attribute, in that the length attribute counts
+ the number of bytes.  With prefixed instructions, we don't want to count a
+ prefixed instruction (length 12 bytes including possible NOP) as taking 3
+ instructions, but just one.  */
+  if (length >= 12 && get_attr_prefixed (insn) == PREFIXED_YES)
+{
+  /* Single prefixed instruction.  */
+  if (length == 12)
+   n = 1;
+
+  /* A normal instruction and a prefixed instruction (16) or two back
+to back prefixed instructions (20).  */
+  else if (length == 16 || length == 20)
+   n = 2;
+
+  /* Guess for larger instruction sizes.  */
+  else
+   n = 2 + (length - 20) / 4;
+}
 
-  int n = get_attr_length (insn) / 4;
   enum attr_type type = get_attr_type (insn);
 
   switch (type)

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] V5, #4 of 15: Update predicates

[Michael Meissner]

This patch updates the predicates.

It allows lwa_operand (used by extendsidi2) to generate offsets that can be
used with PLWA but not LWA (due to LWA using the DS instruction format).

It also adds two new predicates that disallow prefixed memory that will used in
patches #5 and #7.

Along with the other patches, I have done bootstraps on a little endian power8
system, and there were no regressions in the test suite.  Can I check this into
the trunk?

2019-10-08  Michael Meissner  

* config/rs6000/predicates.md (lwa_operand): Allow using PLWA to
generate sign extend with odd offsets.
(non_prefixed_memory): New predicate.
(reg_or_non_prefixed_memory): New predicate.

Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 276713)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -932,6 +932,13 @@ (define_predicate "lwa_operand"
 return false;
 
   addr = XEXP (inner, 0);
+
+  /* The LWA instruction uses the DS-form format where the bottom two bits of
+ the offset must be 0.  The prefixed PLWA does not have this
+ restriction.  */
+  if (address_is_prefixed (addr, DImode, NON_PREFIXED_DS))
+return true;
+
   if (GET_CODE (addr) == PRE_INC
   || GET_CODE (addr) == PRE_DEC
   || (GET_CODE (addr) == PRE_MODIFY
@@ -1807,3 +1814,21 @@ (define_predicate "pcrel_external_addres
 (define_predicate "pcrel_local_or_external_address"
   (ior (match_operand 0 "pcrel_local_address")
(match_operand 0 "pcrel_external_address")))
+
+;; Return 1 if op is a memory operand that is not prefixed.
+(define_predicate "non_prefixed_memory"
+  (match_code "mem")
+{
+  if (!memory_operand (op, mode))
+return false;
+
+  return !address_is_prefixed (XEXP (op, 0), mode, NON_PREFIXED_DEFAULT);
+})
+
+;; Return 1 if op is either a register operand or a memory operand that does
+;; not use a prefixed address.
+(define_predicate "reg_or_non_prefixed_memory"
+  (match_code "reg,subreg,mem")
+{
+  return (gpc_reg_operand (op, mode) || non_prefixed_memory (op, mode));
+})

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] Modify simplify_truncation to handle extended CONST_INT.

[Jim Wilson]

This addresses PR 91860 which has four testcases triggering internal errors.
The problem here is that in combine when handling debug insns, we are trying
to substitute
(sign_extend:DI (const_int 8160 [0x1fe0]))
as the value for
(reg:DI 78 [ _9 ])
in the debug insn
(debug_insn 29 28 30 2 (var_location:QI d (subreg:QI (reg:DI 78 [ _9 ]) 0)) 
"tmp4.c":11:5 -1
 (nil))

The place where this starts to go wrong is in simplify_truncation, where it
tries to compare the size of the original mode VOIDmode with the subreg mode
QI and decides that we need to sign extend the constant to convert it from
VOIDmode to QImode.  We actually need a truncation not a extension here.  Also
note that the GET_MODE_UNIT_PRECISION (VOIDmode) isn't useful.  We can fix
this by changing the mode to MAX_MODE_INT, as the CONST_INT should already be
valid for the largest supported integer mode.  There are already a number of
other places in simplify-rtx.c that do the same thing.

This was tested with rv32/newlib and rv64/linux cross builds and make checks.
There were no regressions.  The new tests all fail for rv64 without the patch,
and work with the patch.

OK?

Jim

gcc/
PR rtl-optimization/91860
* simplify-rtx.c (simplify_truncation): If origmode is VOIDmode, set
it to MAX_MODE_INT.

gcc/testsuite/
PR rtl-optimization/91860
* gcc.dg/pr91860-1.c: New testcase.
* gcc.dg/pr91860-2.c: New testcase.
* gcc.dg/pr91860-3.c: New testcase.
* gcc.dg/pr91860-4.c: New testcase.
---
 gcc/simplify-rtx.c   | 11 +++
 gcc/testsuite/gcc.dg/pr91860-1.c | 18 ++
 gcc/testsuite/gcc.dg/pr91860-2.c | 13 +
 gcc/testsuite/gcc.dg/pr91860-3.c | 15 +++
 gcc/testsuite/gcc.dg/pr91860-4.c | 24 
 5 files changed, 81 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr91860-1.c
 create mode 100644 gcc/testsuite/gcc.dg/pr91860-2.c
 create mode 100644 gcc/testsuite/gcc.dg/pr91860-3.c
 create mode 100644 gcc/testsuite/gcc.dg/pr91860-4.c

diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index 9a70720c764..8593010acf4 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -635,6 +635,17 @@ simplify_truncation (machine_mode mode, rtx op,
 is larger than the origmode, we can just extend to the appropriate
 mode.  */
   machine_mode origmode = GET_MODE (XEXP (op, 0));
+
+  /* This can happen when called from inside combine, if we have a zero
+or sign extend of a CONST_INT.  We assume that all of the bits of the
+constant are significant here.  If we don't do this, then we try
+to extend VOIDmode, which takes us to simplify_const_unary_operation
+which assumes that a VOIDmode operand has the destination mode,
+which can then trigger an abort in a wide_int::from call if the
+constant isn't already valid for that mode.  */
+  if (origmode == VOIDmode)
+   origmode = MAX_MODE_INT;
+
   if (mode == origmode)
return XEXP (op, 0);
   else if (precision <= GET_MODE_UNIT_PRECISION (origmode))
diff --git a/gcc/testsuite/gcc.dg/pr91860-1.c b/gcc/testsuite/gcc.dg/pr91860-1.c
new file mode 100644
index 000..e715040e33d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr91860-1.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-Og -fipa-cp -g --param=max-combine-insns=3" } */
+
+char a;
+int b;
+
+static void
+bar (short d)
+{
+  d <<= __builtin_sub_overflow (0, d, &a);
+  b = __builtin_bswap16 (~d);
+}
+
+void
+foo (void)
+{
+  bar (21043);
+}
diff --git a/gcc/testsuite/gcc.dg/pr91860-2.c b/gcc/testsuite/gcc.dg/pr91860-2.c
new file mode 100644
index 000..7b44e648ca6
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr91860-2.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-Og -fexpensive-optimizations -fno-tree-fre -g 
--param=max-combine-insns=4" } */
+
+unsigned a, b, c;
+void
+foo (void)
+{
+  unsigned short e;
+  __builtin_mul_overflow (0, b, &a);
+  __builtin_sub_overflow (59347, 9, &e);
+  e <<= a & 5;
+  c = e;
+}
diff --git a/gcc/testsuite/gcc.dg/pr91860-3.c b/gcc/testsuite/gcc.dg/pr91860-3.c
new file mode 100644
index 000..2b488cc9048
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr91860-3.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-Og -g2 --param=max-combine-insns=3" } */
+
+int a, b;
+
+void
+foo (void)
+{
+  unsigned short d = 46067;
+  int e = e;
+  d <<= __builtin_mul_overflow (~0, e, &a);
+  d |= -68719476735;
+  b = d;
+}
+
diff --git a/gcc/testsuite/gcc.dg/pr91860-4.c b/gcc/testsuite/gcc.dg/pr91860-4.c
new file mode 100644
index 000..36f2bd55c64
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr91860-4.c
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target int128 } */
+/* { dg-options "-O2 -g" } */
+
+typedef unsigned char u8;
+typedef unsigned int u32;
+typedef unsigned __int128 u128;
+
+u32 b, c;
+
+static inline
+u128 bar (u8 d,

Re: Add std::copy_n overload for istreambuf_iterator

[Christophe Lyon]

On Fri, 4 Oct 2019 at 07:01, François Dumont  wrote:

> On 9/27/19 1:00 PM, Jonathan Wakely wrote:
> > On 19/07/19 23:37 +0200, François Dumont wrote:
> >> It sounds reasonable to overload std::copy_n for istreambuf_iterator.
> > I wonder whether it's worth doing:
> >
> > #if __cplusplus >= 201703L
> >if constexpr (is_same_v<_OutputIterator, _CharT*>)
> >  return __result + __it._M_sbuf->sgetn(__result, __n);
> >else
> >  {
> > #endif
> >  ...
> > #if __cplusplus >= 201703L
> >  }
> > #endif
> >
> > We could extend that to also work for basic_string<_CharT>::iterator
> > and vector<_CharT>::iterator too if we wanted.
> >
> > I'm not sure if it will perform any better than the code below (it's
> > approximately equivalent) but it should result in smaller binaries, as we
> > wouldn't be instantiating the code below when outputting to a pointer
> > or contiguous iterator.
> >
> > We don't need to do that now, it can be a separate patch later (if we
> > do it at all).
>
> Very good remark, I hadn't check streambuf to find out if there were
> better to do. For me it is the streambuf method to target for an
> std::copy_n overload.
>
> So here is a new proposal much simpler. I see no reason to enable it
> only for char types, is there ?
>
> Once the other patch on copy/copy_backward... algos is in I'll provide
> what necessary to benefit from the same optimization for std::deque
> iterators and in Debug mode.
>
> >
> >> +#endif
> >
> > Because the matching #if is more than 40 lines away, please add a
> > comment noting the condition that this corresponds to, i.e.
> >
> > #endif // C++11
> Ok, done even if there is no 40 lines anymore. And also added it in
> stl_algo.h.
> >
> >> +
> >>   template
> >> typename __gnu_cxx::__enable_if<__is_char<_CharT>::__value,
> >>   istreambuf_iterator<_CharT> >::__type
> >> diff --git a/libstdc++-v3/include/std/streambuf
> >> b/libstdc++-v3/include/std/streambuf
> >> index d9ca981d704..4f62ebf4d95 100644
> >> --- a/libstdc++-v3/include/std/streambuf
> >> +++ b/libstdc++-v3/include/std/streambuf
> >> @@ -155,6 +155,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >> __copy_move_a2(istreambuf_iterator<_CharT2>,
> >>istreambuf_iterator<_CharT2>, _CharT2*);
> >>
> >> +#if __cplusplus >= 201103L
> >> +  template >> _OutputIterator>
> >> +friend typename enable_if<__is_char<_CharT2>::__value,
> >> +  _OutputIterator>::type
> >> +copy_n(istreambuf_iterator<_CharT2>, _Size, _OutputIterator);
> >> +#endif
> >> +
> >>   template
> >> friend typename
> >> __gnu_cxx::__enable_if<__is_char<_CharT2>::__value,
> >>   istreambuf_iterator<_CharT2> >::__type
> >> diff --git
> >> a/libstdc++-v3/testsuite/25_algorithms/copy_n/istreambuf_iterator.cc
> >> b/libstdc++-v3/testsuite/25_algorithms/copy_n/istreambuf_iterator.cc
> >> new file mode 100644
> >> index 000..ebd769cf7c0
> >> --- /dev/null
> >> +++ b/libstdc++-v3/testsuite/25_algorithms/copy_n/istreambuf_iterator.cc
> >> @@ -0,0 +1,59 @@
> >> +// Copyright (C) 2019 Free Software Foundation, Inc.
> >> +//
> >> +// This file is part of the GNU ISO C++ Library.  This library is free
> >> +// software; you can redistribute it and/or modify it under the
> >> +// terms of the GNU General Public License as published by the
> >> +// Free Software Foundation; either version 3, or (at your option)
> >> +// any later version.
> >> +
> >> +// This library is distributed in the hope that it will be useful,
> >> +// but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> +// GNU General Public License for more details.
> >> +
> >> +// You should have received a copy of the GNU General Public License
> >> along
> >> +// with this library; see the file COPYING3.  If not see
> >> +// .
> >> +
> >> +// { dg-do run { target c++11 } }
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include 
> >> +
> >> +void test01()
> >> +{
> >> +  std::stringstream ss("12345");
> >> +
> >> +  std::string ostr(5, '0');
> >> +  typedef std::istreambuf_iterator istrb_ite;
> >> +  std::copy_n(istrb_ite(ss), 0, ostr.begin());
> >> +  VERIFY( ostr.front() == '0' );
> >
> > I'd like to see a check here that the value returned from copy_n is
> > equal to ostr.begin().
> >
> >> +
> >> +  std::copy_n(istrb_ite(ss), 2, ostr.begin());
> >> +  VERIFY( ostr == "12000" );
> >
> > And equal to ostr.begin() + 2.
> >
> >> +
> >> +  std::copy_n(istrb_ite(ss), 3, ostr.begin() + 2);
> >> +  VERIFY( ostr == "12345" );
> >
> > And equal to ostr.begin() + 5 here.
> Done.
> >
> >> +}
> >> +
> >> +void test02()
> >> +{
> >> +  std::stringstream ss("12345");
> >> +
> >> +  std::string ostr(5, '0');
> >> +  typedef std::istreambuf_iterator istrb_ite;
> >> +
> >> +  istrb_ite ibfit(ss);
> >> +  std::copy_n(ibfit, 3, std::copy_n(ibfit, 2, ostr.begin())

[PATCH] V5, #5 of 15: Support -fstack-protect and large stack frames

[Michael Meissner]

This patch allows -fstack-protect to work with large stack frames.

It does so by adding a new constraint (em) that matches normal memory that does
not use a prefixed address (including PC-relative addresses).

The stack protect test and set functions now can take indexed address forms,
and there is a define_expand to make sure memory would not use a prefixed
address.

Along with the other patches, I have done bootstraps on a little endian power8
system, and there were no regressions in the test suite.  Can I check this into
the trunk?

2019-10-08  Michael Meissner  

* config/rs6000/constraints.md (em constraint): New constraint.
* config/rs6000/rs6000-protos.h (make_memory_non_prefixed): New
declaration.
* config/rs6000/rs6000.c (make_memory_non_prefixed): New function
to return a traditional non-prefixed instruction.
* config/rs6000/rs6000.md (stack_protect_setdi): Make sure both
memory operands are not prefixed.
(stack_protect_testdi): Make sure both memory operands are not
prefixed.
* doc/md.texi (PowerPC constraints): Document the em constraint.

Index: gcc/config/rs6000/constraints.md
===
--- gcc/config/rs6000/constraints.md(revision 276713)
+++ gcc/config/rs6000/constraints.md(working copy)
@@ -210,6 +210,11 @@ several times, or that might not access
   (and (match_code "mem")
(match_test "GET_RTX_CLASS (GET_CODE (XEXP (op, 0))) != RTX_AUTOINC")))
 
+(define_memory_constraint "em"
+  "A memory operand that does not contain a prefixed address."
+  (and (match_code "mem")
+   (match_test "non_prefixed_memory (op, mode)")))
+
 (define_memory_constraint "Q"
   "Memory operand that is an offset from a register (it is usually better
 to use @samp{m} or @samp{es} in @code{asm} statements)"
Index: gcc/config/rs6000/rs6000-protos.h
===
--- gcc/config/rs6000/rs6000-protos.h   (revision 276713)
+++ gcc/config/rs6000/rs6000-protos.h   (working copy)
@@ -192,6 +192,7 @@ extern enum insn_form address_to_insn_fo
 extern bool prefixed_load_p (rtx_insn *);
 extern bool prefixed_store_p (rtx_insn *);
 extern bool prefixed_paddi_p (rtx_insn *);
+extern rtx make_memory_non_prefixed (rtx);
 extern void rs6000_asm_output_opcode (FILE *);
 extern void rs6000_final_prescan_insn (rtx_insn *, rtx [], int);
 
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 276717)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -24972,6 +24972,34 @@ prefixed_paddi_p (rtx_insn *insn)
   return (iform == INSN_FORM_PCREL_EXTERNAL || iform == INSN_FORM_PCREL_LOCAL);
 }
 
+/* Make a memory address non-prefixed if it is prefixed.  */
+
+rtx
+make_memory_non_prefixed (rtx mem)
+{
+  gcc_assert (MEM_P (mem));
+
+  rtx old_addr = XEXP (mem, 0);
+  if (address_is_prefixed (old_addr, GET_MODE (mem), NON_PREFIXED_DEFAULT))
+{
+  rtx new_addr;
+
+  if (GET_CODE (old_addr) == PLUS
+ && (REG_P (XEXP (old_addr, 0)) || SUBREG_P (XEXP (old_addr, 0)))
+ && CONST_INT_P (XEXP (old_addr, 1)))
+   {
+ rtx tmp_reg = force_reg (Pmode, XEXP (old_addr, 1));
+ new_addr = gen_rtx_PLUS (Pmode, XEXP (old_addr, 0), tmp_reg);
+   }
+  else
+   new_addr = force_reg (Pmode, old_addr);
+
+  mem = change_address (mem, VOIDmode, new_addr);
+}
+
+  return mem;
+}
+
 /* Whether the next instruction needs a 'p' prefix issued before the
instruction is printed out.  */
 static bool next_insn_prefixed_p;
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 276716)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -11531,9 +11531,25 @@ (define_insn "stack_protect_setsi"
   [(set_attr "type" "three")
(set_attr "length" "12")])
 
-(define_insn "stack_protect_setdi"
-  [(set (match_operand:DI 0 "memory_operand" "=Y")
-   (unspec:DI [(match_operand:DI 1 "memory_operand" "Y")] UNSPEC_SP_SET))
+(define_expand "stack_protect_setdi"
+  [(parallel [(set (match_operand:DI 0 "memory_operand")
+  (unspec:DI [(match_operand:DI 1 "memory_operand")]
+  UNSPEC_SP_SET))
+ (set (match_scratch:DI 2)
+  (const_int 0))])]
+  "TARGET_64BIT"
+{
+  if (TARGET_PREFIXED_ADDR)
+{
+  operands[0] = make_memory_non_prefixed (operands[0]);
+  operands[1] = make_memory_non_prefixed (operands[1]);
+}
+})
+
+(define_insn "*stack_protect_setdi"
+  [(set (match_operand:DI 0 "non_prefixed_memory" "=em")
+   (unspec:DI [(match_operand:DI 1 "non_prefixed_memory" "em")]
+  UNSPEC_SP_SET))
(set (match_scratch:DI 2 "=&r") (const_int 0))]
   "TARGET_64BIT"
   "ld%U1%X1 %2,%1\;std%U0%X0 %2,%0\;li %2,0"
@@ -11577,10 +11593,27 @@ (define_insn "

[PATCH] PR fortran/92019 -- BOZ cannot be an array index

[Steve Kargl]

The attach patch fixes an ICE caused by the use of a bOZ as
an array index.  Tested on x86_64-*-freebsd.  OK to commit?

2019-10-09  Steven G. Kargl  

PR fortran/92019
* array.c (match_subscript): BOZ cannot be an array subscript.
 
2019-10-09  Steven G. Kargl  

PR fortran/92019
* gfortran.dg/pr92019.f90: New test.

-- 
Steve
Index: gcc/fortran/array.c
===
--- gcc/fortran/array.c	(revision 276705)
+++ gcc/fortran/array.c	(working copy)
@@ -66,6 +66,7 @@ match_subscript (gfc_array_ref *ar, int init, bool mat
   match m = MATCH_ERROR;
   bool star = false;
   int i;
+  bool saw_boz = false;
 
   i = ar->dimen + ar->codimen;
 
@@ -91,6 +92,12 @@ match_subscript (gfc_array_ref *ar, int init, bool mat
   else if (!star)
 m = gfc_match_expr (&ar->start[i]);
 
+  if (ar->start[i] && ar->start[i]->ts.type == BT_BOZ)
+{
+  gfc_error ("Invalid BOZ literal constant used in subscript at %C");
+  saw_boz = true;
+}
+
   if (m == MATCH_NO)
 gfc_error ("Expected array subscript at %C");
   if (m != MATCH_YES)
@@ -117,6 +124,12 @@ end_element:
   else
 m = gfc_match_expr (&ar->end[i]);
 
+  if (ar->end[i] && ar->end[i]->ts.type == BT_BOZ)
+{
+  gfc_error ("Invalid BOZ literal constant used in subscript at %C");
+  saw_boz = true;
+}
+
   if (m == MATCH_ERROR)
 return MATCH_ERROR;
 
@@ -132,6 +145,12 @@ end_element:
   m = init ? gfc_match_init_expr (&ar->stride[i])
 	   : gfc_match_expr (&ar->stride[i]);
 
+  if (ar->stride[i] && ar->stride[i]->ts.type == BT_BOZ)
+	{
+	  gfc_error ("Invalid BOZ literal constant used in subscript at %C");
+	  saw_boz = true;
+	}
+
   if (m == MATCH_NO)
 	gfc_error ("Expected array subscript stride at %C");
   if (m != MATCH_YES)
@@ -142,7 +161,7 @@ matched:
   if (star)
 ar->dimen_type[i] = DIMEN_STAR;
 
-  return MATCH_YES;
+  return (saw_boz ? MATCH_ERROR : MATCH_YES);
 }
 
 
Index: gcc/testsuite/gfortran.dg/pr92019.f90
===
--- gcc/testsuite/gfortran.dg/pr92019.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr92019.f90	(working copy)
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR fortran/92019
+program foo
+  integer :: a(4) = [1, 2, 3, 4]
+  print *, a(z'1')! { dg-error "Invalid BOZ literal constant" }
+  print *, a(1:z'3')  ! { dg-error "Invalid BOZ literal constant" }
+  print *, a(1:2:z'2')! { dg-error "Invalid BOZ literal constant" }
+  print *, a([z'2',z'1']) ! { dg-error "cannot appear in an array constructor" }
+end program foo

[PATCH] V5, #6 of 15: Make vector load/store instruction length correct with prefixed addresses

[Michael Meissner]

This patch updates the instruction length for 128-bit move insns for types that
go into a single vector register.  It is a lot simpler than the previous patch,
which was written before I added the prefixed_length and non_prefixed_length
attributes.

Along with the other patches, I have done bootstraps on a little endian power8
system, and there were no regressions in the test suite.  Can I check this into
the trunk?

2019-10-08  Michael Meissner  

* config/rs6000/vsx.md (vsx_mov_64bit): Make sure the
instruction length is correct for prefixed loads and stores.

Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md(revision 276713)
+++ gcc/config/rs6000/vsx.md(working copy)
@@ -1149,10 +1149,14 @@ (define_insn "vsx_mov_64bit"
"vecstore,  vecload,   vecsimple, mffgpr,mftgpr,load,
 store, load,  store, *, vecsimple, 
vecsimple,
 vecsimple, *, *, vecstore,  vecload")
-   (set_attr "length"
+   (set_attr "non_prefixed_length"
"*, *, *, 8, *, 8,
 8, 8, 8, 8, *, *,
 *, 20,8, *, *")
+   (set_attr "prefixed_length"
+   "*, *, *, 8, *, 20,
+20,20,20,8, *, *,
+*, 20,8, *, *")
(set_attr "isa"
",   ,   ,   *, *, *,
 *, *, *, *, p9v,   *,

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: C++ PATCH for C++20 P0388R4 (conversions to arrays of unknown bounds) and CWG 1307 (c++/91364, c++/69531)

[Marek Polacek]

On Tue, Oct 08, 2019 at 01:50:17PM -0400, Jason Merrill wrote:
> > > That sounds like a bug in grok_reference_init; it isn't properly
> > > implementing
> > > 
> > > "Otherwise, if the initializer list has a single element of type E and
> > > either T is not a reference type or its
> > > referenced type is reference-related to E, the object or reference is
> > > initialized from that element"
> > 
> > Can that be fixed in a follow up?
> 
> Sure.

I'll open a PR.

> > @@ -9888,6 +9900,7 @@ comp_ptr_ttypes_real (tree to, tree from, int constp)
> >   {
> > bool to_more_cv_qualified = false;
> > bool is_opaque_pointer = false;
> > +  bool is_comp_array = false;
> > for (; ; to = TREE_TYPE (to), from = TREE_TYPE (from))
> >   {
> > @@ -9920,9 +9933,16 @@ comp_ptr_ttypes_real (tree to, tree from, int constp)
> > if (VECTOR_TYPE_P (to))
> > is_opaque_pointer = vector_targets_convertible_p (to, from);
> > +  if (TREE_CODE (to) == ARRAY_TYPE)
> > +   /* P0388R4 allows a conversion from int[N] to int[] but not the
> > +  other way round.  */
> > +   is_comp_array = comp_array_types (to, from, bounds_first,
> > + /*tlq_match=*/false);
> 
> This seems to stop iterating when we first see an array, but 7.3.5
> [conv.qual] seems to allow conversion to unknown bounds at multiple levels,
> and even qualification conversion of an array of pointers, e.g.
> 
> int *ar[4];
> const int *(&arp)[] = ar;

(Should be const int *const (&arp)[] = ar; I believe.)

Yup, this is us lacking DR 330 which I'd been meaning to fix separately, but the
following patch implements that DR too.

Changes from the previous patch are:
* comp_array_types uses similar_type_p when needed, not same_type_ignoring_...;
* comp_ptr_ttypes_const and comp_ptr_ttypes_real will now look through
  arrays.  Fixed a bug whereby we'd accepted a conversion even if it involed
  converting arrays of different bounds;
* a bunch of new tests (qual1.C, qual2.C, qual3.C, ref2.C, ref3.C) to cover
  CWG 330;
* more tests to cover CWG 330 and P0388R4: array-conv16.C, array-conv17.C
* 23_containers/span/lwg3255.cc specifically mentions P0388R4 in a FIXME, so
  trivially adjusted.

> > @@ -10043,8 +10064,12 @@ comp_ptr_ttypes_const (tree to, tree from)
> > if (VECTOR_TYPE_P (to))
> > is_opaque_pointer = vector_targets_convertible_p (to, from);
> > +  if (TREE_CODE (to) == ARRAY_TYPE)
> > +   is_comp_array = comp_array_types (to, from, cb, /*tlq_match=*/false);
> > +
> > if (!TYPE_PTR_P (to))
> > return (is_opaque_pointer
> > +   || is_comp_array
> > || same_type_ignoring_top_level_qualifiers_p (to, from));
> 
> Likewise.

Fixed too.

Bootstrapped/regtested on x86_64-linux, built Boost and cmcstl2.

Ok for trunk?

2019-10-09  Marek Polacek  

PR c++/91364 - P0388R4: Permit conversions to arrays of unknown bound.
PR c++/69531 - DR 1307: Differently bounded array parameters.
PR c++/88128 - DR 330: Qual convs and pointers to arrays of pointers.
* call.c (build_array_conv): Build ck_identity at the beginning
of the conversion.
(standard_conversion): Pass bounds_none to comp_ptr_ttypes_const.
(maybe_warn_array_conv): New.
(convert_like_real): Call it.  Add an error message about converting
from arrays of unknown bounds.
(conv_get_original_expr): New.
(nelts_initialized_by_list_init): New.
(conv_binds_to_array_of_unknown_bound): New.
(compare_ics): Implement list-initialization ranking based on
array sizes, as specified in DR 1307 and P0388R.
* cp-tree.h (comp_ptr_ttypes_const): Adjust declaration.
(compare_bounds_t): New enum.
* typeck.c (comp_array_types): New bool and compare_bounds_t
parameters.  Use them.
(structural_comptypes): Adjust the call to comp_array_types.
(similar_type_p): Handle ARRAY_TYPE.
(build_const_cast_1): Pass bounds_none to comp_ptr_ttypes_const.
(comp_ptr_ttypes_real): Don't check cv-quals of ARRAY_TYPEs.  Use
comp_array_types to compare array types.  Look through arrays as per
DR 330.
(comp_ptr_ttypes_const): Use comp_array_types to compare array types.
Look through arrays as per DR 330.

* g++.dg/conversion/qual1.C: New test.
* g++.dg/conversion/qual2.C: New test.
* g++.dg/conversion/qual3.C: New test.
* g++.dg/conversion/ref2.C: New test.
* g++.dg/conversion/ref3.C: New test.
* g++.dg/cpp0x/initlist-array3.C: Remove dg-error.
* g++.dg/cpp0x/initlist-array7.C: New test.
* g++.dg/cpp0x/initlist-array8.C: New test.
* g++.dg/cpp2a/array-conv1.C: New test.
* g++.dg/cpp2a/array-conv10.C: New test.
* g++.dg/cpp2a/array-conv11.C: New test.
* g++.dg/cpp2a/array-conv12.C: New test.
* g++.dg/cpp2a/array-conv13.C: New test.
* g++.dg

[OG9][committed] Fix OpenMP's use_device_ptr with Fortran array descriptors

[Tobias Burnus]

The committed/attached patch fixes OpenMP 4.5's use_device_ptr(var) for 
variables with array descriptor.


This is the OG9 version of the GCC-10 trunk patch:
[1] https://gcc.gnu.org/ml/fortran/2019-09/msg00088.html [still awaiting 
review]
[On trunk, it makes sense to have first: [2] 
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00503.html ]


Differences:
* OG9 lacks some trunk features, hence omp-low.c differs; e.g. trunk 
supports use_device_addr – or sorting "map" before "use_device_ptr"


* OG9 supports nonpresent optional arguments (to some extend). This 
failed with my patch; while I don't understand why it doesn't fail w/o 
my patch, that's now fixed (search for "present_map" in the code).*


* OG9 has a different implementation of omp_is_optional_argument, hence, 
I fix I applied in [2] for optional+value looks different.


Note that also the optional part is scheduled for the trunk as well, cf. 
[3] https://gcc.gnu.org/ml/fortran/2019-07/msg00082.html


Tobias

[* Inside the target-data block, "if (dummy == NULL)" was used; I think 
it got replaced by DECL_VALUE_EXPR - at least it got later replaced by 
something like "if (.mem-ref = 0)"  (i.e. a mem-ref with variable), 
which the gimplifier did not like. The solution is to use a different(ly 
named) temporary Boolean variable to store the status – and use this one 
in the target-data block. – The actual failing test case was for 
OpenACC, but the result is the same for OpenMP.]


Fix OpenMP's use_device_ptr with Fortran array descriptors

	gcc/fortran
	* f95-lang.c (LANG_HOOKS_OMP_ARRAY_DATA): Set to gfc_omp_array_data.
	* trans-array.c (gfc_conv_descriptor_data_get): Handle ref types.
	* trans-openmp.c (gfc_omp_array_data): New.
	* trans.h (gfc_omp_array_data): Declare.

	gcc/
	* hooks.c (hook_tree_tree_null): New.
	* hooks.h (hook_tree_tree_null): Declare.
	* langhooks-def.h (LANG_HOOKS_OMP_ARRAY_DATA): Define.
	(LANG_HOOKS_FOR_TYPES_INITIALIZER): Use it.
	* langhooks.h (lang_hooks_for_types): Add omp_array_data.
	* omp-general.c (omp_is_optional_argument): Handle value+optional.
	* omp-low.c (omp_context): Add array_data_map + present_map.
	(install_var_field): Handle array descriptors.
	(delete_omp_context): Free new maps.
	(scan_sharing_clauses): Handle array descriptors.
	(lower_omp_target): Ditto. Fix optional-arg present check.

	gcc/testsuite/
	* gfortran.dg/gomp/use_device_ptr1.f90: New.
	* gfortran.dg/gomp/use_device_ptr2.f90: New.
	* gfortran.dg/gomp/use_device_ptr3.f90: New.

	libgomp/
	* testsuite/libgomp.fortran/use_device_ptr1.f90: New.

diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c
index 3e3d3046bdb..a1cbd1b449b 100644
--- a/gcc/fortran/f95-lang.c
+++ b/gcc/fortran/f95-lang.c
@@ -112,6 +112,7 @@ static const struct attribute_spec gfc_attribute_table[] =
 #undef LANG_HOOKS_MARK_ADDRESSABLE
 #undef LANG_HOOKS_TYPE_FOR_MODE
 #undef LANG_HOOKS_TYPE_FOR_SIZE
+#undef LANG_HOOKS_OMP_ARRAY_DATA
 #undef LANG_HOOKS_INIT_TS
 #undef LANG_HOOKS_OMP_PRIVATIZE_BY_REFERENCE
 #undef LANG_HOOKS_OMP_PREDETERMINED_SHARING
@@ -145,6 +146,7 @@ static const struct attribute_spec gfc_attribute_table[] =
 #define LANG_HOOKS_TYPE_FOR_MODE	gfc_type_for_mode
 #define LANG_HOOKS_TYPE_FOR_SIZE	gfc_type_for_size
 #define LANG_HOOKS_INIT_TS		gfc_init_ts
+#define LANG_HOOKS_OMP_ARRAY_DATA		gfc_omp_array_data
 #define LANG_HOOKS_OMP_PRIVATIZE_BY_REFERENCE	gfc_omp_privatize_by_reference
 #define LANG_HOOKS_OMP_PREDETERMINED_SHARING	gfc_omp_predetermined_sharing
 #define LANG_HOOKS_OMP_REPORT_DECL		gfc_omp_report_decl
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 7fb033c1721..02b8a85f94b 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -142,6 +142,9 @@ gfc_conv_descriptor_data_get (tree desc)
   tree field, type, t;
 
   type = TREE_TYPE (desc);
+  if (TREE_CODE (type) == REFERENCE_TYPE)
+type = TREE_TYPE (type);
+
   gcc_assert (GFC_DESCRIPTOR_TYPE_P (type));
 
   field = TYPE_FIELDS (type);
diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
index 5d0d6d2c011..5138a2530a6 100644
--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -47,6 +47,25 @@ along with GCC; see the file COPYING3.  If not see
 
 int ompws_flags;
 
+tree
+gfc_omp_array_data (tree decl)
+{
+  tree type = TREE_TYPE (decl);
+
+  if (TREE_CODE (type) == REFERENCE_TYPE || POINTER_TYPE_P (type))
+type = TREE_TYPE (type);
+
+  if (!GFC_DESCRIPTOR_TYPE_P (type))
+return NULL_TREE;
+
+  if (POINTER_TYPE_P (TREE_TYPE (decl)))
+decl = build_fold_indirect_ref (decl);
+
+  decl = gfc_conv_descriptor_data_get (decl);
+  STRIP_NOPS (decl);
+  return decl;
+}
+
 /* True if OpenMP should privatize what this DECL points to rather
than the DECL itself.  */
 
diff --git a/gcc/fortran/trans.h b/gcc/fortran/trans.h
index 794600a1e61..7659476db10 100644
--- a/gcc/fortran/trans.h
+++ b/gcc/fortran/trans.h
@@ -776,6 +776,7 @@ struct array_descr_info;
 bool gfc_get_array_descr_info (const_tree, str

{PATCH v3, rs6000] Replace X-form addressing with D-form addressing in new pass for Power9

[Kelvin Nilsen]

This patch is a refinement of a patch first submitted to this list on Nov. 10, 
2018, with revisions submitted this list on Dec. 13, 2018 and Sep. 3, 2019.

This new pass scans existing rtl expressions and replaces them with rtl 
expressions that favor selection of the D-form instructions in contexts for 
which the D-form instructions are preferred.  The new pass runs after the RTL 
loop optimizations since loop unrolling often introduces opportunities for 
beneficial replacements of X-form addressing instructions.

For each of the new tests, multiple X-form instructions are replaced with 
D-form instructions, some addi instructions are replaced with add instructions, 
and some addi instructions are eliminated.  The typical improvement for the 
included tests is a decrease of 4.28% to 12.12% in the number of instructions 
executed on each iteration of the loop.  The optimization has not shown 
measurable improvement on specmark tests, presumably because the typical loops 
that are benefited by this optimization are memory bounded and this 
optimization does not eliminate memory loads or stores.  However, it is 
anticipated that multi-threaded workloads and measurements of total power and 
cooling costs for heavy server workloads would benefit.

This version 3 patch responds to feedback and numerous suggestions by Segher:

1. Fixed multiple typos.

2. Improved comments and added discussion of computational complexity.

3. Added a field to the indexing_web_entry class, allowing constant-time test 
for dominance of instructions within a common basic block.

4. Improved implementation of the equivalence hash function.

5. Refactored the code to divide into smaller functions and provide more 
descriptive commentary.

6. Improved indentation.

7. Corrected definition of max_16bit_signed value.

8. Added To-do comment in rs6000_target_supports_dform_offset_p, to alert 
maintainers that adding support for future hardware architectures will require 
code to be added to this function.

9. Simplified the dg directives in the new test cases. 

I have built and regression tested this patch on powerpc64le-unknown-linux 
target with no regressions.

Is this ok for trunk?

gcc/ChangeLog:

2019-10-09  Kelvin Nilsen  

* config/rs6000/rs6000-p9dform.c: New file.
* config/rs6000/rs6000-passes.def: Add pass_insert_dform.
* config/rs6000/rs6000-protos.h
(rs6000_target_supports_dform_offset_p): New function prototype.
(make_pass_insert_dform): Likewise.
* config/rs6000/rs6000.c (rs6000_target_supports_dform_offset_p):
New function.
* config/rs6000/t-rs6000 (rs6000-p9dform.o): New build target.
* config.gcc: Add rs6000-p9dform.o object file.

gcc/testsuite/ChangeLog:

2019-10-09  Kelvin Nilsen  

* gcc.target/powerpc/p9-dform-0.c: New test.
* gcc.target/powerpc/p9-dform-1.c: New test.
* gcc.target/powerpc/p9-dform-10.c: New test.
* gcc.target/powerpc/p9-dform-11.c: New test.
* gcc.target/powerpc/p9-dform-12.c: New test.
* gcc.target/powerpc/p9-dform-13.c: New test.
* gcc.target/powerpc/p9-dform-14.c: New test.
* gcc.target/powerpc/p9-dform-15.c: New test.
* gcc.target/powerpc/p9-dform-2.c: New test.
* gcc.target/powerpc/p9-dform-3.c: New test.
* gcc.target/powerpc/p9-dform-4.c: New test.
* gcc.target/powerpc/p9-dform-5.c: New test.
* gcc.target/powerpc/p9-dform-6.c: New test.
* gcc.target/powerpc/p9-dform-7.c: New test.
* gcc.target/powerpc/p9-dform-8.c: New test.
* gcc.target/powerpc/p9-dform-9.c: New test.
* gcc.target/powerpc/p9-dform-generic.h: New test.

Index: gcc/config/rs6000/rs6000-p9dform.c
===
--- gcc/config/rs6000/rs6000-p9dform.c  (nonexistent)
+++ gcc/config/rs6000/rs6000-p9dform.c  (working copy)
@@ -0,0 +1,1623 @@
+/* Subroutines used to transform array subscripting expressions into
+   forms that are more amenable to d-form instruction selection for p9
+   little-endian VSX code.
+   Copyright (C) 1991-2019 Free Software Foundation, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "backend.h"
+#include "rtl.h"
+#include "tree.h"
+#include "memmodel.

Re: Add std::copy_n overload for istreambuf_iterator

[François Dumont]

On 10/9/19 10:18 PM, Christophe Lyon wrote:



On Fri, 4 Oct 2019 at 07:01, François Dumont > wrote:


On 9/27/19 1:00 PM, Jonathan Wakely wrote:
> On 19/07/19 23:37 +0200, François Dumont wrote:
>> It sounds reasonable to overload std::copy_n for
istreambuf_iterator.
> I wonder whether it's worth doing:
>
> #if __cplusplus >= 201703L
>    if constexpr (is_same_v<_OutputIterator, _CharT*>)
>  return __result + __it._M_sbuf->sgetn(__result, __n);
>    else
>  {
> #endif
>  ...
> #if __cplusplus >= 201703L
>  }
> #endif
>
> We could extend that to also work for basic_string<_CharT>::iterator
> and vector<_CharT>::iterator too if we wanted.
>
> I'm not sure if it will perform any better than the code below (it's
> approximately equivalent) but it should result in smaller
binaries, as we
> wouldn't be instantiating the code below when outputting to a
pointer
> or contiguous iterator.
>
> We don't need to do that now, it can be a separate patch later
(if we
> do it at all).

Very good remark, I hadn't check streambuf to find out if there were
better to do. For me it is the streambuf method to target for an
std::copy_n overload.

So here is a new proposal much simpler. I see no reason to enable it
only for char types, is there ?

Once the other patch on copy/copy_backward... algos is in I'll
provide
what necessary to benefit from the same optimization for std::deque
iterators and in Debug mode.

>
>> +#endif
>
> Because the matching #if is more than 40 lines away, please add a
> comment noting the condition that this corresponds to, i.e.
>
> #endif // C++11
Ok, done even if there is no 40 lines anymore. And also added it in
stl_algo.h.
>
>> +
>>   template
>>     typename __gnu_cxx::__enable_if<__is_char<_CharT>::__value,
>> istreambuf_iterator<_CharT> >::__type
>> diff --git a/libstdc++-v3/include/std/streambuf
>> b/libstdc++-v3/include/std/streambuf
>> index d9ca981d704..4f62ebf4d95 100644
>> --- a/libstdc++-v3/include/std/streambuf
>> +++ b/libstdc++-v3/include/std/streambuf
>> @@ -155,6 +155,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> __copy_move_a2(istreambuf_iterator<_CharT2>,
>>    istreambuf_iterator<_CharT2>, _CharT2*);
>>
>> +#if __cplusplus >= 201103L
>> +  template> _OutputIterator>
>> +    friend typename enable_if<__is_char<_CharT2>::__value,
>> +  _OutputIterator>::type
>> +    copy_n(istreambuf_iterator<_CharT2>, _Size, _OutputIterator);
>> +#endif
>> +
>>   template
>>     friend typename
>> __gnu_cxx::__enable_if<__is_char<_CharT2>::__value,
>> istreambuf_iterator<_CharT2> >::__type
>> diff --git
>>
a/libstdc++-v3/testsuite/25_algorithms/copy_n/istreambuf_iterator.cc
>>
b/libstdc++-v3/testsuite/25_algorithms/copy_n/istreambuf_iterator.cc
>> new file mode 100644
>> index 000..ebd769cf7c0
>> --- /dev/null
>> +++
b/libstdc++-v3/testsuite/25_algorithms/copy_n/istreambuf_iterator.cc
>> @@ -0,0 +1,59 @@
>> +// Copyright (C) 2019 Free Software Foundation, Inc.
>> +//
>> +// This file is part of the GNU ISO C++ Library. This library
is free
>> +// software; you can redistribute it and/or modify it under the
>> +// terms of the GNU General Public License as published by the
>> +// Free Software Foundation; either version 3, or (at your option)
>> +// any later version.
>> +
>> +// This library is distributed in the hope that it will be useful,
>> +// but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> +// GNU General Public License for more details.
>> +
>> +// You should have received a copy of the GNU General Public
License
>> along
>> +// with this library; see the file COPYING3.  If not see
>> +// .
>> +
>> +// { dg-do run { target c++11 } }
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +void test01()
>> +{
>> +  std::stringstream ss("12345");
>> +
>> +  std::string ostr(5, '0');
>> +  typedef std::istreambuf_iterator istrb_ite;
>> +  std::copy_n(istrb_ite(ss), 0, ostr.begin());
>> +  VERIFY( ostr.front() == '0' );
>
> I'd like to see a check here that the value returned from copy_n is
> equal to ostr.begin().
>
>> +
>> +  std::copy_n(istrb_ite(ss), 2, ostr.begin());
>> +  VERIFY( ostr == "12000" );
>
> And equal to ostr.begin() + 2.
>
>> +
>> +  std::copy_n(istrb_ite(ss), 3, ostr.begin() + 2);
>> +  VERIFY( ostr == "12345" );
>
> And equal 

Re: C++ PATCH for C++20 P0388R4 (conversions to arrays of unknown bounds) and CWG 1307 (c++/91364, c++/69531)

[Marek Polacek]

On Wed, Oct 09, 2019 at 11:01:39AM +0100, Jonathan Wakely wrote:
> On 07/10/19 14:56 -0400, Jason Merrill wrote:
> > On 10/7/19 1:42 PM, Marek Polacek wrote:
> > > @@ -7401,8 +7432,20 @@ convert_like_real (conversion *convs, tree expr, 
> > > tree fn, int argnum,
> > > error_at (loc, "cannot bind non-const lvalue reference of "
> > >   "type %qH to an rvalue of type %qI", totype, extype);
> > >   else if (!reference_compatible_p (TREE_TYPE (totype), extype))
> > > -   error_at (loc, "binding reference of type %qH to %qI "
> > > - "discards qualifiers", totype, extype);
> > > +   {
> > > + /* If we're converting from T[] to T[N], don't talk
> > > +about discarding qualifiers.  (Converting from T[N] to
> > > +T[] is allowed by P0388R4.)  */
> > > + if (TREE_CODE (extype) == ARRAY_TYPE
> > > + && TYPE_DOMAIN (extype) == NULL_TREE
> > > + && TREE_CODE (TREE_TYPE (totype)) == ARRAY_TYPE
> > > + && TYPE_DOMAIN (TREE_TYPE (totype)) != NULL_TREE)
> > > +   error_at (loc, "binding reference of type %qH to %qI "
> > > + "discards array bounds", totype, extype);
> > 
> > If we're converting to T[N], that would be adding, not discarding, array
> > bounds?
> 
> I don't think the diagnostic would be very good if we say "adds array
> bounds" though. How about being consistent with the existing error for
> similar cases?
> 
> a.cc:4:17: error: invalid initialization of reference of type ‘int (&)[3]’ 
> from expression of type ‘int []’
>   int (&b)[3] = a;
> ^

In my latest patch the error message reads "cannot bind reference of type T to 
U due to different array bounds".
It'd be trivial to adjust it if anyone hates that.

Marek

[PATCH] V5, #7 of 15: Restrict vector extract to not use prefixed memory

[Michael Meissner]

This patch fixes an issue Aaron Sawdey with vector extracts.  The vector
address adjust functions have a single base register temporary.  However for
PC-relative addresses where the vector element is not constant, it logically
will need two temporary registers, one to load up the PC-relative address, and
the other to hold the offset of the vector element being extracted.

If a vector has a prefixed address and the vector element being extracted is
not constant, this code will load the vector into a register, and then do the
variable extract from that register, insted of just loading the scalar value
up.

Along with the other patches, I have done bootstraps on a little endian power8
system, and there were no regressions in the test suite.  Can I check this into
the trunk?

2019-10-08  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_adjust_vec_address): Add support
for optimizing PC-relative addresses with a constant element
number.  Assert that PC-relative vectors do not have variable
element numbers.  Add support for prefixed addresses with 34-bit
offsets.
* config/rs6000/vsx.md (vsx_extract__var, VSX_D iterator):
Do not allow combining prefixed memory with a variable vector
extract.
(vsx_extract_v4sf_var): Do not allow combining prefixed memory
with a variable vector extract.
(vsx_extract__var, VSX_EXTRACT_I iterator): Do not allow
combining prefixed memory with a variable vector extract.
(vsx_extract__mode_var): Do not allow combining
prefixed memory with a variable vector extract.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 276719)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -6701,6 +6701,7 @@ rs6000_adjust_vec_address (rtx scalar_re
   rtx element_offset;
   rtx new_addr;
   bool valid_addr_p;
+  bool pcrel_p = pcrel_local_address (addr, Pmode);
 
   /* Vector addresses should not have PRE_INC, PRE_DEC, or PRE_MODIFY.  */
   gcc_assert (GET_RTX_CLASS (GET_CODE (addr)) != RTX_AUTOINC);
@@ -6738,6 +6739,38 @@ rs6000_adjust_vec_address (rtx scalar_re
   else if (REG_P (addr) || SUBREG_P (addr))
 new_addr = gen_rtx_PLUS (Pmode, addr, element_offset);
 
+  /* Optimize PC-relative addresses with a constant offset.  */
+  else if (pcrel_p && CONST_INT_P (element_offset))
+{
+  rtx addr2 = addr;
+  HOST_WIDE_INT offset = INTVAL (element_offset);
+
+  if (GET_CODE (addr2) == CONST)
+   addr2 = XEXP (addr2, 0);
+
+  if (GET_CODE (addr2) == PLUS)
+   {
+ offset += INTVAL (XEXP (addr2, 1));
+ addr2 = XEXP (addr2, 0);
+   }
+
+  gcc_assert (SIGNED_34BIT_OFFSET_P (offset));
+  if (offset)
+   {
+ addr2 = gen_rtx_PLUS (Pmode, addr2, GEN_INT (offset));
+ new_addr = gen_rtx_CONST (Pmode, addr2);
+   }
+  else
+   new_addr = addr2;
+}
+
+  /* With only one temporary base register, we can't support a PC-relative
+ address added to a variable offset.  This is because the PADDI instruction
+ requires RA to be 0 when doing a PC-relative add (i.e. no register to add
+ to).  */
+  else if (pcrel_p)
+gcc_unreachable ();
+
   /* Optimize D-FORM addresses with constant offset with a constant element, to
  include the element offset in the address directly.  */
   else if (GET_CODE (addr) == PLUS)
@@ -6752,8 +6785,11 @@ rs6000_adjust_vec_address (rtx scalar_re
  HOST_WIDE_INT offset = INTVAL (op1) + INTVAL (element_offset);
  rtx offset_rtx = GEN_INT (offset);
 
- if (IN_RANGE (offset, -32768, 32767)
- && (scalar_size < 8 || (offset & 0x3) == 0))
+ if (TARGET_PREFIXED_ADDR && SIGNED_34BIT_OFFSET_P (offset))
+   new_addr = gen_rtx_PLUS (Pmode, op0, offset_rtx);
+
+ else if (SIGNED_16BIT_OFFSET_P (offset)
+  && (scalar_size < 8 || (offset & 0x3) == 0))
new_addr = gen_rtx_PLUS (Pmode, op0, offset_rtx);
  else
{
@@ -6801,11 +6837,11 @@ rs6000_adjust_vec_address (rtx scalar_re
   new_addr = gen_rtx_PLUS (Pmode, base_tmp, element_offset);
 }
 
-  /* If we have a PLUS, we need to see whether the particular register class
- allows for D-FORM or X-FORM addressing.  */
-  if (GET_CODE (new_addr) == PLUS)
+  /* If we have a PLUS or a PC-relative address without the PLUS, we need to
+ see whether the particular register class allows for D-FORM or X-FORM
+ addressing.  */
+  if (GET_CODE (new_addr) == PLUS || pcrel_p)
 {
-  rtx op1 = XEXP (new_addr, 1);
   addr_mask_type addr_mask;
   unsigned int scalar_regno = reg_or_subregno (scalar_reg);
 
@@ -6822,10 +6858,16 @@ rs6000_adjust_vec_address (rtx scalar_re
   else
gcc_unreachable ();
 
-  if (REG_P (op1) || SUBREG_P (op1))
-   valid_addr_p = (addr_mask & RELOAD_REG_INDEXED) != 0;
-  else
+

[PATCH] V5, #8 of 15: Use PADDI/PLI to load up 34-bit DImode constants

[Michael Meissner]

This patch uses PADDI (PLI) to load up 34-bit DImode constants.  In the V3 time
frame, it was part of a larger patch, but you asked that this be a separate
patch.

Along with the other patches, I have done bootstraps on a little endian power8
system, and there were no regressions in the test suite.  Can I check this into
the trunk?

2019-10-08  Michael Meissner  

* config/rs6000/rs6000.c (num_insns_constant_gpr): Add support for
PADDI to load up and/or add 34-bit integer constants.
(rs6000_rtx_costs): Treat constants loaded up with PADDI with the
same cost as normal 16-bit constants.
* config/rs6000/rs6000.md (movdi_internal64): Add support to load
up 34-bit integer constants with PADDI.
(movdi integer constant splitter): Add comment about PADDI.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 276723)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -5523,7 +5523,7 @@ static int
 num_insns_constant_gpr (HOST_WIDE_INT value)
 {
   /* signed constant loadable with addi */
-  if (((unsigned HOST_WIDE_INT) value + 0x8000) < 0x1)
+  if (SIGNED_16BIT_OFFSET_P (value))
 return 1;
 
   /* constant loadable with addis */
@@ -5531,6 +5531,10 @@ num_insns_constant_gpr (HOST_WIDE_INT va
   && (value >> 31 == -1 || value >> 31 == 0))
 return 1;
 
+  /* PADDI can support up to 34 bit signed integers.  */
+  else if (TARGET_PREFIXED_ADDR && SIGNED_34BIT_OFFSET_P (value))
+return 1;
+
   else if (TARGET_POWERPC64)
 {
   HOST_WIDE_INT low  = ((value & 0x) ^ 0x8000) - 0x8000;
@@ -20640,7 +20644,8 @@ rs6000_rtx_costs (rtx x, machine_mode mo
|| outer_code == PLUS
|| outer_code == MINUS)
   && (satisfies_constraint_I (x)
-  || satisfies_constraint_L (x)))
+  || satisfies_constraint_L (x)
+  || satisfies_constraint_eI (x)))
  || (outer_code == AND
  && (satisfies_constraint_K (x)
  || (mode == SImode
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 276719)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -8805,24 +8805,24 @@ (define_split
   [(pc)]
 { rs6000_split_multireg_move (operands[0], operands[1]); DONE; })
 
-;;  GPR store  GPR load   GPR move   GPR li GPR lis GPR #
-;;  FPR store  FPR load   FPR move   AVX store  AVX store   AVX 
load
-;;  AVX load   VSX move   P9 0   P9 -1  AVX 0/-1VSX 0
-;;  VSX -1 P9 const   AVX const  From SPR   To SPR  
SPR<->SPR
-;;  VSX->GPR   GPR->VSX
+;;  GPR store  GPR load   GPR move   GPR li GPR lis GPR pli
+;;  GPR #  FPR store  FPR load   FPR move   AVX store   AVX 
store
+;;  AVX load   AVX load   VSX move   P9 0   P9 -1   AVX 
0/-1
+;;  VSX 0  VSX -1 P9 const   AVX const  From SPRTo SPR
+;;  SPR<->SPR  VSX->GPR   GPR->VSX
 (define_insn "*movdi_internal64"
   [(set (match_operand:DI 0 "nonimmediate_operand"
"=YZ,   r, r, r, r,  r,
-m, ^d,^d,wY,Z,  $v,
-$v,^wa,   wa,wa,v,  wa,
-wa,v, v, r, *h, *h,
-?r,?wa")
+r, m, ^d,^d,wY, Z,
+$v,$v,^wa,   wa,wa, v,
+wa,wa,v, v, r,  *h,
+*h,?r,?wa")
(match_operand:DI 1 "input_operand"
-   "r, YZ,r, I, L,  nF,
-^d,m, ^d,^v,$v, wY,
-Z, ^wa,   Oj,wM,OjwM,   Oj,
-wM,wS,wB,*h,r,  0,
-wa,r"))]
+   "r, YZ,r, I, L,  eI,
+nF,^d,m, ^d,^v, $v,
+wY,Z, ^wa,   Oj,wM, OjwM,
+Oj,wM,wS,wB,*h, r,
+0, wa,r"))]
   "TARGET_POWERPC64
&& (gpc_reg_operand (operands[0], DImode)
|| gpc_reg_operand (operands[1], DImode))"
@@ -8832,6 +8832,7 @@ (define_insn "*movdi_internal64"
mr %0,%1
li %0,%1
lis %0,%v1
+   li %0,%1
#
stfd%U0%X0 %1,%0
lfd%U1%X1 %0,%1
@@ -8855,26 +8856,28 @@ (define_insn "*movdi_internal64"
mtvsrd %x0,%1"
   [(set_attr "type"

[PATCH] V5, #9 of 15: Add PADDI (PLI) support to load up 32-bit SImode constants

[Michael Meissner]

This patch is a companion patch to patch #8, and it allows using the PADDI
(PLI) instruction to load up 32-bit SImode constants rather than generating
separate ADDI + ADDIS instructions.

Along with the other patches, I have done bootstraps on a little endian power8
system, and there were no regressions in the test suite.  Can I check this into
the trunk?

2019-10-08  Michael Meissner  

* config/rs6000/rs6000.md (movsi_internal1): Add support to load
up 32-bit SImode integer constants with PADDI.
(movsi integer constant splitter): Do not split constant if PADDI
can load it up directly.

Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 276724)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -6904,22 +6904,22 @@ (define_insn "movsi_low"
 
 ;; MR   LA   LWZ  LFIWZX   LXSIWZX
 ;; STW  STFIWX   STXSIWX  LI   LIS
-;; #XXLORXXSPLTIB 0   XXSPLTIB -1  VSPLTISW
-;; XXLXOR 0 XXLORC -1P9 const MTVSRWZ  MFVSRWZ
-;; MF%1 MT%0 NOP
+;; PLI  #XXLORXXSPLTIB 0   XXSPLTIB -1
+;; VSPLTISW XXLXOR 0 XXLORC -1P9 const MTVSRWZ
+;; MFVSRWZ  MF%1 MT%0 NOP
 (define_insn "*movsi_internal1"
   [(set (match_operand:SI 0 "nonimmediate_operand"
"=r, r,   r,   d,   v,
 m,  Z,   Z,   r,   r,
-r,  wa,  wa,  wa,  v,
-wa, v,   v,   wa,  r,
-r,  *h,  *h")
+r,  r,   wa,  wa,  wa,
+v,  wa,  v,   v,   wa,
+r,  r,   *h,  *h")
(match_operand:SI 1 "input_operand"
"r,  U,   m,   Z,   Z,
 r,  d,   v,   I,   L,
-n,  wa,  O,   wM,  wB,
-O,  wM,  wS,  r,   wa,
-*h, r,   0"))]
+eI, n,   wa,  O,   wM,
+wB, O,   wM,  wS,  r,
+wa, *h,  r,   0"))]
   "gpc_reg_operand (operands[0], SImode)
|| gpc_reg_operand (operands[1], SImode)"
   "@
@@ -6933,6 +6933,7 @@ (define_insn "*movsi_internal1"
stxsiwx %x1,%y0
li %0,%1
lis %0,%v1
+   li %0,%1
#
xxlor %x0,%x1,%x1
xxspltib %x0,0
@@ -6949,21 +6950,21 @@ (define_insn "*movsi_internal1"
   [(set_attr "type"
"*,  *,   load,fpload,  fpload,
 store,  fpstore, fpstore, *,   *,
-*,  veclogical,  vecsimple,   vecsimple,   vecsimple,
-veclogical, veclogical,  vecsimple,   mffgpr,  mftgpr,
-*,  *,   *")
+*,  *,   veclogical,  vecsimple,   vecsimple,
+vecsimple,  veclogical,  veclogical,  vecsimple,   mffgpr,
+mftgpr, *,   *,   *")
(set_attr "length"
"*,  *,   *,   *,   *,
 *,  *,   *,   *,   *,
-8,  *,   *,   *,   *,
-*,  *,   8,   *,   *,
-*,  *,   *")
+*,  8,   *,   *,   *,
+*,  *,   *,   8,   *,
+*,  *,   *,   *")
(set_attr "isa"
"*,  *,   *,   p8v, p8v,
 *,  p8v, p8v, *,   *,
-*,  p8v, p9v, p9v, p8v,
-p9v,p8v, p9v, p8v, p8v,
-*,  *,   *")])
+fut,*,   p8v, p9v, p9v,
+p8v,p9v, p8v, p9v, p8v,
+p8v,*,   *,   *")])
 
 ;; Like movsi, but adjust a SF value to be used in a SI context, i.e.
 ;; (set (reg:SI ...) (subreg:SI (reg:SF ...) 0))
@@ -7108,14 +7109,15 @@ (define_insn "*movsi_from_df"
   "xscvdpsp %x0,%x1"
   [(set_attr "type" "fp")])
 
-;; Split a load of a large constant into the appropriate two-insn
-;; sequence.
+;; Split a load of a large cons

C++ PATCH to fix typo in test name

[Marek Polacek]

Applying as obvious:

A  +initlist-array1.C
> moved from initlist-arrray1.C
D   initlist-arrray1.C
> moved to initlist-array1.C

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

[PATCH] V5, #10 of 15: Use PADDI to add large 34-bit constants

[Michael Meissner]

This patch enables generating PADDI to add 34-bit constants.

This is the last of the patches in V5 to add the necessary support for the
'future' machine.

Along with the other patches, I have done bootstraps on a little endian power8
system, and there were no regressions in the test suite.  Can I check this into
the trunk?

2019-10-08  Michael Meissner  

* config/rs6000/predicates.md (add_operand): Add support for
PADDI.
* config/rs6000/rs6000.md (add3): Add support for PADDI.

Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 276718)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -839,7 +839,8 @@ (define_special_predicate "indexed_addre
 (define_predicate "add_operand"
   (if_then_else (match_code "const_int")
 (match_test "satisfies_constraint_I (op)
-|| satisfies_constraint_L (op)")
+|| satisfies_constraint_L (op)
+|| satisfies_constraint_eI (op)")
 (match_operand 0 "gpc_reg_operand")))
 
 ;; Return 1 if the operand is either a non-special register, or 0, or -1.
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 276726)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -1756,15 +1756,17 @@ (define_expand "add3"
 })
 
 (define_insn "*add3"
-  [(set (match_operand:GPR 0 "gpc_reg_operand" "=r,r,r")
-   (plus:GPR (match_operand:GPR 1 "gpc_reg_operand" "%r,b,b")
- (match_operand:GPR 2 "add_operand" "r,I,L")))]
+  [(set (match_operand:GPR 0 "gpc_reg_operand" "=r,r,r,r")
+   (plus:GPR (match_operand:GPR 1 "gpc_reg_operand" "%r,b,b,b")
+ (match_operand:GPR 2 "add_operand" "r,I,L,eI")))]
   ""
   "@
add %0,%1,%2
addi %0,%1,%2
-   addis %0,%1,%v2"
-  [(set_attr "type" "add")])
+   addis %0,%1,%v2
+   addi %0,%1,%2"
+  [(set_attr "type" "add")
+   (set_attr "isa" "*,*,*,fut")])
 
 (define_insn "*addsi3_high"
   [(set (match_operand:SI 0 "gpc_reg_operand" "=b")

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: C++ PATCH for C++20 P0388R4 (conversions to arrays of unknown bounds) and CWG 1307 (c++/91364, c++/69531)

[Jason Merrill]

On 10/9/19 4:26 PM, Marek Polacek wrote:

On Tue, Oct 08, 2019 at 01:50:17PM -0400, Jason Merrill wrote:

That sounds like a bug in grok_reference_init; it isn't properly
implementing

"Otherwise, if the initializer list has a single element of type E and
either T is not a reference type or its
referenced type is reference-related to E, the object or reference is
initialized from that element"


Can that be fixed in a follow up?


Sure.


I'll open a PR.


@@ -9888,6 +9900,7 @@ comp_ptr_ttypes_real (tree to, tree from, int constp)
   {
 bool to_more_cv_qualified = false;
 bool is_opaque_pointer = false;
+  bool is_comp_array = false;
 for (; ; to = TREE_TYPE (to), from = TREE_TYPE (from))
   {
@@ -9920,9 +9933,16 @@ comp_ptr_ttypes_real (tree to, tree from, int constp)
 if (VECTOR_TYPE_P (to))
is_opaque_pointer = vector_targets_convertible_p (to, from);
+  if (TREE_CODE (to) == ARRAY_TYPE)
+   /* P0388R4 allows a conversion from int[N] to int[] but not the
+  other way round.  */
+   is_comp_array = comp_array_types (to, from, bounds_first,
+ /*tlq_match=*/false);


This seems to stop iterating when we first see an array, but 7.3.5
[conv.qual] seems to allow conversion to unknown bounds at multiple levels,
and even qualification conversion of an array of pointers, e.g.

int *ar[4];
const int *(&arp)[] = ar;


(Should be const int *const (&arp)[] = ar; I believe.)

Yup, this is us lacking DR 330 which I'd been meaning to fix separately, but the
following patch implements that DR too.

Changes from the previous patch are:
* comp_array_types uses similar_type_p when needed, not same_type_ignoring_...;
* comp_ptr_ttypes_const and comp_ptr_ttypes_real will now look through
   arrays.  Fixed a bug whereby we'd accepted a conversion even if it involed
   converting arrays of different bounds;
* a bunch of new tests (qual1.C, qual2.C, qual3.C, ref2.C, ref3.C) to cover
   CWG 330;
* more tests to cover CWG 330 and P0388R4: array-conv16.C, array-conv17.C
* 23_containers/span/lwg3255.cc specifically mentions P0388R4 in a FIXME, so
   trivially adjusted.


@@ -10043,8 +10064,12 @@ comp_ptr_ttypes_const (tree to, tree from)
 if (VECTOR_TYPE_P (to))
is_opaque_pointer = vector_targets_convertible_p (to, from);
+  if (TREE_CODE (to) == ARRAY_TYPE)
+   is_comp_array = comp_array_types (to, from, cb, /*tlq_match=*/false);
+
 if (!TYPE_PTR_P (to))
return (is_opaque_pointer
+   || is_comp_array
|| same_type_ignoring_top_level_qualifiers_p (to, from));


Likewise.


Fixed too.

Bootstrapped/regtested on x86_64-linux, built Boost and cmcstl2.

Ok for trunk?


OK, thanks.


2019-10-09  Marek Polacek  

PR c++/91364 - P0388R4: Permit conversions to arrays of unknown bound.
PR c++/69531 - DR 1307: Differently bounded array parameters.
PR c++/88128 - DR 330: Qual convs and pointers to arrays of pointers.
* call.c (build_array_conv): Build ck_identity at the beginning
of the conversion.
(standard_conversion): Pass bounds_none to comp_ptr_ttypes_const.
(maybe_warn_array_conv): New.
(convert_like_real): Call it.  Add an error message about converting
from arrays of unknown bounds.
(conv_get_original_expr): New.
(nelts_initialized_by_list_init): New.
(conv_binds_to_array_of_unknown_bound): New.
(compare_ics): Implement list-initialization ranking based on
array sizes, as specified in DR 1307 and P0388R.
* cp-tree.h (comp_ptr_ttypes_const): Adjust declaration.
(compare_bounds_t): New enum.
* typeck.c (comp_array_types): New bool and compare_bounds_t
parameters.  Use them.
(structural_comptypes): Adjust the call to comp_array_types.
(similar_type_p): Handle ARRAY_TYPE.
(build_const_cast_1): Pass bounds_none to comp_ptr_ttypes_const.
(comp_ptr_ttypes_real): Don't check cv-quals of ARRAY_TYPEs.  Use
comp_array_types to compare array types.  Look through arrays as per
DR 330.
(comp_ptr_ttypes_const): Use comp_array_types to compare array types.
Look through arrays as per DR 330.

* g++.dg/conversion/qual1.C: New test.
* g++.dg/conversion/qual2.C: New test.
* g++.dg/conversion/qual3.C: New test.
* g++.dg/conversion/ref2.C: New test.
* g++.dg/conversion/ref3.C: New test.
* g++.dg/cpp0x/initlist-array3.C: Remove dg-error.
* g++.dg/cpp0x/initlist-array7.C: New test.
* g++.dg/cpp0x/initlist-array8.C: New test.
* g++.dg/cpp2a/array-conv1.C: New test.
* g++.dg/cpp2a/array-conv10.C: New test.
* g++.dg/cpp2a/array-conv11.C: New test.
* g++.dg/cpp2a/array-conv12.C: New test.
* g++.dg/cpp2a/array-conv13.C: New test.
* g++.dg/cpp2a/array-conv14.C: New test.
* g++.dg/cp

[PATCH] V5, #11 of 15: Make -mpcrel default on Linux 64-bit

[Michael Meissner]

This patch assumes patches #1 through #10 have been applied.  Once all of those
patches have been applied, this patch will change the default for Linux 64-bit
systems to enable -mpcrel and -mprefixed-addr being default when -mcpu=future
is used.  The other OS/bit-size targets (currently) do not enable these
options.

Along with the other patches, I have done bootstraps on a little endian power8
system, and there were no regressions in the test suite.  Can I check this into
the trunk?

2019-10-08  Michael Meissner  

* config/rs6000/linux64.h (TARGET_PREFIXED_ADDR_DEFAULT): Enable
prefixed addressing by default.
(TARGET_PCREL_DEFAULT): Enable pc-relative addressing by default.
* config/rs6000/rs6000-cpus.def (ISA_FUTURE_MASKS_SERVER): Only
enable -mprefixed-addr and -mpcrel if the OS tm.h says to enable
it.
(ADDRESSING_FUTURE_MASKS): New mask macro.
(OTHER_FUTURE_MASKS): Use ADDRESSING_FUTURE_MASKS.
* config/rs6000/rs6000.c (TARGET_PREFIXED_ADDR_DEFAULT): Do not
enable -mprefixed-addr unless the OS tm.h says to.
(TARGET_PCREL_DEFAULT): Do not enable -mpcrel unless the OS tm.h
says to.
(rs6000_option_override_internal): Do not enable -mprefixed-addr
or -mpcrel unless the OS tm.h says to enable it.  Add more checks
for -mcpu=future.

Index: gcc/config/rs6000/linux64.h
===
--- gcc/config/rs6000/linux64.h (revision 276713)
+++ gcc/config/rs6000/linux64.h (working copy)
@@ -640,3 +640,11 @@ extern int dot_symbols;
enabling the __float128 keyword.  */
 #undef TARGET_FLOAT128_ENABLE_TYPE
 #define TARGET_FLOAT128_ENABLE_TYPE 1
+
+/* Enable support for pc-relative and numeric prefixed addressing on the
+   'future' system.  */
+#undef  TARGET_PREFIXED_ADDR_DEFAULT
+#define TARGET_PREFIXED_ADDR_DEFAULT   1
+
+#undef  TARGET_PCREL_DEFAULT
+#define TARGET_PCREL_DEFAULT   1
Index: gcc/config/rs6000/rs6000-cpus.def
===
--- gcc/config/rs6000/rs6000-cpus.def   (revision 276713)
+++ gcc/config/rs6000/rs6000-cpus.def   (working copy)
@@ -75,15 +75,21 @@
 | OPTION_MASK_P8_VECTOR\
 | OPTION_MASK_P9_VECTOR)
 
-/* Support for a future processor's features.  Do not enable -mpcrel until it
-   is fully functional.  */
+/* Support for a future processor's features.  The prefixed and pc-relative
+   addressing bits are not added here.  Instead, rs6000.c adds them if the OS
+   tm.h says that it supports the addressing modes.  */
 #define ISA_FUTURE_MASKS_SERVER(ISA_3_0_MASKS_SERVER   
\
-| OPTION_MASK_FUTURE   \
+| OPTION_MASK_FUTURE)
+
+/* Addressing related flags on a future processor.  These flags are broken out
+   because not all targets will support either pc-relative addressing, or even
+   prefixed addressing, and we want to clear all of the addressing bits
+   on targets that cannot support prefixed/pcrel addressing.  */
+#define ADDRESSING_FUTURE_MASKS(OPTION_MASK_PCREL  
\
 | OPTION_MASK_PREFIXED_ADDR)
 
 /* Flags that need to be turned off if -mno-future.  */
-#define OTHER_FUTURE_MASKS (OPTION_MASK_PCREL  \
-| OPTION_MASK_PREFIXED_ADDR)
+#define OTHER_FUTURE_MASKS ADDRESSING_FUTURE_MASKS
 
 /* Flags that need to be turned off if -mno-power9-vector.  */
 #define OTHER_P9_VECTOR_MASKS  (OPTION_MASK_FLOAT128_HW\
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 276724)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -98,6 +98,16 @@
 #endif
 #endif
 
+/* Set up the defaults for whether prefixed addressing is used, and if it is
+   used, whether we want to turn on pc-relative support by default.  */
+#ifndef TARGET_PREFIXED_ADDR_DEFAULT
+#define TARGET_PREFIXED_ADDR_DEFAULT   0
+#endif
+
+#ifndef TARGET_PCREL_DEFAULT
+#define TARGET_PCREL_DEFAULT   0
+#endif
+
 /* Support targetm.vectorize.builtin_mask_for_load.  */
 GTY(()) tree altivec_builtin_mask_for_load;
 
@@ -2532,6 +2542,14 @@ rs6000_debug_reg_global (void)
   if (TARGET_DIRECT_MOVE_128)
 fprintf (stderr, DEBUG_FMT_D, "VSX easy 64-bit mfvsrld element",
 (int)VECTOR_ELEMENT_MFVSRLD_64BIT);
+
+  if (TARGET_FUTURE)
+{
+  fprintf (stderr, DEBUG_FMT_D, "TARGET_PREFIXED_ADDR_DEFAULT",
+  TARGET_PREFIXED_ADDR_DEFAULT);
+  fprintf (stderr, DEBUG_FMT_D, "TARGET_PCREL_DEFAULT",
+  TARGET_PCREL_DEFAULT);
+}
 }
 
 
@@ -4012,26 +4030,6 @@ rs6000_option_override_internal (bool gl
   rs6000_isa_flags &= ~OPTION_MASK_FLOAT128_HW;
 }
 
-  /* -mprefi

Re: Make C2X imply -fno-fp-int-builtin-inexact

[Joseph Myers]

On Wed, 9 Oct 2019, Rainer Orth wrote:

> the new test FAILs on Solaris/x86, both 32 and 64-bit:
> 
> FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O0  execution test
> FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O1  execution test
> FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O2  execution test
> FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O2 -flto  execution test
> FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O2 -flto 
> -flto-partition=none  execution test
> FAIL: gcc.dg/torture/builtin-fp-int-inexact-c2x.c   -O3 -g  execution test
> 
> The test aborts.  This happens because dg-add-options c99_runtime
> appends -std=c99 to the options, yielding -std=c2x -std=c99.  If I
> manually omit the -std=c99, the test PASSes.  I'm uncertain yet how to
> handle this.  Maybe prepending -std=c99 is an option, but that may well
> break other tests...

Since the default standard is now gnu11, I'd hope that dg-add-options 
c99_runtime doesn't actually need to add any options at all.  (Unless 
there are tests using it with an explicit pre-C99 standard, which would 
seem rather nonsensical.)

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

Re: [PATCH], V4, patch #9 [part of patch #4.2], Add prefixed address offset checks

[Segher Boessenkool]

Hi!

On Fri, Oct 04, 2019 at 08:29:11AM -0400, Michael Meissner wrote:
> @@ -8651,6 +8675,11 @@ rs6000_legitimate_address_p (machine_mod
>&& mode_supports_pre_incdec_p (mode)
>&& legitimate_indirect_address_p (XEXP (x, 0), reg_ok_strict))
>  return 1;
> +
> +  /* Handle prefixed addresses (PC-relative or 34-bit offset).  */
> +  if (address_is_prefixed (x, mode, NON_PREFIXED_DEFAULT))
> +return 1;

Is this correct?  Are addresses with a larger offset always legitimate?
I don't see why that would be the case.

The rest of the patch looks good, thanks.


Segher

Re: [patch, fortran] Fix PR 92004, restore Lapack compilation

[Thomas Koenig]

Hi Tobias,


function ("o" missing); I think it is not clause 14 but paragraph 14.


Fixed. (That one was easy :-)


+   warning for this can be suppressed later.  */
+
+bool
+maybe_dummy_array_arg (gfc_expr *e)
+{
+  gfc_symbol *s;
+
+  if (e->rank > 0)
+    return false;
+
+  if (e->ts.type == BT_CHARACTER && e->ts.kind == 1)
+    return true;
+
+  if (e->expr_type != EXPR_VARIABLE)
+    return false;


What about PARAMETER? :-)


Good catch.

I found that, by the time the code is reached, an element of a
parameter array is already simplified; so I added a flag during
constructor expansion.




+  s = e->symtree->n.sym;
+  if (s->as == NULL)
+    return false;


This looks wrong. You also want to permit dt%array(1) – but not 
dt(1)%scalar


Fixed.


+  if (s->ts.type == BT_CLASS || s->as->type == AS_ASSUMED_SHAPE
+  || s->attr.pointer)
+    return false;


dt%foo – again, "foo" can be an allocatable of polymorphic type or a 
pointer, but at least, it cannot be of assumed shape.


Really? The paragraph reads

# 14 If the actual argument is a noncoindexed scalar, the corresponding
# dummy argument shall be scalar unless
# * the actual argument is default character, of type character with the
#   C character kind (18.2.2), or is an element or substring of an
#   element of an array that is not an assumed-shape, pointer, or
#   polymorphic array,

(The last two points do not apply here because they are invalid without
explicit interface).  Unless I have my negatives wrong, the code is
correct (but I have been getting standardese wrong before).

Anyway, here's an update of the patch. OK, or is there still something
missing?  Or how should I interpret that paragraph? :-)

Regards

Thomas
Index: array.c
===
--- array.c	(Revision 276506)
+++ array.c	(Arbeitskopie)
@@ -1763,6 +1763,7 @@ expand_constructor (gfc_constructor_base base)
 	  gfc_free_expr (e);
 	  return false;
 	}
+  e->from_constructor = 1;
   current_expand.offset = &c->offset;
   current_expand.repeat = &c->repeat;
   current_expand.component = c->n.component;
Index: gfortran.h
===
--- gfortran.h	(Revision 276506)
+++ gfortran.h	(Arbeitskopie)
@@ -1614,6 +1614,9 @@ typedef struct gfc_symbol
   /* Set if a previous error or warning has occurred and no other
  should be reported.  */
   unsigned error:1;
+  /* Set if an interface to a procedure could actually be to an array
+ although the actual argument is scalar.  */
+  unsigned maybe_array:1;
 
   int refs;
   struct gfc_namespace *ns;	/* namespace containing this symbol */
@@ -2194,6 +2197,11 @@ typedef struct gfc_expr
   /* Set this if no warning should be given somewhere in a lower level.  */
 
   unsigned int do_not_warn : 1;
+
+  /* Set this if the expression came from expanding an array constructor.  */
+
+  unsigned int from_constructor : 1;
+
   /* If an expression comes from a Hollerith constant or compile-time
  evaluation of a transfer statement, it may have a prescribed target-
  memory representation, and these cannot always be backformed from
Index: interface.c
===
--- interface.c	(Revision 276506)
+++ interface.c	(Arbeitskopie)
@@ -2229,6 +2229,46 @@ argument_rank_mismatch (const char *name, locus *w
 }
 
 
+/* Under certain conditions, a scalar actual argument can be passed
+   to an array dummy argument - see F2018, 15.5.2.4, clause 14.  This
+   functin returns true for these conditions so that an error or
+   warning for this can be suppressed later.  */
+
+bool
+maybe_dummy_array_arg (gfc_expr *e)
+{
+  gfc_symbol *s;
+  gfc_ref *ref;
+  bool last_array_ref;
+
+  if (e->rank > 0)
+return false;
+
+  if (e->ts.type == BT_CHARACTER && e->ts.kind == 1)
+return true;
+
+  if (e->expr_type == EXPR_CONSTANT)
+return e->from_constructor;
+
+  if (e->expr_type != EXPR_VARIABLE)
+return false;
+
+  s = e->symtree->n.sym;
+  if (s->as == NULL)
+return false;
+
+  if (s->ts.type == BT_CLASS || s->as->type == AS_ASSUMED_SHAPE
+  || s->attr.pointer)
+return false;
+
+  last_array_ref = false;
+
+  for (ref=e->ref; ref; ref=ref->next)
+last_array_ref = ref->type == REF_ARRAY;
+
+  return last_array_ref;
+}
+
 /* Given a symbol of a formal argument list and an expression, see if
the two are compatible as arguments.  Returns true if
compatible, false if not compatible.  */
@@ -2544,7 +2584,9 @@ compare_parameter (gfc_symbol *formal, gfc_expr *a
   || (actual->rank == 0 && formal->attr.dimension
 	  && gfc_is_coindexed (actual)))
 {
-  if (where)
+  if (where 
+	  && (!formal->attr.artificial || (!formal->maybe_array
+	   && !maybe_dummy_array_arg (actual
 	{
 	  locus *where_formal;
 	  if (formal->attr.artificial)
@@ -2594,9 +2636,17 @@ compare_parameter (gfc_symbol *formal, gfc_expr *a
   &&

Re: [PATCH], V4, patch #9 [part of patch #4.2], Add prefixed address offset checks

[Michael Meissner]

On Wed, Oct 09, 2019 at 04:56:48PM -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Fri, Oct 04, 2019 at 08:29:11AM -0400, Michael Meissner wrote:
> > @@ -8651,6 +8675,11 @@ rs6000_legitimate_address_p (machine_mod
> >&& mode_supports_pre_incdec_p (mode)
> >&& legitimate_indirect_address_p (XEXP (x, 0), reg_ok_strict))
> >  return 1;
> > +
> > +  /* Handle prefixed addresses (PC-relative or 34-bit offset).  */
> > +  if (address_is_prefixed (x, mode, NON_PREFIXED_DEFAULT))
> > +return 1;
> 
> Is this correct?  Are addresses with a larger offset always legitimate?
> I don't see why that would be the case.
> 
> The rest of the patch looks good, thanks.

As far as I know, with the exception of SDmode (which is not allowed to have an
offset) all other modes that use D*-form addresses would work with a prefixed
instruction, assuming the offset fits in the 34-bit field.

The function address_to_insn_form, which is called by address_is_prefixed,
checks if the offset is 34-bits or less, whether the mode is SDmode, etc. are
all valid.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH], V4, patch #9 [part of patch #4.2], Add prefixed address offset checks

[Michael Meissner]

On Wed, Oct 09, 2019 at 04:56:48PM -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Fri, Oct 04, 2019 at 08:29:11AM -0400, Michael Meissner wrote:
> > @@ -8651,6 +8675,11 @@ rs6000_legitimate_address_p (machine_mod
> >&& mode_supports_pre_incdec_p (mode)
> >&& legitimate_indirect_address_p (XEXP (x, 0), reg_ok_strict))
> >  return 1;
> > +
> > +  /* Handle prefixed addresses (PC-relative or 34-bit offset).  */
> > +  if (address_is_prefixed (x, mode, NON_PREFIXED_DEFAULT))
> > +return 1;
> 
> Is this correct?  Are addresses with a larger offset always legitimate?
> I don't see why that would be the case.
> 
> The rest of the patch looks good, thanks.

This patch BTW is the same as the new V5 patch #1.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: C++ PATCH to merge concepts-cxx2a branch

[Romain Geissler]

Le mer. 9 oct. 2019 à 19:20, Jason Merrill  a écrit :
>
> Andrew has done a lot of work to update the GCC implementation of C++
> concepts to conform to the upcoming C++20 standard, which clarifies,
> removes, and changes various aspects of the earlier concepts TS.  It can
> still use some polishing, but other stage 1 projects are waiting for it
> to land on trunk and it's already a big improvement from what's
> currently there, so I'm going to go ahead and merge it now.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.

Hi Jason,

This is a very good news to see preliminary concept support being
merged in the trunk :)

However for me, this caused the following bootstrap failure:

In file included from /workdir/src/gcc-10.0.0/gcc/cp/cp-lang.c:24:
/workdir/src/gcc-10.0.0/gcc/cp/cp-tree.h: In function 'tree_node*
template_info_decl_check(const_tree, const char*, int, const char*)':
/workdir/src/gcc-10.0.0/gcc/cp/cp-tree.h:3368:3: error:
'tree_check_failed' was not declared in this scope
   tree_check_failed (t, f, l, fn,
   ^
/workdir/src/gcc-10.0.0/gcc/cp/cp-tree.h:3368:3: note: suggested
alternative: 'vec_check_alloc'
   tree_check_failed (t, f, l, fn,
   ^
   vec_check_alloc
make[2]: *** [Makefile:1118: cp/cp-lang.o] Error 1

Cheers,
Romain

[ARM] Enable DF only when TARGET_VFP_DOUBLE

[Kugan Vivekanandarajah]

As reported in Linaro bug report
(https://bugs.linaro.org/show_bug.cgi?id=4636 ; there is no
reproducible testcase provided), for some applications, we see

(insn 126 125 127 9 (set (reg:DF 189)
(fma:DF (reg:DF 126 [ _74 ])
(reg:DF 190)
(reg:DF 191))) "ops.c":30 -1
 (nil))

This looks like due to a typo in the md patterns. Attached patch fixes
this. Bootsrapped and regression tested on arm-linux-gnueabihf without
any regressions.  Is this OK for trunk?

Thanks,
Kugan

gcc/ChangeLog:

2019-10-10  kugan.vivekanandarajah  

* config/arm/vfp.md (fma4): Enable DF only when
TARGET_VFP_DOUBLE.
(*fmsub4): Likewise.
(*fnmsub4): Likewise.
(*fnmadd4): Likewise.
diff --git a/gcc/config/arm/vfp.md b/gcc/config/arm/vfp.md
index 661919e2357..1979aa6fdb4 100644
--- a/gcc/config/arm/vfp.md
+++ b/gcc/config/arm/vfp.md
@@ -1321,7 +1321,7 @@
 (fma:SDF (match_operand:SDF 1 "register_operand" "")
 (match_operand:SDF 2 "register_operand" "")
 (match_operand:SDF 3 "register_operand" "0")))]
-  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA"
+  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA "
   "vfma%?.\\t%0, %1, %2"
   [(set_attr "predicable" "yes")
(set_attr "type" "ffma")]
@@ -1357,7 +1357,7 @@
 ""))
 (match_operand:SDF 2 "register_operand" "")
 (match_operand:SDF 3 "register_operand" "0")))]
-  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA"
+  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA "
   "vfms%?.\\t%0, %1, %2"
   [(set_attr "predicable" "yes")
(set_attr "type" "ffma")]
@@ -1379,7 +1379,7 @@
(fma:SDF (match_operand:SDF 1 "register_operand" "")
 (match_operand:SDF 2 "register_operand" "")
 (neg:SDF (match_operand:SDF 3 "register_operand" "0"]
-  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA"
+  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA "
   "vfnms%?.\\t%0, %1, %2"
   [(set_attr "predicable" "yes")
(set_attr "type" "ffma")]
@@ -1402,7 +1402,7 @@
   ""))
 (match_operand:SDF 2 "register_operand" "")
 (neg:SDF (match_operand:SDF 3 "register_operand" "0"]
-  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA"
+  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA "
   "vfnma%?.\\t%0, %1, %2"
   [(set_attr "predicable" "yes")
(set_attr "type" "ffma")]