Re: [PATCH] Support multilib-aware target lib flags self-specs overriding

[Alexandre Oliva via Gcc-patches]

On May 20, 2022, Alexandre Oliva  wrote:

> Regstrapped on x86_64-linux-gnu.  Ok to install?

Ping?  https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595356.html

> for  gcc/ChangeLog

>   * common.opt (multiflags): New.
>   * doc/invoke.texi: Document it.
>   * gcc.cc (driver_self_specs): Discard it.
>   * opts.cc (common_handle_option): Ignore it in the driver.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: libiberty: Would it be reasonable to add support for GnuCOBOL function name demangling?

[Simon Sobisch via Gcc-patches]

Am 27.05.22 um 20:31 schrieb Eric Gallager:

On Fri, May 27, 2022 at 3:17 AM Simon Sobisch via Gcc-patches
 wrote:

[...] the first question is: is it reasonable to add support for
GnuCOBOL?

* How would the demangler know it is to be called? Just "best match"
(GnuCOBOL modules always have some symbols in it which should be
available if there is any debugging information in, if that helps)?
* Giving the work of gcc-cobol which was discussed on this mailing list
some months ago (not sure about its current state) there possibly will
be a COBOL support be "integrated" - with possibly different name
mangling. But still - GnuCOBOL is used "in the wild" (for production
environments) since years (and will be for many years to come, both
based on GCC and with other compilers) and the name mangling rules did
not change.

If the plan is to integrate GnuCOBOL into trunk, then I'd say adding
demangling support for it to libiberty would not only be reasonable,
but also a necessary prerequisite for merging the rest of it.


Just to ensure that there aren't confusions:

Nobody intends to integrate GnuCOBOL [0] into gcc; but it would be 
important for gcobol for being integrated into gcc to succeed.


GnuCOBOL (formerly OpenCOBOL) is a project which translates COBOL to 
intermediate C (mostly consisting of calls to functions in the GnuCOBOL 
runtime library libcob), then executes the "native" / system C compiler.
It is very mature and used a lot; we _suggest_ to use GCC but also work 
with other free and nonfree compilers on free and nonfree systems.


gcobol [1][2] (I've also seen it referenced as gcc-cobol) is an actual 
gcc frontend, so translates into gcc intermediate format. As far as I 
know, the plans are to both provide a usable working COBOL compiler and 
reach a state for integration until 2023. It possibly will use a very 
small but important part of libcob (at least if available) to provide 
support of a COBOL-native way to read/write data.
When it comes up to the integration phase it _could_ be considered to 
integrate only those parts as-is (so effectively forking libcob to 
glibcob), as both GCC and GnuCOBOL are FSF-Copyrighted - or add it as an 
optional dependency (a lot of COBOL users don't use that 'old' way of 
accessing data and moved to EXEC SQL preprocessors instead).


But as GnuCOBOL maintainer my question here was about the GnuCOBOL name 
mangling.
I've now learned that as there isn't an explicit prefix like Z_ the 
de-mangling will be an "upon request", and as far as current responses 
were it seems like an reasonable approach and "patches to add that are 
likely to be accepted" (otherwise I won't start, because obviously there 
is always something to do on the GnuCOBOL side, too).


Simon

[0]: http://www.gnu.org/software/gnucobol

[1]: https://gcc.gnu.org/pipermail/gcc/2022-March/238408.html
[2]: https://git.symas.net/cobolworx/gcc-cobol/-/tree/master+cobol/gcc/cobol

[pushed] Darwin: Amend REAL_LIBGCC_SPEC comment [NFC].

[Iain Sandoe via Gcc-patches]

This comment had got out of sync with reality, partly due to merging
of patches.  Updated to reflect the current implementation.

Signed-off-by: Iain Sandoe 

gcc/ChangeLog:

* config/darwin.h (REAL_LIBGCC_SPEC): Update the comment block
describing this macro.
---
 gcc/config/darwin.h | 38 +-
 1 file changed, 13 insertions(+), 25 deletions(-)

diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index 3682bd2b2c5..b73e12372d8 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -465,48 +465,36 @@ extern GTY(()) int darwin_ms_struct;
 
 #define LIB_SPEC "%{!static:-lSystem}"
 
