[PATCH] Allow ChangeLog entries for ignored location.

[Martin Liška]

We should be able to generate ChangeLog entries for
commits like b3d566f570f4416299240b51654b70c74f6cba6a.
I'm going to install the patch.

contrib/ChangeLog:

* gcc-changelog/git_commit.py: Parse changelog entries for
ignored locations.
* gcc-changelog/test_email.py: Add new test for it.
* gcc-changelog/test_patches.txt: Likewise.
---
 contrib/gcc-changelog/git_commit.py| 16 +++
 contrib/gcc-changelog/test_email.py|  5 
 contrib/gcc-changelog/test_patches.txt | 40 ++
 3 files changed, 55 insertions(+), 6 deletions(-)

diff --git a/contrib/gcc-changelog/git_commit.py 
b/contrib/gcc-changelog/git_commit.py
index 2cfdbc83d09..edd8834b898 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -233,8 +233,9 @@ class GitCommit:
 
 project_files = [f for f in self.modified_files

  if self.is_changelog_filename(f[0])
- or f[0] in misc_files
- or self.in_ignored_location(f[0])]
+ or f[0] in misc_files]
+ignored_files = [f for f in self.modified_files
+ if self.in_ignored_location(f[0])]
 if len(project_files) == len(self.modified_files):
 # All modified files are only MISC files
 return
@@ -244,7 +245,9 @@ class GitCommit:
  'separately from normal commits'))
 return
 
-self.parse_lines()

+all_are_ignored = (len(project_files) + len(ignored_files)
+   == len(self.modified_files))
+self.parse_lines(all_are_ignored)
 if self.changes:
 self.parse_changelog()
 self.deduce_changelog_locations()
@@ -292,7 +295,7 @@ class GitCommit:
 modified_files.append((parts[2], 'A'))
 return modified_files
 
-def parse_lines(self):

+def parse_lines(self, all_are_ignored):
 body = self.lines
 
 for i, b in enumerate(body):

@@ -303,8 +306,9 @@ class GitCommit:
 or dr_regex.match(b) or author_line_regex.match(b)):
 self.changes = body[i:]
 return
-self.errors.append(Error('cannot find a ChangeLog location in '
- 'message'))
+if not all_are_ignored:
+self.errors.append(Error('cannot find a ChangeLog location in '
+ 'message'))
 
 def parse_changelog(self):

 last_entry = None
diff --git a/contrib/gcc-changelog/test_email.py 
b/contrib/gcc-changelog/test_email.py
index aa516c6e6d1..bf028a3d40a 100755
--- a/contrib/gcc-changelog/test_email.py
+++ b/contrib/gcc-changelog/test_email.py
@@ -280,3 +280,8 @@ class TestGccChangelog(unittest.TestCase):
 def test_changes_only_in_ignored_location(self):
 email = self.from_patch_glob('0001-go-in-ignored-location.patch')
 assert not email.errors
+
+def test_changelog_for_ignored_location(self):
+email = self.from_patch_glob('0001-Update-merge.sh-to-reflect.patch')
+assert (email.changelog_entries[0].lines[0]
+== '\t* LOCAL_PATCHES: Use git hash instead of SVN id.')
diff --git a/contrib/gcc-changelog/test_patches.txt 
b/contrib/gcc-changelog/test_patches.txt
index 58fd81c85c9..84d4b81d818 100644
--- a/contrib/gcc-changelog/test_patches.txt
+++ b/contrib/gcc-changelog/test_patches.txt
@@ -2611,3 +2611,43 @@ index 000..2609cc49ae7
 
 --

 2.27.0.rc0.183.gde8f92d652-goog
+=== 0001-Update-merge.sh-to-reflect.patch  ===
+From b3d566f570f4416299240b51654b70c74f6cba6a Mon Sep 17 00:00:00 2001
+From: Martin Liska 
+Date: Mon, 25 May 2020 20:55:29 +0200
+Subject: [PATCH] Update merge.sh to reflect usage of git.
+
+After switching to GIT, we should use it in libsanitizer
+merge script. I'll do merge from master as soon as
+PR95311 gets fixed.
+
+I'm going to install the patch.
+
+libsanitizer/ChangeLog:
+
+   * LOCAL_PATCHES: Use git hash instead of SVN id.
+   * merge.sh: Use git instead of VCS.  Update paths
+   relative to upstream git repository.
+---
+ libsanitizer/LOCAL_PATCHES |  2 +-
+ libsanitizer/merge.sh  | 10 --
+ 2 files changed, 5 insertions(+), 7 deletions(-)
+
+diff --git a/libsanitizer/LOCAL_PATCHES b/libsanitizer/LOCAL_PATCHES
+index 292b7a6e489..7732de3d436 100644
+--- a/libsanitizer/LOCAL_PATCHES
 b/libsanitizer/LOCAL_PATCHES
+@@ -1 +1,2 @@
+
++
+diff --git a/libsanitizer/merge.sh b/libsanitizer/merge.sh
+index dfa7bf3d196..3f4f1629a22 100755
+--- a/libsanitizer/merge.sh
 b/libsanitizer/merge.sh
+@@ -1 +1,2 @@
+
++
+
+--
+2.26.2
+
--
2.26.2

Re: [PATCH 0/7] Support vector load/store with length

[Richard Biener]

On Tue, 26 May 2020, Kewen.Lin wrote:

> Hi all,
> 
> This patch set adds support for vector load/store with length, Power 
> ISA 3.0 brings instructions lxvl/stxvl to perform vector load/store with
> length, it's good to be exploited for those cases we don't have enough
> stuffs to fill in the whole vector like epilogues.
> 
> This support mainly refers to the handlings for fully-predicated loop
> but it also covers the epilogue usage.  Now it supports two modes
> controlled by parameter vect-with-length-scope, it can support any
> loops fully with length or just for those cases with small iteration
> counts less than VF like epilogue, for now I don't have ready env to
> benchmark it, but based on the current inefficient length generation,
> I don't think it's a good idea to adopt vector with length for any loops.
> For the main loop which used to be vectorized, it increases register
> pressure and introduces extra computation for length, the pro for icache
> seems not comparable.  But I think it might be a good idea to keep this
> parameter there for functionality testing, further benchmarking and other
> ports' potential future supports.

Can you explain in more detail what "vector load/store with length" does?
Is that a "simplified" masked load/store which instead of masking 
arbitrary elements (and need a mask computed in the first place), masks
elements > N (the length operand)?  Thus assuming a lane IV decrementing
to zero that IV would be the natural argument for the length operand?
If that's correct, what data are the remaining lanes filled with?

>From a look at the series description below you seem to add a new way
of doing loads for this.  Did you review other ISAs (those I'm not
familiar with myself too much are SVE, RISC-V and GCN) in GCC whether
they have similar support and whether your approach can be supported
there?  ISTR SVE must have some similar support - what's the reason
you do not piggy-back on that?

I think a load like I described above might be represented as

_1 = __VIEW_CONVERT  (__MEM  ((double *)p_3));

not sure if that actually works out though.  But given it seems it
is a contiguous load we shouldn't need an internal function here?
[there's a possible size mismatch in the __VIEW_CONVERT above, I guess
on RTL you end up with a paradoxical subreg - or an UNSPEC]

That said, I'm not very happy seeing yet another way of doing loads
[for fully predicated loops].  I'd rather like to see a single
representation on GIMPLE at least.

Will dig into the patch once the actual workings of those load/store with
length is confirmed.

I don't spot tree-vect-slp.c being changed - maybe that's not necessary
for SLP operation, but please do not introduce new vectorizer features
without supporting SLP operation at this point.

Thanks,
Richard.

> As we don't have any benchmarking, this support isn't enabled by default
> for any particular cpus, all testings are with explicit parameter setting.
> 
> Bootstrapped on powerpc64le-linux-gnu P9 with all vect-with-length-scope
> settings (0/1/2).  Regress-test passed with vector-with-length-scope 0,
> for the other twos, several vector related cases need to be updated, no
> remarkable failures found.  BTW, P9 is the one which supports the
> functionality but not ready to evaluate the performance.
> 
> Here still are many things to be supported or improved, not limited to:
>   - reduction/live-out support
>   - Cost model adding/tweaking
>   - IFN gimple folding
>   - Some unnecessary ops improvements eg: vector_size check
>   - Some possible refactoring
> I'll support/post the patches gradually.
> 
> Any comments are highly appreciated.
> 
> BR,
> Kewen
> -
> 
> Patch set outline:
>   [PATCH 1/7] ifn/optabs: Support vector load/store with length
>   [PATCH 2/7] rs6000: lenload/lenstore optab support
>   [PATCH 3/7] vect: Factor out codes for niters smaller than vf check
>   [PATCH 4/7] hook/rs6000: Add vectorize length mode for vector with length
>   [PATCH 5/7] vect: Support vector load/store with length in vectorizer
>   [PATCH 6/7] ivopts: Add handlings for vector with length IFNs
>   [PATCH 7/7] rs6000/testsuite: Vector with length test cases
> 
>  gcc/config/rs6000/rs6000.c  |   3 +
>  gcc/config/rs6000/vsx.md|  30 ++
>  gcc/doc/invoke.texi |   7 +++
>  gcc/doc/md.texi |  16 ++
>  gcc/doc/tm.texi |   6 ++
>  gcc/doc/tm.texi.in  |   2 +
>  gcc/internal-fn.c   |  13 -
>  gcc/internal-fn.def |   6 ++
>  gcc/optabs.def  |   2 +
>  gcc/params.opt  |   4 ++
>  gcc/target.def  |   7 +++
>  gc

Re: [PATCH RFC] gcc-git: Add prepare-commit-msg hook.

[Martin Liška]

Hi.

There's a small improvement. When filling up the ChangeLog entries,
I see it handy to open a patch in a separate window. I would use
GCC_DIFF_FILE env. variable for saving of the diff file.

Thoughts?
Martin
>From bffc1bdd709b5152f290febb334b009c2f225872 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Tue, 26 May 2020 09:08:31 +0200
Subject: [PATCH] prepare-commit-msg: Save diff if requested by user.

contrib/ChangeLog:

	* prepare-commit-msg: Save diff to a file if
	the GCC_DIFF_FILE variable is set.
---
 contrib/prepare-commit-msg | 5 +
 1 file changed, 5 insertions(+)

diff --git a/contrib/prepare-commit-msg b/contrib/prepare-commit-msg
index 820dacc7e42..b2123317308 100755
--- a/contrib/prepare-commit-msg
+++ b/contrib/prepare-commit-msg
@@ -54,4 +54,9 @@ else
 exit 0
 fi
 
+# Save diff to a file if requested.
+if ! [ -z "$GCC_DIFF_FILE" ]; then
+  git $cmd > "$GCC_DIFF_FILE";
+fi
+
 git $cmd | git gcc-mklog -c "$COMMIT_MSG_FILE"
-- 
2.26.2

Re: ChangeLog files - server and client scripts

[Alexandre Oliva]

Hi, Martin,

On May 26, 2020, Martin Liška  wrote:

>> I've long used the following syntax to start ChangeLog entries:
>> 
>> for  /ChangeLog

> Ah, it's new for me.

>> 
>> It was introduced over 20 years ago, with the (so far never formally
>> released) GNU CVS-Utilities.  Among other goodies, there were scripts to
>> turn diffs for ChangeLog files into the above format, and vice-versa,
>> that I've used to this day.  It went through cvs, svn and git.  It would
>> be quite nice if I could keep on using it with GCC. ^^

For clarity, I meant the syntax in the last sentence above.  The
ChangeLog-related functionality in the scripts now becomes mostly
obsolete.

>> The patch below seems to be enough to pass gcc-verify, and to recognize
>> and print the expected ChangeLog files.

'cept it broke cases without 'for' because I missed a '?' in the
regexp.  Good thing I had to adjust for the old format to be able to
push it ;-)  2x0 ;-)

>> Do any hooks need to be adjusted to match?

> Yes, we sync the script from the GCC repository.

Here's what I'm about to push


accept for dir/ChangeLog entries

From: Alexandre Oliva 

I've long introduced ChangeLog entries as "for  dir/ChangeLog", a
format adopted by GNU CVS-Utilities some 20 years ago.  My commits
have been formatted like this forever.

This patch makes it acceptable for git gcc-verify.


contrib/ChangeLog:

* gcc-changelog/git_commit.py (changelog_regex): Accept optional
'for' prefix.
---
 contrib/gcc-changelog/git_commit.py |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/gcc-changelog/git_commit.py 
