GCC 9.4.1 Status Report (2022-05-20)

[Richard Biener via Gcc-patches]

Status
==

The GCC 9 branch is now frozen for its final release, GCC 9.5.
The branch will be closed after that.


Quality Data


Priority  #   Change from last report
---   ---
P1  
P2  369   - 58
P3  37-  5
P4  186   -  2 
P5  25 
---   ---
Total P1-P3 406   - 58
Total   617   - 65


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2022-May/238655.html

Re: [PATCH] ipa-icf: skip variables with body_removed

[Martin Liška]

On 5/19/22 17:02, Jan Hubicka wrote:
>> Similarly to cgraph_nodes, it may happen that body_removed is set
>> during merging of symbols.
>>
>>  PR ipa/105600
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
>> Thanks,
>> Martin
>>
>> gcc/ChangeLog:
>>
>>  * ipa-icf.cc (sem_item_optimizer::filter_removed_items):
>>  Skip variables with body_removed.
>> ---
>>  gcc/ipa-icf.cc | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/gcc/ipa-icf.cc b/gcc/ipa-icf.cc
>> index 765ae746745..6528a7a10b2 100644
>> --- a/gcc/ipa-icf.cc
>> +++ b/gcc/ipa-icf.cc
>> @@ -2411,10 +2411,11 @@ sem_item_optimizer::filter_removed_items (void)
>>  {
>>/* Filter out non-readonly variables.  */
>>tree decl = item->decl;
>> -  if (TREE_READONLY (decl))
>> -filtered.safe_push (item);
>> -  else
>> +  varpool_node *vnode = static_cast > *>(item)->get_node ();
>> +  if (!TREE_READONLY (decl) || vnode->body_removed)
>>  remove_item (item);
>> +  else
>> +filtered.safe_push (item);
> 
> So the situation here is that we merge symbols but keep syntactic alias
> because the declarations are not compatible (have different attributes
> perhaps because of fortify source)?

The test-case is more about a constexpr symbol or so, I'm not familiar enough
with these modern C++.

cgraph_node looks like:

(gdb) p item->node->debug()
_ZN8nlohmann6detail12static_constINS0_10to_json_fnEE5valueE/10 (value) 
@0x77fb3200
  Type: variable
  Body removed by symtab_remove_unreachable_nodes
  Visibility: externally_visible semantic_interposition preempted_reg external 
public weak comdat 
comdat_group:_ZN8nlohmann6detail12static_constINS0_10to_json_fnEE5valueE 
one_only
  References: 
  Referring: 
_Z7to_jsonRN8nlohmann10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmiSaNS_14adl_serializerES2_IhSaIhRK8Settings/1
 (addr) 
_Z7to_jsonRN8nlohmann10basic_jsonISt3mapSt6vectorNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEblmiSaNS_14adl_serializerES2_IhSaIhRK8Settings/1
 (addr) 
  Read from file: a.o
  Availability: not_available
  Varpool flags: initialized read-only


> 
> Will ICF still see through the aliases and do merging?

No.

> I think you can
> craft a testcase by triggering the attribute mismatch and see what
> happens.  At the time we implemented ICF these aliases did not exists,
> so maybe some TLC is needed here.

Please come up with such test case :)

Thanks,
Martin

> 
> Honza

Re: [PATCH v3 09/10] libgcc: Add support for HF mode (aka _Float16) in libbid

[Christophe Lyon via Gcc-patches]

On 5/19/22 21:35, Joseph Myers wrote:

On Thu, 19 May 2022, Christophe Lyon via Gcc-patches wrote:


Hi Joseph,

May I ping you on this version? (I've moved the tests to gcc.dg/torture/ and
checked they work on aarch64 and x86_64.


This version is OK, given a bug report filed in Bugzilla for the
double-rounding issues with conversions from DFP modes to HFmode.



Thanks!

I've filed PR 105669.

Christophe

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

[Richard Biener via Gcc-patches]

On Fri, May 20, 2022 at 8:38 AM Alexander Monakov  wrote:
>
> On Fri, 20 May 2022, Richard Biener via Gcc-patches wrote:
>
> > > Still waiting for a suggestion, since "side effect" is the description
> > > that made sense to me :-)
> >
> > I think side-effect captures it quite well even if it overlaps with a term
> > used in language standards.  Doing c = a << b has the side-effect on
> > imposing a range on 'b' rather than just affecting 'c' (and its range).
> > You could call it 'alternate effect' but that sounds just awkward ;)
>
> I suggest 'deduce', 'deduction', 'deducing a range'. What the code is actually
> doing is deducing that 'b' in 'a / b' cannot be zero. Function in GCC might be
> called like 'deduce_ranges_from_stmt'.

So how would you call determining the range of 'c' from the ranges of
'a' and 'b',
isn't that 'deduction' as well?

> Please don't overload 'side effect' if possible.
>
> Alexander

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

[Eric Botcazou via Gcc-patches]

> I suggest 'deduce', 'deduction', 'deducing a range'. What the code is
> actually doing is deducing that 'b' in 'a / b' cannot be zero. Function in
> GCC might be called like 'deduce_ranges_from_stmt'.

Or "infer", "inference", "inferring a range".

> Please don't overload 'side effect' if possible.

Agreed, "side effect" is something precisely defined in the compiler context.

-- 
Eric Botcazou

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

[Eric Botcazou via Gcc-patches]

> I think side-effect captures it quite well even if it overlaps with a term
> used in language standards.

IMO it's very confusing, see the subject: "Add divide by zero side effect".
The only side effect of dividing by zero is (possibly) raising a trap.

-- 
Eric Botcazou

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

[Alexander Monakov via Gcc-patches]

On Fri, 20 May 2022, Richard Biener wrote:

> On Fri, May 20, 2022 at 8:38 AM Alexander Monakov  wrote:
> >
> > On Fri, 20 May 2022, Richard Biener via Gcc-patches wrote:
> >
> > > > Still waiting for a suggestion, since "side effect" is the description
> > > > that made sense to me :-)
> > >
> > > I think side-effect captures it quite well even if it overlaps with a term
> > > used in language standards.  Doing c = a << b has the side-effect on
> > > imposing a range on 'b' rather than just affecting 'c' (and its range).
> > > You could call it 'alternate effect' but that sounds just awkward ;)
> >
> > I suggest 'deduce', 'deduction', 'deducing a range'. What the code is 
> > actually
> > doing is deducing that 'b' in 'a / b' cannot be zero. Function in GCC might 
> > be
> > called like 'deduce_ranges_from_stmt'.
> 
> So how would you call determining the range of 'c' from the ranges of
> 'a' and 'b', isn't that 'deduction' as well?

Kind of, yes, but for this sort of forward inference I imagine you're already
using 'propagate [ranges through a stmt]', like in 'value range propagation'.

If you'd like to avoid 'propagate'/'deduce' asymmetry, I could suggest
'forward inference' / 'backward inference', but I like it a bit less.

Alexander

Re: [PATCH] libstdc++-v3: Set 26_numerics/random/n.b.d./op./values.cc timeout-factor to 3

[Jonathan Wakely via Gcc-patches]

On Fri, 20 May 2022 at 03:20, Hans-Peter Nilsson via Libstdc++
 wrote:
>
> Also, how about shortening those test-suite file-paths?
> They're path sort-of overlong for any git (and ChangeLog)
> commit-line limit. 1/2 :-)

Yes, they're silly. I like what libc++ does, i.e. name the testsuite
directories after the [stable.name] tags in the standard. They have
std/rand/rand.dis/rand.dist.bern/rand.dist.bern.negbin (for some
reason they use "rand.dis" instead of "rand.dist" for the third
component there, which is not what the standard has,
https://eel.is/c++draft/rand.dist.bern.negbin shows the subclause
hierarchy).

That's still quite unwieldy, so we could remove the repetition and use
26_numerics/rand/dist/bernoulli/negbin/. The problem now is that it
gets quite cryptic, so finding the tests for the
negative_binomial_distribution is a bit harder if you don't know where
to look (but git grep solves that in less than a second).



>
> Ok to commit (without renaming)?

I'm OK with the timeout factor, but we could also solve it differently
so that it doesn't take nearly 5 minutes, as in the attached patch.
The testDiscreteDist function can be parametrized with the number of
iterations to perform. Would you rather do that?
diff --git 
a/libstdc++-v3/testsuite/26_numerics/random/negative_binomial_distribution/operators/values.cc
 
b/libstdc++-v3/testsuite/26_numerics/random/negative_binomial_distribution/operators/values.cc
index dda6f43b254..a3120401d09 100644
--- 
a/libstdc++-v3/testsuite/26_numerics/random/negative_binomial_distribution/operators/values.cc
+++ 
b/libstdc++-v3/testsuite/26_numerics/random/negative_binomial_distribution/operators/values.cc
@@ -26,6 +26,14 @@
 #include 
 #include 
 