-/*
-   Note that by default, -lgcc_eh is not linked against.
-   This is because,in general, we need to unwind through system libraries that
-   are linked with the shared unwinder in libunwind (or libgcc_s for 10.4/5).
+/* Note that by default, -lgcc_eh (which provides a statically-linked unwinder)
+   is not used. This is because, in general, we need to unwind through system
+   libraries that are linked with the shared unwinder in libunwind (or libgcc_s
+   for OSX 10.4/5 [darwin8/9]).
 
-   For -static-libgcc: < 10.6, use the unwinder in libgcc_eh (and find
-   the emultls impl. there too).
+   When -static-libgcc is forced: < 10.6, use the unwinder in libgcc_eh (and
+   find the emultls impl. there too).
 
For -static-libgcc: >= 10.6, the unwinder *still* comes from libSystem and
we find the emutls impl from lemutls_w. In either case, the builtins etc.
-   are linked from -lgcc.
+   are linked from -lgcc.  The eh library is still available so that it could
+   be specified explicitly if there is some reason to do so.
 
When we have specified shared-libgcc or any case that might require
exceptions, we pull the libgcc content (including emulated tls) from
-   -lgcc_s.1 in GCC and the unwinder from /usr/lib/libgcc_s.1 for < 10.6 and
+   -lgcc_s.1.1 in GCC and the unwinder from /usr/lib/libgcc_s.1 for < 10.6 and
libSystem for >= 10.6 respectively.
Otherwise, we just link the emutls/builtins from convenience libs.
 
-   If we need exceptions, prior to 10.3.9, then we have to link the static
-   eh lib, since there's no shared version on the system.
-
-   In all cases, libgcc_s.1 will be installed with the compiler, or any app
-   built using it, so we can link the builtins and emutls shared on all.
-
We have to work around that DYLD_ are disabled in macOS 10.11+ which
means that any bootstrap trying to use a shared libgcc with a bumped SO-
name will fail.  This means that we do not accept shared libgcc for these
-   versions.
+   versions (the primary reason for forcing a shared libgcc was that it
+   contained the unwinder on Darwin8 and 9).
 
-   For -static-libgcc: >= 10.6, the unwinder *still* comes from libSystem and
-   we find the emutls impl from lemutls_w. In either case, the builtins etc.
-   are linked from -lgcc.
->
-   Otherwise, we just link the shared version of gcc_s.1.1 and pick up
-   exceptions:
+   When using the shared version of gcc_s.1.1 the unwinder is provided by:
  * Prior to 10.3.9, then we have to link the static eh lib, since there
-   is no shared version on the system.
+   is no shared unwinder version on the system.
  * from 10.3.9 to 10.5, from /usr/lib/libgcc_s.1.dylib
  * from 10.6 onwards, from libSystem.dylib
-
-   In all cases, libgcc_s.1.1 will be installed with the compiler, or any app
-   built using it, so we can link the builtins and emutls shared on all.
 */
 #undef REAL_LIBGCC_SPEC
 #define REAL_LIBGCC_SPEC \
-- 
2.24.3 (Apple Git-128)

Re: [PATCH] Add divide by zero side effect.

[Eric Gallager via Gcc-patches]

On Fri, May 27, 2022 at 3:57 PM Andrew MacLeod via Gcc-patches
 wrote:
>
> On 5/27/22 15:33, Andi Kleen wrote:
> > Andrew MacLeod via Gcc-patches  writes:
> >> diff --git a/gcc/gimple-range-side-effect.cc 
> >> b/gcc/gimple-range-side-effect.cc
> >> index 2c8c77dc569..548e4bea313 100644
> >> --- a/gcc/gimple-range-side-effect.cc
> >> +++ b/gcc/gimple-range-side-effect.cc
> >> @@ -116,6 +116,23 @@ stmt_side_effects::stmt_side_effects (gimple *s)
> >>   walk_stmt_load_store_ops (s, (void *)this, non_null_loadstore,
> >>non_null_loadstore);
> >>
> >> +  if (is_a (s))
> >> +{
> >> +  switch (gimple_assign_rhs_code (s))
> >> +{
> >> +case TRUNC_DIV_EXPR:
> >> +case CEIL_DIV_EXPR:
> >> +case FLOOR_DIV_EXPR:
> >> +case ROUND_DIV_EXPR:
> >> +case EXACT_DIV_EXPR:
> >> +  // Divide means operand 2 is not zero after this stmt.
> >> +  if (gimple_range_ssa_p (gimple_assign_rhs2 (s)))
> >> +add_nonzero (gimple_assign_rhs2 (s));
> > Sorry I'm late, but how does this ensure the value is a integer?
> > I believe for floating point the assumption is not correct because
> > division by zero doesn't necessarily fault.
> >
> > -Andi
> >
> gimple_range_ssa_p() only returns non-zero when the value is an ssa_name
> whose type is supported by the range calculators... currently only
> integrals values.  When we support floating points we will have to add
> additional logic.
>

Maybe add a comment to that effect, then? As a reminder...

> Andrew
>

libbacktrace patch committed: Update README

[Ian Lance Taylor via Gcc-patches]

This patch updates the libbacktrace README to a near copy of the one
from github.com/ianlancetaylor/libbacktrace.  Committed to mainline.
This fixes GCC PR 105721.

Ian

* README: Update.
6cf19361732bd7f8b41716ef9f4b5c205a3193b8
diff --git a/libbacktrace/README b/libbacktrace/README
index e8b225745c9..6225f92b855 100644
--- a/libbacktrace/README
+++ b/libbacktrace/README
@@ -1,23 +1,31 @@
 The libbacktrace library
-Initially written by Ian Lance Taylor 
+Initially written by Ian Lance Taylor 
 
 The libbacktrace library may be linked into a program or library and
-used to produce symbolic backtraces.  Sample uses would be to print a
-detailed backtrace when an error occurs or to gather detailed
-profiling information.
+used to produce symbolic backtraces.
+Sample uses would be to print a detailed backtrace when an error
+occurs or to gather detailed profiling information.
+In general the functions provided by this library are async-signal-safe,
+meaning that they may be safely called from a signal handler.
 
-The libbacktrace library is provided under a BSD license.  See the
-source files for the exact license text.
+The libbacktrace library is provided under a BSD license.
+See the source files for the exact license text.
 
 The public functions are declared and documented in the header file
 backtrace.h, which should be #include'd by a user of the library.
 
 Building libbacktrace will generate a file backtrace-supported.h,
 which a user of the library may use to determine whether backtraces
-will work.  See the source file backtrace-supported.h.in for the
-macros that it defines.
+will work.
+See the source file backtrace-supported.h.in for the macros that it
+defines.
 
-As of September 2012, libbacktrace only supports ELF executables with
-DWARF debugging information.  The library is written to make it
-straightforward to add support for other object file and debugging
-formats.
+As of October 2020, libbacktrace supports ELF, PE/COFF, Mach-O, and
+XCOFF executables with DWARF debugging information.
+In other words, it supports GNU/Linux, *BSD, macOS, Windows, and AIX.
+The library is written to make it straightforward to add support for
+other object file and debugging formats.
+
+The library relies on the C++ unwind API defined at
+https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html
+This API is provided by GCC and clang.

Re: [PATCH] Modula-2: merge proposal/review: 1/9 01.patch-set-01

[Gaius Mulley via Gcc-patches]

Richard Biener  writes:

> On Wed, May 25, 2022 at 9:50 PM Gaius Mulley  wrote:
>>
>> Richard Biener  writes:
>>
>> > So is there a reason to have the 'scaffold' separate from the object
>> > of hello.mod?
>>
>> Perhaps the major advantage is flexibility?  But no we can by default
>> produce the scaffold within the object of hello.mod (and give users the
>> ability to disable scaffold generation should they wish to implement
>> their own).
>>
>> > Is there more than a 1:1 relation between a .mod and the 'scaffold'?
>>
>> yes there is a 1:1 relation between a .mod and the scaffold.  Although
>> the caveat is that the compiler would need to parse every .def and .mod
>> imports from the application universe.  Not a major change as gm2 has
>> the ability to do whole program (application) compiling, so a minor set
>> of changes to ensure that upon compiling the program module that it also
>> parses every .def/.mod.
>>
>> > Why are multiple tools involved here - can the m2 frontend not parse
>> > imports, reorder runtime modules and generate the 'scaffold' as
>> > GENERIC IL as part of the translation unit of the .mod file?
>> > Indirection through emitting C++ source code makes the process a bit
>> > awkward IMHO.
>>
>> indeed the m2 front end can parse imports, reorder and generate the
>> scaffold.
>>
>> > Unfortunately I have no m2 installation around to look at how complex
>> > the 'scaffold' is.
>>
>> the scaffold is really simple for example here it is for hello.mod:
>>
>>   $ gm2 -c -g -fmakelist hello.mod
>>   $ cat hello.lst
>> Storage
>> SYSTEM
>> M2RTS
>> RTExceptions
>> # libc   11 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/libc.def FOR 'C'
>> # SYSTEM   11 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/SYSTEM.mod
>> # StrIO   11 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/StrIO.mod
>> # StrLib   10 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/StrLib.mod
>> # ASCII   10 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/ASCII.mod
>> # NumberIO   10 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/NumberIO.mod
>> # Indexing   10 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/Indexing.mod
>> # errno9 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/errno.def
>> # termios9 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/termios.def
>> # FIO9 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/FIO.mod
>> # IO8 /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/IO.mod
>> # StdIO7 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/StdIO.mod
>> # Debug6 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/Debug.mod
>> # SysStorage5 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/SysStorage.mod
>> # SysExceptions4 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/SysExceptions.def
>> # M2EXCEPTION4 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/M2EXCEPTION.mod
>> # Storage4 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/Storage.mod
>> # RTExceptions3 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/RTExceptions.mod
>> # M2RTS2 
>> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/M2RTS.mod
>> # hello1 hello.mod
>> #
>> # Initialization order
>> #
>> StrIO
>> StrLib
>> ASCII
>> NumberIO
>> Indexing
>> errno
>> termios
>> FIO
>> IO
>> StdIO
>> Debug
>> SysStorage
>> SysExceptions
>> M2EXCEPTION
>> hello
>>
>>and now to generate the scaffold for a static application:
>>
>>$ ~/opt/bin/gm2 -fmakeinit -c -g hello.mod
>>$ cat hello_m2.cpp
>> extern "C" void exit(int);
>>
>> extern "C" void RTExceptions_DefaultErrorCatch(void);
>> extern "C" void _M2_Storage_init (int argc, char *argv[]);
>> extern "C" void _M2_Storage_finish (void);
>> extern "C" void _M2_SYSTEM_init (int argc, char *argv[]);
>> extern "C" void _M2_SYSTEM_finish (void);
>> extern "C" void _M2_M2RTS_init (int argc, char *argv[]);
>> extern "C" void _M2_M2RTS_finish (void);
>> extern "C" void _M2_RTExceptions_init (int argc, char *argv[]);
>> extern "C" void _M2_RTExceptions_finish (void);
>> extern "C" void _M2_StrIO_init (int argc, char *argv[]);
>> extern "C" void _M2_StrIO_finish (void);
>> extern "C" void _M2_StrLib_init (int argc, char *argv[]);
>> extern "C" void _M2_StrLib_finish (void);
>> extern "C" void _M2_ASCII_init (int argc, char *argv[]);
>> extern "C" void _M2_ASCII_finish (void);
>> extern "C" void _M2_NumberIO_init (int argc, char *argv[]);
>> extern "C" void _M2_NumberIO_finish (void);
>> extern "C" void _M2_Indexing_init (int argc, char *argv[]);
>> extern "C" void _M2_Indexing_finish (void);
>> extern "C" void _M2_errno_init (int argc, char *argv[]);
>> extern "C" void _M2_errno_finish (void);
>> extern "C" void _M2_termios_init (int argc, char *argv[]);
>> extern "C" void _M2_termios

Re: Vim swap files not ignored

[Jeff Law via Gcc-patches]

On 5/25/2022 11:02 AM, Bruce Korb via Gcc-patches wrote:

Subject:
Vim swap files not ignored
From:
Bruce Korb via Gcc-patches 
Date:
5/25/2022, 11:02 AM

To:
gcc-patches@gcc.gnu.org


Hi,
I don't have the keys for write access anymore. This ought to be 
applied. Odd that it never has been. :)

Applied.  We can certainly get you fresh keys if you want them Bruce!

jeff

[committed] [PR target/103722] Fix register_move_cost for the sh

[Jeff Law via Gcc-patches]

As outlined in the BZ the sh is returning cost 2 for various reg->reg 
moves.  Cost 2 has special meaning to reload and prevents the insns from 
being re-recognized.  Vlad's patch bumps the cost to 7.  Other values 
might be better, but given this has been languishing for ~6 months and 
there are no signs of an SH expert stepping in to provide a better 
value, I'm going with Vlad's patch from the PR as-is.


Committed to the trunk,
Jeffcommit 42d8fb2d4569e9930e277b01170bfd3586bf94d3
Author: Vladimir Makarov 
Date:   Sat May 28 12:08:38 2022 -0600

Fix ICE on sh

gcc/
PR target/103722
* config/sh/sh.c (sh_register_move_cost): Avoid cost "2" (which
is special) for various scenarios.

diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
index 8d4056338a5..03e1c04ec7e 100644
--- a/gcc/config/sh/sh.cc
+++ b/gcc/config/sh/sh.cc
@@ -10762,6 +10762,12 @@ sh_register_move_cost (machine_mode mode,
   && ! REGCLASS_HAS_GENERAL_REG (dstclass))
 return 2 * ((GET_MODE_SIZE (mode) + 7) / 8U);
 
+  if (((dstclass == FP_REGS || dstclass == DF_REGS)
+   && (srcclass == PR_REGS))
+  || ((srcclass == FP_REGS || srcclass == DF_REGS)
+ && (dstclass == PR_REGS)))
+return 7;
+
   return 2 * ((GET_MODE_SIZE (mode) + 3) / 4U);
 }
 