b/contrib/gcc-changelog/git_commit.py
index 2cfdbc8..732a9bd8 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -144,7 +144,7 @@ misc_files = [
 author_line_regex = \
 re.compile(r'^(?P\d{4}-\d{2}-\d{2})\ {2}(?P.*  <.*>)')
 additional_author_regex = re.compile(r'^\t(?P\ *)?(?P.*  <.*>)')
-changelog_regex = re.compile(r'^([a-z0-9+-/]*)/ChangeLog:?')
+changelog_regex = re.compile(r'^(?:[fF]or +)?([a-z0-9+-/]*)/ChangeLog:?')
 pr_regex = re.compile(r'\tPR (?P[a-z+-]+\/)?([0-9]+)$')
 dr_regex = re.compile(r'\tDR ([0-9]+)$')
 star_prefix_regex = re.compile(r'\t\*(?P\ *)(?P.*)')


-- 
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist  Stallman was right, but he's left :(
GNU Toolchain Engineer   Live long and free, and prosper ethically

[committed] openmp: Ensure copy ctor for composite distribute parallel for class iterators is instantiated [PR95197]

[Jakub Jelinek via Gcc-patches]

Hi!

During gimplification omp_finish_clause langhook is called in several places
to add the language specific info to the clause like what default/copy ctors,
dtors and assignment operators should be used.

Unfortunately, if it refers to some not yet instantiated method, during
gimplification it is too late and the methods will not be instantiated
anymore.  For other cases, the genericizer has code to detect those and
instantiate whatever is needed, this change adds the same for
distribute parallel for class iterators where we under the hood need
a copy constructor for the iterator to implement it.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
(so far).

2020-05-26  Jakub Jelinek  

PR c++/95197
* gimplify.c (find_combined_omp_for): Move to omp-general.c.
* omp-general.h (find_combined_omp_for): Declare.
* omp-general.c: Include tree-iterator.h.
(find_combined_omp_for): New function, moved from gimplify.c.

* cp-gimplify.c: Include omp-general.h.
(cp_genericize_r) : For class iteration
variables in composite distribute parallel for, instantiate copy
ctor of their types.

--- gcc/gimplify.c.jj   2020-05-19 10:08:58.0 +0200
+++ gcc/gimplify.c  2020-05-25 16:58:32.116416252 +0200
@@ -10963,62 +10963,6 @@ gimplify_omp_task (tree *expr_p, gimple_
   *expr_p = NULL_TREE;
 }
 
-/* Helper function of gimplify_omp_for, find OMP_FOR resp. OMP_SIMD
-   with non-NULL OMP_FOR_INIT.  Also, fill in pdata array,
-   pdata[0] non-NULL if there is anything non-trivial in between, pdata[1]
-   is address of OMP_PARALLEL in between if any, pdata[2] is address of
-   OMP_FOR in between if any and pdata[3] is address of the inner
-   OMP_FOR/OMP_SIMD.  */
-
-static tree
-find_combined_omp_for (tree *tp, int *walk_subtrees, void *data)
-{
-  tree **pdata = (tree **) data;
-  *walk_subtrees = 0;
-  switch (TREE_CODE (*tp))
-{
-case OMP_FOR:
-  if (OMP_FOR_INIT (*tp) != NULL_TREE)
-   {
- pdata[3] = tp;
- return *tp;
-   }
-  pdata[2] = tp;
-  *walk_subtrees = 1;
-  break;
-case OMP_SIMD:
-  if (OMP_FOR_INIT (*tp) != NULL_TREE)
-   {
- pdata[3] = tp;
- return *tp;
-   }
-  break;
-case BIND_EXPR:
-  if (BIND_EXPR_VARS (*tp)
- || (BIND_EXPR_BLOCK (*tp)
- && BLOCK_VARS (BIND_EXPR_BLOCK (*tp
-   pdata[0] = tp;
-  *walk_subtrees = 1;
-  break;
-case STATEMENT_LIST:
-  if (!tsi_one_before_end_p (tsi_start (*tp)))
-   pdata[0] = tp;
-  *walk_subtrees = 1;
-  break;
-case TRY_FINALLY_EXPR:
-  pdata[0] = tp;
-  *walk_subtrees = 1;
-  break;
-case OMP_PARALLEL:
-  pdata[1] = tp;
-  *walk_subtrees = 1;
-  break;
-default:
-  break;
-}
-  return NULL_TREE;
-}
-
 /* Gimplify the gross structure of an OMP_FOR statement.  */
 
 static enum gimplify_status
--- gcc/omp-general.h.jj2020-05-11 21:52:34.825267071 +0200
+++ gcc/omp-general.h   2020-05-25 16:59:39.275409434 +0200
@@ -82,6 +82,7 @@ extern tree omp_get_for_step_from_incr (
 extern void omp_extract_for_data (gomp_for *for_stmt, struct omp_for_data *fd,
  struct omp_for_data_loop *loops);
 extern gimple *omp_build_barrier (tree lhs);
+extern tree find_combined_omp_for (tree *, int *, void *);
 extern poly_uint64 omp_max_vf (void);
 extern int omp_max_simt_vf (void);
 extern int omp_constructor_traits_to_codes (tree, enum tree_code *);
--- gcc/omp-general.c.jj2020-05-19 10:08:30.510650262 +0200
+++ gcc/omp-general.c   2020-05-25 17:21:24.721933786 +0200
@@ -42,6 +42,7 @@ along with GCC; see the file COPYING3.
 #include "hsa-common.h"
 #include "tree-pass.h"
 #include "omp-device-properties.h"
+#include "tree-iterator.h"
 
 enum omp_requires omp_requires_mask;
 
@@ -504,6 +505,61 @@ omp_build_barrier (tree lhs)
   return g;
 }
 
+/* Find OMP_FOR resp. OMP_SIMD with non-NULL OMP_FOR_INIT.  Also, fill in pdata
+   array, pdata[0] non-NULL if there is anything non-trivial in between,
+   pdata[1] is address of OMP_PARALLEL in between if any, pdata[2] is address
+   of OMP_FOR in between if any and pdata[3] is address of the inner
+   OMP_FOR/OMP_SIMD.  */
+
+tree
+find_combined_omp_for (tree *tp, int *walk_subtrees, void *data)
+{
+  tree **pdata = (tree **) data;
+  *walk_subtrees = 0;
+  switch (TREE_CODE (*tp))
+{
+case OMP_FOR:
+  if (OMP_FOR_INIT (*tp) != NULL_TREE)
+   {
+ pdata[3] = tp;
+ return *tp;
+   }
+  pdata[2] = tp;
+  *walk_subtrees = 1;
+  break;
+case OMP_SIMD:
+  if (OMP_FOR_INIT (*tp) != NULL_TREE)
+   {
+ pdata[3] = tp;
+ return *tp;
+   }
+  break;
+case BIND_EXPR:
+  if (BIND_EXPR_VARS (*tp)
+ || (BIND_EXPR_BLOCK (*tp)
+ && BLOCK_VARS (BIND_EXPR_BLOCK (*tp
+   pdata[0] = tp;
+  *walk_subtrees = 1;
+   

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

[Alexandre Oliva]

On May 21, 2020, Alexandre Oliva  wrote:

> On May 19, 2020, Richard Biener  wrote:

>> Thanks again for doing this.  May I also suggest to prepare a short
>> entry for gcc-11/changes.html with these things (like "Output of
>> auxiliary files changed.  See https://gcc.gnu.org/ml/gcc-patches/...
>> for details")?

> How about, under Caveats:

> * Naming and location of auxiliary and dump output files changed.  If
> you compile multiple input files in a single command, if you enable Link
> Time Optimization, or if you use -dumpbase, -dumpdir, -save-temps=*, and
> you expect any file other than the primary output file(s) to be created
> as a side effect, watch out for improvements and a few surprises.  See
> https://gcc.gnu.org/ml/...


Here's the patch I'm pushing to wwwdocs:


gcc-11/changes: -dump* and -aux* revamp

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

diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index e88a628..2f00d1f 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -30,7 +30,15 @@ a work-in-progress.
 
 Caveats
 
-  ...
+  Naming and location of auxiliary and dump output files changed.
+  If you compile multiple input files in a single command, if you
+  enable Link Time Optimization, or if you use -dumpbase,
+  -dumpdir, -save-temps=*, and you expect any file other than the
+  primary output file(s) to be created as a side effect, watch out
+  for improvements and a few surprises.
+  See https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546494.html";>the
+  patch, particularly its textual description, for more
+  details about the changes.
 
 
 


-- 
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist  Stallman was right, but he's left :(
GNU Toolchain Engineer   Live long and free, and prosper ethically

Re: [PATCH 1/2] rs6000: tune cunroll for simple loops at O2

[Jiufu Guo via Gcc-patches]

Richard Biener  writes:

> On Mon, May 25, 2020 at 7:44 PM Segher Boessenkool
>  wrote:
>>
>> On Mon, May 25, 2020 at 02:39:54PM +0200, Richard Biener wrote:
>> > On Fri, May 22, 2020 at 6:54 PM Segher Boessenkool
>> >  wrote:
>> > > > The split above allows the "bug" to be fixed (even on the branch)
>> > > > without introducing even more target specialities.
>> > >
>> > > So does any split.  Or I don't see what you mean?
>> >
>> > Well, a split that does not affect behavior for non-ppc architectures
>> > when the flags by users are unchanged.  Because that allows
>> > the ppc regression to be fixed on the branch.
>> >
>> > Then, on trunk, we can think of a better overall flag design.  Note
>>
>> Oh, as just a (very) temporary thing, it is fine of course (it should
>> say it is then though).
>>
>> > that cunroll/cunrolli are not controlled by a flag currently, they
>> > are gated on optimize >= [2|3] - it's just that either -funroll-loops
>> > or -fpeel-loops causes its heuristics to allow code-size growth
>> > by its own metrics according to the unroll --params.
>> >
>> > So it's a bit difficult to retrofit the heuristic behavior onto new
>> > flags unless we want to completely move that over to a --param
>> > that may be gets adjusted by -funroll-loops.
>>
>> Yes, cunroll does not have its own option, and that is a problem.  But
>> that is easy to fix!  Either with an option, or just with params (the
>> option wouldn't do more than set params anyway?)
>
> Well, given coming up with different names for essentially the same
> transform is going to be challenging how about sth like
>
> -funroll-loops={early,late,static,dynamic}[insert better names here]
>
> note there's also -fpeel-loops which may match the transform
> done on GIMPLE better?  I'm not sure which are the technically
> correct terms for unrollings that elide the loop (the backedge).
> We're doing such kind of unrolling even if we cannot statically
> decide which of a set of possible exits we take (and internally
> call that peeling, if we can statically decide we call it complete
> unrolling).  The RTL side OTOH only performs classical unrolling,
> preserving the backedge with various strategies for the
> remaining iterations.
>
> As said, for the regression on the 10 branch with ppc I'd add
> [a hidden] flag that controls the RTL unroller, also set by
> -funroll-loops and triggered by the ppc specific heuristics.

This way would enable rtl unroller at -O2 instead enable -funroll-loops,
and then cunroll will not unroll/peel the loop if there is potential
size increasing.  This could avoid the negative affect on the loop which
mentioned in PR95018 code.

While, I still hope to tune cunroll at -O2 for ppc (or general
platforms) with keeping possitive and avoid negative affects. Yes, this
may align with what Honza plan to do.

BR,
Jiufu

>
> Richard.
>
>>
>> Segher

gcc-patches@gcc.gnu.org

[Christophe Lyon via Gcc-patches]

Hi,


On Thu, 21 May 2020 at 02:07, Jonathan Wakely via Gcc-patches
 wrote:
>
> On 21/05/20 01:01 +0100, Jonathan Wakely wrote:
> >Also add some missing member functions, nodiscard attributes, and
> >noexcept-specifiers.
> >
> >   * include/experimental/executor (use_future_t::use_future_t()): Fix
> >   incorrect noexcept-specifier.
> >   * include/experimental/internet (basic_resolver_results): Adjust
> >   whitespace.
> >   * include/experimental/socket (__basic_socket_impl::release): Add
> >   member function.
> >   (basic_socket(io_context&, const endpoint_type&)): Fix argument to
> >   target constructor.
> >   (basic_socket::release(), basic_socket::release(error_code&)): Add
> >   missing member functions.
> >   (basic_socket::is_open()): Add nodiscard attribute.
> >   (basic_socket::close(error_code&)): Pass argument to base function.
> >   (basic_socket_acceptor::release())
> >   (basic_socket_acceptor::release(error_code&)): Add missing member
> >   functions.
> >   (basic_socket_acceptor::is_open()): Add nodiscard attribute.
> >   (basic_socket_streambuf::error()): Add noexcept.
> >   (basic_socket_iostream::error()): Likewise.
> >   * testsuite/experimental/net/socket/basic_socket.cc: New test.
>

This new test fails to compile on newlib targets (aarch64-elf,
arm-eabi) because:
include/experimental/executor:509: error: 'mutex' in namespace 'std'
does not name a type
include/experimental/executor:556: error: 'mutex' is not a member of 'std'
[...]

I'm not sure what effective-target is needed here?

Thanks,

Christophe


> This adjusts the nodiscard attributes to use the _GLIBCXX_NODISCARD
> macro for consistency (even though that means the attribute isn't
> there for C++14 mode).
>
> Tested powerpc64le-linux, committed to master.
>

Simplify tree streaming

[Jan Hubicka]

Hi,
this patch cleans up tree streaming.  The code is prepared to stream nested
trees, but we only handle flat trees. As a result we have quite heavy function
to stream in/out tree reference which is used many times and shows up in
profile.

This patch adds stream_write_tree_ref/stream_read_tree_ref which is used to
stream references to trees that are required to exist in the cache or be
indexable.

The actual implementation is just a first cut.  I would like to make it more
compact. We used to stream 2 byte tag (as UHWI) + UHWI representing the index.
Now we stream one UHWI that represent type of reference + index for references
to cache, but still two integers for references to global stream.  This is
becaue the abstraction is not very helpful here and I want to clean this up
incrementally.

I would also like to get rid of the ref_p parameters which seems unnecessary for
flat streams.

This reduces around 7% of global stream, 3% when compressed.
More reduction will happen once the format is sanitized a bit.

from
[WPA] read 4597161 unshared trees
[WPA] read 2937414 mergeable SCCs of average size 1.364280
[WPA] 8604617 tree bodies read in total
[WPA] tree SCC table: size 524287, 247507 elements, collision ratio: 0.377468
[WPA] tree SCC max chain length 2 (size 1)
[WPA] Compared 2689907 SCCs, 184 collisions (0.68)
[WPA] Merged 2689890 SCCs
[WPA] Merged 3722677 tree bodies
[WPA] Merged 632040 types
...
[WPA] Compression: 88124141 input bytes, 234906430 uncompressed bytes (ratio: 
2.665631)
[WPA] Size of mmap'd section decls: 88124141 bytes
...
[WPA] Compression: 113758813 input bytes, 316149514 uncompressed bytes (ratio: 
2.779121)
[WPA] Size of mmap'd section decls: 88124141 bytes
[WPA] Size of mmap'd section function_body: 14485721 bytes

to

[WPA] read 4597174 unshared trees
[WPA] read 2937413 mergeable SCCs of average size 1.364280
[WPA] 8604629 tree bodies read in total
[WPA] tree SCC table: size 524287, 247509 elements, collision ratio: 0.377458
[WPA] tree SCC max chain length 2 (size 1)
[WPA] Compared 2689904 SCCs, 183 collisions (0.68)
[WPA] Merged 2689888 SCCs
[WPA] Merged 3722675 tree bodies
[WPA] Merged 632041 types

[WPA] Size of mmap'd section decls: 86177293 bytes
[WPA] Compression: 86177293 input bytes, 217625095 uncompressed bytes (ratio: 
2.525318)

[WPA] Compression: 111682269 input bytes, 297228756 uncompressed bytes (ratio: 
2.661378)
[WPA] Size of mmap'd section decls: 86177293 bytes
[WPA] Size of mmap'd section function_body: 14349032 bytes

Bootstrapped/regtested x86_64-linux, OK?

gcc/ChangeLog:

2020-05-26  Jan Hubicka  

* lto-streamer-in.c (streamer_read_chain): Move here from
tree-streamer-in.c.
(stream_read_tree_ref): New.
(lto_input_tree_1): Simplify.
* lto-streamer-out.c (stream_write_tree_ref): New.
(lto_write_tree_1): Simplify.
(lto_output_tree_1): Simplify.
(DFS::DFS_write_tree): Simplify.
(streamer_write_chain): Move here from tree-stremaer-out.c.
* lto-streamer.h (lto_output_tree_ref): Update prototype.
(stream_read_tree_ref): Declare
(stream_write_tree_ref): Declare
* tree-streamer-in.c (streamer_read_chain): Update to use
stream_read_tree_ref.
(lto_input_ts_common_tree_pointers): Likewise.
(lto_input_ts_vector_tree_pointers): Likewise.
(lto_input_ts_poly_tree_pointers): Likewise.
(lto_input_ts_complex_tree_pointers): Likewise.
(lto_input_ts_decl_minimal_tree_pointers): Likewise.
(lto_input_ts_decl_common_tree_pointers): Likewise.
(lto_input_ts_decl_with_vis_tree_pointers): Likewise.
(lto_input_ts_field_decl_tree_pointers): Likewise.
(lto_input_ts_function_decl_tree_pointers): Likewise.
(lto_input_ts_type_common_tree_pointers): Likewise.
(lto_input_ts_type_non_common_tree_pointers): Likewise.
(lto_input_ts_list_tree_pointers): Likewise.
(lto_input_ts_vec_tree_pointers): Likewise.
(lto_input_ts_exp_tree_pointers): Likewise.
(lto_input_ts_block_tree_pointers): Likewise.
(lto_input_ts_binfo_tree_pointers): Likewise.
(lto_input_ts_constructor_tree_pointers): Likewise.
(lto_input_ts_omp_clause_tree_pointers): Likewise.
* tree-streamer-out.c (streamer_write_chain): Update to use
stream_write_tree_ref.
(write_ts_common_tree_pointers): Likewise.
(write_ts_vector_tree_pointers): Likewise.
(write_ts_poly_tree_pointers): Likewise.
(write_ts_complex_tree_pointers): Likewise.
(write_ts_decl_minimal_tree_pointers): Likewise.
(write_ts_decl_common_tree_pointers): Likewise.
(write_ts_decl_non_common_tree_pointers): Likewise.
(write_ts_decl_with_vis_tree_pointers): Likewise.
(write_ts_field_decl_tree_pointers): Likewise.
(write_ts_function_decl_tree_pointers): Likewise.
(write_ts_type_common_tree_pointers): Likewise.
 

Re: [PATCH 0/7] Support vector load/store with length

[Kewen.Lin via Gcc-patches]

Hi Richi,

on 2020/5/26 下午3:12, Richard Biener wrote:
> On Tue, 26 May 2020, Kewen.Lin wrote:
> 
>> Hi all,
>>
>> This patch set adds support for vector load/store with length, Power 
>> ISA 3.0 brings instructions lxvl/stxvl to perform vector load/store with
>> length, it's good to be exploited for those cases we don't have enough
>> stuffs to fill in the whole vector like epilogues.
>>
>> This support mainly refers to the handlings for fully-predicated loop
>> but it also covers the epilogue usage.  Now it supports two modes
>> controlled by parameter vect-with-length-scope, it can support any
>> loops fully with length or just for those cases with small iteration
>> counts less than VF like epilogue, for now I don't have ready env to
>> benchmark it, but based on the current inefficient length generation,
>> I don't think it's a good idea to adopt vector with length for any loops.
>> For the main loop which used to be vectorized, it increases register
>> pressure and introduces extra computation for length, the pro for icache
>> seems not comparable.  But I think it might be a good idea to keep this
>> parameter there for functionality testing, further benchmarking and other
>> ports' potential future supports.
> 
> Can you explain in more detail what "vector load/store with length" does?
> Is that a "simplified" masked load/store which instead of masking 
> arbitrary elements (and need a mask computed in the first place), masks
> elements > N (the length operand)?  Thus assuming a lane IV decrementing
> to zero that IV would be the natural argument for the length operand?
> If that's correct, what data are the remaining lanes filled with?
> 

The vector load/store have one GPR holding one length in bytes (called as
n here) to control how many bytes we want to load/store.  If n > vector_size
(on Power it's 16), n will be taken as 16, if n is zero, the storage access
won't happen, the result for load is vector zero, if n > 0 but < vector_size,
the remaining lanes will be filled with zero.  On Power, it checks 0:7 bits
of the length GPR, so the length should be adjusted.

Your understanding is correct!  It's a "simplified" masked load/store, need
the length in bytes computed, only support continuous access.  For the lane
IV, the one should multiply with the lane bytes and be adjusted if needed.

> From a look at the series description below you seem to add a new way
> of doing loads for this.  Did you review other ISAs (those I'm not
> familiar with myself too much are SVE, RISC-V and GCN) in GCC whether
> they have similar support and whether your approach can be supported
> there?  ISTR SVE must have some similar support - what's the reason
> you do not piggy-back on that?

I may miss something, but I didn't find there is any support that meet with
this in GCC.  Good suggestion on ISAs, I didn't review other ISAs, for the
current implementation, I heavily referred to existing SVE fully predicated
loop support, it's stronger than "with length", it can deal with arbitrary
elements, only perform for the loop fully etc.

> 
> I think a load like I described above might be represented as
> 
> _1 = __VIEW_CONVERT  (__MEM  ((double *)p_3));
> 
> not sure if that actually works out though.  But given it seems it
> is a contiguous load we shouldn't need an internal function here?
> [there's a possible size mismatch in the __VIEW_CONVERT above, I guess
> on RTL you end up with a paradoxical subreg - or an UNSPEC]

IIUC, what you suggested is to avoid use IFN here.  May I know the reason?
is it due to the maintenance efforts on various IFNs?  I thought using
IFN is gentle.  And agreed, I had the concern that the size mismatch
problem here since the length can be large (extremely large probably, it
depends on target saturated limit), the converted vector size can be small.
Besides, the length can be a variable.
> 
> That said, I'm not very happy seeing yet another way of doing loads
> [for fully predicated loops].  I'd rather like to see a single
> representation on GIMPLE at least.

OK.  Does it mean IFN isn't counted into this scope?  :)

> 
> Will dig into the patch once the actual workings of those load/store with
> length is confirmed.

Thanks a lot for your time!

> 
> I don't spot tree-vect-slp.c being changed - maybe that's not necessary
> for SLP operation, but please do not introduce new vectorizer features
> without supporting SLP operation at this point.

Got it.  SLP is also one part to be supported, I forgot to state in the
original email.  I'll let it be for now.  :)

BR,
Kewen

gcc-patches@gcc.gnu.org

[Jonathan Wakely via Gcc-patches]

On 26/05/20 10:36 +0200, Christophe Lyon via Libstdc++ wrote:

Hi,


On Thu, 21 May 2020 at 02:07, Jonathan Wakely via Gcc-patches
 wrote:


On 21/05/20 01:01 +0100, Jonathan Wakely wrote:
>Also add some missing member functions, nodiscard attributes, and
>noexcept-specifiers.
>
>   * include/experimental/executor (use_future_t::use_future_t()): Fix
>   incorrect noexcept-specifier.
>   * include/experimental/internet (basic_resolver_results): Adjust
>   whitespace.
>   * include/experimental/socket (__basic_socket_impl::release): Add
>   member function.
>   (basic_socket(io_context&, const endpoint_type&)): Fix argument to
>   target constructor.
>   (basic_socket::release(), basic_socket::release(error_code&)): Add
>   missing member functions.
>   (basic_socket::is_open()): Add nodiscard attribute.
>   (basic_socket::close(error_code&)): Pass argument to base function.
>   (basic_socket_acceptor::release())
>   (basic_socket_acceptor::release(error_code&)): Add missing member
>   functions.
>   (basic_socket_acceptor::is_open()): Add nodiscard attribute.
>   (basic_socket_streambuf::error()): Add noexcept.
>   (basic_socket_iostream::error()): Likewise.
>   * testsuite/experimental/net/socket/basic_socket.cc: New test.



This new test fails to compile on newlib targets (aarch64-elf,
arm-eabi) because:
include/experimental/executor:509: error: 'mutex' in namespace 'std'
does not name a type
include/experimental/executor:556: error: 'mutex' is not a member of 'std'
[...]

I'm not sure what effective-target is needed here?


This is https://gcc.gnu.org/pipermail/libstdc++/2020-March/050186.html
again.

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

[Martin Liška]

On 5/26/20 10:52 AM, Richard Biener wrote:

Did you maybe install a wrong patch or miss some changes?


No, I see the same failures.

Martin

[PATCH] libatomic/test: correctly handle multilib in blddir

[CHIGOT, CLEMENT via Gcc-patches]

Hi, 

This patch fixes how the variable blddir is computed inside libatomic testsuite 
in order to ensure that the multilib arguments are taken into account. 

Note that I'm not sure why DejaGNU function "get_multilibs" can correctly 
retrieve the multilib directory in some configurations and won't with some 
others. Anyway, this patch seems a more logical approach to me. 

Changelog:
2020-05-26 Clement Chigot 
  * libatomic/testsuite/lib/libatomic.exp: pass $GCC_UNDER_TEST to
  get_multilibs


Please apply for me if approved.


0001-libatomic-test-correctly-handle-multilib-in-blddir.patch
Description: 0001-libatomic-test-correctly-handle-multilib-in-blddir.patch

Re: V4 [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

[Martin Liška]

On 5/25/20 7:42 PM, H.J. Lu wrote:

Here is the updated patch.  OK for master?


Thank you for the updated patch.

I have still few nits:

1) I would make all the:


+  has_sse3 = has_feature (FEATURE_SSE3);


a macro. The local variable seems to superfluous.

2) can we automatically deduce option name:


+  ISA_NAMES_TABLE_ENTRY("rdpid", FEATURE_RDPID, P_ZERO, "-mrdpid")
+  ISA_NAMES_TABLE_ENTRY("rdrnd", FEATURE_RDRND, P_ZERO, "-mrdrnd")


I mean "-m" + "rdrnd" == "-mrdrnd" ?

Martin

Re: [PATCH 0/7] Support vector load/store with length

[Richard Biener]

On Tue, 26 May 2020, Kewen.Lin wrote:

> Hi Richi,
> 
> on 2020/5/26 下午3:12, Richard Biener wrote:
> > On Tue, 26 May 2020, Kewen.Lin wrote:
> > 
> >> Hi all,
> >>
> >> This patch set adds support for vector load/store with length, Power 
> >> ISA 3.0 brings instructions lxvl/stxvl to perform vector load/store with
> >> length, it's good to be exploited for those cases we don't have enough
> >> stuffs to fill in the whole vector like epilogues.
> >>
> >> This support mainly refers to the handlings for fully-predicated loop
> >> but it also covers the epilogue usage.  Now it supports two modes
> >> controlled by parameter vect-with-length-scope, it can support any
> >> loops fully with length or just for those cases with small iteration
> >> counts less than VF like epilogue, for now I don't have ready env to
> >> benchmark it, but based on the current inefficient length generation,
> >> I don't think it's a good idea to adopt vector with length for any loops.
> >> For the main loop which used to be vectorized, it increases register
> >> pressure and introduces extra computation for length, the pro for icache
> >> seems not comparable.  But I think it might be a good idea to keep this
> >> parameter there for functionality testing, further benchmarking and other
> >> ports' potential future supports.
> > 
> > Can you explain in more detail what "vector load/store with length" does?
> > Is that a "simplified" masked load/store which instead of masking 
> > arbitrary elements (and need a mask computed in the first place), masks
> > elements > N (the length operand)?  Thus assuming a lane IV decrementing
> > to zero that IV would be the natural argument for the length operand?
> > If that's correct, what data are the remaining lanes filled with?
> > 
> 
> The vector load/store have one GPR holding one length in bytes (called as
> n here) to control how many bytes we want to load/store.  If n > vector_size
> (on Power it's 16), n will be taken as 16, if n is zero, the storage access
> won't happen, the result for load is vector zero, if n > 0 but < vector_size,
> the remaining lanes will be filled with zero.  On Power, it checks 0:7 bits
> of the length GPR, so the length should be adjusted.
> 
> Your understanding is correct!  It's a "simplified" masked load/store, need
> the length in bytes computed, only support continuous access.  For the lane
> IV, the one should multiply with the lane bytes and be adjusted if needed.
> 
> > From a look at the series description below you seem to add a new way
> > of doing loads for this.  Did you review other ISAs (those I'm not
> > familiar with myself too much are SVE, RISC-V and GCN) in GCC whether
> > they have similar support and whether your approach can be supported
> > there?  ISTR SVE must have some similar support - what's the reason
> > you do not piggy-back on that?
> 
> I may miss something, but I didn't find there is any support that meet with
> this in GCC.  Good suggestion on ISAs, I didn't review other ISAs, for the
> current implementation, I heavily referred to existing SVE fully predicated
> loop support, it's stronger than "with length", it can deal with arbitrary
> elements, only perform for the loop fully etc.
> 
> > 
> > I think a load like I described above might be represented as
> > 
> > _1 = __VIEW_CONVERT  (__MEM  ((double *)p_3));
> > 
> > not sure if that actually works out though.  But given it seems it
> > is a contiguous load we shouldn't need an internal function here?
> > [there's a possible size mismatch in the __VIEW_CONVERT above, I guess
> > on RTL you end up with a paradoxical subreg - or an UNSPEC]
> 
> IIUC, what you suggested is to avoid use IFN here.  May I know the reason?
> is it due to the maintenance efforts on various IFNs?  I thought using
> IFN is gentle.  And agreed, I had the concern that the size mismatch
> problem here since the length can be large (extremely large probably, it
> depends on target saturated limit), the converted vector size can be small.
> Besides, the length can be a variable.
>
> > 
> > That said, I'm not very happy seeing yet another way of doing loads
> > [for fully predicated loops].  I'd rather like to see a single
> > representation on GIMPLE at least.
> 
> OK.  Does it mean IFN isn't counted into this scope?  :)

Sure going with a new IFN is a possibility.  I'd just avoid that if
possible ;)  How does SVE represent loads/stores for whilelt loops?
Would it not be possible to share that representation somehow?

Richard.

> > 
> > Will dig into the patch once the actual workings of those load/store with
> > length is confirmed.
> 
> Thanks a lot for your time!
> 
> > 
> > I don't spot tree-vect-slp.c being changed - maybe that's not necessary
> > for SLP operation, but please do not introduce new vectorizer features
> > without supporting SLP operation at this point.
> 
> Got it.  SLP is also one part to be supported, I forgot to state in the
> original email.  I'll let it be for now.  :)
> 
> B

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

[Alexandre Oliva]

On May 26, 2020, Richard Biener  wrote:

> I'm seeing a lot of issues.

:-(

> First any LTO invocations end up with

> xgcc: error: unrecognized command-line option '-dumpbase'^M
> lto-wrapper: fatal error: /home/rguenther/obj/gcc/xgcc returned 1 exit 
> status^M
> compilation terminated.^M

> xg++: error: unrecognized command-line option '-dA'; did you mean '-A'

No luck duplicating these with my builds of gcc master :-(

(conversation on IRC)

Thanks for the binary, I've managed to duplicate the problem using your
binary.  Investigating...

-- 
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist  Stallman was right, but he's left :(
GNU Toolchain Engineer   Live long and free, and prosper ethically

Re: [PATCH 0/7] Support vector load/store with length

[Kewen.Lin via Gcc-patches]

on 2020/5/26 下午5:44, Richard Biener wrote:
> On Tue, 26 May 2020, Kewen.Lin wrote:
> 
>> Hi Richi,
>>
>> on 2020/5/26 下午3:12, Richard Biener wrote:
>>> On Tue, 26 May 2020, Kewen.Lin wrote:
>>>
 Hi all,

 This patch set adds support for vector load/store with length, Power 
 ISA 3.0 brings instructions lxvl/stxvl to perform vector load/store with
 length, it's good to be exploited for those cases we don't have enough
 stuffs to fill in the whole vector like epilogues.

 This support mainly refers to the handlings for fully-predicated loop
 but it also covers the epilogue usage.  Now it supports two modes
 controlled by parameter vect-with-length-scope, it can support any
 loops fully with length or just for those cases with small iteration
 counts less than VF like epilogue, for now I don't have ready env to
 benchmark it, but based on the current inefficient length generation,
 I don't think it's a good idea to adopt vector with length for any loops.
 For the main loop which used to be vectorized, it increases register
 pressure and introduces extra computation for length, the pro for icache
 seems not comparable.  But I think it might be a good idea to keep this
 parameter there for functionality testing, further benchmarking and other
 ports' potential future supports.
>>>
>>> Can you explain in more detail what "vector load/store with length" does?
>>> Is that a "simplified" masked load/store which instead of masking 
>>> arbitrary elements (and need a mask computed in the first place), masks
>>> elements > N (the length operand)?  Thus assuming a lane IV decrementing
>>> to zero that IV would be the natural argument for the length operand?
>>> If that's correct, what data are the remaining lanes filled with?
>>>
>>
>> The vector load/store have one GPR holding one length in bytes (called as
>> n here) to control how many bytes we want to load/store.  If n > vector_size
>> (on Power it's 16), n will be taken as 16, if n is zero, the storage access
>> won't happen, the result for load is vector zero, if n > 0 but < vector_size,
>> the remaining lanes will be filled with zero.  On Power, it checks 0:7 bits
>> of the length GPR, so the length should be adjusted.
>>
>> Your understanding is correct!  It's a "simplified" masked load/store, need
>> the length in bytes computed, only support continuous access.  For the lane
>> IV, the one should multiply with the lane bytes and be adjusted if needed.
>>
>>> From a look at the series description below you seem to add a new way
>>> of doing loads for this.  Did you review other ISAs (those I'm not
>>> familiar with myself too much are SVE, RISC-V and GCN) in GCC whether
>>> they have similar support and whether your approach can be supported
>>> there?  ISTR SVE must have some similar support - what's the reason
>>> you do not piggy-back on that?
>>
>> I may miss something, but I didn't find there is any support that meet with
>> this in GCC.  Good suggestion on ISAs, I didn't review other ISAs, for the
>> current implementation, I heavily referred to existing SVE fully predicated
>> loop support, it's stronger than "with length", it can deal with arbitrary
>> elements, only perform for the loop fully etc.
>>
>>>
>>> I think a load like I described above might be represented as
>>>
>>> _1 = __VIEW_CONVERT  (__MEM  ((double *)p_3));
>>>
>>> not sure if that actually works out though.  But given it seems it
>>> is a contiguous load we shouldn't need an internal function here?
>>> [there's a possible size mismatch in the __VIEW_CONVERT above, I guess
>>> on RTL you end up with a paradoxical subreg - or an UNSPEC]
>>
>> IIUC, what you suggested is to avoid use IFN here.  May I know the reason?
>> is it due to the maintenance efforts on various IFNs?  I thought using
>> IFN is gentle.  And agreed, I had the concern that the size mismatch
>> problem here since the length can be large (extremely large probably, it
>> depends on target saturated limit), the converted vector size can be small.
>> Besides, the length can be a variable.
>>
>>>
>>> That said, I'm not very happy seeing yet another way of doing loads
>>> [for fully predicated loops].  I'd rather like to see a single
>>> representation on GIMPLE at least.
>>
>> OK.  Does it mean IFN isn't counted into this scope?  :)
> 
> Sure going with a new IFN is a possibility.  I'd just avoid that if
> possible ;)  How does SVE represent loads/stores for whilelt loops?
> Would it not be possible to share that representation somehow?
> 
> Richard.
> 

Got it.  :) Currently SVE uses IFNs .MASK_LOAD and .MASK_STORE for 
whileult loops:

  vect__1.5_14 = .MASK_LOAD (_11, 4B, loop_mask_9);
  ...
  .MASK_STORE (_1, 4B, loop_mask_9, vect__3.9_18);
  ...
  next_mask_26 = .WHILE_ULT (_2, 127, { 0, ... });
  if (next_mask_26 != { 0, ... })

I thought to share it once, but didn't feel it's a good idea since it's
like we take something as masks that isn't ac

Re: [PR77691] x86-vxworks malloc aligns to 8 bytes like solaris

[Alexandre Oliva]

On May  9, 2020, Jonathan Wakely  wrote:

> Also approved for gcc-10 branch if the target maintainers are OK with
> it. It's an ABI change (allocations aligned to alignof(max_align_t)
> will store the token in the allocation after this change) but the
> header is an experimental TS feature so not guaranteed to be stable.
> The target maintainers can decide if they'd rather have GCC 10.2 be
> consistent with 10.1 or with master.

Olivier Hainque, with his vxworks maintainer hat on, gave me a go ahead
to install it the patch in the gcc-10 branch, so I'm putting it in.
Thanks,

-- 
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist  Stallman was right, but he's left :(
GNU Toolchain Engineer   Live long and free, and prosper ethically

[PATCH] Support --dry-mode in git_update_version.py.

[Martin Liška]

The patch improves the script based on Jakub's needs,
I'm going to install the patch.

contrib/ChangeLog:

* gcc-changelog/git_update_version.py: Add 2 new options.

contrib/ChangeLog:

* gcc-changelog/git_update_version.py:
---
 contrib/gcc-changelog/git_update_version.py | 43 +++--
 1 file changed, 31 insertions(+), 12 deletions(-)

diff --git a/contrib/gcc-changelog/git_update_version.py 
b/contrib/gcc-changelog/git_update_version.py
index ee3989beb27..3dcc5625eda 100755
--- a/contrib/gcc-changelog/git_update_version.py
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -31,7 +31,7 @@ def read_timestamp(path):
 return open(path).read()
 
 
-def prepend_to_changelog_files(repo, folder, git_commit):

+def prepend_to_changelog_files(repo, folder, git_commit, add_to_git):
 if not git_commit.success:
 for error in git_commit.errors:
 print(error)
@@ -48,7 +48,8 @@ def prepend_to_changelog_files(repo, folder, git_commit):
 if content:
 f.write('\n\n')
 f.write(content)
-repo.git.add(full_path)
+if add_to_git:
+repo.git.add(full_path)
 
 
 active_refs = ['master', 'releases/gcc-8', 'releases/gcc-9', 'releases/gcc-10']

@@ -57,6 +58,12 @@ parser = argparse.ArgumentParser(description='Update 
DATESTAMP and generate '
  'ChangeLog entries')
 parser.add_argument('-g', '--git-path', default='.',
 help='Path to git repository')
+parser.add_argument('-p', '--push', action='store_true',
+help='Push updated active branches')
+parser.add_argument('-d', '--dry-mode',
+help='Generate patch for ChangeLog entries and do it'
+ ' even if DATESTAMP is unchanged; folder argument'
+ ' is expected')
 args = parser.parse_args()
 
 repo = Repo(args.git_path)

@@ -86,19 +93,31 @@ for ref in origin.refs:
 
 print('%d revisions since last Daily bump' % commit_count)

 datestamp_path = os.path.join(args.git_path, 'gcc/DATESTAMP')
-if read_timestamp(datestamp_path) != current_timestamp:
-print('DATESTAMP will be changed:')
+if (read_timestamp(datestamp_path) != current_timestamp
+or args.dry_mode):
 commits = parse_git_revisions(args.git_path, '%s..HEAD'
   % commit.hexsha)
 for git_commit in reversed(commits):
-prepend_to_changelog_files(repo, args.git_path, git_commit)
-# update timestamp
-with open(datestamp_path, 'w+') as f:
-f.write(current_timestamp)
-repo.git.add(datestamp_path)
-repo.index.commit('Daily bump.')
-# TODO: push the repository
-# repo.git.push('origin', branch)
+prepend_to_changelog_files(repo, args.git_path, git_commit,
+   not args.dry_mode)
+if args.dry_mode:
+diff = repo.git.diff('HEAD')
+patch = os.path.join(args.dry_mode,
+ branch.name.split('/')[-1] + '.patch')
+with open(patch, 'w+') as f:
+f.write(diff)
+print('branch diff written to %s' % patch)
+repo.git.checkout(force=True)
+else:
+# update timestamp
+print('DATESTAMP will be changed:')
+with open(datestamp_path, 'w+') as f:
+f.write(current_timestamp)
+repo.git.add(datestamp_path)
+repo.index.commit('Daily bump.')
+if args.push:
+repo.git.push('origin', branch)
+print('branch is pushed')
 else:
 print('DATESTAMP unchanged')
 print('branch is done\n', flush=True)
--
2.26.2

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

[Richard Sandiford]

Richard Biener  writes:
> On Thu, May 21, 2020 at 10:17 PM Segher Boessenkool
>  wrote:
>>
>> Hi!
>>
>> On Thu, May 21, 2020 at 03:29:49PM +0200, Martin Liška wrote:
>> > Adding Segher to CC, he can help us.
>>
>> Oh dear.  Are you sure?
>>
>> > On 5/21/20 2:51 PM, Martin Liška wrote:
>> > >Back to this I noticed that ppc64le target build is broken due to:
>>
>> > >insn-emit.o -MMD -MP -MF ./.deps/insn-emit.TPo insn-emit.c
>> > >/home/marxin/Programming/gcc/gcc/config/rs6000/vector.md:357:11: error:
>> > >vcondv4sfv4sf cannot FAIL
>> > >   357 | FAIL;
>>
>> Is it new that vcond cannot FAIL?  Because we have done that for years.
>>
>> Since this breaks bootstrap on a primary target, please revert the patch
>> until it is sorted.
>>
>> > >which is caused by the 4 added optabs:
>> > >
>> > >+DEF_INTERNAL_OPTAB_FN (VCOND, 0, vcond, vec_cond)
>> > >+DEF_INTERNAL_OPTAB_FN (VCONDU, 0, vcondu, vec_condu)
>> > >+DEF_INTERNAL_OPTAB_FN (VCONDEQ, 0, vcondeq, vec_condeq)
>> > >+DEF_INTERNAL_OPTAB_FN (VCOND_MASK, 0, vcond_mask, vec_cond_mask)
>>
>> > >looking at the generator:
>>
>> > >I get there due to:
>> > >
>> > >B- │516   if (find_optab (&p, XSTR (expand,
>> > >0)))│
>> > >│517
>> > > {   │
>> > >│518   gcc_assert (p.op <
>> > > NUM_OPTABS);   │
>> > >│519   if
>> > > (nofail_optabs[p.op])  │
>> > >│520 can_fail_p =
>> > > false; │
>> > >│521
>> > > }   │
>
> OK, so this is an "artifact" of direct internal functions.  We do check that
> expansion does not actually FAIL before emitting calls to those IFNs.
>
> I guess this simply makes direct internal functions not a 100% match for
> our use and the way out is to add regular internal functions mapping to
> the optabs.  That is, I guess, for direct-internal functions it should be
> enough to check direct_internal_function_supported_p which it is not
> for the case of vcond*.
>
> Richard, do you agree?

Sorry for the late reply, been off for a few days.

I guess that would be OK for VCOND(U) as an intermediate step,
but long term, I think we should try to make all VCOND* directly-mapped.
If we're doing instruction selection on gimple (a good thing IMO)
we need to know before expand whether an operation is supported.

So longer-term, I think we should replace VCOND(U) with individual ifns,
like for VCONDEQ.  We could reduce the number of optabs needed by
canonicalising greater-based tests to lesser-based tests.

Thanks,
Richard

Re: New mklog script

[Richard Earnshaw]

On 25/05/2020 20:41, Jason Merrill via Gcc-patches wrote:
> On Mon, May 25, 2020 at 5:23 AM Martin Liška  wrote:
>>
>> On 5/22/20 11:01 PM, Jason Merrill wrote:
>>> On Thu, May 21, 2020 at 6:03 PM Jason Merrill  wrote:

 On Fri, May 15, 2020 at 11:39 AM Martin Liška  wrote:
>
> On 5/15/20 3:22 PM, Marek Polacek wrote:
>> On Fri, May 15, 2020 at 03:12:27PM +0200, Martin Liška wrote:
>>> On 5/15/20 2:42 PM, Marek Polacek wrote:
 I actually use mklog -i all the time.  But I can work around it if it
 disappears.
>>>
>>> Ah, I can see a consumer.
>>> There's an updated version that supports that.
>>>
>>> For the future, will you still use the option? Wouldn't be better
>>> to put the ChangeLog content directly to commit message? Note
>>> that you won't have to copy the entries to a particular ChangeLog file.
>>
>> The way I do it is to generate a patch using format-patch, use mklog -i
>> on it, then add the ChangeLog entry to the commit message via commit 
>> --amend.
>
> Hmm, you can do much better with:
>
> $ git diff | ./contrib/mklog > changelog && git commit -a -t changelog
>
> Or for an already created commit you can do:
>
> $ git diff HEAD~ | ./contrib/mklog > changelog && git commit -a --amend 
> -e -F changelog

 With these git aliases:

  mklog-editor = "!f() { git show | git gcc-mklog >> $1; }; f"
  addlog = "!f() { GIT_EDITOR='git mklog-editor' git commit 
 --amend; }; f"

 I can 'git addlog' to append the output of mklog to the current
 commit.  Probably better would be to do something with
 prepare-commit-msg.
>>>
>>> This is pretty rudimentary, but good enough as a start:
>>
>> I like the idea of usage of the prepare commit hook.
>>
>>>
>>> #!/bin/sh
>>>
>>> #COMMIT_MSG_FILE=$1
>>> #COMMIT_SOURCE=$2
>>> #SHA1=$3
>>
>> It's better to use the named arguments.
>>
>>>
>>> if ! [ -f "$1" ]; then exit 0; fi
>>>
>>> #echo "# $0 $1 $2 $3" >> $1
>>>
>>> if fgrep 'ChangeLog:' $1 > /dev/null 2>&1; then exit 0; fi
>>>
>>> if [ -z "$2" ]; then
>>>  cmd="diff --cached"
>>> elif [ $2 == commit ]; then
>>>  cmd="show $3"
>>> else
>>>  exit 0
>>> fi
>>>
>>> git $cmd | git gcc-mklog >> $1
>>>
>>
>> Well, that will generate changelog entry for each commit.
>> For a user branch development, it's not desirable.
> 
> It isn't that useful for intermediate commits, but I was thinking it
> wasn't harmful either.  But I can remove the on-by-default aspects.
> 
>> What about more explicit approach:
>>
>> 1) making an alias for: git diff | git gcc-mklog > commit.msg
>> 2) hook:
>>
>> if test -f commit.msg; then
>>cat commit.msg >> "$COMMIT_MSG_FILE"
>>rm commit.msg
>> fi
>>
>> So the changelog is created explicitly and included implicitly.
> 
> How about this?
> 

> +git config alias.commit-mklog '!f() { GCC_FORCE_MKLOG=1 git commit
"$@"; }; f'
> +

I thought we had a convention that aliases we added were prefixed with
'gcc-'?  This seems to go against that.

R.

Re: New mklog script

[Martin Liška]

On 5/26/20 12:23 PM, Richard Earnshaw wrote:

I thought we had a convention that aliases we added were prefixed with
'gcc-'?  This seems to go against that.


You are right, but this one is so handy ;)
What name do you suggest?

Martin

Re: New mklog script

[Richard Earnshaw]

On 26/05/2020 12:14, Martin Liška wrote:
> On 5/26/20 12:23 PM, Richard Earnshaw wrote:
>> I thought we had a convention that aliases we added were prefixed with
>> 'gcc-'?  This seems to go against that.
> 
> You are right, but this one is so handy ;)
> What name do you suggest?
> 
> Martin

gcc-ci?

R.

Re: [PR77691] x86-vxworks malloc aligns to 8 bytes like solaris

[Jonathan Wakely via Gcc-patches]

On 26/05/20 07:11 -0300, Alexandre Oliva wrote:

On May  9, 2020, Jonathan Wakely  wrote:


Also approved for gcc-10 branch if the target maintainers are OK with
it. It's an ABI change (allocations aligned to alignof(max_align_t)
will store the token in the allocation after this change) but the
header is an experimental TS feature so not guaranteed to be stable.
The target maintainers can decide if they'd rather have GCC 10.2 be
consistent with 10.1 or with master.


Olivier Hainque, with his vxworks maintainer hat on, gave me a go ahead
to install it the patch in the gcc-10 branch, so I'm putting it in.


Great. Thanks, Alex.

[Patch, fortran] PR fortran/52351, 85868 Wrong array section bounds when passing to an intent-in pointer dummy

[José Rui Faustino de Sousa via Gcc-patches]

Hi all!

Proposed patch to PRs 52351, 85868 Wrong array section bounds when 
passing to an intent-in pointer dummy.


Patch tested only on x86_64-pc-linux-gnu.

Add code to allow for the creation a new descriptor for array sections 
with the correct one based indexing.


Rework the generated descriptors indexing (hopefully) fixing the wrong 
offsets generated.


Thank you very much.

Best regards,
José Rui


2020-5-25  José Rui Faustino de Sousa  

 PR fortran/85868
 * trans-array.c (gfc_conv_expr_descriptor) Enable the creation of a new
 descriptor with the correct one based indexing for array sections.
 Rework array descriptor indexing offset calculation.

2020-5-25  José Rui Faustino de Sousa  

 PR fortran/85868
 * PR85868A.f90: New test.

2020-5-25  José Rui Faustino de Sousa  

 PR fortran/85868
 * PR85868B.f90: New test.

2020-5-25  José Rui Faustino de Sousa  

 PR fortran/85868
 * coarray_lib_comm_1.f90: Adjust match test for the newly generated
 descriptor.

diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 434960c..ef20989 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -7201,7 +7201,6 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
   tree desc;
   stmtblock_t block;
   tree start;
-  tree offset;
   int full;
   bool subref_array_target = false;
   bool deferred_array_component = false;
@@ -7271,7 +7270,11 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
   else if (info->ref->u.ar.type == AR_FULL || se->descriptor_only)
full = 1;
   else if (se->direct_byref)
-   full = 0;
+   full = 0;
+  else if (info->ref->u.ar.dimen == 0 && !info->ref->next)
+   full = 1;
+  else if (info->ref->u.ar.type == AR_SECTION && se->want_pointer)
+   full = 0;
   else
full = gfc_full_array_ref_p (info->ref, NULL);
 
@@ -7508,10 +7511,9 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
   tree from;
   tree to;
   tree base;
-  bool onebased = false, rank_remap;
+  tree offset;
 
   ndim = info->ref ? info->ref->u.ar.dimen : ss->dimen;
-  rank_remap = ss->dimen < ndim;
 
   if (se->want_coarray)
{
@@ -7555,10 +7557,10 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
gfc_add_modify (&se->pre, expr->ts.u.cl->backend_decl, tmp);
}
 
-  /* If we have an array section or are assigning make sure that
-the lower bound is 1.  References to the full
-array should otherwise keep the original bounds.  */
-  if ((!info->ref || info->ref->u.ar.type != AR_FULL) && !se->want_pointer)
+  /* If we have an array section, are assigning  or passing an array 
+section argument make sure that the lower bound is 1.  References
+to the full array should otherwise keep the original bounds.  */
+  if (!info->ref || info->ref->u.ar.type != AR_FULL)
for (dim = 0; dim < loop.dimen; dim++)
  if (!integer_onep (loop.from[dim]))
{
@@ -7622,8 +7624,6 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
   if (tmp != NULL_TREE)
gfc_conv_descriptor_span_set (&loop.pre, parm, tmp);
 
-  offset = gfc_index_zero_node;
-
   /* The following can be somewhat confusing.  We have two
  descriptors, a new one and the original array.
  {parm, parmtype, dim} refer to the new one.
@@ -7637,22 +7637,17 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
   tmp = gfc_conv_descriptor_dtype (parm);
   gfc_add_modify (&loop.pre, tmp, gfc_get_dtype (parmtype));
 
-  /* Set offset for assignments to pointer only to zero if it is not
- the full array.  */
-  if ((se->direct_byref || se->use_offset)
- && ((info->ref && info->ref->u.ar.type != AR_FULL)
- || (expr->expr_type == EXPR_ARRAY && se->use_offset)))
-   base = gfc_index_zero_node;
-  else if (GFC_ARRAY_TYPE_P (TREE_TYPE (desc)))
-   base = gfc_evaluate_now (gfc_conv_array_offset (desc), &loop.pre);
-  else
-   base = NULL_TREE;
+  /* The 1st element in the section.  */
+  base = gfc_index_zero_node;
+  
+  /* The offset from the 1st element in the section.  */
+  offset = gfc_index_zero_node;
 
   for (n = 0; n < ndim; n++)
{
  stride = gfc_conv_array_stride (desc, n);
 
- /* Work out the offset.  */
+ /* Work out the 1st element in the section.  */
  if (info->ref
  && info->ref->u.ar.dimen_type[n] == DIMEN_ELEMENT)
{
@@ -7672,13 +7667,14 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
 start, tmp);
  tmp = fold_build2_loc (input_location, MULT_EXPR, TREE_TYPE (tmp),
 tmp, stride);
- offset = fold_build2_loc (input_location, PLUS_EXPR, TREE_TYPE (tmp),
-   offset, tmp);
+ base = fold_build2_loc (input_location, PLUS_EXPR, TRE

Re: [PATCH v1 1/2][PPC64] [PR88877]

[Richard Sandiford]

Thanks for working on this.

Kamlesh Kumar via Gcc-patches  writes:
> Here is a discussion we did some time ago regarding the defect.
> https://gcc.gnu.org/pipermail/gcc/2019-January/227834.html
> please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877 for testcase
> behavior.
>
> We incorporating below Jakub's suggestion in this patch series.
>
> Jakub wrote:
> ""
> Yeah, all the callers of emit_library_call* would need to be changed to pass
> triplets rtx, machine_mode, int/bool /*unsignedp*/, instead of just
> rtx_mode_t pair.
> ""
>
>
> In this patch series trying to address same by creating a struct Tuple
> which bundles existing rtx and machine_mode and added one more
> bool member which store unsigned_p which by default is false.
> This patch does not change underlying behavior yet. This will be done in
> follow up patches.
>
> ChangeLog Entry:
>
> 2020-05-24 Kamlesh Kumar 
>
> * rtl.h (Tuple): Defined and typedefed to rtx_mode_t.
> (emit_library_call): Added default arg unsigned_p.
> (emit_library_call_value): Added default arg unsigned_p.
> ---
>  gcc/rtl.h | 26 ++
>  1 file changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/gcc/rtl.h b/gcc/rtl.h
> index b0b1aac..ee42de7 100644
> --- a/gcc/rtl.h
> +++ b/gcc/rtl.h
> @@ -2238,10 +2238,20 @@ struct address_info {
>enum rtx_code base_outer_code;
>  };
>  
> -/* This is used to bundle an rtx and a mode together so that the pair
> -   can be used with the wi:: routines.  If we ever put modes into rtx
> -   integer constants, this should go away and then just pass an rtx in.  */
> -typedef std::pair  rtx_mode_t;
> +/* This is used to bundle an rtx and a mode and unsignedness together so
> +   that the tuple can be used with the wi:: routines.  If we ever put modes
> +   into rtx integer constants, this should go away and then just pass an rtx 
> in.  */
> +typedef struct Tuple {
> +  rtx first;
> +  machine_mode second;
> +  /* unsigned_p  */
> +  bool third;
> +  Tuple (rtx f, machine_mode s, bool t = false) {
> +first = f;
> +second = s;
> +third = t;
> +  }
> +} rtx_mode_t;
>  

I think rtx_mode_t should continue to be what it is now: an rtx
and a mode only.  That's all that most rtl code cares about, since
in rtl signedness is a property of an operation (where necessary)
instead of an operand.

(FWIW, the type was originally added to enable wide-int operators
to be applied to rtx constants, to get around the fact that CONST_INT
& co. don't store a mode.  We should continue not to have signedness
information in that situation.)

I think instead we should make emit_library_call operate on a new and
differently-named type that contains the three pieces of information.

Thanks,
Richard

Re: [PATCH] Extend std::copy/std::copy_n char* overload to deque iterator

[François Dumont via Gcc-patches]

On 24/05/20 3:43 pm, François Dumont wrote:

Now tested in C++98 mode, there was indeed a small problem.

I even wonder if I shouldn't have extend the std::copy overload to any 
call with deque iterator as the output so that it is transform into an 
output to pointer.



Ignore this remark, I had a look and we already have an overload that 
does that. It is limited to RA iterators and is just fine.





Ok to commit ?

François

On 23/05/20 6:37 pm, Jonathan Wakely wrote:

On 22/05/20 22:57 +0200, François Dumont via Libstdc++ wrote:

On 21/05/20 2:17 pm, Jonathan Wakely wrote:


Why is the optimization not done for C++03 mode?

I did it this way because the new std::copy overload rely on 
std::copy_n implementation details which is a C++11 algo.




It looks like the uses of 'auto' can be reaplced easily, and
__enable_if_t<> can be replaced with __gnu_cxx::__enable_if<>::__type.

But yes, we can indeed provide those implementation details in 
pre-C++11.


This is what I've done in this new version.

Tested under Linux x86_64 in default c++ mode.

I tried to use CXXFLAGS=-std=c++03 but it doesn't seem to work even 
if I do see the option in build logs. I remember you adivised a 
different approach, can you tell me again ?


See the documentation:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html#test.run.permutations 

V5 [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

[H.J. Lu via Gcc-patches]

On Tue, May 26, 2020 at 2:30 AM Martin Liška  wrote:
>
> On 5/25/20 7:42 PM, H.J. Lu wrote:
> > Here is the updated patch.  OK for master?
>
> Thank you for the updated patch.
>
> I have still few nits:
>
> 1) I would make all the:
>
> > +  has_sse3 = has_feature (FEATURE_SSE3);
>
> a macro. The local variable seems to superfluous.

Done.

> 2) can we automatically deduce option name:
>
> > +  ISA_NAMES_TABLE_ENTRY("rdpid", FEATURE_RDPID, P_ZERO, "-mrdpid")
> > +  ISA_NAMES_TABLE_ENTRY("rdrnd", FEATURE_RDRND, P_ZERO, "-mrdrnd")
>
> I mean "-m" + "rdrnd" == "-mrdrnd" ?

The new option field serves 2 purposes:

1. Not all features have a corresponding command-line option

ISA_NAMES_TABLE_ENTRY("cmov", FEATURE_CMOV, P_ZERO, NULL)

 for (i = 0; i < ARRAY_SIZE (isa_names_table); i++)
if (isa_names_table[i].option)

2. Some feature has a different name in the command-line option.

  ISA_NAMES_TABLE_ENTRY("fxsave", FEATURE_FXSAVE, P_ZERO, "-mfxsr")

Here is the updated patch.   OK for master?

Thanks.

-- 
H.J.
From 48a429a02c91937ba2a4bd37f42304c2ce59bb28 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Mon, 18 May 2020 05:58:41 -0700
Subject: [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

Move cpuinfo.h from libgcc to common/config/i386 and move isa_names_table
to common/config/i386 so that get_intel_cpu can be shared by libgcc, GCC
driver and gcc.target/i386/builtin_target.c to detect the specific type
of Intel and AMD CPUs:

1. Use the same enum processor_features in libgcc and x86 backend.
2. Add more processor features to enum processor_features.
3. Use the same isa_names_table in i386-builtins.c, driver-i386.c and
gcc.target/i386/builtin_target.c.
4. Use isa_names_table to generate ISA command-line options.
5. Use isa_names_table to generate __builtin_cpu_supports tests.
6. Add M_VENDOR, M_CPU_TYPE and M_CPU_SUBTYPE in i386-builtins.c to
avoid duplication in.
7. Use cpu_indicator_init, has_cpu_feature, get_amd_cpu and get_intel_cpu
in driver-i386.c and builtin_target.c.

gcc/

	PR target/95259
	* common/config/i386/cpuinfo-builtins.h: Moved from
	libgcc/config/i386/cpuinfo.h.
	(processor_vendor): Add VENDOR_CENTAUR, VENDOR_CYRIX, VENDOR_NSC
	and BUILTIN_VENDOR_MAX.
	(processor_types): Add BUILTIN_CPU_TYPE_MAX.
	(processor_features): Add FEATURE_3DNOW, FEATURE_3DNOWP,
	FEATURE_ADX, FEATURE_ABM, FEATURE_CLDEMOTE, FEATURE_CLFLUSHOPT,
	FEATURE_CLWB, FEATURE_CLZERO, FEATURE_CMPXCHG16B,
	FEATURE_CMPXCHG8B, FEATURE_ENQCMD, FEATURE_F16C,
	FEATURE_FSGSBASE, FEATURE_FXSAVE, FEATURE_HLE, FEATURE_IBT,
	FEATURE_LAHF_LM, FEATURE_LM, FEATURE_LWP, FEATURE_LZCNT,
	FEATURE_MOVBE, FEATURE_MOVDIR64B, FEATURE_MOVDIRI,
	FEATURE_MWAITX, FEATURE_OSPKE, FEATURE_OSXSAVE, FEATURE_PCONFIG,
	FEATURE_PKU, FEATURE_PREFETCHWT1, FEATURE_PRFCHW,
	FEATURE_PTWRITE, FEATURE_RDPID, FEATURE_RDRND, FEATURE_RDSEED,
	FEATURE_RTM, FEATURE_SERIALIZE, FEATURE_SGX, FEATURE_SHA,
	FEATURE_SHSTK, FEATURE_TBM, FEATURE_TSXLDTRK, FEATURE_VAES,
	FEATURE_WAITPKG, FEATURE_WBNOINVD, FEATURE_XSAVE, FEATURE_XSAVEC,
	FEATURE_XSAVEOPT, FEATURE_XSAVES and CPU_FEATURE_MAX.
	(__processor_model): Moved to cpuinfo.h.
	(__cpu_model): Removed.
	(__cpu_features2): Likewise.
	(SIZE_OF_CPU_FEATURES): New.
	* common/config/i386/cpuinfo.h: Moved from
	libgcc/config/i386/cpuinfo.c.
	(__processor_model): Moved from libgcc/config/i386/cpuinfo.h.
	(__processor_model2): New.
	(CHECK___builtin_cpu_is): New.  Defined as empty if not defined.
	(has_cpu_feature): New function.
	(set_cpu_feature): Likewise.
	(get_amd_cpu): Moved from libgcc/config/i386/cpuinfo.c.  Use
	CHECK___builtin_cpu_is.  Return AMD CPU name.
	(get_intel_cpu): Moved from libgcc/config/i386/cpuinfo.c.  Use
	Use CHECK___builtin_cpu_is.  Return Intel CPU name.
	(get_available_features): Moved from libgcc/config/i386/cpuinfo.c.
	Also check FEATURE_3DNOW, FEATURE_3DNOWP, FEATURE_ADX,
	FEATURE_ABM, FEATURE_CLDEMOTE, FEATURE_CLFLUSHOPT, FEATURE_CLWB,
	FEATURE_CLZERO, FEATURE_CMPXCHG16B, FEATURE_CMPXCHG8B,
	FEATURE_ENQCMD, FEATURE_F16C, FEATURE_FSGSBASE, FEATURE_FXSAVE,
	FEATURE_HLE, FEATURE_IBT, FEATURE_LAHF_LM, FEATURE_LM,
	FEATURE_LWP, FEATURE_LZCNT, FEATURE_MOVBE, FEATURE_MOVDIR64B,
	FEATURE_MOVDIRI, FEATURE_MWAITX, FEATURE_OSPKE, FEATURE_OSXSAVE,
	FEATURE_PCONFIG, FEATURE_PKU, FEATURE_PREFETCHWT1, FEATURE_PRFCHW,
	FEATURE_PTWRITE, FEATURE_RDPID, FEATURE_RDRND, FEATURE_RDSEED,
	FEATURE_RTM, FEATURE_SERIALIZE, FEATURE_SGX, FEATURE_SHA,
	FEATURE_SHSTK, FEATURE_TBM, FEATURE_TSXLDTRK, FEATURE_VAES,
	FEATURE_WAITPKG, FEATURE_WBNOINVD, FEATURE_XSAVE, FEATURE_XSAVEC,
	FEATURE_XSAVEOPT and FEATURE_XSAVES
	(cpu_indicator_init): Moved from libgcc/config/i386/cpuinfo.c.
	Also update cpu_model2.
	* common/config/i386/i386-isas.h: New file.  Extracted from
	gcc/config/i386/i386-builtins.c.
	(_isa_names_table): Add option.
	(ISA_NAMES_TABLE_START): New.
	(ISA_NAMES_TABLE_END): Likewise.
	(ISA_NAMES_TABLE_ENTRY): Likewise.
	(isa_names_table): Defined with ISA_NAMES_TABLE_START,
	ISA_NAMES_TABLE_END and ISA_

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

[Alexandre Oliva]

On May 26, 2020, Richard Biener  wrote:

> All visible by testing on x86_64-linux.

Interesting bug.  You wouldn't have hit it if you enabled Ada.  That's
because I'd missed the %< directives that validate_switches mishandled
in the Ada specs, so validate_switches handled the %{d*} and validated
-dA, -dumpbase, and any other option starting with -d.

Without those Ada specs, they wouldn't be validated, and we'd end up
reporting them as unrecognized.


So we have two bugs:

1. the Ada specs should have included %


---
 gcc/ada/gcc-interface/lang-specs.h |8 +---
 gcc/gcc.c  |   22 +++---
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/gcc/ada/gcc-interface/lang-specs.h 
b/gcc/ada/gcc-interface/lang-specs.h
index 12b7cf5e..b72ab29 100644
--- a/gcc/ada/gcc-interface/lang-specs.h
+++ b/gcc/ada/gcc-interface/lang-specs.h
@@ -23,6 +23,8 @@
  *  *
  /
 
+#define ADA_DUMPS_OPTIONS DUMPS_OPTIONS ("%{!.adb:%{!.ads:.ada}}")
+
 /* This is the contribution to the `default_compilers' array in gcc.c for
GNAT.  */
 
@@ -35,7 +37,7 @@
  gnat1 %{I*} %{k8:-gnatk8} %{Wall:-gnatwa} %{w:-gnatws} %{!Q:-quiet}\
 %{nostdinc*} %{nostdlib*}\
 %{fcompare-debug-second:-gnatd_A} \
-%{O*} %{W*} %{w} %{p} %{pg:-p} %{d*} %:dumps(%{!.adb:%{!.ads:.ada}}) \
+%{O*} %{W*} %{w} %{p} %{pg:-p} " ADA_DUMPS_OPTIONS " \
 %{coverage:-fprofile-arcs -ftest-coverage} "
 #if defined(TARGET_VXWORKS_RTP)
"%{fRTS=rtp|fRTS=rtp-smp|fRTS=ravenscar-cert-rtp:-mrtp} "
@@ -51,7 +53,7 @@
  %{!c:%e-c required for gnat2why}\
  gnat1why %{I*} %{k8:-gnatk8} %{!Q:-quiet}\
 %{nostdinc*} %{nostdlib*}\
-%{a} %{d*} %:dumps(%{!.adb:%{!.ads:.ada}}) \
+%{a} " ADA_DUMPS_OPTIONS " \
 %{gnatea:-gnatez} %{g*&m*&f*} \
 %1 %{o*:%w%*-gnatO} \
 %i \
@@ -62,7 +64,7 @@
  %{!c:%e-c required for gnat2scil}\
  gnat1scil %{I*} %{k8:-gnatk8} %{!Q:-quiet}\
 %{nostdinc*} %{nostdlib*}\
-%{a} %{d*} %:dumps(%{!.adb:%{!.ads:.ada}}) \
+%{a} " ADA_DUMPS_OPTIONS " \
 %{gnatea:-gnatez} %{g*&m*&f*} \
 %1 %{o*:%w%*-gnatO} \
 %i \
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 8c851d7..49b7020 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -388,7 +388,7 @@ static void do_option_spec (const char *, const char *);
 static void do_self_spec (const char *);
 static const char *find_file (const char *);
 static int is_directory (const char *, bool);
-static const char *validate_switches (const char *, bool);
+static const char *validate_switches (const char *, bool, bool);
 static void validate_all_switches (void);
 static inline void validate_switches_from_spec (const char *, bool);
 static void give_switch (int, int);
@@ -1176,9 +1176,14 @@ static const char *cpp_options =
  %{!fno-working-directory:-fworking-directory}}} %{O*}\
  %{undef} %{save-temps*:-fpch-preprocess}";
 
+/* Make it easy for Ada to override the arguments for the %:dumps
+   specs function call.  */
+#define DUMPS_OPTIONS(EXTS) \
+  "%https://FSFLA.org/blogs/lxo/
Free Software Evangelist  Stallman was right, but he's left :(
GNU Toolchain Engineer   Live long and free, and prosper ethically

Re: [PATCH 0/7] Support vector load/store with length

[Richard Sandiford]

"Kewen.Lin"  writes:
> on 2020/5/26 下午5:44, Richard Biener wrote:
>> On Tue, 26 May 2020, Kewen.Lin wrote:
>> 
>>> Hi Richi,
>>>
>>> on 2020/5/26 下午3:12, Richard Biener wrote:
 On Tue, 26 May 2020, Kewen.Lin wrote:

> Hi all,
>
> This patch set adds support for vector load/store with length, Power 
> ISA 3.0 brings instructions lxvl/stxvl to perform vector load/store with
> length, it's good to be exploited for those cases we don't have enough
> stuffs to fill in the whole vector like epilogues.
>
> This support mainly refers to the handlings for fully-predicated loop
> but it also covers the epilogue usage.  Now it supports two modes
> controlled by parameter vect-with-length-scope, it can support any
> loops fully with length or just for those cases with small iteration
> counts less than VF like epilogue, for now I don't have ready env to
> benchmark it, but based on the current inefficient length generation,
> I don't think it's a good idea to adopt vector with length for any loops.
> For the main loop which used to be vectorized, it increases register
> pressure and introduces extra computation for length, the pro for icache
> seems not comparable.  But I think it might be a good idea to keep this
> parameter there for functionality testing, further benchmarking and other
> ports' potential future supports.

 Can you explain in more detail what "vector load/store with length" does?
 Is that a "simplified" masked load/store which instead of masking 
 arbitrary elements (and need a mask computed in the first place), masks
 elements > N (the length operand)?  Thus assuming a lane IV decrementing
 to zero that IV would be the natural argument for the length operand?
 If that's correct, what data are the remaining lanes filled with?

>>>
>>> The vector load/store have one GPR holding one length in bytes (called as
>>> n here) to control how many bytes we want to load/store.  If n > vector_size
>>> (on Power it's 16), n will be taken as 16, if n is zero, the storage access
>>> won't happen, the result for load is vector zero, if n > 0 but < 
>>> vector_size,
>>> the remaining lanes will be filled with zero.  On Power, it checks 0:7 bits
>>> of the length GPR, so the length should be adjusted.
>>>
>>> Your understanding is correct!  It's a "simplified" masked load/store, need
>>> the length in bytes computed, only support continuous access.  For the lane
>>> IV, the one should multiply with the lane bytes and be adjusted if needed.
>>>
 From a look at the series description below you seem to add a new way
 of doing loads for this.  Did you review other ISAs (those I'm not
 familiar with myself too much are SVE, RISC-V and GCN) in GCC whether
 they have similar support and whether your approach can be supported
 there?  ISTR SVE must have some similar support - what's the reason
 you do not piggy-back on that?
>>>
>>> I may miss something, but I didn't find there is any support that meet with
>>> this in GCC.  Good suggestion on ISAs, I didn't review other ISAs, for the
>>> current implementation, I heavily referred to existing SVE fully predicated
>>> loop support, it's stronger than "with length", it can deal with arbitrary
>>> elements, only perform for the loop fully etc.
>>>

 I think a load like I described above might be represented as

 _1 = __VIEW_CONVERT  (__MEM  ((double *)p_3));

 not sure if that actually works out though.  But given it seems it
 is a contiguous load we shouldn't need an internal function here?
 [there's a possible size mismatch in the __VIEW_CONVERT above, I guess
 on RTL you end up with a paradoxical subreg - or an UNSPEC]
>>>
>>> IIUC, what you suggested is to avoid use IFN here.  May I know the reason?
>>> is it due to the maintenance efforts on various IFNs?  I thought using
>>> IFN is gentle.  And agreed, I had the concern that the size mismatch
>>> problem here since the length can be large (extremely large probably, it
>>> depends on target saturated limit), the converted vector size can be small.
>>> Besides, the length can be a variable.
>>>

 That said, I'm not very happy seeing yet another way of doing loads
 [for fully predicated loops].  I'd rather like to see a single
 representation on GIMPLE at least.
>>>
>>> OK.  Does it mean IFN isn't counted into this scope?  :)
>> 
>> Sure going with a new IFN is a possibility.  I'd just avoid that if
>> possible ;)  How does SVE represent loads/stores for whilelt loops?
>> Would it not be possible to share that representation somehow?
>> 
>> Richard.
>> 
>
> Got it.  :) Currently SVE uses IFNs .MASK_LOAD and .MASK_STORE for 
> whileult loops:
>
>   vect__1.5_14 = .MASK_LOAD (_11, 4B, loop_mask_9);
>   ...
>   .MASK_STORE (_1, 4B, loop_mask_9, vect__3.9_18);
>   ...
>   next_mask_26 = .WHILE_ULT (_2, 127, { 0, ... });
>   if (next_mask_2

[pushed] coroutines, testsuite: Fix co-ret-17-void-ret-coro.C.

[Iain Sandoe]

Hi

This was a bad testcase, found with fsanitize=address; the final suspend
is 'suspend never' which flows off the end of the coroutine destroying
the promise and the frame.   At that point access via the handle is an
error.  Fixed by checking that the promise is destroyed via a global var.

tested on x86_64-darwin, linux
pushed to master
thanks
Iain

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/torture/co-ret-17-void-ret-coro.C: Check for
promise destruction via a global variable.
---
 .../coroutines/torture/co-ret-17-void-ret-coro.C | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/g++.dg/coroutines/torture/co-ret-17-void-ret-coro.C 
b/gcc/testsuite/g++.dg/coroutines/torture/co-ret-17-void-ret-coro.C
index 3168ea272c1..01a75c1905d 100644
--- a/gcc/testsuite/g++.dg/coroutines/torture/co-ret-17-void-ret-coro.C
+++ b/gcc/testsuite/g++.dg/coroutines/torture/co-ret-17-void-ret-coro.C
@@ -5,14 +5,17 @@
 
 #include "../coro.h"
 
+int g_promise = -1;
+
 template
 struct std::coroutine_traits {
 struct promise_type {
 promise_type (HandleRef h, T ...args)
 { h = std::coroutine_handle::from_promise (*this);
   PRINT ("Created Promise");
+  g_promise = 1;
 }
-
+   ~promise_type () { PRINT ("Destroyed Promise"); g_promise = 0;}
 void get_return_object() {}
 
 auto initial_suspend() {
@@ -45,10 +48,11 @@ int main ()
 
   // initial suspend.
   h.resume ();
-  
-  if (!h.done())
+
+  // The coro should have self-destructed.
+  if (g_promise)
 {
-  PRINT ("main: apparently wasn't done...");
+  PRINT ("main: apparently we did not complete...");
   abort ();
 }
 
-- 
2.24.1

Re: [PATCH 5/7] vect: Support vector load/store with length in vectorizer

[Richard Sandiford]

"Kewen.Lin"  writes:
> @@ -626,6 +645,12 @@ public:
>/* True if have decided to use a fully-masked loop.  */
>bool fully_masked_p;
>  
> +  /* Records whether we still have the option of using a length access loop. 
>  */
> +  bool can_with_length_p;
> +
> +  /* True if have decided to use length access for the loop fully.  */
> +  bool fully_with_length_p;

Rather than duplicate the flags like this, I think we should have
three bits of information:

(1) Can the loop operate on partial vectors?  Starts off optimistically
assuming "yes", gets set to "no" when we find a counter-example.

(2) If we do decide to use partial vectors, will we need loop masks?

(3) If we do decide to use partial vectors, will we need lengths?

Vectorisation using partial vectors succeeds if (1) && ((2) != (3))

LOOP_VINFO_CAN_FULLY_MASK_P currently tracks (1) and
LOOP_VINFO_MASKS currently tracks (2).  In pathological cases it's
already possible to have (1) && !(2), see r9-6240 for an example.

With the new support, LOOP_VINFO_LENS tracks (3).

So I don't think we need the can_with_length_p.  What is now
LOOP_VINFO_CAN_FULLY_MASK_P can continue to track (1) for both
approaches, with the final choice of approach only being made
at the end.  Maybe it would be worth renaming it to something
more generic though, now that we have two approaches to partial
vectorisation.

I think we can assume for now that no arch will be asymmetrical,
and require (say) loop masks for loads and lengths for stores.
So if that does happen (i.e. if (2) && (3) ends up being true)
we should just be able to punt on partial vectorisation.

Some of the new length code looks like it's copied and adjusted from the
corresponding mask code.  It would be good to share the code instead
where possible, e.g. when deciding whether an IV can overflow.

Thanks,
Richard

Re: [PATCH 5/7] vect: Support vector load/store with length in vectorizer

[Richard Sandiford]

Richard Sandiford  writes:
> "Kewen.Lin"  writes:
>> @@ -626,6 +645,12 @@ public:
>>/* True if have decided to use a fully-masked loop.  */
>>bool fully_masked_p;
>>  
>> +  /* Records whether we still have the option of using a length access 
>> loop.  */
>> +  bool can_with_length_p;
>> +
>> +  /* True if have decided to use length access for the loop fully.  */
>> +  bool fully_with_length_p;
>
> Rather than duplicate the flags like this, I think we should have
> three bits of information:
>
> (1) Can the loop operate on partial vectors?  Starts off optimistically
> assuming "yes", gets set to "no" when we find a counter-example.
>
> (2) If we do decide to use partial vectors, will we need loop masks?
>
> (3) If we do decide to use partial vectors, will we need lengths?
>
> Vectorisation using partial vectors succeeds if (1) && ((2) != (3))
>
> LOOP_VINFO_CAN_FULLY_MASK_P currently tracks (1) and
> LOOP_VINFO_MASKS currently tracks (2).  In pathological cases it's
> already possible to have (1) && !(2), see r9-6240 for an example.

Oops, I meant r8-6240.

Re: New mklog script

[Martin Liška]

On 5/26/20 1:18 PM, Richard Earnshaw wrote:

On 26/05/2020 12:14, Martin Liška wrote:

On 5/26/20 12:23 PM, Richard Earnshaw wrote:

I thought we had a convention that aliases we added were prefixed with
'gcc-'?  This seems to go against that.


You are right, but this one is so handy ;)
What name do you suggest?

Martin


gcc-ci?


What the abbreviation stands for?

Martin



R.

Re: New mklog script

[Richard Earnshaw]

On 26/05/2020 14:09, Martin Liška wrote:
> On 5/26/20 1:18 PM, Richard Earnshaw wrote:
>> On 26/05/2020 12:14, Martin Liška wrote:
>>> On 5/26/20 12:23 PM, Richard Earnshaw wrote:
 I thought we had a convention that aliases we added were prefixed with
 'gcc-'?  This seems to go against that.
>>>
>>> You are right, but this one is so handy ;)
>>> What name do you suggest?
>>>
>>> Martin
>>
>> gcc-ci?
> 
> What the abbreviation stands for?
> 
> Martin
> 
>>
>> R.
>>
> 

CheckIn

For those who come from the SVN days where ci was the standard
abbreviation for committing :-)

R.

Re: New mklog script

[Martin Liška]

On 5/26/20 3:11 PM, Richard Earnshaw wrote:

On 26/05/2020 14:09, Martin Liška wrote:

On 5/26/20 1:18 PM, Richard Earnshaw wrote:

On 26/05/2020 12:14, Martin Liška wrote:

On 5/26/20 12:23 PM, Richard Earnshaw wrote:

I thought we had a convention that aliases we added were prefixed with
'gcc-'?  This seems to go against that.


You are right, but this one is so handy ;)
What name do you suggest?

Martin


gcc-ci?


What the abbreviation stands for?

Martin



R.





CheckIn

For those who come from the SVN days where ci was the standard
abbreviation for committing :-)


Ah, I see. Anyway, I prefer the original name even though it violates
the naming policy.

Let other express their preferences (Jason?).

Martin



R.

Re: New mklog script

[Jakub Jelinek via Gcc-patches]

On Tue, May 26, 2020 at 03:14:54PM +0200, Martin Liška wrote:
> > > > gcc-ci?
> > > 
> > > What the abbreviation stands for?
> > > 
> > > Martin
> > > 
> > > > 
> > > > R.
> > > > 
> > > 
> > 
> > CheckIn
> > 
> > For those who come from the SVN days where ci was the standard
> > abbreviation for committing :-)
> 
> Ah, I see. Anyway, I prefer the original name even though it violates
> the naming policy.
> 
> Let other express their preferences (Jason?).

gcc-ci looks nice to me.

Jakub

[committed] i386: Implement V2SI and V4HI shuffles

[Uros Bizjak via Gcc-patches]

2020-05-26  Uroš Bizjak  

gcc/ChangeLog:
* config/i386/mmx.md (*mmx_pshufd_1): New insn pattern.
* config/i386/i386-expand.c (ix86_vectorize_vec_perm_const):
Handle E_V2SImode and E_V4HImode.
(expand_vec_perm_even_odd_1): Handle E_V4HImode.
Assert that E_V2SImode is already handled.
(expand_vec_perm_broadcast_1): Assert that E_V2SImode
is already handled by standard shuffle patterns.

gcc/testsuite/ChangeLog:
* gcc.target/i386/vperm-v2si.c: New test.
* gcc.target/i386/vperm-v4hi.c: Ditto.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Uros.
diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
index 79f827fd653..338b4f7cf4f 100644
--- a/gcc/config/i386/i386-expand.c
+++ b/gcc/config/i386/i386-expand.c
@@ -18634,10 +18634,26 @@ expand_vec_perm_even_odd_1 (struct expand_vec_perm_d 
*d, unsigned odd)
 case E_V2DFmode:
 case E_V4SFmode:
 case E_V2DImode:
+case E_V2SImode:
 case E_V4SImode:
   /* These are always directly implementable by expand_vec_perm_1.  */
   gcc_unreachable ();
 
+case E_V4HImode:
+  if (d->testing_p)
+   break;
+  /* We need 2*log2(N)-1 operations to achieve odd/even
+with interleave. */
+  t1 = gen_reg_rtx (V4HImode);
+  emit_insn (gen_mmx_punpckhwd (t1, d->op0, d->op1));
+  emit_insn (gen_mmx_punpcklwd (d->target, d->op0, d->op1));
+  if (odd)
+   t2 = gen_mmx_punpckhwd (d->target, d->target, t1);
+  else
+   t2 = gen_mmx_punpcklwd (d->target, d->target, t1);
+  emit_insn (t2);
+  break;
+
 case E_V8HImode:
   if (TARGET_SSE4_1)
return expand_vec_perm_even_odd_pack (d);
@@ -18820,6 +18836,7 @@ expand_vec_perm_broadcast_1 (struct expand_vec_perm_d 
*d)
 case E_V2DFmode:
 case E_V2DImode:
 case E_V4SFmode:
+case E_V2SImode:
 case E_V4SImode:
   /* These are always implementable using standard shuffle patterns.  */
   gcc_unreachable ();
@@ -19312,6 +19329,11 @@ ix86_vectorize_vec_perm_const (machine_mode vmode, rtx 
target, rtx op0,
   if (d.testing_p && TARGET_SSSE3)
return true;
   break;
+case E_V2SImode:
+case E_V4HImode:
+  if (!TARGET_MMX_WITH_SSE)
+   return false;
+  break;
 case E_V2DImode:
 case E_V2DFmode:
   if (!TARGET_SSE)
@@ -19344,7 +19366,9 @@ ix86_vectorize_vec_perm_const (machine_mode vmode, rtx 
target, rtx op0,
   d.one_operand_p = (which != 3);
 
   /* Implementable with shufps or pshufd.  */
-  if (d.one_operand_p && (d.vmode == V4SFmode || d.vmode == V4SImode))
+  if (d.one_operand_p
+ && (d.vmode == V4SFmode
+ || d.vmode == V4SImode || d.vmode == V2SImode))
return true;
 
   /* Otherwise we have to go through the motions and see if we can
diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index b5564711aa4..c31b4f81079 100644
--- a/gcc/config/i386/mmx.md
+++ b/gcc/config/i386/mmx.md
@@ -1988,6 +1988,28 @@
(set_attr "length_immediate" "1")
(set_attr "mode" "DI,TI")])
 
+(define_insn "*mmx_pshufd_1"
+  [(set (match_operand:V2SI 0 "register_operand" "=Yv")
+(vec_select:V2SI
+  (match_operand:V2SI 1 "register_operand" "Yv")
+  (parallel [(match_operand 2 "const_0_to_1_operand")
+ (match_operand 3 "const_0_to_1_operand")])))]
+  "TARGET_MMX_WITH_SSE"
+{
+  int mask = 0;
+  mask |= INTVAL (operands[2]) << 0;
+  mask |= INTVAL (operands[3]) << 2;
+  mask |= 2 << 4;
+  mask |= 3 << 6;
+  operands[2] = GEN_INT (mask);
+
+  return "%vpshufd\t{%2, %1, %0|%0, %1, %2}";
+}
+  [(set_attr "type" "sselog1")
+   (set_attr "prefix_data16" "1")
+   (set_attr "length_immediate" "1")
+   (set_attr "mode" "TI")])
+
 (define_insn "mmx_pswapdv2si2"
   [(set (match_operand:V2SI 0 "register_operand" "=y")
(vec_select:V2SI
diff --git a/gcc/testsuite/gcc.target/i386/vperm-v2si.c 
b/gcc/testsuite/gcc.target/i386/vperm-v2si.c
new file mode 100644
index 000..5b38b316e3b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/vperm-v2si.c
@@ -0,0 +1,41 @@
+/* { dg-do run { target { ! ia32 } } } */
+/* { dg-options "-O -msse2" } */
+/* { dg-require-effective-target sse2 } */
+
+#include "isa-check.h"
+#include "sse-os-support.h"
+
+typedef int S;
+typedef int V __attribute__((vector_size(8)));
+typedef int IV __attribute__((vector_size(8)));
+typedef union { S s[2]; V v; } U;
+
+static U i[2], b, c;
+
+extern int memcmp (const void *, const void *, __SIZE_TYPE__);
+#define assert(T) ((T) || (__builtin_trap (), 0))
+
+#define TEST(E0, E1) \
+  b.v = __builtin_shuffle (i[0].v, i[1].v, (IV){E0, E1}); \
+  c.s[0] = i[0].s[E0]; \
+  c.s[1] = i[0].s[E1]; \
+  __asm__("" : : : "memory"); \
+  assert (memcmp (&b, &c, sizeof(c)) == 0);
+
+#include "vperm-2-2.inc"
+
+int main()
+{
+  check_isa ();
+
+  if (!sse_os_support ())
+exit (0);
+
+  i[0].s[0] = 0;
+  i[0].s[1] = 1;
+  i[0].s[2] = 2;
+  i[0].s[3] = 3;
+
+  check();
+  retur

Re: V5 [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

[Martin Liška]

On 5/26/20 1:59 PM, H.J. Lu wrote:

On Tue, May 26, 2020 at 2:30 AM Martin Liška  wrote:


On 5/25/20 7:42 PM, H.J. Lu wrote:

Here is the updated patch.  OK for master?


Thank you for the updated patch.

I have still few nits:

1) I would make all the:


+  has_sse3 = has_feature (FEATURE_SSE3);


a macro. The local variable seems to superfluous.


Done.


Thanks!




2) can we automatically deduce option name:


+  ISA_NAMES_TABLE_ENTRY("rdpid", FEATURE_RDPID, P_ZERO, "-mrdpid")
+  ISA_NAMES_TABLE_ENTRY("rdrnd", FEATURE_RDRND, P_ZERO, "-mrdrnd")


I mean "-m" + "rdrnd" == "-mrdrnd" ?


The new option field serves 2 purposes:

1. Not all features have a corresponding command-line option

ISA_NAMES_TABLE_ENTRY("cmov", FEATURE_CMOV, P_ZERO, NULL)

  for (i = 0; i < ARRAY_SIZE (isa_names_table); i++)
 if (isa_names_table[i].option)

2. Some feature has a different name in the command-line option.

   ISA_NAMES_TABLE_ENTRY("fxsave", FEATURE_FXSAVE, P_ZERO, "-mfxsr")


I noticed that, one can theoretically use "" for an option that does not
have a flag. And NULL for these which have option equal to "-m" + name.
Anyway, that's a nit.

I support the patch!
Martin



Here is the updated patch.   OK for master?

Thanks.

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

[Alexandre Oliva]

On May 26, 2020, Richard Biener  wrote:

> xgcc: error: unrecognized command-line option '-dumpbase'^M

> xg++: error: unrecognized command-line option '-dA'; did you mean '-A'


Here's a proper patch submission.  I'm still throwing tests at it, but
it's already proved (with a non-bootstrapped build and test run) to fix
the latent (to me) problems above, exposed by configuring GCC without
Ada support, so I think putting it in is highly desirable, and a strict
improvement.  Ok to install?


do not skip validation of switch after %

After the patch that revamped dump and aux outputs, GCC compilation
drivers built without Ada would reject -d* options.  Such options
would only be validated because of the %{d*} in Ada lang specs, though
other languages had it as well.  Other languages had %< specs that had
to be there before %{d*} %:dumps(), while Ada was missing them.
Adding them to Ada brought the same problem to compilers that had Ada
enabled.

The reason validation failed was that they mishandled %< specs,
advancing past the beginning of the next spec, causing it not to be
handled.  Since %{d*} appeared after an odd %<, it was thus ignored.
The logic of validate_switches originally skipped the closing brace
that matched the opening brace, but this shouldn't happen for %<.
Fixed by letting validate_switches know whether it is handling a
braced group or a single atom, and behaving accordingly.


for  gcc/ChangeLog

* gcc.c (validate_switches): Add braced parameter.  Adjust all
callers.  Expected and skip trailing brace only if braced.
Return after handling one atom otherwise.
(DUMPS_OPTIONS): New.
(cpp_debug_options): Define in terms of it.

for  gcc/ada/ChangeLog

* gcc-interfaces/lang-specs.h (ADA_DUMPS_OPTIONS): Define in
terms of DUMPS_OPTIONS.  Replace occurrences of %{d*} %:dumps
with it.
---
 gcc/ada/gcc-interface/lang-specs.h |   10 +++---
 gcc/gcc.c  |   32 +++-
 2 files changed, 30 insertions(+), 12 deletions(-)

diff --git a/gcc/ada/gcc-interface/lang-specs.h 
b/gcc/ada/gcc-interface/lang-specs.h
index 12b7cf5e..f0ef3b92 100644
--- a/gcc/ada/gcc-interface/lang-specs.h
+++ b/gcc/ada/gcc-interface/lang-specs.h
@@ -23,6 +23,10 @@
  *  *
  /
 
+/* Pass -d* flags to the actual compiler, but mapping non-Ada
+   extensions to .ada in dump file names.  */
+#define ADA_DUMPS_OPTIONS DUMPS_OPTIONS ("%{!.adb:%{!.ads:.ada}}")
+
 /* This is the contribution to the `default_compilers' array in gcc.c for
GNAT.  */
 
@@ -35,7 +39,7 @@
  gnat1 %{I*} %{k8:-gnatk8} %{Wall:-gnatwa} %{w:-gnatws} %{!Q:-quiet}\
 %{nostdinc*} %{nostdlib*}\
 %{fcompare-debug-second:-gnatd_A} \
-%{O*} %{W*} %{w} %{p} %{pg:-p} %{d*} %:dumps(%{!.adb:%{!.ads:.ada}}) \
+%{O*} %{W*} %{w} %{p} %{pg:-p} " ADA_DUMPS_OPTIONS " \
 %{coverage:-fprofile-arcs -ftest-coverage} "
 #if defined(TARGET_VXWORKS_RTP)
"%{fRTS=rtp|fRTS=rtp-smp|fRTS=ravenscar-cert-rtp:-mrtp} "
@@ -51,7 +55,7 @@
  %{!c:%e-c required for gnat2why}\
  gnat1why %{I*} %{k8:-gnatk8} %{!Q:-quiet}\
 %{nostdinc*} %{nostdlib*}\
-%{a} %{d*} %:dumps(%{!.adb:%{!.ads:.ada}}) \
+%{a} " ADA_DUMPS_OPTIONS " \
 %{gnatea:-gnatez} %{g*&m*&f*} \
 %1 %{o*:%w%*-gnatO} \
 %i \
@@ -62,7 +66,7 @@
  %{!c:%e-c required for gnat2scil}\
  gnat1scil %{I*} %{k8:-gnatk8} %{!Q:-quiet}\
 %{nostdinc*} %{nostdlib*}\
-%{a} %{d*} %:dumps(%{!.adb:%{!.ads:.ada}}) \
+%{a} " ADA_DUMPS_OPTIONS " \
 %{gnatea:-gnatez} %{g*&m*&f*} \
 %1 %{o*:%w%*-gnatO} \
 %i \
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 8c851d7..e2362175f4 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -388,7 +388,7 @@ static void do_option_spec (const char *, const char *);
 static void do_self_spec (const char *);
 static const char *find_file (const char *);
 static int is_directory (const char *, bool);
-static const char *validate_switches (const char *, bool);
+static const char *validate_switches (const char *, bool, bool);
 static void validate_all_switches (void);
 static inline void validate_switches_from_spec (const char *, bool);
 static void give_switch (int, int);
@@ -1176,9 +1176,16 @@ static const char *cpp_options =
  %{!fno-working-directory:-fworking-directory}}} %{O*}\
  %{undef} %{save-temps*:-fpch-preprocess}";
 
+/* Pass -d* flags, possibly modifying -dumpdir, -dumpbase et al.
+
+   Make it easy for a language to override the argument for the
+   %:dumps specs function call.  */
+#define DUMPS_OPTIONS(EXTS) \
+  "%https://FSFLA.org/blogs/lxo/
Free Software Evangelist  Stallman was right, but he's left :(
GNU Toolchain Engineer   Live long and free, and prosper ethically

[LTO/offloading] Fix offloading-compilation ICE without -flto (PR84320)

[Tobias Burnus]

LTO stream out not only happens with LTO (-flto) but also for
the offloaded functions with OpenMP/OpenACC.

Without using -flto, this leads to an ICE as a recent patch
(r11-525-g03d90a20a1afcbb9c30da8d4adf4922b0685061f) added the
check to DFS::DFS (lto-streamer-out.c:639):
   if (ob->local_trees && local_tree_p (expr))
where local_tree_p calls odr_type_t.

And the latter that contains the following assert, which fails:

  /* We do not have this information when not in LTO, but we do not need
 to care, since it is used only for type merging.  */
  gcc_checking_assert (in_lto_p || flag_lto);

Adding 'in_lto_p &&' before the 'odr_type_t (t) &&' in local_tree_p
works for offloading but this causes an ICE:
   FAIL: g++.dg/asan/pr85774.C   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (internal compiler error)
lto1: internal compiler error: in unify_scc, at lto/lto-common.c:1678

Hence, the simple solution is to add flag_generate_offload to the
assert, which this patch does.

OK for the trunk?

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
[LTO/offloading] Fix offloading-compilation ICE without -flto (PR84320)

gcc/ChangeLog:
	PR ipa/95320
	* ipa-utils.h (odr_type_p): Also permit calls with
	only flag_generate_offload set.

 gcc/ipa-utils.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/ipa-utils.h b/gcc/ipa-utils.h
index 98edc383461..d0ac3ec86f8 100644
--- a/gcc/ipa-utils.h
+++ b/gcc/ipa-utils.h
@@ -243,7 +243,7 @@ odr_type_p (const_tree t)
 {
   /* We do not have this information when not in LTO, but we do not need
  to care, since it is used only for type merging.  */
-  gcc_checking_assert (in_lto_p || flag_lto);
+  gcc_checking_assert (in_lto_p || flag_lto || flag_generate_offload);
   return TYPE_NAME (t) && TREE_CODE (TYPE_NAME (t)) == TYPE_DECL
  && DECL_ASSEMBLER_NAME_SET_P (TYPE_NAME (t));
 }

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

[Richard Biener]

On Tue, 26 May 2020, Alexandre Oliva wrote:

> On May 26, 2020, Richard Biener  wrote:
> 
> > xgcc: error: unrecognized command-line option '-dumpbase'^M
> 
> > xg++: error: unrecognized command-line option '-dA'; did you mean '-A'
> 
> 
> Here's a proper patch submission.  I'm still throwing tests at it, but
> it's already proved (with a non-bootstrapped build and test run) to fix
> the latent (to me) problems above, exposed by configuring GCC without
> Ada support, so I think putting it in is highly desirable, and a strict
> improvement.  Ok to install?

OK.

Thanks,
Richard.

> 
> do not skip validation of switch after % 
> From: Alexandre Oliva 
> 
> After the patch that revamped dump and aux outputs, GCC compilation
> drivers built without Ada would reject -d* options.  Such options
> would only be validated because of the %{d*} in Ada lang specs, though
> other languages had it as well.  Other languages had %< specs that had
> to be there before %{d*} %:dumps(), while Ada was missing them.
> Adding them to Ada brought the same problem to compilers that had Ada
> enabled.
> 
> The reason validation failed was that they mishandled %< specs,
> advancing past the beginning of the next spec, causing it not to be
> handled.  Since %{d*} appeared after an odd %<, it was thus ignored.
> The logic of validate_switches originally skipped the closing brace
> that matched the opening brace, but this shouldn't happen for %<.
> Fixed by letting validate_switches know whether it is handling a
> braced group or a single atom, and behaving accordingly.
> 
> 
> for  gcc/ChangeLog
> 
>   * gcc.c (validate_switches): Add braced parameter.  Adjust all
>   callers.  Expected and skip trailing brace only if braced.
>   Return after handling one atom otherwise.
>   (DUMPS_OPTIONS): New.
>   (cpp_debug_options): Define in terms of it.
> 
> for  gcc/ada/ChangeLog
> 
>   * gcc-interfaces/lang-specs.h (ADA_DUMPS_OPTIONS): Define in
>   terms of DUMPS_OPTIONS.  Replace occurrences of %{d*} %:dumps
>   with it.
> ---
>  gcc/ada/gcc-interface/lang-specs.h |   10 +++---
>  gcc/gcc.c  |   32 +++-
>  2 files changed, 30 insertions(+), 12 deletions(-)
> 
> diff --git a/gcc/ada/gcc-interface/lang-specs.h 
> b/gcc/ada/gcc-interface/lang-specs.h
> index 12b7cf5e..f0ef3b92 100644
> --- a/gcc/ada/gcc-interface/lang-specs.h
> +++ b/gcc/ada/gcc-interface/lang-specs.h
> @@ -23,6 +23,10 @@
>   *  *
>   
> /
>  
> +/* Pass -d* flags to the actual compiler, but mapping non-Ada
> +   extensions to .ada in dump file names.  */
> +#define ADA_DUMPS_OPTIONS DUMPS_OPTIONS ("%{!.adb:%{!.ads:.ada}}")
> +
>  /* This is the contribution to the `default_compilers' array in gcc.c for
> GNAT.  */
>  
> @@ -35,7 +39,7 @@
>   gnat1 %{I*} %{k8:-gnatk8} %{Wall:-gnatwa} %{w:-gnatws} %{!Q:-quiet}\
>  %{nostdinc*} %{nostdlib*}\
>  %{fcompare-debug-second:-gnatd_A} \
> -%{O*} %{W*} %{w} %{p} %{pg:-p} %{d*} %:dumps(%{!.adb:%{!.ads:.ada}}) \
> +%{O*} %{W*} %{w} %{p} %{pg:-p} " ADA_DUMPS_OPTIONS " \
>  %{coverage:-fprofile-arcs -ftest-coverage} "
>  #if defined(TARGET_VXWORKS_RTP)
> "%{fRTS=rtp|fRTS=rtp-smp|fRTS=ravenscar-cert-rtp:-mrtp} "
> @@ -51,7 +55,7 @@
>   %{!c:%e-c required for gnat2why}\
>   gnat1why %{I*} %{k8:-gnatk8} %{!Q:-quiet}\
>  %{nostdinc*} %{nostdlib*}\
> -%{a} %{d*} %:dumps(%{!.adb:%{!.ads:.ada}}) \
> +%{a} " ADA_DUMPS_OPTIONS " \
>  %{gnatea:-gnatez} %{g*&m*&f*} \
>  %1 %{o*:%w%*-gnatO} \
>  %i \
> @@ -62,7 +66,7 @@
>   %{!c:%e-c required for gnat2scil}\
>   gnat1scil %{I*} %{k8:-gnatk8} %{!Q:-quiet}\
>  %{nostdinc*} %{nostdlib*}\
> -%{a} %{d*} %:dumps(%{!.adb:%{!.ads:.ada}}) \
> +%{a} " ADA_DUMPS_OPTIONS " \
>  %{gnatea:-gnatez} %{g*&m*&f*} \
>  %1 %{o*:%w%*-gnatO} \
>  %i \
> diff --git a/gcc/gcc.c b/gcc/gcc.c
> index 8c851d7..e2362175f4 100644
> --- a/gcc/gcc.c
> +++ b/gcc/gcc.c
> @@ -388,7 +388,7 @@ static void do_option_spec (const char *, const char *);
>  static void do_self_spec (const char *);
>  static const char *find_file (const char *);
>  static int is_directory (const char *, bool);
> -static const char *validate_switches (const char *, bool);
> +static const char *validate_switches (const char *, bool, bool);
>  static void validate_all_switches (void);
>  static inline void validate_switches_from_spec (const char *, bool);
>  static void give_switch (int, int);
> @@ -1176,9 +1176,16 @@ static const char *cpp_options =
>   %{!fno-working-directory:-fworking-directory}}} %{O*}\
>   %{undef} %{save-temps*:-fpch-preprocess}";
>  
> +/* Pass -d* flags, possibly modifying -dumpdir, -dumpbase et al.
> +
> +   Make it easy for a language to override the argument for the
> +   %:dumps specs function call.  */
> +#define DUMPS_OPTIONS

[PATCH] tree-optimization/95327 - fix another vectorizable_shift const SLP op

[Richard Biener]

This fixes another case where we fail to set the type on a SLP
constant operand in vectorizable_shift.

Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.

Richard.

2020-05-26  Richard Biener  

PR tree-optimization/95327
* tree-vect-stmts.c (vectorizable_shift): Compute op1_vectype
when we are not using a scalar shift.
---
 gcc/tree-vect-stmts.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 76c7b995817..225a9dc98ac 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -5733,13 +5733,19 @@ vectorizable_shift (vec_info *vinfo,
 dump_printf_loc (MSG_NOTE, vect_location,
  "vector/vector shift/rotate found.\n");
 
+ if (!op1_vectype)
+   op1_vectype = get_vectype_for_scalar_type (vinfo,
+  TREE_TYPE (op1),
+  slp_node);
+
   /* Unlike the other binary operators, shifts/rotates have
  the rhs being int, instead of the same type as the lhs,
  so make sure the scalar is the right type if we are
 dealing with vectors of long long/long/short/char.  */
  incompatible_op1_vectype_p
-   = !tree_nop_conversion_p (TREE_TYPE (vectype),
- TREE_TYPE (op1));
+   = (!op1_vectype
+  || !tree_nop_conversion_p (TREE_TYPE (vectype),
+ TREE_TYPE (op1)));
 }
 }
 }