+// { dg-options "-DSIMULATOR_TEST" { target simulator } }
+
+#ifdef SIMULATOR_TEST
+# define ARGS 100, 1000
+#else
+# define ARGS
+#endif
+
 void test01()
 {
   using namespace __gnu_test;
@@ -34,18 +42,18 @@ void test01()
 
   std::negative_binomial_distribution<> nbd1(5, 0.3);
   auto bnbd1 = std::bind(nbd1, eng);
-  testDiscreteDist(bnbd1, [](int n)
-  { return negative_binomial_pdf(n, 5, 0.3); } );
+  testDiscreteDist(bnbd1, [](int n)
+{ return negative_binomial_pdf(n, 5, 0.3); } );
 
   std::negative_binomial_distribution<> nbd2(55, 0.3);
   auto bnbd2 = std::bind(nbd2, eng);
-  testDiscreteDist(bnbd2, [](int n)
-  { return negative_binomial_pdf(n, 55, 0.3); } );
+  testDiscreteDist(bnbd2, [](int n)
+{ return negative_binomial_pdf(n, 55, 0.3); } );
 
   std::negative_binomial_distribution<> nbd3(10, 0.75);
   auto bnbd3 = std::bind(nbd3, eng);
-  testDiscreteDist(bnbd3, [](int n)
-  { return negative_binomial_pdf(n, 10, 0.75); } );
+  testDiscreteDist(bnbd3, [](int n)
+{ return negative_binomial_pdf(n, 10, 0.75); } );
 }
 
 int main()

Re: [PATCH] libstdc++-v3: Set 26_numerics/random/n.b.d./op./values.cc timeout-factor to 3

[Jonathan Wakely via Gcc-patches]

On Fri, 20 May 2022 at 10:03, Jonathan Wakely  wrote:
>
> On Fri, 20 May 2022 at 03:20, Hans-Peter Nilsson via Libstdc++
>  wrote:
> >
> > Also, how about shortening those test-suite file-paths?
> > They're path sort-of overlong for any git (and ChangeLog)
> > commit-line limit. 1/2 :-)
>
> Yes, they're silly. I like what libc++ does, i.e. name the testsuite
> directories after the [stable.name] tags in the standard. They have
> std/rand/rand.dis/rand.dist.bern/rand.dist.bern.negbin (for some
> reason they use "rand.dis" instead of "rand.dist" for the third
> component there, which is not what the standard has,
> https://eel.is/c++draft/rand.dist.bern.negbin shows the subclause
> hierarchy).
>
> That's still quite unwieldy, so we could remove the repetition and use
> 26_numerics/rand/dist/bernoulli/negbin/. The problem now is that it
> gets quite cryptic, so finding the tests for the
> negative_binomial_distribution is a bit harder if you don't know where
> to look (but git grep solves that in less than a second).

Or we could forget about mirroring the nesting in the standard and
just use 26_numerics/random/dist/negative_binomial

That's still too long for ChangeLogs though.

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

[Richard Biener via Gcc-patches]

On Wed, May 18, 2022 at 3:47 PM Gaius Mulley via Gcc-patches
 wrote:
>
> hello,
>
> this file is part-01 of the patch set for the gm2 review.

I think you did a better job last time splitting the patches.  This
one contains the
driver changes for which I have a hard time remembering the reason they exist
and whether we already discussed it to death or not.

So - with the chance to re-open and old discussion - what's special about
modula-2 so it needs so many changes here?  Are all of them necessary
or are most of them merely "cleanups" that could be done as followup?

Thanks,
Richard.

>
> 1.  all GCC files which have been patched.
> ==
>
> The 'Only in' diff output was:
>
> Only in gcc-git-devel-modula2/gcc: m2
> Only in gcc-git-devel-modula2/gcc/testsuite: gm2
> Only in gcc-git-devel-modula2/gcc/testsuite/lib: gm2-dg.exp
> Only in gcc-git-devel-modula2/gcc/testsuite/lib: gm2.exp
> Only in gcc-git-devel-modula2/gcc/testsuite/lib: gm2-simple.exp
> Only in gcc-git-devel-modula2/gcc/testsuite/lib: gm2-torture.exp
> Only in gcc-git-devel-modula2/gcc/doc: gm2.texi
> Only in gcc-git-devel-modula2: libgm2
> Only in gcc-git-devel-modula2: gm2tools
>
> and the recursive diffs:
>
>
> diff -x '*autom4te*' -rwu gcc/configure.ac gcc-git-devel-modula2/configure.ac
> --- gcc/configure.ac2022-05-17 11:20:57.487964366 +0100
> +++ gcc-git-devel-modula2/configure.ac  2022-05-17 14:41:05.480881101 +0100
> @@ -140,7 +140,7 @@
>  # binutils, gas and ld appear in that order because it makes sense to run
>  # "make check" in that particular order.
>  # If --enable-gold is used, "gold" may replace "ld".
> -host_tools="texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim 
> gdb gdbserver gprof etc expect dejagnu m4 utils guile fastjar gnattools 
> libcc1 gotools c++tools"
> +host_tools="texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim 
> gdb gdbserver gprof etc expect dejagnu m4 utils guile fastjar gnattools 
> libcc1 gm2tools gotools c++tools"
>
>  # these libraries are built for the target environment, and are built after
>  # the host libraries and the host tools (which may be a cross compiler)
> @@ -162,6 +162,7 @@
> target-libffi \
> target-libobjc \
> target-libada \
> +   target-libgm2 \
> target-libgo \
> target-libphobos \
> target-zlib"
> @@ -459,6 +460,14 @@
>noconfigdirs="$noconfigdirs gnattools"
>  fi
>
> +AC_ARG_ENABLE(libgm2,
> +[AS_HELP_STRING([--enable-libgm2], [build libgm2 directory])],
> +ENABLE_LIBGM2=$enableval,
> +ENABLE_LIBGM2=no)
> +if test "${ENABLE_LIBGM2}" != "yes" ; then
> +  noconfigdirs="$noconfigdirs gm2tools"
> +fi
> +
>  AC_ARG_ENABLE(libssp,
>  [AS_HELP_STRING([--enable-libssp], [build libssp directory])],
>  ENABLE_LIBSSP=$enableval,
> @@ -3617,6 +3626,7 @@
>  NCN_STRICT_CHECK_TARGET_TOOLS(GFORTRAN_FOR_TARGET, gfortran)
>  NCN_STRICT_CHECK_TARGET_TOOLS(GOC_FOR_TARGET, gccgo)
>  NCN_STRICT_CHECK_TARGET_TOOLS(GDC_FOR_TARGET, gdc)
> +NCN_STRICT_CHECK_TARGET_TOOLS(GM2_FOR_TARGET, gm2)
>
>  ACX_CHECK_INSTALLED_TARGET_TOOL(AR_FOR_TARGET, ar)
>  ACX_CHECK_INSTALLED_TARGET_TOOL(AS_FOR_TARGET, as)
> @@ -3655,6 +3665,8 @@
> [gcc/gccgo -B$$r/$(HOST_SUBDIR)/gcc/], go)
>  GCC_TARGET_TOOL(gdc, GDC_FOR_TARGET, GDC,
> [gcc/gdc -B$$r/$(HOST_SUBDIR)/gcc/], d)
> +GCC_TARGET_TOOL(gm2, GM2_FOR_TARGET, GM2,
> +   [gcc/gm2 -B$$r/$(HOST_SUBDIR)/gcc/], m2)
>  GCC_TARGET_TOOL(ld, LD_FOR_TARGET, LD, [ld/ld-new])
>  GCC_TARGET_TOOL(lipo, LIPO_FOR_TARGET, LIPO)
>  GCC_TARGET_TOOL(nm, NM_FOR_TARGET, NM, [binutils/nm-new])
> @@ -3781,6 +3793,9 @@
>  # Specify what files to not compare during bootstrap.
>
>  compare_exclusions="gcc/cc*-checksum\$(objext) | gcc/ada/*tools/*"
> +compare_exclusions="$compare_exclusions | 
> gcc/m2/gm2-compiler-boot/M2Version*"
> +compare_exclusions="$compare_exclusions | gcc/m2/gm2-compiler-boot/SYSTEM*"
> +compare_exclusions="$compare_exclusions | gcc/m2/gm2version*"
>  case "$target" in
>hppa*64*-*-hpux*) ;;
>hppa*-*-hpux*) compare_exclusions="$compare_exclusions | 
> */libgcc/lib2funcs* | gcc/function-tests.o" ;;
> diff -x '*autom4te*' -rwu gcc/gcc/c/gccspec.cc 
> gcc-git-devel-modula2/gcc/c/gccspec.cc
> --- gcc/gcc/c/gccspec.cc2022-05-17 11:20:57.919969752 +0100
> +++ gcc-git-devel-modula2/gcc/c/gccspec.cc  2022-05-17 14:41:05.552881117 
> +0100
> @@ -105,3 +105,9 @@
>
>  /* Number of extra output files that lang_specific_pre_link may generate.  */
>  int lang_specific_extra_outfiles = 0;  /* Not used for C.  */
> +
> +/* lang_register_spec_functions.  Not used for C.  */
> +void
> +lang_register_spec_functions (void)
> +{
> +}
> diff -x '*autom4te*' -rwu gcc/gcc/c-family/cppspec.cc 
> gcc-git-devel-modula2/gcc/c-family/cppspec.cc
> --- gcc/gcc/c-family/cppspec.cc 2022-05-17 11:20:57.911969653 +0100
> +++ gcc-git-devel-modula2/gcc/c-family/cppspec.cc 

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