Re: libatomic: drop redundant all-multi command

[Jeff Law via Gcc-patches]

On 5/27/2022 2:01 AM, Jan Beulich via Gcc-patches wrote:

./multilib.am already specifies this same command, and make warns about
the earlier one being ignored when seeing the later one. All that needs
retaining to still satisfy the preceding comment is the extra
dependency.

libatomic/
2022-05-XX  Jan Beulich  

* Makefile.am (all-multi): Drop commands.
* Makefile.in: Update accordingly.

OK for the trunk.
jeff

Re: [PATCH] sourcebuild.texi: Document new toplevel directories [PR82383]

[Jeff Law via Gcc-patches]

On 5/24/2022 11:32 AM, Eric Gallager via Gcc-patches wrote:

This patch adds entries for the c++tools, gotools, libbacktrace,
libcc1, libcody, liboffloadmic, and libsanitizer directories into the
list of toplevel source directories in sourcebuild.texi. I also
removed the entry for boehm-gc (which is no longer in-tree), and fixed
the alphabetization for libquadmath while I was at it. Any style nits
I need to fix before committing (with a proper ChangeLog entry)?
I think this is fine.  If you're looking for a good cleanup, removing 
liboffloadmic  would be useful IMHO.  MIC is dead.


jeff

Re: [PATCH v3] DSE: Use the constant store source if possible