-- 
2.25.1

Re: [Patch][OpenMP] Fix mapping of artificial variables (PR94874)

[Jakub Jelinek via Gcc-patches]

On Mon, May 25, 2020 at 07:10:31PM +0200, Tobias Burnus wrote:
> +enum omp_clause_defaultmap_kind
> +cxx_omp_predetermined_mapping (tree decl)
> +{
> +  enum omp_clause_default_kind ret = cxx_omp_predetermined_sharing_1 (decl);
> +  if (ret != OMP_CLAUSE_DEFAULT_UNSPECIFIED)
> +return OMP_CLAUSE_DEFAULTMAP_TO;

I don't like the above 3 lines, do you need it for anything?
Static data members certainly aren't covered and it is unlikely we want to
predetermine them mapped.

> +  /* Predetermine artificial variables holding integral values, those
> + are usually result of gimplify_one_sizepos or SAVE_EXPR
> + gimplification.  */
> +  if (VAR_P (decl)
> +  && DECL_ARTIFICIAL (decl)
> +  && INTEGRAL_TYPE_P (TREE_TYPE (decl))
> +  && !(DECL_LANG_SPECIFIC (decl)
> +&& DECL_OMP_PRIVATIZED_MEMBER (decl)))
> +return OMP_CLAUSE_DEFAULTMAP_FIRSTPRIVATE;
> +
> +  /* Similarly for typeinfo symbols.  */
> +  if (VAR_P (decl) && DECL_ARTIFICIAL (decl) && DECL_TINFO_P (decl))
> +return OMP_CLAUSE_DEFAULTMAP_TO;

I think the typeinfo symbols and vtables we should implicitly mark declare
target to, rather than trying to map them, that will not work properly
anyway (they contain embedded function pointers).
So I think the above 3 lines should go too.

Otherwise LGTM.

Jakub

Re: [rs6000] fix mffsl emulation

[Alexandre Oliva]

On Apr 28, 2020, Segher Boessenkool  wrote:

> Okay for trunk with such tweaks.  Thank you!  Also okay for the 9 branch,
> after waiting to see if any fallout appears.

Thanks, I've just pushed it to the gcc-9 branch.

-- 
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist  Stallman was right, but he's left :(
GNU Toolchain Engineer   Live long and free, and prosper ethically

[PATCH 1/2] gcc-changelog: remove file descriptor leaks

[Pierre-Marie de Rodat]

Currently, running gcc-changelog's unit tests may clutter the output
with tons of warnings such as:

.../contrib/gcc-changelog/git_email.py:40: ResourceWarning: unclosed
file <_io.TextIOWrapper name='/tmp/tmpt5okd4qp.patch' mode='r'
encoding='UTF-8'>
  lines = open(self.filename).read().splitlines()
ResourceWarning: Enable tracemalloc to get the object allocation
traceback

This commit fixes these leaks, which restores a clean testsuite output.

contrib/

* gcc-changelog/git_email.py: Close file objects after use.
* gcc-changelog/test_email.py: Likewise.
---
 contrib/gcc-changelog/git_email.py  | 3 ++-
 contrib/gcc-changelog/git_update_version.py | 6 --
 contrib/gcc-changelog/test_email.py | 3 ++-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/contrib/gcc-changelog/git_email.py 
b/contrib/gcc-changelog/git_email.py
index e1d6b70e80c..8c9df293a66 100755
--- a/contrib/gcc-changelog/git_email.py
+++ b/contrib/gcc-changelog/git_email.py
@@ -37,7 +37,8 @@ class GitEmail(GitCommit):
 date = None
 author = None
 
-lines = open(self.filename).read().splitlines()
+with open(self.filename, 'r') as f:
+lines = f.read().splitlines()
 lines = list(takewhile(lambda line: line != '---', lines))
 for line in lines:
 if line.startswith(DATE_PREFIX):
diff --git a/contrib/gcc-changelog/git_update_version.py 
b/contrib/gcc-changelog/git_update_version.py
index 3dcc5625eda..6b6ccf68a5e 100755
--- a/contrib/gcc-changelog/git_update_version.py
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -28,7 +28,8 @@ current_timestamp = 
datetime.datetime.now().strftime('%Y%m%d\n')
 
 
 def read_timestamp(path):
-return open(path).read()
+with open(path) as f:
+return f.read()
 
 
 def prepend_to_changelog_files(repo, folder, git_commit, add_to_git):
@@ -40,7 +41,8 @@ def prepend_to_changelog_files(repo, folder, git_commit, 
add_to_git):
 full_path = os.path.join(folder, entry, 'ChangeLog')
 print('writting to %s' % full_path)
 if os.path.exists(full_path):
-content = open(full_path).read()
+with open(full_path) as f:
+content = f.read()
 else:
 content = ''
 with open(full_path, 'w+') as f:
diff --git a/contrib/gcc-changelog/test_email.py 
b/contrib/gcc-changelog/test_email.py
index bf028a3d40a..1379502e755 100755
--- a/contrib/gcc-changelog/test_email.py
+++ b/contrib/gcc-changelog/test_email.py
@@ -33,7 +33,8 @@ class TestGccChangelog(unittest.TestCase):
 
 filename = None
 patch_lines = []
-lines = open(os.path.join(script_path, 'test_patches.txt')).read()
+with open(os.path.join(script_path, 'test_patches.txt')) as f:
+lines = f.read()
 for line in lines.split('\n'):
 if line.startswith('==='):
 if patch_lines:
-- 
2.20.1

[PATCH 2/2] gcc-changelog: handle entries with multi-line file lists

[Pierre-Marie de Rodat]

This extends the ChangeLog entries parsing machinery to handle entries
that cover multiple files spanning over multiple lines. For instance:

* first_file_patched.c, second_file_patched.c, third_file_patched.c,
fourth_file_patched.c: Do things.

contrib/

* gcc-changelog/git_commit.py (ChangeLogEntry): Handle entries
with multi-line file lists.
* test_email.py: New testcase.
* test_patches.txt: Likewise.
---
 contrib/gcc-changelog/git_commit.py|  18 ++
 contrib/gcc-changelog/test_email.py|   9 +
 contrib/gcc-changelog/test_patches.txt | 290 +
 3 files changed, 317 insertions(+)

diff --git a/contrib/gcc-changelog/git_commit.py 
b/contrib/gcc-changelog/git_commit.py
index 6f99d917b3b..a24a251d8f3 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -185,14 +185,32 @@ class ChangeLogEntry:
 @property
 def files(self):
 files = []
+
+# Whether the content currently processed is between a star prefix the
+# end of the file list: a colon or an open paren.
+in_location = False
+
 for line in self.lines:
+# If this line matches the star prefix, start the location
+# processing on the information that follows the star.
 m = star_prefix_regex.match(line)
 if m:
+in_location = True
 line = m.group('content')
+
+if in_location:
+# Strip everything that is not a filename in "line": entities
+# "(NAME)", entry text (the colon, if present, and anything
+# that follows it).
 if '(' in line:
 line = line[:line.index('(')]
+in_location = False
 if ':' in line:
 line = line[:line.index(':')]
+in_location = False
+
+# At this point, all that 's left is a list of filenames
+# separated by commas and whitespaces.
 for file in line.split(','):
 file = file.strip()
 if file:
diff --git a/contrib/gcc-changelog/test_email.py 
b/contrib/gcc-changelog/test_email.py
index 1379502e755..3d2c8ff2412 100755
--- a/contrib/gcc-changelog/test_email.py
+++ b/contrib/gcc-changelog/test_email.py
@@ -286,3 +286,12 @@ class TestGccChangelog(unittest.TestCase):
 email = self.from_patch_glob('0001-Update-merge.sh-to-reflect.patch')
 assert (email.changelog_entries[0].lines[0]
 == '\t* LOCAL_PATCHES: Use git hash instead of SVN id.')
+
+def test_multiline_file_list(self):
+email = self.from_patch_glob(
+'0001-Ada-Reuse-Is_Package_Or_Generic_Package-where-possib.patch')
+assert (email.changelog_entries[0].files
+== ['contracts.adb', 'einfo.adb', 'exp_ch9.adb',
+'sem_ch12.adb', 'sem_ch4.adb', 'sem_ch7.adb',
+'sem_ch8.adb', 'sem_elab.adb', 'sem_type.adb',
+'sem_util.adb'])
diff --git a/contrib/gcc-changelog/test_patches.txt 
b/contrib/gcc-changelog/test_patches.txt
index 84d4b81d818..3492fb4dcb8 100644
--- a/contrib/gcc-changelog/test_patches.txt
+++ b/contrib/gcc-changelog/test_patches.txt
@@ -2650,4 +2650,294 @@ index dfa7bf3d196..3f4f1629a22 100755
  
 -- 
 2.26.2
+=== 0001-Ada-Reuse-Is_Package_Or_Generic_Package-where-possib.patch ===
+From 557b268fdeb0980a17411f458eee333f55c6 Mon Sep 17 00:00:00 2001
+From: Piotr Trojanek 
+Date: Thu, 12 Dec 2019 11:45:24 +0100
+Subject: [PATCH] [Ada] Reuse Is_Package_Or_Generic_Package where possible
+
+2020-05-26  Piotr Trojanek  
+
+gcc/ada/
+
+   * contracts.adb, einfo.adb, exp_ch9.adb, sem_ch12.adb,
+   sem_ch4.adb, sem_ch7.adb, sem_ch8.adb, sem_elab.adb,
+   sem_type.adb, sem_util.adb: Reuse Is_Package_Or_Generic_Package
+   where possible (similarly, reuse Is_Concurrent_Type if it was
+   possible in the same expressions).
+---
+ gcc/ada/contracts.adb |  2 +-
+ gcc/ada/einfo.adb | 22 +++---
+ gcc/ada/exp_ch9.adb   |  2 +-
+ gcc/ada/sem_ch12.adb  |  2 +-
+ gcc/ada/sem_ch4.adb   |  2 +-
+ gcc/ada/sem_ch7.adb   |  6 +++---
+ gcc/ada/sem_ch8.adb   |  6 +++---
+ gcc/ada/sem_elab.adb  |  2 +-
+ gcc/ada/sem_type.adb  |  2 +-
+ gcc/ada/sem_util.adb  |  6 +++---
+ 10 files changed, 26 insertions(+), 26 deletions(-)
+
+diff --git a/gcc/ada/contracts.adb b/gcc/ada/contracts.adb
+index 981bb91..d58f136 100644
+--- a/gcc/ada/contracts.adb
 b/gcc/ada/contracts.adb
+@@ -213,7 +213,7 @@ package body Contracts is
+   --Initializes
+   --Part_Of (instantiation only)
+ 
+-  elsif Ekind_In (Id, E_Generic_Package, E_Package) then
++  elsif Is_Package_Or_Generic_Package (Id) then
+  if Nam_In (Prag_Nam, Name_Abstract_State,
+   Name_Initial_Condition,
+   Name_Initi

Re: [PATCH 1/2] gcc-changelog: remove file descriptor leaks

[Martin Liška]

On 5/26/20 4:47 PM, Pierre-Marie de Rodat wrote:

Currently, running gcc-changelog's unit tests may clutter the output
with tons of warnings such as:

 .../contrib/gcc-changelog/git_email.py:40: ResourceWarning: unclosed
 file <_io.TextIOWrapper name='/tmp/tmpt5okd4qp.patch' mode='r'
 encoding='UTF-8'>
   lines = open(self.filename).read().splitlines()
 ResourceWarning: Enable tracemalloc to get the object allocation
 traceback

This commit fixes these leaks, which restores a clean testsuite output.


Hello.

Oh, that's new for me. I've never seen the warning.

Please install the patch.

Martin



contrib/

* gcc-changelog/git_email.py: Close file objects after use.
* gcc-changelog/test_email.py: Likewise.
---
  contrib/gcc-changelog/git_email.py  | 3 ++-
  contrib/gcc-changelog/git_update_version.py | 6 --
  contrib/gcc-changelog/test_email.py | 3 ++-
  3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/contrib/gcc-changelog/git_email.py 
b/contrib/gcc-changelog/git_email.py
index e1d6b70e80c..8c9df293a66 100755
--- a/contrib/gcc-changelog/git_email.py
+++ b/contrib/gcc-changelog/git_email.py
@@ -37,7 +37,8 @@ class GitEmail(GitCommit):
  date = None
  author = None
  
-lines = open(self.filename).read().splitlines()

+with open(self.filename, 'r') as f:
+lines = f.read().splitlines()
  lines = list(takewhile(lambda line: line != '---', lines))
  for line in lines:
  if line.startswith(DATE_PREFIX):
diff --git a/contrib/gcc-changelog/git_update_version.py 
b/contrib/gcc-changelog/git_update_version.py
index 3dcc5625eda..6b6ccf68a5e 100755
--- a/contrib/gcc-changelog/git_update_version.py
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -28,7 +28,8 @@ current_timestamp = 
datetime.datetime.now().strftime('%Y%m%d\n')
  
  
  def read_timestamp(path):

-return open(path).read()
+with open(path) as f:
+return f.read()
  
  
  def prepend_to_changelog_files(repo, folder, git_commit, add_to_git):

@@ -40,7 +41,8 @@ def prepend_to_changelog_files(repo, folder, git_commit, 
add_to_git):
  full_path = os.path.join(folder, entry, 'ChangeLog')
  print('writting to %s' % full_path)
  if os.path.exists(full_path):
-content = open(full_path).read()
+with open(full_path) as f:
+content = f.read()
  else:
  content = ''
  with open(full_path, 'w+') as f:
diff --git a/contrib/gcc-changelog/test_email.py 
b/contrib/gcc-changelog/test_email.py
index bf028a3d40a..1379502e755 100755
--- a/contrib/gcc-changelog/test_email.py
+++ b/contrib/gcc-changelog/test_email.py
@@ -33,7 +33,8 @@ class TestGccChangelog(unittest.TestCase):
  
  filename = None

  patch_lines = []
-lines = open(os.path.join(script_path, 'test_patches.txt')).read()
+with open(os.path.join(script_path, 'test_patches.txt')) as f:
+lines = f.read()
  for line in lines.split('\n'):
  if line.startswith('==='):
  if patch_lines:

[committed] jit: check for void types [PR 95296]

[David Malcolm via Gcc-patches]

PR jit/95296 reports an ICE when using libgccjit to create a local of void
type.

This patch adds checking to various API entrypoints in libgccjit.c so that
they fail gracefully with an error if the client code attempts to create
various kinds of rvalues or types involving void types.
The patch documents these and various pre-existing restrictions on types
in the API.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-636-g6f7585deedc140667fd496b48c9fc4f7d625605c.

gcc/jit/ChangeLog:
PR jit/95296
* docs/topics/expressions.rst (Unary Operations): Document that
result_type of gcc_jit_context_new_unary_op must be a numeric type.
(Binary Operations): Likewise for gcc_jit_context_new_binary_op.
(Global variables): Document that "type" of
gcc_jit_context_new_global must be non-`void`.
* docs/topics/function-pointers.rst
(gcc_jit_context_new_function_ptr_type): Document that the
param_types must be non-void, but that return_type may be.
* docs/topics/functions.rst (Params): Document that
gcc_jit_context_new_param's type must be non-void.
(Functions): Likewise for gcc_jit_function_new_local.
* docs/topics/types.rst (gcc_jit_context_new_array_type): Document
that the type must be non-void.
(gcc_jit_context_new_field): Likewise.
* docs/_build/texinfo/Makefile: Regenerate.
* docs/_build/texinfo/libgccjit.texi: Regenerate.
* libgccjit.c (gcc_jit_context_new_array_type): Fail if
element_type is void.
(gcc_jit_context_new_field): Likewise for "type".
(gcc_jit_context_new_function_ptr_type): Likewise for each
element of param_types.
(gcc_jit_context_new_param): Likewise for "type".
(gcc_jit_context_new_global): Likewise.
(gcc_jit_function_new_local): Likewise.
(gcc_jit_type_get_aligned): Likewise.

gcc/testsuite/ChangeLog:
PR jit/95296
* jit.dg/test-error-gcc_jit_context_new_global-void-type.c: New
test.
* jit.dg/test-error-gcc_jit_function_new_local-void-type.c: New
test.
* jit.dg/test-fuzzer.c (fuzzer_init): Allow for make_random_type
to return NULL.
(get_random_type): Allow for elements in f->types to be NULL.
---
 gcc/jit/docs/topics/expressions.rst   |  6 
 gcc/jit/docs/topics/function-pointers.rst |  2 ++
 gcc/jit/docs/topics/functions.rst |  4 +++
 gcc/jit/docs/topics/types.rst |  6 ++--
 gcc/jit/libgccjit.c   | 34 ---
 ...ror-gcc_jit_context_new_global-void-type.c | 25 ++
 ...ror-gcc_jit_function_new_local-void-type.c | 27 +++
 gcc/testsuite/jit.dg/test-fuzzer.c|  2 --
 8 files changed, 98 insertions(+), 8 deletions(-)
 create mode 100644 
gcc/testsuite/jit.dg/test-error-gcc_jit_context_new_global-void-type.c
 create mode 100644 
gcc/testsuite/jit.dg/test-error-gcc_jit_function_new_local-void-type.c

diff --git a/gcc/jit/docs/topics/expressions.rst 
b/gcc/jit/docs/topics/expressions.rst
index db2f2ca2e9c..d783ceea51a 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -162,6 +162,8 @@ Unary Operations
 
Build a unary operation out of an input rvalue.
 
+   The parameter ``result_type`` must be a numeric type.
+
 .. type:: enum gcc_jit_unary_op
 
 The available unary operations are:
@@ -227,6 +229,8 @@ Binary Operations
 
Build a binary operation out of two constituent rvalues.
 
+   The parameter ``result_type`` must be a numeric type.
+
 .. type:: enum gcc_jit_binary_op
 
 The available binary operations are:
@@ -547,6 +551,8 @@ Global variables
 
Add a new global variable of the given type and name to the context.
 
+   The parameter ``type`` must be non-`void`.
+
The parameter ``name`` must be non-NULL.  The call takes a copy of the
underlying string, so it is valid to pass in a pointer to an on-stack
buffer.
diff --git a/gcc/jit/docs/topics/function-pointers.rst 
b/gcc/jit/docs/topics/function-pointers.rst
index c8424ee17dc..7d2fa8b278d 100644
--- a/gcc/jit/docs/topics/function-pointers.rst
+++ b/gcc/jit/docs/topics/function-pointers.rst
@@ -78,3 +78,5 @@ Here's an example of creating a function pointer type 
corresponding to C's
 
Generate a :c:type:`gcc_jit_type` for a function pointer with the
given return type and parameters.
+
+   Each of `param_types` must be non-`void`; `return_type` may be `void`.
diff --git a/gcc/jit/docs/topics/functions.rst 
b/gcc/jit/docs/topics/functions.rst
index 74d479af1bb..29ce96c1e56 100644
--- a/gcc/jit/docs/topics/functions.rst
+++ b/gcc/jit/docs/topics/functions.rst
@@ -35,6 +35,8 @@ Params
In preparation for creating a function, create a new parameter of the
given type and name.
 
+   The parameter ``type`` must be non-`void`.
+
The parameter ``name`` must be non-NU

Re: [PATCH 2/2] gcc-changelog: handle entries with multi-line file lists

[Martin Liška]

On 5/26/20 4:47 PM, Pierre-Marie de Rodat wrote:

This extends the ChangeLog entries parsing machinery to handle entries
that cover multiple files spanning over multiple lines. For instance:

 * first_file_patched.c, second_file_patched.c, third_file_patched.c,
 fourth_file_patched.c: Do things.


Hi.

That was simpler than I expected ;) I compared results for all 2000 patches 
since
we switched to git and there are no changes!



contrib/

* gcc-changelog/git_commit.py (ChangeLogEntry): Handle entries
with multi-line file lists.
* test_email.py: New testcase.
* test_patches.txt: Likewise.
---
  contrib/gcc-changelog/git_commit.py|  18 ++
  contrib/gcc-changelog/test_email.py|   9 +
  contrib/gcc-changelog/test_patches.txt | 290 +
  3 files changed, 317 insertions(+)

diff --git a/contrib/gcc-changelog/git_commit.py 
b/contrib/gcc-changelog/git_commit.py
index 6f99d917b3b..a24a251d8f3 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -185,14 +185,32 @@ class ChangeLogEntry:
  @property
  def files(self):
  files = []
+
+# Whether the content currently processed is between a star prefix the
+# end of the file list: a colon or an open paren.
+in_location = False
+
  for line in self.lines:
+# If this line matches the star prefix, start the location
+# processing on the information that follows the star.
  m = star_prefix_regex.match(line)
  if m:
+in_location = True
  line = m.group('content')
+
+if in_location:
+# Strip everything that is not a filename in "line": entities
+# "(NAME)", entry text (the colon, if present, and anything
+# that follows it).
  if '(' in line:
  line = line[:line.index('(')]
+in_location = False
  if ':' in line:
  line = line[:line.index(':')]
+in_location = False
+
+# At this point, all that 's left is a list of filenames
+# separated by commas and whitespaces.
  for file in line.split(','):
  file = file.strip()
  if file:
diff --git a/contrib/gcc-changelog/test_email.py 
b/contrib/gcc-changelog/test_email.py
index 1379502e755..3d2c8ff2412 100755
--- a/contrib/gcc-changelog/test_email.py
+++ b/contrib/gcc-changelog/test_email.py
@@ -286,3 +286,12 @@ class TestGccChangelog(unittest.TestCase):
  email = self.from_patch_glob('0001-Update-merge.sh-to-reflect.patch')
  assert (email.changelog_entries[0].lines[0]
  == '\t* LOCAL_PATCHES: Use git hash instead of SVN id.')
+
+def test_multiline_file_list(self):
+email = self.from_patch_glob(
+'0001-Ada-Reuse-Is_Package_Or_Generic_Package-where-possib.patch')
+assert (email.changelog_entries[0].files
+== ['contracts.adb', 'einfo.adb', 'exp_ch9.adb',
+'sem_ch12.adb', 'sem_ch4.adb', 'sem_ch7.adb',
+'sem_ch8.adb', 'sem_elab.adb', 'sem_type.adb',
+'sem_util.adb'])
diff --git a/contrib/gcc-changelog/test_patches.txt 
b/contrib/gcc-changelog/test_patches.txt
index 84d4b81d818..3492fb4dcb8 100644
--- a/contrib/gcc-changelog/test_patches.txt
+++ b/contrib/gcc-changelog/test_patches.txt
@@ -2650,4 +2650,294 @@ index dfa7bf3d196..3f4f1629a22 100755
   
  --

  2.26.2
+=== 0001-Ada-Reuse-Is_Package_Or_Generic_Package-where-possib.patch ===
+From 557b268fdeb0980a17411f458eee333f55c6 Mon Sep 17 00:00:00 2001
+From: Piotr Trojanek 
+Date: Thu, 12 Dec 2019 11:45:24 +0100
+Subject: [PATCH] [Ada] Reuse Is_Package_Or_Generic_Package where possible
+
+2020-05-26  Piotr Trojanek  
+
+gcc/ada/
+
+   * contracts.adb, einfo.adb, exp_ch9.adb, sem_ch12.adb,
+   sem_ch4.adb, sem_ch7.adb, sem_ch8.adb, sem_elab.adb,
+   sem_type.adb, sem_util.adb: Reuse Is_Package_Or_Generic_Package
+   where possible (similarly, reuse Is_Concurrent_Type if it was
+   possible in the same expressions).
+---
+ gcc/ada/contracts.adb |  2 +-
+ gcc/ada/einfo.adb | 22 +++---
+ gcc/ada/exp_ch9.adb   |  2 +-
+ gcc/ada/sem_ch12.adb  |  2 +-
+ gcc/ada/sem_ch4.adb   |  2 +-
+ gcc/ada/sem_ch7.adb   |  6 +++---
+ gcc/ada/sem_ch8.adb   |  6 +++---
+ gcc/ada/sem_elab.adb  |  2 +-
+ gcc/ada/sem_type.adb  |  2 +-
+ gcc/ada/sem_util.adb  |  6 +++---
+ 10 files changed, 26 insertions(+), 26 deletions(-)
+
+diff --git a/gcc/ada/contracts.adb b/gcc/ada/contracts.adb
+index 981bb91..d58f136 100644
+--- a/gcc/ada/contracts.adb
 b/gcc/ada/contracts.adb
+@@ -213,7 +213,7 @@ package body Contracts is
+   --Initializes
+   --Part_Of (instantiation only)
+
+-  elsif Ekind_In (Id, E_Generic_Package, E_Packag

[committed] jit: fix sphinx formatting issues in docs

[David Malcolm via Gcc-patches]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as 0981cf960d07752f9844a2f2799fbc85a7f1efd8.

gcc/jit/ChangeLog:
* docs/topics/compatibility.rst: Fix underline.
Fix missing labels.
* docs/topics/types.rst: Fix missing blank line.
* docs/_build/texinfo/Makefile: Regenerate.
* docs/_build/texinfo/libgccjit.texi: Regenerate.
---
 gcc/jit/docs/topics/compatibility.rst | 6 +-
 gcc/jit/docs/topics/types.rst | 1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/gcc/jit/docs/topics/compatibility.rst 
b/gcc/jit/docs/topics/compatibility.rst
index 0c0ce070d72..bb3387fa583 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -62,7 +62,7 @@ You can see the symbol tags provided by libgccjit.so using 
``objdump``:
[...snip...]
 
 Programmatically checking version
-***
+*
 
 Client code can programmatically check libgccjit version using:
 
@@ -200,11 +200,15 @@ entrypoints:
 ``LIBGCCJIT_ABI_11`` covers the addition of
 :func:`gcc_jit_context_add_driver_option`
 
+.. _LIBGCCJIT_ABI_12:
+
 ``LIBGCCJIT_ABI_12``
 
 ``LIBGCCJIT_ABI_12`` covers the addition of
 :func:`gcc_jit_context_new_bitfield`
 
+.. _LIBGCCJIT_ABI_13:
+
 ``LIBGCCJIT_ABI_13``
 
 ``LIBGCCJIT_ABI_13`` covers the addition of version functions via API
diff --git a/gcc/jit/docs/topics/types.rst b/gcc/jit/docs/topics/types.rst
index ea7c8ff4542..e508a6bed0d 100644
--- a/gcc/jit/docs/topics/types.rst
+++ b/gcc/jit/docs/topics/types.rst
@@ -269,6 +269,7 @@ You can model C `struct` types by creating 
:c:type:`gcc_jit_struct *` and
 
This API entrypoint was added in :ref:`LIBGCCJIT_ABI_12`; you can test
for its presence using
+
.. code-block:: c
 
   #ifdef LIBGCCJIT_HAVE_gcc_jit_context_new_bitfield
-- 
2.21.0

Re: [PATCH PR94026] combine missed opportunity to simplify comparisons with zero

[Segher Boessenkool]

Hi!

On Tue, May 26, 2020 at 03:45:05AM +, Yangfei (Felix) wrote:
> > > I am using Outlook and I didn't find the place to change the MIME type
> > > : - (
> > 
> > The simplest option is to use a different email client, one that plays 
> > nicely
> > with others.  You use git, maybe you could even use git-send-email?
> 
> The bad news is that it would be hard to switch to a different email client 
> with my company's IT policy  :-( 
> But I think I can ask IT if that is possible. Sorry for the trouble.

Yes, please try to get this sorted somehow.  Maybe you can ask other
people in your company that have this same problem?

> > > +   new_rtx = gen_rtx_AND (mode, new_rtx,
> > > +  gen_int_mode (mask << real_pos, mode));
> > > + }
> > 
> > So this changes
> >   ((X >> C) & M) == ...
> > to
> >   (X & (M << C)) == ...
> > ?
> > 
> > Where then does it check what ... is?  This is only valid like this if that 
> > is zero.
> > 
> > Why should this go in combine and not in simplify-rtx instead?
> 
> True.  This is only valid when ... is zero.
> That's why we need the "&& equality_comparison " condition here.

But that doesn't test if the other side of the comparison is 0.

> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.dg/pr94026.c
> > > @@ -0,0 +1,21 @@
> > > +/* { dg-do compile { target aarch64*-*-* i?86-*-* x86_64-*-* } } */
> > 
> > Why restrict this to only some targets?
> 
> That's because I only have these targets for verification.
> But I think this can work on other targets.  Removed from the v4 patch.
> Could you please help check the other ports?

In general, you should never restrict anything to some targets simply
because you haven't tested it on other targets.

If it is a good test it will just work on those other targets.  Traffic
on gcc-testresults@ will show you if it actually does.

> > > +/* { dg-options "-O2 -fdump-rtl-combine" } */
> > > +
> > > +int
> > > +foo (int c)
> > > +{
> > > +  int a = (c >> 8) & 7;
> > > +
> > > +  if (a >= 2) {
> > > +return 1;
> > > +  }
> > > +
> > > +  return 0;
> > > +}
> > > +
> > > +/* The combine phase should transform (compare (and (lshiftrt x 8) 6) 0)
> > > +   to (compare (and (x 1536)) 0). We look for the *attempt* to match this
> > > +   RTL pattern, regardless of whether an actual insn may be found on the
> > > +   platform.  */
> > > +
> > > +/* { dg-final { scan-rtl-dump "\\(const_int 1536" "combine" } } */
> > 
> > That is a very fragile test.
> 
> For this specific test case, (const_int 1536) is calculated from 
> subexpression (M << C) in (X & (M << C)).
> I also see some similar checkings in gcc.dg/asr_div1.c.  Suggesions?

Maybe it is better to test that the non-optimal code you saw before is
not generated anymore?  That could be a target-specific test of course.
The advantage is that the test will not break for all kinds of unrelated
reasons (like this test) -- that simply does not scale with the number
of tests we have.


Segher

Re: New mklog script

[Martin Sebor via Gcc-patches]

On 5/26/20 7:14 AM, Martin Liška wrote:

On 5/26/20 3:11 PM, Richard Earnshaw wrote:

On 26/05/2020 14:09, Martin Liška wrote:

On 5/26/20 1:18 PM, Richard Earnshaw wrote:

On 26/05/2020 12:14, Martin Liška wrote:

On 5/26/20 12:23 PM, Richard Earnshaw wrote:
I thought we had a convention that aliases we added were prefixed 
with

'gcc-'?  This seems to go against that.


You are right, but this one is so handy ;)
What name do you suggest?

Martin


gcc-ci?


What the abbreviation stands for?

Martin



R.





CheckIn

For those who come from the SVN days where ci was the standard
abbreviation for committing :-)