[Richard Biener via Gcc-patches]

On Fri, May 20, 2022 at 10:17 AM Alexander Monakov  wrote:
>
> On Fri, 20 May 2022, Richard Biener wrote:
>
> > On Fri, May 20, 2022 at 8:38 AM Alexander Monakov  
> > wrote:
> > >
> > > On Fri, 20 May 2022, Richard Biener via Gcc-patches wrote:
> > >
> > > > > Still waiting for a suggestion, since "side effect" is the description
> > > > > that made sense to me :-)
> > > >
> > > > I think side-effect captures it quite well even if it overlaps with a 
> > > > term
> > > > used in language standards.  Doing c = a << b has the side-effect on
> > > > imposing a range on 'b' rather than just affecting 'c' (and its range).
> > > > You could call it 'alternate effect' but that sounds just awkward ;)
> > >
> > > I suggest 'deduce', 'deduction', 'deducing a range'. What the code is 
> > > actually
> > > doing is deducing that 'b' in 'a / b' cannot be zero. Function in GCC 
> > > might be
> > > called like 'deduce_ranges_from_stmt'.
> >
> > So how would you call determining the range of 'c' from the ranges of
> > 'a' and 'b', isn't that 'deduction' as well?
>
> Kind of, yes, but for this sort of forward inference I imagine you're already
> using 'propagate [ranges through a stmt]', like in 'value range propagation'.
>
> If you'd like to avoid 'propagate'/'deduce' asymmetry, I could suggest
> 'forward inference' / 'backward inference', but I like it a bit less.

Hmm, maybe "guarantees" - if the stmt executed (without traps) then
it's guaranteed that the divisor isn't zero.  I've almost said 'assertions'
but then asserts also have separate meanings, not to mention ASSERT_EXPR
as currently used by the old-style VRP.

Richard.

>
> Alexander

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

[Alexandre Oliva via Gcc-patches]

On May 18, 2022, Andrew MacLeod via Gcc-patches  wrote:

> I'm open to suggestions for a better term!

How about inference?

-- 
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 

[PATCH] Modula-2: merge proposal/review: 8/9 08.patch-set-06 v2

[Gaius Mulley via Gcc-patches]

Hello,

for completeness here is v2 of the patch set:

   (m2pp.c has been renamed m2pp.cc and a missing dependency added to
   m2rte).

6.  gcc/m2/Make-lang.in
==

-
New file: gcc/m2/Make-lang.in
-
# Top level -*- makefile -*- fragment for GNU M2.

# Copyright (C) 2000-2022 Free Software Foundation, Inc.

#This file is part of GCC.

#GCC is free software; you can redistribute it and/or modify
#it under the terms of the GNU General Public License as published by
#the Free Software Foundation; either version 3, or (at your option)
#any later version.

#GCC is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#GNU General Public License for more details.

#You should have received a copy of the GNU General Public License
#along with GCC; see the file COPYING3.  If not see
#.

# QUIAT=@
GM2_MAKE_DEBUG=

# Actual names to use when installing a native compiler.
GM2_INSTALL_NAME = $(shell echo gm2|sed '$(program_transform_name)')
GM2_TARGET_INSTALL_NAME = $(target_noncanonical)-$(shell echo gm2|sed 
'$(program_transform_name)')

# Actual names to use when installing a cross-compiler.
GM2_CROSS_NAME = `echo gm2|sed '$(program_transform_cross_name)'`

GM2_1 = ./gm2 -B./stage1/m2 -g -fm2-g
XGCC = ./xgcc -B./
GM2_2 = ./gm2 -B./stage2/m2 -g -fm2-g
CFLAGS=-g   ## remove this
LDLAGS=-g   ## remove this

# Define the name of target independent tools to be installed in $(bindir)
# Names are subject to change

# The tools directly available to the user are built in gm2tools, gm2m is
# an internal tool and therefore built here.

GM2_LINK_TOOLS_INSTALL =
# GM2_LINK_TOOLS_INSTALL = gm2m$(exeext) #  gm2m is not installed as it is 
under development.

GM2_LINK_TOOLS = gm2m$(exeext) gm2l$(exeext) gm2lcc$(exeext) \
 gm2lgen$(exeext) gm2lorder$(exeext)

GM2_LINK_TOOLS_BOOT = stage1/m2/gm2lcc$(exeext) stage1/m2/gm2l$(exeext) \
  stage1/m2/gm2lgen$(exeext) stage1/m2/gm2lorder$(exeext)

ifeq ($(CC1ONLY),yes)
GCC_TOOLS_FOR_GM2 = \
$(GCC_PASSES) $(GCC_PARTS) \
stage1/m2/gcc$(exeext) \
stage1/m2/cc1$(exeext) \
stage1/m2/cpp$(exeext)
else
GCC_TOOLS_FOR_GM2 = \
$(GCC_PASSES) $(GCC_PARTS) \
stage1/m2/gcc$(exeext) \
stage1/m2/cc1$(exeext) \
stage1/m2/cc1plus$(exeext) \
stage1/m2/cpp$(exeext)
endif

CPP_GM2=-fpermissive -DIN_GCC -g

TEXISRC = $(objdir)/m2/images/gnu.eps \
  $(srcdir)/doc/gm2.texi \
  m2/gm2-libs.texi \
  m2/gm2-ebnf.texi \
  m2/SYSTEM-pim.texi \
  m2/SYSTEM-iso.texi \
  m2/Builtins.texi \
  m2/version.texi


# Define the names for selecting GNU Modula-2 in LANGUAGES.
m2 modula-2 modula2: gm2$(exeext) xgcc$(exeext) cc1gm2$(exeext) \
 $(GCC_TOOLS_FOR_GM2)
m2.serial = cc1gm2$(exeext)

# Tell GNU make to ignore these if they exist.
.PHONY: m2 modula-2 modula2

GM2_PROG_DEP=gm2$(exeext) xgcc$(exeext) cc1gm2$(exeext)

TEXI2HTML=python3 $(srcdir)/m2/www/tools/texi2tr/src/texi2tr.py

include m2/config-make
LIBSTDCXX=../$(TARGET_SUBDIR)/libstdc++-v3/src/.libs/libstdc++.a

SRC_PREFIX=G

m2/gm2spec.o: $(srcdir)/m2/gm2spec.cc $(SYSTEM_H) $(GCC_H) $(CONFIG_H) \
   m2/gm2config.h $(TARGET_H) $(PLUGIN_HEADERS) \
   $(generated_files) $(C_TREE_H)