[Jeff Law via Gcc-patches]

On 5/26/2022 2:43 PM, H.J. Lu via Gcc-patches wrote:

On Thu, May 26, 2022 at 04:14:17PM +0100, Richard Sandiford wrote:

"H.J. Lu"  writes:

On Wed, May 25, 2022 at 12:30 AM Richard Sandiford
 wrote:

"H.J. Lu via Gcc-patches"  writes:

On Mon, May 23, 2022 at 12:38:06PM +0200, Richard Biener wrote:

On Sat, May 21, 2022 at 5:02 AM H.J. Lu via Gcc-patches
 wrote:

When recording store for RTL dead store elimination, check if the source
register is set only once to a constant.  If yes, record the constant
as the store source.  It eliminates unrolled zero stores after memset 0
in a loop where a vector register is used as the zero store source.

gcc/

 PR rtl-optimization/105638
 * dse.cc (record_store): Use the constant source if the source
 register is set only once.

gcc/testsuite/

 PR rtl-optimization/105638
 * g++.target/i386/pr105638.C: New test.
---
  gcc/dse.cc   | 19 ++
  gcc/testsuite/g++.target/i386/pr105638.C | 44 
  2 files changed, 63 insertions(+)
  create mode 100644 gcc/testsuite/g++.target/i386/pr105638.C