Ah, I see. Anyway, I prefer the original name even though it violates
the naming policy.

Let other express their preferences (Jason?).


Personally I struggle to keep track of all the different command
and function names (e.g., in GCC) and what they do.  I find
consistent names and behaviors helpful (and conversely,
inconsistencies trip me up time and time again).  So if/since there
is a convention to prefix gcc Git commands with gcc- I would prefer
to use it consistently, even if shorter names might seem nicer or
more convenient.  We don't check things in so often that typing
a few extra characters should be a burden.

By the way, it's nice that the existing gcc- aliases are documented
on https://gcc.gnu.org/gitwrite.html.  I would suggest to add this
one there as well.

Martin

Re: [Patch][OpenMP] Fix mapping of artificial variables (PR94874)

[Jakub Jelinek via Gcc-patches]

On Tue, May 26, 2020 at 04:06:04PM +0200, Jakub Jelinek wrote:
> On Mon, May 25, 2020 at 07:10:31PM +0200, Tobias Burnus wrote:
> > +enum omp_clause_defaultmap_kind
> > +cxx_omp_predetermined_mapping (tree decl)
> > +{
> > +  enum omp_clause_default_kind ret = cxx_omp_predetermined_sharing_1 
> > (decl);
> > +  if (ret != OMP_CLAUSE_DEFAULT_UNSPECIFIED)
> > +return OMP_CLAUSE_DEFAULTMAP_TO;
> 
> I don't like the above 3 lines, do you need it for anything?
> Static data members certainly aren't covered and it is unlikely we want to
> predetermine them mapped.

And forgot, for this the behavior is already specified in 5.0 that any
reference to this should result in map(tofrom:this[:1]).
It is not implemented yet, but we'll need to implement it some other way
than through this hook.

Jakub

Re: [PATCH 1/2] gcc-changelog: remove file descriptor leaks

[Pierre-Marie de Rodat]

On 26/05/2020 17:04, Martin Liška wrote:

Oh, that's new for me. I've never seen the warning.

Please install the patch.
That was the first time I saw it as well. :-) I just pushed the commit 
on master.