(SHLIB_LINK='$(SHLIB_LINK)' \
SHLIB_MULTILIB='$(SHLIB_MULTILIB)'; \
$(COMPILER) $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
 $(DRIVER_DEFINES) \
-DLIBSUBDIR=\"$(libsubdir)\" \
-DPREFIX=\"$(prefix)\" \
-c $(srcdir)/m2/gm2spec.cc $(OUTPUT_OPTION))

m2/gm2version.c: gm2version-check; @true

gm2version-check:
$(SHELL) $(srcdir)/m2/tools-src/makeversion -p $(srcdir) m2
$(STAMP) gm2version-check

gm2version.o: m2/gm2version.c
(SHLIB_LINK='$(SHLIB_LINK)' \
SHLIB_MULTILIB='$(SHLIB_MULTILIB)'; \
$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(DRIVER_DEFINES) \
-DLIBSUBDIR=\"$(libsubdir)\" \
$(INCLUDES) m2/gm2version.c $(OUTPUT_OPTION))

# Create the compiler driver for M2.
CFLAGS-m2/m2/gm2spec.o += $(DRIVER_DEFINES)

GM2_OBJS = $(GCC_OBJS) m2/gm2version.o \
prefix.o intl.o m2/gm2spec.o

# Create the compiler driver for gm2.
gm2$(exeext): $(GM2_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a $(LIBDEPS) \
m2/gm2config.h
+$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
  $(GM2_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a \
  $(EXTRA_GCC_LIBS) $(LIBS)

# Create a version of the gm2 driver which calls the cross-compiler.
gm2-cross$(exeext): gm2$(exeext)
-rm -f gm2-cross$(exeext)
cp gm2$(exeext) gm2-cross$(exeext)

po-ge

Re: [PATCH] configure: add --disable-fix-includes

[Alexandre Oliva via Gcc-patches]

On May 11, 2022, Martin Liška  wrote:

> Ready to be installed?

Hmm...  I don't like that --disable-fixincludes would still configure,
build and even install fixincludes.  This would be surprising, given
that the semantics of disabling a component is to not even configure it.

How about leaving the top-level alone, and changing gcc/configure.ac to
clear STMP_FIXINC when --disable-fixincludes is given?

-- 
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: [PATCH] gdc 9, 10 and 11 bug fix

[Iain Buclaw via Gcc-patches]

Excerpts from Marc Aurèle La France's message of Mai 20, 2022 6:56 am:
> On Tue, 17 May 2022, Marc Aurèle La France wrote:
>> On Tue, 17 May 2022, Iain Buclaw wrote:
>>> Excerpts from Marc Aurèle La France's message of Mai 17, 2022 5:31 pm:
 On Tue, 17 May 2022, Iain Buclaw wrote:
> Excerpts from Marc Aurèle La France's message of Mai 16, 2022 11:34 pm:
>> On Sun, 15 May 2022, Iain Buclaw wrote:
>>> Excerpts from Marc Aurèle La France's message of Mai 12, 2022 10:29 pm:
> 
 No compiler has any business rejecting files for the sole crime of
 being symlinked to.  The following applies, modulo patch fuzz, to the
 9, 10 and 11 series of compilers.
> 
 Given my use of shadow trees, this bug attempted to prevent me from
 building 12.1.0.  The D-based gdc in 12.1.0 and up does not exhibit
 this quirky behaviour.
> 
>>> Thanks, I've checked upstream and see the following change:
> 
>>> https://github.com/dlang/dmd/pull/11836/commits/ebda81e44fd0ca4b247a1860d9bef411c41c16cb
> 
>>> It should be fine to just backport that.
> 
>> Thanks for the pointer.
> 
>> I ended up with the three slightly different diffs below, one each for
>> the 9, 10 and 11 branches.  Each was rebuilt using 8.5.0, then used to
>> rebuild 12.1.0.  All of this ran smoothly without complaint, although I
>> wouldn't want to do this on a 486...
> 
>> Signed-off-by: Marc Aurèle La France 
> 
>> For GCC 9   --  8< --
>> 
>> diff -aNpRruz -X /etc/diff.excludes gcc-9.4.0/gcc/d/dmd/root/filename.c 
>> devel-9.4.0/gcc/d/dmd/root/filename.c
>> --- gcc-9.4.0/gcc/d/dmd/root/filename.c  2021-06-01 01:53:04.716474774 
>> -0600
>> +++ devel-9.4.0/gcc/d/dmd/root/filename.c2022-05-15 
>> 15:02:49.995441507 
>> -0600
>> @@ -475,53 +475,7 @@ const char *FileName::safeSearchPath(Strings *path, 
>> const char *name)
>>
>>  return FileName::searchPath(path, name, false);
>>  #elif POSIX
>> -/* Even with realpath(), we must check for // and disallow it
>> - */
>> -for (const char *p = name; *p; p++)
>> -{
>> -char c = *p;
>> -if (c == '/' && p[1] == '/')
>> -{
>> -return NULL;
>> -}
>> -}
> 
> I'd keep this check in, otherwise removing/replacing only the `if
> (path)` branch looks OK to me.
> 
 The corresponding D code doesn't care about double slashes and neither
 should this.  Also, the comment is misleading as realpath() would no
 longer be used here.
> 
>>> True, but the D front-end does check the path in other places now:
> 
>>> https://github.com/dlang/dmd/blob/e9ba29d71b557fe079e95ee6554f116b24159bab/src/dmd/root/filename.d#L787-L803
> 
>>> https://github.com/dlang/dmd/blob/e9ba29d71b557fe079e95ee6554f116b24159bab/src/dmd/expressionsem.d#L5984-L6007
> 
>>> If we remove all checks, then there'd be nothing to prevent either
>>> import("/file") or import("../file") from being used.
> 
>> There is still no check for double slashes.  All I want here is to fix a C++ 
>> -> D migration bug without leaving any detritus behind.
> 
> Anything more on this?
> 

My concern is that given:

pragma(msg, import("/etc/fstab"));
pragma(msg, import("../../../../../../etc/fstab"));

This will result in errors with both `gdc-11 -J.` and `gdc-12 -J.`

gdc-11:
---
error: file "/etc/fstab" cannot be found or not in a path specified with -J
1 | pragma(msg, import("/etc/fstab"));
  | ^
error: file "../../../../../../etc/fstab" cannot be found or not in a path 
specified with -J
2 | pragma(msg, import("../../../../../../etc/fstab"));
  | ^
---

gdc-12:
---
error: absolute path is not allowed in import expression: ‘"/etc/fstab"’
1 | pragma(msg, import("/etc/fstab"));
  | ^
error: path refers to parent (‘..’) directory: ‘"../../../../../../etc/fstab"’
2 | pragma(msg, import("../../../../../../etc/fstab"));
  | ^
absimport.d:2:1: note: while evaluat
---

With just this change alone, that means both forms will be permitted.
If we're going to fix how searchPath checks imports, might as well move
in the direction of the v2.100 behaviour in gdc-12, and include a couple
checks for absolute paths and `..` in the string.

Regards,
Iain.

Re: [PATCH 1/8] Move FINAL and OVERRIDE from ansidecl.h to gcc-plugin.h

[David Malcolm via Gcc-patches]

On Thu, 2022-05-19 at 14:45 +0200, Richard Biener wrote:
> On Thu, May 19, 2022 at 2:43 PM David Malcolm via Gcc-patches
>  wrote:
> > 
> > On Thu, 2022-05-19 at 08:32 -0400, David Malcolm wrote:
> > > As of GCC 11 onwards we have required a C++11 compiler, such as
> > > GCC
> > > 4.8
> > > or later.  On the assumption that any such compiler correctly
> > > implements
> > > "final" and "override", this patch removes the FINAL and OVERRIDE
> > > macros
> > > from ansidecl.h.  It adds them back to gcc-plugins.h in case any
> > > plugins
> > > make use of them.
> > > 
> > > Followup patches within this kit replace all uses of the macros
> > > in
> > > the
> > > tree with the lower-case versions; I've split them up for ease of
> > > review, but would apply them as one combined commit if approved.
> > 
> > I forgot to say:
> > I've successfully bootstrapped & regrtested the combined patches on
> > x86_64-pc-linux-gnu, and (very) lightly tested them on aarch64-
> > linux-
> > gnu.
> 
> And I forgot to say - the patches doing the replacement are fine en-
> bloc

Thanks.  I merged those parts of the kit (patches 2-8, replacing the
macros uses with the lower-case specifiers directly) into one patch,
retested with just that, and have pushed it to trunk as r13-690-
gff171cb13df671.  I plan to look at the libiberty discussion early next
week.

Dave

> 
> Thanks,
> Richard.
> 
> > Dave
> > 
> > > 
> > > gcc/ChangeLog:
> > >     * gcc-plugin.h: Add macros OVERRIDE and FINAL.
> > > 
> > > include/ChangeLog:
> > >     * ansidecl.h: Drop macros OVERRIDE and FINAL.
> > > 
> > > Signed-off-by: David Malcolm 
> > > ---
> > >  gcc/gcc-plugin.h   |  7 +++
> > >  include/ansidecl.h | 41 
> > > -
> > >  2 files changed, 7 insertions(+), 41 deletions(-)
> > > 
> > > diff --git a/gcc/gcc-plugin.h b/gcc/gcc-plugin.h
> > > index ee9aa865114..f0f3049d0ce 100644
> > > --- a/gcc/gcc-plugin.h
> > > +++ b/gcc/gcc-plugin.h
> > > @@ -44,4 +44,11 @@ along with GCC; see the file COPYING3.  If not
> > > see
> > >  #include "tree-check.h"
> > >  #include "plugin.h"
> > > 
> > > +/* Versions of GCC prior to GCC 13 defined these macros in
> > > ansidecl.h
> > > +   for C++98 compatibility.  Given that we require C++11 from
> > > GCC 11
> > > onwards,
> > > +   keep definitions here in case plugins made use of them.  */
> > > +
> > > +#define OVERRIDE override
> > > +#define FINAL    final
> > > +
> > >  #endif /* GCC_PLUGIN_H */
> > > diff --git a/include/ansidecl.h b/include/ansidecl.h
> > > index efee5b6904b..119748deb68 100644
> > > --- a/include/ansidecl.h
> > > +++ b/include/ansidecl.h
> > > @@ -345,47 +345,6 @@ So instead we use the macro below and test
> > > it
> > > against specific values.  */
> > >  #define CONSTEXPR
> > >  #endif
> > > 
> > > -/* C++11 adds the ability to add "override" after an
> > > implementation
> > > of a
> > > -   virtual function in a subclass, to:
> > > - (A) document that this is an override of a virtual function
> > > - (B) allow the compiler to issue a warning if it isn't (e.g.
> > > a
> > > mismatch
> > > - of the type signature).
> > > -
> > > -   Similarly, it allows us to add a "final" to indicate that no
> > > subclass
> > > -   may subsequently override the vfunc.
> > > -
> > > -   Provide OVERRIDE and FINAL as macros, allowing us to get
> > > these
> > > benefits
> > > -   when compiling with C++11 support, but without requiring
> > > C++11.
> > > -
> > > -   For gcc, use "-std=c++11" to enable C++11 support; gcc 6
> > > onwards
> > > enables
> > > -   this by default (actually GNU++14).  */
> > > -
> > > -#if defined __cplusplus
> > > -# if __cplusplus >= 201103
> > > -   /* C++11 claims to be available: use it.  Final/override were
> > > only
> > > -  implemented in 4.7, though.  */
> > > -#  if GCC_VERSION < 4007
> > > -#   define OVERRIDE
> > > -#   define FINAL
> > > -#  else
> > > -#   define OVERRIDE override
> > > -#   define FINAL final
> > > -#  endif
> > > -# elif GCC_VERSION >= 4007
> > > -   /* G++ 4.7 supports __final in C++98.  */
> > > -#  define OVERRIDE
> > > -#  define FINAL __final
> > > -# else
> > > -   /* No C++11 support; leave the macros empty.  */
> > > -#  define OVERRIDE
> > > -#  define FINAL
> > > -# endif
> > > -#else
> > > -  /* No C++11 support; leave the macros empty.  */
> > > -# define OVERRIDE
> > > -# define FINAL
> > > -#endif
> > > -
> > >  /* A macro to disable the copy constructor and assignment
> > > operator.
> > >     When building with C++11 and above, the methods are
> > > explicitly
> > >     deleted, causing a compile-time error if something tries to
> > > copy.
> > 
> > 
> 

Re: [PATCH] libstdc++-v3: Set 26_numerics/random/n.b.d./op./values.cc timeout-factor to 3

[Hans-Peter Nilsson via Gcc-patches]

> From: Jonathan Wakely 
> Date: Fri, 20 May 2022 11:03:40 +0200

> > Ok to commit (without renaming)?
> 
> I'm OK with the timeout factor, but we could also solve it differently
> so that it doesn't take nearly 5 minutes, as in the attached patch.
> The testDiscreteDist function can be parametrized with the number of
> iterations to perform. Would you rather do that?

Yes thanks, down from 4m39s to 2.7 seconds, so very much
preferable!

(To the skeptics: the coverage intended with the test, is
IMHO reached with all non-simulator targets also running
this.  Nothing target-dependent here.)

Also in line with many other depth-level-cousin test-files
named value.cc.  Still many more others seem to be
candidates for such pruning, judging by the time it takes
for a 'RUNTESTFLAGS=--target_board=cris-sim\
conformance.exp=values.cc' to get to *that* values.cc.

Though, some -DSIMULATOR_TEST-adjusted files use dg-options,
others dg-additional-options.  It seems the difference is
that by using dg-options, you lose "-include bits/stdc++.h".
Likely not intended.  If so, should Someone fix that by
preapproval but regtested?

brgds, H-P

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

[Segher Boessenkool]

On Fri, May 20, 2022 at 10:11:32AM +0200, Eric Botcazou wrote:
> > I suggest 'deduce', 'deduction', 'deducing a range'. What the code is
> > actually doing is deducing that 'b' in 'a / b' cannot be zero. Function in
> > GCC might be called like 'deduce_ranges_from_stmt'.
> 
> Or "infer", "inference", "inferring a range".

"Infer" is great here, yes!

infer (verb):
  deduce or conclude (something) from evidence and reasoning rather than
  from explicit statements

It has exactly the connotation wanted here, I would say.


Segher

Re: [PATCH] libstdc++-v3: Set 26_numerics/random/n.b.d./op./values.cc timeout-factor to 3

[Jonathan Wakely via Gcc-patches]

On Fri, 20 May 2022 at 15:31, Hans-Peter Nilsson wrote:
>
> > From: Jonathan Wakely 
> > Date: Fri, 20 May 2022 11:03:40 +0200
>
> > > Ok to commit (without renaming)?
> >
> > I'm OK with the timeout factor, but we could also solve it differently
> > so that it doesn't take nearly 5 minutes, as in the attached patch.
> > The testDiscreteDist function can be parametrized with the number of
> > iterations to perform. Would you rather do that?
>
> Yes thanks, down from 4m39s to 2.7 seconds, so very much
> preferable!

Nice, thanks for testing it.

> (To the skeptics: the coverage intended with the test, is
> IMHO reached with all non-simulator targets also running
> this.  Nothing target-dependent here.)

Indeed.

> Also in line with many other depth-level-cousin test-files
> named value.cc.  Still many more others seem to be
> candidates for such pruning, judging by the time it takes
> for a 'RUNTESTFLAGS=--target_board=cris-sim\
> conformance.exp=values.cc' to get to *that* values.cc.
>
> Though, some -DSIMULATOR_TEST-adjusted files use dg-options,
> others dg-additional-options.  It seems the difference is
> that by using dg-options, you lose "-include bits/stdc++.h".
> Likely not intended.  If so, should Someone fix that by
> preapproval but regtested?

Ah good point. I've pushed the attached patch now. This adjusts the
values.cc files for some other distributions, and does so using
dg-additional-options not dg-options. Feel free to change existing
(mis)uses of dg-options to be dg-additional-options.

I've tested it on x86_64-linux, normally and also with
-DSIMULATOR_TEST in the test flags, just to ensure I didn't introduce
a silly syntax error for that case. I haven't tested it on a real sim
though.
commit e3b8b4f7814c54543d9b7ea3ee8cf2cb9cff351d
Author: Jonathan Wakely 
Date:   Fri May 20 15:44:25 2022

libstdc++: Reduce  test iterations for simulators

Some of these tests take several minutes on a simulator like cris-elf,
so we can conditionally run fewer iterations. The testDiscreteDist
helper already supports custom sizes so we just need to make use of that
when { target simulator } matches.

The relevant code is sufficiently tested on other targets, so we're not
losing anything by only running a small number of iterators for sims.

libstdc++-v3/ChangeLog:

* 
testsuite/26_numerics/random/bernoulli_distribution/operators/values.cc:
Run fewer iterations for simulator targets.
* 
testsuite/26_numerics/random/binomial_distribution/operators/values.cc:
Likewise.
* 
testsuite/26_numerics/random/discrete_distribution/operators/values.cc:
Likewise.
* 
testsuite/26_numerics/random/geometric_distribution/operators/values.cc:
Likewise.
* 
testsuite/26_numerics/random/negative_binomial_distribution/operators/values.cc:
Likewise.
* 
testsuite/26_numerics/random/poisson_distribution/operators/values.cc:
Likewise.
* 
testsuite/26_numerics/random/uniform_int_distribution/operators/values.cc:
Likewise.

diff --git 
a/libstdc++-v3/testsuite/26_numerics/random/bernoulli_distribution/operators/values.cc
 
b/libstdc++-v3/testsuite/26_numerics/random/bernoulli_distribution/operators/values.cc
index 4100692981c..b2cb86f976b 100644
--- 
a/libstdc++-v3/testsuite/26_numerics/random/bernoulli_distribution/operators/values.cc
+++ 
b/libstdc++-v3/testsuite/26_numerics/random/bernoulli_distribution/operators/values.cc
@@ -24,6 +24,14 @@
 #include 
 #include 
 
+// { dg-additional-options "-DSIMULATOR_TEST" { target simulator } }
+
+#ifdef SIMULATOR_TEST
+# define ARGS 100, 1000
+#else
+# define ARGS
+#endif
+
 void test01()
 {
   using namespace __gnu_test;
@@ -32,15 +40,15 @@ void test01()
 
   std::bernoulli_distribution bd1(0.25);
   auto bbd1 = std::bind(bd1, eng);
-  testDiscreteDist(bbd1, [](int n) { return bernoulli_pdf(n, 0.25); } );
+  testDiscreteDist(bbd1, [](int n) { return bernoulli_pdf(n, 0.25); } );
 
   std::bernoulli_distribution bd2(0.5);
   auto bbd2 = std::bind(bd2, eng);
-  testDiscreteDist(bbd2, [](int n) { return bernoulli_pdf(n, 0.5); } );
+  testDiscreteDist(bbd2, [](int n) { return bernoulli_pdf(n, 0.5); } );
 
   std::bernoulli_distribution bd3(0.75);
   auto bbd3 = std::bind(bd3, eng);
-  testDiscreteDist(bbd3, [](int n) { return bernoulli_pdf(n, 0.75); } );
+  testDiscreteDist(bbd3, [](int n) { return bernoulli_pdf(n, 0.75); } );
 }
 
 int main()
diff --git 
a/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc
 
b/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc
index 96570d59fb3..efa259b7e03 100644
--- 
a/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc
+++ 
b/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc
@@ -25,6 +25,14 @@
 #include 
 #include 
 
+

RE: [x86 PATCH] Some additional ix86_rtx_costs clean-ups: NEG, AND and pandn.

[Roger Sayle]

Hi Uros,
Many thanks for the review.  As requested here is a revised version of the
patch that's slightly more aggressive in its clean-ups (duplicating 6 lines
of code allowed me to eliminate 9 lines of code), but most significantly
also includes support for the andn for TARGET_BMI, and allows the NOT
operand of andn/pandn to appear as either the first or second operand
(combine/reload/output will swap them as appropriate).

Once again this patch has been tested on x86_64-pc-linux-gnu with 
make bootstrap and make -k check, with and without -m32, with no
new failures.  Ok for mainline?

2022-05-20  Roger Sayle  

gcc/ChangeLog
* config/i386/i386.cc (ix86_rtx_costs): Split AND from XOR/IOR.
Multi-word binary logic operations require two instructions.
For vector integer modes, AND with a NOT operand requires only
a single instruction (pandn).  Likewise, integer andn with -mbmi.
[NOT]: Vector integer NOT requires more than 1 instruction (pxor).
[NEG]: Multi-word negation requires 3 instructions.


Thanks in advance,
Roger

> -Original Message-
> From: Uros Bizjak 
> Sent: 19 May 2022 07:29
> To: Roger Sayle 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [x86 PATCH] Some additional ix86_rtx_costs clean-ups: NEG, AND
> and pandn.
> 
> On Wed, May 18, 2022 at 7:30 PM Roger Sayle
>  wrote:
> >
> >
> > Hi Uros,
> > Very many thanks for the speedy review and approval of my
> > ix86_rtx_costs patch to correct the cost of multi-word
> > multiplications.  In the same spirit, this patch tidies up a few additional 
> > nits I
> noticed while there:
> > Multi-word NOT requires two operations, but multi-word NEG requires
> > three operations.  Using SSE, vector NOT requires a pxor with -1, but
> > AND of NOT is cheap thanks to the existence of pandn.  There's also
> > some legacy (aka incorrect) logic explicitly testing for DImode
> > [independently of TARGET_64BIT] in determining the cost of logic
> > operations that's not required.
> >
> > There should be no behavioural changes from this patch (as confirmed
> > by
> > testing) but hopefully vectorization and other middle-end passes can
> > now rely on more sensible "cost" estimates.
> >
> > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> > and make -k check, both with and without --target_board=unix{-m32},
> > with no new failures.  Ok for mainline?
> >
> >
> > 2022-05-18  Roger Sayle  
> >
> > gcc/ChangeLog
> > * config/i386/i386.cc (ix86_rtx_costs): Split AND from XOR/IOR.
> > Multi-word binary logic operations require two instructions.
> > For vector integer modes, AND with a NOT operand requires only
> > a single instruction (pandn).
> > [NOT]: Vector integer NOT requires more than 1 instruction (pxor).
> > [NEG]: Multi-word negation requires 3 instructions.
> 
> -case AND:
>  case IOR:
>  case XOR:
>if (GET_MODE_CLASS (mode) == MODE_INT
>&& GET_MODE_SIZE (mode) > UNITS_PER_WORD)
>  {
> -  *total = (cost->add * 2
> -+ (rtx_cost (XEXP (x, 0), mode, outer_code, opno, speed)
> -   << (GET_MODE (XEXP (x, 0)) != DImode))
> -+ (rtx_cost (XEXP (x, 1), mode, outer_code, opno, speed)
> -   << (GET_MODE (XEXP (x, 1)) != DImode)));
> +  *total = cost->add * 2
> +   + rtx_cost (XEXP (x, 0), mode, outer_code, opno, speed)
> +   + rtx_cost (XEXP (x, 1), mode, outer_code, opno, speed);
> +  return true;
> +}
> +  else if (GET_MODE_CLASS (mode) == MODE_VECTOR_INT)
> +*total = ix86_vec_cost (mode, cost->sse_op);
> +  else if (GET_MODE_SIZE (mode) > UNITS_PER_WORD)
> +*total = cost->add * 2;
> +  else
> +*total = cost->add;
> +  return false;
> 
> Shouldn't this be just:
> 
> if (GET_MODE_CLASS (mode) == MODE_VECTOR_INT)
>   *total = ix86_vec_cost (mode, cost->sse_op); else if (GET_MODE_SIZE (mode)
> > UNITS_PER_WORD)
>   *total = cost->add * 2;
> else
>   *total = cost->add;
> return false;
> 
> When returning false, subexpressions will be scanned automatically.
> 
> +  else if (GET_MODE_CLASS (mode) == MODE_VECTOR_INT)
> +{
> +  /* pandn is a single instruction.  */
> +  if (GET_CODE (XEXP (x, 0)) == NOT)
> 
> pandn is also a single instruction with BMI.  IMO, this should be also 
> reflected in
> RTX costs.
> 
> Uros.
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 30a9cd0..daa60ac 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -20738,70 +20738,125 @@ ix86_rtx_costs (rtx x, machine_mode mode, int 
outer_code_i, int opno,
}
 
   if (SSE_FLOAT_MODE_SSEMATH_OR_HF_P (mode))
-   {
- *total = cost->addss;
- return false;
-   }
+   *total = cost->addss;
   else if (X87_FLOAT_MODE_P (mode))
-   {
- *total = cost->fadd;
- return false;
-   }
+   *total = cost->fadd;
   else if (FLOAT_MODE_

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

[Gaius Mulley via Gcc-patches]

Richard Biener  writes:

> On Wed, May 18, 2022 at 3:47 PM Gaius Mulley via Gcc-patches
>  wrote:
>>
>> hello,
>>
>> this file is part-01 of the patch set for the gm2 review.

Hi Richard,

> I think you did a better job last time splitting the patches.

ah many apologies I should have annotated the diff and not split across
strict diffs and new file contents boundaries.  I should have included
gm2spec.cc in this patch set (rather than in 07.patch-set-05).

> This one contains the driver changes for which I have a hard time
> remembering the reason they exist and whether we already discussed it
> to death or not.

the changes do raise questions.  The reason for the changes here are to
allow easy linking for modula-2 users.

  $ gm2 hello.mod

for example will compile and link with all dependent modules (dependants
are generated by analysing module source imports).  The gm2 driver will
add objects and libraries to the link.

> So - with the chance to re-open and old discussion - what's special
> about modula-2 so it needs so many changes here?

Sure, the difference with modula-2 is that upon link it will generate a
scaffold program, compile the application module, compile scaffold and
link both in with all application dependants producing the final
executable.  It also needs the ability to insert include paths and link
paths for the appropriate dialect of modula-2 (although this causes
fewer changes).

But I take your point.  Perhaps it is better that gm2 follows say the C
approach of just compile a module?  Linking could be done using normal
link tools - (plus a few gm2tools for generating scaffold and finding
libraries etc).  Or a different approach?

One option is for me to rewrite the linking if required - I see merit -
not least the changes would have significantly less impact on the code
base.

> Are all of them necessary or are most of them merely "cleanups" that
> could be done as followup?

A few cleanups occurred when wishing to provide external access to the
routines.  For example the handle_opt_b function tidied up the OPT_B
case clause and also allowed gm2 to call fe_handle_opt_b but this could
certainly be done as a followup.

> Thanks,
> Richard.

For clarity here is the gm2spec.cc file from (07.patch-set-05):

regards,
Gaius


/* gm2spec.cc specific flags and argument handling within GNU Modula-2.

Copyright (C) 2007-2022 Free Software Foundation, Inc.
Contributed by Gaius Mulley .

This file is part of GNU Modula-2.

GNU Modula-2 is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3, or (at your option)
any later version.

GNU Modula-2 is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License for more details.

You should have received a copy of the GNU General Public License
along with GNU Modula-2; see the file COPYING3.  If not see
.  */

#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "tm.h"
#include "xregex.h"
#include "obstack.h"
#include "intl.h"
#include "prefix.h"
#include "opt-suggestions.h"
#include "gcc.h"
#include "opts.h"
#include "vec.h"

#include "m2/gm2version.h"
#include "m2/gm2config.h"

#ifdef HAVE_DIRENT_H
#include 
#else
#ifdef HAVE_SYS_NDIR_H
#include 
#endif
#ifdef HAVE_SYS_DIR_H
#include 
#endif
#ifdef HAVE_NDIR_H
#include 
#endif
#endif

#ifndef MATH_LIBRARY
#define MATH_LIBRARY "m"
#endif

#ifndef LIBSTDCXX
#define LIBSTDCXX "stdc++"
#endif

#ifndef DIR_SEPARATOR
#define DIR_SEPARATOR '/'
#endif

/* Most every one is fine with LIBRARY_PATH.  For some, it conflicts.  */
#ifndef LIBRARY_PATH_ENV
#define LIBRARY_PATH_ENV "LIBRARY_PATH"
#endif

#ifndef GM2_PREFIX_ENV
#define GM2_PREFIX_ENV "GM2_PREFIX"
#endif

#ifndef GM2_LIBEXEC_ENV
#define GM2_LIBEXEC_ENV "GM2_LIBEXEC"
#endif

#ifndef GM2IPATH_ENV
#define GM2IPATH_ENV "GM2IPATH"
#endif

#ifndef GM2OPATH_ENV
#define GM2OPATH_ENV "GM2OPATH"
#endif

int lang_specific_extra_outfiles = 0;

/* DEBUGGING will print all the options at various stages with their
   error code, full name etc.  */
#undef DEBUGGING

/* LOCAL_DEBUGGING allows the compiler driver to automatically set a -B
   prefix (assuming one it not user supplied).  It sets the -Bprefix with
   the given path to argv[0].  This allows subprograms to be found in the
   build tree (without having to be installed).  It is only meant as an
   aid to development, not a user feature :-).  It allows developers to
   lazily type:  ./gm2 -c hello.c rather than ./gm2 -B./ -c hello.c
   or /somedirectory/development/build/gcc/gm2 -c hello.c.  */
#undef LOCAL_DEBUGGING

#define DEFAULT_DIALECT "pim"

typedef enum { iso, pim, min, logitech, pimcoroutine, maxlib } libs;

/* These are the library names which are installed as part of gm2 and reflect
   -flibs=name.  T

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

[Alexandre Oliva via Gcc-patches]

This patch introduces -multiflags, short for multilib TFLAGS, as an
option that does nothing by default, but that can be added to TFLAGS
and mapped to useful options by driver self-specs.

I realize -m is reserved for machine-specific flags, which this option
sort-of isn't, but its intended use is indeed to stand for
machine-specific flags, so it's kind of ok.  But that's just my
official excuse, the reason I couldn't help picking it up is that it
is a portmanteau of multi[lib] and TFLAGS.

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




Also tested with cross compilers configured to fail when missing
-multiflags, as suggested in the last paragraph in the added docs.

Tests to flag uses of the just-built compiler without -multiflags
required various workarounds.  Self-tests in GCC are compiled without
TFLAGS, so they'd fail if it weren't for a separate patchlet I'm
undecided about.  TFLAGS aren't used by gnattools or gotools either,
even when they are built with *_FOR_TARGET compilers, namely in native
builds, so those fail the above.  Another issue comes up when
bootstrapping: stages other than 1 use a just-built compiler to compile
for the target, in a way, but they don't use TFLAGS.

This brings about the philosophical/practical question of whether TFLAGS
is to apply to target libraries only, or to all compilations using the
just-built compiler, even those for host=target.  I can think of
arguments to support either choice.

I have changes that add TFLAGS for GCC self-tests, gnattools and gotools
(but not for bootstrap stages), and I'd be happy to proceed with them,
but I'd like to hear about any concerns or potential use cases for the
alternatives before proceeding with these changes.

Other possibilities that occurred to me were add a THFLAGS to the
top-level for host components that, in native builds, build with a
for-the-target just-built compiler (gnattools and gotools), or even get
the top level to pass _FOR_TARGET along with TFLAGS or THFLAGS
down as  to such host tools (and that or the previous stage's
TFLAGS when using the previous stage's compiler during bootstraps), like
it adds TFLAGS to  for target libs.




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.
---
 gcc/common.opt  |4 
 gcc/doc/invoke.texi |   30 +-
 gcc/gcc.cc  |6 +-
 gcc/opts.cc |4 
 4 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index 8a0dafc522d12..73b69ba3118e4 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1786,6 +1786,10 @@ fif-conversion2
 Common Var(flag_if_conversion2) Optimization
 Perform conversion of conditional jumps to conditional execution.
 
+multiflags
+Common Driver
+Building block for specs-based multilib-aware TFLAGS.
+
 fstack-reuse=
 Common Joined RejectNegative Enum(stack_reuse_level) Var(flag_stack_reuse) 
Init(SR_ALL) Optimization
 -fstack-reuse=[all|named_vars|none]Set stack reuse level for local 
variables.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 98a543ae06fda..0bd8d7b129612 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -727,7 +727,7 @@ Objective-C and Objective-C++ Dialects}.
 -fsel-sched-verbose  -fsel-sched-dump-cfg  -fsel-sched-pipelining-verbose @gol
 -fstats  -fstack-usage  -ftime-report  -ftime-report-details @gol
 -fvar-tracking-assignments-toggle  -gtoggle @gol
--print-file-name=@var{library}  -print-libgcc-file-name @gol
+-multiflags  -print-file-name=@var{library}  -print-libgcc-file-name @gol
 -print-multi-directory  -print-multi-lib  -print-multi-os-directory @gol
 -print-prog-name=@var{program}  -print-search-dirs  -Q @gol
 -print-sysroot  -print-sysroot-headers-suffix @gol
@@ -18870,6 +18870,34 @@ For example, with 
@option{-fdbg-cnt=dce:2-4:10-11,tail_call:10},
 eleventh invocation.
 For @code{dbg_cnt(tail_call)} true is returned for first 10 invocations.
 
+@item -multiflags
+@opindex multiflags
+This option enables multilib-aware @code{TFLAGS} to be used to build
+target libraries with options different from those the compiler is
+configured to use by default, through the use of specs (@xref{Spec
+Files}) set up by compiler internals, by the target, or by builders at
+configure time.
+
+Like @code{TFLAGS}, this allows the target libraries to be built for
+portable baseline environments, while the compiler defaults to more
+demanding ones.  That's useful because users can easily override the
+defaults the compiler is configured to use to build their own programs,
+if the defaults are not ideal for their target environment, whereas
+rebuilding the runtime libraries is usually not as easy or desirable.
+
+Unlike @code{TFLAGS}, the use of specs enables different flags to be
+selected for different multilibs.  The way to accomplish that is to
+build w

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

[Bernhard Reutner-Fischer via Gcc-patches]

On 20 May 2022 16:39:20 CEST, Segher Boessenkool  
wrote:
>On Fri, May 20, 2022 at 10:11:32AM +0200, Eric Botcazou wrote:
>> > I suggest 'deduce', 'deduction', 'deducing a range'. What the code is
>> > actually doing is deducing that 'b' in 'a / b' cannot be zero. Function in
>> > GCC might be called like 'deduce_ranges_from_stmt'.
>> 
>> Or "infer", "inference", "inferring a range".
>
>"Infer" is great here, yes!
>
>infer (verb):
>  deduce or conclude (something) from evidence and reasoning rather than
>  from explicit statements
>
>It has exactly the connotation wanted here, I would say.

Infer, deduct, refine
Sound all plausible, a native speaker should probably help decide the bikeshed 
:-)
thanks,

RE: [EXTERNAL] Re: [PATCH] Guard against applying scale with 0 denominator

[Eugene Rozenfeld via Gcc-patches]

Thank you for the feedback Richard. I attached a patch that saves/restores 
counts if the epilog doesn't use a scalar loop.

Eugene

-Original Message-
From: Richard Biener  
Sent: Thursday, May 12, 2022 12:34 AM
To: Eugene Rozenfeld 
Cc: Jan Hubicka ; gcc-patches@gcc.gnu.org
Subject: Re: [EXTERNAL] Re: [PATCH] Guard against applying scale with 0 
denominator

On Thu, May 12, 2022 at 3:37 AM Eugene Rozenfeld 
 wrote:
>
> In my case this is not exactly what the FIXME in the comment above 
> says. The count is 0 even before the initial scaling happens. I hit this case 
> with some changes I'm working on to enable per-instruction discriminators for 
> AutoFDO.
>
> I looked into saving/restoring the old counts but it would be awkward to do. 
> The initial scaling happens here:
>
> if (skip_vector)
> {
>   split_edge (loop_preheader_edge (loop));
>
>   /* Due to the order in which we peel prolog and epilog, we first
>  propagate probability to the whole loop.  The purpose is to
>  avoid adjusting probabilities of both prolog and vector loops
>  separately.  Note in this case, the probability of epilog loop
>  needs to be scaled back later.  */
>   basic_block bb_before_loop = loop_preheader_edge (loop)->src;
>   if (prob_vector.initialized_p ())
> {
>   scale_bbs_frequencies (&bb_before_loop, 1, prob_vector);
>   scale_loop_profile (loop, prob_vector, 0);
> }
> }
>
> The scaling happens before we do the cloning for the epilog so to 
> save/restore the counts we would need to maintain a mapping between the 
> original basic blocks and the cloned basic blocks in the epilog.

There is one already - after the epilogue is copied you can use get_bb_original 
(epilouge_bb) to get at the block it was copied from.
It could also be that we can rely on the basic-block order to be preserved 
between the copies (I _think_ that would work ... but then assert () for this 
using get_bb_original ()).  That means the simplest fix would be to have an 
auto_vec and initialize that from the BB counts in loop body order (we 
also have exactly two BBs in all peeled loops ...

But note we only scaled the scalar if-converted loop but eventually used the 
not if-coverted copy for the epilogue (if not vectorizing the epilogue), so 
indiscriminate scaling back looks wrong in some cases (I'd have to double-check 
the details here).

> I'd like to get my simple fix in since it makes things better even if 
> it doesn't address the issue mentioned In the FIXME.

But don't you need to check that
bbs[i]->count.apply_probability (prob_vector) is not zero instead of checking 
that bbs[i].count is not zero?

Richard.

> -Original Message-
> From: Richard Biener 
> Sent: Monday, May 09, 2022 12:42 AM
> To: Eugene Rozenfeld ; Jan Hubicka 
> 
> Cc: gcc-patches@gcc.gnu.org
> Subject: [EXTERNAL] Re: [PATCH] Guard against applying scale with 0 
> denominator
>
> On Fri, May 6, 2022 at 10:32 PM Eugene Rozenfeld via Gcc-patches 
>  wrote:
> >
> > Calling count.apply_scale with a 0 denominator causes an assert.
> > This change guards against that.
> >
> > Tested on x86_64-pc-linux-gnu.
> >
> > gcc/ChangeLog:
> > * tree-loop-vect-manip.cc (vect_do_peeling): Guard against applying 
> > scale with 0 denominator.
> > ---
> >  gcc/tree-vect-loop-manip.cc | 9 +
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/gcc/tree-vect-loop-manip.cc 
> > b/gcc/tree-vect-loop-manip.cc index 1d4337eb261..db54ae69e45 100644
> > --- a/gcc/tree-vect-loop-manip.cc
> > +++ b/gcc/tree-vect-loop-manip.cc
> > @@ -2989,10 +2989,11 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree 
> > niters, tree nitersm1,
> >  get lost if we scale down to 0.  */
> >   basic_block *bbs = get_loop_body (epilog);
> >   for (unsigned int i = 0; i < epilog->num_nodes; i++)
> > -   bbs[i]->count = bbs[i]->count.apply_scale
> > -(bbs[i]->count,
> > - bbs[i]->count.apply_probability
> > -   (prob_vector));
> > +   if (bbs[i]->count.nonzero_p ())
> > + bbs[i]->count = bbs[i]->count.apply_scale
> > +  (bbs[i]->count,
> > +   bbs[i]->count.apply_probability
> > + (prob_vector));
>
> So exactly what the FIXME in the comment above says happens.   It
> might be better
> to save/restore the old counts if the intent is to get them back.  I'm not 
> exactly sure where the other scaling happens though.
>
> Richard.
>
>
>
> >   free (bbs);
> > }
> >
> > --
> > 2.25.1


0001-Fix-profile-count-maintenance-in-vectorizer-peeling.patch
Description: 0001-Fix-profile-count-maintenance-in-vectorizer-peeling.patch

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

[Gaius Mulley via Gcc-patches]

Hi,

Gaius wrote:

> the changes do raise questions.  The reason for the changes here are to
> allow easy linking for modula-2 users.

>  $ gm2 hello.mod

> for example will compile and link with all dependent modules (dependants
> are generated by analysing module source imports).  The gm2 driver will
> add objects and libraries to the link.

in more detail the gm2 driver does the following:

  $ gm2 -v hello.mod

full output below, but to summarise and annotate:

cc1gm2 generates an assembler file from hello.mod
 as --64 /tmp/cc8BoL3d.s -o hello.o
 
 # gm2l generates a list of all dependent modules from parsing all imports
 /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/gm2l -v \
 -I/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim -o \
 /tmp/ccSMojUb.l hello.mod

 # gm2lorder reorders the critical runtime modules
 /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/gm2lorder \
/tmp/ccSMojUb.l -o /tmp/ccHDRdde.lst

 # gm2lgen generates a C++ scaffold from the reordered module list
 /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/gm2lgen -fcpp \
/tmp/ccHDRdde.lst -o a-hello_m2.cpp

 # cc1plus compiles the scaffold
 /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/cc1plus -v \
 -mtune=generic -march=x86-64 \
 -I/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim \
 -quiet a-hello_m2.cpp -o a-hello_m2.s
 as --64 a-hello_m2.s -o a-hello_m2.o

 # gm2lcc creates an archive from the list of modules and the scaffold
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/gm2lcc \
  -L/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim \
  -ftarget-ar=/usr/bin/ar -ftarget-ranlib=/usr/bin/ranlib \
-fobject-path=/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim \
  --exec --startup a-hello_m2.o --ar -o /tmp/ccNJ60fa.a --mainobject \
  a-hello_m2.o /tmp/ccHDRdde.lst

/usr/bin/ar rc /tmp/ccNJ60fa.a  hello.o a-hello_m2.o
/usr/bin/ranlib /tmp/ccNJ60fa.a

# finally collect2 performs the link from the archive and any default
  libraries

hope this helps

regards,
Gaius






$ ~/opt/bin/gm2 -v hello.mod
Using built-in specs.
COLLECT_GCC=/home/gaius/opt/bin/gm2
COLLECT_LTO_WRAPPER=/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/gaius/GM2/graft-combine/gcc-git-devel-modula2/configure 
--prefix=/home/gaius/opt --libexecdir=/home/gaius/opt/lib 
--enable-threads=posix --enable-clocale=gnu --enable-languages=m2 
--enable-multilib --enable-checking --enable-long-longx --enable-bootstrap 
--with-build-config=bootstrap-Og
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220519 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-I/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim'
 '-ftarget-ar=/usr/bin/ar' '-ftarget-ranlib=/usr/bin/ranlib' 
'-fobject-path=/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim' 
'-x' 'modula-2' '-fplugin=m2rte' 
'-L/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim' 
'-L/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim' 
'-shared-libgcc' '-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
 /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/cc1gm2 
-iplugindir=/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/plugin -quiet 
-dumpdir a- -dumpbase hello.mod -dumpbase-ext .mod -mtune=generic -march=x86-64 
-version -ftarget-ar=/usr/bin/ar -ftarget-ranlib=/usr/bin/ranlib 
-fobject-path=/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim 
-fplugin=m2rte -ftarget-ar=/usr/bin/ar -ftarget-ranlib=/usr/bin/ranlib 
-fobject-path=/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim 
-fplugin=m2rte -I/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim -o 
/tmp/cc8BoL3d.s hello.mod
GNU Modula-2  1.9.5  (20220520)
  grafted onto GCC 13.0.0
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv2: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
GNU Modula-2 (GCC) version 13.0.0 20220519 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 13.0.0 20220519 (experimental), GMP version 
6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Versions of loaded plugins:
 m2rte: Unknown version.
GNU Modula-2 (GCC) version 13.0.0 20220519 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 13.0.0 20220519 (experimental), GMP version 
6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Versions of loaded plugins:
 m2rte: Unknown version.
COLLECT_GCC_OPTIONS='-I/home/gaius/opt/lib/gcc/x86_64-pc-l

[PATCH] DSE: Use the constant source if possible

[H.J. Lu via Gcc-patches]

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;
+   }
+   }
+   }
}
 }
 
diff --git a/gcc/testsuite/g++.target/i386/pr105638.C 
b/gcc/testsuite/g++.target/i386/pr105638.C
new file mode 100644
index 000..ff40a459de1
--- /dev/null
+++ b/gcc/testsuite/g++.target/i386/pr105638.C
@@ -0,0 +1,44 @@
+/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-options "-std=gnu++20 -O2 -march=skylake" } */
+/* { dg-final { scan-assembler-not "vpxor" } } */
+
+#include 
+#include 
+#include 
+
+class FastBoard {
+public:
+typedef std::pair movescore_t;
+typedef std::tr1::array scoredlist_t;
+
+protected:
+std::vector m_critical;
+
+int m_boardsize;
+};
+
+class FastState {
+public:
+FastBoard board;
+
+int movenum;  
+protected:
+FastBoard::scoredlist_t scoredmoves;
+};
+
+class KoState : public FastState {
+private: 
+std::vector ko_hash_history;   
+std::vector hash_history; 
+};
+
+class GameState : public KoState {
+public:
+void foo ();  
+private:
+std::vector game_history;  
+};
+
+void GameState::foo() {
+game_history.resize(movenum);
+}
-- 
2.36.1