diff --git a/gcc/dse.cc b/gcc/dse.cc
index 30c11cee034..0433dd3d846 100644
--- a/gcc/dse.cc
+++ b/gcc/dse.cc
@@ -1508,6 +1508,25 @@ record_store (rtx body, bb_info_t bb_info)

   if (tem && CONSTANT_P (tem))
 const_rhs = tem;
+ else
+   {
+ /* If RHS is set only once to a constant, set CONST_RHS
+to the constant.  */
+ df_ref def = DF_REG_DEF_CHAIN (REGNO (rhs));
+ if (def != nullptr
+ && !DF_REF_IS_ARTIFICIAL (def)
+ && !DF_REF_NEXT_REG (def))
+   {
+ rtx_insn *def_insn = DF_REF_INSN (def);
+ rtx def_body = PATTERN (def_insn);
+ if (GET_CODE (def_body) == SET)
+   {
+ rtx def_src = SET_SRC (def_body);
+ if (CONSTANT_P (def_src))
+   const_rhs = def_src;

doesn't DSE have its own tracking of stored values?  Shouldn't we

It tracks stored values only within the basic block.  When RTL loop
invariant motion hoists a constant initialization out of the loop into
a separate basic block, the constant store value becomes unknown
within the original basic block.


improve _that_ if it is not enough?  I also wonder if you need to

My patch extends DSE stored value tracking to include the constant which
is set only once in another basic block.


verify the SET isn't partial?


Here is the v2 patch to check that the constant is set by a non-partial
unconditional load.

OK for master?

Thanks.

H.J.
---
RTL DSE tracks redundant constant stores within a basic block.  When RTL
loop invariant motion hoists a constant initialization out of the loop
into a separate basic block, the constant store value becomes unknown
within the original basic block.  When recording store for RTL DSE, check
if the source register is set only once to a constant by a non-partial
unconditional load.  If yes, record the constant as the constant store
source.  It eliminates unrolled zero stores after memset 0 in a loop
where a vector register is used as the zero store source.

gcc/

   PR rtl-optimization/105638
   * dse.cc (record_store): Use the constant source if the source
   register is set only once.

gcc/testsuite/

   PR rtl-optimization/105638
   * g++.target/i386/pr105638.C: New test.
---
  gcc/dse.cc   | 22 
  gcc/testsuite/g++.target/i386/pr105638.C | 44 
  2 files changed, 66 insertions(+)
  create mode 100644 gcc/testsuite/g++.target/i386/pr105638.C

diff --git a/gcc/dse.cc b/gcc/dse.cc
index 30c11cee034..af8e88dac32 100644
--- a/gcc/dse.cc
+++ b/gcc/dse.cc
@@ -1508,6 +1508,28 @@ record_store (rtx body, bb_info_t bb_info)

 if (tem && CONSTANT_P (tem))
   const_rhs = tem;
+   else
+ {
+   /* If RHS is set only once to a constant, set CONST_RHS
+  to the constant.  */
+   df_ref def = DF_REG_DEF_CHAIN (REGNO (rhs));
+   if (def != nullptr
+   && !DF_REF_IS_ARTIFICIAL (def)
+   && !(DF_REF_FLAGS (def)
+& (DF_REF_PARTIAL | DF_REF_CONDITIONAL))
+   && !DF_REF_NEXT_REG (def))

Can we introduce a helper for this?  There are already similar tests
in ira and loop-iv, and it seems a bit too complex to have to open-code
each time.

I can use find_single_def_src in loop-iv.cc:

/* If REGNO has a single definition, return its known value, otherwise return
null.  */

rtx
find_single_def_src (unsigned int regno)

Yeah, reusing that sounds good.  Perhaps we should move it into df-core.cc,
alongside the df_reg_used group of functions.

I think the mode check in your original patch should be kept though,
so how about we change the parameter to an rtx reg and use rtx_equal 

Re: [PATCH 2/2] avr: Removed errant control characters

[Jeff Law via Gcc-patches]

On 4/1/2022 9:20 AM, Joel Holdsworth via Gcc-patches wrote:

Signed-off-by: Joel Holdsworth 
---
  gcc/config/avr/avr-devices.cc | 2 --
  1 file changed, 2 deletions(-)
These aren't really errant.  There was a time when these form feeds were 
actually encouraged and you'll find them all over the place in GCC.


I'd just assume remove them all at this point, but I think that would 
need broader consensus.


jeff

Re: [PATCH] avr: add support for tinyAVR 2 family

[Jeff Law via Gcc-patches]

On 4/26/2022 8:59 AM, Torsten Duwe via Gcc-patches wrote:

Signed-off-by: Torsten Duwe 

---
gcc/ChangeLog:

2022-04-26  Torsten Duwe  

* config/avr/avr-mcus.def (AVR_MCU): add definitions for
attiny{4,8,16,32}2{4,6,7}; 4k and 8k flash types use RCALL.
Are these independent of patch from Joel Holdworth?  I think so, but I'm 
not at all familiar with the avr family of chips, so it'd be good if 
someone with more familiarity would chime in.


I think you need to update avr-mmcu.texi for the new chips as well.

jeff

Re: [PATCH 1/2] avr: Added AVR-DA and DB MCU series

[Jeff Law via Gcc-patches]

On 4/1/2022 9:20 AM, Joel Holdsworth via Gcc-patches wrote:

gcc/
 * config/avr/avr-mcus.def: Add device definitions.
 * doc/avr-mmcu.texi: Corresponding changes.
 * gcc/config/avr/gen-avr-mmcu-texi.c: Added support for avr
   device prefix.
 * gcc/config/avr/gen-avr-mmcu-specs.c: Prevent -mmcu=avr* flags
   from leaking into cc1.
I fixed a few trivial issues with the ChangeLog and pushed this patch to 
the trunk.

jeff

[PATCH] PR fortran/91300 - runtime error message with allocate and errmsg=

[Harald Anlauf via Gcc-patches]

Dear Fortranners,

the PR rightfully complained that we did not differentiate errors on
ALLOCATE(...,stat=,errmsg=) for failures from allocation of already
allocated objects or insufficient virtual memory.

The attached patch introduces a new STAT value LIBERROR_NO_MEMORY
that is returned for insufficient virtual memory, and a corresponding
(simple and invariant) ERRMSG: "Insufficient virtual memory".

(In the PR Janne mentions checking for errno, but since the standard
malloc(3) only mentions ENOMEM as possible error value, and the user
may replace malloc by a special library, I believe that won't be easy
to handle in a general way.)

Most compilers I tried (Intel/NAG/Crayftn) behave similarly, except
for Nvidia/Flang, which try to return the size of the allocation in
the error message.

I am not sure that this is worth the effort.  First, ERRMSG is very
compiler-dependent anyway and thus not really portable.  If a user
wants to know what the size of the failed allocation is and really
wants to recover, he/she should find that out himself.  Second, I
think that the more important change is the introduction of a STAT
value that allows the distinction between the different causes of
failure.

The testcase should be able to handle 32 and 64 bit systems.
At least that's what I think.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?  Suggestions?

Thanks,
Harald

From 19ccd22ee9359bd14b32a95bd9efcaead3593b2f Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Sat, 28 May 2022 22:02:20 +0200
Subject: [PATCH] Fortran: improve runtime error message with ALLOCATE and
 ERRMSG=

ALLOCATE: generate different STAT,ERRMSG results for failures from
allocation of already allocated objects or insufficient virtual memory.

gcc/fortran/ChangeLog:

	PR fortran/91300
	* libgfortran.h: Define new error code LIBERROR_NO_MEMORY.
	* trans-stmt.cc (gfc_trans_allocate): Generate code for setting
	ERRMSG depending on result of STAT result of ALLOCATE.
	* trans.cc (gfc_allocate_using_malloc): Use STAT value of
	LIBERROR_NO_MEMORY in case of failed malloc.

gcc/testsuite/ChangeLog:

	PR fortran/91300
	* gfortran.dg/allocate_alloc_opt_15.f90: New test.
---
 gcc/fortran/libgfortran.h |  1 +
 gcc/fortran/trans-stmt.cc | 33 +--
 gcc/fortran/trans.cc  |  4 +-
 .../gfortran.dg/allocate_alloc_opt_15.f90 | 40 +++
 4 files changed, 73 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/allocate_alloc_opt_15.f90

diff --git a/gcc/fortran/libgfortran.h b/gcc/fortran/libgfortran.h
index 064795eb469..4328447be04 100644
--- a/gcc/fortran/libgfortran.h
+++ b/gcc/fortran/libgfortran.h
@@ -133,6 +133,7 @@ typedef enum
   LIBERROR_CORRUPT_FILE,
   LIBERROR_INQUIRE_INTERNAL_UNIT, /* Must be different from STAT_STOPPED_IMAGE.  */
   LIBERROR_BAD_WAIT_ID,
+  LIBERROR_NO_MEMORY,
   LIBERROR_LAST			/* Not a real error, the last error # + 1.  */
 }
 libgfortran_error_codes;
diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index 79096816c6e..fd6d294147e 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -7130,7 +7130,8 @@ gfc_trans_allocate (gfc_code * code)
   if (code->expr1 && code->expr2)
 {
   const char *msg = "Attempt to allocate an allocated object";
-  tree slen, dlen, errmsg_str;
+  const char *oommsg = "Insufficient virtual memory";
+  tree slen, dlen, errmsg_str, oom_str, oom_loc;
   stmtblock_t errmsg_block;

   gfc_init_block (&errmsg_block);
@@ -7151,8 +7152,34 @@ gfc_trans_allocate (gfc_code * code)
 			 gfc_default_character_kind);
   dlen = gfc_finish_block (&errmsg_block);

-  tmp = fold_build2_loc (input_location, NE_EXPR, logical_type_node,
-			 stat, build_int_cst (TREE_TYPE (stat), 0));
+  tmp = fold_build2_loc (input_location, EQ_EXPR, logical_type_node,
+			 stat, build_int_cst (TREE_TYPE (stat),
+		  LIBERROR_ALLOCATION));
+
+  tmp = build3_v (COND_EXPR, tmp,
+		  dlen, build_empty_stmt (input_location));
+
+  gfc_add_expr_to_block (&block, tmp);
+
+  oom_str = gfc_create_var (pchar_type_node, "OOMMSG");
+  oom_loc = gfc_build_localized_cstring_const (oommsg);
+  gfc_add_modify (&errmsg_block, oom_str,
+		  gfc_build_addr_expr (pchar_type_node, oom_loc));
+
+  slen = build_int_cst (gfc_charlen_type_node, strlen (oommsg));
+  dlen = gfc_get_expr_charlen (code->expr2);
+  slen = fold_build2_loc (input_location, MIN_EXPR,
+			  TREE_TYPE (slen), dlen, slen);
+
+  gfc_trans_string_copy (&errmsg_block, dlen, errmsg,
+			 code->expr2->ts.kind,
+			 slen, oom_str,
+			 gfc_default_character_kind);
+  dlen = gfc_finish_block (&errmsg_block);
+
+  tmp = fold_build2_loc (input_location, EQ_EXPR, logical_type_node,
+			 stat, build_int_cst (TREE_TYPE (stat),
+		  LIBERROR_NO_MEMORY));

   tmp = build3_v (COND_EXPR, tmp,
 		  dlen, build_empty_st

Re: [PATCH] sourcebuild.texi: Document new toplevel directories [PR82383]

[Eric Gallager via Gcc-patches]

On Sat, May 28, 2022 at 2:30 PM Jeff Law via Gcc-patches
 wrote:
> On 5/24/2022 11:32 AM, Eric Gallager via Gcc-patches wrote:
> > This patch adds entries for the c++tools, gotools, libbacktrace,
> > libcc1, libcody, liboffloadmic, and libsanitizer directories into the
> > list of toplevel source directories in sourcebuild.texi. I also
> > removed the entry for boehm-gc (which is no longer in-tree), and fixed
> > the alphabetization for libquadmath while I was at it. Any style nits
> > I need to fix before committing (with a proper ChangeLog entry)?
> I think this is fine.  If you're looking for a good cleanup, removing
> liboffloadmic  would be useful IMHO.  MIC is dead.
>

OK thanks, committed as r13-817. I'll leave removing the liboffloadmic
directory for someone else to do, as it still has stuff in it.