--
Pierre-Marie de Rodat

Re: [PATCH 2/2] gcc-changelog: handle entries with multi-line file lists

[Pierre-Marie de Rodat]

On 26/05/2020 17:06, Martin Liška wrote:
That was simpler than I expected ;) I compared results for all 2000 
patches since

we switched to git and there are no changes!


Ah, nice! Thank you for double-checking: I only ran the unit tests on my 
side.



+diff --git a/gcc/ada/contracts.adb b/gcc/ada/contracts.adb
+index 981bb91..d58f136 100644
+--- a/gcc/ada/contracts.adb
 b/gcc/ada/contracts.adb
+@@ -213,7 +213,7 @@ package body Contracts is
+   --    Initializes
+   --    Part_Of (instantiation only)
+
+-  elsif Ekind_In (Id, E_Generic_Package, E_Package) then
++  elsif Is_Package_Or_Generic_Package (Id) then
+  if Nam_In (Prag_Nam, Name_Abstract_State,
+   Name_Initial_Condition,
+   Name_Initializes)


The only nit: please replace it with:
@@ -1 +1,2 @@

+

in order to shrink the file.

Please install it with the change.


Done and pushed. Thank you for the quick review!

--
Pierre-Marie de Rodat

Re: [PATCH PR95254] aarch64: gcc generate inefficient code with fixed sve vector length

