[Bug rtl-optimization/92657] High stack usage due ftree-ch

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-26
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
>From a quick look it's a classical testcase for excessive store-motion plus
PRE and GCSE managing to do half of that.

So in essence there are probably duplicates of this bug and what we miss
is something of a register pressure estimation framework on GIMPLE (we do
have multiple sketches of that spread across some passes).  The main issue
here is (as can be seen here) that implementing such estimation in one
pass doesn't solve the issue but merely pushes it elsewhere.

Note that for i?86 with SSE STV is also an offender:

t.c:157:6:mlx5e_grp_sw_update_stats 1376static
t.c:157:6:mlx5e_grp_sw_update_stats 936 static   with -mno-stv

[Bug c/92663] Add __gcc_has_bug or __gcc_bug_fixed

[fiesh at zefix dot tv]

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

--- Comment #6 from fiesh at zefix dot tv ---
My suggestion would be to uniformly include the information about whether a bug
has been closed, irrespective of its nature.  So yes, un-optimal code
generation might also be listed, and I think the use case of providing
workaround code exists for it just like it exists for an ice-on-valid.

As Jonathan already said, the list should be baked into the compiler.  I'm not
suggesting making compilation or even execution of GCC depend on some external
database query;  that's a horrid idea.


As for the use cases: Along the years, I've often found myself to write code of
the following nature:

// https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
#if defined(__GNUC__) && !defined(__llvm__) && __GNUC__ <= 10
// The workaround code
#else
// The good code
#endif

We then re-visit these places on compiler updates in case the bug wasn't fixed
for the major version.  This can be about new features (as a concrete example,
we have code that would like to use std::transform_reduce, so it could do it in
compilers with 91495 closed), or about bugs (as a concrete example, we have a
template with a template template parameter that leads to an internal compiler
error.  We have workaround code in there that uses copy and paste code to
circumvent the issue, but once 92654 is fixed, I'd prefer the good code to be
used automatically.)

This would also allow requiring certain bugs be fixed with ifdef-error-endif
constructs instead of depending on the compiler's version explicitly.


I'm not claiming this is a feature request that's perfectly thought through,
and maybe the cons outweigh the pros.  But I'd like to put this up for
discussion because I believe the current means of circumventing bugs is not
great, and it largely isn't because the information about the bug numbers is
lost needlessly.

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

[John Paul Adrian Glaubitz]

Hi Bernd!

On 11/26/19 2:44 AM, Bernd Schmidt wrote:
> I overlooked a difference in the 68881 vs coldfire patterns when I
> combined them. They use different suffixes for register compares (I only
> spotted the different constraints).
> 
> The following seems to fix the assembler failures. I cannot properly
> test Coldfire however due to lack of hardware.

Angelo Dureghello (CC'ed) does active kernel development work on ColdFire and
he might be able to help with testing on the platform. He also created two
open-source ColdFire SBCs [1, 2].

I do have multiple ColdFire boards myself, but they are currently not set
up and it would take me some time to get them running as I have never used
them before.

Adrian

> [1] http://sysam.it/cff_amcore.html
> [2] http://sysam.it/cff_stmark2.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

AW: [PATCH] m68k architecture: support ccmode + lra

[stefan]

> On 11/21/19 10:30 AM, ste...@franke.ms wrote:
> > Hi there,
> > 
> > here is mc68k's patch to switch the m68k architecture over to ccmode and
> > lra. See https://github.com/mc68kghost/gcc 68k-ccmode branch.
> Bernd Schmidt posted a conversion of the m68k port to ccmode a couple
> weeks before yours.  We've already ACK'd it for installing onto the trunk.
>
> Jeff

To be honest:
- 8 days is hardly "a couple weeks before"
- ccmode is not the same as ccmode+lra

The paperwork for contributing to fsf is on the way and the repo at
https://github.com/mc68kghost/gcc got an update. Tests are not yet at 100%
(master branch fails too many tests) but it's closer to master branch now.
The code is to 50% identical, a fair amount has swapped cmp/bcc, few are a
tad worse and some yield surprisingly better code.

Stefan

[Bug c++/61414] enum class bitfield size-checking needs a separate warning flag controlling it

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-11/msg02329.ht
   ||ml

--- Comment #22 from Eric Gallager  ---
Patch discussion on the gcc-patches mailing list starts here for this month:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02329.html

[Bug debug/46558] dbgcnt.c messages not marked for translation

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
I think I remember seeing Martin Liska sending patches modifying code in this
area recently; cc-ing him to see if he's fixed this...

Re: [PATCH, libstdc++] More

[François Dumont]

I have a patch for the same location so here is my remark that might 
make my patch useless.


Maybe you can even merge it with yours Ed, here it is:

https://gcc.gnu.org/ml/libstdc++/2019-10/msg00072.html

On 11/25/19 10:15 PM, Jonathan Wakely wrote:

On 15/11/19 22:17 -0500, Ed Smith-Rowland via libstdc++ wrote:

Index: include/bits/stl_algobase.h
===
--- include/bits/stl_algobase.h    (revision 278318)
+++ include/bits/stl_algobase.h    (working copy)
@@ -107,6 +107,50 @@
    }

  /*
+   * A constexpr wrapper for __builtin_memmove.


This should say __builtin_memcpy.


+   * @param __num The number of elements of type _Tp (not bytes).
+   */
+  template
+    _GLIBCXX14_CONSTEXPR
+    inline void*
+    __memcpy(_Tp* __dst, const _Tp* __src, size_t __num)
+    {
+#ifdef __cpp_lib_is_constant_evaluated
+  if (std::is_constant_evaluated())
+    {
+  for(; __num > 0; --__num)


for (; __num != 0; --__num)

and make __num prtdiff_t.

would be better here as this way the compiler is able to report bad 
usages rather than silently do nothing.




+    *__dst++ = *__src++;
+  return __dst;
+    }
+  else
+#endif
+    return __builtin_memcpy(__dst, __src, sizeof(_Tp) * __num);
+  return __dst;
+    }
+
+  /*
+   * A constexpr wrapper for __builtin_memmove.


And this should say __builtin_memset.


+   * @param __num The number of elements of type _Tp (not bytes).
+   */
+  template
+    _GLIBCXX14_CONSTEXPR
+    inline void*
+    __memset(_Tp* __dst, _Tp __a, size_t __num)
+    {
+#ifdef __cpp_lib_is_constant_evaluated
+  if (std::is_constant_evaluated())
+    {
+  for(; __num > 0; --__num)
+    *__dst = __a;
+  return __dst;
+    }
+  else
+#endif
+    return __builtin_memset(__dst, __a, sizeof(_Tp) * __num);
+  return __dst;
+    }


OK for trunk with those two comment fixes. Thanks.

[PATCH] Fix two potential memory leak

[luoxhu]

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

gcc/ChangeLog:

2019-11-26  Luo Xiong Hu  

* ipa-pure-const.c (pure_const_write_summary): Fix memory leak.
* ipa-sra.c (ipa_sra_write_summary): Likewise.
---
 gcc/ipa-pure-const.c | 3 +++
 gcc/ipa-sra.c| 5 +
 2 files changed, 8 insertions(+)

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

Re: GNU Mes 0.21 released

[Nala Ginrut]

Congrats!

On Tue, Nov 26, 2019, 11:11 Brett Gilio  wrote:

> Jan Nieuwenhuizen  writes:
>
> > We are pleased to announce the release of GNU Mes 0.21, representing
> > 54 commits over 10 weeks.
> >
> > Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap
> > a GNU/Linux system without binary GNU toolchain or equivalent).  See
> > https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/
> >
> > This release supports a Scheme-only bootstrap: Mes can now be built with
> > Gash and the experimental Gash Core Utils instead of using GNU Awk, GNU
> > Bash, the GNU Core Utilities, GNU Grep, GNU Gzip, GNU Make, GNU SED, and
> > GNU Tar.  Also, the Mes C Library now supports bootstrapping those.
> > Finally, this release brings Mes as a package to Debian GNU/Linux.
> >
> > We are excited that the Nlnet Foundation[12] is now sponsoring this
> > work!
> >
> > Next targets:
> >
> >  - Introduce the Reduced Binaries Seed bootstrap to NixOS (Debian,
> >Gentoo, ...?)
> >  - Scheme-only bootstrap: use Guile, Gash and Gash Core Utils to remove
> >awk, bash, core utilities, grep, gzip, make, sed, tar, etc. from the
> >Guix bootstrap binaries
> >  - ARM support
> >  - Full Source Bootstrap: compile Mes.c using M2-Planet
> >  - Reduced Binary Seed bootstrap for ARM
> >  - the Hurd
> >
> > Packages are available in Guix master.
> >
> > * About
> >
> >   GNU Mes[0] brings a Reduced Binary Seed bootstrap[1] to GNU Guix[2].
> >   This bootstrap has halved the size of opaque, uninspectable binaries
> >   that were needed to bootstrap Guix.  The final goal is to help create
> >   a full source bootstrap as part of the bootstrappable builds[3] effort
> >   for any interested UNIX-like operating system.
> >
> >   It consists of a mutual self-hosting Scheme interpreter written in
> >   ~5,000 LOC of simple C and a Nyacc-based C compiler written in Scheme.
> >   This mes.c is being simplified[4] to be transpiled by M2-Planet[5].
> >
> >   The Scheme interpreter has a Garbage Collector, a library of loadable
> >   Scheme modules-- notably Dominique Boucher's LALR[6], Pre-R6RS
> >   [portable syntax-case[7] with R7RS ellipsis, Matt Wette's Nyacc[8]
> >   --and test suite just enough to support a REPL and a C99 compiler:
> >   MesCC.
> >
> >   Mes+MesCC can compile an only lightly patched TinyCC[9] that is
> >   self-hosting.  Using this tcc and the Mes C library we now have a
> >   Reduced Binary Seed bootstrap for the gnutools triplet: glibc-2.2.5,
> >   binutils-2.20.1, gcc-2.95.3.  This is enough to bootstrap Guix for
> >   i686-linux and x86_64-linux.
> >
> >   Mes is inspired by The Maxwell Equations of Software: LISP-1.5[10] --
> John
> >   McCarthy page 13, GNU Guix's source/binary packaging transparency and
> >   Jeremiah Orians's stage0[11] ~500 byte self-hosting hex assembler.
> >
> > * Download
> >
> >   git clone git://git.savannah.gnu.org/mes.git
> >
> >   Here are the compressed sources and a GPG detached signature[*]:
> > https://ftp.gnu.org/gnu/mes/mes-0.21.tar.gz
> > https://ftp.gnu.org/gnu/mes/mes-0.21.tar.gz.sig
> >
> >   Use a mirror for higher download bandwidth:
> > https://ftpmirror.gnu.org/mes/mes-0.21.tar.gz
> > https://ftpmirror.gnu.org/mes/mes-0.21.tar.gz.sig
> >
> >   Here are the MD5 and SHA1 checksums:
> >
> >   dea43529d2d84fb4b9d81bdd9efcc715  mes-0.21.tar.gz
> >   35721a81feeab6e0d5913b8bf78f18951edbb964  mes-0.21.tar.gz
> >
> >   [*] Use a .sig file to verify that the corresponding file (without the
> >   .sig suffix) is intact.  First, be sure to download both the .sig file
> >   and the corresponding tarball.  Then, run a command like this:
> >
> > gpg --verify mes-0.21.tar.gz.sig
> >
> >   If that command fails because you don't have the required public key,
> >   then run this command to import it:
> >
> > gpg --keyserver keys.gnupg.net --recv-keys
> 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273
> >
> >   and rerun the 'gpg --verify' command.
> >
> > * Get informed, get involved
> >
> >   See https://bootstrappable.org
> >   Join #bootstrappable on irc.freenode.net.
> >
> > * Changes in 0.21 since 0.20
> >  ** Core
> >  *** Mes can now be bootstrapped with Gash and Gash Core Utils.
> >  *** Mes now supports a Scheme-only bootstrap.
> >  *** Mes now supports -c EXPR.
> >  ** MesCC
> >  *** Mes C Library now supports bootstrapping GNU Awk, GNU Bash, GNU
> SED, and GNU Tar.
> >  *** Mes C Library now has limited float support in vfprintf, vsnprintf,
> vsscanf.
> >   7 new functions
> >  abtod, atof, creat, dtoab, execlp, isgraph, mknod, readlink, strtod,
> >  symlink.
> >   5 new stubs
> >  getgrgid, getgrnam, getpgid, getpgrp, mktime, setgrent.
> >  ** Noteworthy bug fixes
> >  *** A bug with `mes -c EXPR' has been fixed.
> >  *** The REPL now works again on x86_64.
> >  *** --with-system-libc now works again.
> >
> > Greetings,
> > janneke and Danny.
> >
> > [0] https://www.gnu.org/software/mes
> > [1] 

Re: [PATCH] V7, #4 of 7, Add explicit (0),1 to @pcrel references

[Alan Modra]

On Mon, Nov 25, 2019 at 07:05:02PM -0600, Segher Boessenkool wrote:
> On Mon, Nov 25, 2019 at 05:52:29PM -0500, Michael Meissner wrote:
> > If you write:
> > 
> > paddi 10,9,foo@pcrel
> > 
> > The assembler will interpret this as:
> > 
> > paddi 10,9,(.-foo),0

foo-. actually.

> > I.e. it will add the difference from current instruction to foo and 
> > register 2
> > and place it in register 10.  But it will not add the current location for 
> > the
> > paddi.
> > 
> > Of course it might make sense if the assembler could flag the first line as 
> > an
> > error, and if you really wanted to write that, you should use:
> > 
> > paddi 10,9,foo@pcrel,0
> 
> Does it ever make sense to allow @pcrel on anything that is not prefixed
> and R=1?  (Cc: Alan).

Probably not, but we might want something similar to generate the high
part of a 64-bit pcrel offset.

   pli 11,(foo-1f)@highera34
   sldi 11,11,34
1: pla 12,foo@pcrel
   add 12,11,12

We don't have the necessary relocs at the moment, and in any case we
might be better off with other code sequences.

-- 
Alan Modra
Australia Development Lab, IBM

[Bug c/92667] spurious missing sentinel in function call with a local sentinel variable

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
possibly related: bug 38481

[Bug c/70477] -Wtautological-compare too aggressive?

[egallager at gcc dot gnu.org]

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

--- Comment #9 from Eric Gallager  ---
*** Bug 92668 has been marked as a duplicate of this bug. ***

[Bug c/92668] [9/10 Regression] -Wtautological-compare warns for macros that expand to the same symbol, inconsistent with C++

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #4 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #3)
> Isn't this the same as bug 70477?

At first I thought of bug 696502, but I'd forgotten that that one was about
-Wlogical-op and not -Wtautological-compare, so on second thought it looks like
you're right, bug 70477 is actually the one to close this as a dup of.

*** This bug has been marked as a duplicate of bug 70477 ***

Re: Branch and tag deletions

[Eric S. Raymond]

Joseph Myers :
> I'm looking at the sets of branches and tags resulting from a GCC 
> repository conversion with reposurgeon.
> 
> 1. I see 227 branches (and one tag) with names like 
> cxx0x-concepts-branch-deleted-r131428-1 (this is out of 780 branches in 
> total in a conversion of GCC history as of a few days ago).  Can we tell 
> reposurgeon not to create such branches (and tags)?  I can't simply do 
> "branch /-deleted-r/ delete" because that command doesn't take a regular 
> expression.

Those dead branches were supposed to never be visible in the final
conversion.

They arise when a tag is created, then deleted, then recreated under
the same name. The dumpfile operations for the old tag can't simply
ignored, as part of its content could get copied forward from before
the delete to a branch that remains live.  So I recolor them, then
have logic to skip generating commits and tags from them. You;re
seeing dome leak through those guards, which is a bug.

I'm using a different and much simpler strategy in the analyzer rewrite;
this bug should be squashed when it lands.

> 2. gcc.lift has a series of "tag  delete" commands, generally 
> deleting tags that aren't official GCC releases or prereleases (many of 
> which were artifacts of how creating such tags was necessary to track 
> merges in the CVS and older SVN era).  But some such commands are 
> mysteriously failing to work.  For example I see
> 
> tag /ZLIB_/ delete
> reposurgeon: no tags matching /ZLIB_/
> 
> but there are tags ZLIB_1_1_3, ZLIB_1_1_4, ZLIB_1_2_1, ZLIB_1_2_3 left 
> after the conversion.  This isn't just an issue with regular expressions; 
> I also see e.g.
> 
> tag apple/ppc-import-20040330 delete
> reposurgeon: no tags matching apple/ppc-import-20040330
> 
> and again that tag exists after the conversion.

I knew there was a problem with those, but I have not diagnosed it
yet.  I know generally where it has to be and think it will be
relatively easy to clean up once I've dealt with the more pressing
issues.

Please file issues about these bugs so I can track then.

On the first one, it would be helpful if you could list some tags
that these match expressions fail to pick up from as early as
possible. Shortening the leading segment I need to load speeds up 
my test cycle significantly,
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: GNU Mes 0.21 released

[Brett Gilio]

Jan Nieuwenhuizen  writes:

> We are pleased to announce the release of GNU Mes 0.21, representing
> 54 commits over 10 weeks.
>
> Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap
> a GNU/Linux system without binary GNU toolchain or equivalent).  See
> https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/
>
> This release supports a Scheme-only bootstrap: Mes can now be built with
> Gash and the experimental Gash Core Utils instead of using GNU Awk, GNU
> Bash, the GNU Core Utilities, GNU Grep, GNU Gzip, GNU Make, GNU SED, and
> GNU Tar.  Also, the Mes C Library now supports bootstrapping those.
> Finally, this release brings Mes as a package to Debian GNU/Linux.
>
> We are excited that the Nlnet Foundation[12] is now sponsoring this
> work!
>
> Next targets:
>
>  - Introduce the Reduced Binaries Seed bootstrap to NixOS (Debian,
>Gentoo, ...?)
>  - Scheme-only bootstrap: use Guile, Gash and Gash Core Utils to remove
>awk, bash, core utilities, grep, gzip, make, sed, tar, etc. from the
>Guix bootstrap binaries
>  - ARM support
>  - Full Source Bootstrap: compile Mes.c using M2-Planet
>  - Reduced Binary Seed bootstrap for ARM
>  - the Hurd
>
> Packages are available in Guix master.
>
> * About
>
>   GNU Mes[0] brings a Reduced Binary Seed bootstrap[1] to GNU Guix[2].
>   This bootstrap has halved the size of opaque, uninspectable binaries
>   that were needed to bootstrap Guix.  The final goal is to help create
>   a full source bootstrap as part of the bootstrappable builds[3] effort
>   for any interested UNIX-like operating system.
>
>   It consists of a mutual self-hosting Scheme interpreter written in
>   ~5,000 LOC of simple C and a Nyacc-based C compiler written in Scheme.
>   This mes.c is being simplified[4] to be transpiled by M2-Planet[5].
>
>   The Scheme interpreter has a Garbage Collector, a library of loadable
>   Scheme modules-- notably Dominique Boucher's LALR[6], Pre-R6RS
>   [portable syntax-case[7] with R7RS ellipsis, Matt Wette's Nyacc[8]
>   --and test suite just enough to support a REPL and a C99 compiler:
>   MesCC.
>
>   Mes+MesCC can compile an only lightly patched TinyCC[9] that is
>   self-hosting.  Using this tcc and the Mes C library we now have a
>   Reduced Binary Seed bootstrap for the gnutools triplet: glibc-2.2.5,
>   binutils-2.20.1, gcc-2.95.3.  This is enough to bootstrap Guix for
>   i686-linux and x86_64-linux.
>
>   Mes is inspired by The Maxwell Equations of Software: LISP-1.5[10] -- John
>   McCarthy page 13, GNU Guix's source/binary packaging transparency and
>   Jeremiah Orians's stage0[11] ~500 byte self-hosting hex assembler.
>
> * Download
>
>   git clone git://git.savannah.gnu.org/mes.git
>
>   Here are the compressed sources and a GPG detached signature[*]:
> https://ftp.gnu.org/gnu/mes/mes-0.21.tar.gz
> https://ftp.gnu.org/gnu/mes/mes-0.21.tar.gz.sig
>
>   Use a mirror for higher download bandwidth:
> https://ftpmirror.gnu.org/mes/mes-0.21.tar.gz
> https://ftpmirror.gnu.org/mes/mes-0.21.tar.gz.sig
>
>   Here are the MD5 and SHA1 checksums:
>
>   dea43529d2d84fb4b9d81bdd9efcc715  mes-0.21.tar.gz
>   35721a81feeab6e0d5913b8bf78f18951edbb964  mes-0.21.tar.gz
>
>   [*] Use a .sig file to verify that the corresponding file (without the
>   .sig suffix) is intact.  First, be sure to download both the .sig file
>   and the corresponding tarball.  Then, run a command like this:
>
> gpg --verify mes-0.21.tar.gz.sig
>
>   If that command fails because you don't have the required public key,
>   then run this command to import it:
>
> gpg --keyserver keys.gnupg.net --recv-keys 
> 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273
>
>   and rerun the 'gpg --verify' command.
>
> * Get informed, get involved
>
>   See https://bootstrappable.org
>   Join #bootstrappable on irc.freenode.net.
>
> * Changes in 0.21 since 0.20
>  ** Core
>  *** Mes can now be bootstrapped with Gash and Gash Core Utils.
>  *** Mes now supports a Scheme-only bootstrap.
>  *** Mes now supports -c EXPR.
>  ** MesCC
>  *** Mes C Library now supports bootstrapping GNU Awk, GNU Bash, GNU SED, and 
> GNU Tar.
>  *** Mes C Library now has limited float support in vfprintf, vsnprintf, 
> vsscanf.
>   7 new functions
>  abtod, atof, creat, dtoab, execlp, isgraph, mknod, readlink, strtod,
>  symlink.
>   5 new stubs
>  getgrgid, getgrnam, getpgid, getpgrp, mktime, setgrent.
>  ** Noteworthy bug fixes
>  *** A bug with `mes -c EXPR' has been fixed.
>  *** The REPL now works again on x86_64.
>  *** --with-system-libc now works again.
>
> Greetings,
> janneke and Danny.
>
> [0] https://www.gnu.org/software/mes
> [1] https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/
> [2] https://www.gnu.org/software/guix
> [3] https://bootstrappable.org
> [4] https://github.com/oriansj/mes-m2
> [5] https://github.com/oriansj/m2-planet
> [6] https://github.com/schemeway/lalr-scm
> [7] 

Re: Split commit naming

[Eric S. Raymond]

Joseph Myers :
> My question is: is it a stable interface to reposurgeon that the portions 
> of such a split commit will always be numbered in lexicographical order by 
> branch name (or some other such well-defined stable ordering), so I can 
> write <80870.2> in gcc.lift and know that some reposurgeon change won't 
> accidentally make that refer to the portion of the commit on 
> gcc-3_3-branch instead?

Your timing is fortuitous, as I just finished rewriting the code for 
mixed-commit handling and it is fresh in my mind.

The old behavior was indeed that cliques were lexicographically ordered
by branch.  This was not documented.  The master branch still uses the
old code.

Current behavior on my development branch is that fileops are not
sorted before splitting; you get whatever order they had in the dump.
I will change this so they are sorted by pathname and document that.

And...it's done.

You won't see the new code for a few days, until I finish the analyzer
rewrite.  The old code had become overgrown and brittle; I spent a
week trying to find a strategy to get around a particular
pathological-tag defect only to discover that I could no longer
modify the analyzer without cascade bugs.

I'll describe the problem, since I think the GCC repository has some
of these and they may explain some of your earlier bug reports.

Suppose you create a tag, then later on modify the tag copy by
copying to one of its subdirectories.  When translating to git
you want to attach the tag reference to the revision the *second*
copy came from.  Simple in concept but the obvious implementation
of root-finding prefers the earliest copy.

When it proved impossible to change this wthout producing a cascade of
breakage, I faced up to the necessity of a scrap-and-rebuild.  It's
not done yet, but it's pretty well advanced.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

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

[Bernd Schmidt]

On 11/26/19 3:21 AM, Joseph Myers wrote:
> 
> The soft-float ColdFire build (--with-arch=cf --with-cpu=54455 
> --disable-multilib) successfully built libgcc and glibc, but ran into an 
> ICE building the glibc tests.  Again, I've not bisected but this commit 
> seems likely to be responsible.  Compile the attached preprocessed source 
> with -O2.

Try the following. This seems to be the same (preexisting) problem which
got fixed for the normal 68k compare patterns, where an operand with
nonimmediate_operand predicate allows constants in its constraints.


Bernd
diff --git a/gcc/config/m68k/m68k.md b/gcc/config/m68k/m68k.md
index 25e0b73741f..d6df385787a 100644
--- a/gcc/config/m68k/m68k.md
+++ b/gcc/config/m68k/m68k.md
@@ -496,7 +496,7 @@
 ;; needs to be reloaded.
 
 (define_mode_attr scc0_cf_constraints [(QI "=d") (HI "=d") (SI "=d,d,d")])
-(define_mode_attr cmp1_cf_constraints [(QI "dm") (HI "dm") (SI "mrKs,r,rm")])
+(define_mode_attr cmp1_cf_constraints [(QI "dm") (HI "dm") (SI "mr,r,rm")])
 (define_mode_attr cmp2_cf_constraints [(QI "C0") (HI "C0") (SI "r,mrKs,C0")])
 (define_mode_attr cmp2_cf_predicate [(QI "const0_operand") (HI "const0_operand") (SI "general_operand")])
 

[Bug tree-optimization/92649] dead store elimination

[jiangning.liu at amperecomputing dot com]

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

--- Comment #5 from Jiangning Liu  ---
Unrolling 1024 iterations would increase code size a lot, so usually we don't
do that. 1024 is only an example. Without knowing we could eliminate most of
them, we don't really want to do loop unrolling, I guess.

Yes. Assigning 5 to all a's elements is only an example as well. It could be
any random value or predefined number.

Let me give a more complicated case,

extern int rand(void);

#define LIVE_SIZE 100
#define DATA_SIZE 256

int f(void)
{
int a[DATA_SIZE], b[DATA_SIZE][DATA_SIZE];
int i,j;
long long s = 0;
int next;

for (i=0; i

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

[Joseph Myers]

On Tue, 26 Nov 2019, Bernd Schmidt wrote:

> On 11/26/19 1:36 AM, Joseph Myers wrote:
> > I'm seeing a libgcc build failure for coldfire in my build-many-glibcs.py 
> > bot (m68k-linux-gnu configured --with-arch=cf --disable-multilib).  That's 
> > building _mulsc3.o; I get assembler errors:
> 
> I overlooked a difference in the 68881 vs coldfire patterns when I
> combined them. They use different suffixes for register compares (I only
> spotted the different constraints).
> 
> The following seems to fix the assembler failures. I cannot properly
> test Coldfire however due to lack of hardware.

Thanks for fixing this (this is not a review of the patch).

The soft-float ColdFire build (--with-arch=cf --with-cpu=54455 
--disable-multilib) successfully built libgcc and glibc, but ran into an 
ICE building the glibc tests.  Again, I've not bisected but this commit 
seems likely to be responsible.  Compile the attached preprocessed source 
with -O2.

during RTL pass: jump2
test-strncmp.c: In function 'test_main':
test-strncmp.c:477:1: internal compiler error: in patch_jump_insn, at 
cfgrtl.c:1291
0x767a92 patch_jump_insn
/scratch/jmyers/glibc/many10/src/gcc/gcc/cfgrtl.c:1290
0x767b9f redirect_branch_edge
/scratch/jmyers/glibc/many10/src/gcc/gcc/cfgrtl.c:1317
0x76a722 rtl_redirect_edge_and_branch
/scratch/jmyers/glibc/many10/src/gcc/gcc/cfgrtl.c:1450
0x752e09 redirect_edge_and_branch(edge_def*, basic_block_def*)
/scratch/jmyers/glibc/many10/src/gcc/gcc/cfghooks.c:373
0x122555c try_forward_edges
/scratch/jmyers/glibc/many10/src/gcc/gcc/cfgcleanup.c:562
0x122555c try_optimize_cfg
/scratch/jmyers/glibc/many10/src/gcc/gcc/cfgcleanup.c:2960
0x1226a8d cleanup_cfg(int)
/scratch/jmyers/glibc/many10/src/gcc/gcc/cfgcleanup.c:3174
0x1226cb8 execute
/scratch/jmyers/glibc/many10/src/gcc/gcc/cfgcleanup.c:3354
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

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

test-strncmp.i.gz
Description: application/gzip

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

[Bernd Schmidt]

On 11/26/19 1:36 AM, Joseph Myers wrote:
> I'm seeing a libgcc build failure for coldfire in my build-many-glibcs.py 
> bot (m68k-linux-gnu configured --with-arch=cf --disable-multilib).  That's 
> building _mulsc3.o; I get assembler errors:

I overlooked a difference in the 68881 vs coldfire patterns when I
combined them. They use different suffixes for register compares (I only
spotted the different constraints).

The following seems to fix the assembler failures. I cannot properly
test Coldfire however due to lack of hardware.


Bernd
	* config/m68k/,68k.c (m68k_output_compare_fp): Use .d instead of .x
	for register compares on Coldfire.

diff --git a/gcc/config/m68k/m68k.c b/gcc/config/m68k/m68k.c
index 8d010ebe6e9..4b30c401e80 100644
--- a/gcc/config/m68k/m68k.c
+++ b/gcc/config/m68k/m68k.c
@@ -4501,7 +4501,12 @@ m68k_output_compare_fp (rtx op0, rtx op1, rtx_code code)
   if (op1 == CONST0_RTX (GET_MODE (op0)))
 {
   if (FP_REG_P (op0))
-	output_asm_insn ("ftst%.x %0", ops);
+	{
+	  if (TARGET_COLDFIRE_FPU)
+	output_asm_insn ("ftst%.d %0", ops);
+	  else
+	output_asm_insn ("ftst%.x %0", ops);
+	}
   else
 	output_asm_insn (("ftst%." + prec + " %0").c_str (), ops);
   return code;
@@ -4510,7 +4515,10 @@ m68k_output_compare_fp (rtx op0, rtx op1, rtx_code code)
   switch (which_alternative)
 {
 case 0:
-  output_asm_insn ("fcmp%.x %1,%0", ops);
+  if (TARGET_COLDFIRE_FPU)
+	output_asm_insn ("fcmp%.d %1,%0", ops);
+  else
+	output_asm_insn ("fcmp%.x %1,%0", ops);
   break;
 case 1:
   output_asm_insn (("fcmp%." + prec + " %f1,%0").c_str (), ops);

Re: Add a new combine pass

[Segher Boessenkool]

On Mon, Nov 25, 2019 at 11:08:47PM +, Richard Sandiford wrote:
> Segher Boessenkool  writes:
> > On Mon, Nov 25, 2019 at 09:16:52PM +, Richard Sandiford wrote:
> >> Segher Boessenkool  writes:
> >> > I am wondering the other way around :-)  Is what you do for combine2
> >> > something that would be more generally applicable/useful?  That's what
> >> > I'm trying to find out :-)
> >> >
> >> > What combine does could use some improvement, if you want to hear a
> >> > more direct motivations.  LOG_LINKS just skip references we cannot
> >> > handle (and some more), so we always have to do modified_between etc.,
> >> > which hurts.
> >> 
> >> The trade-offs behind the choice of representation are very specific
> >> to the pass.
> >
> > Yes, but hopefully not so specific that every pass needs a completely
> > different representation ;-)
> 
> Well, it depends.  Most passes make do with df (without DU/UD-chains).
> But since DU/UD-chains are naturally quadratic in the general case,
> and are expensive to keep up to date, each DU/UD pass is going to have
> make some compromises.  It doesn't seem too bad that passes make
> different compromises based on what they're trying to do.  (combine:
> single use per definition; fwprop.c: track all uses, but for dominating
> definitions only; sched: fudged via a param; regrename: single
> definition/multiple use chains optimised for renmaing; combine2: full
> live range information, but limited use list; etc.)

combine actually *calculates* DU chains almost completely, it just throws
away most of that information (it wants to have LOG_LINKS, as it did ages
ago).  The only thing stopping us from doing that right now is that not
all uses are counted (some are skipped).

Since combine works only within BBs, DU chains are linear to compute, and
UD chains are trivial (and just linear to compute).

Updating is quadratic in general, sure.  Luckily in most realistic cases
it is cheap (most, sigh) (insns aren't combined to very far away).

> So yeah, if passes want to make roughly the same compromises, it would
> obviously be good if they shared a representation.  But since each pass
> does something different, I don't think it's a bad sign that they make
> different compromises and use different representations.
> 
> So I don't think a new pass with a new representation is in itself a
> sign of failure.

Oh, I don't think so either.  I just wonder if it would be useful more
generically :-)

> >> >> >> Target Tests   DeltaBest   Worst  Median
> >> >> >> avr-elf 1341 -111401  -13824 680 -10
> >> >> >
> >> >> > Things like this are kind of suspicious :-)
> >> >> 
> >> >> Yeah.  This mostly seems to come from mopping up the extra moves created
> >> >> by make_more_copies.  So we have combinations like:
> >> >> 
> >> >>58: r70:SF=r94:SF
> >> >>   REG_DEAD r94:SF
> >> >>60: r22:SF=r70:SF
> >> >>   REG_DEAD r70:SF
> >> >
> >> > Why didn't combine do this?  A target problem?
> >> 
> >> Seems to be because combine rejects hard-reg destinations whose classes
> >> are likely spilled (cant_combine_insn_p).
> >
> > Ah, okay.  And that is required to prevent ICEs, in combine2 as well
> > then -- ICEs in RA.
> 
> Not in this case though.  The final instruction is a hardreg<-pseudo move
> whatever happens.  There's nothing special about r70 compared to r94.

So the target hook could be improved?  Or, this doesn't matter anyway,
the extra register move does not prevent any combinations, and RA should
get rid of it when that is beneficial.

But you see smaller code in the end, hrm.


Segher

[Bug target/92651] [10 Regression] Unnecessary stv transform in some x86 backend

[wwwhhhyyy333 at gmail dot com]

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

--- Comment #5 from Hongyu Wang  ---
(In reply to Jakub Jelinek from comment #3)
> Do you mean r274481 rather than r277481, right?

Yes. Thanks for your correction.

[Bug target/92651] [10 Regression] Unnecessary stv transform in some x86 backend

[wwwhhhyyy333 at gmail dot com]

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

--- Comment #4 from Hongyu Wang  ---
(In reply to Richard Biener from comment #2)
> Btw, which variant is actually the fastest for you?   abs expansion doesn't
> do any cost comparison but just uses direct abs, max and then the xor with
> shift as third option (and after that fall back to compare & jump which later
> might be if-converted into cmov).

Actually the xor with shift is could be the fastest, which improves about 8% on
525.x264_r comparing to the pmaxsd one, and with cmove the improvement is 6.5%.

I don't think this conversion should happen on every cmove instruction,
regardless of how many sse register it would use. I think the simplest way to
avoid this is adjusting the cost.

Re: [PATCH] V7, #4 of 7, Add explicit (0),1 to @pcrel references

[Segher Boessenkool]

On Mon, Nov 25, 2019 at 05:52:29PM -0500, Michael Meissner wrote:
> On Fri, Nov 22, 2019 at 06:52:42PM -0600, Segher Boessenkool wrote:
> > On Thu, Nov 14, 2019 at 05:51:14PM -0500, Michael Meissner wrote:
> > > In some of my previous work, I had make a mistake forgetting that the 
> > > PADDI
> > > instruction did not allow adding a PC-relative reference to a register 
> > > (you can
> > > either load up a PC-relative address without adding a register, or you 
> > > can add
> > > a register to a constant).  The assembler allowed the instruction, but it
> > > didn't do what I expected.
> > 
> > So, what was the instruction?
> 
> If you write:
> 
>   paddi 10,9,foo@pcrel
> 
> The assembler will interpret this as:
> 
>   paddi 10,9,(.-foo),0
> 
> I.e. it will add the difference from current instruction to foo and register 2
> and place it in register 10.  But it will not add the current location for the
> paddi.
> 
> Of course it might make sense if the assembler could flag the first line as an
> error, and if you really wanted to write that, you should use:
> 
>   paddi 10,9,foo@pcrel,0

Does it ever make sense to allow @pcrel on anything that is not prefixed
and R=1?  (Cc: Alan).

> > Can you fix this in the caller?
> 
> Since the code was invalid, the add insn modification to allow adding an
> address has been removed.  It was a suggestion after I made the mistake to 
> make
> sure that nobody else would make that mistake.
> 
> As I said, this is an optional patch.  The idea was to be helpful to other
> people in the future, in that if they try to generate an add between a 
> register
> and a PC-relative label, that the assembler would give a warnging (due to 
> (0),1
> present).
> 
> If you don't think it is important to do that protection, I can leave it out.

That isn't what I said.  I'm not happy with how you implemented this,
that's all.


Segher

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

[Joseph Myers]

On Mon, 25 Nov 2019, Rainer Orth wrote:

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

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

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

Re: Properly handle C2x attributes on types

[Joseph Myers]

On Mon, 25 Nov 2019, Rainer Orth wrote:

> it seems you missed updating a couple of testcases that are ia32-only:

I think it's unavoidable that such target-specific testcases need updating 
by someone testing on the target in question.

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

Re: [PATCH], V7, #3 of 7, Use PADDI for 34-bit immediate adds

[Segher Boessenkool]

On Mon, Nov 25, 2019 at 05:40:02PM -0500, Michael Meissner wrote:
> On Fri, Nov 22, 2019 at 06:32:08PM -0600, Segher Boessenkool wrote:
> > On Thu, Nov 14, 2019 at 05:44:42PM -0500, Michael Meissner wrote:
> > > This patch generates PADDI to add 34-bit immediate constants on the 
> > > 'future'
> > > system, and prevents such adds from being split.
> > 
> > I don't see that last part?  Is that a remnant of a previous version of
> > the patch?
> 
> This falls out of the add_operand change.



> Since non_add_cint_operand is defined as:
> 
> (define_predicate "non_add_cint_operand"
>   (and (match_code "const_int")
>(not (match_operand 0 "add_operand"
> 
> It follows that if add_operand now allows a 34-bit constant when -mcpu=future,
> that non_add_cint_operand will return 0, and the add will not be split.

Right, so write that please ("changes add_operand"), not some random
consequence of that change.

> > >   * config/rs6000/rs6000.md (add3): Add support for PADDI.
> > 
> > (add3 for GPR): etc.
> > 
> > We have six things all called add3 (VI2, DDTD, SDI, SFDF, IEEE128,
> > VEC_F).  Erm.
> > 
> > Wait, this is called *add3, not add3.
> 
> Yeah, I usually add the iterator part to identify which one was changed.

No, the asterisk is part of the name, that's my point.  And yes please
say what the iterator is.


Segher

Re: [PATCH], V7, #2 of 7, Use PLI to load up 32-bit SImode constants

[Segher Boessenkool]

On Mon, Nov 25, 2019 at 05:17:08PM -0500, Michael Meissner wrote:
> On Fri, Nov 22, 2019 at 06:20:52PM -0600, Segher Boessenkool wrote:
> > >  (define_split
> > >[(set (match_operand:SI 0 "gpc_reg_operand")
> > >   (match_operand:SI 1 "const_int_operand"))]
> > >"(unsigned HOST_WIDE_INT) (INTVAL (operands[1]) + 0x8000) >= 0x1
> > > -   && (INTVAL (operands[1]) & 0x) != 0"
> > > +   && (INTVAL (operands[1]) & 0x) != 0 && !TARGET_PREFIXED_ADDR"
> > >[(set (match_dup 0)
> > >   (match_dup 2))
> > > (set (match_dup 0)
> > 
> > Please use num_insns_constant, instead (and fix num_insns_constant_gpr
> > so it knows about SIGNED_34BIT).
> 
> The previous patch V6 #1 already had the modification for
> num_insns_constant_gpr.

It's not in trunk yet?


Segher

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

[Joseph Myers]

On Mon, 25 Nov 2019, Bernd Schmidt wrote:

> On 11/23/19 6:36 PM, Jeff Law wrote:
> 
> > Not really.  I've already indicated to Bernd that he should go ahead and
> > commit the changes and we can iterate on any problems that arise.
> 
> After the last fix, I did some more testing and since I feel confident
> that it really is in good shape now, I committed it. Thanks!

I'm seeing a libgcc build failure for coldfire in my build-many-glibcs.py 
bot (m68k-linux-gnu configured --with-arch=cf --disable-multilib).  That's 
building _mulsc3.o; I get assembler errors:

/tmp/ccvO6ZQR.s: Assembler messages:
/tmp/ccvO6ZQR.s:81: Error: invalid instruction for this architecture; 
needs M68K fpu (68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 
68060 [68ec060], cpu32 [68330, 68331, 68332, 68333, 68334, 68336, 68340, 
68341, 68349, 68360]) -- statement `fcmp.x %fp0,%fp0' ignored
/tmp/ccvO6ZQR.s:98: Error: invalid instruction for this architecture; 
needs M68K fpu (68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 
68060 [68ec060], cpu32 [68330, 68331, 68332, 68333, 68334, 68336, 68340, 
68341, 68349, 68360]) -- statement `fcmp.x %fp1,%fp1' ignored

I've not bisected, but r278642 was OK and r278694 had the failure, so I'm 
guessing it's probably this patch.

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

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

[Jakub Jelinek]

Hi!

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

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

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

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

2019-11-26  Jakub Jelinek  

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

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

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

Jakub

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

[Jakub Jelinek]

Hi!

On Mon, Nov 25, 2019 at 03:46:23PM +0100, Jakub Jelinek wrote:
> On Mon, Nov 25, 2019 at 03:39:32PM +0100, Jakub Jelinek wrote:
> > I guess the question is, shall we store the minimum precision needed
> > somewhere by finish_enum_value_list (perhaps only bother if the precision
> > of the underlying type is not the same) or compute it each time again
> > (which would mean for each bitfield of enum type walk the list of all the
> > enum values)?  And, if we should store it somewhere, any preferences where?
> > These days C++ FE has TYPE_LANG_SPECIFIC just for classes, so options are
> > just use the class TYPE_LANG_SPECIFIC and just stick the min/max values in
> > some trees in there, restore having different lang specific variants and
> > store just minimum precision in there, add hash map from tree (hashed using
> > TYPE_UID) to precision, something else?
> 
> Or yet another possibility, only compute it on demand and use a hash map as
> cache.

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

2019-11-26  Jakub Jelinek  

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

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

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

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

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

[Jakub Jelinek]

Hi!

The following testcase ICEs, because we assert the only constants with
NULLPTR_TYPE created are 0.

The fix is to perform the value adjustment of boundary value and EQ/NE
conversion to other comparisons only for scalar integral types, not anything
that happens to be INTEGER_CST (other types are pointers/references or
NULLPTR_TYPE, maybe something else).

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

2019-11-26  Jakub Jelinek  

PR tree-optimization/92644
* tree-ssa-phiopt.c (minmax_replacement): Add INTEGRAL_TYPE_P check
next to INTEGER_CST checks.

* g++.dg/opt/pr92644.C: New test.

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

Jakub

Re: [Patch, Fortran] dec comparisons - for approval

[Jakub Jelinek]

On Fri, Nov 22, 2019 at 12:33:47PM +0100, Tobias Burnus wrote:
> >     Mark Eggleston 
> >     Jim MacArthur 
> > 
> >     * gfortran.dg/dec-comparison.f90: New test.

This test is UNRESOLVED everywhere, a test which expects dg-error diagnostic
really can't be dg-do run, as for erroneous sources no executable is
produced.

Fixed thusly, tested on x86_64-linux, committed to trunk as obvious:

2019-11-26  Jakub Jelinek  

* gfortran.dg/dec-comparison.f90: Change dg-do from run to compile.

--- gcc/testsuite/gfortran.dg/dec-comparison.f90.jj 2019-11-25 
22:44:22.187388294 +0100
+++ gcc/testsuite/gfortran.dg/dec-comparison.f902019-11-26 
00:23:08.669581035 +0100
@@ -1,4 +1,4 @@
-! { dg-do run }
+! { dg-do compile }
 ! { dg-options "-fdec" }
 !
 ! Test case contributed by Mark Eggleston  
@@ -38,4 +38,3 @@ program convert
   if (a.ne.d) stop 17 ! { dg-error "Operands of comparison" }
   if (d.eq.a) stop 18 ! { dg-error "Operands of comparison" }
 end program
-


Jakub

[Bug c/92668] [9/10 Regression] -Wtautological-compare warns for macros that expand to the same symbol, inconsistent with C++

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
Isn't this the same as bug 70477?

Re: Add a new combine pass

[Richard Sandiford]

Segher Boessenkool  writes:
> Hi!
>
> On Mon, Nov 25, 2019 at 09:16:52PM +, Richard Sandiford wrote:
>> Segher Boessenkool  writes:
>> > I am wondering the other way around :-)  Is what you do for combine2
>> > something that would be more generally applicable/useful?  That's what
>> > I'm trying to find out :-)
>> >
>> > What combine does could use some improvement, if you want to hear a
>> > more direct motivations.  LOG_LINKS just skip references we cannot
>> > handle (and some more), so we always have to do modified_between etc.,
>> > which hurts.
>> 
>> The trade-offs behind the choice of representation are very specific
>> to the pass.
>
> Yes, but hopefully not so specific that every pass needs a completely
> different representation ;-)

Well, it depends.  Most passes make do with df (without DU/UD-chains).
But since DU/UD-chains are naturally quadratic in the general case,
and are expensive to keep up to date, each DU/UD pass is going to have
make some compromises.  It doesn't seem too bad that passes make
different compromises based on what they're trying to do.  (combine:
single use per definition; fwprop.c: track all uses, but for dominating
definitions only; sched: fudged via a param; regrename: single
definition/multiple use chains optimised for renmaing; combine2: full
live range information, but limited use list; etc.)

So yeah, if passes want to make roughly the same compromises, it would
obviously be good if they shared a representation.  But since each pass
does something different, I don't think it's a bad sign that they make
different compromises and use different representations.

So I don't think a new pass with a new representation is in itself a
sign of failure.

>> >> >> Target Tests   DeltaBest   Worst  Median
>> >> >> avr-elf 1341 -111401  -13824 680 -10
>> >> >
>> >> > Things like this are kind of suspicious :-)
>> >> 
>> >> Yeah.  This mostly seems to come from mopping up the extra moves created
>> >> by make_more_copies.  So we have combinations like:
>> >> 
>> >>58: r70:SF=r94:SF
>> >>   REG_DEAD r94:SF
>> >>60: r22:SF=r70:SF
>> >>   REG_DEAD r70:SF
>> >
>> > Why didn't combine do this?  A target problem?
>> 
>> Seems to be because combine rejects hard-reg destinations whose classes
>> are likely spilled (cant_combine_insn_p).
>
> Ah, okay.  And that is required to prevent ICEs, in combine2 as well
> then -- ICEs in RA.

Not in this case though.  The final instruction is a hardreg<-pseudo move
whatever happens.  There's nothing special about r70 compared to r94.

> There should be a better way to do this.

ISTM we should be checking for whichever cases actually cause the
RA failures.  E.g. to take on extreme example, if all the following
are true:

- an insn has a single alternative
- an insn has a single non-earyclobber output
- an insn has no parallel clobbers
- an insn has no auto-inc/decs
- an insn has a hard register destination that satisfies its constraints
- the hard register is defined in its original location

then there should be no problem.  The insn shouldn't need any output
reloads that would conflict with the hard register.  It also doesn't
extend the live range of the output.

Obviously that's a lot of conditions :-)  And IMO they should be built
up the other way around: reject specific cases that are known to cause
problems, based on information about the matched insn.  But I think the
avr example shows that there's a real problem with using REGNO_REG_CLASS
for this too.  REGNO_REG_CLASS gives the smallest enclosing class, which
might not be the most relevant one in context.  (It isn't here, since
we're just passing arguments to functions.)

>> This SF argument register
>> happens to overlap POINTER_X_REGS and POINTER_Y_REGS and so we reject
>> the combination based on POINTER_X_REGS being likely spilled.
>
> static bool
> avr_class_likely_spilled_p (reg_class_t c)
> {
>   return (c != ALL_REGS &&
>(AVR_TINY ? 1 : c != ADDW_REGS));
> }
>
> So this target severely shackles combine.  Does it have to?  If so, why
> not with combine2?

As far as the above example goes, I think returning true for
POINTER_X_REGS is the right thing to do.  It only has two 8-bit
registers, and they act as a pair when used as a pointer.

Thanks,
Richard

Re: [PATCH] V7, #1 of 7, Use PLI to load up 34-bit DImode constants

[Segher Boessenkool]

Hi Mike,

On Mon, Nov 25, 2019 at 05:09:10PM -0500, Michael Meissner wrote:
> On Fri, Nov 22, 2019 at 06:06:19PM -0600, Segher Boessenkool wrote:
> > > --- gcc/config/rs6000/rs6000.c(revision 278173)
> > > +++ gcc/config/rs6000/rs6000.c(working copy)
> > > @@ -5552,7 +5552,7 @@ static int
> > >  num_insns_constant_gpr (HOST_WIDE_INT value)
> > >  {
> > >/* signed constant loadable with addi */
> > > -  if (((unsigned HOST_WIDE_INT) value + 0x8000) < 0x1)
> > > +  if (SIGNED_16BIT_OFFSET_P (value))
> > >  return 1;
> > 
> > Hrm, so the SIGNED_nBIT_OFFSET_P should not be called "offset", if we use
> > them for other numbers as well.

Please do something about this?  Not in this patch, of course.

> Is this what you want?

Yeah, like that.

Please send a patch doing *only* this typographical change -- no code
changes at all -- before patches that change the code.  Or, alternatively,
just split up lines that you are touching anyway, and eventually we will
get something nice.

Either option is much easier to review than patches moving 60 constraints
around :-)

This is general advice: if you want to rearrange some code, or fix (some
non-trivial) white space, etc., do that in a separate patch *before* the
rest.  Same as with bugfixes.

That way, it can be immediately applied, whether the rest of the patches
needs further revisions or not.  And it makes reviewing the rest a lot
easier too.

> Now, this is without moving any of the alternatives around.  Logically, you
> could move gpr/fpr/vsx moves to be together (and maybe the direct moves also).
> But I dunno whether this is getting into bike shedding.

Yeah you cannot always move things the way you like them, the ordering
also matters for RA itself (sometimes).  It's all not a big deal except
we have so very very many alternatives in the mov patterns.


Segher

Re: [PATCH] V7, #4 of 7, Add explicit (0),1 to @pcrel references

[Michael Meissner]

On Fri, Nov 22, 2019 at 06:52:42PM -0600, Segher Boessenkool wrote:
> On Thu, Nov 14, 2019 at 05:51:14PM -0500, Michael Meissner wrote:
> > In some of my previous work, I had make a mistake forgetting that the PADDI
> > instruction did not allow adding a PC-relative reference to a register (you 
> > can
> > either load up a PC-relative address without adding a register, or you can 
> > add
> > a register to a constant).  The assembler allowed the instruction, but it
> > didn't do what I expected.
> 
> So, what was the instruction?

If you write:

paddi 10,9,foo@pcrel

The assembler will interpret this as:

paddi 10,9,(.-foo),0

I.e. it will add the difference from current instruction to foo and register 2
and place it in register 10.  But it will not add the current location for the
paddi.

Of course it might make sense if the assembler could flag the first line as an
error, and if you really wanted to write that, you should use:

paddi 10,9,foo@pcrel,0

> > --- gcc/config/rs6000/rs6000.c  (revision 278175)
> > +++ gcc/config/rs6000/rs6000.c  (working copy)
> > @@ -13241,7 +13241,10 @@ print_operand_address (FILE *file, rtx x
> >if (SYMBOL_REF_P (x) && !SYMBOL_REF_LOCAL_P (x))
> > fprintf (file, "@got");
> >  
> > -  fprintf (file, "@pcrel");
> > +  /* Specifically add (0),1 to catch uses where a @pcrel was added to 
> > a an
> > +address with a base register, since the hardware does not support
> > +adding a base register to a PC-relative address.  */
> > +  fprintf (file, "@pcrel(0),1");
> 
> But this is print_operand_address, it shouldn't know anything about
> specific instructions, it certainly shouldn't print commas and other
> fields.
> 
> Can you fix this in the caller?

Since the code was invalid, the add insn modification to allow adding an
address has been removed.  It was a suggestion after I made the mistake to make
sure that nobody else would make that mistake.

As I said, this is an optional patch.  The idea was to be helpful to other
people in the future, in that if they try to generate an add between a register
and a PC-relative label, that the assembler would give a warnging (due to (0),1
present).

If you don't think it is important to do that protection, I can leave it out.

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

Re: Add a new combine pass

[Segher Boessenkool]

On Mon, Nov 25, 2019 at 09:40:36PM +, Richard Sandiford wrote:
> Segher Boessenkool  writes:
> > - i386 goes into an infinite loop compiling, or at least an hour or so...
> > Erm I forgot too record what it was compiling.  I did attach a GDB...  It
> > is something from lra_create_live_ranges.
> 
> Hmm.

This one is actually worrying me -- it's not obviously a simple problem,
or a target problem, or a pre-existing problem.

> Ah, this'll be while m68k was still a cc0 target.  Yeah, I should probably
> just skip the whole pass for cc0.

Yes, tree of last friday or saturday or so.

And yup if you don't handle cc0 yet, yes you want to skip it completely :-)

> > - sh (that's sh4-linux):
> >
> > /home/segher/src/kernel/net/ipv4/af_inet.c: In function 
> > 'snmp_get_cpu_field':
> > /home/segher/src/kernel/net/ipv4/af_inet.c:1638:1: error: unable to find a 
> > register to spill in class 'R0_REGS'
> >  1638 | }
> >   | ^
> > /home/segher/src/kernel/net/ipv4/af_inet.c:1638:1: error: this is the insn:
> > (insn 18 17 19 2 (set (reg:SI 0 r0)
> > (mem:SI (plus:SI (reg:SI 4 r4 [178])
> > (reg:SI 6 r6 [171])) [17 *_3+0 S4 A32])) 
> > "/home/segher/src/kernel/net/ipv4/af_inet.c":1638:1 188 {movsi_i}
> >  (expr_list:REG_DEAD (reg:SI 4 r4 [178])
> > (expr_list:REG_DEAD (reg:SI 6 r6 [171])
> > (nil
> > /home/segher/src/kernel/net/ipv4/af_inet.c:1638: confused by earlier 
> > errors, bailing out
> 
> Would have to look more at this one.  Seems odd that it can't allocate
> R0 when it's already the destination and when R0 can't be live before
> the insn.  But there again, this is reload, so my enthuasiasm for looking
> is a bit limited :-)

It wants to use r0 in some other insn, so it needs to spill it here, but
cannot.  This is what class_likely_spilled is for.

> > Looking at just binary size, which is a good stand-in for how many insns
> > it combined:
> >
> > R2
> >arm64   99.709%
> > ia64   99.651%
> > s390   99.734%
> >sparc   99.877%
> >  sparc64  100.011%
> >
> > (These are those that are not between 99.9% and 100.0%).
> >
> > So only sparc64 regressed, and just a tiny bit (I can look at what that
> > is, if there is interest).  But 32-bit sparc improved, and s390, arm64,
> > and ia64 got actual benefit.
> >
> > Again this is just code size, not analysing the actually changed code.
> 
> OK.  Certainly not an earth-shattering improvement then, but not
> entirely worthless either.

I usually takes 0.2% as "definitely useful" for combine improvements, so
there are a few targets that have that.  There can be improvements that
are important for a target even if they do not improve code size much,
of course, and it can identify weaknesses in the backend code, so you
always need to look at what really changes.

> I see combine also tests cannot_copy_insn_p.  I'm not sure whether that's
> appropriate for the new pass or not.  Arguably it's not copying the
> instruction, it's just moving it to be in parallel with something else.
> (But then that's largely true of the combine case too.)

combine tests this only for the cases where it *does* have to copy an
insn: when the dest if i0, i1, or i2 doesn't die, it is added as another
arm to the (parallel) result.


Segher

Re: [PATCH], V7, #3 of 7, Use PADDI for 34-bit immediate adds

[Michael Meissner]

On Fri, Nov 22, 2019 at 06:32:08PM -0600, Segher Boessenkool wrote:
> On Thu, Nov 14, 2019 at 05:44:42PM -0500, Michael Meissner wrote:
> > This patch generates PADDI to add 34-bit immediate constants on the 'future'
> > system, and prevents such adds from being split.
> 
> I don't see that last part?  Is that a remnant of a previous version of
> the patch?

This falls out of the add_operand change.

The add splitter is:

;; Split an add that we can't do in one insn into two insns, each of which
;; does one 16-bit part.  This is used by combine.  Note that the low-order
;; add should be last in case the result gets used in an address.

(define_split
  [(set (match_operand:GPR 0 "gpc_reg_operand")
(plus:GPR (match_operand:GPR 1 "gpc_reg_operand")
  (match_operand:GPR 2 "non_add_cint_operand")))]
  ""
  [(set (match_dup 0) (plus:GPR (match_dup 1) (match_dup 3)))
   (set (match_dup 0) (plus:GPR (match_dup 0) (match_dup 4)))]
{
  HOST_WIDE_INT val = INTVAL (operands[2]);
  HOST_WIDE_INT low = ((val & 0x) ^ 0x8000) - 0x8000;
  HOST_WIDE_INT rest = trunc_int_for_mode (val - low, mode);

  operands[4] = GEN_INT (low);
  if (mode == SImode || satisfies_constraint_L (GEN_INT (rest)))
operands[3] = GEN_INT (rest);
  else if (can_create_pseudo_p ())
{
  operands[3] = gen_reg_rtx (DImode);
  emit_move_insn (operands[3], operands[2]);
  emit_insn (gen_adddi3 (operands[0], operands[1], operands[3]));
  DONE;
}
  else
FAIL;
})

Since non_add_cint_operand is defined as:

(define_predicate "non_add_cint_operand"
  (and (match_code "const_int")
   (not (match_operand 0 "add_operand"

It follows that if add_operand now allows a 34-bit constant when -mcpu=future,
that non_add_cint_operand will return 0, and the add will not be split.

> > * config/rs6000/predicates.md (add_operand): Add support for
> > PADDI.
> 
> More directly: Allow constants that satisfy eI.

Ok.

> > * config/rs6000/rs6000.md (add3): Add support for PADDI.
> 
> (add3 for GPR): etc.
> 
> We have six things all called add3 (VI2, DDTD, SDI, SFDF, IEEE128,
> VEC_F).  Erm.
> 
> Wait, this is called *add3, not add3.

Yeah, I usually add the iterator part to identify which one was changed.
> 
> Okay for trunk with that fixed.  Thanks,
> 
> 
> Segher

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

[Bug c/92668] [9/10 Regression] -Wtautological-compare warns for macros that expand to the same symbol, inconsistent with C++

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-25
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Hmm, I wonder why

 473   /* If both are in a macro, only warn if they're spelled the same. 
*/
 474   if (!spelled_the_same_p (EXPR_LOCATION (lhs), EXPR_LOCATION (rhs)))
 475 return;

in warn_tautological_cmp doesn't trigger.  Confirmed to make one FE behave as
the other.

[Bug c/92668] [9/10 Regression] -Wtautological-compare warns for macros that expand to the same symbol, inconsistent with C++

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
Summary|-Wtautological-compare  |[9/10 Regression]
   |warns for macros that   |-Wtautological-compare
   |expand to the same symbol   |warns for macros that
   ||expand to the same symbol,
   ||inconsistent with C++

--- Comment #1 from Martin Sebor  ---
Bisection points to r226242 when the warning option was introduced so it's not
a regression.  The C++ front-end warns at that revision as well, but stopped
warning in 9.0 as of r267272: C++: more location wrapper nodes (PR c++/43064,
PR c++/43486).  So what appears to be a "regression" is actually losing the
warning in C++.  I think the fix should be a) to avoid the warning in C, and b)
ensure the warning is suppressed in C++ as a feature, not as an accident of the
location wrapper, and that it doesn't come back.

[Bug libfortran/92569] [8/9 Regression] gfortran read with end directive does not trigger with -ffrontend-optimize

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Thomas Koenig  ---
Fixed on all affected branches, closing.

Thanks for the bug report!

[Bug libfortran/92569] [8/9 Regression] gfortran read with end directive does not trigger with -ffrontend-optimize

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Nov 25 22:26:26 2019
New Revision: 278710

URL: https://gcc.gnu.org/viewcvs?rev=278710=gcc=rev
Log:
Fix EOF handling for arrays.

2019-11-25  Thomas Koenig  
Harald Anlauf 

Backport from trunk
PR fortran/92569
* io/transfer.c (transfer_array_inner):  If position is
at AFTER_ENDFILE in current unit, return from data loop.

2019-11-25  Thomas Koenig  
Harald Anlauf 

Backport from trunk
PR fortran/92569
* gfortran.dg/eof_6.f90: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/eof_6.f90
Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/libgfortran/ChangeLog
branches/gcc-8-branch/libgfortran/io/transfer.c

[Bug c/92668] New: -Wtautological-compare warns for macros that expand to the same symbol

[msebor at gcc dot gnu.org]

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

Bug ID: 92668
   Summary: -Wtautological-compare warns for macros that expand to
the same symbol
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Unlike the C++ front-end and unlike Clang, the C front-end issues
-Wtautological-compare for comparisons involving distinct macros that expand to
the same symbol.  GCC should be consistent with itself, and what Clang does
seems reasonable, so probably also with it.

$ cat t.c && gcc -S -Wall -Wextra -Wtautological-compare t.c
int a;

#define X a
#define Y a

int f (void)
{
  if (X == Y) return 1;
  return 0;
}
t.c: In function ‘f’:
t.c:8:9: warning: self-comparison always evaluates to true
[-Wtautological-compare]
8 |   if (X == Y) return 1;
  | ^~

Re: [PATCH] C++20 P1032 for __debug::array

[Jonathan Wakely]

On 25/11/19 22:34 +0100, François Dumont wrote:

I plan to commit this tomorrow.


Thanks.

But I really wonder if we couldn't just add some __glibcxx_checks_xxx 
in std/array ?


That probably makes sense. std::array::iterator is just T* so we
don't get debug iterators anyway.

Re: [PATCH], V7, #2 of 7, Use PLI to load up 32-bit SImode constants

[Michael Meissner]

On Fri, Nov 22, 2019 at 06:20:52PM -0600, Segher Boessenkool wrote:
> On Thu, Nov 14, 2019 at 05:42:43PM -0500, Michael Meissner wrote:
> > -;; Split a load of a large constant into the appropriate two-insn
> > -;; sequence.
> > +;; Split a load of a large constant into the appropriate two-insn 
> > sequence.  On
> > +;; systems that support PADDI (PLI), we can use PLI to load any 32-bit 
> > constant
> > +;; in one instruction.
> >  
> >  (define_split
> >[(set (match_operand:SI 0 "gpc_reg_operand")
> > (match_operand:SI 1 "const_int_operand"))]
> >"(unsigned HOST_WIDE_INT) (INTVAL (operands[1]) + 0x8000) >= 0x1
> > -   && (INTVAL (operands[1]) & 0x) != 0"
> > +   && (INTVAL (operands[1]) & 0x) != 0 && !TARGET_PREFIXED_ADDR"
> >[(set (match_dup 0)
> > (match_dup 2))
> > (set (match_dup 0)
> 
> Please use num_insns_constant, instead (and fix num_insns_constant_gpr
> so it knows about SIGNED_34BIT).

The previous patch V6 #1 already had the modification for
num_insns_constant_gpr.

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

Re: Add a new combine pass

[Segher Boessenkool]

Hi!

On Mon, Nov 25, 2019 at 09:16:52PM +, Richard Sandiford wrote:
> Segher Boessenkool  writes:
> > I am wondering the other way around :-)  Is what you do for combine2
> > something that would be more generally applicable/useful?  That's what
> > I'm trying to find out :-)
> >
> > What combine does could use some improvement, if you want to hear a
> > more direct motivations.  LOG_LINKS just skip references we cannot
> > handle (and some more), so we always have to do modified_between etc.,
> > which hurts.
> 
> The trade-offs behind the choice of representation are very specific
> to the pass.

Yes, but hopefully not so specific that every pass needs a completely
different representation ;-)

> >> >> Target Tests   DeltaBest   Worst  Median
> >> >> avr-elf 1341 -111401  -13824 680 -10
> >> >
> >> > Things like this are kind of suspicious :-)
> >> 
> >> Yeah.  This mostly seems to come from mopping up the extra moves created
> >> by make_more_copies.  So we have combinations like:
> >> 
> >>58: r70:SF=r94:SF
> >>   REG_DEAD r94:SF
> >>60: r22:SF=r70:SF
> >>   REG_DEAD r70:SF
> >
> > Why didn't combine do this?  A target problem?
> 
> Seems to be because combine rejects hard-reg destinations whose classes
> are likely spilled (cant_combine_insn_p).

Ah, okay.  And that is required to prevent ICEs, in combine2 as well
then -- ICEs in RA.

There should be a better way to do this.

> This SF argument register
> happens to overlap POINTER_X_REGS and POINTER_Y_REGS and so we reject
> the combination based on POINTER_X_REGS being likely spilled.

static bool
avr_class_likely_spilled_p (reg_class_t c)
{
  return (c != ALL_REGS &&
   (AVR_TINY ? 1 : c != ADDW_REGS));
}

So this target severely shackles combine.  Does it have to?  If so, why
not with combine2?

> >> So there's only one case in which it isn't a win, but the number of
> >> tests is tiny.  So I agree there's no justification for trying this in
> >> combine proper as things stand (and I wasn't arguing otherwise FWIW).
> >> I'd still like to keep it in the new pass because it does help
> >> *sometimes* and there's no sign yet that it has a noticeable
> >> compile-time cost.
> >
> > So when does it help?  I can only think of cases where there are
> > problems elsewhere.
> 
> The full list of affected tests (all at -O2 -ftree-vectorize) are:

I'll have to look at this closer later, sorry.


Segher

Re: [PATCH] V7, #1 of 7, Use PLI to load up 34-bit DImode constants

[Michael Meissner]

On Fri, Nov 22, 2019 at 06:06:19PM -0600, Segher Boessenkool wrote:
> On Thu, Nov 14, 2019 at 05:40:10PM -0500, Michael Meissner wrote:
> > --- gcc/config/rs6000/rs6000.c  (revision 278173)
> > +++ gcc/config/rs6000/rs6000.c  (working copy)
> > @@ -5552,7 +5552,7 @@ static int
> >  num_insns_constant_gpr (HOST_WIDE_INT value)
> >  {
> >/* signed constant loadable with addi */
> > -  if (((unsigned HOST_WIDE_INT) value + 0x8000) < 0x1)
> > +  if (SIGNED_16BIT_OFFSET_P (value))
> >  return 1;
> 
> Hrm, so the SIGNED_nBIT_OFFSET_P should not be called "offset", if we use
> them for other numbers as well.
> 
> > -;;  GPR store  GPR load   GPR move   GPR li GPR lis 
> > GPR #
> > -;;  FPR store  FPR load   FPR move   AVX store  AVX store   
> > AVX load
> > -;;  AVX load   VSX move   P9 0   P9 -1  AVX 0/-1
> > VSX 0
> > -;;  VSX -1 P9 const   AVX const  From SPR   To SPR  
> > SPR<->SPR
> > -;;  VSX->GPR   GPR->VSX
> > +;;  GPR store  GPR load   GPR move   GPR li GPR lis 
> > GPR pli
> > +;;  GPR #  FPR store  FPR load   FPR move   AVX store   
> > AVX store
> > +;;  AVX load   AVX load   VSX move   P9 0   P9 -1   
> > AVX 0/-1
> > +;;  VSX 0  VSX -1 P9 const   AVX const  From SPRTo 
> > SPR
> > +;;  SPR<->SPR  VSX->GPR   GPR->VSX
> 
> I cannot make heads or tails of it this way.  Please just add the "pli",
> don't rearrange everything else.

You have to put PLI after LI and LIS and before the splitter insn.

> There do not have to be exactly six per line.  The only reason to have
> some order here is to make it easier to read, not to make it *harder*!

But in doing the transformation, I will modify all of the constraint and
attribute lines.  Otherwise it makes it impossible to add new things, and it
makes it impossible to find the appropriate insn.

> So for this first line let's have three GPR moves, and then have four
> load immediates.  Then in the future if we need to edit it again, make
> the edited part make some sense, etc.


So right now we have:

;;  GPR store  GPR load   GPR move   GPR li GPR lis GPR #
;;  FPR store  FPR load   FPR move   AVX store  AVX store   AVX load
;;  AVX load   VSX move   P9 0   P9 -1  AVX 0/-1VSX 0
;;  VSX -1 P9 const   AVX const  From SPR   To SPR  
SPR<->SPR
;;  VSX->GPR   GPR->VSX
(define_insn "*movdi_internal64"
  [(set (match_operand:DI 0 "nonimmediate_operand"
   "=YZ,   r, r, r, r,  r,
m, ^d,^d,wY,Z,  $v,
$v,^wa,   wa,wa,v,  wa,
wa,v, v, r, *h, *h,
?r,?wa")
(match_operand:DI 1 "input_operand"
   "r, YZ,r, I, L,  nF,
^d,m, ^d,^v,$v, wY,
Z, ^wa,   Oj,wM,OjwM,   Oj,
wM,wS,wB,*h,r,  0,
wa,r"))]
  "TARGET_POWERPC64
   && (gpc_reg_operand (operands[0], DImode)
   || gpc_reg_operand (operands[1], DImode))"
  "@
   std%U0%X0 %1,%0
   ld%U1%X1 %0,%1
   mr %0,%1
   li %0,%1
   lis %0,%v1
   #
   stfd%U0%X0 %1,%0
   lfd%U1%X1 %0,%1
   fmr %0,%1
   stxsd %1,%0
   stxsdx %x1,%y0
   lxsd %0,%1
   lxsdx %x0,%y1
   xxlor %x0,%x1,%x1
   xxspltib %x0,0
   xxspltib %x0,255
   #
   xxlxor %x0,%x0,%x0
   xxlorc %x0,%x0,%x0
   #
   #
   mf%1 %0
   mt%0 %1
   nop
   mfvsrd %0,%x1
   mtvsrd %x0,%1"
  [(set_attr "type"
   "store,  load,   *, *, *, *,
fpstore,fpload, fpsimple,  fpstore,   fpstore,   fpload,
fpload, veclogical, vecsimple, vecsimple, vecsimple, 
veclogical,
veclogical, vecsimple,  vecsimple, mfjmpr,mtjmpr,*,
mftgpr,mffgpr")
   (set_attr "size" "64")
   (set_attr "length"
   "*, *, *, *, *,  20,
*, *, *, *, *,  *,
*, *, *, *, *,  *,
*, 8, *, *, *,  *,
*, *")
   (set_attr "isa"
   "*, *, *, *, *,  *,
*, *, *, p9v,   p7v,p9v,
p7v,   *, p9v,   p9v,   p7v,*,
*, p7v,   p7v,   *, *,  *,
p8v,   p8v")])

If I just change the columns, in order to be 

[Bug fortran/92629] internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:173

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
Should have taken this one...

Fixed on trunk.  Waiting a couple days before backports.

Re: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?

[Ramana Radhakrishnan]

On Mon, Nov 25, 2019 at 9:43 PM Andrew Dean  wrote:
>
> > > >>> I get errors like this:
> > > >>>
> > > >>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file
> > > >>> 'rdimon.specs': No such file or directory
> > > >>>
> > > >>> I can see that the rdimon.specs flag is added based on this line
> > > >>> in aarch64-
> > > >> sim.exp:
> > > >>
> > > >> Where does aarch64-sim.exp comes from?
> > > >
> > > > /usr/share/dejagnu/baseboards/aarch64-sim.exp
> > > >
> > > >>
> > > >>>
> > > >>> set_board_info ldflags  "[libgloss_link_flags] [newlib_link_flags]
> > > >>> -
> > > >> specs=rdimon.specs"
> > > >>>
> > > >> I think this is for baremetal/newlib targets, ie. aarch64-elf, not
> > > >> for aarch64- linux-gnu.
> > > >
> >
> > Yes -specs=rdimon.specs and other such flags are for use only on bare-metal
> > targets.
> >
> > > > Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or 
> > > > aarch64-linux-
> > elf...
> > > > I get a KeyError in build_compilers and build_glibcs when it tries to 
> > > > look up
> > the config with either of those values.
> > > >
> > >
> > > Unfortunately the build-many-glibcs.py does not have support for
> > > baremetal build yet (since it is a tool created to build
> > > cross-compiling toolchain using glibc).
> >
> > And glibc doesn't work bare-metal ..
> >
> > regards
> > Ramana
> I guess that means that the dejagnu baseboard "aarch64-sim" is only meant to 
> do bare-metal testing? How would one build/test GCC hosted on x86_64 and 
> targeting aarch64 then? Is there a different simulator approach I should be 
> using?

For cross-compilers with Linux, you've got 2 options - write up a
board file to use qemu in user-emulation mode or indeed system
emulation mode or use real hardware and construct something using ssh
/ scp.

R

[Bug c/92667] New: spurious missing sentinel in function call with a local sentinel variable

[msebor at gcc dot gnu.org]

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

Bug ID: 92667
   Summary: spurious missing sentinel in function call with a
local sentinel variable
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While looking into bug 92666 I noticed the following false positive in C (it
can be reproduced in C++ making the pointer non-const so it doesn't get
folded).  By being implemented fully in the front-end the warning doesn't see
that the nullptr variable is, in fact, a null pointer.

$ cat t.c && cat t.c && gcc -S -Wall t.c
void f (void)
{
  const char* const null = 0;

  __builtin_execl ("foo", "bar", null);
}
void f (void)
{
  const char* const null = 0;

  __builtin_execl ("foo", "bar", null);
}
t.c: In function ‘f’:
t.c:5:3: warning: missing sentinel in function call [-Wformat=]
5 |   __builtin_execl ("foo", "bar", null);
  |   ^~~

RE: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?

[Andrew Dean via gcc]

> > >>> I get errors like this:
> > >>>
> > >>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file
> > >>> 'rdimon.specs': No such file or directory
> > >>>
> > >>> I can see that the rdimon.specs flag is added based on this line
> > >>> in aarch64-
> > >> sim.exp:
> > >>
> > >> Where does aarch64-sim.exp comes from?
> > >
> > > /usr/share/dejagnu/baseboards/aarch64-sim.exp
> > >
> > >>
> > >>>
> > >>> set_board_info ldflags  "[libgloss_link_flags] [newlib_link_flags]
> > >>> -
> > >> specs=rdimon.specs"
> > >>>
> > >> I think this is for baremetal/newlib targets, ie. aarch64-elf, not
> > >> for aarch64- linux-gnu.
> > >
> 
> Yes -specs=rdimon.specs and other such flags are for use only on bare-metal
> targets.
> 
> > > Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or 
> > > aarch64-linux-
> elf...
> > > I get a KeyError in build_compilers and build_glibcs when it tries to 
> > > look up
> the config with either of those values.
> > >
> >
> > Unfortunately the build-many-glibcs.py does not have support for
> > baremetal build yet (since it is a tool created to build
> > cross-compiling toolchain using glibc).
> 
> And glibc doesn't work bare-metal ..
> 
> regards
> Ramana
I guess that means that the dejagnu baseboard "aarch64-sim" is only meant to do 
bare-metal testing? How would one build/test GCC hosted on x86_64 and targeting 
aarch64 then? Is there a different simulator approach I should be using?

Re: Add a new combine pass

[Richard Sandiford]

Segher Boessenkool  writes:
> Hi!
>
> On Mon, Nov 18, 2019 at 05:55:13PM +, Richard Sandiford wrote:
>> Richard Sandiford  writes:
>> > (It's 23:35 local time, so it's still just about stage 1. :-))
>> 
>> Or actually, just under 1 day after end of stage 1.  Oops.
>> Could have sworn stage 1 ended on the 17th :-(  Only realised
>> I'd got it wrong when catching up on Saturday's email traffic.
>> 
>> And inevitably, I introduced a couple of stupid mistakes while
>> trying to clean the patch up for submission by that (non-)deadline.
>> Here's a version that fixes an inverted overlapping memref check
>> and that correctly prunes the use list for combined instructions.
>> (This last one is just a compile-time saving -- the old code was
>> correct, just suboptimal.)
>
> I've build the Linux kernel with the previous version, as well as this
> one.  R0 is unmodified GCC, R1 is the first patch, R2 is this one:
>
> (I've forced --param=run-combine=6 for R1 and R2):
> (Percentages are relative to R0):
>
> R0R1R2R1R2
>alpha   6107088   6101088   6101088   99.902%   99.902%
>  arc   4008224   4006568   4006568   99.959%   99.959%
>  arm   9206728   9200936   9201000   99.937%   99.938%
>arm64  13056174  13018174  13018194   99.709%   99.709%
>armhf 0 0 0 0 0
>  c6x   2337237   2337077   2337077   99.993%   99.993%
> csky   3356602 0 0 0 0
>h8300   1166996   1166776   1166776   99.981%   99.981%
> i386  11352159 0 0 0 0
> ia64  18230640  18167000  18167000   99.651%   99.651%
> m68k   3714271 0 0 0 0
>   microblaze   4982749   4979945   4979945   99.944%   99.944%
> mips   8499309   8495205   8495205   99.952%   99.952%
>   mips64   7042036   7039816   7039816   99.968%   99.968%
>nds32   4486663 0 0 0 0
>nios2   3680001   3679417   3679417   99.984%   99.984%
> openrisc   4226076   4225868   4225868   99.995%   99.995%
>   parisc   7681895   7680063   7680063   99.976%   99.976%
> parisc64   8677077   8676581   8676581   99.994%   99.994%
>  powerpc  10687611  10682199  10682199   99.949%   99.949%
>powerpc64  17671082  17658570  17658570   99.929%   99.929%
>  powerpc64le  17671082  17658570  17658570   99.929%   99.929%
>  riscv32   1554938   1554758   1554758   99.988%   99.988%
>  riscv64   6634342   6632788   6632788   99.977%   99.977%
> s390  13049643  13014939  13014939   99.734%   99.734%
>   sh   3254743 0 0 0 0
>  shnommu   1632364   1632124   1632124   99.985%   99.985%
>sparc   4404993   4399593   4399593   99.877%   99.877%
>  sparc64   6796711   6797491   6797491  100.011%  100.011%
>   x86_64  19713174  19712817  19712817   99.998%   99.998%
>   xtensa 0 0 0 0 0

Thanks for running these.

> There are fivew new failures, with either of the combine2 patches.  And
> all five are actually different (different symptoms, at least):
>
> - csky fails on libgcc build:
>
> /home/segher/src/gcc/libgcc/fp-bit.c: In function '__fixdfsi':
> /home/segher/src/gcc/libgcc/fp-bit.c:1405:1: error: unable to generate 
> reloads for:
>  1405 | }
>   | ^
> (insn 199 86 87 8 (parallel [
> (set (reg:SI 101)
> (plus:SI (reg:SI 98)
> (const_int -32 [0xffe0])))
> (set (reg:CC 33 c)
> (lt:CC (plus:SI (reg:SI 98)
> (const_int -32 [0xffe0]))
> (const_int 0 [0])))
> ]) "/home/segher/src/gcc/libgcc/fp-bit.c":1403:23 207 {*cskyv2_declt}
>  (nil))
> during RTL pass: reload
>
> Target problem?

Yeah, looks like it.  The pattern is:

(define_insn "*cskyv2_declt"
  [(set (match_operand:SI 0 "register_operand" "=r")
(plus:SI (match_operand:SI 1 "register_operand" "r")
 (match_operand:SI 2 "const_int_operand" "Uh")))
   (set (reg:CC CSKY_CC_REGNUM)
(lt:CC (plus:SI (match_dup 1) (match_dup 2))
   (const_int 0)))]
  "CSKY_ISA_FEATURE (2E3)"
  "declt\t%0, %1, %M2"
)

So the predicate accepts all const_ints but the constraint doesn't.

> - i386 goes into an infinite loop compiling, or at least an hour or so...
> Erm I forgot too record what it was compiling.  I did attach a GDB...  It
> is something from lra_create_live_ranges.

Hmm.

> - m68k:
>
> /home/segher/src/kernel/fs/exec.c: In function 'copy_strings':
> /home/segher/src/kernel/fs/exec.c:590:1: internal compiler error: in 
> final_scan_insn_1, at final.c:3048
>   590 | }
>   | ^
> 0x10408307 final_scan_insn_1
> /home/segher/src/gcc/gcc/final.c:3048
> 0x10408383 final_scan_insn(rtx_insn*, _IO_FILE*, int, 

[Bug c++/92666] [10 Regression] bogus -Wunused-but-set-variable in gcov.c with -Wno-restrict

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
The check_function_restrict() function is called to do the -Wrestrict checking.
 It's called conditionally, from check_function_arguments(), when warn_restrict
is nonzero.  When called, the function calls fold_for_warn() for all arguments
of the functions it checks for aliasing violations.  fold_for_warn() ends up
calling mark_rvalue_use() which ultimately calls mark_exp_read() which sets
DECL_READ_P (exp) = 1 for VAR_DECL and PARM_DECL.  None of this happens when
-Wno-restrict is set.

Re: [PATCH] Add safe iterator iterator_concept

[Jonathan Wakely]

On 25/11/19 22:25 +0100, François Dumont wrote:

I plan to commit this patch tomorrow.

    * include/debug/safe_iterator.h
[__cpp_lib_concepts](_Safe_iterator<>::iterator_concept): Define for
    C++20.


Thanks.


François




diff --git a/libstdc++-v3/include/debug/safe_iterator.h 
b/libstdc++-v3/include/debug/safe_iterator.h
index 685256551d9..abf575186c7 100644
--- a/libstdc++-v3/include/debug/safe_iterator.h
+++ b/libstdc++-v3/include/debug/safe_iterator.h
@@ -141,6 +141,10 @@ namespace __gnu_debug
  typedef typename _Traits::reference   reference;
  typedef typename _Traits::pointer pointer;

+#if __cplusplus > 201703L && __cpp_lib_concepts
+  using iterator_concept = std::__detail::__iter_concept<_Iterator>;
+#endif
+
  /// @post the iterator is singular and unattached
  _Safe_iterator() _GLIBCXX_NOEXCEPT : _Iter_base() { }

[PATCH] C++20 P1032 for __debug::array

[François Dumont]

I plan to commit this tomorrow.

But I really wonder if we couldn't just add some __glibcxx_checks_xxx in 
std/array ?


    * include/debug/array (array<>::fill): Add C++20 constexpr.
    (array<>::swap): Likewise.

François

diff --git a/libstdc++-v3/include/debug/array b/libstdc++-v3/include/debug/array
index 5566a087f9a..4e0fac8daac 100644
--- a/libstdc++-v3/include/debug/array
+++ b/libstdc++-v3/include/debug/array
@@ -80,11 +80,11 @@ namespace __debug
   // No explicit construct/copy/destroy for aggregate type.
 
   // DR 776.
-  void
+  _GLIBCXX20_CONSTEXPR void
   fill(const value_type& __u)
   { std::fill_n(begin(), size(), __u); }
 
-  void
+  _GLIBCXX20_CONSTEXPR void
   swap(array& __other)
   noexcept(_AT_Type::_Is_nothrow_swappable::value)
   { std::swap_ranges(begin(), end(), __other.begin()); }
@@ -282,6 +282,7 @@ namespace __debug
 #endif
 
   template
+_GLIBCXX20_CONSTEXPR
 inline void
 swap(array<_Tp, _Nm>& __one, array<_Tp, _Nm>& __two)
 noexcept(noexcept(__one.swap(__two)))

[PATCH] Add safe iterator iterator_concept

[François Dumont]

I plan to commit this patch tomorrow.

    * include/debug/safe_iterator.h
[__cpp_lib_concepts](_Safe_iterator<>::iterator_concept): Define for
    C++20.

François

diff --git a/libstdc++-v3/include/debug/safe_iterator.h b/libstdc++-v3/include/debug/safe_iterator.h
index 685256551d9..abf575186c7 100644
--- a/libstdc++-v3/include/debug/safe_iterator.h
+++ b/libstdc++-v3/include/debug/safe_iterator.h
@@ -141,6 +141,10 @@ namespace __gnu_debug
   typedef typename _Traits::reference		reference;
   typedef typename _Traits::pointer			pointer;
 
+#if __cplusplus > 201703L && __cpp_lib_concepts
+  using iterator_concept = std::__detail::__iter_concept<_Iterator>;
+#endif
+
   /// @post the iterator is singular and unattached
   _Safe_iterator() _GLIBCXX_NOEXCEPT : _Iter_base() { }
 

[Bug c/92663] Add __gcc_has_bug or __gcc_bug_fixed

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
True, but I still think the list needs to be compiled in to the binaries
statically. If that gave incorrect results in some cases (because a bug was
thought to be fixed when the static list was generated, but was later reopened)
then so be it. That's better than querying bugzilla during compilation, which
is totally unacceptable.

[Bug debug/92442] Compiling Boost.Spirit.X3 code uses exuberant amount of RAM with -gpubnames

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
(In reply to Richard Biener from comment #5)
> There are also quite many _name_ duplicates refering to different DIEs!  Like
> 178 copies of 'std::is_same_v' and others:

std::*_v are variable templates, so the different DIEs are for different
instantiations of the template.  I don't remember what the right pubnames
behavior is for variable templates.

Re: Add a new combine pass

[Richard Sandiford]

Segher Boessenkool  writes:
> On Thu, Nov 21, 2019 at 08:32:14PM +, Richard Sandiford wrote:
>> Segher Boessenkool  writes:
>> > It's not great if every pass invents its own version of some common
>> > infrastructure thing because that common one is not suitable.
>> >
>> > I.e., can this be fixed somehow?  Maybe just by having a restricted DU
>> > chains df problem?
>> 
>> Well, it'd probably make sense to make fwprop.c's approach available
>> as a "proper" df interface at some point.  Hopefully if anyone wants the
>> same thing as fwprop.c, they'd do that rather than copy the code. :-)
>
>> >> * Updating a full, ordered def-use chain after a move is a linear-time
>> >>   operation, so whatever happens, we'd need to apply some kind of limit
>> >>   on the number of uses we maintain, with something like that integer
>> >>   point range for the rest.
>
> Yeah.
>
>> >> * Once we've analysed the insn and built its def-use chains, we don't
>> >>   look at the df_refs again until we update the chains after a successful
>> >>   combination.  So it should be more efficient to maintain a small array
>> >>   of insn_info_rec pointers alongside the numerical range, rather than
>> >>   walk and pollute chains of df_refs and then link back the insn uids
>> >>   to the pass-local info.
>> >
>> > So you need something like combine's LOG_LINKS?  Not that handling those
>> > is not quadratic in the worst case, but in practice it works well.  And
>> > it *could* be made linear.
>> 
>> Not sure why what I've used isn't what I need though :-)
>
> I am wondering the other way around :-)  Is what you do for combine2
> something that would be more generally applicable/useful?  That's what
> I'm trying to find out :-)
>
> What combine does could use some improvement, if you want to hear a
> more direct motivations.  LOG_LINKS just skip references we cannot
> handle (and some more), so we always have to do modified_between etc.,
> which hurts.

The trade-offs behind the choice of representation are very specific
to the pass.  You'd only pick this if you wanted both to propagate
definitions into uses and to move insns around.  You'd also only pick
it if you were happy with tracking a small number of named uses per
definition.  I can't think of any other passes that would prefer this
over what they already use.  (Combine itself is an exception, since
the new pass started out as a deliberate attempt to start from scratch.)

>> >> Target Tests   DeltaBest   Worst  Median
>> >> avr-elf 1341 -111401  -13824 680 -10
>> >
>> > Things like this are kind of suspicious :-)
>> 
>> Yeah.  This mostly seems to come from mopping up the extra moves created
>> by make_more_copies.  So we have combinations like:
>> 
>>58: r70:SF=r94:SF
>>   REG_DEAD r94:SF
>>60: r22:SF=r70:SF
>>   REG_DEAD r70:SF
>
> Why didn't combine do this?  A target problem?

Seems to be because combine rejects hard-reg destinations whose classes
are likely spilled (cant_combine_insn_p).  This SF argument register
happens to overlap POINTER_X_REGS and POINTER_Y_REGS and so we reject
the combination based on POINTER_X_REGS being likely spilled.

I think the same thing could happen on other targets, e.g. for
TAILCALL_ADDR_REGS on aarch64.

>> So there's only one case in which it isn't a win, but the number of
>> tests is tiny.  So I agree there's no justification for trying this in
>> combine proper as things stand (and I wasn't arguing otherwise FWIW).
>> I'd still like to keep it in the new pass because it does help
>> *sometimes* and there's no sign yet that it has a noticeable
>> compile-time cost.
>
> So when does it help?  I can only think of cases where there are
> problems elsewhere.

The full list of affected tests (all at -O2 -ftree-vectorize) are:

arc-elf gcc.c-torture/compile/pr67506.c
avr-elf gcc.dg/torture/pr77916.c
bpf-elf gcc.dg/torture/vshuf-v8hi.c
bpf-elf gcc.dg/torture/vshuf-v4si.c
bfin-elfgcc.dg/torture/vshuf-v8qi.c
c6x-elf gcc.c-torture/execute/991118-1.c
cr16-elfgcc.c-torture/compile/pr82052.c
epiphany-elfgcc.c-torture/execute/991118-1.c
epiphany-elfgcc.dg/pr77664.c
epiphany-elfgcc.dg/vect/vect-mult-pattern-2.c
epiphany-elfgcc.dg/torture/vshuf-v8hi.c
epiphany-elfgcc.dg/tree-ssa/pr77664.c
epiphany-elfgcc.dg/tree-ssa/negneg-3.c
fr30-elfgcc.dg/torture/vshuf-v4hi.c
fr30-elfgcc.dg/torture/vshuf-v8hi.c
frv-linux-gnu   gcc.dg/torture/vshuf-v4hi.c
frv-linux-gnu   gcc.dg/torture/vshuf-v8hi.c
h8300-elf   gcc.c-torture/execute/2422-1.c
h8300-elf   gcc.dg/torture/pr77916.c
ia64-linux-gnu  gcc.c-torture/execute/ieee/pr30704.c
ia64-linux-gnu  gcc.dg/vect/pr49478.c
ia64-linux-gnu  gcc.dg/tree-ssa/ldist-16.c
i686-apple-darwin 

Re: [PATCH, libstdc++] More

[Jonathan Wakely]

On 15/11/19 22:17 -0500, Ed Smith-Rowland via libstdc++ wrote:

Index: include/bits/stl_algobase.h
===
--- include/bits/stl_algobase.h (revision 278318)
+++ include/bits/stl_algobase.h (working copy)
@@ -107,6 +107,50 @@
}

  /*
+   * A constexpr wrapper for __builtin_memmove.


This should say __builtin_memcpy.


+   * @param __num The number of elements of type _Tp (not bytes).
+   */
+  template
+_GLIBCXX14_CONSTEXPR
+inline void*
+__memcpy(_Tp* __dst, const _Tp* __src, size_t __num)
+{
+#ifdef __cpp_lib_is_constant_evaluated
+  if (std::is_constant_evaluated())
+   {
+ for(; __num > 0; --__num)
+   *__dst++ = *__src++;
+ return __dst;
+   }
+  else
+#endif
+   return __builtin_memcpy(__dst, __src, sizeof(_Tp) * __num);
+  return __dst;
+}
+
+  /*
+   * A constexpr wrapper for __builtin_memmove.


And this should say __builtin_memset.


+   * @param __num The number of elements of type _Tp (not bytes).
+   */
+  template
+_GLIBCXX14_CONSTEXPR
+inline void*
+__memset(_Tp* __dst, _Tp __a, size_t __num)
+{
+#ifdef __cpp_lib_is_constant_evaluated
+  if (std::is_constant_evaluated())
+   {
+ for(; __num > 0; --__num)
+   *__dst = __a;
+ return __dst;
+   }
+  else
+#endif
+   return __builtin_memset(__dst, __a, sizeof(_Tp) * __num);
+  return __dst;
+}


OK for trunk with those two comment fixes. Thanks.

[Bug rtl-optimization/92656] The zero_extend insn can't be eliminated in the combine pass

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Hmm, this comes from coremarks (what a bad benchmark).

[Bug rtl-optimization/92656] The zero_extend insn can't be eliminated in the combine pass

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug c++/92666] [10 Regression] bogus -Wunused-but-set-variable in gcov.c with -Wno-restrict

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|bogus   |[10 Regression] bogus
   |-Wunused-but-set-variable   |-Wunused-but-set-variable
   |in gcov.c with  |in gcov.c with
   |-Wno-restrict   |-Wno-restrict

--- Comment #1 from Martin Sebor  ---
I thought the problem was introduced with -Wrestrict but it looks like the
false positive is actually a regression caused by r276059:

r276059 | jason | 2019-09-23 13:48:00 -0400 (Mon, 23 Sep 2019) | 10 lines

PR c++/91809 - bit-field and ellipsis.

decay_conversion converts a bit-field access to its declared type, which
isn't what we want here; it even has a comment that the caller is expected
to have already used default_conversion to perform integral promotion.  This
function handles arithmetic promotion differently, but we still don't want
to call decay_conversion before that happens.

* call.c (convert_arg_to_ellipsis): Don't call decay_conversion for
arithmetic arguments.

Questions about where to find information on IPO state in GCC

[Nicholas Krause]

Greetings Richard,
After looking through the current work on multi-threading seems that we 
can scale
better with a workqueue strategy sharing and launching depending on how 
state is

shared between the GCC passes.

I'm not very familiar with all the details of how state is share in the 
GIMPLE,RTL or

SSA passes so I was wondering where to find information on this. The manual
only seems to mention the pass manager and its interactions with passes 
for running

them.

Thanks,
Nick

[Bug c++/92666] bogus -Wunused-but-set-variable in gcov.c with -Wno-restrict

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-25
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug c++/92666] New: bogus -Wunused-but-set-variable in gcov.c with -Wno-restrict

[msebor at gcc dot gnu.org]

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

Bug ID: 92666
   Summary: bogus -Wunused-but-set-variable in gcov.c with
-Wno-restrict
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Bootstrap with -Wno-restrict fails due to -Werror=unused-but-set-variable in
gcc/gcov.c:

/src/gcc/svn/gcc/gcov.c: In function ‘const char* format_count(gcov_type)’:
/src//gcc/svn/gcc/gcov.c:2328:9: warning: variable ‘r’ set but not used
[-Wunused-but-set-variable]
 2328 |   float r = 1.0f * count / divisor;
  | ^

A small test case reduced from the file is as follows.  This is not
reproducible with the C front-end:

$ cat t.c && gcc -O2 -S -Wall -Wextra -Wno-restrict -xc++ t.c
extern "C" int printf (const char*, ...);

void f (unsigned n)
{
  int i = 0;
  while (n >>= 1)
++i;
  float r = 1.0f * i;
  printf ("%f", r);
}
t.c: In function ‘void f(unsigned int)’:
t.c:8:9: warning: variable ‘r’ set but not used [-Wunused-but-set-variable]
8 |   float r = 1.0f * i;
  | ^

[Bug c/92663] Add __gcc_has_bug or __gcc_bug_fixed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Bugs are sometimes reopened etc., so the list isn't completely static.

Re: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?

[Ramana Radhakrishnan]

On Mon, Nov 25, 2019 at 8:40 PM Adhemerval Zanella
 wrote:
>
>
>
> On 25/11/2019 17:28, Andrew Dean via gcc wrote:
> >>> This completes successfully. However, when I then try to run the gcc 
> >>> tests like
> >> so:
> >>> runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite
> >>> aarch64.exp --target aarch64-linux-gnu --target_board aarch64-sim
> >>> --tool_exec
> >>> /path_to/build_dir/install/compilers/aarch64-linux-gnu/bin/aarch64-gli
> >>> bc-linux-gnu-gcc --verbose -v
> >>>
> >>> I get errors like this:
> >>>
> >>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file
> >>> 'rdimon.specs': No such file or directory
> >>>
> >>> I can see that the rdimon.specs flag is added based on this line in 
> >>> aarch64-
> >> sim.exp:
> >>
> >> Where does aarch64-sim.exp comes from?
> >
> > /usr/share/dejagnu/baseboards/aarch64-sim.exp
> >
> >>
> >>>
> >>> set_board_info ldflags  "[libgloss_link_flags] [newlib_link_flags] -
> >> specs=rdimon.specs"
> >>>
> >> I think this is for baremetal/newlib targets, ie. aarch64-elf, not for 
> >> aarch64-
> >> linux-gnu.
> >

Yes -specs=rdimon.specs and other such flags are for use only on
bare-metal targets.

> > Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or 
> > aarch64-linux-elf...
> > I get a KeyError in build_compilers and build_glibcs when it tries to look 
> > up the config with either of those values.
> >
>
> Unfortunately the build-many-glibcs.py does not have support for baremetal
> build yet (since it is a tool created to build cross-compiling toolchain
> using glibc).

And glibc doesn't work bare-metal ..

regards
Ramana

[Bug c/92663] Add __gcc_has_bug or __gcc_bug_fixed

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Eric Gallager from comment #2)
> This sounds like it could be dangerous from a security context... currently
> no network connection is needed to use gcc, it would be a major
> disappointment if that changed...

I think the suggestion is that the numbers are baked into the executable, not
that Bugzilla is queried. The list of fixed bugs for a given revision of the
source code is a static property, it doesn't need to be queried dynamically.

Re: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?

[Adhemerval Zanella]

On 25/11/2019 17:28, Andrew Dean via gcc wrote:
>>> This completes successfully. However, when I then try to run the gcc tests 
>>> like
>> so:
>>> runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite
>>> aarch64.exp --target aarch64-linux-gnu --target_board aarch64-sim
>>> --tool_exec
>>> /path_to/build_dir/install/compilers/aarch64-linux-gnu/bin/aarch64-gli
>>> bc-linux-gnu-gcc --verbose -v
>>>
>>> I get errors like this:
>>>
>>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file
>>> 'rdimon.specs': No such file or directory
>>>
>>> I can see that the rdimon.specs flag is added based on this line in aarch64-
>> sim.exp:
>>
>> Where does aarch64-sim.exp comes from?
> 
> /usr/share/dejagnu/baseboards/aarch64-sim.exp
> 
>>
>>>
>>> set_board_info ldflags  "[libgloss_link_flags] [newlib_link_flags] -
>> specs=rdimon.specs"
>>>
>> I think this is for baremetal/newlib targets, ie. aarch64-elf, not for 
>> aarch64-
>> linux-gnu.
> 
> Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or 
> aarch64-linux-elf...
> I get a KeyError in build_compilers and build_glibcs when it tries to look up 
> the config with either of those values.
> 

Unfortunately the build-many-glibcs.py does not have support for baremetal
build yet (since it is a tool created to build cross-compiling toolchain
using glibc).

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

[Paolo Carlini]

Hi,

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


Thanks, Paolo.

///

/cp
2019-11-15  Paolo Carlini  

* typeck.c (cp_build_unary_op): Consistently use the accurate
location in seven additional diagnostic messages.
(cp_build_compound_expr): Use cp_expr_loc_or_input_loc in one place.

/testsuite
2019-11-15  Paolo Carlini  

* g++.dg/cpp1z/bool-increment1.C: Test location(s) too.
* g++.dg/expr/bitfield3.C: Likewise.
* g++.dg/expr/bitfield4.C: Likewise.
* g++.dg/expr/bitfield5.C: Likewise.
* g++.dg/expr/bitfield6.C: Likewise.
* g++.dg/expr/bool1.C: Likewise.
* g++.dg/expr/bool2.C: Likewise.
* g++.dg/expr/bool3.C: Likewise.
* g++.dg/expr/bool4.C: Likewise.
* g++.dg/expr/lval3.C: Likewise.
* g++.dg/other/error18.C: Likewise.
* g++.dg/warn/Wpointer-arith-1.C: Likewise.
* g++.old-deja/g++.bugs/900212_01.C: Likewise.
* g++.old-deja/g++.bugs/900428_02.C: Likewise.
* g++.old-deja/g++.jason/rfg14.C: Likewise.
* g++.old-deja/g++.other/overload11.C: Likewise.
Index: cp/typeck.c
===
--- cp/typeck.c (revision 278692)
+++ cp/typeck.c (working copy)
@@ -6520,7 +6520,8 @@ cp_build_unary_op (enum tree_code code, tree xarg,
if (TREE_CODE (argtype) == ENUMERAL_TYPE)
   {
 if (complain & tf_error)
-  permerror (input_location, (code == PREINCREMENT_EXPR || code == 
POSTINCREMENT_EXPR)
+  permerror (location, (code == PREINCREMENT_EXPR
+   || code == POSTINCREMENT_EXPR)
  ? G_("ISO C++ forbids incrementing an enum")
  : G_("ISO C++ forbids decrementing an enum"));
 else
@@ -6536,11 +6537,13 @@ cp_build_unary_op (enum tree_code code, tree xarg,
if (!COMPLETE_OR_VOID_TYPE_P (type))
   {
 if (complain & tf_error)
-  error (((code == PREINCREMENT_EXPR
-   || code == POSTINCREMENT_EXPR))
- ? G_("cannot increment a pointer to incomplete type 
%qT")
- : G_("cannot decrement a pointer to incomplete type 
%qT"),
- TREE_TYPE (argtype));
+  error_at (location, ((code == PREINCREMENT_EXPR
+   || code == POSTINCREMENT_EXPR))
+   ? G_("cannot increment a pointer to incomplete "
+"type %qT")
+   : G_("cannot decrement a pointer to incomplete "
+"type %qT"),
+   TREE_TYPE (argtype));
 else
   return error_mark_node;
   }
@@ -6547,11 +6550,13 @@ cp_build_unary_op (enum tree_code code, tree xarg,
else if (!TYPE_PTROB_P (argtype)) 
   {
 if (complain & tf_error)
-  pedwarn (input_location, OPT_Wpointer_arith,
+  pedwarn (location, OPT_Wpointer_arith,
   (code == PREINCREMENT_EXPR
   || code == POSTINCREMENT_EXPR)
-  ? G_("ISO C++ forbids incrementing a pointer of type 
%qT")
-  : G_("ISO C++ forbids decrementing a pointer of type 
%qT"),
+  ? G_("ISO C++ forbids incrementing a pointer "
+   "of type %qT")
+  : G_("ISO C++ forbids decrementing a pointer "
+   "of type %qT"),
   argtype);
 else
   return error_mark_node;
@@ -6597,8 +6602,9 @@ cp_build_unary_op (enum tree_code code, tree xarg,
if (code == POSTDECREMENT_EXPR || code == PREDECREMENT_EXPR)
  {
 if (complain & tf_error)
- error ("use of an operand of type %qT in % "
-"is forbidden", boolean_type_node);
+ error_at (location,
+   "use of an operand of type %qT in % "
+   "is forbidden", boolean_type_node);
return error_mark_node;
  }
else
@@ -6606,16 +6612,18 @@ cp_build_unary_op (enum tree_code code, tree xarg,
if (cxx_dialect >= cxx17)
  {
if (complain & tf_error)
- error ("use of an operand of type %qT in "
-"% is forbidden in C++17",
-boolean_type_node);
+ error_at (location,
+   "use of an operand of type %qT in "
+   "% is forbidden in C++17",

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

[Rainer Orth]

Hi Joseph,

> Code that directly uses _Decimal* types on architectures not
> supporting DFP is properly diagnosed ("error: decimal floating-point
> not supported for this target"), via a call to
> targetm.decimal_float_supported_p, if the _Decimal32, _Decimal64 or
> _Decimal128 keywords are used to access it.  Use via mode attributes
> is also diagnosed ("unable to emulate 'SD'"); so is use of the
> FLOAT_CONST_DECIMAL64 pragma.  However, it is possible to access those
> types via typeof applied to constants or built-in functions without
> such an error.  I expect that there are ways to get an ICE from this;
> certainly it uses a completely undefined ABI.
>
> This patch arranges for the types not to exist in the compiler at all
> when DFP is not supported.  As is done with unsupported _FloatN /
> _FloatNx types, the global tree nodes are left as NULL_TREE, and the
> built-in function machinery is made to use error_mark_node for them in
> that case in builtin-types.def, so that the built-in functions are
> unavailable.  Code handling constants is adjusted to give an error,
> and other code that might not work with the global tree nodes being
> NULL_TREE is also updated.
>
> Bootstrapped with no regressions for x86_64-pc-linux-gnu.  Also tested
> with no regressions for cross to aarch64-linux-gnu, as a configuration
> without DFP support.  OK to commit (the changes that aren't C front-end 
> changes)?

AFAICS this caused

+FAIL: libstdc++-abi/abi_check

on Solaris.  In libstdc++.log I find

# of added symbols:  0
# of missing symbols:9
# of undesignated symbols:   0
# of incompatible symbols:   9

9 missing symbols
0
_ZTIDf
typeinfo for decimal32
version status: unversioned
type: object
type size: 8
status: subtracted
[...]

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

Rainer

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

[Bug fortran/92533] [F2018] Permit module names in access-stmt (public::/private::)

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #4)
> Probably somewhere in module.c's gfc_use_module.

That's actually to early. gfc_use_module is run after all use statements have
been processed while the public/private statement comes much later.
Additionally for (cf. comment 1)
  use B
  use C
the information that a symbol has been loaded from B and/or C is lost – only
the true module ("A") remains. But we need to know later on that the symbol has
been loaded via B *and* C such that with "private :: B; public :: C" the
symbols are properly marked as public.
Hence, some tracking of the use-associated symbols until either resolving them
or until writing them to the .mod is needed – some kind of (symbol,
list-of-modules) container or (module, list-of-symbols)

RE: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?

[Andrew Dean via gcc]

> > This completes successfully. However, when I then try to run the gcc tests 
> > like
> so:
> > runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite
> > aarch64.exp --target aarch64-linux-gnu --target_board aarch64-sim
> > --tool_exec
> > /path_to/build_dir/install/compilers/aarch64-linux-gnu/bin/aarch64-gli
> > bc-linux-gnu-gcc --verbose -v
> >
> > I get errors like this:
> >
> > aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file
> > 'rdimon.specs': No such file or directory
> >
> > I can see that the rdimon.specs flag is added based on this line in aarch64-
> sim.exp:
> 
> Where does aarch64-sim.exp comes from?

/usr/share/dejagnu/baseboards/aarch64-sim.exp

> 
> >
> > set_board_info ldflags  "[libgloss_link_flags] [newlib_link_flags] -
> specs=rdimon.specs"
> >
> I think this is for baremetal/newlib targets, ie. aarch64-elf, not for 
> aarch64-
> linux-gnu.

Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or 
aarch64-linux-elf...
I get a KeyError in build_compilers and build_glibcs when it tries to look up 
the config with either of those values.

Re: Properly handle C2x attributes on types

[Rainer Orth]

Hi Joseph,

> attribs.c has code to ignore all scoped attributes appertaining to
> types except when they are part of the definition of that type.
>
> I think the premise of that code is incorrect, and its presence is a
> bug; such attributes are clearly valid in both C and C++, which
> explicitly specify that attributes in certain syntactic positions
> appertain to a particular type, only for that use of that type and not
> for other uses of the same type specifiers without that attribute
> specified, and while the standard attributes in C2x aren't relevant in
> such contexts, some gnu:: attributes certainly are.  Where some
> attributes are invalid on some types in such contexts, that's a matter
> for the individual attribute handlers to diagnose (or the front end if
> the requirements on a standard attribute in the standard are more
> strict than those of a handler shared with a GNU attribute).
>
> Thus, this patch removes the bogus code to allow such attributes to be
> used.  Doing so (and adding tests for attributes in such positions)
> shows up that the logic in the C front end for creating the
> c_declarator structures for such attributes put them in the wrong
> place relative to the structures for function and array types, and the
> logic for postfix attributes on a list of declaration specifiers
> failed to handle some cases, so those bugs are also fixed in this
> patch.
>
> Bootstrapped with no regressions for x86_64-pc-linux-gnu.  OK to commit 
> (attribs.c and C++ testsuite changes)?

it seems you missed updating a couple of testcases that are ia32-only:

+FAIL: g++.dg/cpp0x/gen-attrs-36.C  -std=gnu++14  (test for warnings, line 12)
+FAIL: g++.dg/cpp0x/gen-attrs-36.C  -std=gnu++14  (test for warnings, line 13)
+FAIL: g++.dg/cpp0x/gen-attrs-36.C  -std=gnu++14  (test for warnings, line 20)
+FAIL: g++.dg/cpp0x/gen-attrs-36.C  -std=gnu++14  (test for warnings, line 21)
+FAIL: g++.dg/cpp0x/gen-attrs-36.C  -std=gnu++14 (test for excess errors)

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/cpp0x/gen-attrs-36.C:12:50: 
warning: 'stdcall' attribute only applies to function types [-Wattributes]

+FAIL: g++.dg/cpp0x/gen-attrs-36.C  -std=gnu++17  (test for warnings, line 12)
+FAIL: g++.dg/cpp0x/gen-attrs-36.C  -std=gnu++17  (test for warnings, line 13)
+FAIL: g++.dg/cpp0x/gen-attrs-36.C  -std=gnu++17  (test for warnings, line 20)
+FAIL: g++.dg/cpp0x/gen-attrs-36.C  -std=gnu++17  (test for warnings, line 21)
+FAIL: g++.dg/cpp0x/gen-attrs-36.C  -std=gnu++17 (test for excess errors)
+FAIL: g++.dg/cpp0x/gen-attrs-36.C  -std=gnu++2a  (test for warnings, line 12)
+FAIL: g++.dg/cpp0x/gen-attrs-36.C  -std=gnu++2a  (test for warnings, line 13)
+FAIL: g++.dg/cpp0x/gen-attrs-36.C  -std=gnu++2a  (test for warnings, line 20)
+FAIL: g++.dg/cpp0x/gen-attrs-36.C  -std=gnu++2a  (test for warnings, line 21)
+FAIL: g++.dg/cpp0x/gen-attrs-36.C  -std=gnu++2a (test for excess errors)
+FAIL: g++.dg/cpp0x/gen-attrs-37.C  -std=gnu++14  (test for warnings, line 13)
+FAIL: g++.dg/cpp0x/gen-attrs-37.C  -std=gnu++17  (test for warnings, line 13)
+FAIL: g++.dg/cpp0x/gen-attrs-37.C  -std=gnu++2a  (test for warnings, line 13)
+FAIL: g++.dg/cpp0x/gen-attrs-8.C  -std=gnu++14  (test for warnings, line 6)
+FAIL: g++.dg/cpp0x/gen-attrs-8.C  -std=gnu++14 (test for excess errors)
+FAIL: g++.dg/cpp0x/gen-attrs-8.C  -std=gnu++17  (test for warnings, line 6)
+FAIL: g++.dg/cpp0x/gen-attrs-8.C  -std=gnu++17 (test for excess errors)
+FAIL: g++.dg/cpp0x/gen-attrs-8.C  -std=gnu++2a  (test for warnings, line 6)
+FAIL: g++.dg/cpp0x/gen-attrs-8.C  -std=gnu++2a (test for excess errors)

Rainer

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

Autoinc vs reload and LRA

[Bernd Schmidt]

So I was curious what would happen if I turned on LRA for m68k. It turns
out my autoinc patches from the cc0 patch set expose a bug in how LRA
handles autoincrement. While it copies the logic from reload's
inc_for_reload, it appears to be missing the find_reloads_address code
to ensure an autoinc address is reloaded entirely if it is part of a
jump. LRA can reload just the register inside a POST_INC, which leads to
creating an output reload.

Hence, a new version of the autoinc changes, below. Since reload is
known to work, we allow autoinc in jumps unless targetm.lra_p. One part
of the patch is a fix for the earlier combine patch which was already
checked in, the other part is a new version of the auto-inc-dec patch.
Bootstrapped and tested on the gcc135 machine
(powerpc64le-unknown-linux-gnu). OK?


Bernd
	* auto-inc-dec.c (merge_in_block): Allow autoinc in jumps unless
	LRA is enabled.
	* combine.c (can_combine_p): Disallow autoinc in jumps unless LRA is
	disabled.

diff --git a/gcc/auto-inc-dec.c b/gcc/auto-inc-dec.c
index bdb6efab520..1b224cc9777 100644
--- a/gcc/auto-inc-dec.c
+++ b/gcc/auto-inc-dec.c
@@ -1441,10 +1441,9 @@ merge_in_block (int max_reg, basic_block bb)
 	  continue;
 	}
 
-  /* This continue is deliberate.  We do not want the uses of the
-	 jump put into reg_next_use because it is not considered safe to
-	 combine a preincrement with a jump.  */
-  if (JUMP_P (insn))
+  /* Reload should handle auto-inc within a jump correctly, while LRA
+	 is known to have issues with autoinc.  */
+  if (JUMP_P (insn) && targetm.lra_p ())
 	continue;
 
   if (dump_file)
diff --git a/gcc/combine.c b/gcc/combine.c
index 2e21459f504..3fbd84fcb80 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -2117,12 +2117,16 @@ can_combine_p (rtx_insn *insn, rtx_insn *i3, rtx_insn *pred ATTRIBUTE_UNUSED,
 
   /* If INSN contains an autoincrement or autodecrement, make sure that
  register is not used between there and I3, and not already used in
- I3 either.  Neither must it be used in PRED or SUCC, if they exist.  */
+ I3 either.  Neither must it be used in PRED or SUCC, if they exist.
+ Also insist that I3 not be a jump if using LRA; if it were one
+ and the incremented register were spilled, we would lose.
+ Reload handles this correctly.  */
 
   if (AUTO_INC_DEC)
 for (link = REG_NOTES (insn); link; link = XEXP (link, 1))
   if (REG_NOTE_KIND (link) == REG_INC
-	  && (reg_used_between_p (XEXP (link, 0), insn, i3)
+	  && ((JUMP_P (i3) && targetm.lra_p ())
+	  || reg_used_between_p (XEXP (link, 0), insn, i3)
 	  || (pred != NULL_RTX
 		  && reg_overlap_mentioned_p (XEXP (link, 0), PATTERN (pred)))
 	  || (pred2 != NULL_RTX

Re: How to test aarch64 when building a cross-compiler?

[Christophe Lyon]

On Mon, 25 Nov 2019 at 20:17, Andrew Dean via gcc  wrote:
>
> Based on https://www.gnu.org/software/hurd/hurd/glibc.html, I'm using 
> glibc/scripts/build-many-glibcs.py targeting aarch64-linux-gnu as so:
>
> build-many-glibcs.py build_dir checkout --keep all
>
> build-many-glibcs.py build_dir host-libraries --keep all -j 12
>
> build-many-glibcs.py build_dir compilers aarch64-linux-gnu --keep all -j 12 
> --full-gcc
> build-many-glibcs.py build_dir glibcs aarch64-linux-gnu --keep all -j 12
>
> This completes successfully. However, when I then try to run the gcc tests 
> like so:
> runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite aarch64.exp 
> --target aarch64-linux-gnu --target_board aarch64-sim --tool_exec 
> /path_to/build_dir/install/compilers/aarch64-linux-gnu/bin/aarch64-glibc-linux-gnu-gcc
>  --verbose -v
>
> I get errors like this:
>
> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file 
> 'rdimon.specs': No such file or directory
>
> I can see that the rdimon.specs flag is added based on this line in 
> aarch64-sim.exp:

Where does aarch64-sim.exp comes from?

>
> set_board_info ldflags  "[libgloss_link_flags] [newlib_link_flags] 
> -specs=rdimon.specs"
>
I think this is for baremetal/newlib targets, ie. aarch64-elf, not for
aarch64-linux-gnu.

> I've tried searching for how to address this, but so far unsuccessfully. Does 
> anybody know what I'm missing here?
>
> Thanks,
> Andrew

[Bug c/89549] [8/9/10 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers

[david.bolvansky at gmail dot com]

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

--- Comment #17 from Dávid Bolvanský  ---
Check few lines above

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549#c8

[Bug libfortran/92569] [8/9 Regression] gfortran read with end directive does not trigger with -ffrontend-optimize

[tkoenig at gcc dot gnu.org]

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

--- Comment #11 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Nov 25 20:04:28 2019
New Revision: 278702

URL: https://gcc.gnu.org/viewcvs?rev=278702=gcc=rev
Log:
Fix EOF handling for arrays.

2019-11-25  Thomas Koenig  
Harald Anlauf 

Backport from trunk
PR fortran/92569
* io/transfer.c (transfer_array_inner):  If position is
at AFTER_ENDFILE in current unit, return from data loop.

2019-11-25  Thomas Koenig  
Harald Anlauf 

Backport from trunk
PR fortran/92569
* gfortran.dg/eof_6.f90: New test.


Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/eof_6.f90
Modified:
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/libgfortran/ChangeLog
branches/gcc-9-branch/libgfortran/io/transfer.c

[Bug target/92665] [AArch64] low lanes select not optimized out for vmlal intrinsics

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Wilco from comment #3)
> I think it's because many intrinsics in arm_neon.h still use asm which
> inhibits most optimizations.

NO in this case it is not.

Take:
#include "arm_neon.h"

float64x1_t fun(float64x2_t a, float64x2_t b) {
  return vget_low_f64(b);
}
double fun1(float64x2_t a, float64x2_t b) {
  return b[0];
}

 CUT 
Both of these should be optimized to just
fmov d0, d1
ret

Even worse take:
#include "arm_neon.h"

float64x1_t fun(float64x2_t a, float64x2_t b) {
  return vget_low_f64(b) + vget_high_f64(b);
}
double fun1(float64x2_t a, float64x2_t b) {
  return b[0] + b[1];
}

 CUT ---

[Bug c/89549] [8/9/10 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Of course there is, -Wno-misleading-indentation or use line breaks from time to
time.  With >= 4KB long lines, the user clearly doesn't care about indentation,
so the warning doesn't make sense.

[Bug c/85678] -fno-common should be default

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82922

--- Comment #14 from Eric Gallager  ---
(In reply to David Brown from comment #11)
> Reliance on -fcommon has not been correct or compatible with any C standard
> (I don't think it was even right for K C).  If the code is written
> correctly (with at most one definition of all externally linked symbols)
> then -fcommon does not make it incorrect or conflict with the standards. 
> But if your code requires -fcommon to compile correctly, it does not conform
> to C89 or anything newer.
> 
> Personally, I'd like to see many old and dangerous C practices give errors
> by default.  Along with common symbols, I'd include non-prototype function
> declarations and definitions, and calling functions without declaring them. 
> These are the kind of thing you'd expect to see in pre-ANSI C - other than
> that, they  are probably errors in the code.  It is good that gcc still
> supports such code, but I think making them errors by default will reduce
> bugs in current code.  And surely that is worth the cost of adding a
> "-fold-code" flag to ancient build recipes?  (The "-fold-code" flag could
> probably also imply "-fno-strict-aliasing -fwrapv" to deal with other
> assumptions sometimes made in older code.)
> 
> There is precedence for this.  The default standard for gcc changed from
> "gnu89" to "gnu11".  While most "gnu89" code will compile with the same
> semantics in "gnu11" mode, there are a fair number of incompatibilities. 
> Changing the default to "-fno-common" (and ideally
> "-Werror=strict-prototypes -Werror=old-style-declaration
> -Werror=missing-parameter-type") would have a lot smaller impact than
> changing the default standard.

Related: bug 82922

[Bug c/85678] -fno-common should be default

[fw at gcc dot gnu.org]

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

--- Comment #13 from Florian Weimer  ---
(In reply to Wilco from comment #12)
> Giving errors on old-style code by default sounds like a good idea. We could
> add -std=legacy similar to Fortran to support building old K code (and
> that would enable -fcommon by default).

It's unfortunately not that simple. A lot of these changes (admittedly I've
only tried -Werror=implicit-function-declaration by default, something that
trips even experienced developers) tend to produce broken, but internally
consistent builds because autoconf checks give wrong results (and everything,
including the test suite, depends on those results). This was true for a
significant number of core GNU components until this year, including GCC
itself.

[Bug fortran/92629] internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:173

[anlauf at gcc dot gnu.org]

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Mon Nov 25 19:50:38 2019
New Revision: 278699

URL: https://gcc.gnu.org/viewcvs?rev=278699=gcc=rev
Log:
2019-11-25  Harald Anlauf  

PR fortran/92629
* simplify.c (convert_mpz_to_unsigned): Skip assert for argument
range when -fno-range-check is specified.

PR fortran/92629
* gfortran.dg/pr92629.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr92629.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c/92663] Add __gcc_has_bug or __gcc_bug_fixed

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
This sounds like it could be dangerous from a security context... currently no
network connection is needed to use gcc, it would be a major disappointment if
that changed...

[Bug target/92665] [AArch64] low lanes select not optimized out for vmlal intrinsics

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #3 from Wilco  ---
(In reply to Andrew Pinski from comment #2)
> Created attachment 47356 [details]
> Patch which I wrote for GCC 7.3
> 
> I have to double check if it applies directly as I had other patches in this
> area but this is the patch which I had wrote for GCC 7.3.

I think it's because many intrinsics in arm_neon.h still use asm which inhibits
most optimizations.

[Bug bootstrap/92661] [10 Regression] AIX bootstrap failure with builtin-types.def change

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner  ---
(In reply to jos...@codesourcery.com from comment #4)
> My suggestion for the target-specific built-in functions would be:
> 
> * builtin_function_type in rs6000-call.c should detect the case of a 
> DECIMAL_FLOAT_MODE_P mode and NULL_TREE ret_type and return NULL_TREE in 
> place of the existing error in that case.
> 
> * rs6000_common_init_builtins should then accept a NULL_TREE type as 
> indicating not to call def_builtin (or def_builtin could accept it as 
> indicating to return early).

The following implements that idea, although, we have to test the arguments for
similar issues as the return type.  It fixes my powerpc64le-linux
--disable-decimal-float build.

David, can you test this on AIX?



Index: gcc/config/rs6000/rs6000-call.c
===
--- gcc/config/rs6000/rs6000-call.c (revision 278692)
+++ gcc/config/rs6000/rs6000-call.c (working copy)
@@ -2935,6 +2935,10 @@ def_builtin (const char *name, tree type
   unsigned classify = rs6000_builtin_info[(int)code].attr;
   const char *attr_string = "";

+  /* Don't define the builtin if it doesn't have a type.  See PR92661.  */
+  if (type == NULL_TREE)
+return;
+
   gcc_assert (name != NULL);
   gcc_assert (IN_RANGE ((int)code, 0, (int)RS6000_BUILTIN_COUNT));

@@ -7702,6 +7706,11 @@ builtin_function_type (machine_mode mode
   if (!ret_type && h.uns_p[0])
 ret_type = builtin_mode_to_type[h.mode[0]][0];

+  /* If the required decimal float type has been disabled, then return
+ without an error.  */
+  if (!ret_type && DECIMAL_FLOAT_MODE_P (h.mode[0]))
+return NULL_TREE;
+
   if (!ret_type)
 fatal_error (input_location,
 "internal error: builtin function %qs had an unexpected "
@@ -7719,6 +7728,11 @@ builtin_function_type (machine_mode mode
   if (!arg_type[i] && uns_p)
arg_type[i] = builtin_mode_to_type[m][0];

+  /* If the required decimal float type has been disabled, then return
+without an error.  */
+  if (!arg_type[i] && DECIMAL_FLOAT_MODE_P (m))
+   return NULL_TREE;
+
   if (!arg_type[i])
fatal_error (input_location,
 "internal error: builtin function %qs, argument %d "

[Bug target/92665] [AArch64] low lanes select not optimized out for vmlal intrinsics

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 47356
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47356=edit
Patch which I wrote for GCC 7.3

I have to double check if it applies directly as I had other patches in this
area but this is the patch which I had wrote for GCC 7.3.

[Bug c/85678] -fno-common should be default

[wilco at gcc dot gnu.org]

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

--- Comment #12 from Wilco  ---
(In reply to David Brown from comment #11)

> Changing the default to "-fno-common" (and ideally
> "-Werror=strict-prototypes -Werror=old-style-declaration
> -Werror=missing-parameter-type") would have a lot smaller impact than
> changing the default standard.

Giving errors on old-style code by default sounds like a good idea. We could
add -std=legacy similar to Fortran to support building old K code (and that
would enable -fcommon by default).

How to test aarch64 when building a cross-compiler?

[Andrew Dean via gcc]

Based on https://www.gnu.org/software/hurd/hurd/glibc.html, I'm using 
glibc/scripts/build-many-glibcs.py targeting aarch64-linux-gnu as so:

build-many-glibcs.py build_dir checkout --keep all

build-many-glibcs.py build_dir host-libraries --keep all -j 12

build-many-glibcs.py build_dir compilers aarch64-linux-gnu --keep all -j 12 
--full-gcc
build-many-glibcs.py build_dir glibcs aarch64-linux-gnu --keep all -j 12

This completes successfully. However, when I then try to run the gcc tests like 
so:
runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite aarch64.exp 
--target aarch64-linux-gnu --target_board aarch64-sim --tool_exec 
/path_to/build_dir/install/compilers/aarch64-linux-gnu/bin/aarch64-glibc-linux-gnu-gcc
 --verbose -v

I get errors like this:

aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file 'rdimon.specs': 
No such file or directory

I can see that the rdimon.specs flag is added based on this line in 
aarch64-sim.exp:

set_board_info ldflags  "[libgloss_link_flags] [newlib_link_flags] 
-specs=rdimon.specs"

I've tried searching for how to address this, but so far unsuccessfully. Does 
anybody know what I'm missing here?

Thanks,
Andrew

[Bug ipa/92538] Proposal for IPA init() constant propagation

[erick.oc...@theobroma-systems.com]

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

Erick Ochoa  changed:

   What|Removed |Added

 CC||erick.ochoa@theobroma-syste
   ||ms.com

--- Comment #3 from Erick Ochoa  ---
Created attachment 47355
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47355=edit
Update for ipa-initcall-cp

When applied to master (commit id: d0c0f2f6d2ba374085840c79882a13a4f7bbb6f9)
this patch adds an optimization to propagate constants initialized in init
functions.

[Bug c/89549] [8/9/10 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers

[david.bolvansky at gmail dot com]

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

--- Comment #15 from Dávid Bolvanský  ---
But there is no way to silence this "note".

[Bug target/92665] [AArch64] low lanes select not optimized out for vmlal intrinsics

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||aarch64-linux-gnu
 Status|UNCONFIRMED |NEW
Version|unknown |10.0
   Keywords||missed-optimization
   Last reconfirmed||2019-11-25
  Component|rtl-optimization|target
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
Confirmed.
I have a patch (or two) that will optimize this.
I was going to be submitting them in the next few days.

[Bug libstdc++/91786] Clang 8.0.1 can't compile the header on Windows

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Mon Nov 25 19:01:58 2019
New Revision: 278697

URL: https://gcc.gnu.org/viewcvs?rev=278697=gcc=rev
Log:
PR libstdc++/91786 fix compilation error with Clang

PR libstdc++/91786
* include/bits/fs_path.h (filesystem_error): Move definition before
the use in u8path.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/fs_path.h

[PATCH] libstdc++: Add move_sentinel, common_iterator and counted_iterator

[Jonathan Wakely]

This implements most of the remaining C++20 additions to the 
header.

* include/bits/iterator_concepts.h (ranges::iter_swap): Fix parameter
types of poison pill overload. Use remove_reference_t when checking
constraints.
* include/bits/stl_iterator.h (move_sentinel): Define for C++20.
(move_iterator): Adjust definitions of nested types for C++20. Add
hidden friends for move_sentinel operations, iter_move and iter_swap.
(common_iterator, counted_iterator): Define for C++20.
* testsuite/24_iterators/move_iterator/cust.cc: New test.
* testsuite/24_iterators/move_iterator/sentinel.cc: New test.
* testsuite/24_iterators/common_iterator/1.cc: New test.
* testsuite/24_iterators/counted_iterator/1.cc: New test.

Tested powerpc64le-linux, committed to trunk.


commit b22fa1c5cf385af43e1b0c67bdae047b6c3436d3
Author: Jonathan Wakely 
Date:   Thu Oct 17 17:48:52 2019 +0100

libstdc++: Add move_sentinel, common_iterator and counted_iterator

This implements most of the remaining C++20 additions to the 
header.

* include/bits/iterator_concepts.h (ranges::iter_swap): Fix 
parameter
types of poison pill overload. Use remove_reference_t when checking
constraints.
* include/bits/stl_iterator.h (move_sentinel): Define for C++20.
(move_iterator): Adjust definitions of nested types for C++20. Add
hidden friends for move_sentinel operations, iter_move and 
iter_swap.
(common_iterator, counted_iterator): Define for C++20.
* testsuite/24_iterators/move_iterator/cust.cc: New test.
* testsuite/24_iterators/move_iterator/sentinel.cc: New test.
* testsuite/24_iterators/common_iterator/1.cc: New test.
* testsuite/24_iterators/counted_iterator/1.cc: New test.

diff --git a/libstdc++-v3/include/bits/iterator_concepts.h 
b/libstdc++-v3/include/bits/iterator_concepts.h
index 3843ba5d57f..97aed72e255 100644
--- a/libstdc++-v3/include/bits/iterator_concepts.h
+++ b/libstdc++-v3/include/bits/iterator_concepts.h
@@ -700,7 +700,7 @@ namespace ranges
   namespace __cust_iswap
   {
 template
-  void iter_swap(_It1&, _It2&) = delete;
+  void iter_swap(_It1, _It2) = delete;
 
 template
   concept __adl_iswap
@@ -744,7 +744,8 @@ namespace ranges
 public:
   template
requires __adl_iswap<_Tp, _Up>
-   || (readable<_Tp> && readable<_Up>
+   || (readable>
+   && readable>
&& swappable_with, iter_reference_t<_Up>>)
|| (indirectly_movable_storable<_Tp, _Up>
&& indirectly_movable_storable<_Up, _Tp>)
diff --git a/libstdc++-v3/include/bits/stl_iterator.h 
b/libstdc++-v3/include/bits/stl_iterator.h
index a707621c9ed..89cca64438c 100644
--- a/libstdc++-v3/include/bits/stl_iterator.h
+++ b/libstdc++-v3/include/bits/stl_iterator.h
@@ -73,6 +73,11 @@
 # define __cpp_lib_array_constexpr 201803
 #endif
 
+#if __cplusplus > 201703L
+# include 
+# include 
+#endif
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -1055,12 +1060,61 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 { return __it.base(); }
 
 #if __cplusplus >= 201103L
-
   /**
* @addtogroup iterators
* @{
*/
 
+#if __cplusplus > 201703L && __cpp_lib_concepts
+  template
+class move_sentinel
+{
+public:
+  constexpr
+  move_sentinel()
+  noexcept(is_nothrow_default_constructible_v<_Sent>)
+  : _M_last() { }
+
+  constexpr explicit
+  move_sentinel(_Sent __s)
+  noexcept(is_nothrow_move_constructible_v<_Sent>)
+  : _M_last(std::move(__s)) { }
+
+  template requires convertible_to
+   constexpr
+   move_sentinel(const move_sentinel<_S2>& __s)
+   noexcept(is_nothrow_constructible_v<_Sent, const _S2&>)
+   : _M_last(__s.base())
+   { }
+
+  template requires assignable_from<_Sent&, const _S2&>
+   constexpr move_sentinel&
+   operator=(const move_sentinel<_S2>& __s)
+   noexcept(is_nothrow_assignable_v<_Sent, const _S2&>)
+   {
+ _M_last = __s.base();
+ return *this;
+   }
+
+  constexpr _Sent
+  base() const
+  noexcept(is_nothrow_copy_constructible_v<_Sent>)
+  { return _M_last; }
+
+private:
+  _Sent _M_last;
+};
+
+  namespace __detail
+  {
+// Weaken iterator_category _Cat to _Limit if it is derived from that,
+// otherwise use _Otherwise.
+template
+  using __clamp_iter_cat
+   = conditional_t, _Limit, _Otherwise>;
+  }
+#endif // C++20
+
   // 24.4.3  Move iterators
   /**
*  Class template move_iterator is an iterator adapter with the same
@@ -1073,14 +1127,27 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 class move_iterator
 {
-protected:
   _Iterator _M_current;
 
-  typedef iterator_traits<_Iterator>   __traits_type;
-  typedef typename 

[PATCH] PR libstdc++/91786 fix compilation error with Clang

[Jonathan Wakely]

PR libstdc++/91786
* include/bits/fs_path.h (filesystem_error): Move definition before
the use in u8path.

Tested powerpc64le-linux, committed to trunk.


commit 48db2e15557a1e7bff8ce629c8e9979d0b6d0c29
Author: Jonathan Wakely 
Date:   Fri Nov 22 00:29:05 2019 +

PR libstdc++/91786 fix compilation error with Clang

PR libstdc++/91786
* include/bits/fs_path.h (filesystem_error): Move definition before
the use in u8path.

diff --git a/libstdc++-v3/include/bits/fs_path.h 
b/libstdc++-v3/include/bits/fs_path.h
index e1083acf30f..031ec3d7c7f 100644
--- a/libstdc++-v3/include/bits/fs_path.h
+++ b/libstdc++-v3/include/bits/fs_path.h
@@ -622,59 +622,6 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 
   size_t hash_value(const path& __p) noexcept;
 
-  /// Create a path from a UTF-8-encoded sequence of char
-  template
-inline auto
-u8path(_InputIterator __first, _InputIterator __last)
--> decltype(filesystem::path(__first, __last, std::locale::classic()))
-{
-#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
-  // XXX This assumes native wide encoding is UTF-16.
-  std::codecvt_utf8_utf16 __cvt;
-  path::string_type __tmp;
-  if constexpr (is_pointer_v<_InputIterator>)
-   {
- if (__str_codecvt_in_all(__first, __last, __tmp, __cvt))
-   return path{ __tmp };
-   }
-  else
-   {
- const std::string __u8str{__first, __last};
- const char* const __ptr = __u8str.data();
- if (__str_codecvt_in_all(__ptr, __ptr + __u8str.size(), __tmp, __cvt))
-   return path{ __tmp };
-   }
-  _GLIBCXX_THROW_OR_ABORT(filesystem_error(
-   "Cannot convert character sequence",
-   std::make_error_code(errc::illegal_byte_sequence)));
-#else
-  // This assumes native normal encoding is UTF-8.
-  return path{ __first, __last };
-#endif
-}
-
-  /// Create a path from a UTF-8-encoded sequence of char
-  template
-inline auto
-u8path(const _Source& __source)
--> decltype(filesystem::path(__source, std::locale::classic()))
-{
-#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
-  if constexpr (is_convertible_v)
-   {
- const std::string_view __s = __source;
- return filesystem::u8path(__s.data(), __s.data() + __s.size());
-   }
-  else
-   {
- std::string __s = path::_S_string_from_iter(__source);
- return filesystem::u8path(__s.data(), __s.data() + __s.size());
-   }
-#else
-  return path{ __source };
-#endif
-}
-
   /// @}
 
   /// Exception type thrown by the Filesystem library
@@ -706,6 +653,65 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 std::__shared_ptr _M_impl;
   };
 
+  /** Create a path from a UTF-8-encoded sequence of char
+   *
+   * @relates std::filesystem::path
+   */
+  template
+inline auto
+u8path(_InputIterator __first, _InputIterator __last)
+-> decltype(filesystem::path(__first, __last, std::locale::classic()))
+{
+#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
+  // XXX This assumes native wide encoding is UTF-16.
+  std::codecvt_utf8_utf16 __cvt;
+  path::string_type __tmp;
+  if constexpr (is_pointer_v<_InputIterator>)
+   {
+ if (__str_codecvt_in_all(__first, __last, __tmp, __cvt))
+   return path{ __tmp };
+   }
+  else
+   {
+ const std::string __u8str{__first, __last};
+ const char* const __ptr = __u8str.data();
+ if (__str_codecvt_in_all(__ptr, __ptr + __u8str.size(), __tmp, __cvt))
+   return path{ __tmp };
+   }
+  _GLIBCXX_THROW_OR_ABORT(filesystem_error(
+   "Cannot convert character sequence",
+   std::make_error_code(errc::illegal_byte_sequence)));
+#else
+  // This assumes native normal encoding is UTF-8.
+  return path{ __first, __last };
+#endif
+}
+
+  /** Create a path from a UTF-8-encoded sequence of char
+   *
+   * @relates std::filesystem::path
+   */
+  template
+inline auto
+u8path(const _Source& __source)
+-> decltype(filesystem::path(__source, std::locale::classic()))
+{
+#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
+  if constexpr (is_convertible_v)
+   {
+ const std::string_view __s = __source;
+ return filesystem::u8path(__s.data(), __s.data() + __s.size());
+   }
+  else
+   {
+ std::string __s = path::_S_string_from_iter(__source);
+ return filesystem::u8path(__s.data(), __s.data() + __s.size());
+   }
+#else
+  return path{ __source };
+#endif
+}
+
   /// @cond undocumented
 
   struct path::_Cmpt : path

[Bug rtl-optimization/92665] New: [AArch64] low lanes select not optimized out for vmlal intrinsics

[spop at gcc dot gnu.org]

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

Bug ID: 92665
   Summary: [AArch64] low lanes select not optimized out for vmlal
intrinsics
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: spop at gcc dot gnu.org
  Target Milestone: ---

With gcc as of today I see dup instructions that could be optimized out:

$ cat red.c
#include "arm_neon.h"

int32x4_t fun(int32x4_t a, int16x8_t b, int16x8_t c) {
  a = vmlal_s16(a, vget_low_s16(b), vget_low_s16(c));
  a = vmlal_high_s16(a, b, c);
  return a;
}

$ gcc -O3 -S -o- red.c
fun:
dup d3, v1.d[0]
dup d4, v2.d[0]
smlal v0.4s,v3.4h,v4.4h
smlal2 v0.4s,v1.8h,v2.8h
ret

$ clang -O3 -S -o- red.c
fun:
smlal   v0.4s, v1.4h, v2.4h
smlal2  v0.4s, v1.8h, v2.8h
ret

[Bug c/89549] [8/9/10 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  ---
I don't see a bug here, it behaves as expected, once you have too long line
somewhere or too many lines, column tracking is disabled and column tracking is
essential for this warning:
  /* PR c++/68819: if the column number is zero, we presumably
 had a location_t > LINE_MAP_MAX_LOCATION_WITH_COLS, and so
 we have no column information.
 Act as if no conversion was possible, triggering the
 error-handling path in the caller.  */
  if (!exploc.column)
{
  static bool issued_note = false;
  if (!issued_note)
{
  /* Notify the user the first time this happens.  */
  issued_note = true;
  inform (loc,
  "%<-Wmisleading-indentation%> is disabled from this point"
  " onwards, since column-tracking was disabled due to"
  " the size of the code/headers");
}
  return false;
}
This isn't a note that is related to some particular warning, just a message
telling that there won't be any further warnings emitted due to this later.

[Bug c/92663] Add __gcc_has_bug or __gcc_bug_fixed

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
Sometimes bug reports don't get a bugzilla #.
Also would you consider code generation (not wrong code but unoptimial code
generation) get an entry?

Could you provide a full example of where you think this would be useful?