[Richard Sandiford]

Sorry for the slow reply, was off for a few days.

I think the new code ought to happen earlier in emit_move_insn, before:

  if (CONSTANT_P (y))
{

That way, all the canonicalisation happens on the mode we actually
want the move to have.

"Yangfei (Felix)"  writes:
> diff --git a/gcc/expr.c b/gcc/expr.c
> index dfbeae71518..4442fb83367 100644
> --- a/gcc/expr.c
> +++ b/gcc/expr.c
> @@ -3852,6 +3852,62 @@ emit_move_insn (rtx x, rtx y)
>  
>gcc_assert (mode != BLKmode);
>  
> +  rtx x_inner = NULL_RTX;
> +  rtx y_inner = NULL_RTX;
> +  machine_mode x_inner_mode, y_inner_mode;
> +
> +  if (SUBREG_P (x)
> +  && REG_P (SUBREG_REG (x))
> +  && known_eq (SUBREG_BYTE (x), 0))
> +{
> +  x_inner = SUBREG_REG (x);
> +  x_inner_mode = GET_MODE (x_inner);
> +}
> +  if (SUBREG_P (y)
> +  && REG_P (SUBREG_REG (y))
> +  && known_eq (SUBREG_BYTE (y), 0))
> +{
> +  y_inner = SUBREG_REG (y);
> +  y_inner_mode = GET_MODE (y_inner);
> +}

The later code is only interested in SUBREG_REGs that are the same size
as "mode", so I think it would make sense to check that in the "if"s
above instead of checking SUBREG_BYTE.  (SUBREG_BYTE is always zero
when the modes are the same size, but the reverse is not true.)

It might also be better to avoid [xy]_inner_mode and just use GET_MODE
where necessary.

It would be good to have a block comment above the code to explain
what we're doing.

> +  if (x_inner != NULL_RTX
> +  && y_inner != NULL_RTX
> +  && x_inner_mode == y_inner_mode
> +  && known_eq (GET_MODE_SIZE (x_inner_mode), GET_MODE_SIZE (mode))
> +  && ! targetm.can_change_mode_class (x_inner_mode, mode, ALL_REGS))
> +{
> +  x = x_inner;
> +  y = y_inner;
> +}
> +  else if (x_inner != NULL_RTX && CONSTANT_P (y)

Formatting nit: one subcondition per line when the condition spans
multiple lines.

> +&& known_eq (GET_MODE_SIZE (x_inner_mode), GET_MODE_SIZE (mode))
> +&& ! targetm.can_change_mode_class (x_inner_mode, mode, ALL_REGS)
> +&& targetm.legitimate_constant_p (x_inner_mode, y))

This call isn't valid, since the mode has to match the rtx.  ("y" still
has mode "mode" at this point.)  I think instead we should just do:

   && (y_inner = simplify_subreg (GET_MODE (x_inner), y, mode, 0))

to convert the constant, and use it if the result is nonnull.
The existing CONSTANT_P emit_move_insn code will handle cases
in which the new constant isn't legitimate.

> +
> +{
> +  x = x_inner;
> +}
> +  else if (x_inner != NULL_RTX && MEM_P (y)
> +&& known_eq (GET_MODE_SIZE (x_inner_mode), GET_MODE_SIZE (mode))
> +&& ! targetm.can_change_mode_class (x_inner_mode, mode, ALL_REGS)
> +&& (! targetm.slow_unaligned_access (x_inner_mode, MEM_ALIGN (y))
> +|| MEM_ALIGN (y) >= GET_MODE_ALIGNMENT (x_inner_mode)))

What is the last condition protecting against?  Seems worth a comment.

Thanks,
Richard

Re: [LTO/offloading] Fix offloading-compilation ICE without -flto (PR84320)

[Richard Biener]

On May 26, 2020 3:55:01 PM GMT+02:00, Tobias Burnus  
wrote:
>LTO stream out not only happens with LTO (-flto) but also for
>the offloaded functions with OpenMP/OpenACC.
>
>Without using -flto, this leads to an ICE as a recent patch
>(r11-525-g03d90a20a1afcbb9c30da8d4adf4922b0685061f) added the
>check to DFS::DFS (lto-streamer-out.c:639):
>if (ob->local_trees && local_tree_p (expr))
>where local_tree_p calls odr_type_t.
>
>And the latter that contains the following assert, which fails:
>
> /* We do not have this information when not in LTO, but we do not need
>  to care, since it is used only for type merging.  */
>   gcc_checking_assert (in_lto_p || flag_lto);
>
>Adding 'in_lto_p &&' before the 'odr_type_t (t) &&' in local_tree_p
>works for offloading but this causes an ICE:
>FAIL: g++.dg/asan/pr85774.C   -O2 -flto -fno-use-linker-plugin
>-flto-partition=none  (internal compiler error)
>lto1: internal compiler error: in unify_scc, at lto/lto-common.c:1678
>
>Hence, the simple solution is to add flag_generate_offload to the
>assert, which this patch does.
>
>OK for the trunk?

OK. 

Richard. 

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

[PATCH] RS6000 Add testlsbb (Test LSB by Byte) operations

[will schmidt via Gcc-patches]

Hi,

  Add support for new instructions to test LSB by Byte.

  Tested on powerpc64le-unknown-linux-gnu with no
  regressions.  (power7BE, power8LE, power8BE, power9LE).

[gcc]

2020-05-26  Will Schmidt  

* config/rs6000/altivec.h (vec_test_lsbb_all_ones): New define.
(vec_test_lsbb_all_zeros): New define.
* config/rs6000/rs6000-builtin.def (BU_FUTURE_VSX_1): New built-in
handling macro.  (XVTLSBB_ZEROS, XVTLSBB_ONES) New builtin defines.
(xvtlsbb_zeros, xvtlsbb_ones) New builtin overloads.
* config/rs6000/rs6000-call.c (FUTURE_BUILTIN_VEC_XVTLSBB_ZEROS,
FUTURE_BUILTIN_VEC_XVTLSBB_ONES): New altivec_builtin_types entries.
* config/rs6000/rs6000.md (UNSPEC_XVTLSBB):  New unspec.
* config/rs6000/vsx.md (*xvtlsbb_internal): New instruction define.
(xvtlsbbo, xvtlsbbz): New instruction expands.

[testsuite]

2020-05-26  Will Schmidt  

* testsuite/gcc.target/powerpc/lsbb-runnable.c: New test.
* testsuite/gcc.target/powerpc/lsbb.c: New test.



diff --git a/gcc/config/rs6000/altivec.h b/gcc/config/rs6000/altivec.h
index 0a7e8ab..94afaf7 100644
--- a/gcc/config/rs6000/altivec.h
+++ b/gcc/config/rs6000/altivec.h
@@ -490,10 +490,13 @@
 #define vec_cmpnez __builtin_vec_vcmpnez
 
 #define vec_cntlz_lsbb __builtin_vec_vclzlsbb
 #define vec_cnttz_lsbb __builtin_vec_vctzlsbb
 
+#define vec_test_lsbb_all_ones __builtin_vec_xvtlsbb_ones
+#define vec_test_lsbb_all_zeros __builtin_vec_xvtlsbb_zeros
+
 #define vec_xlx __builtin_vec_vextulx
 #define vec_xrx __builtin_vec_vexturx
 #endif
 
 /* Predicates.
diff --git a/gcc/config/rs6000/rs6000-builtin.def 
b/gcc/config/rs6000/rs6000-builtin.def
index 8b1ddb0..e149c5a 100644
--- a/gcc/config/rs6000/rs6000-builtin.def
+++ b/gcc/config/rs6000/rs6000-builtin.def
@@ -956,10 +956,18 @@
RS6000_BTM_FUTURE,  /* MASK */  \
(RS6000_BTC_ ## ATTR/* ATTR */  \
 | RS6000_BTC_UNARY),   \
CODE_FOR_ ## ICODE) /* ICODE */
 
+#define BU_FUTURE_VSX_1(ENUM, NAME, ATTR, ICODE)   \
+  RS6000_BUILTIN_1 (FUTURE_BUILTIN_ ## ENUM,   /* ENUM */  \
+   "__builtin_vsx_" NAME,  /* NAME */  \
+   RS6000_BTM_FUTURE,  /* MASK */  \
+   (RS6000_BTC_ ## ATTR/* ATTR */  \
+| RS6000_BTC_UNARY),   \
+   CODE_FOR_ ## ICODE) /* ICODE */
+
 #define BU_FUTURE_V_2(ENUM, NAME, ATTR, ICODE) \
   RS6000_BUILTIN_2 (FUTURE_BUILTIN_ ## ENUM,   /* ENUM */  \
"__builtin_altivec_" NAME,  /* NAME */  \
RS6000_BTM_FUTURE,  /* MASK */  \
(RS6000_BTC_ ## ATTR/* ATTR */  \
@@ -2635,10 +2643,13 @@ BU_FUTURE_V_1 (VSTRIHL, "vstrihl", CONST, vstril_v8hi)
 BU_FUTURE_V_1 (VSTRIBR_P, "vstribr_p", CONST, vstrir_p_v16qi)
 BU_FUTURE_V_1 (VSTRIHR_P, "vstrihr_p", CONST, vstrir_p_v8hi)
 BU_FUTURE_V_1 (VSTRIBL_P, "vstribl_p", CONST, vstril_p_v16qi)
 BU_FUTURE_V_1 (VSTRIHL_P, "vstrihl_p", CONST, vstril_p_v8hi)
 
+BU_FUTURE_VSX_1 (XVTLSBB_ZEROS,  "xvtlsbb_zeros", CONST, xvtlsbbz)
+BU_FUTURE_VSX_1 (XVTLSBB_ONES,   "xvtlsbb_ones", CONST, xvtlsbbo)
+
 /* Future architecture overloaded vector built-ins.  */
 BU_FUTURE_OVERLOAD_2 (CLRL, "clrl")
 BU_FUTURE_OVERLOAD_2 (CLRR, "clrr")
 BU_FUTURE_OVERLOAD_2 (GNB, "gnb")
 BU_FUTURE_OVERLOAD_4 (XXEVAL, "xxeval")
@@ -2650,10 +2661,13 @@ BU_FUTURE_OVERLOAD_3 (EXTRACTH, "extracth")
 BU_FUTURE_OVERLOAD_1 (VSTRIR, "strir")
 BU_FUTURE_OVERLOAD_1 (VSTRIL, "stril")
 
 BU_FUTURE_OVERLOAD_1 (VSTRIR_P, "strir_p")
 BU_FUTURE_OVERLOAD_1 (VSTRIL_P, "stril_p")
+
+BU_FUTURE_OVERLOAD_1 (XVTLSBB_ZEROS, "xvtlsbb_zeros")
+BU_FUTURE_OVERLOAD_1 (XVTLSBB_ONES,  "xvtlsbb_ones")
 
 /* 1 argument crypto functions.  */
 BU_CRYPTO_1 (VSBOX,"vsbox",  CONST, crypto_vsbox_v2di)
 BU_CRYPTO_1 (VSBOX_BE, "vsbox_be",   CONST, crypto_vsbox_v16qi)
 
diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 0ac8054..f83167f 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -5616,10 +5616,15 @@ const struct altivec_builtin_types 
altivec_overloaded_builtins[] = {
   { FUTURE_BUILTIN_VEC_VSTRIR_P, FUTURE_BUILTIN_VSTRIHR_P,
 RS6000_BTI_INTSI, RS6000_BTI_unsigned_V8HI, 0, 0 },
   { FUTURE_BUILTIN_VEC_VSTRIR_P, FUTURE_BUILTIN_VSTRIHR_P,
 RS6000_BTI_INTSI, RS6000_BTI_V8HI, 0, 0 },
 
+ { FUTURE_BUILTIN_VEC_XVTLSBB_ZEROS, FUTURE_BUILTIN_XVTLSBB_ZEROS,
+RS6000_BTI_INTSI, RS6000_BTI_unsigned_V16QI, 0, 0},
+ { FUTURE_BUILTIN_VEC_XVTLSBB_ONES, FUTURE_BUILTIN_XVTLSBB_ONES,
+RS6000_BTI_INTSI, RS6000_BTI_unsigned_V16QI, 0, 0},
+
   { RS6000_BUILTIN_NONE, RS6000_BUILTIN_NONE, 0, 0, 0, 0 }
 };
 
 

Re: [PATCH] PR fortran/95089 - ICE in gfc_get_derived_type, at fortran/trans-types.c:2843

[Thomas Koenig via Gcc-patches]

Hi Harald,


Another rather obvious case of a buffer too small to hold a name-mangled symbol,
this time with coarrays enabled.

OK for master?


OK.

Thanks!

Re: PR libfortran/95195 - improve runtime error for namelist i/o to unformatted file

[Thomas Koenig via Gcc-patches]

Hello Harald,


Without the patch below, an attempted namelist write to an unformatted file -
which is prohibited by the standard - would generate the following runtime 
error:

At line 12 of file pr95195.f90 (unit = 10, file = 'test.dat')
Fortran runtime error: End of record

followed by some backtrace.  The patch attempts to generate an error pointing
the user to the real issue.

Regtested on x86_64-pc-linux-gnu.

OK for master?


OK, thanks for the patch!

Regards

Thomas

[committed] i386: Add SSE2 alternative to mmx_pswapd2vsi2

[Uros Bizjak via Gcc-patches]

2020-05-26  Uroš Bizjak  

gcc/ChangeLog:
* config/i386/mmx.md (mmx_pswapdv2si2): Add SSE2 alternative.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Uros.
diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index c31b4f81079..215162dedb5 100644
--- a/gcc/config/i386/mmx.md
+++ b/gcc/config/i386/mmx.md
@@ -2011,15 +2011,21 @@
(set_attr "mode" "TI")])
 
 (define_insn "mmx_pswapdv2si2"
-  [(set (match_operand:V2SI 0 "register_operand" "=y")
+  [(set (match_operand:V2SI 0 "register_operand" "=y,Yv")
(vec_select:V2SI
- (match_operand:V2SI 1 "nonimmediate_operand" "ym")
+ (match_operand:V2SI 1 "register_mmxmem_operand" "ym,Yv")
  (parallel [(const_int 1) (const_int 0)])))]
-  "TARGET_3DNOW_A"
-  "pswapd\t{%1, %0|%0, %1}"
-  [(set_attr "type" "mmxcvt")
-   (set_attr "prefix_extra" "1")
-   (set_attr "mode" "DI")])
+  "TARGET_3DNOW_A || TARGET_MMX_WITH_SSE"
+  "@
+   pswapd\t{%1, %0|%0, %1}
+   %vpshufd\t{$0xe1, %1, %0|%0, %1, 0xe1}";
+  [(set_attr "isa" "*,sse2")
+   (set_attr "mmx_isa" "native,*")
+   (set_attr "type" "mmxcvt,sselog1")
+   (set_attr "prefix_extra" "1,*")
+   (set_attr "prefix_data16" "*,1")
+   (set_attr "length_immediate" "*,1")
+   (set_attr "mode" "DI,TI")])
 
 (define_insn "*vec_dupv4hi"
   [(set (match_operand:V4HI 0 "register_operand" "=y,xYw")

Re: [PATCH] RS6000, add VSX mask manipulation support

[will schmidt via Gcc-patches]

On Fri, 2020-05-22 at 13:27 -0700, Carl Love wrote:
> GCC maintainers:
> 
> The following patch adds support for builtins
> vec_genbm(),  vec_genhm(),
> vec_genwm(), vec_gendm(), vec_genqm(), vec_cntm(), vec_expandm(),
> vec_extractm().  Support for instructions mtvsrbm, mtvsrhm, mtvsrwm,
> mtvsrdm, mtvsrqm, cntm, vexpandm, vextractm.
> 
> The test has been tested on:
> 
>   powerpc64le-unknown-linux-gnu (Power 9 LE)
> 
> and mambo with no regression errors.
> 
> Please let me know if this patch is acceptable for mainline.
> 
> Thanks.
> 
>Carl Love
> ---
> 
> RS6000 RFC 2629, add VSX mask manipulation support
> 
> gcc/ChangeLog
> 
> 2020-05-22  Carl Love  
> 
>   * config/rs6000/vsx.md  (VSX_MM): New define_mode_iterator.
>   (VSX_MM4): New define_mode_iterator.
>   (VSX_MM_SUFFIX4): New define_mode_attr.
>   (vec_mtvsrbm): New define_expand.
>   (vec_mtvsrbmi): New define_insn.
>   (vec_mtvsr_): New define_insn.
>   (vec_cntmb_): New define_insn.
>   (vec_extract_): New define_insn.
>   (vec_expand_): New define_insn.
>   (define_c_enum unspec): Add entries UNSPEC_MTVSBM, UNSPEC_VCNTMB,
>   UNSPEC_VEXTRACT, UNSPEC_VEXPAND.
>   * config/rs6000/altivec.h: Add defines vec_genbm, vec_genhm, vec_genwm,
>   vec_gendm, vec_genqm, vec_cntm, vec_expandm, vec_extractm.

Nit (?)  Name/symbol first.  i.e. 
(vec_genbm, vec_genhm,...) Add definitions.

>   * config/rs6000/rs6000-builtin.c: Add defines BU_FUTURE_2, BU_FUTURE_1.
>   (BU_FUTURE_1): Add definitions for mtvsrbm, mtvsrhm, mtvsrwm,
>   mtvsrdm, mtvsrqm, vexpandmb, vexpandmh, vexpandmw, vexpandmd, vexpandmq,
>   vextractmb, vextractmh, vextractmw, vextractmd, vextractmq.
>   (BU_FUTURE_2): Add definitions for cntmbb, cntmbh, cntmbw, cntmbd.
>   (BU_FUTURE_OVERLOAD_1): Add definitions for mtvsrbm, mtvsrhm,
>   mtvsrwm, mtvsrdm, mtvsrqm, vexpandm, vextractm.
>   (BU_FUTURE_OVERLOAD_2): Add defition for cntm.
>   * config/rs6000/rs6000-call.c (rs6000_expand_binop_builtin): Add
>   checks for CODE_FOR_vec_cntmbb_v16qi, CODE_FOR_vec_cntmb_v8hi,
>   CODE_FOR_vec_cntmb_v4si, CODE_FOR_vec_cntmb_v2di.
>   (altivec_overloaded_builtins): Add overloaded argument entries for
>   FUTURE_BUILTIN_VEC_MTVSRBM, FUTURE_BUILTIN_VEC_MTVSRHM, 
> FUTURE_BUILTIN_VEC_MTVSRWM,
>   FUTURE_BUILTIN_VEC_MTVSRDM, FUTURE_BUILTIN_VEC_MTVSRQM, 
> FUTURE_BUILTIN_VEC_VCNTMBB,
>   FUTURE_BUILTIN_VCNTMBB, FUTURE_BUILTIN_VCNTMBH, FUTURE_BUILTIN_VCNTMBW,
>   FUTURE_BUILTIN_VCNTMBD, FUTURE_BUILTIN_VEXPANDMB, 
> FUTURE_BUILTIN_VEXPANDMH,
>   FUTURE_BUILTIN_VEXPANDMW, FUTURE_BUILTIN_VEXPANDMD, 
> FUTURE_BUILTIN_VEXPANDMQ,

>   FUTURE_BUILTIN_VEXTRACTMB, FUTURE_BUILTIN_VEXTRACTMH, 
> FUTURE_BUILTIN_VEXTRACTMW,
>   FUTURE_BUILTIN_VEXTRACTMD, FUTURE_BUILTIN_VEXTRACTMQ.

>   (builtin_function_type): Add case entries for FUTURE_BUILTIN_MTVSRBM,
>   FUTURE_BUILTIN_MTVSRHM, FUTURE_BUILTIN_MTVSRWM, FUTURE_BUILTIN_MTVSRDM,
>   FUTURE_BUILTIN_MTVSRQM, FUTURE_BUILTIN_VCNTMBB, FUTURE_BUILTIN_VCNTMBH,
>   FUTURE_BUILTIN_VCNTMBW, FUTURE_BUILTIN_VCNTMBD, 
> FUTURE_BUILTIN_VEXPANDMB,
>   FUTURE_BUILTIN_VEXPANDMH, FUTURE_BUILTIN_VEXPANDMW, 
> FUTURE_BUILTIN_VEXPANDMD,
>   FUTURE_BUILTIN_VEXPANDMQ.
>   * config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Add entries
>   for MTVSRBM, MTVSRHM, MTVSRWM, MTVSRDM, MTVSRQM, VCNTM, VEXPANDM, 
> VEXTRACTM.

The rs6000-c.c reference here ^ doesn't exist below.  Looks like that
was moved to rs6000-builtin.def.



>   * testsuite/gcc.target/powerpc/vsx_mask-runnable.c:  Add runnable test 
> case.


> ---
>  gcc/config/rs6000/altivec.h   |  10 +
>  gcc/config/rs6000/rs6000-builtin.def  |  45 ++
>  gcc/config/rs6000/rs6000-call.c   |  66 +-
>  gcc/config/rs6000/vsx.md  |  67 ++
>  .../gcc.target/powerpc/vsx_mask-runnable.c| 614 ++



>  5 files changed, 801 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.target/powerpc/vsx_mask-runnable.c
> 
> diff --git a/gcc/config/rs6000/altivec.h b/gcc/config/rs6000/altivec.h
> index 0a7e8ab3647..5917d3a2b76 100644
> --- a/gcc/config/rs6000/altivec.h
> +++ b/gcc/config/rs6000/altivec.h
> @@ -710,6 +710,16 @@ __altivec_scalar_pred(vec_any_nle,
> 
>  #define vec_strir_p(a)   __builtin_vec_strir_p (a)
>  #define vec_stril_p(a)   __builtin_vec_stril_p (a)
> +
> +/* VSX Mask Manipulation builtin. */
> +#define vec_genbm __builtin_vec_mtvsrbm
> +#define vec_genhm __builtin_vec_mtvsrhm
> +#define vec_genwm __builtin_vec_mtvsrwm
> +#define vec_gendm __builtin_vec_mtvsrdm
> +#define vec_genqm __builtin_vec_mtvsrqm
> +#define vec_cntm __builtin_vec_cntm
> +#define vec_expandm __builtin_vec_vexpandm
> +#define vec_extractm __builtin_vec_vextractm
>  #endif

ok

> 
>  #endif /* _ALTIVEC_H */
> diff --git a/gc

Re: [PATCH 1/2] rs6000: tune cunroll for simple loops at O2

[Segher Boessenkool]

Hi!

On Tue, May 26, 2020 at 08:58:13AM +0200, Richard Biener wrote:
> On Mon, May 25, 2020 at 7:44 PM Segher Boessenkool
>  wrote:
> > Yes, cunroll does not have its own option, and that is a problem.  But
> > that is easy to fix!  Either with an option, or just with params (the
> > option wouldn't do more than set params anyway?)
> 
> Well, given coming up with different names for essentially the same
> transform is going to be challenging how about sth like
> 
> -funroll-loops={early,late,static,dynamic}[insert better names here]

User interface is hard :-)  I think luckily we don't need to change
anything there yet, just have an internal flag?

But complete unrolling is something quite different, so it should have
its own flag anyway (at least internally).

> note there's also -fpeel-loops which may match the transform
> done on GIMPLE better?

Peeling and unrolling are the same thing, if doing complete unrolling
(or complete peeling), followed by DCE in both cases.  Peeling is a
nicer name here I think, yeah.

> I'm not sure which are the technically
> correct terms for unrollings that elide the loop (the backedge).

I don't know a better term than "complete", I don't remember ever seeing
something else either.

> We're doing such kind of unrolling even if we cannot statically
> decide which of a set of possible exits we take (and internally
> call that peeling, if we can statically decide we call it complete
> unrolling).

"Peeling" is placing some copies of the loop before the loop;
"unrolling" is placing a few copies of the loop inside the loop body.
Does that match usage here?

> The RTL side OTOH only performs classical unrolling,
> preserving the backedge with various strategies for the
> remaining iterations.

And if you do complete unrolling that way, the backedge can be removed,
since it can be shown never to be taken.

> As said, for the regression on the 10 branch with ppc I'd add
> [a hidden] flag that controls the RTL unroller, also set by
> -funroll-loops and triggered by the ppc specific heuristics.

But the problem is in cunroll?  This is so backwards...  Because some
other transform abuses the unroller flags, adding a second level flag
with the same meaning :-(  It will work for fixing the regression,
sure, and it is slightly less code as well.


Segher

Re: [PATCH RFC] gcc-git: Add prepare-commit-msg hook.

[Jason Merrill via Gcc-patches]

On 5/26/20 3:12 AM, Martin Liška wrote:

Hi.

There's a small improvement. When filling up the ChangeLog entries,
I see it handy to open a patch in a separate window. I would use
GCC_DIFF_FILE env. variable for saving of the diff file.


It seems easy enough to execute the command yourself in another window, 
but I'm not opposed to the change.


Maybe these environment variables should start with GCC_GIT, not just 
GCC, to give more indication what they're for.


Jason

Re: New mklog script

[Jason Merrill via Gcc-patches]

On Tue, May 26, 2020 at 11:38 AM Martin Sebor  wrote:

> On 5/26/20 7:14 AM, Martin Liška wrote:
> > On 5/26/20 3:11 PM, Richard Earnshaw wrote:
> >> On 26/05/2020 14:09, Martin Liška wrote:
> >>> On 5/26/20 1:18 PM, Richard Earnshaw wrote:
>  On 26/05/2020 12:14, Martin Liška wrote:
> > On 5/26/20 12:23 PM, Richard Earnshaw wrote:
> >> I thought we had a convention that aliases we added were prefixed
> >> with 'gcc-'?  This seems to go against that.
> >
> > You are right, but this one is so handy ;)
> > What name do you suggest?
> 
>  gcc-ci?
> >>>
> >>> What the abbreviation stands for?
> >>
> >> CheckIn
> >>
> >> For those who come from the SVN days where ci was the standard
> >> abbreviation for committing :-)
> >
> > Ah, I see. Anyway, I prefer the original name even though it violates
> > the naming policy.
> >
> > Let other express their preferences (Jason?).
>

gcc-ci suggests that it should always be used for commits to gcc, which is
not my intent; the new alias is only used when you want to ask for a new
ChangeLog skeleton to be added.

gcc-ci-log would be better if you want something short; I'd prefer
gcc-commit-mklog, and let people define their own shorter aliases as
desired.


> Personally I struggle to keep track of all the different command
> and function names (e.g., in GCC) and what they do.  I find
> consistent names and behaviors helpful (and conversely,
> inconsistencies trip me up time and time again).  So if/since there
> is a convention to prefix gcc Git commands with gcc- I would prefer
> to use it consistently, even if shorter names might seem nicer or
> more convenient.  We don't check things in so often that typing
> a few extra characters should be a burden.
>

And people can always create their own aliases.


> By the way, it's nice that the existing gcc- aliases are documented
> on https://gcc.gnu.org/gitwrite.html.  I would suggest to add this
> one there as well.
>

Definitely.

Jason

Re: [PATCH] Port libgccjit to Windows.

[David Malcolm via Gcc-patches]

On Mon, 2020-05-25 at 16:48 -0300, Nicolas Bértolo wrote:

> Hi Dave,
> 
> Thanks for your feedback.
> 
> > Do you have copyright assignment paperwork on file?
> > https://gcc.gnu.org/contribute.html#legal
> 
> My paperwork is done.

Thanks.

Do you have commit/push access to the gcc repository?

> > The autotools are not my strongest suit.
> 
> > In a previous life I was a Windows developer, but I think it's been
> > about 18 years since I've done any coding on Windows, so I'm going to
> > have to trust your Windows expertise.
> 
> I guess the best solution would be to use libtool and Automake, but
> that require major changes in the GCC build system. I came up with a
> solution that uses an if statement to choose the way to build the
> dynamic library.

That sounds reasonable.

> > > It is not necessary to use --enable-host-shared in Windows (I tested
> > it),
> > > but I
> > > don't know the proper way to disable that check.
> 
> I used case statement to check the value of $(target).

BTW, why isn't it necessary to use --enable-host-shared in Windows?
Can we document that?

> > What's the issue with fchmod on Windows?  Does it not exist, or does it
> > not work?
> > Please add a comment explaining why.
> 
> fchmod does not exist in Windows.

Fair enough.

> > Please can you fix the indentation here to stay within 80 columns.
> > It looks like there's very similar (identical?) code to this below in
> > several places.
> > Can it be put in a subroutine to avoid repetition?
> 
> I created a new file "jit-w32.{h,c}" to store the definitions of
> win_mkdtemp() and print_last_error().

Thanks.  I like the idea of isolating the Windows-compatibility hooks
in one place.

> > Is there a cast to HMODULE everywhere that m_dso_handle is used?
> > If so, does it make the code cleaner if the field becomes an HMODULE on
> > Windows?
> 
> I added a new type "result::handle_t" that abstracts over this
> difference.

Thanks.

> > This seems like a very awkward way to get a temporary directory, but
> > perhaps it's the best that can be done on Windows?
> 
> We could copy an implementation of mkdtemp () for Windows or write
> something using a random number generator. I did it this way because
> it was the fastest.

Fastest in terms of developer time, as opposed to for the computer,
right?

> > Sorry if this seems excessively like nitpicking - thanks again for the
> > patch.
> 
> No problem.

On the subject of nitpicking, I find myself getting distracted by the 
indentation in the patch; there seem to be a lot of mismatches.

What editor are you using, and does it have options to
(a) show visible whitespace, and
(b) to apply a formatting convention?

I use Emacs, and it takes care of this for me.  I haven't used it, but
there's a contrib/clang-format file in the gcc source tree which
presumably describes GCC's coding conventions, if that helps for the
new code.

> Here is a new version.

Thanks.  More review comments inline below...

> Nico.
> 
> From a620c16adfadcebabd996a0b1d3761a582143ed7 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Nicol=C3=A1s=20B=C3=A9rtolo?= 
> Date: Fri, 22 May 2020 17:54:41 -0300
> Subject: [PATCH] Port libgccjit to Windows.
> 
> * configure: Regenerate.
> * configure.ac: Don't require --enable-host-shared when building for Mingw.
> * gcc/Makefile.in: don't look for libiberty in the "pic" subdirectory when
> building for Mingw. Add dependency on xgcc with the proper extension.
> * gcc/c/Make-lang.in: Remove extra slash.
> * gcc/jit/Make-lang.in: Remove extra slash. Build libgccjit.dll and its import
> library in Windows.
> * gcc/jit/jit-w32.h: New file.
> * gcc/jit/jit-w32.c (print_last_error): New function that prints the error
> string corresponding to GetLastError().
> (win_mkdtemp): Create a temporary directory using Windows APIs.
> * gcc/jit/jit-playback.c: Do not chmod files in Windows. Use LoadLibrary,
> FreeLibrary and GetProcAddress instead of libdl.
> * gcc/jit/jit-result.{h,c}: Introduce result::handle_t to abstract over the
> types used for dynamic library handles.
> * gcc/jit/jit-tempdir.c: Do not use mkdtemp() in Windows, use win_mkdtemp().
> ---
>  configure  |  32 +++--
>  configure.ac   |  32 +++--
>  gcc/Makefile.in|  10 ++--
>  gcc/c/Make-lang.in |   2 +-
>  gcc/jit/Make-lang.in   |  55 ++
>  gcc/jit/jit-playback.c |  24 --
>  gcc/jit/jit-result.c   |  39 +---
>  gcc/jit/jit-result.h   |  14 +-
>  gcc/jit/jit-tempdir.c  |  10 
>  gcc/jit/jit-w32.c  | 102 +
>  gcc/jit/jit-w32.h  |  30 
>  11 files changed, 300 insertions(+), 50 deletions(-)
>  create mode 100644 gcc/jit/jit-w32.c
>  create mode 100644 gcc/jit/jit-w32.h

[...snip...]

> diff --git a/configure.ac b/configure.ac
> index a67801371..edd963d3d 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2079,9 +2079,13 @@ if test -d ${srcdir}/gcc; then
>  esac
>  
>

[PATCH] gcc: xtensa: delegitimize UNSPEC_PLT

[Max Filippov via Gcc-patches]

This fixes 'non-delegitimized UNSPEC 3 found in variable location' notes
issued when building libraries which interferes with running tests.

2020-05-24  Max Filippov  
gcc/
* config/xtensa/xtensa.c (xtensa_delegitimize_address): New
function.
(TARGET_DELEGITIMIZE_ADDRESS): New macro.
---
 gcc/config/xtensa/xtensa.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/gcc/config/xtensa/xtensa.c b/gcc/config/xtensa/xtensa.c
index 5696951fb655..e3afb70cdf04 100644
--- a/gcc/config/xtensa/xtensa.c
+++ b/gcc/config/xtensa/xtensa.c
@@ -188,6 +188,8 @@ static bool xtensa_can_eliminate (const int from 
ATTRIBUTE_UNUSED,
 static HOST_WIDE_INT xtensa_starting_frame_offset (void);
 static unsigned HOST_WIDE_INT xtensa_asan_shadow_offset (void);
 
+static rtx xtensa_delegitimize_address (rtx);
+
 
 
 /* These hooks specify assembly directives for creating certain kinds
@@ -338,6 +340,9 @@ static unsigned HOST_WIDE_INT xtensa_asan_shadow_offset 
(void);
 #undef TARGET_HAVE_SPECULATION_SAFE_VALUE
 #define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
 
+#undef TARGET_DELEGITIMIZE_ADDRESS
+#define TARGET_DELEGITIMIZE_ADDRESS xtensa_delegitimize_address
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 
@@ -4440,4 +4445,23 @@ xtensa_asan_shadow_offset (void)
   return HOST_WIDE_INT_UC (0x1000);
 }
 
+static rtx
+xtensa_delegitimize_address (rtx op)
+{
+  switch (GET_CODE (op))
+{
+case CONST:
+  return xtensa_delegitimize_address (XEXP (op, 0));
+
+case UNSPEC:
+  if (XINT (op, 1) == UNSPEC_PLT)
+   return XVECEXP(op, 0, 0);
+  break;
+
+default:
+  break;
+}
+  return op;
+}
+
 #include "gt-xtensa.h"
-- 
2.20.1

Re: [PATCH] Add debug (slp_tree) and dump infrastructure for this

[David Malcolm via Gcc-patches]

On Mon, 2020-05-25 at 16:56 +0200, Richard Biener wrote:
> This adds an alternate debug_dump_context similar to the one for
> selftests but for interactive debugging routines.  This allows
> to share code between user-visible dumping via the dump_* API
> and those debugging routines.  The primary driver was SLP node
> dumping which wasn't accessible from inside a gdb session up to
> now.
> 
> Bootstrap & regtest running on x86_64-unknown-linux-gnu.
> 
> David, does this look OK?

Overall, seems sane to me; a couple of items inline below.

> Thanks,
> Richard.
> 
> 2020-05-25  Richard Biener  
> 
>   * dump-context.h (debug_dump_context): New class.
>   (dump_context): Make it friend.
>   * dumpfile.c (debug_dump_context::debug_dump_context):
>   Implement.
>   (debug_dump_context::~debug_dump_context): Likewise.
>   * tree-vect-slp.c: Include dump-context.h.
>   (vect_print_slp_tree): Dump a single SLP node.
>   (debug): New overload for slp_tree.
>   (vect_print_slp_graph): Rename from vect_print_slp_tree and
>   use that.
>   (vect_analyze_slp_instance): Adjust.
> ---
>  gcc/dump-context.h  | 19 ++
>  gcc/dumpfile.c  | 26 +
>  gcc/tree-vect-slp.c | 47 +
> 
>  3 files changed, 80 insertions(+), 12 deletions(-)
> 
> diff --git a/gcc/dump-context.h b/gcc/dump-context.h
> index 347477f331e..6d51eaf31ad 100644
> --- a/gcc/dump-context.h
> +++ b/gcc/dump-context.h
> @@ -29,6 +29,7 @@ along with GCC; see the file COPYING3.  If not see
>  
>  class optrecord_json_writer;
>  namespace selftest { class temp_dump_context; }
> +class debug_dump_context;
>  
>  /* A class for handling the various dump_* calls.
>  
> @@ -42,6 +43,7 @@ namespace selftest { class temp_dump_context; }
>  class dump_context
>  {
>friend class selftest::temp_dump_context;
> +  friend class debug_dump_context;
>  
>   public:
>static dump_context &get () { return *s_current; }
> @@ -195,6 +197,23 @@ private:
>auto_vec m_stashed_items;
>  };
>  
> +/* An RAII-style class for use in debug dumpers for temporarily
> using a
> +   different dump_context.  */
> +
> +class debug_dump_context

(Bikeshed Alert)  The name might be confusing in that this class isn't
a dump_context itself.  Some of our existing RAII classes have an
"auto_" prefix; would that be an idea?
Maybe "auto_dump_everything"???

But I don't have a strong objection to the name as-is.

[...snip...]


> diff --git a/gcc/dumpfile.c b/gcc/dumpfile.c
> index 54718784fd4..0c0c076d890 100644
> --- a/gcc/dumpfile.c
> +++ b/gcc/dumpfile.c
> @@ -2078,6 +2078,32 @@ enable_rtl_dump_file (void)
>return num_enabled > 0;
>  }
>  
> +/* debug_dump_context's ctor.  Temporarily override the dump_context
> +   (to forcibly enable output to stderr).  */
> +
> +debug_dump_context::debug_dump_context ()
> +: m_context (),
> +  m_saved (&dump_context::get ()),
> +  m_saved_flags (dump_flags),
> +  m_saved_file (dump_file)
> +{
> +  set_dump_file (stderr);
> +  dump_context::s_current = &m_context;
> +  pflags = dump_flags = MSG_ALL_KINDS | MSG_ALL_PRIORITIES;
> +  dump_context::get ().refresh_dumps_are_enabled ();
> +}
> +
> +/* debug_dump_context's dtor.  Restore the saved dump_context.  */
> +
> +debug_dump_context::~debug_dump_context ()
> +{
> +  set_dump_file (m_saved_file);
> +  dump_context::s_current = m_saved;
> +  pflags = dump_flags = m_saved_flags;
> +  dump_context::get ().refresh_dumps_are_enabled ();
> +}

I notice that the code saves dump_flags, and later restores both
dump_flags and pflags to the same value.  I'm a little hazy on this,
but is there any guarantee they had the same value?  Should the value
of pflags be saved separately from dump_flags?

[...snip...]


Hope this is constructive
Dave
 

[PATCH] libstdc++: Fix common_iterator::operator-> [PR95322]

[Patrick Palka via Gcc-patches]

This patch fixes the definition of common_iterator::operator-> when the
underlying iterator type's operator* returns a non-reference.

The first problem is that the class __detail::_Common_iter_proxy is used
unqualified.  Fixing that revealed another problem: the class's template
friend declaration of common_iterator doesn't match up with the
definition of common_iterator, because the friend declaration isn't
constrained.

If we try to make the friend declaration match up by adding constraints,
we run into frontend bug PR93467.  So we currently can't correctly
express this friend relation between __detail::_Common_iter_proxy and
common_iterator.

As a workaround to this frontend bug, this patch moves the definition of
_Common_iter_proxy into the class template of common_iterator so that we
could instead express the friend relation via the injected-class-name.

(This bug was found when attempting to use views::common to work around
the compile failure of the testcase in PR95322.)

Tested on x86_64-pc-linux-gnu, does this look OK to commit?

libstdc++-v3/ChangeLog:

PR libstdc++/95322
* include/bits/stl_iterator.h (__detail::_Common_iter_proxy):
Remove and redefine it ...
(common_iterator::_Proxy): ... here.
(common_iterator::operator->): Use it.
* testsuite/24_iterators/common_iterator/95322.cc: New test.
* testsuite/std/ranges/adaptors/95322.cc: New test.
---
 libstdc++-v3/include/bits/stl_iterator.h  | 34 +-
 .../24_iterators/common_iterator/2.cc | 63 +++
 .../testsuite/std/ranges/adaptors/95322.cc| 50 +++
 3 files changed, 129 insertions(+), 18 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/24_iterators/common_iterator/2.cc
 create mode 100644 libstdc++-v3/testsuite/std/ranges/adaptors/95322.cc

diff --git a/libstdc++-v3/include/bits/stl_iterator.h 
b/libstdc++-v3/include/bits/stl_iterator.h
index fdb1121f823..19b1d53f781 100644
--- a/libstdc++-v3/include/bits/stl_iterator.h
+++ b/libstdc++-v3/include/bits/stl_iterator.h
@@ -1568,23 +1568,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   namespace __detail
   {
-template
-  class _Common_iter_proxy
-  {
-   iter_value_t<_It> _M_keep;
-
-   _Common_iter_proxy(iter_reference_t<_It>&& __x)
-   : _M_keep(std::move(__x)) { }
-
-   template
- friend class common_iterator;
-
-  public:
-   const iter_value_t<_It>*
-   operator->() const
-   { return std::__addressof(_M_keep); }
-  };
-
 template
   concept __common_iter_has_arrow = indirectly_readable
&& (requires(const _It& __it) { __it.operator->(); }
@@ -1613,6 +1596,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _S_noexcept()
   { return _S_noexcept1<_It, _It2>() && _S_noexcept1<_Sent, _Sent2>(); }
 
+class _Proxy
+{
+  iter_value_t<_It> _M_keep;
+
+  _Proxy(iter_reference_t<_It>&& __x)
+  : _M_keep(std::move(__x)) { }
+
+  friend class common_iterator;
+
+public:
+  const iter_value_t<_It>*
+  operator->() const
+  { return std::__addressof(_M_keep); }
+};
+
   public:
 constexpr
 common_iterator()
@@ -1769,7 +1767,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  return std::__addressof(__tmp);
}
   else
-   return _Common_iter_proxy(*_M_it);
+   return _Proxy{*_M_it};
 }
 
 common_iterator&
diff --git a/libstdc++-v3/testsuite/24_iterators/common_iterator/2.cc 
b/libstdc++-v3/testsuite/24_iterators/common_iterator/2.cc
new file mode 100644
index 000..270e8eaa91c
--- /dev/null
+++ b/libstdc++-v3/testsuite/24_iterators/common_iterator/2.cc
@@ -0,0 +1,63 @@
+// Copyright (C) 2020 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-options "-std=gnu++2a" }
+// { dg-do run { target c++2a } }
+
+#include 
+#include 
+
+struct value { int n; };
+
+struct sentinel { int limit; };
+
+struct iterator
+{
+  using iterator_category = std::input_iterator_tag;
+  using value_type = value;
+  using difference_type = std::ptrdiff_t;
+  using reference = value;
+
+  value operator*() const { return value{counter}; }
+
+  iterator& operator++() { ++counter; return *this; }
+
+  iterator operator++(int) { auto i = *this; ++counter; return i; }
+
+  bool operator

[Patch, fortran] PR fortran/95331 - Unlimited polymorphic arrays have wrong bounds

[José Rui Faustino de Sousa via Gcc-patches]

Hi all!

Proposed patch to PR95331 - Unlimited polymorphic arrays have wrong bounds.

Patch tested only on x86_64-pc-linux-gnu.

When iterating over a class array use the bounds provided by the 
transformed descriptor (in sym->backend_decl) instead of the original 
bounds of the array (in the descriptor passed in the class _data) which 
are passed in se->expr.


The patch partially depends on the patch for PR52351 and PR85868, but 
does not seems to break anything by itself.


Not sure if this is the best solution, but at least it identifies the 
problem.


Thank you very much.

Best regards,
José Rui


2020-5-26  José Rui Faustino de Sousa  

 PR fortran/95331
 * trans-array.c (gfc_conv_array_ref): For class array dummy arguments
 use the transformed descriptor in sym->backend_decl instead of the
 original descriptor.

2020-5-26  José Rui Faustino de Sousa  

 PR fortran/95331
 * PR95331.f90: New test.

diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 434960c..f44a986 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -3672,8 +3672,12 @@ gfc_conv_array_ref (gfc_se * se, gfc_array_ref * ar, 
gfc_expr *expr,
}
 }
 
+  decl = se->expr;
+  if (IS_CLASS_ARRAY (sym) && sym->attr.dummy && ar->as->type != AS_DEFERRED)
+decl = sym->backend_decl;
+
   cst_offset = offset = gfc_index_zero_node;
-  add_to_offset (&cst_offset, &offset, gfc_conv_array_offset (se->expr));
+  add_to_offset (&cst_offset, &offset, gfc_conv_array_offset (decl));
 
   /* Calculate the offsets from all the dimensions.  Make sure to associate
  the final offset so that we form a chain of loop invariant summands.  */
@@ -3694,7 +3698,7 @@ gfc_conv_array_ref (gfc_se * se, gfc_array_ref * ar, 
gfc_expr *expr,
  indexse.expr = save_expr (indexse.expr);
 
  /* Lower bound.  */
- tmp = gfc_conv_array_lbound (se->expr, n);
+ tmp = gfc_conv_array_lbound (decl, n);
  if (sym->attr.temporary)
{
  gfc_init_se (&tmpse, se);
@@ -3718,7 +3722,7 @@ gfc_conv_array_ref (gfc_se * se, gfc_array_ref * ar, 
gfc_expr *expr,
 arrays.  */
  if (n < ar->dimen - 1 || ar->as->type != AS_ASSUMED_SIZE)
{
- tmp = gfc_conv_array_ubound (se->expr, n);
+ tmp = gfc_conv_array_ubound (decl, n);
  if (sym->attr.temporary)
{
  gfc_init_se (&tmpse, se);
@@ -3741,7 +3745,7 @@ gfc_conv_array_ref (gfc_se * se, gfc_array_ref * ar, 
gfc_expr *expr,
}
 
   /* Multiply the index by the stride.  */
-  stride = gfc_conv_array_stride (se->expr, n);
+  stride = gfc_conv_array_stride (decl, n);
   tmp = fold_build2_loc (input_location, MULT_EXPR, gfc_array_index_type,
 indexse.expr, stride);
 
@@ -3756,6 +3760,7 @@ gfc_conv_array_ref (gfc_se * se, gfc_array_ref * ar, 
gfc_expr *expr,
   /* A pointer array component can be detected from its field decl. Fix
  the descriptor, mark the resulting variable decl and pass it to
  build_array_ref.  */
+  decl = NULL_TREE;
   if (get_CFI_desc (sym, expr, &decl, ar))
 decl = build_fold_indirect_ref_loc (input_location, decl);
   if (!expr->ts.deferred && !sym->attr.codimension
diff --git a/gcc/testsuite/gfortran.dg/PR95331.f90 
b/gcc/testsuite/gfortran.dg/PR95331.f90
new file mode 100644
index 000..8024e79
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR95331.f90
@@ -0,0 +1,163 @@
+! { dg-do run }
+!
+! PR fortran/95331
+! 
+
+program main_p
+  
+  implicit none
+
+  integer, parameter :: n = 10
+  integer, parameter :: m = 5
+
+  integer, parameter :: b = 3
+  integer, parameter :: t = n+b-1
+  
+  integer, parameter :: l = 4
+  integer, parameter :: u = 7
+  integer, parameter :: s = 3
+  integer, parameter :: e = (u-l)/s+1
+  
+  call test_f()
+  call test_s()
+  call test_p()
+  call test_a()
+  stop
+
+contains
+
+  subroutine test_f()
+integer :: x(n,n)
+integer :: y(b:t)
+integer :: i
+
+x = reshape([(i, i=1,n*n)], [n,n])
+y = x(:,m)
+call sub_s(x(:,m), y, n)
+call sub_s(y, x(:,m), n)
+return
+  end subroutine test_f
+  
+  subroutine test_s()
+integer :: x(n,n)
+integer :: v(e)
+integer :: i
+
+x = reshape([(i, i=1,n*n)], [n,n])
+v = x(l:u:s,m)
+call sub_s(v, v, e)
+call sub_s(x(l:u:s,m), v, e)
+call sub_s(v, x(l:u:s,m), e)
+return
+  end subroutine test_s
+  
+  subroutine test_p()
+integer,  target :: x(n,n)
+integer, pointer :: p(:)
+integer  :: v(e)
+integer  :: i
+
+x = reshape([(i, i=1,n*n)], [n,n])
+v = x(l:u:s,m)
+p => x(:,m)
+call sub_s(p(l:u:s), v, e)
+p => x(l:u:s,m)
+call sub_s(p, v, e)
+p(l:) => x(l:u:s,m)
+call sub_s(p, v, e)
+p(l:l+e-1) => x(l:u:s,m)
+call sub_s(p, v, e)
+allocate(p(n))
+p(:) = x(:,m)
+call sub_s(p(l:u:s), v, e)
+deallocate(p)
+allocate(p(e))
+p(:

Re: [PATCH] libstdc++: Fix common_iterator::operator-> [PR95322]

[Jonathan Wakely via Gcc-patches]

On 26/05/20 15:18 -0400, Patrick Palka via Libstdc++ wrote:

This patch fixes the definition of common_iterator::operator-> when the
underlying iterator type's operator* returns a non-reference.

The first problem is that the class __detail::_Common_iter_proxy is used
unqualified.  Fixing that revealed another problem: the class's template
friend declaration of common_iterator doesn't match up with the
definition of common_iterator, because the friend declaration isn't
constrained.

If we try to make the friend declaration match up by adding constraints,
we run into frontend bug PR93467.  So we currently can't correctly
express this friend relation between __detail::_Common_iter_proxy and
common_iterator.

As a workaround to this frontend bug, this patch moves the definition of
_Common_iter_proxy into the class template of common_iterator so that we
could instead express the friend relation via the injected-class-name.


OK. I put it at namespace scope originally because it only depends on
the iterator not the sentinel, so we'd only instantiate it once for
common_iterator and common_iterator, but this is fine.


(This bug was found when attempting to use views::common to work around
the compile failure of the testcase in PR95322.)

Tested on x86_64-pc-linux-gnu, does this look OK to commit?


Yes, thanks. OK for gcc-10 too.

Please be aware of the new ChangeLog policies announced on the lists
recently.

[PATCH] PR fortran/95090 - ICE: identifier overflow

[Harald Anlauf]

Yet another obvious case of insufficient size of a temporary buffer.

OK for master?

Thanks,
Harald


PR fortran/95090 - ICE: identifier overflow

For long module name, derive type and component name, the generated
name-mangled symbol did not fit into a buffer when coarrays were
enabled.  Provide sufficiently large temporary.

2020-05-26  Harald Anlauf  

gcc/fortran/
PR fortran/95090
* iresolve.c (gfc_get_string): Enlarge temporary for
name-mangling.

gcc/testsuite/
PR fortran/95090
* gfortran.dg/pr95090.f90: New test.
diff --git a/gcc/fortran/iresolve.c b/gcc/fortran/iresolve.c
index 7ecb6595f59..df4f2265c58 100644
--- a/gcc/fortran/iresolve.c
+++ b/gcc/fortran/iresolve.c
@@ -47,7 +47,8 @@ along with GCC; see the file COPYING3.  If not see
 const char *
 gfc_get_string (const char *format, ...)
 {
-  char temp_name[128];
+  /* Provide sufficient space to hold "_F.caf_token__symbol_MOD_symbol".  */
+  char temp_name[14 + GFC_MAX_SYMBOL_LEN + 5 + GFC_MAX_SYMBOL_LEN + 1];
   const char *str;
   va_list ap;
   tree ident;
diff --git a/gcc/testsuite/gfortran.dg/pr95090.f90 b/gcc/testsuite/gfortran.dg/pr95090.f90
new file mode 100644
index 000..ec77802ec51
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr95090.f90
@@ -0,0 +1,19 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=lib -fsecond-underscore" }
+! PR fortran/95090 - ICE: identifier overflow
+
+module m2345678901234567890123456789012345678901234567890123456789_123
+  type t2345678901234567890123456789012345678901234567890123456789_123 &
+  (n2345678901234567890123456789012345678901234567890123456789_123)
+ integer, len :: n2345678901234567890123456789012345678901234567890123456789_123 = 8
+  end type
+  integer :: a2345678901234567890123456789012345678901234567890123456789_123
+  integer :: b2345678901234567890123456789012345678901234567890123456789_123(3)[*]
+  data b2345678901234567890123456789012345678901234567890123456789_123 /1,2,3/
+contains
+  subroutine s2345678901234567890123456789012345678901234567890123456789_123
+type(t2345678901234567890123456789012345678901234567890123456789_123 &
+(n2345678901234567890123456789012345678901234567890123456789_123)) :: &
+ z2345678901234567890123456789012345678901234567890123456789_123
+   end
+end

[PATCH, committed] [9/10/11 Regression] PR fortran/95104 - Segfault on a legal WAIT statement

[Harald Anlauf]

Committed as obvious.

The invalid NULL pointer dereference was discovered by Steve Kargl.

Will backport in a few days, when I figure out how to do it now.

Thanks,
Harald


PR fortran/95104 - Segfault on a legal WAIT statement

Referencing a unit in a WAIT statement that has not been opened before
resulted in a NULL pointer dereference.  Check for this condition.

2020-05-26  Harald Anlauf  

libgfortran/
PR libfortran/95104
* io/transfer.c (st_wait_async): Do not dereference NULL pointer.

gcc/testsuite/
PR libfortran/95104
* gfortran.dg/pr95104.f90: New test.

Co-Authored-By: Steven G. Kargl  

[committed] jit: fix missing types for builtins [PR 95306]

[David Malcolm via Gcc-patches]

PR jit/95306 reports that attempts to use builtins
__builtin_sadd_overflow" and "__builtin_memcpy" via
gcc_jit_context_get_builtin_function lead to inscrutable error
messages of the form:
  unimplemented primitive type for builtin: 42
and:
  unimplemented primitive type for builtin: 38

The root cause is that jit-builtins.c only implements a subset
of the types defined via DEF_PRIMITIVE_TYPE in builtin-types.def.

This patch:
- implements enough types to enable the above two builtins to be
  referenced
- documents gcc_jit_context_get_builtin_function, and notes the
  limitation that not all types are supported (supporting
  some of them would take a lot of extra work)
- improves the error message for the unsupported cases
- adds a testcase for __builtin_memcpy.  This required
  jit_langhook_global_bindings_p to be implemented (otherwise
  the assertion there failed deep inside "expand" on the builtin)
- adds test coverage for the above

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-647-gbf40f0ba95037f235b007a55a7682646a0578b26.

gcc/jit/ChangeLog:
PR jit/95306
* docs/topics/functions.rst
(gcc_jit_context_get_builtin_function): Document.
* docs/_build/texinfo/libgccjit.texi: Regenerate.
* dummy-frontend.c (jit_langhook_global_bindings_p): Remove
gcc_unreachable.
* jit-builtins.c (type_names): New array.
(get_string_for_type_id): New function.
(gcc::jit::builtins_manager::make_primitive_type): Show name of
type in error messages.  Update cases to reflect the order in
builtin-types.def.  Implement cases for BT_INT8, BT_INT16,
BT_UINT8, BT_CONST_PTR, BT_VOLATILE_PTR, BT_INT_PTR, BT_FLOAT_PTR,
BT_CONST_DOUBLE_PTR, BT_SIZE, BT_CONST_SIZE.

gcc/testsuite/ChangeLog:
PR jit/95306
* jit.dg/all-non-failing-tests.h: Add test-builtin-memcpy.c and
test-pr95306-builtin-types.c.
* jit.dg/test-builtin-memcpy.c: New test.
* 
jit.dg/test-error-gcc_jit_context_get_builtin_function-unimplemented-type.c:
New test.
* jit.dg/test-pr95306-builtin-types.c: New test.
---
 gcc/jit/docs/topics/functions.rst |  15 +++
 gcc/jit/dummy-frontend.c  |   1 -
 gcc/jit/jit-builtins.c| 122 --
 gcc/testsuite/jit.dg/all-non-failing-tests.h  |  20 +++
 gcc/testsuite/jit.dg/test-builtin-memcpy.c|  69 ++
 ..._get_builtin_function-unimplemented-type.c |  20 +++
 .../jit.dg/test-pr95306-builtin-types.c   |  22 
 7 files changed, 259 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/jit.dg/test-builtin-memcpy.c
 create mode 100644 
gcc/testsuite/jit.dg/test-error-gcc_jit_context_get_builtin_function-unimplemented-type.c
 create mode 100644 gcc/testsuite/jit.dg/test-pr95306-builtin-types.c

diff --git a/gcc/jit/docs/topics/functions.rst 
b/gcc/jit/docs/topics/functions.rst
index 29ce96c1e56..eb40d64010e 100644
--- a/gcc/jit/docs/topics/functions.rst
+++ b/gcc/jit/docs/topics/functions.rst
@@ -125,6 +125,21 @@ Functions
gcc_jit_context_get_builtin_function (gcc_jit_context *ctxt,\
  const char *name)
 
+   Get the :type:`gcc_jit_function` for the built-in function with the
+   given name.  For example:
+
+   .. code-block:: c
+
+  gcc_jit_function *fn
+= gcc_jit_context_get_builtin_function (ctxt, "__builtin_memcpy");
+
+   .. note:: Due to technical limitations with how libgccjit interacts with
+  the insides of GCC, not all built-in functions are supported.  More
+  precisely, not all types are supported for parameters of built-in
+  functions from libgccjit.  Attempts to get a built-in function that
+  uses such a parameter will lead to an error being emitted within
+  the context.
+
 .. function::  gcc_jit_object *\
gcc_jit_function_as_object (gcc_jit_function *func)
 
diff --git a/gcc/jit/dummy-frontend.c b/gcc/jit/dummy-frontend.c
index 956ba625164..27fe9d3db96 100644
--- a/gcc/jit/dummy-frontend.c
+++ b/gcc/jit/dummy-frontend.c
@@ -230,7 +230,6 @@ jit_langhook_builtin_function (tree decl)
 static bool
 jit_langhook_global_bindings_p (void)
 {
-  gcc_unreachable ();
   return true;
 }
 
diff --git a/gcc/jit/jit-builtins.c b/gcc/jit/jit-builtins.c
index 2ea298b4415..4842ff3ea96 100644
--- a/gcc/jit/jit-builtins.c
+++ b/gcc/jit/jit-builtins.c
@@ -245,6 +245,85 @@ builtins_manager::make_builtin_function (enum 
built_in_function builtin_id)
   return result;
 }
 
+/* Build an array of type names for use by get_string_for_type_id.  */
+
+static const char * const type_names[] = {
+#define DEF_PRIMITIVE_TYPE(ENUM, VALUE) #ENUM,
+#define DEF_FUNCTION_TYPE_0(ENUM, RETURN) #ENUM,
+#define DEF_FUNCTION_TYPE_1(ENUM, RETURN, ARG1) #ENUM,
+#define DEF_FUNCTION_TYPE_2(ENUM, RETURN, ARG1, ARG2) #ENUM,
+#define DEF_FUNCTION_TYPE_3(ENUM, RETURN, ARG

Re: [PATCH 0/7] Support vector load/store with length

[Jim Wilson]

On Tue, May 26, 2020 at 12:12 AM Richard Biener  wrote:
> From a look at the series description below you seem to add a new way
> of doing loads for this.  Did you review other ISAs (those I'm not
> familiar with myself too much are SVE, RISC-V and GCN) in GCC whether
> they have similar support and whether your approach can be supported
> there?  ISTR SVE must have some similar support - what's the reason
> you do not piggy-back on that?

There isn't any RISC-V Vector support in GCC yet.  The RVV spec is
still in draft and still occasionally changing in incompatible ways.
We've done some experimenting with gcc patches, but all we have are
intrinsics.  We haven't implemented any auto vectorization support, so
we haven't defined tree representations for anything yet, other than
the types we need for intrinsics support.  But if it looks OK for SVE
then it probably will be OK for RVV.

Jim

Re: [PATCH v2] Fix use of singleton in optinfo framework

[Gerald Pfeifer]

Okay to backport c00568f376078129196740d83946d54dc5437401 to the GCC 9 
branch, Jakub?

Thanks,
Gerald

On Tue, 7 Apr 2020, Gustavo Romero via Gcc-patches wrote:
> Currently an use of get() method of dump_context singleton in optinfo
> framework causes a new class to be instantiated and when its dtor
> is called it calls delete on uninitialized data, causing an ICE.
> 
> It happens when a temporary dump_context is instantiated for the 'm_saved'
> initialization in temp_dump_context::temp_dump_context. In that case it
> might happen that that temporary dump_context is not initalized properly
> and when it gets destroyed its dtor tries to delete 'm_pending', (delete an
> uninitialized optinfo *), thus calling delete on an uninitialized memory,
> or on whatever happens to be in the stack, generating an ICE.
> 
> This commit fixes that issue by using singleton's static member get()
> directly to get the singleton's active instance, which doesn't instantiate
> a new class, so no dtor is called.
> 
> gcc/Changelog:
> 2020-04-06  Gustavo Romero  
> 
>   * dumpfile.c:
>   (selftest::temp_dump_context::temp_dump_context): Fix ctor.
> ---
>  gcc/dumpfile.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/dumpfile.c b/gcc/dumpfile.c
> index 468ffab..e392ecf 100644
> --- a/gcc/dumpfile.c
> +++ b/gcc/dumpfile.c
> @@ -2076,7 +2076,7 @@ temp_dump_context::temp_dump_context (bool 
> forcibly_enable_optinfo,
> bool forcibly_enable_dumping,
> dump_flags_t test_pp_flags)
>  : m_context (),
> -  m_saved (&dump_context ().get ())
> +  m_saved (&dump_context::get ())
>  {
>dump_context::s_current = &m_context;
>if (forcibly_enable_optinfo)
> 

Re: [PATCH 0/7] Support vector load/store with length

[Segher Boessenkool]

Hi!

On Tue, May 26, 2020 at 01:29:30PM +0100, Richard Sandiford wrote:
> FWIW, I agree adding .LEN_LOAD and .LEN_STORE seems like a good
> approach.  I think it'll be more maintainable in the long run than
> trying to have .MASK_LOADs and .MASK_STOREs that need a special mask
> operand.  (That would be too similar to VEC_COND_EXPR :-))
> 
> Not sure yet what the exact semantics wrt out-of-range values for
> the IFN/optab though.  Maybe we should instead have some kind of
> abstract, target-specific cookie created by a separate intrinsic.
> Haven't thought much about it yet...

Or maybe only support 0..N with N the length of the vector?  It is
pretty important to support 0 and N, but greater than N isn't as
important (it is useful for tricky hand-written code, but not as much
for compiler-generate code -- we only support an 8-bit number here on
Power, maybe that is why ;-) )


Segher

[PATCH] c++: Fix bogus -Wparentheses warning [PR95344]

[Marek Polacek via Gcc-patches]

Since r267272, which added location wrappers, cp_fold loses
TREE_NO_WARNING on a MODIFY_EXPR that finish_parenthesized_expr set, and
that results in a bogus -Wparentheses warning.

I.e., previously we had "b = 1" but now we have "VIEW_CONVERT_EXPR(b) = 1"
and cp_fold_maybe_rvalue folds away the location wrapper and so we do
2718 x = fold_build2_loc (loc, code, TREE_TYPE (x), op0, op1);
in cp_fold and the flag is lost.

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

PR c++/95344
* cp-gimplify.c (cp_fold) : Set TREE_NO_WARNING.

* c-c++-common/Wparentheses-2.c: New test.
---
 gcc/cp/cp-gimplify.c|  5 -
 gcc/testsuite/c-c++-common/Wparentheses-2.c | 18 ++
 2 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/c-c++-common/Wparentheses-2.c

diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index 53d715dcd89..8b505dd878c 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -2745,7 +2745,10 @@ cp_fold (tree x)
x = org_x;
}
   if (code == MODIFY_EXPR && TREE_CODE (x) == MODIFY_EXPR)
-   TREE_THIS_VOLATILE (x) = TREE_THIS_VOLATILE (org_x);
+   {
+ TREE_THIS_VOLATILE (x) = TREE_THIS_VOLATILE (org_x);
+ TREE_NO_WARNING (x) = TREE_NO_WARNING (org_x);
+   }
 
   break;
 
diff --git a/gcc/testsuite/c-c++-common/Wparentheses-2.c 
b/gcc/testsuite/c-c++-common/Wparentheses-2.c
new file mode 100644
index 000..1aa5d314ae7
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/Wparentheses-2.c
@@ -0,0 +1,18 @@
+// PR c++/95344 - bogus -Wparentheses warning.
+// { dg-do compile }
+// { dg-options "-Wparentheses" }
+
+#ifndef __cplusplus
+# define bool _Bool
+# define true 1
+# define false 0
+#endif
+
+void
+f (int i)
+{
+  bool b = false;
+  if (i == 99 ? (b = true) : false) // { dg-bogus "suggest parentheses" }
+{
+}
+}

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

Broken build (was: Re: drop -aux{dir,base}, revamp -dump{dir,base})

[Hans-Peter Nilsson via Gcc-patches]

> From: Alexandre Oliva 
> Date: Tue, 26 May 2020 15:52:57 +0200

> On May 26, 2020, Richard Biener  wrote:
> 
> > xgcc: error: unrecognized command-line option '-dumpbase'^M
> 
> > xg++: error: unrecognized command-line option '-dA'; did you mean '-A'
> 
> Here's a proper patch submission.

And here's an improper bug report.

One of the commits between cfdff3eeb90..5c8344e7289 caused every
single *linked* test to fail for cris-elf, like:

xgcc: error: : No such file or directory

as in (excerpt from gcc.log):
spawn -ignore SIGHUP 
/netapp/hp3_storage/hp/autotest/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc 
-B/netapp/hp3_storage/hp/autotest/hpautotest-gcc1/cris-elf/gccobj/gcc/ 
/netapp/hp3_storage/hp/autotest/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1.c
 
/netapp/hp3_storage/hp/autotest/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1-lib.c
 
/netapp/hp3_storage/hp/autotest/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c
 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers 
-fdiagnostics-color=never -fdiagnostics-urls=never -w -O1 -fno-tree-dse 
-fno-tree-loop-distribute-patterns -fno-tracer -fno-ipa-ra 
-fno-inline-functions -Wl,--allow-multiple-definition -isystem 
/netapp/hp3_storage/hp/autotest/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include
 -isystem 
/netapp/hp3_storage/hp/autotest/hpautotest-gcc1/gcc/newlib/libc/include 
-B/netapp/hp3_storage/hp/autotest/hpautotest-gcc1/cris-elf/gccobj/cr
 is-elf/./libgloss/cris/ 
-L/netapp/hp3_storage/hp/autotest/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris
 -L/netapp/hp3_storage/hp/autotest/hpautotest-gcc1/gcc/libgloss/cris  
-B/netapp/hp3_storage/hp/autotest/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/
 
-L/netapp/hp3_storage/hp/autotest/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib
 -sim3 -lm -o 
/netapp/hp3_storage/hp/autotest/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/gcc/20010124-1.x1
xgcc: error: : No such file or directory

The only commit in that range that touches gcc.c was
"1dedc12d186 2020-05-26 ol...@adacore.com revamp dump and aux output names"

At bf40f0ba9503, or in LAST_UPDATED parlance,
Tue May 26 23:52:15 UTC 2020 (revision 
56f03cd12be:7d94d872509:bf40f0ba95037f235b007a55a7682646a0578b26)
(after every follow-up commit at the time of this writing) this
is still broken.

Can you please have a look?

brgds, H-P

[PATCH PR95332] gcov-tool: Flexible endian adjustment for merging coverage data

[dongjianqiang (A)]

Hi GCC maintainers,


Proposed patch to PR95332 - gcov-tool merge："not a gcov data file"

This error occurs when using gcov-tool merge dir1 dir2 where dir1 and dir2 are 
the directories containing the .gcda files which were generated by different 
endian machine,
Any suggestions? Thanks.

Regards,
Dong JianQiang


pr95332_v0.patch
Description: pr95332_v0.patch

RE: [PATCH PR94026] combine missed opportunity to simplify comparisons with zero

[Yangfei (Felix)]

Hi,

> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Tuesday, May 26, 2020 11:32 PM
> To: Yangfei (Felix) 
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A) 
> Subject: Re: [PATCH PR94026] combine missed opportunity to simplify
> comparisons with zero

Snip...

> 
> Yes, please try to get this sorted somehow.  Maybe you can ask other people
> in your company that have this same problem?

Will try and see.

> > > > + new_rtx = gen_rtx_AND (mode, new_rtx,
> > > > +gen_int_mode (mask << real_pos, mode));
> > > > +   }
> > >
> > > So this changes
> > >   ((X >> C) & M) == ...
> > > to
> > >   (X & (M << C)) == ...
> > > ?
> > >
> > > Where then does it check what ... is?  This is only valid like this if 
> > > that is
> zero.
> > >
> > > Why should this go in combine and not in simplify-rtx instead?
> >
> > True.  This is only valid when ... is zero.
> > That's why we need the "&& equality_comparison " condition here.
> 
> But that doesn't test if the other side of the comparison is 0.

Well, the caller has ensured that.

Here, local variable "equality_comparison" in make_compound_operation_int 
depends on parameter "in_code":
 8088   if (in_code == EQ)
 8089 {
 8090   equality_comparison = true;
 8091   in_code = COMPARE;
 8092 }

The only caller of make_compound_operation_int is make_compound_operation.
The comment of the caller says something about " in_code ":

 8512IN_CODE says what kind of expression we are processing.  Normally, it 
is
 8513SET.  In a memory address it is MEM.  When processing the arguments of
 8514a comparison or a COMPARE against zero, it is COMPARE, or EQ if more
 8515precisely it is an equality comparison against zero.  */

For the given test case, we have a call trace of:
(gdb) bt
#0  make_compound_operation_int (mode=..., x_ptr=0xbd08, 
in_code=COMPARE, next_code_ptr=0xbd1c) at 
../../gcc-git/gcc/combine.c:8248
#1  0x0208983c in make_compound_operation (x=0xb211c768, 
in_code=EQ) at ../../gcc-git/gcc/combine.c:8539
#2  0x020970fc in simplify_comparison (code=NE, pop0=0xc1e8, 
pop1=0xc1e0) at ../../gcc-git/gcc/combine.c:13032
#3  0x02084544 in simplify_set (x=0xb211c240) at 
../../gcc-git/gcc/combine.c:6932
#4  0x02082688 in combine_simplify_rtx (x=0xb211c240, 
op0_mode=E_VOIDmode, in_dest=0, in_cond=0) at ../../gcc-git/gcc/combine.c:6445
#5  0x0208025c in subst (x=0xb211c240, from=0xb211c138, 
to=0xb211c150, in_dest=0, in_cond=0, unique_copy=0)
at ../../gcc-git/gcc/combine.c:5724
#6  0x02079110 in try_combine (i3=0xb22cc3c0, i2=0xb22cc340, 
i1=0x0, i0=0x0, new_direct_jump_p=0xceb4,
last_combined_insn=0xb22cc3c0) at ../../gcc-git/gcc/combine.c:3413
#7  0x02073004 in combine_instructions (f=0xb211d038, nregs=103) at 
../../gcc-git/gcc/combine.c:1305
#8  0x0209cc50 in rest_of_handle_combine () at 
../../gcc-git/gcc/combine.c:15088

In simplify_comparison (combine.c:13032):

13028   rtx_code op0_mco_code = SET;
13029   if (op1 == const0_rtx)
13030 op0_mco_code = code == NE || code == EQ ? EQ : COMPARE;
13031
13032   op0 = make_compound_operation (op0, op0_mco_code);
13033   op1 = make_compound_operation (op1, SET);


> > > > --- /dev/null
> > > > +++ b/gcc/testsuite/gcc.dg/pr94026.c
> > > > @@ -0,0 +1,21 @@
> > > > +/* { dg-do compile { target aarch64*-*-* i?86-*-* x86_64-*-* } }
> > > > +*/
> > >
> > > Why restrict this to only some targets?
> >
> > That's because I only have these targets for verification.
> > But I think this can work on other targets.  Removed from the v4 patch.
> > Could you please help check the other ports?
> 
> In general, you should never restrict anything to some targets simply
> because you haven't tested it on other targets.
> 
> If it is a good test it will just work on those other targets.  Traffic on 
> gcc-
> testresults@ will show you if it actually does.

OK.  Thanks for pointing this out  :-)

> > > > +/* { dg-options "-O2 -fdump-rtl-combine" } */
> > > > +
> > > > +int
> > > > +foo (int c)
> > > > +{
> > > > +  int a = (c >> 8) & 7;
> > > > +
> > > > +  if (a >= 2) {
> > > > +return 1;
> > > > +  }
> > > > +
> > > > +  return 0;
> > > > +}
> > > > +
> > > > +/* The combine phase should transform (compare (and (lshiftrt x 8) 6)
> 0)
> > > > +   to (compare (and (x 1536)) 0). We look for the *attempt* to match
> this
> > > > +   RTL pattern, regardless of whether an actual insn may be found on
> the
> > > > +   platform.  */
> > > > +
> > > > +/* { dg-final { scan-rtl-dump "\\(const_int 1536" "combine" } }
> > > > +*/
> > >
> > > That is a very fragile test.
> >
> > For this specific test case, (const_int 1536) is calculated from 
> > subexpression
> (M << C) in (X & (M << C)).
> > I also see some similar checkings in gcc.dg/asr_div1.c.  Suggesions?
> 
> Maybe it is bet

[PATCH] extend cselim to check non-trapping for more references (PR tree-optimizaton/89430)

[Hao Liu OS via Gcc-patches]

Hi all,

Previously, the fix for 
PR89430 was reverted by 
PR94734 due to a bug. The 
root cause is missing non-trapping check with dominating LOAD/STORE.

This patch extends the cselim non-trapping check to support ARRAY_REF and 
COMPONENT_REF (previously only support MEM_REF) by get_inner_reference and 
hashing according to the comments from Jakub.

To support cases in PR89430, if there is a dominating LOAD of local variable 
without address escape,  as local stack is always writable, the STORE is not 
trapped and can be optimized.

Review, please.


diff --git a/gcc/tree-ssa-phiopt.c b/gcc/tree-ssa-phiopt.c
index b1e0dce93d8..3733780a0bc 100644
--- a/gcc/tree-ssa-phiopt.c
+++ b/gcc/tree-ssa-phiopt.c
@@ -1986,26 +1986,31 @@ abs_replacement (basic_block cond_bb, basic_block 
middle_bb,

??? We currently are very conservative and assume that a load might
trap even if a store doesn't (write-only memory).  This probably is
-   overly conservative.  */
+   overly conservative.

-/* A hash-table of SSA_NAMEs, and in which basic block an MEM_REF
-   through it was seen, which would constitute a no-trap region for
-   same accesses.  */
-struct name_to_bb
+   We currently support a special case that for !TREE_ADDRESSABLE automatic
+   variables, it could ignore whether something is a load or store because the
+   local stack should be always writable.  */
+
+/* A hash-table of references (MEM_REF/ARRAY_REF/COMPONENT_REF), and in which
+   basic block an *_REF through it was seen, which would constitute a
+   no-trap region for same accesses.  */
+struct ref_to_bb
 {
-  unsigned int ssa_name_ver;
+  tree base;
+  poly_int64 bitsize, bitpos;
+  tree offset;
   unsigned int phase;
-  bool store;
-  HOST_WIDE_INT offset, size;
+  bool writable;
   basic_block bb;
 };

 /* Hashtable helpers.  */

-struct ssa_names_hasher : free_ptr_hash 
+struct refs_hasher : free_ptr_hash
 {
-  static inline hashval_t hash (const name_to_bb *);
-  static inline bool equal (const name_to_bb *, const name_to_bb *);
+  static inline hashval_t hash (const ref_to_bb *);
+  static inline bool equal (const ref_to_bb *, const ref_to_bb *);
 };

 /* Used for quick clearing of the hash-table when we see calls.
@@ -2015,28 +2020,44 @@ static unsigned int nt_call_phase;
 /* The hash function.  */

 inline hashval_t
-ssa_names_hasher::hash (const name_to_bb *n)
+refs_hasher::hash (const ref_to_bb *n)
 {
-  return n->ssa_name_ver ^ (((hashval_t) n->store) << 31)
- ^ (n->offset << 6) ^ (n->size << 3);
+  inchash::hash hstate;
+  inchash::add_expr (n->base, hstate);
+  hstate.add_poly_int (n->bitsize);
+  hstate.add_poly_int (n->bitpos);
+  hstate.add_int (n->writable);
+  if (n->offset != NULL_TREE)
+{
+  inchash::add_expr (n->offset, hstate);
+}
+  return hstate.end ();
 }

 /* The equality function of *P1 and *P2.  */

 inline bool
-ssa_names_hasher::equal (const name_to_bb *n1, const name_to_bb *n2)
+refs_hasher::equal (const ref_to_bb *n1, const ref_to_bb *n2)
 {
-  return n1->ssa_name_ver == n2->ssa_name_ver
- && n1->store == n2->store
- && n1->offset == n2->offset
- && n1->size == n2->size;
+  if (operand_equal_p (n1->base, n2->base, 0)
+  && known_eq (n1->bitsize, n2->bitsize)
+  && known_eq (n1->bitpos, n2->bitpos) && n1->writable == n2->writable)
+{
+  /* Should not call operand_equal_p with NULL_TREE.  */
+  if (n1->offset == NULL_TREE || n2->offset == NULL_TREE)
+  return n1->offset == n2->offset;
+  else
+  return operand_equal_p (n1->offset, n2->offset, 0);
+}
+  return false;
 }

 class nontrapping_dom_walker : public dom_walker
 {
 public:
   nontrapping_dom_walker (cdi_direction direction, hash_set *ps)
-: dom_walker (direction), m_nontrapping (ps), m_seen_ssa_names (128) {}
+: dom_walker (direction), m_nontrapping (ps), m_seen_refs (256)
+  {}

   virtual edge before_dom_children (basic_block);
   virtual void after_dom_children (basic_block);
@@ -2053,7 +2074,7 @@ private:
   hash_set *m_nontrapping;

   /* The hash table for remembering what we've seen.  */
-  hash_table m_seen_ssa_names;
+  hash_table m_seen_refs;
 };

 /* Called by walk_dominator_tree, when entering the block BB.  */
@@ -2102,65 +2123,76 @@ nontrapping_dom_walker::after_dom_children (basic_block 
bb)
 }

 /* We see the expression EXP in basic block BB.  If it's an interesting
-   expression (an MEM_REF through an SSA_NAME) possibly insert the
-   expression into the set NONTRAP or the hash table of seen expressions.
-   STORE is true if this expression is on the LHS, otherwise it's on
-   the RHS.  */
+   expression of:
+ 1) MEM_REF
+ 2) ARRAY_REF
+ 3) COMPONENT_REF
+   possibly insert the expression into the set NONTRAP or the hash table
+   of seen expressions.  STORE is true if this expression is on the LHS,
+   otherwi

[committed] Fix pr20601-1.c on the H8

[Jeff Law via Gcc-patches]

This is a codegen fix for the H8 that I debugged while working on the cc0
conversion.  In simplest terms we're accepting things like (const_int 0) as the
source of a zero_extract and it ultimately interacts badly with register
reloading.

One might argue this is combine's fault for not simplifying the extraction, but
it's really wrong for the pattern to accept something that we simply can't 
handle
correctly, ever.  THere isn't a great predicate for this, so we just reject the
constants in the condition.

Pushed to the trunk, without having to commit a ChangeLog entry! :-)

Jeff
commit bc48456d085d4ab8be92cf5369624dd86317cecb
Author: Jeff Law 
Date:   Tue May 26 22:14:40 2020 -0600

Fix pr20601-1.c on the H8

gcc/
* config/h8300/testcompare.md (tst_extzv_1_n): Do not accept 
constants
for the primary input operand.
(tstsi_variable_bit_qi): Similarly.

diff --git a/gcc/config/h8300/testcompare.md b/gcc/config/h8300/testcompare.md
index 2e4cb5afee7..118db145a8a 100644
--- a/gcc/config/h8300/testcompare.md
+++ b/gcc/config/h8300/testcompare.md
@@ -9,7 +9,7 @@
  (match_operand 1 "const_int_operand" "n,n,n"))
 (const_int 0)))
(clobber (match_scratch:QI 2 "=X,X,&r"))]
-  ""
+  "!CONSTANT_P (operands[0])"
   "@
btst\\t%Z1,%Y0
btst\\t%Z1,%Y0
@@ -82,7 +82,7 @@
  (const_int 7)))
 (const_int 0)))
(clobber (match_scratch:QI 2 "=X,X,&r"))]
-  ""
+  "!CONSTANT_P (operands[0])"
   "@
btst\\t%w1,%X0
btst\\t%w1,%X0

Re: [PATCH 1/2] rs6000: tune cunroll for simple loops at O2

[Jiufu Guo via Gcc-patches]

Segher Boessenkool  writes:

> Hi!
>
> On Tue, May 26, 2020 at 08:58:13AM +0200, Richard Biener wrote:
>> On Mon, May 25, 2020 at 7:44 PM Segher Boessenkool
>>  wrote:
>> > Yes, cunroll does not have its own option, and that is a problem.  But
>> > that is easy to fix!  Either with an option, or just with params (the
>> > option wouldn't do more than set params anyway?)
>> 
>> Well, given coming up with different names for essentially the same
>> transform is going to be challenging how about sth like
>> 
>> -funroll-loops={early,late,static,dynamic}[insert better names here]
>
> User interface is hard :-)  I think luckily we don't need to change
> anything there yet, just have an internal flag?
>
> But complete unrolling is something quite different, so it should have
> its own flag anyway (at least internally).
>
>> note there's also -fpeel-loops which may match the transform
>> done on GIMPLE better?
>
> Peeling and unrolling are the same thing, if doing complete unrolling
> (or complete peeling), followed by DCE in both cases.  Peeling is a
> nicer name here I think, yeah.
>
>> I'm not sure which are the technically
>> correct terms for unrollings that elide the loop (the backedge).
>
> I don't know a better term than "complete", I don't remember ever seeing
> something else either.

How about "Var(flag_cunroll_grow_size) EnabledBy(funroll-loops ||
funroll-all-loops || fpeel-loops)" Or flag_cunroll_allow_grow_size?

And then using this flags as:
  unsigned int val = tree_unroll_loops_completely (flag_cunroll_grow_size
   || optimize >= 3, true);

And we do not need to enable this flag at -O2.

Thanks for all your helpful comments again!

Jiufu

>
>> We're doing such kind of unrolling even if we cannot statically
>> decide which of a set of possible exits we take (and internally
>> call that peeling, if we can statically decide we call it complete
>> unrolling).
>
> "Peeling" is placing some copies of the loop before the loop;
> "unrolling" is placing a few copies of the loop inside the loop body.
> Does that match usage here?
>
>> The RTL side OTOH only performs classical unrolling,
>> preserving the backedge with various strategies for the
>> remaining iterations.
>
> And if you do complete unrolling that way, the backedge can be removed,
> since it can be shown never to be taken.
>
>> As said, for the regression on the 10 branch with ppc I'd add
>> [a hidden] flag that controls the RTL unroller, also set by
>> -funroll-loops and triggered by the ppc specific heuristics.
>
> But the problem is in cunroll?  This is so backwards...  Because some
> other transform abuses the unroller flags, adding a second level flag
> with the same meaning :-(  It will work for fixing the regression,
> sure, and it is slightly less code as well.
>
>
> Segher

Re: [PATCH] Fix nonconforming memory_operand for vpmov instructions which has memory operand narrow than 128 bits [avx512f]

[Hongtao Liu via Gcc-patches]

On Mon, May 25, 2020 at 8:41 PM Uros Bizjak  wrote:
>
> On Mon, May 25, 2020 at 2:21 PM Hongtao Liu  wrote:
> >
> >   According to Intel SDM, VPMOVQB xmm1/m16 {k1}{z}, xmm2 has 16-bit
> > memory_operand instead of 128-bit one which exists in current
> > implementation. Also for other vpmov instructions which have
> > memory_operand narrower than 128bits.
> >
> >   Bootstrap is ok, regression test for i386/x86-64 backend is ok.
>
>
> +  [(set (match_operand:HI 0 "memory_operand" "=m")
> +(subreg:HI (any_truncate:V2QI
> + (match_operand:V2DI 1 "register_operand" "v")) 0))]
>
> This should store in V2QImode, subregs are not allowed in insn patterns.
>
> You need a pre-reload splitter to split from register_operand to a
> memory_operand, Jakub fixed a bunch of pmov patterns a while ago, so
> perhaps he can give some additional advice here.
>

Like this?
---
(define_insn "*avx512vl_v2div2qi2_store"
  [(set (match_operand:V2QI 0 "memory_operand" "=m")
(any_truncate:V2QI
  (match_operand:V2DI 1 "register_operand" "v")))]
  "TARGET_AVX512VL"
  "vpmovqb\t{%1, %0|%0, %1}"
  [(set_attr "type" "ssemov")
   (set_attr "memory" "store")
   (set_attr "prefix" "evex")
   (set_attr "mode" "TI")])

(define_insn_and_split "*avx512vl_v2div2qi2_store"
  [(set (match_operand:HI 0 "memory_operand")
(subreg:HI
  (any_truncate:V2QI
(match_operand:V2DI 1 "register_operand")) 0))]
  "TARGET_AVX512VL && ix86_pre_reload_split ()"
  "#"
  "&& 1"
  [(set (match_dup 0)
(any_truncate:V2QI (match_dup 1)))]
  "operands[0] = adjust_address_nv (operands[0], V2QImode, 0);")
---

> Uros.
>
>
> > gcc/ChangeLog
> >
> > * config/i386/sse.md (*avx512vl_v2div2qi2_store): Refine
> > size of memory_operand according to Intel SDM.
> > (avx512vl_v2div2qi2_mask_store): Ditto.
> > (*avx512vl_v4qi2_store): Ditto.
> > (avx512vl_v4qi2_mask_store): Ditto.
> > (*avx512vl_v8qi2_store): Ditto.
> > (avx512vl_v8qi2_mask_store): Ditto.
> > (*avx512vl_v4hi2_store): Ditto.
> > (avx512vl_v4hi2_mask_store): Ditto.
> > (*avx512vl_v2div2hi2_store): Ditto.
> > (avx512vl_v2div2hi2_mask_store): Ditto.
> > (*avx512vl_v2div2si2_store): Ditto.
> > (avx512vl_v2div2si2_mask_store): Ditto.
> > (*avx512f_v8div16qi2_store): Ditto.
> > (avx512f_v8div16qi2_mask_store): Ditto.
> > * config/i386/i386-builtin-types.def: Adjust builtin type.
> > * config/i386/i386-expand.c: Ditto.
> > * config/i386/i386-builtin.def: Adjust builtin.
> > * config/i386/avx512fintrin.h: Ditto.
> > * config/i386/avx512vlbwintrin.h: Ditto.
> > * config/i386/avx512vlintrin.h: Ditto.
> >
> >   I think the code i changed is already covered by existed intrinsics
> > tests, so i didn't add any new tests.
> > --
> > BR,
> > Hongtao



-- 
BR,
Hongtao

Re: [PATCH] Fortran : ICE in gfc_trans_label_assign PR50392

[Mark Eggleston]

ping

On 19/05/2020 08:49, Mark Eggleston wrote:

Please find attached patch for PR50392.

This patch was extracted from the comments in the PR and was written 
back in 2011! I have verified that it fixes the PR on master, gcc-8, 
gcc-9 and gcc-10.


Commit message:

Fortran  : ICE in gfc_trans_label_assign PR50392

A function may contain an assigned goto.  If the the return variable
is an integer a statement can be assigned to it.  Prior to this fix
this resulted in an ICE.

2020-05-19  Tobias Burnus 

gcc/fortran/

    * trans-decl.c (gfc_get_symbol_decl): Remove unnecessary block
    delimiters.  Add auxiliary variables if a label is assigned to
    a return variable. (gfc_gat_fake_result): ???

2020-05-19  Mark Eggleston 

gcc/testsuite/

    * gfortran.dg/pr50392.f: New test.

As can be seen there is a sequence of question marks in the 
description of the changes made. I don't know how to describe the 
inserted code, Tobias Burnus: you may be able to help as it is your code.


Tested on x86_64 using make check-fortran for master, gcc-8, ggc-9 and 
gcc-10.


Once the addition to the description to the code changes is complete 
will it be OK to commit to master and backport to gcc-8, 9 and 10.



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

Re: [PATCH] PR94397 the compiler consider "type is( real(kind(1.)) )" as a syntax error

[Mark Eggleston]

ping

On 13/05/2020 18:19, Mark Eggleston wrote:

Please find attached a patch for PR94397.

Commit message:

Fortran  : "type is( real(kind(1.)) )" spurious syntax error PR94397

Based on a patch in the comments of the PR. That patch fixed this problem
but caused the test cases for PR93484 to fail. Changed to reduce
initialisation expressions if the expression is not EXPR_VARIABLE and not
EXPR_CONSTANT.

2020-05-13  Steven G. Kargl  
            Mark Eggleston 

gcc/fortran/

    PR fortran/94397
    * match.c (gfc_match_type_spec): New variable ok initialised
    to true. Set ok with the return value of gfc_reduce_init_expr
    called only if the expression is not EXPR_CONSTANT and is not
    EXPR_VARIABLE. Add !ok to the check for type not being integer
    or the rank being greater than zero.

2020-05-13  Mark Eggleston 

gcc/testsuite/

    PR fortran/94397
    * gfortran.dg/pr94397.F90: New test.

The formatting with tabs and date will be corrected prior to commit.

Tested on x86_64 for master, releases/gcc-9, releases/gcc-10 branches. 
OK to commit and backport?



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